¿Es un mal diseño almacenar imágenes como blobs en una base de datos?

Lo he hecho en ambos sentidos varias veces para sitios web muy grandes con tráfico de alto volumen.

Bill Karwin tiene razón en que no puede hacer una declaración inequívoca de que almacenar imágenes en una base de datos siempre es malo. Me gustan muchos de sus puntos. La mayoría de las personas que están en contra de las imágenes en el DB generalmente promueven lo único que saben hacer.

Cualquiera de los inconvenientes relacionados con el llenado del almacenamiento de la base de datos o los riesgos del tamaño de la base de datos claramente no toma en serio la administración de una base de datos. Esas cosas son fácilmente manejables con las mejores prácticas más rudimentarias.

La primera pregunta que me gustaría hacer al tomar tales decisiones es, ¿qué tan importante es que la imagen física y los metadatos asociados con la imagen estén sincronizados? Existe un riesgo cuando separa los metadatos de los datos de la imagen que se desincronizarán.

Lo siguiente que considero es, ¿quiénes son sus desarrolladores de bases de datos? Trabajar con blobs en cada plataforma requiere pasos con los que la mayoría de los desarrolladores de db no están familiarizados. Si sus desarrolladores solo saben cómo interactuar con una plataforma de base de datos en un estilo CRUD solamente y no hay un verdadero especialista en bases de datos en el equipo, entonces tiene sentido colocar las imágenes fuera de la base de datos.

¿Qué patrones de diseño estás usando cuando las imágenes necesitan actualizarse? Si está utilizando una Red de entrega de contenido o va directamente a una página web, puede cambiar lo que desea hacer. Dependiendo de si tiene muchas actualizaciones de imágenes o casi ninguna también puede influir en su decisión.

Personalmente, no tengo una preferencia fuerte siempre que mi personal que lo implemente sea lo suficientemente sofisticado como para hacerlo en ambos sentidos. Si existe una alta tolerancia para lidiar con el riesgo de que las imágenes y los metadatos asociados se desincronicen y el personal de la base de datos no es sofisticado, lo almacenaré fuera de la base de datos.

Los últimos sitios en los que he estado involucrado definitivamente han almacenado gráficos (incluido el contenido cargado por el usuario) como archivos.

El beneficio es básicamente la escalabilidad.

En el nivel más fácil, los archivos viven en un directorio conocido en su servidor (e, idealmente, la aplicación está escrita para que la ‘ubicación de inicio del archivo de imagen’ sea, por falta de un término mejor, una variable global). [Estado aquí cada vez]

Luego, cuando http://www.yoursite.com esté ocupado, puede mover las imágenes a images.mysite.com y separar los requisitos para un servidor con grandes cantidades de espacio y ancho de banda, pero poca potencia de procesamiento (el almacén de imágenes ) del servidor que necesita mucha potencia de procesamiento (la base de datos / aplicación / ‘web html’) finaliza. [He estado aquí algunas veces]

Luego, cuando images.mysite.com comienza a crecer, obtiene una tecnología para pasar una tarde ajustando su código de replicación de archivos y pegar el lote en un grupo de servidores detrás de un equilibrador de carga. [He estado aquí cinco veces]

Luego, cuando su sitio es enorme, telefonea a su proveedor de CDN favorito y solicita un presupuesto [Estuve aquí una vez]

Hola ! Si tiene la capacidad de personalizar los parámetros de la base de datos, está listo. Eso puede depender del proveedor de la nube y db también. Hablando de AWS, tienes RDS MySQL. Allí puede usar el tipo de datos BLOB para almacenar sus imágenes. ¿Por qué es una buena opción? Debido a que tiene grupos de parámetros, donde puede personalizar ciertos parámetros según su caso de uso. En nuestro caso, los archivos de imagen pueden ser de diferentes tamaños. Por lo tanto, puede crear su grupo de parámetros personalizados y modificar algunos parámetros y adjuntar ese grupo a su instancia de MySQL. Seguramente necesitará cambiar el valor de max_allowed_packet de acuerdo con el tamaño máximo, cree que sus imágenes pueden subir. Luego, puede alterar los valores de parámetros como net_write_timeout, etc., de acuerdo con su entorno OLTP / OLAP (tráfico, número de conexiones, etc.). Espero que eso ayude.

