Performanceoptimierung der Datenanalyse in Netzwerkgraphen durch

Performanceoptimierung der
Datenanalyse in Netzwerkgraphen
durch Verwendung von User Defined
Functions in einem
Datenbankmanagementsystem
Diplomarbeit
im Fachgebiet Informatik
vorgelegt von: Andreas Redmer
Studienbereich: Datenbanken und Informationssysteme
Matrikelnummer: 5206419
Erstgutachter: Prof. Clemens Cap
Zweitgutachter: Dr. Holger Meyer
Betreuer: Dr. Thomas Mundt

Zusammenfassung
In Link-State Rechnernetzen ist es üblich, dass jeder Knoten die Topologie des
gesamten Netzwerkes kennt und auf dessen Basis die Routing-Entscheidungen
treffen kann. Um die Performance und Qualität des Netzwerks zu erhöhen ist
meist eine Datenanalyse notwendig. Dabei werden beispielsweise Knoten und
Verbindungen gefunden, die eine hohe Wichtigkeit für das gesamte Netzwerk
haben. Durch die regelmäßige Aufzeichnung der Topologieinformationen an
einer Stelle im Netzwerk kann ein Datenbestand geschaffen werden, der bei
geeigneter Analyse Rückschlüsse auf Schwachstellen im Netzwerk geben kann.
Aufgrund der großen Menge an Daten kann die Datenanalyse sehr viel Zeit in
Anspruch nehmen, was die Nützlichkeit ihrer Ergebnisse in Frage stellen kann.
Deshalb wurde in einer Publikation von Mundt und Vetterick [22] im Juli 2011
die Rechenleistung mittels Cloud Computing verstärkt und der Zeitaufwand
somit verringert. Leider hatte diese Methode auch Nachteile, wie beispielsweise
den teuren Upload der großen Datenmengen in die Cloud.
In dieser Arbeit wurde für den selben Datenbestand die Performance erhöht,
indem User Defined Functions (UDF) in einem Datenbankmanagementsystem
eingesetzt wurden. Die Daten werden direkt auf dem Datenbankserver analysiert
und die Ergebnisse mit SQL abgefragt. Gleichzeitig wurde die bestehende
Implementierung untersucht und ihre Komplexität verringert. Im Ergebnis
konnte die Analyse nicht nur schneller, sondern auch komfortabler für den Anwender
durchgeführt werden. Viele Arten der Datenanalyse der Netzwerktopologiedaten
können nun mit SQL ohne zusätzliche Programme durchgeführt
werden. Am Ende der Arbeit werden mehrere Beispiele für Datenanfragen aufgeführt,
die den Einsatz der neuen Funktionen zeigen und Hinweise zur Laufzeit
geben.
© Andreas Redmer — 29. September 2011

Abstract
In link-state computer networks it is usual that every node knows the topology
of the entire network and can make the routing decisions based on that. To
enhance the performance and quality of the network a data analysis is needed
mostly. For instance nodes and connections with a high importance for the
network can be found by doing that. By capturing and recording the topology
information periodically a database can be created, which can be used to draw
conclusions on weaknesses in the network after adequate data analysis. Due to
the huge amount of data, the data analysis can take a lot of time, which can
be questioning the utility of the results. Because of that Mundt and Vetterick
presented a paper ([22]) in July 2011, which introduced a possibility to increase
the processing power and reduce the processing time by cloud computing.
Unfortunately this method had some disadvantages like the expensive upload
of the data into the cloud.
In this diploma thesis the performance has been increased by using user
defined functions (UDF) in a database management system on the same data
source. So the data is directly analyzed on the database server and the results
are queryable by SQL. Additionally the existing implementation was analyzed
and the time complexity was reduced. As a result, the analysis is not only
faster but also more comfortable. Different kinds of data analysis of netzwork
topology data can now be accomplished with SQL and without additional
programs. At the end of diploma this thesis several examples of queries are
introduced, to show the range of application and to indicate the runtime.
© Andreas Redmer — 29. September 2011

Inhaltsverzeichnis
Inhaltsverzeichnis
Abbildungsverzeichnis
Tabellenverzeichnis
Verzeichnis der Listings
III
IV
V
1. Einleitung 1
1.1. Aufbau der Arbeit . . . . . . . . . . . . . . . . . . . . . . . . . 1
1.2. Beschreibung des Mesh-Netzwerks als Graph . . . . . . . . . . . 2
1.3. Qualität der zu analysierenden Daten . . . . . . . . . . . . . . . 3
1.4. Ziel der Arbeit . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
1.5. Vorausgesetzte Hard- und Software . . . . . . . . . . . . . . . . 10
2. Stand der Technik 12
2.1. Routing-Algorithmen . . . . . . . . . . . . . . . . . . . . . . . . 12
2.2. Metriken . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
2.3. Betrachtung der bestehenden Implementierung als Cloud-Service 14
2.3.1. Algorithmische Komplexität . . . . . . . . . . . . . . . . 15
2.3.2. Vor- und Nachteile der Cloudlösung . . . . . . . . . . . . 19
3. Vorbetrachtungen einer hochperformanten Lösung 21
3.1. Wahl des DBMS und der Programmiersprache . . . . . . . . . . 21
3.1.1. Wahl des Datenbankmodells . . . . . . . . . . . . . . . . 21
3.1.2. Wahl des DBMS . . . . . . . . . . . . . . . . . . . . . . 26
3.1.3. Wahl der Programmiersprache . . . . . . . . . . . . . . . 28
3.2. Schnittstellendefinition . . . . . . . . . . . . . . . . . . . . . . . 32
3.3. Möglichkeiten der Performancemessung . . . . . . . . . . . . . . 36
4. Optimierungen in der Implementierung 40
4.1. Algorithmische Optimierungen . . . . . . . . . . . . . . . . . . . 40
4.1.1. Optimierung des Dijkstra-Algorithmus . . . . . . . . . . 40
4.1.2. Optimierung des Graphen . . . . . . . . . . . . . . . . . 42
4.1.3. Die General-Gateway-Strategie“ . . . . . . . . . . . . . 43
”
4.1.4. Nutzung stabiler Teilergebnisse bei ähnlichen Graphen . 46
© Andreas Redmer — 29. September 2011 I

Inhaltsverzeichnis
4.2. Performanceoptimierter Programmierstil . . . . . . . . . . . . . 51
4.2.1. Quellcodedesign . . . . . . . . . . . . . . . . . . . . . . . 51
4.2.2. Zusammenhang zur algorithmischen Komplexität . . . . 53
4.2.3. Design Pattern . . . . . . . . . . . . . . . . . . . . . . . 54
4.2.4. Implementierung von unendlich“ . . . . . . . . . . . . . 55
”
4.2.5. Adjazenzmatrix statt Adjazenzliste . . . . . . . . . . . . 56
4.3. Parallelisierung . . . . . . . . . . . . . . . . . . . . . . . . . . . 57
4.3.1. Multithreaded Dijkstra . . . . . . . . . . . . . . . . . . . 57
4.3.2. Dijkstra auf der GPU . . . . . . . . . . . . . . . . . . . . 63
4.4. Zusammenfassung und Ergebnisse . . . . . . . . . . . . . . . . . 65
5. Testläufe - Beispiele für Datenabfragen 68
5.1. Alle Routen zu allen Zeitpunkten . . . . . . . . . . . . . . . . . 70
5.2. Routenänderungen zwischen zwei Zeitpunkten . . . . . . . . . . 71
5.3. Routenänderungen bei Ausfall eines Knotens . . . . . . . . . . . 73
5.4. Routenänderungen bei Ausfall zweier Knoten . . . . . . . . . . 76
5.5. Knoten die häufig auf Routen liegen . . . . . . . . . . . . . . . . 79
5.6. Wichtige Knoten und Kanten . . . . . . . . . . . . . . . . . . . 82
5.7. Routenänderungen bei Ausfall einer Kante . . . . . . . . . . . . 84
5.8. Suche nach Flaschenhälsen . . . . . . . . . . . . . . . . . . . . . 87
6. Zusammenfassung und Ausblick 90
6.1. Zusammenfassung . . . . . . . . . . . . . . . . . . . . . . . . . . 90
6.2. Ausblick . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 91
Literaturverzeichnis 94
A. Anhang: SQL Anfragen i
A.1. Anzahl neuer Datensätze pro Minute . . . . . . . . . . . . . . . i
A.2. Prüfung der Vollständigkeit der Daten . . . . . . . . . . . . . . ii
A.3. Prüfung der Korrektheit der Daten . . . . . . . . . . . . . . . . iv
A.4. Maximale Knotenanzahl auf kürzesten Pfaden . . . . . . . . . . v
A.5. Floyd-Warshall-Berechnung in SQL . . . . . . . . . . . . . . . . vii
A.6. Floyd-Warshall-Berechnung mit PL/Python . . . . . . . . . . . viii
A.7. Test der General-Gateway-Strategie . . . . . . . . . . . . . . . . ix
A.8. Implementierung der Algebra aus Abschnitt 4.1.4 . . . . . . . . x
B. Anhang: Suche nach einer Partitionierung xi
© Andreas Redmer — 29. September 2011 II

Abbildungsverzeichnis
Abbildungsverzeichnis
3.1. Objektorientierte Speicherung der Daten (UML-Klassendiagramm) 23
3.2. Integration einer Java UDF in PostgreSQL . . . . . . . . . . . . 32
3.3. Ablauf der shortestPaths Funktion . . . . . . . . . . . . . . . 33
3.4. Interface für shortestPaths PL/Java (UML-Klassendiagramm) 36
4.1. Ein beispielhafter unmodifizierter Graph . . . . . . . . . . . . . 43
4.2. Ein Netzwerkgraph mit generalisiertem Gateway . . . . . . . . . 44
4.3. Venn-Diagramm für zwei Dijkstra-Ergebnismengen . . . . . . . 47
4.4. Schematische Darstellung - eine vollständige Speicherung alle 10
Minuten . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49
4.5. Schematische Darstellung - eine vollständige Speicherung pro
Minute im Wochentag . . . . . . . . . . . . . . . . . . . . . . . 50
4.6. Balkendiagramm der Ausführungszeit der UDF shortestPaths 65
4.7. Reihenfolge der durchgeführten Optimierungen . . . . . . . . . . 66
5.1. ER-Modell der verwendeten Datenbank . . . . . . . . . . . . . . 68
5.2. Graph der Kanten aus Tabelle 5.4 . . . . . . . . . . . . . . . . . 83
5.3. Graph aller Kanten aus Tabelle 5.5 . . . . . . . . . . . . . . . . 86
A.1. Ein kartesisches Einheitsgitter . . . . . . . . . . . . . . . . . . .
vi
B.1. Beispielgraph: Alle kürzesten Wege in die Menge der Backbones xii
B.2. Beispielgraph: Alle kürzesten Wege zu den Gateways ohne Beachtung
der Partitionen . . . . . . . . . . . . . . . . . . . . . . xiii
B.3. Beispielgraph: Alle kürzesten Wege zu den Gateways unter Beachtung
der Partitionen . . . . . . . . . . . . . . . . . . . . . . xiv
B.4. Optimale Partitionen am 14.09.2010 um 14 Uhr . . . . . . . . . xvi
© Andreas Redmer — 29. September 2011 III

Tabellenverzeichnis
Tabellenverzeichnis
1.1. Format der aufgezeichneten Daten . . . . . . . . . . . . . . . . . 3
1.2. Allgemeine Übersicht über die betrachteten Daten . . . . . . . . 4
1.3. Constraints für Vollständigkeit . . . . . . . . . . . . . . . . . . . 5
1.4. Constraints für Exaktheit . . . . . . . . . . . . . . . . . . . . . 6
1.5. Zusammenfassung der Problemklassen . . . . . . . . . . . . . . 10
1.6. Spezifikation der Testsysteme . . . . . . . . . . . . . . . . . . . 11
3.1. Laufzeiten des Floyd-Warshall-Algorithmus . . . . . . . . . . . . 29
4.1. Ausführungszeiten bei gleichzeitiger Ausführung mehrerer Dijkstra
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63
4.2. Ausführungszeiten und Verbesserungen der Optimierungen . . . 67
5.1. Erste Ergebnisse der SQL-Abfrage in Listing 5.3 . . . . . . . . . 74
5.2. Die Ergebnisse der SQL-Abfrage in Listing 5.4 . . . . . . . . . . 77
5.3. Die Ergebnisse der SQL-Abfrage in Listing 5.5 . . . . . . . . . . 80
5.4. Die Ergebnisse der SQL-Abfragen in Listing 5.6 . . . . . . . . . 82
5.5. Das Ergebnis der SQL-Abfrage in Listing 5.7 . . . . . . . . . . . 85
5.6. Das Ergebnis der SQL-Abfrage in Listing 5.8 . . . . . . . . . . . 88
© Andreas Redmer — 29. September 2011 IV

Verzeichnis der Listings
Verzeichnis der Listings
2.1. Pseudocode des Algorithmus aus [22] . . . . . . . . . . . . . . . 16
2.2. Dijkstra-Algorithmus in Pseudocode . . . . . . . . . . . . . . . . 18
2.3. Komplexität des Dijkstra-Algorithmus . . . . . . . . . . . . . . 18
2.4. init-Funktion des Dijkstra-Algorithmus . . . . . . . . . . . . . 18
2.5. update-Funktion des Dijkstra-Algorithmus . . . . . . . . . . . . 18
3.1. Typendefinitionen in PostreSQL . . . . . . . . . . . . . . . . . . 24
3.2. JDBC-Verbindung zu einem MySQL-Server in Java . . . . . . . 27
3.3. JDBC-Verbindung zu einem PostgreSQL-Server in Java . . . . . 27
3.4. Floyd-Warshall-Algorithmus in Pseudocode . . . . . . . . . . . . 29
3.5. Zeitmessung für ein Java-Programm . . . . . . . . . . . . . . . . 39
4.1. Dijkstra-Algorithmus in Pseudocode mit Möglichkeiten zur Parallelisierung
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57
4.2. Zwei Anfragen die getrennt gesendet werden können . . . . . . . 60
4.3. shortestPaths Singlethread Pseudocode . . . . . . . . . . . . . . 61
4.4. shortestPaths Doublethread Pseudocode . . . . . . . . . . . . . 61
4.5. Ablauf des CUDA-Programmes in Pseudocode . . . . . . . . . . 64
5.1. Abfrage aller Routen . . . . . . . . . . . . . . . . . . . . . . . . 70
5.2. Abfrage aller Routenänderungen an einem Tag . . . . . . . . . . 71
5.3. Abfrage der Routenänderungen beim Ausfall eines Knotens . . . 73
5.4. Abfrage der Routenänderungen beim Ausfall zweier Knoten . . 76
5.5. Abfrage wie oft ein Knoten auf einer Route liegt . . . . . . . . . 79
5.6. Abfragen für Wichtigkeit von Knoten und Kanten . . . . . . . . 82
5.7. Abfrage nach Routenänderungen durch Wegfall einer Kante . . 84
5.8. Abfrage der Kanten die häufig auf der Route eines Knotens liegen 87
A.1. Abfrage der Anzahl neuer Datensätze pro Minute . . . . . . . . i
A.2. Abfrage der Vollständigkeit der Daten . . . . . . . . . . . . . . ii
A.3. Abfrage der Lücken in der Datenaufzeichnung . . . . . . . . . . iii
A.4. Abfrage der Exaktheit der Daten . . . . . . . . . . . . . . . . . iv
A.5. Abfrage der Durchschnittlichen und maximalen Pfadlänge der
kürzesten Pfade . . . . . . . . . . . . . . . . . . . . . . . . . . . v
© Andreas Redmer — 29. September 2011 V

Verzeichnis der Listings
A.6. Floyd-Warshall Berechnung in SQL . . . . . . . . . . . . . . . . vii
A.7. Floyd-Warshall Berechnung mit PL/Python . . . . . . . . . . . viii
A.8. Anzahl Unterschiede zwischen herkömmlicher und General Gateway
Strategie . . . . . . . . . . . . . . . . . . . . . . . . . . . ix
A.9. Die Algebra aus Abschnitt 4.1.4 in PL/pgSQL . . . . . . . . . . x
© Andreas Redmer — 29. September 2011 VI

1. Einleitung
1. Einleitung
Das Rostocker Opennet [24] ist ein komplexes Wifi-Mesh-Netzwerk mit zur
Zeit etwa 200 Knoten und mehreren Gateways ins Internet. Die Mitglieder
des Opennet e.V. verwenden WLAN-Technik um sich von Dach zu Dach zu
vernetzen. Die Topologieinformationen des Netzwerks sind in allen Knoten vorhanden.
An einer zentralen Stelle im Netzwerk werden die Topology Control
Nachrichten einmal pro Minute aufgezeichnet. Diese Aufzeichnungen sind für
die Funktion des Netzwerkes nicht notwendig, sondern nur für nachträgliche
Analysen. Anhand dieser Daten lassen sich die Routen, die zu einem bestimmten
Zeitpunkt gültig waren, berechnen. Diese wiederum können für verschiedene
Arten der Netzwerkanalyse genutzt werden. Derzeit dauert die Berechnung
der Routen für einen Zeitpunkt ca. vier Sekunden. Bei der Analyse von mehreren
Wochen oder Monaten aufgezeichneter Daten wird der Zeitaufwand sehr
hoch. Deshalb wurde in einer Publikation von Mundt und Vetterick [22] die
Rechenleistung mittels Cloud Computing verstärkt und der Zeitaufwand somit
verringert. Dieser Ansatz hat jedoch auch einige Nachteile. Im Rahmen dieser
Arbeit soll versucht werden die Performance zu erhöhen indem User Defined
Functions (UDF) in einem Datenbankmanagementsystem (DBMS)
eingesetzt werden. Die Routen sollen direkt auf dem Datenbankserver berechnet
und später mittels SQL direkt abgefragt werden. Weiterhin werden im
Rahmen dieser Arbeit die vorhandenen Quelltexte untersucht und eventuelle
Schwachstellen in der Performance beseitigt.
1.1. Aufbau der Arbeit
Im ersten Kapitel dieser Arbeit werden die graphentheoretischen Grundlagen
für das Mesh-Netzwerk erklärt. Diese sind notwendig um zu verstehen wie die
Datenanalyse funktioniert. Weiterhin wird die Herkunft, der Aufbau und die
Qualität der zu analysierenden Daten beschrieben. Ebenfalls wird das Ziel der
Arbeit genau beschrieben und die zu lösenden Probleme (und Problemklassen)
erklärt.
Im Kapitel 2 werden bestehende Routingalgorithmen und dazu gehörige Metriken
beschrieben. Weiterhin wird die bestehende Implementierung für die
© Andreas Redmer — 29. September 2011 1

1. Einleitung
Datenanalyse in der Cloud genauer betrachtet. Dabei wird eine Komplexitätsbetrachtung
durchgeführt. Anschließend werden die Vor- und Nachteile der
bestehenden Lösung erörtert.
Im Kapitel 3 wird das, im Rahmen dieser Arbeit erstellte, Konzept zur Beschleunigung
der Datenanalyse erklärt. Dabei werden auch viele Alternativen
erwähnt und es wird erklärt warum genau der gewählte Lösungsweg eingeschlagen
wurde. Insbesondere befindet sich in diesem Kapitel auch die Definition
der Schnittstelle, die vor der Implementierung spezifiziert wurde. Diese kann
als Dokumentation für die Nutzung der erstellen UDF verwendet werden. Weiterhin
werden einige Konzepte zur Zeitmessung erklärt, um verständlich zu
machen, wie die Erhöhung der Performance überhaupt gemessen werden kann.
Das entstandene Konzept lässt sich auf verschiedene Arten implementieren.
Im Kapitel 4 wird erklärt, wie die Implementierung angefertigt wurde um die
Performance zu erhöhen und dabei die Usability möglichst nicht zu verringern.
In diesem Kapitel wird das Wort ”
Optimierung“ als Synonym für ”
Verbesserung
der Performance“ oder ”
Verringerung der Laufzeit“ verwendet werden. Es
werden sehr verschiedene Arten der Optimierung aufgeführt.
Die letzten beiden Kapitel beschreiben beispielhaft die Verwendung der entwickelten
UDF und vermitteln eine Vorstellung über die zukünftigen Einsatzmöglichkeiten.
Dabei werden auch erste interessante Ergebnisse kleinerer Datenanalysen
präsentiert. Abschließend wird beschrieben, welche Vor- und Nachteile
sich aus dieser Arbeit ergeben, welche Verbesserungen geschafft wurden
und welche weiteren Anwendungen darauf basierend möglich sind.
1.2. Beschreibung des Mesh-Netzwerks als Graph
Im Rahmen dieser Arbeit wird das Mesh-Netzwerk als mathematischer Graph
betrachtet. Ein Graph (G) besteht aus einer Menge von Knoten (V ) und einer
Menge von Kanten (E). Die Kanten sind in dieser Arbeit gerichtete Kanten
und somit mathematische Tupel der Form
(a, b) ∈ E : a ∈ V ∧ b ∈ V.
Für die bessere Lesbarkeit sollen im Rahmen dieser Arbeit für die Anzahl
der Kanten und Knoten folgende Substitutionen gelten:
|V | = n
|E| = m
© Andreas Redmer — 29. September 2011 2

1. Einleitung
In diesem Fall sind die Netzwerkknoten die Knoten des Graphs. Die direkten
WLAN-Verbindungen zwischen ihnen sind die Kanten. Für das Routing
müssen die Kanten gewichtet sein. Für das Gewicht der Kanten wird eine Metrik
verwendet, welche die Qualität der Verbindung beschreibt. Dabei ist zu
beachten, dass ein Qualitätsmaß aus mathematischer Sicht eine Ähnlichkeitsfunktion
ist, bei der ein hoher Wert für gute Qualität und ein niedriger Wert
für schlechte Qualität steht. Die in dieser Arbeit betrachteten Daten haben als
höchsten Wert für die Qualität 1 und als niedrigsten Wert 0. Dabei bedeutet 0,
dass praktisch keine Verbindung vorhanden ist. Da beim Routing die kürzesten
Wege gesucht werden, muss diese Funktion in eine Abstandsfunktion (Metrik)
abgeändert werden. Wenn f(x) die Ähnlichkeitsfunktion ist, dann wären 1
f(x)
oder 1 − f(x) mögliche Abstandsfunktionen. Dadurch ist sichergestellt, dass
die Verbindungen mit der höchsten Qualität als kleine“ Kanten dargestellt
”
werden. Die Berechnung des kürzesten Weges in dem Graphen ist somit gleich
der Ermittlung der besten“ Route.
”
1.3. Qualität der zu analysierenden Daten
Wie bei Link-State-Verfahren üblich sind die Topologieinformationen über das
Netzwerk in allen Knoten vorhanden. An einer zentralen Stelle im Netzwerk
werden die von OLSR 1 definierten und regelmäßig von allen Knoten versendeten
TC (Topology Control) Nachrichten einmal pro Minute aufgezeichnet. Die
Tabelle 1.1 zeigt einige Beispieldatensätze aus der Aufzeichnung.
Timestamp Node A Node B LQ NLQ
2010-09-10 00:00:02 192.168.0.244 192.168.1.150 1.000 1.000
2010-09-10 00:00:02 192.168.0.254 192.168.1.129 1.000 1.000
2010-09-10 00:00:02 192.168.0.254 192.168.1.14 0.349 0.957
2010-09-10 00:00:02 192.168.0.254 192.168.1.15 0.588 1.000
2010-09-10 00:00:02 192.168.0.254 192.168.1.182 1.000 1.000
2010-09-10 00:00:02 192.168.0.254 192.168.1.25 0.643 1.000
2010-09-10 00:00:02 192.168.0.254 192.168.1.4 0.671 1.000
2010-09-10 00:00:02 192.168.0.254 192.168.10.2 1.000 1.000
2010-09-10 00:00:02 192.168.0.254 192.168.2.7 1.000 0.976
2010-09-10 00:00:02 192.168.0.254 192.168.2.8 1.000 0.000
Tabelle 1.1.: Format der aufgezeichneten Daten
Jeder Datensatz besteht aus einem Timestamp, Knoten A, Knoten B, Link
Quality und Neighbour Link Quality. Die Aufzeichnungen beginnen mit dem
1 Optimized Link State Routing [6] (das im Opennet eingesetzte Routingprotokoll)
© Andreas Redmer — 29. September 2011 3

1. Einleitung
Timestamp 07.04.2010 14:20:02 Uhr. Im Rahmen dieser Arbeit, werden nur
Aufzeichnungen bis zum Timestamp 28.03.2011 17:41:02 Uhr betrachtet um
genaue Angaben über Umfang, Zeitaufwände und Geschwindigkeiten machen
zu können. Pro Minute fallen durchschnittlich 852 neue Datensätze an 2 . Jeder
Datensatz repräsentiert eine Verbindung im Netzwerk. Jeder Timestamp
besteht aus Datum und Uhrzeit (ohne Zeitzone), wobei die Systemzeit des aufzeichnenden
Knotens verwendet wird. Knoten A und Knoten B enthalten die
Bezeichner für die beiden Knoten der Verbindung. Bezeichnet werden die Knoten
in Form ihrer IP-Adresse in dezimaler Schreibweise. Link Quality (LQ) ist
ein Qualitätsmaß für die Verbindung von Knoten A nach Knoten B. Da dieses
Qualitätsmaß asynchron ermittelt wird, gibt es noch die Neighbour Link
Quality (NLQ), welche die Übertragungsqualität von Knoten B zu Knoten A
repräsentiert. Die Qualitätswerte sind hier Fließkommawerte im Intervall [0, 1]
mit einer Genauigkeit von vier Dezimalstellen. Dabei steht die 0 für ”
keine
Verbindung“ und die 1 für ”
sehr gute Verbindung“. Näheres zur Bestimmung
dieses Qualitätsmaßes findet sich im Abschnitt 2.2. Die Qualität der Daten ist
bezüglich der Vollständigkeit und Exaktheit jedoch unvollkommen, was für die
weitere Auswertung beachtet werden muss.
Um eine Vorstellung von den Daten zu bekommen, zeigt die Tabelle 1.2 eine
allgemeine Übersicht über die betrachteten Daten.
Erster Timestamp 2010-04-07 14:20:02
Letzter Timestamp 2011-03-28 17:41:02
Anzahl verschiedener Timestamps 334960
Anzahl verschiedener Knoten (IP Adressen) 260
Anzahl Datensätze 278884776
Dateigröße als CSV Export (String) 15,3 GB
Tabellengröße in PostgreSQL Tabelle 16,0 GB
Tabelle 1.2.: Allgemeine Übersicht über die betrachteten Daten
Vollständigkeit
Bevor mit den Daten gearbeitet wird, soll deren Vollständigkeit geprüft werden.
Unvollständigkeiten in den Daten könnten später zu falschen Ergebnissen
führen, wenn sie nicht beachtet werden. Die Tabelle 1.3 listet einige beispielhafte
Constraints auf, die theoretisch alle vollständig erfüllt sein sollten. Inwiefern
2 Durchschnittliche Anzahl der Datensätze pro Timestamp aus den letzten 3 Wochen der
Aufzeichnung (vgl. Anhang A.1).
© Andreas Redmer — 29. September 2011 4

1. Einleitung
sie tatsächlich erfüllt wurden, listet die Spalte ”
erfüllt“ auf. Die dafür verwendeten
SQL-Anfragen und deren Ergebnisse finden sich im Anhang A.2.
Constraint Fälle korrekte Fälle erfüllt
44 ≤ Einträge < 1600 334960 334829 99,96%
Timestamp
Timestamps
Stunde
= 60 5586 5570 99,71%
Timestamps
Tag
= 1440 235 223 94,89%
Timestamps
Woche
= 10080 35 25 71,43%
Tabelle 1.3.: Constraints für Vollständigkeit
Das Contraint in Zeile 1 in Tabelle 1.3 prüft ob die Anzahl der minütlich
aufgezeichneten Daten in einem sinnvollen Rahmen liegt. Es ist sehr schwierig
festzustellen, die Aufzeichnung zu einem Zeitpunkt abgebrochen ist oder
tatsächlich nur sehr wenige Einträge enthält. Einfache statistische Mittel wie
z. B. das Suchen von Ausreißern durch Rangbildung, führten nicht zum Erfolg.
Es ist also eine komplexere Analyse notwendig. An dieser Stelle wurde
letztlich empirisch ermittelt, dass alle Aufzeichnungen, die weniger als 44 Datensätze
beinhalten definitiv falsch sind. Weiterhin wurde festgestellt, dass am
31.10.2010 zwischen 2 Uhr und 3 Uhr mehr als 1600 Datensätze pro Minute
aufgezeichnet wurden, während es normalerweise nie mehr als 1000 Datensätze
waren. Dies geschah aufgrund der Umstellung von Sommerzeit auf Winterzeit.
In den weiteren Zeilen der Tabelle 1.3 wird die Vollständigkeit nach Stunden,
Tagen und Wochen gruppiert 3 . Es sind fast alle aufgezeichneten Stunden
vollständig. Weiterhin sind ca. 95% der aufgezeichneten Tage vollständig
aufgezeichnet. Jedoch sind nur 25 von insgesamt 35 aufgezeichneten Wochen
vollständig.
Unabhängig von unvollständig aufgezeichneten Zeitpunkten gibt es auch
zwischen den Zeitpunkten einige Lücken in den Aufzeichnungen. Die SQL-
Anfragen zur Ermittlung dieser Lücken finden sich ebenfalls im Anhang A.2.
Es handelt sich als meist um kleine Aussetzer, bei denen nur für einige Minuten
keine Aufzeichnungen gemacht wurden. Allerdings gibt es mit mehr als
108 Tagen auch eine sehr große Lücke in den Aufzeichnungen. So wurden vom
24.05.2010 bis zum 09.09.2010 keine Aufzeichnungen gemacht.
3 Unvollständige Tage/Wochen wie z. B. der/die erste und letzte aufgezeichnete Tag/Woche
wurden nicht beachtet
© Andreas Redmer — 29. September 2011 5

1. Einleitung
Exaktheit
Die Tabelle 1.4 zeigt einige Constraints für die Exaktheit der aufgezeichneten
Daten. Die erste Zeile definiert, dass keine Einträge der Form LQ = LQN = 0
vorhanden sind, da dies eine nicht vorhandene Kante wäre. Zeile 2 prüft ob alle
Qualitätswerte unter 1 liegen. Die letzte Zeile zeigt, dass die Qualität asynchron
zu verschiedenen Zeitpunkten und an verschiedenen Stellen im Netzwerk
gemessen wird. Die Aufzeichnung der Daten im Netzwerk erfolgt minütlich,
aber der Austausch der Topology Control Informationen zwischen den Knoten
mit niedrigerer Frequenz. Somit trifft jeder Knoten die Routingentscheidungen
immer auf Basis des Netzwerkes aus seiner aktuellen Sicht. Dabei kommt
es insbesondere beim Ein- und Ausschalten von Knoten zu Ungenauigkeiten.
Beispielsweise kann eine Verbindung die von einem Knoten als ”
sehr gut“ bewertet
wurde, von dem nächsten Knoten schon als ”
nicht vorhanden“ bewertet
werden, weil die Messung ein paar Sekunden später erfolgte. Durch die redundanten
Informationen in der Datenaufzeichung kommt es also dazu, dass die
selbe Kante mit zwei verschiedenen Qualitätswerten bewertet wurde. In der
letzten Zeile der Tabelle 1.4 ist zu erkennen, dass in mehr als 50% der Fälle
eine Kante zum selben Zeitpunkt durch einen anderen Datensatz anders bewertet
wurde. Dadurch werden je beide Datensätze als nicht exakt angesehen.
Die SQL-Anfragen, welche die Werte für Tabelle 1.4 lieferten, befinden sich im
Anhang A.3.
Constraint Fälle korrekte Fälle erfüllt
lq > 0 ∨ lqn > 0 278884776 278850737 99,99%
lq ≤ 1 ∧ lqn ≤ 1 278884776 278884776 100,00%
∀((t, a, b, lq 1 , lqn 1 ), (t, b, a, lq 2 , lqn 2 ))
=⇒ lq 1 = lqn 2 ∧ lqn 1 = lq 2
278884776 131368930 47,11%
Tabelle 1.4.: Constraints für Exaktheit
In der internen Repräsentation des Graphen (z. B. Adjazenzliste) die später
verwendet werden muss, kann man durchaus mehrere Kanten zwischen
zwei Knoten einfügen. Der Routingalgorithmus würde automatisch immer das
kleinste der Gewichte wählen. Ebenso ist es möglich, im Rahmen einer Vorverarbeitung
der Daten, nur das Minimum dieser Daten zu speichern. Auch
das Maximum, der Durchschnitt oder eine zufällige Auswahl der möglichen
Kanten ist denkbar. Davon kann keine Möglichkeit generell als ”
richtig“ betrachtet
werden. Im Rahmen dieser Arbeit wird eine deterministische Variante
verwendet, um die Ergebnisse mit denen anderer Algorithmen vergleichbar zu
machen.
© Andreas Redmer — 29. September 2011 6

1. Einleitung
Weiterhin gilt für den bisherigen Zeitraum, dass alle vier Gateways immer
konstant anwesend waren und somit in jedem Timestamp auftauchen sollten.
Daraus ergibt sich auch, dass es immer mindestens eine Verbindung von einem
Gateway in den Rest des Graphen geben sollte. Das ist eine Voraussetzung
um überhaupt die kürzesten Wege zu diesem Gateway berechnen zu können.
Da die Gateways im Allgemeinen jedoch als variable Eigenschaft aller Daten
betrachtet werden sollen, wird diese Voraussetzung an dieser Stelle noch nicht
geprüft.
1.4. Ziel der Arbeit
Ziel dieser Arbeit ist es, die bisherigen Möglichkeiten der Datenanalyse zu beschleunigen.
Dazu soll eine Schnittstelle in Form von UDF erstellt werden, mit
deren Hilfe ein Datenanalyst die beschriebenen Daten analysieren kann. Insbesondere
soll dies mit einer besseren Performance geschehen als in bisherigen
Arbeiten (z. B. in [22]). In zukünftigen Arbeiten soll die Möglichkeit bestehen,
abgeleitete Kenngrößen zu bestimmen.
Die verschiedenen möglichen Anfragen an die Datenbank lassen sich in bestimmte
Problemklassen einteilen, die im Folgenden aufgezählt werden. Die
Aufzählung ist nicht abschließend. Es ist wichtig diese Problemklassen zu kennen,
da sie das zu erreichende Ziel der Arbeit gut beschreiben.
Problemklasse A: Knotenaktivität
Diese Klasse beinhaltet beispielsweise die An- und Abschaltaktivität von Knoten.
Diese Problemklasse lässt sich mit SQL aus den Daten ermitteln ohne
weitere Graphenalgorithmen auszuführen. UDF sind für diese Anfragen nicht
nötig.
Problemklasse B: Routen
Diese Klasse beinhaltet beispielsweise die zu einem bestimmten Zeitpunkt geltenden
Routen. Auch eine Anfrage nach der Stabilität der Routen über bestimmte
Zeiträume ist vorstellbar. Dies wäre z. B. nutzbar um die Agilität des
Routing-Protokolls zu justieren.
Die Routen können mit bekannten Graphenalgorithmen zur Ermittlung kürzester
Pfade von einer Quelle (Gateway) zu allen anderen Knoten berechnet
werden. Bei mehreren Gateways muss der Algorithmus mehrmals ausgeführt
© Andreas Redmer — 29. September 2011 7

