Negativer Einfluss auf die Performance und Zwang zur Homogenitaet zu einer Zeit, in der eigentlich Offenheit gefordert ist, sind nur zwei Punkte, die gegen verteilte Datenbanken sprechen. Funktionsaufrufe statt SQL-Befehle sowie gezielte Redundanz und Datenverteilung sind die bessere Loesung.

Von Michael Bauer*

Verteilte Datenbanken stellen ein eigenartiges Phaenomen dar: Obwohl die dafuer erforderlichen Loesungskonzepte seit fast 20 Jahren existieren, gibt es erst seit einiger Zeit lauffaehige Produkte - und selbst diese sind in ihrer Funktionalitaet noch unvollstaendig.

Woran liegt das? Es ist einleuchtend, dass Softwarehersteller nicht in aufwendige Entwicklung investieren, wenn bei den Anwendern kein Bedarf dafuer besteht. Zwar hat die Tendenz zu verteilten Systemen dazu gefuehrt, dass aus Entwicklungen in Richtung Distributed Databases auch einsatzfaehige Produkte entstanden sind. Doch sind ernsthafte Implementierungen in der Praxis noch Mangelware.

Eine verteilte Datenbank soll dem Benutzer - interaktiver Benutzer oder Anwendungsprogramm - die Moeglichkeit bieten, mit auf verschiedenen Rechnern verteilten Daten genauso zu operieren, als waeren sie in dem lokalen DBMS (Database Management Systems) gespeichert. Chris Date, der im Zusammenhang mit relationalen Datenbanken als "Schueler" von Dr. Codd recht bekannt wurde, hat diese Anforderungen einmal in zwoelf Regeln zusammengefasst und damit die gaengige Lehrmeinung in eine knappe Form gegossen. Auf diesen Richtlinien basieren die im Kasten auf Seite 45 kompakt zusammengefassten Anforderungen an eine verteilte Datenbank.

Damit ist natuerlich nicht gesagt, dass man diese Technologie auch in der Praxis einsetzen kann. Speziell in bezug auf die Performance treten grosse Probleme auf, die gegen eine verteilte Datenbank sprechen.

Erstes Problem: die Performance

Die Arbeitsweise von Distributed Databases baut darauf auf, dass ein SQL-Befehl ueber das Netz zu dem DBMS gesandt wird, in dem die betreffenden Daten gespeichert sind. Jeder SQL-Befehl wird so zu einem Nachrichtenpaar: SQL-Befehl hin und Antwort zurueck. Bei operativen Anwendungen kann sich das toedlich auf die Performance auswirken, denn eine Transaktion umfasst ueblicherweise eine Vielzahl von SQL-Befehlen.

Dazu ein Beispiel: Wenn bei einer Client-Server-Loesung auf einem dezentralen PC Auftraege erfasst und anschliessend in einer entfernten Datenbank gespeichert werden sollen, entstehen leicht 20 oder 30 SQL-Befehle. Wenn jeder davon zu einer Nachricht wird, die eine Sekunde benoetigt, dauert der ganze Prozess 20 bis 30 Sekunden. Loest man das Problem dagegen in Form einer kooperativen Verarbeitung, dann residiert der Teil der Anwendung, der die Auftragsdaten verwaltet, auf dem Server, auf dem auch die Daten gespeichert sind.

In diesem Fall sendet der Client nur eine Nachricht mit allen Daten eines Auftrags an den Server. Dort werden dann die SQL- Befehle ausgeloest. Das Nachrichtenaufkommen reduziert sich also betraechtlich (vgl. Abbildung 1). Selbst wenn diese Nachricht laenger ist, dauert der gesamte Prozess hoechstens 20 Sekunden.

SQL-Befehle in einem verteilten System (Remote Database Access) zu versenden ist nur dann sinnvoll, wenn fuer eine Transaktion ein SQL-Befehl ausreicht, also fuer Anzeigefunktionen.

Aber auch bei solchen Informationsabfragen kann eine verteilte Datenbank Performance-kritisch sein, falls zwischen den DB- Systemen ein aufwendiger Prozess ablaeuft.

Hierzu ein weiteres Beispiel: Die Abfrage "Zeige alle Kunden mit Namen "Bauer" an, die auf ihrem Konto einen Saldo >1000 haben" laesst sich in einem einzigen SQL-Befehl formulieren. Sind aber die Kundendaten auf einem und die Kontendaten auf einem anderen Rechner gespeichert, kann es sein, dass erst viele Datensaetze von einem zum anderen System transportiert werden, um nachher vielleicht festzustellen, dass ueberhaupt keine Daten diesen Bedingungen entsprechen (vgl. Abbildung 2).

Unabhaengig von der Frage, wie gut ein DBMS diesen Befehl aufzuloesen versteht - Stichwort: "Globale Optimierung" -, ist es in solchen Faellen besser, die Datenbestaende nicht ueber mehrere Rechner zu verteilen, etwa weil sie haeufig zusammen gebraucht werden, oder sie auf mehreren Systemen redundant zu speichern.

Redundanz ist stets das "Schmiermittel" fuer performante Datenbanken. Das gilt sowohl innerhalb einer einzigen Datenbank als auch fuer verteilte Datenbanken. Diese Redundanzen automatisch zu pflegen, ohne dass die Anwendungen betroffen sind, zaehlt zu den Anforderungen an letztere.

Doch wie sieht das in der Praxis aus? Wenn ein Unternehmen beispielsweise in jeder seiner Niederlassungen eine Kopie des Artikelbestands redundant speichert, verbessern sich dadurch zunaechst die Zugriffszeiten der lokalen Anwendungen.

Eine Aenderung der Artikeldaten dauert jedoch so lange, bis die korrespondierenden Aenderungsbefehle an allen beteiligten Datenbanksystemen der Distributed Database durchgefuehrt wurden.

Da ein solcher Prozess aber Schutz gegen Abstuerze und Unterbrechungen braucht, wird der beruehmte "Two Phase Commit" - ein zweistufiges Bestaetigungsprotokoll - notwendig. Dieses beinhaltet nochmals vier zusaetzliche Nachrichten je beteiligtes DBMS (vgl. Abbildung 3).

Eine Aenderung dauert somit um ein Mehrfaches laenger als in einer lokalen Datenbank. Deshalb gilt die Regel, dass nur Daten mit geringer Aenderungshaeufigkeit fuer eine redundante Speicherung (Replikation) geeignet sind.

Unabhaengig von der Antwortzeit gibt es bei redundanten Daten noch ein weiteres Problem. Was passiert, wenn eines der beteiligten DB- Systeme zum Zeitpunkt einer Aenderung nicht aktiv oder nicht erreichbar ist? Nach dem Konzept einer korrekten Transaktion duerfte dann die Aenderung nicht ausgefuehrt werden. Dadurch waere die Verfuegbarkeit des Gesamtsystems allerdings dramatisch beeintraechtigt. Eine Loesung hierfuer ist das Konzept der "asynchronen Replikation": Dabei werden die Aenderungen zunaechst in einer besonderen Log-Datei gespeichert und durch einen asynchronen Task verteilt. Ein DBMS erhaelt die Aenderungen dann, wenn es wieder verfuegbar ist.

Durch die zeitliche Differenz in der Aktualitaet der Daten laesst sich ein solches Konzept, das auch unter der Bezeichnung "Replication Server" angeboten wird, nur mit Einschraenkungen nutzen. Das groesste Hindernis ist, dass auf den Kopiebestaenden keine Aenderungen zulaessig sind, weil sonst unloesbare Konflikte entstehen. Es darf also nur auf der Master-Kopie geaendert werden, waehrend die anderen Replikate read-only sind. Das schraenkt jedoch die allgemeine Verwendbarkeit dieses Konzepts ein.

Ein weiteres Problem der Distributed Database liegt im Mehrbedarf an CPU-Zeit. Jeder Datenbankbefehl, auch wenn er letztlich lokal ausgefuehrt wird, bedarf hinsichtlich seiner Auswirkungen auf die verteilte Datenbank einer Analyse. Wenn auf einem Rechner 95 Prozent aller Datenbankbefehle lokal und nur fuenf Prozent entfernt ausgefuehrt werden, steigt der Overhead fuer alle diese Befehle gewaltig. Ein besonderes Problemkind scheint hier DB2/MVS zu sein. So belegte der Testbericht eines Anwenders, dass das lokale DBMS, das den Befehl nur an ein entferntes weiterleitete, mehr CPU-Zeit verbraucht hatte, als wenn es die Arbeit selbst getan haette. Die gesamte CPU-Zeit fuer einen verteilten Datenzugriff erhoehte sich so um 235 Prozent bis 400 Prozent gegenueber einer lokalen Ausfuehrung. Dieser Test wurde mit der Version 2.2 durchgefuehrt. Es bleibt nur zu hoffen, dass neuere Fassungen weniger CPU-Zeit verbrauchen werden.

Wenn man die heute verfuegbaren Produkte im Bereich verteilter Datenbanken analysiert, fallen noch zwei weitere Aspekte ins Auge:

- Zwar bietet jeder DBMS-Hersteller zu seinem Produkt auch eine Distributed-Database-Komponente, doch sind diese teilweise noch weit davon entfernt, alle Anforderungen zu erfuellen.

- Verteilte Datenbanken funktionieren heute nur dann gut, wenn es sich bei allen beteiligten DB-Systemen um das gleiche Produkt handelt.

Die unterschiedliche Leistungsfaehigkeit der verteilten Datenbanken laesst sich transparent machen, indem man den Erfuellungsgrad der Anforderungen in vier Stufen gliedert (vgl. Abbildung 4). Keines der marktgaengigen Produkte erreicht zur Zeit die hoechste Stufe. Die besten liegen etwa bei Stufe 3,5 (zum Beispiel Ingres, Adabas, Informix, Oracle, Sybase), waehrend andere Produkte niedriger rangieren. So ist beispielsweise DB2/MVS, Version 3.1 in Stufe 2 einzuordnen. Andere IBM-Datenbanken liegen noch tiefer.

Allerdings wird bei dieser Gruppierung davon ausgegangen, dass es sich bei allen Komponenten der verteilten Datenbanken um das gleiche DBMS handelt. Das ist gerade in einer Client-Server-Welt unwahrscheinlich. Wir wollen im Client-Server-Bereich "offen" sein, das heisst, beliebige Produkte verschiedener Hersteller problemlos einsetzen koennen - und das sollte gerade im Datenbanksektor gelten.

Wenn ein Unternehmen DB2, SQL/Base und Informix in seiner Client- Server-Welt kombinieren moechte, ergeben sich zwei Probleme:

- Die unterschiedlichen DB-Systeme muessen sich untereinander verstaendigen koennen.

- Die Anwendungen muessen ihre SQL-Befehle unabhaengig von dem jeweiligen DBMS absetzen.

Fuer ersteres bietet sich die Standard-Schnittstelle DRDA

(Distributed Relational Database Architecture) von IBM an, die inzwischen von verschiedenen DB-Systemen genutzt wird. In der Praxis findet zur Zeit allerdings nur eine rudimentaere Art der Zusammenarbeit statt (Stufe eins in Abbildung 4).

Da aber DRDA keinen Standard fuer die SQL-Befehle enthaelt, die zwischen den beteiligten DB-Systemen verschickt werden, muessen die Anwendungsprogramme Disziplin ueben: Sie duerfen nur SQL-Anweisungen aus dem kleinsten gemeinsamen Nenner aller DB-Systeme verwenden.

Das entspricht zur Zeit dem Befehlsumfang von DB2. Als Konsequenz aus diesen Darstellungen ergibt sich, dass eine Distributed Database wenig hilfreich fuer verteilte Systeme ist. Vorrangiger ist es:

- die Daten so an die dezentralen Rechner zu verteilen, dass keine oder nur wenige Zugriffe auf entfernte Datenbanken noetig sind;

- nur Daten, die weitgehend statisch sind, redundant zu halten (hierfuer genuegt File-Transfer als Aktualisierungsmechanismus), waehrend Update-intensive Daten nur einmalig zentral gespeichert werden;

- statt SQL-Befehle ueber das Netz zu versenden, lieber Funktionsaufrufe im Rahmen von Cooperative Processing zu versenden. Wer seine Daten zu sehr streut, ist selbst daran schuld, wenn er sie hinterher wieder muehsam zusammensuchen muss.

* Michael Bauer ist Geschaeftsfuehrer der Informatik Training GmbH in Radolfszell.

Anforderungen an verteilte Datenbanken

"location transparency"

In den DB-Anweisungen muss keine Ruecksicht auf den Speicherort der Daten genommen werden.

"distribution transparency"

Die Art der Verteilung - un kat, replikat oder partitioniert - darf keine Auswirkungen auf die Befehle haben. Dies umfasst auch automatisches Nachziehen von Aenderungen.

Vollstaendige Funktionalitaet

Alle DB-Operationen - auch Updates - muessen genauso moeglich sein wie bei lokalen Datenbanksystemen.

DB-uebergreifende Operationen

Ein DB-Befehl muss gegen mehrere DB-Systeme innerhalb der verteilten Datenbanken ausgefuehrt werden koennen. Dies schliesst auch eine netzweite Optimierung ein.

Netzweite Integritaet

Sperr-, Ruecksetz- und Wiederherstellfunktionen muessen netzweit funktionieren.

Besondere Anforderungen

Rechner-Unabhaengigkeit

Die Datenbank sollte sich ueber Rechner verschiedener Hersteller und Betriebssysteme verteilen lassen.

DBMS-Unabhaengigkeit

Die verteilte Datenbank sollte auch mit unterschiedlichen Datenbanksystemen realisiert werden.