Para relatórios mais rápidos e análise de desempenho, queremos inserir os logs do nosso servidor da Web no Sql Server. Isso nos permitirá ver padrões de tráfego, problemas e lentidão quase em tempo real.
Temos um daemon que escuta eventos de solicitação/resposta de nosso balanceador de carga e inserções em massa no banco de dados.
No entanto, obtemos cerca de 1 GB de logs por dia e só precisamos manter cerca de uma semana (pelo menos nesta forma bruta).
Qual é a melhor maneira de armazenar esses dados e a melhor maneira de excluir entradas antigas?
Falamos sobre armazenar os dados de cada dia em sua própria tabela, por exemplo Log_2011_04_07, teria todas as entradas para aquele dia e, em seguida, descartar a tabela mais antiga. Uma exibição pode ser criada para abranger todas as tabelas diárias para facilitar a consulta. O é viável?
Você deve olhar para o particionamento.
http://technet.microsoft.com/en-us/library/dd578580%28SQL.100%29.aspx
O legal do particionamento é que você tem apenas um nome de tabela (em oposição à abordagem de várias tabelas), portanto, suas instruções de inserção permanecem estáticas. Ele funciona com todos os aplicativos - é totalmente transparente para consultas. Você também não precisa se preocupar com o que acontecerá se acabar com diferentes índices ou estatísticas em cada uma das tabelas.
Você cria uma função de partição que decide como dividir a tabela em várias tabelas por trás da cena. A função só pode receber um parâmetro/campo de entrada e, no seu caso, seria um campo de data. A função pode dividir a tabela por data, semana, mês ou ano - no seu caso, você deseja data, período de 24 horas.
Em seguida, crie um trabalho do SQL Server Agent que usa T-SQL para trocar a última partição todos os dias. A exclusão se torna uma operação de metadados e é extremamente rápida. Troque a partição e remova a antiga.
Há 6 anos, desenvolvemos um produto de registro de estatísticas da web que nos permite rastrear cada clique da visita de um usuário.
O que fizemos foi registrar cada visita conforme você escreveu e fazer com que o daemon agendado analise os logs e normalize os dados para uma pesquisa posterior posterior. Assim que os dados/registros foram analisados, eles foram removidos para manter a estrutura de dados baixa.
Para nossa próxima versão do produto, distribuiremos os coletores em massa separadamente nos sites e, em seguida, usaremos o daemon para coletar os dados e limpá-los posteriormente, emitindo comandos para o serviço em massa.
Desta forma, podemos lidar com uma "manutenção programada" sem perder dados.
Com relação ao problema de limpeza no servidor central, nosso plano atual é adicionar "carimbos de data/hora" para poder arquivar dados após, por exemplo. 3 meses.
Pensamos nisso como texturas MIP-MAP em jogos/renderização 3D. Quanto mais perto você chega, mais dados detalhados, quanto mais longe, mais "agrupados" e menos detalhados.
Portanto, no dia a dia, podemos observar os padrões dos visitantes, mas depois de 3 meses esses dados não são realmente relevantes e os compactamos em menos detalhes.
Ainda não decidimos se vamos dividir o banco de dados em partes para manter o "nível de detalhe" separado pr. base de dados. Mas podemos, pois há alguns problemas de nomeação se armazenarmos níveis diferentes no mesmo banco de dados.
Espero que você possa usar isso para alguma coisa? Não posso fornecer um código de exemplo como parte do produto de nossa empresa.
Crie outra tabela Daily_tables com duas colunas: Table_name e Date_table_created. Em seu código que cria uma nova tabela diária (que carrega os logs da web), adicione outra entrada para preencher a tabela Daily_tables com o nome da tabela criada e o carimbo de data/hora (data atual). Crie um trabalho de agente SQL que executará um script TSQL toda semana. O TSQL deve descartar todos os nomes de tabelas (Table_name) de Daily_tables com um carimbo de data/hora Date_table_created com mais de 7 dias.
Espero que isto seja o que você estava procurando :)