JanusGraph: Ein kleiner Blick in die große Welt der Graphen

JanusGraph ist eine skalierbare Graphdatenbank, die für das Speichern und Abfragen von Graphen mit Hunderten von Milliarden von Knoten und Kanten optimiert ist. Das Projekt wurde von Titan abgespalten und steht seit 2017 in der Linux Foundation unter Open Governance.

JP: IBM war Gründungsmitglied von JanusGraph und ich war als Teammitglied an der Entwicklung beteiligt. Wir hatten den Vorgänger Titan bereits für mehrere verschiedene Produkte eingesetzt. Titan haben wir sehr geschätzt, unter anderem wegen seiner Open-Source-Lizenz und der Flexibilität, die es uns in Bezug auf den Aufbau einer umfassenden Graphplattform gegeben hat.

Als DataStax Aurelius (Anm. d. Red.: Aurelius hat Titan gegründet) übernommen hat, stand die Open-Source-Community vor der Frage, wie die Zukunft von Titan aussehen kann. Schließlich veröffentlichte DataStax ein Graphangebot als Teil von DataStax Enterprise – allerdings ohne Open-Source-Option. Uns war klar, dass wir nicht die Einzigen sind, die eine Open-Source-Graphdatenbank benötigen. Also haben wir Partner in der Community gesucht und gemeinsam daran gearbeitet, JanusGraph von Titan abzuspalten und mit offener Governance in der Linux-Foundation einzubringen.

FH: Wir haben auch ursprünglich Titan verwendet, den Vorgänger von JanusGraph. Titan passte natürlich zu uns, da wir nach einer Datenbank suchten, die horizontal skalierbar war und es möglich machte, Verbindungen zwischen Schadsoftwareprogrammen zu finden – ein typischer Anwendungsfall für eine Graphdatenbank. Nachdem die Firma, die Titan entwickelt hatte, übernommen wurde und kurz darauf alle Arbeiten an Titan eingestellt wurden, blieb ein Datenbanksystem, das nicht mehr gepflegt wurde – keine optimale Lösung. Es war sehr erfreulich für uns, dass IBM und andere JanusGraph als Abspaltung von Titan gegründet haben. Wir haben uns an diesem Projekt beteiligt, um JanusGraph als skalierbare Open-Source-Graphdatenbank zum Erfolg zu verhelfen.

Ich war bereits in Apache TinkerPop involviert, wo ich hauptsächlich die .NET-Variante von Gremlin, Gremlin.Net, entwickelte. Daher war es naheliegend, eine Erweiterungsbibliothek für JanusGraph beizusteuern. Aber ich habe auch kleine Beiträge zu anderen Teilen des Projekts geleistet und neuen Anwendern auf der Mailingliste oder auch auf StackOverflow geholfen. So konnte ich die verschiedenen Bereiche des Projekts kennenlernen und mich mehr in das Projekt einbringen.

JP: Anwender sollten wissen, dass JanusGraph und Neo4j das Apache TinkerPop Graph Framework unterstützen. TinkerPop gibt ihnen so die Möglichkeit, die gleiche Graphenstruktur und Gremlin-Graph-Traversalsprache zu verwenden, um mehrere Graphdatenbanken mit dem gleichen Code zu evaluieren. TinkerPop ist mit vielen anderen Anbietern kompatibel, darunter Amazon Neptune, Microsoft Azure Cosmos DB und DataStax Enterprise Graph. Allerdings ist zu beachten, dass viele TinkerPop-Implementierungen keine freien Open-Source-Implementierungen sind.

Eine Antwort, die Anwender nicht unbedingt erwarten: Teams sollten mit ihren Anwälten zusammenarbeiten, um die Lizenzen zu bewerten und festzustellen, welche ihren Bedürfnissen entsprechen. JanusGraph verwendet die Apache-Lizenz, eine liberale Open-Source-Lizenz, die sich mit wenigen Einschränkungen nutzen lässt. Die Neo4j-Community-Edition verwendet die GNU General Public License, die strengere Anforderungen an den Vertrieb von Software stellt. Viele Entwickler benötigen schließlich die Skalierungs- und Verfügbarkeitsfunktionen, die nur in der Neo4j-Enterprise-Edition verfügbar sind. Diese erfordert eine kommerzielle Abonnementlizenz.

