Verteilte Datenbanken

Verteilte Datenbanken
Motivation
• Eine Bank, die geographisch verteilt ist mit ihren Filialen
• Einzelne Filialen sollen autonom die Daten der lokalen Kunden
bearbeiten
• Auch andere Filialen müssen aber Zugriff auf diese Informationen
haben: z.B. für Kontostandsüberprüfung
• Klassischer Fall für den Einsatz eines verteilten Datenbanksystems
Zentralisiertes vs. Verteiltes DB System
• Zentralisiertes DB System
•
•
•
•
Ein einziges Front End
Ein einziges Speicherort für Sperren
Im Falle eines Prozessor Crashes → Totalausfall
Nachteil: keine Knotenautonomie → problematisch für geographisch
verteilten Systemen
• Verteiltes DB System
• Mehrere Prozessoren ( + Speicherplatz)
• Heterogenität und Autonomie der
einzelnen Stationen des Netzwerks
Verteilte Datenbanken
• Die Daten werden auf mehreren Stationen/Knoten/Sites gespeichert, jeweils
durch ein DBMS verwaltet, das unabhängig auf den einzelnen Knoten läuft
• Es handelt sich über eine Kooperation zwischen autonom arbeitenden
Stationen
• Die logische Sicht als eine Datenbank wird in verteilten Datenbanken durch
die Implementierung eines globalen Schemas realisiert
• Verteilte Datenunabhängigkeit (Distributed Data Independece): Benutzer
brauchen nicht zu wissen, wo sich die Daten wirklich befinden
• Erweiterung des Prinzips der physischen und logischen Datenunabhängigkeit
• Wird auch als Transparenz bezeichnet
• Verteilte Transaktionsatomarität (Distributed Transaction Atomicity):
Benutzer müssen in der Lage sein Transaktionen zu schreiben, die auf
mehreren Knoten laufen, sich aber wie lokale Transaktionen verhalten (ACIDEigenschaften)
Beispiel
• Eine große Firma hat Büros in London, New York und Hong Kong
• Die Daten der Angestellten werden meistens lokal verwaltet (wo der
Angestellte arbeitet)
• z.B. Payroll, benefits,
• Regelmäßig braucht die Firma Zugriff zu allen Daten über
Angestellten
• z.B. Berechnen aller Payroll Kosten
• z.B. Berechnen des globalen Gewinns
• Wo soll die Tabelle mit den Angestellten gespeichert werden?
London Payroll
App
New York Payroll
App
Angestellte
New York
London
London Payroll
App
Hong Kong
NY und HK Payroll Apps
sind sehr langsam!
London Payroll
App
New York Payroll
App
Lon Angestellte
New York
London
London Payroll
App
HK Angestellte
Hong Kong
NY Angestellte
Verteilung erlaubt
parallele Ausführung
London
Payroll App
Gesamte
Payroll App
London
New York Payroll
App
Lon, NY
Angestellte
London Payroll
App
HK Angestellte
Hong Kong
New York
NY, HK
Angestellte
Datenreplikation
Typen von verteilten Datenbanken
• Homogen: auf jedem Knoten läuft der gleiche Typ des DBMS
• Heterogen: auf verschiedenen Knoten laufen verschiedene DBMS
(relationale oder auch nicht-relationale DBMS)
Gateway
Gateway
Gateway
DBMS1
DBMS2
DBMS3
• Ein Gateway: ein Software, der die Anfragen weiter an dem lokalen
DBMS sendet und dann das Ergebnis an dem Anfragesteller schickt
Besonderheiten in VDBMS (verteilte DBMS)
• VDBMS Entwurf
• Entscheiden welche Daten wo gespeichert werden
• Dazu ist ein umfassendes Wissen über die zu erwartenden Anwendungen auf
der Datenbank notwendig
• Zwei Probleme:
• Fragmentierungsschema: logisch zusammengehörige Relationen werden
in disjunkte Fragmente zerlegt
• Daten mit ähnlichem Zugriffsmuster werden in einem Fragment
zusammengefasst
• Zuordnungsschema / Allokationsschema: die Zuordnung der Fragmente
auf Stationen
Besonderheiten in VDBMS (verteilte DBMS)
• Verteilte Anfragebearbeitung
• Es ist die Aufgabe des Anfrageübersetzers, einen Anfrageauswertungsplan auf den
Fragmenten zu generieren → Fragmentierungstransparenz
• Zusätzliche Aspekten zu betrachten im verteilten Fall:
• Kommunikationskosten
• Parallele Anfragebearbeitung
• Viel mehrere möglichen Ausführungspläne
• Verteilte Nebenläufigkeitskontrolle (Concurrency Control)
• Transaktionen können sich über mehrere Rechnerknoten entstrecken
• Globale Serialisierbarkeit
• Erkennung und Vermeidung von Deadlocks in verteilten Datenbanken
• Replizierte Daten bei Änderungen synchronisieren (mehrere Kopien auf
unterschiedlichen Knoten)
Besonderheiten in VDBMS (verteilte DBMS)
• Fehlermöglichkeiten im verteilten Fall
• Knotenfehler: Totalausfall oder partieller Ausfall
• Kommunikationsfehler
• Nachrichtenverlust, Nachrichtenverfälschung, doppelte Nachrichten
• Netzwerkpartitionierung: Aufteilung betriebsbereiter Rechner in disjunkte
Partitionen
• Gefährdung der Atomarität von Transaktionen
• Verteilte Commit-Protokolle
• Anforderungen
• Verteilte Synchronisation zur Gewährleistung der Konsistenz
• Commit als atomares Ereignis! Gleichzeitigkeit bei verteilten Knoten
VDBMS Architekturen
Klient-Server
• Ein „degeneriertes“ VDBMS, nur der Server speichert Daten ab
• Klient sendet eine Abfrage an einen einzigen Knoten.
• Gesamte Query-Verarbeitung findet auf Server statt
• Die Klienten können also DatenverarbeitungsKlient
operationen nur im Zusammenspiel mit dem
Abfrage
zentralen Server durchführen
Server
Klient
VDBMS Architekturen
Kollaboratives Server
• Eine Abfrage kann sich über mehrere
Rechnerknoten entstrecken
Middleware System
• Eine Abfrage wird von einem Knoten
bearbeitet, aber eine Transaktion kann
sich über mehrere Recherknoten
entstrecken
• Spezielle Softwareschicht zur
Koordination von Queries und
Transaktionen zwischen mehreren DBMS
Server
Abfrage
Server
Klient
Server
Abfrage
Klient
Server
Middleware
Server
Server
Storing Data
• Fragmentierung
• Horizontal: gewöhnlich disjunkt
• Vertikal: Zerlegung in verlustfreie JoinRelationen
• Replikation
• Erhöhte Verfügbarkeit
• Schnellere Query-Verarbeitung
• Synchron vs. Asynchron
TID
Id1
Id2
Id3
Fragmentierung
• Fragmentierung: eine Relation wird in kleineren Teile, Fragmente, aufgeteilt;
anstatt die ganze Relation werden die Fragmente auf die Stationen gespeichert
• Verschieden Methoden zur Fragmentierung einer Relation:
• Horizontale Fragmentierung: die Relation wird in disjunkte Tupelmengen zerlegt
mit Hilfe einer Qualifikationsbedingung
• Primäre horizontale Fragmentierung: Eine Tupelaufteilung aufgrund einer
Qualifikationsbedingung, die nur auf Attributen der Ausgangrelation beruht
• Abgeleitete horizontale Fragmentierung: wenn zur Auswertung der
Qualifikationsbedingung eine Verbundoperation mit einer anderen Relation
erforderlich ist
• Vertikale Fragmentierung: Attribute mit gleichem Zugriffsmuster werden
zusammengefasst
• Verlustfreier Join (lossless-join)
• Die Relation wird vertikal durch Ausführung von Projektionen zerlegt
• Kombinierte Fragmentierung
Korrektheits-Anforderungen
• Korrektheits-Anforderungen an eine Fragmentierung
R ⇒ F = {F1, F2, ...,Fn}
1. Rekonstruierbarkeit: Die fragmentierte Relation lässt sich aus den
Fragmenten wiederherstellen
Es gibt eine Abbildung g, so dass R = g(F1, F2, ..., Fn)
1. Vollständigkeit: Jedes Datum ist einem Fragment zugeordnet
∀ x ∈ R, ∃ Fi ∈ F, so dass x ∈ Fi
1. Disjunktheit: Die Fragmente überlappen sich nicht, d.h. Ein Datum ist nicht
mehreren Fragmenten zugeordnet
∀ x ∈ Fi , ∄ Fj so dass x ∈ Fj , i≠j
Allokation
• Man unterscheidet zwei Arten der Allokation:
• Redundanzfreie Allokation: jedes Fragment wird genau einer Station zugeordnet
• Eine N:1 Zuordnung
• Allokation mit Replikation: einige Fragmente werden repliziert und mehreren
Stationen zugeordnet
• Eine N:M Zuordnung
Katalogverwaltung
• Kontrolle darüber notwendig, wie die Daten über die einzelnen
Knoten hinweg verteilt werden
• Globale Kataloge: enthalten Metadaten wie: das globale
konzeptionelle Schema, das Fragmentierungsschema sowie das
Allokationsschema
• Lokale Kataloge: enthalten Metadaten, die nur knotenlokale
Bedeutung haben (z.B. Lokales konzeptionelles Schema)
• Die Metadaten werden selbst als Relationen abgelegt → die VDBMS
Zugriffsmechanismen können die Metadaten nutzen
• Die Verteilung der Metadaten spielt auch eine wichtige Rolle
Katalogverwaltung
Mögliche Architekturen im verteilten Fall eines globalen Katalogs:
• Zentralisierter Katalog: in einem zentralen Knoten gespeichert
• Hoher Kommunikationsaufwand, potentielle Leistungs- und Verfügbarkeitsprobleme
• Replizierter Katalog: jeder Knoten enthält eine vollständige Kopie der globalen Katalogdaten
• Vorteil: Zugriff um Daten zu lesen ist immer local
• Nachteil: Änderungen sind sehr aufwendig
• Mehrfachkataloge: die Rechner sind in Clusters partitioniert, wobei pro Cluster jeweils ein
Knoten den globalen Katalog hält
• Reduziertes Änderungsaufwand
• Kommunikation für jeden globalen Katalogzugriff ist weiterhin erforderlich
• Partitionierter Katalog: der globale Katalog wird unter allen Rechner partitioniert gespeichert
• Unterstützt den höchsten Grad an Knotenautonomie
• Der Nachteil der Kommunikationsvorgänge für Katalogzugriffe kann durch ein Caching
abgeschwächt werden
Katalogverwaltung
• Es muss möglich sein, jedes Replikat von jedem Fragment zu
indentifizieren
• Anforderungen:
• Globale Eindeutigkeit
• Ortsunabhängigkeit
• Lokal autonome Namensvergabe: bei Erzeugung neuer Objekte soll eine
lokale Namensvergabe möglich sein, welche die globale Eindeutigkeit
sicherstellt ohne Kommunikation mit anderen Knoten → Knotenautonomie
• <local-name, birth-site>
• <local-name, birth-site, replica-id> - global eindeutige Kombination aus lokalem Name
und Ursprungsknoten (wo die Relation erzeugt wurde)
Katalogverwaltung
• Bei der Verwaltung und Speicherung von Objekten sind drei Arten von
Knoten beteiligt:
• Birth site / Ursprungsknoten – der Knoten an dem ein Objekt erzeugt wurde
• Catalog site – der/die Knoten, an dem Katalogdaten zu dem Objekt verwaltet
werden
• Store site – die Knoten, an denen das Objekt gespeichert ist
• Site Catalog: beschreibt alle Objekte (Fragmente, Replikate) auf einem
Knoten und kontrolliert die Replikate der Relationen, die auf diesem
Knoten erzeugt wurden
• Zum Auffinden einer Relation genügt das Suchen im Katalog seines
Ursprungsknotes
• Ursprungsknoten ändert sich niemal, auch beim Verschieben der Relation zu
anderen Knoten
Daten Replikation
• Eine Relation oder Teile der Relation (Fragmente) werden repliziert
und die Kopien werden unterschiedlichen Stationen zugeordnet
• Nur Leseanwendungen werden bevorteilt → effiziente
Anfragebearbeitung (man kann eine lokale Kopie benutzen)
• Änderungen müssen auf allen Kopien durchgeführt werden
• Ziele:
• Erhöhung der Verfügbarkeit und der Zuverlässigkeit (wenn ein Server ausfällt,
dann kann man einen anderen benutzen)
• Eine Verbesserung des Antwortzeitverhaltens
Daten Replikation - Beispiel
• R ist in R1, R2 und R3 fragmentiert
• R1 wird auf dem Knoten A und B repliziert
Knoten B
Knoten A
R1
R3
R1
R2
Daten Replikation
• Synchrone Replikation:
Alle Kopien der geänderten Relation/Fragment müssen geändert
werden vor dem Commit der modifizierenden Transaktion
• Datenverteilung ist transparent für die Benutzer
• Asynchrone Replikation:
Kopien der modifizierten Relation/Fragment werden nur regelmäßig
synchronisiert
• Verschiedene Kopien können inzwischen inkonsistent werden
• Heutige Produkte folgen diesem Ansatz (komerziell verfügbare Replication
Server)
Synchrone Replikation
• Voting Verfahren: Transaktion muss eine Mehrheit der Kopien schreiben,
um ein Objekt zu modifizieren; Transaktion muss genung Kopien lessen,
um sicher zu sein,zumindest eine jüngste Kopie zu sehen
• Bsp.: 10 Kopien, 7 geschrieben für Update, 4 Kopien lesen
• Jede Kopie hat eine Version-Nummer
• Gewöhnlich nicht attraktiv weil Read sehr häufig sind
• Read-any Write-all Verfahren / Read-one-Write-all (ROWA): Verlangt
die synchrone Änderung aller Replikate vor Abschluss der Transaktion
• Dadurch wird gesichert, dass jedes Replikat auf dem aktuellen Stand ist
• Zum Lesen kann jedes beliebige Replikat ausgewählt werden → erhöhte
Verfügbarkeit für Lesezugriffe
• Relativ zum Voting: Writes sind langsamer und Read sind schneller
• Verbreitester Ansatz zur synchronen Replikation
Synchrone Replikation - Kosten
• Bevor eine Update-Transaktion ein Commit machen kann, muss sie
sperren auf allen modifizierten Kopien erhalten:
• Sendet Sperranforderungen an die anderen Knoten, wartet auf Antowrt, hält
die anderen Sperren
• Wenn Knoten oder Verbindungen fehlerhaft sind, kann die Transaktion kein
Commit machen, bis ein Backup aktiv ist
• Selbst, wenn kein Fehler auftritt, folgt das Commit einem teuren CommitProtokoll mit vielen Messages
• Daher ist die Alternative asynchrone Replikation weit verbreitet
Asynchrone Replikation
• Erlaubt der Update-Transaktion ein Commit, bevor alle Kopien
geändert wurden (wobei Leser trotzdem nur eine Kopie sehen)
• Benutzer müssen wissen, welche Kopie sie lesen und dass Kopien für
kurze Zeitabschnitte inkonsistent sein können
• Zwei Ansätze:
• Primary-Site Replikation (Primary-Copy)
• Peer-to-Peer Replikation
• Differenz besteht darin, wieviele Kopien änderbar sind (diese heißen auch
Master-Kopien)
Asynchrone Replikation:
Peer-to-Peer Replikation
• Mehr als eine der Kopien eines Objektes kann Master sein
• Änderungen auf einer Master-Kopie müssen irgendwie zu anderen Kopien hin
propagiert werden
• Wenn zwei Master-Kopien in einer Weise geändert werden, die zum Konflikt führt,
muss dies aufgelöst werden, z.B.:
• Knoten 1: Alter von Markus wurde auf 35 geändert
• Knoten 2: Alter von Markus wurde auf 36 geändert
• Am besten einsetzbar, wenn keine Konflikte entstehen können:
• Beispiel: Jeder Masterknoten besitzt ein disjunktes (horizontales) Fragment → Änderungen
der Daten von deutschen Angestellten in Frankfurt, Änderungen bei indischen Angestellten in
Madras, obwohl gesamte Datenmenge in beiden Knoten gespeichert
• Beispiel: Änderungsrechte liegen zu einem bestimmten Zeitpunkt bei nur einem Master
Asynchrone Replikation:
Primary-Site Replikation
• Genau eine Kopie einer Relation wird bestimmt als Primär- oder
Masterkopie. Replikate auf anderen Knoten dürfen nicht direkt geändert
werden
• Die Primärkopie ist öffentlich (public)
• Andere Seiten abonnieren diese Relation bzw. Fragmente davon
(subscribe); diese weden als Sekundärkopien bezeichnet
• Die Aktualisierung der anderen Replikate wird dann asynchron vom PrimaryCopy-Rechner aus durchgeführt (nach Ende der Änderungstransaktion)
Asynchrone Replikation:
Primary-Site Replikation
Hauptproblem: Wie werden Änderungen auf der Primärkopie zu den
Sekundärkopien propagiert?
• Erfolgt in zwei Schritten:
1. Erfassen der Änderungen, die von den erfolgreich beendeten
Transaktionen gemacht wurden (Capture)
2. Durchführen dieser Änderungen (Apply)
Implementierung des 1. Schritts:
Capture (Erfassung)
• Log-Basierte Erfassung: Der Log (angelegt für Recovery) wird
verwendet zur Generierung einer Tabelle der geänderten Daten =
Change Data Table (CDT)
• Beim Schreiben des aktuellen Log-Abschnitts auf Platte muss darauf geachtet
werden, dass die Änderungen wieder entfernt werden, die von später
abgebrochenen Transaktionen stammen
• Prozedurale Erfassung: Eine Prozedur, die automatisch aufgerufen wird
(z.B. Trigger), macht die Erfassung :
• Typisch ist die Aufnahme eines Schnappschusses der Primärkopie (Snapshot)
Implementierung des 1. Schritts:
Capture (Erfassung)
• Log-Basierte Erfassung ist besser als Prozedurale Erfassung:
• Geringer Aufwand → billiger
• Geringere Verzögerung zwischen Änderung der Daten und der Propagierung
der Änderungen → schneller
• Nachteil: erfordert vertieftes Verständnis der Struktur der system-spezifischen
Logs
Implementierung des 2. Schritts: Apply
• Der Apply-Prozess auf dem Sekundärknoten bekommt periodisch
Snapshots oder Änderungen der Änderungstabelle vom Primärknoten und
ändert die Kopie
• Periode kann zeitbasiert sein oder definiert durch Benutzer / Applikation
• Replikat kann auch ein Sicht auf der modifizierten Relation sein
• In diesem Fall besteht die Replikation aus einem inkrementellen Update der
materailisierten Sich, wenn sich die Relation ändert
• Log-basierte Erfassung zusammen mit einem kontinuierlichen Apply der
Änderungen minimiert die Verzögerung bei der Propagierung der
Änderungen
• Prozedurale Erfassung zusammen mit einem applikations-getriebenen
(application-driven) „Apply“ der Änderungen ist die flexibelste Art,
Änderungen zu verarbeiten
Data Warehousing und Replikation
• Aktueller Trend: Aufbau gigantischer Data Warehouses, die aus vielen
Knoten bestehen
• Erlaubt komplette Anfragen zur Entscheidungsunterstützung (Decision Support)
auf Daten über die ganze Organisation hinweg
• Warehouses können als eine Instanz von asynchroner Replikation
gesehen werden
• Source-Daten typischerweise kontrolliert durch verschiedene DBMS
• Schwerpunkt auf Bereinigung der Daten (Data Cleaning) und Beseitigung von
syntaktischer und semantischer Heterogenität (z.B. $ vs € ) beim Erzeugen der
Replikate
• Schnapschuss-Replikation (prozedurale Erfassung):
• wird durch zunehmende Anzahl komerzieller Produkte unterstützt (z.B. IBM Data
Propagator, Oracle Replication Server)
Beispiel – Verteilte Queries
SELECT AVG(S.Age)
FROM Sailors S
WHERE S.Rating > 3
AND S.Rating < 7
• Horizontal Fragmentiert: Tupel mit Rating < 5 in Shanghai, >= 5 in
Tokio
• Muss die Funktionen SUM(Age), COUNT(Age) auf beiden Knoten berechnen
• Wenn die WHERE-Klausel hieße: S.Rating >= 6, wäre nu ein Knoten beteiligt
• Vertikal Fragmentiert: SId und Rating in Shanghai, Sname und Age in
Tokyo, TId in beiden
• Relation muss über den Tupel-Identifier TId durch Join rekonstruiert werden,
danacah Auswertung der Query
• Repliziert: Kopien der Relation Sailors auf beiden Seiten
• Wahl des Knoten basiert auf lokalen Kosten und Transportkosten