Verteilte datenbanken
This presentation is the property of its rightful owner.
Sponsored Links
1 / 85

Verteilte Datenbanken PowerPoint PPT Presentation


  • 65 Views
  • Uploaded on
  • Presentation posted in: General

Verteilte Datenbanken. Szenario:. 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 ). Terminologie.

Download Presentation

Verteilte Datenbanken

An Image/Link below is provided (as is) to download presentation

Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.


- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -

Presentation Transcript


Verteilte datenbanken

Verteilte Datenbanken

Szenario:

  • 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)


Terminologie

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


Kommunikationsmedien

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.


Verteiltes datenbanksystem

Verteiltes Datenbanksystem

Station S1

Kommunikations-

netz

Station S2

Station S3


Client server architektur vdbms

Client-Server-Architektur  VDBMS

Client C1

Kommunikations-

netz

Client C2

Server


Aufbau und entwurf eines verteilten datenbanksystems

Aufbau und Entwurf eines verteilten Datenbanksystems

globales Schema

Ausganspunkt

Fragmentierungs-

schema

Zerlegung von Rel.s

in (disjunkte) Fragmente

Allokation von Rel.s

zu Stationen

Zuordnungsschema

lokales

Schema

lokales

Schema

...

lokales

DBMS

...

lokales

DBMS

...

lokale

DB

lokale

DB

...

Station S1

Station Sn


Fragmentierung und allokation einer relation

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).


Verteilte datenbanken

Allokation

(Zuordnung)

Fragmentierung

R

R1

R1

R1

Station S1

R1

R2

R2

R2

R1

Station S2

R3

R3

R2

Station S3

R3

R3


Fragmentierung

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


Anforderungen an das fragmentierungsschema

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.


Beispielrelation professoren

Beispielrelation "Professoren"


Horizontale fragmentierung

Horizontale Fragmentierung

Abstrakte Darstellung:

R

R1

R2

R3

Für zwei Prädikate p1 und p2 ergeben sich 4 Fragmente:

R1 := p1p2(R)

R2 := p1 p2(R)

R3 := p1 p2(R)

R4 := p1 p2(R)

n Zerlegungsprädikate p1,...,pn ergeben 2n Fragmente


Verteilte datenbanken

Sinnvolle Gruppierung der Professoren nach Fakultät:

3 Zerlegungsprädikate:

p1 (Fakultät = 'Theologie')

p2 (Fakultät = 'Physik')

p3 (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) = 


Abgeleitete horizontale fragmentierung

Abgeleitete horizontale Fragmentierung

Die Fragmentierung verschiedener Relationen ist nicht beliebig

und hat Einfluß auf die Anfragebearbeitung.

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


