Almacenamiento de Imágenes en DB - Sí o No?

https://stackoverflow.com/questions/3748

08-06-2019
|

Pregunta

Así que estoy usando una aplicación que almacena las imágenes en gran medida en la DB.¿Cuál es tu perspectiva sobre esto?Yo soy más de un tipo para almacenar la ubicación en el sistema de ficheros, de los guarda directamente en la base de datos.

¿Cuáles crees que son los pros y los contras?

No hay solución correcta

Otros consejos

Estoy a cargo de algunas de las aplicaciones que gestionan muchos TB de imágenes.Hemos encontrado que el almacenamiento de rutas de acceso de archivo en la base de datos para ser mejor.

Hay un par de cuestiones:

almacenamiento de base de datos es generalmente más caro que el sistema de almacenamiento de archivos
usted puede super-acelerar el acceso a archivos del sistema con la norma fuera de la plataforma de productos
- por ejemplo, muchos servidores web que utilizan el sistema operativo sendfile() sistema de llamada de forma asincrónica enviar un archivo directamente desde el sistema de archivos a la interfaz de red.Las imágenes almacenadas en una base de datos no se benefician de esta optimización.
cosas como los servidores web, etc, no necesitan especial de codificación o de procesamiento de acceder a las imágenes en el sistema de archivos
bases de datos de la gana donde la integridad transaccional entre la imagen y metadatos son importantes.
- es más complejo de administrar la integridad entre db metadatos del sistema de archivos y datos
- es difícil (en el contexto de una aplicación web) para garantizar que los datos han sido eliminadas en el disco en el sistema de ficheros

Como con la mayoría de los problemas, no es tan simple como suena.Hay casos en que tendría sentido para almacenar las imágenes en la base de datos.

Usted es el almacenamiento de imágenes que se cambiando dinámicamente, dicen las facturas, y que quería que para obtener una factura como lo fue el 1 de enero de 2007?
El gobierno quiere mantener a los 6 años de historia
Las imágenes almacenadas en la base de datos no requieren una diferente estrategia de copia de seguridad.Las imágenes almacenadas en el sistema de ficheros ¿
Es más fácil controlar el acceso a las imágenes si están en una base de datos.De inactividad a los administradores acceder a cualquier carpeta en el disco.Se necesita un determinado admin para ir a curiosear en una base de datos para extraer las imágenes

Por otro lado, existen problemas asociados

Requiere código adicional para extraer y la secuencia de las imágenes
La latencia puede ser más lento que el acceso directo a archivos
Más pesado de la carga en el servidor de base de datos

Almacén de archivos.Facebook ingenieros tuvieron una gran charla sobre ello.Una toma de distancia para saber el límite práctico de archivos en un directorio.

Aguja en un Pajar:El Almacenamiento eficiente de miles de Millones de Fotos

