Hana: Das Ganze ist mehr als die Summe der Einzelteile
Nun wird wieder vermehrt von „Warm Storage“ gesprochen (Dynamic Tiering und Native Storage Extensions). Geht also SAP den umgekehrten Weg und landet am Ende dort, wo die klassischen Datenbanken herkommen – bei Disk-Datenbanken und Memory als Cache?
Rows für OLTP Columns für OLAP
Oft hört man, dass eine Row-Storage, für ganze Sätze lesen, besser ist. Selbst Hasso Plattner hat das auf der vergangenen Sapphire-Keynote impliziert. Übliches Argument:
In einer zeilenbasierten Datenbank liegen die Daten eines Satzes beisammen. Ein eingängiges Argument, aber zu kurz gedacht. Die topologische Distanz wird außer Acht gelassen.
Dieses Argument kommt aus der Zeit der Festplatten, bei der Lesekopf plus Winkelgeschwindigkeit der rotierenden Platte die Zugriffszeit bestimmten und 4 kB große Sektoren auf einmal gelesen wurden.
Bei SSDs gibt es keine Mechanik mehr, da wird eine Adresse hingeschickt und ein 4 kB großer Sektor zurückgegeben. Die Zugriffszeit auf einen Sektor ist somit deutlich geringer, die Daten sollten aber weiterhin nahe beisammen, im selben 4-kB-Sektor, liegen.
Memory gibt stattdessen pro Zugriff nur 16 Byte zurück, dafür natürlich wesentlich schneller, und welche Speicheradresse als Nächstes angefordert wird, ist irrelevant.
Mit anderen Worten: Um 4 kB mit maximaler Geschwindigkeit zu lesen, sollten bei Festplatten und SSDs die Daten in einem Sektor liegen. Dem Memory ist es wiederum komplett egal, es werden sowieso 256 Zugriffe à 16 Byte gemacht, um 4 kB zu lesen.
Eine Row- oder Column-orientierte Speicherung ist aus dieser Betrachtung, und wenn alle Daten bereits im Memory liegen, gleich schnell. Die Speicheradresse ist eine andere, das hat aber keinen Einfluss auf die Geschwindigkeit.
Nur bei Disk-Operationen gilt die Aussage, dass eine Zeile lesen eine Row-orientierte Speicherung verlangt und OLAP-Analysen eine Column-Orientierung. Damit habe ich zwar die Begründung selbst widerlegt, die Aussage „mit genügend Memory ist auch eine normale Datenbank eine In-memory-Datenbank“ steht noch unbeantwortet im Raum.
Diese Begründung ergibt sich aus der Spaltenorientierung: In einem Datensatz stehen unterschiedlichste Informationen, Materialnummer, Text und viele Indikatoren wie Farbe, Typ, Größe usw.
Diese divergenten Informationen können sicher nicht so gut komprimiert werden wie jede Spalte für sich allein mit eher sich wiederholenden Mustern. Es wird sogar noch intelligenter vorgegangen, indem jeder Wert so einer Spalte einzeln betrachtet wird.
Beispielsweise gibt es für das Feld Größe nur die Ausprägungen M, S, L, XL, also werden vier Strings erzeugt. Der String für M sieht vielleicht so aus: 0100-0000-0000-1000; und er besagt, dass der Wert M im Satz 2 und 13 vorkommt.
So etwas kann von einem Computer sehr gut komprimiert werden und auch sehr schnell. Für andere Spalten, etwa die Materialnummer, die für jedes Material unterschiedlich ist, werden andere Methoden verwendet.
Suchen und finden
Zugriffe auf Daten erfolgen in einem ERP-System entweder nach Primärschlüssel oder über eine Suche. „zeige Sales Order 1234“ oder „suche alle Sales Items zur Sales Order 1234“.
Ersteres läuft bei beiden Typen von Datenbanken gleich ab. Eine klassische Datenbank verwendet den Index, findet dort die Adresse der Zeile und liest diesen Satz an dieser Adresse. In Hana liest man den Index, findet dort die Satznummer und holt aus jeder Spalte den Wert an dieser Position.
Bei der Suche existieren wiederum Unterschiede: Bei einer Row-Orientierung ist hoffentlich ein zweiter Index vorhanden, in dem alle Adressen der Sales-Item-Sätze stehen, die zu einer Sales Order gehören.
Andernfalls hat die Datenbank keine Chance und muss die komplette Tabelle durchforsten. Bei Hana ist eine Indexierung schon durch die Art und Weise der Speicherung gegeben. Ein immenser praktischer Vorteil.
Jeder dieser Punkte – Spaltenorientierung, Komprimierung, Indexierung und In-memory – hat für sich genommen Vor- und Nachteile. Das Alleinstellungsmerkmal von SAP Hana ist, dass diese Datenbank selbst heute noch als einzige all diese Punkte intelligent kombiniert, sodass sich die Vorteile verbinden.
Alles im Memory zu halten geht dann, wenn man komprimiert. Organisiert man die Daten in Spalten, kann besser komprimiert werden. Von Primärschlüsseln abgesehen benötigt man keine Indizes mehr, dank der spaltenweisen Organisation und der Komprimierung.
Weil alle Daten im Memory liegen, sind auch Abfragen eines kompletten Tabellensatzes gleich schnell wie bei einer Row-orientierten Speicherung, man kann also selbst für solche Abfragen eine spaltenweise Speicherung benutzen.
Dafür gewinnt man mit Hana viel für die normalen Fälle. OLAP-Abfragen à la „Summe Umsatz pro Jahr“ gehen sehr schnell, weil die Daten schon in Spalten organisiert sind.
Suchen auf jedwedem Attribut gehen sehr viel schneller, weil jede Spalte per se einen Index repräsentiert. Abfragen, die eben nicht 100 Prozent der Tabellenspalten lesen, sind schneller.
Genau hier liegt aber auch der Hund begraben: Meine komplette Betrachtung lief unter der Prämisse, dass alle Daten bereits im Speicher liegen und auch in den Speicher passen.
Ist das nicht eine Speicher- und damit Geldverschwendung, immer alles im RAM (Random Access Memory) vorzuhalten, egal ob es benötigt wird oder nicht?
SAP gibt hier dem Administrator Möglichkeiten zur Optimierung: Ein erster Punkt sind binäre Datentypen (LOB-, CLOB- und NCLOB-Datentypen). Die werden nicht im Memory abgelegt, sondern bleiben immer auf Disk.
Im Memory liegt der Pointer auf das File, aber nicht der Inhalt. Gute Idee, hilft nur nicht viel, weil solche Datentypen in einem ERP kaum vorkommen.
Erstmalige Verwendung
Nächste Optimierung: Es werden die Partitionen erst dann ins Memory geholt, wenn sie das erste Mal benutzt wurden, und nicht schon vorsorglich. Wenn also eine Tabelle aus einer Milliarde Sätze besteht, aufgeteilt in zehn Partitionen für zehn Jahre, würde nur die Partition für das aktuelle Jahr ins Memory geladen werden.
Auch eine gute Idee, reduziert die Start-up-Zeit und den initialen Speicherbedarf, aber im Laufe der Zeit wird jede Partition mindestens einmal von irgendwem benutzt worden sein. Somit ist erst recht alles irgendwann im RAM und bleibt auch dort bis zum nächsten Restart.
Dafür gibt es ein Feature: die Retention Period. Mit dieser Einstellung werden solche Partitionen nach einer eingestellten Zeit ohne jedweden Zugriff wieder aus dem RAM geschmissen. Endlich eine Einstellung, mit der Dinge aus dem RAM entfernt werden. Achtung, dieser Schalter ist bei Default auf Aus!
Das ist jetzt schon mal sehr gut, hat aber zwei Lücken. Die erste Person, die auch nur einen einzigen Datensatz benutzt, triggert das komplette Laden von dieser Partition ins Memory.
Wenn so eine Partition ein Gigabyte groß ist, kann das schon mal zwei Sekunden dauern. Und all das hilft nicht, wenn die komplette Datenbank 1,1 Terabyte RAM braucht, aber nur 1 Terabyte vorhanden ist.
Hier kommt das neueste Feature zu Hilfe, die Native Storage Extension. Damit wird nicht mehr die komplette Partition geladen, sondern nur noch die benötigten Pages, die diese Daten beinhalten.
Und wenn nicht genügend RAM vorhanden ist, werden nicht benötigte Pages wieder entfernt. Von der Art und Weise geht man hier also wirklich wie bei einer Disk-basierten, klassischen Datenbank vor und benutzt für Tabellen mit dieser Einstellung das RAM nur als Cache.
Multi-Temperature-Daten
So ist das aber nicht gedacht. Hana ist weiter eine In-memory-Computing-Datenbank, es sollen also alle (!) benutzten (!) Daten im Memory vorliegen. Nur so können OLTP- und OLAP-Abfragen von der gleichen Datenbank erledigt werden, nur so bekommt man kurze und vorhersehbare Antwortzeiten.
Diese zusätzlichen Funktionen sind einzig und allein für Multi-Temperature-Daten geeignet. Für Daten, die hin und wieder mal gebraucht werden. Für die der Benutzer nicht in eine Archiv-Datenbank geschickt werden soll.
Würde ich diese Features für alle Tabellen verwenden und zu wenig RAM zur Verfügung stellen, dann beginnen die Nachteile der spaltenorientierten Speicherung sichtbar zu werden. Ich hätte nicht mehr alle Vorteile ohne Nachteile.
Stattdessen stellt Hana den zentralen Einstiegspunkt für die verschieden temperierten Daten dar und versteckt die physikalischen Unterschiede: Der Anwender setzt seine Befehle ab, manche Daten kommen aus dem In-memory-Store, manche von Disk, andere werden über das Hana Smart Data Access Feature von einem externen System eingeblendet („Federated“). Der Anwender merkt nichts davon bis auf gegebenenfalls längere Antwortzeiten. Hana wird zu einem Data Fabric.
Es wird die Physik versteckt, sie ist aber nach wie vor vorhanden. Hana-Datenstrukturen von Memory lesen geht schneller als von Disk bei der Native Storage Extension.
Der Bruch zu Dynamic Tiering mit einer SAP-IQ-Datenbank im Hintergrund ist noch größer, weil hier keine Hana-Datenstrukturen mehr verwendet werden. Das Interface ist somit auf SQL limitiert.
Und greift der Anwender auf ein externes System über Smart Data Access zu, dann kann die Antwort nur so schnell sein, wie das externe System es ermöglicht.
