Comment fonctionnent les clés de partition DynamoDB

Ta clé de partition n'est pas une colonne — c'est une adresse. DynamoDB hache cette clé et le hash décide quelle machine physique stocke l'item. Choisis bien la clé et la charge se répartit ; choisis-la mal et un seul serveur encaisse tout.

Comment fonctionnent les clés de partition DynamoDB ?

DynamoDB passe ta clé de partition dans une fonction de hash interne, et ce hash décide quelle partition physique stocke l'item. La clé n'est pas triée ni indexée comme une colonne SQL — c'est une adresse. Choisis une clé à forte cardinalité et la charge se répartit sur de nombreuses partitions ; choisis une clé à faible cardinalité et une seule partition encaisse tout.

• La clé est hachée, pas triée. DynamoDB passe ta clé de partition dans un hash interne pour choisir une partition. Deux valeurs adjacentes atterrissent loin l'une de l'autre sur le disque.
• Une partition est une vraie unité de stockage. Chacune plafonne autour de 10 Go, 3 000 unités de lecture/s et 1 000 unités d'écriture/s. Ton trafic est divisé par le nombre de partitions sur lesquelles tes clés se répartissent.
• Les clés chaudes sont le piège. Canalise la plupart des requêtes vers une seule valeur de clé de partition et tu throttles sur cette partition pendant que le reste de la table reste inactif.
• Les clés à forte cardinalité gagnent. Plus tu as de valeurs de clé distinctes et uniformément sollicitées, plus de partitions absorbent la charge.

Commence par ce que la clé fait réellement

En venant de SQL, une clé primaire est une colonne triée et indexée sur laquelle tu fais des JOIN et des ORDER BY. Dans DynamoDB, la clé de partition (parfois appelée hash key) fait quelque chose de différent : elle décide du placement.

DynamoDB injecte la clé de partition dans une fonction de hash interne. La sortie se mappe à un espace de clés, et l'espace de clés est découpé en plages — chaque plage appartenant à une partition physique. Cette partition est du vrai stockage sur un vrai nœud.

Donc la clé de partition répond à une question : quelle machine détient cet item ? La clé de tri, si tu en as une, ne fait qu'ordonner les items au sein de cette machine. Elle ne joue aucun rôle dans le placement.

Suis une écriture à travers le hash

Disons que tu exploites un SaaS qui ingère des mesures d'appareils. Ta table SensorReadings utilise une clé de partition deviceId et une clé de tri readingTs. Tu écris une mesure pour deviceId = "vac-7741".

Voici le chemin que prend cette écriture — de ta clé jusqu'au disque où elle atterrit :

L'écriture pour vac-7741 est hachée vers un point de l'espace de clés, ce point tombe dans la plage de P2, et l'item atterrit sur P2 — ordonné là par readingTs.

La chose à intérioriser : "vac-7741" et "vac-7742" ne diffèrent que d'un caractère, mais leurs hashs n'ont aucun rapport. Ils vivent presque certainement sur des partitions différentes. Il n'y a pas de « voisinage » dans l'espace de clés de partition.

C'est l'idée du hachage cohérent que DynamoDB a héritée du design d'origine — le papier Amazon Dynamo de 2007 (« Dynamo: Amazon's Highly Available Key-value Store ») répartissait les clés sur les nœuds en les hachant exactement pour qu'aucun nœud unique ne devienne un goulot d'étranglement.

Respecte les limites strictes de la partition

Une partition physique est finie. Selon le AWS DynamoDB Developer Guide, chacune détient jusqu'à environ :

Quand une partition se remplit au-delà de 10 Go, ou que ton débit provisionné a besoin de plus de place, DynamoDB la scinde — la plage d'espace de clés est divisée et les items se redistribuent sur plus de partitions. C'est automatique ; tu ne le déclenches pas.

Le hic : une scission répartit les items par leur hash. Si chaque requête chaude cible une seule valeur de clé de partition, scinder n'aide pas — tout ce trafic se hache toujours vers le même point. Tu ne peux pas répartir la charge d'une seule clé sur plusieurs partitions.

Nomme le piège : la partition chaude

Une partition chaude est le piège classique. Cela arrive quand une valeur de clé de partition (ou un tout petit ensemble) absorbe une part disproportionnée du trafic.

Échec concret : tu passes SensorReadings à une clé de partition region avec des valeurs comme "us-east", "eu-west". Trois régions, ça veut dire trois valeurs de clé, ça veut dire — au plus — trois partitions qui font du vrai travail. Martèle "us-east" de lectures et elle throttle à 3 000 RCU pendant que la capacité totale provisionnée de la table reste inutilisée.

L'adaptive capacity de DynamoDB adoucit ça — elle peut déplacer du débit inutilisé vers une partition chargée, et isoler une seule clé très chaude sur sa propre partition. AWS a détaillé ça dans les sessions de plongée re:Invent « Advanced Design Patterns for DynamoDB ». Mais l'adaptive capacity achète du temps, pas l'immunité : elle ne peut pas subdiviser la charge d'une seule clé individuelle. Conçois pour la répartition ; ne t'appuie pas sur le filet de sécurité.

Choisis une clé à forte cardinalité

La solution est la cardinalité — le nombre de valeurs de clé distinctes, et la façon dont le trafic les frappe uniformément.

• Faible cardinalité (region, status, true/false) : peu de partitions, le trafic se concentre, tu throttles tôt.
• Forte cardinalité (deviceId, userId, un ID de commande) : beaucoup de valeurs se hachant sur beaucoup de partitions, la charge se répartit, la marge grandit.

En venant de SQL, tu indexerais volontiers une colonne status et tu filtrerais dessus. En tant que clé de partition DynamoDB, c'est un piège — elle ne peut pas se répartir. Garde les attributs à faible cardinalité comme filtres ou comme clé de tri d'un index secondaire, jamais comme la chose qui décide du placement.

Quand une clé naturellement bonne penche quand même — une poignée de locataires baleines distançant le reste — ajoute un suffixe pour éventer une valeur logique sur N partitions, par ex. tenantId#3 pour un chemin d'écriture shardé. Tu ré-agrèges à la lecture.

Pour cibler des items au sein d'une partition une fois ta clé répartie, tu écriras une KeyConditionExpression sur la clé de tri. Tu peux en assembler une contre ton propre schéma dans le constructeur d'expressions DynamoDB avant de la câbler dans le code :

deviceId = "vac-7741" AND readingTs BETWEEN "2026-06-01" AND "2026-06-30"

Ça lit la fenêtre de juin d'un seul appareil depuis une seule partition — un Query, pas un Scan. La clé de partition épingle la machine ; la condition sur la clé de tri restreint les lignes.

Pièges et étapes suivantes

• Ne choisis pas une clé selon ce qui se lit bien en SQL. Choisis-la selon ce qui se répartit. Cardinalité d'abord, commodité de requête ensuite.
• Ne suppose pas que la capacité totale de la table est tienne par clé. Le débit est par partition ; une seule valeur chaude peut throttler pendant que la table semble inactive.
• Ne lutte pas contre une scission. Elle est automatique et pilotée par le hash — ton boulot est de lui donner assez de clés distinctes pour se répartir.

Une fois ta clé proprement répartie, les décisions suivantes portent sur comment disposer les items au sein d'une partition — vois le single-table design — et sur quand un index secondaire est le bon outil pour un second access pattern.

Télécharge DynoTable pour parcourir tes vraies partitions et la distribution de tes clés, et repérer une clé chaude avant qu'elle ne te réveille.