Almacenamiento de imágenes en una base de datos

Question

posible duplicado:
Storing Images in DB - Yea or Nay?

Para las edades me han dicho no almacenar las imágenes en la base de datos, o cualquier mancha grande para el caso. Si bien puedo entender por qué las bases de datos no son/no fueron eficientes para eso, nunca entendí por qué no podían hacerlo. Si puedo poner un archivo en algún lugar y hacer referencia a él, ¿por qué el motor de la base de datos no podría hacer lo mismo? Me alegra que Damien Katz lo haya mencionado en un reciente podcast de Stack Overflow y Joel Spolsky y Jeff Atwood, al menos en silencio, estuvieron de acuerdo.

He estado leyendo sugerencias de que Microsoft SQL Server 2008 debería ser capaz de manejar BLOB eficientemente, ¿es cierto? Si es así, ¿qué es lo que nos impide almacenar imágenes allí y deshacernos de un problema? Una cosa que puedo pensar es que mientras la imagen puede ser servida por un servidor web estático muy rápidamente si es un archivo en alguna parte, cuando está en la base de datos tiene que viajar de la base de datos a la aplicación del servidor web (que puede ser más lenta que el servidor web estático) y luego se sirve. ¿No debería el almacenamiento en caché ayudar a resolver ese último problema?

Answer 1

Sí, es cierto, SQL Server 2008 acaba de implementar una característica como la que usted menciona, se llama una extensión de archivos. Y es un buen argumento para almacenar blobs en un DB, si está seguro de que solo querrá usar SQL Server para su aplicación (o está dispuesto a pagar el precio en rendimiento o en desarrollar una capa similar sobre la nueva). Servidor de base de datos). Aunque espero capas similares comenzarán a aparecer si aún no existen para diferentes servidores de bases de datos.

Como siempre, ¿cuáles serían los verdaderos beneficios dependiendo del escenario en particular? Si va a servir muchos archivos grandes relativamente estáticos, entonces este escenario más el almacenamiento en caché probablemente será la mejor opción teniendo en cuenta un combo de rendimiento/capacidad de administración.

This white paper describe la característica FILESTREAM de SQL Server 2008, que permite el almacenamiento y el acceso eficiente a datos BLOB utilizando una combinación de SQL Server 2008 y el sistema de archivos NTFS. Cubre las opciones de almacenamiento BLOB, la configuración de Windows y SQL Server para usar datos de FILESTREAM, las consideraciones para combinar FILESTREAM con otras características y los detalles de implementación, como la creación de particiones y el rendimiento.

Answer 2

Existen opciones dentro de SQL Server para administrar dónde almacena grandes cantidades de datos, estos han estado allí desde el momento de la concesión SQL2005, por lo que no sé por qué no pudo almacenar grandes BLOB de datos. MOSS, por ejemplo, almacena todos los documentos que carga en una base de datos SQL.

Por supuesto, hay algunas implicaciones de rendimiento, como con casi cualquier cosa, por lo que debe tener cuidado de no recuperar el blob si no lo necesita, y no lo incluya en índices, etc.

Answer 3

El hecho de que pueda hacer algo no significa que deba hacerlo.

Si le preocupa la eficiencia, lo más probable es que no desee hacer esto para cualquier archivo de gran escala que se sirva.

También parece que este tema ha sido muy discutido ...

• duplicado exacto: User Images: Database or filesystem storage?
• duplicado exacto: Storing images in database: Yea or nay?
• duplicado exacto: Should I store my images in the database or folders?
• duplicado exacto: Would you store binary data in database or folders?
• duplicado exacto: Store pictures as files or or the database for a web app?
• duplicado exacto: Storing a small number of images: blob or fs?
• duplicado exacto : store image in filesystem or database?

Answer 4

