Hyperscale-Dienstebene

Gilt für: Azure SQL-Datenbank

Azure SQL-Datenbank basiert auf der an die Cloudumgebung angepasste Architektur der SQL Server-Datenbank-Engine, um Hochverfügbarkeit selbst bei Infrastrukturausfällen sicherzustellen. In Azure SQL-Datenbank werden drei Architekturmodelle verwendet:

  • Universell/Standard
  • Hyperscale
  • Unternehmenskritisch/Premium

Die Dienstebene „Hyperscale“ in Azure SQL-Datenbank ist die neueste Dienstebene im vCore-basierten Kaufmodell. Diese Dienstebene bietet eine hochgradig skalierbare Speicher- und Computeleistung, mit der die Speicher- und Compute-Ressourcen für eine Azure SQL-Datenbank mithilfe der Azure-Architektur weit über die Limits der Dienstebenen „Universell“ und „Unternehmenskritisch“ hinaus aufskaliert werden können.

Hinweis

  • Ausführliche Informationen zu den Dienstebenen „Universell“ und „Unternehmenskritisch“ im vCore-basierten Kaufmodell finden Sie in den Dienstebenen Universell und Unternehmenskritisch. Einen Vergleich zwischen vCore-basiertem Kaufmodell und DTU-basiertem Kaufmodell finden Sie unter Kaufmodelle für Azure SQL-Datenbank und Ressourcen.
  • Die Hyperscale-Dienstebene ist derzeit nur für Azure SQL-Datenbank und nicht für Azure SQL Managed Instance verfügbar.

Welche Funktionen bietet Hyperscale?

Die Dienstebene „Hyperscale“ in Azure SQL-Datenbank bietet folgende zusätzliche Funktionen:

  • Unterstützung für eine Datenbankgröße von bis zu 100 TB.
  • Schnelle Datenbanksicherungen (basierend auf in Azure Blob Storage gespeicherten Dateimomentaufnahmen) unabhängig von der Größe und ohne E/A-Auswirkung auf Compute-Ressourcen.
  • Schnelle Datenbankwiederherstellungen (basierend auf Dateimomentaufnahmen) in Minuten statt Stunden oder Tagen (kein von der Datengröße abhängiger Vorgang).
  • Höhere Gesamtleistung aufgrund eines höheren Transaktionsprotokolldurchsatzes und schnellerer Transaktionscommits unabhängig von Datenmengen.
  • Schnelle Aufskalierung: Sie können ein oder mehrere schreibgeschützte Replikate zum Abladen Ihrer Leseworkload und zur Verwendung als unmittelbar betriebsbereite Standbyserver bereitstellen.
  • Schnelle Hochskalierung: Sie können Ihre Computeressourcen in konstanter Zeit hochskalieren, um hohe Workloads nach Bedarf zu bewältigen, und anschließend wieder herunterskalieren, sobald sie nicht mehr benötigt werden.

Die Dienstebene „Hyperscale“ beseitigt viele praktische Einschränkungen, die normalerweise für Clouddatenbanken gelten. Während die meisten anderen Datenbanken durch die auf einem einzelnen Knoten verfügbaren Ressourcen eingeschränkt werden, gelten in der Dienstebene „Hyperscale“ keine solchen Limits. Aufgrund der flexiblen Speicherarchitektur wächst der Speicher nach Bedarf. Hyperscale-Datenbanken werden ohne Definition einer maximalen Größe erstellt. Eine Hyperscale-Datenbank wächst nach Bedarf – und Ihnen wird nur die tatsächlich verwendete Kapazität in Rechnung gestellt. Für leseintensive Workloads bietet die Dienstebene „Hyperscale“ eine schnelle horizontale Skalierung, indem nach Bedarf zusätzliche Replikate zur Abladung von Leseworkloads bereitgestellt werden.

Darüber hinaus ist die Zeit, die zum Erstellen von Datenbanksicherungen oder zum Hoch- oder Herunterskalieren erforderlich ist, nicht mehr an die Menge der Daten in der Datenbank gebunden. Hyperscale-Datenbanken können praktisch sofort gesichert werden. Außerdem können Sie eine Datenbank in Minutenschnelle in der Größenordnung von zig Terabyte hoch- oder herunterskalieren. Durch diese Funktion müssen Sie nicht befürchten, durch Ihre Auswahl bei der Anfangskonfiguration eingeschränkt zu werden.

