Para hacer o no hacer: almacenar imágenes en una base de datos [duplicar]

https://stackoverflow.com/questions/815626

03-07-2019
|

Pregunta

Esta pregunta ya tiene una respuesta aquí:

Almacenamiento de imágenes en DB: ¿Sí o no? 56 respuestas

En el contexto de una aplicación web, mi antiguo jefe siempre dijo que colocaba una referencia a una imagen en la base de datos, no a la imagen en sí. Tiendo a estar de acuerdo en que almacenar una URL frente a la imagen en sí en la base de datos es una buena idea, pero donde trabajo ahora, almacenamos muchas imágenes en la base de datos.

¿La única razón por la que puedo pensar es quizás más segura? ¿No quieres que alguien tenga un enlace directo a una url? Pero si ese es el caso, siempre puede hacer que el sitio web / servidor maneje las imágenes, como los controladores en asp.net, de modo que el usuario tenga que autenticarse para ver la imagen. También estoy pensando que el rendimiento se vería afectado al extraer las imágenes de la base de datos. ¿Alguna otra razón por la que podría ser una buena / no tan buena idea almacenar imágenes en una base de datos?

Exact Duplicate: Imágenes del usuario: almacenamiento de la base de datos o del sistema de archivos ?
Exacto duplicado: Almacenamiento de imágenes en la base de datos: sí o no ?
Exacto duplicado: Debería ¿Guardar mis imágenes en la base de datos o en las carpetas?
Exacto duplicado: ¿Almacenarías datos binarios en bases de datos o carpetas?
Exacto duplicado: ¿Guardar imágenes como archivos o como base de datos para una aplicación web?
Exact Duplicate: Almacenar un número pequeño de imágenes: blob o fs?
Exact Duplicate: almacenar imagen en el sistema de archivos o base de datos?

Solución

Si en ocasiones necesita recuperar una imagen y tiene que estar disponible en varios servidores web diferentes. Pero creo que eso es todo.

Si no tiene que estar disponible en varios servidores, siempre es mejor colocarlos en el sistema de archivos.
Si tiene que estar disponible en varios servidores y en realidad hay algún tipo de carga en el sistema, necesitará algún tipo de almacenamiento distribuido.

Estamos hablando de un caso de vanguardia aquí, donde puede evitar agregar un nivel adicional de complejidad a su sistema aprovechando la base de datos.

Aparte de eso, no lo hagas.

Otros consejos

Ventajas de poner imágenes en una base de datos.

Transacciones. Cuando guarda el blob, puede enviarlo como cualquier otro dato de base de datos. Eso significa que puede confirmar el blob junto con cualquiera de los metadatos asociados y estar seguro de que los dos están sincronizados. Si te quedas sin espacio en disco? No cometer. ¿El archivo no se cargó completamente? No cometer. ¿Error tonto de la aplicación? No cometer. Si mantener las imágenes y sus metadatos correspondientes es importante para su aplicación, entonces las transacciones que puede proporcionar una base de datos pueden ser de gran ayuda.
Un sistema para gestionar. ¿Necesitas hacer una copia de seguridad de los metadatos y las manchas? Copia de seguridad de la base de datos. ¿Necesitas replicarlos? Replicar la base de datos. ¿Necesita recuperarse de un fallo parcial del sistema? Recargue la base de datos y avance los registros. Todas las ventajas que aportan los DB a los datos en general (asignación de volumen, control de almacenamiento, copias de seguridad, replicación, recuperación, etc.) se aplican a sus blobs. Más coherencia, una gestión más sencilla.
Seguridad. Las bases de datos tienen características de seguridad muy finas que se pueden aprovechar. Esquemas, roles de usuario, incluso cosas como " vistas de solo lectura " para dar acceso seguro a un subconjunto de datos. Todas esas características funcionan también con tablas que contienen manchas.
Gestión centralizada. Relacionado con el # 2, pero básicamente los DBA (como si no tuvieran suficiente poder) pueden administrar una cosa: la base de datos. Las bases de datos modernas (especialmente las más grandes) funcionan muy bien con instalaciones grandes en varias máquinas. Una única fuente de gestión simplifica los procedimientos, simplifica la transferencia de conocimientos.
La mayoría de las bases de datos modernas manejan blobs muy bien. Con el soporte de blobs de primera clase en su nivel de datos, puede transmitir fácilmente blobs desde la base de datos al cliente. Si bien hay operaciones que puedes hacer, se succionarán " " toda la burbuja de una vez, si no necesita esa instalación, entonces no la use. Estudie la interfaz SQL para su base de datos y aproveche sus características. No hay razón para tratarlos como " grandes cadenas " que se tratan de forma monolítica y conviertan tus burbujas en grandes, que engullen la memoria, destruyen las bombas.
Al igual que puede configurar servidores de archivos dedicados para imágenes, puede configurar servidores de blob dedicados en su base de datos. Ofrézcales volúmenes de discos dedicados, esquemas dedicados, cachés dedicados, etc. Todos sus datos en la base de datos no son iguales, o se comportan de la misma manera, no hay razón para configurarlos de todos modos. Las buenas bases de datos tienen un buen nivel de control.

