Artikel als PDF anzeigen

ITMAGAZINE
Alles im Arbeitsspeicher
7. September 2014 - Von Peter Welker, Roland Stirnimann und Jan Ott Die In-Memory-Technologie hält Einzug in klassische Datenbankmanagement-Systeme. Dies hebt jedoch nicht automatisch
alle bisherigen Einschränkungen auf. 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
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.
Copyright by Swiss IT Media 2017