asp.net - tradicionales - en qué se diferencia un archivo de una base de datos

Imágenes en la base de datos vs sistema de archivos (11)

Tenemos un proyecto por delante en el que construiremos todo un sistema CMS de fondo que alimentará toda nuestra extranet e intranet con un solo paquete. La pregunta a la que he estado tratando de encontrar es ¿cuál es mejor: almacenar imágenes en la base de datos (SQL Server 2005) para tener integridad, un único plan de replicación, etc. O para almacenar en el sistema de archivos?

Un problema que tenemos es que tenemos varios servidores de carga equilibrada que requieren tener los mismos datos en todo momento. A partir de ahora tenemos la replicación de 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 varias resoluciones de la misma imagen, no estamos seguros de si crear y almacenar cada versión en el sistema de archivos sería lo mejor o quizás extraer dinámicamente y crear la imagen de resolución que nos gustaría a petición.

Nuestras preocupaciones son las siguientes:

Integridad de los datos
Replicación de datos
Resoluciones múltiples
Velocidad de la base de datos contra el sistema de archivos
Carga máxima de la base de datos frente al sistema de archivos
Administración de datos y respaldo

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

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

Sin embargo, otros puntos:

Integridad - DB, por eso existen bases de datos frente a sistemas de archivos planos.
Replicación: no estoy seguro de si se refiere a la replicación de la imagen, pero si es así, obviamente DB, ya que no se cargará el equilibrio de esto, seguramente.
Se pueden realizar múltiples resoluciones a partir de la imagen de DB, sin embargo, esto agrega costos de procesamiento. Además, cuanto mayor sea la resolución, mayor será el tamaño, más tiempo esperará 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 en un archivo compartido, tendrá que esperar en la red en cualquier caso y la red es casi siempre el cuello de botella.
Gastos generales - Francamente, depende de su definición de sobrecarga y de cómo accede a las imágenes.
Management, DB, sin dudas. Almacenamiento singular = Una preocupación menor, y siempre debe ejecutar copias de seguridad en la base de datos en cualquier caso. Las copias de seguridad del sistema de archivos en varios servidores son costosas de muchas maneras.

En general, los datos de imágenes persistentes en la base de datos pueden no ser tan eficientes como el sistema de archivos, en lo que se refiere a un CMS. En un momento, probablemente solo desee mostrar la imagen estáticamente, otras veces 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 quiera trabajar con ella.

Algunos puntos por los que debe considerar el FileSystem

El navegador hace todo el trabajo, y usted se beneficia del almacenamiento en caché por proxy de las imágenes, etc.
Como una rama de lo anterior, puedes usar fácilmente las Redes de Entrega de Contenido (CDN)
La replicación de datos de imágenes es fácil con herramientas como rsync, etc.
El tiempo de procesamiento (es decir, la CPU) se optimiza drásticamente

Esta pregunta aparece con frecuencia: vea this resultado de búsqueda SO.

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 copias de seguridad de archivos y bases de datos. Esta es también la conclusión de este tipo , que maneja los TB de datos.

Existen preocupaciones válidas en cualquier lado del debate, por lo tanto, siempre dé sus requisitos. ¿Cuántos datos, cuántas imágenes, qué tamaño?

Almacenamiento en línea / BLOB

Upside : simplifica la arquitectura y la implementación, simplifica la copia de seguridad y la recuperación o migración del sistema; solo realice un volcado, copia de seguridad, exportación (cualquiera que sea el término para su sabor de DB) y muévalo a la nueva base de datos. El DB controla el control / la consistencia de la versión, por lo que permite la recuperación de un punto en el tiempo. El control de seguridad / acceso también es más limpio, ya que el acceso a una imagen BLOB es intrínseco para acceder a la fila general. Mover la imagen fuera de la base de datos y dejar que el servidor HTTP la recupere, aunque 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 les pertenecen. Si los aloja 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 bien su autenticación de servidor HTTP se debe integrar con la autenticación general del sistema, o su programa de servidor HTTP que sirve 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 preocupante en sistemas de un solo inquilino de propósito único, con autenticación simple.

A la baja : para bases de datos REALMENTE GRANDES, la copia de seguridad y la recuperación se vuelven frustrantes, o incluso problemáticas y costosas, porque si tiene un pequeño conjunto de datos básicos, puede tener muchos GB o TB de datos de imágenes. Tratarlo como una base de datos consistente es bueno desde el punto de vista de la integridad, pero malo para las copias de seguridad a menos que use DBMS con calidad empresarial, copia de seguridad y recuperación del almacenamiento de datos (por ejemplo, Oracle RMAN y copias de seguridad continuas).

Siempre considere el tiempo de recuperación en cualquier sistema. Si sus requisitos de almacenamiento son <unos pocos gigabytes, digamos 50-100GB pares, y tiene un montón de espacio de copia de seguridad planificado, el almacenamiento en línea es más limpio. Por encima de eso, la separación de 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 por el bien de un pequeño error de datos. El tiempo de recuperación sería mi mayor preocupación.

Gracias por toda la entrada rápida, solo tenemos aproximadamente 5-10 GB de imágenes a partir de ahora y mucho de eso es porque tenemos múltiples resoluciones de la misma imagen.

Otra preocupación que se ha planteado es ¿qué pasaría si quisiéramos ampliar para guardar documentos, presentaciones y videos imortantes? ¿Apoyaría el método de la base de datos permitiéndonos almacenar videos en el databse y seguir transmitiéndolos en flash?

Gracias de nuevo por toda la información!

Hubo un buen artículo de investigación publicado por Microsoft Research llamado To Blob o no para Blob, donde observaron todo tipo de variables e impactos.

Su hallazgo al final:

hasta 256 KB de tamaño, los blobs se almacenan en la base de datos de manera más eficiente que en el sistema de archivos
para 1 MB o más, 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 almacenar cosas en el sistema de archivos, pero bajo control transaccional, sea una realidad. ¡Muy recomendado que lo revises!

La replicación de archivos estáticos, especialmente en una serie de servidores, puede ser difícil de gestionar. Realmente se reduce a una solución de compromiso entre la administración, la supervisión y la depuración de problemas de replicación frente al tamaño y la carga de la base de datos.

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

Las sugerencias para almacenar una ruta en el archivo db carecen del problema real, que se está replicando en varias máquinas.

Me gustaría;

1) Asignar identificador único (GUID) a cada imagen 2) Etiquetar / nombrar la imagen con ese GUID 3) Almacenar GUID en el sistema operativo (Sistema de archivos) 4) Almacenar 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 crear una verificación de integridad de back-end mediante activadores y algunos procedimientos almacenados.

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

No me gustaría que los servidores SQL Data Cache estén llenos de imágenes simples para el sitio web. Quiero que el caché de datos realmente tenga datos en él. Además, si tiene una arquitectura de varios niveles, es mucho más fácil pasar una URL para una imagen que una burbuja de datos binarios. Sin embargo, se encuentra con problemas si solo quiere que ciertas personas vean las imágenes (seguridad).

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

Desventajas del sistema de archivos

-No se replica automáticamente

-Puede complicar su replicación al tener diferentes ubicaciones físicas para cada instancia

-Slow con un gran número de archivos

Al costado del sistema de archivos

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

Sus preocupaciones se dividen en dos campos. Las siguientes preocupaciones favorecen el almacenamiento de documentos en la base de datos:

Integridad de los datos
Replicación de datos
Resoluciones múltiples
Administración de datos y respaldo

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

Velocidad de la base de datos contra el sistema de archivos
Carga máxima de la base de datos frente al sistema de archivos

Por lo tanto, decida qué es lo más importante y elija en consecuencia.