{"id":62754,"date":"2019-11-28T08:00:32","date_gmt":"2019-11-28T07:00:32","guid":{"rendered":"http:\/\/e3mag.com\/?p=62754"},"modified":"2020-02-07T22:12:14","modified_gmt":"2020-02-07T21:12:14","slug":"hana-das-ganze-ist-mehr-als-die-summe-der-einzelteile","status":"publish","type":"post","link":"https:\/\/e3mag.com\/de\/hana-das-ganze-ist-mehr-als-die-summe-der-einzelteile\/","title":{"rendered":"Hana: Das Ganze ist mehr als die Summe der Einzelteile"},"content":{"rendered":"

Nun wird wieder vermehrt von \u201eWarm Storage\u201c gesprochen (Dynamic Tie\u00adring und Native Storage Extensions). Geht also SAP den umgekehrten Weg und landet am Ende dort, wo die klassischen Datenbanken herkommen \u2013 bei Disk-Datenbanken und Memory als Cache?<\/p>\n

Rows f\u00fcr OLTP Columns f\u00fcr OLAP<\/h3>\n

Oft h\u00f6rt man, dass eine Row-Storage, f\u00fcr ganze S\u00e4tze lesen, besser ist. Selbst Hasso Plattner hat das auf der vergangenen Sapphire-Keynote impliziert. \u00dcbliches Argument:<\/p>

\"Fullsize\"<\/a><\/div><\/div>\n

In einer zeilenbasierten Datenbank liegen die Daten eines Satzes beisammen. Ein eing\u00e4ngiges Argument, aber zu kurz gedacht. Die topologische Distanz wird au\u00dfer Acht gelassen.<\/p>\n

Dieses Argument kommt aus der Zeit der Festplatten, bei der Lesekopf plus Winkelgeschwindigkeit der rotierenden Platte die Zugriffszeit bestimmten und 4 kB gro\u00dfe Sektoren auf einmal gelesen wurden.<\/p>\n

Bei SSDs gibt es keine Mechanik mehr, da wird eine Adresse hingeschickt und ein 4 kB gro\u00dfer Sektor zur\u00fcckgegeben. Die Zugriffszeit auf einen Sektor ist somit deutlich geringer, die Daten sollten aber weiterhin nahe beisammen, im selben 4-kB-Sektor, liegen.<\/p>\n

Memory gibt stattdessen pro Zugriff nur 16 Byte zur\u00fcck, daf\u00fcr nat\u00fcrlich wesentlich schneller, und welche Speicheradresse als N\u00e4chstes angefordert wird, ist irrelevant.<\/p>\n

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 \u00e0 16 Byte gemacht, um 4 kB zu lesen.<\/p>\n

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.<\/p>\n

Nur bei Disk-Operationen gilt die Aussage, dass eine Zeile lesen eine Row-orientierte Speicherung verlangt und OLAP-Analysen eine Column-\u00adOrientierung. Damit habe ich zwar die Begr\u00fcndung selbst widerlegt, die Aussage \u201emit gen\u00fcgend Memory ist auch eine normale Datenbank eine In-memory-Datenbank\u201c steht noch unbeantwortet im Raum.<\/p>\n

Diese Begr\u00fcndung ergibt sich aus der Spaltenorientierung: In einem Datensatz stehen unterschiedlichste Informationen, Materialnummer, Text und viele Indikatoren wie Farbe, Typ, Gr\u00f6\u00dfe usw.<\/p>\n

Diese divergenten Informationen k\u00f6nnen sicher nicht so gut komprimiert werden wie jede Spalte f\u00fcr sich allein mit eher sich wiederholenden Mustern. Es wird sogar noch intelligenter vorgegangen, indem jeder Wert so einer Spalte einzeln betrachtet wird.<\/p>\n

Beispielsweise gibt es f\u00fcr das Feld Gr\u00f6\u00dfe nur die Auspr\u00e4gungen M, S, L, XL, also werden vier Strings erzeugt. Der String f\u00fcr M sieht vielleicht so aus: 0100-0000-0000-1000; und er besagt, dass der Wert M im Satz 2 und 13 vorkommt.<\/p>\n

So etwas kann von einem Computer sehr gut komprimiert werden und auch sehr schnell. F\u00fcr andere Spalten, etwa die Materialnummer, die f\u00fcr jedes Material unterschiedlich ist, werden andere Methoden verwendet.<\/p>\n

\"Werner<\/a><\/h3>\n

Suchen und finden<\/h3>\n

Zugriffe auf Daten erfolgen in einem ERP-\u00adSystem entweder nach Prim\u00e4rschl\u00fcssel oder \u00fcber eine Suche. \u201ezeige Sales Order 1234\u201c oder \u201esuche alle Sales Items zur Sales Order 1234\u201c.<\/p>\n

Ersteres l\u00e4uft 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.<\/p>\n

Bei der Suche existieren wiederum Unterschiede: Bei einer Row-Orientierung ist hoffentlich ein zweiter Index vorhanden, in dem alle Adressen der Sales-Item-S\u00e4tze stehen, die zu einer Sales Order geh\u00f6ren.<\/p>\n

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.<\/p>\n

Jeder dieser Punkte \u2013 Spaltenorientierung, Komprimierung, Indexierung und In-memory \u2013 hat f\u00fcr 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.<\/p>\n

Alles im Memory zu halten geht dann, wenn man komprimiert. Organisiert man die Daten in Spalten, kann besser komprimiert werden. Von Prim\u00e4rschl\u00fcsseln abgesehen ben\u00f6tigt man keine Indizes mehr, dank der spaltenweisen Organisation und der Komprimierung.<\/p>\n

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\u00fcr solche Abfragen eine spaltenweise Speicherung benutzen.<\/p>\n

Daf\u00fcr gewinnt man mit Hana viel f\u00fcr die normalen F\u00e4lle. OLAP-Abfragen \u00e0 la \u201eSumme Umsatz pro Jahr\u201c gehen sehr schnell, weil die Daten schon in Spalten organisiert sind.<\/p>\n

Suchen auf jedwedem Attribut gehen sehr viel schneller, weil jede Spalte per se einen Index repr\u00e4sentiert. Abfragen, die eben nicht 100 Prozent der Tabellenspalten lesen, sind schneller.<\/p>\n

Genau hier liegt aber auch der Hund begraben: Meine komplette Betrachtung lief unter der Pr\u00e4misse, dass alle Daten bereits im Speicher liegen und auch in den Speicher passen.<\/p>\n

Ist das nicht eine Speicher- und damit Geldverschwendung, immer alles im RAM (Random Access Memory) vorzuhalten, egal ob es ben\u00f6tigt wird oder nicht?<\/p>\n

SAP gibt hier dem Administrator M\u00f6glichkeiten zur Optimierung: Ein erster Punkt sind bin\u00e4re Datentypen (LOB-, CLOB- und NCLOB-Datentypen). Die werden nicht im Memory abgelegt, sondern bleiben immer auf Disk.<\/p>\n

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.<\/p>\n

Erstmalige Verwendung<\/h3>\n

N\u00e4chste 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\u00e4tze besteht, aufgeteilt in zehn Partitionen f\u00fcr zehn Jahre, w\u00fcrde nur die Partition f\u00fcr das aktuelle Jahr ins Memory geladen werden.<\/p>\n

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\u00e4chsten Restart.<\/p>\n

Daf\u00fcr 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!<\/p>\n

Das ist jetzt schon mal sehr gut, hat aber zwei L\u00fccken. Die erste Person, die auch nur einen einzigen Datensatz benutzt, triggert das komplette Laden von dieser Partition ins Memory.<\/p>\n

Wenn so eine Partition ein Giga\u00adbyte gro\u00df 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.<\/p>\n

Hier kommt das neueste Feature zu Hilfe, die Native Storage Extension. Damit wird nicht mehr die komplette Partition geladen, sondern nur noch die ben\u00f6tigten Pages, die diese Daten beinhalten.<\/p>\n

Und wenn nicht gen\u00fcgend RAM vorhanden ist, werden nicht ben\u00f6tigte Pages wieder entfernt. Von der Art und Weise geht man hier also wirklich wie bei einer Disk-basierten, klassischen Datenbank vor und benutzt f\u00fcr Tabellen mit dieser Einstellung das RAM nur als Cache.<\/p>\n

Multi-Temperature-Daten<\/h3>\n

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\u00f6nnen OLTP- und OLAP-Abfragen von der gleichen Datenbank erledigt werden, nur so bekommt man kurze und vorhersehbare Antwortzeiten.<\/p>\n

Diese zus\u00e4tzlichen Funktionen sind einzig und allein f\u00fcr Multi-Temperature-Daten geeignet. F\u00fcr Daten, die hin und wieder mal gebraucht werden. F\u00fcr die der Benutzer nicht in eine Archiv-Datenbank geschickt werden soll.<\/p>\n

W\u00fcrde ich diese Features f\u00fcr alle Tabellen verwenden und zu wenig RAM zur Verf\u00fcgung stellen, dann beginnen die Nachteile der spaltenorientierten Speicherung sichtbar zu werden. Ich h\u00e4tte nicht mehr alle Vorteile ohne Nach\u00adteile.<\/p>\n

Stattdessen stellt Hana den zentralen Einstiegspunkt f\u00fcr 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 \u00fcber das Hana Smart Data Access Feature von einem externen System eingeblendet (\u201eFederated\u201c). Der Anwender merkt nichts davon bis auf gegebenenfalls l\u00e4ngere Antwortzeiten. Hana wird zu einem Data Fabric.<\/p>\n

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.<\/p>\n

Der Bruch zu Dynamic Tiering mit einer SAP-\u00adIQ-Datenbank im Hintergrund ist noch gr\u00f6\u00dfer, weil hier keine Hana-Datenstrukturen mehr verwendet werden. Das Interface ist somit auf SQL limitiert.<\/p>\n

Und greift der Anwender auf ein externes System \u00fcber Smart Data Access zu, dann kann die Antwort nur so schnell sein, wie das externe System es erm\u00f6glicht.<\/p>\n","protected":false},"excerpt":{"rendered":"

Reportage: Eine kurze Geschichte zum langen Weg \u2013 In-memory Computing mit der Hana-Datenbank:<\/p>\n

Als die Konzepte von Hana das erste Mal innerhalb von SAP vorgestellt wurden, dachte ich, jede Datenbank mit gen\u00fcgend Memory ist doch eine In-memory-Computing-Datenbank und entsprechend schnell. Aber wenigstens war ich nicht der Einzige.<\/p>\n","protected":false},"author":1891,"featured_media":62755,"comment_status":"open","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"_acf_changed":false,"pmpro_default_level":"","footnotes":""},"categories":[5,36593],"tags":[65,428],"coauthors":[36006],"class_list":["post-62754","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-it-management","category-mag-1910","tag-hana","tag-olap","pmpro-has-access"],"acf":[],"featured_image_urls_v2":{"full":["https:\/\/e3mag.com\/wp-content\/uploads\/2019\/10\/shutterstock_519509098.jpg",1000,450,false],"thumbnail":["https:\/\/e3mag.com\/wp-content\/uploads\/2019\/10\/shutterstock_519509098-150x150.jpg",150,150,true],"medium":["https:\/\/e3mag.com\/wp-content\/uploads\/2019\/10\/shutterstock_519509098.jpg",400,180,false],"medium_large":["https:\/\/e3mag.com\/wp-content\/uploads\/2019\/10\/shutterstock_519509098-768x346.jpg",768,346,true],"large":["https:\/\/e3mag.com\/wp-content\/uploads\/2019\/10\/shutterstock_519509098.jpg",1000,450,false],"image-100":["https:\/\/e3mag.com\/wp-content\/uploads\/2019\/10\/shutterstock_519509098-100x45.jpg",100,45,true],"image-480":["https:\/\/e3mag.com\/wp-content\/uploads\/2019\/10\/shutterstock_519509098-480x216.jpg",480,216,true],"image-640":["https:\/\/e3mag.com\/wp-content\/uploads\/2019\/10\/shutterstock_519509098-640x288.jpg",640,288,true],"image-720":["https:\/\/e3mag.com\/wp-content\/uploads\/2019\/10\/shutterstock_519509098-720x324.jpg",720,324,true],"image-960":["https:\/\/e3mag.com\/wp-content\/uploads\/2019\/10\/shutterstock_519509098-960x432.jpg",960,432,true],"image-1168":["https:\/\/e3mag.com\/wp-content\/uploads\/2019\/10\/shutterstock_519509098.jpg",1000,450,false],"image-1440":["https:\/\/e3mag.com\/wp-content\/uploads\/2019\/10\/shutterstock_519509098.jpg",1000,450,false],"image-1920":["https:\/\/e3mag.com\/wp-content\/uploads\/2019\/10\/shutterstock_519509098.jpg",1000,450,false],"1536x1536":["https:\/\/e3mag.com\/wp-content\/uploads\/2019\/10\/shutterstock_519509098.jpg",1000,450,false],"2048x2048":["https:\/\/e3mag.com\/wp-content\/uploads\/2019\/10\/shutterstock_519509098.jpg",1000,450,false],"trp-custom-language-flag":["https:\/\/e3mag.com\/wp-content\/uploads\/2019\/10\/shutterstock_519509098.jpg",18,8,false],"bricks_large_16x9":["https:\/\/e3mag.com\/wp-content\/uploads\/2019\/10\/shutterstock_519509098.jpg",1000,450,false],"bricks_large":["https:\/\/e3mag.com\/wp-content\/uploads\/2019\/10\/shutterstock_519509098.jpg",1000,450,false],"bricks_large_square":["https:\/\/e3mag.com\/wp-content\/uploads\/2019\/10\/shutterstock_519509098.jpg",1000,450,false],"bricks_medium":["https:\/\/e3mag.com\/wp-content\/uploads\/2019\/10\/shutterstock_519509098.jpg",600,270,false],"bricks_medium_square":["https:\/\/e3mag.com\/wp-content\/uploads\/2019\/10\/shutterstock_519509098.jpg",600,270,false],"profile_24":["https:\/\/e3mag.com\/wp-content\/uploads\/2019\/10\/shutterstock_519509098-24x24.jpg",24,24,true],"profile_48":["https:\/\/e3mag.com\/wp-content\/uploads\/2019\/10\/shutterstock_519509098-48x48.jpg",48,48,true],"profile_96":["https:\/\/e3mag.com\/wp-content\/uploads\/2019\/10\/shutterstock_519509098-96x96.jpg",96,96,true],"profile_150":["https:\/\/e3mag.com\/wp-content\/uploads\/2019\/10\/shutterstock_519509098-150x150.jpg",150,150,true],"profile_300":["https:\/\/e3mag.com\/wp-content\/uploads\/2019\/10\/shutterstock_519509098-300x300.jpg",300,300,true]},"post_excerpt_stackable_v2":"

Reportage: Eine kurze Geschichte zum langen Weg \u2013 In-memory Computing mit der Hana-Datenbank:<\/p>\n

Als die Konzepte von Hana das erste Mal innerhalb von SAP vorgestellt wurden, dachte ich, jede Datenbank mit gen\u00fcgend Memory ist doch eine In-memory-Computing-Datenbank und entsprechend schnell. Aber wenigstens war ich nicht der Einzige.<\/p>\n","category_list_v2":"IT-Management<\/a>, MAG 19-10<\/a>","author_info_v2":{"name":"Werner D\u00e4hn, rtdi.io","url":"https:\/\/e3mag.com\/de\/author\/werner-daehn\/"},"comments_num_v2":"0 comments","_links":{"self":[{"href":"https:\/\/e3mag.com\/de\/wp-json\/wp\/v2\/posts\/62754","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/e3mag.com\/de\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/e3mag.com\/de\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/e3mag.com\/de\/wp-json\/wp\/v2\/users\/1891"}],"replies":[{"embeddable":true,"href":"https:\/\/e3mag.com\/de\/wp-json\/wp\/v2\/comments?post=62754"}],"version-history":[{"count":0,"href":"https:\/\/e3mag.com\/de\/wp-json\/wp\/v2\/posts\/62754\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/e3mag.com\/de\/wp-json\/wp\/v2\/media\/62755"}],"wp:attachment":[{"href":"https:\/\/e3mag.com\/de\/wp-json\/wp\/v2\/media?parent=62754"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/e3mag.com\/de\/wp-json\/wp\/v2\/categories?post=62754"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/e3mag.com\/de\/wp-json\/wp\/v2\/tags?post=62754"},{"taxonomy":"author","embeddable":true,"href":"https:\/\/e3mag.com\/de\/wp-json\/wp\/v2\/coauthors?post=62754"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}