SAP HANA Datenbank

SAP HANA Datenbank

Mit der SAP HANA Datenbank hat sich SAP das Thema Performance auf die Fahnen geschrieben. Das ist sehr zu begrüßen, denn tatsächlich war die lange Laufzeit immer wieder ein Ärgernis bei der Anwendung der Software. Es war nicht unüblich, dass man für komplexere Aufgaben oder Berichte minutenlang warten musste.

Die SAP HANA Datenbank erreicht durch Konzepte wie das In-Memory-Computing und das spaltenorientierte Speichern von Datenbanktabellen eine sehr gute Performance. Die SAP-NetWeaver-ABAP-Plattform wurde entsprechend erweitert, um dieses Potential besser auszunutzen. Zu diesen Erweiterungen gehören z. B. das AMDP Framework, das einen direkten Aufruf von SQLScript-Prozeduren aus dem ABAP-Code heraus ermöglicht, und die Core Data Services (CDS), mit denen jetzt auch komplexe Views auf dem NetWeaver System modelliert werden können.

Darüber hinaus wurde Open SQL, ein elementarer Bestandteil der Sprache ABAP, um einige wichtige Features erweitert. Mit diesen Mitteln wurden die klassischen SAP-Anwendungen auch gezielt für SAP HANA optimiert. Mit SAP S/4HANA und SAP BW/4HANA sind zwei Varianten des ERP-Systems und des SAP Business Warehouses (BW) entstanden, die speziell für die Verwendung auf SAP HANA angepasst wurden.

Artikel zur SAP HANA Datenbank in unserem Experten Blog

Cloud System nicht mehr verfügbar

HANA Express Images in der Cloud gelöscht

Die SAP hat sich leider dazu entschlossen, ihre VM-Images der kostenlosen HANA Express , die bislang in der Cloud bei den Hyperscalern verfügbar waren, nicht…

Cheat Sheet – Die SQLScript Übersicht

Die Cheat Sheet ist eine große SQLScript Übersicht über die wichtigsten Grundlagen. Alles an einem Platz, mit Links zu der Referenzdokumentation.

Warum sind skalare UDFs so langsam?

Beim Laden von Daten aus Quellsystemen gibt es im SAP BW Anforderungen, die sich auf Feldebene häufig wiederholen. Dazu gehören vor allem Logiken zum Bereinigen…

Was ist SAP HANA?

SAP HANA ist eine Datenbank und eine Plattform für die Anwendungsentwicklung. Darin sind viele praktische Werkzeuge enthalten, um alle möglichen Anwendungsfälle abzubilden. Diese unterschiedlichen Aspekte möchte ich im Folgenden betrachten.

SAP HANA – eine schnelle SQL Datenbank

Der Begriff HANA stand ursprünglich für High Performance Analytic Appliance. Dabei handelte es sich um eine spaltenorientierte relationale Datenbank, die mit In-Memory-Technologie arbeitet. Die wichtigsten Techniken, die zu einer guten Performance beitragen, werde ich im Folgenden kurz beschreiben.

Column Store – Spaltenbasiertes Speichern

In SAP HANA sind die meisten Daten im sogenannten Column Store abgelegt. Das bedeutet, dass die Daten einer Spalte jeweils gemeinsam abgelegt sind. In Abbildung 2 sehen Sie ein Beispiel, wie die Daten aus Abbildung 1 spaltenweise gespeichert werden.

Abbildung 1: Tabelle mit Beispieldaten

Spaltenweise Speicherung in der SAP HANA Datenbank
Abbildung 2: Spaltenweise Speicherung der Daten aus dem obigen Beispiel

Viele Operationen lassen sich in einzelnen Spalten wesentlich schneller ausführen als in einer ganzen Tabelle. Beispielsweise benötigen Aggregatfunktionen jeweils nur die Daten einer einzelnen Spalte. Ein weiterer Vorteil der Spaltenorientierung ist, dass jede Spalte als Index fungieren kann. Bei der Selektion auf Spaltenwerte muss nicht jeweils die gesamte Tabelle durchsucht werden, sondern nur diese eine Spalte. Auch der Speicherverbrauch ist bei der spaltenorientierten Speicherung erheblich geringer, da eine effiziente Kompression für die einzelnen Spalten stattfindet.

Wegen dieser Vorteile empfiehlt SAP für praktisch alle Anwendungsfälle, die Tabellen im Column Store abzulegen. Weitere Informationen zu den Speicherarten Column Store und Row Store finden Sie im SAP-Hinweis 2222277 mit dem Titel FAQ: SAP HANA Column Store and Row Store.

In-Memory

Dass eine Datenbank schneller ist, wenn die Daten nicht erst von der Festplatte gelesen werden müssen, ist selbstverständlich. Ein Hauptspeicherzugriff ist im Vergleich zum Lesen einer SSD-Platte ca. 30- bis 40-mal schneller. Falls die Daten sogar im CPU-Cache liegen, ist dieser Faktor noch ca. 10‐mal höher.

Nachteil der In-Memory-Technik

Die In-Memory Technik hat aber zwei gravierende Nachteile:

  • Die Kosten für Hauptspeicher sind erheblich höher als für Festplattenspeicher. Dieses Problem wird einerseits durch die laufend sinkenden Hardwarepreise abgemildert, zum anderen reduziert die Kompression (siehe folgender Abschnitt) der Daten den Bedarf an Hauptspeichern.
  • Im Falle eines Stromausfalls oder Hardwaredefekts sind die Daten umgehend aus dem Speicher gelöscht. Da die Daten, im Gegensatz zu den In-Memory-Ansätzen anderer Datenbankhersteller, nicht parallel auf Festplatte gespeichert werden, ist ein anderes Konzept notwendig. SAP setzt dabei auf eine Kombination aus Savepoints, die den Inhalt des Hauptspeichers regelmäßig auf die Festplatte schreiben, und dem Transaktionslog, das für alle ändernden Datenbankzugriffe geschrieben wird. Im Falle eines Neustarts der Datenbank wird der letzte Savepoint geladen, und die Änderungen danach werden aus dem Transaktionslog nachgefahren. Somit können jederzeit die Persistenz und die Konsistenz der Daten sichergestellt werden.

Durch die In-Memory-Technik können nicht nur Leseoperationen schneller durchgeführt werden, weil die Daten nicht erst in den Hauptspeicher kopiert werden müssen. Auch die Schreiboperationen sind erheblich performanter, unter anderem auch deshalb, weil die Erstellung von zusätzlichen Indizes weitgehend überflüssig ist.

Kompression

Die Daten werden spaltenweise komprimiert. Dabei kommen keine komplexen Algorithmen, wie z. B. beim bekannten Zip-Verfahren zum Einsatz. Stattdessen werden mehrere einfache Kompressionstypen verwendet, die jeweils sehr effizientes Packen und Entpacken erlauben. Der Standardalgorithmus ist die Wörterbuch-Kompression, bei dem jedem vorkommenden Wert in einer Spalte ein numerischer Schlüssel als 4-Byte-Integer zugeordnet wird. In der Spalte müssen dann nur noch diese Wert-Schlüssel gespeichert werden.

Damit werden für die meisten Spalten bereits gute Kompressionsraten erreicht. In Abbildung 3 sehen Sie ein Beispiel für dieses Vorgehen. Gerade für Spalten mit wenigen unterschiedlichen Ausprägungen lassen sich sehr hohe Kompressionsraten erzielen.

Abbildung 3: Beispiel für die Wörterbuch-Kompression

CPU-Last beim Packen und Entpacken

Der offensichtliche Nachteil ist die CPU-Last beim Packen und Entpacken. Dagegen gibt es zwei Strategien:

  • Das Packen der Daten findet immer nur bei der Delta-Merge-Operation (beschrieben im folgenden Abschnitt »Insert-Only«) statt. Diese geschieht parallel zu den anderen Einfüge- und Leseoperationen. Damit beeinflusst sie die laufenden Anwendungen nicht.
  • Das Entpacken erfolgt immer nur für die tatsächlich benötigten Spalten. Beispielsweise werden für einen Join zunächst nur die für die Join-Bedingung relevanten Spalten entpackt. Damit lassen sich schnell die relevanten Datensätze für das Ergebnis ermitteln. Später werden die anderen Spalten dazu gelesen. Dabei müssen diese dann ebenfalls entpackt werden. Dies kann aber sehr gut auf mehreren Prozessoren parallel verteilt werden. In Abbildung 11.27 sehen Sie ein Beispiel für die unterschiedlichen Planoperatoren der Datenbank bei einem einfachen Join. Der Planoperator JERequestedAttributes liest die entsprechenden Attribute nach, die dann von JEAssembleResults zu einer Ergebniszeile zusammengefügt werden.