Este podría ser un poco de un tiro largo, pero si usted está utilizando (o la planificación sobre el uso de SQL Server 2008 recomiendo echar un vistazo a la nueva FileStream tipo de datos.

FileStream resuelve la mayoría de los problemas alrededor de almacenamiento de los archivos en la DB:

Los Blobs son en realidad almacenan como archivos en una carpeta.
Las notas pueden ser accedidos usando ya sea una conexión de base de datos o sobre el sistema de ficheros.
Las copias de seguridad están integrados.
La migración "simplemente funciona".

Sin embargo SQL "Cifrado de Datos Transparente" no cifrar los objetos FileStream, por lo que si es una cuenta, usted puede ser mejor simplemente almacenarlas como varbinary.

Desde el Artículo de MSDN:

Instrucciones de Transact-SQL puede insertar, actualizar, consultar, buscar, y copia de seguridad de los datos FILESTREAM.Win32 sistema de archivos que proporcionan las interfaces de transmisión de acceso a los datos.
FILESTREAM utiliza el sistema de caché para almacenar en caché los datos de archivo.Esto ayuda a reducir cualquier efecto de que los datos FILESTREAM podría tener en la Base de datos de rendimiento del Motor.El SQL Server de grupo de búfer no se utiliza;por lo tanto, esta memoria está disponible para el procesamiento de consultas.

Rutas de archivo en la base de datos es definitivamente el camino a seguir - he oído hablar de la historia después de la historia de los clientes con la TUBERCULOSIS de las imágenes que se convirtió en una pesadilla tratando de almacenar cualquier cantidad significativa de imágenes en un DB - el impacto en el rendimiento solo es demasiado.

En mi experiencia, a veces la solución más sencilla es el nombre de las imágenes de acuerdo a la clave principal.Así que es fácil encontrar la imagen que pertenece a un registro en particular, y viceversa.Pero al mismo tiempo no estás almacenando nada sobre la imagen en la base de datos.

El truco aquí es para no convertirse en un fanático.

Una cosa a tener en cuenta aquí es que nadie en el pro sistema de archivos campamento ha incluido un sistema de archivos específico.¿Significa esto que todo lo de FAT16 a ZFS fácilmente late cada base de datos?

No.

La verdad es que muchas bases de datos de vencer a muchos de los sistemas de archivos, incluso cuando estamos hablando sólo de la velocidad pura.

El curso de acción correcto es tomar la decisión correcta para su escenario preciso, y para hacer eso, usted necesitará algunos números y algunos casos de uso de estimaciones.

En los lugares donde se DEBE garantizar la integridad referencial y ÁCIDO cumplimiento, almacenamiento de imágenes en la base de datos se requiere.

Usted no puede transactionaly garantía de que la imagen y el meta-datos acerca de que la imagen almacenada en la base de datos hacen referencia al mismo archivo.En otras palabras, es imposible garantizar que el archivo en el sistema de archivos es de sólo ha alterado al mismo tiempo y en la misma transacción, como los metadatos.

Como otros han dicho, SQL 2008 viene con un Filestream tipo que permite almacenar un nombre o identificador como un puntero en la base de datos y almacena automáticamente la imagen en el sistema de ficheros que es un gran escenario.

Si usted está en una base de datos anterior, entonces yo diría que si usted está almacenando como datos blob, entonces usted realmente no va a conseguir nada fuera de la base de datos en el camino de la búsqueda de características, por lo que es probablemente la mejor manera de almacenar una dirección en un sistema de ficheros, y el almacén de la imagen de esa manera.

De esa manera se ahorra espacio en tu sistema de archivos, ya que sólo va a ahorrar la cantidad exacta de espacio, o incluso compactado de espacio en el sistema de archivos.

También, usted puede decidir guardar con algún tipo de estructura o los elementos que permiten navegar por las imágenes raw en su sistema de ficheros sin ningún db de éxitos, o la transferencia de los archivos de forma masiva a otro sistema, disco duro, S3 o el otro escenario de actualización de la ubicación en el programa, pero mantener la estructura, de nuevo sin mucho de un golpe tratando de llevar las imágenes de tu db cuando se intenta aumentar la capacidad de almacenamiento.

Probablemente, esto también permite arrojar algo de caché de elementos, basados en que comúnmente se golpeó la url de imagen en tu web o motor de programa, de modo que puedes ahorrar así.

Pequeñas imágenes estáticas (no más de un par de megas) que no se modifica con frecuencia, deben ser almacenados en la base de datos.Este método tiene varias ventajas, incluyendo más fácil portabilidad (imágenes se transfieren a la base de datos), más fácil de copia de seguridad/restaurar (las imágenes de copia de seguridad con la base de datos) y una mejor escalabilidad (una carpeta del sistema de archivos con miles de pequeñas miniaturas de los archivos de los sonidos, como una escalabilidad pesadilla para mí).

Servir las imágenes de una base de datos es sencillo, basta con implementar un controlador http que sirve la matriz de bytes devueltos a partir de la base de datos del servidor como una secuencia binaria.

He aquí un interesante libro blanco sobre el tema.

A BLOB o No BLOB:Gran Almacenamiento de Objetos en una Base de datos o un sistema de Ficheros

La respuesta es "depende". Sin duda que esto dependerá de que el servidor de base de datos y su enfoque de almacenamiento de blobs.También depende del tipo de datos que se almacenan en el blob, así como la forma en que los datos se tiene acceso.

Archivos de menor tamaño pueden ser eficientemente almacenados y enviados utilizando la base de datos como mecanismo de almacenamiento.Los archivos más grandes probablemente sería mejor guardados utilizando el sistema de archivos, especialmente si van a ser modificados o actualizados con frecuencia.(blob fragmentación se convierte en un problema en cuanto a rendimiento.)

He aquí un punto adicional a tener en cuenta.Una de las razones que apoyan el uso de una base de datos para almacenar los blobs es un ÁCIDO de cumplimiento.Sin embargo, el enfoque que los encargados de las pruebas utilizadas en el documento, (Masivas opción de SQL Server), el cual se duplicó el rendimiento de SQL Server, efectivamente ha cambiado la 'D' en ÁCIDO a una 'd', como los datos de blob no estaba conectado con la inicial escribe para la transacción.Por lo tanto, si el pleno cumplimiento de ACID es un requisito importante para el sistema, reducir a la mitad el rendimiento de SQL Server cifras de la base de datos escribe al comparar la e/S de archivo de base de datos blob I/O.

Una cosa que no he visto a nadie mencionar, pero es definitivamente vale la pena destacar es que hay problemas asociados con el almacenamiento de grandes cantidades de imágenes en la mayoría de los sistemas de ficheros demasiado.Por ejemplo, si usted toma el enfoque mencionado anteriormente y el nombre de cada archivo de imagen después de la clave primaria, en la mayoría de los sistemas de ficheros que se ejecutará en problemas si se intenta colocar todas las imágenes en un directorio una vez que llegue a un gran número de imágenes (por ejemplo,en los cientos de miles o millones).

Una vez que la solución común a este problema es el hash de ellos en un árbol equilibrado de los subdirectorios.

Algo que nadie ha mencionado es que el DB garantías de acciones atómicas, la integridad transaccional y ofertas de la concurrencia.Incluso referentially integridad está fuera de la ventana, con un sistema de archivos - entonces, ¿cómo saber los nombres de archivo son realmente correctas?

Si tienes tus imágenes en un archivo del sistema y alguien está leyendo el archivo como usted está escribiendo una nueva versión o incluso eliminar el archivo - ¿qué sucede?

Utilizamos blob, ya que son más fáciles de manejar (copia de seguridad, replicación de transferencia), también.Funcionan bien para nosotros.

El problema con el almacenamiento de sólo las rutas de los archivos de imágenes en una base de datos es que la base de datos de la integridad no puede ser forzado.

Si la imagen real a la que apunta la ruta del archivo no está disponible, la base de datos sin darse cuenta tiene un error de integridad.

Dado que las imágenes son los datos reales de ser buscados, y que pueden ser gestionados de manera más fácil (las imágenes no desaparecen de repente) integrado en una base de datos en lugar de tener una interfaz con algún tipo de sistema de ficheros (si el sistema de archivos es de acceso independiente, las imágenes PODRÍAN de repente "desaparecer"), me gustaría ir para almacenarlos directamente como un BLOB o tal.

En una empresa donde yo trabajaba se almacenan los 155 millones de imágenes en un Oracle 8i (luego 9i) de la base de datos.7.5 TB vale la pena.

Normalmente, soy storngly en contra de tomar la más cara y más difícil a escala de una parte de su infraestructura (base de datos) y poniendo toda la carga en él.En el otro lado:Esto simplifica en gran medida la estrategia de copia de seguridad, sobre todo cuando se tienen varios servidores web y necesitan de alguna manera mantener los datos sincronizados.

Como la mayoría de otras cosas, depende del tamaño esperado y Presupuesto.

Hemos implementado un documento de imagen del sistema que almacena todas las imágenes en SQL2005 campos blob.Hay varios cientos de GB en el momento y estamos viendo excelentes tiempos de respuesta y la poca o ninguna degradación en el rendimiento.Además, fr cumplimiento normativo, tenemos una capa de middleware que los archivos recién publicado documentos a una óptica jukebox sistema que se expone como un estándar de sistema de archivos NTFS.

Hemos quedado muy satisfechos con los resultados, en particular con respecto a:

Facilidad de duplicación y Copia de seguridad
Capacidad para implementar fácilmente un documento de sistema de control de versiones

Si esta es la aplicación basada en la web, entonces podría haber ventajas para almacenar las imágenes en un tercer partido de almacenamiento red de distribución, tales como Amazon S3 o el Nirvanix de la plataforma.

Asunción:La aplicación está habilitado para la web/web basado en

Me sorprende que nadie realmente ha mencionado esto ...delegar a los otros que son especialistas -> el uso de una 3ª parte de la imagen/archivo de proveedor de hosting.

Almacenar tus archivos en un pago de servicios en línea como

Otro de StackOverflow hilos hablando de esto aquí.

Este hilo explica por qué usted debe utilizar una 3ª parte de su proveedor de hosting.

Es así que vale la pena.El almacenar de manera eficiente.No hay ancho de banda de conseguir subido desde los servidores de solicitudes de cliente, etc.

Si no estás en SQL Server 2008 y tiene algunas razones sólidas para poner específicos de archivos de imagen en la base de datos, entonces usted puede tomar el "tanto" y utilizar el sistema de archivos como una caché temporal y el uso de la base de datos como repositorio principal.

Por ejemplo, la lógica de negocios se puede comprobar si un archivo de imagen existe en el disco antes de servir para arriba, la recuperación de la base de datos cuando sea necesario.Esta compra usted la capacidad de varios servidores web y menos problemas de sincronización.

No estoy seguro de cuánto de un "mundo real" ejemplo de ello es, pero actualmente tengo una aplicación por ahí que almacena los detalles de un juego de cartas coleccionables, incluyendo las imágenes de las cartas.Concedido el número de registros de la base de datos es sólo 2851 registros hasta la fecha, pero dado el hecho de que ciertas cartas se han publicado varias veces y alternativas obras de arte, en realidad, fue más eficiente sizewise para escanear la "plaza principal" de la obra de arte y, a continuación, generar dinámicamente la frontera y varios efectos para la tarjeta cuando se le solicite.

El creador original de esta imagen de la biblioteca crea un acceso a los datos de la clase que representa la imagen basado en la solicitud, y lo hace bastante rápido para la visualización y la tarjeta individual.

Esto también facilita la implementación y actualizaciones cuando las nuevas tarjetas son liberados, en lugar de comprimir una carpeta de imágenes y envío de abajo de la tubería y velando por la adecuada estructura de la carpeta se crea, yo simplemente la actualización de la base de datos y el usuario que descargar de nuevo.Actualmente tamaños de hasta 56MB, que no es gran cosa, pero estoy trabajando en una actualización incremental característica para futuras versiones.Además, hay un "no" imágenes " de la versión de la aplicación que permite a aquellos a través de acceso telefónico para obtener de la aplicación sin la descarga demora.

Esta solución ha trabajado a la fecha, ya que la aplicación en sí es considerada como un único ejemplo en el escritorio.Hay un sitio web donde todos estos datos son archivados para su acceso en línea, pero yo de ninguna manera el uso de la misma solución para esto.Estoy de acuerdo en el archivo de acceso sería preferible porque sería una escala de mejor a la frecuencia y el volumen de solicitudes que se realicen por las imágenes.

Esperemos que esto no es demasiado balbucear, pero vi el tema y quería proporcionar algunos de mis conocimientos a partir de una relativamente exitosa de pequeña/mediana escala de aplicación.

SQL Server 2008 ofrece una solución que tiene lo mejor de ambos mundos : El tipo de datos de filestream.

Administrar como una tabla normal y tienen el rendimiento del sistema de archivos.

Depende del número de imágenes que se van a almacenar y también su tamaño.He utilizado las bases de datos para almacenar las imágenes en el pasado, y mi experiencia ha sido bastante buena.

De la OMI, Ventajas de usar base de datos para almacenar imágenes,

A.Usted no necesita FS estructura para contener sus imágenes
B.Índices de base de datos se desempeñan mejor que los FS árboles cuando más número de elementos que se pueden almacenar
C.Elegantemente base de datos optimizada hacer un buen trabajo en la caché de los resultados de la consulta
D.Las copias de seguridad son simples.También funciona bien si usted tiene un conjunto de replicación y el contenido es enviado desde un servidor cerca de usuario.En tales casos, una sincronización explícita no es necesario.

Si las imágenes van a ser pequeños (digamos < 64 kb) y el motor de almacenamiento de tu db soporta inline (en el registro) BLOBs, mejora aún más el rendimiento como ningún direccionamiento es necesario (Localidad de referencia se logra).

Almacenamiento de imágenes puede ser una mala idea cuando se trata de lidiar con el pequeño número de enorme tamaño de las imágenes.Otro problema con el almacenamiento de imágenes en la base de datos es que, metadatos, como la creación, la modificación de las fechas que maneja la aplicación.

Recientemente he creado un PHP/MySQL aplicación que almacena los PDFs/archivos de Word en una tabla MySQL (tan grande como 40 MB por archivo hasta el momento).

Pros:

Los archivos subidos se replican al servidor de copia de seguridad junto con todo lo demás, no se separa la estrategia de copia de seguridad es necesario (que la paz de la mente).
Configurar el servidor web es un poco más sencillo porque no necesito tener un uploads/ carpeta y decirle a todos mis aplicaciones donde es.
Puedo llegar a utilizar las transacciones de modificaciones para mejorar la integridad de los datos - no tiene que preocuparse acerca de los huérfanos y de los archivos que faltan

Contras:

mysqldump ahora toma un looooong tiempo porque no es de 500MB de datos de un archivo en una de las mesas.
En general no es muy de memoria/cpu eficiente cuando se compara con el sistema de ficheros

Me gustaría llamar a mi la implementación de un éxito, que se ocupa de los requisitos de copia de seguridad y simplifica el diseño del proyecto.El rendimiento es bueno para los 20-30 personas que utilizan la aplicación.

Im mi experiencia he tenido que gestionar ambas situaciones:las imágenes almacenadas en la base de datos y de imágenes en el sistema de archivo con la ruta almacenada en la base de datos.

La primera solución, las imágenes en la base de datos, es algo más "limpios" como su capa de acceso a datos tendrá que lidiar sólo con objetos de base de datos;pero esto sólo es buena cuando usted tiene que tratar con números bajos.

Obviamente, acceso a bases de datos de rendimiento cuando se trabaja con objetos binarios grandes es degradante, y las dimensiones de base de datos va a crecer mucho, provocando de nuevo la pérdida de rendimiento...y, normalmente, espacio de base de datos es mucho más caro que el espacio del sistema de archivos.

Por otro lado tener grandes objetos binarios almacenados en el sistema de archivos va a hacer que usted tenga planes de copia de seguridad que se han de considerar tanto la base de datos y sistema de archivos, y esto puede ser un problema para algunos sistemas.

Otra razón para ir para el sistema de archivos es cuando usted tiene que compartir sus imágenes de datos (o sonidos, videos, lo que sea) con el acceso de terceros:en esto días estoy desarrollando una aplicación web que utiliza las imágenes que tienen para acceder desde "fuera" de mi granja de servidores web de tal manera que un acceso de base de datos para recuperar datos binarios, es simplemente imposible.Así que a veces hay también consideraciones de diseño que va a conducir a una elección.

Tenga en cuenta también que, al hacer esta elección, si usted tiene que tratar con el permiso y la autenticación de acceso a objetos binarios:estos requisitos normalmente puede ser resuelto de una manera más fácil cuando los datos se almacenan en la base de datos.

Una vez trabajé en un procesamiento de imagen de la aplicación.Se almacenan las imágenes cargadas en un directorio que era algo así como /images/[fecha de hoy]/[número de identificación].Pero también extrae los metadatos (datos exif) a partir de las imágenes y se almacena que en la base de datos, junto con una marca de tiempo y tal.

En un proyecto anterior que almacena las imágenes en el sistema de archivos, y que causó una gran cantidad de dolores de cabeza con las copias de seguridad, replicación, y el sistema de ficheros llegar fuera de sincronización con la base de datos.

En mi último proyecto en el que estoy almacenando las imágenes en la base de datos y la caché de ellos en el sistema de archivos, y funciona realmente bien.No he tenido problemas hasta ahora.

Segundo de la recomendación sobre las rutas de archivo.He trabajado en un par de proyectos que se necesitan para administrar grandes-ish de los activos de las colecciones, y cualquier intento de guardar las cosas directamente en la base de datos resultó en el dolor y la frustración a largo plazo.

La única verdadera "pro" no puedo pensar con respecto a su almacenamiento en la base de datos es el potencial para una fácil individuales de los activos de imagen.Si no hay ningún archivo de rutas a utilizar, y todas las imágenes se transmiten directamente de la base de datos, no hay peligro de que un usuario de búsqueda de archivos que no deberían tener acceso.

Que parece que sería mejor resuelto con un intermediario de secuencia de comandos de la extracción de datos de una web inaccesible almacén de archivos, sin embargo.Así que la base de datos de almacenamiento no es REALMENTE necesario.

La palabra en la calle es que, a menos que usted es un proveedor de base de datos tratando de demostrar que su base de datos puede hacerlo (como, digamos que Microsoft alardear de Terraserver almacenar un bajillion imágenes en SQL Server) no es una idea muy buena.Cuando la alternativa de almacenamiento de imágenes en los servidores de archivos y rutas de acceso en la base de datos es mucho más fácil, ¿por qué molestarse?Campos Blob son como el off-road de las capacidades de los Suv - la mayoría de la gente no las usa, aquellos que no suele meterse en problemas, y entonces hay quienes lo hacen, pero sólo por la diversión de hacerlo.

Almacenar una imagen en la base de datos todavía significa que los datos de la imagen termina en un lugar en el sistema de archivos, pero se oculta para que no se puede acceder a ella directamente.

+ves:

integridad de base de datos
su fácil de manejar ya que usted no tiene que preocuparse de mantener el sistema de ficheros en la sincronización cuando una imagen se agregan o eliminan

-ves:

penalización de rendimiento-una base de datos de búsqueda suele ser más lento que un sistema de ficheros de búsqueda
usted no puede editar directamente la imagen (recortar, redimensionar)

Ambos métodos son comunes y se practica.Eche un vistazo a las ventajas y desventajas.De cualquier manera, usted tendrá que pensar acerca de cómo superar las desventajas.Almacenar en la base de datos generalmente significa ajustar parámetros de base de datos y aplicar algún tipo de almacenamiento en caché.Utilizando el sistema de archivos requiere encontrar alguna manera de mantener el sistema de ficheros+base de datos en modo de sincronización.

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

No afiliado a StackOverflow