Hyperscale-servicelaag

Van toepassing op:Azure SQL Database

Azure SQL Database Hyperscale is een kostenefficiënte clouddatabase met hoge prestaties.

Azure SQL Database is gebaseerd op de SQL-Database Engine. Hyperscale verschilt van andere Azure SQL Database servicelagen:

• In tegenstelling tot andere servicelagen heeft Hyperscale geen licentiekosten voor SQL-software, waardoor het een aanzienlijk prijsvoordeel biedt ten opzichte van andere Azure SQL Database servicelagen voor databases met hoge prestaties.
• Hyperscale-architectuur is uniek: het biedt bijna onmiddellijke back-ups, snelle herstelbewerkingen en hoge doorvoer voor lees- en schrijfbewerkingen.
• Hyperscale biedt het snel opschalen van rekenkracht naar behoefte zonder gegevensverplaatsing.
• Scale-outstrategieën voor leesbewerkingen zijn eenvoudig te implementeren, met maximaal 30 benoemde replica's met onafhankelijk configureerbare rekenkracht, plus ingebouwde replica's voor hoge beschikbaarheid en configureerbare geo-replica's wereldwijd.

De Hyperscale-servicelaag is geschikt voor alle workloadtypen. Reken- en opslagresources in Hyperscale overschrijden aanzienlijk de resources die beschikbaar zijn in de Azure SQL Database lagen Algemeen gebruik en Bedrijfskritiek.

U kunt een bestaande database in Azure SQL Database eenvoudig converteren naar Hyperscale of migreren van elke SQL Server-database naar Hyperscale. Zie Azure databasemigratiehandleidingen voor het migreren van andere databases naar Azure SQL Database.

De Hyperscale-servicelaag is momenteel alleen beschikbaar voor Azure SQL Database en niet voor Azure SQL Managed Instance.

Wat zijn de Hyperscale-mogelijkheden?

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

• Snel omhoog schalen: schaal uw rekenresources omhoog om zware werkbelastingen te verwerken wanneer dat nodig is en schaal de rekenresources weer omlaag wanneer dat niet nodig is.
• Snel opschalen - implementeer een of meer alleen-lezen-replica's voor het afhandelen van uw leeswerklast en voor gebruik als hot stand-by's.
• Automatisch opschalen, afschalen en facturering voor rekenkracht op basis van gebruik met serverloze compute.
• Geoptimaliseerde prijs/prestaties voor een groep Hyperscale-databases met verschillende resourcevereisten met elastische pools.
• Automatisch schalen van opslag met ondersteuning voor maximaal 128 TB aan database- of 100 TB elastische poolgrootte.
• Hogere algehele prestaties vanwege een hogere doorvoer van transactielogboeken en snellere doorvoer van transacties, ongeacht gegevensvolumes.
• Snelle databaseback-ups (op basis van momentopnamen van bestanden) ongeacht de grootte zonder I/O-invloed op rekenresources.
• Snelle database herstelt of kopieert (op basis van momentopnamen van bestanden) in minuten in plaats van uren of dagen.

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 dergelijke limieten niet. 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 toegewezen opslagcapaciteit. Voor leesintensieve werklasten biedt de Hyperscale-servicelaag snelle uitschaling door extra replica's in te richten indien nodig voor het verminderen van leeswerklasten.

Daarnaast is de tijd die nodig is om databaseback-ups te maken of omhoog of omlaag te schalen niet meer gekoppeld aan het volume aan gegevens in de database. Er wordt vrijwel onmiddellijk een back-up gemaakt van Hyperscale-databases. U kunt een database in de tientallen terabytes ook binnen enkele minuten omhoog of omlaag schalen in de ingerichte rekenlaag of serverloze gebruiken om de berekening automatisch te schalen. Deze mogelijkheid bevrijdt u van zorgen over vastzitten door uw initiële configuratiekeuzes.

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

Zie voor meer informatie over de servicelagen Algemeen gebruik en Bedrijfskritiek in het aankoopmodel op basis van vCore Algemeen gebruik en Bedrijfskritieke servicelagen. Zie voor een vergelijking van het aankoopmodel op basis van vCore met het aankoopmodel op basis van DTU Compare vCore en DTU-aankoopmodellen van Azure SQL Database.

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 snelle opslag- en rekenschaalbaarheid. Hyperscale is ideaal voor klanten die overstappen naar de cloud om hun toepassingen te moderniseren of voor 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).

Prijsmodel voor Hyperscale

Voor databases met hoge prestaties biedt Hyperscale een aanzienlijk prijsvoordeel ten opzichte van andere Azure SQL Database servicelagen. Zie voor meer informatie blog: aankondiging van Hyperscale-prijzen voor Azure SQL Database op Ignite 2023. Zie Blog: Azure SQL Database Hyperscale - lagere, vereenvoudigde prijzen!

De Hyperscale-servicelaag is alleen beschikbaar in het vCore-model en wordt geleverd in twee rekenlagen. Facturering voor Hyperscale is gebaseerd op de ingerichte of serverloze rekenlaag:

