Azure SQL Database heeft momenteel drie servicelagen waaruit u kunt kiezen voor uw workload. Deze niveaus bestaan uit Basic, Standard en Premium. Basic ondersteunt slechts één grootte van 5 DTU's. Premium begint bij 125 DTU's en loopt op tot 4.000 DTU's. De Premium-laag is de bovenste laag die is gebouwd voor hogere I/O-workloads en een lagere latentie per I/O biedt, en een orde van grootte meer IOPS per DTU dan in de Standard-laag.
Vóór augustus 2017 ondersteunde de Standard-laag alleen DTU-grootten tussen 15 en 100 DTU's. Momenteel beschikbaar als preview-versie zijn nieuwe prestatieniveaus en opslag-add-ons die prijsoptimalisatievoordelen bieden voor CPU-intensieve workloads. Daarmee ondersteunt de Standard-laag nu maximaal 3.000 DTU's.
Op dit punt vraag je je misschien af wat een DTU precies is? Een DTU is een Database Transaction Unit en is een combinatie van CPU, geheugen en data en transactielog I/O. (Andy Mallon, @AMtwo, heeft dit onlangs besproken in "Wat is in vredesnaam een DTU?") U kunt uw DTU-limiet bereiken door CPU, geheugen of I/O te maximaliseren.
Voorheen bood de Standard-laag slechts 4 niveaus:15, 30, 50 en 100 DTU's, met een databaselimiet van 250 GB, met standaardschijf. Als u een database had die groter was dan 250 GB, maar niet meer dan 100 DTU's nodig had voor CPU, geheugen of I/O, moest u een Premium-prijs betalen alleen voor de databasegrootte. Met de nieuwe wijzigingen kunt u nu een database van maximaal 1 TB in de Standard-laag hebben; je hoeft alleen de extra opslagruimte te betalen. Momenteel wordt opslag tijdens de preview gefactureerd tegen $ 0,085/GB. Toenemend van de meegeleverde grootte van 250 GB naar 1 TB neemt toe met 774 GB tegen een kostprijs van $ 65,79 per maand.
De nieuwe standaard preview-DTU-formaten ondersteunen 200, 400, 800, 1600 en 3000 DTU-opties. Als u een SQL Server-databasewerkbelasting hebt die meer CPU-gebonden is dan I/O, kunnen deze Standard-tieropties u veel geld besparen; Als uw workload echter I/O-gebonden is, zal de Premium-laag beter presteren dan de Standard-laag.
Ik besloot om twee verschillende workloads uit te proberen om te zien hoe verschillend de Standard- en Premium-lagen van elkaar verschillen. Ik wilde een eenvoudige en reproduceerbare test maken, zodat anderen het voor zichzelf kunnen proberen te valideren. Voor mijn eerste test wilde ik een gezonde mix van CPU en I/O genereren. Ik hoopte dat ik meer CPU dan I/O zou pushen en zou kunnen aantonen dat de uitgebreide Standard-laag beter zou presteren dan een Premium-laag met dezelfde DTU-grootte. Ik kreeg niet precies de resultaten waar ik op hoopte.
Om deze demo in te stellen, heb ik een tabel met drie GUID-kolommen gemaakt, 1 miljoen rijen ingevoegd en vervolgens twee van de drie kolommen bijgewerkt met nieuwe ID's. De voorbeeldcode staat hieronder:
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();
Terwijl ik de reeks tests doorliep, verbeterden de prestaties gestaag in de Standard-laag totdat ik bij de S12-optie kwam waar, vreemd genoeg, de CPU en de verstreken tijd toenamen. Ik heb de test meerdere keren uitgevoerd en S12 was constant 54 seconden. Het is vrij duidelijk bij mijn eerste test dat het Premium-niveau beter presteerde dan het Standard-niveau. De S9 en P2 zijn bijvoorbeeld het dichtst in de tijd, maar de DTU-grootte voor Standard is 1.600 in vergelijking met 250 voor de P2. Deze test gaat meer over de I/O-mogelijkheden. De onderstaande grafiek toont de grootte, het DTU-niveau, de kosten, de CPU-tijd, de verstreken tijd en de tijd in seconden voor elke test:
Terwijl de tests werden uitgevoerd, zag ik in het monitordashboard dat data I/O en log I/O-percentage de drijvende kracht waren achter het DTU-percentage. De volgende grafiek was van een run tegen een S4-database:
Ik besloot toen om nog een reeks tests te proberen die meer CPU-zwaar zouden zijn. Voor die test heb ik het volgende script gebruikt:
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; Wat ik in het monitordashboard van deze reeks tests heb waargenomen, is dat het CPU-percentage de enige bestuurder was van het DTU-percentage. Toen ik de reeks tests in de Standard-laag doorliep, leek de test op ongeveer 27 seconden te stabiliseren en begon bij de S4-maat. Wat me vreemd opviel, is dat een S4 bij 200 DTU 27 seconden nodig had om te voltooien en de bijbehorende P2 bij 250 DTU 38 seconden; een P4 bij 500 DTU was beter vergelijkbaar. Als we kijken naar het kostenverschil voor deze demo, kostte een S4 tijdens de preview slechts $ 150,01, terwijl een P4 $ 1.860 kostte; de S4 biedt een kostenbesparing van iets meer dan $ 1.700. Laten we ons voorstellen dat een P2 met 250 DTU's presteerde zoals we hadden verwacht; een P2 kost $ 930 en zou nog steeds $ 780 meer kosten dan een S4.
De volledige resultaten van alle tests in de tweede demo zijn opgenomen in de volgende tabel:
In tegenstelling tot de eerste demo was deze 100% CPU-gestuurd. Ik had geprobeerd een extra cross-join toe te voegen, maar de demo nam toen uren per sessie in plaats van minuten. Voor een toekomstige test zal ik proberen een paar extra scenario's te bedenken die een meer realistische OLTP-werklast pushen; een met een hogere CPU en een die meer I / O-gebonden is, en dan een behoorlijke mix van beide.
U kunt in de onderstaande grafiek zien dat de CPU tijdens deze run tegen een S4-database piekte met bijna 50%, terwijl het DTU-percentage exact overeenkwam:
Uit de twee verschillende workloads die ik heb getest, is het heel duidelijk dat als je een significante I/O-workload hebt, je de Premium-laag nodig hebt, maar als je workload grotendeels CPU-gebonden is zonder significante I/O-behoeften, hoe hoger Standaardlagen kunnen u aanzienlijke besparingen opleveren ten opzichte van de Premium-laag.
Als u een migratie naar een Azure SQL Database overweegt, is de DTU-calculator een geweldige plek om een idee te krijgen van een startpunt voor de dimensionering; op het moment van schrijven houdt de DTU-calculator echter geen rekening met de uitgebreide Standard-laag. Het mooie van de DTU-calculator is dat het CPU, IOP's en loggebruik zal doorbreken om u te laten weten wat de drijvende factor is voor de aanbeveling op DTU-niveau. Ik heb bijvoorbeeld de laatste demo uitgevoerd op een 4 vCPU, 4 GB virtuele machine, en de DTU-calculator raadde een P2 aan. Toen ik ervoor koos om 'meer details te bekijken', kreeg ik de volgende berichten.
Serviceniveau/prestatieniveau voor CPU – Uitsluitend gebaseerd op CPU-gebruik, raden we u aan uw SQL Server-workload te migreren naar Premium – P2. Dit serviceniveau/prestatieniveau zou ongeveer 100,00% van uw CPU-gebruik moeten dekken.
Serviceniveau/prestatieniveau voor Iops :uitsluitend gebaseerd op Iops-gebruik, raden we u aan uw SQL Server-workload naar Basic te migreren. Dit serviceniveau/prestatieniveau moet ongeveer 89,92 % van uw Iops-gebruik dekken.
OPMERKING:ongeveer 10,08 % van uw werklast valt in een hoger serviceniveau/prestatieniveau. Nadat u uw database naar Azure heeft gemigreerd, moet u de prestaties van uw database evalueren met behulp van de richtlijnen die worden vermeld in de informatiesectie hierboven.
Serviceniveau/prestatieniveau voor logboek :uitsluitend gebaseerd op het gebruik van logboeken, raden we u aan uw SQL Server-workload naar Basic te migreren. Dit serviceniveau/prestatieniveau moet ongeveer 100,00% van uw loggebruik dekken.
Aangezien ik weet dat deze workload zwaar CPU-gebonden is, heb ik tot 3.000 DTU's beschikbaar in de Standard-laag als ik de workload niet kan afstemmen om de CPU-vereiste te verminderen. In plaats van $ 930 per maand uit te geven voor een P2 met 250 DTU's, zou een S4 met 200 DTU's voor $ 150 per maand (of een S6 met 400 DTU's voor $ 300,02 per maand) een veel voordeligere optie zijn.
Kortom, er zijn tools beschikbaar om u te helpen een goed startpunt te bepalen voor de grootte van uw Azure SQL Database-migraties, maar de absoluut beste methode is om uw workload te testen. Door een kopie van uw productiedatabase te migreren, een productieworkload vast te leggen en die workload opnieuw af te spelen met de Azure SQL Database, krijgt u een veel beter inzicht in de DTU-grootte die u echt nodig heeft.