Tabellen, Elemente und Primärschlüssel

Amazon DynamoDB ist eine vollständig verwaltete, serverlose Schlüssel-Wert- und Dokumentdatenbank, die bei jeder Skalierung eine Leistung im einstelligen Millisekundenbereich bietet. Anders als relationale Datenbanken ist DynamoDB schemafrei – jedes Element kann über eine andere Menge von Attributen verfügen, solange der primäre Schlüssel vorhanden ist.

DynamoDB speichert Daten in Tabellen. Diese sind der Container der obersten Ebene und entsprechen in etwa einer SQL-Tabelle. Tabellen werden automatisch über mehrere Speicherknoten in verschiedenen AZs verteilt. Dadurch ist Redundanz integriert, ohne dass Sie etwas konfigurieren müssen.

Eine DynamoDB-Tabelle enthält eine Sammlung von Elementen, die jeweils eine Sammlung von Attributen umfassen. Attribute sind typisierte Werte: String (S), Number (N), Binary (B), Boolean (BOOL), Null (NULL), List (L), Map (M) und Set-Typen (SS, NS, BS).

Jedes Element einer Tabelle muss die Attribute des primären Schlüssels enthalten. Alle anderen Attribute sind optional und können sich zwischen Elementen unterscheiden. Ein einzelnes Element darf einschließlich aller Attributnamen und -werte höchstens 400 KB groß sein.

Ein einfacher primärer Schlüssel besteht aus einem einzelnen Attribut, dem Partitionsschlüssel (auch Hash-Schlüssel genannt). DynamoDB wendet eine interne Hash-Funktion auf den Wert des Partitionsschlüssels an, um zu bestimmen, welche Speicherpartition das Element enthält. Alle Elemente mit demselben Partitionsschlüsselwert werden zusammen gespeichert.

Bei einem einfachen primären Schlüssel dürfen zwei Elemente derselben Tabelle nicht denselben Partitionsschlüsselwert haben – er identifiziert jedes Element eindeutig. Dieses Design eignet sich für Tabellen, auf deren Daten Sie immer über eine eindeutige Kennung zugreifen, etwa eine Benutzer-ID oder Bestell-ID.

Ein zusammengesetzter primärer Schlüssel verwendet sowohl einen Partitionsschlüssel als auch einen Sortierschlüssel (auch Range Key genannt). Elemente mit demselben Partitionsschlüssel werden zusammen gespeichert und nach dem Wert des Sortierschlüssels sortiert. Dadurch sind Bereichsabfragen innerhalb einer Partition möglich.

Dieses Design ist äußerst flexibel: Mehrere Elemente können denselben Partitionsschlüssel verwenden, solange sich ihre Sortierschlüssel unterscheiden. Eine Tabelle Orders könnte beispielsweise CustomerId als Partitionsschlüssel und OrderDate als Sortierschlüssel verwenden. So können Sie alle Bestellungen eines Kunden nach Datum sortiert abfragen.

Die Wahl des richtigen Partitionsschlüssels ist die wichtigste Designentscheidung bei DynamoDB. Ein guter Partitionsschlüssel weist eine hohe Kardinalität (viele unterschiedliche Werte) auf und verteilt den Zugriff gleichmäßig auf die Partitionen. Eine schlechte Wahl führt zu Hot-Partitionen, auf die überproportional viel Datenverkehr entfällt und die dadurch eine Drosselung verursachen.

Zu vermeidende Anti-Patterns: ein boolesches Flag (nur zwei Werte), ein Datum, das alle Schreibvorgänge des heutigen Tages bündelt, oder ein Statusfeld mit geringer Kardinalität. Gute Optionen sind Benutzer-ID, Geräte-ID, eine zufällige UUID oder zusammengesetzte Werte wie tenantId#entityType.

Die drei grundlegenden DynamoDB-Operationen für Elemente sind:

• PutItem: schreibt ein neues Element oder ersetzt ein vorhandenes Element mit demselben primären Schlüssel vollständig
• GetItem: ruft ein einzelnes Element über seinen exakten primären Schlüssel ab (erfordert den vollständigen Schlüssel – den Partitionsschlüssel sowie bei einem zusammengesetzten Schlüssel den Sortierschlüssel)
• DeleteItem: entfernt ein Element über seinen exakten primären Schlüssel

Alle drei Operationen sind auf Elementebene atomar. Standardmäßig verwendet GetItem eventually konsistente Lesevorgänge. Durch Hinzufügen von --consistent-read erzwingen Sie einen stark konsistenten Lesevorgang, der immer den zuletzt geschriebenen Wert zurückgibt.

