Da ich in dieser Woche einen Vortrag darüber gehört habe, schreibe ich mal einen kurzen Beitrag dazu.
Sicher haben viele schon von „NoSQL“-Datenbanken gehört.
In den guten alten Zeiten kam so etwa alle 10 Jahre ein neues Datenbank-Paradigma auf, bis die relationalen Datenbanken kamen. So etwa Mitte der 90er Jahre wäre nach diesem 10-Jahres-Rhytmus wieder etwas neues fällig gewesen und die objektorientierten Datenbanken waren ein recht offensichtlicher Kandidat. Letztlich blieben sie aber Nischenprodukte, ebenso wie einige andere Ideen, wie XML-Datenbanken.
Die relationalen Datenbanken und vor allem SQL waren zu gut oder zu gut etabliert und zu gut verstanden und statt objektorientierte Datenbanken einzusetzen verliebte man sich in verschiedene Technologien, um objektorientierte Software mit relationalen Datenbanken zu verbinden, zum Beispiel OR-Mapping wie Hibernate, JDO oder Eclipselink in der Java-Welt oder ActiveRecord in der Ruby-Welt. Diese Technologien, ihre Vor- und Nachteile und auch die grundsätzlichen konzeptionellen Fragen dazu sind sicher noch Stoff für viele Blog-Artikel in der Zukunft…
Letztlich scheint jetzt das Thema „NoSQL“-Datenbanken neben den weiterhin starken relationalen Datenbanken seinen Platz einzunehmen. Dabei steht „NoSQL“ angeblich für „not only SQL“. Letztlich sind es aber zwei Aspekte, an denen man schraubt. Die gängigen SQL-Datenbanken sind relational (oder zumindest unterstützen sie das relationale Modell) und transaktional. Das Thema Transaktionen ist sicher auch interessant genug für viele Blog-Beiträge und man kann problemlos allein darüber ein Buch von mehreren 100 Seiten schreiben, das nicht langweilig wird, wenn man sich mit verteilten Transaktionen und der Implementierung dieser Konzepte und der theoretischen und praktischen Zuverlässigkeit solcher Implementierungen gemessen an den Ansprüchen beschäftigt. Es gibt gegen Einwurf vieler großer Münzen mehrere gute Monographien dazu im Buchhandel.
Eine wichtige Motivation für die Entwicklung und Verbreitung der noSQL-Datenbanken war „Big Data“, also die Verarbeitung riesiger Datenmengen, die den Rahmen traditioneller relationaler transaktionaler Datenbanken wie Oracle, DB2, PostgreQL u.s.w. sprengen. Solche Fragestellungen findet man unter anderem bei Webapplikationen wie sie Google oder Facebook betreiben. Es gibt aber auch Fragestellungen mit Datenmengen, die noch gut für relationale Datenbanken handhabbar sind, die sich aber von ihrer Struktur nicht so gut für das relationale Modell eignen.
Nun muß eine SQL-Datenbank nicht transaktional sein. Zum Beispiel war es mySQL lange Zeit nicht und heute ist die für Data-Warhouses spezialisierte Datenbank Teradata unterstützt Transaktionen nur eingeschränkt.
NoSQL-Datenbanken weichen aber das relationale Prinzip auf und je nach Einzelfall eventuell außerdem die Transaktionalität. Es gibt verschiedene Arten von NoSQL-Datenbanken, zum Beispiel Key-Value-Stores wie Riak oder dokumentenorientierte Datenbanken wie MongoDB oder CouchDB, die sich eignen, wenn man eine gewisse Struktur der Daten kennt, aber die einzelnen Datensätze doch von Zeile zu Zeile (oder hier von Dokument zu Dokument) zu stark varieren oder zu stark strukturiert sind, um gut in eine normalisierte relationale Datenbank zu passen.
Graphendatenbanken speichern Daten in der Struktur eines Graphen. Man hat also Knoten mit gewissen Eigenschaften (Daten) und Verbindungen zwischen diesen Knoten mit gewissen Eigenschaften. Ein Beispiel ist eine IT-Landschaft, in der man Hardware, virtuelle Server, Basis-Software, Applikationen, Businessprozesse u.s.w. hat, zwischen denen verschiedene Arten von Abhängigkeiten bestehen können. Das war das Beispiel, das in dem Vortrag gebracht wurde. Das läßt sich eigentlich gut im relationalen Modell abbilden, ist aber in der Praxis sehr schwerfällig zu gebrauchen, weil die Queries um einen Teilgraphen zu laden, sehr schwerfällig sind und weil man letztlich durch fortgesetztes Verfolgen von Abhängigkeiten sehr schnell einen großen Teil des Systems im Speicher hat. Mit einer Graphendatenbank kann man diese Struktur allerdings ganz natürlich und direkt modellieren. neo4j ist zum Beispiel eine solche Graphendatenbank, die als Opensource-Software verfügbar ist. Sie enthält auch praktischerweise gleich noch Implementierungen einiger gängiger Graphenalgorithmen, die man direkt auf dem gespeicherten Graphen operieren lassen kann. So lassen sich gewisse Aufgabenstellungen sehr elegant lösen, die mit einer relationalen Datenbank zwar theoretisch korrekt, aber nicht praxistauglich umsetzbar sind, sobald der zu speichernde Graph eine gewisse Größe und Komplexität erreicht. Zur Aufweichung des Transaktionsprinzip ist noch zu sagen, daß neo4j transaktional ist.
