GSI vs LSI no DynamoDB
Tanto um Global Secondary Index (GSI) quanto um Local Secondary Index (LSI) permitem que você
faça Query por um atributo que não é a chave da sua tabela. Eles não são
intercambiáveis — as diferenças decidem qual deles um padrão precisa.
As diferenças que importam
| GSI | LSI | |
|---|---|---|
| Chave de partição | Qualquer atributo | A mesma da tabela |
| Chave de ordenação | Qualquer atributo | Qualquer atributo |
| Quando é criado | A qualquer momento | Só na criação da tabela |
| Consistência | Só eventual | Forte disponível |
| Capacidade | A própria | Compartilha a da tabela |
| Propagação de escrita | Assíncrona (eventual) | Síncrona (atômica) |
| Máx. por tabela | 20 (padrão, ampliável) | 5 (fixo) |
| Limite de partição 10 GB | Não | Sim (por PK) |
Uma regra prática
- Precisa de uma chave de partição diferente (por exemplo, buscar pedidos por
statusem vez decustomer)? Você precisa de um GSI — um LSI não consegue reparticionar. - Precisa de uma segunda ordem de ordenação dentro da mesma partição — um LSI mantém a chave de partição exata da tabela e só troca por uma chave de ordenação diferente — decidida desde o início, com leituras de consistência forte? Um LSI serve.
A escolha se reduz a uma pergunta — qual chave você está mudando:
Uma chave de partição diferente força um GSI; uma chave de ordenação diferente na mesma partição é o único caso em que um LSI serve.
Na prática, a maioria das equipes recorre quase exclusivamente a GSIs: eles podem ser adicionados depois, escalam de forma independente e não estão sujeitos ao limite de 10 GB por partição. Sobrecarregue as chaves de um único GSI para servir vários padrões — veja tabela única.
Se você está adicionando um GSI para eliminar um Scan, lembre-se de que ele tem sua própria capacidade de leitura/escrita. Dimensione esse custo extra com a calculadora de preços e experimente o DynoTable para inspecionar os atributos projetados de um índice antes de se comprometer com ele.