database - filestore - que es gridfs
Almacenar una pequeña cantidad de imágenes: blob o fs? (7)
Estoy agregando algunas funcionalidades a mi sitio para que los usuarios puedan cargar sus propias imágenes de perfil, así que me preguntaba si almacenarlas en la base de datos como BLOB, o ponerlas en el sistema de archivos.
Encontré una pregunta similar aquí: almacenar imágenes en DB: sí o no , pero las respuestas dadas estaban más orientadas hacia las personas que esperaban muchos miles o incluso millones de imágenes, mientras que me preocupan más las imágenes pequeñas (JPEG hasta tal vez 150x150 píxeles), y un pequeño número de ellos: tal vez hasta uno o dos mil.
¿Cuáles son los sentimientos acerca de DB BLOB vs Filesystem para este escenario? ¿Cómo van los clientes con el almacenamiento en caché de imágenes de la base de datos frente al sistema de archivos?
Si los BLOB almacenados en el DB son el camino a seguir, ¿hay algo que deba saber sobre dónde almacenarlos? Como imagino que la mayoría de mis usuarios no subirán una imagen, ¿debo crear una tabla user_pics para (externa) unirme a la tabla de users habituales cuando sea necesario?
Editar: Estoy volviendo a abrir esta pregunta, porque no es un duplicado de los dos con los que se vinculó. Esta pregunta es específicamente sobre los pros / contras de usar un DB o FS para una PEQUEÑA cantidad de imágenes. Como dije antes, la otra pregunta está dirigida a personas que necesitan almacenar miles y miles de imágenes grandes.
¿Qué sería más conveniente, desde la perspectiva de atenderlos, escribir el código para servirlos, procedimientos de respaldo, etc.? Desea la respuesta correcta para usted, no la respuesta correcta para otra persona.
Desde mi punto de vista, cualquier cosa que quede fuera de la base de datos debería permanecer fuera. Puede ser un sistema de archivos o tablas separadas que no se replican ni se respaldan todos los días. Hace que la base de datos sea mucho más liviana, crece más despacio y es más fácil de entender y mantener.
Si está en MSSQL, asegúrese de que los blobs estén almacenados en un archivo de datos separado. No en PRIMARIO como todo lo demás.
En Windows, ponga todo lo que pueda en la base de datos. El sistema de archivos es algo lento y algunas veces incluso poco confiable.
En Linux, tienes más opciones. Aquí, debería considerar mover archivos grandes a un sistema de archivos y simplemente mantener el nombre en el DB. Si utiliza un sistema de archivos moderno como Ext3 o ReiseFS, incluso puede crear muchos archivos pequeños con un rendimiento bastante bueno.
También debe tener en cuenta cómo puede acceder a los datos. Si tiene todo en la base de datos, tiene una ruta de acceso, no necesita preocuparse por otro conjunto de permisos, pero tiene que lidiar con la complejidad adicional de leer / escribir BLOB. En muchos DB, los BLOB no se pueden buscar.
En el sistema de archivos, puede ejecutar otras herramientas en sus datos, lo que no es posible si los archivos están almacenados en un DB.
Para responder partes de tu pregunta:
¿Cómo van los clientes con el almacenamiento en caché de imágenes de la base de datos frente al sistema de archivos?
Para una base de datos: tener un campo last_modified en su base de datos. Utilice el encabezado HTTP Last-Modified para que el navegador del cliente pueda almacenar en caché correctamente. Asegúrese de enviar las respuestas adecuadas cuando el navegador solicite una imagen "si es más reciente" (no puede recordar cómo se llama, algún encabezado de solicitud HTTP).
Para un sistema de archivos: haga lo mismo, pero con la hora modificada del archivo.
Si los BLOB almacenados en el DB son el camino a seguir, ¿hay algo que deba saber sobre dónde almacenarlos? Como imagino que la mayoría de mis usuarios no subirán una imagen, ¿debo crear una tabla user_pics para (externa) unirme a la tabla de usuarios habituales cuando sea necesario?
Pondría el BLOB y los metadatos relacionados en su propia tabla, con algún tipo de relación entre este y su tabla de usuarios. Hacer esto facilitará la optimización del método de almacenamiento de la tabla para sus datos, hará las cosas más ordenadas y deja espacio para la capacidad de expansión (por ejemplo, una tabla general de "archivos").
Una vez me enfrenté a una pregunta similar con un pequeño DMS para archivos pdf. El escenario era diferente al suyo: un máximo de puede ser de 100 archivos con tamaños de hasta 10 MB cada uno, no lo que espera para las imágenes de perfil. Pero la respuesta que me dio un amigo también se aplica a tu caso:
Use cada sistema de almacenamiento para lo que está diseñado para hacer.
Almacenar datos en una base de datos . Almacene archivos en un sistema de archivos .
Esta no es la respuesta final (*), pero es una buena regla para los principiantes.
Nunca escuché que Windows FS sea lento y, a veces, poco confiable, como dice Aaron Digulla en su respuesta. Si hay tales problemas, esto debe tenerse en cuenta. Pero para las imágenes de avatar, no me parece tan importante.
(*) Lo sé, lo sé, 42 ...
Creo que hay una ventaja de manejabilidad almacenándolos en la base de datos; se pueden respaldar y restaurar de manera consistente con los otros datos; no se olvidará de eliminar los obsoletos (bueno, es posible, pero es menos probable), y si migra la base de datos a otra máquina, las imágenes van con eso.
Yo los almacenaría en la base de datos:
- Copia de seguridad / restauración es fácil (si copias de seguridad de archivos y también la base de datos, recuperación de punto en el tiempo es más complicado)
- Las transacciones en el db significan que nunca debes terminar apuntando a un nombre de archivo que no está allí
- Menos posibilidades de que alguien descubra una forma furtiva de poner un guión en su servidor a través de un truco de carga de imagen dudosa
Ya que está hablando de un número reducido de imágenes, la facilidad de uso / administración debe tener preferencia sobre los problemas de rendimiento que se debaten en las preguntas vinculadas.