DynamoDB est-il un magasin clé-valeur ?

Oui — DynamoDB est un magasin clé-valeur, et aussi un magasin de documents. Chaque élément est récupéré par sa clé primaire (une clé de partition, éventuellement accompagnée d'une clé de tri), ce qui donne des recherches par clé rapides. Il prend en plus en charge les types document — listes et maps imbriquées — et fonctionne donc à la fois comme base de données clé-valeur et comme base de données document.

Le modèle clé-valeur

Chaque élément a une clé primaire qui l'identifie de façon unique. Un GetItem sur cette clé est une recherche directe de quelques millisecondes — aucun scan. C'est le modèle d'accès clé-valeur classique.

Le côté document

Au-delà de la clé, les valeurs peuvent être des documents riches : maps (objets) et listes (tableaux), imbriqués jusqu'à 32 niveaux, dans la limite des 400 Ko par élément. Cela fait de DynamoDB un magasin clé-valeur dont les valeurs sont des documents de type JSON.

Là où la moitié document s'arrête

Le plafond de 32 niveaux est bien réel (un 33e niveau est rejeté sans appel, avec l'erreur exacte ici), mais ce n'est que rarement la profondeur qui mord. C'est l'adressage.

Tu lis par clé, pas par champ. Une ProjectionExpression restreint ce qui traverse le réseau, pas ce que DynamoDB lit. Sur un élément d'environ 30 Ko contenant une longue bio et une liste tags de 100 éléments, un GetItem fortement cohérent facture la même chose de trois façons :

Requête	Renvoyé	`ConsumedCapacity`
`GetItem`, élément entier	tout	8
`ProjectionExpression: 'status'`	une valeur de 6 octets	8
`ProjectionExpression: 'profile.tags[0]'`	un élément de liste	8

C'est le marché que tu acceptes en stockant des documents dans un magasin clé-valeur : l'unité d'accès, et de facturation, c'est l'élément entier. Si un attribut est lu en permanence et que ses voisins sont volumineux, ils appartiennent à des éléments différents.

Pourquoi la clé compte tant

Parce que les lectures se font par clé, une recherche efficace commence par fixer une seule valeur de clé de partition. Concevoir de bonnes clés est le cœur de la modélisation DynamoDB.

Dimensionne la valeur, pas seulement la clé

La vitesse du clé-valeur suppose que la valeur convient au modèle d'accès. Un élément de 400 Ko coûte la même chose à lire, que tu projettes un seul champ ou le document entier — le tableau de la section précédente affichait déjà 8 unités de capacité pour un élément d'environ 30 Ko. Range les gros blobs dans S3 et garde un pointeur dans DynamoDB quand seule une partie du document est chaude.

Le calculateur de taille d'élément totalise noms et valeurs d'attributs comme DynamoDB les facture.

Dans DynoTable : les clés de partition composites du type USER#123 sont décodées dans la grille, si bien que le préfixe d'entité se lit d'un coup d'œil, et Row Quick View (Space) ouvre le document complet sans te faire perdre ta place. Vois Interroger les tables.

Aller plus loin

Comprends les clés dans clé primaire composite DynamoDB et comment fonctionnent les clés de partition DynamoDB. Télécharge DynoTable pour interroger par clé.

Références

Dernière vérification le 2026-07-13 par rapport à la documentation officielle AWS liée ci-dessus.

Les chiffres de capacité ont été mesurés le 2026-07-28 sur DynamoDB Local 3.3.0 (amazon/dynamodb-local:latest) via @aws-sdk/client-dynamodb 3.1095.0, et non estimés.