3.1 Shared-Everything, Shared-Disk, Shared-Nothing
Beim gemeinsamen Zugriff hat jeder Prozessor direkten Zugriff auf alle Platten und damit auf die gesamte Datenbank. Damit entfällt die Notwendigkeit einer verteilten Transaktionsverarbeitung wie bei der partitionierten Plattenanbindung, jedoch sind ggf. Synchronisationsmaßnahmen für den Externspeicherzugriff vorzusehen. Der gemeinsame Externspeicherzugriff liegt bei Shared-Disk- sowie Shared-Everything-Architekturen vor.
Generell gilt, daß lokal verteilte Systeme eine wesentlich leistungsfähigere Interprozessor-Kommunikation ermöglichen sowie robuster gegenüber Fehlern im Kommunikationssystem sind. Die effiziente Kommunikation ist ein entscheidender Vorteil lokal verteilter Mehrrechner-DBS gegenüber ortsverteilten Ansätzen. Dies ist vor allem auch für die parallele Datenbankverarbeitung von Bedeutung, bei der Transaktionen bzw. DB-Operationen zur Verkürzung der Bearbeitungszeiten intern zerlegt und mehreren Prozessoren zugeordnet werden, da diese Parallelisierung zwangsweise einen Mehrbedarf an Kommunikation mit sich bringt. Auch kann in lokal verteilten Systemen eine dynamische Verteilung und Balancierung der Transaktionslast unter Berücksichtigung des aktuellen Systemzustands eher erfolgen, da die Wartung entsprechender Statusinformationen mit geringerem Aufwand und größerer Aktualität als bei Ortsverteilung möglich ist. Lokal verteilte Mehrrechner-DBS weisen daneben Vorteile hinsichtlich der Administration auf gegenüber geographisch verteilten Systemen, bei denen i.a. in jedem Knoten eine eigene Systemverwaltung erforderlich wird. Wir werden lokal verteilte Systeme vom Typ Shared-Nothing, Shared-Disk und Shared-Everything auch als Parallele Datenbanksysteme bezeichnen (Kap. 16).
Auf der anderen Seite kann nur mit ortsverteilten Mehrrechner-DBS eine Anpassung an verteilte Organisationsstrukturen erfolgen, wie es in großen Unternehmen vielfach wünschenswert ist. Auch bieten ortsverteilte Konfigurationen eine größere Fehlertoleranz gegenüber "Katastrophen" (z.B. Bombenanschlag, Überschwemmung, Erdbeben), welche den Ausfall eines kompletten Rechenzentrums bzw. Clusters mit entsprechendem Datenverlust verursachen können (s. Kap. 9.5).
Für Shared-Everything bzw. Shared-Disk schreibt die gemeinsame Externspeicheranbindung in der Regel eine lokale Rechneranordnung vor. Größere Entfernungen zwischen Rechnern und Platten sind bei Glasfaserkopplung bedingt möglich (derzeit bis zu ca. 30 km), jedoch zu deutlich erhöhten Latenzzeiten. Eine solche Form der Verteilung kann zur Steigerung der Verfügbarkeit genutzt werden, da die Externspeicher selbst den Ausfall sämtlicher Verarbeitungsrechner überleben können. Auch können sich ökonomische Vorteile ergeben, z.B. indem die oft umfangreichen Plattenfarmen an Orten mit günstigen Mietpreisen gehalten werden. Allgemeine dezentrale Organisationsstrukturen werden damit jedoch nicht unterstützt, da hierzu neben einer ortsverteilten Rechneranordnung (LAN, MAN oder WAN) eine partitionierte Externspeicherzuordnung zur Wahrung einer möglichst hohen Unabhängigkeit (Knotenautonomie) einzelner Abteilungen vorzusehen ist.
Shared-Nothing-Systeme gestatten dagegen aufgrund der partitionierten Externspeicheranbindung sowohl eine lokale als auch eine ortsverteilte Rechneranordnung. Verteilte Datenbanksysteme repräsentieren einen bekannten Vertreter geographisch verteilter Shared-Nothing-Systeme.
Allerdings bestehen Verfügbarkeitsprobleme, da der gemeinsame Hauptspeicher nur eine geringe Fehlerisolation bietet und Software wie das Betriebssystem oder das DBVS nur in einer Kopie vorliegt [Ki84]. Auch die Skalierbarkeit ist i.a. stark begrenzt, da mit wachsender Prozessoranzahl der Hauptspeicher leicht zum Engpaß wird. Die Verwendung großer Prozessor-Caches erlaubt zwar eine Reduzierung von Hauptspeicherzugriffen und damit prinzipiell eine bessere Erweiterbarkeit, jedoch führen diese Caches zu einem Kohärenz- oder Invalidierungsproblem [St90]. Denn da nun Speicherinhalte repliziert in den privaten Cache-Speichern der Prozessoren gehalten werden, führen Änderungen in einem der Caches zu veralteten Daten in den anderen Caches.
Die erforderliche Kohärenzkontrolle führt jedoch in der Regel zu vermehrten Hauptspeicherzugriffen und Kommunikationsvorgängen, wodurch die Erweiterbarkeit oft wiederum stark beeinträchtigt wird. Schließlich wird die Erweiterbarkeit oft durch die für den Zugriff auf gemeinsame Hauptspeicher-Datenstrukturen notwendige Synchronisation zwischen Prozessen (z.B. über Semaphore) eingeschränkt, da die Konfliktwahrscheinlichkeit mit der Anzahl zugreifender Prozesse/Prozessoren zunimmt. Aus diesen Gründen sind derzeitige Multiprozessoren meist auf 2 bis 30 Prozessoren beschränkt, wobei bereits ab 10 Prozessoren i.d.R. nur noch geringe Leistungssteigerungen erzielt werden. Die mit Multiprozessoren effektiv nutzbare CPU-Kapazität ist somit relativ beschränkt und für Hochleistungssysteme vielfach nicht ausreichend.
Für lose gekoppelte Mehrrechner-DBS liegt in jedem Rechner eine Kopie des DBVS vor, die zur koordinierten DB-Verarbeitung miteinander kommunizieren. Damit ist im Gegensatz zu Shared-Everything, wo das Betriebssystem bereits die Existenz mehrerer Prozessoren weitgehend verbergen kann, die Verteilung im DBVS sichtbar, was zu einer aufwendigen Realisierung der DBVS führt. Welche Aufgaben Kommunikation erfordern, ist durch den gewählten Architekturtyp, Shared-Nothing oder Shared-Disk, bestimmt (s.u.). Auch die Realisierung einer effektiven Lastbalancierung ist weit schwieriger als bei enger Kopplung, da bei der Lastzuordnung neben einer Vermeidung von Überlastsituationen auch eine Minimierung von Kommunikationsvorgängen bei der DB-Verarbeitung unterstützt werden sollte.
Ziel einer nahen Rechnerkopplung [HR86, Ra86a] ist es, die Vorteile von loser und enger Kopplung miteinander zu verbinden. Wie bei der losen Kopplung besitzen die am Systemverbund beteiligten Rechner einen eigenen Hauptspeicher sowie separate Kopien der Software. Um die Kommunikation der Rechner effizienter realisieren zu können, ist jedoch die Nutzung gemeinsamer Systemkomponenten vorgesehen. Wie in Abb. 3-2c angedeutet, eignen sich hierzu besonders gemeinsame Halbleiterspeicher, über die ein schneller Nachrichten- bzw. Datenaustausch möglich werden soll. Desweiteren können globale Kontrollaufgaben ggf. erheblich vereinfacht werden, wenn statt eines verteilten Protokolls globale Datenstrukturen in einem solchen Speicher genutzt werden können. Aus Leistungsgründen ist es wünschenswert, wenn auf solch gemeinsame Speicher über spezielle Maschinenbefehle synchron zugegriffen werden kann, was Zugriffszeiten von wenigen Mikrosekunden voraussetzt[10]. Durch den Wegfall der Prozeßwechselkosten können dann enorme Einsparungen gegenüber einer losen Kopplung erwartet werden.
Natürlich birgt der gemeinsame Halbleiterspeicher ähnliche Verfügbarkeits- und Skalierbarkeitsprobleme wie ein gemeinsamer Hauptspeicher bei enger Kopplung. Eine größere Fehlerisolation als bei enger Kopplung wird jedoch bereits dadurch unterstützt, daß die einzelnen Rechner weitgehend unabhängig voneinander sind (private Hauptspeicher) und der gemeinsame Speicherbereich nur für globale Kontrollaufgaben genutzt wird. Weiterhin verlangen wir, daß der gemeinsame Speicher nicht instruktionsadressierbar sein darf [Ra86a], sondern die Auswertung und Manipulation von Speicherinhalten innerhalb der privaten Hauptspeicher durchzuführen ist. Desweiteren ist durch entsprechende Recovery-Protokolle zu gewährleisten, daß sich Software- und Hardware-Fehler einzelner Verarbeitungsrechner nicht über den gemeinsamen Speicherbereich ausbreiten und daß ein Ausfall des gemeinsamen Speichers schnell behandelt wird. Inwieweit Erweiterbarkeitsprobleme drohen, hängt vor allem von der Nutzung des gemeinsamen Speichers ab. Generell ist vorzusehen, daß eine Kommunikation wie bei loser Kopplung weiterhin möglich ist, und der gemeinsame Speicherbereich nur für spezielle, besonders leistungskritische Aufgaben verwendet wird, um so die Engpaßgefahr gering zu halten. Die Nutzung eines gemeinsamen Speichers verursacht natürlich Zusatzkosten, wobei zur Wahrung der Kosteneffektivität entsprechende Leistungsverbesserungen erreicht werden müssen.
Die nahe Kopplung schreibt eine lokale Rechneranordnung vor. Sie ist prinzipiell bei Shared-Disk und Shared-Nothing anwendbar. Jedoch ergeben sich für Shared-Nothing geringere Einsatzmöglichkeiten gemeinsamer Halbleiterspeicher, da dieser Architekturtyp auf eine Partitionierung von Haupt- und Externspeicher ausgerichtet ist. Allerdings könnte bei lokaler Rechneranordnung der Nachrichtenaustausch auch bei Shared-Nothing über gemeinsame Halbleiterspeicher abgewickelt werden. Eine solche allgemeine Einsatzform der nahen Kopplung wird daher auch sinnvollerweise bereits im Betriebssystem realisiert und bleibt daher für die beteiligten DBVS transparent. Wie in Kap. 13.4 gezeigt wird, ergeben sich für Shared-Disk weitergehende Einsatzformen einer nahen Kopplung.