Die Präsentation wird geladen. Bitte warten

Die Präsentation wird geladen. Bitte warten

Verteilte Datenbanken Geographisch verteilte Organisationsform einer Bank mit ihren Filialen Filialen sollen Daten lokaler Kunden lokal bearbeiten können.

Ähnliche Präsentationen


Präsentation zum Thema: "Verteilte Datenbanken Geographisch verteilte Organisationsform einer Bank mit ihren Filialen Filialen sollen Daten lokaler Kunden lokal bearbeiten können."—  Präsentation transkript:

1 Verteilte Datenbanken Geographisch verteilte Organisationsform einer Bank mit ihren Filialen Filialen sollen Daten lokaler Kunden lokal bearbeiten können Zentrale soll Zugriff auf alle Daten haben (z.B. für Kontostands ü berpr ü fung bei Kreditvergabe) Szenario:

2 2 Terminologie Sammlung von Informationseinheiten (Knoten, Stationen), verteilt auf mehreren Rechnern, verbunden mittels Kommunikationsnetz nach Ceri & Pelagatti (1984) Kooperation zwischen autonom arbeitenden Stationen, zur Durchführung einer globalen Aufgabe

3 3 Kommunikationsmedien LAN: local area network, z.B. Ethernet, Token-Ring oder FDDI-Netz WAN: wide area network, z.B. das Internet Point-to-Point: z.B. Verbindungen ü ber ISDN oder analoge Modem-Verbindungen Hier: Kommunikationsmedium f ü r verteiltes DBMS transparent. Jede Station kann mit jeder kommunizieren. Dabei werden u.U. signifikant unterschiedliche Kosten (Zeiten) beobachtet.

4 4 Verteiltes Datenbanksystem Kommunikations- netz Station S 1 Station S 2 Station S 3

5 5 Client-Server-Architektur VDBMS Kommunikations- netz Client C 1 Client C 2 Server

6 6 Aufbau und Entwurf eines verteilten Datenbanksystems globales Schema Fragmentierungs- schema Zuordnungsschema lokales Schema lokales Schema lokales DBMS lokales DBMS lokale DB lokale DB Station S 1 Station S n... Ausganspunkt Zerlegung von Rel.s in (disjunkte) Fragmente Allokation von Rel.s zu Stationen

7 7 Fragmentierung und Allokation einer Relation Fragmentierung von Relationen: Fragmente enthalten Daten mit gleichem Zugriffsverhalten, um Kommunikationskosten zu minimieren ( Informationen ü ber den zu erwartenden Workload sind notwendig) Allokation: Fragmente werden den VDBMS-Stationen zugeordnet: Redundanzfreie Allokation: jedes Fragment ist genau einer Station zugeordnet Mit Replikation: Ein Fragment wird redundant auf mehreren Stationen verwaltet (N:M-Zuordnung, s. n ä chste Folie).

8 8 R2R2 R3R3 R1R1 R3R3 R3R3 R2R2 R1R1 R3R3 R2R2 R1R1 R1R1 R1R1 R2R2 R Fragmentierung Allokation (Zuordnung) Station S 1 Station S 3 Station S 2

9 9 Fragmentierung Horizontale Fragmentierung: Zerlegung der Relation in disjunkte Tupelmengen Vertikale Fragmentierung: Zusammenfassung von Attributen mit gleichem Zugriffsmuster Extreme vertikale Fragmentierung: alle Relationen bin ä r (zweispaltig) Vorlesung im WS 06/07 Kombinierte Fragmentierung: Anwendung horizontaler und vertikaler Fragmentierung auf dieselbe Relation

10 10 Anforderungen an das Fragmentierungsschema Rekonstruierbarkeit Jede fragmentierte Relation l äß t sich ohne Informationsverlust aus den Fragmenten wiederherstellen. Vollständigkeit Jedes Datum (Tupel, Attribut) ist einem Fragment zugeordnet. (Voraussetzung f ü r Rekonstruierbarkeit.) Disjunktheit Ein Datum ist nicht mehreren Fragmenten zugeordnet.

11 11 Beispielrelation "Professoren" Professoren PersNrNameRangRaumFakultätGehaltSteuerklasse 2125SokratesC4226Philosophie RusselC4232Philosophie KopernikusC3310Physik PopperC352Philosophie AugustinusC3309Theologie CurieC436Physik KantC47Philosophie980001

12 12 Horizontale Fragmentierung Abstrakte Darstellung: Für zwei Prädikate p 1 und p 2 ergeben sich 4 Fragmente: n Zerlegungsprädikate p 1,...,p n ergeben 2 n Fragmente R R1R1 R2R2 R3R3 R1 := p 1 p 2 (R) R2 := p 1 p 2 (R) R3 := p 1 p 2 (R) R4 := p 1 p 2 (R)

13 13 Sinnvolle Gruppierung der Professoren nach Fakultät: 3 Zerlegungsprädikate: p 1 (Fakultät = 'Theologie') p 2 (Fakultät = 'Physik') p 3 (Fakultät = 'Philosophie') TheolProfs´ := σ p1 p2 p3 (Professoren) = σ p1 (Professoren) PhysikProfs´ := σ p1 p2 p3 (Professoren) = σ p2 (Professoren) PhiloProfs´ := σ p1 p2 p3 (Professoren) = σ p3 (Professoren) AndereProfs´:= σ p1 p2 p3 (Professoren) =

