¿GridFS es lo suficientemente rápido y confiable para la producción?

Desarrollo un nuevo sitio web y quiero usar GridFS como almacenamiento para todas las cargas de los usuarios, porque ofrece muchas ventajas en comparación con un almacenamiento de sistema de archivos normal.

Los puntos de referencia con GridFS servidos por nginx indican que no es tan rápido como un sistema de archivos normal servido por nginx.

Benchmark con nginx

¿Hay alguien que ya use GridFS en un entorno de producción o lo usaría para un nuevo proyecto?

Utilizo gridfs en el trabajo en uno de nuestros servidores, que es parte de un sitio web de comparación de precios con estadísticas de tráfico honorables (alrededor de 25.000 visitantes por día). El servidor no tiene mucha memoria RAM, 2gigs, e incluso la CPU no es realmente rápida (Core 2 duo 1.8Ghz) pero el servidor tiene mucho espacio de almacenamiento: 10Tb (sata) en configuración raid 0. El trabajo que está haciendo el servidor es muy simple:

Cada producto en nuestro comparador de precios tiene una imagen (hay alrededor de 10 millones de productos según nuestro producto db), y el trabajo de los servidores es descargar la imagen, cambiar su tamaño, almacenarla en gridfs y entregarla al navegador de los visitantes. .. si no está presente en la cuadrícula ... o ... envíelo al navegador de los visitantes si ya está almacenado en la cuadrícula. Por lo tanto, esto podría denominarse como un "esquema cdn tradicional".

Hemos almacenado y procesado 4 millones de imágenes en este servidor desde que está en funcionamiento. El cambio de tamaño y almacenamiento se realiza mediante un simple script php ... pero seguro, un script de Python o algo como Java podría ser más rápido.

Tamaño de datos actual: 11,23g

Tamaño de almacenamiento actual: 12,5 g

Índices: 5

Tamaño del índice: 849,65 m

Acerca de la confiabilidad: esto es muy confiable. El servidor no se carga, el tamaño del índice está bien, las consultas son rápidas

Acerca de la velocidad: seguro, ¿no es rápido como almacenamiento de archivos local, quizás un 10% más lento, pero lo suficientemente rápido como para usarse en tiempo real incluso cuando la imagen necesita ser procesada, que en nuestro caso depende mucho de php? Los tiempos de mantenimiento y desarrollo también se han reducido: se volvió tan simple eliminar una o varias imágenes: simplemente consulte la base de datos con un simple comando de eliminación. Otra cosa interesante: cuando reiniciamos nuestro servidor anterior, con almacenamiento de archivos local (millones de archivos en miles de carpetas), a veces se cuelga durante horas porque el sistema estaba realizando una verificación de integridad de archivos (esto realmente tomó horas ...). Ya no tenemos este problema con gridfs, nuestras imágenes ahora se almacenan en grandes trozos de mongodb (archivos de 2gb)

Entonces ... en mi mente ... Sí, gridfs es lo suficientemente rápido y confiable como para usarse en producción.

Como se mencionó, puede que no sea tan rápido como un sistema de archivos ordinario, pero luego le brinda ventajas sobre los sistemas de archivos ordinarios por los que creo que vale la pena renunciar a un poco de velocidad.

En última instancia, con la fragmentación, sin embargo, puede llegar a un punto en el que el almacenamiento GridFS se convierte en la opción más rápida en comparación con un sistema de archivos ordinario y un solo nodo.

Sin embargo, esté atento a las reparaciones para bases de datos más grandes: un nuevo sistema que estamos desarrollando, mongo no salió limpiamente, y la reparación del GridFS de 7TB parece que llevará 130 horas.

Debido a esto, creo que consideraré cambiar a OpenStack Swift o Ceph. Aún así, hasta entonces estuvo bien. Y el módulo nginx-gridfs es genial.

El módulo nginx-gridfs de mdirolf es excelente y bastante fácil de configurar. Lo estamos usando en producción en paint.ly para servir todas las pinturas y hasta ahora no ha habido problemas.

No recomiendo usar gridfs a menos que sepa lo que está haciendo. GridFS es solo una capa de abstracción que divide los archivos en trozos y almacena los archivos en dos colecciones. Más archivos, más gastos generales. Si espera que los archivos sean del mismo tamaño, que no superen los 32M o menos, está en el camino correcto. No intente almacenar archivos grandes en gridfs. ¿Por qué?

1. Los controladores en diferentes idiomas pueden leer el archivo completo (por ejemplo, fragmentos) al leer la pequeña parte del archivo.
2. La modificación del archivo puede afectar a todos los fragmentos y aumentar la carga de la base de datos. Si su sistema de archivos está creciendo, tendrá que decidir dividir el gridfs. ¡Ten cuidado! ¡La consistencia no está garantizada cuando se inicializa la fragmentación!

Si piensa en un proyecto cargado de lectura, considere cargar los archivos en documentos directamente (si es de 16M o menos) o elija otro clusterfs y vincule el nombre de archivo / inodo a su lógica.

Espero que esto ayude.