Adaptive capacity di DynamoDB

DynamoDB distribuisce la tua tabella tra le partizioni, ma il tuo traffico raramente si distribuisce uniformemente. La burst capacity e la adaptive capacity sono i due meccanismi automatici che impediscono a un carico sbilanciato di andare in throttling — finché non colpisce un limite rigido.

Cos'è l'adaptive capacity di DynamoDB?

L'adaptive capacity di DynamoDB è un meccanismo automatico che sposta il throughput inutilizzato verso una hot partition, così che una chiave sbilanciata non vada in throttling mentre il resto della tabella resta inattivo. Abbinata alla burst capacity, assorbe i picchi e lo squilibrio sostenuto 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 picchi brevi. È un cuscinetto, non una funzionalità da regolare.
• La adaptive capacity alza automaticamente il throughput per una partizione "calda" — attingendo dalla capacità inutilizzata del resto della tua tabella — così che una chiave sbilanciata non vada in throttling.
• Isolerà persino un item caldo 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 resta nessun posto da cui prendere in prestito — una chiave davvero calda va comunque in throttling.

Conosci prima il tetto di partizione

Ogni partizione è limitata indipendentemente: 3.000 unità di lettura e 1.000 unità di scrittura al secondo. Quel limite è fisico, non provisioned — vale sia su tabelle provisioned che on-demand. (AWS, Burst and adaptive capacity.)

Venendo da SQL, ragioni sul carico totale del server. In DynamoDB l'unità che va in throttling è la singola partizione, e una sola chiave sbilanciata può fondersi mentre la tabella sta inattiva al 90%. È il divario che entrambi i meccanismi esistono per colmare.

La burst capacity assorbe il picco breve

Ogni volta che non usi completamente il throughput di una partizione, DynamoDB accantona l'avanzo. Fino a 300 secondi di quella capacità inutilizzata sono tenuti in riserva, e un burst improvviso può prosciugarli più velocemente di quanto il tuo tasso al secondo consentirebbe normalmente.

È invisibile e automatico. Non puoi dimensionarlo, e DynamoDB può spenderne in silenzio una parte per il proprio lavoro in background. Trattalo come un cuscinetto per traffico a raffica — mai come margine su cui puoi pianificare.

La adaptive capacity potenzia la hot partition

La burst capacity gestisce i picchi brevi. La adaptive capacity gestisce lo squilibrio sostenuto. Quando una partizione è calda mentre le sue vicine sono inattive, DynamoDB sposta throughput verso quella calda — fino al totale della tabella e al tetto di partizione.

Diciamo che gestisci una tabella di telemetria di flotta con chiavi VEHICLE#<id> (partizione) e TS#<epoch> (sort). Un furgone delle consegne in una zona di flash sale emette 10× i ping di qualsiasi altro. La sua partizione è calda; le partizioni degli altri 200 furgoni sono quasi inattive.

La adaptive capacity se ne accorge e solleva il throughput di quell'unica partizione, attingendo dalla capacità inutilizzata delle partizioni fredde. Nessuna config, nessun costo, nessun warm-up — da maggio 2019 il boost è effettivamente istantaneo. (AWS Database Blog, "How DynamoDB adaptive capacity accommodates uneven access patterns".)

La partizione del furgone caldo ha bisogno di 150 WCU ma la sua quota equa di 100 WCU andrebbe in throttling; la adaptive capacity prende in prestito le WCU inattive dalle partizioni fredde per coprirla.

Isolamento: quando il problema è un singolo item

Lo squilibrio non è sempre per-chiave — a volte un singolo item è incandescente. Se un traffico incessante colpisce un item VEHICLE#HOT, lo split-for-heat di DynamoDB ribilancia le partizioni così che l'item acceduto di frequente atterri da solo.

Una volta isolata, la chiave di quel singolo item può tirare l'intero tetto di partizione: 3.000 RCU e 1.000 WCU. Quello è il limite assoluto per una chiave — non c'è meccanismo sopra di esso. (AWS, Key range throughput exceeded.)

Un avvertimento da fissare: la adaptive capacity non dividerà un'item collection tra le partizioni quando la tabella ha un Local Secondary Index. Un LSI lega la collection a una sola partizione — vedi GSI vs LSI per capire perché.

Quando la adaptive capacity non può salvarti

Questa è la trappola. Entrambi i meccanismi spostano il throughput in giro; nessuno dei due ne crea più di quanto una partizione consenta fisicamente.

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 abituale: appendi un suffisso (VEHICLE#HOT#0 … #9) così che le scritture si distribuiscano tra le partizioni, poi riaggreghi le letture.

Quel fan-in è esso stesso un access pattern da modellare deliberatamente, allo stesso modo in cui pianificheresti un percorso di query nel single-table design — la adaptive capacity compra tempo, non un lasciapassare gratuito sul design delle chiavi.

Vedilo sulla tua tabella

La adaptive capacity è invisibile per design, quindi ci ragioni attraverso un sintomo: quali chiavi sono calde. Quando costruisci il percorso di scrittura a shard, l'Expression Builder genera la sintassi PutItem e Query per una chiave con suffisso.

Per osservare come una chiave si distribuisce davvero sui tuoi dati, scarica DynoTable e ispeziona la distribuzione delle partizioni sulle tue tabelle reali prima di assumere che la adaptive capacity abbia tutto sotto controllo. Per il lato lettura dello squilibrio, vedi Query vs Scan.