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.

Kommentare werden geladen....

Kommentar zu diesem Artikel abgeben

Der Kommentar wird durch einen Redakteur geprüft und in Kürze freigeschaltet.

Anonym mitdiskutieren oder einloggen Anmelden

Avatar
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.
  1. Avatar
    Avatar
    Bearbeitet von am
    Bearbeitet von am
    1. Avatar
      Avatar
      Bearbeitet von am
      Bearbeitet von am

Kommentare werden geladen....

Kommentar melden

Melden Sie diesen Kommentar, wenn dieser nicht den Richtlinien entspricht.

Kommentar Freigeben

Der untenstehende Text wird an den Kommentator gesendet, falls dieser eine Email-hinterlegt hat.

Freigabe entfernen

Der untenstehende Text wird an den Kommentator gesendet, falls dieser eine Email-hinterlegt hat.

copyright

Dieser Beitrag ist urheberrechtlich geschützt. Sie wollen ihn für Ihre Zwecke verwenden? Infos finden Sie unter www.mycontentfactory.de (ID: 42593811 / Infrastruktur)