¿Estrategia para manejar una base de datos de SQL Server con demasiados archivos (BLOB)?

11

Escenario: la
base de datos SQL Server 2005 que da servicio a una aplicación ASP.NET (en servidores web separados).

Base de datos:
DB contiene aproximadamente 5 GB de datos "normales" y aproximadamente 15 GB de "archivos" (por ejemplo: un PDF de 200k almacenado como una imagen (BLOB), ese tipo de cosas). Los usuarios están cargando más archivos y están consumiendo rápidamente más espacio en disco (la base de datos podría crecer a 50 GB en los próximos meses, principalmente archivos).

Preocupaciones:
Almacenar tantos archivos en la base de datos ya está causando problemas (por ejemplo: el gran tamaño total de la base de datos hace que las copias de seguridad e implementaciones ocasionales de la base de datos completa sean difíciles).

Y nos preocupa que haya más problemas . (por ejemplo: problemas de rendimiento, ¿tal vez causados ​​por no poder mantener todo el DB en la RAM, tal vez?)

Pregunta:
¿Qué solución técnica sugeriría para este problema? Almacenar los archivos en el sistema de archivos? ¿Divide la base de datos en dos y tiene una más grande y más lenta para los archivos?

Más detalles si es necesario:
estos archivos no son súper importantes y no necesitan tiempos de acceso muy rápidos: un par de segundos estaría bien, y tal vez haya una docena de selecciones por hora como máximo, actualmente. Los otros datos "normales" en la base de datos incluyen información necesaria muchas veces por segundo.

sql-server-2005 performance disk-space MGOwen
fuente
¿Es posible actualizar a 2008+ como parte de una solución?
Jon Seigel
@ Jon Seigel Sí, ¿qué opciones están disponibles en 2008 (o incluso en 2012)?
MGOwen

Respuestas:

6

Cuido una base de datos muy similar, actualmente de 3 TB y creciendo 5 GB por día.

  • Filestream (2008+) no resuelve el desafío de copia de seguridad / restauración.
  • Filestream funciona mejor que el almacenamiento LOB para archivos> 1 MB, según las pruebas de Paul Randal . Depende de la carga de trabajo a 256 KB-1 MB y generalmente peor a <256 KB.
  • Una gran ventaja para Filestream en algunos entornos es que omite el grupo de búferes y utiliza la memoria caché del sistema de Windows.
  • Si coloca los archivos en un sistema de archivos, pierde la coherencia transaccional con el registro de la base de datos. También ha agregado la sobrecarga de realizar copias de seguridad de millones de archivos individuales, lo que puede ser problemático.

Evalúe los pros y los contras de Filestream y vea si encaja en su caso. En nuestro caso, hemos tomado una ruta diferente y optamos por particionar la base de datos para que podamos hacer uso de la disponibilidad parcial / restauración parcial .

Una opción que no estaba disponible para nosotros, que es posible que tenga, es marcar grupos de archivos antiguos / archivados como de solo lectura. Los grupos de archivos de solo lectura se pueden respaldar con poca frecuencia.

Si está atascado en el estándar 2005 (la partición es una característica de la edición Enterprise) y tiene la opción de solo lectura para el historial, puede abordar esto a la antigua usanza.

  • Divide tu mesa. Puede considerar la ruta activa / histórica o la fecha, por ejemplo, tabla por mes.
  • Coloque los datos históricos en un grupo de archivos de solo lectura y haga una copia de seguridad solo cuando archive más datos. Asegúrese de que sus usuarios comprendan que esto solo reduce el tiempo de respaldo. La restauración puede llevar un tiempo cuando no tiene la función de disponibilidad parcial.
  • Cree una vista particionada sobre las tablas.

Una última opción (que estamos considerando para nuestro blobber de 3TB) es mover los datos del archivo a una base de datos de documentos o almacenamiento en la nube (por ejemplo , AmazonS3 , Azure BLOB Storage ). Esto introduce el problema de consistencia transaccional que mencioné anteriormente, pero quita la carga de esos servidores SQL muy caros.

Mark Storey-Smith
fuente