Fonctionnement des clés de partition DynamoDB

Ta clé de partition n'est pas une colonne — c'est une adresse. DynamoDB hache cette clé et le hachage 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 fait passer ta clé de partition par une fonction de hachage interne, et ce hachage décide quelle partition physique stocke l'item. La clé n'est ni 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-en une à faible cardinalité et une seule partition encaisse tout.

• La clé est hachée, pas triée. DynamoDB fait passer ta clé de partition par un hachage interne pour choisir une partition. Deux valeurs adjacentes atterrissent à des endroits totalement distincts sur le disque.
• Une partition est une véritable 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. Concentre la plupart des requêtes sur une seule valeur de clé de partition et tu seras limité 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 sollicitées de façon homogène, plus de partitions absorbent la charge.

Commence par ce que la clé fait réellement

Quand tu viens 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 clé de hachage) fait quelque chose de différent : elle décide du placement.

DynamoDB alimente une fonction de hachage interne avec la clé de partition. La sortie s'associe à un espace de clés, et l'espace de clés est découpé en plages — chaque plage détenue par une partition physique. Cette partition est un vrai stockage sur un vrai nœud.

Ainsi la clé de partition répond à une seule 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 hachage

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

Voici le chemin que prend cette écriture — de ta clé 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.

Ce qu'il faut intérioriser : "vac-7741" et "vac-7742" sont à un caractère d'écart, mais leurs hachages n'ont aucun rapport. Ils vivent presque certainement sur des partitions différentes. Il n'y a pas de « voisin » dans l'espace de clés de partition.

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

Colle une liste de valeurs de clé de partition ci-dessous pour voir comment un hachage les disperse entre des seaux. Un ensemble à forte cardinalité se répartit de façon homogène ; réutilise une valeur et tout s'entasse dans un seul seau — la partition chaude dont parle la section suivante.

Il s'agit d'un hachage pédagogique pour l'intuition, pas du vrai hachage interne de DynamoDB — la fonction réelle, l'espace de clés et les frontières de partition sont des mécanismes internes d'AWS. Utilise-le pour développer une sensation de répartition vs déséquilibre, pas pour prédire sur quelle partition physique une clé atterrit.

Respecte les limites strictes de la partition

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

Lorsqu'une partition dépasse 10 Go, ou que ton débit provisionné a besoin de plus de marge, DynamoDB la scinde — la plage de l'espace de clés est divisée et les items se redistribuent sur davantage de partitions. C'est automatique ; tu ne le déclenches pas.

Le hic : une scission peut découper la collection d'items d'une clé de partition à une frontière de clé de tri, si bien que la charge d'une clé sollicitée peut se répartir sur davantage de partitions. Ce qu'une scission ne peut pas sauver, c'est un unique item chaud, une clé de tri toujours croissante, ou une table avec un LSI — ceux-là fixent la collection à une seule partition.

Nomme le piège : la partition chaude

Une partition chaude est le piège classique. Elle survient quand une valeur de clé de partition (ou un tout petit ensemble d'entre elles) absorbe une part disproportionnée du trafic.

Échec concret : tu bascules SensorReadings sur une clé de partition region avec des valeurs comme "us-east", "eu-west". Trois régions signifient trois valeurs de clé signifient — au plus — trois partitions faisant un vrai travail. Bombarde "us-east" de lectures et elle est limitée à 3 000 RCU pendant que la capacité provisionnée totale de la table reste inutilisée.

La capacité adaptative de DynamoDB adoucit cela — elle peut déplacer le débit inutilisé vers une partition sollicitée, et isoler une unique clé très chaude sur sa propre partition. AWS l'a détaillé dans les sessions approfondies re:Invent « Advanced Design Patterns for DynamoDB ». Mais la capacité adaptative achète du temps, pas de l'immunité : un unique item chaud, une clé de tri toujours croissante, ou un LSI plafonnent toujours une clé à une seule partition. Conçois pour la répartition ; ne compte pas sur le filet de sécurité.

Choisis une clé à forte cardinalité

La solution, c'est la cardinalité — le nombre de valeurs de clé distinctes, et l'homogénéité avec laquelle le trafic les sollicite.

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

Quand tu viens 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 ce qui décide du placement.

Quand une clé naturellement bonne se déséquilibre malgré tout — une poignée de gros locataires distançant le reste — ajoute un suffixe pour éventer une valeur logique sur N partitions, par ex. tenantId#3 pour un chemin d'écriture partitionné. Tu ré-agrèges à la lecture.

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

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

Cela lit la fenêtre de juin d'un seul appareil depuis une seule partition — un Query, pas un Scan. La clé de partition fixe la machine ; la condition de 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. La cardinalité d'abord, la commodité de requête ensuite.
• Ne suppose pas que la capacité totale de la table est à toi par clé. Le débit est par partition ; une seule valeur chaude peut être limitée pendant que la table semble inactive.
• Ne combats pas une scission. Elle est automatique et guidée par le hachage — ton rôle est de lui donner assez de clés distinctes pour se répartir.

Une fois ta clé bien répartie, les décisions suivantes portent sur la façon de disposer les items au sein d'une partition — voir conception à table unique — et sur le moment où un index secondaire est le bon outil pour un second pattern d'accès.

Télécharge DynoTable et lance un GROUP BY sur ta clé de partition dans le SQL Workbench pour voir quelles clés entassent le plus d'items avant que l'une ne se transforme en partition chaude.