Sirviendo imágenes desde el servidor SQL vs. sistema de archivos vs. S3 etc.

Mi aplicación (¡asp clásico yay!) Tiene alrededor de 2.1 millones de imágenes a 25GB y eso solo representa 90 días de datos y me gustaría ir a 365 como mínimo. Necesito tener esto bajo control y estoy considerando todas las opciones. ¿Qué piensa sobre las ventajas y desventajas de las siguientes prácticas?

• Ventajas de SQL Server: fácil de respaldar Contras: ¿rendimiento?
• Ventajas del sistema de archivos: Contras de velocidad: redundancia, la copia de seguridad es lenta (actualmente se está investigando hacer copias de seguridad completas sintéticas que podrían mejorarlo)
• S3 y similares Pros: el ancho de banda se transfiere de mi centro de datos a Amazon, almacenamiento prácticamente ilimitado. Contras: Costo, el análisis de costos es complicado (estimar que el 80% de mi ancho de banda son imágenes para fines de ROI), difícil / costoso para cambiar los proveedores de servicios en caso de que sea necesario

¿Alguien más se enfrenta al desafío de imágenes multimillonarias y cómo lo resolvió?

No tenemos millones de imágenes, pero tenemos cientos de miles, y utilizamos el enfoque híbrido: mysql para metadatos, imágenes almacenadas en el disco local para copia de seguridad y enviadas a Amazon s3 donde se sirven a los usuarios. No hemos tenido problemas con Amazon y su disponibilidad. La mudanza a Cloudfront está en nuestros planes, solo necesitamos encontrar el tiempo.

Esta discusión puede ser útil para usted en su decisión:
http://ask.metafilter.com/59635/Millions-of-images

Iría con metadatos en el servidor SQL y archivos en el sistema de archivos (o s3 o cloudfront). Pero la mejor respuesta depende de otros patrones de uso:

• las imágenes cambian a menudo
• ¿puede servir las imágenes directamente desde el sistema de archivos (es decir, img src="...") o necesita que se controle el acceso? Si este último, entonces una solución de base de datos es mejor
• ¿Está sirviendo una pequeña cantidad de imágenes la mayor parte del tiempo (el 10% más reciente) o la distribución está relativamente extendida.

Las copias de seguridad de millones de imágenes serán complicadas, sin importar cómo las organice, solo son muchos datos. Me gustaría encontrar un buen caso de estudio sobre cómo realizar copias de seguridad de blobs en el servidor SQL antes de comprometerme con esa solución. (Aquí hay un artículo que puede ser útil: http://www.databasejournal.com/features/mssql/article.php/3738276/Storing-Images-and-BLOB-files-in-SQL-Server-Part-4.htm )

Si decide almacenarlos en el sistema de archivos, es posible que desee leer esta pregunta de ServerFault para algunas cosas que hacer y no hacer: almacenar un millón de imágenes en el sistema de archivos .

Ignore a las personas que dicen: " No almacene imágenes / datos binarios en la base de datos ", ya que basan sus respuestas en información antigua (suponiendo que almacenará los datos en una columna de tipo VarBinary). Los problemas de rendimiento al usar SQL Server para almacenar imágenes ahora se pueden mitigar mediante el uso del tipo de datos FILESTREAM en SQL Server 2008. En esencia, el tipo de datos FILESTREAM le permite combinar la facilidad de almacenar datos en la base de datos con el rendimiento que obtiene al servir archivos de un almacén de archivos NTFS.

Para citar SQL Mag :

"El nuevo soporte FILESTREAM de SQL Server 2008 combina la ventaja de acceder a los LOB directamente desde el sistema de archivos NTFS con la integridad referencial y la facilidad de acceso que ofrece el motor de base de datos relacional de SQL Server".

Para obtener más información, lea este blog de Ravi S.Maniam en MSDN .

Si bien no enfrento el desafío de imágenes multimillonarias, usaría Amazon CloudFront. Todos los archivos se almacenan en un depósito S3 pero son servidores a través del sistema de entrega de contenido de Amazon. No usaría S3 solo.

Mi segunda opción sería el sistema de archivos. Simple y fácil, el único problema es que si todos estos archivos terminan en un directorio, todo se bloqueará, con fuerza.

SQL para mí no sería una opción para un sistema como este. No solo se le cobrará por la transferencia de ancho de banda, también se le cobrará por el procesamiento de la consulta, esto dependerá mucho del alojamiento, sino que supongo que está utilizando un servidor dedicado o al menos un vps donde se le cobrará por ciclos. Luego, ralentizará todo su sitio si usa la misma base de datos que el servidor de imágenes. Si no, entonces agrega toda esta complejidad de tener que administrar dos conexiones de base de datos.

Las bases de datos están diseñadas para datos transaccionales / consistencia y seguridad.

Los archivos multimedia (imágenes, audio, video) tienden a crearse y tal vez eliminarse, pero rara vez se actualizan. Por lo tanto, generalmente no hay necesidad de mantenerlos consistentemente transaccionales con otros datos y una base de datos no le dará ningún beneficio real allí. El contenido del texto puede ser un asunto diferente.

Siempre que no tenga ningún problema con el concepto de que alguien extraiga su archivo directamente si tiene la URL del archivo, entonces un sistema de archivos está bien. Si estaba ejecutando algo así como una biblioteca de fotos, donde espera cargar antes de que las personas descarguen el archivo, entonces probablemente sea un asunto diferente. Es decir, una vez que un usuario ha pagado, puede obtener una URL específica para ese usuario o válida solo por un corto tiempo, y la aplicación maneja URL múltiples o temporales que apuntan a la misma imagen. Eso todavía podría ser manejado por la aplicación y un sistema de archivos, pero terminas sirviendo los medios a través de la aplicación en lugar de una descarga directa de archivos (que en su mayoría descartaría cualquier beneficio de S3) y hay menos diferencia entre DB y el sistema de archivos .