UpdateItem ändert bestimmte Attribute eines vorhandenen Elements, ohne es vollständig zu ersetzen – anders als PutItem. Sie können Attribute hinzufügen oder entfernen und arithmetische Operationen auf Number-Attributen atomar ausführen, etwa einen Zähler erhöhen.

Mit bedingten Ausdrücken können Sie festlegen, dass eine Operation nur erfolgreich sein darf, wenn eine Bedingung erfüllt ist. Sie können beispielsweise den Status eines Elements nur aktualisieren, wenn er derzeit PENDING lautet. Damit lassen sich Muster für optimistisches Sperren ohne Transaktionen umsetzen, was eine wichtige DynamoDB-Designtechnik ist.

Query ruft Elemente ab, die denselben Partitionsschlüsselwert haben, und kann optional nach Bedingungen für den Sortierschlüssel filtern. Query ist effizient, da nur die Zielpartition gelesen wird. Sie können Bedingungen für den Sortierschlüssel wie begins_with, between, =, < und > verwenden, um die Ergebnisse innerhalb der Partition einzugrenzen.

Scan liest jedes Element der Tabelle und wendet anschließend einen optionalen Filterausdruck an. Scans sind bei großen Tabellen kostspielig und sollten in Abfragemustern für Produktionsumgebungen vermieden werden. Wenn Sie häufig Scans benötigen, überdenken Sie Ihr Tabellendesign oder fügen Sie einen globalen sekundären Index hinzu.

DynamoDB speichert drei Kopien Ihrer Daten über mehrere AZs hinweg. Letztlich konsistente Lesevorgänge (die Standardeinstellung) können einen leicht veralteten Wert zurückgeben, wenn ein kürzlich erfolgter Schreibvorgang noch nicht an alle Kopien verteilt wurde – sie verbrauchen jedoch die Hälfte der Read Capacity Units stark konsistenter Lesevorgänge.

Stark konsistente Lesevorgänge geben immer den neuesten bestätigten Schreibvorgang zurück, kosten jedoch doppelt so viele RCUs und sind für Global Secondary Indexes nicht verfügbar. Verwenden Sie letztlich konsistente Lesevorgänge für leseintensive Workloads mit hohem Durchsatz und stark konsistente Lesevorgänge nur dann, wenn Ihre Anwendung zwingend die aktuellsten Daten benötigt.

DynamoDB unterstützt ACID-Transaktionen über TransactWriteItems und TransactGetItems. Eine Transaktion kann bis zu 100 Schreiboperationen über mehrere Elemente und sogar mehrere Tabellen hinweg gruppieren und stellt dabei sicher, dass entweder alle Operationen erfolgreich ausgeführt oder atomar zurückgerollt werden.

Verwenden Sie Transaktionen beispielsweise für die Überweisung von Geld zwischen Konten (ein Element belasten, ein anderes gutschreiben) oder für die Buchung eines Sitzplatzes (Verfügbarkeit prüfen und den Platz atomar reservieren). Transaktionen kosten doppelt so viele RCUs/WCUs wie normale Vorgänge. Verwenden Sie sie daher nur, wenn Atomarität über mehrere Elemente hinweg tatsächlich erforderlich ist.

Das Limit von 400 KB pro Element in DynamoDB beeinflusst die Datenmodellierung. Speichern Sie große Nutzdaten (z. B. Bilder oder umfangreiche Dokumente) in S3 und hinterlegen Sie in DynamoDB nur den S3-Objektschlüssel. Modellieren Sie tief verschachtelte hierarchische Daten, indem Sie jeden Knotentyp mit einem eigenen Partition-Key-Muster unter Verwendung des Single-Table-Designs abbilden – eine Tabelle enthält dabei mehrere Entitätstypen, die durch das Präfix des Partition Keys und das Muster des Sort Keys unterschieden werden.

Das Single-Table-Design minimiert die Anzahl der Tabellen und ermöglicht effiziente Zugriffsmuster, indem zusammengehörige Elemente in derselben Partition gespeichert werden. Es handelt sich um eine fortgeschrittene Technik, die den betrieblichen Aufwand reduziert und die Leistung bei komplexen Zugriffsmustern verbessert.

Testen Sie Ihr Verständnis der AWS-Solutions-Architect-Konzepte (SAA-C03) aus dieser Lektion.

In dieser Lektion haben Sie gelernt: DynamoDB-Tabellen enthalten schemafreie Elemente mit einer Größe von maximal 400 KB, einfache Primärschlüssel verwenden ausschließlich einen Partition Key, während zusammengesetzte Schlüssel für Bereichsabfragen einen Sort Key ergänzen, und Partition Keys mit hoher Kardinalität verhindern Hot Partitions. Verwenden Sie für effiziente Zugriffe Query statt Scan. Als Nächstes beschäftigen wir uns mit den Kapazitätsmodi Provisioned und On-Demand.