Yo diría que es una mala idea. Solía ​​ser la forma de hacerlo. Pero ahora que existen estos grandes servicios de almacenamiento en la nube como s3 y el almacenamiento en la nube de Google, es mucho mejor que solo almacene imágenes en ellos y coloque la URL de la imagen en la base de datos.

Pros y contras de tenerlo en el DB:
pros:
– todos los datos en un solo lugar
– fácil de usar para uso local
contras:
– ocupa mucho espacio
– DB es más probable que tenga espacio finito
– tiene que usar más potencia de cómputo en su servidor de aplicaciones para recuperar la imagen

Pros y contras de anotar solo la URL en la base de datos:
pros:
– muchos matones
– más portátil
– más legible
– expanda fácilmente el almacenamiento en hosts en la nube
– Menos trabajo en sus servidores para servir
contras:
– tiene que pagar a un proveedor de host en la nube
– tienes que subir tus archivos
– Muchas de las URL son ilegibles.

Como otros han dicho, almacene la ruta en el DB. Esto le brinda flexibilidad si desea migrar sus imágenes de un sistema de archivos local a un CDN. Sin embargo, si planea almacenar imágenes pequeñas como miniaturas, puede almacenarlas en la base de datos. Su aplicación funcionará mejor que almacenar las imágenes pequeñas en el sistema de archivos.

Una ventaja obvia de almacenar imágenes como archivos ordinarios es que su servidor web puede servirlas de manera eficiente directamente, evitando así su capa de aplicación, su controlador de base de datos y su base de datos. Bueno, en teoria. Es posible que no desee hacerlo así por razones de seguridad. Depende de cómo se implemente su autenticación / autorización.

Es aconsejable no almacenar imágenes en la base de datos y utilizar direcciones URL para vincular a las imágenes almacenadas en otro lugar como flickr o las carpetas de imágenes en su sitio web. Siempre puede editar / reemplazar / actualizar sus imágenes para que estén actualizadas sin interferir con la base de datos. También puede usar imágenes gratuitas de Internet o del sitio web de sus clientes. Puede vincular videos de youtube / vimeo, archivos pdf almacenados en una nube. Acerca de las bases de datos, 10 bases de datos no es una limitación en mi opinión. Puede crear tantas tablas como desee en cada base de datos. pero el almacenamiento total de la base de datos en MB es lo que cuenta para sus gastos. Debe organizar, diseñar y estructurar su base de datos para satisfacer sus necesidades.

Estoy de acuerdo con Ed y recomiendo almacenar imágenes fuera de la base de datos. Hay muchas razones, pero algunas de las más importantes son:

• Es mucho más fácil administrar, ver y manipular imágenes que están en el sistema de archivos. Puede usar herramientas de línea de comandos estándar (por ejemplo, imagemagick para cambiar el tamaño o recortar) y visores de imágenes.
• Proporciona flexibilidad a largo plazo. Como ya se mencionó, las imágenes pueden consumir mucho espacio y, al mantenerlas separadas, tiene una base de datos más pequeña para manejar y más opciones para escalar en el futuro. Podría, por ejemplo, mover todas sus imágenes a un servidor completamente separado.
• Los blobs son a menudo un elemento “gotcha” en muchas soluciones de replicación y respaldo.

Algo a tener en cuenta es si desea publicar imágenes localmente. El S3 de Amazon y plataformas de almacenamiento de medios similares se escalan mucho mejor que su sistema de archivos y se integran con el servicio de almacenamiento en caché, lo que hace que la distribución sea más escalable y más fSter.

