Bancos colunares

O problema: relatórios sobre muitas linhas

O painel de vendas pergunta "quanto vendemos por dia em março?". A tabela de eventos tem 20 milhões de linhas e cinco colunas, e a pergunta usa duas delas. Num banco relacional comum, as linhas ficam guardadas inteiras, uma depois da outra. Para somar uma coluna, o banco lê as páginas com as linhas completas, inclusive as colunas que a consulta não usa.

Um banco colunar guarda os valores de cada coluna juntos. Para somar valor, ele lê só o arquivo da coluna valor. E valores parecidos lado a lado se comprimem muito bem: uma coluna tipo com quatro valores possíveis vira quase nada.

Por linha (PostgreSQL):              Por coluna (ClickHouse):
[ts, tipo, cliente, valor]           ts:      [t1, t2, t3, t4, ...]
[ts, tipo, cliente, valor]           tipo:    [compra, compra, compra, ...]
[ts, tipo, cliente, valor]           cliente: [42, 7, 981, ...]
...                                  valor:   [19.90, 120.00, 5.50, ...]

O nome "colunar" cobre duas famílias diferentes. Este tópico trata das duas, porque a confusão entre elas é comum.

O colunar analítico, medido

Carregamos os mesmos 20 milhões de eventos (data e hora, tipo, cliente e valor) no PostgreSQL 18 e no ClickHouse 26, com 4 núcleos e 4 GB de memória para cada:

Nas consultas analíticas, o ClickHouse foi de 11 a 55 vezes mais rápido e ocupou um décimo do espaço. O índice do PostgreSQL não ajudou nas compras por dia: elas tocam centenas de milhares de linhas, e o índice serve para achar poucas. Na última linha, a situação se inverte: para achar os 40 eventos de um cliente, o índice B-tree do PostgreSQL respondeu em 0,35 ms, e o ClickHouse precisou ler a coluna inteira de clientes.

Os números são de uma máquina de desenvolvimento, e servem para comparar os dois bancos entre si. As somas dos dois bancos conferiram.

O que o colunar faz mal

O mesmo desenho que acelera as leituras cobra nas escritas. O ClickHouse grava os dados em partes imutáveis, ordenadas e comprimidas, e as junta em segundo plano.

Cada INSERT criou uma parte nova no disco, com seus arquivos e sua sincronização. Mil inserções de uma linha custaram mil vezes mais que uma de mil linhas, e deixariam o servidor ocupado juntando partes (no teste, a junção estava pausada para contar as partes). Uma aplicação que grava cada evento assim que ele acontece derruba o ClickHouse; o caminho é juntar os eventos em lotes, numa fila ou num buffer, e gravar de tempos em tempos.

A atualização reescreveu as partes que continham o cliente. Bancos analíticos são feitos para dados que chegam e ficam: eventos, medições, logs. Corrigir registros é possível, mas é exceção.

Linha larga: escrita distribuída, leitura pela chave

O Cassandra e o ScyllaDB guardam os dados em partições, distribuídas entre os servidores por uma chave. Dentro de cada partição, as linhas ficam ordenadas por uma chave de ordenação. A modelagem começa pela consulta: cada tabela é desenhada para uma pergunta.

CREATE TABLE leituras (
  sensor_id int, dia date, ts timestamp, valor double,
  PRIMARY KEY ((sensor_id, dia), ts)       -- partição: sensor e dia; ordem: ts
) WITH CLUSTERING ORDER BY (ts DESC);

Testamos no Cassandra 5:

O Cassandra só responde bem às consultas que dizem em qual partição procurar. Qualquer outra pergunta exige varrer todos os servidores, e ele a recusa por padrão. Para uma pergunta nova, cria-se uma tabela nova, com os mesmos dados organizados por outra chave.

O teste mostrou outra diferença importante. Um INSERT com uma chave que já existia sobrescreveu a leitura anterior (o valor passou de 21,5 para 99,9), sem erro nenhum: no Cassandra, inserir e atualizar são a mesma operação. Para impedir, há o IF NOT EXISTS, que no teste recusou o segundo cadastro com o mesmo e-mail, ao custo de uma rodada de consenso entre as réplicas.

Por que isso importa quando a IA escreve o código

Um assistente que integra um banco colunar costuma tratá-lo como um relacional:

• Inserções de uma linha por evento, em vez de lotes.
• Atualizações e exclusões frequentes, como num cadastro.
• Consultas por um registro só, que um índice B-tree resolveria melhor.
• No Cassandra, tabelas modeladas como no relacional, e ALLOW FILTERING para fazer as consultas passarem.
• Contar com o erro de chave duplicada no Cassandra, que não existe: o segundo INSERT sobrescreve.
• Relatórios pesados direto no banco transacional, sem resumo nem réplica.

O próximo nível compara quando usar cada família, como alimentar um banco analítico e como modelar no Cassandra.