{"id":440,"date":"2014-02-27T14:08:39","date_gmt":"2014-02-27T13:08:39","guid":{"rendered":"http:\/\/e3mag.com\/?p=440"},"modified":"2022-02-06T14:40:24","modified_gmt":"2022-02-06T13:40:24","slug":"logwriter-datawriter","status":"publish","type":"post","link":"https:\/\/e3mag.com\/de\/logwriter-datawriter\/","title":{"rendered":"Logwriter & Datawriter"},"content":{"rendered":"

Die In-memory-Technologie<\/span> erfordert grunds\u00e4tzlich neue Programmiermodelle, die sich nicht durch Anpassungen vorhandener Software realisieren lassen, sondern radikal neue Ans\u00e4tze erfordern. Damit steht nicht nur in der Hardware-, sondern auch in der Softwaretechnologie ein Paradigmenwechsel bevor.<\/p>\n

Im Zuge des technischen Fortschritts hat die Zugriffsgeschwindigkeit von Storagesystemen nicht Schritt halten k\u00f6nnen mit den Zuw\u00e4chsen bei der Prozessorgeschwindigkeit. Bei CPU-Taktraten von 3 GHz, was Zykluszeiten von 0,3 Nanosekunden entspricht, dauern Verarbeitungsschritte im Prozessor in der Gr\u00f6\u00dfenordnung von Nanosekunden (ns), w\u00e4hrend Zugriffe auf externen Storage sich im Bereich von Millisekunden (ms) bewegen. Das ist ein Missverh\u00e4ltnis von 1 zu 1.000.000!<\/p>

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

Als Konsequenz warten CPUs bei Anwendungen der Informationsverarbeitung die meiste Zeit auf IO. Nun reicht es nicht, nur den Storage schneller zu machen, etwa mit ultraschnellen Flash<\/span>-Devices, da auch schon das Licht und damit auch die Daten im ns-Bereich nur eine sehr beschr\u00e4nkte Distanz zur\u00fccklegen k\u00f6nnen (< 30 cm in 1 ns).<\/p>\n

Somit kann schneller Datenzugriff letztlich nur dadurch erzielt werden, dass die Daten auch nahe beim Prozessor bereitgehalten werden: im RAM<\/span>, oder besser noch im Cache.<\/p>\n

Code to Data<\/h3>\n

Eine weitere Beschleunigung der Verarbeitungsgeschwindigkeit l\u00e4sst sich dadurch erzielen, dass Anwendungscode direkt in der Datenbank ausgef\u00fchrt wird, wodurch vergleichsweise hohe Latenzen bei der Kommunikation zwischen Applikation und Datenbank vermieden werden.<\/p>\n

Wurden also bislang Daten durch die Datenbank zur Anwendung geschleust, wird zuk\u00fcnftig Anwendungscode zu den Daten gebracht. Damit l\u00e4sst sich der Paradigmenwechsel am anschaulichsten beschreiben: Statt \u201eData to Code\u201c hei\u00dft es zuk\u00fcnftig \u201eCode to Data\u201c.<\/p>\n

Aktuell ist RAM<\/span> allerdings noch fl\u00fcchtig, sodass Schreiboperationen im Hauptspeicher durch eine Persistenzschicht, also letztlich doch wieder Storage, abgesichert werden m\u00fcssen. F\u00fcr lesenden Zugriff, auch auf sehr gro\u00dfe Datenmengen, ist RAM<\/span> heute bereits gut ger\u00fcstet, da mit immer h\u00f6herer Packungsdichte der Speicherelemente und gleichzeitigem Preisverfall Rechner mit hohen RAM<\/span>-Kapazit\u00e4ten (bis zu mehreren TB) zu vertretbaren Preisen verf\u00fcgbar sind.<\/p>\n

Da Lesen aus dem RAM<\/span> heute also effizient und sinnvoll m\u00f6glich ist, liegt der Fokus von SAP Hana und anderen In-memory-Technologien<\/span> schwerpunktm\u00e4\u00dfig auf lesenden Anwendungen wie Reporting und Business Intelligence (OnLine Analytic Processing, OLAP<\/span>).<\/p>\n

F\u00fcr transaktionale Systeme (OnLine Transaction Processing, OLTP<\/span>) kann man Vorteile daraus gewinnen, dass einerseits Online-Reporting auf den transaktionalen Daten ohne Performanceeinbu\u00dfen bei der Transaktionsverarbeitung m\u00f6glich ist oder dass Codestrecken mit hohem Kommunikationsaufkommen zwischen Datenbank und Applikation von einer Verlagerung in die Datenbank schon jetzt profitieren.<\/p>\n

Aber gleich ob OLAP<\/span> oder OLTP<\/span>, die In-memory-DB (IMDB) ben\u00f6tigt eine Persistenz<\/span>, denn sp\u00e4testens, wenn der Rechner ausgeschaltet wird, sind die Daten aus dem RAM<\/span> verschwunden.<\/p>\n

Persistenzschicht und Performance<\/h3>\n

Da bei einer IMDB die Datenzugriffe \u00fcberwiegend im RAM<\/span> geschehen, k\u00f6nnte man erwarten, dass der Storage als Persistenzschicht hinsichtlich Performance eine geringe Rolle spielt und in erster Linie zur Absicherung dient, damit keine Daten verloren gehen. Die Anforderungen der SAP<\/span> an die Performance der Persistenz<\/span> waren und sind aber zum Teil h\u00f6her als f\u00fcr klassische Datenbanken. Allgemein lassen sich bei Datenbanken zwei Schreibmechanismen ausmachen \u2013 Logwriter und Datawriter. Der Logwriter dokumentiert zeitnah (synchron) in einem eigenen Bereich jede einzelne \u00c4nderung (Insert, Update, Delete), die auf der Datenbank durchgef\u00fchrt wird. Der Datawriter aktualisiert von Zeit zu Zeit (asynchron) die \u00c4nderungen der Tabellen im Storage und sorgt f\u00fcr ein konsistentes, aber meist nicht aktuelles (da asynchrones) Abbild der Datenbank. Kritisch f\u00fcr die Transaktionsverarbeitung und f\u00fcr eine Datenbank-Recovery, wenn sie einmal n\u00f6tig sein sollte, ist der Logwriter. Eine Transaktion gilt erst dann als abgeschlossen, wenn der Logwriter sie als dokumentiert zur\u00fcckgemeldet hat. Erst dann kann die Verarbeitung fortgesetzt werden. Damit ist sichergestellt, dass nach einem ungeplanten Abbruch der Datenbank der letzte g\u00fcltige Zustand wiederhergestellt werden kann, indem das letzte konsistente Datenimage mit den dort noch nicht erfassten Logeintr\u00e4gen fortgeschrieben wird (Roll Forward).<\/p>\n

Logwriter & Datawriter<\/h3>\n

In den fr\u00fchen Revisions von Hana<\/span> war der Logwriter so konzipiert, dass er alle \u00c4nderungen in kleinen Blockgr\u00f6\u00dfen in den Log-Bereich schrieb. Bei umfangreichen \u00c4nderungen in der Datenbank f\u00fchrte das zu einer erheblichen Anzahl an IO-Operationen. Deshalb war damals die Anforderung von SAP<\/span>, dass die Persistenz<\/span> in der Lage sein musste, mindestens 100.000 IOps (IO-Operationen pro Sekunde) schreiben zu k\u00f6nnen.<\/p>\n

Das ist mit vertretbarem Aufwand nur mit lokalen Flash<\/span>-Devices (PCI-basiert) zu realisieren. Deshalb hatten und haben die meisten Single-Node-Installationen von Hana PCIe basierte Flash<\/span>-Devices. Sp\u00e4ter wurde Hana<\/span> um eine ScaleOut-Architektur erweitert f\u00fcr den Fall, dass der maximal m\u00f6gliche Hauptspeicherausbau innerhalb eines Rechners nicht mehr ausreichte, eine gr\u00f6\u00dfere Datenbank komplett zu speichern.<\/p>\n

Hana<\/span> kann mit dieser Option auf mehrere Rechnerknoten verteilt werden. Die Rechner k\u00f6nnen so ausgelegt werden, dass nicht alle aktiv sind, sondern dass auch ein oder mehrere Knoten als Failover<\/span> konfiguriert werden k\u00f6nnen f\u00fcr den Fall, dass ein aktiver Knoten ausf\u00e4llt. Das setzt allerdings eine (externe) Persistenz<\/span> voraus, die von allen Rechnern gelesen werden kann, denn sonst kann ein Failover<\/span>-Knoten nicht die Daten eines ausgefallenen Rechners einlesen.<\/p>\n

Damit war das Konzept, Log-Daten sehr schnell auf ein lokales Device zu schreiben, nicht mehr haltbar. Dementsprechend wurde der Logwriter dahin gehend optimiert, dass er variable Blockgr\u00f6\u00dfen schreiben konnte. Damit waren die hohen IO-Raten auch nicht mehr erforderlich. In einem ScaleOut-Szenario waren knapp 20.000 IOps pro Rechnerknoten ausreichend. Gleichwohl hielt SAP<\/span> die 100.000 IOps f\u00fcr Single-Nodes bis in die j\u00fcngste Vergangenheit aufrecht.<\/p>\n

Neben dem Logwriter gibt es noch, wie schon erw\u00e4hnt, den Datawriter. Zun\u00e4chst sollte man wiederum meinen, dass der unkritisch im Hinblick auf Performance ist, da er ja asynchron schreibt. Tats\u00e4chlich schreibt Hana<\/span> in konfigurierbaren Zeitabst\u00e4nden \u2013 Default ist f\u00fcnf Minuten \u2013 sogenannte Savepoints. Die Performance des Storage muss so ausgelegt sein, dass zumindest vom Durchsatz das zwischen zwei Save\u00adpoints ge\u00e4nderte Volumen im verf\u00fcgbaren Zeitintervall geschrieben werden kann.<\/p>\n

Da der Datawriter nach dem Prinzip Copy-on-write verf\u00e4hrt, ist die Schreiblast tendenziell sequenziell, da ge\u00e4nderte Bl\u00f6cke<\/span> nicht \u00fcberschrieben werden, sondern die \u00c4nderungen in neu allokierte Bl\u00f6cke<\/span> abgelegt werden. Damit vereinfachen sich die Anforderungen an die Persistenz<\/span>, weil sequenzielle IO wesentlich effizienter realisiert werden kann als Random-IO.<\/p>\n

Da die spaltenbasierte interne Architektur von Hana<\/span> vergleichbar ist mit zu einhundert Prozent indizierten Datenbest\u00e4nden, fallen im Vergleich zu anderen Datenbanken bei Hana<\/span> h\u00e4ufiger interne Reorganisationen an, die dann auch auf die Persistenz<\/span> abgebildet werden.<\/p>\n

Damit erh\u00f6ht sich die Anforderung des Data\u00adwriters an den Schreibdurchsatz. Dagegen sollte man erwarten, dass die Anforderungen an den IO-Durchsatz beim Lesen von Daten eher gering sind, da Hana<\/span> Daten eigentlich im RAM<\/span> lesen sollte.<\/p>\n

Das mag f\u00fcr den Normalbetrieb richtig sein, stimmt aber nicht f\u00fcr den Fall, dass Hana<\/span> hochgefahren wird. Nimmt man an, dass 1 TB Daten in den Hauptspeicher gelesen werden m\u00fcssen, dauert das bei einem Durchsatz von 1 GB\/s noch immerhin 20 Minuten. Das w\u00e4re kein Problem, wenn Restarts der Datenbank die Ausnahme w\u00e4ren.<\/p>\n

Da Hana<\/span> aktuell aber st\u00e4ndig weiterentwickelt wird mit dem Ziel, eines Tages NVRAM optimal zu nutzen, sind in regelm\u00e4\u00dfigen Abst\u00e4nden Updates einzuspielen, die oft mit einem Restart der Datenbank einhergehen. Daher erkl\u00e4rt sich die Anforderung von SAP<\/span>, die Persistenz<\/span> auch mit hohen Durchsatzraten f\u00fcr das Lesen im Datenbereich auszustatten.<\/p>\n

OLAP<\/span> versus OLTP<\/span><\/strong><\/h3>\n

Auch wenn, wie oben erw\u00e4hnt, der Haupteinsatzbereich von IMDBs tendenziell im OLAP<\/span> liegt, geht SAP<\/span> bereits den Weg, auch OLTP<\/span>-Anwendungen auf Hana<\/span> zu propagieren (Suite on Hana<\/span>). Technisch ist es m\u00f6glich, f\u00fcr OLTP<\/span>-Systeme sowohl Single Nodes als auch Scale\u00adOut-Architekturen einzusetzen.<\/p>\n

Aus Sicht der Performance ergibt sich jedoch ein signifikanter Unterschied. Wie bereits erl\u00e4utert, kann sich f\u00fcr OLTP<\/span>-Anwendungen ein Performancevorteil auf Hana<\/span> ergeben, wenn Codestrecken in die Datenbank verlagert werden, um zeitaufw\u00e4ndige Kommunikation zwischen Applikation und Datenbank zu vermeiden.<\/p>\n

Wenn Hana<\/span> aber in einer ScaleOut-Landschaft \u00fcber mehrere Rechnerknoten verteilt ist, wird es sehr schwierig, Code und Datentabellen so \u00fcber die Knoten zu verteilen, dass die Codestrecken ihre Tabellen auch auf dem gleichen Rechner finden, auf dem sie gerade ablaufen. Denn wenn der Code sich die Daten von einem Nachbarknoten holen muss, f\u00e4llt wieder Kommunikationsaufwand zwischen den Knoten an, was mit vergleichsweise hoher Latenz geschieht, wie wenn der Code gleich auf dem Applikationsserver verblieben w\u00e4re.<\/p>\n

Aus diesem Grunde ist eine Single-Node-Implementierung von Hana<\/span> f\u00fcr OLTP<\/span> auf jeden Fall gegen\u00fcber einer ScaleOut-Architektur vorzuziehen.<\/p>\n

Zugleich bestand SAP<\/span> bislang f\u00fcr Hana<\/span> als Single Node auf der Anforderung nach schnellen (internen) Log-Devices. Interne Log-Devices sind jedoch f\u00fcr gesch\u00e4ftskritische OLTP-Anwendungen<\/span> nicht akzeptabel, da ein Verlust des Rechners bzw. des Log-Devices gleichzeitig auch mit Datenverlust einhergeht.<\/p>\n

Gesch\u00e4ftskritische Daten, insbesondere die Logdaten, sollten immer an eine zweite Lokation geschrieben (gespiegelt) werden, sodass man im Notfall die Datenbank aus einer zweiten Quelle bis zur letzten abgeschlossenen Transaktion recovern kann.<\/p>\n

Fujitsu hat schon fr\u00fchzeitig die Hana<\/span>-Single-Node-Architektur in das FlexFrame-Betriebskonzept integriert und die Logdaten auf externe, spiegelbare Storage-Einheiten platziert. Dort stehen zwar nicht die bisher geforderten 100.000 IOps zur Verf\u00fcgung, aber aus technischer Sicht sind sie schon lange nicht mehr notwendig. Damit ist aber f\u00fcr Hana<\/span> der von FlexFrame bekannte sichere und flexible Betrieb f\u00fcr gesch\u00e4ftskritische Anwendungen mit den daf\u00fcr typischen hohen SLAs gew\u00e4hrleistet.<\/p>\n

Zwischenzeitlich r\u00fcckt auch SAP<\/span> von den hohen IO-Anforderungen f\u00fcr den Logwriter ab, um Hana<\/span> f\u00fcr eine flexible Integration in den RZ-Betrieb vorzubereiten.<\/p>\n

Effizientes Betriebskonzept und Schattendatenbanken<\/h3>\n

Die Forderung nach sicherer Datenhaltung und einem effizienten Betriebskonzept ist durch die Integration von Hana<\/span> in FlexFrame gel\u00f6st. Mit gespiegeltem Shared-Storage ist Hochverf\u00fcgbarkeit sowohl lokal als auch RZ-\u00fcbergreifend gew\u00e4hrleistet.<\/p>\n

Ein offener Punkt ist noch das Problem der Wiederanlaufzeiten. In Abh\u00e4ngigkeit von der Gr\u00f6\u00dfe der Datenbank kann ein vollst\u00e4ndiger Restart selbst bei hochperformanten IO-Kan\u00e4len \u00fcberm\u00e4\u00dfig lang dauern.<\/p>\n

Im Zuge der Weiterentwicklung von Hana<\/span> arbeitet SAP<\/span> am Konzept der Schattendatenbank, das Umschaltzeiten idealerweise minimieren w\u00fcrde, da Schattendatenbanken in der Regel nahezu synchron mit den prim\u00e4ren Daten mitlaufen.<\/p>\n

Nach Ausfall der prim\u00e4ren Datenbank w\u00fcrde die Aktivierung und vollst\u00e4ndige Recovery der Schattendatenbank nur wenige Minuten beanspruchen, bis der Betrieb wieder aufgenommen werden kann.<\/p>\n

Schattendatenbanken sind in Hana<\/span> heute noch nicht verf\u00fcgbar, aber als Vorstufe dazu bietet Hana<\/span> die Option der Systemreplication, die daf\u00fcr sorgt, dass die Logdaten synchron zu einer zweiten Instanz repliziert werden und dass in regelm\u00e4\u00dfigen Abst\u00e4nden dort der Columnstore (die Spaltenstruktur) von Hana<\/span> in den Hauptspeicher vorgeladen und aktualisiert wird.<\/p>\n

So entf\u00e4llt bei einem Failover<\/span> das komplette Nachladen des Column\u00adstores, da der gr\u00f6\u00dfte Teil schon vorgeladen ist. Damit lassen sich die Wiederanlaufzeiten in kritischen Umgebungen auf ein vern\u00fcnftiges Ma\u00df reduzieren.<\/p>\n

Die Empfehlung f\u00fcr Anwendungen, die nur minimale Ausfallzeiten erlauben, w\u00e4re, lokal zur produktiven Hana<\/span>-Instanz eine zweite Instanz mit Sytemreplication zu betreiben und f\u00fcr den Desaster-Fall die produktive Persistenz<\/span> in ein zweites RZ zu spiegeln.<\/p>\n

Da die Instanz mit der Systemreplication die Rechnerressourcen nur zu einem kleinen Teil nutzt, k\u00f6nnten parallel dazu auf dem Rechnerknoten noch andere, nicht produktive Systeme gefahren werden.<\/p>\n

ScaleOut<\/h3>\n

Bleibt noch zu diskutieren, wie eine ScaleOut-Architektur gegen\u00fcber einem Single Node zu bewerten ist. Im Grunde gilt sowohl f\u00fcr OLTP<\/span> als auch f\u00fcr OLAP<\/span>, dass bei gleicher Datenbankgr\u00f6\u00dfe der Single Node, sofern von den RAM<\/span>-Kapazit\u00e4ten m\u00f6glich, die bevorzugte Alternative ist.<\/p>\n

Das hat im Wesentlichen zwei Gr\u00fcnde. Der erste wurde schon bei der Diskussion im Zusammenhang mit OLTP<\/span> diskutiert. Die Kommunikation zwischen den Datenbankknoten kostet vergleichsweise viel Zeit und beeinflusst die Performance negativ.<\/p>\n

Speziell bei OLAP-Anwendungen<\/span> ist das Problem der geschickten Zuordnung von Codestrecken zu den Daten nicht so relevant wie bei OLTP<\/span>, da Queries sich von ihrer mathematischen Struktur in der Regel gut verteilt abarbeiten lassen. Trotzdem bleibt aber das Problem der Latenz, weil die Teilergebnisse einer Query schlie\u00dflich auf einem Knoten zusammengef\u00fchrt und in ein Endergebnis konsolidiert werden m\u00fcssen.<\/p>\n

Ein zweites Problem stellt sich beispielsweise bei Joins, die \u00fcber Tabellen gehen, die \u00fcber mehrere Knoten verteilt sind. Bevor der Join ausgef\u00fchrt werden kann, m\u00fcssen die Daten der beteiligten Tabellen auf den Knoten \u00fcbertragen und zwischengespeichert werden, auf dem der Join durchgef\u00fchrt wird. Das kostet einerseits Zeit und andererseits zus\u00e4tzlich Hauptspeicher.<\/p>\n

Bei einem Single Node entf\u00e4llt die Daten\u00fcbertragung und Zwischenspeicherung, da ja alle Daten lokal sind. Damit ergibt sich als Empfehlung, dass Anwendungen so lange wie m\u00f6glich mit einer Single-Node-Instanz bedient werden sollten.<\/p>\n

Die aktuellen Entwicklungen in der Hardwaretechnik kommen diesem Ansatz entgegen. Mit der im Februar 2014 offiziell verf\u00fcgbaren Hardware wird es m\u00f6glich sein, bis zu 12 TB RAM<\/span> in einer Maschine zu installieren.<\/p>\n

SAP<\/span> l\u00e4sst inzwischen verlauten, dass sie mit der neuen Hardware f\u00fcr OLTP-Anwendungen bis zu 6 TB auf einem Rechner f\u00fcr produktive Systeme unterst\u00fctzen wird und f\u00fcr OLAP<\/span> bis zu 2 TB bei acht best\u00fcckten Sockeln gegen\u00fcber 1 TB in der Vergangenheit.<\/p>\n

Das klingt plausibel, da sich die CPU-Leistung der neuen Prozessorgeneration etwa verdoppelt hat. Allerdings hat sich auch die Performance der Hana<\/span>–Technologie<\/span> in den vergangenen Jahren st\u00e4ndig und signifikant verbessert, sodass man sich aus technischer Sicht f\u00fcr die Zukunft auch noch gr\u00f6\u00dferen RAM<\/span>-Ausbau als 2 TB f\u00fcr einen Knoten in einer ScaleOut-Architektur vorstellen kann.<\/p>\n

\"https:\/\/e3mag.com\/partners\/fujitsu\/\"<\/a><\/p>\n","protected":false},"excerpt":{"rendered":"

SAP entwickelt mit Hana seit einigen Jahren eine neue technische Basis f\u00fcr ihre Anwendungen. Die Motivation daf\u00fcr mag darin begr\u00fcndet sein, dass mit nicht fl\u00fcchtigem Hauptspeicher (NVRAM \u2013 non volatile RAM) ein technologischer Paradigmenwechsel bevorsteht.<\/p>\n","protected":false},"author":46,"featured_media":1125,"comment_status":"open","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"_acf_changed":false,"pmpro_default_level":"","footnotes":""},"categories":[5],"tags":[424,428,430],"coauthors":[24296],"class_list":["post-440","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-it-management","tag-in-memory-technologie","tag-olap","tag-oltp","pmpro-has-access"],"acf":[],"featured_image_urls_v2":{"full":["https:\/\/e3mag.com\/wp-content\/uploads\/2014\/02\/shutterstock_395220502.jpg",1000,667,false],"thumbnail":["https:\/\/e3mag.com\/wp-content\/uploads\/2014\/02\/shutterstock_395220502-150x150.jpg",150,150,true],"medium":["https:\/\/e3mag.com\/wp-content\/uploads\/2014\/02\/shutterstock_395220502.jpg",400,267,false],"medium_large":["https:\/\/e3mag.com\/wp-content\/uploads\/2014\/02\/shutterstock_395220502-768x512.jpg",768,512,true],"large":["https:\/\/e3mag.com\/wp-content\/uploads\/2014\/02\/shutterstock_395220502.jpg",1000,667,false],"image-100":["https:\/\/e3mag.com\/wp-content\/uploads\/2014\/02\/shutterstock_395220502-100x67.jpg",100,67,true],"image-480":["https:\/\/e3mag.com\/wp-content\/uploads\/2014\/02\/shutterstock_395220502-480x320.jpg",480,320,true],"image-640":["https:\/\/e3mag.com\/wp-content\/uploads\/2014\/02\/shutterstock_395220502-640x427.jpg",640,427,true],"image-720":["https:\/\/e3mag.com\/wp-content\/uploads\/2014\/02\/shutterstock_395220502-720x480.jpg",720,480,true],"image-960":["https:\/\/e3mag.com\/wp-content\/uploads\/2014\/02\/shutterstock_395220502-960x640.jpg",960,640,true],"image-1168":["https:\/\/e3mag.com\/wp-content\/uploads\/2014\/02\/shutterstock_395220502.jpg",1000,667,false],"image-1440":["https:\/\/e3mag.com\/wp-content\/uploads\/2014\/02\/shutterstock_395220502.jpg",1000,667,false],"image-1920":["https:\/\/e3mag.com\/wp-content\/uploads\/2014\/02\/shutterstock_395220502.jpg",1000,667,false],"1536x1536":["https:\/\/e3mag.com\/wp-content\/uploads\/2014\/02\/shutterstock_395220502.jpg",1000,667,false],"2048x2048":["https:\/\/e3mag.com\/wp-content\/uploads\/2014\/02\/shutterstock_395220502.jpg",1000,667,false],"trp-custom-language-flag":["https:\/\/e3mag.com\/wp-content\/uploads\/2014\/02\/shutterstock_395220502.jpg",18,12,false],"bricks_large_16x9":["https:\/\/e3mag.com\/wp-content\/uploads\/2014\/02\/shutterstock_395220502.jpg",1000,667,false],"bricks_large":["https:\/\/e3mag.com\/wp-content\/uploads\/2014\/02\/shutterstock_395220502.jpg",1000,667,false],"bricks_large_square":["https:\/\/e3mag.com\/wp-content\/uploads\/2014\/02\/shutterstock_395220502.jpg",1000,667,false],"bricks_medium":["https:\/\/e3mag.com\/wp-content\/uploads\/2014\/02\/shutterstock_395220502.jpg",600,400,false],"bricks_medium_square":["https:\/\/e3mag.com\/wp-content\/uploads\/2014\/02\/shutterstock_395220502.jpg",600,400,false],"profile_24":["https:\/\/e3mag.com\/wp-content\/uploads\/2014\/02\/shutterstock_395220502-24x24.jpg",24,24,true],"profile_48":["https:\/\/e3mag.com\/wp-content\/uploads\/2014\/02\/shutterstock_395220502-48x48.jpg",48,48,true],"profile_96":["https:\/\/e3mag.com\/wp-content\/uploads\/2014\/02\/shutterstock_395220502-96x96.jpg",96,96,true],"profile_150":["https:\/\/e3mag.com\/wp-content\/uploads\/2014\/02\/shutterstock_395220502-150x150.jpg",150,150,true],"profile_300":["https:\/\/e3mag.com\/wp-content\/uploads\/2014\/02\/shutterstock_395220502-300x300.jpg",300,300,true]},"post_excerpt_stackable_v2":"

SAP entwickelt mit Hana seit einigen Jahren eine neue technische Basis f\u00fcr ihre Anwendungen. Die Motivation daf\u00fcr mag darin begr\u00fcndet sein, dass mit nicht fl\u00fcchtigem Hauptspeicher (NVRAM \u2013 non volatile RAM) ein technologischer Paradigmenwechsel bevorsteht.<\/p>\n","category_list_v2":"IT-Management<\/a>","author_info_v2":{"name":"J\u00fcrgen Meynert, Fujitsu","url":"https:\/\/e3mag.com\/de\/author\/juergen-meynert\/"},"comments_num_v2":"0 comments","_links":{"self":[{"href":"https:\/\/e3mag.com\/de\/wp-json\/wp\/v2\/posts\/440","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\/46"}],"replies":[{"embeddable":true,"href":"https:\/\/e3mag.com\/de\/wp-json\/wp\/v2\/comments?post=440"}],"version-history":[{"count":0,"href":"https:\/\/e3mag.com\/de\/wp-json\/wp\/v2\/posts\/440\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/e3mag.com\/de\/wp-json\/wp\/v2\/media\/1125"}],"wp:attachment":[{"href":"https:\/\/e3mag.com\/de\/wp-json\/wp\/v2\/media?parent=440"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/e3mag.com\/de\/wp-json\/wp\/v2\/categories?post=440"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/e3mag.com\/de\/wp-json\/wp\/v2\/tags?post=440"},{"taxonomy":"author","embeddable":true,"href":"https:\/\/e3mag.com\/de\/wp-json\/wp\/v2\/coauthors?post=440"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}