Types de données DynamoDB
Chaque attribut DynamoDB est tagué avec un code de type d'une ou deux lettres dans le format de transport. Connaître l'ensemble compte, car le type détermine à la fois la façon dont une valeur est stockée et la façon dont elle compte dans la taille d'un item.
En un coup d'œil
| Code | Type | Catégorie | Équivalent JSON / JS | Exemple (DynamoDB-JSON) |
|---|---|---|---|---|
S | String | Scalaire | string | {"S": "Ada"} |
N | Number | Scalaire | number | {"N": "37"} |
B | Binary | Scalaire | Uint8Array / base64 | {"B": "ZGF0YQ=="} |
BOOL | Boolean | Scalaire | boolean | {"BOOL": true} |
NULL | Null | Scalaire | null | {"NULL": true} |
M | Map | Document | object | {"M": {"k": {"S": "v"}}} |
L | List | Document | array | {"L": [{"N": "1"}]} |
SS | String set | Set | — (pas de type JSON) | {"SS": ["a", "b"]} |
NS | Number set | Set | — | {"NS": ["1", "2"]} |
BS | Binary set | Set | — | {"BS": ["ZA=="]} |
Scalaires
S— string (UTF-8 ; dimensionnée par sa longueur en octets, pas en nombre de caractères).N— number, envoyé sous forme de string pour la précision ; jusqu'à 38 chiffres.B— binary, envoyé encodé en base64.BOOL—true/false.NULL— un marqueur null explicite.
Documents
M— map (object). Les attributs imbriqués conservent chacun leur propre tag de type.L— list. Les éléments peuvent être de types mixtes.
{"profile": {"M": {"name": {"S": "Ada"}, "age": {"N": "37"}}}}Sets
SS— string set,NS— number set,BS— binary set.
Les sets sont non ordonnés, homogènes et ne peuvent pas être vides. Surtout, le
JSON brut n'a pas de type set — un tableau fait un aller-retour en list (L),
jamais en SS/NS. C'est une vraie limitation de conversion, pas un bug ; voir la
note du convertisseur DynamoDB-JSON.
Quels types peuvent être une clé ?
Les clés de partition et de tri — sur la table comme sur n'importe quel index —
doivent être un scalaire, et uniquement S, N ou B. Tu ne peux pas clé
sur un boolean, un set, une map ou une list. Modélise une clé « composite » en
concaténant des valeurs dans un seul S (par ex. ORDER#2026#42).
Limites à connaître
- Un item plafonne à 400 KB — chaque nom d'attribut plus sa valeur, y compris les imbriquées.
- Les nombres portent jusqu'à 38 chiffres de précision (positifs ou négatifs).
- Les maps et les lists s'imbriquent jusqu'à 32 niveaux de profondeur.
- Les sets sont non vides et homogènes — pas de set vide, pas de mélange
SetN.
Pourquoi le type affecte le coût
La taille d'un item est la somme des octets des noms d'attributs plus les octets des valeurs, et chaque type se dimensionne différemment — les nombres sont compactés, les booleans et les nulls font 1 octet, les maps et les lists ajoutent une surcharge par élément. Cette taille est arrondie aux unités de capacité de lecture/écriture. Mesure un item réel avec le calculateur de taille d'item.
Essaie DynoTable pour voir le type de chaque attribut et le décompte d'octets en direct pendant que tu édites un item — et pour filtrer ou agréger sur des attributs typés dans le Workbench SQL, qui lit chaque tag de type pour toi.