Por que reduzimos os chunks do TimescaleDB de 30 para 7 dias

O Warner Music Group reduziu o chunk_time_interval do TimescaleDB de 30 para 7 dias após identificar falhas crônicas na compressão, lentidão em consultas de dados recentes (como 'últimas 24 horas') e custos excessivos em operações de backfill. Essa mudança não é uma exceção, mas segue recomendações oficiais do TimescaleDB: chunks de 7 dias são o padrão recomendado para hypertables com alta ingestão, pois equilibram granularidade de poda (chunk pruning), tempo de compressão/descompressão e uso eficiente de memória cache. Dados reais mostram que chunks de 7 dias comprimidos atingem cerca de 10% do tamanho original, enquanto chunks maiores — embora potencialmente mais compactáveis — geram sobrecarga crítica no I/O e no planejador de consultas, especialmente quando os dados ativos ultrapassam 25% da memória RAM disponível.

A decisão também está alinhada com avanços recentes do TimescaleDB em 2024, como os chunk-skipping indexes para hypertables comprimidas (lançados na versão 2.14), que melhoram em até 7× o desempenho de consultas com filtros de tempo — mas só são eficazes com chunks bem dimensionados. Além disso, chunks menores permitem políticas de retenção mais precisas (ex.: descartar exatamente 7 dias de logs obsoletos) e reduzem o risco de falhas em operações de manutenção, como recompression ou retention policy executadas via drop_chunks().

Essa otimização impacta diretamente a confiabilidade e escalabilidade de aplicações críticas de séries temporais — como sistemas de monitoramento em tempo real, análise de comportamento de usuários e ingestão de eventos de streaming. Para empresas brasileiras que usam TimescaleDB (ex.: fintechs com métricas de transações por segundo ou plataformas de IoT com sensores de telemetria), escolher um chunk_time_interval inadequado pode causar degradação silenciosa: consultas que levavam 200 ms passam para 2 s, processos de backfill consomem 3× mais CPU e o custo de armazenamento cresce exponencialmente devido à ineficiência da compressão. O ajuste para 7 dias não é uma regra universal, mas sim uma resposta técnica fundamentada em benchmarks reais: chunks com 25 milhões de linhas por chunk oferecem o melhor trade-off entre taxa de compressão e velocidade de acesso, conforme validado pela equipe de engenharia do TimescaleDB em estudos publicados em 2024.

Para desenvolvedores e DBAs, essa mudança implica revisão prática nas estratégias de modelagem de hypertables: o comando create_hypertable() deve especificar chunk_time_interval => INTERVAL '7 days', e alterações posteriores exigem set_chunk_time_interval() — que afeta apenas novos chunks, sem bloqueio ou downtime. É essencial monitorar a contagem total de chunks (idealmente entre 100–500 para workloads ativos) e evitar milhares de chunks pequenos, que sobrecarregam o planejador. Ferramentas como timescaledb_information.chunks e métricas do PostgreSQL pg_stat_bgwriter devem ser integradas a dashboards de observabilidade. Em ambientes com alta variação de ingestão (ex.: picos sazonais em plataformas de música), é recomendável usar adaptive_chunking (disponível desde a versão 2.12) ou scripts automatizados que recalibrem o intervalo com base em chunk_size_bytes e rows_per_chunk coletados via hypertable_approximate_row_count().