Weitere Informationen zu den Computegrößen für die Dienstebene „Hyperscale“ finden Sie unter Merkmale der Dienstebene.

Wer sollte die Dienstebene „Hyperscale“ in Betracht ziehen?

Die Dienstebene „Hyperscale“ ist für all jene Kunden geeignet, die eine höhere Leistung und Verfügbarkeit, eine schnelle Sicherung und Wiederherstellung und/oder eine schnelle Skalierbarkeit von Speicher und Compute benötigen. Hierzu zählen Kunden, die zur Modernisierung ihrer Anwendungen in die Cloud wechseln sowie Kunden, die bereits andere Dienstebenen in Azure SQL-Datenbank verwenden. Die Hyperscale-Dienstebene unterstützt eine breite Palette von Datenbankworkloads, von reinem OLTP bis hin zu reinen Analysen. Sie ist für OLTP- und Hybridtransaktions- und Analyseverarbeitungsworkloads (HTAP) optimiert.

Wichtig

Pools für elastische Datenbanken bieten für die Dienstebene „Hyperscale“ keine Unterstützung.

Preismodell für „Hyperscale“

Die Dienstebene „Hyperscale“ ist nur im V-Kern-Modell verfügbar. In Anpassung an die neue Architektur ist das Preismodell etwas anders gestaltet als bei den Dienstebenen „Universell“ oder „Unternehmenskritisch“:

  • Compute:

    Der Preis für Compute-Einheiten bei „Hyperscale“ ist pro Replikat. Der Preis für den Azure-Hybridvorteil wird automatisch auf Hochverfügbarkeits- und benannte Replikate angewandt. Benutzer können die Gesamtzahl der sekundären Replikate mit hoher Verfügbarkeit von 0 bis 4 anpassen, je nach Verfügbarkeits- und Skalierbarkeitsanforderungen, und erstellen Sie bis zu 30 benannte Replikate, um eine Vielzahl von Skalierungs-Workloads zu unterstützen.

  • Storage:

    Beim Konfigurieren einer Hyperscale-Datenbank müssen Sie keine maximale Datengröße angeben. Im Hyperscale-Tarif werden Gebühren für den Speicher Ihrer Datenbank basierend auf der tatsächlichen Zuordnung berechnet. Speicher wird automatisch zwischen 10 GB und 100 TB zugewiesen und erhöht sich bei Bedarf in 10-GB-Schritten.

Weitere Informationen zu den Hyperscale-Preisen finden Sie unter Preise für Azure SQL-Datenbank.

Vergleichen von Ressourcengrenzwerten

Die auf virtuellen Kernen basierenden Dienstebenen unterscheiden sich im Hinblick auf Datenbankverfügbarkeit, Speichertyp, Leistung und maximaler Speichergröße, wie in der folgenden Tabelle beschrieben:

Allgemeiner Zweck Hyperscale Unternehmenskritisch
Am besten geeignet für Bietet budgetorientierte ausgewogene Compute- und Speicheroptionen. Die meisten geschäftlichen Workloads. Automatische Skalierung der Speichergröße bis zu 100 TB, schnelle vertikale und horizontale Computeskalierung, schnelle Datenbankwiederherstellung. OLTP-Anwendungen mit hoher Transaktionsrate und geringen Latenzen bei E/A-Vorgängen. Bietet mit mehreren synchron aktualisierten Replikaten höchste Resilienz gegenüber Fehlern und schnelle Failover.
Computegröße 1 bis 80 virtuelle Kerne 1 bis 80 virtuelle Kerne1 1 bis 80 virtuelle Kerne
Speichertyp Storage Premium (remote, pro Instanz) Entkoppelter Speicher mit lokalem SSD-Cache (pro Instanz) Äußerst schneller lokaler SSD-Speicher (pro Instanz)
Speichergröße1 5 GB – 4 TB Bis zu 100 TB 5 GB – 4 TB
IOPS 500 IOPS pro virtuellem Kern mit maximal 7.000 IOPS Hyperscale ist eine mehrstufige Architektur mit Caching auf mehreren Ebenen. Der tatsächliche IOPS-Wert hängt von der Workload ab. 5.000 IOPS mit maximal 200.000 IOPS
Verfügbarkeit 1 Replikat, keine horizontale Leseskalierung, zonenredundante Hochverfügbarkeit (Vorschau), kein lokaler Cache Mehrere Replikate, bis zu 4 Replikate mit horizontaler Leseskalierung, zonenredundanter Hochverfügbarkeit, teilweise lokaler Cache 3 Replikate, 1 Replikat mit horizontaler Leseskalierung, zonenredundante Hochverfügbarkeit, vollständiger lokaler Cache
Sicherungen Wahl zwischen georedundantem, zonenredundantem oder lokal redundantem Sicherungsspeicher mit einer Aufbewahrungsdauer von 1 bis 35 Tagen (Standardeinstellung: 7 Tage) Wahl zwischen georedundantem, zonenredundantem oder lokal redundantem Sicherungsspeicher mit einer Aufbewahrungsdauer von 1 bis 35 Tagen (Standardeinstellung: 7 Tage) Wahl zwischen georedundantem, zonenredundantem oder lokal redundantem Sicherungsspeicher mit einer Aufbewahrungsdauer von 1 bis 35 Tagen (Standardeinstellung: 7 Tage)

