GridFS est-il suffisamment rapide et fiable pour la production?


86

Je développe un nouveau site Web et je souhaite utiliser GridFS comme stockage pour tous les téléchargements d'utilisateurs, car il offre de nombreux avantages par rapport à un stockage de système de fichiers normal.

Les benchmarks avec GridFS servis par nginx indiquent qu'il n'est pas aussi rapide qu'un système de fichiers normal servi par nginx.

Benchmark avec nginx

Y a-t-il quelqu'un là-bas, qui utilise déjà GridFS dans un environnement de production, ou qui l'utiliserait pour un nouveau projet?


1
Un article de blog sur le stockage d'images dans mongodb pour les futurs chercheurs qui avaient une intention similaire à moi: menge.io/2015/03/24/storing-small-images-in-mongodb (compare GridFS en le jetant simplement dans le document comme binaire data)

Il y a beaucoup de compromis à considérer pour décider si vous voulez stocker des données binaires dans MongoDB - voir: alexmarquardt.com/2017/03/02/…
Alexander Marquardt

Réponses:


118

J'utilise gridfs au travail sur l'un de nos serveurs qui fait partie d'un site Web de comparaison de prix avec des statistiques de trafic honorables (environ 25 000 visiteurs par jour). Le serveur n'a pas beaucoup de RAM, 2 Go, et même le processeur n'est pas vraiment rapide (Core 2 duo 1,8 GHz) mais le serveur a beaucoup d'espace de stockage: 10 To (sata) en configuration raid 0. Le travail du serveur est très simple:

Chaque produit de notre comparateur de prix a une image (il y a environ 10 millions de produits selon notre db produit), et le travail des serveurs est de télécharger l'image, de la redimensionner, de la stocker sur gridfs et de la livrer au navigateur des visiteurs. .. s'il n'est pas présent dans la grille ... ou ... le livrer au navigateur des visiteurs s'il est déjà stocké dans la grille. Donc, cela pourrait être appelé un «schéma cdn traditionnel».

Nous avons stocké et traité 4 millions d'images sur ce serveur depuis qu'il est opérationnel. Le redimensionnement et le stockage sont effectués par un simple script php ... mais bien sûr, un script python, ou quelque chose comme java pourrait être plus rapide.

Taille actuelle des données: 11,23 g

Taille de stockage actuelle: 12,5 g

Indices: 5

Taille de l'index: 849,65 m

À propos de la fiabilité: c'est très fiable. Le serveur ne se charge pas, la taille de l'index est correcte, les requêtes sont rapides

À propos de la vitesse: Bien sûr, n'est-il pas rapide en tant que stockage de fichiers local, peut-être 10% plus lent, mais suffisamment rapide pour être utilisé en temps réel même lorsque l'image doit être traitée, ce qui est dans notre cas très dépendant de php. Les temps de maintenance et de développement ont également été réduits: il est devenu si simple de supprimer une ou plusieurs images: il suffit d'interroger la base de données avec une simple commande de suppression. Autre chose intéressante: lorsque nous avons redémarré notre ancien serveur, avec un stockage de fichiers local (donc des millions de fichiers dans des milliers de dossiers), il se bloque parfois pendant des heures car le système effectuait un contrôle d'intégrité des fichiers (cela a vraiment pris des heures ...). Nous n'avons plus ce problème avec gridfs, nos images sont maintenant stockées dans de gros morceaux mongodb (fichiers de 2 Go)

Donc ... dans mon esprit ... Oui, gridfs est suffisamment rapide et fiable pour être utilisé pour la production.


9
Je suis choqué que quiconque utilise le raid 0 comme stockage principal sur un site Web de production. Même avec de bonnes sauvegardes, augmenter la probabilité d'une panne de stockage est un prix assez élevé à payer pour améliorer les performances.
mikerobi

67
Nous utilisons le raid 0 car dans notre cas particulier, les données d'image peuvent être volatiles. Peu importe si l'image est perdue puisque nous la téléchargerons à nouveau depuis le site Web du marchand. Pragmatiquement, nous pourrions considérer que notre serveur est un simple serveur de cache d'images.
Manu Eidenberger

