Graphdatenbanksysteme Überblick und Benchmark

Transkript

1 Graphdatenbanksysteme Überblick und Benchmark Diplomarbeit zur Erlangung des akademischen Grades Diplominformatiker Humboldt-Universitat zu Berlin Mathematisch-Naturwissenschaftliche Fakult at II Institut fur Informatik eingereicht von: Benjamin Raphael Gehrels geboren am: 10. September 1987 in: Heidelberg Gutachter: Prof. Dr. Ulf Leser Prof. Dr.-Ing. Stefan Edlich eingereicht am: verteidigt am:......

2

3 Zusammenfassung Netzartige Strukturen erfahren derzeit ein steigendes Interesse in der Informatik, sowohl im akademischen als auch im kommerziellen Bereich. Der Trend, die soziale Interaktion von Nutzern und die Ähnlichkeit ihrer Interessen zur Verbesserung von Onlinediensten zu nutzen, ist im kommerziellen Bereich der wohl einflussreichste Faktor soziale Netzwerke stellen hier eines der prominentesten Beispiele dar. Im akademischen Bereich lässt sich beispielsweise die Analyse von metabolischen Netzen und Protein-Interaktions-Netzen nennen. In den letzten Jahren kamen unter dem Stichwort NoSQL eine Vielzahl neuer Datenbankmanagementsysteme auf den Markt. Sie versuchen, bestimmte Probleme mit anderen als den dominierenden relationalen Datenmodellen und teils neuen Anfrageparadigmen besser zu lösen. In diesem Zusammenhang erfreuen sich auch Graphdatenbankmanagementsysteme steigender Popularität. Diese nutzen Graphen, eine mathematische Repräsentation von Netzen, als Datenmodell und versprechen Vorteile für die Speicherung und Analyse großer Netze. Diese Arbeit gibt einen Überblick über das Themenfeld der Graphdatenbankmanagementsysteme. Sie beginnt mit einer historischen Einordnung und definiert die mathematischen Grundlagen der verwendeten Datenmodelle. Anhand von vier exemplarischen Systemen Neo4j, FlockDB, HyperGraphDB und DEX wird anschließend ein funktionaler Vergleich verschiedener am Markt existierender Systeme vorgenommen: Welche Datenmodelle wurden gewählt, welche Anfragesprachen existieren, welche Indexstrukturen können genutzt werden, wie werden die Graphdaten persistiert, welche Ansätze zur Transaktionskontrolle werden unterstützt und wie skalieren die Systeme bei wachsenden Anfrage- oder Datenmengen? Der rein funktionalen Analyse wird ein Benchmark der untersuchten Systeme gegenübergestellt, welches die Geschwindigkeit von typischen Graphanfragen auf Graphen verschiedener Größe misst und vergleicht. Abgeschlossen wird diese Arbeit mit einer zusammenfassenden Einordnung der Erkenntnisse: Welche Konzepte und Systeme erweisen sich für welche Anwendungsgebiete als vorteilhaft und wo liegen ihre Probleme?

4 Inhaltsverzeichnis 1. Motivation Probleme bei der Nutzung relationaler Datenbanken zur Speicherung von Graphen Graphdatenbankmanagementsysteme als Alternative Related Work Ziel der Arbeit Historischer Hintergrund Grundbegriffe Graphen Hypergraphen Reguläre Pfadanfragen Reguläre Graphanfragen Graphdatenbankmanagementsysteme Eingebettetes Datenbankmanagementsystem Horizontale und vertikale Skalierbarkeit Überblick über verschiedene Graphdatenbankmanagementsysteme Neo4j Indexstrukturen Anfragemechanismen Transaktionen Persistenz und Caching Skalierbarkeit und Ausfallsicherheit FlockDB Anfragemechanismen Persistenz und Caching Transaktionen Skalierbarkeit und Ausfallsicherheit HyperGraphDB Indexstrukturen Anfragemechanismen Persistenz und Caching

