Wo ist In-memory tatsächlich sinnvoll?

Allen voran hat SAP mit sehr viel Aufwand versucht, die eigene In-memory-Datenbank Hana als eine Revolution unter den Datenbanken zu positionieren.

In der Zwischenzeit gibt es eine Reihe von In-memory-Datenbank-Lösungen für SAP-Anwendungen, welche sich jedoch alle unterscheiden. Deshalb lohnt wie immer ein tieferer Blick hinter die Kulissen, bevor sich ein Unternehmen für eine dieser Lösungen entscheidet.

Unterschiede bei der Implementierung, bei der Nutzung und den tatsächlichen Vorteilen sind neben den Anschaffungskosten für Hard- und Software sehr deutlich.

Bevor sich ein Unternehmen mit In-memory in einer Datenbank beschäftigt, steht zunächst die Frage: Was will ich damit erreichen?

Es ist eine falsche Erwartung, dass allein eine In-memory-Technologie, von welchem Hersteller diese auch angewendet wird, eine grundsätzliche Verbesserung der Performance aller Prozesse aus analytischen Abfragen oder auch schreibenden Transaktionen in der Datenbank mit sich bringt. Dies ist nicht zutreffend.

Viele Anforderungen – In-memory allein löst sie nicht

Nicht nur In-memory zeichnet eine gute Datenbank aus. Lösungen mit einem Entweder-oder-Ansatz lösen nicht die übergreifenden Anforderungen an ein Datenbankmanagement-System, sie liefern die Lösung einzelner spezifischer analytischer Anforderungen.

Ein Formel-1-Auto wurde bei der Rallye Dakar noch nicht gesehen. Eine Datenbank zeichnet sich dadurch aus, mit allen Anforderungen an Performance, Hochverfügbarkeit, Stabilität, Sicherheit bestens umgehen zu können, und dies bei effektivster Ausnutzung vorhandener Ressourcen im RAM, CPU, Storage und Netzwerk.

Gerade in den Anwendungen der SAP Business Suite sind in aller Häufigkeit Einzelsatz-Zugriffe zu verzeichnen. Ist das Datenbanksystem richtig eingestellt, kann In-memory kaum Verbesserungen in der Performance bei diesen Transaktionen erreichen.

Im Gegenteil können Einzelsatz-Zugriffe mit aufwändigen Verknüpfungen über mehrere Tabellen aufgelöst in einer spaltenorientierten In-memory-Ablage deutlich aufwändiger sein als ein Einzelsatz-Zugriff auf einen einzigen Datenbankblock im Memory (Buffer Cache) in einer zeilenorientierten Ablage.

In einem SAP-BW-System erfolgen in der Regel analytische Abfragen, daher erfolgt hier sehr selten eine Einzelsatzverarbeitung. Gerade für diesen Anwendungsfall kann die In-memory-Technologie mit immer größer werdenden Datenvolumen eine entscheidende Verbesserung bringen.

Was ist nun das Optimum?

Entweder alle Daten zu 100 Prozent im Memory oder nur ausgewählte Objekte? Entscheidet ein Datenbankhersteller mit einer reinen In-memory-Datenbank oder entscheidet der Datenbankadministrator, wo In-memory sinnvoll ist?

Erreichen wir das Optimum für alle SAP-Anwendungen also für SAP BW, SAP ERP, SAP CRM, SAP HR, wenn wir alle Daten immer permanent im Memory halten müssen?

Alle Daten im Memory zu halten ist immer noch mit hohen Investitionskosten in eine entsprechend ausgestattete Hardware mit ausreichend RAM und CPU für die Produktiv- als auch Ausfall absichernde Umgebung verbunden. Sinnvoller ist doch eine Lösung, welche alle Möglichkeiten einer performanten Ausführung für alle lesenden und schreibenden Transaktionen gestattet.

Alle namhaften Datenbankhersteller haben sich in der Vergangenheit bei der Entwicklung ihrer Datenbanken für einen zeilenorientierten Ansatz entschieden, weil gerade dieser für schreibende Transaktionen der optimale Ansatz ist.

Heute sehen wir enorm gewachsene Datenbanken. Diese Daten müssen also zunächst durch schreibende Transaktionen in den Datenbanken angelegt werden. Hierbei kann In-memory kaum Unterstützung liefern.

Die Vorteile der In-memory-Technologie liegen eindeutig im analytischen Umfeld beim Lesen und Aggregieren von sehr großen Datenmengen.

