Die CPU-Entwicklung stößt an physikalische Grenzen und Leistung moderner Storage-Systeme wächst langsamer als die verfügbare Speicherkapazität. RAM ist zeitgleich so günstig und so schnell wie noch nie.
Die Idee, Datenbanken weitgehend im RAM zu betreiben, zwängt sich einem als logische Folge dieser Entwicklung geradezu auf. Nun weiß jeder, dass RAM nach einem Stromausfall leer ist. Sogenannte „Speicheroptimierte Tabellen“ werden also auf der Platte „persistiert“. Transaktionen finden aber vollständig im RAM statt. Der Performancevorteil ist nicht nur in der Theorie beachtlich. Was wie eine geniale Idee klingt, bringt im Detail aber leider etliche Probleme mit sich. Einige davon sollen hier erwähnt werden:
Möglichen Datenverlust beschreibt Microsoft schon in einem MSDN-Artikel zu In-Memory OLTP. Datenverlust kann entstehen, wenn Daten zwar in einer bereits abgeschlossenen Transaktion in die Tabelle ins RAM übertragen, aber noch nicht auf der Platte persistiert wurden. In diesem Moment – mag er noch so kurz andauern – kann bei einem Systemausfall Datenverlust entstehen. Im Vergleich zu dem Datenverlust einer unvollständigen Transaktion bekommt in diesem Fall der Client ggf. keine Meldung über den Datenverlust – und somit der Benutzer ebenfalls nicht.
Die Eingeschränkte Nutzung speicheroptimierter Objekte stellt eine weitere Hürde dar. Zum einen dürfen bei In-Memory-Tabellen nicht alle Datentypen verwendet werden (Weder LOB- noch CLR-Typen), zum anderen sind auch noch die SQL-Statements in ihrem Umfang bei diesen Objekten eingeschränkt. Bspw. kann man sich von Einschränkungen wie CHECK oder UNIQUE verabschieden. Auch IDENTITY-Spalten haben in solchen Objekten keinen Platz gefunden. Noch schmerzlicher vermisst werden FOREIGN KEYS. Weiter geht´s mit den Einschränkungen für In-Memory-Prozeduren. Diese müssen bspw. ohne Optionen wie DISTINCT oder die Funktionen UNION, EXCEPT sowie die gerade erst eingeführte OFFSET-Funktion auskommen. Das sind nur Beispiele, die Liste ist lang. Wem das jetzt alles nichts sagt, dem sei versichert, dass der Großteil der bestehenden Datenbankanwendungen regen Gebrauch von diesen Funktionalitäten macht.
Eine Bewertung des In-Memory-Ansatzes fällt nun schwer. Man könnte versuchen, sich mit einer der folgenden Sichtweisen anzufreunden:
Migrationen bestehender Datenbanken werden trotz des im MSDN-Artikel vorgeschlagenen Weges sowie der Tipps für die Auflösung der „verbotenen“ Funktionen hin zu „erlaubten Workarounds“ auch mit Tool-Unterstützung kein Pappenstiel sein. Schon die Abschätzung eines solchen Vorhabens ist nicht ohne. Die Workarounds lassen sich in einfachen Fällen problemlos anwenden. Oft wird das aber komplex und aufwendig sein. Für eine solche Migration sollte es also gute Gründe geben. Es ist auch nicht auszuschließen, dass es Fälle gibt, in denen eine Migration (relativ) problemlos durchführbar ist.
Bei neuen Projekten ist der In-Memory-Ansatz sicherlich ins Kalkül zu ziehen. Auch wenn die Liste der „Verbote“ für einen Entwickler (vielleicht sogar noch vielmehr für den Architekten) ein Mienenfeld darstellt, kann dies natürlich als Herausforderung gesehen werden – oder einfach als der „Preis für überdurchschnittliche Performance“ verstanden werden. Aber nicht nur die höheren Umsetzungskosten einer In-Memory-Lösung machen den Ansatz ein Stück weit unattraktiv. Man bedenke auch den drohenden Datenverlust sowie mögliche Probleme durch eingeschränkte Referenzielle Integrität usw. – also die qualitativen Einbußen. In-Memory ist kein Ansatz für jede „Ottonormaldatenbank“. Microsoft nennt selbst verschiedene Szenarien, bei denen potenziell Engpässe bei herkömmlichen Architekturen auftreten. Gemeint sind hierbei nicht die üblichen Wartezeiten bei der einen oder anderen komplexen Abfrage.
Ich bin ehrlich gesagt gespannt auf das erste Projekt mit In-Memory-Ansatz. Diese Neuerung ist gut und zeitgemäß, auch wenn sie nur für spezielle Fälle anwendbar sein wird. Sicher wird es trotz aller Kritikpunkte Projekte geben wird, in denen In-Memory zeigen wird, was es zu leisten vermag. Außerdem bin ich mir sicher, dass einige Nachteile von Microsoft in den nächsten Versionen noch beseitigt werden.