Les partitions chaudes DynamoDB

DynamoDB répartit tes données sur de nombreuses partitions physiques, chacune avec sa propre tranche de débit. Une partition chaude, c'est lorsqu'une clé attire bien plus de lectures ou d'écritures que sa tranche ne peut servir — les requêtes vers cette clé throttlent pendant que le reste de la table reste inactif.

Qu'est-ce qu'une partition chaude DynamoDB ?

Une partition chaude DynamoDB, c'est lorsqu'une clé de partition absorbe bien plus de lectures ou d'écritures que sa tranche de débit ne peut servir : les requêtes vers cette clé throttlent pendant que le reste de la table reste inactif. La cause, c'est la conception de la clé — un item célèbre, une clé à faible cardinalité, la date du jour — pas la taille de la table. Le remède, c'est de répartir les écritures.

• La cause est la conception de la clé, pas la taille de la table. Une clé de partition qui concentre le trafic — un utilisateur célèbre, un drapeau status="OPEN", la date du jour — voilà le piège.
• La capacité adaptative aide, mais ce n'est pas une solution. DynamoDB rééquilibre la chaleur automatiquement, mais un seul item ou une seule clé peut malgré tout dépasser ce qu'une partition peut servir.
• Le remède, c'est de répartir les écritures. Ajoute de l'entropie à la clé (write sharding) ou déplace le chemin de lecture chaud vers un mode d'accès mieux réparti.
• En venant de SQL, ça n'a pas d'équivalent. Une table relationnelle n'a aucune notion de « la valeur d'index d'une ligne est trop populaire » — le modèle plat de débit-par-clé de DynamoDB, lui, en a une.

Pourquoi les partitions existent

DynamoDB est l'héritier en production du papier Amazon Dynamo de 2007, qui a échangé le modèle SQL mono-nœud contre un modèle partitionné et scalé horizontalement. Les données sont shardées par un hash de la clé de partition sur des nœuds de stockage physiques.

Chaque partition contient une quantité bornée de données et sert un débit borné. AWS documente un plafond strict de 3 000 unités de lecture et 1 000 unités d'écriture par partition, par seconde (AWS — comportement des partitions).

Ce plafond, c'est toute l'histoire. Le débit provisionné de ta table est la somme sur toutes les partitions — mais une clé donnée n'atterrit jamais que sur une seule partition.

Nomme le piège : le trafic qui s'entasse sur une clé

Le débit est partagé équitablement seulement si tes accès sont répartis équitablement entre les clés. Dès qu'une clé reçoit un trafic disproportionné, elle throttle seule pendant que la capacité globale de la table reste inutilisée.

Les formes classiques de clé chaude :

• Un item célèbre — un utilisateur, un produit ou un tenant que tout le monde lit.
• Une clé de partition à faible cardinalité — status, country, type. Peu de valeurs distinctes signifie peu de partitions qui font tout le travail.
• Une clé bucketée par le temps — PK = "2026-06-23". Chaque écriture du jour martèle une seule partition ; celle d'hier est froide à jamais.

En venant de SQL, rien de tout cela n'aurait d'importance. Un index B-tree sur une valeur populaire, c'est très bien. Dans DynamoDB la valeur populaire est l'unité de placement physique, donc la popularité devient une falaise de débit.

Un exemple concret : le classement avec célébrité

Disons que tu gères un classement de jeu mondial. Les scores vivent dans une table clée ainsi :

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

Les lectures récupèrent le top N par score ; les écritures incrémentent le currentScore d'un joueur après chaque partie. Chaque ligne du classement mondial partage une seule clé de partition — BOARD#global — donc chaque lecture et chaque écriture atterrit sur une seule partition.

Ajoute un streamer avec deux millions de spectateurs en direct qui spamment le bouton d'actualisation sur leur propre rang, et cette unique partition franchit les 3 000 unités de lecture. Tu obtiens une ProvisionedThroughputExceededException sur le classement mondial pendant que tous les autres classements de la table sont inactifs.

Le footgun, c'est l'effondrement sur BOARD#global : tu as modélisé un seul classement logique comme une seule clé physique.

Répartir les écritures : sharder la clé

La solution consiste à fabriquer de la cardinalité. Ajoute un suffixe de shard à la clé de partition pour qu'un classement logique se déploie sur N partitions physiques :

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

Les écritures se dispersent désormais sur dix partitions au lieu d'une — dix fois la marge d'écriture. Le coût : une lecture de tout le classement doit atteindre les dix shards et les fusionner, car aucun Query unique ne franchit les frontières de shard. Tu échanges la simplicité de lecture contre la distribution des écritures.

AWS appelle ça le write sharding et le recommande précisément pour les clés à forte vélocité et faible cardinalité (AWS — utiliser le write sharding).

C'est le même instinct de key overloading que derrière le single-table design — tu façonnes la clé pour le mode d'accès, pas pour la façon dont les données « se posent naturellement ».

Laisse la capacité adaptative faire le plus facile

DynamoDB embarque la capacité adaptative, abordée dans la session re:Invent 2018 « Amazon DynamoDB Under the Hood » (DAT401). Elle redistribue continuellement le débit d'une table vers les partitions qui prennent la chaleur, et elle isolera une clé durablement chaude sur sa propre partition (isolation au niveau de la clé, AWS — bursting & capacité adaptative).

C'est instantané et gratuit — mais c'est borné par la physique. La capacité adaptative peut déplacer la chaleur entre les clés ; elle ne peut pas pousser une seule clé au-delà du plafond par partition. Une vraie clé célèbre throttle quand même. Le sharding, c'est ce qui te fait passer ce mur.

Voici le chemin de décision dès que tu vois des throttles sur une clé chargée :

La plupart des partitions chaudes se résolvent soit par « sharder la clé », soit par « laisser la capacité adaptative l'absorber » — le diagramme indique juste sur quelle branche tu te trouves.

Diagnostique avant de redessiner

Tu ne peux pas réparer ce que tu ne vois pas. Le throttling apparaît comme une ProvisionedThroughputExceededException (provisionné) ou comme des ThrottledRequests et le ThrottleCount par partition dans CloudWatch (AWS — métriques CloudWatch).

Associe ça à CloudWatch Contributor Insights pour DynamoDB, qui classe directement tes clés les plus sollicitées — le moyen le plus rapide de confirmer une clé célèbre par son nom (AWS — Contributor Insights).

Quand tu testes le chemin de lecture shardé, tu construiras à la main le KeyConditionExpression de chaque shard. Génère-les sans fautes de frappe avec le DynamoDB Expression Builder — il émet la forme exacte PK = :pk AND begins_with(SK, :sk) par shard.

Pièges à éviter

• Clés auto-incrémentées ou monotones. Des ids séquentiels et des timestamps comme clé de partition routent les écritures consécutives vers la même partition. Ajoute un préfixe de hash.
• Sharder le chemin de lecture-intensive sans raison. Si les lectures dominent et que l'item est petit, un cache ou un GSI avec une clé mieux répartie bat souvent le coût de lecture scatter-gather du sharding.
• Confondre une partition chaude avec un Scan lent. Un Scan est lent parce qu'il lit tout ; une partition chaude throttle parce qu'une clé est surchargée. Deux problèmes différents — voir Query vs Scan.

Étapes suivantes

Esquisse les clés shardées, puis prouve le chemin de lecture sur de vraies données. Construis les conditions par shard dans le DynamoDB Expression Builder, et télécharge DynoTable pour les exécuter sur tes propres tables et observer quelles partitions prennent vraiment la chaleur.