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

Unter Begriff ODBMS - Operational Database Management Systems lässt sich ein bunter Strauss an sehr unterschiedlich konzipierten Datenbanksystemen zusammenfassen. Gemeinsam ist ihnen, dass sie Daten nicht als sequentielle Datei beziehungsweise nach einem Entity-Relationship-Modell (ERM) ansprechen. Durch die explosionsartige Vermehrung an neuen Datenauswertungs-Szenarien - vereinfachend als Big Data bezeichnet - sind Zugriffe mit SQL auf Datenbestände für viele Anwendungen nicht mehr zeitgemäß. Für die derzeit besonders vielversprechenden Anwendungen, wie sie in den Bereichen "Predictive Analysis" (Prognosen auf Basis großer Datenmengen), Video- und Data-Streaming, SmartCity, Connected Cars oder Industrie 4.0 zu finden sind, benötigen Anwender künftig jeweils maßgeschneiderte Zugriffswege auf die Daten.

ODBMS werden daher künftig die Schlüsselrolle für viele Enterprise-Anwendungen spielen. Urvater der ODBMS ist "MUMPS", eine Programmiersprache mit integrierter Datenbank, welche gezielt für das Bearbeiten von strukturfreien Datenbanken wie große Textdokumente geschaffen wurde, was in den 1960ger Jahren die visionäre Herausforderung am Massachusetts Institute of Technology (MIT) war. Aus dieser Forschung ging dann das spätere "Interbase Caché" hervor, auch heute noch eine der führenden und visionären post-relationalen Datenbanksysteme.

ODBMS - die nächste Datenbankgeneration

Ein ODBMS ist keine Alternative zu relationalen Datenbank-Management-Systemen (RDBMS), sondern die nächste Generation. Auch eine klassische SQL-Datenbank nach dem Entity Relationship Model lässt sich damit jederzeit modellieren, indem man jede Tabelle schlicht als ein Objekt anlegt und betrachtet. Charakterisierend für ODBMS ist, dass solche Datenbanken zusätzlich zu den atomaren Informationen auch Aggregationen (zusammenfassende Zwischenergebnisse) und strukturfreie Information abspeichern, wie sie bei Texten häufig vorkommen oder für flexible Auswertungen, also dem klassischen Data-Mining auf einem Business-Warehouse benötigt werden.

Manche ODBMS entscheiden sogar in Verfahren nach dem Muster der Künstlichen Intelligenz selbst, welche Daten überhaupt abgespeichert werden. Der alternative Begriff einer "Post-relationalen Datenbank" beschreibt die Realitäten besser: Das sind Datenbanken, die sich nicht mehr an den technischen Begrenzungen orientieren, sondern an den visionären Zielen der Anwendungsentwicklung.

Anwendungen für ODBMS

Für Anwender stellt sich nun die Frage, welche ODBMS für das eigene Einsatzszenario die beste ist. Das ist allerdings nicht einfach zu beantworten. Für RDBMS gibt es noch gute und hinreichend sinnvolle Vergleichsparameter, weil diese zumindest funktional sehr ähnlich zueinander sind: Allerdings geht es dabei meist nur um einfache Performance-Messungen beim Zugriff auf kleine oder große Tabellen, den Aufbau von JOINs oder das Ausführen von vordefinierten Kalkulationen sowie das Verhalten bei technischen Störungen, wie einem Netzwerkausfall oder Fehlern bei Speichermedien.

ODBMS sind jedoch so verschieden und oft derart auf bestimmte Anwendungen spezialisiert, dass sie kaum mehr unmittelbar miteinander zu vergleichen sind. Im Markt gibt es einen solch weit gespannten Reigen an Anwendungen, dass es künftig nicht mehr die eine "beste" Datenbank geben wird, sondern eine große Anzahl an verschiedenen Lösungen, die jeweils in ihrer eigenen Anwendungsnische glänzen können.

