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

19 5. Grundbegriffe Für die Analyse von Graphdatenbanksystemen ist es notwendig, einige grundlegende Begriffe der Graphentheorie und den Begriff des Graphdatenbanksystems selbst zu definieren. Darüber hinaus werden in diesem Kapitel einige mathematische Grundlagen von Graphanfragesprachen dargestellt. Das Kapitel schließt ab mit der Definition eingebetteter Datenbankmanagementsysteme und den Begriffen horizontaler und vertikaler Skalierbarkeit Graphen Als Grundform vieler Graphdefinitionen kann der gerichtete Multigraph gesehen werden: Definition 1. Ein gerichteter Multigraph ist ein Tupel G = (V, E, ɛ). Hierbei sind V und E beliebige Mengen, ɛ : E (V V ) eine totale Funktion. Die Menge V wird Knotenmenge genannt, die Menge E Kantenmenge. Für eine Kante e E mit ɛ(e) = (v 1, v 2 ) ist v 1 ihr Ausgangsknoten, v 2 ihr Endknoten. Eine spezielle Form des gerichteten Multigraphen ist der gerichtete Graph: Definition 2. Ein gerichteter Multigraph G = (V, E, ɛ) wird als gerichteter Graph bezeichnet, sofern ɛ injektiv ist. Da in dieser Arbeit ausschließlich gerichtete (Multi-) Graphen betrachtet werden, werden diese im Folgenden nur noch als Graphen und Multigraphen bezeichnet. Definition 3. Ein Knoten v 2 heißt inzidenter Knoten eines Knotens v 1 in einem Multigraphen G = (V, E, ɛ), wenn eine Kante e mit ɛ(e) = (v 1, v 2 ) oder ɛ(e) = (v 2, v 1 ) existiert. e wird dann als inzidente Kante von v 1 und von v 2 bezeichnet. In Multigraphen lassen sich Pfade finden. Ein Pfad ist ein möglicher Weg von einem Knoten im Graph zu einem anderen Knoten: Definition 4. Ein Tupel p = (v 1, e 1, v 2, e 2,..., e n 1, v n ) heißt Pfad im Multigraphen G = (V, E, ɛ), wenn v 1,..., v n V und e 1,..., e n 1 E sind sowie für jedes e i in p gilt: ɛ(e i ) = (v i, v i+1 ). 19

20 Rodriguez und Neubauer [2010a] geben einen Überblick über verschiedene Möglichkeiten, die Struktur von Graphen um weitere Elemente zu erweitern. Einige dieser Erweiterungsmöglichkeiten, welche auch in die Datenmodelle der in dieser Arbeit untersuchten Graphdatenbankmanagementsysteme Einzug gehalten haben, werden im Folgenden definiert. Eine Erweiterungsmöglichkeit besteht darin, Knoten oder Kanten ein beliebiges Datum zuzuordnen, Label genannt: Definition 5. G LV = (G, L V, l V ) ist ein Multigraph mit Knoten-Labeln, wenn G = (V, E, ɛ) ein Multigraph, L V eine beliebige Menge und l V : V L V eine totale Funktion ist. l V (v) wird Label von v genannt. Analog gilt für Kanten: Definition 6. G LE = (G, L E, l E ) ist ein Multigraph mit Kanten-Labeln, wenn G = (V, E, ɛ) ein Multigraph, L E eine beliebige Menge und l E : E L E eine totale Funktion ist. Sollen mehr Daten als nur ein Label annotiert werden, so bietet sich die Zuweisung von Schlüssel-Wert-Paaren, sogenannten Properties, zu Knoten oder Kanten an: Definition 7. G p = (G, p V ) ist ein Multigraph mit Knoten-Properties, wenn G = (V, E, ɛ) ein Multigraph ist, K und W beliebige Mengen sind und p V : (V K) W eine partielle Funktion ist. Hierbei ist K die Menge der möglichen Schlüssel, W die Menge der möglichen Werte. Definition 8. Sei G p = (G, p V ) ein Multigraph mit Knoten-Properties mit G = (V, E, ɛ). Das Tupel (k, w) mit k K, w W heißt Property von v V, wenn gilt: p V (v, k) = w. k wird Schlüssel, w wird Wert genannt. Dies gilt analog auch für Multigraphen mit Kanten-Properties. Die hier definierten verschiedenen Annotationsmöglichkeiten lassen sich natürlich auch beliebig kombinieren. In Abbildung 5.1 ist beispielhaft ein Multigraph mit Kanten-Labeln und Knoten-Properties dargestellt Hypergraphen Für die Modellierung komplexerer Daten mit n-ären Beziehungen sind Hypergraphen besonders geeignet. Aufbauend auf den Ausführungen von Iordanov [2010], welcher eine Vereinfachung der von Boley [1977] eingeführten Directed Recursive Labelnode Hypergraphs beschreibt, lassen sich Hypergraphen wie folgt definieren: 20

21 Abbildung 5.1.: Beispiel eines gerichteten Multigraphen mit Kanten-Labeln und Knoten-Properties Abbildung 5.2.: Beispiel eines gelabelten und gerichteten Multihypergraphen Definition 9. Sei M eine beliebige Menge. Dann ist T (M) die Menge aller Tupel beliebiger Größe, welche ausschließlich aus Elementen von M bestehen. Insbesondere ist das leere Tupel () in T (M) enthalten. Definition 10. H = (A, inzidenz) mit inzidenz : A T (A) ist ein gerichteter Multihypergraph. Die Elemente von A werden als Atome im Graphen bezeichnet. Ein Atom a A heißt Knoten in H, wenn gilt: inzidenz(a) = (). Alle anderen Atome heißen Kanten in H. Die Elemente des Tupels inzidenz(a) für ein Atom a A heißen inzidente Atome von a. Man kann sich einen gerichteten Multihypergraphen im Folgenden wird er vereinfachend Hypergraph genannt als einen Multigraphen vorstellen, bei dem Kanten und Knoten zusammengefasst als Atome bezeichnet werden, Kanten auch auf andere Kanten zeigen, Kanten auch von anderen Kanten ausgehen, Kanten auch von mehreren Knoten und Kanten ausgehen und Kanten auch auf mehrere Knoten und Kanten zeigen können. 21

22 Die Definition lässt offen, welche der inzidenten Atome Ausgangs- und welche Zielatome der Kante sind. Da jedes Inzidenztupel eine Ordnung besitzt, kann dies für den jeweiligen Anwendungsfall seperat definiert werden. Selbstverständlich können auch die Atome eines Hypergraphen mit Labeln und Properties annotiert werden. Ein Beispiel eines solchen Multihypergraphen mit Atom-Labeln ist in Abbildung 5.2 zu sehen Reguläre Pfadanfragen Ein großer Teil des Informationsgehaltes von Graphen liegt in ihrer Struktur. Es kann daher von Interesse sein, Teile eines Graphen zu finden, welche bestimmten Mustern entsprechen. Eine einfache Möglichkeit hierfür stellen reguläre Pfadanfragen dar. Angelehnt an Mendelzon und Wood [1989] lassen sich diese wie folgt definieren: Definition 11. Gegeben ein gerichteter Multigraph mit Kanten- und Knotenlabeln G = (V, E, ɛ, L V, L E, l V, l E ). Ein regulärer Ausdruck R über dem Alphabet L V L E wird als reguläre Pfadanfrage an G bezeichnet. Definition 12. Sei G = (V, E, ɛ, L V, L E, l V, l E ) ein gerichteter Multigraph mit Knoten- und Kantenlabeln, R eine reguläre Pfadanfrage an G und L(R) die von R definierte Sprache. R findet genau die Menge RP Q(R) von zyklenfreien Pfaden, bei der für jeden Pfad (v 1, e 1,..., e n 1, v n ) RP Q(R) gilt: Das Wort l V (v 1 ) l E (e 1 )... l E (e n 1 ) l V (v n ) ist in L(R) enthalten 1. Eine reguläre Pfadanfrage beantwortet also die Frage: Wenn die Knoten- und Kanten- Labels von Pfaden zu Worten konkateniert werden, welche der Pfade bzw. Worte entsprechen dann einem gegebenen regulären Ausdruck?. Ein einfaches Beispiel findet sich bei Koschmieder und Leser [2012]: Suppose a graph of researchers (nodes), either labeled as Professors or STudents, connected by directed edges such as Supervised or Joint work. In this graph, the query P (JP )(JP )? finds all paths between a professor and direct or indirect co-workers. (P S)(P S) + (P T ) finds all paths between a professor and his doctorate descendants. Analoge Definitionen lassen sich auch für Graphen finden, die lediglich lediglich Knoten- oder lediglich Kanten-Labels haben. Aufwendiger gestaltet es sich, dieses Konzept auf Graphen mit Knoten- oder Kanten-Properties anzuwenden. Ein Ansatz wäre hier, dem Alphabet des regulären Ausdruckes spezielle Symbole für der vorliegende Knoten hat eine Property mit Schlüssel x und Wert y hinzuzufügen. So ließen sich dann auch Anfragen wie Finde alle Pfade zwischen einer Professorin mit der Property name: Doe und den Menschen, mit denen sie im jahr: 2000 direkt und indirekt zusammengearbeitet hat beantworten. 1 Das Symbol stellt hier die Konkatenation von Symbolen zu einem Wort dar. 22

23 5.4. Reguläre Graphanfragen Aufbauend auf der Definition regulärer Pfadanfragen wird im Folgenden eine Definition regulärer Graphanfragen, teilweise auch als Conjunctive Regular Path Queries Calvanese et al. [2000] bezeichnet, entwickelt. Diese kombinieren Graph-Pattern- Matching mit regulären Pfadanfragen. Eine reguläre Graphanfrage verknüpft reguläre Pfadanfragen zu einem größeren Graphmuster, welches nicht nur einzelne Pfade, sondern ganze Teilgraphen aus vernetzten Teilpfaden finden kann: Definition 13. R(Σ) bezeichnet die Menge aller möglichen regulären Ausdrücke über einem beliebigen Alphabet Σ. Definition 14. Ein Tupel RGQ = (V AR, EXP ) heißt reguläre Graphanfrage mit den Variablen var V AR über dem Multigraphen mit Kantenlabeln G = (V, E, ɛ, L E, l e ), wenn V AR eine beliebige Menge und EXP V AR R(L E ) V AR ist Reguläre Graphanfragen finden nicht wie reguläre Pfadanfragen einzelne Pfade, sondern Tupel von teils verbundenen Pfaden: Definition 15. Sei RGQ = (V AR, EXP ) mit EXP = {(v 1, R 1, w 1 ),..., (v n, R n, w n )} eine reguläre Graphanfrage über dem Multigraphen G = (V, E, ɛ, L E, l e ) mit Kantenlabeln. Ein Tupel (p 1,..., p n ) RP Q(R 1 )... RP Q(R n ) wird von RGQ gefunden, wenn für jedes i, j N +, i, j n gilt: Ist v i = v j, dann ist der Anfangsknoten von p i auch der Anfangsknoten von p j ; ist v i = w j, dann ist der Anfangsknoten von p i auch der Endknoten von p j ; ist w i = v j, dann ist der Endknoten von p i auch der Anfangsknoten von p j ; ist w i = w j, dann ist der Endknoten von p i auch der Endknoten von p j. In der Regel wird es sinnvoll sein, lediglich zusammenhängende Graphanfragen auszuwerten: Definition 16. Eine reguläre Graphanfrage RGQ = (V AR, EXP ) heißt zusammenhängend, wenn für jedes a = (v a, R a, w a ), a EXP gilt: Es gibt ein b = (v b, R b, w B ), b EXP, a b, für das mindestens eine der folgenden Bedingungen gilt: v a = v b oder v a = w b oder w a = v b oder 23

24 Abbildung 5.3.: Schematische Darstellung einer zusammenhängenden regulären Graphanfrage mit 4 Variablen und 4 Ausdrücken w a = w b. Die zusammenhängende Beispielanfrage RGQ = (V AR, EXP ) V AR = {x, y, a, b} EXP = {(b, (P S) + P, x), (x, P JP, y), (b, (P S) + (P T ), y), (a, (A N)HP, y)} ist in Abbildung 5.3 schematisch dargestellt. Die regulären Ausdrücke sind angelehnt an das bereits in Abschnitt 5.3 verwendete Beispiel von Koschmieder und Leser [2012]. Hierbei ist erkennbar, dass sowohl die zusammenhängende Anfrage selbst als auch die Ergebnispfade derselben einen gerichteten, zusammenhängenden Graphen bilden. Wäre die Anfrage nicht zusammenhängend, so würden die Ergebnisgraphen ebenfalls nicht zwingend zusämmenhängend sein Graphdatenbankmanagementsysteme Als Graphdatenbankmanagementsysteme (kurz GDMBS) werden in dieser Arbeit Datenbankmanagementsysteme bezeichnet, die mit einem logischen Datenmodell arbeiten, welches einer der Definitionen aus 5.1 und 5.2 folgt. Die von einem GDBMS verwaltete und persistierte Form eines tatsächlichen Graphen wird als Graphdatenbank, die Kombination aus einem Graphdatenbankmanagementsystem und einer Graphdatenbank als Graphdatenbanksystem bezeichnet Eingebettetes Datenbankmanagementsystem Datenbankmanagementsysteme lassen sich neben dem verwendeten Datenmodell auch anhand ihrer Einbettbarkeit klassifizieren. Hiernach teilt sich die Menge der 24

25 Datenbankmanagementsysteme in zwei Klassen auf: Zum einen solche, die als eigenständige Anwendungen unabhängig von der Software laufen, welche sie nutzt, zum anderen solche, welche in diese Software eingebettet (engl. embedded ) sind. Eingebettete Datenbankmanagementsysteme sind Teil der Anwendung, welche sie nutzt. Sie werden häufig als Softwarebibliothek eingebunden. Die Abfrage erfolgt über APIs des Datenbankmanagementsystems. Die Einbettung als Softwarebibliothek erlaubt es, das DBMS zusammen mit der Anwendung auszuliefern. Eine separate Installation durch den Nutzer ist nicht notwendig. Für den Nutzer der Software ist weder sichtbar noch relevant, ob und wenn ja welches DBMS genutzt wird. Auch etwaige Updates des DBMS können vom Anbieter der Software zusammen mit dieser selbst ausgeliefert werden. Nachteil hierbei ist, dass die Datenbanksysteme meist nicht von verschiedenen Prozessen gleichzeitig genutzt werden können und auch eine Kommunikation über ein Netz in der Regel nicht vorgesehen ist. Nicht eingebettete Datenbankmanagementsysteme laufen als eigenständige Anwendungen im Betriebssystem, werden seperat von der sie nutzenden Software entwickelt, vertrieben und gewartet und kommunizieren mit der sie nutzenden Software über Mechanismen der Interprozesskommunikation oder häufig über Netzwerkprotokolle. Sie sind oftmals im Client-Server-Modus von verschiedenen Rechnern im Netzwerk nutzbar Horizontale und vertikale Skalierbarkeit Softwaresysteme stehen häufig dem Problem steigender Systemlast gegenüber. Dies kann beispielsweise durch eine Steigerung der zu verarbeitenden Datenmengen, durch eine Steigerung der Anzahl lesender Interaktionen oder durch eine Steigerung der Anzahl schreibender Interaktionen mit dem Softwaresystem bedingt sein. Auch andere Faktoren oder Kombinationen mehrerer Faktoren kommen als Ursachen in Frage. Die Möglichkeit, als System oder Systembetreiber ohne Änderungen an der Software selbst auf diese Laststeigerungen zu reagieren, lässt sich als Skalierbarkeit bezeichnen. Grundsätzlich lassen sich hier zwei mögliche Handlungsdimensionen sehen [Michael et al., 2007]. So ist es möglich die Leistungsfähigkeit der Hardware zu erhöhen, auf welcher das Softwaresystem läuft. Ein Datenbankserver lässt sich beispielsweise mit mehreren oder stärkeren CPUs, mehr RAM oder größeren bzw. schnelleren Festplatten bestücken. Diese Handlungsdimension wird häufig als Horizontales Skalieren, im Englischen auch Scale-Up bezeichnet. Diese Dimension ist aber begrenzt durch den jeweiligen Stand der technischen Entwicklung im Hardwarebereich. 2 Dieser Abschnitt Eingebettetes Datenbankmanagementsystem ist weitgehend [Gehrels, 2012, 4.3] entnommen. 25

26 Eine andere, häufig als vertikales Skalieren, im Englischen auch Scale-Out, bezeichnete Möglichkeit ist, das Softwaresystem stattdessen als verteiltes System auf einer Vielzahl von Rechnern laufen zu lassen und bei Laststeigerungen zusätzliche Rechner hinzuzufügen statt immer größere Rechner zu nutzen werden immer mehr Rechner genutzt. Hierbei stößt man nicht an die Grenzen der technischen Entwicklung im Hardwarebereich 3, allerdings geht mit der Verteilung auch eine deutliche Steigerung der Komplexität des Gesamtsystems einher. Hierauf aufbauend bezeichnet Horizontale Skalierbarkeit die Fähigkeit eines Systems, auf leistungsstärkerer Hardware auch mit gesteigerter Leistung zu arbeiten. Vertikale Skalierbarkeit bezeichnet die Fähigkeit, als verteiltes System auf einer steigenden Zahl von Rechnern mit gesteigerter Leistung zu arbeiten. Dies bedeutet insbesondere auch, dass das Softwaresystem überhaupt als verteiltes Softwaresystem konzipiert sein muss. 3 Natürlich gibt es auch hier Grenzen, bspw. kann bei der Verteilung die Kapazität des Netzwerk zum Flaschenhals werden. 26

27 6. Überblick über verschiedene Graphdatenbankmanagementsysteme Die in dieser Arbeit betrachteten Datenbankmanagementsysteme haben sehr unterschiedliche Entwicklungsmotivationen. Neo4j wurde mit der Prämisse entwickelt, kommerziell vermarktbar zu sein. Seine Herstellerin vermarktet es als Alternative zu relationalen Datenbanken als Operational Datastore, insbesondere wegen des Wegfalls des Object-Relational Impedance Mismatch [Smith und Zdonik, 1987], also der aus den Unterschieden zwischen dem Datenmodell objektorientierter Programmiersprachen und dem relationaler Datenbanken resultierenden Problemen bei der Abbildung aufeinander. FlockDB ist eine aus einem bestimmten Anwendungsfall heraus geborene Lösung von Twitter. Twitter stand dem Problem gegenüber, eine Lösung für das horizontale Skalieren bzgl. Schreiblast, Leselast und Datenmenge bei mengenorientierten Graphanfragen zu finden. DEX und HyperGraphDB kommen aus einem akademischen Umfeld. Sparsity Technologies, die Herstellerin von DEX, ist eine Ausgründung der Data Management Group der Universitat Politècnica de Catalunya mit dem Ziel, die dort gewonnenen Forschungsergebnisse kommerziell zu verwerten. HyperGraphDB stammt aus dem Umfeld des OpenCog-Projekts 1, welches darauf abzielt, eine Software-Plattform für Forschungsprojekte im Bereich der Künstlichen Intelligenz zu entwickeln. Diese vier Datenbankmanagementsysteme werden im Folgenden anhand mehrerer Analysekategorien untersucht. Eingeführt werden die einzelnen Systeme mit einer Beschreibung ihres Datenmodells und der Frage, ob diese wie viele NoSQL- Datenbanken - schemalos sind, bzw. welche Form von Schema forciert wird. Darauf aufbauend wird untersucht, welche Anfragemechanismen an die so modellierten Daten unterstützt werden. Neben den elementaren CRUD-Operationen 2 auf einzelnen Entitäten werden verschiedene typische Anfragemöglichkeiten untersucht: Da Graphanfragen häufig traversierende Anfragen sind und effizientes Traversieren das Alleinstellungsmerkmal von Graphdatenbanksystemen ist [Ciglan et al., 2012], wird dies ein Fokus der Analyse sein. Für nicht-traversierende Anfragen sind auch 1 Zu finden unter abgerufen am 25. März CRUD steht als Abkürzung für die elementaren Operationen Create, Read, Update, Delete. 27

28 mengenbasierte Anfragemechanismen, wie sie von SQL [1999] bekannt sind, interessant, weshalb auch ihre Unterstützung geprüft wird. Abschließend soll ein Blick auf die Unterstützung regulärer Graphanfragen geworfen werden. Um solche Anfragen effizient auszuwerten, ist eine optimierte Persistierung notwendig. Es wird daher untersucht werden, wie die verschiedenen Systeme ihre Daten persistieren und cachen und welche Auswirkungen dies theoretisch auf die Fähigkeiten hat, effizient über die Datenmenge zu traversieren. Hierbei wird auch untersucht, welche Indexstrukturen genutzt werden und wie diese die Anfragebearbeitung unterstützen. Ein weiterer häufig beachteter Aspekt von Datenbanksystemen ist ihre Fähigkeit transaktionaler Zugriffe. Härder und Reuter [1983] haben mehrere Analysekategorien (die sog. ACID-Eigenschaften) für transaktionale Systeme eingeführt, namentlich, ob diese in der Lage sind, Atomarität der Datenspeicherung, Konsistenz innerhalb der Datenbasis, Isolation nebenläufiger Zugriffe und Dauerhaftigkeit der Speicherung einmal abgeschlossener Transaktionen auch nach Systemausfällen sicherzustellen. Dies sind keine binären Kategorien, viel mehr sind bei jedem der Kriterien Abstufungen möglich. Es wird daher analysiert, welche dieser Analysekriterien in welchem Umfang unterstützt werden und durch welche Maßnahmen dies geschieht. Gerade bei verteilten NoSQL-Datenbanken werden häufig Abstriche bei der Datenkonsistenz gemacht: Brewer [2000] hat diesbezüglich die plakative These aufgestellt, dass ein verteiltes System nur zwei der drei wünschenswerten Eigenschaften Datenkonsistenz (über alle Knoten hinweg), hohe Verfügbarkeit und Toleranz gegenüber Netzwerkpartitionen aufweisen kann, das sogenannte CAP-Theorem. In diesem Zusammenhang hat er das BASE-Prinzip von Fox et al. [1997] angeführt Basically Available, Soft State, Eventual Consistency, also eine Fokussierung auf Verfügbarkeit unter teilweiser Aufgabe von Datenkonsistenz. Auch wenn er sich in [Brewer, 2012] teilweise von dieser 2 von 3 -Formulierung distanziiert hat, scheinen Konsistenz, Verfügbarkeit und Partitionstoleranz zumindest als Analysekategorien für verteilte Systeme durchaus geeignet. Es wird daher untersucht werden, ob sich die einzelnen Systeme als verteilte Datenbanksysteme nutzen lassen, welche Kompromisse dabei zwischen Konsistenz, Verfügbarkeit und Partitionssicherheit getroffen wurden sowie welche Mechanismen und Werkzeuge hierfür genutzt wurden Neo4j Neo4j [Neo Technology, 2012] ist ein in Java geschriebenes Graphdatenbankmanagementsystem. Es wird von Neo Technology entwickelt und steht unter der freien Lizenz GNU General Public Licence zur Verfügung. Um weitere Monitoring-, Backupund Replikationsmöglichkeiten erweiterte Versionen stehen unter der (für Entwickler 28

29 Abbildung 6.1.: Beispielhafte Darstellung einer Neo4j-Datenbank restriktiveren) GNU Affero General Public License sowie kommerziellen Lizenzen zur Verfügung. Neo4j basiert auf dem Datenmodell eines gerichteten Multigraphen mit Kantenlabeln sowie optionalen Knoten- und Kanten-Properties. Knoten und Kanten sind veränderbar, haben aber eine vom DBMS verwaltete Identität. Labels und Property- Schlüssel sind Strings, Property-Werte können primitive Java-Datentypen oder Strings sowie Arrays aus beiden sein. Das Datenmodell von Neo4j ist schemalos, Knoten und Kanten können beliebige Kombinationen aus Properties und Labeln haben und Knoten können mittels Kanten beliebig miteinander verknüpft werden. Eine DBMS-Instanz verwaltet stets genau eine Datenbank. Eine Beispieldatenbank ist in Abbildung 6.1 visualisiert. Drei Betriebsmodi werden unterstützt, jeweils mit einer eigenen Kommunikationsschnittstelle. Erstens ist es möglich, Neo4j als Server im Client-Server-Betrieb zu nutzen. Die Kommunikation erfolgt dann über eine REST-API. Zweitens gibt es die Möglichkeit, Neo4j als in Java-Programme eingebettetes Datenbankmanagementsystem zu nutzen. Die Kommunikation erfolgt dann über eine Java-Schnittstelle. Drittens gibt es zum schnellen Import großer Datenmengen die Möglichkeit, Daten unter Umgehung der Transaktionskontrolle direkt in eine Datenbank zu schreiben. Hierfür wird das DBMS ebenfalls mittels einer Java-Schnittstelle in die importierende Anwendung eingebettet. Die persistierten Datenbanken sind zwischen den einzelnen Betriebsmodi binär kompatibel, eine im Embedded-Modus befüllte Datenbank kann also später als REST-Server betrieben werden. Eine gleichzeitige Nutzung in verschiedenen Modi ist allerdings nicht möglich, es kann also beispielsweise nicht gleichzeitig ein Batch-Import durchgeführt und die DB im Client-Server-Betrieb genutzt werden. 29

30 Indexstrukturen Neo4j erlaubt das Indizieren von Entitäten (Knoten und Kanten) anhand von Schlüssel-Wert-Paaren. Diese Schlüssel-Wert-Paare müssen nicht zwingend Properties der zu indizierenden Entität sein, sondern können beliebig gewählt werden. Hierbei wird zunächst nur eine Index API definiert, es können prinzipiell beliebige Index- Mechanismen als Plugins installiert werden. Wie die Indizierung genau geschieht, ist nicht spezifiziert. Die API unterstützt die Abfrage von Entitätsmengen anhand von gegebenen Schlüssel-Wert-Paaren und Plugin-spezifischen Anfrageobjekten, das Hinzufügen von Entitäten zum Index anhand gegebener Schlüssel-Wert-Paare und das Löschen von Index-Einträgen anhand von Entitäten, Schlüssel-Entitäts-Paaren und Schlüssel-Wert-Entitäts-Tripeln. Eine automatische Indizierung wird rudimentär unterstützt. Das DBMS legt hierfür je einen Index für Knoten und einen für Kanten an, der Nutzer kann je eine Liste von Attributnamen spezifizieren. Für jeden angelegten Knoten/jede angelegte Kante werden diese Attribute dann automatisch dem Knoten-/Kantenindex hinzugefügt. Mitgeliefert wird als Index-Plugin Apache Lucene [Apache, 2012]. Lucene ist eine Softwarebibliothek zur Indizierung von Volltexten. Es basiert auf Dokumenten als Datenmodell. Dokumente sind eine Menge von benannten Feldern, welche wiederum eine Menge von Volltexten enthalten. Volltexte sind eine geordnete Liste von Termen. Lucene speichert stark vereinfacht zu jedem Term eine Liste der Dokumente und Positionen im Dokument, in denen der Term vorkommt [Apache, 2012, File Formats] 3. Bei der Anwendung als Index-Plugin für Neo4j wird für jede indizierte Entität ein Dokument erstellt mit je einem Feld pro indiziertem Schlüssel und den indizierten Werten als Feldinhalt. Lucene hat eine eigene Anfragesprache, welche weit über das reine Abfragen von Schlüssel-Wert-Paaren hinausgeht [Apache, 2012, Query Syntax]. Sie erlaubt die AND-, OR- sowie NOT-Verknüpfung verschiedener Schlüssel-Wert-Paare als Anfragebedingung, das Suchen von Werten per Wildcard, Anfragen nach numerischen und nichtnumerischen Wertebereichen und Relevanzsortierung von Ergebnissen. Solche nativen Anfragen können als Plugin-spezifische Anfragen ebenfalls über die beschriebene Neo4j Index API gestellt werden Anfragemechanismen Neo4j unterstützt vier verschiedene Anfragemechanismen unterschiedlicher Mächtigkeit. Sämtliche Anfragemechanismen werden sowohl im Embedded-Modus als auch über die REST-API unterstützt. Ihnen gemeinsam ist ebenfalls, dass Ergebnisse in der 3 Apache Lucene hat einen deutlich größeren Funktionsumfang als hier vorgestellt. Da das Neo4j- Plugin aber nur einen Bruchteil dessen nutzt, wird an dieser Stelle auf eine ausführlichere Beschreibung verzichtet. 30

