Replikation nach dem Peer-to-Peer-Konzept

Damit ein Server bei vielen oder komplexen Anfragen nicht in die Knie geht, repliziert der erfahrene Admin die Datenbank auf zusätzlichen Servern. Es ist aber recht schwierig, Graphen auf mehreren Servern konsistent zu halten. Nur drei freie Datenbanken nehmen sich dieses Themas an: Neo4j nutzt das Single-Master-/Multiple-Slave-Konzept, bei dem ein Master-Server seine Daten auf mehrere Slave-Server kopiert. Auf diese Kopien darf der Anwender nur lesend zugreifen. Änderungen nimmt nur der Master vor und propagiert sie zu seinen Slaves. Info Grid und Hyper Graph DB bevorzugen hingegen ein Peer-to-Peer-Konzept, bei dem jede Datenbank alle anderen Kollegen auf dem Laufenden hält.

Ähnlich spannend wird das Partitionieren der Datenbank: Wird ein Graph zu groß für einen Server, könnte ihn der Admin auf mehrere Server verteilen. Dazu müsste er ihn an einer Stelle zerschneiden – aber dummerweise gibt es noch keinen Algorithmus, der automatisch die perfekte Schnittstelle findet. Immerhin existieren recht gute Heuristiken, die etwa darauf achten, die Anzahl der zerschnittenen Kanten zu minimieren (Stichwort Min-Cut). Dabei können die Graphen aber in ungleichmäßige Teile zersplittern, womit wiederum ein Server mehr Arbeit erhält als die anderen. Bis auf Info Grid und Hyper Graph DB bieten die kostenlosen Graphdatenbanken daher erst gar keine verteilte Datenhaltung an.

Erstaunlicherweise sind die meisten freien Graphdatenbanken in Java programmiert, nur die deutsche Firma Sones nutzt C# für ihre Graph DB. Vertex DB setzt auf Ruby. Allesamt laufen damit jedoch in einer virtuellen Maschine, die maßgeblich die Performance beeinflusst (siehe Kasten "Benchmarking"). Dennoch ignorieren die Entwickler andere, unter manchen Umständen schnellere Sprachen wie etwa C oder C++.

Benchmarking

Wer die Verarbeitungsgeschwindigkeit der Datenbanken in einem Benchmark vergleichen möchte, stößt unweigerlich auf mehrere Probleme: Zunächst sind die Graphdatenbanken auf unterschiedliche Anwendungsgebiete zugeschnitten. Während beispielsweise Sones Graph DB aus dem Bereich der Analyse sozialer Netzwerke kommt, liegen die Wurzeln von Hyper Graph DB in der künstlichen Intelligenz. Obendrein nutzen alle Datenbanken unterschiedliche Abfragesprachen. So ist Cypher von Neo4j auf die Mustererkennung spezialisiert, Graph DB hingegen auf die Traversierung von Graphen. Unter dem Strich würde man also Äpfel mit Birnen vergleichen.

Problem – vergleichbare Datenbasis

Ein weiteres Problem ist die Datenbasis. Um verlässliche Ergebnisse zu erhalten und die Datenbanken zu stressen, müssen möglichst große Graphen her. Gerade bei Graphdatenbanken sind die jedoch sehr anwendungsspezifisch und obendrein auch noch meist gut unter Verschluss. Paradebeispiel sind Straßenkarten, an die man durchweg nur gegen eine nicht zu knappe Gebühr und mit Knebelverträgen herankommt.

Sones hat für seine Datenbank immerhin einen kleinen Benchmark entwickelt [4]. Er ist allerdings für die Graph DB optimiert und soll primär verschiedene (Server-)Hardware beziehungsweise Plattformen miteinander vergleichen. Als Datenbasis nutzt Sones zudem zufallsgenerierte Graphen, deren Größe und Laufzeit der Anwender frei bestimmen kann (Abbildung 3). Vergleichszahlen von Referenzsystemen muss man derzeit mit der Lupe in älteren Whitepapers suchen [5].

Abbildung 3: Für die Graph DB stellt Sones einen Benchmark bereit, der auf zufällig generierten Graphen arbeitet.

Ergo: Derzeit gibt es keinen (praxisnahen) Benchmark oder Belastungstest, mit dem man alle Graphdatenbanken zuverlässig vergleichen könnte. Wer vor der Entscheidung steht, kommt nicht umhin, mehrere Produkte auf seiner eigenen Datenbasis auszuprobieren.

Neo4j

Zu den ältesten Graphdatenbanken zählt Neo4j. 2003 als Unterbau eines Contentmanagement-Systems entstanden, gliederten sie die Entwickler 2007 in ein eigenständiges Produkt aus. Heute koordiniert die Firma Neo Technologies die Weiterentwicklung, die Finanzierung geschieht über kostenpflichtigen Support. Neo4j lässt sich sowohl als eigenständiger Datenbankserver betreiben als auch in eigene Java-Programme einbetten. Letzteres soll vor allem die Verarbeitungsgeschwindigkeit erhöhen. Der Neo4j-Server bietet unter »http://localhost:7474« eine Webanwendung zur Administration der Datenbank (Abbildung 4). Darüber hinaus darf der Admin den Server über Plugins aufbohren.

Abbildung 4: Neo4j bringt gleich eine Webapplikation mit, in der der Admin Abfragen und Steuerkommandos absetzen kann.

Wie der Datenbankentwickler aus seinem Java-Programm heraus die Datenbank anspricht, zeigt das Beispiel aus Listing 1. Für Java-Programmierer sollte es selbsterklärend sein – der Einstieg in Neo4j fällt somit relativ leicht. Mittlerweile existieren aber auch Anbindungen an zahllose andere Sprachen, darunter Ruby, Python, Scala, Closure und C#. Besonders beliebt ist Neo4j bei Jruby-Entwicklern. Seit Version 1.4 besitzt Neo4j eine eigene Abfragesprache (Cypher), die vor allem zur vereinfachten Mustererkennung gedacht ist, alternativ lässt sich Neo4j auch in Gremlin ansprechen.

01 // Datenbank in /var/speicherort anlegen und neue Beziehung definieren:
02 GraphDatabaseService datenbank = new EmbeddedGraphDatabase("/var/speicherort");
03 private static enum RelTypes implements RelationshipType { erreichbar }
04 // Transaktion starten:
05 Transaction tx = datenbank.beginTx();
06 // Knoten definieren:
07 Node dortmund = datenbank.createNode();
08 Node koeln = datenbank.createNode();
09 // Properties setzen:
10 dortmund.setProperty("Name", "Dortmund");
11 koeln.setProperty("Name", "Köln");
12 // Kanten erzeugen:
13 Relationship a1_do_k = dortmund.createRelationshipTo(koeln, RelTypes.erreichbar);
14 Relationship a1_k_do = koeln.createRelationshipTo(dortmund, RelTypes.erreichbar);
15 // Daten Speichern und alles beenden:
16 tx.success();
17 tx.finish();
18 datenbank.shutdown();