Ein Einblick in das Gebiet der Verteilten Datenbanksysteme

Seminar Programmiersprachen und Programmiersysteme
Ein Einblick in das Gebiet der Verteilten
Datenbanksysteme
Bettual Richter
8. Februar 2010
Betreuer: Prof. Frank Huch
1

Inhaltsverzeichnis
1 Einleitung 3
2 Grundlagen 3
2.1 Datenbanksysteme . . . . . . . . . . . . . . . . . . . . . . 3
2.1.1 Relationale Datenbanken . . . . . . . . . . . . . . . 4
2.1.2 Operationen . . . . . . . . . . . . . . . . . . . . . . 5
2.1.3 Transaktionen . . . . . . . . . . . . . . . . . . . . . 6
2.2 Rechnernetze . . . . . . . . . . . . . . . . . . . . . . . . . 8
3 Architektur verteilter Datenbanksysteme 9
3.1 Katalog des Systems . . . . . . . . . . . . . . . . . . . . . 10
3.2 Fragmentierung und Allokation . . . . . . . . . . . . . . . 11
3.3 Klassifikation nach Verteilungsgrad . . . . . . . . . . . . . 12
4 Umsetzung einiger Konzepte 14
4.1 Client/Server-Datenbanksysteme . . . . . . . . . . . . . . 14
4.1.1 Funktional gleichgestellte DBS . . . . . . . . . . . . 15
5 Anfragebearbeitung und Transaktionsverwaltung 16
5.1 Anfragebearbeitung . . . . . . . . . . . . . . . . . . . . . . 16
5.2 Transaktionsverwaltung . . . . . . . . . . . . . . . . . . . 17
5.3 Drei-Phasen-Commit(3PC) . . . . . . . . . . . . . . . . . . 19
6 Fazit und Ausblick 20
2

1 Einleitung
Aufgrund der sinkenden Hardwarepreise in den letzten Jahren steigt das
Interesse an verteilten Systemen zunehmend. Die Anforderungen eines Unternehmens
bezüglich Leistungsfähigkeit, Kosteneffektivität und Verfügbarkeit
führen bei zentralistisch organisierten Informationssystemen schnell zu unverhältnismäßig
hohen Ausgaben. Es ist auch leicht nachvollziehbar, dass
ein einzelner Rechner schnell zu einem Systemengpaß werden kann und
die Antwortzeiten beim Systemzugriff darunter leiden.
Der Einsatz einer verteilten Systemstruktur stellt hingegen die Kapazität
mehrerer Rechner zur Verfügung und die Kapazität des Gesamtsystems
kann grundsätzlich durch Erhöhung der Rechnerzahl vergleichweise
kostengünstig gesteigert werden.
Besonders im Bereich der Datenverwaltung kann eine dezentrale Organisation
der Informationssysteme im Vergleich zu zentralen Rechnenzentren
punkten. In dieser Arbeit wollen wir einen Überblick über die Konzepte
solcher verteilten Datenverwaltungssysteme schaffen.
2 Grundlagen
In diesem Abschnitt betrachten wir zunächst grundlegende Konzepte, die
für das Verständnis notwendig sind. Dabei geht 2.1 auf verbreitete Datenbanksysteme
ein und 2.2 schafft einen Überlbick über Rechnernetze als
Vorraussetzung verteilter Systeme.
2.1 Datenbanksysteme
Aufgabe eines Datenbanksystems ist die Verwaltung von Daten eines Unternehmens
oder einer Behörde. Dabei soll die interne Struktur und Organisation
der Daten möglichst für den Benutzer bzw. die Anwendung
transparent gehalten werden. Im Zuge dieser Forderung muss das System
also weitgehend selbständig Kriterien der Integrität, Konsistenz sowie Persistenz
der Daten gewährleisten und trotzdem den hohen Anforderungen
an Leistungsfähigkeit und Verfügbarkeit genügen. In gängigen Systemen
wird dies durch ein sogenanntes Datenbank-Managementsystem(DBMS),
eine vor die Datenbank geschaltete Software, bewerkstelligt. Die, aus Sicht
3

