COMPAREX AG
Warum Sie sich mit dem SQL Server 2016 von Microsoft auseinander setzten sollten

Warum Sie sich mit dem SQL Server 2016 von Microsoft auseinander setzen sollten

Microsofts Cloud-Lösung Azure erfreut sich nicht nur steigender Beliebtheit, sondern auch eines stetig wachsenden und damit auch breitgefächerten Funktionsumfangs. Dieser Entwicklung folgt nun der SQL Server 2016. Wesentliche Neuerungen beziehen sich zum einen auf die Anbindung an Microsoft Azure und zum anderen auf die Übernahme von Features. Somit können auch Unternehmen, die nur den SQL Server 2016 einsetzen wollen, von den aktuellen Neuerungen profitieren.

Ein Blogbeitrag von Frank Sander, SQL Server Consultant

SQL Server: Die Sicherheit im Blick

Mit der transparenten Datenverschlüsselung (TDE) und der Verschlüsselung auf Spaltenebene, bietet Microsoft seit dem SQL Server 2008 die Möglichkeit, sensible Daten in verschlüsselter Form zu verwalten. Diese haben aber, abhängig vom jeweiligen Anwendungsfall, zwei mögliche Nachteile.

  • Zum einen findet die Ver- und Entschlüsselung innerhalb des SQL Servers statt, hochprivilegierte Nutzer innerhalb des SQL Servers wie Sysadmins können sich daher ohne Mühe Zugriff auf die Daten verschaffen.
  • Andererseits muss die Verschlüsselung der Kommunikation zwischen Client und SQL Server bei Bedarf separat eingerichtet werden.

Always Encrypted, d.h. die clientseitige Ver- und Entschlüsselung der Daten, bietet eine Lösung für beide Probleme. Mit ihr gehen allerdings auch Einschränkungen einher, die in der Natur der Sache begründet sind. So können Vergleiche mit regulären Ausdrücken (LIKE-Operator) auf verschlüsselten Spalten genauso wenig wie „größer/kleiner als“-Vergleiche ausgeführt werden. Damit können z.B. verschlüsselte Spalten nicht gleichzeitig Partitionierungsspalten sein. Mit einer erhöhten Prozessorauslastung des Clients ist zu rechnen.

Es gilt also abzuwägen, ob eine Datenbank nicht oder vollständig verschlüsselt (TDE) wird, oder ob eine Kombination aus nicht verschlüsselten Spalten, Verschlüsselung auf Spaltenebene und Verschlüsselung mittels „Always Encrypted“ eingesetzt wird.

Des Weiteren ist es seit dem SQL Server 2014 möglich, Datenbank-Sicherungen zu verschlüsseln. Bisher war dies nur indirekt über die Verwendung von TDE möglich. Außerdem besteht die Möglichkeit, Sicherungen in Azure zu speichern. Dies ist aufgrund der Geo-Redundanz gerade für Unternehmen mit nur einem Rechenzentrum interessant. Denn bei moderaten Preisen wird die Datensicherheit in einem Katastrophenfall deutlich erhöht.

Ähnliches gilt für Replikate von Always-On-Verfügbarkeitsgruppen nach Azure. Mit dem SQL Server 2016 bietet sich in solch einem hybriden Szenario die Möglichkeit, eine Notfallwiederherstellung mittels asynchroner Replikate mit der Geo-Redundanz von Azure und der clientseitigen Verschlüsselung der Daten von Always encrypted zu kombinieren. Dies könnte den Vorbehalt gegenüber Cloud-Lösungen bezüglich des Datenschutzes entkräften. Außerdem kann man beispielsweise für ein Berichtswesen, das keinen synchronen Datenstand voraussetzt, eine Last-Balancierung durch Zugriff auf das Azure-Replikat erreichen. Ein synchrones Azure-Replikat ist nicht vorgesehen. Es würde den oftmals schon vorhandenen Flaschenhals „Festplattenzugriffe bei Datensatzänderungen“ aufgrund der Netzwerk-Latenz nur noch verstärken.

Stretch Database bei SQL Server

Ein weiteres Feature von SQL Server 2016 ist Stretch Database. Dabei können Tabellen ganz oder anhand eines Filterprädikates teilweise nach Azure ausgelagert werden. Durch die mögliche Skalierbarkeit innerhalb Azures können strengere SLAs erfüllt werden, Wartungsaufgaben schneller durchgeführt und Anfragen wesentlich rascher beantwortet werden. Dies macht vor allem bei sehr großen Tabellen mit hunderten Millionen Datensätzen bzw. einer Größe im Terabyte-Bereich Sinn. Gerade wenn Daten aufgrund von Vorschriften viele Jahre aufbewahrt werden müssen und ältere Daten sehr wenig genutzt werden, jedoch verfügbar sein müssen, ist der Einsatz einer Stretch Database sinnvoll. So können zum Beispiel in Kombination mit Always Encrypted sensible Spalten verschlüsselt sowie Datensätze anhand des Erstellungsdatums partitioniert werden. Ältere werden nach Azure ausgelagert. Der Vorteil einer Stretch Database ist, meiner Meinung nach, dass Datenbank-Administratoren dies auch bei einer sich schon in Betrieb befindenden Datenbank einrichten können. Die schon mögliche Partitionierung auf verschiedene Dateigruppen mit z.B. historischen und aktuellen Daten, muss von Datenbank-Entwicklern eingerichtet werden. Oftmals findet dies aber in der Entwicklungsphase nicht statt, sei es aufgrund fehlender Spezifikation oder einem zu gering eingeschätzten Datenwachstum.