En la medida en que la plataforma elástica de almacenamiento en la nube maneja el respaldo, usted también resuelve ese problema.

Todavía querría una copia de archivo local. Y también almacenaría la clave de nube elástica y algunos metadatos en la base de datos.

Esto no funcionará en todas las situaciones. Pero deberías considerarlo.

HTH

No hay muchas situaciones en las que recomendaría almacenar algo más que texto en una base de datos. Claro, puede almacenar archivos en una base de datos Mysql, pero eso no significa que deba hacerlo.

Si le importa el rendimiento y la facilidad de mantenimiento, almacene las rutas a las imágenes y no al revés. El espacio en disco puede ser barato, pero si está almacenando muchos archivos, pronto ocupará mucho espacio y no será bonito, especialmente cuando sus consultas se vuelven tan lentas, su aplicación tarda literalmente segundos en completarse.

Descubrí que después de una cierta cantidad de imágenes, comencé a tener problemas con la base de datos. El almacenamiento de imágenes en la base de datos provoca hinchazón, ralentiza las copias de seguridad e impacta el rendimiento de db.

La mayoría de los sitios grandes almacenan sus imágenes en el sistema de archivos y luego las duplican en un CDN para permitir que otros servidores sirvan esas imágenes para un mejor rendimiento del sitio

Las siguientes son algunas razones por las que las imágenes no deben almacenarse como BLOBS en la base de datos:

• leer / escribir en una base de datos siempre es más lento que un sistema de archivos
• Las copias de seguridad de su base de datos se vuelven enormes y requieren más tiempo. También puso una carga pesada en el servidor de la base de datos.
• Requerir código adicional para extraer y transmitir las imágenes

• Los servidores web necesitan codificación o procesamiento especial para acceder a las imágenes en el sistema de archivos

Uno de los problemas con el almacenamiento de archivos como blobs es que su base de datos se inflará rápidamente en tamaño. Recientemente tuve un cliente que tenía su sitio configurado de esta manera, pero necesitaba actualizar sus sistemas y quería un nuevo sitio. Su base de datos tenía un tamaño de más de un gigabyte y era difícil tratar con una base de datos de ese tamaño por una gran cantidad de razones, incluida la dificultad para quitarla del servidor para implementarla en mi servidor de desarrollo.

Los sistemas de archivos permiten una mejor organización y permitirán transferencias más fáciles en el futuro si necesita cambiar servidores o versiones de software.

Como han dicho otros, realmente solo debe almacenar texto en bases de datos, nada binario. Ponga las rutas a las imágenes en su base de datos y las imágenes en el disco. Si tiene que preocuparse por la escalabilidad, el tiempo de actividad, etc., busque usar un CDN para almacenar las imágenes, de modo que se sirvan desde una plataforma más sólida que un solo servidor.

Si almacena imágenes en DB, puede utilizar muchos beneficios, como conexiones, consultas, funciones, estrategias de copia de seguridad en caché y de copia de seguridad. bla bla … Por otro lado, puede almacenar una gran cantidad de imágenes sin miedo a su base de datos, tamaño de las imágenes, número, … también puede elegir almacenar en el sistema de archivos normal o distribuido en función de lo que necesita.

Cuando se compara con las imágenes como archivos, hay una ventaja si son pequeñas (iconos) y espera una audiencia razonable (sin almacenamiento en caché del archivo del lado del cliente), puede confiar en la replicación de DB que seguramente estará allí para tener estas imágenes disponibles En más lugares.

Es mejor cuando almacena la imagen en una carpeta y actualiza su ruta en su base de datos MySQL. Disminuirá el tamaño de su base de datos y se procesará más rápido cuando no solicite la base de datos cada vez que se necesite mostrar una imagen. Debe cuidar el nombre de la imagen que le está dando. Por ejemplo, puede agregar la fecha y la hora en el nombre de la imagen para evitar la redundancia de datos.

Guárdelos en S3.