Thomas Reinwart
Derzeit arbeitet Microsoft an der nächsten Generation des SQL Servers. Das ist auch notwendig, denn relationale Datenbanksysteme haben sich in ihrer Architektur in den letzten 20 Jahren nicht verändert. Das Konzept vieler Datenbank Hersteller beruht immer noch darauf, dass die Daten auf herkömmlichen Datenträgern physisch persistiert sind. Die Hardware hat sich aber inzwischen radikal geändert – man denke nur an Kapazität, Durchsatz, Zugriffszeiten, dem Preis/Leistungsverhältnis und den neuen Technologien wie SSD und den fallenden Memory Preisen. Ebenso haben sich die Anforderungen geändert – so dass Handeln angesagt ist.
In unserer Zeit spielt sich alle nur mehr online und in Echtzeit ab, alles muss 24x7 Verfügbarkeit sein. Ist es das nicht, steht man mit seiner Ausfallzeit in den Medien und ist negativ bekannt. Just in Time Datenverarbeitung ist angesagt und jede erdenkliche Auswertung muss sofort am Tisch liegen.
Die bisherige Architektur der meisten Datenbank Systeme beruht darauf, dass ein dahinter liegender Prozess die Daten zyklisch auf die Platte schreibt, also ein permanenter I/O Zugriff erfolgt. Ebenso gibt es einen I/O Zugriff auf einer HDD beim Lesen. Der Zugriff/Seek auf die Disk bedeutet intern auch zusätzlich Speicherzugriff und CPU-Verbrauch Somit gilt es, diesen Flaschenhals zu optimierten. Der Trend heißt In-Memory-Datenbanken, die Datenbank wird also komplett in RAM gehalten, was von den Zugriffzeiten natürlich einem enormen Steigerungspotenzial bietet.
Wie kommen meine Daten ins Memory und was passiert bei einem Systemcrash?
Das sind natürlich berechtigte Fragen.
Nun, zu Beginn also beim Starten der Datenbank werden die Daten ins Memory geladen, nur jene, die man auch möchte. Je nach Umfang der Daten der Größe des RAMS kann das einmalig etwas dauern.
Die im RAM gehaltenen Daten müssten natürlich weiterhin auf einem physischen Speichermedium persistiert werden. Bei bestimmten periodischen Snapshots werden die Daten mittels Transaction Logging auf ein physisches Medium geschrieben. Es gehen niemals Daten verloren, die Datenbank ist ACID kompatibel.
Mit ACID werden die Eigenschaften (atomicity, consistency, isolation, durability), also die Zuverlässigkeit in Datenbank Management System und verteilten Systemen beschrieben.
Was bedeutet dies für meine bestehende Datenbank und Anwendung, muss ich etwas anpassen oder ist die nicht mehr kompatibel?
Die Datenbank wird sich den Systemgegebenheiten anpassen. Dies bedeutet, es nimmt sich so viel RAM wie möglich, greift jedoch erst auf die übliche I/O-Technik des SQL Servers zurück, wenn kein RAM mehr zur Verfügung steht. Es können einzelne Tabellen oder ganzen Datenbanken ins Memory geladen werden. Das Schema ist immer persistiert. Die Daten können wahlweise persistiert werden.
Stored Procedures (SP) werden mit SQL Server 2014 nicht mehr interpretiert, sondern kompiliert. Am Server wird eine SP als dll abgelegt und somit zur Laufzeit als Maschinencode ausgeführt. Die Kompilierung erfolgt im Hintergrund. Dadurch spart der SQL Server viel Zeit, da der auszuführende Code bereits in binärer Form vorliegt. Der Aufruf der SP hat sich in der Verwendung nicht verändert, wenn man SPs anpasst, erfordert dies nur Änderungen am Server. Am Client sind daher keine Anpassungen notwendig.
Die bisherigen Stored Procedures sahen folgendermaßen aus:
CREATE PROCEDURE [dbo].[InsertOrder]
@id tOrderId,
@description tDescription
AS
BEGIN
INSERT [MyDatabase].dbo.Orders
(orderId,
created,
description)
VALUES
(@id,
GETDATE(),
@description)
RETURN 0
END
Mit SQL Server 2014 (in memory tauglich) sehen SPs nun so aus:
CREATE PROCEDURE [dbo].[InsertOrder]
@id nvarchar(50),
@description varbinary(7000)
WITH NATIVE_COMPILATION, SCHEMABINDING, EXECUTE AS SELF AS
BEGIN ATOMIC WITH (TRANSACTION ISOLATION LEVEL = SNAPSHOT, LANGUAGE = ‘English‘)
INSERT [MyDatabase].dbo.Orders
(orderId,
created,
description)
VALUES
(@id,
GETDATE(),
@description)
RETURN 0
END
SQL Server 2014 CTP1
http://www.microsoft.com/en-us/sqlserver/sql-server-2014.aspx
Für welche Ausbaustufe (schon ab Professionell oder doch nur Enterprise) das Produkt final vorliegen wird, lässt sich noch nicht sagen. Da grundsätzlich die Hardwarevoraussetzungen viel Memory fordern, wird die Express-Variante für daheim wohl ausfallen.
SQL Server 2014 besitzt eine Memory optimierte OLTP Engine, die tief im SQL Server integriert ist. Das Produkt befindet sich derzeit noch in der Entwicklung, die erste Vorschau wird mit der CTP1 nun angeboten. Natürlich arbeiten derzeit auch andere Datenbank-Hersteller an einer solchen Technik. Es wird spannend, ob am Ende alle Hersteller von In-memory-Datenbanken in etwa den gleichen Geschwindigkeitszuwachs erreichen und wer einen Vorsprung für sich erzielen kann.