SQL Server 2014: In-Memory-Datenbank mit Cloud-Anschluss

SQL Server 2014: In-Memory-Datenbank mit Cloud-Anschluss

Artikel erschienen in IT Magazine 2014/03

Clustered-Columnstore-Indizes

Beispiel-Report aus dem Management Data Warehouse zur Identifikation der Migrationskandidaten. (Quelle: Microsoft)
Wie schon erwähnt, erlaubt es bereits SQL Server 2012 solche Columnstore-Indizes zu erstellen und so ohne weitere Anpassungen die Abfragen zu beschleunigen. Da die Columnstore-Indizes aber immer zusätzlich zur regulären Tabelle angelegt werden, kann von der Komprimierung nur bedingt profitiert werden. Zudem bedeutet das Anlegen eines Columnstore-Index, dass die Basis-Tabelle zu einem read-only Objekt wird und die Daten nicht mehr verändert werden können. Das hat zur Folge, dass entweder der Index im ETL-Prozess (Extract, Transform, Load) gelöscht und nach dem Load der Daten neu angelegt wird oder dass die Applikation dazu gezwungen wird, mit Partitionen zu arbeiten.

SQL Server 2014 erlaubt es, Clustered-Columnstore-Indizes zu verwenden. Das bedeutet, dass die Daten überhaupt nicht mehr page-orientiert gespeichert werden, sondern vollständig spaltenorientiert abgelegt sind. Damit kann voll von der hohen Komprimierung profitiert werden und der Platzbedarf lässt sich so um Faktoren senken. Zudem lassen sich die Daten der Tabelle nach wie vor verändern und die DWH-Abfragen können von den Performance-Vorteilen profitieren.


Neben den offensichtlichen Vorteilen der Clustered-Columnstore-Indizes dürfen aber deren Konsequenzen nicht aus den Augen verloren werden. Einerseits ist zu berücksichtigen, dass eine Clustered-Columnstore-Tabelle keine weiteren Indizes, keine Computed Columns, keine DML-Trigger und auch keine Foreign-Key Constraints besitzen darf. Andererseits ist anzumerken, dass die spaltenorientierte Speicherung vor allem für typische, interaktive DWH-Abfragen optimal ist. Full Table Scans sind hingegen mit einem recht grossen Overhead verbunden. In Umgebungen, in welchen zum Beispiel Analysis Services Cubes oder Tabulare-Modelle verwendet werden, bedeutet das, dass der Ladeprozess tendenziell länger dauern wird. Aus diesem Grund wird sich wohl eine Mischung aus traditionellen Tabellen mit Columnstore-Indizes und reinen Clustered-Columnstore-Tabellen durchsetzen.

In-Memory OLTP

Im Gegensatz zu Columnstore-Indizes, die durch ihre hohe Komprimierung hauptsächlich im Memory gehalten werden können und für Data-Warehouse-Workloads geeignet sind, werden die schon angesprochenen «Memory-Optimized Tables» konstant und vollständig im Memory gehalten. Sie sind damit primär für OLTP-Applikationen geeignet. Zusätzlich und optional dazu kann mit kompiliertem Code auf die Memory-Strukturen zugegriffen werden. So kann das Optimum an Performance herausgeholt werden. Performance-Verbesserungen um den Faktor 100 sind dabei keine Seltenheit. Die Tatsache, dass Microsoft bei den Memory-Optimized Tables standardmässig mit Row-Versioning arbeitet und so komplett auf Locks und Latches verzichten kann, ist ein weiterer Grund für den Performance-Boost. All diese Optimierungen nehmen Rücksicht auf moderne Multi-Core-Hardware, welche oft auch mit sehr viel RAM ausgestattet ist.

Obwohl die In-Memory-OLTP-Features in den Datenbank-Kernel integriert sind, braucht die Einführung meist eine Anpassung des vorhandenen Codes. Nicht alle Applikationsteile sind einfach zu migrieren und profitieren gleichermassen von der Umstellung. SQL Server 2014 unterstützt den Prozess zur Identifikation der Komponenten, welche idealerweise adaptiert werden sollten. Im integrierten Management Data Warehouse sind spezielle Reports vorhanden, welche aufzeigen, wie aufwendig die Migration ist und welche Elemente von der Migration profitieren.

Neuen Kommentar erfassen

Anti-Spam-Frage Vor wem mussten die sieben Geisslein aufpassen?
Antwort
Name
E-Mail
SPONSOREN & PARTNER