Auf den ersten Blick klingt es durchaus einleuchtend, dass man Datenbanken in den Hauptspeicher lädt, um damit eine Beschleunigung der Verarbeitung zu erreichen. Immerhin funktioniert das Auslesen einer Festplatte deutlich langsamer als der Zugriff auf einen Hauptspeicher. Das wissen wir schon seit den 1980ger Jahren, als man zur Beschleunigung des nun wirklich langsamen Zugriffs auf Floppy-Disks die RAM-Disk erfand, um einfach eine Kopie der Floppy im Hauptspeicher anzulegen, um dann dort "In-memory" weiterzuarbeiten. Genau dieses Konzept hatte SAP verfolgt, als man dem rechenaufwändigen, auf SAP BW basierenden Produktionsplanungs-Server "APO" einen "Live-Cache" zur Seite stellte - der Vater von HANA.
In Memory ist nicht neu
Doch HANA ist keineswegs ein neuer Wegbereiter. Die Konkurrenz bei In-Memory ist groß. Nahezu alle bekannten relationalen Datenbank-Managementsysteme (RDBMS) bieten In-Memory in der einen oder anderen Form an. IBM integriert ähnliche Features schon lange in DB/2 und vermarktet diese nun gezielt als Antwort auf HANA unter dem Begriff BLU. Oracle und Microsoft mit SQL offerieren ebenso In-Memory-Optionen. Auch die freien Datenbanken wie MARIA/DB alias MySQL erlauben schon lange In-Memory: Dort wird einfach die Standard Storage-Engine "INNODB" durch die Storage-Engine "MEMORY" (vormals: "HEAP") ausgetauscht. Die Entwickler betonen, dass die "CLUSTER" Storage-Engine eine vergleichbare Performance erziele, dabei aber die Persistenz, also das Speichern der Daten, erlaube.
Andere Anbieter verfolgen indes andere Strategien. Beispielsweise verweigert sich PostgreSQL diesem Trend und verweist darauf, dass In-Memory im Grunde kein Feature, sondern im Grunde ein Defekt im eigentlichen Wortsinne sei - nämlich eine Datenbank, die nicht speichern kann. Erwähnen sollte man an dieser Stelle auch Interbase Caché, MongoDB oder Couchbase, die konsequent den Ansatz einer operationalen strukturfreien Datenbank verfolgen. Doch es gibt mittlerweile so viele Anbieter in diesem Umfeld, dass man leicht den einen oder anderen Mitspieler vergessen kann.
Datenbanktechnologie ist selten die Performancebremse
Es wäre allerdings kurzsichtig, nur auf die Technologie der Datenbank selbst zu sehen. Ein Benchmark zwischen In-Memory versus traditionellen Datenbanken ist in Wirklichkeit schwierig. Nicht erst seit VW wissen wir, dass man im Labor gut messen und die Ergebnisse auch intelligent steuern kann. Testen wir zum Beispiel eine Datenbank mit sehr vielen Mikrozugriffen mit Ergebnissen von wenigen Bytes, zum Beispiel das Abfragen aller in einem Monat erzeugten Auftragsnummern, dann gewinnt In-Memory leicht. Bei Massenzugriffen, zum Beispiel dem Auslesen aller Buchungsbelege einer kompletten Woche, ist jedoch eine Disk kaum langsamer, denn der Disk-Zugriff zum Lesen eines ganzen Datenblocks dauert kaum länger als bei einem einzelnen Datensatz.
Einflussfaktoren für einen Benchmark
Tatsächlich ist der Gewinn an Performance durch eine In-Memory-Datenbank deutlich geringer als man es zunächst erwartet. Denn der Datenzugriff auf die Festplatte durch das DBMS ist nur ein Faktor, der das System ausbremst. Folgende Faktoren spielen auch eine Rolle beim tatsächlichen Durchsatz einer In-Memory Datenbank:
tatsächlicher Durchsatz des Lesens von einer Festplatte;
vorausschauende Lese-Algorithmen;
zwischenspeichern von Ergebnissen (Result-Caching);
Geschwindigkeit der Datenübertragung zwischen Client (Anwendung) und Server (Datenbank);
Ergebnis-Komprimierung und Differentielle Datenübertragung zwischen Server und Anwendung.
Diese Liste erhebt keinen Anspruch auf Vollständigkeit, denn es gibt noch viele weitere potentielle Stellschrauben. Letztlich geht es nicht nur um die Optimierung einzelner Komponenten, sondern die gesamten Verarbeitungs- und Antwortzeiten über alle Komponenten hinweg. Folgende Details gilt es dabei zu beachten:
Tatsächlicher Durchsatz des Lesens von einer Festplatte: Die Hardware einer Festplatte ist heutzutage nicht alleine entscheidend. Das liegt zum einen daran, dass DMBS-Software über Jahrzehnte verfeinerte Algorithmen nutzt, um die Geschwindigkeitsverluste durch langsame Festplatten durch intelligente Zugriffe zu kompensieren.
Festplatten-Architektur: Hinzu kommt der Einfluss durch die Geometrie (Bauweise) einer Festplatte. So besteht eine Platte aus mehreren Scheiben und vielen Lese-Köpfen. Die Daten werden somit nicht mehr Bit für Bit ausgelesen, sondern 16, 32 oder mehr Bits gleichzeitig.
Solid-State-Disks: Allgemein scheint es, dass mechanische Festplatten langsam durch Halbleiterspeicher mit Solid-State-Technologie verdrängt werden. Nutzt man solche Geräte im Rahmen klassischer Datenbankarchitekturen zusammen mit guten Cache-Algorithmen, lässt sich gegenüber In-Memory kaum ein Nachteil erkennen.
Pre-Fetch und Look-Ahead: Es geht aber noch weiter - Festplatten haben selbst intelligente Cache-Mechanismen. Mit aufwändigen Patenten geschützte Algorithmen schaffen es, den Cache so zu befüllen, dass sich mit hoher Präzision Daten schon im Cache befinden, bevor die Anfrage vom Client tatsächlich gestellt wird. Dieses Caching stoßen viele Anwendungen selbst an, indem zum Beispiel eine ganze Datenbanktabelle einfach in den Hauptspeicher gelesen wird. Auch das Betriebssystem übernimmt solche Aufgaben, zum Beispiel hat Windows das Prefetch implementiert, um schneller zu starten.
Vorausschauende Lese-Algorithmen: Festplatten sind kleine Expertensysteme. Daten werden nicht einfach seriell gelesen und dann weiter gesendet. Vielmehr greifen spezialisierte Festplatten-Controller mit hoc-spezialisierten Algorithmen auf die physischen Platten zu. Zum einen sind die Daten schon so abgelegt, dass die Wege zwischen zusammenhängenden Daten klein sind. Zusätzlich erkennen diese Algorithmen Verhaltensmuster, um den "In-Memory"-Cache bereits vorausschauend zu befüllen. Sobald dann die Anwendung die Daten lesen möchte, befinden sich diese mit einer hohen Treffsicherheit von gewöhnlich über 95 Prozent bereits im Cache. Auf solche Algorithmen gibt es übrigens zahlreiche Patente, was ein Problem für jeden Newcomer im Bereich analytische Datenbanken darstellt, weil viele guten Ideen erst patentrechtlich geprüft und abgesichert werden müssen.
Zwischenspeichern von Ergebnissen: Den größten Performance-Gewinn bringen operationale Datenbanken wie HANA, indem Antworten beziehungsweise die Pfade zur Antwort bereits zwischengespeichert werden. Anstatt jedes Zwischenergebnis jedes Mal neu zu berechnen, rechnet das System einmal und erinnert sich an die bereits zuvor ermittelte Lösung.
Kommunikation zwischen Anwendung und Datenbank: Datenbanken und Anwendungen kommunizieren in aller Regel durch eine Client-Server-Architektur. Dabei sendet die Anwendung eine "Anfrage" an den Server und erhält eine "Antwort". Dabei stellt der Zugriff auf die Festplatte nur einen kleinen Teil dar. Die Zeit, um die Daten vom Server zum Client zu transportieren, hängt von der Datenmenge und dem Durchsatz der Netzwerkverbindung ab. Wenn es dumm läuft, kann das "In-memory" ermittelte Ergebnis erst auf der Festplatte zwecks Datenübertragung zwischengespeichert und dann übertragen werden. Verlässt man sich rein auf die Messwerte, so bildet oft die Netzwerkverbindung bei reinen Client-Server-Architekturen den Flaschenhals, weniger die Disk-Zugriffe.
Ergebnis-Komprimierung: Für die Übertragung zwischen Anwendung und Datenbank, also Client und Server kommt auch noch die Komprimierung der Ergebnisse in Frage. Dazu lassen sich typische Antwortmuster als atomare Einheit definieren und anstatt den Block jedes Mal zu übertragen, wird ein zuvor gesendetes Ergebnis referenziert. Ähnlich funktioniert differentiale Datenübertragung, das heißt man überträgt nur das, was wirklich neu ist. Webbrowser als Prototypen des Client-Server würden ohne diese Form des Caching gar nicht effizient funktionieren.
Auf das Zusammenspiel kommt es an
Am Beispiel In-Memory sehen wir, dass es nicht darum geht, wer die beste individuelle Lösung hat, sondern wie diese Lösung mit den anderen Komponenten einer komplexen und sich unvorhersehbar ändernden Landschaft zusammenspielt. Und was HANA betrifft, werden wir in einem anderen Artikel sehen, dass SAPs In-Memory-System durchaus seinen Platz in diesem Spiel hat: allerdings nicht als In-Memory-Datenbank, sondern in seiner Rolle als Operational DBMS.