michelangelus - Fotolia

Performance-Steigerung: Optionen für das Skalieren des Microsoft SQL Servers

Das Skalieren einer Datenbank bei rechenintensiven Anwendungen kann eine Herausforderung sein. Einige Skalierungsmethoden für Microsoft SQL Server.

Eine der großen Herausforderungen für Administratoren von Microsoft SQL Server war schon immer die Skalierung von Datenbanken. Dies hilft, besonders rechenintensive Anwendungen effizient abarbeiten zu können. Um dies zu gewährleisten, bietet Microsoft verschiedene Skalierungsoptionen für SQL Server an. Nicht jede Option ist allerdings für jede Situation geeignet.

Zunächst stellt sich die grundlegende Frage, ob eine SQL-Server-Architektur vertikal (scale up) oder horizontal (scale out) skaliert werden soll. Ersteres beinhaltet das Verschieben einer Datenbank auf einen größeren Server mit mehr Prozessoren, Memory und Storage. Letzteres verteilt die SQL-Server-Anwendungen auf zusätzliche Server, so dass die rechenintensiven Workloads auf mehreren Einheiten aufgeteilt werden. Dies bietet den Vorteil von Datenredundanz und hoher Verfügbarkeit.

In diesem Beitrag konzentrieren wir uns auf die verschiedenen Möglichkeiten, SQL Server horizontal (scale out) zu skalieren. Vor der Entscheidung, welche Skalierbarkeitsmethode in diesem Umfeld verwendet werden kann, müssen Datenbank-Administratoren (DBA) verschiedene Kriterien berücksichtigen, zum Beispiel die Häufigkeit von Datenaktualisierungen, ob Daten unter verschiedenen Datenbanken aufgeteilt werden können und ob sich die auf dem SQL Server ausgeführten Anwendungen ändern lassen. Mit den Antworten auf diese Fragen kann man einen Scale-out-Plan erstellen, der die spezifischen Bedürfnisse erfüllt.

Um diese Fragen beantworten zu können, stellen wir ein paar grundlegende Details zu einigen der am häufigsten verwendeten SQL Server Scale-out-Ansätze vor. Wir haben diese Informationen aus den technischen Dokumenten von Microsoft extrahiert und zusammengefasst.

Scalable Shared Databases (skalierbare freigegebene Datenbanken): Eine Datenbank muss nicht auf einem Datenbankserver liegen. Wenn man die Daten stattdessen auf ein Storage Area Network (SAN) legt, können sie gleichzeitig von mehreren SQL-Server-Instanzen, die auf verschiedenen Servern laufen, abgerufen werden. Im Wesentlichen arbeitet dabei jede Instanz, die mit dem SAN verbunden ist, mit derselben Datenbankkopie.

Diese Skalierbarkeitsmethode kann im Grunde ohne irgendwelche Änderungen an den SQL-Server-Anwendungen genutzt werden. Ein großer Nachteil ist aber, dass sich diese Methode nur für Workloads mit statischen Daten eignet. Skalierbare freigegebene Datenbanken funktionieren gut bei leseintensiven Anwendungen, die komplexe Abfragen beinhalten – zum Beispiel einem Data Warehouse.

Skalierbare freigegebene Datenbanken sind jedoch nicht für Anwendungen mit einem Mix aus Lese- und Schreiboperationen geeignet. Der Grund ist: Wenn Daten geschrieben werden, wird die SQL Server Datenbank grundsätzlich gesperrt. Wenn nun Daten in eine freigegebene Datenbank geschrieben werden müssen, werden alle bis auf eine SQL-Server-Instanz von ihr separiert, bis die Schreiboperation abgeschlossen ist. Infolgedessen beeinflussen Schreibvorgänge die Datenbankleistung in signifikanter Weise negativ.

Distributed Partitioned Views (verteilte partitionierte Ansichten): Auch diese Technik teilt die Arbeitslast auf mehrere parallel arbeitende SQL Server auf. Im Gegensatz zu skalierbaren freigegebenen Datenbanken funktioniert diese Skalierungstechnik für SQL-Server-Workloads gut für Daten, die häufig aktualisiert werden. Damit eignet sich diese Methode vor allem für Anwendungen mit Online-Transaktionsverarbeitung. Der potentielle Nachteil ist, dass die Daten sich partitionieren lassen müssen. Mit großer Wahrscheinlichkeit müssen auch die Datenbankanwendungen geändert werden, um Verarbeitungsvorgänge in allen Partitionen zu synchronisieren.

Das Konzept hinter Distributed Partitioned Views ist einfach: Die Daten in einer großen Datenbank werden auf mehrere kleinere, verteilte Datenbanken aufgeteilt. Zum Beispiel kann eine Datenbank, die Rechnungen enthält, nach Jahren partitioniert werden. Rechnungen aus dem Jahr 2016 könnten in einer Datenbank abgelegt werden, während Rechnungen für das Jahr 2017 in einer anderen Datenbank gespeichert sind. Aktualisierungen und Abfragen können dann mit derjenigen Datenbank ausgeführt werden, die die relevanten Daten enthält.

