ClickHouse em Cloud Server para analytics em tempo real

Resposta direta

Para rodar ClickHouse com analytics em tempo real, escolha um Cloud Server com CPU forte, RAM suficiente para agregações e disco NVMe com boa taxa de escrita sustentada. Um ambiente inicial de produção costuma começar em 4 vCPUs, 16 GB de RAM e 160 GB de NVMe, mas o número muda rápido conforme volume de eventos, retenção, cardinalidade das colunas e quantidade de consultas simultâneas. Para ingestão contínua, prefira batches de 1.000 a 10.000 linhas, partições bem definidas, TTL para retenção e monitoramento de merges. Cloud Server faz sentido quando você precisa de controle sobre kernel, disco, rede e tuning do ClickHouse, sem ficar preso às limitações de uma hospedagem tradicional.

Resumo rápido

• ClickHouse é um banco OLAP colunar, então CPU, RAM e disco pesam de forma diferente de um PostgreSQL ou MySQL transacional.
• Para produção pequena, considere pelo menos 4 vCPUs, 16 GB de RAM e 160 GB de NVMe, com folga para merges e retenção.
• Ingestão evento a evento costuma desperdiçar recursos. Batches de 1.000 a 10.000 linhas reduzem overhead e melhoram compressão.
• NVMe ajuda bastante em workloads com escrita contínua, leitura por grandes intervalos e múltiplas consultas analíticas ao mesmo tempo.
• Particionamento por data, TTL e ordenação por chaves consultadas com frequência evitam crescimento descontrolado.
• Um único Cloud Server pode funcionar bem no início, mas clusters com shards e réplicas entram quando há alta disponibilidade ou muitos terabytes.
• Backups de ClickHouse precisam validar restauração, não apenas copiar diretórios ou confiar em snapshot sem teste.

Por que ClickHouse muda o dimensionamento do servidor

ClickHouse não deve ser dimensionado como um banco relacional comum. Ele foi criado para consultas analíticas em grandes volumes, com armazenamento colunar, compressão agressiva e execução vetorizada. Isso significa que uma consulta pode ler bilhões de valores de poucas colunas, aplicar filtros, agrupar por dimensões e devolver resultado em segundos quando o modelo está bem desenhado. O mesmo cenário em um banco transacional tradicional poderia exigir índices pesados, tabelas auxiliares ou pré-agregações complexas.

Na prática, o Cloud Server precisa absorver três movimentos ao mesmo tempo: entrada constante de dados, merges em segundo plano e consultas de usuários ou dashboards. Imagine uma aplicação SaaS que envia 2.000 eventos por segundo, cada um com usuário, conta, tipo de ação, país, dispositivo e timestamp. Durante o dia, o time de produto abre painéis por coorte, o time de suporte busca eventos de clientes específicos e o time de engenharia investiga latência por endpoint. O servidor não está apenas armazenando linhas. Ele está compactando partes, reorganizando dados e respondendo agregações.

Essa diferença explica por que a escolha de CPU, RAM e NVMe precisa ser feita junto com a modelagem. Um servidor com 8 vCPUs e 32 GB de RAM pode parecer grande para uma API comum, mas pode ficar apertado se o ClickHouse receber inserts muito pequenos, partições demais e consultas com GROUP BY em campos de cardinalidade alta. Antes de contratar uma instância, ajuda revisar critérios de hardware como os discutidos em como escolher CPU, RAM e NVMe, porque o gargalo raramente aparece em um único recurso isolado.

OLAP não se comporta como banco transacional

Em OLTP, o foco costuma ser consistência por linha, baixa latência em operações pequenas e muitos writes pontuais. Em OLAP, o desenho favorece leitura sequencial, compressão e agregações. ClickHouse brilha quando recebe dados em blocos, grava partes ordenadas e consegue pular faixas inteiras usando índices primários esparsos. Por isso, um esquema mal ordenado pode custar mais do que uma vCPU extra.

Analytics em tempo real exige folga operacional

Tempo real não significa gravar um evento e consultá-lo individualmente no milissegundo seguinte. Em muitos produtos, uma latência de 2 a 10 segundos já entrega uma experiência excelente para dashboards operacionais, antifraude leve, métricas de funil ou observabilidade de produto. Essa folga permite agrupar inserts, reduzir fragmentação e manter o servidor estável durante picos.

