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 2.1 Datenbanksysteme . . . . . . . 2.1.1 Relationale Datenbanken 2.1.2 Operationen . . . . . . . 2.1.3 Transaktionen . . . . . . 2.2 Rechnernetze . . . . . . . . . . . . . . . 3 3 4 5 6 8 3 Architektur verteilter Datenbanksysteme 3.1 Katalog des Systems . . . . . . . . . . . . . . . . . . . . . 3.2 Fragmentierung und Allokation . . . . . . . . . . . . . . . 3.3 Klassifikation nach Verteilungsgrad . . . . . . . . . . . . . 9 10 11 12 4 Umsetzung einiger Konzepte 4.1 Client/Server-Datenbanksysteme . . . . . . . . . . . . . . 4.1.1 Funktional gleichgestellte DBS . . . . . . . . . . . . 14 14 15 5 Anfragebearbeitung und Transaktionsverwaltung 5.1 Anfragebearbeitung . . . . . . . . . . . . . . . . . . . . . . 5.2 Transaktionsverwaltung . . . . . . . . . . . . . . . . . . . 5.3 Drei-Phasen-Commit(3PC) . . . . . . . . . . . . . . . . . . 16 16 17 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(A1 , . . . , An ) und B(B1 , . . . , Bn ) auf Grundlage eines passenden Vergleichsoperators 5 θ : Domain(Ai ) × Domain(Bj ) → bool liefert, für fest gewählte i, j ∈ {1, . . . , n}, die Menge der Tupel {a ∪ b | a ∈ Ai ∧ b ∈ Bj ∧ θ(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 ObjecktorientierteDatenbankmodelle, 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. ΠKN R,N ame,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 DatenbankObjekten, 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 GlobalenKonzeptionellen-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 KoordinatorKnoten 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 wer17 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 LogEinträ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-toPeer ä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. Konzepte und Sprachen. mitp, 2008. Datenbanken - [3] Patrick Valduriez M. Tamer Ãszu. Principles of Distributed Database Systems. Springer-Verlag, 1996. [4] Andreas Reuter Theo Haerder. database recovery, 1983. 21 Principles of transaction-oriented