ClickHouse: OLAP analytics de alto throughput

⏱ 13 min·⭐ 55 XP

Pré-requisitos (0/1)0%

⬜⚡ DynamoDB: single-table design(NoSQL + Vector Databases)

Recomendamos completar os pré-requisitos antes de seguir, mas nada te impede de continuar.

Por que ClickHouse existe

Postgres é row-oriented: uma row vive junta em disco. Excelente para OLTP (ler/atualizar 1 row inteira). Péssimo para analytics (SELECT SUM(x) em 1B rows lê todas as colunas, mesmo usando só x). ClickHouse inverte: colunar. Cada coluna é um arquivo comprimido. Query agregada lê só as colunas necessárias.

Schema real: eventos de analytics

CREATE TABLE events
(
    event_time  DateTime64(3) CODEC(DoubleDelta, LZ4),
    event_name  LowCardinality(String),
    user_id     UInt64,
    session_id  UUID,
    country     LowCardinality(FixedString(2)),
    device      LowCardinality(String),
    url         String CODEC(ZSTD(3)),
    referrer    String CODEC(ZSTD(3)),
    properties  Map(String, String)
)
ENGINE = MergeTree
PARTITION BY toYYYYMM(event_time)
ORDER BY (event_name, event_time, user_id)
TTL event_time + INTERVAL 18 MONTH
SETTINGS index_granularity = 8192;

💡

LowCardinality é dicionário automático para colunas com < 10k valores únicos (event_name, country). Reduz tamanho em 10x. CODEC(DoubleDelta, LZ4) em timestamp aproveita que eventos são quase sequenciais — compressão 50x+. Essas decisões de schema têm impacto brutal em custo.

Query analítica real

-- Top 10 paginas por unique users nos ultimos 7 dias,
-- com conversion rate, segmentado por pais
SELECT
    url,
    country,
    uniqExact(user_id)                                     AS unique_users,
    countIf(event_name = 'page_view')                      AS views,
    countIf(event_name = 'purchase')                       AS purchases,
    round(purchases / unique_users * 100, 2)               AS conversion_pct
FROM events
WHERE event_time >= now() - INTERVAL 7 DAY
  AND country IN ('BR', 'US', 'PT')
GROUP BY url, country
HAVING unique_users > 100
ORDER BY conversion_pct DESC
LIMIT 10
SETTINGS max_threads = 8;

Em tabela de 2 bilhões de rows, essa query roda em ~3-5s num nó de 8 cores. Postgres mesmo com índices levaria minutos.

Quiz rápido

Por que bancos colunares dominam cargas analíticas?

Materialized views para rollups

-- Rollup diario por pais (atualiza em tempo real)
CREATE MATERIALIZED VIEW events_daily
ENGINE = SummingMergeTree
PARTITION BY toYYYYMM(day)
ORDER BY (day, country, event_name)
AS SELECT
    toDate(event_time) AS day,
    country,
    event_name,
    count()            AS events,
    uniqState(user_id) AS users_state
FROM events
GROUP BY day, country, event_name;

-- Query sobre o rollup (instantanea)
SELECT day, country, sum(events) AS total
FROM events_daily
WHERE day >= today() - 30
GROUP BY day, country
ORDER BY day DESC;

Do evento cru ao painel: onde a agregação acontece

Ingestão

Aplicaçãoemite eventos

Loteinserção em blocos grandes, nunca linha a linha

Tabela bruta

Eventoscolunar, ordenada pela chave primária

Partiçõespor mês; descarte é remoção de partição

Agregação incremental

Visão materializadagatilho na inserção, não consulta agendada

Tabela de agregadosestados parciais por hora

Consumo

Painellê o agregado, responde em milissegundos

Investigaçãodesce ao evento cru quando precisa

→ blocos
→ a cada inserção

Compute
Conceito de arquitetura
Analytics

Repare que a seta da agregação sai da tabela crua no momento da inserção, e não do painel no momento da consulta. É essa inversão — pagar na escrita para que a leitura seja barata — que sustenta painel interativo sobre volume que não caberia numa consulta ao vivo.

💡

Materialized view em ClickHouse é trigger: cada insert na tabela base alimenta a MV. Diferente de Postgres, onde MV precisa REFRESH.

Ingestion: sempre em batch

⚠️

Nunca faça single-row INSERT em ClickHouse em produção. Mínimo ~10k rows por batch, idealmente 100k+. Use Kafka engine, Buffer tables, ou aplicação com buffering em memória. Single inserts geram too-many-parts e matam a performance.

✅

ClickHouse é a resposta quando Postgres gasta horas numa query analítica. Mas não é substituto — é complemento via CDC. OLTP fica no Postgres, analytics vai para ClickHouse.

Perguntas frequentes

❓ Quando um banco colunar de alta vazão vence o armazém?

Quando a consulta é analítica sobre volume grande e você precisa de latência de subsegundo com custo baixo — painel em tempo quase real, análise de evento. Ele perde em atualização frequente de registro individual e em transação, que não é o objetivo dele.

❓ Por que não usar como banco de aplicação?

Porque ele é otimizado para inserção em lote e leitura em massa, não para atualização e exclusão de registro único nem para transação. Usá-lo como fonte de verdade transacional é o erro que aparece na primeira necessidade de corrigir uma linha.

