DynamoDB Proiezioni dell'indice

Quando crei un indice secondario, DynamoDB non copia automaticamente l'intero elemento in esso. Scegli cosa viene copiato: la proiezione dell'indice. Scegli troppo poco e le tue domande pagano una seconda lettura per recuperare il resto; scegli tutto e paghi un extra costi di archiviazione e scrittura per ogni aggiornamento. È un compromesso che imposti una volta al momento della creazione dell'indice e convivere.

(Non confonderlo con un'espressione di proiezione, che taglia gli attributi a ritorni a lettura singola. Questa pagina riguarda ciò che un indice memorizza fisicamente: vedi espressioni di proiezione per l'altro.)

Cos'è una proiezione dell'indice DynamoDB?

Una proiezione è l'insieme di attributi DynamoDB copia dalla tabella di base in un indice secondario. Scegli uno dei tre tipi: KEYS_ONLY (solo le chiavi), INCLUDE (chiavi più un elenco di attributi con nome) o ALL (l'intero elemento). Una maggiore proiezione significa meno recuperi dalla tabella di base ma costi di archiviazione e scrittura più elevati.

• Una proiezione è l'insieme di attributi copiati in un indice secondario.
• KEYS_ONLY — solo le chiavi della tabella e dell'indice. Il più piccolo, il più economico.
• INCLUDE: le chiavi più un elenco denominato di attributi extra scelti da te.
• ALL: ogni attributo dell'articolo. Il più grande; le query non necessitano mai della tabella di base.
• Un attributo che non è previsto semplicemente non è disponibile da GSI: la tua app deve emettere le proprie letture della tabella di base. (Solo un LSI recupera attributi non proiettati per tu, a un costo di lettura aggiuntivo.)
• Più proiezione = più spazio di archiviazione + più costi di scrittura, poiché ogni scrittura della tabella base si propaga all'indice.

Il problema: l'indice che ti fa leggere due volte

Supponiamo che tu gestisca un desk di supporto con un GSI che ti consente di elencare i ticket aperti in base alla priorità. Proietti KEYS_ONLY per mantenerlo snello. La query ritorna velocemente, ma ti dà solo gli ID dei biglietti e la schermata della coda richiede l'oggetto, l'assegnatario e l'età di ciascun biglietto.

Quindi ora il tuo codice esegue un secondo ciclo di letture rispetto alla tabella di base per idratare ogni risultato. La "una query" che hai progettato è in realtà una query più N ottiene e il la latenza e i costi che stavi cercando di risparmiare sono tornati subito. La proiezione era troppo sottile per il modello di accesso.

Ciò che copia ogni tipo di proiezione

• KEYS_ONLY memorizza solo la chiave della tabella base e la chiave dell'indice. Usalo quando il la query deve solo sapere quali elementi corrispondono e recupererai i dettagli altrove - oppure per niente.
• INCLUDE memorizza le chiavi più un elenco fisso di attributi da te nominati. Il dolce spot: proietta esattamente i campi che la tua query deve visualizzare e niente di più.
• ALL copia l'intero elemento. Le query sono completamente gestite autonomamente dall'indice, all'indirizzo il costo della duplicazione dell'archiviazione dell'intero articolo e della scrittura del throughput al suo interno.

Per la coda del supporto tecnico, INCLUDE con oggetto, assegnatario e età è il valore chiamata giusta: la coda esegue il rendering solo dall'indice, senza e senza secondo recupero duplicando il grande "corpo" del ticket nell'indice.

Il costo del tuo trading

Ogni attributo che proietti lo è memorizzato una seconda volta e riscritto nell'indice ogni volta che cambia l'elemento base. Quindi un generoso ALL la proiezione su una tabella aggiornata frequentemente moltiplica sia la capacità di archiviazione che quella di scrittura. Proietta ciò che la query legge, non "tutto, per ogni evenienza".

