Wie passen relationale Daten in eine Graphendatenbank?

Wie passen relationale Daten in eine Graphen­datenbank?

Teil 2 unserer Blog-Reihe

Seit dem Aufkommen von Datenbankmanagementsystemen gibt es eine anhaltende Debatte darüber, wie das Datenbankmodell für ein solches System aussehen sollte. Die Vielfalt der existierenden Datenbankmodelle zeigt, dass es viele Faktoren gibt, die ihre Entwicklung beeinflussen. Seien es die Eigenschaften oder die Struktur der zu modellierenden Domäne oder die Ansprüche an die Hard- und Software. Darüber hinaus basiert jeder Datenbank-Modellvorschlag auf bestimmten theoretischen Grundlagen und dient als Basis für die Entwicklung von verwandten Modellen. Je nach Domäne oder Datensatz können aber auch unterschiedliche Datenbankmodelle für denselben Datensatz dabei helfen, verschiedenste Aspekte abzubilden, die unter der Verwendung eines einzigen Modells unberücksichtigt geblieben wären. Warum die Stückliste, auch Bill of Materials (BOM) genannt, ein solcher Datensatz ist und warum Graphendatenbanken für ihre Modellierung hilfreich sein können, wurde bereits in unserem letzten Blogbeitrag besprochen (hier nachzulesen).

Um die Vorzüge einer Graphendatenbank zur Modellierung von Stücklisten aufzuzeigen, wurde eine große Stückliste mit Produkten und deren Einzelteilen verwendet. Jedes Produkt und jedes Einzelteil besaß dabei verschiedene Eigenschaften wie Typ, Preis oder Hersteller (s. Abbildung 1). Diese Daten wurden im Rahmen des Projektes in eine Graphendatenbank geladen, zuvor mussten sie jedoch aus einem relationalen Datenbanksystem extrahiert und in ein für Graphendatenbanken lesbares Format gebracht werden.

Je nach Typ und Abfragesprache der Graphendatenbank ist das Ladeformat, in dem die Daten an die Datenbank geliefert werden, unterschiedlich. Ein jedoch häufig genutztes Ladeformat, dass auch für unseren PoC verwendet wurde, ist das Gremlin csv Format. Gremlin ist eine open-source Abfragesprache, die für verschiedene Graphendatenbanken wie Neo4j, OrientDB, DEX und Amazon Neptune verwendet werden kann. Für dieses Ladeformat ist es wichtig, dass die Objekte und ihre jeweiligen Eigenschaften in einer Datei, und die Beziehungen zwischen den einzelnen Objekten in einer zweiten separaten Datei abgelegt werden. Jedes Objekt und jede Beziehung benötigt dabei einen eindeutigen Identifier und ein Label, dass das Objekt oder die Beziehung einer Gruppe zuweist. Eigenschaften von Objekten oder Beziehungen können, wenn gegeben, ebenfalls definiert werden. Jede Eigenschaft, beispielsweise der Artikelname, entspricht dabei einer Spalte, deren Überschrift dem Format NameDerEigenschaft:Typ folgen sollte. Ein Auszug aus den Dateien, die für das Laden unserer Graphendatenbank verwendet wurden, zeigt Tabelle 1.

PoC-Architektur – Alles rund um die Graphendatenbank in der AWS

Zusätzlich zur Etablierung einer Graphendatenbank wurde auch eine benutzerfreundliche Abfrage und Analyseoberfläche in der Form eines interaktiven Dashboards entwickelt. Hierzu mehr im Blogartikel zu den Verwendungsmöglichkeiten von Graphendatenbanken (hier nachzulesen). Dies wurde mit Hilfe einer Umgebung des Cloud Computing Anbieters Amazon Web Services (AWS) verwirklicht. Die verwendete Architektur ist in Abbildung 2 schematisch dargestellt.

Wie in Abbildung 2 dargestellt, wurden die Produkte und ihre Einzelteile als Stückliste aus einem ERP-System extrahiert. Dazu legten wir die Daten im Amazon-Objektspeicher, dem Simple Storage Service (S3) ab, um sie für Amazons Graphendatenbanklösung Neptune nutzbar zu machen. Da Amazon Neptune ebenfalls die Abfragesprachesprache Gremlin unterstüzt, konnten die bereitgestellten Daten im Gremlin-Ladeformat eingelesen werden. Um die Daten vor Fremdnutzung und unerwünschten eingehenden Verbindungen zu schützen, befanden sich alle Bestandteile des Systems in einer isolierten Sektion der AWS Cloudumgebung, in einer sogenannten Virtual Private Cloud (VPC). Um lokal auf die Graphendatenbank zugreifen und so ein interaktives Dashboard nutzbar machen zu können, launchten wir eine Recheninstanz innerhalb des VPC, wodurch eine Verbindung über OpenVPN ermöglicht wurde. Des Weiteren stellten wir eine Verbindung zwischen Amazon Neptune und Amazon SageMaker, Amazons vollständiger verwalteter ML-Entwicklerplatform her, um kleinere Analysen auf den Daten zu ermöglichen, ohne die VPN-Verbindung nutzen zu müssen.

