Graphdatenbanken

Oliver Tigges: Hallo Stefan.

Stefan Tilkov: Oliver, wie immer: erzähle uns doch am Anfang ganz kurz, wer du bist und was du bei uns machst!

Oliver Tigges: Hallo, ja. Meine Name ist Oliver, ich bin bei innoQ als Principle Consultant für Softwareentwicklung und -architektur tätig. Und mein Schwerpunktbereich ist die große, weite Welt von Java-Enterprise und dem Web. Ja und heute geht’s aber um Datenbanken, Graphendatenbanken.

Stefan Tilkov: Ok. Bevor wir über Graphendatenbanken reden, wäre es vielleicht nicht schlecht, wenn wir mal über Graphen reden und so ein bisschen die Kenntnisse auffrischen. Bei dem ein oder anderen ist vielleicht noch etwas hängen geblieben, so wie bei mir. Allerdings auch ehrlicherweise nicht all zu viel. Erzähl uns doch mal ein bisschen, was Graphen denn eigentlich sind.

Oliver Tigges: Ja, also im ganz Allgemeinen ist ein Graph einfach eine sehr generische oder die generischste Form, Informationen zu repräsentieren. Die besteht aus zwei sehr einfachen Elementen. Das eine sind die Knoten. Das was man auf einem Whiteboard üblicherweise als Kreis oder Kästchen malen würde und was ein Ding aus der realen oder gedachten Welt repräsentiert. Das könnte also z.B. eine Person sein oder ein Bestellvorgang oder ein Produkt, könnte aber auch was ganz einfaches sein – so ein primitiver Datentyp – wie z.B. eine Datumsangabe oder vielleicht auch nur eine Zahl. Und das zweite Element, das sind die Kanten, die Knoten miteinander verbinden können, also dann die Beziehung zwischen zwei Knoten angeben. Z.B. zwischen zwei Personen oder eine Person einem Bestellvorgang zuordnen. Und ja darüber hinaus gibt es noch viele weitere Dinge, die man da hinzufügen kann, zu dem Graphen. Z.B. Beschriftungen, um die Beziehung genauer zu beschreiben, indem man z.B. sagt: “Diese Person hat dieses Produkt bestellt”. Und man kann natürlich auch die Knoten weiter Beschriften und Attribute hinzufügen, theoretisch. Man kann die Knoten gewichten. Ja, das sind letztendlich mal so die Basics zu der Graphen-Theorie.

Stefan Tilkov: Hmhm. Wie lange gibt es Graphen?

Oliver Tigges: Ja, also – jetzt generell die Graphen-Theorie – wird teilweise Leonard Euler schon im 18. Jahrhundert, also vor ungefähr 300 Jahren, da als der Entwickler der Graphen-Theorie dargestellt. Das war natürlich weit vor der Zeit der Computer und das, was wir eigentlich mit Graphen-Theorie verbinden, das ist wahrscheinlich mit Edsger Dijkstra entstanden. Der hat diesen berühmten Dijkstra-Algorithmus u.a. entwickelt, mit dem man die kürzeste Entfernung, den kürzesten Pfad zwischen zwei Knoten in einem großen Graphen berechnen kann und das ist jetzt natürlich auch elementar z.B. in Navigationsgeräten, um da den kürzesten Weg zu finden.

Stefan Tilkov: Genau. Damit sind zumindest alle, die mal irgendwie was Informatik studiert haben, gequält worden.

Oliver Tigges: Genau.

Stefan Tilkov: Wenn wir nicht mehr allgemein über Graphen reden, die was sehr sehr generischen sind – wie du schon gesagt hast –, sondern über Graphen- Datenbanken, was muss man da noch mehr wissen über das hinaus, was du gerade gesagt hast?

Oliver Tigges: Genau, also wenn man jetzt weg geht von diesem ganz Generellen, was jetzt theoretisch natürlich überall vorkommen könnte in der IT. Z.B. auch Git benutzt ja einen direkten, einen gerichteten, azyklischen Graphen um seine Historie darzustellen. Aber wir sprechen jetzt von Graphendatenbanken. D.h., wir meinen hiermit jetzt wirklich Datenbankmanagementsysteme, die so wie die anderen DBMS, die wir kennen, online verfügbar sind, in Transaktionen arbeiten können und wir können da drin – jetzt in dem Fall – Graphen anlegen, Graphen aktualisieren, erweitern, verkleinern, Graphen löschen. Wir können da drin suchen und wir können, was jetzt natürlich für Graphendatenbanken insbesondere interessant ist, auch Sub-Graphen finden, wir können traversieren über Knoten usw.

Stefan Tilkov: Ok, also dann sind wir im Prinzip schon genau bei dem Thema Abgrenzung gegenüber “klassischen Datenbanken”. Also wenn ich jetzt ein “normales RDBMS” habe, also eine relationale Datenbank, was genau sind die Unterschiede zu einer Graphendatenbank von der offensichtlichen abgesehen? Also natürlich ist das eine eine Relation, das andere ein Graph, aber was bedeutet das ganz konkret?

Oliver Tigges: Ja, genau. Also sagen wir erstmal, eine relationale Datenbank organisiert ja ihre Daten und strukturiert die in Tabellen, Spalten und Zeilen. Das ist also jetzt erstmal eine sehr fest vordefinierte Struktur. Die Tabellen können über Relationen auch miteinander verknüpft werden. Natürlich kann man darüber jetzt genauso logisch erstmal genauso die gleichen Beziehungen abbilden, wie wir es gerade besprochen haben. Z.B. wieder zwischen Person und Bestellung oder sowas. Und in einer Graphendatenbank, klar, da gibt’s eben auch nur die Elemente, die gerade jetzt auch für den Graphen dargestellt worden sind. Da gibt es jetzt erstmal nur Knoten und Kanten. Und was es noch dazu gibt, zumindest mal für den elementaren oder den wichtigsten Bereich der Graphendatenbanken – das sind die sogenannten Property-Graphen, dazu gehören z.B. Neo4J oder OrientDB – da kann man dann zusätzlich zu diesen Knoten und Kanten beliebig viele Attribute hinzufügen, um natürlich die ganzen Stammdaten einer Person oder eines Produkts noch darin zu erfassen und auch einer Relation, also einer Kante noch ein paar Meta-Informationen mitzugeben.

Stefan Tilkov: Was hat das denn für Konsequenzen? Oder lass mich andersrum fragen: was ist sozusagen darüber hinaus noch ein typischer Unterschied? Würdest du noch andere Dinge sehen oder ist das im Prinzip der einzige und entscheidene Punkt? Das Datenmodell, welches ich unten drunter habe.

