Was unter dem Projektnamen „Hekaton“ begann, konnte nun im Microsoft SQL Server 2014 umgesetzt werden. „In-Memory OLTP“ bietet alle notwendigen Funktionalitäten, um den wachsenden Anforderungen an die Verarbeitungsgeschwindigkeit gerecht zu werden.

Der Bedarf an einem immer höheren Durchsatz und geringeren Latenzzeiten ist auch im Datenbankumfeld ungebrochen. Bisher wurde die notwendige Steigerung der Performance durch eine verbesserte Software und eine regelmäßige Leistungsverdoppelung der CPUs erreicht. Da die Datenbankmanagementsysteme aber mittlerweile ausgereift sind und die CPUs an ihre Grenzen stoßen, hat diese Entwicklung inzwischen ihr Ende erreicht. Hinzu kommt, dass die bisherige Speicherung und Verarbeitung der Daten auf Festplatten optimiert ist. Die 8 KB großen Seiten sind das Maß aller Dinge. Im Hauptspeicher soll sich nur noch der für die aktuelle Verarbeitung notwendige Teil befinden. Konkurrierende Zugriffe werden mit Hilfe von Sperren koordiniert bzw. weitestgehend serialisiert.

Fazit: Es wird (Haupt-)Speicherplatz eingespart, doch dafür muss mit Wartezeiten bezahlt werden.

MS SQL Server 2014: Ein neuer Ansatz

Auf dieser Grundlage verfolgte Microsoft die Idee, die Anzahl der Verarbeitungsschritte und die damit benötigte Wartezeit radikal zu reduzieren. Dies bedingte allerdings eine grundlegende Veränderung der Architektur. Durch die Reduzierung der Kosten für Hauptspeicherplatz kann bei vielen Systemen eine Speicherung – zumindest der zentralen Tabellen – komplett im Hauptspeicher erfolgen. Durch den Verzicht auf Sperren und die Versionierung der einzelnen Datensätze mit Hilfe von Zeitstempeln wurde daher die Grundlage für eine neue Art der Verarbeitung geschaffen.

Diese neue Architektur wurde so in den SQL Server integriert, dass in vielen Fällen keine Änderungen an den Applikationen notwendig sind. Hauptspeicheroptimierte und klassische Tabellen können zusammen in einer Transaktion verwendet werden. Fast der komplette Sprachumfang von Transact-SQL ist auf die neuen Tabellen anwendbar.

Verzicht auf Sperren durch Datenversionierung

Ein zentrales Merkmal der neuen Speicherstruktur ist die Versionierung der einzelnen Datensätze mit zwei Zeitstempeln: Dem Beginn und dem Ende als Sequenznummern der zugehörigen Transaktionen. Dies ermöglicht parallel ablaufenden Transaktionen, immer beurteilen zu können, ob der gelesene Datensatz im (zeitlichen) Kontext der eigenen Transaktion gültig ist oder nicht.

Auch wenn es weiterhin möglich ist, UPDATE-Statements zu verwenden, wird technisch gesehen immer ein neuer Datensatz erzeugt. Die vorherige Version des Datensatzes wird dann durch den Eintrag des Ende-Zeitstempels als nicht mehr gültig markiert. Lesende Transaktionen werden damit nicht mehr durch schreibende Transaktionen behindert und auf Sperren wird komplett verzichtet. Damit entfallen auch die Wartezeiten durch Locks und Latches, was eine deutliche Performance-Steigerung bewirkt.

Hierbei gilt es aber zu beachten, dass es sehr wohl zu Konflikten zwischen zwei schreibenden Transaktionen kommen kann, wenn sie den gleichen Datensatz ändern. Beim Commit wird dieser Konflikt erkannt und führt zu einem Abbruch einer der beiden Transaktionen. Bedingt durch die Performance-Steigerung nimmt die Transaktionsdauer ab. Damit verringert sich auch das Risiko, dass solche Situationen entstehen. Die Applikation muss aber in jedem Fall mit einer solchen Situation umgehen können.

Zwei neue Index-Arten

Das zweite zentrale Merkmal der neuen Speicherstruktur stellt die ausschließliche Nutzung von Indizes zur Verwaltung der Datensätze dar. Eine unstrukturierte Speicherung der Datensätze, wie in klassischen Heap-Tabellen, ist nicht möglich. In diesem Zuge wurden zwei neue Arten von Indizes geschaffen: Hash-Indizes und Bw-Bäume.

Die Basis eines Hash-Index ist eine Hash-Funktion sowie eine Liste mit allen möglichen Ergebnissen dieser Funktion, die im Hauptspeicher abgelegt wird (im Folgenden Hash-Tabelle genannt). Wird nun ein Datensatz eingefügt, so wird er an einer beliebigen Stelle im Hauptspeicher abgelegt und die Hash-Funktion auf die indizierte(n) Spalte(n) angewendet.