5 Transaktionen Skalierbarkeit und Ausfallsicherheit DEX Anfragemechanismen Transaktionen Persistenz und Caching Indexstrukturen Skalierbarkeit und Ausfallsicherheit Zusammenfassung Benchmark Datengrundlage Typische Eigenschaften großer Graphen Generierung von Graphen Die generierten Daten Algorithmen Neo4j FlockDB HyperGraphDB DEX Experimentaufbau Neo4j FlockDB HyperGraphDB DEX Methodenkritik Ergebnisse Ergebnisse der einzelnen Algorithmen Gesamtergebnis Zusammenfassung Neo4j FlockDB HyperGraphDB DEX Ausblick A. Literaturverzeichnis 89 B. Messergebnisse des Benchmarks 96 C. Selbstständigkeitserklärung 120 5

6 Abbildungsverzeichnis 5.1. Beispiel eines gerichteten Multigraphen mit Kanten-Labeln und Knoten- Properties Beispiel eines gelabelten und gerichteten Multihypergraphen Schematische Darstellung einer zusammenhängenden regulären Graphanfrage mit 4 Variablen und 4 Ausdrücken Beispielhafte Darstellung einer Neo4j-Datenbank Beispielhafte Darstellung einer FlockDB-Datenbank Beispielhafte Darstellung einer HyperGraphDB-Datenbank Schematische Darstellung der Datenspeicherung von HyperGraphDB Beispielhafte Darstellung einer DEX-Datenbank Die Knotengradverteilung des generierten Benchmarkgraphen ( Knoten, 1 Mio Kanten) verglichen mit einer Power-Law-Distribution mit γ = 1, Visualisierung des im Rahmen des Benchmarks ausgeführten regulären Graphausdrucks: Gegeben der Knoten x, welche Knoten y und z sind mit diesem über einen Dreieckspfad mit den Labeln L1, L2 und L3 verbunden? Messergebnisse: Import eines Graphen mit variabler Anzahl Knoten und Kanten in verschiedene Datenbanksysteme Messergebnisse: Auslesen aller Kanten eines Graphen mit variabler Anzahl Knoten und Kanten bei kalten Caches aus verschiedenen Datenbanksystemen Messergebnisse: Auslesen transitiv inzidenter Knoten in einem Graphen mit variabler Anzahl Knoten und Kanten bei warmen Caches aus verschiedenen Datenbanksystemen Messergebnisse: Berechnung der starken Zusammenhangskomponenten eines Graphen mit variabler Anzahl Knoten und Kanten bei warmen Caches aus verschiedenen Datenbanksystemen Messergebnisse: Auslesen gemeinsamer inzidenter Knoten in einem Graphen mit variabler Anzahl Knoten und Kanten bei warmen Caches aus verschiedenen Datenbanksystemen Messergebnisse: Finden von Dreiecken in einem Graphen mit variabler Anzahl Knoten und Kanten bei warmen Caches aus verschiedenen Datenbanksystemen

7 Tabellenverzeichnis 6.1. Überblick der untersuchten Datenbankmanagementsysteme: Allgemeines, Datenmodell und Anfragemöglichkeiten Überblick der untersuchten Datenbankmanagementsysteme: Persistenz, Caching und Indexstrukturen Überblick der untersuchten Datenbankmanagementsysteme: Transaktionen und Verteilung B.1. Messergebnisse: Datenimport in Neo4j B.2. Messergebnisse: Auslesen aller Kanten aus Neo4j B.3. Messergebnisse: Berechnung der starken Zusammenhangskomponenten mit Neo4j B.4. Messergebnisse: Abfrage transitiv inzidenter Knoten auf Neo4j B.5. Messergebnisse: Abfrage gemeinsamer inzidenter Knoten auf Neo4j. 100 B.6. Messergebnisse: Suchen von Dreickspfaden in Neo4j B.7. Messergebnisse: Datenimport in FlockDB B.8. Messergebnisse: Auslesen aller Kanten aus FlockDB B.9. Messergebnisse: Berechnung der starken Zusammenhangskomponenten mit FlockDB B.10.Messergebnisse: Abfrage transitiv inzidenter Knoten auf FlockDB B.11.Messergebnisse: Abfrage gemeinsamer inzidenter Knoten auf FlockDB 106 B.12.Messergebnisse: Suchen von Dreickspfaden in FlockDB B.13.Messergebnisse: Datenimport in HyperGraphDB B.14.Messergebnisse: Auslesen aller Kanten aus HyperGraphDB B.15.Messergebnisse: Berechnung der starken Zusammenhangskomponenten mit HyperGraphDB B.16.Messergebnisse: Abfrage transitiv inzidenter Knoten auf HyperGraphDB111 B.17.Messergebnisse: Abfrage gemeinsamer inzidenter Knoten auf Hyper- GraphDB B.18.Messergebnisse: Suchen von Dreickspfaden in HyperGraphDB B.19.Messergebnisse: Datenimport in DEX B.20.Messergebnisse: Auslesen aller Kanten aus DEX B.21.Messergebnisse: Berechnung der starken Zusammenhangskomponenten mit DEX B.22.Messergebnisse: Abfrage transitiv inzidenter Knoten auf DEX B.23.Messergebnisse: Abfrage gemeinsamer inzidenter Knoten auf DEX. 118 B.24.Messergebnisse: Suchen von Dreickspfaden in DEX

