ClickHouse Lightweight Deletes: Mitigando Read Amplification

Quando o read amplification por deletes leves no ClickHouse disparou um aumento de 400% nas requisições S3 GET durante o horário de pico, a latência p99 de nossas consultas degradou de 120ms para 4,2 segundos. Painéis analíticos apresentaram timeout em três ferramentas executivas críticas, violando nosso SLO de disponibilidade de 99,9% e ultrapassando os orçamentos de computação. A causa raiz não foi bloqueio de banco de dados ou escassez de CPU, mas o acúmulo descontrolado de arquivos de máscara de deleção em partes de dados MergeTree com alta taxa de churn.

Para resolver este incidente sem incorrer em custos massivos de reescrita, foi necessário reavaliar como as mutações em nível de linha interagem com a execução vetorial de consultas, mesclagens em segundo plano e camadas de cache em storage de objetos. Este artigo analisa a mecânica de falha de deletes leves no ClickHouse, quantifica seu impacto no I/O de disco e apresenta uma estrutura operacional para ajustar background merges, controlar filas de mutação e aplicar políticas rigorosas de ciclo de vida de dados.

A Anatomia dos Deletes Leves no ClickHouse

Historicamente, remover registros do ClickHouse exigia mutações explícitas do tipo ALTER TABLE ... DELETE. Essas mutações tradicionais reescrevem partes inteiras de dados no disco. Embora esse design garanta compactação colunar limpa e velocidades de varredura previsíveis após a conclusão, cargas de trabalho com muitas mutações consomem I/O substancial, bloqueiam operações na tabela e causam alto write amplification.

Para mitigar o custo computacional de reescrever partes de dados, o ClickHouse introduziu Deletes Leves (DELETE FROM table WHERE ...). Em vez de reconstruir partes imediatamente, os deletes leves marcam as linhas como removidas gerando um pequeno arquivo .prow contendo um bitmap das linhas deletadas para cada parte afetada. Durante a execução da consulta, o motor lê esses bitmaps e filtra as linhas correspondentes antes de retornar os resultados.

Contudo, essa otimização transfere o custo de reescrita para o momento da consulta. Quando tabelas sofrem milhares de remoções esporádicas em milhões de partes, cada consulta SELECT precisa carregar, analisar e aplicar milhares de máscaras simultaneamente. Em topologias de nuvem onde as partes residem no AWS S3 ou Google Cloud Storage, ler múltiplos arquivos .prow minúsculos converte leituras sequenciais de bloco em buscas pontuais fragmentadas, disparando o efeito de ClickHouse lightweight delete read amplification.

Quantificando o Acúmulo de Máscaras e a Degradação de Consultas

Durante o incidente em produção, os painéis de monitoramento indicavam consumo normal de CPU e memória nos nós do cluster ClickHouse. No entanto, o tempo de espera de I/O na camada de proxy do object storage disparou. Consultando o catálogo do sistema, observamos que certas partes de dados continham mais de 50 arquivos de máscara distintos, enquanto os background merges estavam atrasados em relação à taxa de ingestão.

Para diagnosticar a gravidade do read amplification através das tabelas do sistema, avaliamos as métricas de mutação por parte de dados:

SELECT
    table,
    partition,
    count() AS total_parts,
    sum(delete_rows) AS total_deleted_rows,
    sum(rows) AS total_active_rows,
    round(sum(delete_rows) / sum(rows + delete_rows) * 100, 2) AS deleted_percentage,
    sum(bytes_on_disk) / 1024 / 1024 / 1024 AS size_gb
FROM system.parts
WHERE active = 1 AND table = 'user_events_stream'
GROUP BY table, partition
ORDER BY total_deleted_rows DESC;

Quando a métrica deleted_percentage ultrapassa 15% em centenas de pequenas partes, o desempenho das consultas degrada exponencialmente. Em nossos benchmarks, escanear 100 GB de partes limpas levou 140 ms, enquanto escanear os mesmos 100 GB com 12% de linhas deletadas distribuídas em 4.000 partes exigiu 3,8 segundos. Cada thread de consulta passou até 80% do tempo resolvendo máscaras de bitmap em vez de executar kernels de agregação vetorial SIMD.

Para equipes que operam ingestão contínua com atualizações em tempo real via Kafka Debezium dbt, remoções soft-delete não monitoradas saturam rapidamente o subsistema de armazenamento. Se ignorado, esse perfil de carga degrada motores analíticos muito mais rápido do que a evolução clássica de esquema ou fragmentação de índices, conforme detalhado no nosso ClickHouse MergeTree Primary Key Index Tuning Guide.

Mitigações Arquiteturais: Background Merges e Compactação

