16 Einführung in Parallele DBS

16.2 Architektur von Parallelen DBS

Die Diskussion verschiedener Typen von Mehrrechner-DBS in Kap. 3.4 hat gezeigt, daß die Anforderungen an Parallele DBS (hohe Leistung, Skalierbarkeit, hohe Verfügbarkeit, Kosteneffektivität) am besten von lokal verteilten, integrierten Mehrrechner-Datenbanksystemen erfüllt werden. Die Nutzung mehrerer Prozessoren (Verarbeitungsparallelität) wird vor allem durch die drei Architekturklassen Shared-Nothing, Shared-Disk sowie (mit Abstrichen) Shared-Everything ermöglicht (Abb. 16-2). Daneben sind auch hybride Architekturen denkbar, z.B. Shared-Nothing- oder Shared-Disk-Systeme, bei denen jeder Knoten vom Typ Shared-Everything ist [Va93a, Va93b]. Statt der in diesem Buch verwendeten Architekturbezeichnungen findet man auch häufig die Begriffe SMP (Symmetric Multiprocessing) und MPP (Massive Parallel Processing). SMP-Systeme entsprechen Multiprozessoren und somit Shared-Everything. MPP-Systeme sind lose gekoppelte Mehrrechnersysteme, welche sowohl dem Shared-Nothing- oder Shared-Disk-Ansatz folgen können. Üblicherweise geht man dabei von Parallelrechnern aus, die aus Hunderten bis Tausenden von Prozessor-Elementen (PE) bestehen.

Abb. 16-2: Shared-Everything, Shared-Disk, Shared-Nothing

Die lokale Verteilung innerhalb eines Clusters ist aus Leistungsgründen als obligatorisch anzusehen (Kap. 3.1.1). Dies gestattet den Einsatz eines skalierbaren Hochgeschwindigkeits-Netzwerkes, dessen Übetragungskapazität proportional zur Prozessoranzahl gesteigert werden kann. Eine sehr schnelle Inter-Prozessor-Kommunikation ist für die effiziente Zerlegung einer Transaktion in zahlreiche Teiltransaktionen sowie für die Übertragung großer Datenmengen entscheidend. Weiterhin kann bei lokaler Verteilung am ehesten eine dynamische Lastbalancierung erreicht werden, wobei der aktuelle Systemzustand berücksichtigt wird. Dies betrifft sowohl die initiale Verteilung eintreffender Transaktionen und Anfragen unter den Verarbeitungsrechnern (Transaktions-Routing) als auch die Rechnerzuordnung von Teilaufträgen während der parallelisierten Abarbeitung. Die Lastbalancierung wird auch dadurch erleichtert, daß Parallele DBS auf homogenen Architekturen basieren, so daß eine bestimmte DB-Funktion prinzipiell von jedem Prozessor ausgeführt werden kann[69].

Wesentlich für die Kosteneffektivität von Parallelen DBS ist der weitgehende Verzicht auf Spezial-Hardware, da diese i.a. hohe Kosten verursacht. Stattdessen sollte soweit wie möglich Standard-Hardware zum Einsatz kommen, insbesondere weit verbreitete Mikroprozessoren für die CPUs. Durch die software-mäßige Parallelisierung der DB-Verarbeitung können dann sowohl die geringen Kosten als auch die enormen Leistungssteigerungen der Standard-Hardware (Mikroprozessoren) unmittelbar genutzt werden. Dieser Aspekt wurde bei der Realisierung älterer DB-Maschinen ignoriert und ist Hauptgrund für deren geringe Relevanz (Kap. 3.3). Eine software-basierte Parallelisierung kann jedoch durchaus innerhalb eines auf DB-Verarbeitung beschränkten Back-End-Systems (DB-Maschine, Server) erfolgen (Beispiele: Teradata, IBM Parallel Query Server). Für OLTP-Anwendungen auf allgemeinen Verarbeitungsrechnern kann dies jedoch zu hohen Kommunikationskosten führen, wenn jede (einfache) DB-Operation eine Kommunikation mit dem Back-End-System erfordert. Für Anfragen, die große Ergebnismengen zurückliefern, entsteht ebenfalls ein hoher Kommunikationsaufwand mit dem Back-End-System, wenn die Ergebnisse satzweise abgerufen werden.

Intra-Transaktionsparallelität wurde bisher vor allem für Shared-Everything- (Multiprozessoren) und für Shared-Nothing-Systeme untersucht sowie innerhalb von Prototypen und kommerziellen DBS realisiert. Die Nutzung von Multiprozessoren zur Parallelverarbeitung kann dabei als erster Schritt aufgefaßt werden, da er i.a. auf relativ wenige Prozessoren begrenzt ist (Kap. 3.1). Die Verwendung eines gemeinsamen Hauptspeichers erleichtert dabei die Parallelisierung, da eine effiziente Kommunikation zwischen Prozessen einer Transaktion und eine einfachere Lastbalancierung möglich wird. Prototyp-Realisierungen paralleler Shared-Everything-DBS sind u.a. XPRS [SKPO88], Volcano [Gra94] und DBS3 [ZZB93]. Auch kommerzielle DBS nutzen zunehmend Multiprozessoren für Intra-Transaktionsparallelität, z.B. DB2 [Ha90] oder Informix [Dav92].

