Es ist eine grundlegende Entscheidung, wenn es darum geht, Applikationen zu entwickeln: Soll für die Datenspeicherung eine SQL- oder eine NoSQL-Datenbank zum Einsatz kommen?

Herkömmliche - also relationale - Datenbanken, die die Structured Query Language (SQL) für Abfragen verwenden, haben sich über Jahrzehnte bewährt, sind praxiserprobt und für zuverlässige Transaktionen und Ad-Hoc-Abfragen konzipiert - die Grundpfeiler von Business-Applikationen. Sie sind jedoch auch mit Limitationen behaftet, beispielsweise starren Schemata, wodurch sie sich für andere Anwendungsarten weniger gut eignen. Als Antwort auf diese Einschränkungen sind NoSQL-Datenbanken entstanden.

NoSQL - Definition

NoSQL-Systeme speichern und verwalten Daten auf eine Art und Weise, die Entwicklern eine hohe Betriebsgeschwindigkeit und große Flexibilität ermöglicht. Viele dieser Datenbanken wurden von Unternehmen wie Google, Amazon, Yahoo und Facebook entwickelt - auf der Suche nach besseren Möglichkeiten, Inhalte zu speichern oder Daten für umfangreiche Websites zu verarbeiten. Im Gegensatz zu SQL-Datenbanken lassen sich viele NoSQL-Datenbanken horizontal über Hunderte oder Tausende von Servern skalieren.

Die Vorteile von NoSQL haben jedoch ihren Preis: NoSQL-Systeme geben Geschwindigkeit und Skalierbarkeit den Vorzug vor den sogenannten ACID-Eigenschaften (dazu später mehr), die hinter den zuverlässigen Transaktionen von SQL-Datenbanken stehen. Auch die Grundprinzipien, nach denen die Datenarbeit in NoSQL-Systemen funktioniert, sind - verglichen mit dem über Jahrzehnte institutionalisierten Wissen rund um SQL - relativ neu.

SQL- und NoSQL-Datenbanken gehen unterschiedliche Kompromisse ein. Während sie im Kontext eines bestimmten Projekts miteinander konkurrieren können - etwa bei der Frage, welche für diese oder jene Anwendung zu wählen ist -, ergänzen sie sich im Gesamtbild: SQL und NoSQL eignen sich für unterschiedliche Anwendungsfälle. Bei der Entscheidung geht es deswegen im Kern um die Frage, welche Datenbank für den jeweiligen Task am besten geeignet ist.

NoSQL- vs. SQL-Datenbanken

Der grundlegende Unterschied zwischen SQL und NoSQL ist nicht sonderlich kompliziert. Sie beruhen auf einer jeweils unterschiedlichen Philosophie, wenn es darum geht, Daten zu speichern und abzurufen.

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. Das hat zur Folge, dass die in dieser Spalte gespeicherten Daten einen hohen Normierungsgrad 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.

Im Fall von NoSQL können die Daten Schema-unabhä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, um Daten zu speichern, die zu vier gängigen Typen von NoSQL-Datenbanken führen:

• Dokumentdatenbanken (wie MongoDB): Eingegebene Daten werden in Form von schemafreien JSON-Strukturen oder "Dokumenten" gespeichert, wobei es sich bei den Daten um Ganzzahlen, Zeichenketten oder Freiformtext handeln kann. Es besteht keine Notwendigkeit, festzulegen, ob und welche Felder ein JSON-Dokument enthalten soll.

• Key-Value-Speicher (wie Redis): Auf Freiformwerte, von einfachen Ganzzahlen oder Zeichenketten bis hin zu komplexen JSON-Dokumenten, wird in der Datenbank mit Hilfe von Schlüsseln, wie zum Beispiel Zeichenketten, zugegriffen.

• Wide-Column-Speicher (wie 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) kann je nach Bedarf für Abfragen oder Datenansichten gruppiert oder aggregiert werden.

• Graph-Datenbanken (wie Neo4j): Die Daten werden als Netzwerk oder Graph von Entitäten und ihren Beziehungen dargestellt, wobei jeder Knoten im Graph ein Freiform-Datenstück ist.

Schemalose Datenspeicherung ist in folgenden Szenarien nützlich:

• Sie wollen schnellen Datenzugriff und legen mehr Wert auf Geschwindigkeit und einfachen Zugriff als auf zuverlässige Transaktionen oder Konsistenz.

• Sie speichern große Datenmengen und wollen sich nicht auf ein Schema festlegen, da eine spätere Änderung mühsam sein und viel Zeit beanspruchen könnte.

• Sie nehmen unstrukturierte Daten aus einer oder mehreren Quellen auf und möchten diese in ihrer ursprünglichen Form behalten, um maximale Flexibilität zu gewährleisten.