Una sottigliezza che vale la pena conoscere: con un indice sparso, la proiezione mantiene ancora solo il elementi che portano la chiave dell'indice, quindi INCLUDE/ALL su un indice sparso rimane piccolo perché l'indice stesso è piccolo. Pesare la memoria e scrivere il moltiplicatore per la proiezione con DynamoDB calcolatore dei prezzi e assemblare il l'indice si interroga con il file DynamoDB generatore di espressioni.

Vedere una proiezione in DynoTable

DynoTable elenca ciascuno degli indici secondari di una tabella e consente di eseguire query direttamente uno. Esegui lo stesso modello di accesso rispetto alla tabella base e rispetto a GSI e confronta i risultati: gli attributi mancanti dal risultato dell'indice sono esattamente quelli non proietta, quindi l'effetto di una proiezione è visibile senza rileggere la tabella definizione.

Insidie + passaggi successivi

• Un attributo non proiettato su GSI indica un recupero della tabella di base: progetta il proiezione attorno a ciò che viene visualizzato dalla query.
• ALL è raramente gratuito — duplica i costi di archiviazione e scrittura; predefinito a INCLUDE a meno che l'indice non abbia veramente bisogno di ogni campo.
• Le proiezioni sono per lo più fisse. Non puoi modificare liberamente la proiezione di GSI in un secondo momento senza ricreare l'indice: scegli deliberatamente in anticipo.
• Correlati: GSI vs LSI e indici sparsi modellano quanto una proiezione effettivamente negozi.

Vuoi vedere cosa restituisce effettivamente ciascuno dei tuoi indici prima di riprogettarli? Scarica DynoTable ed interroga direttamente le tue tabelle.

Costo di idratazione: KEYS_ONLY + N ottiene

Ritorna all'esempio della coda del supporto tecnico: 50 ticket aperti visualizzati con soggetto, assegnatario ed età.

I numeri esatti dipendono dalle dimensioni degli attributi previsti: incolla un ticket di esempio in il calcolatore della dimensione dell'oggetto e moltiplicare per profondità della coda. INCLUDE che elenca solo i campi dell'interfaccia utente spesso batte ALL quando L'attributo "body" è grande e raramente viene mostrato nella visualizzazione elenco.

Comportamento di recupero della proiezione LSI

Solo LSIs può facoltativamente recuperare attributi non proiettati dalla tabella di base durante una query (con costo di lettura aggiuntivo). GSI non lo fanno mai — mancante gli attributi richiedono che l'applicazione chiami GetItem sulla tabella di base. Quello la differenza spinge molti progetti GSI verso proiezioni INCLUDE leggermente più ampie davanti.

Modifica delle proiezioni in un secondo momento

Le proiezioni GSI sono fissate al momento della creazione. Ampliamento di KEYS_ONLY a INCLUDE richiede la creazione di un nuovo indice, il riempimento, la riduzione del traffico e l'eliminazione il vecchio indice: pianifica i campi prima del lancio. LSI condividono la stessa limitazione.

Quando si valuta un nuovo modello di accesso, interrogare l'indice candidato in DynoTable e elenca gli attributi visualizzati: gli spazi vengono mappati 1:1 alle voci di proiezione mancanti.

Accoppia con indici sparsi

Un GSI sparso che indicizza solo i ticket status = open memorizza le proiezioni per solo righe aperte. INCLUDE su quell'indice rimane economico anche quando si trova la tabella di base detiene milioni di ticket chiusi: l'indice non li ha mai copiati.

Combina con modelli di indici sparsi quando il il sottoinsieme filtrato è piccolo rispetto alla tabella.

Costruisci prima il modello di accesso

Utilizza il costruttore di query per prototipare GSI query (condizione chiave, espressione di proiezione e filtro) prima di modificarla CloudFormation. Scambiare i tipi di proiezione nella discussione sulla progettazione chiedendo quali colonne visualizzate dall'interfaccia utente; tutto il resto rimane sul tabella base.