SAP HANA - weniger In-Memory-, mehr operationale Datenbank

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.