FH: Ich sehe hauptsächlich zwei unterscheidende Faktoren zwischen diesen beiden Graphdatenbanken. Erstens ist Neo4j in der Regel ein in sich geschlossenes Projekt. Es implementiert also eine eigene Speicher-Engine, Indizes, Serverkomponente, Netzwerkprotokoll und Abfragesprache. JanusGraph hingegen nutzt für die meisten dieser Aspekte Drittprojekte. Der Grund dafür ist, dass es für diese Anforderungen bereits Lösungen gibt, die in ihrer spezifischen Aufgabe gut sind. Durch ihre Verwendung kann sich JanusGraph wirklich auf den Graphaspekt konzentrieren, anstatt auch diese Probleme wieder lösen zu müssen.

JanusGraph kann beispielsweise Elasticsearch oder Apache Solr für erweiterte Indexfunktionen wie Volltextsuche und skalierbare Datenbanken wie Apache Cassandra oder HBase verwenden, um Daten zu speichern. Aus diesem Grund ist es wahrscheinlich einfacher, mit Neo4j zu beginnen. Aber JanusGraph bietet mehr Flexibilität, da Benutzer beispielsweise je nach Bedarf zwischen verschiedenen Speicher- und Index-Backends wählen können. Der Nutzer kann selbst entscheiden, welchen Ansatz er bevorzugt.

Die anderen wichtigen Unterscheidungsmerkmale sind aus meiner Sicht die Schnittstellen für Nutzer dieser beiden Graphdatenbanken mit der Abfragesprache als zentralem Aspekt. JanusGraph implementiert dafür TinkerPop (Anm. d. Red.: der derzeitigen De-facto-Standard für Graphdatenbanken), das den Benutzern meist die gleiche Erfahrung über verschiedene Graphendatenbanken hinweg bietet - ähnlich der Rolle, die SQL für relationale Datenbanken spielt.

Während sich TinkerPop mit seiner Abfragesprache Gremlin zusammen mit Neo4j verwenden lässt, empfiehlt Neo4j meist ihre eigene Abfragesprache – Cipher. So landen die meisten Neo4j-Benutzer zwangsläufig bei dieser Sprache. Natürlich müssen die Benutzer selbst entscheiden, welche Abfragesprache sie bevorzugen - Gremlin oder Cipher. Und auch, wie wichtig es ist, dass sie irgendwann in der Zukunft leicht zu einer anderen Graphdatenbank wechseln können.

Neben diesen technischen Aspekten möchte ich natürlich auch darauf hinweisen, dass JanusGraph ein Open-Source-Projekt ist, das vollständig community-driven ist. Benutzer, die eine bestimmte Funktion implementiert sehen wollen, können diese daher einfach selbst implementieren.

FH: Ich habe bereits erwähnt, dass JanusGraph verschiedene Komponenten verwendet, um eine Graphdatenbank zu erzeugen. Diese bieten zahlreiche Funktionalitäten wie Index- und Speicher-Engine. Dank dieses Ansatzes erhalten Nutzer zwar eine große Flexibilität und einen umfangreichen Funktionsumfang. Gleichzeitig kann es aber auch neue Benutzer etwas überfordern. Ich möchte allerdings darauf hinweisen, dass man für den Einstieg in JanusGraph keine tiefen Kenntnisse aller Komponenten benötigt. Als ich mit Titan anfing - und für JanusGraph gilt es im Grunde genommen auch noch - wusste ich nicht wirklich etwas über Cassandra oder Elasticsearch. Aber ich konnte Titan mit diesen Backends trotzdem schnell einrichten und einsetzen. Im Laufe der Jahre wechselten wir von Cassandra zu Scylla, fügten Apache Spark für maschinelles Lernen hinzu und vereinfachten unsere Bereitstellung, indem wir JanusGraph in Docker-Container verschoben haben, die auf Docker Swarm gehostet werden.

