Der Zugriff auf RAM-Speicher ist bis zu eine Million Mal schneller als bei herkömmlichen Festplatten und selbst beim Datendurchsatz sind es immerhin noch knapp Faktor 100. Die Preise für Arbeitsspeicher sinken pro Jahr durchschnittlich 30 Prozent. Gleichzeitig werden die Prozessoren für fast alle Architekturen immer leistungsfähiger. Trotzdem sind die meisten Zugriffsverfahren in Datenbanken auf dem algorithmischen Stand der 80er und 90er Jahre: Sie sind auf ein möglichst effizientes Zusammenspiel von Festplatte und RAM ausgerichtet. Doch ist das noch zeitgemäß?

SAP HANA

Um diese Altlasten abzuwerfen, und natürlich um durch technischen Fortschritt den lukrativen Markt der Datenbankmanagementsysteme (DBMS) aufzurollen, präsentierten Entwickler des Hasso Plattner Instituts und der Universität Stanford 2008 erstmals Beispiele ihrer relationalen In-Memory-Datenbank für Real-Time-Analysen. Zunächst noch ironisch unter dem Titel "Hassos New Architecture" geführt, entstand daraus zwei Jahre später SAP HANA, die "High-Performance Analytic Appliance".
Ziel war die Einsatzfähigkeit einer einzigen Plattform, ja sogar eines einzigen Datenbestandes - sowohl für den Online Einsatz (Online Transaction Processing = OLTP) als auch für analytische Zwecke (Online Analytical Processing = OLAP). Die Entwickler wollten die bisher harte und aufwändige Trennung zwischen operativen und Business-Intelligence-Aufgaben eliminieren und damit einen außerordentlichen Produktivitätsvorteil für den Einsatz dieser Appliance schaffen. Dennoch kam HANA 2011 zunächst "nur" für das SAP-Business-Warehouse auf den Markt. Seit Mitte 2013 war es dann auch für operative SAP-Module verfügbar.

HANA ist konsequent darauf ausgelegt, alle Daten im Hauptspeicher zu halten. Die Datenbank nutzt dafür sehr intensiv CPU-Caches, organisiert die Daten vorwiegend spaltenorientiert - statt wie bisher üblich in Zeilen. Zudem komprimiert sie die Daten im RAM und auf Festplatte und parallelisiert Datenoperationen innerhalb der CPU-Cores bei Multicore-Systemen und sogar über mehrere Rechenknoten hinweg.

Und plötzlich stellte man bestehende IT-Systeme infrage: Werden analytische Abfragen jetzt auch eine Million Mal schneller und vielleicht sogar online verfügbar? Sollen wir uns jetzt von Data Warehouses und älteren DBMS trennen? Ist der durch SAP aufgebaute Vorsprung noch einholbar? Der Druck auf die traditionellen Datenbank-Anbieter wie IBM wuchs und schon bald bereicherten sie mit eigenen In-Memory-Lösungen den Markt. Bis heute gleicht natürlich kein Ansatz dem anderen.

IBM DB2 BLU Acceleration

Im April 2013 wurde das In-Memory-Funktionspaket "BLU Acceleration" als Teil der Advanced-Editions der IBM DB2-Datenbank veröffentlicht. Im Prinzip kommen dabei dieselben Techniken wie bei HANA zum Einsatz. Allerdings integriert IBM diese einfach in die eigene Technik und erlaubt die Koexistenz herkömmlicher und Memory-optimierter Tabellen innerhalb derselben Datenbank. Diese Tabellen können von einem Format in das andere umgewandelt werden und sollen nach Aussage von IBM gut optimierbare Abfragen um den Faktor 8-40 beschleunigen. Darüber hinaus werden durch Komprimierung sowohl im RAM als auch auf Festplatte bis zu 90 Prozent Speicherplatz eingespart. Im Gegensatz zu HANA ist BLU Acceleration heute aber noch klar auf analytischen Workload ausgerichtet. Im Produktiveinsatz sollte OLTP also weiterhin auf zeilenorientierten Tabellen durchgeführt werden.

Microsoft SQL Server In-Memory Database Features