14 14 Abgeleitete horizontale Fragmentierung Beispiel: Vorlesungen aus dem Universitätsschema: Zerlegung in Gruppen mit gleicher SWS-Zahl 2SWSVorls := σ SWS=2 (Vorlesungen) 3SWSVorls := σ SWS=3 (Vorlesungen) 4SWSVorls := σ SWS=4 (Vorlesungen) Für Anfragebearbeitung u.U. schlechte Zerlegung Die Fragmentierung verschiedener Relationen ist nicht beliebig und hat Einfluß auf die Anfragebearbeitung.

15 15 SELECT Titel, Name FROM Vorlesungen, Professoren WHERE gelesenVon = PersNr; resultiert in: Titel, Name ((TheolProfs´ 2SWSVorls) (TheolProfs´ 3SWSVorls) … (PhiloProfs´ 4SWSVorls) ) Join-Graph zu dieser Anfrage: TheolProfs´ PhysikProfs´ PhiloProfs´ 2SWSVorls 3SWSVorls 4SWSVorls

16 16 Einschub: Join-Arten natürlicher Join L ABC a1a1 b1b1 c1c1 a2a2 b2b2 c2c2 R CDE c1c1 d1d1 e1e1 c3c3 d2d2 e2e2 = Resultat ABCDE a1a1 b1b1 c1c1 d1d1 e1e1

17 17 Einschub: Join-Arten (Semi-Joins) L ABC a1a1 b1b1 c1c1 a2a2 b2b2 c2c2 R CDE c1c1 d1d1 e1e1 c3c3 d2d2 e2e2 Resultat CDE c1c1 d1d1 e1e1 = Semi-Join von R mit L (Right Semi-Join) L ABC a1a1 b1b1 c1c1 a2a2 b2b2 c2c2 R CDE c1c1 d1d1 e1e1 c3c3 d2d2 e2e2 = Semi-Join von L mit R (Left Semi-Join) Resultat ABC a1a1 b1b1 c1c1

18 18 Lösung: abgeleitete Fragmentierung TheolProfs´ PhysikProfs´ PhiloProfs´ TheolVorls PhysikVorls PhiloVorls TheolVorls := Vorlesungen gelesenVon=PersNr TheolProfs ´ PhysikVorls := Vorlesungen gelesenVon=PersNr PhysikProfs ´ PhiloVorls := Vorlesungen gelesenVon=PersNr PhiloProfs ´ Titel, Name ((TheolProfs´ p TheolVorls) (PhysikProfs´ p PhysikVorls) (PhiloProfs´ p PhiloVorls) ) mit p (PersNr = gelesenVon)

19 19 Vertikale Fragmentierung Abstrakte: Vertikale Fragmentierung einer Relation R mit Prim ä rschl ü ssel : R1R1 R2R2 R κ

20 20 Vertikale Fragmentierung Jedes Fragment enthält den Primärschlüssel der Originalrelation. Aber: Verletzung der Disjunktheit. Surrogat Jedem Tupel der Originalrelation wird ein eindeutiges Surrogat (= künstlich erzeugter Tupelidentifikator) zugeordnet, welches in jedes vertikale Fragment des Tupels mit aufgenommen wird. Beliebige vertikale Fragmentierung gewährleistet keine Rekonstruierbarkeit. Mögliche Ansätze, um Rekonstruierbarkeit zu garantieren:

21 21 Vertikale Fragmentierung (Beispiel) Für die Universitätsverwaltung sind PersNr, Name, Gehalt und Steuerklasse interessant: ProfVerw := PersNr, Name, Gehalt, Steuerklasse (Professoren) Für Lehre und Forschung sind dagegen PersNr, Name, Rang, Raum und Fakultät von Bedeutung: Profs := PersNr, Name, Rang, Raum, Fakultät (Professoren) Rekonstruktion der Originalrelation Professoren: Professoren = ProfVerw ProfVerw.PersNr = Profs.PersNr Profs

22 22 Kombinierte Fragmentierung a) a) Horizontale Fragmentierung nach vertikaler Fragmentierung: b) b) Vertikale Fragmentierung nach horizontaler Fragmentierung: R1R1 R2R2 R 21 R R 22 R 23 R R1R1 R2R2 R3R3 R 32 R 31

23 23 Rekonstruktion nach kombinierter Fragmentierung a) Fall a) R = R 1 R 1. = R 2. (R 21 R 22 R 23 ) b) Fall b) R = R 1 R 2 (R 31 R 31. = R 32. R 32 )

24 24 Baumdarstellung der Fragmentierungen (Beispiel) v hh ProfsProfVerw PhysikProfsTheolProfsPhiloProfs Vorlesungen PhysikVorlsTheolVorlsPhiloVorls Professoren abgeleitete Fragmentierung

25 25 Allokation (Beispiel) Ein Fragment kann prinzipiell mehreren Stationen zugeordnet werden (Replikation). Allokation für unser Beispiel jedoch ohne Replikation redundanzfreie Zuordnung. Station S Verw S Physik S Philo S Theol Bemerkung Verwaltungsrechner Dekanat Physik Dekanat Philosophie Dekanat Theologie zugeordnete Fragmente {ProfVerw} {PhysikVorls, PhysikProfs} {PhiloVorls, PhiloProfs} {TheolVorls, TheolProfs}