eines Benutzers bzw. einer Anwendung, transparente Verbindung zwischen
der eigentlichen Datenbank(DB) und dem DBMS, führt dazu, dass häufig
von einem Datenbanksystem(DBS) gesprochen wird und eine bezugnehmende
Trennung nur stattfindet, wenn diese vonnöten ist[2]. Im Allgemeinen werden
die von einem Datenbanksystem bereitgestellten Daten von unterschiedlichen
Benutzern verwendet, was eine bedarfsgerechte Aufbereitung
und eine Berechtigungsprüfung erfordert. Der Mehrbenutzerbetrieb führt
offensichtlich auch zu konkurrierenden Anfragen an das Datenbanksystem,
die weder zu einem inkonsistenten Zustand noch zu einem Verlust
von Daten führen dürfen.
Bei unseren Erläuterungen betrachten wir vor allem das relationale Datenmodell,
denn es hat sich klar gegen ältere Konkurrenzmodelle, wie das hierarchische
oder das Netzwerk-Modell, durchgesetzt und bietet aufgrund
seiner mengenorietierten Anfragen einige Vorteile zur verteilten und parallelen
Datenbankverarbeitung. Daneben gibt es aber auch neuere Konzepte.
Das objektorientierte Datenbankmodell verwaltet Daten in Form von Objekten.
Dieses Konzept konnte sich jedoch nach der Euphorie in den 1980ern
nicht durchsetzen als man erkannte, dass die Vorteile ihrem Preis in Form
von längeren Antwortzeiten forderten. Die Forschungen aus diesem bereich
ermöglichten aber die Erweiterung des relationalen Datenbankmodells
zu einem Objektrelationalen-Modell, dessen Konzepte weitgehend in
den SQL2003 aufgenommen wurden. Die späte Standardisierung dieser
Konzepte führte dazu, dass ihre Umsetzung in kommerziellen Systemen
noch uneinheitlich ist.[2]
2.1.1 Relationale Datenbanken
Die Daten in einer relationalen Datenbank werden in Tabellen(Relationen)
gespeichert. Dabei besteht eine Relation aus ihrem Namen, einer Anzahl
von Spalten(Attributen), die den Grad der Relation bestimmt und einer
Anzahl von Zeilen oder Tupel, welche die Kardinalität der Relation angibt.
Darüber hinaus ist jedem Attribute ein Definitionsbereich(Domain)
zugeordnet, welcher die zulässigen Werte festlegt. Die Mengeneigenschaft
von Relationen bedeutet in diesem Kontext, dass Tupel nicht mehrfach
vorkommen und keine vorgegebene Ordnung innerhalb der Relation besteht.
Das relationale Datenbankmodell schreibt zwei Integritätsbedingungen,
die sogenannten Relationalen Invariaten, vor.
4

• Die Primärschlüsselbedingung erwartet zu jeder Relation eine
Menge(auch einelementig) von Attributen, mit der ein Tupel eindeutig
identifiziert werden kann. Diese Menge ist als Primärschlüssel
der Relation auszuzeichnen.
• Die Fremdschlüsselbedingung hingegen fordert für Fremdschlüssel,
mit denen Beziehungen zwischen Relationen realisiert werden können,
dass ein durch einen Fremdschlüsselwert referenziertes Tupel in der
Datenbank existiert.
Die Menge der Relationen einer Datenbank bezeichnet man als Schema
und unterscheidet Grundsätzlich zwischen dem Konzeptionellen- und dem
Internen- Schema. Letzteres befasst sich weitgehend mit der physischen
Speicherung der Daten und ist für den Anwender transparent. Den Zugriff
auf die Daten erhält der Benutzer also über das Konzeptionelle-Schema,
wobei in den meisten Fällen ein an die jeweiligen Anforderung angepasstes
Externes-Schema für Benutzer bereitgestellt wird.
2.1.2 Operationen
Für Anfragen auf einer Datenbank findet die Sprache SQL(Structured
Query Language), eine praktische Umsetzung der relationalen Algebra,
verwendung. Diese bietet, neben den allgemeinen mengentheoretischen
Operatoren wie Durchschnitt(∩), Vereinigung(∪) oder kartesisches Produkt(×),
auch die relationalen Operatoren Selektion(σ - Selektion), Projektion(π)
oder Verbund(⊲⊳ - Join) an.
• Die Selektion σ P (R) bildet eine horizontale Teilmenge der Relation
R, in der alle Tupel enthalten sind, die das Selektionsprädikat
P erfüllen. Teilweise wird auch von Tupelauswahl gesprochen[2]
• Mit der Projektion π (x:xs) (R) wird eine vertikale Teilmenge der
Relation R gebildet. Dabei enthält die Attributliste (x : xs) alle
Eigenschaften, die erhalten bleiben sollen.
• Der Verbund oder Join ermöglicht das Verknüpfen zweier Relationen,
die Attribute mit übereinstimmenden Wertebereichen(Domains)
besitzen. Ein Verbund der Relationen A(A 1 , . . . , A n ) und B(B 1 , . . . , B n )
auf Grundlage eines passenden Vergleichsoperators
5

