Estratégia para lidar com um banco de dados do SQL Server com muitos arquivos (BLOBs) nele?

Cenário:
banco de dados do SQL Server 2005 atendendo a um aplicativo ASP.NET (em servidores Web separados).

Banco de dados: O
DB possui cerca de 5 GB de dados "normais" e cerca de 15 GB de "arquivos" (por exemplo: um PDF de 200k armazenado como imagem (BLOB), esse tipo de coisa). Mais arquivos estão sendo carregados pelos usuários e estão consumindo rapidamente mais espaço em disco (o banco de dados pode aumentar para 50 GB nos próximos meses, principalmente arquivos).

Preocupações: O
armazenamento de tantos arquivos no banco de dados já está causando problemas (por exemplo: o grande tamanho total do banco de dados dificulta os backups e implantações ocasionais de todo o banco de dados).

E estamos preocupados que haverá mais problemas . (por exemplo: problemas de desempenho - talvez causados ​​por não conseguir manter todo o banco de dados na RAM, talvez?)

Pergunta:
Que solução técnica você sugeriria para este problema? Armazenar os arquivos no sistema de arquivos? Dividir o banco de dados em dois e ter um maior e mais lento para arquivos?

Detalhes adicionais, se necessário:
esses arquivos não são extremamente importantes e não precisam de tempos de acesso muito rápidos - alguns segundos seriam bons e, atualmente, talvez haja uma dúzia de seleções por hora. Os outros dados "normais" no banco de dados incluem informações necessárias muitas vezes por segundo.

Eu cuido de um banco de dados muito semelhante, atualmente com 3 TB e crescendo 5 GB por dia.

• O Filestream (2008+) não resolve o desafio de backup / restauração.
• O Filestream tem desempenho melhor que o armazenamento LOB para arquivos> 1 MB, diz o teste de Paul Randal . Depende da carga de trabalho em 256 KB-1 MB e geralmente é pior em <256 KB.
• Uma grande vantagem do Filestream em alguns ambientes é que ele ignora o buffer pool e usa o cache do sistema Windows.
• Se você colocar os arquivos em um sistema de arquivos, você perde a consistência transacional com o registro do banco de dados. Você também adicionou a sobrecarga de fazer backup de milhões de arquivos individuais, o que pode ser problemático.

Pese os prós e contras do Filestream e veja se ele se encaixa no seu caso. No nosso caso, seguimos uma rota diferente e optamos por particionar o banco de dados para podermos usar a disponibilidade parcial / restauração fragmentada .

Uma opção que não estava disponível para nós, que você pode ter, é marcar os grupos de arquivos mais antigos / archive como somente leitura. O (s) grupo (s) de arquivos somente leitura podem ser copiados com pouca frequência.

Se você ficou preso no 2005 Standard (o particionamento é um recurso da edição Enterprise) e você tem a opção de somente leitura para o histórico, pode resolver isso da maneira antiga.

• Divida sua mesa. Você pode considerar a rota / data ativa / histórica com base, por exemplo, tabela por mês.
• Coloque os dados históricos em um grupo de arquivos somente leitura e faça backup somente quando arquivar mais dados. Garanta que seus usuários entendam que isso reduz apenas o tempo de backup. A restauração pode demorar um pouco quando você não possui o recurso de disponibilidade parcial.
• Crie uma exibição particionada sobre as tabelas.

Uma opção final (que estamos considerando para o nosso blobber de 3 TB) é mover os dados do arquivo para um banco de dados de documentos ou armazenamento em nuvem (por exemplo , AmazonS3 , Azure BLOB Storage ). Isso introduz o problema de consistência transacional que mencionei anteriormente, mas reduz a carga desses servidores SQL muito caros.

tente o recurso FILESTREAM no SQL server,

O FILESTREAM integra o Mecanismo de Banco de Dados do SQL Server a um sistema de arquivos NTFS, armazenando dados varbinary (max) binary large object (BLOB) como arquivos no sistema de arquivos

bons artigos sobre isso

1. Uma introdução ao SQL Server FileStream
2. BLOB ou Não BLOB: Armazenamento de Objetos Grandes em um Banco de Dados ou Sistema de Arquivos
3. Armazenamento FILESTREAM no SQL Server 2008