Vor wenigen Jahren galten In-Memory-Datenbanken als Exoten und genossen eine Sonderstellung. Sie wurden im Fall von Oracle Times Ten und IBM SolidDB als Beschleunigungs-Caches für herkömmliche relationale Datenbanken (RDBMS) eingesetzt; im Fall von Exasol als spezialisierte, abfrageoptimierte Data-Warehouse-/Data-Mart-Lösung oder als kleine Open-Source- und Public-Domain-Implementierungen für jedermann (Beispiele: HyperSQL, SQLite). Inzwischen hat aber vor allem SAP Hana die In-Memory-Technik auf eine andere Ebene gehoben.
Noch 2010 sprach vor allem ein hochfrequentierter Lesezugriff auf den Daten-Caches oder ein intensives Lesen und Schreiben von temporären Daten für den Einsatz der In-Memory-Technik. Dies entlastete die «normale» Datenbank bezüglich Anzahl Transaktionen, I/O und User Sessions. Damit jedoch die Performance-Vorteile vollumfänglich ausgenutzt werden konnten, waren einfache und kurz laufende SQL-Statements erforderlich. Darüber hinaus musste die In-Memory-Datenbank nahe bei der Applikation sein, idealerweise auf demselben Server, um den Geschwindigkeitsvorteil nicht auf dem Netzwerk einzubüssen. All diese Anforderungen waren klar auf OLTP-Applikationen zugeschnitten. Dies sind Anwendungen, bei denen sehr viele Benutzer sehr viele kleine Änderungen an den Daten vornehmen, wie beispielsweise bei ERP- oder CRM-Lösungen. Analytische Applikationen mit wenigen, dafür komplexen, oftmals lang laufenden Abfragen waren wiederum nur durch wenige, auf Business Intelligence spezialisierte Lösungen optimiert. Diese orientierten sich stark an den spaltenorientierten Datenbankansätzen von Sybase IQ oder Vertica.
Eines haben die damaligen Lösungen mit den heutigen gemeinsam: das Risiko für Datenverlust. Dies, da die Daten im flüchtigen Hauptspeicher nicht zwingend synchron auf persistenten Speicher geschrieben werden.
Oracle Times Ten: Werdegang eines Spezialisten
Die eingangs genannten spezialisierten Produkte sind nach wie vor auf dem Markt und haben sich natürlich weiterentwickelt. So versteht beispielsweise Oracle Times Ten heute mehr Verdichtungsfunktionen (zum Beispiel AVG, SUM oder GROUP) und erlaubt die spaltenorientierte Verwaltung und Komprimierung von Tabelleninhalten. Diese Erweiterungen hingen mit dem Release der Oracle Exalytics In-Memory Machine Ende 2011 zusammen und wiesen bereits in Richtung analytischer Workload. Auch sonst beseitigte Oracle in Times Ten Einschränkungen beim Performance-Monitoring (etwa HTML-Reports und Statistiken) und der SQL-Implementation. Inzwischen werden Large-Object-Datentypen (LOBs) unterstützt und es sind weitere aus dem Oracle RDBMS bekannte SQL-Funktionen vorhanden (WITH, REPLACE). Inkrementelle Verbesserungen gibt es auch bei den Kommandozeilen-Tools und diversen Assistenten wie Index Advisor.
Im Grundsatz haben sich Architektur und Stossrichtung von Times Ten in den letzten drei Jahren aber nicht verändert. Times Ten kann immer noch als reine In-Memory-Datenbank oder als vor ein RDBMS geschalteter Database-Cache betrieben werden, ist aber nach wie vor OLTP-orientiert und nur eingeschränkt für komplexe analytische Abfragen geeignet.
SAP Hana: Revolution oder Evolution?
Hauptspeicher werden immer günstiger, CPUs immer leistungsfähiger. Mit Faktor 1000 bis 1‘000‘000 für die Zugriffszeit liegen Welten zwischen RAM und Festplatte oder Solid State Disk. Selbst beim Datendurchsatz sind es immerhin noch ein bis zwei Grössenordnungen. Warum sollte es nicht möglich sein, diese Vorteile durchgängig stärker zu nutzen, ohne eine In-Memory-Speziallösung vor das althergebrachte RDBMS zu stellen?
2008 zeigten Entwickler am Hasso-Plattner-Institut und der Universität Stanford erstmals Beispiele ihrer relationalen In-Memory-Datenbank für Real-Time-Analysen. Damals noch scherzhaft als «Hassos New Architecture» bezeichnet, entwuchs diesen Ansätzen Ende 2010 SAP Hana als «High-Performance Analytic Appliance». Hana stellte den Anspruch, sowohl für OLTP als auch für Business-Intelligence-Aufgaben gleichermassen gewappnet zu sein. Folgerichtig ist die SAP-Datenbank seit Ende 2011 als Plattform für das SAP-Business-Warehouse und seit Mitte 2013 auch für die SAP-ERP-Lösung verfügbar.
Hana ist konsequent auf die Verwaltung aller Daten im Hauptspeicher ausgelegt, macht intensiven Gebrauch von CPU-Caches und kombiniert zahlreiche weitere Techniken miteinander. Dazu zählen die spaltenorientierte Speicherung von Daten, Kompression, Parallelisierung über viele CPUs, die gleichzeitige Verarbeitung von Daten sogar innerhalb eines CPU-Kerns (SIMD = Single Instruction, Multiple Data) und Clustering über viele Rechenknoten hinweg. Von Anfang an gibt es auch – passend zum Appliance-Begriff – strenge Vorgaben für die Hardware.
Hana machte in der Datenbankwelt Furore und war lange Zeit Top-Gesprächsthema auf Messen und Kongressen. Alles schien auf den Kopf oder in Frage gestellt: Werden analytische Queries jetzt zweimal, 50-mal oder sogar 1000-mal schneller? Wird auch OLTP schneller? Ist das endlich eine Lösung, mit der sich ein Data Warehouse einsparen lässt und die gleichzeitig echte Real-Time-Analysen ermöglicht – direkt auf dem OLTP-System? Sollte man sich darum von seiner DB2, seinem SQL-Server oder seiner Oracle-DB jetzt langsam verabschieden? Ist der herkömmliche Ansatz bei den gängigen RDBMS eine Sackgasse und eine vollständige Neuimplementierung der Datenbanksoftware erforderlich? Und falls ja, hat SAP hier jetzt einen uneinholbaren Vorsprung?
Der Druck auf die grossen Datenbankhersteller wuchs. So brachten diese ihrerseits In-Memory-Lösungen für schnelle Analysen und bessere OLTP-Unterstützung auf den Markt – mit ähnlichen und doch unterschiedlichen Ansätzen.
IBM DB2 BLU Acceleration
Ein In-Memory-Funktionspaket hielt unter dem Namen BLU Acceleration im April 2013 in die Advanced Editions von IBMs DB2-Datenbank ab Version 10.5 Einzug. Die IBM-Lösung nutzt ähnliche Techniken wie Hana – spaltenorientierte Verarbeitung und Kompression, SIMD- und Vektoroperationen oder dynamisch erstellte, hauptspei-
cherorientierte Indexe. Das Besondere: Ist die Datenbank einmal auf BLU Acceleration eingestellt, lassen sich Tabellen wahlweise im normalen zeilenorientierten Modus erzeugen oder eben spaltenorientiert mit den genannten Verarbeitungsvorteilen. Alternativ können Tabellen vom einen Format in das andere umgewandelt werden. Dann werden, je nach Quelle, Abfragen 8- bis 40-mal schneller, und dies bei gleichzeitiger Kompression, die üblicherweise bei typischen grossen Faktendaten etwa Faktor 10 beträgt. Dabei sind wie bei Hana die Daten im RAM und auf Disk komprimiert.
BLU Acceleration ist klar für den analytischen Workload gedacht. OLTP soll weiterhin auf zeilenorientierten Tabellen durchgeführt werden, die friedlich mit den spaltenorientierten Tabellen koexistieren.
Microsoft SQL Server In-Memory Database Features
Auch der Microsoft-SQL-Server folgte dem Trend. Schon mit dem SQL-Server-Release 2012 kam die xVelocity Engine. Diese erzeugte für analytische Abfragen spezielle spaltenorientierte, komprimierte In-Memory-Indexe für bestehende Tabellen. So konnte sie komplexe Abfragen deutlich beschleunigen. Diese Indexe wurden jedoch zusätzlich zur normalen Tabelle erstellt und waren zudem «read only». Somit mussten sie nach jeder Änderung in einem Tabellensegment neu erstellt werden. Im Frühjahr dieses Jahres wurde diese Limitierung mit dem neuen SQL-Server 2014 beseitigt. Dazu kam mit In-Memory OLTP eine zusätzliche Lösung für die Beschleunigung von OLTP-Workloads. Diese müssen im Gegensatz zu den xVelocity-Daten komplett und durchgängig im Hauptspeicher gehalten werden und bringen für bestimmte, transaktionsintensive Workloads deutliche Performance-Zuwächse – je nach Anwendungsfall um Faktor 100 oder sogar mehr. Ausserdem wurde das Concurrency-Verhalten geändert und eine spezielle Zugriffsmöglichkeit für nativ kompilierte Programme geschaffen. Diese Massnahmen reduzieren den üblichen OLTP-Overhead drastisch. Damit hat Microsoft zwei getrennte Lösungen im Programm: OLTP-optimierte Tabellen und analyseoptimierte Tabellen.
Oracle In-Memory Database Option
Im Juli zog auch Oracle nach und stattete nach der Ankündigung im Herbst 2013 die neueste Version seiner 12c-Datenbank mit einer kostenpflichtigen In-Memory-Zusatzoption aus. Diese besteht im Wesentlichen aus einem In-Memory Column-Store für die Beschleunigung von analytischen Abfragen. Dieser Column-Store-Typ funktioniert von aussen betrachtet ganz ähnlich wie die BLU-Accelerator-Variante von IBM. Laut Oracle sollen je nach Anwendungsfall Beschleunigungen um Faktor 10, 100 und mehr erreicht werden. Ein wesentlicher Unterschied zu den anderen Lösungen besteht aber darin, dass Oracle keinerlei In-Memory-Daten auf Disk schreibt. Spaltenorientierte Datenhaltung, automatische Indexierung und Kompression laufen ausschliesslich im Hauptspeicher ab. Alle disk-relevanten Operationen (Buffer und Logs auf Disk schreiben) werden mit den gängigen Mitteln auf normalen zeilenorientierten Strukturen durchgeführt und redundant, aber konsistent für die spaltenorientierten In-Memory-Strukturen mitgezogen. Als Nachteile sind die teilweise redundante Ressourcenbelastung und die fehlende Kompression auf Disks zu nennen. Ersteres ist laut Oracle minimal, Letzteres muss mit anderen Oracle-Kompressionsmechanismen erreicht werden.
Der Vorteil liegt aber auf der Hand: In-Memory ist hier nur ein Schalter pro Tabelle, tatsächlich sogar pro Partition und auch für einzelne oder Gruppen von Spalten aktivierbar. Um von den neuen Möglichkeiten zu profitieren, müssen keine Daten migriert werden. Eine Evaluation ist also einfach.
Ähnlichkeiten und Unterschiede der Lösungen
Nebst SAP Hana, das von vornherein als rein hauptspeicherorientiertes RDBMS und damit als besonders schnelle Alternative zu etablierten relationalen Datenbanken entwickelt wurde, haben IBM, Microsoft und Oracle nachgezogen, indem sie vergleichbare Funktionalitäten direkt in die bestehenden Datenbankplattformen integrierten. Die Stossrichtung ist klar: Der Wechsel auf eine andere, separate In-Memory-Plattform wie Hana soll nicht mehr nötig sein. Im einfachsten Fall möge der Administrator in bestehenden Datenbanken bitte einen Schalter umlegen, um alle Applikationen damit um ein Vielfaches zu beschleunigen. Aber ist das realistisch?
Werfen wir einen Blick auf die Technik dahinter. Es fällt schnell auf, dass sich alle neuen In-Memory-Datenbankfunktionen ähnlicher Mechanismen bedienen:
- Zugriff via SQL. Allenfalls sind weitere Sprachen wie MDX möglich.
- Spaltenorientierte Datenhaltung zumindest für die analytischen Anforderungen.
- Hauptspeicheroptimierte Datenstrukturen und Indexe, Letztere oft automatisch nach Bedarf erzeugt.
- Intensive Nutzung von CPU-Caches und CPU-Features wie SIMD.
- Kompression von Daten im Hauptspeicher, teils auch auf Platte.
- Einhaltung des ACID-Prinzips (Atomicity, Consistency, Isolation & Durability). Die Lösungen müssen daher zumindest am Ende jeder Transaktion die Daten dauerhaft speichern. Dies ist heute noch ein spürbarer Flaschenhals bei der Geschwindigkeit von Schreiboperationen.
Es gibt aber auch Unterschiede zwischen den einzelnen Lösungen. Im Folgenden vier Beispiele:
Datenhaltung: Manche Datenbanken müssen betroffene Datensegmente spätestens bei der ersten Abfrage vollständig in den Hauptspeicher laden. Dies gilt für SAP Hana und MS SQL Server bei OLTP-optimierten Tabellen. Andere können Teile davon, die nicht mehr in den Hauptspeicher passen, auch auf Festplatte nutzen. Dies ist bei Oracle und IBM DB2 der Fall. Natürlich lässt dabei die Performance entsprechend nach, dafür gibt es keinen Abbruch der Verarbeitung.
Speicherstrukturen: Teils werden die Daten komprimiert auf den Storage geschrieben und davon gelesen, teils sind die In-Memory-Strukturen nur im Hauptspeicher abgebildet und müssen nach einem Restart der Datenbank erst wieder neu auf Basis der zeilenorientiert gespeicherten Daten aufgebaut werden.
Techniken für die Transaktionssicherheit: Geänderte Daten werden je nach Produkt in regelmässigen Abständen mit dem persistenten Speicher (Festplatte) als Snapshot gespeichert oder mit üblichen Buffer-Pool-Mechanismen abgeglichen. Oder sie werden nur beim Stoppen der Datenbank auf Platte geschrieben.
Workload-Orientierung: Microsoft offeriert spezielle, OLTP-optimierte Tabellentypen. SAP Hana unterscheidet nach Bedarf zwischen zeilen- und spaltenorientierter Datenhaltung. Oracle platziert seine Lösung auch für verbesserten OLTP-Workload, da die In-Memory-Nebeneffekte (keine analytischen Indexe mehr auf normale Tabellen) den DML-Durchsatz verbessern sollen.
Diese Besonderheiten gilt es vor einer Applikationsumstellung zu beachten. Ein paar Anwendungsfälle werden von einer direkten Umstellung ohne weitere Anpassungen profitieren. Andere werden hingegen nicht die gewünschten PerformanceVorteile zeigen oder sogar deutlich langsamer werden. Und in einigen Fällen wird man mit unvorhergesehenen Problemen kämpfen und funktionale Einbussen haben. Es gilt also auch im Falle einer Umstellung auf In-Memory-Technik innerhalb des vertrauten RDBMS, zunächst die jeweils geeigneten Tabellenkandidaten zu identifizieren und mit typischen Anwendungsfällen gründlich zu testen.
Fazit
Für IT-Entscheider stellt sich die Frage, ob sich ein Umstieg auf In-Memory-Technologie lohnt – und zwar auch dann, wenn es sich nur um ein Upgrade der bestehenden Systeme handelt. Fakt ist, dass In-Memory-Technologien in bestimmten Anwendungsszenarien sowohl im OLTP als auch im analytischen Bereich schneller und effizienter arbeiten als bisher übliche Techniken, gleichzeitig aber auch Einschränkungen und Applikationsanpassungen mit sich bringen. Wenn auch Letzteres nicht mehr in dem Masse wie noch vor ein paar Jahren.
Festzuhalten ist auch: In-Memory-Datenbanken sind keine Wunderwaffen. Wie die jeweiligen Produktvorteile genutzt und die Nachteile vermieden oder in Kauf genommen werden, ist für jeden Anwendungsfall separat zu klären. Im Folgenden einige wesentliche Entscheidungskriterien:
- Wie schnell ist die Lösung wirklich für den Anwendungsfall? Evaluation, Proof-of-Concept durchführen.
- Welche Kosten entstehen für Lizenzen, neue Hardware, Hardware-Erweiterung (RAM), Services, Migrationsaufwand, Fortbildung, Applikationsanpassungen und dergleichen?
- Wo liegen technische Einschränkungen und Risiken für den Einsatz? Wie können diese beseitigt werden?
- Ist eine Migration auf eine andere Plattform nötig? Mit Applikationsanpassungen, neuem Know-how, eventuell einem neuem Lieferanten bedeutet dies erhöhten Aufwand.
- Ist eine Migration innerhalb der bestehenden Plattform möglich? Dies erfordert weniger Applikationsanpassungen, aber dennoch eine physische Reorganisation der Daten.
- Ist keine Migration nötig, nur eine Rekonfiguration? Dann ist die Evaluation einfach, aber es gibt keine Platzersparnis auf den Disks.
- Welche funktionalen Limitierungen der In-Memory-Lösungen gibt es? Zum Beispiel Datentypen, Workload, Scale-Up/Scale-Out, Parallelisierung, Partitionierung. Welche Applikationsanpassungen sind nötig?
- Wie stabil ist die neue Technologie? Gibt es viele Bugs, Kinderkrankheiten und dergleichen?
So sind vor einer Entscheidung eine Menge Fragen zu klären: Stehen Performance-Zuwachs und Disk-Platzersparnis in einem positiven Verhältnis zu Aufwand, Kosten, Applikationseinschränkungen und sonstigen Risiken? Und am Ende kommt es – wie immer – darauf an, was man genau erreichen möchte.
Peter Welker ist Senior Principal Consultant bei trivadis, Roland Stirnimann und Jan Ott sind Senior Consultants, ebenfalls bei Trivadis.