1. Einleitung
und am Ende die geringste Entfernung zu einem Gateway ausgewählt werden.
Die Laufzeit des Verfahrens erhöht sich dadurch um einen konstanten Faktor.
Die zugehörige graphentheoretische Problemstellung ist Single-Source-
Shortest-Path (SSSP). Die Algorithmen Dijkstra [8] und Bellman-Ford [3]
lösen dieses Problem. Dijkstra hat eine geringere Zeitkomplexität. Einige optimierte
Varianten, wie z. B. der A* oder D* Algorithmus [18][29] funktionieren
nur, wenn der kürzeste Weg von einer Quelle zu einem Ziel gesucht ist. Im
Wesentlichen wird dabei versucht den Algorithmus so früh wie möglich abzubrechen,
wenn der Zielknoten erreicht ist. Dabei ändert sich die Worst-Case-
Komplexität nicht, jedoch werden die durchschnittlichen Laufzeiten mit diesen
Algorithmen verbessert. Da jedoch für die Problemklasse B stets die kürzesten
Wege zu allen anderen Knoten gesucht werden, ist Dijkstra die beste Wahl.
Auch der Floyd-Warshall-Algorithmus [13], der das All-Pairs-Shortest-Path
(APSP) Problem löst, kann das gesuchte Ergebnis berechnen, jedoch mit deutlich
höherem Zeitaufwand. Floyd-Warschall berechnet paarweise die Abstände
von jedem Knoten zu jedem anderen Knoten im gesamten Graph. Die allgemeine
Komplexität 4 des Dijkstra-Algorithmus ist O(n 2 + m).
Problemklasse C: Routenänderungen
Diese Klasse beinhaltet beispielsweise die Routenänderungen durch den Ausfall
einzelner Knoten oder Kanten. Ebenso sind Routenänderungen durch eine
Verschlechterung von Kanten denkbar. Daraus könnte man eine Kenngröße
für die Wichtigkeit einzelner Knoten im Netzwerk ermitteln. Dies ist für die
Netzplanung nutzbar, um einzelne Knoten oder Verbindungen zu verstärken.
Um dieses Problem zu lösen, wird ein Knoten aus dem Graphen gestrichen,
und dann wie in Problemklasse B die Routen neu berechnet. An der Ergebnismenge,
kann dann abgefragt werden, wie viele Routen sich durch den Wegfall
dieses Knotens verschlechtert haben bzw. gar nicht mehr erreichbar sind. Somit
lässt sich auch ein Maß für die Wichtigkeit dieses Knotens definieren. Diese
Verfahrensweise muss für jeden Knoten einmal ausgeführt werden, um die
Wichtigkeit aller Knoten zu ermitteln. Die Komplexität für dieses Verfahren
beträgt also O(n · (n 2 + m)).
Diese Problemklasse lässt sich sogar noch erweitern. Beispielsweise soll ermittelt
werden, wie stark sich der Ausfall von zwei Knoten gleichzeitig auf die
Routen im Netzwerk auswirkt. Dafür müsste man jeweils paarweise zwei Kno-
4 Die amortisiert betrachtete Komplexität kann, für die hier vorliegenden spärlichen Graphen,
noch weiter reduziert werden. Weiteres dazu wird im Abschnitt 4.1.1 erläutert.
© Andreas Redmer — 29. September 2011 8

1. Einleitung
ten aus dem Graphen streichen und das Ganze für alle möglichen Knotenpaare
im Graphen durchführen. Die Komplexität beträgt dann O(n 2 · (n 2 + m)).
Problemklasse D: Flaschenhalsanalyse
Diese Problemklasse beinhaltet die Suche nach den Flaschenhälsen im Netzwerkgraphen.
Durch die Identifikation einiger Verbindungen als Flaschenhälse
könnten diese gezielt verstärkt werden, um die Netzwerkqualität zu verbessern.
Einen Flaschenhals (auch Minimaler Schnitt) findet man in der Graphentheorie
durch Lösung des Min-Cut-Max-Flow (MCMF) Problems 5 .
Ein Algorithmus zum Finden des Flaschenhalses ist der Algorithmus von
Ford und Fulkerson [15]. Verbesserungen dieses Algorithmus sind der Algorithmus
von Edmonds und Karp [11] (Komplexität: O(n · m 2 ) ) und der Algorithmus
von Dinic [9] (Komplexität: O(n 2 · m) ). Im Falle der in dieser
Arbeit betrachteten Netzwerkgraphen sind derartig komplexe Algorithmen jedoch
nicht nötig. Ein Netzwerkgraph kann nicht als Flussgraph (wie etwa bei
Straßensystemen oder wasserführenden Rohrleitungen) betrachtet werden, da
für die Pakete jeweils nur eine Route gewählt wird. Wenn ein Client sehr viele
Pakete auf einmal sendet, werden diese nicht auf mehrere Routen aufgeteilt.
Das reduziert das MCMF Problem (für diese Graphen) wieder auf das Finden
der kürzesten Wege. Der Flaschenhals ist dann jeweils die ”
schlechteste“
Kante auf dem gefundenen Weg. Da man sich im Zuge der Ausführung des
Dijkstra-Algorithmus die ”
schlechteste“ Kante trivial speichern kann, bleibt die
Zeitkomplexität für dieses Verfahren die gleiche. Sie ist auch hier O(n 2 + m).
Problemklasse E: Alternativrouten
Diese Problemklasse beinhaltet das Finden von Alternativrouten. Dabei ist sowohl
die Anzahl als auch die Qualität der Alternativrouten interessant. Nutzbar
ist dies für eine Risikoanalyse der einzelnen Knoten. Feststellbar wäre
z. B. wie stark sich die Verbindung zum Gateway verschlechtert oder ob sie
komplett ausfällt, wenn die beste Route nicht mehr möglich ist. Mit der Anzahl
und Qualität von Alternativrouten lassen sich somit Kennzahlen für Netzqualität
und das Ausfallrisiko einzelner Knoten erstellen.
In der Graphentheorie werden dazu die k besten Pfade ermittelt. Das zugehörige
Problem ist das k-Shortest-Path (kSP) Problem. Zur Lösung dieses
5 Das Min-Cut-Max-Flow Theorem besagt, dass der maximale Fluss in einem Graphen
immer durch seine Engstelle (Flaschenhals) bestimmt wird. Minimaler Schnitt (Min-Cut)
und maximaler Fluss (Max-Flow) sind vom Betrag her gleich.
© Andreas Redmer — 29. September 2011 9

1. Einleitung
Problems, das Yen in [33] beschreibt, schlägt er einen auf Bellman-Ford basierenden
Algorithmus vor, da dies sehr einfach zum implementieren ist. Als
Basisalgorithmus, zur Ermittlung der kürzesten Pfade, kann jedoch auch der
Dijkstra verwendet werden. Dieser gibt die k kürzesten Pfade sortiert nach ihrer
Qualität zurück. Wenn man den Dijkstra mit der Komplexität O(n 2 + m)
als Basis verwendet, löst der Algorithmus von Yen [33] das kSP-Problem mit
der Zeitkomplexität von O(k · n · n 2 + m) = O(k · n 3 + m). Dies gilt jedoch nur
unter der sehr pessimistischen Annahme, dass der gefundene beste Weg alle
Knoten des Graphen enthält. Eine erste Untersuchung der Ergebnisse der Problemklasse
B hat jedoch gezeigt, dass sich auf den kürzesten Wegen maximal
1.78 √ n Knoten befinden (vgl. Anhang A.4). Dadurch ist eine gute Schätzung für
die obere Schranke der Komplexität dieses Problems O(k · 1.78√ n · n 2 + m) =
O(k · n 2.56 + m).
Zusammenfassung
Problemklasse Problem Komplexität Algorithmus
A Knotenaktivität - - -
B Routen SSSP O(n 2 + m) Dijkstra
C Routenänderungen SSSP O(n · (n 2 + m)) Dijkstra
D Flaschenhalsanalyse MCMF O(n 2 + m) Dijkstra
E Alternativrouten kSP O(k · n 2.56 + m) Dijkstra
Tabelle 1.5.: Zusammenfassung der Problemklassen
Die Tabelle 1.5 zeigt, dass alle für die Ergebnisse dieser Arbeit wichtigen
Probleme auf den Algorithmus von Dijkstra zurückführbar sind. Somit ist es
das wichtige Ziel, eine sehr performante Dijkstra-Implementierung zu finden.
Diese muss dann in einer UDF-Schnittstelle zur Verfügung gestellt werden.
1.5. Vorausgesetzte Hard- und Software
Um die Ergebnisse dieser Arbeit nachvollziehbar zu machen, sollen hier die
Computer beschrieben werden, der für die Erstellung der Implementierung
verwendet wurden. Tabelle 1.6 zählt alle relevanten Features auf.
Alle in dieser Arbeit angegebenen Laufzeiten beziehen sich, wenn nicht anders
angegeben, auf das Testsystem 1. Laufzeiten auf anderen Systemen können
entsprechend abweichen. Generell lassen sich alle Ergebnisse auch auf
anderen Computern nachvollziehen, es sei denn grundlegende Hardware (wie
© Andreas Redmer — 29. September 2011 10

1. Einleitung
z. B. Grafikkarte für GPU Berechnung) oder Software (z. B. das DBMS) ist
nicht vorhanden.
Feature Testsystem 1 Testsystem 2
Desktop PC
XEN Virtual Machine
CPU
AMD Athlon 64 X2 Dual Intel Xeon X5482
Core 4200+
(4 XEN Cores)
CPU Takt 2200 MHz 3200 MHz
CPU Cache
L1/L2
128 KB / 512 KB 64 KB / 6 MB
Arbeitsspeicher 4 GB DDR II - 800 MHz 1 GB DDR II
Festplatte
Samsung HD103SJ 7200
XEN XVDA
RPM, 32MB Cache, 150
Virtual Block Device
MB/s max
Grafikkarte
GeForce GTX 460, 16x
PCIe, 768MB GDDR5
-
RAM
GPU
1350 MHz und 336 CUDA
Cores à 675 MHz
-
Betriebssystem
Ubuntu 10.04.3 LTS, CentOS Release 5.5,
Kernel 2.6.32-32 Kernel 2.6.18-194.32.1
Dateisystem ext4 ext3
DB Server PostgreSQL 8.4.8 x86 64 PostgreSQL 8.4.5 x86 64
Java OpenJDK 1.9.9 OpenJDK 1.7.5
Tabelle 1.6.: Spezifikation der Testsysteme
© Andreas Redmer — 29. September 2011 11

2. Stand der Technik
2. Stand der Technik
2.1. Routing-Algorithmen
Als Routing wird in Rechnernetzen das Festlegen von Pfaden für die Nachrichtenübermittlung
bezeichnet. Es existiert eine Vielzahl von Algorithmen für
das Routing. Dabei gibt es zwei generelle Vorgehensweisen:
ˆ Link-State-Verfahren und
ˆ Distanzvektor-Verfahren.
Beim Link-State-Verfahren teilt jeder Teilnehmer der Welt mit, wer seine Nachbarn
sind. Dadurch ist nach einiger Zeit die gesamte Topologie des Netzwerks
an jedem Knoten verfügbar. Jeder Knoten kann also alle Pfade selbst berechnen.
Beim Distanzvektor-Verfahren wird auf jedem Knoten nur gespeichert, wie
gut bestimmte Ziele erreichbar sind. Diese Information wird jedem Nachbarn
mitgeteilt. Im Unterschied zu Link-State-Verfahren ist hier auf jedem Knoten
nur ein Teil der Welt abgespeichert und auch die Berechnung der Pfade erfolgt
über mehrere Knoten verteilt. Dafür wird in der Praxis meist der Algorithmus
von Dijkstra [8] oder der von Floyd und Warshall [13] eingesetzt.
Ein Verfahren kann grundsätzlich zentral oder dezentral sein. Dabei unterscheidet
sich die Lokalität auf der der Algorithmus ausgeführt wird. Bei
dezentralen Verfahren wird der Algorithmus auf allen Knoten ausgeführt, während
dies bei zentralen Verfahren in einem Kontrollzentrum geschieht. Auch
die Dynamik eines Verfahrens kann bewertet werden. Ein sehr dynamisches
Verfahren trifft die Routingentscheidungen aufgrund des aktuellen Zustandes
des Netzwerks. Bei weniger dynamischen Verfahren bleibt die Routingtabelle
über längere Zeit unverändert. Zentrale und undynamische Verfahren belasten
das Netzwerk weniger mit Topology Control (TC) Nachrichten. Dafür benutzen
sie jedoch möglicherweise veraltete oder unvollständige Informationen über
das Netzwerk.
Im Opennet-Netzwerk wird wird das Link-State-Protokoll OLSR (Optimized
Link State Routing [6]) als Routing-Protokoll eingesetzt. Dabei handelt
es sich um einen RFC-Standard, der ein Link-State-Verfahren für Wireless
Netzwerke beschreibt. Das Verfahren ist dezentral und sehr dynamisch. Die
Rechenlast und der Speicheraufwand für die aktuell geltenden Routen müs-
© Andreas Redmer — 29. September 2011 12

2. Stand der Technik
sen auf jedem Knoten aufgewandt werden. Etwa 10% der Bandbreite wird
im Opennet für TC-Nachrichten aufgewendet. Zur Berechnung der kürzesten
Pfade wird der Dijkstra-Algorithmus verwendet.
Für den Routing-Algorithmus sind verschiedene Weisen der zukünftigen Verbesserung
denkbar. Eine algorithmische Verbesserung könne beispielsweise dafür
sorgen, dass weniger (oder kleinere) TC-Nachrichten verschickt werden
müssen (Verbesserung auf OSI Schicht 4). Ein weiteres Beispiel ist eine Publikation
von Badis und Al Agha [2], in der sie den Datendurchsatz durch
eine Heuristik für die Selektion von MPRs 6 erhöhen. Andererseits ist auch die
Verbesserung der Hardware (Erhöhung der Sendeleistung, geringfügige physische
Repositionierung der WLAN-Antenne, etc.) möglich (Verbesserung auf
OSI-Schicht 1).
In all diesen Fällen wird jedoch eine vorherige Datenanalyse benötigt, um
festzustellen welche TC-Nachrichten redundant sind und nicht wiederholt versendet
werden müssen oder um wichtige Knoten und Verbindungen zu finden,
die dann gezielt verstärkt werden können. Im Rahmen dieser Arbeit wurde
ein Framework erstellt mit dem diese Datenanalyse sehr performant und sehr
einfach durchgeführt werden kann.
2.2. Metriken
Unabhängig vom verwendeten Routing-Algorithmus und dem darin enthaltenen
Graphen-Algorithmus wird eine Metrik benötigt. Auch die Algorithmen
Dijkstra und Floyd-Warshall setzen eine Metrik voraus mit der der Abstand
von einem Knoten zum anderen bestimmt werden kann. Aus mathematischer
Sicht heißt eine Funktion f : M×M → R Metrik, wenn für beliebige a, b, c ∈ M
gilt:
1. f(a, b) ≥ 0
2. f(a, b) = 0 ⇔ a = b
3. f(a, b) = f(b, a)
4. f(a, b) ≤ f(a, c) + f(c, b).
Wenn man auf das dritte Axiom (Symmetrie) verzichtet, erhält man eine Quasimetrik.
Eine Metrik in einem Rechnernetz ist eine mathematische Quasimetrik, die
ein Maß für die Güte einer Verbindung definiert. Die Qualitätswerte sind üblicherweise
in einem Intervall definiert und können invers zu einer tatsächlichen
6 MPR: Multipoint Relay, ein Knoten der Nachrichten an mehrere Empfänger weiterleitet
© Andreas Redmer — 29. September 2011 13

2. Stand der Technik
mathematischen Metrik sein. Dabei können Verbindungsqualität, Bandbreite,
Verzögerung (Latenzzeiten), aktuelle Last, MTU, Verlässlichkeit, Hop Count
und/oder die tatsächlichen Kosten für die physikalische Aufrechterhaltung der
Verbindung in die Berechnung eingehen. Netzwerk-Metriken geben die Güte
des gesamten Pfades zwischen zwei Knoten an. Dies muss keine direkte Verbindung
sein. Sei f(a, b) eine Metrik für eine Verbindung zwischen den Netzwerkknoten
a und b und sei (n 1 = a, n 2 , . . . , n m−1 , n m = b) der beschreibende Pfad
zwischen a und b, dann gibt es verschiedene Formen der Zusammenführung
der einzelnen Teilpfade. Diese können additiv, multiplikativ oder konkav sein
und sind wie folgt definiert:
additiv: f(a, b) = f(n 1 , n m ) =
m−1
∑
multiplikativ: f(a, b) = f(n 1 , n m ) =
i=1
f(n i , n i+1 )
m−1
∏
i=1
f(n i , n i+1 )
konkav: f(a, b) = f(n 1 , n m ) = m−1
min
i=1 (f(n i, n i+1 ))
Beispielsweise verwendet man die Übertragungsverzögerung als additive Metrik.
Die Summe der Verzögerung auf jedem Teilpfad ergibt den Gesamtwert,
der die Qualität der Verbindung beschreibt. Ein Beispiel für eine multiplikative
Metrik ist die Verlustwahrscheinlichkeit. Dabei ist das Produkt aller Wahrscheinlichkeiten,
auf dem Weg von a zu b, die Gesamtwahrscheinlichkeit für den
Paketverlust auf der Verbindung. Für eine konkave Metrik ist die Bandbreite
beispielhaft zu nennen. Die geringste Bandbreite, die auf einem Teilpfad verfügbar
ist, ist der Wert für die gesamte Bandbreite auf dem Pfad. Im Opennet
wird die multiplikative Metrik ETX (Expected Transmission Count) verwendet,
die in [7] vorgestellt wurde. Diese beschreibt die Wahrscheinlichkeit dafür,
dass ein Paket von a nach b tatsächlich ankommt.
2.3. Betrachtung der bestehenden
Implementierung als Cloud-Service
In diesem Abschnitt wird die Implementierung von Mundt und Vetterick [22]
genauer betrachtet. Sie stellt den aktuellen Stand der Technik bezüglich der
Datenanalyse und ihrer Performanceoptimierung dar.
© Andreas Redmer — 29. September 2011 14

2. Stand der Technik
2.3.1. Algorithmische Komplexität
In dieser Implementierung dauerte die Berechnung der kürzesten Wege von
jedem Knoten zu einem Gateway mit dem Dijkstra-Algorithmus eine Sekunde.
Dabei werden durchschnittlich 200 Knoten und 800 Kanten verwendet. Da
es derzeit vier Gateways gibt, muss der Dijkstra-Algorithmus vier mal ausgeführt
werden. Dadurch ergibt sich eine Ausführungszeit von vier Sekunden, pro
Timestamp, die für die Datenauswertung mindestens nötig ist. Da dieser Zeitaufwand
(mehr als zwanzig Tage für ein Jahr aufgezeichnete Daten) sehr hoch
ist um effizient damit arbeiten zu können, wurde die Berechnung in [22] erfolgreich
parallelisiert. Dafür wurde der Cloud-Service von Google verwendet. Je
nach Anzahl der verwendeten CPU-Kerne ließ sich die Verarbeitungszeit für
ein Jahr aufgezeichnete Daten damit bis auf 20 Stunden reduzieren.
Da das Problem der kürzesten Pfade und der Dijkstra-Algorithmus in vielen
Wissenschaftszweigen sehr verbreitet ist, wird fortlaufend an Optimierungen
für den Algorithmus von Dijkstra geforscht. Derzeitige Implementierungen erreichen
das Ergebnis für eine Millionen Knoten in weniger als zehn Sekunden
[17]. Es stellte sich also die Frage, warum die bestehende Implementierung damit
verglichen so langsam ist. Da in der Implementierung keine offensichtlichen
Fehler beim Hardwarezugriff oder Datenbankzugriff erkennbar sind, liegt die
Vermutung nahe, dass die Komplexität des implementierten Algorithmus zu
hoch sein könnte. Deshalb wurde an dieser Stelle eine Komplexitätsbetrachtung
durchgeführt.
Die Laufzeitkomplexität wurde durch Substitution aller Quelltextzeilen durch
die Ausgabe einer Zeichenkette realisiert. Die Zeichenkette stellt jeweils die
Komplexität für den einzelnen Befehl dar. So wurde jeder Zugriff auf eine Java
TreeMap (containsKey, get, put) und jeder Zugriff auf ein Java TreeSet (add,
remove, contains) durch die Zeichenkette ”
log(n)“ ersetzt. Diese Operationen
werden garantiert in logarithmischer Zeit ausgeführt 7 . Die Zeichenkette ”
n“
steht für die Anzahl der Knoten und ”
m“ für die Anzahl der Kanten. Analog
wurde jede Schleife die über alle Knoten iteriert mit ”
n ∗“ ersetzt. Dabei wurde
jeweils der Worst-Case (also der schlechteste Fall) angenommen.
Ausgabe des Programms war:
n + log(n) + log(n) + log(n) + n ∗ (+n ∗ (+log(m) + n ∗ (+log(n) + m +
log(m))) + m + log(n) + m ∗ (+log(n) + log(n) + log(n)) + log(n) + log(n))
Dieser Term wird vereinfacht und die konstanten Faktoren werden der Lesbarkeit
wegen gestrichen (diese ändern die Komplexitätsklasse nicht).
7 Diese Angabe stammt aus der Java API Dokumentation [25] der jeweiligen Funktionen.
© Andreas Redmer — 29. September 2011 15

2. Stand der Technik
n + log(n) + n(n(n(log(n) + log(m) + m) + log(m)) + m · log(n) + log(n) + m)
oder:
(((n 3 · log(n) + n 3 · log(m) + n 3 · m) + n 2 · log(m)) + n · m · log(n) + n ·
log(n) + n · m) + log(n) + n
Wie die roten Stellen offenbaren, liegt die Komplexitätsklasse über O(n 3 ), da
der Quelltext drei ineinander verschachtelte Schleifen hat, die bis zu n mal
ausgeführt werden. Der Dijkstra-Algorithmus läuft jedoch eigentlich mit einer
Laufzeit von O(n 2 + m). Wie diese hohe Komplexität zustande kommt, kann
bei der Betrachtung des Quelltextes ermittelt werden. Dazu ist in Listing 2.1
nochmal eine Pseudocode-Schreibweise des o.g. Terms angegeben.
1 n
2 log(n)
3 n mal (
4 n mal (
5 n mal (
6 log(n)
7 log(m)
8 m
9 )
10 log(m)
11 )
12 m mal log(n)
13 log(n)
14 m
15 )
Listing 2.1: Pseudocode des Algorithmus aus [22]
Konstante Ausdrücke wurden in dieser Darstellung weggelassen. Die Ausdrücke
”
n“ und ”
m“ repräsentieren eine Schleife, deren Inhalt jedoch konstant
ist (z. B. ”
n mal 1“ oder ”
n mal 3“).
Die ersten beiden Zeilen erhöhen die Laufzeit nicht wesentlich. Dabei handelt
es sich um die übliche Aufbereitung der Daten für den Algorithmus. In
vielen Fällen ist auch noch eine Nachbereitung notwendig. Wenn beispielsweise
nach der Ausführung des Dijkstra zusätzlich einmal über alle Knoten iteriert
werden muss, so erzeugt dies nur ein weiteres ”
+n“ im Term der Komplexität.
Die Laufzeit erhöht sich also linear und somit nur unwesentlich. Die höchsten
Laufzeiten in diesem Quelltext sind die Polynomiellen. Also die drei Schleifen,
© Andreas Redmer — 29. September 2011 16

2. Stand der Technik
die in den Zeilen 3, 4 und 5 beginnen. In diesen Zeilen hat n die folgenden
Bedeutungen:
ˆ n in Zeile 3: n u die Anzahl unbearbeiteter Knoten
ˆ n in Zeile 4: n b die Anzahl bearbeiteter Knoten
ˆ n in Zeile 5: n n die Anzahl der Nachbarn eines Knoten
Für den Worst-Case gilt:
aber auch:
n u = n
n b = n.
In jedem Teil des Programmablaufes gilt jedoch:
n = n u + n b
denn es wird in jedem Schleifendurchlauf ein weiterer unbearbeiteter Knoten
als bearbeitet markiert. Tatsächlich wird der Inhalt der ersten beiden Schleifen
also niemals n 2 mal ausgeführt. Für die Worst-Case-Betrachtung ist dieser
Wert allerdings richtig, da er für große n gegen n 2 konvergiert.
Die Worst-Case-Annahme, dass sich alle Knoten in der Nachbarschaft eines
Knotens befinden, ist relativ pessimistisch. Für kleine Netzwerke in der sich
alle Knoten untereinander gegenseitig in direkter Funkreichweite befinden, ist
sie dennoch richtig. Eine Einschränkung für die Komplexitätsbetrachtung kann
also nicht gemacht werden. Somit gilt
n n = n
und es kann n u = n b = n n = n für die Komplexitätsbetrachtung angenommen
werden.
Im Folgenden soll die Komplexität des eigentlichen Dijkstra-Algorithmus
vergleichend betrachtet werden.
© Andreas Redmer — 29. September 2011 17

2. Stand der Technik
1 FUNCTION dijkstra() {
2 init()
3 WHILE Q ≠ ∅ {
4 u := min(Q)
5 Q := Q \ {u}
6 FOR EACH NEIGHBOUR v OF u {
7 IF v ∈ Q THEN update(u, v)
8 }
9 }
10 }
Listing 2.2: Dijkstra-Algorithmus
in Pseudocode
1 FUNCTION dijkstra() {
2 O(n)
3 n mal (
4 O(1)
5 O(n)
6 n mal (
7 O(1)
8 )
9 )
10 }
Listing 2.3: Komplexität des
Dijkstra-Algorithmus
1 FUNCTION init() {
2 FOR EACH v ∈ V (G) {
3 dist[v] := ∞
4 pred[v] := null
5 }
6 dist[s] := 0
7 Q := V (G)
8 }
Listing 2.4: init-Funktion des
Dijkstra-Algorithmus
1 FUNCTION update(u,v) {
2 new_way := dist[u] + distance(u, v)
3 IF new_way < dist[v] THEN {
4 dist[v] := new_way
5 pred[v] := u
6 }
7 }
8
Listing 2.5: update-Funktion des
Dijkstra-Algorithmus
In Listing 2.2 ist der Algorithmus von Dijkstra in Pseudocode dargestellt.
Daneben (Listing 2.3) ist zeilenweise die Komplexität für den Algorithmus angegeben.
Der Algorithmus arbeitet mit der Prioritätswarteschlange Q. Diese
enthält anfangs die Menge aller Knoten des Graphen (V ). Der aktuell kürzeste
Weg vom Startknoten (s) wird in Q als Priorität gespeichert. Die Funktion
min(Q) gibt das Element mit der kleinsten Priorität zurück. Im Array dist[]
werden die Abstände von allen Knoten zum Startknoten gespeichert. Das Array
pred[] speichert den Vorgänger zu jedem Knoten, der auf dem Pfad des
kürzesten Weges liegt.
Die Funktion init() (vgl. Listing 2.4) setzt die Startwerte für all diese
Variablen. Sie hat eine Laufzeit von O(n). Die WHILE-Schleife, die in Zeile 3
beginnt, arbeitet alle Knoten in Q ab und hat somit eine Laufzeit von O(n).
In Zeile 4 und 5 des Dijkstra-Algorithmus (Listing 2.2) wird der Knoten u
mit dem kleinsten Wert in Q gefunden und dann aus Q gelöscht. In der Praxis
implementiert man sich dafür eine extract_minimum-Funktion die beide
Schritte in O(n) ausführt. Dabei liegt die Annahme zu Grunde, dass Q mit
einem einfachen Array programmiert wurde und somit eine lineare Laufzeit
© Andreas Redmer — 29. September 2011 18

2. Stand der Technik
für das Auffinden eines Elementes hat. Andere Datenstrukturen sind dabei
auch möglich. In Zeile 6 des Dijkstra-Algorithmus startet die Schleife, die über
alle Nachbarn des Knotens iteriert. Auch hier wird angenommen, dass sich alle
Knoten in der Nachbarschaft des Knotens befinden. Somit wird der Inhalt
dieser Schleife n mal ausgeführt.
In Zeile 7 kommt der wichtige Unterschied zu der Implementierung aus [22]
zum Vorschein. Die Abfrage, ob ein Knoten schon bearbeitet wurde, muss nicht
auf das Suchen eines Elementes in einer Menge (v ∈ Q) zurückgeführt werden.
Dies wäre genau so aufwändig wie die Verwendung von zwei disjunkten Mengen
für bearbeitete und unbearbeitete Elemente (wie in Listing 2.1). Stattdessen
kann hier einfach ein boolesches Array angelegt werden, das die Information
speichert ob der Knoten schon bearbeitet wurde oder nicht. Somit kann die
Abfrage v ∈ Q in konstanter Zeit ausgeführt werden. Da die Funktion update
(Listing 2.5) ebenfalls nur konstante Laufzeit hat, ist die gesamte Zeile 7 mit
konstantem Zeitaufwand ausführbar.
Für den gesamten Algorithmus in Listing 2.2 ergibt sich somit, wie man in
Listing 2.3 auch erkennt, eine Komplexität von:
O(n + n · (n + n)) = O(n + 2n 2 )
Diese Laufzeit ist deutlich geringer als die für das im Listing 2.1 angegebene
Verfahren.
Abschließend sei noch bemerkt, dass die obere Schranke noch niedriger angesetzt
werden kann. Aufgrund der Vorbedingungen wird die Funktion update
tatsächlich nur m mal ausgeführt. Die Anzahl der Nachbarn pro Knoten ist
zwar variabel, aber über den gesamten Algorithmus betrachtet sinkt die Anzahl
der Nachbarn für den Knoten, die noch nicht bearbeitet wurden. Die Funktion
update wird nur einmal pro Kante ausgeführt. Dadurch erhält man die noch
geringere Komplexität von
O(n + n 2 + m).
Dabei ist der erste Teil (n) die Vorbereitung bzw. Initialisierung der Daten und
der zweite Teil (n 2 + m) die eigentliche Laufzeit eines Dijkstra-Algorithmus.
2.3.2. Vor- und Nachteile der Cloudlösung
Für die Implementierung aus [22] wurde die ”
App Engine“ benutzt. So bezeichnet
der Anbieter Google seine Cloud. Der größte Vorteil war eine klare
© Andreas Redmer — 29. September 2011 19

2. Stand der Technik
Beschleunigung des Programmablaufes durch die hochgradige Parallelisierung.
Weiterhin ist die Nutzung von kostengünstigen On-Demand-Ressourcen ein
entscheidender Vorteil. Mundt und Vetterick rechnen in ihrer Publikation exemplarisch
vor, dass die Nutzung der Cloud kostengünstiger ist als die Verwendung
(Anschaffung und Wartung) eines eigenen Servers.
Im Rahmen dieser Arbeit wird ein eigener Datenbankserver verwendet. Dieser
ist jedoch konzeptionell gleich mit dem Computer der die Datenaufzeichnung
anfertigt, denn Ziel ist es ja die Berechnungen direkt in der Datenbank
auszuführen. Abhängig davon, wie sehr der aufzeichnende Knoten durch auf
ihm laufende Datenanalysen ausgelastet werden darf, ist für das hier entwickelte
Konzept kein separater Server notwendig. Bezüglich der Geschwindigkeit
sollten die Ergebnisse, die mit den User Defined Functions (UDF) erreicht
werden idealerweise so schnell sein, dass ihre Verwendung lohnenswerter ist als
die der ”
App Engine“.
Der größte Nachteil bei der Berechnung in der Cloud ist der teure Upload
der Daten in die Cloud. Dabei sind nicht nur die monetären Kosten sondern
auch der benötigte Zeitaufwand entscheidend. Weiterhin ist die Benutzung
der ”
App Engine“ an das dokumentbasierte Datenbanksystem ”
Bigtable“ [5]
von Google gebunden. Dies bringt die generellen Vorteile eines NoSQL DBMS
mit sich. Beispielsweise ist es möglich sehr große Datenmengen im dreistelligen
Terabyte-Bereich zu speichern und schnell auf diese zugreifen zu können.
Dies bringt jedoch den Nachteil, dass die Anfragesprache verglichen mit SQL
deutlich reduzierter ist. Sämtliche Data Mining Funktionen aus dem SQL’97
Standard, können bei NoSQL-Datenbanken nicht genutzt werden. Somit muss
die Datenanalyse immer in einem zusätzlichen Programm stattfinden. Weiterhin
bietet die Google ”
App Engine“ verständlicherweise eine eingeschränkte
Version der Java API an. Dies ist zwar nicht zwangsweise ein Nachteil, könnte
aber unter Umständen den Entwicklungsaufwand erhöhen.
In dieser Arbeit können die eben genannten Nachteile beseitigt werden. Zunächst
entfällt der teure Upload, da ein eigener Server benutzt wird. Die Einschränkung
der Anfragesprache kann aufgehoben werden, indem ein relationales
DBMS benutzt wird. Näheres dazu wird im Abschnitt 3.1.1 erläutert. Die
Einschränkung der Programmiersprache bzw. der API kann ebenfalls durch
die richtige Auswahl verhindert werden. Dies wird später im Abschnitt 3.1.3
genauer erörtert.
© Andreas Redmer — 29. September 2011 20

3. Vorbetrachtungen einer hochperformanten Lösung
3. Vorbetrachtungen einer
hochperformanten Lösung
3.1. Wahl des DBMS und der
Programmiersprache
Die Topologieinformationen des Mesh-Netzwerks werden an einem zentralen
Punkt im Netzwerk einmal pro Minute aufgezeichnet. Dabei läuft auf diesem
Knotenpunkt ein Java-Programm, dass die Informationen über eine JDBC-
Schnittstelle auf einem MySQL Datenbankserver speichert. Die ursprüngliche
Idee zu dieser Arbeit ist es, User-Defined-Functions (UDF) direkt auf diesem
Datenbankserver auszuführen und dadurch die Laufzeitperformance zu verbessern.
Im Folgenden soll zunächst untersucht werden, inwiefern der Umstieg auf
ein anderes DBMS sinnvoll ist und welches Datenmodell das DBMS verwenden
sollte. Die Verwendung eines anderen DBMS wäre denkbar, wenn sich dadurch
entscheidende Unterschiede in der Performance ergeben und die Umstellung auf
das neue DBMS einfach realisierbar ist.
3.1.1. Wahl des Datenbankmodells
Da MySQL ein relationales DBMS ist, werden die Daten bisher relational, also
zeilenweise in Tabellen gespeichert. Neben dem relationalen Datenbankmodell
existieren noch folgende Formen:
ˆ Netzwerkartig: Die Datenobjekte werden als Knoten in einem Graphen
betrachtet, die mit Kanten untereinander verbunden sein können.
ˆ Objektorientiert: Die Datenobjekte sind als komplexe Objekte aus einfachen
Datentypen erstellt. Beziehungen zwischen den Objekten können
Komposition, Aggregation oder Generalisierung sein.
ˆ Dokumentbasiert: Die Datenobjekte werden als Dokumente gespeichert,
deren Struktur jedoch nicht prinzipiell festgelegt ist. Im Gegensatz zum
objektorientierten Ansatz hat ein Datenobjekt hier eine variable Anzahl
© Andreas Redmer — 29. September 2011 21

3. Vorbetrachtungen einer hochperformanten Lösung
von Eigenschaften. Auch die Beziehungen zwischen Datenobjekten werden
über die Eigenschaften variabel gestaltet.
ˆ Hierarchisch: Die Datenobjekte stehen in Parent-Child-Beziehungen zueinander.
Es existieren auch Mischformen.
Netzwerkartige Speicherung
Die Topologiedaten des Mesh-Netzwerks sind naturgemäß als netzwerkartige
Daten zu betrachten, die derzeit jedoch in relationaler Form gespeichert
werden. Es existiert also ein Mapping, das die netzwerkartige Form der Daten
in die relationale (tabellarische) Form bringt. In diesem Fall wird eine
erweiterte Form einer Adjazenzliste in der Tabelle gespeichert. Diese wurde
gewählt, weil sich die Daten in ähnlicher Form auch in der OLSR-Software
des Knotenpunktes befinden und weil sich die zeilenweise Speicherung in der
MySQL-Datenbank sehr einfach implementieren ließ.
Um die in der Tabelle 1.1 (Seite 3) in einem netzwerkartigen DBMS (im folgenden
Graph-DBMS genannt) zu speichern, kann man auf zwei verschiedene
Arten vorgehen:
1. Man speichert alle Knoten des Mesh-Netzwerkes in ein großes Netzwerk
in der Datenbank ab. Dabei bildet man aus dem Timestamp und der
IP-Adresse einen gemeinsamen, eindeutigen Schlüssel für einen Knoten.
Alle Knoten aus allen Timestamps werden dann in das selbe Netzwerk
eingefügt, wobei nur Verbindungen zwischen Knoten des selben Timestamps
existieren. Hier muss das DBMS also einen sehr großen Graph
speichern können.
2. Man speichert jeden Timestamp (also jedes separate Abbild) in ein neues
Netzwerk in der Datenbank. Dabei wäre der Timestamp jeweils der Name
des Netzwerks und die Knoten wären die IP-Adressen der Knotenpunkte
aus dem Mesh-Netzwerk. Die Verbindungen zwischen den Knoten werden
wie im tatsächlichen Mesh-Netzwerk gespeichert. Hier muss das DBMS
also sehr viele einzelne Graphen speichern können.
Welche dieser beiden Speicherstrategien man wählt, hängt von der internen
Speicherung der Graphen im DBMS ab. Moderne DBMS sind darauf optimiert
auch sehr große Netzwerke oder Graphen effizient speichern zu können. Die
erste der genannten Strategien eignet sich also gut, wobei der Timestamp in
irgendeiner Weise indiziert werden müsste. Schließlich werden die Graphenalgorithmen
(z. B. das Finden der kürzesten Pfade) jeweils nur ”
pro Timestamp“
© Andreas Redmer — 29. September 2011 22

3. Vorbetrachtungen einer hochperformanten Lösung
ausgeführt. Somit muss die Gesamtheit aller Knoten eines Timestamps immer
effizient selektierbar sein. Gleichzeitig müsste dafür gesorgt werden, dass die
Knoten mit gleichem Timestamp immer möglichst auf der selben Seite gespeichert
und nicht im gesamten Speicherbereich verteilt werden.
Im Rahmen dieser Arbeit, konnte kein DBMS mit netzwerkartiger Speicherung
gefunden werden, das Open-Source vertrieben wird oder die Art der
Speicherung offen dokumentiert. Ein weiter Nachteil ist, dass die populären
Graph-DBMS kostenpflichtig sind und deshalb für diese Arbeit nicht geeignet.
Auch konnten keine Graph-DBMS gefunden werden, in denen User Defined
Functions in der Anfragesprache definierbar sind.
Ein weiterer interessanter Ansatz für die Speicherung der Daten ist, eine
Mapping-Strategie zu finden, welche die Graphen effizient in einem relationalen
DBMS speichert. Dabei kann man ein kostenloses DBMS verwenden und
man könnte selbst dafür Sorge tragen, dass die Speicherung für die eigenen
Zwecke effizient geschieht. Dabei könnten Datenzugriffe über UDF gemacht
werden, wie es beispielsweise bei PostGIS[28] gemacht wurde. Aber auch bei
solchen Ansätzen ist festzustellen, dass sie für sehr große Datenmengen entworfen
wurden. Das bedeutet, dass der Graph so groß ist, dass er nicht in eine
Speicherseite passt (bei PostgreSQL vier Kilobytes). PostGIS wurde beispielsweise
für die Verwaltung geographischer Daten (z. B. Straßennetze) entwickelt.
Die in dieser Arbeit behandelten Netzwerkgraphen sind so klein (≈ 200 Knoten),
dass sie keiner besonderen Speicherform bedürfen um die Geschwindigkeit
des Datenzugriffs zu erhöhen.
Objektorientierte Speicherung
Weiterhin soll nun die Speicherung in einer objektorientierten Datenbank untersucht
werden. Die in Tabelle 1.1 (Seite 3) gezeigten Daten können, wie in
Abbildung 3.1 als UML-Klassendiagramm gezeigt, objektorientiert gespeichert
werden.
Link
+KnotenA:String
+KnotenB:String
+LQ:float
+NLQ:float
1 1..*
Zeitpunkt
+Datum:date
+Uhrzeit:time
+Links:Link[]
Abbildung 3.1.: Objektorientierte Speicherung der Daten (UML-
Klassendiagramm)
© Andreas Redmer — 29. September 2011 23

3. Vorbetrachtungen einer hochperformanten Lösung
Ein Link ist dabei ein Vier-Tupel bestehend aus Knoten A, Knoten B, Link
Quality und Neighbour Link Quality. Eine Liste dieser Links stellt dabei eine
Repräsentation des Graphen zu einem Zeitpunkt da. Zusätzlich zu der Liste
wird der Timestamp dieses Zeitpunktes gespeichert. Neben der Speicherung
in einem objektorientierten DBMS wäre auch ein objektrelationales Mapping
denkbar. Dabei würden die objektorientierten Inhalte in einer relationalen Datenbank
gespeichert werden. Für sehr einfache Objekte, die keine komplizierten
objektorientierten Methoden verwenden, wäre es auch denkbar die Datensätze
als erweiterte Datentypen (auch TypeDefs oder Structs genannt) in Tabellen
zu speichern. Listing 3.1 zeigt wie man derartige Datentypen in PostgreSQL
definieren kann. Durch diese Speicherung wird jedoch weder Performance noch
Usability erhöht. Je nach gewählter Speicherform könnte sich durch diese Speicherform
der verwendete Speicherplatz geringfügig reduzieren lassen. Dies verursacht
jedoch zusätzlichen Zeitaufwand beim Zugriff auf die Daten.
1 CREATE TYPE Link AS (
2 KnotenA varchar,
3 KnotenB varchar,
4 LQ float,
5 NLQ float );
6
7 CREATE TYPE Zeitpunkt AS (
8 DatumUndUhrzeit timestamp,
9 Links Link[] );
Listing 3.1: Typendefinitionen in PostreSQL
Dokumentbasierte Speicherung
Die Daten können auch auf verschiedene Weisen in einem dokumentbasierten
Datenbanksystem gespeichert werden. In [22] wurde die Datenanalyse für
die hier behandelten Mesh-Netzwerke in die Google-Cloud ausgelagert, um
sie zu beschleunigen. Dafür ist es nötig, die Daten auf dem Datenbankserver
von Google abzulegen. Dabei wird das Datenbanksystem BigTable verwendet,
welches in [5] vorgestellt wurde. Dokumentbasierte Datenbanken werden bevorzugt
benutzt, wenn sehr große Datenmengen gespeichert werden müssen.
Dadurch gewinnen sie derzeit, in der industriellen und wissenschaftlichen Verwendung,
immer mehr an Bedeutung. Verglichen mit dem relationalen Ansatz
der Datenspeicherung, werden die Daten beim dokumentbasierten Ansatz nicht
mehr normalisiert. Es werden also auch redundante Daten gespeichert und keine
Prüfungen auf Konsistenz mehr durchgeführt. Die Verwendung von Joins
© Andreas Redmer — 29. September 2011 24

3. Vorbetrachtungen einer hochperformanten Lösung
und Constraints macht das relationale Konzept sehr langsam. Dadurch haben
relationale Datenbanken bei sehr großen Datenmengen performancebedingt
keine praktische Bedeutung mehr. Allerdings sind dadurch auch die Anfragen
an die Daten komplizierter. Es kann kein SQL oder nur noch eine sehr eingeschränkte
Form von SQL verwendet werden. Derartige moderne Datenbanken
werden auch als NoSQL-Datenbanken bezeichnet.
Aufgrund der Datenmengen ist ein Wechsel von MySQL auf eine dokumentbasierte
Datenbank derzeit nicht nötig, da die gespeicherten Daten nur etwa
40 Gigabytes (in MySQL) belegen. Die textuelle Repräsentation der Daten in
einer einfachen CSV-Datei ist 15,3 Gigabytes groß. Der Import dieser Daten
in eine PostgreSQL-Tabelle mit den tatsächlichen Datentypen (und nicht ihrer
textuelle Form) ist 16 Gigabytes groß. Jonathan Ellis (ein Entwickler des dokumentbasierten
Datenbanksystems Cassandra [1]) gibt in einem Vortrag [12]
an, dass es für die Performance keinen Unterschied macht, ob man Cassandra
oder eine relationale Datenbank einsetzt, wenn man keine verteilte Datenbank
benutzt und keine Joins und Constraints verwendet. Da im Rahmen dieser Arbeit
nur eine Tabelle von Datenaufzeichnungen verwendet wird, die durchaus
Fehler in der Konsistenz und redundante Informationen enthält (vgl. Abschnitt
1.3), ist der Umstieg auf ein dokumentbasiertes DBMS nicht nötig.
Hierarchische Speicherung
Die Speicherung in einem hierarchischen Datenbankmodell ist für diese Daten
nicht sinnvoll, da sie keine sinnvolle hierarchische Repräsentation haben.
Zusammenfassung
Abschließend ist zu bemerken, dass im Rahmen dieser Arbeit die Speicherung
der Daten in relationaler Form beibehalten wurde. Der Hauptgrund dafür ist,
dass das Programm für die Datenaufzeichung nicht geändert werden muss.
Beim Wechsel auf ein anderes relationales DBMS würde sich auch der Import
und Export der Daten einfacher gestalten, als bei einem Wechsel des Datenbankmodells.
Im folgenden Abschnitt soll deshalb untersucht werden, ob ein
Wechsel auf ein anderes relationales DBMS sinnvoll ist und welche Vor- und
Nachteile dieser hätte.
© Andreas Redmer — 29. September 2011 25

3. Vorbetrachtungen einer hochperformanten Lösung
3.1.2. Wahl des DBMS
Als populärste Vertreter von relationalen DBMS sind Oracle, DB2, MS SQL
Server, PostgreSQL und MySQL zu nennen. An das gesuchte System sind
jedoch folgende Bedingungen zu stellen:
1. Das DBMS sollte kostenlos oder sehr kostengünstig verwendbar sein, da
es später nur für die Datenanalyse beim Opennet e.V. verwendet werden
soll.
2. Das DBMS sollte plattformunabhängig sein, um eine Installation auf dem
aufzeichnenden Opennet-Knoten zu ermöglichen.
3. Wenn es eine Lizenz, die für Forschungszwecke o. ä. frei verwendbar ist,
darf diese nicht so weit eingeschränkt sein, dass sie mit den Voraussetzungen
für dieses Projekt kollidiert. So bietet Oracle beispielsweise eine
Version an, die für studentische Forschungen frei ist, diese kann jedoch
nur Daten bis zu zwei Gigabytes verwalten.
Nach Beachtung dieser Kriterien bleibt letztlich nur die Wahl, bei dem bestehenden
MySQL-Server zu bleiben oder zu einem PostgreSQL-Server zu wechseln.
Dazu ist zu sagen, dass PostgreSQL das einzige völlig kostenlos verwendbare
der genannten Systeme ist. MySQL hat ein relativ komplexes Lizenzmodell
und ist unter gewissen Umständen auch kostenpflichtig. Generell ist
PostgreSQL funktionaler und kann größere Datenmengen besser handhaben
als MySQL [20] [30] [31]. Dafür ist die Installation und Bedienung von MySQL
deutlich einfacher.
Bei MySQL gibt es lediglich zwei Möglichkeiten User Defined Functions
(UDF) anzulegen. Die eine ist, das Anlegen von sogenannten Stored Procedures,
wobei es sich um eine Abfolge von SQL-Anweisungen handelt. Diese sind
nicht turingvollständig und lassen dadurch unter Umständen die Implementierung
der benötigten Graphenalgorithmen nicht zu. Die zweite Möglichkeit
ist die C++ Schnittstelle für UDF bei MySQL zu verwenden. Diese werden
dann kompiliert und als Teil des Datenbankservers geladen. Die Programmierung
solcher C++ UDF ist sehr rudimentär und aufwändig. Dabei können viele
Fehler entstehen, die mit moderneren Programmiersprachen ausgeschlossen
sind. Da MySQL selbst auch in C++ entwickelt ist, muss bei der Verwendung
von Bibliotheken (wie z. B. stdlib) auf die richtige Version geachtet werden.
Das Debugging solcher UDF gestaltet sich schwierig und es entsteht ein recht
hoher Entwicklungsaufwand.
Gleichzeitig wurde PostgreSQL als DBMS betrachtet, für das es verschiedene
Konzepte zum Erstellen von UDF in verschiedenen Programmiersprachen
gibt. Die beiden für MySQL genannten Möglichkeiten existieren in PostgreSQL
© Andreas Redmer — 29. September 2011 26

3. Vorbetrachtungen einer hochperformanten Lösung
ebenfalls. Zusätzlich gibt es die Möglichkeit über eine generelle Schnittstelle
Unterstützung für neue Programmiersprachen hinzuzufügen. Dabei ist es
grundsätzlich nicht vorgegeben, ob die Funktion ein Link auf eine kompilierte
Funktion in einer Bibliothek ist, oder ob der Inhalt der Funktion (als Zeichenkette)
im Quelltext auf dem Server gespeichert ist und bei Bedarf interpretiert
und ausgeführt wird. Es können jeweils einfache Funktionen mit elementarem
Datentyp, Tabellenfunktionen, Aggregatfunktionen und Triggerfunktionen erstellt
werden. Hinzu kommt die Möglichkeit, dass PostgreSQL eigene komplexe
Datentypen aus einfachen Datentypen (oder Arrays davon) definieren kann.
Diese können wiederum als Werte in Tabellen, Indizes und UDF (Ein- und
Ausgabe) verwendet werden. Dazu ist zu bemerken, dass die Speicherung eines
komplexen Datentyps oder Arrays in einer Tabellenspalte prinzipiell der
ersten Normalform bei der Normalisierung von relationalen Datenbanken widerspricht.
Allerdings können dadurch meist Joins eingespart werden, um die
Performance der Datenbankanfragen zu erhöhen. Man muss also in der Praxis
genau wissen, wann der Einsatz solcher Features sinnvoll ist.
Aufgrund der größeren Auswahl bei PostgreSQL und der generell besseren
Performance gegenüber MySQL-Datenbanken (vgl. [20]) wurde die Entscheidung
getroffen PostgreSQL für diese Arbeit als DBMS zu verwenden. Die Untersuchungen
in Abschnitt 3.1.3 bestätigen dies als gute Entscheidung. Der
Export der Daten aus der MySQL-Datenbank (in eine CSV-Datei) und der
Import in die PostgreSQL-Datenbank ist sehr einfach. Auch die permanente
Umstellung des Java-Programms, das die Daten aufzeichnet, ist sehr einfach,
da die verwendeten SQL-Anweisungen (INSERT INTO) bei PostgreSQL die gleiche
Syntax haben (nämlich SQL 97). Somit müsste nur die Stelle im Quelltext
geändert werden, die den Datenbanktreiber lädt und die Verbindung zum Datenbankserver
herstellt. Im einfachsten Falle bedeutet das:
1 DriverManager.getConnection(
2 "jdbc:mysql://localhost:3306/dbname","user", "pass").connect();
Listing 3.2: JDBC-Verbindung zu einem MySQL-Server in Java
wird zu:
1 DriverManager.getConnection(
2 "jdbc:postgresql://localhost:5432/dbname","user", "pass").connect();
Listing 3.3: JDBC-Verbindung zu einem PostgreSQL-Server in Java
© Andreas Redmer — 29. September 2011 27

3. Vorbetrachtungen einer hochperformanten Lösung
Die Unterschiede zwischen Listing 3.2 und Listing 3.3 sind lediglich ein anderer
Datenbanktreiber und Standardport für den Verbindungsaufbau. Dies
ist offensichtlich nur eine minimale und leicht vertretbare Veränderung an dem
Programm, das die Datenaufzeichung vornimmt. Für die Zeit der Umstellung
ist auch eine parallele Aufzeichnung auf zwei verschiedenen Datenbankservern
denkbar. An dieser Stelle wird nochmal darauf hingewiesen, dass die Verwendung
eines anderen Datenbankmodells (nicht relational) oder eines anderen
Speicherkonzeptes (JDO, Hibernate o. ä.) wesentlich größere Änderungen erfordert
hätten.
3.1.3. Wahl der Programmiersprache
PostgreSQL bietet Unterstützung für SQL und PL/SQL (für PostgreSQL wird
es PL/pgSQL genannt). PL/SQL ist die Eweiterung von SQL um Entscheidungen,
Schleifen und benutzerdefinierte Funktionen. Dadurch ist die Sprache im
Gegensatz zu SQL turingvollständig 8 . Je nach Kompilat bringt PostgreSQL
auch Unterstützung für PL/Perl, PL/Python und PL/Tcl mit. Dabei handelt
es sich jeweils um eine prozedurale Variation der Programmiersprache, die der
Kern-Distribution von PostgreSQL angehört. Derartige Funktionen werden im
Quelltext auf den Server geladen und bei Bedarf interpretiert und ausgeführt.
Durch das einfache Konzept des Server Programming Interface (SPI) von
PostgreSQL ist es möglich auch Handler für eigene Programmiersprachen
zu erstellen. So sind beispielsweise in externen Projekten bereits PL/Java,
PL/PHP, PL/Ruby und einige mehr entstanden. Diese befinden sich in unterschiedlichen
Entwicklungsstadien und haben auch unterschiedliche Performance.
Auch der Aufwand der Installation kann, je nach Basissystem, für einige
der Programmiersprachen höher sein. Letztendlich richtet sich es jedoch auch
nach den Erfahrungen und Präferenzen der Softwareentwickler, die die UDF
erstellen, welche Programmiersprache verwendet wird.
Um die Laufzeiten der verschiedenen Möglichkeiten für UDF zu ermitteln
wurde der Floyd-Warshall-Algorithmus implementiert. Dieser berechnet alle
kürzesten Wege von jedem Knoten zu jedem anderen Knoten in einem Graphen.
Da in späteren Betrachtungen immer nur die kürzesten Wege von den
Knoten zu den Gateways von Interesse sein werden, berechnet der Floyd-
Warshall-Algorithmus viel mehr Informationen als eigentlich von Interesse sind.
Er läuft mit einer Komplexität von O(n 3 ) auch relativ lange. Er wurde für die
8 Das Hauptmerkmal dafür ist die Tatsache, dass SQL-Anfragen immer enden. Endlosschleifen
gibt es in SQL-Anfragen nicht. Somit können mit SQL weniger Programme
implementiert werden als mit turingvollständigen Sprachen.
© Andreas Redmer — 29. September 2011 28

3. Vorbetrachtungen einer hochperformanten Lösung
ersten Geschwindigkeitsvergleiche nur verwendet, weil er sich sehr einfach implementieren
lässt.
1 ∀k = 1 TO n
2 ∀i = 1 TO n
3 ∀j = 1 TO n
4 D i,j = min(D i,j , D i,k + D k,j )
Listing 3.4: Floyd-Warshall-Algorithmus in Pseudocode
In Listing 3.4 ist der Floyd-Warshall-Algorithmus im Pseudocode abgebildet.
Dabei steht n für die Anzahl der Knoten und D für die Distanzmatrix in der
der Graph gespeichert ist. Der Algorithmus arbeitet direkt auf dieser Matrix.
D ist die Eingabe und nach der Berechnung auch die Ausgabe. Wie man leicht
sieht, prüft der Algorithmus für jedes mögliche Paar von Knoten (i, j) ob der
Weg über einen dritten Knoten (k) kürzer ist, als der bereits gefundene Weg
zwischen i und j.
Dieser Algorithmus wurde im Rahmen dieser Arbeit in SQL, PL/pgSQL,
PL/Python und PL/Java implementiert. Dabei wurden die in Tabelle 3.1 angegebenen
Laufzeiten gemessen.
Programmiersprache Laufzeit
SQL
> 60 Sekunden
PL/pgSQL
> 60 Sekunden
PL/Python
6 Sekunden
PL/Java
0,25 Sekunden
Tabelle 3.1.: Laufzeiten des Floyd-Warshall-Algorithmus
SQL ist keine Programmiersprache und eignet sich somit meist nicht zur Implementierung
von Algorithmen. Der Floyd-Warshall-Algorithmus ist jedoch so
einfach, dass er mit einer SQL-Zeile berechnet werden kann. Das funktioniert,
da die letzte Zeile des Algorithmus eine einfache Zuweisung ist und sich die
drei Schleifen als Cross-Joins abbilden lassen. Im Anhang A.5 ist der zugehörige
Quelltext abgebildet. Dennoch sind für diese Ausführung umfangreiche
Vorbereitungen notwendig. So muss die Menge der Knoten in eine Tabelle
geschrieben und dann die Distanzmatrix D in eine Tabelle gespeichert werden.
Es müssen Accessor- und Mutator-Funktionen geschrieben werden um
auf einen Wert in D (lesend und schreibend) zugreifen zu können. Weiterhin
muss ein Wert für unendlich (∞) definiert (dabei sind ”
-1“ oder NULL beispielhafte
Werte) und eine Minimum-Funktion geschrieben werden, die diesen
∞-Wert korrekt berücksichtigt.
© Andreas Redmer — 29. September 2011 29

3. Vorbetrachtungen einer hochperformanten Lösung
Die Laufzeit von mehr als einer Minute ist nicht akzeptabel, da jeweils eine
Minute an aufgezeichneten Daten ausgewertet werden soll. Somit wäre die
Datenaufzeichnung schneller als die Datenanalyse und der Versuch alle Daten
zu analysieren würde nie enden. Weiterhin wurde im Abschnitt 2.3.1 angegeben,
dass die bisherige Implementierung nur vier Sekunden dauert und diese
optimiert werden soll. Die Laufzeit dieser SQL-Funktion ist so hoch, weil die
Matrix D auf die mindestens 3 · n 3 mal zugegriffen wird (lesend und schreibend)
hier nicht im Arbeitsspeicher liegt, sondern als persistente Tabelle in der
Datenbank.
Mit PL/pgSQL ist die Implementierung auch nicht sehr performant implementierbar.
Die Sprache unterstützt zwar mehrdimensionale Arrays und eindimensionale
Arrays mit variabler Größe, allerdings keine mehrdimensionalen
Arrays mit variabler Größe. Dadurch ist die Implementierung des Algorithmus
eigentlich gar nicht möglich. Für dieses Problem gibt es einige Workarounds,
die jedoch das mehrdimensionale Array bei jedem Zugriff komplett neu anlegen
oder es in einer temporären Tabelle in der Datenbank speichern. Dadurch
ist auch hier keine Ausführung des Floyd-Warshall-Algorithmus unter einer
Minute durchführbar.
Mit PL/Python liegt die Ausführungszeit bei sechs Sekunden. Der dafür
verwendete Quelltext findet sich im Anhang A.6.
Mit PL/Java wird die schnellste Ausführungszeit von 250 Millisekunden erreicht.
Das Parsen oder Ausführen eines Java-Programms ist im Allgemeinen
nicht schneller als bei einem Python-Programm. Der Unterschied ist, dass die
UDF für PL/Python definiert wird, indem der Quelltext direkt auf den Server
hochgeladen wird. Bei Bedarf (also bei jedem Aufruf der Funktion) wird der
Python-Quelltext geparst und ausgeführt. Bei PL/Java wird nur ein Verweis
auf eine Funktion in einer class-Datei gespeichert. Jede PL/Java UDF besteht
also für den Server aus nur einer Zeile, wobei die tatsächliche Funktionalität
in vorkompilierter Form in der class-Datei vorliegt.
Dieses Resultat legt die Vermutung nahe, dass auch die anderen ad-hoc interpretierten
Sprachen ähnliche Defizite in der Ausführungszeit haben. Deshalb
wurden PL/Tcl und PL/Perl nicht getestet. Auch PL/pgSQL würde wahrscheinlich
auch in dieser Geschwindigkeit laufen, wenn die Arrays korrekt funktionieren
würden. Es wurde also festgestellt, dass für die performanceoptimierte
Programmierung eine kompilierte UDF zu bevorzugen ist. Da C++ Funktionen
(die es ja in MySQL auch gibt) aufgrund des hohen Entwicklungsaufwandes
zuvor ausgeschlossen wurden, fiel die Wahl der Programmiersprache für diese
Arbeit auf PL/Java.
© Andreas Redmer — 29. September 2011 30

3. Vorbetrachtungen einer hochperformanten Lösung
Zusätzlich zu der hohen Ausführungsgeschwindigkeit bringt die Verwendung
von Java noch diverse weitere Vorteile, da mit PL/Java, die gesamte Mächtigkeit
von Java in die UDF von PostgreSQL eingebracht wird.
ˆ Es kann Eclipse als IDE verwendet werden,
ˆ es kann JUnit als Test-Framework verwendet werden,
ˆ es existiert eine sehr gute und umfangreiche API und Dokumentation,
ˆ die gesamte API (auch Dateisystemzugriffe, Socketverbindungen, JDBC
uvm.) kann in einer UDF verwendet werden ohne durch einen Security-
Manager eingeschränkt zu sein,
ˆ es gibt eine Garbage-Collection
ˆ und neben dem Just-In-Time Compiler wird der Code auch zur Laufzeit
optimimiert.
PL/Java-Funktionen sollen im Folgenden, der Einfachheit wegen, nur noch
Java-Funktionen genannt werden. Der Ablauf für die Ausführung einer Java-
Funktion auf dem Datenbankserver ist in Abbildung 3.2 schematisch aufgezeigt.
In Schritt 1 wird der Java-Quelltext in eine java-Datei geschrieben. In
Schritt 2 erfolgt die Übersetzung in Bytecode in eine class-Datei. Diese wird in
Schritt 3 in eine jar-Datei komprimiert. Mit Hilfe des Deployers von PL/Java
wird in Schritt 4 eine Kopie der jar-Datei auf dem Datenbankserver abgelegt.
Zudem wird die Datei registriert und geladen. Da die Funktionen später als
UDF dienen sollen, wurden sie alle als static deklariert und sind mit dem Laden
der Datei einsatzbereit. Globale Variablen, die in der Klasse dann ebenfalls
als static deklariert wurden, werden an dieser Stelle initialisiert. Derartige Variablen
können dazu dienen, zwischen mehreren UDF zu kommunizieren oder
Zustände zu speichern. In Schritt 5 wird die UDF auf dem Server angelegt,
also der Verweis der neuen Funktion auf die bestehende Java-Funktion. Java-
Funktion und UDF müssen nicht den gleichen Namen haben, aber die Anzahl
und Datentypen der Parameter und des Rückgabewertes müssen übereinstimmen.
Schritt 6 ist die Ausführung der Funktion, die jetzt beliebig oft wiederholt
werden kann. Wenn sich der Java-Quelltext ändert müssen die Schritte 1 bis
4 erneut ausgeführt werden. Schritt 5 braucht nur erneut ausgeführt werden,
wenn sich die Signatur der Java-Funktion und somit auch die Signatur der
UDF geändert hat. Alles was in der Abbildung innerhalb des DB-Servers eingezeichnet
wurde (JAR und UDF) ist persistent.
Generell ist es freigestellt, welche Java Virtual Machine (JVM) benutzt wird.
Die Entwickler von PL/Java geben an, dass auch der Gnu Java Compiler
(GJC) benutzt werden kann, der den Java-Quelltext plattformabhängig in den
© Andreas Redmer — 29. September 2011 31

3. Vorbetrachtungen einer hochperformanten Lösung
1
2
Klasse.java
Klasse.class
class Klasse {
static int f(int a) {
return a+1;
}
}
3
file:///Klasse.jar
DB Server
4
SELECT deploy ( ′ file:///Klasse.jar ′ );
JAR
5
CREATE FUNCTION f (int4 a)
RETURNS int4 AS ′ Klasse.f ′
LANGUAGE java;
UDF
int f(int)
int f(int)
{
. . .
}
6
SELECT f (1);
Abbildung 3.2.: Integration einer Java UDF in PostgreSQL
Maschinencode des Zielsystems kompiliert. Allerdings ist dies derzeitig als experimentell
gekennzeichnet und wird deshalb im Rahmen dieser Arbeit nicht
benutzt. Die im Rahmen dieser Arbeit verwendeten JVMs sind in der Tabelle
1.6 (Seite 11) angegeben.
3.2. Schnittstellendefinition
In diesem Abschnitt wird die Schnittstelle beschrieben, die dem Datenanalysten
zur Verfügung gestellt wird. Es wird also erklärt, wie die neu entwickelten
UDF zu verwenden sind. Weiterhin wird der innere Aufbau der UDF und der
Java-Funktionen soweit definiert, dass gute Erweiterbarkeit und Wiederverwendbarkeit
des Quelltextes gegeben sind. Zunächst werden alle UDF definiert,
die in einer SQL Anweisung aufgerufen werden können.
© Andreas Redmer — 29. September 2011 32

3. Vorbetrachtungen einer hochperformanten Lösung
Funktionsname: shortestPaths
Parameter: Timestamp
Rückgabewert: eine Menge von 2-Tupeln der Form: (Knoten,Vorgänger)
SQL Beispielaufruf:
SELECT * FROM shortestPaths("2011-01-31 07:30:02");
Funktion: Berechnet die für die in Tabelle 1.1 (Seite 3) gegebenen
Daten die kürzesten Wege von jedem Knoten zu einem der Gateways,
die zu einem bestimmten Zeitpunkt gültig waren.
Die Funktion shortestPaths ist eine PL/pgSQL UDF, die weitere PL/Java
UDF (Subfunktionen) aufruft. Sie löst das Problem der Abfrage der kürzesten
Pfade (Problemklasse B - vgl. Abschnitt 1.4). Sie dient auch gleichzeitig
als Vorlage um weitere UDF zu entwickeln, die mit den selben Subfunktionen
weitere Probleme lösen, die in Abschnitt 1.4 beschrieben wurden (z.B. Flaschenhalsermittlung).
Die Funktion shortestPaths soll den in Abbildung 3.3
skizzierten Ablauf haben.
Start
Eingabe Timestamp
truncateRootNodes
addRootNode
≈ 4 mal
truncateLinks
≈ 800 mal
addLink
≈ 800 mal
run
getResultSet
Stop
Abbildung 3.3.: Ablauf der shortestPaths Funktion
Da die Gateways variabel sein können, werden diese nicht fest definiert, sondern
für jeden Zeitpunkt separat angegeben. Die Funktion addGateway fügt ein
Gateway in die Java-Klasse ein. Die Funktion addLink fügt eine Zeile aus dem
Datenbestand für den gewählten Timestamp in die Java-Klasse ein und spei-
© Andreas Redmer — 29. September 2011 33

3. Vorbetrachtungen einer hochperformanten Lösung
chert diese dort in der internen Abbildung des Graphen. Da die Java-Klasse nur
beim Deploy-Vorgang bzw. beim Neustart des Datenbankservers initialisiert
wird, muss es eine Methode geben, um die interne Speicherung des Graphen
zu initialisieren bzw. sie für die nächste Berechnung zurückzusetzen. Da sich die
Knotenmenge (im Gegensatz zur Menge der Gateways) sehr stark verändert,
soll diese separat zurückgesetzt werden können. Deshalb gibt es die Funktion
truncateGateways die alle Gateways aus der Java-Klasse löscht, sowie die
Funktion truncateLinks die alle zuvor mit addLink eingefügten Kanten im
Graphen löscht. Die Knoten des Graphen werden nicht eingefügt, sondern automatisch
aus den Kanten ermittelt. Die Funktion run soll den Algorithmus
zur Berechnung der kürzesten Wege ausführen. Die Funktion getResultSet
gibt das Ergebnis zurück, welches unmittelbar auch die Rückgabe der Funktion
shortestPaths sein soll. Die Funktionen run und getResultSet sind bewusst
getrennt um spätere Erweiterbarkeit zu gewährleisten. So kann zum Beispiel
die Implementierung verschiedener Algorithmen später mit einem Parameter
der Funktion run gelöst werden. Wenn die Ausgabe um zusätzliche Spalten erweitert
werden soll, kann der Rückgabewert von der Funktion getResultSet
verändert werden. Die genannten Subfunktionen sind wie folgt definiert.
Funktionsname: addLink
Parameter: Knoten A, Knoten B, Link Quality, Neighbour Link Quality
Rückgabewert: kein
SQL Beispielaufruf:
SELECT addLink("192.168.0.1","192.168.0.2",1.0,0.9);
Funktion: Fügt zwei Kanten in die interne Repräsentation des Graphen
in die Java-Klasse ein, welche die bidirektionale Verbindung zwischen
Knoten A und Knoten B im Graphen gewichtet repräsentieren.
Wenn Link Quality oder Neighbour Links Quality den Wert 0 hat, wird
dafür entsprechend keine Kante eingefügt. Die Knotennamen sind Zeichenketten
und die Qualitätswerte sind Fließkommazahlen.
© Andreas Redmer — 29. September 2011 34

3. Vorbetrachtungen einer hochperformanten Lösung
Funktionsname: truncateLinks
Parameter: kein
Rückgabewert: kein
SQL Beispielaufruf:
SELECT truncateLinks();
Funktion: Entfernt alle Kanten und Knoten aus der internen Repräsentation
des Graphen in der Java Klasse, die zuvor mit addLink eingefügt
wurden.
Funktionsname: addGateway
Parameter: Knotenname
Rückgabewert: kein
SQL Beispielaufruf:
SELECT addGateway("192.168.0.1");
Funktion: Fügt ein Gateway in die Java Klasse ein. Später wird von
jedem Knoten im Graphen der kürzeste Weg zu einem Gateway bestimmt.
Funktionsname: truncateGateways
Parameter: kein
Rückgabewert: kein
SQL Beispielaufruf:
SELECT truncateGateways();
Funktion: Entfernt alle Gateways aus der Java Klasse, die zuvor mit
addGateway eingefügt wurden.
Funktionsname: run
Parameter: kein
Rückgabewert: kein
SQL Beispielaufruf:
SELECT run();
Funktion: Startet die Berechnung der kürzesten Wege von jedem Knoten
zu einem Gateway. Es müssen zuvor Knoten, Kanten und mindestens
ein Gateway mit den Funktionen addLink und addGateway erstellt
worden sein. Wenn mehrere Gateways gegeben sind, wird der Weg zum
nächstgelegenen Gateway als Ergebnis gespeichert.
© Andreas Redmer — 29. September 2011 35

3. Vorbetrachtungen einer hochperformanten Lösung
Funktionsname: getResultSet
Parameter: kein
Rückgabewert: eine Tabelle mit den Spalten Knoten und Vorgänger
SQL Beispielaufruf:
SELECT * FROM getResultSet();
Funktion: Gibt die zuvor mit run berechneten Pfade zurück. Für jeden
Knoten wird der Vorgänger auf dem Pfad zum nächsten Gateway
zurückgegeben. Für die Gateways werden keine Vorgänger zurückgegeben.
Die Anzahl der zurückgegebenen Zeilen entspricht der Anzahl
der eingefügten Knoten abzüglich der Anzahl der Gateways.
Alle zuvor genannten Funktionen (außer shortestPaths) sollen PL/Java
UDF sein, die auf Methoden in einer Java-Klasse verweisen. Die Java-Klasse
wird nach dem in Abbildung 3.2 gezeigten Schema erstellt und geladen. Die
Methoden sind alle als public und static deklariert . Die Klasse soll mindestens
das in Abbildung 3.4 in UML dargestellte Interface implementieren.
-graph
-rootNodes
IShortestPaths
+truncateRootNodes(): void
+addRootNode(in Node:String): void
+truncateLinks(): void
+addLink(in A:String,in B:String,in LQ:float,in NLQ:float): void
+run(): void
+getResultSet(): ResultSet
Abbildung 3.4.: Interface für shortestPaths PL/Java (UML-
Klassendiagramm)
3.3. Möglichkeiten der Performancemessung
Um die Performance der Implementierung des vorgestellten Konzeptes zu prüfen
und zu verbessern, gibt es verschiedene praktische Arten der Zeitmessung,
die zum Einsatz kommen, um die Geschwindigkeit der Datenverarbeitung zu
ermitteln. Diese werden hier vorgestellt, um die gemessenen Zeiten nachvollziehbar
zu machen.
© Andreas Redmer — 29. September 2011 36

3. Vorbetrachtungen einer hochperformanten Lösung
Die Dauer einer SQL-Anweisung, die mit einer graphischen Oberfläche an
den SQL-Server gesendet wird, wird meist zusätzlich zum Ergebnis angezeigt.
Im Rahmen dieser Arbeit wurde pgAdmin [27] verwendet, welches nach jeder
Abfrage die benötigte Zeit in Millisekunden anzeigt. Wenn keine graphische
Oberfläche vorhanden ist und die SQL-Abfragen direkt an der Shell an den
SQL-Server gesendet werden, kann die Zeit durch den Linux/Unix Befehl time
gemessen werden. Ein solcher Aufruf könnte beispielsweise wie folgt aussehen:
time echo ’SELECT count(*) FROM links;’ | psql
Diese Zeitmessung umfasst nicht nur die Ausführung der SQL-Anweisung selbst,
sondern auch das Senden der Anweisung an den Server (unter Umständen über
eine Netzwerkverbindung) und die Ausgabe des Ergebnisses. Die Ausgabe des
Ergebnisses auf der Konsole ist sehr langsam und verfälscht die Messung stark.
Wenn also sehr viele Zeilen zurückgegeben werden, ist das gemessene Ergebnis
unbrauchbar. Das einfache Zählen der Zeilen im Ergebnis vermeidet dieses
Problem. So dauert die Ausführung des Befehls:
time echo ’SELECT * FROM links;’ | psql
deutlich länger als der vorher genannte.
Jedoch verbraucht auch das Zählen der Zeilen ein wenig Zeit. Dies kann
vermieden werden, indem das Ergebnis der Abfrage in eine Datei umgeleitet
wird. Dies kann bei großen Dateien zu Problemen führen und hängt von der
Geschwindigkeit der Festplatte ab. Außerdem verwalten verschiedene Dateisystem
große Dateien auf verschiedene Weisen. Auch der Füllstand der Partition
und die Fragmentierung der neuen Datei wirkt sich auf die Zeitmessung aus.
Somit bietet die Umleitung in eine Datei, die nicht in einem Dateisystem auf
einem physikalischen Speicher abgelegt ist, die genaueste Messung. Ein Beispiel
dafür sieht so aus:
time echo ’SELECT * FROM links;’ | psql > /dev/null
Bei der Verwendung einer graphischen Oberfläche ist die Ausgabe von sehr vielen
(> 1000000) Zeilen nicht mehr möglich. Denn dabei wird pro Ergebniszeile,
eine Zeile in einem Listenfeld der verwendeten GUI angelegt. Derartig große
Listenfelder sind nicht vorgesehen. Der Versuch eine solche Ausgabe anzuzeigen
bricht nach mehreren Stunden Ausführungszeit ab (da der Arbeitsspeicher
voll ist) oder dauert aufgrund der Auslagerung von Arbeitsspeicher so lange,
dass die Ausführung nicht effizient möglich ist. Wenn die graphische Benut-
© Andreas Redmer — 29. September 2011 37

3. Vorbetrachtungen einer hochperformanten Lösung
zeroberfläche keine Möglichkeit bietet, das Ergebnis in eine Datei umzuleiten,
kann der SQL-Server mit dem COPY-Befehl die Ausgabe in einer Datei ablegen.
Beispielsweise kann man die SQL-Anweisung
COPY (SELECT * FROM links) TO /dev/null ;
verwenden. Die Ausgabe in eine Datei erfolgt dann jedoch auf dem Server und
nicht auf dem Client (der Zeitaufwand für die Übertragung des Ergebnisses
zum Client entfällt also).
Die gemessene Performance ist immer abhängig von der aktuellen Auslastung
des Systems. Es spielt also der Füllstand des Arbeitsspeichers und des
Auslagerungsspeichers, sowie die aktuelle CPU-Last eine Rolle. Auch die Größe
und der Füllstand des CPU-Caches spielen besonders auf dedizierten Datenbankservern
eine Rolle. Durch die Nutzung eines CPU-Caches wird eine UDF
im ersten Durchlauf deutlich langsamer ausgeführt als in den folgenden Durchläufen.
Die komplexen Zusammenhänge zwischen den Hardwarekomponenten
und den Ausführungszeiten sollen an dieser Stelle nicht weiter erläutert werden.
Alle Laufzeiten, die im Rahmen dieser Arbeit angeben werden sind Durchschnittszeiten.
Insbesondere bei Messungen im Millisekundenbereich wurden
jeweils mehrere Millionen Testläufe durchgeführt und jeweils die durchschnittliche
Ausführungszeit angegeben.
Unabhängig von den UDF können auch die beinhalteten Java-Programme
einer Zeitmessung unterzogen werden. Dazu wurden im Rahmen dieser Arbeit
die folgenden drei Arten verwendet:
ˆ Verwendung der JUnit
ˆ Verwendung von System.currentTimeMillis()
ˆ Verwendung von System.nanoTime()
Die JUnit [21] ist ein Testframework für Java, das es ermöglicht automatisierte
Tests für Java-Programme durchzuführen. Auch für die in dieser Arbeit
verwendeten Algorithmen (und deren Subfunktionen) wurden weitreichende
Tests geschrieben. Diese wurden in einer Testsuite zusammengefasst und nach
jeder Änderung im Quelltext ausgeführt. Da die JUnit nach jedem Test auch
die Ausführungszeit angibt, wurde eine weitere Testsuite für Performancetests
angelegt. Diese Tests führen zeitkritische Funktionen einmal oder mehrmals
aus, um Performanceveränderungen nach jeder Änderung im Quelltext evaluieren
zu können.
Die Java-Funktion System.currentTimeMillis() gibt die aktuelle Systemzeit
in Millisekunden aus, also die Anzahl der vergangenen Millisekunden seit
© Andreas Redmer — 29. September 2011 38

3. Vorbetrachtungen einer hochperformanten Lösung
dem 01.01.1970 00:00 Uhr. Damit lässt sich die Ausführungszeit von Quelltext
relativ genau messen. Die Funktion System.nanoTime() funktioniert analog,
jedoch mit der Angabe des Timestamps in Nanosekunden. Dazu ist zu bemerken,
dass die Granularität zwar nanosekundengenau ist, jedoch nicht die
Präzision [26]. Die Präzision hängt vom Betriebssystem ab, auf dem die JVM
ausgeführt wird. In der Javadokumentation [26] wird der in Listing 3.5 angegebene
Java-Quelltext zur Zeitmessung vorgeschlagen. Dort finden sich auch
weitere Informationen zu diesen beiden API-Funktionen.
1 long startTime = System.nanoTime();
2 // ... the code being measured ...
3 long estimatedTime = System.nanoTime() - startTime;
Listing 3.5: Zeitmessung für ein Java-Programm
Besondere Beachtung, bei der Zeitmessung für Java-Programme, ist dem
JIT-Compiler zu schenken. Java-Programme werden grundsätzlich von Quelltext
in Bytecode übersetzt. Bytecode ist eine plattformunabhängige Form des
Java-Programms. Auf dem Zielsystem wird der Bytecode in Hotspots unterteilt
und jeder Hotspot wird unmittelbar vor der Ausführung kompiliert. So
kann beispielsweise der Inhalt einer Schleife oder einer Funktion ein Hotspot
sein. Das führt dazu, dass die erste Ausführung im ersten Durchlauf deutlich
länger dauert als alle weiteren Durchläufe. Zusätzlich hat die JVM einen
JIT-Optimierer, der den Programmablauf zur Laufzeit mit Compilertechniken
optimiert. So kann z. B. der IF- und der ELSE-Zweig einer Entscheidung zur
Laufzeit vertauscht werden, wenn der Optimierer feststellt, dass die Bedingung
öfter falsch ist als wahr. Ähnliche Mechanismen gibt es auch auf Hardwareebene
in modernen CPUs.
Das führt dazu, dass die gemessenen Zeiten der ersten Durchläufe ignoriert
werden sollten. Danach kann wieder mit den durchschnittlichen Ausführungszeiten
gearbeitet werden. Die durchschnittlichen Ausführungszeiten sind später
relevant um eine Vorhersage für die Dauer großer Datenanalyen machen zu
können.
© Andreas Redmer — 29. September 2011 39

4. Optimierungen in der Implementierung
4. Optimierungen in der Implementierung
Im praktischen Teil dieser Arbeit wurde das zuvor vorgestellte Konzept implementiert
und auf verschiedenste Arten optimiert. Diese Optimierungen lassen
sich generell in algorithmische Optimierungen (Abschnitt 4.1), Optimierungen
am Programmierstil (Abschnitt 4.2) und Parallelisierung (Abschnitt 4.3)
einteilen. In diesem Kapitel werden sie genauer erläutert und die Gründe für
ihre Verwendung oder Nichtverwendung genannt. Am Ende dieses Kapitels,
werden alle durchgeführten Optimierungen nochmals tabellarisch zusammengefasst
(Abschnitt 4.4). Als Optimierung ist hier immer eine Veränderung des
Softwareprogramms gemeint, die den Zeitaufwand für dessen Ausführung reduziert.
Weitere Optimierungen (wie z. B. die Verwendung schnellerer Hardware)
wären ebenfalls möglich gewesen, wurden jedoch im Rahmen dieser Arbeit
nicht untersucht.
4.1. Algorithmische Optimierungen
4.1.1. Optimierung des Dijkstra-Algorithmus
Im Abschnitt 1.4 wurde bereits festgestellt, dass eine effiziente Implementierung
des Dijkstra-Algorithmus nötig ist um die Ziele dieser Arbeit zu erreichen.
Im Abschnitt 2.3.1 (Listing 2.2, Seite 18) wurde der Dijkstra-Algorithmus beschrieben.
Der große Teil des Zeitaufwandes für den Algorithmus liegt darin,
die unbenutzten von den bereits benutzten Knoten zu trennen, von den unbenutzten
Knoten den Nächstgelegenen zu finden und von diesem dann wieder
alle unbenutzten Nachbarn zu betrachten. Diese Form der Exploration kann
sehr zeitaufwändig sein, wenn die dafür benutzen Datentypen nicht korrekt
gewählt werden. Der Dijkstra-Algorithmus wurde mit der Komplexität
O(n + n 2 + m)
angegeben. Dabei ist das erste n lediglich die Initialisierung, die sich nicht
optimieren lässt. Es wird dafür gesorgt, dass alle Knoten in die vorgesehenen
abstrakten Datentypen eingefügt, Anfangswerte auf 0 gesetzt bzw. noch
nicht ermittelte Abstände mit ∞ ( ”
unendlich“) initialisiert werden. Je nach
© Andreas Redmer — 29. September 2011 40

4. Optimierungen in der Implementierung
verwendeter Programmiersprache und abhängig von dem Wert, den man für
∞ festlegt (vgl. Abschnitt 4.2.4), ist die Initialisierung optional. Somit wird
nur die Optimierung des Terms
betrachtet.
O(n 2 + m)
Für die Verwaltung der noch nicht behandelten Knoten, wurde die Prioritätswarteschlange
Q verwendet. Auf dieser Warteschlange, müssen verschiedene
Operationen (wie z. B. Einfügen, Minimum finden, Löschen) ausgeführt
werden. Im Listing 2.2 (Seite 18) wurde zunächst angenommen, dass die Warteschlange
mit einer einfach verketteten Liste implementiert ist. Damit sind alle
Operationen (außer Löschen) mit dem Aufwand O(1) möglich. Zum Löschen
wird jedoch lineare Zeit (O(n)) benötigt. Während das Finden des Minimums,
mittels einer zusätzlichen Variable, immer in konstanter Zeit ausgeführt werden
kann, ändern sich die Zeitkomplexitäten für die anderen Operationen je
nach verwendeter Datenstruktur. So ist es beispielsweise möglich einen Heap
zu verwenden und damit einen Zeitaufwand für jede Operation von O(log(n))
zu haben. Der Zeitaufwand für den Algorithmus von Dijkstra läge damit bei
O((n + m) · log(n)).
Im Jahre 1987 fanden Fredman und Tarjan eine Möglichkeit Fibonacci-Heaps
sehr effizient im Dijkstra-Algorithmus zu verwenden [16]. Mit einem Fibonacci-
Heap ist das Einfügen in konstanter Zeit und das Löschen in O(log(n)) möglich.
Weiterhin stellten sie für den Fibonacci-Heap verbesserte Laufzeiten in
der amortisierten Laufzeitanalyse fest, wobei der Worst-Case O(log(n)) nur
sehr selten eintrat. Für die meisten Durchläufe im gesamten Dijkstra-Ablauf
sind die Kosten für das Löschen ebenfalls O(1). Nach dieser amortisierten Betrachtungsweise
ist die Laufzeit für den Dijkstra-Algorithmus auf
O(n · log(n) + m)
gesunken. Die Verwendung von Fibonacci-Heaps ist heute die gängigste Methode
um kürzeste Pfade mit dem Dijkstra-Algorithmus zu berechnen.
Die Java-Klasse PriorityQueue verwendet lediglich eine verkettete Liste
(bzw. ein dynamisch wachsendes Array) und ist somit für die Verwendung im
Dijkstra-Algorithmus nicht optimal. Die freie Graphen-Bibliothek JGraphT
[23] bringt jedoch eine Implementierung des Dijkstra-Algorithmus und eine
FibonacciHeap-Klasse mit sich. Der Dijkstra-Algorithmus wurde im Rahmen
© Andreas Redmer — 29. September 2011 41

4. Optimierungen in der Implementierung
dieser Arbeit neu implementiert, weil er sehr einfach ist und weil die Implementierung
von JGraphT nicht unverändert übernommen werden konnte. So
berechnete JGraphT nur den Weg von einem Startknoten zu einem Zielknoten
und bricht die Berechnung dann ab. Wie aber im Abschnitt 1.4 schon erwähnt,
darf der Dijkstra in unserem Projekt nicht abbrechen, sondern muss immer die
kürzesten Wege von einem Startknoten zu allen anderen Knoten finden. Die
Klasse FibonacciHeap wurde jedoch zunächst in diese Arbeit übernommen.
Die Verwendung des Fibonacci-Heaps brachte für die Graphen, die in dieser
Arbeit Verwendung finden, signifikante Unterschiede und wurde deshalb in der
endgültigen Version beibehalten.
4.1.2. Optimierung des Graphen
Unabhängig vom verwendeten Graphenalgorithmus kann der Graph in vielen
Fällen vorher optimiert werden, um die Ausführung des Algorithmus zu beschleunigen.
Dies geschieht durch das Streichen von Kanten. Im Abschnitt
1.3 wurde bereits erklärt, dass die Daten auch teilweise mehrere Kanten zwischen
zwei Knoten aufzeigen, die durchaus von unterschiedlicher Qualität sein
können. Das hängt damit zusammen, dass die Aufzeichnungen von Werten
abhängen, die von unterschiedlichen Stellen im Netzwerk zu unterschiedlichen
Zeiten aufgezeichnet wurden. Der Dijkstra-Algorithmus würde in jedem Fall
die bessere Verbindung wählen und die schlechteren Kanten ignorieren. Dennoch
wird der Algorithmus dadurch langsamer, denn die Anzahl der Kanten m
ist ein Summand in der Komplexität des Algorithmus (O(n · log(n) + m)). Wie
man schnell erkennt, ist die dadurch erreichbare Optimierung nur sehr gering,
da m keinen sehr großen Einfluss auf die Laufzeit hat.
Das Streichen von Knoten ist theoretisch auch möglich um den Dijkstra
zu beschleunigen, jedoch nur wenn es tatsächlich unerreichbare Knoten (also
Knoten zu denen keine Kante führt) gibt. Das ist für die hier aufgezeichneten
Daten nie der Fall, da eine Zeile in der Datenaufzeichnung immer zwei Knoten
und die Kanten zwischen Ihnen repräsentiert. Somit führt zu jedem Knoten
mindestens eine Kante.
Im Rahmen dieser Arbeit wurde das Streichen von Kanten direkt mit in
die Initialisierung des Dijkstra-Algorithmus in Java implementiert. Das Entfernen
der falschen Kanten, kann im Vorfeld auch durch eine SQL-Anweisung
geschehen. Dies wurde jedoch aus den folgenden Gründen nicht getan:
ˆ es dauert bei der Anwendung auf den gesamten Datenbestand sehr lange,
© Andreas Redmer — 29. September 2011 42

4. Optimierungen in der Implementierung
ˆ die Determinierung der ”
gültigen“ Kante (Minimum, Maximum oder
Durchschnitt - vgl. Abschnitt 1.3) bleibt variabel,
ˆ die Originaldaten sollen durch die Analyse nicht verändert werden (die
UDF müssten also mit einer Kopie arbeiten) und
ˆ die UDF sollen auch zukünftig, jederzeit auf unbearbeiteten Daten funktionieren.
Die Performance wurde durch das Streichen der Kanten nur sehr geringfügig
verbessert.
4.1.3. Die ”
General-Gateway-Strategie“
Ein allgemeines Problem ist, dass der Dijkstra-Algorithmus immer k mal ausgeführt
werden muss, wobei k die Anzahl der Gateways ist. Es müssen immer
die kürzesten Wege zu jedem anderen Knoten, ausgehend von jedem einzelnen
Gateway ermittelt und anschließend der kürzeste Weg zu einem Gateway ausgegeben
werden. Derzeit befinden sich vier Gateways im Opennet, jedoch ist
diese Anzahl variabel. Da der Graph für jeden Timestamp konstant vorgegeben
ist, stellt sich die Frage, ob man den Ablauf nicht so modifizieren kann,
dass einmal berechnete Wege nicht immer wieder berechnet werden müssen.
A
1 2
B
M
1
8
G 1 G 2
2
C
1
2
7
1
D
K
13
7
H
6
G 4
10
G 3
3
3
F
E
Abbildung 4.1.: Ein beispielhafter unmodifizierter Graph
Abbildung 4.1 zeigt einen Netzwerkgraphen mit vier Gateways (G 1 , G 2 , G 3
und G 4 ). Der Dijkstra-Algorithmus muss dort vier mal gestartet werden, mit
jeweils einem der Gateways als Startpunkt. Zum Schluss werden alle vier kürzesten
Wege, die pro Knoten zu einem Gateway führen, verglichen und nur
der kürzeste Weg zurückgegeben. Jeder Durchlauf betrachtet den gesamten
© Andreas Redmer — 29. September 2011 43

4. Optimierungen in der Implementierung
Graphen. Unter anderem würde also vier mal festgestellt werden, dass beispielsweise
der kürzeste Weg von C nach E immer die Kosten 2 hat und immer
über D geht. Es werden also vielfach die gleichen Berechnungen ausgeführt.
Im Rahmen dieser Arbeit wurde eine Idee entwickelt, die dieses Problem löst
und somit keine mehrfachen Berechnungen (auf dem selben Graphen) mehr
durchgeführt werden müssen. Grundlage dafür ist die Tatsache, dass die kürzeste
Route zu einem Gateway nie über ein anderes Gateway verläuft. Der
theoretische Idealzustand wäre, wenn sich alle Gateways an einem zentralen
Punkt des Netzwerks befinden, wenn zwischen den Gateways keine weiteren
Knoten wären und die Gateways sich untereinander alle mit einem Kostenaufwand
von 0 erreichen können. In diesem Fall könnte man alle Gateways zu
einem Gateway zusammenfassen und bräuchte nur noch die Wege zu diesem
vereinheitlichten Gateway zu suchen.
A
1 2
B
M
1
8
0
G 1 G 2
2
C
1
2
7
0
0
1
D
K
13
7
H
6
G 4
0
G 3
3
3
F
E
Abbildung 4.2.: Ein Netzwerkgraph mit generalisiertem Gateway
In der Praxis ist das natürlich nicht der Fall, da die Gateways beliebig im
Netzwerk verteilt sein können. Da jedoch bereits festgestellt wurde, dass die
direkten Wege zwischen den Gateways irrelevant sind (da sie nie zu einem der
gesuchten kürzesten Pfade gehören werden und da für Gateways selbst auch
kein Pfad gesucht werden muss), können die irrelevanten Wege durch Nullkanten
9 ersetzt werden. Dabei ist es egal, ob vorher eine direkte oder indirekte
Verbindung zwischen den Gateways existiert hat oder nicht. Das bedeutet,
dass das gesamte Netzwerk auch aus mehreren getrennten Teilnetzwerken be-
9 Exakt wäre hier die Bezeichnung Nullelementkante, was bedeutet, dass jeweils das Nullelement
aus der Metrik als Kantengewicht verwendet wird. Bei einer multiplikativen Metrik
wäre es beispielsweise eine Kante mit dem Kostenfaktor 1.
© Andreas Redmer — 29. September 2011 44

4. Optimierungen in der Implementierung
stehen kann, wobei in jedem Teilnetzwerk mindestens ein Gateway existiert.
Es ist auch egal wie viele Nullkanten eingefügt werden, allerdings muss jedes
Gateway jedes andere Gateway mit den Kosten 0 erreichen. In Abbildung 4.2
wurden diese Nullkanten hinzugefügt und das generalisierte (zusammengefasste)
Gateway mit einer gestrichelten Linie gekennzeichnet.
Mit dem neu entstandenen Graph wird nun wie folgt verfahren:
1. Wähle einen beliebiges Gateway als Startknoten.
2. Führe damit den Dijkstra-Algorithmus einmal aus.
3. Streiche bei der Rückgabe des Ergebnisses alle Wege über Nullkanten 10 .
Beispielsweise wählt man in Abbildung 4.2 G 1 als Startknoten. Ausgabe ist
zunächst der kürzeste Weg von jedem Knoten zu G 1 . So erhält man unter
anderem die Route
0 2
G 1 −→ G 2 −→ C −→ 1
D
zum Knoten D. Am Anfang jeder Route können sich nun durchaus mehrere
Gateways befinden, die über Nullwege zum gesuchten Gateway führen. Alle
Nullwege und die davor liegenden Gateways müssen vor der Ausgabe gestrichen
werden, da dies die künstlich erzeugten Wege sind. Als Ergebnis erhält man
dann die Route
2
G 2 −→ C −→ 1
D
zum Knoten D. Dies ist der kürzeste Weg vom Knoten D zu einem Gateway.
Diese Strategie soll im folgenden General-Gateway-Strategie genannt werden
und wurde auch an den entsprechenden Stellen im Quelltext so benannt.
Die Strategie liefert das gleiche Ergebnis, wie die Ausführung von vier Dijkstra-
Durchläufen und der anschließenden Auswahl des nächstgelegenen Gateways.
Zwar muss der kürzeste Weg nicht immer eindeutig bestimmt sein, aber es ist in
realen Netzwerken unwahrscheinlich, dass zwei Gateways den selben und besten
Weg ins Internet bieten. Wenn dies auftreten würde, wären die Ergebnisse
nicht falsch, aber die Strategien nicht mehr vergleichbar. Testweise wurden beide
Strategien in dieser Arbeit für den gesamten Datenbestand gegeneinander
getestet und es wurden keine Unterschiede festgestellt 11 .
Aus Sicht der Komplexitätstheorie verbessert die General-Gateway-Strategie
den Ablauf um einen konstanten Faktor (im Beispiel um den Faktor 4). Der
Teil der UDF, der für die tatsächliche Ausführung des Dijkstra-Algorithmus
zuständig ist, wird also um ein vielfaches schneller ausgeführt. Im Rostocker
10 Über alle Nullkanten, die sich am Anfang einer Route zwischen zwei Gateways befinden,
falls vorher schon Nullkanten im Graph vorhanden waren.
11 Die SQL-Anweisung dafür ist im Anhang A.7 aufgeführt.
© Andreas Redmer — 29. September 2011 45

4. Optimierungen in der Implementierung
Opennet, in dem es derzeit vier Gateways und etwa 200 Teilnehmer gibt, ist die
Veränderung noch recht klein. Für gleichartige Netzwerke in Großstädten, mit
einer höheren Anzahl an Gateways, wäre die Zeitersparnis für die Berechnung
enorm.
4.1.4. Nutzung stabiler Teilergebnisse bei ähnlichen
Graphen
Die General-Gateway-Strategie beschrieb die Optimierung der Berechnung auf
einem unveränderten Graph, die ausgeführt wird wenn die Routen für einen
Timestamp berechnet werden. In der Praxis kommt es vor, dass die Routen
für mehrere Timestamps berechnet werden sollen. Natürlich könnten alle Routen
vorberechnet und dann in der Datenbank abgespeichert werden. Damit
wären sie stets sehr schnell erhalten. Wenn man die Zeit für Vorberechnung
ignoriert, erhält man eine sehr schnelle Ermittlung der Routen. Diese Art der
Performanceoptimierung soll im Rahmen dieser Arbeit jedoch nicht durchgeführt
werden, weil man sie ebenso mit allen bestehenden Verfahren hätte
durchführen können. Der Zeitaufwand würde dabei reduziert werden, indem
der Speicheraufwand stark erhöht wird.
Da die Datenaufzeichnung einmal pro Minute erfolgt, kann man annehmen,
dass aufeinander folgende Graphen sehr ähnlich oder sogar gleich sind. In diesem
Fall wäre es nur nötig, das Ergebnis einer Berechnung vollständig und
danach jeweils nur den Unterschied zur vorherigen Berechnung zu speichern.
Im folgenden wird erklärt, wie die Ausgabe des Dijkstra-Algorithmus effektiv
gespeichert werden kann.
Die Ausgabe des Dijkstra-Algorithmus umfasst die Menge (D) von Tupeln,
die mindestens 12 je einen Knoten (v) und jeweils den Vorgängerknoten (v p ) auf
dem kürzesten Pfad zum nächsten Gateway enthalten.
t = (v, v p )
D = {t|v p ist Vorgänger von v}
Die Menge D hätte immer n Elemente abzüglich der Anzahl der Gateways,
wobei n die Anzahl der Knoten im Graph ist. Sei x die Anzahl der insgesamt
12 Das Speichern zusätzlicher Informationen (wie z. B. Weglänge) ist optional.
© Andreas Redmer — 29. September 2011 46

4. Optimierungen in der Implementierung
aufgezeichneten Timestamps und sei D t das Ergebnis der Berechnung zum
Zeitpunkt t, dann sind alle Berechnungsergebnisse mit der Menge:
{D 0 , D 1 , D 2 , . . . , D x } ⊆ E
wobei: E = {alle möglichen D}
erfasst. Dabei beschreibt t die Nummer eines Timestamps. Da über den Timestamps
eine strenge Totalordnung definierbar ist, lassen sie sich hintereinander
aufzählen.
D a D b M P
Abbildung 4.3.: Venn-Diagramm für zwei Dijkstra-Ergebnismengen
In Abbildung 4.3 ist ein Venn-Diagramm zweier Ergebnismengen dargestellt
um die folgenden Schritte anschaulicher zu machen. Um die Ergebnismenge D a
in eine andere Ergebnismenge (D b ) umzuwandeln, sind zwei Schritte notwendig.
Es muss eine gewisse Teilmenge (M) von Tupeln entfernt und eine gewisse
weitere Menge (P ) hinzugefügt werden.
M = D a \ D b
P = D b \ D a
Wobei in jedem Fall M ∈ E und P ∈ E gilt. Der für diese Arbeit sehr wichtige
algebraische Unterschied zwischen zwei Ergebnissen lässt sich dann als
Tupel u speichern
u = (M, P )
und die Menge aller möglichen Unterschiede (U) lässt sich ebenfalls definieren
U = {alle möglichen u}.
Um den algebraischen Unterschied zwischen zwei Ergebnismengen zu berechnen,
können die Formeln für die Elemente M und P direkt angewendet
werden. Die Speicherung des algebraischen Unterschieds ist somit vollständig
definiert. Für die Speicherung in einer relationalen Datenbank kann eine Relati-
© Andreas Redmer — 29. September 2011 47

4. Optimierungen in der Implementierung
on (Tabelle) angelegt werden, die zu zwei Timestamps jeweils den Unterschied
abspeichert. Diese Relation würde dann Tupel der Form
speichern.
v = (t a , t b , u)
Da nicht alle Ergebnismengen einen Vorgänger haben (z. B. ist t 0 der erste
je aufgezeichnete Timestamp), sei zusätzlich noch bemerkt, dass sich auch eine
vollständige Ergebnismenge mit einem eben definierten algebraischen Unterschied
darstellen lässt. Dies geschieht indem die vollständige Menge auf die
leere Menge aufaddiert wird. Also gilt:
M = ∅
P = D 0
und weiterhin gilt u = (M, P ). In der Datenbank kann die Tatsache, dass
es keinen Vorgänger gibt, gespeichert werden indem der NULL-Wert für den
ersten Timestamp abgespeichert wird; so speichert man für t 0 beispielsweise
v = (NULL, t 0 , u).
Weiterhin lässt sich, wie folgt, auch eine Funktion diff auf der Menge E
definieren, die durch das Aufaddieren eines Unterschieds (M, P ) ein neues Element
in der Menge E erzeugt:
diff : E × U → E, (D a , (M, P )) ↦→ (D a \ M) ∪ P
diff hat folgende Umkehrfunktion:
diff −1 : E × U → E, (D b , (M, P )) ↦→ (D b \ P ) ∪ M
und ist assoziativ. Die algebraische Struktur (E, diff) ist keine algebraische
Halbgruppe, da diff keine innere Verknüpfung sondern eine Rechtsoperation
von U auf E ist.
Die nun eingeführte Algebra wurde im Rahmen dieser Arbeit im PostgreSQL
DBMS implementiert. Die Definition neuer Datentypen erfolgt in PostgreSQL
mit CREATE TYPE aus bereits bestehenden Datentypen, Tupeln von Datentypen
und Arrays von Datentypen. Damit lässt sich jede zuvor angegebene Form
von Mengen oder Tupeln implementieren. Mit CREATE FUNCTION lässt sich die
Funktion diff sehr einfach als PL/SQL UDF umsetzen, da die Mengenoperationen
(UNION (∪), INTERSECT (∩) und EXCEPT (\)) bereits im SQL-Server
enthalten sind. Optional kann mit CREATE OPERATOR eine Funktion direkt als
© Andreas Redmer — 29. September 2011 48

4. Optimierungen in der Implementierung
Operator für einen Datentyp definiert werden, um die Usability der Datentypen
zu erhöhen. Eine vollständige Implementierung dieser Algebra ist im Anhang
A.8 zu finden.
Zunächst wurde die trivialste Version implementiert, bei der nur der erste
verfügbare Timestamp (t 0 ) vollständig abgespeichert wurde. Wie man sich
leicht vorstellen kann, dauert die Berechnung relativ lange. Beispielsweise sind
nach nur drei Tagen (4320 Minuten) in der Aufzeichnung schon 4320 neue
Timestamps gespeichert worden. Es muss also 4319 mal die diff Funktion
aufgerufen werden, um die Routen zum Zeitpunkt t 4320 zu erhalten. Dies ist
wesentlich langsamer als die bis dato bereits erreichten Geschwindigkeiten der
Berechnung. Es ist also nötig, mehrere Ergebnisse vollständig abzuspeichern
um einen guten Kompromiss zwischen aufgewandtem Speicher und benötigter
Rechenzeit zur Rekonstruktion eines Ergebnisses zu finden. Beispielsweise
könnte man jedes zehnte oder jedes hundertste Ergebnis vollständig speichern
und danach jeweils nur die Unterschiede zu den Nachfolgern. Ebenso ist es
denkbar, dass das Ergebnis des ersten Timestamps eines Tages oder einer Stunde
komplett aufgezeichnet wird und alle Nachfolger als Unterschiede.
00:00 Uhr 00:01 Uhr 00:02 Uhr
. . . . . .
00:09 Uhr
00:10 Uhr 00:11 Uhr 00:12 Uhr
. . . . . .
00:19 Uhr
Abbildung 4.4.: Schematische Darstellung - eine vollständige Speicherung alle
10 Minuten
Eine einfache Analyse der Daten hat ergeben, dass sich die Routen sehr stark
ändern. Im Durchschnitt verändern sich 10% der Routen von einem Timestamp
zum Nächsten. Diese Veränderungsrate war höher als erwartet und es stellte
sich die Frage, ob es damit überhaupt Sinn macht diese Strategie anzuwenden.
Letztlich bedeutet dies, dass das Ergebnis jedes zehnten Timestamps vollständig
gespeichert werden muss. Abbildung 4.4 stellt dieses Vorgehen schematisch
dar. Dabei kann n(t) = t + 1min als Nachfolgefunktion betrachtet werden,
die beschreibt wie der nachfolgende Timestamp zu bestimmen ist. Die Anzahl
der mit Unterschieden zu speichernden Timestamps (in diesem Fall 10) kann
als Zählwert betrachtet werden.
Wie man sich leicht vorstellen kann, könnte eine veränderte Nachfolgefunktion
die Unterschiede deutlich reduzieren. Beispielsweise könnten die Unterschiede
zwischen den geltenden Routen zwischen Montag 00:00 Uhr und Dienstag
00:00 Uhr sehr gering sein. Dies ist in Abbildung 4.5 schematisch dargestellt,
© Andreas Redmer — 29. September 2011 49

4. Optimierungen in der Implementierung
Montag
00:00 Uhr
00:01 Uhr 00:02 Uhr
. . . . . .
23:59 Uhr
Dienstag
00:10 Uhr
00:11 Uhr 00:12 Uhr
. . . . . .
23:59 Uhr
Abbildung 4.5.: Schematische Darstellung - eine vollständige Speicherung pro
Minute im Wochentag
wobei die Nachfolgefunktion dann n(t) = t + 24h wäre und der Zählwert vielleicht
wesentlich höher (z. B. 365) gesetzt werden könnte. Es sind noch viele
weitere Möglichkeiten denkbar, wie zum Beispiel, dass der Unterschied zwischen
erstem Montag 00:00 Uhr und allen weiteren Montagen 00:00 Uhr gespeichert
wird (also Nachfolgefunktion n(t) = t + 7d und Zählwert z. B. 52).
Im Rahmen dieser Arbeit konnte keine sinnvolle Kombination von Nachfolgefunktion
und Zählwert gefunden werden, die die Performance erhöht und
vergleichsweise wenig Speicherplatz verbraucht.
Der Vorteil dieses Verfahrens ist also, dass es unter gewissen Umständen und
je nach zur Verfügung stehendem Speicherplatz schneller werden könnte. Die
Nachteile sind jedoch:
1. Es ist zunächst eine Datenanalyse nötig, um die geringsten Unterschiede
zwischen den berechneten Routen zu finden. Dabei ist die effiziente
Durchführung der Datenanalyse eigentlich eines der Ziele (und keine Voraussetzung)
dieser Arbeit (vgl. Abschnitt 1.4 - Problemklasse B).
2. Es ist eine sehr aufwändige Implementierung erforderlich, da die Daten
nicht vollständig und durchaus fehlerhaft sind. So müssen sehr viele Ausnahmen
programmiert werden, die diese Situationen behandeln. Die einfachste
Form der Implementierung wäre, als Nachfolgefunktion generell
einfach den nächsten verfügbaren Timestamp zu verwenden, was jedoch
zu ineffizient ist.
3. Da nur die unmittelbaren Ergebnisse des Dijkstra-Algorithmus gespeichert
werden, sind die Ergebnisse nur für die Problemklasse B verwendbar.
Für die anderen in Abschnitt 1.4 genannten Problemklassen wäre
diese Optimierung generell nicht verfügbar.
Da die Nachteile stark überwiegen, wurde diese Form der Optimierung in
der abschließenden Implementierung nicht eingesetzt.
© Andreas Redmer — 29. September 2011 50

4. Optimierungen in der Implementierung
4.2. Performanceoptimierter Programmierstil
Unabhängig von der praktisch eingesetzten Hardware und von der theoretischen
Komplexität eines Algorithmus, lässt sich die Geschwindigkeit eines
Programms durch den Stil der Programmierung erhöhen. In diesem Kapitel,
werden die Techniken erklärt, die in den UDF eingesetzt wurden um die Performance
zu erhöhen. Dabei wird insbesondere die Übersetzung des Programms
von Hochsprache in Maschinencode betrachtet (die durch den Compiler durchgeführt
wird), um einzelne elementare Rechenoperationen auf der CPU einzusparen.
4.2.1. Quellcodedesign
Da Java eine objektorientierte Programmiersprache ist, wurden die Java-UDF
im objektorientierten Programmierparadigma erstellt. Die großen Vorteile der
objektorientierten Programmierung, im Vergleich mit der strukturierten Programmierung,
sind die bessere Lesbarkeit, Erweiterbarkeit und Wiederverwendbarkeit
des Quelltextes. Grundidee ist dabei, dass alle Variablen Objekte
sind und somit alle Daten in Objekte verpackt werden. Beispielsweise wird
aus dem Datentyp int in der strukturierten Programmiersprache C, die Klasse
Integer in der objektorientierten Sprache Java. Die Klasse hat lediglich
den Unterschied, dass das eigentliche Datum nicht mehr von außerhalb der
Klasse gelesen oder geschrieben wird, sondern durch Accessor- und Mutator-
Methoden 13 auf den Ganzzahlwert zugegriffen wird. Man spricht dabei von der
Datenkapselung. In Java gibt es zur Vereinfachung auch weiterhin den Datentyp
int. Somit ist Java keine reine objektorientierte Sprache. Der lesende und
schreibende Zugriff in der Programmiersprache Assembler (also im Maschinencode)
ist bei einer strukturierten Sprache nur ein Zugriff auf ein Register in
der CPU oder ein Speicherzugriff. Während der Aufruf einer Funktion (wie
Accessor oder Mutator) bekanntlich immer mit einem PUSH auf den Stack beginnt,
damit die Register für die lokalen Variablen innerhalb der CPU genutzt
werden können, und mit einem POP endet um das Programm nach dem Funktionsaufruf
weiter laufen zu lassen.
Durch moderne Methoden im Compilerbau werden objektorientierte Programme
nicht automatisch langsamer als strukturierte. Ein Compiler würde
triviale Accessor- und Mutator-Methoden erkennen und sie ebenso effizient umsetzen.
Dennoch können die Zugriffsmethoden auch deutlich komplexer sein.
Bei einem gekapselten Ganzzahlwert könnte beispielsweise auf einen gültigen
13 auch ”
Getter“ und ”
Setter“ genannt
© Andreas Redmer — 29. September 2011 51

4. Optimierungen in der Implementierung
Wertebereich geprüft werden um keine ungültigen Daten zu speichern. Eine
derartige Gültigkeitsprüfung kann eine einfache mathematische Vergleichsoperation
(wie z. B. , =, ≠, . . . ) oder aber auch ein komplexer Algorithmus
sein, der ausgeführt wird. Dies ist stark von den Daten abhängig. In jedem
Fall würde der Zugriff auf die Daten um mindestens eine Operation auf der
CPU erhöht. Da moderne CPUs durchaus 2 Milliarden FLOPS 14 berechnen
und selbst auch durch viele Techniken (wie z. B. Pipelining) optimiert sind,
spielt es meist keine Rolle ob eine oder zwei Rechenoperationen ausgeführt
werden. Bei dem vorliegenden Problem, bei dem die Ermittlung aller Routen
zu allen aufgezeichneten Zeitpunkten im Mesh-Netzwerk, mehrere Wochen
dauerte, ist es jedoch durchaus sinnvoll diese Art der Performanceoptimierung
zu betrachten.
Für diese Art der Optimierung ist es nötig, dass man die Optimierungen
die der Compiler durchführt kennt und möglichst genau absehen kann, wie
das Programm später in Maschinencode aussehen wird. Idealerweise benutzt
man keine vorgefertigten abstrakten Datentypen (wie z. B. Stack, Queue oder
Liste), es sei denn sie sind quelloffen oder man kann zumindest im Debugger
ihre genaue Funktionsweise einsehen. Die meisten dieser vorgefertigten Datentypen
sind für den allgemeinen Fall optimiert, sie können also für sehr spezielle
Fälle ungeeignet sein. Somit ist eine eigene Implementierung empfehlenswert,
wenn dabei intensiv darauf geachtet wird, dass möglichst wenig Operationen
ausgeführt werden. Eine gute Einführung und einfache Implementierungen von
abstrakten Datentypen finden sich in [14].
In der zu dieser Arbeit gehörenden Implementation wurde der Dijkstra-
Algorithmus auf möglichst primitive Art umgesetzt. Es wurden nur die Datentypen
int und float eingesetzt und wenn nötig Arrays davon gebildet. Die
Klasse Array und die Wrapper-Klassen werden nach Möglichkeit vermieden.
Dies gilt insbesondere für die inneren Schleifen, die im Dijkstra-Algorithmus
ablaufen, und teilweise auch für die Vor- und Nachbereitung der Daten.
Wie man sich leicht vorstellen kann, wurde dadurch der Entwicklungsaufwand
erhöht und die Lesbarkeit und Wiederverwendbarkeit des Quelltextes
reduziert. Tatsächlich ist es immer ein Problem, einen guten Kompromiss zwischen
Lesbarkeit und Performance zu finden. Um die Erweiterbarkeit der Java-
UDF zu gewährleisten, wurde der Quelltext nur an den nötigsten Stellen sehr
stark optimiert. Beim Import der Daten aus der Datenbank in den Algorithmus
und beim Aufbereiten der Ausgabe für die Rückgabe an das DBMS, wurden
14 Floating point operations per second - die Anzahl der Fließkomma-Rechenoperationen die
eine CPU pro Sekunde ausführen kann
© Andreas Redmer — 29. September 2011 52

4. Optimierungen in der Implementierung
wieder vermehrt Java-Klassen verwendet, da diese Abschnitte auch vergleichsweise
selten ausgeführt werden.
4.2.2. Zusammenhang zur algorithmischen Komplexität
Die Verwendung des zuvor beschriebenen performanceoptimierten Programmierstils
reduziert die algorithmische Komplexität um einen konstanten Faktor.
Konstante Faktoren werden in der Komplexitätsbetrachtung meist weggelassen,
da sie die Komplexitätsklasse nicht ändern und für große Variablen
(also sehr lange laufende Programme) meist nicht relevant sind.
Wenn man beispielsweise auf eine große Anzahl Ganzzahlwerte mehrfach
lesend zugreifen muss, macht es keinen Unterschied, ob man diese in einem
Array oder in einer Hashmap verwaltet. Beide haben sehr geringe Zeiten (O(1)
und O(log(n))) für den Zugriff auf ein Element 15 . Allerdings ist eine Array-
Zugriffsfunktion im Maschinencode lediglich eine Addition, welche die Speicheradresse
des gesuchten Wertes zurück gibt, während eine Hashfunktion
durchaus aus mehreren Additionen besteht. Somit ist der konstante Faktor
bei einer Hashfunktion deutlich größer.
Bei der Verwendung von vorgefertigten Java-Klassen zur Verwaltung von
Listen, Arrays oder Maps, ist darauf zu achten, wie diese Klasse intern funktioniert
und ob sie den gewünschten Ansprüchen entspricht. So ist z. B. die
Java-Klasse Vector eine Mischung aus doppelt verketteter Liste und Array,
die dynamisch je nach Gebrauch um eine variable Anzahl von freien Speicherplätzen
anwachsen kann. Dies ist beim Debugging der Klasse erkennbar. Auch
eine vorgefertigte Array-Klasse kann intern mit doppelt verketteten Listen
oder Hashmaps implementiert sein. Die meisten Klassen die das Java-Interface
Map oder Collection implementieren, lassen sich durch einen parametrisierten
Konstruktoraufruf auf eine bestimmte Größe initialisieren, damit sie zur
Laufzeit möglichst nicht vergrößert werden müssen.
Die IP-Adressen die jeden Knoten im Opennet-Netzwerk eindeutig identifizieren,
kommen als Zeichenkette im Java Programm an. Dort werden sie mittels
einer Java-Hashmap auf ganze Zahlen abgebildet. Die UDF kann also mit beliebigen
Knotennamen arbeiten, während der Dijkstra intern nur mit Ganzzahlen
arbeitet. Derzeit gibt es etwa 200 aktive Knoten im Opennet. Jedoch wurde
die Java-Hashmap mit der Größe 500 initialisiert, damit sie auch in zukünftigen
Jahren nicht zur Laufzeit wachsen muss. Ein deutlicher Unterschied zur Implementierung
von Mundt und Vetterick [22] ist, dass die Hashmap nur noch
15 Dies gilt nur, wenn die in der Hashmap verwendete Hashfunktion effizient berechenbar
ist.
© Andreas Redmer — 29. September 2011 53

4. Optimierungen in der Implementierung
vor und nach dem Dijkstra-Algorithmus, jedoch nicht mehr während seiner
Ausführung verwendet wird.
Generell lässt sich hier auch gut erkennen, dass im Rahmen dieser Arbeit
nicht auf Speicherplatz sondern nur auf Zeit optimiert wurde. Bei derartig kleinen
Graphen (n ≈ 200) braucht auf die Art der Verwaltung im Arbeitsspeicher,
bei heutigen Computern, nicht geachtet zu werden.
Wie bereits im Abschnitt 4.1.1 erklärt wurde die Klasse FibonacciHeap aus
dem JGraphT-Framework übernommen. Die Klasse wurde jedoch im Zuge dieser
Optimierung nochmal komplett überarbeitet, da das Framework ebenfalls
für allgemeine Graphen optimiert ist. So konnte jeder enthaltene Knoten ein
beliebiges Objekt sein, zu dem diverse Zusatzinformationen gespeichert wurden.
Dies wurde alles auf den Datentyp int reduziert und alle in dieser Klasse
verwendeten vorgefertigten Java-Klassen entfernt. Die neue Klasse wurde
FastFibonacciHeap genannt. Die durch diese Optimierung erreichte Zeitersparnis
war sehr gering. Wie zu erwarten war, brachte diese Optimierung den
kleinsten Teil der Zeitersparnisse ein.
4.2.3. Design Pattern
Eine Besonderheit bei der modernen Programmierung mit objektorientierten
Programmiersprachen ist die Verwendung von Design Pattern (engl. für Entwurfsmuster).
Softwaretechniker kennen eine ganze Reihe von Design Pattern,
welche die Wiederverwendbarkeit und Veränderbarkeit von Quelltext stark erhöhen.
Auf Design Pattern wurde im Rahmen dieser Arbeit weitestgehend
verzichtet.
Insbesondere solche Pattern wie Factory oder Strategy wurden bewusst weggelassen,
da sie zur Laufzeit eine Zeichenkette auslesen, um danach dann eine
bestimmte Klasse zu laden oder einen bestimmten Algorithmus auszuführen.
Diese Pattern sind vergleichsweise langsam. Normalerweise ist dieser Geschwindigkeitsunterschied
nicht relevant, aber in der performanceoptimierten Programmierung
sollte nach Möglichkeit darauf verzichtet werden. Factory hätte
z. B. dafür benutzt werden können, die Klasse für den Fibonacci-Heap dynamisch
auszutauschen und mit Strategy hätte man sich zur Laufzeit dynamisch
für verschiedene Graphenalgorithmen entscheiden können.
Ein Nachteil der hier entstandenen Implementierung ist, dass die Metrik
nicht problemlos austauschbar ist. Die Metrik zur Berechnung des Abstands
zwischen zwei Knoten ist fest in den Algorithmus einprogrammiert. Ein austauschbarer
Komparator oder ein Strategy-Pattern mit wechselbaren Metriken
hätten hier Abhilfe geschafft wurden jedoch aus Performancegründen nicht ein-
© Andreas Redmer — 29. September 2011 54

4. Optimierungen in der Implementierung
gesetzt. Sollte sich die verwendete Metrik in Zukunft mehrmals ändern oder
sogar zwangsweise variabel sein, sollte dies korrigiert werden. Der dadurch zu
erwartende Performanceverlust ist sehr gering.
4.2.4. Implementierung von ”
unendlich“
In Graphenalgorithmen werden Wege, von denen man noch nicht weiß ob sie
existieren oder wie lang sie sind, mit ∞ (unendlich) beschrieben. Dabei kann ∞
im Computer nicht als Wert gespeichert werden. Man ersetzt ∞ also mit einem
zuvor definierten Wert. Wenn der Algorithmus sehr häufig ausgeführt werden
soll, kann die Wahl dieses Wertes die Performance geringfügig beeinflussen. Es
gibt die folgenden drei Möglichkeiten:
1. ein dynamisch berechneter hoher Wert (z. B. 2 · ∑m
i=0
w(i); die doppelte
Summe aller Kantengewichte),
2. ein Wert außerhalb des Wertebereichs (z. B. NULL, 0, -1) oder
3. ein konstanter sehr großer Wert (z. B. MAX_INT, MAX_FLOAT).
Die erste Möglichkeit ist, dass der Wert für jeden speziellen Graphen genau
ermittelt wird und somit theoretisch immer funktioniert. Der Nachteil ist der
Zeitaufwand für die Berechnung des hohen Wertes. Die zweite Variante setzt
als Maximalwert einen Wert der niemals eine Weglänge sein kann, da er außerhalb
des Wertebereiches liegt. Wenn es nur positive Kantengewichte im Graph
gibt bietet sich −1 an. In PL/SQL UDF und objektorientierten Programmiersprachen
kann auch der Wert NULL verwendet werden. Der Nachteil hierbei ist,
dass die min- und max-Funktionen zum Finden des kleineren/größeren von zwei
Werten so angepasst werden müssen, dass diese die vorgenannten Werte immer
als größer betrachten. Diese Variante wurde bei der Implementierung des
Floyd-Warshall-Algorithmus in einer SQL UDF (vgl. Anhang A.5) verwendet.
Dadurch wird die min-Funktion jedoch sehr langsam, was die Ausführung des
Algorithmus stark verlangsamt. Die dritte Variante kann eingesetzt werden,
wenn genaue Informationen über den Graphen vorhanden sind, die als fixe
Vorbedingung vorausgesetzt werden können. Für die in dieser Arbeit verwendeten
Graphen werden die Kantengewichte als float Werte gespeichert und es
steht fest, dass sie niemals den für float maximal größen Wert (MAX_FLOAT)
erreichen werden. Diese Möglichkeit ist die schnellste in der Ausführung und
wurde in der Implementation verwendet.
Die durch diese Optimierung erreichte Performanceerhöhung ist relativ zum
betrachteten Vergleichswert. Verglichen mit einem Wert außerhalb des Wertebereiches
und angepasster min-Funktion (also Variante zwei) sind eins und
© Andreas Redmer — 29. September 2011 55

4. Optimierungen in der Implementierung
drei deutlich schneller. Zwischen Variante eins und drei gibt es nur große
Unterschiede, wenn sehr viele Graphenalgorithmen hintereinander ausgeführt
werden sollen.
4.2.5. Adjazenzmatrix statt Adjazenzliste
Die zwei wesentlichen Formen um einen Graphen im Computer zu speichern
sind Adjazenzmatrix und Adjazenzliste. Eine Adjazenzmatrix ist ein zweidimensionales
Array, welches je eine Spalte und eine Zeile für jeden Knoten hat.
Die eingetragenen Werte repräsentieren das Kantengewicht und die Angabe
ob überhaupt eine Kante zwischen den beiden Knoten vorhanden ist. Die Adjazenzliste
ist eine zweidimensionale einfach verkettete Liste (oder ein Array
von Listen), die für jeden vorhandenen Knoten eine Liste von Nachbarn und
zugehörigem Kantengewicht speichert. Im Allgemeinen ist die Adjazenzmatrix
größer und schneller und die Adjazenzliste langsamer und platzsparender. Bei
sehr großen Graphen ist es nicht mehr möglich eine Adjazenzmatrix zu speichern,
weil sie eine quadratische Speicherkomplexität hat (O(n 2 )). Dafür ist
der Zugriff auf ein spezielles Element bei einer Adjazenzliste langsamer, da
zunächst über die Knoten iteriert werden muss, die zuerst in der Liste stehen.
Im Rahmen dieser Arbeit wurde nur die Adjazenzmatrix zum Speichern der
Graphen eingesetzt. Dies geschah insbesondere weil die ersten Implementierungen
noch den einfachen Floyd-Warshall-Algorithmus verwendeten und dieser
den Graphen in einer Adjazenzmatrix voraussetzt. Ein weiterer Grund ist die
einfache Erstellung bzw. der einfache Import der Daten aus der Datenbank
in den Algorithmus und die Tatsache, dass intern theoretisch der Graphenalgorithmus
dynamisch gewechselt werden kann. Letztlich führte die Tatsache,
dass die Graphen recht klein sind ebenfalls dazu, dass keine Adjazenzliste eingesetzt
werden musste. Das Speichern von n 2 float-Werten (für n ≈ 200) ist
bei den heutigen Speichergrößen kein Problem.
Der Performanceunterschied, der durch diese Optimierung erreicht wird ist
relativ hoch, hängt jedoch davon ab wie die Adjazenzliste implementiert ist,
die man zum Vergleich heranzieht. In der Implementierung von Mundt und
Vetterick [22] wurden alle Knoten und auch jeweils deren Nachbarschaft in
einer sehr effizienten Baumstruktur (Java-Klasse TreeMap) verwaltet. Jedoch
wurde zur Bestimmung aller Nachbarn zu einem Knoten eine Funktion mit
der Komplexität o(m) entwickelt, die die Effizienz einer normalen Adjazenzliste
hat. Sehr langsame und immer wiederkehrende Zugriffe auf den Graphen
verlangsamen den Algorithmus stark.
© Andreas Redmer — 29. September 2011 56

4. Optimierungen in der Implementierung
4.3. Parallelisierung
Eine weitere Form der Beschleunigung in der Ausführung des Algorithmus von
Dijkstra ist die Parallelisierung. Dabei gibt es zwei verschiedene Arten:
ˆ die Parallelisierung des Dijkstra-Algorithmus in sich, also die parallele
Ausführung auf mehreren Rechnereinheiten um die Routen für einen
Graph schneller zu erhalten und
ˆ die Parallelisierung mehrerer Dijkstra-Algorithmen, die die Routen für
verschiedene Graphen parallel berechnen.
Diese beiden Formen wurden im Rahmen dieser Arbeit auf verschiedene
Weisen eingesetzt, die in den folgenden beiden Abschnitten erklärt werden.
4.3.1. Multithreaded Dijkstra
Da die Computer, die zum Testen der Implementierung zu dieser Arbeit, über
Multicore-Prozessoren verfügten, entstand die Idee, diese zu parallelen Verarbeitung
zu nutzen. Die Anzahl der zur Verfügung stehenden CPU-Kerne soll
im folgenden c sein. Einige Teile des Dijkstra-Algorithmus lassen sich parallelisieren,
indem an den entsprechenden Stellen c Threads ausgeführt werden.
Java bringt eine API zur einfachen Implementierung von Threads mit sich.
Dabei werden Objekte der Klasse Thread erzeugt und mit der Methode run()
gestartet.
Im folgenden soll die Parallelisierung des Algorithmus in mehrere Threads
erklärt werden. Für die bessere Übersichtlichkeit wird zunächst nochmals der
Pseudocode für den Dijkstra-Algorithmus aus Kapitel 2.3.1 (Listing 2.2) mit
einigen Ergänzungen gegeben.
1 FUNCTION dijkstra() {
2 init()
3 WHILE Q ≠ ∅ {
4 u := min(Q) // Möglichkeit zur Parallelisierung hier
5 Q := Q \ {u}
6 FOR EACH NEIGHBOUR v OF u { // Möglichkeit zur Parallelisierung hier
7 IF v ∈ Q THEN update(u, v)
8 }
9 }
10 }
Listing 4.1: Dijkstra-Algorithmus in Pseudocode mit Möglichkeiten zur
Parallelisierung
© Andreas Redmer — 29. September 2011 57

4. Optimierungen in der Implementierung
Im Listing 4.1 wurden zwei Kommentare eingefügt, welche die Stellen kennzeichnen,
an denen eine parallele Ausführung möglich ist. In [10] beschreiben
Driscoll et al. eine mögliche Einteilung der Menge Q (die Menge der noch nicht
verarbeiteten Knoten) in c Teile. Jedem Prozessor wird dann einer dieser Teile
zur Verarbeitung zugeteilt. Dabei findet jeder Prozess das für sich lokale Minimum.
Mit einer einfachen Methode kann dann mit dem Zeitaufwand log(c)
das globale Minimum gefunden werden. Dabei werden alle Prozessoren binärbaumförmig
angeordnet. Dann gibt jeder Prozessor sein lokales Minimum an
seinen Eltern-Prozessor weiter. Jeder Eltern-Prozessor ermittelt wiederum das
Minimum von den ihm zugereichten Werten seiner Kind-Prozessoren. Das ganze
wird so lange weitergeführt, bis der Prozessor erreicht wird, der im Baum
ganz oben steht. Das von ihm ermittelte lokale Minimum ist das globale Minimum.
Die zweite Möglichkeit zur Parallelisierung ist, die update-Funktion auf
die einzelnen Kerne aufzuteilen. Dabei würde also die Menge der Nachbarn des
aktuellen Knotens in c Teile zerlegt werden.
Wie jetzt schon leicht zu erkennen ist, ist diese Methode insbesondere für
sehr große Graphen und für eine hohe Anzahl an Prozessoren geeignet. Die
verwendeten Testsysteme verfügen jedoch nur über zwei bzw. vier CPU-Kerne
und die Graphen sind mit n ≈ 200 relativ klein. Diese Methode der parallelisierten
Ermittlung des Minimums ist für die Implementierung in dieser Arbeit
auch nicht relevant, da das Minimum immer schon beim Einfügen in einer
gesonderten Variable gespeichert wird und somit immer in O(1) Zeit abgefragt
werden kann. Der dafür zusätzliche Aufwand beim Einfügen ist ebenfalls
konstant und bei kleinen Graphen kaum bemerkbar.
Zum Zeitpunkt als die Parallelisierung in die Implementation aufgenommen
wurde, wurden bereits Ausführungszeiten für die gesamte UDF von etwa neun
Millisekunden erreicht, wobei der Dijkstra-Algorithmus selbst nur noch etwa
eine Millisekunde Ausführungszeit benötigte. Genaueres dazu wird später im
Abschnitt 4.4 erklärt. Dabei war es nicht mehr möglich diesen extrem kurzen
Zeitraum durch Parallelisierung noch zu verkürzen. Das Gegenteil trat ein. Die
Ausführungszeiten wurden bis auf 200% erhöht. Dazu muss man sich vorstellen,
dass die relativ kleine Menge aller Nachbarn eines Knotens (z. B. zehn Nachbarknoten)
in zwei Teile geteilt wird, dann zwei Thread-Objekte initialisiert
und auf zwei Prozessoren parallel ausgeführt werden. Die Teilung der Menge,
die Initialisierung und das Starten der Threads dauert leider deutlich länger als
die zehn Update-Operationen seriell auszuführen. Das Problem ist also, dass
die Ausführungsteile die parallelisierbar wären extrem klein sind, und dass
die Aufteilung der Menge und das Threading auch eine gewisse Overhead-Zeit
© Andreas Redmer — 29. September 2011 58

4. Optimierungen in der Implementierung
benötigen. Diese Form Optimierung wurde wieder aus der Implementierung
entfernt, da sie keine Verbesserung brachte.
Der Vollständigkeit halber sei noch erwähnt, dass Brodal et al. in [4] eine
Form von parallelen Fibonacci-Heaps vorstellen, die noch schneller ist als die in
[10] beschriebene. Diese konnte jedoch aus den selben Gründen nicht eingesetzt
werden. Weiterhin ist allgemein bekannt, dass beim Dijkstra-Algorithmus auch
die Möglichkeit besteht, ihn vom Startknoten und vom Zielknoten aus gleichzeitig
zu starten. Dafür werden genau zwei CPU-Kerne benötigt. Beide Abläufe
laufen dann aufeinander zu und stoppen, im Durchschnitt, nach der Hälfte der
Zeit. Diese Möglichkeit wurde nicht eingesetzt, da im Rahmen dieser Arbeit
keine Zielknoten definiert werden, sondern der Algorithmus immer erst stoppt,
wenn alle Knoten entdeckt sind.
Ausführung mehrerer Dijkstras parallel
Obwohl sich der Algorithmus in sich nicht optimal parallelisieren lässt, gibt
es dennoch Möglichkeiten mehrere Dijkstra-Algorithmen gleichzeitig laufen zu
lassen. Im einfachsten Fall schickt der Datenanalyst zwei getrennte Anfragen
an einen Datenbankserver, der mindestens zwei Prozessoren nutzt. Um beispielsweise
alle Routen zu berechnen, die im November und Dezember des
Jahres 2010 gültig waren, kann er die Funktion shortestPaths, die im Abschnitt
3.2 beschrieben wurde benutzen. Dabei schickt er die beiden in Listing
4.2 gezeigten Anfragen für die beiden Monate, getrennt über zwei verschiedene
Client-Verbindungen an den Server. Die Ergebnisse könnte er sich beispielsweise
in je eine Datei umleiten und danach beide Dateien aneinander hängen.
© Andreas Redmer — 29. September 2011 59

4. Optimierungen in der Implementierung
1 -- Anfrage Nummer 1:
2 SELECT shortestpaths(s1.time) AS paths FROM
3 (
4 SELECT time FROM times WHERE
5 time BETWEEN ’2010-11-01 00:00:00’::timestamptz
6 and ’2010-12-01 00:00:00’::timestamptz
7 ) as s1
8
9 -- Anfrage Nummer 2:
10 SELECT shortestpaths(s1.time) AS paths FROM
11 (
12 SELECT time FROM times WHERE
13 time BETWEEN ’2010-12-01 00:00:00’::timestamptz
14 and ’2011-01-01 00:00:00’::timestamptz
15 ) as s1
Listing 4.2: Zwei Anfragen die getrennt gesendet werden können
Diese Art der ”
manuellen“ Parallelisierung funktioniert natürlich immer. Das
eben beschriebene Fallbeispiel würde bei einem dedizierten Datenbankserver
das selbe Ergebnis in der Hälfte der Zeit bringen. Das ganze bringt natürlich
nur Vorteile, wenn die Ergebnisse getrennt immer noch verwendbar sind, und
wenn deren Ausführung lange genug dauert um eine Einteilung zu rechtfertigen.
Um dem Benutzer diese Form der Optimierung leichter zugänglich zu machen
wurde im Rahmen dieser Arbeit versucht, eine Schnittstelle zu entwickeln,
die dem Benutzer die Ausführung auf mehreren CPU-Kernen ermöglicht. Dies
sollte wahlweise möglich sein, da der Benutzer nicht immer sehr große Mengen
abfragt und zusätzlich sollte die in Abschnitt 3.2 angegebene Schnittstellendefinition
nicht verändert, sondern höchstens erweitert werden.
Den Dijkstra-Algorithmus in ein Java-Thread-Objekt zu verschieben war
problemlos möglich. Aber dem Benutzer eine effektive Schnittstelle zu bieten
gestaltete sich als schwierig, da in SQL eine Möglichkeit gefunden werden musste
um verschiedene Graphen an verschiedene Threads zu übergeben. Generell
hätte man auch mehrere Graphen in die Klasse laden können und die Java-
Klasse hätte dann selbst entschieden, wie viele Threads sie dafür eröffnet. Dies
passte jedoch nicht in das bestehende Konzept zur Ergebnisrückgabe an die
aufrufende SQL-Funktion.
In Abbildung 3.3 (Seite 33) wurde die Funktion shortestPaths schematisch
dargestellt. Im Listing 4.3 findet sich nun die selbe Funktion im Pseudocode.
Daneben wird im Listing 4.4 die Funktion shortestPaths, mit dem erweiterten
Multithread-Konzept aufgezeigt.
© Andreas Redmer — 29. September 2011 60

4. Optimierungen in der Implementierung
1 FUNCTION shortestPath(TIMESTAMP t)
2
3 BEGIN
4 truncateRootNodes()
5 FOR EACH g ∈ Gateways of t
6 DO addRootNode(g) // ≈ 4 mal
7
8
9
10
11
12 truncateLinks()
13 FOR EACH l ∈ Links of t
14 DO addLink(l) // ≈ 800 mal
15
16
17
18
19
20 run() // läuft ≈ 1 ms
21
22 R := getResultSet()
23
24 RETURN R
25 END
Listing 4.3: shortestPaths Singlethread
Pseudocode
1 FUNCTION shortestPath(TIMESTAMP t 1 ,
2 TIMESTAMP t 2 )
3 BEGIN
4 truncateRootNodes(CPU1)
5 FOR EACH g ∈ Gateways of t 1
6 DO addRootNode(CPU1,g) //≈4 mal
7
8 truncateRootNodes(CPU2)
9 FOR EACH g ∈ Gateways of t 2
10 DO addRootNode(CPU2,g) //≈4 mal
11
12 truncateLinks(CPU1)
13 FOR EACH l ∈ Links of t 1
14 DO addLink(CPU1,l) // ≈ 800 mal
15
16 truncateLinks(CPU2)
17 FOR EACH l ∈ Links of t 2
18 DO addLink(CPU2,l) // ≈ 800 mal
19
20 run(CPU1)
21 run(CPU2)
22 R 1 := getResultSet(CPU1) //≈1 ms
23 R 2 := getResultSet(CPU2)
24 RETURN (R 1 , R 2 )
25 END
Listing 4.4: shortestPaths Doublethread
Pseudocode
In dem erweiterten Konzept hat jede der inneren Funktionen einen neuen
Parameter bekommen, mit dem der Benutzer angibt, in welchem Thread er
den Graphen berechnen möchte. In diesem Fall wurden die Threads CPU1 und
CPU2 genannt. In der Java-Klasse gibt es nun zwei getrennte Repräsentationen
von Graphen, die getrennt mit addRootNode und addLink gefüllt werden. In
Zeile 20 des Listings 4.4 startet die parallele Ausführung. Die Funktion run
hat hier nur noch eine sehr kurze Laufzeit, da sie nur im Hintergrund den
Thread startet und dann die Kontrolle wieder an die aufrufende Funktion
zurück gibt. Die Laufzeit, die der Dijkstra-Algorithmus benötigt, wird nun
von der getResultSet-Funktion gebraucht, da diese so lange wartet bis der
erste Dijkstra-Algorithmus durchgelaufen ist.
Die Funktion ist nur beispielhaft für zwei Threads dargestellt. Das verbessert
die Übersichtlichkeit. Man erkennt jedoch leicht, dass man der Funktion auch
ein Array oder eine Liste von x Timestamps hätte übergeben können und diese
dann in der Java-Klasse auf x Threads aufteilen können. Falls x eine sehr
© Andreas Redmer — 29. September 2011 61

4. Optimierungen in der Implementierung
große Zahl ist, ist natürlich die Verwendung einer Threadpool-Verwaltung in
der Java-Klasse nicht ausgeschlossen, um die maximale Anzahl der erzeugten
Thread-Objekte zu begrenzen.
In Zeile 24 des Listings 4.4 erkennt man jedoch, dass auch hier wieder die
Rückgabe des Ergebnisses ein Problem ist. In diesem Fall wird ein Tupel von
zwei Ergebnismengen zurückgegeben. Dadurch dass sich der Rückgabetyp nun
geändert hat, muss die Funktion in einem völlig anderen Kontext eingesetzt
werden.
Der Vorteil ist also, dass diese Optimierung die Ausführung von mehreren
Dijkstra-Algorithmen tatsächlich schneller macht. Der Nachteil ist aber, dass
der Datenanalyst zwangsweise die Anzahl seiner Prozessorkerne kennen muss.
Wenn er beispielsweise vier CPU-Kerne zur Verfügung hat, muss er alle zu
analysierenden Daten immer in Vierergruppen zerlegen und absenden. Als Ergebnis
bekommt er wieder eine Vierergruppe von Ergebnissen, die er dann
selbst wieder entsprechend auswerten muss. Das wäre in SQL deutlich komplizierter
als die Single-Thread-Methode und es widerspricht damit dem Ziel der
Arbeit eine einfache Lösung bereitzustellen. Durch die Kapselung der allgemeinen
Java-API-Funktion Runtime.getRuntime().availableProcessors() in
eine PL/Java UDF, konnte die Anzahl der verfügbaren Prozessorkerne schon
in SQL bestimmt werden und die shortestPaths-Funktion dann dynamisch
mit der entsprechenden Anzahl an Threads aufgerufen werden. Damit wurden
dann aber nur sehr viele geltenden Routen für sehr viele Zeitpunkte hintereinander
ausgegeben. Dies löst maximal einen Teil der Probleme in Problemklasse
B und ist somit auch nicht geeignet um das Ziel der Arbeit zu erreichen (vgl.
Abschnitt 1.4).
Die Verbesserung der Performance durch diese Art der Parallelisierung war
relativ gut. Allerdings ist zu bedenken, dass hier nur die Ausführung des
Dijkstra-Algorithmus parallel erfolgt, jedoch nicht die gesamte UDF. Zum Zeitpunkt
der Einführung dieser Optimierung lief die gesamte UDF bereits in nur
noch neun Millisekunden ab, wobei der Dijkstra-Algorithmus nur noch eine
Millisekunde davon benötigte. Tabelle 4.1 stellt die obere Schranke der dadurch
erreichbaren Verbesserungen da. Dabei wurde angenommen, dass immer
Anzahl Threads = Anzahl CPU-Kerne = Anzahl zu berechnender Graphen
gilt. Der Overhead für das Threading wurde nicht berücksichtigt.
Dieses Konzept wurde, noch vor der vollständigen Implementierung, wieder
aus dem Projekt entfernt, da die Nachteile (sehr aufwändige Implementierung,
schlechtere Usability und sehr beschränktes Einsatzgebiet) einem relativ gerin-
© Andreas Redmer — 29. September 2011 62

4. Optimierungen in der Implementierung
Threads Laufzeit Singlethread Laufzeit Multithread Verbesserung
1 9 ms 9 ms 0,0%
2 18 ms 17 ms 5,6%
4 36 ms 33 ms 8,3%
8 72 ms 65 ms 9,7%
Tabelle 4.1.: Ausführungszeiten bei gleichzeitiger Ausführung mehrerer
Dijkstra
gen Vorteil (bessere Performance) gegenüberstanden. Insbesondere das breite
Einsatzgebiet, das in Kapitel 5 noch verdeutlicht wird, spricht dafür, dass die
Entscheidung gegen das Multithreading gut war.
4.3.2. Dijkstra auf der GPU
Nach der Betrachtung Parallelisierung auf Multiprozessorsystemen und die
Parallelverarbeitung in der Cloud bereits von Mundt und Vetterick in [22]
bleibt noch eine weitere Möglichkeit offen, den Graphenalgorithmus zu beschleunigen.
Moderne Grafikkarten bieten Möglichkeiten, die Berechnungen die
in der Computergrafik nötig sind stark zu parallelisieren. In früheren Generationen
wurden Berechnungen, die für jeden Pixel einzeln ausgeführt werden
mussten, mit Pixelshadern berechnet. Ebenso wurden Berechnungen für die
Vertices von grafischen 3D Modellen mit Vertexshadern berechnet. Dabei war
der Befehlssatz dieser Shader jeweils stark eingeschränkt. Da die Ansprüche
immer weiter stiegen, entwickelten die Hersteller der Grafikkarten sogenannte
General Purpose Graphics Processing Units (GPGPU); also universelle
Shader die alle Arten von Berechnungen stark parallel ausführen können. Die
Graphics Processing Unit (GPU) dient dabei als Container der Shader und
wird auch als Grafikprozessor bezeichnet. Die General Purpose Shader können
mit einer API für die Programmiersprache C programmiert werden.
Zunächst entwickelten die großen Hersteller (ATI und Nvidia) eigene Standards.
Dabei war die Compute Unified Device Architecture (CUDA) der
Standard von Nvidia. Da im Rahmen dieser Arbeit bei einem der Testcomputer
eine GPGPU Grafikkarte von Nvidia zur Verfügung stand, wurde versucht
den Dijkstra-Algorithmus ebenfalls mit CUDA umzusetzen. Es sei an dieser
Stelle jedoch bemerkt, dass CUDA nicht der aktuellste Standard ist um Berechnungen
auf der Grafikkarte durchzuführen. Noch moderner ist die Open
Computing Language (OpenCL), die ebenfalls von Nvidia mit entwickelt
wurde. OpenCL wurde in dieser Arbeit nicht betrachtet, da die Untersuchungen
mit CUDA ausreichend waren.
© Andreas Redmer — 29. September 2011 63

4. Optimierungen in der Implementierung
Die Programmierung von GPUs ist ein großes eigenes Themengebiet, das an
dieser Stelle nicht ausführlich erläutert werden soll. Wichtig ist jedoch zu wissen,
dass die Grafikkarte eine komplett eigene Architektur (also ein Computer
im Computer) ist. Auf ihr gibt es Shader, die jeweils alle ihren eigenen kleinen
Arbeitsspeicher haben und zusätzlich gibt es einen größten Arbeitsspeicher auf
den alle Shader gemeinsam zugreifen können.
Harish und Narayanan stellen in [17] Möglichkeiten vor, eine Vielzahl von
Graphenalgorithmen mit CUDA auf der Grafikkarte zu implementieren. Sie
implementierten auch Floyd-Warshall und Dijkstra und stellten ihre Implementierung
für die Erstellung dieser Arbeit freundlich zur Verfügung. Diese
Implementierung bestand aus einem C-Programm und zwei CUDA-Dateien.
Die CUDA-Dateien enthalten den minimal kleinen Sourcecode, der mit dem
Nvidia Compiler (NVC) zu einer CUBIN-Datei (CUDA Binary) kompiliert
werden kann. Diese enthält den binären Maschinencode der auf GPGPUs ausgeführt
werden kann. Das C-Programm folgte größtenteils einem üblichen Schema,
nach dem auch sehr viele von Nvidia veröffentlichte Beispielprogramme
entworfen sind. Dieses Schema ist in Listing 4.5 aufgezeigt.
1 LESE Graph aus Datei
2 ALLOKIERE den Host-Speicher (auf dem Computer)
3 INITIALISIERE den Host-Speicher
4 ALLOKIERE den Gerätespeicher (auf dem Grafikkarte)
5 KOPIERE den Inhalt von Host-Speicher zu Gerätespeicher
6 ALLOKIERE den Host-Speicher für das Ergebnis
7 ALLOKIERE den Gerätespeicher für das Ergebnis
8 STARTE den Algorithmus (nutzt die CUBIN-Programme)
9 KOPIERE das Ergebnis von Gerätespeicher zu Host-Speicher
10 SPEICHERE das Ergebnis in einer Datei
11 GIB Host-Speicher FREI
12 GIB Gerätespeicher FREI
Listing 4.5: Ablauf des CUDA-Programmes in Pseudocode
Dieses C-Programm wurde im Rahmen dieser Arbeit nach Java portiert.
Dabei wurde das JCuda Framework [19] verwendet. Anschließend konnte die
CUDA-Implementierung mit den selben Graphen und mit den selben Testklassen
getestet werden. Dabei wurde festgestellt, dass diese langsamer sind,
was ganz offensichtlich mit der aufwändigen Vor- und Nachbereitung des Programms
zusammen hing. Die Kopiervorgänge in Listing 4.5 (Zeile 5 und 9) vom
Arbeitsspeicher des Computers in den der Grafikkarte und zurück, dauern leider
viel zu lange um für derartig kleine Graphen einen Geschwindigkeitsvorteil
zu erreichen.
© Andreas Redmer — 29. September 2011 64

4. Optimierungen in der Implementierung
Harish und Narayanan geben in [17] an, dass ihre GPU-Implementierung für
zufällige Graphen deutlich schneller ist, als eine vergleichbare CPU-Version.
Allerdings hängt dies stark von der Anzahl der Nachbarknoten pro Knoten ab.
Für Graphen mit einer Millionen Knoten mit 6 Nachbarn pro Knoten (was auch
im Opennet durchschnittlich so ist) erreichten sie eine Ausführungszeit von
100 Millisekunden, während die CPU schon 10 Sekunden dafür benötigte. Die
Zeitmessung erfolgt dabei allerdings nur über den reinen Dijkstra-Algorithmus.
Die Zeiten für den Transfer der Daten zwischen den Arbeitsspeichern wurden
ignoriert. Für kleinere Graphen wurden keine Testwerte angegeben.
Für die Relevanz in dieser Arbeit mussten aber auch die Zeiten für die Datentransfers
mitgemessen werden. Die Ausführungen mit Graphen mit 200 Knoten
dauerten über 15 Millisekunden (das wären dann 15+8=23 Millisekunden für
die gesamte UDF). Da die UDF damit nicht beschleunigt werden konnten, wurde
diese Optimierung nicht in die Implementierung der UDF aufgenommen.
4.4. Zusammenfassung und Ergebnisse
Die finale Form der UDF, die aus genannten Gründen ohne jegliche Parallelisierung
funktioniert, hat die in Abbildung 4.6 aufgezeigten Laufzeiten. Diese
wurde mit den in Abschnitt 3.3 vorgestellten Methoden so genau wie möglich
gemessen. Die Java-UDF läuft 9,08 Millisekunden. Dabei handelt es sich um
die durchschnittliche Laufzeit für eine UDF, die über allen zur Verfügung stehenden
Daten ermittelt wurde.
3,23
9,08
1,805
1,04
3,905
shortestPaths (100 %)
truncate/addRootNodes
(0,14 ms; 1,54 %)
truncate/addLinks (35,57 %)
run (19,88 %)
dijkstra (11,45 %)
getResultSet (43,01 %)
0 1 2 3 4 5 6 7 8 9 10 ms
Abbildung 4.6.: Balkendiagramm der Ausführungszeit der UDF shortest-
Paths
Die Ausführung des Dijkstra-Algorithmus dauert in der finalen Version nur
noch 1,04 Millisekunden. Es ist sehr wichtig zu beachten, dass alle Optimierun-
© Andreas Redmer — 29. September 2011 65

4. Optimierungen in der Implementierung
gen, die den Dijkstra-Algorithmus betrafen (z. B. General-Gateway-Strategie,
Dijkstra auf der GPU, etc.), sich immer nur auf diesen Zeitraum auswirkten.
Insbesondere können auch zukünftige Optimierungen am Dijkstra-Algorithmus
nur eine Verringerung dieser 1,04 Millisekunden bewirken. Damit kann auch
die zu erwartende Zeitersparnis für zukünftige Optimierungen gut eingeschätzt
werden.
In Abbildung 4.7 wird die Reihenfolge der durchgeführten Optimierungen
dargestellt und wie diese aufeinander aufbauen. Die Tabelle 4.2 zeigt eine Zusammenfassung
dieser Optimierungen. Um die Ergebnisse nachvollziehbar zu
machen, wurde der Abschnitt, in dem diese Art der Optimierung beschrieben
wurde, in jeder Zeile genannt.
1
Implementierung
aus [22]
2
Floyd-Warshall
in SQL
10
ohne Fibonacci-
Heap mit
Multithreaded
Dijkstra
3
Floyd-Warshall
in PL/Python
6
mit JGraphT
Fibonacci-Heap
11
mit mehreren
Dijkstras
parallel
4 5
Floyd-Warshall
in PL/Java
jetzt mit
Dijkstra
7 8 9
mit eigenem
FastFibonacci-
Heap
mit General-
Gateway-
Strategie
mit gestrichenen
redundanten
Kanten
12
ohne
Fibonacci-Heap
auf der GPU
Abbildung 4.7.: Reihenfolge der durchgeführten Optimierungen
In Tabelle 4.2 wurde die Implementierung von Mundt und Vetterick [22] als
Referenz angegeben um die erreichte Verbesserung prozentual ausdrücken zu
können. Eine relative Verbesserung konnte nicht angegeben werden, da diese
immer vom betrachteten Vorgänger abhängig wäre. Beispielsweise bringt
die General-Gateway-Strategie prozentual unterschiedliche Verbesserungen, je
nachdem welche Programmiersprache und welche Art von Heap eingesetzt
wird. Theoretisch sollte es derartige Unterschiede nicht geben; in der Praxis
treten sie jedoch aufgrund verschiedenartiger Compileroptimierungen auf.
© Andreas Redmer — 29. September 2011 66

4. Optimierungen in der Implementierung
Nr. Optimierung Abschnitt Laufzeit in ms Laufzeit in %
1 Implementierung aus [22] 2.3.1 ∼ = 4000 ms 100%
2 Floyd-Warshall in SQL 3.1.3 > 60000 ms 1500%
3 Floyd-Warshall in 3.1.3 = 6000 ms 150%
PL/Python
4 Floyd-Warshall in 3.1.3 = 250 ms 6,25%
PL/Java
5 jetzt mit Dijkstra 4.1.1 = 20,02 ms 0,50050%
6 mit JGraphT
4.1.1 = 12,26 ms 0,30650%
Fibonacci-Heap
7 mit eigenem
4.2.2 = 12,23 ms 0,30575%
FastFibonacciHeap
8 mit General-Gateway- 4.1.3 = 9,15 ms 0,22875%
Strategie
9 mit gestrichenen 4.1.2 = 9,08 ms 0,22700%
redundanten Kanten
10 ohne Fibonacci-Heap mit 4.3.1 ∼ = 12,2 ms 0,30500%
Multithreaded Dijkstra
11 mit mehreren Dijkstras 4.3.1 ∼ = 8,5 ms 0,21250%
parallel
12 ohne Fibonacci-Heap auf 4.3.2 ∼ = 23 ms 0,57500%
der GPU
Tabelle 4.2.: Ausführungszeiten und Verbesserungen der Optimierungen
Zusätzlich gelten für die Tabelle 4.2 folgende Hinweise:
ˆ Nr. 9 representiert die finale Version dieser Arbeit,
ˆ gemessene Werte werden mit ”
=“ angegeben,
ˆ geschätzte oder berechnete Werte werden mit ”
∼ =“ angegeben,
ˆ für Nr. 10 gilt 2 Threads und 2 verfügbare CPU-Kerne,
ˆ für Nr. 11 gilt 2 Threads, 2 verfügbare CPU-Kerne und 2 zu berechnende
Graphen (Durschnittswert) und
ˆ für alle Messungen wurde das Testsystem 1 verwendet.
Alle im Abschnitt 4.2 (performanceoptimierter Programmierstil) genannten
Optimierungen wurden jederzeit angewendet. Auch wenn die dadurch erhaltenen
Verbesserungen nicht gemessen wurden, erkennt man schon an dem
Sprung von Nr. 6 auf Nr. 7, dass die Unterschiede dadurch wahrscheinlich nur
sehr gering waren. Die in Abschnitt 2.3.1 schon beschriebene, sehr effiziente,
Implementierung des Dijkstra-Algorithmus, wurde ebenfalls von Anfang an
verwendet. Sie ist also schon in Nr. 5 enthalten und beeinflusst die Laufzeit
relativ stark.
© Andreas Redmer — 29. September 2011 67

5. Testläufe - Beispiele für Datenabfragen
5. Testläufe - Beispiele für
Datenabfragen
Dieses Kapitel zeigt eine Reihe von Abfragen, in denen die im Rahmen dieser
Arbeit erstellten UDF eingesetzt werden. In den hier gezeigten Beispielen kann
ein Datenanalyst erkennen, die wie die Funktionen zu verwenden sind und
welche Möglichkeiten sich damit bieten.
Die Beispiele setzen voraus, dass die Daten in der in Tabelle 1.1 (Seite 3)
gezeigten Form in einer Tabelle namens links auf dem Datenbankserver abgelegt
sind. Da die Angabe der Zeitpunkte (Timestamps) aus den Aufzeichnungen
immer benötigt wird und die Abfrage aller vorhandenen Zeitpunkte (ohne
Duplikate) sehr lange dauert, wurden diese im Vorfeld in eine separate Tabelle
geschrieben. Dazu wurde folgende Anweisung verwendet:
CREATE TABLE times AS SELECT DISTINCT time FROM links;
Dabei werden nur die Timestamps ausgewählt, alle Duplikate entfernt und
dann in die Tabelle times geschrieben. Die Datenbank für die nachfolgenden
SQL-Abfragen kann nun mit dem in Abbildung 5.1 gezeigten Entity-
Relationship-Modell dargestellt werden.
nodeA
(1,1) (1,N)
Time Has Link
nodeB
LQ
time
time
NLQ
Abbildung 5.1.: ER-Modell der verwendeten Datenbank
Die Spalte time wurde in jeder der beiden Tabellen mit einem B-Baum indiziert.
Dadurch sind partial-match-Anfragen und exact-match-Anfragen sehr
schnell möglich. Ohne diese währen die angegebenen Laufzeiten teilweise nicht
© Andreas Redmer — 29. September 2011 68

5. Testläufe - Beispiele für Datenabfragen
erreichbar. Dabei ist zu beachten, dass Anfragen mit einer WHERE-Klausel der
Form:
WHERE time BETWEEN ’2011-01-01 00:00:00’ AND ’2011-12-31 23:59:59’
eine geringere Ausführungszeit als Anfragen mit der Form:
WHERE EXTRACT (year from time) = 2011
haben. Beide liefern die selbe Ergebnismenge. Der Index wird jedoch nur bei
Verwendung eines Vergleichsoperators verwendet, nicht jedoch bei der Ausführung
einer Funktion. Zusätzlich wäre es möglich den Rückgabewert einer
Funktion zu indizieren, was für die im Anschluß gezeigten SQL-Anfragen jedoch
nicht nötig war.
Soweit nicht anders angegeben, wurden alle Laufzeiten auf dem Testsystem 1
gemessen, das in Tabelle 1.6 (Seite 11) definiert wurde.
Die gegebenen SQL-Abfragen lesen sich am besten ”
von innen nach außen“.
Also in der Reihenfolge in der sie auf dem Server ausgeführt werden. Innere
SQL-Selektionen wurden weiter eingerückt und teilweise der Reihenfolge nach
benannt (z. B. mit s1, s2, s3, s4). Für jedes Beispiel wird die Ausgabe, die
Laufzeit und eine ausführliche Erklärung angegeben. Weiterhin gibt es zu einigen
der Beispiele ein Fazit, welche eine Datenanalyst beispielhaft aus den
Ergebnissen ziehen könnte. Dabei handelt es sich um tatsächliche Schlussfolgerungen,
die das real bestehende Netzwerk betreffen.
© Andreas Redmer — 29. September 2011 69

5. Testläufe - Beispiele für Datenabfragen
5.1. Alle Routen zu allen Zeitpunkten
1 SELECT s1.time, (shortestpaths(s1.time)).* as PE from
2 (
3 select time from times
4 ) as s1;
Listing 5.1: Abfrage aller Routen
Ausgabe: 57396862 Zeilen von Tupeln der Form: (Timestamp, Knoten, Vorgänger,
Abstand)
Laufzeit: ≈ 74 Minuten (Testsystem 1), ≈ 83 Minuten (Testsystem 2)
Erklärung: Die Anfrage in Listing 5.1 ist die Standardabfrage, die den
meisten Performancetests als Benchmark diente. Sie gibt alle geltenden Routen
zu allen aufgezeichneten Zeitpunkten zurück. Damit können Fragen aus der
Problemklasse B (vgl. Abschnitt 1.4) beantwortet werden. Die Ausführungszeit
für alle shortestPaths-Funktionen ergibt sich aus der Anzahl der bestehenden
Timestamps (334960) mal der Zeit die eine UDF-Berechnung benötigt (9 ms).
334960 · 9ms = 3014640ms ≈ 50min
Hinzu kommt in diesem Fall die Ausgabe der enormen Anzahl der Ergebniszeilen,
die erhebliche Zeit in Anspruch nimmt. In diesem Fall erfolgte die Ausgabe
in eine Datei, die das Ergebnis in Textform repräsentiert. Die Datei war 3,0
Gigabytes groß. Die höhere Laufzeit für Testsystem 2 resultiert aus der langsameren
Festplatte.
© Andreas Redmer — 29. September 2011 70

5. Testläufe - Beispiele für Datenabfragen
5.2. Routenänderungen zwischen zwei
Zeitpunkten
1 DROP FUNCTION IF EXISTS unterschied(timestamptz,timestamptz);
2 CREATE OR REPLACE FUNCTION unterschied(timestamptz,timestamptz)
3 RETURNS bigint AS
4 $$
5 select count (*) from
6 (
7 (
8 select node,pred from shortestpaths($1)
9 EXCEPT
10 select node,pred from shortestpaths($2)
11 )
12 UNION
13 (
14 select node,pred from shortestpaths($2)
15 EXCEPT
16 select node,pred from shortestpaths($1)
17 )
18 ) s1
19 $$
20 STABLE LANGUAGE SQL;
21
22 SELECT t1.time,t2.time,unterschied(t1.time,t2.time) FROM times t1,times t2
23 WHERE t1.time BETWEEN ’2010-09-14 00:00:00’
24 AND ’2010-09-15 00:00:00’
25 AND t2.time = (SELECT MIN(time) FROM times t3 WHERE t3.time >t1.time)
Listing 5.2: Abfrage aller Routenänderungen an einem Tag
Ausgabe: 1440 Zeilen der Form (Timestamp 1,Timestamp 2, Anzahl der
Unterschiede)
Laufzeit: 53 Sekunden
Erklärung: Die Anfrage in Listing 5.2 löst ein Problem aus der Problemklasse
C. Sie gibt aus, wie stark sich die Routen von einem Zeitpunkt zum
nächsten an einem Tag ändern. Der Einfachheit wegen, wird dabei zunächst
eine einfache neue UDF namens unterschied angelegt. Diese bekommt zwei
Timestamps als Parameter und gibt die Anzahl der Unterschiede zwischen den
Routen der beiden Timestamps zurück. Der Unterschied ist dabei wie folgt
definiert: sei D x die Menge aller Knoten mit zugehörigen Vorgängern zum
© Andreas Redmer — 29. September 2011 71

5. Testläufe - Beispiele für Datenabfragen
Zeitpunkt x. Sei weiterhin der Vorgänger immer der Knoten, der auf dem Weg
zum nächsten Gateway direkt angesprochen wird. Dann ist
|(D i \ D j ) ∪ (D j \ D i )|
ein Maß für den Unterschied zwischen Zeitpunkt i und j.
Die SQL-Anfrage die in Zeile 22 beginnt, listet alle Timestamps, die am
14.09.2010 aufgezeichnet wurden auf und ordnet ihnen ihren Nachfolger zu.
Als Nachfolger wird immer der nächst größere aufgezeichnete Timestamp ausgewählt.
Dann wird die Funktion unterschied auf jedes Paar angewendet.
Die Ausführungszeit für eine solche Anfrage kann wie folgt im Vorfeld geschätzt
werden, da die Anzahl der Minuten pro Tag (1440) bekannt ist.
Timestamps · shortestpaths() in unterschied() · Dauer shortestpaths()
} {{ } } {{ } } {{ }
1440
4
9ms
1440 · 4 · 9ms = 51840ms ≈ 52s
Der maximale Unterschied zwischen zwei Timestamps kann abgefragt werden,
indem die Aggregatfunktion MAX im SELECT-Teil der Anweisung verwendet
wird. Ebenso sind weitere Funktionen wie MIN oder AVG möglich, um die 1440
Zeilen zusammenfassend zu betrachten. Wie man leicht sieht, lassen sich diese
Ergebnisse dann wiederum in UDF kapseln und/oder in weiteren komplexeren
Anfragen verwenden.
Fazit: Am 14.09.2010 lag der maximale Unterschied, zwischen zwei aufeinander
folgenden Timestamps, bei 68 und der minimale Unterschied bei 6
Veränderungen. Durchschnittlich gab es 26,2 Veränderungen zwischen zwei Timestamps.
© Andreas Redmer — 29. September 2011 72

5. Testläufe - Beispiele für Datenabfragen
5.3. Routenänderungen bei Ausfall eines Knotens
1 CREATE OR REPLACE FUNCTION shortestpaths_skip1(timestamptz, inet)
2 RETURNS SETOF PathElement AS $$ DECLARE
3 BEGIN
4 PERFORM truncateRootNodes();
5 PERFORM addRootNode (host(’192.168.0.254’::inet));
6 PERFORM addRootNode (host(’10.2.0.251’::inet));
7 PERFORM addRootNode (host(’10.2.0.247’::inet));
8 PERFORM addRootNode (host(’192.168.0.251’::inet));
9 PERFORM truncateLinks();
10 PERFORM addLink(host(nodea), host(nodeb), lq, lqn) from links
11 where time=$1
12 AND nodea!=$2 AND nodeb!=$2; -- NEU
13
14 PERFORM run();
15 RETURN QUERY SELECT node,pred,d from getPathSet();
16 END;
17 $$ STABLE LANGUAGE plpgsql;
18
19 CREATE OR REPLACE FUNCTION unterschied_skip1(timestamptz,inet)
20 RETURNS bigint AS $$
21 select count (*) from
22 ( ( select node,pred from shortestpaths($1) EXCEPT
23 select node,pred from shortestpaths_skip1($1,$2)
24 ) UNION
25 ( select node,pred from shortestpaths_skip1($1,$2) EXCEPT
26 select node,pred from shortestpaths($1)
27 )
28 ) s1 $$
29 STABLE LANGUAGE SQL;
30
31 SELECT nodea,SUM(u) as summe FROM
32 ( SELECT time,nodea,unterschied_skip1(time,nodea) as u FROM (
33 -- 200733 zeilen
34 SELECT distinct t.time,nodea FROM times t, links l
35 WHERE t.time BETWEEN ’2010-09-14 00:00:00’ and ’2010-09-15 00:00:00’
36 AND t.time = l.time
37 ) as s1
38 ) as s2
39 GROUP BY nodea ORDER BY summe DESC;
Listing 5.3: Abfrage der Routenänderungen beim Ausfall eines Knotens
© Andreas Redmer — 29. September 2011 73

5. Testläufe - Beispiele für Datenabfragen
Ausgabe: 146 Zeilen (die ersten zehn Zeilen sind in Tabelle 5.1 angegeben)
Nr. Knoten Summe Nr. Knoten Summe
1 192.168.0.254 94170 6 192.168.1.112 27606
2 192.168.1.111 57870 7 192.168.1.155 27247
3 192.168.1.184 35342 8 192.168.1.214 26729
4 192.168.1.93 33846 9 192.168.1.180 26691
5 10.2.0.247 31915 10 192.168.2.7 25120
Tabelle 5.1.: Erste Ergebnisse der SQL-Abfrage in Listing 5.3
Laufzeit: ≈ 121 Minuten ( ≈ 2 Stunden)
Erklärung: Die Anfrage in Listing 5.3 löst ein in Abschnitt 1.4 beschriebenes
Problem der Problemklasse C. Sie streicht vor der Ausführung des Dijkstra-
Algorithmus einen Knoten aus dem Graphen (dies simuliert den Ausfall des
Knotens) und führt dies für jeden im Graphen vorhandenen Knoten aus. Die
Komplexität erhöht sich dadurch um den Faktor O(n). Die Ausgabe ist die
Anzahl der Unterschiede, die ein Knoten in den Routen verursacht, wenn er
ausfällt. Dies kann durchaus als ein Maß für die Wichtigkeit eines Knotens
verwendet werden. Es ist allerdings zu beachten, dass an dieser Stelle die Existenz
und Qualität der Alternativrouten nicht betrachtet wird und somit der
entstehende Nachteil durch die veränderten Routen unbestimmt ist.
Wie bereits zu Beginn des Abschnitts 3.2 erklärt, wurde die PL/pgSQL-
Funktion shortestPaths auch als Vorlage verwendet, um weitere UDF zu
entwickeln, die ähnliche Probleme lösen. Diese wurde hier kopiert und es wurde
die neue Funktion shortestpaths_skip1 erstellt. Diese hat den selben Ablauf
wie das Original: alle Gateways hinzufügen 16 , alle Links hinzufügen, ausführen
und Ergebnis zurückgeben 17 . PERFORM funktioniert übrigens genau wie die
SQL-Anweisung SELECT. Sie weist den Interpreter jedoch an, das Ergebnis der
Abfrage zu ignorieren. Hinzugefügt wurden nun also lediglich ein Parameter
(eine IP-Adresse eines Knotens) und eine zusätzliche Bedingung in der WHE-
RE-Klausel (Zeile 12), die dafür sorgt, dass keine Kanten, die diesen Knoten
beinhalten, in der Java Klasse registriert werden. Der Knoten wird vollständig
ignoriert.
Analog zu Listing 5.2 wird auch hier wieder eine Unterschiedsfunktion erstellt.
Sie heißt unterschied_skip1 (beginnend in Zeile 19) und berechnet
ein Maß für den Unterschied für die normalerweise geltenden Routen und die
16 Für die Gateways gibt es noch keine Tabelle, deshalb werden sie alle konstant in die
Funktion eingetragen.
17 Die originale shortestpaths-Funktion hat noch ein Exception-Handling, was hier aus
Platzgründen weggelassen wurde.
© Andreas Redmer — 29. September 2011 74

5. Testläufe - Beispiele für Datenabfragen
Routen wenn ein definierter Knoten ausfällt. Sei hier D V die Ausgabemenge
des Dijkstra-Algorithmus auf der Knotenmenge V . Dann erzeugt der Knoten
u ∈ V einen Unterschied von
wenn er ausfällt.
|(D V \ D V \{u} ) ∪ (D V \{u} \ D V )|
Die innere Abfrage (s1) selektiert zunächst alle am 14.09.2010 aufgezeichneten
Timestamps und Knoten. In Zeile 34 wird das Kreuzprodukt der beiden
Mengen (also Timestamps × Knoten) gebildet. Für die spätere Schätzung der
Laufzeit ist es immer hilfreich, mit der Aggregatfunktion COUNT die Elemente
der inneren Abfragen zu zählen. In diesem Fall ergeben sich 200733 Zeilen aus
der inneren Abfrage. In der Abfrage s2 wird nun für jedes Paar die Funktion
unterschied_skip1 aufgerufen. Es wird also in jedem Timestamp jeder
Knoten einmal ignoriert. Die äußere Abfrage summiert alle ermittelten Unterschiede
pro Knoten auf und sortiert die Knoten mit der größten Summe nach
ganz oben.
Die Laufzeit kann im Vorfeld wie zuvor mit
abgeschätzt werden.
200733 · 4 · 9ms = 7226388ms ≈ 120min
Fazit: Basierend auf den aufgezeichneten Daten am 14.09.2010, würde der
Gateway-Knoten 192.168.0.254 mit Abstand die meisten Veränderungen in
den Routen hervorrufen, wenn er ausfallen würde. Er bildet zusammen mit dem
Gateway 10.2.0.247 und den Nicht-Gateways 192.168.1.111, 192.168.1.184
und 192.168.1.93 die Top 5 an diesem Tag. Weiterhin ist zu erkennen, dass
jeder der 146 Knoten, des gesamten Netzwerkes (in dem Zeitraum), Routenveränderungen
verursacht wenn er ausfällt, da die Summe immer größer als
0 ist. Das kommt daher, dass die Routenveränderung immer für das gesamte
Netzwerk summiert ist, egal für wie viele Knoten die Änderung tatsächlich
relevant ist.
© Andreas Redmer — 29. September 2011 75

5. Testläufe - Beispiele für Datenabfragen
5.4. Routenänderungen bei Ausfall zweier Knoten
1 CREATE OR REPLACE FUNCTION shortestpaths_skip2(timestamptz, inet, inet)
2 RETURNS SETOF PathElement AS $$ DECLARE
3 BEGIN
4 PERFORM truncateRootNodes();
5 PERFORM addRootNode (host(’192.168.0.254’::inet));
6 PERFORM addRootNode (host(’10.2.0.251’::inet));
7 PERFORM addRootNode (host(’10.2.0.247’::inet));
8 PERFORM addRootNode (host(’192.168.0.251’::inet));
9 PERFORM truncateLinks();
10 PERFORM addLink(host(nodea), host(nodeb), lq, lqn) from links
11 where time=$1 AND nodea!=$2 AND nodeb!=$2 AND nodea!=$3 AND nodeb!=$3;
12
13 PERFORM run();
14 RETURN QUERY SELECT node,pred,d from getPathSet();
15 END; $$ STABLE LANGUAGE plpgsql;
16
17 CREATE OR REPLACE FUNCTION unterschied_skip2(timestamptz,inet,inet)
18 RETURNS bigint AS $$
19 select count (*) from
20 ( ( select node,pred from shortestpaths($1) EXCEPT
21 select node,pred from shortestpaths_skip2($1,$2,$3)
22 ) UNION
23 ( select node,pred from shortestpaths_skip2($1,$2,$3)
24 EXCEPT select node,pred from shortestpaths($1)
25 )
26 ) s1 $$ STABLE LANGUAGE SQL;
27
28 select n,m,SUM(u) as Summe from
29 ( SELECT time,n,m,unterschied_skip2(time,n,m) as u FROM (
30 SELECT distinct t.time,n1.nodea as n,n2.nodea as m FROM times t, (
31 SELECT distinct l1.time,l1.nodea FROM links l1
32 WHERE l1.time BETWEEN ’2010-09-14 00:00:00’ and ’2010-09-15 00:00:00’
33 AND EXTRACT(minute FROM l1.time)=0
34 ) as n1, (
35 SELECT distinct l2.time,l2.nodea FROM links l2
36 WHERE l2.time BETWEEN ’2010-09-14 00:00:00’ and ’2010-09-15 00:00:00’
37 AND EXTRACT(minute FROM l2.time)=0
38 ) as n2
39 WHERE t.time = n1.time AND t.time = n2.time AND n1.nodea

5. Testläufe - Beispiele für Datenabfragen
Ausgabe: ist in Tabelle 5.2 dargestellt
n m Summe
192.168.0.254 192.168.1.111 2314
10.2.0.247 192.168.0.254 2084
192.168.0.254 192.168.1.155 1988
192.168.0.254 192.168.1.180 1988
192.168.0.254 192.168.1.69 1964
192.168.0.254 192.168.1.93 1940
192.168.0.254 192.168.1.143 1894
192.168.0.254 192.168.1.245 1878
192.168.0.254 192.168.1.188 1842
192.168.0.254 192.168.1.27 1818
Tabelle 5.2.: Die Ergebnisse der SQL-Abfrage in Listing 5.4
Laufzeit: ≈ 143 Minuten ( ≈ 2,4 Stunden)
Erklärung: Die Anfrage in Listing 5.4 löst ein Problem der Problemklasse
C. Sie streicht vor der Ausführung des Dijkstra-Algorithmus zwei Knoten
aus dem Graphen (dies simuliert den Ausfall der Knoten) und führt dies für
jedes mögliche im Graphen vorhandene Paar von Knoten aus. Die Komplexität
erhöht sich dadurch um den Faktor O(n 2 ). Die Ausgabe ist die Anzahl
der Unterschiede, die in den Routen entstehen, wenn sie gleichzeitig ausfallen.
Hier kann also geprüft werden, ob es eine Kombination von Knoten gibt, die
bei gleichzeitigem Ausfall sehr gravierende Änderungen im Netzwerk bewirkt.
Zunächst wurde wieder eine neue Variante der shortestpaths-Funktion erstellt,
die jedoch nun zwei Knoten ignorieren kann. Die Funktion heißt shortestpaths_skip2,
enthält einen zusätzlichen Parameter (den zusätzlichen Knoten)
und in Zeile 11 eine angepasste Bedingung in der WHERE Klausel. Alle Kanten,
die von und zu diesen beiden Knoten führen, werden dort ignoriert. Wie
dort schon zu erkennen ist, hätte man der Funktion auch ein Array der Größe
x übergeben können. Jedoch ist es wahrscheinlich nicht sehr interessant, was
passiert, wenn x Knoten gleichzeitig ausfallen. Weiterhin riskiert man dabei
alle Gateways zu ignorieren, was eine der Vorbedingungen für den Dijkstra-
Algorithmus eliminieren würde. Es muss immer einen Startknoten, also mindestens
ein Gateway, geben.
Analog zu Listing 5.3 wird auch hier wieder eine Unterschiedsfunktion erstellt.
Diese heißt unterschied_skip2 (beginnend in Zeile 17) und berechnet
ein Maß für den Unterschied zwischen den normalerweise geltenden Routen
und den Routen, die gelten wenn zwei definierte Knoten gleichzeitig ausfallen.
© Andreas Redmer — 29. September 2011 77

5. Testläufe - Beispiele für Datenabfragen
Sei hier D V die Ausgabemenge des Dijkstra-Algorithmus auf der Knotenmenge
V . Dann erzeugen die Knoten u, w ∈ V einen Unterschied von
wenn sie gleichzeitig ausfallen.
|(D V \ D V \{u,w} ) ∪ (D V \{u,w} \ D V )|
Die erste innere Abfrage (n1) selektiert zunächst alle Timestamps und Knoten
(ohne Duplikate), die am 14.09.2010 (Zeile 32) und zu einer vollen Stunde
(Zeile 33) aufgezeichnet wurden. Genau das Gleiche wird in n2 (Zeile 35 bis
38) nochmal gemacht, um die selbe Knotenmenge erneut zu erhalten. In Zeile
39 wird das Kreuzprodukt (Timestamps × Knoten × Knoten) gebildet.
Gleichzeitig sorgt die WHERE-Klausel in dieser Zeile dafür, dass die IP-Adresse
des ersten Knotens immer kleiner ist als die des zweiten. Dadurch wird nicht
nur ausgeschlossen, dass beide gleich sind, sondern es werden auch Duplikate in
der Ergebnismenge verhindert, da sonst jedes Paar doppelt vorkommen würde.
Das passiert, weil Zeile 11 beide Knoten ignoriert, egal in welcher Reihenfolge
sie übergeben werden. Somit wird in Zeile 29, für jeden Timestamp und
für jedes mögliche Paar von Knoten, einmal die Funktion unterschied_skip2
aufgerufen. Die äußere Abfrage summiert alle ermittelten Unterschiede pro
Knotenpaar auf und sortiert die höchsten Summen nach oben.
Wenn im Vorfeld mit der Aggregatfunktion COUNT die Elemente des Kreuzproduktes
aus s1 gezählt werden, erhält man in diesem Fall die Zahl 231888.
Genau so oft wird die Funktion unterschied_skip2 aufgerufen. Die Laufzeit
kann also mit
231888 · 4 · 9ms = 8347968ms ≈ 139min
abgeschätzt werden.
Fazit: Basierend auf den am 14.09.2010 zur vollen Stunde aufgezeichneten
Daten, würden die Knoten 192.168.0.254 und 192.168.1.111 die meisten Routen
verändern, wenn sie gleichzeitig ausfallen würden. Dabei ist Letzterer kein
Gateway. Erst an zweiter Stelle kommt das Gatewaypaar 192.168.0.254 und
10.2.0.247. Der Knoten 192.168.0.254 ist in der gesamten Top 10 Liste in
jedem Paar enthalten.
© Andreas Redmer — 29. September 2011 78

5. Testläufe - Beispiele für Datenabfragen
5.5. Knoten die häufig auf Routen liegen
1 CREATE OR REPLACE FUNCTION path(inet,varchar[]) RETURNS inet[] AS $$
2 DECLARE p INET; pa INET[];
3 BEGIN
4 SELECT min(pred) INTO p FROM (
5 SELECT (string_to_array(unnest, ’,’))[1] as node,
6 (string_to_array(unnest, ’,’))[2] as pred FROM unnest($2)
7 ) as s1
8 WHERE node = host($1);
9 IF p IS NOT NULL THEN pa = pa || path(p,$2); END IF;
10 RETURN p||pa;
11 END;
12 $$ STABLE LANGUAGE plpgsql;
13
14 SELECT s4.n, count(s4.n) FROM
15 (
16 select s1.time, s2.nodea,
17 path (s2.nodea,array_agg(host(node) ||’,’|| host(pred)))
18 from (
19 select t.time,(shortestpaths(t.time)).* from times t
20 where extract (minute from time)=0
21 AND extract (year from time)=2011
22 AND extract (DOW from time)=1
23 ) as s1,
24 (
25 select distinct nodea from links
26 where extract (minute from time)=0
27 AND extract (year from time)=2011
28 AND extract (DOW from time)=1
29 ) as s2
30 GROUP BY s1.time, s2.nodea
31 ) as s3,
32 (
33 select distinct nodea as n from links
34 where extract (minute from time)=0
35 AND extract (year from time)=2011
36 AND extract (DOW from time)=1
37 ) as s4
38 where s3.path @> ARRAY[s4.n]
39 GROUP BY s4.n ORDER BY count DESC LIMIT 10;
Listing 5.5: Abfrage wie oft ein Knoten auf einer Route liegt
© Andreas Redmer — 29. September 2011 79

5. Testläufe - Beispiele für Datenabfragen
Ausgabe: ist in Tabelle 5.3 dargestellt
n
count
10.2.0.247 21217
192.168.0.254 20284
192.168.1.93 9872
192.168.1.111 9667
192.168.2.7 9039
192.168.2.3 8732
192.168.1.182 5489
192.168.1.184 5170
192.168.1.187 4982
192.168.1.155 4826
Tabelle 5.3.: Die Ergebnisse der SQL-Abfrage in Listing 5.5
Laufzeit: ≈ 7 Minuten
Erklärung: In Abschnitt 5.3 wurde angenommen, dass ein Knoten wichtig
ist, wenn er beim Ausfall viele Routenveränderungen verursacht. Die Abfragen
dauerten recht lange. Im Listing 5.5 wird nun mit weniger Zeitaufwand ein
anderes Maß berechnet. Es gibt an, wie oft ein Knoten (direkt oder indirekt)
für die Internetverbindung eines anderen Knotens notwendig ist (also wie oft
er auf dessen Route liegt). Je mehr Knoten hierarchisch von einem Knoten
abhängig sind, desto wichtiger wird er. Theoretisch können die hier gefundenen
Knoten auch als Vorauswahl in Abschnitt 5.3 und 5.4 verwendet werden, um
die dortige Knotenmenge zu reduzieren.
Zuerst wird hier eine rekursive Funktion namens path angelegt, die alle Knoten,
die auf dem Weg zum nächsten Gateway liegen, für einen Knoten zurück
gibt. Sie hat die Komplexität O(log(n)). Die Rückgabe erfolgt als Array von
IP-Adressen. Als Parameter bekommt sie den Ausgangsknoten, für den der
Weg ermittelt werden soll, und das Ergebnis des Dijkstra-Algorithmus. Wie
im Abschnitt 3.1.3 schon erwähnt, gibt es in PL/pgSQL praktisch keine mehrdimensionalen,
dynamischen Arrays. Wesentlich einfacher als ein Workaround,
ist es den Knoten und dessen Vorgänger einfach per Komma getrennt in einer
Zeichenkette zu speichern. Somit ist der zweite Parameter der Funktion ein
Array von Strings. In diesem Dijkstra-Ergebnis wird der Vorgänger des gegebenen
Knotens gesucht und an die Ausgabe angehängt. Dies geschieht rekursiv
so lange, bis kein weiterer Vorgänger auffindbar ist.
Aufgrund des Geschwindigkeitsvorteils (durch die geringe Komplextität)
kann nun ein größerer Zeitraum zur Analyse gewählt werden, als in Abschnitt
5.4. Die erste innere Selektion (s1) wählt alle Timestamps und die zugehöri-
© Andreas Redmer — 29. September 2011 80

5. Testläufe - Beispiele für Datenabfragen
gen Ergebnisse des Dijkstra-Algorithmus von allen Daten aus, die an einem
Montag (Zeile 22), im Jahre 2011 (Zeile 21) und zu einer vollen Stunde (Zeile
20) aufgezeichnet wurden. Die Abfrage s2 wählt Knoten (ohne Duplikate) aus,
die in diesem Zeitraum vorhanden sind. Die Abfrage s3 bildet das Kreuzprodukt
(Timestamps × Knoten) und ruft für jedes erhaltene Paar die Funktion
path auf (Zeile 17). Die Ausgabe von s3 ist also der Pfad, von jedem Knoten
zu jedem Zeitpunkt, ins Internet. In s4 werden nochmal alle Knoten in dem
selben Zeitraum selektiert. Die Abfrage, die in Zeile 14 beginnt, fügt s3 und
s4 mit einem Inner Join zusammen, wobei die Bedingung für die Zusammenführung
ist, dass der Knoten aus s4 in dem Pfad aus s3 vorhanden ist (Zeile
38). Der Operator @> der dabei verwendet wird, ist in PostgreSQL der contains-Operator
für Arrays. In Zeile 14 wird nun gezählt, wie oft jeder Knoten
in diesem Join vorkam. Das Ergebnis wird nach diesem Zähler sortiert.
Fazit: Basierend auf den Daten, die an allen Montagen im Jahr 2011, zu
einer vollen Stunde aufgezeichnet wurden, ist das Gateway 10.2.0.247 auf den
meisten Routen vorhanden. An zweiter Stelle liegt das Gateway 192.168.0.254.
Die Nicht-Gateways 192.168.1.93, 192.168.1.111 und 192.168.2.7 sind die drei
aktivsten Router bezüglich der Anzahl der von Ihnen abhängigen Teilnehmer.
Ohne das beschränkende LIMIT 10 am Ende, gibt die Abfrage 129 Knoten zurück,
die in diesem Zeitraum überhaupt auf einer Route liegen. Alle anderen
Knoten sind nichtroutende Teilnehmer. Die Anzahl der Teilnehmer die zu diesen
Zeitpunkten überhaupt im Netzwerk ist beträgt 168. Dies ergibt sich wenn
die Ausgabe der Abfrage s4 gezählt wird.
© Andreas Redmer — 29. September 2011 81

5. Testläufe - Beispiele für Datenabfragen
5.6. Wichtige Knoten und Kanten
1 -- Abfrage 1: Wie oft ist ein Knoten Vorgaenger ?
2 select pred, count(d) from (
3 select (shortestpaths(time)).* from times
4 where time between (select max(time) from times) - interval’14 days’
5 and (select max(time) from times)
6 ) as s1
7 GROUP BY pred ORDER BY count DESC LIMIT 10
8
9 -- Abfrage 2: Wie oft ist eine Kante in den Routen enthalten ?
10 select node, pred, count(d) from (
11 select (shortestpaths(time)).* from times
12 where time between (select max(time) from times) - interval’14 days’
13 and (select max(time) from times)
14 ) as s1
15 GROUP BY node, pred ORDER BY count DESC LIMIT 10
Listing 5.6: Abfragen für Wichtigkeit von Knoten und Kanten
Ausgaben: sind in Tabelle 5.4 dargestellt
Abfrage 1 Abfrage 2
pred count node pred count
192.168.1.69 242885 192.168.2.3 192.168.2.7 20095
10.2.0.247 233442 192.168.1.52 192.168.2.3 20095
192.168.0.254 201877 192.168.2.4 192.168.2.3 20095
192.168.1.184 155214 192.168.10.2 192.168.0.254 20095
192.168.1.214 145658 192.168.10.3 192.168.0.254 20095
192.168.2.3 120120 192.168.2.7 192.168.0.254 20094
192.168.1.208 107194 192.168.2.6 192.168.2.5 20094
192.168.1.199 97647 192.168.1.126 192.168.2.3 20094
192.168.1.241 96574 192.168.2.5 192.168.2.8 20094
192.168.1.183 93700 192.168.2.8 192.168.0.254 20094
Tabelle 5.4.: Die Ergebnisse der SQL-Abfragen in Listing 5.6
Laufzeiten: jeweils ≈ 9 Minuten
Erklärung: In Abschnitt 5.3 wurde angenommen, dass ein Knoten wichtig
ist, wenn er beim Ausfall viele Routenveränderungen verursacht. In Abschnitt
5.5 wurde die Wichtigkeit nach der Anzahl der direkt und indirekt abhängigen
Knoten bestimmt. In Listing 5.6 (Abfrage 1) wurde nun eine noch einfachere
Abfrage verwendet, die einfach zählt, wie häufig ein Knoten als Vorgänger eines
anderen Knoten vorkommt. Dies ist nur ein bedingtes Maß für die Wichtigkeit,
© Andreas Redmer — 29. September 2011 82

5. Testläufe - Beispiele für Datenabfragen
da die gefundenen Knoten sehr weit unten in der Hierarchie sein können. Somit
sind sie nicht für das gesamte Netzwerk, sondern nur für die Knoten in der
direkten Nachbarschaft wichtig. Theoretisch könnte die Abfrage aus Listing
5.5 als Vorauswahl dienen wichtige Knoten zu finden, wobei die Abfrage 1 aus
Listing 5.6 dann die Qualität und Verfügbarkeit deren Nachbarschaftsknoten
prüfen könnte.
In Zeile 4 werden alle Timestamps ausgewählt, die im Zeitraum der letzten
14 aufgezeichneten Tage (genau 14 mal 24 Stunden) liegen. Die Abfrage s1
führt die shortestPaths-Funktion für diese Timestamps aus. Abfrage 1 zählt
dann, wie oft ein Knoten als Vorgänger vorgekommen ist.
In Abfrage 2 in Listing 5.6 wird genau das selbe für Kanten gemacht. Es
zeigt also an, wie häufig eine Kante in den Pfaden vorkam. Man erkennt hier
auch schnell, wie einfach alle Maße die zuvor für ”
wichtige“ Knoten verwendet
wurden auf einfache Weise auch für Kanten verwendet werden können. Weitere
Beispiele folgen dazu noch in den folgenden Abschnitten.
Fazit: In den letzten 14 Tagen der Datenaufzeichnungen war der Knoten
192.168.1.69 für seine direkte Nachbarschaft sehr wichtig, da er sehr häufig der
erste Schritt auf dem Pfad ins Internet war. Das Gateway 10.2.0.247 lag dabei
auf Platz zwei. In Abbildung 5.2 werden die zehn Kanten, die hier als wichtig
ermittelt wurden, grafisch dargestellt. Das Präfix ”
192.168.“ wurde dabei
aus Platzgründen weggelassen. Allerdings ist dieses Maß (für diesen Zeitraum)
nicht sehr aussagekräftig, denn die Werte liegen alle sehr dicht beieinander
(vgl. Tabelle 5.4).
✞ ☎
✝0.254
✆
✞ ☎
✝2.7
✆
✞ ☎
✝2.3
✆
✞ ☎
✝1.126
✆
✞ ☎
✝10.3
✆
✞ ☎
✝10.2
✆
✞ ☎
✝1.52
✆
✞ ☎
✝2.4
✆
✞ ☎
✝2.8
✆
✞ ☎
✝2.5
✆
✞ ☎
✝2.6
✆
Abbildung 5.2.: Graph der Kanten aus Tabelle 5.4
© Andreas Redmer — 29. September 2011 83

5. Testläufe - Beispiele für Datenabfragen
5.7. Routenänderungen bei Ausfall einer Kante
1 CREATE OR REPLACE FUNCTION shortestpaths_edge(timestamptz, inet, inet)
2 RETURNS SETOF PathElement AS $$ DECLARE
3 BEGIN
4 PERFORM truncateRootNodes();
5 PERFORM addRootNode (host(’192.168.0.254’::inet));
6 PERFORM addRootNode (host(’10.2.0.251’::inet));
7 PERFORM addRootNode (host(’10.2.0.247’::inet));
8 PERFORM addRootNode (host(’192.168.0.251’::inet));
9 PERFORM truncateLinks();
10 PERFORM addLink(host(nodea), host(nodeb), lq, lqn) from links
11 where time=$1
12 AND NOT((nodea=$2 AND nodeb=$3) OR (nodea=$3 AND nodeb=$2));
13
14 PERFORM run();
15 RETURN QUERY SELECT node,pred,d from getPathSet();
16 END; $$ STABLE LANGUAGE plpgsql;
17
18 CREATE OR REPLACE FUNCTION unterschied_edge(timestamptz,inet,inet)
19 RETURNS bigint AS $$
20 select count (*) from
21 ( ( select node,pred from shortestpaths($1) EXCEPT
22 select node,pred from shortestpaths_edge($1,$2,$3) )
23 UNION
24 ( select node,pred from shortestpaths_edge($1,$2,$3)
25 EXCEPT select node,pred from shortestpaths($1) )
26 ) s1 $$
27 STABLE LANGUAGE SQL;
28
29 select n,m,SUM(u) as Summe from (
30 SELECT time,n,m,unterschied_edge(time,n,m) as u FROM (
31 -- 10074 zeilen
32 SELECT distinct time, nodea as n, nodeb as m FROM links
33 WHERE time >= ’2011-03-11 00:00:00’
34 AND extract(minute FROM time)=0
35 AND extract(DOW FROM time) IN (0,6)
36 AND extract(hour FROM time) between 15 and 18
37 ) as s1
38 ) as s2
39 GROUP BY n,m ORDER BY Summe DESC LIMIT 10;
Listing 5.7: Abfrage nach Routenänderungen durch Wegfall einer Kante
© Andreas Redmer — 29. September 2011 84

5. Testläufe - Beispiele für Datenabfragen
Ausgabe: ist in Tabelle 5.5 dargestellt
n m Summe
192.168.1.93 192.168.1.111 522
192.168.1.111 192.168.1.197 516
192.168.1.155 192.168.1.197 492
192.168.1.155 192.168.1.166 468
192.168.1.111 192.168.1.112 447
192.168.1.180 192.168.1.187 431
192.168.1.69 192.168.1.180 415
192.168.1.112 192.168.1.214 400
192.168.2.3 192.168.2.7 366
192.168.1.182 192.168.1.184 290
Tabelle 5.5.: Das Ergebnis der SQL-Abfrage in Listing 5.7
Laufzeit: 367 Sekunden ( ≈ 6 Minuten)
Erklärung: Die Anfrage in Listing 5.7 löst ein Problem der Problemklasse
C, ist jedoch auch der erste Schritt beim Finden von Flaschenhälsen (Problemklasse
D). Sie streicht vor der Ausführung des Dijkstra-Algorithmus eine
Kante aus dem Graphen (dies simuliert den Ausfall der Kante) und führt dies
für jede Kante im Graphen aus. Die Komplexität erhöht sich dadurch um den
Faktor O(m). Die Ausgabe ist die Anzahl der Unterschiede, die in den Routen
entstehen, wenn die Kante (Verbindung) ausfällt. Die Anfrage ist sehr ähnlich
zu Listing 5.4. Nur war dort keine Verbindung zwischen beiden Knoten notwendig.
Hier wird nur die direkte Verbindung zwischen beiden angegebenen
Knoten gestrichen, sofern sie existiert.
Zunächst wurde wieder eine neue Variante der shortestPaths-Funktion erstellt,
die genau eine Kante ignorieren kann. Die Funktion heißt shortestpaths_edge
und hat nur in Zeile 12 eine angepasste Bedingung in der WHERE-
Klausel. Ansonsten funktioniert shortestpaths_edge genau wie shortestpaths_skip2
aus Listing 5.4.
Auch hier wird wieder eine Unterschiedsfunktion erstellt. Sie heißt unterschied_edge
(beginnend in Zeile 18) und berechnet das Maß für den nachfolgend
definierten Unterschied. Sei D E die Ausgabemenge des Algorithmus von
Dijkstra auf einem Graphen mit der Kantenmenge E und der Knotenmenge
V . Dann erzeugt die Kante (u, w) ∈ E (wobei u, w ∈ V ) einen Unterschied
von
|(D E \ D E\{(u,w),(w,u)} ) ∪ (D E\{(u,w),(w,u)} \ D E )|
wenn sie ausfällt.
© Andreas Redmer — 29. September 2011 85

5. Testläufe - Beispiele für Datenabfragen
Die erste innere Abfrage (s1) selektiert alle Timestamps und Kanten (ohne
Duplikate), die nach dem 11.03.2011 (Zeile 33), zu einer vollen Stunde (Zeile
34), zwischen 15 und 18 Uhr (Zeile 36) und an einem Wochenende (Zeile 35)
aufgezeichnet wurden. Dabei werden 10074 Timestamps ausgewählt. In Zeile
30 wird dann für jeden Timestamp und den zugehörigen Kanten einmal die
Funktion unterschied_edge aufgerufen. Die äußere Abfrage summiert alle
ermittelten Unterschiede pro Kante auf und sortiert die höchsten Summen
nach oben. Die Laufzeit kann mit
abgeschätzt werden.
10074 · 4 · 9ms = 362664ms ≈ 6min
Fazit: Basierend auf den nach dem 11.03.2011, zu einer vollen Stunde, zwischen
15 und 18 Uhr und an einem Wochenende aufgezeichneten Daten, würde
die Verbindung zwischen 192.168.1.93 und 192.168.1.111 die meisten Routen
verändern, wenn sie ausfallen würde. In Abbildung 5.3 werden die zehn
Kanten, die hier als wichtig ermittelt wurden, grafisch dargestellt. Das Präfix
192.168.“ wurde dabei aus Platzgründen weggelassen.
”
✞ ☎
✝1.214
✆
✞ ☎
✝ 2.7 ✆
✞ ☎
✝2.3
✆
✞ ☎ ✞ ☎ ✞ ☎ ✞ ☎
✝1.112 ✆ ✝1.197
✆ ✝1.166
✆ ✝1.187
✆
✞ ☎
✝ 1.184 ✆
✞ ☎
✝1.182
✆
✞ ☎
✝ 1.111 ✆
✞ ☎
✝1.93
✆
✞ ☎
✝1.155
✆
✞ ☎
✝ 1.180 ✆
✞ ☎
✝1.69
✆
Abbildung 5.3.: Graph aller Kanten aus Tabelle 5.5
© Andreas Redmer — 29. September 2011 86

5. Testläufe - Beispiele für Datenabfragen
5.8. Suche nach Flaschenhälsen
1 SELECT s4.nodea, s4.nodeb, count(s4.nodea) as w, s4.avg as alq
2 FROM
3 (
4 select s1.time, s2.nodea,
5 path (s2.nodea,array_agg(host(node) ||’,’|| host(pred)))
6 from
7 (
8 select t.time,(shortestpaths(t.time)).* from times t
9 where extract (minute from time)=0
10 AND extract (hour from time) between 14 AND 22
11 AND extract (DOW from time) IN (6,0)
12 AND time >=’2011-01-01 00:00:00’
13 ) as s1,
14 (
15 select distinct nodea from links
16 where extract (minute from time)=0
17 AND extract (hour from time) between 14 AND 22
18 AND extract (DOW from time) IN (6,0)
19 AND time >=’2011-01-01 00:00:00’
20 ) as s2
21 GROUP BY s1.time, s2.nodea
22 ) as s3,
23 (
24 select nodea, nodeb ,AVG((lq+lqn)/2) from links
25 where extract (minute from time)=0
26 AND extract (hour from time) between 14 AND 22
27 AND extract (DOW from time) IN (6,0)
28 AND time >=’2011-01-01 00:00:00’
29 GROUP BY nodea,nodeb
30 )as s4
31 where POSITION ((host(s4.nodea)||’,’||host(s4.nodeb))
32 IN (host(s3.nodea) ||’,’||array_to_string(s3.path,’,’))) >0
33 GROUP BY s4.nodea,s4.nodeb,alq
34 ORDER BY w DESC LIMIT 10;
Listing 5.8: Abfrage der Kanten die häufig auf der Route eines Knotens liegen
© Andreas Redmer — 29. September 2011 87

5. Testläufe - Beispiele für Datenabfragen
Ausgabe: ist in Tabelle 5.6 dargestellt
nodea nodeb w alq
192.168.2.3 192.168.2.7 7002 0.996162393663684
192.168.1.187 192.168.2.3 4008 0.999786956932234
192.168.1.155 192.168.1.197 3922 0.964632478279945
192.168.1.180 192.168.1.187 3377 0.968367520560566
192.168.1.69 192.168.1.180 3143 0.999843477166217
192.168.1.143 192.168.1.166 2469 0.972499997952046
192.168.1.208 192.168.1.214 1364 0.674356127966125
192.168.1.126 192.168.2.3 1289 1
192.168.1.140 192.168.1.166 978 0.896254852848146
192.168.2.5 192.168.2.8 914 0.998369659114088
Tabelle 5.6.: Das Ergebnis der SQL-Abfrage in Listing 5.8
Laufzeit: 608 Sekunden ( ≈ 10 Minuten)
Erklärung: In Listing 5.8 wird versucht Flaschenhälse (also Engstellen) auf
den Routen zu finden. Dies fällt in die Problemklasse D. Dabei wird einerseits
ein Maß für die Wichtigkeit von Kanten berechnet (Spalte w in der Ausgabe),
indem geprüft wird, in wie vielen Routen die Kante vorkommt. Dies geschieht
analog zu Listing 5.5. Die dort bereits definierte Funktion path wird auch hier
verwendet. Andererseits wird auch die durchschnittliche Qualität der Verbindung
(Spalte alq in der Ausgabe) gegenübergestellt. Die Suche nach möglichen
Flaschenhälsen erfolgt im Anschluss manuell, da im Rahmen dieser Arbeit kein
gutes Maß für die Eigenschaft gefunden wurde, dass ein Knoten wahrscheinlich
eine kritische Engstelle ist. Eine solche Eigenschaft berechnet sich aus:
w · f()
alq
wobei f() eine unbekannte Funktion ist. Diese könnte konstant sein, kann aber
ebenso von anderen Faktoren (wie w, alq oder der Anzahl der Knoten in der
Ergebnismenge) abhängig sein. Wichtig ist dabei, dass Verbindungen mit hoher
Wichtigkeit auch eine hohe Qualität haben sollten.
Im Abschnitt 1.4 wurde zum Finden von Flaschenhälsen ein anderes Verfahren
beschrieben. Dabei wurde jeweils die Kante mit der geringsten Qualität auf
einer bestehenden Route gesucht. Das wird hier nicht getan. Listing 5.8 ignoriert
den konkreten Zusammenhang zwischen Wichtigkeit und Qualität einer
Kante zu einem bestimmten Zeitpunkt. Vielmehr wird der Durchschnittswert
über mehrere Zeitpunkte ermittelt. Demnach könnte eine Kante, die bei starker
Nutzung eine hohe Qualität hat und bei sehr geringer Qualität auch nicht
© Andreas Redmer — 29. September 2011 88

5. Testläufe - Beispiele für Datenabfragen
genutzt wird (was eigentlich in Ordnung ist), durch die Durchschnittsbildung,
schon als Problemstelle erkannt werden.
Die Abfrage s1 wählt zunächst alle Timestamps aus, die nach dem 01.01.2011
(Zeile 12), an einem Wochenende (Zeile 11), zu einer vollen Stunde (Zeile 9)
und zwischen 14 Uhr und 22 Uhr (Zeile 10) aufgezeichnet wurden. Gleichzeitig
werden alle geltenden Routen für diese Zeitpunkte berechnet. Die Abfrage s2
wählt alle Knoten (ohne Duplikate) aus, die in diesem Zeitraum vorhanden
waren. In s3 wird das Kreuzprodukt aus s1 und s2 erstellt. Dabei wird für
jedes erhaltene Paar (Timestamp, Knoten) der Pfad ins Internet berechnet. In
s4 werden alle Kanten (ohne Duplikate), die in diesem Zeitraum existierten
und ihre durchschnittliche Qualität ermittelt. Zum Schluss werden die Ergebnisse
von s3 und s4 mit einem Inner Join verbunden und zwar immer genau
dann, wenn die Kante aus s4 in dem Pfad aus s3 vorkommt. In diesem Fall
wird auch der Anfangsknoten selbst als Teil des Pfades betrachtet (was in Listing
5.5 nicht nötig war). Dafür wird nicht der contains-Operator für Arrays
verwendet, sondern ein Vergleich zweier Zeichenketten durchgeführt (Zeile 31
und 32), da die beiden Elemente genau nacheinander auf der Route stehen
müssen. Am Ende wird die Ausgabe nach Wichtigkeit der Kante sortiert, während
die durchschnittliche Qualität nur als zusätzliche Information ausgegeben
wird. Mit dieser zusätzlichen Information ist es möglich, von den wichtigsten
Kanten, die möglichen Problemstellen zu finden.
Fazit: Gemessen an den Daten, die seit dem 01.01.2011, am Wochenende,
zwischen 14 und 22 Uhr zu einer vollen Stunde aufgezeichnet wurden. Ist die
Verbindung zwischen 192.168.2.3 und 192.168.2.7 mit Abstand die Wichtigste.
Die Verbindung zwischen 192.168.1.208 und 192.168.1.214 liegt auf Platz
7 und ist damit ebenfalls sehr wichtig. Sie hat allerdings nur eine durchschnittliche
Qualität von 0, 67 (das heißt nur etwa zwei Drittel aller Pakete kommen
an). Diese Verbindung ist (in diesen Nutzungszeiten) höchstwahrscheinlich eine
Problemstelle. Es sollte untersucht werden, welche Art von Verbindung dort
besteht und ob sie durch geeignete Maßnahmen verbessert werden kann.
© Andreas Redmer — 29. September 2011 89

6. Zusammenfassung und Ausblick
6. Zusammenfassung und Ausblick
6.1. Zusammenfassung
In dieser Arbeit wurde ein Konzept vorgestellt, dass die Performance der Datenanalyse
von Netzwerkgraphen unter Verwendung von UDF stark beschleunigt.
Die Berechnung der gültigen Routen für einen Zeitpunkt dauert nun
nur noch neun Millisekunden, statt vorher vier Sekunden. Weiterhin wurde die
Usability dadurch so verändert, dass eine Datenanalyse nun mit Hilfe von SQL
erfolgen kann. Dabei sind Abfragen aus allen vorher definierten Problemklassen
möglich. Zusätzlich kann die Datenanalyse in-place erfolgen, ohne dass die
Daten zu einem schnelleren Computer (bzw. in eine Cloud) transportiert werden
müssen. Es stellte sich heraus, dass PL/Java-UDF auf dem PostgreSQL-
Server die beste Usability und Performance bieten um die Datenanalyse direkt
auf dem SQL-Server stattfinden zu lassen. Die einzige nötige Umstellung ist
der Wechsel des DBMS von MySQL auf PostgreSQL oder zumindest eine zusätzliche
Installation eines PostgreSQL-Servers. Das Programm, dass die Datenaufzeichnung
vornimmt, kann durch eine minimale Änderung auf den neuen
Server umgestellt werden.
Zunächst wurde jedoch die Komplexität der Implementierung von Mundt
und Vetterick [22] untersucht. Dabei wurde festgestellt, dass diese in einer zu
hohen Komplexitätsklasse liegt und algorithmisch optimiert werden müsste.
Die Implementierung des Dijkstra-Algorithmus, in einer besseren Komplexitätsklasse,
beschleunigte ihn sehr stark. Es wurden einige weitere algorithmische
Performanceoptimierungen vorgenommen. Der in der Praxis bewährte
und sehr übliche Fibonacci-Heap beschleunigt auch in diesem Fall die Ausführung.
Außerdem wurde mit der General-Gateway-Strategie eine Vorgehensweise
entdeckt, die dafür sorgt, dass die kürzesten Wege jetzt nur noch einmal pro
Graph und nicht mehrmals pro Graph (für je ein Gateway) ausgeführt werden
muss. Weitere Optimierungen des Dijkstra-Algorithmus, die ihn beschleunigen,
indem sie ihn früher abbrechen lassen, konnten im Rahmen dieser Arbeit
aufgrund der Problemstellung nicht eingesetzt werden.
Einen optimierten Programmierstil zu verwenden, hat nur geringfügige Verbesserungen
mit sich gebracht. Das lag insbesondere daran, dass die modernen
Compiler schon sehr gut optimieren, und dass die Lesbarkeit und Erweiterbar-
© Andreas Redmer — 29. September 2011 90

6. Zusammenfassung und Ausblick
keit der UDF nicht unermesslich verschlechtert werden sollten. Wichtig ist es,
bei der Implementierung einen konstanten (sehr hohen) Wert für ∞ und die
Adjazenzmatrix statt einer Liste zu verwenden. Durch die sehr geringe Größe,
der hier verwendeten Graphen, brauchte die Optimierung des Speicherplatzes
nicht beachtet zu werden.
Im Rahmen dieser Arbeit ist es nicht gelungen, durch Parallelisierung mehrerer
Dijkstra-Berechnungen noch weitere Beschleunigungen zu erreichen. Zwar
können mehrere Abfragen auf einem Server mit Multi-Core-CPU gleichzeitig
ausgeführt werden, jedoch muss dies immer manuell geschehen. Der Versuch
eine Multi-Core-Schnittstelle per UDF bereit zu stellen, endete darin, dass die
Usability zu sehr eingeschränkt war. Damit konnte nur sehr aufwändig und
auch nur eine bestimmte Problemklasse angefragt werden. Mehrere Dijkstra-
Berechnungen müssen also weiterhin parallel, von mehreren Clients an den
Server gesendet werden. Eine Parallelisierung des Dijkstra-Algorithmus selbst
(auf CPU und GPU) brachte keinen Geschwindigkeitsvorteil. Das Hauptproblem
war dabei jeweils, dass die Graphen mit ca. 200 Knoten viel zu klein sind
um sie durch parallele Verarbeitung zu beschleunigen. Diese Möglichkeiten sind
also zukünftig nur für sehr große Graphen interessant.
Durch eine Reihe beispielhafter SQL-Anfragen wurde die Verwendung der
erstellten UDF demonstriert und die Einsatzgebiete aufgezeigt. Für die spätere
Verwendung durch einen Datenanalysten sind die Spezifikation der UDF
(Abschnitt 3.2) und die Beispielanfragen im Kapitel 5 gute Einstiegspunkte.
Die vorgestellten SQL-Abfragen weisen teilweise sehr hohe Laufzeiten auf, so
dass auch jeweils Methoden zur vorherigen Abschätzung des Zeitaufwandes
angegeben wurden. Dabei wird nochmal sehr eindrucksvoll deutlich, wie stark
sich die Verbesserung von vier Sekunden auf neun Millisekunden auf die späteren
Datenanalysen auswirkt. Komplexe Datenanalysen waren vorher nicht
effizient möglich. Die gezeigten Datenanalysen konnten auch vorher schon gemacht
werden, jedoch weder schnell noch komfortabel. Insbesondere bietet die
Datenbank der Google-Cloud eine so eingeschränkte Anfragesprache, dass die
Analyse fast immer in einem gesonderten Programm nach der Abfrage der
Daten passieren muss.
6.2. Ausblick
Weitere Optimierung
Für die Topology-Control-Daten des Opennet-Netzwerkes ist eine weitere signifikante
Beschleunigung des Dijkstra-Algorithmus in Zukunft unwahrscheinlich.
© Andreas Redmer — 29. September 2011 91

6. Zusammenfassung und Ausblick
Jedoch nimmt der Dijkstra weniger als 12% der gesamten Laufzeit der UDF
in Anspruch. Der Transport der Daten zur und aus der UDF dauert relativ
lange. Wobei nicht nicht klar ist, ob der Datenbankserver und die Selektion
der Daten vor der UDF dabei zu langsam ist oder die Aufbereitung der Daten
nach der UDF-Ausführung oder die Kommunikation zwischen PostgreSQL-
SPI und der Java-VM so langsam ist. Die PL/Java-Schnittstelle zum SPI ist
keinesfalls inperformant programmiert. Dennoch wäre es interessant, ob die
Ausführung von kompilierten UDF in der Programmiersprache C die Ausführung
beschleunigen. Weiterhin könnte auch ein kommerzielles DBMS (wie DB2
oder Oracle) testweise für solche UDF verwendet werden. Eventuell lassen sich
dadurch noch wesentlich bessere Ergebnisse erzielen. Dazu sind künftig noch
weitere Untersuchungen nötig.
Wenn das hier vorgestellte Konzept für sehr große Graphen eingesetzt werden
soll, kann durchaus auf die vorgestellten Möglichkeiten zur Parallelisierung
zurückgegriffen werden. Auch die Verwendung der GPU auf der Grafikkarte ist
technisch in PL/Java-UDF möglich. Dadurch, dass insbesondere der Transport
in den Speicher der Grafikkarte sehr langsam war, ist es durchaus denkbar, dass
die GPU auch Vorteile bringt, wenn wesentlich komplexere Algorithmen berechnet
werden sollen. Beispielsweise die Berechnung minimaler Spannbäume
oder die Lösung des Cliquenproblems könnte auf der GPU durchaus schneller
sein. Auch die in dieser Arbeit vorgestellten Algorithmen, die nur einen
Knoten oder eine Kante aus dem Graphen streichen und dann den Dijkstra-
Algorithmus erneut berechnen, könnten in dedizierte PL/Java-UDF (mit oder
ohne GPU-Support) programmiert werden, um eine weitere Beschleunigung zu
erreichen. Inwiefern dies in Zukunft sinnvoll ist, hängt davon ab, wie oft ein
bestimmtes Problem aus einer bestimmten Problemklasse gelöst werden muss.
In jedem Fall liefert diese Arbeit alle Grundlagen für derartige Erweiterungen.
An dieser Stelle sei noch bemerkt, dass die in Kapitel 5 vorgestellten Analysen
selbst auch noch nicht performanceoptimiert erstellt sind. Die dortigen
Abfragen und die neuen Funktionen (z. B. unterschied oder path) können
noch beschleunigt werden. Sie sind dort nur sehr einfach und in kurzer Schreibweise
dargestellt. Weitere Beschleunigungen sind auch durch die Verwendung
der Mechanismen im DBMS wie z. B. Indizes, gespeicherte Anfagepläne oder
zwischengespeicherte Teilergebnisse (Materialisierung) möglich.
Sollte die Berechnung in der Cloud trotz ihrer Nachteile zukünftig weiterhin
eine Alternative darstellen, so bietet diese Arbeit eine gute Einführung in eine
effiziente Dijkstra-Implementierung. Die hier vorgenommenen algorithmischen
Verbesserungen (insbesondere die General-Gateway-Strategie) sollte auch zukünftig
übernommen werden.
© Andreas Redmer — 29. September 2011 92

6. Zusammenfassung und Ausblick
Datenanalyse
Die SQL-Abfragen die in Kapitel 5 vorgestellt wurden, zeigen das große Potential
auf, für das die erschaffenen UDF künftig eingesetzt werden können.
Dabei wurden je drei verschiedene Maße vorgestellt, mit denen zukünftig die
Wichtigkeit der Knoten und Kanten festgestellt werden kann. Mit den Abfragen
aus der Problemklasse B und C und entsprechend neuen Erkenntnissen ist
unter Umständen eine Verbesserung des Routing-Protokolls und eine bessere
Netzplanung möglich.
In dieser Arbeit wurden auch zwei Möglichkeiten beschrieben, um mögliche
Flaschenhälse im Netzwerk zu bestimmen. Dies fällt in die Problemklasse D.
Dazu wird auf die Ergebnisse der Problemklasse B aufgebaut. Dadurch können
zukünftig Schwachstellen im Netzwerk gefunden und verbessert werden.
Für die Problemklasse E (das Finden von Alternativrouten) wurde in dieser
Arbeit kein Beispiel angegeben. Der Algorithmus von Yen (vgl. [33]) wurde
nicht in die PL/Java-UDF eingebaut um die Usability nicht zu beeinträchtigen.
Es ist jedoch möglich, mit den vorgestellten SQL-Anfragen, einzelne Verbindungen
(auf dem ”
besten“ Pfad) aus dem Graphen zu streichen und dann den
Dijkstra erneut auszuführen und die entstehenden Alternativrouten zu prüfen.
Auch dafür kann auf die Ergebnisse der Problemklasse B aufgebaut werden.
Das ist auch das, was der Algorithmus von Yen im Wesentlichen tut, jedoch in
einer besseren Komplexitätsklasse (also schneller). Ob es zukünftig nötig ist,
den Algorithmus von Yen in eine gesonderte PL/Java-UDF zu implementieren,
hängt davon ab, wie stark die Nachfrage nach solchen Ergebnissen ist.
Auch weitere noch nicht genannte Problemklassen lassen sich nach Bedarf
in neue PL/Java-UDF implementieren, wenn sich diese zukünftig als relevant
ergeben sollten. Die Möglichkeit die Daten aus der Datenbank in eine
Java-Klasse zu importieren, ist bereits geschaffen. Es muss also nur noch der
Algorithmus selbst integriert werden, wobei durchaus eine bestehende Java-
Implementierung genutzt werden kann. Die Ausgabe des Ergebnisses unterscheidet
sich meist von der beim Dijkstra. Demnach muss für neue Probleme
eine neue Rückgabefunktion geschaffen werden und die Funktionen müssen
auch in einem anderen SQL-Kontext aufgerufen werden. Dies gilt z. B. für das
Finden minimaler Spannbäume, k-Cliquen, Zyklen, Minoren, Stabilitätszahlen,
Paarungen, Flüssen, Schnitten, Hamiltonkreisen und vielen mehr. Einige neue
Problemstellungen können auch mit den bestehenden Funktionen und dem
Dijkstra-Algorithmus gelöst werden. Beispielsweise kann eine Partitionierung
des Graphen mit den bestehenden Funktionen gefunden werden. Ein Verfahren
dazu ist im Anhang B vorgestellt.
© Andreas Redmer — 29. September 2011 93

Literaturverzeichnis
Literaturverzeichnis
1 ApacheSoftwareFoundation: The Apache Cassandra Project Webseite.
2011. – URL http://cassandra.apache.org/. – Zugriffsdatum:
07.08.2011
2 Badis, Hakim ; Al Agha, Khaldoun: QOLSR, QoS routing for ad hoc
wireless networks using OLSR. In: European Transactions on Telecommunications
16 (2005), Nr. 5, S. 427–442. – URL http://dx.doi.org/10.
1002/ett.1067. – ISSN 1541-8251
3 Bellman, R. E.: On a Routing Problem. In: Quarterly of Applied Mathematics
16 (1958), Nr. 1, S. 87–90
4 Brodal, Gerth S. ; Träff, Jesper L. ; Zaroliagis, Christos D.: A
Parallel Priority Queue with Constant Time Operations. In: Journal of
Parallel and Distributed Computing 49 (1998), S. 4–21
5 Chang, Fay ; Dean, Jeffrey ; Ghemawat, Sanjay ; Hsieh, Wilson C. ;
Wallach, Deborah A. ; Burrows, Mike ; Chandra, Tushar ; Fikes,
Andrew ; Gruber, Robert E.: Bigtable: A Distributed Storage System for
Structured Data. In: ACM Trans. Comput. Syst. 26 (2008), June, S. 4:1–
4:26. – URL http://doi.acm.org/10.1145/1365815.1365816. – ISSN
0734-2071
6 Clausen, Thomas ; Jacquet, Philippe ; Adjih, Cédric ; Laouiti, Anis ;
Minet, Pascale ; Muhlethaler, Paul ; Qayyum, Amir ; Viennot, Laurent:
Optimized Link State Routing Protocol (OLSR). In: Network Working
Group Request for Comments : 3626 Category : Experimental (2003)
7 Couto, Douglas S. J. D. ; Aguayo, Daniel ; Bicket, John ; Morris,
Robert: a high-throughput path metric for multi-hop wireless routing.
In: Wireless Networks 11 (2005), S. 419–434. – URL http://dx.doi.
org/10.1007/s11276-005-1766-z. – 10.1007/s11276-005-1766-z. – ISSN
1022-0038
8 Dijkstra, Edsger W.: A note on two problems in connexion with graphs.
In: Numerische Mathematik 1 (1959), S. 269–271
9 Dinic, E. A.: Algorithm for solution of a problem of maximum flow in a
network with power estimaton. (1970), S. 1277–1280
© Andreas Redmer — 29. September 2011 94

Literaturverzeichnis
10 Driscoll, J.R. ; Gabow, H.N. ; Shrairman, R. ; Tarjan, R.E.: Relaxed
heaps: An alternative to Fibonacci heaps with applications to parallel
computation. In: Assoc. Comput. (1988), 03, Nr. 11, S. 1343–1354
11 Edmonds, J. ; Karp, Richard M.: Theoretical Improvements in Algorithmic
Efficiency for Network Flow Problems. In: Journal of ACM 18 (1972),
S. 248–264
12 Ellis, Jonathan: Cassandra Summit - The State of Cassandra. Video.
12. August 2010. – URL http://riptano.blip.tv/file/4011925/. –
Zugriffsdatum: 18.08.2011
13 Floyd, Robert W.: Algorithm 97 (SHORTEST PATH). In: Communications
of the ACM 5 (1962), Nr. 6, S. 345
14 Forbrig, Peter: Introduction to Programming by Abstract Data Types.
Leipzig : Fachbuchverlag, 2001. – ISBN 3-446-21782-7
15 Ford, Lester R. ; Fulkerson, Delbert R.: Maximal flow through a network.
In: Canadadian Journal of Mathematics 8 (1956), S. 399–404
16 Fredman, Michael L. ; Tarjan, Robert E.: Fibonacci heaps and their
uses in improved network optimization algorithms. In: J. ACM 34 (1987),
July, S. 596–615. – URL http://doi.acm.org/10.1145/28869.28874. –
ISSN 0004-5411
17 Harish, Pawan ; Narayanan, P. J.: Accelerating large graph algorithms
on the GPU using CUDA. In: IEEE High Performance Computing (2007),
S. 197–208
18 Hart, P. E. ; Nilsson, N. J. ; Raphael, B.: A Formal Basis for the
Heuristic Determination of Minimum Cost Paths. In: IEEE Transactions
on Systems Science and Cybernetics SSC 4 (1968), Nr. 2, S. 100–107
19 Hutter, Marco: JUDA - Java bindings for CUDA. 2011. – URL http:
//www.jcuda.org/. – Zugriffsdatum: 14.08.2011
20 ItNovum: Whitepaper: Open Source-Datenbanken. 2011. - URL
http://www.it-novum.com/download/downloads/whitepaper-opensource-datenbanken.html
- Zugriffsdatum 15.08.2011
21 JUnit: JUnit Webseite. 2011. – URL http://www.junit.org/. – Zugriffsdatum:
28.05.2011
22 Mundt, Thomas ; Vetterick, Jonas: Network Topology Analysis in the
Cloud. In: ICOMP’11 - The 2011 International Conference on Internet
Computing, July 2011
23 Naveh, Barak: JGraphT - a free Java Graph Library. 2005. – URL
http://www.jgrapht.org/. – Zugriffsdatum: 15.08.2011
© Andreas Redmer — 29. September 2011 95

Literaturverzeichnis
24 Opennet: Opennet e.V. Webseite. 2011. – URL http://wiki.
opennet-initiative.de/. – Zugriffsdatum: 05.06.2011
25 Oracle: Java API Onlinedokumentation. 2011. – URL
http://download.oracle.com/javase/1.4.2/docs/api/. – Zugriffsdatum:
27.05.2011
26 Oracle: Java API Onlinedokumentation der Klasse SYSTEM. 2011.
– URL http://download.oracle.com/javase/1,5.0/docs/api/java/
lang/System.html. – Zugriffsdatum: 27.05.2011
27 pgAdmin: pgAdmin: PostgreSQL administration and management tools.
2011. – URL http://www.pgadmin.org/. – Zugriffsdatum: 21.08.2011
28 RefractionsResearch: PostGIS Webseite. 2011. – URL http:
//postgis.refractions.net/. – Zugriffsdatum: 21.05.2011
29 Stentz, Anthony: Real-Time Replanning in Dynamic and Unknown Environments.
2000. – URL http://www.frc.ri.cmu.edu/~axs/dynamic_
plan.html. – Zugriffsdatum: 27.05.2011
30 Stonebraker, M. ; Rowe, L.A. ; Hirohama, M.: The implementation
of POSTGRES. In: Knowledge and Data Engineering, IEEE Transactions
on 2 (1990), mar, Nr. 1, S. 125 –142. – ISSN 1041-4347
31 Stonebraker, Michael ; Kemnitz, Greg: The POSTGRES next generation
database management system. In: Commun. ACM 34 (1991), October,
S. 78–92. – URL http://doi.acm.org/10.1145/125223.125262. – ISSN
0001-0782
32 Straube, Georgi: Bachelorarbeit - Cloud Computing zur Optimierung einer
Netzwerkpartitionierung, Universität Rostock, Fakultät für Informatik
und Elektrotechnik. August 2011
33 Yen, J. Y.: Finding the k shortest loopless paths in a network. In: Management
Science 17 (1971), S. 712–716
© Andreas Redmer — 29. September 2011 96

A. Anhang: SQL Anfragen
A. Anhang: SQL Anfragen
A.1. Anzahl neuer Datensätze pro Minute
1 --count average new datasets per minute
2 select avg(count) from (
3 -- count number of datasets per minute
4 select time,count(*) from links
5 where time between
6 -- 3 weeks before last date
7 (select max(time)from times)-interval’3 weeks’
8 and
9 -- last date
10 (select max(time)from times)
11 group by time
12 ) as s1;
13 -- Ausgabe: 852.3924772162386081
Listing A.1: Abfrage der Anzahl neuer Datensätze pro Minute
Listing A.1 zeigt die durchschnittliche Anzahl der Datensätze pro Timestamp
in den letzten drei Wochen der Aufzeichnung. Dies ist etwa die Anzahl
der Datensätze, die pro Minute zum Datenbestand hinzu kommen.
© Andreas Redmer — 29. September 2011 i

A. Anhang: SQL Anfragen
A.2. Prüfung der Vollständigkeit der Daten
1 -- korrekt aufgezeichnete Timestamps nach Anzahl der Eintraege
2 -- pro Timestamp
3 select count (*) from (
4 select time,count(*) c from links
5 group by time
6 having count(*) between 44 and 1600
7 ) as s1
8 -- Ausgabe: 334829 (korrekte)
9
10
11 -- Timestamps pro Stunde = 60
12 select count(c) FROM
13 (
14 select date_trunc(’hour’, time),count (*) c from times
15 --skip first hour (always incomplete!)
16 WHERE time >
17 date_trunc(’hour’, timestamp ’2010-04-07 14:20:02’+interval ’1 hour’)
18 --skip last hour (always incomplete!)
19 AND time <
20 date_trunc(’hour’, timestamp ’2011-03-28 17:41:02’-interval ’1 hour’)
21 group by date_trunc(’hour’, time)
22 having count (*) = 60
23 )as s1;
24 -- Ausgabe: 5570 (richtige) (Hinweis: alle: 5586 und falsche: 16)
25
26
27 -- Timestamps pro Tag = 1440
28 select count(c) FROM
29 (
30 select date_trunc(’day’, time),count (*) c from times
31 --skip first day (always incomplete!)
32 WHERE time >= ’2010-04-08 00:00:00’
33 --skip last day (always incomplete!)
34 AND time < ’2011-03-28 00:00:00’
35 group by date_trunc(’day’, time)
36 having count (*) = 1440
37 )as s1;
38 -- Ausgabe: 223 (richtige) (Hinweis: alle: 235 und falsche: 12)
39
40
41 -- Timestamps pro Woche = 10080
42 select count(c) FROM
43 (
44 select EXTRACT(WEEK FROM time),count (*) c from times
45 --skip first week (always incomplete!)
46 WHERE time >= ’2010-04-12 00:00:00’
47 --skip last week (always incomplete!)
48 AND time < ’2011-03-28 00:00:00’
49 group by EXTRACT(WEEK FROM time)
50 having count (*) = 10080
51 )as s1;
52 -- Ausgabe: 25 (richtige) (Hinweis: alle: 35 und falsche: 10)
Listing A.2: Abfrage der Vollständigkeit der Daten
© Andreas Redmer — 29. September 2011 ii

A. Anhang: SQL Anfragen
1 -- (min,max,avg) aller Luecken in den Daten
2 SELECT min(diff),max(diff),avg(diff) FROM (
3 SELECT t1t,t2t,t2t-t1t diff FROM (
4 SELECT date_trunc (’minute’,t1.time) t1t ,date_trunc (’minute’,t2.time)
5 t2t FROM times t1, times t2
6 WHERE t2.time = (SELECT MIN(time) FROM times t3 WHERE t3.time >t1.time)
7 ) as s1
8 where t2t-t1t > interval’1 minute’
9 ) as s2;
10 --Ausgabe:
11 --min:"00:02:00"
12 --max:"108 days 04:30:00"
13 --avg:"8 days 18:05:17.142857"
14
15
16 -- Abfrage der Luecken selbst
17 SELECT date_trunc (’day’,t1t), min(diff),max(diff),avg(diff)
18 FROM (
19 SELECT t1t,t2t,t2t-t1t diff FROM (
20 SELECT date_trunc (’minute’,t1.time) t1t ,date_trunc (’minute’,t2.time)
21 t2t FROM times t1, times t2
22 WHERE t2.time =
23 (SELECT MIN(t3.time) FROM times t3 WHERE t3.time >t1.time)
24 ) as s1
25 where t2t-t1t > interval’1 minute’
26 ) as s2
27 GROUP BY date_trunc (’day’,t1t);
28
29 -- Ausgabe:
30 -- "2010-04-07 14:38:00+02";"2010-04-07 14:41:00+02";"00:03:00"
31 -- "2010-05-22 23:02:00+02";"2010-05-24 11:23:00+02";"1 day 12:21:00"
32 -- "2010-05-24 11:35:00+02";"2010-09-09 16:05:00+02";"108 days 04:30:00"
33 -- "2010-09-10 12:21:00+02";"2010-09-10 12:23:00+02";"00:02:00"
34 -- "2010-09-10 12:26:00+02";"2010-09-10 13:00:00+02";"00:34:00"
35 -- "2010-09-20 13:56:00+02";"2010-09-20 14:38:00+02";"00:42:00"
36 -- "2010-09-21 14:42:00+02";"2010-09-21 16:33:00+02";"01:51:00"
37 -- "2010-10-31 01:59:00+02";"2010-10-31 02:00:00+01";"01:01:00"
38 -- "2010-11-27 13:42:00+01";"2010-12-09 14:46:00+01";"12 days 01:04:00"
39 -- "2011-01-17 17:13:00+01";"2011-01-17 17:15:00+01";"00:02:00"
40 -- "2011-02-09 07:24:00+01";"2011-02-09 22:19:00+01";"14:55:00"
41 -- "2011-03-28 17:05:00+02";"2011-03-28 17:08:00+02";"00:03:00"
42 -- "2011-03-28 17:25:00+02";"2011-03-28 17:27:00+02";"00:02:00"
43 -- "2011-03-28 17:31:00+02";"2011-03-28 17:35:00+02";"00:04:00"
Listing A.3: Abfrage der Lücken in der Datenaufzeichnung
Listing A.2 zeigt die Abfragen für die Tabelle 1.3 auf Seite 5. Listing A.3
zuerst die Abfrage der minimalen, durchschnittlichen und maximalen Länge
einer Lücke in den Aufzeichnungen. Danach zeigt es die Abfrage die die Lücken
selbst ausgibt. Dazu wird jedem Timestamp sein Nachfolger zugeordnet und
dann werden alle Paare angezeigt die mehr als eine Minute auseinander liegen.
Die Ausgabe (14 Lücken) ist darunter als Kommentar eingefügt.
© Andreas Redmer — 29. September 2011 iii

A. Anhang: SQL Anfragen
A.3. Prüfung der Korrektheit der Daten
1 --constraint 1
2 select count (*)from links where lq >0 or lqn >0;
3 -- Ausgabe: 278850737
4
5 --constraint 2
6 select count (*)from links where lq

A. Anhang: SQL Anfragen
A.4. Maximale Knotenanzahl auf kürzesten
Pfaden
1 CREATE OR REPLACE FUNCTION path(inet,varchar[]) RETURNS inet[]
2 AS $$ DECLARE p INET; pa INET[];
3 BEGIN
4 SELECT min(pred) INTO p FROM (
5 SELECT (string_to_array(unnest, ’,’))[1] as node,
6 (string_to_array(unnest, ’,’))[2] as pred
7 FROM unnest($2) ) as s1
8 WHERE node = host($1);
9 IF p IS NOT NULL THEN pa = pa || path(p,$2); END IF;
10 RETURN p||pa;
11 END;
12 $$ STABLE LANGUAGE plpgsql;
13
14 SELECT avg(array_length),max(array_length) FROM
15 (
16 select s1.time, s2.nodea, array_length(
17 path(s2.nodea,array_agg(host(node)||’,’||host(pred))),1)
18 from(
19 select t.time,(shortestpaths(t.time)).* from times t
20 where extract (minute from time)=0 and
21 time >= (select max (time) from times)-interval’14 days’
22 ) as s1,
23 (
24 -- selects 189 nodes
25 select distinct nodea from links
26 where extract (minute from time)=0 and
27 time >= (select max (time) from times)-interval’14 days’
28 ) as s2
29 GROUP BY s1.time, s2.nodea
30 ) as s3;
31 --Ausgabe : avg:4.8187159440890784, max: 19
Listing A.5: Abfrage der Durchschnittlichen und maximalen Pfadlänge der
kürzesten Pfade
Listing A.5 zeigt eine Abfrage, die die durschnittliche und maximale Anzahl
der Knoten auf den gefundenen kürzesten Wegen bestimmt. Dafür wird die
gleiche path-Funktion verwendet, die auch in Listing 5.5 (Seite 79) verwendet
wird. Es wurden nur Timestamps betrachtet, die in den letzten zwei Wochen
der Aufzeichnung zu einer vollen Stunde aufgezeichnet wurden.
Wie ist das Verhältnis von maximaler Pfadlänge zur Knotenanzahl?
Für die Komplexitätbetrachtung ist es wichtig zu wissen, welches Verhältnis
zwischen Knotenanzahl (n) und maximaler Pfadlänge besteht. Im kartesischen
Einheitgitter 18 (wie z. B. in Abbildung A.1) enthält ein kürzester Weg nie mehr
als 2 √ n Knoten.
18 Ein quadratisches Gitter indem nur horizontale und vertikale Kanten existieren, deren
Kantengewichte alle gleich 1 sind.
© Andreas Redmer — 29. September 2011 v

A. Anhang: SQL Anfragen
N (1,1)
N (1,2)
N (1,3)
N (1,4)
N (1,5)
N (1,6)
N (2,1)
N (2,2)
N (2,3)
N (2,4)
N (2,5)
N (2,6)
N (3,1)
N (3,2)
N (3,3)
N (3,4)
N (3,5)
N (3,6)
N (4,1)
N (4,2)
N (4,3)
N (4,4)
N (4,5)
N (4,6)
N (5,1)
N (5,2)
N (5,3)
N (5,4)
N (5,5)
N (5,6)
N (6,1)
N (6,2)
N (6,3)
N (6,4)
N (6,5)
N (6,6)
N (7,1)
N (7,2)
N (7,3)
N (7,4)
N (7,5)
N (7,6)
N (7,7)
Abbildung A.1.: Ein kartesisches Einheitsgitter
Wenn dort die Diagonalen eingezeichnet wären, wäre die obere Schranke nur
noch √ n Knoten. Deshalb wurde angenommen, dass dieses Verhältnis auch für
die betrachteten Netzwerkgraphen ein Wurzelverhältnis der Form
x√ n
ist.
In Listing A.5 werden 189 Knoten selektiert. Dies ist die Anzahl der Knoten
die im betrachten Zeitraum aktiv waren. Im Ergebnis waren maximal 19
Knoten auf einem kürzesten Pfad zu finden. Also gilt:
und daraus folgt:
x√
189 = 19 =⇒ 189
1
x = 19
x =
log 189
log 19
≈ 1, 78.
Dadruch gibt es für diesem Zeitraum maximal
1,78 √ n
Knoten die auf einem kürzesten Pfad liegen. Allerdings ist der durchschnittliche
Wert 3,33√ n (nach dem selben Verfahren berechnet) noch wesentlich geringer.
© Andreas Redmer — 29. September 2011 vi

A. Anhang: SQL Anfragen
A.5. Floyd-Warshall-Berechnung in SQL
1 -- set_w
2 CREATE FUNCTION set_w(varchar, varchar, real) RETURNS void AS $$
3 UPDATE nodematrix SET w = $3 WHERE (nodea,nodeb)=($1,$2);
4 $$ LANGUAGE SQL;
5
6 -- set_d
7 CREATE FUNCTION set_d(varchar, varchar, real) RETURNS void AS $$
8 UPDATE nodematrix SET d = $3 WHERE (nodea,nodeb)=($1,$2);
9 $$ LANGUAGE SQL;
10
11 -- get_d
12 CREATE OR REPLACE FUNCTION get_d(varchar, varchar) RETURNS real AS $$
13 SELECT d FROM nodematrix WHERE (nodea,nodeb)=($1,$2);
14 $$ LANGUAGE SQL;
15
16 -- min-Funktion die NULL als unendlich gross betrachtet
17 CREATE FUNCTION min(real, real) RETURNS real AS $$
18 BEGIN
19 IF (($1 IS NULL) AND ($2 IS NULL)) THEN RETURN NULL; END IF;
20 IF ($1 IS NULL) THEN RETURN $2; END IF;
21 IF ($2 IS NULL) THEN RETURN $1; END IF;
22 IF ($1 < $2) THEN RETURN $1; END IF;
23 RETURN $2;
24 END;
25 $$ LANGUAGE ’plpgsql’;
26
27 -- Floyd-Warshall Funktion
28 CREATE FUNCTION floyd(varchar) RETURNS boolean AS $$
29
30 -- fill weights (both directions)
31 select set_w(nodea, nodeb, lq) from oneweek
32 where time=’2010-09-14 09:38:02’;
33 select set_w(nodeb, nodea, lqn) from oneweek
34 where time=’2010-09-14 09:38:02’;
35
36 -- set initial distances to weights
37 UPDATE nodematrix SET d = w;
38
39 select
40 set_d (i.name,j.name,
41 min (get_d (i.name, j.name),
42 get_d (i.name, k.name) + get_d (k.name, j.name))
43 )
44 from nodes i,nodes j,nodes k ;
45
46 select true;
47 $$ LANGUAGE SQL;
Listing A.6: Floyd-Warshall Berechnung in SQL
Listing A.6 zeigt eine Funktion (floyd), die den Floyd-Warshall-Algorithmus
berechnet und das Ergebnis in die Tabelle nodematrix schreibt. Zuvor wird eine
veränderte min-Funktion und Getter- und Setter-Funktionen für die Tabelle
nodematrix angelegt.
© Andreas Redmer — 29. September 2011 vii

A. Anhang: SQL Anfragen
A.6. Floyd-Warshall-Berechnung mit PL/Python
1 CREATE OR REPLACE FUNCTION pyfloyd (stamp character varying)
2 RETURNS character varying
3 AS $$
4 q_create_nodelist = "(select distinct nodea as list from oneweek "
5 q_create_nodelist += "where time=’2010-09-14 09:38:02’) "
6 q_create_nodelist += "UNION "
7 q_create_nodelist += "(select distinct nodeb from oneweek "
8 q_create_nodelist += "where time=’2010-09-14 09:38:02’); "
9
10 q_create_linklist = "(select nodea,nodeb,lq,lqn from oneweek "
11 q_create_linklist += "where time=’2010-09-14 09:38:02’); "
12
13 #-- nl = nodelist (INT --> String)
14 nl = plpy.execute(q_create_nodelist)
15 foo = nl[0]["list"]
16 n = len(nl)
17
18 #-- nm = linkmap (String --> INT)
19 nm = dict()
20 for i in range(n):
21 nm[nl[i]["list"]]=i
22
23 #-- ll = linklist
24 ll = plpy.execute(q_create_linklist)
25
26 #-- generate distance matrix d
27 d = [[0 for col in range(n)] for row in range(n)]
28
29 #-- fill d with infinity
30 for i in range(n):
31 for j in range(n):
32 d[i][j] = 99999
33
34 #-- INIT: add links to distance matrix
35 for i in range(len(ll)):
36 nodea = ll[i]["nodea"]
37 nodeb = ll[i]["nodeb"]
38 d[nm[nodea]][nm[nodeb]] = ll[i]["lq"]
39 d[nm[nodeb]][nm[nodea]] = ll[i]["lqn"]
40
41 for k in range(n):
42 for i in range(n):
43 for j in range(n):
44 d[i][j] = min (d[i][j],d[i][k] + d[k][j])
45 return len(ll)
46 $$ LANGUAGE plpythonu;
Listing A.7: Floyd-Warshall Berechnung mit PL/Python
Listing A.7 zeigt die PL/Python Funktion pyfloyd, die den Floyd-Warshall-
Algorithmus berechnet. Sie gibt das Ergebnis jedoch nicht zurück, da sie nur
für eine Zeitmessung erstellt wurde.
© Andreas Redmer — 29. September 2011 viii

A. Anhang: SQL Anfragen
A.7. Test der General-Gateway-Strategie
1 -- Compares the 2 Dijkstra implementations and returns the number
2 -- of differences. This should always return 0.
3 DROP FUNCTION IF EXISTS compare_algorithms(timestamptz);
4 CREATE OR REPLACE FUNCTION compare_algorithms(timestamptz)
5 RETURNS bigint AS
6 $$
7 select count (*) from
8 (
9 (
10 select * from shortestpaths($1,1)
11 EXCEPT
12 select * from shortestpaths($1,2)
13 )
14 UNION
15 (
16 select * from shortestpaths($1,2)
17 EXCEPT
18 select * from shortestpaths($1,1)
19 )
20 ) s1
21 $$
22 STABLE LANGUAGE SQL;
23
24
25 -- Return all timestamps and their number of differences,
26 -- if there are more than 0 differences, ordered by differences.
27 select diffs, time from
28 (
29 select compare_algorithms(s1.time) diffs, s1.time from
30 (
31 select time from times
32 ) as s1
33 ) as s2
34 where diffs>0
35 order by diffs DESC;
36 -- Ausgabe: 0 Zeilen
Listing A.8: Anzahl Unterschiede zwischen herkömmlicher und General Gateway
Strategie
Listing A.8 zeigt eine Abfrage, die die Ergebnisse mit der General Gateway
Strategie mit denen der herkömmlichen Strategie vergleicht. Dazu wird ein
optionaler Parameter in der shortestPaths-Funktion verwendet, mit dem die
Strategie einstellbar ist. Es werden alle Timestamps selektiert bei denen die
General Gateway Strategie ein anderes Ergebnis liefert als die herkömmliche
Strategie. Es werden 0 Zeilen ausgegeben. Somit liefert die General Gateway
Strategie für alle vorhandenen Timestamps das gleiche Ergebnis, das auch ohne
ihre Verwendung entstehen würde.
© Andreas Redmer — 29. September 2011 ix

A. Anhang: SQL Anfragen
A.8. Implementierung der Algebra aus Abschnitt
4.1.4
1 -- ein (Knoten, Vorgaenger) Tupel
2 CREATE TYPE t AS (v varchar, v_p varchar );
3
4 -- ein Dijkstra-Ergebnis
5 CREATE TYPE D AS (results t[]);
6
7 -- ein Unterschied (M,P)
8 CREATE TYPE u AS ( M D, P D);
9
10 -- Tabelle, die d. Unterschied zw. 2 Timestamps speichern kann
11 CREATE TABLE unterschiede ( t_a timestamp, t_b timestamp, u u );
12
13 -- diff-Funktion
14 CREATE FUNCTION _diff (D D,u u) RETURNS D
15 AS $$ DECLARE res D;
16 BEGIN
17 SELECT array_agg(
18 ((SELECT unnest (D.results) EXCEPT
19 SELECT unnest (u.M))
20 UNION SELECT unnest (u.P)))
21 INTO res.results;
22 RETURN res;
23 END; $$
24 LANGUAGE plpgsql;
25
26 -- Inverse der diff-Funktion
27 CREATE FUNCTION _inverse_diff (D D,u u) RETURNS D
28 AS $$ DECLARE res D;
29 BEGIN
30 SELECT array_agg(
31 ((SELECT unnest (D.results) EXCEPT
32 SELECT unnest (u.P))
33 UNION SELECT unnest (u.M)))
34 INTO res.results;
35 RETURN res;
36 END; $$
37 LANGUAGE plpgsql;
38
39 -- Operatordefinitionen
40 CREATE OPERATOR + ( leftarg = D, rightarg = u,
41 procedure = _diff, commutator = + );
42
43 CREATE OPERATOR - ( leftarg = D, rightarg = u,
44 procedure = _inverse_diff, commutator = - );
Listing A.9: Die Algebra aus Abschnitt 4.1.4 in PL/pgSQL
Listing A.9 zeigt die Algebra aus Abschnitt 4.1.4 in PL/pgSQL implementiert.
Bei der Ausführung von Listing A.9 werden nur Datenstrukturen und
Funktionen auf dem Datenbankserver angelegt. Diese können danach im Datenbanksystem
verwendet werden. Es werden keine Berechnungen durchgeführt.
© Andreas Redmer — 29. September 2011 x

B. Anhang: Suche nach einer Partitionierung
B. Anhang: Suche nach einer
Partitionierung
An dieser Stelle soll eine neue Problemstellung erklärt werden, die mit dieser
Arbeit im Zusammenhang steht. Im Opennet arbeiten alle Knoten auf dem
selben WLAN-Kanal (Kanal 1). Dies führt zu Interferenzen und beeinträchtigt
unter Umständen die Netzwerkqualität. In [32] wurde versucht mittels
Brute-Force eine Partitionierung des Graphen zu berechnen. Wenn geeignete
Partitionen gefunden werden, können diese auf getrennten Kanälen arbeiten
und so die Netzwerkqualität erhöhen. Im Folgenden soll ein Ansatz erklärt werden,
der die Partitionierung mit den in dieser Arbeit entwickelten Funktionen
ermöglicht.
Aus Platzgründen wird hier kein SQL-Quelltext mehr abgebildet. Die Funktionen
werden formal beschrieben. Ziel ist es den Netzwerkgraphen in Partitionen
einzuteilen. Die Verbindung zwischen zwei verschiedenen Partitionen ist
dabei nur über spezielle Backbone-Knoten möglich, die im Graphen vorhanden
sind. Im Folgenden wird eine Möglichkeit der Bestimmung solcher Partitionen
mit den vorhandenen UDF beschrieben. Es wird dabei lediglich SQL verwendet;
die Java-UDF brauchen auch hier nicht verändert zu werden. Gegeben sei
ein Graph mit der Knotenmenge V = (v 1 , . . . , v n ) und der Kantenmenge E.
Sei weiterhin G eine Menge von Gateways für die gilt:
G ⊂ V mit: G = {g 1 , g 2 , . . . }
und B eine Menge von Backbones für die gilt:
B ⊂ V mit: B = {b 1 , b 2 , . . . }.
Dabei müssen G und B nicht disjunkt sein. Gesucht ist eine Partitionierungsabbildung
part : (V \ B) −→ N,
die jedem Knoten, der kein Backbone ist, genau eine Partitionsnummer zuweist.
Es muss
∀v x ∈ (V \ B) : part(v x ) = p i (mit: 1 ≤ i ≤ k)
gelten. Dabei ist p i ∈ N eine Partitionsnummer und k eine vorher zu definierende
Konstante, welche die maximale Anzahl der Partitionen festlegt. Eine
Partitionierung soll gültig sein, wenn der Graph mit der Kantenmenge
E \ {(v x , v y )|(part(v x ) ≠ part(v y )) ∧ v x /∈ B ∧ v y /∈ B}
immernoch vollständig verbunden ist. Die Kantenmenge wird also auf Kanten
reduziert, die von oder zu einem Backbone laufen oder sich in der gleichen
Partition befinden.
© Andreas Redmer — 29. September 2011 xi

B. Anhang: Suche nach einer Partitionierung
Mit der Bruteforce-Methode (also dem Probieren aller möglichen Kombinationen
aus Knoten und Partitionsnummer), könnte mit dem Zeitaufwand O(k n )
eine gültige Partitionierung gefunden werden. Eine Random-Walk-Strategie
(also dem Probieren zufälliger Kombinationen) könnte schneller eine gültige
Partitionierung finden. Diese hat allerdings die Worst-Case-Komplexität
O(∞). Da diese beiden Methoden für die praktische Ausführung zu zeitaufwändig
sind, soll nun eine weitere Methode vorgestellt werden, die im Rahmen
dieser Arbeit entwickelt wurde.
Schritt 1: Betrachte alle Gateways als normale Knoten und alle Backbones
als Gateways. Führe dann die shortestPaths-Funktion aus.
v 1
v 2
g 1
Backbones (Menge B)
b 1
v 3 v 4
b 2
v 5 v 6
b 3
g 2
v 7
v 8 b 4
Abbildung B.1.: Beispielgraph: Alle kürzesten Wege in die Menge der
Backbones
Schritt 2: Wähle alle Knoten, die als direkten Vorgänger ein Backbone
haben, aus und betrachte sie und die daran angehängten Knoten als eine Partition.
In Abbildung B.1 wurde dies an einem Beispiel durchgeführt. Dabei
bilden die Knoten g 1 , v 4 , v 6 und v 8 die Ausgangsknoten für die Partitionen. Es
entstehen also vier Partitionen. Diese sind als gestrichelte Linie gekennzeichnet.
Schritt 3 (optional): Reduziere die Partitionen. Im Opennet sind derzeit
60 Backbone-Knoten definiert. Mit dieser Methode entstehen also sehr viele
Partitionen. Diese werden nun zusammengefasst. Um die Implementierung an
dieser Stelle einfach zu halten, geschieht dies nach dem Zufallsprinzip. Dabei
wird mit einer Modulo-Operation auf einer Zufallszahl (modulo k) dafür
gesorgt, dass die maximale Anzahl der gewünschten Partitionen nicht überschritten
wird. Später sollte man sich evtl. Gedanken über eine geschicktere
© Andreas Redmer — 29. September 2011 xii

B. Anhang: Suche nach einer Partitionierung
Zusammenfassung der Partitionen machen. Beispielsweise könnte man immer
Partitionen zusammenfassen, die bezüglich ihrer geographischen Koordinaten
möglichst weit voneinander entfernt sind. Damit würde man sicherstellen, dass
die Partitionen sich über das gesamte geographische Gebiet des Netzwerkes
erstrecken. Im Beispiel in Abbildung B.1 entstanden nur vier Partitionen, so
dass diese nicht weiter zusammengefasst wurden.
v 1
v 2
g 1
Backbones (Menge B)
b 1
v 3 v 4
b 2
v 5 v 6
b 3
g 2
v 7
v 8 b 4
Abbildung B.2.: Beispielgraph: Alle kürzesten Wege zu den Gateways ohne
Beachtung der Partitionen
Schritt 4: Streiche alle Kanten, die zwei Knoten aus verschiedenen Partitionen
miteinander verbinden. In Abbildung B.2 wurden die kürzesten Wege
eingezeichnet, die der Dijkstra-Algorithmus bei der normalen Ausführung auf
dem Graphen finden würde. Die Kanten, die nun nicht mehr verwendet werden
dürfen und somit gestrichen werden müssen, wurden rot gekennzeichnet.
Schritt 5: Berechne abschließend (mit der reduzierten Kantenmenge) die
kürzesten Pfade mit der shortestPaths-Funktion. Wenn jeder Knoten mit
einem Gateway verbunden werden kann (also einen Vorgänger zugewiesen bekommt),
ist die Partitionierung gültig. Der Algorithmus ist beendet. In Abbildung
B.3 wurden die neuen Pfade, die der Dijkstra-Algorithmus nun gefunden
hat, grün eingezeichnet. In der Implementation mit dem Opennet-
Netzwerkgraph war die Partitionierung für mit den 60 Backbones für k = 3
immer gültig. Da die Zufallszahlen in Schritt 3 gleichverteilt sind, ist es sehr
unwahrscheinlich, dass eine solche Partitionierung einen Teilgraphen vollständig
abtrennt.
© Andreas Redmer — 29. September 2011 xiii

B. Anhang: Suche nach einer Partitionierung
v 1
v 2
g 1
Backbones (Menge B)
b 1
v 3 v 4
b 2
v 5 v 6
b 3
g 2
v 7
v 8 b 4
Abbildung B.3.: Beispielgraph: Alle kürzesten Wege zu den Gateways unter
Beachtung der Partitionen
Eine so gefundene Partitionierung ist wahrscheinlich besser, als eine durch
Brute-Force oder Random-Walk entdeckte, da schon im ersten Schritt nur die
besten Wege in die Menge der Backbones gewählt werden. Dort wären allerdings
noch viele weitere Wege möglich. Beispielsweise hätte v 4 auch über g 1
den Knoten b 1 erreichen können.
Es stellt sich also die Frage, wie die Partitionierung durch geschicktes Zusammenfassen
in Schritt 3 optimiert werden kann. Im Beispiel in Abbildung
B.3 wäre es offensichtlich gut gewesen, die oberen beiden Partitionen zusammen
zu fassen und damit die direkte Verbindung von v 4 zu g 1 zu erhalten.
Um die Güte einer gültigen Partitionierung zu messen, können verschiedene
Fitness-Funktionen für die gefundenen Partitionen definiert werden. Beispielsweise
kann ermittelt werden:
ˆ Welche Qualität haben die gestrichenen Kanten?
ˆ Welche Qualität haben die nicht gestrichenen Kanten?
ˆ Wie viele Kanten wurden durch die Partitionierung gestrichen?
ˆ Wie viele Kanten, die in den tatsächlichen kürzesten Wegen vorhanden
sind, wurden durch die Partitionierung gestrichen?
Auch Kombinationen davon und weitere Fitness-Funktionen sind denkbar.
Im Rahmen dieser Arbeit wurde die zuletzt aufgezählte Möglichkeit implementiert.
Dazu sei D E die Ausgabemenge des Dijkstra-Algorithmus auf einem
Graphen mit der Kantenmenge E, dann beschreibt die Funktion
fitness(part) := |D E ∩ D E\{(vx,v y)|(part(v x)≠part(v y))∧v x /∈B∧v y /∈B}|
© Andreas Redmer — 29. September 2011 xiv

B. Anhang: Suche nach einer Partitionierung
die implementierte Funktion. Dabei wird praktisch die Ausgabe der unveränderten
shortestPaths-Funktion mit der Augabe einer anderen shortest-
Paths-Funktion, die Kanten streichen kann (analog zu Listing 5.7) verglichen.
Die Minimierung der Fitness-Funktion ist die Optimierung der Partitionierung.
Es gilt
min(fitness(part)) = 0.
Wenn die Fitness-Funktion also auf 0 minimiert werden kann, dann ist die
durch part beschriebene Partitionierung optimal und kann nicht weiter verbessert
werden. Im Rahmen dieser Arbeit wurden die Zufallszahlen in Schritt
3 beibehalten und die Fitness-Funktion durch wiederholte Ausführungen minimiert.
Dies entspricht einer Random-Walk-Strategie.
Schritt 6 (optional): Wiederhole Schritt 1 bis 5 viele Male. Speichere
dabei jeweils den niedrigsten gefundenen Wert der Fitness-Funktion und gib
die zugehörige Partitionierung am Ende aus. Brich die Ausführung vorher ab,
wenn die Fitness-Funktion einen gewissen Wert unterschreitet oder 0 ist.
Fazit: Es wurde der Timestamp ”
2010-09-14 14:00:02“ betrachtet. Es sollten
drei Partitionen gefunden werden (also k = 3). Nach 30 Sekunden Laufzeit war
die Partitionierung optimal (also fitness = 0), so dass die kürzesten Wege
sich durch die Partitionierung nicht geändert haben. In Abbildung B.4 sind
die entstandenen Partitionen visualisiert. Darin ist zu erkennen, dass keine
direkten Verbindungen zwischen zwei Partitionen bestehen, und dass dennoch
jeder Knoten einen Pfad zu einem Gateway hat. Verbindungen zwischen zwei
Partitionen führen nun immer über mindestens einen Backbone-Knoten.
In Zukunft müsste nun überprüft werden, ob eine solche Partitionierung
sinnvoll ist. Sie ist nun zwar mathematisch optimal, aber das könnte auch bedeuten,
dass sich die Partitionen geographisch gar nicht überschneiden. Die
Partitionen müssten nun also auf die geographisch korrekten Positionen der
Knoten eingezeichnet werden um zu prüfen wie stark sie sich überschneiden.
Nur so kann sichergestellt werden, dass durch die Partitionierung auch Interferenzen
vermieden werden. Unter Umständen muss der Algorithmus (wie
in Schritt 3 schon angedeutet) um einige geographische Parameter erweitert
werden.
© Andreas Redmer — 29. September 2011 xv

B. Anhang: Suche nach einer Partitionierung
Partition 1
192.168.1.123
192.168.1.125
192.168.1.109 192.168.1.54
192.168.1.190
192.168.1.178
192.168.1.134
192.168.1.156
192.168.1.163
192.168.1.193
192.168.1.204
192.168.1.69
192.168.1.6
192.168.1.82
192.168.1.195
192.168.1.84
192.168.1.168
192.168.2.6
192.168.1.94
192.168.1.28
192.168.33.220
192.168.1.96
192.168.2.5
192.168.1.29
192.168.1.33
192.168.1.4
192.168.33.12
192.168.1.5
192.168.2.8
192.168.1.113
192.168.1.52
192.168.1.14
192.168.1.129
192.168.1.99
192.168.2.4
192.168.1.39
192.168.1.25
192.168.1.10
192.168.1.171
192.168.2.2
192.168.10.2
GW
192.168.1.103
192.168.1.124
192.168.1.32
192.168.1.16
192.168.1.172
192.168.1.104
192.168.2.3
192.168.1.15
192.168.1.205
192.168.1.138
192.168.2.7
192.168.1.120 192.168.1.70
192.168.1.126
192.168.1.46
192.168.1.159
192.168.1.182
192.168.1.184
192.168.1.189 192.168.1.185
192.168.1.186
192.168.0.244
192.168.1.150
Partition 2
192.168.1.140
192.168.1.166 192.168.1.155
192.168.1.147
192.168.1.187
192.168.1.180
192.168.1.197
192.168.1.122
192.168.1.143
192.168.1.188
192.168.1.133
192.168.1.22
192.168.1.71
192.168.1.208
192.168.1.112
192.168.1.111
192.168.1.222
192.168.1.132
Partition 0
192.168.1.35
192.168.1.58
192.168.1.89
192.168.1.77
192.168.1.106
192.168.1.79
192.168.1.157
192.168.1.248 192.168.1.245
192.168.1.165
192.168.1.121
192.168.1.177
192.168.1.247
192.168.1.167
192.168.1.49
192.168.1.149 192.168.1.158
192.168.1.20
192.168.1.242
192.168.1.239
192.168.1.238
192.168.1.241
192.168.1.236
192.168.1.235
192.168.1.207
192.168.1.80
192.168.1.67
192.168.1.26
192.168.1.214
192.168.1.93
192.168.1.240
192.168.1.98
192.168.1.215
192.168.1.91
GW
10.2.1.1
192.168.1.38
192.168.1.218
192.168.1.216
192.168.1.226
192.168.1.36
192.168.1.223
192.168.1.213
192.168.1.43
192.168.1.27
192.168.1.75
192.168.1.55
192.168.11.181
192.168.1.76
192.168.1.139
192.168.1.86
192.168.1.73
192.168.33.253
192.168.1.81
192.168.1.83
192.168.1.57
192.168.1.12
192.168.1.116 192.168.1.194
192.168.1.148
192.168.1.62
192.168.1.45
192.168.1.135 192.168.1.90
GW
192.168.1.87
192.168.1.51
192.168.1.145
192.168.1.130
192.168.1.78
192.168.1.198
192.168.1.199
192.168.1.56
192.168.1.88
192.168.1.170
192.168.1.19
192.168.1.196
192.168.1.202
192.168.1.37
192.168.1.191
192.168.1.31
192.168.1.141
192.168.1.154
192.168.11.203
192.168.1.174
192.168.1.128
192.168.1.183
192.168.1.127
192.168.1.176
192.168.1.232
192.168.1.233
192.168.1.234
192.168.1.179
Abbildung B.4.: Optimale Partitionen am 14.09.2010 um 14 Uhr
© Andreas Redmer — 29. September 2011 xvi