System Design/02 - Componentes/Databases2 min
Wide Column Store
- Que problema isso resolve?
- Quando usar / quando NÃO usar?
- Qual o principal trade-off?
- Como isso falha em produção?
Conceito
Dados organizados em famílias de colunas, com o modelo (partition key, clustering key) → colunas. Cada partição pode ter colunas diferentes.
usuario_id (partição) | timestamp (clustering) | evento | dados
u42 | 2026-08-26T10:00 | login | {...}
u42 | 2026-08-26T10:05 | compra | {...}
Exemplos: Cassandra, ScyllaDB, HBase, Google Bigtable, Amazon Keyspaces.
Por que escala tanto para escrita
A arquitetura interna é LSM-tree: a escrita vai para um log sequencial e uma tabela em memória, sem leitura de disco nem atualização em lugar. Isso torna a escrita quase tão barata quanto anexar a um arquivo — e é o motivo de Cassandra sustentar milhões de escritas por segundo.
O custo aparece na leitura, que pode precisar consultar vários arquivos (SSTables), e na compactação em background, que consome I/O.
O modelo de consulta
A regra é rígida: a consulta precisa fornecer a partition key. Dentro da partição, os dados já estão ordenados pela clustering key, o que torna consultas por intervalo de tempo muito eficientes.
Não há junção. Não há consulta ad-hoc. Não há agregação arbitrária.
Trade-offs
Wide column entrega escrita distribuída em escala massiva e disponibilidade contínua (Cassandra é AP, ver CAP Theorem) — ao custo de rigidez total no acesso.
Isso força uma tabela por consulta. Se você precisa buscar eventos por usuário e também por tipo de evento, são duas tabelas, com o dado duplicado e escrito duas vezes. Desnormalização não é otimização aqui; é o modelo.
Os modos de falha característicos:
| Problema | Causa |
|---|---|
| Partição grande | Partition key com baixa cardinalidade — uma partição cresce sem limite |
| Hot partition | Escrita concentrada numa chave |
| Tombstones | Deleção cria marcador; excesso degrada a leitura seriamente |
| Consulta sem partition key | Vira varredura do cluster inteiro |
Adicionar um novo padrão de acesso depois costuma significar criar uma nova tabela e migrar todo o histórico — o oposto de um CREATE INDEX num banco relacional.
Exemplo prático
Telemetria de IoT: 100 mil sensores enviando uma leitura por segundo, consultada sempre como "leituras do sensor X entre T1 e T2".
PRIMARY KEY ((sensor_id, dia), timestamp)
A partition key inclui o dia deliberadamente: sem isso, a partição de um sensor cresceria indefinidamente. Com o dia, cada partição tem no máximo 86.400 leituras — tamanho previsível.
A escrita é sequencial e barata; a leitura por intervalo é uma varredura ordenada dentro de uma partição. Exatamente o padrão para o qual o modelo foi desenhado.
Se amanhã surgir "média de todos os sensores de uma fábrica por hora", o modelo não responde — e a resposta será uma segunda tabela, ou um pipeline para um banco analítico.
Relacionado
Parte de Databases · roadmap.sh/system-design