CPU, RAM e NVMe: onde o gargalo aparece primeiro

O gargalo em ClickHouse costuma alternar conforme o estágio do workload. Durante ingestão pesada, CPU e disco disputam atenção por causa de parsing, compressão e escrita de partes. Durante consultas amplas, CPU e leitura de disco ganham peso. Em agregações grandes, RAM entra no centro da conversa. O erro comum é contratar um Cloud Server olhando apenas para a quantidade de vCPUs e esquecer que analytics em tempo real também precisa de I/O sustentado, baixa latência de disco e memória para operações intermediárias.

Para uma base inicial, 4 vCPUs e 16 GB de RAM atendem muitos projetos internos com alguns milhões de eventos por dia, desde que o esquema seja simples e a retenção não passe de algumas centenas de gigabytes. Um ambiente com 50 a 200 milhões de eventos por dia já costuma pedir 8 a 16 vCPUs, 32 a 64 GB de RAM e NVMe com espaço suficiente para dados comprimidos, merges temporários e margem de crescimento. Se o servidor ficar com 85% do disco ocupado, os merges sofrem, as consultas oscilam e qualquer manutenção vira risco.

CPU para compressão, parsing e consultas

ClickHouse usa CPU de forma intensa. Formatos como JSONEachRow são práticos, mas custam mais CPU que Native ou Parquet. Se a aplicação envia eventos em JSON com campos aninhados, a etapa de parsing pode virar gargalo antes mesmo do disco. Em consultas, funções de data, conversões de tipo, joins e agregações por alta cardinalidade também consomem bastante processamento. Para produção, prefira vCPUs modernas e evite instâncias muito compartilhadas quando a carga for previsível.

RAM para merges, caches e agregações

RAM não serve apenas para cache. Ela segura estados intermediários de agregações, ordenações, joins e merges. Uma consulta com GROUP BY user_id, session_id em dezenas de milhões de linhas pode consumir muito mais memória que um dashboard agregado por dia e país. Defina limites como max_memory_usage, max_bytes_before_external_group_by e políticas de usuários para evitar que uma consulta exploratória derrube o ambiente inteiro.

NVMe para ingestão contínua e leitura por coluna

NVMe não faz milagre, mas faz diferença quando há escrita constante e leitura analítica concorrente. ClickHouse grava partes, compacta, mescla e reorganiza dados em segundo plano. Em SSD SATA ou storage de rede mais lento, o servidor pode acumular merges pendentes. Em NVMe local ou bloco de alta performance, há mais margem para manter ingestão e consulta convivendo. Ainda assim, confirme no provedor se o NVMe está disponível no plano e na localidade escolhida, porque esse recurso varia bastante.

Ingestão de eventos sem derrubar as consultas

A ingestão é onde muitos projetos de analytics em tempo real começam bem e depois tropeçam. ClickHouse aceita altos volumes, mas ele prefere blocos. Inserir uma linha por requisição HTTP cria muitas partes pequenas, aumenta o trabalho de merge e desperdiça CPU. Em um cenário de aplicação web, faz mais sentido colocar um coletor, uma fila ou um serviço intermediário que agrupe eventos por alguns segundos antes de gravar. Batches de 1.000 a 10.000 linhas costumam ser um bom ponto de partida, ajustando conforme tamanho médio do evento e latência aceitável.

Um exemplo prático: uma API recebe eventos de navegação, cliques e conversões. Em vez de cada microserviço escrever diretamente no ClickHouse, os serviços publicam mensagens em Kafka, Redpanda, NATS ou RabbitMQ. Um consumidor lê a fila, valida campos, normaliza tipos e envia blocos para uma tabela events_raw. Depois, materialized views podem popular tabelas agregadas por minuto, campanha ou cliente. Esse desenho reduz acoplamento e evita que um pico de tráfego na aplicação vire pico direto no banco analítico.

Batch pequeno é melhor que evento isolado

