Postrelationale Datenbank Cache

Viele Datenbanksysteme sind bereits auf Linux portiert worden. Dazu zählen auch solche, die ihre Datenbestände nicht in Form flacher, relationaler Tabellen, sondern objektorientiert verwalten. Ein Vertreter dieser Richtung ist die postrelationale Datenbank Caché der Firma Intersystems.

Caché, aktuell in der Version 4.0 vorliegend, bedient sich einer speziellen Form der Datenverwaltung, der Unified Data Architecture (Abbildung 1). Dabei ist es möglich, mit einer ganzen Reihe von Front-Ends auf die Datenbestände zuzugreifen und sie für die verschiedensten Auswertungen zur Verfügung zu stellen. So hat jeder Entwickler das ihm gewohnte Werkzeug und ist auch unabhängig vom eingesetzten Betriebssystem, das auf Server- und Client-Seite auch unterschiedlich sein kann.

Bezüglich der Serverplattform kann zwischen OpenVMS, Windows sowie verschiedenen Unixen und Linuxen gewählt werden. Offiziell unterstützt Intersystems Red Hat 6.0 bis 7.0, SuSE 6.3 bis 7.0 und Turbo Linux 6.0. Jedoch ist der Server bei etwas Aufwand auch mit höheren Versionen oder anderen Distributionen lauffähig.

Installationshürden

Für den Test stand die Linux-Department-Version 4.0.3 des Caché-Datenbankservers zur Verfügung. Nach dem Mounten der CD beginnt mit der Kommandofolge

cd /cdrom
./cinstall

die Installation. Hierzu ist ein echter Root-Login erforderlich, »su« führt zum Abbruch. Das Installationsskript »cinstall« testet auf Vorhandensein eines unterstützten Betriebssystems und fragt vom Administrator das Installationsverzeichnis ab. Danach wird eine Reihe weiterer Fragen zur Installation gestellt, unter anderem nach der Gruppe des Benutzers, der den Datenbankserver starten und herunterfahren darf. Zweckmäßig ist hier »root« anzugeben.

Das Kopieren von Dateien geht flott vonstatten (auf den meisten gängigen PCs unter zehn Minuten); danach wird der Server sofort gestartet und initialisiert. Schließlich ist noch eine Reihe diffiziler Fragen zur Lizenz zu beantworten. Der letzte Teil lässt sich auch auf später verschieben, dann läuft die Datenbank zunächst mit einer Ein-Benutzer-Lizenz, wie sie Beta-Testern bekannt ist (siehe Web-Link [1]).

Die Erweiterung der Lizenz lässt sich jederzeit nachträglich vornehmen. Zusätzlich ist es möglich, im Anschluss an die eigentliche Serverinstallation ein CGI-Interface zum - unter Linux meist vorhandenen - Webserver zu installieren. Dieser Installationsschritt macht den Server fit zur Verarbeitung von Cache Server Pages (CSP) und lässt sich, wie schon der vorige, auch später ausführen. Das zugehörige Skript »CSPinstall,« das sich im Unterverzeichnis »csp« des Caché-Installationsverzeichnisses befindet, hat einen kleinen Bug: Die Zeile

WSCGI ="/usr/httpd/cgi-bin"

müsste eigentlich lauten:

WSCGI="/usr/httpd/cgi-bin"

Das stört aber den Installationsprozess nur wenig. Gravierender ist der Lapsus, dass in die Apache-Konfigurationsdateien einfach beim jeweils letzten Auftreten des Containers für das CGI-Directory ein »FollowSymlinks« an die Optionen angehängt wird. Das kann gut gehen, schief geht es aber auf jeden Fall bei den »SSLOptions«, wo es natürlich ein Syntaxverstoß ist.

Deshalb empfiehlt es sich nicht, am Ende der Installation den Apache-Webserver neu starten zu lassen, da er sonst leise abstirbt. Vielmehr ist die überzählige Option von Hand aus dem SSL-Abschnitt der Datei »httpd.conf« beziehungsweise der »access.conf« zu entfernen und in den richtigen Container einzusetzen. Erst dann darf der Webserver neu gestartet werden. Zusätzlich ist ein Neustart des »CSPnsd« (CSP network service daemon) erforderlich. Leider versteht der Dämon das HUP-Signal nicht im üblichen Sinne, so dass er über

Installationsverzeichnis/csp/CSPnsd

im Anschluss an ein vorher gegebenes TERM- beziehungsweise HUP-Signal erneut gestartet werden muss.

Caché Server Pages

Nach all diesen Mühen wird der Installateur durch einen schönen Erfolg belohnt. Ein Blick auf die offenen Ports zeigt uns:

netstat -ta

Active Internet connections
(servers and established) Proto Recv-Q Send-Q Local
Address Foreign Address
State tcp 0 0 *:7038 *.* LISTEN
tcp 0 0 *:intersys-cache *.* LISTEN ...

Beide erforderlichen Ports »1972« und »7038« werden überwacht; sowohl der Datenbankserver als auch der CSP-Network-Service-Dämon warten auf Aufträge. Das lässt sich gleich verifizieren, indem in einem Javascript-fähigen Webbrowser die URL »http://localhost/csp /samples/menu.csp« eingegeben wird. Es dauert einen Moment, weil der Datenbankserver die angeforderte Seite beim ersten Aufruf zunächst kompilieren muss, aber dann erscheint ein Menü mit Links auf Beispielseiten, die die Leistungsfähigkeit der CSP-Technologie eindrucksvoll demonstrieren.

Eine einfache Anwendung ist die Anzeige von Eigenschaften gespeicherter Objekte (Abbildung 2): Der Benutzer trägt im Formularfeld eine Zahl von 1 bis 100 ein und klickt auf den »Go«-Button. Daraufhin wird das gespeicherte Objekt aus der Datenbank in den RAM geholt, wo sein Inhalt für diverse Auswertungen zur Verfügung steht. In unserem Fall handelt es sich um ein Objekt der Klasse »Person«, dessen Eigenschaften »Name« und »SSN« (Sozialversicherungsnummer) im unteren Teil des Browserfensters angezeigt werden.

Beim Browserzugriff ist es seitens der Datenbank egal, von welchem Rechner aus er erfolgt. Für den Caché-Server tritt als Kunde stets der Apache-Server in Erscheinung. Dessen Zugriffsberechtigungen sind für Remote-Zugriffe natürlich entsprechend den Wünschen des Anwenders einzustellen. Ist dies geschehen, kann der Client-Rechner irgendwo im Netz stehen, auch das Betriebssystem ist beliebig. Es ist lediglich in der obigen URL die Bezeichnung »localhost« durch den DNS-Namen oder die IP-Adresse des Hosts zu ersetzen, auf dem der Webserver läuft.

Abbildung 1: Die Unified Data Architecture (UDA) erlaubt sowohl objektbasierte als auch SQL-Zugriffe auf die gespeicherten Daten.