DynamoDB-Datentypen

Jedes DynamoDB-Attribut wird im Wire-Format mit einem ein- oder zweibuchstabigen Typcode markiert. Die Menge zu kennen ist wichtig, weil der Typ sowohl steuert, wie ein Wert gespeichert wird, als auch, wie er zur Größe eines Items zählt.

Auf einen Blick

Code	Typ	Kategorie	JSON-/JS-Entsprechung	Beispiel (DynamoDB-JSON)
`S`	String	Skalar	string	`{"S": "Ada"}`
`N`	Number	Skalar	number	`{"N": "37"}`
`B`	Binary	Skalar	Uint8Array / base64	`{"B": "ZGF0YQ=="}`
`BOOL`	Boolean	Skalar	boolean	`{"BOOL": true}`
`NULL`	Null	Skalar	null	`{"NULL": true}`
`M`	Map	Dokument	object	`{"M": {"k": {"S": "v"}}}`
`L`	List	Dokument	array	`{"L": [{"N": "1"}]}`
`SS`	String set	Menge	— (kein JSON-Typ)	`{"SS": ["a", "b"]}`
`NS`	Number set	Menge	—	`{"NS": ["1", "2"]}`
`BS`	Binary set	Menge	—	`{"BS": ["ZA=="]}`

Skalare

S — String (UTF-8; dimensioniert nach seiner Byte-Länge, nicht der Zeichenanzahl).
N — Number, aus Präzisionsgründen als String übertragen; bis zu 38 Stellen.
B — Binary, base64-kodiert übertragen.
BOOL — true / false.
NULL — ein expliziter Null-Marker.

Dokumente

M — Map (Objekt). Verschachtelte Attribute behalten jeweils ihren eigenen Typ-Tag.
L — List. Elemente dürfen gemischte Typen sein.

{"profile": {"M": {"name": {"S": "Ada"}, "age": {"N": "37"}}}}

Mengen

SS — String-Menge, NS — Number-Menge, BS — Binary-Menge.

Mengen sind ungeordnet, homogen und dürfen nicht leer sein. Entscheidend: reines JSON hat keinen Mengen-Typ — ein Array kommt als List (L) zurück, niemals als SS/NS. Das ist eine echte Konvertierungsgrenze, kein Bug; siehe den Hinweis im DynamoDB-JSON-Konverter.

Welche Typen können ein Schlüssel sein?

Partition Key und Sort Key — auf der Tabelle und auf jedem Index — müssen ein Skalar sein, und zwar nur S, N oder B. Du kannst nicht auf einem Boolean, einer Menge, Map oder List keyen. Modelliere einen „zusammengesetzten“ Schlüssel, indem du Werte zu einem S verkettest (z. B. ORDER#2026#42).

Limits, die du kennen solltest

Ein Item ist auf 400 KB begrenzt — jeder Attributname plus Wert, inklusive verschachtelter.
Numbers tragen bis zu 38 Stellen Präzision (positiv oder negativ).
Maps und Lists verschachteln bis zu 32 Ebenen tief.
Mengen sind nicht leer und homogen — keine leere Menge, kein Mischen von S und N.

Warum der Typ die Kosten beeinflusst

Die Item-Größe ist die Summe der Attributnamen-Bytes plus Wert-Bytes, und jeder Typ wird unterschiedlich dimensioniert — Numbers werden komprimiert, Booleans und Nulls sind 1 Byte, Maps und Lists fügen Overhead pro Element hinzu. Diese Größe wird auf Lese-/Schreib-Kapazitätseinheiten aufgerundet. Miss ein echtes Item mit dem Item-Größen-Rechner.

Probiere DynoTable, um den Typ jedes Attributs und die Live-Byte-Anzahl beim Bearbeiten eines Items zu sehen — und um über typisierte Attribute hinweg in der SQL Workbench zu filtern oder zu aggregieren, die jeden Typ-Tag für dich liest.