IT-Academy Logo
Sign Up Login Help
Home - Programmieren - Datenbanken - Verteilte Datenbanksysteme



Verteilte Datenbanksysteme

Dieser Artikel geht auf die Grundlage verteilter Datenbanksysteme ein. Kernpunkte sind unter anderem die Transparenz bei der Datenverteilung und bei der Transaktionsverwaltung.


Autor: Patrick Bucher (paedubucher)
Datum: 29-05-2007, 14:44:08
Referenzen: Datenbanken - Grundlagen und Design, Frank Geisler, MITP-Verlag, jetzt bei Amazon.de kaufen!
Schwierigkeit: Fortgeschrittene
Ansichten: 8996x
Rating: Bisher keine Bewertung.

Hinweis:

Für den hier dargestellte Inhalt ist nicht der Betreiber der Plattform, sondern der jeweilige Autor verantwortlich.
Falls Sie Missbrauch vermuten, bitten wir Sie, uns unter missbrauch@it-academy.cc zu kontaktieren.

[Druckansicht] [Als E-Mail senden] [Kommentar verfassen]



Bei der klassischen Client/Server-Architektur läuft das Datenbanksystem auf einem Server, auf den dann mehrere Clients zugreifen.

Das Problem an dieser Architektur ist, dass man so einen sog. "single point of failure" hat, also eine einzige Fehlerquelle. Fällt dieser Server aus, so steht die gesamte Datenbank nicht mehr zur Verfügung.

Ausserdem genügt diese Architektur sehr grossen Unternehmen oftmals nicht, da diese dezentral organisiert sind (mehrere Filialen). Die Client/Server-Architektur spiegelt diesen Sachverhalt nicht korrekt wieder. Hierzu sind verteilte Datenbanken besser geeignet.

Vor- und Nachteile verteilter Datenbanken

Bei bestimmten Anwendungen haben verteilte Datenbanken klare Vorteile gegenüber der Datenverwaltung nach der Client/Server-Architektur:

  • Durch eine Verteilung der Daten kann man erreichen, dass die benötigten Daten näher beim Anwender sind, als das es bei einer monolithischen Datenbank der Fall ist.
  • Manche Daten sind ortsspezifisch. Es macht beispielsweise keinen Sinn, dass in der Berner Filiale die Kundendaten von der Zürcher Filiale einsehbar sind. So halten die einzelnen Teile der Datenbank nur die Daten, die sie auch wirklich benötigen. Dies reduziert die zu durchsuchende Datenmenge.
  • Stürzt ein einzelner Datenbankserver ab, so bedeutet dies nur für die betreffende Filiale einen Ausfall. Die anderen Filialen können wie gewohnt weiter arbeiten.
  • Der Netzwerkverkehr kann unter Umständen reduziert werden. Zudem wird keine enorme Bandbreite für einen einzigen zentralen Server benötigt.

Selbstverständlich hat eine verteilte Datenbank gewisse Nachteile gegenüber einer zentralen:

  • Das System wird deutlich komplexer in der Planung, in der Wartung und auch in der Implementierung.
  • Daten werden an verschiedenen Orten gehalten und auch verändert. Diese Daten müssen miteinander abgeglichen werden, was zu Konflikten führen kann. Damit keine Inkonsistenzen auftreten, muss das verteilte Datenbanksystem Mechanismen zur Behebung dieser Konflikte zur Verfügung stellen.
  • Erlaubt man, dass die Anwender der verschiedenen Filialen auf allen Teil-Datenbanken Änderungen vornehmen können, so kann es zu Deadlocks über mehrere Rechner hinweg kommen.
  • Es fehlen noch Standards für die Kommunikation verteilter Datenbanken untereinander. Dies stellt vor allem bei verteilten Datenbanken ein Problem dar, die aus verschiedenen Produkten bestehen (MS SQL Server, Oracle usw.).

Das Distributed Database Management System

Ein verteiltes Datenbanksystem besteht aus mehreren DBMS (Database Management System) und wird durch ein sog. DDBMS (Distributed Database Management System) zusammengehalten. Dieses steuert sowohl die verteilte Datenverarbeitung als auch die verteilte Datenhaltung.

Aufgaben des DDBMS:

  • Optimierung der Datenbankabfragen
  • Ermittlung des optimalen Zugriffsweg zu den Daten
  • Sicherheitsfunktionen, Backup und Recovery
  • Transaktionsverwaltung über die einzelnen DBMS hinweg
  • Abstraktion der verteilten Datenbank (der Benutzer soll nur eine Datenbank "sehen")

Datenmanager und Transaktionsmanager

Ein DDBMS enthält also sämtliche Funktionen eines "normalen" DBMS. Dazu kommen jedoch noch zwei Komponenten; der Datenmanager und der Transaktionsmanager.

