Hyperscale-servicelaag

Van toepassing op: Azure SQL-database

Azure SQL Database is gebaseerd op SQL Server Database Engine-architectuur die is aangepast voor de cloudomgeving om hoge beschikbaarheid te garanderen, zelfs in geval van infrastructuurfouten. Er zijn drie architectuurmodellen die worden gebruikt in Azure SQL Database:

  • Algemeen/Standard
  • Hyperscale
  • Bedrijfskritiek/Premium

De Hyperscale-servicelaag in Azure SQL Database is de nieuwste servicelaag in het aankoopmodel op basis van vCore. Deze servicelaag is een zeer schaalbare opslag- en rekenprestatielaag die gebruikmaakt van de Azure-architectuur om de opslag- en rekenresources voor een Azure SQL Database aanzienlijk verder uit te schalen dan de limieten die beschikbaar zijn voor de servicelagen Algemeen en Bedrijfskritiek.

Notitie

  • Zie Algemeen en Bedrijfskritiek servicelagen voor meer informatie over de Algemeen- en Bedrijfskritiek-servicelagen in het aankoopmodel op basis van vCore. Zie Azure SQL Database-aankoopmodellen en -resources voor een vergelijking van het aankoopmodel op basis van vCore met het aankoopmodel op basis van DTU.
  • De Hyperscale-servicelaag is momenteel alleen beschikbaar voor Azure SQL Database en niet Azure SQL Managed Instance.

Wat zijn de Mogelijkheden van Hyperscale?

De Hyperscale-servicelaag in Azure SQL Database biedt de volgende aanvullende mogelijkheden:

  • Ondersteuning voor maximaal 100 TB databasegrootte.
  • Snelle databaseback-ups (op basis van bestandsmomentopnamen die zijn opgeslagen in Azure Blob Storage) ongeacht de grootte zonder I/O-impact op rekenresources.
  • Snelle databaseherstel (op basis van bestandsmomentopnamen) in minuten in plaats van uren of dagen (geen grootte van gegevensbewerking).
  • Hogere algehele prestaties vanwege een hogere doorvoer van transactielogboeken en snellere transactiedoorvoertijden, ongeacht gegevensvolumes.
  • Snelle uitschalen: u kunt een of meer alleen-lezen replica's inrichten voor het offloaden van uw leesworkload en voor gebruik als hot-stand-bys.
  • Snel omhoog schalen: u kunt in constante tijd uw rekenresources omhoog schalen om zo nodig zware werkbelastingen te verwerken en vervolgens de rekenresources weer omlaag te schalen wanneer dat niet nodig is.

De Hyperscale-servicelaag verwijdert veel van de praktische limieten die traditioneel worden gezien in clouddatabases. Wanneer de meeste andere databases worden beperkt door de resources die beschikbaar zijn in één knooppunt, hebben databases in de Hyperscale-servicelaag geen dergelijke limieten. Met de flexibele opslagarchitectuur groeit de opslag naar behoefte. Hyperscale-databases worden zelfs niet gemaakt met een gedefinieerde maximale grootte. Een Hyperscale-database groeit naar behoefte en u wordt alleen gefactureerd voor de capaciteit die u gebruikt. Voor leesintensieve werkbelastingen biedt de Hyperscale-servicelaag snelle uitschalen door zo nodig extra replica's in te richten voor het offloaden van leesworkloads.

Daarnaast is de tijd die nodig is om databaseback-ups te maken of om omhoog of omlaag te schalen niet meer gekoppeld aan het volume van gegevens in de database. Back-ups van Hyperscale-databases kunnen vrijwel onmiddellijk worden gemaakt. U kunt een database ook in enkele minuten omhoog of omlaag schalen in de tientallen terabytes. Met deze mogelijkheid kunt u zich zorgen maken over het gebruik van uw eerste configuratieopties.

Zie Kenmerken van de Servicelaag voor meer informatie over de rekengrootten voor de Hyperscale-servicelaag.

Wie moet de Hyperscale-servicelaag overwegen

De Hyperscale-servicelaag is bedoeld voor alle klanten die hogere prestaties en beschikbaarheid nodig hebben, snelle back-up en herstel en/of snelle schaalbaarheid van opslag en rekenkracht. Dit omvat klanten die overstappen naar de cloud om hun toepassingen te moderniseren en klanten die al andere servicelagen in Azure SQL Database gebruiken. De Hyperscale-servicelaag ondersteunt een breed scala aan databaseworkloads, van pure OLTP tot pure analyse. Het is geoptimaliseerd voor OLTP- en HTAP-workloads (Hybrid Transaction and Analytical Processing).

