Perché un DynamoDB GSI limita le scritture della tabella base

Scrivi al tuo tabella. La scrittura fallisce con un'eccezione di throughput, ma il file l'eccezione nomina un Indice secondario globale, non la tabella. la tabella ha spazio di riserva capacità.

Venendo da SQL, non ha senso: un indice secondario non può bloccare un INSERT. Dentro DynamoDB può, e il meccanismo si chiama GSI contropressione.

Perché scrive una tabella base con acceleratore DynamoDB GSI?

DynamoDB limita la scrittura della tabella base perché ogni scrittura si replica anche su ciascun GSI e se una partizione GSI non può assorbire la tua quota, DynamoDB applica una contropressione per impedire che l'indice rimanga permanentemente indietro. Pertanto, una chiave GSI con provisioning insufficiente o con cardinalità bassa diventa un limite massimo per la velocità di scrittura della tabella di base.

• Una scrittura sulla tabella base scrive anche su ogni GSI. Se un GSI non può assorbire la tua quota, DynamoDB limita la scrittura della tabella di base per impedire l'accesso all'indice rimanere permanentemente indietro. (AWS documenti)
• Una tabella con base pari non ti salva. Il GSI è partizionato dalla propria chiave. Una chiave GSI a bassa cardinalità (come status) crea un filepartizione hot-indexanche quando le scritture della tabella base sono perfettamente distribuite.
• L'eccezione riguarda la vittima. Il ResourceArn punta al GSI; l'operazione effettivamente limitata è la tua scrittura sulla tabella.
• La correzione riguarda la capacità o la progettazione della chiave, non i cicli di tentativi: aumenta il throughput di GSI, oppure scegli un GSIchiave di partizioneche si diffonde.

Come una singola scrittura tocca l'indice

Un PutItem sulla tabella di base non è una scrittura. DynamoDB replica quello dell'oggetto attributi proiettati in ciascun GSI in modo asincrono, su un piano eventualmente coerente modello. Una scrittura logica si espande su N scritture fisiche: tabella più ogni indice.

Tale replica non è gratuita e non è facoltativa. Il GSI deve tenere il passo, oppure il l'indice si allontana ulteriormente dalla tabella ad ogni operazione.

Per fermare questa deriva, DynamoDB applica una contropressione: strozza la fonte scrivere in modo che l'indice non diventi mai completamente obsoleto.

Quindi la capacità di scrittura di GSI è un limite rigido alla velocità di scrittura della tabella di base — anche se non scrivi mai direttamente al GSI.

Un esempio pratico: una tabella degli ordini

Supponiamo che tu gestisca una tabella degli ordini. L'articolo base:

Le scritture della tabella base sono integre. CUST#... ha una cardinalità elevata, quindi l'ordine è scritto distribuire uniformemente sulle partizioni di base. Nessun tasto di scelta rapida, molta capacità.

Ora aggiungi un GSI per rispondere "mostrami tutti gli ordini in un determinato stato":

Quattro possibili valori della chiave di partizione. Durante una vendita flash, quasi ogni nuovo ordine finisce in order_state = "PENDING". Ognuna di queste scritte colpisce lo stesso Partizione GSI.

Quella partizione ha un limite di throughput per partizione e hai appena mirato al tuo intera tempesta di scrittura su di esso.

la tabella base va bene. La partizione PENDING GSI è in fiamme. DynamoDB limita la tabella base PutItem per proteggere l'indice.

Il flusso che ti morde

Percorso di contropressione: scrittura di base bilanciata, scrittura dell'indice concentrata:

Una partizione hot GSI rifiuta la scrittura della tabella di base che lo ha nutrito.

Leggi l'eccezione, non il tuo istinto

Il tipo di eccezione ti dice esattamente quale limite raggiungi. Il file "ResourceArn". nomina il GSI; l'operazione limitata è ancora la scrittura della tabella.

Fonte: Comprensione di GSI scrittura di limitazione e contropressione.

Il motivo "KeyRange" è l'omaggio al caso di partizione calda di cui sopra: nel complesso La capacità GSI può sembrare soddisfacente mentre un intervallo chiave è saturo.

Come risolverlo

Dai la stanza GSI. La causa più semplice è il provisioning insufficiente. A GSI ha il tuo propria capacità di lettura e scrittura, completamente separata dalla tabella - cfr GSI vs LSI.

Se hai rifornito generosamente la tabella e hai lasciato pochi GSI, rilancia i GSI capacità di scrittura (o il tuo massimo su richiesta).

Correggi la chiave di partizione. La capacità non salverà una chiave con cardinalità bassa: non puoi eseguire il provisioning di una singola partizione attiva. Scegli una chiave di partizione GSI che si diffonde.

Componilo: order_state#shard dove shard è un piccolo suffisso casuale o fold la data in (PENDING#2026-06-23). Scrive sparse tra le partizioni e tu ancora Query uno stato interrogando gli shard.

Proietta meno attributi. Ogni scrittura GSI copia gli attributi proiettati. A La proiezione KEYS_ONLY o stretta INCLUDE significa scritture sull'indice più piccole e meno pressione superiore a ALL. Non proiettare ciò che non leggerai mai dall'indice.

Tralasciare GSI se è solo per la segnalazione. Se "ordini per stato" è un domanda occasionale dell'amministratore, non un percorso caldo, una scansione periodica con un filtro potrebbe essere migliore un indice permanentemente caldo: valutalo Query vs Scan.

Quando esegui una query su quell'indice, il file Expression Builder scrive il KeyConditionExpression per te — ad es. #s = :stato AND begins_with(SK, :prefisso) — con i nomi e i valori sfuggiti correttamente:

KeyConditionExpression     "#s = :state AND begins_with(SK, :prefix)"
ExpressionAttributeNames   { "#s": "order_state" }
ExpressionAttributeValues  { ":state": { "S": "PENDING" }, ":prefix": { "S": "ORD#2026-06-23" } }

La trappola da ricordare

L'istinto relazionale — "indicizza solo lentamente, scrive un po'" — no trasferimento. A DynamoDB GSI è una dipendenza dal throughput, non una struttura passiva. Sottodimensionarlo o scegliere una chiave agglomerante, esercita una pressione negativa sul tabella che serve.

Guarda "ConsumedWriteCapacityUnits" e "WriteThrottleEvents" su GSI dimensione, non solo quella della tabella, e utilizza Contributor Insights per trovare gli argomenti più interessanti chiavi.

Passaggi successivi

• GSI vs LSI — perché un GSI ha una propria capacità e un chiave di partizione diversa.
• Design a tabella singola — sovraccaricando uno GSI su servire molti modelli senza moltiplicare gli hot index.
• Query vs Scan - quando un indice non vale il tuo costo di scrittura.

Prova DynoTable per ispezionare ogni GSI sulle tue tabelle: schema chiave e conteggi degli articoli e interroga i tuoi indici prima che una vendita li diventi rossi.