El principal problema relacionado con el servicio de un blob desde una base de datos es garantizar que su capa HTTP realmente aproveche todo el protocolo HTTP para realizar el servicio.

Muchas implementaciones ingenuas simplemente toman el blob y las vuelcan al azar. Pero HTTP tiene varias características importantes que se adaptan bien a la transmisión de imágenes, etc. En particular, el almacenamiento en caché de encabezados, ETags y la transferencia fragmentada para permitir que los clientes soliciten " piezas " del blob.

Asegúrese de que su servicio HTTP respeta correctamente todas esas solicitudes, y su base de datos puede ser un muy buen ciudadano de la Web. Al almacenar en caché los archivos en un sistema de archivos para ser servidos por el servidor HTTP, obtendrá algunas de esas ventajas " gratis " (ya que un buen servidor lo hará de todos modos para los recursos de " static "), pero asegúrese de que si lo hace, respete cosas como las fechas de modificación, etc. para las imágenes.

Por ejemplo, alguien solicita spaceshuttle.jpg, una imagen creada el 1 de enero de 2009. Eso termina en caché en el sistema de archivos en la fecha de solicitud, por ejemplo, el 1 de febrero de 2009. Luego, la imagen se elimina de la caché. (Política FIFO, o lo que sea), y alguien, más tarde, el 1 de marzo de 2009 lo solicita nuevamente. Bueno, ahora tiene una fecha de creación del 1 de marzo de 2009, aunque la fecha de creación fue realmente el 1 de enero. Por lo tanto, puede ver, especialmente si su caché gira mucho, los clientes que pueden usar If -Los encabezados modificados pueden estar obteniendo más datos de los que realmente necesitan, ya que el servidor PIENSA que el recurso ha cambiado, cuando en realidad no lo ha hecho.

Si mantiene la fecha de creación de la memoria caché sincronizada con la fecha de creación real, esto puede ser un problema menor.

Pero el punto es que es algo para pensar en todo el problema para ser un "buen ciudadano de la red", y ahorrarle a usted y a sus clientes un poco de ancho de banda, etc.

Acabo de pasar por todo esto para un proyecto Java que sirve videos desde una base de datos, y todo funciona a la perfección.

Entiendo que la mayoría de los profesionales de bases de datos cruzarán sus dedos y silbidos si almacena imágenes en la base de datos (o incluso la menciona). Sí, definitivamente hay implicaciones de rendimiento y almacenamiento cuando se usa la base de datos como repositorio para grandes bloques de datos binarios de cualquier tipo (las imágenes tienden a ser los bits de datos más comunes que no pueden normalizarse). Sin embargo, existen circunstancias en las que el almacenamiento de imágenes en la base de datos no solo es admisible, sino aconsejable .

Por ejemplo, en mi antiguo trabajo teníamos una aplicación donde los usuarios adjuntaban imágenes a varios puntos diferentes de un informe que estaban escribiendo, y esas imágenes tenían que imprimirse cuando se hizo. Estos informes se trasladaron a través de la replicación de SQL Server, y habría introducido un ENORME dolor de cabeza para tratar de administrar estas imágenes y rutas de archivos a través de múltiples sistemas y servidores con cualquier tipo de confiabilidad. Almacenarlos en la base de datos nos dio todo eso " gratis, " y la herramienta de informes no tuvo que salir al sistema de archivos para recuperar la imagen.

Mi consejo general sería no limitarse a uno u otro enfoque: siga la técnica que se ajuste a la situación. Los sistemas de archivos son muy buenos para almacenar archivos, y las bases de datos son muy buenas para proporcionar porciones de datos de tamaño reducido a pedido. Por otro lado, uno de los productos de mi empresa tiene el requisito de almacenar todo el estado de la aplicación en la base de datos, lo que significa que los archivos adjuntos también se almacenan allí. Con nuestro servidor de base de datos (SQL Server 2005) todavía no he encontrado problemas de rendimiento observables incluso con grandes clientes y bases de datos.