Belangrijk

Elastische pools bieden geen ondersteuning voor de Hyperscale-servicelaag.

Hyperscale-prijsmodel

De Hyperscale-servicelaag is alleen beschikbaar in het vCore-model. Als u wilt uitlijnen met de nieuwe architectuur, verschilt het prijsmodel enigszins van Algemeen of Bedrijfskritiek servicelagen:

  • Rekenkracht:

    De prijs van de Hyperscale-rekeneenheid is per replica. De Azure Hybrid Benefit prijs wordt automatisch toegepast op hoge beschikbaarheid en benoemde replica's. Gebruikers kunnen het totale aantal secundaire replica's met hoge beschikbaarheid aanpassen van 0 tot 4, afhankelijk van de beschikbaarheids- en schaalbaarheidsvereisten, en maximaal 30 benoemde replica's maken ter ondersteuning van een verscheidenheid aan workloads voor opschaling voor leesbewerking.

  • Opslag:

    U hoeft de maximale gegevensgrootte niet op te geven bij het configureren van een Hyperscale-database. In de Hyperscale-laag worden kosten in rekening gebracht voor opslag voor uw database op basis van de werkelijke toewijzing. Opslag wordt automatisch toegewezen tussen 10 GB en 100 TB en groeit indien nodig in stappen van 10 GB.

Zie Azure SQL Databaseprijzen voor meer informatie over Hyperscale-prijzen

Resourcelimieten vergelijken

De servicelagen op basis van vCore zijn gedifferentieerd op basis van databasebeschikbaarheid en opslagtype, prestaties en maximale opslaggrootte, zoals beschreven in de volgende tabel:

Algemeen doel Hyperscale Bedrijfskritiek
Ideaal voor Biedt budgetgerichte, evenwichtige reken- en opslagopties. De meeste zakelijke workloads. Automatisch schalen van opslaggrootte tot 100 TB, snelle verticale en horizontale rekenschaalaanpassing, snel databaseherstel. OLTP-toepassingen met een hoge transactiesnelheid en lage IO-latentie. Biedt de hoogste tolerantie voor fouten en snelle failovers met behulp van meerdere synchroon bijgewerkte replica's.
Rekenkracht 1 tot 80 vCores 1 tot 80 vCores1 1 tot 80 vCores
Opslagtype Premium externe opslag (per exemplaar) Niet-gekoppelde opslag met lokale SSD-cache (per exemplaar) Super snelle lokale SSD-opslag (per exemplaar)
Opslaggrootte1 5 GB – 4 TB Tot 100 TB 5 GB – 4 TB
IOPS 500 IOPS per vCore met maximaal 7.000 IOPS Hyperscale is een architectuur met meerdere lagen met caching op meerdere niveaus. Effectieve IOPS is afhankelijk van de workload. 5.000 IOPS met maximaal 200.000 IOPS
Beschikbaarheid 1 replica, geen uitschaling lezen, zone-redundante hoge beschikbaarheid (preview), geen lokale cache Meerdere replica's, maximaal 4 lees-uitschalen, zone-redundante hoge beschikbaarheid, gedeeltelijke lokale cache 3 replica's, 1 Read Scale-out, zone-redundante HA, volledige lokale opslag
Back-ups Een keuze uit geografisch redundante, zone-redundante of lokaal redundante back-upopslag, retentie van 1-35 dagen (standaard 7 dagen) Een keuze uit geografisch redundante, zone-redundante of lokaal redundante back-upopslag, retentie van 1-35 dagen (standaard 7 dagen) Een keuze uit geografisch redundante, zone-redundante of lokaal redundante back-upopslag, retentie van 1-35 dagen (standaard 7 dagen)

1 Elastische pools worden niet ondersteund in de Hyperscale-servicelaag.

Notitie

Back-upretentie voor korte termijn voor 1-35 dagen voor Hyperscale-databases is nu in preview.

Architectuur voor gedistribueerde functies

Hyperscale scheidt de queryverwerkingsengine van de onderdelen die langetermijnopslag en duurzaamheid bieden voor de gegevens. Deze architectuur biedt de mogelijkheid om de opslagcapaciteit zo snel mogelijk te schalen (het oorspronkelijke doel is 100 TB) en de mogelijkheid om rekenresources snel te schalen.

In het volgende diagram ziet u de verschillende typen knooppunten in een Hyperscale-database:

Architectuur

Meer informatie over de architectuur van gedistribueerde Hyperscale-functies.

Voordelen van schaal en prestaties