8 Listings 1.1. Beispiel einer rekursiven SQL-Anfrage: Finde alle Vorgesetzten einer Person Beispiel einer graphbasierten Anfragesprache (Cypher): Finde alle Vorgesetzten einer Person Beispiel einer rein lesenden Cypher-Anfrage Beispiel einer komplexen Selektionsanfrage in FlockDB [Gehrels, 2013] SQL-Schema der FlockDB Kantentabellen SQL-Schema der FlockDB Knotentabellen

9 1. Motivation Viele Strukturen der realen Welt lassen sich als Graphen interpretieren, einer mathematischen Repräsentation von Netzen. Bei Straßennetzen, Beziehungsgeflechten zwischen Personen oder den Reaktionswegen biochemischer Komponenten ist dies offensichtlich, ebenso bei Baumstrukturen beispielsweise Hierarchien, Ontologien oder Stücklisten in der Industrie, bei denen einzelne Produkte jeweils aus Vorprodukten zusammengesetzt sind. Doch auch in der objektorientierten Programmierung werden Graphen aufgebaut: So lassen sich Objektinstanzen als Knoten und ihre Beziehungen als Kanten interpretieren. Möchte man Graphen automatisiert verarbeiten, so müssen diese in der Regel effizient gespeichert und ausgelesen werden. Hierfür können Datenbanksysteme genutzt werden Probleme bei der Nutzung relationaler Datenbanken zur Speicherung von Graphen Eine in der Praxis stark verbreitete Klasse von Datenbankmanagementsystemen basiert auf dem von Codd [1970] entwickelten relationalen Datenmodell. Dieses fußt auf dem Konzept der Relation, einer Menge von Tupeln gleicher Länge und gleicher Domänenfolge. Beziehungen zwischen verschiedenen Tupeln werden lediglich dadurch dargestellt, dass eines der Tupel den identifizierenden Schlüssel des anderen Tupels als Attribut enthält ( Fremdschlüssel ). Mit Joins lassen sich die Tupel mehrerer Relationen zu einer neuen Relation verknüpfen; Joins gelten als sehr rechenaufwendig, wobei sich der Aufwand durch Indexstrukturen verringern lässt. Das relationale Modell legt seinen Fokus somit auf die Entitäten selbst (in Form von Tupeln) und deren Attribute (in Form von Elementen des Tupels). Diese ergeben sich explizit aus dem Datenmodell. Beziehungen zwischen Entitäten hingegen werden nur implizit über die Gleichheit von Attributwerten repräsentiert. Bei der Navigation in großen Straßennetzen hingegen beispielsweise liegt der Fokus auf den Wegen zwischen den Orten, weniger auf den Orten selbst. Auch bei biochemischen Reaktionswegen ist gerade die Reaktionskette der interessante Part, nicht die einzelnen beteiligten Substanzen in Isolation. Die wichtigen Informationen liegen bei derartigen Modellen in der Struktur des modellierten Graphen, nicht in den Eigenschaften seiner 9

