Como devo armazenar quantidades extremamente grandes de dados de tráfego para fácil recuperação?

Question

para um sistema de contabilidade de tráfego, preciso armazenar grandes quantidades de conjuntos de dados sobre pacotes de Internet enviados através de nosso roteador gateway (contendo carimbo de data/hora, ID do usuário, IP de destino ou origem, número de bytes, etc.).

Esses dados devem ser armazenados por algum tempo, pelo menos alguns dias.A recuperação fácil também deve ser possível.

Qual é uma boa maneira de fazer isso?Já tenho algumas ideias:

• Crie um arquivo para cada usuário e dia e anexe todos os conjuntos de dados a ele.

  • Vantagem:Provavelmente é muito rápido e os dados são fáceis de encontrar devido a um layout de arquivo consistente.
  • Desvantagem:Não é facilmente possível ver, por ex.todo o tráfego UDP de todos os usuários.

• Use um banco de dados

  • Vantagem:É muito fácil encontrar dados específicos com a consulta SQL correta.
  • Desvantagem:Não tenho certeza se existe um mecanismo de banco de dados que possa lidar com eficiência com uma tabela com possivelmente centenas de milhões de conjuntos de dados.

• Talvez seja possível combinar as duas abordagens:Usando um arquivo de banco de dados SQLite para cada usuário.

  • Vantagem:Seria fácil obter informações para um usuário usando consultas SQL em seu arquivo.
  • Desvantagem:Obter informações gerais ainda seria difícil.

Mas talvez alguém tenha uma ideia muito boa?

Muito obrigado antecipadamente.

Answer 1

Primeiro, pegue O kit de ferramentas de data warehouse antes de fazer qualquer coisa.

Você está fazendo um trabalho de armazenamento de dados e precisa lidar com isso como se fosse um trabalho de armazenamento de dados.Você precisará ler sobre os padrões de design adequados para esse tipo de coisa.

[Observação: Data Warehouse não significa muito grande, caro ou complexo.Significa Star Schema e maneiras inteligentes de lidar com grandes volumes de dados que nunca são atualizados.]

1. Os bancos de dados SQL são lentos, mas essa lentidão é boa para recuperação flexível.

2. O sistema de arquivos é rápido.É péssimo atualizar, mas você não está atualizando, só está acumulando.

Uma abordagem típica de DW para isso é fazer isso.

1. Defina o "Esquema Estrela" para seus dados.Os fatos mensuráveis ​​e os atributos ("dimensões") desses fatos.Seu fato parece ser # de bytes.Todo o resto (endereço, carimbo de data/hora, ID do usuário, etc.) é uma dimensão desse fato.

2. Crie os dados dimensionais em um banco de dados de dimensões mestre.É relativamente pequeno (endereços IP, usuários, dimensão de data, etc.). Cada dimensão terá todos os atributos que você deseja conhecer.Isso cresce, as pessoas estão sempre adicionando atributos às dimensões.

3. Crie um processo de "carregamento" que pegue seus logs, resolva as dimensões (horários, endereços, usuários, etc.) e mescle as chaves de dimensão com as medidas (nº de bytes).Isso pode atualizar a dimensão para adicionar um novo usuário ou um novo endereço.Geralmente, você está lendo linhas de fatos, fazendo pesquisas e escrevendo linhas de fatos que possuem todos os FKs adequados associados a eles.

4. Salve esses arquivos de carregamento no disco.Esses arquivos não são atualizados.Eles apenas se acumulam.Use uma notação simples, como CSV, para que você possa carregá-los em massa facilmente.

Quando alguém quiser fazer análises, construa um datamart para ele.

Para o endereço IP ou período selecionado ou qualquer outro, obtenha todos os fatos relevantes, além dos dados de dimensão mestre associados e carregue em massa um datamart.

Você pode fazer todas as consultas SQL que desejar neste mercado.A maioria das consultas será direcionada para SELECT COUNT(*) e SELECT SUM(*) com vários GROUP BY e HAVING e WHERE cláusulas.

Answer 2

Eu acho que a resposta adequada realmente depende da definição de um "conjunto de dados". Como você menciona em sua pergunta, você está armazenando conjuntos de informações individuais para cada registro; Timestamp, UserID, IP de destino, IP de origem, número de bytes etc.

O SQL Server é perfeitamente capaz de entregar esse tipo de armazenamento de dados com centenas de milhões de registros sem nenhuma dificuldade real. Concedido que esse tipo de registro exigirá um bom hardware para lidar com isso, mas não deve ser muito complexo.

Qualquer outra solução, na minha opinião, dificultará os relatórios e, pelo que é um requisito importante.

Answer 3

Então você está em um dos casos em que você tem Muito de Mais atividades de gravação do que lê, você deseja que suas gravações não o bloqueem e deseja que suas leituras sejam "razoavelmente rápidas", mas não críticas. É um caso de uso típico de inteligência de negócios.

Você provavelmente deve usar um banco de dados e armazenar seus dados como um esquema "desnormalizado" para evitar junções complexas e várias inserções para cada registro. Pense na sua tabela como um enorme arquivo de log.

Nesse caso, alguns dos bancos de dados NoSQL "novos e sofisticados" são provavelmente o que você está procurando: eles fornecem restrições de ácido relaxado, que você não deve se importar aqui (em caso de colisão, você pode perder as últimas linhas de sua log), mas eles têm um desempenho muito melhor para a inserção, porque não precisam sincronizar os periódicos no disco em cada transação.