Oliver Tigges: Also es gibt, genau. Das hat natürlich wahrsinnig viele Konsequenzen, weil wenn man jetzt einfach in der relationalen Datenbankwelt arbeitet, sich damit auskennt, auch allein das ganze Tooling, was man nachher hat, wenn man OR-Mapper denkt. Fast alles muss natürlich irgendwie ganz neu gedacht, neu erfunden werden, wenn man jetzt ganz neu in die Graphen- Datenbankenwelt einsteigt. Natürlich gibt es da auch wieder ganz viel, also natürlich muss man nicht alles wieder ganz neu erfinden.

Stefan Tilkov: Es ist ja auch nichts neue, ne? Graphendatenbanken sind ja nicht letztes Jahr entstanden, die gibt es ja auch schon ein bisschen länger.

Oliver Tigges: Genau, die gibt es auch schon länger, auch Neo4J gibt es theoretisch, glaube ich, schon seit zehn, elf Jahren. Wobei die erst so richtig öffentlich verfügbar als Open Source und so Mainstream seit fünf Jahren jetzt vielleicht angekommen sind. Ja. Ne klar, da ist es jetzt nicht so, dass man alles neu, die Tools neu entwickeln müsste. Aber es ist eben schon so, dass von der Sache natürlich alles ganz anders funktioniert. Es gibt z.B. – bis auf Ausnahmen – gibt es jetzt natürlich auch kein SQL mehr oder in dem Sinn. Oder man kann jetzt auch seinen Graphen nicht mehr mit SQL abfragen, sondern entweder macht man das programmatisch, indem man wirklich sich einen Knoten schnappt und über die Relationen iteriert, den Graphen entlang wandert und sich die Informationen heraus sucht oder ergänzt oder aktualisiert, an denen man eben gerade interessiert ist. Oder klar, es gibt natürlich auch spezielle Abfragesprachen, die neu erfunden worden sind, die quasi analog zu SQL sind und spezifisch für Graphendatenbanken sind.

Stefan Tilkov: Was ist mit anderen Datenbanken? Also zunächst mal, wo würdest du Graphen- Datenbanken einsortieren? In die NoSQL-Welt?

Oliver Tigges: Ja. Also offiziell, wenn man das so sagen kann, sind sie da ja einsortiert, im großen Bereich der NoSQL-Datenbanken. Das war sicher auch dem Hype geschuldet, dass ganz plötzlich z.B. sowas wie Neo4J ganz groß bei sich hatten “Wir sind auch eine NoSQL-Datenbank – weil wir benutzen ja kein SQL.” Sicherlich passt es auch irgendwie in die Kategorie, je nachdem welche Definition von NoSQL man sich anguckt. Das wichtigste ist ja immer dieser Schema-freie Ansatz. Und das trifft natürlicha auch erstmal auf eine Graphen- Datenbank zu. Da gibt es jetzt eben nicht so ein Datenbankschema, was man fest vorher ausdefiniert hat: das sind meine Entitätstypen, die haben diese Spalten oder diese Attribute mit diesen konkreten Wertebereichen und es gibt noch diese Constraints. Das gibt es für so eine Graphendatenbank erstmal genauso wenig, wie für eine Dokumenten- Datenbank oder für einen Key-Value-Store. Insofern passt es ganz gut. Klar, natürlich ist der Bereich jetzt wahnsinnig groß. Also ich habe letztens was gesehen, dass auch OpenLDAP in den Bereich der NoSQL-Datenbanken eingereiht wird, was natürlich diese Kategorie letztenendes irgendwann ad absurdum führt, wenn alles dazu gehört. Deswegen ist das natürlich auch wieder fraglich. Also es hat natürlich wieder andere Eigenarten. Also ich würde sagen, eine Graphen- Datenbank ist quasi genauso weit weg von einem Key-Value-Store, wie von einer relationalen Datenbank.

Stefan Tilkov: Ok. Sollen wir das noch abgrenzen gegenüber den anderen NoSQL-Datenbanken? Hast du eigentlich schon gemacht, so implizit. Also du hast vom Datenmodell gesprochen, es gibt Dokumenten-Datenbanken, Key-Value-Datenbanken, Spalten-orientierte Datenbanken, als Unterschied vom Datenmodell her. Würdest du die typischen Graphendatenbanken auch noch anders abgrenzen gegenüber den sonstigen NoSQL-Datenbanken oder ist das Datenmodell das Wichtigste und Entscheidenste?

Oliver Tigges: Wahrscheinlich gibt es da jetzt noch ein paar Dinge, die mir jetzt gerade nicht einfallen. Primär sicherlich ist der Fokus eben das, wie man die Daten abbildet. Ja.

Stefan Tilkov: Ok. Dann sind wir ja im Prinzip jetzt in der Welt, wo es darum geht, sich mal zu überlegen, warum man sowas benutzen sollte. Also es gibt ja viele Dinge, die vielen Argumente für eine relationale Datenbank – die Diskussion führen wir auch häufiger, dafür oder dagegen. Einige hast du schon gesagt: es ist erprobt, es kennt jeder, da weiß man, wie das geht und worauf man sich einlässt und es gibt das Tooling, was man gut finden kann oder nicht so gut finden kann, egal. Aber es gibt auf jeden Fall einen ganzen Haufen an Dingen. Warum würde man eine Graphendatenbank einsetzen wollen?

Oliver Tigges: Ja, genau. Also ich gebe vielleicht erstmal so einen Überblick und dann kann man nachher nochmal im Detail drauf gehen. Also die typischen Argumente, die da hervor gebracht sind, die ich auch selber sagen würde “Ja, das trifft auch immer zu.” – vielleicht nicht immer ganz generell, aber für bestimmte Problemgebiete, wo man sagen kann “Es gibt eben einfach Szenarien, da ist eine Graphendatenbank von der Performance her viel besser geeignet.” Gerade mit großen Datenmengen in bestimmten Strukturierungen, wenn eben Beziehungen im Vordergrund stehen, wo eine Graphendatenbank einfach bestimmte Probleme deutlich, also um ein vielfaches schneller lösen könnte, als eine relationale Datenbank.

Stefan Tilkov: Gibt doch mal ein konkretes Beispiel, was für eine Art von Daten würden wir mit einer Graphendatenbank sehr, sehr viel schneller abfragen können, als mit einer relationalen Datenbank?