Das Ergebnis der Hash-Funktion bestimmt, an welcher Stelle der Hash-Tabelle der Verweis auf die Speicheradresse des Datensatzes eingetragen wird. Ist dort bereits ein Datensatz vermerkt, so wird der Verweis auf den neuen Datensatz in den bereits bestehenden eingefügt. Alle Datensätze, bei denen die Hash-Funktion dasselbe Ergebnis liefert, werden somit in Form einer Kette miteinander und mit der Liste verbunden.

Ein schneller Zugriff auf die einzelnen Datensätze ist damit aber nur möglich, wenn der exakte Wert der indizierten Spalte(n) bekannt ist und damit die Hash-Funktion angewendet werden kann. Für Abfragen über Wertebereiche (Range-Scans) wird die zweite Index-Art, der Bw-Baum verwendet.

Die Basis dieser Index-Architektur bildet der klassische Index-Baum, wie er auch beim SQL Server verwendet wird. Um hier auf Sperren verzichten zu können, werden Änderungen nicht direkt an den einzelnen Knoten vorgenommen. Für jede Änderung wird ein sogenannter Delta-Knoten erzeugt, auf dem die neue Information, sowie ein Verweis auf den ursprünglichen Knoten abgelegt wird. Alle ursprünglich auf den Knoten zeigenden Verweise zeigen anschließend auf den Delta-Knoten. Eine erneute Änderung erzeugt einen weiteren Delta-Knoten mit Verweis auf den ersten Delta-Knoten. Bei mehr als 16 Knoten findet eine Konsolidierung der Informationen auf einen neuen Knoten statt, um die Verarbeitung wieder zu beschleunigen und den Hauptspeicherbedarf zu senken.

Sequenzielle Sicherung auf der Festplatte

Auch beim Zugriff auf die Festplatte findet das Prinzip, Daten möglichst nicht zu ändern, sondern neue Versionen zu schreiben, Anwendung. Denn selbstverständlich können die Inhalte der speicheroptimierten Tabellen auch auf der Festplatte gesichert werden, um nach einem Neustart der Instanz wieder zur Verfügung zu stehen. Doch auch hier wurden neue Strukturen geschaffen. Als Basis verwendet Microsoft die in der Version 2005 eingeführte Technologie „Filestream“. Aus Sicht der Datenbank werden die Tabellen dabei in separaten Dateigruppen gespeichert. Technisch gesehen sind es Verzeichnisse im Dateisystem.

Hier werden die Daten in 128 MB großen s.g. Datendateien abgelegt. Diese werden immer nur sequenziell geschrieben. Werden Datensätze gelöscht, so werden diese nicht aus den Dateien entfernt, sondern Einträge in einer zusätzlichen Datei (Deltadatei) erzeugt. Für jede Datendatei existiert immer genau eine zugehörige Deltadatei.

Ein Hintergrundprozess analysiert regelmäßig die Anzahl der noch aktiven Zeilen in den Datendateien und fügt zwei oder mehr benachbarte Datendateien zu einer Datei zusammen, wenn sie jeweils weniger als 50 % aktive Zeilen beinhalten.

Schnellerer Zugriff durch native Kompilierung

Die Zugriffe auf hauptspeicheroptimierte Tabellen erfolgen zwar aus Sicht des Anwenders mit den klassischen SQL-Befehlen (select, insert, update, delete). Der direkte Zugriff auf die Daten im Hauptspeicher erfolgt jedoch mittels DDL-Statements, die bei der Erstellung der Tabelle erzeugt, kompiliert und anschließend geladen werden. Aus diesem Grund ist es auch nicht möglich, eine solche Tabelle nachträglich noch zu verändern.

Für eine weitere Steigerung der Performance können die benutzerdefinierten Prozeduren, die ausschließlich auf hauptspeicheroptimierte Tabellen zugreifen, kompiliert abgelegt und verwendet werden.

Fazit

Mit „In-Memory OLTP“ hat Microsoft neue Wege beschritten und erreicht damit eine signifikante Steigerung der Verarbeitungsgeschwindigkeit. Je nach Art der Verarbeitung kann ein Faktor von 5 bis 20 erreicht werden.

Um diese Steigerung erreichen zu können, muss aber auch in der Applikation unter Umständen neue Wege gegangen werden. Bei der Ermittlung der notwendigen Änderungen unterstützen wir Sie gerne.

Für einen tieferen Einblick in die technischen Details empfehlen wir das Whitepaper von Kalen Delaney [2].