NoSQL („Not only SQL") bezeichnet Datenbanken, die bewusst auf das starre Tabellen-Schema klassischer relationaler Systeme verzichten. Statt Zeilen und Spalten nutzen sie flexible Datenmodelle wie Dokumente, Schlüssel-Wert-Paare oder Graphen. Der Name bedeutet nicht „kein SQL", sondern „nicht nur SQL": Viele NoSQL-Systeme bieten eigene Abfragesprachen oder sogar SQL-ähnliche Schnittstellen an.
Warum NoSQL?
Relationale Datenbanken wie MySQL oder PostgreSQL sind hervorragend für strukturierte Daten mit festen Beziehungen geeignet. Sie stoßen aber an Grenzen, wenn:
- Milliarden Datensätze auf viele Server verteilt werden müssen (horizontale Skalierung),
- die Datenstruktur sich häufig ändert (z. B. bei agiler Entwicklung),
- sehr hohe Lese- und Schreibgeschwindigkeiten gefragt sind (z. B. bei Sitzungen oder Caches),
- unstrukturierte Daten wie Logs, JSON-Dokumente oder Social-Media-Inhalte gespeichert werden.
Die wichtigsten NoSQL-Typen
- Dokumentenorientiert: Daten liegen als JSON-ähnliche Dokumente vor (z. B. MongoDB).
- Schlüssel-Wert-Speicher: Einfachste Form mit sehr hoher Geschwindigkeit (z. B. Redis).
- Spaltenorientiert: Optimiert für große Analysen (z. B. Apache Cassandra, Google Bigtable).
- Graphdatenbanken: Für stark vernetzte Daten wie soziale Beziehungen (z. B. Neo4j).
NoSQL vs. relationale Datenbanken
Relationale Systeme garantieren mit ACID strenge Konsistenz und unterstützen komplexe JOINs. NoSQL-Datenbanken lockern diese Garantien häufig zugunsten von Verfügbarkeit, Geschwindigkeit und Skalierbarkeit — ein Ansatz, der unter dem Kürzel BASE (Basically Available, Soft state, Eventual consistency) bekannt ist. Statt SQL mit festem Schema setzen sie auf flexible Schemas, die sich ohne Migration erweitern lassen.
Wann NoSQL sinnvoll ist
- Echtzeit-Analysen und große Log-Datenmengen
- Content-Management mit heterogenen Dokumenten
- Session-Speicher und Caches mit extrem niedriger Latenz
- Anwendungen, die von vornherein horizontal skalieren müssen
Für klassische Geschäftsanwendungen mit starken Beziehungen und Transaktionen bleibt die relationale Datenbank oft die bessere Wahl — Normalisierung und Schlüssel sorgen dort für Integrität. Eine moderne Architektur kombiniert beide Welten: SQL für das Kerngeschäft, NoSQL für spezialisierte Lasten.