10 WITH RECURSIVE manager ( level, managerid) AS ( SELECT 1 AS depth, employees.managerid AS managerid FROM employees WHERE employees.employeeid=13 UNION ALL SELECT manager.depth+1, employees.managerid FROM manager INNER JOIN employees ON employees.employeeid=manager.managerid ) SELECT manager.depth, manager.employeeid FROM manager ORDER BY manager.depth ASC; Listing 1.1: Beispiel einer rekursiven SQL-Anfrage: Finde alle Vorgesetzten einer Person Knoten. Es liegt daher nahe, zur Speicherung solcher Daten ein Datenmodell zu nutzen, welches seinen Fokus auf diese Beziehungen legt. Nach Iordanov [2010] gibt es drei typische Anfragemuster auf Graphen. Nur eines davon, mengenbasierte Anfragen, wird von der weit verbreiteten relationalen Anfragesprache SQL [1999] gut abgedeckt. Bei den anderen beiden Anfragemustern zeigt sich die Diskrepanz zwischen dem Fokus des relationalen Datenmodells und den Fragestellungen graphorientierter Probleme. So folgen traversierende Anfragen ausgehend von einem oder mehreren Knoten den Kanten des Graphen; ein Beispiel dafür ist das Suchen kürzester Wege in einem Graphen. Graph-Pattern-Matching sucht im Graphen nach bestimmten Mustern, die von Kanten und ihren inzidenten Knoten gebildet werden, beispielsweise die Suche von Dreiecksbeziehungen und den beteiligten Personen in einem sozialen Netzwerk. Traversierende Anfragen sind in SQL [1999] zwar möglich, allerdings zeigen sich hier die Folgen eines unpassenden Datenmodells: Unter Verwendung der nicht-optionalen Bestandteile von SQL [1999] sind solche Anfragen nur dann möglich, wenn die genaue Traversiertiefe bekannt ist. Selbst dann müssen sie mittels rechenaufwendigen JOIN-Kaskaden berechnet werden. SQL [1999] spezifiziert zwar eine Lösungsmöglichkeit in Form eines optionalen Featu- 10

11 START employee=node(13) MATCH manager [pfad:manages ] >employee RETURN manager.id, length(pfad) AS depth ORDER BY depth ASC Listing 1.2: Beispiel einer graphbasierten Anfragesprache (Cypher): Finde alle Vorgesetzten einer Person res T131 (Recursive Common Table Expressions), allerdings ist auch dessen Semantik mengenorientiert. Listing 1.1 zeigt ein einfaches Beispiel einer solchen rekursiven SQL-Anfrage: Sie selektiert zu einer gegebenen Person (jener mit der Id 13 ) alle direkten und indirekten Vorgesetzten zusammen mit der jeweiligen Hierarchietiefe. Bereits bei einer solchen intuitiv eher einfachen Anfrage ist ein recht komplexes Anfragekonstrukt notwendig. Insbesondere fällt auf, dass die SQL eigentlich auszeichnende Deklarativität hier größtenteils verloren geht. Statt wie bei mengenorientierten Anfragen das Problem in SQL zu formulieren und das Datenbankmanagementsystem den Lösungsweg suchen zu lassen, wird hier bereits der Algorithmus skizziert. Außerdem ist die ursprüngliche Intention dieser SQL-Anfrage nur schwer zu erkennen Graphdatenbankmanagementsysteme als Alternative Graphdatenbankmanagementsysteme können hier eine Alternative darstellen: Sie stellen die Beziehung zwischen Entitäten in den Fokus des Datenmodells. Die Verknüpfungen ergeben sich nicht implizit aus Attributwerten, sondern sind expliziter Teil der Daten. Je nach System können Kanten gerichtet oder ungerichtet, können Knoten und Kanten gelabelt und können Knoten oder Kanten mit Attribute annotiert sein. Graphdatenbankmanagementsysteme bieten darüber hinaus teilweise graphbasierte Anfragesprachen und haben die Möglichkeit, die Datenspeicherung für typische Graphanfragemuster zu optimieren. Graphbasierte Anfragesprachen sind beispielsweise SPARQL [Prud hommeaux und Seaborne, 2008], Gremlin [Rodriguez, 2013] oder Cypher [Neo Technology, 2012, 14]. Listing 1.2 zeigt eine Cypher-Anfrage, welche das selbe Ergebnis berechnet wie die SQL-Anfrage aus Listing 1.1. Hierfür wird die Hierarchie als gerichteter Baum modelliert, wobei von jedem Manager eine mit MANAGES gelabelte Kante zu seinen unmittelbaren Mitarbeitern führt. Cypher wird in Abschnitt eingehender erläutert werden. Da die Anfragesprache demselben Konzept (Graphen) folgt wie das zu lösende Problem, lässt sich auch die Problemstellung unmittelbar in Cypher-Code ausdrücken. Anfragen sind damit einfacher zu lesen, einfacher zu schreiben und potentiell flexibler optimierbar. Graphdatenbanksysteme bieten zudem die Chance, die Datenspeicherung für ihren 11

