Azure SQL Database har i øjeblikket tre serviceniveauer at vælge imellem for din arbejdsbyrde. Disse niveauer består af Basic, Standard og Premium. Basic understøtter kun én størrelse på 5 DTU'er. Premium starter ved 125 DTU'er og går op til 4.000 DTU'er. Premium-laget er det øverste niveau, som er bygget til højere I/O-arbejdsbelastninger og giver lavere latency pr. I/O og en størrelsesorden mere IOPS pr. DTU end i Standard-laget.
Før august 2017 understøttede standardniveauet kun DTU-størrelser mellem 15 og 100 DTU'er. I øjeblikket tilgængelige i forhåndsvisning er nye ydeevneniveauer og lagertilføjelser, der tilbyder prisoptimeringsfordele for CPU-intensive arbejdsbelastninger. Med dem understøtter Standard-laget nu op til 3.000 DTU'er.
På dette tidspunkt spørger du måske dig selv, hvad der helt præcist er en DTU? En DTU er en Database Transaction Unit og er en blanding af CPU, hukommelse og data og transaktionslog I/O. (Andy Mallon, @AMtwo, adresserede for nylig dette i "Hvad pokker er en DTU?") Du kan nå din DTU-grænse ved at udnytte CPU, hukommelse eller I/O maksimalt.
Tidligere tilbød standardniveauet kun 4 niveauer:15, 30, 50 og 100 DTU'er, med en databasestørrelsesgrænse på 250 GB, med standarddisk. Hvis du havde en database, der var større end 250 GB, men ikke havde brug for mere end 100 DTU'er til CPU, hukommelse eller I/O, blev du hængende ved at betale en Premium-pris bare for databasestørrelsen. Med de nye ændringer kan du nu have op til en 1 TB database i standardniveauet; du skal bare betale den ekstra lagerplads. I øjeblikket faktureres lagerplads med $0,085/GB under forhåndsvisningen. En stigning fra den inkluderede størrelse på 250 GB til 1 TB øges med 774 GB til en pris af $65,79 pr. måned.
De nye Standard forhåndsvisning af DTU-størrelser understøtter 200, 400, 800, 1.600 og 3.000 DTU-muligheder. Hvis du har en SQL Server-database-arbejdsbelastning, der er mere CPU-bundet end I/O, har disse standard-tier muligheder potentiale til at spare dig for mange penge; Men hvis din arbejdsbyrde er I/O-bundet, vil Premium-laget klare sig bedre end Standard-laget.
Jeg besluttede at prøve to forskellige arbejdsbelastninger for at se, hvor forskellige Standard- og Premium-niveauerne sammenlignet med hinanden. Jeg ønskede at skabe en enkel og reproducerbar test, så andre kan prøve at validere selv. Til min første test ønskede jeg at generere en sund blanding af CPU og I/O. Jeg håbede, at jeg ville skubbe mere CPU end I/O og være i stand til at vise, at det udvidede Standard-lag ville overgå et Premium-lag med samme DTU-størrelse. Jeg fik ikke lige de resultater, jeg håbede på.
For at konfigurere denne demo oprettede jeg en tabel med tre GUID-kolonner, indsatte 1 million rækker og opdaterede derefter to af de tre kolonner med nye ID'er. Eksempelkoden er nedenfor:
CREATE TABLE dbo.TestTable ( Table_id UNIQUEIDENTIFIER DEFAULT NEWID(), Customer_id UNIQUEIDENTIFIER DEFAULT NEWID(), Cust_Name VARCHAR(40) DEFAULT CAST(NEWID() AS VARCHAR(40)) ); SET NOCOUNT ON; GO INSERT INTO dbo.TestTable DEFAULT VALUES; GO 1000000 CREATE CLUSTERED INDEX [ClustTestTable] ON [dbo].[TestTable] ( [Table_id] ASC, [Customer_id] ASC ); SET STATISTICS TIME ON; UPDATE TestTable SET Table_id = NEWID(), Customer_id = NEWID();
Efterhånden som jeg kørte gennem serien af tests, blev ydeevnen støt forbedret i Standard-niveauet, indtil jeg kom til S12-indstillingen, hvor CPU og forløbet tid mærkeligt nok steg. Jeg kørte testen flere gange, og S12 var konsekvent 54 sekunder. Det er ret klart med min første test, at Premium-laget klarede sig bedre end Standard-laget. For eksempel er S9 og P2 tættest på tiden, men DTU-størrelsen for Standard er 1.600 sammenlignet med 250 for P2. Denne test handler mere om I/O-funktionerne. Nedenstående diagram viser størrelse, DTU-niveau, pris, CPU-tid, forløbet tid og tid i sekunder for hver test:
Mens testene blev udført, observerede jeg i monitorens dashboard, at data-I/O og log I/O-procent var drivkraften bag DTU-procenten. Følgende diagram var fra en kørsel mod en S4-database:
Jeg besluttede mig for at prøve en anden serie af tests, der ville være mere CPU-tunge. Til den test brugte jeg følgende script:
SET STATISTICS TIME ON;
SELECT SUM(CONVERT(BIGINT, t1.object_id)
+ CONVERT(BIGINT, t2.object_id)
+ CONVERT(BIGINT, t3.object_id)
+ CONVERT(BIGINT, t4.object_id))
FROM sys.objects t1
CROSS JOIN sys.objects t2
CROSS JOIN sys.objects t3
CROSS JOIN sys.objects t4; Det, jeg observerede på skærmens dashboard i denne serie af tests, er, at CPU-procenten var den eneste driver for DTU-procenten. Da jeg gennemgik rækken af tests i Standard-niveauet, så testen ud til at blive plateau på omkring 27 sekunder og startede ved S4-størrelsen. Det, der slog mig som mærkeligt, er, at en S4 på 200 DTU tog 27 sekunder at gennemføre, og den tilsvarende P2 på 250 DTU tog 38 sekunder; en P4 på 500 DTU var mere sammenlignelig. Hvis vi ser på omkostningsforskellen for denne demo, koster en S4 under preview kun $150,01, mens en P4 koster $1.860; S4 giver en omkostningsbesparelse på lidt over $1.700. Lad os forestille os, at en P2 på 250 DTU'er fungerede, som vi havde forventet; en P2 koster $930 og ville stadig koste $780 mere end en S4.
De fulde resultater af alle tests i den anden demo er inkluderet i følgende diagram:
I modsætning til den første demo var denne 100% CPU-drevet. Jeg havde forsøgt at inkludere en ekstra cross join, men demoen tog derefter timer pr session i stedet for minutter. Til en fremtidig test vil jeg forsøge at komme med et par yderligere scenarier, der presser en mere realistisk OLTP-arbejdsbyrde; en der er højere CPU, og en der er mere I/O bundet, og så en anstændig blanding af de to.
Du kan se fra grafen nedenfor, at på denne kørsel mod en S4-database steg CPU'en med næsten 50 %, mens DTU-procenten matchede nøjagtigt:
Ud fra de to forskellige arbejdsbelastninger, som jeg testede, er det meget tydeligt, at hvis du har nogen betydelig I/O-arbejdsbyrde, har du brug for Premium-niveauet, men hvis din arbejdsbyrde for det meste er CPU-bundet uden væsentlige I/O-behov, jo højere Standardniveauer kan give dig betydelige besparelser i forhold til Premium-niveauet.
Hvis du overvejer en migrering til en Azure SQL-database, er DTU-beregneren et godt sted at starte for at få en idé om et udgangspunkt for dimensionering; i skrivende stund tager DTU-beregneren dog ikke højde for det udvidede standardniveau. Det gode ved DTU-beregneren er, at den udbryder CPU, IOP'er og logbrug for at fortælle dig, hvad den drivende faktor for DTU-niveauanbefalingen er. For eksempel kørte jeg den sidste demo på en 4 vCPU, 4GB virtuel maskine, og DTU-beregneren anbefalede en P2. Da jeg valgte at 'se flere detaljer', fik jeg følgende beskeder.
Serviceniveau/ydelsesniveau for CPU – Baseret udelukkende på CPU-udnyttelse anbefaler vi, at du migrerer din SQL Server-arbejdsbelastning til Premium – P2. Dette serviceniveau/ydelsesniveau bør dække cirka 100,00 % af din CPU-udnyttelse.
Serviceniveau/ydelsesniveau for Iops – Baseret udelukkende på Iops-brug, anbefaler vi, at du migrerer din SQL Server-arbejdsbelastning til Basic. Dette serviceniveau/ydelsesniveau bør dække cirka 89,92 % af din Iops-udnyttelse.
BEMÆRK:Der er cirka 10,08 % af din arbejdsbyrde, der falder ind under et højere serviceniveau/ydelsesniveau. Efter at have migreret din database til Azure, bør du evaluere din databases ydeevne ved hjælp af vejledningen nævnt i informationsafsnittet ovenfor.
Serviceniveau/ydelsesniveau for log – Baseret udelukkende på logbrug, anbefaler vi, at du migrerer din SQL Server-arbejdsbelastning til Basic. Dette serviceniveau/ydelsesniveau bør dække cirka 100,00 % af din logudnyttelse.
Da jeg ved, at denne arbejdsbyrde er stærkt CPU-bundet, hvis jeg ikke kan justere arbejdsbyrden for at reducere CPU-kravet, har jeg op til 3.000 DTU'er tilgængelige i Standard-tier. I stedet for at bruge $930 pr. måned for en P2 med 250 DTU'er, ville en S4 med 200 DTU'er til $150 pr. måned (eller en S6 med 400 DTU'er til $300,02 pr. måned) være en meget mere økonomisk mulighed.
Afslutningsvis er der tilgængelige værktøjer til at hjælpe dig med at bestemme et godt udgangspunkt for størrelsen af dine Azure SQL Database-migreringer, men den absolut bedste metode er at teste din arbejdsbyrde. Migrering af en kopi af din produktionsdatabase, indfangning af en produktionsarbejdsbelastning og genafspilning af denne arbejdsbelastning mod Azure SQL-databasen vil give dig en meget bedre forståelse af, hvilken DTU-størrelse du virkelig har brug for.