Der Transaktionsmanager ist ein Programm, dass auf jedem Rechner ausgeführt wird, der auf das verteilte Datenbanksystem zugreifen muss. Dieser kümmert sich darum, dass die Anfragen der einzelnen Clients an das richtige Datenbanksystem weitergeleitet werden. Weiter muss er die Antworten der verschiedenen Datenbanksysteme entgegennehmen und für den Client entsprechend zusammenstellen.

Der Datenmanager wird auf jedem DBMS ausgeführt. Dieser kümmert sich darum, dass die Antworten (Abfrageergebnisse) an die richtigen Clients bzw. an den richtigen Transaktionsmanager gesendet werden.

Vollständig verteiltes Datenbanksystem

Bei einem vollständig verteiltem Datenbanksystem ist sowohl die Datenhaltung als auch die Datenverarbeitung auf mehrere Rechner verteilt.

Dabei unterscheidet man zwischen homogenen und heterogenen Datenbanksystemen. Bei einem homogenen System wird auf jedem Rechner das gleiche Datenbanksystem eingesetzt (alle Rechner mit MS SQL Server, alle Rechner mit Oracle usw.). Dies steht im Gegensatz zum heterogenen Datenbanksystem, bei welchem auf den verschiedenen Rechner unterschiedliche Datenbanksysteme eingesetzt werden (MS SQL Server, Oracle, PostgreSQL usw. gemischt).

In der Praxis werden häufiger homogene als heterogene Datenbanksysteme eingesetzt, da derzeit noch einen Mangel an standardisierten Kommunikationsprotokollen zwischen den einzelnen Produkten besteht.

Replikation

Um den Zugriff auf bestimmte Daten zu beschleunigen, können diese auf verschiedene Teilsysteme repliziert (d.h. kopiert) werden. Replizierte Daten stellen eine weitere Gefahr für die Datenkonsistenz dar und müssen somit vom DDBMS synchronisiert werden.

Ob sich dieser Performancegewinn im Hinblick auf mögliche Dateninkonsistenzen und den Overhead beim DDBMS lohnt, ist in jedem Fall neu abzuwägen.

Transparenz

Transparenz bedeutet, dass ein Benutzer keine Kenntnis von den internen Abläufen eines Systems haben muss, um dieses anwenden zu können.

Stufen der Transparenz

Bei der Datenverteilung wird zwischen drei Transparenzstufen unterschieden:

  1. Vollständige Transparenz
    • Der Datenbankanwender weiss nicht, wo sich die Daten, mit den er arbeitet, physisch befinden.
    • Der Datenbankanwender kann das verteilte Datenbanksystem so verwenden, als ob es sich um eine einzige Datenbank handeln würde.
  2. Ortstransparenz
    • Der Datenbankanwender muss wissen, dass sich die Daten an verschiedenen Standorten befinden.
    • Wo sich diese Daten physikalisch befinden, muss der Datenbankanwender jedoch nicht wissen.
  3. Keine Transparenz
    • Der Datenbankanwender muss wissen, wie die Daten verteilt sind.
    • Zudem muss der Datenbankanwender wissen, wo sich welche Daten befinden.

Die vollständige Transparenz ist nicht nur in der Anwendung am komfortabelsten, sondern auch in der Wartung. Angenommen, die verteilte Datenbank wird um einen Standort erweitert, so muss bei der Ortstransparenz sowie auch bei fehlender Transparenz jeder SQL-Befehl an die neuen Gegebenheiten angepasst werden.

Eine vollständige Transparenz kann nur durch ein sog. "distributed Database Dictionary" erreicht werden. In diesem ist enthalten, welche Daten sich an welchem Standort befinden. Auf sämtlichen Teilsystemen muss sich eine aktuelle Kopie des distributed Databse Dictionaries befinden. Bei einer vollständigen Transparenz erhält das DDBMS somit noch eine weitere wichtige Aufgaben dazu.

Transaktionsverwaltung

Transparenz ist nicht nur bei der Datenverteilung wünschenswert, auch die Transaktionsverwaltung soll für den Benutzer komplett transparent ablaufen.

Werden bei einer Datenänderung die Daten von verschiedenen Teilsystemen geändert, so muss die Transaktion nicht nur für die einzelnen Teilsysteme, sondern über sämtliche Teilsysteme hinweg erfolgreich sein. Eine Transaktion ist somit bei verteilten Datenbanksystemen nur erfolgreich, wenn die Änderungen an sämtlichen Standorten durchgeführt werden konnten.

Im Falle eines Fehlers auf einem einzigen Teilsystem müssen die durchgeführten Operationen auf sämtlichen Teilsystemen wieder rückgängig gemacht werden.

Die Transaktionsverwaltung ist somit bei verteilten Datenbanken wesentlich komplexer als bei der zentralen Datenhaltung. Verteilte Datenbanken arbeiten darum mit einer erweiterten Transaktionsverwaltung, mit dem sog. 2-Phasen-Commit-Protokoll.

Das 2-Phasen-Commit-Protokoll