Predictive Analysis (Big Data für Ultra-Large-Systems): Hier geht es um die klassische Herausforderung im Bereich Big Data. Das ist der Sektor, den primär auch SAP mit seinem In-Memory-System HANA umwirbt. Wir sprechen hier auch oft von Ultra-Large-Systems als Bezeichnung für das Zusammenspiel von einer unkontrollierbar großen und gewöhnlich nicht vorhersehbaren hohen Anzahl an Computersystemen und Software-Agenten. Ziel ist, aus einer riesigen sich ständig ändernden Datenmenge Erkenntnisse zu gewinnen und so künftige Entwicklungen vorherzusagen.

Financial Storm Prediction: Eine momentan sehr gefragte Anwendung sind Systeme zur Analyse von "Financial Storms", also das Vorhersagen von plötzlich und heftig auftretenden ("sturmartig") Veränderungen am Finanzmarkt wie beispielsweise Börsen-Crashs und Bankenpleiten wie im Falle Lehmann Brothers. Das funktioniert ähnlich wie die Wettervorhersage und - kein Wunder - die Algorithmen sind verwandt.

Financial Fraud Analysis: Ebenfalls im Finanzsektor sehr beliebt sind Systeme, die alle Banktransaktionen online analysieren und Erkenntnisse gewinnen wollen, ob kriminelle Aktivitäten stattfinden.

Data Streaming: Beim Data Streaming geht es um das Bereitstellen großer Datenmengen an eine Vielzahl von Clients, die aber allesamt gewöhnlich zeitversetzt zueinander darauf zugreifen. Klassiker ist hier das Videostreaming beim Zugriff auf Videotheken.

Industrie 4.0, Smart City und Connected Cars: Hier geht es darum, einen permanent dahin rauschenden Informationsfluss bereits frühzeitig nach brauchbaren und unbrauchbaren Daten auszusortieren. Es gilt, Daten zu analysieren bevor diese überhaupt abgespeichert werden - der Klassiker einer In-Memory Anwendung. Tatsächlich ist dies das Spielfeld von Enterprise Service Bus Software und Message-Queuing Systemen wie zum Beispiel IBM Websphere MQ, Oracle OSB, Software AG Webmethods, Fiorano ESB, MULE oder Talend.

Industrie 4.0: Industrie 4.0 ist letztlich eine Kombination von Data Streaming und Predictive Analysis. Einerseits liefern Produktionsmaschinen laufend neue Informationen. Diese müssen aber zunächst ausgedünnt werden, um überhaupt eine vernünftige Analyse zu ermöglichen. Smart City, Connected Cars sind verwandte Anwendungen, die weitgehend die gleiche Herausforderung darstellen.

Smart Coast Guard: Eine sehr anschauliche Anwendung demonstriert die US-Küstenwache. Dort werden die Funkpositionssignale eingesammelt, die jedes Schiff, das sich in den Hoheitsgewässern der USA aufhält mindestens alle fünf Minuten aussenden muss. Bei mehreren Zehntausend Schiffen im Durchschnitt kommen wir hier leicht auf 100 Positionssignalen pro Sekunde.

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.

Austauschbare Storage Engine ist das Herz einer Datenbank

Die Storage-Engine ist das Herzstück jedes DBMS und in aller Regel austauschbar. Bei der Open-Source Datenbank MariaDB (alias MySQL) zum Beispiel können Anwender standardmäßig zwischen Varianten einer Speicher-Engine wählen, zum Beispiel für Speicherung nach dem ERM (InnoDB, XtraDB), transaktionsfreie Speicherung wie MyISAM oder CSV, einer In-Memory-Option (MEMORY alias HEAP) sowie einer Option für verteilte Datenspeicherung über mehrere Server (CLUSTER) - und das sind noch längst nicht alle Möglichkeiten.

