Benchmarking von Graphdatenbanken

Fakultät Informatik Institut für Systemarchitektur
Benchmarking von Graphdatenbanken
Matthias Jordan
Matrikelnummer: 3664069
Großer Beleg
Betreuer
Benjamin Schiller
Hannes Voigt
Selbstständigkeitserklärung
Ich erkläre hiermit, dass ich die vorliegende Arbeit selbstständig und ohne Benutzung anderer
als der angegebenen Hilfsmittel angefertigt habe. Die aus fremden Quellen wörtlich oder sinngemäß übernommenen Gedanken sind als solche kenntlich gemacht. Ich erkläre ferner, dass
ich die vorliegende Arbeit an keiner anderen Stelle als Prüfungsarbeit eingereicht habe oder
einreichen werde.
Ort, Datum
Matthias Jordan
Zusammenfassung
Facebook, Instagram, Twitter und YouTube sind prominente Beispiele für Plattformen, welche
Menschen miteinander vernetzen und deren Anzahl an Benutzern stetig wächst. Daraus ergibt
sich die Notwendigkeit in Verbindung stehende Daten effizient speichern und verarbeiten zu
können.
Für das Abbilden und Speichern von Netzwerken in einem Computersystem eigenen sich
Graphdatenbanken (GDBs). Die Verknüpfung der Informationen entspricht dabei dem Property-Graph-Modell, wobei Graphen in ihrem Aufbau den Netzwerken gleichkommen und aus
Kanten und Knoten bestehen. Im Vergleich dazu gibt es relationale Datenbanken, die in der
Praxis weitverbreitet sind und ebenfalls auf mehrstelligen Relationen beruhen. Das Abbilden
von Netzwerken ist grundsätzlich in relationalen Datenbanken möglich, jedoch stoßen diese
Datenbanken bei der Traversierung von Netzwerken an die Grenzen des Datenmodells. Aus
diesem Grund ist es erforderlich sich mit GDBs weiter auseinanderzusetzen. Um verschiedene Datenbanken bezüglich ihrer Leistung voneinander abgrenzen zu können, bedarf es der
Definition von Benchmarks.
Dynamic Network Analyzer (DNA) ist ein Framework zur Analyse von statischen und dynamischen Systemen. Im Mittelpunkt der Arbeit steht die Integration von GDBs in DNA. In
der ersten Ausbaustufe finden Datenbanken Berücksichtigung, die das Tinkerpop Blueprints
Interface implementieren. Dadurch können gleiche Zugriffszeiten aus DNA heraus auf die verschiedenen Datenbanken und somit die Vergleichbarkeit von Messergebnissen gewährleistet
werden. Die Messwerterfassung erfolgt für die GDBs Bitsy, Neo4J, OrientDB und TinkerGraph. Mit dieser wird die Durchführbarkeit eines Benchmarks unter Nutzung der vorliegenden Implementierung aufgezeigt. Ein möglicher Benchmark mit Tiefensuche, Breitensuche,
lokalem Clustering-Koeffizienten, Knoten- und Kanteniteration wird vorgestellt und die erfassten Messwerte für verschiedene Graphtopologien werden bezüglich ihrer Laufzeit verglichen.
Mit der Arbeit wurde die Grundlage geschaffen GDBs mithilfe des DNA Frameworks bezüglich ihrer Leistung zu vergleichen. Dafür kann auf die vorhandenen Graphgeneratoren zugegriffen werden, die die GDBs befüllen, auf denen anschließend selbst definierte Benchmarks
ausgeführt werden können. Für Benchmarks, unter Berücksichtigung des eigenen Datenbestandes, bedarf es jedoch der Erweiterung des bestehenden Quellcodes.
Inhaltsverzeichnis
Zusammenfassung
Abkürzungsverzeichnis
III
1 Einleitung
1
2 Benchmarking von Graphdatenbanken
3
2.1 Graph . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3
2.2 Graphdatenbank . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
4
2.3 Benchmarks und deren Relevanz . . . . . . . . . . . . . . . . . . . . . . . . . . .
4
2.4 Existierende Benchmarks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
6
3 Implementierung
9
3.1 Frameworks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
9
3.1.1 DNA - Dynamic Network Analyzer . . . . . . . . . . . . . . . . . . . . . . .
9
3.1.2 Tinkerpop Blueprints . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
3.2 Verwendete Graphdatenbanken . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
3.3 Graphdatenbanken in DNA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
3.4 Anwendung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
4 Messwerterfassung
14
4.1 Setup . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
4.2 Ergebnisse und Auswertung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
4.2.1 Graphgenerierung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
4.2.2 BFS und DFS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
4.2.3 Knoteniteration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
4.2.4 Kanteniteration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
4.2.5 Lokaler Clustering-Koeffizient . . . . . . . . . . . . . . . . . . . . . . . . . . 20
4.2.6 Resultate . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
5 Ausblick
22
Anhangsverzeichnis
23
Anhang
24
Abbildungsverzeichnis
29
I
Tabellenverzeichnis
30
Quellenverzeichnis
31
II
Abkürzungsverzeichnis
BFS Breadth-First-Search\Breitensuche
CPU Central Processing Unit\Zentrale Prozessoreinheit
DFS Depth-First-Search\Tiefensuche
DNA Dynamic Network Analyzer
GDB Graphdatenbank
HPC High-Performance-Computing\Hochleistungsrechnen
LDBC Linked Data Benchmark Council
MVCC Multiversion Concurrency Control
RDB Relationale Datenbank
SNB Social Network Benchmark
SPB Semantic Publishing Benchmark
SQL Structured Query Language
SSD Solid State Disk\Solid State Drive
TPC Transaction Processing Performance Council
VM Virtuelle Maschine
III
1 Einleitung
Es gibt mehr als 100 verschiedene Soziale Netzwerke auf der Welt, zu den bekanntesten zählen
sicherlich Facebook, Instagram, Twitter oder YouTube. Knapp ein Siebtel der Weltbevölkerung nutzte im August 2015 Facebook [vgl. 10, 18], damit zählt die Plattform zu einem der
meist genutzten Sozialen Netzwerke weltweit. Mit der steigenden Anzahl an Benutzern wächst
die Notwendigkeit, die produzierten Daten effizient speichern und verarbeiten zu können.
Für das Abbilden und Speichern von Nutzerbeziehungen in einem Computersystem eignen
sich Graphdatenbanken (GDBs), diese vernetzen Informationen über Knoten und Kanten.
Dabei können die Nutzer als Knoten und ihre Beziehungen untereinander als Kanten modelliert werden, wie in der Abbildung 1.1 vereinfacht dargestellt.
Abbildung 1.1: Vernetzung der Facebook-Nutzer weltweit
Quelle: www.facebook.com [11]
Nicht alle GDBs eignen sich für den eigenen Anwendungsfall. Sie können sich beispielsweise
hinsichtlich der Performanz beim Hinzufügen von Knoten und Kanten oder der Traversierung
durch den Graphen unterscheiden. Benchmarks dienen als Grundlage für den Vergleich von
ähnlichen Systemen. Mit Hilfe der in einem Benchmark erfassten Messwerte kann man für
eine Problemstellung die bestmögliche GDB finden.
Im Speziellen befasst sich die Arbeit mit der Integration von GDBs in das bestehende
Framework Dynamic Network Analyzer (DNA), welches zur Untersuchung von dynamischen
Systemen eingesetzt wird. Das Ziel ist es dabei eine Möglichkeit zu schaffen, die verschiedenen Implementierungen von Datenbanken hinsichtlich deren Speicherverbrauch, Zugriffs- und
1
Laufzeiten von Metriken miteinander zu vergleichen.
Die Arbeit gliedert sich im Folgenden in vier Kapitel. Die theoretischen Grundlagen werden in Kapitel 2 erläutert. Sie beinhalten Definitionen, die im Zusammenhang mit GDBs
stehen und heben darüber hinaus die Relevanz von Benchmarks für GDBs hervor. Im daran
anschließenden Kapitel 3 werden die Implementierungsdetails, um GDBs in DNA nutzen zu
können, besprochen. Mit Kapitel 4 werden im Anschluss die erfassten Messwerte präsentiert
und ausgewertet. Die Ergebnisse des durchgeführten Benchmarks werden dabei grafisch dargestellt und näher beleuchtet. Im abschließenden Kapitel 5 wird ein Ausblick auf mögliche
Erweiterungen zur derzeitigen Implementierung gegeben und ein Fazit gezogen.
2
2 Benchmarking von Graphdatenbanken
Relationale Datenbanken (RDBs) zählen in der Praxis wohl zu den am weitverbreitetsten
und bekanntesten Systemen. Seit 2000 wird in der Firma NeoTechnology die Entwicklung von
GDBs vorangetrieben (Abbildung 2.1), da die RDBs bei der Traversierung von Graphen an
die Grenzen des Datenmodells stoßen.
Abbildung 2.1: Entwicklung von Neo4J bei NeoTechnology
Quelle: www.neo4j.com [14]
Das folgende Kapitel befasst sich mit den Grundlagen: GDBs und Benchmark. Das Kapitel
2.1 widmet sich dem Begriff des Graphen und dessen mathematischer Definition. Dieser bildet
die Basis für GDBs. In Kapitel 2.2 werden GDBs den RDBs gegenübergestellt und gegeneinander abgegrenzt. Die Entwicklung von GDBs schreitet zunehmend voran, um diese bezüglich
ihrer Leistung voneinander abzugrenzen werden Benchmarks definiert. In Kapitel 2.3 wird auf
die Relevanz von Benchmarks in der Praxis eingegangen und im daran anschließenden Kapitel
2.4 werden bereits existierende Benchmarks für GDBs vorgestellt.
2.1 Graph
Es seien V eine Menge an Knoten und E eine Menge von Kanten. Ein geordnetes Paar (V, E),
bezeichnet man dann als Graphen G. Die Knoten sind dabei immer paarweise über eine
Kante miteinander verbunden. Die Kanten eines Graphen können gerichtet oder ungerichtet
sein. Man spricht von einem gerichteten Graphen, wenn die Kanten des Graphen geordnete
Paare der Form (v, w) ∈ E wobei v, w ∈ V sind. Eine grafische Darstellung eines gerichteten
Graphen zeigt die Abbildung 2.2. Die Kanten eines ungerichteten Graphen sind hingegen
ungeordnete Paare der Form {v, w} ∈ E wobei v, w ∈ V .
3
Abbildung 2.2: Beispiel für einen einfachen gerichteten Graphen
2.2 Graphdatenbank
Bei Mehrstelligen Relationen handelt es sich um eine Menge von Tupeln mit gleicher Länge,
wobei die Länge n ≥ 2 ist. Sie bilden die Grundlage für das relationale Modell und die Abfragesprache SQL [vgl. 8]. RDBs speichern Informationen in Tabellen und realisieren Beziehungen
zwischen diesen über Schlüsselpaare, in Abbildung 2.3 wird dies vereinfacht dargestellt.
Abbildung 2.3: Beispiel einer Relation
GDBs beruhen ebenfalls auf mehrstelligen Relationen, speichern aber im Gegensatz zu den
RDBs die Beziehungen explizit. Die meisten nutzen dabei das Property-Graph-Modell. Im
Vergleich zu einem einfachen Graphen, wie in Abbildung 2.2 dargestellt, können Knoten und
Kanten im Property-Graphen Eigenschaften besitzen. Eine mögliche Erweiterung des Graphen
in Abbildung 2.2 besteht zum Beispiel im Speichern von personenbezogenen Daten, wie dem
Geburtstag im Knoten und dem Eintrittstermin in die Firma für die Kante.
GDBs bieten eine Alternative zur Speicherung und Verarbeitung von in Beziehung stehenden Informationen und damit auch zu den gebräuchlichen RDBs. Aufgrund dieses ähnlichen
Ansatzes ist eine Überführung der Daten zwischen den Systemen möglich.
2.3 Benchmarks und deren Relevanz
Der Duden definiert den Begriff Benchmark als „Maßstab für den Vergleich von Leistungen“
[7]. Anwendung finden Benchmarks zum Beispiel beim Vergleich von Unternehmen, Produkten
4
oder Computersystemen. Es können gesamte Systeme oder nur bestimmte Details untersucht
und verglichen werden. Die Leistung wird dabei über definierte Indikatoren gemessen. Für
GDBs können dies der Speicherverbrauch, die Laufzeit für die Berechnung einer Metrik oder
auch die Dauer für das Hinzufügen von Kanten sein. Nachdem man mehrere Systeme unter
dem gleichen Maßstab getestet hat, erfolgt eine Evaluation. Daraus ergeben sich Schlussfolgerungen für die Optimierung von Prozessen oder für die Wahl einer effizienten Datenbank,
entsprechend dem eigenen Anwendungsfall.
Für das Projekt SocialSensor1 wurde ein Vergleichsmaßstab benötigt, um auf dessen Grundlage sich für eine passende GDB zu entscheiden. Der zentrale Anwendungsfall war dabei die
performante Entdeckung von Communities in sozialen Netzwerken. Die Verantwortlichen entwickelten daraufhin ihren eigenen Benchmark, da sie auf keinen bestehenden zurückgreifen
konnten. Für den Benchmark, der drei zu vergleichenden GDBs Neo4J, OrientDB und Titan,
wurden 4 Workloads verwendet:
• Clustering [vgl. 2, Kapitel 3.1]:
nutzt die Louvain-Methode [vgl. 3] zur Entdeckung von Communities
• Massive Insertion [vgl. 2, Kapitel 3.2]:
GDB neuerstellen, Bulk Load konfigurieren, Datensatz laden, Zeit messen bis kompletter
Graph erzeugt wurde
• Single Insertion [vgl. 2, Kapitel 3.2]:
GDB neuerstellen und Datensatz laden, Commit nach jeder Einfügeoperation, Zeit pro
Block messen, Block besteht aus 1000 Kanten und aus Knoten die beim Einfügen mit
betrachteten wurden
• Query [vgl. 2, Kapitel 3.2]:
Abfrage über die Nachbarn aller Knoten oder über adjazente Knoten für alle Kanten, Suche
nach dem kürzesten Pfad zwischen dem ersten Knoten und 100 zufälligen Knoten
Als Ergebnis weist die Publikation von Beis, Papadopoulos und Kompatsiaris [vgl. 2] Neo4J
als beste GDB für „das Speichern und Abfragen von Graphdaten“ [2, Kapitel 6, S. 11]2 großer
Datensätze aus. Laut der Untersuchung eignet sich OrientDB eher für viele aufeinanderfolgende lokale Abfragen und die dritte getestete GDB, Titan, für einzelne Einfügeoperationen.
In einem Webinar3 des CEO von Neo Technology, Emil Eifrem, wird die Performanz von
GDBs den RDBs gegenübergestellt. Grundlage des ersten Tests war ein Datensatz mit 1000
Personen, die durchschnittlich 50 Freunde haben. Die Aufgabe der Datenbanken bestand darin
einen Pfad zwischen zwei Personen A und B innerhalb von vier Schritten zu finden. Im Ergebnis benötigte die RDB, welche nur als bekannte Open-Source-Datenbank spezifiziert wurde,
2000 ms und Neo4J 2 ms. Im zweiten Test, bei gleicher Aufgabenstellung, wurde ein Datensatz
mit 1 Million Personen und durchschnittlich 50 Freunden herangezogen. Neo4J benötigte für
diese Abfrage 2 ms, wobei die Abfrage für die RDB nach mehreren Tagen abgebrochen werden
musste. Das Beispiel demonstriert die Notwendigkeit von GDBs in der modernen Datenverarbeitung und -haltung, da bei diesen Anforderungen die RDBs an ihre Grenzen stoßen. Für ein
gutes Marketing ist es jedoch sehr viel interessanter Neo4J mit anderen GDBs zu vergleichen.
1
http://www.socialsensor.eu/
"Neo4J appears to be the most efficient solution for storing and querying graph data."[2, Kapitel 6, S. 11]
3
https://www.youtube.com/watch?v=UodTzseLh04&t=54m
2
5
Für gesicherte Messwerte ist deshalb ein unabhängiger Benchmark notwendig und sehr viel
aussagekräftiger.
2.4 Existierende Benchmarks
Für RDBs gibt es standardisierte und etablierte Benchmarks, wie die vom Transaction Processing Performance Council (TPC)4 bereitgestellten. Entwicklungen in diese Richtung gibt
es auch für GDBs. Das Kapitel gibt einen Einblick über bestehende GDB-Benchmarks.
Eine der Organisationen, die sich mit der Definition von Benchmarks befasst, ist das Linked
Data Benchmark Council (LDBC)5 . Ähnlich wie das TPC entwickeln die Mitglieder des
LDBC, zu denen unter anderem Firmen aber auch wissenschaftliche Einrichtungen zählen,
Benchmarks beziehungsweise Workloads, die sich an realen Anwendungsfällen orientieren. Im
Dezember 2015 stellte das LDBC zwei verschiedene Benchmarks zur Verfügung:
• Semantic Publishing Benchmark (SPB) - für RDF Systeme6
• Social Network Benchmark (SNB)7
– Interactive Workload:
„nur lesende Abfragen mit gleichzeitigen Einfügeoperationen“ [9, Kapitel 1, SNB-Interactive]8
– Business Intelligence Workload:
„Abfragen, die auf einen großen Anteil aller Einträge zugreifen“ [9, Kapitel 1, SNB-BI]9
– Graph Analytics Workload:
PageRank, Community Detection, Clustering, Breitensuche (BFS) [vgl. 9, Kapitel 1,
SNB-Algorithms]
Die Spezifikation des Interactive Workloads wurde in der vorläufigen Version 0.2.2 am 20.
April 2015 auf Github veröffentlicht10 . Im Vergleich dazu befinden sich die anderen beiden
Workloads für SNB noch in der Entwicklung. Zu den bereits veröffentlichten Komponenten
des SNB zählt unter anderem der Graphgenerator „datagen“, der realistische und skalierbare
Graphen verschiedener Größe erzeugen kann.
Das Projekt Graphalytics11 , der Technischen Universität Delft, „konzentriert sich auf das
Verständnis, wie die Leistung der Graph-Analytik-Plattformen von dem Eingabedatensatz,
dem Analyse-Algorithmus und der bereitgestellten Infrastruktur abhängt“ [13, Kapitel 1,
S. 2]12 . Anwendung findet der GDB-Benchmark für verteilte Systeme (Giraph, GraphX, Hadoop), aber auch für traditionelle GDBs (Neo4J) [vgl. 4, Kapitel 1, S. 1; Kapitel 3.2, S. 4].
Graphalytics kooperiert unter anderem mit dem LDBC und verwendet dessen Graphgenerator in einer modifizierten Variante zur Unterstützung verschiedener Charakteristiken von
4
http://www.tpc.org/
http://ldbcouncil.org/
6
http://ldbcouncil.org/benchmarks/spb
7
http://ldbcouncil.org/benchmarks/snb
8
„[c]oncurrent with these read-only queries is an insert workload“ [9, Kapitel 1, SNBInteractive]
9
„queries that access a large percentage of all entities in the dataset “ [9, Kapitel 1, SNB-BI]
10
https://github.com/ldbc/ldbc_snb_docs/blob/master/LDBC_SNB_v0.2.2.pdf
11
http://graphalytics.ewi.tudelft.nl/
12
„focuses on understanding how the performance of graph analytics platforms depends on the input dataset,
on the analytics algorithm, and on the provisioned infrastructure“ [13, Kapitel 1, S. 2 ]
5
6
Graphen [vgl. 4, Kapitel 2.2, S. 3].
Graph50013 definiert Benchmarks für die Verarbeitung von Graphen, die im Bereich Hochleistungsrechnen (HPC) Anwendung finden. Für das Benchmarking stellt Graph500 derzeit
eine Spezifikation [vgl. 12] und verschiedene Referenzimplementierungen14 zur Verfügung.
Grundlage für den Benchmark 1 „Search“ ist die Erzeugung einer Kantenliste, deren Größe
sich zwischen circa 17 GB (toy) und 1.1 PB (huge) bewegen kann. Anschließend wird daraus
ein gewichteter, ungerichteter Graph erzeugt und eine BFS ausgeführt [vgl. 12, Kapitel 1]. Die
Zeiterfassung erfolgt für die Generierung des Graphen und für die Ausführung der BFS. Diese
erhobenen Werte, einschließlich der maximal gelösten Problemgröße, werden unter anderem
für die Evaluation und für den Vergleich mit anderen Systemen herangezogen. Der erste
Entwurf für diesen Benchmark erfolgte im Juli 2010, am 1. Oktober desselben Jahres erschien
dann die Version 1.0 (aktuelle Version 2.1.4, Stand Dez. 2015). Die erste Veröffentlichung der
Graph500-Liste, die verschiedene Systeme miteinander vergleicht, erfolgte im November 2010.
Neue Listen werden etwa alle sechs Monate veröffentlicht.
XGDBench ist ein Benchmark für GDBs im Cloud-Computing-Bereich. Das Framework
ist in X10 geschrieben, einer von IBM Research entwickelten Programmiersprache, die vor
allem für verteilte System im Bereich des HPC gedacht ist15 . Es werden sieben verschiedene
Workloads in dem Benchmark durchgeführt:
• A: Update heavy: 50% Lesend/ 50% Update
– Abfrage eines Knoten und lesen aller Attribute
– Update-Operationen ändern die Zeit des letzten Logins
• B: Read mostly: 95% Lesend/ 5% Update
– Ähnlich zu A
• C: Read only:
– Nur lesende Operationen
• D: Read latest:
– Einfügen neuer Knoten, sodass Power-Law-Verteilung erhalten bleibt
• E: Short range scan:
– Alle Nachbarn eines Knoten abfragen und deren Attribute lesen
• F: Traverse heavy: 45% Traversierung/ 55% Lesend
• G: Traverse only:
– Nur Traversierungsoperationen [vgl. 6, Kapitel 6, Tabelle 2]
In der Publikation von Dayarathna und Suzumura [vgl. 6] werden die GDBs AllegroGraph,
Fuseki, Neo4J, OrientDB und Titan miteinander verglichen. OrientDB schnitt hinsichtlich der
Performanz beim Laden der Daten und bei den Workloads am besten ab.
GraphBench16 ist eine Graph-Benchmark-Suite, welche verschiedene „Graph Kernels“ [5]
und Datensätze enthält. Entwickelt wird das Projekt durch die Github-Gemeinschaft in Zu13
http://www.graph500.org
http://www.graph500.org/referencecode
15
http://x10-lang.org/articles/79.html
16
https://github.com/uwsampa/graphbench
14
7
sammenarbeit mit Oracle und der University of Washington. Bereitgestellt wird ein Skript
zum Download von realen Datensätzen von Sozialen Netzwerken. Diese umfassen kleine Graphen mit rund 4000 Knoten und 88.000 Kanten (Facebook) bis hinzu Datensätzen mit einer
Größe von 65 Millionen Knoten und 1,8 Milliarden Kanten (Friendster) [vgl. 5, Datasets and
Synthetic data generators]. Darüber hinaus bietet das Projekt einen Generator, der auf dem
Graph500-Generator basiert.
8
3 Implementierung
DNA stellt im Allgemeinen ein Framework zur Analyse von Graphen dar. In Kapitel 3.1.1
wird auf dieses näher eingegangen. Für die Untersuchung von GDBs bedarf es der Erweiterung
des DNA Frameworks. Damit mehrere GDBs in der Arbeit Unterstützung finden, wird das
Framework Tinkerpop Blueprints (Kapitel 3.1.2) verwendet. Es wird von den in Kapitel 3.2
vorgestellten Datenbanken implementiert. Die konkreten Anpassungen des DNA Framworks
werden in Kapitel 3.3 erläutert. Das abschließende Kapitel 3.4 beschreibt den Aufruf der neuen
Funktionen in Java.
3.1 Frameworks
3.1.1 DNA - Dynamic Network Analyzer
Dynamic Network Analyzer (DNA)1 ist ein in Java verfasstes Framework zur Untersuchung
von statischen und dynamischen Systemen. Das Hauptaugenmerk liegt jedoch auf der Analyse
von Netzwerken, die sich über die Zeit verändern. Soziale Netzwerke und Transportnetze sind,
entsprechend der Publikation von Schiller und Strufe [vgl. 17, S.1], diesen zu zuordnen. Der
DNA enthält verschiedene Bausteine, die im Rahmen der Arbeit Anwendung finden:
• Die Komponente des „Graphgenerators“ kann zufällige Graphen, Barabsi-Albert-Graphen
oder auch Ringe generieren, sowie solche aus Dateien auslesen. Die zur Speicherung des
Graphen verwendeten Datenstrukturen können je nach den Bedürfnissen des Anwenders
verändert oder getauscht werden, um den Einfluss der Datenstrukturen auf Speicher und
Laufzeit zu testen. Dafür stehen neben Arrays und Hashmaps viele weitere Datenstrukturen
zur Verfügung.
• Die Metrikkomponente stellt häufig genutzte Metriken der Graphentheorie, wie zum Beispiel Clustering-Koeffizient oder ShortestPath, zur Verfügung. Ferner unterstützt diese den
Vergleich von verschiedenen Implementierungen der gleichen Metrik hinsichtlich Korrektheit und den erfassten Messwerten.
• Es gibt drei Komponenten für die Visualisierung der Resultate:
– Visualization - live Visualisierung, vor allem für dynamische Systeme
– Plot - Darstellung mittels GnuPlot2
– LaTeX - Ausgabe aller Eingabeparameter und Resultate als LaTeX-Dokument.
Das Framework wurde als Open Source unter der GNU General Public License veröffentlicht.
Der Quellcode ist auf GitHub3 gehostet.
1
http://www.dynamic-networks.org/dna
http://www.gnuplot.info/
3
https://github.com/BenjaminSchiller/DNA
2
9
3.1.2 Tinkerpop Blueprints
Für die Integration von GDBs in DNA fiel die Entscheidung auf Tinkerpop Blueprints4 , da
bereits ein Vielzahl an kommerziellen und freien Datenbanken dieses Framework unterstützen.
Blueprints umfasst Interfaces, Implementierungen, Testsuiten und arbeitet dabei mit dem
Property-Graph-Modell. Durch die Verwendung von Blueprints bietet sich die Möglichkeit
in Zukunft weitere GDBs für die Nutzung mit DNA ohne großen Anpassungsaufwand des
Quelltextes hinzuzufügen. Bei der Implementierung kam Blueprints in der Version 2.6.0 zum
Einsatz.
3.2 Verwendete Graphdatenbanken
Im Folgenden werden die GDBs Bitsy5 , Neo4J6 , OrientDB7 und TinkerGraph8 vorgestellt,
welche in DNA integriert wurden. Alle verwendeten Datenbanken haben gemein, dass sie
die Interfaces von Tinkerpop Blueprints implementieren. Die GDBs Bitsy, OrientDB und
TinkerGraph werden in der In-Memory-Variante genutzt. Das heißt alle Daten werden lediglich
im Speicher gehalten und nicht persistiert. Bitsy wird neben Neo4J zusätzlich auch für die
persistente Speicherung des Graphen genutzt.
Bitsy
Bitsy ist eine „kleine, schnelle, integrierbare, persistente In-Memory-Graphdatenbank“ [19],
die unter der GNU Affero General Public License Version 3 als freie Software veröffentlicht
wurde. Bitsy unterstützt die ACID-Eigenschaft (Atomarität, Konsistenz, Isolation und Dauerhaftigkeit) für Transaktionen und nutzt, um Konsistenz zu gewährleisten, optimistisches
Locking. In der Arbeit findet die Version 1.5.1 Anwendung.
Neo4J
Neo4J wurde im Jahr 2007 von NeoTechnology veröffentlicht und zählt heute, nach Aussage
des Konzerns, zu den führenden GDBs auf dem Markt [vgl. 14]. Eine Vielzahl namhafter
Firmen, darunter das Internetauktionshaus Ebay oder die Fluggesellschaft Lufthansa [vgl.
15], zählen zu den Nutzern. Neo4J unterstützt die ACID-Eigenschaft für Transaktionen und
nutzt pessimistisches Locking. Es gibt die Datenbank in einer Community und einer Enterprise
Edition, wobei Ersteres in der vorliegenden Implementierung in der Version 2.0.1 zum Einsatz
kommt.
OrientDB
OrientDB ist eine Multi-Model-Datenbank, das heißt sie „unterstützt das Graphen-, Dokumenten-, Key/Value- und das Object-Modell“ [16, Multimodel, NoSQL Models]. OrientDB
4
https://github.com/tinkerpop/blueprints/wiki
https://bitbucket.org/lambdazen/bitsy
6
http://neo4j.com
7
http://orientdb.com
8
https://github.com/tinkerpop/blueprints/wiki/TinkerGraph
5
10
unterstützt die ACID-Eigenschaft für Transaktionen. Für die Gewährleistung der Konsistenz
nutzt die Datenbank Multiversion Concurrency Control (MVCC). Ähnlich wie Neo4J gibt es
auch OrientDB als Community und Enterprise Edition. Anwendung findet die CommunityEdition in der Version 2.0.12.
TinkerGraph
TinkerGraph ist die Referenzimplementierung für das Property-Graph-Modell von Tinkerpop
Blueprints und wird in der Version 2.6.0 verwendet.
3.3 Graphdatenbanken in DNA
Bisher gab es drei grundlegende Klassen zu Speicherung von Graphen in DNA: Node, Edge,
Graph. In der Klasse Graph werden Knoten und Kanten in einer frei wählbaren Datenstruktur
gespeichert. Die Klassen Node und Edge stellen Basisklassen dar, von denen für gerichtete und
ungerichtete Graphen entsprechende Klassen abgeleitet sind. In den Knoten werden jeweils
eine Liste für ein- und ausgehende Kanten und für den gerichteten Fall auch benachbarte
Knoten gespeichert.
Mit der Integration von GDB in DNA wird zunächst ein neues Interface, IGraph (Anhang
A.1), eingeführt. Klassen für die Graphrepräsentation in DNA müssen dieses implementieren,
davon betroffen sind Graph und die neu eingeführte BlueprintsGraph. Die Verwendung des
Interfaces IGraph ermöglicht es die Anpassungen des bestehenden Quelltextes so gering wie
möglich zu halten. Darüber hinaus erlaubt das Interface zukünftig weitere GDBs oder andere
Speichermöglichkeiten einzuführen, die nicht Blueprints implementieren und nicht über die
vorhandenen Datenstrukturen abgedeckt werden können. Die vorgenommenen Änderungen
an der ursprünglichen Architektur von DNA, veröffentlicht durch Schiller und Strufe [vgl. 17,
Kapitel 4, Abbildung 2], sind farblich in der Abbildung 3.1 hinterlegt.
Abbildung 3.1: Architektur von DNA
Die aktuelle Implementierung unterstützt drei In-Memory-Varianten (Bitsy, OrientDB und
11
TinkerGraph) und zwei persistente Datenbank-Varianten (Bitsy und Neo4J). Alle in DNA
nutzbaren Graphen können über die neue Klasse DNAGraphFactory erzeugt werden. In der
Tabelle 3.1 werden die unterstützten DNA-Graphtypen aufgelistet.
GF_GraphType
persistent In-Memory
DNA
X
BITSY_DURABLE
X
BITSY_NON_DURABLE
X
CONFIG
(X)9
NEO4J2
X
(X)9
ORIENTDBNOTX
X
TINKERGRAPH
X
Tabelle 3.1: Alle unterstützten DNA-Graphtypen
Der Graphtyp CONFIG liest aus einer Konfigurationsdatei, welche im Anhang A.2 beispielhaft dargestellt ist, die notwendigen Werte zur Erstellung eines DNA-Graphen. Es wird eine
Instanz der Klasse Graph erzeugt, wenn der Parameter GF_GraphType den Wert DNA hat.
Alle anderen in Tabelle 3.1 angegebenen Werte erzeugen jeweils eine neue Instanz der Klasse
BlueprintsGraph. Diese stellt intern eine Verbindung zu der entsprechenden Datenbank her,
beziehungsweise initialisiert die eingebettete GDB.
Für die Ausführung von Operationen auf Knoten und Kanten der Blueprints-GDBs wurden ebenfalls neue Klassen in DNA integriert. Diese erben von den bisherigen Knoten- bzw.
Kanten-Klassen und erweitern sie. Die neuen Klassen enthalten einen Verweis auf die zugehörige Instanz der Klasse BlueprintsGraph. Dies ermöglicht, dass Knoten und Kanten Operationen
auf dem Graphen ausführen, ohne das jede Klasse eine eigene Verbindung zur Datenbank aufbaut. Für gewichtete Knoten und Kanten werden die Gewichte als Properties in der GDB
gespeichert.
Einige GDBs ermöglichen das Speichern von Referenzen auf DNA-Elemente in den Properties, für die anderen GDBs ist es nötig sich die Knoten- und Kanten-Paare in einer separaten Liste zu speichern. Dafür werden die Knoten- beziehungsweise Kantenindizes aus
der Datenbank mit dem DNA-Knoten oder der -Kante in einer Hashmap gespeichert. Um
die Vergleichbarkeit der erfassten Ergebnisse zu gewährleisten, kann durch den Parameter
GF_GDB_STORE_DNA_ELEMENTS_IN_GDB angegeben werden, dass alle Datenbanken gleichermaßen die Liste der DNA-Elemente speichern.
Der Quellcode zu dieser Erweiterung wurde auf GitHub10 veröffentlicht. Ein UML-Klassendiagramm der neu implementierten Klassen ist im Anhang A.3 dargestellt.
9
10
hängt vom Parameter GF_GraphType ab
https://github.com/matjoe/DNA
12
3.4 Anwendung
Zur Nutzung von GDBs in DNA gibt es generell zwei Möglichkeiten. Die Erste besteht darin,
über die neue Klasse GraphFactory sich eine Instanz von Graph oder BlueprintsGraph zu
erzeugen:
1
2
3
IGraph graph = GraphFactory . newInstance ( GraphType . BITSY_NON_DURABLE , name , timestamp ) ;
graph . addNode (...) ;
graph . addEdge (...) ;
4
5
6
// den Graph wieder freigeben / Verbindung zur Datenbank schlie ß en
graph . close () ;
Abbildung 3.2: Anwendungsbeispiel 1
Die zweite Möglichkeit sieht die Änderung der Werte für die Einstellungsparameter entweder
im Quelltext oder in der Konfigurationsdatei selbst vor. Der folgende Code-Ausschnitt zeigt,
wie mit Hilfe eines Graphgenerators und der festgelegten Konfiguration ein Graph in einer
Datenbank erstellt werden kann:
1
2
3
Config . overwrite ( " GF_GRAPHTYPE " , GraphType . TINKERGRAPH ) ;
Config . overwrite ( " G F _ GD B _ W O R K S P A C E " , IOUtils . getPathForOS ( workspace + " GDB / " ) ) ;
Config . overwrite ( " G F _ G D B _ S T O R E _ D N A _ E L E M E N T S _ I N _ G D B " , storeInGDB . toString () ) ;
4
5
Graph Generato r rg = new RandomGraph ( GDS . directedGDB () , nodes , edges ) ;
6
7
8
9
// entweder
Series s = new Series ( rg , ... ) ;
s . generate () ;
10
11
12
13
14
// oder
IGraph graph = rg . generate () ;
graph . addNode (...) ;
graph . addEdge (...) ;
15
16
17
// den Graph wieder freigeben / Verbindung zur Datenbank schlie ß en
graph . close () ;
Abbildung 3.3: Anwendungsbeispiel 2
13
4 Messwerterfassung
Mit der Implementierung folgt im nächsten Schritt die Erfassung von Messwerten, um die
Durchführbarkeit eines Benchmarks aufzuzeigen. In Kapitel 4.1 wird das zugrundeliegende
Setup zur Erhebung der Messwerte vorgestellt. Daran anschließend werden in Kapitel 4.2
die Messergebnisse grafisch präsentiert und ausgewertet. Im Fokus der Auswertung für die
durchgeführten Operationen steht dabei das Kriterium der Laufzeit. Speicher wird zunehmend
günstiger, daher ist der Speicherverbrauch in der heutigen Zeit nicht der wichtigste Faktor
bei der Analyse von GDBs. Zeit hingegen spielt ein wichtige Rolle, da kein Nutzer lang auf
ein Resultat warten möchte. Schnelle Antwortzeiten eines Softwareproduktes steigern dessen
Attraktivität für den Endverbraucher.
4.1 Setup
Die Messungen wurden auf einem System mit 64 CPUs und 512 GB Arbeitsspeicher durchgeführt, wobei jeder Java VM genau ein logischer Prozessor zugewiesen wurde. An den Einstellungen der GDBs wurden keine Optimierung vorgenommen. Die beiden Datenbanken Neo4J
und Bitsy wurden persistent auf eine Solid State Disk (SSD) geschrieben. Des Weiteren wurden alle verwendeten GDBs als eingebettete Datenbank verwendet, das heißt es wurde für
jede Java-Instanz eine eigene Datenbankinstanz erzeugt. Damit liefen sowohl Datenbank, als
auch der dazugehörige Java-Prozess auf demselben Prozessor.
Die Messwerterfassung erfolgte für jeden Schritt des in Abbildung 4.1 dargestellten Ablaufdiagramms. Der ursprüngliche Zustand der Graphen wurde dabei zu Beginn eines jeden
Prozesses variiert. Im Voraus wurde für jede Graphkonfiguration eine Datei erstellt, die für
die Generierung ausgelesen wurde, damit alle GDBs denselben Ausgangszustand haben:
• gerichteter zufälliger Graph
• ungerichteter zufälliger Graph
• gerichteter Barabasi-Albert-Graph
• ungerichteter Barabasi-Albert-Graph
14
Abbildung 4.1: Ablauf der Messung
Für die gerichteten Graphen wurden jeweils 13 und für die ungerichteten Graphen je 12
verschiedene Größen gemessen. Die genaue Auflistung der Parameter für die Generierung der
Graphen ist im Anhang B.1 aufgeführt.
Der Barabasi-Albert-Graph beruht auf dem gleichnamigen Modell von Réka Albert und
Albert-László Barabási [vgl. 1] und stellt einen Graph dar, dessen Anzahl von Kanten pro
Knoten nach einem Potenzgesetz verteilt sind. Diese Graphen ähneln realen Netzwerken, wie
dem Internet, Stromnetzen oder den Verlinkungen zwischen verschiedenen Webseiten [vgl. 1,
Kapitel 2]. Im Gegensatz dazu wurden zufällige Graphen generiert, die keiner bestimmten
Verteilung folgen. Ziel dabei war es festzustellen, ob sich die GDBs für diese Graphen anders
verhalten oder gleiche Tendenzen zu erkennen sind. Für den Vergleich wurden neben den
erwähnten GDBs auch drei DNA-Datenstrukturen gemessen, es handelt sich dabei um:
• Array: Alle Listen werden in Arrays gespeichert.
• HashMultimap: Die globale Kantenliste wird in einer HashMultimap gespeichert, alle anderen Listen werden in Arrays abgelegt.
• Empty: Die globale Kantenliste wird nicht gespeichert, alle anderen Listen werden in Arrays
abgelegt.
Untersucht wurden im Speziellen fünf verschiedene Workloads. Wie in Abbildung 4.1 ersichtlich, wurden jeweils fünf Messungen pro Graph und Workload durchgeführt. Im Folgenden
wird kurz erläutert, was die einzelnen Workloads beinhalten und was ein möglicher Anwendungsfall sein kann:
• Breitensuche (BFS)
– Suche für 20 zufällige Knoten mit 10 Wiederholungen
– Einsatz: Distanzen zwischen zwei Knoten → Beziehungen zwischen zwei Personen
• Tiefensuche (DFS)
– Suche für 20 zufällige Knoten mit 10 Wiederholungen
– Einsatz: Suche nach starken Zusammenhangskomponenten → Suche in sozialen Netzwerken nach Gruppen gleicher Eigenschaft
• Knoteniteration
– einmalige Iteration über die Menge V aller Knoten des Graphen
• Kanteniteration
– einmalige Iteration über die Menge E aller Kanten der Graphen
15
• Lokaler Clustering-Koeffizient
– Berechnung über 20 festgelegte Knoten
4.2 Ergebnisse und Auswertung
4.2.1 Graphgenerierung
Mit zunehmender Kantenanzahl steigt für alle GDBs die Laufzeit bei der Generierung des Graphen auf der Datenbank, dabei benötigten ungerichtete Graphen für alle Datenbanken mehr
Zeit als Digraphen. Dies gilt auch für Barabasi-Albert-Graphen, die eine höhere Laufzeit aufweisen als zufällige Graphen. Besonders langsam bei der Generierung von gerichteten Graphen
ist OrientDB. Zeigt Neo4J für gerichtete Graphen noch eine Laufzeit, die der von DNA Array
ähnelt, schneidet sie für ungerichtete Graphen deutlich schlechter ab. Eine mögliche Ursache kann dabei der größere Funktionsumfang der GDBs sein, was zur längeren Startzeit der
internen Datenbank führen kann. Eine weitere Ursache für die höheren Zeiten beim Schreiben der Graphen kann die Indexerstellung sein, wie sie OrientDB für jeden neuen Knoten
und jede Kante durchführt. Die Indexerstellung stellt gegenüber den DNA-Datenstrukturen
einen Mehraufwand dar und nimmt somit mehr Zeit in Anspruch. Die schnellste Datenbank
im Test war TinkerGraph, diese bietet jedoch nicht die typischen Datenbank-Eigenschaften
(keine Transaktionen, kein ACID). Betrachtet man die Produktivsysteme, so ist Bitsy die
schnellste Datenbank. Die Unterschiede zwischen der persistenten und In-Memory Variante
sind marginal.
Abbildung 4.2: Graphgeneratoren für 1k Knoten und 100k Kanten
Der Speicherverbrauch variiert stark zwischen den verschiedenen Größen der Graphen bei
gleicher Datenbank. Auffällig ist, dass der Speicherverbrauch bei 10k Kanten geringer ist als
bei 5k Kanten. Grund dafür könnte der Aufruf des Garbage Collectors sein und damit die Freigabe des Speichers. Eine hohe Varianz im Speicherverbrauch, zwischen den unterschiedlichen
Durchläufen, liegt bei der Datenbank OrientDB vor.
16
4.2.2 BFS und DFS
Betrachtet werden im Folgenden die Messergebnisse für gerichtete Graphen beider getesteter
Graphtopologien, da diese das Resultat von BFS und DFS kaum beeinflussen. Die Performanz
von Bitsy (persistent, In-Memory) verschlechtert sich mit steigender Kantenanzahl der Graphen. Für kleine Graphen, der Größenordnung 1k Knoten und 1k bis 5k Kanten, ist Bitsy, im
Vergleich zu den anderen getesteten Datenbanken, die Schnellste. Die längste Laufzeit für den
kleinsten getesteten Graphen hat Neo4J. Mit steigender Kantenanzahl ist der Anstieg der benötigten Zeit jedoch deutlich geringer als für die anderen GDBs und Neo4J erweist sich als die
schnellste. Am schlechtesten schneidet OrientDB bei der Durchführung des BFS beziehungsweise DFS ab. Bei einem Graphen mit 1k Knoten und 500k Kanten ist die Laufzeit bereits
21 mal länger, als bei der Referenzimplementierung TinkerGraph. Die DNA-Datenstrukturen,
die in diesem Zusammenhang ebenfalls getestet wurden, weisen mit steigender Kantenanzahl
eine deutlich bessere Performanz als die GDBs auf. Für kleine Graphen (1k Knoten, 1k Kanten) ist das Niveau jedoch auf dem von Bitsy. Abgesehen von kleinen Graphen ergibt sich
folgende Rangordnung der Datenstrukturen bezüglich der Laufzeit: DNA-Datenstrukturen,
Neo4J, TinkerGraph, Bitsy (persistent), Bitsy (In-Memory) und OrientDB.
Abbildung 4.3: BFS für gerichtete zufällige Graphen mit 1k Knoten bei steigender Kantenanzahl
Bei ungerichteten Graphen, unabhängig von der Graphtopologie, ergibt sich eine etwas andere Reihenfolge der GDBs. Die beste Performanz weisen auch hier die DNA-Datenstrukturen,
gefolgt von TinkerGraph, auf. Die persistente Variante von Bitsy ist für ungerichtete Graphen
die Schnellste im Test. Daran anschließend folgen die In-Memory Variante von Bitsy, Neo4J
und OrientDB.
17
Abbildung 4.4: BFS für ungerichtete zufällige Graphen bei 1k Knoten mit steigender Kantenanzahl
4.2.3 Knoteniteration
Die Laufzeitanalyse bei der Knoteniteration für gerichtete Graphen ergibt, dass Neo4J und
OrientDB zu den GDBs gehören, die am schnellsten die Aufgabe lösen konnten. Im Vergleich
dazu sind die DNA-Datenstrukturen, vor allem HashMultimap und Empty, circa vier- bis
sechsmal langsamer. Auffällig ist, dass die Varianzen der Messungen für die DNA-Datenstrukturen sehr hoch sind. Die Gesamtlaufzeit liegt für GDBs als auch DNA-Datenstrukturen
im Millisekundenbereich, die durchschnittlichen Werte bewegen sich im Bereich von 400 µs
bis 13 ms. Ähnliche Ergebnisse erhält man bei der Betrachtung der Messungen für ungerichtete Graphen. Die Laufzeiten sind sehr gering, sie liegen im selben Wertebereich wie für die
gerichteten Graphen. In diesem Test sticht keine GDB eindeutig hervor.
4.2.4 Kanteniteration
Obwohl OrientDB sich für BFS und DFS als langsamste GDB herausstellte, zeigt sich, dass sie
für die Kanteniteration über gerichtete zufällige Graphen, neben Neo4J, eine der schnellsten
Datenbanken ist. Zurückzuführen ist dies vermutlich auf eine globale Kantenliste. Für BFS
und DFS ist diese nicht von Vorteil, da über Kanten in Beziehung stehende Knoten erst
gefiltert werden müssen. Des Weiteren zeigt sich, dass beim Iterieren über die Kanten die DNADatenstruktur, die eine HashMultimap als globale Kantenliste verwendet, eine schlechtere
Performanz als die GDBs aufweist.
18
Abbildung 4.5: Kanteniteration für gerichtete zufällige Graphen mit 1k Knoten
Für gerichtete Barabasi-Albert-Graphen ist nach TinkerGraph, OrientDB ebenfalls die
schnellste Datenbank bei der Kanteniteration. Am schlechtesten schneidet ebenfalls wieder
die DNA-Struktur HashMultimap ab. Für kleine Graphen weisen die DNA-Datenstrukturen
Array und Empty ebenfalls eine schlechtere Performanz, als die getesteten GDBs, auf.
Abbildung 4.6: Kanteniteration für gerichtete Barabasi-Albert-Graphen mit 1k Knoten
Bei ungerichteten Graphen sind ähnliche Ergebnisse zu verzeichnen, wie für gerichtete Graphen. Abweichungen gibt es für kleine Graphen (1k Knoten, bis zu 5k Knoten). Hier ist Neo4J
teilweise besser als OrientDB. Die etwas bessere Performanz der GDBs bei kleinen Graphen
kann vermutlich auf eine bessere Speicherverwaltung oder auch auf das Caching zurückgeführt
werden. Neo4J bietet zum Beispiel einen eigenen Cache, über den auf die Dateien zugegriffen
wird.
19
4.2.5 Lokaler Clustering-Koeffizient
Für die Berechnung des lokalen Clustering-Koeffizienten ist TinkerGraph die schnellste Graphdatenbank. Betrachtet man die Produktivsysteme sind für kleine Graphen (1k Knoten) die
beiden Varianten von Bitsy am schnellsten. Für die größeren getesteten Graphen eignet sich
hingegen eher die GDB Neo4J. Die schlechteste Performanz bei der Berechnung des lokalen
Clustering-Koeffizienten weist dabei OrientDB auf, die 30- bis 50-mal so viel Zeit benötigt
wie TinkerGraph.
Abbildung 4.7: Lokaler Clustering-Koeffizient für gerichtete Barabasi-Albert-Graphen mit 1k
Knoten
4.2.6 Resultate
Im Folgenden sei die Rangordnung der DNA-Datenstrukturen und GDBs bezüglich der Laufzeitmessungen für die durchgeführten Workloads in der Tabelle 4.1 dargestellt. Ausgenommen
davon sind die Operationen Knoten- und Kanteniteration, da die Messergebnisse der verschiedenen GDBs dicht beieinander liegen.
Rangfolge
Graph
1k
Knoten,
gerichtet
10k
Knoten,
gerichtet
Workload
1.
2.
3.
BFS oder
DNA
DNA
DNA
DFS
HM
A
E
BFS oder
DNA
DNA
DNA
DFS
A
E
HM
20
4.
5.
6.
7.
8.
N
TG
BD
BND
ODB
N
TG
BD
BND
ODB
Rangfolge
Graph
Workload
1.
2.
3.
Knoten,
BFS oder
DNA
DNA
DNA
ungerich-
DFS
E
A
HM
Knoten,
BFS oder
DNA
DNA
DNA
ungerich-
DFS
E
A
HM
DNA
DNA
DNA
A
HM
E
DNA
DNA
DNA
A
HM
E
4.
5.
6.
7.
8.
TG
BD
BND
N
ODB
TG
BD
BND
N
ODB
TG
BD
BND
N
ODB
TG
N
BND
BD
ODB
1k
tet
10k
tet
1k
Lokaler
Knoten,
Clustering-
gerichtet
Koeffizient
10k
Lokaler
Knoten,
Clustering-
gerichtet
Koeffizient
Tabelle 4.1: Ergebnisübersicht
(DNA A - DNA Array, DNA E - DNA Empty, DNA HM - DNA HashMultimap, BD - Bitsy
(persistent), BND - Bitsy (In-Memory), N - Neo4J, ODB - OrientDB, TG - TinkerGraph)
21
5 Ausblick
Die mit dieser Arbeit vorgelegte Implementierung, beziehungsweise Erweiterung von DNA,
kann als Benchmark für GDBs genutzt werden. Grundlage für die Gewährleistung der Vergleichbarkeit von Messergebnissen ist eine gemeinsame Schnittstelle für alle Datenbanken.
Mit der Verwendung der Blueprints Interfaces können gleiche Zugriffszeiten aus DNA heraus auf die verschiedenen Datenbanken gewährleistet werden. Die aktuelle Implementierung
umfasst bisher nur einige wenige GDBs. Durch die Erweiterung der Klassen BlueprintsGraph
und DNAGraphFactory können Datenbanken, die die Interfaces von Tinkerpop Blueprints
implementieren, hinzugefügt werden. Aufbauend auf dieser Arbeit können weitere GDBs in
DNA berücksichtigt werden. Dafür bedarf es mindestens der Implementierung des Interfaces
IGraph, sowie der Erweiterung der Klasse DNAGraphFactory um den neuen Graphtypen. Zu
beachten ist dabei, dass die Zugriffszeiten aus DNA heraus auf die Datenbanken, die die Blueprints Interfaces nicht implementieren, sich aber für die Messungen gegenüber den Zeiten mit
der Klasse BlueprintsGraph unterscheiden können.
Die derzeitige Erweiterung für DNA berücksichtigt das Neuerstellen eines Graphen auf einer
gewünschten GDB. Damit die Anwender in Zukunft das Benchmarking unter Berücksichtigung
ihrer eigenen Daten durchführen können, bedarf es der Erweiterung der Klasse BlueprintsGraph um ein „Import-Funktion“. Diese Anpassung bietet die Möglichkeit eigene Graphen
zu analysieren und sie auf anderen Datenbanken zu testen. Somit kann der Anwender für
seine Daten und seinen Workload die bestmögliche Datenbank finden. Neben der Analyse von
statischen Systemen, die in dieser Arbeit im Vordergrund standen, berücksichtigt DNA auch
dynamisches Verhalten - das Anwachsen des Graphen über die Zeit. Für das Erstellen von
Prognosen bei größer werdenden Graphen bietet DNA weitere Operationen wie z.B. Kanten
und Knoten hinzufügen. Damit kann das Verhalten der Datenbank mit steigender Anzahl von
Kanten und Knoten untersucht und verglichen werden.
22
Anhangsverzeichnis
A Implementierung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
A.1 Das Interface IGraph
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
A.2 Beispiel einer Konfigurationsdatei . . . . . . . . . . . . . . . . . . . . . . . . 25
A.3 UML-Klassendiagramm . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
B Graphgenerierung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
B.1 Alle Parameter für die Generierung der Graphen . . . . . . . . . . . . . . . . 27
23
Anhang
A. Implementierung
A.1. Das Interface IGraph
24
A.2. Beispiel einer Konfigurationsdatei
1
2
3
# #####################################################################
# # SETTINGS FOR THE GRAPHFACTORY
# #####################################################################
4
5
6
7
8
9
10
11
12
13
# # GF_GRAPHTYPE # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # #
# Possible Values :
# * BITSY_DURABLE
# * BITSY_NON_DURABLE
# * DNA
# * NEO4J2
# * ORIENTDBNOTX
# * TINKERGRAPH
GF_GRAPHTYPE = TINKERGRAPH
14
15
16
17
18
19
20
## GF_GDB_CLEAR_WORKSPACE_ON_CLOSE ###################################
# Applies only for :
# * BITSY_DURABLE
# * NEO4J2
G F _ G D B _ C L E A R _ W O R K S P A C E _ O N _ C L O S E = true
GF_GDB_WORKSPACE = data / GDB /
21
22
23
24
25
26
27
28
29
# # G F _ G D B _ O P E R A T I O N S _ P E R _ C O M M I T [0 - INTEGER . MAX_VALUE ]###############
# Defines after how many operations a commit will be executed .
# Default : 0
# <0 : NO_COMMIT
# =0 : COMMIT_ON_CLOSE
# Example :
# OPER ATIO NS_P ER_CO MMIT =1000 -> commit after 1000 operations
G F _ G D B _ O P E R A T I O N S _ P E R _ C O M M I T =0
30
31
32
33
34
## GF_GDB_STORE_DNA_ELEMENTS_IN_GDB ##################################
# If this option is true DNA tries to store the DNA elements ( nodes ,
# edges ) in the graph database if possible
G F _ G D B _ S T O R E _ D N A _ E L E M E N T S _ I N _ G D B = false
25
A.3. UML-Klassendiagramm
26
B. Graphgenerierung
B.1. Alle Parameter für die Generierung der Graphen
Parameter für die Generierung des Graphen
Ungerichteter zufälliger Graph
Gerichteter zufälliger Graph
Typ
#Knoten
#Kanten
#Startkno-
#Startkan-
ten
ten
1k
1k
1k
1k
1k
5k
1k
5k
1k
10k
1k
10k
1k
50k
1k
50k
1k
100k
1k
100k
1k
500k
1k
500k
10k
1k
10k
1k
10k
5k
10k
5k
10k
10k
10k
10k
10k
50k
10k
50k
10k
100k
10k
100k
10k
500k
10k
500k
10k
1M
10k
1M
1k
1k
1k
1k
1k
5k
1k
5k
1k
10k
1k
10k
1k
50k
1k
50k
1k
100k
1k
100k
10k
1k
10k
1k
10k
5k
10k
1k
10k
10k
10k
10k
10k
50k
10k
50k
10k
100k
10k
100k
10k
500k
10k
500k
10k
1M
10k
1M
27
#Hinzuzufügende
Knoten
#Kanten
pro Knoten
Parameter für die Generierung des Graphen
Ungerichteter Barabasi-Albert-Graph
Gerichteter Barabasi-Albert-Graph
Typ
#Knoten
#Kanten
#Startkno-
#Startkan-
ten
ten
#Hinzuzufügende
Knoten
#Kanten
pro Knoten
1k
1k
10
10
990
1
1k
5k
10
50
990
5
1k
10k
50
500
950
10
1k
50k
52
2600
948
50
1k
100k
150
15 K
850
100
1k
500k
800
400 K
200
500
10k
1k
9001
1
999
1
10k
5k
9001
5
999
5
10k
10k
10
10
9990
1
10k
50k
50
250
9950
5
10k
100k
50
500
9950
10
10k
500k
102
5100
9898
50
10k
1M
204
20400
9796
100
1k
1k
10
10
990
1
1k
5k
20
100
980
5
1k
10k
50
500
950
10
1k
50k
102
5100
898
50
1k
100k
204
20400
796
100
10k
1k
9001
1
999
1
10k
5k
9001
5
999
5
10k
10k
10
10
9990
1
10k
50k
50
250
9950
5
10k
100k
50
500
9950
10
10k
500k
102
5100
9898
50
10k
1M
204
20400
9796
100
28
Abbildungsverzeichnis
1.1 Vernetzung der Facebook-Nutzer weltweit . . . . . . . . . . . . . . . . . . . . . .
1
2.1 Entwicklung von Neo4J bei NeoTechnology . . . . . . . . . . . . . . . . . . . . .
3
2.2 Beispiel für einen einfachen gerichteten Graphen . . . . . . . . . . . . . . . . . .
4
2.3 Beispiel einer Relation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
4
3.1 Architektur von DNA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
3.2 Anwendungsbeispiel 1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
3.3 Anwendungsbeispiel 2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
4.1 Ablauf der Messung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
4.2 Graphgeneratoren für 1k Knoten und 100k Kanten . . . . . . . . . . . . . . . . . 16
4.3 BFS für gerichtete zufällige Graphen mit 1k Knoten bei steigender Kantenanzahl 17
4.4 BFS für ungerichtete zufällige Graphen mit 1k Knoten bei steigender Kantenanzahl 18
4.5 Kanteniteration für gerichtete zufällige Graphen mit 1k Knoten
. . . . . . . . . 19
4.6 Kanteniteration für gerichtete Barabasi-Albert-Graphen mit 1k Knoten . . . . . 19
4.7 Lokaler Clustering-Koeffizient für gerichtete Barabasi-Albert-Graphen mit 1k
Knoten . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
29
Tabellenverzeichnis
3.1 Alle unterstützten DNA-Graphtypen . . . . . . . . . . . . . . . . . . . . . . . . . 12
4.1 Ergebnisübersicht . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
30
Quellenverzeichnis
[1]
Réka Albert und Albert-László Barabási. „Statistical mechanics of complex networks“.
In: Reviews of Modern Physics 74 (Januar 2002), S. 47–97. doi: 10.1103/RevModPhys.
74.47. eprint: cond-mat/0106096. (Besucht am 28. Februar 2016).
[2]
Sotirios Beis, Symeon Papadopoulos und Yiannis Kompatsiaris. „New Trends in Database and Information Systems II“. In: Springer, 2014. Kap. Benchmarking Graph
Databases on the Problem of Community Detection, S. 3 –14. doi: 10.1007/978-3319-10518-5_1. (Besucht am 28. Februar 2016).
[3]
Vincent D Blondel, Jean-Loup Guillaume, Renaud Lambiotte und Etienne Lefebvre.
„Fast unfolding of communities in large networks“. In: Journal of Statistical Mechanics:
Theory and Experiment 2008.10 (2008), P10008. url: http://stacks.iop.org/17425468/2008/i=10/a=P10008 (besucht am 28. Februar 2016).
[4]
Mihai Capotă, Tim Hegeman, Alexandru Iosup, Arnau Prat-Pérez, Orri Erling und
Peter Boncz. „Graphalytics: A Big Data Benchmark for Graph-Processing Platforms“.
In: Proceedings of the GRADES’15. GRADES’15. Melbourne, VIC, Australia: ACM,
2015, 7:1–7:6. isbn: 978-1-4503-3611-6. doi: 10.1145/2764947.2764954. url: http:
//doi.acm.org/10.1145/2764947.2764954 (besucht am 28. Februar 2016).
[5]
Hassan Chafi, Tim Harris, Cindy Xin Yi, Jake Sanders, Jacob Nelson, Brandon Holt,
Brandon Myers, Luis Ceze, Mark Oskin und Simon Kahan. GraphBench Wiki. 2015.
url: https : / / github . com / uwsampa / graphbench / wiki (besucht am 28. Februar
2016).
[6]
Miyuru Dayarathna und Toyotaro Suzumura. „Graph database benchmarking on cloud
environments with XGDBench“. English. In: Automated Software Engineering 21.4 (2014),
S. 509–533. issn: 0928-8910. doi: 10.1007/s10515- 013- 0138- 7. url: http://dx.
doi.org/10.1007/s10515-013-0138-7 (besucht am 28. Februar 2016).
[7]
Duden. Benchmark. Dezember 2015. url: http : / / www . duden . de / node / 774596 /
revisions/1162309/view (besucht am 28. Februar 2016).
[8]
H. Ehrig, B. Mahr, F. Cornelius, M. Große-Rhode und P. Zeitz. Mathematisch-strukturelle
Grundlagen der Informatik. Springer-Lehrbuch. Springer Berlin Heidelberg, 2013. isbn:
9783642567926. url: https://books.google.de/books?id=aEkjBgAAQBAJ (besucht
am 28. Februar 2016).
[9]
Orri Erling, Alex Averbuch, Josep Larriba-Pey, Hassan Chafi, Andrey Gubichev, Arnau
Prat, Minh-Duc Pham und Peter Boncz. „The LDBC Social Network Benchmark: Interactive Workload“. In: Proceedings of the 2015 ACM SIGMOD International Conference
on Management of Data. SIGMOD ’15. Melbourne, Victoria, Australia: ACM, 2015,
31
S. 619–630. isbn: 978-1-4503-2758-9. doi: 10 . 1145 / 2723372 . 2742786. url: http :
//doi.acm.org/10.1145/2723372.2742786 (besucht am 28. Februar 2016).
[10]
Facebook Inc. 1,000,000,000 People, Together. August 2015. url: https : / / www .
facebook . com / 20531316728 / posts / 10154009990506729 (besucht am 28. Februar
2016).
[11]
Facebook Inc. friendships formed on Facebook. Dezember 2013. url: https://scontent.
xx.fbcdn.net/hphotos-frc3/t31.0-8/1275272_10101026493146301_791186452_o.
jpg (besucht am 28. Februar 2016).
[12]
Graph 500 Steering Committee. Graph 500 Benchmark 1 (ßearch"). url: http://www.
graph500.org/specifications (besucht am 28. Februar 2016).
[13]
Alexandru Iosup, Mihai Capotă, Tim Hegeman, Guo Yong, Wing Lung Ngai, Ana Lucia
Varbanescu und Merijn Verstraaten. „Towards Benchmarking IaaS and PaaS Clouds
for Graph Analytics“. In: 2014. url: http : / / www . pds . ewi . tudelft . nl / ~iosup /
Benchmarking - IaaSPaaS - Graph - Analytics14WBDB . pdf (besucht am 28. Februar
2016).
[14]
Neo Technology. Neo4J Fact Sheet. url: http://info.neo4j.com/rs/neotechnology/
images/neo4j-factsheet.pdf (besucht am 28. Februar 2016).
[15]
Neo Technology. Neo4j Customer Success Stories and Case Studies. url: http : / /
neo4j.com/customers/ (besucht am 28. Februar 2016).
[16]
OrientDB Ltd. OrientDB Manual-version 2.0. url: http : / / orientdb . com / docs /
last/OrientDB-Manual.pdf (besucht am 28. Februar 2016).
[17]
Benjamin Schiller und Thorsten Strufe. „Dynamic Network Analyzer Building a Framework for the Graph-theoretic Analysis of Dynamic Networks“. In: Proceedings of the
2013 Summer Computer Simulation Conference. SCSC ’13. Toronto, Ontario, Canada:
Society for Modeling & Simulation International, 2013, 49:1–49:6. isbn: 978-1-62748276-9. url: http://dl.acm.org/citation.cfm?id=2557696.2557750 (besucht am
28. Februar 2016).
[18]
United Nations, Population Devision, Department of Economic and Social Affairs UN.
Total Population - both sexes. 2015. url: http://esa.un.org/unpd/wpp/DVD/Files/
1_Indicators%20(Standard)/EXCEL_FILES/1_Population/WPP2015_POP_F01_1_
TOTAL_POPULATION_BOTH_SEXES.XLS (besucht am 28. Februar 2016).
[19]
lambdazen. Bitsy Wiki. url: https://bitbucket.org/lambdazen/bitsy/wiki/Home
(besucht am 28. Februar 2016).
32