Una de las razones clásicos para precaución sobre el almacenamiento de manchas en bases de datos es que los datos serán almacenados y editados (cambiado) bajo control de transacciones, que significa que el DBMS necesita para asegurarse de que puede deshacer los cambios, y recuperar los cambios después de un bloqueo. Esto normalmente se realiza mediante alguna variación en el tema de un registro de transacciones. Si el DBMS debe registrar el cambio en un blob de 2 GB, entonces debe tener una forma de identificar qué ha cambiado. Esto podría ser simple (la imagen anterior y la imagen posterior) o más sofisticada (algún tipo de operación delta binaria) que es más costosa desde el punto de vista computacional. Aun así, a veces el resultado neto será gigabytes de datos que se almacenarán a través de los registros. Esto perjudica el rendimiento del sistema. Hay varias formas de limitar el impacto de los cambios, lo que reduce la cantidad de datos que fluyen a través de los registros, pero hay compensaciones.

La penalidad para almacenar nombres de archivos en la base de datos es que el DBMS no tiene control (en general) sobre cuándo cambian los archivos, y de nuevo, la reproducibilidad de los datos está comprometida; no puede garantizar que algo fuera del SGBD no haya cambiado los datos. (Hay una versión muy general de ese argumento: no se puede estar seguro de que alguien no haya manipulado los archivos de almacenamiento de la base de datos en general. Pero me refiero a almacenar un nombre de archivo en la base de datos haciendo referencia a un archivo no controlado por el DBMS. Los archivos controlados por el DBMS están protegidos contra cambios accidentales por parte de los no privilegiados.)

La nueva funcionalidad de SQL Server parece interesante. No he explorado lo que hace, por lo que no puedo comentar en qué medida evita o limita los problemas mencionados anteriormente.

Answer 5

Trataré de descomponer su pregunta y abordar sus diversas partes lo mejor que pueda.

• SQL Server 2008 y el Tipo Filestream - La respuesta de Vinko arriba es el mejor que he visto hasta ahora. El tipo de Filestream es el SQL Server 2008 es lo que estabas buscando. Filestream está en la versión 1, por lo que todavía hay algunas razones por las que no recomendaría su uso si es para una aplicación empresarial. Como ejemplo, mi recuerdo es que no se puede dividir el almacenamiento de los archivos físicos subyacentes en varias rutas de Windows UNC. Tarde o temprano se convertirá en una restricción bastante seria para una aplicación empresarial.

• Almacenar archivos en la base de datos - En el esquema más grandioso, la dirección original de Damien Katz era correcta. La mayoría de los reproductores de gestión de contenido empresarial (ECM) almacenan archivos en el sistema de archivos y los metadatos en el RDBMS. Si va aún más grande y mira el servicio S3 de Amazon, está buscando archivos físicos con un back-end de base de datos no relacional. A menos que estés midiendo tus archivos en almacenamiento por miles de millones, no recomendaría ir por esta ruta y hacer la tuya.

• Un poco más detalles sobre los archivos en la base de datos - A primera vista, muchas cosas hablan de los archivos en la base de datos. Una es la simplicidad, dos es la integridad transaccional. Dado que el sistema de archivos de Windows no puede enlistarse en una transacción, escribe que debe ocurrir en toda la base de datos y el sistema de archivos debe tener una lógica de compensación de transacciones incorporada. Realmente no vi el otro lado de la historia hasta que hablé con los DBA. Por lo general, no les gusta mezclar datos comerciales y blobs (la copia de seguridad se vuelve dolorosa), a menos que tenga una base de datos separada dedicada al almacenamiento de archivos, esta opción generalmente no es tan atractiva para los DBA. Tiene razón en que la base de datos será más rápida, en igualdad de condiciones. Sin conocer el caso de uso de su aplicación, no puedo decir mucho sobre la opción de almacenamiento en caché. Baste decir que en muchas aplicaciones empresariales, la tasa de aciertos de la caché en los documentos es demasiado baja para justificar el almacenamiento en caché.

Espero que esto ayude.