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.
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?
Réponses:
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.
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.
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.
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?
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.