26 26 Transparenz in verteilten Datenbanken Transparenz: Grad der Unabhängigkeit den ein VDBMS dem Benutzer/Client-Programmen beim Zugriff auf verteilte Daten vermittelt. Transparenzgrade (abnehmende Transparenz): Fragmentierungstransparenz Alle Aspekte der Verteilung verborgen, Nutzer arbeiten mit globalem Schema Allokationstransparenz Fragmentierung der Relationen sichtbar, Verteilung auf Stationen verborgen Lokale Schema-Transparenz Operationen adressieren Fragmente und Stationen explizit

27 27 Fragmentierungstransparenz Beispiel (Fragmente/Stationen nicht explizit adressiert): SELECT Titel, Name FROM Vorlesungen, Professoren WHERE gelesenVon = PersNr; Beispiel für eine Änderungsoperation: UPDATE Professoren SET Fakultät = "Theologie" WHERE Name = "Sokrates"; Welche Operation(en) muß das VDBMS intern ausf ü hren, um die UPDATE-Anweisung zu realisieren?

28 28 Fragmentierungstransparenz (cont.) 1.Im betroffenen Fragment: Ändern des Attributwertes von Fakultät. 2.Transferieren des Sokrates-Tupels aus Fragment PhiloProfs in das Fragment TheolProfs (= Löschen aus PhiloProfs, Einfügen in TheolProfs). 3.Ändern der abgeleiteten Fragmentierung von Vorlesungen (= Einfügen der von Sokrates gehaltenen Vorlesungen in TheolVorls, Löschen der von ihm gehaltenen Vorlesungen aus PhiloVorls).

29 29 Allokationstransparenz Benutzer müssen Fragmentierung kennen, aber nicht die Station(en) eines Fragmentes: Beispiel: SELECT Gehalt FROM ProfVerw WHERE Name = "Sokrates"; Fragmentname!

30 30 Allokationstransparenz (cont.) Unter Umständen m ü ssen Originalrelationen erst rekonstruiert werden. Beispiel: Verwaltung möchte wissen, wieviel die C4-Professoren der Theologie insgesamt verdienen? Da Fragmentierungstransparenz fehlt, muß die Anfrage folgendermaßen formuliert werden: SELECT SUM (Gehalt) FROM ProfVerw, TheolProfs WHERE ProfVerw.PersNr = TheolProfs.PersNr AND Rang = "C4";

31 31 Lokale Schema-Transparenz Der Benutzer muss jetzt auch noch die Station kennen, auf der ein Fragment liegt. Beispiel: SELECT Name FROM TheolProfs AT S Theol WHERE Rang = "C3";

32 32 Lokale Schema-Transparenz (cont.) Ist hier überhaupt noch Transparenz gegeben? Lokale Schema-Transparenz setzt voraus, dass alle Rechner dasselbe Datenmodell und dieselbe Anfragesprache verwenden. Vorherige Anfrage kann somit analog auch an Station S Philo ausgeführt werden. Dies ist nicht möglich bei Kopplung unterschiedlicher DBMS. Multi-Database-Systems Verwendung grundsätzlich verschiedener Datenmodelle auf lokalen DBMS nennt man Multi-Database-Systems. Oft unumgänglich in realen (unternehmensweiten) Applikationen.

33 33 Anfrageübersetzung und Anfrageoptimierung Annahme: Es liegt Fragmentierungstransparenz vor Anfragen werden gegen das globale Schema/die globalen Relationen formuliert Aufgabe des Anfrageübersetzers: Generierung eines Anfrageauswertungsplans auf den Fragmenten Aufgabe des Anfrageoptimierers: Generierung eines möglichst effizienten Auswertungsplanes abhängig von der Allokation der Fragmente auf den verschiedenen Stationen des Rechnernetzes

34 34 Anfragebearbeitung bei horizontaler Fragmentierung Übersetzung einer SQL-Anfrage auf dem globalen Schema in eine äquivalente Anfrage auf den Fragmenten benötigt 2 Schritte: 1.Rekonstruktion aller in der Anfrage vorkommenden globalen Relationen aus den Fragmenten, in die sie während der Fragmentierungsphase zerlegt wurden. Hierfür erhält man einen algebraischen Ausdruck. 2.Kombination des Rekonstruktionsausdrucks mit dem algebraischen Anfrageausdruck, der sich aus der Übersetzung der SQL-Anfrage ergibt.

35 35 Beispiel SELECT Titel FROM Vorlesungen, Profs WHERE gelesenVon = PersNr AND Rang = "C4"; Der entstandene algebraische Ausdruck heißt kanonische Form der Anfrage: Π Titel σ Rang="C4" gelesenVon=PersNr TheolVorlsPhiloVorlsPhysikVorlsTheolProfsPhiloProfsPhysikProfs

