Relationale Datenbanken (RDB) gibt es schon lange. Das relationale Datenbankmodell wurde 1970 von Edgar F. Codd vorgestellt. Viele Entwickler kennen sich gut mit SQL aus und es wurde bislang für praktisch alle Persistenz Probleme eine relationale Datenbank verwendet. Diese RDB machen auch einen guten Job: Terabyte große Datenbestände sind kein Problem, Zuverlässigkeit ist auch kein Problem und es gibt die passenden Treiber für alle (relevanten) Programmiersprachen. Als das Internet in Fahrt kam, brauchten die Suchmaschinenbetreiber eine Datenbank, um die Suchanfragen schnell zu beantworten. Die Anforderungen hier sind aber sehr speziell (flaches Datenmodell, extrem große Datenbestände, Skalierung, massive Benutzerzahlen). RDB können dieses spezielle Szenario nicht wirklich gut bedienen. Damals wurden hierfür genau passende Datenbanken erfunden. Diese neuen Datenbanken werden als NoSQL (Not only SQL) bezeichnet, da sie nicht dem relationalen Modell folgen.

Den Begriff NoSQL gibt es seit 1998 wobei er damals für “no SQL” benutzt wurde. Erst seit 2009 wird der Begriff NoSQL für “Not only SQL” benutzt.

Unterschied RDB und NoSQL

RDB legen ihre Daten in Tabellen ab, wobei es Beziehungen zwischen den Tabellen geben kann. Hierdurch wird ein weiteres Merkmal dieser Datenbanken ermöglicht: Normalisierung. Damit werden Redundanzen in den Daten vermieden womit letztlich die Wartung vereinfacht wird. Edgar F. Codd hat hierfür 4 Normalformen vorgeschlagen, wovon in der Praxis aber meistens nur 3 umgesetzt werden. Einige RDB bieten von Haus aus Replikation an. Nur wenige bieten eine Clusterfähigkeit an. Üblicherweise wird eine RDB vertikal über die Hardware (CPUs, Kerne und RAM) skaliert, da der Datenbankserver üblicherweise nur auf einer Maschine läuft.

NoSQL Datenbanken haben kein Schema und können sehr gut mit unstrukturierten Daten umgehen. Die meisten dieser Datenbanken arbeiten nativ mit JSON bzw. BSON (Binary JSON). Hier holen die RDB auf, da mittlerweile auch viele nativ mit JSON umgehen können. Da das Thema Skalierung einer der Ursachen ist, warum diese Kategorie von Datenbanken erfunden wurde, bieten fast alle NoSQL DBs von Haus aus eine horizontale Skalierung (Sharding). Dabei wird der Datenbestand auf verschiedene Maschinen verteilt und es gibt üblicherweise einen Proxy, der die Suchanfragen auf die Maschinen verteilt und die Ergebnisse wieder zusammenfasst. Eine Ausfallsicherheit durch Replikation wird auch bei fast allen NoSQL Datenbanken mitgeliefert.

Unterschiedliche Typen von NoSQL

Im Prinzip könnte man alle Datenbanken unter dem Stichwort NoSQL zusammenfassen, die nicht dem relationalen Prinzip genügen. Im Laufe der Zeit haben sich aber ein paar Unterkategorien ergeben, die im Folgenden aufgelistet werden.

Key/Value

Bei diesem Typ handelt es sich im Prinzip um eine persistente HashMap. Über den Key erreicht man das zugehörige Datenobjekt. Diese NoSQL Datenbanken werden häufig für Cache Systeme und bei den Suchmaschinenbetreibern genutzt.
Beispiele: Redis, memcached, DynamoDB

Document

Dokumenten Datenbanken haben in letzter Zeit viel Aufmerksamkeit erreicht, da sie viele Eigenschaften von RDB bieten. Es gibt zwar keine Tabellen aber dafür z.B. Collections (MongoDB), die Tabellen recht ähnlich sind. Allerdings haben diese Collections keine feste Struktur. Es kann also jeder Datensatz eine komplett andere Struktur als der Nächste haben. Für das Wiederfinden solcher Daten ist dies allerdings suboptimal. Eine gewisse Struktur sollte schon vorhanden sein. Eine Normalisierung lässt sich über die Verwendung von mehreren Collections erreichen. Dadurch geht allerdings der atomare Zugriff verloren.
Beispiele: MongoDB, Couchbase

Graph

