Seminarband - Lehrgebiet Datenbanksysteme für neue Anwendungen

294 Pages·2013·7.69 MB·German

FernUniversita¨t in Hagen
Fakult¨at fu¨r Mathematik und Informatik
Sommersemester 2013
Seminar 01912
Big Data Management
Prof. Dr. Ralf Hartmut Gu¨ting
Fabio Vald´es

Zeitplan und Inhaltsverzeichnis
Donnerstag, 18. Juli 2013
11:00 Uhr Parallele Datenbanken
Klaus Nieswand
12:15 Uhr Spaltenorientierte Datenbanken
Nico Geisler
13:15 Uhr Mittagspause
14:15 Uhr MapReduce
Johannes Unterstein
15:30 Uhr Google File System
Simon Eiersbrock
16:45 Uhr Kontroverse: Parallele Datenbanken vs. MapReduce
Alica Moser
Freitag, 19. Juli 2013
09:00 Uhr HadoopDB & SQL/MapReduce
Michael Ku¨pper
10:15 Uhr Hive
Markus H¨ohnerbach
11:30 Uhr Pig
Roland Hellwig
12:30 Uhr Mittagspause
13:30 Uhr U¨berblick: NoSQL-Datenbanken & Key-Value Stores
Steffi Uhl
14:45 Uhr Dynamo
Jana Stehmann
16:00 Uhr Bigtable
Felix Siegrist
Samstag, 20. Juli 2013
09:00 Uhr CouchDB
Kristina Steiger
10:15 Uhr MongoDB
Wiebke Wilken
11:30 Uhr Cassandra
Jan Kristof Nidzwetzki
12:30 Uhr Mittagspause
13:30 Uhr H-Store & VoltDB
Anette Naffin-Rehorst
14:30 Uhr Verabschiedung

FernUniversität in Hagen
-
Seminar 01912
im Sommersemester 2013
Big Data Management
Thema 1
Parallele Datenbanken
Referent: Klaus Nieswand
Big Data Management Parallele Datenbanken 2
Inhaltsverzeichnis
1 Einleitung................................................................................................................................3
2 Parallele Datenverarbeitung....................................................................................................3
2.1 Anforderungen an die elektronische Datenverarbeitung................................................3
2.2 Warum Parallelisieren ?..................................................................................................3
2.3 Wichtige Begriffe............................................................................................................4
2.4 Parallelisierungstechniken..............................................................................................6
3 Hardwarearchitektur................................................................................................................7
3.1 Shared Nothing...............................................................................................................7
3.2 Shared Memory...............................................................................................................7
3.3 Shared Disk.....................................................................................................................8
3.4 Bewertung der Architekturen..........................................................................................8
3.5 Parallele Komponenten...................................................................................................8
3.6 Virtualisierung................................................................................................................9
4 Softwareanforderungen.........................................................................................................10
4.1 Allgemeine Vorrausetzungen........................................................................................10
4.2 Die Eignung von Datenbanksystemen..........................................................................10
4.3 SQL...............................................................................................................................10
4.4 Verteilte Datenbanken...................................................................................................11
4.5 Partitionierung...............................................................................................................12
4.6 Kostenmodelle..............................................................................................................14
5 Realisierungen.......................................................................................................................16
5.1 Teradata.........................................................................................................................16
5.2 Tandem NonStop SQL..................................................................................................16
5.3 Gamma..........................................................................................................................17
5.4 The Super Database Computer (SDC)..........................................................................17
5.5 Bubba............................................................................................................................17
6 Fazit.......................................................................................................................................18
Big Data Management Parallele Datenbanken 3

