Post on 11-Jun-2020
transcript
Anfrageverarbeitung im semantischen Internet of Thingsmit P2P-NetzenQuery Processing in the Semantic Internet of Things withP2P Networks
Masterarbeit
im Rahmen des StudiengangsInformatikder Universität zu Lübeck
vorgelegt vonBjörn Eberhardt
ausgegeben und betreut vonPD. Dr. rer. nat. habil. Sven Groppe
Lübeck, den 9. Januar 2014
Abstract
The Internet of Things connects physical devices to the Internet by creating a virtual represen-
tation of these. With that the amount of information that needs to be processed and transferred
increases. The idea is to put semantic information into a dynamic, server independent network,
peer-to-peer network that uses a optimzed data distribution algorithm, which allows a uniform
distribution of the information through the system. Here, each device is connected to other
devices, which build together a knowledge base. As for traditional semantic web databases,
there is no P2P distribution. This should be developed as an extension for the semantic web
database. In this new component, the query processing will be optimized, for example with
new developed distribution strategies, that allow parallel processing on other nodes in the P2P
network.
Keywords
Semantic Web, Peer-To-Peer, IoT
ii
Kurzfassung
Das Internet der Dinge (engl. Internet of Things) bezeichnet die Verknüpfung eindeutig identifi-
zierbarer physischer Objekte mit einem virtuellen, digitalen Repräsentanten. Die untereinander
vernetzten intelligenten Geräte agieren dabei im Hintergrund und nicht wie der herkömmliche
PC in der bewussten Aufmerksamkeit des Benutzers. Durch vermehrtes Aufkommen solcher
Geräte und der einhergehenden Netzwerkkommunikation, entstehen größere Datenmengen die
verwaltet und verarbeitet werden müssen. Die Idee ist es, semantische Informationen in ei-
nem serverunabhängigen dynamischen Peer-To-Peer-Netz zu hinterlegen und durch geschickte
Verteilungsalgorithmen im Netz zu verteilen. Durch die jeweiligen Informationen der vernetz-
ten Geräte entsteht dabei eine gemeinsame Wissensdatenbank. Da für herkömmliche Semantic
Web-Datenbanken keine P2P-Verteilung existiert, soll dieses als Erweiterung entwickelt wer-
den. Dabei wird die Anfrageverarbeitung mit neue Verteilungsstrategien und Optimierungen
verbessert, indem Teilberechnungen auf Knoten im P2P-Netz ausgelagert und damit parallel
berechnet werden können.
Schlüsselwörter
Semantic Web, Peer-To-Peer, IoT
iii
Inhaltsverzeichnis
1 Einleitung 11.1 Motivation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1
1.2 Ziele der Arbeit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
2 Stand der Technik und Wissenschaft 42.1 Grundbegriffe . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
2.1.1 Peer-to-Peer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
2.1.2 Semantisches Web . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
2.1.3 LuposDate . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
2.2 Stand der Technik . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
3 Konzeption 253.1 P2P-Architektur für RDF-Daten . . . . . . . . . . . . . . . . . . . . . . . . . 26
3.1.1 Architektur . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
3.1.2 Funktionalität . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
3.1.3 Zusammenfassung . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
3.2 Verteilungsstrategien . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
3.2.1 Einfache Verteilungsstrategien . . . . . . . . . . . . . . . . . . . . . . 32
3.2.2 Fortgeschrittene Verteilungsstrategien . . . . . . . . . . . . . . . . . . 37
3.2.3 Verteilungsstrategien im P2P-Netz . . . . . . . . . . . . . . . . . . . . 45
3.2.4 Grafische Darstellung der fortgeschrittenen Verteilungsstrategien . . . . 49
3.3 Parallelität bei Partitionsanfragen . . . . . . . . . . . . . . . . . . . . . . . . . 51
3.4 Optimierungsstrategien . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52
4 Realisierung 584.1 P2P-Architektur für RDF-Daten . . . . . . . . . . . . . . . . . . . . . . . . . 58
4.2 Verteilungsstrategien . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68
4.3 Parallelität bei Partitionsanfragen . . . . . . . . . . . . . . . . . . . . . . . . . 69
4.4 Abfrageauswertung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71
4.5 Optimierungsstrategien . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73
4.5.1 Vermeidung der Operation „Union“ bei einseitiger Quelle . . . . . . . 74
4.5.2 Lokaler Join von Unteroperatorgraphen gleichen Schlüssels . . . . . . 74
4.5.3 MultiInputRule . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75
4.5.4 Lokaler Join bei Partitionsanfragen . . . . . . . . . . . . . . . . . . . 76
4.5.5 Filter verschieben . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77
4.5.6 Asynchron, parallel-ausführbare Unteroperatorgraphen . . . . . . . . . 78
4.5.7 Regelwerke . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78
iv
Inhaltsverzeichnis
5 Evaluierung 805.1 Benchmark . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 80
5.1.1 SP2Bench . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 80
5.1.2 Berlin SPARQL Benchmark . . . . . . . . . . . . . . . . . . . . . . . 81
5.1.3 DBPedia . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81
5.2 Testumgebungen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82
5.3 Einfügezeiten der RDF-Daten in das P2P-Netz . . . . . . . . . . . . . . . . . . 83
5.4 Kollisionsvermeidung gleichartiger Partitionen . . . . . . . . . . . . . . . . . 85
5.5 Vergleich zwischen lokalem Join und ausgelagertem Join . . . . . . . . . . . . 86
5.5.1 Testdurchführung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 87
5.5.2 Auswertung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 89
5.6 Vergleich der Verteilungsstrategien mit TomP2P . . . . . . . . . . . . . . . . . 90
5.6.1 Testdurchführung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 90
5.6.2 Auswertung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 91
5.7 Vergleich der Verteilungsstrategien im Endpoint-Network . . . . . . . . . . . . 96
5.7.1 Testdurchführung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 96
5.7.2 Auswertung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 98
5.8 Vergleich der Verteilungsstrategien ohne Untergraphanfragen . . . . . . . . . . 103
5.8.1 Testdurchführung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 103
5.8.2 Auswertung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 106
6 Zusammenfassung und Ausblick 1086.1 Zusammenfassung der Arbeit . . . . . . . . . . . . . . . . . . . . . . . . . . . 108
6.2 Offene Punkte . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 108
6.3 Ausblick . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 110
Abbildungen 112
Tabellen 114
Quelltexte 115
Quellen 116Literatur . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 116
Glossar 122
Abkürzungen 124
Anhänge 125A Exkurs: Statistiken zum DBPedia-Dataset . . . . . . . . . . . . . . . . . . . . 125
B Exkurs: Java-Heap . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 125
C Realisierte Packages und Klassen . . . . . . . . . . . . . . . . . . . . . . . . . 127
D Übersicht der Parameter für das Konsolenprogramm . . . . . . . . . . . . . . . 129
Erklärung 131
v
1 Einleitung
In diesem Kapitel wird mit einer Motivation in das Thema eingeleitet, sowie das Thema der
Arbeit erläutert. Außerdem werden ein paar wichtige Begriffe wie auch das Thema des seman-
tischen Netzes erklärt, da diese für das Verständnis der vorliegende Arbeit unerlässlich sind
und für die weiteren Kapitel als Voraussetzung dienen (Kapitel 2).
In Kapitel 3 wird das Thema der Arbeit konzipiert, wobei zuerst die bereits vorhandenen Kom-
ponenten und Projekte analysiert werden und die Konzeption unterstützen. Nachdem die Ar-
beit theoretisch erstellt und durchdacht wurde, wird in der Realisierung (Kapitel 4) jenes Kon-
zept umgesetzt. Im Zuge des Wasserfallmodells (nach Royce, 1987) werden jedoch iterative
Nachänderungen und Verbesserungen an der Arbeit erlaubt, wenn Probleme oder neue Ideen
auftreten. Das fertig gestellte Produkt wird letztlich in Kapitel 5 evaluiert und die Ergebnisse
interpretiert. Die Arbeit endet mit einer Zusammenfassung der Ausarbeitung (Kapitel 6), sowie
einen Ausblick über weiterführende Projekte und Verbesserungen.
1.1 Motivation
1989 entwickelte der am CERN in Genf arbeitende Tim Berners Lee (Berners-Lee et al., 1992)
ein neuartiges System, das Hypertextsystem, welches im lokalen Intranet für die schnelle und
einfache Verbreitung der Forschungsergebnisse sorgen sollte. Nachdem dieses System 1991
der Öffentlichkeit vorgestellt wurde, war die Nachfrage nach einen kostengünstigem Zugang
zum Internet geweckt. Ein eigentlich für das Forschungsnetz betriebenes, weltweit verbundenes
Netz von Webservern entwickelte sich jedoch in 20 Jahren zu einem großen Kommunikations-
netz. Es sind Dienste und Anwendungen entstanden, die auch im Zuge der Entwicklung von
mobilen Endgeräten immer größere Datenmengen verarbeiten müssen, da jegliche Informatio-
nen über den digitalen Kanal ausgetauscht und auch gespeichert werden sollen. Das führt zu
einem hohen Datenaufkommen, wobei neben reinen Nutzdaten auch Statistiken eine wichtige
Rolle spielen, die vor allem finanzielle Aspekte der Datensammlung auf sich haben. Als ak-
tuelles Schlagwort wurde „Big Data“ geprägt, was nach Beyer (o.J.) vor allem folgende drei
Ausprägungen enthält: Das ansteigende Volumen der Daten, die ansteigende Geschwindigkeit,
mit der die Daten gesendet, gespeichert und verarbeitet werden sowie die dritte Ausprägung,
die steigende Vielfalt der Daten. Immer größere Datenmengen sollen unter Echtzeitbedingun-
gen verarbeitet werden und dann noch eine Vielfalt von medialen Inhalten wie Videos, Bilder
und Texte zueinander in Verbindung stellen. Diese Anforderungen sind nicht nur im Internet zu
bewältigen, sondern immer mehr auch in semantischen Netzen, die ebenfalls von Berners Lee
1
1 Einleitung
beschrieben wurden. Dabei wird das unstrukturierte Hypertextsystem um weitere Regeln zur
Strukturierung erweitert, die Zusammenhänge von Informationen beschreiben. Diese ermög-
licht es zum Beispiel die Semantik einer Internetseite durch Maschinen erkennen zu können,
was bei der Verarbeitung der Daten enorm wichtig ist, um automatisierte Schlussfolgerungen
aus den großen Datenmengen zu unterstützen, die aufgrund des Volumens von Menschenhand
manuell nicht angegangen werden kann.
1.2 Ziele der Arbeit
In dieser Arbeit sollen ebenfalls große Datenmengen, die in semantischer Art vorliegen, ver-
arbeitet werden. Bereits in dem Aufsatz „The Computer for the 21st Century“ sprach Weiser
(1991) von der Vision, dass Computer im Alltag ihre Bedeutung als Gerät verlieren und durch
eine neue Art von intelligenten Gegenständen ersetzt werden. Dabei unterstützen die neuen
Gegenstände die Tätigkeiten der Menschen, ohne dass jenes Gerät in der bewussten Aufmerk-
samkeit seines Benutzers liegt. Dieser Begriff wird »Internet of Things« (IoT), Internet der
Dinge, genannt und bezeichnet die Verknüpfung von realen, physischen Geräten zu seinem
virtuellen Repräsentanten (Ashton, 2009). Dazu zählt auch die Vernetzung der Geräte unter-
einander, wobei die Geräte selbständig in einem Netz agieren und damit einen höheren Nutzen
realisieren können, da die Kopplung von Daten aus mehreren unterschiedlichen Quellen eine
neue Schlussfolgerung ergeben kann. Dabei besteht die Herausforderung darin, die umfang-
reichen und echtzeit-kritischen Daten zu verarbeiten. Dass ein zentraler Dienst zur Verwaltung
und Speicherung der Daten keine gute Lösung ist, zeigt sich in der Problematik typischer klassi-
scher Client-Server-Architekturen. Dabei entsteht eine einseitige Abhängigkeit vom Serverbe-
treiber. Des Weiteren sind Skalierbarkeit (im Sinne der Datenhaltung) und Kosten Themen, die
beim Anbieten eines Dienstes berücksichtigt werden müssen. Vor allem bei dem Datendurch-
satz der vielen Daten müssen Vorkehrungen getroffen werden, da der Server als Flaschenhals
fungiert und sämtlicher Datenaustausch über die eine Instanz erfolgt. Ein weiteres Problem
ist ebenfalls der Single Point of Failure, sodass bei einem Ausfall des Servers die komplette
Dienstleistung nicht mehr nutzbar ist (Cikryt, 2010).
Die Idee ist, diese Daten in einem dynamischen Netz (Peer-To-Peer-Netz; vgl. Kapitel 2.1.1)
selbst zu verteilen, welches die einzelnen IoT-Geräte bereits aufspannen, wobei ein sinnvol-
les Aufteilen der Daten auf verschiedene Knoten nötig ist. Für die Verarbeitung der Daten
müssen ebenfalls schnelle und optimierte Anfragen an das Netz möglich sein. Ähnlich des
Divide and Conquer-Algorithmus (Ottmann & Widmayer, 2012) wird dabei die Anfrage an
die zuständigen Knoten unterteilt und weitergeleitet sowie das spätere Suchergebnis aus den
Einzelergebnissen zusammengefügt. Im Gegensatz zum zentralistischen Ansatz lassen sich in
dieser Architektur sowohl die Daten als auch die Berechnungen gleichmäßig verteilen, sodass
kein Flaschenhals oder Engpässe bei der Erreichbarkeit der Daten entstehen.
Dabei richtet sich die Aufgabenstellung der Arbeit darin, die etablierte, hocheffiziente Seman-
tic Web Datenbank »LuposDate« (siehe Kapitel 2.1.3) derart zu erweitern, dass beliebige Peer-
To-Peer-Architekturen implementiert und integriert werden können, wobei die semantischen
Informationen der IoT-Geräte verteilt gespeichert und Abfragen dieser Daten ermöglicht wer-
2
1 Einleitung
den. Außerdem ist eine Verteilungsstrategie der Daten zu konzipieren, die eine intelligente,
schnell verarbeitungsfähige Verteilung der Daten an die dynamisch zugeschalteten Knoten des
Peer-To-Peer-Netzwerks verteilt und für Abfragen lokalisieren kann. Die jeweiligen Abfragen
sollten dabei bezüglich der neuen Architektur optimiert werden, sodass eine effiziente Datenbe-
schaffung erfolgen kann. Im Anschluss soll das realisierte System summativ evaluiert werden;
dies geschieht mithilfe von Benchmark-Anfragen, um eine Vergleichbarkeit zu Referenzsyste-
men zu ermöglichen (Scriven, 1991).
3
2 Stand der Technik und Wissenschaft
In diesem Kapitel werden zuerst nötige Grundbegriffe und Architekturen erklärt. Anschlie-
ßend wird ein Überblick über verwandte Arbeiten und Projekte gegeben, die im Kontext dieser
Arbeit passen.
2.1 Grundbegriffe
Zuerst werden ein paar Grundbegriffe, Architekturen und Frameworks vorgestellt, die für die
Arbeit ungemein benötigt werden. Dabei wird zuerst die Architektur, sowie die Vor- und Nach-
teile von Peer-to-Peer-Systemen (P2P) präsentiert. Im Anschluss wird das Semantische Web
vorgestellt, dass einen wesentlichen Bestandteil der Arbeit darstellt, wie auch das bereits an-
gesprochene Framework »LuposDate«, in welchem die Verteiltheit mittels P2P effizient gelöst
werden kann.
2.1.1 Peer-to-Peer
Definition
Unter Peer-to-Peer (kurz: P2P) versteht man den „gleichberechtigten Zugriff aller im Netz
gekoppelter Rechner auf alle Ressourcen“ (Fischer & Hofer, 2008). Im Gegensatz zur P2P-
Architektur steht die klassische Server-Client-Architektur, wobei ein Server einen Dienst be-
reitstellt, der von mehreren Clients genutzt werden kann. Im P2P-Netz ist jeder der sogenannten
Peers (Teilnehmer) „gleichberechtigt“ an dem Netzwerk und nimmt dabei sowohl die Rolle ei-
nes Servers als auch Clients gleichzeitig ein. Die Datenverbindungen zwischen diesen Peers
dienen hierbei zum Datenaustausch, zur Kommunikation oder der Nutzung und Bereitstellung
von gemeinsamen Funktionen (Böhringer et al., 2008). Hierzu zählt auch die Verteilung von
Ressourcen, wobei hier nicht nur die angesprochenen Daten sondern auch CPU und Speicher-
platz genannt werden können (Oram, 2001), sodass z.B. rechenintensive Berechnungen im
P2P-Netz an Knoten delegiert werden können und mittels geeigneter Algorithmen das Ergeb-
nis später zusammengefügt werden kann. Ein Beispiel wäre das verteilt angelegte Projekt SE-
TI@home1, welches sich mit der Suche nach außerirdischen intelligenten Leben befasst. Neben
der angesprochenen Knotenautonomie und Gleichberechtigung der Peers ist die Dynamik in
P2P-Netzen ein wichtiger Unterschied zu Client-Server-Architekturen. In P2P-Netzen können
1http://setiathome.berkeley.edu/
4
2 Stand der Technik und Wissenschaft
Abbildung 1: Architektur von P2P Netzen
sich Peers dynamisch an- und abmelden und werden mittels temporärer Netzwerkkennung un-
tereinander bekannt gemacht, während bei einer Client-Server-Architektur die Netzwerkstruk-
tur starr ist (Oram, 2001). In Abbildung 1 wird eine Vernetzung von mehreren Peers dargestellt,
die als Graph repräsentiert werden kann. Diese Netzstruktur ist nicht an ein lokales Netzwerk
gebunden, sondern auch über Internet möglich. Da ein P2P-Netz dann eine Teilüberdeckung
des gesamten Netzes ist, spricht man von einem Overlay-Netzwerk. Bekannt geworden ist P2P
vor allem durch Filesharing. Dabei werden über das selbst-organisierende P2P-Netz bestimmte
Dateien ausgetauscht, ohne dass ein zentraler Server benötigt wird, der die Verbindungsdaten
speichert oder einer Zensur unterliegt (Becker, 2011). Die ersten P2P-Netzwerke schützten sich
vor der angesprochenen Zensur und erstellten sogenannte Newsgroups, eine reine Austausch-
plattform der freien Meinungsäußerung (Hauben et al., 1997).
Typen von P2P-Netzen
Aus technischer Sicht lassen sich P2P-Netze in mehrere Typen und Ausprägungen unterschei-
den. Zuerst werden unstrukturierte P2P-Netze betrachtet, die neben den reinen P2P-Systemen
auch in Semi-P2P-Netze (semi P2P networks) und in Semi-Zentralisierte P2P-Netze (semi cen-
tralized P2P networks) unterteilt werden (Chou et al., 2007). Bei Semi-P2P-Netzen gibt es
einen zentralen Server, der sozusagen die Verwaltung des Netzwerkes übernimmt und auch
einen Index der verfügbaren Ressourcen verwaltet. Ein Problem bei P2P-Netzen ist es, einen
Zugang in das virtuelle Netz zu erlangen, da sie autonom und selbst-organisierend sind und
mindestens ein Peer dem beitretenden Teilnehmer bekannt sein muss. Aber aufgrund der Dy-
namik im P2P-Netzwerk ist es nicht immer möglich einen festen Peer zu kennen, sodass ein
taktisches Probieren vieler Adressen nötig ist. Abhilfe schafft im Semi-P2P-Netz die zentra-
le Serverinstanz, die genau die Teilnehmer des Netzwerkes kennt und alle Anfragen an diese
delegiert. Somit läuft die Suche nach Ressourcen über den zentralen Server und nur der reine
Datenaustausch über die direkte Verbindung zweier Peers ab. Als Beispiel ist hier der Mes-
senger Skype2 zu nennen, der alle Nutzerdaten auf seinem Server vorrätig hat und für eine
2www.skype.com, Microsoft
5
2 Stand der Technik und Wissenschaft
Abbildung 2: Schema: Semi-Zentralisierte P2P-Netze mit „super nodes“
Authentisierung und Autorisierung zuständig ist. Der Nachrichtenaustausch oder die Videote-
lefonie wird jedoch grundsätzlich als Direktverbindung der beiden Teilnehmer realisiert3.
Eine andere Art von P2P-Netzen sind Semi-Zentralisierte P2P-Netze. Hier wird eine Hierarchie
im Netzwerk aufgebaut, die im Grunde der Knotenautonomie widerspricht. Knoten sind hier-
bei in Gruppen angeordnet, die einem Verwalter-Knoten (Supernode) zugeordnet sind, der die
Interaktion und Delegation übernimmt (Abbildung 2). Die letztliche Datenübertragung wür-
de dann jedoch wieder als P2P-Verbindung gestaltet. Diese Art der Netzpartitionierung dient
dazu, nicht die kleineren Peers mit Tätigkeiten wie Anfragen zu belasten, vor allem mit dem
Hintergrund, dass dessen Lebensdauer nicht langlebig ist. Nur die hochverfügbaren Supernodes
nehmen solche Anfragen entgegen und delegieren diese weiter zu den jeweiligen Zielknoten.
Die reinen bzw. auch vollständig dezentralisierten P2P-Netze hingegen kommen ohne Server
basierte Indexstrukturen und ohne Verwalter-Knoten aus. Das unstrukturierte Netz ist dabei
eine flach-hierarchische Architektur und jeder Teilnehmer gleichberechtigt und autonom. Je
nach Algorithmus werden Suchanfragen von einzelnen Peers durch das Netzwerk geflutet, bis
ein Knoten die bestimmte Ressource kennt oder sogar lokal vorrätig hat. Um das P2P-Netz
nicht zu überlasten, wird oft die Tiefe der Weiterleitungen einer Suchanfrage begrenzt (über
den TTL-Wert). Dennoch könnten bei diesen Suchanfragen Schleifen entstehen, sodass stän-
dig dieselben Knoten des Datums befragt werden oder die Tiefe der Weiterleitungen nicht
3Die Ausnahme besteht in der Aufnahme einer „Video-Offlinenachricht“, die dann serverseitig gespeichert wird,und beim nächsten Anmelden des Empfängers übertragen wird.
6
2 Stand der Technik und Wissenschaft
ausreichend groß sein, um den Zielknoten überhaupt zu erreichen. Wenn ein Knoten gefunden
wurde, welcher die Ressource, die angefragt wurde, kennt, wird über eine direkte Verbindung
zum anfragenden Teilnehmer die Ressource (oder die Kennung des Peers, der diese vorrätig
hat) ausgetauscht. Das Problem, einen Einsprungspunkt in das Netzwerk zu finden, bleibt je-
doch auch im reinen P2P-System. Entweder muss durch bloßes „anpingen“4 von Rechnern
ein Teilnehmer des P2P-Netzes erkannt werden oder es gibt z.B. über das WWW erreichbare
Listen, welche IP-Adressen von P2P-Peers beinhaltet, welche dann als Einsprungspunkt in das
P2P-Netz dienen.
Neben den unstrukturierten P2P-Netzen existieren noch strukturierte P2P-Netze, welche die
Überflutung von Anfragen im Overlay-Netz verhindern soll. Da zu viele parallel angefragte
Nachrichten das Netz und damit den Dienst des Systems blockieren, werden in strukturierten
Netzen die Daten so verteilt, dass der Zielrechner schnell aufgelöst werden kann. Dies erfolgt
mittels verteilter Hashtabellen (DHTs). Über eine Hashfunktion existiert somit eine Abbildung
zwischen einem Hashwert einer Ressource und dem Knoten des P2P-Netzes. Die Topologie
des Overlay-Netzes ergibt sich nun durch die berechneten Hashwerte, wobei in jedem Peer die
gleiche Zuordnung zwischen Hashwert und Peer-Knoten hinterlegt werden muss. Soll ein be-
stimmtes Datum im Netz gespeichert werden, ist der Hashwert dieses Datums zu berechnen.
Anhand des Hashwertes ist eine Zuordnung möglich, sodass jene Ressource dort gespeichert
wird. Die Auflösung einer Anfrage erfolgt deterministisch auf demselben Weg (Beispiel in
Abbildung 3). Somit kann diese Anfrage effizient zu dem Zielknoten geroutet (weitergelei-
tet) werden, sodass diese Architektur besser skaliert als das reine unstrukturierte P2P-Netz.
Ein Problem stellt jedoch das Mapping, also die Zuordnung zwischen Hash und Peer, dar, da
diese ständig aktualisiert werden muss, wenn neue Peers dem Netz hinzugefügt werden bzw.
Peers das Netz verlassen. Aufgrund der Dynamik des Netzes muss jede Änderung der Zu-
ordnung allen Peers mitgeteilt werden, da ansonsten eine nicht aktuelle Zuordnung zu einem
womöglich offline geschalteten Peer verläuft. Ein weiterer Nachteil ist es, dass die Volltext-
suche oder Suche der Ressource über Teilbegriffe aufgrund des Hashens nicht mehr möglich
ist, da der Hash eines Teilbegriffs des Datums im Allgemeinen auf einen anderen Peer zeigt
(hash(Hallo) 6= hash(Hal∗)). Dabei existieren jedoch weitaus effizientere Verfahren und To-
pologien, wie das in Abbildung 3 gezeigte Verfahren der Datenzuordnung. In Netzen wie CAN
(Ratnasamy et al., 2001) oder Chord (Stoica et al., 2001) existiert dabei eine Zuordnung zwi-
schen Schlüsselbereichen und Peers, welche die Dynamik des P2P-Netzes berücksichtigen.
Dabei wird ein Schlüsselraum (die Menge aller mit der Hashfunktion erstellbaren möglichen
Schlüssel) auf die vorhandene Anzahl an Peers aufgeteilt, sodass ein Peer ganze Hashbereiche
verwaltet. Auch das dynamische Hinzufügen von Peer-Knoten wird in diesen Verfahren mög-
lichst effizient gehandhabt, sodass nicht wie im einfachen Beispiel alle Peers mit den neuen
Zuordnungen informiert werden müssen. Das Wegfallen von Peers, die gerade nicht mit dem
Netz verbunden ist, wird bei CAN oder Chord insofern effizient gelöst, dass lediglich der Hash-
bereich des Peers, der weggefallen ist, neuverteilt werden muss. Dies erfolgt üblicherweise an
den Nachbarknoten der jeweiligen Topologie, die dann größere Bereiche verwalten (Bischof,
2005).
4Senden einer bestimmten Nachricht (Ping) zu einer IP-Adresse (Rechner); wenn dieser antwortet (Pong) ist derRechner online und verfügbar, ansonsten nicht erreichbar (offline).
7
2 Stand der Technik und Wissenschaft
Abbildung 3: Ein Beispiel, wie verteilte Hashtabellen funktionieren (Chou et al., 2007)
2.1.2 Semantisches Web
Ein Problem des gegenwärtigen Internets ist das schlechte Auffinden von Informationen. Das
hängt damit zusammen, dass Suchmaschinen, die Internetseiten per Volltextsuche analysieren,
in einem Such-Index abbilden und mit Beachtung einiger Metriken und Suchalgorithmen den
Such-Index nach gewünschtem Inhalt filtern (Baumgärtel, 1998). Dabei werden jedoch nur die
Syntax und die Begrifflichkeit bewertet, jedoch nicht der Kontext oder die etwaige Semantik
des Inhalts. Deshalb kam Tim Berners-Lees die Idee des semantischen Webs, einer Erwei-
terung des Internets, in dem Informationen wohldefinierte Bedeutungen haben. Das heißt, die
Informationen sollen nicht nur von dem Menschen verstanden werden, sondern auch von Com-
putern, der dann dessen Bedeutung erkennt und Zusammenhänge eigenständig herstellen kann
(Berners-Lee & Miller, 2002). Ein großes Problem bei nicht-semantischen Suchmaschinen ist
es, dass der Mensch die Suchergebnisse selbst filtern muss oder womöglich keine passenden
Suchergebnisse finden kann. Das liegt zum Beispiel daran, dass das eigentliche Suchergebnis
von Internetseiten überschüttet wird, die die enthaltenen Suchwörter öfters erhalten oder im
Kontext öfter gesucht wurden. Als Beispiel soll ein kleines Szenario dienen (Virtuelle Hoch-
schule, 2012):
Maik Hamburger ist ein renommierter Shakespeare-Kenner im deutschsprachigen
Raum und hat unter anderen den Roman Hamlet übersetzt; diese Version wird
zwar in Schauspielhäusern gespielt, ist jedoch nie öffentlich publiziert worden.
Gibt man die beiden Suchbegriffe „Hamburger“ und „Hamlet“ ein, findet man ei-
ne berühmte amerikanische Restaurantkette mit dem Namen „Hamburger Hamlet“
oder die Aufführungstermine des Stückes „Hamlet“ in „Hamburg“. Das erwarte-
te Suchergebnis ist jedoch schwer zu finden und muss überdies auch noch vom
Suchenden gefiltert werden.
8
2 Stand der Technik und Wissenschaft
In dem angesprochenen Szenario ist erkennbar, dass eine Suchmaschine nicht den Kontext der
Suche erkennt, also den Namen des Autors „Hamburger“, der das Stück Hamlet übersetzt hat.
Sie filtert lediglich ihren Suchindex nach den Begriffen und trifft dann aufgrund von eigenen
Metriken (z.B. die Häufigkeiten des Vorkommens der Begriffe auf einer Seite oder dessen Ak-
tualität) die Filterung. Sinnvoller wäre es, wenn die Suchmaschine wüsste, dass nicht die Stadt
Hamburg gemeint ist, sondern eine Person dessen Nachname so lautet. Oder dass Hamlet ein
Buch ist und keine Stadt oder die gleichnamige Theateraufführung. Mit diesen Zusatzinfor-
mationen würden die Suchergebnisse dem eigentlichen erwarteten Resultat wesentlich näher
kommen. Weitere Beispiele lassen sich durch Doppeldeutigkeiten der deutschen Sprache fin-
den. So kann „Bank“ sowohl als Geldinstitut oder auch als Sitzgelegenheit verstanden werden,
und auch eine Suche nach „Kohl“ wird sicherlich neben dem gesunden Gemüse auch den Alt-
kanzler in den Suchergebnissen erscheinen lassen.
Dazu bedarf es Konzepte, Technologien und Datenstrukturen, die eben solche Zusammenhän-
ge repräsentieren können. Vor allem im WWW als Hypermedia-Raum spielt das Verlinken von
Informationen eine sehr wichtige Rolle. Diese Verlinkungen sind jedoch an keine Attribute ge-
knüpft, sodass einer Suchmaschine der Zusammenhang von zwei Internetressourcen, wie z.B.
eine Internetseite und ein Bild, nicht klar ist. Ein sogenanntes Prädikat, z.B. „istBürgermeis-
terVon“ könnte ein Bild und die Internetpräsenz einer Gemeinde in Zusammenhang bringen.
Während Taxonomien, also die hierarchische Strukturierung von Begriffen, bereits eine Mög-
lichkeit darstellen, Kontexte herzustellen, gibt es ein viel mächtigeres Konstrukt: die Ontologie.
Dies ist eine explizite Spezifikation einer Konzeptualisierung („An ontology is an explicit spe-
cification of a conceptualization“) (Gruber, 1993). In dieser Ontologie (auch Wissensbereich
genannt) wird ein bestimmtes Weltmodell repräsentiert. Dabei findet eine Trennung zwischen
Konzept und Inhalt statt. Diese Konzepte werden Schema genannt, wohingegen die Inhalte
als Instanzen aufgefasst werden. Mit Hilfe der Konzepte, die als Regelwerk betrachtet werden
können, lassen sich Zusammenhänge zwischen Objekten des Wissensbereiches ausdrücken.
So lässt sich im erwähnten Beispiel feststellen, dass „Kohl“ eine Person ist und es eine andere
Instanz „Kohl“ gibt, die eine Unterklasse von „Gemüse“ ist.
Daten-Repräsentation in RDF
Für die Repräsentation, den Austausch, sowie die Speicherung von Daten im semantischen
Web, wird RDF verwendet. RDF steht für Resource Description Framework und wurde ur-
sprünglich vom World Wide Web Consortium (W3C) zur Beschreibung von Metadaten kon-
zipiert, hat jedoch erst im Semantischen Web große Beliebtheit gefunden. RDF ist ein Daten-
modell, das auf gerichtete Graphen basiert. Jede darstellbare Aussage wird als Tripel (auch
3-Tupel) aufgefasst, wobei die drei Einheiten solcher RDF-Daten Subjekt, Prädikat und Ob-
jekt sind. Es ist mit den gleichbenannten Satzgliedern der deutschen Sprache zu vergleichen.
Einfache Aussagen, wie „Der Baum ist blau“ lassen sich so wie folgt unterteilen in Subjekt,
Prädikat, Objekt : Baum, ist, blau. Als einfacher Graph wird das Subjekt sowie das Objekt als
Ressource (Knoten) aufgefasst und das Prädikat als Kante. Dies ist in Abbildung 4 sichtbar.
9
2 Stand der Technik und Wissenschaft
Baum blauist
Abbildung 4: Einfacher RDF-Graph mit einer Tripel-Aussage zur Beschreibung der Farbe ei-nes Baumes
RDF-Daten bestehen aus drei verschieden Bausteinen: Internationalized Resource Identifier
(IRI)5, Blank Nodes und Literale. In RDF wird eine Aussage als Subjekt, welches durch ein
Prädikat mit einem Objekt in Verbindung gebracht wird, beschrieben. IRIs dienen zur Identifi-
kation von bestimmten Ressourcen. Diese erfolgen in der Syntax von Internetadressen, wobei
diese jedoch im Gegensatz dazu nicht im Internet erreichbar sein müssen, sondern lediglich
die Struktur für die Herkunft und Eindeutigkeit der Information steht. So lassen sich die zwei
gleichlautende Subjekte wie z.B. Kohl (Gemüse) und Kohl (Altkanzler) über unterschiedli-
che IRIs unterscheiden. Eine Besonderheit stellt der sogenannte Blank Node dar, der es er-
laubt Objekte ohne Verwendung einer expliziten IRI zu bezeichnen. Der dritte Baustein von
RDF-Daten, die Literale ermöglichen es, Werte darzustellen. Dabei kann nur die Objektkom-
ponente im RDF-Tripel ein Literal sein, z.B. die Zahl „42“. Diese würde in jedem Kontext als
gleichwertige, nummerische Zahl interpretiert werden. Diese Werte lassen sich noch typisie-
ren, sodass beispielsweise der Wertetyp „Ganzzahl“ mit angegeben wird oder die Werte mit
zusätzlichen Sprachinformationen versehen werden. Formal gesehen besteht das 3-Tupel aus
{I∪B}× I×{I∪B∪L} wobei L,B, I die Menge aller Literale, Blank Nodes und IRIs darstellt.
Um die RDF-Graphen in einer Datei zu serialisieren, können verschiedene Formate gewählt
werden, wie z.B. die komplex-sprachige N3-Notation6 aus dem Jahr 1998 (Berners-Lee, 2006;
Berners-Lee & Connolly, 2008; Berners-Lee, 2000). Dabei werden Ressourcen in Spitzklam-
mern „<. . . >“ geschrieben; nur Literale sind in Anführungszeichen zu setzen. Um die Daten-
typen der Literale zu beschreiben sind wie bereits erwähnt Typisierungen möglich, sodass die
Zeichenkette „2012-08-02“ als Datum interpretiert werden kann. Dazu muss der Typ als ein-
deutige IRI zur Kennung des Datentyps mitangegeben werden. Im Beispiel des Datums:
"2012-08-02"^^<http://www.w3.org/2001/XMLSchema#date>.
Mit Hilfe von RDF-Tripeln lassen sich nun Aussagen erstellen und verknüpfen, die als Graph
dargestellt werden können. In Abbildung 5 ist ein Ausschnitt eines RDF-Graphen dargestellt,
der Aussagen über den Science-Fiction-Film Matrix in Beziehung setzt. Ein RDF-Tripel (oder
eine Aussage) besteht dabei aus zwei Knoten (Subjekt und Objekt), die mit einer Kante (Prädi-
kat) verbunden sind. Die Verknüpfung mehrerer Aussagen führt zu dem dargestellten Graphen,
wobei sich weitere Beziehungen offenbaren, die nicht direkt als RDF-Tripel formuliert wurden,
wie z.B. dass der Film Matrix unter der Regie der Geschwister Lana und Andy Wachowski ge-
leitet wurde. Ein solcher Graph kann mit neuen Informationen so beliebig erweitert werden.
Dabei fällt im angeführten Beispiel auf, dass die Verkettung der Informationen in keiner defi-
nierten Form vorgenommen wurde, sodass es für eine Maschine ohne zusätzliche Information
unmöglich ist, zu dem obigen Schluss zu kommen. Für solche Wissensrepräsentationen werden
Zusatzinformationen benötigt, die in einer Ontologie hinterlegt sind.
5In der Literatur oft mit Uniform Resource Identifier (URI) gleichgesetzt.6Es gibt auch andere Serialisierungsformate wie Turtle (Beckett & Berners-Lee, 2008) oder N-Triples (Grant &
Beckett, 2004) vom W3C.
10
2 Stand der Technik und Wissenschaft
Matrix
Keanu Reeves
mits
piel
end
Laurence Fishburnemitspielend
Wachowski-Geschwister
Regie Don Davis
Musik
Science-Fiction
Genre
Lana Wachowski
sind
Andy Wachowski
sind
Abbildung 5: RDF-Graph mit Aussagen über den Science-Fiction-Film Matrix
Datenstrukturierung in Ontologien
In einer Ontologie, einem Weltmodell, werden Begrifflichkeiten sowie Beziehungen zwischen
verschiedenen Begrifflichkeiten eines gewissen Gegenstandsbereichs formal geordnet darge-
stellt (Gruber, 1993). Dabei enthalten Ontologien Interferenz-Regeln, die der Schlussfolgerung
der einzelnen Informationen dienen, sowie Integritätsregeln für die Gewährleistung der Gültig-
keit. In Ontologien bekommen die Daten zusätzliche formale Beschreibungen, sowie Regeln
über den Zusammenhang der Daten. Dies erfolgt in Ontologien über sogenannte Klassen, Ty-
pen, Instanzen und Relationen (Eigenschaften). Relationen geben dabei an, wie zwei gleiche
Instanzen in Beziehung stehen. Instanzen repräsentieren Objekte des Weltmodells. Wichtig
sind bei Ontologien noch Vererbungen, die es ermöglichen, transitive Beziehungen herzustel-
len, und Axiome, also Aussagen, die immer wahr sind und angegeben werden müssen, weil sie
sich nicht aus vorhandenem Wissen ableiten lassen. In Abbildung 6 ist das Funktionsprinzip
einer Ontologie beschrieben, wobei die Struktur in der Ontologie anhand von Begrifflichkeiten
und deren Beziehung definiert ist. Die Vererbung ergibt sich aus den unbeschrifteten Kanten,
sodass im Beispiel Bildhauer und Kubist die Eigenschaften der Oberklasse Künstler („name“
und „vorname“) übernehmen. Aus der Aussage, dass ein Künstler ein Kunstwerk erzeugt, wird
auch, dass ein Bildhauer eine Skulptur erzeugt, wobei zwischen diesen beiden Typen jedoch
eine zusätzliche Relation „schlägt“ möglich ist. Anhand dieser Struktur ist die Möglichkeit
von Aussagen (oder RDF-Tripeln) sowie dessen Beziehung sehr eingeschränkt worden, da-
für kann mit den jeweiligen Instanzen (unten im Bild) jedoch explizit Wissen erzeugt werden.
So kann eine Maschine aufgrund der Ontologie zu dem Schluss kommen, dass in der „Gal-
leria dell’Acca demia“ Werke der beiden Künstler Santi und Buonarroti ausgestellt werden.
Zur Beschreibung von Ontologien und Weltmodellen sind formale Sprachen nötig. Zu den be-
kanntesten Ontologiesprachen zählt z.B. die „Web Ontology Language“, eine Spezifikation
des W3C, oder unter Nutzung von RDF-Daten das „Resource Description Framework Schema
(RDFS)“ (Empfehlung des W3C). Bei diesem werden die Beziehungen und Vererbungen als
11
2 Stand der Technik und Wissenschaft
Abbildung 6: Funktionsprinzip einer Ontologie anhand des Beispiels eines Museums
12
2 Stand der Technik und Wissenschaft
RDF-Tripel aufgefasst. So lässt sich der Graph aus Abbildung 6 in RDF-Aussagen überfüh-
ren, wobei spezifizierte Attribute wie z.B. subClassOf (in der Prädikat-Komponente) die
Transitivität zweier Klassen darstellt (Hitzler et al., 2007).
Daten-Abfrage
Neben der Speicherung von Aussagen ist es im Semantic Web wichtig, die gespeicherten Tri-
pel und Informationen abzufragen. In klassischen relationalen Datenbanken gibt es die Abfra-
gesprache SQL; für die semantischen Daten gibt es die an SQL angelehnte Abfragesprache
SPARQL (SPARQL Protocol And RDF Query Language). Diese wurde vom W3C 2008 als
empfohlene Anfragesprache für das Semantic Web herausgegeben (Hartmann, 2008, Seite 111)
und löst die damalige proprietäre »RDF Query Language« ab.
Während bei SQL-Anfragen in relationalen Datenbanken die Tabellenstruktur bekannt sein
muss, um die Tabellenspalten in der Anfrage zu selektieren, dient bei SPARQL-Anfragen die
Struktur von RDF-Daten für den Zugriff auf die Daten. Aufgrund der fest definierten drei
Komponente von Tripeln, beziehen sich auch die Abfragen in SPARQL auf diese. Anhand
eines Beispiels soll die Darstellung der Anfragen in SPARQL vorgestellt werden:
1 PREFIX abc: <http://example.com/exampleOntology#>
2 SELECT ?capital ?country
3 WHERE {
4 ?x abc:cityname ?capital ;
5 ?x abc:isCapitalOf ?y .
6 ?y abc:countryname ?country ;
7 ?y abc:isInContinent abc:Africa .
8 }
Der Präfix dient lediglich der Lesbarkeit, wobei in der Anfrageauswertung alle Zeichenketten
„abc:“ mit der jeweiligen definierten IRI ersetzt werden. Variablen werden in SPARQL mit
einem Fragezeichen gefolgt von einem definierbaren Variablennamen bezeichnet. Gleiche Va-
riablen repräsentieren gleiche Werte in der Anfrage. In der SELECT-Klausel sind die Variablen
vermerkt, die im Anfrageergebnis selektiert werden. Die Anfrage im gezeigten Beispiel findet
die Namen aller afrikanischen Hauptstädte (?capital) und das Land (?county), in dem sich die
jeweilige Hauptstadt befindet. Dabei werden die Variablen ?y (Instanz für das Land) und ?x (In-
stanz für die Hauptstadt) im Ergebnis nicht weiter benötigt, dienen aber hier der Repräsentation
von gleichen IRIs in der Subjekt-Komponente eines RDF-Tripels. Die dargestellte Zeile ?y
abc:isInContinent abc:Africa repräsentiert hier die RDF-Tripel, dessen Prädikat-
Komponente „abc:isInContinent“ und dessen Objekt-Komponente „abc:Africa“ ist. In dieser
Arbeit wird diese Zeile der Abfrage als Tripelmuster q=(?y,abc : isInContintent,abc : A f rika)
notiert.
13
2 Stand der Technik und Wissenschaft
Um auf bestimmte Datenmengen zurückgreifen zu können, gibt es sogenannte SPARQL-
Endpoints, die z.B. im WWW erreichbar sind. An diese Endpoints können entsprechende
SPARQL-Anfragen gestellt werden, die dann ausgeführt und das Ergebnis dargestellt wird.
Ein Beispiel für eine Datenbank mit semantischen RDF-Daten ist DBPedia7. Dabei verweist
die WWW-Adresse http://dbpedia.org/sparql auf einen SPARQL-Endpoint, der nach spezi-
fizierter Art Anfragen über die URL verarbeitet. Dabei kann dieser Dienst nur in Anspruch
genommen werden, solange der Server erreichbar ist und die Kapazität des Servers für die
Berechnung ausreicht. Sollte ein Rechner nicht erreichbar, oder die Adresse geändert worden
sein, ist über den ehemals eingerichteten Endpoint keine Abfrage mehr möglich.
Das Problem der Erreichbarkeit bzw. die Kenntnis von Endpoint-Adressen, um externe seman-
tische Datenbestände zu nutzen, kann in einem P2P-Netz vermieden werden. Hier können alle
Datenbestände auf mehreren Knoten verteilt werden, was eine Lastbalancierung und Datenver-
teilung bewirkt. Stuckenschmidt et al. (2006) sehen in dem Gebrauch einer P2P-Archtitektur
auch den Vorteil der Flexibilität. Durch die Knotenautonomität kann jeder Peer eine entspre-
chende Anfrage annehmen, sodass der Ausfall eines Knotens nicht den ganzen Dienst verhin-
dert. Außerdem lassen sich in dynamischen Netzen beliebige Datenquellen hinzufügen und
replizieren, um einen Datenverlust vorzubeugen. Das Problem von derzeitigen RDF-Speichern
mit Endpoint-Strukturen sind die Engpässe von Skalierung, Kosten und komplexere Probleme,
die sich erst während der Zeit ergeben, zum Beispiel Marktbedingungen, welche dafür sorgen,
dass Abfragen mit Kosten verbunden werden oder bestimmte Datensätze nur mit bestimmten
Berechtigungen genutzt werden könnten (Stuckenschmidt et al., 2006). Gerade die Skalierung
müsste von den einzelnen Anbietern der Endpoints geregelt werden und benötigt wiederum ge-
wisse Hardware, Kenntnisse und Arbeitskräfte zur Lastverteilung der Informationsquelle, die
mit Kosten verbunden sind. In einem P2P-Netzwerk sind mittels geeigneter Algorithmen be-
reits redundante Informationsspeicher und Lastverteilung integriert, die nicht nur dafür sorgen,
dass Ressourcen von offline geschalteten Knoten auf anderen Knoten vorhanden sind, um einen
Datenverlust oder die Nichterreichbarkeit von Informationen zu verhindern, sondern auch auf
einfachen Wegen die Dynamik und Auffindbarkeit der Datensätze bietet.
2.1.3 LuposDate
LuposDate (Logically and Physically Optimized Semantic Web Database Engines) ist eine se-
mantische Webdatenbank, welche RDF-Daten speichert, verwaltet und diese Daten über die
Abfragesprache SPARQL zugänglich macht (Groppe et al., 2009b). Das System enthält eine
Vielzahl von lokal und physisch optimierten SPARQL-Engines und auch eigene Optimierungs-
strategien und Indexierungsstrategien (Groppe et al., 2007a,b). Es enthält und unterstützt viele
Ansätze von verschiedenen RDF-Datenbanken-Bibliotheken, wie z.B. das populärste RDF-
Framework Jena8(solid IT, 2013) oder auch Index, RDF3X (Neumann & Weikum, 2010, 2008)
oder Stream. Als Ontologie-Sprache unterstützt das System sowohl OWL (Hitzler et al., 2009)
wie auch RDFS und die Regelsprache RIF-BLD. Außerdem unterstützt es die Verarbeitung der
Daten im Arbeitsspeicher, wie auch auf Auslagerungsdateien auf der Festplatte und bietet somit
7www.dbpedia.org8http://jena.sourceforge.net/
14
2 Stand der Technik und Wissenschaft
Benchmarktool Beschreibung
LUBM OWL inference benchmark, many successorsSP2B SPARQL benchmark without ontology inference, synthetical data,
but ideal for first performance tests DBPSB, no inference, real-worldqueries and data
FedBench for federated queriesSPLODGE queries generated from linked dataSRBench a benchmark for streaming SW data
Tabelle 1: Benchmark-Tools für LuposDate
die Möglichkeit, mehrere Millionen Tripel effizient zu verarbeiten (Groppe et al., 2009a), zum
Beispiel beim Joinen zweier Datenmengen. Ein weiteres Feature ist die grafische Aufbereitung
von Abfragen über SPARQL 1.1. So kann der Aufrufbaum sowie die logischen und physischen
Optimierungen im Operatorgraph dargestellt werden. LuposDate unterscheidet sich von ande-
ren Anwendungen im Semantischen Netz, da sowohl das Konzept sowie der Zusammenhang
mit den verbundenen Datenbanktechniken studiert und analysiert wurde. Auch die im Akro-
nym »LuposDate« benannten logischen und physischen Optimierungen wurden evaluiert, um
die Leistung und das Ergebnis der Datenbank sowie dessen Verarbeitung zu verbessern. An-
hand mehreren Benchmarks (vgl. Tabelle 1) und Testdaten vom W3C9 konnte gezeigt werden,
dass das System vielen Anforderungen nachkommt und effizient und optimiert arbeitet.
In Abbildung 7 wird die Architektur von LuposDate gezeigt. Dabei ist erkennbar, dass eine
strikte Aufteilung des Frameworks in „Preprocessing“, „Datamanagement“ und „Optimizati-
on“ vorgenommen wurde, sodass eine Trennung zwischen Datenspeicher (RDF-Speicher), der
Anfrageverarbeitung und der Anfrageoptimierung erkennbar ist. Dies erleichtert es, neue Kom-
ponenten und Zusatzfeatures in diesem Framework hinzuzufügen, da lediglich die zu nutzende
Teil-API studiert werden muss und durch die lose Kopplung der Systeme unabhängig vonein-
ander lauffähig sind.
2.2 Stand der Technik
In diesem Kapitel werden Projekte, Frameworks und Konzepte vorgestellt, die im gleichem
Kontext dieser Arbeit bearbeitet wurden. Aus der Analyse dieser Werke werden Schlüsse,
Ideen und Verbesserungsvorschläge hinsichtlich der zu erstellenden P2P-Integration für eine
SPARQL-Engine sowie der Verteilung von RDF-Daten in dieser Architektur einbezogen.
Vom wissenschaftlichen Kontext ist die Idee nicht neu, semantischen Inhalt in einem P2P-Netz
zur Verfügung zu stellen und Anfragen an mehreren Knoten zu beantworten, bzw. weiterzulei-
ten. Es gibt viele Ansätze von Systemen, die sich mit der Verbindung von Semantik und P2P
beschäftigen, jedoch ist der Schwerpunkt jeweils auf verschiedene Aspekte gesetzt.
9http://www.w3.org/2001/sw/DataAccess/tests/r2
15
2 Stand der Technik und Wissenschaft
Abbildung 7: Architektur von LuposDate
PEPSINT
Ein solcher Ansatz der Kopplung von semantischen Daten im P2P-Netz ist in dem Artikel
„Peer-to-Peer Semantic Integration of XML and RDF Data Sources“ (Cruz et al., 2005) zu
finden. Dort wurde ein System namens PEPSINT (PEer-to-Peer Semantic INTegration fra-
mework) entwickelt, das heterogene XML und RDF-Datenquellen in einem hybriden P2P-
Netzwerk integriert. Da PEPSINT in einem hybriden P2P-Netzwerk agiert, ist die Knotenhier-
archie in sogenannte „super peer’s“ und „peers“ unterteilt. Dabei enthalten die „super peer’s“
die globale RDF-Ontologie, während die normalen Knoten die lokalen Schemata (im Fall von
XML-Daten) und RDF-Datensätze enthalten. Während die RDF-Datensätze als gerichtete Gra-
phen repräsentiert werden können, werden in PEPSINT XML-Schemata in der Datenstruktur
Baum repräsentiert. Um in diesem Framework sowohl RDF wie auch XML-Daten vergleich-
bar zu machen, wurde ein Hilfsprogramm zur Konvertierung von XML zu RDF implementiert
(„XML to RDF wrapper“), der die hierarchische Struktur von XML als hierarchieloses, flaches
RDF darstellt. Dieses Mapping wird auf dem Knoten vollzogen, sodass am „super peer“ so-
fort das Mapping in die globale Ontologie vorgenommen werden kann. Dabei ist diese globale
Ontologie die Verwaltungsschnittstelle für Anfragen von beliebigen Clients. Diese verbinden
sich stets mit einem „super peer“, der anhand des globalen Schemata dem Client eine Sicht auf
verfügbare Daten geben kann und gleichzeitig als Vermittler wirkt. Um die Elemente in den auf
den Peers vorliegenden XML- und RDF-Daten zu repräsentieren, werden im globalen Schema
jeweils RDF-Pfadausdrücke bzw. XPath/XQuery-Ausdrücke benutzt.
16
2 Stand der Technik und Wissenschaft
Ein beispielhafter Ablauf in dem PEPSINT-Framework könnte wie folgt aussehen:
1. Ein neuer Client verbindet sich mit einem „super peer“. Er überträgt sein lokales Schema,
so dass die Informationen am „super peer“ vorliegen.
2. Ein Client stellt an dem „super peer“ eine Suchanfrage. Diese wird anhand des globalen
Schemata in mehrere neue Suchanfragen unterteilt, die im P2P-Netzwerk an die ent-
sprechenden, datenvorhaltenden Peers verteilt wird. Die Antwort wird am „super peer“
eingefangen, aufbereitet und dann zu dem anfragenden Client gesendet.
Um die Last über den „super peer“ zu vermeiden, können Anfragen lokal und parallel dazu an
einige Peers gesendet und verarbeiten werden. Diese ortsfremden Ergebnisse müssen anschlie-
ßend am „super peer“ wieder gesammelt und gemappt werden. Dort werden dann entsprechend
die Daten integriert und an den Client zurückgesendet, der die Anfrage gestellt hat (Cruz et al.,
2005).
In dem vorgestellten Projekt PEPSINT geht es vorrangig um das Thema des Mappings zwi-
schen lokalen und globalen Schemata wie auch die Übersetzung zwischen RDF-Daten und
XML-Daten, sodass aus einem RDF-Pfadausdruck das entsprechende Äquivalent als XPath-
Audruck überführt wird:
Book.booktitle⇒ /books/book/@booktitle
Dennoch ist der Ansatz des „super peers“, der globale Informationen enthält, interessant, um
auch mehrere unabhängige Datenquellen in ein und demselben P2P-Netz verwalten zu können.
So lassen sich etwa zwei verschiedene Semantische Datennetze in einem P2P-Netz integrieren,
indem ein „super peer“ als Mediator dient und zwischen den beiden Netzwerken vermittelt.
Die genaue Indizierung der Daten ist in der Arbeit aber vorenthalten.
GridVine
Genau diese Funktionalität des Auffindens von Daten im P2P-Netz durch definierte Schlüssel
wird im Ansatz von GridVine(Aberer et al., 2004) benutzt. GridVine basiert auf P-Grid, ein
selbst-organisierendes strukturiertes P2P-System, dass sich von anderen strukturierten P2P-
Systemen wie Chord10 dahingehend unterscheidet, da es datenorientiert konzipiert wurde (Ali-
ma et al., 2004). Bei P-Grid werden die Peers in einer Baumstruktur angeordnet, wobei das
Routing im Netzwerk durch den binären Schlüssel determiniert ist. Durch die rekursive Un-
terteilung des Schlüsselraumes entstehen Partitionen, welche die annähernd selbe Anzahl von
Schlüsseln enthalten. Außerdem bestimmt der binäre Schlüssel den Weg durch die Baumstruk-
tur, sodass im Schlüsselraum (0,1], der linke Teilast mit der ersten Bitstelle 0 erreicht wird und
der rechte entsprechend mit der 1. In der zweiten Ebene wird der linke Weg mit dem gesamten
binären Schlüssel 00 erreicht, usw. Dieses Verfahren wird bei der Huffman-Codierung (vgl.
Huffman, 1952) verwendet und ist präfixfrei, d.h. dass der Weg durch den Baum durch den
Schlüssel eindeutig definiert ist und nicht Teil eines anderen Pfades sein kann (Cormen et al.,
2001). So kann nach Präfixen gesucht werden, was bei RDF-Tripeln von Nutzen sein könnte, da
die Suche entsprechend nach Subjekt, Prädikat und Objekt oder Verknüpfungen dieser erfolgen
10Chord basiert auf eine verteilte Hashtabelle, die für ein Mapping zwischen Datenschlüssel und dem Peer sorgt,auf dem das Datum vorrätig ist.
17
2 Stand der Technik und Wissenschaft
kann. Des Weiteren unterstützt P-Grid unter anderem Lastbalancierung, d.h. dass unterforderte
Peers nach Peers suchen, die momentan überlastet sind und sich die Baumstruktur durch die
Verweise zu Kindknoten (bzw. mögliche Routingpfade) ständig anpasst. Der Vorteil von P-
Grid liegt auch bei der Effizienz der Allokation der Daten bei Bereichsanfragen, die durch die
Datenstruktur vorgegeben sind und auch dafür sorgt, dass Suchanfragen effizient geroutet und
der Nachrichtenaufwand minimal gehalten werden kann. Ein Gütekriterium eines P2P-Netzes
ist die Churn rate (Abwanderungsrate), welche die Dynamik ausdrückt, die dem System un-
terliegt. Dazu zählt das Hinzu- und Abschalten von Peers sowie die Umverteilung der Daten,
sodass kein Datenverlust entsteht. Je höher diese Rate ist, desto schwerer wird es, das Netzwerk
konsistent zu halten (Rhea et al., 2004a). Da dieses Kriterium auf die Stabilität des Systems
schließt und das Verhalten beim Hinzufügen oder Abmelden eines Peers bei P-Grid aufgrund
der Baumstruktur aufwändig ist, wurden in dieser Datenstruktur Mehrfachverweise erlaubt,
d.h. mehrere Peers können auf Teilbäume zugewiesen werden (Mahlmann & Schindelhauer,
2007, S. 161f). GridVine setzt auf dieses P2P-System auf und versucht sowohl Daten (hier:
RDF-Tripel) wie auch Schemata (hier: RDFS) in P-Grid zu integrieren und diese später effi-
zient im Netz routbar zu machen. Jedes Blatt im P-Grid-Baum, das in dem Fall von GridVine
binär ist, wird einem Peer zugeordnet, wobei das Blatt durch die binäre Repräsentation des ein-
deutigen Pfades gekennzeichnet ist (vgl. oben genannte Huffman-Codierung). Der Trick liegt
nun in der Präfixfreiheit. Jeder Peer speichert in eigenen Routingtabellen für jedes Präfix jeder
möglichen Länge, Verweise zu anderen Peers, die die Eigenschaft besitzen, dass dessen Präfix
der gleichen Länge genau in der letzten Bitposition invertiert wurde (Aberer et al., 2004). Es gilt
folgender Algorithmus, der für einen Peer n eine Routingtabelle berechnet und bestimmten Prä-
fixen p eine Menge von Peers zuordnet, an die entsprechende Anfragen weitergeleitet werden.
Data : Peer n as binary path bn
Result : Map< prefix, Set<Peers> >
forall the prefix p in binary path representation from n with length l (p = π(bn, l)) doSearch for peers q (with binary path bq), where r = π(bq, l)) and p only differs in the
last bit position;
Store the found peers q by the prefix p;
end
In Abbildung 8 wird dieses anhand eines Beispiels kurz skizziert. Das Abfragen eines be-
stimmten Schlüssels ist, wenn der Baum ausgeglichen ist, in der Zeit O(log|π|) zu bewälti-
gen, da mittels der Routingtabelle eines jeden Peers der Suchpfad definiert ist und die Län-
ge abhängig ist von der Schlüssellänge. Eine nicht-uniform verteilte Hashfunktion wird be-
nutzt, um die Ordnung der Daten zu erhalten. Dadurch ist es möglich, effiziente Bereichs-
anfragen zu realisieren. (Aberer et al., 2004). Dies würde bedeuten, dass die Hashwerte der
beiden Daten „Müllmann“ und „Müll“ eine gewisse Ähnlichkeit aufwiesen, sodass sie bis zu
einer gewissen Stelle dasselbe Präfix im Hashwert / Schlüssel haben, und damit bestimmte
Bereiche der Daten durchsucht werden können. Es bleibt jedoch immer noch das Problem,
RDF-Tripel in GridVine einzusetzen, da eine Hashfunktion aus dem gesamten Tripel, beste-
hend aus Subjekt, Prädikat und Objekt, einen Schlüssel generiert. Der Hashwert einer Abfrage,
die dieses Datum als RDF-Anfrage lediglich mittels übereinstimmenden Prädikats sucht, ist
ein normalerweise vollkommen anderer und auch mit Hilfe von ordnungserhaltenden Hash-
18
2 Stand der Technik und Wissenschaft
Peer1
Peer2 Peer3
Peer4 Peer5
Peer6
0 1
0 1
0 1 0 1
0 1
Abbildung 8: Beispiel-Baum im P2P-Framework P-Grid/GridVineDer Peer 4 hat durch den präfixfreien Pfad die Repräsentation „1100“. In sei-ner Routingtabelle enthält der folgende Verweise, nach absteigender Präfixlängesortiert: p1 = 1100 = π(1100,4) zeigt nach Peer 5 (1101 = π(1101,4)), p2 =110 = π(1100,3) zeigt nach Peer 6 (111 = π(111,3)), p3 = 11 = π(1100,2)zeigt nach Peer 2 (10 = π(100,2)) und Peer 3 (10 = π(101,2)).
funktionen zu realisieren: So lassen sich die Hashwerte von <Bauer> <sucht> <Frau>
und der angedeuteten Abfrage ?x <sucht> ?y nicht aufeinander schließen, da hier je nach
Hashfunktion lediglich eine Übereinstimmung in der Mitte des Schlüssels auffindbar wäre, das
entsprechende Suchen von diesen Zeichenketten jedoch nicht mehr effizient gestaltet werden
kann. Deshalb wird in GridVine das RDF-Tripel drei Mal im P2P-Netz gespeichert, wobei
jeweils Prädikat-, Subjekt- sowie Objektkomponente als Schlüssel dienen, bzw. dessen Has-
hwerte (insert(hash(S), t), insert(hash(P), t), insert(hash(O), t) mit t = Triple). Bei der Ab-
frage von dem eben gezeigten Beispiel mit zwei ungebundenen Variablen, wird das Prädikat
anhand seines Hashwertes gesucht. Bei einer ungebundenen Variable müssen dabei die beiden
festen Tripelkomponenten mittels Hash gesucht und die Ergebnisse mit der Anfrage überprüft
werden, da die Verbindungen „Subjekt-Prädikat“, „Subjekt-Objekt“ etc. nicht als Hashwert im
System hinterlegt wurden.
Insgesamt ist das Projekt GridVine ein interessant nutzbares Framework, weil es die Struktur
der gespeicherten Informationen und Hashes verbirgt und eine Abstraktion zwischen physi-
schem Layer und der darauf liegenden logischen Ebene bietet, sodass der letztliche Anwender
lediglich seine Datenstruktur (hier: RDF und RDFS) in das P2P-Netz verteilt. Außerdem wur-
de, im Gegensatz zu PEPSINT, eine gute Struktur für die Autonomie und Selbstorganisation
der Architektur gewählt, in dem Fall das P-Grid, dessen (Such-)Kosten in der Menge von Peers
logarithmisch wächst (vgl. Aberer et al., 2004). Ein Nachteil, das bei GridVine bereits kurz no-
tiert wurde, ist das Problem der Ausfallsicherheit, sprich die Kosten bei einer Umorganisierung
des in der Architektur berücksichtigen Binärbaumes beim Ausfall eines Peers. Da ein P2P-Netz
vor Ausfällen von Peers nicht geschützt ist, sollte dieses Problem vorrangig bedacht werden.
Auch ob eine Anfrage mit zwei Komponenten effizient berechnet werden kann, ist zu unter-
suchen, da eine direkte Auflösung der Tripel nicht möglich ist, weil es keinen entsprechenden
Hashwert der beiden gegebenen Komponenten gibt.
19
2 Stand der Technik und Wissenschaft
RDFPeer
Das laut Publikation erste P2P-System, das das Verteilen von semantischen Informationen mit
Nutzung einer verteilten Hashtabelle (DHT) realisierte, ist RDFPeer (Cai & Frank, 2004). Es
nutzt dabei die Architektur MAAN (Cai et al., 2004), welches als Erweiterung von Chord (Stoi-
ca et al., 2001) dient und das Netz in Form eines Ringes organisiert (Ring-Topologie). Dabei
kennt ein Peer die Vor- und Nachfolger in der Ringstruktur, sowie logarithmisch viele Verbin-
dungen (sog. fingers) zu Folgeknoten, die sich wie folgt berechnen lassen: n+2i+1mod N; wo-
bei n die aktuelle Knotennummer des Peers und N die Anzahl der verfügbaren Peers darstellt.
Wie bei GridVine werden die RDF-Tripel nach allen Komponenten gehasht in die Hashtabelle
eingefügt. Jedem Knoten in der Ringstruktur wir ein Hashbereich zugeteilt, für dessen Organi-
sation der Daten er zuständig ist. Das Auffinden der Daten bei der Abfrage erfolgt dabei mittels
des Hashwertes. Dieser gibt als Ergebnis sofort den Peer an, der den gewünschten Schlüssel
vorhält. Somit lassen sich alle atomaren Anfragen11 in maximal O(log(N)) hops beantworten;
Anfragen der Form q = (?x,?y,?z)12 in höchstens N Schritten. In Abbildung 9 wird ein Bei-
spiel von RDFPeer dargestellt, wobei zur Demonstration ein kleiner Abbildungsraum gewählt
wurde. In der Realität werden Adressbereiche ≥ 128bit gewählt (Cai & Frank, 2004), z.B. der
SHA-1 (Secure Hash Algorithm) mit 160 bit.
Abbildung 9: Verteilung von RDF-Daten in RDFPeer mit 8 Knoten und einem Adressbereichvon 4bit (=max. 16 Peers möglich), nach Cai & Frank (2004)
11Anfragen mit mindestens einer konstanten Komponente12Tripelmuster ohne konstanter Komponente; besteht nur aus Variablen
20
2 Stand der Technik und Wissenschaft
Der Vorteil von RDFPeer ist die Ausnutzung der P2P-Architektur von Chord/MAAN, die als
Ring organisiert ist. Dabei ist das Lokalisieren von Tripeln über dessen Hash in logarithmischer
Zeit möglich. Vor allem die Berechnungen mit der Ringstruktur von RDFPeer lassen sich durch
die mathematischen Operation „Modulo“ (Euklidischer Ring) berechnen. Diese Funktionalität
wird auch in der Hashfunktionen genutzt, um eine disjunkte Abbildung beliebiger Eingaben
(Hashwerte) auf einen fest definierten Abbildungsbereich zu verteilen (Kaplan, 2005). Damit
lässt sich ein beliebig langes Datum in einen Hashwert überführen, der angibt, auf welchen Peer
in der Ringstruktur das Datum gespeichert und verwaltet wird. Eine Ausfallsicherheit lässt sich
erreichen, indem pro Einfügung n Kopien in weiteren n Peers angelegt werden. Dabei muss die
Berechnung der Peers, welche Kopien eines Datums beinhalten, an jedem Knoten ermöglicht
werden (statische, deterministische Auflösung). Sollte ein Peer ausfallen, kann anhand des Da-
tums ein Peer ermittelt werden, welcher eine Kopie der Information verwaltet. Ein weiterer
Vorteil in der Struktur von Chord findet sich in der Dynamik des Netzwerkes, weil bei einem
Verlassen bzw. Hinzufügen von Knoten jeweils die Hashbereiche der jeweiligen Ring-Knoten
neu aufgeteilt und deren Daten umstrukturiert werden müssen (Stoica et al., 2003). Dieser Be-
reich wird bei Chord auf den zwei Nachbarknoten der Ringstruktur neu aufgeteilt, da durch die
konsistente Hash-Funktion, die Anzahl der Neuzuordnungen minimiert werden (Karger et al.,
1997). Bei einer allgemeinen (inkonsistenten) Hashfunktion x∗ pmod n müssten hingegen alle
Daten neu aufgeteilt werden.
Dieser Vorteil der P2P-Topologie Chord ist bei der Integration in eine SPARQL-Engine zu
bedenken, weil dabei sowohl Parameter wie Ausfallsicherheit, Duplikate über Kopien sowie
logarithmisches Lokalisieren von Daten bedacht sind. Ob die Verteilungsstrategie, die auch in
GridVine Verwendung findet, optimal ist, muss später analysiert werden. Dabei erlauben An-
fragen mit zwei festen Komponenten keine direkte Lokalisierung der Daten, da ein eingefügtes
Tripel lediglich unter den Hashwerten der einzelnen Tripel-Komponenten verteilt ist.
PAGE
Eine andere Verteilungsstrategie stellt PAGE (Put And Get Everywhere) von Valle et al. (2006)
dar. Im Gegensatz zu GridVine und RDFPeer wird beim Einfügen und Abfragen nicht nur
der Hash der einzelnen Komponenten eines RDF-Tripels als Schlüssel verwendet, sondern ei-
ne Indexierung gewählt, die sich im Schlüssel kodiert wiederfindet. In PAGE wird das RDF-
Tripel um eine Komponente (C) erweitert, welches den Kontext des Datums wie die Datei oder
das Repository des Datums beschreibt. Hierbei wird jedes Quadrupel (Tripel + Kontext =
(S,P,O,C)) sechsfach indiziert (bei GridVine lediglich dreifach), wobei die Kombinationen
SPOC, CP, OCS, POC, CSP und OS im Schlüssel kodiert werden13. Zur Verdeutlichung soll
in einem Beispiel das Quadrupel (x,y,z,w) gespeichert werden, wobei die Hashwerte hier
hash(x) = 1, hash(y) = 4, hash(z) = B, hash(w) = 8 sind. Die 6 Indizierungskombinationen
sind ebenfalls kodiert, während die Kodierung idx(SPOC) = 1, idx(CP) = 3, idx(OCS) = 5,
. . . , idx(OS) = C fest gewählt sein muss. Um das angegebene Quadrupel zu speichern, wird
13Eigentlich sind die Kombinationen SPOC, CPSO, OCSP, POCS, CSPO und OSPC; die fehlenden Buchstabenergeben sich aus den restlichen, noch nicht angegebene reihenfolgeerhaltenden Komponenten, die ebenfalls inden Schlüssel eingehen.
21
2 Stand der Technik und Wissenschaft
der Index der Indizierungskombination konkateniert mit dem Hashwert als Schlüssel verwen-
det. Im Beispiel wird das Tripel mit der Indizierung SPOC unter 114B8 gespeichert (1 für
idx(SPOC), 14B8 für die jeweiligen Hashes aus x,y,z und w), bzw. dem Knoten, der am dich-
testen an diesem Wert liegt (z.B. durch Hamming-Abstand berechenbar). Dies erfolgt sechs-
fach mit allen Index-Kombinationen (bei CP, erfolgt die Kodierung aus der Konkatenation aus
idx(CP),hash(C),hash(P),hash(S),hash(O)). Um die Abfrage in PAGE aufzulösen, ist das
Anfragemuster entsprechend einer passenden Index-Kombination zu erstellen. Mit Berücksich-
tigung des obigen Beispiels würde eine Anfrage q = (x,y,?,?) mit festem Subjekt und Prädikat
über die Indizierungskombination SPOC aufgelöst (idx(SPOC) = 1) werden. Als Schlüssel er-
gibt sich dann 11400/3, wobei nicht gegebene Informationen mit 0 beschrieben werden. Ähn-
lich der Darstellung der Subnetzmaske bei IPv4, gibt hier die 3 an, dass die ersten drei Stellen
fix sind. Um die gegebene Anfrage zu beantworten, müssen nun alle Knoten anhand des Präfix
abgefragt werden (Filali et al., 2011), also dem Bereich 11400-114FF. PAGE basiert auf eine
verteilte Hashtabelle, die auf Bamboo (Rhea et al., 2004b) aufbaut und eine Verbesserung von
Routing und Nachbarschaftsgeometrien (basierend auf Chord) aufweist. Dennoch unterstützt
das Open-Source-Projekt Bamboo keine Bereichsabfragen, weshalb die Funktionalität nachim-
plementiert und der Routingalgorithmus entsprechend erweitert wurde (Valle et al., 2006).
Der Ansatz von PAGE zeigt, dass über die herkömmliche Art der Tripel-Speicherung über die
jeweiligen Hashes der Komponenten auch andere Verteilungsstrategien möglich sind. Das Pro-
blem bei der Indizierung ist jedoch, dass die statische Kodierung der Indizierungskomponen-
ten den Adressbereich stark einschränkt. Dabei müssen die Präfixe der sechs Kombinationen
gleichverteilt auf dem Schlüsselraum liegen; diese lassen sich bei Vergrößerung des Schlüssel-
raums jedoch nicht dynamisch anpassen. Dennoch erscheint die Verteilungsstrategie interessant
und erlaubt durch die vorgegebenen Kombinationen alle Anfragetypen zu beantworten, auch
wenn eine sechsfache Speicherung der Daten erfolgen muss.
FedX
FedX ist ein Framework, das es erlaubt, mehrere verbundenen Datenquellen transparent14 zu
nutzen. Es beinhaltet viele Optimierungstechniken; die Anfrageverarbeitung ist hoch skalier-
bar (Schwarte et al., 2011). Während die Anfrageverarbeitung von semantischen Informationen
über RDF vorwiegend lokal ausgeführt wird, fährt FedX einen föderativen Weg, um dezentra-
lisiert mehrere RDF-Speicher zu nutzen und die Suche effizient auf verschiedene Knoten zu
verteilen. In der »Linked Open Data«15 gibt es bereits eine Vielzahl von semantischen Daten,
die mit RDF-Verweisen verlinkt sind, wobei eine Abfrage jedoch dazu führt, die Daten in ei-
nem lokalen, temporären Speicher zu lagern und dort die Daten entsprechend zu integrieren,
da die meisten Endpoints SPARQL verstehen. In diesem Protokoll ist jedoch das föderierte
Suchen nicht integriert und ob eine Erweiterung des Protokolls in den Endpoints Einzug finden
wird, ist abzuwarten. Deshalb wurde als Lösung des Problems das Framework FedX konzi-
piert, welches genau diesen Umweg des lokalen Speichers beim Nutzen von verschiedenen
Datenquellen verhindert, bzw. effektiv löst (Schwarte et al., 2011). Dafür baut FedX auf dem
14Ohne dass dem Benutzer die Verteiltheit der Daten bewusst wird.15Teil des semantischen Netzes; Verlinkung von semantischen Inhalten (über URIs) in RDF.
22
2 Stand der Technik und Wissenschaft
Framework Sesame16 (Broekstra et al., 2002) auf, das es erlaubt, beliebige Datenquellen/Repo-
sitories (RDF-Stores) anzubinden und abzufragen. Bei FedX werden SPARQL-Endpoints (via
HTTP-Schnittstelle) nativ unterstützt. Bei anderen Repositories muss lediglich ein bestimmtes
Interface implementiert werden, dass für die Ansteuerung der Datenquelle nötig ist bzw. eine
bestimmte API-Schnittstelle angesprochen werden, die von der SPARQL-Engine Sesame be-
reitgestellt und unterstützt wird. Sesame dient hier als Kommunikationsschicht, die Anfragen
von Anwendungen empfängt und transparent verarbeitet, sodass der eigentlichen Anwendung
verborgen bleibt, wie die Resultate angefragt, verarbeitet und ausgeliefert werden. FedX ist da-
bei der „Federation Layer“, der für die Optimierung (Join-Reihenfolge, Gruppierung, Filter),
Statistiken (über sog. voiDs, Alexander & Hausenblas, 2009), Cache und die Infrastruktur
(Parallelität von Anfragen, Endpoint-Management) sorgt. So wird eine Suchanfrage (Query)
einer Anwendung von Sesame empfangen und an die darunter liegende Schicht, FedX, wei-
tergegeben. FedX zerlegt die Anfrage in entsprechende Teilanfragen, die bestimmten zuvor
konfigurierten Datenquellen gesendet werden. FedX erstellt mittels eines Ausführungsplans
einen Operatorgraphen und optimiert diesen anhand der vorliegenden Daten und Statistiken.
Im Gegensatz zur herkömmlichen Methode der Selbstverwaltung von Anfrageverarbeitung und
-optimierung mehrerer verschiedener Datenquellen wurde gezeigt, das durch FedX die Perfor-
mance stark gestiegen ist (Schwarte et al., 2011).
Fallstudie 12/13
Eine erste Möglichkeit der Realisierung einer P2P-Architektur im Zusammenhang mit dem
Framework LuposDate wurde im Rahmen einer Fallstudie an der Universität zu Lübeck er-
stellt17, die im Jahr 2012/2013 damit begonnen hat, eine Grundlage zu schaffen, in LuposDate
eine horizontale Skalierung über eine dynamische Anzahl von Knoten zu ermöglichen. Dabei
stand als Anforderung, dass an einem Master-Knoten eine entsprechende SPARQL-Anfrage
angenommen werden kann und im P2P-Netzwerk verarbeitet wird. Je nach Anfrage wird eine
Optimierung vorgenommen, die dafür sorgt, dass die Anfrage in einen Operatorgraph über-
führt wird, entsprechende Untergraphen an die entsprechenden zuständigen Knoten weiterge-
leitet werden und das Gesamtergebnis dann von den angefragten Knoten zurückgeliefert und
aufbereitet wird (David et al., 2013). Dabei basiert diese Implementation auf TomPeer2Peer18,
welche auf die verteilte Hashtabelle „Kademlia“ basiert und die Grundfunktionalität eines P2P-
Systems zur Verfügung stellt (Bocek, 2013a). Dazu zählt unter anderem das Senden von Nach-
richten im P2P-System sowie das Einfügen, Abfragen und Löschen von Daten. Außerdem sorgt
es für die Umverteilung der Daten, ohne dass sich der Entwickler darum kümmern muss – er
kann jedoch diese Funktionalität durch Parameter verändern. So wird beim Zuschalten eines
neuen Peers diesem ein Bereich zugeteilt, dessen Daten er verwalten muss. Dazu werden die
entsprechenden Daten im System zu dem neuen Knoten umverteilt. Ebenso wird beim Abmel-
den eines Peers aus dem P2P-System eine Umverteilung und Neuzuordnung der verbleibenden
Knoten vorgenommen, um Datenverlust vorzubeugen.
16http://www.openrdf.org/17https://github.com/mariodavid/Fallstudie121318http://www.tomp2p.net/
23
2 Stand der Technik und Wissenschaft
Das Problem an der Arbeit dieser Fallstudie liegt darin, dass als Ausgangspunkt zwar das
LuposDate-Framework verwendet wurde, die Anbindung jedoch nicht an dessen Programmier-
schnittstelle (API) angepasst ist. So werden Optimierungsstrategien und Ansätze der Datenver-
waltung von LuposDate verwendet, jedoch so umgeschrieben, dass sie in den Nutzungskon-
text eines verteilten P2P-Systems passen. Die Verarbeitung der RDF-Daten geschieht bei der
Fallstudie in eigenen Datenstrukturen, ebenso das Ansprechen des P2P-Systems sowie dessen
Management, wie das Halten der Verbindung zu den Peers oder das Bilden des Operatorgraphs
und dessen Verteilung im P2P-System.
Decent Sparql
Ein weiteres Projekt ist Decent Sparql19, das vom Institut für Telematik an der Universität
zu Lübeck als Erweiterung des zuvor beschriebenen Projektes der Fallstudie erstellt wurde.
Dabei wurde versucht die Schnittstelle zu dem P2P-System zu abstrahieren, sodass beliebige
Implementierungen von P2P-Systemen möglich sind. Neben dem angesprochenen P2P-System
TomP2P unterstützt Decent Sparql auch eine modifizierte Version20 von Chordless21, die auf
die P2P-Topologie Chord basiert. Decent Sparql soll jedoch mit beliebigen P2P-Systemen aus-
kommen, die die Grundfunktionalität einer verteilten Hashtabelle (DHT) bereitstellt. Es wurde
das Projekt der Fallstudie hinsichtlich Schnittstellen und Abstraktionen erweitert, die eben jene
Integration erlaubt. Außerdem lassen sich die Anfragen über die Kommandozeile abarbeiten,
sodass ein einfaches Testen der Funktionalität von neuen Verteilungsstrategien oder Optimie-
rungsstrategien in der Anfrage möglich ist. Wie auch bei der Fallstudie bemängelt, werden
lediglich Datenstrukturen von LuposDate verwendet, aber die Anbindung nicht an dessen API
gebunden. Außerdem wurde in Decent Sparql eine neue Struktur des Projektes erstellt, die
auf die Datenstrukturen der Guice API22 von Google basiert und mit Services und Modulen
realisiert wurde, die in LuposDate nicht verwendet werden können, da sie die Architektur des
Framework widersprächen.
19https://github.com/itm/decentsparql20https://github.com/rwglab/p2p-triplestore21http://sourceforge.net/projects/chordless/22https://code.google.com/p/google-guice/
24
3 Konzeption
Wie bereits in den „Zielen der Arbeit“ (Kapitel 1.2) beschrieben, soll in dieser Arbeit eine
SPARQL-Engine erweitert werden, sodass sie auf semantische Daten zugreifen kann, die in
einer dynamischen Netzstruktur, dem P2P-Netz, gespeichert wird.
In Kapitel 3.1 wird dabei zuerst die Konzeption für die Komponente beschrieben, welche ei-
ne SPARQL-Engine mit einem beliebigen, realisierungsunabhängigen P2P-Netz koppelt. Trotz
der vorhandenen wissenschaftlichen Arbeiten, die in Kapitel 2.2 vorgestellt wurden, ist dieses
nötig, da alle Projekte den Nachteil haben, dass sie nicht beidseitig, sprich an der SPARQL-
Engine und bei der Wahl des P2P-Netzes, variabel und lose gekoppelt sind. So wurde in
GridVine zwar ein dynamisches Netz konstruiert, dass mit guten Routingalgorithmen ausge-
stattet ist, jedoch keinerlei andere P2P-Systeme zulässt, sowie Parameter wie der Ausfallsicher-
heit und Datenreplikation. Die lose Kopplung an eine abstrakte Schnittstelle, die von beliebigen
SPARQL-Engines genutzt werden kann, kann hier als Vorteil gesehen werden und wird auch
in diesem Konzept der Arbeit aufgegriffen. RDFPeer erlaubt zwar im Gegensatz zu GridVine
Ausfallsicherheit und effiziente Datenumverteilung im Netz, arbeitet hingegen auch fest ver-
ankert mit der P2P-Ring-Topologie Chord und ist diesbezüglich nicht Netz ungebunden. Das
Projekt Decent Sparql hingegen lässt im Gegensatz zu den vorigen Ansätzen die Wahl des
P2P-Systems offen, mit der Einschränkung dass strukturierte P2P-Netze, die auf DHTs basie-
ren, genutzt werden müssen. Diese Arbeit ist dennoch als eigenständiges Programm anzusehen,
das teilweise Strukturen der SPARQL-Engine LuposDate (vgl. Kapitel 2.1.3) übernommen hat,
jedoch nicht lose daran gekoppelt ist und eine derartige Verzahnung im Nachhinein nicht ein-
fach gelöst werden kann. In dieser Arbeit soll jedoch sowohl die Anbindung an jede Semantic
Webdatenbank wie auch die Wahl des zu nutzenden P2P-Systems möglich sein, sodass ein be-
liebiger Austausch möglich wird. Außerdem soll die zu konzipierende P2P-Komponente die
Strukturen und Arbeitsweise der gekoppelten Systeme verbergen, sodass dem P2P-Netz die
Funktionsweise der SPARQL-Engine unbekannt ist und die SPARQL-Engine bis auf Einstel-
lungsmöglichkeiten kein direktes Wissen über Funktionsweise des P2P-Systems hat.
In Kapitel 2.1.1 und 2.2 wurde außerdem bereits gezeigt, dass das Speichern und Abfragen
semantischer Daten in schlüsselbasierten P2P-Netzen nicht trivial ist. In Kapitel 3.2 werden
deshalb Verteilungsstrategien vorgestellt, welche für das Speichern und Abfragen von Tripeln
genutzt werden können. Diese geben an, unter welchen P2P-Schlüsseln die jeweiligen RDF-
Daten gespeichert werden und übergeben diese dann der zuvor konzipierten P2P-Komponente
der SPARQL-Engine. Bereits in dem aufgegriffenen Projekt GridVine aus Kapitel 2.2 sind ein-
fache Strategien entwickelt worden, die vor allem in Kapitel 3.2.1 näher betrachtet werden,
25
3 Konzeption
aber den Nachteil aufweisen, dass sie keine wirkliche Datenverteilung im P2P-Netz vorneh-
men, sondern die Daten lediglich über Schlüssel zugänglich machen. Das einzige Projekt, dass
sich mit einer durchdachteren Datenverteilung speziell für das dynamische P2P-Netz beschäf-
tigt hat, ist PAGE. Diese Arbeit zeigt eine direkt auf das strukturierte P2P-Netz abgestimmte
Verteilungsstrategie, wobei verschiedene Anfragetypen (Anfragen mit beliebiger Anzahl von
gegebenen Komponenten) effizient abgefragt werden können. Jedoch ist ein Nachteil dieses
Verfahrens die direkte Kodierung als Hashwert, der in der verteilten Hashtabelle eines P2P-
Systems zu nutzen ist. Hier werden dann Parameter wie Schlüsselraum und Hashbereichsgrö-
ßen direkt in der Verteilungsstrategie genutzt, was zu einer nicht gewünschten Abhängigkeit
zwischen der SPARQL-Engine und P2P-Komponente führt. Dies resultiert darin, dass in dieser
Arbeit neue Strategien entwickelt werden, die auf Schlüsselbasis in jedem beliebig großen P2P-
Netz effizient funktionieren und dennoch eine klare Trennung zwischen der SPARQL-Engine
und einer P2P-Komponente erlauben.
Da P2P-Systeme nicht nur für die Datenverteilung sondern auch für Lastverteilungen genutzt
werden können, wird in Kapitel 3.3 konzipiert, wie insbesondere Operationen der semanti-
schen Anfragesprache SPARQL auf andere Peer-Knoten berechnet werden können, die bei
paralleler Ausführung zu einer verkürzten Anfragezeit führen kann. Zudem werden in Evalua-
toren semantischer Datenbanken die jeweiligen SPARQL-Anfragen in einen Ausführungsplan
überführt, der die Reihenfolge der Abarbeitung der Operationen und der Datenbeschaffung
festlegt. Wie in klassischen Datenbanksystemen können diese Anfragen optimiert werden, so-
dass die Operationen auf das System abgestimmt und damit die gesamte Anfragezeit verkürzt
werden kann. In Kapitel 3.4 werden anhand der konzipierten Verteilungsstrategien aus Ka-
pitel 3.2 solche Optimierungen konzipiert, die in der SPARQL-Engine dazu führen, dass die
Abfragen bestmöglich auf die neuen P2P-Strukturen umgesetzt werden können. In den vor-
gestellten Arbeiten zeigte sich kein Ansatz, der eine entsprechende Last- und Datenverteilung
vornimmt. In den Arbeiten wird stets direkt mit dem P2P-Netz bzw. der verteilten Hashtabelle
gearbeitet, sodass keine Datenumverteilung nötig war. Ein großer Nachteil ist jedoch, dass so
keine Berechnungen an anderen Knoten stattfinden können und das Netz evtl. oft mit großen
Datentransfers beschäftigt ist, die zu dem anfragenden Client gesendet werden. Des Weiteren
wird das P2P-Netz in den Ansätzen lediglich als verteilter Speicher genutzt, sodass die Da-
ten verteilt unter den Knoten vorliegen. Die Berechnungen erfolgen direkt am Client, sodass
im Widerspruch eines dynamisch-autonomen Systems, die Logik am Client vorherrscht und die
anderen eigentlich gleichwertigen Knoten lediglich für die Datenspeicherung und -beschaffung
verwendet werden. In dieser Arbeit sollen jedoch alle Knoten gleichermaßen für die Datenver-
waltung wie auch die Möglichkeit der Berechnungen ausgestattet werden, was es schließlich
erlaubt, dass Teilberechnungen direkt im Netz stattfinden können und dadurch großer Daten-
transfer eingespart werden kann.
3.1 P2P-Architektur für RDF-Daten
In diesem Abschnitt werden die Anforderungen für die Integration eines P2P-Systems an ei-
ne SPARQL-Engine gestellt, welches sowohl die Wahl der SPARQL-Engine wie auch das zu
nutzende P2P-System offen lässt, und damit variabel einsatzfähig ist.
26
3 Konzeption
3.1.1 Architektur
Eine P2P-Komponente muss für eine gute Integration in eine bestehende SPARQL-Engine eine
erweiterungsfähige Struktur aufweisen, die es erlaubt Änderungen vornehmen zu können, ohne
dass eine komplett neue Anbindung realisiert werden muss. Bereits im vorgestellten Projekt
LuposDate zeigt sich eine klare Aufteilung von Komponenten, die sich mit einer API koppeln
lassen. Außerdem wird in LuposDate über Schnittstellen eine Grundfunktionalität vorgegeben,
die lediglich zu implementieren und später auch auszutauschen ist, ohne jegliche Schnittstellen
ändern zu müssen. Solch eine Struktur sollte sich auch in der P2P-Komponente widerspiegeln,
sodass beliebige P2P-Systeme zu integrieren sind, unabhängig von ihrer Realisierung. Dabei
muss eine Grundschnittstelle zur Verfügung stehen, die von allen zu implementierenden und
zukünftig zu implementierenden Systemen unterstützt werden muss.
Im Gegensatz zu den vorgestellten Projekten der Fallstudie und Decent Sparql, kann eine In-
stanz zum Halten einer P2P-Verbindung nicht an die jeweiligen Datenstrukturen der SPARQL-
Engine übergeben werden, da diese weder vorgesehen sind, noch jedes P2P-System eigene
Objekttypen und Klassen besitzt, und keine allgemeingültige abstrahierbare Schnittstelle ge-
nutzt wird. Bereits bei den beiden in Decent Sparql genutzten P2P-Systemen (TomP2P und
Chordless) sind die internen Strukturen (eines Peer-Knotens) nicht mehr abstrahierbar, sodass
in der Anbindung darauf geachtet werden muss, dass eine Integration an eine Engine pro-
blemlos erfolgen kann, ohne dass diese explizites Wissen über die angebundenen Datentypen
und -strukturen hat. So sollte in einer SPARQL-Engine einmalig eine Schnittstelle implemen-
tiert werden, die es dann erlaubt, beliebige Objektinstanzen von P2P-Systemen aufzunehmen,
ohne dessen Anwendungsinterface kennen zu müssen. Dies wird in Abbildung 10 dargestellt,
wobei lediglich der umrahmte Bereich der SPARQL-Engine bekannt ist, und das genutzte P2P-
System sowie dessen Strukturen für die Engine nicht von belang ist.
Abbildung 10: Grundgedanke für die P2P-Anbindung in einer SPARQL-Engine, wobei dieEngine die Realisierung und die Datenstrukturen des P2P-Systems nicht kennt.
Für die P2P-Komponente sind strukturierte Netze zu benutzen. Bereits in Kapitel 2.1.1 wurde
gezeigt, dass unstrukturierte P2P-Netze den Nachteil haben, dass zu viel Nachrichtenkommu-
nikation im Netz stattfindet und kein geordnetes Verteilen der Daten geschieht. Außerdem ska-
lieren strukturierte Architekturen besser, da das Auffinden von Ressourcen effizient gestaltet
ist und die dynamischen Anpassung des Overlay-Netzes und die Kosten für eine Umvertei-
lung der Ressourcen durch konsistentes Hashen gering gehalten werden (vgl. RDFPeer aus
Kapitel 2.2). Als Grundlage des strukturierten P2P-Netzes ist deshalb eine DHT zu wählen.
27
3 Konzeption
Der Nachteil hierbei ist jedoch, dass jeweils nur Hashwerte für den Zugriff auf Daten genutzt
werden können. Dennoch zeigt sich in RDFPeer und PAGE, dass ein effizienter Zugriff auf
die Daten möglich ist, wobei sich Chord und MAAN als DHT etabliert haben. Dennoch muss
das System frei von einer festgelegten Topologie sein, sodass unabhängig davon, DHT basier-
te P2P-Netze genutzt werden können. Dies vereinfacht auch den Funktionsumfang, den die
spätere Komponente als Grundfunktionalität für Implementierungen voraussetzen muss.
3.1.2 Funktionalität
Wie bereits in der Architektur der P2P-Komponente festgelegt, sind strukturierte, auf DHT
basierende P2P-Netze für die SPARQL-Engine zu unterstützen. Zu dieser Grundfunktionali-
tät von verteilten Hashtabellen zählt das Einfügen, Löschen und Abfragen von Datensätzen
über einen Schlüssel (Hash), wobei für das Löschen zusätzlich das Datum angegeben werden
muss, da unter einem Schlüssel mehrere Daten gespeichert werden können. Der Typ des zu
speichernden Datums kann generisch gehalten sein, um es zu ermöglichen, beliebig definierte
Daten speichern zu können. Für die Anwendung mit semantischen Daten ist es aber sinnvoll
die Daten als RDF-Tripel zu hinterlegen, sodass eine SPARQL-Engine in der Grundfunktiona-
lität das Einfügen, Abfragen und Löschen von Tripeln vornehmen kann. Dabei dient die ange-
sprochene Grundfunktionalität als Mindestumfang und sollte sowohl in verteilten Hashtabellen
(DHT) sowie anderen Architekturen und Topologien vorhanden sein. Dazu zählt unter anderem
P-Grid, dass als Baum-basierende Topologie aufzufassen ist, oder Ring-Topologien wie Chord,
MAAN, Bamboo oder RDFPeers (vgl. Kapitel 2.2 und Filali et al., 2011). Somit ist es später
möglich, die kontext- und nutzungsorientierte, bestmögliche P2P-Topologie zu nutzen, um die
jeweiligen Vorteile auszunutzen. So wurde bereits gezeigt, dass vor allem Bereichsanfragen in
PAGE optimiert wurden und die Topologie Chord einfache und schnelle Schlüsselauflösungen
erzielt.
Neben dieser Grundfunktionalität, die jede DHT bereits bereitstellt, ist es notwendig eine Mög-
lichkeit zu bieten, dass Peers direkt miteinander kommunizieren können. Vor allem für das
Auslagern von Operationen einer SPARQL-Anfrage ist das Senden von Nachrichten zwischen
den Peers unerlässlich. Dies erlaubt die parallele Ausführung von Aufgaben, die auf mehrere
Knoten eines P2P-Netzwerkes verteilt werden. Solch eine Kommunikation soll auf asynchro-
nem Weg geschehen, sodass das Senden von Nachrichten nicht die Anfrageinstanz des Kno-
tens bei langen Berechnungen bis zur Antwort blockiert. Die Antwort erfolgt dabei asynchron,
sodass der Client auf die jeweilige Antwort warten muss, wobei jede Nachricht über eindeu-
tige Nachrichtennummern identifiziert werden. Außerdem liegt in dem Fall der asynchronen
Nachrichtenübermittlung der Arbeitsaufwand bei dem Client, der eine SPARQL-Anfrage ge-
stellt bekommt, sodass hier die meiste Logik vorliegen muss, und deshalb das Abhandeln von
Nachrichten erfolgen kann, ein Peer im Netz jedoch lediglich für die Datenbeschaffung und
Operationsausführung zuständig ist. Diese Voraussetzung führt dazu, dass eine entsprechende
Funktionalität für das Senden und Empfangen von Nachrichten in der P2P-Schnittstelle benö-
tigt wird. Dazu zählt das Senden und Empfangen an P2P-Schlüsseln sowie das direkte Senden
und Empfangen zwischen zwei Peerknoten (Schlüssel und Adressen basiert). Eine Methode
zum Auflösen eines Schlüssels in die entsprechende Peer-Adresse, welche diesen Schlüssel
28
3 Konzeption
verwaltet, ist ebenfalls denkbar. Das Senden von Operationen einer SPARQL-Anfrage bietet
den Vorteil, dass Berechnungen auf externe Peers ausgelagert werden können (Ali & Lausan,
2012) und sind ebenfalls beim Bilden von Joins1 von Nutzen, die dann an anderen Peers be-
rechnet werden können. So wird verhindert, dass alle Daten am anfragenden Client gesammelt
und dort berechnet werden müssen. So findet eine Leistungsausbalancierung statt, die es außer-
dem ermöglicht, viele Prozesse parallel ausführbar zu gestalten, sodass die Funktionalität der
Nachrichtenversendung im P2P-System zwingend erforderlich ist, um Optimierungen vorneh-
men zu können. Die Nachrichtenfunktionalität sollte neben dem Senden von auf Zeichenketten
basierenden Nachrichten auch strombasierte Nachrichten unterstützten, da vor allen bei großen
RDF-Datenbanken entsprechend große Ergebnismengen auftreten. Aufgrund des begrenzten
Arbeitsspeichers kann diese Datenmenge nicht als textuelle Zeichenkette übertragen werden
(Khristianov, 2013). Viele SPARQL-Engines unterstützen deshalb strombasiertes Übermitteln
von Ergebnismengen, sodass diese Funktionsanbindung ein manuellen Umwandeln von Strom
in Zeichenketten verhindern und damit den Prozess beschleunigen würde. Neben diesen sta-
tischen Daten, kann diese Funktionalität ebenfalls bei einer Verarbeitung von dynamischen
Datenquellen genutzt werden, die sogenanntes Echtzeit-Reasoning (auch Stream Reasoning)
ermöglicht (Della Valle et al., 2009). Da derzeit jedoch nicht alle P2P-Systeme diesen Nach-
richtentyp unterstützen, ist diese Funktionalität optional.
In SPARQL-Engines kann es nötig sein, dass Anfragen oder Teilanfragen nur auf den lokalen
Datenbestand ausgeführt werden. Vor allem wenn bereits klar ist, dass eine Anfrage dort verar-
beitet wird, wo auch die Daten vorliegen, braucht in diesem Fall das P2P-Netz nicht angefragt
und benutzt werden. Deshalb ist als Ergänzung der Funktionalität einer P2P-Implementierung
für eine SPARQL-Engine die Unterstützung von lokalen Speicheranfragen eines Peers zu reali-
sieren. Damit ist es möglich, die Auswertung von empfangenden Teilanfragen nur auf die lokal
an dem Knoten existenten Daten vorzunehmen. Vor allem in Topologien, welche die Auflö-
sung eines Schlüssels nicht lokal vornehmen, würde dies zu einer Belastung des Netzes führen,
wenn später der Verweis auf die Daten des lokalen Knotens zeigt. Für diesen Fall kann eine
P2P-Implementierung optional einen lokalen Evaluator oder einen lokalen RDF-Datenzugriff
erzeugen, welcher die Anfrage des Unteroperatorgraphen lediglich mit lokal vorherrschenden
Daten ausführt.
Wie bereits in der Architektur (Kapitel 3.1.1) erläutert, lassen sich beliebige P2P-Implemen-
tierungen nutzen und sollen diesbezüglich auch in der SPARQL-Engine aufgelistet und ange-
sprochen werden. Deshalb ist es notwendig, eine Verwaltungsinstanz zu implementieren, die
es erlaubt, P2P-Systeme zu integrieren, welche die erforderlichen Schnittstellen implemen-
tiert hat. Diese Verwaltungsinstanz wird dabei einerseits zur Registrierung von (neuen) P2P-
Implementierungen genutzt. Andererseits fragt die SPARQL-Engine in dieser Instanz nach, ob
es das gewünschte P2P-System gibt und erhält daraufhin eine Instanz dieses Systems, welches
in der Abfrage genutzt wird. Dieser Verwaltungsmanager ist dabei die Verbindung zwischen der
SPARQL-Engine und beliebigen P2P-Systemen, wobei die Engine über die Realisierung der
P2P-Systeme und dessen eigene Datenstrukturen keine Aussagen benötigt (vgl. Kapitel 3.1.1).
Die Identifizierung von den P2P-Implementierungen erfolgt als Zeichenkette, sodass in einer
1Das Zusammenfügen zweier Teilergebnisse, welche die gleichen Felder besitzen.
29
3 Konzeption
SPARQL-Engine lediglich diese zu konfigurieren ist, um das entsprechende P2P-System zu
nutzen. In Abbildung 11 wird der Gedanke der Verwaltungsinstanz dargestellt, welche dafür
sorgt, dass die Anbindung über Schnittstellen so erfolgt, dass die Engine lediglich die Ken-
nung des zu nutzenden P2P-Systems benötigt und dann mit diesem arbeiten kann. Außerdem
sind die jeweiligen Implementierungen mit Hilfe von Parametern zu konfigurieren. Diese op-
tionalen Parameter werden dann bei der Anfrage eines P2P-Systems an die Verwaltungsinstanz
übergeben und können von der P2P-Implementierung gelesen und für die Konfiguration ge-
nutzt werden. Die Grundeinstellungsmöglichkeiten sollte der Port sein, auf welchem der Peer
gestartet und horchen wird, sowie die Adresse und Port für einen Master-Peer, mit welchen
der neue Knoten verbunden wird, um Teilnehmer in einem bereits existierenden P2P-Netz zu
werden. Wenn die Einstellungen über Key-Value-Paare gesetzt werden, ist außerdem dafür
gesorgt, dass neue Parameter hinzugefügt werden können ohne die Schnittstellen der Engi-
ne oder der Netz-Implementierung ändern zu müssen. Sollte ein Einstellungsparameter in der
P2P-Implementierung nicht unterstützt sein, kann dieser einfach ignoriert werden.
Abbildung 11: Verwaltungsinstanz für das Verwalten von beliebigen P2P-Systemen, welchesvon einer SPARQL-Engine genutzt werden kann. Dabei sorgen Schnittstellenfür die Kommunikation und Anbindung der Engine fremden Datentypen undInstanzen
Außerdem müssen die Implementierungen verschiedene Verteilungsstrategien nutzen können,
die im folgenden Abschnitt näher betrachtet werden. Dabei wird geregelt, mit welchen Schlüs-
seln RDF-Tripel im Netz gespeichert werden. Die Verteilungsstrategien müssen dabei zwischen
dem Evaluator und dem P2P-System angebracht sein. Eine Einfügung eines Tripels führt in der
Verteilungsstrategie dazu, dass von dem Datum ein oder mehrere Schlüssel generiert werden,
unter welchen das Tripel im Netz zu speichern ist. Bei Anfragen, die ebenfalls in der Vertei-
lungsstrategie entgegen genommen werden, muss anhand des Tripelmusters der Schlüssel er-
zeugt werden, unter welchem die entsprechenden Tripel gespeichert sind. Die Abfrage erfolgt
dann am P2P-System über den Schlüssel.
30
3 Konzeption
3.1.3 Zusammenfassung
Zusammengefasst sollte die P2P-Komponente, die mit einer SPARQL-Engine gekoppelt wird,
folgende Funktionalitäten besitzen:
• Lose Kopplung zwischen P2P-System und SPARQL-Engine
• Erweiterbarkeit und einfache Anbindung neuer P2P-Systeme
• Grundschnittstelle für die SPARQL-Engine zur Kommunikation mit einer P2P-Kompo-
nente (basierend auf DHTs)
• Verwaltungszentrale, welche alle möglichen P2P-Systeme verwaltet und jeweils parame-
trisiert instanziiert und als Ansprechpartner für die Engine dient
• Senden und Empfangen von Nachrichten (Peer-gerichtet, Schlüssel-gerichtet)
• strombasierte Kommunikation für lange Nachrichten, v.a. für große Ergebnismengen
(optional)
• Lokaler Evaluator am P2P-Knoten, der lediglich mit den lokal vorhandenen Daten agiert
(optional)
• Nutzung von beliebigen Verteilungsstrategien für die Datenverteilung, die zwischen
SPARQL-Engine und der P2P-Komponente sitzt
Da dieses Konzept relativ offen für die jeweiligen Implementationen von P2P-Systemen wie
Chord, MAAN usw. ist, benötigen diese lediglich die Funktionalität von verteilten Hashtabel-
len und damit das Einfügen, Abfragen und Löschen über Schlüssel. Aufgrund der Konzeption
von Schnittstellen für die Anbindung sollten sich neue Netze deshalb leicht an eine entspre-
chende SPARQL-Engine anbinden lassen.
3.2 Verteilungsstrategien
In Kapitel 3.1 wurde die Architektur der Komponente vorgestellt, die eine SPARQL-Engine
mit einem beliebigen P2P-Netz verbindet. Die einzige Voraussetzung des Netzes ist es, dass
das P2P-System auf die Grundfunktionalität von verteilten Hashtabellen aufbaut, und somit
diese Schnittstellen bedienen kann. Das führt dazu, dass alle RDF-Daten über Schlüssel in die-
sem Netz hinterlegt werden müssen. In Kapitel 2.1.1 wurde bereits angesprochen, dass stets ein
Faktor weniger effizient genutzt werden kann: In unstrukturierten P2P-Netzen skaliert die Ver-
teilung und das Suchen von Ressourcen nicht, da große Teile des Netzes mit entsprechenden
Anfragenachrichten belastet werden. Dennoch ließen sich in solchen Systemen die Ressourcen
gut suchen, wobei Volltextsuche oder Teilbegriffe für die richtige Auflösung der entsprechen-
den Daten genutzt werden konnten. Strukturierte Netze hingegen skalieren und ermöglichen
direktes Routing zu dem entsprechend gesuchten Datum, das jedoch nur über einen entspre-
chenden Schlüssel erreicht werden kann. In vielen Fällen wird der zugewiesene Schlüssel noch
intern gehasht, was zur Gleichverteilung der Hashwerte auf die gesamte Schlüsselmenge und
damit verbunden zu einer gleichmäßigen Datenverteilung auf den Peers im Netz führt. Wenn
keine interne Hashfunktion genutzt wird, werden die Daten z.B. lexikalisch verteilt. Für ei-
31
3 Konzeption
ne ausgeglichene Datenverteilung auf diese beiden Peers muss der Anfangsbuchstabe eines
Schlüssels auf dem Alphabet gleichverteilt sein, was im Allgemeinen nicht der Fall ist2, wes-
halb eine interne Hashfunktion oft zusätzlich verwendet wird.
In diesem Kapitel werden Verteilungsstrategien konzipiert, welche die RDF-Daten über Schlüs-
sel in der P2P-Komponente und dem angeschlossenen P2P-Netz verteilt. Diese Schlüssel müs-
sen dabei nicht gleichverteilt auf den der SPARQL-Engine ohnehin unbekannten Schlüssel-
raum sein, sodass hier beliebige Zeichenketten genutzt werden können. Da die DHT basierten
P2P-Netze, wie oben angesprochen, interne Verteilungshashfunktionen nutzen, ist der Schlüs-
sel und dessen Verteilung in diesem Kapitel uninteressant.
Die weiteren Abschnitte des Kapitels untergliedern sich in „Einfache Verteilungsstrategien“,
„Fortgeschrittene Verteilungsstrategien“ sowie „Verteilungsstrategien im P2P-Netz“, wobei zu-
erst die Verteilungskonzepte hinter den Verteilungsstrategien erläutert werden und dann mit
einer möglichen Problematik im P2P-Netz sowie mit der in Kapitel 3.1 konzipierten P2P-
Komponenten für SPARQL-Engines in Verbindung gebracht werden.
3.2.1 Einfache Verteilungsstrategien
Ganzes RDF-Tripel als Schlüssel
Die einfachste Idee ist sicherlich, das RDF-Tripel als Schlüssel zu verwenden, wobei die drei
Komponenten konkateniert den Schlüssel ergeben. Unter diesem Schlüssel wird dann über ei-
ne SPARQL-Engine das Tripel im P2P-Netz gespeichert und kann unter diesem auch wieder
gefunden werden. Wir nehmen hier an, das P2P-System nutzt für die interne Verteilung eine
Hashfunktion, die gemäß der Anforderungen, jeglichen Inhalt, also alle Komponenten des Tri-
pels gleichwertig berücksichtigt (Fischer et al., 1998). Dann fügen wir ein Tripel <S><P><O>
wie folgt in die verteilte Hashtabelle insert(key,value)3 und damit ins P2P-Netz ein:
insert(hash(< S >< P >< O >),< S >< P >< O >)
Das Problem bei dieser Methode ist jedoch, dass eine Anfrage q = (?x,P,O) nicht beantwortet
werden kann, da die Hashfunktion der Anfrage (hash(?x < P >< O >)) einen anderen Wert
aufweist wie das oben eingefügte Tripel. An dieses Datum kommt man jedoch nur, wenn al-
le Komponenten des Tripels bekannt sind. Es ist an diesem Beispiel gut erkennbar, dass ein
P2P-Netz in Form einer verteilten Hashtabelle für RDF-Daten auf den ersten Blick keine gute
Idee ist, da die Abfrage abhängig von den eingefügten Werten und nicht von dessen Schlüs-
seln ist. Dies liegt daran, dass die Wertepaare aus mehreren Komponenten bestehen, die für
die Anfragen einzeln betrachten werden. In Kapitel 2.2 wurde bereits auf die Problematik hin-
gewiesen, dass die Hashfunktion es nicht ermöglicht, Ähnlichkeiten im RDF-Tripel auf Ähn-
lichkeiten der Hashwerte zu übertragen, sodass diese Verteilungsstrategie im P2P-Netz nicht
praktikabel ist, da lediglich das Überprüfen, ob ein festes Datum im Netzwerk hinterlegt wur-
2Der Anfangsbuchstabe „J“ liegt im Fließtext bei einer Häufigkeit von ≤ 0.9%; das „D“ liegt bei 14,2% (Vogel-gesang, 2003)
3Zu lesen: füge in das P2P-Netz das Tripel value unter dem Schlüssel key ein.
32
3 Konzeption
de (contains(hash(< S >< P >< O >),< S >< P >< O >))4, möglich ist. Das vorhandene
Ergebnis ist vernachlässigbar, da das Datum bereits in der Anfrage bestand und ein Ergebnis
lediglich Aufschluss darauf gibt, ob das Tripel gespeichert wurde.
Vorteile Nachteile
• einfach • keine Anfragen möglich, außer die
Überprüfung, ob ein Tripel im P2P-Netz
gespeichert wurde
Komponentenweiser Schlüssel
Eine andere Möglichkeit ist das Einfügen des Tripels mit dem Hash jeder vorkommenden
Komponente (vgl. Gridvine und RDFPeer (Aberer et al., 2004; Cai & Frank, 2004)). Dies
führt im Endeffekt zum dreifachen Aufwand beim Einfügen und auch dreifacher Speicher-
platzverbrauch pro Tripel. Eine Optimierung, nur in einer gehashten Komponente das Tripel
zu speichern, und in den anderen einen Verweis zu dem Schlüssel der ersten Komponente zu
speichern, führt zwar je nach Bitlänge des Hashwertes zu einer Speicherentlastung dafür aber
zu Mehraufwand, das entsprechende Tripel aufzulösen. In dem angesprochenen Fall führt das
Einfügen eines Tripels <S><P><O> zu drei Einfügungen mit den jeweiligen Schlüsseln, bei
der jede Komponente gehasht wird:
insert(hash(< S >),< S >< P >< O >)
insert(hash(< P >),< S >< P >< O >)
insert(hash(< O >),< S >< P >< O >)
Der Vorteil hierbei ist, dass Anfragen, die sich auf eine Komponente beziehen, schnell gefunden
werden können. Hierbei muss lediglich der Hash einer in der Anfrage vorkommenden Kompo-
nente gebildet werden, um im P2P-Netz nach dem generierten Schlüssel gesucht werden. Am
Beispiel der P2P-Topologie Chord ist dies in logarithmischer Laufzeit möglich (Stoica et al.,
2003). Bei Anfragen mit zwei festen Komponenten (z.B. q = (?x, p1,o1)) erfolgt die Auflösung
entweder durch den Schlüssel hash(< P>) oder durch den Schlüssel hash(<O>). Diese Auf-
lösung betrachtet dabei jedoch alle mit diesem Prädikat bzw. Objekt gespeicherten Tripel im
P2P-Netzwerk. Diese Ergebnismenge muss in diesem Fall durchiteriert werden, wobei jedes
Ergebnis anhand der Anfrage verglichen werden muss und nicht zutreffende Daten aus der Er-
gebnismenge eliminiert werden. Dennoch zeigt sich, dass bei dieser Verteilungsmethode alle
möglichen sieben Anfragemuster beantwortet werden können (Tabelle 2).
4Zu lesen: gibt es unter dem Schlüssel hash(< S >< P >< O >) das RDF-Tripel <S><P><O>
33
3 Konzeption
Anfragemuster mögliche Schlüsselkom-binationen
nachträgliche Ergebnis-überprüfung?
<S><P><O> S, P, O Ja<?><P><O> P, O Ja<?><?><O> O Nein<?><P><?> P Nein<S><?><?> S Nein<S><P><?> S, P Ja<S><?><O> S, O Ja
Tabelle 2: Mögliche Anfragemuster sowie deren Auflösung über die möglichen Schlüsselkom-binationen der Verteilungsstrategie mit den jeweiligen Komponenten als Schlüssel
Vorteile Nachteile
• schnelles Finden von Tripeln mit Anfra-
gen, die eine feste Komponente besitzen
• 3 Schlüssel pro Tripel, damit dreifache
Datenmenge
• Anfragen mit zwei oder drei festen
Komponenten lediglich über eine Kom-
ponente auflösbar verbunden mit nach-
träglicher Eliminierung falscher Tripel
Konkatenation zweier Komponenten als Schlüssel
Um das Problem des nachträglichen Aufbereitens der Ergebnisse anhand des Anfragemusters
zu vermeiden, kann als Verteilungsstrategie ebenfalls die Konkatenation von zwei Kompo-
nenten im Hash genutzt werden, damit die Ergebnismenge bei Anfragen wesentlich optimiert
wird. Wie im voran gestellten Fall ist eine dreifache Belegung vom Speicher im P2P-System
zu verbuchen, wobei die Schlüsselkombinationen „SP“, „PO“, „SO“5 als jeweiliger Schlüssel
dienen. Vor allem wenn die Art der Anfragen a priori nicht bekannt sind, kann diese Strategie
zu Problemen führen, wenn jeweils nur nach einer Komponente gesucht wird (vgl. Tabelle 3).
Hier ist kein Rückschluss und Auflösen des Anfragemusters ausführbar, da es die Hashfunk-
tion nicht erlaubt, Komponenten im Hashwert wiederzufinden. Das Tripel t = (S,P,O), dass
über insert(hash(S+P), t) eingefügt wurde, lässt sich demnach nicht durch das Wissen von
lediglich einer Komponente, wie z.B. S auflösen, da hash(S) kein Schlüssel im Netz ist, und
hash(S) und hash(S+P) keine Ähnlichkeit aufweisen. Dennoch liefert die Ergebnismenge bei
Anfragen mit zwei gegebenen Tripel-Komponenten optimale Ergebnisse, da die Ergebnismen-
ge die Tripel enthält, die gesucht werden und keine nachträgliche iterative Überprüfung vorge-
nommen werden muss (vgl. vorige Strategie mit den Schlüsselkombinationen S, P, O). Diese
nachträgliche Datenselektion ist lediglich bei Anfragen ohne Variablen (z.B. q = (S,P,O)) nö-
tig, da die Daten über eine der drei Schlüsselpaare (S+P, P+O, S+O) aufgelöst werden müssen.
Da in dieser Verteilungsstrategie, wie in Tabelle 3 gezeigt, nicht alle möglichen Anfragen be-
antwortet werden können, ist diese Strategie nur anzuwenden, wenn es keine Anfrage gibt, die
aus lediglich einer festen Komponente besteht.
5SP steht für Subjekt+Prädikat, die Einfügung geschieht über den Schlüssel, wobei Subjekt mit Prädikat konkate-niert wird, PO steht für Prädikat+Objekt usw.
34
3 Konzeption
Anfragemuster mögliche Schlüsselkombinationen
<S><P><O> SP, PO, SO<?><P><O> PO<?><?><O> -<?><P><?> -<S><?><?> -<S><P><?> SP<S><?><O> SO
Tabelle 3: Mögliche Anfragemuster sowie deren Auflösung über die möglichen Schlüsselkom-binationen der Verteilungsstrategien, die im Schlüssel die Konkatenation zweierKomponenten beinhaltet
Vorteile Nachteile
• schnelles Finden von Tripeln mit Anfra-
gen, die zwei feste Komponente besit-
zen
• 3 Schlüssel pro Tripel, damit dreifache
Datenmenge
• Anfragen mit drei festen Komponenten
in allen drei Schlüsseln auflösbar, da-
mit evtl. Lastverteilung bei der Abfrage
möglich
• Anfragen mit drei festen Komponen-
ten über alle Schlüssel auflösbar ver-
bunden mit nachträglicher Eliminierung
falscher Tripel
• Anfragen mit einer Komponente nicht
auflösbar, daher dürfen solche Anfragen
nie auftreten
• Nur bei a priori Wissen aller Anfragen
nutzbar
Schlüssel jeder Komponente und Konkatenation zweier Komponenten
Verbindet man diese Strategie mit der vorigen, ergibt sich zusammen eine sechsfache Einfü-
gung des Tripels (Liarou et al., 2006, vgl. Spread By Value Algorithmus) mit den unterschied-
lichen Schlüsselkombinationen (S, P, O, SP, PO, SO). Würde auch das komplette RDF-Tripel
gehasht, das vor allem für eine Methode boolean contains(String key, Triple
t) sinnvoll ist, führt das Einfügen eines Tripels in das P2P-System zu dem Anlegen von sieben
Einträgen in der Hashtabelle unter den jeweiligen Schlüsseln. Hierbei ist jedoch abzuwägen,
wie oft eine entsprechende Anfrage auftritt, da immerhin Mehrkosten6 von einem zusätzlichen
Schlüssel pro eingefügten Tripel aufkommen. In Tabelle 4 zeigt sich jedoch, dass diese Vertei-
lungsstrategie alle möglichen Anfragen optimal berechnen kann, ohne dass eine nachträgliche
Eliminierung in der Ergebnismenge durchgeführt werden muss.
6Pro eingefügten Tripel muss dieses Datum unter 7 verschiedenen Schlüsseln gespeichert werden; dies führt zueiner 7-fachen Speichermenge im Netz.
35
3 Konzeption
Anfragemuster mögliche Schlüsselkombinationen
<S><P><O> SPO, SP, PO, SO, S, P, O<?><P><O> PO, P, O<?><?><O> O<?><P><?> P<S><?><?> S<S><P><?> SP, S, P<S><?><O> SO, S, O
Tabelle 4: Mögliche Anfragemuster sowie deren Auflösung über die möglichen Schlüsselkom-binationen bzw. der Schlüsselkombinationen, die keine nachträgliche Eliminierungbenötigt(hervorgehoben)
Vorteile Nachteile
• optimales Auflösen aller Anfragen
• Lastverteilung möglich, wenn eine
nachträgliche Auflösung in Kauf ge-
nommen wird, um andere Knoten zu
entlasten (z.B. bei gleichen parallel
gestellten Anfragen)
• 6 bzw. 7 Schlüssel pro Tripel, damit
vielfache Datenmenge
Zusammenfassung
Wie bereits aufgeführt, kann je nach Verteilungsstrategie, unterschiedlicher Aufwand nötig
sein, um eine Anfrage korrekt zu beantworten (vgl. auch Tabelle 5). Dabei ist eine Abwägung
zwischen Speicherplatz, Anfragekomplexität und einem eventuellen a-priori Wissen über die
Anfragen nötig.
Verteilungsstrategie Einfügungenpro Tripel
Nachteil der Methode
OneKeyDistribution(S, P, O)
3 Nachträgliche Datenselektionbei Anfragen mit mehr als zweiLiteralen, wobei alle Ergebnissedurchiteriert werden müssen
TwoKeysDistribution(SP, PO, OS)
3 Anfragen mit 2 Variablen nichtauflösbar; Datenselektion beiAnfragen ohne Variablen
ThreeKeysDistribution(SPO)
1 Anfragen mit Variablen nichtauflösbar; nur Überprüfung, obTripel vorhanden
OneToThreeKeysDistribution(S, P, O, SP, PO, OS, SPO)
7 Viele Einfügungen, aber optima-le Anfragen berechenbar, da kei-ne Nachselektion nötig
Tabelle 5: Vergleich verschiedener Verteilungsstrategien
36
3 Konzeption
Der Nachteil aller angeführten Verteilungsstrategien liegt darin, dass sie im P2P-Netz nicht
optimal verteilt werden. Zum Beispiel landen bei der Verteilungsstrategie, bei denen die drei
Komponenten einzeln als Schlüssel dienen (S, P, O), alle Tripel mit dem Prädikat „rdf:type“
im dem entsprechenden Schlüssel „rdf:type“. In DHTs werden diese Tripel letztlich jedoch an
einem Peer gespeichert, da die Zuordnung zwischen Schlüssel und Peer existiert und die Da-
tenmenge i.A. nicht berücksichtigt und verteilt wird. Bei riesigen Datenmengen sind diese auf
einem Peer zu finden, sodass auch alle entsprechenden Anfragen dort eintreffen und ausgeführt
werden müssen. Dies führt weder zu einer optimalen Datenverteilung noch zu einer Entlastung
des jeweils häufig befragten Knotens. Die Verteilungsstrategie TwoKeysDistribution (SP, PO,
OS) hingegen ist im Allgemeinen nicht nutzbar, da Anfragen, die eine feste Komponente bein-
halten sehr häufig benutzt werden (vgl. Kapitel 5.1), von der Verteilungsstrategie aber nicht
unterstützt werden. Deshalb bietet sich für den allgemeinen Einsatz nur die OneKeyDistributi-
on und OneToThreeKeysDistribution an (vgl. Tabelle 5). Im folgenden Abschnitt werden somit
neue Verteilungsstrategien entwickelt, die für eine bessere Verteilung der Daten und die besse-
re Möglichkeit der Lastverteilung sorgen, da bisher lediglich alternative Schlüssel verwendet
werden konnten, die aber zu einer nachträglichen Eliminierung in der Ergebnismenge führt
(OneToThreeKeysDistribution, siehe alternative Schlüsselpaare in Tabelle 4).
3.2.2 Fortgeschrittene Verteilungsstrategien
Wie bereits in Kapitel 3.2 beschriebenen, sorgen die beiden relevanten Verteilungsstrategien
(„OneKeyDistribution“ oder „OneToThreeKeysDistribution“) aufgrund häufig vorkommender
gleicher Schlüssel zu einem erhöhten Datenaufkommen des jeweiligen Peers und damit bei
Anfragen zu einer Mehrbelastung, da manche Schlüssel häufiger benutzt werden. Für die op-
timale Auflösung beliebiger Anfragen werden des Weiteren sechs bzw. sieben Schlüssel pro
Tripel benötigt. Dies führt zu einer entsprechend hohen Datenmenge, die im P2P-Netz gespei-
chert werden muss. Vor allem im Kontext von IoT-Geräten, die in Echtzeit Daten verarbeiten
und einfügen, ist auf den Speicherplatz zu achten.
Es wurde bereits die Verteilungsstrategie von PAGE vorgestellt, die sich im Gegensatz zum
einfachen Hashen von RDF-Komponenten sowie dessen Kombinationen unterscheidet, indem
eine Kodierung vorgenommen wurde (vgl. Kapitel 2.2), die je nach Anfragemuster optimal
bedient werden konnte (Valle et al., 2006). Diese war jedoch sehr statisch aufgebaut und eine
nachträgliche Änderung der Schlüsselmenge sehr aufwendig, was zu einer Umverteilung aller
Daten geführt hätte. In diesem Kapitel sollen ähnliche Varianten konzipiert werden, die es im
Gegensatz zu PAGE erlauben, die Tripel gruppiert in Partitionen zur Verfügung zu stellen und
somit eine bessere Verteilung der Tripel zu bedingen. Dabei ist es auch hier wichtig, dass alle
möglichen Anfragetypen unterstützt werden und verschiedene Optimierungen möglich sind,
um Anfragen zu verbessern und parallelisierbar zu gestalten. Die angesprochene Partitionie-
rung soll dabei jedoch nur auf Schlüsselbasis geschehen, sodass die Implementierung der P2P-
Architektur und -topologie nicht dafür verantwortlich ist oder diese extra den Parametern an-
gepasst werden muss. Einen ähnlichen Ansatz beschreiben Mietz et al. (2013). Hier werden
die Tripel zwar nach den Komponenten gehasht (S, P, O), jedoch ist das n−fache Hashen er-
laubt, sodass die jeweilige Komponente zufallsgesteuert 1 bis n-mal gehasht den Schlüssel für
37
3 Konzeption
ein P2P-System darstellt. Bei der Abfrage des Tripels ergeben sich dabei n mögliche Schlüs-
sel, unter denen das Datum gespeichert worden sein kann. Dabei kann diese Anfrage an alle n
Schlüssel gesendet und parallel evaluiert werden. Unter Beachtung der drei Komponenten, die
jeweils gehasht werden, ergibt sich bei dieser Methode eine probialistische Verteilung auf 3n
verschiedene Peers (Mietz et al., 2013).
Die neuen Verteilungsstrategien basieren auf das Bilden von n virtuellen Partitionen7, die im
Schlüssel kodiert werden, sodass keine Anpassung eines P2P-Systems an die Verteilungsstra-
tegie nötig ist. In den folgenden Unterabschnitten werden die neuen Strategien konzeptionell
vorgestellt, wobei in Kapitel 3.2.4 diese fortgeschrittenen Verteilungsstrategien anhand von
grafischen Beispielen dargestellt werden.
Einfache Partitionierung
Die Schlüsselpaare dieser Strategie sind so aufzufassen, dass die letzte Komponente des
Schlüsselpaares nicht wie bei den einfachen Verteilungsstrategien als jeweilige Tripel-Kom-
ponente genutzt wird, sondern als Partitionsnummer. Diese Partitionsnummer liegt zwischen 0
und n und lässt sich mit einer Hashfunktion berechnen, die unabhängig von der Hashfunktion
des P2P-Systems für die Gleichverteilung des Schlüssels auf die Peers ist, sondern ledig-
lich für die Partitionierung auf Schlüsselbasis. Das Einfügen eines Tripels t = (S,P,O) unter
dem Schlüsselpaar „SP“ (steht für die Konkatenation der Subjekt- und Prädikatkomponente)
erfolgt dabei mit insert(hash(S+ hash2(P)), t), wobei die Hashfunktion hash2 die Prädikat-
Komponente des Tripels auf einen Bereich von 0 bis n abbildet (die Partitionsnummer). So
wird ein Tripel t1 = (S1,P1,O) bei gegebenem Schlüsselpaar „SP“ im Schlüssel „<S1>1“ ge-
speichert, wenn hash2(< P1 >) = 1; ein Tripel t2 = (S2,P2,O) mit hash2(< P2 >) = 0 im
Schlüssel „<S2>0“. Entsprechend gibt es auch die Schlüsselkombinationen „PO“ und „OS“
sowie dessen Spiegelpaare (PS, OP, SO), die es erlauben, alle möglichen Anfragetypen zu
beantworten. Eine Anfrage mit einer festen, gegebenen Komponente lässt sich nun so auflösen,
dass sich dass Datum in einer der n verschiedenen Partitionen befindet, und deshalb parallel al-
le n Partitionen befragt und das Ergebnis vereint werden kann. Dies ist möglich, da die Mengen
disjunkt untereinander sind. Wenn zwei oder mehr Komponente in einer Anfrage gegeben sind,
kann mit Hilfe dieser Komponenten eindeutig bestimmt werden, in welcher Partition 0≤ i < n
die entsprechenden Tripel liegen. Eine Anfrage q = (S,?p,O) lässt sich mit dem Schlüsselpaar
„OS“ direkt zu dem eindeutigen Schlüssel „<O>2“ auflösen, wobei hash2(< S >) = 2 ist.
Der Vorteil dieser Strategie liegt in den voraussehbaren Kosten einer Anfrage, da bekannt ist,
dass bei einer Anfrage einer festen Komponente genau n Unterstrukturen zu prüfen sind, die
das Tripel vorhalten können; bei mindestens zwei gegebenen Komponenten kann direkt der
richtige Schlüssel aufgelöst werden.
Die vorgestellte Schlüsselbildung mit Nutzung einer Hashfunktion (hash2(...)), um eine Kom-
ponente auf n Partitionen gleichverteilt zu speichern, ist jedoch im Allgemeinen nicht eindeu-
tig. So kann der Schlüssel <S>2 mehrdeutig sein, da nicht fest bestimmt ist, welches Schlüs-
selpaar für die Kodierung verwendet wurde. In dem kodierten Schlüssel ist lediglich vermerkt,
7Virtuelle Partitionen meint, dass die Partitionierung nur auf Schlüsselbasis geschieht, und keine physischen Par-titionen darstellt.
38
3 Konzeption
dass eine Komponente <S> sowie eine andere Komponente mit dem Hashwert 2 in diesem
Schlüssel gespeichert wurde. Aufgrund der Einwegfunktion, wie Hashfunktionen auch genannt
werden, ist ein Rückschluss der Zahl 2 auf die vorherige Komponente nicht möglich, sodass
nicht definierbar ist, ob sich der Hashwert 2 aus der Prädikat-, Subjekt- oder der Objektkompo-
nente ergab. Dies kann dazu führen, dass jede Ergebnismenge eines Schlüssels <S>2 explizit
auf das Anfragemuster überprüft werden muss, um sicherzugehen, dass die Mehrdeutigkeit
nicht zu einem Fehler führt. Jedoch werden dafür Mehrkosten verursacht, da im worst case alle
ermittelten Tripel durchiteriert und verworfen werden müssten. Deshalb ist in der Kodierung
des Schlüssels zu notieren, dass die 2 das Hashergebnis der Prädikatskomponente ist. Dies kann
z.B. durch Voranstellen der Buchstaben „S“, “P“ oder „O“ gelöst werden, welcher jeweils an-
gibt, welche Komponente (Subjekt, Prädikat oder Objekt) jeweils gehasht wurde. Außerdem ist
zu beachten, dass, wie bereits in Kapitel 2.1.2 beschrieben, die Objekt-Komponenten unter an-
derem ein Literal wie auch eine IRI, die eine bestimmte Ressource referenziert, sein kann. Um
die Problematik zu demonstrieren, wird wieder der Beispielschlüssel <S>2 genommen, wobei
hier angenommen werden kann, dass, wie oben beschrieben, die 2 das Ergebnis des Hashes des
Prädikates ist. Jedoch ist das <S> in dem Schlüssel nicht eindeutig, da nur beschrieben wurde,
dass dieses die serialisierte Komponente ist, also z.B. das Subjekt in der N3-Notation. Wenn
diese Komponente <S> aber eine IRI ist, kann keine Aussage darüber getroffen werden, ob
diese Komponente das Subjekt, Prädikat oder Objekt ist. Mit dem Vorwissen, dass in diesem
Beispiel die Zahl 2 das Hashergebnis des Prädikats ist, kann deshalb entweder das Schlüssel-
paar „OP“ oder „SP“ verwendet worden sein. Da bei „<S>“ keine Unterscheidung zwischen
einer Komponente möglich ist, müsste auch hier die Ergebnismenge explizit anhand des Anfra-
gemusters überprüft werden. Deshalb ist auch hier in der Kodierung darauf zu achten, die Res-
source mit seiner Komponente darzustellen, um keine Mehrfachdeutung zu ermöglichen, die
zu Mehrkosten und nachträglichem Überprüfen der Ergebnismenge führt. Es bietet sich an, vor
der serialisierten Komponente im Schlüssel dessen Komponenten-Typ (S=Subjekt, P=Prädikat,
O=Objekt) voranzustellen, um eindeutige Partitionsschlüssel zu erhalten.
Ein Code-Beispiel der vorgestellten Schlüsselgenerierung ist im Quelltext 1 gegeben. Dabei
wird ein Tripel t in ein P2P-System unter allen sechs Schlüsselkombinationen (keyCombination)
eingefügt.
1 function insert(String keyCombination,Triple t) {2 String newKey = keyCombination.firstCharacter()3 newKey += t.getElement(keyCombination.firstCharacter())4 newKey += keyCombination.secondCharacter()5 newKey += getHash(t.getElement(keyCombination.
secondCharacter()))6 P2P.insert(newKey,t);7 }
Quelltext 1: Einfügen eines Tripels erfolgt in der vorgestellten Methode sechsfach,d.h. mit jeder Kombination als keyCombination (SO, PS, PO, OS,OP, SP). Dabei wird der Schlüssel erstellt, der z.B. bei insert(SO,<Subject><Predicate><Object>) die Form S<Subject>P<hash(Predicate)>hat.
39
3 Konzeption
Anfragemuster mögliche Schlüsselkom-binationen
Anz. d. Schlüssel bei nPartitionen
<S><P><O> SO, PS, PO, OS, OP, SP 1<?><P><O> PO, OP 1<?><?><O> OP, OS n<?><P><?> PO, PS n<S><?><?> SO, SP n<S><P><?> SP, PS 1<S><?><O> SO, OS 1
Tabelle 6: Mögliche Anfragemuster sowie deren Auflösung, die möglichen Schlüsselkombi-nationen in der einfachen Partitionierung und die Anzahl der Schlüssel, in der dieTripel der Anfrage vorliegen
Die Auflösung einer Anfrage q = (S,?p,?o) kann nicht in einem Schritt erfolgen, da keine
Schlüsselkombination ausschließlich das Subjekt enthält. Deshalb müssen alle Schlüssel der
Form „S<S>Pi“ mit i ∈ (0 . . .n) 8 abgefragt werden (vgl. Tabelle 6). Wenn die Hashfunkti-
on die gehashten Werte in drei Partitionen (n = 3) verteilt, muss die Abfrage an die Schlüs-
sel „S<S>P0“, „S<S>P1“ sowie „S<S>P2“ erfolgen, und das Ergebnis dann vereint werden.
Würde z.B. die Kombination aus Subjekt und Prädikat abgefragt werden, kann mit Hilfe der
Hashfunktion eindeutig der Schlüssel bestimmt werden, der jene Tripel enthält. Dennoch wird
mittels der Partitionen eine Aufteilung der Datenmenge auf mehrere Peers erzwungen. In Ta-
belle 6 sind die möglichen Anfragemuster sowie dessen Auflösung mit der Verteilungsstrategie
aufgelistet. Im Gegensatz zu den einfachen Verteilungsstrategien aus Kapitel 3.2.1 lässt sich so-
mit bei einer Anzahl von 4 Partitionen der vorige Datenbestand im Mittel vierteln. Außerdem
ist bei der Verteilung dafür gesorgt, dass die Datenpartitionen unabhängig voneinander abge-
fragt werden können, sodass selbst durch die Schlüsselkodierung bereits eine Lastverteilung
zu verzeichnen ist. Durch die Auswahl der Spiegelpaare der Schlüsselkombinationen kann des
Weiteren ein redundanter anderer Schlüssel verwendet werden, wenn der Peer des ursprüng-
lich zu verwendeten Schlüssels bereits sehr ausgelastet ist. Vor allem wenn Statistiken im Netz
und an den Peers über die Auslastung angefertigt werden, ist für jede SPARQL-Anfrage der
jeweilige Peer zu benutzen, der zur Zeit oder im Durchschnitt am wenigsten ausgelastet ist.
Vorteile Nachteile
• Datenverteilung durch Partitionen
• Lastverteilung möglich, wenn alterna-
tive Schlüsselkombinationen gewählt
werden
• 6 Schlüssel pro Tripel, damit vielfache
Datenmenge
• Schnelle Datenauflösung nur möglich,
wenn an den Knoten die Daten in einem
Index vorliegen, da sonst bei Anfragen
mit 2 festen Komponenten viele Elimi-
nierungen nötig sind
8Erklärung: S steht für Subjekt, danach folgt das jeweilige Subjekt des Tripels, hier: <S>; P steht für das Prädikat,wobei die Zahl die Partition identifiziert, die das Prädikat mit dem entsprechenden Hashwert gespeichert hat.
40
3 Konzeption
Zweifache Partitionierung
Im bisherigen konzipierten Fall können Anfragen der Form q = (S,P,O) nicht perfekt aufge-
löst werden, da eine Nachauflösung der Ergebnismenge nötig ist. Wie bereits in den „einfachen
Verteilungsstrategien“ aus Kapitel 3.2.1 beschrieben, diente die Schlüsselkombination „SPO“
der Überprüfung, ob ein gegebenes Tripel im RDF-Speicher hinterlegt ist. Diese Anfragen sind
zwar relativ selten, in der einfach partitionierten Form jedoch nicht direkt auflösbar, da ledig-
lich Schlüsselpaare bestehend aus zwei Komponenten zur Verfügung stehen. Der Fall, dass alle
Komponenten in der Anfrage fest vorhanden sind, kann mit Hilfe einer weiteren Partitionie-
rung unter dem bekannten virtuellen Knoten i ∈ 0 . . .n gelöst werden, wobei auch die dritte
Komponente mitbestimmt, auf welchem der m Unterstrukturen dessen Komponente i liegt. So
ergeben sich die Schlüsselkombinationen „SPO“, „PSO“, „OPS“ der Länge 3 aus der Teilmen-
gen der Permutation von „SPO“. Dass diese Kombinationen für jegliche Anfragen genügen, ist
in Tabelle 7 gezeigt. In dieser Verteilungsstrategie ist die Kodierung auf zwei, nicht zwingend
gleichgroße Partitionen der zweiten und dritten Komponente der Schlüsselkombination zurück-
zuführen. In der Schlüsselkombination „SPO“ wird die Kodierung durch die Konkatenation der
Subjektkomponente mit der Partitionierung der Prädikatkomponente und der Partitionierung
der Objektkomponente durchgeführt, welche die Form „S<S>PiOj“ hat, wobei i ∈ 0 . . .n und
j ∈ 0 . . .m die Prädikatskomponente und die Objektkomponente auf dessen n bzw. m Partitio-
nen verteilt. Die Auflösung geschieht dabei analog zur einfachen Partitionierung. Eine Anfrage
q = (S,P,O) ergibt sich direkt aus der Hashbildung von Prädikat und Objekt, die Anfrage
q = (S,P,?o) führt mit hash(P) = 1 zu dem Schlüssel „S<S>P1Oj“ (der Schlüsselkombina-
tion SPO) wobei alle Partitionen 0 ≤ j ≤ m abgefragt und das Ergebnis vereinigt wird. Bei
Anfragen mit nur einer Komponente ist eine n ∗m−fache Auflösung nötig, wenn die Anzahl
der Partitionen der zweiten Komponente n und der dritten Komponente m ist. Dies liegt daran,
dass die einzige gegebene Komponente der Anfrage in der ersten Komponente des Schlüssels
genutzt werden muss und für die jeweiligen Hashwerte der anderen Schlüsselkomponenten
(Partitionen) alle Kombinationen ausprobiert werden müssen. Bei Anfragen mit einer Variable
ist der Aufwand nötig, der bei der einfachen Partitionierung nötig war, wenn lediglich eine
feste Komponente vorhanden gewesen ist. Im Gegensatz dazu kann jedoch bei der zweifachen
Partitionierung mehr Parallelität ausgenutzt werden, da bei den meisten Anfragen9 keine di-
rekte Auflösung nötig ist und deshalb viele Partitionen parallel mit dem Anfragemuster befragt
werden können.
Vorteile Nachteile
• Datenverteilung durch Partitionen
• Lastverteilung möglich durch alternati-
ve Schlüsselkombinationen und Anzahl
an Partitionen
• nur 3 Schlüssel pro Tripel benötigt
• Schnelle Datenauflösung nur möglich,
wenn an den Knoten die Daten in einem
Index vorliegen, da sonst viele Eliminie-
rungen nötig sind
9Die meisten Anfragen bestehen aus ein oder zwei Variablen, vgl. Benchmarks aus Kapitel 5.1
41
3 Konzeption
Anfragemuster mögliche Schlüsselkom-binationen
Anz. d. Schlüssel bei nund m Partitionen
<S><P><O> SPO, PSO, OPS 1<?><P><O> OPS bzw. PSO m bzw. n<?><?><O> OPS n∗m<?><P><?> PSO n∗m<S><?><?> SPO n∗m<S><P><?> SPO, PSO m<S><?><O> OPS, SPO n
Tabelle 7: Mögliche Anfragemuster sowie deren Auflösung, die möglichen Schlüsselkombi-nationen in der zweifachen Partitionierung und die Anzahl der Schlüssel, in der dieTripel der Anfrage vorliegen
Die beiden bisher vorgestellten fortgeschrittenen Verteilungshierarchien sind in Abbildung 12
schematisch dargestellt, wobei zwischen der einstufigen/einfachen und zweistufigen/zweifa-
chen Partitionierung unterschieden wird. Visualisierte Beispiele der konzipierten Verteilungs-
strategie finden sich in Kapitel 3.2.4.
Abbildung 12: Schlüsselbildung bei den fortgeschrittenen Verteilungsstrategien mit einstu-figer Partitionierung (SP,SO,PO,PS,OS,OP) und zweistufiger Partitionierung(SPO,PSO,OPS)
42
3 Konzeption
Einfache Partitionierung ohne nachträgliche Eliminierung
In der dritten fortgeschrittenen Verteilungsstrategie wird eine Indexstruktur im Schlüssel be-
reitgestellt, die dafür sorgt, dass beim Abfragen von Schlüsseln über Anfrage-Muster bereits
nur relevante Daten lokalisiert werden. Bei den vorigen Strategien kann sich eine große Er-
gebnismenge ergeben, welche mit dem Anfragemuster verglichen werden musste und viele
Eliminierungen ergeben konnte. Im Gegensatz zu den beiden hierarchischen Strategien, muss
hierbei bereits im Schlüssel möglichst viel Wissen über das Anfragemuster hinterlegt werden,
was unweigerlich dazu führt, dass pro Tripel mehr Einfügungen nötig sein werden als bei den
vorgestellten Varianten. So werden hier neben den Paarungen „SP“, „PS“, „OS“ die jeweiligen
Spiegelungen mitbetrachtet: „SO“, „PO“, „OP“. Dabei werden die Paarungen so gelesen, dass
die letzte Komponente jeweils partitioniert wird. Dies geschieht wie bei der hierarchischen
Strategie über Hashfunktionen, die das Datum unter den n Partitionen verteilt. Bei Anfragen
mit lediglich einer festen Komponente und zwei Variablen wird entsprechend die Schlüssel-
kombination gewählt, wobei die feste gegebene Komponente die erste Position der Kombina-
tion repräsentiert. Die zweite Position ist mit allen n möglichen Partitionen zu besetzen: Eine
Anfrage q = (s,?p,?o) ist so in den Schlüssel-Paaren „SO“ oder „SP“ zu beantworten, bei
n = 2 Partitionen jeweils in den Schlüsseln „S<s>O0“, „S<s>O1“ bzw. „S<s>P0“, „S<s>P1“.
Um Anfragen mit nur einer Variable zu beantworten, können zwar die vorgestellten Paarungen
genügen, jedoch tritt hier das erwähnte Problem auf, dass in den berechneten Schlüsseln eine
Vielzahl von nicht zutreffenden Tripeln gespeichert sein können. Eine Anfrage q = (s, p,?o)
mit den Hashwerten hash(p) = 1 ergibt zum Beispiel den eindeutigen Schlüssel „S<s>P1“,
wobei hier zwar das entsprechende Datum hinterlegt ist, jedoch aufgrund der Partitionierung
auch viele andere, nicht zutreffende Tripel10. Da genau dieses Problem bei dieser Verteilungs-
strategie vermieden werden sollte, müssen neben den sechs Paarungen noch die Paare „POS“,
„SOP“ sowie „SPO“ bei der Einfügung und Abfrage berücksichtigt werden, wobei hier im Un-
terschied zur zweifachen Partitionierung nur die letzte Komponente gehasht wird und die ersten
Komponenten in den Schlüsselkombinationen die Komponenten des Tripels repräsentieren. So
lässt sich obige Anfrage q auf die Schlüssel „S<s>P<p>O0“ und „S<s>P<p>O1“ (bei n = 2)
auflösen. Da Anfragen ohne Variable selten vorkommen, wird verzichtet, eine zehnte Schlüssel-
paarung „SPO“ zu fordern, sodass der Mehraufwand von Anfragen wie q = (s, p,o) zu dulden
ist, wo wiederum Eliminierungen vorgenommen werden müssen (s.o.). In Tabelle 8 ist gezeigt,
dass alle Anfragemuster mit dieser Verteilungsstrategie beantwortet werden können, wobei
stets konstant n Partitionen die Tripel vorhalten können, sodass die Partitionsgröße hier angibt,
wie viele Anfragen parallel an die n Knoten im P2P-Netz verarbeitet werden können. Aufgrund
der Disjunktheit der Partitionen, ist die Vereinigung der n Ergebnismengen das Endresultat der
Anfrage. Wegen der neunfachen Datenmenge, die sich aus den verschiedenen Schlüsselpaaren
ergibt, ist der Nachteil dieser Verteilungsstrategie wiederum, dass pro Tripel, das dem P2P-Netz
hinzugefügt werden soll, eine neunfache Speicherung des Datums vorgenommen werden muss.
Der Kompromiss liegt darin, dass man sagen kann, dass die Daten lediglich ein Mal dem P2P-
System hinzugefügt werden und deshalb ein Mehraufwand in der Zeit zu verkraften sei. Ein
weiterer Vorteil der Methode ist, dass verschiedene Anfragen so aufgelöst werden können, dass
10Genau die Tripel, dessen Hashwert 1 sich aus der Prädikatskomponente ergibt.
43
3 Konzeption
Anfragemuster mögliche Schlüsselkom-binationen
Anz. d. Schlüssel bei nPartitionen
<S><P><O> POS, SOP, SPO n<?><P><O> POS n<?><?><O> OP, OS n<?><P><?> PS, PO n<S><?><?> SP, SO n<S><P><?> SPO n<S><?><O> SOP n
Tabelle 8: Mögliche Anfragemuster sowie deren Auflösung, die möglichen Schlüsselkombi-nationen in der einfachen Partitionierung ohne Eliminierungen und die Anzahl derSchlüssel, in der die Tripel der Anfrage vorliegen
im Zielschlüssel die Daten nicht durchiteriert und mit der Anfrage verglichen werden müssen.
Das liegt daran, dass je nach Anfrage die Schlüsselkombination zu wählen ist, die am zutref-
fendsten ist: Bei Anfragen mit zwei Variablen die passende Schlüsselkombination der Länge
2; bei Anfragen mit lediglich einer Variable die passende Schlüsselkombination der Länge 3
(siehe Tabelle 8). Nur bei Anfragen ohne Variablen ist eine direkte Auflösung nicht möglich.
Im Gegensatz zu den hierarchischen Methoden ist diese Verteilungsstrategie somit unabhängig
von einer Indexstruktur des Datenlagers eines Peers nutzbar. Würden die Tripel indiziert am
Knoten vorliegen, ließe sich durch das Anfragemuster direkt der Bereich zurückgeben, das die
entsprechenden, richtigen Tripel beinhaltet. Sollte eine solche Struktur am P2P-System vor-
handen sein, ist das hierarchische Verfahren durch die Reduzierung der Datenmenge auf 1/3
zu bevorzugen, wobei die dritte vorgestellte Methode für alle beliebigen P2P-Topologien gilt,
die auf DHTs basieren.
Vorteile Nachteile
• Datenverteilung durch Partitionen
• Lastverteilung möglich durch alterna-
tive Schlüsselkombinationen bei einer
festen Komponente
• Direkte Datenauflösung ohne nachträg-
licher Überprüfung und Dateneliminie-
rung (außer bei drei festen Komponen-
ten)
• Insgesamt 9 Schlüssel pro Tripel, d.h.
die neunfache Datenmenge muss im
P2P-Netz hinterlegt werden
44
3 Konzeption
3.2.3 Verteilungsstrategien im P2P-Netz
Die im vorigen Abschnitt konzipierte Kodierung im Schlüssel mit Partitionen hat den Vorteil,
dass ein P2P-System nicht für das Management und die Verteilung der Tripel in Partitionen
zuständig ist und deshalb eventuell angepasst werden müsste. Deshalb kann für die Realisie-
rung auch jede P2P-Architektur eingesetzt werden, die auf verteilte Hashtabellen basiert, da
diese die Funktionalität des Einfügens und Abfragens von Daten über Schlüssel bereitstellt.
Die SPARQL-Engine fragt bei entsprechenden Anfragemustern die gewählte Verteilungsstra-
tegie, an welchem P2P-Schlüssel die erforderlichen Daten liegen. Anschließend kann über die
Engine die konzipierte P2P-Komponente angesprochen werden, die dann die Daten aus dem
P2P-Netz abfragt (vgl. Architekturschema in Abbildung 11, S. 30).
Der Vorteil bei der Partitionierung liegt darin, dass parallel Anfragemuster an die jeweiligen
Partitionen (im Idealfall alles verschiedene Peers) versendet werden können. Diese werden
dann lokal an dieser Partition berechnet, wobei lediglich die Daten bei der Berechnung benö-
tigt werden, die auch lokal auf dieser Partition vorliegen11. Das Ergebnis wird anschließend zu
dem anfragenden Client zurückgesendet, der die Daten weiterverarbeiten kann. Wie bereits in
Kapitel 3.1 beschrieben, muss dabei auf jedem Knoten eine Instanz einer Anfrage-Engine für
die Berechnung vorliegen. Des Weiteren müssen P2P-Nachrichten empfangen und gesendet
werden können, sodass die Unteranfragen zu den Zielknoten gelangt – und wieder zurück (vgl.
Kapitel 3.1). Würde eine solche Struktur nicht existieren, hätten Unteranfragen einen geringe-
ren Sinn, da auf jedem Knoten die komplette P2P-Topologie nach den Daten befragt würde und
eine Partitionierung dadurch überflüssig wäre. Außerdem ist dann zwischen den herkömmli-
chen Verteilungsstrategien und der Partitionierungsmethode kein Unterschied bemerkbar, da
der Schlüssel nur zum Speichern und Abfragen im P2P-Netz verwendet werden würde, jedoch
keinerlei weitere Vorteile böte.
Außerdem muss die Anzahl der Peers in einem gewissen Größenverhältnis zu der Partitions-
größe n stehen, um eine echte Partitionierung im P2P-Netz zu erhalten, d.h. jede zugehörige
Partition muss auf verschiedene Peers verteilt liegen. Eine Partitionierung in vier Teile bei le-
diglich zwei Knoten im Netzwerk führt unweigerlich dazu, dass im worst case alle Partitionen
an einem Peer zu lokalisieren sind. Dabei ist zu bedenken, dass die Anzahl der Duplikate in der
Ergebnismenge möglicherweise falsch sein kann, wenn die Verteilung der Partitionen schlecht
erfolgt. Sind zwei Partitionen auf einem Peer vertreten, führt dies in der Abfrage unweigerlich
dazu, dass bei beiden Unteranfragen an die Partitionen die selben Ergebnisse zurückgeliefert
werden und somit am anfragenden Peer die doppelte Menge der Ergebnisse weiterverarbeitet
wird. Deshalb ist es wichtig, die Zahl der Partitionen und die Menge an Rechnern im P2P-
System gut zu wählen, wobei wesentlich mehr Peers vorhanden sein müssen, um Kollisio-
nen12 zu vermeiden. Auch bei der Hashfunktion muss sichergestellt werden, dass sie uniforme,
gleichverteilte Werte liefert, sodass die Hashwerte der ähnlichen Schlüssel einen entsprechen-
den Abstand haben, sodass sie nicht auf denselben Peer gespeichert werden. Die beschriebenen
neuen Verteilungsstrategien führen unweigerlich dazu, dass unter einem festen Schlüssel viele
11Dieser Umstand ergibt sich aus der Partitionierung, da hierbei viele Tripel unter dem jeweiligen Schlüssel ge-speichert wurden und die Anfrage sich lediglich auf diese Tripel bezieht.
12 Mehrere Partitionen der gleichen Sorte auf einem Peer
45
3 Konzeption
Tripel gespeichert werden, sodass die P2P-Architektur dafür sorgen muss, dass diese Daten in
einer Indexstruktur geordnet zu platzieren sind. Ansonsten müssten alle Tripel des übergebenen
Schlüssels durchiteriert und mit dem Anfragemuster verglichen werden. Eine Indexstruktur in
der Speicherschicht eines Peers könnte es zudem erlauben, dass anhand des Tripel-Musters nur
zutreffende Daten zurückgeliefert werden. Je nach Datenstruktur des Index könnte damit ein
Auffinden in logarithmischer Zeit erfolgen (Ottmann & Widmayer, 2012). Da es nicht jede be-
liebige P2P-Topologie und -Implementierung erlaubt, die Speicherschicht anzupassen, wurde
eine ähnliche dritte Verteilungsstrategie konzipiert, die wiederum auf Schlüssel basierte Parti-
tionierung arbeitet (vgl. Einfache Partitionierung ohne Eliminierung). Diese Methode enthält
eine Art Indexstruktur in dem Schlüssel, wobei je nach Anfragemuster immer der bestmögliche
Schlüssel zurückgegeben wird, der die Anfrage direkt auflösen kann, ohne dass die Ergebnis-
menge mit der Anfrage verglichen und falsche Tripel eliminiert werden müssen. Die Kosten
liegen bei der Strategie jedoch in der 9-fachen Datenmenge.
Diese Schlüssel der vorgestellten Verteilungsstrategien sind jedoch in den SPARQL-Engines
nur lokal gültig, sodass der jeweilige Evaluator mit Hilfe des Abfragemusters die jeweiligen
Schlüssel einer Verteilungsstrategie abfragt, und Unteranfragen an die P2P-Knoten sendet, die
sich aus dem Schlüssel ergeben. Bei der Übertragung der Abfrage an diesen Knoten wird die-
ser Schlüssel nicht weiter behandelt oder mitgesendet, sodass dieser Schlüssel dem Empfänger
nicht bekannt ist. Dies führt vor allem im P2P-Netz zu Problemen, da ein Knoten für mehrere
Schlüssel zuständig sein kann, und deshalb der Empfänger auch nicht wissen kann, an welche
seiner Empfänger-Adressen (also die jeweiligen Schlüssel, die der Peer verwaltet) die Anfrage
gestellt wurde. Der Empfänger muss in diesem Fall lokal in seinem RDF-Speicher die Anfrage
mit allen möglichen Schlüsseln der Verteilungsstrategie verarbeiten, um das angefragte Er-
gebnis zu erhalten. Dies impliziert ebenfalls, dass in der Verteilungsstrategie Determiniertheit
gefordert werden muss, d.h. bei gleicher Anfrage muss dieselbe Schlüsselmenge zurückgelie-
fert werden. In Kapitel 3.2 wird gezeigt, dass es je nach Verteilungsstrategie mehrere mögliche
Schlüssel geben kann, welche die Daten verwalten. Zum Beispiel kann eine Abfrage ohne
Variablen (q = (S,P,O)) in der hierarchischen Verteilungsstrategie (einfachen Partitionierung)
jeweils unter den Schlüsselkombinationen „SP“, „SO“, „PS“, „PO“, „OS“ und „OP“ gesen-
det werden. Hier wäre eine zufällige Auswahl möglich, da letztlich alle Schlüssel das Tripel
t = (S,P,O) beinhalten. Die Auswahl einer zu nutzenden Schlüsselkombination kann auch mit
Unterstützung von Histogrammen und Statistiken erfolgen. Dies kann jedoch dazu führen, dass
ein anderer Knoten, der eine Anfrage enthält, einen anderen Schlüssel durch Verteilungsstrate-
gie zugewiesen bekommt, der lokal in seinem Datenlager gar nicht vorliegt. Dies führt später zu
einer falschen Ergebnismenge am anfragenden Client. In Abbildung 13 wird dieses Problem-
Szenario grafisch aufgezeigt.
Aufgrund der Determiniertheit an allen Peers muss auf ein zufälliges Auswählen eines vali-
den Schlüssels verzichtet werden. Zwar ist es möglich, den Schlüssel in einer Unteranfrage zu
integrieren, jedoch birgt dieses den Nachteil, dass die API und Datenstrukturen einer SPAQRL-
Engine dahingehend verändert werden müssen. Das führte dazu, dass die Verwaltung von Indi-
zes und die Datenstruktur, die das Anfragemuster verarbeitet auf diesen Fall umgebaut werden
müsste. Da solche Engines jedoch nicht nur für P2P-Zwecke gedacht sind und die Änderungen
nur in P2P-Systemen genutzt werden würden, wird darauf verzichtet, eine entsprechende An-
46
3 Konzeption
Abbildung 13: Problem-Szenario mit nicht deterministischen SchlüsselnEine Anfrage mit einer Variablen wird an den Anfrageclient gesendet. Dieserermittelt anhand des Anfrage-Musters den Schlüssel im P2P-Netz wo das Tri-pel vorliegt. Hier wird zufällig (oder mit Hilfe von Statistiken) die Anfragean Knoten 3 weitergeleitet. Knoten 3 ist für mehrere Schlüssel zuständig, undweiß nicht, welchen der Anfrageclient nutzte, und wählt zufällig aus der Vertei-lungsstrategie einen Schlüssel. Für diesen ausgewählten Schlüssel ist er jedochnicht zuständig, und das Ergebnis deshalb leer, obwohl es ein Tripel im lokalenSpeicher gibt.
passung umzusetzen. Ein weiterer Ausweg wäre das Starten von separaten P2P-Knoten für die
verschiedenen Schlüsselkombinationen, sodass die Adressierung wie gewohnt über die Vertei-
lungsstrategie vorgenommen wird und der Knoten beim Empfang der Unteranfrage aufgrund
seiner Schlüsselkombination weiß, welche Daten er zu adressieren hat. Im Zusammenhang mit
der Determiniertheit der Schlüssel, welche die Verteilungsstrategien anhand des Anfragemus-
ters erstellen, können in den ersten beiden fortgeschrittenen Verteilungsstrategien (einfache
und zweifache Partitionierung) die Menge an Schlüsselkombinationen verringert werden. Die
jeweils zu vorhandenen Schlüsselkombinationen ergeben sich aus Tabelle 9. In Tabelle 10 und
11 ist aufgezeigt, dass jene Schlüssel/Schlüsselpaare ausreichen, um allen Anfragemustern zu
genügen.
47
3 Konzeption
Verteilungsstrategie Schlüsselpaare
Einfache Partitionierung (SP, PO, OS)Zweifache Partitionierung (SPO, PSO, OPS)Neunfache Partitionierung(Einfache Partitionierungohne Eliminierung)
(SP, PO, OS, SO, PS, OP, SPO, SOP, POS)
Tabelle 9: Übersicht der fortgeschrittenen Verteilungsstrategien und dessen Schlüsselpaare ausKapitel 3.2.2
Anfragemuster zugehörige Schlüssel (determi-
nistisch) bei n Partitionen
<S><P><O> S<S>P{hash(<P>)}
<?><P><O> P<P>O{hash(<O>)}
<?><?><O> O<O>S{i,∀i ∈ [0,n]}
<?><P><?> P<P>O{i,∀i ∈ [0,n]}
<S><?><?> S<S>P{i,∀i ∈ [0,n]}
<S><P><?> S<S>P{hash(<P>)}
<S><?><O> O<S>S{hash(<S>)}
Tabelle 10: Mögliche Anfragemuster sowie deren deterministische Schlüssel-Auflösung fürein P2P-Netzwerk bei der einfachen Partitionierung
Anfragemuster mögliche Schlüsselkombinationen
<S><P><O> SPO, PSO, OPS
<?><P><O> PSO, OPS
<?><?><O> OPS
<?><P><?> PSO
<S><?><?> SPO
<S><P><?> SPO, PSO
<S><?><O> SPO, OPS
Tabelle 11: Mögliche Anfragemuster sowie deren nicht-deterministische Schlüssel-Auflösungfür ein P2P-Netzwerk bei der zweifach-hierarchischen Verteilungsstrategie / zwei-fache Partitionierung
48
3 Konzeption
3.2.4 Grafische Darstellung der fortgeschrittenen Verteilungsstrategien
Ein Beispiel für das Einfügen und Abfragen mit der Strategie der einfachen Partitionierung ist
in Abbildung 14 dargestellt. Die verwendeten Schlüssel ergeben sich dabei unmittelbar aus Ta-
belle 10. In dieser Verteilungsstrategie werden alle Tripel in der geforderten deterministischen
Schlüsselerzeugung in drei P2P-Schlüsseln der Kombinationen „SP“, „PO“ und „OS“ einge-
fügt. Die Auflösung der Anfragen ergibt sich aus obiger Tabelle, wobei im ersten Fall eine
direkte Schlüsselauflösung möglich ist. Dabei müssen jedoch die Ergebnisse anhand des An-
fragemusters verglichen werden, da in diesem Schlüssel alle Tripel gespeichert werden, die aus
dem Subjekt „Bjoern“ und einem Prädikat, welches den Hashwert 3 besitzt, bestehen. Im zwei-
ten Fall sind in den jeweiligen vier Partitionen jedoch alle korrekten, der Anfrage genügenden
Tripel, gespeichert und somit kein nachträgliches Überprüfen mehr nötig.
Abbildung 14: Beispiel für das Einfügen von Tripeln und dem Abfragen von Tripeln in dereinfachen hierarchischen Verteilungsstrategie.
Wenn die nötige nachträgliche Eliminierung aufgrund einer in dem P2P-Knoten nicht vorhan-
denen Indexstruktur nicht effizient gelöst werden kann, ist die Verteilungsstrategie der einfache
Partitionierung ohne Eliminierung zu wählen. Diese ist analog zu obigen Beispiel anwendbar,
wobei jedoch für die Auflösung der Anfrage q = (B joern, ist,?o) die neue Schlüsselkombinati-
on „SPO“ zu nutzen (vgl. Tabelle 8, S. 44). Dies führt zu der entsprechenden Auflösung in den
n Partitionen „S<Bjoern>P<ist>O0“ bis „S<Bjoern>P<ist>On“. In diesen Partitionen sind bei
diesem Verfahren lediglich die Tripel, die der obigen Anfrage q genügen, sodass keine Iteration
und Überprüfung der Ergebnismenge nötig ist. Dafür sind jedoch auch anstatt der im Beispiel
gezeigten 3 Einfügungen ganze 9 Einfügungen ins P2P-Netz nötig.
49
3 Konzeption
Als Beispiel für die Verteilungsstrategie mit der zweifachen Partitionierung wird für die Par-
titionierung der zweiten Komponente des Schlüsselpaares ein Bereich von 4 Partitionen an-
genommen, für die Partitionierung der dritten Komponente entsprechend 2. Aufgrund der ge-
forderten Determiniertheit werden lediglich die Schlüsselkombinationen „SPO“, „PSO“ sowie
„OPS“ gewählt. Diese genügen allen erdenklichen Kombinationen von Anfragen, wie Tabel-
le 11 zeigt. In Abbildung 15 ist das Einfügen und Abfragen eines Tripels für diese Verteilungs-
strategie exemplarisch dargestellt. Aufgrund der unterschiedlichen Partitionsgrößen (hier: vier
und zwei) lässt sich bei Vernachlässigung der Forderung der Determiniertheit außerdem eine
Verbesserung der Anzahl an parallelen Unteranfragen erreichen. Um dies zu verdeutlichen ist
die Abfrage q = (?s, p,o) zu betrachten, wobei sich laut Tabelle 11 die Kombinationen „PSO“
und „OPS“ anbieten. Bei der ersten Variante erhält man vier Unteranfragen (entsprechend:
P<P>S0O1, P<P>S1O1, P<P>S2O1, P<P>S3O1), bei der zweiten Variante aufgrund der Par-
titionsgröße der dritten Komponente der Schlüsselkombination lediglich zwei Unteranfragen.
Abbildung 15: Beispiel für das Einfügen von Tripeln und dem Abfragen von Tripeln inder Verteilungsstrategie mit zweifacher Partitionierung. Dabei wird die zweiteSchlüsselkomponente in 4 Teile und die dritte Schlüsselkomponente in 2 Teilepartitioniert.
Im Vergleich der beiden exemplarisch dargestellten Strategien ist erkennbar, dass bei der zwei-
fachen Partitionierung viel mehr Unteranfragen nötig sind, um Abfragen ausführen zu können
(vgl. Abbildung 14 und Abbildung 15). Bei der einfachen hierarchischen Strategie mussten ma-
ximal n Unterabfragen gestellt werden (wobei n die Partitionsgröße darstellt). Bei der doppelt
hierarchischen Strategie dagegen n∗m Unterabfragen (wobei n und m die jeweiligen Partitions-
größen sind). Dies muss jedoch nicht unbedingt von Nachteil sein, wenn diese Unteranfragen
parallel ausgeführt und außerdem optimiert werden können. Jedoch ist wieder darauf zu achten,
dass eine entsprechende Netzwerkgröße gewählt wird, um Kollisionen gleichartiger Partitionen
auf einem Peer zu vermeiden.50
3 Konzeption
3.3 Parallelität bei Partitionsanfragen
In SPARQL-Engines wird eine Anfrage in einen Operatorgraphen überführt, der einen Aus-
führungsplan für die Berechnung darstellt (Kemper & Eickler, 2001). Dabei ist dieser Ope-
ratorgraph als Baumstruktur zu verstehen, wobei die Knoten die verschiedenen Operationen
(wie z.B. Join, Vereinigung, Sortierung) darstellt. Dabei werden die bis dato errechneten Daten
von Operator zu Operator weitergereicht, bis das Anfrageergebnis berechnet wurde. Anhand
des Operatorbaums kann dann eine Optimierung vorgenommen werden, wobei zwischen lo-
gischer und physischer Optimierung unterschieden wird. Bei der logischen Optimierung wird
die Anfrage algebraisch vereinfacht (Yu & Meng, 1998). Dies geschieht durch Ausnutzung
von Regeln und Gruppenaxiomen (wie z.B. das Assoziativgesetz) der Datenbankoperatoren.
Zu diesen wichtigsten Regeln zählt unter anderem das Verschieben der Selektionsoperatoren
so weit wie möglich zum Anfang des Operatorgraphen, da die Operation die Datenmenge stark
reduzieren kann sowie die Ersetzung von kartesischen Produkten durch Verbundoperationen
(Yu & Meng, 1998). Dabei ist kein Wissen über Schemata der Datenbank und des Datenbe-
standes nötig. Während der Optimierung wird der Operatorbaum in einen äquivalenten Baum
transformiert, der das Ergebnis nicht beeinflusst. Die abschließende und aufwendige physische
Optimierung (auch interne Optimierung) wählt nun anhand von Statistiken, Indizes oder der
Kardinalität einer Relation den bestmöglichen Algorithmus für eine Berechnung aus. In dem
Operatorbaum werden dabei abstrakte Operatoren (Baumknoten) in physische Operatoren um-
gewandelt. Für die meisten abstrakten Operationen stehen verschiedene Algorithmen für die
unterschiedlichsten Anwendungszwecke zur Verfügung (Garcia-Molina et al., 2002), z.B. für
Merge-Joins, die je nach Datenquelle und -größe im Arbeitsspeicher oder mittels Dateien er-
folgen können.
Für das Ausnutzen von parallelen Berechnungen kann der Operatorgraph einer Anfrage in
Unter(operator)graphen aufgeteilt werden, die an verschiedene P2P-Knoten gesendet und dort
optimiert und ausgeführt werden können. Dies hat den Vorteil, dass bei einer lokalen Opti-
mierung mehr Informationen für bestimmte Operatoren vorhanden sein können, und deshalb
Statistiken etc. nicht an den anfragenden Client gesendet werden müssen. Außerdem können
bei SPARQL-Anfragen unterschiedliche Datenquellen genutzt werden, sodass die Anfrage an-
hand der verschiedenen Anfragemuster, unterteilt in Untergraphen, zu den entsprechenden Da-
tenquellen gesendet werden. Diese können dort parallel berechnet werden und die Ergebnisse
der Unteroperatorbäume dann im globalen Operatorbaum am anfragenden Client weiterverar-
beitet werden. Vor allem die Verteilungsstrategien (vgl. Kapitel 3.2), welche durch die Parti-
tionierung viel Potential für Parallelität bieten, sollen eine solche Unterteilung des globalen
Operatorbaums möglich machen. Dabei geben diese Strategien je nach Anfragemuster dieje-
nigen Schlüssel zurück, unter welchen die nötigen Tripel im P2P-System vorliegen. Wegen
der möglichen Partitionierung führt dies dazu, dass ein Anfragemuster parallel zu beantworten
ist. Im Idealfall sind alle Partitionen im P2P-Netz kollisionsfrei verteilt, sodass die einzelnen
Partitionen gleichzeitig abgefragt werden können. Eine Optimierung geschieht, indem allen n
Partitionen das entsprechende Anfragemuster gesendet und dort lokal ausgeführt wird. Die Er-
gebnisse aller Partitionen werden dann wieder im globalen Operatorgraph vereinigt, da die Par-
titionen aufgrund ihrer Kodierung jeweils disjunkte Datenmengen enthalten. In Abbildung 16
51
3 Konzeption
Abbildung 16: Parallele Unteroperatorgraphen bei der Nutzung von Verteilungsstrategien mitPartitionierung
wird dies anhand eines Beispiels mit einer Partitionierung in drei Teile gezeigt. Operatoren, die
im Operatorbaum auf gleicher (horizontaler) Ebene liegen, lassen sich parallel ausführen. Dies
entsprechen in der Grafik die drei parallel ausführbaren Unteranfragen „S<S>P0“, „S<S>P1“
und „S<S>P2“. In der Operation „Union“ werden alle drei Ergebnisse wieder vereinigt, wel-
ches das Resultat der Anfrage q = (S,?p,?o) darstellt. Bei einer guten Aufteilung der Parti-
tionen auf mehrere P2P-Knoten führt dies dazu, dass drei unterschiedliche Peers die Anfragen
beantworten und die Ergebnisse zum Client senden.
3.4 Optimierungsstrategien
In diesem Abschnitt wird auf mögliche Optimierungen des Operatorbaums eingegangen, die
sich aus den fortgeschrittenen Verteilungsstrategien (siehe Kapitel 3.2.2) ergeben. Dazu zählt
zum Beispiel die Parallelisierung von Operationen sowie die Auslagerung von Berechnungen
auf andere Knoten im P2P-Netz, was eine Entlastung des Anfragepeers bewirkt.
Dazu bedarf es einer Ansammlung von bestimmten Transformationsregeln, die auf der Da-
tenstruktur des Operatorbaumes operieren. In SPARQL-Engines, wie z.B. LuposDate, sind
derartige Regeln bereits für die logische und physische Optimierung implementiert, die den
Grundumfang darstellen. Für die neuen konzipierten Verteilungsstrategien (siehe Kapitel 3.2.2)
sind daher Regeln zu implementieren, die in dem Evaluator integriert werden können, um die
Anfrage zu optimieren.
Wie bereits im vorigen Abschnitt gezeigt, ergeben sich je nach genutzter Verteilungsstrategie
bei bestimmten Anfragen mehrere Schlüssel, an denen entsprechende Tripel vorliegen können.
Diese Anfragen können parallel ausführbar mit Hilfe von zu verschickenden Unteroperator-
graphen realisiert werden. Dabei wird ein Teil des globalen Operatorbaumes in eine Anfrage
verpackt und zur Ausführung auf einen anderen Knoten ausgelagert. Da in diesem Fall diese
52
3 Konzeption
Unteroperatorgraphen lediglich eine Anfrage mit Hilfe eines Tripelmusters beinhalten, wird
dieses Konstrukt im Weiteren auch synonym als Unteranfrage oder Teilanfrage bezeichnet.
Jedoch bieten die Partitionen der Verteilungsstrategie noch weitere Vorteile: Wenn z.B. im
Operatorbaum Tripel-Anfragen mit gleichem P2P-Schlüssel gejoint werden, können diese ver-
eint in einem Unteroperatorgraph an den entsprechenden Schlüssel (der einem Peer zugeordnet
ist) gesendet und dann dort lokal am Knoten gejoint werden. Vor allem wenn die Ergebnis-
menge durch den Join stark verringert werden kann, führt das Joinen am anderen Knoten zu
einer geringeren Netzbelastung und außerdem zur Entlastung des anfragenden Knotens. Ein
Beispiel solcher Verschmelzungen von Unteroperatorgraphen (hier auch Unteranfragen), die
an den gleichen P2P-Schlüssel gesendet werden, ist in Abbildung 17 gezeigt. Dabei ist bei der
Optimierung auf die Join-Reihenfolge und das Join-Attribut zu achten.
Da in einer späteren logischen Optimierung immer nur zwei Unteroperatorgraphen mit glei-
chem Schlüssel gesucht und dann eine Änderungen vorgenommen wird, ist diese Regel nicht
nur einmalig anzuwenden, da im resultierenden Operatorbaum noch andere Join-Partner vor-
handen sein könnten. Als Abbruchbedingung für solche Optimierungsregeln genügt es, dass
eine Regel so oft angewendet wird, bis in einer Iteration keine Änderungen am Operatorgraph
mehr erfolgt. Diese Optimierungsstrategie für lokale Joins bei Unteroperatorgraphen mit glei-
chem P2P-Schlüssel kann zwar in bestimmten Fällen ausgenutzt werden, jedoch ist je nach
Verteilungsstrategie und Anfrage die Häufigkeit von gleichen Schlüsseln relativ gering.
Abbildung 17: Optimierung (rechts), durch Verschmelzung der Anfragen an gleiche Schlüssel.Die gleichen Schlüssel ergeben sich trotz unterschiedlichen Prädikats durch dieHashfunktion, welche in diesem Fall hash(P1) = hash(P2) = 0 ist. Die Tripel-muster, welche in den Unteranfragen ausgeführt werden, sind in der Abbildungkorrespondierend zu ihrer Unteranfrage aufgetragen.
53
3 Konzeption
In vielen Fällen kann jedoch aufgrund der Partitionierung ein lokaler Join zwischen gleich-
artigen Partitionen13 vorgenommen werden. So können alle n Partitionen, die nach voriger
Optimierung (vgl. Kapitel 3.3) parallel in Unteranfragen versendet werden, mit den n Partitio-
nen anderer parallel ausführbarer Unteranfragen gejoint werden, ohne dass die Ergebnisse der
einzelnen Partitionen am globalen Operatorgraph zusammengeführt und gejoint werden müs-
sen. In Abbildung 18 ist ein entsprechender Operatorgraph aufgezeigt, wobei die Optimierung
in dem unteren Teil der Abbildung dargestellt ist.
Abbildung 18: Optimierungen im Operatorbaum mit PartitionenOben: Operatorbaum mit parallelen Unteranfragen, wobei die Partitionen inder Objekt-Komponente gegeben sind.Unten: Verbesserung des Operatorbaumes durch lokales Join der zugehörigenPartitionen in der Objekt-Komponente
13Partitionen, wo die Komponente mit welcher die Partitionierung durchgeführt wird, übereinstimmt. Z.B. dieObjekt-Komponente in S<S1>O1 und S<S2>O1,
54
3 Konzeption
Dabei wurden alle parallelen Unteroperatorgraphen, die Unteranfragen beinhalten, mit gege-
benem Prädikat in die jeweiligen passenden Partitionen der parallelen Unteranfragen mit gege-
benem Subjekt verschoben. Diese Unteroperatorgraphen14 werden nun lokal an den jeweiligen
Knoten der Partitionen ausgeführt, wobei dort das eine Tripel-Muster direkt aufgelöst werden
kann (weil die Tripel an dem Knoten vorliegen) und die andere Unteranfrage von dort versen-
det (und das Ergebnis empfangen) wird. Das Ergebnis der Unteranfrage wird nun lokal mit
dem Ergebnis des direkt aufgelösten Tripel-Musters gejoint, sodass der anfragende Client in
diesem Szenario lediglich auf die Ergebnisse der 3 parallel ausführbaren Unteranfragen warten
muss.
Bisher wurden für die Optimierungsstrategien Beispiele gezeigt, die das Konzept der Opti-
mierung erläutern. Um allen möglichen Fällen für die Optimierung zu genügen, sind diese
Verbesserungen als Regelwerk für Unteroperatorgraphen des Operatorbaumes zu verstehen.
Die Anordnung von parallel ausführbaren Unteroperatorgraphen mittels Partitionen (vgl. Ka-
pitel 3.3) ergibt sich aus n parallelen Anfragen, die anschließend mit der Operation „Union“
vereinigt werden. Ist ein so definierter Teilgraph gefunden, wird von der Operation „Union“
ausgehend nach einer Join-Operation gesucht (Abbildung 19), die als Vorgänger (im Baum)
eine gleiche Struktur hat: Also Partitionen, die anschließend vereinigt werden (Abbildung 20).
Die Anzahl der Partitionen in der ersten und zweiten Struktur müssen übereinstimmen und
sich auf die gleiche Partitionskomponente beziehen. Da es für manche Anfragemuster alter-
native Schlüssel gibt15, sind diese auch zu beachten. So kann in der Verteilungsstrategie mit
der neunfachen Einfügung (siehe Kapitel 3.2.2, Teil 3) ein Tripel t = (S,P,O) mit der Anfrage
q = (S,?p,?o) in den Schlüsseln „S<S>P0“ . . . „S<S>P3“ oder in den Schlüsseln „S<S>O0“
. . . „S<S>O3“ hinterlegt sein (bei n = 3 Partitionen).
Abbildung 19: Verbindungsregel Teil 1: Finden von Partitions-Operatoruntergraphen
14Keine Unteranfragen mehr, da in dem Operatorgraph komplexere Operationen abgearbeitet werden.15Menge an Schlüsseln, welche die gleichen erforderlichen Tripel lokalisieren. Aufgrund der Determiniertheit ist
dies nicht bei allen Strategien möglich.
55
3 Konzeption
Abbildung 20: Verbindungsregel Teil 2: Finden von zugehörigen Partitions-Operatorunter-graphen
Stimmen die Partitionskomponenten überein, muss das Join-Attribut verglichen werden, wel-
ches sich auf die Partitionskomponente beziehen muss. Ansonsten können die einzelnen Parti-
tionen nicht miteinander gejoint werden, da der Hashwert der dritten Komponente nicht mit der
Schlüsselkodierung übereinstimmt (und auch die Disjunktheit der Tripelmengen nicht mehr ge-
währleistet ist). Denkbar wäre auch das Join-Attribut, das sich auf die Komponente bezieht, die
in beiden Schlüsseln vollständig gegeben ist. Sind diese Voraussetzungen eingehalten, müssen
die jeweiligen paarweise zugehörigen Partitionen gefunden werden (Abbildung 21).
Abbildung 21: Verbindungsregel Teil 3: Verbinden der Unter-Operatorgraphen und Säuberndes globalen Operatorgraphen
56
3 Konzeption
Sollten statistische Daten über die Größe der jeweiligen Relationen vorliegen, ist es ratsam, das
Joinen an der Partition durchzuführen, welche die größere Relation besitzt, um weniger Daten
übertragen zu müssen(Kemper & Eickler, 2001). In diesem Unteroperatorgraph ist nun der
zugehörige Operatorgraph zu integrieren, sodass sich ein verschachtelter Unteroperatorgraph
mit einem zweiten Unteroperatorgraph ergibt (siehe Beispiel von oben, Abbildung 18). Das
Ergebnis dieses integrierten Unter-Unter-Operatorgraphs muss mit dem Ergebnis des Anfra-
gemusters in dem Unteroperatorgraphen anhand des Join-Attributes gejoint werden. Der „ver-
schobene“ Untergraph muss anschließend aus dem globalen Operatorgraph entfernt werden, da
diese nicht mehr vom anfragenden Client auszuführen ist. Außerdem ist die Operation „Join“
aus dem Operatorbaum zu entfernen, da dieser nun lokal in der Unteranfrage ausgeführt wird
(Abbildung 21). Das „Union“, dass mit den nun verschobenen Unteroperatorgraph verbunden
war, sollte als Folge der vorigen Aktionen ebenfalls im Operatorbaum nicht mehr hinterlegt
sein, oder ist entsprechend zu entfernen. Das Ergebnis ist in Abbildung 22 dargestellt.
Abbildung 22: Verbindungsregel Teil 4: Endergebnis der Optimierung
57
4 Realisierung
In diesem Kapitel wird die Realisierung der Komponenten beschrieben, die in der Konzepti-
on beschrieben wurden. Dabei wird zuerst die Realisierung der P2P-Komponente, die an die
SPARQL-Engine »LuposDate« angebunden werden soll, erläutert. Anschließend wird auf die
Verteilungsstrategien und die Anfrageoptimierung eingegangen. Eine Übersicht über die rea-
lisierten Java-Packages und Java-Klassen finden sich im Anhang C mit einer Erklärung der
Funktionalität.
4.1 P2P-Architektur für RDF-Daten
Die einzelnen vorgestellten Projekte aus „Stand der Technik“ (Kapitel 2.2), welche sich bereits
mit P2P-Architekturen und RDF-Daten beschäftigen (u.a. RDFPeers und GridVine), haben al-
lesamt den Nachteil, dass sie das Versenden von Unter-Operatorgraphen nicht unterstützen.
Diese Funktionalität ist bereits in LuposDate und den beiden Projekten Fallstudie und Decent
Sparql vorhanden, was den Vorteil hat, diese Architektur für die Realisierung der konzipierten
P2P-Anbindung zu nutzen. Dabei werden zum jetzigen Stand in LuposDate lediglich Unter-
graphen an Endpoints gesendet, die via URL angesprochen werden. Diese Methode ist jedoch
statisch, sodass die Endpoints beim Starten der SPARQL-Engine bekannt sein müssen. Dies
kommt den Anforderungen eines dynamischen Netzes nicht nach, sodass diese Strukturen in
LuposDate nachgebessert werden, um den konzipierten Anforderungen aus Kapitel 3.1 zu ge-
nügen. Außerdem unterstützt LuposDate keine Erweiterungen für P2P-Systeme, sodass die
Funktionalität aus der Konzeption vollständig realisiert werden muss und eine lose Kopplung
für beliebige P2P-Implementationen geschaffen wird.
Da alle Projekte des in Java implementierten Systems LuposDate mit Unterstützung des Build-
Management-Tools Apache Maven1 erstellt wurden, wird für das Modul der P2P-Komponente
ebenfalls ein solches Projekt angelegt und die nötigen Abhängigkeiten der Bibliotheken einge-
richtet, sodass das erstellte Modul Zugriff auf Datenstrukturen der LuposDate-API hat. Auch
die Namensgebung von Packages und abgeleiteten Datenstrukturen wurde beibehalten, so dass
das Modul nicht als eigenständiges Programm sondern als wichtige Teilkomponente von Lu-
posDate heraussticht.
1http://maven.apache.org/, Apache
58
4 Realisierung
Als Beispielimplementierung eines P2P-Systems soll TomP2P2 verwendet werden. Es nutzt
eine verteilte Hashtabelle (DHT), die an den jeweiligen Knoten entweder persistent auf einer
Festplatte oder im Arbeitsspeicher existiert und Informationen über die Netz-Topologie sowie
verantwortliche Peers und Daten beinhaltet. TomP2P ist ebenfalls in Java implementiert und
nutzt den Java Standard Java NIO3 (Oracle, 2010), um parallel Anfragen beantworten und ver-
arbeiten zu können. Als Adressraum stehen 160bit zur Verfügung, was erlaubt, dass 2160 Peers
im Overlay-Netz teilnehmen können – das sind mehr als im Adressraum von IPv6 möglich
sind (Bocek, 2013b). Für das Routing verwendet TomP2P iteratives Routing mit symmetrischer
XOR-Metrik, um den dichtesten Knoten anhand des Schlüssels zu berechnen (d(x,y) = x⊕y),
das sich an dem Routingalgorithmus von Kademlia (Maymounkov & Mazières, 2002) orien-
tiert. Da TomP2P auf eine DHT aufbaut, lassen sich Bereichsanfragen nicht verarbeiten, sodass
ein Schlüssel stets angegeben werden muss. Damit sind Anfragen ohne feste Komponente wie
q = (?s,?p,?o) nicht zu beantworten. Im Gegensatz dazu unterstützt TomP2P Ausfallsicher-
heit und Kopien über Duplikate – Parameter, die jeweils pro Einfügung speziell gesetzt werden
können. Das kommt den Anforderungen des dynamischen Netzwerkes, das in dieser Arbeit
Anwendung findet, nach und erlaubt die Erreichbarkeit der Daten auch wenn ein Peer tempo-
rär keine Verbindung zum Overlay-Netz hat. Außerdem sind Signaturen und Zugriffskontrollen
implementiert, die im praktischen Einsatz von Nutzen sein können, wenn bestimmte Daten nur
autorisierten Clients zur Verfügung stehen sollen (Bocek, 2013a). Somit lassen sich auch RDF-
Daten unterschiedlicher Quellen gemeinsam im Netz hinterlegen, wobei die Abfragen jedoch
spezielle Berechtigungen benötigen bzw. in einem anderen Namensraum aufgelöst werden. Der
komplette Nachrichtenaustausch geschieht auf binärem Protokoll, um Overhead zu vermeiden
und die Bandbreite zu schonen (Bocek, 2013a).
Für die Anbindung eines beliebigen Datenlagers, in welchem die Tripel für die Anfragever-
arbeitung verwaltet werden, ist in der LuposDate-API die Klasse IStorage gegeben. Diese
gilt als Schnittstelle zwischen einem Evaluator, der die Anfragen ausführt und optimiert, und
dem RDF-Speicher (vgl. Architektur von LuposDate, Kapitel 2.1.3), welcher die RDF-Tripel
enthält. In Abbildung 23 ist dieses Interface dargestellt, welches für das P2P-Netz neu zu imple-
mentieren ist, da eine bisherige Implementierung sich damit begnügte, SPARQL-Anfragen zu
generieren und diese an die statisch voreingestellten Endpoint-URLs zu senden. Dabei werden
aus den dargestellten Funktionen addTriple() entsprechend INSERT DATA (...) An-
fragen, aus containsTriple() werden normale SELECT * FROM Queries, wobei das
Vorhandensein eines Ergebnis als Rückgabe genügt, sowie DELETE DATA (...) für das
entsprechende Löschen von Tripeln.
Für die P2P-Komponente ist jedoch keine SPARQL-Anfrage mehr zu generieren, da die ent-
sprechenden Befehle aus dem IStorage direkt in das Netzwerk übertragen und zum ent-
sprechenden Peer geroutet werden. In dem UML-Diagramm aus Abbildung 24 ist die ent-
sprechende Implementierung für das P2P-Netz dargestellt. Dabei übernimmt diese Klasse die
Entgegennahme von neuen Tripeln, die in das P2P-Netz über die Schlüssel der Verteilungsstra-
tegie gespeichert werden, das Löschen von Tripeln (über den entsprechenden Schlüssel) sowie
das Abfragen von Tripelmustern. Aufgrund der möglichen Speicherung von mehreren Tripel
2http://www.tomp2p.net3Java New I/O
59
4 Realisierung
Abbildung 23: UML-Klassendiagramm des Interfaces IStorage
Abbildung 24: UML-Klassendiagramm der IStorage-Implementierung StorageWithDistribu-tionStrategy
pro Schlüssel ist die Ergebnismenge anhand des Anfragemusters aufzubereiten. Hier werden
alle Daten des Schlüssels durchiteriert und die festen Komponenten des Datums mit der An-
frage verglichen. Findet ein Datum keine Übereinstimmung wird es aus der Ergebnismenge
gelöscht. Als Parameter für diese Klasse ist es zudem notwendig, die Verteilungsstrategie (vgl.
Kapitel 3.2) zu setzen wie auch die zu nutzende P2P-Implementierung, da diese die Funktio-
nalität bietet, das P2P-System zu bedienen sowie Schlüssel für das P2P-System aufgrund der
Verteilungsstrategie zu erstellen. Diese Parameter müssen später auf allen Peers des dynami-
schen Netzes gleich konfiguriert werden, sodass die Schlüsselauflösung auf jedem Peer unter
den gleichen Konfigurationen erfolgt und dieselben Verteilungsstrategien genutzt werden.
60
4 Realisierung
Abbildung 25: UML-Klassendiagramme zu der P2P-Implementierung in LuposDate
Die Implementierung eines P2P-Systems muss dabei die erstellte Klasse AbstractP2P-
Network<T> beinhalten, welche aus Funktionen besteht, die in einer Implementierung eines
P2P-Netzes für LuposDate und andere SPARQL-Engines unerlässlich ist und Grundfunktio-
nen von verteilten Hashtabellen sowie Datenlokalisierung und Nachrichtenaustausch voraus-
setzt. Wie in Abbildung 25 gezeigt ist diese Klasse generisch, wobei der Typ T das zu spei-
chernde, serialisierbare Datum spezifiziert, das im Netz verteilt werden soll. Dies ermöglicht
es, beliebige Informationen im P2P-System zu hinterlegen, die unabhängig von den Datenty-
pen aus LuposDate sind. Da in dieser Arbeit das Speichern von RDF-Tripeln eine Vorausset-
zung ist, wird, wie in der Abbildung angedeutet, eine neue Klasse entworfen, welche Funk-
tionalitäten beim Umgang mit Tripeln bereitstellt und die notwendigen Implementierungen an
die spezifizierten Klassen in Form von abstrakten Methoden weitergibt, sodass die abstrakte
Klasse P2PTripleNetwork lediglich den Datentyp Triple festlegt und weitere Funktio-
nalitäten bereitstellen kann, aber keine Implementierung eines P2P-Netzes vornimmt. Auch
um Abwärtskompatibilität zu gewährleisten, wurde bedacht, die Schnittstellen für die P2P-
Implementationen nicht weiter zu ändern oder diese Änderungen in späteren Entwicklungen
vorzunehmen. Eine entsprechende Erweiterung kann in der Klasse als funktionslose Methode
implementiert werden, die dann von einer P2P-Implementationen überschrieben und imple-
61
4 Realisierung
mentiert wird, um damit das Zusatzfeature zu unterstützen. Zu den bisher realisierten optiona-
len Features zählt der konzipierte lokale Evaluator, der nur auf die Daten, welcher der jeweilige
Knoten im P2P-Netz enthält, zugreift, sowie das Senden und Empfangen von Nachrichtenströ-
men übernimmt, welches vor allem bei großen Ergebnismengen genutzt werden kann. So wer-
den die Ergebnisse des Evaluators direkt zu dem Client gestreamt (auch wenn noch nicht alle
Ergebnisse feststehen), der diese dann nacheinander lesen und weiterverarbeiten kann, ohne
explizit auf das Nachrichtenende warten zu müssen.
Wie bereits in der Konzeption festgelegt, wird ein Manager realisiert (vgl. Abbildung 26),
der es ermöglicht, dynamisch neue Implementationen von P2P-Netzen zu registrieren und für
die Nutzung einer SPARQL-Engine bereitzustellen. Dabei muss die eindeutige Kennung der
P2P-Implementierung angegeben werden, wobei die Instanz mit weiteren optionalen Argumen-
ten zusätzlich konfiguriert werden kann (z.B. den Port, an welchem das P2P-Netzwerk „hor-
chen“ soll). Zur Registrierung eines neuen P2P-Systems muss die Implementation der Klas-
se P2PImplementation folgen. Die Instanziierung des P2P-Systems ist in der Methode
public AbstractP2PNetwork call() vorzunehmen. In diesem Aufruf kann optio-
nal abgefragt werden, ob Parameter für die Konfiguration (z.B. Port-Nummer des Peers, Boot-
strapping) übergeben worden sind. Diese P2PImplementation muss dann im Netzwerk-
Manager mit einer eindeutigen Kennung registriert werden.
Wie dem UML-Diagramm (Abbildung 25, S. 61) zu entnehmen ist, ist in allen P2P-Systemen
das Versenden und Empfangen von benutzerdefinierten Kommandos oder Nachrichten rea-
lisiert, da diese für das Ausführen von Untergraphanfragen in LuposDate genutzt werden.
Wie bereits in der Konzeption erwähnt, ist als erweiterte Funktionalität eines P2PTriple-
Networks ein Zugriff auf das lokale RDF-Datenlager zur Verfügung zu stellen. Dabei
ist auf jedem Peer ein lokaler Evaluator zu erstellen, der die Anfragen aus dem P2P-Netz
empfängt und dann auf dem lokalen Datenbestand ausführt. Außerdem muss dieser Evalua-
tor die Ergebnisse der Unteranfragen wieder an den Peer senden, der sie gestellt hat. Das
Versenden von Untergraphanfragen geschieht dabei in LuposDate serialisiert u.a. als JSON
oder XML, sodass die Kommunikation über Zeichenketten genügt. Für das lokale Daten-
lager der Peers wird wiederum das IStorage der LuposDate-API implementiert, wobei
hierbei jedoch nicht das P2P-Netz angeschlossen wird, sondern die lokale Datenquelle des
P2P-Systems des jeweiligen Peers. Wie bereits erwähnt, sind zusätzliche, optionale Funk-
tionalitäten in der abstrakten Netzwerk-Klasse mit dem Überschreiben von Funktionen zu
implementieren. Wenn die Methode boolean isLocalStorageSupported() in der
P2P-Implementierung überschrieben und aktiviert wird, wird in LuposDate über die Methode
IStorage getLocalStorage() ein Datenlager angesprochen, das nur auf die lokalen
RDF-Daten zugreift. Der Lupos-Evaluator wird bei der Nutzung eines P2P-Systems abfragen,
ob dieser eine lokale Zugriffsschicht bietet und entsprechend Unteranfragen an diesen Speicher
verweisen.
Eine Implementation eines P2PTripleNetworks ist das am Anfang des Kapitels vorgestell-
te System TomP2P4, das in der gleichnamigen Klasse TomP2P als zu nutzendes Komponente
für LuposDate realisiert ist. Dabei bietet es statische Methoden an, um neue Peerknoten zu ge-
4http://tomp2p.net/
62
4 Realisierung
Abbildung 26: UML-Klassendiagramm zur Verwaltung von verschiedenen P2P-Implementie-rungen
nerieren, welche jeweils im Konstruktor übergeben werden müssen. Mit Hilfe des bereits vor-
gestellten Managers, der die P2P-Implementierungen verwaltet, ist diese Peererstellung (und
Anbindung an ein womöglich existentes Netz) bereits vorgenommen, sodass durch die eindeu-
tige Kennung TOM_P2P eine neue Instanz der Implementierung erstellt wird und ein Peer auf
dem ausführenden Rechner gestartet wird. Für die erforderlichen Methoden des „Speicherns“,
„Auffindens“ und „Löschens“ von Tripeln nutzt TomP2P für den intern benutzten Schlüssel
eine eigene Hashfunktion, die den im IStorage mittels der Verteilungsstrategie erstellen
Schlüssel (KeyContainer<T>) erneut hasht und im P2P-Netz hinterlegt. Durch dieses zwei-
te Hashen des Schlüssels ist sichergestellt, dass der neue Schlüssel dem Schlüsselraum des
P2P-Netzes genügt, sodass durch diese Hashfunktion sichergestellt werden kann, dass eine in-
terne Verwaltung auf den zugeschalteten Peers problemlos funktioniert. Das liegt daran, dass
TomP2P auf verteilten Hashtabellen basiert, wobei jeder Peer einen bestimmten Bereich von
Schlüsseln gleichmäßig verwaltet. Würde der durch die Verteilungsstrategie erstellte Schlüs-
sel genutzt, weiß die interne Verwaltung von TomP2P nicht, wie die Bereiche gleichzuverteilen
sind, da die erstellen Schlüssel der Verteilungsstrategie nicht gleichverteilt auf der Kleeneschen
63
4 Realisierung
Hülle5 unseres Alphabets sind (Wagenknecht & Hielscher, 2009). Aufgrund der unbeschränk-
ten Länge eines solchen Schlüssels ergibt sich eine unbegrenzte Schlüsselmenge, die a priori
nicht unterteilt werden kann. Als Hashfunktion nutzt TomP2P in diesem Fall Number160.
createHash(locationKey), also einen 160bit-langen Hashwert, der gleichverteilt in der
Schlüsselmenge (hier: 2160) vorkommt. Je nach Wahl der Parameter, kann diese Hashfunktion
auch geändert werden, es ist jedoch zu bedenken, dass, je weniger Bit die Hashfunktionen in
seinem Ergebnis liefert, vermehrt Kollisionen auftreten können und auch zu bedenken ist, dass
die maximale Anzahl der Peers im Schlüsselraum Platz finden muss. Für das Versenden und
Empfangen von Nachrichten für Unteranfragen steht in TomP2P bereits die Funktionalität zur
Verfügung. Ebenso wird in der Klasse TomP2PLocalStorage ein Zugriff auf den loka-
len Datenspeicher des Peers zur Verfügung gestellt, sodass die TomP2P-Implementierung die
Möglichkeit bietet, parallelisierbare Unteranfragen im Netz zu versenden. Das Empfangen und
Versenden von Nachrichtenströmen wird erst in kommenden Versionen von TomP2P imple-
mentiert. Außerdem werden alle Daten im Arbeitsspeicher verwaltet, da die bereits integrierte
Auslagerung auf die Festplatte noch fehlerhaft ist.
Neben der Implementierung von TomP2P wurde das bereits in Kapitel 2.2 erläuterte modifi-
zierte Chordless (basierend auf Chord) in LuposDate integriert. Dabei ist jedoch zu bedenken,
dass das Versenden von Nachrichten im Netz nicht integriert ist. Eine nachträgliche Verbes-
serung des Systems hat außerdem gezeigt, dass die Knoten, welche die Tripel eines bestimm-
ten Schlüssels repräsentieren, nicht dieselben Knoten sind, die eine interne Nachricht selben
Schlüssels erhalten. Aufgrund dieser Fehllokalisierung treten beim Ausführen von Unteranfra-
gen, die im P2P-System versendet werden, auch Fehleinträge bei den SPARQL-Anfragen auf.
Dies zeigte bei einer näheren Analyse, dass das Speichern und Verteilen der Daten in Chordless
nicht alleine anhand des Schlüssels erfolgte, sondern aus einer Verbindung von Schlüssel und
Datum, sodass zwar das globale Auffinden von Daten problemlos funktioniert, lokales Auf-
lösen am entsprechenden Datenspeicher eines Knotens jedoch nicht übereinstimmt. Auch die
Re-Implementierung eines eigenen Nachrichtentyps beseitigte das Problem nicht, sodass die-
se Implementierung lediglich zu nutzen ist, wenn keine Nachrichten wie Unteranfragen oder
Teil-Operatorgraphen versendet werden. Aufgrund der in dieser Arbeit im Vordergrund stehen-
de Optimierung bei parallelen Anfragen an Partitionen, ist Chordless somit nicht einsatzfähig.
Wegen dieser Problematik könnten jedoch andere in Java entwickelte P2P-Systeme verwen-
det werden. So bietet sich FreePastry6 an, das wie TomP2P ebenfalls auf DHTs basiert und in
späteren Versionen integriert werden könnte.
Wie bereits erwähnt unterstützen die vorgestellten P2P-Systeme kein Senden von Nachrich-
tenströmen, sodass nur auf Zeichenketten basierte Nachrichten zwischen zwei Peers versendet
werden können. Da in zukünftigen Versionen von TomP2P dieses Feature integriert werden
soll, ist auf ein manuelles Bearbeiten verzichtet worden, welches zwischen den IP-Adressen
der Peers eine neue Verbindung aufbaut und strombasierte Kommunikation anbietet. Aufgrund
dessen ist das ursprüngliche verteilt funktionierende Endpoint-Network von LuposDate in ei-
ne P2P-Implementierung überführt worden. Diese überträgt die Daten zwischen den einzelnen
Endpoints über die HTTP-Schnittstelle, sodass auch Datenströme genutzt werden können. Wie
5Kleeneschen Hülle = Σ∗ des Alphabetes bezeichnet die Menge aller Wörter über dem Alphabet Σ6http://www.freepastry.org/FreePastry/
64
4 Realisierung
in der Konzeption erwähnt, ist das Senden von riesigen Datenmengen auf das Senden von
Strömen angewiesen, da die Zeichenketten ansonsten zu groß für den Arbeitsspeicher sind. Ein
Aufteilen in kleinere Nachrichten, die mittels laufender Nummer beim Empfänger wieder kor-
rekt zusammengesetzt werden könnten, ist nicht zu empfehlen, da dieses die Transportschicht
des OSI-Modells (International Telecommunication Union, 1994; Scheller et al., 1994) auf der
Applikationsschicht reimplementieren würde.
Die auf die Endpoints aufsetzende P2P-Implementierung ist in der Klasse Endpoint-
Network realisiert. Hierbei wird jedoch kein P2P-Netz instanziiert, sondern lediglich in
die verfügbaren Schnittstellen integriert. Dabei ist die Hashtabelle, die Aufschluss über die
verfügbaren Endpoints und dessen Schlüsselbereiche gibt, statisch implementiert. Es muss
in jeder Instanz eines EndpointNetworks dieselbe Liste von statischen URLs eingelesen
werden, unter welchen die Knoten erreichbar sind. Die Schlüsselbildung ist fest integriert und
erfolgt über MD5-Hashwerte, die mit dem mathematischen Ringoperator (Modulo) auf die
Liste der URLs verteilt wird. Die Kommunikation läuft über die HTTP-Schnittstelle ab, sodass
die Unteroperatorgraphen entweder via Zeichenkette oder als Nachrichtenstrom empfangen
und versendet werden können. Daher bietet sich diese P2P-Implementierung für das Testen
mit großen Datenmengen an. Im Gegensatz zu TomP2P speichern die Endpoints die Daten
auf der Festplatte ab, wobei häufig genutzte Tripel im Cache verbleiben. Dies geschieht über
die RDF-Speicherlösung RDF3X (Neumann & Weikum, 2010, 2008), die effizientes Lokali-
sieren durch sechs verschiedene Sortierungen der Tripel bietet, die in B+-Bäumen persistent
abgespeichert werden. Das ursprünglich in C++ veröffentlichte Projekt wurde in Java reimple-
mentiert, erweitert und anschließend in LuposDate integriert (Groppe et al., 2009b). Um die
initialen Daten für den RDF-Speicher nicht manuell über den Anfrageevaluator von LuposDate
zu laden, wurden zwei statische Methoden realisiert, die für die Verteilung und Indexerstellung
zuständig sind. Diese lassen sich per Kommandozeile aufrufen. Der erste Aufruf überführt
eine N3-Datei in mehrere N3-Dateien, welche aufgrund der Verteilungsstrategie ein Tripel auf
die verfügbaren Knoten (Endpoint-URLs) aufteilt. Der zweite Aufruf wird anschließend auf
jedem Knoten mit seiner entsprechenden (zuvor erstellten) N3-Datei aufgerufen: Dabei parst
das Programm die Daten und speichert diese im Festplatten basierten Index von RDF3X.
Die Schicht zwischen P2P-System und dem Evaluator für die Verarbeitung von Untergra-
phanfragen stellt die Schnittstelle ISubgraphExecuter aus der LuposDate-API bereit.
Dessen Realisierung ist in der Klasse P2P_SubgraphExecuter erfolgt. Wie im UML-
Klassendiagramm in Abbildung 27 gezeigt, wird neben dem Interface aus der LuposDate-
API zusätzlich ein Nachrichtenlistener implementiert. Dieser stellt die Verbindung zum
P2P-System, welches je nach Nachrichtentyp (Nachrichtenstrom oder Zeichenkette) die
onMessage(...)-Funktionen auslöst, wenn eine neue Nachricht empfangen und ver-
arbeitet werden soll. Diese Daten werden dann dem P2P_SubgraphExecuter wei-
tergeleitet. Eine Rückantwort wird asynchron direkt an die bereits erläuterte Instanz des
AbstractP2PNetworks über die Funktionen send(...) abgesetzt. Um die versende-
ten Nachrichten zu identifizieren, bedarf es eindeutigen Nachrichtenkennungen (vgl. Kapi-
tel 3.1), sodass die Objekte P2PMessage und P2PInputStreamMessage die eigent-
lichen Operatorgraph-Nachrichten in ein internes Format einbettet und mit Zusatzinforma-
tionen füllt. Für Zeichenketten basierte Kommunikation wird in einer P2PMessage eine
65
4 Realisierung
neue Nachricht erzeugt, welche zusätzlich die Nachrichtenkennung und Empfangsschlüssel
beinhaltet. Für die strombasierte Kommunikation dienen statische Funktionen der Klasse
P2PInputStreamMessage. Dort kann ein Header erzeugt werden, der zuerst in den Nach-
richtenstrom geschrieben werden muss. Dieser Header besteht aus 37 Bytes und beinhaltet
Nachrichtentyp und -kennung, die für eine Zuordnung in der Verarbeitung wichtig ist. Für
das Auslesen des Headers sind ebenfalls statische Methoden implementiert. Der Arbeitsab-
lauf für das Senden, Evaluieren und Empfangen von Untergraph-Nachrichten läuft wie folgt
beschrieben ab:
• Ein aus LuposDate versendeter Operatorgraph wird in evaluate(K, String) emp-
fangen. Der Empfängerschlüssel (K) wird generiert und über zeichenkettenbasierte Kom-
munikation zu dem entsprechenden Peer versendet. Zuvor wird eine neue Nachrichten-
kennung erzeugt sowie ein DelayedResult<QueryResult>, welches so lange blo-
ckiert, bis eine Antwortnachricht (mit dem Ergebnis) empfangen wurde. Maximale Aus-
führungszeiten verhindern das Einfrieren der Applikation, wenn der Empfängerknoten
nicht zeitgerecht antwortet.
• Das (entfernte) P2P-System empfängt die Nachricht und leitet diese und die Senderken-
nung an die lokale Instanz des P2P_SubgraphExecuters (onMessage(String
msg, String sender)). Dort wird die Nachricht entsprechend entpackt und der
Unteroperatorgraph am lokalen Evaluator ausgeführt. Dabei ist die gleiche Verteilungs-
strategie zu wählen, die auch beim Sender gesetzt wurde. Wenn das P2P-System strom-
basierte Nachrichten unterstützt, wird ein neuer InputStream erzeugt, dem zur Iden-
tifizierung der Header (P2PInputStreamMessage) zugefügt wird. Anschließend
können die Ergebnisse parallel via Nachrichtenstrom zum Empfänger gesendet werden
(AbstractP2PNetwork#sendMessage(InputStream,String)). Sollte kei-
ne Kommunikation über Nachrichtenströme möglich sein, wird das Ergebnis serialisiert
(z.B. in JSON) zum anfragenden Client zurückgesendet.
• Das P2P-System des Clients, der die Anfrage gestellt hat, empfängt entweder den Nach-
richtenstrom oder die Nachricht und gibt diese zusammen mit der Absenderkennung
an P2P_SubgraphExecuter#onMessage(...) weiter. Dort wird die Nachricht
entpackt (bzw. der Header ausgelesen) und das bei der Anfrageversendung erstellte
DelayedResult<QueryResult> mit der entsprechenden Nachrichtenkennung
angestoßen, sodass das empfangende Ergebnis in LuposDate verarbeitet werden kann.
Dieser Ablauf ist auch in mehreren Ebenen ausführbar, sodass eine Unteranfrage wiederum als
neue Unter-Unteranfrage weitergeleitet, auf das Ergebnis gewartet und verarbeitet zurückge-
sendet werden kann. Außerdem lässt sich konfigurieren, wie viele Anfragen parallel bearbeitet
werden sollen. So kann je nach Rechnersystem und der Anzahl der Kerne die Parallelität hoch-
gestellt werden. Außerdem lassen sich für Entwicklungszwecke die ausgeführten Aufgaben
darstellen, sodass erkennbar ist, welche Nachrichten noch in der Bearbeitung sind und bei wel-
chen bereits das Ergebnis versendet wurde. Auch für Statistiken lässt sich der Durchsatz von
Tripeln beim Lesen aus dem Nachrichtenstrom bzw. beim Schreiben in dem Nachrichtenstrom
darstellen.
66
4 Realisierung
Abbildung 27: Klassendiagramm für die Verarbeitung von Unteroperatorgraphanfragen
In LuposDate werden bisher lediglich sequentielle, lineare Unteroperatorgraphanfragen un-
terstützt. Diese erlauben es, dass in den Unteranfragen lediglich ein (Ausführungs-)Pfad ab-
gearbeitet werden kann. Vor allem bei den konzipierten Joins mit Partitionen (Kapitel 3.3)
treten jedoch, wie z.B. in Abbildung 18 auf Seite 54, Verzweigungen auf, die in der bisheri-
gen Version von LuposDate nicht unterstützt werden. Deshalb mussten entsprechende Klassen
der LuposDate-API verändert werden, die für die Serialisierung und Deserialisierung zwischen
Operatorbaum und JSON zuständig sind. In JSON wird dabei kodiert, wie die jeweiligen Ope-
ranten im Graph verbunden sind. In dieser Graphserialisierung7 wird nun auch die Verzwei-
gung unterstützt, wie auch die Integration von Untergraphanfragen in selbigen. Dazu wurde
die Klasse SubSubgraphContainerFormatter erstellt, die eine Unteranfrage in einer
Unteranfrage verpacken kann und diese später auch beim Empfänger wieder zurück umsetzt
und ausführt.
7Serialisierung von Knoten und Kanten, sowie dessen Verbindungen (z.B. als Adjazenzliste)
67
4 Realisierung
4.2 Verteilungsstrategien
Die Verteilungsstrategien sind bereits in Kapitel 3.2 ausführlich erklärt worden. Das vorrätige
Interface IDistributionKeyContainer<T> (vgl. Abbildung 28) aus der LuposDate-
API kann dafür weiterhin verwendet werden, wobei als Typ T die Klasse String gewählt
wurde, da diese für die Endpoints und bereits implementierten Verteilungsstrategien bereits
genutzt wird.
Abbildung 28: UML-Diagramm der Schnittstelle IDistribution
Im IDistributionKeyContainer<T> werden die Schlüssel für das Speichern von
Tripeln sowie für die Abfragen von Tripelmustern erstellt. Diese Schlüssel werden als Paar
aus Type und Key übertragen, wobei hier der Typ die jeweilige kodierte Notation der Vertei-
lungsstrategie (vgl. Kapitel 3.2) ist und der Schlüssel die Konkatenation der zu benutzenden
Komponenten im RDF-Tripel. In dem folgenden Beispiel wird die einfache Verteilungsstrate-
gie (Kapitel 3.2.1) genutzt, bei welcher jede Komponente als Schlüssel gehasht wird (S, P, O).
Für das Speichern eines Tripels <S><P><O> werden hier die drei KeyContainer8
KeyContainer<String>("S",toString(<S>))
KeyContainer<String>("P",toString(<P>))
KeyContainer<String>("O",toString(<O>))
erstellt, die als Schlüssel für das P2P-Netzwerk dienen. Bei der einfachen Partitionierung (vgl.
Kapitel 3.2.2) wäre einer der drei KeyContainer analog:
KeyContainer<String>("SP","S"+toString(<S>)+"P"+hash(<P>))
Die einfachen Verteilungsstrategien aus Kapitel 3.2.1 sind analog in den jeweiligen Klassen
OneKeyDistribution (nur eine Komponente wird jeweils gehasht: S, P, O; 3-fache Da-
ten), TwoKeysDistribution (Konkatenation zweier Komponenten wird gehasht: SP, PO,
OS; 3-fache Daten) bzw. OneToThreeKeysDistribution (Alle Möglichkeiten werden
gehasht: S, P, O, SP, PO, OS, SPO; 7-fache Daten) realisiert.
Für die einfach hierarchische Verteilungsstrategie mit Partitionierung ist die Implementierung
in der Klasse SimplePartitionDistribution realisiert. Dabei führt die besproche-
ne Determiniertheit der Schlüsselgenerierung zu einer Reduktion der Schlüsselkombinationen,
8Die Methode toString() erzeugt eine repräsentierbare Zeichenkette der jeweiligen Komponente des Tripels.
68
4 Realisierung
sodass bei diesem Verfahren auch je Tripel drei Schlüssel generiert und somit die dreifache Da-
tenmenge im P2P-Netz hinterlegt wird. Für den Fall, dass das Problem mit der Determiniertheit
gelöst wird, ist bereits die Möglichkeit integriert, zufallsbasiert einen Schlüssel aus der Menge
an passenden Schlüssel auszuwählen. Die Schritte, um diese Funktionalität zu aktivieren, sind
in der realisierten Java-Klasse beschrieben.
Die Verteilungsstrategie mit zwei Partitionierungen und Schlüsselkombinationen der Länge
drei ist in der Klasse TwoPartitionsDistribution realisiert. Hierbei sind auch auf-
grund der Determiniertheit nur die Schlüsselpaare „SPO“, „PSO“ und „OPS“ implementiert.
Die Verteilungsstrategie mit der 9-fachen Datenmenge, die bei der Einfügung eines Tripels im
P2P-Netz gespeichert wird, ist in der Klasse NinefoldInsertionDistribution rea-
lisiert. Aufgrund späterem Nutzen bei der Optimierung von Anfragen mit dieser Verteilungs-
strategie, bleibt die Klasse entsprechend der Konzeption mit allen 9-Schlüsselkombinationen
bestehen. Dabei sind ebenfalls die Spiegelpaare integriert. Um diese jedoch nutzen zu können,
ohne die Determiniertheit zu verletzen, wurde die Klasse AlternativeKeyContainer
als Ergänzung zum KeyContainer erstellt (vgl. Abbildung 29). Dabei kann diese Klas-
se abwärtskompatibel mit der LuposDate-API umgehen, sodass die alternativen Schlüssel
lediglich ignoriert würden. Mit Hilfe von alternativen Schlüsseln können jedoch im Eva-
luator Optimierungen (siehe Kapitel 4.5) vorgenommen werden, sodass die Wahrschein-
lichkeit von zwei Untergraph-Anfragen mit gleicher Partitionsart steigt. So kann in einem
AlternativeKeyContainer neben dem Type und Key auch noch eine Liste von alterna-
tiv gültigen Schlüsseln angehängt werden, da bei vielen Anfragen eine Menge von Schlüsseln
gültig sein kann. Zum Beispiel ist die Anfrage q = (s,?p,?o) in den Schlüsselkombinationen
„SP“ oder „SO“ verarbeitbar.
Abbildung 29: UML-Diagramm der Schnittstelle AlternativeKeyContainer
4.3 Parallelität bei Partitionsanfragen
In der bisherigen Implementierung von LuposDate wird von einer beliebigen Verteilungsstrate-
gie, die im Interface IDistributionKeyContainer realisiert ist, nur der erste Schlüssel
eines Anfragemusters verwendet und in eine Untergraphanfrage (ISubgraphContainer)
verpackt. Wie bereits in der Konzeption (Kapitel 3.3) angemerkt, werden im P2P-Netz alle
zurückgegebenen Schlüssel benötigt, da die Summe der disjunkten Partitionsergebnisse das
Gesamtergebnis bildet. Im Fall von Endpoint-URLs war dies bisher nicht nötig. Diese neuen
69
4 Realisierung
Anforderungen werden dabei in LuposDate entsprechend umgesetzt. Ansonsten würde, wie in
der bisherigen Implementierung, nur der jeweils erste Schlüssel abgefragt werden, was zu ei-
nem leeren Ergebnis führen könnte, wenn die korrekten Tripel z.B. im dritten Schlüssel einer
Partition gespeichert wären.
Für diese Anpassung ist eine Modifikation der Klasse AddSubgraphContainerRule aus
der LuposDate-API nötig:
1 distribution.getKeysForQuerying(indexScan
2 .getTriplePattern().iterator().next())[0];
Dabei wird die jeweilig genutzte Verteilungsstrategie nach den Schlüsseln gefragt, die für die
gegebene Tripel-Abfrage (TriplePattern) erforderlich wären. Der globale Operatorgraph
wird dann so verändert, dass alle möglichen Schlüssel berücksichtigt werden: Nun wird je
Schlüssel ein SubgraphContainer (Unteroperatorgraphanfrage) erstellt, der parallel aus-
führbar ist und das entsprechende Anfragemuster enthält. Außerdem vereinigt sich das Ergeb-
nis aller Unteranfragen in der Operation Union. Dabei sind alle Operationen, die im Operator-
graph in der gleichen Ebene liegen, parallel ausführbar. Die Vereinigungsoperation (Union)
wartet auf alle Ergebnisse und übergibt sie der nächsten Operation im Operatorgraph, die dann
die gesamte Datenmenge weiterverarbeitet. In Abbildung 30 wird das Ergebnis des globalen
Operatorgraphs der nachfolgenden SPARQL-Anfrage gezeigt9, wobei durch die Verteilungs-
strategie die vier Partitionen der Schlüsselkombination „PO“ parallel abgefragt werden kön-
nen:
1 PREFIX ub: <ub#>
2 SELECT ?X ?Y
3 WHERE
4 { ?X ub:publicationAuthor ?Y}
Abbildung 30: Beispiel für parallele Unteranfragen, sowie die Vereinigung der Ergebnisse imOperatorgraph
9Aus Gründen der Übersicht, wurden die Präfixe aus der Originalabfrage verkürzt.
70
4 Realisierung
Ohne die Änderungen wäre anstatt der vier parallelen Unteranfragen nur eine Unteranfrage im
Operatorgraph erkennbar (die sich nur auf die erste Partition auswirken würde). Es ist auch
zu bedenken, dass eine Vereinigung (Union) optional ist, wenn von der Verteilungsstrategie
lediglich ein Schlüssel geliefert wird. In diesem Fall kann eine Optimierung des Operatorbaums
erfolgen, indem die überflüssige Operation entfernt wird.
Außerdem wird in LuposDate der Operatorgraph stets iterativ ausgeführt, was zu einer Blo-
ckierung führt, wenn der Prozess der Abarbeitung einer Operation zu lange dauert. So werden
die in einer Ebene liegenden Operatoren im Operatorbaum nacheinander ausgeführt, anstatt
alle Operationen anzustoßen und auf dessen Ergebnisse zu warten. Wenn solche Operato-
ren jedoch SubgraphContainer sind, die zu anderen Peers gesendet und dort ausge-
führt werden sollen, wird im globalen Operatorgraph erst fortgefahren, wenn das Ergebnis
zurückgesendet wurde. Vor allem wenn diese Unteroperatorgraphen weitere Unteroperator-
graphen enthalten, ist diese Operation sehr zeitaufwändig. Damit die parallel ausführbaren
Operationen ebenfalls ausgeführt werden und gemeinsam auf das Ergebnis aller Operationen
gewartet wird, bis die nächste Ebene des Operatorbaum ausgeführt wird, muss in Lupos-
Date eine Änderung in der Klasse SubgraphContainer vorgenommen werden, wobei
die Strukturen für asynchrones Ausführen von Operatoren in LuposDate bereits angelegt
sind. Dabei wird über interne Nachrichten, die durch den Operatorgraph versendet werden,
die Beendigung der Ausführung eines Operators mitgeteilt. In einer Anpassung wird diese
Nachricht asynchron dann versendet, wenn das Ergebnis des Untergraphs eingetroffen ist.
Beim Starten der Ausführung des SubgraphContainers wird dabei gleich ein leeres
Ergebnis zurückgegeben, was dazu führt, dass die nächste verfügbare Operation ausgeführt
werden kann. Im Hintergrund wird jedoch der Unteroperatorgraph entsprechend im P2P-Netz
versendet. Beim Eintreffen des Ergebnis wird dann eine entsprechende EndOfEvaluation
-Nachricht versendet, die dem Vorgänger-Operator mitteilt, dass das Ergebnis angekommen
ist. Sobald alle EndOfEvaluation-Nachrichten der parallel ausgeführten Operatoren an-
gekommen sind, kann der Operatorbaum weiterabgearbeitet werden. Diese Funktionalität
wurde in einer entsprechenden Klasse AsynchronSubgraphContainer implemen-
tiert, die von der ursprünglichen LuposDate-Klasse SubgraphContainer vererbt wird.
Um diese nicht blockierende Versendung von Unteroperatorgraphen zu nutzen, wird außer-
dem eine Optimierungsregel (siehe Kapitel 4.5.7) erstellt, welche den Austausch zwischen
SubgraphContainer und AsynchronSubgraphContainer vornimmt. Dies ermög-
licht es, in den anderen Nutzungskontexten von LuposDate die ursprüngliche Methode zu
verwenden, sodass nur beim P2P-System die Regel angewendet und das asynchrone Ausfüh-
ren ermöglicht wird.
4.4 Abfrageauswertung
Die Auswertung und Optimierung der Abfragen erfolgt im Framework LuposDate über einen
QueryClient, der einen Evaluator um Konstruktoren erweitert, die es ermöglichen, eine
Abfrage über die grafische Schnittstelle von LuposDate abzusetzen. Dieser Evaluator führt die
Optimierungen am Operatorgraph durch und startet die Anfrage, sowie im Fall von Unterope-
71
4 Realisierung
ratorgraphen die Verteilung der Untergraphen an die jeweiligen Knoten. Außerdem dient die
Speicherebene (IStorage) in LuposDate für das konkrete Ansprechen von Tripeln, wobei
im Fall der Endpoint-URLs von hier SPARQL-Anfragen erstellt und an die Endpoints gesen-
det wurden, die daraufhin lokal die Speicherung vornehmen. So muss das IStorage kein
endgültiges Datenlager wiederspiegeln, sondern dies lediglich abstrahieren und mit der Wei-
terleitung der Daten dafür sorgen, dass es verteilt gespeichert wird.
Um einen solchen Evaluator in der Lupos-GUI zu registrieren, ist eine Registrierung der
Klasse nötig. Dabei muss ein Anzeigename festgelegt werden, der in dem Auswahlfeld
eines Evaluators in der grafischen Schnittstelle erscheint, sowie der Klassenname eines
QueryEvaluators. Da hier lediglich der Klassenname parameterlos übergeben wird,
kann hier keine nähere Spezifikation des P2P-Netzwerks oder die Verteilungsstrategie va-
riabel festgelegt werden. Dies führte dazu, dass je Verteilungsart eine eigene Klasse von dem
QueryClient abgeleitet werden müsste, welche die Verteilungsart spezifiziert. Verbunden
mit den verschiedenen P2P-Systemen ergibt das etliche neue Klassen, die in der GUI registriert
werden müssten.
Für die P2P-Integration wird ein P2P_QueryClient erstellt, der die Optimierungen für den
P2P-Fall abdeckt und weiterhin Einstellungen und Parameter für den verteilten Einsatz defi-
niert. Dieser Evaluator kann nun vererbt werden, wobei in der jeweiligen abgeleiteten Klasse
die zu nutzende P2P-Implementation sowie das IStorage und die Verteilungsstrategie fest-
gelegt werden. In der Methode public QueryResult evaluateTriplePattern(
final TriplePattern triplePattern) der jeweiligen IStorage-Implementie-
rung werden sodann die jeweiligen TriplePattern abgefragt. Da für das Abfragen von
Tripeln aus dem P2P-Netz wiederum Schlüssel nötig sind, wird über die Verteilungsstrategie
mittels public KeyContainer<T>[] getKeysForQuerying(TriplePattern
triplePattern) der jeweilige Schlüssel erfragt, der dann für die Anfrage im P2P-Netz
genutzt wird. Wie bereits in Kapitel 3.2.3 festgestellt, müssen diese Methoden deterministisch
sein, damit auf allen Peers im Netzwerk dieselben Schlüssel bei gleicher Eingabe erzeugt
werden.
Aufgrund der verschiedenen Konfigurationsmöglichkeiten, ergäben sich bei der Vielfalt an Ver-
teilungsstrategien (7) und P2P-Implementierungen (3) zu viele Klassen (21), die in einer GUI
registriert werden müssten. Außerdem bietet es sich beim Testen der realisierten Systeme an,
unabhängig von einer GUI, in welcher sowohl die RDF-Daten wie auch die Abfragen visu-
ell aufbereitet eingegeben werden, zu arbeiten. Deshalb wurde neben einer Implementierung
eines P2P_QueryClients, das TomP2P mit den fortgeschrittenen Verteilungsstrategien be-
reitstellt, ein Kommandozeilen-Programm erzeugt. Dieses ermöglicht es sowohl über Parame-
ter wie auch durch ein Menüsystem die Einstellungen vorzunehmen. Die einzelnen Parameter
hierzu finden sich im Anhang D. Die Klasse Commandline im Java-Package console lässt
sich auch über ein selbst-ausführendes Java-Programm starten.
72
4 Realisierung
Dabei werden unter anderem folgende Einstellungsmöglichkeiten geboten:
• Auswahl des P2P-Systems
• Festlegen der Ports, auf welche der Knoten auf Verbindungen warten soll
• Verbindung mit einem bereits gestarteten P2P-Systems (Master-Peer) über dessen IP-
Adresse und Port
• Auswahl der Verteilungsstrategie
• Auswahl der implementierten Benchmark-Tests
Außerdem können Logging-Parameter eingestellt oder das Anzeigen der Operatorgraphen nach
der Optimierung aktiviert werden. Sobald die Einstellungen vorgenommen wurden (entweder
per Menüeingabe oder durch Konfigurationsdateien und Kommandozeilenparameter) können
folgende Aktionen getätigt werden:
• Einfügen von Tripeln (z.B. über N3-Dateien)
• Ausführen von SPARQL-Abfragen
• Ausführen von Benchmark-Tests
4.5 Optimierungsstrategien
In diesem Abschnitt werden die nötigen Optimierungsstrategien aus der Konzeption (vgl. Ka-
pitel 3.4) sowie in der Realisierung erkannte Optimierungen umgesetzt und in LuposDate inte-
griert.
Mit Hilfe des RuleEditors von LuposDate ist es relativ einfach, Regeln zur Optimierung
eines Operatorbaums zu realisieren. Dabei können einfache Optimierungen durch Model-
lierung von Vorher- und Nachherzuständen als Regel aufgefasst werden. Der Editor erstellt
daraufhin eine Java-Klasse, die in der logischen Anfrageoptimierung ausgeführt werden kann.
Bei der Evaluierung der Regel überprüft LuposDate, ob der jeweilige modellierte Unter-
graph im Operatorbaum vorhanden ist, und nimmt ggf. die implementierte Optimierungen
vor. Dabei werden in LuposDate die Regeln in der Klasse Rule implementiert. In dem
UML-Diagramm in Abbildung 31 ist ersichtlich, dass unter anderem eine Funktion boolean
check(BasisOperator) zu realisieren ist. Dabei läuft LuposDate jeden Knoten (jeden
Operator) des Operatorbaumes ab und überprüft in der Methode, ob die Regel anhand des ak-
tuellen Operators angewendet werden kann. Sollte diese zutreffen, also theoretisch anwendbar
sein (Vorbedingung), ist die Transformation des Operatorgraphs in void replace(...)
anzuwenden (Umsetzung). Der Regel-Editor von LuposDate implementiert diese Methoden
anhand der erwähnten grafisch erstellten Vorher-Nachher Strukturen.
In den folgenden Unterabschnitten werden die erstellten LuposDate-Regeln beschrieben, die
für die P2P-Komponente nötig sind (vgl. Kapitel 3.4).
73
4 Realisierung
Abbildung 31: UML-Klassendiagramm für die Implementierung von Optimierungsregeln an-hand des Operatorbaums.
4.5.1 Vermeidung der Operation „Union“ bei einseitiger Quelle
Diese Optimierung tritt bei der Nutzung von versendbaren Unteroperatorgraphen (Subgraph-
Container) ein, wenn lediglich ein Schlüssel bei der Abfrage eines Tripel-Musters erfor-
derlich ist. Aufgrund der Anpassungen, die alle gegebenen Schlüssel der Verteilungsstrate-
gie berücksichtigt, kann es vorkommen, dass bei Anfragen lediglich ein Schlüssel zurück-
gegeben wird. Daraus resultiert nach der angesprochenen Modifikation die Abfolge von
SubgraphContainer und Union, wobei die Vereinigung der Datenmenge bei ledig-
lich einem Vorgänger, dem SubgraphContainer wenig Sinn macht. Diese Regel erkennt
diesen Zustand und beseitigt diesen, indem die Operation Union entfernt wird.
In Abbildung 32 ist ein Ausschnitt des RuleEditors zu sehen, der die beschriebene Regel de-
finiert, die aus einer Verkettung von einem SubgraphContainer und der anschließenden
Vereinigung (UNION), eine Optimierung vornimmt. Diese Regel lässt sich aus dem Editor ex-
portieren und in die LuposDate-Engine integrieren, wobei dies entweder in einer bestehenden
Regelsammlung hinterlegt wird oder manuell in der Anfrage-Optimierung des Evaluator (z.B.
beim P2P_QueryEvaluator in der Methode int logicalOptimization(...)).
Die beispielhafte Anwendung der Regel ist im Operatorbaum aus Abbildung 33 dargestellt.
4.5.2 Lokaler Join von Unteroperatorgraphen gleichen Schlüssels
Aufgrund der möglichen Kodierung der Schlüssel in der P2P-Komponente wird es bei den
fortgeschrittenen Verteilungsstrategien (Kapitel 3.2.2) vorkommen, dass in einer SPARQL-
Abfrage mehrere Anfragen über Unteroperatorgraphen an die gleichen Schlüssel gesendet wer-
den (vgl. Kapitel 3.4). Diese Regel wurde in LuposDate integriert und wird in der logischen
74
4 Realisierung
Abbildung 32: RuleEditor: Die entsprechende Regel, die das Vereinigen der Ergebnisse beinur einem SubgraphContainer verhindert. Auf der linken Seite wird die zu su-chende Struktur (SubgraphContainer, Union, bel. Operator) gesucht und in dieStruktur der rechten Seite überführt, wobei die eindeutig vergebenen Namengleiche Operatoren darstellen.
Optimierung des Operatorbaums angewendet. Wie bereits in der Konzeption erwähnt, müs-
sen die beiden Unteroperatorgraphen (SubgraphContainer) und das Join-Attribut über-
einstimmen. Dabei ist die Tiefe des zweiten SubgraphContainer unabhängig von dem
in der Konzeption gezeigtem Beispiel, sodass in der Lupos-Regel folgende Struktur gesucht
wird: SubgraphContainer mit anschließendem Union und einem Join in beliebiger Ebe-
ne unter dem Union. Von diesem Join ausgehend wird daraufhin wieder ein Union als
Vorgängeroperator gesucht, der eine Untergraphanfrage mit dem gleichen Schlüssel wie der
Ausgangs- SubgraphContainer haben muss. Daraufhin kann die Regel, die in der Klas-
se JoinSGRule realisiert wurde, angewendet werden. Dabei ist wieder die Struktur aus der
LuposDate-API genutzt, sodass die Vorbedingung das Auffinden der erklärten Struktur aus-
macht und in der letztlichen Regelausführung die Optimierung vorgenommen wird. Dabei wird
der zweite SubgraphContainer in den ersten integriert und anschließend aus dem Opera-
torbaum entfernt.
4.5.3 MultiInputRule
Je nachdem wie die konzipierten Regel aus Kapitel 3.4 in LuposDate umgesetzt wurden, kön-
nen bei der Konkatenation verschiedener Regeln Strukturen im Operatorbaum entstehen, die
später nicht ausgeführt werden können. Vor allem bei der Verschiebung von Operatoren ist
es möglich, dass diese im Operatorbaum noch integriert sind. Vor allem bei Operatoren, die
mindestens zwei Eingangsoperatoren (Vorgänger) haben müssen, aber durch die Optimierung
nur noch einen Vorgänger besitzen, ist diese Operation oft zu entfernen. Um diese Struktur
nicht in allen implementierten Regeln einzeln prüfen und die Transformation vornehmen zu
75
4 Realisierung
(a) vor der Optimierung (b) nach der Optimierung
Abbildung 33: Operatorbaum mit einem SubgraphContainer und Union vor und nach der Op-timierung: Der unnötige Operator Union wird aus dem Operatorgraphen ge-löscht.
müssen, wird eine MultiInputRule realisiert, welche derartige Operatoren sucht, die zwei
Vorgänger-Operatoren (MultiInputOperator) benötigen, jedoch nur einen Vorgänger be-
sitzen. Diese Regel ist eine Verallgemeinerung der Union-Regel aus Kapitel 4.5.1, da der Ver-
einigungsoperator in LuposDate ebenfalls ein MultiInputOperator ist.
4.5.4 Lokaler Join bei Partitionsanfragen
In Kapitel 3.4 wurde die Ausnutzung von parallelen Joins bei Verteilungsstrategien mit Partitio-
nen erwähnt. Für die Umsetzung wurde dabei das beschriebene Regelwerk in der LuposDate-
Klasse Rule implementiert. Für die Überprüfung der jeweils vermeintlich passenden Parti-
tionen, ob ein lokaler Join an einer Partition durchgeführt werden kann, sind in dieser Re-
gel zusätzliche Methoden zur Überprüfung realisiert. Wie bereits im Kapitel 4.4 erwähnt,
erlauben es manche Verteilungsstrategien, redundante Schlüssel für das P2P-Netz zu spei-
chern. Dabei ist ein entsprechendes Datum an allen angegebene Schlüssel redundant zu fin-
den. Es ist hierbei jedoch zu beachten, dass stets einer dieser Schlüssel verwendet wird, da
ansonsten entsprechend viele Duplikate auftreten. Bei der Überprüfung der Schlüssel der bei-
den SubgraphContainer auf Gleichheit in der Partitionskomponente ist deshalb jegli-
che Kombination von Schlüsseln und alternativen Schlüsseln zu überprüfen. Das Beispiel in
Abbildung 34 soll dieses verdeutlichen: Es sind zwei Unteroperatorgraphen gegeben, wel-
che die gleiche Partition ansprechen (hier: Partition 1). Dabei ist jedoch im ersten Operator
die Prädikat-Komponente, im zweiten Operator die Objekt-Komponente im Partitionsattribut
vorhanden. Aufgrund des vorhandenen alternativen, redundanten Schlüssels im ersten Unter-
operatorgraph, ist jedoch ein lokaler Join der beiden Partitionen möglich, wenn der alternati-
ve Schlüssel verwendet wird. Nach der Optimierung muss darauf geachtet werden, dass der
jeweilige Unteroperatorgraph seinen ursprünglichen Schlüssel und andere alternative Schlüs-
sel nicht mehr nutzen darf. Sonst könnte eine spätere Optimierung wiederrum den alterna-
76
4 Realisierung
Abbildung 34: Zwei dargestellte Unteroperatorgraphen (hier: Unteranfragen) die theoretischlokal gejoint werden können, wenn der alternative Schlüssel verwendet wird.
Abbildung 35: Eine erneute Optimierung der dargestellten Unteroperatorgraphen würde wie-der den alternativen Schlüssel verwenden und verknüpfen (vgl. Abbildung 34).Das Ergebnis (rechts) verwendet nun jedoch verschiedene Partitionsattribute(fett hervorgehoben).
tiven Schlüssel verwenden, was in einem Unteroperatorgraph resultiert, welcher nicht pas-
sende Partitionsattribute verwendet (siehe Abbildung 35). Weil diese Partitionsmengen nicht
mehr gleicher Art sind, ist das Ergebnis der lokalen Joins auch nicht korrekt. Der zweite
Punkt, der bei der Ausführung der Regel beachtet werden muss, ist das Join-Attribut. Ent-
sprechend der Konzeption wird überprüft, ob das Join-Attribut in der Komponente vorhanden
ist, welche für die Partitionierung verwendet wurde. Die komplette Regel ist in der Klasse
PartitionSubgraphRule realisiert.
4.5.5 Filter verschieben
Filter sind Hauptbestandteil von SPARQL10, die es erlauben, die Ergebnismenge stark ein-
zuschränken. Dabei wirkt sich der Filter auf eine Tripel-Komponente aus und schränkt diese
zusätzlich ein. So lässt sich z.B. überprüfen, ob eine in der Anfrage gegebene Variable ei-
ne IRI ist (FILTER isIRI(?var)), oder eine (Un-)Gleichheit zwischen mehreren Varia-
10http://www.w3.org/TR/rdf-sparql-query/
77
4 Realisierung
blen besteht. Auch Bereiche lassen sich damit definieren, indem durch Minimum-Maximum-
Einschränkungen oder reguläre Ausdrücke entsprechende Daten berücksichtigt werden.
Vor allem bei Nutzung von Unteroperatorgraphen können solche Filter die Ergebnismenge
stark einschränken und verhindern das Übertragen von überflüssigen Daten, die später eh
eliminiert würden. Eine entsprechende Regel PushFilterRule ist bereits in LuposDate
realisiert, wird jedoch im Kontext der P2P-Komponente nicht ausgeführt. Deshalb wird die-
se Regel auch in der P2P-Komponente mit der Änderung integriert, dass auch Filter in ein
SubgraphContainer verschoben werden können, welche zu den anderen Peers gesendet
werden. Diese Regel führt dabei, wie es der Name bereits erkennen lässt, eine Optimierung
in der Ausführung eines Filters durch, sodass Filter so früh wie möglich durchgeführt werden.
Jedoch ist darauf zu achten, dass die berücksichtigten Variablen zu dieser Zeit bereits verfügbar
sind. In der modifizierten Form kann solch ein Filter nun in eine Untergraphanfrage verscho-
ben werden. Vor allem durch die Optimierung an den Partitionsanfragen, wird damit verhindert,
dass zu viele Daten an den Client zurückgesendet werden, die dort dann anlässlich des Filters
eliminiert würden.
4.5.6 Asynchron, parallel-ausführbare Unteroperatorgraphen
Wie bereits in Kapitel 4.3 angesprochen, werden in LuposDate parallel ausführbare Opera-
toren im globalen Operatorgraph nicht gleichzeitig sondern sequentiell abgearbeitet. Deshalb
wird die neue Datenstruktur AsynchronSubgraphContainer erstellt, welche paral-
leles Ausführen ermöglicht. Um abwärtskompatibel zu bleiben und die sequentielle Ab-
arbeitung weiterhin zu ermöglichen, wird eine neue Regel erstellt, welche die Ersetzung
zwischen SubgraphContainer und dem parallel-ausführbaren AsynchronSubgraph-
Container durchführt. Diese Regel wird nur in der P2P-Komponente von LuposDate ein-
gesetzt und ermöglicht es so, dass nur in dieser Komponente der asynchrone Einsatz genutzt
wird.
4.5.7 Regelwerke
Wie bereits in der Konzeption erwähnt, sind Regeln so lange anzuwenden, bis keine neuen
Transformationen mehr am Operatorbaum vorgenommen werden. In LuposDate werden die
Regeln der Klasse Rule aber nur ein Mal ausgeführt. Dabei wird jede Operant im Operator-
baum in der Methode boolean check(BasisOperator) der jeweiligen Regel auf die
Vorbedingung überprüft. Sobald die für die Regel erforderliche Struktur (Untergraph) gefunden
ist, wird die implementierte Transformation durchgeführt. Anschließend ist das Abarbeiten der
Regel beendet, wie auch, wenn die Struktur nicht gefunden wurde und deshalb keine Optimie-
rung möglich gewesen wäre. Um Regeln mehrfach ausführen zu können, gibt es in LuposDate
ein neues Konstrukt, die Regelsammlung RulePackage. Hier werden die integrierten Re-
geln solange angewendet bis keine Optimierung mehr möglich ist. Vor allem das gegenseitige
Voraussetzen von Optimierungen wird damit unterstützt, sodass eine Optimierung einer Regel
eine andere Regel ebenfalls zur Optimierung bedingt, auch wenn in einem vorigen Durchlauf
diese Regel nicht angewendet werden konnte. Der Ablauf dieses Regelpakets ist dabei stets
78
4 Realisierung
gleich: Es wird die erste Regel solange angewendet, bis sie nicht mehr angewendet werden
kann. Danach wird die zweite Regel angewendet. Wenn diese angewendet werden kann, be-
ginnt das Abarbeiten der Regel wieder am Anfang; sollte die Regel nicht anwendbar sein, wird
die nächste Regel in der Reihe ausprobiert. Nachdem in einem Durchlauf keine Regel mehr
angewendet werden konnte, ist die Optimierung beendet.
Die erstellten Regeln in der neuen P2P-Komponente von LuposDate sind in der Regelsamm-
lung HierachialDistributionRulePackage zusammengefasst, um ein mehrfaches
Ausführen der Optimierung zu erlauben. Dabei ist die Reihenfolge so festgelegt, dass die Re-
gel aus Kapitel 4.5.3 (die Regel, die unbenutzbare Operationen entfernt, wenn diese weniger
als zwei Vorgängeroperationen hat) zuletzt ausgeführt wird, um einen validen Operatorgraph
zu erhalten.
79
5 Evaluierung
In diesem Kapitel werden die Umsetzungen des Kapitels „Realisierung“ evaluiert. Dazu wer-
den Benchmark-Tests durchgeführt, um die Güte der neuen Komponenten zu testen.
Zuerst werden in Kapitel 5.1 die verschiedenen Benchmarktests vorgestellt, die für die späte-
ren Untersuchungen benutzt werden sollen. Anschließend werden die Testumgebungen (Ka-
pitel 5.2), an welchen die Testdurchführung stattfindet, technisch erläutert. In den darauffol-
genden Abschnitten werden dann die Einfügezeiten der Tripelmenge in das P2P-Netz gemes-
sen, Kollisionsvermeidungen stochastisch analysiert sowie Benchmarktests an dem realisierten
TomP2P-System und dem Endpoint basierten System durchgeführt und dessen Ergebnisse ana-
lysiert.
5.1 Benchmark
In diesem Kapitel werden Benchmark-Tools vorgestellt, die das erstellte System unter Belas-
tung evaluieren und eine Vergleichbarkeit zwischen bereits existierenden Ansätzen und den
neuen Umsetzungen in dieser Arbeit bietet.
5.1.1 SP2Bench
Unter anderem wird für die Benchmark-Testreihe das Benchmark SP2B1 verwendet, das an der
Universität Freiburg entwickelt wurde. Ein Test mit eigenen Abfragen und benutzerdefinierten
Experimenten ist problematisch, wenn es um den Vergleich mehrerer Optimierungsstrategien
geht, sowie dessen Vorhersagen über reale Szenarien und echten Daten sowie die Güte im
Allgemeinen (Schmidt et al., 2008). Um diesen Mängeln entgegen zu kommen, wurde der
umfassende Benchmark-Test SP2B erstellt. Außerdem ist es für erste Performancetests (siehe
Tabelle 1, Seite 15) nützlich und wurde bereits bei anderen Komponententests für LuposDate
verwendet, obwohl es auf synthetischen Daten arbeitet. Jedoch kritisiert Bizer (2008), dass die
Abfragen des Benchmarks nicht auf realistischen Arbeitslasten ausgelegt seien.
SP2B umfasst 12 Abfragen (Schmidt et al., 2008, S.12), wobei es bei einigen dieser Abfragen
noch Varianten gibt, die diese vor allem um das Abfragekriterium „Optional“ ergänzen. Ein
Test besteht hierbei aus dem Einfügen der Tripel in das P2P-Netz und das Abfragen mit der
optimierten Anfrage. Außerdem befindet sich im Umfang des SP2Bs ein Generator, der ent-
sprechend große Datensätze für Tests generiert, sodass die verschiedenen Abfragen bei entspre-
1eigentlich sp2b, http://dbis.informatik.uni-freiburg.de/index.php?project=SP2B
80
5 Evaluierung
chenden Datengrößen evaluiert werden können. Die Korrektheit dieser Abfragen kann jedoch
nicht mit Hilfe der mitgelieferten Tools von SP2B überprüft werden. Dafür muss ein bereits
verifizierter SPARQL-Evaluator parallel gestartet werden und die Ergebnisse auf Gleichheit
überprüft werden, sodass SP2B lediglich als Benchmark-Tool dient und keine Anfragerichtig-
keit überprüft. Außerdem sind die Anfragen 7 und 9 nicht mit dem P2P-Netz beantwortbar, da
zu Teilanfragen, die lediglich aus Variablen bestehen, keine P2P-Schlüssel generiert werden
können. Eine Optimierung der SPARQL-Engine müsste hier eine Optimierung vornehmen, in-
dem die Variablen mit bereits ermittelten Teilergebnissen versehen werden und anschließend
auch die Schlüsselgenerierung möglich ist.
5.1.2 Berlin SPARQL Benchmark
Außerdem wird das Berlin SPARQL Benchmark (BSBM)2 in den Messreihen verwendet. Dies
Tool definiert eine Masse an Bechmarkanfragen, die im Kontext eines Internethandels spie-
len, wobei verschiedene Produkte verschiedener Hersteller angeboten werden, die von Kunden
bewertet werden (Bizer & Schultz, 2009). Es werden hierbei jedoch keine realen Daten ver-
wendet, sondern mit Hilfe eines erstellten Tools Daten anhand von Namenslisten generiert.
Dabei muss bei der Generierung ein Skalierungsfaktor angegeben werden, der die Anzahl an
Warenprodukten darstellt. Im Beispiel ergibt eine Skalierung von 91 Produkten rund 50k Tripel
(Bizer & Schultz, 2011). In den Messreihen werden die Skalierung jeweils auf 10er-Potenzen
gesetzt und entsprechende Daten erstellt. Außerdem wird für die Abfrage die BSBM Spezi-
fikation V3.1 vom 06.07.2011 gewählt. Wie SP2B enthält es 12 Abfragen (Bizer & Schultz,
2009, S.7ff), wobei der Unterschied voriger Versionen zur neusten Spezifikation ein regulärer
Ausdruck in der 6ten Abfrage ist, der neu integriert wurde.
5.1.3 DBPedia
DBPedia3 ist ein Gemeinschaftsprojekt der Universität Leipzig, der Freien Universität Berlin
und OpenLink Software. Es stellt dabei strukturierte Daten in RDF zur Verfügung, die aus der
Enzyklopädie Wikipedia extrahiert wurden. Über einen Web-Endpoint lassen sich mit der An-
fragesprache SPARQL diese Daten von jedem frei nutzen. Somit ist DBPedia Teil von Linked
Open Data, also verknüpften frei verfügbaren semantischen Daten. Auf dieser Datengrundla-
ge wurde DBPSB (DBPedia SPARQL Benchmark) konzipiert, ein Benchmark-Tool, welches
mit existenten semantischen Daten arbeitet (Morsey et al., 2011). Andere Benchmark-Tools
hingegen arbeiteten oft mit synthetischen Daten oder Daten, die aus relationalen Datenban-
ken stammen. Im Gegensatz dazu nutzt DBPSB die RDF-Daten aus der Wikipedia, die mit
über 4 Millionen „things“ und 470 Millionen „facts“ (Sahnwaldt et al., 2013) eine Menge an
semantischen Daten bereitstellt.
2http://wifo5-03.informatik.uni-mannheim.de/bizer/berlinsparqlbenchmark/3http://wiki.dbpedia.org/UseCases
81
5 Evaluierung
Für die Durchführung eines Benchmarks müssen zuerst die RDF-Daten heruntergeladen wer-
den. Über Einstellungsdateien kann mit dem Tool DBPSB unter anderem die Menge und Art
der Daten bestimmt werden. Die 25 Abfragen sind im Unterschied zu SP2B und BSBM nur
Anfragetemplates, die mit existenten strukturierten Daten gefüllt werden müssen.
1 SELECT ?v2 WHERE {
2 ?v2 a dbp-owl:Settlement .
3 ?v2 rdfs:label \%\%v\%\% .
4 }
In dieser Template-Anfrage ist der Platzhalter „%%v%%“ mit einer existenten RDF-Objekt-
Komponente zu ersetzen. Dafür gibt es zu jedem Template eine entsprechende Anfrage, welche
eine Liste mit (limitierten) Ergebnissen erzeugt, die als Platzhalter fungieren können. Für die
Testreihen wird selbstverständlich nur die Zeit gemessen die für die erstellte Anfrage benö-
tigt wird, da die Ersetzung der Platzhalter nur dazu dient, eine Anfrage auf existenten Daten
durchzuführen.
5.2 Testumgebungen
Für die späteren Benchmark-Tests werden zwei verschiedene Rechnernetze benutzt. In der ers-
ten Zusammenstellung (im späteren Pool1), einem homogenen Netz, finden sich 5 gleichartige
Dual-Core-Rechner mit jeweils 4GB Arbeitsspeicher. Diese sind im Gigabit-LAN untereinan-
der erreichbar. In der zweiten Zusammenstellung (Pool2) wird der Pool1 um weitere 4 Rechner
ergänzt, die hingegen Quadcore-Rechner mit jeweils 4GB Arbeitsspeicher sind.
Für die Tests wird jeweils das Java basierte, ausführbare Programm unter dem Betriebssystem
Ubuntu 12.04.3 LTS (GNU/Linux 3.2.0-57-generic x86 64) mit 64-bit-Architektur ausgeführt.
Dabei laufen alle Tests in der Kommandozeile, die per Remote (SSH) bedient wird. Die Java-
Version der Linux-Distributionen ist Java OpenJDK 1.7.0_25 (7u25-2.3.10-1ubuntu0.12.04.2).
Die Tests laufen so ab, dass zuerst die Tripel, die als Datengrundlage dienen, eingelesen und
verteilt werden. Anschließend wird die entsprechende Anfrage, die getestet werden soll, ausge-
führt und die Zeiten notiert. Diese Methode wird grundsätzlich mindestens drei Mal wiederholt.
Wenn die Abweichungen unter 5% sind (außer es wurde anders angegeben) wird der Median
gewählt. Ansonsten werden die Anfragen so lange durchgeführt bis eine derartige Abweichung
der dichtesten Punktmenge gefunden ist. Somit werden stark abweichende Ergebnisse bei der
Berechnung eines Mittelwertes oder Medians ausgeschlossen, da sich derartige Abweichung
wohl aus Komplikationen mit Netzwerk und Prozess- bzw. Threadwechsel ergeben und nicht
als Testwert aufgenommen werden kann.
82
5 Evaluierung
5.3 Einfügezeiten der RDF-Daten in das P2P-Netz
Das abstrakte P2P-Netzwerk stellt, wie in Kapitel 3.1 beschrieben, die Grundfunktionali-
tät zur Verfügung, welche von den jeweiligen Implementationen von P2P-Systemen ange-
sprochen und realisiert werden muss. Dabei steht bei dieser Grundfunktionalität das Ein-
fügen eines Tripels (add(key,data)), Löschen eines Tripels (delete(key,data))
und Abfragen eines Tripelmusters (List<Data> get(key)) von verteilten Hashtabel-
len zur Verfügung. Das Einfügen kann bei dieser Methodik jedoch sehr lange dauern, was
in einem Benchmark-Test mit BSBM (vgl. Kapitel 5.1.2) festgestellt wurde. Eine mögli-
che Beschleunigung könnte erreicht werden, wenn die Daten vorsortiert würden und dann
blockweise in das P2P-Netz integriert würden. Dabei werden die einzufügenden Schlüssel
und Daten für das P2P-Netz in einem begrenzten Zwischenspeicher gespeichert, sodass die
Daten gleicher Schlüssel in Blöcken von o.B.d.A. 100 Tripeln vorgehalten werden und dann
blockweise über eine neu erstellte Funktion addAll(key, List<Data>) in das P2P-
System eingefügt werden. Die Standard-Implementierung dieser Funktion iteriert dabei durch
den Datensatz und ruft die oben vorgestellte Einfügemethode auf. Da TomP2P das Einfü-
gen von Datenlisten unter gleichen Schlüsseln beherrscht, ist in dieser Implementierung die
neue Methode überschrieben und mit dem neuen Feature versehen, gleich mehrere Daten
unter demselben Schlüssel abzuspeichern. Der Benchmark-Test wurde mit dem angepass-
ten BlockStorageWithDistributionStrategy (einer Unterklasse des vorgestellten
StorageWithDistributionStrategy, vgl. Kapitel 4.1) ebenfalls durchgeführt. Die
Ergebnisse in Abbildung 36 zeigen, dass das blockweise Einfügen bei allen generierten Daten-
sätzen des Berlin SPARQL Benchmarks deutlich schneller erfolgte. Die Wahl der Blockgröße
im vorgestellten Test lag bei 100, um den Arbeitsspeicher beim Vorhalten der Daten nicht zu
sehr zu belasten. Im worst case sind von allen möglichen Schlüsseln nur jeweils 99 Tripel vor-
handen, sodass diese im Arbeitspeicher gehalten werden müssten. In einer weiteren Testreihe
wurde die Blockgröße variiert. Die Ergebnisse aus Tabelle 12 zeigen unter Berücksichtigung
eines Fehlerindikators von 5%, dass sich ein Trend zwischen Einfügezeit und Blockgröße wi-
derspiegelt. So zeigt sich bei großen RDF-Daten (Skalierung4 > 100), dass die Einfügedauer
verringert wird, wenn die Blockgröße größer gewählt wurde. So lassen sich in diesem Test 8
bis 10 Sekunden einsparen. Bei den Skalierungen 1 und 10 der BSBM-Daten lässt sich unter
Berücksichtigung des Fehlerindikators keine Aussage darüber treffen, ob eine große oder klei-
ne Blockgröße von Vorteil ist. Bei der Skalierung 1000 zeigte sich, dass eine Blockgröße von
5000 dennoch ausgenutzt wird, sodass genug Tripel mit gleichem Schlüssel vorhanden sind,
um diese Grenze zu erreichen. Bei Blockgrößen von 25 bzw. 10 wurde diese Grenze zu oft
überschritten, sodass zwar wenig Daten im Arbeitsspeicher zur Zwischenlagerung gespeichert
wurden, aber zu oft Blöcke von 10 Tripeln in das P2P-Netz integriert wurden und deshalb
der Vorgang aufgrund des P2P-Systems zu viel Zeit benötigte und nachfolgende Aktionen
blockierte. Bei allen Testvariationen zeigte sich kein Speicherüberlauf, selbst bei groß gewähl-
ten Blockgrößen, obwohl viele Blöcke nicht bis 5000 Tripel gefüllt und deshalb im Speicher
verblieben.
4Skalierungsfaktor, der im Generator von BSBM eingestellt wird; vgl. Kapitel 5.1.2
83
5 Evaluierung
1
10
100
1000
10000
100000
1000000
10000000
1 (1844) 10 (5007) 100 (40377) 1000 (374911)
Daue
r [m
s]
Skalierung (Anz. d. Tripel) in BSBM
Einfaches Einfügen
Einfügen in Blöcken
Abbildung 36: Messreihe für das Einfügen der RDF-Daten von BSBM mit den jeweiligenSkalierungen und Tripeln mit den vorgestellten Storage-Implementierungenauf 5 Peers
Blockgröße 5000 1000 500 100 50 25 10
Skalierung1 11153 10590 11163 11119 11136 12120 1137410 10287 10267 11573 10463 10762 10835 11290100 56535 54897 56083 56369 58568 60597 648161000 523895 519263 527061 564713 564741 600951 630183
Tabelle 12: Messreihe der Dauer [in ms] von Einfügungen in ein P2P-System mit 5 Peers mitunterschiedlicher Blockgröße und Skalierung (BSBM).
Die Funktionalität des blockweisen Löschens bringt in TomP2P keine Vorteile, da es die Daten-
struktur der DHT nicht performant ermöglicht, eine Reihe von Daten gleichzeitig zu löschen,
da sowohl die Daten in der Hashtabelle am Peer durchiteriert werden müssen wie auch die
Liste der zu löschenden Daten, sodass diese Operation bei O(n2) schlecht ist. Dies liegt dar-
an, dass es TomP2P nicht zulässt, die Tripel mit einem zweiten Schlüssel für die Indizierung
zu speichern. Würde z.B. jedes Datum nicht nur mittels eines Hash-Schlüssels eindeutig be-
stimmt, sondern intern noch sortiert vorgehalten werden, ließe sich das zu löschende Datum
schneller finden (logarithmischer Aufwand) und damit auch der Löschvorgang beschleunigen.
Die Funktionalität für blockweises Löschen über removeAll(key, List<Data>) lässt
sich so bei TomP2P noch nicht (aus)nutzen. In späteren Versionen des Frameworks soll es je-
doch möglich sein, die Speicherlösung an den Peers selbst zu implementieren. Dabei könnte
zusätzlich zum P2P-Schlüssel ein interner Datenschlüssel pro Datum gespeichert werden. Die-
ser kann dann ausgenutzt werden, um das zu löschende Tripel schnell zu lokalisieren und eine
Iteration zu vermeiden.
Im Endpoint-Netz (der P2P-Implementierung, die auf HTTP-Endpoints aufsetzt, vgl. Kapi-
tel 4.1) kann die relative lange Einfügedauer, die bei TomP2P auftritt, vermieden werden, in-
dem die Daten initial eingelesen werden. Obwohl das Einfügen lediglich ein Mal geschieht und
deshalb ein zeitlicher Mehraufwand hinnehmbar ist, dauert dieses bei TomP2P für die Durch-
führung von Benchmark-Anfragen entsprechend lange. Dies liegt auch daran, dass die Daten in
84
5 Evaluierung
TomP2P im Arbeitsspeicher liegen und deshalb nicht persistent verteilt sind. Bei den Endpoints
hingegen werden die RDF-Tripel über den RDF-Speicher RDF3X dauerhaft auf der Festplat-
te geschrieben, sodass sie nach einem Neustart eines Benchmark-Tests erneut genutzt werden
können. Um solch einen Index schnell anlegen zu können, wurden deshalb Methoden konzi-
piert, die der Verteilung von RDF-Daten und dem Anlegen eines Index dienen. Damit lässt sich
ein Index von 15 Millionen Tripeln unter 34 Minuten anlegen, was über das P2P-Netz aufgrund
des gegenseitigen Blockierens und des Netzwerkoverheads nicht möglich ist. Außerdem ist die
Speicherstruktur von TomP2P nicht semantischen Daten angepasst, sondern für jegliche Inhal-
te zu verwenden. RDF3X hingegen sortiert die Tripel indiziert, sortiert in einem B+-Baum ab
und ist für SPARQL-Anfragen optimiert (Neumann & Weikum, 2008). Da dieses Endpoint-
Netz eigentlich kein P2P-Netz widerspiegelt, sind die entsprechenden Einfüge-Daten nicht
erhoben worden. Diese Implementierung ist lediglich zum Testen von großen Datenmengen
gedacht, da TomP2P und Chordless das Senden von Nachrichtenströmen und damit riesigen
Ergebnismengen nicht unterstützen.
5.4 Kollisionsvermeidung gleichartiger Partitionen
Vor allem bei der Anwendung fortgeschrittener Verteilungsstrategien mit Partitionen (vgl. Ka-
pitel 3.2.2) ist es wichtig, eine Kollisionsvermeidung zu erreichen. Wie bereits in der Konzepti-
on angesprochen, ist es wichtig, die Partitionsgröße an die Größe des P2P-Netzes anzupassen,
sodass sichergestellt ist, dass auf einem Peer nicht zwei Partitionen eines Schlüssels vorhan-
den sind (z.B. „S<Subjekt>P0“ und „S<Subjekt>P1“). Bei dieser Voraussetzung würde sonst
im Ergebnis die Anzahl an Duplikaten falsch berechnet, da beide Partitionsanfragen auf dem-
selben Peer die gleiche Berechnung ergeben würden und deshalb jenes Ergebnis doppelt in
der Ergebnismenge vorkommt. Vor allem bei Anfragen, bei denen die Anzahl der Ergebnisse
benötigt wird, ist besonders darauf zu achten, dass die Partitionen kollisionsfrei auf den Peers
verteilt sind. Bei anderen Anfragen könnte dennoch ein Nachteil zu erwarten sein, nämlich dass
bei vielen Operationen im Anfragegraph eine Vervielfachung der Ergebnismenge zu längeren
Anfragezeiten führt. In Tabelle 13 sind ein paar Kollisionswahrscheinlichkeiten aufgeführt.
Anz. der Peers 1 5 10 15 20 40 50 75 100 200
Anz.d.Partitionen
1 0 0 0 0 0 0 0 0 0 0
2 1 0,20 0,10 0,07 0,05 0,03 0,02 0,013 0,01 0,005
3 1 0,52 0,280 0,191 0,145 0,074 0,059 0,040 0,030 0,015
4 1 0,81 0,496 0,353 0,273 0,143 0,116 0,078 0,059 0,030
5 1 0,962 0,698 0,526 0,419 0,229 0,186 0,127 0,097 0,049
6 1 1 0,849 0,684 0,564 0,325 0,268 0,185 0,142 0,073
7 1 1 0,940 0,810 0,695 0,427 0,356 0,251 0,193 0,101
8 1 1 0,982 0,899 0,802 0,527 0,446 0,321 0,250 0,132
Tabelle 13: Kollisionswahrscheinlichkeiten (= mehr als zwei Partitionen pro Peer) bei Betrach-tung verschiedener Netzwerkgrößen und Partitionsgrößen
85
5 Evaluierung
Die Formel zur Berechnung der Kollisionsrate ergibt sich aus dem Geburtstagsparadoxon, das
beispielhaft zeigt, dass sich bei einer Menge von 23 Personen mit einer Wahrscheinlichkeit von
50% zwei oder mehr Personen finden, die am selben Tag Geburtstag haben (Ball & Coxeter,
1939; von Mises, 1939). Übertragen auf die Partitionsgröße (r) und die Anzahl der Peers (N)
ergibt sich die Formel:
C(N,r) = 1−P(N,r) (5.1)
P(N,r) = (1−1/N)∗ . . .∗ (1− (r−1)/N) =r−1
∏i(1− i/N) (5.2)
Dabei bezeichnet C(N,r) die Wahrscheinlichkeit einer Kollision unter r unabhängigen Ereig-
nissen. Dies impliziert, dass die nötige Hashfunktion, die bei der Kodierung im Schlüssel ver-
wendet wird, einigen Anforderungen von kryptographischen Hashfunktionen nachkommt. Da-
zu zählt die Gleichverteilung der Hashergebnisse auf dem gesamten, möglichen Schlüsselraum
(Menezes et al., 1996, S.323ff) sowie die Beachtung des Lawineneffekts, der aussagt, dass eine
minimale Änderung des Eingabedatums zu einer völlig anderen Ausgabe führt. Anders aus-
gedrückt liegt beim Lawineneffekt die Wahrscheinlichkeit des Kippens jedes Ausgabebits bei
50% (Ertel, 2003, S.66). Da im Allgemeinen jedoch die Partitionsgrößen sehr gering sind (vgl.
Tabelle 13), ist bei der Aufteilung der Tripel in die Partitionen von einer kryptografischen Hash-
funktion abzusehen und dennoch r als unabhängiges Ereignis zu nutzen. Diese berechneten
Schlüssel müssen jedoch auf die N Peers gleichverteilt werden. Das heißt, dass die ähnlichen
Schlüssel „S<Subjekt>P0“ und „S<Subjekt>P1“ völlig andere Hashwerte aufweisen müssen,
damit sie nicht im verwalteten Hashbereich eines Peers landen.
Die nötige Netzwerkgröße, um eine Kollisionswahrscheinlichkeit unter 2% zu erreichen, ist
in Tabelle 14 dargestellt. Zum Beispiel ist es ratsam, bei einer Schlüsselaufteilung in 2 Par-
titionen bereits ein P2P-Netz mit 50 Peers zu nutzen. Dabei können dennoch Fehler bei der
Berechnung mit Duplikatzählung stattfinden; die Wahrscheinlichkeit liegt jedoch unter 2%.
Bei einer erlaubten Kollisionsrate von 0.001 sind dagegen 1000 Peers nötig.
Anz. der Partitionen 1 2 3 4 5 6 7 8
Netzwerkgröße 1 50 149 298 496 744 1042 1388
Tabelle 14: Darstellung der nötigen Netzwerkgröße abhängig von der Anzahl der Partitionenmit einer Kollisionswahrscheinlichkeit ≤ 2 %
5.5 Vergleich zwischen lokalem Join und ausgelagertem Join
In diesem Test wird die neue Optimierung des Auslagerns von Berechnungen auf andere Peer-
Knoten mit der herkömmlichen Methode verglichen. Diese bewährte Methode sieht es vor, dass
alle Teilergebnisse von Tripel-Muster-Anfragen am Client gesammelt und dort die gesamte
Berechnung physischer Operationen durchgeführt werden.
86
5 Evaluierung
5.5.1 Testdurchführung
Für den Test wurde die Testumgebung „pool2“ mit 9 Rechnern benutzt. Als Benchmark-Test
wurde SP2B gewählt, da dieser einfache, häufig vorkommende Anfragetypen beinhaltet und
die generierte Datenmenge auf das maximal nutzbare Maß für das TomP2P-System genutzt
werden kann. Da die Daten bei TomP2P im Arbeitsspeicher verwaltet werden und keine strom-
basierte Kommunikation der Unteroperatorgraphen möglich ist, wurde ein Maximum von
500k Tripeln gewählt, was je nach Verteilungsstrategie zu 4,5 Millionen eingefügten Tripeln
führt. Die einfache Verteilungsstrategie OneKeyDistribution wird der Verteilungsstrate-
gie NinefoldInsertion gegenübergestellt, da diese ohne Indexstruktur im P2P-Speicher
auskommt und eine Iteration über die Ergebnismenge und nachträglicher Eliminierung nicht
benötigt (vgl. Kapitel 3.2.2). Als Parameter für die Partitionierung wurde die Partitionsmenge
2 gewählt (aufgrund der Kollisionswahrscheinlichkeiten, Tabelle 13); eine Partitionsmenge
von eins würde hingegen nichts bewirken, da keine parallel durchgeführte, externe Joins mög-
lich sind. Für diesen Test wurden die Zeiten der logischen Optimierung gemessen wie auch
die Dauer der jeweiligen Abfrage. Zudem ist die Größe der Ergebnismenge aufgeführt, was
als Indiz für die vorhandene Kollision zu interpretieren ist. Außerdem wurde der Test stets
auf demselben Rechner (Quadcore) der Testumgebung gestartet. Somit dienen bei allen Tests
immer dieselben Rechner als angefragter Client. Die Ergebnisse sind in Tabelle 15 (s.u.)
dargestellt. Die im Ergebnis fehlende Anfrage q9 beinhaltet ein Tripelmuster ohne feste Kom-
ponente, die im P2P-Netz nicht aufgelöst werden kann. So lässt sich aus den in q9 enthaltenen
Teilanfragen q1 = (?sub ject,?predicate,?person) und q2 = (?person,?predicate,?ob ject)
kein Schlüssel generieren. Im Grunde müssten alle im Netz hinterlegten Tripel zurückgegeben
werden und anschließend mit den bereits in der Optimierung ermittelten Variablen ?person
eine Überprüfung erfolgen. Aus gleichen Gründen konnte q7 nicht in den Tests ausgeführt
werden.
OneKeyDistribution 9 f oldInsertion
lokaler Join lokaler Join externer Join
Query1
log.Opt. 17 18 21
Ab f rage 1069 1618 3090
#Erg. 1 4 4
Query2
log.Opt. 8 13 23
Ab f rage 5150 6261 9805
#Erg. 965 3860 3860
Query3a
log.Opt. 3 4 4
Ab f rage 2303 634 2017
#Erg. 3647 3647 3647
Fortsetzung auf der nächsten Seite
87
5 Evaluierung
OneKeyDistribution 9 f oldInsertion
lokaler Join lokaler Join externer Join
Query3b
log.Opt. 2 2 2
Ab f rage. 513 513 1004
#Erg. 25 50 50
Query3c
log.Opt. 1 1 1
Ab f rage. 1012 513 1006
#Erg. 0 0 0
Query4
log.Opt. 3 3 17
Ab f rage. 39460 38981 124453
#Erg. 104746 104746 104746
Query5a
log.Opt. 1256 761 744
Ab f rage. 3446 3513 3397
#Erg. 1085 1085 1085
Query5b
log.Opt. 2 1 6
Ab f rage. 1306 1277 2298
#Erg. 1085 1085 1085
Query6
log.Opt. 2 - 39
Ab f rage. 199896 - 3
#Erg. 1769 - 918695
Query8
log.Opt. 3 5 16
Ab f rage. 2622 4345 7809
#Erg. 264 264 264
Query10
log.Opt. 0 1 0
Ab f rage. 503 503 505
#Erg. 307 307 307
Query11
log.Opt. 1 1 1
Ab f rage. 591 612 609
#Erg. 10 10 10
Fortsetzung auf der nächsten Seite
88
5 Evaluierung
OneKeyDistribution 9 f oldInsertion
lokaler Join lokaler Join externer Join
Query12a
log.Opt. 0 0 0
Ab f rage. 25345 24309 51716
#Erg. 1 1 1
Query12b
log.Opt. 0 0 0
Ab f rage. 62554 65419 113595
#Erg. 1 1 1
Query12c
log.Opt. 0 0 0
Ab f rage. 503 504 502
#Erg. 0 0 0
Tabelle 15: Vergleich zwischen lokalem Join am Anfrageclient und externem Join im TomP2P-Netz (9 Peers, pool2) mit dem SP2-Benchmark (0.5 Mio. Tripel) und der zwei Ver-teilungsstrategien OneKeyDistribution und NinefoldInsertion (mit Partitionsgröße2). Bei den jeweiligen Anfragen wurden die Zeiten [in ms] für die logische Op-timierung und die Dauer der Anfrageauswertung sowie die Anzahl der Tripel imErgebnis aufgelistet.
5.5.2 Auswertung
Normalerweise wird durch die realisierten Regeln (Kapitel 4.5) die Verwendung von Unte-
roperatorgraphen aktiviert, welche externe Joins ausführen und auch den Datentransfer über
die P2P-Komponente von LuposDate laufen lassen, anstatt direkt das P2P-System anzuspre-
chen (vgl. Kapitel 5.8). Durch die Partitionierung der Tripelmengen lassen sich die dadurch
entstehenden disjunkten Teilergebnisse im Netz mit entsprechend gleichartigen Partitionser-
gebnissen joinen, was zur Entlastung des Clients führt, dem die Anfrage gestellt wurde. In
diesem Versuch wurde diese Regel deaktiviert, sodass keine Verschachtelungen von Unterope-
ratorgraphen auftreten können (vgl. Testdurchführung in Kapitel 5.5.1). Dies führt dazu, dass
alle Teilergebnisse am anfragenden Client weiterverarbeitet werden. Die anderen Knoten des
Netzes werden lediglich zur Datenbeschaffung benutzt. In den Ergebnissen aus Tabelle 15 ist
ersichtlich, dass die Anfragen mit der Verteilungsstrategie OneKeyDistribution im Mit-
tel genauso schnell erfolgen wie der neuen Verteilungsstrategie mit der 9-fachen Einfügung
über Partitionierung. Leichte Abweichungen ergeben sich in beide Richtungen, sodass in eini-
gen Fällen (q15, q2, q3c, q8) bei der OneKeyDistribution schnellere Abfragen erfolgen.
In den anderen Fällen ist die NinefoldInsertion-Strategie leicht im Vorsprung. Durch
diesen Test ist gezeigt worden, dass die neue Verteilungsstrategie ohne Auslagerung von Joins
auf andere Knoten genauso gut wie die herkömmliche Methode ist. In einem zweiten Vergleich
wurde die Regel, die das Ausführen von externen Joins ermöglicht, aktiviert und mit den Zeiten
5Die jeweilige Nummer der Abfrage, also „query1“
89
5 Evaluierung
des lokalen Joins verglichen (Tabelle 15). Dabei fällt auf, dass die Anzahl der Ergebnisse der
jeweiligen Anfragen oft unterschiedlich ist (q1, q2, q3b). Dies zeigt, dass keine kollisionsfreie
Verteilung gleicher Partitionen erreicht wurde und deshalb Duplikate auftreten, die sich auf-
grund weiterer, späterer Joins auf die Ergebnismenge auswirkt. Die benutzte Partitionierung
n = 2 mit einem Rechner-Netz von insgesamt 9 Knoten (vgl. Tabelle 13, S. 85) hat immerhin
noch eine Kollisionswahrscheinlichkeit von 1/9≈ 0.11%. Aufgrund der begrenzten Kapazität
an Test-Rechnern (pool2) kann somit eine Kollision nicht vermieden werden und muss für die
Testreihen hingenommen werden. Aufgrund der Kollisionen lässt sich auch ein zeitlicher Mehr-
aufwand bei der Berechnung zwischen dem lokalen Joinen und der Auslagerung erklären. So
treten neben dem normalen Overhead an Netzwerk-Kommunikation größere Ergebnismengen
auf, sodass größere Datenmengen verschickt werden. Außerdem führen Kollisionen unweiger-
lich dazu, dass auf einem Knoten gleiche Anfragen parallel beantwortet werden müssen. So
werden zwei Operatorgraphen gleichzeitig auf dem lokalen Datenbestand ausgeführt und die
Ergebnisse serialisiert und versendet. Da in LuposDate keine zwei Evaluatoren zur selben Zeit
im gleichen Prozess ausgeführt werden können, ist hier eine sequentielle Evaluierung der Da-
ten nötig. Dies liegt daran, dass in LuposDate wichtige Einstellungen statisch vorgenommen
werden, sodass der eine Evaluator die Einstellungen des anderen überschreibt und deshalb eine
Synchronisierung nötig ist. Des Weiteren zeigt sich, dass manche Anfragen zu speicherlas-
tig sind und mehr als den verfügbaren, physikalischen Arbeitsspeicher benötigen (q6). Dies
führt in Java zu einem Heap-Überlauf und endet im Abbruch des Teilprogramms (siehe Ex-
kurs „Java-Heap“ im Anhang B). Ohne externen Join führt diese SP2B-Abfrage zu 18 parallel
versendeten Unteroperatorgraphen, welche relativ große Ergebnismengen zurücksenden. Dies
endet nicht nur darin, dass 18 gleichzeitige Verbindungen geöffnet sind sondern auch, dass
alle Ergebnisse gleichzeitig übertragen und im Arbeitsspeicher des angefragten Knotens lan-
den. Bei Ausnutzung von externen Joins werden lediglich 14 Unteroperatorgraphen versendet,
die jedoch kleine Ergebnismengen zurückliefern oder aufgrund der unterschiedlichen Ausfüh-
rungsdauer zeitlich versetzt versendet werden, sodass diese Anfrage in diesem Test keinen
Speicherüberlauf hervorbringt.
5.6 Vergleich der Verteilungsstrategien mit TomP2P
In diesem Test werden die vorgestellten Verteilungsstrategien aus Kapitel 3.2.1 und 3.2.2 ver-
glichen, wobei das P2P-System „TomP2P“ benutzt wird.
5.6.1 Testdurchführung
Für den Test wurde die Testumgebung „pool2“ mit 9 Rechnern benutzt. Als Benchmark-Test
wurde SP2B gewählt, da dieser einfache, häufig vorkommende Anfragetypen beinhaltet und
die generierte Datenmenge auf das maximal nutzbare Maß für das TomP2P-System eingestellt
werden kann. Hier ist ebenfalls aufgrund der nicht unterstützten Nachrichtenströme und des
begrenzten Arbeitsspeichers von effektiven 3.7 GB (davon 3.5 GB an Java zugewiesen) ein
Datenumfang von 500k Tripeln gewählt wurden. Aus obigen Gründen (Kapitel 5.5) wurde
die Partitionsmenge 2 beibehalten. Für den Test diente stets derselbe Dual-Core-Computer als
90
5 Evaluierung
Client, der die Anfragen startete und das Ergebnis evaluierte. Aufgrund der vernachlässigbaren
Zeiten der logischen und physischen Optimierung (∆600ms), wurden diese Werte im Testergeb-
nis nicht weiter betrachtet. Nur in q5 fiel auf, dass die logische Optimierung bei allen Strategi-
en mehr als 10 Sekunden benötigte, was auf die Komplexität und Größe des Operatorgraphen
zurückzuführen ist, die in jeder Regel durchlaufen werden muss. Durch die Regelwerke wird
deshalb auch bei kleinsten Änderungen durch die letzte Regel der Sammlung jede vorige Regel
erneut geprüft, sodass der tiefe Operatorgraph oft durchlaufen und die Vorbedingung überprüft
werden muss (vgl. Kapitel 4.5.7).
In den Ergebnissen in Abbildung 37 (Seite 92) werden die Anfragezeiten der verschiedenen
Verteilungsstrategien mit den Anfragen aus dem SP2-Benchmark dargestellt. Die zweite Achse
ist dabei logarithmisch dargestellt. Nicht vorhandene Werte sind auf nicht durchführbare Tests
zurückzuführen, die aufgrund des begrenzten Arbeitsspeichers abgebrochen wurden (vgl. Ex-
kurs: Java Heap Space im Anhang B). Dazu zählen auch die nicht dargestellten, aufwändigen
Abfragen q4 und q6, die jeweils zum Abbruch führten, weshalb keine Messdaten vorliegen. q7
und q9 sind aufgrund des Vorhandenseins von im P2P-Netz nicht unterstützten Anfragemustern
mit drei Variablen nicht in den Tests eingeflossen. Die Tests wurden so oft wiederholt, bis alle
Werte in einer erlaubten 10%-Abweichung lagen. Eine Standardabweichung von 5% war auf-
grund von Nichtdeterminismus im Kontextwechsel der Java-Threads oder aufgrund des Netz-
werkverkehrs nicht erreichbar. Bei mehr als 10 nötigen Tests wurde der k-Nearest-Neighbor-
Algorithmus angewendet, und der Median aus der dichtesten Punkthäufung der Messung be-
rechnet. Dies war vor allem bei der NinefoldInsertion nötig gewesen (q3a-c,q5b), da
einige Anfragezeiten bis zu 50 Sekunden Differenz aufwiesen. In Tabelle 16 sind die Grö-
ßen der Ergebnismenge der jeweiligen Verteilungsstrategien aufgelistet. Zudem ist die Dauer
für das Einfügen der Datenmenge mit 0.5 Mio. Tripel in TomP2P in Tabelle 17 dargestellt.
Für das Einfügen wurde die bereits in Kapitel 5.3 verbesserte blockweise Einfügung mit einer
Blockgröße von 100 verwendet, wobei dieser Wert die Messreihen nicht beeinflusst, sondern
lediglich die Einfügedauer für die Testdurchführung mindert.
5.6.2 Auswertung
In Tabelle 17 sind die Zeiten, die für die Einfügung der Daten benötigt wurden, dargestellt.
Dabei fällt auf, dass der Quotient Tripel/s relativ konstant ist und TomP2P somit im arithme-
tischen Mittel 523 Tripel pro Sekunde in das Netz schreiben kann. Dies ist bezogen auf einen
etwaigen Initialimport von Tripeldaten zwar sehr langsam, jedoch ist das Einfügen zur Lauf-
zeit nutzbar. Dies sollte bei einer Verwendung des Verfahrens berücksichtigt werden, sodass
die einzelnen Knoten nicht mehr Tripel pro Sekunde einfügen als im Test ermittelt wurden.
Ansonsten würde bei gleichmäßigem Einfügeintervall eine Blockierung des Netzes die Fol-
ge sein. Wie bereits in Kapitel 5.3 getestet, ist das Einfügen durch Blöcke bereits in TomP2P
optimiert, jedoch ist das initiale Einfügen von einer halben Million Tripel in 145 Minuten
(2 Stunden, 25 Minuten) in TomP2P nicht wirklich tauglich. Im Gegensatz dazu erledigt der
RDF3X-Evaluator des Endpoint-Netzwerks dies lokal in nicht mal 2 Minuten, wobei die Daten
hier aber nicht durch das P2P-Netz verteilt werden, sondern dessen Daten bereits lokal an den
jeweiligen Knoten vorliegen.
91
5 Evaluierung
Q1
Q2
Q3a
Q3b
Q3c
Q5a
Q5b
Q8
Q10
Q11
Q12
aQ
12b
Q12
c9f
oldI
nser
tion
9072
6325
814
121
3505
3504
2221
917
591
3615
651
145
0843
821
8612
357
17O
neKe
yDist
ribut
ion
7890
5471
878
4937
2630
5244
864
1587
1426
6122
1082
7322
2534
562
544
503
One
ToTh
reeK
eysD
istrib
utio
n10
641
5674
577
4535
3934
4659
576
9563
00
504
5907
2841
374
424
503
Sim
pleP
artit
ionD
istrib
utio
n92
5917
4226
9976
7084
6582
4407
593
927
074
667
7019
555
6245
557
2
110100
1000
1000
0
1000
00
1000
000
Ausführungszeit [ms] Abfr
age
aus S
P2B
9fol
dIns
ertio
n
One
KeyD
istrib
utio
n
One
ToTh
reeK
eysD
istrib
utio
n
Sim
pleP
artit
ionD
istrib
utio
n
Abbildung 37: Vergleich der Verteilungsstrategien mit dem SP2-Benchmark im P2P-Netz„TomP2P“ mit 9 Knoten; es wurden jeweils die Anfragezeiten [in ms] gemes-sen
92
5 Evaluierung
Aufgrund der Anzahl von Schlüsselkombinationen der jeweiligen Verteilungsstrategien er-
gibt sich ein Einfügevolumen von 1.5 Mio. Tripel (OneKeyDistribution, Simple-
Partition) bis 4.5 Mio. Tripel (NinefoldInsertion), die auf die 9 Rechner verteilt
werden. Unter Betrachtung von Statistiken, die während des Testlaufs angefertigt werden, ist
ersichtlich, dass keine Gleichverteilung der Datenmenge auf den Peers existieren kann. Dies
liegt daran, dass die Häufigkeit an Schlüsseln nicht gleich ist. Betrachtet man z.B. DBPe-
dia (vgl. Kapitel 5.1.3) so beinhaltet jeder Datensatz ein Tripel mit dem Prädikat »rdf:type«.
Unter der Schlüsselkombination „P“ und seinem P2P-Schlüssel (z.B. „P<rdf:type>" bei der
OneKeyDistribution) ist somit jeder Datensatz (nicht jedes Tripel) aus der DBPedia
gespeichert worden. Da Schlüssel und dessen Hashwerte immer identisch sind, werden diese
Daten eine Schlüssels im Allgemeinen alle an einem Peer gespeichert (siehe auch Exkurs
„Statistiken zum DBPedia-Dataset“ im Anhang A). Da auch SP2B dieses Prädikat verwendet,
kann in dem durchgeführten Test nicht davon ausgegangen werden, dass alle Peers unter Be-
rücksichtigung einer Standardabweichung dieselbe Menge an Daten verwalten. Deshalb kann
trotz der geringen Datenmenge von einer halben Millionen Tripeln, wie in einigen Abfragen
geschehen (z.B. q4 und q6, vgl. Abbildung 37), diese Anfrage nicht durchgeführt werden,
da hier Speicherengpässe auftreten (vgl. Exkurs Java-Heap im Anhang B). Außerdem muss
bedacht werden, dass die Testdurchführung nichtdeterministisch ist, sodass jegliche Testwie-
SP2B-Query OneKey OneToThreeKeys SimplePartition NinefoldInsertion
q1 1 1 4 4q2 14063 14063 68637 26567
q3a 29223 29223 43559 29223q3b 208 208 346 329q3c 0 0 0 0
q5/q5b 15085 15085 15085 15085q8 352 - - 352
q10 512 512 512 512q11 10 10 10 10
q12a/q12b 1 1 1 1q12c 0 0 0 0
Tabelle 16: Die Größe der Ergebnismenge der jeweiligen Verteilungsstrategien der SP2B-Testreihe im P2P-Netz; die Anfragen 4 und 6 konnten aufgrund Abbrüche wegendes Speichers nicht durchgeführt werden.
Verteilungsstrategie Anz. eingefügter Tripel Dauer (s) Tripel/s
OneKey 1.5 Mio. 2827 ≈ 530OneToThreeKeys 3.5 Mio. 6519 ≈ 536
SimplePartition 1.5 Mio. 2932 ≈ 5119foldInsertion 4.5 Mio. 8717 ≈ 516
Tabelle 17: Vergleich zwischen den Einfügezeiten und der Datenmenge der RDF-Tripel für dieSP2B-Testreihe im P2P-Netz
93
5 Evaluierung
derholung zu unterschiedlichen Ergebnissen der Anfragezeiten führen. Bereits während des
Testens fiel auf, dass einige Anfragezeiten weit von vorher gemessenen Zeiten abwichen,
was sich nur dadurch erklären lässt. So erfolgt die Datenbeschaffung großer Datenmengen,
die direkt am Client-Knoten liegen, schneller als wenn diese durch das P2P-Netz gesendet
werden müssen. Die Testergebnisse müssen deshalb unter Betrachtung der Messfehler ana-
lysiert werden. Selbst die Verteilung der Daten auf den Peers ist nicht vorhersehbar, da in
TomP2P jedem zugeschaltenen Knoten ein anderer Hashbereich zugewiesen wird als dieser
in einem vorigen Test verwaltet hat. Ein anderer nicht berechenbarer Faktor ist das Netzwerk,
sodass später versendete Daten den Zielrechner vor einem zuvor gesendeten Paket erreichen.
Die Reihenfolge der Abarbeitung von Unteroperatorgraphen sowie die Kontextwechsel der
Threads in Java führen dazu, dass die Prioritäten der aktuellen Aufgaben neuverteilt wer-
den und deshalb Ergebnisse unterschiedlich schnell verarbeitet werden. Zudem zeigt sich,
dass sich die Ergebnismengen abhängig von der genutzten Verteilungsstrategie unterscheiden
(Tabelle 16), da in manchen Abfragen aufgrund der Kollision von gleichartigen Partitionen
Duplikate auftreten. In q2 sind so in der SimplePartitionDistribution 400% mehr
Ergebnisse zusammengetragen worden, was sich in der Ausführungszeit widerspiegelt (Ab-
bildung 37). Wegen der höheren Datenmenge, die im P2P-Netz versendet werden muss, sind
auch längere Übertragungsraten zu beobachten. Auch die Weiterverarbeitung in Joins führen in
einer Kettenreaktion zu einer drei Mal längeren Dauer, wie bei der OneKeyDistribution
. Außerdem spielt die nicht vorhandene Index-Struktur der Daten an den Peers eine Rolle
in dieser Verteilungsstrategie. So muss durch die Ergebnismenge des jeweiligen Peers ite-
riert und nicht zutreffende Tripel eliminiert werden. Würden die Tripel in TomP2P in einer
sortierten Struktur vorliegen, ließe sich das vermeiden. In den Ergebnissen zeigt sich, dass
die SimplePartitionDistribution deshalb nicht besser ist als die anderen Vertei-
lungsstrategien. Vor allem bei der dreigeteilten Abfrage q3 benötigte diese Strategie nahe das
doppelte an Zeit wie die anderen Verfahren. Aufgrund von Problemen mit den relativ großen
zu verarbeiteten Daten und auftretenden Kollisionen, ist Abfrage q8 nur von den Verteilungs-
strategien NinefoldInsertion und der OneKeyDistribution erfolgreich berechnet
worden. Die OneToThreeKeysDistribution konnte sich nicht gegen die anderen Ver-
fahren durchsetzen, wenn man berücksichtigt, dass die 7-fache Menge im Netz gespeichert
wird und keine Lastauslagerung auf andere Peers erfolgt. Verglichen mit dem Test aus Kapi-
tel 5.5 zeigt sich, dass in einigen Abfragen das Verlagern von Berechnungen auf externe Knoten
sowie der Join an den Partitionen zu Zeiteinsparungen führt (q5 bis q11, v.a. Sternanfragen, die
gut parallel berechenbar sind). Vor allem bei q12a und q12b fällt auf, dass die Verteilungsstra-
tegien mit den Partitionen mehr Ausführungszeit benötigen. In q12a wird abgefragt, ob es eine
Person gibt, die sowohl in »bench:Inproceedings« als auch »bench:Article« als Autor eingetra-
gen ist. Aufgrund der Zusammensetzung der Anfrage werden als Zwischenanfrage alle Namen
und alle Autoren abgefragt – bei SP2B sind diese in fast jedem Datensatz verfügbar, sodass
hier große Datenmengen verarbeitet werden müssen. In der Optimierung erfolgen deshalb an
allen Partitionen der Knoten, welche die Artikel-Tripel und Inproceedings-Tripel vorhalten, ein
Join mit den von dort angefragten Autoren-Instanzen. Im Nachhinein werden diese Ergebnisse
mit allen vorhandenen Namen gejoint und dann verglichen, welche Artikel-Autornamen auch
bei den Berichten (Inproceedings) als Autor existieren. Wenn an den Knoten jeweils Statistiken
94
5 Evaluierung
über die Datenmengen vorliegen würde, wäre die Optimierung, die Join-Berechnungen an der
Partition der Autoren durchzuführen, da die Anzahl der Artikel viel geringer ist, und damit
der Join auf der Partition mit der größeren Datenmenge durchgeführt werden könnte. Auch
dass vier Partitionen (zwei für die Artikel, zwei für die Berichte) gleichzeitig die jeweilige
Partition der Daten aller Autoren anfordern, führt an dem Knoten, der diese Autordaten ver-
waltet, zu einer Belastung, da beide großen Datenmengen parallel versendet werden müssen.
Außerdem fiel bei der Abarbeitung von q12a in der NinefoldInsertion auf, dass die
Autor-Partitionen und Artikel-Partitionen Kollisionen hervorriefen und deshalb noch eine grö-
ßere Belastung der jeweiligen Knoten zutraf. Das liegt vor allem daran, dass diese Kollisionen
nicht nur Kollisionen gleichartiger Partitionen wie „S<Subjekt>O1“ und „S<Subjekt>O2“
(Schlüsselkombination „SO“) waren, sondern auch verschiedener Schlüsselkombinationen. In
diesem Fall waren die Partitionen „P<type>O<bench:Article>S1“ (POS) und „P<creator>S0“
aufgrund des nahen Hashwertes auf einem Peer vereint. Da beide angesprochenen Schlüs-
sel gleichzeitig benutzt werden, fällt natürlich auch hier wieder ein starker Kontextwechsel
der beiden Anfragen des Peers an, was die Dauer zusätzlich negativ beeinflusst. Ähnlich ist
die Anfrage q12b gestrickt, die den Wahrheitswert „yes“ zurück gibt, wenn ein Autor „Paul
Erdoes“ publiziert hat oder ein Autor, der zusammen mit „Paul Erdoes“ publiziert hat. Ob-
wohl diese Anfrage genau dieselbe wie q8 ist, nur dass ein Boolscher-Wert zurückgeliefert
wird, ob das entsprechende Datum existiert, unterscheiden sich die Werte stark. Das zeigt,
dass der Test trotz der Wiederholungen zu unterschiedlichen Verteilungen geführt hat, sodass
sich entsprechend gute bzw. schlechte Verteilungen in q8 und q12 ergaben. In q12c zeigt sich
außerdem, dass der Overhead bei Anfragen ohne Resultat (vgl. Tabelle 16) sehr hoch ist (vgl.
Abbildung 37). Da der Client-Knoten hier kaum Auslastung hat, außer die leere Ergebnis-
menge zu empfangen, führt eine Auslagerung der Berechnung und das Joinen der Partitionen
zu keiner Einsparung, sondern zu einer Verlängerung des Anfrageaufwandes um den Faktor
10, was auf der logarithmischen Skalar gut nachvollziehbar ist. Bei den anderen Benchmark-
Anfragen ist die Strategie NinefoldInsertion nicht schlechter als die anderen Verfahren.
Im Hinblick auf die 9-fache Datenmenge ist ein richtiger Vorteil des Verfahrens bei einer hal-
ben Million RDF-Tripel nicht erkennbar. Ein Test mit größeren Datenmengen kann aufgrund
des begrenzten Arbeitsspeichers der Testrechner nicht durchgeführt werden. Auch die Anzahl
von 9 Rechnern ist wegen der auftretenden Kollisionen nicht optimal, jedoch aufgrund der
Kapazitäten im Testlabor nicht änderbar. Weitere Tests, die dann pro Rechner zwei oder drei
Instanzen eines P2P-Knotens erlaubten und so eine Gesamtzahl von 18 bzw. 27 Knoten boten,
waren jedoch nicht zufriedenstellend, da eine Halbierung und Drittelung des Arbeitsspeichers
nicht für die Berechnungen ausreichten. Auch die Auslagerung von virtuellem Arbeitsspeicher
auf die Festplatte (Swap-Partition) führte zu Seitenfehlern6 und einer Verschlechterung der
Abfragezeit.
6Seitenfehler ergeben sich, wenn ein Datum benötigt wird, welches aufgrund des begrenzten Arbeitsspeichers ineine Auslagerungsdatei auf die Festplatte geschrieben wurde und nun zurück in den Arbeitsspeicher geschriebenwerden muss.
95
5 Evaluierung
5.7 Vergleich der Verteilungsstrategien im Endpoint-Network
In diesem Test werden die vorgestellten Verteilungsstrategien aus Kapitel 3.2.1 und 3.2.2 ver-
glichen. Da die jetzige P2P-Implementierung TomP2P rein Arbeitsspeicher basierend arbeitet,
sind große Datenmengen bei dem begrenzten Arbeitsspeicher von 4 GB der Testrechner nicht
zu verarbeiten (vgl. Kapitel 5.6). Um Vergleichswerte für Daten über 1 Million Tripel zu erhal-
ten, wurde das EndpointNetwork realisiert, das im Grunde genommen keine P2P-Struktur
darstellt, sondern eine Vernetzung von Endpoint-Servern, die über das HTTP-Protokoll kom-
munizieren. Die Vernetzung ist hierbei vorweg statisch konfiguriert und nicht dynamisch. Auch
baut die Endpoint-Struktur nicht auf DHTs auf, sodass der P2P-Schlüssel lediglich für die
Zuordnung des entsprechenden Endpoints genutzt wird, also zur Adressauflösung. Außerdem
laufen auf den Endpoints jeweils RDF3X-Evaluatoren, welche die empfangenden Tripelmus-
ter der Unteroperatorgraphen auf den persistent gespeicherten RDF-Daten ausführt und somit
direkt zu einem korrekten Ergebnis kommt. In TomP2P mussten je nach Verteilungsstrate-
gie nachträgliche Eliminierungen von Ergebnisdaten vorgenommen werden, die nicht auf die
Anfrage zutrafen, da die Speicherlösung in TomP2P keinen optimalen Index der RDF-Tripel
beinhaltet. Dennoch können auch im EndpointNetwork Kollisionen auftreten, sodass zwei
gleichartige Partitionen in einem Endpoint-Server zu lokalisieren sind und deshalb bei allen
Teil-Partitionen das gleiche, korrekte Ergebnis zurückgibt. Dies führt auch hierbei zu einer
falschen Ergebnismenge, sodass die Duplikatanzahl möglicherweise falsch sein kann – oder
sich während der Joins so auflöst, dass es im Resultat nicht auffällt.
5.7.1 Testdurchführung
Vortests wurden aufgrund der zu der Zeit zur Verfügung stehenden Testumgebung „pool1“ auf
5 Rechner ausgeführt, dessen Ergebnisse Tendenzen aufzeigten. Dabei sind auf jedem der fünf
Rechner jeweils zwei Instanzen gestartet worden, sodass effektiv 10 Endpoints im Netz regis-
triert sind. Die Ergebnisse mit 5 Millionen Tripeln des SP2-Benchmarks sind in Abbildung 38
dargestellt. Aufgrund der Erkenntnisse der vorigen Tests wurden nur die beiden Verteilungs-
strategien OneKeyDistribution und NinefoldInsertion betrachtet, um eine einfa-
che Strategie mit lediglich dreifachem Datenvolumen mit der Verteilungsstrategie, die zwar
Joins auf andere Knoten anbietet dafür jedoch die neunfache Datenmenge benötigt, zu verglei-
chen. Die Anfragen 2 und 6 konnten mit der Verteilungsstrategie OneKeyDistribution
nicht durchgeführt werden, da der Arbeitsspeicher für die Verarbeitung aller Ergebnisse nicht
ausreichte, da sich bei 5 Rechnern und 2 Partitionen zu viele Kollisionen ergaben.
Bei den großen Initialdaten konnte im Gegensatz zum TomP2P-System eine Abkürzung ge-
wählt werden, sodass nicht alle Tripeldaten in der laufenden Instanz verteilt und persistent
gespeichert werden müssen. Da dieses Verfahren alle Daten in einem Index auf der Festplatte
speichert, kann dieser bereits vorher angelegt werden. Dazu ist die jeweilige N3-Datei mit den
Tripeln in einem ersten Programmlauf zu verteilen, sodass auf jedem Endpoint nur die Tripel
landen, die dort auch entsprechend eines P2P-Schlüssels gespeichert würden. Dies spart ein
lästiges Einfügen über die SPARQL-Engine, da entsprechende Datengrößen im Netz versendet
und gespeichert werden müssten, was für die Testdurchführung viel mehr Zeit in Anspruch
nähme.
96
5 Evaluierung
Abbildung 38: Testergebnisse des SP2-Benchmarks mit 5 Millionen Tripel und 10 Instanzenauf 5 Rechnern im EndpointNetwork
In weiteren Tests wurden 10 Millionen Tripel des SP2-Benchmarks generiert und verwen-
det. Dabei wurde aufgrund der Erkenntnisse des Vortests die Testumgebung „pool2“ mit 9
Rechnern benutzt. Aufgrund der ungleichmäßigen Verteilung der Daten, ergeben sich bei der
NinefoldInsertion dabei Datenmengen von 5,280 bis 11,562 Millionen Tripel pro End-
point. Aufgrund von auftretenden Kollisionen (21 Millionen) ergeben sich in der Endsumme
keine 90 Millionen RDF-Daten, da in dem Index im Gegensatz zur DHT jedes Datum nur
ein Mal hinterlegt wird. Das Erstellen des Index benötigte einen Zeitraum von 4 Minuten 25
Sekunden bis 11 Minuten 59 Sekunden.
In Abbildung 39 sind die Ergebnisse von einigen Abfragen des SP2-Benchmark-Tests mit den
verschiedenen Verteilungsstrategien grafisch dargestellt. Die gesamten Ergebnisse finden sich
in Tabelle 18. Dabei wurden die jeweiligen Abfragen mit 5 bzw. 10 Millionen Tripeln durch-
geführt. Als Testumgebung wurde aufgrund der Rechneranzahl „pool2“ gewählt. Bemerkens-
wert ist außerdem, dass die jeweiligen Abfragen (q1, q3, q10, q11, q12) nicht alle Rechner
97
5 Evaluierung
gleichmäßig belasten. Bei der NinefoldInsertion und der OneKeyDistribution
sind drei der neun Rechner unbenutzt geblieben. Bei der Verteilungsstrategie OneToThree-
KeysDistribution sogar fünf, während bei der einfachen Partitionierung nur ein Rechner
nicht für die Berechnungen benutzt wurde, obwohl die Anfragen verschiedene Prädikate und
Objekte benutzen. Wie bei den vorigen Tests variieren die Ergebnisse bei ca. 10% Abweichung.
10 Mio. 5 Mio. 10 Mio. 5 Mio. 10 Mio. 5 Mio. 10 Mio. 5 Mio. 10 Mio. 5 Mio.q1 q3a q3b q3c q11
9foldInsertion 87 59 254 124 10 6 14 8 232 107OneKey 119 54 176 94 35 21 38 23 138 77OneToThreeKeys 124 55 183 89 36 21 37 21 139 72SimplePartition 206 94 291 121 40 20 42 28 210 74
0
50
100
150
200
250
300
Zeit
[s]
9foldInsertionOneKeyOneToThreeKeysSimplePartition
Abbildung 39: Auszug der Ergebnisse des SP2B-Test im EndpointNetwork mit 5 bzw. 10 Mil-lionen Tripel
5.7.2 Auswertung
Vortest
In dem durchgeführten Vortest, bei welchem je 2 Instanzen eines Knotens pro Rechner ge-
startet wurden, fällt auf, dass die neue Verteilungsstrategie nur in q12 wesentlich schneller
zum Ergebnis kommt als die herkömmliche Strategie (Abbildung 38). In q10 und q1 lie-
gen die Unterschiede bei einigen Millisekunden bis 7 Sekunden. In den anderen Abfragen
liegt die NinefoldInsertion um den Faktor 10 hinter der einfachen Strategie. Erklä-
ren lässt sich dies durch die Mehrbelastung der jeweiligen Rechner, sodass neben den bereits
vorhandenen Kollisionen von Partitionen auch noch zwei verschiedene Instanzen auf dem-
selben Rechner gestartet wurden. Dies führt im Betriebssystem zu einem erhöhten Kontext-
wechsel zwischen den Prozessen sowie der Doppelbelastung der Verarbeitung an den HTTP-
Endpoints. Vor allem bei den aufwändigen Anfragen mit bis zu 14 parallel berechenbaren Un-
teroperatorgraphen und dem großen Datensatz kommt es dabei zu Verzögerungen, die in der
98
5 Evaluierung
q1q2
q3a
q3b
q3c
q4q5
aq5
bq6
q8q1
0q1
1q1
2aq1
2bq1
2c
Nin
efol
dIns
erti
on5
Mio
.59
4428
124
68
1365
410
252
436
564
110
741
758
01
10M
io.
87-
254
1014
2103
769
310
445
854
223
277
159
31
One
Key 5
Mio
.54
-94
2123
3211
213
-43
6-
277
237
-1
10M
io.
119
-17
635
38-
567
-61
2-
213
860
2-
1O
neTo
Thr
eeK
eys
5M
io.
5531
4589
2121
3243
196
-53
3-
272
201
-2
10M
io.
124
-18
336
36-
436
-60
5-
213
952
0-
1Si
mpl
ePar
titi
on5
Mio
.94
6232
121
2028
3650
244
302
457
625
374
240
639
110
Mio
.20
6-
291
4042
4741
538
521
749
-3
210
558
-1
Tabelle 18: Anfragezeiten [in s] des SP2-Benchmarks im EndpointNetwork mit verschiedenenVerteilungsstrategien
99
5 Evaluierung
OneKeyDistribution nicht auftreten, da hier der anfragende Client zwar alle Ergebnis-
se entgegennehmen muss, die anderen Peers jedoch nur Daten liefern und damit weder den
Speicher auslasten noch Berechnungen wie Joins durchführen müssen. Außerdem zeigt sich
bei den initialen Datenmengen, die im EndpointNetwork geladen werden müssen, dass
diese nicht gleichverteilt sind. Dies ließ sich über die Einfügezeit und -menge an den jewei-
ligen Peers zeigen. Es wurde bereits erklärt, dass trotz der Partitionierung auf einigen Peers
mehr Daten zu verwalten sind als bei anderen, da diese P2P-Schlüssel mit einer größeren Da-
tenmenge verwalten. Dies ist auf häufiger benutzte RDF-Prädikate zurückzuführen (siehe dazu
Anhang A). Vor allem fällt in den Vortests auf, dass Berechnungen der Anfragen q2 und q6 bei
der OneKeyDistribution nicht durchgeführt werden konnten und deshalb in der Ergeb-
nisgrafik (Abbildung 38) fehlen. Dies liegt vor allem daran, dass die Tripelmuster der Abfra-
ge häufige RDF-Prädikate benutzt. So werden u.a. folgende Prädikate verwendet: »rdf:type«
(20%), »dc:creator« (14%), »foaf:name« (8%) sowie »dcterms:issued« (4%)7. Diese Prädika-
te sind jedoch bei den von SP2B generierten Daten in sehr vielen Datensätzen vorhanden, um
diese näher zu spezifizieren. Vor allem die ersten beiden genannten Prädikate sind sehr häufig
vorhanden, so dass diese Tripelmengen sehr groß sind (hier: bei 1Mio.). Werden diese nun par-
allel am Client gesammelt, da in der OneKeyDistribution keine Auslagerung auf andere
Peers vorgesehen ist, entsteht plötzlich eine riesige zu verwaltende Datenmenge, die in weite-
ren Operationen verarbeitet werden muss und in LuposDate deshalb die Variablenbindungen
der Ergebnismengen im Speicher verbleiben. Beim jeweiligen Vergrößern des Speichers für
diese Bindungen ist aber bei beiden Anfragen der Programmspeicher nicht mehr ausreichend
gewesen. Ein sogenannter Heap-Dump, der dieser Arbeit beiliegt, bestätigt diese Vermutung.
Des Weiteren zeigt dies, dass ein Rechnerpool der 5 Knoten eines P2P-Netzes darstellt, zu vie-
len Kollisionen führt, da selbst die Werte der Verteilungsstrategien, die verteilte Berechnungen
ermöglichen, sehr hoch sind.
Bewertung des EndpointNetworks
Vor allem bei der neunfachen Einfügemenge (NinefoldInsertion) ergibt sich bei 10
Millionen Tripel ein effektiver Datensatz von 90 Millionen Tripel, die ungleichmäßig auf die
Endpoints verteilt sind (s.o.). Dass die Summe der einzelnen, an den Endpoints gespeicher-
ten Daten nicht wieder 90 Millionen Tripel ergab, zeigt, dass das EndpointNetwork keine
realistische P2P-Implementierung ist. Während im P2P-Netz die Daten an Schlüsseln gespei-
chert werden, dient in der Endpoint basierten Version der Schlüssel lediglich zur Auswahl des
richtigen Endpoints, nicht aber zur Datenbeschaffung oder Eingrenzung der Datenmenge auf
dem Knoten. Dafür wird der RDF3X-Evaluator verwendet, der Duplikate eliminiert und da-
mit nur ein Tripel einfügt, auch wenn durch die Verteilungsstrategie dieses Tripel auch unter
einem anderen Schlüssel gespeichert werden müsste. Ein damit entstandener Unterschied von
21 Millionen Daten, die im P2P-Netz hätten mehr gespeichert werden müssen, zeigt, dass das
EndpointNetwork nicht mit den Ergebnissen von TomP2P verglichen werden kann. So-
mit sind die Ergebnisse des durchgeführten Tests in „pool2“ aus Abbildung 39 nicht mit den
vorigen Tests in Beziehung setzbar.
7In Klammern: Prozentualer Anteil gemessen an allen Tripeln des SP2B-Datensatzes.
100
5 Evaluierung
Test mit 5 bzw. 10 Millionen RDF-Tripeln
In der Abbildung 39 zeigt sich beim Vergleich zwischen 5 Millionen und 10 Millionen Tripel
im Endpoint basierten System, dass die neue Verteilungsstrategie NinefoldInsertion
in q1 sowie q3b und q3c bei einem Datensatz von 10 Millionen RDF-Tripeln schneller war
als die anderen Verfahren. Bei 5 Millionen Tripeln liegt das Verfahren in der ersten Abfrage
noch leicht hinterher, sodass sich dort die 9-fache Datenmenge erst bei größeren Datensätzen
bezahlbar macht und die Auslagerung und das Joinen an anderen Knoten einen Geschwindig-
keitsvorteil von über 20 Sekunden bringt. Auffällig ist außerdem, dass die Verdopplung der
Tripelmenge auch zur Verdoppelung der Berechnungszeit führt. Dies liegt jedoch in diesem
Fall an den generierten SP2B-Daten, da diese entsprechend doppelt so viele gleichwertige Da-
ten produzieren, sprich Instanzen, die mit denselben Prädikaten versehen und gefüllt werden.
Bei realistischen Daten kann dies durchaus unterschiedlich und nicht eine so proportionale
Ausprägung sichtbar sein. Vor allem durch die nicht mögliche gleichzeitige Ausführung meh-
rerer unterschiedlicher Evaluatoren in LuposDate dienen Synchronisierungen zwischen den
Evaluatoren für den lokalen Speicher (RDF3X) und der P2P-Komponente. Diese verhindern
das gleichzeitige Ausführen und resultiert damit in einer sequenzartigen Abarbeitung der zu
berechnenden Aufgaben, weshalb sich bei einigen Abfragen (q2, q4, q6, q8) entsprechend
hohe Werte ergeben, auch wenn Partitionsjoins durchgeführt werden. Auffällig ist, dass die
Anfragen, die im Vortest aufgrund von Speicherproblemen auch in der größeren Testumge-
bung nicht bei der OneKeyDistribution und OneToThreeKeysDistribution lie-
fen. Dies liegt daran, dass bei den beiden Verteilungsstrategien keine Lastverteilung auf den
anderen Knoten vorgenommen wird. Deshalb werden alle Daten von dem Client direkt ange-
fragt, was zu einer parallelen Datenübertragung aller Anfragen führt, die vom Client entgegen-
genommen werden muss. Dies führt aufgrund der riesigen Datenmengen wie in den genann-
ten Anfragen zu einem Speicherdefizit. Die Verteilungsstrategien NinefoldInsertion
und SimplePartitionDistribution hingegen nutzen die Berechnungen im P2P-Netz,
weshalb viele Anfragen trotzdessen beantwortet werden können. Dennoch zeigt sich dies auch
in der benötigten Zeit, die durch die Synchronisation der Evaluatoren und der parallelen Verar-
beitung negativ beeinflusst wird.
Im Schnitt ließ sich in der Debug-Konsole erkennen, dass etwa 500-1200 Tripel pro Sekunde
zwischen zwei Endpoints gesendet werden konnten. Die Zeit ergibt sich aus der Serialisierung
der Daten sowie das Senden über die HTTP-Schnittstelle. Bei einem Datenumfang von 10
Millionen Tripel und einer Abfrage, in der das Tripelmuster lediglich das Prädikat »rdf:type«
beinhaltet, ergibt das immerhin ein Datenumfang von 2 Millionen Tripel, was die entsprechen-
de Zeit benötigt. Bei schlechten ausgewählten Knoten, die den Join zweier Partitionen durch-
führen (also solchen, wo der Join an der geringeren Datenmenge gejoint wird und die große
Datenmenge stets übertragen werden muss), ist deshalb mehr Zeit nötig, vor allem wenn die
Ergebnismenge entsprechend groß ist und zurück zum Client gesendet werden muss.
Die relativ gleichen Ausführungszeiten zwischen den Anfragen q5a und q12a bzw. q8 und q12b
lassen sich dadurch erklären, dass diese Anfragen stets die gleichen sind, wobei die späteren
Anfragen jedoch lediglich das Vorhandensein des Datums über die „ASK“-Klausel beinhal-
ten. Bei den einfachen Verteilungsstrategien ließen sich beide Anfragen nicht berechnen, da
101
5 Evaluierung
wiederum alle großen Daten zeitgleich (und in diesen Abfragen sogar mehrfach) beim Client
verarbeitet werden mussten, was zu einem Speicherfehler führte.
Die SimplePartitionDistribution ist in fast allen Fällen etwas langsamer als die an-
deren Verfahren. Hier kann auch der Vorteil der parallelen Joins oft nicht ausgenutzt werden, da
durch die geforderten deterministische Berechnung der P2P-Schlüssel nur drei Schlüsselkom-
binationen möglich sind. Dies führt zu drei Einfügungen in das Netz pro Tripel – dies ist ebenso
gut wie die OneKeyDistribution, wobei wie bereits erwähnt eine Indexstruktur an den
Knoten genutzt werden muss, um nicht mehr durch die Ergebnismenge iterieren und Eliminie-
rungen durchführen zu müssen. Diese Funktionalität ist jedoch aufgrund des oft nicht vorhan-
denen Index in der Verteilungsstrategie implementiert, sodass selbst im EndpointNetwork
eine Datenüberprüfung anhand des Anfragemusters durchgeführt wird, was bei großen Daten
entsprechend Zeit in Anspruch nimmt. Außerdem kann diese Verteilungsstrategie mit Anfra-
gen, die nur eine feste Komponente besitzt, keine perfekte Schlüsselauflösung vollziehen, da
hier alle Partitionen geprüft werden müssen. Selbst bei Anfragen mit zwei festen Komponen-
ten ist durch die Hashauflösung der zweiten Komponente lediglich der Datensatz der zu ite-
rierenden Daten bei einer Partitionsanzahl n = 2 nur halb so groß wie zuvor. Bereits in den
Testdurchführungen in TomP2P zeigte sich, dass sich dieses Verfahren im Allgemeinen nicht
lohnt und für diesen Zweck die neunfache Datenmenge mit der NinefoldInsertion zu
nehmen ist, die vermehrt Joins an Partitionen im Netz ermöglicht.
Ein weiteres Problem, dass es zu optimieren gilt, ist die Tatsache, dass oft unnötig Daten im
Netz verschickt werden. Anhand des Beispiels in Abbildung 40 wird dieses verdeutlicht.
Abbildung 40: Verdeutlichung von nicht optimaler Datenversendung anhand eines Beispiels
In der Optimierungsstrategie sendet der Client (node 1) eine entsprechend dargestellte Unter-
operatoranfrage an Peer 3, wobei anhand der jeweiligen Partitionen ein Join zwischen den
lokalen Daten von Peer 3 und den zugesendet bekommenden Daten von Peer 2 erfolgt. Dieses
Ergebnis wird anschließend mit den empfangenden Daten der Partition von Peer 1 gejoint
102
5 Evaluierung
und das Ergebnis anschließend zum angefragten Client (Peer 1) gesendet. Wenn diese Daten
jedoch relativ groß sind, wird hier ein riesiger Datensatz von Peer 1 nach Peer 3 gesendet,
und das Join-Ergebnis dann wieder zurück gesendet. Optimiert werden könnte hier, dass in
der Unteranfrage nur der Join zwischen Peer 2 und 3 erfolgt und das Ergebnis dann direkt am
Client verarbeitet wird. In der Optimierung ist jedoch aufgrund der losen Kopplung zwischen
der SPARQL-Engine und dem P2P-Netz keine Feststellung möglich, welche P2P-Schlüssel
der Client-Knoten verwaltet, vor allem weil sich dieser auch dynamisch ans Netz anpasst. So
ergeben sich vor allem bei wenigen Rechnern im P2P-Netz oft derartige Strukturen, die unnötig
große Daten versenden.
5.8 Vergleich der Verteilungsstrategien ohne Untergraphanfragen
In diesem Test soll vor allem das strukturierte P2P-Netz im Vordergrund stehen, sodass die
Datenbeschaffung nicht über Unteroperatorgraphanfragen geschieht und somit keine externen
Joins unterstützt werden. So werden alle Anfragemuster direkt in den Schlüssel übersetzt und
dieser vom Client aus im P2P-Netz abgefragt. Bei den vorigen Tests geschah dies stets über
Teil-Operatorgraphen, die an die entsprechenden Peers durch den Schlüssel gesendet wurden.
Dort wurden dann die Operationen und auch die Datenbeschaffung anhand der lokal verfügba-
ren Daten durchgeführt.
5.8.1 Testdurchführung
Für diesen Test wird das BSBM-Benchmark im „pool2“ genutzt, sodass insgesamt 9 vernetze
Peers zur Verfügung stehen. Die Verteilungsstrategien OneKeyDistribution, OneTo-
ThreeKeysDistribution, SimplePartition sowie NineFoldInsertion wur-
den dabei gegenübergestellt, da sich diese als erfolgversprechendste Strategien aus den vori-
gen Tests ergaben. Für die Benchmark-Anfragen wurden mittels des Generators Datensätze der
Skalierung 100 und 1000 verwendet, um einen Trend ersehen zu können. Dies macht effektiv
40377 bzw. 374911 Tripel aus, die in das zu testende P2P-System TomP2P eingefügt werden.
Die Testdurchführung kann mit der Konsole über den Parameter »-noSG_Submission«8 gesteu-
ert werden, der dem Evaluator in LuposDate mitteilt, dass keine Optimierungsregeln für das
Erstellen von SubgraphContainern ausgeführt werden. Dies bewirkt, dass die Schlüssel
direkt als Anfrage (und nicht als Unteroperatorgraph-Nachricht) im P2P-Netz abgesetzt und
das Ergebnis empfangen wird. Für die Datenbeschaffung und das Routing sorgt in diesem Fall
TomP2P. Als Standardabweichung wurde ein Spielraum bis 10% zugelassen, wobei aus den
Anfragen mit unter einer Sekunde Ausführungszeit (vor allem q9, q11) der mittlere Messwert
(Median) gewählt wurde, da eine so exakte Messung in diesem Bereich mit Java nicht aussage-
kräftig ist. Auch hier muss bedacht werden, dass die Netzwerk-Instanziierung pro Strategie drei
Mal erfolgte, da TomP2P die zugeschalteten Peers stets neu auf die Schlüsselmenge aufteilte,
sodass sich Fälle ergeben, wo die häufig genutzten Daten auf dem Anfrageclient liegen oder
durchs Netz übertragen werden müssen, wobei ersteres in kurzer Zeit erfolgen kann. Dieses
nichtdeterministische Verhalten muss bei der Auswertung später berücksichtigt werden. Die
Ergebnisse des durchgeführten Tests sind in Tabelle 19 bzw. Abbildung 41 dargestellt.
8Eine Übersicht über die Konsolen-Parameter findet sich im Anhang D. 103
5 Evaluierung
BSB
MSk
alie
rung
100
BSB
MSk
alie
rung
1000
Nin
efol
dO
neK
eySi
mpl
ePar
titio
nO
neTo
Thr
eeK
eys
Nin
efol
dO
neK
eySi
mpl
ePar
titio
nO
neTo
Thr
eeK
eys
Que
ry1
1516
1338
1795
1420
1602
3070
5754
1567
Que
ry2
913
1373
984
1031
2455
3606
2672
2910
Que
ry3
1939
2601
2009
2693
2110
933
003
2803
621
288
Que
ry4
401
632
767
600
2216
4710
5898
3370
Que
ry5
1724
2075
772
1076
4427
6177
6068
6655
Que
ry6
303
277
286
357
1159
1799
1680
1561
Que
ry7
3100
3461
2732
3398
2965
340
732
3298
437
483
Que
ry8
549
1350
607
866
7396
1364
576
4611
044
Que
ry9
911
119
1011
149
Que
ry10
2052
2530
2292
2492
2648
036
292
3065
826
509
Que
ry11
157
109
107
137
Que
ry12
259
449
268
453
1896
2556
2320
2570
Tabelle 19: Anfragezeiten [in ms] des BSBM-Benchmarks ohne Versendung von Unterope-ratorgraphen und der gesamten Berechnung am Client mit verschiedenen Vertei-lungsstrategien
104
5 Evaluierung
Abbildung 41: Anfragezeiten [in ms] des BSBM-Benchmarks ohne Versendung von Unter-operatorgraphen und der gesamten Berechnung am Client mit verschiedenenVerteilungsstrategien
105
5 Evaluierung
5.8.2 Auswertung
In den Ergebnissen aus Tabelle 19 ist vor allem bei der Benchmark-Skalierung von 1000 er-
kennbar, dass sich in dem Testversuch die Vor- und Nachteile der Verteilungsstrategien wider-
spiegeln. So ist bereits in der Konzeption der Verteilungsstrategien (Kapitel 3.2.3) beschrieben
worden, dass vor allem bei der OneKeyDistribution und der SimplePartition-
Distribution bei bestimmten Anfragen ein nachträgliches Iterieren durch die Ergebnis-
menge nötig ist, und aus dieser die Elemente entfernt werden müssen, die nicht zum Anfra-
gemuster passen. Dies tritt bei der OneKeyDistribution immer bei Anfragen auf, die
mehr als eine feste Komponente besitzen, da jeweils nur eine Komponente als Schlüssel ver-
wendet wird. Selbst im Trend zwischen den beiden getesteten, um den Faktor 10 skalierten
Datenmengen, zeigt sich, dass in den Anfragen 7, 10 und 12 mehrere solcher nachträglichen
Eliminierungen nötig sind. Vor allem in der SimplePartitionDistribution zeigt sich
dieses stark. Obwohl wie bei der OneKeyDistribution nur die dreifache Datenmenge
im Netz hinterlegt wird, sind in dieser Verteilungsstrategie immer nachträgliche Auflösun-
gen nötig. Bei Anfragen mit zwei festen Komponenten lässt sich zwar die genaue Partition
wie etwa „<Subject>P0“ feststellen, da der Hashwert der Prädikatkomponente hier eindeu-
tig die Partition bestimmt, jedoch sind in dieser Partition auch alle Tripel gespeichert, die
denselben Hashwert aufweisen, sodass eine Überprüfung der Ergebnismenge zwingend nö-
tig ist. Bei Anfragen mit einer Komponente sind bei der Verteilungsstrategie alle disjunk-
ten Partitionen zu betrachten (vgl. Tabelle 6, S. 40). Deshalb schneidet dieses Verfahren bei
diesem Test auch vergleichsweise schlecht ab. Bis auf einige Schwankungen (q7, q8, q10)
sind die Werte verhältnismäßig mit der OneKeyDistribution zu vergleichen, wobei die-
ses Verfahren durch die ständige Nachauflösung auch in vielen Fällen mehr Zeit benötigt
(q1, q4). Dieser Trend wird sich bei größeren Datenmengen bestätigen. Diese konnten je-
doch aufgrund des speicherlastigen TomP2P nicht verifiziert werden, dennoch zeigt sich bereits
bei der Verzehnfachung der Datenmenge, dass die Zeitverhältnisse es zu schließen erlauben.
Betrachtet man die beiden verbleibenden Verteilungsstrategien NinefoldInsertion und
OneToThreeKeysDistribution fällt auf, dass diese bei den meisten Anfragen diesel-
ben Ausführungszeiten benötigen bis auf Schwankungen in den Anfragen 7 und 8 des BSBM-
Benchmarks. Da eigentlich beide Verfahren eine perfekte Schlüsselauflösung beherrschen, ist
es erstaunlich, dass in den angesprochenen Anfragen Unterschiede von 4-8 Sekunden zu ver-
zeichnen sind. Dies mag an der angesprochenen Testungenauigkeit liegen, sodass in diesem
Fall trotz der Testwiederholungen viele Tripel bereits am Anfrageclient lokal vorlagen, so-
dass diese nicht durch das Netz transportiert werden mussten oder es sich lohnt, entsprechende
kleinere Partitionen zu Joinen, was den Zeitunterschied erklärt. In den Anfragen 9 und 11
werden jeweils nur maximal zwei Anfragemuster gestellt, sodass sich die kurzen Anfragezei-
ten ergaben. Aufgrund der ungenauen Zeitmessung von Java und den geringen Zeiten lässt
sich aus diesen kein Schluss ziehen, vor allem da in diesen Größenverhältnissen auch Fak-
toren des Betriebssystem eine wichtige Rolle einnehmen können, die zu Verzögerungen füh-
ren. Insgesamt betrachtet sind in diesem Test vor allem die beiden Strategien, die perfekte
Schlüsselauflösungen beherrschen, im Vorteil, da kein nachträgliches Eliminieren falscher Tri-
pel notwendig ist. Die NinefoldInsertion schneidet in diesem Test dabei am Besten
106
5 Evaluierung
ab, sodass sich die Verteilungsstrategie mit der Partitionierung gegenüber den anderen Ver-
fahren durchsetzen kann. Während bei der kleineren Skalierung aufgrund der geringen Da-
tenmenge von nur etwa 50 Tausend Tripel die NinefoldInsertion bei den Anfragen
q2, q3, q4, q8, q9, q10, q12 besser abschnitt, ist bei der zehnfachen Datenmenge bei je-
der Anfrage eine bessere Abfragezeit erreicht worden, wenn die schnellen Anfragen q9 und
q11 ignoriert werden. Dort liegt das Verfahren lediglich ein bis drei Millisekunden hinter der
OneToThreeKeysDistribution. Selbst die aufgrund der fehlenden Indexstruktur bei
TomP2P nicht optimale SimplePartitionDistribution ist bei den Anfragen q7, q8
und q12 besser als die einfachen Verteilungsstrategien, sodass die Partitionierung in diesen Fäl-
len aufgrund der kleineren zu joinenden Datenmengen im Vorteil ist. In q1 und q4 hingegen
liegt die SimplePartitionDistribution auf dem letzten Platz, sodass hier der Mehr-
aufwand bei der Dateneliminierung aufgrund der fehlenden Index-Struktur größer ist, als bei
den anderen Verteilungsstrategien.
Zusammenfassend liegen die beiden Verteilungsstrategien NinefoldInsertion und
OneToThreeKeysDistribution weit vor den Ergebnissen der anderen Verfahren, was
auf die Schlüsselauflösung zurückzuführen ist. Dennoch können die Verfahren mit der Partitio-
nierung in einigen Abfragen des BSBM-Tests punkten, da die Joins auf kleinere Datenmengen
einen Vorteil von bis zu 10 Sekunden gegenüber der OneKeyDistribution aufwiesen (q3,
q7, q10). Trotz des im Vergleich zur OneKeyDistribution dreifachen Speicheraufkom-
mens, zeichnet sich die NinefoldInsertion in diesen Fällen weit von den Ergebnissen
der anderen Verfahren ab. In Anbetracht dessen, dass bei höheren Skalierungen noch mehr
Zeitvorteile zu erwarten sind, ist auch die neunfache Datenmenge, welche dieses Verteilungs-
verfahren benötigt, hinnehmbar.
Jedoch findet in diesem Test der Vorzug der Lastbalancierung nicht statt, die von den neuen
Strategien NinefoldInsertion und SimplePartitionDistribution unterstützt
werden. Diese lässt sich nur Nutzen, wenn die Daten über SubgraphContainer durch das
P2P-Netz verschickt und dann auf den P2P-Knoten die jeweiligen Joins an Partitionen gebildet
werden. Eine Möglichkeit wäre es, eine Vermischung beider Ansätze zu nutzen, sodass Last-
balancierung stattfindet, sofern entsprechende Join-Partner anhand der gleichen Partitionsart
ausfindig gemacht werden können, und ansonsten die Daten direkt aus dem P2P-Netz abzu-
fragen sind. Dabei muss jedoch in späteren Evaluierungen gezeigt werden, ob TomP2P eine
entsprechend große Datenmenge übertragen kann.
107
6 Zusammenfassung und Ausblick
6.1 Zusammenfassung der Arbeit
In dieser Arbeit wurde eine Anbindung von P2P-Netzen an SPARQL-Engines konzipiert, die es
erlaubt, die Anfrageverarbeitung und Datenverteilung in einem dynamischen P2P-Netz durch-
zuführen. Im Gegensatz zu bereits existierenden Ansätzen ist es nun möglich, sowohl das P2P-
Netz wie auch die SPARQL-Engine frei zu wählen, sodass keine feste Bindung an bestimmte
Systeme nötig ist und die entwickelte Komponente keine Abhängigkeiten besitzt. Vor allem im
Kontext des IoT ist die Nutzung von P2P-Netzen nicht ungewöhnlich, da vor allem IoT-Geräte
autonom und selbst-organisierend agieren müssen und bei der Vernetzung solcher intelligenter
Geräte die gemeinsame Datenmenge für individuelle Auswertungen genutzt werden kann. Um
diese Möglichkeiten zu realisieren, wurde beispielhaft die SPARQL-Engine LuposDate erwei-
tert, sodass die Datenverteilung und -auswertung in ein P2P-Netz ausgelagert wird. Vor allem
durch die Möglichkeit des Versendens von Unteroperatorgraphen in LuposDate, bietet dieses
eine Lastverteilung der Ausführung von SPARQL-Anfragen, die auf beliebige Knoten des Net-
zes ausgelagert werden können. Mit Hilfe von mehreren Verteilungsstrategien wurde außerdem
die Optimierung von Joins, die im Netz berechnet werden können, ermöglicht. Dies beinhaltet
auch die asynchrone und parallele Verarbeitung von Teilanfragen, sodass die Erweiterung der
SPARQL-Engine auf eine P2P-Struktur von großem Nutzen sein kann.
6.2 Offene Punkte
Vor allem in der Evaluierung zeigte sich, dass große Datenmengen mit dem etablierten P2P-
System TomP2P nicht zu behandeln sind, da die Strukturen für Nachrichtenströme fehlten.
Außerdem funktionierte die persistente Speicherung der Daten in TomP2P nicht korrekt, so-
dass einige Tripel nicht gespeichert wurden und es so zu Fehlern kam, weshalb diese Speicher-
schicht nicht in Betracht kam. Dort zeigte sich ebenfalls, dass die Strukturen, in welchen die
Daten gespeichert werden, für allgemeine Datentypen gedacht sind und nicht für RDF-Tripel
des semantischen Webs. So werden die entsprechenden Informationen in TomP2P in einem
In-Memory-Speicher gehalten, d.h. dass jegliche Daten in einer Hashtabelle im Arbeitsspei-
cher verwaltet werden. Für die leider fehlerbehaftete persistente Speicherung dient in TomP2P
und anderen Systemen wie Chordless und FreePastry, eine relationale Datenbank, die entspre-
chend das (serialisierte) Datum anhand der jeweiligen Hashes speichert. Dies berücksichtigt
jedoch nicht den Datentyp „Triple“ und ist deshalb auch für keine Indizierung oder perfor-
108
6 Zusammenfassung und Ausblick
mante Auflösung semantischer Daten gedacht. Da in dem konzipierten System jedoch nur
RDF-Daten gespeichert werden, ist ein darauf spezialisiertes P2P-System zu nutzen, welches
dieses optimiert vornimmt. So könnte die Speicherebene des P2P-Systems in einem „native
storage"vorgenommen werden (Stegmaier et al., 2009). Dort werden RDF-Daten permanent
persistent im Dateisystem in einer gut untersuchten Indexstruktur wie einem B-Baum gespei-
chert. Diese Ansätze bestehen bereits, wie z.B. in RDF3X, beachten jedoch keine Schlüssel
basierte Speicherung. Auch eine Lösung für relationale Datenbanken wird angeboten, wobei
eine Tabelle alle RDF-Tripel komponentenweise enthält und dann weitere Tabellen für Indizie-
rungen genutzt werden können. Außerdem muss eine Tabelle für das Mapping zwischen P2P-
Schlüssel und Datum vorhanden sein. Sollte ein persistenter Speicher in TomP2P integriert
werden, kann außerdem evaluiert werden, ob ein geteilter Ansatz der Datenverarbeitung sinn-
voll ist. Hier findet eine Lastbalancierung über Unteroperatorgraphen nur statt, sofern passende
Join-Partitionen gefunden werden. Die restlichen Daten werden dann direkt über die verteilte
Hashtabelle des P2P-System angefragt und am Client verarbeitet, da dies in den Evaluationen
schneller erfolgte, als wenn die Daten ebenfalls über Unteroperatorgraphen verschickt wurden.
Zudem zeigte sich, dass die Daten im P2P-Netz nicht gleichmäßig verteilt sind. Dies liegt z.B.
daran, dass einige Prädikate häufiger benutzt werden als andere (vgl. Exkurs „Statistiken zum
DBPedia-Datasetïm Anhang A). Das führt dazu, dass je nach Verteilungsstrategie nahezu alle
Tripel, die ein bestimmtes Prädikat enthalten, auf einem Peer gespeichert werden und resul-
tiert darin, dass einige Peers häufiger für Abfragen benötigt werden und außerdem viel größere
Datenmengen verwalten als andere Peers. Zwar nehmen die neuen Verteilungsstrategien be-
reits eine Aufteilung in die entsprechende Anzahl an Partitionen vor, jedoch genügte dies in
der Evaluierung nicht, da die Daten lediglich in zwei Partitionen aufgeteilt wurden. Dies lag
vor allem an der begrenzen Anzahl an Rechner und dem geringen verfügbaren Arbeitsspeicher,
der für die interne Verarbeitungen nicht genügend Speicher besaß. Eine Möglichkeit wäre es,
die Anzahl der Partitionen herauf zu setzen, was jedoch anhand der erhöhten Kollisionswahr-
scheinlichkeit in einen größeren Rechnerumfang resultiert. Ein n−faches Hashen ähnlich der
Methode von Mietz et al. (2013) würde für eine bessere Verteilung sorgen, endet jedoch bei
der Anfrageverarbeitung in einen Mehraufwand, da alle n Hashes berechnet und die Ergebnis-
se verarbeitet werden müssen.
Des Weiteren ist in der Evaluierung aufgefallen, dass im P2P-System TomP2P für die Hashbe-
reichsaufteilung nicht deterministische Funktionalität genutzt wird. Dies führt dazu, dass jede
Testwiederholung bzw. jedes Starten des P2P-Systems zu einer neuen Aufteilung der Hash-
bereiche unter den Peers führt und damit zu einer unterschiedlichen Datenverteilung unter den
Peers. So lassen sich zwar die Werte einer Verteilungsstrategie, sofern diese ohne Neustart oder
Änderung des Netzes ermittelt wurden, gut messen. Sobald jedoch ein neues Netz instanziiert
wird, z.B. um eine andere Verteilungsstrategien zu testen, kann die Datenverteilung auf den
Peers anders erfolgt sein als in einem vorigen Test, sodass sich die ermittelten Anfragezeiten
an manchen Stellen schwer vergleichen lassen.
109
6 Zusammenfassung und Ausblick
6.3 Ausblick
Die Entwicklungen dieser Arbeit zeigen bereits, dass eine Lastverteilung für die Berechnun-
gen in einem P2P-Netz durchaus Vorzüge haben. Der Vorteil liegt darin, dass die Berechnungen
möglichst dort durchgeführt werden, wo auch der größte Datenbestand der Anfrage vorhanden
ist. Dies führt dazu, dass die Verbindungen der Peers nicht damit blockiert werden, Datenmen-
gen zu übertragen die in der späteren Verarbeitung ohnehin stark verringert würden. Außerdem
wird verhindert, dass eine Berechnung in zwei Phasen, dem Abfragen und der Auswertung,
unterschieden wird. In herkömmlichen Realisierungen werden alle Ergebnisse am angefragten
Client empfangen und dann anhand der Operationen im Operatorbaum weiterverarbeitet. Das
in dieser Arbeit entwickelte Verfahren führt dazu, dass einige Berechnungen bereits ins P2P-
Netz verlagert werden, sodass nur wenige Operationen mit dem reduzierten Datenbestand am
angefragten Client durchgeführt werden müssen.
Um diese Entwicklungen noch mehr zu fördern, ist auf jeden Fall persistentes Speichern der
Daten in einer entsprechend für RDF-Daten geeigneten Index-Struktur zu ermöglichen, sodass
der Arbeitsspeicher entlastet wird und riesige Datenmengen verarbeitbar sind. Außerdem ist in
diesem Fall nach einem Neustart eines Knotens die Datenmenge noch vorhanden, wenn eine
Umverteilung durch das P2P-System nicht mehr möglich gewesen ist und sonst einen Daten-
verlust bewirken würde. Zudem lässt sich das Ausführen von zeitaufwändigen Operationen
auf Peers verteilen, die zu der Zeit wenig Belastet sind, sodass Statistiken über die Auslas-
tung des Netzes dazu führen, dass Berechnungen an andere Knoten delegiert werden. Bisher
erfolgte dies lediglich an den Partitionen, die miteinander gejoint werden müssen. In späteren
Entwicklungen können diese Ergebnisse dann von anderen wenig belasteten Knoten empfan-
gen werden und dann ähnlich des Divide and Conquer-Prinzips der globale Operatorgraph in
sinnvolle Teilgraphen untergliedert im Netz verteilt berechnet und zusammengeführt werden.
Auch für das implementierte Endpoint-Network ist eine womögliche Verbesserung zu untersu-
chen, die dem P2P-System und dessen Schlüssel näher kommt. Momentan werden die Schlüs-
sel lediglich für die Zuordnung der jeweiligen Endpoint-URLs verwendet, nicht jedoch für die
Datenspeicherung. Hier könnte untersucht werden, ob das Starten unterschiedlicher Instanzen
pro Schlüsselart eine Verbesserung bringt. Dies erlaubte dann, dass in den Verteilungsstrate-
gien kein Determinismus mehr gefordert werden müsste, da durch die Zuordnung der Schlüs-
selkombination der zu nutzende Schlüssel bestimmt ist. Vor allem für die Endpoint-URLs ist
damit auch eine gezieltere Datenspeicherung ähnlich der P2P-Schlüssel zu verzeichnen, sodass
getrennt auf diese Datenmengen zugegriffen werden kann, die nicht miteinander interferieren.
Ob diese Möglichkeit eine Verbesserung erreicht, müsste in späteren Arbeiten integriert und
evaluiert werden.
Im Kontext der IoT-Geräte ist auch zu untersuchen, ob eine angepasstere Verteilung im dyna-
mischen Netz genutzt werden kann. Der Nachteil der DHTs ist es, dass die Daten anhand der
Schlüssel verteilt werden. Bei IoT-Geräten wären eventuell Publish-Subscribe-Methoden oder
Map-Reduce-Ansätze passender, sodass die Geräte diejenigen Daten bekommen, die sie für
häufige Anfragen benötigen werden. So ist lediglich für selten benötigte Daten ein Routing im
Netz und die damit verbundene Datenübertragung nötig. Je nach Anwendungsgebiet könnten
110
6 Zusammenfassung und Ausblick
diese Ansätze eine bessere auf den Anwendungsfall optimierte Datenverteilung vornehmen.
Bei DHTs mit der Lokalisierung der Daten über Schlüssel sind jene Daten zwar im Netz relativ
gleichverteilt (anhand des Schlüsselraums), jedoch sind bereits bei einfachen Anfragen viele
Datenübertragungen nötig. Verbunden mit der Tatsache, dass viele Anfragen ähnliche Tripel-
muster verwenden, führt dies auch zu einer erhöhten Auslastung des entsprechenden Knotens.
111
Abbildungen
Abbildung 1: Architektur von P2P Netzen . . . . . . . . . . . . . . . . . . . . . . . . 5
Abbildung 2: Schema: Semi-Zentralisierte P2P-Netze mit „super nodes“ . . . . . . . . 6
Abbildung 3: Ein Beispiel, wie verteilte Hashtabellen funktionieren, Quelle: Chou
et al. (2007), S.17 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
Abbildung 4: Einfacher RDF-Graph mit einer Tripel-Aussage zur Beschreibung der
Farbe eines Baumes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
Abbildung 5: RDF-Graph mit Aussagen über den Science-Fiction-Film Matrix . . . . . 11
Abbildung 6: Funktionsprinzip einer Ontologie anhand des Beispiels eines Museums,
Quelle: Public domain by Häger via Wikimedia Commons . . . . . . . . 12
Abbildung 7: Architektur von LuposDate, Institut für Informationssysteme (IFIS),
Universität zu Lübeck, http://www.ifis.uni-luebeck.de/index.php?L=1&
id=luposdate-demo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
Abbildung 8: Beispiel-Baum im P2P-Framework P-Grid/GridVine . . . . . . . . . . . 19
Abbildung 9: Verteilung von RDF-Daten in RDFPeer, Quelle: Cai & Frank (2004) . . . 20
Abbildung 10: Grundgedanke für die P2P-Anbindung in einer SPARQL-Engine . . . . . 27
Abbildung 11: Verwaltungsinstanz für das Verwalten von beliebigen P2P-Systemen . . . 30
Abbildung 12: Schlüsselbildung bei den fortgeschrittenen Verteilungsstrategien mit ein-
stufiger und zweistufiger Partitionierung . . . . . . . . . . . . . . . . . . 42
Abbildung 13: Problem-Szenario mit nicht deterministischen Schlüsseln in Verteilungs-
strategien . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47
Abbildung 14: Beispiel für das Einfügen von Tripeln und dem Abfragen von Tripeln in
der einfachen hierarchischen Verteilungsstrategie. . . . . . . . . . . . . . 49
Abbildung 15: Beispiel für das Einfügen von Tripeln und dem Abfragen von Tripeln in
der Verteilungsstrategie mit zweifacher Partitionierung . . . . . . . . . . 50
Abbildung 16: Parallele Unteroperatorgraphen bei der Nutzung von Verteilungsstrategi-
en mit Partitionierung . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52
Abbildung 17: Optimierung durch Verschmelzung der Anfragen an gleiche Schlüssel . . 53
Abbildung 18: Beispielhafter optimierter Operatorbaum mit Partitionierungen . . . . . . 54
Abbildung 19: Verbindungsregel Teil 1: Finden von Partitions-Operatoruntergraphen . . 55
Abbildung 20: Verbindungsregel Teil 2: Finden von zugehörigen Partitions-Operatorun-
tergraphen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56
Abbildung 21: Verbindungsregel Teil 3: Verbinden der Unter-Operatorgraphen und Säu-
bern des globalen Operatorgraphen . . . . . . . . . . . . . . . . . . . . . 56
Abbildung 22: Verbindungsregel Teil 4: Endergebnis der Optimierung . . . . . . . . . . 57
Abbildung 23: UML-Klassendiagramm des Interfaces IStorage . . . . . . . . . . . . . . 60
112
Abbildungen
Abbildung 24: UML-Klassendiagramm der IStorage-Implementierung StorageWith-
DistributionStrategy . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60
Abbildung 25: UML-Klassendiagramme zu der P2P-Implementierung in LuposDate . . 61
Abbildung 26: UML-Klassendiagramm zur Verwaltung von verschiedenen P2P-Imple-
mentierungen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63
Abbildung 27: Klassendiagramm für die Verarbeitung von Unteroperatorgraphanfragen . 67
Abbildung 28: UML-Diagramm der Schnittstelle IDistribution . . . . . . . . . . . . . . 68
Abbildung 29: UML-Diagramm der Schnittstelle AlternativeKeyContainer . . . . . . . 69
Abbildung 30: Beispiel für parallele Unteranfragen, sowie die Vereinigung der Ergeb-
nisse im Operatorgraph . . . . . . . . . . . . . . . . . . . . . . . . . . . 70
Abbildung 31: UML-Klassendiagramm für die Implementierung von Optimierungsre-
geln anhand des Operatorbaums. . . . . . . . . . . . . . . . . . . . . . . 74
Abbildung 32: Logische Optimierungsregel: Vereinigung eines SubgraphContainers
verhindern . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75
Abbildung 33: Beispielhafte Optimierung am Operatorbaum mittels Union-Regel . . . . 76
Abbildung 34: Paralleler Join zweier Unteroperatorgraphen mit Ausnutzung von alter-
nativen Schlüsseln . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77
Abbildung 35: Fehlerbeispiel bei der Mehrfachausnutzung von alternativen Schlüsseln . 77
Abbildung 36: Messreihe der Einfügedauer von BSBM-Tripel mit TomP2P . . . . . . . 84
Abbildung 37: sp2b-Messreihe der verschiedenen Verteilungsstrategien mit TomP2P . . 92
Abbildung 38: Testergebnisse des SP2B mit zwei Instanzen pro Rechner . . . . . . . . . 97
Abbildung 39: Auszug der Ergebnisse des SP2B-Test im EndpointNetwork mit 5 bzw.
10 Millionen Tripel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 98
Abbildung 40: Verdeutlichung von nicht optimaler Datenversendung anhand eines Bei-
spiels . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 102
Abbildung 41: Ergebnisse des BSBM-Benchmarks ohne Versendung von Unteropera-
torgraphen und der gesamten Berechnung am Client . . . . . . . . . . . 105
Abbildung 42: Darstellung der Java-Speicherverwaltung über Visual GC, Quelle: Lange
(2011) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 126
113
Tabellen
Tabelle 1: Benchmark-Tools für LuposDate, Quelle: LuposDate Github, https://github
.com/luposdate/luposdate/wiki/List-of-benchmarks . . . . . . . . . . . . . . 15
Tabelle 2: Mögliche Schlüsselkombinationen bei der Verteilungsstrategie mit den je-
weiligen Komponenten als Schlüssel . . . . . . . . . . . . . . . . . . . . . . 34
Tabelle 3: Mögliche Schlüsselkombinationen bei der Verteilungsstrategie mit Schlüs-
selpaaren konkatenierter Komponenten der Länge 2 . . . . . . . . . . . . . . 35
Tabelle 4: Mögliche Schlüsselkombinationen bei der Verteilungsstrategie nach dem
Spread By Value Algorithmus . . . . . . . . . . . . . . . . . . . . . . . . . 36
Tabelle 5: Vergleich verschiedener Verteilungsstrategien aus Kapitel 3.2.1 . . . . . . . 36
Tabelle 6: Mögliche Schlüsselkombinationen bei der Verteilungsstrategie mit einfacher
Partitionierung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40
Tabelle 7: Mögliche Schlüsselkombinationen bei der Verteilungsstrategie mit zweifa-
cher Partitionierung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42
Tabelle 8: Mögliche Schlüsselkombinationen bei der Verteilungsstrategie mit einfacher
Partitionierung ohne Eliminierungen . . . . . . . . . . . . . . . . . . . . . . 44
Tabelle 9: Übersicht der fortgeschrittenen Verteilungsstrategien sowie dessen Schlüs-
selpaare . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48
Tabelle 10: Mögliche Anfragemuster sowie deren deterministische Schlüssel-Auflösung
für ein P2P-Netzwerk bei der einfachen Partitionierung . . . . . . . . . . . . 48
Tabelle 11: Mögliche Schlüsselkombinationen bei der zweifach-hierarchischen Vertei-
lungsstrategie (nicht deterministisch) . . . . . . . . . . . . . . . . . . . . . 48
Tabelle 12: Messreihe der Dauer von RDF-Tripel-Einfügungen in TomP2P unterschied-
licher Blockgröße und Skalierung . . . . . . . . . . . . . . . . . . . . . . . 84
Tabelle 13: Kollisionswahrscheinlichkeiten bei Betrachtung verschiedener Netzwerk-
größen und Partitionsgrößen . . . . . . . . . . . . . . . . . . . . . . . . . . 85
Tabelle 14: Darstellung der nötigen Netzwerkgröße abhängig von der Anzahl der Parti-
tionen mit einer Kollisionswahrscheinlichkeit ≤ 2 % . . . . . . . . . . . . . 86
Tabelle 15: Vergleich lokaler Join vs. externer Join in SP2B im P2P-Netz TomP2P . . . . 89
Tabelle 16: Größe der Ergebnismengen in der sp2b-Messreihe verschiedener Vertei-
lungsstrategien . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 93
Tabelle 17: Dauer der Einfügung der SP2B-Tripel in der TomP2P-Messreihe . . . . . . . 93
Tabelle 18: Ergebnisse des SP2B-Tests im Endpoint basierten Netz . . . . . . . . . . . . 99
Tabelle 19: Ergebnisse des BSBM-Benchmarks ohne Versendung von Unteroperatorgra-
phen und der gesamten Berechnung am Client . . . . . . . . . . . . . . . . 104
Tabelle 20: Übersicht wichtiger Packages und Klassen in der P2P-Komponente . . . . . 129
Tabelle 21: Konsolenparameter für die P2P-Komponente . . . . . . . . . . . . . . . . . 130
114
Quelltexte
Quelltext 1: Beispiel-Code für das Einfügen eines Tripels in ein P2P-Netz durch die
Schlüsselkombination . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
115
Quellen
Literatur
Aberer, K., Cudré-Mauroux, P., Hauswirth, M. & Pelt, T. (2004). GridVine: Building Internet-
Scale Semantic Overlay Networks. In McIlraith, S., Plexousakis, D. & Harmelen, F.
(Hrsg.), The Semantic Web – ISWC 2004, Band 3298 von Lecture Notes in Computer
Science. London: Springer, S. 107–121.
Alexander, K. & Hausenblas, M. (2009). Describing linked datasets - on the design and usage
of void, the ’vocabulary of interlinked datasets. In In Linked Data on the Web Workshop
(LDOW 09), in conjunction with 18th International World Wide Web Conference (WWW
09).
Ali, L. & Lausan, G. (2012). Evaluating SPARQL Subqueries over P2P Overlay Networks.
23rd International Workshop on Database and Expert Systems Applications, 272–276.
Alima, L. O., Ghodsi, A. & Haridi, S. (2004). A Framework for Structured Peer-to-Peer Over-
lay Networks. In In Post-proceedings of the Global Computing Conference, LNCS. Ber-
lin: Springer Verlag, S. 223–250.
Ashton, K. (2009). That Internet of Things Thing. RFID Journal. URL http://www.rfidjourna
l.com/articles/view?4986.
Ball, W. W. R. & Coxeter, H. S. M. (1939). Mathematical recreations and essays. New York,
NY, USA: Macmillan Publishing Company, 11 Auflage.
Baumgärtel, T. (1998). Reisen ohne Karte - wie funktionieren Suchmaschinen?, Band 98-
104. TU Berlin: WZB, Forschungsschwerpunkt Technik, Arbeit, Umwelt. URL http:
//nbn-resolving.de/urn:nbn:de:0168-ssoar-125832.
Becker, K.-B. (2011). Wie die Zensur umgangen wird. In Internetzensur in China. Wiesbaden:
Springer-VS, S. 165–187.
Beckett, D. & Berners-Lee, T. (2008). Turtle - Terse RDF Triple Language, W3C Team Sub-
mission. URL http://www.w3.org/TeamSubmission/turtle/, letzter Aufruf: 21.09.2013.
Berners-Lee, T. (2000). Primer: Getting into RDF & Semantic Web using N3. URL http:
//www.w3.org/2000/10/swap/Primer.html, letzter Aufruf: 12.12.2013.
116
Literatur
Berners-Lee, T. (2006). Notation-3. URL http://www.w3.org/DesignIssues/Notation3, letzter
Aufruf: 19.10.2013.
Berners-Lee, T., Cailliau, R., Groff, J.-F. & Pollermann, B. (1992). World-Wide Web: The
Information Universe. Electronic Networking: Research, Applications and Policy, 1(2),
74–82.
Berners-Lee, T. & Connolly, D. (2008). Notation3 (N3): A readable RDF syntax. Technischer
Bericht, W3C. URL http://www.w3.org/TeamSubmission/n3/.
Berners-Lee, T. & Miller, E. (2002). The Semantic Web lifts off. ERCIM News, 51, 9–11.
Beyer, M. (o.J.). Gartner Says Solving ’Big Data’ Challenge Involves More Than Just Ma-
naging Volumes of Data. URL http://www.gartner.com/newsroom/id/1731916, letzter
Aufruf: 08.10.2013.
Böhringer, J., Bühler, P. & Schlaich, P. (2008). Kompendium der Mediengestaltung - Kon-
zeption und Gestaltung für Digital- und Printmedien. Berlin, Heidelberg: Springer, 5.
Auflage.
Bischof, U. (2005). Strukturierte P2P Netze. Seminar p2p networking, TU Cottbus.
Bizer, C. (2008). The Berlin SPARQL Benchmark. Talk at Lilly, Indianapolis, USA. http:
//www4.wiwiss.fu-berlin.de/bizer/pub/Bizer-Lilly-BSBM-Talk.pdf.
Bizer, C. & Schultz, A. (2009). The berlin sparql benchmark. International Journal On Se-
mantic Web and Information Systems.
Bizer, C. & Schultz, A. (2011). Berlin SPARQL Benchmark (BSBM) - Benchmark Ru-
les. URL http://wifo5-03.informatik.uni-mannheim.de/bizer/berlinsparqlbenchmark/spe
c/BenchmarkRules/index.html#datagenerator, letzter Aufruf: 11.10.2013.
Bocek, T. (2013a). Tom P2P. URL http://www.tomp2p.net/, letzter Aufruf: 15.10.2013.
Bocek, T. (2013b). Tom P2P - FAQ. URL http://www.tomp2p.net/doc/faq/, letzter Aufruf:
15.10.2013.
Broekstra, J., Kampman, A. & Van Harmelen, F. (2002). Sesame: A generic architecture for
storing and querying rdf and rdf schema. In The Semantic Web—ISWC 2002. Berlin:
Springer, S. 54–68.
Cai, M. & Frank, M. R. (2004). RDFPeers: a scalable distributed RDF repository based on
a structured peer-to-peer network. In Feldman, S. I., Uretsky, M., Najork, M. & Wills,
C. E. (Hrsg.), WWW. ACM, S. 650–657.
Cai, M., Frank, M. R., Chen, J. & Szekely, P. A. (2004). MAAN: A Multi-Attribute Addressable
Network for Grid Information Services. J. Grid Comput., 3–14.
Chou, C. et al. (2007). Techniques for Peer-to-peer Content Distribution Over Mobile Ad Hoc
Networks. Cambridge, UK: ProQuest.
117
Literatur
Cikryt, C. (2010). Beyond Music Filesharing: A Technical Introduction to P2P Networks.
Seminararbeit, Freie Universität Berlin.
Cormen, T. H., Leiserson, C. E. & Rivest, R. L. (2001). Introduction To Algorithms. Cam-
bridge: MIT Press, 2. Auflage.
Cruz, I., Xiao, H. & Hsu, F. (2005). Peer-to-Peer Semantic Integration of XML and RDF Data
Sources. In Moro, G., Bergamaschi, S. & Aberer, K. (Hrsg.), Agents and Peer-to-Peer
Computing, Band 3601 von Lecture Notes in Computer Science. Berlin, Heidelberg:
Springer, S. 108–119.
David, M. et al. (2013). Github: Fallstudie2013. URL https://github.com/mariodavid/Fallstud
ie1213, letzter Aufruf: 12.10.2013.
Della Valle, E., Ceri, S., van Harmelen, F. & Fensel, D. (2009). It’s a Streaming World! Rea-
soning upon Rapidly Changing Information. Intelligent Systems, IEEE, 24(6), 83–89.
Ertel, W. (2003). Angewandte Kryptographie. 30 Aufgaben. München: Hanser Fachbuchverlag.
Filali, I., Bongiovanni, F., Huet, F. & Baude, F. (2011). A Survey of Structured P2P Systems
for RDF Data Storage and Retrieval. In Hameurlain, A., KÃng, J. & Wagner, R. (Hrsg.),
Transactions on Large-Scale Data- and Knowledge-Centered Systems III, Band 6790
von Lecture Notes in Computer Science. Heidelberg: Springer, S. 20–55.
Fischer, P. & Hofer, P. (2008). Lexikon der Informatik. Berlin: Springer-Verlag.
Fischer, S., Steinacker, A., Bertram, R. & Steinmetz, R. (1998). Kryptographie und Zertifizie-
rung. In Open Security. Springer Berlin Heidelberg, S. 51–73.
Garcia-Molina, H., Ullman, J. D. & Widom, J. (2002). Database systems: the complete book.
Upper Saddle River, NJ 07458, USA: Prentice-Hall.
Grant, J. & Beckett, D. (2004). RDF Test Cases. http://www.w3.org/TR/2004/REC-rdf-testc
ases-20040210/. Letzter Aufruf: 12.12.2013.
Groppe, J., Groppe, S., Ebers, S. & Linnemann, V. (2009a). Efficient processing of SPARQL
joins in memory by dynamically restricting triple patterns. In Proceedings of the 2009
ACM symposium on Applied Computing, SAC ’09. New York, NY, USA: ACM, S. 1231–
1238.
Groppe, J., Groppe, S., Schleifer, A. & Linnemann, V. (2009b). LuposDate: a semantic web
database system. In Proceedings of the 18th ACM conference on Information and know-
ledge management, CIKM ’09. New York, NY, USA: ACM, S. 2083–2084.
Groppe, S., Groppe, J., Kukulenz, D. & Linnemann, V. (2007a). A SPARQL Engine for Strea-
ming RDF Data. In Signal-Image Technologies and Internet-Based System, 2007. SITIS
’07. Third International IEEE Conference on. S. 167–174.
Groppe, S., Groppe, J. & Linnemann, V. (2007b). Using an Index of Precomputed Joins in
Order to Speed up SPARQL Processing. In ICEIS. Funchal, Madeira, Portugal, S. 13–
20.
118
Literatur
Gruber, T. R. (1993). A translation approach to portable ontology specifications. Knowledge
Acquisition, 5(2), 199–220.
Hartmann, S. (2008). Überwindung semantischer Heterogenität bei multiplen Data-
Warehouse-Systemen. Doktorarbeit, University of Bamberg.
Hauben, M., Hauben, R. & Truscott, T. (1997). Netizens - on the history and impact of Usenet
and the Internet. Los Alamitos, CA, USA: IEEE Computer Society Press.
Hitzler, P., Krötzsch, M., Parsia, B., Patel-Schneider, P. F. & Rudolph, S. (2009). OWL 2 Web
Ontology Language Primer. W3C Recommendation 27 October 2009. http://www.w3.
org/TR/owl2-primer/.
Hitzler, P., Krötzsch, M., Rudolph, S. & Sure, Y. (2007). Semantic Web: Grundlagen. Berlin:
Springer, 2008 Auflage.
Huffman, D. (1952). A Method for the Construction of Minimum-Redundancy Codes. Pro-
ceedings of the IRE, 40(9), 1098–1101.
International Telecommunication Union (1994). Information technology – Open Systems Inter-
connection – Basic Reference Model: The basic model. ITU-T Recommendation X.200.
URL http://www.itu.int/rec/T-REC-X.200-199407-I.
Kaplan, M. (2005). Grundlegende algebraische Strukturen. In Computeralgebra. Heidelberg:
Springer, S. 57–165.
Karger, D., Lehman, E., Leighton, T., Panigrahy, R., Levine, M. & Lewin, D. (1997). Consistent
hashing and random trees: distributed caching protocols for relieving hot spots on the
World Wide Web. In Proceedings of the twenty-ninth annual ACM symposium on Theory
of computing, STOC ’97. New York, NY, USA: ACM, S. 654–663.
Kemper, A. & Eickler, A. (2001). Datenbanksysteme. Eine Einführung. München: Oldenbourg.
Khristianov, N. (2013). Architekturen zur Analyse von strombasierten Daten. Diplomarbeit,
TU Hamburg-Harburg.
Lange, F. (2011). Java Speicher - Konfiguration und Überwachung (Teil 3). URL https://bl
og.codecentric.de/2011/03/java-speicher-konfiguration-und-uberwachung-3-akt/, letz-
ter Aufruf: 22.12.2013.
Liarou, E., Idreos, S. & Koubarakis, M. (2006). Evaluating Conjunctive Triple Pattern Queries
over Large Structured Overlay Networks. In In International Semantic Web Conference,
volume 4273 of Lecture. Berlin: Springer, S. 399–413.
Mahlmann, P. & Schindelhauer, C. (2007). Peer-to-Peer-Netzwerke - Algorithmen und Metho-
den. Berlin: Springer DE, 2007 Auflage.
Maymounkov, P. & Mazières, D. (2002). Kademlia: A Peer-to-Peer Information System Based
on the XOR Metric. In Revised Papers from the First International Workshop on Peer-
to-Peer Systems, IPTPS ’01. London, UK: Springer, S. 53–65.
119
Literatur
Menezes, A. J., Vanstone, S. A. & Oorschot, P. C. V. (1996). Handbook of Applied Cryptogra-
phy. Boca Raton, FL, USA: CRC Press, Inc., 1. Auflage.
Mietz, R., Groppe, S., Oliver Kleine, D. B., Fischer, S., Römer, K. & Pfisterer, D. (2013). A
P2P Semantic Query Framework for the Internet of Things. PIK - Praxis der Informati-
onsverarbeitung und Kommunikation, 36(2), 73–79.
Morsey, M., Lehmann, J., Auer, S. & Ngonga Ngomo, A.-C. (2011). DBpedia SPARQL Bench-
mark – Performance Assessment with Real Queries on Real Data. In Aroyo, L., Welty,
C., Alani, H., Taylor, J., Bernstein, A., Kagal, L., Noy, N. & Blomqvist, E. (Hrsg.), The
Semantic Web – ISWC 2011, Band 7031 von Lecture Notes in Computer Science. Berlin,
Heidelberg: Springer, S. 454–469.
Neumann, T. & Weikum, G. (2008). RDF-3X: A RISC-style Engine for RDF. Proc. VLDB
Endow., 1(1), 647–659.
Neumann, T. & Weikum, G. (2010). The RDF-3X Engine for Scalable Management of RDF
Data. The VLDB Journal, 19(1), 91–113.
Oracle (2010). New I/O APIs. http://docs.oracle.com/javase/1.5.0/docs/guide/nio/index.html.
Letzter Aufruf: 03.11.2013.
Oram, A. (Hrsg.) (2001). Peer-to-Peer: Harnessing the Power of Disruptive Technologies.
Sebastopol, CA, USA: O’Reilly & Associates, Inc.
Ottmann, T. & Widmayer, P. (2012). Algorithmen und Datenstrukturen. Berlin: Springer DE,
5. Auflage.
Ratnasamy, S., Francis, P., Handley, M., Karp, R. & Shenker, S. (2001). A Scalable Content-
addressable Network. SIGCOMM Comput. Commun. Rev., 31(4), 161–172. URL http:
//doi.acm.org/10.1145/964723.383072.
Rhea, S., Geels, D., Roscoe, T. & Kubiatowicz, J. (2004a). Handling churn in a DHT. In
Proceedings of the annual conference on USENIX Annual Technical Conference, ATEC
’04. Berkeley, CA, USA: USENIX Association, S. 10–10.
Rhea, S., Geels, D., Roscoe, T. & Kubiatowicz, J. (2004b). Handling Churn in a DHT. In In
Proceedings of the USENIX Annual Technical Conference.
Royce, W. W. (1987). Managing the development of large software systems: concepts and
techniques. In Proceedings of the 9th international conference on Software Engineering,
ICSE ’87. Los Alamitos, CA, USA: IEEE Computer Society Press, S. 328–338.
Sahnwaldt, C. et al. (2013). The DBPedia Data Set (3.9). URL http://wiki.dbpedia.org/Datase
ts, letzter Aufruf: 18.12.2013.
Scheller, M., Boden, K.-P., Geenen, A. & Kampermann, J. (1994). Internet Werkzeuge und
Dienste: Von Archie"bis World Wide Web"(German Edition). Springer, 1. Auflage.
Schmidt, M., Hornung, T., Lausen, G. & Pinkel, C. (2008). SP2Bench: A SPARQL Performan-
ce Benchmark. Computing Research Repository, abs/0806.4.
120
Literatur
Schwarte, A., Haase, P., Hose, K., Schenkel, R. & Schmidt, M. (2011). FedX: A Federation
Layer for Distributed Query Processing on Linked Open Data. In The Semanic Web: Re-
search and Applications : 8th Extended Semantic Web Conference, ESWC 2011, Lecture
Notes in Computer Science. Berlin: Springer.
Scriven, M. (1991). Evaluation thesaurus. Los Angeles, USA: Sage.
solid IT (2013). DB-Engines Ranking - popularity ranking of RDF stores. http://db-
engines.com/en/ranking/rdf+store. Letzter Aufruf: 02.12.2013.
Stegmaier, F., Gröbner, U., Döller, M., Kosch, H. & Baese, G. (2009). Evaluation of current
RDF database solutions. In Proceedings of the 10th International Workshop on Seman-
tic Multimedia Database Technologies (SeMuDaTe), 4th International Conference on
Semantics And Digital Media Technologies (SAMT).
Stoica, I., Morris, R., Karger, D., Kaashoek, F. & Balakrishnan, H. (2001). Chord: A Scala-
ble Peer-To-Peer Lookup Service for Internet Applications. Computer Communication
Review, 31(4), 149–160.
Stoica, I., Morris, R., Liben-Nowell, D., Karger, D. R., Kaashoek, M. F., Dabek, F. & Balakris-
hnan, H. (2003). Chord: a scalable peer-to-peer lookup protocol for internet applications.
IEEE/ACM Trans. Netw., 11(1), 17–32.
Stuckenschmidt, H., van Harmelen, F., Siberski, W. & Staab, S. (2006). Semantic Web and
Peer-to-Peer. In Staab, S. & Stuckenschmidt, H. (Hrsg.), Semantic Web and Peer-to-
Peer - Decentralized Management and Exchange of Knowledge and Information. Berlin,
Heidelberg: Springer.
Valle, E. D., Turati, A. & Ghioni, A. (2006). PAGE: A Distributed Infrastructure for Fostering
RDF-Based Interoperability. In Eliassen, F. & Montresor, A. (Hrsg.), DAIS, Band 4025
von Lecture Notes in Computer Science. Berlin: Springer, S. 347–353.
Virtuelle Hochschule (2012). Semantic Web. URL http://www.virtuelle-hochschule.de/techn
ik/vernetzung/semanticweb/, letzter Aufruf: 21.10.2013.
Vogelgesang, P. (2003). Häufigkeit von Buchstaben. http://web.archive.org/web/
20060209143823/http://zwilling.dawa.de/sammelsurium/worte/buchhauf.html. Letzter
Aufruf: 02.12.2013.
von Mises, R. (1939). Über Aufteilungs- und Besetzungswahrscheinlichkeiten. Istanbul Üni-
versitesi Fen Fakültesi Mecmuasi, 4, 145–163. Siehe auch Ball & Coxeter (1939).
Wagenknecht, C. & Hielscher, M. (2009). Formale Sprachen, abstrakte Automaten und Compi-
ler: Lehr- und Arbeitsbuch für Grundstudium und Fortbildung (German Edition). Wies-
baden: Vieweg+Teubner Verlag, 2009 Auflage.
Weiser, M. (1991). The Computer for the 21st Century. Scientific American, 265(3), 66–75.
URL http://www.ubiq.com/hypertext/weiser/SciAmDraft3.html.
Yu, C. T. & Meng, W. (1998). Principles of Database Query Processing for Advanced Appli-
cations. San Francisco, CA, USA: Morgan Kaufmann Publishers Inc.
121
Glossar
Authentisierung Verifizierung eines behaupteten Eigenschaft; Zugriff erfolgt meist aufgrund
Kenntnis eines Wissens (Passwort), Verwendung eines Gegenstands (Schlüssel) oder der
Gegenwart der Person selbst (biometrischer Fingerabdruck). Nach der Verifikation wird
dem Authentisierten sein Autorisierungskontext zugeteilt.
Autorisierung Zustimmung/Einräumung von Rechten in einem Kontext; bedarf voriger Au-
thentisierung,
Disjunkt aus der Mengenlehre: ohne gemeinsame Elemente.
Heap-Dump in dt. Speicherabbild, speichert den aktuellen Programmspeicher sowie den Me-
thodenstack in einer Datei, um den Speicherverbrauch eines Programms analysieren zu
können.
Konkatenation aus dem Lat. für Verkettung; in der theoretischen Informatik: eine Verknüp-
fung, bei der mehrere Wörter aneinandergehängt werden.
Linked Open Data Frei für jegliche Zwecke nutbare semantisch vernetzte Ressourcen, oft in
RDF kodiert.
Map-Reduce-Ansatz Diese Methode zerlegt eine Aufgabe in kleinste Teile, die dann verteilt
auf viele Rechnerknoten parallel verarbeitet werden können (mapping). Das Ergebnis
wird anschließend zusammengefasst (recuce).
Overhead zusätzlicher Aufwand, zusätzliche Kosten
Overlay-Netz Rechnernetz, welches auf einem bestehenden Netz, dem so genannten Under-
lay, aufsetzt und eine Teilmenge des Netzes ausmacht.
Peer „gleichgestellter“ (aus engl. peer) Rechner/Knoten eines Peer-To-Peer-Netzes.
Permutation Veränderung der Reihenfolge von Elementen einer Menge.
Publish-Subscribe-Ansatz Lose Kopplung mehrerer Systeme, wobei sich diese gegenseitig
für bestimmte Nachrichten (Objekte) registrieren können. Sollte solche Daten an einem
System anfallen, werden alle Partner, die diese Nachricht abonniert haben, über das neue
Datum informiert.
122
Glossar
Semantik oder Bedeutungslehre, Wissenschaft der Bedeutung der Zeichen.
Single Point of Failure bezeichnet die Gegebenheit, dass ein Ausfall eines Bestandteils eines
technischen Systems den Ausfall des gesamten Systems verursacht.
SPARQL-Engine Anfrageevaluator im Semantic Web, Semantic Web Datenbank.
Topologie bezeichnet in einem Rechnernetz die Struktur der Verbindungen zwischen meh-
reren Geräten für gemeinsamen Datenaustausch; bekannte Topologien: Ring-Topologie,
Stern-Topologie, Bus-Topologie oder Vermaschtes Netz.
Tripel Datenstruktur des semantischen Netzes zum Speichern der drei Komponenten Subjekt,
Prädikat und Objekt.
World Wide Web Consortium (W3C) Gremium zur Standardisierung des WWW
123
Abkürzungen
Abk. . . . . . . . . . . . . . . Abkürzung
API . . . . . . . . . . . . . . . Application programming interface (z.Dt: Programmierschnittstelle)
bel. . . . . . . . . . . . . . . . beliebig/er
bzw. . . . . . . . . . . . . . . beziehungsweise
d.h. . . . . . . . . . . . . . . . das heißt
DHT . . . . . . . . . . . . . . Distributed Hash Table (Verteilte Hashtabelle)
GUI . . . . . . . . . . . . . . Graphical User Interface, dt. Benutzungsschnittstelle
i.A. . . . . . . . . . . . . . . . im Allgemeinen
IoT . . . . . . . . . . . . . . . Internet of Things
JSON . . . . . . . . . . . . . JavaScript Object Notation
o.B.d.A. . . . . . . . . . . . ohne Beschränkung der Allgemeinheit
P2P . . . . . . . . . . . . . . . Peer-to-Peer
s.o. . . . . . . . . . . . . . . . siehe oben
s.u. . . . . . . . . . . . . . . . siehe unten
TTL . . . . . . . . . . . . . . Time To Live
u.a. . . . . . . . . . . . . . . . unter anderem
W3C . . . . . . . . . . . . . . World Wide Web Consortium
WWW . . . . . . . . . . . . World Wide Web
z.B. . . . . . . . . . . . . . . . zum Beispiel
124
Anhänge
A Exkurs: Statistiken zum DBPedia-Dataset
Vor allem während der Evaluierung des Systems anhand der DBPedia-Daten fiel auf, dass von
einer Gleichverteilung der Datensätze auf den Peers nicht ausgegangen werden kann, da einige
RDF-Komponenten häufiger vorkommen als andere. Hauptsächlich bei den einfachen Vertei-
lungsstrategien, wie der OneKeyDistribution, wird somit ein Schlüssel erzeugt, der alle
Tripel mit der häufig vorkommenden Prädikatkomponente an einem Peer im Netz hinterlegt.
Um die 100 häufigsten Prädikate des DBPedia-Datasets herauszufinden, kann die abgebildete
SPARQL-Anfrage dienen:
1 select distinct ?p, count(?p)
2 where {?s ?p ?o} ORDER BY DESC(count(?p))
3 LIMIT 100
Das Ergebnis zeigte, dass das Prädikat „http://www.w3.org/2002/07/owl#sameAs“ 451 Mio.
mal vorhanden war. Auf dem zweiten Platz liegt das Prädikat „http://www.w3.org/1999/02/22-
rdf-syntax-ns#type“ mit 64 Mio. Einträgen. Mit immerhin 53 Mio. Einträgen landet das Prädi-
kat „http://www.w3.org/2000/01/rdf-schema#label“ auf dem dritten Platz. Die Werte basieren
auf einen derzeitig verfügbaren Datensatz von 817 Millionen Einträgen im DBPedia-Endpoint,
der unter http://dbpedia.org/sparql erreichbar ist.
Werden diese Prädikate anhand der verschiedenen Schlüsselkombination der Verteilungsstra-
tegien verteilt, zeigt sich, dass eine Häufung dieser P2P-Schlüssel zu verzeichnen ist, die einer
gleichmäßigen Verteilung auf allen Peers im Wege steht. Zumindest die Verteilungsstrategien
mit der Partitionierung führen zu einer gleichmäßigen Aufteilung der Datenmenge, wobei je-
doch eine entsprechend große Partitionsanzahl gewählt werden muss, um dieses ausreichend
sicherzustellen.
B Exkurs: Java-Heap
Ein Vorteil der Java Virtual Machine ist es, dass sich der Programmierer nicht darum kümmern
muss, den Speicher wieder freizugeben. In anderen Programmiersprachen wie C++ muss für
ein Datum entsprechender Programmspeicher reserviert und anschließend wieder freigegeben
werden, um zu verhindern, dass das Programm abstürzt, da der für dieses Programm zugewie-
125
Glossar
sene Speicher verbraucht ist. In Java übernimmt diese Aufgabe der im Hintergrund arbeitende
sogenannte Garbage Collector, der in bestimmten Abständen prüft, ob ein Speicherbereich
noch benötigt wird und diesen dann wieder freigibt. Dabei darf der vom Betriebssystem zuge-
wiesene Speicher jedoch ebenfalls nicht überstiegen werden. Als Befehlsparameter kann dieser
für Java allokierte Speicher festgelegt werden. Aufgrund des begrenzten Arbeitsspeichers der
Rechner, ist auch dieses Maximum nicht überschreitbar. Wie in Abbildung 42 dargestellt, ver-
waltet Java diesen zugewiesen Speicher selbst. Es unterteilt den Speicher in Tenured (auch
Old genannt), Young (auch New genannt), und Permanent (Perm) (Lange, 2011). In Tenured
sollte möglichst wenig Garbage Collection stattfinden, im Young dagegen sehr viel. Java lässt
deshalb im Young-Bereich öfters die Speicheraufräumung parallel zu der Anwendung laufen,
sodass möglichst schnell nicht mehr gebrauchter Speicher freigegeben werden kann. Die Rela-
tionen zwischen der Größe der drei Speicherbereiche lassen sich per Befehlszeile konfigurieren
und manuell anpassen, wenn die standartmäßig konfigurierten Werte nicht den Anforderungen
genügen.
Abbildung 42: Darstellung der Java-Speicherverwaltung über Visual GC (Lange, 2011)
Zu Programmabbrüchen aufgrund des Speichers kann es bei Java kommen, wenn ein soge-
nannter „OutOfMemoryError“ erzeugt wird. Dies ist nicht damit gleichzusetzen, dass der Pro-
grammspeicher vollkommen belegt ist, sondern dass eine Umstrukturierung der Daten nicht
mehr problemlos möglich ist, wie folgendes Beispiel in Abbildung 42 von Lange (2011) zeigt.
Dort ist der Tenured-Speicher voll, während der Eden-Speicher zu 1/3 gefüllt ist. Der Eden-
Speicher ergibt dabei mit den beiden Survivor-Speichern S0, S1 den gesamten Young-Speicher.
Obwohl in dem Beispiel noch etwa 30MB Speicher frei sind, wird die entsprechende Fehler-
meldung von Java geworfen. Dies liegt daran, dass in der aktuellen Programmschleife des
Java-Prozesses neuer Speicher benötigt wird oder voriger Speicherplatz für eine Datenstruk-
tur vergrößert werden muss. Sollte der Speicher in Eden nicht mehr ausreichend sein, würde
Garbage Collection stattfinden mit dem Ziel den Speicher aufzuräumen. In Old ist jedoch kein
Speicher mehr frei um die Objekte dort hinzuverschieben, was zum besagten Fehler führt.
126
Glossar
Diesen Fehler kann man durch Anpassung der Größenrelationen des Tenureds, Youngs oder
Permanents hinauszögern; ebenso kann der initiale Programmspeicher z.B. mittels des Pro-
grammparameters „-XmX512M“ auf 512MB heraufgesetzt werden.
Fehlerursachen liegen zumeist an den Java eigenen Datenstrukturen wie „List“, „Array“ und
„Map“. Da dessen Füllgröße zur Kompilierzeit nicht feststeht (oder zuvor manuell festgelegt
wurde), wird ein initialer Wert angenommen. So wird für eine neues ArrayList in Java zum
Beispiel eine Liste mit Platz für 10 Datenobjekte reserviert. Wird diese Füllgrenze überschritten
muss diese Liste nun entsprechend vergrößert werden. Dies geschieht intern über die Methode
java.util.Arrays.copyOf(Arrays.java), welche eine neues Liste mit mehr Platz
reserviert und anschließend die alten Daten an diese neue Speicherstelle kopiert. Jenes führt
dazu, dass für dieses Verschieben mehr Speicher benötigt wird als im Optimalfall nötig wäre,
da der alte Speicher ja erneut benutzt werden könnte.
C Realisierte Packages und Klassen
Package / Klasse Beschreibung
lupos.distributed.p2p.distributionstrategy Hier finden sich die fortgeschrittenen Vertei-
lungsstrategien
→AlternativeKeyContainer Modifizierter KeyContainer, der neben den
P2P-Schlüsselinformationen zusätzlich ei-
ne Liste alternativer redundanter Schlüssel
beinhaltet, die in der Optimierung Einsatz
findet.
→NinefoldInsertionDistribution Verteilungsstrategie mit 9 Schlüsselkombi-
nationen
→SimplePartitionDistribution Verteilungsstrategie mit einfacher Parti-
tionierung der letzten Komponente eines
Schlüsselpaares
→TwoPartitionsDistribution Verteilungsstrategie mit zweifacher Partitio-
nierung der letzten beiden Komponente ei-
nes Schlüsselpaares
lupos.distributed.p2p.network P2P-Interfaces und -klassen
→AbstractP2PNetwork Abstrakte Klasse für bel. P2P-Implementa-
tionen
→IP2PMessageListener Listener-Klasse, welche das AbstractP2P-
Network mit dem P2P_SubgraphExecutor
verbindet
→P2PNetworkCreator Instanz, um neue Peers beliebiger P2P-
Implementationen zu starten; einfach para-
metrisierbar
127
Glossar
Package / Klasse Beschreibung
→P2PTripleNetwork Abstrakte Klasse für bel. P2P-Imple-
mentation, die als RDF-Speicher fungieren
lupos.distributed.p2p.network.impl P2P-Implementierungen
→Chordless P2P-System „Chordless“
→ChordlessLocalStorage IStorage, dass nur auf Daten zugreift, die auf
dem jeweiligen Peer lokal vorhanden sind
→EndpointNetworkwork „P2P-Atrappe“, die auf Endpoint-HTTP-
Server aufbaut, jedoch Nachrichtenströme
senden/empfangen kann
→TomP2P P2P-Implementierung „TomP2P“
→TomP2PLocalStorage IStorage, dass nur auf Daten zugreift, die auf
dem jeweiligen Peer lokal vorhanden sind
lupos.distributed.p2p.query Klassen mit unterschiedlichen Konfiguratio-
nen von P2P-System und Verteilungsstrate-
gien für die Nutzung der LuposDate-GUI
lupos.distributed.p2p.query.withsubgraph Klassen mit unterschiedlichen Konfiguratio-
nen von P2P-System und Verteilungsstrate-
gien mit Versendung von Unteroperatorgra-
phen (SubgraphContainer) für die Nutzung
der LuposDate-GUI
lupos.distributed.p2p.rules Regeln für die logische Anfrageoptimierung
→AsynchronSubgraphContainerRule Ersetzung des sequentiellen Abarbeitens
von Unteroperatorgraphen im Operator-
baum durch nicht blockierendes, paralleles
Abarbeiten
→HierachialDistributionRulePackage Regelsammlung, die alle wichtigen Regel in
einer Sammlung bereitstellt, welche die Re-
geln so lange anwendet, bis keine Transfor-
mation mehr vorgenommen wird.
→JoinSGRule Regel, die zwei Unteroperatorgraphen mit
selben Schlüssel in einem Unteroperatorgra-
phen verschmelzt
→MoveFilterToSubgraph Regel, welche Filter in einen versendbaren
Unteroperatorgraphen verschiebt, sodass der
Filter möglichst früh ausgeführt wird
→MultiInputRule Regel, die im Operatorbaum Restbestän-
de von Operatoren löscht, die zwei Daten-
Eingänge benötigen, jedoch nur einen haben
128
Glossar
Package / Klasse Beschreibung
→PartitionSubgraphRule Regel, welche Partitions-Joins mit den
fortgeschrittenen Verteilungsstrategien vor-
nimmt
→UnionRule (Alte) Regel, welche die Vereinigungs-
Operation im Operatorbaum entfernt, wenn
diese nur ein Vorgänger hat (von der Multi-
InputRule überholt)
lupos.distributed.p2p.storage IStorage-Implementationen für P2P
→StorageWithDistributionStrategy IStorage, das mit einem AbtractP2PNetwork
verbunden ist, und die Datenspeicherung
von LuposDate darstellt. Hier finden Einfü-
gungen, Löschungen und Anfragen statt.
→BlockStorageWithDistributionStrategy Wie StorageWithDistributionStrategy, aber
mit der Verbesserung, dass Tripel in Blö-
cken eingefügt werden, was das Einfügen je
nach P2P-System verbessern kann und we-
niger Zeitaufwändig ist.
lupos.distributedendpoints.gui Klassen für die Lupos-GUI
→PeerCreator Hilfsklasse, die das Erstellen eines
Lupos-Evaluators mit beliebiger P2P-
Implementierung und Verteilungsstrategie
und IStorage-Implementation vereinfacht
→Start_Demo_Applet_DE Startklasse, welche die Lupos-GUI startet
Tabelle 20: Übersicht wichtiger Packages und Klassen in der P2P-Komponente
D Übersicht der Parameter für das Konsolenprogramm
Die P2P-Komponente ist über die Konsole startbar. Vor allem bei dem ausführbaren Programm
wird die Hauptklasse des Packages „console“ gestartet, wobei die in Tabelle 21 dargestellten
Parameter genutzt werden können. Alternativ können diese Einstellungen auch in einer Kon-
figurationsdatei vorliegen, die Schlüssel-Werte-Paare der Form „Parameter=Wert“ beinhalten.
Über den Parameter „-cfg Dateiname“ kann dann diese entsprechende Datei eingelesen wer-
den.
129
Glossar
Parameter Beschreibung
-b VAL Die IP-Adresse des Master-Peers
-blockSize N Die Blockgröße, wenn als IStorage einBlock basiertes Einfügen gesetzt ist
-bp N Den Port des Master-Peers
-cfg (-config, -conf) VAL Lädt eine Konfigurationsdatei, die Schlüssel-Werte-Paare der dargestellten Parameter ent-hält
-distrib VAL Der Klassenname der Verteilungsstrategie,die verwendet werden soll
-fs Benutzt, wenn von dem P2P-System unter-stützt, einen Festplatten basierten Speicher
-help (\?, \help, -h) Zeigt eine Übersicht aller Parameter
-log (-logging, -log4j) VAL Setzt die Logging-Einstellung von log4j
-manual Aktiviert die manuelle Koonfiguration überein Konsolenmenü
-network VAL Der Name des zu nutzenden P2P-Systems
Deaktiviert die Versendung von Unter-Operatorgraphen
-p N Der Port, an welchem der aktuelle Knoten ge-startet werden soll
-percentageBuffer N Gibt den Prozentwert des verfügbaren Spei-chers an, den LuposDate für die Ergebnisver-arbeitung nutzen kann, ohne dies auf die Fest-platte auszulagern
-showOperator Zeigt die Operatorgraphen, die versendet wer-den, in der LuposDate-GUI an
-storage VAL Der Klassenname der zu nutzendenIStorage-Implementation
-test VAL Der Klassenname für ein auszuführendesTestpackage, das nach dem Start durchgeführtwird
Tabelle 21: Konsolenparameter für die P2P-Komponente(VAL = Zeichenkette, N = Zahl, Werte in Klammern sind redundante Parameter)
130
Erklärung
Ich versichere an Eides statt, die vorliegende Arbeit selbstständig und nur unter Benutzung der
angegebenen Hilfsmittel angefertigt zu haben.
Lübeck, den 9. Januar 2014
131