Technologie der ODBMS

Um die Performance eines ODBMS zu steigern, gibt es viele Stellschrauben. Eine davon ist es, die Zugriffe auf die Datenbank zu beschleunigen, was durch schnellere Disk-Zugriffe bis hin zur In-Memory-Technologie möglich wird, aber auch durch bessere Zugriffsalgorithmen und schnellere Übertragung zwischen dem Datenbankserver und dem anfragenden Client. Ausgangspunkt für unsere Betrachtung ist die bekannte klassische nach dem Entity Relationship Model (ERM) funktionierende Datenbank. Zur Erinnerung: eine Datenbank ist relational, wenn sämtliche Datenobjekte ohne Redundanz abgespeichert werden. Das ist zwar in der Theorie sehr sinnvoll, in der Praxis gibt es kaum eine SQL Anwendung, die sich an die Regel hält. Aus Gründen der Performance werden oft wichtige Information in nachgeordneten Tabellen wiederholt.

Nehmen wir als Beispiel eine Bestellung. Eine solche besteht in einem RDBMS aus zwei grundsätzlichen Komponenten: einem Bestellkopf und den Bestellpositionen.

Um sich aber in der Anwendung das Lesen von zwei Tabellen zu sparen, werden gerne Kopfinformationen in die Positionen repliziert:

Dieses Abweichen vom streng relationalen Dogma liegt komplett in der Verantwortung des Entwicklers einer Anwendung und ist - vorsichtig ausgedrückt - selten sinnvoll. Da die Daten in einem modernen DBMS keineswegs Tabelle für Tabelle und Zeile für Zeile abgespeichert werden, kann diese Art des Umgangs mit Datenbanken manchmal die Performance der Anwendung sogar bremsen. Wenn jede Anwendung seine Daten erst in den Hauptspeicher kopiert oder Daten redundant ablegt, macht sich der Entwickler nicht nur das Leben selber schwer, auch die Gesamtperformance der kompletten Installation leidet darunter, dass Speicher unvorhersehbar und extensiv missbraucht wird, anstatt dem DBMS sauber die Aufbereitung der Daten zu überlassen.

Ein ODBMS erzeugt eine zusätzliche Schicht zur Datenbank und versucht dadurch, dem Entwickler einer Anwendung ein Werkzeug an die Hand zu geben, Daten nur noch als logische Objekte anzusprechen. Bauen wir das Beispiel mit der Bestellung von gerade eben in die OO-Denkweise um: Anstatt zunächst den Kopf einer Bestellung aus der Kopftabelle ("select * from ORDER_HEADER where ORDERNO = 123..") zu lesen und danach die Positions-Daten aus der Positionstabelle ("select * from ORDER_ITEMS where ORDERNO = ORDER_HEADER-ORDERNO ..") einzusammeln, lässt sich die Anwendung immer das komplette Objekt, auch Entität genannt, zurückgeben: get ORDER with key = 123.

Auf diese Weise schaffen ODBMS die Möglichkeit, Daten als komplette Objekte zu sehen, ohne dass sich Anwender um die physikalische Anordnung der Daten kümmern müssen. Das ist schon deshalb wünschenswert, weil Entwickler gar nicht wissen können und sollen, wie die Daten wirklich in der Datenbank abgelegt sind. Ob die Daten des Objekts nun komplett in den Speicher geladen werden, oder erst beim ersten Zugriff, liegt damit in der Entscheidungsgewalt der ODBMS.

Programmierlogik von der Datenbank entkoppeln

Eine solche Entkopplung der Programmierlogik von der Datenbank wird in Zukunft immer bedeutsamer: Bei Cloud-Datenbanken liegen eventuell die Schlüsselfelder einer Tabelle auf einem ganz anderen Server als die Daten. Das ist eine mögliche Strategie um den Gesamtdurchsatz der Datenbank zu optimieren. Um diese Strategie nicht dem Zufall zu überlassen, verwenden DBMS dazu sogenannte Optimizer, die anhand von Berechnungen aus einer großen Anzahl von Strategien diejenige auswählen, die in der Praxis die beste Performance verspricht und dadurch die durchschnittliche Zugriffszeit optimiert.