12 Anwendungszweck zu optimieren: Da die Beziehungen zwischen den Objekten explizit gegeben sind, könnten diese beispielsweise auch als direkte Verknüpfung persistiert werden. Auch könnte man verknüpfte Entitäten gruppiert persistieren, so dass diese effizienter geladen werden können. 12

13 2. Related Work Einen guten Überblick über verschiedene Möglichkeiten, Graphen semantisch anzureichern, um sie als Datenmodell einer Datenbank zu nutzen Attribute, Labels, Gewichtungen, et cetera, bieten Rodriguez und Neubauer [2010a]. Sie geben auch eine kurze Einführung in das Feld der Graphdatenbanksysteme. Die Arbeit von Angles und Gutierrez [2008] bietet eine nunmehr historische, aber sehr breite und tiefgehende Analyse der Literatur zu Graphdatenmodellen und Graphanfragesprachen bis zurück ins Jahr Sie zeigen nicht nur die Modelle selbst, sondern auch die Entwicklungslinien und historischen Zusammenhänge auf. Zwei Ansätze für Graphanfragen finden in aktuellen Graphdatenbanksystemen häufig Verwendung: Zum einen traversierende Anfragen. Rodriguez und Neubauer [2010b] haben hierzu eine gute Überblicksarbeit veröffentlicht, welche auch eine mathematische Formalisierung dieses in der Literatur häufig nur grob umschriebenen Konzepts bietet. Zum anderen reguläre Pfadanfragen, welche von Mendelzon und Wood [1989] eingeführt wurden und in Abschnitt 5.3 noch genauer betrachtet werden. Die Arbeit von Buerli [2012] gibt einen Überblick über Anwendungsbereiche von Graphdatenbanksystemen. Außerdem bietet sie mit einer Kategorisierung von 18 Graphdatenbankmanagementsystemen als reine, verteilte, Key-Value-basierte, dokumentenorientierte, SQL-basierte und Map-Reduce-basierte Datenbankmanagementsysteme mit jeweils einem zusammenfassenden Absatz einen hervorragenden Einstieg in das Feld. Etwas mehr in die Tiefe geht [Angles, 2012], der aber wegen der Kürze dieser Arbeit nur einen groben Überblick über 9 verschiedene Graphdatenbankmanagementsysteme bietet: Die Arbeit kategorisiert diese anhand ihrer Datenmodelle, ihrer Möglichkeit, Integritäts-Constraints zu definieren sowie der Geeignetheit ihrer Anfragemechanismen für bestimmte Graphanfragen. Mit Benchmarks von Graphdatenbanksystemen haben sich verschiedene Autoren sowohl theoretisch als auch praktisch auseinandergesetzt. So haben Leskovec et al. [2008] eine gute Übersicht gegeben, welche wesentlichen Eigenschaften existierende große Graphen haben, Chakrabarti und Faloutsos [2006] geben einen Überblick über eine Vielzahl von Algorithmen zur Generierung synthetischer mit solchen Eigenschaften. Sie geben auch einen Überblick über die historische Entwicklung dieses Forschungsfeldes. Dominguez-Sal et al. [2011] haben auf dieser Grundlage eine hervorragende Diskussion über das Design von Graphdatenbanksystembenchmarks veröffentlicht. Sie spannen den Bogen von der Analyse motivierender Anwendungsfälle von Graphdatenbanksystemen über Charakteristika sinnvoller Testdaten und Auswahlkriterien 13

