GSI vs LSI dans DynamoDB
Un Global Secondary Index (GSI) comme un Local Secondary Index (LSI) te permettent
tous deux de faire un Query sur un attribut qui n'est pas la clé de ta table. Ils
ne sont pas interchangeables — les différences décident lequel un pattern réclame.
Les différences qui comptent
| GSI | LSI | |
|---|---|---|
| Clé de partition | N'importe quel attribut | Identique à la table |
| Clé de tri | N'importe quel attribut | N'importe quel attribut |
| Quand créé | À tout moment | À la création de la table seulement |
| Cohérence | À cohérence à terme uniquement | Forte disponible |
| Capacité | La sienne | Partage celle de la table |
| Propagation des écritures | Asynchrone (à cohérence à terme) | Synchrone (atomique) |
| Max par table | 20 (par défaut, augmentable) | 5 (strict) |
| Plafond de partition 10 GB | Non | Oui (par PK) |
Une règle empirique
- Besoin d'une clé de partition différente (par ex. retrouver des commandes par
statusplutôt que parcustomer) ? Il te faut un GSI — un LSI ne peut pas repartitionner. - Besoin d'un second ordre de tri dans la même partition — un LSI garde la clé de partition exacte de la table et n'échange qu'une clé de tri différente, décidée en amont, avec des lectures fortement cohérentes ? Un LSI convient.
Le choix se résume à une seule question — quelle clé es-tu en train de changer :
Une clé de partition différente impose un GSI ; une clé de tri différente sur la même partition est le seul cas où un LSI convient.
En pratique, la plupart des équipes optent presque exclusivement pour les GSI : ils sont ajoutables plus tard, mis à l'échelle indépendamment et non soumis à la limite de 10 GB par partition. Surcharge les clés d'un seul GSI pour servir plusieurs patterns — voir single-table design.
Si tu ajoutes un GSI pour éliminer un Scan, souviens-toi qu'il a sa propre capacité de lecture/écriture. Dimensionne ce coût supplémentaire avec le calculateur de tarifs, et essaie DynoTable pour inspecter les attributs projetés d'un index avant de t'y engager.