Je ne peux répondre que 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 de service de fichiers dans MongoDB lui-même, effectivement MongoDB lui-même ne comprend même pas qu'il s'agit de fichiers ( http://docs.mongodb.org/manual/applications/gridfs/ ).
Cela signifie que l'interrogation de n'importe quelle partie des files ou chunks entraînera le même processus que pour toute autre requête, par lequel il charge les données dont il a besoin dans votre ensemble de travail ( http://en.wikipedia.org/wiki/Working_set ) qui représente un ensemble de données (ou toutes données chargées à ce moment-là) requises par MongoDB dans un laps de temps donné pour maintenir des performances optimales. Pour ce faire, il le pagine dans la RAM (enfin, techniquement, le système d'exploitation le fait).
Un autre point à prendre en considération est qu'il s'agit d'un pilote implémenté. Cela signifie que la spécification peut varier, cependant, je ne pense pas que ce soit le cas. Tous les pilotes vous permettront d'interroger un ensemble de documents à partir des files collection qui n'héberge que les métadonnées des fichiers vous permettant de servir ultérieurement le fichier lui-même à partir des chunks collection 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 les files collection et ses chunks suivants collection dans votre ensemble de travail.
Dans cet esprit, nous avons déjà rencontré le premier problème :
Les fichiers de gridfs seront-ils mis en cache dans la RAM et comment cela affectera-t-il les performances de lecture-écriture ?
Les performances de lecture de petits fichiers pourraient être impressionnantes, directement à partir de la RAM ; les écritures seraient tout aussi bonnes.
Pour les fichiers plus volumineux, ce n'est pas le cas. La plupart des ordinateurs n'auront pas 600 Go de RAM et il est probable, tout à fait normal en fait, d'héberger une partition de 600 Go d'un seul fichier sur un seul mongod exemple. Cela crée un problème car ce fichier, pour être servi, doit tenir dans votre ensemble de travail, mais il est incroyablement plus gros que votre RAM ; à ce stade, vous pourriez avoir un page thrashing ( http://en.wikipedia.org/wiki/Thrashing_%28computer_science%29 ) où le serveur ne fait que des erreurs de page 24 heures sur 24, 7 jours sur 7, essayant de charger le fichier. Les écritures ici ne sont pas meilleures non plus.
La seule façon de contourner cela est de commencer à mettre un seul fichier sur plusieurs partitions :\ .
Remarque :une autre chose à considérer est que la taille moyenne par défaut d'un chunks "morceau" est de 256 Ko, donc c'est 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 plusieurs fichiers simultanément. Y aura-t-il un verrou pour les opérations de lecture/écriture ? (Je ne l'utiliserai que 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 (pre-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 en cours d'écriture ?
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 y a-t-il d'autres solutions qui peuvent résoudre mon problème plus efficacement ?
J'ai personnellement trouvé que S3 (comme l'a dit @mluggy) dans un format de redondance réduite fonctionne mieux en stockant une simple partie des métadonnées sur le fichier dans MongoDB, un peu comme utiliser GridFS mais sans la collection de morceaux, laissez S3 gérer toute cette distribution, sauvegarde et d'autres choses pour vous.
J'espère avoir été clair, j'espère que ça aide.
Edit :Contrairement à ce que j'ai dit par inadvertance, MongoDB n'a pas de verrou au niveau de la collection, c'est un verrou au niveau de la base de données.
