Die technischen SAP HANA-Betriebsmodi

In-Memory-Technik leicht erklärt Die technischen SAP HANA-Betriebsmodi

20.03.2014Autor / Redakteur: Jürgen Meynert / Ulrike Ostler

SAP entwickelt mit „HANA“ seit einigen Jahren eine neue technische Basis für ihre Anwendungen. Die Motivation dafür mag darin begründet sein, dass mit nicht flüchtigem Hauptspeicher (NVRAM – non volatile RAM) ein technologischer Paradigmenwechsel bevorsteht.

Firma zum Thema

Die In-Memory-Datenbank SAP HANA kann Auswertungen um ein Vielfaches beschleunigen. Sie katapultiert Anwendungen direkt in einen Paradigmenwechsel.
(Bild: fotomek/Fotolia.com)

Die In-Memory-Technologie erfordert grundsätzlich neue Programmiermodelle, die sich nicht durch Anpassungen vorhandener Software realisieren lassen, sondern radikal neue Ansätze erfordern. Damit steht nicht nur in der Hardware, sondern auch in der Software ein Paradigmenwechsel bevor.

Im Zuge des technischen Fortschritts hat die Zugriffsgeschwindigkeit von Storage-Systemen nicht Schritt halten können mit den Zuwächsen bei der Prozessorgeschwindigkeit. Bei CPU-Taktraten von 3 Gigahertz, was Zykluszeiten von 0,3 Nanosekunden entspricht, dauern Verarbeitungsschritte im Prozessor in der Größenordnung von Nanosekunden (ns), während Zugriffe auf externen Storage sich im Bereich von Millisekunden (ms) bewegen. Das ist ein Missverhältnis von 1 zu 1.000.000!

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-Devices, da auch schon das Licht und damit auch die Daten im ns-Bereich nur eine sehr beschränkte Distanz zurücklegen können (< 30 cm in 1 ns). Somit kann schneller Datenzugriff letztlich nur dadurch erzielt werden, dass die Daten auch nahe beim Prozessor bereitgehalten werden: im RAM, oder besser noch im Cache.

Code to Data

Eine weitere Beschleunigung der Verarbeitungsgeschwindigkeit lässt sich dadurch erzielen, dass Anwendungscode direkt in der Datenbank ausgeführt wird, wodurch vergleichsweise hohe Latenzen bei der Kommunikation zwischen Applikation und Datenbank vermieden werden. Wurden also bislang Daten durch die Datenbank zur Anwendung geschleust, wird zukünftig Anwendungscode zu den Daten gebracht.

Damit lässt sich der Paradigmenwechsel am anschaulichsten beschreiben: Statt „Data to Code“ heißt es zukünftig „Code to Data“.

(ID:42593811)