Verteilte Datenbanken

Transkript

1 Verteilte Datenbanken Stand der Technik: Zentrale oder Verteilte Datenbanken Bisher (implizit) diskutiert: Zentraler Ansatz, d. h. keine Netzwerke berücksichtigt: Terminals / Arbeitsplatzrechner DB 1 Zentraler Rechner DB 2 1

2 Verteilte Datenbanken: Begriffe und Motivation Lokalität kliäin Abteilungen / Teilorganisationen i i / Virtuelle Organisationen Inkompatible Datenbestände; nur Teil im globalen Datenbankschema Integration wg. langer Prozessketten über Organisations /Besitzgrenzen hinweg Guter Ansatz: verteilte, logisch konsistente Datenhaltung: Datenfragmente Mehrere Architekturen denkbar: Eine DB heißt verteilt (VDB), wenn sie koordiniert auf mehrere Rechner (Knoten) verteilt und von jedem Arbeitsplatz zugreifbar ist Verteiltes DBMS (VDMBS) kann verteilte DB verwalten VDMBS heißt ortstransparent, wenn für die Nutzer der Daten die Verteilung nicht relevant (d. h. sichtbar) ist. Mindestens folgende Anforderungen an VDB: Die Daten sind auf zwei oder mehr Rechner verteilt Die Rechner sind vernetzt Dem Nutzer steht die DB so zur Verfügung, als wenn sie auf einem zentralen (lokalen) l Konten gehalten würde 2

3 Verteilte Datenbanken: Verteilungsaspekte Auf zwei (Datenbank )Server verteilte Datenbanksysteme: Terminals / Arbeitsplatzrechner Rechner 1 DB 1; Teil 1 DB 2; Teil 1 Netz Rechner 2 DB 1; Teil 2 DB 2; Teil 2 Terminals / Arbeitsplatzrechner 3

4 Verteilte Datenbanken: Verteilungsaspekte Verteilte, offene Architektur WS 4 WS 6 DB-Fragment DB-Fragment Server 1 DB-Fragment WS 2 WS 3 DB-Fragment WS 5 Server 2 DB-Fragment WS 1 Server 3 4

5 Verteilte Datenbanken: Hintergrund Gründe für und gegen Datenverteilung: Für Datenverteilung sprechen in der Regel: Kosten Leistung (Performanz, Zuverlässigkeit und Verfügbarkeit) Flexibilität Organisationskultur Gegen Datenverteilung sprechen in der Regel: Netzkosten Konsistenz Zugriffsintegrität Einheitliches Datenmodell 5

6 Datenverteilung Verteilte Datenbanken: Konzepte Horizontal: durch Selektion Vertikal: durch hprojektion Beispiel: Die Personalverwaltung eines Unternehmens mit mehreren Standorten: In dem konzeptionellen Schema der Unternehmens DB existiere eine zu verteilende Relation Personal(P_ID, Name, Adresse, Standort, Abteilung) mit folgender Extension: Personal P_ID Name Adresse Standort Abteilung Müller, E. Dülmen Münster F Schulte, A. Bielefeld Bielefeld A Brauer, G. Hagen Dortmund A Meier, G. Dortmund Dortmund A Vetter, H. Bochum Münster F Gerdes, U. Paderborn Münster F Taubner, F. Geseke Bielefeld A Hagen, U. Hamm Dortmund F1 6

7 Verteilte Datenbanken: Konzepte Beispiel der Fragmentierungsspezifikation : Die Verteilung ist so durchzuführen, dass Namen und Adressen lokal vor Ort verwaltet werden, während die Zuordnung zu Abteilungen und Standorten von der Hauptverwaltung vorgenommen wird. Durch Projektion auf die relevanten Attribute P_ID ID, Name Name, Adresse und Standort erhält man die relevanten Daten in der Tabelle Personal_F: Personal_F P_ID Name Adresse Standort Müller, E. Dülmen Münster Schulte, A. Bielefeld Bielefeld Brauer, G. Hagen Dortmund Meier, G. Dortmund Dortmund Vetter, H. Bochum Münster Gerdes, U. Paderborn Münster Taubner, F. Geseke Bielefeld Hagen, U. Hamm Dortmund 7

8 Verteilte Datenbanken: Konzepte Vertikale Fragmentierung, dh d.h. Slki Selektion der Daten für die einzelnen Standorte, erzeugt aus Personal_F die jeweiligen Relationen für die Standorte, indenen dann Standort Standort überflüssig ist; Personal_DO P_ID Name Adresse Brauer, G. Hagen Meier, G. Dortmund Hagen, U. Hamm Personal_MS P_ID Name Adresse Müller, E. Dülmen Vetter, H. Bochum Gerdes, U. Paderborn Personal_BI P_ID Name Adresse Schulte, A. Bielefeld Taubner, F. Geseke 8

9 Verteilte Datenbanken: Konzepte Eine zweite Projektion liefert aus Personal die relevanten Informationen für die Hauptverwaltung in der Tabelle Personal_HV. Diese müssen den angegebenen Umfang haben: Personal_HV P_ID Standort Abteilung Münster F Bielefeld A Dortmund A Dortmund A Münster F Münster F Bielefeld A Dortmund F1 9

10 Verteilte Datenbanken: Konzepte In verteilten Datenbanken wird häufig auch Replikation eingesetzt: t Identische Daten auf mehreren Knoten Vorteil lokale Autonomie: Unabhängigkeit gg der Knoten Notwendig: ausgezeichnetes Original Alle anderen Vorkommen sind Duplikate Nachteil: Hoher Änderungsaufwand d Wichtig: Konsistenz: Alle Duplikate müssen jederzeit dem Original entsprechen; geändert wird immer nur das Original: Lokale Autonomie nur bzgl. Abfragen immer erreichbar Eigenschaften verteilter Datenbanken: Ortstransparenz Replikationstransparenz lk Fragmentierungstransparenz Integriert Föderiert 10

