local recomendado para armazenamento de documentos - no banco de dados ou em outro lugar?

https://stackoverflow.com/questions/512262

21-08-2019
|

Pergunta

Fundo:

Nós temos um sistema de armazenamento de documentos na casa que foi implementado há muito tempo. Por alguma razão, usando o banco de dados como o mecanismo de armazenamento para os documentos foi escolhido.

A minha pergunta é esta:

O que é a melhor prática para armazenar documentos? Quais são as alternativas? Quais são os prós e contras? Respostas não tem que ser a tecnologia ou plataforma específica, é mais de uma melhor pergunta geral prática.

Meus pensamentos:

Os bancos de dados não são destinadas para o armazenamento de documentos. sistemas de arquivo de sistemas ou 3rd party Gestão de Documentos podem ser de melhor uso. Documento de armazenamento em bancos de dados é caro. Operações são lentas. São estes pressupostos lógicos? Talvez este é o melhor, mas na minha mente, temos melhores alternativas. Poderia da Oracle BFILE (links para documentos sobre NAS ou SAN) ser melhor do BLOB / CLOB?

Detalhes:

Os documentos são vários tipos (pdf, palavra, xml)
O código de Camada Intermediária é escrito em .net 2.0 / c #
Os documentos são armazenados numa base de dados Oracle 10g em BLOB com compressão (NAS Storage)
Os tamanhos dos arquivos raiva
O número de documento está crescendo drasticamente e não tem sinais de abrandamento
inserções é tipicamente está nas hunderds por hora durante o pico
Retreival é tipicamente na casa dos milhares por hora durante o pico
armazenamento NAS e armazenamento SAN está disponível

UPDATE (a partir de perguntas abaixo):

minha formação é o desenvolvimento
meta-dados não é associado sobre os arquivos armazenados ao lado de arquivos no banco de dados

Solução

O único limite para o armazenamento de documentos no banco de dados é tecnológica.

A relação de banco de dados pretende ser o armazenamento persistente da missão dados críticos de uma empresa . Quão bem ele pode executar essa função varia de banco de dados para banco de dados e um sistema para outro, é claro. Mas idealmente ACID propriedades de um banco de dados relacional são destinado para torná-lo a loja de todos dados da empresa . O sistema de arquivos, sistemas de controle de revisão e outros sistemas de armazenamento de armazenamento local pode ter vantagens específicas, mas eles não são projetados para armazenamento de dados da empresa como tal.

Se os documentos que você está armazenando qualificar como dados da empresa - se forem usados ??persistentemente através de saída da empresa - então é lógico para mantê-los no banco de dados. Se você está tendo problemas com o armazenamento no banco de dados, talvez um DBA pode encontrar uma solução melhor. Você pode até ter para movê-los para fora do banco de dados por razões de desempenho, mas eu não acho que você deve movê-los para fora do banco de dados por razões de melhores práticas.

Claro que, se os documentos não são os dados da empresa, se eles são usados ??apenas para um aplicativo, dizer, então movê-los para fora do banco de dados também faria sentido.

Outras dicas

Com base na minha experiência eu diria que mantê-los no banco de dados. Nós movemo-nos dois dos nossos sistemas para fazer isso.

colocá-lo no meio do banco de dados:

É fácil acesso, mesmo a partir de vários servidores
É feito o backup automaticamente (em vez de ter que ter um trabalho separado para fazer isso)
Você não precisa se preocupar com o espaço (já que as pessoas manter o DB de encher demais o disco, mas pode se esqueça de monitorar onde os documentos são armazenados)
Você não tem que ter um esquema de diretório complicado

Tivemos documentos fora do banco de dados. Torna-se um problema com lotes de documentos. Um diretório normal em Linux é um bloco, que geralmente é 4K. Tivemos um diretório que era 58MB porque tinha muitos arquivos nele (que era apenas um diretório simples, sem hierarquia). Tinha que muitos blocos indiretos. Levou mais de uma hora para apagar. Levou minutos para obter uma contagem do número de arquivos no diretório. Ele foi péssimo. Esta é em ext3.

Com o sistema de arquivos que você precisa:

mecanismo de backup separado (a partir do backup DB)
Para manter as coisas em sincronia (para que o registro não existir no DB sem o arquivo estar lá)
Uma hierarquia para armazenamento (para evitar o problema listado acima, de modo nenhum diretório acaba com 10,000s de arquivos)
Alguns maneira de visualizá-los a partir de outros servidores, se você precisa de um cluster (então provavelmente NFS ou algum tal)

É realmente uma dor. Para qualquer número não trivial de documentos, eu recomendo contra o sistema de arquivos com base no que eu vi.

Eu prefiro armazenar o documento no sistema de arquivos e depois armazenar um link para o arquivo e meta-dados de arquivos associados no banco de dados .

Ele provou mais conveniente, mais fácil de manter, e menos caro do que a alternativa.

A maioria dos sistemas de gestão de documentos de classe empresarial não armazenar o arquivo objeto no banco de dados. Só porque você pode não significa que você deve . Se escalabilidade e desempenho são importantes para você e você tem um grande conjunto de documentos que você precisa ser muito cuidadosos sobre como armazenar os objetos no db. Considere o seguinte:

No caso caso de imagens de documentos, 200 milhões de arquivos TIFF pode ser considerado um relativamente grande, mas não enorme, sistema. sistemas de maior escala pode ter mais de 1 bilhão de arquivos de objetos. , Digamos, 20KB por bitonal TIFF você poderia ter 4TB de armazenamento de arquivos objeto. Quanto tempo seus backups de banco de dados vai levar? Quanto tempo são as suas consultas vai levar? Qual é a frequência de acesso para esses objetos? Se esses objetos têm uma freqüência alta de acesso, você quer que seu servidor DB high-end gastar todo o seu tempo servindo-se arquivos? Se você tem milhões de objetos, então você precisa ser muito danado cuidadosos sobre como arquiteto de uma solução onde os objetos são armazenados no db.

Suponha que você está agora encarregado de converter esses arquivos 200M TIFF para arquivos PDF. Esteja preparado para levar sua solução para seus joelhos como os seus resíduos de servidor de banco de dados seu tempo servindo-se todos e cada arquivo objeto para o processo de conversão e, em seguida, re-gravar os resultados.

Apenas como exemplo, Sharepoint é famoso para armazenar objetos no db. Sharepoint também é famosa por problemas de escalabilidade.

A minha resposta:
Para sistemas pequenos ( arquivos 1M) armazenar arquivos no DB é um erro.

Minha maior preocupação com o armazenamento dos arquivos no banco de dados em si está a gerir o tamanho ea complexidade de backups e outras operações de manutenção db.

Uma estratégia para atenuar esta dificuldade (pelo menos em MS SQL) é a criação de partições de banco de dados separados, potencialmente armazenados em unidades diferentes.

Em seguida, separar o seu esquema de dados para que seus metadados sobre os arquivos estão localizados em uma partição, e os arquivos BLOB reais estão localizados em uma partição separada.

Estas partições podem ser armazenados em diferentes horários, ou mesmo recuperado separadamente.

Eu armazenadas as imagens como BLOBs no banco de dados de uma vez lamentou a primeira vez que eu tinha que realizar uma operação de lote nessas imagens. Teria sido muito mais fácil fazê-lo no sistema de arquivos. Além disso, como você mencionou, é muito mais rápido para recuperar os documentos se eles vivem em um sistema de arquivos.

A minha visão simples:. O sistema de arquivos deve armazenar arquivos, e um banco de dados relacional deve armazenar dados relacional

Armazenar os arquivos binários no sistema de arquivos. Criar um aplicativo ASP.NET para o armazenamento e operações de recuperação. Pode ser extravagante com o aplicativo web (versionamento doc, segurança multi-camadas, etc). Acho que este é o consenso na indústria de gestão de doc.

Uma vez que o seu "número do documento está crescendo drasticamente", parece que isso está se tornando grande escala. Você pode querer começar a olhar de terceiros, out-of-the-box soluções (como http: // Kofax .com / captura / - Eu tenho uma vasta experiência com isso) para fazer o "trabalho sujo" para você!. Ou melhor ainda, considerar a olhar para SaaS oferecendo como esses caras http://www.edocumentsolutionsllc.com/

: -)

Armazene seus documentos como arquivos como .doc, se você quer ser capaz de acessar os arquivos e edite e salve-los.

Armazene seus documentos como arquivos tais como .pdf ou .tiff se você quiser cópias históricas reais que pode ser puxado para trás para cima e reproduzidas.

loja todas as informações sobre seus arquivos (tais como datas, autores, localização) em seu banco de dados.

Eu sempre armazenar informações núcleo e caminho de arquivo para documentos no banco de dados, mas nunca o documento em si. Raramente a necessidade documento inteiro para estar no banco de dados.

Isso permite muito mais flexibilidade na utilização desses documentos. Por exemplo, quer de armazenamento de backup em camadas usado e mecanismos deduping? Tente fazer isso no Oracle BLOBs.

A única vantagem que eu posso ver para armazenar documentos no banco de dados é a facilidade de mover os documentos para outro ambiente. Além disso, eu não faria isso por todas as razões já mencionadas.

Expertise pessoais: Você é um administrador db ou um programador?

Segurança: uma definição para o banco de dados vs 2 para o sistema de banco de dados e arquivo. É uma preocupação de alguém acidentalmente mover / apagar os arquivos? Em um ambiente complexo um administrador pode optar por mover os arquivos para outro servidor e apenas mudar a partilha ou mapeamento. Eu sei, isso nunca aconteceria.

Novas bases de dados estão a melhorar nesta área.

Considere armazenar seus documentos na subversão, ou outro sistema de controle de versão. Você vai ter um bom backup, a capacidade de olhar para versões antigas de documentos e acesso à rede esplêndida. Consulte " Minha vida na subversão ".

Ao contrário eu iria para armazenamento no banco de dados para um par de razões:

Mais simples estratégia de backup
Os documentos armazenados no banco de dados podem ser indexados e pesquisados ??
Você não tem que se preocupar com arquivos que estão sendo movidos / segurança adulterado
Fácil de porta para outro servidor em caso de um acidente
Se os mandatos do governo você deve armazenar dados indo para trás x anos, administrando isso usando um banco de dados é muito mais fácil

Os bancos de dados são feitos para armazenar dados. Os arquivos são dados apenas.

Apesar de ter dito que há benefícios para armazenar arquivos no sistema de arquivos, o desempenho de um banco de dados de ser chefe é melhor e o tamanho é mantido baixo. SQL Server 2008 permite que você tenha o melhor dos dois mundos, usando o FileStream. Leia este whitepaper para mais informações

Licenciado em: CC-BY-SA com atribuição

Não afiliado a StackOverflow