SQL Server 2014: In-Memory-Datenbank mit Cloud

ITMAGAZINE
SQL Server 2014: In-Memory-Datenbank mit
Cloud-Anschluss
8. März 2014 - Von Meinrad Weiss
Mit dem 2014er-Release des SQL Server, der in Kürze erscheint, adressiert Microsoft grosse Trends wie
In-Memory und Cloud Computing. 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.
Copyright by Swiss IT Media 2017