Suchen

Apache TinkerPop, Neo4J, Amazon Neptune und TigerGraph Graphdatenbanken im Vergleich

| Autor / Redakteur: Michael Matzer / Nico Litzel

Der Markt für Graphdatenbanken blüht und wächst, denn die Nachfrage hinsichtlich der Analyse vernetzter Daten steigt rasch. Doch der IT-Nutzer fragt sich, welche Graphdatenbank die leistungsfähigste ist und sich mit ihren Funktionen für ihn am besten eignet.

Firmen zum Thema

Für bestimmte Anwendungsszenarien und die Speicherung von stark vernetzten Informationen bieten Graphdatenbanken einige Vorteile. Wir stellen die bekanntesten vor.
Für bestimmte Anwendungsszenarien und die Speicherung von stark vernetzten Informationen bieten Graphdatenbanken einige Vorteile. Wir stellen die bekanntesten vor.
(Bild: © flashmovie - stock.adobe.com)

Dieser kleine Überblick untersucht verbreitete Graphdatenbanken, die inzwischen alle in der Cloud betrieben werden können: Neo4J, Amazon Neptune und Apache TinkerPop. Ein Newcomer in der Auswahl ist TigerGraph.

Apache TinkerPop

Apache TinkerPop ist ein Open-Source-Projekt. Die Veröffentlichung der ersten Version der Graph-Traversal-Engine fand 2011 statt. 2015 fand es seinen Weg in den Apache-Inkubator. Weil es sich leicht integrieren lässt, flexible Speicheroptionen aufweist und eine Permissive-Use-Lizenz besitzt, wurde TinkerPop zur bevorzugten Wahl von NoSQL-Anbietern, wenn sie ihren Produkten eine Graph-Schnittstelle hinzufügen wollten.

Nach Angaben der unabhängigen Publikation DB-Engines.com ist Neo4J bereits für etwa die Hälfte des gesamten Graph-Marktes verantwortlich. Produkte, die auf TinkerPop basieren, sind in etwa 40 Prozent des Gesamtmarktes vertreten. Die restlichen zehn Prozent verteilen sich auf über 20 verschiedene Anbieter, darunter auch bekannte wie Apache Spark, junge wie Amazon Neptune und proprietäre wie SAP HANA.

Neo4J

Neo4J lässt sich unter anderem für das Aufdecken von Betrugsversuchen verwenden.
Neo4J lässt sich unter anderem für das Aufdecken von Betrugsversuchen verwenden.
(Bild: Neo4J)

Neo4J verfügt über eine native Graph-Plattform. „Nativ bedeutet, dass wir die Graphdatenbank von Grund auf für das Graph-Datenmodell entwickelt haben“, erläuterte CEO Emil Eifrem, der auf seiner Kundenveranstaltung Berlin besuchte, den Unterschied zu nicht-nativen Graphdatenbanken. „Dort wird das Graph-Datenmodell über eine Adapterschicht realisiert, die auf das darunter liegende Datenmodell, egal, ob relational, JSON-basiert oder Key-Value-basiert, aufgesetzt wird.“ Dieser Ansatz sei wenig performant, nur begrenzt skalierbar und zudem fehleranfällig.

Im Unterschied dazu sei die Neo4j-Datenbank aus einem Guss, denn der Hersteller besitze ja den kompletten Technologiestapel und könne alle Komponenten für einen bestimmten Zweck optimieren, also auch für bestimmte Workloads. Zudem besitze er die Indizes, die er oder der Kunde ebenfalls zweckgebunden optimieren könnten. Die Neo4j-Plattform steht unter den Namen „Aura“ als Service in der Public Cloud bereit.

Die Abfragesprache Cypher ist mittlerweile die Standardabfragesprache für Graphen, beispielsweise auf Apache Spark. „Cypher soll das Spark-eigene Graph-Tool mit der Zeit ablösen, wobei die Cypher-Implementierung für Spark CAPS (Cypher für Apache Spark) heißen wird“, sagte Eifrem.

Amazon Neptune

Die Grafik zeigt ein Beispiel eines Social-Network-Graphs. Anhand der Menschen (Knoten) und ihrer Beziehungen (Kanten) können Nutzer herausfinden, wer die „Freunde von Freunden“ einer bestimmten Person sind – zum Beispiel die Freunde von Howards Freunden.
Die Grafik zeigt ein Beispiel eines Social-Network-Graphs. Anhand der Menschen (Knoten) und ihrer Beziehungen (Kanten) können Nutzer herausfinden, wer die „Freunde von Freunden“ einer bestimmten Person sind – zum Beispiel die Freunde von Howards Freunden.
(Bild: AWS)

