Neo4J, Amazon Neptune und TigerGraph Graph-Datenbanken im Vergleich

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

Anbieter zum Thema

Vogel IT-Medien GmbH

Confluent Germany GmbH

Fivetran Germany GmbH

Neo Technology, Inc.

mehr weniger

Amazon Web Services Germany GmbH

weniger

Dieser kleine Überblick untersucht verbreitete Graph-Datenbanken, 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 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önne. Die Neo4j-Plattform steht unter den Namen „Aura“ als Service in der Public Cloud bereit.

Die Abfragesprache Cypher ist mittlerweile die Standard-Abfragesprache für Graphen, beispielsweise auf Apache Spark. „Cypher soll das Spark-eigene Graph-Tool (s. u.) 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

Amazon Neptune ist ein schneller, belastbarer, vollständig verwalteter Graph-Datenbankservice für die Erstellung von Anwendungen, die mit stark verbundenen Datensätzen arbeiten. Der Kern ist laut Hersteller eine speziell entwickelte, hochleistungsfähige Graph-Datenbank-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.

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 Graph-Datenbank, 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 Graph-Datenbank sinnvoll.

„Die Hochverfügbarkeit von Neptune wird vor allem mit Read Replicas gewährleitet“, 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-Millisekundenbereich liegt.“

Es gebe eine Master-Instanz und bis zu 15 Read-Replicas. Der schreibende Zugriff ist auf die Master-Instanz der Gesamt-Datenbank 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 bzw. 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

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.

Datenbank-as-a-Service

TigerGraph bietet seine Datenbank stundenweise an

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.

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:46745059)