11 Verteilte Datenbanken: Architekturen Kommunikationssystembasiert Eine einheitliche Kommunikationsinfrastruktur für die verteilten Datenbanken Der Nutzer (Anwendungsprogramm) sieht ihtdie Lokationen: keine ki Verteilungstransparenz Nutzer kann lokale Dialekte ausnutzen Keine verteilte Datenbank im eigentlichen Sinne Benutzer Kommunikationssystem Datenbank 1 Datenbank 2 Datenbank 3 11

12 Verteilte Datenbanken : Architekturen Homogene verteilte Datenbank Ein verteiltes Datenbankmanagementsystem wird genutzt Ott Ortstransparenz gegeben Heute die übliche Implementierung verteilter DB auf der grünen Wiese Benutzer VDBMS Kommunikationssystem t Daten 1 Daten 2 Daten 3 12

13 Verteilte Datenbanken : Architekturen Heterogenes (verteiltes) DBS A1 A2 A3 An Transaktionsverwalter Einheitliches Datenmodell Kommunikationssystem Übersetzer m Übersetzer 1 Übersetzer 2 Umsetzung Datenverwalter 1 Datenverwalter 2 Datenverwalter m Betriebssystem 1 Betriebssystem 2 Betriebssystem m Hardware 1 Hardware 2 Hardware m Daten 1 Daten 2 Daten m 13

14 Verteilte Datenbanken: Schemata Vollständig integriertes verteiltes DBS Benutzer der verteilten Datenbank globales externes Schema globales externes Schema globales externes Schema globales konzeptionelles Schema Benutzer Teil- Datenbank Verteilungsfunktion lokales externes Schema lokales konzeptionelles Schema 1 lokales konzeptionelles Schema 2 lokales konzeptionelles Schema 3 14

15 Verteilte Datenbanken: Schemata Föderiertes verteiltes DBS Benutzer der verteilten Datenbank globales externes Schema lokales konzeptionelles Schema 1 lokales konzeptionelles Schema 2 lokales konzeptionelles Schema 3 15

16 Verteilte Datenbanken: Probleme Verteilung kann zu vermehrtem Aufwand bei Anfragen führen: Beispiel: Die Tabellen Personal und Abteilung sind auf zwei Knoten verteilt: Personal V_Name N_NameName P_ID Geb_Dat Adr M_W Gehalt Vorg Abt_Nr Personal auf Knoten 1 mit Tupeln der Größe 100 Bytes. Tabellengröße = 10 6 Bytes. Abteilung Abt_Name Abt_ID Abt_Leiter Abt_Leiter_Seit Abteilung auf Knoten 2 mit 100 Tupeln der Größe 35 Bytes. Tabellengröße = 3500 Bytes. Q: Gib mir den Namen eines jeden Mitarbeiters zusammen mit dem Namen der zugehörigen Abteilung. Q: V_Name,N_Name,Abt_Nname (Personal Abt_Nr = Abt_ID Abteilung) Ergebnis hat Tupel a ca. 40 Bytes und wird von Knoten 3 angefragt. Strategien: 1. Transferiere Personal und Abteilungstabellen zu Knoten 3: Bytes 2. Transferiere Personal zum 2. Knoten, führe Join durch und sende Ergebnis an Knoten 3: Bytes 3. Transferiere Abteilungsrelation zum Knoten 1, führe Join durch und sende Ergebnis an Knoten 3: Bytes 16

17 Verteilte Datenbanken: Probleme Eine Transaktion bei verteilten Daten soll identische Eigenschaften haben wie im lokalen Fall (ACID Eigenschaften) Eine verteilte Tx wird durch eine Menge lokalertx (Subtransaktionen auf Knoten) realisiert, die von einer Wurzeltransaktion (auf dem Koordinator = Knoten mit Änderungsauftrag) gesteuert werden (geschachtelte Tx) Geeignete Sperrkonzepte sind zu realisieren Zentrales Sperren (Sperrknoten) Alle Sperren Mehrheitssperren Oii Originalsperre Fehlermöglichkeiten Abbruch Subtransaktion (z. B. Konsistenzfehler, Knotenausfall) Knotenausfall während der Kommunikation Verlust / Verdopplung von Nachrichten Langandauernder Ausfall der Kommunikationsverbindung 17

18 Verteilte Datenbanken: Probleme Lösung: 2 Phase Commit Protokoll (2PC): Phase 1: Koordinator gibt Auftrag an alle Knoten mit prepare to commit Knoten entscheiden und liefern commit oder abort Jeder Knoten nutzt lokal 2PL, bei commit sind alle Sperren gesetzt (Sperrphase) Phase 2: Sobald alle Knoten geantwortet haben, entscheidet der Koordinator: Falls alle Knoten commit dann commit an alle Knoten: Knoten führt lokale Tx nach 2PL zu Ende: anschließend alle Sperren wieder frei (Entsperrphase) p Ansonsten: abort an alle Knoten: Knoten, die commit in Phase 1 gesendet hatten machen ein undo auf Tx spezifischen Operationen. Die Knoten führen die Aktion aus und senden o.k. an Koordinator Sobald der Koordinator ein o.k. von allen Knoten empfangen hat, beendet er die Transaktion. 18