Oliver Tigges: Also das klassische Beispiel – vielleicht schon ein bisschen überstrapaziert, weil es ja auch in der Enterprise-Welt weniger vorkommt – aber das ist jetzt z.B. der soziale Graph oder das soziale Netz, was man sieht zwischen Personen oder vielleicht auch Unternehmen und Organisationseinheiten, die man alle miteinander verbinden kann. Also wie bei Facebool, Twitter, Xing usw. Da ist es ja jetzt so, dass wirklich die Beziehungen im Vordergrund stehen. Also es geht nicht darum, dass jetzt die Struktur der Person an sich relevant ist, natürlich müssen auch die Stammdaten drinnen sein, aber letztendlich geht es um die Beziehung und die gehen eben über mehrere Ebenen. Also es ist jetzt nicht so, dass einfach eine Relation zwischen zwei Klassen besteht, sondern die Personen beziehen mehrfach auf sich selber, um z.B. so eine Kette von sechs Personen in einer Reihe darzustellen. Und in so einem Bereich, das kann man natürlich in einer relationalen Datenbank abbilden, also dass man sagen kann “Eine Tabelle referenziert sich quasi selber, und das mehrfach und mehrfach und mehrfach.” und man joint die Tabelle dann z.B. sechs Mal aneinander. Wenn man sich jetzt vorstellt, man hat halt theoretische eine Tabelle mit 1.000.000 Datensätzen und man sagt 1.000.000 hoch sechs, dann kommt eine – ich will das gar nicht raten, wie viele Trillionen das vielleicht nachher sein könnten – unglaublich hohe Zahl raus. Und selbst wenn die Datenbank natürlich über den Index geht und da optimieren kann usw., kommt man da sehr schnell einfach in Bereiche, wo eine relationale Datenbank dann irgendwann aussteigt. Also das typische ist, kann man sagen, in ganz einfachen Szenarien, wenn es noch um zwei oder drei Ebenen geht, dann hält die noch sehr gut mit, mit Graphendatenbanken. Es gibt aber auch so Beispiele, wenn nachher eine vierte oder fünfte Ebene kommt, dann bleibt es bei der Graphendatenbank – da können wir gleich auch nochmal zu kommen – erstaunlicherweise relativ konstant, also dass ist kaum ein Unterschied macht, wenn jetzt nochmal eine ganze Ebene hinzukommt – also potentiell alles mit 1.000.000 multipliziert wird. Während dann die relationalen Datenbanken ganz schnell in den Bereich von Minuten oder halbe Stunde kommen und bei sechs Ebenen es sehr oft – zumindest mal so in den klassischen Beispielen oder so was eben, die natürlich sicherlich auch ein bisschen immer gefärbt sind, um die Vorteile der Graphendatenbank vorzuzeigen – aber da steigt die relationale Datenbank meistens bei sechs Ebenen aus.

Stefan Tilkov: Das ist die eine Dimension, also die Anzahl der Hops sozusagen. Also ich will jetzt irgendwie wissen, über wie viele Wege mit maximal sechs Hops kann ich irgendjemanden erreichen oder so. Ne, das wäre so eine Abfrage in so einem Social Graph. Was ist mit der Menge der Elemente, die da drin sind? Also wenn du jetzt sagst, 1.000.000. Was ist wenn da nur 10.000 Personen drin sind oder 100.000 oder 20.000.000?

Oliver Tigges: Ja. Das ist – genau, da müsste man jetzt ein bisschen kommen vielleicht mal auf den Unterschied zwischen diesen Relationen in der relationalen Datenbank und den Beziehungen in so einer Graphendatenbank. In der relationalen Datenbank – klar, wie der Name auch schon sagt – ist sie natürlich auch dafür geeignet, Relationen zwischen Dingen auszugeben. Das ist jetzt aber natürlich sowas sehr Allgemeines. Also theoretisch selbst wenn man nachher sagt, in unserem impliziten Modell, was wir irgendwo haben, sagen wir eigentlich: zwischen denen und denen und denen Tabellen wollen wir nachher Beziehungen ausdrücken und die wollen wir aneinander joinen können. Einer relationalen Datenbank der ist es erstmal egal, welche Tabellen wir miteinander in Beziehung setzen.

Stefan Tilkov: Ist nicht in einer relationalen Datenbank die Relation auch die Menge, sozusagen das N, die Menge der Attribute, die ich zusammen packe? Ich frage mich gerade, ob nicht die Relation sozusagen das ist, was zwischen zwei Tabellen besteht? Oder ob die Relation einfach die Menge der Attribute ist, egal wo ich die raus selektiert habe? Von der Namensgebung her.

Oliver Tigges: Achso. Ja kann schon sein, dass es auch auf Spalten noch zutrifft. Ich hätte es jetzt einfach so gesehen, dass die Relation eben einfach das ist, wenn ich zwei Tabellen joine.

Stefan Tilkov: Ok, ok. Also sorry, ich wollte dich wirklich nicht aus dem Konzept bringen. Wir waren bei der Frage, was das Performance-mäßig bedeutet.

Oliver Tigges: Ja, also wir können einfach beliebige Tabellen letztendlich miteinander in Verbindung setzen und dann über irgendein Attribut, über irgendeine Zuweisung können wir dann sagen, welche Dinge tatsächlich zusammen gehören. Z.B. über so einen ON-Constraint. Wenn wir einfach sagen, hier diese Person hat irgendwie – ne, die Bestellung wäre es üblicherweise. Die Bestellung hätte jetzt also eine logische ID, wo dann eine Personen-ID drin steht und darüber würde sie dann drauf verlinken und wir könnten die Sachen laden. Hier ist es jetzt aber natürlich so, dass es eine logische Verknüpfung ist. Also letztendlich, die Datenbank selber weiß ja gar nicht, dass da jetzt tatsächlich – also selbst wenn wir den Foreign-Key-Constraint gemacht haben, dann sorgt sie zwar dafür, dass eine gewissen Integrität bewahrt wird, aber sie optimiert jetzt normalerweise ja nicht, dass diese Beziehung möglichst schnell gemacht werden kann, über einen Index-Zugriff hinaus. Das heißt, wenn ich jetzt so eine Abfrage mache, erstmal auf die Bestellung, dann lade ich erstmal wirklich den Wert, also die logische ID über die Bestellung, mache dann nochmal einen Index-Lookup und anhand des Index-Lookups komme ich dann irgendwann auf die physikalische Adresse dieser Zeile oder dieses Eintrags und kann den dann laden. Und das führt natürlich auch dazu, diese Indirektion und dieser Index-Lookup, dass erstmal eine längere Laufzeit da ist. Und potentiell wächst natürlich dann auch, der Index-Lookup dauert natürlich auch länger und alles wird ein bisschen komplizierter nochmal, wenn einfach mehr Datensätze in der Datenbank dann stehen. Also wenn ich plötzlich nicht mehr 10.000 Bestellungen habe, sondern 10.000.000 Bestellungen. Und in der Graphendatenbank ist es tatsächlich so, dass auf diesen Index da oder diese Indirektion verzichtet wird. Da ist es üblicherweise so, wenn da eine Relation besteht – also jedenfalls, naja da gibt es jetzt natürlich viele Datenbanksysteme, Graphendatenbanksysteme – aber bei den Neo4J ist es z.B. auch so, dass da wirklich die Relation direkt physikalisch auf den nächsten Knoten verweist. Also da besteht – diese Relation verweist wirklich physikalisch auf zwei Knoten und wenn ich den einen Knoten geladen habe, habe ich direkt die physikalischen Pointer auf die nächsten Knoten und habe die quasi direkt in der Hand. Und deswegen ist es auch relativ egal, wenn ich jetzt eine Person oder ein Kundenobjekt habe und der hat zehn Verweise auf eine Bestellung, dann ist es egal, ob da in der Datenbank noch 10.000.000 andere Kunden und Milliarden von anderen Bestellungen sind, mich interessiert in dem Fall wirklich nur dieses lokale, dieser kleine lokale Datensatz.

Stefan Tilkov: Das heißt dann im übertragenen Sinne, wenn ich jetzt über mehrere Hops gehe, dann entscheidet das vielleicht noch, weil ich muss jetzt wenn ich über fünf Hops gehe, muss ich fünf mal diesem Pointer folgen, aus dem Objekt laden, und dann dem Pointer folgen und das Objekt was ich geladen habe, da wieder dem Pointer folgen usw. Das heißt, wenn ich von fünf auf sechs auf sieben gehe, wird es länger dauern. Vielleicht nicht viel, aber ein bisschen. Aber ob daneben eben noch andere liegen, spielt dann keine Rolle. Also es bestimmt nur die Länge des Pfades, den ich sozusagen entlang navigiere, über meine Performance und nicht die Menge der sonstigen in der Datenbank noch rum liegenen…

Oliver Tigges: Ne, dann haben wir uns jetzt gerade falsch verstanden. Sondern das ist, das gehört natürlich schon dazu, weil ja eben diese lokale Speicherung in der Graphendatenbank ist und ich sofort, wenn ich einen Knoten lade, die Relationen direkt im Zugriff habe und ich muss eben nicht nochmal quasi über einen Index oder etwas anderes gehen und alle anderen Daten mitladen um sie rauszufiltern.

Stefan Tilkov: Ne, wir haben uns vielleicht wirklich missverstanden. Ich habe gedacht, wenn ich jetzt z.B. über mehrere Hops die Personen finden will, irgendwie ich will wissen, welche Personen oder kann ich diese Personen über jemand anderen erreichen? Oder gibt es zwei Freunde, die mir dabei helfen können, diese Person kennen zu lernen? Gibt es einen Weg von mir zu dieser Person? Dann muss ich doch diese Wege – ach da gibt es bestimmt wieder irgendeinen Algorithmus, der mir dabei weiter hilft, um das klüger auszuwählen – aber wenn ich das Brute-Force mäßig navigieren will, dann gehe ich von meiner Position aus zu einer nächsten Position und navigiere sozusagen von da aus immer eine konstante Menge an Hops irgendwie weiter. Und dann ist es doch egal, ob da noch andere auch noch irgendwelche Pointer irgendwohin haben.

Oliver Tigges: Genau, ja. Das stimmt, ja.

Stefan Tilkov: Ok, gut. Also wir haben das an dieser Stelle. Das heißt, wenn wir jetzt so einen Social-Graph haben, dann ist so eine Datenbank eine tolle Idee. Jetzt ist – das hat mich schon häufiger irritiert – ist es aber so, dass gerade die Websites, die große Social-Graphs haben, keine Graphendatenbanken benutzen. Also sowas wie Facebook ist ein gutes Beispiel, die machen irgendwie MySQL mit 10.000 Servern. Hast du irgendeine Idee, warum die das machen?

Oliver Tigges: Ich denke mal, also – gut, das ist natürlich eine reine Mutmaßung, aber ich würde bei sowas halt immer vermuten, dass es eben einfach damals gestartet worden ist zu einem Zeitpunkt, als man sich noch gar keine Gedanken darüber gemacht hat und sobald man einmal mit einer relationalen Datenbank gefahren ist, wird man wahrscheinlich erstmal dabei bleiben, eine ganze Zeit lang. Ob da jetzt Bestrebungen im Gange sind, das zu ändern, das weiß ich jetzt ehrlich gesagt gar nicht. Ich denke mal, das könnte natürlich sicherlich eine ganz interessanter Ansatz sein.

Stefan Tilkov: Anders gefragt: wenn ich jetzt keinen Social-Graph habe, hat das dann immer noch irgendeinen Sinn für mich oder sind es wirklich genau diese – wie du schon gesagt hast – etwas abgenutzten, ausgelutschten Beispiele, die interessant sind?

Oliver Tigges: Das ist natürlich so das klassischste Beispiel. Aber ich glaube auch im Unternehmensumfeld wird man immer wieder auf sowas stoßen, wo relationale Datenbanken im Grunde nicht, wo man nicht natürlich das abbilden kann – das wäre jetzt vielleicht der zweite Punkt auch schon so ein bisschen, neben der Performance, aber die Performance spielt da auch noch mit rein. Ich erinnere mich z.B. an sowas, da hatten wir mit unglaublich vielen Bilanzdaten mal in einem Projekt zu tun. Also ganz viele Konzerne und Unternehmen wurden da verwaltet, von denen alle Bilanzdaten und an den Bilanzdaten hingen die einzelnen Bilanzpositionen, weil die für bestimmte Berechnungen gebraucht werden wollten, sollten die eigentlich nochmal rausgezogen werden aus den Bilanzdaten, so dass man dort auch nachher Milliarden von Bilanzdatenpositionen hatte. Und das wäre prinzipiell sicher auch ein gutes Beispiel gewesen, wo man eine Graphendatenbank angeben könnte, um diese Relationen oder diese Beziehungen quasi von Kunden zu Bilanzen bzw. Bilanzpositionen darzustellen, um ganz schnell z.B. auf sowas zu kommen, wie eine Bilanzsumme oder irgendwas aus der Gewinn- und Verlustrechnung und irgendwelche relevanten Kennzahlen. Wo die relationale Datenbank dann irgendwann schon wieder Probleme macht. Jetzt immernoch aus der Performance-Sicht und wo wir nachher dann z.B. hingegangen sind und die normalisiert haben, also Bilanzpositionen wieder zurückgezogen haben in die Bilanz rein, obwohl das eigentlich nicht natürlich war und das widergespiegelt hat, sondern einfach aus Performance, um nicht so große Joins zu haben. Weil sonst jedes Mal für jede Bilanz einen Join auf eine Bilanzdatenposition-Tabelle mit Milliarden von Einträgen gemacht werden musste. Und ähnlich sieht es glaube ich auch im TelKo-Bereich aus, ne? Also wenn man da über Verbindungsdaten oder so was spricht, was auch potentiell, wo sehr viel sicherlich auch immer einen Graphen-Charakter hat. Also was jetzt nicht natürlich immer in ein relationales Modell rein passt, sondern auch zu einer Graphendatenbank passt, da kann es dann auch immer sein, dass man da deutlich schneller ist, wenn man eben mit einer Graphendatenbank unterwegs ist.

