Estructura de tabla de SQL Server para almacenar una gran cantidad de imágenes

Question

¿Cuál es la mejor práctica para almacenar una gran cantidad de datos de imagen en SQL Server 2008? Espero almacenar alrededor de 50,000 imágenes usando aproximadamente 5 gigas de espacio de almacenamiento. Actualmente estoy haciendo esto usando una sola tabla con las columnas:

ID: int/PK/identity
Picture: Image
Thumbnail: Image
UploadDate: DateTime

Me preocupa porque alrededor del 10% de mi capacidad total esperada parece que las inserciones están tardando mucho. Una imagen típica es alrededor de 20k - 30k. ¿Existe una mejor estructura lógica para almacenar estos datos? ¿O necesito analizar clustering o alguna otra solución de TI para acomodar la carga de datos?

Answer 1

Image es un tipo de datos obsoleto en SQL Server 2008. Se ha reemplazado con VARBINARY (MAX) desde SQL Server 2005. Si decide almacenar la imagen en DB, entonces debe usar los campos VARBINARY (MAX) y considerar agregar la opción FILESTREAM .

Para la transmisión de datos, como imágenes, FILESTREAM es mucho más rápido que VARBINARY (MAX) , según este documento técnico :

_{(fuente: microsoft.com )}

Tenga en cuenta que para lograr este rendimiento de transmisión debe usar la API adecuada en su diseño y obtener el Identificador Win32 del BLOB . Tenga en cuenta que las actualizaciones en una columna FILESTREAM (incluyendo INSERTS ) serán más lentas que VARBINARY (MAX) .

Answer 2

Para DB o no para DB, esa es la pregunta.

Estás comenzando una guerra religiosa aquí con imágenes en DB.

La opinión se dividiría para SQL 2000, pero 2005 y superiores hacen un trabajo bastante decente al almacenar blobs: solo mire la cantidad de instalaciones de SharePoint que usan MS SQL Server como su almacenamiento. Solo seguiría esta ruta para el almacenamiento de imágenes menores.

Si terminas poniéndolos en la base de datos, diría que debes separar la imagen de los datos asociados para facilitar la consulta y reducir tu IO y las instancias cuando los desarrolladores escriben SELECT * (y sí, lo harán).

Eche un vistazo a FILESTREAM en SQL 2008: está destinado a cosas como esta.

Aquí hay algunos otros puntos sobre DB vs. Sistema de archivos que puede considerar:

• El almacenamiento de bases de datos, las copias de seguridad, la restauración y las licencias de mantenimiento son caras
• El almacenamiento en la base de datos es difícil de obtener que en el disco
• El disco se puede acelerar
• Necesitará escribir código para obtener / configurar imágenes en DB - no es necesario para el disco

Answer 3

Consulte las nuevas funciones Filestream en SQL Server 2008. Esencialmente, le permite almacenar datos de blob (lectura: imagen) en la base de datos, sin la sobrecarga de tener que leer los datos en buffers sql en cada lectura y escritura. Utiliza sin problemas el sistema de archivos para almacenar sus archivos grandes en lugar de páginas sql. Esto puede conducir a tiempos de lectura y escritura mucho más rápidos para archivos más grandes y, lo mejor de todo, dado que todo esto sucede de manera oculta, no necesita cambiar ningún proceso almacenado existente para trabajar con columnas de flujo de archivos. Consulte aquí para obtener ejemplos de código y algunos perfiles de rendimiento.