In-Memory-Technik leicht erklärt

Die technischen SAP HANA-Betriebsmodi

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

Die Reorganisation von HANA

Da die spaltenbasierte interne Architektur von HANA vergleichbar ist mit zu einhundert Prozent indizierten Datenbeständen, fallen im Vergleich zu anderen Datenbanken bei HANA häufiger interne Reorganisationen an, die dann auch auf die Persistenz abgebildet werden. Damit erhöht sich die Anforderung des Datawriter an den Schreibdurchsatz.

Restarts stellen noch ein Problem dar.
Restarts stellen noch ein Problem dar. (Bild: joannis kounadeas/Fotolia.com)

Dagegen sollte man erwarten, dass die Anforderungen an den IO-Durchsatz beim Lesen von Daten eher gering sind, da HANA-Daten eigentlich im RAM lesen sollte. Das mag für den Normalbetrieb richtig sein, stimmt aber nicht für den Fall, dass HANA hochgefahren wird.

Nimmt man an, dass 1 Terabyte Daten in den Hauptspeicher gelesen werden müssen, dauert das bei einem Durchsatz von 1 Gigabit pro Sekunde noch immerhin 20 Minuten. Das wäre kein Problem, wenn Restarts der Datenbank die Ausnahme wären.

Da HANA aktuell aber ständig mit dem Ziel weiterentwickelt wird, eines Tages NVRAM optimal zu nutzen, sind in regelmäßigen Abständen Updates einzuspielen, die oft mit einem Restart der Datenbank einhergehen. Daher erklärt sich die Anforderung von SAP, die Persistenz auch mit hohen Durchsatzraten für das Lesen im Datenbereich auszustatten.

OLAP versus OLTP

Auch wenn, wie oben erwähnt, der Haupteinsatzbereich von IMDBs tendenziell im OLAP liegt, geht SAP bereits den Weg, auch OLTP-Anwendungen auf HANA zu propagieren (Suite on HANA). Technisch ist es möglich, für OLTP-Systeme sowohl Single Nodes als auch Scale­Out-Architekturen einzusetzen. Aus Sicht der Performance ergibt sich jedoch ein signifikanter Unterschied.

Wie bereits erläutert, kann sich für OLTP-Anwendungen ein Performance-Vorteil auf HANA ergeben, wenn Codestrecken in die Datenbank verlagert werden, um zeitaufwändige Kommunikation zwischen Applikation und Datenbank zu vermeiden. Wenn HANA aber in einer Scale-Out-Landschaft über mehrere Rechnerknoten verteilt ist, wird es sehr schwierig, Code und Datentabellen so über die Knoten zu verteilen, dass die Codestrecken ihre Tabellen auch auf dem gleichen Rechner finden, auf dem sie gerade ablaufen.

Was meinen Sie zu diesem Thema?

Schreiben Sie uns hier Ihre Meinung ...
(nicht registrierter User)

Zur Wahrung unserer Interessen speichern wir zusätzlich zu den o.g. Informationen die IP-Adresse. Dies dient ausschließlich dem Zweck, dass Sie als Urheber des Kommentars identifiziert werden können. Rechtliche Grundlage ist die Wahrung berechtigter Interessen gem. Art 6 Abs 1 lit. f) DSGVO.
Kommentar abschicken
copyright

Dieser Beitrag ist urheberrechtlich geschützt. Sie wollen ihn für Ihre Zwecke verwenden? Kontaktieren Sie uns über: support.vogel.de/ (ID: 42593811 / Software)