Performance Evaluation - je höher die Komplexität der Daten, desto besser die Performance

Um die Leistungsunterschiede zwischen Graphendatenbanken und relationalen Datenbanken wie Aurora MySQL besser verstehen zu können, wurden fünf Abfragen mit steigender Komplexität in der Abfragesprache MySQL erstellt. Die Abfragen reichten von einer einfachen Select-Anweisung an den Datensatz bis zu Abfragen, die ein, zwei und drei SQL-Joins erforderten. Die Abfragen wurden anschließend in den Python-Dialekt der Graph-Traversal-Sprache Gremlin übersetzt, die, wie bereits erwähnt, zur Abfrage der Amazon Neptune-Datenbank verwendet wurde.

Alle Abfragen wurden daraufhin an eine nicht optimierte Amazon Aurora MySQL-Datenbank, eine indizierte Amazon Aurora MySQL-Datenbank und die Amazon Neptune Graphendatenbank gesendet und die Ausführungsdauer der jeweiligen Abfragen aufgezeichnet. Jeder Abfragetyp wurde 100 Mal an die jeweiligen Datenbanken gesendet. Alle untersuchten Datenbanken verwendeten den selben Instanzyp.

In Abbildung 3 sind die Ergebnisse des Benchmarks dargestellt. Das Balkendiagramm zeigt, dass für einfache Abfragen und Abfragen, die eine SQL-Aggregate-Funktion enthalten, kein Leistungsgewinn beim Vergleich der Ausführungszeiten der drei Datenbanksysteme zu beobachten ist. Ein Leistungsgewinn wird erst bei Abfragen deutlich, die einen oder mehrere SQL-Joins benötigen. Hier zeigte sich eine Verbesserung in der Ausführungsdauer der jeweiligen Abfragen von bis zu 50% im Vergleich zur optimierten relationalen DB. Im Vergleich zur nicht optimierten relationalen DB, zeigte sich sogar eine 84%ige Verbesserung in der gebrauchten Zeit.

Das Balkendiagramm veranschaulicht deutlich den Punkt, an dem eine Implementierung einer Graphdatenbank sinnvoll ist. Für die Abfrage stark vernetzter Daten, die rechen- und speicherintensive Join-Operationen erfordern würden, ist die Organisation der Daten in Graphdatenbanken wie Amazon Neptune eine geeignete Lösung, insbesondere wenn man an einer Steigerung der Abfrage-Performance interessiert ist. Bei einfachen Abfragen ist dieser Leistungsgewinn jedoch vernachlässigbar. Generell gilt: Je stärker die Daten miteinander verbunden sind, desto größer ist der Performance-Vorteil, den eine Graphendatenbank bietet.
Lesen Sie in Teil 3 unserer Blog-Reihe, welche Verwendungszwecke sich für Graphendatenbanken anbieten. 

Haben Sie schon einmal über den Einsatz einer Graphendatenbank nachgedacht? Die Hürde ist viel kleiner, als Sie vielleicht im ersten Moment glauben, denn:

Wir bringen den Prototyp gleich mit!

Unser Vorschlag: Starten Sie doch einfach einmal mit einem Prototypen – die notwendige Infrastruktur und die Komponenten bringen wir mit und erzielen damit schnell erste Ergebnisse!

Wir bringen die Daten aus Ihren Systemen in die Analytics Workbench in der Cloud und schaffen mit dem Five1 Deep Analytics Explorer (DAE) die Basis für Ihre Impact-Analyse. So können Sie ihre Daten interaktiv abfragen und Auswirkungsanalysen schnell und einfach durchführen. 

In unserem Flyer "Five1 DAE" haben wir die wichtigsten Funktionen und Vorteile einer Lösung mit einer Graphendatenbank noch einmal zusammen gefasst.

Sie wollen tiefer mit uns in die Materie eintauchen? Kontaktieren Sie uns für ein unverbindliches Beratungsgespräch!