31 Regel iteratorbasiert zurückgegeben werden. Ergebnisse werden, sofern dies möglich ist, erst dann berechnet, wenn der Nutzer sie ausliest. Hiermit unterscheidet es sich beispielsweise von vielen klassischen relationalen Datenbankmanagementsystemen, die erst die komplette Ergebnismenge berechnen, um sie dann zurückzugeben. Dieses Verhalten ermöglicht potentiell kürzere Reaktionszeiten bei in der Summe vermutlich eher langsamerer Anfragebearbeitung 4. Elementare Kanten- und Knotenoperationen Die wohl einfachste Möglichkeit der Interaktion mit Neo4j stellen die elementaren Kanten- und Knotenoperationen dar. Sie erlauben Schreib- und Leseoperationen. So können Knoten und gelabelte Kanten zwischen Knoten erstellt und gelöscht sowie Properties einzelner Knoten und Kanten erstellt, geändert und gelöscht werden. Ausgelesen werden können Knoten mit ihren Properties sowie ihren eingehenden und ausgehenden Kanten und Kanten mit ihren Labeln, Properties sowie Start- und Endknoten. Dies erlaubt bereits das Auslesen und Verändern sämtlicher Daten, auch wenn viele komplexe Anfragen, bspw. nach kürzesten Pfaden, in der Anwendungssoftware implementiert werden müssen. Das Traversal Framework Diese Lücke schließt das Traversal Framework. Es erlaubt die deklarative Spezifikation und Ausführung von Breiten- und Tiefensuchen im Datenbestand. Grundsätzlich werden hierbei Pfade gesucht und zurückgegeben, wobei optional auch nur der Endknoten oder die Endkante betrachtet werden kann. Es werden nur lesende Anfragen unterstützt. Eine Anfrage besteht aus mehreren Elementen: Einer Menge von Ausgangsknoten. Der Angabe, ob es sich um eine Tiefen- oder Breitensuche handeln soll. Der Angabe, wie oft einzelne Knoten und Kanten traversiert werden dürfen. Mögliche Werte sind hier wahlweise für Knoten oder für Kanten: Beliebig oft, maximal einmal pro Ergebnispfad oder insgesamt maximal einmal. Der Angabe, welchen Kanten gefolgt werden soll. Hier kann nach Label und Richtung selektiert werden, wobei Mehrfachnennungen möglich sind. 4 Dies ist zu vermuten, da bei einer Abarbeitung an einem Stück ein besseres Caching auf verschiedenen Ebenen (Hardware, Betriebssystem, DBMS) möglich scheint. 31

32 Einem Abbruchkriterium. Es gibt für jeden traversierten Knoten und für jede traversierte Kante an, ob von diesem Punkt aus weiter in die Tiefe traversiert werden soll. Dies wird im Embedded-Modus als Java-Objekt (Callback), bei der Nutzung per REST-API als ECMAScript-Ausdruck spezifiziert. Einem Filterkriterium. Es bestimmt für jeden traversierten Knoten und jede traversierte Kante, ob der bis dato traversierte Pfad in der Ergebnismenge enthalten sein soll. Es wird im Embedded-Modus als Java-Objekt (Callback), bei der Nutzung per REST-API als ECMAScript-Ausdruck spezifiziert. Einem Expander (nur im Embedded-Modus). Ein Expander bestimmt für einen gegebenen und bereits traversierten Pfad, welche Kanten weiter zu verfolgen sind. Ist er gegeben, so ersetzt er die oben beschriebene Angabe der Kanten- Labels und Kantenrichtungen. Der Expander wird als Java-Objekt (Callback) übergeben. Einer Branch Ordering Policy (nur im Embedded-Modus). Hat die Suche einen Knoten erreicht, so gibt es potenziell mehrere Kanten, welche verfolgt werden können. Die Branch Ordering Policy definiert hierfür eine Reihenfolge. Hiermit können Heuristiken implementiert werden, welche Kanten erfolgversprechender, relevanter oder kürzer sind. Diese werden dann als Erstes verfolgt. Die Branch Ordering Policy wird als Java-Objekt (Callback) übergeben. Einem Pfadkomparator (nur im Embedded-Modus). Er bestimmt die Sortierung der Ergebnispfade und wird als Java-Objekt (Callback) übergeben. Da die als Callback übergebenen Java-Objekte einen eigenen Zustand haben können und Java Turing-vollständig ist, ergibt sich eine daraus ein sehr ausdrucksstarkes Framework. Viele der Probleme, welche als Breiten- oder Tiefensuchen spezifizierbar sind, sollten hiermit modellierbar sein. Es scheint, als würde die Produktstrategie von Neo Technology dahin gehen, das Traversal Framework mittelfristig durch die Cypher Query Language zu ersetzen 5. Die Cypher Query Language Die Cypher Query Language ist eine domänenspezifische Sprache zur Abfrage und Veränderung von Graphen. Sie erinnert syntaktisch an SQL und SPARQL. 5 In einem Kommentar zu [Neo Technology, 2012, 18.13] schreibt dazu Peter Neubauer, ein Mitarbeiter von Neo Technology: Also, I agree that this traversal logic is not the best example of a restful API. It mimics the Java counterpart which does not work out good. For something better, please try out sending cypher over REST. I am sure that will out better, and I hope we can retire the traversal part of the REST API soon, as cypher takes its place. 32

33 Cypher kombiniert rein graphbasierte Anfragesemantiken wie das Matching regulärer Graph-Ausdrücke und das Suchen von Pfaden mit relationalen Anfragesemantiken, insbesondere der Arbeit mit Mengen gleichförmiger Tupel 6 als grundlegender Datenstruktur. Elementare Datentypen der Anfragesprache sind Knoten, Kanten, Pfade, Strings, elementare Java-Datentypen sowie Tupel aus diesen. Eine Cypher-Anfrage definiert zunächst verschiedene Variablen und gibt Regeln für deren Bindung an Knoten des Graphen an (mittels der START -Klausel). Daraus resultiert eine Menge von Tupeln, wobei jedes Element eines Tupels einer Variablen, jedes Tupel einer möglichen Belegung entspricht. Diese Tupelmenge kann daraufhin auf verschiedene Weisen verändert werden: Durch Selektion (WHERE-Klausel) können, ähnlich wie mittels der gleichnamigen Klausel in SQL, einzelne Tupel anhand eines boolschen Ausdrucks über den Eigenschaften ihrer Elemente (Wert, Properties, Label) aus der Ergebnismenge entfernt undwerden. Durch Projektion (WITH - und RETURN -Klauseln) kann die Struktur der einzelnen Tupel, ähnlich wie mittels der SELECT -Klausel in SQL, gleichförmig verändert werden, wobei auch neue (berechnete) Elemente zu den vorhandenen Tupeln hinzugefügt werden können. Die neuen Tupel-Elemente werden dabei jeweils durch Ausdrücke über den alten Tupeln definiert. Durch Aggregation (ebenfalls mit WITH - und RETURN -Klauseln) können je mehrere Tupel zu je einem mittels einer Aggregationsfunktion zusammengefasst werden. Dies funktioniert ähnlich wie die Kombination aus der SELECT - und der GROUP BY -Klausel in SQL. Durch das Matching regulärer Graph-Ausdrücke (MATCH -Klausel) kann aus einer Ausgangsmenge eine neue Ergebnismenge generiert werden: Für jedes Tupel der Ausgangsmenge werden die einzelnen Variablen des Tupels an gleichnamige Variablen des Graph-Ausdrucks gebunden. Dieser Graphausdruck, mit eventuell ungebundenen Variablen, wird sodann gegen den Graphen gematched. Jede mögliche gültige Variablenbelegung ergibt dann ein Tupel der Ergebnismenge. Hierbei bleiben Variablen des Ausgangstupels, welche nicht an eine Variable des Patterns gebunden wurden, unverändert im Ergebnistupel erhalten. Durch Sortierung (ORDER BY -Klausel) kann die Reihenfolge der Ergebnismenge (ähnlich wie mittels der gleichnamigen Klausel in SQL) geändert werden. Durch Paginierung (SKIP- und LIMIT -Klauseln) können bestimmte Bereiche der Ergebnismenge entfernt werden. 6 Wenn hier von Mengen die Rede ist, so meint dies streng mathematisch Tupel, da deren Elemente eine Ordnung haben und mehrfach vorkommen können. Zu Gunsten der leichteren Intuition spricht dieses Unterkapitel dennoch von (Ergebnis-) Mengen, statt von Multimengen oder Tupeln. 33

34 Beispielhaft sei in Listing 6.1 eine Anfrage gegeben, welche potentiell schwierige Beziehungskonstellationen im mittelbaren Freundeskreis von John Doe in einem fiktiven sozialen Graphen sucht. START person = node:personen(name= John Doe ), c = node(15) MATCH a [:LIEBT] >b, b [:LIEBT] >c, c [:LIEBT] >a, p=shortestpath(person [:FREUND VON 3] a) WHERE c.alter < 18 RETURN a, b, c, c.alter, LENGTH(p) AS abstand ORDER BY abstand ASC Listing 6.1: Beispiel einer rein lesenden Cypher-Anfrage Diese Anfrage selektiert zunächst eine Menge von Knoten, indem ein Index namens personen nach all jenen Knoten angefragt wird, deren Feld name genau John Doe enthält. Diese werden an die Variable person gebunden. Außerdem wird eine einelementige Knotenmenge selektiert, indem eine Variable c an den Knoten mit der Id 15 gebunden wird. Das kartesische Produkt aus diesen beiden Mengen, eine Menge zweielementiger Tupel aus Knoten, stellt die initiale Tupelmenge dar - die Menge aller gültigen Belegungen der beiden Variablen. Daraufhin wird ein Graph-Pattern spezifiziert. Hierfür werden drei neue Variablen eingeführt: a, b und p. a muss ein Knoten sein, welcher mit einer ausgehenden Kante mit dem Label LIEBT mit einem Knoten b verbunden ist, selbiges gilt für die Paare b/c und c/a. Darüber hinaus muss ein Pfad zwischen einer der eingangs selektierten Personen und dem Knoten a existieren, welcher maximal 3 Kanten enthält, welche alle das Label FREUND VON besitzen. Durch das Fehlen des Pfeils im Pattern werden die Kanten hier unabhängig von ihrer Richtung betrachtet. Der Kürzeste dieser Pfade wird an die Variable p gebunden. Nach diesem Matching-Schritt besteht die Ergebnismenge aus fünfelementigen Tupeln, bestehend aus je einem Element für person, a, b, c und p. Jedes der Tupel stellt eine gültige Belegung des Patterns dar. Die Ergebnismenge wird nach der Property alter des Knotens c gefiltert, mittels der RETURN-Klausel projeziert und mittels ORDER BY nach der Pfadlänge sortiert zurückgegeben. Die MATCH-, WITH- (hiermit lassen sich Zwischenprojektionen und Zwischenaggregationen realisieren) und WHERE-Klauseln können beliebig oft in beliebiger Reihenfolge kombiniert werden. Es ist so beispielsweise möglich, die Ergebnismenge eines regulären Graph-Ausdrucks zu aggregieren, das Ergebnis anhand der aggregierten Werte zu filtern und mit dem gefilterten Ergebnis wiederum reguläre Graph-Ausdrücke zu matchen. 34

35 Cypher bietet darüber hinaus auch die Möglichkeit, den Graphen zu verändern. Hierfür können CREATE-Klauseln für das Erstellen von Knoten und Kanten, DELETE-Klauseln zum Entfernen ebendieser und SET-Klauseln zum Setzen von Properties auf bestehenden Knoten und Kanten genutzt werden. Diese Klauseln können überall dort verwendet werden, wo auch MATCH-, WHERE- und WITH-Klauseln verwendet werden können und haben dann Zugriff auf die jeweils dort aktuelle Ergebnismenge. Sie werden allerdings erst nach der Generierung der endgültigen Ergebnismenge angewendet, so dass sie auf das endgültige Ergebnis keinen Einfluss haben. Cypher stellt somit eine sehr mächtige und vielseitig einsetzbare Anfragesprache für Graphanfragen dar. Sie bietet auf der einen Seite mehr Möglichkeiten als das Traversal Framework, da sie nicht nur Pfade, sondern auch anders strukturierte und konstruierte Ergebnismengen berechnen kann. Auch bezüglich der Möglichkeit, ausgehend von mehreren Knoten zu traversieren, ist sie dem Traversal-Framework voraus. Das Traversal-Framework bietet jedoch auf der anderen Seite die Möglichkeit, beliebigen Java/JavaScript-Code als Teil der Anfrage auszuführen, was wiederum andere Möglichkeiten eröffnet (bspw. die Integration anderer Datenquellen in die Anfragebearbeitung) Transaktionen Neo Technology bewirbt Neo4j mit dessen Unterstützung für Transaktionen und dessen Einhaltung der ACID-Eigenschaften. Dies geschieht auf unterschiedliche Weisen in unterschiedlichem Ausmaß. Im Embedded-Betrieb ist es möglich, eine Transaktion zu beginnen und nach der Ausführung beliebiger Schreib- und Leseoperationen als erfolgreich oder nicht erfolgreich zu markieren. Diese wird daraufhin entsprechend abgeschlossen (commit) oder zurückgerollt (rollback). Leseoperationen können auch außerhalb einer Transaktion ausgeführt werden. Es werden sogenannte Flat Nested Transactions unterstützt. Diese bieten keine Isolation zu anderen Subtransaktionen der selben Elterntransaktion oder zu letzterer selbst. Wird eine Subtransaktion als nicht erfolgreich markiert, so ist unwiderruflich auch die Elterntransaktion nicht erfolgreich und wird beim Abschluss der selben zurückgerollt. Im Server-Betrieb können mehrere Lese- und Schreiboperationen gebündelt an den Server übermittelt werden. Einzelne Operationen können dabei auf die Ergebnisse vorangegangener Operationen referenzieren, bspw. um eine Kante zwischen zwei soeben angelegten Knoten hinzuzufügen. Sie werden dann als eine Transaktion ausgeführt, die fehlschlägt, sobald eine der Teiloperationen fehlschlägt. Neo4j garantiert keine serialisierbaren Ausführungspläne der Transaktionen. Es garantiert jedoch, dass eine Transaktion nur solche Daten lesen kann, welche entweder von ihr selbst, oder von einer bereits abgeschlossenen Transaktion geschrieben 35

36 wurden 7. Dies vermeidet das Lesen aus nicht abgeschlossenen Transaktionen, lässt aber weiterhin die Möglichkeit von nicht wiederholbarem Lesen und verlorenen Schreiboperationen. Das DBMS kann folglich mangels ausreichender Isolation nicht garantieren, dass sich die Datenbank stets in einem konsistenten Zustand befindet. Die ACID-Kriterien sind somit bezüglich dieser beiden Punkte nicht vollständig erfüllt. Technisch wird dies dadurch gelöst, dass die Transaktion beim ersten schreibenden Zugriff auf eine Entität (Knoten oder Kante) eine exklusive Schreibsperre auf diese anfordert und alle Sperren bis zum Ende der jeweiligen Transaktion hält. Im Embedded-Modus kann darüber hinaus der Nutzer selbst weitere teilbare Lese- oder exklusive Schreibsperren beim DBMS anfordern, welche ebenfalls bis zum Ende der Transaktion gehalten werden. Dadurch ist es dem Nutzer möglich, die geschilderten Isolationsprobleme zu umgehen und serialisierbare Schedules sicherzustellen. Über die REST-API ist dies nicht möglich. Das DBMS erkennt hierbei mittels eines Wait- For-Graphen, ob das Anfordern einer Sperre zu einem Deadlock führen würde und bricht die anfordernde Transaktion in diesem Fall mit einer Exception ab Gioran [2010c]. Atomarität und Dauerhaftigkeit von Transaktionen werden in vollem Umfang garantiert. Dies geschieht, in dem mittels eines Write-Ahead-Logs jede schreibende Operation zuerst in eine Log-Datei geschrieben wird. Beim Commit werden dann, nachdem der Commit ebenfalls im Log vermerkt wurde, die einzelnen Schreiboperationen in chronologischer Reihenfolge auf den eigentlichen Datenbestand angewendet. Kommt es zwischenzeitlich zu einem Ausfall des Systems, so können beim nächsten Start die noch nicht vollständig in den eigentlichen Datenbestand geschriebenen Transaktionen aus dem Log rekonstruiert und das Übertragen fortgesetzt werden (REDO-Algorithmus) Gioran [2010c]. Die mitgelieferte Lucene Index-Bibliothek erfüllt ebenfalls die ACID-Eigenschaften. Sie realisiert dies, indem Sie jeweils nur einen schreibenden Zugriff gleichzeitig zulässt und die Indexzustände versioniert. Dadurch arbeiten lesende Transaktionen stets auf der zuletzt erfolgreich committeten Version. Erst, wenn die schreibende Transaktion vollständig geschrieben ist, werden die lesenden Transaktionen auf die neue Version geschwenkt. 8 Dies entspricht dem Isolationslevel des Neo4j-Kerns (READ COMMITTED) Persistenz und Caching Die Persistenz- und Caching-Architektur von Neo4j besteht aus dem Datenspeicher selbst sowie zwei Cache-Ebenen. 7 Dies entspricht dem von relationalen Datenbankmanagementsystemen bekannten Isolationslevel READ COMITTED. 8 Quelle: Dokumentation der IndexWriter-Klasse in der Lucene Core JavaDoc: apache.org/core/3_6_1/api/core/org/apache/lucene/index/indexwriter.html. 36

37 Gespeichert werden die Daten in einem vom Nutzer bestimmbaren Verzeichnis des Dateisystems. Dieses Verzeichnis enthält dabei alle Dateien und Unterverzeichnisse, welche zu einer Datenbank gehören. Eine Datenbank ist nicht benannt, sondern wird ausschließlich über dieses Verzeichnis identifiziert. Die Daten des Neo4j-Kerns werden in Dateien gespeichert [Gioran, 2010a]. Jeweils eine Datei dient dabei der Speicherung von Knoten, Kanten, Kantentypen, Properties, Propertywerten dynamischer Länge, etc. Diese Dateien bestehen aus Records jeweils fester Größe. Die Knoten- und Kanten-Ids entsprechen dabei jeweils dem Index des dazugehörigen Records in der entsprechenden Datei, so dass das Lesen ebendieser bei bekannter Id prinzipiell mit O(1) Operationen möglich ist. Beim Löschen von Records werden deren Indizes in je einer seperaten Datei gespeichert und anschließend wiederverwendet. Können mehrere Records eines Typs zusammengehören, beispielsweise alle Kanten eines Knotens, so werden diese mittels ihrer Record-Ids zu Listen verkettet. Ebenso wird mit Datentypen variabler Länge verfahren (Strings und Arrays): Für diese gibt es je eine Datei. Passt ein Datum nicht in einen Record, so wird es auf mehrere, doppelt verkettete Records aufgeteilt. Neo4j verknüpft logisch verknüpfte Entitäten bereits auf der Persistenzebene: Ein Knoten-Record enthält die Record-Id seiner ersten Kante. Jede Kante ist Teil von zwei doppelt verketteten Kantenlisten, jeweils eine pro beteiligtem Knoten. Ein Kanten-Record enthält darüber hinaus die Record-Ids der beteiligten Knoten. Somit ist das Abfragen aller inzidenten physischen Knoten-Ids zu einer gegebenen physischen Ausgangsknoten-Id in O(n) möglich, wobei n die Anzahl der inzidenten Kanten des Ausgangsknotens ist: Vom Ausgangsknoten aus lässt sich die erste Kante laden (O(1)). Von dort aus können die miteinander verketteten Kantenliste durchsucht werden (O(n)). Für jede der Kanten kann die Id ihres Endknotens ausgelesen werden (O(1)). Kanten können in beide Richtungen gleich effizient traversiert werden. Die zweite Ebene der Persistenzarchitektur stellen die Datei-Caches dar [Gioran, 2010b; Neo Technology, 2012, 22.3]. Für jede der oben beschriebenen Dateien existiert ein Cache konfigurierbarer Größe. Die Dateien werden in sogenannte Fenster gleicher Größe eingeteilt. Diese Fenster werden gecachet, entweder im Java-Heap oder, sofern vom Betriebssystem unterstützt, mittels Memory Mapping. Ist ein Dateicache voll, so werden periodisch die Fenster, welche weniger oft gelesen wurden, durch diejenigen ungecacheten ersetzt, welche häufiger gelesen wurden (LFU). Dieses Caching dient zwei Zwecken: Zum einen können Seiten, auf die häufig lesend zugegriffen wird, im Hauptspeicher gehalten und somit Festplatten-IO eingespart werden. Zum anderen ist es, da das REDO-Log spätestens beim erfolgreichen Transaktionsabschluss auf der Festplatte persistiert ist, möglich, das Aktualisieren der Daten selbst lediglich im Cache vorzunehmen. Diese Cache-Seiten können dann zu einem späteren Zeitpunkt auf die Platte geschrieben werden. Die dritte Ebene der Persistenzarchitektur stellt der Objekt-Cache dar [Neo Technology, 2012, 22.3]. Dieser speichert die zu den einzelnen Knoten-, Kanten- und Properties 37

38 gehörenden Java-Objekte. Da hier echte Java-Objekte gespeichert werden, sind die Größen der jeweiligen Entitäten deutlich höher, es passen also weniger Elemente in die selbe Menge an Hauptspeicher. Dieser Cache dient dazu, das zeitintensive Instantiieren von Java-Objekten möglichst zu vermeiden. Dies bringt insbesondere beim Traversieren Vorteile, wenn derselbe Knoten innerhalb kurzer Zeit über viele verschiedene Pfade erreicht wird. Der Cache basiert auf Soft- bzw. WeakReferences 9. Dies sind Java-Objektreferenzen, welche es dem Java Garbage Collector erlauben, referenzierte Objekte nach (nahezu) eigenem Ermessen zu entfernen, sofern keine normalen Referenzen (bspw. von anderen Teilen der Applikation) zu ihnen mehr gehalten werden. Für das Caching wird sämtlicher verfügbarer Java-Heap verwendet. Der Garbage Collector leert den Cache dann, wie beschrieben, bei Bedarf. Dies kann gerade in Hochlastsituationen zu unerwünschten Effekten wie häufiger Garbage Collection und damit Performance- Einbußen führen [Neo Technology, 2012, ]. Daten (Knoten, Kanten und deren Properties) werden stets erst dann geladen, wenn auf sie zugegriffen wird. So können bspw. auch Kanten mit sehr großen Attributmengen sehr schnell geladen und traversiert werden. Dies geht aber mit dem Nachteil höherer Latenz beim Zugriff auf diese Daten einher Skalierbarkeit und Ausfallsicherheit Die Enterprise-Version von Neo4j bietet die Möglichkeit, Neo4j als Cluster aufzusetzen - sowohl im Embedded-Modus als auch als REST-Server [Neo Technology, 2012, 23]. So ist es auch möglich, eine Neo4j-Instanz aus mehreren Prozessen im Embedded- Betrieb zu nutzen. Hierbei dient eine der Instanzen als Master-, alle anderen als Slave-Instanzen. Lese- und Schreiboperationen können jeweils sowohl auf der Masterals auch auf den Slave-Instanzen ausgeführt werden. Lesetransaktionen werden sowohl von der Master- als auch von den Slave-Instanzen jeweils aus dem lokalen Datenbestand beantwortet. Wird eine Schreiboperation auf einer Slave-Instanz ausgeführt, so agiert diese als Proxy: Sämtliche Operationen werden an den Master weitergereicht. Fällt der Master während einer Transaktion aus, so schlägt auch die Transaktion fehl. Mit jeder Antwort des Masters erhält die Slave- Instanz Informationen über die zwischenzeitlich auf dem Master abgeschlossenen Transaktionen 10, welche sie zum Aktualisieren des lokalen Datenbestandes nutzt. 9 SoftReferences sind dokumentiert unter lang/ref/softreference.html, WeakReferences unter docs/api/java/lang/ref/weakreference.html, jeweils abgerufen am 26. März Zu finden in Version 1.8.M07 in Methode <T> T receive(response<t> response) der Klasse org.neo4j. kernel.highlyavailablegraphdatabase.localdatabaseoperations: kernel/highlyavailablegraphdatabase.java, abgerufen am 22. September

39 Darüber hinaus aktualisieren sich Slave-Instanzen periodisch durch Polling der Master-Instanz. Bezüglich Lesezugriffen skaliert Neo4j somit horizontal, bei Schreibzugriffen jedoch nur vertikal, da jede Schreiboperation auf dem Master ausgeführt wird und es hiervon nur genau einen geben kann. Da jede Slave-Instanz ihre Daten vom Master repliziert, steigt die Last des Masters zusätzlich zur Schreiblast auch mit der Anzahl der Slave- Instanzen, so dass auch hier der Skalierbarkeit Grenzen gesetzt sind. Auch bezüglich der Datenmenge skaliert Neo4j lediglich vertikal, da jede Instanz eine lokale Kopie des vollständigen Datenbestandes halten muss. Fällt eine Slave-Instanz aus, so ist die Funktion des Clusters als ganzes unbeeinträchtigt. Fällt die Master-Instanz aus, so übernimmt eine andere Slave-Instanz deren Rolle. Zur Koordination dessen nutzt Neo4j einen zusätzlich zu betreibenden von Apache Zookeeper Cluster [Hunt et al., 2010]. Hierin speichert jede Instanz die Id der höchsten in ihrem Datenbestand abgeschlossenen Transaktion. Außerdem dient er zur Speicherung der Menge der aktiven Neo4j-Instanzen und zur Benachrichtigung bei Ausfällen dieser. Neuer Master wird nun stets der, dessen Transaktions-Id am höchsten ist. Existieren mehrere solche, so gewinnt der mit der kleinsten Instanz- Id [Gioran, 2012]. Auch beim Ausfall der Masterinstanz bleibt der Cluster also verfügbar. Auch gegen bestimmte Partitionierungsmuster des Netzwerks ist Neo4j tolerant [Neo Technology, 2012, 23]Gioran [2012]: Sofern mehr als die Hälfte der Instanzen eines Zookeeper-Clusters noch miteinander kommunizieren können, bleibt dieser Teil verfügbar. Solange der Neo4j-Cluster Zugriff auf mindestens eine dieser Instanzen hat, bleibt auch dieser für Schreib- und Lesezugriffe verfügbar. Verliert die Master- Instanz die Verbindung zum Zookeeper-Cluster, so wird dieser die erreichbaren Slave-Instanzen hierüber benachrichtigen und diese werden einen neuen Master aus ihrer Mitte wählen. Verliert eine Slave-Instanz ihre Verbindung zur Master-Instanz, so wird diese den Versuch starten, einen neuen Master zu wählen. Alle Instanzen, die weiterhin eine Verbindung zum Master haben, können weiterhin auch Lese- und Schreiboperationen ausführen. Werden schreibende Transaktionen stets gegen eine Slave-Instanz ausgeführt, so existiert auch stets, selbst bei Ausfall des Masters, ein redundanter Datenbestand bei diesem, so dass die Dauerhaftigkeit der Datenspeicherung gesichert bleibt. Erst wenn sowohl die Master als auch die als Schreib-Proxy genutzte Slave-Instanz gleichzeitig ausfallen, kann es zu einem Datenverlust kommen. Die dann gewählte neue Master- Instanz hat dann einen veralteten, aber in sich konsistenten Datenbestand. Diese Fehlertoleranz geht allerdings einher mit einem Verzicht auf Datenkonsistenz innerhalb des Clusters: Da die Slave-Instanzen ihren Datenbestand lediglich periodisch und bei schreibenden Zugriffen abgleichen, sind abgeschlossene Transaktionen nicht sofort auf allen Instanzen innerhalb des Clusters sichtbar. Werden beispielsweise Leseund Schreibzugriffe zufällig mittels eines Loadbalancers über die Knoten verteilt, so 39

40 können von den jeweiligen Instanzen völlig unterschiedliche Ergebnisse für die selben Anfragen zurückkommen. Nach einiger Zeit ohne Schreibzugriffe befinden sich jedoch alle Instanzen wieder auf dem gleichen, konsistenten Stand. Dieses Verhalten wird auch als Eventual Consistency bezeichnet FlockDB FlockDB [Pointer et al., 2010] wurde von Twitter entwickelt und steht unter der freien Lizenz Apache License 2.0 zur Verfügung. FlockDB basiert auf dem Datenmodell eines gerichteten Graphen mit zwei Arten von Kantenlabeln. Die Knoten werden durch eine ganzzahlige Id identifiziert. Eines der Kantenlabels ist nutzerdefiniert, ganzzahlig und dient der Sortierbarkeit (Anfrageergenisse sind stets nach diesem Label sortiert), das andere dient der Anwendung zur Statuskennzeichnung (normal, gelöscht, archiviert oder negiert). FlockDB ist schemalos, Kanten können unabhängig von ihren Labels zwischen beliebigen Knoten existieren. Knoten ohne inzidente Kanten werden nicht unterstützt. Ein FlockDB-Cluster kann mehrere Datenbanken (Graphen), welche über eine ganzzahlige Id identifiziert werden, verwalten. Da aber Anfragen sich auch über mehrere Graphen erstrecken können, kann diese Graph-Id auch als weiteres ganzzahliges Kantenlabel genutzt werden. Dies ist bei der Beispieldatenbank in Abbildung 6.2 der Fall, die als Sammlung solcher Teilgraphen visualisiert ist je einer pro Kantenlabel. Die Überschriften der Teilgraphen dienen der einfacheren Vergleichbarkeit von FlockDB gespeichert wird lediglich die numerische Graph-Id. FlockDB ist kein eigenständiges Datenbankmanagementsystem. Es ist eine Mediatorsoftware, welche einen MySQL-Cluster verwaltet, nach außen allerdings eine graphbasierte Schnittstelle anbietet. FlockDB ist somit ein von Grund auf verteiltes Datenbankmanagementsystem. Es unterstützt weder vom Nutzer steuerbare Indizierung noch ACID-Transaktionen Anfragemechanismen FlockDB nimmt Anfragen über eine API basierend auf Thrift [Slee et al., 2007] entgegen, einem von Facebook entwickelten, plattformneutralen RPC-Mechanismus. Es unterstützt zwei Arten von Anfragen: Elementare Knoten- und Kantenoperationen sowie komplexe, mengenbasierte Leseoperationen Es existiert nur wenig Dokumentation zu den Anfragemöglichkeiten, als Quelle diente hier die Thrift-Interfacedefinitionsdatei unter 1d70e2b1f705cde5bc3918de25b58d085c54144a/src/main/thrift/Flockdb.thrift, die darin enthaltenen Kommentare sowie Recherchen im Code von FlockDB. 40