θ : Domain(A i ) × Domain(B j ) → bool
liefert, für fest gewählte i, j ∈ {1, . . . , n}, die Menge der Tupel
{a ∪ b | a ∈ A i ∧ b ∈ B j ∧ θ(a, b)}.
Sonderfälle des Verbunds sind der Gleichverbund(Equi Join), mit
einem Gleichheitsoperator, und der Natürliche-Verbund(Natural Join),
der sich aus einem Gleichverbund und einer Ausblendung gleicher
Attribute zusammensetzt. Das Verknüpfen der Tupel beim natürlichen
Verbund erfolgt über Attribute, die in den beteiligten Relationen die
selbe Bezeichnung haben. Falls kein solches Attribut vorhanden ist,
erhält man als Ergebnis das kartesische Produkt.
Der Vollständigkeit halber sollten wir noch erwähnen, dass die Sprache
SQL weniger als Schnittstelle für den Endanwender, sondern viel mehr
als Abstraktionsebene für Anwendungsentwickler gedacht ist. Ein einfacher
Angestellter, der auf Firmendaten zugreifen möchte, muß sich für
gewöhnlich nicht dieser bedienen, sondern benutzt eine Anwendung, die,
optimalerweise über eine intuitive graphische Oberfläche, ähnliche Funktionalität
bereitstellt und die SQL-Anfragen intern generiert.
2.1.3 Transaktionen
Um einen korrekten Ablauf von Operationen im Mehrbenutzerbetrieb zu
gewährleisten, zieht man das Konzept der Transaktion zu Hilfe. Mit Korrektheit
ist die Integrität des Datenbestandes gemeint. Unterschieden wird
zwischen der semantischen Integrität und der Ablaufintegrität[2].
Ersteres bezieht sich auf die Bedeutung der Daten und fordert einen semantisch
konsistenten Datenbankzustand nach Abschluss einer Tranksaktion.
Beispielsweise würde eine negative Altersangabe ein semantisches Problem
darstellen, auch wenn sich der Wert innerhalb des Definierten Wertebereichs
befindet und syntaktisch zulässig ist.
Bei der Ablaufintegrität , die auch als operationale Integrität bezeichnet
wird, ist die Zusicherung, dass Fehler nicht durch konkurrierende Anfragen
bzw. Zugriffe entstehen. So würde das Resultat verschiedener ”gleichzeitiger”
Buchungen auf einem Konto immer zum selben Ergebnis führen.
6

Eine Transaktion ist eine Folge von Datenbankoperationen, die von außen
betrachtet als atomare Einheit erscheint und eine Datenbank von einem
konsistenten Zustand in einen anderen konsistenten Zustand überführt.
Innerhalb des Datenbanksystems kann eine Transaktion aus vielen Operationen
bestehen. Stellt man sich eine Banküberweisung von einem Konto
A zu einem Konto B vor, so sind die notwendigen internen Operationen
erkennbar, die, transparent für den Benutzer, vom DBMS durchgeführt
werden.
Transaktion Überweise
e 20.00 von Konto A → Konto B
• Prüfe ob es ein Konto A gibt
• Prüfe ob Konto A über ausreichend Deckung verfügt
• Prüfe ob es ein Konto B gibt
• Belaste Konto A mit e 20.00
• Schreibe e 20.00 auf Konto B gut
• Schließe die Transaktion ab
Sollte bei der Abarbeitung dieser Operationen ein Fehler auftreten, darf
dennoch kein Fehler in der Datenbank resultieren, denn es ist ja schon
genug Geld in letzter Zeit verschwunden.
Eine große Herausforderung an Datenbanksysteme ist das Gewährleisten
dieser Forderung, deren Komplexität natürlich mit dem Verteilungsgrad
eines Informationssystems zu nimmt.
In den 70er und 80er Jahren des vergangen Jahrhunderts, prägte Jim
Gray die Transaktionsverarbeitung im Bereich der Datenbanken bevor
Theo Härder und Andreas Reuter 1983 mit ihrer Arbeit Principles of
transaction-oriented database recovery[4] das Schlag-Akronym ACID in
den Informationswissenschaften etablierten. Das ACID-Prinzip wird heutzutage
als Maßstab für korrekte Transaktionen angesehen und stellt die folgenden
vier Bedingungen auf[1] [2] :
• Atomarität(Atomicity) : Eine Transaktion wird entweder ganz oder
gar nicht auf einer Datenbank ausgeführt und kann im Falle eines
Fehlers keine Zwischenzustände hinterlassen.
7

• Konsistenz(Consistency) : Transaktionen sind kleinste Einheiten
der Integritätsüberwachung und nach Abschluss einer transaktion
muss die Integrität sichergestellt sein.
• Entkoppelung(Isolation) : Für einzelne Transaktionen wird der
Einbenutzerbetrieb so simuliert, dass sich konkurrierende Transaktionen
nicht gegenseitig beeinflussen können.
• Dauerhaftigkeit(Durability) : Ist eine Transaktion einmal erfolgreich
abgeschlossen wurden, so bleiben die gemachten Änderungen
auch im Falle eines Fehlers erhalten.
2.2 Rechnernetze
Ein Rechnernetz verbindet mehrere Rechner miteinander und ermöglicht
so den Nachrichtenaustausch unter den verbundenen Netzteilnehmern. In
den Anfängen der verteilten Informationssysteme war es notwendig auf
die Beschaffenheit und die Kapazitäten dieser Netze einzugehen, weshalb
sich in den meisten älteren Büchern auch ein Kapitel mit der Problematik
auseinander setzte.
Dieser Aspekt kann mittlerweile jedoch weitgehend aufgrund der großflächigen
Einführungen von Breitband-Netzen vernachlässigt werden. Ebenfalls sind
relativ zuverlässige Protokolle wie TCP, IPv4 oder das in der Einführung
befindliche IPv6 schon ausreichend etabliert und innerhalb der gängigen
Entwicklungs-Technologien mit Hilfe von Schnittstellen so weit abstrahiert,
dass man diese als Entwickler nur noch einbinden muss, um eine Kommunikation
zu ermöglichen. Einen tieferen Einblick in diese Materie ermöglichen
die Vorlesungen Communication Systems oder Internet Communications
von Prof. Luttenberger, deren Inhalte unseren Rahmen hier sprengen würde.
Unsere Bedürfnisse sind damit befriedigt, dass wir eine Schnittstelle haben,
die uns eine Kommunikation mit Ortsfremden Rechnern ermöglicht und
durch die Synchronisation des Nachrichtenaustauschs, wie bei TCP, ein
Maß an Zuverlässigkeit gegeben ist.
8

3 Architektur verteilter Datenbanksysteme
Unter einer verteilten Datenbank versteht man eine Sammlung logisch
zusammengehöriger Datenbanken, die über Rechnerknoten(Sites) verteilt
sind und über ein Rechnernetz mit einander Kommunizieren. In dem
Zusammenhang spricht man von einem verteilten DBMS(vDBMS, DDBMS)
und meint damit eine Software zur Verwaltung einer verteilten Datenbank.
Eine solche Software muss verschiedene Kriterien der Transparenz erfüllen;
also die interne Realisierung dieser Eigenschaften sollen für den Einsatz
nicht relevant sein.
• Orts-Transparenz : Ein Benutzer, der eine Datenbankanfrage in
Auftrag gibt, muß nicht wissen wo die angefragten Daten physisch
liegen.
• Fragmentierungs-Transparenz : Die Zerlegung einzelner Relationen
zum Zwecke der Verteilung ist für den Benutzer unsichtbar.
• Replikations-Transparenz : Ob und wie Daten intern redundant
gehalten werden, soll für den Benutzer verborgen bleiben.
• Implementierungs-Transparenz : Der Einsatz des Datenbanksystems
soll unabhängig von der internen Aufbereitung für verteilte
Anfragen sein.
Man unterscheidet verteilte Datenbanken unter anderen auch nach den
eingesetzten Modellen. Als herterogen verteilte Systeme bezeichnet man
solche, die unterschiedliche Datenmodelle, etwa Relationale- und Objecktorientierte-
Datenbankmodelle, als Grundlage haben. Solche Systeme entstehen beispielsweise
bei der Fusionierung zweier Unternehmen, die zuvor unterschiedliche
Produkte in der Datenverwaltung eingesetzt haben, weshalb man hier
auch von föderativen Datenbanksystemen spricht. Bei Systemen dieser
Art müssen natürlich Abstriche in Bezug auf die obigen Kriterien in Kauf
genommen werden. Von homogenen verteilten Systemen spricht man hingegen,
wenn beteiltigte Datenbanken das gleiche Datenmodell als Grundlage
haben und damit eine Verteilungtransparenz für den Benutzer erreichbar
ist.
9

3.1 Katalog des Systems
Der Datenkatalog bezeichnet die Menge der für die Verwaltung nötigen
Meta-Daten wie (Schemainformationen, Zugriffsberechtigungen, Passwörter,
Statistiken).
Im verteilten Fall muss hier eine Trennung bezüglich der lokalen und
globalen Daten erfolgen. Der lokale Katalog enthält die Metainformationen
zu den lokal gespeicherten während der Globale eine Gesamtübersicht
sämtlicher Daten des Systems verwaltet. Die Verteilungstransparenz wird
dabei vom globalen Katalog durch eine Abbildung zwischen logischen,
globalen Namen und physischen Adressen realisiert. Für die Katalogverwaltung
gibt es verschiedene Konzepte :
• Zentralisierter Katalog : Ein vollständiger Katalog wird an einem
Knoten verwaltet. Diese Art der Verwaltung bringt einen hohen
Kommunikationsaufwand mit sich, kann schnell zu Engpässen führen
und schränkt die gewünschte Knotenautonomie stark ein.
• Replizierter Katalog : Ein vollständiger Katalog an jedem Knoten
vorhanden. Dadurch erreicht man eine hohe effizienz für lokale Leseoperationen.
Nachteile bestehen jedoch bei Änderungsoperationen
und im Schutz der Daten.
• Mehrfachkotaloge : Die beteiligten Rechner werden zu Cluster
verknüpft und man legt in jedem Cluster einen vollständigen globalen
Katalog an. Der Gewinn bei Änderungsoperationen und einer
erhöhten Knotenautonomie muss jedoch mit einer Partitionierung
des Gesamtnetzes bezahlt werden.
• Partitionierter Katalog : Der globale Katalog wird verteilt gespeichert.
Damit hat man keinen expliziten globalen Katalog. Dieser
liegt nur noch implizit als Vereinigung der lokalen Kataloge vor.
Dazu sind dann auch noch erweiterte Bezeichner mit Verteilungsinformationen
nötig, um nicht lokale Daten finden zu können. Der
Gewinn dieser Aufteilung ist ein hohes Maß an Autonomie.
10

