Come viene memorizzato internamente un DynamoDB GSI

UNIndice secondario globalenon è un puntatore alla tabella. È un separato, tabella gestita internamente: le proprie partizioni, il proprio schema di chiavi, il proprio capacità - che DynamoDB mantiene sincronizzato copiando le scritture in modo asincrono.

Proveniente da SQL, un indice è un B-tree imbullonato sulla stessa tabella fisica, aggiornato all'interno della stessa transazione. A GSI infrange entrambi questi presupposti, e quasi ogni sorpresa GSI riconduce a quell'unico fatto.

Come viene memorizzato un DynamoDB GSI?

Un DynamoDB GSI viene archiviato come una tabella separata, gestita internamente, con le proprie partizioni, schema di chiavi e capacità, non come puntatore alla tabella di base. DynamoDB copia ciascuna scrittura nell'indice in modo asincrono, memorizzando solo le chiavi GSI, le chiavi della tabella base ed eventualiproiettatoattributi.

• A GSI è una tabella a sé stante. Ha uno spazio di partizione completamente indipendente caratterizzato da la chiave di partizione di GSI, non quella della tabella di base.
• Le scritture vengono replicate in modo asincrono. La tua scrittura si impegna prima nella tabella di base, quindi DynamoDB lo distribuisce a ciascun GSI su un percorso di sfondo.
• Vengono memorizzati solo gli attributi proiettati. L'indice contiene le chiavi GSI, la base chiavi, più qualunque attributo tu abbia previsto, nient'altro.
• Non è necessario che la chiave GSI sia univoca. Più elementi base possono condividere un GSI chiave di partizione/ordinamento; la basechiave primariaè il tie-break che li mantiene distinto.

Inizia con un articolo base

Ottieni un registro di controllo SaaS. Ogni azione privilegiata in uno spazio di lavoro diventa un evento immutabile. La tabella di base, "WorkspaceEvents", è codificata in modo che tutto a gli eventi di workspace vivono in unoraccolta di oggetti, ordinati per tempo:

Partizioni EventPK = "WS#orbit-9" per area di lavoro; EventSK è quindi un timestamp ISO un Query restituisce gli eventi di uno spazio di lavoro in ordine cronologico. Questo serve "mostrami la sequenza temporale di questo spazio di lavoro" perfettamente.

Non serve ad altro. Non puoi chiedere "cosa ha fatto USR#kp in tutti i file spazio di lavoro?" — actorId non è una chiave, quindi l'unico modo per rispondere sulla base la tabella è una Scan completa. Questo è il modello di accesso a GSI esiste per aggiungere.

Aggiungi un GSI e guarda apparire una seconda tabella

Definire un GSI, ByActor, che ripartiziona gli stessi eventi in base a chi li ha eseguiti:

ByActor (GSI)
partition key = actorId   ("USR#kp")
sort key      = EventSK   ("TS#2026-06-23T14:02:11Z")

DynamoDB ora mantiene una seconda struttura fisica. Lo stesso evento logico è memorizzato due volte — una volta nella partizione WS#orbit-9 della tabella base e di nuovo dentro la partizione USR#kp di GSI:

Nota cosa è successo: le chiavi della tabella base (EventPK, EventSK) sono memorizzate in ogni elemento GSI automaticamente. Ecco come un colpo GSI può riportarti al articolo completo - e perché un KEYS_ONLY l'indice costa ancora l'archiviazione.

Cosa vive realmente nel GSI

L'indice non copia l'intero elemento. Ogni voce GSI ne contiene esattamente tre cose, e controlli solo la terza:

Proiezione è KEYS_ONLY, INCLUDE (un elenco con nome) o ALL. Un Query sul GSI può restituire solo attributi presenti nell'indice.

Richiedine uno che non sia proiettato e DynamoDB non lo recuperi in modo trasparente

• non ottieni nulla in cambio per quel campo. (documenti AWS GSI)

Questa è la trappola relazionale invertita: SQL si unirebbe nuovamente all'heap per il colonna mancante. A GSI non lo fa mai. ILproiezioneè l'intero contratto.

Come una scrittura raggiunge l'indice

La replica è la parte che rompe più duramente l'intuizione di SQL. Una scrittura di base e il tuo aggiornamento dell'indice non è un'operazione atomica.

Quando PutItem, DynamoDB si impegna in modo duraturo nella tabella di base, riconosce il tuo write e quindi propaga la modifica su un percorso in background che li aggiorna ciascuno GSI. Il riconoscimento non attende l'indice.