Verteilte datenbanken

  • 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´

    2SWSVorls

    PhysikProfs´

    3SWSVorls

    PhiloProfs´

    4SWSVorls


    Einschub join arten

    Einschub: Join-Arten

    • natürlicher Join

    =


    Einschub join arten semi joins

    Einschub: Join-Arten (Semi-Joins)

    • Semi-Join von R mit L (Right Semi-Join)

    =

    • Semi-Join von L mit R (Left Semi-Join)

    =


    Verteilte datenbanken

    Lösung: abgeleitete Fragmentierung

    TheolProfs´

    TheolVorls

    PhysikProfs´

    PhysikVorls

    PhiloProfs´

    PhiloVorls

    TheolVorls := Vorlesungen gelesenVon=PersNrTheolProfs ´

    PhysikVorls := Vorlesungen gelesenVon=PersNrPhysikProfs ´

    PhiloVorls := Vorlesungen gelesenVon=PersNrPhiloProfs ´

    Titel, Name((TheolProfs´ p TheolVorls) 

    (PhysikProfs´ p PhysikVorls)  (PhiloProfs´ p PhiloVorls) )

    mit p (PersNr = gelesenVon)


    Vertikale fragmentierung

    Vertikale Fragmentierung

    Abstrakte: Vertikale Fragmentierung einer Relation R mit

    Primärschlüssel :

    R

    R2

    R1

    κ


    Vertikale fragmentierung1

    Vertikale Fragmentierung

    • Jedes Fragment enthält den Primärschlüssel der Originalrelation. Aber: Verletzung der Disjunktheit.

    • 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:


    Vertikale fragmentierung beispiel

    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.PersNrProfs


    Kombinierte fragmentierung

    Kombinierte Fragmentierung

    • )Horizontale Fragmentierung nach vertikaler Fragmentierung:

    R

    R21

    R22

    R23

    R1

    R2

    • )Vertikale Fragmentierung nach horizontaler Fragmentierung:

    R

    R1

    R2

    R3

    R31

    R32


    Rekonstruktion nach kombinierter fragmentierung

    Rekonstruktion nach kombinierter Fragmentierung

    Fall a)

    R = R1R1. =R2.  (R21 R22 R23)

    Fall b)

    R = R1 R2 (R31 R31.  =R32.  R32)


    Baumdarstellung der fragmentierungen beispiel

    Baumdarstellung der Fragmentierungen (Beispiel)

    Professoren

    v

    abgeleitete Fragmentierung

    Profs

    ProfVerw

    Vorlesungen

    h

    h

    PhysikProfs

    TheolProfs

    PhiloProfs

    PhysikVorls

    TheolVorls

    PhiloVorls


    Allokation beispiel

    Allokation (Beispiel)

    • Ein Fragment kann prinzipiell mehreren Stationen zugeordnet werden (Replikation).

    • Allokation für unser Beispiel jedoch ohne Replikation  redundanzfreie Zuordnung.

    Station

    Bemerkung

    zugeordnete Fragmente

    SVerw

    SPhysik

    SPhilo

    STheol

    Verwaltungsrechner

    Dekanat Physik

    Dekanat Philosophie

    Dekanat Theologie

    {ProfVerw}

    {PhysikVorls, PhysikProfs}

    {PhiloVorls, PhiloProfs}

    {TheolVorls, TheolProfs}


    Transparenz in verteilten datenbanken

    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


    Fragmentierungstransparenz

    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?


    Fragmentierungstransparenz cont

    Fragmentierungstransparenz (cont.)

    • Im betroffenen Fragment: Ändern des Attributwertes von Fakultät.

    • Transferieren des Sokrates-Tupels aus Fragment PhiloProfs in das Fragment TheolProfs (= Löschen aus PhiloProfs, Einfügen in TheolProfs).

    • Ändern der abgeleiteten Fragmentierung von Vorlesungen (= Einfügen der von Sokrates gehaltenen Vorlesungen in TheolVorls, Löschen der von ihm gehaltenen Vorlesungen aus PhiloVorls).


    Allokationstransparenz

    Allokationstransparenz

    Benutzer müssen Fragmentierung kennen, aber nicht die

    Station(en) eines Fragmentes:

    Beispiel:

    SELECT Gehalt

    FROM ProfVerw

    WHERE Name = "Sokrates";

    Fragmentname!


    Allokationstransparenz cont

    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";


    Lokale schema transparenz

    Lokale Schema-Transparenz

    Der Benutzer muss jetzt auch noch die Station kennen, auf der ein Fragment liegt.

    Beispiel:

    SELECT Name

    FROM TheolProfs ATSTheol

    WHERE Rang = "C3";


    Lokale schema transparenz cont

    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 SPhilo ausgeführt werden.

    Dies ist nicht möglich bei Kopplung unterschiedlicher DBMS.

    Verwendung grundsätzlich verschiedener Datenmodelle auf lokalen DBMS nennt man Multi-Database-Systems. Oft unumgänglich in realen (unternehmensweiten) Applikationen.


    Anfrage bersetzung und anfrageoptimierung

    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


    Anfragebearbeitung bei horizontaler fragmentierung

    Anfragebearbeitung bei horizontaler Fragmentierung

    • 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.

    • Kombination des Rekonstruktionsausdrucks mit dem algebraischen Anfrageausdruck, der sich aus der Übersetzung der SQL-Anfrage ergibt.

    Übersetzung einer SQL-Anfrage auf dem globalen Schema in eine äquivalente Anfrage auf den Fragmenten benötigt 2 Schritte:


    Beispiel

    Beispiel

    SELECT Titel

    FROM Vorlesungen, Profs

    WHEREgelesenVon = PersNr AND Rang = "C4";

    Der entstandene algebraische Ausdruck heißt kanonische Form der Anfrage:

    ΠTitel

    σRang="C4"

    gelesenVon=PersNr

    TheolVorls

    PhiloVorls

    PhysikVorls

    TheolProfs

    PhiloProfs

    PhysikProfs


    Algebraische quivalenzen

    Algebraische Äquivalenzen

    Für eine effizientere Abarbeitung der Anfrage benutzt der Anfrageoptimierer die folgende Eigenschaft:

    (R1 R2) p (S1  S2) =

    (R1p S1)  (R1p S2)  (R2p S1)  (R2p S2)

    Die Verallgemeinerung auf n horizontale Fragmente R1,...,Rn von R und m Fragmente S1,...,Sm von S ergibt:

    (R1 ...  Rn) p (S1  ...  Sm) =   (Rip Sj)

    1in 1jm

    Falls gilt: Si = S p Ri mit S = Si  ...  Sn ,

    dann tragen die Joins Rip Sj für i  j nichts Neues zum Join-Ergebnis bei. (Achtung: Fehler im Buch!)


    Algebraische quivalenzen forts

    Algebraische Äquivalenzen (Forts.)

    Für eine derartig abgeleitete horizontale Fragmentierung von S gilt somit:

    (R1 ...  Rn) p (S1  ...  Sm) =

    (R1p S1)  (R2p S2)  ...  (Rnp Sn)


    Algebraische quivalenzen forts1

    Algebraische Äquivalenzen (Forts.)

    Für eine derartig abgeleitete horizontale Fragmentierung von S gilt somit:

    (R1 ...  Rn) p (S1  ...  Sm) =

    (R1p S1)  (R2p S2)  ...  (Rnp Sn)

    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(R1  R2) = σp(R1)  σp(R2)

    L(R1  R2) = L(R1)  L(R2)


    Optimale form der anfrage

    Optimale Form der Anfrage

    Die Anwendung dieser algebraischen Regeln generiert den folgenden Auswertungsplan:

    ΠTitel

    ΠTitel

    ΠTitel

    gelesenVon=PersNr

    gelesenVon=PersNr

    gelesenVon=PersNr

    σRang=‚C4‘

    σRang=‚C4‘

    σRang=‚C4‘

    PhysikVorls

    PhysikProfs

    PhiloVorls

    PhiloProfs

    TheolVorls

    TheolProfs

    Auswertungen können lokal auf den Stationen STheol, SPhysik und SPhilo ausgeführt werden Stationen können parallel abarbeiten und lokales Ergebnis voneinander unabhängig an die Station, die die abschliessende Vereinigung durchführt, übermitteln.


    Anfragebearbeitung bei vertikaler fragmentierung

    Anfragebearbeitung bei vertikaler Fragmentierung

    Kanonischer Auswertungsplan:

    Beispiel:

    SELECT Name, Gehalt

    FROM Professoren

    WHERE Gehalt > 80000;

    ΠName, Gehalt

    σGehalt>80000

    ProfVerw

    TheolProfs

    PhysikProfs

    PhiloProfs


    Optimierung bei vertikaler fragmentierung

    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;


    Der nat rliche verbund zweier relationen r und s

    Der natürliche Verbund zweier Relationen R und S

    S

    C

    D

    E

    c1

    c3

    c4

    c5

    c7

    c8

    c5

    d1

    d2

    d3

    d4

    d5

    d6

    d7

    R

    A

    B

    C

    R S

    a1

    a2

    a3

    a4

    a5

    a6

    a7

    b1

    b2

    b3

    b4

    b5

    b6

    b7

    c1

    c2

    c1

    c2

    c3

    c2

    c6

    e1

    e2

    e3

    e4

    e5

    e6

    e7

    A

    B

    C

    D

    E

    d1

    d1

    d2

    e1

    e1

    e2

    a1

    a3

    a5

    b1

    b3

    b5

    c1

    c1

    c3

    =


    Join auswertung in vdbms

    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


    Join auswertung in vdbms1

    Join-Auswertung in VDBMS

    Betrachtung des allgemeinsten Falles:

    • Äußere Argumentrelation R ist auf Station StR gespeichert

    • Innere Argumentrelation S ist der Station StS zugeordnet

    • Ergebnis der Joinberechnung wird auf einer dritten Station StResult benötigt


    Join auswertung ohne filterung

    Join-Auswertung ohne Filterung

    Ziel: Einsatz etablierter Join-Verfahren aus zentralisierten DBMS:

    • Nested-Loops

    • Transfer einer Argumentrelation

    • Transfer beider Argumentrelationen


    Nested loops

    Nested Loops

    Iteration durch die äußere Relation R mittels Laufvariable r und Anforderung (über Kommunikationsnetz bei StS)

    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.


    Der nat rliche verbund zweier relationen r und s1

    Der natürliche Verbund zweier Relationen R und S

    S

    C

    D

    E

    c1

    c3

    c4

    c5

    c7

    c8

    c5

    d1

    d2

    d3

    d4

    d5

    d6

    d7

    R

    A

    B

    C

    a1

    a2

    a3

    a4

    a5

    a6

    a7

    b1

    b2

    b3

    b4

    b5

    b6

    b7

    c1

    c2

    c1

    c2

    c3

    c2

    c6

    e1

    e2

    e3

    e4

    e5

    e6

    e7


    Alternative 1 transfer einer argumentrelation

    Alternative 1:Transfer einer Argumentrelation

    1.

    2.

    Vollständiger Transfer einer Argumentrelation (z.B. R) zum Knoten der anderen Argumentrelation

    Ausnutzung eines möglicherweise auf S.C existierenden Indexes auf Station StS


    Alternative 2 transfer beider argumentrelationen

    Alternative 2: Transfer beider Argumentrelationen

    1. Transfer beider Argumentrelationen zum Rechner StResult

    2. Berechnung des Ergebnisses auf dem Knoten StResult mittels

    a) Merge-Join (bei vorliegender Sortierung)

    oder

    b) Hash-Join (bei fehlender Sortierung)

     evtl. Verlust der vorliegenden Indexe (auf StR und/oder StS) für die Join-Berechnung

     aber kein Verlust der Sortierung der Argumentrelation(en)


    Join auswertung mit filterung

    Join-Auswertung mit Filterung

    Bisher: Transfer potentiell großer Datenmengen, auch falls

    Resultat der Join-Operation selbst sehr klein ist (hohe Selektivität).

    • 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)

    Daher:


    Join auswertung mit filterung beispiel filterung der relation s

    Join-Auswertung mit Filterung (Beispiel, Filterung der Relation S)

    Transfer der unterschiedlichen C-Werte von R (= ΠC(R)) nach StS

    Auswertung des Right-Semi-Joins R S =ΠC(R) S auf StS und Transfer des Ergebnisses nach StR

    Auswertung des Joins auf StR , der nur diese transferierten Ergebnistupel des Semi-Joins braucht

    1.

    2.

    3.

    Transferkosten werden nur reduziert, wenn gilt:

    ΠC(R) + R S <  S 

    mit  = Größe (in Byte) einer Relation


    Verteilte datenbanken

    ...

    C

    R (ΠC(R) S)

    c1

    c2

    c3

    c6

    A

    B

    C

    D

    E

    S

    d1

    d1

    d2

    e1

    e1

    e2

    a1

    a3

    a5

    b1

    b3

    b5

    c1

    c1

    c3

    C

    D

    E

    c1

    c3

    c4

    c5

    c7

    c8

    c5

    d1

    d2

    d3

    d4

    d5

    d6

    d7

    e1

    e2

    e1

    e2

    e3

    e2

    e6

    ΠC(R) S

    C

    D

    E

    c1

    c3

    d1

    d2

    e1

    e2

    StResult

    15 Attributwerte

    6 Attributwerte

    Auswertung des Joins R A S mit Semi-Join-Filterung von S

    4 Attributwerte

    ΠC

    R

    A

    B

    C

    a1

    a2

    a3

    a4

    a5

    a6

    a7

    b1

    b2

    b3

    b4

    b5

    b6

    b7

    c1

    c2

    c1

    c2

    c3

    c2

    c6

    StR

    StS


    Verteilte datenbanken

    Alternative Auswertungungspläne

    1. Alternative:

    ...

    StResult

    ΠC

    R

    S

    StR

    StS

    2. Alternative:

    (R ΠC(S)) (ΠC(R) S)


    Parameter f r die kosten eines vbmds auswertungsplans

    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.


    Transaktionskontrolle in vdbms

    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.


    Eot behandlung in vdbms

    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

    oder

    • abort:globale Transaktion wird an allen (relevanten) Stationen nicht festgeschrieben

    Problem in verteilter Umgebung, da die Stationen eines

    VDBMS unabhängig voneinander "abstürzen" können


    Probleml sung two phase commit protokoll 2pc

    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) A1,…An , 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


    Nachrichtenaustausch beim 2pc protokoll f r 4 agenten

    Nachrichtenaustausch beim 2PC-Protokoll (für 4 Agenten)

    A1

    A1

    A2

    A2

    A3

    A3

    A4

    A4

    4 Messages?

    K

    K

    K

    PREPARE

    FAILED/READY

    COMMIT/ABORT

    ACK

    Phase 1

    Phase 2


    Ablauf der eot behandlung beim 2pc protokoll

    Ablauf der EOT-Behandlung beim 2PC-Protokoll

    • K schickt allen Agenten eine PREPARE-Nachricht, um herauszufinden, ob sie Transaktionen festschreiben können

    • Jeder Agent Ai empfängt PREPARE-Nachricht und schickt eine von zwei möglichen Nachrichten an K:

    • READY, falls Ai in der Lage ist, die Transaktion T lokal festzuschreiben

    • FAILED, falls Ai kein commit durchführen kann (wegen Fehler, Inkonsistenz etc.)

    • Hat K von allenn Agenten A1,...,An 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.


    Zustands bergang beim 2pc protokoll koordinator

    Zustandsübergang beim 2PC-Protokoll: Koordinator

    Initial

    "Bullet" 

    = wichtigste Aktion(en)

    EOT:

    • Alle an T beteiligen Agenten im Log protokollieren

    • sende PREPARE an Agenten

    Bereit

    READY von allen Agenten

    empfangen:

    Timeout oder 1 x FAILED

    empfangen:

    • (T,commit) ins Log

    • sende COMMIT

    • (T,abort) ins Log

    • ABORT senden

    Abgebrochen

    Festschreibend

    von allen ACK empfangen:

    von allen ACK empfangen:

    Fertig

    • (T,terminated) ins Log


    Zustands bergang beim 2pc protokoll agent

    Zustandsübergang beim 2PC-Protokoll: Agent

    Wartend

    PREPARE empfangen und

    lokal alles okay:

    Timeout od. PREPARE empfangen

    und lokaler Fehler entdeckt:

    • Log-Einträge für T schreiben

    • (T,ready) ins Log

    • sende READY

    • (T,abort) ins Log

    • sende FAILED

    Ab hier: Agent verpflichtet sich,

    T erfolgreich zu beenden

    Bereit

    ABORT empfangen:

    COMMIT empfangen:

    • (T,abort) ins Log

    • sende ACK

    • (T,commit) ins Log

    • sende ACK

    Abgebrochen

    Festgeschrieben

    "Bullet" 

    = wichtigste Aktion(en)

    (verspätetes)PREPARE empfangen:

    • sende FAILED


    Blockierung eines agenten

    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

      • Versuche globale COMMIT-Entscheidung bei K nachzufragen (Kommunikationsfehler?)

      • Ist 1. erfolglos (K abgestürzt?), erfrage COMMIT-Entscheidung bei weiteren Agenten A oder erfrage, ob A mit FAILED geantwortet hat

      • Ist auch 2. erfolglos, wird der Agent blockiert, bis K wieder funktionsfähig ist und die COMMIT-Entscheidung nachholt


    Crash recovery in agenten knoten

    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).


    Crash recovery im koordinator

    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.


    Lineare organisationsform beim 2pc protokoll

    Lineare Organisationsform beim 2PC-Protokoll

    COMMIT-Entscheidung wird sequentiell zwischen den Agenten

    Kommuniziert:

    FAILED/READY

    FAILED/READY

    FAILED/READY

    K

    A1

    A2

    A3

    COMMIT/ABORT

    COMMIT/ABORT

    COMMIT/ABORT

    ACK

    • 2PC-Phase 1: Vorwärtskommunikation

    • 2PC-Phase 2: Komm.sequenz in umgekehrter Reihenfolge


    Mehrbenutzersynchronisation in vdbms

    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


    Serialisierbarkeit

    Serialisierbarkeit

    S1

    S2

    Schritt

    T1

    T2

    Schritt

    T1

    T2

    r(B)

    w(B)

    3.

    4.

    1.

    2.

    r(A)

    w(A)

    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):

    T1 T2


    Lokale sperrverwaltung

    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


    Globale sperrverwaltung

    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


    Deadlocks in vdbms

    Deadlocks in VDBMS

    • Erkennung von Deadlocks (Verklemmungen)

    • Zentralisierte Deadlock-Erkennung: 

    • Dezentrale (verteilte) Deadlock-Erkennung: schwierig

    • Vermeidung von Deadlocks


    Ein verteilter deadlock

    Ein "Verteilter Deadlock"

    S1

    S2

    Schritt

    T1

    T2

    Schritt

    T1

    T2

    0.

    1.

    2.

    6.

    BOT

    lockS(A)

    r(A)

    lockX(A)

    

    3.

    4.

    5.

    7.

    lockS(B)

    

    BOT

    lockX(B)

    w(B)

    • Lokal ist jeweils keine Deadlock-Situation zu erkennen

    • Der globale Waits-for-Graph ist jedoch zyklisch


    Erkennung von verteilten deadlocks timeout

    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


    Erkennung von verteilten deadlocks zentralisiert

    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


    Erkennung von verteilten deadlocks dezentral

    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


    Dezentrale deadlock erkennung external

    Dezentrale Deadlock-Erkennung: External

    S1

    S2

    Schritt

    T1

    T2

    Schritt

    T1

    T2

    0.

    1.

    2.

    6.

    BOT

    lockS(A)

    r(A)

    lockX(A)

    3.

    4.

    5.

    7.

    lockS(B)

    BOT

    lockX(B)

    w(B)

    External T2 *)External T1

    T1External T2External

    *) Lies: Externe Transaktionen können potentiell aufgrund von T2 auf S1 gesetzten Locks blockieren.


    Beispiel s 1 heimatknoten von t 1 s 2 heimatknoten von t 2

    Beispiel:S1 Heimatknoten von T1, S2 Heimatknoten von T2

    Wartegraphen (Zyklus mit External = potentieller Deadlock):

    External → T2 →T1 → External

    S1:

    S1 sendet Wartegraphen

    an die Station, auf der T1

    eine Teiltransaktion angestoßen

    hat (hier: S2).

    External → T1 →T2 → External

    S2:

    External  T1 T2 External

    S2:

    T1 → T2 →T1

    T2 → T1 →T2

    • S2 kann globalen Deadlock (Zyklus ohne External) erkennen.

      S2 wählt eine Opfer-Transaktion, setzt diese zurück und löst

      damit den Deadlock auf.


    Deadlock vermeidung

    Deadlock-Vermeidung

    Deadlock-Erkennung in VDBMS ist aufwendig und

    Kommunikationsintensiv  Versuche, Deadlocks von vornherein zu vemeiden.

    • 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)


    Sperrbasierte synchronisation

    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)


    Zeitstempel voraussetzungen f r deadlockvermeidungsverfahren

    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 Zeit

    Stations-ID

    • Lokale Uhren müssen hinreichend genau aufeinander abgestimmt sein.


    Synchronisation bei replizierten daten

    Synchronisation bei replizierten Daten

    • Problem:

    • Im VDBMS gibt es zu einem Datum A mehrere Replikate A1, A2, ..., An, 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 Ai nicht erreichbar)

       Lesetransaktionen eindeutig bevorteilt


    Quorum consensus verfahren

    Quorum-Consensus Verfahren

    • Ausgleich der Leistungsfähigkeit zwischen Lese- und Änderungstransaktionen teilweise Verlagerung des Overheads von den Änderungs- zu den Lesetransaktionen indem den Kopien Ai eines replizierten Datums A individuelle Gewichte (Stimmen) wizugeordnet werden.

    • Beispiel:

    • Gesamtgewicht W(A) = i=1,…,4 wi(Ai) = 8


    Quorum consensus verfahren1

    Quorum-Consensus Verfahren

    • Weiterhin: Festlegung von LesequorumQr(A) und SchreibquorumQw(A).

    • Eine Lesetransaktion, die r(A) ausführen will, muß zuvor mindestens Qr(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) Qw(A) Stimmen an den Stationen einsammeln und derenKopien jeweils mit exclusive locks lockX(A) belegen.

    • Zusatzbedingungen (Beispiel: Qr(A) = 4, Qw(A) = 5):

      Qw(A) + Qw(A) > W(A)

      Qr(A) + Qw(A) > W(A)


    Quorum consensus verfahren2

    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.


    Zust nde vor a und nach b update a a 100

    Zustände vor (a) und nach (b) Update A := A + 100

    a) vor dem Schreiben eines Schreibquorums

    b) nach dem Schreiben eines Schreibquorums


    Quorum consensus verfahren3

    Quorum-Consensus Verfahren

    • Eine Lesetransaktion liest mehrere Kopien, um mindestens Qr(A) Stimmen "einzusammeln", nutzt aber nur den A-Wert mit der höchsten Versionsnummer.

    • Beispiel: Lese die Kopien A3 und A4 (Stimmen? w3(A) + w4(A) = 4 Qr(A)), nutze jedoch nur den Wert der Kopie A3.

    • Die Bedingunng

      Qr(A) + Qw(A) > W(A)

      stellt sicher, daß auf mindestens eine Kopie des letzten Schreibquorums zugegriffen wird.


  • Login