Service-lagen in het op DTU gebaseerde aankoopmodel

VAN TOEPASSING OP: Azure SQL Database

Servicelagen in het aankoopmodel op basis van DTU worden onderscheiden door een reeks rekengrootten met een vaste hoeveelheid inbegrepen opslag, een vaste retentieperiode voor back-ups en een vaste prijs. Alle servicelagen in het aankoopmodel op basis van DTU bieden flexibiliteit bij het wijzigen van de rekengrootte met minimale downtime; Er is echter een switch gedurende een bepaalde periode waarbij de verbinding met de database gedurende korte tijd verloren gaat, wat kan worden beperkt met behulp van logica voor opnieuw proberen. Individuele databases en elastische pools worden per uur gefactureerd op basis van de servicelaag en rekenkracht.

Belangrijk

Azure SQL Managed Instance biedt geen ondersteuning voor een aankoopmodel op basis van DTU.

Notitie

Zie vCore-servicelagenvoor meer informatie over op vCore gebaseerde servicelagen. Zie Aankoopmodellen voor meer informatie over het differentiëren van DTU-servicelagen en vCore-servicelagen.

De DTU-servicelagen vergelijken

Het kiezen van een servicelaag is voornamelijk afhankelijk van bedrijfscontinuïteit, opslag en prestatievereisten.

Basic Standard Premium
Doelworkload Ontwikkeling en productie Ontwikkeling en productie Ontwikkeling en productie
Uptime SLA 99,99% 99,99% 99,99%
Maximale back-upretentie 7 dagen 35 dagen 35 dagen
CPU Beperkt Laag, Gemiddeld, Hoog Gemiddeld, hoog
IOPS (bij benadering)* 1-4 IOPS per DTU 1-4 IOPS per DTU >25 IOPS per DTU
I/O-latentie (bij benadering) 5 ms (lezen), 10 ms (schrijven) 5 ms (lezen), 10 ms (schrijven) 2 ms (lezen/schrijven)
Columnstore-indexering N.v.t. S3 en hoger Ondersteund
In-memory OLTP N.v.t. N.v.t. Ondersteund

* Alle IOPS lezen en schrijven op gegevensbestanden, inclusief achtergrond-IO (controlepunt en luie schrijver)

Belangrijk

De servicedoelstellingen Basic, S0, S1 en S2 bieden minder dan één vCore (CPU). Voor CPU-intensieve workloads wordt een servicedoelstelling van S3 of hoger aanbevolen.

In de servicedoelstellingen Basic, S0 en S1 worden databasebestanden opgeslagen in Azure Standard Storage, dat gebruikmaakt van hdd-opslagmedia (Hard Disk Drive). Deze servicedoelstellingen zijn het meest geschikt voor ontwikkeling, tests en andere werkbelastingen die niet vaak worden gebruikt en die minder gevoelig zijn voor de variabiliteit van de prestaties.

Tip

Als u de werkelijke resourcebeheerlimieten voor een database of elastische pool wilt bekijken, moet u een query uitvoeren sys.dm_user_db_resource_governance weergave.

Notitie

U kunt een gratis database krijgen in Azure SQL Database de servicelaag Basic in combinatie met een gratis Azure-account om Azure te verkennen. Zie Een beheerde clouddatabase maken met uw gratis Azure-account voor meer informatie.

DTU- en opslaglimieten voor individuele databases

Rekengrootten worden uitgedrukt in DTUs (Database Transaction Units) voor individuele databases en eDTUs (Elastic Database Transaction Units) voor elastische pools. Zie Aankoopmodel op basis van DTU voor meer informatie over DTU's en eDTU's.

Basic Standard Premium
Maximale opslaggrootte 2 GB 1 TB 4 TB
Maximum DTUs 5 3000 4000

Belangrijk

Onder bepaalde omstandigheden moet u mogelijk een database verkleinen om ongebruikte ruimte vrij te maken. Zie Bestandsruimte beheren in Azure SQL Database.

eDTU-, opslag- en pooldatabaselimieten voor elastische pool

Basic Standard Premium
Maximale opslaggrootte per database 2 GB 1 TB 1 TB
Maximale opslaggrootte per pool 156 GB 4 TB 4 TB
Maximum aantal eDTUs per database 5 3000 4000
Maximum aantal eDTUs per pool 1600 3000 4000
Maximumaantal databases per pool 500 500 100

Belangrijk

Meer dan 1 TB aan opslag in de Premium-laag is momenteel beschikbaar in alle regio's behalve: China - oost, China - noord, Duitsland - centraal en Duitsland - noordoost. In deze regio’s is de maximale opslagruimte in de Premium-laag beperkt tot 1 TB. Raadpleeg P11-P15 huidige beperkingen voor meer informatie.

