Gerenciando registros de transações enormes?

Question

Eu tenho um aplicativo que está programado e obter alguns dados de uma tabela outro banco de dados e despeja na minha tabela de banco de dados principais aplicações, o número de registros nesta tabela aumenta diariamente e presumo que ele irá crescer diariamente como é dados de eventos de transações que os dados occur.This é usado para o processamento pelo aplicativo principal que leva cada registro e faz a análise necessária e marcas cada registro como processado.

Que tipo de solução eu posso prover para que eu possa manter o tamanho do banco de dados para baixo no futuro?

Como você vai fazer sobre isso nesta situação?

A minha observação de algumas aplicações empresariais, um fornece uma opção que o utilizador pode registros de arquivo 'mais velhos do que 60 dias' etc ... para um texto file.Well eu poderia fornecer uma opção para arquivar os registros processados ??em um arquivo de texto e excluir os registros do banco de dados, o arquivo de texto pode ser importado posteriormente, se necessário? Será esta uma solução?

Answer 1

Se você precisa ocasionalmente de acesso que os dados mais antigos, em seguida, a construção de um processo para arquivá-lo ao texto e, em seguida, a carga de volta a partir de texto provavelmente não é uma grande solução. Os discos rígidos são baratos.

Você poderia agregar os dados mais antigos. Por exemplo, se os dados da transação está no grão milissegundo agora, mas quando você relatórios sobre os dados mais antigos, você obtê-lo a cada dia, em seguida, considere agregar os dados para "diária", como o seu processo de arquivamento. Você pode ser capaz de entrar em colapso centenas de milhares de linhas em uma apenas alguns para cada dia.

Considere também um bom esquema de particionamento onde você pode manter as transações mais recentes em um conjunto de discos e os dados arquivados para outros discos, espero que em um processo onde você pode facilmente adicionar novos discos e criar tabelas para os discos.

Answer 2

Que tipo de dados passados ??relatando necessidades que sua empresa tem? Descartando dados arquivados em um arquivo de texto é tudo muito bem, supondo que você não precisa ser capaz de relatar fora de que os dados no futuro. No entanto, tê-lo em um arquivo de texto significa que você tem que ter um processo manual para importá-lo sob demanda em um banco de dados quando for necessário.

A melhor opção seria mover dados de arquivo fora em um banco de dados de data warehouse que não é utilizado para processamento de transações (OLTP), e em vez disso é usado como a fundação de um banco de dados de processamento analítico (OLAP). Quando chega a hora de informar fora desta dados arquivados, o seu pronto para ir. Se você é cuidadoso sobre como você estruturar os dados neste banco de dados de arquivo, ele deve ser muito fácil para agregar todos os dados em um cubo OLAP, o que torna a relatar fora de que os dados muito mais rápido e mais flexível.

Mas, novamente ... depende se você relatar off os dados ou não, e como longe no tempo que o relatório pode ir.

Answer 3

Ele faz depender de quanto análise será feita em dados passados, mas há uma maneira de manter tudo no banco de dados sem desempenho se tornando um problema.

A solução que vem à mente é particionar as tabelas em questão. Minha empresa tem uma tabela de banco de dados que possui dados particionado por mês, cada um dos quais contêm cerca de 20 milhões de linhas. O particionamento faz usando esses dados muito mais prático do que se foram armazenados em uma única tabela. Agora a restrição única verdadeira é espaço em disco, que é um não-problema dada como barato é nos dias de hoje.

Eu sei, porém, que alguns bancos de dados não suportam particionamento. Se este for o caso, suponho armazenar os dados em um arquivo delimitado seria uma solução adequada.

Answer 4

IMHO, isso depende de quão provável é que o usuário terá de analisar os dados passados. Se é provável, basta criar bons índices e manter todos os dados em seu banco de dados principal.

Se não for, em seguida, solte-o a um TXT. O tempo em que isso acontece deve ser configurável é claro.