Von Barbara Finger*

Inter-Query-Parallelismus und Partitionierungstechniken - behandelt im ersten Teil dieses Beitrags in CW Nr. 41 vom 13. Oktober 1995, Seite 47 - sind nicht die einzigen wichtigen Faktoren zur Beurteilung einer Datenbank fuer Multiprozessorsysteme. Eine Schluesselkomponente ist die zugrundeliegende Datenbankarchitektur.

Die Frage ist insbesondere, inwieweit die Datenbankarchitektur es ermoeglicht, die Vorteile der Parallelverarbeitung in Shared- Memory-, Shared-Disk- und Shared-Nothing-Umgebungen zu nutzen. Die Architektur einer Datenbank bestimmt letztendlich, wie weitgehend ein System skalieren kann, und es ist wichtig zu verstehen, wie die einzelnen Hersteller ihre parallele Software-Architektur auf die parallele Hardware-Architektur abbilden.

In einer auf Shared-Memory basierenden parallelen Datenbankarchitektur geht das Datenbank-Management-System (DBMS) davon aus, dass mehrere Datenbankkomponenten an einem SQL-Statement arbeiten und dabei das Shared-Memory fuer die Uebertragung der Daten und Messages verwenden. Alle Prozessoren haben Zugriff auf alle Daten, die ueber lokale Platten verteilt sind. Das heisst, alle Prozessoren teilen sich das Shared-Memory und die Platten.

Wenn sich die Prozessoren Ressourcen teilen muessen

Wesentlicher Vorteil dieser Architekur ist, dass die Verwendung des Shared-Memory fuer die Inter-Prozess-Kommunikation wesentlich schneller ist als der Austausch von Messages zwischen Knoten via Netzwerk. Und da sich alle Prozessoren den Zugriff auf die Platten teilen, brauchen Daten auch nicht physikalisch im Netz hin und her geschoben werden. Aber die Skalierbarkeit dieser Architekur ist auf eine bestimmte Anzahl an CPUs begrenzt.

In einer Shared-Disk-Umgebung nimmt das DBMS an, dass alle Prozessoren direkten Zugriff auf alle Platten (alle Daten) haben, sich aber nicht das Shared-Memory teilen. Eine zusaetzliche Softwareschicht, der Distributed Lock Manager (DLM), ist erforderlich, um den konkurrierenden Zugriff auf die Platten (Daten) zu steuern. Shared-Disk-Architekturen lassen sich nur bis zu einer bestimmten Anzahl an CPUs skalieren, da das zentrale Setzen und Verwalten der Locks ueber den DLM einen grossen Overhead produziert: Alle Requests laufen ueber diesen zentralen Lock Manager.

Angenommen, Knoten 1 fuehrt eine Transaktion durch, mit der ein Kundendatensatz aktualisiert werden soll. Bei einem Datenbanksystem mit zentralisierter Steuerung muss Knoten 1 zunaechst beim DLM (zentraler Knoten) anfragen, ob bereits ein anderer Knoten auf die benoetigten Daten zugreift. Dieses Modell kann also sehr viel unnoetige Netzbelastung verursachen und die Zahl der Ein- und Ausgaben um ein Vielfaches erhoehen. In einer sehr verarbeitungsintensiven Umgebung kann darueber hinaus der zentrale Knoten zu einem Flaschenhals werden, der die Performance der gesamten Infrastruktur negativ beeinflusst.

Shared-Nothing-Architekturen bieten die beste Skalierbarkeit. Jeder Prozessor hat sein eigenes Memory, sein eigenes Betriebssystem und seine eigene DBMS-Instanz. Jeder Prozessor verwaltet seine eigenen Daten und fuehrt seine Datenbankabfragen auf seinen lokalen Daten aus, die auf den lokalen Platten gespeichert sind, somit laesst sich der I/O-Bedarf auf das Notwendigste reduzieren. Die Prozessoren sind zum Beispiel ueber ein Hochgeschwindigkeits-Netzwerk miteinander verbunden. Messages und Funktionen werden untereinander ausgetauscht.