41 Abbildung 6.2.: Beispielhafte Darstellung einer FlockDB-Datenbank 41

42 int FOLLOWS = 1; int BLOCKS = 2; List<PagedNodeIdList> result = myflockdbconnection. select ( difference ( intersect ( simpleselection(personaid, FOLLOWS, INCOMING), simpleselection(personbid, FOLLOWS, INCOMING) ), simpleselection(personcid, BLOCKS, OUTGOING) ) ).execute(); Listing 6.2: Beispiel einer komplexen Selektionsanfrage in FlockDB [Gehrels, 2013] Elementare Operationen bieten die Möglichkeiten, Kanten anhand ihrer Quell- und ihrer Ziel-Id abzufragen. Das Ergebnis enthält neben Quell- und Ziel-Id den Statusund die Sortierungs-Labels der Kante. Außerdem ist es möglich, Metadaten zu einzelnen Knoten anhand ihrer Knoten-Id abzufragen. Das Ergebnis enthält neben der Knoten-Id die Anzahl der ausgehenden Kanten. Zuletzt ist auch das Hinzufügen von neuen Kanten sowie das Markieren von Kanten als gelöscht, archiviert und negiert möglich. Letztere drei Anfragen funktionieren auch als Wildcard-Queries, z.b.: Lösche alle von Knoten x ausgehenden Kanten. Komplexe Suchanfragen sind ebenfalls möglich. Ihr Grundbaustein ist die Selektion. Selektiert wird nach einer Ausgangsknoten-Id, einer Richtung, einer Menge von Kantenstati und einer optionalen Menge von Zielknoten-Ids. Aus mehreren Selektionen resultierende Ausgangsmengen können mittels Vereinigung, Differenz und Schnittmengenoperationen zu einer Ergebnismenge kombiniert werden. Die Ergebnisse können paginiert werden. Traversierende Anfragen werden nicht unterstützt. Ein einfaches Beispiel (ohne Zielknoten- oder Kantenstatusspezifikation) ist in Listing 6.2 dargestellt. Es beantwortet die Frage Welche Personen folgen persona und personb, ohne von personc blockiert worden zu sein? Persistenz und Caching FlockDB persistiert seine Daten in einem selbstverwalteten MySQL-Cluster. Hierbei werden pro Graph je vier Tabellen mittels der Storage-Engine InnoDB verwaltet. 12 Der Beispiel-Code arbeitet nicht mit der original FlockDB Thrift API sondern mit einem im Rahmen dieser Arbeit entstandenen leichtgewichtigen Java-Wrapper [Gehrels, 2013] um diese. Dies dient der Anschaulichkeit, da der automatisch aus der Thrift-Interface-Definition generierte Java-Code nicht sonderlich gut lesbar ist. 42

43 CREATE TABLE edges ( source id INT UNSIGNED NOT NULL, position BIGINT NOT NULL, updated at INT UNSIGNED NOT NULL, destination id INT UNSIGNED NOT NULL, count TINYINT UNSIGNED NOT NULL, state TINYINT NOT NULL, PRIMARY KEY (source id, state, position), UNIQUE src dest (source id, destination id) ) ENGINE=INNODB Listing 6.3: SQL-Schema der FlockDB Kantentabellen CREATE TABLE metadata ( source id INT UNSIGNED NOT NULL, count INT NOT NULL, state TINYINT NOT NULL, updated at INT UNSIGNED NOT NULL, PRIMARY KEY (source id) ) ENGINE=INNODB Listing 6.4: SQL-Schema der FlockDB Knotentabellen Davon sind je zwei paarweise schematisch identisch, ein Paar verwaltet die eingehenden Kanten von Knoten, ein Paar die ausgehenden. Jedes Paar besteht aus einer Tabelle, welche die (ein- bzw. ausgehenden) Kanten, (Listing 6.3) und einer Tabelle, welche zu jedem Knoten die Anzahl der (ein- bzw. ausgehenden) Kanten mitsamt einem Zeitstempel speichert (Listing 6.4). Eine MySQL-Instanz hält hierbei in der Regel nicht den gesamten Datenbestand, sondern lediglich eine Partition hiervon. Somit müssen sich die Tabellen für eingehende und ausgehende Kanten auch nicht zwingend in der selben MySQL-Instanz befinden. Vier Optimierungen werden von FlockDB getroffen: Erstens werden alle Kanten eines Knotens stets in der selben Partition gespeichert, so dass Anfragen zu einem Knoten von einer einzigen Partition beantwortet werden könne. Zweitens ist es, da InnoDB den Primärschlüssel der Kantentabelle als B-Baum implementiert [Oracle, 2012, ], möglich, die inzidenten aktiven Knoten eines gegebenen Knotens in O(log( E ) + m) abzufragen 13, wobei m die Anzahl dieser inzidenten Kanten ist: O(log E ) für das 13 Oracle [2012, ] erwähnt nicht, welche genaue B-Baum-Variante genutzt wird, schreibt aber, dass die Nutzdaten in den Blattknoten liegen. Es erscheint wahrscheinlich, dass hierbei eine Variante genutzt wird, die effiziente Range-Queries, bspw. durch Verkettung der Blattknoten 43

44 Auffinden des ersten Blattes, O(m) für das Auslesen der verketteten Folgeblätter, welche ihrerseits die Nachbarknoten-Ids als Werte enthalten. Da die Position (das Label, welches die Ordnung der Kanten repräsentiert) teil des Primärschlüssels ist sind die Ergebnisse auch ohne zusätlichen Aufwand sortiert. Drittens werden bei paginierten Anfragen die einzelnen Seiten nicht anhand ihres Offsets, sondern anhand des Positionslabels der letzten nicht mehr enthaltenen Kante adressiert. Somit muss für die Beantwortung nicht die gesamte Ergebnismenge berechnet werden, um daraus anhand eines Offsets die Seite zu extrahieren. Vielmehr kann, da die Position Teil des Primärschlüssels ist, die Paginierung anhand des Indizes berechnet werden. Viertens wird jede Kante in zwei Tabellen gespeichert, einmal in eingehender und einmal in ausgehender Richtung. Somit können Kanten in beide Richtungen gleich schnell abgefragt werden. FlockDB selbst cachet keine Daten, diese werden bei jeder Anfrage von den MySQL- Instanzen geladen, gegebenenfalls zusammengeführt und ausgegeben. Laut Pointer et al. [2010] war allerdings eines der Paradigmen beim Entwurf von FlockDB, dass die zu Grunde liegenden MySQL-Instanzen Caches nutzen, welche den kompletten Datenbestand der jeweiligen Instanz im Hauptspeicher halten. Die von MySQL genutzte Storage-Engine InnoDB nutzt hierfür einen LRU-Cache konfigurierbarer Größe [Oracle, 2012, 8.9.1] Transaktionen FlockDB bietet die Möglichkeit, mehrere Schreiboperationen zu einem einzelnen Request zu bündeln, was insbesondere für das Befüllen mit großen Datenmengen einen Performancevorteil bieten dürfte. ACID-Eigenschaften werden hierbei jedoch nicht garantiert. Insbesondere wird nicht garantiert, dass die geschriebenen Daten sofort lesbar sind. Eine Isolation zwischen nebenläufigen Prozessen ist ebenfalls nicht vorgesehen. Zwar greift FlockDB auf MySQL-Datenbanksysteme zur Datenpersistenz zurück, allerdings verlässt es sich nicht auf dessen Transaktionskontrolle, sondern implementiert eigene Mechanismen zur Vermeidung von Race Conditions bei nebenläufigen Zugriffen. Alle Schreiboperationen von FlockDB sind idempotent und kommutativ. Dies bedeutet, dass sie beliebig oft in beliebiger Reihenfolge ausgeführt werden können und dennoch das selbe Ergebnis entsteht. Dieses Verhalten wird erzielt, indem jedem Befehl ein Zeitstempel angehängt wird. Auch die Datenbankzeilen haben jeweils ein updated at -Feld, welches einen Zeitstempel ihrer letzten Änderung enthält. Die Schreibperationen sind nun so definiert, dass sie nur dann ausgeführt werden, wenn ihr Zeitstempel neuer ist als der der letzten Änderung des Datums. Andernfalls werden sie verworfen 14. ermöglicht. 14 Dies funktioniert nur dann absolut verlässlich, wenn die Uhren aller beteiligten Systeme absolut synchron laufen. Pointer et al. [2010] trifft hierzu allerdings keine Aussagen. 44

45 Serverseitig werden die einzelnen Operationen separat betrachtet und ausgeführt. FlockDB reiht alle Schreiboperationen in eine persistente lokale Queue ein. Hierfür wird Kestrel [Pointer, 2012] genutzt, eine persistente FIFO-Queue-Implementierung. Sind alle Schreiboperationen idempotent, kann Kestrel so konfiguriert werden, dass Atomarität und Dauerhaftigkeit gewährleistet sind. Kestrel nutzt hierfür ein REDO- Log und Rückbestätigung durch den lesenden Prozess. Somit ist sichergestellt, dass, sofern das Speichermedium nicht defekt ist, Schreiboperationen in FlockDB atomar und dauerhaft sind. Die MySQL-Instanzen, in welche die Daten schlussendlich geschrieben werden, verwenden die Tabellenengine InnoDB, welche alle ACID-Eigenschaften für die einzelnen Schreiboperationen garantiert. Da eine Einfügeoperation aber einzeln aus der Kestrel- Queue entnommen und ausgeführt wird, zerfällt das Einfügen von 100 Kanten in 100 einzelne SQL-Transaktionen. MySQL stellt hier also schlussendlich nur die Atomarität und Dauerhaftigkeit während des schlussendlichen Schreibvorgangs sicher. Es nutzt hierfür REDO-UNDO-Logging und RX-Locking auf Tabellenzeilenebene [Oracle, 2012, , , ] Skalierbarkeit und Ausfallsicherheit FlockDB ist ein von Grund auf verteiltes Datenbanksystem. Es wurde mit dem Ziel entworfen, keinen Single Point of Failure zu besitzen. FlockDB nutzt hierfür Gizzard [Kallen et al., 2010], eine ebenfalls von Twitter veröffentlichte Softwarebibliothek, welche das Sharding (Replikation und Partitionierung) von Daten sowie die Fehlererholung verwaltet. Gizzard tut dies nahezu unabhängig vom Datenmodell und den zugrunde liegenden Datenspeichern. FlockDB nutzt einen durch Gizzard verwalteten Cluster aus MySQL-Servern. Dieser dient als eigentlicher operativer Datenspeicher. Hierin werden die Kanten-Daten, die Knotenmetadaten und die Verwaltungsdaten des Clusters selbst gespeichert. Es werden allerdings nicht die Replikations- und Partitionierungsmöglichkeiten von MySQL genutzt. Statt dessen laufen die einzelnen MySQL-Instanzen als Stand-Alone- Datenbanksysteme, da Gizzard die Replikation und Partitionierung durchführt. Gizzard nutzt hierfür die Abstraktion eines Shards. Es gibt logische und physische Shards. Ein physisches Shard entspricht in FlockDB einem physischen Datenspeicher (Tabellen auf einem bestimmten MySQL-Server). Logische Shards haben die selbe Schnittstelle wie physischer Shards, speichern ihre Daten allerdings nicht selbst, sondern leiten Daten und Anfragen unter bestimmten Bedingungen an andere, verknüpfte Shards weiter. Ein logisches Shard kann beispielsweise ein replizierendes Shard sein, welches mit den einzelnen physischen Replikaten verknüpft ist. Es können zur Laufzeit beliebig neue Shards, ob logisch oder physisch, hinzugefügt und entfernt werden. Auch die Verknüpfungen zwischen den Shards können hinzugefügt oder entfernt werden, bspw. um Datenmigrationen zwischen Shards zu realisieren. 45

46 Eine Forwarding-Tabelle ordnet Knoten einem Shard zu. Hierfür wird die Knoten-Id gehasht. Die Forwarding-Tabelle gibt zu einem Intervall solcher Hashwerte, einer Graph-Id und einer Richtung das Shard an, in dem diese Daten gespeichert werden. Ein FlockDB-Cluster selbst besteht aus vielen FlockDB-Instanzen, welche jeweils die Gizzard-Bibliothek beinhalten. Der einzige Kommunikationskanal zwischen den Instanzen ist der MySQL-Cluster. Jede Instanz verwaltet via Gizzard eine eigene Kestrel-Queue. Fällt ein einzelner FlockDB-Server temporär aus, so können die Clients stattdessen die verbleibenden Instanzen nutzen. Ist die Festplatte dieses Servers ausgefallen, so gehen nur die Schreiboperationen verloren, welche sich noch in diesem einen Server in der Queue befanden. Verliert ein FlockDB-Server die Verbindung zu einer oder mehreren Instanzen des operativen Datenspeichers, so werden die fehlschlagenden Schreiboperationen für diese Instanzen wieder ans Ende der Queue eingereiht und später erneut versucht. FlockDB ist somit immer für Schreiboperationen verfügbar, unabhängig von der Verfügbarkeit der zugrundeliegenden Datenspeicher. Leseoperationen sind möglich, so lange mindestens ein physisches Shard der Partition verfügbar ist. Datenverlust tritt nur auf, wenn alle Replikate verloren gehen. Der Grad der Leseverfügbarkeit und Datensicherheit kann also von den Anwendenden selbst festgelegt werden. FlockDB garantiert Eventual Consistency. Werden über einige Zeit hinweg keine Schreiboperationen ausgeführt und sind alle MySQL-Instanzen verfügbar, so werden alle FlockDB-Instanzen ihre Queues abarbeiten. Danach sind alle physischen Shards auf dem selben, konsistenten Stand. Während des Betriebs hingegen können verschiedene replizierte Shards unterschiedliche Versionen der Daten beinhalten. Durch die Nutzung von Sharding kann einem Wachstum der Datenmenge durch das Hinzufügen weiterer MySQL-Instanzen bei Erhöhung der Anzahl der Partitionen begegnet werden. Die einzige hier denkbare Grenze ist die Tatsache, dass alle Kanten einer Richtung, an denen ein bestimmter Knoten beteiligt ist, auf der selben physischen Instanz liegen müssen. Dies dürfte nur selten ein reales Problem sein. Bezüglich der Datenmenge skaliert FlockDB daher horizontal. Einer erhöhten Lese- bzw. Schreiblast kann einerseits durch das Hinzufügen weiterer MySQL-Instanzen als Replikate zu einzelnen Shards und damit einer Lastverteilung auf dieser Ebene begegnet werden. Sind hingegen die Daten mehrerer Partitionen zusammenführenden FlockDB-Instanzen der Flaschenhals, so lässt sich eine Lastverteilung durch beliebiges Hinzufügen weiterer FlockDB-Instanzen erreichen. Auch bezüglich der Lese- und Schreiblast skaliert FlockDB also horizontal. 46

47 Abbildung 6.3.: Beispielhafte Darstellung einer HyperGraphDB-Datenbank 6.3. HyperGraphDB HyperGraphDB [Iordanov, 2010] ist ein in Java geschriebenes und ausschließlich per Java-API nutzbares eingebettetes Graphdatenbankmanagementsystem. Es wird von Kobrix Software entwickelt und steht unter der freien Lizenz GNU LGPL. Zur Datenpersistenz greift es auf Berkeley DB Java Edition [Oracle, 2011a] zurück. HyperGraphDB basiert auf dem Datenmodell eines gerichteten Multihypergraphen mit je zwei Atomlabeln. Einzelne Atome werden mittels eines Handle genannten Java-Objekts identifiziert. Eines der beiden Labels ist der Typ des Atoms, das zweite dient zur Speicherung von Nutzdaten, die dem Atomtyp entsprechen müssen. Das Typensystem von HyperGraphDB ist deutlich komplexer als das anderer untersuchter Graphdatenbankmanagementsysteme: Typen Atome eines Typs können einander subsumieren 15. Da Typen selbst wiederum als Atome im Graphen gespeichert sind, können Typen auch einander subsumieren, um Vererbungshierarchien abszubilden. Die Atomtypen definieren auch die Struktur der Inzidenzliste und die Abbildung dieser und der Nutzdaten auf Java-Objekte. Sie definieren dadurch ein Schema des Graphen, namentlich welche Atomtypen es gibt und mit welchen anderen Atomen diese auf welche Weise verknüpft sein können. Eine Beispieldatenbank ist in Abbildung 6.3 visualisiert, der abgebildete Hypergraph entspricht dem Beispielhypergraphen aus Abbildung 5.2. Als Typen werden die primitiven Java-Typen sowie deren Arrays, Map, Collection und Date sowie Klassen unterstützt, welche der Java-Beans-Spezifikation entsprechen. Hypergraph liefert auch einige weitere Typen mit, welche übliche Anwendungsfälle erleichtern, bspw. für Kanten ohne Nutzdaten. Außerdem können mittels einer Programmierschnittstelle eigene Typen definiert werden. Die Atomtypen können 15 Beispielsweise könnte bei einem Typ Ontologieeintrag das Atom Fahrzeug das Atom PKW subsumieren. 47

48 andere Atomtypen subsumieren, wodurch Vererbungshierarchien abgebildet werden können. Alle gespeicherten Atome sind unveränderbar. Sie können aber gelöscht und mit einem anderen Wert neu angelegt werden Indexstrukturen HyperGraphDB unterstützt die Indizierung verschiedener Aspekte des verwalteten Graphen [Kobrix, 2012]. Indizes sind Schlüssel-Wert-basiert, wobei einem Schlüssel mehrere Werte zugeordnet werden können. Zum einen können Atome anhand ihrer Nutzdaten indiziert werden. Hierfür können sowohl das vollständige Nutzdatum als auch einzelne Felder eines zusammengesetzten Nutzdatums als Schlüssel genutzt werden. So könnten die Atome, welche Nutzdaten vom Typ Automobil tragen, anhand eines Feldes Hubraum indiziert werden. Zum anderen können Atome anhand der Struktur des Graphen indiziert werden, genauer gesagt anhand der Position anderer Atome in ihrer Inzidenzliste. Hat beispielsweise eine mag -Kante stets zwei inzidente Atome das erste repräsentiert die mögende, das zweite die gemochte Person, so könnten alle mag -Kanten mit dem zweiten Atom ihrer Inzidenzliste als Schlüssel indiziert werden. Dies ermöglicht es, Anfragen wie Gib mir alle auf Person A zeigenden mag -Kanten effizienter anhand des Indizes zu beantworten. Gespeichert werden die Indizes als Schlüssel-Wert-Paare in der Berkeley DB, wobei jeder Index seine eigene Datenbank verwaltet. Da Berkeley DB seine Daten als B-Baum im Hauptspeicher verwaltet, handelt es sich bei den Indizes also faktisch ebenfalls um B-Bäume. Es ist darüber hinaus möglich, eigene Index-Implementierungen zu schreiben und beim Datenbanksystem zu registrieren. Diese werden dann vom DBMS mitverwaltet, bei der Anfrageauswertung aber nicht automatisch berücksichtigt Anfragemechanismen HyperGraphDB stellt drei Interaktionsmechanismen zur Verfügung: Elementare Operationen auf Atomen, mengenbasierte Anfragen und traversierende Anfragen. Die meisten Operationen außer jenen, welche explizit Labels abfragen geben Handles zurück. Die Nutzdaten werden nicht automatisch geladen, um Festplatten-IO zu sparen. 48

49 Elementare Operationen Die elementaren Operationen umfassen Funktionen zum Anlegen, Lesen und Löschen von Atomen. Zum Anlegen eines Atoms wird dem Datenbankmanagementsystem eine Instanz der Nutzdaten und sofern dieser nicht automatisch bestimmt werden kann deren Typ übergeben. Man erhält daraufhin ein Handle, welches das soeben angelegte Atom repräsentiert. Anhand des Handles können die Nutzdaten und der Typ abgefragt werden. Ebenfalls anhand ihres Handles können Atome wieder gelöscht werden. Mengenbasierte Atomanfragen Möchte man mehrere Atome auf einmal abfragen oder hat man kein Handle zur Hand, so bieten sich die mengenbasierten Atomanfragen an. Diese werden in zwei Schritten ausgeführt: Zuerst erfolgt eine Selektion über dem gesamten Datenbestand bzw. einzelnen Indizes, anschließend eine Transformation der Ergebnismenge. Selektionen bestehen aus der konjunktiven oder disjunkiven Verknüpfung mehrerer, eventuell negierter Prädikate. Konjunktionen und Disjunktionen können dabei auch verschachtelt werden. Prädikate können die Nutzdaten des Atoms betrachten ( ist der Wert größer gleich x?, haben die Nutzdaten ein Attribut Name mit dem Wert Schmidt? ), seinen Typ ( Subsumiert persönliche Bekanntschaft den Typ dieses Atoms? ) oder seine Inzidenzmenge ( Hat das Atom mindestens 5 inzidente Atome?, Ist das Handle x an fünfter Stelle der Inzidenzliste? ). Das Ergebnis der Selektion ist die Menge der passenden Atom-Handles. Bei der Anfrageauswertung werden die genannten Indizes automatisch berücksichtigt. Sind mehrere UND-verknüpfte Prädikate indiziert, so wird deren Schnittmenge mittels Zick-Zack-Joins der Indexresultate gebildet. Sind keine Indizes Nutzbar, so wird die Selektionsanfragen sukzessive gegen alle Elemente des Datenbestandes gematched. Bei der Transformation werden Mapping-Funktionen auf die einzelnen Elemente der Ergebnismenge angewandt. Es können mehrere Mappingfunktionen nacheinander angewandt werden, die als Teil der Anfrage als Callbackfunktion (Closure-Objekt) übergeben werden. Also Beispiel könnte man 1. für jedes Atom seine Nutzdatum laden; 2. für jedes Nutzdatum sein Feld Name laden, 3. jeden Namen in Kleinschreibung konvertieren. Die Ergebnismenge bestünde hiernach nicht mehr aus Handles, sondern aus Strings. Ergebnisse werden, sofern möglich, iteratorbasiert erst dann berechnet, wenn sie angefragt werden, wodurch Festplatten-IO und Rechenzeit eingespart werden kann. 49

50 Traversierende Anfragen Es werden Tiefen- und Breitensuchen unterstützt. Beide arbeiten wie auch die mengenbasierten Anfragen iteratorbasiert. Traversierende Anfragen geben Atompaare zurück, bestehend aus dem soeben erreichten Atom und jenem inzidenten Atom, über das es erreicht wurde. Pfade werden nicht berechnet und müssen bei Bedarf anwendungsseitig rekonstruiert werden. Bei einer Tiefensuche wäre dies beispielsweise über einen parallel verwalteten Stack möglich, der mit den besuchten Atomen befüllt und, wenn ein Atom zum zweiten Mal besucht wird, teilweise wieder geleert wird. Gesteuert wird die Traversierung des Graphen mittels eines Adjazenzlistengenerators, welcher als Teil der Anfrage spezifiziert wird. Hierbei handelt es sich um eine Callback- Funktion, welche für ein gegebenes Atom einen Iterator zurückgibt. Dieser zählt Paare von Atomen auf: das als nächstes zu traversierende Atom und jenes, welches dort hin führte. Die Aufzählungsreihenfolge entspricht der späteren Traversierungsreihenfolge, so dass diese explizit steuerbar wird. Bei Breitensuchen kann zusätzlich eine maximale Rekursionstiefe angegeben werden. Jedes Atom wird maximal einmal traversiert. Bei HyperGraphDB kann dies nicht beeinflusst werden Persistenz und Caching HyperGraphDB nutzt zur Persistierung der Daten die Berkeley DB Java Edition [Oracle, 2011a], einen in Java implementierten, eingebetteten Key-Value-Store der Firma Oracle. Berkeley DB kann mehrere Datenbanken in einer Database Environment zusammenfassen. Die Datenbanken einer solchen teilen sich das Transaktionslog und den Cache, haben aber unterschiedliche Schlüsselräume. Das heißt: Ein Schlüssel muss innerhalb der Datenbank einmalig sein, nicht innerhalb der Database Environment. Zu jedem Database Context gehört ein Verzeichnis, in welches dieser seine Daten speichert. Berkeley DB hält die persistierten Daten im Hauptspeicher in Form einer Variante des B-Baums 16. Auf die Festplatte wird allerdings nur das Transaktionslog geschrieben. Um das Lesen von Daten und die damit verbundene Wiederherstellung der Nicht- Blatt-Knoten zu beschleunigen, können sogenannte Checkpoints angelegt werden. Hierbei wird der komplette B-Baum persistiert, so dass bei einem Neuaufbau des Baums beispielsweise bei einem Neustart oder nach einem Systemausfall nur jene Logeinträge erneut eingelesen werden müssen, welche nach der Erstellung des Checkpoints geschrieben wurden. HyperGraphDB teilt jedem Atom sowie jedem primitiven Wert ein global einmaliges Persistence Handle zu. Außerdem legt es in einem von der Anwendung definierten 16 Oracle [2011a] dokumentiert nicht, um was für eine B-Baum-Variante es sich genau handelt. Es wird lediglich beschrieben, dass sämtliche Daten in den Blättern gespeichert werden. 50

51 Verzeichnis einen Database Context mit drei Datenbanken ab, welche in Abbildung 6.4 schematisch dargestellt sind. Eine der Datenbanken ist für die Speicherung primitiver Nutzdaten zuständig. Jedes primitive Nutzdatum bekommt ein Persistence Handle als Key, unter dem es gespeichert wird. Die Ganzzahl 123 könnte bspw. mit dem Handle x gespeichert werden. Jeder primitive Wert wird nur einmal gespeichert und ist unveränderbar. Verwenden mehrere Atome den gleichen primitiven Wert, so zeigen sie auf das selbe Persistence Handle. Die zweite Datenbank speichert zusammengesetzte Werte in Form eines Persistence Handle Arrays. Zum einen sind dies die Atome selbst, bestehend aus ihrem Typ, dem Persistence Handle ihrer Nutzdaten sowie den Handles ihrer ausgehenden Kanten. Zum anderen können dies zusammengesetzte nicht-primitive Nutzdaten sein. Die dritte Datenbank speichert zu einem Atom die eingehenden inzidenten Atome als Persistence Handle Array, also die Handles der Atome, deren Inzidenzliste das fragliche Atom beinhaltet. Dies ermöglicht es, eingehende und ausgehende Kanten ungefähr gleich schnell zu traversieren. Das Auslesen der Persistence Handles aller benachbarten Knoten eines gegebenen Ausgangsknoten benötigt O(m log( V + E )) Leseoperationen, wobei m die Anzahl der inzidenten Kanten des Knotens ist 17 : Das Finden des Ausgangsatoms im B- Baum der BerkeleyDB anhand seines PersistenceHandles benötigt O(log( V E )) Zugriffe, das Auslesen der im Blatt gespeicherten Liste inzidenter Kantenatom- PersistenceHandles O(m) Zugriffe. Das Auslesen der Kanten-Atome anhand ihrer PersistenceHandles benötigt wiederum O(log( V + E )) Zugriffe für jedes der m Kantenatome. Das Auslesen von deren Inzidenzliste ist in O(1) möglich, da sie nur eine konstante Anzahl (2) inzidenter Atome haben. Hinzu kommen zwei Cache-Ebenen. Zum einen nutzt Berkeley DB selbst einen LRU- Cache. Dieser hält eine Repräsentation des B-Baums im Hauptspeicher. Seine Größe steigt während der Laufzeit bis auf maximal 30 % des zur Verfügung stehenden Java Heaps an. Leider ist die Dokumentation von Berkeley DB an dieser Stelle relativ dünn, so dass hier über die Caching-Verfahren keine genaueren Aussagen möglich sind 18. Zusätzlich verwaltet HyperGraphDB selbst noch einen Objekt-Cache, in welchem die deserialisierten Atome vorgehalten werden, und einen Inzidenzlisten-Cache, in 17 Die Komplexitätsanalyse vergleichbar mit den anderen Datenbanksystemen zu halten gestaltet sich hier schwieriger, da es im Ermessen der Anwendung liegt, wie Kanten modelliert werden ob als eigenständiges Kantenatom oder als inzidentes Atom des Ausgangsknotens. Möchte man allerdings Kantenlabels in HyperGraphDB speichern, so kommt man um die Erstellung von Kanten-Atomen nicht herum. Daher bezieht sich die Analyse auf diesen Anwendungsfall. 18 Diese wäre insbesondere interessant, da Berkeley DB laut der Dokumentation Daten, welche nicht im RAM liegen, lediglich aus dem Transaktionslog und den Checkpoints rekostruieren kann. 51

