System Design/04 - Cloud Design Patterns/Data Management2 min
Index Table
- Que problema isso resolve?
- Quando usar / quando NÃO usar?
- Qual o principal trade-off?
- Como isso falha em produção?
Conceito
Uma tabela auxiliar que mapeia um campo não-chave para a chave primária, permitindo busca eficiente onde o armazenamento não oferece índice secundário.
tabela principal: pedidos (pedido_id) → dados
tabela de índice: pedidos_por_cliente (cliente_id, pedido_id)
pedidos_por_data (data, pedido_id)
É o índice secundário construído à mão — necessário em Key-Value Store e Wide Column Store, que só sabem buscar pela chave de partição.
Duas variantes
| Variante | Conteúdo | Custo |
|---|---|---|
| Só a chave | Aponta para o registro real | Duas leituras; índice pequeno |
| Com dados duplicados | Já traz os campos da listagem | Uma leitura; duplicação e sincronização |
Trade-offs
O ganho é acesso direto onde antes seria varredura — em bancos distribuídos, a diferença entre uma consulta viável e uma que atinge todos os nós.
O custo é o de todo índice, agravado por ser manual:
- Escrita mais cara: cada gravação atualiza a tabela principal e todas as tabelas de índice
- Sem atomicidade: sem transação entre elas, o índice pode divergir do dado real
- Manutenção sua: nenhum otimizador cuida disso; um índice desatualizado devolve resultado errado
A ausência de atomicidade é o problema sério. Se a escrita principal tem sucesso e o índice falha, existe um registro invisível para as consultas por aquele campo. As mitigações usuais são: gravar primeiro o índice (um índice apontando para nada é detectável e corrigível), processar de forma assíncrona e idempotente, e rodar reconciliação periódica.
A variante com dados duplicados troca uma leitura por mais sincronização — e cada campo duplicado é mais um que pode ficar velho.
Vale sempre a pergunta anterior: o banco não oferece isso nativamente? DynamoDB tem GSI, Cassandra tem índice secundário (com ressalvas), MongoDB tem índices normais. Construir à mão só se justifica quando o nativo não existe ou não atende.
Exemplo prático
No DynamoDB, uma tabela de pedidos com chave pedido_id. A consulta necessária é "todos os pedidos do cliente 42".
Sem índice, isso é um Scan — varredura da tabela inteira, cara e lenta. A tabela de índice resolve:
pedidos_por_cliente: PK = cliente_id, SK = criado_em
→ devolve os pedido_id ordenados por data
Duas operações: consultar o índice, buscar os pedidos. Ambas por chave, ambas rápidas.
Nesse caso específico, um GSI faria exatamente isso de forma gerenciada — e é a resposta certa. A tabela manual só entra quando o custo do GSI ou suas limitações (consistência apenas eventual, capacidade própria) forem impeditivos.
Relacionado
Parte de Data Management · roadmap.sh/system-design