Almacenamiento de imágenes en DB - ¿Sí o no?

415

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?

James Hall
fuente
Bueno, puedes hacer ambas cosas con un caché de disco transaccional .
Lilith River

Respuestas:

350

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:

  • el almacenamiento de bases de datos suele ser más costoso que el almacenamiento del sistema de archivos
  • puede acelerar el acceso al sistema de archivos con productos estándar
    • por ejemplo, muchos servidores web utilizan la llamada al sistema sendfile () del sistema operativo para enviar un archivo de forma asíncrona 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 servidores web, etc., no necesitan codificación o procesamiento especial para acceder a las imágenes en el sistema de archivos
  • las bases de datos ganan donde la integridad transaccional entre la imagen y los metadatos es importante.
    • es más complejo administrar la integridad entre los metadatos db y los datos del sistema de archivos
    • es difícil (dentro del contexto de una aplicación web) garantizar que los datos se hayan vaciado al disco en el sistema de archivos
Mark Harrison
fuente
33
¿Qué productos estándar están disponibles para "acelerar" el sistema de archivos?
Andrei Rînea
22
Si bien solo administro 3 TB de archivos, definitivamente estoy de acuerdo. Las bases de datos son para datos estructurados, no para blobs.
derobert
77
@derobert: bastante, si nunca usará un elemento de datos en una consulta, como condición o para una unión, probablemente no pertenezca a la base de datos. Por otra parte, si tiene una buena función de base de datos para consultar imágenes en busca de semejanza ...
Nils Weinander
14
¿Qué productos estándar están disponibles para "acelerar" el sistema de archivos?
ablmf
55
Re: productos "súper acelerados": la mayoría de los servidores web ahora pueden aprovechar la llamada al sistema sendfile () para entregar archivos estáticos de forma asincrónica al cliente. Descarga al sistema operativo la tarea de mover el archivo del disco a la interfaz de red. El sistema operativo puede hacer esto de manera mucho más eficiente, operando en el espacio del kernel. Esto, para mí, parece una gran victoria para el sistema de archivos frente a db para almacenar / servir imágenes.
Alan Donnelly
140

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.

  • ¿Está almacenando imágenes que cambian dinámicamente, digamos facturas y quería obtener una factura como estaba el 1 de enero de 2007?
  • El gobierno quiere que mantengas 6 años de historia
  • Las imágenes almacenadas en la base de datos no requieren una estrategia de copia de seguridad diferente. Las imágenes almacenadas en el sistema de archivos hacen
  • Es más fácil controlar el acceso a las imágenes si están en una base de datos. Los administradores inactivos pueden acceder a cualquier carpeta en el disco. Se necesita un administrador realmente decidido para espiar en una base de datos para extraer las imágenes

Por otro lado, hay problemas asociados.

  • Requerir código adicional para extraer y transmitir las imágenes
  • La latencia puede ser más lenta que el acceso directo a archivos
  • Mayor carga en el servidor de la base de datos.
Rad
fuente
2
No tener una estrategia de copia de seguridad separada puede ser un gran problema cuando se escriben aplicaciones instaladas en las instalaciones (como SharePoint). Cuando crea una copia de seguridad de SharePoint, todo está en la base de datos, lo que lo hace muy fácil.
Eric Schoonover
44
¡La seguridad por oscuridad no es realmente una estrategia de control de acceso!
Jon Cage
55
No creo que esté abogando por la seguridad por la oscuridad: está diciendo que poner imágenes en el DB agrega otra capa de seguridad. (Creo que ... @ Conrad, no quiero poner palabras en tu boca)
AJ.
Elegí almacenar imágenes en la base de datos debido a la ventaja de una sola copia de seguridad (o, en términos más generales, tener todos los datos en un solo lugar), pero los problemas que mencionas también son ciertos, por lo que guardo en caché las imágenes en el sistema de archivos. Es lo mejor de ambos mundos, y me sorprende que ninguna de las principales respuestas aquí lo mencione.
Bart van Heukelom
¿Está, por casualidad, utilizando la biblioteca ImageResizing.Net para manejar su almacenamiento en caché de imagen de disco SQL->? Es el caché de disco más avanzado, escalable y robusto que puede obtener ...
Lilith River
56

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:

  1. Los blobs se almacenan realmente como archivos en una carpeta.
  2. Las burbujas se puede acceder usando ya sea una conexión de base o sobre el sistema de ficheros.
  3. Las copias de seguridad están integradas.
  4. La migración "simplemente funciona".

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.