File-System Storage Engine: Eine File-System Storage Engine speichert Daten in einzelnen Betriebssystem-Dateien ab und greift grundsätzlich durch das Betriebssystem auf die Daten zu. Typischerweise sind die Daten einer Tabelle einer relationalen Datenbank pro Datei abgespeichert, und innerhalb der Datei werden Daten zeilenweise abgelegt. Typischer Vertreter ist das klassische dBase. Um Daten zwischen Tabellen zu verknüpfen, ist es erforderlich, mehrere Dateien zu öffnen und diese auch sequentiell zu durchsuchen. Das macht diese Methode wenig effizient.

File Storage Engine: Um diese Einschränkungen des File-Systems zu umgehen, werden üblicherweise die Daten in einer eigenen großen Datei abgelegt. Die Verwaltung der Daten innerhalb der Datei übernimmt das DBMS selbst. Dadurch müssen Daten auch nicht mehr Tabelle für Tabelle und innerhalb der Tabellen zeilenweis abgelegt werden.

Spaltenweises Abspeichern: Eine alternative Speichermethode ist das spaltenweise Speichern der Daten. Üblicherweise werden Datensätze nur nach einer Spalte durchsucht. Wenn nun die Felder einer Spalte nacheinander liegen, kann man die ganze Spalte als einen Block in den Hauptspeicher laden und durchsuchen, was sehr viel schneller geht und eine Art In-Memory Effekt darstellt. Scheinbarer Nachteil ist zunächst, das die Daten wieder in die ursprüngliche Form arrangiert werden müssen. Der Nachteil ist nur scheinbar, denn tatsächlich muss eine Datenbank die Daten ohnehin in ein Ausgabeformat aufbereiten. Da die Daten aber aus dem Hauptspeicher geholt werden, spielt es kaum eine Rolle, dass die Daten nicht reihenweise abgelegt sind.

Hash-Verfahren: Eine weitere Optimierung wird erzielt, indem man die Werte einer Datenbank nicht unmittelbar abgelegt, sondern die Werte einer Tabelle auflistet und durchnummeriert. Dadurch verhindert man, dass Datenwerte mehrfach gespeichert werden müssen. Das spart Speicherplatz und das Suchen außerhalb von Schlüsselfeldern funktioniert erheblich schneller. Das Verfahren nennt man HASH.

In-Memory: In-Memory, auch HEAP genannt, ist ein Verfahren, welches zur Lagerung von temporären, unkritischen Daten dient. Üblicherweise nutzt man dies zum Zwischenspeichern von Teilergebnissen, die zum Ende einer kompletten Transaktion nicht mehr benötigt werden. Durch die zunehmende Popularität von Solid-State-Disks (SSD) ist dieses Verfahren nicht mehr zeitgemäß. Fast alle DBMS bieten eine solche Storage Engine an. Besonders populär waren diese aber selten und fristeten deshalb eher ein Nischendasein Erst durch SAPs HANA erlangte das Thema wieder mehr Popularität.

Cluster: Cluster-Storage-Engines speichern Daten nicht in einer einzigen Datei auf einem einzigen Datenträger ab, sondern in verteilten Landschaften. Die bekannten Tablespaces sind bereits ein Ansatz in diese Richtung. Jedoch reicht das Clustern weiter: Ähnlich wie RAID-Systeme lassen sich die Daten auch redundant auf verschiedenen Systemen ablegen. Durch aktive Synchronisation können so Daten auf einem lokalen, schnellen Medium abgelegt werden, zum Beispiel einer RAM-Disk oder besser SSD, und werden dann in sogenannten "Totzeiten" der CPU auf den endgültigen Speicherplatz verschoben. Cluster-Storage-Engines decken übrigens die Vorteile von In-Memory ab und sind diesen meist überlegen, wenn es um das Thema Geschwindigkeitsoptimierung geht.

Graphen-basierte Speichertechnologie