❓ Como lidar com duplicata na ingestão?

Com motor de mesclagem que deduplica por chave, aceitando que a deduplicação é eventual — ela acontece na mesclagem, não na inserção. Consulta feita antes disso pode ver duplicata, e é preciso escrever a consulta ciente disso ou forçar a deduplicação na leitura.

Fixando

Quiz rápido

Para que servem visões materializadas com agregação prévia nesse contexto?

Quiz rápido

Qual é a limitação que precisa ser aceita ao escolher esse tipo de banco?

Terminou de ler?

Marcar como concluído registra o XP, mantém sua sequência e coloca 3 cartas deste módulo na fila de revisão espaçada.

Próximos passos sugeridos

🪨

SQLite moderno: edge, mobile e backend 2026

NoSQL + Vector Databases · 12 min · +50 XP

→

Temas deste módulo

Discussão

Carregando comentários…

ClickHouse: OLAP analytics de alto throughput

⏱ 13 min·⭐ 55 XP

Pré-requisitos (0/1)0%

⬜⚡ DynamoDB: single-table design(NoSQL + Vector Databases)

Recomendamos completar os pré-requisitos antes de seguir, mas nada te impede de continuar.

Por que ClickHouse existe

Schema real: eventos de analytics

CREATE TABLE events
(
    event_time  DateTime64(3) CODEC(DoubleDelta, LZ4),
    event_name  LowCardinality(String),
    user_id     UInt64,
    session_id  UUID,
    country     LowCardinality(FixedString(2)),
    device      LowCardinality(String),
    url         String CODEC(ZSTD(3)),
    referrer    String CODEC(ZSTD(3)),
    properties  Map(String, String)
)
ENGINE = MergeTree
PARTITION BY toYYYYMM(event_time)
ORDER BY (event_name, event_time, user_id)
TTL event_time + INTERVAL 18 MONTH
SETTINGS index_granularity = 8192;

💡

Query analítica real

-- Top 10 paginas por unique users nos ultimos 7 dias,
-- com conversion rate, segmentado por pais
SELECT
    url,
    country,
    uniqExact(user_id)                                     AS unique_users,
    countIf(event_name = 'page_view')                      AS views,
    countIf(event_name = 'purchase')                       AS purchases,
    round(purchases / unique_users * 100, 2)               AS conversion_pct
FROM events
WHERE event_time >= now() - INTERVAL 7 DAY
  AND country IN ('BR', 'US', 'PT')
GROUP BY url, country
HAVING unique_users > 100
ORDER BY conversion_pct DESC
LIMIT 10
SETTINGS max_threads = 8;

Em tabela de 2 bilhões de rows, essa query roda em ~3-5s num nó de 8 cores. Postgres mesmo com índices levaria minutos.

Quiz rápido

Por que bancos colunares dominam cargas analíticas?

Materialized views para rollups

-- Rollup diario por pais (atualiza em tempo real)
CREATE MATERIALIZED VIEW events_daily
ENGINE = SummingMergeTree
PARTITION BY toYYYYMM(day)
ORDER BY (day, country, event_name)
AS SELECT
    toDate(event_time) AS day,
    country,
    event_name,
    count()            AS events,
    uniqState(user_id) AS users_state
FROM events
GROUP BY day, country, event_name;

-- Query sobre o rollup (instantanea)
SELECT day, country, sum(events) AS total
FROM events_daily
WHERE day >= today() - 30
GROUP BY day, country
ORDER BY day DESC;

Do evento cru ao painel: onde a agregação acontece

Ingestão

Aplicaçãoemite eventos

Loteinserção em blocos grandes, nunca linha a linha

Tabela bruta

Eventoscolunar, ordenada pela chave primária

Partiçõespor mês; descarte é remoção de partição

Agregação incremental

Visão materializadagatilho na inserção, não consulta agendada

Tabela de agregadosestados parciais por hora

Consumo

Painellê o agregado, responde em milissegundos

Investigaçãodesce ao evento cru quando precisa

→ blocos
→ a cada inserção

Compute
Conceito de arquitetura
Analytics

💡

Materialized view em ClickHouse é trigger: cada insert na tabela base alimenta a MV. Diferente de Postgres, onde MV precisa REFRESH.

Ingestion: sempre em batch

⚠️

✅

ClickHouse é a resposta quando Postgres gasta horas numa query analítica. Mas não é substituto — é complemento via CDC. OLTP fica no Postgres, analytics vai para ClickHouse.

Perguntas frequentes

❓ Quando um banco colunar de alta vazão vence o armazém?

❓ Por que não usar como banco de aplicação?

❓ Como lidar com duplicata na ingestão?

Fixando

Quiz rápido

Para que servem visões materializadas com agregação prévia nesse contexto?

Quiz rápido

Qual é a limitação que precisa ser aceita ao escolher esse tipo de banco?

Terminou de ler?

Marcar como concluído registra o XP, mantém sua sequência e coloca 3 cartas deste módulo na fila de revisão espaçada.

Próximos passos sugeridos

🪨

SQLite moderno: edge, mobile e backend 2026

NoSQL + Vector Databases · 12 min · +50 XP

→

Temas deste módulo

Discussão

Carregando comentários…