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

Microsofts SQL Server 2014 ist im Anmarsch. In den nächsten Tagen werden die Redmonder den neuen Release ihrer beliebten Datenbanklösung veröffentlichen. Kurz zusammengefasst lassen sich die Neuerungen in folgende drei Schwerpunkte einteilen: In-Memory für OLTP (Online Transaction Processing) und Business-Intelligence-Applikationen, Einbindung in Azure (Cloud) und höhere Verfügbarkeit respektive verbessertes Management. «Swiss IT Magazine» hat die neuen Funktionen des SQL Server im Vorfeld des grossen Launches kritisch unter die Lupe genommen.

In-Memory mit SQL Server 2014

Der In-Memory-Trend für Datenbanksysteme geht offensichtlich nicht spurlos an SQL Server vorbei. Bereits seit der Version 2012 können Data-Warehouse (DWH)-Systeme von Columnstore-Indizes profitieren. Mit SQL Server 2014 wird die Columnstore-Funktionalität weiter ausgebaut und zusätzlich auch der OLTP-Bereich abgedeckt. Dafür stehen neu In-Memory-Tabellen, sogenannte Memory-Optimized Tables und Compiled Stored Procedures zur Verfügung. Aber der Reihe nach.


Traditionell werden die Daten in relationalen Datenbanken row-orientiert in Data Pages gespeichert. Das bedeutet, dass alle Attribute einer Datarow zusammenhängend abgelegt sind. Diese Speicherform ist für OLTP-Systeme sehr gut geeignet, da bei einem Zugriff meist ein Grossteil der Attribute einer Row verwendet werden und meist auf einzelne Rows zugegriffen wird. Data-Warehouse-Systeme arbeiten aber typischerweise mit einem anderen Zugriffsmuster. Oft werden nur einzelne Attribute gelesen, mehrere Rows angesprochen und das Resultat wird durch Gruppierung gebildet. Solche Abfragen können row-orientiert kaum optimal umgesetzt werden. Für Data-Warehouse-Abfragen ist eine spaltenorientierte Speicherung darum oft deutlich besser geeignet und führt meist zu einer erheblichen Steigerung der Performance. Zudem können die Daten viel besser komprimiert werden, was im DWH-Umfeld ein riesiger Vorteil ist.

Clustered-Columnstore-Indizes

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.

Migration bestehender Applikationen

Die Migration bestehender Applikationen ist am einfachsten, wenn nur die vorhandenen Tabellen ins Memory migriert werden. Diese können wie gewohnt mit T-SQL angesprochen und mit traditionellen Objekten in Join-Abfragen kombiniert werden. Wenn aber Performance im Vordergrund steht, dann ist der Schritt zu Compiled Stored Procedures notwendig. Diese werden beim Erstellen optimiert und direkt in eine DLL kompiliert. Im aktuellen Release können Compiled Stored Procedures nur auf Memory-Optimized Tables zugreifen und auch der T-SQL-Support ist noch sehr eingeschränkt. Dafür lässt sich so das Maximum an Performance aus dem Datenbank-System herausholen.


In vielen Fällen wird es aber reichen, wenn nur die Tabellen in Memory gehalten werden und mit nicht kompiliertem SQL-Code darauf zugegriffen wird. In diesem Fall ist praktisch der komplette SQL-Funktionsumfang unterstützt. Zu berücksichtigen sind aber auch hier die Einschränkungen bezüglich Datentypen und die fehlende Unterstützung oft verwendeter Funktionen wie Identity Column, Check und Foreign-Key Constraints, Computed Columns und Replication. Zudem geht bei der aktuellen Version von SQL Server mit der Umstellung auf Memory-Optimized Tables einiges an Flexibilität verloren. So ist es zum Beispiel nicht möglich, die Struktur der Tabellen anzupassen. Weder eine Veränderung der Attribute noch das Hinzufügen oder Entfernen von Indizes sind erlaubt. Wenn solche Anpassungen notwendig sind, muss eine neue Tabelle erzeugt und die Daten müssen migriert werden.

Architektur der neuen Memory- Optimized Tables

