Como armazenar com eficiência grandes dados de séries temporais?

Preciso armazenar e poder consultar dados de séries temporais de quantidades muito grandes.

As propriedades dos dados são as seguintes:

• número de séries: cerca de 12.000 (doze mil)
• número de pontos de dados, globalmente: cerca de 500.000.000 por mês (quinhentos milhões)
• tipos de valor misto: a maioria dos pontos de dados são valores de ponto flutuante, o restante são cadeias
• período de amostragem: variável entre séries e dentro de uma série
• registros de data e hora: precisão de milissegundos
• período de retenção de dados: vários anos, sem deterioração ou redução da amostragem
• os arquivos de dados precisam ser criados quase em tempo real, mas um atraso razoável (~ 1 hora) é aceitável
• dados passados ​​podem ser reconstruídos, se necessário, mas a um custo elevado
• Às vezes, mas muito raramente, alguns dados anteriores precisam ser atualizados

Propriedades das consultas previstas:

• a maioria das consultas nos dados será baseada em timestamp; variando de um dia a vários meses / anos. Mais de 90% serão consultas nos dados mais recentes

Outros requerimentos:

• a solução deve ser livre como na cerveja grátis e preferencialmente de código aberto

Meu pensamento inicial era usar PyTables / Pandas com arquivos HDF5 como armazenamento de back-end em vez de um banco de dados SQL.

Questões :

1. Supondo que o PyTables / Pandas seja a melhor "rota", seria melhor dividir os dados em vários arquivos HDF, cada um deles em um determinado período de tempo, ou colocar tudo em um único arquivo que se tornaria enorme?

2. Devo preferir o formato fixo ou a tabela? Para mim, o formato fixo parece bom se eu mantiver um arquivo HDF por mês, pois dessa forma uma série inteira provavelmente se encaixa na RAM e posso fatiar na memória sem precisar de um índice de formato de tabela. Estou correcto ?

E se essa não é a melhor abordagem, como devo estruturar esse armazenamento de dados ou quais tecnologias devo considerar? Não sou o primeiro a lidar com o armazenamento de grandes conjuntos de dados de séries temporais. Qual é a abordagem geral para resolver esse desafio?

Outras abordagens que considerei:

• bancos de dados de matriz: eles são ótimos para séries temporais com período de amostragem constante, pois você só precisa armazenar os horários de início e término e o período de amostragem da matriz e, em seguida, apenas os valores na matriz e a indexação são fáceis. Porém, com períodos de amostragem variáveis ​​dentro das próprias séries, preciso manter uma relação de carimbo de data / hora mais próxima - de valor, que, na minha opinião, não é tão adequada para DBMS de matriz.
• banco de dados SQL padrão com registro de data e hora, paramID, valor como colunas, mas por sua natureza, eles solicitam muita E / S de disco para qualquer consulta

Você pode dar uma olhada no carbono e no sussurro , parte do projeto de grafite . O carbono pode lidar com grandes quantidades de dados de séries temporais. No entanto, agora que li os documentos (faz alguns anos desde que o usei), é apenas para dados numéricos. Você disse que também possui dados de sequência, portanto, pode não achar isso útil. No entanto, você poderá obter um pouco de sabedoria sobre como eles são capazes de processar grandes quantidades de dados rapidamente.

Para ter uma idéia de quão bem ela é dimensionada, quando a grafite foi colocada em produção pela primeira vez em Orbitz, ela estava processando 160.000 métricas por minuto .

O InfluxDB é um banco de dados de código aberto escrito em Go. Ele foi escrito especialmente para lidar com dados de séries temporais, e eles publicaram benchmarks mostrando um desempenho muito melhor do que o Cassandra :

O InfluxDB superou o Cassandra em todos os três testes com taxa de transferência de gravação 4.5x maior, usando 10.8x menos espaço em disco e oferecendo tempos de resposta até 168x mais rápidos para consultas testadas.

convém verificar bancos de dados orientados a colunas. Não sei ao certo o que você quer dizer com bancos de dados de matriz, mas com minha abordagem sugerida você pode ter um número dinâmico de valores por período de tempo. Você também pode ter vários valores para o mesmo registro de data e hora. A parte interessante é que, se você tiver valores medidos no mesmo registro de data e hora, poderá salvá-los como colunas adicionais (por exemplo, um sensor que mede temperatura e umidade, no preço de negociação de ações e tamanho de uma negociação, ...). Devido à natureza orientada a colunas, você pode ter tabelas com 100 colunas, mas se sua consulta acessar apenas cinco colunas, o banco de dados lê apenas os dados das cinco colunas.

Escrevi uma série sobre a criação de seu próprio banco de dados de séries temporais. Você pode dar uma olhada:

• Parte 1: https://medium.com/@hellomichibye/column-oriented-database-introduction-part-1-572e5780aebb
• Parte 2: https://medium.com/@hellomichibye/column-oriented-database-draft-part-2-21199a2de18a