AnfrageverarbeitungimsemantischenInternetofThings mit P2P ...Die Idee ist es, semantische...

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.2 Auswertung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 91

5.7 Vergleich der Verteilungsstrategien im Endpoint-Network . . . . . . . . . . . . 96


5.7.2 Auswertung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 98

5.8 Vergleich der Verteilungsstrategien ohne Untergraphanfragen . . . . . . . . . . 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

http://setiathome.berkeley.edu/


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

www.skype.com


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


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


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


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

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


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


Abbildung 6: Funktionsprinzip einer Ontologie anhand des Beispiels eines Museums

12

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


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

http://dbpedia.org/sparql

www.dbpedia.org

http://jena.sourceforge.net/


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

http://www.w3.org/2001/sw/DataAccess/tests/r2


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


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

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

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


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


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


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


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

http://www.openrdf.org/

https://github.com/mariodavid/Fallstudie1213


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

https://github.com/itm/decentsparql

https://github.com/rwglab/p2p-triplestore

http://sourceforge.net/projects/chordless/

https://code.google.com/p/google-guice/

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><O>

wie folgt in die verteilte Hashtabelle insert(key,value)3 und damit ins P2P-Netz ein:

insert(hash(< S >< O >),< S >< 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 < 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 >< O >),< S >< 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><O> zu drei Einfügungen mit den jeweiligen Schlüsseln, bei

der jede Komponente gehasht wird:

insert(hash(< S >),< S >< O >)

insert(hash(),< S >< O >)

insert(hash(< O >),< S >< 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() 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 >< O >) das RDF-Tripel <S><O>

33

3 Konzeption

Anfragemuster mögliche Schlüsselkom-binationen

nachträgliche Ergebnis-überprüfung?

<S><O> S, P, O Ja<?><O> P, O Ja<?><?><O> O Nein<?><?> P Nein<S><?><?> S Nein<S><?> 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><O> SP, PO, SO<?><O> PO<?><?><O> -<?><?> -<S><?><?> -<S><?> 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


<S><O> SPO, SP, PO, SO, S, P, O<?><O> PO, P, O<?><?><O> O<?><?> P<S><?><?> S<S><?> 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


Anz. d. Schlüssel bei nPartitionen

<S><O> SO, PS, PO, OS, OP, SP 1<?><O> PO, OP 1<?><?><O> OP, OS n<?><?> PO, PS n<S><?><?> SO, SP n<S><?> 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


• 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


Anz. d. Schlüssel bei nund m Partitionen

<S><O> SPO, PSO, OPS 1<?><O> OPS bzw. PSO m bzw. n<?><?><O> OPS n∗m<?><?> PSO n∗m<S><?><?> SPO n∗m<S><?> 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>PO0“ und „S<s>PO1“ (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


Anz. d. Schlüssel bei nPartitionen

<S><O> POS, SOP, SPO n<?><O> POS n<?><?><O> OP, OS n<?><?> PS, PO n<S><?><?> SP, SO n<S><?> 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


• 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><O> S<S>P{hash()}

<?><O> PO{hash(<O>)}

<?><?><O> O<O>S{i,∀i ∈ [0,n]}

<?><?> PO{i,∀i ∈ [0,n]}

<S><?><?> S<S>P{i,∀i ∈ [0,n]}

<S><?> S<S>P{hash()}

<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


<S><O> SPO, PSO, OPS

<?><O> PSO, OPS

<?><?><O> OPS

<?><?> PSO

<S><?><?> SPO

<S><?> 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:

PS0O1, PS1O1, PS2O1, PS3O1), 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

http://maven.apache.org/

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

http://www.tomp2p.net

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

http://tomp2p.net/

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

http://www.freepastry.org/FreePastry/

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><O> werden hier die drei KeyContainer8

KeyContainer<String>("S",toString(<S>))

KeyContainer<String>("P",toString())

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())

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

http://www.w3.org/TR/rdf-sparql-query/

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

http://dbis.informatik.uni-freiburg.de/index.php?project=SP2B

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

http://wifo5-03.informatik.uni-mannheim.de/bizer/berlinsparqlbenchmark/

http://wiki.dbpedia.org/UseCases

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



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



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.


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.


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.


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


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.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


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

http://www.ifis.uni-luebeck.de/index.php?L=1&id=luposdate-demo

http://www.ifis.uni-luebeck.de/index.php?L=1&id=luposdate-demo

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

https://github.com/luposdate/luposdate/wiki/List-of-benchmarks

https://github.com/luposdate/luposdate/wiki/List-of-benchmarks

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

http://www.rfidjournal.com/articles/view?4986

http://www.rfidjournal.com/articles/view?4986

http://nbn-resolving.de/urn:nbn:de:0168-ssoar-125832

http://nbn-resolving.de/urn:nbn:de:0168-ssoar-125832

http://www.w3.org/TeamSubmission/turtle/

http://www.w3.org/2000/10/swap/Primer.html

http://www.w3.org/2000/10/swap/Primer.html

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

http://www.w3.org/DesignIssues/Notation3

http://www.w3.org/TeamSubmission/n3/

http://www.gartner.com/newsroom/id/1731916

http://www4.wiwiss.fu-berlin.de/bizer/pub/Bizer-Lilly-BSBM-Talk.pdf

http://www4.wiwiss.fu-berlin.de/bizer/pub/Bizer-Lilly-BSBM-Talk.pdf

http://wifo5-03.informatik.uni-mannheim.de/bizer/berlinsparqlbenchmark/spec/BenchmarkRules/index.html#datagenerator

http://wifo5-03.informatik.uni-mannheim.de/bizer/berlinsparqlbenchmark/spec/BenchmarkRules/index.html#datagenerator

http://www.tomp2p.net/

http://www.tomp2p.net/doc/faq/

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:


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



http://www.w3.org/TR/2004/REC-rdf-testcases-20040210/

http://www.w3.org/TR/2004/REC-rdf-testcases-20040210/

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:


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

http://www.w3.org/TR/owl2-primer/

http://www.w3.org/TR/owl2-primer/

http://www.itu.int/rec/T-REC-X.200-199407-I

https://blog.codecentric.de/2011/03/java-speicher-konfiguration-und-uberwachung-3-akt/

https://blog.codecentric.de/2011/03/java-speicher-konfiguration-und-uberwachung-3-akt/

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

http://docs.oracle.com/javase/1.5.0/docs/guide/nio/index.html

http://doi.acm.org/10.1145/964723.383072

http://doi.acm.org/10.1145/964723.383072

http://wiki.dbpedia.org/Datasets

http://wiki.dbpedia.org/Datasets

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

http://www.virtuelle-hochschule.de/technik/vernetzung/semanticweb/

http://www.virtuelle-hochschule.de/technik/vernetzung/semanticweb/

http://web.archive.org/web/20060209143823/http://zwilling.dawa.de/sammelsurium/worte/buchhauf.html

http://web.archive.org/web/20060209143823/http://zwilling.dawa.de/sammelsurium/worte/buchhauf.html

http://www.ubiq.com/hypertext/weiser/SciAmDraft3.html

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

http://dbpedia.org/sparql

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


→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


→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

AnfrageverarbeitungimsemantischenInternetofThings mit P2P ...Die Idee ist es, semantische...

Documents

Transcript of AnfrageverarbeitungimsemantischenInternetofThings mit P2P ...Die Idee ist es, semantische...