Shared-Nothing-Systeme, aber auch Shared-Disk-Systeme, bieten eine größere Erweiterbarkeit als Shared-Everything, so daß eine entsprechend weitergehende Parallelisierung unterstützt werden kann. Bei der Realisierung lokal verteilter Shared-Nothing-DBS können viele der Konzepte von Verteilten DBS übernommen werden, z.B. zur Transaktionsverarbeitung (Commit-Behandlung, Synchronisation). Dabei ergibt sich aufgrund der schnelleren Kommunikation i.a. eine effizientere Bearbeitung als im ortsverteilten Fall[70]. Bezüglich der Katalog- und Namensverwaltung spielt die Wahrung einer hohen Knotenautonomie keine Rolle mehr, so daß einfachere Lösungen möglich werden. Zum Beispiel kann eine vollständige Replikation der Katalogdaten vorgesehen werden. Notwendige Erweiterungen zur Unterstützung von Intra-Transaktionsparallelität betreffen vor allem die Bestimmung der Datenverteilung sowie die Anfragebearbeitung; darauf wird in diesem Kapitel ausführlich eingegangen. Intra-Transaktionsparallelität wird bereits seit mehreren Jahren in den beiden Shared-Nothing-Systemen Teradata (Kap. 19.8) und Tandem NonStop-SQL (Kap. 19.7) unterstützt; neuere Entwicklungen bestehen für Sybase (Kap. 19.6) und DB2/6000 (Kap. 19.1.3). Daneben verfolgen zahlreiche Prototypen den Shared-Nothing-Ansatz, z.B. Gamma [De90], Bubba [Bo90], EDS [Sk92], Prisma [Ap92] und Arbre [LY89].

Demgegenüber stehen die Untersuchungen zur Intra-Transaktionsparallelität in Shared-Disk-Systemen noch am Anfang [Ra93e]. Existierende Implementierungen sind bisher weitgehend auf Inter-Transaktionsparallelität beschränkt. Eine initiale Unterstützung von Intra-Transaktionsparallelität auf Basis von Oracles "Parallel Server" (Kap. 19.2.2) wurde für den KSR1-Parallelrechner (Kendall Square) realisiert [RMW93]. In der allgemeinen Produktversion 7.1 ist ebenfalls eine beschränkte Form von Intra-Transaktionsparallelität vorgesehen. Daneben wird in dem neuen IBM Shared-Disk-System Parallel Query Server für DB2 (Kap. 19.1.3) eine Parallelisierung von SQL-Anfragen unterstützt.

Parallele DBS müssen nicht nur Verarbeitungsparallelität, sondern auch E/A-Parallelität unterstützen, insbesondere um große Datenmengen parallel von mehreren Platten einzulesen. Dies setzt auch in Shared-Everything- und Shared-Disk-DBS eine entsprechende Verteilung der Daten (Relationen) über mehrere Platten voraus. Dies kann transparent für das DBS erfolgen, und zwar innerhalb sogenannter Disk-Arrays, welche in der jüngsten Vergangenheit starke Bedeutung erreicht haben [PGK88, Ra93a, WZ93]. Disk-Arrays bestehen intern aus mehreren Platten, können jedoch logisch wie eine Platte angesprochen werden, so daß ihr Einsatz prinzipiell keine Änderungen in der nutzenden Software erfordert. Durch den Einsatz von E/A-Parallelität soll das Leistungsverhalten gegenüber einzelnen Platten jedoch deutlich verbessert werden. Ferner sind automatische Methoden zur Fehlerbehandlung vorgesehen, um eine hohe Ausfallsicherheit zu gewährleisten. Ein weiterer Vorteil liegt in der Verwendung kleiner Platten (z.B. mit einem Durchmesser von 3,5 Zoll), welche eine verbesserte Kosteneffektivität gegenüber großen Platten aufweisen. Der Kostenvorteil wird jedoch durch die Notwendigkeit spezialisierter Platten-Kontroller wieder kompensiert, welche für die Organisation der E/A-Parallelität sowie die Fehlerbehandlung verantwortlich sind.

Die Realisierung Paralleler DBS mit solchen Disk-Arrays wurde bisher noch nicht ausreichend untersucht und ist zumindest problematisch. Denn außerhalb des DBS kann eine Datenverteilung nur auf physischen Objektgranulaten wie Blöcken erfolgen. Wünschenswert dagegen wäre eine logische Definition der Datenverteilung über Datenwerte, um so die Bearbeitung bestimmter Operationen auf eine Teilmenge der Platten begrenzen zu können. Ferner kann eine Parallelisierung ohne genaue Kenntnis der Datenverteilung dazu führen, daß parallele Teiloperationen auf dieselben Platten zugreifen und somit E/A-Engpässe erzeugt werden[71]. Zudem stellen Disk-Arrays Spezial-Hardware dar und weisen eine Reihe weiterer Probleme für die DB-Verarbeitung auf (z.B. ist die Erzeugung von Archivkopien sehr problematisch) [GHW90]. Wir werden daher diesen Ansatz hier nicht weiter betrachten, sondern annehmen, daß die Verteilung der Daten über mehrere Platten den DBVS bekannt ist und über Datenbankwerte definiert werden kann.

[69] Für Shared-Nothing gilt dies aufgrund der Abhängigkeiten zur Datenverteilung nur eingeschränkt.
[70] Auch können mächtigere Kommunikationsprimitive wie Broadcast- oder Multicast-Kommunikation vorteilhaft genutzt werden, z.B. zur parallelen Commit-Behandlung.
[71] Die Umgehung dieser Probleme setzt also u.a. voraus, daß dem DBS Angaben zur Datenverteilung innerhalb von Disk-Arrays bekanntgemacht werden (Abschwächung der "Geräteunabhängigkeit").