1 Pools für elastische Datenbanken werden in der Dienstebene „Hyperscale“ nicht unterstützt.

Hinweis

Die kurzfristige Sicherungsaufbewahrung für 1 bis 35 Tage für Hyperscale-Datenbanken ist ab sofort in der Vorschauversion verfügbar.

Architektur mit verteilten Funktionen

Hyperscale trennt das Abfrageverarbeitungsmodul von den Komponenten, die langfristige Speicherung und Dauerhaftigkeit für die Daten bereitstellen. Diese Architektur bietet die Möglichkeit, die Speicherkapazität problemlos nach Bedarf (ursprüngliches Ziel sind 100 TB) und auch die Computeressourcen schnell zu skalieren.

Das folgende Diagramm veranschaulicht die verschiedenen Typen von Knoten in einer Hyperscale-Datenbank:

Architektur

Erfahren Sie mehr über die Hyperscale-Architektur mit verteilten Funktionen.

Skalierungs- und Leistungsvorteile

Mit der Möglichkeit, weitere Computeknoten schnell hoch- bzw. herunterzufahren, erlaubt die Hyperscale-Architektur eine erhebliche horizontale Leseskalierung und kann außerdem den primären Computeknoten freigeben, um weitere Schreibanforderungen zu verarbeiten. Darüber hinaus können die Computeknoten aufgrund der Hyperscale-Architektur mit freigegebenem Speicher schnell zentral hoch- oder herunterskaliert werden.

Erstellen und Verwalten von Hyperscale-Datenbanken

Sie können Hyperscale-Datenbanken mithilfe des Azure-Portals, mit Transact-SQL, PowerShell und der Azure CLI erstellen und verwalten. Siehe Schnellstart: Erstellen einer Hyperscale-Datenbank.

Vorgang Details Weitere Informationen
Erstellen einer Hyperscale-Datenbank Hyperscale-Datenbanken stehen nur bei Verwendung des vCore-basierten Kaufmodells zur Verfügung. Sehen Sie sich Beispiele an, wie Sie eine neue Hyperscale-Datenbank erstellen: Schnellstart: Erstellen einer Hyperscale-Datenbank in Azure SQL-Datenbank.
Ausführen eines Upgrades einer vorhandenen Datenbank auf Hyperscale Das Migrieren einer vorhandenen Azure SQL-Datenbank-Instanz zur Hyperscale-Ebene ist ein von der Größe der Daten abhängiger Vorgang. Erfahren Sie mehr über das Migrieren einer vorhandenen Datenbank zu Hyperscale.
Umgekehrte Migration einer Hyperscale-Datenbank zur Dienstebene „Universell“ (Vorschau) Wenn Sie zuvor eine vorhandene Azure SQL-Datenbank zur Dienstebene „Hyperscale“ migriert haben, können Sie innerhalb von 45 Tagen nach der ursprünglichen Migration zu Hyperscale eine umgekehrte Migration der Datenbank zur Dienstebene „Universell“ durchführen.

Wenn Sie die Datenbank zu einer anderen Dienstebene migrieren möchten, z. B. zu „Unternehmenskritisch“, führen Sie zunächst umgekehrte Migration zur Dienstebene „Universell“ aus, und ändern Sie dann die Dienstebene.
Erfahren Sie mehr über umgekehrte Migration aus Hyperscale, einschließlich der Einschränkungen für umgekehrte Migration.

Hochverfügbarkeit von Datenbanken in Hyperscale

