GridFS est-il suffisamment rapide et fiable pour la production?
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 que ce n'est pas aussi rapide qu'un système de fichiers normal servi par nginx.
Y a-t-il quelqu'un qui utilise déjà GridFS dans un environnement de production, ou qui l'utiliserait pour un nouveau projet?
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.8Ghz) 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 sur notre comparateur de prix a une image (il y a environ 10 millions de produits selon notre base de données de produits), et le travail des serveurs consiste à télécharger l'image, à la redimensionner, à la stocker sur gridfs et à la livrer au navigateur des visiteurs. .. s'il n'est pas présent dans la grille ... ou ... remettez-le 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 pour 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, ce n'est pas rapide comme stockage de fichiers local, peut-être 10% plus lent, mais assez 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 une vérification d'intégrité des fichiers (cela prenait vraiment des heures ...). Nous n'avons plus ce problème avec gridfs, nos images sont maintenant stockées en gros morceaux mongodb (fichiers 2gb)
Donc ... dans mon esprit ... Oui, gridfs est suffisamment rapide et fiable pour être utilisé en production.
Comme mentionné, il n'est peut-être pas aussi rapide qu'un système de fichiers ordinaire mais cela vous donne des avantages par rapport à 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 cependant arriver à un point où le stockage GridFS devient en fait l'option plus rapide par opposition à un système de fichiers ordinaire et à un seul nœud.
le module nginx-gridfs de mdirolf est génial et assez facile à installer. Nous l'utilisons en production à Paint.ly pour servir toutes les peintures et il n'y a eu aucun problème jusqu'à présent.
Attention aux réparations pour les plus grandes bases de données - un nouveau système que nous développons, mongo n'a pas quitté proprement, et réparer les 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 doux.
Je ne recommande pas d'utiliser gridfs sauf si vous savez 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 soient à peu près de 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?
- Les pilotes dans différentes langues peuvent lire l'intégralité du fichier (par exemple des morceaux) lors de la lecture de la petite partie du fichier.
- 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 grandit, vous devrez décider de partager les grilles. Faites attention! La cohérence n'est pas garantie lors de l'initialisation du sharding!
Si vous pensez à un projet chargé en lecture - envisagez de charger les fichiers directement dans les 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.