Met de mogelijkheid om snel extra alleen-lezen rekenknooppunten op te zetten/omlaag, biedt de Hyperscale-architectuur aanzienlijke mogelijkheden voor leesschaal en kan het primaire rekenknooppunt ook vrijmaken voor meer schrijfaanvragen. Bovendien kunnen de rekenknooppunten snel omhoog/omlaag worden geschaald vanwege de architectuur voor gedeelde opslag van de Hyperscale-architectuur.

Hyperscale-databases maken en beheren

U kunt Hyperscale-databases maken en beheren met behulp van de Azure Portal, Transact-SQL, PowerShell en de Azure CLI. Raadpleeg quickstart: Een Hyperscale-database maken.

Bewerking Details Meer informatie
Een Hyperscale-database maken Hyperscale-databases zijn alleen beschikbaar met behulp van het aankoopmodel op basis van vCore. Voorbeelden zoeken voor het maken van een Hyperscale-database in quickstart: Een Hyperscale-database maken in Azure SQL Database.
Een bestaande database upgraden naar Hyperscale Het migreren van een bestaande database in Azure SQL Database naar de Hyperscale-laag is een grootte van de gegevensbewerking. Meer informatie over het migreren van een bestaande database naar Hyperscale.
Een Hyperscale-database omkeren naar de servicelaag Algemeen Als u eerder een bestaande Azure SQL-database naar de Hyperscale-servicelaag hebt gemigreerd, kunt u de database terugdraaien naar de servicelaag Algemeen binnen 45 dagen na de oorspronkelijke migratie naar Hyperscale.

Als u de database wilt migreren naar een andere servicelaag, zoals Bedrijfskritiek, moet u eerst omkeren naar de servicelaag Algemeen en vervolgens de servicelaag wijzigen.
Meer informatie over het omkeren van migratie van Hyperscale, met inbegrip van de beperkingen voor omgekeerde migratie.

Hoge beschikbaarheid van databases in Hyperscale

Net als in alle andere servicelagen garandeert Hyperscale duurzaamheid van gegevens voor vastgelegde transacties, ongeacht de beschikbaarheid van rekenreplica's. De mate van downtime omdat de primaire replica niet beschikbaar is, is afhankelijk van het type failover (gepland versus niet-gepland), of zoneredundantie is geconfigureerd en op de aanwezigheid van ten minste één replica met hoge beschikbaarheid. In een geplande failover (bijvoorbeeld een onderhoudsgebeurtenis), maakt het systeem de nieuwe primaire replica voordat een failover wordt gestart of gebruikt een bestaande replica met hoge beschikbaarheid als failoverdoel. In een niet-geplande failover (bijvoorbeeld een hardwarefout op de primaire replica), gebruikt het systeem een replica met hoge beschikbaarheid als failoverdoel als er een bestaat of maakt een nieuwe primaire replica uit de pool met beschikbare rekencapaciteit. In het laatste geval is de downtime langer vanwege extra stappen die nodig zijn om de nieuwe primaire replica te maken.

Zie SLA voor Azure SQL Database voor Hyperscale SLA.

Back-up en herstel

Back-up- en herstelbewerkingen voor Hyperscale-databases zijn gebaseerd op bestandsmomentopnamen. Hierdoor kunnen deze bewerkingen bijna onmiddellijk worden uitgevoerd. Aangezien hyperscale-architectuur gebruikmaakt van de opslaglaag voor back-up en herstel, worden de verwerkingslast en prestatieimpact voor rekenreplica's aanzienlijk verminderd. Meer informatie over Hyperscale-back-ups en opslagredundantie.

Herstel na noodgevallen voor Hyperscale-databases

Als u een Hyperscale-database in Azure SQL Database wilt herstellen naar een andere regio dan de regio waarin deze momenteel wordt gehost, als onderdeel van een noodherstelbewerking of drill, herlocatie of een andere reden, is de primaire methode een geo-herstelbewerking van de database uit te voeren. Geo-herstel is alleen beschikbaar wanneer geografisch redundante opslag (RA-GRS) is gekozen voor opslagredundantie.

Meer informatie over het herstellen van een Hyperscale-database naar een andere regio.

Bekende beperkingen

Dit zijn de huidige beperkingen van de Hyperscale-servicelaag. We werken er actief aan om zoveel mogelijk van deze beperkingen te verwijderen.

Probleem Beschrijving
Langetermijnretentie van back-ups Back-upretentie voor korte termijn voor 1-35 dagen voor Hyperscale-databases is nu in preview. Een niet-Hyperscale-database kan niet worden hersteld als een Hyperscale-database en een Hyperscale-database kan niet worden hersteld als een niet-Hyperscale-database.

