MÜNCHEN (mer) - Eine Untersuchung von neun Datenbanksystemen die unter dem Betriebssystem Unix zur Verfügung stehen, führte unlängst die Scientific Control Systems GmbH durch. Auf dem "SCS-Prüfstand" landeten die DB-Systeme Informix, Ingres, Logix, MDBS, Mistress, Oracle, Sequitur, Unify und Yard, welche das Hamburger Systeshaus für den eigenen Bedarf evaluierte.
Im wesentlichen stützte sich die SCS auf Manuals und Präsentationen der Hersteller. In einigen Fällen wurde die Software auch im praktischen Einsatz getestet. So etwa die DB-Systeme Oracle und Unify, die bei SCS in Kundenprojekte involviert waren. Ihr Augenmerk richteten die Hamburger vornehmlich auf die Frage welche Eigenschaften ein "aufgesetztes" DBMS haben sollte, um gut mit dem Unix-Betriebssystem zu harmonieren.
Wie viele andere moderne Betriebssysteme enthält auch Unix für das Filesystem einen Cache im Hauptspeicher. In ihm werden Plattenblöcke nach einer LRU-Ersetzungsstrategie (LRU: Least Recently Used) im schnellen Zugriff gehalten.
Zusätzlich werden bei Erkennen von physikalisch-sequentiellem Zugriff im voraus Blöcke in den Cache geladen (Prefetch).
Für viele Anwendungen ist dieses nach Meinung der SCS eine wünschenswerte Eigenschaft, da bei vorhandener "Lokalität" der Zugriffe - analog zum demand paging - aufeinanderfolgende Ein-/Ausgaben nicht notwendigerweise Zugriffe zum Filesystem erforderlich machen.
Plattencache nicht unbedingt ein Vorteil
Im Zusammenhang mit einem aufgesetzten Datenbanksystem müsse dieser Plattencache jedoch nicht unbedingt von Vorteil sein, sondern könne unnötigen System-Overhead erzeugen.
Es gibt DB-Systeme (zu ihnen gehört das Unify-System), die sich explizit auf die LRU-Strategie des Betriebssystems verlassen und es sich leisten, für jedes einzelne Feld eines
n-Tupels (Record) einen I/O-Request abzusetzen.
Hier sehen die Hamburger Softwerker einige Vorteile in der Performance und beim Speicherbedarf. So sei beispielsweise der Overhead eines einzelnen Feldzugriffs unabhängig von der Satzlänge, Recordpuffer seien nicht notwendig und es gebe keine Längenbegrenzung für n-Tupel (beim "Ingres"-DBMS muß ein n-Tupel in eine Page passen). Aber auch in Bereichen der Datensicherheit und des konkurrierenden Zugriffs ergibt sich weiterer Nutzen für den User: Da logisch zusammengehörige Updates in verschiedenen Records direkt aufeinanderfolgend gemacht werden können, gebe es in der Datenbank, abgesehen von der Diskrepanz zwischen Plattencache und Filesystem, weniger inkonsistente Zustände. Weiterhin seien Zugriffe auf verschiedene Felder eines Satzes physikalisch entkoppelt, so daß ein Record-Locking nicht notwendig ist.
Ad-hoc Suche sequentiell
Die Untersuchungen der SCS haben gezeigt, daß viele Ad-hoc-Queries es erforderlich machen, den gesamten Datenbestand sequentiell abzusuchen. Dazu müßte, sollte den Prefetch-Mechanismus unter Unix wirken, alle Records eines Typs physikalisch dicht gepackt sein, konstatieren die Hamburger. Viele Datenbanken seien optimiert für den direkten Zugriff über einen Primärschlüssel (key), wobei über einen Hash-Algorithmus aus dem Key direkt die Adresse des Records bestimmt wird (zum Beispiel Ingres). Sequentielle Zugriff sei dann nur über Indextabellen oder Pointer-Ketten möglich, so daß ein Prefetch wirksam wird. Auf der anderen Seite gebe es Datenbanksysteme, die ohne Hashkeys und nur zum Beispiel mit
B-Trees indizieren (Oracle, Informix, Mistress). Unify verwendet ein zweistufiges Verfahren: Der Key liefert eine Adresse in der Hashtable, die ihrerseits die Recordadressen enthalten. Die Vorteile sind offensichtlich: Hash-Algorithmen können geändert werden, ohne Sätze physikalisch zu verschieben, und Records eines Typs sind für den schnellen sequentiellen Zugriff dennoch dicht gepackt.
Ein schwerwiegendes Problem wirft nach Ansicht der SCS-Spezialisten der Plattensache bezüglich der Integrität der Datenbank auf. Bei einem Systemzusammenbruch könne das Filesystem in einem inkonsistenten Zustand zurückbleiben.
Ein sicherer Recovery-Mechanismus sei nur implementierbar, wenn an sogenannten Checkpoints ein vollständiges Zurückschreiben aller Plattenblöcke erzwungen werden könne. Im Unix-System gebe es hierzu den Systemcall "sync", der allerdings bewirke, daß der Cache vollständig geleert wird, so daß diese Möglichkeit aus Performance-Gründen ausscheide.
Die MDBS-Datenbank löse das Problem, indem das Filesystem völlig umgangen und der Plattenzugriff über einen speziellen, in das System eingebundenen Treiber durchgeführt werde.
Andere Datenbanksysteme (Informix, Unify) bewältigen die Situation durch das Mitführen von Protokollen (Audit Trails, Transaction Logging). Die Protokollierung wird gestartet, nachdem die Datenbank vollständig gesichert worden ist. Nach einem Crash muß die gesamte Datenbank restauriert und das Protokoll bis zum letzten Konsistenzpunkt nachgezogen werden.
Eine wesentliche Forderung der SCS an die Datenbanksysteme war die Multiuser-Fähigkeit. Damit verbunden ist die Notwendigkeit, Datenbereiche gegen den Zugriff anderer Prozesse zu schützen. Nach den Erkenntnissen der Studie gab es im Unix-System dazu bisher keinen effizienten Mechanismus. File Locks waren meist der einzige Ausweg. Viele Unix-Systeme bieten jedoch mit dem System-Call "locking" eine Erweiterung des Kernels (Xenix, Onix, Plexus, Berkeley unix), mit dem beliebige Bereiche eines Files gegen den Zugriff anderer gesperrt werden.
Im System V gibt es Semaphoren. Da auch eine verbesserte Interprozeßkommunikation implementiert ist, lassen sich nun effiziente DB-Server Systeme aufbauen.
Die Hamburger haben bei ihren Untersuchungen festgestellt, daß das Einsatzspektrum der Datenbanksysteme sehr unterschiedlich ist.
So gebe es Systeme, die sich im wesentlichen als eine Menge von Elementaroperationen auf "flat files" darstellen, ergänzt um einen sogenannten relationalen Editor, mit dem sich solche Tabellen editieren lassen. Diese Produkte unterstützten überhaupt keinen direkten Zugriff und seien so langsam, daß sie bei größeren Datenmengen nicht mehr sinnvoll einzusetzen sind (Beispiel sind Sequitur und Yard).
Weiterhin sind nach Meinung der SCS Datenbanken auf dem Markt, deren Benutzeroberfläche von der Theorie her zwar sehr elegant sind und in denen sich jede Art von Query formulieren läßt. Jedoch sind sie so langsam, daß sie sich bei mehr als 500 Records nicht mehr einsetzen lassen (Beispiele dafür sind Sequitur und mit Einbehalt Yard).
Es gibt aber auch DBMS-Systeme deren Einsatzspektrum sehr groß ist die also eine Menge sogenannter "Features" haben. Nachteil dieser Systeme ist, daß sie viel Ressourcen benötigen und auf kleinen Mikros nur mit Einschränkungen lauffähig sind (MDBS, Ingres, Oracle).
Andere DB' s wie etwa Mistress, Informix, Logix oder Unify sind nach Aussagen der SCS-Tester mehr im mittleren Bereich angesiedelt.
In Datenbanken mit Netzwerkstrukturen (MDBS) wird die physikalische Struktur vom Anwender vorgegeben. Daten, die häufig miteinander in Beziehung gebracht werden können über Pointer-Ketten oder Pointer-Listen direkt miteinander verknüpft werden. Die Hamburger kamen bei ihrer Untersuchung zu dem Ergebnis, daß es eine Eigenart des Unify-Systems ist, daß implizite Member/Owner-Relationen nachträglich in explizite Relationen verwandelt werden können. Die Anpassungsmöglichkeiten an verschiedene Performance-Anforderungen seien hier besonders gut, da auf unterster Ebene mit Netzwerkstrukturen und auf oberster Ebene mit einer relationalen Query-Language (SQL) operiert werden könne.
Kein Navigieren in Netzwerkstrukturen
Im Bereich der Query-Sprachen setzt sich das relationale Modell durch, so die SCS-Studie, da das Navigieren in vordefinierten Netzwerk-Strukturen entfällt. Unter den relationalen Query-Sprachen scheint sich SQL durchzusetzen (System R, Oracle, Unify).
Alle untersuchten DB-Systeme hatten mehr oder weniger mächtige Report Writer. Interessant war für das Systemhaus, wie die Report Writer in Applikationen eingebunden werden können. Der Report Writer sollte auch isoliert von der Query Language zum Beispiel aus Programmen ansprechbar sein.
Als einen wesentlichen Punkt wertete die Testmannschaft der SCS die Fähigkeit der einzelnen Systeme, den Entwurf benutzerfreundlicher Schnittstellen zu unterstützen. Hier ergaben sich denn auch eklatante Unterschiede: Die einfachsten Datenbanken stellen nur eine nicht-prozedurale Schnittstelle zur Verfügung (zum Beispiel Sequitur, Yard). Es gibt keine Programmierschnittstelle, was zur Folge hat, daß man sein Problem entweder mit diesen Tools lösen kann - oder überhaupt nicht.
Beim DB-System Informix ist zwar eine Programmierschnittstelle vorhanden, diese besteht aber nur aus neun einfachen Prozeduren, die lediglich geeignet sind, einzelne Relationen zu aktualisieren. Query-, Report-, Sortier- oder Bildschirmfunktionen gibt es nicht.
Die Programmierschnittstellen von Mistress, Logix und MDBS sind etwas mächtiger, aber Report- und Bildschirmfunktionen sind auch hier nicht vorhanden.
Tools für BS-Formulare
Unify, Oracle und Ingres haben sehr mächtige Programmierschnittstellen. Mit ihnen lassen sich beliebige Benutzerschnittstellen aufbauen unter Ausnutzung aller Möglichkeiten des Datenbanksystems. Diese Systeme haben auch mehr oder weniger mächtige Tools zum Definieren von Bildschirmformularen. Die Bildschirmfelder erhalten logische Namen, so daß sich Maskenlayouts ohne Eingriffe in die Programme ändern lassen.
Unify und Ingres haben zusätzlich Standard-Kontroll-Programme zwischen Datenbank und Bildschirmmasken (QBF, Query by Forms), so daß sich Anwendungen generieren lassen, ohne ein einziges Programm zu schreiben. Großer Vorteil dieser Schnittstellen sei es, so die Hamburger, daß der Anwender keine Kenntnis über die intern benutzten Attribut- und Recordtyp-Namen haben müsse.
Im Unify-System lassen sich komplette Anwendungen mit Standard-Tools erzeugen, da auch noch Menüs zu Programm- und Bildschirmauswahl mit den zugehörigen Help-Texten interaktiv generiert werden können. Der Zugang zu den Anwendermenüs wird durch Schutzmechanismen der Datenbank verwaltet, so daß sich völlig abgeschlossene, sichere
Applikationen erzeugen lassen.