Belangrijk

Onder bepaalde omstandigheden moet u mogelijk een database verkleinen om ongebruikte ruimte vrij te maken. Zie Bestandsruimte beheren in Azure SQL Database voor meer Azure SQL Database.

DTU-benchmark

Fysieke kenmerken (CPU, geheugen, IO) die aan elke DTU-meting zijn gekoppeld, worden ge kalibreerd met behulp van een benchmark die de werkelijke databaseworkload simuleert.

Benchmarkresultaten correeren met databaseprestaties in de echte wereld

Het is belangrijk om te begrijpen dat alle benchmarks alleen representatief en indicatief zijn. De transactietarieven die met de benchmarktoepassing worden behaald, zijn niet hetzelfde als de tarieven die kunnen worden bereikt met andere toepassingen. De benchmark bestaat uit een verzameling verschillende transactietypen die worden uitgevoerd op een schema dat een reeks tabellen en gegevenstypen bevat. Hoewel de benchmark dezelfde basisbewerkingen gebruikt die gemeenschappelijk zijn voor alle OLTP-workloads, vertegenwoordigt deze geen specifieke klasse van de database of toepassing. Het doel van de benchmark is om een redelijke handleiding te bieden voor de relatieve prestaties van een database die kan worden verwacht bij het omhoog of omlaag schalen tussen rekengrootten. Databases hebben in werkelijkheid verschillende grootten en complexiteit, ondervinden verschillende combinaties van workloads en reageren op verschillende manieren. Een IO-intensieve toepassing kan bijvoorbeeld eerder I/O-drempelwaarden bereiken of een CPU-intensieve toepassing kan de CPU-limieten eerder overschrijden. Er is geen garantie dat een bepaalde database op dezelfde manier wordt geschaald als de benchmark onder toenemende belasting.

De benchmark en de methodologie worden hieronder gedetailleerder beschreven.

Benchmarksamenvatting

De benchmark meet de prestaties van een combinatie van basisdatabasebewerkingen die het vaakst voorkomen in OLTP-workloads (Online Transaction Processing). Hoewel de benchmark is ontworpen met cloud-computing in gedachten, zijn het databaseschema, de gegevenspopulatie en transacties zo ontworpen dat deze globaal representatief zijn voor de basiselementen die het meest worden gebruikt in OLTP-workloads.

Schema

Het schema is ontworpen om voldoende variatie en complexiteit te hebben om een breed scala aan bewerkingen te ondersteunen. De benchmark wordt uitgevoerd voor een database die uit zes tabellen bestaat. De tabellen kunnen worden onderverdeeld in drie categorieën: vaste grootte, schalen en groeien. Er zijn twee tabellen met een vaste grootte; drie tabellen schalen; en één groeiende tabel. Tabellen met een vaste grootte hebben een constant aantal rijen. Het schalen van tabellen heeft een kardinaliteit die evenredig is met de prestaties van de database, maar die niet verandert tijdens de benchmark. De groeiende tabel is bij de eerste belasting geschaald als een schaaltabel, maar de kardinaliteit verandert tijdens het uitvoeren van de benchmark wanneer rijen worden ingevoegd en verwijderd.

Het schema bevat een combinatie van gegevenstypen, waaronder geheel getal, numeriek, teken en datum/tijd. Het schema bevat primaire en secundaire sleutels, maar geen referentiële sleutels, dat wil zeggen dat er geen beperkingen voor referentiële integriteit zijn tussen tabellen.

Een programma voor het genereren van gegevens genereert de gegevens voor de initiële database. Gehele getallen en numerieke gegevens worden gegenereerd met verschillende strategieën. In sommige gevallen worden waarden willekeurig verdeeld over een bereik. In andere gevallen wordt een set waarden willekeurig gepermuteerd om ervoor te zorgen dat een specifieke verdeling behouden blijft. Tekstvelden worden gegenereerd op basis van een gewogen lijst met woorden om realistisch uitziende gegevens te produceren.

De grootte van de database is gebaseerd op een 'schaalfactor'. De schaalfactor (afgekort als SF) bepaalt de kardinaliteit van de tabellen die worden geschaald en groeien. Zoals hieronder wordt beschreven in de sectie Gebruikers en Pacing, worden de grootte van de database, het aantal gebruikers en de maximale prestaties evenredig met elkaar geschaald.

Transacties

De workload bestaat uit negen transactietypen, zoals wordt weergegeven in de onderstaande tabel. Elke transactie is ontworpen om een bepaalde set systeemkenmerken in de database-engine en systeemhardware te markeren, met hoog contrast van de andere transacties. Deze aanpak maakt het gemakkelijker om de impact van verschillende onderdelen op de algehele prestaties te beoordelen. De transactie 'Read Heavy' produceert bijvoorbeeld een groot aantal leesbewerkingen vanaf schijf.