52 Abbildung 6.4.: Schematische Darstellung der Datenspeicherung von HyperGraphDB welchem die eingehenden Verweise auf Atome vorgehalten werden. Der Inzidenzlisten- Cache ist ein LRU-Cache er verdrängt 30 % seiner Elemente, wann immer der Java Heap Space zu 90 % gefüllt ist. Der Atom-Cache basiert auf Javas WeakReferences. Dadurch kann der Cache allen nicht anderweitig genutzen Java-Heap nutzen, Objekte werden allerdings stets dann vom Garbage Collector aus dem Cache entfernt, wenn keine andere Anwendungskomponente mehr Referenzen auf sie halten. Sie werden somit sehr schnell wieder verdrängt Transaktionen HyperGraphDB unterstützt Transaktionen, welche atomar, konsistent und isoliert ausgeführt werden. Es werden keine Zusicherungen bezüglich der Dauerhaftigkeit gemacht. Es ist somit nur garantiert, dass sich die Datenbank nach einem Systemausfall in einem konsistenten Zustand befindet, es können aber einzelne schon abgeschlossene Transaktionen verloren gegangen sein. Transaktionen können beliebig tief verschachtelt werden, wobei eine Elterntransaktion genau eine aktive Kindtransaktion haben kann. Wird eine Kindtransaktion zurückgerollt, so bleibt die Elterntransaktion davon unbetroffen. Wird die Elterntransaktion zurückgerollt, so werden alle Kindtransaktionen ebenfalls zurückgerollt. Es ist darüber hinaus möglich, reine Leseoperationen auch ohne Nutzung der Transaktionskontrolle auszuführen. Beim Start des DBMS kann die Transaktionskontrolle auch vollständig deaktiviert werden, beispielsweise um große Datenmengen schnell in die Datenbank zu laden. 52

53 Die Sicherstellung der ACI-Eigenschaften wird großteils an die zugrunde liegende BerkeleyDB JE delegiert. Diese ist so konfiguriert, dass sie zwar beim Commit das Transaktionslog schreibt, die vom Betriebssystem verwalteten Schreibpuffer aber aus Performancegründen nicht flusht, weshalb keine Dauerhaftigkeit gewährleistet ist [Oracle, 2011b, 3]. BerkeleyDB garantiert das Isolationslevel REPEATABLE READ. Dies bedeutet, dass Transaktionen nicht-committete, veränderte Objekte anderer Transaktionen weder lesen noch überschreiben können. Darüber hinaus kann auch keine Transaktion Objekte verändern, welche bereits von einer anderen nicht abgeschlossenen Transaktion gelesen wurden. Es können in diesem Isolationslevel allerdings Phantom Reads auftreten: Bei wiederholten Lesezugriffen können Objekte im Ergebnis auftauchen, die erst nach dem ersten Lesezugriff von anderen Transaktionen angelegt wurden. Bei der Verwaltung seiner eigenen Caches nutzt HyperGraphDB das Konzept von Versioned Boxes [Cachopo und Rito-Silva, 2006]. Versioned Boxes kann man als historisierte, versionierte Variablen verstehen. Hiermit kann eine Anwendung Multiversion Concurrency Control für Teile ihres eigenen Heaps implementieren. Somit wird sichergestellt, dass die von HyperGraphDB selbst verwalteten Caches zusammen mit dem von BerkeleyDB verwalteten Storage-Layer committed und zurückgerollt werden können und dass eine Isolation zwischen nebenläufigen Transaktionen auch auf Objektcacheebene stattfindet Skalierbarkeit und Ausfallsicherheit HyperGraphDB stellt in seiner Kernbibliothek keine Möglichkeiten zur Verteilung zur Verfügung. Es wird allerdings ein spärlich dokumentiertes Framework zur Verfügung gestellt, um eigene Kommunikationsmechanismen zu implementieren. Als Kommunikationsplattform wird dabei XMPP (Jabber) genutzt, ein XML-basiertes Streaming- Protokoll, was mit einem Fokus auf Instant-Messaging entwickelt wurde. Die einzelnen Datenbank-Instanzen nutzen für ihre Kommunikation die FIPA Agent Communication Language [FIPA, 2002], eine Sprache, die zum Abgleich von Wissen und zur Aushandlung von Aktionen innerhalb von Agentensystemen entwickelt wurde. Zwar legen die vorhandenen Java-Klassen nahe, dass bereits Implementationen für einige Anwendungsfälle beispielsweise Datenreplikation existieren, es existiert aber keine Dokumentation dessen. Iordanov [2010, 7] beschreibt einige Grundzüge des Kommunikationsframeworks, geht aber ebenfalls nicht über die Nennung von möglichen Anwendungsbereichen hinaus. Daher wird an dieser Stelle auf eine weitere Analyse verzichtet. 53

54 Abbildung 6.5.: Beispielhafte Darstellung einer DEX-Datenbank 6.4. DEX DEX [Martínez-Bazan et al., 2007] ist ein in C++ geschriebenes, eingebettetes Graphdatenbankmanagementsystem, welches mit Wrapper-Bibliotheken auch von JVM-basierten Sprachen,.Net-basierten Sprachen und C++ aus verwendet werden kann. Es wird von der Firma Sparsity Technologies entwickelt und steht unter kostenpflichtigen Lizenzen, wobei für nichtkommerzielle akademische Anwendungen und nichtkommerzielle Evaluationszwecke kostenlose Lizenzen zur Verfügung gestellt werden. DEX basiert auf dem Datenmodell eines teils gerichteten Multigraphen mit Kantenund Knotenlabeln und Kanten- und Knotenproperties. Teils gerichtet bedeutet, dass Kanten wahlweise als gerichtet oder ungerichtet markiert werden können. Eine Beispieldatenbank ist in Abbildung 6.5 visualisiert. DEX forciert ein Schema, welches vom Benutzer vor der Befüllung festgelegt wird. Das Schema legt fest welche Knoten- und Kanten-Labels existieren, welche Attribute mit welchem Datentyp die Knoten und Kanten eines bestimmten Labels haben dürfen sowie ob Kanten eines bestimmten Labels gerichtet oder ungerichtet sind und optional, von welche Labels die Ausgangs- und Zielknoten einer Kante eines bestimmten Kantenlabels haben dürfen. Das Schema kann zur Laufzeit geändert werden, es können Labels und Attribute hinzugefügt und gelöscht werden 19. Im Schema definierte Attribute können, müssen aber 19 Das Löschen von Attributen und Labels aus dem Schema ist nur dann möglich, wenn alle Vorkommen in der Datenbank zuvor gelöscht wurden. 54

55 nicht gesetzt werden. Unterstützte Datentypen sind ganzzahlige Werte, Fließkommazahlen, Datumswerte, Strings und boolsche Werte. Alle Knoten und Kanten haben eine vom DBMS verwaltete Identität, wobei die Mengen der Knoten- und Kanten-Ids disjunkt sind. Sie können damit zusammengefasst als Objekt-Ids bezeichnet werden. Leider ist DEX ein Closed-Source-Produkt und die Dokumentation noch recht spärlich, weshalb dieses Kapitel nicht so weit in die Tiefe gehen kann, wie es wünschenswert wäre Anfragemechanismen Die Anfragemechanismen von DEX beschränken sich im Wesentlichen auf elementare Knoten- und Kantenoperationen. Ihnen gemeinsam ist, dass sie größtenteils lediglich Objekt-Ids, Mengen von Objekt-Ids oder skalare Werte zurückgeben, nicht wie beispielsweise bei Neo4j oder HyperGraphDB Java-Objekte, welche eine Entität samt ihrer Label und Attribute repräsentieren. Der Umgang mit der API ist dadurch etwas umständlicher. Zu den elementaren Operationen gehört das Anlegen und Entfernen von Knoten und Kanten sowie das Hinzufügen und Entfernen von Attributen zu Knoten und Kanten anhand von deren Id. Das Auffinden von Kanten ist anhand ihrer Id möglich, das Auffinden von Knoten- und Kanten-Ids anhand ihres Labels oder mittels einfacher Vergleichsoperationen bzgl. genau eines Attributs. Darüber hinaus können Kanten- Ids anhand ihres Typs und der Ids der Start- und Endknoten selektiert werden, Knoten-Ids anhand der Ids der beteiligten Kanten. Dies scheint zuerst nicht sehr mächtig zu sein, allerdings wirbt Sparsity Technologies damit, dass die zurückgegebenen Kantenmengen bzgl. Mengenoperationen sehr effizient Bitmap-basiert implementiert seien. Somit lassen sich auch mengenorientierte Verknüpfungen der oben beschriebenen Anfrageergebnisse durchführen, was die Komposition deutlich komplexerer Anfragen ermöglicht. Für traversierende Algorithmen gibt es die Möglichkeit, zu einem bestimmten Knoten die Ids der inzidenten Kanten und die Ids der inzidenten Knoten abzufragen. Außerdem werden Funktionen zum Abfragen der Anzahl der Knoten und Kanten sowie des Knotengrads bestimmter Knoten zur Verfügung gestellt. Zuletzt werden Implementierungen einiger typischer Graphalgorithmen zur Verfügung gestellt: Tiefensuchen, Breitensuchen, verschiedene Single-Pair-Shortest-Path-Algorithmen sowie die Suche starker und schwacher Zusammenhangskomponenten Transaktionen Zur Sicherstellung der Isolation nebenläufiger Zugriffe nutzt DEX zwei Konzepte: Für jeden zugreifenden Thread wird eine Session benötigt. Sessions halten die temporären 55

56 Daten, welche beim Zugriff des Threads auf die Datenbank entstehen. Die Anwendung kann darüber hinaus auch Knoten- und Kanten-Attribute erstellen, welche nicht persistiert sondern an die Session gebunden werden, bspw. um Zwischenergebnisse von Graphalgorithmen zu speichern. Mit dem Schließen der Session werden alle temporären Daten gelöscht; nach dem Schließen kann der Thread eine neue Sesion öffnen. Außerdem können Operationen zu Transaktionen zusammengefasst werden. Geschieht dies nicht, so werden Schreiboperationen in einem auto commit mode ausgeführt, welcher jede Operation in eine eigene Transaktion kapselt. Leseoperationen können auch außerhalb von Transaktionen durchgeführt werden. Es werden allerdings lediglich Konsistenz und Dauerhaftigkeit von Transaktionen garantiert. Transaktionen können zwar begonnen und per commit abgeschlossen werden, es ist aber nicht möglich, begonnene Transaktionen zurückzurollen. Dadurch ist die Atomarität der Transaktionsausführung nicht gewährleistet. Es ist leider nicht dokumentiert, was im Fehlerfall mit halb-durchgeführten, aber nicht abgeschlossenen Transaktionen passiert. Eine Transaktion beginnt als Lesetransaktion mit einem Shared Lock auf dem gesamten Graphen. Beim ersten Schreibzugriff fordert die Transaktion eine exklusive Sperre für den gesamten Graphen an, welche bis zum Ende der Transaktion gehalten wird. Da ein derart ungranulares Locking für Anwendungen mit einer Vielzahl konkurrierender Schreibzugriffe suboptimal sein dürfte, scheint der Fokus bei der Entwicklung von DEX mehr auf der analytischen als auf der transaktionalen Datenverarbeitung gelegen zu haben. Da das Zurückrollen von Transaktionen nicht möglich ist, kann DEX im Falle eines Deadlocks auch keine der wartenden Transaktionen abbrechen, um den Deadlock aufzulösen. Stattdessen wartet es, bis alle nicht am Deadlock beteiligten Transaktionen beendet sind und gewährt dann nicht-deterministisch einer der wartenden Transaktionen die Schreibsperre. Dies bricht mit dem Isolationskriterium von ACID und kann Lost-Update-Probleme verursachen. Dauerhaftigkeit ist nur dann garantiert, wenn dies per Konfigurationsschalter explizit eingeschaltet worden ist. Diesen nicht zu aktivieren, könnte sich dann als vorteilhaft erweisen, wenn große Datenmengen schnell in die Datenbank geladen werden sollen Persistenz und Caching Martínez-Bazan et al. [2012] beschreiben die interne Datenrepräsentation von DEX als eine Kombination von B + -Bäumen und komprimierten Bitmaps. Der Graph wird hierfür nach verschiedenen Aspekten zerlegt: Die Zuordnung von Labeln zu Objekt-Ids, von Ausgangsknoten zu Kanten-Ids sowie von Zielknoten zu Kanten-Ids werden seperat verwaltet und gespeichert. 56

57 Für jeden dieser Aspekte werden zwei B + -Bäume aufgebaut: Einer ordnet Objekt-Ids einem Wert zu, hat also Objekt-Ids als Schlüssel und Werte als Nutzdaten an den Blattknoten. Der andere gewährleistet das Mapping in umgekehrte Richtung, er hat Werte als Schlüssel und Mengen von Objekt-Ids als Nutzdaten an den Blattknoten. Die Mengen von Objekt-Ids werden als Bitmaps gespeichert: Die Objekt-Id n ist genau dann in der Menge enthalten, wenn das n-te Bit der Bitmap gesetzt ist. Diese bei großen Graphen sehr langen Bitmaps werden komprimiert. Jede Bitmap wird hierfür in Blöcke von 32 Bit zerlegt. Gespeichert werden nur noch die Blöcke, in denen mindestens ein Bit gesetzt ist, jeweils mit einem vorangestelltem 32 Bit Blockindex. Dies erlaubt mengenbasierte Operationen (Vereinigung, Schnitt, Differenz) effizient mittels binärer Operatoren durchzuführen: Es müssen nur jene Datenbereiche betrachtet werden, in denen auch tatsächlich ein Bit gesetzt ist. Als weitere Optimierung bezieht DEX die Label-Id des Objekts mit in die Objekt-Id ein und sorgt somit dafür, dass Objekte des selben Typs sehr viel wahrscheinlicher von nahe beieinander liegenden Bits repräsentiert werden. Diese Kombination ermöglicht das Auslesen der Objekt-Ids aller benachbarten Knoten einer gegebenen Knoten-Id mit O(log( V ) + m log( E )) Operationen, wobei m die Menge der inzidenten Kanten ist: Das Auffinden der Kanten-Id-Menge anhand der Ausgangsknoten-Id im entsprechenden B-Baum benötigt O(log( V )) Zugriffe, das Auslesen der Verketteten Kanten-Id-Menge O(m) Zugriffe und das Auslesen des jeweiligen Endknoten zu jeder der m Kanten im entsprechenden B-Baum wiederum je O(log V ) Zugriffe. Auch für die Persitierung der Properties werden B + -Bäume verwendet: Für jeden Attributtyp existiert ein B + -Baum mit Objekt-Ids als Schlüsseln und Attributwerten als Blattwerten. DEX speichert sowohl die persistierten Daten als auch sofern der RAM nicht ausreicht die Session-Daten auf der Festplatte. Sein Cache wird durch den C++- Core außerhalb des JVM-Heaps verwaltet. Der Cache ist dabei zweigeteilt: Ein Teil steht zum Caching der persistenten Daten zur Verfügung, der andere zur Speicherung der temporären Daten. Die Verteilung des konfigurierten maximal zur Verfügung stehenden Speichers auf die beiden Bereiche erfolgt dabei nach Bedarf dynamisch, wobei von der Anwendung jeweils Höchstgrenzen und Mindestwerte festgelegt werden können. Die verwendeten Caches sind leider sehr spärlich dokumentiert, sowohl in [Martínez-Bazan et al., 2007] als auch in den Konferenzpublikationen der Hersteller, weshalb sich hier keine genaueren Aussagen treffen lassen Indexstrukturen DEX unterstützt drei Formen der Indizierung. Hierfür werden ebenfalls die beschriebenen Kombinationen aus B-Bäumen und Bitmaps verwendet Martínez-Bazan et al. [2012]. Zu Knoten-Ids können die Id-Mengen ihrer jeweils inzidenten Knoten indiziert 57

58 werden. Dies ermöglicht es dem Datenbanksystem, inzidente Knoten unmittelbar zurückzugeben, statt sie anhand der inzidenten Kanten zu berechnen. Dadurch verringert sich die Komplexität des Auslesens von O(log( V ) + m log( E )) (vgl ) auf O(log( V ) + m), wobei m die Anzahl der inzidenten Knoten ist: O(log( V )) für das Auffinden des Knotenblattes im B-Baum, O(m) für das Auslesen der verketteten Bitmap. Darüber hinaus werden Attributindizes unterstützt, um Knoten und Kanten effizient anhand des Inhalts genau eines ihrer Attribute auffinden zu können. Attributindizes werden im Rahmen der Schemadefinition beim Anlegen eines Attributs definiert. Wird einem Knoten oder einer Kante ein Attribut hinzugefügt oder entfernt, so wird der Index automatisch aktualisert. Werden Knoten anhand eines Attributwertes selektiert, so wird, sofern ein Index vorhanden ist, dieser automatisch verwendet. Sie werden durch einen B + Baum umgesetzt, welcher Attributwerte als Schlüssel und Objekt-Id-Mengen als Blattwerte speichert. Indizes können auch als unique definiert werden. Das Datenbankmanagementsystem unterbindet dann das Schreiben von Attributwerten, wenn bereits ein anderes Objekt des selben Labels ein Attribut des selben Schlüssels mit dem selben Wert besitzt. Es ist nicht dokumentiert, wie die Indizes implementiert sind. Basierend auf den in Abschnitt beschriebenen Ausführungen von Martínez-Bazan et al. [2012] erscheint wahrscheinlich, dass hierfür jene B-Bäume genutzt werden, welche pro Attributtyp Attributwerten Objekt-Ids (in Form von komprimierten Bitmaps) zuordnen. Da Attributindizes optional sind, ist anzunehmen, dass diese B-Bäume nur dann erzeugt werden, wenn die Indizierung aktiviert ist Skalierbarkeit und Ausfallsicherheit DEX kann als verteiltes Datenbanksystem in einer verteilten Applikation betrieben werden. Hierfür werden mehrere Instanzen der nutzenden Anwendung gestartet, jede Instanz enthält eine eingebettete DEX-Instanz. Eine der DEX-Instanzen fungiert als Master-, alle weiteren als Slave-Instanzen. Die Master- und alle Slave-Instanzen enthalten jeweils ein vollständiges Replikat der Datenbank. Lesende und schreibende Operationen können sowohl auf dem Master als auch auf den Slave-Instanzen ausgeführt werden. Lesende Operationen werden von allen Instanzen direkt aus dem lokalen Datenbestand beantwortet. Wird eine Schreiboperation auf einer Slave-Instanz angefordert, so wird diese an den Master weitergeleitet und von diesem ausgeführt. Nach Abschluss der Transaktion auf dem Master erhält die Slave-Instanz Informationen über die seit der letzten Synchronisation auf dem Master abgeschlossenen Transaktionen. Sie übernimmt diese Änderungen dann in ihren lokalen Datenbestand. Ist eine häufigere Synchronisation des Datenbestandes gewünscht, so können Slave-Instanzen zusätzlich 58

59 in konfigurierbaren Zeitintervallen die zwischenzeitlichen Änderungen von der Master- Instanz abrufen. Koordiniert wird der DEX-Cluster durch einen zusätzlich zu betreibenden Apache Zookeeper Cluster [Hunt et al., 2010]. Dieser wird (unter anderem) dazu genutzt, die Master-Instanz zu wählen: Die erste Instanz, die sich bei Zookeeper anmeldet, wird zur Master-Instanz. Weitere Dokumentation, wie DEX Apache Zookeeper verwendet, ist nicht vorhanden. DEX skaliert prinzipiell horizontal bezüglich der Leselast: Einer hohen Leselast kann mit einer hohen Anzahl an Slave-Instanzen begegnet werden. Allerdings hält DEX sein Transaktionslog nur für eine begrenzte Zeit vor. Kommt eine Slave-Instanz hinzu, deren Stand älter ist als der Beginn des Transaktionslogs, so verweigert der Master die Synchronisation. Damit ist ein späteres Hinzufügen neuer Knoten zum Cluster problematisch. Bezüglich der Schreiblast skaliert DEX lediglich vertikal, da alle Schreiboperationen auf genau einer Master-Instanz durchgeführt werden müssen. Auch bezüglich der Datenmenge skaliert DEX lediglich vertikal, da jede Instanz eine Kopie des kompletten Datenbestandes vorhalten muss. DEX ist auch im verteilten Modus nur eingeschränkt fehlertolerant: Fällt der Master aus, so wird kein neuer Master gewählt das System verbleibt in einem Zustand, welches Sparsity [2013, High availability] als non-operational beschreibt 20. Fällt eine Slave-Instanz aus, so bleibt der Cluster davon grundsätzlich unbeeinflusst. Eine Ausnahme besteht, wenn die Slave-Instanz eine Transaktion begonnen hatte: Die Transaktion bleibt dann geöffnet, die Sperren auf der Master-Instanz werden nicht wieder freigegeben, weitere Schreiboperationen sind damit nicht mehr möglich. Ebenfalls nicht dokumentiert ist das genaue Verhalten des Clusters, wenn Slave- Instanzen die Verbindung zur Master-Instanz verlieren. Es ist lediglich dokumentiert, dass, sollte dies während der Synchronisation passieren, das System non-operational hinterlassen wird. Der Apache Zookeeper Cluster ist gegen Partitionierung insofern tolerant, als dass er solange funktionstüchtig bleibt, wie mehr als die Hälfte der Knoten noch miteinander kommunizieren können Zusammenfassung Die Tabellen 6.1 bis 6.3 fassen die Ergebnisse dieses Kapitels zusammen. Die Variable inz bei den Komplexitätsabschätzungen in Tabelle 6.2 bezeichnet die Inzidenzmenge des Ausgangsknotens. Es fällt auf, dass drei von vier betrachteten Systemen B-Baum basiert sind und lediglich Neo4j Entitäten auf Storage-Ebene verknüpft. Daraus ergibt sich auch, dass Neo4j für traversierende Anfragen die beste Komplexitätsabschätzung hat. 20 Laut Sparsity [2013, High availability] ist eine Neuwahl der Master-Instanz für zukünftige Versionen geplant. 59

60 Insbesondere bei DEX ist dies interessant, da dessen Hersteller wie auch die von Neo4j explizit die Geschwindigkeit bei Graphanfragen hervorheben. Hier wird das Benchmark zeigen müssen, inwiefern sich die theoretischen Komplexitäten mit den tatsächlichen Messwerten decken. Bei der Betrachtung der Anfragemöglichkeiten sticht Neo4j durch Vielseitigkeit und Mächtigkeit hervor. Insbesondere Cypher als auf regulären Graphanfragen basierende deklarative Anfragesprache ist hier besonders hervorzuheben ein vergleichbarer Anfragemechanismus existiert bei keinem der anderen Systeme. Allerdings geht mit der Nutzung einer solchen Anfragesprache auch ein Verlust an Kontrolle über die Anfrageausführung einher. Es wird spannend sein zu sehen, inwiefern Neo4j im späteren Benchmark gegenüber manueller Anfrageoptimierung konkurrenzfähig ist. HyperGraphDB und FlockDB bieten gute mengenbasierte Anfragemöglichkeiten, DEX hingegen nur eine sehr minimalistische API. Bei der Betrachtung der Transaktionskontrollmechanismen fällt auf, das DEX mit seiner sehr radikalen Sperrstrategie, fehlender Rückrollbarkeit von Transaktionen und schwacher Isolation nebenläufiger Zugriffe anscheinend nicht für die Nutzung in Szenarien mit vielen nebenläufigen Schreibzugriffen entworfen wurde. In OLAP- Umgebungen könnte dies aber durchaus ausreichend sein. Neo4j und HyperGraphDB können hingegegen beide mit einer angemessenen Transaktionskontrolle aufwarten. FlockDB bietet nur eine geringfügige Kontrolle nebenläufiger Zugriffe es garantiert lediglich, dass früher abgesetzte Schreiboperationen später abgesetzte Schreiboperationen nicht überschreiben. Dies ist ein Ergebnis der Fokussierung auf Verfügbarkeit und Partitionstoleranz. Bei der Verteilbarkeit und Skalierbarkeit sticht FlockDB folglich auch aus der Masse heraus, es skaliert horizontal in allen drei untersuchten Bereichen Leselast, Schreiblast, und Datenmenge. Neo4j implementiert eine Master-Slave-Replikation, die zumindest das Abfangen hoher Leselast ermöglicht. Die Replikationslösung von DEX scheint noch in einem sehr rudimentären Zustand zu sein. Für die angesprochenen OLAP-Anwendungen könnte dies aber verkraftbar sein. So ließe sich hohe Leselast mehrerer komplexer analytischer Anfragen durch Verteilung der einzelnen Anfragen auf je ein Replikat abfangen. Dies wird auch von DEX gut unterstützt. 60

61 Neo4j FlockDB HyperGraphDB DEX Hersteller Neo Technology Twitter Kobrix Software Sparsity Technologies Lizenz GPL / AGPL / Kommerziell Apache License 2.0 GNU LGPL Kommerziell Embedded JVM Nein JVM JVM,.NET, C++ Client-Server REST-API Thrift Nein Nein Datenmodell Gerichteter Multigraph Gerichteter Graph Gerichteter Multihypergraph Optional gerichteter Multigraph Labels Kantenlabels Kantenlabels (Zahlen) Atomlabels Knoten- und Kantenlabels Properties Knoten- und Kantenproperties Nein Atomproperties Knoten- und Kantenproperties Schema Nein Nein Ja Ja CRUD Ja Ja Ja Ja Traversierende Anfragen Reguläre Graphanfragen Mengenorientierte Anfragen Ja, sehr detailliert steuerbar Nein Ja Ja, mittels Algorithmenbibliothek Ja, mittels Cypher Nein Nein Nein Ja, mittels Cypher Ja Ja Ja Tabelle 6.1.: Überblick der untersuchten Datenbankmanagementsysteme: Allgemeines, Datenmodell und Anfragemöglichkeiten 61

62 Neo4j FlockDB HyperGraphDB DEX Storage Fixed Records; Id als Offset; Verknüpfte Entitäten Komplexität des Traversieres zu Nachbarknoten Caches Memory Mapped Files (LFU); Soft References / Weak References MySQL-Backend (B- Baum) B-Baum-basierter Key- Value-Store; Inzidenzlisten in den Blättern B + -Bäume mit komprimierten Bitmaps als Inzidenzlisten in den Blättern O( inz ) O(log( E ) + inz ) O( inz log( V + E )) O(log( V ) + inz ) bei Indexverwendung Bei MySQL: Memory Mapped Files (LRU) Kaum dokumentiert, LRU / Weak References Kaum dokumentiert, speicheradaptiv Indizes Lucene keine B-Baum B-Baum mit Bitsets in den Blättern Struktur indizierbar Automatische Indexverwaltung Automatische Berücksichtigung bei Anfragen Ja, da Schlüssel frei wählbar - Ja Ja Ja, optional - Ja Ja Nein - Ja Ja Tabelle 6.2.: Überblick der untersuchten Datenbankmanagementsysteme: Persistenz, Caching und Indexstrukturen 62

63 Neo4j FlockDB HyperGraphDB DEX Transaktionsmodell ACID Idempotente und kommutative Schreiboperationen Isolationsmechanismus Daten: RX-Locking; Lucene: Single Writer & Versionierung Keiner Daten: RX-Sperren; Caches: Software- Transactional Memory ACI CD, Lost Updates möglich RX-Sperren & Single Writer Verteilungsmodus Master-Slave- Replikation Konsistenz im verteilten System Skalierbarkeit Lesen Skalierbarkeit Schreiben Skalierbarkeit Daten Sharding - Master-Slave- Replikation Eventual Consistency Eventual Consistency - Eventual Consistency Horizontal Horizontal Vertikal Horizontal Vertikal Horizontal Vertikal Vertikal Vertikal Horizontal Vertikal Vertikal Tabelle 6.3.: Überblick der untersuchten Datenbankmanagementsysteme: Transaktionen und Verteilung 63