Stefan Tilkov: Interessant, ok. Ich hätte jetzt nämlich erwartet, dass du solche Dinge, solche anderen Beispiele nennst, die einem auch irgendwie ins Auge springen. Was weiß ich, wie irgendein Modell in einem Case-Tool oder weißt du? Also irgendwie solche Dinge.

Oliver Tigges: Ja, ok.

Stefan Tilkov: Das sind die, wo ich mich immer frage, das ist relativ offensichtlich, dass das dafür passen würde und dann gerate ich in die Sackgasse und frage mich, gibt es denn irgendwas, wo eine Graphendatenbank nicht passt? Oder ist eine Graphen- Datenbank einfach immer die bessere Datenbank? Das kann ja irgendwie auch nicht sein.

Oliver Tigges: Ja. Genau, also prinzipiell etwas, wo es per se nicht passt, wird man wahrscheinlich nicht finden. Also alles kann man sicherlich immer auf einen Graphen zurückführen.

Stefan Tilkov: Kann man mit der relationalen Datenbank ja irgendwie auch, ja.

Oliver Tigges: Kann man damit natürlich auch. Jede Graphendatenbank kann auch über einen generisches Tabellen-Set mit Nodes und Vertices oder Edges könnte man es auch wieder abbilden. Insofern wird man da immer was finden. Aber klar, es gibt so Dinge, wo man jetzt sagen könnte, da macht es jetzt erstmal keinen richtigen Sinn oder es gibt jetzt zumindest keinen direkten Vorteil. Das sind jetzt eben immer so was wie, wenn man erstens mit überschaubaren Datenmengen zu tun hat, wo jetzt Performance-Gesichtspunkte über mehrere Hops keine Rolle spielen. Und wo es jetzt einfach darum geht, Daten strukturiert abzulegen. Das betrifft jetzt sicherlich nicht nur die Graphendatenbanken, sondern alle NoSQL-Datenbanken, die Schema-frei sind. Klar, da kann es manchmal eben sein, dass man einfach sagt, man will jetzt genau für seine Tabelle Kunde oder Unternehmenskunde und Privatkunde will man genau diese statische oder diese Tabelle haben mit der festen Struktur, wo man genau angeben kann: was sind die Pflichtfelder, welche Attribute müssen vorhanden sein, was für Datenbreiche habe ich da, was für Constraints liegen noch drauf. In so welchen Fällen ist es natürlich immer, genau, ist eine relationale Datenbank relativ dicht dran. Genau wie, wenn man mental sowieso in Tabellen denkt, also in Excel-Sheets, wenn man sich vorstellt, das optimale um so eine Reporting-Anwendung für Bilanzen darzustellen, wäre jetzt sowieso eine Tabelle, dann passt das natürlich auch perfekt zu einer relationalen Datenbank und dann ist es schon umständlich sicherlich sowas auf Knoten, Kanten und Attribute oder Properties runter zu brechen.

Stefan Tilkov: Ok. Du hast ein paar mal schon diese Schemafreiheit erwähnt. Warum ist die wichtig oder warum könnte die relevant sein? Für welche Fälle könnte die interessant sein?

Oliver Tigges: Ja, also da würde ich jetzt gar nicht sagen, dass das jetzt konkrete Anwendungsfälle sind. Das hat natürlich wahnsinnig viele Implikationen und da kann man viel drüber streiten, ob und wann es jetzt gut ist, ein Schema zu haben. Also wie gesagt, es ist natürlich schon was, die positiven Dinge dafür sind natürlich alleine schon, die jetzt für ein Schema sprechen würden, dass die Struktur explizit dargestellt ist, dass man explizit sagt, wie die Spalten heißen, was für Wertebereiche sie haben. Also kann jetzt nichts schief gehen, wenn man irgendwie was einträgt oder so, was jetzt in einer Schema-losen Datenbank natürlich passieren kann, dass da jemand aus Versehen oder aus Absicht und wie auch immer, Daten rein schreibt, die nicht ganz zu dem Schema passen oder zu dem implizierten Schema dann eben passen. Weil irgendwas gibt es ja schon immer. Irgendwer greift hier nachher auf die Attribute zu und wenn wir sie nicht explizit definiert haben, wie in einer relationalen Datenbank, dann stehen sie eben implizit im Source-Code oder in irgendeiner Dokumentation. Da gibt es natürlich immer Pro und Contra. Das kann natürlich auch Vorteile haben, diese Flexibilität, die man einfach hat, dass man einfach sagen kann, da ist jetzt nochmal etwas, das haben wir vielleicht nicht vorhergesehen und ich kann jetzt nochmal z.B. eine Beziehung hier zwischen zwei Entitäten anlegen, die so erstmal gar nicht von Anfang an gedacht war. Oder ich kann nochmal Attribute, Custom-Attributes, irgendwie hinzufügen, die ich vorher nicht bedacht habe. Und manchmal führt es natürlich auch dazu, dass es dann eine natürlichere Abbildung ist. Also z.B. wenn man sich sowas vorstellt, wo man sehr oft drauf läuft, wie Kunden verwaltet werden, wenn es jetzt Privat- und juristische Kunden sind, die in eine gemeinsamen Tabelle gelegt werden, dann hat man da sehr oft sehr viele Spalten, die eigentlich nur auf einen Fall zutreffen. Ganz viele Spalten sind immer nullable, was natürlich bei jeder Abfrage darauf muss man immer drauf achten, da könnte es jetzt auch mal sein, dass der Wert null zurück gibt. Und sehr oft werden dann auch Sachen wieder – klar, aus Gründen der Denormalisierung – werden die wieder zurück geführt, z.B. in dieser große Tabelle Kunden, anstatt dass man jetzt ein Attribut Telefonnummer hat oder zu E-Mail, wo man mehrere oder N Telefonnummern oder E-Mails hinterlegen kann, werden hier jetzt aus Denormalisierungsgründen, um wieder performanter zu sein, gibt es ja jetzt sowas wie Telefonnummer1, Telefonnummer, E-Mail1, E-Mail2 usw. Und das sind auch so Dinge, die hätte man natürlich in so einem Schema-freien Ansatz oder jetzt auch in einer Graphendatenbank, da hätte man die natürlich nicht. Da kann man sagen, man packt exakt die Daten, die eben relevant sind und die man haben will, packt man rein, an diesen Knoten. Und z.B. hier sowas wie eine Telefonnummer oder eine E-Mail oder eine Anschrift würde man auch sagen, könnte man natürlich schön abbilden als weitere Entität, als weiteren Knoten und da hat man halt auch immer eine 0 bis N Relation. Was man in einer Datenbank über eine N:M-Tabelle, gegebenenfalls – über solche Konstrukte, die es manchmal gibt, um sowas abzubilden, was da natürlich deutlich unnatürlicher ist, wieder zum mentalen Modell, was wir davon im Kopf haben.