Mein Ratschlag ist, mit einer kleinen und einfachen Bereitstellung zu beginnen und dann die Größe der Bereitstellung und ihre Komplexität bei Bedarf zu erhöhen. Die Dokumentation von JanusGraph enthält auch ein Kapitel "Deployment Scenarios", das ein relativ einfaches Einstiegsszenario beschreibt und wie es sich zu einem fortgeschritteneren Szenario weiterentwickeln lässt. Ein weiteres Projekt, das für JanusGraph sehr wichtig ist, ist TinkerPop. Daher würde ich neuen Benutzern empfehlen, sich mit TinkerPop und vor allem mit der Graphabfragesprache Gremlin vertraut zu machen. Es gibt wirklich gute Hilfen, um loszulegen, wie die Tutorials von TinkerPop oder das kostenlose E-Book „Practical Gremlin“.

JP: In erster Linie sollten Nutzer bereit sein, sich voll und ganz auf Open Source einzustellen und dazu beizutragen. JanusGraph ist ein Community-Projekt, das weder im Besitz von noch von einem einzigen Anbieter betrieben wird. Interessierte Teams sollte sich mit der JanusGraph-Community zusammenschließen, um Fehler zu identifizieren und zu beheben, auf die sie in der täglichen Arbeit stoßen. Im Laufe der Zeit können Teams mit kontinuierlichen Beiträgen mehr Einfluss bei JanusGraph erhalten, um das Projekt voranzubringen. Der Betrieb kann eine große Hürde sein, wenn Teams verstärkt in die Produktion gehen. Wenn sie mit einer größeren Zahl Technologien arbeiten, die neu für ein Team sind, ist großtmögliche Sorgfalt erforderlich, um die eigene Dateninfrastruktur am Laufen zu halten. Da JanusGraph auf ein externes Speicher-Backend (z.B. Apache Cassandra oder Apache HBase) angewiesen ist, benötigten Anwender Kenntnisse in der Bereitstellung und im Betrieb dieser horizontal skalierbaren Datenbanken und ihrer Abhängigkeiten. Natürlich sollten sich Anwender auch in diesen Open-Source-Communities engagieren.

JP: In den nächsten Jahren wünsche ich mir, dass die Tools rund um das Graph-Ökosystem verbessert werden. Dazu gehören Tools zur Graphmodellierung, zur Graphvisualisierung und zum Betrieb von Graphdatenbanken. Graphen sind in der Regel nicht allein in einer allgemeinen Datenarchitektur, so dass es nützliche Tools braucht, die Lücke zwischen Graphendaten und anderen Datenmodellen zu schließen, um Graphen in den Mainstream zu bringen.

Das Interesse an der Standardisierung von Graphdaten, einschließlich Property-Graphen, RDF und SQL, ist beim W3C in diesem Jahr gestiegen. Mit einer offenen Standardspezifikation für Graphdaten könnte es den Anbietern von Graphdatenbanken besser gelingen, ihre Position im Wettbewerb zu verbessern.

FH: Gerade für JanusGraph ist es schwierig, die zukünftige Entwicklung vorherzusagen. Denn das Projekt ist vollständig community-driven. Viele Beiträge kommen von Entwicklern, die im Prinzip interessierte Anwender sind. Sie wollen JanusGraph aufgrund ihrer eigenen Erfahrungen und Bedürfnissen verbessern.

Neben vielen kleinen Performance-Verbesserungen wird JanusGraph höchstwahrscheinlich bald über ein In-Memory-Backend mit deutlich verbesserter Performance verfügen. Dieses ist dann auch produktionsreif – im Gegensatz zum aktuellen In-Memory-Backend, das nur zu Testzwecken gedacht ist. Dieses verbesserte Backend ist ein gutes Beispiel für einen Beitrag von Anwendern von JanusGraph, in diesem Fall waren es Entwickler von Goldman Sachs.

Backends sind im Allgemeinen ein Bereich, in dem ich für JanusGraph in den nächsten Jahren erhebliche Verbesserungen erwarte. Natürlich profitieren wir einfach von Optimierungen in neuen Versionen der Backends selbst, aber völlig neue Backends können auch große Verbesserungen oder völlig neue Funktionen für JanusGraph bieten.

