​​​​​​​​​​10 Mythen über SAP HANA​

04.07.2018 | Dennis Bühring

Mit HANA bleiben alle Daten im RAM, ABAP-Programmierer haben ausgedient und mit HANA wird definitiv alles schneller als vorher: Wir haben 10 Vorurteile über HANA entmystifiziert. 


 

1.       HANA ist eine rein spaltenorientierte Datenbank (Column Store)

Nein, HANA legt die Tabellen zwar hauptsächlich spaltenbasiert ab (über 95% in einer Business Suite), stellt aber für spezielle Fälle auch zeilenbasierte Tabellen zur Verfügung. Wenn man zum Beispiel immer jede einzelne Spalte bei einer Abfrage benötigt, bietet sich die zeilenbasierte Ablage an, da die Tupel-Rekonstruktion eine sehr teure Operation darstellt. Die Vor- und Nachteile von Row- und Column Store sind in SAP Note 2222277 dargestellt. Der Tabellentyp wird im ABAP Dictionary (SE11, Technical Settings) für alle SAP Tabellen bereits vorgegeben.


 

2.       In-Memory Datenbank bedeutet, dass alle Daten im RAM gehalten werden müssen

Nein, HANA hält von vielen Tabellen nur einzelne Spalten im RAM, je nach Regelmäßigkeit des Zugriffs. Mit Tabellenpartitionierung ist es sogar möglich, nur ausgewählte Daten (beispielsweise Datensätze aus dem Monat Juli des Jahres 2018) im RAM zu halten und den Rest auf die Festplatte auszulagern. Das kostenfreie Tool „Data Aging“ unterstützt die Business Suite Anwendung bei der Erstellung der Partitionen. Man ist keinesfalls gezwungen, alle Daten im RAM zu vorhalten.


 

3.       HANA könnte bei einem Stromausfall Daten verlieren, da alles „In-Memory“ abläuft

Nein, aus Gründen der Persistenz wird weiterhin eine Disk benötigt (Data und Log Volume). Ohne die Disk wäre die Bedingung „durability“ (Dauerhaftigkeit) des ACID-Prinzips nicht gegeben, da RAM ein flüchtiger Speicher ist und Änderungen verloren gehen könnten. Jede Änderung muss durch ein Redo-Log protokolliert werden, daher ist die Geschwindigkeit des Log Volumes direkt ausschlaggebend für die Performance der HANA. HANA 2.0 SPS03 unterstützt zwar NVRAM, es gibt jedoch noch keinen praktischen Anwendungsfall.


 

4.       HANA verbindet OLTP und OLAP Anwendungen, braucht man also kein BW mehr?

HANA kann zwar mit beiden Applikationstypen umgehen, man wird aber nicht in einem SAP System eine OLTP Anwendung (ERP) zusammen mit einer OLAP Anwendung (BW) gemeinsam betreiben. Das sind bis heute zunächst zwei getrennte Datenbanken. Ein Business Warehouse System besteht weiterhin aus einem Applikationsserver und der Datenbank. Mit HANA benötigt man jedoch den BW Accelerator nicht mehr, der kostenpflichtig wäre. Das Nachfolgeprodukt von BW on HANA ist BW/4HANA.


 

5.      Mit HANA braucht man keine ABAP Programmierer mehr (Logik auf die DB-Ebene verschieben, „Code Pushdown“)

Nein, denn vieles der Business Logik wird weiterhin aus dem ABAP heraus gesteuert. ABAP Programmierer werden natürlich immer noch benötigt. Es gibt jedoch neue Funktionen und Sprachen (ABAP oder HANA Core Data Services), die eventuell als Zusatzqualifikation relevant werden. Geschäftsprozesse sind weiterhin in ABAP abgebildet. Performance bei Zugriffen auf Daten wird zum Beispiel durch Nutzung der HANA Calculation Views erzielt. Es lässt sich nicht jede Logik auf die Datenbank verschieben, da es zum Beispiel steuerrechtliche Hintergründe geben kann.


 

6.       SQL-Abfragen auf HANA funktionieren genauso wie mit jeder anderen Datenbank auch

Nein, denn unter HANA gibt es Änderungen durch die spaltenbasierte Ablage. Ein Beispiel hierfür ist die Ausgabereihenfolge (Stichwort ORDER BY PRIMARY KEY). Im SAP Standard Code sind diese Änderungen eingebaut, bei Z-Programmen muss eine Überarbeitung stattfinden. Durch die Installation des ABAP Test Cockpits (ein eigenständiges ABAP System für die Codeanalyse) können Z-Programme auf relevante Änderungen überprüft werden. Mit HANA werden Pool- und Clustertabellen aufgelöst, da eine DB-seitige Optimierung sonst nicht möglich wäre. Aus Sicht der Performance gibt es bei der spaltenorientierten Ablage andere wichtige Faktoren als bei einer zeilenorientierten Datenbank.


 

7.       HANA macht jedes Programm definitiv um Faktor X schneller

Nein, das kommt stark auf die Abfrage an und es gibt keinen verlässlichen Faktor. Manche Abfragen laufen Faktor 1000, 100 oder 10 schneller und manche sogar langsamer als auf einer AnyDB. Es kommt stark auf die Abfrage an (man sollte zum Beispiel bei Column Store Tables niemals „select *“ verwenden) und wie stark eine Parallelisierung möglich ist. Es gibt viele Reports, deren Laufzeit von vielen Stunden auf wenige Minuten reduziert wurde.


 

8.       HANA Tabellen können nur eine gewisse Anzahl an Einträgen fassen

Das stimmt teilweise, denn eine Column Store Table kann aus technischen Gründen nur 2.147.483.648 Einträge fassen. Hintergrund ist der Attributsvektor einer komprimierten Spalte. Durch Partitionierung kann man diese Einschränkung jedoch umgehen, da jede Tabellenpartition wiederum diese Anzahl an Einträgen aufnehmen kann.


 

9.       Mit HANA gibt es keine UPDATE und DELETE Operationen mehr

Diese Aussage ist soweit korrekt. Bei der Änderung eines Datensatzes wird nicht der ursprüngliche Datensatz überschrieben, sondern im Delta Store der Column Table ein neuer Eintrag angelegt. Der Eintrag im Main Store wird als ungültig ausgewiesen und erst beim Delta Merge entfernt, ist aber nicht mehr durch SQL sichtbar. Hierbei spricht man vom Insert-Only Modus. Die SQL Operatoren DELETE und UPDATE gibt es natürlich trotzdem noch.


 

10.   Man braucht ein Berechtigungskonzept auf HANA

HANA bietet die Möglichkeit, ein eigenes Berechtigungskonzept abzubilden. Es kommt auf die Verwendung des Systems an. Wenn User über die SAP Applikation einsteigen und die Berechtigungsprüfung im ABAP durchgeführt wird, dann ist es nicht relevant. Wenn jedoch User direkt über ein Tool Daten per SQL abrufen können, beispielsweise über ein eigenes BI-Tool, muss der Zugriff auf kritische Daten reguliert werden. Wenn man HANA nur als Datenbank für sein SAP System einsetzt und keine nativen Funktionen nutzt, hält sich der Aufwand in Grenzen.



TAGS
SAP HANA
Nein
SAP