Entonces estoy usando una aplicación que almacena imágenes en gran medida en la base de datos. ¿Cuál es tu perspectiva sobre esto? Soy más de un tipo para almacenar la ubicación en el sistema de archivos, que almacenarla directamente en la base de datos.
¿Cuáles crees que son los pros / contras?
Respuestas:
Estoy a cargo de algunas aplicaciones que manejan muchas TB de imágenes. Descubrimos que almacenar rutas de archivos en la base de datos es lo mejor.
Hay un par de problemas:
Como con la mayoría de los problemas, no es tan simple como parece. Hay casos en los que tendría sentido almacenar las imágenes en la base de datos.
Por otro lado, hay problemas asociados.
Almacén de archivos. Los ingenieros de Facebook tuvieron una gran charla al respecto. Una conclusión fue conocer el límite práctico de los archivos en un directorio.
Aguja en un pajar: almacenamiento eficiente de miles de millones de fotos
Esto podría ser un poco arriesgado, pero si está utilizando (o planea utilizar) SQL Server 2008, le recomendaría que eche un vistazo al nuevo tipo de datos FileStream .
FileStream resuelve la mayoría de los problemas relacionados con el almacenamiento de archivos en la base de datos:
Sin embargo, el "Cifrado de datos transparente" de SQL no cifra los objetos FileStream, por lo que si eso es una consideración, es mejor que los almacene como varbinary.
Del artículo de MSDN:
Las instrucciones Transact-SQL pueden insertar, actualizar, consultar, buscar y hacer una copia de seguridad de los datos de FILESTREAM. Las interfaces del sistema de archivos Win32 proporcionan acceso de transmisión a los datos.
FILESTREAM utiliza la memoria caché del sistema NT para almacenar en caché los datos del archivo. Esto ayuda a reducir cualquier efecto que los datos de FILESTREAM puedan tener en el rendimiento del motor de base de datos. El grupo de búferes de SQL Server no se usa; por lo tanto, esta memoria está disponible para el procesamiento de consultas.
Las rutas de archivo en la base de datos son definitivamente el camino a seguir: he escuchado una historia tras otra de clientes con TB de imágenes que se convirtió en una pesadilla al tratar de almacenar una cantidad significativa de imágenes en una base de datos; el rendimiento solo es demasiado.
En mi experiencia, a veces la solución más simple es nombrar las imágenes de acuerdo con la clave principal . Por lo tanto, es fácil encontrar la imagen que pertenece a un registro en particular, y viceversa. Pero al mismo tiempo no está almacenando nada sobre la imagen en la base de datos.
El truco aquí es no convertirse en un fanático.
Una cosa a tener en cuenta aquí es que nadie en el campo del sistema de archivos profesional ha incluido un sistema de archivos en particular. ¿Significa esto que todo, desde FAT16 hasta ZFS, supera fácilmente a todas las bases de datos?
No.
La verdad es que muchas bases de datos superan a muchos sistemas de archivos, incluso cuando solo estamos hablando de velocidad bruta.
El curso de acción correcto es tomar la decisión correcta para su escenario preciso, y para hacerlo, necesitará algunos números y algunas estimaciones de casos de uso.
En lugares donde DEBE garantizar la integridad referencial y el cumplimiento de ACID, se requiere almacenar imágenes en la base de datos.
No puede garantizar transaccionalmente que la imagen y los metadatos sobre esa imagen almacenados en la base de datos hagan referencia al mismo archivo. En otras palabras, es imposible garantizar que el archivo en el sistema de archivos solo se altere al mismo tiempo y en la misma transacción que los metadatos.
Como otros han dicho, SQL 2008 viene con un tipo de Filestream que le permite almacenar un nombre de archivo o identificador como puntero en la base de datos y almacena automáticamente la imagen en su sistema de archivos, lo cual es un gran escenario.
Si está en una base de datos más antigua, entonces diría que si la está almacenando como datos de blob, entonces realmente no obtendrá nada de la base de datos en la forma de buscar características, por lo que probablemente sea mejor para almacenar una dirección en un sistema de archivos y almacenar la imagen de esa manera.
De esa manera, también ahorrará espacio en su sistema de archivos, ya que solo ahorrará la cantidad exacta de espacio, o incluso el espacio compactado en el sistema de archivos.
Además, puede decidir guardar con alguna estructura o elementos que le permitan navegar por las imágenes en bruto en su sistema de archivos sin ningún golpe de base de datos, o transferir los archivos a granel a otro sistema, disco duro, S3 u otro escenario, actualizando la ubicación en su programa, pero mantenga la estructura, de nuevo sin mucho éxito tratando de sacar las imágenes de su base de datos cuando intente aumentar el almacenamiento.
Probablemente, también le permitiría arrojar algún elemento de almacenamiento en caché, basado en URL de imágenes comúnmente golpeadas en su motor / programa web, por lo que también se está guardando allí.
Las imágenes estáticas pequeñas (no más de un par de megas) que no se editan con frecuencia, deben almacenarse en la base de datos. Este método tiene varios beneficios que incluyen una portabilidad más fácil (las imágenes se transfieren con la base de datos), una copia de seguridad / restauración más fácil (las imágenes se respaldan con la base de datos) y una mejor escalabilidad (una carpeta del sistema de archivos con miles de pequeños archivos en miniatura suena como una pesadilla de escalabilidad para yo).
Servir imágenes desde una base de datos es fácil, solo implemente un controlador http que sirva la matriz de bytes devuelta desde el servidor de DB como una secuencia binaria.
Aquí hay un libro blanco interesante sobre el tema.
Para BLOB o no BLOB: Almacenamiento de objetos grandes en una base de datos o un sistema de archivos
La respuesta es, depende." Ciertamente, dependería del servidor de base de datos y su enfoque para el almacenamiento de blobs. También depende del tipo de datos que se almacenan en blobs, así como de cómo se debe acceder a esos datos.
Los archivos de menor tamaño se pueden almacenar y entregar de manera eficiente utilizando la base de datos como mecanismo de almacenamiento. Los archivos más grandes probablemente se almacenarán mejor utilizando el sistema de archivos, especialmente si se modificarán / actualizarán con frecuencia. (la fragmentación de blob se convierte en un problema con respecto al rendimiento).
Aquí hay un punto adicional a tener en cuenta. Una de las razones que respaldan el uso de una base de datos para almacenar los blobs es el cumplimiento de ACID. Sin embargo, el enfoque que los probadores utilizaron en el documento técnico (opción de registro masivo de SQL Server), que duplicó el rendimiento de SQL Server, cambió efectivamente la 'D' en ACID a una 'd', ya que los datos de blob no se registraron con las escrituras iniciales para la transacción. Por lo tanto, si el cumplimiento total de ACID es un requisito importante para su sistema, reduzca a la mitad las cifras de rendimiento de SQL Server para las escrituras de la base de datos al comparar la E / S del archivo con la E / S del blob de la base de datos.
Una cosa que no he visto a nadie mencionar todavía, pero definitivamente vale la pena señalar, es que hay problemas asociados con el almacenamiento de grandes cantidades de imágenes en la mayoría de los sistemas de archivos también. Por ejemplo, si adopta el enfoque mencionado anteriormente y nombra cada archivo de imagen después de la clave principal, en la mayoría de los sistemas de archivos se encontrará con problemas si intenta colocar todas las imágenes en un directorio grande una vez que alcanza una gran cantidad de imágenes ( por ejemplo, en cientos de miles o millones).
Una solución común a esto es dividirlos en un árbol equilibrado de subdirectorios.
Algo que nadie ha mencionado es que el DB garantiza acciones atómicas, integridad transaccional y trata con la concurrencia. Incluso referencialmente, la integridad está fuera de la ventana con un sistema de archivos, entonces, ¿cómo sabes que los nombres de tus archivos siguen siendo correctos?
Si tiene sus imágenes en un sistema de archivos y alguien está leyendo el archivo mientras está escribiendo una nueva versión o incluso eliminando el archivo, ¿qué sucede?
Usamos blobs porque también son más fáciles de administrar (copia de seguridad, replicación, transferencia). Funcionan bien para nosotros.
El problema con el almacenamiento de solo rutas de archivo a imágenes en una base de datos es que ya no se puede forzar la integridad de la base de datos.
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 que se buscan y que se pueden gestionar más fácilmente (las imágenes no desaparecerán repentinamente) en una base de datos integrada en lugar de tener que interactuar con algún tipo de sistema de archivos (si se accede al sistema de archivos de forma independiente, las imágenes PODRÍAN "desaparecer" de repente), iría a almacenarlas directamente como un BLOB o similar.
En una empresa donde solía trabajar, almacenamos 155 millones de imágenes en una base de datos Oracle 8i (luego 9i). 7,5 TB por valor.
Normalmente, estoy totalmente en contra de tomar la parte más costosa y difícil de escalar de su infraestructura (la base de datos) y poner toda la carga en ella. Por otro lado: simplifica enormemente la estrategia de copia de seguridad, especialmente cuando tiene múltiples servidores web y necesita de alguna manera mantener los datos sincronizados.
Como la mayoría de las otras cosas, depende del tamaño esperado y el presupuesto.
Hemos implementado un sistema de imágenes de documentos que almacena todas sus imágenes en campos de blobs SQL2005. Hay varios cientos de GB en este momento y estamos viendo excelentes tiempos de respuesta y poca o ninguna degradación del rendimiento. Además, de conformidad con la normativa, tenemos una capa de middleware que archiva los documentos recién publicados en un sistema óptico de jukebox que los expone como un sistema de archivos NTFS estándar.
Estamos muy satisfechos con los resultados, particularmente con respecto a:
Supuesto: la aplicación está habilitada para web / basada en web
Me sorprende que nadie haya mencionado esto realmente ... delegarlo a otros especialistas -> usar un proveedor de alojamiento de imágenes / archivos de terceros .
Almacene sus archivos en un servicio de pago en línea como
Otros hilos de StackOverflow que hablan sobre esto aquí .
Este hilo explica por qué debería utilizar un proveedor de alojamiento de terceros.
Vale mucho la pena. Lo almacenan de manera eficiente. No se carga el ancho de banda de sus servidores a las solicitudes del cliente, etc.
Si no está en SQL Server 2008 y tiene algunas razones sólidas para colocar archivos de imagen específicos en la base de datos, entonces podría adoptar el enfoque "ambos" y usar el sistema de archivos como caché temporal y usar la base de datos como repositorio maestro .
Por ejemplo, su lógica de negocios puede verificar si existe un archivo de imagen en el disco antes de servirlo, recuperando de la base de datos cuando sea necesario. Esto le brinda la capacidad de múltiples servidores web y menos problemas de sincronización.
No estoy seguro de cuánto es un ejemplo del "mundo real", pero actualmente tengo una aplicación que almacena detalles para un juego de cartas coleccionables, incluidas las imágenes de las cartas. Por supuesto, el recuento de registros para la base de datos es solo de 2851 registros hasta la fecha, pero dado el hecho de que ciertas tarjetas se han lanzado varias veces y tienen ilustraciones alternativas, en realidad fue más eficiente en tamaño para escanear el "cuadrado primario" de la ilustración y luego dinámicamente generar el borde y los efectos varios para la tarjeta cuando se solicite.
El creador original de esta biblioteca de imágenes creó una clase de acceso a datos que representa la imagen en función de la solicitud, y lo hace bastante rápido para la visualización y la tarjeta individual.
Esto también facilita la implementación / actualizaciones cuando se lanzan nuevas tarjetas, en lugar de comprimir una carpeta completa de imágenes y enviarlas por el tubo y garantizar que se cree la estructura de carpetas adecuada, simplemente actualizo la base de datos y hago que el usuario la descargue nuevamente. Esto actualmente tiene un tamaño de hasta 56 MB, lo que no es genial, pero estoy trabajando en una función de actualización incremental para futuras versiones. Además, hay una versión de la aplicación "sin imágenes" que permite a los usuarios de acceso telefónico obtener la aplicación sin demora en la descarga.
Esta solución ha funcionado muy bien hasta la fecha, ya que la aplicación en sí está dirigida como una única instancia en el escritorio. Hay un sitio web donde todos estos datos se archivan para el acceso en línea, pero de ninguna manera usaría la misma solución para esto. Estoy de acuerdo en que el acceso al archivo sería preferible porque se adaptaría mejor a la frecuencia y el volumen de las solicitudes que se realizan para las imágenes.
Espero que esto no sea demasiado balbuceo, pero vi el tema y quise proporcionar algunas de mis ideas de una aplicación de pequeña / mediana escala relativamente exitosa.
SQL Server 2008 ofrece una solución que tiene lo mejor de ambos mundos: el tipo de datos de flujo de archivos .
Adminístrelo como una tabla normal y obtenga el rendimiento del sistema de archivos.
Depende de la cantidad de imágenes que vaya a almacenar y también de sus tamaños. He utilizado bases de datos para almacenar imágenes en el pasado y mi experiencia ha sido bastante buena.
OMI, los pros de usar la base de datos para almacenar imágenes son,
A. No necesita una estructura FS para mantener sus imágenes
B. Los índices de la base de datos funcionan mejor que los árboles FS cuando se almacena más cantidad de elementos
C. La base de datos ajustada de forma inteligente realiza un buen trabajo al almacenar en caché los resultados de la consulta
D. Las copias de seguridad son simples. También funciona bien si tiene configurada la replicación y el contenido se entrega desde un servidor cercano al usuario. En tales casos, no se requiere sincronización explícita.
Si sus imágenes van a ser pequeñas (digamos <64k) y el motor de almacenamiento de su base de datos admite BLOB en línea (en el registro), mejora aún más el rendimiento ya que no se requiere indirección (se logra la localidad de referencia).
Almacenar imágenes puede ser una mala idea cuando se trata de un pequeño número de imágenes de gran tamaño. Otro problema con el almacenamiento de imágenes en db es que, como la creación de metadatos, las fechas de modificación deben ser manejadas por su aplicación.
Recientemente he creado una aplicación PHP / MySQL que almacena archivos PDF / Word en una tabla MySQL (hasta ahora 40 MB por archivo).
Pros:
Contras:
Yo llamaría a mi implementación un éxito, se ocupa de los requisitos de respaldo y simplifica el diseño del proyecto. El rendimiento está bien para las 20-30 personas que usan la aplicación.
Según mi experiencia, tuve que gestionar ambas situaciones: imágenes almacenadas en la base de datos e imágenes en el sistema de archivos con la ruta almacenada en db.
La primera solución, las imágenes en la base de datos, es algo "más limpia", ya que su capa de acceso a datos tendrá que tratar solo con objetos de la base de datos; pero esto es bueno solo cuando tienes que lidiar con números bajos.
Obviamente, el rendimiento del acceso a la base de datos cuando se trata con objetos binarios grandes se degrada, y las dimensiones de la base de datos crecerán mucho, causando nuevamente una pérdida de rendimiento ... y normalmente el espacio de la base de datos es mucho más costoso que el espacio del sistema de archivos.
Por otro lado, tener grandes objetos binarios almacenados en el sistema de archivos hará que tenga planes de respaldo que tengan que considerar tanto la base de datos como el sistema de archivos, y esto puede ser un problema para algunos sistemas.
Otra razón para optar por el sistema de archivos es cuando tiene que compartir sus datos de imágenes (o sonidos, video, lo que sea) con acceso de terceros: en estos días estoy desarrollando una aplicación web que utiliza imágenes a las que se debe acceder desde "fuera "mi granja web de tal manera que el acceso a una base de datos para recuperar datos binarios es simplemente imposible. Entonces, a veces también hay consideraciones de diseño que lo llevarán a elegir.
Considere también, al hacer esta elección, si tiene que lidiar con el permiso y la autenticación al acceder a objetos binarios: estos requisitos normalmente se pueden resolver de una manera más fácil cuando los datos se almacenan en db.
Una vez trabajé en una aplicación de procesamiento de imágenes. Almacenamos las imágenes cargadas en un directorio que era algo así como / images / [fecha de hoy] / [número de identificación]. Pero también extrajimos los metadatos (datos exif) de las imágenes y los almacenamos en la base de datos, junto con una marca de tiempo y tal.
En un proyecto anterior almacené imágenes en el sistema de archivos, y eso causó muchos dolores de cabeza con las copias de seguridad, la replicación y la falta de sincronización del sistema de archivos con la base de datos.
En mi último proyecto, estoy almacenando imágenes en la base de datos y almacenando en caché en el sistema de archivos, y funciona muy bien. No he tenido problemas hasta ahora.
En segundo lugar, la recomendación sobre rutas de archivos. He trabajado en un par de proyectos que necesitaban administrar colecciones de activos de gran tamaño, y cualquier intento de almacenar cosas directamente en la base de datos resultó en dolor y frustración a largo plazo.
El único "profesional" real que se me ocurre al almacenarlos en la base de datos es el potencial para facilitar los activos de imágenes individuales. Si no hay rutas de archivo para usar, y todas las imágenes se transmiten directamente desde la base de datos, no hay peligro de que un usuario encuentre archivos a los que no debería tener acceso.
Sin embargo, parece que se resolvería mejor con un script intermediario que extraiga datos de un almacén de archivos inaccesible en la web. Por lo tanto, el almacenamiento de DB no es REALMENTE necesario.
La palabra en la calle es que, a menos que sea un proveedor de bases de datos que intente demostrar que su base de datos puede hacerlo (por ejemplo, digamos que Microsoft se jacta de que Terraserver almacena un millón de imágenes en SQL Server) no es una muy buena idea. Cuando la alternativa: almacenar imágenes en servidores de archivos y rutas en la base de datos es mucho más fácil, ¿por qué molestarse? Los campos de gotas son algo así como las capacidades todoterreno de los SUV: la mayoría de las personas no los usan, los que generalmente se meten en problemas y luego están aquellos que sí, pero solo por diversión.
Almacenar una imagen en la base de datos aún significa que los datos de la imagen terminan en algún lugar del sistema de archivos pero que están ocultos para que no pueda acceder a ellos directamente.
+ ves:
-ves:
Ambos métodos son comunes y practicados. Echa un vistazo a las ventajas y desventajas. De cualquier manera, tendrá que pensar en cómo superar las desventajas. Almacenar en la base de datos generalmente significa ajustar los parámetros de la base de datos e implementar algún tipo de almacenamiento en caché. El uso del sistema de archivos requiere que encuentre alguna forma de mantener sincronizados el sistema de archivos + la base de datos.