Sehr vielversprechend sieht zum Beispiel FoundationDB aus, da es sich vollständig auf die Entwicklung einer skalierbaren Speicher-Engine konzentriert, die Transaktionen mit ACID-Eigenschaften bietet. Zusätzliche Schichten können Funktionen wie komplexere Datenmodelle oder erweiterte Indexfunktionen hinzufügen. Dieser Ansatz scheint gut zu der modularen Architektur von JanusGraph zu passen und hat das Potenzial, einige häufige Probleme mit JanusGraph zu lösen wie etwa das Speichern von Supernodes oder die Durchführung von Upserts.

Viele Verbesserungen für JanusGraph werden tatsächlich von TinkerPop kommen, besonders wenn die nächste Hauptversion, TinkerPop 4 veröffentlicht wird. Die Entwicklung von TinkerPop 4 befindet sich noch in einem sehr frühen Stadium, aber einige wesentliche Verbesserungen sind bereits erkennbar. Worauf ich mich persönlich besonders freue ist eine breitere Palette von Execution-Engines für Gremlin-Traversals. Im Moment kann man wählen, ob man ein Traversal mit einem einzelnen Thread - was für Echtzeit-Anwendungsfälle gut geeignet ist - oder auf einem Rechencluster mit Spark (z.B. für maschinelles Lernen oder Graph Analytics) durchführen möchte.

Bei G DATA haben wir oft Anwendungsfälle, die sich in der Mitte dieser beiden Optionen befinden, da sie in wenigen Sekunden beantwortet werden sollten - was mit Spark nicht ganz möglich ist, da es einige Overheads hat. Aber sie beinhalten das Ablaufen einer beträchtlichen Anzahl von Kanten, was auch nicht gut für die Ausführung mit einem einzelnen Thread geeignet ist. Eine zusätzliche Execution-Engine, die mehr Computerressourcen verbraucht, aber nicht erst den gesamten Graphen laden muss, könnte die perfekte Lösung für diese Anwendungsfälle sein.

Derzeit wird auch viel Aufwand in die Erstellung eines abstrakteren Datenmodells für TinkerPop investiert, das nicht graphspezifisch ist. Dies hat das Potenzial, TinkerPop auch für nicht-Graphdatenbanken und Rechenmaschinen zu öffnen. So kann es das Ökosystem von TinkerPop-fähigen Datenbanken erheblich erweitern.

FH: Das mag offensichtlich klingen: Nämlich ein neues Schema oder größere Änderungen an einem Schema zu evaluieren, bevor sie es in die Produktion nehmen. Aber ich glaube, dass viele Nutzer es immer noch nicht machen. Dies sollte möglichst mit realen Daten erfolgen und die Auswertung sollte Abfragen beinhalten, die tatsächliche Anwendungsfälle modellieren. Es gibt wirklich keinen anderen Weg, um sicherzustellen, dass das Schema tatsächlich gut zu den Anwendungsfällen passt. Außerdem ist das spätere Ändern des Schemas in der Produktion viel zeitaufwendiger als eine erste Evaluation.

Ein Thema, das wahrscheinlich für alle Graphdatenbanken sehr wichtig ist, sind Supernodes. Denn sie können zu Problemen führen, insbesondere zu sehr hohen Ausführungszeiten bei Abfragen. Am besten ist es also frühzeitig zu prüfen, ob Supernodes in dem gewählten Datenmodell auftreten können. Sie sollten dann umgangen werden, zum Beispiel indem das Schema entsprechend angepasst wird.

Eine weitere allgemeine Frage für Graphmodelle ist, ob etwas eine Eigenschaft auf einem Knoten oder ein eigenständiger Knoten sein sollte, der mit einer Kante mit dem ursprünglichen Knoten verbunden ist. Mein üblicher Ansatz ist es, zu entscheiden, ob ich nach anderen Knoten suchen möchte, die den gleichen Wert für diese Eigenschaft haben. In diesem Fall modelliere ich sie als eigenen Knoten mit Kanten, die sie mit allen Knoten mit diesem Wert verbinden. Andernfalls kann es in der Regel auch nur eine Knoteneigenschaft sein.

JP: Die Graphmodellierung braucht Zeit. Es ist einfach, mit einem naiven Graphmodell zu beginnen, aber höchstwahrscheinlich wird man beim ersten Versuch nicht das beste Modell erhalten. Es dauert in der Regel mehrere Iterationen, um das richtige Modell für die spezifischen Anwendungsfälle zu finden.