Auch der Microsoft-SQL-Server folgte dem Trend: Schon mit dem SQL-Server-Release 2012 konnten für komplexe Abfragen auf Tabellen spezielle spaltenorientierte, komprimierte In-Memory-Indizes erzeugt werden. Damit wurde es möglich, die Analytik spürbar zu beschleunigen. Die Indizes werden jedoch zusätzlich zur normalen Tabelle erstellt und müssen nach jeder Änderung manuell neu erstellt werden - mit dem neuen SQL-Server 2014 sind sie hingegen aktualisierbar.

In Version 2014 kam mit "In-Memory OLTP" eine neue Lösung ausschließlich für die Beschleunigung von Transaktionen auf operativen Systemen wie ERPs oder CRMs hinzu. Tabellen dieser Art müssen dabei komplett im Hauptspeicher gehalten werden. Sie ermöglichen für transaktionsintensive Anwendungsfälle dabei deutliche Performancezuwächse. Nach Angaben von Microsoft liegen diese je nach Anwendungsfall bei Faktor 100 oder sogar noch höher. Auch hier existieren natürlich In-Memory Tabellen friedlich neben herkömmlichen Tabellen in der gleichen Datenbank und können fast beliebig miteinander kombiniert werden.
Damit hat Microsoft zwei getrennte Lösungen für OLTP und Analysen im Programm.

Oracle Database In-Memory Option

Im Juli 2014 zog endlich auch Oracle nach und stattete seine 12c-Datenbank mit einer kostenpflichtigen In-Memory-Zusatzoption aus. Diese besteht im Wesentlichen aus einem "In-Memory Column-Store" zur Beschleunigung analytischer Abfragen, ist aber aufgrund ihrer Bauart teilweise auch für OLTP-Anwendungsfälle einsetzbar.

Die Oracle-Datenbank funktioniert ähnlich wie IBM BLU Acceleration und soll je nach Anwendungsfall Performancesteigerungen von Faktor 10 bis 100 erreichen. Im Gegensatz zu anderen Lösungen schreibt die Oracle Datenbank jedoch keinerlei In-Memory-Daten auf Festplatte. Spaltenorientierte Datenhaltung, automatische Indexierung, Kompression - sämtliche Operationen laufen ausschließlich im Hauptspeicher ab. Alle Festplatten-relevanten Operationen werden dabei mit den althergebrachten Mitteln durchgeführt und redundant, aber konsistent für die In-Memory-Strukturen mitgezogen. Daraus ergeben sich einerseits Nachteile wegen redundanter Ressourcenbelastung sowie der fehlenden Kompression auf Festplatte.
Andererseits gibt aber auch einen besonderen Vorteil dieser Vorgehensweise: "In-Memory" ist bei Oracle lediglich ein Schalter, mit dem sich online Tabellen oder auch nur Teile von Tabellen In-Memory optimieren lassen. Es müssen also keine Daten migriert werden, um von den neuen Möglichkeiten zu profitieren. Dies macht einen Test also besonders einfach.

Gemeinsamkeiten und Unterschiede

Die Stoßrichtung der "Großen Drei" ist klar: Der Wechsel auf eine andere, separate In-Memory-Plattform wie HANA soll künftig nicht mehr nötig sein. Im einfachsten Fall braucht der Administrator in bestehenden Datenbanken nur einen Schalter umlegen, um alle Applikationen damit um ein Vielfaches zu beschleunigen. Aber ist das wirklich realistisch? Es fällt schnell auf, dass alle neuen In-Memory-Datenbanken ähnliche Mechanismen nutzen. Dazu gehören die spaltenorientierte Datenhaltung, automatisch erzeugte und hauptspeicheroptimierte Datenstrukturen sowie eine intensive Nutzung von CPU-Features und die Komprimierung von Daten im Hauptspeicher und/oder Festplatte.