Stefan Tilkov: Was mich natürlich irgendwie wieder zu der Frage bringt, wie frage ich so ein Ding denn ab? Also bei einer relationalen Datenbank wissen das irgendwie alle, wir machen ein SQL-Statement, ich kenne das Schema, ich weiß, was ich da wie zusammenbauen kann und wenn ich irgendwas referenziere, was nicht da ist, dann fliegt mir das eben um die Ohren, weil das als Syntax-Error sozusagen direkt erkannt wird, weil es die Spalte nicht gibt oder die Tabelle nicht gibt. Wir fragt man denn so eine Graphendatenbank ab?

Oliver Tigges: Also gehen wir jetzt mal von dem einfachen Fall aus, dass wir nicht sowas haben, wie ein Objekt-Graphen-Mapper, also so einen ORM-Pendant. Dann hätte man das natürlich auf Java-Seite oder auf Anwendungsseite wieder sicher gestellt. Genau, prinzipiell wie man damit arbeitet ist es eben wirklich, man muss sich erstmal seinen Einstiegsknoten finden. Das ist natürlich immer schon ein guter Punkt: wie findet man überhaupt diese erste Bestellung oder sowas oder die erste Person, von der man dann weiter navigieren will? Und generell bieten einem die Graphendatenbanken erstmal nur so eine Möglichkeit einen Knoten üblicherweise anhand seiner internen technischen ID zu finden. Die ist natürlich nicht hilfreich. Deswegen gehört fast immer dazu, nochmal sowas wie einen Index. Z.B. sowas wie Lucene, was einfach implizit mit drinne ist. Das kriegt man manchmal gar nicht mit, aber darüber hat man jetzt die Möglichkeit z.B. die Attribute direkt abzufragen und so eine Art Lucene-Query zu machen. Dass man sagt: gibt mir doch mal direkt die Personen mit diesem Namen oder mit dieser E-Mailadresse. Und wenn man die hat, kann man eben ganz normal – was heißt ganz normal – dann ist eben das klassische, dass man dann eben iteriert über die Relationen und zu den anderen Knoten springt usw. Das muss man jetzt nicht immer programmatisch machen, wenn man eben jetzt über drei Ebenen dann z.B. geht und was sucht, würde man üblicherweise jetzt nicht drei for-Schleifen ineinander schachteln, sondern z.B. in irgendeiner logischen Art eine Traversion beschreiben, die einem dann ein Ergebnis zurück gibt, das zu einem bestimmten Muster passt.

Stefan Tilkov: Hmhm, ok. Wie sieht es mit Query-Sprachen aus? Also mit so richtigen, sowas SQL-Ähnlichem?

Oliver Tigges: Ja. Also bei manchen Datenbanken, z.B. OrientDB unterstützt in einem gewissen Maße sogar SQL als Abfragesprache. Das passt nicht immer eins zu eins, es gibt natürlich auch immer so ein paar Einschränkungen, aber prinzipiell gibt es da sowas wie SQL. Bei anderen Sachen, Neo hat jetzt z.B. eine andere Sprache entwickelt, die nennt sich Cypher. Die finde ich auch eigentlich wahnsinnig gut, sieht wahnsinnig durchdacht aus. Es ist auch eine im Grunde noch proprietäre Sprache für Neo4J, über die man eben einen Start in seinen Knoten wieder definieren kann, z.B. über einen Index-Lookup. Und dann kann man auch wieder Pfade definieren, die man abfragen will und definiert, welches ResultSet, also welche Knoten will man nachher zurück haben. Das ist also so eine spezifische Abfragesprache, aktuell für Neo4J. Ein bisschen sieht man da vielleicht auch wieder, das Problem ist nicht wie bei SQL, was für alle Produkte aller Hersteller in einer gewissen Art oder zu 99% irgendwie standardisiert ist, sondern in der Graphendatenbankenwelt gibt es eben noch nicht diesen übergreifenden Standard, sondern da ist alles noch sehr Hersteller-proprietär.

Stefan Tilkov: Generell, was sind so Produkte? Du hast jetzt schon zwei Namen erwäht, Neo4J und OrientDB. Sind das die beiden, die du so hauptsächlich nennen würdest oder gibt es noch mehr, die relevant sind?

Oliver Tigges: Also ich sag mal, das sind jetzt so die beiden verbreitesten, auch Open- Source. Ich glaube es gibt noch wahrsinnig viele andere. Da fällt mir jetzt noch so Dex z.B. ein, als Dritte. Wobei ich da jetzt auch immer sagen würde, ich könnte jetzt nicht im Detail sagen, wo jetzt noch die Vor- und Nachteile sind. OrientDB, könnte man jetzt sagen, ist generell noch ein bisschen allgemeiner. Da könnte man auch Dokumente z.B. drin speichern. Neo4J ist diese klassische 100% Graphendatenbank und sicherlich auch am verbreitetsten, ja.

Stefan Tilkov: Ok, gut. Also wenn ich jetzt in meinem Projekt irgendwie entscheiden muss, was ich denn tue. Wenn ich mir Gedanken darüber mache, was ich baue. Muss ich mich dann entscheiden, eins von beidem zu verwenden oder siehst du Varianten, beides gemeinsam zu benutzen? Was heißt “beides gemeinsam” – verschiedene Datenbanken gemeinsam zu benutzen? Eine Graphendatenbank in Verbindung mit irgendwas anderem?

