SAP HANA – Erfahrungen mit der In-Memory-Datenbank, Teil 3: Einordnung

In den ersten beiden Beiträgen zu dieser Blogreihe haben wir uns in erster Linie mit den Möglichkeiten von SAP HANA zur Performancesteigerung auf Datenbank-Ebene auseinandergesetzt. Diese Möglichkeiten greifen in Umgebungen für ERP, für Business Intelligence und für individuelle Anwendungen.

In diesem dritten Beitrag wollen wir einige grundsätzliche Überlegungen zum Einsatz von SAP HANA anstellen. An dieser Stelle sei betont, dass es sich um die Darstellung unserer subjektiven Einschätzungen und nicht um offizielle Statements zu SAP HANA handelt.

Bedeutung

SAP HANA ist neben den Themen Cloud und mobile Anwendungen eine der drei Säulen des aktuellen SAP-Marketings. Ist dies jetzt nur eine Marketing-Kampagne oder steckt mehr dahinter?

Bevor wir diese Frage beantworten wollen, zunächst einige wesentliche Fakten, was sich denn hinter SAP HANA verbirgt:

• SAP HANA ist eine In-Memory-Datenbank, d.h. die Datenhaltung der aktuellen Daten erfolgt im Hauptspeicher des Datenbank-Servers
• SAP HANA kann die Daten spalten-orientiert bearbeiten (im Gegensatz zum traditionellen zeilen-orientierten Ansatz)
• SAP HANA ist SQL-kompatibel und kann von bestehenden SAP und Non-SAP-Anwendungen genutzt werden (auch ABAP-Zugriffe)
• SAP stellt mit HANA XS einen eng mit der Datenbank verbundenen Application Server zur Verfügung (server-side JavaScript, OData etc.- aber keine integrierte ABAP-Ablaufumgebung)
• SAP stellt mit SAP HANA Studio eine eigene (Eclips-basierende) Entwicklungsumgebung bereit
• SAP HANA kann nicht von CD installiert werden, SAP HANA muss (zumindest Stand heute) als komplette Hardware-Appliance erworben werden
• SAP bietet SAP HANA über diverse Angebote auch in der Cloud an

Wir glauben, dass SAP HANA einen Wandel in den geschäftlich genutzten Datenbank-orientierten Anwendungen einläutet und in wenigen Jahren selbstverständlich genutzt werden wird.

Hierfür sehen wir mehrere Gründe.

1. Technologie

Die aktuelle Hardware-Technik ist für den Einsatz von In-Memory-Datenbanken vorbereitet. Entsprechende Server mit den notwendigen Kapazitäten stehen zu wirtschaftlich vertretbaren Preisen zur Verfügung.

SAP hat sich auf diesen Trend vorbereitet und gehört mit SAP HANA zu den Technologie-Führern in diesem Bereich. Die Grundlagen für die Entwicklung von SAP HANA wurden am Hasso-Plattner-Institut in Potsdam erforscht.

2. SAP-Strategie

Mit SAP HANA hat SAP endlich eine eigene konkurrenzfähige Datenbank für den Unternehmensbereich im Portfolio.  Hier kann sie die Datenbank-Entwicklung auf die Entwicklung der eigenen ERP- und Data Warehouse-Produkte abstimmen und so enger integrieren. Und vielleicht noch wichtiger: die Lizenzzahlungen an die Konkurrenten (vor allem Oracle) für die Nutzung derer Datenbanken fallen weg.

3. Nachvollziehbarer Nutzen

Neben den Geschwindigkeitssteigerungen durch den Einsatz einer In-Memory-Datenbank entsteht dieser Nutzen vor allem durch die Verschmelzung der bisher getrennten ERP- und Data Warehouse-Installationen. SAP verspricht auf lange Sicht, dass keine eigenständigen Data Warehouse-Lösungen mehr notwendig sind. Durch den Wegfall der Installationen und vor allem der oft zeit- und betreuungsaufwändigen Ladeprozeduren entsteht hier ein nachvollziehbarer Nutzen für die Kunden.

Hasso Plattner sieht durch In-Memory-Datenbanken die heute bestehende strikte Trennung der OLTP- und OLAP-Welten aufgehoben. Auch diese Darstellung ist aus unserer Sicht nachvollziehbar und vorteilhaft.

4. Smarter Übergang

Der Einsatz von SAP HANA muss nicht durch einen „Alles oder Nichts“-Ansatz erkauft werden. Für alle Anwendungsgebiete gibt es Ansätze, SAP HANA schrittweise einzuführen und somit sowohl Investitionen als auch Risiko zu begrenzen. Die SAP selbst ist hier Vorreiter und hat inzwischen ihre  produktiven Anwendungen im Rechnungswesen und CRM weltweit auf SAP HANA umgestellt.

