Warum NoSQL?
Wenn du relationale Datenbanken kennst – Tabellen, Zeilen, SQL, Constraints – kommt dir die Welt erstmal ordentlich vor. Schemas sind definiert, Beziehungen klar, ACID-Garantien verhindern Datenchaos. Warum sollte irgendjemand etwas anderes wollen?
Die Antwort ist: weil in den 2000ern Web-Anwendungen entstanden sind, deren Bedürfnisse nicht mehr zu klassischen Datenbanken passten. Facebook mit Milliarden Posts, Amazon mit Millionen Produktklicks pro Sekunde, Twitter mit unstrukturierten Daten – diese Use Cases brachen relationale Systeme an drei Stellen: Skalierung, Schema-Flexibilität und Datenmodell-Anpassung. Daraus entstand die NoSQL-Bewegung – kein „kein SQL", sondern „Not Only SQL".
1) Das Skalierungsproblem
Eine klassische SQL-Datenbank läuft auf einem Server. Wenn der zu klein wird, gibt es zwei Wege: vertikale Skalierung („Scale up") – einen stärkeren Server kaufen. Oder horizontale Skalierung („Scale out") – mehrere Server zusammenschalten. Letzteres ist mit relationalen DBs sehr schwierig, weil JOINs über Server-Grenzen extrem teuer werden.
2) Das Schema-Problem
Eine SQL-Tabelle hat ein festes Schema: definierte Spalten, feste Datentypen. Jede Zeile sieht gleich aus. Wenn du eine neue Spalte willst, ist ein ALTER TABLE nötig – bei großen Tabellen eine teure Operation. Wenn manche Zeilen das Feld brauchen und andere nicht, hast du viele NULL-Werte.
In modernen Web-Anwendungen ändern sich Datenstrukturen ständig: neue Felder, optionale Attribute, verschachtelte Strukturen. Ein Produkt mit 5 Eigenschaften heute, mit 23 morgen, mit teils geteilten Eigenschaften. Im SQL-Schema wird das schnell zur Tortur.
| id | name | preis | autor | seiten | spieldauer |
|---|---|---|---|---|---|
| 1 | Roman | 19,90 | Müller | 320 | NULL |
| 2 | Brettspiel | 45,00 | NULL | NULL | 90 min |
| 3 | Stift | 2,50 | NULL | NULL | NULL |
Viele NULL-Werte, weil unterschiedliche Produkttypen unterschiedliche Felder brauchen. Neue Produktart → ALTER TABLE.
preis: 19.90, autor: "Müller",
seiten: 320 }
preis: 45.00,
spieldauer: "90 min" }
preis: 2.50 }
Jedes Dokument trägt nur die Felder, die es braucht. Neues Feld? Einfach hinzufügen, kein Schema-Update nötig.
3) Die historische Entwicklung
NoSQL ist keine spontane Erfindung, sondern eine Reaktion auf reale Probleme der Web-Riesen Anfang der 2000er. Eine kurze Zeitleiste der wichtigsten Stationen:
4) Wo NoSQL glänzt
NoSQL ist kein Universalwerkzeug. Es löst bestimmte Probleme besser als SQL – und andere schlechter. Hier die klassischen Stärken-Domänen:
5) Wo NoSQL Nachteile hat
Genauso wichtig wie die Stärken sind die Schwächen. Wer sie ignoriert, baut sich Schmerzen ein. Drei häufige Stolpersteine:
- Schwächere Konsistenz-Garantien: viele NoSQL-Systeme bieten nur „Eventually Consistent" statt voller ACID. Heißt: kurz nach einem Schreibvorgang können andere Knoten noch alte Daten liefern. Für Likes okay, für Kontostände nicht. Mehr dazu im CAP-Theorem (Lektion 3).
- Weniger Standardisierung: SQL ist normiert, NoSQL nicht. Jede DB hat eine eigene Query-Sprache, eigene Tools, eigene Konzepte. Wechsel von MongoDB zu Cassandra ist viel mehr Arbeit als von MySQL zu PostgreSQL.
- Komplexe Abfragen sind schwerer: Was in SQL ein einziger JOIN ist, wird in vielen NoSQL-DBs zu mehreren Round-Trips oder zur Datenduplikation. Geschäfts-Reports, die in SQL trivial sind, werden oft kompliziert.
Die ehrliche Wahrheit: relationale DBs sind nicht schlecht. Sie sind seit 50 Jahren weiterentwickelt, hochoptimiert, robust. Wenn dein Use Case in eine relationale DB passt, nimm eine. NoSQL nur dort, wo die SQL-Welt an echte Grenzen stößt.
6) Polyglot Persistence – das pragmatische Ende
Der heutige Standard in größeren Architekturen heißt Polyglot Persistence: man nutzt mehrere Datenspeicher parallel, jeweils für das, was sie am besten können. Ein typisches Setup:
- Eine relationale DB (PostgreSQL, MySQL) für die Kerngeschäftsdaten mit ACID-Anforderungen: Kunden, Bestellungen, Rechnungen.
- Eine Dokumenten-DB (MongoDB) für variable Daten: Produktkataloge mit unterschiedlichen Attributen, User-generated Content.
- Ein Key-Value-Store (Redis) für Cache und Sessions: Login-Tokens, gerenderte Seiten, Counter.
- Eine Such-Engine (Elasticsearch) für Volltextsuche.
- Eine Graph-DB (Neo4j) für Empfehlungen und Beziehungs-Analysen.
Das macht die Architektur komplexer – aber jedes Tool macht das, wofür es gebaut ist. Wer alles in eine einzige DB stopft, optimiert für Einfachheit, zahlt aber an anderer Stelle (Performance, Kosten, Skalierung).
Zusammenfassung
NoSQL („Not Only SQL") ist eine Familie nicht-relationaler Datenbanken, die ab Mitte der 2000er als Antwort auf die Skalierungs-Probleme der Web-Riesen entstand. Drei Hauptgründe für NoSQL: horizontale Skalierung (viele günstige Server statt eines großen, „Scale out"), Schema-Flexibilität (unterschiedliche Datensätze in einer Collection, keine ALTER TABLE-Schmerzen), angepasste Datenmodelle für spezifische Use Cases (Dokumente, Key-Value, Graphen, Spalten). NoSQL ist kein Ersatz für SQL, sondern ein Ergänzung für spezielle Use Cases: Big Data, hochfrequente Schreibvorgänge, unstrukturierte Daten, Caching, Graphen, globale Verteilung. Nachteile: schwächere Konsistenz, weniger Standardisierung, komplexere Abfragen. Modernes Pragma: Polyglot Persistence – mehrere Datenspeicher kombinieren, jeden für das was er kann.