3.2 Fragmentierung und Allokation
In einem verteilten Informationssystem geht es natürlich auch um die
Verteilung der Informationen. In unserem Fall also um die Verteilung der
vom Datenbanksystem verwalteten Daten. Diese beeinflußt zwangsläufig
auch Systemeigentschaften wie den Kommunikationsaufwand für einen
gewünschten Datenzugriff, die Systemlast und natürlich auch die Verfügbarkeit
der Daten. Bei der physischen Streuung der Daten spricht man von Allokation
und beschreibt die Aufteilung einzelner Relationen als Fragmentierung.
Fragmentierung
Die Fragmentierung unterscheidet zwischen horizontaler - und vertikaler
Fragmentierung. Bei der horizontalen Fragmentierung wird eine Relation
anhand eines Attributes mit Hilfe einer Selektion in disjunkte Teilmengen
aufgeteilt. Zum Beispiel könnte man eine globale Relation von Kunden
einer Bank mit Hilfe der zugehörigen Filiale aufteilen und bekommt ein
Fragment mit den jeweiligen Kunden für jede Filiale σ F iliale=”Kiel” (R)
.
Die vertikale Fragmentierung hingegen ist eine Projektion bestimmter Attribute
einer globalen Relation. Dabei sollte der Primärschlüssel in jeder
Projektion für eine Rekonstruktion mit Hilfe eines Verbunds enthalten
sein.
Π KNR,Name,F iliale (R)
Allokation
Die Verteilung der einzelnen Fragmente auf bestimmte Knoten oder Sites
wird als Allokation bezeichnet. Die Verteilung aller Fragmente auf alle
Knoten nennt man eine replizierte Datenbank, wohingegen eine disjunkte
Verteilung eine partitionierte Datenbank zur Folge hat. Im Allgemeinen
wird aber eine partielle Replikation eingesetzt, da diese geringere Änderungskosten
als eine volle Replikation hat und trotzdem die Verfügbarkeit des Gesamtsystems
steigert, denn falls gewisse Knoten ausfallen, sind die dort gespeicherten
Daten aufgrund der Replikation noch immer verfügbar. Natürlich
11

erreicht man damit keine Verfügbarkeitsgarantie, aber immerhin eine signifikante
Steigerung bei akzeptablen Kosten[3]
Eine geeignete Kombination aus Fragmentierung und Allokation kann
zu einer hohen Lokalität der Verfügbarkeit führen. Wenn man beispielsweise
in einer Bank eine horizontale Fragmentierung bezüglich der Filialen
wie beschrieben vornimmt und die Allokation so gestaltet, dass die
Filial-Fragmente an der jeweiligen Filiale vorhanden sind, kann ein Großteil
der Operationen in der Filiale lokal und ohne Interaktion mit dem Rest
des Systems erfolgen.
3.3 Klassifikation nach Verteilungsgrad
Multiprozessor Datenbanksysteme(Shared-Everything)
Diese Art von Datenbanksystemen unterscheiden sich von zentralen System
nur aufgrund der Anzahl an Recheneinheiten. Verteilungsaspekte wie
die Kommunikation, werden dabei weitgehend vom Betriebstsystem übernommen
und müssen nicht besonders bei der Datenverwaltung berücksichtigt werden.
Aus Sicht der ”Datenbänker” sind diese weitgehend als gewöhnliche
zentrale Datenbankssysteme zu behandeln.
Datenbank-Sharing(Shared-Disks)
Bei diesen Datenbanksystemen hat man keine physische Datenaufteilung
zwischen den beteiligten Rechnern, jedoch ein Datenbanksystem auf jedem
Rechner. Die Daten werden in einem externen Speicher gelagert, auf
den die CPUs bei Bedarf zugreifen. Die Kommunikation zwischen den
Rechnern muss dann vor allem die Speicher- bzw Datenbank-Zugriffe synchronisieren.
Ein Vorteil dieser Struktur ist, dass alle Operationen einer
Transaktion auf einem Rechner abgearbeitet werden können und somit
verteilte Ausführungspläne unnötig sind. Hingegen kann es hier zu Problemen
durch mehrfach Kopien in dem Hauptspeicher der beteiligten Rechner
kommen. Der gemeinsame Zugriff aller Beteiligten bringt natürlich auch
Probleme in der Anfragebearbeitung und der Transaktionsverwaltung mit
sich. Als kommerzielle Produkte in diesem Bereich kann man Oracle Parallel
Server oder IBM DB2 aufführen.
12

Datenbank-Distribution(Shared-Nothing)
Hierbei hat man das Datenbanksystem im allgemeinen auf mehrere lose
gekoppelte Rechner und DBMS verteilt. Jeder einzelne Rechner hat zunächst
nur Zugriff auf lokale Daten was offensichtlich verteilte Ausführungspläne
für Datenbankoperationen nötig macht. Probleme sind hier durch globale
Deadlocks und die Wartung replizierter Daten gegeben. Bei diesen Strukturen
sind sogenannte rechnerübergreifende Commit-Protokolle und Katalogverwaltung
nötig. Einige kommerzielle Produkte hier sind Teradata,
Sybase SQL-Anywhere oder IBM DB2.
13

