NoSQL – Was steckt hinter diesem Begriff?
Obwohl der Begriff NoSQL schon im Jahre 1998 (https://de.wikipedia.org/wiki/NoSQL) geprägt wurde und mittlerweile im allgemeinen IT-Sprachgebrauch etabliert ist, ist eine genaue Definition auch heute noch nicht eindeutig etabliert.
Deshalb möchte ich hier zwei Dinge zur Sicherheit anmerken:
- Der Bezug zu SQL ist unsinnig. NoSQL lehnt nicht die Abfragesprache SQL ab, sondern bezieht sich kritisch auf die relationale Datenmodellierung. Somit sollte eigentlich besser von “NoRelational” gesprochen werden.
- Zum zweiten kann auch “No” falsch interpretiert werden: Hier ist keine (dogmatische) Ablehnung gemeint, sondern “No” ist die Abkürzung für “Not only”. Also eine wesentlich schwächere Formulierung, die besagt, dass für die Datenablage “nicht nur/nicht ausschließlich” relationale Datenbanken benutzt werden sollten.
Relational allein genügt nicht
Warum ist ein relationales Modell nicht für alle Anwendungen gut geeignet? Dafür kann es je nach Anforderung unterschiedliche Argumente geben:
- Eine relationale Datenbank ist für bestimmte Szenarien ganz einfach Overhead. Warum soll beispielsweise eine Session einer Web-Anwendung in einer Tabelle abgelegt werden? Hierfür genügt ein simpler Cache.
- Das Navigieren über Relationen hinweg ist sehr Speicher- und Rechenintensiv. Selbst bei Benutzung moderner Hardware sind mehr als 6 – 8 verkettete Joins kaum möglich, ohne die Antwortzeiten dramatisch zu erhöhen.
- Und schließlich skalieren relationale Datenbanken in der Regel nur vertikal. Ein höherer Durchsatz kann damit nur durch mächtigere Hardware erreicht werden, was früher oder später an seine Grenzen stößt.
Ein vertikal skalierendes System Im Gegensatz dazu können horizontal skalierende Systeme durch Hinzufügen neuer Knoten praktisch beliebig erweitert werden:
Ein horizontal skalierendes System Ein relationales Modell kann aber nicht einfach über mehrere Knoten hinweg verteilt werden, da für die Ausführung selbst einfacher Abfragen eine aufwändige Kommunikation zwischen den Knoten und damit über Netzwerk notwendig wird.
Die 5 Kategorien von NoSQL-Datenbanken
NoSQL-Datenbanken werden in Kategorien aufgeteilt. Diese Kategorien sind als Extremwerte anzusehen, konkrete Produkte werden deshalb häufig nicht eindeutig einzuordnen sein.
- Key-Value-Datenbanken können Daten nur unter einem eindeutigen Key abspeichern und lesen. Obwohl dies eine recht deutliche Einschränkung darstellt, sind diese Systeme weit verbreitet und werden beispielsweise als zentrale Caches eingesetzt.
- Graphen-orientierte Datenbanken erweitern Relationen zu vollwertigen Datenstrukturen. Die Datenablage erfolgt nicht in einem Tabellen-Schema, sondern in Knoten, die über Relationen flexibel verbunden sind. Diese Form der Datenablage macht die Analyse von Graphen extrem schnell, so dass in der Praxis keine relevanten Beschränkungen auf die Anzahl zu verfolgender Verknüpfungen gegeben ist.
- Für Dokumenten-orientierte Datenbanken werden Daten nicht über Relationen modelliert, sondern über Verlinkung verbunden. Es ist Aufgabe des Clients, bei Bedarf die Links zu verfolgen, es gibt keine Datenbank-seitigen Joins. Ein Beispiel für eine Dokumenten-orientierte Datenbank wäre das gesamte Internet.
- Spalten-orientierte Datenbanken halten die Daten nicht in einer tabellarischen Struktur, sondern in einer verschachtelten Menge von Maps.
- Die Literatur zu NoSQL spricht in den allermeisten Fällen nur von 4 Kategorien. Allerdings gehört meiner Meinung nach eine weitere Gruppe definitiv mit dazu: Relationale Datenbanken! Nochmals: NoSQL heißt “Not only SQL”.
Einsatz von NoSQL-Datenbanken
Jede dieser Kategorien hat ihre speziellen Anwendungsfälle, für die der Einsatz einer entsprechenden Datenbank positive Effekte haben wird. Wichtig ist aber, hier nicht zu übertreiben: Nur weil NoSQL aktuell in vielen Unternehmen in verstärktem Maße eingeführt wird heißt es nicht, dass eine etablierte relationale Datenbank durch beispielsweise eine Spalten-orientiertes System abgelöst werden muss.
Jede fachliche Anforderung muss gesondert analysiert werden um entscheiden zu können, ob und welche Datenbank-Technologie am Besten geeignet ist.