John Gietzen
fuente
+1 para FileStream. En realidad, almacena los blobs como archivos en el disco, pero los gestiona transaccionalmente.
John Gietzen
Además, el servidor SQL permite que los blobs FileStream tengan acceso directamente fuera del disco, para que pueda evitar la conexión de la base de datos
John Gietzen
Aún así, se agregó latencia entre la base de datos y el servidor web ... Y el servidor web tendrá que cargarlo en la memoria para transmitirlo al cliente en lugar de poder transmitirlo desde el disco, a menos que esté usando el almacenamiento en caché del disco.
Lilith River
39

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.

Greg Hurlman
fuente
35

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.

Patrick McElhaney
fuente
Muy bueno de verdad. Sus usuarios ahora pueden incrementar fácilmente su nombre de archivo para acceder a otros archivos ...
Marijn Huizendveld
66
@ Marijn: Eso solo si expones las imágenes al mundo.
Seun Osewa el
Hicimos algo muy similar con nuestros documentos con imágenes (nuestra clave principal es una clave compuesta de tres elementos), pero agregamos la fecha y hora en que se escaneó el documento para que podamos tener varias versiones en el mismo directorio.
Andrew Neely
@Osewa, ¿cómo es eso? Sí, para acceder directamente al archivo, el usuario final necesitaría acceso a la carpeta. Podría tener un proceso para servir el archivo a través de FTP a pedido, y la seguridad estaría a la par con el servidor SQL.
Andrew Neely
31

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.

dicroce
fuente
66
No veo a nadie que afirme que un sistema de archivos es más rápido que un DB el 100% del tiempo (lea la respuesta de Mark Harrison). Eso es un poco un hombre de paja. Probablemente hay situaciones en las que es preferible no usar el cinturón de seguridad, pero en general , usar un cinturón de seguridad es una buena idea.
Calvin
30

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.

mluebke
fuente
77
En realidad, no, puedes. Siempre que los archivos de imagen nunca se eliminen, cambien o se sobrescriban una vez creados, todos los archivos de imagen se sincronizarán antes de intentar confirmar las transacciones, no hay corrupción del sistema de archivos, puede estar seguro de que los archivos de imagen y los metadatos están sincronizados. Para algunas aplicaciones, supongo que son demasiados ifs.
Seun Osewa
Yo iría aún más lejos y diría que con un sistema de archivos de Journaling y alguna lógica de programa adicional, se puede lograr el cumplimiento de ACID. Los pasos serían escribir el registro db, escribir el archivo. Si el archivo se compromete, confirme la transacción db.
Andrew Neely
28

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í.

crisol
fuente
27

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.

urini
fuente
Yo diría que la base de datos es mejor para los archivos que se editan con frecuencia, ya que la coherencia puede ser un problema en ese caso.
Seun Osewa
26

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.

usuario13550
fuente
25

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.

Juan
fuente
Se podría pensar que sí, pero los problemas son realmente menores; Tengo una aplicación con millones de archivos en un directorio, al que acceden cientos de usuarios, sin ningún problema. No es inteligente, pero funciona. El mayor problema es que si usa el Explorador para explorar el directorio, verá una linterna para siempre.
SqlACID
1
Es mejor usar un sistema de archivos que no tenga problemas con directorios grandes
Seun Osewa
8
Tenía una aplicación con millones de archivos en un directorio (servidor que ejecuta RHEL 4), incluso enumerar los contenidos del directorio (canalizar a un archivo) tomó días y creó un archivo de salida de 100 de MB de tamaño. Ahora están en una base de datos. Tengo un único archivo que puedo mover o respaldar con bastante facilidad.
Richard
1
@Seun Osewa: cada sistema de archivos tiene limitaciones ... y si conoce uno que no tenga problemas para almacenar millones de entradas en el mismo directorio, ¡hágamelo saber!
Guillaume el
1
@Seun Osewa: la base de datos es de hasta 28 GB ahora, con 5.4 M de registros. Terminé teniendo que particionar la tabla de la base de datos, así que tengo varios archivos para respaldar que tienen un tamaño aproximado de 5 GB. Ahora muevo las imágenes individuales a Amazon S3, así que solo tengo que almacenar el nombre de archivo en la base de datos (y Amazon puede hacer las copias de seguridad) )
Richard
22

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.

