4 Architektur von Verteilten Datenbanksystemen
4.3 Katalogverwaltung
Wie im zentralen Fall werden auch in Verteilten DBS die Schemaangaben zum DB-Aufbau sowie weitere Metadaten wie Zugriffsberechtigungen, Paßwörter oder Statistiken (Relationengrößen, Werteverteilungen, Zugriffshäufigkeiten etc.) in einem Katalog verwaltet. Aufgrund der eingeführten Schemaarchitektur kann im verteilten Fall zwischen lokalem und globalem Katalog unterschieden werden. Ein lokaler Katalog entspricht im wesentlichen dem Katalog eines zentralisierten DBS und enthält insbesondere das LKS und LIS eines Knotens. Der globale Katalog dagegen umfaßt u.a. das GKS und GVS und ist damit maßgebend zur Gewährleistung von Verteilungstransparenz. Insbesondere lassen sich mit ihm logische Objektnamen des globalen konzeptionellen Schemas transparent für den Benutzer auf physische Adressen abbilden. Der globale Katalog dient ferner zur systemweiten Verwaltung von Benutzern und Zugriffsrechten. Die Katalogdaten werden vor allem bei der Übersetzung, Optimierung und Ausführung von DB-Anfragen benötigt (Kap. 6).
In relationalen Datenbanksystemen hat es sich durchgesetzt, den Katalog selbst als Datenbank zu führen, auf die mit der DB-Anfragesprache zugegriffen werden kann. Zudem lassen sich dann die Mechanismen zur Transaktionsverwaltung (Synchronisation, Logging, Recovery) auch auf den Katalog anwenden. Der SQL-92-Standard schreibt ein sogenanntes INFORMATION-SCHEMA vor, das aus verschiedenen Sichten (Views) auf den eigentlichen Katalog ("Definition Schema") besteht [[DD92], [MS92]]. Zur Unterstützung von Datenunabhängigkeit bzw. Verteilungstransparenz sind im INFORMATION_SCHEMA keine Angaben bezüglich des internen Schemas (z.B. existierende Indexstrukturen) und Verteilungsschemas vorgesehen. Diese Angaben befinden sich lediglich im Katalog selbst, dessen Aufbau jedoch nicht standardisiert ist, sondern herstellerspezifisch festgelegt werden kann.
Bei der Verwaltung des Katalogs ist neben dem Aufbau des Katalogs vor allem zu klären, wo dieser gespeichert werden soll. Dabei ist generell vorzusehen, daß jeder Knoten einen lokalen Katalog bezüglich der bei ihm vorliegenden Objekte führt. Damit können für lokale Daten auch für den Katalogzugriff Kommunikationsvorgänge vermieden werden. Dies ist bei der oft hohen Lokalität des Datenzugriffs für das Leistungsverhalten sehr wesentlich. Weiterhin wird ein hohes Maß an Knotenautonomie unterstützt. Für die Speicherung des globalen Katalogs bestehen im wesentlichen folgende Alternativen:
- Zentralisierter Katalog
Sämtliche globalen Katalogangaben werden an einem zentralen Knoten gespeichert. Dieser Ansatz ist einfach, führt jedoch einen hohen Kommunikationsaufwand ein. Weiterhin stellt der zentrale Knoten einen potentiellen Leistungs- und Verfügbarkeitsengpaß dar. Zudem ergibt sich eine für geographisch verteilte Systeme inakzeptable Beeinträchtigung der Knotenautonomie.
- Replizierter Katalog
Jeder Knoten führt eine vollständige Kopie der globalen Katalogdaten. Der Vorteil liegt darin, daß lesende Katalogzugriffe stets lokal, ohne Kommunikationsverzögerungen, durchführbar sind. Änderungen sind dagegen sehr aufwendig, insbesondere in geographisch verteilten Systemen, da sie an allen Knoten durchzuführen sind. Zur Wartung der Replikation kommen dabei dieselben Techniken wie für replizierte Datenbanken (Kap. 9) in Betracht. In geographisch verteilten Systemen ist es auch unter Schutzaspekten problematisch, daß in jedem Rechner Metadaten von allen Knoten vorliegen, auch wenn deren Daten nicht referenziert werden.
- Mehrfachkataloge
Hierbei partitioniert man die Rechner in mehrere Cluster, wobei pro Cluster jeweils ein Knoten den vollständigen globalen Katalog hält. Dies entspricht einem Kompromiß aus den beiden vorhergehenden Ansätzen. Insbesondere wird der Änderungsaufwand reduziert; die Einschränkungen des zentralisierten Ansatzes hinsichtlich Engpaßgefahr, Verfügbarkeit und unzureichender Knotenautonomie entfallen weitgehend. Allerdings ist weiterhin für jeden globalen Katalogzugriff Kommunikation erforderlich.
- Partitionierter Katalog
Der globale Katalog wird unter allen Rechnern partitioniert gespeichert. Dabei erfolgt keine explizite Speicherung des GKS, sondern dieses ergibt sich als Vereinigung der LKS. Eine Partitionierung des GVS ist möglich, da durch erweiterte Objektbezeichnungen ermittelt werden kann, wo die relevanten Verteilungsinformationen vorliegen, um nicht-lokale Objekte zu lokalisieren (s. Namensverwaltung, Kap. 4.4).
Von diesen Alternativen erscheint der letzte Ansatz am vielversprechendsten, da er den höchsten Grad an Knotenautonomie bewahrt. Allerdings werden dabei für nicht-lokale Daten Kommunikationsvorgänge bereits für Katalogzugriffe erforderlich. Dieser Nachteil kann durch eine Pufferung (Caching) nicht-lokaler Katalogdaten abgeschwächt werden. Damit läßt sich für häufiger benötigte Katalogdaten anderer Rechner ebenfalls Kommunikation vermeiden.
Bei der Pufferung nicht-lokaler Katalogdaten besteht ein ähnliches Änderungsproblem wie bei replizierten Katalogen, da gepufferte Kopien nach einer Änderung an einem anderen Knoten ungültig sind. Im Zusammenhang von (replizierter) Pufferung von Objekten spricht manedoch üblicherweise von der Notwendigkeit einer Kohärenzkontrolle [Ra93b]; Anzahl und Ort der Kopien sind im Gegensatz zu replizierten Katalogen (Datenbanken) nicht vorbestimmt sondern ergeben sich dynamisch durch die Referenzverteilung im System. Zur Kohärenzkontrolle für gepufferte Katalogdaten werden im wesentlichen zwei Alternativen eingesetzt:
- Der Besitzerknoten der Katalogdaten vermerkt sich, an welchen Rechnern eine Pufferung seiner Daten erfolgte. Bei einer Änderung werden die betroffenen Kopien explizit invalidiert. Damit kann der Zugriff auf invalidierte Daten vermieden werden, jedoch zu Lasten eines hohen Wartungs- und Kommunikationsaufwandes. Ein solcher Ansatz wurde in der Prototyp-Implementierung SDD-1 verfolgt.
- Bei der im Prototyp R* realisierten Alternative wird eine Invalidierung von Katalogdaten zugelassen [Li81]. Die Verwendung veralteter Katalogdaten bei der Erstellung von Ausführungsplänen für DB-Operationen wird erst zur Ausführungszeit an den datenhaltenden Knoten erkannt. Dies geschieht durch Führen von Versionsnummern für Katalogeinträge, wobei in den Ausführungsplänen die Versionsnummern der verwendeten Kopien aufgenommen werden. Wird zur Ausführungszeit festgestellt, daß nach Erstellung des Ausführungsplanes eine Änderung der Katalogdaten erfolgte (z.B. Löschen einer Indexstruktur), muß ein neuer Plan bestimmt werden.
Ein Sonderfall bei der lokalen Katalogverwaltung ergibt sich, wenn Objekte (Relationen) über mehrere Knoten partitioniert oder repliziert sind. In diesem Fall empfiehlt sich, die Kataloginformation der Objekte repliziert an allen Knoten zu führen, an denen sie (teilweise) gespeichert werden [Li81]. Denn dann können die Katalogzugriffe für lokal vorliegende Objekte weiterhin lokal abgewickelt werden.