Partitions physiques DynamoDB

Une partition physique est l'unité sur laquelle DynamoDB stocke réellement tes données : une tranche de SSD, répliquée entre Availability Zones, qui tient une tranche de ton key space. Ton table est une chose logique. Les partitions sont là où les octets — et les limites de throughput — vivent vraiment.

Comment fonctionnent les partitions DynamoDB ?

DynamoDB stocke ton table à travers des partitions physiques — des tranches SSD répliquées entre Availability Zones. Chacune plafonne à ~10 GB, 3 000 unités de lecture/sec, et 1 000 unités d'écriture/sec. Le hash de ta partition key décide sur quelle partition un item atterrit, et DynamoDB split les partitions automatiquement quand elles grandissent ou deviennent hot.

• Chaque partition plafonne à ~10 GB de stockage, 3 000 unités de lecture/sec, et 1 000 unités d'écriture/sec. Ces plafonds sont par partition, pas par table.
• Le hash de ta partition key choisit la partition. Les items avec la même clé atterrissent ensemble ; un seul item hot — ou une sort key monotone — est ce qui pin une partition.
• DynamoDB split les partitions pour toi — sur la taille, et sur la chaleur soutenue — y compris en découpant l'item collection d'une clé à une frontière de sort key, sauf si un LSI ou une sort key toujours croissante le bloque.
• Le throttling avec de la capacité à spare est le signal. Une erreur ProvisionedThroughputExceeded alors que ton table est à 5 % d'usage signifie qu'une seule partition est maxée.

Comment un item trouve sa partition

DynamoDB passe la valeur de ta partition key dans une fonction de hash interne. La sortie du hash choisit la partition physique. Même clé en entrée, même partition en sortie — à chaque fois.

Venant de SQL, il n'y a pas d'analogie. Pas de B-tree d'index à tuner, pas de shard key assignée à la main. Le placement est un hash que tu ne contrôles pas et ne vois jamais.

Les items qui partagent une partition key forment une item collection, stockés ensemble et triés par sort key. C'est ce qui rend un Query sur une clé bon marché — il lit une plage contiguë sur une partition. (Vois Query vs Scan.)

Prends un store d'événements de match pour un jeu. Les clés du table sont arenaId (partition) et eventKey (sort) :

# Item
arenaId    = "ARENA#7f3a"
eventKey   = "EVT#1719100800#a91c"
playerTag  = "Nightjar"
dmgDealt   = 412

Chaque événement pour l'arena 7f3a hashe vers la même partition et s'empile en ordre de sort key. Excellent pour « lire la timeline de ce match ». Une liabilité si cette arena prend tout le trafic.

Les trois plafonds que chaque partition enforce

Une seule partition est conçue pour délivrer au plus :

Source : le guide AWS Best practices for designing partition keys.

La taille d'item scale le calcul. Un item de 20 KB coûte 5 unités de lecture par lecture strongly-consistent, donc une partition sert ~600 telles lectures/sec avant de throttle — pas 3 000. Arrondis le coût d'écriture vers le haut par 1 KB, le coût de lecture vers le haut par 4 KB.

Ces plafonds sont par partition, pas par table. Ton table peut être provisionné pour 40 000 WCU et throttle encore, parce que toutes les écritures martèlent une partition qui plafonne à 1 000.

Comment les partitions split

DynamoDB ajoute des partitions automatiquement dans deux cas. Tu ne lances jamais de commande.

Split sur la taille. Quand une partition se remplit vers ~10 GB, DynamoDB split sa plage de clés en deux et déplace la moitié des items vers une nouvelle partition. Le stockage grandit de façon transparente ; tes lectures et écritures continuent de marcher pendant ce temps.

Split pour la chaleur. Quand une partition prend un trafic soutenu près de son plafond de throughput, DynamoDB split la plage de clés chaude pour que chaque moitié atterrisse sur sa propre partition. AWS appelle ça le mécanisme split-for-heat. Les courts bursts de throttling qui s'arrêtent seuls signifient souvent que split-for-heat a kické — bien que de brefs pics puissent aussi juste épuiser la burst capacity.

Le splitting achète de la place à travers beaucoup de clés, et split-for-heat peut même découper l'item collection d'une clé à une coupe de sort key. Ce qu'il ne peut pas étaler, c'est un seul item hot, une sort key toujours croissante, ou une collection pinnée par un LSI.

Pourquoi une hot key bat le splitter

Le splitting redistribue des plages de partition keys. Si ton trafic se concentre sur une valeur de clé, chaque requête hashe vers la même partition, et il ne reste aucune plage à diviser.

Si l'arena 7f3a est une finale de tournoi qui tire 4 000 écritures/sec tandis que chaque autre arena est idle, tu throttle à 1 000 — et split-for-heat ne peut pas te sauver ici, parce que l'eventKey préfixé timestamp est monotone, donc chaque nouvelle écriture atterrit au leading edge d'une plage de sort key étroite sans rien à découper. La raison de throttle plus récente KeyRangeThroughputExceeded nomme exactement ça : la plage de clés d'une partition, pas le table, est au-dessus de sa limite.

Le fix est dans le data model, pas le slider de capacité. Write-shard la hot key : ajoute un petit suffixe pour qu'une arena logique s'étale sur N partitions physiques.

arenaId = "ARENA#7f3a#3"   # shard 0..9, chosen per write

Les lectures fan-out ensuite à travers les shards et merge côté client. Tu peux prototyper les formes de clés et le Query pour chaque shard avec le DynamoDB Expression Builder avant de toucher une ligne de code applicatif.

Une nuance : l'exception LSI

Il y a un cas où le stockage est plafonné par partition key. Sans Local Secondary Index, une item collection split à travers autant de partitions qu'il faut pour servir à la fois ses octets stockés et son throughput — des milliards de valeurs de sort key vont bien.

Ajoute un LSI, et toute la collection pour une partition key doit tenir dans une seule partition de 10 GB, parce que le LSI la partage. C'est la falaise par-PK couverte dans GSI vs LSI — une autre raison pour laquelle la plupart des équipes se tournent vers les GSIs.

Concevoir pour que les partitions restent cool

Le levier que tu contrôles vraiment est la partition key. Choisis-en une avec beaucoup de valeurs distinctes par rapport au nombre de lignes, pour que le trafic s'étale uniformément. (Plus de patterns dans single-table design.)

• Clé à haute cardinalité. Une clé per-user ou per-tenant bat une clé per-day ou per-status que tout le monde martèle en même temps.
• Surveille les hot keys connues. Une valeur « current tournament » ou « today » est un risque de concentration avant que tu ships, pas après.
• Shard la hot key inévitable. Quand une clé doit prendre un trafic démesuré, un suffixe est l'échappatoire standard.

Le throttling avec de la capacité à spare est ton signal qu'une partition est hot. Inspecte l'item collection biaisée et répète un layout de clé shardée dans DynoTable — pointe-le sur ton propre table, GROUP BY la partition key dans le SQL Workbench pour voir quelles clés dominent, et modélise le fix avant que ça te page.