Die Architekten von Microsoft haben grössten Wert darauf gelegt, den IO auf ein Minimum zu reduzieren. So werden zum Beispiel die Index-Seiten nur im Memory gehalten und ein Index-Update verursacht daher keinen IO in der Daten-File-Gruppe und auch nicht im Log File. Wenn der Rechner neu gestartet wird, dann müssen sowieso alle Daten der Memory-Optimized Tables von der Disk ins Memory gelesen werden. In diesem Schritt werden auch die notwendigen In-Memory-Index-
Strukturen neu aufgebaut. Unterstützt werden sowohl Hash- wie auch Range-Indizes.

Bei temporären Tabellen kann sogar noch ein Schritt weitergegangen werden. Beim Erstellen von Tabellen kann festgelegt werden, ob nach einem Neustart des Servers Struktur und Daten (DURABILITY=SCHEMA_AND_DATA) oder nur die Struktur (DURABILITY=SCHEMA_ONLY) wieder vorhanden sein sollen. Bei Tabellen, welche mit der Option DURABILITY=SCHEMA_ONLY angelegt werden, entfällt der IO auf dem Log File bei DML-Operationen (Data Manipulation Language) komplett. Solche temporären Tabellen können sowohl im OLTP-Umfeld wie auch im Data-Warehouse-Umfeld für die Optimierung von ETL-Prozessen eingesetzt werden.


Was passiert aber, wenn das Memory nicht ausreicht, um die Daten darin abzulegen? Auch hierfür ist die Antwort sehr einfach. Die Datenbestände ändern sich nur mit DML-Befehlen. Falls das Memory nicht ausreicht, dann schlägt der entsprechende Befehl fehl. Die Datenbank wird in den Bereich zurückgefahren, in welchem das Memory ausreicht. Anschliessend kann entschieden werden, ob das Statement angepasst oder das Memory des Servers ausgebaut werden muss. Aber auf jeden Fall gehen so keine bereits gespeicherten Daten verloren.

Zusätzlich ist hervorzuheben, dass auch die In-Memory-Funktionen zu 100 Prozent in die Datenbank integriert sind. Das heisst, dass auch die relevanten Transaktionen im Transaction Log festgehalten werden und alle Daten mit den bekannten Backup-Verfahren gesichert und auch wieder hergestellt werden können.

Always-On-Server in der Cloud

Neben In-Memory gehört die Cloud aktuell sicher zu den heissesten Themen. Mit SQL Server 2014 lassen sich Cloud Services elegant nutzen. Dabei werden folgende Szenarien unterstützt: Always-On Server in Azure, das Nutzen von Azure Infrastructure as a Service (IaaS) für Datenbank-Anwendungen und Backup to Azure.

Die mit SQL Server 2012 eingeführte Always-On-Technologie wird verwendet, um eine hohe Verfügbarkeit des Datenbank-Services beim Verlust einzelner Server garantieren zu können und auch um gegen ein Desaster im Rechenzentrum gewappnet zu sein. Um ein Desaster überstehen zu können, wird ein zweites Rechenzentrum benötigt. Dieses bedeutet traditionell einen hohen finanziellen Aufwand. Mit der Möglichkeit, Azure als zweites Rechenzentrum zu nutzen, können die Kosten sehr einfach reduziert werden. Technisch ist der Aufbau eines Always-On SQL Server in Azure bereits mit SQL Server 2012 möglich. Dabei müssen aber diverse Konfigurationen manuell ausgeführt werden. In SQL Server 2014 wird die Konfiguration direkt durch eingebaute Wizards erledigt.

Vollständiger Datenbank-Service aus Azure

Ebenso einfach wie das Einrichten von Always-On-Rechnern in Azure ist es mit SQL Server 2014, einzelne Datenbanken in die Cloud zu zügeln. Auch dieser Prozess wird jetzt durch einen Wizard unterstützt. Dieser erlaubt es, das Setup des benötigten virtuellen Servers direkt mit der Migration der Datenbank durchzuführen. Auch wenn bei vielen Unternehmen die Produktions-Datenbank in absehbarer Zeit nicht in der Cloud betrieben wird, bietet Azure für Entwicklungs- und Test-Zwecke oft auch hier eine flexible und kostengünstige Alternative.

Backups direkt in die Wolke