Zu Beginn ist es sinnvoll, mit einem kleinen repräsentativen Datensatz für die eigene Domäne und einer Liste der Abfragen, die auszuführen sind, zu arbeiten. Damit lässt sich festellen, wie gut das Modell gegenüber bestehenden Anwendungsfällen abschneidet. Dabei sollten Anwender genau auf den Verzweigungsfaktor achten, wenn sie von Knoten zu Knoten springen. Denn selbst bei einer angemessenen Anzahl von Kanten an einem bestimmten Knoten kann die Anzahl der Graphelemente, die die Abfrage berühren, mit wenigen Sprüngen exponentiell explodieren. Daher ist es eine Überlegung wert, die Graphstruktur zu denormalisieren, um die Filterung (Anpassung an Label oder Eigenschaften) besser auszunutzen. So lässt sich die Anzahl der Elemente bereits in einer frühen Phase der Abfrage reduzieren.

FH: Es kommt darauf an, ob Anwender Code beisteuern, die Dokumentation verbessern oder auf andere Weise helfen wollen, wie etwa anderen Benutzern auf der Mailingliste zu helfen, die auf ein Problem stoßen, auf das sie auch schon gestoßen sind und wissen, wie man es löst.

Für Code- oder Dokumentationsänderungen können neue Entwickler einfach die offenen Issues auf GitHub durchsuchen, um die für sie relevanten zu finden. Oder sie erstellen ein neues Issue, um die vorgeschlagene Verbesserung zu beschreiben und erstellen dann einfach einen Pull-Request.

Dies ist nicht anders als bei anderen Open-Source-Projekten. Ein Vorteil von JanusGraph für neue Entwickler besteht wahrscheinlich darin, dass es aus so vielen verschiedenen Modulen besteht. Daher gibt es es auch ein breites Spektrum an Themen, zu denen man beitragen kann – von etwas Spezifischen zu einem bestimmten Backend wie Cassandra oder Elasticsearch über Kernbereiche wie die Ausführung einer Abfrage bis hin zu Utility-Aspekten rund um JanusGraph wie Schemamanagement oder Client-Bibliotheken für eine bestimmte Programmiersprache. So können neue Entwickler also einen Bereich auswählen, in dem sie bereits über Kenntnisse verfügen oder an dem sie interessiert sind.

Wenn jemand daran interessiert ist, einen Beitrag zu JanusGraph zu leisten, aber etwas Hilfe braucht, um loszulegen, dann ist es natürlich immer möglich, mich oder einen anderen aktiven Entwickler zu fragen. Wir sind gerne bereit, zu helfen.

JP: JanusGraph ist eine offene Community und die Vielfalt dieser Community hat dazu beigetragen, das Projekt in viele neue Richtungen zu lenken. Wir haben solide Beiträge aus unserer Community erhalten, um JanusGraph mit Treibern für verschiedene Programmiersprachen und mit Speicheradaptern für verschiedene Datenbank-Backends zu erweitern.

Unsere Entwickler von IBM Compose haben Features für die dynamische Graphverwaltung auf dem Server beigetragen. Wir haben Verbesserungen an den Build- und Testinfrastrukturen sowie an der Integration mit Docker und Apache Ambari erhalten.

Wir würden uns freuen, wenn sich mehr Menschen beteiligen. Und es gibt viele Möglichkeiten, auch über die Programmierung des Quellcodes hinaus zu helfen. Ich denke, dass es als kollaborative Gemeinschaft am wichtigsten ist, dass Menschen ihr Wissen und ihre Erfahrungen teilen, indem sie Fragen in den Foren beantworten, die JanusGraph-Dokumentation aktualisieren, Beispielprojekte aufbauen, die JanusGraph auf innovative Weise nutzen, indem sie JanusGraph auf lokalen Meetups oder Konferenzen präsentieren. Der beste Weg, um uns zu erreichen, ist über unsere Google Groups. Wenn Google durch Firmen-Firewalls oder in bestimmten Regionen eingeschränkt ist, lässt sich diese als Mailingliste mit einer E-Mail-Adresse abonnieren.

Dieses Interview ist eine Übersetzung eines Beitrags, der zuerst hier im IBM-Blog erschienen ist.