Amazon Neptune ist ein schneller, belastbarer, vollständig verwalteter Graphdatenbankservice für die Erstellung von Anwendungen, die mit stark verbundenen Datensätzen arbeiten. Der Kern ist laut Hersteller eine speziell entwickelte, hochleistungsfähige Graphdatenbank-Engine, die für die Speicherung von Milliarden von Beziehungen und die Abfrage des Graphen mit einer Latenzzeit im Millisekundenbereich optimiert ist. „Die Datenbank ist auf OLTP-Anfragen optimiert, auf sehr viele parallele Anfragen mit sehr kurzer Latenzzeit“, erläutert Michael Hanisch, Head of Technology bei Amazon Web Services (AWS) in Deutschland.

Dieses Diagramm veranschaulicht die Funktionsweise von Amazon Neptune.
Dieses Diagramm veranschaulicht die Funktionsweise von Amazon Neptune.
(Bild: AWS)

Amazon Neptune unterstützt die gängigsten Datenmodelle Property Graph und RDF von W3C sowie die zugehörigen Abfragesprachen Apache TinkerPop Gremlin und SPARQL, sodass Nutzer damit wie mit offenen APIs Abfragen erstellen können, die effizient durch hochverknüpfte Datasets navigieren.

Amazon Neptune ist für die Arbeit mit Graphdaten im Hauptspeicher optimiert, beschränkt die Datenbank aber nicht auf die Größe des Speichers. Die Größe einer Amazon-Neptune-Datenbank ist immer auf 64 Terabyte beschränkt, unabhängig von der Größe des Hauptspeichers. Der Nutzer muss zusehen, dass er seine Daten immer im Working Set hat, also in dem, was viel gelesen wird. Dafür optimiert Neptune die Lesezugriffe, die Read Queries. Deshalb muss der Nutzer je nach Bedarf nach oben oder nach unten skalieren. „Wir unterscheiden zwischen schreibendem und lesendem Zugriff“, sagt Hanisch. Die diversen Working Sets könnten je nach Anfragelasten verschieden gestaltet werden.

„Was die Kunden wollen, sind Ausfall- und Datensicherheit, Performance und angemessene Kosten pro Workload“, weiß Hanisch. „Sie wollen zudem Hochverfügbarkeit, Unternehmenskunden wollen Support und die Einhaltung von SLAs.“

Skalierbarkeit und Leistung

Zugleich verlangen die Kunden die Skalierbarkeit der Graphdatenbank, wenn beispielsweise ein größeres Datenbankmodell zu realisieren sei, wie etwa bei Facebook. „Da gibt es dann auch viele Verbindungen zwischen den Entitäten und Konzepten.“

Es gibt verschiedene Wege, eine ausreichende Skalierbarkeit sicherzustellen. „Man könnte im relationalen Modell beispielsweise eine ziemlich lange Tabelle erstellen, etwa für einen Kunden und seine Kontakte“, schlägt Hanisch vor. Aber bei einem Beziehungsgeflecht komme der Nutzer mit einem relationalen Modell schnell an seine Grenzen. Deshalb sei die Verwendung einer Graphdatenbank sinnvoll.

„Die Hochverfügbarkeit von Neptune wird vor allem mit Read Replicas gewährleistet“, sagt Hanisch. Diese können in verschiedene Availability Zones (AZs) platziert werden und synchronisieren ihre Daten automatisch aus dem Cluster-Volume von Amazon Neptune. „Der Lesezugriff für Queries“, so Hanisch, „erfolgt über diese Replikate, was optimal für OLTP ist, sodass die Latenz im Zehn-Millisekunden-Bereich liegt.“

Es gebe eine Master-Instanz und bis zu 15 Read-Replicas. Der schreibende Zugriff ist auf die Master-Instanz der Gesamtdatenbank begrenzt, aber der Lesezugriff lässt sich stark skalieren: „Der Nutzer kann diese Zugriffe über maximal 15 Replikate der gesamten Datenbank verteilen.“ Die Master-Instanz sei auch für die Serialisierung der Transaktionen zuständig, für die Neptune ausgelegt sei. Sie und viele Working Sets würden im Hauptspeicher gehalten, um den Durchsatz zu erhöhen und die Latenz zu reduzieren. Das Anlegen von Working Sets und ihre Optimierung erfolgen laut Hanisch automatisch.

Die Daten werden an die Replikate über den Virtual Storage Layer (VSL) von Amazon Neptune verteilt, das sogenannte Cluster-Volume. Diese logische Schicht basiert auf einem Storage-Cluster, den Neptune verwaltet. Der VSL führt ein über die Availability Zones (AZs) verteiltes Transaktions-Log, was zusätzlich zu IAM- und Key-Management die Datensicherheit erhöht. Hochverfügbarkeit und Dauerhaftigkeit der Daten seien so für die anspruchsvollen Kunden gewährleistet.