Bei allen hybriden Szenarien sollten allerdings zwei Aspekte immer berücksichtigt werden. Zum einen ist dies die Auswirkung des geplanten Szenarios auf die Performance. Während in Azure umgesetzte Rechnerleistung zu Performance-Gewinnen führt, kann es auch zu Performance-Einbußen kommen. Und zwar immer dann, wenn eine große Menge an Daten zwischen Microsoft Azure und dem On-Premises-System transportiert werden muss. Zum anderen kann der Datentransport, ausgehend von Azure, neben den anfallenden Bereitstellungskosten ein zusätzlicher Kostenfaktor sein, zum Beispiel bei einem Berichtswesen mit Zugriff auf ein lesbares Azure-Replikat.

Business Intelligence mit SQL Server

Für statistische Auswertungen von Daten ist die Programmiersprache R in vielen Fällen die erste Wahl. Allerdings unterliegt die Verwendung von R mit SQL Server bis einschließlich Version 2014 diversen Einschränkungen. Die Daten müssen von dem SQL Server zum Rechner transportiert werden, auf dem R Runtime installiert ist. Neben Sicherheitsrisiken ist das immer größer werdende Datenvolumen ein erhebliches Problem an dieser Stelle. Um R selbst in eine bestehende Applikation zu integrieren, muss diese meist separat angepasst werden, eine weitere mögliche Fehlerquelle. Letztendlich hat R Performance-kritische Einschränkungen. Es ist nicht multithreadfähig und die auszuwertenden Daten müssen in den RAM passen. Diese Einschränkungen wurden mittels R-Services gelöst. R-Skripte werden innerhalb des SQL Servers 2016 wenn nötig parallel und unter Ausnutzung von Indexen ausgeführt. Nur die Anfrage und das Ergebnis müssen transportiert werden, nicht aber die Daten. Dadurch ergibt sich gerade für große Datenmengen ein signifikanter Performance-Gewinn. Außerdem entfallen dadurch die schon erwähnten Sicherheitsrisiken. Nutzer einer R-IDE können dabei einfach eine Verbindung zum SQL Server innerhalb ihres R-Skripts definieren, um R-Services zu nutzen. Applikationen hingegen können gespeicherte Prozeduren, in denen das entsprechende R-Skript hinterlegt ist, aufrufen und erhalten wie gewohnt das Ergebnis. Dieses Feature birgt für Datenanalysten gravierende neue Möglichkeiten.

Auf der anderen Seite wurde das Berichtsdesign von SQL Service Reporting Services (SSRS) vollständig überarbeitet. Hierbei handelt es sich um ein in allen Editionen enthaltenes Feature zur Erstellung, Veröffentlichung und dem Abonnieren von Berichten. Zusätzlich bietet es nun die Möglichkeit für mobile Endgeräte optimierte Berichte zu erstellen. Diese Änderung mag nicht so gravierend sein, wird aber bei vielen Nutzern von SSRS Anklang finden.

Mein Fazit

Der Schwerpunkt bei den SQL Server 2016 Neuerungen liegt in der Kombination mit Microsoft Azure. Dort werden vor allem bestehende, hybride Möglichkeiten durch neue Sicherheitsaspekte ergänzt, von denen auch On-Premises-Lösungen profitieren. Stretch Datenbaken und lesbare Azure-Replikate stellen für Administratoren neue Möglichkeiten dar, um die Performance bei großen Datenbanken zu steigern. Oftmals geht die Einführung neuer Features aufgrund einer veröffentlichungsorientierten Entwicklungsstrategie seitens Microsoft mit Einschränkungen einher. Zum Beispiel gibt es für Stretch Datenbanken und Always Encrypted Einschränkungen bezüglich des Datentyps der entsprechenden Tabellenspalte. Genaueres hierzu findet man in der Dokumentation. Bei den kommenden Versionen von SQL Server ist mit dem Abbau dieser Einschränkungen zu rechnen. Sollte also ein Feature interessant, aber noch mit zu vielen Einschränkungen versehen sein, lohnt sich auch der Blick auf kommende Versionen.

Sollten mittels SQL Server allerdings nur kleine bis mittlere Datenbanken ohne Lastspitzen in älteren Versionen betrieben werden, gestaltet sich die Suche nach dem Must-Have-Feature bei SQL Server 2016 bisweilen schwierig. Datenbank-Administratoren werden sich in diesem Fall eher am Supportende und der dann aktuellen Version orientieren.

SQL 2016 Workshop Reihe – Next Generation

Erfahren Sie, was der SQL Server 2016 kann, was er nicht kann, wann sich eine Migration lohnt und wie die Lizenzierung funktioniert.

Die eintägigen Workshops finden in sechs Orten in Deutschland statt und sind für Sie kostenfrei. Empfohlen für IT-Administratoren und IT-Entscheider.

Ich möchte mich anmelden »

Diesen Artikel teilen

Artikel vom:
13.12.2016

geschrieben von:

TAGS:
Datenbanken, Microsoft, SQL-Server

Thema:

Kommentieren sie diesen Artikel...

© COMPAREX AG
Zurück nach oben