Bancos colunares
Armazenamento orientado a colunas para escrita em volume e para consultas analíticas.
As decisões sobre bancos colunares são quatro: se um banco analítico é necessário, qual escolher, como alimentá-lo e, no caso da linha larga, como modelar.
É preciso um banco analítico?
| Situação | Saída |
|---|---|
| Relatórios ocasionais, tabelas de até dezenas de milhões de linhas | O próprio PostgreSQL, com índices, tabelas de resumo e visões materializadas |
| Relatórios pesando no banco principal | Uma réplica de leitura só para relatórios |
| Análises pontuais sobre arquivos exportados | DuckDB, direto em Parquet ou CSV, sem servidor |
| Painéis sobre centenas de milhões de eventos, consultados o tempo todo | Banco analítico colunar |
| Análise de dados de toda a empresa, com várias fontes | Armazém de dados gerenciado (BigQuery, Snowflake, Redshift) |
No teste do nível Conceito, o ClickHouse foi de 11 a 55 vezes mais rápido nas agregações e ocupou um décimo do espaço. O preço é mais um banco para operar, alimentar e manter coerente com a fonte da verdade.
Qual banco analítico
| Opção | Como roda | Bom para |
|---|---|---|
| ClickHouse | Servidor próprio ou nuvem gerenciada | Painéis em tempo quase real sobre eventos, logs e métricas |
| DuckDB | Biblioteca dentro do processo, como o SQLite | Análises locais, notebooks, arquivos Parquet, tarefas de dados |
| BigQuery, Snowflake, Redshift | Gerenciados, cobrados por uso ou capacidade | Armazém de dados da empresa, com muitas fontes e muitos analistas |
| PostgreSQL com extensões colunares | O mesmo PostgreSQL | Volumes médios, sem querer um banco novo |
Como alimentar o banco analítico
| Forma | Como funciona | Atraso |
|---|---|---|
| Exportação periódica | Um job copia os dados novos a cada hora ou dia | Horas |
| Captura de mudanças (change data capture, CDC) | Uma ferramenta lê o log do banco principal (Debezium, por exemplo) e envia as mudanças | Segundos |
| Eventos da aplicação | A aplicação publica eventos numa fila, e um consumidor grava em lotes | Segundos |
Em todas, a regra do teste vale: gravar em lotes. No teste, mil inserções de uma linha levaram 69 segundos e criaram mil partes; a mesma carga num lote levou 60 ms. O ClickHouse também aceita inserções assíncronas (async_insert), em que o próprio servidor junta as inserções pequenas antes de gravar; o teste não mediu essa opção.
Modelar para o banco analítico
| Prática | Por quê |
|---|---|
| Tabelas largas e desnormalizadas | Junções são caras; o nome do produto e a categoria vão junto com o evento |
Ordem da tabela pelas consultas (ORDER BY (tipo, ts) no ClickHouse) | É o índice principal: as consultas que filtram por essas colunas leem menos |
Tipos pequenos e de baixa cardinalidade (LowCardinality(String), UInt32) | Comprimem mais e leem menos |
| Particionar por período | Apagar meses antigos vira apagar uma partição |
| Dados imutáveis, com correções como novas linhas | Atualizações reescrevem partes inteiras: 1,1 s no teste para atualizar 40 linhas |
Linha larga: quando e como
| Use Cassandra ou ScyllaDB quando | Evite quando |
|---|---|
| A escrita é enorme e contínua (sensores, mensagens, eventos) | O volume cabe num PostgreSQL bem configurado |
| A disponibilidade em várias regiões importa mais que a consistência imediata | As consultas mudam com frequência, ou são exploratórias |
| As consultas são conhecidas de antemão e sempre pela chave | Há relatórios e agregações ad hoc |
| O time aceita modelar uma tabela por consulta | Há transações entre vários registros |
Modelar no Cassandra
- Liste as consultas antes das tabelas.
- Uma tabela por consulta, com a chave de partição igual aos filtros obrigatórios da consulta.
- Limite o tamanho das partições: um sensor com anos de leituras numa partição só fica grande demais. Por isso a chave do exemplo é
(sensor_id, dia), e não sósensor_id. - Use a chave de ordenação para as faixas e a ordem (as leituras mais recentes primeiro).
- Duplique os dados entre as tabelas, gravando em todas.
- Lembre que
INSERTsobrescreve, e useIF NOT EXISTSsó onde a unicidade importa: ela custa uma rodada de consenso. - Evite
ALLOW FILTERINGem produção: ele faz a consulta varrer o cluster.
Resumo da decisão
- Comece pelo PostgreSQL, com resumos e réplica; um banco analítico quando os relatórios sobre grandes volumes virarem rotina.
- ClickHouse para painéis sobre eventos; DuckDB para análises locais; armazém gerenciado para os dados da empresa.
- Grave em lotes e trate os dados como imutáveis.
- Modele o analítico largo e desnormalizado, ordenado pelas consultas.
- Cassandra só para escrita enorme e consultas pela chave, com uma tabela por consulta.
O próximo nível mostra a gravação em lotes e a consulta analítica no ClickHouse nas cinco linguagens, pela interface HTTP.
Prompts para aprofundar
Ao abrir no ChatGPT ou no Claude, o prompt é enviado ao serviço escolhido pela URL e também fica copiado na sua área de transferência.
Planejar o banco analítico do meu sistema
Quero acrescentar um banco analítico ao meu sistema para os painéis e relatórios. Pergunte quais relatórios existem, o volume de dados, com que atraso os painéis podem ficar, qual é o banco principal e se prefiro operar servidores ou usar um serviço gerenciado. Proponha: 1. Se o banco analítico é mesmo necessário, ou se resumos e uma réplica bastam. 2. Qual banco analítico, e por quê. 3. Como os dados chegam até ele (exportação, CDC ou eventos), sempre em lotes. 4. O esquema das tabelas principais, largas e ordenadas pelas consultas. 5. Como lidar com correções de dados.
Modelar no Cassandra
Preciso modelar um sistema no Cassandra (ou ScyllaDB). Pergunte o que o sistema faz, quais são as consultas, o volume de escrita e quanto tempo os dados ficam guardados. Me guie: 1. Listar as consultas antes de qualquer tabela. 2. Desenhar uma tabela por consulta, com a chave de partição e a de ordenação. 3. Limitar o tamanho das partições. 4. Gravar nas várias tabelas e lidar com a duplicação. 5. Onde usar IF NOT EXISTS, e o custo disso. No final, aponte as consultas que o modelo não atende.
ClickHouse, DuckDB ou armazém gerenciado
Estou escolhendo uma ferramenta para análises e relatórios. Pergunte o volume de dados, quem consulta (painéis da aplicação ou analistas), a frequência das consultas, as fontes de dados e o orçamento. Compare para o meu caso ClickHouse, DuckDB, BigQuery, Snowflake e extensões colunares do PostgreSQL quanto a velocidade, custo, operação e integração com o que eu já tenho. Recomende uma opção.