Strategia per gestire un DB SQL Server con troppi file (BLOB) in esso?

Scenario:
database SQL Server 2005 per la manutenzione di un'applicazione ASP.NET (su server Web separati).

Database:
DB contiene circa 5 GB di dati "normali" e circa 15 GB di "file" (es: un PDF 200k archiviato come immagine (BLOB), quel genere di cose). Altri file vengono caricati dagli utenti e consumano rapidamente più spazio su disco (il DB potrebbe aumentare fino a 50 GB nei prossimi mesi, principalmente file).

Preoccupazioni: l'
archiviazione di così tanti file nel DB sta già causando problemi (ad esempio: le grandi dimensioni totali del database rendono difficili i backup e le distribuzioni di interi DB occasionali).

E siamo preoccupati che ci saranno più problemi . (ad esempio: problemi di prestazioni - forse causati dalla mancata conservazione dell'intero DB nella RAM, forse?)

Domanda:
quale soluzione tecnica suggeriresti a questo problema? Memorizzare i file nel file system? Dividi il database in due e ne hai uno più grande, più lento per i file?

Ulteriori dettagli se necessari:
questi file non sono estremamente importanti e non richiedono tempi di accesso molto rapidi: un paio di secondi andrebbero bene e al momento ci sono forse una dozzina di selezioni all'ora. Gli altri dati "normali" nel DB includono le informazioni necessarie più volte al secondo.

Mi occupo di un database molto simile, attualmente 3 TB e in crescita di 5 GB al giorno.

• Filestream (2008+) non risolve la sfida di backup / ripristino.
• Filestream ha prestazioni migliori dell'archiviazione LOB per file> 1 MB, così afferma il test di Paul Randal . Il carico di lavoro dipende da 256 KB-1 MB e generalmente peggiora a <256 KB.
• Un grande vantaggio per Filestream in alcuni ambienti è che ignora il pool di buffer e utilizza invece la cache di sistema di Windows.
• Se si inseriscono i file in un filesystem, si perde la coerenza transazionale con il record del database. Hai anche aggiunto il sovraccarico del backup di milioni di singoli file, il che può essere problematico.

Valuta i pro e i contro di Filestream e vedi se si adatta al tuo caso. Nel nostro caso, abbiamo preso una strada diversa e abbiamo optato per il partizionamento del database in modo da poter fare uso di disponibilità parziale / ripristino frammentario .

Un'opzione che non era disponibile per noi, che potresti avere, è quella di contrassegnare i filegroup precedenti / di archivio come di sola lettura. I filegroup di sola lettura possono quindi essere sottoposti a backup di rado.

Se sei bloccato su Standard 2005 (il partizionamento è una funzione dell'edizione Enterprise) e hai l'opzione di sola lettura per la cronologia, puoi affrontarlo alla vecchia maniera.

• Dividi il tuo tavolo. È possibile prendere in considerazione il percorso attivo / storico o la data, ad esempio tabella al mese.
• Metti i dati storici su un filegroup di sola lettura ed esegui il backup solo quando archivi altri dati. Assicurati che i tuoi utenti comprendano che ciò riduce solo i tempi di backup. Il ripristino potrebbe richiedere del tempo quando non si dispone della funzione di disponibilità parziale.
• Crea una vista partizionata sopra le tabelle.

Un'ultima opzione (che stiamo prendendo in considerazione per il nostro blobber da 3 TB) è quella di spostare i dati del file in un database di documenti o in un archivio cloud (ad esempio AmazonS3 , Azure BLOB Storage ). Ciò introduce il problema di coerenza transazionale che ho citato in precedenza, ma allontana il carico da quei server SQL molto costosi.

prova la funzione FILESTREAM in SQL server,

FILESTREAM integra il Motore di database di SQL Server con un file system NTFS archiviando i dati varbinary (max) binary large object (BLOB) come file sul file system

bei articoli a riguardo

1. Un'introduzione a FileStream di SQL Server
2. BLOB o Non BLOB: archiviazione di oggetti di grandi dimensioni in un database o in un filesystem
3. Archiviazione FILESTREAM in SQL Server 2008