Imágenes en la database vs sistema de files

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

Un problema que tenemos es que tenemos varios serveres 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 files parece ser un poco más difícil. Otra preocupación que tenemos es que nos gustaría tener varias resoluciones de la misma image, no estamos seguros de si crear y almacenar cada versión en el sistema de files sería lo mejor o quizás extraer dinámicamente y crear la image 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 database contra el sistema de files
  • Carga máxima de la database frente al sistema de files
  • 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!

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 database de manera más eficiente que en el sistema de files
  • para 1 MB o más, el sistema de files 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 files, pero bajo control transaccional, sea una realidad. ¡Muy recomendado que lo revises!

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

No hay una respuesta correcta, depende de las circunstancias.

Personalmente, mantenga una ruta de file en el DB y el file en el sistema de files. Cada uno tiene sus propias fortalezas. Puede hacer copys de security de files y bases de datos. Esta es también la conclusión de este tipo , que maneja los TB de datos.

La replicación de files estáticos, especialmente en una serie de serveres, puede ser difícil de gestionar. Realmente se networkinguce a una solución de compromiso entre la administración, la supervisión y la debugging de problemas de replicación frente al tamaño y la carga de la database.

Creo que probablemente elegiría el enfoque de la database, y si la carga se convertía en un problema, mira cómo colocar algún tipo de capa de caching alnetworkingedor de las llamadas de image.

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

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 filesystems planos.

  • Replicación: no estoy seguro si se refiere a la replicación de la image, 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 image de DB, sin embargo, esto agrega costos de procesamiento. Además, cuanto mayor sea la resolución, mayor será el tamaño, más time esperará la networking. 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 file compartido, tendrá que esperar en la networking en cualquier caso y la networking 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 copys de security en la database en cualquier caso. Las copys de security del sistema de files en varios serveres son costosas de muchas maneras.

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

  • 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 files:

  • Velocidad de la database contra el sistema de files
  • Carga máxima de la database frente al sistema de files

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

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 architecture y la implementación, simplifica la copy de security y la recuperación o migration del sistema; solo realice un volcado, copy de security, export (cualquiera que sea el término para su sabor de DB) y muévalo a la nueva database. El DB controla el control / la consistencia de la versión, por lo que permite la recuperación de un punto en el time. El control de security / acceso también es más limpio, ya que el acceso a una image BLOB es intrínseco para acceder a la fila general. Mover la image fuera de la database y dejar que el server HTTP la recupere, aunque sea mejor para la concurrency 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 security cubra el control de acceso de las imágenes entre los usuarios. O bien su authentication de server HTTP se debe integrar con la authentication general del sistema, o su progtwig de server HTTP que sirve las imágenes utiliza algún tipo de mecanismo de session para garantizar que la request 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 authentication simple.

A la baja : para bases de datos REALMENTE GRANDES, la copy de security y la recuperación se vuelven frustrantes, o incluso problemáticas y costosas, porque si tiene un pequeño set de datos básicos, puede tener muchos GB o TB de datos de imágenes. Tratarlo todo como una database consistente es bueno desde el punto de vista de la integridad, pero malo para las copys de security a less que use DBMSes con calidad empresarial, copy de security y recuperación ajustadas del depósito de datos (por ejemplo, Oracle RMAN y copys de security continuas).

Siempre considere el time 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 copy de security 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 files haga su trabajo se convierte en una ventaja key. Nada es peor que tratar de restaurar, recuperar y abrir una gran database por el bien de un pequeño error de datos. El time de recuperación sería mi mayor preocupación.

En general, los datos de imágenes persistentes en la database pueden no ser tan eficientes como el sistema de files, en lo que se refiere a un CMS. En un momento, probablemente solo desee mostrar la image estáticamente, otras veces desea que esa image esté disponible para sus diseñadores charts para actualizaciones, etc.

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

Algunos puntos por los que debe considerar el FileSystem

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

Suponiendo que se encuentra en un entorno de Windows, no hay una buena razón para usar el sistema de files. 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 performance, no es un gran problema.

Desventajas del sistema de files

-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 files

Al costado del sistema de files

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

Me gustaría;

1) Asignar identificador único (GUID) a cada image 2) Etiquetar / nombrar la image con ese GUID 3) Almacenar GUID en el sistema operativo (Sistema de files) 4) Almacenar el puntero de Nombre de file totalmente calificado (FQN) en la database.

Almacenar imágenes en la database 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 database por una razón (mi respuesta proviene del server sql):

No me gustaría que los serveres SQL Data Cache estén llenos de imágenes simples para el website. Quiero que el caching de datos realmente tenga datos en él. Además, si tiene una architecture de varios niveles, es mucho más fácil pasar una URL para una image que una burbuja de datos binarys. Sin embargo, se encuentra con problemas si solo quiere que ciertas personas vean las imágenes (security).

Gracias por toda la input 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 image.

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

Gracias de nuevo por toda la información!