Single Table Design: Einordnung

Überblick

• Single Table Design (STD): alle Entitätstypen in einer einzigen DynamoDB-Tabelle
• DynamoDB bietet keinen JOIN-Support → STD als Lösungsstrategie
• Ziel: alle Zugriffsmuster mit einem einzigen Roundtrip abbilden
• PK und SK werden „überladen" (Key Overloading) – gleichnamige Spalten, verschiedene Semantik
• Entgegengesetzt zu relationalen Prinzipien: Denormalisierung statt Normalisierung
• Kernprinzip: Zugriffsmuster zuerst definieren, dann Datenmodell ableiten

Mehrere Entitätstypen in einer Tabelle

• PK und SK bekommen generische Namen: PK, SK
• Statt spezifischer Namen wie userId, orderId
• Typ-Präfix im Wert identifiziert die Entität: USER#, ORDER#
• Zusätzliches Attribut Type für explizite Kennzeichnung

One-to-Many: Konzept

Grundprinzip

• Parent-Item und Child-Items teilen denselben PK
• SK unterscheidet die Items innerhalb der Partition
• SK wird so gewählt, dass sinnvolle Sortierung entsteht
• Zeitstempel im SK → chronologische Sortierung automatisch

One-to-Many: User mit Bestellungen

Abfragemuster

• Alles auf einmal: Query PK = "USER#Alice" → Parent + alle Children
• Nur Children: Query PK + SK begins_with "ORDER#"
• Zeitbereich: Query PK + SK BETWEEN "ORDER#2024-01" AND "ORDER#2024-06"

Vorteile

• 1 Query statt mehrerer JOINs
• Zusammengehörige Daten physisch benachbart im Storage
• Horizontale Skalierung durch Partition-basiertes Sharding

E-Commerce: Überblick Single Table

Abfragemuster & ihre Queries

// AP-01: User-Profil
GetItem: PK="USER#U-001", SK="PROFILE"

// AP-02: Alle Bestellungen eines Users
Query:  PK = "USER#U-001"
        SK begins_with "ORDER#"

// AP-03: Items einer Bestellung
Query:  PK = "ORDER#2024-01-15"
        SK begins_with "ITEM#"

// AP-04: User + alle Bestellungen
Query:  PK = "USER#U-001"
// → liefert PROFILE + alle ORDER#-Items

Bestellungen Januar 2024
Query:
  PK = "USER#U-001"
  SK BETWEEN "ORDER#2024-01-01"
         AND "ORDER#2024-01-31"

// Bestellungen ganzes Jahr 2024
Query:
  PK = "USER#U-001"
  SK begins_with "ORDER#2024"

// Neueste 5 Bestellungen (absteigend)
Query:
  PK = "USER#U-001"
  SK begins_with "ORDER#"
  ScanIndexForward = false
  Limit = 5

GSI: Sekundäre Zugriffsmuster

GSI: Konzept & Anwendung

GSI-Grundlagen

• Global Secondary Index: eigener PK/SK, eigene Sortierung
• Bis zu 20 GSIs pro Tabelle
• Eigene Lese-/Schreibkapazität (oder On-Demand)
• Nur Eventually Consistent Reads
• Projection: KEYS_ONLY, INCLUDE, ALL

GSI-Overloading

• Generische GSI-Attribute: GSI1PK, GSI1SK
• Verschiedene Entitätstypen nutzen denselben GSI für unterschiedliche Zwecke
• Spart GSI-Slots (Limit: 20)

// Item: User-Profil
{
  PK:     "USER#U-001",
  SK:     "PROFILE",
  GSI1PK: "EMAIL#alice@x.de", 
  GSI1SK: "USER#U-001"
}

// Item: Bestellung
{
  PK:     "USER#U-001",
  SK:     "ORDER#2024-01-15",
  GSI1PK: "STATUS#PENDING", 
  GSI1SK: "2024-01-15"
}

// Query AP-06: User nach E-Mail
Query GSI1:
  GSI1PK = "EMAIL#alice@x.de"

E-Commerce: Umsetzung

Die Links verweisen auf die AWS-DynamoDB-Dokumentation

Struktur	Link
Basistabelle	link
GSI1	link
GSI2	link

Composite Sort Key: Hierarchische Abfragen

Sparse Index

Konzept

• GSI-Attribut nur bei bestimmten Items vorhanden
• DynamoDB indiziert nur Items, bei denen der GSI-Key existiert
• Effiziente Suche über eine kleine Teilmenge der Tabelle

Anwendungsfälle

• Alle offenen Bestellungen (Status = PENDING)
• Alle ablaufenden Sessions (ExpiresAt vorhanden)
• Alle VIP-Nutzer (VIP-Attribut gesetzt)
• Alle fehlgeschlagenen Jobs (ErrorCode gesetzt)

// Nur PENDING-Orders haben GSI1PK
{
  PK: "USER#Alice",
  SK: "ORDER#O-001",
  GSI1PK: "STATUS#PENDING"  // gesetzt
}
// Abgeschlossene Orders: kein GSI1PK
{
  PK: "USER#Alice",
  SK: "ORDER#O-002"
  // kein GSI1PK → nicht im Sparse GSI
}

Many-to-Many - Soziale Netzwerke

Die Follower-Beziehung ist many-to-many

• Eine Person kann mehrere Follower haben
• Eine Person kann mehrere Personen folgen

Der Link verweist auf die AWS-DynamoDB-Dokumentation: link

Single Table Design vs. Multi-Table Design

Aspekt	Single Table Design	Multi-Table Design
Queries	1 Query für alle Daten (1 Roundtrip)	Mehrere Queries + App-seitige JOINs
Effizienz	Maximal bei richtigem Modell	Mehr Roundtrips, höhere Latenz
Komplexität	Modellierung komplex, Betrieb einfach	Modellierung einfach, Betrieb komplexer
Lesbarkeit	Niedrig (generische Keys)	Hoch (sprechende Tabellen/Spalten)
Schema-Änderungen	Aufwendig (Schlüsselstruktur ändern)	Einfacher (neue Tabelle hinzufügen)
Monitoring	Schwieriger (alles in einer Tabelle)	Einfacher (pro Tabelle)
Einsatz	Bekannte, stabile Zugriffsmuster	Explorative, sich ändernde Abfragen