SQL-Datenbanken unterliegen Beschränkungen in Bezug auf Datentypen und Konsistenz. NoSQL hebt diese zugunsten von Geschwindigkeit, Flexibilität und Skalierbarkeit auf. [...]
Eine der grundlegendsten Entscheidungen, die bei der Entwicklung einer Anwendung zu treffen sind, ist die Frage, ob eine SQL- oder eine NoSQL-Datenbank für die Speicherung der Daten verwendet werden soll. Herkömmliche Datenbanken, also relationale Datenbanken, die SQL (Structured Query Language) für Abfragen verwenden, sind das Ergebnis jahrzehntelanger technologischer Entwicklung, bewährter Verfahren und Belastungstests in der Praxis. Sie sind für zuverlässige Transaktionen und Ad-hoc-Abfragen konzipiert, die Grundpfeiler von Geschäftsanwendungen. Sie sind jedoch auch mit Einschränkungen behaftet, wie z. B. starren Schemata, die sie für andere Arten von Anwendungen weniger geeignet machen.
NoSQL-Datenbanken sind als Antwort auf diese Einschränkungen entstanden. NoSQL-Systeme speichern und verwalten Daten auf eine Art und Weise, die eine hohe Betriebsgeschwindigkeit und große Flexibilität seitens der Entwickler ermöglicht. Viele von ihnen wurden von Unternehmen wie Google, Amazon, Yahoo und Facebook entwickelt, die nach besseren Möglichkeiten suchten, Inhalte zu speichern oder Daten für umfangreiche Websites zu verarbeiten.
Im Gegensatz zu SQL-Datenbanken können viele NoSQL-Datenbanken horizontal über Hunderte oder sogar Tausende von Servern skaliert werden.
Die Vorteile von NoSQL kommen jedoch nicht ganz ohne Folgen. NoSQL-Systeme legen mehr Wert auf Geschwindigkeit und Skalierbarkeit als auf die von SQL-Datenbanken versprochenen ACID-Eigenschaften, die für zuverlässige Transaktionen sorgen. Und auch die Metaphern, die für die Arbeit mit Daten in NoSQL-Systemen verwendet werden, sind relativ neu, verglichen mit dem jahrzehntelangen institutionellen Wissen, das um SQL herum aufgebaut wurde.
SQL- und NoSQL-Datenbanken bieten unterschiedliche Kompromisse. Während sie im Kontext eines bestimmten Projekts miteinander konkurrieren können – z. B. bei der Frage, welche für diese oder jene Anwendung zu wählen ist -, ergänzen sie sich im Gesamtbild. Jede eignet sich für unterschiedliche Anwendungsfälle. Bei der Entscheidung geht es nicht so sehr um ein Entweder-Oder, sondern vielmehr um die Frage, welches Tool für die jeweilige Aufgabe am besten geeignet ist.
NoSQL im Vergleich zu SQL
Der grundlegende Unterschied zwischen SQL und NoSQL ist gar nicht so gravierend. Sie verfolgen jeweils eine andere Philosophie, wie Daten gespeichert und abgerufen werden sollten.
Bei SQL-Datenbanken haben alle Daten eine inhärente Struktur. Eine herkömmliche Datenbank wie Microsoft SQL Server, MySQL, PostgreSQL oder Oracle Database verwendet ein Schema – eine formale Definition, wie die in die Datenbank eingefügten Daten zusammengesetzt werden. So kann beispielsweise eine bestimmte Spalte in einer Tabelle nur auf Ganzzahlen beschränkt sein.
Dies hat zur Folge, dass die in dieser Spalte gespeicherten Daten einen hohen Grad an Normalisierung aufweisen. Das starre Schema einer SQL-Datenbank macht es auch relativ einfach, Daten zu aggregieren, indem beispielsweise Daten aus zwei Tabellen mit dem SQL-Befehl JOIN kombiniert werden.
Bei NoSQL können die Daten schemaunabhängig oder in freier Form gespeichert werden. Alle Daten können in jedem Datensatz gespeichert werden. Unter den NoSQL-Datenbanken gibt es vier gängige Modelle für die Speicherung von Daten, die zu vier gängigen Typen von NoSQL-Systemen führen:
- Dokumentendatenbanken (z. B. MongoDB). Eingegebene Daten werden in Form von schemafreien JSON-Strukturen oder „Dokumenten“ gespeichert, wobei es sich bei den Daten um Ganzzahlen, Strings oder Freiformtext handeln kann. Es besteht keine Notwendigkeit, festzulegen, ob und welche Felder ein JSON-Dokument enthalten soll.
- Schlüssel-Wert-Speicher (z. B. Redis). Auf Freiformwerte, von einfachen ganzen Zahlen oder Zeichenketten bis hin zu komplexen JSON-Dokumenten, wird in der Datenbank mit Hilfe von Schlüsseln, wie z. B. Zeichenketten, zugegriffen.
- Breite Spaltenspeicher (z. B. Cassandra). Die Daten werden in Spalten und nicht in Zeilen wie in einem herkömmlichen SQL-System gespeichert. Eine beliebige Anzahl von Spalten (und damit viele verschiedene Datentypen) können je nach Bedarf für Abfragen oder Datenansichten gruppiert oder aggregiert werden.
- Graphdatenbanken (z. B. Neo4j). Die Daten werden als Netzwerk oder Graph von Entitäten und ihren Beziehungen dargestellt, wobei jedes Node im Graphen ein frei geformtes Datenstück ist.
Die schemafreie Datenspeicherung kann in der Praxis in folgenden Fällen nützlich sein:
- Sie wollen schnellen Zugriff auf die Daten und legen mehr Wert auf Geschwindigkeit und einfachen Zugriff als auf zuverlässige Transaktionen oder Konsistenz.
- Sie speichern eine große Datenmenge und wollen sich nicht auf ein Schema festlegen, da eine spätere Änderung des Schemas langwierig und mühsam sein könnte.
- Sie nehmen unstrukturierte Daten aus einer oder mehreren Quellen auf und möchten die Daten in ihrer ursprünglichen Form behalten, um maximale Flexibilität zu gewährleisten.
- Sie möchten Daten in einer hierarchischen Struktur speichern, aber Sie möchten, dass diese Hierarchien durch die Daten selbst und nicht durch ein externes Schema beschrieben werden. NoSQL ermöglicht es, dass Daten auf eine Art und Weise selbstreferenziell sind, die für SQL-Datenbanken nur schwer zu emulieren ist.
Abfragen von NoSQL-Datenbanken
Die Structured Query Language, die von relationalen Datenbanken verwendet wird, bietet eine einheitliche Methode zur Kommunikation mit dem Server beim Speichern und Abrufen von Daten. Die SQL-Syntax ist in hohem Maße standardisiert, so dass die einzelnen Datenbanken zwar bestimmte Vorgänge unterschiedlich handhaben (z. B. Fensterfunktionen), die Grundlagen aber gleich bleiben.
Im Gegensatz dazu hat jede NoSQL-Datenbank ihre eigene Syntax für die Abfrage und Verwaltung der Daten. CouchDB zum Beispiel verwendet Anfragen in Form von JSON, die über HTTP gesendet werden, um Dokumente in der Datenbank zu erstellen oder abzurufen. MongoDB sendet JSON-Objekte über ein binäres Protokoll, über eine Kommandozeile oder eine Programmbibliothek.
Einige NoSQL-Produkte können eine SQL-ähnliche Syntax für die Arbeit mit Daten verwenden, allerdings nur in begrenztem Umfang. Apache Cassandra, ein breiter Spaltenspeicher, verfügt beispielsweise über eine eigene SQL-ähnliche Sprache, die Cassandra Query Language oder CQL.
Einige der CQL-Syntaxen stammen direkt aus dem SQL-Spielbuch, wie die Schlüsselwörter SELECT oder INSERT. Es gibt jedoch keine native Möglichkeit, eine JOIN- oder Unterabfrage in Cassandra durchzuführen, und daher gibt es die entsprechenden Schlüsselwörter in CQL nicht.
Shared-Nothing Architektur
Eine für NoSQL-Systeme übliche Designentscheidung ist eine „Shared-Nothing“-Architektur. In einem Shared-Nothing-Design arbeitet jeder Serverknoten im Cluster unabhängig von jedem anderen Knoten. Das System muss nicht die Zustimmung der anderen Nodes einholen, um Daten an einen Client zurückzugeben. Abfragen sind schnell, da sie von dem Node zurückgegeben werden können, der am nächsten liegt oder am praktischsten ist.
Ein weiterer Vorteil eines Shared-Nothing-Systems ist die Ausfallsicherheit und Skalierbarkeit. Die Skalierung des Clusters ist so einfach wie das Aufsetzen neuer Nodes im Cluster und das Warten darauf, dass sie mit den anderen synchronisiert werden.
Wenn ein NoSQL Node ausfällt, laufen die anderen Server im Cluster weiter. Alle Daten bleiben verfügbar, auch wenn weniger Nodes für die Bearbeitung von Anfragen zur Verfügung stehen.
Zu beachten ist, dass ein Shared-Nothing-Design nicht nur für NoSQL-Datenbanken gilt. Viele herkömmliche SQL-Systeme können nach dem Shared-Nothing-Konzept eingerichtet werden, wie z. B. MySQL, obwohl dies in der Regel bedeutet, dass die Konsistenz im gesamten Cluster zugunsten der Leistung geopfert wird.
Auch NoSQL ist nicht ohne Fehler
Wenn NoSQL so viel Freiheit und Flexibilität bietet, warum sollte man dann nicht ganz auf SQL verzichten? Die einfache Antwort ist, dass viele Anwendungen nach wie vor die Arten von Einschränkungen, Konsistenz und Schutzmaßnahmen erfordern, die SQL-Datenbanken bieten.
In diesen Fällen können sich einige „Vorteile“ von NoSQL in Nachteile verwandeln. Andere Einschränkungen ergeben sich aus der Tatsache, dass NoSQL-Systemen bestimmte Funktionen fehlen, die man im SQL-Bereich als selbstverständlich ansieht.
Selbst wenn Sie Daten in freier Form erfassen, müssen Sie fast immer Beschränkungen für die Daten festlegen, um sie nutzbar zu machen. Bei NoSQL bedeutet das Auferlegen von Beschränkungen, dass die Verantwortung von der Datenbank auf den Anwendungsentwickler übertragen wird. Der Entwickler könnte zum Beispiel durch ein objektrelationales Mapping-System (ORM) eine Struktur vorgeben. Wenn Sie jedoch möchten, dass das Schema mit den Daten selbst verbunden ist, wird dies von NoSQL in der Regel nicht unterstützt.
Einige NoSQL-Lösungen bieten optionale Datentypisierungs- und Validierungsmechanismen für Daten. Apache Cassandra beispielsweise verfügt über eine Reihe von nativen Datentypen, die an die in herkömmlichem SQL verwendeten Typen erinnern.
Eventuelle Redundanz
NoSQL-Systeme bieten die Möglichkeit, eine starke oder sofortige Beständigkeit gegen eine bessere Verfügbarkeit und Leistung einzutauschen. Herkömmliche Datenbanken stellen sicher, dass Vorgänge atomar (alle Teile einer Transaktion werden erfolgreich ausgeführt oder überhaupt keine), konsistent (alle Benutzer haben die gleiche Sicht auf die Daten), isoliert (Transaktionen konkurrieren nicht miteinander) und dauerhaft (einmal abgeschlossen, überstehen sie einen Serverausfall) sind.
Diese vier Eigenschaften, die zusammen als ACID bezeichnet werden, können in NoSQL-Systemen anders gehandhabt werden. Anstatt eine starke Konsistenz im gesamten Cluster zu verlangen, was zwangsläufig zu Verzögerungen bei der Beantwortung von Anfragen führen würde, können Sie sich für eine eventuelle Beständigkeit entscheiden, die es ermöglicht, Anfragen zu bedienen, ohne darauf zu warten, dass die letzten Schreibvorgänge auf andere Nodes im Cluster kopiert werden.
Die in den Cluster eingefügten Daten sind dann letztendlich überall verfügbar, aber Sie können nicht garantieren, wann.
Bei einigen NoSQL-Systemen können Sie sich für einen von mehreren Kompromissen zwischen Beständigkeit und Geschwindigkeit entscheiden, wobei die Angebote je nach Produkt variieren. Bei Azure Cosmos DB von Microsoft können Sie zum Beispiel ein Beständigkeitslevel pro Anfrage auswählen, so dass Sie das Verhalten wählen können, das zu Ihrem Anwendungsfall passt.
Die Transaktionssemantik, die in einem SQL-System garantiert, dass alle Schritte einer Transaktion (z. B. die Ausführung eines Verkaufs und die Reduzierung des Lagerbestands) entweder abgeschlossen oder rückgängig gemacht werden, ist in einigen NoSQL-Systemen wie MongoDB verfügbar.
NoSQL-Bindung
Die meisten NoSQL-Systeme sind konzeptionell ähnlich, aber unterschiedlich implementiert. Jedes hat seine eigenen Metaphern und Mechanismen für die Abfrage und Verwaltung von Daten.
Ein Nebeneffekt davon ist ein potenziell hohes Maß an Abhängigkeit zwischen der Anwendungslogik und der Datenbank. Diese Abhängigkeit ist nicht so schlimm, wenn Sie sich für ein NoSQL-System entscheiden und bei diesem bleiben, aber sie kann zu einem Stolperstein werden, wenn Sie das System später wechseln.
Wenn man z.B. von MongoDB zu CouchDB (oder umgekehrt) migriert, muss man mehr tun als nur Daten zu migrieren. Sie müssen sich auch mit den Unterschieden im Datenzugriff und den programmatischen Metaphern auseinandersetzen. Das heißt, Sie müssen die Teile Ihrer Anwendung, die auf die Datenbank zugreifen, neu schreiben.
NoSQL Fachwissen
Ein weiterer Nachteil von NoSQL ist der relative Mangel an Fachwissen. Während der Markt für herkömmliche SQL-Talente recht groß ist, ist der Markt für NoSQL-Kenntnisse erst im Entstehen begriffen.
Indeed.com berichtet, dass bis 2022 die Zahl der Stellenangebote für herkömmliche SQL-Datenbanken – MySQL, Microsoft SQL Server, Oracle Database usw. – höher sein wird als die Zahl der Stellenangebote für MongoDB, Couchbase und Cassandra. Die Nachfrage nach NoSQL-Fachwissen bleibt ein Bruchteil des Marktes für SQL-Kenntnisse.
SQL und NoSQL zusammenführen
Wir können davon ausgehen, dass einige der Unterschiede zwischen SQL- und NoSQL-Systemen im Laufe der Zeit verschwinden werden. Bereits jetzt akzeptieren viele SQL-Datenbanken JSON-Dokumente als nativen Datentyp und können Abfragen auf diese Daten durchführen.
Einige verfügen sogar über systemeigene Möglichkeiten, JSON-Daten Beschränkungen aufzuerlegen, so dass sie mit der gleichen Strenge behandelt werden wie herkömmliche Zeilen- und Spaltendaten.
NoSQL-Datenbanken fügen aber nicht nur SQL-ähnliche Abfragesprachen hinzu, sondern auch andere Merkmale herkömmlicher SQL-Datenbanken, wie z. B. die ACID-Eigenschaften von MongoDB.
Ein wahrscheinlicher Weg ist, dass künftige Datenbankgenerationen sowie künftige Versionen aktueller Datenbanksysteme die Paradigmen überbrücken und sowohl SQL- als auch NoSQL-Funktionen anbieten werden, was dazu beiträgt, dass die Datenbankwelt weniger fragmentiert ist.
Microsofts Azure Cosmos DB beispielsweise verwendet eine Reihe von Primitiva unter der Haube, um das Verhalten beider Arten von Systemen austauschbar zu reproduzieren. Google Cloud Spanner kombiniert SQL und starke Konsistenz mit der horizontalen Skalierbarkeit von NoSQL-Systemen.
Dennoch werden reine SQL- und NoSQL-Systeme noch viele Jahre lang ihren Platz haben. In Szenarien, in denen Designflexibilität, horizontale Skalierbarkeit und Hochverfügbarkeit wichtiger sind als starke Lesekonsistenz und andere Schutzmechanismen, die bei SQL-Datenbanken üblich sind, sollten Sie auf NoSQL zurückgreifen. Für viele Anwendungen kann es sich durchaus lohnen, diese Schutzmechanismen gegen die Vorteile von NoSQL einzutauschen.
*Serdar Yegulalp ist ein leitender Autor bei InfoWorld, der sich auf maschinelles Lernen, Containerisierung, Devops, das Python-Ökosystem und regelmäßige Reviews konzentriert.
Be the first to comment