In einer Shared-Nothing-Umgebung parallelisiert die Datenbank SQL- Statements ueber alle vorhandenen Knoten. Basis der Parallelisierung ist wiederum eine Verteilung der Daten ueber die Knoten und, wenn moeglich, auch innerhalb der einzelnen Knoten. Jeder Knoten verwaltet und pflegt zwar seine eigenen Daten, weiss aber auch genau, wo sich die anderen Daten befinden. Benoetigt ein Knoten nun Daten, die ihm nicht gehoeren, sendet er eine entsprechende Anforderung an den Eigentuemer der Daten, was auch als "Function Shipping" bezeichnet wird.

Hierzu ein Beispiel: Knoten 1 erhaelt eine Benutzeranforderung fuer einen Zwei-Tabellen-Join. Er stellt fest, dass sich die erste Tabelle auf Knoten 2 und die zweite Tabelle auf Knoten 3 befindet. Da beide Tabellen relativ klein sind, sieht der vom Query Optimizer erstellte Abfrageplan einen Sort/Merge-Join vor, bei dem beide Tabellen gescannt, nach dem Join-Schluessel sortiert und auf Basis der Join-Kriterien zusammengefuehrt werden. Die auszufuehrenden Tasks (Scannen und Sortieren von Tabelle 1 beziehungsweise 2) werden auf die Knoten 2 und 3 verteilt. Die Ergebnisse der Scan- und Sort-Operationen werden an Knoten 1 zur abschliessenden Verbindung der Tabellen zurueckgeliefert.

Einige Datenbanken bieten zwar ebenfalls die Moeglichkeit, mehrere Knoten an einer Abfrage zu beteiligen. Statt des Function-Shipping implementieren diese Systeme jedoch ein Verfahren, das Data- Shipping oder I/O-Shipping heisst. Dabei greift der primaere Knoten nur fuer das Daten-Retrieval auf andere Knoten zurueck. Diese sekundaeren Knoten rufen die Daten ab und uebergeben die Ergebnisse zur Ausfuehrung der restlichen Abfrageoperationen, zum Beispiel Sorts, Joins etc., an den primaeren Knoten.

Function-Shipping ist demgegenueber sehr viel besser fuer die Parallelverarbeitung geeignet. Da hier die eigentlichen SQL- Operationen an andere Knoten uebergeben werden, ermoeglicht es eine parallele, knotenuebergreifende Ausfuehrung der Abfrage. Beim Data- Shipping sind andere Daten dagegen nur am Daten-Retrieval beteiligt, die eigentliche Ausfuehrung der Abfrage bleibt weiterhin sequentiell.

"Online XPS" von Informix, IBMs "DB2 PE" und der "Navigation Server" von Sybase sowie die proprietaeren DBMS "Teradata" von AT&T und Tandems "Non-Stop SQL/MP" basieren alle auf einer Shared- Nothing-Architektur. Shared-Nothing-Architekturen sind optimiert fuer lose gekoppelte und massiv-parallele Systeme. Beispiele fuer solche Systeme sind IBMs "SP2", AT&Ts "5100", ICLs "Goldrush" und SNIs "Reliant RM1000".

Parallelismus in puncto Knoten

Besonderes Merkmal einer Shared-Nothing-Architektur ist ihre nahezu unbegrenzte Skalierbarkeit. Mit Shared-Nothing kann die Power Hunderter oder gar Tausender Prozessoren fuer eine einzelne Benutzeranfrage aufgewendet werden. Ausserdem kann diese Architektur mehrere 100 GB oder TB grosse Datenbanken unterstuetzen.

Um die Unterschiede dieser Architekturen aufzuzeigen, ist ausserdem zwischen Inter-Server- und Intra-Server-Parallelismus zu unterscheiden. Inter-Server-Parallelismus heisst, dass ein SQL- Statement wie in Shared-Nothing-Umgebungen ueber mehrere Knoten - also auch mehrere Datenbankinstanzen - parallelisiert wird.