64 7. Benchmark In diesem Kapitel werden die untersuchten Datenbankmanagementsysteme einem vergleichenden Benchmark unterzogen. Ziel ist es, herauszufinden, welche Auswirkungen insbesondere die in Kapitel 6 herausgearbeiteten theoretischen Vor- und Nachteile einzelner Persistenzmodelle und Anfragesprachen tatsächlich auf die Geschwindigkeit der Anfrageausführung haben. Hierbei werde ich mich insbesondere an der Arbeit von Dominguez-Sal et al. [2011] orientieren, welche eine sehr tiefgehende und vielseitige theoretische Arbeit zum Design von Graphdatenbankbenchmarks publiziert haben Datengrundlage Aus der Wahl der Datenbankmanagementsysteme, welche in diesem Benchmark gemessen werden sollen, und aus der Wahl der Benchmarkalgorithmen ergeben sich einige Anforderungen an die Datengrundlage, auf der die Algorithmen ausgeführt werden. Die untersuchten Datenbankmanagementsysteme verwalten zwar allesamt Graphen, jedoch unterscheiden sich die Datenmodelle darüber hinaus teils erheblich. Daher sind die Testdaten so zu wählen, dass sie in sämtlichen untersuchten Datenbankmanagementsystemen darstellbar sind. FlockDB bietet das leichtgewichtigste Datenmodell. Es unterstützt keinerlei Zuordnung von Attributen oder Labeln zu Knoten und keine Zuordnung von Attributen zu Kanten. Die Testdatenbasis sollte daher auf Knotenlabels und Knotenattribute verzichten. Auch Kantenattribute werden von FlockDB nicht unterstützt. Desweiteren unterstützt FlockDB lediglich einfache Graphen, keine Multigraphen. 1 Als Testdatenmodell wird daher ein gerichteter Graph mit Kantenlabeln genutzt. 1 Prinzipiell wäre es möglich, Knotenlabels mittels speziell gelabelter Kanten zwischen dem Knoten selbst und je einem Knoten, der das Label repräsentiert, zu simulieren und so eine isomorphe Abbildung zu erreichen. Auch mehrfache Kanten zwischen zwei Knoten ließen sich durch Einfügen eines zusätzlichen Knotens in jede der Kanten abbilden. Es wäre sicherlich auch spannend zu sehen, in wie weit die eventuell leichtgewichtigere Anfragebearbeitung durch ein einfacheres Datenmodell den Mehraufwand in der Modellierung und damit den Mehraufwand bei der Anfrageauswertung durch eine gesteigerte Knoten- und Kantenanzahl ausgleichen kann. Allerdings geht eine solche Nutzung in einem Umfang am von Pointer et al. [2010] genannten Anwendungszweck von FlockDB vorbei, dass es für ein vergleichendes Benchmark mehrerer Systeme methodisch zweifelhaft erscheint. 64

65 Die Performance von Softwaresystemen verhält sich nicht immer linear zur zu verarbeitenden Datenmenge. Möchte man ein repräsentatives Bild der verschiedenen getesteten Systeme bekommen, sollten Benchmarkalgorithmen folglich auf unterschiedlich großen Datenbeständen ausgeführt werden. Da keine Attribute genutzt werden, gibt es lediglich zwei variable Faktoren: Die Anzahl der Knoten und die Anzahl der Kanten im Graphen. Im Rahmen des Benchmarks werden daher Messreihen mit verschiedenen Kombinationen dieser beiden Parameter durchgeführt. Um eine strukturelle Ähnlichkeit der Graphen sicherzustellen, werden diese alle mithilfe desselben Algorithmus generiert. Reale Graphen würden hier mehrere Probleme erzeugen: Zum einen könnte es schwierig werden, genügend geeignete Graphen in verschiedenen Größen zu finden, zum anderen wäre es unwahrscheinlich, dass Graphen aus verschiedenen Quellen mit verschiedenen Größen hinreichend ähnlich strukturiert sind also bspw. ähnliche Knotengradverteilungen besitzen. Ist dies aber nicht der Fall, so ist nur schwer zu sagen, ob die Performanceunterschiede durch die veränderte Größe des Graphen oder vielleicht durch die veränderte Struktur zustande kommen Typische Eigenschaften großer Graphen Die generierten Graphen sollten Strukturmuster aufweisen, die denen realer Graphen möglichst ähnlich sind. Chakrabarti und Faloutsos [2006, 2] geben einen kurzen Überblick über übliche Strukturmuster und den diesbezüglichen Stand der Forschung. Sie kommen zu dem Schluss, dass reale Graphen häufig zumindest mehrere der folgenden Eigenschaften haben: Die Verteilung der Knotengrade folgt einer sog. Power-Law distribution, das heißt die Wahrscheinlichkeitsfunktion der Knotengrade deg ist p(deg) = α deg γ, α > 0, γ > 1. Es gibt also sehr viele Knoten mit sehr geringem Knotengrad, aber auch einige wenige Knoten mit sehr hohen Knotengraden, wobei die Anzahl dieser mit steigendem Knotengrad sehr schnell abnimmt. Zusammenhängende Teilgraphen haben einen kleinen Durchmesser im Verhältnis zur Kantenmenge. Häufig verringert sich der Durchmesser sogar mit steigender Anzahl an Kanten, der Graph wächst also nicht in die Breite. Diese Beobachtung wird häufig auf Milgram [1967] zurückgeführt, der dies bzgl. sozialer Netze postulierte. Die Graphen haben relativ hohe Clustering-Koeffizienten. Ist ein Knoten mit zwei anderen Knoten verbunden, so ist die Wahrscheinlichkeit hoch, dass diese verbundenen Knoten auch untereinander verbunden sind. Am Beispiel sozialer Netze lässt sich dieser Effekt gut verdeutlichen: Die Freundinnen und Freunde einer Person sind häufig auch untereinander bekannt bzw. befreundet, es bilden sich Freundeskreise (Cluster) unteinander bekannter Personen. Darüber hinaus bestehen die Graphen häufig aus signifikant weniger Kanten als aufgrund ihrer Knotenmenge möglich wäre und haben häufig eine sehr große verbundene Komponente, welche einen Großteil aller Knoten enthält. 65

66 Generierung von Graphen Chakrabarti und Faloutsos [2006, 3] bieten einen weiten Überblick über verschiedene Ansätze und Algorithmen zur Graphgenerierung, sie treffen allerdings bei vielen der Algorithmen keine Aussagen dazu, wie sich der Graphdurchmesser und der Clustering- Koeffizient in Abhängigkeit von den Parametern der Algorithmen verhält. Unter den beschriebenen Algorithmen gibt es mehrere, die gerichtete Graphen generieren, deren Knotengrade einer Power-Law-Distribution entsprechen. Hier stechen zwei Algorithmen hervor, da sie (zumindest aufgrund empirischer Beobachtungen) ein gut dokumentiertes Verhalten bzgl. Clustering und Graphdurchmesser haben. Zum einen handelt es sich um den Forest Fire-Algorithmus von Leskovec et al. [2005], zum anderen um R-MAT von Chakrabarti et al. [2004]. Forest Fire fügt iterativ Knoten zu einem Graphen hinzu, wobei jeweils eine Kante zu einem Zufallsknoten erstellt wird. Es werden außerdem Kanten zu einer zufällig ausgewählten Menge von Nachbarknoten dieses Knoten gebildet. Dieser Prozess wird rekursiv traversierend auch auf transitive Nachbarn des Knotens angewandt, wobei das so simulierte Feuer im Graphen irgendwann stirbt. Die Rekursion und die Auswahl der Knoten erfolgt basierend auf verschiedenen Wahrscheinlichkeitsverteilungen, deren Parameterwerte definierbar sind. Forest Fire kann Graphen generieren, welche einen hohen Clustering-Koeffizienten und mit wachsender Knotenzahl sinkende Durchmesser haben. R-MAT geht aus von einer Knotenmenge definierbarer Größe, welche eine Potenz zur Basis 2 sein muss. Zu dieser Knotenmenge fügt er sukzessive eine definierbare Anzahl an Kanten hinzu. Hierfür wird die Adjazenzmatrix in vier gleich große Quadranten geteilt. Einer der vier wird zufällig ausgewählt. Diese zwei Schritte werden nun rekursiv wiederholt, bis lediglich ein Eintrag der Matrix verbleibt. Hier wird nun eine Kante eingefügt. Welcher der vier Quadranten mit welcher Wahrscheinlichkeit gewählt wird, ist vom Anwender definierbar. Auch R-MAT kann Graphen mit starken Community-Effekten und kleinem Durchmesser generieren. R-MAT scheint zum einen einfacher zu implementieren, zum anderen erlaubt er eine genauere Beeinflussung der tatsächlich generierten Kantenzahlen. Daher wurde dieser für die Testdatengenerierung gewählt Die generierten Daten Mit der Wahl von R-MAT als Graphgenerator geht die Einschränkung einher, dass die Knotenzahlen der Graphen ein Vielfaches von 2 sein müssen. Leskovec et al. [2008, Tabellen 1 3] haben in einer Überblicksarbeit viele reale Graphen untersucht. Die dort untersuchten Graphen hatten Durchschnittsknotengrade, welche zwischen 66

67 10 3 Generierte Daten γ = 1.1 Anzahl Knotengrad Abbildung 7.1.: Die Knotengradverteilung des generierten Benchmarkgraphen ( Knoten, 1 Mio Kanten) verglichen mit einer Power-Law- Distribution mit γ = 1, 1. 2, 5 und 403, 5 und im Median bei 6,04 lagen. Für dieses Benchmark wurden daher mittels R-MAT synthetische Graphen generiert, für die gilt: und V {2 n 3 n 20}, E {10 m 0 m 7} 2 E V 403, 5. Der größte generierte Graph besteht also aus 100 Mio. Kanten und ca. 8,4 Mio. Knoten mit einem Durchschnittsknotengrad von ca. 23,8. Die generierten Graphen wurden zur späteren Verarbeitung in je einer Textdatei gespeichert. Die Parameter von R-MAT wurden so gewählt, dass der obere linke Quadrant der Adjazenzmatrix stets mit einer Wahrscheinlichkeit von 58% gewählt wird, der obere rechte und der untere linke Quadrant mit einer Wahrscheinlichkeit von 19% und der untere rechte Quadrant folglich mit einer Wahrscheinlichkeit von 4%. Die sich daraus ergebende Knotengradverteilung ist am Beispiel eines Graphen mit Knoten und 1 Mio. Kanten in Abbildung 7.1 dargestellt. Es ist ersichtlich, dass diese ungefähr einer Power-Law-Distribution mit γ = 1, 1 entspricht. Um reguläre Graphanfragen auf dem Datenbestand ausführen zu können, mussten Kantenlabel generiert werden. Die genutzte (und in Abschnitt 7.2 beschriebene) Graphanfrage verwendet lediglich 3 Kantenlabel. Damit nicht alle Kanten von der Anfrage erfasst werden, wurden den Kanten vier verschiedene Labels ( L1 bis 67

68 L4 ) zugeordnet. Hierbei wurde L1 mit einer Wahrscheinlichkeit von 70, 0%, L2 mit 17, 6%, L3 mit 7, 8% und L4 mit 4,6% zugeordnet, was einer Power-Law- Distribution mit γ = 2 entspricht Algorithmen Graphalgorithmen lassen sich nach Dominguez-Sal et al. [2011] anhand verschiedenen Kriterien kategorisieren: Handelt es sich um analysierende oder mutierende Algorithmen? Wird weiter als bis zur Tiefe 1 traversiert? Betrachten sie nur einen kleinen Teil (lokale Anfrage) oder den kompletten Graphen (globale Anfrage)? Werden Attribute oder lediglich die Struktur des Graphen betrachtet? Welche Art von Ergebnis wird zurückgegeben? Ciglan et al. [2012] merken hierzu an, dass die Fähigkeit, effizient über die Topologie des Graphen zu traversieren, das Alleinstellungsmerkmal von Graphdatenbanksystemen sei, weshalb dies auch der Schwerpunkt von Graphdatenbank-Benchmarks sein sollte. Da diese Arbeit mit FlockDB und HypergraphDB auch zwei B-Baum-basierte Systeme in die Untersuchung mit einbezieht, von denen zumindest eines (FlockDB) explizit nicht auf traversierende, sondern auf mengenbasierte Anfragen ausgelegt ist, würde eine alleinige Messung traversierender Anfragen aber am Zweck des Systems vorbeigehen. Daher wurde zusätzlich zu traversierenden auch ein mengenbasierter Benchmarkalgorithmus gewählt. Im Einzelnen wurden folgende Benchmarkalgorithmen ausgeführt und gemessen: Das Befüllen der Datenbank mit den Testdaten. Sofern unterstützt, wurde hierfür auf Bulk-Load-Funktionalitäten zurückgegriffen. Das Auslesen aller Kanten des Graphen als Beispiel einer globalen, nicht-traversierenden Anfrage, welche Kantenmengen berechnet. Die Berechnung starker Zusammenhangskomponenten nach Tarjan [1972] als Beispiel einer global traversierenden Anfrage, welche Knotenmengen berechnet. Das Auslesen transitiv erreichbarer Knoten bis zur Tiefe 3 (sog. friends-offriends -Anfragen) als Beispiel lokal traversierender Anfragen, welche Knotenmengen zurückgeben. Das Auslesen gemeinsamer Nachbarknoten zweier Ausgangsknoten als Beispiel mengenbasierter Anfragen. Die Beantwortung (regulärer) Graphanfragen. Genauer das Suchen zweier Knoten y, z im Graphen, welche mit einem bestimmten Knoten x durch einen Dreieckspfad mit bestimmten Labeln verbunden sind. Der Ausdruck ist in Abbildung 7.2 visualisiert 2. 68

69 Abbildung 7.2.: 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? Die Benchmarkalgorithmen wurden abhängig von den Fähigkeiten der jeweiligen Datenbankmanagementsysteme unterschiedlich implementiert, wobei versucht wurde, Berechnungen nur dann durch Eigenimplementierungen durchzuführen, wenn das DBMS selbst dafür keine Anfragemöglichkeiten bereitstellt. Darüber hinaus wurden Indizes so angelegt, wie dies für die einzelnen Systeme optimale Performance versprach. Die Gemeinsamkeiten und Besonderheiten bei der Implementierung für die einzelnen Datenbankmanagementsysteme werden im Folgenden kurz umrissen 3. Beim Einfügen von Kanten war es nötig, die Knoten-Ids der Ausgangs- und Endknoten der Kante anzugeben. Da nur FlockDB mit nutzerdefinierten IDs arbeitet, wurde bei den anderen Systemen eine Zuordnung von DBMS-Ids zu nutzerdefinierten Ids in Form einer HashMap im Benchmarkcode gepflegt. Dies vermied häufige Leseoperationen zum Auslesen der Id-Attribute während des Batch-Imports. Bei der Auswertung der starken Zusammenhangskomponenten wurde für alle Datenbankmanagementsysteme dieselbe abstrakte Implementierung verwendet. Datenbankspezifisch wurde lediglich das Iterieren über sämtliche Knoten, das Abfragen der Knoten-Ids und das Finden ausgehender inzidenter Knoten implementiert. Da nur Neo4j reguläre Graphanfragen unterstützt, wurden diese für alle anderen Systeme selbst implementiert. Hierfür wurde eine Tiefensuche ausgeführt beginnend 2 Da außer Neo4j keines der untersuchten Systeme reguläre Graphanfragen unterstützt, wurde eine sehr einfache Variante einer regulären Graphanfrage ohne Wildcards im Pattern gewählt. Dies diente primär der einfacheren anwendungsseitigen Implementierung im Benchmarkcode derjenigen Systeme, welche keine Unterstützung anbieten. 3 Der vollständige Benchmark-Code ist zusammen mit den verwendeten Konfigurationsdateien für MySQL und FlockDB unter zu finden. 69

70 beim Ausgangsknoten. Wegen der höheren Selektivität wurden gegen die Kantenrichtung traversiert. Zuerst wurden die L3 -Kanten verfolgt, danach die L2 -Kanten. Danach wurden L1 -Kanten gesucht, welche wieder zum Ausgangsknoten zurück führen Neo4j Neo4j wurde als Embedded-Datenbanksystem angebunden. Der Datenimport erfolgte unter Verwendung des BatchInserters, wobei auch ein Index über die Knoten-Ids der Testdaten angelegt wurde. Das Auslesen aller Kanten wurde mittels der primitiven Kantenoperationen durchgeführt. Auch die datenbankmanagementsystemspezifischen Elemente der Berechnung der starken Zusammenhangskomponenten wurden durch primitive Knotenoperationen implementiert. Die Abfrage der transitiven inzidenten Knoten ( friends-of-friends -Anfrage) wurde mittels des Traversal-Frameworks implementiert, da solche Anfragen quasi das Kernanwendungsgebiet desselben sind. Hierbei wurde eine Breitensuche verwendet. Die Abfrage gemeinsamer inzidenter Knoten und die reguläre Graphanfrage wurden mittels der Anfragesprache Cypher umgesetzt. Die Alternative wäre gewesen, diese Anfragen mittels des Traversal-Frameworks umzusetzen, was aber jeweils einen größeren Anteil selbstgeschriebenen Codes benötigt hätte FlockDB Aufgrund der sehr eingeschränkten Anfragemöglichkeiten von FlockDB musste deutlich häufiger auf Eigenimplementierungen von Teilalgorithmen zurückgegriffen werden. Sämtliche Kommunikation mit FlockDB fand über die Thrift-Schnittstelle statt, wobei wegen der schlechten Usability der API eine Java-Wrapper-Bibliothek entstand [Gehrels, 2013], welche für die Implementierung der Algorithmen Verwendung fand. Da FlockDB keine Möglichkeiten für Batch-Import-Vorgänge bietet, wurde der Datenimport mittels normaler Schreiboperationenen implementiert. FlockDB bietet prinzipiell die Möglichkeit, mehrere Schreibanfragen in einem Bündel zusammengefasst zu übertragen. Da es jedoch beim Bündeln aller Kanten zu Arbeitsspeicherengpässen während der Benchmarkentwicklung gekommen ist und keine Dokumentation bzgl. der optimalen Bündelgrößen vorhanden war, wurde darauf verzichtet. Da FlockDB nicht garantiert, dass Daten unmittelbar geschrieben werden es reiht sie in eine lokale Warteschlange ein und schreibt sie nach und nach in die Datenbank, bedurfte es einer Definition, wann der Import im Sinne des Benchmarks als beendet gilt. Der Import gilt im Sinne dieses Benchmarks als beendet, wenn die Daten für Leseoperationen zur Verfügung stehen. Um dies bei FlockDB sicherzustellen, wird im 70

71 Anschluss an den Import das zugrunde liegende MySQL-Datenbanksystem in einem 300 ms-takt angefragt, wie viele Kanten vorhanden sind 4. Die Messung wird erst beendet, wenn alle Kanten auch in der MySQL-Datenbank vorliegen. Das Abfragen aller Kanten des Graphen wurde mittels einer Abfrage der ausgehenden inzidenten Kanten pro Knoten und Kantenlabel implementiert. Die Anfragen wurden auch hier wg. Arbeitsspeicherengpässen während der Entwicklung nicht gebündelt. Die Abfrage der inzidenten Knoten zur Berechnung der starken Zusammenhangskomponenten wurde mittels der Selektionsfunktionen von FlockDB implementiert, wobei eine Union-Anfrage über alle vier Kantenlabels gebildet wurde. Die Abfrage der transitiven inzidenten Knoten wurde mit einer Breitensuche (Eigenentwicklung) durchgeführt, da FlockDB keine Traversierungsmöglichkeiten bietet. Für die einzelnen Breitensuchschritte wurden die inzidenten Kanten aller Knoten der aktuellen Tiefe mittels einer Union-Abfrage über alle vier Kanten-Labels und alle Knoten dieser Tiefe berechnet. Die Abfrage der gemeinsamen inzidenten Knoten wurde durch eine Intersection- Anfrage implementiert. Die jeweiligen Suchschritte bei der Abfrage regulärer Graphausdrücke wurden durch einfache Selektionsabfragen implementiert HyperGraphDB HyperGraphDB unterstützt die Deaktivierung der Transaktionskontrolle durch die Clientanwendung. Dies wurde genutzt, um einen effizienteren Import der Daten zu erreichen. Darüber hinaus wurden beim Import die Knoten-Ids und die Kanten-Label sowie die Anfangs- und Endknoten der einzelnen Kanten indiziert. Das Auslesen aller Kanten ließ sich mit der Anfragesprache von HyperGraphDB problemlos implementieren. Selbiges gilt für die Abfrage aller Knoten-Ids und der ausgehenden inzidenten Kanten eines Knotens für die Berechnung der starken Zusammenhangskomponenten, wobei auch die Kantenindizes genutzt werden. Die Abfrage der transitiv inzidenten Knoten konnte mit den Traversal-Anfragen von HypergraphDB als Breitensuche umgesetzt werden. Die Berechnung der gemeinsamen inzidenten Knoten zweier Ausgangsknoten a und b war mit der Anfragesprache von HyperGraphDB nicht möglich. Sie wurde durch je eine Einzelanfrage für die inzidenten Knoten von a und b mit anschließender Schnittmengenbildung in der Anwendung implementiert. Auch die regulären Graphanfragen konnten nicht mit den Anfragemöglichkeiten von HyperGraphDB implementiert werden. Das Finden ausgehender inzidenter Knoten 4 Hier wurde auf MySQL-Abfragen zurückgegriffen, da FlockDB keine Möglichkeit bietet, die Menge der gespeicherten Kanten in Erfahrung zu bringen. 71

72 für die Berechnung der regulären Graphausdrücken war mit der Anfragesprache problemlos möglich DEX DEX kann Dauerhaftigkeit für Transaktionen garantieren, dieses Feature lässt sich allerdings ein- und ausschalten. Für den Datenimport wurde es aus-, bei allen anderen Benchmarkalgorithmen eingeschaltet. Beim Datenimport wurden darüber hinaus das Knotenlabel als Primärschlüssel sowie die jeweils inzidenten Knoten indiziert. Das Auslesen aller Kanten wurde durch das iterative Auslesen aller Kanten jeweils eines Typs implementiert, da Kanten nur anhand ihres Typs ausgelesen werden können. Zur Berechnung der gemeinsamer inzidenten Knoten wurden die von DEX angebotene Schnittmengenoperation auf den Ergebnismengen zweier Anfragen genutzt je eine Ergebnismenge mit den inzidenten Konten eines der beiden Ausgangsknoten. Teil der Algorithmensammlung, welche von DEX mitgeliefert wird, ist die Berechnung starker Zusammenhangskomponenten nach Gabow [2000]. Diese wurde statt der sonst genutzten Eigenimplementierung verwendet. Ebenfalls Teil der Algorithmensammlung sind Implementierungen von Breiten- und Tiefensuchen im Graphen. Zur Abfrage der transitiv inzidenten Knoten wurde dieser Breitensuchalgorithmus genutzt. Für die Abfrage inzidenter Knoten bei der Auswertung der regulären Graphanfrage wurde unmittelbar die DEX API benutzt Experimentaufbau Die Benchmarks wurden auf einem dedizierten System mit vier AMD Opteron ,4 GHz 64 bit Dual Core Prozessoren, 32 GB RAM und zwei 72,4 GB HDDs als RAID 1 ausgeführt. 29 GB RAM wurden dabei für das jeweils laufende Benchmark genutzt. Für jede Kombination aus Graphgröße und Datenbankmanagementsystem wurden die Benchmarkalgorithmen wie folgt ausgeführt: 1. Importieren des Graphen (mit Zeitmessung) 2. Reboot (ohne Zeitmessung) 3. Auslesen aller Kanten (mit Zeitmessung) 4. Reboot und Auslesen aller Kanten (ohne Zeitmessung) 5. Berechnung der starken Zusammenhangskomponenten (mit Zeitmessung) 6. Reboot und Auslesen aller Kanten (ohne Zeitmessung) 72

73 7. Abfrage der transitiven inzidenten Knoten für pseudozufällig gewählte Ausgangsknoten ( friends-of-friends, mit Zeitmessung) 8. Reboot und Auslesen aller Kanten (ohne Zeitmessung) 9. Abfrage gemeinsamer inzidenter Knoten für pseudozufällig gewählte Knotenpaare (mit Zeitmessung) 10. Reboot und Auslesen aller Kanten (ohne Zeitmessung) 11. Auswertung der regulären Graphanfragen für pseudozufällig gewählte Ausgangsknoten (mit Zeitmessung) Ein kritischer Punkt beim Design von Datenbankbenchmarks ist der Umgang mit den Caches, welche von der Hardware, vom Betriebssytem und auch von den Datenbankmanagementsystemen selbst genutzt werden. Hier können unterschiedliche Ausführungsreihenfolgen von Algorithmen und undefinierte Warm-Up-Prozeduren zu unvergleichbaren und unreproduzierbaren Ergebnissen führen (vgl. [Dominguez-Sal et al., 2011, 3.5]). Im Rahmen dieses Benchmarks wurde daher nach jedem Benchmarkschritt ein Reboot des Systems durchgeführt, um zumindest die Software-Caches in einen definierten und möglichst leeren Zustand zurückzuversetzen. Darüber hinaus wurde das Auslesen aller Kanten als einheitlicher Schritt zum Aufwärmen der Caches vor alle anderen lesenden Algorithmen vorgeschaltet. Somit werden der Import in Schritt 1 und das Auslesen aller Kanten in Schritt 3 auf kalten Caches, alle anderen Algorithmen auf warmen Caches ausgeführt. Gemessen wurden außer beim Datenimport und dem Auslesen aller Kanten jeweils 1000 Durchläufe des Algorithmus mit pseudozufälligen Eingabeparametern. Die gemessenen Werte sind die Gesamtlaufzeit dieser 1000 Durchläufe ohne Hochund Herunterfahren des Datenbanksystems und ohne Cache-Warmup. Somit sollten einzelne Ausreißer unter den Durchläufen im Gesamtergebnis keinen wesentlichen Einfluss haben. Wo immer pseudozufällige Zahlen generiert wurden, wurde dies mittels fester Random- Seeds implementiert. So ist sichergestellt, dass die Benchmarkalgorithmen - wenngleich sie auf verschiedenen Datenbanksystemen laufen - die selben Ausgangsknoten und den selben Datenbestand verwenden. Sonst wäre es beispielsweise möglich, dass bei einem Datenbanksystem zufällig überdurchschnittlich viele Knoten mit sehr hohem Knotengrad ausgewählt werden. Hierunter würde die Vergleichbarkeit der Messergebnisse leiden. Jeder Benchmarkalgorithmus hat ein definiertes Ausgabeformat. Diese Ausgabe wird zwischen den verschiedenen Datenbanksystemen paarweise verglichen, um Vorteile einzelner Datenbanksysteme durch Implementierungsfehler zu vermeiden. Ein weiterer kritischer Punkt beim Benchmarkdesign ist die Konfiguration der einzelnen Datenbanksysteme [Dominguez-Sal et al., 2011, 3.5]. Hierbei gilt es insbesondere, einen experimentellen Bias zu vermeiden, der beispielsweise entsteht, wenn eine 73

74 Datenbank stark auf den konkreten Anwendungsfall optimiert wird, während eine andere mangels Wissen über das Optimierungspotential in der Standardkonfiguration genutzt wird. Für dieses Benchmark wurden daher nur jene Änderungen an der Standardkonfiguration der Datenbankmanagementsysteme durchgeführt, die entweder zur Anpassung an das Benchmarksystem notwendig waren (Dateipfade, etc.) oder die in der Dokumentation des Datenbankmanagementsystems explizit empfohlen wurden. Die folgenden Abschnitte geben einen kurzen Überblick über die jeweiligen Besonderheiten des Testsetups Neo4j Neo4j wurde als Embedded-Datenbank konfiguriert. Die Konfiguration orientierte sich dabei an [Neo Technology, 2012, ]: Da Neo4j Memory Mapped Files nutzt, welche Arbeitsspeicher außerhalb des JVM-Heaps belegen, können nicht die vollen 29 GB RAM für den Benchmarkcode allokiert werden. Neo4j wurde so konfiguriert, dass auch für den größten generierten Graphen die Datenbankdateien vollständig gemappt werden können: 4 GB wurde für das Mapping des Kantenspeichers, 500 MB für das Mapping des Property-Speichers und 100 MB für das Mapping des Knotenspeichers konfiguriert. Experimente zeigten, dass die JVM selbst ca. 2 GB RAM benötigte. Der Java Heap Space wurde daher auf 22 GB eingestellt. Einer weiteren Empfehlung von Neo Technology [2012, ] folgend wurden zwei Einstellungen des Linux-Kernels angepasst: Der Anteil der Dirty Pages, ab denen der Kernel seine Festplattenpuffer per Hintergrundprozess auf die Festplatte persistiert, wurde von 10% auf 50% angehoben, der Anteil der Dirty Pages, ab dem der Kernel anfängt, schreibende Festplattenzugriffe unmittelbar und synchron auszuführen, wurde von 20% auf 90% angehoben FlockDB Die Konfiguration von FlockDB gestaltete sich etwas komplexer, da hier drei unabhängige Systeme zusammenarbeiten. Insbesondere stellte sich die Frage, wie der Arbeitsspeicher auf die drei Systeme aufgeteilt werden sollte. Laut Pointer et al. [2010] war einer der Grundgedanken beim Design von FlockDB, dass die zugrunde liegenden MySQL-Instanzen genug RAM zur Verfügung haben, um alle Daten im Cache zu halten. Experimentelle Ergebnisse zeigten, dass für den größten generierten Graphen ca. 12 GB Fesplattenspeicher belegt werden. MySQL wurde daher in der mitgelieferten Standardkonfiguration my huge.cnf für sehr große Instanzen ausgeführt. Die Größe des InnoDB Buffer Pools wurde auf besagte 12 GB festgesetzt, der MyISAM-Key-Buffer wurde auf 16 MB herabgesetzt, da keine MyISAM-Tabellen genutzt werden. Die Größe des Transaktionslogs von InnoDB wurde auf 2 GB eingestellt, da ein Kommentar in my huge.cnf 25% des InnoDB 74

75 Buffer Pools empfiehlt, 2 GB aber die maximal unterstützte Größe ist. Da keine Datenreplikation genutzt wird, wurde zudem die Aufbewahrung des binären Transaktionslogs deaktiviert. Insgesamt nahm die MySQL-Instanz hiernach 17 GB RAM ein. Die verbleibenden 12 GB wurden mangels anderweitiger Empfehlungen in der Dokumentation je zur Hälfte der JVM von FlockDB und dem Benchmark-Code zugeschlagen. FlockDB wurde mit seiner mitgelieferten Konfigurationsdatei production.scala ausgeführt HyperGraphDB HyperGraphDB und BerkeleyDB JE passen ihre Cachekonfigurationen automatisch an die gegebene Größe des Java Heaps an. Dieser wurde daher auf 27 GB festgesetzt, so dass mit den bereits beschriebenen 2 GB Speicherverbrauch der JVM die zu Verfügung stehenden 29 GB RAM vollständig der JVM zugeteilt wurden. Entsprechend einer Empfehlung aus den HyperGraphDBs FAQ 5 wurde darüber hinaus der Konfigurationsschalter UseSystemAtomAttributes auf false gesetzt, da dieses Feature bisher vom Datenbanksystem selbst zwar berechnet, aber nicht ausgewertet wird DEX Da DEX größtenteils in C++ implementiert ist und die Java-Anbindung lediglich ein JNI-basierter Wrapper um diesen C++-Kern ist, werden auch die Caches von DEX außerhalb des Java-Heaps verwaltet. Die Speicherverwaltung wurde daher analog zu FlockDB konfiguriert: 6 GB wurden der JVM zugeteilt, um den Benchmark- Client auszuführen, wobei 0,5 GB zusätzlich für die JVM eingerechnet wurden. Die verbleibenden 22,5 GB wurden als maximale Cachegröße für DEX konfiguriert. Weitere Konfigurationsänderungen wurden mangels entsprechender Empfehlungen in der DEX Dokumentation nicht angepasst Methodenkritik Im Rahmen dieses Benchmarks wurden keinerlei konkurrierende Zugriffe ausgeführt. Bei diesen fließt das komplexe Zusammenspiel von Locking und Caching, Durchsatz und Latenz von Netzwerk- und Festplatten-IO, die Scheduling Strategien des Betriebsystems und auch die Geschwindigkeit der Clientanwendung in einem so hohen Maße in die Ergebnisse ein, dass für ein repräsentatives Benchmark großer Wert auf eine repräsentative Anfragelast gelegt werden muss. Diese Anfragelast wiederum ist sehr 5 Zu finden unter hypergraphdb, abgerufen am 18. Februar

76 schwer zu synthetisieren, da aufgrund der soeben beschriebenen Interdependenzen kleine Änderungen sehr große Auswirkungen haben können. Eine solche Simulation müsste realistische Anfragelast bezüglich der Anfragetypen, ihrer Häufigkeit, ihrer Sequenzierung, ihrer Ergebnisgrößen und der Verarbeitungsgeschwindigkeiten der anfragenden Anwendungen generieren hinzu kämen noch Latenzen und Netzwerkdurchsatz bei FlockDB. Ob sich solche Lastszenarien wirklich sinnvoll auf synthetischen Daten umsetzen ließen, ist zweifelhaft. Alleine die Simulation solcher Lastszenarien böte genug Raum für mehrere Diplomarbeiten, weshalb an dieser Stelle darauf verzichtet wurde. Das Benchmark führt darüber hinaus größtenteils Batch-Importe unter Umgehung der Transaktionskontrolle aus. Es fehlt daher ein Test, welcher die Schreib-Performance im Normalbetrieb testet. Auch damit hat dieses Benchmark für OLTP-Systeme nur eingeschränkte Relevanz. Allerdings wäre hierfür auch ein solches single-threaded Schreibbenchmark eher irrelevant, da bei OLTP-Systemen isolierte Schreiboperationen eher in Ausnahmefällen vorkommen. Sobald mehrere Schreiboperationen zusammenkommen, so kommt auch wieder all jene Problematiken zusammen, welche bzgl. konkurrierender Zugriffe beschrieben wurden. Der Schwerpunkt dieses Benchmarks liegt damit eher auf analytischen Anfrageszenarien, bei denen die Datenbank nur periodisch befüllt wird, um daraufhin für lesende Anfragen zur Verfügung zu stehen. Die Cachegrößen wurden so gewählt, dass zumindest bei Neo4j und FlockDB der komplette Datenbestand in den Hauptspeicher passt. Durch die gewählte Cache- Warm-Up-Prozedur (Auslesen des gesamten Graphen) dürfte sich folglich in der Regel auch der komplette Datenbestand in selbigem befinden. Dieses Benchmark sagt daher wenig darüber aus, wie effizient das Zusammenspiel zwischen den hauptspeicherbasierten Caches und der Festplatte von den einzelnen Datenbankmanagementsystemen gelöst ist. Dies ist eine bewusste Entscheidung: Auf der einen Seite hätte die Nutzung eines kleineren Hauptspeichers einer willkürlichen Grenzsetzung bedurft, die auch die Vergleichbarkeit der Ergebnisse kleiner Datenmengen mit denen großer Datenmengen zunichte gemacht hätte. Zum anderen scheinen Arbeitsspeicherbegrenzungen für klassische, nicht-verteilte Datenbanksysteme zunehmend an Relevanz zu verlieren: Mühe et al. [2012] führen dazu an, dass am Massenmarkt für Serversysteme inzwischen Hardware mit bis zu einem Terabyte verfügbar ist. Sie schreiben hierzu: [... ] main memory will not only change the database systems landscape in terms of processing speed but additionally in how solutions for well known problems like multi-tenancy can be crafted. Das gewählte Datenmodell wurde sehr einfach gehalten. Dies ermöglicht eine fairere Vergleichbarkeit hinsichtlich FlockDB, damit geht allerdings auch eine verringerte Aussagekraft in anderen Aspekten einher. Bei der Nutzung von Graphdatenbanksystemen als objektorientierte Datenbanken wird wohl die Anfrageauswertung tatsächlich 76

77 häufig graphbasiert sein, bei der Ergebnismenge hingegen werden vermutlich viele der Knoten- und Kantenproperties auch ausgelesen werden. Hier könnte HyperGraphDB, welches die Attribute eines Atoms sequentiell zusammen mit dem Atom selbst im Blattknoten des B-Baums speichert, Vorteile haben gegenüber Neo4j, welches lediglich eine verkettete Liste von Attributblöcken speichert, oder DEX, welches für jeden Attributtyp einen eigenen B-Baum verwaltet. Beim Import in FlockDB wurde keine Bündelung mehrerer Anfragen vorgenommen. Dies könnte einen Einfluss auf die Benchmarkergebnisse haben, allerdings musste zumindest bei größeren Kantenzahlen während der Benchmarkläufe stets auf die Abarbeitung der Kestrel-Queue gewartet werden. Die Kommunikation zwischen Client und FlockDB-Server scheint somit im gegebenen Setup nicht der Engpass des Systems zu sein. Auch beim Auslesen des kompletten Graphen fand keine Bündelung der Anfragen statt. Hierdurch könnte es zu einer Verzerrung der Benchmarkergebnisse gekommen sein, weshalb die Messergebnisse diesbezüglich mit Skepsis betrachtet werden sollten. Bei der Abfrage gemeinsamer inzidenter Knoten galt es bei Neo4j eine Abwägung zwischen der Nutzung zweier traversierender Anfragen mit anschließender Schnittmengenbildung oder der Nutzung von Cypher als deklarativer Anfragesprache zu treffen. Die erstere Lösung hätte mehr clientseitigen Code bedurft, dafür aber auch mehr Kontrolle über die Anfrageoptimierung gegeben. Die Entscheidung für Variante zwei sorgt folglich dafür, dass das Benchmark nicht zwingend die Performance der Datenmodells wiedergibt. Dafür ergibt sich ein Bild der Qualität des Anfrageoptimierers, was nicht weniger relevant ist. Die gewählte reguläre Graphanfrage erscheint auf den ersten Blick sehr einfach und damit wenig geeignet, die reguläre Ausdrücke gerade ausmachenden Vielfachheiten zu testen. Da Neo4j allerdings als einziges System überhaupt reguläre Graphausdrücke unterstützt, wäre ein solcher Test in einem vergleichenden Benchmark deplatziert. Der hier gewählte einfache Ausdruck ermöglicht vielmehr, zu testen, in wie fern Neo4j in der Lage ist, zumindest bei einfachen Anfragen Ausführungspläne zu generieren, die mit händischer Optimierung vergleichbar sind. Die Verwendung von Domänenwissen über die Selektivität der einzelnen Kantenlabels ist damit auch keine schwerwiegende Verzerrung, da Selektivitätsabschätzungen zum normalen Handwerkszeug der (automatischen) Anfrageoptimierung gehören. Dies wäre daher auch von einem Datenbankmanagementsystem zu erwarten, welches reguläre Graphanfragen unterstützt. Die Ergebnisse dürfen dennoch nicht so interpretiert werden, als wären einzelne der vorgestellten Systeme alleine aufgrund ihrer Geschwindigkeit reguläre Graphanfragen besonders geeignet. 77

78 7.5. Ergebnisse In diesem Abschnitt sollen die Ergebnisse des Benchmarks zusammenfassend dargestellt werden. Hierbei kann der Kürze wegen nur auf einen exemplarischen Ausschnitt der Messdaten eingegangen werden. Die vollständigen Messdaten finden sich im Anhang B. An einigen Stellen fehlen Messwerte. Dies ist zum einen bei FlockDB der Fall, welches nach Pointer et al. [2010] rigide Timeouts nutzt. Dies führte dazu, dass einzelne Algorithmen mit steigender Datenbankgröße häufig fehlschlugen. Bei der Berechnung der starken Zusammenhangskomponenten war ab 1 Mio. Kanten der JVM-Stack zu klein für die Eigenimplementierung. Außerdem wurde die Ausführung der Benchmarkalgorithmen auf HyperGraphDB und FlockDB bei großen Datenmengen teils so langsam, dass diese abgebrochen werden musste. Die Benchmarkalgorithmen wurden auch auf Datenbanken ausgeführt, welche unrealistisch niedrige Durchschnittsknotengrade aufweisen. Wenn vom signifikanten Punkten die Rede ist, so meint dies die Kombinationen von Knoten- und Kantenanzahl, welche einen Durchschnittsknotengrad im Bereich zwischen 2, 5 und 403, 5 aufweisen. In diesem Bereich ist der Durchschnittsknotengrad auch in den Abbildungen gezeichnet. In den Tabellen im Anhang B sind die signifikanten Werte fett hervorgehoben. Das jeweils rechte Diagramm jeder Abbildung trägt die Gesamtzahl an Entitäten, also die Summe der Anzahl von Knoten und Kanten, gegen die Laufzeit des jeweiligen Algorithmus auf. Da die Kantenanzahl jeweils um den Faktor 10, die Knotenanzahl aber um den Faktor 2 erhöht wurde, bedeuten horizontal eng zusammenliegende Punkte eine Erhöhung der Knoten, weiter auseinanderliegende Punkte eine Erhöhung der Kantenanzahl. Durch die Kombination dieser beiden Aspekte erklärt sich auch die Unstetigkeit der Graphen. Beginnend mit Abbildung 7.5 wurden in diesen Diagrammen die Datenpunkte nicht mehr gezeichnet. Wegen der Masse der Datenpunkte wäre sonst eine Erkennbarkeit bei eng zusammenliegenden Werten nicht mehr möglich gewesen Ergebnisse der einzelnen Algorithmen Beim Datenimport teilen sich Neo4j und DEX bei den signifikanten Punkten die vorderen Plätze. Während DEX bei Datenbanken mit weniger als 1 Mio. Kanten teils deutlich schneller ist, fällt es bei höheren Kantenmengen hinter Neo4j zurück. Deutlich dahinter rangiert HyperGraphDB, FlockDB ist am langsamsten. In Abbildung 7.3 ist auch zu erkennen, dass FlockDB von steigenden Knotenzahlen weniger beeinflusst wird als die anderen Systeme. Dies ist wohl darauf zurückzuführen, dass FlockDB kaum Informationen über die Kanten speichert. In Abbildung 7.4 sind die Laufzeiten für das Auslesen aller Kanten des Graphen bei kalten Caches abgebildet. Für Graphen mit oder mehr Entitäten hier teilen 78

79 Kanten Knoten signifik. Punkte Laufzeit (s) Anzahl Knoten Anzahl Kanten Anzahl Entitäten Neo4j FlockDB HyperGraphDB DEX Knotengrad Abbildung 7.3.: Messergebnisse: Import eines Graphen mit variabler Anzahl Knoten und Kanten in verschiedene Datenbanksysteme Kanten Knoten signifik. Punkte Laufzeit (s) Anzahl Knoten Anzahl Kanten Anzahl Entitäten Neo4j FlockDB HyperGraphDB DEX Knotengrad Abbildung 7.4.: Messergebnisse: Auslesen aller Kanten eines Graphen mit variabler Anzahl Knoten und Kanten bei kalten Caches aus verschiedenen Datenbanksystemen 79

80 Kanten Knoten 10 4 signifik. Punkte Laufzeit (s) Anzahl Knoten Anzahl Kanten Anzahl Entitäten Neo4j FlockDB HyperGraphDB DEX Knotengrad Abbildung 7.5.: Messergebnisse: Auslesen transitiv inzidenter Knoten in einem Graphen mit variabler Anzahl Knoten und Kanten bei warmen Caches aus verschiedenen Datenbanksystemen sich DEX und Neo4j die vorderen Plätze DEX ist bei Graphen unter 1 Mio. Knoten schneller, Neo4j bei Graphen über 1 Mio. Knoten. FlockDB und HyperGraphDB teilen sich den letzten Platz. Auffällig ist hier, dass die Ausführungsdauer auf FlockDB kaum von der Kantenanzahl, aber massiv von der Knotenanzahl abhängt. Dies ist dadurch zu begründen, dass diese Anfrage auf FlockDB durch iterative Anfragen der inzidenten Kanten jedes einzelnen Knotens implementiert werden musste. Beim Auslesen der transitiv inzidenten Kanten ergibt sich ein sehr ausgeglichenes Bild. Wenig überraschend liegt FlockDB hier bei nahezu allen signifikanten gemessenen Werten auf dem letzten Platz. Dies deckt sich mit der Aussage von Pointer et al. [2010], dass effizientes Traversieren kein Designziel von FlockDB sei. Außerdem zeigt sich, dass DEX und Neo4j bei traversierenden Anfragen auf hinreichend großen Graphen (> Entitäten) in den signifikanten Messwerten nahezu gleich schnell sind. HyperGraphDB ist auch hier langsamer als Neo4j und DEX. Auf den ersten Blick überraschend mag eventuell der Laufzeitverlauf bei fester Kantenzahl in Abbildung 7.5 sein. Hier steigen die Graphen zuerst, wie intuitiv eventuell erwartbar wäre, mit steigender Datenmenge, um dann jedoch stark abzufallen. Letzteres erklärt sich daraus, dass mit sinkendem Knotengrad die Menge der bei einer Breitensuche zu verfolgenden Kanten und damit auch die Ausführungszeit sinkt. Ersteres erklärt sich damit, dass bei 2 9 Knoten und Kanten der Durchschnittsknotengrad bei ca. 390 liegt, ein sehr großer Teil der Knoten ist hier folglich schon bei einer sehr geringen Suchtiefe erreicht die volle Suchtiefe von 3 Schritten wird nur äußerst selten nötig sein. Die Laufzeiten der Berechnung der starken Zusammenhangskomponenten sind in Abbildung 7.6 abgebildet. Bei den signifikanten Punkten lässt sich eine eindeutige 80

81 Kanten 512 Knoten signifik. Punkte Laufzeit (s) Anzahl Knoten Anzahl Kanten Anzahl Entitäten Neo4j FlockDB HyperGraphDB DEX Knotengrad Abbildung 7.6.: Messergebnisse: Berechnung der starken Zusammenhangskomponenten eines Graphen mit variabler Anzahl Knoten und Kanten bei warmen Caches aus verschiedenen Datenbanksystemen Rangfolge feststellen: DEX ist das schnellste unter den Systemen, Neo4j das zweitschnellste, Hypergraph auf Platz 3 und FlockDB auf dem letzten Platz. Auffällig ist, dass die Laufzeit hier im Gegensatz zur lokal traversierenden Anfrage keine Korrelation zum Durchschnittsknotengrad zeigt. Dies rührt daher, dass bei global traversierenden Anfragen stets alle Kanten traversiert werden, die Größe des Suchraums ist unabhängig vom Knotengrad. Es fällt ebenfalls auf, dass sämtliche untersuchten Datenbanksysteme deutlich sensibler auf Steigerungen der Knotenzahl als auf Steigerungen der Kantenzahl reagieren, wobei dieser Effekt bei Neo4j am schwächsten ist. Dies rührt daher, dass jeder Knoten einmal traversiert wird. Für jeden Knoten wird somit einmal die Inzidenzmenge abgefragt. Steigt nun die Menge an Knoten, so steigt auch die Menge an Inzidenzmengenanfragen. Steigt hingegen die Menge an Kanten, so werden die Inzidenzmengen lediglich größer. Besonders deutlich ist dieser Effekt bei FlockDB zu erkennen, wo jede Inzidenzmengenanfrage über zwei Kommunikationsschnittstellen gereicht wird und danach noch eine Suche in einem B-Baum erfordert. Hier zeigt sich auch ein Vorteil des Datenmodells von Neo4j: Da ausgehend von einer Knotenreferenz ein Pointer auf die Menge der inzidenten Kanten existiert, reagiert es deutlich weniger sensibel auf solche Veränderungen der Knotenanzahl als DEX, welches hierfür anhand der Objekt-Id einen B-Baum traversieren muss. Bei mengenorientierten Anfragen (Abbildung 7.7) liegt DEX deutlich an der Spitze. Hier folgt FlockDB auf Platz 2, mit einer leichten Annäherung an DEX bei größeren Graphen. Die verhältnismäßig gute Performance von FlockDB deckt sich mit der Aussage von Pointer et al. [2010], dass mengenorientierte Anfragen der Designschwerpunkt von FlockDB gewesen seien. HyperGraphDB liegt bei sehr kleinen Graphen auf 81

82 Kanten 512 Knoten signifik. Punkte Laufzeit (s) Anzahl Knoten Anzahl Kanten Anzahl Entitäten Neo4j FlockDB HyperGraphDB DEX Knotengrad Abbildung 7.7.: Messergebnisse: Auslesen gemeinsamer inzidenter Knoten in einem Graphen mit variabler Anzahl Knoten und Kanten bei warmen Caches aus verschiedenen Datenbanksystemen dem dritten Platz, Neo4j bei größeren Graphen. Das im Vergleich zu traversierenden Anfragen schlechtere Abschneiden von Neo4j könnte allerdings auch auf fehlende Anfrageoptimierung von Cypher zurückzuführen sein. Die Dreieckssuchanfrage, die als Beispiel eines regulären Graphausdrucks ausgeführt wurde, wurde bei FlockDB, HyperGraphDB und DEX als lokal traversierende Anfrage umgesetzt, weshalb bei den Ausführungszeiten keine Überraschungen im Vergleich zur Abfrage transitiv inzidenter Knoten zu erwarten waren. Abbildung 7.8 zeigt die Ergebnisse. Da der selbstgeschriebene Auswertungsalgorithmus mit dem selektivsten Kantenlabel beginnt, welches nur bei 7,8 % der Knoten gesetzt ist, werden hier weniger Knoten traversiert als bei der Abfrage transitiv inzidenter Knoten in Abbildung 7.5. Dadurch werden in FlockDB weniger einzelne SQL-Anfragen ausgeführt, weshalb FlockDB etwas besser abschneidet. Es liegt sogar größtenteils vor HyperGraphDB. Was im Vergleich ebenfalls auffällt, ist das deutlich schlechtere Abschneiden von Neo4j. Dies deutet darauf hin, dass Neo4j wohl keine selektivitätsbasierte Anfrageoptimierung vornimmt. Interessanterweise ist auch hier zu beobachten, dass sich DEX und Neo4j nichtsdestotrotz bei großen Datenmengen deutlich aneinander annähern Gesamtergebnis In der Zusammenfassung von Kapitel 6 wurde die Hypothese aufgestellt, dass Neo4j aufgrund der unmittelbaren Verknüpfung verbundener Entitäten auf Persistenzebene einen signifikanten Vorteil bei traversierenden Anfragen vor DEX, HyperGraphDB und FlockDB habe, welche allesamt auf B-Bäumen basieren. 82

83 Kanten 512 Knoten signifik. Punkte Laufzeit (s) Anzahl Knoten Anzahl Kanten Anzahl Entitäten Neo4j FlockDB HyperGraphDB DEX Knotengrad Abbildung 7.8.: Messergebnisse: Finden von Dreiecken in einem Graphen mit variabler Anzahl Knoten und Kanten bei warmen Caches aus verschiedenen Datenbanksystemen Zusammenfassend lässt sich allerdings sagen, dass nahezu allen ausgeführten Algorithmen mit DEX die geringsten Laufzeiten hatten teilweise mit deutlichem Vorsprung, teilweise zusammen mit Neo4j. Dies betrifft insbesondere auch die traversierenden Algorithmen und widerspricht folglich der Erwartung. Bei vielen Algorithmen war bei großen Datenmengen allerdings eine Annäherung der Laufzeiten von DEX und Neo4j zu beobachten. Hier wäre interessant zu sehen, wie sich die Verhältnisse bei noch größeren Datenmengen entwickeln. Diese Annäherung ist auch insofern interessant, als das Martínez-Bazan et al. [2012] die Vorteile der von DEX gewählten Persistenzarchitektur insbesondere bei sehr großen Graphen sehen, was hier folglich ebenfalls nicht belegt werden konnte. HyperGraphDB hatte bei nahezu allen Algorithmen signifikant schlechtere Laufzeiten als DEX und Neo4j. Allerdings wurden die Algorithmen lediglich auf gerichteten Graphen, nicht auf Hypergraphen ausgeführt. Eventuell verringert sich dieser Abstand, wenn die Datenbasis viele n-äre Verknüpfungen beinhaltet, da HyperGraphDB für ebendiesen Anwendungsfall entwickelt wurde. Da bei graphbasierten Datenbankmanagementsystemen Hyperkanten mittels Zwischenknoten abgebildet werden müssten, könnte hier die kompaktere Repräsentation zum Vorteil gereichen. Die teils sehr großen Laufzeitunterschiede zwischen den Systemen lassen hieran aber Zweifel aufkommen. Es zeigte sich, dass bei beiden Algorithmen, bei denen Cypher als Anfragesprache genutzt wurde, Neo4j im Verhältnis deutlich schlecher abschnitt, als sonst. Bei den regulären Graphanfragen ist schlechte Anfrageoptimierung von Cypher sogar der einzige überzeugende Erklärungsansatz. Dies deckt sich mit den Ergebnissen von 83

84 Holzschuher und Peinl [2013], welche ebenfalls einen signifikanten Vorsprung der Neo4j Java-API gegenüber Cypher-Anfragen festgestellt haben. 84

85 8. Zusammenfassung Graphdatenbanksysteme sind ein geeignetes Konzept, um große Datenmengen mit Fokus auf Beziehungen zwischen Entitäten effizient zu persistieren und zu verarbeiten. Da sowohl Knoten als auch Kanten elementarer Teil ihres Datenmodells sind, lassen sich Graphen einfach in diesen speichern. Graphalgorithmen können selbst dann, wenn das Datenbankmanagementsystem keine komplexen Anfragesprachen anbietet, sehr einfach implementiert werden. Dies zeigte sich auch bei der Implementierung der Benchmarkalgorithmen, die sich dank der graphbasierten Anfragesemantik deutlich einfacher gestaltete als dies bspw. mit relationalen Systemen möglich gewesen wäre. Hier kam der Vorteil eines Datenbanksystems zum Tragen, dessen Datenmodell sich mit dem der zu verarbeitenden Domäne deckt. Holzschuher und Peinl [2013] und Vicknair et al. [2010] kommen diesbezüglich zu ähnlichen Ergebnissen. Graphdatenbanksysteme bieten ein Datenmodell, welches dem häufig verwendeter objektorientierter Programmiersprachen deutlich näher ist als beispielsweise das relationale Modell. Im Rahmen von [Gehrels, 2012] zeigte sich, dass gelabelte Propertygraphen tatsächlich geeignet sind, den objekt-relationalen Impedance Mismatch deutlich zu verringern. Zwar bieten diese keine unmittelbare Abbildungsmöglichkeit für Vererbungen, allerdings lassen sich zumindest Objekte und ihre Attribute gut auf Knoten und ihre Properties, Beziehungen bestimmter Art zwischen Objekten gut auf gelabelte Kanten abbilden. Graphdatenbanksysteme können laut Vicknair et al. [2010] traversierende Anfragen teils deutlich schneller auswerten als MySQL als relationales System. Holzschuher und Peinl [2013] berichten von Geschwindigkeitssteigerungen einer Größenordnung bei lokal traversierenden Anfragen. Die Wahl eines passenden Datenmodells kann hier anscheinend auch zu einer effizienteren Speicherung und Anfragebearbeitung führen. Das graphbasierte Datenmodell erlaubt es insbesondere, die explizit gegebene Struktur des Graphen durch Pointer zwischen Records zu persistieren. Die etwaige Schlussfolgerung, dass dies als Folge deutlich besserer Komplexitätsabschätzungen bei traversierenden Anfragen zwangsläufig Performancevorteile bringe, scheint aber zu kurz zu greifen. So ließ sich in den Benchmarks bei traversierenden Anwendungen kein klarer Vorteil von Neo4j nachweisen, welches als einziges untersuchtes System Knoten- und Kantenrecords durch Pointer persistiert. Insbesondere bei kleineren Graphen war DEX als B-Baum-basiertes System sogar deutlich schneller. 85

86 8.1. Neo4j Neo4j bietet die vielfältigsten Anfragemöglichkeiten von elementaren Knotenund Kantenoperationen über traversierende Anfragen bis hin zu Cypher, einer deklarativen Anfragesprache für reguläre Graphanfragen mit einer sehr geringen Einarbeitungsschwelle. Neo4j garantiert ACID-Eigenschaften für Transaktionen und ist auch für große Leselast horizontal skalierbar. Die Benchmarkergebnisse zeigen Neo4j meist auf den vorderen Plätzen, wobei die Anfrageoptimierung bei Cypher noch ausbaufähig zu sein scheint. Sofern keine horizontale Skalierbarkeit bezüglich Datenmenge oder Schreiblast benötigt wird, scheint Neo4j als einziges untersuchtes System vorbehaltlos als Graphdatenbankmanagementsystem für größere OLTP-Anwendungen geeignet zu sein. Diesbezüglich fehlt es allerdings an praktischen Benchmarkergebnissen. Neo4j eignet sich besonders, um in objektorientierten Systemen den objekt-relationalen Impedance Mismatch zu überbrücken und Kohärenz zwischen den Datenmodellen der Anwendung und des Datenbanksystems zu bieten FlockDB FlockDB ist als einziges System dafür ausgelegt, eine weitreichende Skalierbarkeit bei einer steigenden Zahl konkurrierender Schreibzugriffe und vieler lesender Mengenanfragen zu bieten. Es ist ein von Grund auf verteiltes Datenbankmanagementsystem, welches Eventual Consistency garantiert und MySQL als Key-Value-Store gebraucht. Basierend auf Gizzard bietet es gute Möglichkeiten zur Clusterverwaltung. Dies alles geht allerdings einher mit einem sehr minimalistischen Funktionsumfang und nur sehr eingeschränkt vorhandener Dokumentation. Das Datenmodell ist wenig mehr als eine um eine natürliche Kantenordnung und Kantenlabels erweiterte Inzidenzmatrix. Die Anfragesprache ist rein mengenbasiert, traversierende Anfragen werden nicht unterstützt. FlockDB scheint damit besonders in Kombination mit anderen Datenbanksystemen (sog. Polyglot Persistence [Leberknight, 2008]) nutzbar zu sein: In einer fiktiven Anwendung können bspw. komplexe Nutzerprofile in einer dokumentenorientierten Datenbank gespeichert werden, während die sich häufiger ändernden Beziehungen zwischen den Nutzern in FlockDB persistiert werden. In einem solchen Umfeld von Polyglot Persistence, massiver Schreiblast und hauptsächlich mengenbasierten Anfragen kann FlockDB seine Vorteile ausspielen. Andere Anwendungsszenarien scheinen bei Betrachtung der Benchmarkergebnisse eher wenig empfehlenswert zu sein. 86

