sql-server - tipo - sql varbinary image
Usando SQL Server como Image store (6)
¿Es SQL Server 2008 una buena opción para usar como una tienda de imágenes para un sitio web de comercio electrónico? Se usaría para almacenar imágenes de productos de varios tamaños y ángulos. Un servidor web generaría esas imágenes, leyendo la tabla mediante una ID agrupada. El tamaño total de la imagen sería de alrededor de 10 GB, pero deberá escalar. Veo muchos beneficios sobre el uso del sistema de archivos, pero me preocupa que el servidor SQL, al no tener una búsqueda O (1), no sea la mejor solución, dado que el sitio tiene mucho tráfico. ¿Sería eso incluso un cuello de botella? ¿Cuáles son algunos pensamientos, o tal vez otras opciones?
10 Gb no es una gran cantidad de datos, por lo que probablemente pueda usar la base de datos para almacenarla y no tenga grandes problemas, pero por supuesto es mejor usar el sistema de archivos y, en cuanto a la administración de seguridad, es mejor usar la base de datos. (copias de seguridad y consistencia).
Afortunadamente, Sql Server 2008 le permite tener su pastel y comerlo también, con:
En SQL Server 2008, puede aplicar el atributo FILESTREAM a una columna varbinary, y SQL Server luego almacena los datos para esa columna en el sistema local de archivos NTFS. Almacenar los datos en el sistema de archivos trae dos beneficios clave:
- El rendimiento coincide con el rendimiento de transmisión del sistema de archivos.
- El tamaño de BLOB está limitado solo por el tamaño del volumen del sistema de archivos.
Sin embargo, la columna puede administrarse como cualquier otra columna BLOB en SQL Server, para que los administradores puedan usar las capacidades de administración y seguridad de SQL Server para integrar la administración de datos BLOB con el resto de los datos en la base de datos relacional, sin necesidad de administrar el archivo de datos del sistema por separado.
Definir los datos como una columna FILESTREAM en SQL Server también garantiza la coherencia del nivel de datos entre los datos relacionales en la base de datos y los datos no estructurados que se almacenan físicamente en el sistema de archivos. Una columna FILESTREAM se comporta exactamente igual que una columna BLOB, lo que significa integración completa de las operaciones de mantenimiento como copia de seguridad y restauración, integración completa con el modelo de seguridad de SQL Server y compatibilidad total con las transacciones.
Los desarrolladores de aplicaciones pueden trabajar con datos de FILESTREAM a través de uno de dos modelos de programación; pueden usar Transact-SQL para acceder y manipular los datos al igual que las columnas estándar BLOB, o pueden usar las API de transmisión de Win32 con semántica transaccional de Transact-SQL para garantizar la coherencia, lo que significa que pueden usar llamadas de lectura / escritura estándar de Win32 a FILESTREAM BLOB como lo harían si interactúan con archivos en el sistema de archivos.
En SQL Server 2008, las columnas de FILESTREAM solo pueden almacenar datos en volúmenes de discos locales, y algunas características como el cifrado transparente y los parámetros con valores de tabla no son compatibles con las columnas de FILESTREAM. Además, no puede usar tablas que contengan columnas FILESTREAM en instantáneas de bases de datos o sesiones de creación de reflejo de bases de datos, aunque sí se admite el envío de registros.
Consulte este documento técnico de MS Research ( http://research.microsoft.com/research/pubs/view.aspx?msr_tr_id=MSR-TR-2006-45 )
Detallan exactamente lo que estás buscando. La versión corta es que cualquier tamaño de archivo superior a 1 MB comienza a degradar el rendimiento en comparación con guardar los datos en el sistema de archivos.
Normalmente, una buena solución es almacenar las imágenes en el sistema de archivos y los metadatos (nombre de archivo, dimensiones, hora de última actualización, cualquier otra cosa que necesite) en la base de datos.
Habiendo dicho eso, no hay una solución "correcta" para esto.
Para algo así como un sitio web de comercio electrónico, es probable que vaya con el almacenamiento de la imagen en una tienda de blob en la base de datos. Si bien no desea realizar una optimización prematura, el beneficio de tener mis imágenes organizadas fácilmente junto con mis datos, así como también ser muy portátil, es un beneficio automático para algo como el comercio electrónico.
Si las imágenes están indexadas, la búsqueda no será un gran problema. No estoy seguro, pero no creo que la búsqueda del sistema de archivos sea O (1), más bien como O (n) (no creo que los archivos estén indexados por el sistema de archivos).
Lo que me preocupa en esta configuración es el tamaño de la base de datos, pero si se maneja correctamente, eso no será un gran problema, y una gran ventaja es que solo tiene una cosa para respaldar (la base de datos) y no preocuparse por los archivos en el disco .
Dudo que O(log n) para búsquedas sea un problema. Usted dice que tiene 10 GB de imágenes. Suponiendo un tamaño de imagen promedio de, por ejemplo, 50 KB, eso equivale a 200 000 imágenes. Hacer una búsqueda indexada en una tabla para filas de 200K no es un problema. Sería pequeño en comparación con el tiempo necesario para leer realmente la imagen del disco y transferirla a través de su aplicación y al cliente.
Todavía vale la pena considerar los pros y los contras habituales de almacenar imágenes en una base de datos en lugar de almacenar rutas en la base de datos a archivos en el sistema de archivos. Por ejemplo:
- Las imágenes en la base de datos obedecen al aislamiento de transacciones, se borran automáticamente cuando se elimina la fila, etc.
- La base de datos con 10 GB de imágenes es, por supuesto, más grande que una base de datos que almacena solo las rutas de acceso a los archivos de imagen. La velocidad de respaldo y otros factores son relevantes.
- Debe configurar encabezados MIME en la respuesta cuando sirve una imagen desde una base de datos, a través de una aplicación.
- Las imágenes en un sistema de archivos son más fáciles de almacenar en caché por el servidor web (por ejemplo, Apache mod_mmap), o pueden ser servidas por un servidor web más delgado como lighttpd. Esto es realmente un gran beneficio.