• Geprovisioneerde rekenlaag:

  De vCore-rekenkosten weerspiegelen de totale rekencapaciteit die continu wordt ingericht voor de toepassing. De prijs van de Hyperscale-rekeneenheid is voor elke replica.

• Serverloze rekenlaag:

  Facturering voor serverloze rekenkracht is gebaseerd op gebruik. Zie Serverloze rekenlaag voor Azure SQL Database voor meer informatie.

U geeft niet de maximale gegevensgrootte op bij het configureren van een Hyperscale-database. In de Hyperscale-laag betaalt u voor opslag op basis van de werkelijke toewijzing. Opslag wordt automatisch toegewezen tussen 10 GB en 128 TB en groeit naar behoefte. Voor meer informatie, zie In welke stappen groeit mijn databasegrootte?

Voordelen van schaal en prestaties

Hyperscale scheidt de hoofddatabase-engine van de onderdelen die langetermijnopslag en duurzaamheid bieden voor de gegevens. Met deze architectuur kunt u rekenresources snel schalen, zonder gegevensverplaatsing en opslag (maximaal 128 TB) onafhankelijk van berekeningen schalen. Zie de Hyperscale-architectuur voor meer informatie, waaronder een architectuurdiagram.

• Doordat extra alleen-lezen-computeknooppunten snel kunnen worden op- en afgeschaald, biedt de Hyperscale-architectuur aanzienlijke schaalbaarheid voor leesbewerkingen en kan er ook voor zorgen dat het primaire computeknooppunt vrijkomt om meer verzoeken te verwerken.
• Je kunt de compute provisionen voor secundaire nodes of serverless compute gebruiken. In beide gevallen kunt u ze snel omhoog of omlaag schalen vanwege de architectuur voor gedeelde opslag van Hyperscale.
  • Secundaire replica's van rekenknooppunten met hoge beschikbaarheid in Hyperscale volgen de rekenlaag van de primaire, wat resulteert in failovers met een lage impact.
• Wanneer u serverloze, primaire of secundaire rekenknooppunten gebruikt, wordt automatisch geschaald op basis van uw workloadvraag.

De primaire Azure SQL Database Hyperscale-database verwerkt zowel lees- als schrijfworkloads, maar u kunt eenvoudig alleen-lezen replica's maken als onderdeel van uw toepassingsstrategie:

• U kunt het totale aantal secundaire replica's met hoge beschikbaarheid aanpassen van 0 tot 4, afhankelijk van de beschikbaarheids- en schaalbaarheidsvereisten.
• U kunt maximaal 30 benoemde replica's maken om leesworkloads met uitschaling te ondersteunen.
• U kunt geografisch gedistribueerde uitschaling voor leesbewerkingen over de wereldwijde Azure-datacenters realiseren met behulp van geo-replica's.

Hoge beschikbaarheid van databases in Hyperscale

Net als in alle andere servicelagen garandeert Hyperscale de duurzaamheid van gegevens voor doorgevoerde transacties, ongeacht de beschikbaarheid van replika's. De mate van downtime omdat de primaire replica niet beschikbaar is, is afhankelijk van het type failover (gepland versus ongepland), of zoneredundantie is geconfigureerden op de aanwezigheid van ten minste één replica met hoge beschikbaarheid. Bij een geplande failover (zoals 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 (zoals 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 duurt de downtime langer vanwege extra stappen die nodig zijn om de nieuwe primaire replica te maken.

U kunt een onderhoudsvenster kiezen om impactvolle onderhoudsevenementen voorspelbaar en minder verstorend te maken voor uw workload.

Zie SLA voor Azure SQL Database voor Hyperscale SLA.

bufferpool en uitbreiding voor een robuuste bufferpool

In Azure Database Hyperscale is er een afzonderlijke scheiding tussen rekenkracht en opslag. Opslag bevat alle databasepagina's in één database en kan worden toegewezen over meerdere computers naarmate de database groeit. Het rekenknooppunt slaat echter alleen in de cache op wat er onlangs wordt gebruikt. De heetste pagina's in de computer worden in het geheugen gehouden in een structuur genaamd buffer pool (BP). Het wordt ook opgeslagen in de lokale SSD, de tolerante buffergroepextensie (RBPEX), zodat gegevens sneller kunnen worden opgehaald als het rekenproces opnieuw wordt opgestart.

In een cloudsysteem kan compute naar verschillende computers worden verplaatst, indien nodig. De rekenlaag kan meerdere replica's hebben. Eén replica is primair en ontvangt alle updates, terwijl de andere secundaire replica's zijn. Als de primaire replica uitvalt, promoveert het systeem een van de secundaire replica's met hoge beschikbaarheid tot primaire replica in een proces dat failover wordt genoemd. De secundaire replica beschikt mogelijk niet over een cache in de BP en RBPEX die is geoptimaliseerd voor de primaire werkbelasting.

Doorlopende priming