Data-dependent Routing (datenabhängiges Routing): Diese Scale-out-Methode ist eine Variante der verteilten partitionierten Ansichten für hochvolumige OLTP-Anwendungen. Dabei wird eine Datenbank ebenfalls in eine Reihe kleinerer Datenbanken unterteilt. Der Unterschied besteht darin, wie der Prozess des Routings der Abfragen auf die richtige Datenbank gemanagt wird. Bei Distributed Partitioned Views kennt der SQL Server selbst die Datenpartitionierungsstruktur und bestimmt, wo auf die angeforderten Daten zugegriffen werden kann. Beim datenabhängigen Routing legen SQL-Server-Anwendungen oder Middleware Services fest, wo sich die notwendigen Daten befinden.

Linked Server (Verbindungsserver): Der SQL Server kann auf Remote-Datenbanken genauso zugreifen, als wären sie lokal verfügbar. Aus diesem Grund ist es möglich, die Software so zu konfigurieren, dass sie eine herunterskalierte Menge von Datenbanken so behandelt, als wäre sie eine einzige große Datenbank. Verbindungsserver bieten eine praktikable Alternative, wenn vorhandene SQL-Server-Anwendungen nicht einfach geändert werden können, um einen anderen Scale-out-Ansatz zu unterstützen.

Mehr zum Thema Microsoft SQL Server:

Was SQL Server für Linux über die Zukunftspläne von Microsoft verrät.

Relationales DBMS: Das bietet Microsoft SQL Server 2016.

Microsoft SQL Server 2016: Mit diesen Lizenz-Tipps vermeidet man Ärger.

Was man vor dem Upgrade zu Microsoft SQL Server 2016 wissen sollte.

Warum Microsoft SQL Server Express innerhalb von Azure anbietet.

Da sich der SQL Server jedoch mit unabhängigen Datenbanken verbindet, gibt es keine formale Kopplung zwischen ihnen. Zusätzlich zu einigen Einschränkungen innerhalb des SQL Servers – wie zum Beispiel einem Mangel an referenzieller Integrität zwischen lokalen und nicht-lokalen Tabellen – ist ein erheblicher Verarbeitungsaufwand beim Zugriff auf entfernte Datenbanken erforderlich. SQL-Server-Architekturen, die Verbindungsserver einbeziehen, müssen deshalb so ausgelegt sein, dass der Zugriff auf dezentrale Daten minimiert wird. Dies betrifft besonders Joins zwischen lokalen und nicht-lokalen Tabellen.

Peer-to-Peer-Replikation: Ein weiterer Mechanismus für das Skalieren von SQL-Server-Anwendungen ist das Replizieren von Daten zwischen verschiedenen Servern. Die Peer-to-Peer-Replikation ist im Prinzip das Gegenteil der Methode der skalierbaren freigegebenen Datenbanken. Anstatt, dass sich mehrere Datenbankserver eine einzige Kopie einer Datenbank teilen, arbeiten die Server jeweils mit einer eigenen Kopie. Tritt eine Schreiboperation auf, wird die Änderung auf alle Kopien repliziert.

Peer-to-Peer-Replikation kann zwar mit moderat auftretenden Datenbank-Schreibvorgängen umgehen. Die Methode ist aber am besten geeignet für Daten, die relativ statisch sind. Wegen der Latenz, die bei der Replikation auftritt, ist dieses Verfahren weniger gut für Daten geeignet, die zeitempfindlich sind. Peer-to-Peer-Replikation ist jedoch eine gute Allzweck-Skalierungsmethode für Datenbanken, die mehr Lese- als Schreibvorgänge verarbeiten.

Folgen Sie SearchEnterpriseSoftware.de auch auf Twitter, Google+ und Facebook!

Artikel wurde zuletzt im April 2017 aktualisiert

Pro+

Premium-Inhalte

Weitere Pro+ Premium-Inhalte und andere Mitglieder-Angebote, finden Sie hier.

Erfahren Sie mehr über Datenbank-Management-Systeme (DBMS)

Diskussion starten

Schicken Sie mir eine Nachricht bei Kommentaren anderer Mitglieder.

Mit dem Absenden dieser Daten erklären Sie sich bereit, E-Mails von TechTarget und seinen Partnern zu erhalten. Wenn Ihr Wohnsitz außerhalb der Vereinigten Staaten ist, geben Sie uns hiermit Ihre Erlaubnis, Ihre persönlichen Daten zu übertragen und in den Vereinigten Staaten zu verarbeiten. Datenschutz

Bitte erstellen Sie einen Usernamen, um einen Kommentar abzugeben.

- GOOGLE-ANZEIGEN

SearchSecurity.de

SearchStorage.de

SearchNetworking.de

SearchDataCenter.de

Close