Imágenes en el sistema de archivos de base de datos versus

Question

Tenemos un proyecto que surge donde construiremos un sistema CMS de backend completo que alimentará toda nuestra Extranet e Intranet con un solo paquete. La pregunta a la que he estado tratando de encontrar una respuesta es que sea mejor: almacenar imágenes en la base de datos (SQL Server 2005) para que tengamos integridad, un plan de replicación único, etc. o almacenamiento en el sistema de archivos.

Un problema que tenemos es que tenemos múltiples servidores de carga equilibrada que requieren tener los mismos datos en todo momento. A partir de ahora tenemos la replicación SQL que se encarga de eso, pero la replicación de archivos parece ser un poco más difícil. Otra preocupación que tenemos es que nos gustaría tener múltiples resoluciones de la misma imagen, no estamos seguros de si crear y almacenar cada versión en el sistema de archivos sería mejor o tal vez extrayendo y creando dinámicamente la imagen de resolución que nos gustaría a pedido.

Nuestras preocupaciones son las siguientes:

• Integridad de los datos
• Replicación de datos
• Múltiples resoluciones
• Velocidad de la base de datos versus sistema de archivos
• Sobrecarga del sistema de archivos de base de datos versus
• Gestión de datos y copia de seguridad

¿Alguien tiene una situación similar o tiene alguna información sobre lo que se recomendaría? ¡Gracias de antemano por la ayuda!

Answer 1

Hubo un buen trabajo de investigación publicado por Microsoft Research llamado A Blob o no a Blob donde miraron todo tipo de variables e impactos.

Su hallazgo al final:

• Hasta 256 kb de tamaño, las blobs se almacenan en la base de datos de manera más eficiente que en el sistema de archivos
• Para 1 MB y más grande, el sistema de archivos es más eficiente
• En el medio es un lanzamiento

Desde que se publicó ese documento, SQL Server 2008 también ha agregado el atributo FileStream que hace que el almacenamiento de cosas en el sistema de archivos, pero bajo control transaccional, sea una realidad. ¡Muy recomendable que lo revises!

Answer 2

Esta pregunta aparece a menudo - ver este Entonces el resultado de la búsqueda.

No hay una respuesta correcta, depende de las circunstancias.

Personalmente: mantenga una ruta de archivo en el DB y el archivo en el sistema de archivos. Cada uno tiene sus propias fortalezas. Puede hacer una copia de seguridad de archivos y bases de datos. Esta es también la conclusión de este chico, que administra TBS de datos.

Answer 3

La replicación de archivos estáticos, especialmente en varios servidores, puede ser difícil de administrar. Realmente se reduce a una compensación entre los problemas de replicación de gestión, monitoreo y depuración frente al tamaño y carga de la base de datos.

Creo que probablemente elegiría el enfoque de la base de datos, y si la carga se convirtió en un problema, busque colocar algún tipo de capa de caché alrededor de las llamadas de imagen.

Las sugerencias para almacenar una ruta en el DB están perdiendo el problema real, que está replicando esto en múltiples máquinas.

Answer 4

Tus preocupaciones se dividen en dos campamentos. Las siguientes preocupaciones favorecen los documentos de almacenamiento en la base de datos:

• Integridad de los datos
• Replicación de datos
• Múltiples resoluciones
• Gestión de datos y copia de seguridad

Estas preocupaciones (probablemente) favorecen los documentos de almacenamiento en el sistema de archivos:

• Velocidad de la base de datos versus sistema de archivos
• Sobrecarga del sistema de archivos de base de datos versus

Entonces, decida lo que más importa y elija en consecuencia.

Answer 5

Bueno, si sus dos necesidades principales son la integridad y la replicación, entonces la respuesta es definitivamente DB.

Sin embargo, ustedes otros puntos:

• Integridad: DB, es por eso que existen bases de datos frente a sistemas de archivos planos.

• Replicación: no estoy seguro de si se refiere a la replicación de imágenes, pero si es así, obviamente DB, ya que no lo puede equilibrar con esto, seguramente.

• Se pueden realizar múltiples resoluciones a partir de la imagen DB, sin embargo, esto agrega costos de procesamiento. Además, cuanto mayor sea la resolución, mayor es el tamaño, más larga espera la red. Múltiples resoluciones intercambian espacio por velocidad.

• Velocidad: dependiendo del acceso a las imágenes, podría ser insignificante. Si está tomando imágenes a través de un archivo compartido, tendrá que esperar en la red en cualquier caso y la red es casi siempre el cuello de botella.

• Overhead: francamente, depende de su definición de sobrecarga y de cómo acceda a las imágenes.

• Gestión, DB, sin duda. Almacenamiento singular = una preocupación menos, y siempre debe ejecutar copias de seguridad en la base de datos en cualquier caso. Las copias de seguridad del sistema de archivos en múltiples servidores son costosas de muchas maneras.

Answer 6

Hay preocupaciones válidas a ambos lados del debate, así que siempre otorgue sus requisitos. ¿Cuántos datos, cuántas imágenes, qué tan grandes?

