DynamoDB Einordnung

Managed Service von AWS
Key-Value- und Dokumentendatenbank
Serverless: keine Serververwaltung notwendig
Automatische Skalierung und hohe Verfügbarkeit
Multi-Region-Replikation möglich (Global Tables)
SLA: 99,999 % Verfügbarkeit

Tabellen, Items, Attribute

Grundstruktur

Tabelle: Sammlung von Items (kein festes Schema)
Item: einzelner Datensatz, schemalos
Attribut: typisiertes Feld (String, Number, Binary, List, Map, …)
JSON-ähnliche Struktur
Maximale Item-Größe: 400 KB

Primärschlüssel: Partition Key

Einfacher Primärschlüssel aus einem einzigen Attribut
DynamoDB berechnet einen Hash-Wert → bestimmt physische Partition
Jedes Item muss einen eindeutigen Partition Key besitzen

{
  "UserId": "U-1001",   <-- PK
  "Name": "Alice",
  "Email": "alice@example.com"
}

Primärschlüssel: Composite Key

Partition Key + Sort Key
Mehrere Items mit gleichem Partition Key möglich
Sort Key ermöglicht Bereichsabfragen (begins_with, between, <, >, …)

{
  "UserId":  "U-1001",    <-- PK
  "OrderId": "O-2024-01", <-- SK
  "Total":   149.99
}

Local Secondary Index (LSI)

Gleicher Partition Key wie Basistabelle, aber anderer Sort Key
Alternative Sortierung und Filterung innerhalb einer Partition
Muss beim Erstellen der Tabelle definiert werden
Maximal 5 LSIs pro Tabelle
Starke Konsistenz möglich
Teilt Kapazität mit der Basistabelle

Global Secondary Index (GSI)

Eigener Partition Key und optionaler Sort Key
Abfragen nach beliebigen Attributen möglich
Kann jederzeit erstellt oder gelöscht werden
Eigene Lese- und Schreibkapazität
Nur Eventually Consistent Reads
Maximal 20 GSIs pro Tabelle (Standard-Limit)

Kapazitätsmodi

Provisioned

Feste Anzahl Read Capacity Units (RCU) und Write Capacity Units (WCU)
1 RCU = 1 strongly consistent Read (4 KB) oder 2 eventually consistent Reads
1 WCU = 1 Write bis 1 KB
Auto-Scaling möglich
Günstiger bei vorhersehbarer Last

On-Demand

Keine Kapazitätsplanung notwendig
Bezahlung pro Request (Pay-per-request)
Automatische Skalierung auf jede Last
Geeignet für unbekannte oder stark schwankende Last
Höhere Kosten pro Request als Provisioned

Lese- und Schreiboperationen

GetItem: einzelnes Item über Primary Key abrufen
PutItem: Item einfügen oder vollständig ersetzen
UpdateItem: einzelne Attribute eines Items ändern
DeleteItem: einzelnes Item löschen
Query: effiziente Abfrage über Partition Key (+ optionaler Sort Key Bedingung)
Scan: vollständiger Tabellen-Scan, alle Items werden gelesen (ineffizient)
BatchGetItem / BatchWriteItem: mehrere Items auf einmal lesen / schreiben

Konsistenz

Eventually Consistent Read (Standard): geringere Kosten (0,5× RCU), Daten ggf. kurz veraltet
Strongly Consistent Read: aktuellste Daten, 1× RCU, höhere Latenz
GSI-Lesezugriffe sind immer eventually consistent
Transaktionen möglich für ACID-Anforderungen

Transaktionen

TransactWriteItems: atomares Schreiben über mehrere Items / Tabellen
TransactGetItems: konsistentes Lesen mehrerer Items in einer Operation
ACID-Garantien: Atomarität, Konsistenz, Isolation, Dauerhaftigkeit
Bis zu 100 Items oder 4 MB pro Transaktion
Kosten: 2× WCU bzw. 2× RCU im Vergleich zu nicht-transaktionalen Operationen
Kein Cross-Region-Support (nur innerhalb einer Region)

DynamoDB Streams

Change Data Capture (CDC): Protokoll aller Änderungen
Ereignisse: INSERT, MODIFY, REMOVE
Aufbewahrungsdauer: 24 Stunden
Integration mit AWS Lambda
TTL (Time to Live): automatisches Löschen abgelaufener Items
Grundlage für Global Tables

Global Tables

Multi-Region-Replikation: Tabelle in mehreren AWS-Regionen aktiv
Active-Active: Lese- und Schreibzugriffe in jeder Region
Eventual Consistency zwischen Regionen (< 1 Sekunde)
Konfliktauflösung: Last-Write-Wins
Basiert auf DynamoDB Streams
Niedrige Latenz für globale Nutzer

Preismodell

Provisioned

Preis pro RCU und WCU pro Stunde
Reservierte Kapazität möglich (Rabatt)
Auto-Scaling verursacht Anpassungskosten

On-Demand

Preis pro Request Read Unit (RRU) und Write Request Unit (WRU)
Keine Mindestgebühren
Ca. 6–7× höherer Preis pro Request vs. Provisioned

Weitere Kostenfaktoren

Speicher: pro GB-Monat
Streams: pro Leseanfrage
Global Tables: zusätzliche Replikationsschreibeinheiten

Modellierungsprinzipien

Zugriffsmuster zuerst: Datenmodell an den Abfragen ausrichten, nicht an der Domäne
Single-Table Design: alle Entitäten in einer Tabelle, um Joins zu vermeiden
Daten denormalisieren: Duplikation akzeptieren für bessere Leseleistung
Key Overloading: generische PK/SK-Namen (z.B. PK, SK) für mehrere Entitätstypen
Abfragen möglichst über Query (nicht Scan) realisieren
GSIs für sekundäre Zugriffsmuster einsetzen

Beispiel: Online Shop

Key-Struktur (Single Table)

PK             SK
USER#123       PROFILE
USER#123       ORDER#456
USER#123       ORDER#789
ORDER#456      ITEM#001
ORDER#456      ITEM#002
PRODUCT#P01    METADATA

Beispiel: Social Network

Key-Struktur (Single Table)

PK             SK
USER#Alice     PROFILE
USER#Alice     FRIEND#Bob
USER#Alice     FRIEND#Carol
USER#Alice     POST#2024-01-15
USER#Bob       PROFILE
USER#Bob       FRIEND#Alice