Als weitere Option bietet SQL Server 2014 die Möglichkeit, Backups direkt in die Cloud durchzuführen. Die Daten werden dabei komprimiert und verschlüsselt in Azure abgelegt. So können Kunden von den durchaus attraktiven Preisen des Storage-Angebots profitieren und ein aufwendiges Verwalten von Tapes entfällt. Zudem sind die Daten so automatisch ausserhalb des Rechenzentrums gespeichert, was wiederum einen grossen Vorteil im Bereich von Desaster Recovery bietet. Im Desaster-Fall ist es so möglich, einen SQL Server als virtuellen Rechner in Azure zu starten, ein Restore durchzuführen und die Datenbank innert kürzester Zeit wieder on-line zu bringen. Durch die Verschlüsselung der Daten ist auch das Thema Sicherheit der Daten elegant gelöst, da die Verschlüsselungs-Keys auf dem lokalen Server bleiben.


Eine weitere Vereinfachung des Backups von Datenbanken wird mit dem sogenannten Managed Backup to Windows Azure erreicht. Dieses kann für eine ganze Instanz oder für einzelne Datenbanken eingerichtet werden. Dabei muss lediglich festgelegt werden, in welchen Container in Windows Azure die Backups abgelegt und wie lange diese aufbewahrt werden sollen. Aktuell werden Werte zwischen einem und 30 Tagen unterstützt. Der Rest wird automatisch von SQL Server erledigt. Je nachdem, wie viele Transaktionen in den so gesicherten Datenbanken durchgeführt werden, erstellt SQL Server die notwendigen Backups. Damit kann mit minimalem Aufwand ein erstklassiges Backup-Konzept umgesetzt werden. Schade ist nur, dass das Managed Backup ausschliesslich mit Windows Azure verwendet werden kann und die Backups nicht auch auf lokalen Drives erstellt werden können.

Zahlreiche weitere Neuerungen

Um auch extremste Datenmengen effizient verwalten zu können, bietet SQL Server schon seit längerer Zeit die Möglichkeit der Partitionierung von Tabellen. Neu ist es möglich, Indizes auf einzelnen Partitionen on-line zu reorganisieren. Die Reorganisationen von Indizes wie auch der Switch-In-Prozess benötigten für kurze Zeit ein exklusives Lock (Sch-M) auf den betroffenen Objekten. Bis anhin hat der SQL Server darauf gewartet, dass er das Lock bekommt und alle nachfolgenden Prozesse so lange blockiert, bis er das Lock erhalten hat. Dieses Verhalten hat, zusammen mit lange laufenden Transaktionen, zu unangenehmen Verzögerungen im Betrieb geführt. Neu kann gesteuert werden, wie sich der SQL Server in solchen Situationen verhalten soll. Entweder kann spezifiziert werden, dass blockierende Prozesse ([BLOCKERS]) nach einer spezifizierten Zeit abgeschossen werden oder dass der Prozess, der gerne das exklusive Lock beziehen würde, aufgibt ([SELF]).

Auch am Ressource Governor wurde weiter gearbeitet. Neben den bereits bekannten CPU- und Memory-Ressourcen kann neu auch die IO-Kapazität gezielt einzelnen Prozess-Gruppen zugeordnet werden. Damit wird es möglich, den verschiedenen Benutzern die notwendigen Ressourcen fair zuteilen zu können.
Datensicherheit ist ein immer wichtiger werdendes Thema. Auch hier bietet SQL Server 2014, unter dem Begriff Separation of Duties, einige Verbesserungen an. Damit wird es möglich, dass System-Administratoren ihre Arbeit ausführen können, ohne dass es ihnen möglich ist, die Daten in den von ihnen verwalteten Datenbanken lesen zu können.


Um die mögliche Verfügbarkeit von SQL-Server-Datenbanken weiter zu erhöhen, hat Microsoft die Always-On-Technologie verfeinert. Neben der vereinfachten Unterstützung von Azure können neu bis zu acht Replicas erstellt werden. Zudem bleiben sogenannte Readable Secondories auch dann für Abfragen zur Verfügung, wenn die Verbindung zum Primary oder das Quorum verloren gehen.

Failover Cluster werden, trotz oder sogar in Kombination mit Always-On, immer noch sehr häufig eingesetzt. Bei grösseren Systemen ist es teilweise wünschenswert, mehr Laufwerke verwenden zu können als Laufwerksbuchstaben existieren. Neu können die Daten auch auf sogenannten Clustered Shared Volumes abgelegt werden. Damit lassen sich die Daten-Drives auf Directory-Strukturen abbilden und so die Limite bezüglich der vorhandenen Laufwerksbuchstaben elegant umschiffen.