Beim 2-Phasen-Commit-Protokoll gibt es zwei Transaktionsstufen:

  1. Die Transaktionen auf den einzelnen Teilsystemen
  2. Die Transaktion über das gesamte System hinweg

Weiter stellt dieses Protokoll drei neue Mechanismen zur Verfügung:

  • DO
    • Die Operation (INSERT, UPDATE, DELETE) wird ausgeführt.
    • Die Werte vor und nach der Operation werden ins Transaktionsprotokoll geschrieben.
  • REDO
    • Die Operation, die mit DO in das Transaktionsprotokoll geschrieben wurde, wird endgültig ausgeführt (in die Datenbank geschrieben) und bestätigt (COMMIT).
  • UNDO
    • Die Änderungen werden mithilfe der Einträge aus dem Transaktionsprotokoll wieder rückgängig gemacht.

Sämtliche Änderungen werden zunächst ins Transaktionsprotokoll geschrieben, bevor sie in die eigentliche Datenbank aufgenommen werden. Das Transaktionsprotokoll wird jeweils persistent abgespeichert, um die Ausfallsicherheit zu erhöhen (dies wird als "write-ahead"-Modus bezeichnet).

Beispiel eines Ablaufs anhand eines UPDATE-Befehls:

  1. Ein Client sendet einen UPDATE-Befehl, der sämtliche Teilsysteme betrifft.
  2. Das DDBMS leitet diesen Befehl an sämtliche Teilsysteme weiter.
  3. Die Teilsysteme schreiben die Änderungen mit DO in das Transaktionsprotokoll.
  4. Nach einer Weile sendet das DDBMS den PREPARE TO COMMIT-Befehl an alle Teilsysteme, um diese auf den COMMIT-Befehl vorzubereiten.
  5. Die einzelnen Systeme beantworten diesen Befehl mit YES oder NO.
    • Antwortet mindestens ein Teilsystem mit NO, so sendet das DDBMS den Befehl ABORT an sämtliche Teilsysteme. Die Teilsysteme machen die vorgenommenen Änderungen mit UNDO wieder rückgängig. Die Transaktion ist fehlgeschlagen.
    • Antworten alle Systeme mit YES, so wird der Vorgang fortgesetzt.
  6. Das DDBMS sendet den COMMIT-Befehl an sämtliche Teilsysteme.
  7. Die Teilsysteme schreiben die Änderungen aus dem Transaktionsprotokoll nun in der Datenbank nieder (REDO).
    • Hat dies funktioniert, antwortet das jeweilige Teilsystem mit COMMITED. Die Transaktion wurde erfolgreich durchgeführt und ist somit abgeschlossen.
    • Ist die Aktualisierung fehlgeschlagen, antwortet das jeweilige Teilsystem mit NOT COMMITED.
      • Antwortet auch nur ein Teilsystem mit NOT COMMITED, so sendet das DDBMS den ABORT-Befehl an sämtliche Teilsysteme.
      • Jedes Teilsystem nimmt seine Änderungen wieder mit dem UNDO-Befehl zurück.
      • Die Transaktion ist fehlgeschlagen.

Mit dem 2-Phasen-Commit-Protokoll kann die Transaktionssicherheit auch über verteilte Datenbanken hinweg gewährleistet werden.

Datenfragmentierung

Einzelne Tabellen können auf verschiedene Standorte verteilt werden. Dies bezeichnet mal als Datenfragmentierung, ein Teilstück einer Tabelle wird als Datenfragment bezeichnet. Hier kommt das distributed Database Dictionary zum Zuge. Dieses enthält Informationen darüber, welche Datenfragmente sich auf welchen Teilsystemen befinden.

Es gibt drei Möglichkeiten, eine Tabelle zu fragmentieren:

  1. Horizontale Fragmentierung
    • Eine Tabelle wird anhand von Datensätzen aufgeteilt.
    • An jedem Standort befindet sich die gleiche Tabellenstruktur (die gleichen Spalten), jedoch nicht sämtliche Datensätze.
  2. Vertikale Fragmentierung
    • Jedes Tabellenfragment enthält alle Datensätze, jedoch nicht alle Informationen (Spalten) jedes Datensatzes.
    • Der Primärschlüssel muss bei sämtlichen Fragmenten vorhanden sein.
  3. Gemischte Fragmentierung
    • Eine Tabelle wird sowohl horizontal als auch vertikal fragmentiert.


[back to top]



Userdaten
User nicht eingeloggt

Gesamtranking
Werbung
Datenbankstand
Autoren:04508
Artikel:00815
Glossar:04116
News:13565
Userbeiträge:16552
Queueeinträge:06245
News Umfrage
Ihre Anforderungen an ein Online-Zeiterfassungs-Produkt?
Mobile Nutzung möglich (Ipone, Android)
Externe API Schnittstelle/Plugins dritter
Zeiterfassung meiner Mitarbeiter
Exportieren in CSV/XLS
Siehe Kommentar



[Results] | [Archiv] Votes: 1150
Comments: 0