Almacenamiento en línea / blob

Al revés: simplifica la arquitectura y la implementación, simplifica la copia de seguridad y la recuperación o migración del sistema; Simplemente haga un volcado, copia de seguridad, exporte (sea cual sea el término para su sabor de DB) y muévalo a la nueva base de datos. El control / consistencia de la versión es manejado por el DB, por lo que permite la recuperación de punto en el tiempo. El control de seguridad / acceso también es más limpio, ya que el acceso a un blob de imagen es intrínseco para acceder a la fila general. Mover la imagen fuera del DB y dejar que el servidor HTTP la obtenga, mientras que sea mejor para la concurrencia y la escalabilidad, puede tener problemas para garantizar que las personas no puedan piratear las URL y solicitar imágenes que no posean. Si los alberga fuera del DB, asegúrese de que su política de seguridad cubra el control de acceso de las imágenes entre los usuarios. O la autenticación de su servidor HTTP tiene que integrarse con la autenticación general del sistema, o su programa de servidor HTTP que sirve a las imágenes utiliza algún tipo de mecanismo de sesión para garantizar que la solicitud HTTP sea válida. Esta es una gran preocupación en las bases de datos de múltiples inquilinos. Menos preocupaciones en sistemas de un solo propósito, con una sola autenticación.

Abajo: Para bases de datos realmente realmente grandes, la copia de seguridad y la recuperación se vuelven frustrantes, o incluso problemáticas y costosas, porque donde puede tener un conjunto de datos de núcleo pequeño de lo contrario, puede tener muchos datos de imágenes GB o TB. Tratarlo todo como una base de datos consistente es bueno desde el punto de vista de integridad, pero es malo para las copias de seguridad a menos que use DBMSE con calidad empresarial, copia de seguridad y recuperación sintonizada de almacén de datos (el ejemplo es Oracle RMAN y copias de seguridad rodantes).

Siempre considere el tiempo para recuperarse en cualquier sistema. Si sus requisitos de almacenamiento son <algunos gigabytes, digamos 50-100GB incluso, y tiene mucho espacio de respaldo planeado, el almacenamiento en línea es más limpio. Por encima de eso, la separación de las preocupaciones y dejar que el sistema de archivos haga su trabajo se convierte en una ventaja clave. Nada es peor que tratar de restaurar, recuperar y abrir una gran base de datos en aras de un pequeño error de datos. El tiempo de recuperación sería mi mayor preocupación.

Answer 7

En general, los datos de imagen persistentes en el DB podrían no ser tan eficientes como el sistema de archivos, en lo que respecta a un CMS. En un momento probablemente solo desee mostrar la imagen estáticamente, en otras ocasiones desea que esa imagen esté disponible para sus diseñadores gráficos para actualizaciones, etc.

Considere la sobrecarga de procesamiento asociada con la recuperación de la imagen cada vez que desee trabajar con ella.

Algunos puntos por qué debe considerar el sistema de archivos

1. El navegador hace todo el trabajo, y se beneficia del almacenamiento en caché de imágenes, etc.
2. Como una rama de lo anterior, puede usar fácilmente las redes de entrega de contenido (CDN)
3. La replicación de los datos de la imagen es fácil con herramientas como RSYNC, etc.
4. El tiempo de procesamiento (es decir, CPU) se optimiza drásticamente

Answer 8

Suponiendo que se encuentre en un entorno de Windows, no hay una gran razón para usar el sistema de archivos. Es posible que desee tener cuidado de cómo almacena las imágenes en las tablas para evitar divisiones de páginas no deseadas, pero ese es un ajuste de rendimiento, no un gran problema.

Desventaja al sistema de archivos

-NO no se replica automáticamente

-Asugo complicar su replicación teniendo diferentes ubicaciones físicas para cada caso

-Low con números muy grandes de archivos

Upside al sistema de archivos

-Si almacena algunos archivos muy grandes, funcionará un poco mejor.

Answer 9

Me gustaría;

1) Asigne un identificador único (GUID) a cada imagen 2) Etiqueta/nombre la imagen con ese GUID 3) Almacene GUID en el sistema operativo (sistema de archivos) 4) Almacene el puntero de nombre de archivo totalmente calificado (FQN) en la base de datos.

Almacenar imágenes en la base de datos es demasiado costoso en términos de almacenamiento y mantenimiento. Almacenar solo el puntero FQN proporcionaría una mejor solución. También puede construir una verificación de integridad de back-end a través de desencadenantes y algunos procedimientos almacenados.

Answer 10

No almacenaría imágenes en la base de datos por una razón (mi respuesta proviene del servidor SQL):

No quisiera que los servidores SQL se encuentren en caché de datos poblados por imágenes simples para el sitio web. Quiero que el caché de datos tenga datos en él. Además, si tiene una arquitectura de múltiples niveles, es mucho más fácil pasar una URL por una imagen que una gota de datos binarios. Sin embargo, se encuentra con problemas si solo desea que ciertas personas vean las imágenes (seguridad).