Auch für ältere OLTP-Systeme kann SQL Server 2014 interessant sein. Neu ist es möglich, den Buffer-Pool mit den sogenannten SSD Buffer Pool Extensions mittels SSDs zu erweitern. Dies hilft vor allem Rechnern, die wenig RAM (z.B. 32 GB) besitzen, dieses nicht erweitert werden kann und die vorhandene CPU-Leistung nicht ausgeschöpft ist. Tests haben gezeigt, dass davon hauptsächlich OLTP-Applikationen profitieren. Schön ist, dass es absolut keine Anpassung der bestehenden Applikation benötigt und so sehr schnell klar wird, ob eine Applikation davon profitieren kann oder nicht.

Fokus auf Datenbank-Kernel

All jene, die sich grosse Erweiterungen im Bereich Integration-, Analysis-, Reporting-, Data-Quality- oder Master-Data-Services erwartet haben, werden von SQL Server 2014 enttäuscht sein, denn hier sind aktuell keine grossen Verbesserungen sichtbar. Microsoft hat sich offensichtlich auf den Datenbank-Kernel fokussiert und versucht, diesen ein grosses Stück weiter zu bringen. Bleibt zu hoffen, dass bald ein nächster Release am Horizont erscheint, der auch in den restlichen Bereichen einen Schub bringen wird.


Der Upgrade auf SQL Server 2014 sollte übrigens in den meisten Umgebungen keine grossen Probleme darstellten, da sich am Fundament von SQL Server kaum etwas ändert und nur neue Features dazukommen. Ein Upgrade von SQL Server 2008 SP3 oder neuer wird unterstützt. Als Upgrade-Optionen bieten sich In-Place, Backup und Restore oder Detach und Attach an.

SQL Server 2014

Fazit
Zusammenfassend lässt sich sagen, dass SQL Server 2014 mit sehr vielen Neuerungen aufwartet. Vor allem die Verbesserungen im Bereich In-Memory lassen SQL Server in neue Sphären vordringen. Die Kombination von Memory-Optimized Tables und Compiled Stored Procedures lassen Transaktionsraten zu, von denen in der Vergangenheit nur geträumt werden konnte. Die Tatsache, dass die neuen Clustered-Columnstore-Indizes auch Daten-Manipulation-Statements zulassen und die enormen Komprimierungsraten, die damit erreicht werden, bringen SQL Server im Data-Warehouse-Umfeld in eine hervorragende Position. Ebenso offensichtlich sind die Vorteile der verbesserten Cloud-Integration. Durch den Sowohl-als-auch-Ansatz, den Microsoft hier verfolgt, kann die Cloud genau dort eingesetzt werden, wo sie auch Vorteile bringt. Zu guter Letzt sind auch die Verbesserungen im Bereich Verfügbarkeit und Management von grossem Nutzen. Die Tatsache, dass alle neuen Features in die bekannte SQL Server Engine integriert sind und mit SQL Server Management Studio verwaltet werden können, erleichtert deren Einführung deutlich.

Neuerungen
- Updatable Tables mit Clustered-Columnstore-Indizes
- In-Memory OLTP mit Memory-Optimized Tables
- Verbesserte Cloud-Integration (Always-On Server in Azure, IaaS, Backup to Azure)
- Höchste Verfügbarkeit
- Separation of Duties


Positiv
+ Integration aller neuen Features in bekannte SQL Server Engine
+ Relevante Datenbank-Trends (In-Memory, Column Storage, Cloud) sind umgesetzt

Negativ
- Einschränkungen bezüglich T-SQL bei In-Memory OLTP
- Keine echten Verbesserungen ausserhalb der Datenbank-Engine

Hersteller/Anbieter
Microsoft

Preis
Auf Anfrage

Wertung
Funktionalität: 5
Bedienung: 6
Preis/Leistung: 5
Gesamt: 5

Der Autor

Meinrad Weiss ist Technology Manager des Bereichs Microsoft bei Trivadis und arbeitet seit über 15 Jahren mit Microsoft und SQL Server als Trainer und Principal Consultant. Zudem bekleidet er das Amt als MSDN Regional Director Switzerland.