Azure SQL Database har för närvarande tre tjänstenivåer att välja mellan för din arbetsbelastning. Dessa nivåer består av Basic, Standard och Premium. Basic stöder endast en storlek på 5 DTU:er. Premium börjar på 125 DTU och går upp till 4 000 DTU. Premium-nivån är den översta nivån som är byggd för högre I/O-arbetsbelastningar och ger lägre latens per I/O och en storleksordning mer IOPS per DTU än i standardnivån.
Före augusti 2017 stödde standardnivån endast DTU-storlekar mellan 15 och 100 DTU:er. För närvarande tillgängliga i förhandsgranskning är nya prestandanivåer och lagringstillägg som erbjuder prisoptimeringsfördelar för CPU-intensiva arbetsbelastningar. Med dessa stöder nu standardnivån upp till 3 000 DTU:er.
Vid det här laget kanske du frågar dig själv vad, exakt, är en DTU? En DTU är en Databas Transaction Unit och är en blandning av CPU, minne och data och transaktionslogg I/O. (Andy Mallon, @AMtwo, tog nyligen upp detta i "Vad fan är en DTU?") Du kan nå din DTU-gräns genom att maxa ut CPU, minne eller I/O.
Tidigare erbjöd standardnivån bara 4 nivåer:15, 30, 50 och 100 DTU:er, med en databasstorleksgräns på 250 GB, med standarddisk. Om du hade en databas som var större än 250 GB, men inte behövde mer än 100 DTU:er för CPU, minne eller I/O, fick du betala ett premiumpris bara för databasstorleken. Med de nya ändringarna kan du nu ha upp till en 1TB databas i standardnivån; du behöver bara betala det extra lagringsutrymmet. För närvarande faktureras lagringsutrymmet med $0,085/GB under förhandsvisningen. Att öka från den inkluderade storleken på 250 GB till 1 TB ökar med 774 GB till en kostnad av 65,79 USD per månad.
De nya standardstorlekarna för förhandsvisning av DTU stöder 200, 400, 800, 1 600 och 3 000 DTU-alternativ. Om du har en SQL Server-databas arbetsbelastning som är mer CPU-bunden än I/O, har dessa standardnivåalternativ potential att spara mycket pengar. Men om din arbetsbelastning är I/O-bunden, kommer Premium-nivån att överträffa standardnivån.
Jag bestämde mig för att prova två olika arbetsbelastningar för att se hur olika standard- och premiumnivåerna är jämfört med varandra. Jag ville skapa ett enkelt och reproducerbart test så att andra kan försöka validera själva. För mitt första test ville jag skapa en hälsosam blandning av CPU och I/O. Jag hoppades att jag skulle pressa mer CPU än I/O och kunna visa att den utökade standardnivån skulle överträffa en Premium-nivå med samma DTU-storlek. Jag fick inte riktigt de resultat jag hoppades på.
För att ställa in denna demo skapade jag en tabell med tre GUID-kolumner, infogade 1 miljon rader och uppdaterade sedan två av de tre kolumnerna med nya ID:n. Exempelkoden är nedan:
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();
När jag gick igenom testserien förbättrades prestanda stadigt i standardnivån tills jag kom till S12-alternativet där, konstigt nog, CPU och förfluten tid ökade. Jag körde testet flera gånger och S12 var konsekvent 54 sekunder. Det är ganska tydligt med mitt första test, att Premium-nivån överträffade Standard-nivån. Till exempel är S9 och P2 närmast i tiden, men DTU-storleken för Standard är 1 600 jämfört med 250 för P2. Det här testet handlar mer om I/O-funktionerna. Diagrammet nedan visar storlek, DTU-nivå, kostnad, CPU-tid, förfluten tid och tid i sekunder för varje test:
När testerna utfördes, observerade jag i monitorns instrumentpanel att data I/O och log I/O-procent var drivkraften bakom DTU-procenten. Följande diagram var från en körning mot en S4-databas:
Jag bestämde mig då för att prova en annan serie tester som skulle vara mer CPU-tunga. För det testet använde jag följande skript:
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; Vad jag observerade i monitorns instrumentpanel i denna serie av tester är att CPU-procenten var den enda drivkraften för DTU-procenten. När jag gick igenom serien av tester i standardnivån verkade testet ha en platå vid ungefär 27 sekunder och började i storleken S4. Det som slog mig som konstigt är att en S4 vid 200 DTU tog 27 sekunder att slutföra och motsvarande P2 vid 250 DTU tog 38 sekunder; en P4 vid 500 DTU var mer jämförbar. Om vi tittar på kostnadsskillnaden för denna demo så kostade en S4 under förhandsgranskning bara $150,01, medan en P4 kostade $1 860; S4 ger en kostnadsbesparing på drygt 1 700 dollar. Låt oss föreställa oss att en P2 vid 250 DTU:er fungerade som vi hade förväntat oss; en P2 kostar $930 och skulle fortfarande kosta $780 mer än en S4.
De fullständiga resultaten av alla tester i den andra demon finns i följande diagram:
Till skillnad från den första demon var detta 100% CPU-drivet. Jag hade försökt inkludera ytterligare en korskoppling, men demon tog sedan timmar per session istället för minuter. För ett framtida test ska jag försöka komma med några ytterligare scenarier som driver en mer realistisk OLTP-arbetsbelastning; en som är högre CPU, och en som är mer I/O-bunden, och sedan en anständig blandning av de två.
Du kan se från diagrammet nedan att, vid denna körning mot en S4-databas, ökade CPU:n med nästan 50 %, medan DTU-procenten matchade exakt:
Från de två olika arbetsbelastningarna som jag testade är det mycket uppenbart att om du har någon betydande I/O-arbetsbelastning kommer du att behöva Premium-nivån, men om din arbetsbelastning mestadels är CPU-bunden utan några betydande I/O-behov, desto högre Standardnivåer kan ge dig avsevärda besparingar jämfört med Premium-nivån.
Om du funderar på en migrering till en Azure SQL-databas är DTU-kalkylatorn ett bra ställe att börja för att få en uppfattning om en utgångspunkt för storleksanpassning; Men i skrivande stund tar DTU-kalkylatorn inte hänsyn till den utökade standardnivån. Det som är bra med DTU-kalkylatorn är att den kommer att bryta ut CPU, IOP:er och logganvändning för att låta dig veta vad den drivande faktorn för rekommendationen på DTU-nivån är. Till exempel körde jag den senaste demon på en 4 vCPU, 4 GB virtuell maskin, och DTU-kalkylatorn rekommenderade en P2. När jag valde att "visa fler detaljer" fick jag följande meddelanden.
Servicenivå/prestandanivå för CPU – Baserat enbart på CPU-användning rekommenderar vi att du migrerar din SQL Server-arbetsbelastning till Premium – P2. Denna servicenivå/prestandanivå bör täcka cirka 100,00 % av din CPU-användning.
Servicenivå/prestandanivå för Iops – Baserat enbart på Iops-användning rekommenderar vi att du migrerar din SQL Server-arbetsbelastning till Basic. Denna tjänstenivå/prestandanivå bör täcka cirka 89,92 % av din Iops-användning.
OBS:Det är ungefär 10,08 % av din arbetsbelastning som faller in på en högre servicenivå/prestandanivå. Efter att ha migrerat din databas till Azure bör du utvärdera din databas prestanda med hjälp av vägledningen som nämns i informationsavsnittet ovan.
Servicenivå/prestandanivå för logg – Baserat enbart på logganvändning rekommenderar vi att du migrerar din SQL Server-arbetsbelastning till Basic. Denna tjänstenivå/prestandanivå bör täcka cirka 100,00 % av din logganvändning.
Eftersom jag vet att denna arbetsbelastning är starkt CPU-bunden, om jag inte kan justera arbetsbelastningen för att minska CPU-kravet, har jag upp till 3 000 DTU:er tillgängliga i standardnivån. Istället för att spendera 930 USD per månad för en P2 med 250 DTU:er skulle en S4 med 200 DTU:er för 150 USD per månad (eller en S6 med 400 DTU:er för 300,02 USD per månad) vara ett mycket mer ekonomiskt alternativ.
Sammanfattningsvis finns det tillgängliga verktyg som hjälper dig att fastställa en bra utgångspunkt för storleken på dina Azure SQL Database-migreringar, men den absolut bästa metoden är att testa din arbetsbelastning. Att migrera en kopia av din produktionsdatabas, fånga en produktionsbelastning och spela upp den arbetsbelastningen mot Azure SQL Database ger dig en mycket bättre förståelse för vilken DTU-storlek du verkligen behöver.