36 36 Algebraische Äquivalenzen Für eine effizientere Abarbeitung der Anfrage benutzt der Anfrageoptimierer die folgende Eigenschaft: (R 1 R 2 ) p (S 1 S 2 ) = (R 1 p S 1 ) (R 1 p S 2 ) (R 2 p S 1 ) (R 2 p S 2 ) Die Verallgemeinerung auf n horizontale Fragmente R 1,...,R n von R und m Fragmente S 1,...,S m von S ergibt: (R 1... R n ) p (S 1... S m ) = (R i p S j ) 1 i n 1 j m Falls gilt: S i = S p R i mit S = S i... S n, dann tragen die Joins R i p S j für i j nichts Neues zum Join-Ergebnis bei. (Achtung: Fehler im Buch!)

37 37 Algebraische Äquivalenzen (Forts.) Für eine derartig abgeleitete horizontale Fragmentierung von S gilt somit: (R 1... R n ) p (S 1... S m ) = (R 1 p S 1 ) (R 2 p S 2 )... (R n p S n )

38 38 Algebraische Äquivalenzen (Forts.) Für eine derartig abgeleitete horizontale Fragmentierung von S gilt somit: (R 1... R n ) p (S 1... S m ) = (R 1 p S 1 ) (R 2 p S 2 )... (R n p S n ) Noch einmal das konkrete Beispiel: (TheolVorls PhysikVorls PhiloVorls) (TheolProfs PhysikProfs PhiloProfs) Um Selektionen und Projektionen über hinweg "nach unten zu drücken" (push down) benötigt man folgende Ä quivalenzen: σ p (R 1 R 2 ) = σ p (R 1 ) σ p (R 2 ) L (R 1 R 2 ) = L (R 1 ) L (R 2 )

39 39 Optimale Form der Anfrage Die Anwendung dieser algebraischen Regeln generiert den folgenden Auswertungsplan: Π Titel gelesenVon=PersNr σ Rang=C4 TheolVorlsTheolProfs PhysikVorlsPhysikProfsPhiloVorlsPhiloProfs Auswertungen können lokal auf den Stationen S Theol, S Physik und S Philo ausgeführt werden Stationen können parallel abarbeiten und lokales Ergebnis voneinander unabhängig an die Station, die die abschliessende Vereinigung durchführt, übermitteln.

40 40 Anfragebearbeitung bei vertikaler Fragmentierung Beispiel: SELECT Name, Gehalt FROM Professoren WHERE Gehalt > 80000; Kanonischer Auswertungsplan: Π Name, Gehalt σ Gehalt>80000 TheolProfsPhysikProfsPhiloProfs ProfVerw

41 41 Optimierung bei vertikaler Fragmentierung Für unser Beispiel gilt: Alle notwendigen Informationen sind in ProfVerw enthalten Der Teil mit Vereinigung und Join kann "abgeschnitten" werden. Das ergibt den folgenden optimierten Auswertungsplan: Π Name, Gehalt σ Gehalt>80000 ProfVerw Beispiel für eine schlecht zu optimierende Anfrage: (Attribut Rang fehlt in ProfVerw) SELECT Name, Gehalt, Rang FROM Professoren WHERE Gehalt > 80000;

42 42 Der natürliche Verbund zweier Relationen R und S R ABC a1a2a3a4a5a6a7a1a2a3a4a5a6a7 b1b2b3b4b5b6b7b1b2b3b4b5b6b7 c1c2c1c2c3c2c6c1c2c1c2c3c2c6 S CDE c1c3c4c5c7c8c5c1c3c4c5c7c8c5 d1d2d3d4d5d6d7d1d2d3d4d5d6d7 e1e2e3e4e5e6e7e1e2e3e4e5e6e7 R S CDE AB a1a3a5a1a3a5 b1b3b5b1b3b5 c1c1c3c1c1c3 d1d1d2d1d1d2 e1e1e2e1e1e2 =

43 43 Join-Auswertung in VDBMS Spielt eine kritischere Rolle als in zentralisierten Datenbanken Problem: Argumente eines Joins zweier Relationen können auf unterschiedlichen Stationen des VDBMS liegen Zwei Möglichkeiten zur Realisierung: Join-Auswertung mit und ohne Filterung

44 44 Betrachtung des allgemeinsten Falles: Join-Auswertung in VDBMS Äußere Argumentrelation R ist auf Station St R gespeichert Innere Argumentrelation S ist der Station St S zugeordnet Ergebnis der Joinberechnung wird auf einer dritten Station St Result benötigt

45 45 Join-Auswertung ohne Filterung Nested-Loops Transfer einer Argumentrelation Transfer beider Argumentrelationen Ziel: Einsatz etablierter Join-Verfahren aus zentralisierten DBMS:

46 46 Nested Loops Iteration durch die äußere Relation R mittels Laufvariable r und Anforderung (über Kommunikationsnetz bei St S ) der zu jedem Tupel r passenden Tupel s S mit r.C = s.C Diese Vorgehensweise benötigt pro Tupel aus R eine Anforderung und eine passende Tupelmenge aus S (welche bei vielen Anforderungen leer sein könnte) es werden 2 R Nachrichten benötigt Hohes Nachrichtenaufkommen, das sich nur in LANs verantworten l äß t.

47 47 Der natürliche Verbund zweier Relationen R und S R ABC a1a2a3a4a5a6a7a1a2a3a4a5a6a7 b1b2b3b4b5b6b7b1b2b3b4b5b6b7 c1c2c1c2c3c2c6c1c2c1c2c3c2c6 S CDE c1c3c4c5c7c8c5c1c3c4c5c7c8c5 d1d2d3d4d5d6d7d1d2d3d4d5d6d7 e1e2e3e4e5e6e7e1e2e3e4e5e6e7