Es gibt aber auch erkennbare Unterschiede bei den einzelnen Lösungen. Da ist zunächst die Frage einer Limitierung der Datenbankgröße durch den verfügbaren Hauptspeicher. SAP HANA und die SQL Server OLTP Lösung müssen In-Memory Daten spätestens bei der ersten Abfrage vollständig in den Hauptspeicher laden, während Oracle und IBM DB2 dies nicht erfordern und somit die Arbeit mit größeren Datenmengen vereinfacht. Hinzu kommt, dass bei Oracle komprimierte Daten nicht in komprimierter Form auf Storage-Datenträger geschrieben werden. Sie müssen nach einem Restart der Datenbank wieder neu aufgebaut werden. Dieser Ansatz bietet zwar mehr Flexibilität bei Administration und ein breiteres Einsatzspektrum, spart aber keinen Platz auf Datenträgern und erzeugt Redundanzen in der Verarbeitung.

Und dann ist da noch die Art der nutzbaren Applikationsarten: Microsoft offeriert spezielle, OLTP-optimierte Tabellentypen, IBM hingegen Tabellentypen für rein analytischen Workload. SAP HANA unterscheidet mitunter nach Bedarf zwischen zeilen- und spaltenorientierter Datenhaltung und unterstützt beide Arten von Workload. Oracle platziert seine Lösung hauptsächlich für den analytischen Bereich, verspricht aber auch Verbesserungen für OLTP-Applikationen, weil weniger Indexe auf Tabellen nötig sind und somit der DML-Durchsatz verbessert werden soll.

Welcher In-Memory-Ansatz ist der Richtige?

Für Unternehmen stellen sich im Grunde zwei Fragen: Welcher In-Memory-Ansatz ist der richtige und welche Lösung soll ich kaufen?

Mögliche Antworten darauf lassen sich jedoch nicht verallgemeinern sondern sind von individuellen Einsatzszenarien abhängig. Unternehmen sollten in jedem Fall alle technischen, organisatorischen und kostenrelevanten Besonderheiten differenziert betrachten - sowohl für eine Neuentwicklung als auch bei einer Anwendungsmigration. Sie sollten wissen, dass nur wenige Anwendungsfälle ohne weitere Anpassungen profitieren werden - und sie in entsprechende Leistungen investieren müssen. Darüber hinaus werden die Performancevorteile nicht bei allen Anwendungen möglich sein und können diese sogar verlangsamen. In einigen Fällen wird man auch mit funktionalen Einschränkungen leben müssen.

Vor der Einführung einer In-Memory-Datenbank sollte eine gründliche Evaluation stattfinden sowohl beim Wechsel auf eine neue Plattform als auch bei einer geplanten Migration. Auch im Falle einer vermeintlich einfachen Umstellung auf die In-Memory-Technik innerhalb des vertrauten RDBMS ist es ratsam, die jeweils geeigneten Daten zu identifizieren und alle Anwendungsfälle ausführlich zu überprüfen. Dies kann entweder mit eigenen Teams oder durch einen externen Dienstleister geschehen.

Lohnt sich die In-Memory-Technologie?

Für IT-Entscheider stellt sich am Ende die Frage, ob sich ein Umstieg auf In-Memory-Technologie lohnt, auch oder gerade wenn es sich in manchen Fällen nur um ein Upgrade der bestehenden Systeme handelt. Fakt ist, dass die Lösungen in bestimmten Anwendungsszenarien sowohl im OLTP als auch im analytischen Bereich deutlich schneller und effizienter arbeiten als bisher übliche Techniken. Allerdings lassen sich nur sehr abgegrenzte Prozesse um die oben erwähnten Faktoren beschleunigen - im Durchschnitt wird der Performancegewinn deutlich geringer ausfallen.

Doch durch die In-Memory-Technologie lassen sich in vielen Fällen Kosten für Hardware und Lizenzen einsparen. Diese Kostensenkungen werden jedoch erst nach der Umsetzung sichtbar. Denn der Umstieg auf die neue Technologie ist fast immer mit Applikationsanpassungen verbunden - die in die Gesamtkostenrechnung einfließen werden.

In-Memory-Datenbanken sind eine echte Bereicherung der Datenbankwelt. Aber sie eignen sich nicht für jeden Anwendungsfall und sollten vor der sprichwörtlichen Bindung an eine neue Technologie umfassend geprüft werden. (bw)