DynamoDB Indici sparsi

Un indice sparso è un indice secondario che contiene solo gli elementi che lo contengono attributo chiave: in questo modo un sottoinsieme piccolo e importante di una tabella enorme diventa suo raccolta prefiltrata e pronta per l'esecuzione di query.

Hai milioni di righe ma la query che esegui tutto il giorno tocca una piccola fetta: il ticket di supporto aperti, fatture non pagate, account contrassegnati per la revisione.

Il filtraggio di quella sezione esegue comunque la scansione dell'intera tabella e ti fattura per ogni lettura. A L'indice sparso rende invece piccolo l'indice stesso.

Cos'è un indice sparso in DynamoDB?

Un indice sparso è un indice secondario che contiene solo gli elementi che portano il tuo attributo chiave. Poiché DynamoDB salta qualsiasi elemento a cui manca quella chiave, inventi una chiave che scrivono solo gli elementi desiderati (biglietti aperti, fatture non pagate) e l'indice diventa quel sottoinsieme esatto. Le query quindi leggono solo quello, senza filtri, senza capacità di lettura sprecata.

• Un indice secondario indicizza solo gli elementi che hanno la propria chiave. Ometti la chiave su an elemento e non entra mai nell'indice: nessun segnaposto, nessuna riga nulla.
• Quindi inventi una chiave che portano solo gli oggetti desiderati. Scrivila sugli oggetti che hai query, rimuovilo dal resto. L'indice diventa esattamente quel sottoinsieme.
• La query legge solo il sottoinsieme, nessun filtro. la tua dimensione tiene traccia del piccolo hot impostato, non il totale della tabella.
• REMOVE è la leva, non la cancellazione. Una stringa vuota non è un indice valido key - DynamoDB rifiuta l'intera scrittura con una ValidationException - quindi devi eliminare l'attributo.

Il problema: il filtraggio non salva le letture

Provenendo da SQL, presumi che una clausola WHERE restringa il lavoro. DynamoDB FilterExpression no. Viene eseguito dopo che gli elementi sono stati letti, non prima.

Secondo il Guida per sviluppatori AWS, "a Query consuma la stessa quantità di capacità di lettura, indipendentemente dal fatto che sia presente un filtro espressione è presente" - paghi per ogni elemento esaminato, quindi lanci il file mancate partite in trasferta.

Quindi, se 50 dei tuoi 5 milioni di ticket sono aperti, si legge un Query/Scan filtrato attraverso milioni per darti quei 50.

Questa è la pistola dietro ogni thread "perché la mia scansione è così costosa"; query vs. scan contiene il quadro completo dei costi.

Un indice sparso lo elude rendendo l'indice stesso piccolo.

Come funziona la scarsità

Un indice secondario indicizza solo gli elementi che effettivamente hanno la chiave dell'indice attributi.

Il AWS documenti sugli indici sparsi spiegalo bene: DynamoDB scrive un elemento in un indice secondario solo quando quell'elemento trasporta gli attributi chiave dell'indice, quindi rimane un indice su un attributo impostato raramente naturalmente piccolo.

Manca la chiave di partizione (o chiave di ordinamento) di GSI su un elemento e DynamoDB semplicemente non lo fa scrivilo nell'indice. Nessun segnaposto, nessuna riga nulla: l'elemento è assente.

Quella "assenza per impostazione predefinita" è l'intero trucco. Non indicizzare un attributo status che ogni oggetto porta con sé. Inventa un attributo che solo gli articoli che desideri query carry affatto.

L'indice diventa quindi un elenco pulito esattamente di quegli elementi e un Query contro li legge solo: nessun filtro, nessuna capacità sprecata.

Immagina la tabella di base che alimenta l'indice, dove si incrociano solo gli elementi che portano la chiave:

Solo gli elementi con chiave (aperti) vengono replicati nell'indice; gli elementi chiusi non vi entrano mai.

Questa è la stessa mentalità di formazione delle chiavi di progettazione a tabella singola: le chiavi sono strumenti creati per modello di accesso specifico, non specchio fedele dei tuoi dati.

Un esempio pratico: "solo biglietti aperti"