El SQL 2008 de Microsoft le ofrece lo mejor de ambos mundos con la función FileStream; podría valer la pena echarle un vistazo. http://technet.microsoft.com/en-us/library/bb933993.aspx

Una de las ventajas de almacenar imágenes en la base de datos es que es portátil en todos los sistemas e independiente en el diseño de los sistemas de archivos.

La solución más simple / con mejor rendimiento / más escalable es almacenar sus imágenes en el sistema de archivos. Si la seguridad es una preocupación, colóquelas en una ubicación a la que no pueda acceder el servidor web y escriba un script que maneje la seguridad y sirva los archivos.

Suponiendo que su servidor de aplicaciones / web y el servidor de bases de datos son máquinas diferentes, recibirá algunas visitas colocando imágenes en la base de datos: (1) Latencia de red entre las dos máquinas, (2) sobrecarga de conexión de base de datos, (3) consumo una conexión DB adicional para cada imagen servida. Me preocuparía más el último punto: si su sitio contiene muchas imágenes, sus servidores web consumirán muchas conexiones de base de datos y podrían agotar sus grupos de conexiones.

Si su aplicación se ejecuta en varios servidores, almacenaría la copia de referencia de sus imágenes en la base de datos y luego las almacenaría en la memoria caché en los sistemas de archivos. Hacerlo no es más que un dolor propenso a errores en el culo que intentar sincronizar los sistemas de archivos lateralmente.

Si su aplicación está en un solo servidor, sí, apéguese al sistema de archivos y haga que la base de datos mantenga una ruta de acceso a los datos.

La mayoría de las bases de datos SQL, por supuesto, no están diseñadas teniendo en cuenta las imágenes, pero hay una cierta comodidad asociada con tenerlas en la base de datos.

Por ejemplo, si ya tiene una base de datos en ejecución y tiene la replicación configurada. Al instante, tiene un almacén de imágenes HA en lugar de intentar trabajar con la replicación de un sistema de archivos basado en rsync o nfs. Además, tener un montón de procesos web (o diseñar algún servicio nuevo) para escribir archivos en el disco aumenta un poco su complejidad. Realmente solo son más partes móviles.

Como mínimo, recomendaría mantener los 'meta' datos sobre la imagen (como los permisos, quién la posee, etc.) y los datos reales separados en tablas diferentes, por lo que será bastante fácil cambiar a una almacén de datos en la línea. Eso, junto con algún tipo de CDN o almacenamiento en caché, debería proporcionarte un buen rendimiento hasta cierto punto, por lo que supongo que depende de qué tan escalable deba ser esta aplicación y cómo se equilibre con la facilidad de implementación.

No tiene que almacenar la URL (si cree que esto no es seguro). Solo puede almacenar una ID única que haga referencia a la imagen en otro lugar.

El almacenamiento de la base de datos tiende a ser más costoso y costoso de mantener que un sistema de archivos, por lo que no almacenaría MUCHAS imágenes en una base de datos.

la recuperación de desastres no es para nada divertida cuando tienes terabytes de datos de imagen almacenados en la base de datos. Es mejor encontrar una mejor manera de distribuir sus datos para hacerlos más confiables, etc ... Por supuesto, todos los gastos generales (mencionados anteriormente) se multiplican al replicar y así sucesivamente ...

¡No lo hagas!

Esto realmente parece un problema de KISS (mantenlo simple y estúpido). Los sistemas de archivos están diseñados para manejar fácilmente el almacenamiento de archivos de imágenes, pero no es fácil de hacer en una base de datos y es fácil desordenar los datos. ¿Por qué tener un impacto en el rendimiento y toda la dificultad en el sql y la renderización cuando solo puede preocuparse por la seguridad de los archivos? También puede manejar sistemas mixtos con NFS o CIFS. Los sistemas de archivos son tecnologías maduras. Mucho más simple, más robusto.

He almacenado imágenes en una base de datos para una aplicación de demostración. La razón por la que lo hice fue por seguridad: eliminar un registro que no debería no era un gran problema, ¡pero eliminar un archivo que no debería haber sido podría haber sido un problema!

Si el rendimiento se convirtiera en un problema, habría investigado si la eliminación de archivos maliciosos era una posibilidad real o no.

Si se trata de imágenes que se extraen de la base de datos de forma regular, siempre intentaría utilizar el sistema de archivos.

Si eran imágenes que debían sacarse de vez en cuando, y guardarlas en la base de datos hace la vida más fácil, no tengo ningún problema con esto.

base de datos para datos
sistema de archivos para archivos

Licenciado bajo: CC-BY-SA con atribución

No afiliado a StackOverflow