Verteilte Datenbanken

Transkript

1 Verteilte Datenbanken

2 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

3 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

4 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 (ACID- Eigenschaften)

5 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?

6 London Payroll App New York Payroll App London Angestellte New York Hong Kong Payroll App NY und HK Payroll Apps sind sehr langsam! Hong Kong

7 London Payroll App New York Payroll App London Lon Angestellte New York NY Angestellte Hong Kong Hong Kong Payroll App HK Angestellte Verteilung erlaubt parallele Ausführung

8 London Payroll App New York Payroll App London Gesamte Payroll App Lon, NY Angestellte New York NY, HK Angestellte London Payroll App Datenreplikation Hong Kong HK Angestellte

9 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

10 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

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

12 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

13 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 Datenverarbeitungsoperationen nur im Zusammenspiel mit dem zentralen Server durchführen Klient Abfrage Klient Server

14 VDBMS Architekturen Kollaboratives Server Eine Abfrage kann sich über mehrere Rechnerknoten entstrecken Klient Abfrage Server Server Server 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 Klient Abfrage Middleware Server Server Server

15 Storing Data Fragmentierung Horizontal: gewöhnlich disjunkt Zerlegung einer Relation in disjunkte Tupelmengen Zerlegung durch Selektionen Vertikal: Zerlegung in verlustfreie Join- Relationen Zusammenfassen von Attributen mit gleichen Zugriffsmustern Zerlegung durch Projektionen Replikation Erhöhte Verfügbarkeit Schnellere Query-Verarbeitung Synchron vs. Asynchron TID Id1 Id2 Id3

16 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

17 Korrektheits-Anforderungen Korrektheits-Anforderungen an eine Fragmentierung R F = {F 1, F 2,...,F n } 1. Rekonstruierbarkeit: Die fragmentierte Relation lässt sich aus den Fragmenten wiederherstellen Es gibt eine Abbildung g, so dass R = g(f 1, F 2,..., F n ) 1. Vollständigkeit: Jedes Datum ist einem Fragment zugeordnet x R, F i F, so dass x F i 1. Disjunktheit: Die Fragmente überlappen sich nicht, d.h. Ein Datum ist nicht mehreren Fragmenten zugeordnet x F i, F j so dass x F j, i j

18 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

19 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

20 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 lokal 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

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

22 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

23 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

24 Daten Replikation - Beispiel R ist in R 1, R 2 und R 3 fragmentiert R 1 wird auf dem Knoten A und B repliziert Knoten A Knoten B R 1 R 3 R 1 R 2

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

26 Synchrone Replikation Voting Verfahren: Transaktion muss eine Mehrheit der Kopien schreiben, um ein Objekt zu modifizieren; Transaktion muss genung Kopien lesen, 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

27 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 Commit- Protokoll mit vielen Messages Daher ist die Alternative asynchrone Replikation weit verbreitet

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

29 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

30 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 Primary- Copy-Rechner aus durchgeführt (nach Ende der Änderungstransaktion)

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

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

33 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

34 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

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

36 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 Tokyo Muss die Funktionen SUM(Age), COUNT(Age) auf beiden Knoten berechnen Wenn die WHERE-Klausel hieße: S.Rating >= 6, wäre nur 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