Considerações onde armazenar documentos - no servidor de arquivos ou no banco de dados?

Question

Eu tenho uma decisão de design a tomar em relação aos documentos enviados para o meu site: posso armazená -los no meu servidor de arquivos em algum lugar ou posso armazená -los como uma blob no meu banco de dados (MSSQL 2005). Se fizer alguma diferença na decisão de design, esses documentos são confidenciais e devem ter um certo grau de proteção.

As considerações que pensei são:

1. O armazenamento no servidor de arquivos faz com que os números de arquivos huuuuuuuge sejam despejados em um único diretório e, portanto, acesso mais lento, a menos que eu possa elaborar uma definição semântica razoável para uma estrutura de árvore de diretório
2. OTOH, acho que o servidor de arquivos pode lidar com a compactação um pouco melhor que o banco de dados ... ou estou errado?
3. Meus instintos me dizem que a segurança do banco de dados é mais forte que a do servidor de arquivos, mas não tenho certeza se isso é necessariamente verdadeiro.
4. Não sei como ter terabytes de blobs no meu banco de dados afetará o desempenho.

Eu apreciaria muito algumas recomendações aqui. Obrigado!

Answer 1

No SQL Server 2005, você só tem a opção de usar VARBINARY(MAX) Para armazenar os arquivos dentro da tabela de banco de dados ou mantê -los do lado de fora.

A desvantagem óbvia de deixá -los fora do banco de dados é que o banco de dados não pode realmente controlar o que acontece com eles; Eles poderiam ser movidos, renomeados, excluídos .....

servidor SQL 2008 apresenta o FILESTERAM atributo em VARBINARY(MAX) Tipos, que permitem deixar os arquivos fora da tabela de banco de dados, mas ainda sob controle transacional do banco de dados - por exemplo, você não pode simplesmente excluir os arquivos do disco, os arquivos são parte integrante do banco de dados e, assim, são copiados e backup com isto. Ótimo se você precisar, mas pode ser um grande backup! :-)

O lançamento do SQL Server 2008 apresentou algumas "melhores práticas" sobre quando armazenar coisas no banco de dados diretamente e quando usar o FilEstream. Estes são:

• Se os arquivos tipicamente forem menores de 256 kb de tamanho, a tabela de banco de dados é a melhor opção
• Se os arquivos tipicamente tiverem mais de 1 mb de tamanho, ou poderão ter mais de 2 GB de tamanho, depois FileStream (ou no seu caso: sistema de arquivos antigo simples) é a sua melhor escolha
• Nenhuma recomendação para arquivos entre essas duas margens

Além disso, para não afetar negativamente o desempenho de suas consultas, geralmente é uma boa idéia colocar os arquivos grandes em uma tabela separada, não - não tenha os enormes bolhas que façam parte de suas tabelas regulares que você consulte - mas crie um A tabela separada, contra a qual você apenas se pergunta, se realmente precisa dos megabytes de documentos ou imagens.

Para que isso possa lhe dar uma idéia de onde começar!

Answer 2

Eu sugiro fortemente que você considere a solução do sistema de arquivos. As razões são:

• Você tem melhor acesso aos arquivos (precioso em caso de depuração), o que significa que você pode usar ferramentas regulares baseadas em console
• Você pode aproveitar de maneira rápida e fácil o sistema operacional para distribuir a carga, por exemplo, usando um sistema de arquivos distribuído, adicionar redundância por meio de um ataque de hardware etc.
• Você pode aproveitar as listas de controle de acesso ao sistema operacional para aplicar permissões.
• você não entupida seu banco de dados

Se você está preocupado com grandes quantidades de entradas em seus diretórios, sempre pode criar um esquema de ramificação. por exemplo:

filename : hello.txt
filename md5: 2e54144ba487ae25d03a3caba233da71
final filesystem position: /path/2e/54/hello.txt

Answer 3

Há muitos "depende" por trás desse assunto popular. Como você diz que os documentos são sensíveis e confidenciais, fora do manguito, eu iria armazenar no banco de dados. Aqui estão algumas razões:

• Segurança potencialmente melhor. Muitas vezes, é mais fácil invadir um sistema de arquivos do que um banco de dados.
• Melhor controle de volume. Milhares de arquivos em uma pasta podem forçar um sistema operacional, onde um banco de dados pode levar milhões de linhas em uma tabela sem piscar.
• Melhor pesquisa e digitalização. Adicione colunas categorizando quando você carrega os dados ou experimente a indexação de texto completo para digitalizar os documentos reais.
• Os backups podem ser mais eficientes - basta adicionar outro banco de dados ao seu plano de backup e você estará coberto (depois de elaborar detalhes do espaço, é claro). E esses arquivos de backup são outra camada de ofuscação em qualquer pessoa que tenta obter seus documentos confidenciais.
• O SQL Server 2008 possui opções de compactação de dados que podem ajudar aqui. Isso, ou tem o aplicativo, faça isso? (Mais segurança através da ofuscação, talvez)

O SQL Server 2008 também possui o tipo de dados do FileStream, que pode ajudar aqui, mas não estou familiarizado o suficiente para dar uma recomendação para sua situação.