Ähnlich wie Ende der 60er Jahre und Anfang der 70er Jahre die verschiedensten Funktionen wie zum Beispiel Reportgenerator, TP-Monitorfunktionen in Datenbanksysteme "hineininterpretiert" wurden, so wird heute sehr viel Unrealistisches in Datenbankcomputer "hineingeredet". Wenn wir uns aber ansehen, wofür ein Datenbank-Computer eigentlich gebaut werden soll, wo seine Vorteile liegen, so sieht man bald, daß man die Menge der Funktionen, die er ausführen soll, doch stark reduzieren kann.
Man wird keine Spezialmaschine bauen, wenn sie keine signifikanten Vorteile gegenüber der allgemeinen Maschine (heutige Standard-CPUs mit Standardsoftware) aufweist. Die Vorteile eines DB-Computers sollen darin liegen, daß er
a) wirtschaftlicher,
b) flexibler, das heißt verwendbar für verschiedenste Zentralcomputer verschiedener Hersteller
c) ausfallsicherer
ist als bisherige Systeme, die Datenbankverwaltung ganz mit Software unter dem jeweiligen Betriebssystem des Zentralrechners durchführen.
Zu a): Sehr wichtig für die sichere und wirtschaftliche Implementierung eines DB-Systems ist der Maschinencode des DB-Computers.
Es ist nicht sinnvoll, sich hier auf Mikrocode (im heutigen Sinne) zu verlassen, da damit nahezu unüberwindliche Probleme der Wartung und Fehlerkorrektur verbunden sind (ein so komplexes System wie Datenbankverwaltung läßt sich heutzutage nicht völlig fehlerfrei implementieren). Vernünftiger ist die Verwendung eines Software-implementierungsfreundlichen Maschinencodes, um ein DB-System als Software zu implementieren.
Der IBM 360/370-Code ist für die Implementierung guter Softwaresysteme ungeeignet, da er nur sehr elementare und ungeschickte Instruktionen besitzt. (Als Beispiel: Es fehlen alle Instruktionen für Stack- und Warteschlangenverwaltung; das Erhöhen eines normalen Feldes um 1 benötigt drei Instruktionen; das Adressierungskonzept ist extrem unflexibel und elementar.)
Als Beispiel eines softwarefreundlichen Maschinencodes, der für solche Zwecke gut geeignet ist, kann man das VAX-System von DEC ansehen.
Beim Bau eines DB-Computers sollte man also durchaus auf die langjährigen Erfahrungen zurückgreifen, die mit dem Design, der Implementierung und der Unterstützung derjenigen Funktionen zusammenhängen, die in der wirklichen Welt der Anwender benötigt werden (dies ist vernehmlich die Welt der kommerziellen Anwender). Es ist besser, bewährte Teile intelligent zu einem neuen System zusammenzubauen, als immer wieder das Rad neu zu erfinden.
Zu b): Flexibilität eines DB-Computers bedeutet die Einsetzbarkeit in verschiedensten Hardware- und Anwendungs-Umgebungen. Dies bedeutet, daß sich der DB-Computer auf die Aufgabe beschränkt, die sein Name schon angibt, nämlich auf die Verwaltung einer oder mehrerer Datenbanken. Anwendungsprogramme gehören ebensowenig in einen DB-Computer wie Reportgeneratoren, End-user-Sprachen etc. DB-Computer sollten also nur eine ganz klare, einfache Schnittstelle zur Außenwelt haben, vergleichbar mit der Schnittstelle eines heutigen I/0-Controllers zur Zentraleinheit.
Ein Befehl an einen I/0-Controller ist ein Befehl zur Ausführung einer physischen I/0-Operation. Ein Befehl an einen DB-Computer kann als komfortabler, logischer I/0-Befehl angesehen werden. Intern erzeugt er null, einen oder mehrere physische I/0-Operationen, wobei der rufende Benutzer keinerlei Kenntnisse mehr über die physischen Gegebenheiten der DB hat und benötigt. Er ist von allen Vorgängen losgelöst, die mit der Strategie der Auffindung, Sicherung und Veränderung von Daten in der physischen Datenbank zu tun haben.
Ein solcher DB-Computer kann über ein kleines Software-Interface an jede sinnvolle End-user-Sprache, Reportgenerator oder große Anwendungssysteme angeschlossen werden. Dies ist wichtig, um die hohen Investitionen bei der Entwicklung dieser Systeme insbesondere in der Vergangenheit zu sichern.
Zu c): Neben den Standardmethoden auf der Hardwareseite (ausfallsichere Schaltkreislogik, mehrere CPUs, mehrere I/0-Controller etc.) kann man auf der Softwareseite vor allem im Design viel tun, um den Verfügbarkeitsgrad des DB-Computers zu maximieren. Hierzu gehört vor allem ein vollautomatischer Restart auf logischer Transaktionsebene, der in wenigen Sekunden (unabhängig davon, ob man 1 Milliarde Bytes oder 20 Milliarden Bytes verwaltet) das System wieder voll verfügbar macht, wenn einmal ein Fehler (temporärer Hardwarefehler, Stromausfall, Softwarefehler) das System zum Stillstand gebracht hat. Gerade diesen Punkt kann man gar nicht hoch genug bewerten, da ein DB-Computer ein zentrales Gerät ist, von dessen Funktionen die meisten Teile der DV einer Firma abhängen.
Zusammenfassend kann man sagen daß zukünftige DB-Computer keine wesentlichen Vorteile bringen, wenn sie als Spezialgeräte mit Spezialtechnologie gebaut werden, sondern wenn sie mit bewährter (und daher preiswerter) Technologie sich auf die Aufgabe der DB-Verwaltung beschränken. Welches sind dann die verbleibenden internen Aufgaben und Strukturen?
Ein Standrechner mit einem oder mehreren Prozessoren, der sich kümmert um - die Warteschlangen der eingehenden DB-Aufrufe,
- die gleichzeitige Ausführung verschiedenster DB-Aufrufe,
- die Verwendung des Standard I/0 über die vorhandenen Controller zur Abwicklung physischer I/0-Operationen.
Wir können davon ausgehen, daß während der nächsten 4 bis 8 Jahre die relativ langsamen mechanischen Massenspeicher noch eine dominierende Rolle spielen werden. Auf der anderen Seite werden im Laufe der Zeit neue Speichertypen in der Geschwindigkeitshierarchie entwickelt, so daß man auch deren Eigenschaften nutzen kann.
In der Geschwindigkeits- (und daher aus Preis-)hierarchie
- mechanische Plattenspeicher (Zugriff im Millisekundenbereich),
- nichtmechanische Speicher (bubble memory etc.) (Zugriff im Mikrosekundenbereich),
- Arbeitsspeicher (Zugriff im Nanosekundenbereich) bietet es sich daher an, die Software und die zur Zeit häufig verwendeten Teile der DB (Bufferpool) im Arbeitsspeicher, die Verwaltungstabellen der DB (Dictionary, inverted lists etc.) in nichtmechaniche Speicher und die eigentlichen Daten (das Gros des Speicherbedarfs) auf mechanischem Speicher zu halten.
Eine Grundforderung ergibt sich also hier für die Zukunft, um kommende neue Hardwarekomponenten leicht einbauen zu können: Trennung von Daten und Verwaltungsinformation, ein wichtiges Prinzip, dem bisher nur wenige der bekannten DB-Systeme genügen.
Das Betriebssystem des DB-Rechners ist sehr elementar, da es sich nicht um die Balance verschiedener Regions (und den Prozessen darin) kümmern muß sondern ganz auf DB-Verwaltung ausgerichtet sein kann. Dies bringt einen extrem kleinen Aufwand für BS-Verwaltung und hohe Flexibilität zur Nutzung der gegebenen Hardware. (Überlappung aller möglichen I/0s; Datenverwaltungslogik für verschiedene DB-Aufrufe in verschiedenen Prozessoren als parallele Prozesse.)
Durch den starken Preisverfall auf dem Schaltkreissektor läßt sich mit einem solchen Multiprozessorkonzept ein DB-Computer erstellen, der 50 bis 100 Transaktionen pro Sekunde verarbeitet und gleichzeitig erheblich preiswerter ist als eine einfache heutige CPU.
Der Sinn eines DB-Computers für den Anwender sollte nicht darin bestehen, viel teure Hardware durch noch mehr Hardware zu ergänzen, sondern den Wald der unüberschaubaren Funktionen zu lichten, die heute gleichzeitig (also sich gegenseitig behindernd) in dem zentralen Rechner ablaufen. Das neue Stichwort heißt also Rationalisierung innerhalb der Datenverarbeitung.
*Peter Schnell ist Vorstandsvorsitzender der Software AG, Darmstadt