Oliver Tigges: Ja, prinzipiell kann man das natürlich machen. Genauso, wie man jetzt – auch früher schon – verschiedene Datenbanken verwenden kann, da gibt es ja auch das Pendant relationale Datenbank in Verbindung mit so einem Index wie ElasticSearch. Klar, das ist jetzt natürlich immer sehr spezifisch mit den ganzen Vor- und Nachteilen, denn es ist natürlich wieder sehr indirekt verlinkt. Es ist ja eigentlich nochmal – also da kann man wirklich nur noch verlinken und verliert dieses, wenn man wirklich rein in der Graphendatenbank drinne ist, wo alles physikalisch miteinander direkt verknüpft ist. Das würde natürlich dagegen sprechen.

Stefan Tilkov: Hmhm, ok. Was sind sonst so Themen, die man noch ansprechen könnte? Herausforderungen, besondere Probleme auf die man Laufen kann, wenn man so eine Datenbank benutzt?

Oliver Tigges: Genau, also schemafrei hatten wir schon besprochen. Das ist jetzt diese Grundsatzentscheidung, die man mal treffen will, ob man das so machen will oder nicht. Ein weiterer Punkt, wo ich öfters drauf gestolpert bin, was zumindest am Anfang erstmal so ein kritischer Punkt ist – grad im Versicherungs- und Bankenbereich, wo dann irgendwann die Frage nach Security hin kommt. Wo man sagen kann, in einer relationalen Datenbankwelt kann man wirklich teilweise sehr feingranular definieren, welche Datenbank-User auf welche Tabellen da welche Operationen ausführen dürfen. Z.B. dürfen die Tabellen lesen, dürfen die Tabellen gar nicht sehen, dürfen hier auch ändern und speichern usw. Das wird in den Graphendatenbanken üblicherweise nicht unterstützt. Klar, wie will man das auch genau machen? Also das ist sehr schwierig da jetzt Sub-Graphen zu definieren, wo man bestimmte Operationen drauf machen dürfte oder auch nicht machen darf. Also das ist sicherlich immer so ein Knackpunkt. Wobei man da natürlich auch sagen muss, in der relationalen Datenbankwelt ist es natürlich auch sehr oft so, dass man eigentlich technisch User nutzt, die wieder alles dürfen und man bildet die Security in der Anwendungslogik ab. Das würde man dann typischerweise auch bei so einer Graphendatenbank machen. Und sicherlich sowas, was auch nochmal öfters – zumindest am Anfang – die Sache schwieriger macht, bei relationalen Datenbanken und mit SQL, was irgendwie jeder kann, da fällt es meistens auch dem Fachbereich oder zumindest auch den Administratoren nicht schwer, selber auf die Datenbank drauf zu gucken, selber mal in die Datenbank reinzuschauen, irgendwas abzufragen. Vielleicht sich mal auch Aggregatfunktionen auszuführen, um sich mal ganz schnell eine Summe von irgendwas geben zu lassen. Das funktioniert.

Stefan Tilkov: Was zu ändern. Oder was zu korrigieren, was nicht ganz richtig ist.

Oliver Tigges: Was zu – genau – zu korrigieren. Wird natürlich auch immer gerne gemacht. Das geht prinzipiell natürlich auch bei den Graphendatenbanken. Also die haben meistens auch nochmal irgendwie eine Web-Konsole dabei, über die man letztendlich auch Cypher-Abfragen oder auch in anderen Datenbanken irgendwelche SQL-ähnlichen Abfragen starten könnte. Aber das ist eben, ja es ist eben doch irgendwie was anderes. Also ich glaube da fühlt man sich nicht ganz so erstmal zu Hause, wie das für einen Admin ist, wenn er einfach auf eine relationale Datenbank sich einloggen kann und kann sich die Tabellen direkt angucken.

Stefan Tilkov: Ok.

Oliver Tigges: Ja und dann gibt es vielleicht noch so ganz am Rande, als letzten Punkt würde ich sagen, sind auch so Dinge, sobald man mal damit gearbeitet hat, da findet man auch immer Lösungen für, aber das kommt einem am Anfang vielleicht etwas merkwürdig vor, weil es fehlen auf einmal Dinge wie eine natürlich Ordnung. Oder so eine einfache Sortierung. In der relationalen Datenbank hat man die eigentlich immer. Wenn man zwei Mal ein SELECT macht oder ein JOIN und man zeigt sich von irgendeinem Kunden jetzt z.B. wieder seine Bestellungen an, kommen die übrlicherweise immer in derselben Reihenfolge. Oder ansonsten kann man sehr einfach über so ein ORDER BY gibt man eben eine andere Reihenfolge an. Das ist teilweise ein bisschen schwieriger in einer Graphendatenbank. Weil da hängen einfach N Beziehungen zwischen den Entitäten und die sind erstmal haben die keine Reihenfolge und sowas. Sondern da muss man sich jedes Mal etwas eigenes überlegen, wie bildet man sowas jetzt da ab.

Stefan Tilkov: Wenn ich mir Graphendatenbanken angucke, dann erinnern die so ein bisschen an eine andere generische Möglichkeit, Sachen abzubilden, nämlich an Triples, an semantic web Technologie, RDF und Co. Kannst du das noch irgendwie abgrenzen, wie verhalten sich Graphendatenbanken zu Triple Stores?

Oliver Tigges: Ja. Da muss man auch ein bisschen aufpassen, weil nach manchen Definitionen sind Triple Stores auch einfach eine Unterkategorie der Graphendatenbanken. Da gibt es also die Unterkategorien Triple Stores und Property-Graphendatenbanken.

Stefan Tilkov: Aha, ok.

Oliver Tigges: Wir haben jetzt heute quasi immer nur über Property-Datenbanken gesprochen, weil ich das auch so ein bisschen als was anderes sehe. Genau, Triple Stores – du hast es jetzt gerade schon gesagt – dienen dazu, RDF semantic web Welt abzubilden. Also das heißt, sie bestehen aus Triples – Subjekt, Prädikat, Objekt –, wo man über zwei Ressourcen eine Aussage treffen kann.

Stefan Tilkov: Knote, Kante, Knoten – sozusagen.

Oliver Tigges: Letztendlich, genau, ist es letztendlich auch ein Graph oder sagen wir mal, die Statement an sich spannen einen Graphen auf. Wenn man jetzt wieder sagt, Subjekte und Objekte gleicher Identität bilden also den gleichen Knoten ab, hat man auch wieder einen Graphen. Ja und die Triple Stores sind natürlich dann letztendlich genau für diese Art von Graphen optimiert. D.h., es sind jetzt erstmal Graphen, wo die Beziehungen immer nur in eine Richtung gehen. Das haben wir eben gar nicht so explizit glaube ich erwähnt, aber in einer Graphendatenbank sind die immer bidirektional, also sind die tendenziell bidirektional. Also genauso leicht komme ich von der Person zu seinen Bestellungen, wie von der Bestellung zur Person. In einem Triple Store, bei den Statement sind die erstmal immer nur in eine Richtung. In die Richtung, in die das Statement eben geht. Ja, dafür sind die eben optimiert und können meistens noch so ein paar Features, so was ein bisschen in die Richtung Reasoning geht – also dass sie aus bestimmten Aussagen, die getroffen worden sind, weitere Aussagen implizieren können, die dann auch eben im Triple Store abgelegt werden.