O método mais direto para eliminar o read amplification por deletes leves é forçar o ClickHouse a consolidar arquivos de máscara em reescritas físicas de dados durante os processos normais de merge em segundo plano. O ClickHouse oferece configurações dedicadas para controlar a agressividade com que linhas deletadas são expurgadas durante a consolidação de partes.

Por padrão, os merges combinam partes menores em partes maiores com base no tamanho e idade, mas podem adiar o expurgo de linhas deletadas se os recursos de computação estiverem restritos. Ajustamos as configurações do cluster para priorizar a limpeza de máscaras e limitar a vida útil dos bitmaps de deleção:

ALTER TABLE user_events_stream MODIFY SETTING
    vertical_merge_algorithm_min_rows_to_activate = 1000000,
    vertical_merge_algorithm_min_columns_to_activate = 10,
    min_merge_bytes_to_use_direct_io = 1073741824,
    lightweight_deletes_sync = 1;

A opção lightweight_deletes_sync = 1 força as operações de deleção leve a aguardarem a confirmação das máscaras em todas as réplicas. Além disso, o ajuste no seletor da árvore de mesclagem garante que partes com alta proporção de linhas deletadas recebam maior prioridade na fila de merge.

Para limpar partições fragmentadas sem executar mutações bloqueantes em toda a tabela, engenheiros de dados podem emitir comandos de otimização explícitos durante janelas de manutenção de baixo tráfego:

OPTIMIZE TABLE user_events_stream PARTITION '2026-03' FINAL DEDUPLICATE;

Embora o comando OPTIMIZE ... FINAL reescreva todas as partes da partição especificada e expurgue permanentemente as linhas deletadas, executá-lo de forma global em tabelas de escala de petabytes pode esgotar o orçamento de I/O. Portanto, scripts de automação devem focar dinamicamente apenas nas partições cujas métricas de linhas deletadas violem os limites operacionais estabelecidos.

Integrando Observabilidade na Governança de Dados

Prevenir a degradação de consultas exige incorporar métricas de mutação em frameworks de qualidade de dados corporativos. Plataformas como nosso Data Observability Platform monitoram o frescor dos pipelines, anomalias e saúde do armazenamento antes que consultas lentas violem SLAs operacionais.

Ao projetar sistemas analíticos confiáveis, gestores de engenharia devem tratar a profundidade da fila de mutações e a densidade de máscaras como indicadores primários de saúde da plataforma. Conforme destacado em relatórios recentes de infraestrutura como InfoQ Airbnb Rebuilt Alert Development, o cansaço de alertas frequentemente decorre do monitoramento de sintomas secundários em vez dos gargalos técnicos primários.

Implementamos alertas automáticos no Prometheus baseados em métricas de sistema do ClickHouse:

1. Contagem da Fila de Mutações Pendentes: Dispara um alerta quando SELECT count() FROM system.mutations WHERE is_done = 0 permanece maior que 20 por mais de 15 minutos.
2. Densidade de Máscara por Parte: Dispara um aviso quando qualquer partição contiver partes ativas onde linhas deletadas excedam 20% do total de linhas.
3. Fator de Read Amplification no Storage: Monitora a razão entre bytes solicitados ao S3 e bytes processados pelo vetor de execução da consulta.

Essas métricas proativas permitem que equipes de engenharia de dados isolem a degradação do armazenamento antes que os painéis executivos falhem.

Estratégias de Armazenamento Híbrido para Cargas de Alto Churn

Para tabelas sujeitas a atualizações e remoções contínuas—como solicitações de conformidade LGPD/GDPR, atualizações de estado de sessão ou espelhamento CDC transacional—depender exclusivamente de deletes leves é um padrão arquitetural insustentável. Em vez disso, arquitetos de dados devem implantar uma estratégia de ingestão híbrida combinando tabelas de staging, ReplacingMergeTree e mutações em lote periódicas.

Neste padrão híbrido:

• Eventos CDC de alta frequência chegam a uma tabela de staging operacional configurada com o motor ReplacingMergeTree. A desduplicação ocorre nativamente durante os background merges com base em colunas de versão ou carimbo de data/hora.
• Camadas analíticas de consumo utilizam materializações desduplicadas ou visualizações unificadas que consultam o estado ativo não deletado usando cláusulas FINAL parametrizadas ou filtros de versão explícitos.
• Deletes leves ficam estritamente reservados para remoções ad-hoc de conformidade, e não para atualizações operacionais de alta vazão.

Ao desacoplar remoções transacionais de linhas do armazenamento analítico de longo prazo, as equipes eliminam o read amplification em disco, protegem a capacidade de processamento vetorial e mantêm tempos de resposta sub-segundo mesmo sob pesadas cargas de ingestão.