Séries temporais

O problema: dados que só crescem

Mil sensores mandando uma medição por minuto são 1,44 milhão de linhas por dia, meio bilhão por ano. Métricas de servidores, cliques, preços e posições de veículos têm o mesmo formato: um carimbo de tempo, o que foi medido e o valor.

Esse tipo de dado, a série temporal, tem características próprias:

Um banco relacional comum guarda séries temporais, mas três operações ficam caras com o volume: apagar o que é antigo, guardar com eficiência e agregar intervalos longos. Os bancos de séries temporais atacam essas três.

Os testes desta página usaram o TimescaleDB 2.32, uma extensão do PostgreSQL 17, comparando uma tabela comum com uma hipertabela do TimescaleDB, com os mesmos dados: 1.000 sensores, uma medição por minuto, 10 dias. São 14,4 milhões de linhas.

Particionar pelo tempo

A hipertabela parece uma tabela comum para quem consulta, mas é dividida em pedaços (chunks) por intervalo de tempo, um por dia no teste. Cada pedaço é uma tabela própria, com os próprios índices. As consultas de um intervalo só leem os pedaços daquele intervalo.

A diferença na consulta foi moderada. Onde o particionamento muda tudo é na hora de apagar.

Apagar o que é antigo

Uma política comum: guardar o minuto a minuto por 7 dias. Apagamos os 3 primeiros dias dos 10, 4,3 milhões de linhas:

O DELETE marca cada linha como apagada, gera log para todas elas e deixa o espaço para ser reaproveitado depois. O arquivo da tabela não diminui sem um VACUUM FULL, que trava a tabela inteira. O drop_chunks descarta os pedaços inteiros, como apagar arquivos: rápido, e o espaço volta na hora. Uma política de retenção roda isso sozinha, todos os dias.

Comprimir o que é antigo

As medições de um mesmo sensor, em ordem de tempo, são muito parecidas entre si. O TimescaleDB converte os pedaços antigos para um formato por coluna, agrupado por sensor, como os bancos colunares:

Catorze vezes menos espaço, em 3,9 segundos de compressão. As consultas continuaram rápidas sobre os pedaços comprimidos: a média por hora de todos os sensores num dia comprimido levou 128 ms, e a de um sensor em 3 dias, 1,4 ms. A troca é que dados comprimidos são mais caros de alterar, o que combina com séries temporais, que quase não mudam.

Resumos prontos

O painel mostra a média por hora dos últimos 30 dias. Calcular isso a partir do minuto a minuto, a cada vez que alguém abre o painel, é refazer o mesmo trabalho. Um resumo contínuo (continuous aggregate) guarda as médias por hora já calculadas e as atualiza conforme os dados chegam:

As médias conferiram até a sexta casa decimal. O teste mostrou um detalhe importante: uma medição gravada depois da criação do resumo não apareceu nele até a atualização seguinte. Na versão testada, os resumos mostram só o que já foi materializado (materialized_only), e uma política de atualização periódica é que traz os dados novos. Depois de uma atualização manual, a medição apareceu.

Gravar em lotes

Séries temporais chegam aos milhares por segundo, e o custo de cada gravação individual pesa:

Mais de 200 vezes mais rápido. A aplicação junta as medições por alguns segundos ou por quantidade, e grava o lote de uma vez, como mostra a Implementação.

Por que isso importa quando a IA escreve o código

Um assistente que grava medições costuma tratar a série temporal como um cadastro:

• Um INSERT por medição, confirmado sozinho, a cada leitura recebida.
• Retenção com DELETE diário em tabelas enormes, sem particionamento.
• Painéis que recalculam médias de milhões de linhas a cada carregamento.
• Nenhuma compressão, e o disco crescendo sem limite.
• Carimbos de tempo sem fuso, ou com o horário do servidor em vez do horário da medição.
• Rótulos com valores ilimitados (o identificador de cada requisição) em bancos de métricas, que explodem em número de séries.

O próximo nível compara os bancos de séries temporais e as decisões de retenção, resumo e cardinalidade.