A Momentic, plataforma de testes de software baseada em IA, redesenhou seu sistema de cache para suportar mais de 2 milhões de consultas por dia em 20 bilhões de registros, mantendo latência média de 250 ms. A transição do PostgreSQL para o ClickHouse foi o motor dessa escalabilidade.
- ClickHouse substituiu PostgreSQL em cache de alta carga, eliminando contenção de locks.
- Índices esparsos e chave primária bem projetada garantem buscas em 1-2 partes de dados na maioria dos casos.
- Materialized views resolvem picos em branches principais, evitando leitura de todas as partições.
- Uso de ReplacingMergeTree reduziu lógica de três consultas para apenas INSERTs, dispensando Redis.
- Migração segura com shadow queries e rollback mantendo escritas duplas.
O desafio: PostgreSQL e a concorrência de alta escrita e leitura
No início, a tabela de cache da Momentic armazenava cerca de 80 mil entradas. Com o crescimento acelerado da plataforma, o volume saltou para 1 bilhão de registros, expondo as limitações do PostgreSQL.
"Estávamos enfrentando tanto uso elevado de recursos quanto contenção de locks entre consultas simultâneas de leitura e escrita no cache", relatou a equipe. A situação piorava à medida que a tabela crescia.
Quando a decisão de migrar foi tomada, o sistema processava aproximadamente 600 mil consultas ao cache por dia, com exigência de latência inferior a um segundo.
Por que o ClickHouse? Índices esparsos e eficiência em escala
O principal diferencial arquitetônico do ClickHouse sobre o PostgreSQL está nos índices primários esparsos. Enquanto o PostgreSQL utiliza índices B‑tree, cujo custo de consulta tende a crescer com o volume de dados, o ClickHouse consegue restringir buscas a um pequeno número de “grânulos” quando os valores da chave são conhecidos.
A chave primária do ClickHouse, cuidadosamente projetada, incluiu ID do teste, ID da etapa, versão da Momentic, branch do Git e timestamp do commit. Com isso, em 90% dos casos (branches de feature), as consultas localizavam os dados percorrendo apenas 1 ou 2 partes de dados, mantendo o desempenho previsível.
O problema das branches principais e a solução com materialized views
Em branches principais (main), o número de entradas a varrer podia ser enorme. "Algumas consultas acabavam lendo quase todas as partes de dados, gerando picos de uso de memória e operações de disco", explicou o time.
Para contornar essa exceção, a Momentic recorreu às materialized views do ClickHouse. Elas pré‑calculam os timestamps de commit disponíveis por ID de teste, permitindo que a consulta principal acesse diretamente a parte de dados correta, sem varreduras desnecessárias.
Simplificando consultas e eliminando o Redis com ReplacingMergeTree
Outra mudança significativa foi a redução do número de consultas. No PostgreSQL, a lógica exigia três operações: SELECT para obter caches, INSERT para renovar TTL dos caches usados e novo INSERT dos caches gerados após a execução dos testes. Esse padrão não se adaptava bem ao ClickHouse.
A equipe substituiu essa sequência por um fluxo baseado apenas em INSERTS com o mecanismo ReplacingMergeTree. O novo processo funciona assim:
INSERT dos caches que devem ter o TTL estendido (marcando a versão mais recente).
INSERT dos caches recém‑gerados.
O ClickHouse trata a deduplicação de forma assíncrona, mantendo apenas a versão mais recente de cada chave.
Essa simplificação eliminou completamente a camada de Redis, que já agregava pouco valor devido à alta cardinalidade das chaves de cache.
- INSERT dos caches com TTL estendido
- INSERT dos novos caches
- ClickHouse deduplica assincronamente
Estratégia de migração: shadow queries e rollback seguro
A transição foi gradual e segura. A Momentic operou os dois bancos em paralelo, duplicando todas as escritas para PostgreSQL e ClickHouse. O tráfego de produção continuou sendo servido pelo PostgreSQL, enquanto o ClickHouse era consultado em modo “sombra” (shadow queries), com os resultados sendo comparados para garantir consistência.
Mesmo após o corte, as escritas duplas foram mantidas por um período para permitir rollback imediato em caso de qualquer problema. Essa abordagem garantiu uma migração sem interrupções ou perda de dados.
Resultados e próximos passos
Com a nova arquitetura, a Momentic escalou o cache para 20 bilhões de entradas, processa mais de 2 milhões de consultas por dia e mantém latência média de 250 ms. A eliminação do Redis reduziu a complexidade operacional e os custos.
Para profissionais de infraestrutura no Brasil, o caso mostra que sistemas de cache baseados exclusivamente em ClickHouse podem substituir arquiteturas que combinam PostgreSQL e Redis, especialmente quando a cardinalidade das chaves é alta e a atualização é frequente. Grandes empresas brasileiras de tecnologia com cargas similares podem se beneficiar dessa abordagem.
| Característica | PostgreSQL | ClickHouse |
|---|---|---|
| Tipo de índice | B‑tree | Esparso (grânulos) |
| Escalabilidade de consulta | Cresce com o tamanho da tabela | Constante quando a chave é conhecida |
| Concorrência leitura/escrita | Suscetível a contenção de lock | Otimizado para leitura pesada |
| Deduplicação | Via UNIQUE / ON CONFLICT | Assíncrono com ReplacingMergeTree |
| Camada de cache adicional | Redis frequentemente necessário | Pode eliminar Redis |
Arraste para o lado para ver toda a tabela.
Perguntas Frequentes (FAQ)
Qual a principal vantagem do ClickHouse sobre PostgreSQL para caching?
O ClickHouse utiliza índices esparsos que permitem localizar dados com número constante de operações, independentemente do tamanho da tabela, enquanto o PostgreSQL com B‑tree sofre degradação proporcional ao volume de dados.
O que é ReplacingMergeTree e como elimina a necessidade de Redis?
É um mecanismo de tabela do ClickHouse que deduplica assincronamente registros com a mesma chave de ordenação, mantendo apenas a versão mais recente. Isso permite renovar TTLs com simples INSERTs, eliminando operações de SELECT e a necessidade de um cache externo como Redis.
Como a Momentic garantiu segurança na migração?
Duplicou todas as escritas para PostgreSQL e ClickHouse, executou shadow queries comparando resultados e migrou o tráfego gradualmente. Manteve também as escritas duplas pós‑migração para permitir rollback rápido.
O ClickHouse substitui totalmente o PostgreSQL?
Não. Cada um tem seu nicho. O ClickHouse é excelente para analytics e cargas de leitura pesada com dados colunares, mas o PostgreSQL ainda é a escolha padrão para workloads transacionais (OLTP) e quando se exige consistência forte em tempo real.