SQL Server 2016 - in-Memory OLTP

Die letzten Monate habe ich recht viel Zeit damit verbraucht Kunden im Rahmen von Workshops, PoCs und Projekten das Thema in-Memory OLTP und unsere Erfahrungen damit im SQL Server 2014 und SQL Server 2016 näher zu bringen. Bekannt wurde das Feature ja vor einiger Zeit als Projekt “Hekaton” für den SQL Server 2012.

Seinerzeit war das Interesse bei den Kunden sehr verhalten. Sowohl Endkunden als auch ISVs haben das Thema zwar wahrgenommen, aber da es ja erst mit 2014 realisierbar war, führte dieses bei den meisten zu einer “Das ist etwas für später…”-Meinung. Wenige haben für sich das Potenzial von in-Memory OLTP erkannt.

Das letzte halbe Jahr hat sich dieses geändert. Mit der Sichtbarkeit des Commitments von Microsoft in diese Technologie, von einem Feature mag ich da gar nicht mehr sprechen wollen, wurde vielen Nutzern des SQL Servers klar, dass sich das Spiel ändern wird bzw. eigentlich schon geändert hatte.

Nun, im SQL Server 2016, durch die Kombination von Technologien (Columnstore Index und in-Memory OLTP) zu Operational Analytics ist der Umfang der Änderungen bzw. Erweiterungen an der Architektur der SQL Server Engine deutlich sichtbarer geworden. Marketing ist halt doch alles. Hier mal ein gutes Beispiel.

Und für viele ist damit nun ein Wettbewerbsvorteil möglich, welchen man nicht mehr ignorieren kann.

Was machen wir da draußen schon mit in-Memory OLTP?

In den Workshops und PoCs erfahren und erleben die Kunden, wie leicht es geworden ist eine für sie bisher unvorstellbare Geschwindigkeit ihres Workloads auf ihrer bestehenden Hardware zu realisieren. Und ja, es ist kein “ein-und-läuft”-Feature. Viele Kunden entwickeln mittlerweile ihre LoB Systeme zum Teil selber und sind sehr darauf bedacht sich am Ende keinen Flaschenhals bei der Datenbank einzubauen.

In Projekten werden meist partiell Tabellen vom sogenannten “disk-based” Modell übertragen in die in-Memory Welt. Dabei sind häufig gar nicht die eigentliche Tabelle und die neuen Formen der Indizierung die Herausforderung, sondern ist eher die intellektuelle Hürde, dass nun mit einem Versionstore gearbeitet wird und sich die Isolationslevel ein wenig anders anfühlen. Hilft ja alles nichts. Da kommt ja auch ein wesentlicher Teil der Geschwindigkeit her.

Des Weiteren leiten wir Teams an sich dieser Technologie kreativ zu nähern. Zwar steht ja OLTP drauf, aber das heißt ja nichts. Gerade mit der Möglichkeit auf die “Durability” bewusst zu verzichten, können ganz besondere Number Cruncher in T-SQL entstehen. Besonders, wenn der T-SQL Code dann auch kompiliert werden konnte.

Und wir bringen in-Memory OLTP in Produktion. Das ist nicht immer ganz einfach, da bei dieser spezialisierten Engine ein wenig von der Flexibilität des SQL Servers abhanden kam. Dieses ist aber meist verkraftbar, wenn man sich die Vorteile vor Augen führt. Speziell Deployment Szenarien beim rund-um-die-Uhr-Betrieb können dabei Herausforderungen sein, welchen man bereits in der Designphase einer Lösung begegnen muss. Wobei, DevOps lässt hier grüßen. Und wer schon mal mit unseren Entwicklern in Berührung gekommen ist, kennt unsere repository-driven Ansätze für größere Umgebungen.

Resümee von mir: in-Memory OLTP lebt!

Popular posts from this blog

PSG Performance Driven Development für den SQL Server

SQL Server in-Memory OLTP – Ein Plädoyer für Lasttest Werkzeuge und End-to-End Monitoring

SQL Server In-Memory OLTP – Isolation Level Beispiele