Demnächst erscheint der SQLServer 2017. Im neusten Streich aus dem Hause Microsoft wird erstmals auch eine Graph-Database-Engine mitgeliefert. In diesem Artikel erhalten Sie kurz einen Überblick über Graphdatenbanken, wofür sie gebraucht werden und wie Sie Daten vom relationalen Modell in eine Graphdatenbank kriegen können.
Eine Graphdatenbank ist allgemein gesagt eine Ansammlung von Nodes und Edges. Dabei stehen die Nodes für Entitäten und Edges für Beziehungen. Die Nodes sind stets mit einem Unique-Identifier versehen und können beliebig viele Properties (Eigenschaften) enthalten. Die Edges, welche ebenfalls einen Unique-Identifier und Properties besitzen, verbinden jeweils einen Start- und End-Node. Diese Beziehungen können einseitig oder auch beidseitig dargestellt werden.
Abbildung 1: Beziehungen in der Graph DB
Im Gegensatz zu einer relationalen Datenbank werden Beziehungen als separate Objekte abgelegt. Gerade bei Use-Cases, wo es viele many-to-many Beziehungen gibt, spielen Graphdatenbanken ihre volle Stärke aus. Eine In-Shop Produktempfehlung wie z.B. bei Amazon wäre ohne Graphdatenbank-Technologie nur sehr schwer zu realisieren. Oder auch Abfragen für einen „Perfect-Match“ bei einer Dating-Plattform sind mit Graphdatenbanken unterstützt. Sie sehen gerade bei neuen, vernetzten Geschäftsmodellen, welche viele Entitäten aufweisen, bietet sich eine Graphdatenbank hervorragend an.
Im SQL Server 2017 werden die Nodes und Edges als Tabellen abgelegt. Die Tabellen sehen auf den ersten Blick normal aus, sie enthalten jedoch gewisse Graph-DB spezifische Felder. Die einzelnen Nodes erhalten jeweils ein calculated field: $node_id. Dies fungiert als Primärschlüssel für die Entität. Bei den Edges müssen wir uns mit drei spezifischen Feldern auseinandersetzen. Die $edge_id (welche als Primärschlüssel der Beziehung dient) die $from_id (welche den Node-Startpunkt definiert) und die $to_id (welche den Endpunkt-Node aufzeigt).
Ich möchte Ihnen anhand eines Beispiels das Vorgehen in SQL Server 2017 beschreiben, wie sie von einer klassischen relationalen Datenbank in eine Graph-DB gelangen. Als Datengrundlage diente ein CSV-File, welches die Top-500 Filme aus IMDB ausweist.
Zuerst wurden die Node- und Edge-Tabellen erstellt. Hierbei wurden zum Beispiel die Schauspieler und die Regisseure der jeweiligen Filme als einzelne Entitäten modelliert. Bei den Beziehungen wurde „wer spielt wo mit“ und „wer hat Regie geführt“ erfasst.
Abbildung 2: Create Node Tables
Abbildung 3: Create Edge Tables
Über einen zusätzlichen View-Layer wurden dann die Daten in die Node-Tabellen eingefügt. In Beispiel unten werden sämtliche Filme erfasst.
Abbildung 4: Insert Data into Tables
Anschliessend wurden die entsprechenden Beziehungen bestückt. Hier ist schön zu sehen, wie die dazugehörige node_id (von Actor und Movie) auf einen Datensatz gelegt wird.
Abbildung 5: Edge
Die Abfragen sind bei Graphdatenbanken enorm vereinfacht, gestalten sich sehr intuitiv und sind nicht mit komplexen Joins bestückt. Das Datenmodell ist, verglichen zu einer relationalen DB, viel flexibler und Datenveränderungen aus der realen Welt können agiler umgesetzt werden. Darüber hinaus sind die Queries auch bei grossen Datenmengen extrem performant.
SQL ist nicht die ideale Sprache für eine Graphdatenbank. Fast jeder Graph-DB Anbieter hat eine eigene individuelle Abfragesprache. Bei Neo4j kommt Cypher zum Einsatz, der SQL Server2017 hat eine Queryabfragesprache, welche Cypher sehr ähnlich ist.
Zum Schluss zeige ich noch ein paar Beispiel-Abfragen:
Mit der folgenden Query werden sämtliche Filme mit Johnny Depp angezeigt:
SQL Abfrage:
Abbildung 6: SQL Query
Graph-DB Query:
Abbildung 7: Graph-DB Query
Bei der untenstehenden Abfrage werden alle Filme der Co-Schauspieler von Al Pacino abgefragt. Die Beziehung vereinfacht die Abfrage enorm. Mit einer klassischen SQL-Abfrage wäre dieses Query um ein Vielfaches komplexer.
Abbildung 8: Complex Query
Je tiefer wir in hierarchische Strukturen eindringen, desto mehr Tabellen müssen bei einer klassichen SQL Abfrage dazu gejoined werden. Dies führt unweigerlich zu Performance Verlust. Generell kann gesagt werden, je komplexer das Query und die Beziehungen innerhalb werden, desto mehr können wir von einer Graphdatenbank profitieren!
Es ist ein guter und wichtiger Schritt, dass Microsoft in ihrem neusten Release eine Graph-DB-Engine mitliefert. Es ist jedoch eine erste Version und es fehlen meiner Meinung nach ein paar wichtige Features, wie z.B. Beispiel eine „shortest-path“ Abfrage-Möglichkeit (Abfragefunktion für den kürzesten Weg über mehrere Beziehungen zu berechnen) oder eine visuelle Ansichtsmöglichkeit.
So wie wir es von Microsoft kennen, werden sie mit Sicherheit schnell nachliefern, um die Graphdatenbank, gespickt mit neuen/zusätzlichen Features, noch viel mächtiger zu machen.