Se a meta é dashboard quase em tempo real, um atraso de 3 segundos pode ser aceitável. Esse intervalo permite montar blocos maiores e reduzir a quantidade de partes criadas. No ClickHouse, muitas partes pequenas levam a merges constantes, maior uso de disco temporário e queda de previsibilidade. Para eventos com 1 KB em média, um batch de 5.000 linhas tem cerca de 5 MB antes da compressão, tamanho razoável para escrita frequente.

Kafka, filas e buffers reduzem picos

Filas também ajudam na recuperação. Se o ClickHouse reiniciar para manutenção, a aplicação não precisa perder eventos. O consumidor pausa, a fila acumula mensagens e a ingestão volta depois. Para workloads próximos de observabilidade, a lógica se parece com pipelines de logs. Se o seu caso mistura eventos de produto e logs estruturados, vale comparar a arquitetura com um ambiente de logs centralizados com Loki, porque os problemas de retenção, cardinalidade e custo de armazenamento aparecem nos dois mundos.

Particionamento e TTL precisam nascer certos

Particionar por dia ou mês parece simples, mas a decisão depende do volume. Partições diárias funcionam bem para alto volume e retenção curta. Partições mensais podem servir bases menores. O ORDER BY deve refletir filtros comuns, como (tenant_id, event_date, event_name) em SaaS multi-tenant. TTL pode mover dados antigos, resumir informações ou apagar eventos brutos após 30, 90 ou 180 dias. Sem TTL, o custo cresce silenciosamente.

Single node, cluster ou serviço gerenciado?

Um único Cloud Server bem dimensionado pode rodar ClickHouse por bastante tempo. Essa é uma das vantagens do banco: ele consegue entregar consultas rápidas em hardware relativamente simples quando os dados estão bem ordenados e comprimidos. Para um time pequeno, começar com single node reduz complexidade, facilita backup, simplifica troubleshooting e evita custos operacionais de cluster. O ponto é saber quando essa simplicidade deixa de ser suficiente.

Single node faz sentido quando a indisponibilidade de alguns minutos é tolerável, a base está abaixo de alguns terabytes comprimidos e a ingestão cabe em uma máquina com folga. Um servidor com 8 vCPUs, 32 GB de RAM e 500 GB a 1 TB de NVMe pode atender dashboards internos, analytics de produto, métricas de marketing e auditoria de eventos de uma aplicação de médio porte. O segredo é manter monitoramento, snapshots ou backups testados e um plano claro de aumento de disco.

Quando um servidor único faz sentido

Projetos em fase inicial, ferramentas internas e times que ainda estão validando o modelo de dados se beneficiam de uma arquitetura simples. Você pode instalar ClickHouse, configurar firewall, criar usuários separados para ingestão e leitura, limitar memória por perfil e expor apenas endpoints necessários. Esse desenho é parecido com o de aplicações backend em produção, e muitos cuidados de rede e latência também aparecem em VPS para APIs e microsserviços no Brasil, especialmente quando os eventos vêm de serviços hospedados no país.

Quando dividir shards e réplicas

Cluster entra quando há necessidade de alta disponibilidade, crescimento acima da capacidade vertical ou volume de consulta concorrente que uma máquina não absorve mais. Réplicas ajudam leitura e disponibilidade. Shards dividem dados, mas adicionam complexidade em distribuição, rebalanceamento e consultas. Um cluster com 2 shards e 2 réplicas, por exemplo, envolve 4 nós de ClickHouse, além de Keeper ou ZooKeeper para coordenação. Isso muda backup, deploy e monitoramento.

Quando considerar managed analytics

Serviços gerenciados podem valer a pena quando o time não quer operar banco, atualização, cluster e backup. Eles reduzem trabalho operacional, mas podem custar mais e limitar ajustes finos. Para dados sensíveis, também entram discussões de região, compliance e saída de dados. Cloud Server autogerenciado entrega controle e previsibilidade técnica, desde que alguém assuma a responsabilidade por segurança, atualização e restauração.

Tabela de dimensionamento para ClickHouse em Cloud Server

A tabela abaixo não substitui teste de carga, mas ajuda a criar uma primeira estimativa. Os números consideram eventos estruturados, compressão típica de dados colunares e consultas analíticas comuns, como contagem por intervalo, funil, agrupamento por cliente e filtros por atributos. Se os eventos tiverem payloads muito grandes, JSON aninhado pesado ou cardinalidade extrema, suba um nível antes de ir para produção.