Draemon
fuente
¿Cuál es la probabilidad de tener dos actualizaciones simultáneas para una imagen en particular?
Arafangion
1
no necesita actualizaciones simultáneas para tener problemas, puede ser una lectura y una escritura. En nuestro caso, esto está casi garantizado.
Draemon el
20

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.

chico listo
fuente
17

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.

graham.reeds
fuente
55
Absolutamente. Aparentemente, la base de datos es mucho más grande ahora. Tener los datos en una base de datos significa que replicar la base de datos en diferentes sitios también es mucho más fácil.
graham.reeds
Vi una demostración de Oracle donde realmente podía montar un sistema de archivos en la base de datos, o algo así. ¿Sabes si esto es lo que hiciste? (Lo siento, no tengo ni idea con Oracle, así que tal vez estoy hablando basura)
Stu Thompson
No lo creo, estaba almacenando imágenes en la base de datos como una base de datos. La base de datos se ajustó agresivamente: recuerdo múltiples discusiones sobre el cambio de tamaño de las imágenes a medida que se agregaban y eliminaban campos. Todo estaba alineado con los límites.
graham.reeds
14

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.

Michael Stum
fuente
13

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:

  1. Facilidad de replicación y respaldo
  2. Capacidad para implementar fácilmente un sistema de control de versiones de documentos
dan90266
fuente
11

Si esta es una aplicación basada en la web, podría haber ventajas al almacenar las imágenes en una red de entrega de almacenamiento de terceros, como el S3 de Amazon o la plataforma Nirvanix.

David
fuente
11

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.

Pure.Krome
fuente
10

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.

a7drew
fuente
1 Esto también le permite almacenar la imagen original, entregando el / versión optimizada en caché permitiendo al mismo tiempo el tamaño / compresión que ser alterado después
Deebster
7

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.

Dillie-O
fuente
Cuando se trata de replicación, almacenar las imágenes en la base de datos es una OMI muy superior.
Beep beep
7

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.

Andrei Rînea
fuente
7

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.

nikhilbelsare
fuente
7

Recientemente he creado una aplicación PHP / MySQL que almacena archivos PDF / Word en una tabla MySQL (hasta ahora 40 MB por archivo).

Pros:

  • Los archivos cargados se replican en el servidor de respaldo junto con todo lo demás, no se necesita una estrategia de respaldo separada (tranquilidad).
  • Configurar el servidor web es un poco más simple porque no necesito tener una carpeta / uploads y decirle a todas mis aplicaciones dónde está.
  • Puedo usar transacciones para ediciones para mejorar la integridad de los datos: no tengo que preocuparme por los archivos huérfanos y faltantes

Contras:

  • mysqldump ahora lleva mucho tiempo porque hay 500 MB de datos de archivo en una de las tablas.
  • En general, no es muy eficiente en memoria / CPU en comparación con el sistema de archivos

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.

demasiado php
fuente
6

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.

ila
fuente
4

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.

Thomas Owens
fuente
4

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.

Christoffer Hammarström
fuente
3

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.

Jeff
fuente
3

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.

programador muerto
fuente
3

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:

  • integridad de la base de datos
  • es fácil de administrar ya que no tiene que preocuparse por mantener el sistema de archivos sincronizado cuando se agrega o elimina una imagen

-ves:

  • penalización de rendimiento: una búsqueda en la base de datos suele ser más lenta que una búsqueda en el sistema de archivos
  • no puede editar la imagen directamente (recortar, cambiar el tamaño)

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.

Salman A
fuente