14 für Benchmarkalgorithmen bis hin zu Empfehlungen für den Versuchsaufbau und die Messmethodiken. Benchmarksuiten für objektorientierte Datenbanksysteme und damit für Objektgraphen haben unter anderem Cattell und Skeen [1992] und Carey et al. [1993] definiert, Guo et al. [2005] definieren eine Benchmarksuite für RDF-Graphen. Eine weitere Benchmarksuite, welche originär auf Graphverarbeitung ausgerichtet ist wurde von Bader et al. [2009] definiert. Vicknair et al. [2010] haben Neo4j und MySQL gegeneinander einem Benchmark unterzogen. Sie kommen zu dem Schluss, dass Neo4j für traversierende Anfragen und durch die Nutzung von Lucene als Index-Lösung auch für Volltextanfragen die schnellere Wahl ist, MySQL aber für Anfragen, die Entitäten anhand bestimmter Attribute zählen. Holzschuher und Peinl [2013] haben verschiedene Anfragemöglichkeiten von Neo4j einem Benchmark unterzogen, sowohl gegeneinander als auch gegenüber MySQL/JPA. Auch sie sehen Neo4j bei traversierenden Anfragen gegenüber MySQL im Vorteil, bei Abfragen, die lediglich einzelne Knoten vollständig auslesen, hingegen im Nachteil. Darüber hinaus gibt es noch einige Benchmarks, welche von Entwicklern von Graphdatenbanksystemen durchgeführt wurden und wenig überraschend jeweils das eigene System als vorteilhaft herausstellen: Zu nennen wären hier insbesondere Ciglan et al. [2012], die DEX, Neo4j, SAIL, OrientDB und ihren Prototypen SGDB anhand traversierender Anfragen vergleichen, Dominguez-Sal et al. [2010], die ihr Datenbankmanagementsystem DEX mit Neo4j, Jena und HyperGraphDB vergleichen, Martínez-Bazan et al. [2012], die vom selben Institut stammend DEX mit MonetDb, MySQL und Neo4j vergleichen. Dass all diese Arbeiten von den jeweiligen Entwicklern publiziert wurden, heißt nicht, dass diese Arbeiten zwingend einen methodischen Bias haben. Es zeigt aber, dass es kaum herstellerunabhängige Benchmarks gibt, welche Graphdatenbanksysteme untereinander vergleichen. 14

15 3. Ziel der Arbeit Die existierende vergleichende Literatur zu Graphdatenbanksystemen beschränkt sich hauptsächlich auf eine abstrakte Ebene und vergleicht Datenmodelle und die Existenz verschiedener Typen von Anfragesprachen. Eine tiefergehende Analyse der verschiedenen Systeme insbesondere bezüglich der jeweils verwendeten Datenstrukturen und deren Optimierung für bestimmte Anfragemechanismen fehlt weitgehend. Gleichzeitig gibt es kaum herstellerunabhängige Benchmarks, welche die Auswirkungen dieser Designentscheidungen auf die Geschwindigkeit der Systeme prüfen. Diese Arbeit versucht, diese Lücke zu füllen. Hierfür werden zuerst verschiedene exemplarisch ausgewählte Graphdatenbankmanagementsysteme vorgestellt. Dies umfasst einführend die verwendeten Graphenmodelle und die Anfragemöglichkeiten. Darauf folgend wird jeweils ein Blick auf die technische Umsetzung geworfen werden: Welche Ansätze wurden gewählt, um Graphen zu persistieren? Welche Caching-Verfahren wurden gewählt? Wie gehen die Systeme mit nebenläufigen Zugriffen um? Welche Möglichkeiten bieten die Systeme, auf steigende Datenmengen, steigende Schreiblast oder steigende Leselast zu reagieren? Ergänzt wird diese Arbeit um eine Geschwindigkeitsmessung der Datenbanksysteme mittels verschiedener Anfragemuster auf Graphen verschiedener Größen. Dies soll sichtbar machen, welche Auswirkungen die den einzelnen Systemen zugrundeliegenden Designentscheidungen auf die Performance des Gesamtsystems haben. Am Beispiel von vier exemplarisch gewählten System wird herausgearbeitet, in welchen Anwendungsgebieten welcher der gewählten Ansätze Vorteile bietet und wo deren Nachteile liegen - eine breiter angelegte Untersuchung aller am Markt existierenden Graphdatenbankmanagementsysteme würde den Rahmen einer Diplomarbeit deutlich sprengen. Neo4j [Neo Technology, 2012] sticht aus den vorhandenen Systemen durch seine mächtigen und vielfältigen Anfragemöglichkeiten heraus. Es verknüpft Datensätze auf Persistenzebene und ist damit auch ein Beispiel explizit graphbasierter Datenpersistenz. DEX [Martínez-Bazan et al., 2007] stellt das entgegengesetzte Extrem dar: Es hat nur sehr minimalistische Anfragemöglichkeiten. DEX basiert auf B-Bäumen und Bitmaps zur Datenpersistenz und ist damit beispielhaft für graphbasierte Datenbankmanagementsysteme, welche keine direkte Verknüpfung zwischen Entitäten persistieren. 15

