Verwalten von Computeressourcen für dedizierte SQL-Pools

Tip

Microsoft Fabric Data Warehouse ist ein relationales Enterprise-Warehouse auf einem Data Lake-Fundament mit zukunftsfähiger Architektur, integrierter KI und neuen Features. Wenn Sie mit Data Warehouse noch nicht vertraut sind, beginnen Sie mit Fabric Data Warehouse. Vorhandene dedizierte SQL-Pool-Workloads können auf Fabric aktualisieren, um neue Funktionen in den Bereichen Data Science, Echtzeitanalyse und Berichterstellung zu nutzen.

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 Rechnerverwaltung?

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 Rechenressourcen 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 Berechnungskosten sparen, indem Sie die Berechnung anhalten.

Skalierung von Rechenressourcen

Sie können Rechenressourcen 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 auch Skalierungsvorgänge mit einer REST-API durchfü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 Rechenknoten 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.

Wann sollte skaliert werden

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.

Was passiert, wenn die Ausskalierung 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 Ihre Leistung nicht verbessert, gibt es einige Gründe, warum dies der Fall sein könnte. 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 Computing-Diensten

Das Pausieren des Computes führt dazu, dass die Speicherebene von den Compute-Knoten getrennt wird. Die Computeressourcen werden aus Ihrem Konto freigegeben. Es fallen keine Kosten für Rechenressourcen an, während sie pausiert sind. Beim Fortsetzen von Rechenressourcen wird der Speicher wieder mit den Rechenknoten verbunden, und die Gebühren für die Rechenressourcen werden wieder aufgenommen.

Wenn Sie einen dedizierten SQL-Pool anhalten:

  • Verarbeitungs- und Speicherressourcen werden dem 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 beschafft sich Rechen- und Speicherressourcen basierend auf Ihrer DWUs-Einstellung.
  • Die Berechnung der Gebühren für Ihre DWUs wird fortgesetzt.
  • Ihre Daten sind verfügbar.
  • Wenn der dedizierte SQL-Pool online ist, müssen Sie Ihre Workloadabfragen neu starten.

Falls der dedizierte SQL-Pool stets verfügbar sein soll, könnten Sie ihn auf die kleinste Größe verkleinern, statt 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 Pause- oder Skalierungsvorgang starten.

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.

Das Zurücksetzen der von einer Transaktionsabfrage vorgenommenen Arbeit kann genauso lange oder sogar länger dauern als die ursprüngliche Änderung, die die Abfrage angewendet hat. 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 ausführen, während die Transaktionen im Gange sind, kann das Pausieren oder Skalieren lange dauern, da das Pausieren und Skalieren warten muss, bis das Rollback abgeschlossen ist.

Weitere Informationen finden Sie unter Verwenden von Transaktionen und Optimieren von Transaktionen.

Automatisierung der Computerverwaltung

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 der Vorgänge für die Skalierung, das Anhalten und das 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.