5 Datenbankverteilung

5.2 Allokation und Replikation

Nach Festlegung der Fragmentierung für globale Relationen besteht der zweite Schritt bei der Datenverteilung in der Allokation der Fragmente zu Knoten. Wird dabei keines der Fragmente mehrfach allokiert, erhält man eine partitionierte Datenbank, anderenfalls eine replizierte Datenbank. Im letzteren Fall unterscheidet man noch zwischen voller Replikation, bei der jede globale Relation vollständig an allen Rechnern gespeichert wird, und partieller Replikation. Bei voller Replikation entfällt das Fragmentierungs- und Allokationsproblem. Weiterhin erübrigt sich eine verteilte Anfrageverarbeitung, da jede lesende DB-Operation lokal verarbeitet werden kann. Die Speicherplatz- und Änderungskosten einer vollen Replikation sind jedoch meist prohibitiv.

Ein wesentliches Ziel der replizierten Datenhaltung ist die Steigerung der Verfügbarkeit, da im Gegensatz zur partitionierten Datenallokation replizierte Objekte auch nach Ausfall eines der Speicherknoten zugreifbar bleiben. Replikation kann jedoch - für Leseoperationen - auch unter Leistungsgesichtspunkten sinnvoll sein. Denn wenn mehrere Knoten ein bestimmtes Fragment führen, bestehen größere Optimierungsmöglichkeiten zur Erstellung eines kostengünstigen Ausführungsplanes. Insbesondere kann ein repliziertes Objekt an mehreren Knoten lokal referenziert werden, so daß Kommunikationsvorgänge gegenüber einer partitionierten Datenbankallokation eingespart werden können. Weiterhin erhöhen sich die Möglichkeiten zur Lastbalancierung, da bestimmte Datenzugriffe von mehreren Rechnern ausführbar sind. Diese Vorteile werden jedoch zu Lasten von Änderungsvorgängen erkauft, da jede Objektänderung auf alle Kopien (Replikate) propagiert werden muß.

Aufgrund der geforderten Replikationstransparenz ist die Wartung der Replikation alleinige Aufgabe des Verteilten DBS. Für den Benutzer bleibt die Existenz von Replikation vollständig verborgen. Ebenso unsichtbar bleibt die Lokation einzelner Fragmente (Ortstransparenz).