mongodb - imagenes - que es gridfs

MongoDB como almacenamiento de archivos

Question

Estoy tratando de encontrar la mejor solución para crear almacenamiento escalable para archivos grandes. El tamaño del archivo puede variar de 1 a 2 megabytes y de 500 a 600 gigabytes.

He encontrado información sobre Hadoop y su HDFS, pero parece un poco complicado, porque no necesito ningún trabajo de Map / Reduce y muchas otras funciones. Ahora estoy pensando en usar MongoDB y es GridFS como solución de almacenamiento de archivos.

Y ahora las preguntas:

1. ¿Qué pasará con gridfs cuando intento escribir pocos archivos a la vez? ¿Habrá algún bloqueo para las operaciones de lectura / escritura? (Lo usaré solo como almacenamiento de archivos)
2. ¿Se almacenarán en caché los archivos de gridfs en RAM y cómo afectará el rendimiento de lectura-escritura?
3. Tal vez hay algunas otras soluciones que pueden resolver mi problema de manera más eficiente?

Gracias.

Answer 1

¿Ha considerado guardar metadatos en MongoDB y escribir archivos reales en Amazon S3? Ambos tienen excelentes controladores y este último es altamente redundante, con almacenamiento de archivos preparado para la nube / cdn. Yo le daría una oportunidad.

Answer 2

Empezaré por contestar los dos primeros:

1. Hay un bloqueo de escritura al escribir en GridFS, sí. No hay bloqueo para las lecturas.
2. Los archivos no se almacenarán en la memoria caché cuando los consulte, pero sus metadatos sí.

Es posible que GridFS no sea la mejor solución para su problema. Los bloqueos de escritura pueden convertirse en una molestia cuando se trata de este tipo de situación, especialmente para archivos grandes. Hay otras bases de datos que pueden resolver este problema por usted. HDFS es una buena opción, pero como usted dice, es muy complicado. Recomendaría considerar un mecanismo de almacenamiento como Riak o S3 de Amazon. Están más orientados a ser el almacenamiento de archivos y no tienen grandes inconvenientes. S3 y Riak tienen excelentes instalaciones de administración y pueden manejar archivos de gran tamaño. Aunque con Riak, lo último que sabía, tenía que hacer algunos fragmentos de archivos para almacenar archivos de más de 100 mb. A pesar de eso, generalmente es una buena práctica hacer un cierto nivel de fragmentación para tamaños de archivo enormes. Hay muchas cosas malas que pueden suceder al transferir archivos a las bases de datos: desde los tiempos de espera de la red hasta los desbordamientos de búfer, etc. De cualquier manera, su solución requerirá una cantidad justa de ajuste para tamaños de archivo masivos.

Answer 3

Solo puedo responder por MongoDB aquí, no pretenderé saber mucho sobre HDFS y otras tecnologías similares.

La implementación de GridFs es totalmente del lado del cliente dentro del controlador. Esto significa que no hay una carga o comprensión especial del contexto del servicio de archivos dentro de MongoDB, efectivamente, MongoDB ni siquiera entiende que son archivos ( http://docs.mongodb.org/manual/applications/gridfs/ ).

Esto significa que la consulta de cualquier parte de la colección de files o chunks resultará en el mismo proceso que para cualquier otra consulta, por lo que carga los datos que necesita en su conjunto de trabajo ( http://en.wikipedia.org/wiki/Working_set ) que representa un conjunto de datos (o todos los datos cargados en ese momento) requeridos por MongoDB dentro de un marco de tiempo dado para mantener un rendimiento óptimo. Lo hace paginándolo en RAM (bueno, técnicamente el sistema operativo lo hace).

Otro punto a tener en cuenta es que este controlador está implementado. Esto significa que la especificación puede variar, sin embargo, no creo que lo haga. Todos los controladores le permitirán consultar un conjunto de documentos de la colección de files que solo aloja los metadatos de los archivos, lo que le permite servir el archivo posteriormente desde la colección de chunks con una sola consulta.

Sin embargo, eso no es lo importante, usted quiere servir el archivo en sí, incluyendo sus datos; esto significa que cargará la colección de files y su posterior colección de chunks en su conjunto de trabajo.

Con eso en mente, ya hemos alcanzado el primer obstáculo:

¿Se almacenarán en caché los archivos de gridfs en RAM y cómo afectará el rendimiento de lectura-escritura?

El rendimiento de lectura de archivos pequeños podría ser impresionante, directamente desde la RAM; Las escrituras serían igual de buenas.

Para archivos más grandes, no es así. La mayoría de las computadoras no tendrán 600 GB de RAM y es probable, de hecho, bastante normal, alojar una partición de 600 GB de un solo archivo en una sola instancia mongod . Esto crea un problema ya que ese archivo, para que se sirva, debe encajar en su conjunto de trabajo, sin embargo, es increíblemente más grande que su RAM; en este punto, es posible que tenga páginas en movimiento ( http://en.wikipedia.org/wiki/Thrashing_%28computer_science%29 ) en las que el servidor solo tiene errores de página 24/7 al intentar cargar el archivo. Los escritos aquí tampoco son mejores.

La única forma de evitar esto es comenzar a colocar un solo archivo en muchos fragmentos :/ .

Nota: una cosa más a tener en cuenta es que el tamaño promedio predeterminado de los "trozos" es de 256 KB, por lo que es una gran cantidad de documentos para un archivo de 600 GB. Esta configuración es manipulable en la mayoría de los controladores.

¿Qué pasará con gridfs cuando intento escribir pocos archivos a la vez? ¿Habrá algún bloqueo para las operaciones de lectura / escritura? (Lo usaré solo como almacenamiento de archivos)

GridFS, al ser solo una especificación usa los mismos bloqueos que en cualquier otra colección, tanto los bloqueos de lectura como los de escritura en un nivel de base de datos (2.2+) o en un nivel global (pre-2.2). Los dos también interfieren entre sí, es decir, ¿cómo puede garantizar una lectura coherente de un documento que se está escribiendo?

Dicho esto, existe la posibilidad de disputa en función de su situación específica, el tráfico, el número de escrituras / lecturas concurrentes y muchas otras cosas de las que no tenemos idea.

Tal vez hay algunas otras soluciones que pueden resolver mi problema de manera más eficiente?

Personalmente, he encontrado que S3 (como dijo @mluggy) en formato de redundancia reducida funciona mejor almacenando una mera porción de metadatos sobre el archivo dentro de MongoDB, muy parecido a usar GridFS pero sin la colección de fragmentos, deje que S3 maneje toda esa distribución, respaldo y otras cosas para ti

Esperemos que haya sido claro, espero que ayude.

Edición: A diferencia de lo que dije accidentalmente, MongoDB no tiene un bloqueo de nivel de recopilación, es un bloqueo de nivel de base de datos.