Banco de dados de esquema Projeto - Dicas para melhorar a capacidade de arquivo?

Question

Eu estou projetando uma tabela no banco de dados que irá armazenar as entradas de log da aplicação. Existem algumas coisas que está me fazendo pensar sobre este projeto mais do que o habitual.

• No entanto, estas entradas de log será usado em tempo de execução pelo sistema de tomar decisões para que eles precisam de ser relativamente rápido acesso.
• Eles também têm o problema é que não vai ser muitos deles (12,5 milhões adicionados por mês é a minha estimativa).
• Não mais do que os últimos 30 a 45 dias precisa, no máximo, para o processamento de decisão.
• Eu preciso manter todos eles por muito mais tempo do que 45 dias para apoio e questões jurídicas, provavelmente pelo menos 2 anos.
• O design da tabela é bastante simples, todos os tipos simples (sem blobs ou qualquer coisa), sempre que possível irá utilizar o motor de banco de dados para colocar nos dados padrão, no máximo, uma chave estrangeira.
• Se faz alguma diferença o banco de dados será Microsoft SQL Server 2005.

O que eu estava pensando é tê-los gravado em uma tabela ao vivo / banco de dados e, em seguida, usando uma solução de movimento ETL "velhos" entradas para uma tabela de arquivo / banco de dados -. Que é grande e em hardware mais lento

A minha pergunta é fazer você souber de alguma dicas, truques ou sugestões para o projeto de banco de dados / tabela para garantir que isso funciona tão bem quanto possível? Além disso, se você acha que é uma má idéia por favor me avise, eo que você acha que uma ideia melhor seria.

Answer 1

Alguns bancos de dados oferecem "partições" (Oracle, por exemplo). Uma partição é como um ponto de vista que recolhe várias tabelas com uma definição idêntica em um. Você pode definir critérios que tipo novos dados em tabelas diferentes (por exemplo, o mês ou semana de ano% 6).

Do ponto de vista do usuário, esta é apenas uma mesa. A partir do banco de dados PoV, é várias mesas independentes, para que possa executar comandos de tabela cheia (como truncado, gota, excluir da tabela (sem uma condição), carga / descarga, etc.) contra eles de forma eficiente.

Se você não pode ter uma partição, você obtém um efeito semelhante com vistas. Neste caso, você pode coletar várias tabelas em uma única exibição e redefinir este ponto de vista, digamos, uma vez por mês para "livre" uma tabela com dados antigos do resto. Agora, você eficientemente possível arquivar esta tabela, limpá-la e instalá-la à vista quando o grande trabalho tem sido feito. Isso deve ajudar muito a melhorar o desempenho.

[EDIT] servidor SQL 2005 em diante (Enterprise Edition) suporta partições. Graças à Mitch Wheat

Answer 2

Big mesas desacelerar rapidamente, e é uma grande sobrecarga de desempenho para uso ETL aos dados de puxar com base na data, a partir de uma grande mesa e, em seguida, excluir as linhas antigas. A resposta para isso é usar várias tabelas - provavelmente 1 mesa / mês com base em suas figuras. Claro que você vai precisar de alguma lógica para gerar os nomes de tabela dentro de suas consultas.

Eu concordo com o uso de disparadores para preencher a tabela 'CurrentMonthAudit', no final do mês, você pode, então, mudar o nome que a tabela para MonthAuditYYYYMM. Movendo tabelas velho fora de seu principal servidor usando ETL então será fácil, e cada uma de suas tabelas será administrável. Confie em mim isso é muito melhor do que a tentar gerir uma única tabela com aproximadamente 250 milhões de linhas.

Answer 3

Sua primeira decisão bom é manter tudo o mais simples possível.

Eu tive sorte com o seu padrão de um arquivo de log de transações só de escrita simples, onde os registros são apenas previsto em ordem cronológica. Então você tem várias opções para mudar a dados antigos. Mesmo tendo tabelas diferentes mensais é administrável consulta-wise, enquanto você manter a simplicidade em mente. Se você tem qualquer tipo de replicação em operação, suas tabelas replicadas podem ser rolados para fora e servir como o arquivo. Então comece com uma tabela vazia fresco no primeiro dia de cada mês.

Normalmente eu estremecer com as conseqüências de design relacionais de fazer algo assim, mas eu descobri que somente gravação tabelas de log cronológicos são uma exceção aos padrões de projeto usuais, pelas razões que você está lidando aqui.

Mas ficar longe de gatilhos. O mais longe possível. A solução mais simples é uma tabela primária do tipo que estamos falando aqui, com um mecanismo de replicação simples robusto off-the-shelf vez comprovada.

(BTW - grandes mesas não abrandar rapidamente se eles são bem desenhados -. Eles diminuem a velocidade lentamente)

Answer 4

Se você não precisa procurar os registos recentes, não há outra opção: Não use um banco de dados em tudo. Em vez disso, escrever a informação de log para um arquivo e rode o nome do arquivo todas as noites. Quando um arquivo foi escrito, você pode, então, iniciar um trabalho de fundo para importar os dados diretamente no banco de dados de arquivo.

Bases de dados nem sempre são a melhor opção, especialmente para arquivos de log:)