4 Umsetzung einiger Konzepte
Um die 1980er Jahre gab es spezielle Datenbank-Hardware, die mit der
Hoffnung besserer Effizienz aufgrund von spezialisierung im Markt platziert
wurde. Diese Rechner konnten sich jedoch nicht durchsetzen, denn die
softwarebasierten Systeme entwickelten sich ungleich schneller und waren
kosteneffizienter. Der enorme Leistungszuwachs der softwarebasierten Maschinen
hat diesen Ansatz mittlerweile komplett verdrängt, so dass er nur noch
einen geschichtlichen Einfluss hat.
4.1 Client/Server-Datenbanksysteme
Die Client/Server-Datenbanksysteme sind Systeme der funktionalen Spezialisierung
und sehr verbreitet in der heutigen Informationsverarbeitung.
Haupteigenschaft ist die Unterteilung in Client- und Server-Datenbanksysteme.
Die Daten werden auf einer Datenbank unter verwaltung des Server-Systems
gehalten. Clients können diese Abfragen bzw. auf diese Zugreifen, haben
aber auch einiges an typischer Datenbankfunktionalität in ihrem lokalen
Datenbank-Managementsystem gegeben. Einerseits entstehen hier geringere
Kosten durch Clients, die ungleich Kosteneffizienter sind als große
Server-Systeme und eine Einbenutzer-Sicht ermöglichen,andererseits kann
der Server auch schnell zum Engpaß bei hoher Frequentierung werden.
• Client-Dienste : Clients übernehmen lokale Dienste wie Anfragebearbeitung,
bei welcher die Anfrageoptimierung schon weitgehend
auf den Clientsystem stattfinden kann, oder die Pufferung von Datenbank-
Objekten, um die kommunikation zwischen Client und Server zu
minimieren und so den Server, der leicht zum Flaschenhals wird, zu
entlasten.
• Server-Dienste : Typischerweise übernimmt das Server-System globale
Aufgaben wie die Externspeicherverwaltung, Synchronisation oder
Logging, die nicht unmittelbar relevant für den Bentuzer sind und
verschiedene Beteiligte miteinander koordinieren müssen.
Die Aufteilung in dieser Form ist nicht einheitlich in allen kommerziellen
Systemen zu finden, sondern beschreibt nur die Tendenzen, die hin und
wieder auch vermischt zum Einsatz kommen. Der zunehmende Einsatz
14

dieser Strukuren zeigt natürlich auch die damit verbundenen Probleme.
Beispielsweise stellt der Server einen empfindlichen Punkt für Angriffe dar.
Bei einem Ausfall resultiert natürlich ein globaler Ausfall des gesamten
Systems, weshalb die Verfügbarkeitsanforderungen in diesem Bereich besonders
hoch sind. Dies treibt wiederum die Instandhaltungs- und Betriebskosten
in die Höhe.
4.1.1 Funktional gleichgestellte DBS
Während die Client/Server-Systeme sich als funktional spezialisiert beschreiben
lassen, findet eine derartige Aufgabentrennung bei diesem Konzept nicht
statt. Funktional geleichgestelle Datenbanksysteme bestehen aus einzelnen
Rechnerknoten, die alle über ein eigenes DBMS zur Verwaltung lokaler
Daten verfügen, über ein Rechnernetz mit einander kommunizieren und
anhand eines globalen Schemas nicht lokale Daten referenzieren können.
Dabei sind grundsätzlich alle Rechnerknoten gleichberechtig und übernehmen
spezielle Aufgaben, wenn es um einen Transaktionsabschluss oder ähnliches
geht. Wenn man auf Redundanz verzichtet, ist die Verfügbarkeit von
lokalen Daten bei einem Ausfall natürlich nicht mehr gewährleistet. Im
Gegensatz zu anderen Lösungen bleibt jedoch das Gesamtsystem weiterhin
im Einsatz und macht das betroffene unternehmen nicht völlig handlungsunfähig.
Für die Realisierung solcher Systeme ist es natürlich nötig eine
nicht hierarchische Lösung z.B. für Änderungsoperationen einzuführen,
denn es gibt hier keinen Server, der globale Aufgaben übernehmen kann.
15

5 Anfragebearbeitung und Transaktionsverwaltung
Die vom DBMS realisierte Verteilungstransparenz ermöglicht es dem Benutzer
einer verteilten Datenbank seine Anfragen auf Grundlage des Globalen-
Konzeptionellen-Schemas(GKS) zu formulieren, ohne dass dieser sich auf
die Allokation bestimmter Daten beziehen muß. Das erfordert eine interne
Bearbeitung der Anfrage, um die gewünschten Operationen korrekt
und möglichst effizient auf die einzelnen Rechnerknoten verteilen zu
können. Trotz der Verteilung, ist jedoch die Gewährleistung der in 2.1.3
eingeführten ACID-Eigenschaften eine unverzichtbare Anforderung. Hierbei
gibt es einige Aufgaben, wie die Anfrageoptimierung, die weitgehend
lokal durchgeführt werden können und andere, die einer externen Bearbeitung
bedürfen.
5.1 Anfragebearbeitung
Genau wie bei zentralen Datenbanksystem ist es die Aufgabe der Anfragebearbeitung
möglichst effiziente Ausführungspläne für ankommende
DB-Operationen zu erstellen und auszuführen. Es muss also entschieden
werden in welcher Reihenfolge der Zugriff auf Relationen abzulaufen hat.
Zunächst wird die eingehende SQL-Anfrage in eine interne äquivalente
Form, z.B. in einen Ausdruck der relationen Algebra, Transformiert. Dieser
Schritt kann lokal erfolgen, da er, bis auf mögliche verteilte Katalogzugriffe,
keine Verteilungsinformationen benötigt. Im Falle der Fragmentierung
einzeler Relationen müssen diese mit Hilfe des globalen Verteilungsschemas
durch einen Rekonstruktionsausdruck ersetzt werden, welche auch
zu optimieren sind. Zuletzt muss eine aus globaler Sicht möglichst kostengünstige
Ausführungsreihenfolge festgelegt werden, wobei vorallem der Kommunikationsaufwand
neben der benötigten CPU-Zeit und dem Speicherbedarf
eine große Rolle spielt. Diese Transformation liefert einen optimierten
Fragment-Ausdruck, mit den einzelnen Kommunikationsoperationen und
einzelne Fragment-Anfragen für physisch entfernte Rechnerknoten, aus
dem die Code-Generierung ein ausführbares Programm macht.
16

5.2 Transaktionsverwaltung
Eine Transaktion ist eine Menge von Datenbank-Operationen, die von einer
BOT(Begin of Transaction)-Operation und einer EOT(End of Transaction)-
oder Commit-Operation umschlossen sind. Außerdem besteht die Möglichkeit
mit einer Rollback-Anweisung diese transaktion abzubrechen. Der Rechnerknoten,
der die Transaktion veranlasst, wird als Koordinator-Knoten der
Transaktion bezeichnet. Beschränken sich die Operationen einer Transaktion
auf den Koordinator spricht man von einer lokalen Transaktion wohingegen
eine globale Transaktion noch weitere Knoten einbezieht, die wir
auch Agenten nennen. An diese werden Teil- oder Sub-Transaktionen
übermittelt, welche auf dem Knoten ausgeführt werden. Die am Koordinator-
Knoten ausgeführte Teiltransaktion nennt man dann Primär-Transaktion.
Die Atomarität von Transaktionen ist ein zentrales Problem bei verteilten
Datenbanken und wird mit Hilfe von Commit-Protokollen gewährleistet.
Zwei-Phasen-Commit(2PC)
Um eine Transaktion abschließen zu können, ist es nötig zu wissen, ob alle
Subtranksaktionen erfolgreich waren und falls nicht müssen Änderungen
an sämtlichen beteiligten Knoten rückgängig gemacht werden. Für die
Lösung dieses Problems gibt es das 2PC-Protokoll zur Festschreibung von
Änderungen auf verteilten Datenbanken. Es besteht wie der Name schon
sagt aus zwei Phasen, der Prepare-Phase und der Commit/Abort-Phase.
• Prepare-Phase : Will der Koordinator eine Transaktion abschließen,
so schickt er eine Prepare-Nachricht an alle beteiligten Knoten. Diese
machen einen Vermerk in ihren lokalen Log-Dateien und antworten
mit einer Ready-Nachricht, falls ihre Subtransaktion erfolgreich war.
Andernfalls antworten sie mit einer Failed-Nachricht und beginnen
die lokalen Änderungen der Transaktion rückgängig zu machen,
da ihre Failed-Nachricht ein Zurücksetzen der gesamten globalen
Transaktion zur Folge hat.
• Commit/Abort-Phase : Der Koordinator wartet, nach dem Versandt
der Prepare-Nachrichten auf die Antworten aller Agenten.
Wenn alle mit einem Ready antworten, so waren alle Subtransaktionen
erfolgreich und die globale Transaktion kann übernommen wer-
17

den. Dazu vermerkt der Koordinator ein Commit in seiner Log-Datei
und schickt diese Nachricht an alle Agenten, die ihrerseits das Commit
in ihrer Log-Datei eintragen und die Transaktion abschliessen.
Hat jedoch mindestens ein Agent probleme bei der Ausführung der
Transaktion gehabt und mit einem Failed geantwortet, so muss die
gesamte Transaktion zurückgesetzt werden. Der Koordinator schickt
dazu eine Abort-Nachricht an alle Agenten, damit diese ihre Subtransaktionen
wieder rückgängig machen. Sowohl im Commit als
auch im Abort Fall, senden die Agenten nach einem Log-Eintrag eine
Empfangsbestätigung an den Koordinator, der nach dem Empfang
aller Bestätigungen das Ende der Transaktion in seiner Log-Datei
vermerken kann.
Im Falle eines Rechnerausfalls, kann der letzte Zustand mit den Log-
Einträgen und einer eventuellen Koordinator-Anfrage wiederhergestellt
werden. Erhält ein Agent keine Prepare-Nachricht, so entscheidet er nach
Ablauf eines Timeouts ein lokales Abort. Nach dem Versandt der READY -
Nachricht besteht die Gefahr der Blockierung, falls keine neue entsprechende
Nachricht empfangen wird. In der Entscheidung eines Abbruchs einer
Transaktion ist jeder Agent weitgehend autonom. Sobald er jedoch die
Ready-Nachricht an den Koordinator schickt, verzichtet er auf das Recht
dieser Entscheidung und willigt ein eine globale Entscheidung zu übernhemen.
Wird dem Agenten wegen eines Koordinator-Ausfalls keine Entscheidung
mitgeteilt, so kann er grundsätzlich nicht mehr entscheiden was zu machen
ist, ohne die Gefahr der System-Inkonsistenz einzugehen. Eine Hilfe bei
der Entscheidungsfindung kann es sein andere an der selben Transaktion
beteiligten Agent zu befragen, ob diese möglicherweise eine globale Anweisung
erhalten haben oder ihre Subtransaktion nicht ausführen konnten.
Vorraussetzung hierfür ist natürlich, dass die beteiligten Agent auch
bekannt sind. Grundsätzlich muß aber gewartet werden, bis der Koordinator
wieder funktionsfähig ist und das Ergebnis der Transaktion mitteilen
kann. Solange muss der Agent blockieren und darf gesperrte Resourcen
nicht wieder freigeben, um Inkonsistenzen zu vermeiden.
18

5.3 Drei-Phasen-Commit(3PC)
Eine Hauptschwäche des 2PC-Protokolls ist die starke Abhängigkeit der
Agenten vom Koordinator und die damit verbundene Blockierungen bei
einem Ausfall. Als Verbesserung entwickelten D. Skeen und M. Stonebreaker
1983 in ihrer Arbiet ”A Formal Model of Crash Recovery in a
Distributed System” das 3PC-Protokoll, welches das Blockadeproblem auf
Kosten eines gesteigerten Aufwands und zwei Annahmen abschwächt.
1. Keine Partitionierung des Netzwerks(völlig getrennte Bereiche/Cluster)
2. Höchstens K gleichzeitige Rechnerausfälle, bei N Sites mit K < N
Der Abortfall läuft genau wie beim 2PC-Protokoll ab. Erhält der Koordinator
nach dem Prepare ein Ready von allen beteiligten Agenten, so
verschickt er eine Pre-Commit-Nachricht an alle Agenten, worauf diese
mit einer Pre-Ack-Nachricht antworten müssen. Erhält der Koordinator
mindestens K Pre-Ack-Nachricht, so trifft er die Entscheidung eines Commits
und verschickt diese nach einer Protokollierung an alle Agenten. Bei
einem Koordinator-Ausfall(z.B. Timeout) während der Prozedur muss ein
neuer Koordinator ermittelt werden. Dieser fragt die Commitzustände der
verbliebenen Agenten ab und globalisiert eine gefundene Entscheidung
falls einer der Beteiligten bereits eine Commit oder eine Abort Meldung
vor dem Ausfall erhalten hat. Sollte noch keiner der Verbliebenen eine
Entscheidung erhalten haben, aber mindestens einer befindet sich im Status
Pre-Commit, dann setzt der neue Koordinator den Vorgang mit einer
neuen Serie von Pre-Commit-Nachrichten fort. Falls keiner der Agenten
zuvor ein Pre-Commit erhalten hat, so entscheidet der neue Koordinator
einen Abort und verbreitet diese Entscheidung im Netzwerk. So ist unter
den obigen Vorraussetzung gewährleistet, dass gesperrte Resourcen nach
einer bestimmten Zeit wieder freigegeben wird und eine Verbesserung im
Vergleich zum 2PC erreicht.
19

6 Fazit und Ausblick
Das Gebiet der Datenbanken ist schon relativ weit entwickelt, jedoch findet
der Paradigmenwechsel von zentralisierten zu verteilten und gar Peer-to-
Peer ähnlichen Lösungen erst jetzt statt, was die spärliche Verbreitung
kommerzieller Systeme vorallem im extrem verteilten Segment der Datenverwaltung
erklärt. Dieser Trend wird sich vorraussichtlich durch die deutlich
höhere Kosteneffektivität, geringeren Wartungsaufwand und Robustheit
verteilter Systeme sogar noch steigern. Im Bereich der Forschung sind
unter anderem auch erweiterte Transaktions und Verarbeitungskonzepte
speziell für neuere Datenbankmodelle, in denen Transaktionen Stunden
oder sogar Tage dauern können, noch zu entwerfen. Die Entwicklung zuverlässiger
Recovery-Strategien in solchen Systemen ist eine der Aufgaben,
die bislang noch ungelöst sind und begrenzen dadurch den Einsatz in kommerziellen
Systemen.
20

Literatur
[1] Peter Dadam. Verteilte Datenbanken und Client/Server-Systeme.
Springer-Verlag, 1996.
[2] Andreas Heuer Gunter Saake, Kai-Uwe Sattler. Datenbanken -
Konzepte und Sprachen. mitp, 2008.
[3] Patrick Valduriez M. Tamer Ãszu. Principles of Distributed Database
Systems. Springer-Verlag, 1996.
[4] Andreas Reuter Theo Haerder. Principles of transaction-oriented
database recovery, 1983.
21