Objektorientierte Datenbanken sind immer noch Ausnahmen von der relationalen Regel. Sie versprechen aber eine bessere Integration in Programme, die mit einer objektorientierten Sprache erstellt wurden. Die Datenbank Goods aus Russland - ausgestattet mit einer BSD-ähnlichen Lizenz - misst sich in diesem Coffee-Shop an diesem Anspruch.
Einen Überblick über verschiedene Datenbanksysteme unter Linux gab es in der April-Ausgabe des Linux-Magazins. Auf fast alle dieser Datenbanken ist der Zugriff über JDBC möglich, das Java-Standard-API für den DB-Zugriff. Das API ist einfach und lässt sich weitgehend sogar datenbankunabhängig verwenden - trotzdem ist es ein Strukturbruch. Die Beziehungen zwischen Objekten lassen sich nicht immer in relationale Tabellen zwingen. Und das Schreiben und Lesen von Daten oder Objekten ist stets explizit zu implementieren. Damit werden die Applikations- und die Persistenzschicht innerhalb des Codes gemischt.
Ist eine Datenbank schon vorhanden, die eventuell sogar schon von alten Anwendungen genutzt wird, gibt es zu JDBC im Grunde keine Alternative. Bei neuen Anwendungen allerdings ist der Verzicht auf eine klassische Datenbank immer eine Überlegung wert. Das gilt umso mehr, je stärker die zu speichernden Objekte miteinander durch Referenzen verknüpft sind. Denn gerade jene Objekte, die nicht Value-Objects sind, also nur einfache Attribute besitzen, lassen sich schwer in relationale Datenbanken abspeichern. Als Beispiel sei ein Stammbaum genannt: Hier gibt es eine Fülle vielfältiger Objektbeziehungen.
Um aber nicht zu sehr in die Theorie abzugleiten, geht es gleich ins Eingemachte: Die Datenbank Goods wird zunächst heruntergeladen, kompiliert und installiert.
Die Quelle von Goods (Generic Object Oriented Database System) ist [1]. Der Download des 604 KByte großen Pakets geht flott vonstatten. Zusätzlich sind zwei nützliche Postscript-Dateien verfügbar: Eine ausführliche Readme-Datei (31 Seiten) und eine Beschreibung des Zugriffs über Java (13 Seiten). Wer also längere Dokumentationen lieber in Papierform liest, ist hier sehr gut bedient. Allerdings scheinen mir die in der Distribution vorhandenen HTML-Versionen etwas aktueller zu sein. Nach dem Entpacken wird zuerst das Skript Config aufgerufen, das im Wesentlichen ein paar Makefile-Templates umkopiert. Danach langt die schlichte Anweisung
> make -k all
um die Client- und Serverbibliotheken, die administrativen Tools, die Beispiele und die Java-Bibliotheken zu erzeugen. Die Option -k war in der eingesetzten Version 2.37 notwendig, weil das Linken eines Beispiels nicht funktioniert hat. Das beeinträchtigt aber nicht die Funktionsweise des Serverprogramms oder der Java-Schnittstelle.
Nach dem Kompilieren befinden sich im lib-Verzeichnis die Bibliotheken libclient.a, libserver.a sowie die beiden Jar-Archive goodsjpi.jar und goodslib.jar. Im bin-Verzeichnis sind dagegen die Tools und der eigentliche Server goodsrv gelandet.
Goods ist grundsätzlich sprachneutral, aktuell stehen C++- und Java-Schnittstellen bereit. Das wird möglich, weil die gesamte Applikationslogik beim Client liegt, während der Server für das Schreiben und Lesen von Objekten, Transaktionen, Objekt-Locks, Backups, Garbage Collection und so weiter verantwortlich ist.
Die Kommunikation zwischen Client und Server verwendet ein Request/ Response-Messagemodell auf normalen Netzwerkverbindungen. Das Protokoll ist ausführlich dokumentiert und kommt zurzeit mit 14 Requesttypen und zehn Reply-Typen aus. Deren Details sind aber für einen normalen Benutzer irrelevant, eher für Programmierer, die beispielsweise eine Schnittstelle zu Python implementieren wollen.
Goods-Datenbanken bestehen aus einem oder mehreren Storages, die über das gesamte Netzwerk verteilt sein können. Jedes Storage wird von einem Storage Server ( goodsrv) verwaltet. Ein Objekt wird jeweils nur in einem storage gespeichert. Ist es einmal dort gebunden, kann es nicht mehr verschoben werden. Mehrere Server dienen also nicht der Replikation, sondern der Partitionierung.
Normalerweise muss sich ein Client nicht darum kümmern, wo das Objekt gespeichert wird, es ist aber möglich, dies Client-seitig zu definieren. Die Anzahl der Server pro Datenbank sollte nicht zu groß sein, da sonst ein zu hoher Synchronisationsaufwand notwendig ist, etwa bei serverübergreifenden Transaktionen.
Die Architektur des Servers ist modular. So gibt es einen Storage Memory Manager, einen Transaction Manager, einen Page Pool Manager, einen Object Access Manager und einen Class Information Manager. Durch die modulare Struktur sind diese Komponenten austauschbar, es lassen sich also auch mehrere Implementationsstragegien untersuchen.
Alle Rezensionen aus dem Linux-Magazin
Im Insecurity Bulletin widmet sich Mark Vogelsberger aktuellen Sicherheitslücken sowie Hintergründen und Security-Grundlagen. mehr...
