In-Memory Computing als Treiber neuartiger Geschäftsanwendungen

Seit einigen Jahren erfreut sich das Thema "In-Memory" zunehmenden Interesses in der Welt der Datenbanken. Die Produkte in dem Umfeld bestechen mit erstaunlichen Leistungsangaben. Entwickler von Unternehmenssoftware können damit Anwendungen implementieren, die reich an Informationen sind und dennoch alle Transaktionen und Analysen in wenigen Sekunden ausführen.

Um für mehr Beschleunigung bei der Datenverarbeitung zu sorgen, haben sich die Hersteller unterschiedliche Beschleunigungsverfahren einfallen lassen: Diese reichen von der Einschränkung der Schreib-/Lesevorgänge auf die äußeren Bahnen der Festplattensektoren über die Vorverarbeitung der Daten in oder beziehungsweise auf der Festplatte selbst bis hin zu großen Zwischenspeichern, die die tatsächlichen Zugriffe auf Festplatten reduzieren sollen. Diese Techniken haben eines gemeinsam: Im Kern setzen sie voraus, dass Daten auf den Festplatten gespeichert sind, und sie versuchen, den Zugriff zu beschleunigen.

Speicher ist heute nicht nur in wesentlich größeren Kapazitäten als früher erhältlich, er ist zudem mittlerweile bezahl- und dank moderner 64-Bit-Betriebssysteme überhaupt erst nutzbar. Die mit 32-Bit-Adressraum sind auf vier Gigabyte Speicher beschränkt, während eines mit 64-Bit-Adressierung so viel Speicher nutzen kann, dass er derzeit noch gar nicht in einen Server passt.

Damit lässt sich grundsätzlich eine bisherige Grundannahme in Frage zu stellen: Müssen Daten tatsächlich aus dem Hauptspeicher genommen werden, da dieser klein ist? "In-Memory" beschreibt einen Ansatz, mit dem sich alle für eine Aufgabe notwendigen Daten im Hauptspeicher unterbringen lassen.

Zeitgemäße Server kann man mit bis zu zwei Terabyte Hauptspeicher ausstatten. Ist es nun nicht mehr notwendig, Daten schnell aus dem Speicher zu räumen, damit neue Daten aufgenommen werden können, stellt sich die Frage der Notwendigkeit Festplatten nutzender Datenbanken. Techniken werden irrelevant, die sich mit der Beschleunigung beim Lesen von Festplatten beschäftigen und andere relevant, die sich mit dem schnellen Informationsaustausch zwischen Hauptspeicher und CPU-Registern auseinandersetzen. Mit den Worten des Datenbankexperten Jim Gray hat sich die Technik um einen Schritt hin zur CPU bewegt: "RAM is Disk, Disk is Tape, and Tape is dead."

Jedoch wären alle Daten im Hauptspeicher nutzlos, wenn die CPUs nicht über ausreichend Leistung verfügten, um diese Daten auch zu verarbeiten. Wenn nämlich die Verarbeitungsgeschwindigkeit der CPU so langsam ist, dass ein Lesevorgang von einer Festplatte schnell genug ist, müssen nicht alle Daten schon im Speicher sein. An dieser Stelle hat es in den vergangenen Jahren eine große Veränderung von komplexen CPUs hin zu Multi-Core-Prozessoreinheiten gegeben. Diese Rechenmeister verfügen über bis zu zehn Rechenkerne und lassen sich zu zweit, zu viert oder zu acht in einen Server bauen. Damit warten bei jedem Schlag, den das Herz eines Rechners schlägt, bis zu 80 datenhungrige Rechenkerne auf neue Daten oder Instruktionen.

Für diese Rechenleistung ist es notwendig, spezifische Software zu schreiben. Diese muss komplexe Aufgaben in viele kleine Prozessstränge (Threads) zerlegen können, die die große Anzahl an Rechenkernen parallel nutzen können. Zur optimalen Verarbeitung sind zudem die Daten schnell genug und in optimierten Datenstrukturen bereitzustellen.

Das ist genau die Köngsdisziplin des In-Memory Computing: Daten werden in Strukturen im Speicher gehalten, die sich an den Prozessor-Caches (L1, L2 und Smart Cache) und CPU-Registern orientieren und nicht mehr an der Organisation von Festplatten. Außerdem werden die Daten im Speicher so verteilt, dass sich alle Operationen hochparallelisiert in möglichst vielen Rechenkernen gleichzeitig ausführen lassen, um die Ausführungszeit maximal zu optimieren.

Bei Annahme, dass alle Daten im Hauptspeicher stehen, stellt sich die Frage, ob diese Daten sicher (durable) gespeichert werden, da das RAM volatil, also flüchtig ist. Es gibt einige In-Memory-Datenbanken, die diese Eigenschaft aus dem Transaktionsmodell nicht bereitstellen, da ihre Nutzungsszenarien den Grad der Datensicherheit nicht erfordern. Andere Ansätze verfügen jedoch über eine vollständige Persistenzschicht, die die Haltbarkeit der Daten auch bei einem Stromausfall sicherstellt. Diese Schicht sichert die Daten im Speicher, so wie eine traditionelle Datenbank ein Bandlaufwerk zur Sicherung der Daten auf Festplatte einsetzt, allerdings so, dass keine einzige bestätigte Transaktion verloren gehen kann.