Partitions chaudes DynamoDB : les repérer et les corriger

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

Qu'est-ce qu'une partition surchargée dans DynamoDB ?

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

• La cause est la conception des clés, pas la taille de la table. Une seule clé de partition qui concentre le trafic — un utilisateur vedette, un drapeau status="OPEN", la date du jour — voilà le piège.
• La capacité adaptative aide, mais ce n'est pas un correctif. DynamoDB rééquilibre la chaleur automatiquement, mais un seul item ou une seule clé peut quand même dépasser ce qu'une partition peut servir.
• Le remède est de répartir les écritures. Ajoute de l'entropie à la clé (write sharding) ou déplace le chemin de lecture chaud vers un pattern d'accès mieux réparti.
• Quand tu viens du 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, si.

Pourquoi les partitions existent

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

Chaque partition contient une quantité bornée de données et sert une quantité bornée de débit. AWS documente un plafond dur de 3 000 unités de lecture et 1 000 unités d'écriture par partition, par seconde (AWS — comportement des partitions). Le mode de facturation ne relève pas le plafond physique ; il change seulement la façon dont la dépense est comptée au niveau de la table. Sers-toi du calculateur de tarifs pour le coût au niveau table, et de Contributor Insights pour voir si les throttles sont limités par partition ou par table.

Ce plafond est toute l'histoire. Le débit provisionné de ta table est la somme sur toutes les partitions. La collection d'items d'une clé démarre sur une partition, et la division pour cause de chaleur peut la découper sur plusieurs aux frontières de clé de tri — sauf si la table a un LSI ou que la clé de tri est toujours croissante, ce qui l'épingle sur une seule.

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

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

Les formes classiques de clé surchargée :

• Un item vedette — un utilisateur, produit ou tenant que tout le monde lit.
• Une clé de partition à faible cardinalité — status, country, type. Peu de valeurs distinctes signifie peu de partitions faisant tout le travail.
• Une clé regroupée par temps — PK = "2026-06-23". Chaque écriture d'aujourd'hui martèle une partition ; celle d'hier est froide pour toujours.

Quand tu viens du SQL, rien de tout ça n'importerait. 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 vedette

Disons que tu gères un classement de jeu mondial. Les scores vivent dans une table avec des clés comme ceci :

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

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

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

Le piège, 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é

Le correctif est de fabriquer de la cardinalité. Ajoute un suffixe de shard à la clé de partition pour qu'un seul classement logique se déploie sur N partitions physiques :

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

Les écritures se dispersent maintenant sur dix partitions au lieu d'une — dix fois plus de marge en écriture. Le coût : une lecture du classement entier doit frapper 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.

Vois la différence par toi-même. Colle une seule clé répétée dans le visualiseur ci-dessous et chaque écriture atterrit dans un seul seau — la partition surchargée. Ajoute un suffixe de shard (BOARD#global#0 … #9) et les mêmes écritures se déploient uniformément :

C'est un hachage pédagogique pour l'intuition, pas le vrai hachage interne de DynamoDB — la vraie fonction et les frontières de partition sont des mécanismes internes d'AWS. Lis-le comme « répartition équilibrée vs déséquilibre », pas comme une prédiction de la partition physique où une clé atterrit.

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

C'est le même instinct de surcharge de clés derrière le single-table design — tu façonnes la clé pour le pattern d'accès, pas pour la manière dont les données « reposent naturellement ».

Laisse la capacité adaptative faire le facile

DynamoDB embarque la capacité adaptative, présentée lors de 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 va isoler une clé durablement surchargée sur sa propre partition (isolation au niveau de la clé, AWS — bursting & adaptive capacity).

C'est instantané et gratuit — mais borné par la physique (comment fonctionne la capacité adaptative). La capacité adaptative peut déplacer la chaleur entre clés, et la division pour cause de chaleur peut même diviser une collection d'items surchargée à une frontière de clé de tri. Le plafond par partition reste absolu uniquement pour un seul item surchargé, une clé de tri toujours croissante, ou une table avec un LSI — où une clé vedette throttle toujours. Le sharding est le correctif déterministe ; la division pour cause de chaleur est lente et opportuniste, alors ne l'attends pas.

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

La plupart des partitions surchargées se résolvent soit en « sharder la clé » soit en « laisser la capacité adaptative l'absorber » — le diagramme dit juste sur quelle branche tu es.

Diagnostique-la avant de reconcevoir

Tu ne peux pas corriger ce que tu ne vois pas. Le throttling apparaît sous forme de ProvisionedThroughputExceededException (provisionné) ou de ThrottledRequests, ReadThrottleEvents/WriteThrottleEvents, et ReadThrottleEventsForKeyRange/WriteThrottleEventsForKeyRange — les décomptes spécifiques à la limite de partition — dans CloudWatch (AWS — métriques CloudWatch).

Associe ça à CloudWatch Contributor Insights for DynamoDB, qui classe directement tes clés les plus accédées — le moyen le plus rapide de confirmer une clé vedette par son nom (AWS — Contributor Insights pour DynamoDB). Et si tu n'es pas encore sûr qu'une clé surchargée soit bien la cause — DynamoDB throttle pour quatre raisons distinctes — pars du guide du throttling et laisse les métriques nommer la limite que tu as réellement atteinte.

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

Pièges à éviter

• Clés de tri toujours croissantes. Une clé de tri monotone (un timestamp, un numéro de séquence) force chaque nouvelle écriture vers la même extrémité d'une collection d'items, et la division pour cause de chaleur ne peut pas aider — la collection reste plafonnée à 1 000 unités d'écriture. Ajoute de l'entropie à la clé de tri ou shard la clé de partition.
• Sharder inutilement le chemin dominé par la lecture. 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 en scatter-gather du sharding.
• Confondre une partition surchargée avec un Scan lent. Un Scan est lent parce qu'il lit tout ; une partition surchargée throttle parce qu'une clé est surchargée. Problèmes différents — voir Query vs Scan.

Étapes suivantes

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