Continue priming is een proces waarbij informatie wordt verzameld over welke pagina's in alle computerreplica's het vaakst worden benaderd (de meest actieve pagina's). Het proces voegt deze informatie samen en secundaire replica's met hoge beschikbaarheid gebruiken de lijst met heetste pagina's die overeenkomen met de typische workload van de klant. Dit proces vult zowel de BP als de RBPEX voortdurend met de meest gebruikte pagina's om gelijke tred te houden met veranderingen in de workload van de klant.

Zonder voortdurende priming worden zowel BP als RBPEX niet overgenomen door nieuwe replica's voor hoge beschikbaarheid en worden ze alleen tijdens de gebruikersbelasting opnieuw opgebouwd. Continue priming bespaart tijd en voorkomt inconsistente prestaties, omdat er geen wachttijd is voordat de caches volledig gehydrateerd zijn. Met continue priming beginnen nieuwe secundaire replica's met hoge beschikbaarheid onmiddellijk met het aanbrengen van hun BP en RBPEX. Dit helpt de prestaties consistenter te houden naarmate er failovers plaatsvinden.

Continue priming werkt in beide richtingen: secundaire replica's met hoge beschikbaarheid cachen pagina's die worden gebruikt in de primaire replica, en de primaire replica cacht pagina's met de werklast van de secundaire replica's.

Doorlopende priming is momenteel beschikbaar in de geconfigureerde Hyperscale-rekenlaag.

Back-up maken en herstellen

Back-up- en herstelbewerkingen voor Hyperscale-databases zijn gebaseerd op bestandsmomentopnamen. Deze aanpak maakt deze bewerkingen vrijwel onmiddellijk. Omdat de Hyperscale-architectuur gebruikmaakt van de opslaglaag voor back-up en herstel, vermindert dit de verwerkingsbelasting en de prestatieimpact op rekenreplica's. Zie Hyperscale-back-ups en opslagredundantie voor meer informatie.

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, voert u een geo-herstel uit. Deze methode is geschikt voor disaster-recoveryactiviteiten, oefeningen, verplaatsing of om een andere reden. Geo-herstel is alleen beschikbaar wanneer u geografisch redundante opslag (RA-GRS) kiest voor opslagredundantie.

Zie voor meer informatie het herstellen van een Hyperscale-database naar een andere regio.

Resourcelimieten vergelijken

De servicelagen op basis van vCore verschillen in databasebeschikbaarheid, opslagtype, prestaties en maximale opslaggrootte. In de volgende tabel worden deze verschillen beschreven:

¹ Vereenvoudigde prijzen voor SQL Database Hyperscale zijn in december 2023 aangekomen. Raadpleeg de hyperscale-prijzenblog voor meer informatie.

² Vanaf december 2023 is Azure Hybrid Benefit niet beschikbaar voor nieuwe Hyperscale-databases of in dev/test-abonnementen. Bestaande Hyperscale-databases met ingerichte berekeningen kunnen Azure Hybrid Benefit blijven gebruiken om te besparen op de rekenkosten tot december 2026. Raadpleeg de hyperscale-prijzenblogvoor meer informatie.

³ Momenteel zijn de opties voor 160 en 192 vCore een preview-functie.

Rekenresources

In de volgende tabel worden rekenresources in verschillende hardwareconfiguraties en rekenlagen voor Azure SQL Database Hyperscale vergeleken. Voor niet-Hyperscale Azure SQL Database raadpleegt u het vCore-aankoopmodel - Azure SQL Database.

* Voor een bepaalde rekenkracht en hardwareconfiguratie zijn resourcelimieten hetzelfde, ongeacht het CPU-type (Intel® Broadwell, Skylake, Ice Lake, Cascade Lake, Emerald Rapid of AMD Milaan, Genua). In de sys.dm_user_db_resource_governance dynamische beheerweergave wordt hardwaregeneratie voor databases gebruikt met:

• Intel® SP-8160 -processors (Skylake) wordt weergegeven als Gen6
• Intel® 8272CL (Cascade Lake) wordt weergegeven als Gen7
• Intel® Xeon® Platinum 8370C (Ice Lake) of AMD EPYC™ 7763v (Milaan) verschijnen als Gen8
• AMD EPYC™ 9004 (Genua) verschijnen als Gen9 of Intel® Xeon® Platinum 8573C (Emerald Rapids) verschijnen als Gen10

Zie resourcelimieten voor individuele databases en elastische poolsvoor meer informatie.

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. Zie Quickstart: Een Hyperscale-database makenvoor meer informatie.

Beperkingen

Deze beperkingen zijn momenteel van toepassing op de Hyperscale-servicelaag. Het productteam werkt er actief aan om zoveel mogelijk van deze beperkingen te verwijderen.

Verwante inhoud

• Veelgestelde vragen over Hyperscale
• Compare vCore- en DTU-aankoopmodellen van Azure SQL Database
• Resourcebeheer in Azure SQL Database
• Resourcelimieten voor individuele databases met gebruikmaking van het vCore-aankoopmodel
• vergelijking van Features: Azure SQL Database en Azure SQL Managed Instance
• Hyperscale-architectuur voor gedistribueerde functies
• Een Hyperscale-database beheren
• Wijzigbare configuratiereferentie voor Azure SQL Database