Einen anderen Ansatz verfolgen die Graphen-basierten Speichermethoden. Grundidee dabei ist, dass Daten als Assoziationen in Form von miteinander durch Listen verbundenen Knoten abgelegt werden, ähnlich wie es der vereinfachten Vorstellung von der Funktionsweise des Gehirns von Säugetieren entspricht. Wir kennen das Konzept von der Programmiersprache LISP. Der Ursprung liegt genau wie das Konzept der Objektorientierung mit Smalltalk und SIMULA in den 1960ger Jahren. Ein Beispiel:

• Das Material 4711 heißt "Kölnisch Wasser"

• Die Flasche 4711 wiegt 2 kg.

• Kunde "MAIER" kaufte an folgenden Tagen das Material 4711: 2015.06.01 - 12ST, 2015.08.15 - 23ST

Das Potential der Graphen-Technologie ist enorm, vor allem weil die Möglichkeiten weit größer sind, als die anderer Speichertechnologien. Aber wie schon bei LISP wird eine Verbreitung wegen mangelnder Ausbildung der Informatiker behindert. Graphen erfordern ein tieferes mathematisches Verständnis, welches in der Informatik meist wenig gefördert wird. Es gibt verschiedene Varianten der Graphen-basierten Methode: Die am weitesten fortgeschrittene darunter ist RDF, auch Triple Store genannt, welche Teil der Spezifikationen des WWW-Konsortium ist und als primäres Ziel das Speichern unstrukturierter Daten verfolgt.

Fazit: So gut ist SAP HANA

Es wäre unfair den zahlreichen Konkurrenten mit ihren hervorragenden Datenbanklösungen gegenüber, alles an HANA zu messen. SAP gebührt aber der Verdienst, das wichtige Zukunftsthema richtig in die Köpfe der Entscheider gebracht zu haben. Technologisch gesehen ist HANA durchaus ein Produkt mit einer frühen Marktreife. Mit dem Marketing-Fokus auf den in der Praxis vollkommen irrelevanten Aspekt des In-Memory-Computings lenkt SAP allerdings von der wesentlichen Bedeutung und Leistung ab: nämlich als Analyse- und Prognose-Software.

Durch das mit HANA verwandte APO konnte SAP bereits zeigen, Anwendungen in der Prognostik mit nennenswerter Qualität liefern zu können. Das schaffen aber auch die anderen Mitspieler im ODBMS-Markt, von denen es mittlerweile hunderte für alle möglichen Spezialanwendungen gibt, darunter auch die bekannten universellen Player wie zum Beispiel IBM mit DB2 und Cognos, SAS, Oracle, Microsoft, Caché und viele andere - wobei man auch die Open-Source-Lösungen wie MariaDB, PostgreSQL nicht aus den Augen verlieren sollte.

Künftig sind vor allem Lösungen gefragt. Die Technologie darunter werden die Entwickler der jeweiligen Lösungen bestimmen. Es braucht Apps, nicht Betriebssysteme. Für die Anwender bedeutet dies, sich nicht auf die Technologie zu konzentrieren und an einen Hersteller zu binden, sondern Wege zu entwickeln, um den Mehrwert einer Lösung zu ermitteln und die beste Lösung aus einem Reigen verschiedener Angebote zu finden. HANA wird dabei sicher eine Rolle spielen, aber als eine Option unter vielen Möglichkeiten.

Die Informatik der Zukunft wird einer Großstadt ähneln, wo es um Vielfalt geht und ein möglichst harmonisches Zusammenspiel. In zehn Jahren werden wir nicht einzelne Gewinner sehen, sondern eine Auswahl passender Anbieter für bestimmte Anwendungsbereiche. HANA wird schon allein durch seine Marktmacht ihre Position finden, genauso wie die anderen Giganten IBM, Microsoft oder SAS. Aber der Markt wird bunt bleiben, denn in der Informatik der Zukunft ist für eine One-Vendor-Politik kein Platz mehr.