Früher waren relationale Datenbanken das Maß der Dinge, doch in den vergangenen 15 Jahren haben sich zahlreiche andere Datenbanktypen etabliert. Wie unterscheiden sie sich, und spielen relationale Datenbanken heutzutage überhaupt noch eine Rolle?

Der mit Abstand einfachste Datenbanktyp ist die Key-Value-Datenbank. Solche Datenbanken funktionieren quasi wie ein Dictionary, indem sie zu einem gegebenen Schlüssel einen passenden Wert speichern. Diese Werte können durchaus unterschiedliche Datentypen haben, allen gemein ist aber, dass die Indexierung nur über den Schlüssel und nicht über den Wert erfolgt.

Key-Value-Datenbanken eignen sich daher zum Verwalten von Daten, die einer ID zugeordnet werden und auf die auch ausschließlich anhand der ID zugegriffen wird. Dazu zählen beispielsweise das Caching von Daten und das Ablegen von Sessions für eine Webanwendung.

Ein typisches Produkt dieser Art ist Redis, was als Akronym für "Remote Dictionary Server" steht. Redis verwaltet Key-Value-Paare primär in Listen, kennt aber auch andere Strukturen, unter anderem Mengen und sortierte Mengen. Seit Version 5 werden auch Streams, ähnlich zu Kafka, unterstützt. Aufgrund dieser verschiedenen Datenstrukturen eignet sich Redis auch hervorragend für andere Anwendungsfälle wie Pub/Sub und Queues.

Generell können Key-Value-Datenbankeneinfach horizontal skaliert werden, da nur die ID als Diskriminator dient und die Daten auf dem Weg einfach geshardet werden können. Der größte Haken ist die fehlende Standardisierung, die sich aufgrund der Einfachheit aber problemlos in der Anwendung nachbilden lässt.

Column- und Wide-Column-Datenbanken

Geringfügig komplexer sind die Wide-Column-Datenbanken, die ebenfalls zu einem Schlüssel passende Daten speichern, allerdings handelt es sich bei diesen Daten um komplexere Werte, die aus mehreren Feldern beziehungsweise Spalten bestehen. Im Prinzip ist eine Wide-Column-Datenbank, wenn man so will, nichts anderes als eine zweidimensionale Key-Value-Datenbank.

Ganz deutlich unterscheiden muss man davon die Column-Datenbanken, die eher den klassischen relationalen Datenbanken entsprechen, im Gegensatz zu diesen aber spalten- und nicht zeilenorientiert arbeiten. Das ist besonders dann praktisch, wenn primär einzelne Spalten über eine große Anzahl von Datensätzen verarbeitet werden.

Häufig trifft man spaltenorientierte Datenbanken daher im OLAP-Bereich an, zeilenorientierte eher im OLTP-Bereich, wobei die Grenzen hier fließend sind. Column-Datenbanken sind daher ein relativ ausgefallener Spezialfall, für den es zwar Anwendungsgebiete gibt, die überwiegende Mehrheit der Datenbanken arbeitet aber zeilenorientiert.

Dokumentenorientierte Datenbanken

Key-Value- und Wide-Column-Datenbanken ist gemein, dass lediglich der Schlüssel zum Indexieren genutzt wird. Die Werte, unabhängig ob einfach oder zusammengesetzt, sind auf dem Weg daher nicht beziehungsweise nicht effizient durchsuchbar. Was aber, wenn man das braucht, um beispielsweise komplexere Abfragen ausführen zu können?

In diesem Fall kann man auf sogenannte dokumentenorientierte Datenbanken zurückgreifen. Unter einem Dokument versteht man hier in der Regel ein JSON-Objekt, theoretisch kann es sich aber auch um andere Datenformate handeln. Die Objekte werden dabei ohne Beziehungen zueinander gespeichert, sondern werden als in sich geschlossene Einheiten betrachtet. Relationen lassen sich theoretisch über IDs abbilden, haben für die Datenbank aber keine Relevanz, sondern müssen in der Regel auf Anwendungsebene aufgelöst werden.