Transactietype Description
Read Lite SELECT; in-memory; alleen-lezen
Gemiddeld lezen SELECT; voornamelijk in het geheugen; alleen-lezen
Leeszware SELECT; meestal niet in het geheugen; alleen-lezen
Update Lite UPDATE; in-memory; lezen/schrijven
Update Heavy UPDATE; meestal niet in het geheugen; lezen/schrijven
Insert Lite INSERT; in-memory; lezen/schrijven
Heavy invoegen INSERT; meestal niet in het geheugen; lezen/schrijven
Verwijderen VERWIJDEREN; combinatie van in-memory en niet in-memory; lezen/schrijven
CPU-intensief SELECT; in-memory; relatief zware CPU-belasting; alleen-lezen

Workloads combineren

Transacties worden willekeurig geselecteerd uit een gewogen verdeling met de volgende algemene combinatie. De totale combinatie heeft een lees-/schrijfverhouding van ongeveer 2:1.

Transactietype % van de combinatie
Read Lite 35
Gemiddeld lezen 20
Leeszware 5
Update Lite 20
Update Heavy 3
Insert Lite 3
Heavy invoegen 2
Verwijderen 2
CPU-intensief 10

Gebruikers en pacing

De benchmarkworkload wordt aangestuurd door een hulpprogramma dat transacties over een reeks verbindingen verstuurt om het gedrag van een aantal gelijktijdige gebruikers te simuleren. Hoewel alle verbindingen en transacties automatisch worden gegenereerd, verwijzen we voor het gemak naar deze verbindingen als 'gebruikers'. Hoewel elke gebruiker onafhankelijk van alle andere gebruikers werkt, voeren alle gebruikers dezelfde cyclus van stappen uit die hieronder worden weergegeven:

  1. Een databaseverbinding tot stand brengen.
  2. Herhaal dit totdat wordt gesignaleerd om af te sluiten:
    • Selecteer een willekeurige transactie (uit een gewogen verdeling).
    • Voer de geselecteerde transactie uit en meet de reactietijd.
    • Wacht op een pacing-vertraging.
  3. Sluit de databaseverbinding.
  4. Afsluiten.

De pacing-vertraging (in stap 2c) wordt willekeurig geselecteerd, maar met een distributie met een gemiddelde van 1,0 seconde. Elke gebruiker kan dus gemiddeld één transactie per seconde genereren.

Regels voor schalen

Het aantal gebruikers wordt bepaald door de grootte van de database (in schaalfactor-eenheden). Er is één gebruiker voor elke vijf schaalfactor-eenheden. Vanwege de pacing-vertraging kan één gebruiker gemiddeld één transactie per seconde genereren.

Een schaalfactor van 500 (SF=500) heeft bijvoorbeeld 100 gebruikers en kan een maximale snelheid van 100 TPS bereiken. Voor een hogere TPS-snelheid zijn meer gebruikers en een grotere database vereist.

Duur van de meting

Voor een geldige benchmark-run is een metingsduur van ten minste één uur vereist.

Metrische gegevens

De belangrijkste metrische gegevens in de benchmark zijn doorvoer en reactietijd.

  • Doorvoer is de essentiële prestatiemeting in de benchmark. Doorvoer wordt gerapporteerd in transacties per tijdseenheid, met het tellen van alle transactietypen.
  • Reactietijd is een maat voor de voorspelbaarheid van prestaties. De beperking van de reactietijd is afhankelijk van de serviceklasse, en hogere serviceklassen hebben een strengere reactietijdvereiste, zoals hieronder wordt weergegeven.
Serviceklasse Meting doorvoer Vereiste reactietijd
Premium Transacties per seconde 95e percentiel op 0,5 seconden
Standard Transacties per minuut 90e percentiel na 1,0 seconden
Basic Transacties per uur 80e percentiel na 2,0 seconden

Notitie

Metrische gegevens voor reactietijd zijn specifiek voor de DTU-benchmark. Reactietijden voor andere workloads zijn afhankelijk van de werkbelasting en verschillen.

Volgende stappen

  • Zie op DTU gebaseerde resourcelimieten voor individuele SQL Database databases voor meer informatie over specifieke rekengrootten en opties voor opslaggrootten die beschikbaar zijn voor individuele databases.
  • Zie op DTUgebaseerde resourcelimieten voor meer informatie over specifieke rekengrootten en opties voor opslaggrootten die beschikbaar zijn voor elastische SQL Database pools.