Herkunft und bekannte Systeme
Den Begriff „NoSQL“ in seiner heutigen Bedeutung führte Johan Oskarsson 2009 ein. Seither versuchen diese Systeme, die Grenzen relationaler Datenbanken zu überwinden – vor allem bei verteilter Datenhaltung. Bekannte Vertreter sind Amazon DynamoDB und Google Bigtable sowie die quelloffenen Systeme Apache Cassandra, CouchDB, OrientDB und MongoDB.
Relationale Modelle arbeiten effizient bei vielen kleinen Transaktionen und großen Stapelverarbeitungen mit überwiegendem Lesezugriff. Skaliert wird dort in der Regel über stärkere Hardware und zusätzlichen Speicher. NoSQL setzt stattdessen auf „scaling out“: Die Last verteilt sich über viele Systeme statt über einen größeren Rechner.
NoSQL-Datenbankrevolution: Jenseits relationaler Modelle
NoSQL-Datenbanken können in vier Hauptkategorien unterteilt werden:
- Key-Value Datenbanken: Diese nutzen eine Hash-Tabelle, in der Schlüssel und ihre zugehörigen Datensatzzeiger gespeichert sind. Sie sind typischerweise mit Cache-Mechanismen zur Überwindung ausgestattet.
- Spaltenorientierte Datenbanken: Ideal für die Speicherung riesiger Datenmengen über viele Rechner verteilt. Ein Zeilenschlüssel adressiert eine komplette Zeile einer Spaltenfamilie.
- Dokumentenorientierte Datenbanken: Hier werden Dokumente verwendet, die Sammlungen von Schlüssel-Wert-Paaren sind. Diese semi-strukturierten Dokumente werden in Formaten wie JSON gespeichert.
- Graph- und Objektdatenbanken: Sie verwenden Graphen, die aus Knoten, Kanten und Knoteneigenschaften bestehen, und können über viele Rechner hinweg skaliert werden.
Wann lohnt sich NoSQL?
NoSQL ist kein Ersatz für relationale Datenbanken, sondern eine Ergänzung. Sinnvoll ist der Einsatz vor allem dann, wenn eines dieser Merkmale zutrifft:
- Die Datenmenge wächst über das hinaus, was ein einzelner Server sinnvoll trägt.
- Das Schema ändert sich häufig oder unterscheidet sich von Datensatz zu Datensatz.
- Es dominieren einfache Zugriffe über einen bekannten Schlüssel statt komplexer Verknüpfungen.
- Schreiblast und Leselast müssen über mehrere Standorte verteilt werden.
Bleiben dagegen Transaktionen über mehrere Tabellen, komplexe Auswertungen und ein festes Schema im Vordergrund, ist eine relationale Datenbank meist die bessere Wahl.
Konsistenz: ACID und BASE
Relationale Systeme folgen dem ACID-Prinzip: Eine Transaktion ist entweder vollständig oder gar nicht wirksam, und nach ihrem Abschluss sehen alle Beteiligten denselben Stand. Verteilte NoSQL-Systeme setzen häufig auf BASE – der Zustand ist grundsätzlich verfügbar, zwischenzeitlich weich und wird schließlich konsistent.
Der Hintergrund ist das CAP-Theorem: Fällt in einem verteilten System die Verbindung zwischen Knoten aus, muss man sich zwischen Konsistenz und Verfügbarkeit entscheiden. Viele NoSQL-Systeme lassen diese Abwägung pro Abfrage einstellen, etwa über die Anzahl der Knoten, die eine Schreiboperation bestätigen müssen.
Wichtig zu wissen: Moderne Vertreter wie MongoDB oder Couchbase beherrschen inzwischen auch Transaktionen über mehrere Dokumente. Die frühere Trennlinie „NoSQL kann keine Transaktionen“ ist damit überholt.
Datenmodellierung in NoSQL
Der größte Unterschied zur relationalen Welt liegt im Vorgehen: Statt die Daten zu normalisieren und die Abfragen später darauf aufzusetzen, modelliert man in NoSQL von den Abfragen her. Daten, die gemeinsam gelesen werden, liegen gemeinsam – auch wenn das Redundanz bedeutet.
Für Dokumentdatenbanken heißt das konkret: einbetten statt verknüpfen, solange die eingebetteten Daten überschaubar bleiben und sich nicht unabhängig ändern. Bei spaltenorientierten Systemen bestimmt der Partitionsschlüssel, wie gleichmäßig sich Last und Datenmenge über den Cluster verteilen – eine schlechte Wahl führt zu einzelnen überlasteten Knoten.
Typische Einsatzszenarien
- Nutzerprofile und Sitzungsdaten: schneller Zugriff über einen Schlüssel, hohe Schreibrate.
- Produktkataloge: Artikel mit sehr unterschiedlichen Eigenschaften in einem Modell.
- Zeitreihen und Telemetrie: große Mengen an Messwerten mit zeitlichem Bezug.
- Empfehlungen und Netzwerke: Beziehungen zwischen Objekten als Graph abbilden.
- Volltextsuche und Protokolldaten: dokumentorientierte Suche über große Bestände.
Betrieb und Skalierung
NoSQL-Systeme skalieren horizontal: Statt eines größeren Servers kommen weitere Knoten hinzu. Daten werden dabei über Sharding auf Partitionen verteilt und über Replikation mehrfach vorgehalten. Das erhöht Verfügbarkeit und Lesedurchsatz, verlangt aber ein durchdachtes Betriebskonzept.
Praktisch bewährt haben sich: Replikate über mehrere Verfügbarkeitszonen verteilen, Sicherungen regelmäßig zurückspielen statt nur anzulegen, Zugriffe über Rollen und Netzsegmentierung einschränken und die Verteilung der Partitionen im Blick behalten, bevor einzelne Knoten zum Engpass werden.
FAQ zu NoSQL
Wofür steht NoSQL?
Für „Not only SQL“. Der Begriff grenzt nicht-relationale Datenbanken ab, schließt SQL-ähnliche Abfragesprachen aber ausdrücklich nicht aus.
Ersetzt NoSQL relationale Datenbanken?
Nein. Beide Ansätze bestehen nebeneinander. Viele Anwendungen setzen beides gleichzeitig ein – relationale Systeme für Stammdaten und Abrechnung, NoSQL für Sitzungsdaten, Kataloge oder Telemetrie.
Gibt es in NoSQL Transaktionen?
Je nach System ja. Mehrere verbreitete Vertreter unterstützen inzwischen Transaktionen über mehrere Dokumente, wenn auch mit anderen Leistungseigenschaften als in relationalen Datenbanken.
Wie wählt man die passende Kategorie?
Über das Zugriffsmuster: Schlüssel-Wert für einfache Nachschlagevorgänge, dokumentorientiert für verschachtelte Objekte, spaltenorientiert für sehr große Schreibmengen, Graph für stark vernetzte Daten.
NoSQL-Datenbanken für skalierbare Anwendungen
Verwalten Sie große Datenmengen effizient mit unseren NoSQL-Lösungen. Perfekt für moderne, datenintensive Anwendungen.
Datenbanklösungen bei centron Cloud Hosting für Datenbanken