Wie bei allen anderen Dienstebenen gewährleistet Hyperscale die Dauerhaftigkeit von Daten für committete Transaktionen unabhängig von der Verfügbarkeit des Computereplikats. Das Ausmaß der Ausfallzeiten aufgrund der Nichtverfügbarkeit des primären Replikats hängt von der Art des Failovers (geplant oder ungeplant), von einer eventuellen Konfiguration der Zonenredundanz und vom Vorhandensein mindestens eines Replikats mit Hochverfügbarkeit ab. Bei einem geplanten Failover (d. h. einem Wartungsereignis) erstellt das System entweder das neue primäre Replikat, bevor ein Failover initiiert wird, oder es verwendet ein vorhandenes Hochverfügbarkeitsreplikat als Failoverziel. Bei einem ungeplanten Failover (d. h. bei einem Hardwarefehler auf dem primären Replikat) verwendet das System ein Hochverfügbarkeitsreplikat als Failoverziel (sofern vorhanden), oder es erstellt ein neues primäres Replikat aus dem Pool der verfügbaren Computekapazität. Im letzteren Fall ist die Dauer der Ausfallzeit länger, da zusätzliche Schritte erforderlich sind, um das neue primäre Replikat zu erstellen.

Weitere Informationen zur Hyperscale-SLA finden Sie unter SLA für Azure SQL-Datenbank.

Sichern und Wiederherstellen

Sicherungs- und Wiederherstellungsvorgänge für Hyperscale-Datenbanken basieren auf Dateimomentaufnahmen. Dadurch können diese Vorgänge nahezu sofort durchgeführt werden. Da die Hyperscale-Architektur die Speicherebene für Sicherung und Wiederherstellung nutzt, werden die Verarbeitungslast und die Auswirkungen auf die Leistung der Computereplikate erheblich verringert. Weitere Informationen finden Sie unter Hyperscale-Sicherungen und Speicherredundanz.

Notfallwiederherstellung für Hyperscale-Datenbanken

Wenn Sie im Rahmen der Wiederherstellung einer Hyperscale-Datenbank in Azure SQL-Datenbank im Notfall oder im Rahmen einer Übung, wegen eines Umzugs oder aus einem sonstigen Grund in einer anderen Region wiederherstellen müssen als der, in der sie gerade gehostet wird, besteht die primäre Methode in einer Geowiederherstellung der Datenbank. Die Geowiederherstellung ist nur verfügbar, wenn georedundanter Speicher (RA-GRS) für die Speicherredundanz ausgewählt wurde.

Weitere Informationen finden Sie unter Wiederherstellen einer Hyperscale-Datenbank in einer anderen Region.

Bekannte Einschränkungen

Hierbei handelt es sich um die aktuellen Einschränkungen der Hyperscale-Dienstebene. Wir arbeiten daran, möglichst viele dieser Einschränkungen zu beseitigen.

Problem BESCHREIBUNG
Kurzfristige Sicherungsaufbewahrung Die kurzfristige Sicherungsaufbewahrung für 1 bis 35 Tage für Hyperscale-Datenbanken ist ab sofort in der Vorschauversion verfügbar. Datenbanken mit einer anderen Dienstebene als Hyperscale können nicht als Hyperscale-Datenbanken wiederhergestellt werden, und eine Hyperscale-Datenbank kann nicht als eine Datenbank mit einer anderen Dienstebene wiederhergestellt werden.

Bei Datenbanken, die von anderen Dienstebenen von Azure SQL-Datenbank zu Hyperscale migriert wurden, werden Sicherungen vor der Migration so lange aufbewahrt, wie in der Aufbewahrungsdauer für Sicherungen der Quelldatenbank angegeben (einschließlich Richtlinien für die Langzeitaufbewahrung). Das Wiederherstellen einer Sicherung vor der Migration innerhalb des Aufbewahrungszeitraums für Sicherungen der Datenbank wird über die Befehlszeile unterstützt. Diese Sicherungen können auf jeder beliebigen Dienstebene wiederhergestellt werden (mit Ausnahme von „Hyperscale“).
Langfristiges Aufbewahren von Sicherungen Die langfristige Aufbewahrung von Sicherungen wird derzeit nicht unterstützt. Hyperscale verfügt über eine momentaufnahmebasierte Sicherungsarchitektur, die sich von anderen Dienstebenen unterscheidet.
Die Änderung der Dienstebene von „Hyperscale“ zu „Universell“ wird in begrenzten Szenarien direkt unterstützt Die umgekehrte Migration von „Hyperscale“ ermöglicht es Kunden, die vor kurzem eine vorhandene Azure SQL-Datenbank zur Dienstebene „Hyperscale“ migriert haben, wieder zur Ebene „Universell“ zu verschieben, falls Hyperscale ihre Anforderungen nicht erfüllt. Während die umgekehrte Migration durch eine Änderung der Dienstebene eingeleitet wird, handelt es sich im Wesentlichen um eine Verschiebung der Datengröße zwischen verschiedenen Architekturen. Datenbanken, die in der Hyperscale-Dienstebene erstellt wurden, sind von der umgekehrten Migration ausgeschlossen. Erfahren Sie mehr über die Einschränkungen für die umgekehrte Migration.

Für Datenbanken, die nicht für die umgekehrte Migration in Frage kommen, besteht die einzige Möglichkeit der Migration von Hyperscale zu einer anderen Dienstebene im Export/Import mithilfe einer Bacpac-Datei oder anderer Datenverschiebungstechnologien (Massenkopieren, Azure Data Factory, Azure Databricks, SSIS usw.). Der Bacpac-Export/Import über das Azure-Portal, über PowerShell mit New-AzSqlDatabaseExport oder New-AzSqlDatabaseImport, über die Azure CLI mit az sql db export und az sql db import und über die REST-API wird nicht unterstützt. Der BACPAC-Import/-Export für kleinere Hyperscale-Datenbanken (bis zu 200 GB) wird über SSMS und SqlPackage Version 18.4 und höher unterstützt. Bei größeren Datenbanken kann der BACPAC-Export/-Import sehr lange dauern und aus verschiedenen Gründen zu Fehlern führen.
Pools für elastische Datenbanken Pools für elastische Datenbanken werden mit Hyperscale derzeit nicht unterstützt.
Migration von Datenbanken mit In-Memory-OLTP-Objekten Hyperscale unterstützt eine Teilmenge von In-Memory-OLTP-Objekten, einschließlich speicheroptimierter Tabellentypen, Tabellenvariablen und systemintern kompilierter Module. Wenn aber In-Memory-OLTP-Objekte in der gerade migrierten Datenbank vorhanden sind, wird die Migration von der Dienstebene „Premium“ oder „Unternehmenskritisch“ zu „Hyperscale“ nicht unterstützt. Für die Migration solch einer Datenbank zu Hyperscale müssen alle In-Memory-OLTP-Objekte und deren Abhängigkeiten gelöscht werden. Nachdem die Datenbank migriert wurde, können diese Objekte neu erstellt werden. Speicheroptimierte dauerhafte und nicht dauerhafte Tabellen werden zurzeit in Hyperscale nicht unterstützt und müssen in Datenträgertabellen geändert werden.
Verkleinern der Datenbank DBCC SHRINKDATABASE, DBCC SHRINKFILE oder die Einstellung von AUTO_SHRINK auf ON auf Datenbankebene werden derzeit nicht für Hyperscale-Datenbanken unterstützt.
Datenbankintegritätsprüfung DBCC CHECKDB wird für Hyperscale-Datenbanken derzeit nicht unterstützt. Als Problemumgehung können DBCC CHECKTABLE ('TableName') WITH TABLOCK und DBCC CHECKFILEGROUP WITH TABLOCK verwendet werden. Ausführliche Informationen zur Datenintegritätsverwaltung in Azure SQL-Datenbank finden Sie unter Datenintegrität in Azure SQL-Datenbank.
Elastische Aufträge Die Verwendung einer Hyperscale-Datenbank als Auftragsdatenbank wird nicht unterstützt. Elastische Aufträge können jedoch Hyperscale-Datenbanken auf die gleiche Weise wie jede andere Datenbank in Azure SQL-Datenbank als Ziel verwenden.
Datensynchronisierung Die Verwendung einer Hyperscale-Datenbank als Hubdatenbank oder als Datenbank für Synchronisierungsmetadaten wird nicht unterstützt. Eine Hyperscale-Datenbank kann jedoch eine Mitgliedsdatenbank in einer Datensynchronisierungstopologie sein.

Nächste Schritte

Weitere Informationen zu Hyperscale in Azure SQL-Datenbank finden Sie in den folgenden Artikeln: