MongoDB comme stockage de fichiers
j'essaie de trouver la meilleure solution pour créer un stockage évolutif pour les gros fichiers. La taille du fichier peut varier de 1 à 2 mégaoctets et jusqu'à 500 à 600 gigaoctets.
J'ai trouvé des informations sur Hadoop et son HDFS, mais cela semble un peu compliqué, car je n'ai pas besoin de travaux Map/Reduce et de nombreuses autres fonctionnalités. Maintenant, je pense utiliser MongoDB et c'est GridFS comme solution de stockage de fichiers.
Et maintenant les questions:
- Que se passera-t-il avec gridfs lorsque j'essaierai d'écrire quelques fichiers simultanément. Y aura-t-il un verrou pour les opérations de lecture/écriture? (Je vais l'utiliser uniquement comme stockage de fichiers)
- Les fichiers de gridfs seront-ils mis en cache dans ram et comment cela affectera-t-il les performances en lecture-écriture?
- Peut-être existe-t-il d'autres solutions qui peuvent résoudre mon problème plus efficacement?
Merci.
Je ne peux que répondre pour MongoDB ici, je ne prétendrai pas en savoir beaucoup sur HDFS et d'autres technologies similaires.
L'implémentation de GridFs est totalement côté client dans le pilote lui-même. Cela signifie qu'il n'y a pas de chargement spécial ou de compréhension du contexte du service de fichiers dans MongoDB lui-même, effectivement MongoDB lui-même ne comprend même pas que ce sont des fichiers ( http://docs.mongodb.org/manual/applications/gridfs/ ).
Cela signifie que la requête pour n'importe quelle partie de la collection files ou chunks se traduira par le même processus que pour toute autre requête, par laquelle elle charge les données dont elle a besoin dans votre ensemble de travail (- http://en.wikipedia.org/wiki/Working_set ) qui représente un ensemble de données (ou toutes les données chargées à ce moment) requises par MongoDB dans un laps de temps donné pour maintenir des performances optimales. Il le fait en le paginant dans RAM (eh bien techniquement le système d'exploitation le fait).
Un autre point à prendre en considération est que ce pilote est implémenté. Cela signifie que la spécification peut varier, mais je ne pense pas. Tous les pilotes vous permettront d'interroger un ensemble de documents de la collection files qui ne contient que les métadonnées des fichiers vous permettant de servir ultérieurement le fichier lui-même de la collection chunks avec une seule requête.
Cependant, ce n'est pas la chose importante, vous voulez servir le fichier lui-même, y compris ses données; cela signifie que vous allez charger la collection files et sa collection chunks suivante dans votre jeu de travail.
Dans cet esprit, nous avons déjà touché le premier hic:
Les fichiers de gridfs seront-ils mis en cache dans ram et comment cela affectera-t-il les performances en lecture-écriture?
Les performances de lecture de petits fichiers peuvent être impressionnantes, directement depuis la RAM; les écritures seraient tout aussi bonnes.
Pour les fichiers plus volumineux, non. La plupart des ordinateurs n'auront pas 600 Go de RAM et il est probable, tout à fait normal en fait, de loger une partition de 600 Go d'un seul fichier sur une seule instance mongod. Cette crée un problème car ce fichier, pour être servi, doit s'adapter à votre ensemble de travail, mais il est incroyablement plus grand que votre RAM; à ce stade, vous pourriez avoir une page thrashing ( http: //en.wikipedia. org/wiki/Thrashing_% 28computer_science% 29 ) par lequel le serveur fait juste des erreurs de page 24/7 essayant de charger le fichier. Les écritures ici ne sont pas mieux non plus.
La seule façon de contourner ce problème consiste à commencer à placer un seul fichier sur plusieurs fragments :\.
Remarque: une autre chose à considérer est que la taille moyenne par défaut d'un chunks "bloc" est de 256 Ko, ce qui représente beaucoup de documents pour un fichier de 600 Go. Ce paramètre est manipulable dans la plupart des pilotes.
Que se passera-t-il avec gridfs lorsque j'essaierai d'écrire quelques fichiers simultanément. Y aura-t-il un verrou pour les opérations de lecture/écriture? (Je vais l'utiliser uniquement comme stockage de fichiers)
GridFS, n'étant qu'une spécification, utilise les mêmes verrous que sur toute autre collection, à la fois des verrous en lecture et en écriture au niveau de la base de données (2.2+) ou au niveau global (pré-2.2). Les deux interfèrent également l'un avec l'autre, c'est-à-dire comment pouvez-vous assurer une lecture cohérente d'un document sur lequel vous écrivez?
Cela étant dit, la possibilité de conflit existe en fonction des spécificités de votre scénario, du trafic, du nombre d'écritures/lectures simultanées et de bien d'autres choses dont nous n'avons aucune idée.
Peut-être existe-t-il d'autres solutions qui peuvent résoudre mon problème plus efficacement?
Personnellement, j'ai trouvé que S3 (comme l'a dit @mluggy) au format de redondance réduite fonctionne mieux en stockant une simple portion de métadonnées sur le fichier dans MongoDB, tout comme l'utilisation de GridFS mais sans la collection de morceaux, laissez S3 gérer toute cette distribution, sauvegarde et d'autres trucs pour vous.
J'espère avoir été clair, j'espère que cela aide.
Edit: Contrairement à ce que j'ai accidentellement dit, MongoDB n'a pas de verrou au niveau de la collection, c'est un verrou au niveau de la base de données.
Je vais commencer par répondre aux deux premiers:
- Il y a un verrou en écriture lors de l'écriture dans GridFS, oui. Pas de verrou pour les lectures.
- Les fichiers ne seront pas mis en cache en mémoire lorsque vous les interrogerez, mais leurs métadonnées le seront.
GridFS n'est peut-être pas la meilleure solution à votre problème. Les verrous en écriture peuvent devenir quelque chose de pénible lorsque vous faites face à ce type de situation, en particulier pour les fichiers volumineux. Il existe d'autres bases de données qui peuvent résoudre ce problème pour vous. HDFS est un bon choix, mais comme vous le dites, c'est très compliqué. Je recommanderais d'envisager un mécanisme de stockage comme Riak ou Amazon S3. Ils sont plus orientés vers le stockage de fichiers et ne se retrouvent pas avec des inconvénients majeurs. S3 et Riak ont tous deux d'excellentes fonctionnalités d'administration et peuvent gérer d'énormes fichiers. Bien qu'avec Riak, la dernière fois que je le savais, vous deviez faire un segment de fichier pour stocker des fichiers de plus de 100 Mo. Malgré cela, il est généralement recommandé d'effectuer un certain niveau de segmentation pour les grandes tailles de fichiers. Il y a beaucoup de mauvaises choses qui peuvent se produire lors du transfert de fichiers vers des bases de données - Des délais d'expiration du réseau, aux débordements de tampon, etc.
Avez-vous envisagé d'enregistrer des métadonnées sur MongoDB et d'écrire des fichiers réels sur Amazon S3? Les deux ont d'excellents pilotes et ce dernier est un stockage de fichiers hautement redondant, prêt pour le cloud/cdn. Je lui donnerais un coup.