Hana 3, was sonst?

Dass Hana nicht für die Cloud gebaut wurde, ist bekannt. Doch was ist das Problem dabei? Da trifft der E-3 Artikel „Wir sind ERP“ von Autor „no/name“ aus E-3 Februar 2020 den Nagel auf den Kopf: die Betriebskosten von Hana as a Service für SAP selbst.

Eine Datenbank, die sich automatisch an die Last anpasst, wäre die optimale Lösung. Damit könnte man die Betriebskosten zu 100 Prozent im optimalen Bereich halten und keine Ressourcen verschwenden.

Der Wunsch nach unendlicher Skalierbarkeit ist naheliegend und nachvollziehbar. Ist er machbar, das ist die andere Seite der Medaille. Eine Anekdote von SAP: „Wir brauchen disruptive Lösungen, also entwickelt diese.

Los, los!“ Man soll also etwas noch nie Dagewesenes auf Zuruf erfinden, schnell umsetzen und physikalische Gesetze so nebenbei verschieben. Das ist schwierig, oder?

Bei Hana 3 berührt man genau so eine physikalische Grenze. Für die geforderte unendliche Skalierung müssen die Aufgaben (a) in unendlich kleine Teile zerlegbar sein, (b) parallel ausgeführt werden und – damit es weiterhin eine Datenbank ist – (c) trotzdem eine globale Reihenfolge/Transaktionalität beibehalten. Das geht nicht. Der innere Widerspruch der Anforderungen muss über einen Kompromiss an mindestens einer Stelle aufgelöst werden.

Aufwand und Ziel

Wenn die unendliche Skalierung aber nur eine Methode ist, wie man die Kosten reduzieren kann, gibt es vielleicht eine billigere Art und Weise? Das wurde schon einmal versucht, die Hana-Admins kennen das als Multi-Database-Container (MDC).

Dabei wurde der Indexserver als das Problem ausgemacht, der Prozess, der sich um alle Datenverarbeitungen und die Datenspeicherung in Hana kümmert.

Im Cloud-Rechenzentrum benötigt jede Hana einen dieser großen Indexserver-Prozesse. Wie wäre es also, nur eine Hana-In­stanz pro Server zu installieren und dafür unabhängige Datenbank-Container zu haben?

Die Entwicklung hat also alles aus dem Indexserver entfernt, das nicht zu einer Datenbank gehört, und in den Name-Server verlagert: Die Datenhaltung? Nein, geht nicht, das ist der Kern der Datenbank.

Die Abfragen? Das Session Management? Im Endeffekt war nichts entfernbar. Ergebnis: Auf jedem Rechner laufen die SystemDB plus ein Indexserver pro Datenbank-Con­tainer. Einsparung? Praktisch null.

Der Indexserver

Wie könnte man stattdessen den Indexserver kleiner bekommen? Im Moment ist er bei einer leeren Datenbank 4 GB groß.

Er hat eine SQL-Engine, eine Calc-Engine, Spatial Queries, Time Series und Graph Queries, Document Store. Die billige Methode wäre, Teile der Funktionalitäten zu entfernen.

Einer der Vorteile von Hana ist aber gerade die Universalität. Das steht zu Recht auf jeder Marketingfolie. Man müsste den Indexserver also irgendwie anders zerschneiden, naheliegend in eine kleine Kernfunktionalität und eine dynamische, lastabhängige Komponente.

Eine der Kernaussagen von Hasso Plattner vor zehn Jahren war, dass ein Datensatz einmal angelegt wird und Hunderte Male abgefragt wird. Daraus folgerte Plattner, dass eine Datenbank eher auf Abfragegeschwindigkeit optimiert werden sollte und Insert-Performance zweit­rangig ist.

Die komplette Hana-Datenbank sowie S/4 Hana sind rund um diese Prämisse aufgebaut und deswegen so erfolgreich.

Für unseren Indexserver bedeutet es, man schmeißt allen Code heraus, der sich um die Abfrage von Daten kümmert. Wirklich alles! Die Verantwortlichkeit des Indexservers reduziert sich damit auf die Datenverwaltung und die Durchführung der Datenänderungen.

Der Prozess besitzt also das RAM mit den Daten, er behandelt die Insert-, Update- und Delete-State­ments. Der Indexserver wäre nur noch die In-memory-Storage-Ebene.

Queries sind der komplexe Teil mit dem Query Optimizer, den verschiedenen En­gines und der hohen Gefahr, einen Bug zu haben. Diesen Funktionen genügt Read- only-Zugriff auf das RAM des Indexservers (Shared Memory) und sie können vollkommen unabhängig voneinander arbeiten.

Ein weiterer Vorteil dieses Ansatzes: Was passiert heute, wenn ein Anwender ein Query absetzt und wegen eines Bugs läuft der Code Amok? Der Indexserver stürzt ab und damit die komplette Datenbank.

Wenn das Query ein eigener Prozess ist, vielleicht sogar jedes aktuell laufende Query in einem eigenen Prozess laufen würde, bricht nur die eine User Session zusammen.

Diesen Query-Prozess gut zu gestalten ist allerdings nicht einfach.

Conteneur

Wie würde das praktisch aussehen? Jeder Kunde besitzt ein Docker Image mit Hana. Dieses Image wird auf einem Server mit den gekauften Leistungsdaten gestartet. Da der Indexserver jetzt so klein ist, kann er sehr schnell gestartet werden, so schnell, dass die meisten Entwicklerinstanzen sogar in einen Ruhezustand gehen können und das Docker Image bei Inaktivität gestoppt wird.

Benötigt ein Kunde mehr Ressourcen, wird seine Hana-Instanz gestoppt und auf der anderen Hardware wieder hochgefahren. Oder man geht in Richtung Scale-out, startet mehrere Docker-Instanzen auf den gleichen Datenbank-Files und diese verteilen die Daten untereinander.

Wo ein Container läuft, im Cloud-Rechenzentrum oder beim Kunden, macht keinen Unterschied.

Was ich bis jetzt beschrieben habe, ist Allgemeinwissen aus dem Datenbankbau. Es wird spannend zu sehen, welchen technischen Unterbau Hana Cloud bekommt.