Ist DynamoDB ein Key-Value-Store?
Ja — DynamoDB ist ein Key-Value-Store und zugleich ein Dokumentspeicher. Jedes Item wird über seinen Primärschlüssel abgerufen (einen Partitionsschlüssel, optional mit einem Sortierschlüssel), was schnelle schlüsselbasierte Lookups ergibt. Zusätzlich unterstützt es Dokumenttypen — verschachtelte Listen und Maps — und funktioniert damit sowohl als Key-Value- als auch als Dokumentdatenbank.
Das Key-Value-Modell
Jedes Item hat einen Primärschlüssel, der es eindeutig identifiziert. Ein GetItem auf diesen Schlüssel ist ein direkter Lookup im einstelligen Millisekundenbereich — ohne Scan. Das ist das klassische Key-Value-Zugriffsmuster.
Die Dokumentseite
Jenseits des Schlüssels dürfen Werte reichhaltige Dokumente sein: Maps (Objekte) und Listen (Arrays), bis zu 32 Ebenen tief verschachtelt, innerhalb des 400-KB-Limits pro Item. Damit ist DynamoDB ein Key-Value-Store mit JSON-artigen Dokumentwerten.
Wo die Dokumenthälfte endet
Die 32-Ebenen-Obergrenze ist real (eine 33. Ebene wird rundweg abgelehnt, hier mit dem exakten Fehler), aber selten ist die Tiefe das, was dich einholt. Die Adressierung ist es.
Du liest nach Schlüssel, nicht nach Feld. Eine ProjectionExpression grenzt ein, was über die Leitung geht, nicht, was DynamoDB liest. Bei einem ~30 KB großen Item mit einer langen bio und einer 100-elementigen tags-Liste rechnet ein stark konsistentes GetItem in allen drei Fällen gleich ab:
| Request | Zurückgeliefert | ConsumedCapacity |
|---|---|---|
GetItem, ganzes Item | alles | 8 |
ProjectionExpression: 'status' | ein 6-Byte-Wert | 8 |
ProjectionExpression: 'profile.tags[0]' | ein Listenelement | 8 |
Das ist der Handel, auf den du dich einlässt, wenn du Dokumente in einem Key-Value-Store ablegst: Die Einheit des Zugriffs — und der Abrechnung — ist das ganze Item. Wird ein Attribut ständig gelesen und sind seine Nachbarn groß, gehören sie in verschiedene Items.
Warum der Schlüssel so viel ausmacht
Weil Lesevorgänge über Schlüssel laufen, beginnt ein effizienter Lookup damit, genau einen Partitionsschlüssel-Wert festzunageln. Gute Schlüssel zu entwerfen ist der Kern der Datenmodellierung in DynamoDB.
Dimensioniere den Wert, nicht nur den Schlüssel
Key-Value-Tempo setzt voraus, dass der Wert zum Zugriffsmuster passt. Ein 400 KB großes Item kostet im Lesen gleich viel, ob du ein Feld projizierst oder das ganze Dokument — die Tabelle im Abschnitt oben zeigte bereits 8 Kapazitätseinheiten für ein ~30 KB großes Item. Lege große Blobs in S3 ab und halte in DynamoDB nur einen Zeiger, wenn nur ein Teil des Dokuments heiß ist.
Der Item-Size-Rechner summiert Attributnamen und -werte so auf, wie DynamoDB sie abrechnet.
In DynoTable: Zusammengesetzte Partitionsschlüssel wie USER#123 werden im Grid dekodiert, sodass du das Entitätspräfix auf einen Blick liest, und die Row Quick View (Space) öffnet das vollständige Dokument, ohne dass du deine Stelle verlierst. Siehe Tabellen abfragen.
Tiefer einsteigen
Verstehe Schlüssel in Zusammengesetzter Primärschlüssel in DynamoDB und wie DynamoDB-Partitionsschlüssel funktionieren. Lade DynoTable herunter, um per Schlüssel abzufragen.
Referenzen
- Fast NoSQL Key-Value Database — Amazon DynamoDB — AWS
- Core components of Amazon DynamoDB — Amazon DynamoDB Developer Guide
- What is Amazon DynamoDB? — Amazon DynamoDB Developer Guide
Zuletzt überprüft am 13.07.2026 anhand der oben verlinkten offiziellen AWS-Dokumentation.
Die Kapazitätszahlen wurden am 28.07.2026 gegen DynamoDB Local 3.3.0 (amazon/dynamodb-local:latest) über @aws-sdk/client-dynamodb 3.1095.0 gemessen, nicht geschätzt.