1 Einleitung
Im Rahmen dieser Ausarbeitung sollen verschiedene Aspekte von parallelen Datenbanken be-
trachtet werden. In Kapitel 2 wird das Problemfeld der parallelen Datenverarbeitung allgemein
dargestellt, beginnend mit einer kurzen Beschreibung der zugrunde liegenden Ziele der elektro-
nischen Datenverarbeitung. In Kapitel 3 werden ausgewählte Hardwarearchitekturen für die pa-
rallele Datenverarbeitung vorgestellt und bewertet. Im Anschluss werden dann in Kapitel 4 die
Softwareaspekte der parallelen Datenverarbeitung untersucht. Hierbei wird der Schwerpunkt auf
die Besonderheiten von Datenbanksystemen gelegt. Dabei werden insbesondere in Kapitel 4.5
Partitionierung viele der in den übrigen behandelten oder angesprochenen Themen nochmals
zusammenhängend und ausführlich behandelt. Im letzten Kapitel werden einige frühe Realisie-
rungen von parallelen Datenbanksystemen beschrieben. Große Teile dieses Arbeit gehen auf
einen Artikel von David DeWitt und Jim Gray zurück [1]. Die Beschreibung der Kostenmodelle
basiert auf einem Artikel von Donald Kossmann [2].
2 Parallele Datenverarbeitung
2.1 Anforderungen an die elektronische Datenverarbeitung
Ziel der elektronischen Datenverarbeitung ist es, Aufgabenstellungen fehlerfrei zu lösen. Ein
wichtiges Qualitätskriterium ist dabei die Zeit, die benötigt wird, um die Ergebnisse für die ge-
stellten Aufgaben zu erhalten. Daneben spielen die Kosten, die für die Erstellung und den Be-
trieb der benötigten Systeme anfallen, eine wesentliche Rolle.
Werden für die Spezifikation der Leistungsanforderungen Antwortzeiten definiert, können in der
Datenverarbeitung zwei unterschiedliche Verarbeitungsarten unterschieden werden. Bei der
Batchverarbeitung ist es in der Regel ausreichend, wenn die Zeitvorgaben genau eingehalten
werden. Für Nutzeranfragen hingegen stellen die Zeitvorgaben nur die Obergrenzen dar, die ide-
aler Weise möglichst weit unterschritten werden sollten, weil so die Benutzerfreundlichkeit ver-
bessert werden kann. Aus diesem Grund sollen meist leistungsstarke Systeme zum Einsatz
kommen. Obwohl für die Realisierung leistungsstarker Systeme das technisch Machbare ein be-
grenzender Faktor ist, wird in der Regel eher der Kostenfaktor entscheidend für die Auswahl der
zu realisierenden Lösungen sein. Grundsätzlich gilt, je weiter man sich den technischen Leis-
tungsgrenzen annähert, je teurer wird der Leistungsgewinn, der sich so erzielen lässt. Dement-
sprechend wird es das Ziel sein, innerhalb einer vorgegebenen Kostenobergrenze das leistungs-
stärkste System zu finden. Im Folgenden wird erläutert, wie die parallele Datenbankverarbeitung
zur Erreichung dieses Zieles beitragen kann.
2.2 Warum Parallelisieren ?
In diesem Abschnitt werden Konzepte der zeitlichen Abarbeitung von Aufgaben in einem EDV-
System beschrieben. Dabei geht es um die Fragestellung, wie die vorhandene Hardware den ein-
zelnen auszuführenden Prozessen zugeordnet wird. Um die Komplexität der folgenden Betrach-
tungen zu verringern, wird ein Rechnersystem auf drei wesentliche Komponenten reduziert. Da-
bei handelt es sich um den Prozessor, den Arbeitsspeicher und den Festspeicher. Eine ausführli-
chere Beschreibung der Hardwarearchitektur erfolgt in Kapitel 3.
Die einfachste zeitliche Abfolge bei der Abarbeitung der Aufgaben wäre eine sequentielle An-
ordnung. Das heißt zum Beispiel für die Datenbankverarbeitung, nachdem eine Datenbankabfra-
ge eingegangen ist, würde diese vollständig abgearbeitet, bevor eine neue Datenbankabfrage
angenommen wird. In ähnlicher Weise lief die Datenverarbeitung in den ersten Rechnersystemen
ab. Als die Rechnersysteme leitungsfähiger wurden, und sich das Anforderungsprofil durch ver-
Big Data Management Parallele Datenbanken 4
stärkte Nutzerinteraktion bzw. durch eine dynamischere Interaktion von Anwendungen mit den
Datenbanksystemen veränderte, hat sich daran angepasst auch die Ablaufsteuerung von Daten-
bankabfragen verändert. Auch wenn die Komponenten nur einfach vorhanden waren, wurde die
Ablaufsteuerung so verändert, dass das Rechnersystem in die Lage versetzt wurde, eine neue
Datenbankabfrage anzunehmen, bevor die letzte abgearbeitet war. Da eine nicht parallele Hard-
warestruktur eine echte Parallelverarbeitung nicht zulässt, müssen den einzelnen Aufgaben die
vorhandenen Hardwarekomponenten abwechselnd zugeordnet werden. Gäbe es einen idealen
Rechner mit einem unendlich schnellen Prozessor, unendlich viel Speicher mit einer unendlich
großen Bandbreite und einem Festspeichersystem ohne Verzögerungen beim Datentransfer, der
darüber hinaus nicht viel kostet, würde eine Parallelisierung nicht benötigt ([1] S.88). Alle Auf-
gaben könnten auch auf einem solchem sequentiellen System ausreichend schnell bearbeitet
werden. Da es ein solches System nicht gibt, müssen Lösungen gefunden werden, die die oben
genannte Zielsetzung möglichst gut erfüllen.
In dem zuvor beschriebenen Fall muss die laufende Abfrage unterbrochen werden, um neue An-
fragen entgegennehmen zu können. Das heißt, dass die einzelnen Aufgaben stückweise ineinan-
der verzahn abgearbeitet werden. Damit das System aber von außen erreichbar bleibt, müssen die
einzelnen Prozesse priorisiert werden, um der Annahmebearbeitung bevorzugt die Hardware zur
Verfügung zu stellen. Durch die überlappende Verarbeitung ist es möglich die Systemkompo-
nenten besser auszulasten. Da im Rahmen einer einzelnen Verarbeitung nicht alle Komponenten
gleichmäßig benötigt werden (zum Beispiel wird während eines Datentransfers aus dem Fest-
speicher in den Arbeitspeicher der Prozessor nur wenig ausgelastet), können freie Ressourcen
neu zugeordnet werden. Dadurch lässt sich für die Gesamtheit der Aufgaben ein Geschwindig-
keitsgewinn erzielen. Gleichzeitig entsteht für die Verwaltung der eingegangenen Aufgaben ein
zusätzlicher Verwaltungsaufwand, der mit zunehmender Anzahl der Aufgaben ansteigt. Dadurch
verlangsamt sich die Datenverarbeitung wieder etwas.
Eine weitere Möglichkeit die Leistung zu steigern ist die Parallelisierung. Dabei werden zusätz-
liche Hardwarekomponenten in das System eingebunden, sodass die wesentlichen Komponenten
für die Abarbeitung der gestellten Aufgaben mehrfach zur Verfügung stehen. Dadurch entstehen
parallele Teilsysteme. Architekturen, die durch die Bereitstellung mehrfach vorhandener Kom-
ponenten eine echte Parallelverarbeitung ermöglichen, werden in Kapitel 3 beschrieben. Die ein-
gehenden Datenbankabfragen können dann diesen Teilsystemen zugewiesen werden. Im optima-
len Fall liegen unabhängige Datenbankabfragen vor. Diese können dann unabhängig von weite-
ren Abfragen einem der parallelen Teilsysteme zugeordnet werden. Ziel muss es also sein, ein-
zelne Datenbankabfragen so in unabhängige Teilaufgaben zu zerlegen, dass der Grad der Paralle-
lisierung weiter gesteigert werden kann (intraquery parallelism). Die Möglichkeiten der Paralle-
lisierung von Datenbankabfragen werden in Abschnitt 2.4 und in Kapitel 4 weiter beschrieben.
Bei der Parallelisierung wird durch eine große Anzahl von Verarbeitungskomponenten die Leis-
tungssteigerung erzielt. Dabei können auch leistungsschwächere Standardkomponenten verwen-
det werden, die ein besseres Preis-Leistungs-Verhältnis haben. Die schwächere Leistung wird
durch eine größere Anzahl von Komponenten kompensiert. Damit lassen sich kostengünstigere
Systeme zusammenstellen, als bei der Verwendung weniger teurer Spezialkomponenten.
2.3 Wichtige Begriffe
Zum Vergleich der Qualität von parallelen Systemen wurden einige Maßzahlen eingeführt ([1] S.
87). Diese Maßzahlen bewerten die Leistungsgewinne, die sich durch eine Parallelisierung von
Programmabläufen erzielen lassen. Dabei hängt der Leistungsgewinn sowohl von der Systemar-
chitektur und der eingesetzten Software, als auch von der speziellen Aufgabe ab. Zum Vergleich
der Effizienz von Programmabläufen auf unterschiedlichen Systemen, werden die beiden Begrif-
fe Speedup und Scaleup definiert. Der Speedup ist das Verhältnis der Ausführungszeiten, die
Big Data Management Parallele Datenbanken 5
zwei zu vergleichende Systeme benötigen, wenn auf ihnen die gleichen Aufgaben ausgeführt
werden.
Ausführungszeit (Problem A, System 1)
Speedup =
Ausführungszeit (Problem A, System 2)

