Le Fri, 27 Aug 2010 22:49:48 +0200, Pierre Chapuis catwell@archlinux.us a écrit :
"Jerome Benoit" jerome.benoit@grenouille.com a écrit :
Des données de type "multimédia" (ahah, définition alakon™ quand tu nous tiens), un type qui veut rien ou tout dire. C'est vendredi et je suis nase mais en gros des BLOBs et leur métadonnées exprimés en XML et du XML (du texte donc encodé en UTF-8).
Métadonnées que tu veux utiliser pour des requêtes je suppose ?
Et définir le schéma si je pars sur une dé-sérialisation du XML, oeuf de course.
Parce que sinon tu peux peut-être te contenter du FS distribué.
C'est ce que j'avais pensé faire pour mettre les BLOBs seulement et utiliser le NoSQL comme un index de hash par répertoire qui permet de retrouver rapidement la bonne version du BLOB. J'avais un htree à l'esprit plus exactement (comme dans ext{3,4}), le pb étant que le htree ne gère pas le versionning dans son design mais je peux réfléchir à comment le faire proprement.
Certains gèrent les métadonnées nativement (par exemple S3), avec les autres utiliser de simples fichiers texte est une possibilité.
Sinon, tout dépend du contenu de ton XML. Si tu ne le maitrises pas le plus simple sera probablement de prendre une base NoSQL orientée documents.
J'ai la maitrise du XML, c'est même un format standardisé pour certains la partie non métadonnées de BLOB.
Pour les blobs ça me semble une mauvaise idée de les stocker dans la base NoSQL. Presque toutes les gèrent mal et certaines ont des limites sur la taille des données pour éviter ce genre d'utilisation. > Beaucoup n'ont pas de type binaire non plus, et le base64 n'est pas vraiment une solution. C'est typiquement le rôle d'un FS distribué de stocker les assets.
Tu as raison et c'était mon idée première :)
a +.