Les 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 sur plusieurs zones de disponibilité, contenant une tranche de ton espace de clés. Ta table est une chose logique. Les partitions sont là où vivent vraiment les octets — et les limites de débit.

Comment fonctionnent les partitions DynamoDB ?

DynamoDB stocke ta table sur des partitions physiques — des tranches de SSD répliquées sur plusieurs zones de disponibilité. Chacune plafonne à ~10 Go, 3 000 unités de lecture/s et 1 000 unités d'écriture/s. Le hash de ta détermine sur quelle partition atterrit un item, et DynamoDB scinde les partitions automatiquement à mesure qu'elles grossissent ou s'échauffent.

Chaque partition plafonne à ~10 Go de stockage, 3 000 unités de lecture/s et 1 000 unités d'écriture/s. Ces plafonds sont par partition, pas par table.
Le hash de ta clé de partition choisit la partition. Les items avec la même clé atterrissent ensemble ; une clé chaude signifie une partition chaude.
DynamoDB scinde les partitions pour toi — sur la taille, et sur la chaleur soutenue — mais il ne peut pas réparer une clé qui canalise tout le trafic vers un seul endroit.
Throttler alors qu'il reste de la capacité est le signe. Une erreur ProvisionedThroughputExceeded pendant que ta table est à 5 % d'utilisation signifie qu'une seule partition est saturée.

Comment un item trouve sa partition

DynamoDB injecte la valeur de ta clé de partition 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.

En venant de SQL, il n'y a pas d'analogue. Pas de B-tree d'index que tu règles, pas de clé de shard que tu assignes à la main. Le placement est un hash que tu ne contrôles pas et que tu ne vois jamais.

Les items partageant une clé de partition forment une collection d'items, stockés ensemble et triés par clé de tri. C'est ce qui rend un Query sur une clé bon marché — il lit un segment contigu sur une seule partition. (Vois Query vs Scan.)

Prenons un stock d'événements de match pour un jeu. Les clés de la table sont arenaId (partition) et eventKey (tri) :

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

Chaque événement de l'arène 7f3a se hache vers la même partition et s'empile en ordre de clé de tri. Génial pour « lire la timeline de ce match ». Un handicap si cette seule arène prend tout le trafic.

Les trois plafonds que chaque partition impose

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

Limite	Par partition	Compté comme
Stockage	~10 Go	octets bruts des items
Capacité de lecture	3 000 unités de lecture/s	1 RU = une lecture fortement cohérente de 4 Ko
Capacité d'écriture	1 000 unités d'écriture/s	1 WU = une écriture de 1 Ko

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

La taille de l'item module le calcul. Un item de 20 Ko coûte 5 unités de lecture par lecture fortement cohérente, donc une partition sert ~600 lectures de ce genre/s avant de throttler — pas 3 000. Arrondis le coût d'écriture au 1 Ko supérieur, le coût de lecture au 4 Ko supérieur.

Le piège : ce sont des limites de partition, pas de table. Ta table peut être provisionnée pour 40 000 WCU et throttler quand même, parce que toutes les écritures martèlent une seule partition qui plafonne à 1 000.

Comment les partitions se scindent

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

Scission sur la taille. Quand une partition se remplit vers ~10 Go, DynamoDB scinde 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 fonctionner pendant tout ce temps.

Scission pour la chaleur. Quand une partition prend un trafic soutenu près de son plafond de débit, DynamoDB scinde la plage de clés chaude pour que chaque moitié atterrisse sur sa propre partition. AWS appelle ça le mécanisme split-for-heat. De courtes rafales de throttling qui s'arrêtent d'elles-mêmes signifient généralement qu'une scission vient d'avoir lieu.

La scission achète de la place à travers plusieurs clés, mais le nœud du bas est le hic : une scission divise une plage de clés, jamais une seule clé.

Pourquoi une clé chaude bat le scindeur

Voici le piège. La scission redistribue des plages de clés de partition. Si ton trafic se concentre sur une seule valeur de clé, chaque requête se hache vers la même partition, et il ne reste aucune plage à diviser.

Si l'arène 7f3a est une finale de tournoi tirant 4 000 écritures/s pendant que chaque autre arène est inactive, tu throttleras à 1 000 — et une scission ne peut pas aider, parce que les 4 000 partagent une seule clé. La nouvelle raison de throttle KeyRangeThroughputExceeded nomme exactement ceci : la plage de clés d'une partition, pas la table, dépasse sa limite.

La solution est dans le modèle de données, pas dans le curseur de capacité. Write-shard la clé chaude : ajoute un petit suffixe pour qu'une arène logique se répartisse sur N partitions physiques.

arenaId = "ARENA#7f3a#3"   # shard 0..9, choisi par écriture

Les lectures s'éventent alors sur les shards et fusionnent côté client. Tu peux prototyper les formes de clé et le Query pour chaque shard avec le constructeur d'expressions DynamoDB avant de toucher une ligne de code applicatif.

Une nuance : l'exception LSI

Il y a un cas où le stockage est plafonné par clé de partition. Sans Local Secondary Index, une collection d'items se scinde automatiquement sur autant de partitions qu'il en faut — des milliards de valeurs de clé de tri ne posent aucun problème.

Ajoute un LSI, et toute la collection pour une clé de partition doit tenir dans une seule partition de 10 Go, 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 optent pour les GSI.

Concevoir pour que les partitions restent fraîches

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

Clé à forte cardinalité. Une clé par utilisateur ou par locataire bat une clé par jour ou par statut que tout le monde martèle en même temps.
Surveille les clés chaudes connues. Une valeur « tournoi en cours » ou « aujourd'hui » est un risque de concentration avant que tu ne livres, pas après.
Shard la clé chaude inévitable. Quand une clé doit prendre un trafic démesuré, un suffixe est la porte de secours standard.

Throttler alors qu'il reste de la capacité est ton signal qu'une partition est chaude. Inspecte les items fautifs et répète une disposition de clé shardée dans DynoTable — pointe-le sur ta propre table, trouve la clé surchargée et modélise la solution avant qu'elle ne te réveille.