Mit einer Verteilung von Replicas über mehrere AZs hinweg lasse sich die Hochverfügbarkeit zwecks Failover maximieren. „Die Replikate“, so Hanisch, „holen sich ihre Daten natürlich zunächst aus der gleichen AZ, um die Latenzzeit zu reduzieren.“ Die Größe der Replikate hänge von der Arbeitslast ab, doch diese Größe lasse sich statisch gut definieren. Die Workload sei entscheidend, so etwa wie viele Anwendungen zugreifen können oder dürfen.

Die Leistung lässt sich analog zur Skalierbarkeit steigern. „Replicas“, so Hanisch weiter, „lassen sich auf größere EC2-Instanzen verlegen, um ihnen mehr Leistung zu verleihen: Mehr Ressourcen, mehr gleichzeitige Verbindungen, können mehr Daten im Cache vorhalten.“ Load Balancing lasse sich für alle Replikate realisieren. „Amazon Cloudwatch, das die Datenbank überwacht, liefert dazu geeignete Metriken, wie beispielsweise die CPU oder der Hauptspeicher ausgelastet sind.“

TigerGraph

Vorbereitung für einen Benchmark-Test, der 2018 und 2019 von TigerGraph durchgeführt wurde. Diese zwei Balkendiagramme zeigen die Größe einer normalisierten Datenbank für die Datenmengen Graph500 (www.graph500.org) und für Twitter (http://an.kaist.ac.kr/traces/WWW2010.html) an. Auffällig ist, dass die Datenbank von TigerGraph sehr klein ist.
Vorbereitung für einen Benchmark-Test, der 2018 und 2019 von TigerGraph durchgeführt wurde. Diese zwei Balkendiagramme zeigen die Größe einer normalisierten Datenbank für die Datenmengen Graph500 (www.graph500.org) und für Twitter (http://an.kaist.ac.kr/traces/WWW2010.html) an. Auffällig ist, dass die Datenbank von TigerGraph sehr klein ist.
(Bild: © TigerGraph)

Im März 2020 wurde die Version 3.0 der Graph-Datenbank TigerGraph freigegeben. Als TigerGraph Cloud steht sie auch als Graphdatenbank-as-a-Service zur Verfügung. Die Stärken dieser Version, die über einen Visual Query Builder verfügt, sollen lineare Skalierbarkeit und vor allem Analyse sein. Mit einer „Analyse per Mausklick“ soll der Nutzer relevante Rückschlüsse aus komplexen Datenbeziehungen ziehen können, einfach durch das Bewegen der Knoten und Kanten in einem Diagramm und der Angabe der Analyseebenen.

In der Benutzeroberfläche von TigerGraph ist der gleiche Graph zu sehen, aber mit dem Vermerk (in der linken Spalte), dass zehn Ebenen an Beziehungen untersucht wurden und die Ausführung daher langsam sein könnte.
In der Benutzeroberfläche von TigerGraph ist der gleiche Graph zu sehen, aber mit dem Vermerk (in der linken Spalte), dass zehn Ebenen an Beziehungen untersucht wurden und die Ausführung daher langsam sein könnte.
(Bild: TigerGraph)

Dieser Graph zeigt in TigerGraph die Beziehung auf, in der die CEOs von Unternehmen A und B zueinander stehen: Sie spielen beide Fußball. Dieses Modell lässt sich exportieren.
Dieser Graph zeigt in TigerGraph die Beziehung auf, in der die CEOs von Unternehmen A und B zueinander stehen: Sie spielen beide Fußball. Dieses Modell lässt sich exportieren.
(Bild: TigerGraph)

Besonders stolz ist man TigerGraph auf die Fähigkeit, bis zu zehn Ebenen an Beziehungen untersuchen und darstellen zu können. Dafür ist ein hohes Maß an Skalierbarkeit in einer entsprechend ausgestatteten Cloud-Instanz nötig. In einer Vorführung lief TigerGraph auf AWS. Damit diese Skalierbarkeit linear wachsen kann, sind eine entsprechende Clusterverwaltung und Massive Parallel Processing notwendig, zwei Leistungsmerkmale, auf die TigerGraph Wert legt.

OLTP (Online Transaction Processing) und OLAP (Online Analytical Processing) werden in TigerGraph zu HTAP zusammengeführt: Hybrid Transactions + Analytics.
OLTP (Online Transaction Processing) und OLAP (Online Analytical Processing) werden in TigerGraph zu HTAP zusammengeführt: Hybrid Transactions + Analytics.
(Bild: TigerGraph)

Im Cluster sind die Daten abgelegt und gesichert. Die nutzerdefinierte Indexierung soll Nutzer in die Lage versetzen, die Datenbankleistung für bestimmte Fragen zu verbessern – analog zum Working Set in Neptune. „Ähnlich wie der Index am Ende eines Fachbuchs enthält auch ein nutzerdefinierter oder Sekundärindex in einer Datenbank Verweise, mit denen der Nutzer direkt auf die Daten zugreifen kann, die er gerade benötigt“, so der Hersteller.

(ID:46850378)

Über den Autor