Intra-Server-Parallelismus dagegen heisst, dass ein SQL-Statement innerhalb eines Knotens (also innerhalb einer Datenbankinstanz) parallelisiert wird. Dies setzt voraus, dass es sich dabei um ein SMP-System handelt.

Optimum ist somit eine flexible parallele Architektur, die vollen Nutzen aus ihrer Umgebung ziehen kann. Ein wirklich fortschrittliches paralleles DBMS sollte daher in der Lage sein, SQL-Statements sowohl ueber Knoten hinweg parallel auszufuehren als auch innerhalb eines Knotens. Dieses Zwei-Stufen-Konzept sorgt fuer beste Flexibilitaet, Performance und Skalierbarkeit.

Durch die redundante Auslegung lose gekoppelter und massiv- paralleler Systeme bieten diese Plattformen ideale Voraussetzungen hinsichtlich Verfuegbarkeit und Fehlertoleranz - Kriterien, die gerade bei sehr grossen Datenbanken (VLDBs) extrem wichtig sind. Der Ausfall eines Knotens, ob geplant oder ungeplant, sollte den Zugriff auf die Daten dieses Knotens nicht beeintraechtigen. Der Datenbank-Server muss also in der Lage sein, bei einem Knotenausfall den betroffenen Datenbankbereich automatisch wiederherzustellen und die Arbeitslast des Knotens zeitweilig auf andere Netzwerkknoten zu verteilen.

Datenbankadministratoren sollten die Moeglichkeit haben, alle Datenbankobjekte eines Systems - unabhaengig davon, auf welchem Knoten sie residieren - von ein und derselben Konsole aus zu verwalten. Bei lose gekoppelten und massiv-parallelen Systemen ist dies besonders wichtig, da die Daten aus Effizienzgruenden meist auf eine Vielzahl von Knoten verteilt sind. Durch Single-System- View lassen sich alle Datenbankobjekte des Netzwerks von einem zentralen Standort aus konfigurieren, ueberwachen und steuern, was die Verwaltung betraechtlich vereinfacht.

Randaspekte sind nicht nebensaechlich

Angesichts der Tatsache, dass die meisten sehr grossen Datenbanken zunaechst auf SMP-Systemen liegen, sollte ein verteilter Datenbank- Server neben lose gekoppelten und massiv-parallelen Systemen auch SMP-Systeme unterstuetzen. Die auf SMP-Systemen entwickelten Anwendungen muessen mit den Shared-Nothing-Architekturen hundertprozentig kompatibel sein, damit der Benutzer seine SMP- Anwendungen ohne zusaetzlichen Schulungsaufwand auch in einer MPP- Umgebung einsetzen kann.

Ausserdem sollte die Anwendung kein Neukompilieren erforderlich machen, wenn die Betriebssystem-Umgebung konsistent bleibt. Eine Anwendung, die urspruenglich auf einem HP-T500-SMP-System implementiert wurde, sollte also ohne Codeaenderungen oder Rekompilierung auch auf einem HP-T500-Cluster laufen.

Verteilte Datenbank-Server haben ihr kommerzielles Potential bereits bei mehreren Herstellern, darunter Tandem Computers und Teradata/AT&T, unter Beweis gestellt. Diese Loesungen sind jedoch proprietaer und teuer. Viele Open-Systems-Hersteller unterstuetzen jedoch mittlerweile lose gekoppelte und massiv-parallele Systeme. Da es in den kommenden Jahren auch in diesem Bereich zu einem Preisverfall kommen wird, sollte ein verteilter Datenbank-Server Open-Systems-Plattformen in jedem Fall unterstuetzen, um offene, standardkompatible Loesungen zu ermoeglichen.

*Barbara Finger ist Produkt-Managerin Datenbank-Server bei der Informix Software GmbH in Ismaning.