Partizioni attive DynamoDB: come trovarle e risolverle

DynamoDB distribuisce i tuoi dati su molte partizioni fisiche, ciascuna con la propria fetta di throughput. Una partizione calda è quando una chiave attira molte più letture o scrive di quanto la sua porzione possa servire, quindi richiede a quel tasto di accelerare mentre il resto del tavolo è inattivo.

Cos'è una partizione hot DynamoDB?

Una partizione hot DynamoDB si verifica quando un assorbe molte più letture o scritture di quanto la sua fetta di throughput possa servire, quindi le richieste a quel tasto vengono accelerate mentre il resto della tabella rimane inattivo. La causa è il design della chiave (un oggetto di una celebrità, una chiave con bassa cardinalità, la data odierna) e non le dimensioni della tabella. La cura si sta diffondendo scrive.

La causa è il design principale, non le dimensioni del tavolo. Un concentrato il traffico - un utente famoso, una bandiera status="OPEN", la data di oggi - è la trappola.
La capacità adattiva aiuta, ma non è una soluzione. DynamoDB riequilibra il calore automaticamente, ma un singolo elemento o una singola chiave possono comunque superare quello la partizione può servire.
La cura si sta diffondendo scrive. Aggiungi entropia alla chiave (scrittura sharding) o spostare il percorso di lettura a caldo su un modello di accesso meglio distribuito.
Proveniente da SQL, questo non ha equivalenti. Una tabella relazionale non ha nozione di "il valore dell'indice di una riga è troppo popolare" - modello flat throughput per chiave di DynamoDB lo fa.

Perché esistono le partizioni

DynamoDB è l'erede produttivo della carta Amazon Dynamo del 2007, che commerciava il modello SQL a nodo singolo per uno partizionato e scalabile orizzontalmente. I dati vengono suddivisi da un hash della chiave di partizione sui nodi di archiviazione fisici.

Ciascuna partizione contiene una quantità limitata di dati e ne serve una quantità limitata rendimento. AWS documenta un limite rigido di 3.000 RCU e 1.000 WCU per partizione, al secondo: lo stesso limite massimo per l'ingresso fornito e su richiesta us-east-1 (AWS — comportamento della partizione). La modalità di fatturazione non aumenta il limite fisico; cambia solo la modalità di spesa a livello di tabella è misurato. Utilizza il calcolatore dei prezzi per costo a livello di tabella e Contributor Insights per vedere se ci sono limitazioni limitato a partizioni e limitato a tabelle.

Quel soffitto è tutta la storia. Il throughput della tua tabella è la somma su tutte le partizioni. La raccolta di elementi di una chiave inizia su una partizione e split-for-heat può ritagliarlo su diversi confini della chiave di ordinamento, a meno che non sia la tabella ha un LSI o la chiave di ordinamento è in continuo aumento, il che lo blocca a uno.

Dai un nome alla trappola: traffico che si accumula su una chiave

Il throughput è condiviso equamente solo se l'accesso è distribuito equamente tra le chiavi. Nel momento in cui una chiave riceve un traffico sproporzionato, rallenta da sola mentre l'altra la capacità complessiva della tabella rimane inutilizzata.

Forme classiche dei tasti di scelta rapida:

Un articolo di una celebrità: un utente, un prodotto o un inquilino che tutti leggono.
Una chiave di partizione a bassa cardinalità: status, country, type. Pochi distinti valori significa che poche partizioni eseguono tutto il lavoro.
Una chiave a intervalli di tempo: PK = "2026-06-23". Ogni scrittura oggi ne martella una partizione; quello di ieri sarà freddo per sempre.

Venendo da SQL, nessuno di questi avrebbe importanza. Un indice B-tree su un valore popolare è bene. In DynamoDB il valore popolare è l'unità di posizionamento fisico, quindi la popolarità diventa un precipizio.

Un esempio pratico: la classifica delle celebrità

Supponiamo che tu gestisca una classifica globale dei giochi. I punteggi si trovano in una tabella così composta:

PK = "BOARD#global"
SK = "PLAYER#<playerId>"

Le letture prendono la prima N in base al punteggio; scrive bump currentScore di un giocatore dopo ciascuno partita. Ogni riga nella scheda globale condivide una chiave di partizione: BOARD#global

quindi ogni lettura e scrittura finisce su una singola partizione.

Aggiungi uno streamer con due milioni di spettatori dal vivo che inviano spam al pulsante di aggiornamento sul loro proprio rango e che una partizione supera le 3.000 unità di lettura. Ottieni ProvisionedThroughputExceededException sul tabellone globale mentre ogni altro la scheda del tavolo è inattiva.

La pistola è il collasso BOARD#global: hai modellato una singola scheda logica come a unica chiave fisica.

Diffondi le scritture: sharding della chiave

La soluzione è produrre la cardinalità. Aggiungi un suffisso shard alla partizione chiave in modo che una scheda logica si distribuisca su N partizioni fisiche:

PK = "BOARD#global#<shard>"  -- shard = playerId mod 10
SK = "PLAYER#<playerId>"

