Qual é a melhor estratégia para retenção de grandes conjuntos de dados?

Question

Estou liderando um projeto onde registraremos dados de métricas.Eu gostaria de reter os dados por anos.No entanto, também gostaria de evitar que a tabela principal fique cheia de dados que, embora necessários para tendências de longo prazo, não são necessários para relatórios de curto prazo.

Qual é a melhor estratégia para lidar com esta situação?Simplesmente arquivar os dados antigos em outra tabela?Ou "acumular" por meio de alguma consolidação dos próprios dados (e depois armazená-los em uma tabela diferente)?Ou algo totalmente diferente?

Informação adicional:estamos usando o SQL Server 2005.

Answer 1

Usamos os dois métodos no meu trabalho, mas um pouco diferentes, mantemos todos os dados de vendas na tabela primária por 30 dias, depois à noite (parte dos trabalhos noturnos) os dias em que as vendas são acumuladas em resumos (n quantidade de x produto vendido hoje etc.) em uma tabela separada por motivos de relatório, e as vendas superiores a 30 dias são arquivadas em um banco de dados diferente, então, uma vez por ano (vamos para os anos fiscais), um novo banco de dados de arquivo é iniciado.não exatamente perfeito, mas..

desta forma obtemos os dados dos resumos rapidamente, mantemos todos os dados de vendas atuais à mão e temos um espaço ilimitado para os dados detalhados do arquivo.tentamos manter tudo em um banco de dados (em tabelas diferentes), mas o tamanho do arquivo do banco de dados (interbase) ficaria tão grande que arrastaria o sistema para baixo.

o único problema real que temos é acessar dados detalhados que abrangem vários bancos de dados, pois a conexão e a desconexão são lentas e a análise deve ser feita em código em vez de sql

Answer 2

Se você estiver usando o SQL Server 2005, este pode ser um bom candidato para usar tabelas particionadas.

Answer 3

Dependendo de restrições como orçamento, etc., este parece ser um candidato perfeito para um aplicativo de data warehouse.Isso normalmente introduziria um novo servidor para uso como data warehouse.O SQL Server 2005 oferece suporte imediato a muitas dessas atividades; além disso, você poderá utilizar serviços adicionais do SQL Server (por exemplo,Analysis Services, Reporting Services) para fornecer valor adicional aos seus usuários.(ver http://www.microsoft.com/technet/prodtechnol/sql/2005/dwsqlsy.mspx)

Answer 4

@Jason - Não vejo como manter os dados em arquivos de texto simples e antigos permitirá que você faça facilmente análises de tendências de longo prazo nos dados.

@Jason - acho que o que quero dizer é que, se houver algum tipo de análise ad-hoc (ou seja,tendências) precisa ser feito nos dados por pessoas de negócios, acumular ou arquivar os dados em arquivos de texto realmente não resolve nenhum problema.É claro que escrever código para consumir um arquivo de texto é fácil em muitas linguagens, mas esse problema foi resolvido.Além disso, eu diria que os RDBMS atuais são extremamente duráveis ​​quando configurados e mantidos adequadamente.Se não fossem, por que você administraria um negócio em cima de um (e muito menos arquivaria dados nele)?Simplesmente não vejo sentido em arquivar em um arquivo de texto simples devido à alegação de que a durabilidade dos arquivos de texto é superior à dos bancos de dados.

Answer 5

Qualquer uma dessas opções é excelente, mas realmente depende do domínio do problema.Para coisas como saldos de caixa ou dados estatísticos, acho que acumular registros e consolidá-los é a melhor maneira, você pode então mover os registros acumulados para uma tabela de arquivo paralela, codificando-os de forma que você possa "desenrolar" se necessário.Isso mantém sua tabela de dados primária limpa e rápida, mas permite reter os dados extras para auditoria ou qualquer outra coisa.A questão principal é: como implementar o processo de “roll-up”.Automaticamente, por meio de um gatilho ou processo no servidor, ou por intervenção do usuário no nível do aplicativo?