Bolna migra do BigQuery para ClickHouse, reduzindo custos em 6x e otimizando disponibilidade de dados
Aprofundamento CEVIU
Aprofundamento
A migração da Bolna do BigQuery para o ClickHouse, que resultou em uma redução de 6 vezes nos custos e melhoria expressiva na disponibilidade de dados, mostra como decisões arquiteturais impactam diretamente a engenharia de plataformas. O problema inicial era duplo: custos crescentes no BigQuery, impulsionados por operações de MERGE que varriam tabelas não particionadas para pequenas atualizações, e uma latência de 5 a 15 minutos na entrega dos dados analíticos.
A solução envolveu a realocação da pipeline de dados para PostgreSQL, ClickPipes (baseado em PeerDB) e ClickHouse Cloud. Técnicas como o uso de ReplacingMergeTree no ClickHouse ajudaram na deduplicação. Desafios específicos foram superados: queries diretas com FINAL causavam picos de memória, resolvidos com views materializadas e perfis de usuário com limites de recursos. Para dados JSONB TOASTed ausentes ou antigos, a Bolna configurou REPLICA IDENTITY FULL no PostgreSQL, garantindo que o WAL incluísse a linha completa. A maior economia, porém, veio da camada de aplicação, ao reduzir o volume de CDC (Change Data Capture), escrevendo apenas o estado final das chamadas, não cada atualização intermediária. Essa abordagem evidencia a importância de otimizar a fonte de dados para um pipeline eficiente.
Por que isso importa
Para engenheiros de plataforma e equipes de DevOps, o caso da Bolna sublinha a necessidade de uma visão holística da stack de dados. Otimizar custos não se resume a trocar um banco de dados por outro; é preciso entender os padrões de acesso e escrita da aplicação. A experiência da Bolna mostra que ajustar a forma como a aplicação interage com o banco de dados (escrevendo apenas o estado final) pode ser mais impactante que a otimização de infraestrutura isoladamente.
A resolução do problema de dados TOASTed JSONB com REPLICA IDENTITY FULL no PostgreSQL é um aprendizado valioso sobre os detalhes da replicação lógica e o gerenciamento de dados complexos. Além da economia, a redução da latência de dados para 1 a 2 minutos representa um ganho operacional crucial, permitindo depuração em tempo real e tomadas de decisão mais rápidas. Isso afeta diretamente a experiência do cliente e a agilidade do negócio.
Linha do tempo
Bolna migra do BigQuery para ClickHouse, reduzindo custos em 6x e otimizando disponibilidade de dados
Perguntas frequentes
Por que o BigQuery se tornou problemático para a Bolna?
O BigQuery se tornou caro e lento para a Bolna devido ao grande volume de dados e ao padrão de uso. Operações de MERGE em uma tabela grande e não particionada, frequentemente atualizada, resultavam em varreduras completas da tabela, elevando os custos de computação. Além disso, a latência de 5 a 15 minutos na disponibilização dos dados de chamadas gerava problemas operacionais e insatisfação.
O que é REPLICA IDENTITY FULL e como ajudou a Bolna?
REPLICA IDENTITY FULL é uma configuração do PostgreSQL que força o envio da linha completa antiga no WAL (Write-Ahead Log) durante atualizações e exclusões. A Bolna usou essa configuração para resolver o problema de dados JSONB TOASTed ausentes ou antigos no ClickHouse. Isso garantia que colunas de grande volume, armazenadas fora da linha principal, fossem sempre replicadas corretamente.
Como a Bolna reduziu o volume de CDC e qual foi o impacto?
A Bolna reduziu o volume de CDC alterando a lógica da aplicação. Em vez de registrar cada mudança de status de uma chamada como uma atualização no PostgreSQL, a aplicação passou a escrever apenas o estado final da chamada. Essa mudança foi a maior responsável pela redução de custos em 6 vezes, diminuindo o volume de dados a serem replicados e a carga sobre os sistemas.
Qual foi a principal melhoria de performance após a migração para ClickHouse?
A principal melhoria foi a drástica redução na latência de dados. Antes, os dados de chamadas levavam de 5 a 15 minutos para estarem disponíveis para análise após o término da ligação. Com a nova arquitetura, essa latência caiu para apenas 1 a 2 minutos, permitindo que os clientes e equipes internas acessem informações críticas quase em tempo real e rodem métricas personalizadas sob demanda.
Fontes
- bolna.aifonte original
- Categoria
- CEVIU DevOps
- Publicado
- 30 de setembro de 2026
- Editoria
- CEVIU DevOps

