Pergunta

Ok, aqui está o cenário.Eu tenho um utilitário que processa toneladas de registros e insere as informações no banco de dados de acordo.

Funciona nesses registros em lotes multithread.Cada lote grava no mesmo arquivo de log para criar um rastreamento de fluxo de trabalho para cada registro.Potencialmente, poderíamos fazer cerca de um milhão de gravações de log por dia.

Esse log deve ser feito em um banco de dados residente em outro servidor?Considerações:

  1. A desvantagem óbvia de vários threads gravando no mesmo arquivo de log é que as mensagens de log são embaralhadas entre si.No banco de dados, eles podem ser agrupados por ID de lote.
  2. Desempenho – o que retardaria mais o processamento em lote?gravar em um arquivo local ou enviar dados de log para um banco de dados em outro servidor na mesma rede.Teoricamente, o arquivo de log é mais rápido, mas há alguma pegadinha aqui?

Existem otimizações que podem ser feitas em qualquer abordagem?

Obrigado.

Foi útil?

Solução

Eu apoio as outras respostas aqui, depende do que você está fazendo com os dados.

Temos dois cenários aqui:

  1. A maior parte do registro é para um banco de dados, já que os usuários administradores dos produtos que construímos precisam ser capazes de visualizá-los em seu pequeno aplicativo com todos os recursos.

  2. Registramos todos os nossos diagnósticos e informações de depuração em um arquivo.Não precisamos realmente "embelezá-lo" e, TBH, nem sempre precisamos disso, então apenas registramos e arquivamos a maior parte.

Eu diria que se o usuário estiver fazendo alguma coisa com ele, registre-se no banco de dados; se for para você, um arquivo provavelmente será suficiente.

Outras dicas

A questão interessante, caso você decida fazer logon no banco de dados, é onde você registra erros de conexão com o banco de dados?

Se estou registrando em um banco de dados, sempre tenho um local de log secundário (arquivo, log de eventos, etc.), caso haja erros de comunicação.Isso realmente torna mais fácil diagnosticar problemas posteriormente.

Uma coisa que vem à mente é que você pode fazer com que cada thread grave em seu próprio arquivo de log e, em seguida, execute uma execução diária em lote para combiná-los.

Se você estiver registrando no banco de dados, provavelmente precisará fazer alguns ajustes e otimização, especialmente se o banco de dados estiver na rede.No mínimo, você precisará reutilizar as conexões do banco de dados.

Além disso, você tem alguma necessidade específica de ter o banco de dados de log?Se tudo que você precisa é de um "grep", não acho que você ganhe muito fazendo login no banco de dados.

Não tenho certeza se isso ajuda, mas também há um utilitário chamado LogParser da Microsoft que você supostamente pode usar para analisar arquivos de log baseados em texto e usá-los como se fossem um banco de dados.A partir do site:

O Log Parser é uma ferramenta poderosa e versátil que fornece acesso universal à consulta a dados baseados em texto, como arquivos de log, arquivos XML e arquivos CSV, bem como fontes de dados principais no sistema operacional Windows®, como o log de eventos, o registro, o sistema de arquivos e o Active Directory®.Você diz ao LOG Parser que você precisa e como deseja processado.Os resultados da sua consulta podem ser formatado sob medida na saída baseada em texto, ou podem persistir para mais destinos especiais como SQL, SYSLOG ou um gráfico.A maioria dos softwares é projetada para realizar um número limitado de tarefas específicas.O Log Parser é diferente...o número de maneiras que ele pode ser usado é limitado apenas pelas necessidades e imaginação do usuário.O mundo é o seu banco de dados com Log Parser.

Eu não usei o programa, mas parece bastante interessante!

Ou que tal entrar em uma fila?Dessa forma, você pode trocar os pollers sempre que quiser fazer login em coisas diferentes.Isso facilita muito a rolagem e o arquivamento de arquivos de log.Também é bom porque você pode adicionar pollers que registram coisas diferentes, por exemplo:

  • um poller que procura mensagens de erro e as publica em sua conta do FogBugz
  • um poller que procura violações de acesso ('x tentou acessar /foo/y/bar.html') em um arquivo de 'tentativas de hacking'
  • etc.

Banco de dados - já que você mencionou vários threads.A sincronização e a recuperação filtrada são os motivos da minha resposta.
Veja se você tem algum problema de desempenho antes de decidir mudar para arquivos
"Knut:A otimização prematura é a raiz de todos os males" Não fui mais longe naquele livro...:)

Existem maneiras de contornar as limitações do registro de arquivos.

Você sempre pode iniciar cada entrada de log com algum tipo de ID de thread e obter os IDs de thread individuais.Ou um arquivo de log diferente para cada thread.

Já entrei no banco de dados no passado, em um thread separado com prioridade mais baixa.Devo dizer que a possibilidade de consulta é muito valiosa quando você está tentando descobrir o que deu errado.

Que tal fazer login em um arquivo de banco de dados, digamos, um banco de dados SQLite?Acho que ele pode lidar com gravações multithread - embora isso também possa ter suas próprias sobrecargas de desempenho.

Acho que depende muito do que você fará com os arquivos de log posteriormente.

Das duas operações, gravar no arquivo de log será mais rápido - especialmente quando você sugere gravar em um banco de dados em outro servidor.

No entanto, se você estiver tentando processar e pesquisar os arquivos de log regularmente, o melhor lugar para fazer isso seria um banco de dados.

Se você usar uma estrutura de registro como o log4net, eles geralmente fornecem maneiras simples, baseadas em arquivos de configuração, de redirecionar a entrada para um arquivo ou banco de dados.

Gosto da resposta do Caio.Coloque todas as instruções de log em uma fila threadsafe e processe-as a partir daí.Para o banco de dados, você pode agrupá-los em lote, digamos 100 instruções de log em um lote, e para o arquivo, você pode simplesmente transmiti-los para o arquivo à medida que entram na fila.

Arquivo ou banco de dados?Como muitos outros dizem;depende de para que você precisa do arquivo de log.

Licenciado em: CC-BY-SA com atribuição
Não afiliado a StackOverflow
scroll top