87 8.3. HyperGraphDB HyperGraphDB kombiniert ein mächtiges Datenmodell, verhältnismäßig vielfältige Indizierungsmöglichkeiten, einen guten mengenbasierten Anfragemechanismus und die Möglichkeit, relativ einfach traversierende Anfragen zu spezifizieren. Ein Mapping von Java-Objekten auf Datenbankentitäten scheint sehr einfach zu sein. Hyper- GraphDB unterstützt ACI-Transaktionen. Es existiert keine hinreichend dokumentierte Möglichkeit, HyperGraphDB als verteiltes Datenbankmanagementsystem zu nutzen. Die Anzahl an Entwicklern und Nutzern scheint eher gering zu sein, was sich in der Qualität der Software niederschlägt alleine im Rahmen dieser Arbeit wurden mehrere Fehler gefunden. Darüber hinaus lag das System bei nahezu allen im Rahmen dieser Arbeit ausgeführten Benchmarks im hinteren Bereich. Nichtsdestotrotz kann HyperGraphDB gerade für kleinere Anwendungen, deren Datenmodell auf Hypergraphen basiert und bei denen hohe Performance keine übergeordnete Bedeutung hat, eine gute Wahl sein DEX DEX hat eine überzeugende Performance bei allen getesteten Anfragetypen. Allerdings bringt es nur rudimentäre Anfragemöglichkeiten und eine unpraktische API mit sich. Die Transaktionskontrolle scheint für eine größere Menge konkurrierender Schreibzugriffe nachteilig, da Schreibzugriffe stets eine Sperrung des gesamten Datenbestands bewirken. Bei der Nutzung als verteilte Datenbank kann das System schon in einigen einfachen Fehlerfällen in einem nicht mehr betriebsfähigen Zustand zurückbleiben. Insbesondere für analytische Anfragen auf sehr großen Datenbeständen scheint DEX dennoch hervorragend geeignet zu sein: OLAP-Systeme werden häufig mittels Batch- Importen befüllt und es ist meist auch akzeptabel, wenn das System hier eine Zeit lang nur eingeschränkt zur Verfügung steht. Bei der Nutzung selbstgeschriebener Auswertungsalgorithmen ist auch eine fehlende mächtigere Anfragesprache entbehrlich. Die hervorragende Performance bei der Auswertung großer Datenbestände ist dann Kernanforderung. Sind gelegentliche Systemausfälle tolerabel, aber sehr viele lesende Anfragen zu verarbeiten, so kann auch die Nutzung als verteilte Datenbank eine vorteilhafte Lösung darstellen Ausblick Es ist zu überlegen, ob HyperGraphDB mit dem Konzept von Atomen nicht gerade die Vorteile, die ein Graphdatenmodell bietet, verloren haben: Die Beziehung zwischen Entitäten als Element erster Klasse im Datenmodell. Ein geeigneterer Ansatz könnten 87

88 klassische Hypergraphen sein, welche Kanten mit mehreren klar definierten Anfangsund Endpunkten haben. Systeme mit solchen Datenmodellen existieren allerdings heute noch nicht am Markt. Eine interessante Erweiterung bekannter Graphmodelle beschreiben auch Hunger und Plantikow [2013]: So sollen einem Knoten ein oder mehrere Label zugeordnet werden können. Dies könnte beispielsweise zur Abbildung von Vererbungshierarchien nützlich sein. Offen geblieben ist die Frage, weshalb das Persistenzmodell von Neo4j nicht die theoretisch zu erwartenden Vorteile brachte. Ein Erklärungsansatz könnte sein, dass DEX eine deutlich kompaktere Datenrepäsentation bietet. Somit könnte es zu einer effizienteren Nutzung insbesondere der CPU-Caches gekommen sein, welche die theoretischen Vorteile pointerbasierter Persistenz aushebelt. Hier wäre es spannend zu untersuchen, ob dies wirklich der ausschlaggebende Faktor war, und ob es möglich ist, das theoretisch überlegende pointerbasierte Persistenzmodell noch wirksamer zum Einsatz zu bringen. Die durchgeführten Benchmarks haben Datenbanksysteme, welche für die Speicherung auf Festplatten entworfen wurden, in einem Setup gemessen, in welchem quasi alle Daten im Hauptspeicher lagen. Wenn rein hauptspeicherbasierte Datenbanksysteme zukünftig tatsächlich eine steigende Bedeutung erfahren, so wäre die Frage, wie sich Graphdatenbanken effizient im Hauptspeicher repräsentieren lassen, ein interessantes Feld für zukünftige Arbeiten. Im Rahmen dieser Arbeit nicht gemessen und dennoch hochinteressant ist die Performance der verschiedenen Systeme bei konkurrierenden Zugriffen. Hierbei zeigt sich erst, inwiefern Neo4j und HyperGraphDB tatsächlich als OLTP-Systeme geeignet sind und ob die ungranulare Locking-Strategie von DEX wirklich problematisch ist. Das Ende 2012 gegründete Linked Data Benchmark Council 1, ein Projekt mehrerer Datenbankhersteller und Universitäten zur Entwicklung aussagekräftiger Graphdatenbankbenchmarks, könnte hier gute Ansätze liefern. 1 Zu finden unter abgerufen am 26. März

89 A. Literaturverzeichnis Amann, B. und Scholl, M. (1992). Gram: a graph data model and query languages. In Lucarella, D., Nanard, J., Nanard, M., und Paolini, P. (Hrsg.), ECHT 92: Proceedings of the ACM conference on Hypertext, Seite ACM. Angles, R. (2012). A comparison of current graph database models. In ICDEW [2012], Seiten Angles, R. und Gutierrez, C. (2008). Survey of graph database models. ACM Computing Surveys, 40(1). Apache (2008). Apache Hadoop. Apache Software Foundation. Apache (2012). Lucene Java Documentation. The Apache Software Foundation. Online, abgerufen am 22. September Bader, D. A., Feo, J., Gilbert, J., Kepner, J., Koester, D., Loh, E., Madduri, K., Mann, B., Meuse, T., und Robinson, E. (2009). HPC Scalable Graph Analysis Benchmark, 1.0 Ausgabe. Online, GraphAnalysisBenchmark-v1.0.pdf, abgerufen am 24. Februar Boley, H. (1977). Directed recursive labelnode hypergraphs: A new representationlanguage. Artificial Intelligence, 9(1): Brewer, E. (2012). Cap twelve years later: How the rules have changed. Online, abgerufen am 25. März Brewer, E. A. (2000). Towards robust distributed systems. Invited Talk, Principles of Distributed Computing, Portland, Oregon, July Slides online: http: // abgerufen am 25. März Buerli, M. (2012). The current state of graph databases. Online, Bibliography/Graph_Databases_Survey.pdf, abgerufen am 23. März Cachopo, J. und Rito-Silva, A. (2006). Versioned boxes as the basis for memory transactions. Science of Computer Programming, 63(2):

90 Calvanese, D., Giacomo, G. D., Lenzerini, M., und Vardi, M. Y. (2000). Containment of conjunctive regular path queries with inverse. In Cohn, A. G., Giunchiglia, F., und Selman, B. (Hrsg.), KR 2000, Principles of Knowledge Representation and Reasoning Proceedings of the Seventh International Conference, Breckenridge, Colorado, USA, April 11-15, 2000, Seiten Morgan Kaufmann. Carey, M. J., DeWitt, D. J., und Naughton, J. F. (1993). The OO7 benchmark. In Buneman, P. und Jajodia, S. (Hrsg.), Proceedings of the 1993 ACM SIGMOD International Conference on Management of Data, Washington, D.C., May 26-28, 1993, Seiten ACM. Cattell, R. G., Barry, D. K., Berler, M., Eastman, J., Jordan, D., Russell, C., Schadow, O., Stanienda, T., und Velez, F. (Hrsg.) (2000). The Object Data Management Standard: ODMG 3.0. Morgan Kaufmann. Cattell, R. G. G. und Skeen, J. (1992). Object operations benchmark. ACM Transactions on Database Systems, 17(1):1 31. Chakrabarti, D. und Faloutsos, C. (2006). Graph mining: Laws, generators, and algorithms. ACM Computing Surveys, 38(1). Chakrabarti, D., Zhan, Y., und Faloutsos, C. (2004). R-MAT: A recursive model for graph mining. In Berry, M. W., Dayal, U., Kamath, C., und Skillicorn, D. (Hrsg.), Proceedings of the Fourth SIAM International Conference on Data Mining, Seite Society for Industrial and Applied Mathematics. Ching, A., Choi, H., Homan, J., Kunz, C., O Malley, O., Mannix, J., Ryaboy, D., Martella, C., Schelter, S., und Koontz, E. (2012). Apache Giraph. Apache Software Foundation. Online, incubator.apache.org/giraph/, abgerufen am 24. März Ciglan, M., Averbuch, A., und Hluchy, L. (2012). Benchmarking traversal operations over graph databases. In ICDEW [2012], Seiten Codd, E. F. (1970). A relational model of data for large shared data banks. Communications of the ACM, 13(6): Dean, J. und Ghemawat, S. (2004). Mapreduce: Simplified data processing on large clusters. In OSDI 04: Proceedings of the 6th conference on Symposium on Opearting Systems Design & Implementation - Volume 6. USENIX Association. Dominguez-Sal, D., Martinez-Bazan, N., Muntes-Mulero1, V., Baleta, P.,, und Larriba-Pey, J. L. (2011). A discussion on the design of graph database benchmarks. In Nambiar, R. und Poess, M. (Hrsg.), Proceedings of the Second TPC technology conference on Performance evaluation, measurement and characterization of complex systems, number 6417 in Lecture Notes In Computer Sciences, Seiten Transaction Processing Performance Council, Springer-Verlag. 90

91 Dominguez-Sal, D., Urbón-Bayes, P., Giménez-Vañó, A., Gómez-Villamor, S., Martínez-Bazán, N., und Larriba-Pay, J. (2010). Survey of graph database performance on the HPC scalable graph analysis benchmark. In Shen et al. [2010], Seiten FIPA (2002). FIPA ACL message structure specification. Online. org/specs/fipa00061/sc00061g.pdf, abgerufen am 02. Februar Fox, A., Gribble, S. D., Chawathe, Y., Brewer, E. A., und Gauthier, P. (1997). Cluster-based scalable network services. In Waite, W. M. (Hrsg.), SOSP 97 Proceedings of the sixteenth ACM symposium on Operating systems principles. Association for Computing Machinery. Gabow, H. N. (2000). Path-based depth-first search for strong and biconnected components. Information Processing Letters, 74(3 4): Gehrels, B. R. (2012). Entwicklung einer Schnittstelle zur Abfrage von Protein- Protein-Interaktionsgraphen. Studienarbeit, Online, finished/2012/sa_gehrels_final.pdf, abgerufen am 18. Dezember Gehrels, B. R. (2013). FlockDB Client A lightweight, idiomatic Java wrapper around the Thrift API of FlockDB. Online, Client/blob/f62a46954f62e4447f14dd8db07cca30ebe99e34/README.md, abgerufen am 29. Januar Gioran, C. (2010a). Neo4j Internals: File Storage. Online. blogspot.de/2010/10/neo4j-internals-file-storage.html, abgerufen am 22. September Gioran, C. (2010b). Neo4j Internals: Persistence and Memory Mapping. Online. abgerufen am 22. September Gioran, C. (2010c). Neo4j Internals: Transactions (Part 1) Write Ahead Log and Deadlock Detection. Online. 10/neo4j-internals-transactions-part-1.html, abgerufen am 22. September Gioran, C. (2012). Master election in Neo4j High Availability Clusters. Online. abgerufen am 22. September Gonzalez, J. E., Low, Y., Gu, H., Bickson, D., und Guestrin, C. (2012). PowerGraph: Distributed graph-parallel computation on natural graphs. In Proceedings of the 10th USENIX Symposium on Operating Systems Design and Implementation, Hollywood, CA, USA October 8 10, 2012, Seiten The USENIX Association. 91

92 Guo, Y., Pan, Z., und Heflin, J. (2005). Lubm: A benchmark for owl knowledge base systems. Journal of Web Semantics, 3(2 3): Holzschuher, F. und Peinl, R. (2013). Performance of graph query languages comparison of Cypher, Gremlin and native access in Neo4j. In EDBT/ICDT Workshops 2013 Electronic Conference Proceedings. Online, org/proceedings/2013-genova/index.html, abgerufen am 23. März Härder, T. und Reuter, A. (1983). Principles of transaction-oriented database recovery. ACM Computing Surveys, 15(4): Hunger, M. und Plantikow, S. (2013). Cypher in Neo4j Labels and indexing. Hunt, P., Konar, M., Junqueira, F. P., und Reed, B. (2010). Zookeeper: wait-free coordination for internet-scale systems. In Barham, P. und Roscoe, T. (Hrsg.), Proceedings of the 2010 USENIX conference on USENIX annual technical conference, Seite 11. USENIX Association. ICDEW (2012). Proceedings af the 28th IEEE International Conference on Data Engineering Workshops. IEEE. Iordanov, B. (2010). HyperGraphDB: A Generalized Graph Database. In Shen et al. [2010], Seiten Kallen, N., Pointer, R., Ceaser, E., und Kalucki, J. (2010). Introducing Gizzard, a framework for creating distributed datastores. Online. twitter.com/2010/04/introducing-gizzard-framework-for.html, abgerufen am 27. September Klyne, G. und Carroll, J. J. (Hrsg.) (2004). Resource Description Framework (RDF): Concepts and Abstract Syntax. The World Wide Web Consortium (W3C). Kobrix (2012). HyperGraphDB How to use indices. Online, com/p/hypergraphdb/wiki/indiceshowto, abgerufen am 28. Januar Koschmieder, A. und Leser, U. (2012). Regular path queries on large graphs. In Ailamaki, A. und Bowers, S. (Hrsg.), Scientific and Statistical Database Management 24th International Conference, SSDBM 2012, Chania, Crete, Greece, June 25 27, Proceedings, Volume 7338 der Lecture Notes in Computer Science, Seiten Springer. Leberknight, S. (2008). Polyglot persistence. Online. com/blogs/scott_leberknight/polyglot_persistence.html, abgerufen am 21. März Leskovec, J., Chakrabarti, D., Kleinberg, J., und Faloutsos, C. (2005). Realistic, mathematically tractable graph generation and evolution, using kronecker multiplication. In Jorge, A., Torgo, L., Brazdil, P., Camacho, R., und Gama, J. (Hrsg.), 92

93 Knowledge Discovery in Databases: PKDD 2005: 9th European Conference on Principles and Practice of Knowledge Discovery in Databases, Porto, Portugal, Oktober 2005, Proceedings, Volume 3721 der Lecture Notes in Artificial Intelligence, Seite Springer. Leskovec, J., Lang, K. J., Dasgupta, A., und Mahoney, M. W. (2008). Statistical properties of community structure in large social and information networks. Manuscript, Online, &rep=rep1&type=pdf, abgerufen am 07. Februar 2012, gekürzt veröffentlicht in [WWW, 2008]. Malewicz, G., Austern, M. H., Bik, A. J., Dehnert, J. C., Horn, I., Leiser, N., und Czajkowski, G. (2010). Pregel: a system for large-scale graph processing. In SIGMOD 10: Proceedings of the 2010 international conference on Management of data, Seiten , New York, NY, USA. ACM Martínez-Bazan, N., Águila Lorente, M. A., Muntés-Mulero, V., Dominguez-Sal, D., Gómez-Villamor, S., und Larriba-Pey, J.-L. (2012). Efficient graph management based on bitmap indices. In IDEAS 12: Proceedings of the 16th International Database Engineering & Applications Sysmposium, Seiten ACM. Martínez-Bazan, N., Nin, J., Muntés-Mulero, V., Sánchez-Martínez, M.-A., Gómez- Villamor, S., und Larriba-Pey, J.-L. (2007). DEX: High-performance exploration on large graphs for information retrieval. In CIKM 07: Proceedings of the sixteenth ACM conference on information and knowledge management, New York, NY, USA. ACM. Mendelzon, A. O. und Wood, P. T. (1989). Finding regular simple paths in graph databases. In Apers, P. M. G. und Wiederhold, G. (Hrsg.), Proceedings of the Fifteenth International Conference on Very Large Data Bases, August 22 25, 1989, Amsterdam, The Netherlands, Seiten Morgan Kaufmann. Mühe, H., Kemper, A., und Neumann, T. (2012). The mainframe strikes back: Elastic multi-tenancy using main memory database systems on a many-core server. In Rundensteiner, E., Markl, V., Manolescu, I., Amer-Yahia, S., Naumann, F., und Ari, I. (Hrsg.), Proceedings of the 15th International Conference on Extending Database Technology, Seiten Michael, M., Moreira, J. E., Shiloach, D., und Wisniewski, R. W. (2007). Scale-up x scale-out: A case study using nutch/lucene. In 21st International Parallel and Distributed Processing Symposium Proceedings. IEEE International. Milgram, S. (1967). The small-world problem. Psychology Today, 1(1): Neo Technology (2012). Neo4j the graph database. Neo Technology. Online, abgerufen am 31. August

94 Oracle (2011a). Oracle Berkeley DB, Java Edition Getting Started with Berkeley DB Java Edition. Oracle, library version Ausgabe. Online, BerkeleyDB-JE-GSG.pdf, abgerufen am 24. Januar Oracle (2011b). Oracle Berkeley DB, Java Edition Getting Started with Transaction Processing. Oracle, library version Ausgabe. Online, BerkeleyDB-JE-Txn.pdf, abgerufen am 24. Januar Oracle (2012). MySQL 5.5 Reference Manual. Including MySQL Cluster NDB 7.2 Reference Guide. Oracle Corporation. en/index.html, abgerufen am 8. Oktober Pointer, R. (2012). Kestrel. bf4ac4da5957d4de4c76be36b6d8634e f/readme.md, abgerufen am 11. Oktober Pointer, R., Kallen, N., Ceaser, E., und Kalucki, J. (2010). Introducing FlockDB. Online. abgerufen am 22. September Prud hommeaux, E. und Seaborne, A. (Hrsg.) (2008). SPARQL Query Language for RDF. The World Wide Web Consortium (W3C). Rodriguez, M. A. (2013). Gremlin. Online, gremlin/wiki/home/59f0f5c0f31d6b168be355d41a74af690a2d2abe, abgerufen am 15. März Rodriguez, M. A. und Neubauer, P. (2010a). Constructions from dots and lines. Bulletin of the American Society for Information Science and Technology, 36(6): Rodriguez, M. A. und Neubauer, P. (2010b). The graph traversal pattern. Preprint, abgerufen am 27. Juni Shen, H. T., Pei, J., Özsu, M. T., Zou, L., Lu, J., Ling, T.-W., Yu, G., Zhuang, Y., und Shao, J. (Hrsg.) (2010). Web-Age Information Management. WAIM 2010 Workshops, Volume 6185 der Lecture Notes In Computer Science. Springer-Verlag. Singh, S. K. (2009). Database Systems: Concepts, Design & Applications. Prentice Hall. Slee, M., Agarwal, A., und Kwiatkowski, M. (2007). Thrift: Scalable cross-language services implementation. Online pdf, abgerufen am 27. September

95 Smith, K. E. und Zdonik, S. B. (1987). Intermedia: A case study of the difference between relational and object-oriented database systems. In Meyrowitz, N. (Hrsg.), OOPSLA 87: Conference proceedings on Object-oriented programming systems, languages and applications. Association for Computing Machinery. Sparsity (2013). DEX User Manual. Sparsity Technologies. Online, abgerufen am 15. März SQL (1999). ANSI/ISO/IEC :1999 Database Language SQL Part 2: Foundation (SQL/Foundation). ANSI/ISO/IEC. Tarjan, R. (1972). Depth-first search and linear graph algorithms. SIAM Journal on Computing, 1(2): Vicknair, C., Macais, M., Zhao, Z., Nan, X., Chen, Y., und Wilkins, D. (2010). A comparison of a graph database and a relational database. In ACM SE 10: Proceedings of the 48th Annual Southeast Regional Conferenc. Association for Computing Machinery. WWW (2008). WWW 08: Proceedings of the 17th international conference on World Wide Web, New York, NY, USA. ACM. 95

96 B. Messergebnisse des Benchmarks Anzahl Kanten Anzahl Knoten ,29 s 2,24 s 16 2,27 s 2,32 s 2,25 s 32 2,27 s 2,31 s 2,32 s 64 2,32 s 2,29 s 2,34 s 2,47 s 128 2,23 s 2,29 s 2,35 s 2,65 s 256 2,39 s 2,39 s 2,40 s 2,60 s 2,92 s 512 2,40 s 2,34 s 2,50 s 2,67 s 3,09 s 3,74 s ,63 s 2,56 s 2,65 s 2,73 s 3,21 s 3,76 s ,86 s 3,15 s 2,96 s 3,11 s 3,64 s 4,00 s ,30 s 3,28 s 3,56 s 3,77 s 3,77 s 4,29 s ,82 s 3,84 s 3,84 s 3,86 s 4,30 s 4,81 s 9,38 s ,43 s 4,16 s 4,50 s 4,49 s 4,64 s 5,25 s 10,12 s ,65 s 4,61 s 4,61 s 4,65 s 5,02 s 5,40 s 10,48 s ,03 s 5,20 s 5,19 s 5,27 s 5,60 s 6,11 s 11,28 s 94,66 s ,13 s 6,31 s 6,32 s 6,30 s 6,66 s 7,24 s 12,60 s ,54 s 8,85 s 8,85 s 8,90 s 8,96 s 9,60 s 15,28 s ,78 s 15,46 s 15,70 s 15,53 s 15,76 s 16,41 s 33,33 s ,75 s 27,17 s 26,68 s 26,67 s 28,28 s 27,78 s 33,85 s 144,80 s Tabelle B.1.: Messergebnisse: Datenimport in Neo4j 96

97 Anzahl Kanten Anzahl Knoten ,38 s 1,53 s 16 1,40 s 1,38 s 1,51 s 32 1,39 s 1,44 s 1,41 s 64 1,39 s 1,38 s 1,48 s 1,54 s 128 1,38 s 1,39 s 1,41 s 1,68 s 256 1,39 s 1,42 s 1,41 s 1,57 s 2,34 s 512 1,39 s 1,42 s 1,46 s 1,68 s 2,41 s 3,94 s ,45 s 1,38 s 1,48 s 1,66 s 2,48 s 3,73 s ,42 s 1,40 s 1,46 s 1,68 s 2,47 s 3,66 s ,41 s 1,43 s 1,50 s 1,72 s 2,51 s 3,87 s ,40 s 1,46 s 1,46 s 1,73 s 2,57 s 3,84 s 15,75 s ,41 s 1,49 s 1,50 s 1,94 s 3,00 s 4,39 s 16,22 s ,38 s 1,42 s 1,56 s 2,00 s 3,10 s 4,50 s 16,99 s ,44 s 1,45 s 1,65 s 2,13 s 3,59 s 4,88 s 17,42 s 187,00 s ,43 s 1,48 s 1,76 s 2,34 s 3,53 s 5,03 s 17,82 s ,40 s 1,52 s 1,90 s 2,63 s 3,94 s 5,44 s 18,59 s ,41 s 1,49 s 2,08 s 3,89 s 6,34 s 7,90 s 149,80 s ,44 s 1,55 s 2,29 s 5,30 s 10,05 s 92,38 s 26,34 s 166,50 s Tabelle B.2.: Messergebnisse: Auslesen aller Kanten aus Neo4j 97

98 Anzahl Kanten Anzahl Knoten ,71 ms 31,63 ms 16 29,59 ms 34,29 ms 44,94 ms 32 36,17 ms 35,66 ms 49,68 ms 64 45,47 ms 46,64 ms 59,71 ms 139,40 ms ,72 ms 66,52 ms 74,92 ms 142,30 ms ,30 ms 110,00 ms 122,70 ms 175,10 ms 318,20 ms ,30 ms 197,00 ms 208,50 ms 238,30 ms 359,40 ms 1,15 s ,00 ms 349,40 ms 350,70 ms 346,10 ms 437,80 ms 1,32 s ,30 ms 619,20 ms 616,70 ms 580,60 ms 587,40 ms 1,54 s ,04 s 1,01 s 995,80 ms 925,50 ms 854,30 ms 2,08 s ,52 s 1,56 s 1,52 s 1,33 s 1,14 s 2,58 s ,55 s 2,54 s 2,47 s 2,09 s 1,50 s 2,94 s ,96 s 2,91 s 2,82 s 2,40 s 1,81 s 3,33 s ,60 s 3,39 s 3,48 s 3,05 s 2,65 s 4,76 s ,23 s 4,67 s 4,51 s 4,30 s 3,71 s 7,30 s ,32 s 7,46 s 6,79 s 5,91 s 5,69 s 10,23 s ,50 s 13,12 s 11,01 s 9,94 s 9,52 s 13,32 s ,14 s 23,34 s 21,65 s 18,23 s 18,16 s 22,45 s Tabelle B.3.: Messergebnisse: Berechnung der starken Zusammenhangskomponenten mit Neo4j 98

99 Anzahl Kanten Anzahl Knoten ,60 ms 389,10 ms ,30 ms 419,80 ms 500,30 ms ,80 ms 460,70 ms 578,10 ms ,10 ms 508,70 ms 667,70 ms 1,08 s ,50 ms 596,30 ms 708,20 ms 1,43 s ,40 ms 739,80 ms 826,10 ms 1,75 s 3,80 s ,20 ms 947,40 ms 1,00 s 2,12 s 6,35 s 46,09 s ,24 s 1,21 s 1,26 s 2,32 s 10,71 s 107,50 s ,25 s 1,26 s 1,29 s 2,00 s 8,88 s 106,30 s ,29 s 1,27 s 1,28 s 1,83 s 6,68 s 86,81 s ,35 s 1,34 s 1,32 s 1,52 s 4,77 s 69,38 s 1.417,00 s ,54 s 1,62 s 1,51 s 1,50 s 3,15 s 48,74 s 1.253,00 s ,83 s 1,75 s 1,76 s 1,71 s 2,81 s 34,50 s 972,40 s ,23 s 2,20 s 2,20 s 2,11 s 2,62 s 17,71 s 656,70 s ,00 s ,95 s 3,11 s 2,85 s 2,80 s 3,57 s 11,00 s 486,10 s ,17 s 4,22 s 4,16 s 4,08 s 3,89 s 7,53 s 245,10 s ,81 s 6,76 s 7,01 s 6,22 s 7,50 s 8,02 s 161,40 s ,38 s 12,15 s 11,87 s 11,05 s 10,21 s 18,30 s 79,05 s 3.841,00 s Tabelle B.4.: Messergebnisse: Abfrage transitiv inzidenter Knoten auf Neo4j 99

100 Anzahl Kanten Anzahl Knoten ,63 s 3,68 s 16 4,22 s 4,26 s 4,25 s 32 4,90 s 4,99 s 5,02 s 64 6,32 s 6,36 s 6,25 s 6,55 s 128 8,65 s 8,55 s 8,46 s 8,71 s ,96 s 12,32 s 12,57 s 12,35 s 13,22 s ,84 s 19,69 s 18,72 s 19,68 s 19,93 s 23,21 s ,70 s 33,04 s 31,83 s 32,86 s 32,26 s 34,70 s ,47 s 32,34 s 32,50 s 32,01 s 33,30 s 32,89 s ,35 s 31,98 s 32,16 s 30,85 s 31,91 s 33,52 s ,50 s 32,68 s 31,93 s 32,44 s 31,86 s 33,58 s 34,13 s ,88 s 34,37 s 33,32 s 33,64 s 31,00 s 32,11 s 32,03 s ,72 s 33,81 s 31,79 s 33,04 s 32,61 s 33,34 s 34,14 s ,53 s 33,01 s 34,65 s 34,68 s 33,43 s 33,11 s 32,38 s 40,86 s ,54 s 36,52 s 35,55 s 35,69 s 36,32 s 32,96 s 34,39 s ,91 s 37,83 s 37,48 s 40,19 s 38,97 s 35,82 s 36,76 s ,06 s 45,97 s 46,31 s 44,31 s 44,80 s 42,98 s 92,88 s ,23 s 62,60 s 65,20 s 64,56 s 62,76 s 62,78 s 58,01 s 61,79 s Tabelle B.5.: Messergebnisse: Abfrage gemeinsamer inzidenter Knoten auf Neo4j 100

101 Anzahl Kanten Anzahl Knoten ,03 s 4,22 s 16 4,68 s 4,92 s 4,97 s 32 6,15 s 5,96 s 6,07 s 64 7,95 s 7,93 s 8,24 s 9,41 s ,36 s 12,13 s 11,87 s 12,43 s ,12 s 19,35 s 19,72 s 19,11 s 23,51 s ,11 s 31,68 s 31,16 s 30,54 s 34,34 s 236,00 s ,08 s 53,95 s 51,51 s 54,44 s 56,24 s 230,30 s ,78 s 55,39 s 56,63 s 53,28 s 55,76 s 113,40 s ,31 s 55,00 s 56,81 s 57,16 s 54,72 s 90,42 s ,81 s 57,73 s 55,75 s 53,14 s 58,76 s 71,59 s 2.112,00 s ,78 s 58,07 s 55,27 s 54,92 s 56,44 s 59,65 s 851,30 s ,15 s 54,89 s 53,01 s 52,07 s 53,14 s 61,59 s 296,20 s ,87 s 60,79 s 56,31 s 53,59 s 54,17 s 53,61 s 109,80 s ,00 s ,73 s 57,75 s 53,89 s 57,20 s 54,26 s 56,11 s 65,04 s ,74 s 60,03 s 60,29 s 62,33 s 61,60 s 62,48 s 70,40 s ,42 s 62,29 s 62,77 s 59,89 s 63,00 s 58,73 s 113,00 s ,35 s 70,23 s 70,58 s 72,85 s 70,78 s 82,16 s 77,38 s 288,10 s Tabelle B.6.: Messergebnisse: Suchen von Dreickspfaden in Neo4j 101