Perfil de uso	Volume de ingestão sugerido	Cloud Server inicial	Disco e retenção	Observações técnicas
Laboratório e BI interno	Até 5 milhões de eventos/dia	4 vCPUs, 16 GB RAM	160 a 250 GB SSD NVMe	Bom para testar schema, materialized views e dashboards com poucos usuários
Produto SaaS em crescimento	10 a 100 milhões de eventos/dia	8 vCPUs, 32 GB RAM	500 GB a 1 TB NVMe	Use fila, batches, TTL e limites de memória por usuário
Analytics operacional intenso	100 a 500 milhões de eventos/dia	16 vCPUs, 64 GB RAM	1 a 3 TB NVMe	Avalie cluster, réplicas, storage separado e testes de carga antes da publicação
Alta disponibilidade	Depende do shard	4 nós ou mais	NVMe por nó, backup externo	Modelo comum: 2 shards com 2 réplicas, mais ClickHouse Keeper

Ao comparar provedores, não publique decisão baseada apenas em preço de tabela sem revisão humana. Planos mudam, regiões mudam e recursos como bandwidth, snapshot, backup automático e tipo de storage podem variar por localidade. DigitalOcean, Vultr, Akamai Linode, AWS Lightsail, Hetzner e Contabo aparecem com frequência em discussões de Cloud Server para dados, mas cada um tem diferenças de região, disco, rede e perfil de suporte. No Brasil, LetsCloud pode entrar na análise quando latência local, pagamento nacional ou presença regional forem fatores relevantes, mas disponibilidade de NVMe, snapshots e recursos específicos precisa ser confirmada por plano e localidade antes da publicação.

Para um teste inicial, crie uma carga sintética com dados parecidos com os reais. Uma tabela events com DateTime, tenant_id, event_name, user_id, session_id, country, device e propriedades normalizadas já revela bastante. Gere 50 milhões de linhas, rode consultas por hora, dia e cliente, e acompanhe CPU, RAM, leitura de disco, partes ativas e merges. Se o servidor só fica rápido com cache quente, o dimensionamento pode estar otimista demais.

Também reserve espaço para manutenção. Em ClickHouse, disco cheio é um problema sério. Trabalhe com alerta em 70%, plano de ação em 80% e emergência antes de 90%. Dados comprimidos podem ocupar pouco, mas merges e mutações precisam de área livre. Se a retenção bruta é de 180 dias, talvez faça sentido manter dados detalhados por 30 dias e criar agregados para histórico longo.

Operação, segurança e backup em produção

Colocar ClickHouse em produção não termina na instalação do pacote. A operação define se o ambiente vai sobreviver a picos, falhas humanas e crescimento de dados. O primeiro cuidado é separar usuários. Um usuário de ingestão não precisa fazer DROP TABLE. Um usuário de dashboard não precisa inserir dados. Perfis com limites de memória, tempo de execução e simultaneidade impedem que uma consulta exploratória consuma todos os recursos. Em ambiente exposto, TLS, firewall e regras de origem são obrigatórios.

No Linux, mantenha atualizações planejadas, ajuste limites de arquivos abertos e monitore o serviço pelo systemd. ClickHouse pode abrir muitos arquivos, especialmente com muitas partes e tabelas. Configurações como nofile adequado, discos montados com opções corretas e logs rotacionados evitam surpresas. Se você usa Docker, cuide de volumes persistentes, limites de memória e atualização de imagem. Docker facilita padronização, mas não elimina a necessidade de backup e tuning do host.

Backups precisam testar restauração

Snapshot do provedor ajuda, mas não deve ser o único plano. ClickHouse tem ferramentas como BACKUP e RESTORE, além de integrações com discos externos e object storage em determinados cenários. Para bases menores, backups em object storage compatível com S3 podem funcionar bem. Para bases grandes, teste tempo de restauração, custo de tráfego e consistência. Um backup que nunca foi restaurado é apenas uma hipótese otimista.

Monitoramento deve olhar merges e disco

