profile - perfiles - personalizar el perfil de usuario local predeterminado al preparar una imagen de windows 10

¿Almacenar imágenes de perfil de usuario en el disco o en la base de datos? (2)

Estoy creando una aplicación mvc de asp.net donde los usuarios pueden adjuntar una imagen a su perfil, pero también en otras áreas del sistema, como un gadget de mensajería en el panel que muestra los mensajes recientes, etc.

Cuando el usuario los carga, me pregunto si sería mejor almacenarlos en la base de datos o en el disco.

Ventajas de base de datos

es fácil hacer copias de seguridad de toda la base de datos y mantener el contenido del perfil / imágenes con las tablas de perfil / usuario asociadas
cuando construyo servicios web más adelante, solo pueden extraer todos los datos relacionados con el perfil de un lugar (la base de datos)

Ventajas del sistema de archivos

cargar archivos desde el disco es probablemente más rápido
¿Alguna otra ventaja?

Donde otros sitios almacenan este tipo de información. ¿Tengo razón al preocuparme un poco por el rendimiento de la base de datos para algo como esto?

¿Tal vez habría una manera de almacenar en caché las imágenes extraídas de la base de datos durante un período de tiempo?

Alternativamente, ¿qué pasa con la idea de almacenar estas imágenes en la base de datos, pero copiarlas al disco para que el servidor web pueda cargarlas desde allí? Esto parece dar tanto la copia de seguridad como la conveniencia de un Db, al mismo tiempo que brinda las ventajas de velocidad de los archivos en el disco.

Infraestructura en cuestión

El sitio web se implementará en IIS en Windows Server 2003 ejecutando el sistema de archivos NTFS.
La base de datos será SQL Server 2008.

Resumen

Leyendo un montón de temas relacionados aquí en SO, muchas personas ahora están tendiendo hacia el tipo de Filestream de SQL Server. Sin embargo, de lo que pude reunir (puedo estar equivocado), no hay mucho beneficio cuando los archivos son bastante pequeños. Sin embargo, la transferencia de archivos parece mejorar en gran medida el rendimiento cuando los archivos tienen varios MB o más.

Como las fotos de mi perfil tienden a sentarse alrededor de ~ 5kb, decidí dejarlas almacenadas en un almacén de archivos en la base de datos como varbinary (max).

En ASP.NET MVC vi un poco de un problema de rendimiento al devolver FileContentResults para las imágenes extraídas de la base de datos de esta manera. Así que terminé de almacenar en caché el archivo en el disco cuando se lee si la ubicación de este archivo no se encuentra en la caché de mi aplicación.

Así que supongo que fui por un híbrido;

Almacenamiento de base de datos para facilitar la recopilación de datos y los archivos se vinculan directamente a los perfiles
Copia instantánea en el disco para permitir un mejor almacenamiento en caché

En cualquier momento, puedo eliminar la carpeta de la caché en el disco y, a medida que se vuelvan a solicitar las imágenes, se volverán a copiar en el primer golpe y se servirán desde la caché allí después.

En realidad, su búsqueda de datos con la base de datos puede ser más rápida dependiendo de la cantidad de imágenes que tenga, a menos que esté utilizando un motor de sistema de archivos altamente optimizado. Las bases de datos están diseñadas para búsquedas rápidas y utilizan MUCHAS técnicas más interesantes que un sistema de archivos.

reiserfs (obsoleto) realmente impresionante para las búsquedas, zfs, xfs y NTFS tienen fantásticos algoritmos de hashing, linux ext4 parece prometedor también.

El impacto en el sistema no será diferente en términos de lecturas en bloque. La pregunta es: ¿qué es más rápida una consulta de consulta que devuelve el nombre de archivo (puede ser un hash?) Al que a su vez se accede mediante un cierre de envío de archivos abierto, separado? ¿O simplemente deshacerse de la mancha?

Hay varias cosas que se deben considerar, incluyendo el impacto de la red, el impacto del procesamiento, la distribución, etc. Si almacena cosas en la base de datos, puede moverla. Entonces, nuevamente, si almacena imágenes en un servicio de entrega de contenido que puede ser MUCHO más rápido, ya que no está haciendo ningún tipo de acceso a la red en sí mismo.

Piénselo, y recuerde que un poco de evaluación comparativa nunca le hará daño a nadie :-) así que pruébelo con su tamaño de conjunto de datos típico y tenga en cuenta cosas como consultas simultáneas, etc.

Almacene las referencias a los archivos en una base de datos y almacene los archivos en el disco .

Este enfoque es mucho más flexible y más fácil de escalar.

Puede tener una sola base de datos y varios servidores que sirven contenido estático. Será mucho más complicado tener varias bases de datos que hagan ese trabajo.

Flickr funciona de esta manera.

Espero eso ayude.