48 48 Alternative 1: Transfer einer Argumentrelation Vollständiger Transfer einer Argumentrelation (z.B. R) zum Knoten der anderen Argumentrelation Ausnutzung eines möglicherweise auf S.C existierenden Indexes auf Station St S 1.2.

49 49 Alternative 2: Transfer beider Argumentrelationen Transfer beider Argumentrelationen zum Rechner St Result Berechnung des Ergebnisses auf dem Knoten St Result mittels a) a) Merge-Join (bei vorliegender Sortierung) oder b) b) Hash-Join (bei fehlender Sortierung) evtl. Verlust der vorliegenden Indexe (auf St R und/oder St S ) für die Join-Berechnung aber kein Verlust der Sortierung der Argumentrelation(en)

50 50 Join-Auswertung mit Filterung Verwendung des Semi-Join-Operators zur Vorfilterung Schlüsselidee: transferiere nur die Tupel, die passenden tats ä chlich einen Join-Partner finden werden Benutzung der folgenden algebraischen Eigenschaften: R S = R (R S) R S = Π C (R) S (Join-Attribut in Relation R ist C) Bisher: Transfer potentiell gro ß er Datenmengen, auch falls Resultat der Join-Operation selbst sehr klein ist (hohe Selektivit ä t). Daher:

51 51 Join-Auswertung mit Filterung (Beispiel, Filterung der Relation S) Transfer der unterschiedlichen C-Werte von R (= Π C (R) ) nach St S Auswertung des Right-Semi-Joins R S = Π C (R) S auf St S und Transfer des Ergebnisses nach St R Auswertung des Joins auf St R, der nur diese transferierten Ergebnistupel des Semi-Joins braucht Transferkosten werden nur reduziert, wenn gilt: Π C (R) + R S < S mit = Größe (in Byte) einer Relation

52 52 R ( Π C (R) S) CDE AB a1a3a5a1a3a5 b1b3b5b1b3b5 c1c1c3c1c1c3 d1d1d2d1d1d2 e1e1e2e1e1e2 R ABC a1a2a3a4a5a6a7a1a2a3a4a5a6a7 b1b2b3b4b5b6b7b1b2b3b4b5b6b7 c1c2c1c2c3c2c6c1c2c1c2c3c2c6 C c1c2c3c6c1c2c3c6 S CDE c1c3c4c5c7c8c5c1c3c4c5c7c8c5 d1d2d3d4d5d6d7d1d2d3d4d5d6d7 e1e2e1e2e3e2e6e1e2e1e2e3e2e6 15 Attributwerte... Π C (R) S CDE c1c3c1c3 d1d2d1d2 e1e2e1e2 ΠCΠC St R St Result St S 4 Attributwerte 6 Attributwerte Auswertung des Joins R A S mit Semi-Join-Filterung von S

53 53 Alternative Auswertungungspläne 1. Alternative:... ΠCΠC St R St Result St S RS 2. Alternative: (R Π C (S)) ( Π C (R) S)

54 54 Parameter für die Kosten eines VBMDS-Auswertungsplans Kardinalitäten von Argumentrelationen Selektivitäten von Joins und Selektionen + Transferkosten für Datenkommunikation: Verbindungsaufbau + Datenvolumen (CPU-)Auslastung der einzelnen VDBMS-Stationen Effektive Anfrageoptimierung muss auf Basis eines Kosten- modells durchgeführt werden und soll mehrere Alternativen für unterschiedliche Auslastungen des VDBMS erzeugen.

55 55 Transaktionskontrolle in VDBMS Globale Transaktionen können sich bei VDBMS über mehrere Rechnerknoten erstrecken. Recovery: Redo: Wenn eine Station nach einem Fehler wieder anläuft, müssen alle Änderungen einmal abgeschlossener Transaktionen - seien sie lokal auf dieser Station oder global über mehrere Stationen ausgeführt worden - auf den an dieser Station abgelegten Daten wiederhergestellt werden. Undo: Die Änderungen noch nicht abgeschlossener lokaler und globaler Transaktionen müssen auf den an der abgestürzten Station vorliegenden Daten rückgängig gemacht werden.

56 56 EOT-Behandlung in VDBMS commit: globale Transaktion wird an allen (relevanten) lokalen Stationen festgeschrieben Die EOT (End-of-Transaction)-Behandlung von globalen Transaktionen stellt in VDBMS eine Herausforderung dar. Eine globale Transaktion muss atomar beendet werden, d.h. entweder abort:globale Transaktion wird an allen (relevanten) Stationen nicht festgeschrieben oder Problem in verteilter Umgebung, da die Stationen eines VDBMS unabhängig voneinander "abstürzen" können

57 57 Problemlösung: Two-Phase-Commit-Protokoll (2PC) Das 2PC-Verfahren wird von der sog. Koordinator- StationK überwacht. 2PC gewährleistet, dass die n Agenten (= Stationen im VDBMS) A 1,…A n, die an einer Transaktion beteiligt waren, entweder alle von Transaktion T geänderten Daten festschreiben oder alle Änderungen von T rückgängig machen. Gewährleistet die Atomarität der EOT-Behandlung in VDBMS