ODBMS werden auch als Objekt-Datenbanken oder OLTP (für: Online Transaction Processing) bezeichnet. Die Begriffe sind weitgehend gleich und stammen aus unterschiedlichen Philosophien. So geht der Begriff Objekt-Datenbank davon aus, dass die Datenbank auch nur eine Sammlung von Objekten darstellt, die genauso angesprochen werden wie Programmierobjekte innerhalb einer objektorientierten Programmiersprache. Der Begriff OLTP wird heute als Online Transaction Processing bezeichnet und hieß ursprünglich Object-Layer Transaction Processing, war also ein Synonym zu Objekt-Datenbank. Wer auch immer die Langform "Online" ins Spiel brachte, wollte damit vor allem das Ziel deutlich machen, Zugriffe auf Ergebnisse in Echtzeit zu erzielen. Allerdings sagt die Begrifflichkeit "Echtzeit" ohnehin nicht viel aus, da eigentlich bei jeder Verarbeitung eine Echtzeitverarbeitung angestrebt wird, das gilt genauso auch für klassische SQL-Datenbanken.

In der Praxis ist die Unterscheidung zwischen Non-SQL- und SQL-Datenbanken eher theoretischer Natur. Tatsächlich sind fast alle hoch-performanten SQL-Datenbanken in ihrem Inneren nicht relational mit getrennten Tabellen implementiert. Der Unterschied liegt vielmehr in der Art und Weise, wie auf die Daten tatsächlich zugegriffen wird. Umgekehrt wird damit aber auch deutlich, dass die heutige, vor allem als SQL-Datenbank eingesetzte Software, fast ausnahmslos auch in der Liga der ODBMS mitspielen kann.

Funktionsweise von Datenbanken für Client-Server Anwendungen

Jedes DBMS ist selbst nach einem Client-Server-Modell aufgebaut. Dieses Modell besteht aus mehreren funktionalen Ebenen, entsprechend dem Aufbau jedes modernen Betriebssystems. Jeder der Layer kommuniziert dabei jeweils ausschliesslich mit seinem benachbarten Peer-Layer. Das sind die wesentlichen Kommunikations-Schichten einer DBMS:

Real Time OS: Grundlage der Technologie ist ein Real-Time Betriebssystem wie Windows, Unix, zOS und zunehmend auch virtuelle Cloud Betriebssysteme usw.

Physical Translation Layer (API): Die API dient dazu, dass die darüber liegende Schicht keine Kenntnis zum tatsächlichen Betriebssystem haben muss. Es wird ein virtuelles Betriebssystem emuliert.

Physical Storage Layer: Diese Ebene entscheidet, welche Speichermethode verwendet wird. Auf dieser Ebene finden sich auch die Optimierungs-Algorithmen.

Cluster (Multi-Server) Arbitration Layer: Die Multi-Server Arbitration sorgt dafür, dass auch bei verteilten Systemen die Datenkonsistenz bewahrt wird.

Transaction Management Layer (Concurrency): Auf dieser Ebene werden die konkurrierenden Zugriffe von verschiedenen Clients auf dieselben Entitäten gesteuert und sichergestellt, dass nur konsistente Daten bereit gestellt werden.

Object Access Layer: Der Object Layer stellt die Abfragesprache beziehungsweise API und das Zugriffsmodell bereit, mit der eine Anwendung auf die Daten zugreifen kann. Hier wird zwischen SQL, OLTP, OLAP und den zahlreichen anderen Zugriffen eines ODBMS unterschieden.

Für die nähere Betrachtung mit Blick auf den modernen Nutzen als ODBMS interessieren uns vor allem die Storage Engine und der Object Access Layer:

• Storage Engine - auch Persistenz-Layer genannt, ist die Komponente, die für die physikalische Speicherung von Daten zuständig ist.

• Hinter dem Object Access Layer verbirgt sich die Query Language: Diese Komponente übersetzt Anfragen in entsprechende Befehle für die Storage Engine zum Lesen und Schreiben von Daten.