Métricas úteis incluem CPU, RAM, I/O, espaço livre, número de partes por tabela, merges em execução, inserts por segundo, queries lentas e erros de background. O ClickHouse expõe tabelas de sistema como system.parts, system.merges, system.query_log e system.errors. Um alerta de muitas partes ativas pode indicar batches pequenos demais. Um aumento de merges pendentes pode apontar gargalo de disco ou partições mal desenhadas.

Rede e acesso administrativo

Não exponha a porta nativa ou HTTP do ClickHouse para a internet sem controle. Use VPN, rede privada, allowlist de IPs ou proxy autenticado. Em Cloud Server, também verifique tráfego entre regiões. Se a aplicação está no Brasil e o ClickHouse nos Estados Unidos, a latência pode não destruir batches assíncronos, mas pode afetar dashboards interativos e aumentar custo de transferência. Para consultas usadas por times locais, região próxima melhora a experiência.

Recomendações por perfil

Dev solo ou projeto interno

Para um dev solo, laboratório de dados ou BI interno, comece simples. Um Cloud Server com 4 vCPUs, 16 GB de RAM e 160 a 250 GB de NVMe é suficiente para aprender o comportamento do ClickHouse, validar tabelas MergeTree e construir dashboards com alguns milhões de eventos por dia. Use Docker Compose apenas se você souber cuidar de volumes e limites, ou instale via pacote oficial para reduzir camadas. Configure uma tabela bruta, uma ou duas materialized views e TTL de 30 a 90 dias. O foco não é extrair o máximo de performance, mas criar um desenho que não precise ser jogado fora quando o volume crescer.

Time de produto com eventos de aplicação

Times de produto precisam equilibrar velocidade e confiabilidade. Um ponto de partida comum é 8 vCPUs, 32 GB de RAM e 500 GB a 1 TB de NVMe, com ingestão por fila e batches controlados. Separe eventos brutos de agregados, normalize campos que entram em filtros frequentes e evite guardar JSON livre como única fonte de consulta. Dashboards de funil, retenção e uso por cliente devem consultar tabelas otimizadas, não varrer payloads crus o tempo todo. Também defina governança mínima: quem pode criar query pesada, quem altera schema e qual retenção vale para cada tipo de dado.

Produção crítica e analytics de alto volume

Para produção crítica, não trate o Cloud Server como uma ilha. Planeje alta disponibilidade, backup externo, testes de restauração e capacidade de crescer sem migração emergencial. Workloads acima de 100 milhões de eventos por dia, múltiplos dashboards simultâneos ou retenção em terabytes pedem 16 vCPUs, 64 GB de RAM ou mais, NVMe amplo e possível cluster com réplicas. Antes de contratar vários nós, rode benchmark com dados parecidos com os reais. Meça ingestão, latência de consultas, impacto dos merges e comportamento durante falha de nó. Só depois compare provedores, regiões e custos com revisão humana dos dados comerciais.

Agência, consultoria ou multi-tenant

Agências e consultorias que hospedam analytics para vários clientes devem pensar em isolamento desde o começo. Se todos os clientes compartilham a mesma tabela, use tenant_id no ORDER BY quando as consultas filtrarem por cliente. Também vale criar políticas de usuário por cliente ou por aplicação, limitando memória e tempo máximo. Para clientes maiores, separar tabelas ou até servidores pode reduzir risco operacional. O erro caro é misturar workloads muito diferentes, como tracking de alto volume, auditoria jurídica e dashboards executivos, no mesmo desenho sem limites.

Quando adiar ClickHouse

Nem todo projeto precisa de ClickHouse no primeiro mês. Se você tem poucos milhares de eventos por dia, dashboards simples e equipe pequena, PostgreSQL com tabelas particionadas, TimescaleDB ou uma ferramenta gerenciada de analytics pode resolver por mais tempo. ClickHouse começa a fazer mais sentido quando consultas agregadas ficam lentas, o volume cresce para milhões de eventos por dia ou a retenção histórica passa a pesar. A decisão boa é técnica, não uma corrida por ferramenta nova. Quando o problema ainda é modelagem de eventos, trocar o banco pode apenas esconder a causa por algumas semanas.