6 3 Verteilte Transaktionen Situation Fragmentierung Ein Datenbestand

Зарегистрируйтесь, чтобы просмотреть полный документ!

6. 3 Verteilte Transaktionen Situation: Fragmentierung: Ein Datenbestand ist über mehrere Stationen verteilt (z. B. verteilte Datenbank, verteiltes Dateisystem, . . . ) d. h. in Fragmente aufgeteilt, für die jeweils ein Server zuständig ist. Auf diesem Datenbestand soll eine Operationsfolge "sicher" ausgeführt werden. vs 6. 3 1

z. B. : Buchung einer Pauschalreise: Fragment Hotels + Fragment Flüge Konsistenzforderung: - keine Hotelbuchung ohne passende Flugbuchung - keine Flugbuchung ohne passende Hotelbuchung Überweisung: Fragment Bank A + Fragment Bank B Konsistenzforderung: - Es geht kein Geld verloren und es kommt keines hinzu vs 6. 3 2

Operationen sollten transaktional ausgeführt werden Transaktion BEGIN. . . [ABORT]. . . COMMIT sichert die Eigenschaften Atomicity - Atomarität: alles oder nichts Consistence - Konsistenz: Invariante bleibt gewährleistet Isolation - Serialisierbarkeit bei nebenläufigen Zugriffen Durability - Persistenz: Daten bleiben dauerhaft erhalten vs 6. 3 3

Serialisierbarkeit Isolation: Transaktionen sollen voneinander unabhängig sein, im Interesse der Performanz sollen sie jedoch so "nebenläufig wie möglich" ausgeführt werden Serialisierbarkeit: Der Effekt der nebenläufigen Ausführung mehrerer Transaktionen soll der gleiche sein, als wären die Transaktionen nacheinander ausgeführt worden vs 6. 3 4

Transaktion T 1: begin x = 0; x = x+1; commit Transaktion T 2: begin x = 0; x = x+2; commit Transaktion T 3: begin x = 0; x = x+3; commit Ausführungsreihenfolge 1: Ausführungsreihenfolge 2: Ausführungsreihenfolge 1: x x x x x = = = 0; x+1; 0; x+2; 0; x+3; serialisiert (x==3) = = = 0; 0; x+1; x+2; 0; x+3; nicht serialisiert aber OK (x==3) vs 6. 3 = = = 0; 0; x+1; 0; x+2; x+3; nicht OK (x==5) 5

6. 3. 1 Serialisierbarkeit durch Ausschlusssynchronisation nur praktikabel für kleine fragmentierte Objekte, nicht für ganze Datenbanken! Möglichkeiten: Verteilter Ausschluss (5. 4 Sperrsynchronisation durch zentralen Koordinator, virtuellen Token Ring oder verteilte Warteschlange) zu strikt angesichts lesender vs. schreibender Operationen vs 6. 3 6

Verteilter R/W-Ausschluss: a) In virtuellem Ring kreisende Marke (5. 4. 2 ) trägt Zähler m = Anzahl der gerade aktiven lesenden Operationen; schreibwillige Operation muß auf Marke mit m = 0 warten und diese festhalten. Nachteil: strikte Bevorzugung der Leser vs 6. 3 7

b) Virtueller Ring von n Stationen, kreisende Marke enthält m „Stimmen“ (anfangs m = n); festgelegte Quoren für Lese- bzw. Schreibrecht Leser braucht r Stimmen Schreiber braucht w Stimmen, mit folgenden Bedingungen für r und w: r + w n (keine Leser-Schreiber-Konflikte) n/2 w n (keine Schreiber-Konflikte) ( 0 r n) vs 6. 3 8

Beispiel: n=8 r=4 A B C D. . . w=5 (m = 8) lesen schreiben lesen m -= 4 (4) m -= 4 (0) (m<5) (m<4) fertig schreiben lesen m += 4 (4) m += 4 (8) m -= 5 (3) (m<4) Leser-Schreiber-Ausschluss im Unterschied zu Variante a) weniger Leser gleichzeitig vs 6. 3 9

etwas bessere Fairness für Schreiber Fairness "einstellbar" Variante r = 1, w = n äquivalent zu a) Vorteile werden erkauft durch eingeschränkte Nebenläufigkeit für die Leser c) Varianten anderer Ansätze aus 5. 4 vs 6. 3 10

6. 3. 2 Serialisierbarkeit durch verteilte Transaktionen (sichern nicht nur Serialisierbarkeit, sondern ACID insgesamt) naiver Ansatz: – beteilige Server starten lokale Transaktion – Koordinator fordert sie auf Wunsch des Klienten zum Commit oder Abort auf – (kein Abbruch durch andere Server möglich) Klienten . . . . Koordinator . . Verteiltes Objekt vs 6. 3 11

2 -Phasen-Commit-Protokoll (2 PC) (nicht verwechseln mit 2 -Phasen-Sperren, 2 PL) – beteiligte Server müssen sich bei Commit-Wunsch einig werden über Abschluss oder Abbruch der verteilten Transaktion BEGIN: alle beteiligten Server werden zu lokalem BEGIN aufgefordert ABORT: alle beteiligten Server werden zu lokalem ABORT aufgefordert COMMIT: 2 PC tritt in Aktion: . . . vs 6. 3 12

Phase 1 – Abstimmen: 1. „Commit? “ an alle Server; 2. diese prüfen, ob Commit möglich wäre und antworten mit „Ja“ oder „Nein“. Phase 2 – Abschließen nach Eintreffen aller Anworten: 3. Falls alle Server mit „Ja“ geantwortet haben, „Commit!“ an alle Server, sonst „Abort!“ an alle Server; 4. diese befolgen den Befehl und quittieren. Präzisierung/weiter Absicherung unter Zuhilfenahme diverser Timeouts – siehe z. B. Coulouris et al. : Verteilte Systeme vs 6. 3 13

Geschachtelte Transaktionen (nested transactions): Die Teiltransaktionen können wiederum Teiltransaktionen haben T 11 T Y T 22 Z V Z flache (verteilte) Transaktion Y U T T 2 X T 21 T 1 W T 12 X verschachtelte Transaktion vs 6. 3 14

Vorteile: - Erhöhung des Parallelitätsgrades - Abbruch einer Kind-Transaktion muss nicht unbedingt Abbruch der Eltern-Transaktion zur Folge haben (letztere ist programmatisch darauf vorbereitet) weitere Details: Özsu/Valduriez: Principles of Distributed Database Systems vs 6. 3 15

Скачать презентацию 6 3 Verteilte Transaktionen Situation Fragmentierung Ein Datenbestand

e6a7ece4d482009ee15d0a6281159aa1.ppt

Количество слайдов: 15