Graphendatenbanken

Graphendatenbanken gehören zu den am schnellsten wachsenden Bereichen der NoSQL-Welt. Dies ist nicht weiter verwunderlich, da ein bedeutender Teil des Web 2.0 eine Graphenstruktur hat. Nicht nur das Web selbst ist ein Graph, auch viele Anwendungen im Web benötigen graphenähnliche Daten und passende Algorithmen. Das betrifft zum Beispiel Social-Web-Dienste (wer ist wessen Freund, alias Facebook oder Xing) das Semantic Web, GIS (Geoinformationssysteme) und Location Based Services.

Gerade der letzte Bereich spielt eine große Rolle für Graphendatenbanken. Die Anforderungen an Mehrschichten-Graphenabfragen werden immer größer. So müssen beispielsweise alle Ebenen für Landkarten, Freunde und Points of Interest miteinander verknüpft werden, wenn mobile Anwender mit Smartphones entsprechende Anfragen stellen.

Interessant ist dabei, dass die Graphentheorie (zum Beispiel mit Dijkstra 1959) schon relativ alt ist. Um so erstaunlicher ist es, dass es allgemeine und leistungsfähige Graphendatenbanken noch nicht allzu lange gibt. So hat sich erst in den letzten Jahren das Modell des Property-Graphen ganz vorne positioniert. Bei einem Property-Graphen [12] können sowohl Kanten als auch Knoten mit beliebigen Attributen (ähnlich eines Objektes) versehen werden. Dieses mächtige Datenmodell erlaubt auch die einfache Abbildung von komplexen gerichteten und gewichteten Graphen.

Während man vor fünf oder zehn Jahren noch lange nach entsprechenden Datenbanken suchen musste und oft nur wenige Speziallösungen gefunden hat, gibt es seit einigen Jahren gut ein Dutzend dieser Datenbanken, die an dieser Stelle aufgelistet sein sollen: Neo4j, sones, InfoGrid, DEX, HyperGraphDB, InfiniteGraph, OrientDB, FlockDB, Google Pregel, Apache Hama / Hamburg, VertexDB und Filament. Viele dieser Projekte wie das deutsche sones, Infinite Graph oder OrientDB sind relativ neu, aber vielversprechend.

Schnell gefunden

Vorteil der Graphendatenbanken ist, dass Links, das heißt die Verbindungen zwischen den Kanten, schnell gefunden und traversiert werden können. Links sind hier sozusagen First Class Citizens. Leider wird in der Industrie oft ein Graphenmodell in eine relationale Datenbank gepresst, was fatale Auswirkungen hat. Das Traversieren und Suchen wird extrem ineffizient. Graphendatenbanken sind hier um ein Vielfaches schneller. Leider ist die Suche in extrem großen Graphdatenbeständen generell problematisch und eine Skalierung von großen Graphendatenbanken auch nicht einfach. Ein Grund dafür ist, dass das Sharding, das heißt die Aufteilung des Datenbestandes des Graphen auf mehrere Server nicht ohne große Nachteile möglich ist.

Neo4j: An dieser Stelle soll ein System ausführlicher erwähnt werden: Bei Neo4j handelt es sich um eine der ältesten Propeller-Graph-Datenbanken, die seit 2003 in Produktion und seit 2007 auch als Open-Source-Version verfügbar ist. Neo4j implementiert einen ACID-Datenzugriff und ist im Wesentlichen auf Performance getrimmt. Es ist in Java implementiert und läuft nur auf einer JVM. Nebenbei können auch Indexsysteme wie Lucene & Solar angebunden werden.

Neo4j ist als Jar-File verfügbar und kann daher leicht in das Maven- oder andere Buildsysteme integriert werden. Neben einer REST-Schnittstelle gibt es Anbindungen für fast alle bekannten Programmiersprachen. Dennoch ist Java die Haussprache von Neo4j. Listing 2 zeigt das Erstellen oder Updaten der Property eines Knotens in Java.

Interessant ist auch, dass Neo4j einige neue Standards für die Suche in Graphen implementiert. Auch hier wirkt Neo4j intensiv an der Standardisierung [13] von Sprachen und Konzepten wie Tinkerpop Gremlin, Pipes, Traversern oder Rexter mit. Bewertung: Neo4j ist industrieerprobt und liegt in Enterprise-Versionen wie als Open Source vor. Es existieren Anbindungen für sehr viele Sprachen. Das Skalieren der Datenbank oder Sharden des Datenbestandes ist nicht leicht möglich (das gilt allerdings für alle Graphendatenbanken).

Sones stammt aus einer deutschen Softwareschmiede und ist auf den .NET-Markt spezialisiert. Dennoch liegt eine REST-Schnittstelle vor. Interessant ist dabei, dass ein eigenes Filesystem genutzt werden kann, welches die Datenbank sehr schnell macht. Ausgefeilte Versionierungsfähigkeiten, Binärdatenmanagement und Cloud-Fähigkeit (auf Basis von Amazon S3 oder MS Azure) zeichnen die Datenbank aus.

OrientDB entstammt zwar aus der Feder eines einzigen cleveren Entwicklers namens Luca Garulli, jedoch ist diese Datenbank aus zwei Gründen nicht minder interessant: Die Datenbank war zuerst eine Key/Value-Datenbank und kann als solche genutzt werden. Danach wurde die Fähigkeit, Dokumente zu verwalten integriert. Und schließlich wurden Eigenschaften einer Graphendatenbank hinzugefügt. Dies macht OrientDB zu einer sehr universell einsetzbaren Datenbank.

OrientDB ist extrem schnell und braucht den Benchmark mit anderen berühmten Turbo-NoSQL-Datenbanken wie MongoDB oder Redis nicht zu fürchten.