Teil 1: Was ist In-Memory OLTP

Bei der Neubeschaffung eines Datenbank Servers wird immer mehr Arbeitsspeicher verwendet. Das Preisgefüge erlaubt es den Speicher so zu dimensionieren das komplette Datenbanken, oder zumindest Teile davon, in den Arbeitsspeicher ausgelagert werden können. Im Gegenzug werden aktuelle Datenbanken ebenfalls größer. Wachsende Datenbestände führen oft auch dazu, dass es zu Engpässen in den Storagesystemen kommt, die teilweise nur mit höherem Aufwand beseitigt werden können. Eine mögliche Entschärfung dieses Problems bietet Microsoft mit dem neuen In-Memory OLTP an. Mit dieser Technologie können Tabellen direkt im Arbeitsspeicher gelesen und bearbeitet werden, und somit den erheblichen Geschwindigkeitsvorteil von RAM gegenüber Festplatten ausnutzen.

Warum benötigt In-Memory OLTP weniger Zugriffe? Und wie wird die Integrität der Tabellen im Flüchtigen Speicher gewährleistet?

Was ist so anders an In-Memory OLTP?

Ein wichtiger Unterschied zwischen speicheroptimierten und festplattenbasierten Tabellen ist, das die zu verarbeitenden Daten nicht mehr in den Cache gelesen werden müssen. Da die Daten bei speicheroptimierten Tabellen schon im Speicher vorgehalten werden, ist kein Zugriff auf die Festplatten notwendig. Das spart Abfragekosten.

Weitere Besonderheit sind die Indizes welche zu den Tabellen gehören. Ein Index einer In-Memory Tabelle wird nicht auf der Festplatte gespeichert, sondern immer beim Laden der Daten in den Speicher (Initialisieren) der Tabelle neu generiert. Dazu zählt auch der Start des SQL Server Dienstes. Für die Indexverwendung muss also nicht auf die Festplatte zugegriffen werden. Auch an dieser Stelle wird also Storage I/O gespart.

Neu ist auch die optimierte Speicherverwaltung. Zeilen werden in sogenannten Heaps allokiert. Diese unterscheiden sich jedoch von den “normalen” SQL Server-Heaps. Die Zeilen einer Tabelle müssen nicht unbedingt zusammenhängend gespeichert werden. Der SQL Server identifiziert die einzelnen zusammengehörigen Zeilen durch den Index der Tabelle. Aus diesem Grund wird auch immer mindestens ein Index pro Tabelle benötigt. Indizes werden intern in Form einer Hash-Tabelle angelegt. Weiterführende Informationen zum Thema Index und Datenzugriff werden in diesem White Paper sehr detailliert beschrieben.

Weitere Neuerung im Zuge von In-Memory OLTP sind „Natively Compiled Stored Procedures“. Das sind gespeicherte Prozeduren, die auf speicheroptimierte Tabellen zugreifen können. Sie werden hierzu in nativem C-Code gespeichert und dann in Maschinensprache kompiliert, um die Speicheroperationen möglichst effiziert durchführen zu können. Ein Kompilieren während der Ausführung ist somit nicht mehr notwendig. Diese Stored Procedures erreichen die bestmögliche Abfragegeschwindigkeit, allerdings mit einigen Einschränkungen in der T-SQL Sprache. Ebenfalls ist nur der Zugriff auf speicheroptimierte Tabellen möglich.

Dauerhaftigkeit bei In-Memory gespeicherten Tabellen

Auch für speicheroptimierte Tabellen sind die ACID Eigenschaften einzuhalten. Insbesondere die Eigenschaft „Durability“ (Dauerhaftigkeit) ist durch den flüchtigen Speicher genauer zu beleuchten.

Um das Problem des Datenverlustes zu umgehen, müssen in der Datenbank speicheroptimierte Filegroups angelegt werden. In diesen Gruppen werden automatisch sogenannte Data- und Delta Files, die Checkpoint Dateien, angelegt. Wird ein Datensatz hinzugefügt, wird dieser mit einer Zeilen ID sequentiell in das Datafile angefügt. Wird eine Zeile gelöscht, wird ein Eintrag in der Delta Datei erstellt und die Zeile über die Row ID als gelöscht markiert. Das physikalische Löschen aus der DB übernimmt ein zeitgesteuerter Garbage Collector. Die Checkpoint Dateien werden nur sequentiell beschrieben, damit das zeitintensive Positionieren der Festplattenköpfe weitestgehend minimiert wird. Sollte, z. B. durch einen Serverrestart, der Speicher geleert werden, wird aus den Checkpoint Dateien der aktuelle Datenbestand wiederhergestellt.

Um Storageaktivitäten komplett zu vermeiden und höchstmöglichen Durchsatz zu erreichen, können In-Memory Tabellen auch ohne Checkpoint-Dateien angelegt werden. Allerdings empfiehlt sich das nur für reproduzierbare Daten wie z.B. das Staging eines DWH’s.

Das Transaction Log bleibt weiterhin auf dem Storage und wird gemeinsam mit den normalen Tabellen verwendet. Auch hier wurde für In-Memory OLTP optimiert: Gibt es während einer Transaktion mehrere Datensätze, werden sie nicht wie bisher Einzeln, sondern Gruppiert in das Transaktionsprotokoll geschrieben. Auch hierzu empfiehlt sich die Lektüre des MS Research Artikels.

Wie greift der Client auf diese Tabellen zu?

Die Client Applikation greift weiterhin, wie gewohnt über den Tabular Data Stream (TDS) auf die Datenbank zu. Für sie ändert sich nichts.

Die internen Prozesse sind jedoch sehr verschieden. Bei klassischen Tabellen ändert sich ebenfalls nichts. Wird eine speicheroptimierte Tabelle angesprochen, entscheidet der TDS Handler ob interpreted T-SQL ausgeführt wird oder direkt über eine kompilierte SP zugegriffen wird. Der Client greift dabei, bis auf wenige Ausnahmen, transparent auf die Tabellen zu, egal ob In-Memory oder nicht.

Abbildung 1: Vereinfachte Darstellung der SQL Server Engine inkl. der In-Memory OLTP Komponenten

Fazit:

Die Aussagen der PR Abteilungen sind geradezu überschwänglich. 10-100 x schneller ist die Vorgabe. Der betriebene Aufwand ist erheblich, scheint beim Technikreview aber die gesteckten Ziele erreichen zu können. Der Aufbau der Tabellen im Speicher ist grundlegend anders, die Verwendung allerdings kaum. Ich verspreche mir von diesem Feature einiges. Der Implementierungsaufwand scheint auch in bestehenden Umgebungen gering. Möglicherweise kann dieses Feature in Zukunft zu schnelleren Zugriffen auf Datenbanken beitragen.

Wie die neuen speicheroptimierten Filegroups und Tabellen angelegt werden und worauf dabei zu achten ist, erläutere ich im nächsten Kapitel dieser Serie: Arbeiten mit speicheroptimierten Tabellen / Performance.

Hier werde ich auch speicheroptimierte mit herkömmlichen Tabellen in Benchmarks gegeneinander vergleichen. Ich bin gespannt wie hoch der Unterschied ausfällt!