Es sind also spezielle Anwendungsfälle im analytischen Umfeld, wo In-memory-Technologie tatsächlich deutliche Vorteile in der Performance erreichen kann. Daraus ableitend ist ein Mix aus klassischem Datenbankdesign mit konventioneller zeilenorientierter Ablage und der neuen spaltenorientierten In-memory-Technologie eine optimale Vorgehensweise.

Wer sollte besser über performante Zugriffswege in seiner Datenbank informiert sein, wenn nicht die Datenbank selbst? Warum soll ein Datenbanksystem alle Daten in einer spaltenorientierten In-memory-Architektur ablegen, wenn die Datenbank auf Basis ihrer Statistiken Informationen für einen besseren Zugriff über einen zeilenorientierten Datenbankblock ermittelt?

Die Einführung von Partitionen mit der physikalischen Aufteilung und Verkleinerung von Tabellen zum Zweck der Aufrechterhaltung der Performance ist im SAP-BW-Standard, in SAP-ERP-Systemen dagegen sehr begrenzt und nur unter hohem Aufwand umsetzbar.

Deshalb sind auch Scale-out-Architekturen mit SAP Hana für die Anwendungen der SAP Business Suite nur schwer zu realisieren. Vorteile einer massiv parallelen Verarbeitung einer einzelnen Transaktion durch In-memory über ein scale-out können hier kaum genutzt werden.

Der Ansatz der Oracle-Database-In-memory-Technologie ist anders. Dieser verbindet beide Welten optimal miteinander, den klassisch zeilenorientierten Ansatz für Einzelsatzverarbeitung als auch parallel die spaltenorientierte In-memory-Architektur für extrem beschleunigte analytische Abfragen.

Die Datenbank erhält damit eine weitere Option für den Datenbank Optimizer, um Abfragen aus dem zeilenorientierten Buffer Cache oder dem spaltenorientierten In-memory Store in höchster Performance für identische Tabellen auszuführen.

Damit ist Oracle der einzige Datenbankhersteller, welcher transparent für die Applikation konventionelle Datenbanktechnologien mit modernster In-memory-Technologie verknüpft.

Daraus können sich sehr viele Vorteile ableiten. Die Datenbank benötigt wesentlich weniger zusätzlichen Memory gegenüber einer 100-Prozent-In-memory-Datenbank, da nur ausgewählte Tabellen zusätzlich mit einer spaltenorientierten Ablage im Memory definiert werden.

Analytische Anforderungen über größere Datenmengen können nun extrem beschleunigt werden. Eigens angelegte Indizes zur Beschleunigung analytischer Abfragen können wieder entfernt werden, wodurch nebenbei die OLTP-Performance auf diesen Objekten verbessert werden kann.

Eine Migration von Tabellen in dieses spaltenorientierte Format ist nicht notwendig. Alle bisher genutzten Funktionalitäten der Oracle-Datenbank wie Komprimierung, Verschlüsselung, Real Application Clusters oder Backup/Recovery können unverändert weiter betrieben werden.

Die Oracle-Datenbank ist auf allen gängigen Betriebssystemen lauffähig, durch die In-memory-Lösung ändert sich daran nichts.

Die Oracle-Datenbank kennt kein Entweder-oder, In-memory oder kein In-memory, sondern ein Sowohl-als-auch. Schreibende Transaktionen als auch lesende Transaktionen auf den gleichen Tabellen in einer einzigen Datenbank sind nun mit traditionellen Methoden als auch der modernen In-memory-Technologie parallel möglich.

Dies ist die Basis für die 2015 erfolgte Zertifizierung der Oracle-Database-In-memory-Technologie für alle auf SAP NetWeaver basierenden Applikationen. Damit ist Oracle neben Hana einziger Hersteller mit einer In-memory-Lösung, welche für OLTP und OLAP in SAP eingesetzt werden kann.

Eine Vielzahl an Unternehmen konnte hierdurch im SAP BW und SAP CRM bestehende Anforderungen an die Performance in wenigen Tagen sehr erfolgreich umsetzen. Eine wesentlich verbesserte Verhandlungsposition für zukünftige Hardware-Investitionen dank Anbietervielfalt und Betriebssystem sowie weniger benötigtem RAM zeichnen Oracle Database In-memory ebenfalls aus.

Weiterführende technologische Entwicklungen auf Basis der Oracle-­Database-In-memory-Technologie werden jetzt mit der Umsetzung von „Flat Cubes“ als neues Design der InfoCubes im SAP NetWeaver BW 7.40 möglich. Hierdurch wird neben einer deutlichen Verbesserung der Performance für Analysen ohne vorherige aufwändige Bildung von Aggregaten die Ladeperformance wegen fehlender Indizes und Dimensionstabellen deutlich verbessert. Hierfür werden Pilotkunden gesucht.