Ein Zweiphasen-Commit-Protokoll gilt heute als State-of-the-Art für verteilte Datenbanken. Es gewährleistet maximale Datenkonsistenz, kostet allerdings Verarbeitungszeit. Matthias Engelbach* stellt diesem "synchronen" Realisierungskonzept ein "asynchrones" gegenüber, das - je nach Anforderung - vorteilhafter Alternative sein könnte.
Getragen von der technischen Entwicklung (Rechenleistung wird immer billiger) und den Anforderungen der Anwender (schneller Zugriff auf Daten, unternehmensweites Datenmodell, Minimierung der Auswirkungen von Ausfällen) werden zunehmend integrierte, dezentrale Rechnerumgebungen eingesetzt. Es handelt sich im allgemeinen um vernetzte Umgebungen, in denen Maschinen verschiedener Hersteller mit unterschiedlichen Betriebssystemen aus allen Rechnerklassen (PC, Midrange, Mainframe) vertreten sind. Daten und Anwendungen sollen in diesen Umgebungen frei beweglich sein (portierbare Anwendungen, transparente Datenhaltung).
Der Engpaß ist das Netz
In solchen vernetzten Umgebungen gibt es zumindest beim heutigen Stand der Technik einen entscheidenden Engpaß, nämlich das Netz selbst. Netzlaufzeiten bestimmen zu einem großen Teil die Antwortzeiten. DV-Konzepte sind deshalb immer bestrebt, das über ein Netz (LAN und WAN) laufende Datenvolumen zu minimieren. Somit wird die Notwendigkeit von Vernetzungen (die Filiale in München muß Zugriff auf die Daten der Zentrale in Frankfurt haben) begleitet von ressourcenbestimmten Randbedingungen (kein Fernanschluß von Bildschirmen, sondern redundante Datenhaltung wegen höherer Performance und Ausfallsicherheit).
Die mit der Vernetzung Hand 4, Hand gehende Verteilung von Daten(banken) hat diese Randbedingungen zu berücksichtigen. Es müssen flexible Konzepte angeboten werden, die einerseits den typischen Netzeigenschaften und andererseits den Anwenderanforderungen Rechnung tragen. Erreichbarkeit und Verfügbarkeit sowie Netzdurchsatz auf der einen, die Ansprüche der Anwender an das Antwortzeitverhalten und an die Aktualität der verteilten Daten auf der anderen Seite - so sehen hier die Maßstäbe aus.
Mit der Verteilung von Datenbanken in einem Netz sind an das Datenbank-Management-System (DBMS) bestimmte Forderungen zu stellen, ohne deren Erfüllung ein sinnvoller Einsatz im Netz unmöglich ist oder zumindest erheblich eingeschränkt wird.
So muß sich eine Datenbank beispielsweise an beliebigen Stellen (Knoten) im Netz installieren lassen. Ein Anwender, der auf die in dieser Datenbank enthaltenen Daten zugreift, sollte dies unabhängig von der Lokation der Datenbank und der Anwendung tun können. Mit anderen Worten: Wo sich Datenbank und Anwendung im Netz befinden, hat für die Anwendung transparent zu sein, so daß die Anwendung scheinbar immer mit einer lokalen Datenbank arbeitet. Diese Forderung ist insbesondere dann von Bedeutung, wenn eine Datenbank von einem auf einen anderen Knoten gelegt werden soll.
Requst und Antwort nehmen transparente Wege
Ebenso muß der Weg, den zum einen ein Request vom Anwender und zum anderen die Antwort des DBMS im Netz zurücklegen, für die Anwendung transparent sein. Veränderungen der Netztopologie sowie der Verteilung der Datenbanken im Netz dürfen sich nicht auf die Anwendungen auswirken. Ausfälle von Leitungen müssen durch dynamische Ermittlung und Schaltung von Alternativrouten kompensiert werden können.
Um datenbankspezifischen Anforderungen an das Netz Rechnung zu tragen, um Netzwerke zu unterstützen, die kein vollautomatisches Rerouting anbieten und um heterogene Netze flexibel miteinander zu verbinden, sollte die datenbankspezifische Kommunikationssoftware zwischen Anwendung und Datenbank außerdem über entsprechende Routing-Möglichkeiten verfügen.
Fehlendes Remote Data Access Ist K.o.-Kriterium
Die Möglichkeit, aus einer Anwendung heraus Daten zu verarbeiten, die sich auf einem anderen Knoten befinden, wird als Remote Database Access oder RDA bezeichnet. Anwendungen oder DBMS, die diese Möglichkeit nicht bieten, sind für einen Einsatz in einer vernetzten Umgebung grundsätzlich nicht geeignet.
Voraussetzung für RDA ist ein DBMS, das echte Server-Eigenschaften besitzt. Dies bedeutet im wesentlichen, daß es Requests von vielen Clients gleichzeitig bearbeiten kann. Während diese Multiuser-Fähigkeit bei den Mainframe- und Midrange-Datenbanken heute Stand der Technik ist, kann man sie von den PC-Datenbanken nicht durchgängig erwarten.
Mit dem RDA ist der einfachste Fall einer Datenbank im Netz gegeben. Dabei handelt es sich mehr als die klassische Struktur zwischen Anwendung und Datenbank, nur daß die Datenbank sich auf einem anderen Knoten befindet als die Anwendung. Die nächste Stufe besteht darin, von einer Anwendung gleichzeitig auf verschiedene Datenbestände zuzugreifen, die - natürlich transparent für die Anwendung - auf verschiedenen und wechselnden Knoten im Netz verteilt sein können: In diesem Fall spricht man von verteilter Datenhaltung oder verteilten Datenbanken.
Das ist an folgende Voraussetzung gebunden: Die (datenbankspezifischen) Kommunikationsmechanismen zwischen Anwendung und Datenbank ermöglichen die Verwaltung von mehreren gleichzeitig geöffneten und im Netz verteilten Datenbanken sowie deren Zuordnung zu einer Anwendung. Oft wird übrigens mit dem Begriff der SQL-Datenbank eine standardisierte Kommunikation zwischen Anwendung und Datenbank assoziiert. Aber dies ist unzulässig. Der SQL-Standard bezieht sich lediglich auf die Sprachsyntax und schreibt keine Protokolle zur Kommunikation vor
Ein wesentliches Merkmal eines DBMS ist die Fähigkeit, Datenveränderungen in Form von Transaktionen vorzunehmen. Von verteilter Datenverarbeitung kann man erst sprechen, wenn über mehrere im Netz verteilte Datenbanken Veränderungen so vorgenommen wer den können, daß die Konsistenz der Daten auch unter Berücksichtigung aller denkbaren Ausfallsituationen gewährleistet ist.
Besonders in großen Netzen (ein großes Netz kann in diesem Zusammenhang schon bei drei Knoten beginnen) müssen flexible Konzepte realisierbar sein, die den Gegensätzen zwischen den Anwenderforderungen und dem technisch Machbaren gerecht werden. Diese Gegensätze werden gerade bei verteilter Verarbeitung schnell offenkundig. Die nachfolgenden Konzepte befassen sich damit, Transaktionen, also logisch zusammenhängende Veränderungen an mehreren im Netz verteilten Datenbanken, vorzunehmen:
- Datendopplung (replicated files) im Rahmen eines Sicherungs- und Ausfallkonzeptes,
- Datendopplung (replicated files) für dezentrale Verarbeitung zur Reduzierung der Netzlaufzeiten (zum Beispiel sind alle Produktinformationen in allen Niederlassungen verfügbar),
- Datenverteilung (partitioned files) für dezentrale Verarbeitung zur Reduzierung der Netzlaufzeiten (zum Beispiel Verteilen der Firmenpersonaldatei auf mehrere Datenbanken einer logischen Datei, Verarbeiten hauptsächlich lokal bei den Niederlassungen),
- Transaktionen über Datenbestände, die zwingend in unterschiedlichen Datenbanken gespeichert werden müssen.
Zwei-Phasen-Commit noch kaum realisiert
Der klassische Fall verteilter Verarbeitung wird heute mit einer Technologie beschrieben, die als Zwei-Phasen-Commit bekannt ist. Ich sage bewußt "beschrieben" und nicht "realisiert". Denn zum einen ist diese Technologie noch keineswegs durchgängig in allen DBMS-Produkten verfügbar beziehungsweise ist ihre Verfügbarkeit oft unnötigerweise mit anderen Betriebssystemkomponenten (beispielsweise mit einem bestimmten TP-Monitor) verknüpft. Zum anderen stellt ihr produktiver Einsatz wegen der mit diesem Konzept verbundenen Randbedingungen noch eine große Ausnahme dar.
Merkmal dieser Technologie ist die synchrone Arbeitsweise. Demzufolge ist eine Transaktion erst dann beendet, wenn alle an der Transaktion beteiligten Knoten geantwortet haben. Netzlaufzeiten und Verfügbarkeit der Knoten spielen die entscheidende Rolle für die Realisierbarkeit eines solchen Konzeptes, denn die Anwendungen arbeiten selbst synchron zu den Transaktionen, können also erst nach Abschluß der jeweiligen Transaktion weiterarbeiten. Den Anwender vor seinem Bildschirm schmerzt aber jedes Bit, das über die Leitung muß.
Eine systemimmanente Eigenschaft der synchronen verteilten Verarbeitung ist - solange es keine beliebig schnellen Netze gibt - die verlängerte Dauer einer Transaktion. Dabei muß man auch dem Umstand Beachtung schenken, daß ein DBMS für die Dauer einer Transaktion intern einige Ressourcen sperrt. Dies sind im günstigsten Fall nur die an der Transaktion beteiligten Datensätze, bei manchen DBMS-Produkten jedoch ganze Blöcke. Dadurch werden Transaktionen anderer Anwender ebenfalls entsprechend verzögert.
Auf der Basis Master-Slave-Prinzips
Das Konzept der asynchronen Verarbeitung hingegen geht vom ständigen Fehlerfall aus. Es baut auf der Erkenntnis auf, daß in einem entsprechend großen Netz immer irgendein Knoten nicht erreichbar ist. Der wesentliche Unterschied zum synchronen Konzept ist aus Anwendersicht die Entkopplung zwischen den Mechanismen für Konsistenzsicherung und Transaktion.
Die asynchrone Verarbeitung basiert auf dem Master-Slave-Prinzip. Ein Knoten fungiert als Master. Dort erfolgen alle Veränderungen zentral. Dies impliziert, daß auch bei Datenverteilung (partitioned files oder Transaktion über mehrere Datenbanken) ein vollständiger Datenbestand als Replikat auf dem Master vorhanden ist. Der Master aktualisiert in einstellbaren Intervallen die Slave-Knoten, sofern oder sobald diese erreichbar sind. Abfragen auf den Datenbestand erfolgen jeweils lokal (auf den Slave-Knoten).
Vorteil eines solchen Systems ist zumeist die von der Verteilung unbeeinflußte Antwortzeit sowie die Unanfälligkeit gegen Netzprobleme. Nachteilig sind die Notwendigkeit zur zentralen Datenaktualisierung sowie die vom Aktualisierungsintervall abhängige Datendivergenz zwischen den Knoten. Die Daten auf jedem einzelnen Knoten sind allerdings zu jedem Zeitpunkt in sich konsistent.
Mischformen sind durchaus denkbar
Ob ein synchrones oder ein asynchrones Konzept zum Einsatz kommt, sollte von Forderungen der Anwender abhängen. Neben diesen beiden Eckpunkten einer Theorie der verteilten Datenbanken sind auch Konzepte denkbar, die irgendwo dazwischen angesiedelt sind - beispielsweise synchron, solange alle Knoten erreichbar sind, und automatisches Umschalten zu einem asynchronen Konzept, wenn ein Knoten nicht erreichbar ist.