Insbesondere in Anwendungsbereichen, in denen für den Entwurf und die Realisierung von Softwaresystemen verstärkt objektorientierte Techniken eingesetzt werden, bieten objektorientierte Datenbanken große Vorteile:
- natürliche Modellierung von komplex strukturierten Informationen in Form von Objekten und Beziehungen,
- objektorientierte Datenbank-Schnittstellen, bei denen die Datenbankfunktionalität nahtlos in eine Programmiersprache (meist C++ oder Smalltalk) integriert ist,
- effiziente Speicherung von Objekten und
- eine hohe Performance bei navigierenden Zugriffen von Objekt zu Objekt.
Zum Teil unterscheiden sich die derzeit verfügbaren ODBMS-Produkte allerdings erheblich, trotz Bestrebungen der Object Database Management Group (siehe Kasten auf Seite 24). Sie basieren auf unterschiedlichen Objektmodellkonzepten, haben verschiedene Möglichkeiten zur Schema- und Transaktionsverwaltung und im Mehrbenutzerbetrieb. Außerdem differieren sie bei den assoziativen Anfragemöglichkeiten, beim Zugriffsschutz und bei den Werkzeugen für den Datenbankadministrator. Architektur und interne Funktionsweise üben darüber hinaus erheblichen Einfluß auf das Laufzeitverhalten aus.
Wie auch die meisten relationalen Datenbanksysteme basieren ODBMS auf dem Client-Server-Architekturmodell. Verglichen mit relationalen Systemen wird aber bei den objektorientierten Systemen weitaus mehr Funktionalität direkt auf dem Client erbracht. Die Folge: verbesserte Performance bei vielen Zugriffsprofilen.
Dabei hilft insbesondere der Client-seitige Cache. Objekte werden im Client-Cache gepuffert und sind bei wiederholten Zugriffen meist lokal verfügbar, ohne daß eine Client-Server-Interaktion erforderlich wird. Nach den Einheiten, die zwischen Server und Client-Cache ausgetauscht werden, lassen sich zwei Datenbanktypen unterscheiden: Seiten- und Objekt-Server (siehe Abbildung auf Seite 24).
Bei den Seiten-Servern stellt der Server dem Client stets ganze Hintergrundspeicherseiten zur Bearbeitung zur Verfügung. Die Objektverwaltung des Datenbanksystems ist beim Client konzentriert.
Der Client kennt die Position und Größe der auf einer Seite gespeicherten Objekte und führt sämtliche Operationen auf diesen Objekten lokal aus. Auf diese Weise kommt die Rechenleistung des Client-Rechners zum Tragen, und der Server wird entlastet. Zu diesem Typus zählen "Objectivity/DB" von Objectivity und "Objectstore" von Object Design.
In Verbindung mit Seiten-Servern werden physische Objektidentifikatoren eingesetzt. Aus dem Objektidentifikator ist der Ort im Hintergrundspeicher direkt ableitbar. Benötigt der Client ein Objekt, das sich noch nicht im Cache befindet, so kann er anhand des Objektidentifikators direkt die Seite, auf der sich das Objekt befindet, ermitteln und laden. Alle weiteren Objekte, die sich auf der Seite befinden, sind ebenfalls in Hauptspeichergeschwindigkeit zugreifbar. Diesem Vorteil stehen Probleme gegenüber, die sich ergeben, wenn der Speicherort eines Objekts geändert wird, zum Beispiel bei Änderung der Objektgröße oder bei Datenbankreorganisationen.
Auch die Sperrgranularität ist seitenweise geregelt. Es werden alle Objekte, die auf einer Seite gespeichert sind, als Ganzes gesperrt und nicht nur die, die von der Applikation bearbeitet werden. Dieser Vorgang ist auch als "Phantomsperren" bekannt. Aus Anwendersicht können daraus unnötige Zugriffskonflikte resultieren, die zu niedrigeren als den erwarteten Transaktionsraten führen.
Die Auswertung von assoziativen Anfragen erfolgt bei Seiten-Servern vollständig auf der Client-Seite. Dafür müssen zunächst sämtliche der Objekte, auf die sich eine Anfrage bezieht, auf den Client überspielt werden. Dieser wertet die Anfragen für jedes Objekt aus und berechnet die Ergebnisse. Der Nachteil dieser Verfahrensweise besteht in dem aufwendigen Datentransfer vom Server auf den Client. Bei den heute üblichen Netzstrukturen, insbesondere bei WANs, kann die Client-seitige Anfragebearbeitung problematisch werden.
Objekt-Server dagegen wie "Versant" empfangen Objektanforderungen des Clients und schicken daraufhin ein oder mehrere einzelne Objekte an ihn zurück. Sie verwenden intern meist logische Objektidentifikatoren, bei denen erst eine Abbildungstabelle die Zuordnung zum physischen Speicherort herstellt. Zwar erfordern logische Identifikatoren eine Indirektionsstufe, um das zugeordnete Objekt aufzusuchen, aber sie bieten hohe Flexibilität bezüglich Änderungen der internen Datenbankorganisation: Wenn ein Objekt verschoben wird, reicht es aus, den Eintrag in der Abbildungstabelle anzupassen.
Eine Sperreinheit bezieht sich zumeist auf ein Objekt. Dadurch werden nur die Objekte gesperrt, die die Anwendung benötigt. Ein Phantomsperren ist ausgeschlossen. Greift aber die Anwendung auf sehr viele Objekte zu, kann der Aufwand für die Verwaltung der zahlreichen Sperren drastisch ansteigen. Deshalb bieten die meisten Produkte, die dem Objekt-Server-Ansatz entsprechen, eine zusätzliche Möglichkeit, um größere Objektmengen als Einheit zu sperren.
Die Serverseitige Auswertung von assoziativen Anfragen führt dazu, daß nur diejenigen Elemente der Datenbank an den Client übertragen werden, die die Anfragebedingung erfüllen. Allerdings bereitet das Client-Caching dem Datenbanksystem Schwierigkeiten: Dadurch, daß Objekte auf der Client-Seite gepuffert und dort modifiziert werden können, verfügt der Server nicht stets über den aktuellen Objektstatus. Damit geänderte und neu erzeugte Objekte in Anfragen berücksichtigt werden können, müssen sie somit zuvor vom Client an den Server zurückgeschrieben werden. Mit geschickten Tuning-Maßnahmen läßt sich die Leistungsfähigkeit von Datenbankapplikationen mitunter erheblich steigern. Gerade bei Performance-kritischen Anwendungen kommen Administratoren um ein grundlegendes Tuning nicht herum.
Jedes ODBMS bietet zu diesem Zweck einen mehr oder weniger umfangreichen Satz an "Stellschrauben". Das Spektrum reicht von einfachen, aber effektiven Maßnahmen wie dem Anlegen von Indizes zur Zugriffsbeschleunigung bis hin zu speziellen Transaktionskonzepten, beispielsweise dem "Multiple-Reader-One-Writer" in Objectivity/DB und der "Multi-Version-Concurrency-Control" in Objectstore, mit denen sich die Parallelität steigern läßt.
Viele Maßnahmen hängen unmittelbar mit der Architektur zusammen. So sind etwa die Cache-Größen auf der Client- und eventuell auf der Server-Seite an die zu bearbeitende Objektmenge anpaßbar.
Objektorientierte Datenbanken sind immer dann schnell, wenn sich die benötigten Objekte bereits im Client-Cache befinden. In diesem Fall erfolgt der Zugriff in Hauptspeichergeschwindigkeit. Müssen die Objekte erst vom Server angefordert werden, so dauert der Zugriff aufgrund der Netzkommunikation länger. Tuning-Maßnahmen befassen sich deshalb auch damit, die zeitaufwendige Kommunikation zwischen Client und Datenbank-Server zu reduzieren.
Bei Seiten-Servern wird die Anzahl kostspieliger Seitentransfers über das Netz verringert, wenn eine physische Seite bereits viele Objekte enthält, die von der Applikation benötigt werden. Eine entsprechende Gruppierung der Objekte läßt sich in vielen Systemen über Clustering-Direktiven einstellen. Dafür muß der Speicherungsort explizit angebbar sein, zum Beispiel durch die Mitteilung logischer Einheiten wie Containern in Objectivity/DB oder von Clustern und Segmenten wie in Objectstore.
Objekt-Server erfordern eine andere Steuerung, da hier ohnehin immer nur angeforderte Objekte zwischen Server und Clients transportiert werden. Der Kommunikationsaufwand läßt sich reduzieren, indem die Anzahl der Objekttransporte verringert wird. Zum Beispiel kann das Ergebnis einer assoziativen Anfrage oder bei einer Traversierung die Menge der in Beziehung stehenden Objekte als Objektgruppe mit einem Transfer aus der Datenbank geholt werden: Versant bezeichnet den Vorgang als "group fetch". Umgekehrt lassen sich mehrere Objekte in der Anwendung als Objektgruppe zusammenstellen und auf einmal speichern.
*Uwe Hohenstein, Regina Laufer, Klaus Schmatz und Petra Weikertsind bei der Siemens AG als Software-Entwickler und DV-Berater tätig und Autoren des Buches "Objektorientierte Datenbanksysteme - ODMG-Standard, Produkte, Systembewertung,Benchmarks, Tuning", Vieweg Verlag, 1996.