Proiezioni degli indici DynamoDB: KEYS_ONLY, INCLUDE & ALL

Quando crei un indice secondario, DynamoDB non copia automaticamente l'intero item al suo interno. Scegli tu cosa viene copiato — la proiezione dell'indice. Scegli troppo poco e le tue query pagano una seconda lettura per recuperare il resto; scegli tutto e paghi storage e costo di scrittura extra a ogni aggiornamento. È un compromesso che imposti una volta alla creazione dell'indice e con cui poi convivi.

(Non confonderlo con una projection expression, che riduce gli attributi restituiti da una singola lettura. Questa pagina riguarda cosa un indice memorizza fisicamente — vedi projection expressions per l'altro concetto.)

Cos'è una proiezione di un indice DynamoDB?

Una proiezione è l'insieme di attributi che DynamoDB copia dalla tabella base in un indice secondario. Scegli uno di tre tipi: KEYS_ONLY (solo le chiavi), INCLUDE (le chiavi più un elenco di attributi che nomini) o ALL (l'intero item). Più proiezione significa meno recuperi dalla tabella base, ma costo di storage e di scrittura più alti.

• Una proiezione è l'insieme di attributi copiati in un indice secondario.
• KEYS_ONLY — solo le chiavi della tabella e dell'indice. La più piccola, la più economica.
• INCLUDE — le chiavi più un elenco di attributi extra che scegli tu.
• ALL — ogni attributo dell'item. La più grande; le query non hanno mai bisogno della tabella base.
• Leggere un attributo non proiettato forza un recupero dalla tabella base per una GSI — un costo extra silenzioso. (Una LSI può recuperare per te gli attributi non proiettati, a un costo di lettura aggiuntivo.)
• Più proiezione = più storage + più costo di scrittura, poiché ogni scrittura sulla tabella base si propaga all'indice.

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

Diciamo che gestisci un supporto clienti con una GSI che ti permette di elencare i ticket aperti per priorità. Proietti KEYS_ONLY per tenerla snella. La query restituisce in fretta — ma ti dà solo gli ID dei ticket, e la schermata della coda ha bisogno di oggetto, assegnatario ed età di ogni ticket.

Così ora il tuo codice fa un secondo giro di letture sulla tabella base per idratare ogni risultato. L'"unica query" che avevi progettato è in realtà una query più N get, e la latenza e il costo che cercavi di risparmiare sono tornati subito a galla. La proiezione era troppo magra per l'access pattern.

Cosa copia ciascun tipo di proiezione

• KEYS_ONLY memorizza solo la chiave della tabella base e la chiave dell'indice. Usala quando la query deve solo sapere quali item corrispondono e recupererai i dettagli altrove — o per niente.
• INCLUDE memorizza le chiavi più un elenco fisso di attributi che nomini. Il punto ideale: proietta esattamente i campi che la query deve renderizzare, e nulla di più.
• ALL copia l'intero item. Le query sono completamente autosufficienti dall'indice, al costo di duplicare al suo interno lo storage e il throughput di scrittura dell'intero item.

Per la coda del supporto clienti, INCLUDE con subject, assignee e age è la scelta giusta — la coda si renderizza dal solo indice, senza un secondo recupero e senza duplicare nell'indice il grande body del ticket.

Il costo che stai barattando

Ogni attributo che proietti viene memorizzato una seconda volta e riscritto nell'indice ogni volta che l'item base cambia. Quindi una generosa proiezione ALL su una tabella aggiornata di frequente moltiplica sia lo storage sia la capacità di scrittura. La disciplina è: proietta ciò che la query legge, non "tutto, per sicurezza".

Una sottigliezza da conoscere: con un indice sparse, la proiezione contiene comunque solo gli item che portano la chiave dell'indice — quindi INCLUDE/ALL su un indice sparse resta piccolo perché l'indice stesso è piccolo. Valuta il moltiplicatore di storage e scrittura della tua proiezione con il calcolatore dei prezzi DynamoDB, e assembla le query dell'indice con il DynamoDB expression builder.

Vedere una proiezione in DynoTable

DynoTable elenca ciascuno degli indici secondari di una tabella e ti permette di interrogare direttamente attraverso uno di essi. Esegui lo stesso access pattern sulla tabella base e su una GSI e confronta i risultati — gli attributi mancanti dal risultato dell'indice sono esattamente quelli che non proietta, quindi l'effetto di una proiezione è visibile senza rileggere la definizione della tabella.

Trappole e prossimi passi

• Un attributo non proiettato su una GSI significa un recupero sulla tabella base — progetta la proiezione attorno a ciò che la query renderizza.
• ALL è raramente gratis — duplica storage e costo di scrittura; usa di default INCLUDE a meno che l'indice non abbia davvero bisogno di ogni campo.
• Le proiezioni sono per lo più fisse. Non puoi modificare liberamente la proiezione di una GSI in seguito senza ricreare l'indice — scegli con cura fin dall'inizio.
• Correlati: GSI vs LSI e indici sparse influenzano quanto una proiezione effettivamente memorizza.

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