QuestDB 10.1 reduz reescrita de dados atrasados e ganha percentis exatos em SQL

O QuestDB mantém cada partição ordenada por tempo. Por isso, um commit com linhas atrasadas para uma partição já gravada sempre exigiu escrever uma cópia nova dela, com as linhas tardias mescladas. Poucos milhares de linhas atrasadas podem custar a reescrita de milhões. Com cairo.o3.partition.merge.append.enabled=true, o commit pega só a fatia da partição afetada, mescla as linhas atrasadas nela e anexa o resultado ao fim dos arquivos de coluna. A partição passa a apontar para a nova cópia da fatia, e as linhas substituídas ficam como espaço morto até uma compactação em segundo plano juntar tudo de novo.

Na demo pública, com o recurso ativo desde 22 de outubro, a escrita caiu de cerca de 440 para cerca de 8 linhas em disco por linha ingerida, em boa parte por causa do refresh de materialized views. A mediana de aplicação de um lote WAL foi de 1,7 ms para 0,6 ms. O custo é espaço em disco temporário. O recurso vem desligado por padrão, e versões anteriores à 10.1 recusam uma tabela que ainda tenha partições merge-append, então o rollback pede preparo. A compactação roda a cada dois minutos em tabelas WAL, sem pausar a ingestão, e novas colunas (deadRows, pieceCount, lastWriteTimestamp) aparecem em table_partitions() e SHOW PARTITIONS.

A release também traz percentile_disc() e percentile_cont() exatos, com vários níveis numa passada e suporte a valores negativos, ao contrário de approx_percentile(). A cláusula SUBSAMPLE seleciona linhas reais do resultado, e a tabela sys.metrics grava cerca de 160 métricas por segundo, com TTL de uma semana. Há ainda GROUP BY paralelo sobre joins e mudanças em HORIZON JOIN que podem alterar resultados existentes. O texto da fonte avisa que esta versão tem mais breaking changes que o normal.

Para quem opera QuestDB com vários produtores ou reconexões que reenviam dados, o ganho está em I/O de disco e em latência até a linha ficar legível. Em troca, é preciso monitorar espaço e planejar o rollback antes de ligar a flag. Quem usa HORIZON JOIN ou aritmética com INT deve ler a lista de breaking changes antes de atualizar. O sys.metrics ajuda a ver a amplificação de escrita antes e depois, mas é histórico de uma instância só; para frotas, Prometheus ou Telegraf continuam fazendo sentido.