Technik

An dieser Stelle wollen wir einige grundlegende Aspekte der technischen Realisierung von SAP HANA betrachten. Es ist selbstverständlich, dass diese Darstellung nur wenige Fakten und diese auch nur per highligthing betrachten kann.

In-Memory-Datenbank

Ist es denn überhaupt möglich, eine große unternehmensweite Datenbank im Hauptspeicher eines Servers zu halten und zu bearbeiten? Die Antwort auf diese Frage lautet heute: Ja. Solche Server (bzw. Server-Cluster) sind heute wirtschaftlich betreibbar und in der Lage, sehr große Datenmengen im Hauptspeicher zu speichern und zu bearbeiten.

Hierbei unterstützt SAP HANA durch diverse Techniken zur Reduktion des Umfangs der zu speichernden Datenmenge, z.B. Dictionary-encoding und Einsatz von Kompressionstechniken.

Ein wesentlicher Aspekt ist aber eher in organisatorischer Hinsicht zu sehen: Untersuchungen am Hasso-Plattner-Institut haben gezeigt, dass in heute produktiv genutzten ERP-Systemen

– 40% der Spalten ungenutzt sind,

– die meisten Spalten eine geringe Kardinalität (= Menge der Spaltenwerte) haben

– bei den Werten in vielen Spalten NULL bzw. Default-Werte dominieren.

Diese Erkenntnisse nutzt SAP HANA über seine Architektur und den Einsatz von Kompressionstechniken aus, um den tatsächlichen Speicherbedarf deutlich zu reduzieren.

Spalten-orientierte Datenbank-Organisation

Traditionelle SQL-Datenbanken speichern ihre Daten in einem zeilen-orientierten Ansatz. Dies bedeutet, dass alle Daten, die z.B. zu einer konkreten Person gehören, direkt hintereinander abgelegt werden. Dies klingt logisch und hat auch Vorteile beim Einfügen eines Datensatzes und beim Auffinden aller Daten zu einer konkreten Person.

Nachteile dieser Datenbank-Organisation ergeben sich beim Suchen von Datenmengen anhand von Suchwerten und auch beim Auslesen gezielter Attribute einzelner Datensätze, weil die zu verarbeitende Datenmenge (und damit die benötigte Zeit) größer ist.

Die bereits oben erwähnten Untersuchungen am Hasso-Plattner-Institut haben gezeigt, dass in heute produktiv genutzten ERP- und Data Warehouse-Systemen

– weniger als 20% der Datenbank-Operationen Modifikationen (Insert, Update, Delete) und

– mehr als 80% der Datenbank-Operationen Lesevorgänge (Lookups einzelner Datensätze,    Auswertungen über größere Datenbereiche)

sind. Diese Werte gelten (mit Abweichungen) sowohl für OLTP-Systeme als auch für OLAP-Systeme.

Aus diesen Gründen kann SAP HANA Daten in einer spalten-orientierten Organisation ablegen. Die Entscheidung, ob zeilen- oder spalten-orientiert, kann für jede einzelne Datenbank-Tabelle getroffen werden.

In der spalten-orientierten Organisation werden z.B. die Nachnamen aller Personen und die Geburtstage aller Personen (und auch alle weiteren Attribute der Personen) jeweils zusammen abgespeichert. Bei der Suche nach einem bestimmten Nachnamen muss nur die entsprechende Spalte durchsucht werden, alle anderen Spalten bleiben bei dieser einfachen Suche unberücksichtigt. Dadurch wird die Menge der zu lesenden Daten begrenzt und die Verarbeitungsgeschwindigkeit erhöht.

Dictionary-Encoding

Von den weiteren technischen Merkmalen von SAP HANA sei an dieser Stelle noch Dictionary-Encoding erwähnt. Dictionary-Encoding stellt einen einfachen Weg dar, um den benötigten Speicherbedarf bei geringfügig erhöhtem Verarbeitungsbedarf zu reduzieren.

Diese Technik wollen wir an einem Beispiel erläutern.

Wenn in einer Datenbank alle 80 Millionen Einwohner von Deutschland erfasst werden und für deren Nachnamen 30 Stellen vorgesehen sind, dann werden hierfür in einer traditionellen Datenbank 80 M * 30 Byte = 2,4 GB Speicherplatz benötigt.

Unterstellen wir, dass es unter den Einwohnern in Deutschland 200.000 unterschiedliche Nachnamen gibt (und somit für eine eindeutige Kennzeichnung der unterschiedlichen Nachnamen 18 bit benötigt werden), dann berechnet sich der benötigte Speicherplatz mit Dictionary-Encoding wie folgt:

Platzbedarf für Dictionary: 200 K * 30 Byte = 6 MB

Platzbedarf für Daten 80 M * 18 bit = 180 MB

Gesamtbedarf 186 MB

Das sind weniger als 8% des originalen Speicherbedarfs von 2,4 GB.

Geringerer Speicherbedarf führt auch zu höherer Performance, weil weniger Daten aus dem Hauptspeicher zu lesen sind.

Datensicherheit

Der natürliche Reflex auf In-Memory-Datenbanken ist die Frage. „Was passiert denn, wenn der Strom ausfällt?“

Natürlich stehen dann die Daten erst wieder nach einem Recovery-Vorgang zur Verfügung. Das unterscheidet aber In-Memory-Datenbanken in keinster Weise von traditionellen SQL-Datenbanken.

Um die Datensicherheit und die Konsistenz der Daten zu gewährleisten, verwenden In-Memory-Datenbanken (genauso wie traditionelle SQL-Datenbanken) Snapshots und Logfiles.

Der Inhalt des Hauptspeichers wird als direkter Abzug in regelmäßigen Abständen auf externen dauerhaften Speichern (z.B. Magnetplatten) gesichert. Dazu werden Logfiles zu allen abgeschlossenen Änderungsoperationen der Datenbank ebenfalls auf externen Speichern abgelegt.

Beim Recovery wird zunächst der letzte Snapshot in den Hauptspeicher geladen und dann die Logfiles nachgearbeitet. Hierfür gibt es ebenfalls spezielle Techniken, um diesen Vorgang performant zu gestalten. Darauf wollen wir an dieser Stelle aber nicht tiefer eingehen.

Es sind an dieser Stelle aber zwei Dinge erkennbar:

1. auch In-Memory-Datenbanken nutzen Backup-/Recovery-Mechanismen, die von den traditionellen SQL-Datenbanken bekannt sind
2. auch In-Memory-Datenbanken benötigen einen dauerhaften Speicher (z.B. Magnetplatten).

Architektur von Anwendungen

Neben der In-Memory-Datenbank bietet SAP HANA mit HANA XS auch einen eng mit der Datenbank verbundenen Application Server an und propagiert gleichzeitig einen Wechsel des Programmier-Paradigmas von der Dreischicht-Architektur auf eine Datenbank-zentrierte Entwicklung.

So sollen zukünftig alle datenintensiven Programmanteile direkt in der Datenbank ablaufen. Hierfür bietet SAP in SAP HANA zum einen unterschiedliche Views (Attribute View, Analytic View, Calculation View) an, um die Verwendung der gespeicherten Daten für Analysen und Abfragen zu erleichtern.

Zum anderen unterstützt SAP HANA stored procedures und bietet hierfür auch spezifische Spracherweiterungen für prozedurale Logik an.

Beide Features von SAP HANA sollen die Entwickler (von neuen Applikationen) dazu bewegen, vor allem datenintensive Operationen direkt in der Datenbank durchzuführen und nur noch die Ergebnisse an den Application Server zu übertragen.

Mit diesem Ansatz geht ein beträchtlicher Teil der Logik vom Application Server auf den Datenbank-Server über. SAP argumentiert, dass datennahe Operationen dort effizienter auszuführen sind. Inwieweit das tatsächlich zutrifft, muss noch abgewartet werden.

Auf jeden Fall wird die Gesamt-Performance von Anwendungen aber erhöht, wenn keine großen Datenmengen mehr vom Datenbank-Server auf den Application Server (und evtl. zurück) übertragen werden müssen, wie das in heutigen klassischen 3-tier-Architekturen der Fall ist.

Mit der Verlagerung von Programmierlogik in den Datenbank-Server wird aber die Bedeutung des Application Servers deutlich geringer. SAP antwortet hierauf mit SAP HANA XS, das Bestandteil von SAP HANA ist und Funktionalitäten eines „schmalen“ Application Servers aufweist. Insbesondere unterstützt SAP HANA XS server-side JavaScript (mit SAP-Erweiterungen), was für viele Anwendungen die Verwendung eines zusätzlichen Application Servers überflüssig machen wird.

Fazit Teil 3

In diesem Teil der Blogreihe haben wir einige Aspekte von SAP HANA betrachtet und auch unsere Einschätzungen zu diesen Themen dargestellt.

Im vierten Teil wollen wir eine einfache SAP HANA – Anwendung für die Performance-Untersuchungen aus Teil 1 und Teil 2 vorstellen.