16 HyperGraphDB 1.2 [Iordanov, 2010] basiert auf dem Datenmodell eines Hypergraphen und stellt damit das wohl ausdrucksmächtigste Datenmodell unter den momentan verfügbaren Graphdatenbankmanagementsystemen zur Verfügung. FlockDB 1 [Pointer et al., 2010] wählt wiederum einen vollständig anderen Ansatz: Es stellt lediglich einen graphbasierten Mediator zwischen der Anwendung und einem relationalen Datenbankmanagementsystem dar, welches über SQL [1999] angesprochen wird. Es unterstützt ausschließlich mengenbasierte Anfragen. Darüber hinaus ist FlockDB als einziges betrachtetes System explizit für hohe, nebenläufige Schreiblast ausgelegt. Diese vier Systeme sind als Stichprobe besonders geeignet, einen Überblick über die sich teils stark unterscheidenden existierenden Konzepte zu bilden. Außerdem sind sie zumindest für die akademische Nutzung kostenfrei verfügbar. Weitere Graphdatenbankmanagementsysteme, welche im Rahmen dieser Arbeit nicht betrachtet wurden, sind OrientDB, InfoGrid, Objectivity InfiniteGraph und Allegro- Graph. Darüber hinaus existieren VertexDB, welches anscheinend nicht mehr aktiv entwickelt wird 2 und GraphDB, welche als Teil der Insolvenzmasse ihrer Entwicklerin, der Sones GmbH, bis heute zum Verkauf steht 3. Zumindest ein Teil von GraphDB steht aber unter AGPL online 4. Ebenfalls in dieser Arbeit nicht betrachtet werden Systeme zur verteilten Analyse sehr großer Graphen wie Google Pregel [Malewicz et al., 2010] und dessen Open- Source-Implementierung Apache Giraph Ching et al. [2012] oder GraphLab [Gonzalez et al., 2012]. Diese stellen keine Graphdatenbankmanagementsysteme im Sinne dieser Arbeit dar, da sie nicht zur kontinuierlichen Verwaltung von Daten, sondern zur gelegentlichen Analyse großer Datenbestände entworfen wurden. 1 Betrachtet wirde die Fassung des Git-Master-Branches auf Github.com vom 28. April 2012: 2 Das GIT-Repository des Projekts verzeichnet lediglich einen Commit in den letzten 2 Jahren: abgerufen am 13. März Telefonische Auskunft des Insolvenzverwalters, Herrn Dr. Oliver Hartig, vom 12. März Zu finden unter abgerufen am 13. März