Einer der bekanntesten Vertreter dieser Art von Datenbanken ist MongoDB, was sich ebenfalls wieder gut horizontal skalieren lässt, wobei auch hier Sharding wieder eine große Rolle spielt. Da die Dokumente in sich geschlossene Einheiten sind, werden die ACID-Kriterien häufig nicht unterstützt, wobei es Ausnahmen gibt. So unterstützt auch MongoDB seit der Version 4.0 ACID-konforme Transaktionen, die mehrere Dokumente umfassen.

Graph-Datenbanken

Wenn Relationen eine große Rolle spielen, kann es hilfreich sein, eine Graph-Datenbank einzusetzen. In einer solchen Datenbank werden nicht nur die Entitäten, sondern auch die Relationen explizit modelliert, wodurch als Datenmodell ein Graph entsteht. Das bedeutet, dass sich unterschiedliche Arten von Beziehungen abbilden und vor allem auch abfragen lassen.

Ein typischer Anwendungsfall für Graphdatenbanken ist das Abbilden menschlicher Beziehungen beziehungsweise Interaktionen, wo sich anschließend über den Graph ermitteln lässt, wer wen über wen kennt oder wer mit wem Kontakt haben könnte. Prinzipiell sind aber auch andere Abfragen denkbar, wobei hier vor allem Themen aus der Graphtheorie relevant sind, beispielsweise das Ermitteln von kürzesten Wegen, Cliquen oder Hotspots.

Ein bekannter Vertreter dieser Art von Datenbanken ist ArangoDB, das als 3-in-1-System fungiert. ArangoDB lässt sich nämlich als Key-Value-, als dokumentenorientierte und auch als Graph-Datenbank einsetzen. Dabei ist die Datenbanken in weiten Teilen sogar kompatibel zu MongoDB, weshalb sich ArangoDB ein bisschen anfühlt wie eine um Graph-Fähigkeiten erweiterte MongoDB.

Relationale Datenbanken

Alle genannten Datenbanktypen, von der Key-Value- bis hin zur Graphdatenbank, haben ihre Berechtigung und adressieren jeweils unterschiedliche Anwendungsfälle. Was sie aber alle gemeinsam haben, ist, dass sie in der Regel schemalos arbeiten und daher für unstrukturierte Daten geeignet sind. Das ist in vielen Fällen ein Vorteil, trotzdem bietet sich gelegentlich auch der Einsatz eines festen Schemas an.

Dann sind häufig klassische relationale und SQL-basierte Datenbanken das Mittel der Wahl. Die Trennlinie verläuft dabei übrigens gar nicht so scharf, wie man das zunächst annehmen könnte, denn gerade die relationalen Datenbanken haben in den vergangenen Jahren aufgeholt beziehungsweise sind um Funktionen für das Verwalten unstrukturierter Daten erweitert worden. So kennen beispielsweise PostgreSQL und MySQL spezielle Datentypen für JSON.

Doch auch in anderer Hinsicht sind relationale Datenbanken häufig weitaus flexibler, als man das zunächst annehmen könnte. Der Microsoft SQL Server kennt zum Beispiel den Index-Typ "Columnstore", mit dem sich eine Tabelle nicht zeilen-, sondern spaltenorientiert verwalten lässt, ähnlich einer Column-Datenbank.

Fazit

Insgesamt sind relationale Datenbanken also nicht per se besser oder schlechter als NoSQL-Datenbanken, sondern es gilt, wie so oft, dass man das richtige Werkzeug für den passenden Anwendungsfall auswählen sollte. Wenn das im konkreten Fall eine NoSQL-Datenbank ist, ist das in Ordnung. Es ist aber ebenfalls in Ordnung, wenn es eine relationale Datenbank ist.

Beide Welten zu kennen ist aber so oder so hilfreich, denn ein Blick über den Tellerrand erweitert den Horizont und befähigt Entwicklerinnen und Entwickler, bessere und vor allem fundiertere Entscheidungen zu treffen. ()