102 Anzahl Kanten Anzahl Knoten ,81 s 2,05 s 16 2,17 s 2,20 s 3,50 s 32 2,63 s 2,36 s 3,55 s 64 2,54 s 2,51 s 3,25 s 11,06 s 128 1,68 s 2,22 s 3,13 s 10,15 s 256 1,90 s 2,31 s 3,20 s 10,22 s 53,74 s 512 2,17 s 2,30 s 3,41 s 9,52 s 54,45 s 271,30 s ,00 s 2,10 s 3,66 s 9,94 s 55,29 s 269,80 s ,33 s 2,30 s 3,25 s 9,10 s 56,78 s 299,00 s ,31 s 2,41 s 3,61 s 10,60 s 56,38 s 274,80 s ,08 s 2,49 s 3,45 s 10,34 s 54,94 s 283,80 s 2.624,00 s ,21 s 2,44 s 3,78 s 9,99 s 56,20 s 272,40 s 2.507,00 s ,48 s 2,27 s 3,81 s 10,02 s 60,03 s 324,10 s ,13 s 2,50 s 3,52 s 9,69 s 55,72 s 309,40 s 2.665,00 s ,00 s ,43 s 2,35 s 3,93 s 10,02 s 51,87 s 333,20 s 2.681,00 s ,47 s 2,68 s 4,08 s 9,98 s 49,62 s 319,10 s 2.811,00 s ,53 s 2,75 s 4,35 s 10,39 s 55,46 s 349,30 s ,83 s 3,26 s 4,58 s 11,18 s 54,86 s 2.931,00 s Tabelle B.7.: Messergebnisse: Datenimport in FlockDB 102

103 Anzahl Kanten Anzahl Knoten ,90 ms 712,10 ms ,10 ms 839,60 ms 881,00 ms 32 1,27 s 1,19 s 1,19 s 64 1,87 s 1,86 s 1,88 s 1,95 s 128 2,90 s 2,88 s 2,92 s 3,19 s 256 5,08 s 5,00 s 5,17 s 4,98 s 5,76 s 512 8,48 s 8,54 s 8,64 s 8,57 s 9,26 s 10,83 s ,42 s 14,68 s 14,43 s 14,25 s 15,41 s 16,54 s ,57 s 26,21 s 26,54 s 26,87 s 28,09 s 32,66 s ,13 s 44,74 s 47,01 s 48,40 s 47,53 s 54,35 s ,64 s 76,67 s 73,80 s 74,81 s 78,00 s 83,96 s 119,00 s ,90 s 128,80 s 131,30 s 131,10 s 133,10 s 141,30 s 177,30 s ,70 s 239,50 s 245,50 s 243,50 s 247,80 s 259,10 s ,20 s 466,90 s 486,70 s 474,00 s 473,70 s 489,90 s 537,20 s 873,10 s ,90 s 908,40 s 903,30 s 919,00 s 920,90 s 969,90 s 1.011,00 s ,00 s 1.847,00 s 1.832,00 s 1.837,00 s 1.883,00 s 1.926,00 s 1.959,00 s ,00 s 3.676,00 s 3.766,00 s 3.664,00 s 3.789,00 s 3.823,00 s ,00 s 7.265,00 s 7.339,00 s 7.278,00 s 7.508,00 s Tabelle B.8.: Messergebnisse: Auslesen aller Kanten aus FlockDB 103

104 Anzahl Kanten Anzahl Knoten ,37 ms 96,24 ms ,80 ms 153,70 ms 174,30 ms ,50 ms 325,60 ms 292,90 ms ,20 ms 504,20 ms 513,10 ms 626,10 ms ,60 ms 884,00 ms 917,90 ms 983,30 ms 256 1,54 s 1,54 s 1,52 s 1,64 s 1,81 s 512 2,68 s 2,71 s 2,67 s 2,83 s 2,96 s 3,66 s ,54 s 4,58 s 4,58 s 4,59 s 4,83 s 6,75 s ,73 s 11,99 s 11,79 s 12,13 s 12,76 s 15,16 s ,80 s 14,92 s 15,14 s 15,29 s 15,97 s 19,70 s ,73 s 29,49 s 29,73 s 30,98 s 30,12 s 35,35 s ,03 s 57,94 s 57,84 s 58,14 s 58,37 s 60,34 s ,30 s 114,10 s 114,60 s 115,50 s 115,50 s 123,70 s ,50 s 233,60 s 232,50 s 233,30 s 232,70 s 244,40 s ,50 s 470,80 s 473,20 s 472,80 s 477,40 s 485,70 s ,50 s 956,60 s 964,10 s 957,60 s 952,60 s 989,70 s ,00 s 1.921,00 s 1.945,00 s 1.942,00 s 1.961,00 s 1.962,00 s ,00 s 3.845,00 s 3.859,00 s 3.855,00 s 3.887,00 s Tabelle B.9.: Messergebnisse: Berechnung der starken Zusammenhangskomponenten mit FlockDB 104

105 Anzahl Kanten Anzahl Knoten ,08 ms 221,30 ms ,80 ms 243,80 ms 1,23 s ,40 ms 355,40 ms 1,64 s ,50 ms 548,00 ms 2,05 s 6,15 s ,50 ms 946,60 ms 2,04 s 256 1,51 s 1,56 s 2,46 s 512 2,63 s 2,65 s ,40 s 4,44 s 4,81 s ,51 s 6,42 s 7,12 s ,23 s 4,23 s 4,36 s 7,97 s ,35 s 4,38 s 4,58 s 6,55 s ,54 s 4,64 s 4,69 s 5,68 s ,92 s 4,99 s 4,95 s 5,35 s ,57 s 5,61 s 5,52 s 5,80 s ,83 s 6,89 s 6,75 s 8,18 s ,86 s 8,45 s 8,46 s 8,53 s 9,82 s ,75 s 11,96 s 11,66 s 11,91 s 12,35 s ,90 s 21,69 s 22,17 s 22,00 s 21,85 s Tabelle B.10.: Messergebnisse: Abfrage transitiv inzidenter Knoten auf FlockDB 105

106 Anzahl Kanten Anzahl Knoten ,40 ms 143,60 ms ,90 ms 239,00 ms 257,50 ms ,90 ms 504,80 ms 534,20 ms ,00 ms 765,70 ms 751,80 ms 818,60 ms 128 1,26 s 1,27 s 1,21 s 1,35 s 256 2,14 s 2,14 s 2,06 s 2,19 s 2,64 s 512 3,75 s 3,73 s 3,61 s 4,18 s 5,16 s ,66 s 5,63 s 5,50 s 5,74 s 6,91 s 10,31 s ,64 s 10,51 s 10,14 s 9,75 s 11,08 s Tabelle B.11.: Messergebnisse: Abfrage gemeinsamer inzidenter Knoten auf FlockDB 106

107 Anzahl Kanten Anzahl Knoten ,18 ms 91,06 ms 16 85,50 ms 87,10 ms 240,40 ms ,20 ms 198,10 ms 294,10 ms ,10 ms 304,00 ms 390,80 ms 2,39 s ,90 ms 570,30 ms 653,60 ms 2,15 s 256 1,00 s 967,10 ms 1,05 s 2,04 s 32,23 s 512 1,68 s 1,60 s 1,75 s 2,60 s 27,55 s 483,10 s ,79 s 2,72 s 3,06 s 3,37 s 24,76 s 529,50 s ,23 s 4,14 s 4,14 s 4,59 s 13,75 s 200,30 s ,70 s 1,78 s 1,84 s ,80 s 1,87 s 1,79 s ,04 s 2,09 s 1,99 s 2,13 s ,25 s 2,32 s 2,31 s 2,30 s ,75 s 2,82 s 2,65 s 3,34 s ,08 s 4,33 s 4,03 s 3,97 s ,84 s 5,67 s 5,54 s 5,60 s 5,85 s ,82 s 9,33 s 8,86 s 9,14 s 9,12 s ,95 s 17,83 s 18,14 s 17,82 s 18,76 s Tabelle B.12.: Messergebnisse: Suchen von Dreickspfaden in FlockDB 107

108 Anzahl Kanten Anzahl Knoten ,35 s 2,42 s 16 2,36 s 2,32 s 2,71 s 32 2,46 s 2,58 s 2,88 s 64 2,44 s 2,68 s 2,95 s 4,68 s 128 2,80 s 2,87 s 3,01 s 4,73 s 256 3,05 s 3,05 s 3,45 s 4,85 s 9,11 s 512 3,57 s 3,70 s 3,84 s 5,28 s 9,03 s 25,09 s ,38 s 4,40 s 4,69 s 5,76 s 9,12 s 25,66 s ,41 s 5,32 s 5,61 s 6,00 s 9,42 s 25,15 s ,52 s 6,52 s 6,72 s 7,16 s 10,21 s 25,27 s ,79 s 7,68 s 7,90 s 8,03 s 10,54 s 27,63 s 633,30 s ,29 s 10,52 s 9,52 s 9,67 s 12,04 s 28,44 s 608,90 s ,49 s 12,43 s 12,26 s 13,07 s 14,98 s 30,55 s 636,40 s ,88 s 16,79 s 16,90 s 17,37 s 19,41 s 35,08 s 1.765,00 s 7.810,00 s ,98 s 26,46 s 26,44 s 26,52 s 28,51 s 45,61 s 688,90 s ,62 s 46,72 s 47,92 s 47,73 s 51,80 s 86,49 s 804,10 s ,20 s 151,10 s 155,40 s 148,80 s 167,90 s 236,30 s 993,70 s ,70 s 477,80 s 482,90 s 480,80 s 498,80 s 554,10 s 1.341,00 s 8.398,00 s Tabelle B.13.: Messergebnisse: Datenimport in HyperGraphDB 108

109 Anzahl Kanten Anzahl Knoten ,90 s 1,77 s 16 1,90 s 1,82 s 1,95 s 32 1,76 s 1,81 s 1,99 s 64 1,78 s 1,82 s 2,05 s 2,79 s 128 1,80 s 1,81 s 2,00 s 2,91 s 256 1,80 s 1,85 s 2,12 s 2,90 s 5,38 s 512 1,89 s 1,91 s 2,24 s 3,15 s 5,46 s 26,45 s ,05 s 2,13 s 2,21 s 3,26 s 5,74 s 26,52 s ,03 s 2,05 s 2,34 s 3,25 s 5,78 s 27,45 s ,09 s 2,11 s 2,31 s 3,47 s 5,76 s 28,02 s ,26 s 2,17 s 2,46 s 3,77 s 6,05 s 26,91 s 335,20 s ,31 s 2,47 s 2,76 s 4,00 s 6,43 s 27,63 s 352,00 s ,68 s 2,60 s 2,90 s 4,22 s 6,54 s 27,81 s 330,30 s ,05 s 3,09 s 3,43 s 4,83 s 7,18 s 26,10 s ,76 s 2,98 s 4,08 s 9,27 s 15,90 s 32,27 s 362,00 s ,73 s 3,84 s 7,58 s 15,16 s 17,20 s 44,75 s 399,50 s ,02 s 6,61 s 11,70 s 27,60 s 43,63 s 88,74 s 493,80 s ,27 s 7,60 s 14,42 s 42,22 s 93,68 s 273,40 s 611,00 s Tabelle B.14.: Messergebnisse: Auslesen aller Kanten aus HyperGraphDB 109

110 Anzahl Kanten Anzahl Knoten ,29 ms 26,05 ms 16 45,24 ms 38,69 ms 70,28 ms 32 77,37 ms 72,51 ms 94,62 ms ,10 ms 139,90 ms 145,00 ms 279,50 ms ,00 ms 252,40 ms 265,60 ms 337,10 ms ,10 ms 483,50 ms 458,60 ms 464,60 ms 774,50 ms ,10 ms 878,20 ms 830,70 ms 759,10 ms 789,00 ms 2,84 s ,60 s 1,58 s 1,53 s 1,22 s 1,08 s 2,90 s ,75 s 2,78 s 2,63 s 2,10 s 1,51 s 3,60 s ,25 s 4,14 s 4,00 s 3,43 s 2,36 s 5,03 s ,78 s 5,78 s 5,66 s 4,39 s 3,38 s 7,75 s ,11 s 7,33 s 6,56 s 5,66 s 4,62 s 12,67 s ,29 s 8,44 s 8,52 s 7,42 s 6,08 s 21,37 s ,43 s 11,29 s 11,39 s 9,85 s 8,80 s 29,88 s ,40 s 37,49 s 33,73 s 29,74 s 22,09 s 50,95 s ,23 s 44,77 s 39,33 s 34,31 s 29,29 s 103,70 s ,90 s 145,20 s 133,50 s 115,60 s 119,50 s 217,40 s ,90 s 370,20 s 373,00 s 365,50 s 322,30 s 438,60 s Tabelle B.15.: Messergebnisse: Berechnung der starken Zusammenhangskomponenten mit HyperGraphDB 110

111 Anzahl Kanten Anzahl Knoten ,64 ms 48,05 ms 16 54,09 ms 65,65 ms 224,90 ms 32 80,69 ms 94,52 ms 299,70 ms ,90 ms 147,90 ms 380,00 ms 1,21 s ,10 ms 260,70 ms 444,00 ms 1,77 s ,10 ms 464,20 ms 576,40 ms 2,10 s 19,66 s ,90 ms 810,30 ms 869,70 ms 2,26 s 32,39 s 443,00 s ,32 s 1,40 s 1,36 s 2,64 s 44,05 s 865,00 s ,36 s 1,34 s 1,34 s 1,94 s 27,57 s 755,70 s ,43 s 1,38 s 1,35 s 1,56 s 14,74 s 566,50 s ,49 s 1,48 s 1,40 s 1,33 s 8,24 s 365,10 s ,62 s 1,60 s 1,54 s 1,28 s 4,15 s 189,40 s 7.432,00 s ,89 s 1,93 s 1,90 s 1,67 s 2,84 s 108,90 s 5.297,00 s ,36 s 2,42 s 2,32 s 1,80 s 2,27 s 45,11 s ,72 s 5,26 s 5,58 s 4,50 s 3,44 s 21,42 s ,73 s 4,34 s 4,52 s 5,30 s 4,32 s 16,97 s ,31 s 14,06 s 13,57 s 7,41 s 5,07 s 14,25 s 725,60 s ,17 s 24,62 s 24,59 s 18,75 s 12,87 s 18,84 s 401,00 s Tabelle B.16.: Messergebnisse: Abfrage transitiv inzidenter Knoten auf HyperGraphDB 111

112 Anzahl Kanten Anzahl Knoten ,81 ms 143,60 ms ,00 ms 261,90 ms 1,01 s ,60 ms 357,20 ms 1,25 s ,20 ms 578,20 ms 1,50 s 2,48 s ,00 ms 918,70 ms 1,77 s 3,51 s 256 1,51 s 1,53 s 2,18 s 4,78 s 42,28 s 512 2,13 s 2,47 s 2,82 s 6,36 s 84,38 s 1.059,00 s ,18 s 3,62 s 3,76 s 8,00 s 134,40 s 1.943,00 s ,36 s 3,59 s 3,68 s 6,79 s 101,90 s 1.865,00 s ,74 s 3,79 s 3,79 s 5,51 s 71,90 s 1.701,00 s ,92 s 3,80 s 3,76 s 4,57 s 50,00 s 1.254,00 s ,21 s 4,32 s 4,04 s 4,40 s 32,65 s 930,80 s ,00 s ,56 s 4,58 s 4,48 s 4,45 s 25,09 s 756,20 s ,42 s 5,52 s 5,11 s 5,09 s 18,00 s 539,40 s ,72 s 10,47 s 10,27 s 8,80 s 15,55 s 367,10 s ,21 s 10,15 s 9,80 s 9,39 s 14,72 s 275,60 s ,88 s 23,54 s 22,76 s 19,58 s 28,50 s 495,40 s ,00 s ,41 s 46,87 s 43,97 s 38,91 s 37,89 s 338,30 s ,00 s Tabelle B.17.: Messergebnisse: Abfrage gemeinsamer inzidenter Knoten auf HyperGraphDB 112

113 Anzahl Kanten Anzahl Knoten ,33 ms 103,40 ms 16 84,83 ms 94,08 ms 683,90 ms ,40 ms 194,60 ms 607,80 ms ,40 ms 242,30 ms 671,30 ms 3,70 s ,70 ms 527,10 ms 810,90 ms 2,92 s ,70 ms 750,30 ms 1,23 s 2,49 s 445,70 s 512 1,34 s 1,29 s 1,61 s 2,91 s 246,10 s ,16 s 2,48 s 2,44 s 3,23 s 177,10 s ,27 s 2,18 s 2,47 s 2,80 s 49,40 s ,00 s ,30 s 2,26 s 2,50 s 2,57 s 24,00 s ,36 s 2,66 s 2,53 s 2,38 s 14,61 s 5.170,00 s ,46 s 2,66 s 2,73 s 2,44 s 6,20 s 1.540,00 s ,82 s 2,61 s 2,89 s 2,56 s 4,48 s 386,60 s ,40 s 3,55 s 3,27 s 2,91 s 3,81 s 76,96 s ,66 s 6,25 s 6,27 s 5,34 s 5,15 s 39,70 s ,49 s 6,33 s 5,39 s 6,06 s 5,26 s 32,26 s ,67 s 13,80 s 12,71 s 10,56 s 8,70 s 44,86 s 6.150,00 s ,72 s 25,38 s 25,44 s 20,85 s 17,52 s 43,30 s 1.699,00 s Tabelle B.18.: Messergebnisse: Suchen von Dreickspfaden in HyperGraphDB 113

114 Anzahl Kanten Anzahl Knoten ,90 ms 729,10 ms ,30 ms 732,70 ms 607,10 ms ,60 ms 733,10 ms 672,60 ms ,80 ms 757,60 ms 725,70 ms 618,60 ms ,70 ms 754,80 ms 627,40 ms 840,60 ms ,60 ms 734,10 ms 733,10 ms 751,70 ms 1,02 s ,70 ms 653,40 ms 753,20 ms 733,90 ms 986,50 ms 2,73 s ,80 ms 1,17 s 621,90 ms 616,90 ms 1,36 s 2,56 s ,70 ms 741,60 ms 737,70 ms 947,10 ms 1,14 s 2,75 s ,20 ms 941,40 ms 933,10 ms 926,00 ms 1,15 s 2,94 s ,70 ms 817,60 ms 860,50 ms 820,90 ms 1,12 s 2,94 s 33,41 s ,50 ms 1,08 s 1,16 s 1,11 s 1,17 s 3,33 s 29,23 s ,50 ms 1,01 s 1,03 s 1,23 s 1,54 s 3,54 s 31,63 s ,53 s 1,41 s 1,42 s 1,41 s 1,54 s 4,01 s 32,17 s 395,10 s ,16 s 2,25 s 2,23 s 1,94 s 2,41 s 4,73 s 32,97 s ,61 s 3,13 s 3,34 s 3,54 s 3,54 s 7,33 s 39,04 s ,76 s 6,14 s 5,75 s 5,94 s 5,93 s 8,54 s 43,88 s ,94 s 11,95 s 10,95 s 10,95 s 11,35 s 14,15 s 46,65 s 443,20 s Tabelle B.19.: Messergebnisse: Datenimport in DEX 114

115 Anzahl Kanten Anzahl Knoten ,50 ms 523,60 ms ,00 ms 526,30 ms 513,80 ms ,30 ms 522,60 ms 522,70 ms ,10 ms 499,10 ms 526,10 ms 530,20 ms ,70 ms 517,60 ms 529,70 ms 529,00 ms ,00 ms 517,60 ms 526,50 ms 523,40 ms 1,12 s ,20 ms 523,00 ms 527,70 ms 509,70 ms 1,15 s 3,14 s ,70 ms 543,70 ms 555,40 ms 539,50 ms 1,14 s 3,13 s ,80 ms 531,20 ms 517,70 ms 526,00 ms 1,10 s 3,15 s ,70 ms 528,80 ms 518,70 ms 522,80 ms 1,14 s 3,15 s ,50 ms 515,50 ms 509,20 ms 511,20 ms 1,13 s 3,12 s 96,73 s ,20 ms 528,80 ms 516,30 ms 723,50 ms 1,13 s 3,11 s 27,74 s ,70 ms 532,40 ms 550,70 ms 762,10 ms 1,12 s 3,48 s 28,13 s ,10 ms 521,40 ms 714,00 ms 735,90 ms 1,34 s 3,54 s 28,13 s 285,40 s ,70 ms 510,90 ms 715,00 ms 916,00 ms 1,32 s 3,73 s 29,14 s ,50 ms 752,70 ms 724,60 ms 925,00 ms 1,91 s 4,12 s 28,72 s ,30 ms 716,00 ms 913,00 ms 1,72 s 2,93 s 6,13 s 219,50 s ,20 ms 704,80 ms 1,10 s 2,32 s 5,32 s 9,92 s 37,14 s 325,90 s Tabelle B.20.: Messergebnisse: Auslesen aller Kanten aus DEX 115

116 Anzahl Kanten Anzahl Knoten ,38 ms 30,82 ms 16 28,93 ms 19,96 ms 15,90 ms 32 32,12 ms 44,03 ms 69,14 ms 64 35,52 ms 40,43 ms 49,24 ms 49,44 ms ,36 ms 37,34 ms 30,47 ms 34,20 ms ,39 ms 64,19 ms 58,89 ms 54,28 ms 92,62 ms ,45 ms 99,50 ms 103,10 ms 105,80 ms 137,30 ms 664,80 ms ,30 ms 157,30 ms 156,50 ms 177,90 ms 171,80 ms 693,10 ms ,20 ms 286,60 ms 282,40 ms 290,30 ms 264,90 ms 816,40 ms ,80 ms 539,00 ms 574,20 ms 549,40 ms 472,40 ms 993,00 ms ,80 ms 890,90 ms 883,30 ms 867,40 ms 870,90 ms 1,45 s ,41 s 1,44 s 1,40 s 1,42 s 1,38 s 2,05 s ,31 s 2,37 s 2,37 s 2,40 s 2,35 s 2,99 s ,26 s 4,36 s 4,40 s 4,41 s 4,36 s 5,08 s 15,26 s ,89 s 8,83 s 8,94 s 8,94 s 8,94 s 9,61 s ,95 s 20,42 s 20,27 s 20,36 s 20,51 s 21,44 s ,54 s 49,36 s 49,15 s 49,73 s 49,94 s 50,19 s ,30 s 138,20 s 138,40 s 138,20 s 137,50 s 136,40 s 150,60 s 288,30 s Tabelle B.21.: Messergebnisse: Berechnung der starken Zusammenhangskomponenten mit DEX 116

117 Anzahl Kanten Anzahl Knoten ,73 ms 28,13 ms 16 21,08 ms 12,29 ms 47,02 ms 32 21,98 ms 21,25 ms 73,18 ms 64 23,42 ms 24,19 ms 93,22 ms 359,10 ms ,63 ms 17,47 ms 99,97 ms 656,00 ms ,02 ms 34,19 ms 77,36 ms 892,80 ms 3,28 s ,98 ms 37,42 ms 84,13 ms 1,10 s 7,41 s 30,73 s ,34 ms 70,17 ms 86,13 ms 1,16 s 14,77 s 75,94 s ,26 ms 68,09 ms 82,00 ms 716,20 ms 12,65 s 91,77 s ,21 ms 87,51 ms 91,84 ms 455,40 ms 7,86 s 95,66 s ,30 ms 109,20 ms 100,70 ms 247,50 ms 4,88 s 83,96 s 718,50 s ,30 ms 166,80 ms 140,00 ms 199,90 ms 2,25 s 65,35 s 830,40 s ,40 ms 253,40 ms 238,80 ms 267,80 ms 1,27 s 52,77 s 755,00 s ,70 ms 713,40 ms 688,60 ms 620,60 ms 998,00 ms 27,56 s 610,70 s 7.164,00 s ,43 s 1,34 s 1,29 s 1,17 s 1,24 s 14,38 s 496,30 s ,52 s 2,74 s 2,31 s 3,08 s 2,92 s 8,28 s 322,50 s ,32 s 5,33 s 5,18 s 5,09 s 5,04 s 7,78 s 388,30 s ,79 s 12,51 s 9,40 s 9,50 s 9,43 s 10,74 s 123,10 s 3.466,00 s Tabelle B.22.: Messergebnisse: Abfrage transitiv inzidenter Knoten auf DEX 117

118 Anzahl Kanten Anzahl Knoten ,35 ms 6,51 ms 16 6,88 ms 7,38 ms 10,60 ms 32 7,73 ms 8,87 ms 9,45 ms 64 9,92 ms 9,88 ms 10,75 ms 25,62 ms ,76 ms 15,09 ms 15,01 ms 25,86 ms ,28 ms 22,36 ms 23,23 ms 30,74 ms 130,70 ms ,53 ms 37,94 ms 38,68 ms 51,96 ms 93,95 ms 717,80 ms ,23 ms 69,70 ms 68,63 ms 71,68 ms 81,73 ms 532,10 ms ,49 ms 78,52 ms 77,69 ms 80,81 ms 75,56 ms 290,30 ms ,13 ms 93,84 ms 113,90 ms 118,70 ms 93,67 ms 177,90 ms ,90 ms 127,20 ms 121,20 ms 127,80 ms 129,60 ms 251,00 ms 1,15 s ,70 ms 219,50 ms 212,00 ms 209,50 ms 227,60 ms 275,20 ms 1,14 s ,20 ms 536,20 ms 497,20 ms 481,00 ms 478,30 ms 549,20 ms 1,52 s ,27 s 1,15 s 1,12 s 1,16 s 1,16 s 1,27 s 2,33 s 6,10 s ,23 s 2,19 s 2,35 s 2,09 s 2,05 s 2,41 s 3,60 s ,26 s 4,38 s 5,38 s 4,11 s 4,22 s 4,93 s 6,13 s ,67 s 9,69 s 10,53 s 8,97 s 8,74 s 9,35 s 117,20 s ,86 s 18,32 s 18,49 s 18,23 s 17,78 s 17,97 s 23,12 s 26,57 s Tabelle B.23.: Messergebnisse: Abfrage gemeinsamer inzidenter Knoten auf DEX 118

119 Anzahl Kanten Anzahl Knoten ,01 ms 8,39 ms 16 6,23 ms 6,26 ms 13,72 ms 32 6,79 ms 8,01 ms 16,82 ms 64 7,80 ms 7,82 ms 17,19 ms 31,74 ms ,10 ms 11,44 ms 12,15 ms 27,26 ms ,58 ms 14,40 ms 26,07 ms 27,64 ms 358,50 ms ,94 ms 23,10 ms 31,18 ms 45,98 ms 228,80 ms 6,84 s ,58 ms 47,33 ms 41,63 ms 63,38 ms 186,80 ms 4,92 s ,84 ms 43,20 ms 44,30 ms 48,20 ms 94,20 ms 2,04 s ,85 ms 51,70 ms 53,04 ms 61,99 ms 74,69 ms 1,19 s ,77 ms 75,77 ms 73,18 ms 80,26 ms 101,70 ms 737,60 ms 45,98 s ,10 ms 112,10 ms 104,00 ms 103,10 ms 111,70 ms 448,90 ms 14,55 s ,10 ms 230,10 ms 202,50 ms 204,10 ms 207,30 ms 503,70 ms 8,43 s ,20 ms 575,50 ms 590,30 ms 527,00 ms 547,40 ms 868,10 ms 6,73 s 1.622,00 s ,25 s 1,22 s 1,21 s 1,12 s 1,11 s 1,86 s 6,67 s ,53 s 2,35 s 2,24 s 2,64 s 2,50 s 3,00 s 8,20 s ,51 s 5,11 s 5,08 s 5,68 s 4,84 s 5,23 s 134,60 s ,60 s 9,52 s 9,46 s 9,42 s 9,21 s 9,36 s 15,44 s 93,01 s Tabelle B.24.: Messergebnisse: Suchen von Dreickspfaden in DEX 119

120 C. Selbstständigkeitserklärung Ich erkläre hiermit, dass ich die vorliegende Arbeit selbständig verfasst und nur unter Verwendung der angegebenen Quellen und Hilfsmittel angefertigt habe. Weiterhin erkläre ich, eine Diplomarbeit in diesem Studiengebiet erstmalig einzureichen. Berlin, den 27. März 2013 Benjamin Gehrels 120