Die NoSQL-Landschaft: vier Familien und die richtige Wahl

Worum es geht

Tim arbeitet im 2. Lehrjahr bei der Alpwerk Software AG in Chur. Sein Team baut für eine Tourismusorganisation ein Portal mit Wanderungen, Biketouren und Schneeschuhtrails. Der erste Prototyp läuft mit MariaDB, und die Tabelle tour sieht inzwischen so aus:

Jede Tourenart braucht andere Felder: Wanderungen die SAC-Wanderskala (T1 bis T6), Biketouren die Singletrail-Skala (S0 bis S5), Schneeschuhtouren eine eigene Skala (WT1 bis WT6). Jede neue Angabe bedeutet ALTER TABLE, Migration und angepassten Code, und die Hälfte der Zellen ist NULL.

Die Projektleiterin fragt: «Sollen wir auf NoSQL wechseln?» Tim soll eine Empfehlung vorbereiten. In dieser Lektion lernst du die vier NoSQL-Familien kennen und begründest eine Datenbankwahl anhand von Anforderungen statt nach Trend.

Was «NoSQL» wirklich bedeutet

NoSQL ist kein Produkt und keine einzelne Technologie, sondern ein Sammelbegriff. Heute liest man ihn meist als «Not only SQL»: Datenbanken, die nicht oder nicht nur mit dem relationalen Tabellenmodell arbeiten. Was sie verbindet:

• Flexibles Schema: Nicht jeder Datensatz muss dieselben Felder haben.
• Spezialisierung: Jede Familie ist für bestimmte Zugriffsmuster optimiert.
• Horizontale Skalierung: Daten werden auf mehrere Server verteilt, statt einen Server immer grösser zu machen.

Zur Erinnerung aus den Modulen 162 und 164: Eine relationale Datenbank speichert normalisierte Tabellen mit festen Spalten, verbindet sie mit Joins und sichert Änderungen mit ACID-Transaktionen ab. Ideal für Geschäftsdaten mit klaren Regeln wie Rechnungen oder Lager.

Ein Bild aus dem Büroalltag hilft beim Einordnen:

• Relational: eine Hängeregistratur mit genormten Formularen, Querverweise über Nummern.
• Dokument: ein Schrank mit Dossiers. Jedes enthält alles zu einem Fall und darf anders aufgebaut sein.
• Key-Value: die Theatergarderobe. Gegen die Nummer bekommst du sofort deine Jacke, aber «alle roten Jacken» findet niemand.
• Graph: eine Pinnwand mit Fäden zwischen Personen und Orten. Die Fäden sind so wichtig wie die Karten.

Die vier Familien im Überblick

Dokumentdatenbanken

Eine Dokumentdatenbank speichert Datensätze als Dokumente, meist im JSON-Format beziehungsweise in einer binären Variante davon. Ein Dokument kann verschachtelte Objekte und Arrays enthalten, und Dokumente in derselben Sammlung (Collection) dürfen unterschiedliche Felder haben. Der bekannteste Vertreter ist MongoDB, weitere sind Couchbase oder Firestore.

{
  "titel": "Flimser Trailrunde",
  "art": "Biketour",
  "distanz_km": 24.0,
  "hoehenmeter": 950,
  "trailskala": "S2",
  "e_bike_ladestation": true,
  "etappen": [
    { "nr": 1, "von": "Flims Dorf", "bis": "Foppa", "km": 6.2 },
    { "nr": 2, "von": "Foppa", "bis": "Caumasee", "km": 9.4 }
  ]
}

Die Biketour hat eine Trailskala, die Wanderung daneben eine SAC-Skala. Keine NULL-Spalten, kein ALTER TABLE. Das passt zu Produktkatalogen, Inhalten mit wechselnder Struktur und allem, was die Applikation ohnehin als Objekt mit Unterobjekten verarbeitet.

Key-Value-Stores

Ein Key-Value-Store speichert Werte unter einem eindeutigen Schlüssel: schreiben, lesen, löschen. Weil die Daten im Arbeitsspeicher liegen, dauert ein Zugriff oft weniger als eine Millisekunde. Bekannte Vertreter: Redis und der kompatible Fork Valkey.

SET wetter:chur '{"temp":12,"wetter":"sonnig"}' EX 600
GET wetter:chur

Typische Einsätze: Cache, Sessions, Zähler, Warteschlangen, Ranglisten (mehr in Lektion 7).

Spaltenorientierte Datenbanken (Wide Column)

Wide-Column-Datenbanken wie Apache Cassandra verteilen riesige Datenmengen auf viele Server. Jede Zeile gehört über einen Partitionsschlüssel zu einer Partition, darin sind die Zeilen sortiert. Die Sprache CQL sieht aus wie SQL, aber du fragst fast immer über den Partitionsschlüssel ab, Joins gibt es nicht.

CREATE TABLE messwerte (
  zaehler_id    text,
  tag           date,
  zeitpunkt     timestamp,
  verbrauch_kwh double,
  PRIMARY KEY ((zaehler_id, tag), zeitpunkt)
);

Das passt zu Anwendungen mit sehr vielen Schreibzugriffen: Sensordaten von Tausenden Smart Metern, Logeinträge, Klickströme.

Graphdatenbanken

Eine Graphdatenbank speichert Knoten (Personen, Touren, Orte) und Kanten (Beziehungen wie «bewertet» oder «folgt»). Beziehungen sind gespeicherte Verbindungen, denen die Datenbank direkt folgt, statt Fremdschlüssel zur Laufzeit zusammenzusuchen. Bekanntester Vertreter: Neo4j mit der Sprache Cypher.

MATCH (t:Tour {titel: "Prättigauer Höhenweg"})<-[:BEWERTET]-(p:Person)-[:BEWERTET]->(andere:Tour)
RETURN andere.titel, count(p) AS gemeinsame_fans
ORDER BY gemeinsame_fans DESC LIMIT 5

