Verwalten von Computeressourcen für dedizierte SQL-Pools
In diesem Artikel wird beschrieben, wie Sie Computeressourcen für dedizierte SQL-Pools (ehemals SQL DW) in Azure Synapse Analytics verwalten. Sie können die Kosten senken, indem Sie den dedizierten SQL-Pool anhalten oder skalieren, um Leistungsanforderungen zu erfüllen.
Was ist Computeverwaltung?
In der Architektur von dedizierten SQL-Pools werden Speicher- und Computeressourcen voneinander getrennt, sodass diese unabhängig voneinander skaliert werden können. Daher können Sie Computeressourcen skalieren, um Leistungsanforderungen unabhängig vom Datenspeicher zu erfüllen. Sie können Computeressourcen auch anhalten und fortsetzen.
Eine logische Konsequenz dieser Architektur ist, dass die Preise für Compute- und Speicherressourcen voneinander unabhängig sind. Wenn Sie Ihren dedizierten SQL-Pool für eine Weile nicht verwenden müssen, können Sie Computekosten sparen, indem Sie Computeressourcen anhalten.
Skalieren von Computeressourcen
Sie können Computeressourcen auf- oder abskalieren, indem Sie die Einstellung für Data Warehouse-Einheiten (DWUs) für Ihren dedizierten SQL-Pool anpassen. Sie können die Lade- und die Abfrageleistung linear erhöhen, indem Sie weitere DWUs hinzufügen.
Die Schritte zur horizontalen Skalierung finden Sie in den Schnellstarts zum Azure-Portal, zu PowerShell oder zu T-SQL. Sie können horizontale Skalierungsvorgänge auch mit einer REST-API ausführen.
Um einen Skalierungsvorgang auszuführen, beendet der dedizierte SQL-Pool zunächst alle eingehenden Abfragen und führt dann einen Rollback der Transaktionen durch, um einen konsistenten Zustand zu gewährleisten. Die Skalierung tritt erst auf, wenn der Transaktionsrollback abgeschlossen ist. Für einen Skalierungsvorgang trennt das System die Speicherebene von den Serverknoten, fügt Serverknoten hinzu und verbindet dann die Speicherebene wieder mit der Computeebene.
Jeder dedizierte SQL-Pool wird als 60 Distributionen gespeichert, die gleichmäßig auf die Serverknoten verteilt werden. Durch Hinzufügen von weiteren Computeknoten wird die Computeleistung erhöht. Mit zunehmender Anzahl von Computeknoten verringert sich die Anzahl der Verteilungen pro Computeknoten, sodass mehr Computeleistung für Ihre Abfragen bereitsteht. Entsprechend verringert sich mit abnehmender Anzahl von DWUs die Anzahl der Serverknoten, wodurch die Computeressourcen für Abfragen verringert werden.
Die folgende Tabelle zeigt, wie sich die Anzahl von Distributionen pro Serverknoten ändert, wenn sich die DWUs ändern. DW30000c bietet 60 Serverknoten und führt zu einer erheblich höheren Abfrageleistung als DW100c.
| Data Warehouse-Einheiten | Anzahl von Serverknoten | Anzahl von Verteilungen pro Knoten |
|---|---|---|
| DW100c | 1 | 60 |
| DW200c | 1 | 60 |
| DW300c | 1 | 60 |
| DW400c | 1 | 60 |
| DW500c | 1 | 60 |
| DW1000c | 2 | 30 |
| DW1500c | 3 | 20 |
| DW2000c | 4 | 15 |
| DW2500c | 5 | 12 |
| DW3000c | 6 | 10 |
| DW5000c | 10 | 6 |
| DW6000c | 12 | 5 |
| DW7500c | 15 | 4 |
| DW10000c | 20 | 3 |
| DW15000c | 30 | 2 |
| DW30000c | 60 | 1 |
Ermitteln der richtigen Größe der Data Warehouse-Einheiten
Um von den Leistungsvorteilen der Skalierung insbesondere für größere Data Warehouse-Einheiten zu profitieren, sollten Sie ein Dataset von mindestens 1 TB verwenden. Ermitteln Sie durch Hoch- und Herunterskalieren die optimale Anzahl von DWUs für Ihren dedizierten SQL-Pool. Führen Sie nach dem Laden Ihrer Daten einige Abfragen mit einer unterschiedlichen Anzahl von DWUs aus. Da die Skalierung schnell erfolgt, können Sie innerhalb einer Stunde verschiedene Leistungsebenen ausprobieren.
Empfehlungen für die Ermittlung der optimalen Anzahl von DWUs:
- Bei einem dedizierten SQL-Pool in der Entwicklung sollten Sie zunächst eine kleinere Anzahl von DWUs auswählen. Ein guter Startpunkt ist DW400c oder DW200c.
- Überwachen Sie die Anwendungsleistung, und beobachten Sie dabei die Anzahl der ausgewählten DWUs im Vergleich zur beobachteten Leistung.
- Gehen Sie von einer linearen Skalierung aus, und bestimmen Sie, wie stark Sie die DWUs erhöhen oder verringern müssen.
- Nehmen Sie weitere Anpassungen vor, bis Sie die optimale Leistungsstufe für Ihre geschäftlichen Anforderungen erreichen.
Fälle für das Aufskalieren
Das Skalieren von DWUs wirkt sich auf die folgenden Leistungsaspekte aus:
- Lineares Verbessern der Systemleistung bei Scans, Aggregationen und CTAS-Anweisungen
- Erhöhen der Anzahl von Readern und Writern für des Laden von Daten
- Maximale Anzahl von gleichzeitigen Abfragen und Parallelitätsslots
Empfehlungen für den Zeitpunkt für die horizontale Skalierung von DWUs:
- Bevor Sie einen umfangreichen Vorgang zum Laden oder Transformieren von Daten durchführen, skalieren Sie auf, damit die Daten schneller verfügbar sind.
- Skalieren Sie während der Hauptgeschäftszeiten auf, um eine größere Anzahl gleichzeitiger Abfragen verarbeiten zu können.
Welche Optionen gibt es, wenn das horizontale Skalieren die Leistung nicht verbessert?
Das Hinzufügen von DWUs steigert die Parallelität. Wenn die Arbeit gleichmäßig zwischen den Serverknoten verteilt wird, steigt die Abfrageleistung durch die zusätzliche Parallelität. Wenn das horizontale Skalieren die Leistung nicht ändert, sind einige Ursachen denkbar. Die Daten können über die Verteilungen verstreut sein, oder Abfragen führen zu umfangreichen Datenverschiebung. Informationen zu Leistungsproblemen bei Abfragen finden Sie unter Behandlung von Problemen mit der Abfrageleistung.
Anhalten und Fortsetzen von Computevorgängen
Durch das Anhalten einer Computeressource wird die Speicherebene von den Serverknoten getrennt. Die Computeressourcen werden aus Ihrem Konto freigegeben. Computeressourcen werden Ihnen nicht berechnet, während sie angehalten sind. Beim Fortsetzen von Computeressourcen wird der Speicher wieder mit den Serverknoten verbunden, und die Computeressourcen werden wieder berechnet.
Wenn Sie einen dedizierten SQL-Pool anhalten:
- Compute- und Speicherressourcen werden an den Pool der verfügbaren Ressourcen im Rechenzentrum zurückgegeben.
- Die Kosten für Data Warehouse-Einheiten sind für die Dauer der Pause gleich null.
- Die Speicherung von Daten ist nicht betroffen, und Ihre Daten bleiben intakt.
- Alle laufenden oder in die Warteschlange eingereihten Vorgänge werden abgebrochen.
- DMV-Zähler werden zurückgesetzt.
Wenn Sie einen dedizierten SQL-Pool fortsetzen:
- Der dedizierte SQL-Pool ruft Compute- und Speicherressourcen gemäß Ihrer DWUs-Einstellung ab.
- Computegebühren für Ihre DWUs fallen wieder an.
- Ihre Daten sind verfügbar.
- Wenn der dedizierte SQL-Pool online ist, müssen Sie Ihre Workloadabfragen neu starten.
Falls der dedizierte SQL-Pool immer verfügbar sein soll, könnten Sie ihn auf die kleinste Größe herunterskalieren, anstatt ihn anzuhalten.
Die Schritte zum Anhalten und Fortsetzen finden Sie in den Schnellstarts zum Azure-Portal oder zu PowerShell. Sie Können auch die REST-API zum Anhalten oder die REST-API zum Fortsetzen verwenden.
Beseitigen von Transaktionen vor dem Pausieren oder Skalieren
Es wird empfohlen, dass vorhandene Transaktionen abgeschlossen werden, bevor Sie einen Anhalte- oder Skalierungsvorgang initiieren.
Beim Anhalten oder Skalieren Ihres dedizierten SQL-Pools werden Ihre Abfragen im Hintergrund abgebrochen, wenn Sie die Anforderung zum Anhalten oder Skalieren initiieren. Das Abbrechen einer einfachen SELECT-Abfrage ist ein schneller Vorgang und hat fast keinerlei Auswirkung auf den Zeitraum, der für das Pausieren oder Skalieren Ihrer Instanz anfällt. Dagegen können Transaktionsabfragen, bei denen die Daten oder deren Struktur geändert wird, unter Umständen nicht so schnell beendet werden. Transaktionsabfragen müssen laut Definition entweder vollständig abgeschlossen sein, oder es muss ein Rollback der Änderungen durchgeführt werden.
Ein Rollback der Schritte, die von einer Transaktionsabfrage ausgeführt wurden, kann genauso lange oder sogar länger als die ursprüngliche Änderung dauern, die mit der Abfrage durchgeführt werden sollte. Wenn Sie beispielsweise eine Abfrage abbrechen, mit der Zeilen gelöscht werden, und die Abfrage bereits eine Stunde lang ausgeführt wurde, kann es eine Stunde dauern, bis die gelöschten Zeilen wieder eingefügt wurden. Wenn Sie das Pausieren oder Skalieren bei aktiven Transaktionen ausführen, kann das Pausieren oder Skalieren lange dauern, da erst gewartet werden muss, bis das Rollback abgeschlossen ist.
Weitere Informationen finden Sie unter Verwenden von Transaktionen und Optimieren von Transaktionen.
Automatisieren der Computeverwaltung
Weitere Informationen zum Automatisieren der Computeverwaltungsvorgänge finden Sie unter Verwenden von Azure Functions zum Verwalten von Computeressourcen für Ihren dedizierten SQL-Pool.
Jeder Vorgang zum horizontalen Skalieren, Anhalten und Fortsetzen kann mehrere Minuten in Anspruch nehmen. Wenn Sie das Skalieren, Anhalten oder Fortsetzen automatisch durchführen, empfiehlt es sich, eine Logik zu implementieren, die sicherstellt, dass bestimmte Vorgänge abgeschlossen wurden, bevor mit einer anderen Aktion fortgefahren wird. Überprüfen Sie den Status des dedizierten SQL-Pools über verschiedene Endpunkte, um sicherzustellen, dass die Automatisierung dieser Vorgänge ordnungsgemäß implementiert werden kann.
Weitere Informationen zum Überprüfen des Zustands eines dedizierten SQL-Pools finden Sie in den Schnellstarts zu PowerShell oder T-SQL. Sie können den Zustand des dedizierten SQL-Pools auch mit einer REST-API überprüfen.
Berechtigungen
Zum Skalieren des dedizierten SQL-Pools sind die in ALTER DATABASE beschriebenen Berechtigungen erforderlich. Zum Anhalten und Fortsetzen ist die Rolle SQL-DB-Mitwirkender erforderlich, insbesondere die Berechtigung Microsoft.Sql/servers/databases/action.