58 58 Nachrichtenaustausch beim 2PC-Protokoll (für 4 Agenten) KK A1A1 A2A2 A3A3 A4A4 K A1A1 A2A2 A3A3 A4A4 PREPAREFAILED/READYCOMMIT/ABORTACK 4 Messages? Phase 1Phase 2

59 59 Ablauf der EOT-Behandlung beim 2PC-Protokoll K schickt allen Agenten eine PREPARE-Nachricht, um herauszufinden, ob sie Transaktionen festschreiben können Jeder Agent A i empfängt PREPARE-Nachricht und schickt eine von zwei möglichen Nachrichten an K: Hat K von allen n Agenten A 1,...,A n ein READY erhalten, kann K ein COMMIT an alle Agenten schicken mit der Aufforderung, die Änderungen von T lokal festzuschreiben; antwortet einer der Agenten mit FAILED od. gar nicht innerhalb einer bestimmten Zeit (timeout), schickt K ein ABORT an alle Agenten und diese machen die Änderungen der Transaktion rückgängig Haben die Agenten ihre lokale EOT-Behandlung abgeschlossen, schicken sie eine ACK-Nachricht (= acknowledgement, Bestätigung) an K. READY, falls A i in der Lage ist, die Transaktion T lokal festzuschreiben FAILED, falls A i kein commit durchführen kann (wegen Fehler, Inkonsistenz etc.)

60 60 Zustandsübergang beim 2PC-Protokoll: Koordinator Initial Abgebrochen Bereit Fertig Festschreibend EOT : Alle an T beteiligen Agenten im Log protokollieren sende PREPARE an Agenten READY von allen Agenten empfangen: (T,commit) ins Log sende COMMIT Timeout oder 1 x FAILED empfangen: (T,abort) ins Log ABORT senden von allen ACK empfangen: " Bullet" = wichtigste Aktion(en) (T,terminated) ins Log

61 61 Zustandsübergang beim 2PC-Protokoll: Agent Wartend Bereit AbgebrochenFestgeschrieben COMMIT empfangen: (T,commit) ins Log sende ACK ABORT empfangen: (T,abort) ins Log sende ACK PREPARE empfangen und lokal alles okay: Log-Einträge f ü r T schreiben (T,ready) ins Log sende READY Timeout od. PREPARE empfangen und lokaler Fehler entdeckt: (T,abort) ins Log sende FAILED (verspätetes) PREPARE empfangen: sende FAILED " Bullet" = wichtigste Aktion(en) Ab hier: Agent verpflichtet sich, T erfolgreich zu beenden

62 62 Blockierung eines Agenten 2PC birgt die Gefahr der Blockierung der Agenten: Agent befindet sich im Zustand Bereit (hat sich also verpflichtet, T erfolgreich zu beenden) Agent wartet vergeblich auf COMMIT/ABORT - Entscheidung durch K Timeout 1.Versuche globale COMMIT -Entscheidung bei K nachzufragen (Kommunikationsfehler?) 2.Ist 1. erfolglos (K abgest ü rzt?), erfrage COMMIT- Entscheidung bei weiteren Agenten A oder erfrage, ob A mit FAILED geantwortet hat 3.Ist auch 2. erfolglos, wird der Agent blockiert, bis K wieder funktionsf ä hig ist und die COMMIT -Entscheidung nachholt

63 63 Crash-Recovery in Agenten-Knoten Inspiziere den lokalen Log des Agenten, um nach Wiederanlauf die Recovery zu steuern: Ist auf dem Log ein Eintrag (T, commit) vorhanden, war T bereits erfolgreich beendet. REDO(T) anstossen, um Ä nderungen, die ausfallbedingt verloren gingen, nachzuholen. Ist Eintrag (T, abort) vorhanden, war T zur R ü cksetzung vorgesehen. Durch UNDO(T) alle Ä nderungen durch T an der Datenbank zur ü cknehmen. Ist Eintrag (T, ready) vorhanden, fehlte zum Absturzzeitpunkt die COMMIT -Entscheidung von K. Entscheidung bei K nachfragen (K h ä lt diese Information noch, da nicht alle ACK -Messages von allen Agenten eingetroffen).

64 64 Crash-Recovery im Koordinator Koordinator K untersucht seinen lokalen Log: Ist (T,terminated) im Log, stoße lediglich lokales UNDO(T)/REDO(T) an, je nachdem ob (T,abort) oder (T,commit) zuvor im Log gefunden wird Ist (T,abort) im Log, f ü hre lokal ein UNDO(T) aus. Sende ABORT an alle Agenten, die bisher noch kein ACK signalisiert haben. Ist (T,commit) im Log, f ü hre lokal REDO(T) aus. Sende COMMIT an alle Agenten, die bisher noch kein ACK signalisiert haben. Setze im jeweils durch den Log signalisierten Zustand fort.

65 65 Lineare Organisationsform beim 2PC-Protokoll KA1A1 A2A2 A3A3 FAILED/READY COMMIT/ABORT COMMIT -Entscheidung wird sequentiell zwischen den Agenten Kommuniziert: 2PC-Phase 1: Vorw ä rtskommunikation 2PC-Phase 2: Komm.sequenz in umgekehrter Reihenfolge ACK

66 66 Mehrbenutzersynchronisation in VDBMS Serialisierbarkeit (kontrollierte und konsistente Verzahnung von DBMS- Operationen: Zyklen im Serialisierbarkeitsgraphen?) Zwei-Phasen-Sperrprotokoll in VDBMS lokale Sperrverwaltung an jeder Station globale Sperrverwaltung

67 67 Serialisierbarkeit Lokale Serialisierbarkeit an jeder der an den Transaktionen beteiligten Stationen reicht nicht aus. Deshalb muß man bei der Mehrbenutzersynchronisation auf globaler Serialisierbarkeit bestehen. Beispiel (lokal serialisierbare Historien): SchrittT1T1 T2T SchrittT1T1 T2T r(A) w(A) w(B) r(B) S1S1 S2S2 T 1 T 2

68 68 Lokale Sperrverwaltung Globale Transaktion muß vor Zugriff/Modifikation eines Datums A, das auf Station S liegt, eine Sperre vom Sperrverwalter der Station S erwerben Verträglichkeit der angeforderten Sperre (Shared, eXclusive) mit bereits existierenden Sperren kann lokal entschieden werden Favorisiert lokale Transaktionen, da diese nur mit ihrem lokalen Sperrverwalter kommunizieren müssen

69 69 Globale Sperrverwaltung Zentraler Sperrverwalter kann zum Engpass des VDBMS werden, besonders bei einem Absturz der Sperrverwalter- Station Verletzung der lokalen Autonomie der Stationen, da auch lokale Transaktionen ihre Sperren bei der zentralisierten Sperrverwaltung anfordern müssen Alle Transaktionen fordern alle Sperren an einer einzigen, ausgezeichneten Station (Koordinator) an. Nachteile: Zentrale Sperrverwaltung i.a. nicht akzeptabel

70 70 Deadlocks in VDBMS Erkennung von Deadlocks (Verklemmungen) Zentralisierte Deadlock-Erkennung: Dezentrale (verteilte) Deadlock-Erkennung: schwierig Vermeidung von Deadlocks

71 71 Ein "Verteilter Deadlock" SchrittT1T1 T2T BOT lockS(A) r(A) lockX(A) S1S1 SchrittT1T1 T2T lockS(B) BOT lockX(B) w(B) S2S2 Lokal ist jeweils keine Deadlock-Situation zu erkennen Der globale Waits-for-Graph ist jedoch zyklisch

72 72 Erkennung von verteilten Deadlocks : Timeout Betroffene Transaktion T wird nach Erreichen einer nicht mehr akzeptablen Wartezeit zurückgesetzt und alle Sperren freigegeben. Dann T erneut starten einfach zu realisieren Problem: Richtige Wahl des Timeout-Intervalls: zu lang schlechte Ausnutzung der Systemressourcen, Stationen sind f ü r signifikante Zeit "idle" zu kurz Deadlock-Behandlung initiiert, obwohl keine Verklemmung vorliegt

73 73 Erkennung von verteilten Deadlocks : Zentralisiert Stationen melden lokal vorliegende Wartebeziehungen an neutralen Knoten, der daraus globalen Wartegraphen aufbaut (Zyklus im Graphen Deadlock) sichere Lösung Nachteile: hoher Aufwand (viele Nachrichten) Entstehung von Phantom-Deadlocks durch gegenseitiges "Überholen" von Nachrichten im Kommunikationssystem

74 74 Erkennung von verteilten Deadlocks : Dezentral F ü hre lokale Wartegraphen an den einzelnen Stationen Erkennen von lokalen Deadlocks: Erkennung globaler Deadlocks: Jeder lokale Wartegraph hat einen Knoten External, der stationenübergreifenden Wartebeziehungen zu externen Subtransaktionen repr ä sentiert Zuordnung jeder Transaktion zu einem Heimatknoten (Station, auf der BOT ausgef ü hrt wurde), von wo aus externe Subtransaktionen auf anderen Stationen initiiert werden

75 75 Dezentrale Deadlock-Erkennung: External External T 2 *) External T 1 T 1 External T 2 External *) Lies: Externe Transaktionen k ö nnen potentiell aufgrund von T 2 auf S 1 gesetzten Locks blockieren. SchrittT1T1 T2T BOT lockS(A) r(A) lockX(A) S1S1 SchrittT1T1 T2T lockS(B) BOT lockX(B) w(B) S2S2

76 76 Beispiel: S 1 Heimatknoten von T 1, S 2 Heimatknoten von T 2 Wartegraphen (Zyklus mit External = potentieller Deadlock): S1:S1: External T 2 T 1 External S2:S2: External T 1 T 2 External S2:S2: T 1 T 2 T 1 T 2 T 1 T 2 S 1 sendet Wartegraphen an die Station, auf der T 1 eine Teiltransaktion angestoßen hat (hier: S 2 ). S 2 kann globalen Deadlock (Zyklus ohne External) erkennen. S 2 w ä hlt eine Opfer-Transaktion, setzt diese zur ü ck und l ö st damit den Deadlock auf.

77 77 Deadlock-Vermeidung Optimistische Mehrbenutzersynchronisation: Nach Abschluss der Transaktionsbearbeitung auf lokalen Kopien wird Validierung (alles serialisierbar?) durchgeführt Zeitstempel-basierende Synchronisation: Zuordnung eines Lese-/Schreib-Stempels zu jedem Datum entscheidet, ob beabsichtigte Operation durchgeführt werden kann ohne Serialisierbarkeit zu verletzen oder ob Transaktion abgebrochen wird (abort) Deadlock-Erkennung in VDBMS ist aufwendig und Kommunikationsintensiv Versuche, Deadlocks von vornherein zu vemeiden.

78 78 Sperrbasierte Synchronisation Wound/wait: Nur jüngere Transaktionen (jedes T bekommt zu BOT einen time stamp) warten auf ältere. Fordert ältere Transaktion Sperre an, die mit der von der jüngeren Transaktion gehaltenen nicht verträglich ist, wird jüngere Transaktion abgebrochen ( strikte Bevorzugung bereits lang laufender Transaktionen) Wait/die: Nur ältere Transaktionen warten auf jüngere. Fordert jüngere Transaktion Sperre an, die mit der von der älteren Transaktion gehaltenen nicht kompatibel ist, wird jüngere Transaktion abgebrochen ( ä ltere Transaktionen bevorzugt, Blockierung mit zunehmender Alter aber immer wahrscheinlicher)

79 79 Zeitstempel: Voraussetzungen für Deadlockvermeidungsverfahren Vergabe global eindeutiger Zeitstempel als Transaktionsidentifikatoren. Format: Vergleich von Zeitstempeln lexikographisch: vergleiche erst bzgl. lokaler Zeit, dann bzgl. Station. Lokale Uhren müssen hinreichend genau aufeinander abgestimmt sein. lokale Zeit Stations-ID

80 80 Synchronisation bei replizierten Daten Problem: Im VDBMS gibt es zu einem Datum A mehrere Replikate A 1, A 2,..., A n, die auf unterschiedlichen Stationen liegen. Eine Lesetransaktion erfordert nur (irgend)eine Kopie, bei Änderungstransaktionen müssen aber alle bestehenden Kopien geändert werden, inkl. Sperrfanforderung, Kommunikation, etc. Hohe Laufzeit und Verfügbarkeitsprobleme (bspw. Heimatstation einer Kopie A i nicht erreichbar) Lesetransaktionen eindeutig bevorteilt

81 81 Quorum-Consensus Verfahren Ausgleich der Leistungsfähigkeit zwischen Lese- und Änderungstransaktionen teilweise Verlagerung des Overheads von den Änderungs- zu den Lesetransaktionen indem den Kopien A i eines replizierten Datums A individuelle Gewichte (Stimmen) w i zugeordnet werden. Beispiel: Gesamtgewicht W(A) = i=1,…,4 w i (A i ) = 8 Station (S i )Kopie (A i )Gewicht (w i ) S1S1 A1A1 3 S2S2 A2A2 1 S3S3 A3A3 2 S4S4 A4A4 2

82 82 Quorum-Consensus Verfahren Weiterhin: Festlegung von Lesequorum Q r (A) und Schreibquorum Q w (A). Eine Lesetransaktion, die r(A) ausf ü hren will, muß zuvor mindestens Q r (A) Stimmen an den Stationen "einsammeln" und deren Kopien von A mit einem shared lock lockS(A) belegen. Eine Schreibtransaktion muß vor Operation w(A) Q w (A) Stimmen an den Stationen einsammeln und deren Kopien jeweils mit exclusive locks lockX(A) belegen. Zusatzbedingungen (Beispiel: Q r (A) = 4, Q w (A) = 5): Q w (A) + Q w (A) > W(A) Q r (A) + Q w (A) > W(A)

83 83 Quorum-Consensus Verfahren Wie werden Updates propagiert? Eine Schreibtransaktion wird ja nur die Kopien auf den Stationen ä ndern, deren Stimmen sie eingesammelt hat (und dort lockX-Locks besitzt). Protokolliere f ü r jedes Datenobjekt eine Versionsnummer. Eine Schreibtransaktion versieht das geschriebene Objekt mit dem Maximum aller seiner Versionsnummern + 1.

84 84 Zustände vor (a) und nach (b) Update A := A StationKopieGewichtWertVersions# S1S1 A1A S2S2 A2A2 1 1 S3S3 A3A3 2 1 S4S4 A4A4 2 1 a) vor dem Schreiben eines Schreibquorums b) nach dem Schreiben eines Schreibquorums StationKopieGewichtWertVersions# S1S1 A1A S2S2 A2A S3S3 A3A S4S4 A4A

85 85 Quorum-Consensus Verfahren Eine Lesetransaktion liest mehrere Kopien, um mindestens Q r (A) Stimmen "einzusammeln", nutzt aber nur den A-Wert mit der h ö chsten Versionsnummer. Beispiel: Lese die Kopien A 3 und A 4 (Stimmen? w 3 (A) + w 4 (A) = 4 Q r (A) ), nutze jedoch nur den Wert der Kopie A 3. Die Bedingunng Q r (A) + Q w (A) > W(A) stellt sicher, daß auf mindestens eine Kopie des letzten Schreibquorums zugegriffen wird.


Herunterladen ppt "Verteilte Datenbanken Geographisch verteilte Organisationsform einer Bank mit ihren Filialen Filialen sollen Daten lokaler Kunden lokal bearbeiten können."

Ähnliche Präsentationen


Google-Anzeigen