Die Abfrage beantwortet: «Wer diese Tour mochte, mochte auch ...». In SQL bräuchtest du mehrere Self-Joins, die mit jeder Beziehungsstufe langsamer werden. Typische Einsätze: Empfehlungen, soziale Netzwerke, Betrugserkennung.

Relational oder NoSQL? Nach Anforderungen entscheiden

Die wichtigste Regel zuerst: Es gibt keine «bessere» Datenbank, nur eine passendere für eine bestimmte Anforderung. Wer NoSQL wählt, weil es modern klingt, kämpft danach oft mit Problemen, die eine relationale Datenbank nie gehabt hätte. Umgekehrt quälen sich Teams mit Dutzenden NULL-Spalten, weil «wir immer MariaDB nehmen».

Diese Fragen helfen bei der Entscheidung:

Viele Systeme kombinieren mehrere Datenbanken. Das nennt man Polyglot Persistence: Jeder Teil bekommt die passende Datenhaltung. Ein Ticketanbieter speichert zum Beispiel Veranstaltungen mit unterschiedlichen Angaben in MongoDB, die Warteschlange beim Vorverkaufsstart in Redis und Zahlungen in PostgreSQL, weil dort Transaktionen Pflicht sind. Der Preis: Das Team betreibt mehrere Systeme.

Der Entscheidungsbaum ist eine Denkhilfe, kein Gesetz. Er zeigt die Reihenfolge: zuerst harte Anforderungen (Transaktionen), dann Zugriffsmuster.

Schritt für Schritt: Tims Empfehlung fürs Teammeeting

Tim geht systematisch vor und schreibt seine Empfehlung so, dass das Team sie nachvollziehen kann.

Schritt 1: Anforderungen sammeln. Aus Gesprächen mit der Tourismusorganisation notiert er:

• vier Tourenarten mit unterschiedlichen Angaben, Klettersteige geplant
• rund 25'000 Touren nach drei Jahren
• etwa 95 % Lesezugriffe, die Redaktion schreibt wenig
• Wetter für 40 Orte von einem externen Dienst, der fast eine Sekunde pro Abfrage braucht
• Rechnungen an Partnerbetriebe, bereits in MariaDB

Schritt 2: Die wichtigsten Zugriffsmuster aufschreiben.

1. Tourdetailseite: Tour mit Etappen und Fotos laden (sehr häufig)
2. Suche nach Region, Art und Schwierigkeit (häufig)
3. Wetter am Startort anzeigen (bei jedem Aufruf)
4. Tour erfassen oder ändern (selten)
5. Rechnung verbuchen (monatlich, muss exakt stimmen)

Schritt 3: Teilbereiche bilden. Touren, Wetter und Rechnungen haben ganz andere Anforderungen und werden getrennt bewertet.

Schritt 4: Kandidaten bewerten. (+ passt gut, o geht, - passt schlecht)

Schritt 5: Entscheiden und begründen. Tims Text für das Meeting:

Touren: MongoDB. Die vier Tourenarten haben unterschiedliche Felder, und die
Detailseite lädt eine Tour mit Etappen und Fotos als Ganzes. Ein Dokument pro
Tour bildet das direkt ab, neue Felder brauchen keine Migration.

Wetter: Redis als Cache mit 10 Minuten Ablaufzeit. Der Wetterdienst ist langsam,
die Daten sind kurzlebig und werden nur über den Ort gelesen.

Rechnungen: bleiben in MariaDB. Hier zählen Transaktionen und exakte Beträge,
das relationale Modell ist dafür ideal und bereits im Einsatz.

Schritt 6: Risiken offen nennen. Tim ergänzt: «Wir betreiben damit drei Systeme statt einem, und das Team muss MongoDB lernen. Gegen uneinheitliche Daten definieren wir Pflichtfelder (Lektion 6).»

Typische Fehler

1. NoSQL wählen, weil es modern klingt. Verlangen die Anforderungen Transaktionen und feste Beziehungen, ist relational meist besser. Begründe immer konkret.
2. «Schemafrei» mit «ohne Regeln» verwechseln. Die Applikation erwartet trotzdem eine Struktur. Ohne Regeln hast du bald distanz, distanz_km und Distanz nebeneinander.
3. MongoDB wie eine relationale Datenbank benutzen. Eine Collection pro Tabelle und Verknüpfungen in jeder Abfrage verschenken genau die Stärken von Dokumenten.
4. Redis als einzige Ablage für wichtige Daten. Redis hält Daten im Arbeitsspeicher. Für einen Cache ist das ideal, für Rechnungen ohne zusätzliche Absicherung nicht.
5. Zu viele Technologien. Jede Datenbank muss gesichert, aktualisiert und überwacht werden. Eine zusätzliche lohnt sich nur, wenn der Nutzen den Aufwand übersteigt.

Zusammenfassung

• NoSQL ist ein Sammelbegriff für Datenbanken, die nicht oder nicht nur mit Tabellen arbeiten.
• Die vier Familien: Dokument (MongoDB), Key-Value (Redis), Wide Column (Cassandra) und Graph (Neo4j). Jede ist für bestimmte Zugriffsmuster gebaut.
• Relationale Datenbanken bleiben erste Wahl für Daten mit festen Regeln und Transaktionen über viele Datensätze.
• Entscheide nach Struktur, Zugriffsmustern, Konsistenz, Last und Betriebsaufwand, nicht nach Trend.
• Polyglot Persistence kombiniert mehrere Datenbanken, kostet aber zusätzlichen Betriebsaufwand.
• Eine gute Empfehlung nennt pro Teilbereich die Wahl, die Begründung und die Risiken.