Stefan Tilkov: Das gibt es bei Graphendatenbank nicht, sowas? So ein Reasoning?

Oliver Tigges: Also nicht. Als Add-On vielleicht oder als etwas, was man drauf setzt. Aber prinzipiell unten drunter, ne gibt es da jetzt kein Reasoning. Das ist jetzt wirklich speziell für diese Triple Stores oder für das semantic web. Und letztendlich ist das jetzt eben sowas, könnte man natürlich auch wieder sagen – da haben wir auch hier viele Diskussionen drüber geführt – wenn man jetzt eine semantic web Anwendung hat, nimmt man dann auf jeden Fall einen Triple Store, weil der ja genau dafür gemacht ist, oder macht dann auch vielleicht eine Graphendatenbank mehr Sinn? Ich glaube, da ist bisher noch niemand zu einer konsolidierten Meinung gekommen oder dass wir uns da jetzt alle einig gewesen wären. Also ich kann nur sagen, meine persönliche Sicht darauf ist eben immer sowas, dass ich eher, wenn ich ans semantic web denke, ich denke dann eben eher an einen großen Graphen, wo unglaublich viele Daten aus unterschiedlichen Quellen miteinander verknüpft sind und alle zusammen gehören. Und ich denke da jetzt nicht an eine Liste von Aussagen, die da jetzt erstmal stehen und theoretisch irgendwie einen Graphen aufspannen. Das ist aber sicherlich eher so ein bisschen persönliche Geschmacksfrage.

Stefan Tilkov: Wir machen ja seit – du hast schon drauf angespielt – wir machen schon seit einer Weile ein größeres Open Source Projekt, das so einen Thesaurus hat und da ist unten drunter der Data Store. Interessanterweise aber weder ein Triple Store noch eine Graphendatenbank, sondern eine relationale Datenbank. Und das Team streitet sich seit Menschengedenken darum, in welche Richtung es da gehen soll.

Ok, gut. Lass uns doch mal zu einem Fazit kommen. Also jetzt haben wir viel darüber geredet, was diese Dinger so können, was man theoretisch damit machen kann. Taugt das denn? Also würdest du das freiwillig benutzen wollen? Ich vermute, die Antwort ist “Ja”, aber vielleicht kannst du es ein bisschen begründen.

Oliver Tigges: Ja genau. Also ich würde es – klar – auf jeden Fall irgendwie benutzen wollen und bin mir auch relativ sicher, dass es in den meisten auch unternehmenskritischen Anwendungen, wo aktuell eine relationale Datenbank funktioniert, dass es auch weitestgehend genauso gut funktioniert, wenn die eben besprochenen Grundsatzentscheidungen dazu passen. Also dass man mit einem schemafreien Ansatz klar kommt, dass es von der Natur jetzt auch nicht in die Kategorie Excel fällt, sondern in die Kategorie – irgendwie – Beziehungen darstellen. Dann glaube ich schon, dass es eine sehr gute Lösung sein kann, auf jeden Fall. Wir haben jetzt natürlich hier bei innoQ auch schon verschiedenste Dinge ausprobiert, meistens in internen Projekten oder wo wir einfach mal wirklich auch Forschungsprojekte gemacht haben, wo wir mal ein paar Dinge ausprobiert haben und das klingt alles erstmal wahnsinnig gut. Was noch so aussteht ist sicherlich sowas, mal wirklich der Praxisbeweis, dass sich das in so einem Unternehmensumfeld, dass es auch eine langjährig bestehende Anwendung, wo man immer weiß “Die hat gewisse Macken” und die könnte man vielleicht mit eine Graphendatenbank lösen, dass man da wirklich mal die Gelegenheit hat, sowas wirklich mal zu beweisen, dass es funktioniert.

Stefan Tilkov: Ok, gut. Wenn man starten will, wenn man sich ein bisschen tiefer einarbeiten möchte in das Thema Graphendatenbanken, hast du ein paar gute Tipps?

Oliver Tigges: Ja. Also was ich da auf jeden Fall empfehlen könnte, ist ein Buch, was jetzt vor kurzem raus gekommen ist. Das heißt passend “Graph Databases”. Ist einfach von O’Reilly. Von drei Leuten von – ich meine, dass sie alle drei bei Neo Technology arbeiten oder zumindest an Neo4J arbeiten. Unter anderem Ian Robinson und Jim Webber. Und das gibt es eben auch als kostenloses PDF zum download. Also das wäre schon mal ein guter Einstieg, das hat so 200–300 Seiten, glaube ich. Und bietet einen sehr guten Überblick über Graphendatenbanken, auch genau die Themen, die wir so gerade besprochen haben. Wann setzt man sie ein? Warum setzt man sie ein? Wo liegen die Vorteile? Klar, natürlich noch mehr ein bisschen gefärbt. Einerseits, dass Graphendatenbanken natürlich ultimativ cool sind und auch, dass Neo4J insbesondere wahnsinnig toll ist.

Stefan Tilkov: Ganz klar.

Oliver Tigges: Aber trotzdem, es ist auf jeden Fall ein guter Einstieg. Und ansonsten würde ich auch die Neo4J-Seite generell so empfehlen. Die haben da wahnsinnig viele Präsentationen, Videos und Tutorials, wo man einfach ganz schnell rein steigen kann, in die Graphendatenbank-Welt. Und ansonsten klar, geht natürlich nichts darüber, einfach mal sich eins von den Tools – grad von den Open Source Tools – einfach mal runter zu laden, entweder Neo4J oder OrientDB, und damit auszuprobieren. Das finde ich zumindest so, die meisten die das gemacht haben, man stellt sich das am Anfang immer so wahrsinnig abstrakt vor, aber man kommt unglaublich schnell rein und kommt damit eigentlich sehr schnell zurecht. Also meiner Meinung nach lohnt es sich auf jeden Fall mal, da so einen Start hinzulegen.

Stefan Tilkov: Alles klar. Ok. Oli, vielen Dank. Danke an unsere Zuhörer, bis zum nächsten Mal.

Oliver Tigges: Ja, ciao.