Adaptive Capacity in DynamoDB: cosa fa e cosa non fa
DynamoDB distribuisce la tua tabella tra le partizioni, ma il tuo traffico raramente si distribuisce in modo uniforme. La burst capacity e la capacità adattiva sono i due meccanismi automatici che impediscono a un carico di lavoro sbilanciato di generare throttling — finché non raggiunge un limite fisico.
Cos'è la capacità adattiva di DynamoDB?
La capacità adattiva di DynamoDB è un meccanismo automatico che sposta il throughput inutilizzato verso una , così che una chiave sbilanciata non generi throttling mentre il resto della tabella resta inattivo. Abbinata alla burst capacity, assorbe picchi e sbilanciamenti prolungati gratuitamente — ma non può spingere una singola chiave oltre il tetto di partizione.
- La burst capacity ti presta fino a 5 minuti (300 secondi) di throughput inutilizzato per superare i picchi brevi. È un cuscinetto, non una funzione che regoli.
- La capacità adattiva aumenta automaticamente il throughput per una — attingendo dal resto della capacità inutilizzata della tua tabella — così che una chiave sbilanciata non generi throttling.
- Isolerà persino un hot item sulla propria partizione, dando a una singola chiave fino al tetto di partizione di 3.000 RCU / 1.000 WCU.
- Non è una licenza per ignorare il design delle chiavi. Oltre il tetto per-partizione non c'è più nulla da cui prendere in prestito — una chiave davvero hot genera comunque throttling.
Conosci prima il tetto di partizione
Ogni partizione è limitata in modo indipendente: 3.000 unità di lettura e 1.000 unità di scrittura al secondo. Quel limite è fisico, non con provisioning — vale sia sulle tabelle con provisioning sia On-Demand. (AWS, Burst and adaptive capacity.)
Venendo da SQL, ragioni sul carico totale del server. In DynamoDB l'unità che genera throttling è la singola partizione, e una chiave sbilanciata può fondersi mentre la tabella resta inattiva al 90%. È il divario che entrambi i meccanismi esistono per colmare.
La burst capacity assorbe il picco breve
Ogni volta che non usi del tutto il throughput di una partizione, DynamoDB mette da parte l'avanzo. Fino a 300 secondi di quella capacità inutilizzata viene tenuta in riserva, e un burst improvviso può prosciugarla più in fretta di quanto normalmente permetterebbe la tua velocità al secondo.
È invisibile e automatica. Non puoi dimensionarla, e DynamoDB può spenderne una parte in silenzio per il proprio lavoro in background. Trattala come un cuscinetto per il traffico a raffiche — mai come margine su cui puoi contare in fase di pianificazione.
La capacità adattiva potenzia la hot partition
La burst capacity gestisce i picchi brevi. La capacità adattiva gestisce lo sbilanciamento prolungato. Quando una partizione è hot mentre le sue vicine sono inattive, DynamoDB sposta il throughput verso quella hot — fino al totale della tabella e al tetto di partizione.
Diciamo che gestisci una tabella di telemetria di flotta con chiave VEHICLE#<id> (partizione) e
TS#<epoch> (ordinamento). Un furgone di consegne in una zona di flash-sale emette 10× i ping di
qualsiasi altro. La sua partizione è hot; le partizioni degli altri 200 furgoni sono quasi inattive.
La capacità adattiva se ne accorge e solleva il throughput di quella singola partizione, attingendo dalla capacità inutilizzata delle partizioni fredde. Nessuna configurazione, nessun costo, nessun warm-up — da maggio 2019 il potenziamento è effettivamente istantaneo. (AWS Database Blog, "How DynamoDB adaptive capacity accommodates uneven access patterns".)
La partizione del furgone hot ha bisogno di 150 WCU ma la sua quota equa di 100 WCU genererebbe throttling; la capacità adattiva prende in prestito le WCU inattive dalle partizioni fredde per coprirle.
Isolamento: quando il problema è un singolo item
Lo sbilanciamento non è sempre per-chiave — a volte è un singolo item a essere incandescente. Se
un traffico incessante martella un item VEHICLE#HOT, lo split-for-heat di DynamoDB riequilibra
le partizioni così che l'item ad accesso frequente finisca da solo.
Una volta isolata, la chiave di quel singolo item può raggiungere l'intero tetto di partizione: 3.000 RCU e 1.000 WCU. È il soffitto assoluto per una chiave — non c'è alcun meccanismo al di sopra. (AWS, Key range throughput exceeded.)
Un avvertimento da fissare: la capacità adattiva non dividerà una tra le partizioni quando la tabella ha un . Un LSI lega la collezione a una sola partizione — vedi GSI vs LSI per il perché.
Quando la capacità adattiva non può salvarti
È la trappola. Entrambi i meccanismi spostano il throughput in giro; nessuno dei due crea più di quanto una partizione fisicamente consenta.
| Scenario | Burst | Adattiva | Esito |
|---|---|---|---|
| Picco breve, la tabella ha margine | Lo copre | — | Nessun throttle |
| Sbilanciamento prolungato, vicine fredde | — | Potenzia la hot | Nessun throttle |
| Un item, < 3K RCU / 1K WCU | — | Lo isola | Nessun throttle |
| Un item, > tetto di partizione | Prosciugata in fretta | Al soffitto | Throttling — serve ridisegno |
| Molte chiavi hot insieme, tabella satura | Prosciugata in fretta | Nulla di inattivo | Throttling — serve ridisegno |
Se una singola chiave ha legittimamente bisogno di più di 1.000 scritture al secondo, nessun meccanismo automatico ti salva — devi distribuire il carico su più chiavi.
Il write sharding è la soluzione consueta: aggiungi un suffisso (VEHICLE#HOT#0 … #9) così le
scritture si spargono tra le partizioni, poi raccogli di nuovo le letture.
Quella raccolta è a sua volta un pattern di accesso da modellare deliberatamente, allo stesso modo in cui pianificheresti un percorso di query in single-table design — la capacità adattiva ti compra tempo, non un lasciapassare sul design delle chiavi.
Vedilo sulla tua tabella
La capacità adattiva è invisibile per design, quindi ci ragioni attraverso un sintomo: quali chiavi
sono hot. Quando costruisci il percorso di scrittura con sharding, l'
Expression Builder genera la sintassi PutItem e Query per
una chiave con suffisso.
Per osservare come una chiave si distribuisce effettivamente tra i tuoi dati, scarica DynoTable ed esegui un GROUP BY sulla tua chiave di partizione nel SQL Workbench per vedere come gli Item si accumulano per chiave prima di dare per scontato che la capacità adattiva abbia risolto tutto. Per il lato lettura dello sbilanciamento, vedi Query vs Scan.