Graphen Datenbanken kommen dann zur Anwendung, wenn die Daten ein komplexes Beziehungsgeflecht aufspannen. Passende Anwendungsfälle wären soziale Netzwerke wie Facebook, Xing und LinkedIn.
Beispiel: neo4j

Objekt

Eine Objektdatenbank stellt die Reinform für das native Speichern von Objekten dar. Bei RDB wird für diese Art der Persistierung ein Objekt Relationaler Mapper (ORM) wie z.B. Hibernate benötigt. Die Aufgaben die ein ORM verrichtet, sind bei einer Objektdatenbank in die Datenbank verlagert worden.
Beispiel: db4o

Spalten

Relationale Datenbanken arbeiten zeilenorientiert. Bei Data Warehouse Anwendungen (Online Analytical Processing - OLAP) ist es von Vorteil wenn die Datenbank spaltenorientiert arbeitet, da hier häufig Aggregate über sehr große Spalten gebildet werden müssen. Bei solchen Abfragen hat eine spaltenorientierte Datenbank Geschwindigkeitsvorteile.
Beispiele: Cassandra, Amazon SimpleDB

Multi Model

Multi Model NoSQL Datenbanken beherrschen mehr als 1 Paradigma. OrientDB kann z.B. mit Dokumenten und mit Graphen umgehen. ArangoDB bietet zusätzlich noch den Einsatz als Key/Value Store.
Beispiele: ArangoDB, OrientDB

Konsistenz bei NoSQL

RDB bieten ACID (Atomicity, Consistency, Isolation, Durability). Wenn ein Datenbank Client einen Wert geschrieben hat, so kann nach dem Ende der Transaktion davon ausgegangen werden, dass dieser Wert von allen anderen Clients gelesen werden kann.
Bei NoSQL Datenbanken, die häufig mit Replication Sets und Sharding arbeiten, wird dieses Konsistenzmodell aufgrund von Skalierbarkeit/Geschwindigkeit meistens aufgeweicht. So kann es z.B. vorkommen, dass der geschriebene Wert erst auf einer Maschine im Cluster wirklich geschrieben wurde und die beiden anderen Maschinen (bei einem 3er Replica Set) aufgrund von Netzwerk Latenzen dies erst etwas später tun. Sind alle 3 Maschinen für Lese Operationen berechtigt, so kann ein Client gerade die Maschine erwischen, wo der Wert noch nicht geschrieben wurde. Dieses Verhalten nennt sich eventual consistency. Letztendlich sind die Daten auch bei NoSQL Datenbanken konsistent, nur nicht sofort. Dies ist der Preis für die verteilte Datenhaltung. Bei MongoDB z.B. können die Parameter, die das Konsistenz Verhalten definieren, sehr fein eingestellt werden.

Transaktionen

RDB bieten Transaktionen, um mehrere zusammenhängende Lese-/Schreiboperationen entweder ganz oder gar nicht auszuführen. Es wird also immer sichergestellt, dass entweder alle Operationen erfolgreich waren (Commit) oder nichts verändert wurde (Rollback).
Bei NoSQL Datenbanken braucht es keine Transaktionen über mehrere Operationen, da ein Dokument alle Daten enthält die logisch zusammengehören und ein Dokument wird entweder vollständig geschrieben oder nicht. Auch hier nähern sich die beiden Welten an: MongoDB unterstützt z.B. ab v4.0 multi-document transactions.

Fazit

NoSQL Datenbanken sind für mich die Spezialisten unter den Persistenzlösungen. Für fast alle Spezialfälle gibt es auch eine passende NoSQL Datenbank. RDB hingegen sind die „Allzweckwaffe“ für Persistierung, wenn es keine Anforderungen gibt die dagegen sprechen. Es hängt also sehr vom Anwendungsfall der Anwendung ab, ob, und wenn ja, welche NoSQL Datenbank zum Einsatz kommen sollte. RDB sind meiner Meinung nach noch lange nicht als aussterbende Spezies zu betrachten. Für sehr viele Anwendungen (nicht nur Geschäftsanwendungen) sind RDB noch immer eine gute Wahl. Nicht zu vergessen ist hierbei, dass viele Entwickler ein profundes SQL Wissen haben und die große Vielzahl von vorhandenen NoSQL Datenbanken es schwieriger macht geeignete Spezialisten zu finden.

Für mich sind NoSQL Datenbanken im Mainstream angekommen und bei Neuentwicklungen sollte man sie unbedingt in Betracht ziehen.

Andreas Lüdtke