• Sie möchten Daten in einer hierarchischen Struktur speichern - dabei sollen die Hierarchien aber durch die Daten selbst und nicht durch ein externes Schema beschrieben werden. NoSQL ermöglicht selbstreferenzielle Daten, was mit SQL-Datenbanken nicht so einfach zu emulieren ist.

NoSQL-Datenbanken abfragen

Die von relationalen Datenbanken verwendete Structured Query Language bietet eine einheitliche Methode zur Kommunikation mit dem Server, wenn es darum geht, Daten abzulegen und wieder aufzurufen. Die SQL-Syntax ist in hohem Maße standardisiert, so dass die einzelnen Datenbanken bestimmte Vorgänge zwar unterschiedlich handhaben (etwa Window-Funktionen), die Grundlagen jedoch gleichbleiben.

Im Gegensatz dazu hat jede NoSQL-Datenbank ihre eigene Syntax, um Daten abzufragen und zu managen. CouchDB zum Beispiel verwendet JSON-Requests, die über HTTP gesendet werden. MongoDB sendet JSON-Objekte über ein binäres Protokoll, per Kommandozeilen-Interface oder Sprachbibliothek.

Einige NoSQL-Produkte verwenden eine SQL-ähnliche Syntax für die Arbeit mit Daten, allerdings nur in begrenztem Umfang. Apache Cassandra verfügt beispielsweise über eine eigene SQL-ähnliche Sprache, die Cassandra Query Language oder CQL. Dabei kommt die ein oder andere Syntax direkt aus dem SQL-Spielbuch, beispielsweise die Keywords SELECT oder INSERT. Es gibt jedoch keine native Möglichkeit, einen JOIN oder eine Subquery in Cassandra auszuführen, weswegen die entsprechenden Schlüsselwörter in CQL nicht existieren.

Shared-Nothing-Architektur

Für NoSQL-Systeme ist eine "Shared-Nothing"-Architektur typisch. Dabei arbeitet jeder Serverknoten im Cluster unabhängig von den anderen Knoten. Um Daten an einen Client zurückzugeben, muss das System nicht die Zustimmung der anderen Knoten einholen. Weil sie von dem Knoten zurückgegeben werden können, der am nächsten liegt, sind Abfragen in dieser Architektur besonders schnell.

Weitere Vorteile des Shared-Nothing-Systems manifestieren sich in seiner Ausfallsicherheit und Skalierbarkeit. Ein Cluster zu skalieren ist ebenso simpel wie einen neuen Knoten im Cluster aufzusetzen und darauf zu warten, dass er sich mit den anderen synchronisiert. Fällt ein NoSQL-Knoten aus, laufen die anderen Server im Cluster weiter. Alle Daten bleiben verfügbar, auch wenn weniger Knoten zur Verfügung stehen, um Anfragen zu bearbeiten.

Wichtig ist dabei, dass das Shared-Nothing-Design nicht nur für NoSQL-Datenbanken relevant ist: Viele konventionelle SQL-Systeme können nach diesem Designprinzip aufgebaut sein (etwa MySQL) - auch wenn das in der Regel bedeutet, dass die Konsistenz des Clusters zugunsten der Performance geopfert wird.

NoSQL - Einschränkungen

Wenn NoSQL so viel Freiheit und Flexibilität bietet, warum sollte man dann nicht ganz auf SQL verzichten? Die einfache Antwort: Viele Anwendungen erfordern nach wie vor die Konsistenz, die Stabilität und den Schutz von SQL-Datenbanken. In diesen Fällen können sich einige NoSQL-Vorteile in Nachteile verwandeln. Zudem lassen NoSQL-Datenbanken bestimmte Funktionen vermissen, die im SQL-Bereich als selbstverständlich vorausgesetzt werden.

Kein Schema

Selbst wenn Sie Daten in freier Form erfassen, müssen Sie den Daten fast immer Beschränkungen auferlegen, um sie nutzbar zu machen. Bei NoSQL bedeutet das, dass die Verantwortung von der Datenbank auf den Anwendungsentwickler übergeht. Der Entwickler könnte zum Beispiel durch ein Object-Relational-Mapping-System (ORM) eine Struktur vorgeben. Ein Schema, das in den Daten selbst "lebt", wird von NoSQL-Datenbanken in der Regel nicht unterstützt.

Einige NoSQL-Lösungen bieten optionale Typisierungs- und Validierungsmechanismen für Daten. Apache Cassandra verfügt beispielsweise über eine Reihe nativer Datentypen, die an die für SQL typischen erinnern.

Eventuelle Konsistenz

NoSQL-Systeme bieten die Möglichkeit, Konsistenz gegen eine optimierte Verfügbarkeit und Performance "einzutauschen". Herkömmliche Datenbanken stellen indes sicher, dass Operationen folgende Merkmale aufweisen:

• 'atomic' (alle Teile einer Transaktion sind erfolgreich oder keiner)

• konsistent (alle Benutzer haben die gleiche Sicht auf die Daten)

• isoliert (Transaktionen konkurrieren nicht)

• dauerhaft (einmal abgeschlossen, überstehen sie einen Serverausfall)

Diese vier Eigenschaften bezeichnet man zusammengenommen als ACID. Sie können in NoSQL-Systemen anders gehandhabt werden: Statt auf eine starke Konsistenz im gesamten Cluster abzustellen (was zwangsläufig zu Verzögerungen bei der Beantwortung von Requests führen würde), können Sie sich für eine eventuelle Konsistenz entscheiden. Das ermöglicht, Anfragen zu bedienen, ohne darauf zu warten, dass die letzten Schreibvorgänge auf andere Knoten im Cluster kopiert werden. Die ins Cluster eingefügten Daten sind schließlich überall verfügbar, aber Sie können nicht genau sagen, wann.

Einige NoSQL-Systeme bieten mehrere Kompromisse zwischen Konsistenz und Geschwindigkeit, die Möglichkeiten variieren je nach Produkt: Im Fall von Microsofts Azure Cosmos DB können Sie zum Beispiel eine Konsistenzstufe pro Request auswählen, passend zum jeweiligen Use Case. Die Transaktionssemantik, die in einem SQL-System garantiert, dass alle Schritte einer Transaktion (etwa der Anschluss eines Verkaufs oder die Reduzierung des Lagerbestands) entweder abgeschlossen oder zurückgenommen werden, ist auch in einigen NoSQL-Datenbanken wie MongoDB verfügbar.

NoSQL-Lock-in

Die meisten NoSQL-Systeme sind konzeptionell ähnlich, werden aber unterschiedlich implementiert. Jedes System verwendet dabei seine eigenen Prinzipien und Mechanismen, um Daten abzufragen und zu verwalten. Das resultiert in einem potenziell hohen Maß an Kopplung zwischen Anwendungslogik und Datenbank. Das kann sich als Hürde erweisen, wenn Sie das System später einmal wechseln möchten.

Eine Migration von MongoDB zu CouchDB (oder umgekehrt) erfordert deshalb mehr, als nur Daten zu migrieren: Auch die Unterschiede in Sachen Datenzugriff und programmatische Schemata müssen dabei berücksichtigt werden. Anders ausgedrückt: Sie müssen die Teile Ihrer Anwendung, die auf die Datenbank zugreifen, neu schreiben.

NoSQL-Skillgap

Das fehlende Know-how ist ein weiterer Nachteil von NoSQL-Datenbanken: Während kein Mangel an SQL-Experten herrscht, ist bei NoSQL das Gegenteil der Fall. Der Stellenmarkt ist laut dem Job-Portal Indeed im Jahr 2022 immer noch stark SQL-lastig.

SQL und NoSQL verschmelzen

Es ist davon auszugehen, dass die Grenzen zwischen SQL- und NoSQL-Datenbanken im Laufe der Zeit verschwimmen werden. Schon jetzt akzeptieren viele SQL-Datenbanken JSON-Dokumente als nativen Datentyp und können auf dieser Grundlage Abfragen durchführen. Einige verfügen sogar über systemeigene Möglichkeiten, JSON-Daten Beschränkungen aufzuerlegen, so dass sie ebenso strikt behandelt werden wie herkömmliche Zeilen- und Spaltendaten. Auf der anderen Seite fügen NoSQL-Datenbanken nicht nur SQL-ähnliche Abfragesprachen hinzu, sondern auch andere Merkmale, wie die ACID-Eigenschaften von MongoDB.

Künftige Datenbank-Generationen sowie kommende Versionen aktueller Datenbanksysteme könnten die Paradigmen überbrücken und sowohl SQL- als auch NoSQL-Funktionen anbieten. Das wäre einer Defragmentierung der Datenbankwelt zuträglich. Erste Anzeichen sind bereits zu erkennen: So versucht Microsoft mit seiner Azure Cosmos DB das Verhalten beider Systemtypen austauschbar zu reproduzieren. Google Cloud Spanner kombiniert hingegen SQL und starke Konsistenz mit der horizontalen Skalierbarkeit von NoSQL.

Nichtsdestotrotz werden reine SQL- und NoSQL-Datenbanken noch über viele Jahre ihre Berechtigung haben. In Szenarien, in denen Designflexibilität, horizontale Skalierbarkeit und Hochverfügbarkeit wichtiger sind als starke Lesekonsistenz und andere bei SQL-Systemen übliche Schutzmechanismen, sollten Sie auf NoSQL zurückgreifen. Das kann sich für viele Applikationen lohnen.

Dieser Beitrag basiert auf einem Artikel unserer US-Schwesterpublikation Infoworld.