Modul 6: Data Architecture — SQL, NoSQL und Caching

Daten als Fundament

Die Datenbankwahl ist selten reversibel. SQL (relational) bietet Transaktionen, Joins und Konsistenz. NoSQL (Dokument, Key-Value, Spalte, Graph) bietet Flexibilität, horizontale Skalierung und schemalose Entwicklung. Die Entscheidung hängt von den Zugriffsmustern ab, nicht von Hypes.

Lesson 1: SQL vs. NoSQL — die richtige Wahl

SQL (PostgreSQL, MySQL): ACID-Transaktionen, relationale Integrität, Joins. Ideal für komplexe Beziehungen und konsistente Daten. NoSQL: Document (MongoDB) für flexible Schemas, Key-Value (Redis) für Caching, Spalte (Cassandra) für zeitreihen, Graph (Neo4j) für Beziehungen. Hybrid ist normal: SQL für Transaktionen, NoSQL für Spezialfälle.

Lesson 2: Normalisierung und Denormalisierung

Normalisierung (1NF-3NF) reduziert Redundanz: jede Tatsache einmal. Vorteile: Konsistenz, wenig Speicher. Nachteil: Joins werden teuer bei Lese-intensiven Workloads. Denormalisierung dupliziert Daten bewusst für Lese-Performance. Faustregel: Schreiben-normalisiert, Lesen-denormalisiert (Views, Materialized Views, CQRS).

Lesson 3: Indizierung — der größte Hebel

Ein Index ist ein sortierter Verweis auf Zeilen. B-Tree (Standard), Hash (exakte Treffer), GIN (Volltext). Indizes beschleunigen Lesezugriffe um Größenordnungen, verlangsamen aber Schreibvorgänge. Faustregel: Index auf Foreign Keys, häufig gefilterte Spalten und Sortier-Spalten. EXPLAIN ANALYZE zeigt, ob der Index genutzt wird. Über-Indizierung ist genauso schädlich wie Unter-Indizierung.

-- Query wird langsam ohne Index: Seq Scan über 10 Mio Zeilen
SELECT * FROM claims WHERE policy_id = ? AND status = 'OPEN';

-- Index auf die gefilterten Spalten
CREATE INDEX idx_claims_policy_status ON claims (policy_id, status);

-- Prüfen: Seq Scan -> Index Scan in der Ausgabe
EXPLAIN ANALYZE SELECT * FROM claims
  WHERE policy_id = 42 AND status = 'OPEN';

Lesson 4: Caching-Strategien

Cache-Aside (Lazy Loading): Anwendung liest Cache, bei Miss die DB und füllt den Cache. Write-Through: Jeder Schreibvorgang geht auch in den Cache. Write-Behind: Schreiben in den Cache, asynchron in die DB. TTL verhindert stale Daten. Mehrstufig: L1 (in-prozess), L2 (Redis), CDN für statische Assets. Cache-Invalidierung ist das schwerste Problem („There are only two hard things...").

Lesson 5: CQRS — Lesen und Schreiben trennen

Command Query Responsibility Segregation: Schreibmodell (Commands) und Lesemodell (Queries) sind getrennt. Das Schreibmodell optimiert für Validierung und Konsistenz (normalisiert), das Lesemodell für Abfrageperformance (denormalisiert). Events synchronisieren die Modelle. Vorteil: Unabhängige Skalierung von Lese- und Schreiblast. Nachteil: Eventuelle Konsistenz, mehr Infrastruktur.