Dieser Wert ist besonders zum Vergleich von transaktionsorientierten Systemen geeignet. Hier-
bei kann untersucht werden, wie sich die Ausführungszeit für eine größere Anzahl von Transak-
tionen verändert, wenn ein leistungsstärkeres System (großes System) eingesetzt wird. Der
Speedup wird als linear bezeichnet, wenn die Ausführungszeit um den Faktor abnimmt, um den
die Leistungsfähigkeit des Systems zunimmt. Im Falle der Parallelisierung wird der Leistungsfä-
higkeitsfaktor durch die Anzahl der beteiligten Systeme, bzw. die Anzahl der relevanten Kom-
ponenten bestimmt. Eine gute Parallelisierbarkeit liegt vor, wenn ein linearer Speedup erreicht
wird.
Beim Scaleup werden die Ausführungszeiten zweier Systeme verglichen, wenn die Problemgrö-
ße der Aufgabe, die auf dem großen System ausgeführt wird um den gleichen Faktor zunimmt,
um den die Leistungsfähigkeit des großen Systems zunimmt. Der Scaleup ist dann das Verhältnis
der beiden Ausführungszeiten, die die Systeme für die Bearbeitung der ihnen gestellten Aufga-
ben benötigen.
Ausführungszeit (Problem A, System 1)
Scaleup =
Ausführungszeit (Problem B, System 2)

