Neo4j – NoSQL-Datenbank mit graphentheoretischen Grundlagen

NoSQL-Datenbanken sind derzeit heiß diskutierte Alternativen zu ihren relationalen Konkurrenten. Wie die meisten ist Neo4j für spezielle Anwendungsfälle entworfen worden, und die Datenbank spielt dort (Performance-)Vorteile gegenüber der relationalen Konkurrenz aus.

In Pocket speichern vorlesen Druckansicht
Lesezeit: 8 Min.
Von
  • Rudolf Jansen
Inhaltsverzeichnis

NoSQL-Datenbanken sind derzeit heiß diskutierte Alternativen zu ihren relationalen Konkurrenten. Wie die meisten von ihnen ist Neo4j für spezielle Anwendungsfälle entworfen worden, und die Datenbank spielt dort (Performance-)Vorteile gegenüber der relationalen Konkurrenz aus.

Hinter dem Schlagwort NoSQL-Datenbanken verbirgt sich eine Reihe von Datenbanken, die seit einigen Jahren existieren, aber erst jetzt im Zuge der NoSQL-Bewegung einer breiteren Öffentlichkeit bekannt geworden sind. Am Beispiel der in diesem Artikel vorgestellten Neo4j-Datenbank zeigt sich, dass die zugrunde liegende Theorie – die Graphentheorie – bereits lange bekannt ist und nun verstärkt Einzug in der Praxis hält.

NoSQL-Datenbanken lassen sich in vier Gruppen einteilen: Key-Value-Stores, spaltenorientierte, dokumentenorientierte und Graphendatenbanken. Die "einfachste" Form stellen die Key-Value-Stores dar, die die zu speichernden Daten immer nur in Form eines Key-Value-Paars ablegen. Der Schlüssel verweist dabei auf einen (meist in Binär- oder Zeichenketten-Format vorliegenden) Wert. Die Einfachheit, die sich vom Grundprinzip her nicht wesentlich von einer einfachen Ablage in Betriebssystemdateien unterscheidet und die seit vielen Jahren in Embedded-Datenbanken wie Oracles Berkeley DB zur Verfügung steht, lässt sich nun auch über "standalone" NoSQL-Datenbanken wie Redis einsetzen. Ein Vertreter der spaltenorientierten Datenbanken, bei denen die Speicherung im Hinblick auf Analysefunktionen optimiert wurde und die sich an Googles BigTable orientieren, ist Cassandra, das seit Anfang 2010 Top-Level-Projekt bei Apache ist. Dokumentenorientierte Datenbanken (zum Beispiel CouchDB spielen ihre Stärken vor allem da aus, wo es um die Speicherung von unstrukturierten Daten geht.

Bei Graphendatenbanken schließlich liegt der Fokus auf der Modellierung und Speicherung der Daten in Form von Knoten und Kanten. Die Knoten enthalten in Form von Properties Eigenschaften eines Objekts, während die Kanten Beziehungen zwischen den Objekten (Knoten) darstellen. Auch Kanten und Beziehungen lassen sich über Properties näher beschreiben. Zielgruppe für solche Graphendatenbanken sind Anwendungen, bei denen die Beziehungen zwischen den Objekten und eine performante Navigation in den Beziehungen im Mittelpunkt stehen.

Die theoretischen Grundlagen zu dieser Speicherart stammen aus der Graphentheorie, bei der es unter anderem um effiziente Navigation in Netzwerken geht. Dazu existieren einige Verfahren (etwa Kürzeste-Wege-Algorithmen, Travelling Salesman Problem), auf deren Basis nun einige NoSQL-Datenbanken entwickelt und in der Praxis eingesetzt werden.

Welche Datenart kann man als Netzwerk in Graphenform ablegen und ist daher geeignet für die Graphendatenbanken? Neben klassischen GIS-Anwendungen (Geographic Information System), die etwa eine Navigation zwischen zwei Orten durchführen sollen, sind soziale Netze aus der Web-2.0-Szene zu nennen. Dort geht es häufig um die Frage, wer wen kennt oder über welche Wege zwei Entitäten (Knoten) in Beziehung zueinander stehen.

Sicherlich lassen sich solche Beziehungssysteme auch in relationalen Datenbanken implementieren. Jede Entität wird dort als Tabelle modelliert, und Beziehungen zwischen den Entitäten erfolgen dann über Fremdschlüssel, die sich als Basis für Join-Abfragen verwenden lassen. Abfragen auf solchen relational modellierten Systemen führen aber bei steigender Komplexität der Beziehungen in vielen Fällen zu Performanceengpässen.

Während die Key-Value-Datenbanken die Probleme relationaler Datenbanken mit extrem großen Datenmengen umgehen und auch bei solchen hohen Datenmengen noch akzeptable Antwortzeiten anbieten wollen, geht es bei den Graphendatenbanken in erster Linie um komplexe vernetzte Daten, bei denen das relationale Modell durch die hohe Zahl von Join-Operationen an seine Grenzen stößt. Beispiele für Graphendatenbank-Vertreter in der NoSQL-Gemeinde sind Sones der gleichnamigen Firma aus Erfurt, auf die sich per Webservice, REST oder C#-API zugreifen lässt, und eben Neo4j.