Vergleich und Evaluation zwischen modernen und traditionellen Datenbankkonzepten unter den Gesichtspunkten Skalierung, Abfragemöglichkeit und Konsistenz
©2010
Bachelorarbeit
78 Seiten
Zusammenfassung
Inhaltsangabe:Einleitung:
1. Einleitung:
Zehntausende Web-Services verwenden relationale Datenbanken, um Daten zu speichern und auszulesen. Im Vergleich zu modernen Konzepten können relationale Datenbanken als wichtigster Stellvertreter für traditionelle Technologien bezeichnet werden. Wenn man als Entwickler zu Seiten wie Google.com, Facebook.com, Amazon.com, Digg.com, Ebay.com, Yahoo.com, Twitter.com, oder Dawanda.com surft, wird meist angenommen, dass eine verteilte relationale Datenbank verwendet wird. Die Annahme ist zu 50% richtig, jedoch ist die Datenhaltung meist nicht relational. Diese Großunternehmen verwalten mehrere hundert Gigabytes, bis hin zu 100.000 Gigabyte an Daten, und mussten in den letzten sechs Jahren Lösungen finden, um erfolgreich diese riesigen Datenmengen zu beherrschen. Google erfand vor ca. sieben Jahren ein Verfahren, um Datenmengen im Petabytebereich zu beherrschen. Facebook entwickelte selbst eine Datenbanktechnologie, um die Posteingänge von Benutzern verfügbar zu machen, Twitter.com adaptiert diese Technologie für andere Zwecke. Amazon.com entwickelte Dynamo, um Hochverfügbarkeit für deren weltgrößte E-Commerce Plattform zu schaffen. Diese und andere Eigenentwicklungen entstanden aus der Notwendigkeit heraus, riesige Datenmengen bzw. Datenbanken hoch verfügbar, konsistent und skalierbar zu machen.
1.1. Motivation:
Seit den letzten drei Jahren sind alternative Open-Source-Implementierungen dieser Entwicklungen entstanden. Die Veröffentlichung der Konzepte und Technologien führten zu einer ganzen Bewegung namens NoSQL. Sind diese Konzepte vorteilhafter, um eine bessere und für Entwickler einfachere Skalierung, Abfragemöglichkeit und Datenkonsistenz in einem hochverfügbaren Datenbanksystem, zu gewährleisten? Wie werden komplexe Abfragen in modernen und traditionellen verteilten Systemen gemacht und wie werden diese ausgeführt? Speziell stellt sich die Frage, ob das MapReduce Verfahren ein vollständiger Ersatz für SQL ist. Für welche Einsatzzwecke sind beide besonders gut geeignet und für welche weniger?
1.2. Zielsetzung:
Ausgewählte Konzepte moderner, verteilter Datenbanksysteme sind zentrale Bestandteile dieser Arbeit. Dazu werden die Eigenschaften Verfügbarkeit, Konsistenz und Skalierbarkeit in den verteilten Systemen ausführlicher beschrieben, um zu analysieren, ob gegenüber relationalen Datenbanken Vorteile und Nachteile dieser Eigenschaften existieren. Ergebnisse dieser Aufgabenstellung sollen Chancen […]
1. Einleitung:
Zehntausende Web-Services verwenden relationale Datenbanken, um Daten zu speichern und auszulesen. Im Vergleich zu modernen Konzepten können relationale Datenbanken als wichtigster Stellvertreter für traditionelle Technologien bezeichnet werden. Wenn man als Entwickler zu Seiten wie Google.com, Facebook.com, Amazon.com, Digg.com, Ebay.com, Yahoo.com, Twitter.com, oder Dawanda.com surft, wird meist angenommen, dass eine verteilte relationale Datenbank verwendet wird. Die Annahme ist zu 50% richtig, jedoch ist die Datenhaltung meist nicht relational. Diese Großunternehmen verwalten mehrere hundert Gigabytes, bis hin zu 100.000 Gigabyte an Daten, und mussten in den letzten sechs Jahren Lösungen finden, um erfolgreich diese riesigen Datenmengen zu beherrschen. Google erfand vor ca. sieben Jahren ein Verfahren, um Datenmengen im Petabytebereich zu beherrschen. Facebook entwickelte selbst eine Datenbanktechnologie, um die Posteingänge von Benutzern verfügbar zu machen, Twitter.com adaptiert diese Technologie für andere Zwecke. Amazon.com entwickelte Dynamo, um Hochverfügbarkeit für deren weltgrößte E-Commerce Plattform zu schaffen. Diese und andere Eigenentwicklungen entstanden aus der Notwendigkeit heraus, riesige Datenmengen bzw. Datenbanken hoch verfügbar, konsistent und skalierbar zu machen.
1.1. Motivation:
Seit den letzten drei Jahren sind alternative Open-Source-Implementierungen dieser Entwicklungen entstanden. Die Veröffentlichung der Konzepte und Technologien führten zu einer ganzen Bewegung namens NoSQL. Sind diese Konzepte vorteilhafter, um eine bessere und für Entwickler einfachere Skalierung, Abfragemöglichkeit und Datenkonsistenz in einem hochverfügbaren Datenbanksystem, zu gewährleisten? Wie werden komplexe Abfragen in modernen und traditionellen verteilten Systemen gemacht und wie werden diese ausgeführt? Speziell stellt sich die Frage, ob das MapReduce Verfahren ein vollständiger Ersatz für SQL ist. Für welche Einsatzzwecke sind beide besonders gut geeignet und für welche weniger?
1.2. Zielsetzung:
Ausgewählte Konzepte moderner, verteilter Datenbanksysteme sind zentrale Bestandteile dieser Arbeit. Dazu werden die Eigenschaften Verfügbarkeit, Konsistenz und Skalierbarkeit in den verteilten Systemen ausführlicher beschrieben, um zu analysieren, ob gegenüber relationalen Datenbanken Vorteile und Nachteile dieser Eigenschaften existieren. Ergebnisse dieser Aufgabenstellung sollen Chancen […]
Leseprobe
Inhaltsverzeichnis
Nils Petersohn
Vergleich und Evaluation zwischen modernen und traditionellen Datenbankkonzepten
unter den Gesichtspunkten Skalierung, Abfragemöglichkeit und Konsistenz
ISBN: 978-3-8428-0608-5
Herstellung: Diplomica® Verlag GmbH, Hamburg, 2010
Zugl. Fachhochschule Brandenburg, Brandenburg, Deutschland, Bachelorarbeit, 2010
Dieses Werk ist urheberrechtlich geschützt. Die dadurch begründeten Rechte,
insbesondere die der Übersetzung, des Nachdrucks, des Vortrags, der Entnahme von
Abbildungen und Tabellen, der Funksendung, der Mikroverfilmung oder der
Vervielfältigung auf anderen Wegen und der Speicherung in Datenverarbeitungsanlagen,
bleiben, auch bei nur auszugsweiser Verwertung, vorbehalten. Eine Vervielfältigung
dieses Werkes oder von Teilen dieses Werkes ist auch im Einzelfall nur in den Grenzen
der gesetzlichen Bestimmungen des Urheberrechtsgesetzes der Bundesrepublik
Deutschland in der jeweils geltenden Fassung zulässig. Sie ist grundsätzlich
vergütungspflichtig. Zuwiderhandlungen unterliegen den Strafbestimmungen des
Urheberrechtes.
Die Wiedergabe von Gebrauchsnamen, Handelsnamen, Warenbezeichnungen usw. in
diesem Werk berechtigt auch ohne besondere Kennzeichnung nicht zu der Annahme,
dass solche Namen im Sinne der Warenzeichen- und Markenschutz-Gesetzgebung als frei
zu betrachten wären und daher von jedermann benutzt werden dürften.
Die Informationen in diesem Werk wurden mit Sorgfalt erarbeitet. Dennoch können
Fehler nicht vollständig ausgeschlossen werden und der Verlag, die Autoren oder
Übersetzer übernehmen keine juristische Verantwortung oder irgendeine Haftung für evtl.
verbliebene fehlerhafte Angaben und deren Folgen.
© Diplomica Verlag GmbH
http://www.diplomica.de, Hamburg 2010
Inhaltsverzeichnis
1. Einleitung
1
1.1. Motivation
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1
1.2. Zielsetzung
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
2
1.3. Überblick . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
2
2. Konzepte moderner Datenbanken
4
2.1. Consistent Hashing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
5
2.2. Brewer's Theorem und "letztendliche Konsistenz" . . . . . . . . . . . . . . .
8
2.3. Versionierung der Daten . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
13
2.4. MapReduce . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
2.4.1. Map . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
16
2.4.2. Reduce
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
16
2.4.3. Abarbeitungsübersicht . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
2.5. Zusammenfassung
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
19
3. Riak - ein Key-Value-Store
20
3.1. Key-Value-Store
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
20
3.2. Riak . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
20
3.3. Das konsistente Hashverfahren und die CAP-Parameter . . . . . . . . . . . . 21
3.4. eventually consistent . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
26
3.5. MapReduce . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
28
3.6. Zusammenfassung
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
30
4. Relationale Datenbanken
31
4.1. Skalierung und Partitionierung . . . . . . . . . . . . . . . . . . . . . . . . . . 31
4.1.1. vertikal . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
32
4.1.2. horizontal . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
32
4.1.3. funktionale Partitionierung . . . . . . . . . . . . . . . . . . . . . . .
32
4.1.4. Sharding
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
33
4.1.5. Abfragen über mehrere Shards . . . . . . . . . . . . . . . . . . . . .
33
4.2. Zusammenfassung
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
5. Gegenüberstellungen
35
5.1. Abfragedynamik vs. Daten-Zuwachsrate . . . . . . . . . . . . . . . . . . . .
35
5.1.1. geringe Abfragedynamik . . . . . . . . . . . . . . . . . . . . . . . . .
35
5.1.2. mittlere Abfragedynamik
. . . . . . . . . . . . . . . . . . . . . . . .
36
5.1.3. mittlere bis hohe Datendynamik und vorhersehbare Daten-Zuwachsrate 36
5.1.4. hohe Abfragedynamik und hohe Daten-Zuwachsrate . . . . . . . . . . 37
iii
5.1.5. Zusammenfassung und Bewertung . . . . . . . . . . . . . . . . . . . . 37
5.2. Skalierung und Konsistenz . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
5.3. Abfragemöglichkeiten . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
5.3.1. Anwendungsfälle für MapReduce . . . . . . . . . . . . . . . . . . . .
43
5.3.2. Anwendungsfälle für SQL . . . . . . . . . . . . . . . . . . . . . . . . . 47
5.4. Abfragen: Riak und MySql
. . . . . . . . . . . . . . . . . . . . . . . . . . .
48
5.4.1. Stored Procedures . . . . . . . . . . . . . . . . . . . . . . . . . . . .
48
5.4.2. Von MySQL zu Riak . . . . . . . . . . . . . . . . . . . . . . . . . . .
50
5.4.3. MapReduce . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
52
5.4.4. Bewertung
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
55
6. Zusammenfassung
56
Literaturverzeichnis
58
A. Anhang
63
Anhang
63
A.1. MySQL Stored Procedure - Verfügbarkeitsabfragen im Hotel System mit
Stored Procedures
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
63
A.2. Riak MapReduce - Verfügbarkeitsabfragen im Hotel System mit MapReduce
64
A.3. Amazon EC2 Riak Installation Script und Testfall . . . . . . . . . . . . . .
66
A.4. Amazon EC2 Riak Join Script
. . . . . . . . . . . . . . . . . . . . . . . . . . 71
iv
1. Einleitung
Zehntausende Web-Services verwenden relationale Datenbanken, um Daten zu speichern
und auszulesen. Im Vergleich zu modernen Konzepten können relationale Datenbanken als
wichtigster Stellvertreter für "traditionelle Technologien" bezeichnet werden. Wenn man als
Entwickler zu Seiten wie Google.com, Facebook.com, Amazon.com, Digg.com, Ebay.com,
Yahoo.com, Twitter.com, oder Dawanda.com surft, wird meist angenommen, dass eine
verteilte relationale Datenbank verwendet wird. Die Annahme ist zu 50% richtig, jedoch ist
die Datenhaltung meist nicht relational. Diese Großunternehmen verwalten mehrere hundert
Gigabytes, bis hin zu 100.000 Gigabyte an Daten, und mussten in den letzten sechs Jahren
Lösungen finden, um erfolgreich diese riesigen Datenmengen zu beherrschen. Google erfand
vor ca. sieben Jahren ein Verfahren, um Datenmengen im Petabytebereich zu beherrschen.
Facebook entwickelte selbst eine Datenbanktechnologie, um die Posteingänge von Benutzern
verfügbar zu machen, Twitter.com adaptiert diese Technologie für andere Zwecke (vgl.
[Lai10]). Amazon.com entwickelte "Dynamo", um Hochverfügbarkeit für deren weltgrößte
E-Commerce Plattform zu schaffen. Diese und andere Eigenentwicklungen entstanden aus der
Notwendigkeit heraus, riesige Datenmengen bzw. Datenbanken hoch verfügbar, konsistent
und skalierbar zu machen.
1.1. Motivation
Seit den letzten drei Jahren sind alternative "Open-Source-Implementierungen" dieser
Entwicklungen entstanden. Die Veröffentlichung der Konzepte und Technologien führten zu
einer ganzen Bewegung namens "NoSQL". Sind diese Konzepte vorteilhafter, um eine bessere
und für Entwickler einfachere Skalierung, Abfragemöglichkeit und Datenkonsistenz in einem
hochverfügbaren Datenbanksystem, zu gewährleisten? Wie werden komplexe Abfragen in
modernen und traditionellen verteilten Systemen gemacht und wie werden diese ausgeführt?
Speziell stellt sich die Frage, ob das MapReduce Verfahren ein vollständiger Ersatz für SQL
ist. Für welche Einsatzzwecke sind beide besonders gut geeignet und für welche weniger?
1
1. Einleitung
1.2. Zielsetzung
Ausgewählte Konzepte moderner, verteilter Datenbanksysteme sind zentrale Bestandteile
dieser Arbeit. Dazu werden die Eigenschaften Verfügbarkeit, Konsistenz und Skalierbarkeit
in den verteilten Systemen ausführlicher beschrieben, um zu analysieren, ob gegenüber
relationalen Datenbanken Vorteile und Nachteile dieser Eigenschaften existieren. Ergebnisse
dieser Aufgabenstellung sollen Chancen und Risiken von modernen Datenbanken aufdecken.
Key-Value-Stores sind die einfachsten Vertreter moderner Datenbanken. "Riak" wird in
dieser Arbeit als Implementierung moderner Konzepte benutzt. "MySQL" soll als Vertreter
für relationale Datenbanken verwendet werden da dieser Vertreter eine weit verbreitete
Open-Source-Implementierung von relationalen Datenbanken ist. Andere Datenbankkon-
zepte/Datenbanken werden in dieser Arbeit nicht behandelt. Dazu zählen unter anderem
objektorientierte, objektrelationale, hierarchische, spaltenorientierte und graphenorientierte
Datenbankkformen, sowie Repräsentanten von relationalen Datenbanken, wie "db2", "Sybase"
oder "Oracle", da diese nicht Open-Source sind.
1.3. Überblick
Das konsistente Hashfunktionsverfahren wird zuerst kurz erläutert, um theoretische Grund-
lagen für die Implementierung moderner und traditioneller Skalierungsmethoden zu legen.
Danach werden, im Kontext moderner Datenbanktechnologien, wichtige theoretische Kon-
zepte zur Skalierung erläutert. Dazu werden die drei wichtigsten Eigenschaften verteilter
Systeme definiert und in Zusammenhang gebracht (Verfügbarkeit, Konsistenz und Parti-
tionstoleranz). Dementsprechend wird das Prinzip "letztendliche Konsistenz" vorgestellt,
welches eine zentrale Rolle bei modernen verteilten Systemen darstellt. Weiterhin wird das
MapReduce-Verfahren konzeptionell vorgestellt. Es wird aus zwei Perspektiven betrachtet:
Filterung von Daten durch benutzerdefinierte Funktionen anhand eines Beispiels und in
diesem Zusammenhang die Ausführung des Verfahrens in verteilten Systemen. Implementie-
rungen dieser theoretischen Ansätze werden in diesem Kapitel aufgelistet. Eine detaillierte
Beschreibung von "Key-Value-Stores" (KVS) wird im nächsten Kapitel bereitgestellt. KVS
sind die einfachste Form von modernen Datenbanken, an denen sich die grundlegenden
Konzepte abstrakt beschreiben lassen. "Riak" ist ein wichtiger Vertreter für moderne Daten-
banken und KVS. Die theoretischen Grundlagen der drei zentralen Eigenschaften verteilter
System werden an dieser direkten Implementierung gefestigt und erweitert. Dem folgt eine
kurze Vorstellung von relationalen Datenbanken. Dabei wird ausschließlich auf Möglichkeiten
2
1. Einleitung
zur Skalierung eingegangen. Im letzten Kapitel werden zuerst beide Datenbanktechnologien
hinsichtlich der Skalierung, Konsistenz, Verfügbarkeit und Komplexität verglichen. Weiterhin
findet ein Vergleich zwischen MapReduce und SQL bzw. "benutzerdefinierten Funktionen"
anhand von Einsatzmöglichkeiten, Stabilität und Komplexität statt. Der Vergleich von MyS-
QL und Riak erfolgt durch eine Analyse der Abfragemöglichkeiten mittels Stored Procedures
und MapReduce anhand mehrerer Beispiele. Hierbei sollen die zentralen Fragestellungen
beantwortet werden. Abschließend werden die Ergebnisse zusammengefasst und bewertet.
3
2. Konzepte moderner Datenbanken
Festplatten habe eine Kapazitätsgrenze. Wenn z.B. zehn Festplatten mit ca. 2 Terabyte pro
Stück mit Datenbankinhalten belegt sind, kann ein einzelner Prozessor diese Mengen nicht
mehr bewältigen. Selbst mehrere Kerne in der CPU haben es schwer und leistungsstarke
Prozessoren sind vergleichsweise teurer als diejenigen, die man in jedem Discounter kaufen
kann. Ein Intel-Extrem Prozessor kostet zum Beispiel so viel wie ein ganzer Desktopcomputer
mit Bildschirm, Blue-Ray Laufwerk usw.. Abgesehen davon ist es ab einem bestimmten
Punkt auch nicht mehr möglich, in einen einzelnen Computer mehr als 20 Festplatten zu
bauen. Das ist praktisch unrealistisch. Eine Lösung für dieses Problem, ist ein verteiltes
Netzwerk mit vielen preiswerten Maschinen und Prozessoren. Wie verhält sich ein verteiltes
Datenbanksystem? Die Annahme, dass die Datenbank sich intern bei einem Netz genau
so verhält wie in einer einzelnen Maschine ist falsch. Verteilten Datenbanksysteme haben
Eigenheiten, die man sich vor Beginn klar machen muss. Weitere Fragen stellen sich bei
der Verwendung einer verteilten Datenbank: Wie kann eine Anfrage am besten auf alle
Maschinen gleich verteilt werden? Welche Daten werden auf welchen Rechner geschrieben?
Was passiert nachdem z.B. ein Computer oder das Netzwerk zwischen einigen Maschinen
ausfällt, müssen dann alle Daten neu aufgeteilt werden? Muss der Entwickler sich darum
kümmern?
Die ursprünglichen Konzepte relationaler Datenbanken beschäftigen sich weniger mit dem
Umgang einer verteilten Datenbank, sondern konzentrieren sich auf die Struktur der Daten
und kombinatorischer Abfragen derer. Moderne Datenbankkonzepte fokussieren im Gegensatz
dazu weniger die Struktur, sondern richten den Fokus auf Effizienz, Fehlertoleranz und
Konsistenz in verteilten Systemen.
Die wichtigsten Konzepte moderner Datenbanken, werden in diesem Kapitel beschrieben.
Diese Konzepte sind ausschlaggebend, um ein Verständnis von modernen Datenbanktechno-
logien zu entwickeln. Die weit verbreiteten relationalen Datenbanken basieren nur zum Teil
auf den folgenden Konzepten.
Skalierung, Leistung (Performance), Verfügbarkeit und Fehlertoleranz sind wichtige Begriffe
4
2. Konzepte moderner Datenbanken
dieser Arbeit:
· Performance
"Leistung ist das Vermögen eines Datenverarbeitungssystems Aufgaben (Antwortzeit,
Datendurchsatz) auf bestimmte Weise (schnell, gleichzeitig, ununterbrochen usw.)
auszuführen." (vgl. [unk10f])
· Skalierung
"In der Informatik und Softwaretechnik bezeichnet Skalierbarkeit das Verhalten von
Programmen oder Algorithmen bezüglich des Ressourcenbedarfs bei wachsenden Ein-
gabemengen." (vgl. [unk10g])
· Verfügbarkeit
"Verfügbarkeit ist ein prozentualer Anteil der Antwortzeit, bei welchem die Datenbank
auf Anfragen eine Antwort liefert. Dies wird meist in "neuen" gemessen. "Fünf Neu-
nen" bedeutet, dass die Datenbank zu 99,999% Verfügbar ist. Das Entspricht einem
Ausfallzeitrahmen von ca. 5 Minuten pro Jahr." (vgl. S. 410 [SZT
+
08])
· Fehlertoleranz
"Die Fähigkeit einer Datenbank mit Fehlern umzugehen, diesen vorzubeugen und diese
von der Applikation zu verbergen ohne die Verfügbarkeit einzuschränken." (vgl. S. 410
[SZT
+
08])
· Konsistenz
"Daten sind konsistent, wenn Widerspruchsfreiheit innerhalb einer Datenbank gewähr-
leistet ist" (vgl. [unk10b]) und alle Daten abrufbar sind.
2.1. Consistent Hashing
Um auf die Frage "Wie werden die Daten auf die Computer verteilt?" eine Antwort zu geben,
wird in diesem Kapitel das konsistente Hashverfahren vorgestellt. Eine kurze Überlegung
über die Antwort dieser Frage, bringt den logischen Schluss hervor, alle Daten gleichmäßig
zu verteilen. Eine Datenmenge x wird durch die Anzahl der verfügbaren Rechenmaschinen
geteilt und das Ergebnis ist die Anzahl der Daten, die jeder Rechner zur Speicherung
erhält. Bei 10 Computern speichert jeder ein Zehntel der Datenmenge. Was passiert aber,
wenn zur gleichen Zeit zwei Computer ausfallen? Angenommen die Daten sind noch auf
den anderen Maschinen für eine Wiederherstellung gespeichert. Angenommen die defekten
Maschinen sind so schwer beschädigt, dass sie nicht binnen Wochenfrist ersetzt werden
können. Der Vorschlag, die Daten auf Knoten im Netz gleich verteilt zu speichern, ist
5
2. Konzepte moderner Datenbanken
bei einer Initialbespielung eine Möglichkeit. Die Rechnung geht dann nicht auf, wenn sich
während der Laufzeit die Anzahl der Knoten verändert, in diesem Beispiel zum negativen.
Angenommen 10 Rechner reichen nicht mehr, um die riesigen Datenmengen zu bewältigen,
und drei neue Rechner werden gekauft, dann bekommt jeder Rechner 1/13 der Datenmenge.
Bei einer Neuverteilung (Ausbalancierung) der Daten, würde jeder Rechner neue Daten von
anderen Rechner im Netz erhalten und auch wieder an andere Rechner abgeben, was die
Verfügbarkeit einschränken würde. Das Prinzip des konsistenten Hashverfahrens erlaubt es
dem Entwickler, beliebige Recheneinheiten in das verteilte Datenbanknetz hinzuzufügen
ohne die Verfügbarkeit entscheidend einzuschränken. Wichtig ist, dass bei Ausfällen nicht
alle Daten auf alle Knoten im Netz neu verteilt werden müssen, sondern nur der "Nachbar"
ist für die temporäre Haltung der Daten verantwortlich.
Angenommen 100 Äpfel sollen auf zehn Menschen verteilt werden. Zuvor bekommt jede
Person und jeder Apfel eine zufällige Nummer zw. 1 und 1000 zugeteilt. Zuerst ziehen alle
Personen eine Nummer. Dann werden die 100 Äpfel nummeriert. Die Personen stellen sich
in Reihenfolge der gezogenen Nummern in einem Kreis auf. Die Äpfel werden nun anhand
der Zahlenbereiche, die die Personen zwischen einander bilden, aufgeteilt. Angenommen
jeder hält nun eine Schale mit zehn Äpfeln vor sich. Ein etwas schwacher Mensch kann diese
Schale nach einer Stunde Stehen nicht mehr halten und "fällt aus". Der Zahlenbereich für den
Nachbarn des Ausgefallenen ist nun größer geworden und er muss die Äpfel nun vom Boden
aufheben und solange tragen, bis der andere wieder einsatzbereit ist. Da der Ausgefallene
den Zettel mit seiner Nummer aber noch tragen konnte und er nach einer Weile wieder
erholt zurückkommt, nimmt er den ursprünglichen Platz und seine Äpfel wieder ein. Wichtig
bei diesem Gedankenexperiment ist, dass Personen und Äpfel immer die gleiche Nummer
behalten. Wenn eine elfte Person "tragen helfen" will, dann ist nur der linke Nachbar dafür
zuständig, ihm ein Teil seiner Äpfel zu übergeben, alle anderen brauchen sich nicht um ihn
zu kümmern.
Das Ergebnis (gezogene Nummer) einer Hashfunktion für ein Objekt ist z.B. ein Integer im
Wertebereich -2
31
- 2
31
- 1.
"Eine konsistente Hash-Funktion ist eine Hashfunktion, die die Anzahl der Neuzuordnungen
minimiert. [. . . ] Bei dem Gebrauch einer inkonsistenten Hash-Funktion werden alle Schlüssel
neu auf die verfügbaren Behälter verteilt. [. . . ] Konsistente Hash-Funktionen haben folgende
Eigenschaften: Einwegberechenbarkeit Kollisionsresistenz, Gleichverteiltheit und effiziente
Berechenbarkeit." [unk10e]
Daten (Äpfel) und Knoten (Personen) werden mit derselben Hashfunktion im Ring verteilt.
6
2. Konzepte moderner Datenbanken
"In einem Netzwerk von mehr als 200 Knoten wird somit eine akzeptable Standardverteilung
erreicht"(vgl. [Whi10]). Intervalle werden für die Datenaufnahme der Knoten gebildet. Wenn
ein "Knoten oder eine Festplatte ausfällt"(vgl. [PWB07]), werden nur die verlorenen Daten
neu verteilt. Diese kommen von Replikaten auf anderen Knoten.
Um dieses Verfahren zu veranschaulichen, ist in Abb. 2.1 eine Verteilung von Knoten und
Daten dargestellt. Wenn beide Enden des Intervalls miteinander verbunden werden, entsteht
ein schematischer Kreis.
Abbildung 2.1.: Consistent Hashing [Whi10] [KSB
+
99]
In Abb. 2.1 werden folgendermaßen Daten im Uhrzeigersinn auf die Knoten verteilt:
Knoten
Daten
A
2
B
3
C
4,1
"Wenn der Knoten C ausfällt, wird der Datensatz 3 auf A verteilt, alle anderen Verteilungen
bleiben gleich. Wenn ein Knoten D hinzugefügt wird (Abb. 2.2) werden die Datensätze 3
und 4 auf D verteilt und 1 auf A. " (vgl. [Whi10])
Die Daten haben einen eindeutig zugewiesenen Platz im verteilten Netz. Man geht davon
aus, das ausgefallene Knoten wieder hergestellt werden können (der Ausgefallene kommt
zurück).
7
2. Konzepte moderner Datenbanken
Abbildung 2.2.: Consistent Hashing [Whi10] [KSB
+
99]
2.2. Brewer's Theorem und "letztendliche Konsistenz"
"The dream scenario for scaling is a single logical database that can hold as much data, serve
as many queries, and grow as large as you need it to." (vgl. S. 412 [SZT
+
08])
In einem verteilten System geht es hauptsächlich um diese drei Eigenschaften: Verfügbarkeit,
Konsistenz und Ortsunabhängigkeit (Partitionstoleranz).
· Konsistenz
Ein konsistenter Service funktioniert ganz oder gar nicht. Weil von jedem Web-Service
Konsistenz erwartet wird, muss eine Ordnung zwischen den Operationen liegen, damit
es so scheint, als ob alle auf einer einzelnen Maschine ausgeführt wurden.
· Verfügbarkeit
Jede Anfrage an einen korrekt arbeitenden Knoten im verteilten System muss eine
korrekte Antwort geben. Jeder vom Service benutzte Algorithmus muss letztendlich
terminieren. Die Partitionstoleranz ist davon abhängig, denn wenn Netzwerkfehler
auftreten muss dieser Algorithmus trotzdem erfolgreich beendet werden.
· Partitionstoleranz
Partitionstoleranz ist ausschlaggebend für Verfügbarkeit und Konsistenz. Diese Toleranz
bringt unweigerlich verlustbehaftete Datenübertragungen zwischen den Partitionen mit
sich. Bei der Kommunikation zwischen den Partitionen ist es erlaubt, dass beliebig viele
Nachrichten verloren gehen. Die oben beschriebene Konsistenz in einem Web-Service
setzt voraus, dass jede Antwort für eine Anfrage ausgeliefert wird, gleichgültig ob
Nachrichten im verteilten System verloren gehen oder nicht. Keine Menge von Fehlern
8
2. Konzepte moderner Datenbanken
erlaubt es dem System inkonsistente oder inkorrekte Nachrichten auszugeben, außer
wenn das gesamte Netzwerk ausfällt. Im Web 2.0 Bereich existieren Datenmengen bei
denen Aufgrund der Größe jedes Datenbanksystem zusammenbrechen würde, wenn es
nicht partitionstolerant wäre.
Das Wunschszenario beschreibt ein verteiltes System, das immer verfügbar ist, das bei
Ausfällen weiterhin korrekt arbeitet und das auf einer einzigen Maschine funktioniert.
Weiterhin aber ist die Konsistenz einer Datenbank dann "traumhaft", wenn ein Wert auf
einen Knoten neu geschrieben oder verändert wird und jeder andere Knoten diesen Wert ohne
Verzögerung lesen kann. Alle diese Eigenschaften gleichzeitig in einem verteiltem System zu
haben stellt sich jedoch als Unmöglichkeit heraus. Im Juli 2000 wurde von Professor Brewer
die Behauptung aufgestellt, dass diese Eigenschaften im verteilten Netz nicht gleichzeitig
möglich sind, jedoch zwei davon: "You can have at most two of these properties for any shared-
data System." (vgl. [Bre00]) C, A und P sind die Anfangsbuchstaben dieser Eigenschaften,
daher wird dieses Theorem auch als CAP-Theorem bezeichnet. Zwei Jahre später wurde
diese Behauptung von S. Gilbert und N. Lynch (vgl. [GL02]) formal bewiesen. Abbildung
2.3) zeigt, dass es keine Schnittmenge zwischen den drei Eigenschaften gibt, jedoch die
Schnittmengen für zwei Eigenschaften vorhanden sind.
Abbildung 2.3.: CAP Theorem [unk10c]
Das würde bedeuten, dass ein verteiltes Datenbanksystem entweder hochverfügbar und
verteilt sein kann, die Daten aber einen inkonsistenten Zustand haben können. Das Netz
kann hochverfügbar sein und konsistent, jedoch muss die Datenbank dann auf einem einzigen
9
2. Konzepte moderner Datenbanken
Rechner installiert werden (vertikale Skalierung). Um die Konsistenz in einem verteilten
Netz zu gewährleisten muss demnach der Kompromiss gemacht werden, die Verfügbarkeit
einzuschränken.
Eine Datenbank ist beispielsweise auf mehrere Knoten aufgeteilt und durch asynchrone
Kommunikation sind die Knoten in der Lage miteinander zu kommunizieren, ohne dabei
die Verfügbarkeit einzuschränken. Der Beweis von Gilbert und Lynch bezieht sich auf
ein asynchrones, verteiltes Netzwerk, in dem Nachrichten zwischen den Knoten verloren
gehen können. Dadurch ist es definitiv nicht sicher, dass ein konsistenter Zustand, zu jedem
Zeitpunkt in einem verteilten, immer verfügbaren System gegeben ist.
Der Beweis zwingt den Entwickler folgende "Kompromisse" (vgl. [Bro10] ) zu machen:
1. Partitionstoleranz einschränken
Um dies zu umgehen ist es erforderlich, alles auf einer einzelnen Partition auszuführen.
Das ganze System muss auf einer atomar fehlschlagenden Einheit, z.B. einem Rack,
liegen. Das würde Seiteneffekte eines partitionierten Systems unterbinden. Dement-
sprechend gibt es einschlagende Grenzen bei der Skalierung.
2. Verfügbarkeit einschränken
Im Gegensatz zu Punkt 1 kann bei einem partitionierten System die Verfügbarkeit
gegenüber der Konsistenz bevorzugt werden. Um die Daten konsistent zu machen,
müssen sie auf einer festgelegten Anzahl von Knoten repliziert werden. In diesem
Zeitfenster ist das System nicht verfügbar.
3. Konsistenz einschränken
Damit würden Fälle entstehen bei denen Algorithmen ältere, inkonsistente Werte
zurückliefen.
Relationale Datenbanken unterliegen theoretisch einer starken Konsistenz, denn das "ACID"-
Prinzip (vgl. [HR83]) beschreibt, wie sich Transaktionen zu verhalten haben. Dieses Prinzip
sagt aber nichts darüber aus, ob das verteilte System in der Zeit, in der eine Transaktion
durchgeführt wird, noch verfügbar ist. Wenn ein Web-Service nicht verfügbar ist, entstehen
Umsatzeinbußen und Vertrauensverluste gegenüber Kunden. Wenn ein Web-Service am
meisten gebraucht wird, nämlich dann, wenn viele Zuggriffe auf einmal erfolgen wie z.B. zur
Weihnachtszeit, darf dieser nicht ausfallen oder einzelne Anfragen nicht beantworten.
ACID schreibt eine starke Konsistenz vor. Als Alternative steht dem ACID-Prinzip das
"BASE" (vgl. [FGC
+
97]) (Basically Available, Soft-state, Eventually consistent) Prinzip
gegenüber, welches ein optimistisches Konkurrenzverhalten [KR81] beschreibt. Dabei wird
10
2. Konzepte moderner Datenbanken
akzeptiert, dass die Datenbank sich in einem inkonsistenten Zustand befinden kann. "Es
stellt sich heraus, dass es möglich ist damit umzugehen und eine Skalierung erreicht werden
kann, die mit dem ACID-Prinzip nicht möglich wäre." (vgl. [Pri08])
Das E in "BASE" steht für "Eventually Conistent" (zu Deutsch "letztendlich konsistent").
"Viele Web-Services tolerieren inkonsistente Zustände zu einem gewissen Grad. Eine letzt-
endliche Konsistenz wird dabei anvisiert." (vgl. [GL02]) Moderne Datenbanken machen sich
u.a. dies zu Nutze, um Hochverfügbarkeit zu garantieren. Im nächsten Abschnitt wird die
letztendliche Konsistenz näher beschrieben.
Letztendliche Konsistenz
Letztendliche Konsistenz ist dann von großer Bedeutung, wenn
ein hochverfügbarer Datenbankservice bereitgestellt werden soll.
Wenn die Daten in einem verteilten System redundant gespeichert sind und es eine Verzö-
gerung bei der asynchronen Replikation gibt, dann ist es möglich, dass eine Anfrage an eine
dieser Replikationen einen nicht aktuellen Wert zurückliefert. Welche Chancen und Risiken
bietet letztendliche Konsistenz bei genau diesem Szenario?
Wenn ein System starke Konsistenz unterstützt, dann wird der geschriebene Wert garantiert
zurückgegeben. Bei einer schwachen Konsistenz wird dies nicht garantiert. Dann ist es
nicht vorhersehbar, wann eindeutig der veränderte Wert von jedem Knoten ausgegeben
wird. "Die letztendliche Konsistenz ist eine Form von schwacher Konsistenz, bei welcher
das Datenbanksystem garantiert, dass, wenn keine weiteren Veränderungen an dem Objekt
vorgenommen werden, das System letztendlich und von jeder Serverinstanz den richtigen
Wert zurückgibt." (vgl. S.42 [Vog09]) Wenn kein Fehler auftritt kann die Zeit, bis das System
einen konsistenten Zustand erreicht hat, bestimmt werden. Das erfolgt anhand Eigenschaften
wie Kommunikationsverzögerungen, Systemlast und Anzahl der Serverinstanzen. Eines der
berühmtesten Systeme dieser Art ist z.B. das Domain Name System (DNS).
Welche Möglichkeiten existieren, um mit inkonsistenten Verhalten umzugehen? Wenn ein
Algorithmus einen Wert schreibt, dann muss es Möglich sein, dass dieser Prozess auch
den veränderten Wert wieder zurückgibt und niemals den alten ("lies-was-du-schreibst
(RYW-)Konsistenz" [vgl. Vog09, S. 42]). In Kapitel 3.4 wird die RYW-Konsistenz näher
beschrieben. Praktisch kann dies mit "Session-Konsistenz" [vgl. Vog09, S. 42] umgesetzt
werden. Ein Prozess greift innerhalb einer Sitzung auf die Datenbank zu. Solange die
Sitzung existiert, wird die "RYW-Konsistenz" garantiert. Wenn diese Sitzung aufgrund
eines Fehlers terminiert, dann wird eine neue Sitzung eröffnet, welche keine Überlappungen
mit anderen Sitzungen garantiert. Durch eine Versionierung der Datensätze (Kapitel 2.3)
11
2. Konzepte moderner Datenbanken
ist eine "Monotonic read consistency"[vgl. Vog09, S. 42] (gleichbleibende Lese-Konsistenz)
möglich, hierbei gibt ein Prozess immer die letzte Version eines Wertes zurück, niemals einen
älteren. Bei einer gleichbleibenden Schreib-Konsistenz "Monotonic write consistency"(vgl.
S. 42 [Vog09]) wird garantiert, dass ein Prozess, welcher eine Serialisierung vornehmen soll,
diese auch eigenständig durchführt und kein anderer.
"Viele dieser Eigenschaften können kombiniert werden, z.B. "gleichbleibende Lese-" mit
"sitzungsbasierter Konsistenz". Aus praktischer Sicht sind "gleichbleibende-Lese-Konsistenz"
und "RYW Konsistenz" die wichtigsten Vertreter in einem "letztendliche Konsistenz"-System.
" (vgl. S. 42 [Vog09]). Diese zwei Prinzipien machen es für Entwickler einfacher, Applikationen
zu entwickeln. Die Datenbank kann ihre Konsistenz aufweichen und hohe Verfügbarkeit
bieten. Es gibt viele verschiedene Szenarios und Kombinationen, die auf unterschiedliche
Anwendungen zugeschnitten sein können. An Kompromissen führt jedoch kein Weg vorbei.
Inkonsistenz muss bei verteilten Systemen akzeptiert werden. Die Lese- und Schreibgeschwin-
digkeit ist unter hoch konkurrierenden Bedingungen, zu langsam. Partitionstoleranz kann
aufgrund der Fehlertoleranz entscheidend dazu beitragen. Ob diese Kompromisse gemacht
werden können, hängt stark von der jeweiligen Applikation ab. In jedem Fall muss sich
der Entwickler darüber im Klaren sein, dass diese Konsistenzansprüche von der Datenbank
ausgehen und diese bei einer Entwicklung beachten. "Verbesserungen wie "sitzungsbasierende
Konsistenz" oder "gleichbleibende Lese-Konsistenz" geben dem Entwickler bessere Werkzeu-
ge, um mit "letztendlicher Konsistenz" zu arbeiten." [vgl. Vog09, S. 42] Ein bestimmter Fall
beschreibt eine Webseite, bei der die Absicht besteht, dem Benutzer eine von ihm akzeptierte
Konsistenz zu gewährleisten. Dabei muss das "inkonsistente Zeitfenster" kleiner sein als das
zu erwartende "Neuladen" der Seite sein. Dabei kann eine Konsistenz hergestellt werden,
bevor ein neuer Lesezugriff höchstwahrscheinlich erfolgt. Wenn z.B. ein Facebookbenutzer
eine Nachricht an jemand schreibt, dann kann die Nachricht im "Browser-Speicher" (Javas-
cript) zwischengespeichert werden, bis diese Nachricht in der Datenbank persistent gemacht
wurde. Die gesendete Nachricht erscheint vorrübergehend im Postausgang, doch ist sie noch
nicht "gespeichert" und an den Empfänger übermittelt. Die kurze Zeitspanne erlaubt es der
asynchronen Verteilung dem Benutzer ein jederzeit konsistenten Service zu simulieren, bis
die Speicherung in einem "letztendliche Konsistenz System" wirklich erfolgt ist.
Der Web-Service einer Bank, um z.B. Überweisungstransaktionen durchzuführen, benötigt
eine starke Konsistenz. Angenommen es befindet sich eine relationale Datenbank auf dem
Server, "dann verbringt die Datenbank mehr Zeit damit zu entscheiden, auf welchen Server
geschrieben werden soll und in welcher Reihenfolge der Bearbeitungsprozess stattfindet als
mit dem eigentlichen Schreibprozess."(vgl. S.15 [ALS09]) Der Service in einem verteilten
12
2. Konzepte moderner Datenbanken
System ist dann nicht verfügbar. Dieser Kompromiss muss für diese Art von Web-Service
akzeptiert werden.
Ein Webshop führt keine Geldtransfers durch, der Kompromiss, die "Verfügbarkeit ein-
zuschränken", kann nicht gemacht werden, denn in der Zeit können andere Kunden keine
Artikel bestellen. Bei einem hochfrequentierten Webshop entstehen sonst Umsatzeinbußen.
"Es wird akzeptiert, dass, wenn zwei Kunden denselben Artikel bestellen, einer davon eine
nachträgliche Stornierung erhält."(vgl. [Bro10]) Wenn z.B. zwei Kunden bei einem Webshop
denselben Artikel bestellen und nur ein einziger verfügbar ist, dann bekommt der Käufer,
der vielleicht nur eine Sekunde später auf "Bestellen" geklickt hat eine Stornierung. Das ist
ein Kompromiss um Verfügbarkeit gegenüber Konsistenz vorzuziehen. Vorsorglich kann die
Lieferzeit verändert werden, wenn nur noch wenige Bestände von einem Artikel vorhanden
sind. Wenn zwei Kunden sich gegenseitig "kongruieren", dann freut sich der eine Kunde,
weil er den Artikel sofort zugeschickt bekommt und der andere weiß von der langen Warte-
zeit im Voraus. Wenn die Zeitspanne, bis eine Konsistenz letztendlich wieder erreicht ist,
gering bleibt, dann gehen viele diesen Kompromiss ein und akzeptieren eine vorübergehende
Inkonsistenz. Amazon behauptet, dass "nur eine Steigerung der Antwortlatenz um 0.1 einen
Umsatzrückgang von 1% nach sich zieht" (vgl. [LIN10]). Google sagt aus, dass "eine Sucher-
gebnisliste, welche nur 0.5 Sekunden zu spät ausgeliefert wird, einen Datendurchsatzrückgang
von 0.2 % nach sich zieht "(vgl. [Hof10]).
2.3. Versionierung der Daten
Angenommen ein Knoten fällt für fünf Minuten aus. In der Zwischenzeit werden die Daten,
die dem Knoten zugewiesen wurden von der "Nachbar-Maschine" bearbeitet. Nach einer
Wiederherstellung sind nun ältere Werte auf dem Knoten gespeichert. Wie werden die
obsoleten Datenstände letztendlich wieder aktualisiert?
Genau wie bei einem "Version Control System" (VCM) (subversion oder git) werden die
Daten in der Datenbank mit einer Version behaftet. In einem System, das sich über ca. 200
Knoten erstreckt, reicht es nicht aus, einen Datensatz mit einer Versionsnummer zu versehen
und anhand derer den wirklich korrekten, aktuellsten Wert zu berechnen. Ganz entscheidend
bei dem folgenden Prinzip ist, dass durch ein geeignetes Protokoll nachträglich berechnet
werden kann, welche Versionen von einander abstammen und welche nicht.
Das Prinzip der "Vektor Clocks" (vgl. [Fid88]) (vgl. [JS10b]) erweitert die Versionsverwal-
tung dahingehend, dass der Knoten, der das Objekt verändert, inkrementell seine Veränderung
13
2. Konzepte moderner Datenbanken
angibt. Es wird ein Protokoll an den Datensatz angehangen. Das Protokoll wird dann angelegt
oder erweitert, wenn ein Knoten einen Datensatz hinzufügt oder aktualisiert. Jedes Mal wenn
ein Knoten einen Wert verändert, erhöht er die Versionsnummer in dem Protokoll um eins.
Dabei gibt der Knoten seine Id mit. Wenn ein anderer Knoten denselben Datensatz verändert,
dann fügt er seine Id hinzu. Wenn derselbe Knoten einen Datensatz zweimal verändert, dann
entsteht ein Schlüssel-Wert-Paar: ""X":2". Der Knoten "Y" verändert jetzt zum ersten Mal
diesen Datensatz und fügt in das Protokoll seine Signatur ein: ""KnotenX":2, "KnotenY":1"
usw.. Die Protokolle können in manchen Fällen lang werden und eine Berechnung kann
damit viel CPU-Zeit in Anspruch nehmen.
2.4. MapReduce
Wie können Daten in einem verteilten System abgefragt oder analysiert werden?
Eine "Tagcloud" in einem Blog besteht z.B. aus einer Menge von Tags, die einem Blogeintrag
zugeordnet wurden. Ein "Tag" wird größer dargestellt, wenn es öfters verwendet wurde als
andere. Angenommen Wordpress.com mit all seinen Blogs baut eine neue Art von Tagcoulds,
die nicht auf Tags basiert, sondern auf allen Wörtern in jedem Artikel. Höchstwahrscheinlich
ist dann das Wort "ok" am größten, weil es vielleicht am meisten vorkommt. Wordpress hosted
unzählige Blogs. Eine Berechnung der Tagcould würde mit nur einem Datenbanksystem
wahrscheinlich Jahre dauern. Angenommen Wordpress.com speichert die Artikel in einem
verteilten Netzwerk mit ca. 200 Knoten. Jeder dieser Knoten ist für zehn Terabyte an
Blogdaten (Artikel) verantwortlich. Um diese Aufgabe bewältigen zu können, muss die
Anfrage an alle Knoten gesendet werden. Die Knoten filtern die Daten, im besten Fall
alle gleichzeitig und geben das Ergebnis zurück. Angenommen das Datenbankteam bei
Wordpress.com entscheidet sich gegen die Verwendung einer SQL Abfrage, weil diese nach
langem Probieren zu ineffizient ist. Angenommen die Daten von der relationalen Datenbank
liegen in mehreren Datenbankdateien auf jedem Knoten. Dann bestünde die Möglichkeit,
diese durch ein geeignetes Programm zu parsen. Nach langem Probieren stellt sich heraus,
dass es eindeutig schneller ist, die Rohdaten zu parsen. Das Team entscheidet später das
"ParseProgramm" für ein verteiltes Rechnen zu erweitern, jedoch stellt sich heraus, dass die
"Programmierung mit Threads, Locks, Forks nicht trivial ist."(vgl. S.372 ff [DG10b]) Eine
Optimierung dieses verteilten Programms würde mehrere Monate in Anspruch nehmen.
Google stand vor dem gewaltigen Problem, das ganze Internet zu indizieren und entwarf
ein Verfahren, um große Datenmengen parallel zu verarbeiten: "MapReduce"(vgl. [GGL03]).
MapReduce erfüllt "drei primäre Leistungen." (vgl. S.8 [PDGQ05]) Erstens bietet es ein
14
Details
- Seiten
- Erscheinungsform
- Originalausgabe
- Jahr
- 2010
- ISBN (eBook)
- 9783842806085
- DOI
- 10.3239/9783842806085
- Dateigröße
- 1.4 MB
- Sprache
- Deutsch
- Institution / Hochschule
- Fachhochschule Brandenburg – Informatik
- Erscheinungsdatum
- 2010 (November)
- Note
- 1,9
- Schlagworte
- konsistenz skalierung
