![Abbildung 6.23: Darstellung der unterschiedlichen Skalierbarkeitsarten [155, S.526]](https://www.researchgate.net/profile/Robin-Funck/publication/281834670/figure/fig5/AS:670006375358483@1536753376827/Abbildung-623-Darstellung-der-unterschiedlichen-Skalierbarkeitsarten-155-S526_Q320.jpg)
Content uploaded by Robin Funck
Author content
All content in this area was uploaded by Robin Funck on Sep 17, 2015
Content may be subject to copyright.
KONZEPTUELLE UND METHODISCHE
AUFARBEITUNG VON
NOSQL-DATENBANKSYSTEMEN
Robin Hecht
KONZEPTUELLE UND METHODISCHE
AUFARBEITUNG VON
NOSQL-DATENBANKSYSTEMEN
Von der Universität Bayreuth
zur Erlangung des Grades eines
Doktors der Naturwissenschaften (Dr. rer. nat.)
genehmigte Abhandlung
von
Robin Stefan Hecht
aus Berlin
1. Gutachter: Prof. Dr.-Ing. Stefan Jablonski
2. Gutachter: Prof. Dr. Thomas Rauber
Tag der Einreichung: 16. September 2014
Tag des Kolloquiums: 11. Dezember 2014
Für Svenja.
i
ZUSAMMENFASSUNG
Big Data beschreibt einen derzeitigen Trend in der Informationsverarbeitung, bei dem
sehr große Mengen an unterschiedlich strukturierten Daten in einer sehr hohen Ge-
schwindigkeit verarbeitet werden. Die hierbei gestellten Anforderungen überschreiten
immer häufiger die Kapazität und die Leistungsfähigkeit von relationalen Datenban-
ken, die seit Jahrzehnten erfolgreich in der Datenverarbeitung eingesetzt werden.
Führende Internetunternehmen sahen sich deshalb zu Beginn dieses Jahrtausends
dazu gezwungen, neue Datenbanksysteme zu entwerfen, die auf die spezifischen An-
forderungen von Big Data-Anwendungsfällen ausgerichtet sind. Die Konzepte dieser
neuen Datenbanksysteme motivierten die Entwicklung einer Vielzahl weiterer, nicht-
relationaler Datenbanksysteme, die heute unter dem Namen NoSQL-Datenbanken be-
kannt sind.
NoSQL-Datenbanken versprechen eine flexible Datenmodellierung, eine hohe Verar-
beitungsgeschwindigkeit sowie eine lineare Skalierbarkeit und sind daher Mittelpunkt
eines derzeit anhaltenden Hypes um das Thema Big Data. Allerdings existiert kaum
neutrale und qualitativ hochwertige Fachliteratur zu dieser Thematik, sodass über die
Vor- und Nachteile der einzelnen Datenbanksysteme und deren korrekte Verwendung
kaum fachlich fundierten Aussagen vorliegen. Angesichts dieser Problematik ist der
Einstieg in die Welt der NoSQL-Datenbanken mit einem unverhältnismäßig hohen
Aufwand und einer starken Fehleranfälligkeit verbunden.
Ziel dieser Arbeit ist es, den Einstieg in die komplexe NoSQL-Thematik zu erleichtern
und somit die hohen Investitionskosten zu senken, die derzeit mit dem Einsatz eines
NoSQL-Datenbanksystems verbunden sind. Durch eine methodische Aufarbeitung der
diesen Systemen zugrunde liegenden Konzepte können allgemeingültige Aussagen zu
den Vor- und Nachteilen der verschiedenen Datenbanksysteme getroffen und somit
das derzeitig vorhandene Fachwissen nicht nur erweitert, sondern vor allem qualitativ
aufgewertet werden. Basierend auf den Erkenntnissen der konzeptuellen Aufarbei-
tung werden darüber hinaus dringend benötigte Modellierungsmuster erstellt, mit de-
ren Hilfe konzeptuelle Datenmodelle systematisch in die logischen Datenmodelle der
verschiedenen Datenbanken überführt werden können. Die in dieser Arbeit gewonne-
nen Erkenntnisse werden abschließend in einem Kriterienkatalog zusammengefasst,
mit dem selbst unerfahrene Anwender in die Lage versetzt werden, aus der Vielzahl
an derzeit verfügbaren Datenbanksystemen das für einen bestimmten Anwendungs-
fall ideale System auswählen zu können. Dank der klaren Herausstellung der Vor- und
Nachteile der verschiedenen Systeme leistet diese Arbeit einen wertvollen Beitrag zur
Versachlichung der NoSQL-Diskussion.
iii
ABSTRACT
Big Data describes a recent trend in information processing whereby a huge amount of
differently structured data is processed at a very high velocity. The given requirements
this kind of information processing demands, tend to exceed the capacity and perfor-
mance of relational databases at a more frequent rate, which had successfully been
used in data handling for decades. Therefore, at the beginning of the millennium, lead-
ing e-commerce businesses felt compelled to develop new database systems, which are
aligned to specific requirements of Big Data-use cases. The concept of these new data-
base systems motivated the development of a multitude of non-relational database sys-
tems, which are nowadays known as NoSQL databases.
NoSQL databases promise flexible data modeling, high processing speed and linear
scalability. Therefore, they are the center of a currently ongoing hype around the topic
of Big Data. However, there is hardly any neutral- and specialized literature of high
quality for the above-mentioned topic. As a result, there is no qualitative evidence on
the advantages and disadvantages of each database system and their correct applica-
tion. Due to this difficulty, accessing the world of NoSQL databases is associated with
a disproportionate effort and a high susceptibility to errors.
The goal of this thesis is to facilitate the access to the complex topic of NoSQL and to
reduce the high investment costs, which are currently associated with the implemen-
tation of NoSQL databases. Through a methodical reappraisal of the underlying con-
cepts of these systems, universal statements towards advantages and disadvantages
of the different database systems can be made and therefore, existing expert knowledge
can not only be extended, but especially be enhanced qualitatively. Based on the in-
sights of the conceptual reappraisal, urgently needed modeling patterns are created,
whereby conceptual data models can be systematically converted into logical data mod-
els for each of the databases. The knowledge, which is gained within this thesis, is
summarized conclusively in a set of criteria with which even inexperienced users are
enabled to choose the ideal system for a specific use case from the multitude of cur-
rently available database systems. Through the clear emphasis on advantages and dis-
advantages of the different systems, this thesis serves as a valuable contribution to-
wards the objectification of the NoSQL discussion.
v
DANKSAGUNG
Die hier vorliegende Arbeit entstand während meiner Tätigkeit als wissenschaftlicher
Mitarbeiter am Lehrstuhl für Datenbanken und Informationssysteme an der Univer-
sität Bayreuth. Ich möchte mich an dieser Stelle ganz herzlich bei allen Personen be-
danken, die mich in dieser Zeit bei der Anfertigung dieser Arbeit tatkräftig unterstützt
haben.
Mein Dank gilt in erster Linie meinem Doktorvater Prof. Dr.-Ing. Stefan Jablonski,
der mir nicht nur die Chance zur Promotion gab, sondern darüber hinaus durch zahl-
reiche Denkanstöße, Ideen und Ratschläge entscheidend zu dieser Dissertation beige-
tragen hat. Ganz besonders möchte ich mich für die sehr freundschaftliche Atmosphäre
und die hervorragende Unterstützung während meiner Zeit am Lehrstuhl bedanken.
Beides ist in dieser Form alles andere als selbstverständlich.
Zudem möchte ich Dr. Olivier Curé für die lehrreichen Diskussionsrunden in Paris und
Bayreuth danken, in denen ich erstmalig mit NoSQL-Datenbanken in Berührung kam.
Ohne diese konstruktive Zusammenarbeit wäre es nicht zu dem hier vorliegenden Er-
gebnis gekommen.
Prof. Dr. Thomas Rauber danke ich für die Übernahme des Zweitgutachtens und die
kritischen Präsentationsrunden an seinem Lehrstuhl, die mir sehr dabei geholfen ha-
ben, die Inhalte und Ergebnisse dieser Dissertation mit wenigen Worten auf den Punkt
zu bringen.
Mein besonderer Dank gilt meiner Mutter, die mich immer unterstützte und moti-
vierte und ohne deren Engagement ich nicht in die Lage gekommen wäre, diese Arbeit
zu schreiben. Darüber hinaus möchte ich mich ganz herzlich bei Erich für die sehr
zeitintensive Korrektur und die zahlreichen konstruktiven Kritikpunkte bedanken,
die diese Dissertation ungemein bereichert haben. Nicht zuletzt bedanke ich mich bei
Svenja, die nicht nur aufgrund der vielen wertvollen Anregungen aus Blickwinkeln
jenseits der Informatik einen großen Anteil an der Fertigstellung dieser Arbeit hat.
vii
INHALTSVERZEICHNIS
Zusammenfassung ........................................................................................................... i
Abstract .......................................................................................................................... iii
Danksagung ..................................................................................................................... v
Abbildungsverzeichnis ............................................................................................. xiii
Tabellenverzeichnis .................................................................................................. xix
1 Einführung ................................................................................................................... 1
1.1 NoSQL-Datenbanken ........................................................................................ 4
1.1.1 Definition .................................................................................................... 6
1.1.2 Klassifikation ............................................................................................. 8
1.2 Problemstellung ............................................................................................... 10
1.2.1 Fehlende Entwicklungsreife ................................................................... 12
1.2.2 Mangelnde Fachliteratur ........................................................................ 12
1.3 Ziel der Arbeit .................................................................................................. 15
1.4 Verwandte Arbeiten ........................................................................................ 16
1.5 Aufbau der Arbeit ............................................................................................ 17
2 Relationale Datenbanken ....................................................................................... 19
2.1 Einführung ....................................................................................................... 20
2.2 Konzeptuelle Ebene ......................................................................................... 25
2.2.1 Datenmodell ............................................................................................. 25
2.2.2 Anfrageverarbeitung ............................................................................... 28
2.2.3 Datenmodellierung .................................................................................. 32
2.3 Interne Ebene .................................................................................................. 35
2.3.1 Speicherstrukturen .................................................................................. 35
2.3.2 Transaktionen und konkurrierende Zugriffe ......................................... 39
2.4 Verteilte Datenhaltung ................................................................................... 45
2.4.1 Replikation ............................................................................................... 46
Inhaltsverzeichnis
viii
2.4.2 Fragmentierung und Allokation ............................................................. 47
2.4.3 Verteilte Anfrageverarbeitung ................................................................ 51
2.4.4 Verteilte Transaktionsverwaltung .......................................................... 53
2.5 Zusammenfassung ........................................................................................... 56
3 Key Value Stores ....................................................................................................... 59
3.1 Einführung ....................................................................................................... 60
3.2 Konzeptuelle Ebene ......................................................................................... 61
3.2.1 Datenmodell ............................................................................................. 61
3.2.2 Anfrageverarbeitung ................................................................................ 63
3.2.3 Datenmodellierung .................................................................................. 65
3.3 Interne Ebene ................................................................................................... 77
3.3.1 Speicherstrukturen .................................................................................. 77
3.3.2 Transaktionen und konkurrierende Zugriffe ......................................... 78
3.4 Verteilte Datenhaltung .................................................................................... 81
3.4.1 Replikation ............................................................................................... 81
3.4.2 Fragmentierung und Allokation ............................................................. 81
3.4.3 Verteilte Anfrageverarbeitung ................................................................ 84
3.4.4 Verteilte Transaktionsverwaltung .......................................................... 86
3.5 Zusammenfassung ........................................................................................... 89
4 Document Stores ....................................................................................................... 91
4.1 Einführung ....................................................................................................... 92
4.2 Konzeptuelle Ebene ......................................................................................... 93
4.2.1 Datenmodell ............................................................................................. 93
4.2.2 Anfrageverarbeitung ................................................................................ 96
4.2.3 Datenmodellierung ................................................................................ 100
4.3 Interne Ebene ................................................................................................. 110
4.3.1 Speicherstrukturen ................................................................................ 110
4.3.2 Transaktionen und konkurrierende Zugriffe ....................................... 111
4.4 Verteilte Datenhaltung .................................................................................. 114
4.4.1 Replikation ............................................................................................. 114
4.4.2 Fragmentierung und Allokation ........................................................... 115
4.4.3 Verteilte Anfrageverarbeitung .............................................................. 116
Inhaltsverzeichnis
ix
4.4.4 Verteilte Transaktionsverwaltung ....................................................... 118
4.5 Zusammenfassung ......................................................................................... 119
5 Column Family Stores ........................................................................................... 121
5.1 Einführung ..................................................................................................... 122
5.2 Konzeptuelle Ebene ....................................................................................... 122
5.2.1 Datenmodell ........................................................................................... 122
5.2.2 Anfrageverarbeitung ............................................................................. 125
5.2.3 Datenmodellierung ................................................................................ 127
5.3 Interne Ebene ................................................................................................ 139
5.3.1 Speicherstrukturen ................................................................................ 139
5.3.2 Transaktionen und konkurrierende Zugriffe ....................................... 142
5.4 Verteilte Datenhaltung ................................................................................. 144
5.4.1 Replikation ............................................................................................. 146
5.4.2 Fragmentierung und Allokation ........................................................... 146
5.4.3 Verteilte Anfrageverarbeitung .............................................................. 146
5.4.4 Verteilte Transaktionsverwaltung ....................................................... 148
5.5 Zusammenfassung ......................................................................................... 148
6 Kritische Betrachtung von NoSQL ..................................................................... 151
6.1 Strukturelle Vielfalt ...................................................................................... 152
6.1.1 Relationale Datenbanken ...................................................................... 154
6.1.2 Key Value Stores.................................................................................... 159
6.1.3 Document Stores .................................................................................... 161
6.1.4 Column Family Stores ........................................................................... 162
6.1.5 Zusammenfassung ................................................................................. 163
6.2 Hohe Geschwindigkeit ................................................................................... 166
6.2.1 Benchmarks ........................................................................................... 167
6.2.2 Relationale Datenbanken ...................................................................... 176
6.2.3 Key Value Stores.................................................................................... 177
6.2.4 Document Stores .................................................................................... 178
6.2.5 Column Family Stores ........................................................................... 179
6.2.6 Zusammenfassung ................................................................................. 180
6.3 Wachsende Datenmenge ............................................................................... 183
Inhaltsverzeichnis
x
6.3.1 Benchmarks ............................................................................................ 184
6.3.2 Relationale Datenbanken ...................................................................... 190
6.3.3 Key Value Stores .................................................................................... 191
6.3.4 Document Stores .................................................................................... 192
6.3.5 Column Family Stores ........................................................................... 194
6.3.6 Zusammenfassung ................................................................................. 194
6.4 Kritik an NoSQL-Datenbanken .................................................................... 197
6.4.1 Fehlende Entwicklungsreife .................................................................. 198
6.4.2 Geringer Support ................................................................................... 199
6.4.3 Geringe Nachhaltigkeit ......................................................................... 199
6.4.4 Minimale Werkzeugunterstützung ....................................................... 199
6.4.5 Mangelndes Fachwissen ........................................................................ 200
6.4.6 Fehlende Standardisierung ................................................................... 200
6.4.7 Zunehmende Komplexität auf Applikationsebene ............................... 201
6.5 Zusammenfassung ......................................................................................... 202
7 Auswahl eines Datenbanksystems ...................................................................... 205
7.1 Analyse von Anwendungsfällen .................................................................... 206
7.1.1 Key Value Stores .................................................................................... 206
7.1.2 Document Stores .................................................................................... 212
7.1.3 Column Family Stores ........................................................................... 219
7.2 Klassifizierung von Auswahlkriterien .......................................................... 226
7.2.1 Konzeptuelle Ebene ............................................................................... 226
7.2.2 Interne Ebene ......................................................................................... 227
7.2.3 Verteilte Datenhaltung .......................................................................... 227
7.2.4 Sonstige Kriterien .................................................................................. 228
7.3 Erstellung eines Kriterienkatalogs ............................................................... 229
7.3.1 Identifikation der Kriterien .................................................................. 230
7.3.2 Bewertung .............................................................................................. 230
7.3.3 Gewichtung ............................................................................................. 234
7.3.4 Nutzwertberechnung ............................................................................. 235
7.3.5 Kriterienkatalog ..................................................................................... 235
7.4 Polyglot Persistence ....................................................................................... 237
Inhaltsverzeichnis
xi
7.5 Zusammenfassung ......................................................................................... 239
8 Zusammenfassung, Ausblick und Fazit ............................................................. 241
8.1 Zusammenfassung ......................................................................................... 241
8.2 Ausblick .......................................................................................................... 243
8.3 Fazit ................................................................................................................ 245
Literaturverzeichnis ................................................................................................. 247
xiii
ABBILDUNGSVERZEICHNIS
1.1: Charakteristische Eigenschaften von Big Data ....................................................... 2
1.2: Klassifikation von NoSQL-Datenbanken .................................................................. 9
1.3: Verlauf des Gartner Hype-Zyklus ........................................................................... 10
1.4: Aufbau der Arbeit ..................................................................................................... 18
2.1: Drei-Schichten-Modell nach ANSI/SPARC ............................................................. 20
2.2: Vereinfachte Darstellung eines Prädikatorenschemas .......................................... 23
2.3: Konzeptuelles Datenmodell eines Online-Shops .................................................... 24
2.4: Logisches Datenmodell der Entität Kunde ............................................................. 26
2.5: Prädikatorenschema der Relation Kunde ............................................................... 27
2.6: Operationen der relationalen Algebra .................................................................... 30
2.7: Verarbeitung einer SQL-Anfrage ............................................................................ 32
2.8: Logisches Datenmodell eines Online-Shops ........................................................... 34
2.9: Aufbau einer ISAM-Speicherstruktur mit Überlaufseite ...................................... 36
2.10: Aufbau eines B*-Baums mit der Höhe 3 ............................................................... 37
2.11: Konzeptuelles Modell der Entitäten Warenkorb und WarenkorbArtikel ............ 39
2.12: Aktualisierung des Warenkorbs im Rahmen einer Transaktion ........................ 40
2.13: Prinzip des Write Ahead Loggings ........................................................................ 41
2.14: Anfrageverarbeitung einer replizierten Master-Slave-Architektur .................... 47
2.15: Anfrageverarbeitung einer funktional partitionierten Architektur ................... 48
2.16: Gegenüberstellung der horizontalen und der vertikalen Fragmentierung. ....... 49
2.17: Reorganisationsaufwand bei statischer Allokation .............................................. 50
2.18: Vierstufiger Verarbeitungsprozess einer verteilten Leseanfrage ....................... 52
2.19: Abbildung einer erfolgreich durchgeführten Transaktion ................................... 53
2.20: Abbildung einer fehlgeschlagenen Transaktion ................................................... 54
3.1: Caching mithilfe von Memcached ............................................................................ 60
3.2: Logisches Datenmodell der Entität Kunde ............................................................. 62
3.3: Prädikatorenschema des Buckets Kunde ................................................................ 63
3.4: Die Operationen get, set und delete ......................................................................... 64
3.5: Konzeptuelle Darstellung der Entität Kunde ......................................................... 66
3.6: Atomare Abbildung der Entität Kunde ................................................................... 67
Abbildungsverzeichnis
xiv
3.7: Fragmentierte Abbildung der Entität Kunde ......................................................... 68
3.8: Konzeptuelles Datenmodell eines Online-Shops .................................................... 69
3.9: Konzeptuelle Abbildung einer M:N-Beziehung mit zwei 1:N-Beziehungen ......... 70
3.10: Zweistufige Auflösung von referenzierten Adressen ............................................ 70
3.11: Denormalisierte Abbildung einer Adresse ............................................................ 71
3.12: Konzeptuelle Darstellung der Aggregation Kunde-Adresse ................................. 72
3.13: Logische Darstellung der Aggregation Kunde-Adresse ........................................ 72
3.14: Identifikation von Teilmengen auf konzeptueller Ebene ..................................... 74
3.15: Modellierung der identifizierten Teilmengen als Aggregationen ........................ 75
3.16: Logische Darstellung der aggregierten Entität Warenkorb ................................. 76
3.17: Lost Update durch zeitgleiche Aktualisierung ..................................................... 79
3.18: Zeitgleiche Aktualisierung mit Check-and-Set-Funktionen ................................ 80
3.19: Allokation mithilfe von Consistent Hashing ......................................................... 82
3.20: Geringer Reallokationsaufwand beim Hinzufügen eines Servers ....................... 83
3.21: Verarbeitung von verteilten Leseanfragen ........................................................... 85
3.22: Erfolgreiche Aktualisierung eines Datenobjekts auf zwei Servern ..................... 87
3.23: Fehlgeschlagene Aktualisierung eines Datenobjekts auf zwei Servern ............. 87
3.24: Konflikterkennung anhand widersprüchlicher Vektoruhren .............................. 88
4.1: Vergleich der Lesbarkeit zwischen JSON und XML .............................................. 92
4.2: Logisches Datenmodell der Entität Kunde ............................................................. 94
4.3: Prädikatorenschema des Dokuments Kunde .......................................................... 95
4.4: Formulierung von Restriktions- und Projektionsbedingungen in MongoDB ....... 97
4.5: Formulierung von Restriktions- und Projektionsbedingungen in CouchDB ........ 99
4.6: Konzeptuelle Darstellung der Entität Kunde ....................................................... 101
4.7: Abbildung und Anfrage von kompositen Attributen ............................................ 102
4.8: Konzeptuelles Datenmodell eines Online-Shops .................................................. 103
4.9: Zweistufige Auflösung von referenzierten Adressen ............................................ 104
4.10: Konzeptuelle Darstellung der Aggregation Kunde-Adresse ............................... 105
4.11: Logische Abbildung der Aggregation Kunde-Adresse ......................................... 106
4.12: Identifikation von Teilmengen auf konzeptueller Ebene ................................... 108
4.13: Modellierung der identifizierten Teilmengen als Aggregationen ...................... 109
4.14: Logische Darstellung der aggregierten Entitäten .............................................. 110
4.15: Konzeptuelles Modell der Entitäten Warenkorb und WarenkorbArtikel .......... 111
Abbildungsverzeichnis
xv
4.16: Aggregation der Entitäten Warenkorb und WarenkorbArtikel.......................... 113
4.17: Abbildung eines MongoDB-Clusters ................................................................... 115
4.18: Ablauf einer verteilten MapReduce-Anfrage ...................................................... 117
5.1: Logisches Datenmodell der Entität Kunde ........................................................... 123
5.2: Prädikatorenschema der Column Family Kunde ................................................. 124
5.3: Formulierung von Restriktions- und Projektionsbedingungen ........................... 126
5.4: Konzeptuelle Darstellung der Entität Kunde ....................................................... 128
5.5: Restriktion mithilfe eines zusammengesetzten Schlüssels ................................. 129
5.6: Restriktion mithilfe einer Index-Tabelle .............................................................. 130
5.7: Konzeptuelles Datenmodell eines Online-Shops .................................................. 131
5.8: Zweistufige Auflösung von referenzierten Adressen ............................................ 132
5.9: Konzeptuelle Darstellung der Aggregation Kunde-Adresse ................................ 133
5.10: Logische Darstellung der Aggregation Kunde-Adresse ...................................... 134
5.11: Identifikation von Teilmengen auf konzeptueller Ebene ................................... 136
5.12: Modellierung der identifizierten Teilmengen als Aggregationen ...................... 137
5.13: Logisches Datenmodell der aggregierten Entität Kunde ................................... 138
5.14: Aufbau eines SSTables ......................................................................................... 140
5.15: Verarbeitung einer Schreiboperation .................................................................. 140
5.16: Verarbeitung einer Leseoperation ....................................................................... 141
5.17: Konzeptuelles Modell der Entitäten Warenkorb und WarenkorbArtikel .......... 142
5.18: Aggregation der Entitäten Warenkorb und WarenkorbArtikel.......................... 143
5.19: Aufbau eines Column Family Store-Clusters ..................................................... 144
5.20: Hierarchie der Katalogtabellen ........................................................................... 147
6.1: Charakteristische Eigenschaften von Big Data ................................................... 151
6.2: Konzeptuelles Datenmodell eines Artikels und seiner Eigenschaften ............... 153
6.3: Horizontale Abbildung der Relation Artikel ......................................................... 154
6.4: Horizontale Abbildung der Entität Artikel mit heterogenen Eigenschaften ...... 155
6.5: Abbildung der Entitäten Literatur, Artikel und E-Book mittels Vererbung ...... 156
6.6: Vertikale Abbildung der Relation Artikel ............................................................. 157
6.7: Vertikale Abbildung der Relation Artikel mit heterogenen Eigenschaften ........ 157
6.8: Atomare Abbildung des Buckets Artikel ............................................................... 159
6.9: Fragmentierte Abbildung des Buckets Artikel ..................................................... 160
6.10: Darstellung zweier heterogener Artikel ............................................................. 162
Abbildungsverzeichnis
xvi
6.11: Abbildung von heterogenen Artikeln................................................................... 163
6.12: Aufbau eines YCSB-Datensatzes in einem Key Value Store ............................. 169
6.13: Durchsatz und Latenz bei Leseoperationen (Benchmark 1) .............................. 170
6.14: Durchsatz und Latenz bei Leseoperationen (Benchmark 2) .............................. 171
6.15: Durchsatz und Latenz bei Leseoperationen (Benchmark 3) .............................. 171
6.16: Latenzentwicklung bei steigendem Lese-Durchsatz (Benchmark 4) ................ 172
6.17: Latenzentwicklung bei steigendem Lese-Durchsatz (Benchmark 5) ................ 172
6.18: Durchsatz und Latenz bei Schreiboperationen (Benchmark 1) ......................... 173
6.19: Durchsatz und Latenz bei Schreiboperationen (Benchmark 2) ......................... 173
6.20: Durchsatz und Latenz bei Schreiboperationen (Benchmark 3) ......................... 174
6.21: Latenzentwicklung bei steigendem Schreib-Durchsatz (Benchmark 4) ........... 175
6.22: Latenzentwicklung bei steigendem Schreib-Durchsatz (Benchmark 5) ........... 175
6.23: Darstellung der unterschiedlichen Skalierbarkeitsarten .................................. 183
6.24: Durchsatz-Scaleup bei Leseoperationen ............................................................. 186
6.25: Antwortzeit-Scaleup bei Leseoperationen ........................................................... 187
6.26: Durchsatz-Scaleup bei Schreiboperationen ........................................................ 188
6.27: Antwortzeit-Scaleup bei Schreiboperationen ...................................................... 189
6.28: Skalierbarkeitseigenschaften von MongoDB (Durchsatz) ................................. 192
6.29: Skalierbarkeitseigenschaften von MongoDB (Latenz) ....................................... 193
6.30: Kritische Fehlermeldung in der CouchDB-Version 1.0 ...................................... 198
7.1: Tweet von Barack Obama zum Wahlsieg 2012 ..................................................... 208
7.2: Repräsentation von Benachrichtigungen in Tumblr ............................................ 209
7.3: Verlauf des wöchentlichen Datenverkehrs bei Gilt .............................................. 211
7.4: Heterogener Produktkatalog bei CustomInk ........................................................ 213
7.5: Ein typischer Artikel auf der Plattform The Business Insider. ........................... 214
7.6: Relationales Datenmodell eines Artikels .............................................................. 215
7.7: Datenmodell eines aggregierten Artikels .............................................................. 215
7.8: Datenmodell eines Event-Logging-Systems bei Ebay .......................................... 220
7.9: Datenmodell zur Speicherung von Benutzerinteraktionen bei Google ............... 221
7.10: Von Facebook Insights bereitgestellte Nutzerstatistiken .................................. 222
7.11: Datenmodell von Facebook Insights .................................................................... 223
7.12: Datenmodell von Googles Webcrawler ................................................................ 223
7.13: Datenmodell von Facebook Messages ................................................................. 224
Abbildungsverzeichnis
xvii
7.14: Die Vor- und Nachteile der unterschiedlichen Datenbankklassen ................... 237
xix
TABELLENVERZEICHNIS
2.1: SQL ist relational vollständig .................................................................................. 31
2.2: Von SQL unterstützte Operatoren .......................................................................... 32
2.3: Komponenten des ER-Modells und des relationalen Modells ............................... 33
2.4: Zugriffskosten der wichtigsten Operationen .......................................................... 39
2.5: Isolationslevel des SQL92 Standards und die jeweils vermiedenen Anomalien .. 44
2.6: Funktionsumfang von relationalen Datenbanken ................................................. 56
3.1: Gegenüberstellung der unterschiedlichen Strukturbezeichnungen ..................... 61
3.2: Unterstützte relationale Operationen und Operatoren ......................................... 65
3.3: Übereinstimmungen zwischen dem ER-Modell und Key Value Stores ................ 73
3.4: Performanz bei server- und clientseitiger Koordination ........................................ 85
3.5: Funktionsumfang von Key Value Stores ................................................................ 90
4.1: Gegenüberstellung der unterschiedlichen Strukturbezeichnungen ..................... 93
4.2: Angabe von Datentypen mithilfe von Code-Konventionen .................................... 94
4.3: Unterstützte relationale Operationen und Operatoren ....................................... 100
4.4: Übereinstimmungen zwischen dem ER-Modell und Document Stores .............. 107
4.5: Funktionsumfang von Document Stores ............................................................... 120
5.1: Gegenüberstellung der unterschiedlichen Strukturbezeichnungen ................... 123
5.2: Unterstützte relationale Operationen und Operatoren ....................................... 127
5.3: Übereinstimmungen zwischen dem ER-Modell und Column Family Stores ..... 135
5.4: Funktionsumfang von Column Family Stores ...................................................... 149
6.1: Vor- und Nachteile der unterschiedlichen Abbildungsvarianten ........................ 164
6.2: Konfigurationen der verschiedenen YCS-Benchmarks ........................................ 169
6.3: Gegenüberstellung der Leistungsfähigkeit der Datenbanksysteme ................... 181
6.4: Durchsatz-Scaleup bei Leseoperationen ............................................................... 186
6.5: Antwortzeit-Scaleup bei Leseoperationen ............................................................ 187
6.6: Durchsatz-Scaleup bei Schreiboperationen .......................................................... 188
6.7: Antwortzeit-Scaleup bei Schreiboperationen ....................................................... 189
6.8: Gegenüberstellung der Skalierbarkeitseigenschaften ......................................... 196
6.9: Vergleich des Funktionsumfangs .......................................................................... 201
6.10: Eigenschaften der Datenbanksysteme ................................................................ 203
Tabellenverzeichnis
xx
7.1: Bewertungsskala..................................................................................................... 230
7.2: Bewertung der konzeptuellen Ebene ..................................................................... 231
7.3: Bewertung der internen Ebene .............................................................................. 232
7.4: Bewertung der verteilten Datenhaltung ............................................................... 232
7.5: Bewertung der sonstigen Kriterien ....................................................................... 233
7.6: Kriterienkatalog zur Auswahl eines Datenbanksystems ..................................... 236
1
1
EINFÜHRUNG
Kapitelinhalt
Big Data
NoSQL-Datenbanken
Problemstellung und Zielsetzung
Der Begriff Big Data entwickelte sich in den letzten Jahren zum absoluten Top-Thema
in der IT-Welt [29, 66] und ist spätestens seit Bekanntwerden der Überwachungs- und
Spionageaffäre der National Security Agency (NSA) auch in den Fokus der öffentlichen
Wahrnehmung gerückt. Big Data beschreibt sehr große Datenmengen, die zum Ge-
winn entscheidungsrelevanter Informationen aus unterschiedlichen Quellen erfasst,
gespeichert, analysiert und visualisiert werden können. Diese Informationen können
von Unternehmen herangezogen werden, um neue Geschäftsfelder zu identifizieren,
Geschäftsprozesse zu optimieren oder um Wettbewerbsvorteile durch eine bessere
Kundenbeziehung zu erzielen. In der Forschung können Daten aus Versuchen, Simu-
lationen und Messungen wesentlich umfangreicher als bisher ausgewertet und somit
neue Erkenntnisse gewonnen werden. Behörden erhoffen sich dagegen wichtige Infor-
mationen zur Kriminalitäts- und Terrorismusbekämpfung. Die Auswertung der in ei-
ner zunehmend digitalisierten Welt anfallenden Datenmenge verspricht ein derart
großes Gewinnpotenzial, dass um den Begriff Big Data ein regelrechter Hype entstan-
den ist. Nicht selten ist vom „Öl des Digitalen Zeitalters“ [95] oder dem Ausbruch eines
„neuen Goldrausches“ [58] die Rede.
Big Data Analysen unterscheiden sich vom klassischen Data Mining im Business In-
telligence in der Datenmenge, der Verarbeitungsgeschwindigkeit und der Datenviel-
falt (Abbildung 1.1) [64].
1 Einführung
2
Abbildung 1.1: Charakteristische Eigenschaften von Big Data
Datenmenge
Big Data beschreibt in erster Linie die extrem großen Datenmengen, die in immer
mehr Datenbanken von Unternehmen, Instituten und Behörden verarbeitet werden
müssen. Durch die rasante Weiterentwicklung und Verbreitung von Informations- und
Kommunikationstechnologien ist gegenwärtig ein exponentielles Wachstum [63] die-
ser Datenmenge zu beobachten. Treibende Faktoren für diese Informationsflut sind
unter anderem das Web 2.0, mobile Endgeräte und Sensornetze.
Soziale Netzwerke, Videoplattformen, Onlineversandhäuser, Wikis und ähnliche Web
2.0-Plattformen generieren täglich mehrere Petabyte an Daten. Längst können die
Dienste führender Plattformen nur noch unter Zuhilfenahme einer Vielzahl weltweit
verteilter Rechenzentren bereitgestellt werden. Die flächendeckende Verbreitung des
Internets sowie die Zunahme mobiler Endgeräte ermöglicht einen nahezu permanen-
ten und ortsunabhängigen Zugriff auf diese Plattformen, die aus dem Alltag unserer
Informations- und Wissensgesellschaft nicht mehr wegzudenken sind. Darüber hinaus
sind zunehmend mehr mobile Endgeräte in der Lage, mithilfe standortbezogener
Dienste den realen Alltag mit zusätzlichen Informationen aus dem Internet anzurei-
chern. Die Fortschritte im Bereich der sogenannten Augmented Reality (engl. erwei-
terte Realität) verringern nicht nur die Lücke zwischen realer und virtueller Welt, sie
lassen die zu verarbeitende Datenmenge weiter anwachsen. Einen großen Anteil an
der gegenwärtigen Datenexplosion hat auch die zunehmende Integration von Sensoren
in Alltagsgegenständen, wie beispielsweise Kleidungsstücken oder Haushaltsgeräten.
So bieten GPS-Sensoren in Sportschuhen [133] die Möglichkeit, die Laufleistung in
Echtzeit zu überwachen und diese Daten anschließend am Computer auszuwerten.
Parallel hierzu sorgt die RFID-Technologie gegenwärtig in der industriellen Fertigung
[154] und in der Logistikbranche für eine zunehmende Rationalisierung von Geschäfts-
prozessen. Durch die kontaktlose Übertragung von Paketinformationen können Ver-
sandunternehmen immer mehr Schritte im Zustellungsprozess automatisieren und in-
folgedessen nicht nur Kosten einsparen, sondern auch den Kundenservice dank einer
1.1 NoSQL-Datenbanken
3
gestiegenen Transparenz erhöhen. Nach der Vision des Internet der Dinge werden Ge-
genstände in den kommenden Jahren nicht mehr nur passiv, sondern auch vermehrt
aktiv mit ihrer Umgebung kommunizieren. Das Potenzial dieser Smart Objects ist da-
bei kaum absehbar und prägt die gegenwärtigen Entwicklungsbereiche Industrie 4.0,
Smart Living und vernetzter Autoverkehr [62]. Hinzu kommt die gewaltige Daten-
menge, die Sensornetze in wissenschaftlichen Einrichtungen wie CERN oder NASA
generieren.
Die beschriebene Entwicklung von Informations- und Kommunikationstechnologien
führt zu einem erleichterten Zugang zu Metainformationen, die über einzelne Perso-
nen gesammelt werden können. Der sogenannte „Digitale Schatten“ [63] eines Men-
schen wächst durch die Aufzeichnung seines Surfverhaltens im Internet, seiner Bewe-
gungsprofile im Alltag sowie seiner virtuellen und realen Einkäufe. Die mithilfe dieser
Daten erstellten personenbezogenen Profile ermöglichen eine Verbesserung des Ser-
viceumfangs von Informations- und Kommunikationssystemen und können von Un-
ternehmen zur Intensivierung ihrer Kundenbeziehungen herangezogen werden. Per-
sonenbezogene Profile besitzen jedoch nicht nur im E-Commerce eine steigende Bedeu-
tung, auch Behörden verarbeiten zunehmend mehr personenbezogene Daten, um bei-
spielsweise Straftaten aufklären oder verhindern zu können. Der Informationsgehalt,
der durch die Auswertung dieser Daten gewonnen werden kann, ist derart wertvoll,
dass immer mehr Metainformationen gesammelt und verarbeitet werden und somit
die generierte Datenmenge ständig weiter ansteigt. Der hierbei von Unternehmen und
Behörden betriebene Aufwand sowie die hieraus resultierende Datenschutzproblema-
tik rücken verstärkt in den Fokus der öffentlichen Wahrnehmung. Berichte über
Google Street View, ACTA oder die NSA zogen nationale und internationale Proteste
auf gesellschaftlicher und politscher Ebene nach sich.
Geschwindigkeit
Neben der steigenden Informationsflut, die infolge von Web 2.0 Plattformen, mobilen
Endgeräten und Sensornetzen erzeugt wird, ist die hohe Geschwindigkeit, mit der
diese Daten gesammelt, verarbeitet und wieder bereitgestellt werden müssen, charak-
teristisch für Big Data. So müssen führende Internetplattformen wie Twitter und
YouTube nicht nur über 347.000 Tweets [97] beziehungsweise über 100 Stunden Vi-
deomaterial [185] pro Minute an neuen Daten verarbeiten, sie müssen ihren Nutzern
diese Daten anschließend, wie im Beispiel von Twitter, auch „in Echtzeit“ zur Verfü-
gung stellen. Fallstudien von Google [22] und Amazon [104] belegen, wie sensibel Be-
nutzer auf geringste Verzögerungen der Webplattformen reagieren. Wenige Millise-
kunden Latenz reichen demnach aus, um deutliche Rückgänge bei den Benutzerinter-
aktionen zu registrieren und dadurch einen signifikanten finanziellen Schaden sowie
einen Vertrauensverlust bei den Kunden zu verursachen [45]. Ähnlich verhält es sich
mit den Ergebnissen, die aus Big Data Analysen gewonnen werden. Wurden im Be-
reich des Business Intelligence noch vor einiger Zeit Statistiken und Auswertungen
von Umsätzen und Benutzerverhalten am Ende eines Tages, Quartals oder Jahres er-
stellt, wird inzwischen immer häufiger eine Echtzeitanalyse dieser Daten gefordert.
1 Einführung
4
Systeme wie Google Analytics [72] und Facebook Insights [86] ermöglichen es Betrei-
bern einer Webseite, Statistiken über Benutzergruppen, Click-Stream-Analysen und
Suchverhalten bereitzustellen, die auf erst wenige Sekunden alten Daten basieren.
Hierdurch hofft man frühzeitig Erkenntnisse über Kundenbedürfnisse, Marktentwick-
lungen und den Erfolg von Werbemaßnahmen zu erhalten, die einen entscheidenden
Wettbewerbsvorteil gegenüber der Konkurrenz bedeuten können.
Datenvielfalt
Die dritte typische Eigenschaft von Big Data ist die große Vielfalt der zu verarbeiten-
den Daten. Neben strukturierten Informationen mit tabellarischem Aufbau, welche
die Datenhaltung der vergangenen Jahrzehnte prägten, verarbeiten Informations- und
Kommunikationssysteme heutzutage zunehmend mehr sogenannte unstrukturierte
beziehungsweise semistrukturierte Daten. Zu diesen zählen benutzergenerierte In-
halte wie Statusmeldungen, Emails und Dokumente, aber auch Logdateien, Sensorda-
ten sowie Bild- und Videomaterialien. So haben sich zum Beispiel die im Bereich des
Business Intelligence herangezogenen Daten, mit denen sich im Einzelhandel das
Kaufverhalten von Kunden analysieren lässt, mit dem Aufkommen von Onlineshops
massiv gewandelt. Wurden früher vorwiegend strukturierte Informationen wie Kun-
denstammdaten und getätigte Transaktionen erfasst, kombiniert und ausgewertet,
werden heutige Kundenprofile mit einer großen Vielfalt von unterschiedlichen, we-
sentlich persönlicheren Daten angereichert. Im Bereich des Web Analytics werden
Log-Dateien, Click-Stream-Daten und Trackinginformationen herangezogen, um zu
bestimmen, wie der Kunde auf die Seite gelangt ist, welche Bereiche er angesehen hat
und wie er durch Werbung, Bewertungen und Webseitengestaltung beeinflusst wurde
[114]. Im Idealfall korrelieren diese Daten mit Kunden-, Surf- und Suchprofilen, die
von externen Dienstleistern, wie beispielsweise sozialen Netzwerken, bereitgestellt
werden. Die so gewonnenen Daten unterscheiden sich in ihrem Aufbau und ihrer Viel-
falt deutlich von den strukturierten Daten, die mithilfe von traditionellen Mitteln, wie
personalisierten Kundenkarten und Transaktionsanalysen, gewonnen werden.
1.1 NoSQL-Datenbanken
Der Wandel in der Informations- und Kommunikationsverarbeitung, der durch den
Begriff Big Data beschrieben wird, betraf zu Beginn des 21. Jahrhunderts zunächst
führende Internetunternehmen wie Google, Amazon und Yahoo sowie soziale Netz-
werke wie Facebook, LinkedIn und Twitter. Vor allem die diesen Webseiten zugrunde
liegenden Datenbanken, deren Markt bereits seit Jahrzehnten von relationalen Da-
tenbanken dominiert wird, wurden infolge der teilweise extremen Anforderungen an
ihre Belastungsgrenzen geführt. Google benötigte beispielsweise ein über mehrere tau-
send Maschinen verteiltes Datenbanksystem, das in der Lage ist, die gigantische Da-
tenmenge von über sechzig verschiedenen Produkten und Projekten, wie Google Earth,
1.1 NoSQL-Datenbanken
5
Google Analytics und dem Google Index, effizient verarbeiten zu können. Da beste-
hende Datenbanksysteme diesen sehr hohen Ansprüchen nicht gerecht wurden, ent-
wickelte das Unternehmen mit dem Column Family Store Bigtable [30] ein eigenes
Datenbanksystem, dessen Implementierungskonzept im Jahr 2006 veröffentlicht
wurde. Auch Amazon sah sich zu diesem Zeitpunkt mit ähnlichen Herausforderungen
konfrontiert. Viele unternehmenskritische Dienste und Daten des Onlineshops, wie
Bestsellerlisten, Einkaufswagen, Benutzervorlieben, Verkaufszahlen und Produktka-
taloge, mussten innerhalb riesiger Cluster verteilt werden. Da auch nur kurzzeitige
Ausfälle dieser Dienste massive finanzielle Schäden nach sich ziehen würden, stand
vor allem die Hochverfügbarkeit dieser Dienste im Fokus des Interesses von Amazon.
Weil sich traditionelle Datenbankenlösungen auch hier als ineffizient erwiesen, entwi-
ckelte Amazon den hochverfügbaren Key Value Store Dynamo [45] und stellte dessen
Konzept im Jahr 2007 vor.
Auch wenn Bigtable und Dynamo bis heute ausschließlich innerhalb ihrer Unterneh-
men eingesetzt und nicht zur freien Verfügung gestellt wurden, haben die Veröffentli-
chungen von Google und Amazon für ein hohes Interesse in der Open Source Commu-
nity gesorgt. Inspiriert von den Bigtable- und Dynamo-Konzepten wurden innerhalb
kürzester Zeit neue Datenbanksysteme entwickelt, veröffentlicht und in Unternehmen
wie Yahoo [36], Facebook [99], Twitter [172, 174] und LinkedIn [96] eingesetzt. Diese
Systeme werden auch als Web-Scale-Datenbanken bezeichnet und haben die Bewälti-
gung der „ungeheuren Datenmengen des Web 2.0-Zeitalters im Terabyte- oder Peta-
byte-Bereich“ [50] zum Ziel. Aufgrund der steigenden Anforderungen an Informations-
und Kommunikationssysteme erhalten diese Datenbanken in zunehmendem Maße
auch außerhalb von führenden Internetunternehmen eine erhöhte Aufmerksamkeit,
weshalb sich inzwischen der von Johan Oskarsson und Eric Evans im Jahr 2009 ein-
geführte Begriff „NoSQL“ [153] für diese verteilten, nichtrelationalen Datenbanksys-
teme etabliert hat. Diese Bezeichnung ist dabei nicht unumstritten und häufig auch
irreführend. Einerseits wurde der Begriff bereits 1998 von Carlo Strozzi für eine leicht-
gewichtige relationale Datenbank ohne SQL-Schnittstelle verwendet [165], anderer-
seits ist nicht die Anfragesprache SQL, sondern das relationale Datenbankmodell Ge-
genstand der Kritik der NoSQL Bewegung [161]. Auch wenn Strozzi daher die Bezeich-
nung „NoREL“ für diese neuen nichtrelationalen Datenbanken vorschlug [165], hat
sich dennoch die Bezeichnung „NoSQL“ – vermutlich aus absatzwirtschaftlichen Grün-
den – durchgesetzt.
Innerhalb der NoSQL-Bewegung wird die Verwendung relationaler Datenbanken als
Allzweckwerkzeug („One size fits all“ [164]) in der Datenhaltung kritisiert. Ob Apps
für Smartphones, Web- und Desktopapplikationen, eingebettete Systeme oder Data
Warehouse Systeme, relationale Datenbanken dominieren sämtliche Anwendungsfälle
in allen IT-Bereichen der heutigen Zeit. Selbst wenn in bestimmten Anwendungsfällen
keine relationalen Daten vorliegen, wird häufig viel Zeit und Energie investiert, um
diese Daten mithilfe nicht selten komplexer Transformationen auf das relationale Da-
tenmodell abzubilden. Nach der Philosophie der NoSQL-Bewegung sollten Software-
1 Einführung
6
entwickler in solchen Fällen alternative Datenbankmodelle in Betracht ziehen, die un-
ter Umständen besser zu den Daten und Anforderungen der jeweiligen Anwendungen
passen („Use the right tool for the job“) [84]. Dieses Umdenken kann dazu führen, dass
eine einzige Anwendung verschiedene Datenbanksysteme einsetzt, die jeweils spezifi-
sche Teilanforderungen der Applikation abdecken. In diesem als Polyglot Persistence
bezeichneten Ansatz ist es durchaus üblich, dass parallel zu NoSQL-Datenbanken
auch relationale Systeme eingesetzt werden, weshalb der Begriff „NoSQL“ inzwischen
als „Not Only SQL“ interpretiert wird. Diese Interpretation hebt das Potenzial von
NoSQL-Datenbanken als Ergänzung zu relationalen Datenbanken in bestimmten An-
wendungsfällen hervor und beschreibt somit strenggenommen nicht einzelne Daten-
banksysteme, sondern vielmehr die Systemarchitektur, in der diese Datenbanken ein-
gesetzt werden [153].
1.1.1 Definition
NoSQL-Datenbanken fehlt es jedoch nicht nur an einer klaren, unstrittigen Bezeich-
nung, sondern auch an einer eindeutigen Definition. Da „es weder Gremien noch Or-
ganisationen gibt, die sich um eine Begriffsklärung bemüht haben“ [50], ist die Samm-
lung an Systemen, die sich als NoSQL-Datenbank bezeichnen, entsprechend vielfältig.
Diese Datenbanken unterscheiden sich teilweise so stark in ihren Eigenschaften, dass
eine klare Definition des Begriffs sowie eine anschließende Klassifikation der Systeme
unerlässlich für das weitere Verständnis dieser Arbeit sind.
Kombiniert man die am häufigsten zitierte Definition des NoSQL-Archivs [50] mit der
gegenwärtig verfügbaren Fachliteratur [28, 153], ergeben sich in folgenden Kernpunk-
ten Übereinstimmungen:
Kein relationales Datenmodell,
Schwache Schemarestriktionen,
Kein ACID-Transaktionsmodell,
Einfache Datenreplikation,
Horizontale Skalierbarkeit.
Diese fünf Eigenschaften zielen auf die gestiegenen Anforderungen von Informations-
und Kommunikationssystemen des 21. Jahrhunderts ab [153].
1.1 NoSQL-Datenbanken
7
Kein relationales Datenmodell und schwache Schemarestriktionen: Die Forde-
rung nach nichtrelationalen Datenmodellen mit schwachen Schemarestriktionen ist
auf die steigende strukturelle Vielfalt der zu verarbeitenden Daten zurückzuführen.
Dank des Einsatzes von flexibleren Datenmodellen können einerseits heterogene Da-
tensätze, wie sie gerade im Umgang mit semistrukturierten Daten typisch sind [148,
S.6], effizienter verwaltet werden und andererseits kann auf strukturelle Änderungen
mit einem wesentlich geringeren Aufwand reagiert werden. Diese Vorteile können de-
nen des sauber strukturierten relationalen Datenmodells beispielsweise in der agilen
Entwicklung von Webapplikationen überlegen sein, bei der die vergleichsweise häufig
auftretenden Schemaänderungen hohe Kosten verursachen können. In solchen Fällen
kann ein bewusster Verzicht auf die Vorzüge des relationalen Datenmodells, wie die
mächtige Anfragesprache SQL oder das umfangreiche Typsystem, eine durchaus kos-
teneffizientere Alternative darstellen.
Kein ACID-Transaktionsmodell, einfache Datenreplikation und horizontale
Skalierbarkeit: Der Verzicht auf ein ACID-kompatibles Transaktionsmodell ist den
steigenden Geschwindigkeitsanforderungen geschuldet. In Anwendungsfällen, in de-
nen nur sehr einfache Lese- und Schreiboperationen ausgeführt werden und Daten
zudem keine hohen Konsistenzanforderungen besitzen, kann eine strikte Umsetzung
der ACID-Eigenschaften einen unnötigen Mehraufwand darstellen. Vor allem in ver-
teilten Datenbanksystemen kann in Anbetracht der erhöhten Kommunikationskosten
ein Verzicht auf eine strikte Konsistenz sinnvoll sein. Die Forderungen nach einfacher
Datenreplikation und horizontaler Skalierbarkeit basiert auf den steigenden Mengen
an Anfragen und Daten, die in vielen Anwendungsfällen verarbeitet werden müssen.
Im Gegensatz zu relationalen Datenbanken sind NoSQL-Datenbanken von Beginn an
für einen Einsatz in verteilten Systemen konzipiert. Diese Systeme sind deswegen in
der Lage, ohne den Einsatz zusätzlicher Werkzeuge und ohne Anpassungen auf Appli-
kationsebene, auf mehrere Server verteilt zu werden.
Häufig werden NoSQL-Datenbanken neben den fünf oben genannten Eigenschaften
durch weitere Merkmale charakterisiert. So wird die freie Verfügbarkeit dieser Sys-
teme sowie deren einfache, von SQL abweichende Schnittstelle als typisch für NoSQL
Systeme angesehen [50]. Da es sich bei Dynamo und Bigtable jedoch um proprietäre
Systeme handelt und in den vergangenen Jahren immer mehr NoSQL-Datenbanken
mit SQL-ähnlichen Anfragesprachen ausgestattet wurden, sind diese beiden Eigen-
schaften offensichtlich nicht für alle Systeme bindend. Dennoch fällt auf, dass in
NoSQL-Datenbanken einfache, schlüsselbasierte Operationen dominieren [28].
Typisch für NoSQL-Datenbanken ist dagegen deren hoher Spezialisierungsgrad. An-
gesichts ihrer schlanken Architektur und des geringeren Funktionsumfangs verfügen
sie zwar über kein so breites Anwendungspotenzial wie relationale Datenbanken, sie
erzielen jedoch wegen ihre Spezialisierung Vorteile bei der Geschwindigkeit und der
Verteilung.
1 Einführung
8
1.1.2 Klassifikation
Auch wenn relationale Datenbanken seit Jahrzehnten den Markt dominieren [166],
wurden immer wieder alternative Datenbanksysteme entwickelt, die gezielt die
Schwächen des relationalen Datenmodells mit neuen Konzepten zu lösen versuchten.
Zu den bekanntesten Vertretern gehören Objekt- beziehungsweise objektrelationale
Datenbanken, die „seit den 90er Jahren die vielleicht erste ernstzunehmende Alterna-
tive“ [50] zu relationalen Datenbanken darstellen, sowie XML- und Graphdatenban-
ken. Während objektrelationale Datenbanken in der Lage sind, den sogenannten Im-
pedance Mismatch
1
zu beheben, wurden XML-Datenbanken entwickelt, um die primär
durch das Internet vermehrt auftretenden semistrukturierten Daten mithilfe von
XML-Dokumenten besser verarbeiten zu können. Im Gegensatz hierzu sind Graphda-
tenbanken auf die Analyse von umfangreichen Beziehungen zwischen Objekten aus-
gelegt, wie sie bei komplexen Suchanfragen oder Freundschaftsempfehlungen in sozi-
alen Graphen auftreten können.
Bei all diesen Systemen handelt es sich um nichtrelationale Datenbanken mit teilweise
schwächeren Schemarestriktionen, welche vorwiegend eine Alternative zum relationa-
len Datenbankmodell darstellen. Sie genügen jedoch nicht den Leistungsfähigkeitsan-
forderungen der NoSQL-Definition, da sie größtenteils weder ein von ACID abweichen-
des Konsistenzmodell noch eine einfache Datenreplikation aufweisen und nicht ohne
größeren Aufwand horizontal skalierbar sind [28]. Zusätzlich sind diese Systeme auf
eine schnelle und intensive Auflösung von Beziehungen und komplexen Objektverhal-
tensweisen spezialisiert. Damit unterscheiden sie sich von den überwiegend einfachen,
schlüsselbasierten Datensatzanfragen, wie sie für Web-Scale-Datenbanken typisch
sind.
Alle gängigen Klassifikationen [28, 50, 74, 84, 101, 111, 170] orientieren sich bei der
Gruppierung von NoSQL-Datenbanken an deren Datenmodellen. Auch wenn sich die
einzelnen Bezeichnungen sowie die Anzahl der Kategorien in diesen Arbeiten unter-
einander nicht immer gleichen, kristallisieren sich überwiegend drei Gruppen von
NoSQL-Datenbanken heraus, die im Folgenden als Key Value Stores, Document Stores
und Column Family Stores bezeichnet werden (Abbildung 1.2).
1
Der Impedance Mismatch beschreibt ein Problem in der Informatik, das durch den strukturel-
len Unterschied von Datenobjekten zwischen objektorientierten Programmiersprachen und
relationalen Datenbanken entsteht.
1.1 NoSQL-Datenbanken
9
Abbildung 1.2: Klassifikation von NoSQL-Datenbanken
Key Value Stores: Key Value Stores basieren auf einem sehr einfachen Datenmodell,
bei dem jeweils ein Schlüssel auf einen einzigen Wert verweist. Da dieser Wert in der
Regel beliebige Bytesequenzen annehmen kann, sind Key Value Stores entsprechend
vielseitig einsetzbar. Key Value Stores sind in der Lage, einzelne Datensätze sehr effi-
zient und in hoher Geschwindigkeit zu verarbeiten. Der Nachteil dieser Systeme liegt
jedoch in ihrem minimalistischen Funktionsumfang. Beispiele für Key Value Stores
sind Dynamo, Project Voldemort und Redis.
Document Stores: Diese Systeme verwalten einzelne Datensätze in sogenannten Do-
kumenten. Hierbei handelt es sich um strukturierte Sammlungen von Schlüssel-Wert-
Paaren, die überwiegend im ausdrucksstarken JSON-Format abgelegt werden. Auf-
grund der daraus resultierenden hohen Flexibilität in der Datenmodellierung und der
relativ großen Mächtigkeit der Systeme stellen Document Stores eine Alternative zu
relationalen Datenbanken in Anwendungsfällen mit heterogenen Datensätzen dar. Zu
den bekanntesten Document Stores gehören CouchDB und MongoDB.
Column Family Stores: Column Family Stores sind eine Mischung aus Key Value
Stores, spaltenorientierten Datenbanken
2
und relationalen Datenbanken [50, S.7]. Ein
Datensatz wird durch eine Sammlung von Schlüssel-Wert-Paaren beschrieben. Diese
können horizontal angeordnet und daher als Zeile in einer Tabelle dargestellt werden.
2
Spaltenorientierte Datenbanken speichern ihre Daten physisch nicht zeilenweise, sondern
spaltenweise ab. Hierdurch besitzen diese Systeme Vorteile in Anwendungsgebieten, wie bei-
spielsweise Data Warehousing, bei denen häufig nur wenige Attribute von sehr vielen Daten-
sätzen für Berechnungen herangezogen werden.
1 Einführung
10
Schlüssel-Wert-Paare, die in mehreren Datensätzen vorkommen, können dann spal-
tenweise zu sogenannten Column Families gruppiert werden. Column Family Stores
wurden für die Verarbeitung sehr großer Datenmengen entworfen und weisen eine
hohe Systemkomplexität auf. Die im Laufe dieser Arbeit näher vorgestellten Column
Family Stores sind Bigtable, HBase und Cassandra.
1.2 Problemstellung
Das Marktforschungsunternehmen Gartner
3
wählte NoSQL-Datenbanken zu einem
der wichtigsten Trends für Informationsinfrastrukturen im Jahr 2013 [66]. Demnach
genießen NoSQL-Datenbanken gegenwärtig deren bisher größte mediale Aufmerk-
samkeit und folgen somit einem fünf Phasen umfassenden Modell [65], das neue Tech-
nologien für gewöhnlich durchlaufen (Abbildung 1.3).
Abbildung 1.3: Verlauf des Gartner Hype-Zyklus
In der ersten Phase („Technologischer Auslöser“) stößt eine erste Veröffentlichung oder
ein Projektstart auf ein erhöhtes Interesse in der Fachwelt. Infolge weiterer Veröffent-
lichungen sowie der Entwicklung anderer, konzeptuell ähnlicher Systeme, rückt die
neue Technologie verstärkt in die Wahrnehmung einer breiteren Öffentlichkeit. Eine
unsachliche und häufig überstürzte Berichterstattung über erste Erfolgsgeschichten,
in denen Fehler und Schwierigkeiten im Umgang mit der neuen Technologie gerne
3
http://www.gartner.com
1.2 Problemstellung
11
verschwiegen werden, sorgen in der zweiten Phase („Gipfel der überzogenen Erwar-
tungen“) für eine übertriebene und unrealistische Erwartungshaltung. Dieser kann die
neue Technologie in der dritten Phase („Tal der Enttäuschungen“) nicht gerecht wer-
den. Die hierdurch provozierten Misserfolge führen sehr schnell zu einem starken
Rückgang des Interesses und sorgen schließlich dafür, dass die Technologie wieder aus
dem Fokus der öffentlichen Wahrnehmung gerät. Nur dank einer konsequenten Wei-
terentwicklung und Zusammenarbeit mit den nicht vom Hype beeinflussten Nutzern
kann die vierte Phase („Pfad der Erleuchtung“) erreicht werden. Hier beginnt sich der
wahre kommerzielle Wert der neuen Technologie herauszukristallisieren. Sobald Er-
fahrungen über die tatsächlichen Vorteile, den Umgang und auch die Grenzen der
Technologie bekannt sind und Zweit- und Drittgenerationen der Technik veröffentlicht
werden, ist die fünfte Phase („Plateau der Produktivität“) erreicht. Hier entscheidet
sich, ob sich die neue Technologie langfristig auf dem Markt durchsetzen oder ein Ni-
schenprodukt bleiben wird [65].
Gartner veröffentlicht jedes Jahr in einem umfassenden Bericht unter anderem eine
grafische Darstellung dieser fünf Phasen und kombiniert diese mit einer Einschätzung
des gegenwärtigen Status von neuen Technologien („Hype Cycle for Emerging Tech-
nologies“). Mithilfe dieses Berichts soll herausgefunden werden, ob es sich bei einer
neuen Technologie um einen kurzfristigen Hype handelt oder ob deren Potenzial tat-
sächlich hoch genug ist, um sich langfristig auf dem Markt zu etablieren.
Auch die NoSQL-Bewegung folgt dieser hier beschriebenen Entwicklung. Die Veröf-
fentlichungen von Google und Amazon in anerkannten Journalen stießen 2006 auf ein
großes Interesse in der Fachwelt. Der praktische Einsatz dieser neuen Techniken in
allseits bekannten und sehr erfolgreichen Produkten, wie dem Amazon Einkaufswagen
oder dem Google Index, animierte die Entwicklung weiterer nicht relationaler Sys-
teme, die seit 2009 unter dem Begriff NoSQL vereint sind (Phase 1). Nachdem in zu-
nehmendem Maße auch andere bekannte Internetunternehmen wie Facebook, Twit-
ter, LinkedIn und Ebay NoSQL-Datenbanken in ihren Infrastrukturen einsetzten und
über ihre Erfolge berichteten, stieg das öffentliche Interesse an diesen Systemen
sprunghaft an. Inzwischen ist gerade in Kombination mit dem Begriff „Big Data“ ein
regelrechter Hype um NoSQL-Datenbanken entstanden, der durch die gegenwärtige
Berichterstattung weiter angeheizt wird. Große Datenmengen werden als „Datengold“
[58], „Goldmine“ [31] oder „Öl des Digitalen Zeitalters“ [95] beschrieben und deren
Auswertungspotenzial mit dem Ausbruch eines „neuen Goldrausches“ [58] gleichge-
setzt.
Laut Gartners Hype-Zyklus können NoSQL-Datenbanken dieser überzogenen Erwar-
tungshaltung nicht gerecht werden. Nach einer Reihe von Misserfolgen wird sich Er-
nüchterung im Hype-Thema NoSQL-Datenbanken einstellen und das „Tal der Enttäu-
schungen“ folgen. Diese Einschätzung erscheint durchaus realistisch, da sowohl die
enthusiastische Berichterstattung in den Massenmedien als auch die häufig sehr ein-
seitigen Diskussionen in Entwicklerblogs und Konferenzvorträgen zwei gravierende
1 Einführung
12
Problempunkte außer Acht lassen: NoSQL-Datenbanken fehlt es zum einen an Ent-
wicklungsreife und zum anderen an qualitativ hochwertiger Fachliteratur.
1.2.1 Fehlende Entwicklungsreife
NoSQL-Datenbanken weisen gegenüber relationalen Datenbanken einen deutlich ge-
ringeren Reifegrad auf. Auch wenn von den meisten NoSQL-Datenbanken inzwischen
Produktivversionen existieren, die scheinbar über eine gewisse Systemstabilität ver-
fügen, fällt dennoch die sehr hohe Frequenz auf, in der neue Versionen der verschie-
denen Datenbanksysteme veröffentlicht werden. Diese sehr kurzen Entwicklungszyk-
len sind einerseits auf die mangelnde Anzahl an Funktionalitäten zurückzuführen, die
Entwickler für den Einsatz dieser Datenbanken benötigen, und ist andererseits der
Instabilität einiger NoSQL-Datenbanken geschuldet, was sich in der relativ hohen An-
zahl von Fehlermeldungen in den Mailinglisten der Anbieter widerspiegelt. Die im
Vergleich zu relationalen Datenbanken geringere Stabilität und Verlässlichkeit sind
selten Bestandteil der gegenwärtigen Berichterstattung und können beim unbedach-
ten Einsatz im produktiven Betrieb sehr schnell zu Misserfolgen führen.
1.2.2 Mangelnde Fachliteratur
Relationale Datenbanken haben sich als Standardlösung in der Datenverarbeitung
etabliert. Die Wahl des konkreten Produkts besitzt häufig eine untergeordnete Priori-
tät, da sich diese Systeme nur in wenigen Eigenschaften voneinander unterscheiden.
Dank jahrzehntelanger Einsatzerfahrung können Anwender auf umfangreiches Fach-
wissen zurückgreifen. Dadurch sind sie in der Lage, nahezu jeden Anwendungsfall auf
ein relationales Datenmodell abbilden und das System entsprechend seiner Eigen-
schaften effizient einsetzen zu können. NoSQL-Datenbanken unterscheiden sich in
diesen beiden Bereichen von relationalen Datenbanken. Aufgrund fehlender Stan-
dards existieren inzwischen über 150 verschiedene Produkte [49], die als NoSQL-Da-
tenbanken bezeichnet werden. Im Gegensatz zu relationalen Datenbanken sind diese
Systeme auf spezifische Anwendungsfälle ausgelegt und unterscheiden sich deshalb
sehr stark in ihren Eigenschaften. Darüber hinaus können Anwender infolge mangeln-
der Fachliteratur nicht ansatzweise auf das Wissen zurückgreifen, das über den effi-
zienten Einsatz von relationalen Datenbanken verfügbar ist. Für potenzielle Anwen-
der eines NoSQL-Datenbanksystems ergeben sich deswegen zu Beginn eines Software-
projekts zwei grundlegende Problemstellungen:
Problem 1 – Die Wahl eines passenden Datenbanksystems
Angesichts der hohen Heterogenität von NoSQL-Datenbanken ist es für Anwender we-
sentlich schwieriger, das für einen Anwendungsfall passende Produkt auszuwählen.
Neben den vielen unterschiedlichen Eigenschaften wird die Wahl auch wegen der ho-
hen Entwicklungsgeschwindigkeit der Systeme erschwert. So kann es vorkommen,
dass Artikel über NoSQL-Datenbanken zum Zeitpunkt ihrer Veröffentlichung bereits
1.2 Problemstellung
13
wieder veraltet sind. Dieser Umstand wird in einer der ersten umfangreichen NoSQL-
Untersuchungen von Cattell [28] deutlich:
”Statements in this paper are based on sources and documentation that may
not be reliable, and the systems described are „moving targets“, so some state-
ments may be incorrect.“ – Cattell [28]
Cattel moniert hierbei neben der hohen Entwicklungsgeschwindigkeit vor allem die
Qualität der verfügbaren Quellen. Mit den Journal-Publikationen von Google, Amazon
und Facebook existieren zwar durchaus anspruchsvolle Artikel, doch stellen diese Ver-
öffentlichungen lediglich zugrunde liegende technische Konzepte einzelner Daten-
banksysteme vor. Detaillierte Aussagen über den praktischen Einsatz sowie über die
aufgetretenen Schwierigkeiten und daraus resultierende Grenzen werden jedoch we-
der hier noch in den Dokumentationen der einzelnen Datenbanksysteme getätigt. Die
wenigen wissenschaftlichen Veröffentlichungen und die im Handel erhältliche Litera-
tur beschränken sich zum Großteil auf eine Zusammenfassung der aus den Journalen
und Dokumentationen verfügbaren Informationen und liefern keine allgemeingültigen
Aussagen. Aus diesen Gründen bilden Entwicklerblogs und Erfahrungsberichte häufig
die einzige Quelle, um Informationen über den praktischen Einsatz von NoSQL-Da-
tenbanken zu erhalten. Diese Beiträge sind jedoch aus der NoSQL-Bewegung heraus
motiviert und lassen neben der gewünschten Qualität auch die nötige Neutralität ver-
missen. Nicht selten werden relationale Datenbanken mit unsachlichen oder nicht
haltbaren Behauptungen belegt, um die vermeintliche Überlegenheit von NoSQL-Da-
tenbanken demonstrieren zu können. Potenzielle Anwender von NoSQL-Datenbanken
müssen sich darum nicht nur mit neuen Technologien auseinandersetzen, sondern au-
ßerdem in der Lage sein, Aussagen über NoSQL-Datenbanken, die aus dem Hype her-
aus motiviert sind, von denen zu trennen, die einen fachlich korrekten Informations-
gehalt besitzen. Ohne ein tiefgreifendes Verständnis von Datenbanktechnologien ist
diese Aufgabe nicht zu bewältigen.
Problem 2 – Der effiziente Einsatz des ausgewählten Datenbanksystems
Für den effizienten Einsatz eines Datenbanksystems sind umfangreiche Kenntnisse
über dessen Eigenschaften unabdingbar. Neben den technischen Details des Systems
gehören hierzu vor allem die spezifischen Eigenschaften des Datenmodells und die da-
mit verbundenen Anfragemöglichkeiten. Während nahezu jedem Entwickler die rela-
tionale Datenmodellierung und die Formulierung von SQL-Statements bestens ver-
traut sind, ist ein vergleichbares Wissen über den Umgang mit NoSQL-Datenbanken
nicht vorhanden. Besonders deutlich wird dieses Problem in der vergleichsweise sehr
umfangreichen Dokumentation der beliebtesten [158] NoSQL-Datenbank MongoDB.
Zum Thema Datenmodellierung, das für den erfolgreichen Einsatz eines Datenbank-
systems essenziell ist, befindet sich trotz mehrjähriger Entwicklungszeit lediglich fol-
gendes Statement:
1 Einführung
14
”Document-oriented data modeling is still young. The fact is, many more ap-
plications will need to be built on the document model before we can say any-
thing definitive about best practices.“ – MongoDB [120]
Wegen des Defizits an allgemeingültigen Abbildungsregeln stehen Entwicklern in der
Regel nur die häufig herangezogenen Anwendungsbeispiele von Google [30], Amazon
[45], Facebook [99], Twitter [172], Ebay [140, 141], LinkedIn [96] und Digg [135] zur
Verfügung, um mögliche Modellierungsmuster identifizieren zu können. Dabei wird
jedoch außer Acht gelassen, dass sich aus den spezifischen Lösungen großer Internet-
unternehmen keine allgemeingültigen Rückschlüsse auf andere, häufig wesentlich
kleinere Anwendungsfälle ziehen lassen.
Bedingt durch den hier beschriebenen Mangel an qualitativ hochwertiger Fachlitera-
tur ist der Einstieg in die alles andere als triviale NoSQL-Thematik äußerst schwierig
und mit einem sehr hohen Aufwand verbunden. Das gilt insbesondere für Anwender,
die keine tiefgreifenden Hintergrundinformationen über die verschiedenen Systeme
besitzen und keine umfangreichen praktischen Erfahrungen im Umgang mit NoSQL-
Datenbanken vorweisen können. Ihnen ist es nur im Rahmen ausgiebiger Tests mög-
lich, aus der Vielzahl zur Verfügung stehender Datenbanken das für einen bestimmten
Anwendungsfall passende System auszuwählen und dieses daraufhin bestmöglich zu
verwenden. Entsprechend groß ist die Gefahr, ein NoSQL-Datenbanksystem aus einer
falschen Motivation heraus und in einer ineffizienten Art und Weise einzusetzen. Der
hier beschriebene Aufwand und das gestiegene Risiko von Fehlentwicklungen sorgen
dafür, dass die Investitionskosten, die mit dem Einsatz eines NoSQL-Datenbanksys-
tems verbunden sind, deutlich höher liegen als bei den bewährten relationalen Lösun-
gen. Berücksichtigt man zusätzlich die potenziellen Kosten, welche durch die ver-
gleichsweise geringe Stabilität der Systeme verursacht werden können, erscheint die
gegenwärtige Erwartungshaltung an NoSQL-Datenbanken deutlich überzogen. Es
wird deswegen nur eine Frage der Zeit sein, bis erste Misserfolge zu einer Ernüchte-
rung des Hypes führen und NoSQL-Datenbanken aus der öffentlichen Wahrnehmung
verschwinden werden. Ob sich NoSQL-Datenbanken anschließend auf dem Markt
etablieren können, hängt davon ab, wie schnell sie sich zu stabilen Systemen weiter-
entwickeln und wie schnell sich deren wahrer Nutzen herauskristallisiert.
1.3 Ziel der Arbeit
15
1.3 Ziel der Arbeit
NoSQL-Datenbanksysteme sind angesichts ihrer fehlenden Entwicklungsreife und der
mangelnden Fachliteratur derzeit nicht in der Lage, die hohen Erwartungshaltungen
zu erfüllen, die an sie gestellt werden. Auch wenn in einer sehr hohen Entwicklungs-
geschwindigkeit neue Datenbankversionen veröffentlicht werden, die einen größeren
Funktionsumfang und eine höhere Systemstabilität aufweisen, liegen die Investitions-
aufwendungen beim Einsatz von NoSQL-Datenbanken vor allem aufgrund der man-
gelnden Fachliteratur weiterhin wesentlich höher als bei relationalen Datenbanksys-
temen. In dieser Problemstellung liegt die Motivation der hier vorliegenden Arbeit.
Ziel dieser Arbeit ist es, den Einstieg in die komplexe Thematik von NoSQL-Datenban-
ken durch eine methodische Aufarbeitung auf konzeptueller Ebene deutlich zu erleich-
tern. Dieser neuartige Ansatz bietet die Möglichkeit, bisher verborgene Informationen
explizit hervorzuheben und somit das Wissen über NoSQL-Datenbanken nicht nur zu
erweitern, sondern auch qualitativ aufzuwerten. Basierend auf den erzielten Ergeb-
nissen sollen allgemeingültige Aussagen über die Vor- und Nachteile der verschiede-
nen Datenbanksysteme hinsichtlich spezifischer Anforderungen getroffen werden. Au-
ßerdem ermöglicht die konzeptuelle und methodische Aufarbeitung die Erstellung von
derzeit dringend benötigten Abbildungsregeln, mit deren Hilfe ein bestimmtes NoSQL-
Datenbanksystem entsprechend seiner Stärken bestmöglich eingesetzt werden kann.
Die hier erzielten Ergebnisse können zu zwei dringend benötigten Hilfsmitteln zusam-
mengefasst werden, die gegenwärtig in der Literatur nicht zu finden sind:
Hilfsmittel 1 – Kriterienkatalog: In dieser Arbeit wird ein Kriterienkatalog entwi-
ckelt, der selbst unerfahrene Anwender in die Lage versetzt, aus der Vielzahl zur Ver-
fügung stehender Datenbanksysteme das für einen Anwendungsfall passende System
auszuwählen. Die Bewertung für die Eignung eines Datenbanksystems basiert auf ei-
ner individuellen Gewichtung verschiedener Auswahlkriterien. Hierdurch können die
spezifischen Anforderungen eines jeden Anwendungsfalls feingranular berücksichtigt
werden.
Hilfsmittel 2 – Modellierungsmuster: Um einen optimalen Einsatz von NoSQL-Da-
tenbanken zu ermöglichen, werden im Rahmen dieser Arbeit verschiedene Modellie-
rungsmuster erstellt. Mithilfe dieser Modellierungsmuster können Problemstellungen
in Anwendungsfällen systematisch auf die spezifischen Datenmodelle der verschiede-
nen Datenbanksysteme überführt und diese dadurch wesentlich effizienter genutzt
werden.
Darüber hinaus leistet diese Arbeit dank der klaren Herausstellung der Vor- und
Nachteile der verschiedenen Systeme einen wertvollen Beitrag zur Versachlichung der
NoSQL-Diskussion.
1 Einführung
16
1.4 Verwandte Arbeiten
In der oben beschriebenen Herangehensweise unterscheidet sich diese Arbeit grundle-
gend von anderen Arbeiten, welche die NoSQL-Bewegung thematisieren. Die Veröf-
fentlichungen von Cattell [28] sowie von Hecht und Jablonski [84] zählen zu den ersten
Fachartikeln, welche ebenfalls einen Überblick über die Vor- und Nachteile der ver-
schiedenen Datenbanksysteme liefern und unterschiedliche Anwendungsgebiete für
NoSQL-Datenbanken vorstellen. Allerdings können diese beiden Arbeiten in Anbe-
tracht des begrenzten Umfangs ausschließlich als Einstiegsliteratur für die NoSQL-
Thematik herangezogen werden.
Einen größeren Überblick über die verschiedenen Datenbanksysteme ist in den Fach-
büchern von Edlich et al. [50] und Tiwari [170] zu finden. Neben den Vor- und Nach-
teilen der einzelnen Systeme werden hierin vor allem die technischen Aspekte der Sys-
teme hervorgehoben. Anhand einer Vielzahl an Quelltextauszügen werden Installati-
onsprozesse beschrieben, der Umgang mit den verschiedenen Schnittstellen demons-
triert und verschiedene Konfigurationsmöglichkeiten thematisiert. Abgesehen davon,
dass diese Beispiele sehr stark von den technischen Eigenschaften bestimmter Daten-
bankversionen abhängig sind, lassen sich infolge der fehlenden konzeptuellen Arbeit
aus diesen Büchern keine allgemeingültigen Rückschlüsse über den Umgang mit
NoSQL-Datenbanken ziehen.
Eine Thematisierung von NoSQL-Datenbanken auf konzeptueller Ebene findet sich
erstmalig im Fachbuch von Sadalage und Fowler [153]. Anhand eines Anwendungs-
beispiels wird hierin ein Modellierungsmuster vorgestellt, mit dessen Hilfe sich Bezie-
hungen zwischen Datensätzen abbilden lassen. Allerdings beschränkt sich die konzep-
tuelle Arbeit ausschließlich auf eben dieses eine Modellierungsmuster, welches zudem
lediglich in einem sehr geringen Umfang behandelt wird. Der komplexe Bereich der
Datenmodellierung, der für den erfolgreichen Einsatz eines Datenbanksystems essen-
ziell ist, wird deshalb auch in dieser Arbeit nicht ausreichend abgedeckt.
Neben den hier beschriebenen Arbeiten, welche die NoSQL-Thematik allgemein be-
handeln, existieren einige Artikel und Fachbücher, die jeweils die spezifischen Eigen-
schaften eines bestimmten Datenbanksystems exklusiv beschreiben. Hierzu zählen in
erster Linie die häufig zitierten Artikel von Google [30], Amazon [45] und Facebook
[99] sowie die verfügbaren Fachbücher über die populären NoSQL-Datenbanken
CouchDB [9, 103], MongoDB [14, 143] und Cassandra [85], aber auch die vielen offizi-
ellen Dokumentationen zu den einzelnen Systemen. In diesen Quellen werden vor al-
lem die technischen Aspekte der verschiedenen Datenbanksysteme ausführlich be-
leuchtet. Dabei stehen die bereitgestellten Funktionalitäten, Implementierungsdetails
und administrative Informationen im Vordergrund. Auch wenn diese Informationen
einen wertvollen Beitrag für die konzeptuelle Aufarbeitung in dieser Arbeit liefern,
sind die getätigten Aussagen ausschließlich auf bestimmte Versionen einzelner Daten-
banksysteme beschränkt. Allgemeingültige Rückschlüsse und Modellierungsmuster
sind darum auch in diesen Arbeiten nicht zu finden. Darüber hinaus ergibt sich bei
1.5 Aufbau der Arbeit
17
diesen Quellen die bereits erwähnte Problematik der fehlenden Neutralität, wodurch
vor allem die Wahl nach einem passenden Datenbanksystem sehr stark erschwert
wird.
1.5 Aufbau der Arbeit
Diese Arbeit ist in acht Kapitel gegliedert und kann in die zwei Teile konzeptuelle und
methodische Aufarbeitung unterteilt werden.
Konzeptuelle Aufarbeitung: Nach einem einführenden Kapitel in die Grundlagen
relationaler Datenbanken, die für das Verständnis dieser Arbeit unabdingbar sind, bil-
den die konzeptuellen Aufarbeitungen von Key Value Stores (Kapitel 3), Document
Stores (Kapitel 4) und Column Family Stores (Kapitel 5) den Schwerpunkt dieser Ar-
beit. In diesen Kapiteln werden die Eigenschaften der verschiedenen Datenbanksys-
teme methodisch herausgearbeitet, die bei der Wahl und dem Einsatz eines Daten-
banksystems von entscheidender Bedeutung sind. Der jeweils erste Teil dieser Kapitel
beinhaltet entsprechend der Zielsetzung dieser Arbeit eine konzeptuelle Rekonstruk-
tion der zugrunde liegenden Datenmodelle. Basierend auf diesen Ergebnissen sowie
einer Analyse der verschiedenen Anfragemöglichkeiten werden anschließend Abbil-
dungsregeln und Modellierungsmuster erstellt, mit deren Hilfe sich konzeptuelle Da-
tenmodelle auf die verschiedenen logischen Datenmodelle von NoSQL-Datenbanken
überführen lassen. Der jeweils zweite Teil dieser Kapitel beschäftigt sich mit den tech-
nischen Grundlagen der jeweiligen Systeme. Neben Zugriffspfaden und Transaktions-
konzepten liegt der Fokus hierbei auf den verschiedenen Replikations- und Vertei-
lungsstrategien.
Methodische Aufarbeitung: In Kapitel 6 wird das Verhalten von relationalen Da-
tenbanken und NoSQL-Datenbanken in Bezug auf Big Data Anforderungen systema-
tisch untersucht und infolgedessen eine sachliche Bewertung des NoSQL-Hypes er-
möglicht. Zu diesem Zweck werden zunächst verschiedene Strategien vorgestellt, mit
denen sich heterogene Datensätze (Datenvielfalt) auf die einzelnen Datenmodelle ab-
bilden lassen. Anschließend werden anhand von Benchmarks die Leistungsfähigkeit
(Geschwindigkeit) und die Skalierbarkeitseigenschaften (Datenmenge) der wichtigs-
ten Datenbanksysteme untersucht. Das Kapitel schließt mit einer kritischen Ausei-
nandersetzung mit NoSQL-Datenbanken. In Kapitel 7 wird der zur Auswahl eines pas-
senden Datenbanksystems benötigte Kriterienkatalog erstellt. Hierzu werden in ei-
nem ersten Schritt entscheidungsrelevante Auswahlkriterien identifiziert und klassi-
fiziert. Anschließend werden die verschiedenen Datenbanksysteme hinsichtlich dieser
Kriterien bewertet und tabellarisch gegenübergestellt.
1 Einführung
18
Im abschließenden Kapitel 8 werden die in dieser Arbeit erzielten Ergebnisse zusam-
mengefasst und ein Ausblick auf die zukünftige Entwicklung der NoSQL-Bewegung
gewagt.
Ein grafischer Überblick über den Aufbau der Arbeit ist in Abbildung 1.4 dargestellt.
Abbildung 1.4: Aufbau der Arbeit
19
2
RELATIONALE DATENBANKEN
Kapitelinhalt
Drei-Schichten-Modell
Wedekindsches Prädikatorenschema
Grundlagen von relationalen Datenbanksystemen
Relationale Datenbanken basieren auf dem 1970 von Codd [33] vorgestellten relatio-
nalen Datenmodell und haben sich seitdem als de facto Standardlösung im Datenma-
nagement etabliert. Heute gehören relationale Datenbanken zu den am weitesten ver-
breiteten und kommerziell am häufigsten eingesetzten Datenbanksystemen [67]. Zu
den bekanntesten relationalen Datenbanken zählen Oracle
4
, MySQL
5
, Microsoft SQL
Server
6
, PostgreSQL
7
und DB2
8
[158].
Um die Motivation hinter der NoSQL-Bewegung nachvollziehen zu können, ist eine
nähere Betrachtung von relationalen Datenbanken hinsichtlich der im vorherigen Ka-
pitel vorgestellten BigData-Anforderungen unabdingbar. Nach einer Einführung in
grundlegende Aspekte der Datenbanktheorie, die für das Verständnis dieser Arbeit
zwingend notwendig sind, werden in diesem Kapitel zunächst die Konzepte relationa-
ler Datenbanken vorgestellt, die für die BigData-Eigenschaft Datenvielfalt relevant
sind. Hierzu zählen das relationale Datenmodell, die Anfragesprache SQL und Kon-
zepte der Datenmodellierung. Der zweite Teil dieses Kapitels setzt sich mit den tech-
nischen Eigenschaften von relationalen Datenbanken auseinander, um eine sachliche
Diskussion bezüglich der BigData-Eigenschaft Geschwindigkeit zu ermöglichen. Be-
standteil dieses Abschnitts sind Zugriffspfade und verschiedene Konzepte der Trans-
aktionsverwaltung. Abschließend werden Konzepte verteilter Datenbanksysteme vor-
gestellt, welche die BigData-Eigenschaft Datenmenge betreffen. Neben verschiedenen
4
http://www.oracle.com/database
5
http://www.mysql.com
6
http://www.microsoft.com/sql-server
7
http://www.postgresql.org
8
http://www.ibm.com/db2
2 Relationale Datenbanken
20
Replikationstechniken wird dabei auf die Fragmentierung und Allokation von Relati-
onen sowie auf die zugrunde liegenden Konzepte verteilter Anfrageverarbeitung und
verteilter Transaktionsverwaltung eingegangen.
2.1 Einführung
Relationale Datenbanken dominieren seit Jahrzehnten den Datenbankmarkt und sind
auch heute noch die kommerziell am häufigsten eingesetzten Datenbanksysteme [66].
Die Grundlagen für diesen Erfolg bilden wissenschaftliche Arbeiten aus den 1970er
Jahren. Zu den wichtigsten zählen hierbei die Veröffentlichungen zum relationalen
Datenmodell von Codd [33, 34]. Parallel entwickelte Bayer die für Zugriffspfade essen-
ziellen B-Bäume [115]. Später folgte das Entity-Relationship-Modell von Chen [142],
das noch heute zur konzeptuellen Datenmodellierung verwendet wird. Einen weiteren
Meilenstein in der Datenbankgeschichte bildet das von IBM entwickelte System R [53],
das als erstes relationales Datenbanksystem gilt und bereits Transaktionskonzepte
und die deskriptive Anfragesprache SEQUEL
9
anwendete [55, S.33].
Abbildung 2.1: Drei-Schichten-Modell nach ANSI/SPARC [55]
9
SEQUEL: Structured English Query Language
2.1 Einführung
21
Auch wenn bis heute viele verschiedene Datenbanksysteme mit teilweise unterschied-
lichen Datenmodellen entwickelt wurden, basieren nahezu alle Systeme auf dem in
Abbildung 2.1 dargestellten Drei-Schichten-Modell, das 1975 von einer Arbeitsgruppe
des ANSI/SPARC
10
vorgestellt wurde. Das Drei-Schichten-Modell ermöglicht mithilfe
verschiedener Beschreibungsebenen unterschiedliche Sichten auf die in einer Daten-
bank enthaltenen Informationen. Man unterscheidet zwischen externer Ebene, kon-
zeptueller Ebene und interner Ebene. Die einzelnen Beschreibungen innerhalb der
Ebenen werden als Schema bezeichnet [76, S.9].
Externe Ebene: Auf externer Ebene werden individuelle Sichten auf die in einer Da-
tenbank verfügbaren Informationen definiert. Hierdurch können exakt die Daten be-
reitgestellt werden, die eine Benutzergruppe oder Anwendung zur Bearbeitung einer
bestimmten Aufgabenstellung benötigt. Neben der Reduzierung der Verarbeitungs-
komplexität und dem gerade in größeren Systemen essenziellen Aspekt der Rechte-
vergabe auf ausgewählte Daten kann auf spezifische Anforderungen, wie beispiels-
weise die Bereitstellung eines speziellen Fachvokabulars, eingegangen werden.
Konzeptuelle Ebene: Zentraler Bestandteil des Drei-Schichten-Modells ist die kon-
zeptuelle Ebene (in Abbildung 2.1 konzeptionelle Ebene genannt). Diese bietet eine
Gesamtansicht auf alle in der Datenbank hinterlegten Informationen. Innerhalb der
konzeptuellen Ebene wird zwischen dem konzeptuellen und dem logischen Schema un-
terschieden. „Das konzeptuelle Schema spiegelt die Informationen über Sachverhalte,
Beziehungen und Vorgänge der betrachteten Miniwelt wieder, die im Datenbanksys-
tem durch Daten repräsentiert werden sollen“ [76, S.10]. Üblicherweise werden hierfür
anschauliche Techniken wie das Entity-Relationship-Modell (ER-Modell) oder die Uni-
fied Modeling Language (UML) eingesetzt, welche „von den meisten Menschen intuitiv
erschlossen werden“ [67, S.198] können. Das logische Schema entspricht einer Abbil-
dung des plattformunabhängigen konzeptuellen Schemas auf die plattformspezifi-
schen Regeln des eingesetzten Datenbanksystems.
Interne Ebene: Die interne Ebene umfasst Informationen über die „Art und den Auf-
bau der Datenstrukturen auf dem physikalischen Speicher“ [55, S.44] sowie über Da-
tenzugriffsmechanismen. Auf dieser Ebene können technische Maßnahmen zur Lauf-
zeitverbesserung, Verfügbarkeit und Sicherheit durchgeführt werden. Diese Ebene ist
abhängig vom konkreten Datenbanksystem und kann sich daher produktabhängig
teilweise erheblich unterscheiden.
Die drei Ebenen sind sowohl physisch als auch logisch voneinander unabhängig, wes-
halb Änderungen einer Ebene keine oder nur minimale Auswirkungen auf die darüber
liegende Ebene nach sich ziehen. So darf das Hinzufügen eines Index auf der internen
10
ANSI: American National Standards Institute; SPARC: Standards Planning and Require-
ments Committee
2 Relationale Datenbanken
22
Ebene keinen Einfluss auf das logische Datenbankmodell der konzeptuellen Ebene ha-
ben und minimale Änderungen auf konzeptueller Ebene, wie die Umbenennung eines
Attributs, sollten keine Änderungen bereits existierender Anwendungen auf der exter-
nen Ebene veranlassen [94, S.22–23].
Da ausschließlich die interne Ebene die tatsächlichen Daten enthält, muss ein Daten-
banksystem sämtliche von Benutzern und Anwendungen formulierten Anfragen in
Operationen der konzeptuellen Ebene und hiernach in Operationen der internen
Ebene übersetzen. Anschließend müssen die Daten im Fall von Leseoperationen wie-
der vom internen Schema bis zum externen Schema durchgereicht und entsprechend
aufbereitet werden. „Diese Vorgänge können sehr zeitaufwendig sein, sodass einige
DBMS, insbesondere solche, die für die Unterstützung kleiner Datenbanken ausgelegt
wurden, keine externen Sichten unterstützen“ [52, S.51].
Im Rahmen des Datenbankentwurfs werden die einzelnen Schemata des Drei-Schich-
ten-Modells mittels einer allgemeingültigen Methodologie systematisch erstellt. Diese
umfasst je nach Definition mehrere aufeinander aufbauende Prozessschritte, die se-
quenziell ausgeführt werden [52, 55, 94]. In ihrem Kern beinhaltet jede Definition vier
essenzielle Entwurfsphasen:
Anforderungsanalyse: Der Datenbankentwurf beginnt mit der Beschreibung des
Ausschnitts der „realen Welt“, der in der Datenbank abgebildet werden soll [94, S.24].
Hierzu werden sämtliche Informationsanforderungen und Datenverarbeitungsvor-
gänge der sogenannten Miniwelt in einem Pflichtenheft spezifiziert.
Konzeptueller Datenbankentwurf: Basierend auf den Informationsanforderungen
des Pflichtenhefts wird das konzeptuelle Schema entworfen. Hierbei handelt es sich
um eine „manuelle / intellektuelle Modellierung“ [94, S.25], bei der „möglichst genau
alle Objekte, Gegenstände und Beziehungen“ [55, S.71] der Miniwelt abgebildet wer-
den.
Logischer Datenbankentwurf: Das konzeptuelle Schema wird anschließend in das
logische Schema der eingesetzten Datenbank überführt. Dieser Prozess kann mithilfe
„halbautomatischer Transformationen“ [94, S.25] erfolgen, bei denen Modellierungs-
werkzeuge einen ersten Entwurf des logischen Schemas generieren. Dieser wird häufig
in weiteren Schritten manuell angepasst, um die im konzeptuellen Schema nicht ent-
haltenen Informationen, wie beispielsweise die im Pflichtenheft definierten Datenver-
arbeitungsvorgänge, zu berücksichtigen.
Physischer Datenbankentwurf: Abschließend werden die physischen Speicher-
strukturen, die Datensatzanordnung und Zugriffsmechanismen spezifiziert, um eine
Effizienzsteigerung zu erzielen. Hierzu ist eine „detaillierte Kenntnis des zugrunde
liegenden Datenbanksystems, aber auch der Hard- und Software […] notwendig“ [94,
S.33].
2.1 Einführung
23
Grundlegender Bestandteil jedes Datenbankentwurfs ist die Definition der Informati-
onsanforderungen der betrachteten Miniwelt. Hierzu werden gleichartige Objekte (En-
titäten) und Beziehungen der realen Welt zu Mengen zusammengefasst. Eine Menge
wird durch bestimmte Eigenschaften (Attribute) charakterisiert. Alle konkreten Enti-
täten oder Beziehungen einer Menge besitzen spezifische Ausprägungen dieser Eigen-
schaften (Attributwerte) und können mithilfe von Schlüsselattributen in dieser Menge
eindeutig identifiziert werden.
Abbildung 2.2: Vereinfachte Darstellung eines Prädikatorenschemas
Die hier beschriebenen Abhängigkeiten zwischen den einzelnen Begriffen können an-
hand des in Abbildung 2.2 dargestellten Prädikatorenschemas [181, S.101] veran-
schaulicht werden. Dabei repräsentiert ein Rechteck eine konkrete Entität der Mini-
welt. Dieser Entität können im Rahmen einer Prädikation erster Ordnung (Ɛ1) ver-
schiedene sogenannte Prädikatoren zugesprochen werden. Zu diesen zählen ein Eigen-
prädikator (Mengennamen), eine bis mehrere Konnotationen (Schlüsselnamen) sowie
mehrere Zusatzprädikatoren (Attributwerte). In einer Prädikation zweiter Ordnung
(Ɛ2) können optional Zusatzprädikatoren mittels Apprädikatoren (Attributnamen) nä-
her beschrieben werden. Um die fachliche Diskussion in dieser Arbeit zu vereinfachen,
werden im Folgenden die hier verwendeten Termini der Orthosprache [108, S.24]
durch die in den jeweiligen Klammern verwendeten Begriffe ersetzt und das Wede-
kindsche Prädikatorenschema gemäß der Darstellung in Abbildung 2.2 angepasst.
Darüber hinaus wird auf eine Unterscheidung zwischen Entitäten und Entitätsmen-
gen sowie Beziehungen und Beziehungsmengen verzichtet. Auch wenn Prädikatoren-
schemata heutzutage bei der Datenmodellierung kaum noch Beachtung finden, wer-
den sie dennoch im Laufe dieser Arbeit immer wieder aufgegriffen, da sich mit ihnen
die Vor- und Nachteile der verschiedenen Datenmodelle sehr gut veranschaulichen
lassen.
Sobald die Entitäten, Beziehungen und deren charakteristische Attribute identifiziert
wurden, kann das konzeptuelle Datenmodell der abzubildenden Miniwelt modelliert
werden. Hierfür werden in der Regel das Entity-Relationship-Modell (ER-Modell) oder
2 Relationale Datenbanken
24
die Unified Modeling Language (UML) herangezogen. Unabhängig von der verwende-
ten Notationsform werden Entitäten durch Rechtecke und Beziehungen als Linien zwi-
schen den entsprechenden Entitäten dargestellt. Attribute werden innerhalb der
Rechtecke notiert. Die so erstellten Modelle enthalten keine Implementierungsdetails
und sind darum relativ leicht verständlich. Sie bieten sich deswegen zur Kommunika-
tion mit den in der Regel nicht datenbankversierten Anwendern an.
Abbildung 2.3: Konzeptuelles Datenmodell eines Online-Shops
Abbildung 2.3 beschreibt ausschnittsweise das konzeptuelle Datenmodell eines On-
lineshops. Hierzu wurden die fünf Entitäten Kunde, Adresse, Warenkorb, Warenkorb-
Artikel und Artikel identifiziert. Jede Entität wird durch bestimmte Attribute näher
beschrieben. Zwischen den einzelnen Entitäten bestehen verschiedene, binäre Bezie-
hungen, die mithilfe sogenannter Kardinalitäten genauer spezifiziert werden. Man un-
terscheidet drei typische Arten von Beziehungen:
1:1-Beziehungen: Einer Entität E1 ist maximal eine Entität E2 zugeordnet und eine
Entität E2 kann zu maximal einer Entität E1 eine Beziehung besitzen. Eine 1:1-Bezie-
hung besteht im oben abgebildeten Beispiel zwischen der Entität Kunde und der Enti-
tät Warenkorb.
1:N-Beziehungen: Einer Entität E1 sind beliebig viele Entitäten E2 zugeordnet.
Gleichzeitig kann eine Entität E2 zu maximal einer Entität E1 eine Beziehung besitzen.
1:N-Beziehungen bestehen in Abbildung 2.3 zwischen den Entitäten Warenkorb und
WarenkorbArtikel sowie zwischen WarenkorbArtikel und Artikel.
M:N-Beziehungen: Einer Entität E1 sind beliebig viele Entitäten E2 zugeordnet und
eine Entität E2 kann Beziehungen zu beliebig vielen Entitäten E1 besitzen. Eine M:N-
Beziehung besteht zwischen der Entität Kunde und der Entität Adresse.
2.2 Konzeptuelle Ebene
25
In der in Abbildung 2.3 beschriebenen Miniwelt besitzt ein Kunde genau einen Waren-
korb und ein Warenkorb ist genau einem Kunden zugewiesen. Jeder Kunde hat min-
destens eine Adresse. Unter einer Adresse muss mindestens ein Kunde erreichbar sein.
Einem Warenkorb kann eine beliebige Anzahl von Artikeln zugeordnet werden. Befin-
det sich ein Artikel in einem Warenkorb, werden die Menge und der Preis für diese
Bestellung in der Entität WarenkorbArtikel gespeichert. Das hier beschriebene kon-
zeptuelle Datenmodell wird im Laufe dieser Arbeit immer wieder herangezogen, um
die vielfältigen Abbildungsmöglichkeiten von konzeptuellen Komponenten auf die ver-
schiedenen logischen Datenmodelle der zu betrachtenden Datenbanksysteme zu erläu-
tern.
2.2 Konzeptuelle Ebene
Das relationale Datenmodell basiert im Wesentlichen auf einfachen Tabellen (Relati-
onen), in denen Zeilen die einzelnen Datenobjekte (Tupel) und Spalten deren jeweili-
gen Eigenschaften (Attribute) repräsentieren. Die Datenverarbeitung erfolgt mithilfe
entsprechender Operatoren ausschließlich mengenorientiert [55, 94].
2.2.1 Datenmodell
Gegeben seien n Wertebereiche (Domänen) D1, D2, …, Dn, deren Werte ausschließlich
atomar sein dürfen. Dann ist eine Relation R als Teilmenge des kartesischen Produkts
(Kreuzprodukt) der n Domänen definiert:
R
D1 x D2 x … x Dn.
Jede Stelle i mit i
{1, …, n} der Relation R bildet ein Attribut, das innerhalb einer
Relation über einen eindeutigen Namen angesprochen wird. Ein Schema der Relation
R besteht aus dem Namen der Relation sowie den Attribut-Domänen-Paaren, wobei
auf die Domänenangabe der Einfachheit halber häufig verzichtet wird:
R (A1: D1, A2: D2, …, An: Dn).
Es wird zwischen einem Schema einer Relation und dessen Elementen (Instanzen)
unterschieden [94, S.71]. Ein Element der Menge R wird als Tupel bezeichnet, dessen
i-te Komponente dem Attribut Ai entspricht. Die Anzahl aller n Attribute wird als Grad
einer Relation bezeichnet, die Anzahl aller Tupel als Kardinalität. Innerhalb einer Re-
lation wird ein Tupel durch den Wert eines Primärschlüssels eindeutig identifiziert.
Dieser entspricht im Idealfall einem oder einer möglichst minimalen Menge an Attri-
buten. Primärschlüssel werden in der Relationennotation unterstrichen:
R (A1: D1, A2: D2, …, An: Dn).
2 Relationale Datenbanken
26
Üblicherweise werden Relationen als Tabellen dargestellt, in denen das Relationen-
schema der Spaltenbeschriftung entspricht und einzelne Tupel durch jeweils eine Zeile
repräsentiert werden.
Abbildung 2.4: Logisches Datenmodell der Entität Kunde
Abbildung 2.4 beschreibt die Relation Kunde, welche der gleichnamigen Entität des in
Abbildung 2.3 dargestellten konzeptuellen Datenmodells entspricht. Sie enthält die
vier verschiedenen Attribute KundenNr, Name, GebDat und Adresse, weshalb sie als
Relation vierten Grades bezeichnet wird. Das mehrwertige Attribut Telefon wird für
gewöhnlich in einer zusätzlichen Tabelle abgebildet. Jedes dieser Attribute besitzt ei-
nen im Relationenschema definierten Wertebereich (Number, String, Date und
String). Das Attribut Adresse wird in diesem Beispiel der Einfachheit halber als eine
Zeichenkette verarbeitet. Das zugehörige Relationenschema lautet daher:
Kunde (KundenNr: Number, Name: String, GebDat: Date, Adresse: String).
Jedes Tupel in der Relation muss zwingend dieser definierten Struktur folgen, das
heißt, jeder Datensatz besteht aus der gleichen Anzahl und Art von Attributen. Jeder
Attributwert eines Datensatzes muss dem für das Attribut definierten Wertebereich
entsprechen. Besitzt ein Tupel für ein bestimmtes Attribut keine Ausprägung, muss
dieser Sachverhalt explizit mit dem Wert null gekennzeichnet werden.
2.2 Konzeptuelle Ebene
27
Abbildung 2.5: Prädikatorenschema der Relation Kunde
Die hohe Ausdrucksstärke des relationalen Datenmodells wird bei der Betrachtung
des entsprechenden Prädikatorenschemas deutlich (Abbildung 2.5). Ein Tupel einer
Relation entspricht einem Objekt der abgebildeten Miniwelt. Es wird durch einen Pri-
märschlüssel identifiziert und durch Attributwerte beschrieben (Prädikation erster
Ordnung). Attributnamen (Prädikationen zweiter Ordnung) sowie der Name des Pri-
märschlüssels werden im Relationenschema verwaltet. Der Name der Relation ent-
spricht dem Namen der Entitätsmenge. Das relationale Datenmodell ist somit in der
Lage, sämtliche Elemente eines Prädikatorenschemas abzubilden.
Um Beziehungen zwischen Objekten darstellen zu können, kann ein Attribut einer
Relation R1 den Schlüsselkandidaten einer Relation R2 referenzieren. Dieser wird in
der Relation R1 als Fremdschlüssel bezeichnet. „Ein Fremdschlüssel darf null-Werte
besitzen“ [55, S.148].
Datenintegrität
„Ein relationales Datenbanksystem soll nicht nur die Daten verwalten, sondern auch
für ihre Korrektheit sorgen“ [55, S.149]. Diese Korrektheit wird als Integrität bezeich-
net und in drei verschiedenen Arten klassifiziert:
Referenzielle Integrität: „Eine Menge von Relationen R1, …, Rk besitzt die referen-
zielle Integrität, wenn jeder Wert eines Fremdschlüssels einer Relation Ri Wert eines
Primärschlüssels in einer anderen Relation Rj ist“ [55, S.149].
Entity-Integrität: „Eine Menge von Relationen R1, …, Rk besitzt die Entity-Integri-
tät, wenn jede Relation einen Primärschlüssel besitzt“ [55, S.149].
Semantische Integrität: „Eine Menge von Relationen R1, …, Rk besitzt die semanti-
sche Integrität, wenn die Korrektheit der Eingaben der Benutzer gewährleistet ist“
[55, S.149].
Zur Einhaltung dieser Integritätsarten können verschiedene Bedingungen formuliert
werden, die vom Datenbanksystem automatisch sichergestellt werden. Referenzielle
2 Relationale Datenbanken
28
Integrität und Entity-Integrität werden durch statische Integritätsbedingungen for-
muliert, die bei jedem Zustand der Datenbank erfüllt sein müssen [94, S.159]. Seman-
tische Integritätsbedingungen können mittels Constraints
11
deklarativ beschrieben
werden. Häufig werden Constraints herangezogen, um den Wertebereich eines Attri-
buts einzuschränken oder bestimmte Werte auszuschließen. Semantische Integrität
kann jedoch auch mit dynamischen Bedingungen unter Zuhilfenahme von Triggern
12
überprüft werden. „Dynamische Integritätsbedingungen beschreiben, welche Bedin-
gungen beim Übergang eines Zustands in einen anderen erfüllt sein müssen“ [55,
S.151]. Hierzu zählt beispielsweise, dass sich das Gehalt eines Angestellten aus-
schließlich erhöhen oder „der Einkaufspreis innerhalb eines Jahres um nicht mehr als
10% steigen darf“ [55, S.151].
2.2.2 Anfrageverarbeitung
Relationale Algebra
Auf dem relationalen Datenmodell lassen sich verschiedene Arten von Operationen
ausführen. Man unterscheidet zwischen Anfrageoperationen und Änderungsoperatio-
nen [76, S.328]. Änderungsoperationen haben die Modifikation des Datenbestandes
zum Ziel. Zu ihnen zählen die Operationen Insert, Update und Delete, mit denen
mehrere Tupel in eine Relation eingefügt, aktualisiert oder gelöscht werden können.
Änderungsoperationen sind immer auf eine Relation beschränkt und werden tupel-
weise bearbeitet. Die für die Änderungsoperationen Update und Delete relevante
Tupel-Menge wird durch Anfrageoperationen spezifiziert [52, S.239].
Anfrageoperationen basieren im relationalen Datenmodell auf der relationalen Al-
gebra. Diese stellt eine fundamentale Grundlage relationaler Datenbanken dar. Mit-
hilfe dieser formalen Sprache können Anfragen an ein relationales Datenbankschema
formuliert und dadurch Informationen zusammengestellt werden. Die relationale Al-
gebra wird als „abgeschlossen“ bezeichnet, da sie Operationen definiert, die auf Rela-
tionen angewendet werden und als Ergebnis erneut Relationen erzeugen. Es ist des-
wegen möglich, eine Sequenz relationaler Algebra-Operationen zu bilden, die als rela-
tionaler Ausdruck bezeichnet wird [52, S.242]. Die einzelnen Operationen eines relati-
onalen Ausdrucks können beliebig ineinander geschachtelt werden [55, S.141].
Die relationale Algebra besteht in ihrem Kern aus sechs Basisoperationen, die im Fol-
genden kurz vorgestellt werden. Man unterscheidet dabei die Operationen, die speziell
11
Constraints definieren Bedingungen wie not null, unique oder check.
12
Trigger sind kleine Programme, die bei Änderungen ausgeführt werden.
2.2 Konzeptuelle Ebene
29
für die relationale Algebra definiert wurden (Restriktion und Projektion) von den klas-
sischen Operationen der Mengenlehre (Kartesisches Produkt, Vereinigung und Diffe-
renz) [55, S.125].
Restriktion (Selektion)
Bei der Restriktion werden die Tupel einer Relation ausgewählt, die eine gegebene
Selektionsbedingung erfüllen. Die Restriktion wird mit
gekennzeichnet und hat die
Selektionsbedingung als Subskript [94, S.86]:
R2 =
<Selektionsbedingung> (R1).
Bei der Selektionsbedingung handelt es sich um einen booleschen Ausdruck, der sich
aus Attributnamen aus R1 oder konstanten Werten, den arithmetischen Vergleichsope-
ratoren (=, ≠, <, ≤, >, ≥) sowie den logischen Operatoren (und), (oder) und ¬ (nicht)
zusammensetzt.
Projektion
Im Gegensatz zur Restriktion, bei der einzelne Tupel (Zeilen) einer Relation ausge-
wählt werden, selektiert die Projektion einzelne Attribute (Spalten). Die Projektion
wird durch das Operatorsymbol π dargestellt und hat einen sogenannten Projektor als
Subskript [94, S.87]. Hierbei handelt es sich um eine Auflistung von Attributen der
entsprechenden Relation R1:
R2 = π <Projektor> (R1).
Kartesisches Produkt (Kreuzprodukt)
Das kartesische Produkt zweier Relationen R und S enthält alle möglichen Paare aus
Tupel tr von R verknüpft mit den Tupel ts von S:
R x S = { tr * ts | tr
R und ts
S}.
Vereinigung (Union)
Zwei Relationen R und S mit gleichem Schema, das heißt gleicher Stelligkeit und iden-
tischen Domänen, können durch die Vereinigung zu einer Relation zusammengefasst
werden [94, S.87]:
R
S = {t | t
R oder t
S}.
Differenz
„Für zwei Relationen R und S mit gleichem Schema ist die Mengendifferenz […] defi-
niert als Menge der Tupel, die in R aber nicht in S vorkommen“ [94, S.88]:
R − S = {t | t
R und nicht t
S}.
2 Relationale Datenbanken
30
Umbenennung
Eine Relation R als auch deren Attribute a1, …, an können mit der Operation ρ umbe-
nannt werden. Es entsteht eine neue, aber identische Relation S mit den Attributen
b1, …, bn:
S = ρ S(b1, …, bn) (R(a1, …, an)).
Diese sechs Operationen „sind ausreichend, um die relationale Algebra formal definie-
ren zu können“ [94, S.90]. Die relationale Algebra umfasst noch weitere Operationen,
die sich jedoch aus den bisher vorgestellten Basisoperationen ableiten lassen und des-
halb nicht näher vorgestellt werden. Auch wenn diese Operationen die Ausdruckskraft
nicht weiter erhöhen, werden sie häufig verwendet, da sie die Formulierung relationa-
ler Ausdrücke wesentlich erleichtern. Zu diesen Operationen zählen Verbund (Join),
Durchschnitt und Division. Eine ausführliche Erläuterung dieser Operationen befin-
det sich unter anderem in Kemper und Eickler [94, S.90] und in Elmasri und Navathe
[52, S.249]. Abbildung 2.6 veranschaulicht die sechs Basisoperationen der relationalen
Algebra.
Abbildung 2.6: Operationen der relationalen Algebra
„Codd [34] hat die Ausdruckskraft von relationalen Anfragesprachen definiert. In sei-
ner Terminologie heißt eine Anfragesprache relational vollständig, wenn sie min-
destens so mächtig ist wie die relationale Algebra“ [94, S.105]. Wie bereits erwähnt, ist
die Bereitstellung der sechs relationalen Basisoperationen (
, π, x,
, −, ρ) hierfür aus-
reichend.
2.2 Konzeptuelle Ebene
31
SQL
Die Structured Query Language (SQL) „ist die Standardsprache
13
zur Kommunikation
mit relationalen Datenbanksystemen“ [67, S.208] und wird in leicht abgeänderter
Form (Dialekt) „von praktisch allen relationalen Datenbanksystemen zur Verfügung
gestellt“ [94, S.111]. SQL „gilt als einer der wichtigsten Gründe für den Erfolg relatio-
naler Datenbanken in der kommerziellen Welt“ [52, S.273].
„SQL beinhaltet einige Merkmale der relationalen Algebra, basiert aber größtenteils
auf dem relationalen Tupelkalkül
14
, also einer weiteren formalen Anfragesprache für
relationale Datenbanken“ [52, S.273-274], die jedoch an dieser Stelle nicht vertieft vor-
gestellt wird. „Im Unterschied zum theoretischen Modell werden in der Praxis einige
Vereinfachungen gemacht, die die Benutzer entlasten und eine effizientere Abarbei-
tung ermöglichen“ [94, S.111]. Trotz dieser Vereinfachung ist SQL streng relational
vollständig, das heißt, jede Operation der relationalen Algebra wird durch genau einen
Datenbankoperator der Anfragesprache umgesetzt (Tabelle 2.1).
Relationale Algebra
SQL
Projektion
Restriktion
Kartesisches Produkt
Vereinigung
Differenz
Umbenennung
Tabelle 2.1: SQL ist relational vollständig
Die bisher vorgestellten Befehle stellen dabei nur eine Teilmenge der sogenannten
Data Manipulation Language (DML) dar. Neben vielen weiteren Operationen der DML
bietet SQL mit der Data Definition Language (DDL) außerdem umfangreiche Möglich-
keiten, das relationale Schema zu definieren und zu ändern. Benutzerrechte lassen
sich mit der Data Control Language (DCL) verwalten. SQL stellt dementsprechend
„alle Funktionen zur Verfügung, die man benötigt, um mit relationalen Datenbanksys-
temen zu arbeiten“ [67, S.212]. Eine vollständige Übersicht über den Umfang von SQL
kann diese Arbeit nicht geben. Es wird daher auf die einschlägige Literatur verwiesen
[52, 67, 94]. Tabelle 2.2 gibt eine Übersicht über alle von SQL zur Formulierung von
Restriktionsbedingungen zur Verfügung gestellten Operationen.
13
ISO/IEC 9075:2011
14
Das relationale Tupelkalkül ist eine formale Anfragesprache, die auf der mathematischen Lo-
gik basiert. Sie ist deklarativ und unterscheidet sich somit von der relationalen Algebra, in der
eine Suchanfrage durch eine Sequenz von Operationen prozedural formuliert wird [52, S.329].
2 Relationale Datenbanken
32
Operator
SQL
Gleich
Ungleich
Größer, Kleiner
Like
In
Exists
And, Or
Not
Tabelle 2.2: Von SQL unterstützte Operatoren
Bei SQL handelt es sich um eine deskriptive Sprache, die im Gegensatz zu prozedura-
len Sprachen nicht definiert, wie eine Aufgabe gelöst werden soll, sondern was als Er-
gebnis erwartet wird. „Die oft sehr komplexen, zur Festlegung der Auswertung nötigen
Entscheidungen werden vom Anfrageoptimierer des Datenbanksystems übernommen“
[94, S.111]. SQL ist deswegen trotz ihrer Mächtigkeit sehr benutzerfreundlich, da An-
wender mithilfe der sehr leicht erlernbaren Syntax nur formulieren müssen, „welche
Daten sie interessieren, und nicht, wie die Auswertung der Daten vorgenommen wird“
[94, S.111].
Abbildung 2.7: Verarbeitung einer SQL-Anfrage
SQL-Anfragen werden, wie in Abbildung 2.7 verdeutlicht, in drei Schritten in ausführ-
baren Code übersetzt. Ein Parser prüft die syntaktische Korrektheit des SQL-State-
ments und formuliert die Anfrage in einen Ausdruck der relationalen Algebra um. Die-
ser Ausdruck wird vom Anfrageoptimierer bearbeitet und in einen Auswertungsplan
übersetzt. Der Auswertungsplan wird abschließend in ausführbaren Code umgewan-
delt [55, S.172].
2.2.3 Datenmodellierung
Die relationale Entwurfstheorie beschäftigt sich mit der Transformation des konzep-
tuellen in das logische Datenbankmodell. Da es viele Möglichkeiten gibt, einen Sach-
verhalt der Miniwelt in einem relationalen Schema darzustellen, ist es das Ziel, ein
möglichst „gutes“ Schema zu entwerfen. Bei der Datenmodellierung wird in der Regel
zweistufig vorgegangen. Zunächst wird das konzeptuelle Modell unter Zuhilfenahme
2.2 Konzeptuelle Ebene
33
von Algorithmen in das relationale Datenmodell überführt. Dieser Prozess kann in
fünf Schritte unterteilt werden:
1. Konvertierung der starken Entitätstypen,
2. Konvertierung der schwachen Entitätstypen,
3. Konvertierung der Beziehungen,
4. Auflösung mehrwertiger Attribute,
5. Konvertierung von is-a-Beziehungen (Spezialisierung, Generalisierung).
Eine detaillierte Beschreibung der einzelnen Abbildungsschritte findet sich unter an-
derem in Elmasri und Navathe [52, S.320]. Die verschiedenen Konstrukte des ER- und
des relationalen Modells sind in Tabelle 2.3 gegenübergestellt. Eine Abbildung von is-
a-Beziehungen ist im relationalen Datenmodell nicht vorgesehen. Eine Vorstellung
von Modellierungsmustern zur Kompensation dieses Nachteils folgt in Kapitel 6.
ER-Modell
Relationales Modell
Entitätstyp
Relation
Entität
Tupel
Einfaches Attribut
Attribut
Zusammengesetztes Attribut
Menge einfacher Attribute
Mehrwertiges Attribut
Relation und Referenzierung
1:1-Beziehung
Referenzierung
1:N-Beziehung
Referenzierung
M:N-Beziehung
Relation und Referenzierung
Tabelle 2.3: Komponenten des ER-Modells und des relationalen Modells
Die systematische Transformation des konzeptuellen in das logische Datenmodell
kann mithilfe von CASE
15
-Werkzeugen automatisch erfolgen. Hierbei wird das kon-
zeptuelle Datenmodell zunächst analysiert. Anschließend werden SQL-DDL-Befehle
generiert, mit denen das relationale Schema erzeugt werden kann. Das so generierte
grobe Datenbankschema benötigt eine in der zweiten Stufe durchgeführte konzeptu-
elle Feinabstimmung [94, S.171]. „Die Basis für diesen Feinentwurf bilden funktionale
Abhängigkeiten“, mit denen sogenannte Normalformen definiert werden. „Normalfor-
men dienen dazu die „Güte“ eines Relationenschemas zu bewerten“ [94, S.171].
15
CASE: Computer Aided Software Engineering. Eine Übersicht über verschiedene Werkzeuge
bietet unter anderem [52, S.604].
2 Relationale Datenbanken
34
Ein gutes Datenbankschema zeichnet sich neben einer hohen Übersichtlichkeit vor al-
lem durch möglichst wenig redundant gespeicherte Informationen aus. So können ei-
nerseits der benötigte Speicherplatz reduziert und andererseits Inkonsistenzen ver-
mieden werden, die durch verschiedene Anomalien verursacht werden [52, 55]. „Wenn
für ein Relationenschema diese Normalformen nicht erfüllt sind, kann man es durch
Anwendung entsprechender Normalisierungsalgorithmen in mehrere Schemata zerle-
gen, die dann die entsprechende Normalform erfüllen“ [94]. „Insgesamt existieren fünf
Normalisierungsregeln, die aufeinander aufbauen“ [55].
In der Praxis kommen hiervon in der Regel maximal die ersten drei Regeln zum Ein-
satz, da mit zunehmendem Normalisierungsgrad der Programmieraufwand und die
Komplexität des Datenmodells steigen und sich parallel Performanzverluste bei der
Anfrage der Daten einstellen können. Dieser Effekt ist vor allem dann zu beobachten,
wenn inhaltlich zusammengehörige Daten über mehrere Tabellen verteilt werden und
sich dadurch die Anzahl der Operationen erhöht, die benötigt werden, um diese ver-
teilten Informationen bei einer Anfrage wieder zusammenzuführen. Bei der Normali-
sierung muss darum zwischen Performanz und Konsistenz des Datenmodells abgewo-
gen werden. Häufig wird das Datenmodell in einem ersten Schritt vollständig norma-
lisiert und dann gezielt an den Stellen denormalisiert, an denen Performanzvorteile
die Nachteile von Redundanzen überwiegen [55, 67]. Eine Möglichkeit, um die Konsis-
tenz der Datenbank trotz eines geringen Normalisierungsgrads gewährleisten zu kön-
nen, bietet der Einsatz von Datenbanktriggern.
Abbildung 2.8: Logisches Datenmodell eines Online-Shops
Abbildung 2.8 beschreibt eine logische Abbildung des in Abbildung 2.3 dargestellten
konzeptuellen Datenmodells eines Online-Shops. In einem ersten Schritt wird jede
konzeptuelle Entität auf eine logische Relation abgebildet. Anschließend muss für jede
M:N-Beziehung, wie beispielsweise die zwischen den Entitäten Kunde und Adresse,
2.3 Interne Ebene
35
eine sogenannte Join-Tabelle (KundeAdresse) angelegt werden. Auch das mehrwertige
Attribut Telefon in der Entität Kunde wird in der Regel durch mindestens eine zusätz-
liche Tabelle abgebildet, weil relationale Datenbanken den Datentyp Map nicht unter-
stützen. Das am Ende erstellte logische Datenmodell umfasst aus diesen Gründen
mehr Entitäten als das zugehörige konzeptuelle Datenmodell.
2.3 Interne Ebene
2.3.1 Speicherstrukturen
In Datenbanksystemen stellen üblicherweise Magnetplatten (Hard Disk Drive – HDD)
das bevorzugte Speichermedium dar. Diese bestehen aus mehreren Oberflächen, die
wiederum mehrere Spuren besitzen, welche schlussendlich in gleich große Blöcke un-
terteilt sind. Sowohl bei Magnetplatten als auch bei den immer mehr an Bedeutung
gewinnenden Solid State Disks (SSD) bilden Blöcke mit durchschnittlich 4096 Bytes
die kleinste Speichereinheit.
Es stehen mehrere verschiedene Speicherstrukturen zur Verfügung, die bestimmen,
wie einzelne Datensätze physisch auf die einzelnen Blöcke einer Platte verteilt werden.
Ziel ist es, diejenige Speicherstruktur zu wählen, die eine möglichst effiziente Daten-
verarbeitung für den jeweiligen Anwendungsfall unterstützt. Die wichtigsten und im
Folgenden vorgestellten Speicherstrukturen sind Heap, ISAM, B*-Baum und Hash-
Funktionen [52, 55].
Neben diesen sogenannten primären Zugriffspfaden können sekundäre Zugriffspfade
(Indizes) definiert werden, die keinen Einfluss auf die physische Speicherung der Da-
tensätze haben. Ähnlich einem Schlagwortverzeichnis am Ende eines Buches sind hier
zu einem bestimmten Schlüsselwert eines Datensatzes eine oder mehrere zugehörige
Speicheradressen hinterlegt, was die Suche nach einem Datensatz erheblich beschleu-
nigen kann. Man unterscheidet dichtbesetzte Indizes, welche die Schlüssel aller Da-
tensätze enthalten und dünnbesetzte Indizes, welche nur auf einige ausgewählte Da-
tensätze verweisen.
Heap
„Die Heap-Struktur (Haufen, sequenzielle Datei) ist die sequenzielle Speicherung der
Daten in der Reihenfolge ihrer Eingabe. Die Daten werden in Blöcken nacheinander
auf der Platte abgelegt, die als lineare Liste miteinander verkettet sind“ [55, S.469].
Aus diesem Grund können vor allem neue Datensätze äußerst effizient eingefügt wer-
den, da diese lediglich in den letzten Block geschrieben werden müssen.
2 Relationale Datenbanken
36
Allerdings ist das anschließende Auffinden eines Datensatzes vergleichsweise teuer,
da die gespeicherten Daten Block für Block nach Treffern abgesucht werden müssen
(lineare Suche). Bei b Blöcken müssen somit im Durchschnitt b/2 Blöcke in den Haupt-
speicher gelesen werden. Deshalb werden Heap-Dateien häufig mit sekundären Zu-
griffspfaden kombiniert [52, S.162].
Es wird logisches Löschen mithilfe von Löschmarkierungen oder physisches Löschen
durch Überschreiben mit Blanks unterstützt. In beiden Fällen wird der alte Speicher-
platz nicht mehr zur Verfügung gestellt, weshalb nach einiger Zeit eine Reorganisation
notwendig wird. Heap ist daher für kleine Tabellen geeignet, die idealerweise in einen
Block passen. Scans auf großen Tabellen sind dagegen äußerst ineffizient [55, S.470].
ISAM
Bei der ISAM-Speicherstruktur (Index Sequential Access Method) werden die Daten
über eine Indexspalte sortiert in den Blöcken gespeichert. Darüber hinaus wird ein
dünnbesetzter Index angelegt, der jeweils den größten Schlüsselwert eines Blocks als
dessen Repräsentant sowie die zugehörige logische Adresse des Blocks speichert (Ab-
bildung 2.9).
Abbildung 2.9: Aufbau einer ISAM-Speicherstruktur mit Überlaufseite
Beim Einfügen neuer Datensätze wird über den Index die entsprechende Blockadresse
ermittelt und anschließend der Datensatz an der richtigen Stelle innerhalb des Blocks
eingetragen. Wenn der Block bereits gefüllt ist, wird der Datensatz in einer Über-
laufseite (Überlaufblock) gespeichert. Leseoperationen gestalten sich bei wenigen
Überlaufseiten sehr effizient und benötigen im Idealfall genau zwei Operationen: Eine
Leseoperation auf dem Index und eine innerhalb eines Blocks. „Bei Überlaufseiten sind
2.3 Interne Ebene
37
es entsprechend mehr Zugriffe, die die Antwortzeit schnell spürbar verlangsamen kön-
nen“ [55, S.472]. Bei ISAM-Speicherstrukturen werden Datensätze physisch gelöscht
und der Speicherplatz wieder für neue Datensätze zur Verfügung gestellt.
Da bei häufigen Datenänderungen schnell Überlaufseiten entstehen, die „eine regel-
mäßige Dateireorganisation“ nach sich ziehen, ist ISAM eher für „große, statische Da-
tenbestände gut geeignet“. „Gegenüber Heap-Speicherung ist bei Anfragen ein drama-
tischer Zeitgewinn zu verzeichnen, […] beim Schreiben fällt der Mehraufwand meist
nicht ins Gewicht“ [55, S.473]. ISAM-Indizes können bei großen Datenmengen auch
mehrstufig gestaltet werden und erhalten dann eine Struktur, die den im Folgenden
vorgestellten Bäumen ähnelt.
B*-Bäume
B*-Bäume (auch B+-Bäume genannt) stellen eine Erweiterung von B-Bäumen und
ISAM dar, bei denen die eigentlichen Daten ausschließlich in linear geordneten Blatt-
knoten des Baumes gespeichert werden. Die Knoten entsprechen einzelnen Blöcken
und enthalten ausschließlich Schlüsselwerte. Innere Knoten verweisen mit einem lin-
ken Zeiger auf nachfolgende Knoten, die kleinere Schlüsselwerte verwalten und mit
einem rechten Zeiger auf Knoten mit gleichen oder größeren Schlüsselwerten (Abbil-
dung 2.10).
Abbildung 2.10: Aufbau eines B*-Baums mit der Höhe 3
Bäume sind stets balanciert, weshalb sich alle Blätter auf einer gleichen Ebene befin-
den und sich so für alle Datensätze ein gleicher Suchaufwand ergibt. Die Wurzel eines
B*-Baums enthält immer mindestens einen Wert, innere Knoten sind mindestens im-
mer bis zur Hälfte gefüllt.
2 Relationale Datenbanken
38
B*-Bäume bieten eine sehr effiziente Suche in großen Datenbeständen. Ausgehend von
der Wurzel entspricht die Anzahl der benötigten Operationen immer der Höhe h des
Baumes. Beim Schreiben wird zunächst der Zielblock gesucht und anschließend der
Wert in die sortierte Liste eingetragen. Im Fall eines Überlaufs wird der Block gesplit-
tet und der darüber liegende Indexknoten um einen Verweis ergänzt. Es ergeben sich
infolgedessen minimal eine und maximal 2h+1 Operationen. Beim Löschen kann es
zum sogenannten Unterlauf kommen, der eine Zusammenlegung der Knoten zur Folge
hat. Hier liegen die Kosten bei minimal 1 und maximal h+1 [55, S.479].
Durch Splitten, Ausgleichen und Zusammenführen von Knoten bei Einfüge- und
Löschoperationen ergibt sich ein „relativ hoher Verwaltungsaufwand“ [55, S.479]. Die-
ser ist jedoch akzeptabel, solange es sich dabei nicht um Massendatenverarbeitung
handelt. Da sich ihre Struktur dynamisch anpassen lässt und infolgedessen kostspie-
lige Reorganisationen vermieden werden können, sind B*-Bäume für veränderliche
Datenbestände geeignet.
Hashing
„Die Idee des Hash-Verfahrens besteht darin, die Schlüsselwerte eines Datensatzes
mithilfe eines Algorithmus direkt in die physische Adresse umzurechnen und so eine
sehr gute Performanz beim Lesen zu erreichen“ [55, S.480]. Die am häufigsten verwen-
dete Hash-Funktion ist die mathematische Funktion Modulo n. Hierfür wird einem
Schlüssel zunächst ein ganzzahliger Wert zugeordnet, dieser wird anschließend durch
eine große Zahl n geteilt und anhand des entstehenden Rests kann schließlich ein zu-
gehöriger Block ermittelt werden [55, S.480]:
h(a) := a MOD n.
Beim Schreiben weist die Hash-Funktion den errechneten Block zu. Falls dieser be-
reits voll ist, wird eine Überlaufseite angelegt, welche dann bei einer Suche linear
durchlaufen werden muss. Ebenso effizient gestalten sich Löschoperationen, bei denen
der Wert physisch entfernt wird. Der Nachteil von Hashing liegt in der nicht vorhan-
denen Unterstützung von Bereichsanfragen.
Zugriffskosten
Tabelle 2.4 zeigt eine grobe Kostenabschätzung der wichtigsten Zugriffsoperationen
für die verschiedenen Speicherstrukturen. Es wird hierbei ein Datenbestand N von 108
Datensätzen und eine Clusterbildung von 100 Datensätzen pro Seite angenommen.
Während sich die Kosten für Einfüge- und Löschoperationen bei B*-Bäumen ange-
sichts möglicher Ausbalancierungen minimal erhöhen können, verursachen häufige
Änderungen bei ISAM teure Reorganisationen des Index. Die Werte der Hash-Funk-
tion berücksichtigen keine Überlaufseiten.
2.3 Interne Ebene
39
Operation
Direkter Zugriff
Sequenzielle
Verarbeitung
Einfügen / Löschen
HEAP
O(N/2) ≈ 5*107
O(N) ≈ 108
O(1) ≈ 2
ISAM / B*-Baum
O(logkN) ≈ 4
O(N/100) ≈ 106
O(1) ≥ 5
HASH
O(1) ≈ 1
O(N) ≈ 108
O(1) ≈ 2
Tabelle 2.4: Zugriffskosten der wichtigsten Operationen [76, S.225]
Hashverfahren bieten demnach den schnellsten Direktzugriff, unterstützen jedoch an-
sonst keine Suchzugriffe. Aus diesem Grund haben sich B*-Bäume „wegen ihren aus-
gewogenen Kosten für alle Operationen als Standardstruktur [für relationale Daten-
banken] durchgesetzt“ [76, S.226]. Sekundäre Zugriffspfade können den Zugriff über
Nicht-Schlüsselattribute deutlich beschleunigen. Von einem übermäßigen Gebrauch
von Indizes sollte jedoch Abstand genommen werden, da die Einführung und Wartung
eines Index automatisch mit einem Mehraufwand verbunden ist, der bei Einfüge- und
Löschoperationen sowie bei Änderungen auf indizierten Attributen zu spürbaren Per-
formanzverlusten führen kann [52, S.596].
2.3.2 Transaktionen und konkurrierende Zugriffe
„Eine Transaktion ist eine logische Verarbeitungseinheit auf der Datenbank, die eine
oder mehrere Datenbankoperationen – Einfügen, Löschen, Modifizieren oder Suchen
– beinhaltet“ [52, S.677]. Dieses Prinzip kann anhand des bereits aus Abbildung 2.3
bekannten Datenmodells eines Onlineshops veranschaulicht werden.
Abbildung 2.11: Konzeptuelles Modell der Entitäten Warenkorb und WarenkorbArtikel
In Abbildung 2.11 sind die Entitäten Warenkorb und WarenkorbArtikel abgebildet. Ein
Warenkorb wird über einen Primärschlüssel identifiziert und besitzt eine Summe. Ein
Warenkorb kann eine beliebige Anzahl an Artikeln enthalten. Diese besitzen neben
der Artikelnummer eine Menge und einen Preis. Wird ein Artikel zu einem Warenkorb
hinzugefügt, muss die Relation WarenkorbArtikel um einen Datensatz erweitert und
das Attribut Summe in der Relation Warenkorb aktualisiert werden. Um diese einzel-
2 Relationale Datenbanken
40
nen Operationen fehlerfrei und ohne unerwünschte Einflüsse anderer zeitgleich statt-
findender Operationen ausführen zu können, werden diese zu einer Transaktion
zusammengefasst.
Abbildung 2.12: Aktualisierung des Warenkorbs im Rahmen einer Transaktion
Eine mögliche Transaktion zur Aktualisierung des Warenkorbs ist in Abbildung 2.12
dargestellt. Eine Transaktion startet mit dem Befehl Begin of Transaction (BOT).
Daraufhin werden die einzelnen Operationen definiert, die innerhalb einer Transak-
tion ausgeführt werden sollen. In diesem Fall wird zunächst der Artikel in die Relation
WarenkorbArtikel eingefügt. Anschließend wird die Summe aus der Relation Waren-
korb ausgelesen, um den entsprechenden Wert erhöht und wieder in die Relation Wa-
renkorb zurückgeschrieben. Eine Transaktion endet mit dem Befehl End of Transac-
tion (EOT).
Transaktionen weisen gewisse Eigenschaften auf, die unter dem Akronym ACID zu-
sammengefasst werden:
Atomarität (Atomicity): Eine Transaktion wird vollständig oder überhaupt nicht
ausgeführt („Alles-oder-Nichts-Prinzip“). Tritt während der Ausführung einer Trans-
aktion ein Fehler auf, werden alle bisher durchgeführten Änderungen dieser Transak-
tion zurückgesetzt [76, S.393].
Konsistenz (Consistency): Eine Transaktion überführt eine Datenbank von einem
konsistenten Zustand in einen anderen konsistenten Zustand, das heißt, vor und nach
der Ausführung einer Transaktion müssen die im Schema definierten Integritätsbe-
dingungen erfüllt sein. „Änderungen, welche zu einer Verletzung der Integritätsbedin-
gungen führen, werden abgewiesen, das heißt, sie führen zum Zurücksetzen der Trans-
aktion“ [76, S.393].
Isolation (Isolation): Parallel ausgeführte Transaktionen laufen isoliert voneinan-
der ab und beeinflussen sich nicht gegenseitig, das heißt, „alle anderen parallel ausge-
führten Transaktionen beziehungsweise deren Effekte dürfen [für eine Transaktion]
nicht sichtbar sein“ [94, S.289].
Dauerhaftigkeit (Durability): Die von einer Transaktion durchgeführten Änderun-
gen werden dauerhaft (persistent) gespeichert und sind gegenüber zukünftigen Soft-
und Hardwarefehlern gesichert.
Begin of Transaction
//Schreibe Artikel in WarenkorbArtikel
//Lies Summe aus Warenkorb
//Schreibe aktualisierte Summe in Warenkorb
End of Transaction
2.3 Interne Ebene
41
Aus diesen vier Eigenschaften lassen sich zwei grundlegende Anforderungen an die
Transaktionsverwaltung eines Datenbanksystems ableiten. Einerseits müssen konsis-
tente Datenbankzustände nach Fehlern wiederhergestellt werden können (Fehlerbe-
handlung) und andererseits müssen Transaktionen im Mehrbenutzerbetrieb isoliert
voneinander ablaufen können (Nebenläufigkeitskontrolle) [94, S.289]. Entsprechend
dieser Anforderungen besteht eine Transaktionsverwaltung aus den Komponenten
Recovery (Wiederherstellung) und Synchronisation.
Recovery
In einem Datenbanksystem können verschiedene Fehler zu einem Datenverlust füh-
ren. Man unterscheidet lokale Fehler einer Transaktion, Fehler mit Hauptspeicher-
verlust und Fehler mit Hintergrundspeicherverlust. Je nach aufgetretenem Fehler
müssen von der Recovery-Komponente der Transaktionsverwaltung unterschiedliche
Maßnahmen eingeleitet werden, um den jüngsten konsistenten Datenbankzustand
wiederherstellen zu können [94, S.293]:
Lokale Fehler einer Transaktion: Die am häufigsten auftretenden Fehler sind so-
genannte lokale Fehler, bei denen Transaktionen vom Datenbanksystem oder vom Be-
nutzer zurückgesetzt werden. In einem solchen Fehlerfall werden im Rahmen eines
„lokalen Undo“ sämtliche Operationen widerrufen, die innerhalb der annullierten
Transaktion bereits ausgeführt wurden.
Fehler mit Hauptspeicherverlust: Die zweite Fehlerklasse bilden Fehler mit
Hauptspeicherverlust, hervorgerufen beispielsweise durch Stromausfälle, bei denen
alle Daten verloren gehen, die noch nicht im Hintergrundspeicher gesichert wurden.
Im Rahmen des Recovery wird in diesem Fall zunächst ein „globales Undo“ durchge-
führt, um alle nicht erfolgreich abgeschlossenen Transaktionen zurückzusetzen und
anschließend ein „Redo“ veranlasst, um die erfolgreichen, aber noch nicht materiali-
sierten Transaktionen erneut durchzuführen. Die hierzu notwendigen Informationen
befinden sich in einer im Hintergrundspeicher befindlichen Logdatei (Write Ahead Log
– WAL), die vor und nach dem Durchführen einer Transaktion mit Wiederherstel-
lungsinformationen beschrieben wird (Abbildung 2.13).
Abbildung 2.13: Prinzip des Write Ahead Loggings
2 Relationale Datenbanken
42
Das Intervall, in der diese Log-Datei persistiert wird, hängt vom eingesetzten Daten-
banksystem ab. Das von MySQL verwendete Speichersubsystem InnoDB sichert diese
Datei einmal pro Sekunde [128, S.1210].
Fehler mit Hintergrundspeicherverlust: Fehler der dritten und am seltensten auf-
tretenden Fehlerklasse führen zu einem Verlust des Hintergrundspeichers durch
Hardwarefehler oder Zerstörungen. Für eine Behebung solcher Fehler ist „eine Archiv-
kopie der materialisierten Datenbasis und ein Log-Archiv mit allen seit Anlegen dieser
Datenbasis-Archivkopie vollzogenen Änderungen notwendig“ [94, S.295]. Hierfür bie-
tet sich die später behandelte Replikation an.
Synchronisation
„Eine zentrale Problemstellung beim Mehrbenutzerbetrieb ist der Umgang mit kon-
kurrierenden Zugriffen verschiedener Benutzer auf das gleiche Objekt, zum Beispiel
auf eine Tabelle oder einen Datensatz“ [55, S.443]. Infolge eines unkontrollierten Zu-
griffs können verschiedene Probleme (Anomalien) auftreten:
Lost Update: „Dieses Problem entsteht, wenn sich die Operationen zweier Transak-
tionen, die auf die gleichen Datenobjekte zugreifen, auf eine Weise zeitlich überschnei-
den, sodass sich ein falscher Wert eines Datenbankobjekts ergibt“ [52, S.679].
Dirty Read: „Dieses Problem