Die unterschiedlichen Kompressionsverfahren und noch weitere Hintergrundinformationen zu dem Thema finden Sie in SAP-Hinweis 2112604 mit dem Titel FAQ: SAP HANA Compression.

Insert-Only

Die SAP-HANA-Datenbank verwendet den Insert-Only-Ansatz für alle ändernden Operationen. Das bedeutet nicht, dass das Aktualisieren oder Löschen von Datensätzen nicht möglich wäre. Aber die bestehenden Datensätze im Main Storage werden im laufenden Betrieb durch Schreiboperationen nicht verändert. Dieser Speicherbereich ist für lesende Zugriffe und geringen Speicherverbrauch optimiert. Änderungen hier wären relativ teuer.

Delta Storage

Stattdessen werden Änderungen in den sogenannten Delta Storage geschrieben (siehe Abbildung 4). Dies ist ein zusätzlicher Speicherbereich, der für die schreibenden Zugriffe optimiert wurde. Die Daten liegen hier unkomprimiert vor. Das Einfügen neuer Daten erfolgt direkt in den Delta Storage. Beim Löschen von Daten werden diese im Main- oder Delta Storage als zu löschen markiert. Bei Änderungen eines bestehenden Datensatz wird der ursprüngliche Datensatz als zu löschen markiert und ein neuer Datensatz in den Delta Storage geschrieben.

Delta Merge

Die Delta Merge Operation schreibt die Änderungen des Delta Storage zurück in den Main Storage. Dabei werden zu löschende Datensätze entfernt und es bleibt pro Datensatz nur eine gültige Version im Main Storage übrig. Der Delta Storage ist nach dem Delta Merge leer.

Der Delta Merge wird normalerweise in Abhängigkeit der Konfiguration der Datenbank automatisch angestoßen. Bei Datentransferprozessen (DTP) in SAP BW lässt sich ein expliziter Delta Merge nach der Ausführung einstellen.

Abbildung 4: Operationen auf Main und Delta Storage

Informationen über den Tabellenzustand

Über die Views M_CS_TABLES und M_CS_COLUMNS können Sie sich den aktuellen Zustand einer Tabelle bzw. deren Spalten anzeigen lassen. Darin sehen Sie z. B., wie viele Daten gerade im Delta und Main Storage liegen.

Hintergrund zum Delta-Merge-Verfahren finden Sie in dem Dokument »How To – Delta Merge for SAP HANA and SAP BW powered by SAP HANA«.

Die Kombination der Techniken

Die vier oben beschriebenen Techniken ergänzen sich hervorragend und gleichen gegenseitig ihre Schwächen aus:

  • Die spaltenweise Speicherung ermöglicht eine gute Kompression der Daten.
  • Die Kompression reduziert wiederum den Speicherverbrauch, so dass weniger Hauptspeicher benötigt wird.
  • Die Insert-Only-Strategie mit gelegentlichem Delta Merge bewirkt, dass die Kompression der Daten die laufenden Anwendungen nicht beeinflusst.
  • Und zu guter Letzt erlaubt eine performante Datenbank auch den Verzicht auf zusätzliche Indizes, Aggregate und materialisierte Views. Damit reduziert sich der Hauptspeicherbedarf noch weiter.

Die Kombination der Techniken machen SAP HANA zu einer sehr leistungsfähigen Datenbank. Sie sind im Detail auch in den genannten SAP-Hinweisen und in dem lesenswerten Blog von Werner Daehn (http://s-prs.de/v620800) beschrieben.

This post is also available in: English