Pregunta

Estoy agregando algunas funcionalidades a mi sitio para que los usuarios puedan cargar sus propias imágenes de perfil, por lo que me preguntaba si almacenarlas en la base de datos como BLOB o colocarlas en el sistema de archivos.

Encontré una pregunta similar a esta aquí: Almacenamiento de imágenes en DB: Sí o No , pero las respuestas dadas se dirigieron más a personas que esperaban muchos miles o incluso millones de imágenes, mientras que estoy más preocupado por las imágenes pequeñas (JPEG de hasta 150x150 píxeles) y un pequeño número de ellas: quizás 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 las imágenes de DB vs del sistema de archivos?

Si los BLOB almacenados en la base de datos son el camino a seguir, ¿hay algo que deba saber sobre dónde para almacenarlos? Como me imagino que la mayoría de mis usuarios no subirán una imagen, ¿debería crear una tabla user_pics para unirme (externamente) a la tabla normal de usuarios cuando sea necesario?


Editar: estoy reabriendo esta pregunta, porque no es un duplicado de los dos a los que se vinculó. Esta pregunta es específicamente sobre las ventajas y desventajas de utilizar una base de datos o FS para una PEQUEÑA cantidad de imágenes. Como dije anteriormente, la otra pregunta está dirigida a personas que necesitan almacenar miles y miles de imágenes grandes.

¿Fue útil?

Solución

Para responder partes de su 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: tenga un campo last_modified en su base de datos. Utilice el encabezado HTTP de última modificación para que el navegador del cliente pueda almacenar en caché correctamente. Asegúrese de enviar las respuestas apropiadas cuando el navegador solicite una imagen "si es más nueva". (no recuerdo cómo se llama; algún encabezado de solicitud HTTP).

Para un sistema de archivos: haga lo mismo, pero con el tiempo modificado del archivo.

  

Si los BLOB almacenados en la base de datos son el camino a seguir, ¿hay algo que deba saber sobre dónde almacenarlos? Dado que imagino que la mayoría de mis usuarios no subirán una imagen, ¿debería crear una tabla user_pics para unirme (externamente) a la tabla de usuarios normales cuando sea necesario?

Pondría el BLOB y los metadatos relacionados en su propia tabla, con algún tipo de relación entre él y su tabla de usuario. Hacer esto facilitará la optimización del método de almacenamiento de la tabla para sus datos, hará que las cosas estén más ordenadas y deje espacio para la capacidad de expansión (por ejemplo, una tabla general de "archivos").

Otros consejos

Una vez enfrenté una pregunta similar con un pequeño DMS para archivos pdf. El escenario era diferente al suyo: un máximo de 100 archivos con tamaños de hasta 10 MB cada uno, no es lo que espera para las imágenes de perfil. Pero la respuesta que me dio un amigo en ese momento también se aplica a su 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 general para empezar.

Nunca he oído que Windows FS sea lento y, a veces, poco confiable, como afirma Aaron Digulla en su respuesta. Si hay tales problemas, esto ciertamente debe tenerse en cuenta. Pero para las imágenes de avatar, no me parece importante.

(*) Lo sé, lo sé, 42 ...

¿Qué sería más conveniente, desde la perspectiva de servirlos, 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, todo lo que pueda quedar fuera de la base de datos debe quedar afuera. Puede ser un sistema de archivos o tablas separadas que no se replican ni respaldan todos los días. Hace que la base de datos sea mucho más ligera, se hace más lenta 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, a veces, incluso poco confiable.

En Linux, tiene más opciones. Aquí, debe considerar mover archivos grandes a un sistema de archivos y simplemente mantener el nombre en la base de datos. 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 debe lidiar con la complejidad adicional de leer / escribir BLOB. En muchos DB, no se pueden buscar BLOB.

En el sistema de archivos, puede ejecutar otras herramientas en sus datos que no es posible si los archivos se almacenan en una base de datos.

Los almacenaría en la base de datos:

  1. La copia de seguridad / restauración es fácil (si hace una copia de seguridad de los archivos y también de la base de datos, la recuperación en un punto en el tiempo es más complicada)
  2. Las transacciones en la base de datos significan que nunca debe terminar apuntando a un nombre de archivo que no está allí
  3. Menos posibilidades de que alguien descubra una forma astuta de poner un script en su servidor a través de un truco de carga de imagen poco fiable

Dado que está hablando de un pequeño número de imágenes, la facilidad de uso / administración debe preferir los problemas de rendimiento que se debaten en las preguntas vinculadas.

Creo que hay una ventaja de manejabilidad al almacenarlos en la base de datos; se pueden hacer copias de seguridad y restaurar de manera coherente con los otros datos: no olvidará eliminar los obsoletos (bueno, podría, pero es un poco menos probable), y si migra la base de datos a otra máquina, las imágenes irán con

Licenciado bajo: CC-BY-SA con atribución
No afiliado a StackOverflow
scroll top