Ordine degli eventi per la nostra revisione contabile, dall'alto al basso:

Il chiamante ottiene il tuo "200 OK" al passaggio tre, prima che i passaggi da quattro a sei finiscano — quindi un Query su ByActor nell'intervallo può perdere un evento nuovo di zecca.

Questa asincronia è prevista dalla progettazione. Deriva dal lignaggio del 2007 Documento su Amazon Dynamo, che ha scelto la disponibilità rispetto alla coerenza sincrona. Tutte le conseguenze in diretta in perché un GSI alla fine è coerente.

La chiave GSI non è una chiave univoca

In SQL, un indice secondario non univoco è l'impostazione predefinita e uno unico è a vincolo a cui si opta. A GSI è l'opposto: non ha nessuna unicità garanzia, mai.

Due eventi di controllo dello stesso attore in timestamp che si scontrano condividerebbero il file stesso GSI1PK e GSI1SK. DynamoDB memorizza entrambi: li disambigua internamente dalla chiave primaria della tabella base, che viene sempre portata con sé.

Quindi un GSI Query per un attore in un istante può legittimamente restituirne diversi elementi. Se assumessi una riga per chiave come ti darebbe un indice univoco SQL, quella è la pistola.

Quando interroghi l'indice, il file DynamoDB Expression Builder scrive il KeyConditionExpression con nomi e valori sfuggiti correttamente — ad es. corrispondenza un attore dopo la chiusura:

KeyConditionExpression: "#a = :actor AND #ts > :since"
ExpressionAttributeNames:  { "#a": "actorId", "#ts": "EventSK" }
ExpressionAttributeValues: {
  ":actor": { "S": "USR#kp" },
  ":since": { "S": "TS#2026-06-01T00:00:00Z" }
}

La capacità risiede nell'indice, non nella tabella

Poiché GSI è una tabella a sé stante, ha la propria propria capacità di lettura e scrittura, fatturato e limitato separatamente dalla tabella base. Una lettura "ByActor" consuma le unità lette di GSI, mai quelle della tabella.

L'accoppiamento inverso è la parte che morde. Ogni scrittura della tabella base scrive anche il e se GSI non riesce ad assorbirlo, esercita una contropressione sulla scrittura di base. Quello il meccanismo ha la propria guida - quando un GSI limita le scritture della tabella di base.

Questo è anche il motivo per cui la chiave di partizione di GSI è importante tanto quanto quella della tabella di base. A i gruppi di chiavi GSI a bassa cardinalità scrivono su una partizione di indice anche quando base le scritture sono perfettamente distribuite: una partizione hot creata ricodificando.

GSI amplificazione di scrittura (fatturata)

Ogni scrittura di tabella base che proietta in un GSI costa base WCU + indice WCU su su richiesta in "us-east-1". Un elemento da 1 KB con proiezione ALL in genere fattura ~2 WCU totale: uno per la riga della tabella, uno per la copia dell'indice. KEYS_ONLY riduce l'indice di scrittura; "ALL" raddoppia la memoria e l'amplificatore di scrittura. Dimensioni dell'articolo del modello e proiezione nel calcolatore dei prezzi.

Insidie e passaggi successivi

• Non aspettarti che vengano restituiti attributi non proiettati. A GSI Query restituisce solo ciò che i negozi dell'indice. Se ti serve l'articolo completo, proiettalo o recuperalo dal file tabella base tramite le chiavi portate con sé.
• Non considerare una chiave GSI come unica. Pianifica che Query restituisca più di una chiave articolo per chiave; la chiave primaria di base è l'unica vera identità.
• Non leggere un GSI subito dopo la scrittura che lo ha alimentato. Il percorso asincrono indica il l'indice potrebbe non mostrare ancora la tua scrittura: leggi la tabella di base quando ne hai bisogno leggi-i-tuoi-scritti.
• Dimensiona deliberatamente la capacità di GSI. È indipendente dalle letture e da a dipendenza nascosta dalle scritture.

L'intero gioco sta nello scegliere le forme chiave che servono i tuoi schemi: design a tabella singola sovraccarica uno GSI su molti di loro; GSI vs LSI copre quando invece si adatta un indice locale.

Costruisci e visualizza l'anteprima del tuo GSI KeyConditionExpression nel file DynamoDB Expression Builder, quindi prova DynoTable per ispezionare gli attributi previsti di un indice e guarda scrive replica nel GSI sui tuoi tabelle.