Der Scaleup wird als linear bezeichnet, wenn der Quotient der beiden Ausführungszeiten eins ist.
In diesem Fall ist das große System in der Lage eine entsprechend größere Aufgabe in der glei-
chen Zeit zu lösen, in der das kleine System die kleine Aufgabe löst. Dieses Testverfahren ist
besonders geeignet, um das Verhalten der Systeme bei der Ausführung von einzelnen großen
Aufgaben zu untersuchen. Eine gute Parallelisierbarkeit liegt vor, wenn ein linearer Scaleup er-
reicht wird.
Es gibt drei Einflussgrößen, die den Zeitgewinn bei der Parallelisierung beeinflussen können.
Als Startup wird die Initialisierungsphase beim Starten einer parallelen Verarbeitung bezeich-
net. In dieser Initialisierungsphase können möglicherweise noch keine Parallelisierungstechniken
zum Einsatz gebracht werden. Deshalb wird hierbei durch ein paralleles System noch keine ent-
sprechende Beschleunigung erzielt. Nimmt der Startup einen relativ großen Anteil der Ausfüh-
rungszeit ein, wird nur ein schlechter Wert für den Speedup und den Scaleup erreicht. Ein Bei-
spiel für solch eine Initialisierungsphase könnte die Ermittlung des Ausführungsplans für einen
Datenbankverarbeitungsprozess sein.
Als Interference wird der Einfluss bezeichnet, den ein neuer Prozess auf das Laufzeitverhalten
der anderen gleichzeitig ausgeführten Prozesse hat. Da dieses jeden der anderen Prozesse be-
trifft, nehmen die Auswirkungen der Interference mit der Anzahl der ausgeführten Prozesse zu.
Dies führt dazu, dass, wenn die Anzahl der parallelen Prozesse zu groß wird, sich die Verarbei-
tungszeit im Vergleich zu einer sequentiellen Ausführung verlängert. Bei Datenbankprozessen