Hot Partition in DynamoDB

DynamoDB distribuisce i tuoi dati su molte partizioni fisiche, ognuna con la propria fetta di throughput. Una hot partition si verifica quando una chiave attira molte più letture o scritture di quante la sua fetta possa servire — così le richieste verso quella chiave vanno in throttling mentre il resto della tabella resta inattivo.

Che cos'è una hot partition in DynamoDB?

Una hot partition in DynamoDB si verifica quando una chiave di partizione assorbe molte più letture o scritture di quante la sua fetta di throughput possa servire, così le richieste verso quella chiave vanno in throttling mentre il resto della tabella resta inattivo. La causa è il design della chiave — un Item "celebrità", una chiave a bassa cardinalità, la data di oggi — non la dimensione della tabella. La cura è distribuire le scritture.

• La causa è il design della chiave, non la dimensione della tabella. Una chiave di partizione che concentra il traffico — un utente "celebrità", un flag status="OPEN", la data di oggi — è la trappola.
• La adaptive capacity aiuta, ma non è una soluzione. DynamoDB riequilibria il calore automaticamente, ma un singolo Item o una singola chiave possono comunque superare ciò che una partizione può servire.
• La cura è distribuire le scritture. Aggiungi entropia alla chiave (write sharding) oppure sposta il percorso di lettura caldo su un pattern di accesso meglio distribuito.
• Venendo da SQL, questo non ha equivalenti. Una tabella relazionale non ha il concetto di "il valore di indice di una riga è troppo popolare" — il modello a throughput-per-chiave piatto di DynamoDB ce l'ha.

Perché esistono le partizioni

DynamoDB è l'erede in produzione del paper Amazon Dynamo del 2007, che ha scambiato il modello SQL single-node con uno partizionato e scalato orizzontalmente. I dati sono frammentati tramite un hash della chiave di partizione su nodi di storage fisici.

Ogni partizione contiene una quantità limitata di dati e serve una quantità limitata di throughput. AWS documenta un tetto rigido di 3.000 read unit e 1.000 write unit per partizione, al secondo (AWS — partition behavior).

Quel tetto è tutta la storia. Il throughput provisioned della tua tabella è la somma di tutte le partizioni — ma ogni singola chiave finisce sempre su una sola partizione.

Riconosci la trappola: traffico che si accumula su una chiave

Il throughput è condiviso in modo uniforme solo se i tuoi accessi sono distribuiti uniformemente tra le chiavi. Nel momento in cui una chiave riceve traffico sproporzionato, va in throttling da sola mentre la capacità complessiva della tabella resta inutilizzata.

Forme classiche di hot key:

• Un Item "celebrità" — un utente, prodotto o tenant che tutti leggono.
• Una chiave di partizione a bassa cardinalità — status, country, type. Pochi valori distinti significano poche partizioni che fanno tutto il lavoro.
• Una chiave a bucket temporale — PK = "2026-06-23". Ogni scrittura di oggi martella una partizione; quella di ieri resta fredda per sempre.

Venendo da SQL, nulla di tutto ciò avrebbe importanza. Un indice B-tree su un valore popolare va benissimo. In DynamoDB il valore popolare è l'unità di posizionamento fisico, quindi la popolarità diventa un dirupo di throughput.

Un esempio pratico: la leaderboard "celebrità"

Diciamo che gestisci una leaderboard di gioco globale. I punteggi vivono in una tabella con chiavi così:

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

Le letture prendono i primi N per punteggio; le scritture aggiornano il currentScore di un giocatore dopo ogni partita. Ogni riga nella board globale condivide una chiave di partizione — BOARD#global — quindi ogni lettura e scrittura finisce su una sola partizione.

Aggiungi uno streamer con due milioni di spettatori live che spammano il pulsante di refresh sul proprio rank, e quella singola partizione supera le 3.000 read unit. Ottieni ProvisionedThroughputExceededException sulla board globale mentre ogni altra board nella tabella è inattiva.

Il footgun è il collasso su BOARD#global: hai modellato una singola board logica come una singola chiave fisica.

Distribuisci le scritture: lo sharding della chiave

La soluzione è fabbricare cardinalità. Aggiungi un suffisso di shard alla chiave di partizione così una board logica si distribuisce su N partizioni fisiche:

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

Le scritture ora si distribuiscono su dieci partizioni invece di una — dieci volte il margine di scrittura. Il costo: una lettura dell'intera board deve colpire tutti e dieci gli shard e fare il merge, perché nessuna singola Query attraversa i confini degli shard. Scambi la semplicità di lettura per la distribuzione delle scritture.

AWS chiama questo write sharding e lo raccomanda proprio per chiavi a bassa cardinalità ad alta velocità (AWS — using write sharding).

È lo stesso istinto di key overloading dietro il single-table design — modelli la chiave per il pattern di accesso, non per come i dati "naturalmente" si dispongono.

Lascia che la adaptive capacity faccia la parte facile

DynamoDB include la adaptive capacity, trattata nella sessione re:Invent 2018 "Amazon DynamoDB Under the Hood" (DAT401). Ridistribuisce continuamente il throughput di una tabella verso le partizioni sotto calore, e isola una chiave persistentemente calda sulla propria partizione (isolamento a livello di chiave, AWS — bursting & adaptive capacity).

È istantanea e gratuita — ma è limitata dalla fisica. La adaptive capacity può spostare il calore tra chiavi; non può spingere una singola chiave oltre il tetto per partizione. Una vera chiave "celebrità" va comunque in throttling. Lo sharding è ciò che ti porta oltre quel muro.

Ecco il percorso decisionale una volta che vedi throttling su una chiave trafficata:

La maggior parte delle hot partition si risolve in "fai lo shard della chiave" oppure "lascia che la adaptive capacity la assorba" — il diagramma indica solo su quale ramo ti trovi.

Diagnostica prima di riprogettare

Non puoi correggere ciò che non vedi. Il throttling si presenta come ProvisionedThroughputExceededException (provisioned) o come ThrottledRequests e il ThrottleCount per partizione in CloudWatch (AWS — CloudWatch metrics).

Abbinalo a CloudWatch Contributor Insights for DynamoDB, che classifica le tue chiavi più accedute direttamente — il modo più rapido per confermare per nome una chiave "celebrità" (AWS — Contributor Insights).

Quando testi il percorso di lettura con sharding, costruirai a mano la KeyConditionExpression per ogni shard. Generale senza refusi con il DynamoDB Expression Builder — emette la forma esatta PK = :pk AND begins_with(SK, :sk) per ogni shard.

Errori da evitare

• Chiavi auto-incrementanti o monotone. ID sequenziali e timestamp come chiave di partizione instradano scritture consecutive sulla stessa partizione. Aggiungi un prefisso hash.
• Fare lo sharding del percorso a prevalenza letture senza necessità. Se dominano le letture e l'Item è piccolo, una cache o un GSI con una chiave meglio distribuita spesso batte il costo di lettura scatter-gather dello sharding.
• Confondere una hot partition con uno Scan lento. Uno Scan è lento perché legge tutto; una hot partition va in throttling perché una chiave è sovraccarica. Problemi diversi — vedi Query vs Scan.

Prossimi passi

Abbozza le chiavi con sharding, poi verifica il percorso di lettura su dati reali. Costruisci le condizioni per shard nel DynamoDB Expression Builder, e scarica DynoTable per eseguirle sulle tue tabelle e osservare quali partizioni prendono davvero il calore.