17 4. Historischer Hintergrund In den letzten Jahren kam eine Vielzahl neuer Graphdatenbanksysteme auf den Markt. Die Idee, Netzwerkstrukturen als Datenmodell für Datenbankmanagementsysteme zu nutzen, reicht aber weit zurück. Charles Bachman entwarf Mitte der 1960er Jahre mit dem Integrated Data Store eines der ersten Allzweckdatenbanksysteme. Es basierte auf dem Datenmodell eines gerichteten, zyklenfreien Graphen aus Records und Pointern, welches später (1969) von der Conference on Data Systems Languages als network model (auch CODASYL data model) spezifiziert wurde veröffentlichte IBM das Information Management System, welches auf dem Datenmodell eines gerichteten Baums basierte, hierarchisches Modell genannt [Singh, 2009, 1.9]. Das von Codd [1970] vorgeschlagene relationale Modell verdrängte in der Folge nach der Einführung von SQL/DS durch IBM in den frühen 1980er Jahren zunehmend das Netzwerk- und das hierarchische Modell. Singh [2009, 1.9] führt dies unter anderem auf die Einfachheit des relationalen Modells, die einfache Nutzbarkeit der relationalen Datenbanksysteme auch durch Nicht-Programmierer mittels SQL als Anfragesprache und der SQL innewohnenden, deklarativen Abstraktion von Implementierungsdetails des Datenbankmanagementsystems zurück. Die Idee, Graphdatenbanken als Allzweckdatenbanken zu nutzen, entstand Anfang der 1990er Jahre. So beschreiben Amann und Scholl [1992] ein seinerzeit wachsendes Interesse an Graphmodellen und -sprachen in der aktuellen Datenbankforschung 1, insbesondere für Hypertext- und Geoinformationssysteme. Sie entwerfen sowohl ein Datenmodell basierend auf einem gerichteten gelabelten Multigraphen als auch eine Anfragesprache hierfür. In den späten 1990ern wurden vermehrt objektorientierte Datenbankmanagementsysteme entwickelt [Singh, 2009, 1.9]. Die von der Object Data Management Group definierte Object Definition Language [Cattell et al., 2000] basiert auf einem Graphen als abstraktem Datenmodell, mit Objekten als Knoten und Relationen zwischen ihnen als Kanten. Auch die Vererbungshierarchien zwischen Klassen sind hierbei Graphen. Mit dem Aufkommen des Semantic Web als Forschungsgebiet um die Jahrtausendwende wurde auch das Resource Description Framework [Klyne und Carroll, 2004] 1 Eigene Übersetzung. 17

18 als Datenmodell standardisiert. Es beschreibt Fakten als Subjekt-Prädikat-Objekt- Tripel. Mit Subjekt und Objekt als Knoten und Prädikaten als Kanten formt es einen Graphen. Damit einhergehend wurde auch eine neue Klasse von Datenbanksystemen geschaffen, sogenannte Triple Stores. SPARQL [Prud hommeaux und Seaborne, 2008], die wohl prominenteste Anfragesprache für Semantic-Web-Daten, ist ebenfalls als Graphanfragesprache konzipiert. Ende des letzten Jahrzehnts kam unter dem Begriff NoSQL eine große Menge neuer Datenbanksysteme auf den Markt. Ihnen gemeinsam ist, dass sie abseits des relationalen Modells neue Möglichkeiten suchen, bestimmte Probleme der Datenspeicherung und Anfragebearbeitung effizienter zu lösen. Hierfür wurden, im Gegensatz zum relationalen Modell, häufig schemalose Ansätze gewählt, um strukturierte und semistrukturierte Daten zu speichern. Das Interesse an der Analyse sehr großer Graphen, sei es im Bereich sozialer, technischer, semantischer oder biologischer Netze, führte auch zu einem weiter steigenden Interesse an Graphdatenbanksystemen [Angles und Gutierrez, 2008, 2.4]. Auch für die immer häufiger anzutreffenden Empfehlungssysteme, insbesondere im E-Commerce-Bereich, stellen sie eine gute Grundlage dar [Rodriguez und Neubauer, 2010b, 3.1]. Ungefähr gleichzeitig wurde gerade im Bereich dieser Empfehlungssysteme das Destillieren von Empfehlungen aus teils enormen und wachsenden Mengen von Transaktionsdaten eine Herausforderung von großem Interesse. Hierbei ist es häufig notwendig, diese Berechnungen über mehrere Systeme zu verteilen. Dieser Trend wird immer häufiger unter dem Begriff Big Data gefasst. In diesem Zusammenhang wurde Apache Hadoop [Apache, 2008] populär, welches auf dem zuvor von Dean und Ghemawat [2004] publizierten MapReduce-Paradigma basiert. Die Unzulänglichkeiten von MapReduce bei der Analyse von Graphdaten führte in der Folge zur Entwicklung von Systemen wie Google Pregel [Malewicz et al., 2010], Apache Giraph [Ching et al., 2012] und GraphLab [Gonzalez et al., 2012]. 18