Voor databases die zijn gemigreerd naar Hyperscale vanuit andere Azure SQL Database-servicelagen, worden back-ups vóór de migratie bewaard voor de duur van de back-upretentieperiode van de brondatabase, inclusief langetermijnretentiebeleid. Het herstellen van een back-up vóór de migratie binnen de bewaarperiode van de back-up van de database wordt ondersteund via de opdrachtregel. U kunt deze back-ups herstellen naar een andere servicelaag dan Hyperscale.
Langetermijnretentie van back-ups Langetermijnretentie van back-ups voor Hyperscale-databases is nu in preview.
Servicelaag wijzigen van Hyperscale in Algemeen laag wordt rechtstreeks ondersteund in beperkte scenario's Met omgekeerde migratie van Hyperscale kunnen klanten die onlangs een bestaande Azure SQL Database naar de Hyperscale-servicelaag hebben gemigreerd, overstappen naar Algemeen laag, als Hyperscale niet aan hun behoeften voldoet. Hoewel omgekeerde migratie wordt gestart door een wijziging in de servicelaag, is het in feite een verplaatsing van grootte van gegevens tussen verschillende architecturen. Databases die zijn gemaakt in de Hyperscale-servicelaag komen niet in aanmerking voor omgekeerde migratie. Meer informatie over de beperkingen voor omgekeerde migratie.

Voor databases die niet in aanmerking komen voor omgekeerde migratie, is de enige manier om van Hyperscale naar een niet-Hyperscale-servicelaag te migreren of importeren met behulp van een bacpac-bestand of andere technologieën voor gegevensverplaatsing (bulkkopie, Azure Data Factory, Azure Databricks, SSIS, enzovoort) Bacpac exporteren/importeren vanuit Azure Portal, vanuit PowerShell met behulp van New-AzSqlDatabaseExport of New-AzSqlDatabaseImport, vanuit Azure CLI met behulp van az sql db export en az sql db import, en vanuit REST API wordt niet ondersteund. Bacpac importeren/exporteren voor kleinere Hyperscale-databases (maximaal 200 GB) wordt ondersteund met behulp van SSMS en SqlPackage versie 18.4 en hoger. Voor grotere databases kan het exporteren/importeren van bacpac lang duren en om verschillende redenen mislukken.
Elastische pools Elastische pools worden momenteel niet ondersteund met Hyperscale.
Migratie van databases met In-Memory OLTP-objecten Hyperscale ondersteunt een subset van In-Memory OLTP-objecten, waaronder tabeltypen die zijn geoptimaliseerd voor geheugen, tabelvariabelen en systeemeigen gecompileerde modules. Wanneer er echter In-Memory OLTP-objecten aanwezig zijn in de database die wordt gemigreerd, wordt migratie van Premium- en Bedrijfskritiek-servicelagen naar Hyperscale niet ondersteund. Als u een dergelijke database naar Hyperscale wilt migreren, moeten alle In-Memory OLTP-objecten en de bijbehorende afhankelijkheden worden verwijderd. Nadat de database is gemigreerd, kunnen deze objecten opnieuw worden gemaakt. Duurzame en niet-duurzame tabellen die zijn geoptimaliseerd voor geheugen worden momenteel niet ondersteund in Hyperscale en moeten worden gewijzigd in schijftabellen.
Database verkleinen DBCC SHRINKDATABASE, DBCC SHRINKFILE of AUTO_SHRINK instellen op AAN op databaseniveau, worden momenteel niet ondersteund voor Hyperscale-databases.
Controle van databaseintegriteit DBCC CHECKDB wordt momenteel niet ondersteund voor Hyperscale-databases. DBCC CHECKTABLE ('TableName') MET TABLOCK en DBCC CHECKFILEGROUP WITH TABLOCK kan worden gebruikt als tijdelijke oplossing. Zie Gegevensintegriteit in Azure SQL Database voor meer informatie over het beheer van gegevensintegriteit in Azure SQL Database.
Elastische taken Het gebruik van een Hyperscale-database omdat de taakdatabase niet wordt ondersteund. Elastische taken kunnen echter op dezelfde manier als andere databases in Azure SQL Database worden gericht op Hyperscale-databases.
Gegevens synchroniseren Het gebruik van een Hyperscale-database als hub- of synchronisatiemetagegevensdatabase wordt niet ondersteund. Een Hyperscale-database kan echter een liddatabase zijn in een Data Sync-topologie.

Volgende stappen

Meer informatie over Hyperscale in Azure SQL Database vindt u in de volgende artikelen: