GSI vs LSI in DynamoDB
Sia un Global Secondary Index (GSI) sia un Local Secondary Index (LSI) ti permettono di fare
Query per un attributo che non è la chiave della tua tabella. Non sono
intercambiabili — le differenze decidono quale serve a un determinato pattern.
Le differenze che contano
| GSI | LSI | |
|---|---|---|
| Partition key | Qualsiasi attributo | La stessa della tabella |
| Sort key | Qualsiasi attributo | Qualsiasi attributo |
| Quando si crea | In qualsiasi momento | Solo alla creazione della tabella |
| Coerenza | Solo eventuale | Forte disponibile |
| Capacità | Propria | Condivide quella della tabella |
| Propagazione scritture | Asincrona (eventuale) | Sincrona (atomica) |
| Massimo per tabella | 20 (default, aumentabile) | 5 (rigido) |
| Limite partizione 10 GB | No | Sì (per PK) |
Una regola pratica
- Ti serve una partition key diversa (es. cercare gli ordini per
statusinvece che percustomer)? Ti serve un GSI — un LSI non può ripartizionare. - Ti serve un secondo ordinamento all'interno della stessa partizione — un LSI mantiene la partition key esatta della tabella e cambia solo la sort key — deciso in anticipo, con letture a coerenza forte? Allora un LSI è adatto.
La scelta si riduce a una domanda — quale chiave stai cambiando:
Una partition key diversa impone un GSI; una sort key diversa sulla stessa partizione è l'unico caso in cui un LSI è adatto.
In pratica la maggior parte dei team ricorre quasi esclusivamente ai GSI: sono aggiungibili in seguito, scalati in modo indipendente e non soggetti al limite di 10 GB per partizione. Sovraccarica le chiavi di un singolo GSI per servire diversi pattern — vedi single-table design.
Se stai aggiungendo un GSI per eliminare uno Scan, ricorda che ha la propria capacità di lettura/scrittura. Dimensiona quel costo extra con il calcolatore dei prezzi, e prova DynoTable per ispezionare gli attributi proiettati di un Index prima di impegnarti su di esso.