Mais vous augmentez activement le risque de défaillance (facteur de défaillance initial du disque multiplié par le nombre de broches). Raid 10 serait idéal si vous avez besoin de plus d'écritures que de lectures ou Raid 5/6 si vous avez besoin de plus de lectures que d'écritures.
NeuroScr

9
@ManuEidenberger Pourquoi utilisez-vous GridFS pour stocker des images qui préfèrent être stockées dans un document MongoDB? Je suppose que vous n'avez pas atteint la limite de taille de document de 16 Mo. Et stocker l'image en tant que BLOB dans un document MongoDB serait plus efficace, car vous n'avez pas besoin de la couche GridFS au-dessus des documents MongoDB.
Arnaud Bouchez

1
Je suis également curieux de connaître la question de @ ArnaudBouchez. Y a-t-il eu un avantage qui vous a poussé à choisir GridFS plutôt que de simplement le stocker sous forme de données binaires dans un document, Manu? Merci!

12

Comme mentionné, ce n'est peut-être pas aussi rapide qu'un système de fichiers ordinaire, mais cela vous donne ensuite des avantages par rapport aux systèmes de fichiers ordinaires pour lesquels je pense qu'il vaut la peine de renoncer à un peu de vitesse.

En fin de compte, avec le partitionnement, vous pourriez atteindre un point où le stockage GridFS devient en fait l'option la plus rapide par opposition à un système de fichiers ordinaire et à un seul nœud.


6

Attention cependant aux réparations pour les bases de données plus volumineuses - un nouveau système que nous développons, mongo n'est pas sorti proprement, et la réparation du 7 To GridFS semble prendre 130 heures.

Pour cette raison, je pense que je vais envisager de passer à OpenStack Swift ou Ceph. Pourtant, jusque-là c'était bien. Et le module nginx-gridfs est sympa.


Alors, comment êtes-vous allé?
Mukus

5

Le module nginx-gridfs de mdirolf est excellent et assez facile à installer. Nous l'utilisons en production chez paint.ly pour servir toutes les peintures et il n'y a eu aucun problème jusqu'à présent.


3
paint.ly n'est plus disponible, semble-t-il. :(
Marian

2

Je ne recommande pas d'utiliser gridfs à moins que vous ne sachiez ce que vous faites. GridFS est juste une couche d'abstraction qui divise les fichiers en morceaux et stocke les fichiers dans deux collections. Plus de fichiers - plus de frais généraux. Si vous vous attendez à ce que les fichiers aient à peu près la même taille, ne dépassant pas 32 Mo environ, vous êtes dans la bonne voie. N'essayez pas de stocker des fichiers volumineux sur gridfs. Pourquoi?

  1. Les pilotes de différentes langues peuvent lire le fichier entier (par exemple des morceaux) lors de la lecture de la petite partie du fichier.
  2. La modification du fichier peut affecter tous les morceaux et augmenter la charge de la base de données. Si votre système de fichiers se développe, vous devrez décider de fragmenter les gridfs. Faites attention! La cohérence n'est pas garantie lors de l'initialisation du sharding!

Si vous pensez à lire un projet chargé, envisagez de charger les fichiers directement dans des documents (si la taille est de 16 Mo ou moins) ou choisissez un autre clusterfs, et liez le nom de fichier / inode à votre logique.

J'espère que cela t'aides.


4
Je suis assez nouveau sur GridFS mais d'après ce que je comprends, GridFS est plus qu'une simple couche d'abstraction qui double le nombre de fichiers. GridFS fournit un moyen simple de tirer parti des fonctionnalités de réplication et de partitionnement de MongoDB. Je crois que d'autres ont également mentionné que les fichiers sont stockés par blocs de 2 Go, ce qui, j'imagine, réduirait le nombre total de fichiers, surtout si quelqu'un a une très grande quantité de petites images.

+1 Vous avez raison. Même des fichiers plus petits ne gagneraient pas à être stockés avec GridFS. Si votre fichier pouvait être stocké dans un document MongoDB (c'est-à-dire <de sa taille limite de 16 Mo), vous préféreriez stocker le fichier en tant que BLOB dans un document MongoDB. Il contournera la surcharge de l'utilisation de GridFS au-dessus du stockage MongoDB. Voir compose.io/articles/gridfs-and-mongodb-pros-and-cons
Arnaud Bouchez
En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.