Le scritture ora sono sparse su dieci partizioni invece che su una: dieci volte la scrittura altezza libera. Il costo: una lettura dell'intera scheda deve colpire tutti e dieci i frammenti e unirli, perché nessun singolo Query supera i confini degli shard. Scambi la semplicità di lettura per scrivere la distribuzione.

Scopri tu stesso la differenza. Incolla una singola chiave ripetuta nel visualizzatore sotto e ogni scrittura finisce in un bucket: la partizione hot. Aggiungi un suffisso shard (BOARD#global#0 … #9) e lo stesso scrive in modo uniforme:

Distribuzione della partition key

Valori della partition key

Un valore di partition key per riga. Ripeti un valore per simulare una hot key.

8 bucket8 chiavi

#0
0
#1
1
#2
1
#3
0
#4
2
#5
2
#6
0
#7
2

Questo è un hash didattico semplificato, non il vero hash interno di DynamoDB. DynamoDB usa una funzione interna non documentata e un numero di partizioni che cresce con la tua tabella — usalo solo per farti un'intuizione di come le chiavi distinte si distribuiscono e una singola hot key si accumula.

Questo è un hash didattico per l'intuizione, non il vero hash interno di DynamoDB: il la funzione reale e i confini della partizione sono interni AWS. Leggilo come "anche diffuso". vs skew", non come una previsione di quale partizione fisica si trova su una chiave.

AWS lo chiama scrittura sharding e lo consiglia proprio per l'alta velocità, chiavi a bassa cardinalità (AWS — utilizzando lo sharding di scrittura).

Questo è lo stesso istinto di dietro design a tabella singola: sei tu a modellare la chiave per modello di accesso, non per come si trovano i dati "naturalmente".

Lascia che la capacità adattiva faccia la parte facile

DynamoDB viene fornito con capacità adattiva, trattata nella sessione re:Invent 2018 "Amazon DynamoDB sotto il cofano" (DAT401). Ridistribuisce continuamente una tabella throughput verso le partizioni che assorbono calore e isolerà un file persistentemente tasto di scelta rapida sulla propria partizione (isolamento a livello di chiave, AWS: capacità di bursting e adattiva).

È istantaneo e gratuito, ma è limitato dalla fisica (come funziona la capacità adattiva). La capacità adattiva può muoversi i tasti heat between e split-for-heat possono persino dividere una raccolta di articoli caldi in un batter d'occhio confine della chiave di ordinamento. Il soffitto per partizione rimane assoluto solo per un singolo caldo elemento, una chiave di ordinamento in costante aumento o una tabella con un LSI, dove una chiave di celebrità accelera ancora. Lo sharding è la soluzione deterministica; split-for-heat è lento e opportunistico, quindi non aspettare.

Percorso decisionale quando vengono visualizzate le limitazioni su un tasto occupato:

La maggior parte delle partizioni attive viene risolta in "shard the key" o "let capacità adattiva assorbilo" - il diagramma mostra esattamente su quale ramo ti trovi.

Effettua la diagnosi prima di riprogettare

Non puoi aggiustare ciò che non puoi vedere. La limitazione si presenta come ProvisionedThroughputExceededException (provisioned) o come ThrottledRequests, ReadThrottleEvents/WriteThrottleEvents e ReadThrottleEventsForKeyRange/WriteThrottleEventsForKeyRange — il conteggi specifici del limite di partizione: in CloudWatch (AWS: parametri CloudWatch).

Abbinalo a CloudWatch Contributor Insights per DynamoDB, che classifica il tuo direttamente le chiavi più consultate: il modo più veloce per confermare la chiave di una celebrità per nome (AWS — Approfondimenti sugli autori). E se non sei ancora sicuro che la causa sia un tasto di scelta rapida, DynamoDB accelera quattro ragioni distinte: inizia da la guida alla limitazione e lascia che i parametri nominino il limite che hai effettivamente raggiunto.

Quando testerai il percorso di lettura partizionato, costruirai manualmente il file KeyConditionExpression per ogni frammento. Genera quelli senza errori di battitura con il file DynamoDB Expression Builder — emette il file forma esatta PK = :pk AND begins_with(SK, :sk) per frammento.

Insidie da evitare

Chiavi di ordinamento in continuo aumento. Una chiave di ordinamento monotona (un timestamp, una sequenza number) forza ogni nuova scrittura nella stessa fine di una raccolta di elementi e split-for-heat non può aiutare: la raccolta rimane limitata a 1.000 unità di scrittura. Aggiungi entropia alla chiave di ordinamento o frammenta la chiave di partizione.
Sharding inutilmente il percorso pesante di lettura. Se le letture dominano e l'elemento lo è piccolo, una cache o un GSI con una chiave meglio distribuita spesso batte il costo di lettura scatter-gather dello sharding.
Confondere una partizione attiva con una Scan lenta. Una Scan è lenta perché legge tutto; una partizione attiva viene limitata perché una chiave è sovraccarica. Problemi diversi: vedere Query vs Scan.

Passaggi successivi

Disegna le chiavi frammentate, quindi verifica il percorso di lettura confrontandolo con dati reali. Costruisci il condizioni per-shard nel Generatore di espressioni DynamoDB e scarica DynoTable per confrontarli con i tuoi tavoli e guarda quali le partizioni in realtà prendono il calore.