Prendi una tabella per i ticket di supporto. La tabella di base è codificata per recuperare un ticket in base all'ID ed elencare i biglietti di un cliente:

Nel corso della vita della tabella, la maggior parte dei ticket finisce per essere chiusa. Ma la query del dashboard i tuoi agenti hanno colpito tutto il giorno è "mostrami tutti i ticket aperti, prima il più vecchio" - alcuni centinaia di righe nascoste all'interno di milioni.

Definire aGSIcon chiave di partizione "openBucket" e chiave di ordinamento openedAt e scrivi openBucket solo sui ticket aperti. Impostalo quando viene creato il biglietto; "RIMUOVI" quando il ticket viene risolto.

I biglietti "a91f" e "b02c" contengono "openBucket", quindi vivono nel GSI. Biglietto 77de è stato risolto e openBucket è stato rimosso, quindi è stato eliminato silenziosamente. Il dashboard è ora una query economica:

Query  IndexName = "open-tickets-index"
KeyConditionExpression: openBucket = "OPEN"
ScanIndexForward: true        # oldest first

Questo legge solo i ticket aperti. Man mano che i ticket si chiudono, l'indice si riduce da solo: its la dimensione tiene traccia della popolazione aperta, mai del totale.

Un valore di partizione statico ("OPEN"`) qui va bene proprio perché l'insieme rimane piccolo. Un enorme set aperto avrebbe bisogno di una chiave di partizione frammentata, ma il "sottoinsieme piccolo" l'indice è esattamente dove un valore è la chiamata giusta.

La transizione che lo fa funzionare è una solaaggiornare l'espressione- rimuovendo il attributo quando il ticket viene risolto.

Prototipa la clausola "REMOVE" e la condizione chiave digitata per il lato di lettura nel file DynamoDB Expression Builder, invece di assemblando manualmente i segnaposto "ExpressionAttributeNames" e ":val".

Fallo in DynoTable

La parte difficile di un indice sparso è vedere quali elementi lo hanno creato nell'indice rispetto al quale è caduto silenziosamente.

DynoTable ti consente di passare da una visualizzazione tabella a un indice secondario e vedere esattamente il sottoinsieme popolato. In questo modo potrai confermare che un ticket risolto è effettivamente rimasto "open-tickets-index" invece di persistere con una chiave obsoleta.

Insidie e passaggi successivi

Alcune cose da guardare:

• Rimuovi la chiave, non cancellarla. Una stringa vuota non è una chiave di indice valida — la scrittura di openBucket = "" fallisce con una ValidationException, quindi l'elemento non lo è mai indicizzato con esso. Per eliminare un elemento dall'indice è necessario "RIMUOVERE" l'attributo.
• L'indice èeventualmente coerente. GSIs si aggiorna in modo asincrono, quindi a Il ticket appena risolto potrebbe ancora apparire brevemente - si legge GSI supporta solo la coerenza eventuale. Non fidarti di "questo biglietto è aperto in questo momento".
• Menteproiettatoattributi. Un Query sull'indice restituisce solo il attributi proiettati in esso. Se la dashboard necessita di oggetto e priorità, proiettali o paga un extra di GetItem per l'intero articolo base.
• Sia GSI che LSI possono essere sparsi — la leva è la stessa: omettere gli indici chiave di ordinamento sugli elementi che non desideri indicizzare. A GSI di solito è la soluzione migliore, però: puoi aggiungerlo dopo la creazione della tabella e assegnargli il proprio schema di chiavi e capacità. GSI vs. LSI risolve il compromesso.

Gli indici sparsi sono una delle idee più antiche del modello. L'originale Documento su Amazon Dynamo del 2007 ha costruito il negozio servendo modelli di accesso noti e ad alto volume a basso costo.

Un indice sparso è esattamente questo: modella le chiavi in modo che la query comune non legga nulla non ha bisogno.

Per costruirne e ispezionarne uno dal vero, download DynoTable, puntalo su la tua tabella e capovolgi la visualizzazione dei dati sul tuo GSI sparso: guarda l'aggiornamento del sottoinsieme come gli elementi ottengono e perdono la chiave dell'indice.