Documento / Imagem banco de dados repositório Projeto Pergunta

Question

Pergunta:

Devo escrever meu aplicativo para acessar diretamente um banco de dados Imagem Repository ou escrever uma peça middleware aos pedidos de documentos punho.

Fundo:

Eu tenho um costume Document Imaging e aplicação de fluxo de trabalho que atualmente armazena cerca de 15 milhões de documentos / imagens de documentos (90% + uma única página, grupo 4 tiffs, o resto PDF, documentos do Word e Excel). O repositório de imagens é um, 3ª aplicação comercial partido que é muito caro e, francamente, tem muita sobrecarga. Eu só preciso de um sistema para armazenar e recuperar imagens de documentos.

Estou pensando em mudar a imagem diretamente em um banco de dados SQL Server 2005. As informações de indexação é muito limitado - basicamente 2 campos de índice. É um sistema de administração de apólices de seguro de vida para que as imagens I índice com uma série de políticas e um sistema de número de identificação ampla único. Há outros valores de índice, mas eles são armazenados e mantidos separadamente dos dados da imagem. Esses valores de índice dá-me a capacidade de olhar-se o valor id único para a recuperação de imagem individual.

O servidor de banco de dados é um dual-quad janelas centrais caixa de 2003 com unidades de SAN que hospedam os arquivos de DB. O tamanho atual repositório de imagem é de cerca de 650GB. Eu não fiz qualquer teste para ver quão grande é a base de dados convertida será. Eu realmente não estou perguntando sobre o design de banco de dados - Estou trabalhando com nossos DBAs sobre esse aspecto. Se isso mudar, eu vou estar de volta: -)

O actual sistema a ser substituído é, obviamente, um aplicativo de middleware, mas é um sistema de propagação muito pesado por 3 servidores Windows. Se eu seguir esse caminho, seria um sistema único servidor.

As minhas principais preocupações são scalabity e performace - fortemente ponderada para o desempenho. Eu tenho cerca de 100 usuários, e crescimento de uso provavelmente será lenta para os próximos anos. A maioria dos usuários são lidos principalmente usuários - eles não adicionar imagens para o sistema muito frequentemente. Temos um departamento que lida com a digitalização e de outra maneira adicionar imagens para o repositório. Temos também algumas outras aplicações que recebem documentos (via FTP) e que inseri-las no repositório automaticamente à medida que são recebidos, ou vai informações índice completo ou como "lotes" de que um comentário de usuário e índices.

A maioria (90% +) dos documentos / imagens são muito pequenas, <100K, provavelmente <50K, então eu acredito que o armazenamento das imagens no arquivo de banco de dados será o mais eficiente em vez de obter SQL 2008 e usando um filestream.

Answer 1

Muitas vezes escalabilidade e desempenho são finalmente casados ??entre si no sentido de que daqui a seis meses de gestão de volta e diz "Função Y na Aplicação X está sendo executado inaceitavelmente lento, como podemos acelerá-lo?" E tudo muito a muitas vezes a resposta é atualizar a solução de back-end. E quando se trata de extremidades melhoria das costas, é quase sempre vai menos caro para escalar para fora do que para dimensionar-se em termos de hardware.

Então, longa história curta, eu recomendaria a construção de um aplicativo de middleware que especificamente lida com solicitações de entrada do aplicativo de usuário e em seguida, encaminha-os para o destino apropriado. Este será suficientemente abstrata seu aplicativo do usuário front-end da solução de armazenamento de back-end para que quando escalabilidade se torna um problema apenas o aplicativo middleware terá de ser atualizado.

Answer 2

Este é simples. Escrever o aplicativo para uma interface, use algum tipo de mecanismo de fábrica para fornecer essa interface, e implementar essa interface como quiser.

Uma vez que você está feliz com sua interface, em seguida, o aplicativo é (principalmente) isolado a partir da implementação, se ele está falando diretamente para a DB ou a algum outro componente.

Pensando no futuro um pouco em seu design de interface, mas fazendo osso estúpido, "É simples, ele funciona aqui, ele funciona agora" implementações ofertas um bom equilíbrio de futuro à prova o sistema enquanto não necessariamente sobre engenharia-lo.

É fácil argumentar que você não precisa mesmo de uma interface, neste momento, e não apenas uma simples classe que você instancia. Mas se o seu contrato está bem definida (ou seja, a interface ou classe assinatura), que é o que você protege de alteração (como refazer a implementação de back-end). Você sempre pode substituir a classe com uma interface mais tarde, se você achar necessário.

Quanto escalabilidade, testá-lo. Então você sabe que não só se você pode precisar de escala, mas talvez quando bem. "Funciona muito bem para 100 usuários, problemático para 200, se nós batemos 150 que pode querer considerar tomar um outro olhar para o back-end, mas é bom para agora."

Isso é devida diligência e um design tática responsável, IMHO.

Answer 3

Eu concordo com gabriel1836. No entanto, um benefício adicional seria que você poderia por um tempo executar um sistema híbrido para um tempo desde que você não está indo para converter 14 milhões de documentos do seu sistema proprietário para você sistema de home grown durante a noite.

Além disso, eu fortemente incentivá-lo para armazenar os documentos fora de um banco de dados. Armazená-los em um sistema de arquivos (local, SAN, NAS, não importa) e armazenar ponteiros para os documentos no banco de dados.

Eu adoraria saber o sistema de gerenciamento de documento que você está usando agora.

Além disso, não subestime o esforço de substituir a captura (digitalização e importação) fornecido pelo sistema proprietário.