Nové standardní velikosti vrstev Azure SQL Database

Azure SQL Database má aktuálně tři úrovně služeb, ze kterých si můžete vybrat pro svou pracovní zátěž. Tyto úrovně se skládají z Basic, Standard a Premium. Základní podporuje pouze jednu velikost 5 DTU. Premium začíná na 125 DTU a dosahuje až 4 000 DTU. Úroveň Premium je nejvyšší úrovní, která je vytvořena pro vyšší I/O pracovní zátěž a poskytuje nižší latenci na I/O a řádově více IOPS na DTU než úroveň Standard.

Před srpnem 2017 podporovala úroveň Standard pouze velikosti DTU mezi 15 a 100 DTU. V současné době jsou k dispozici ve verzi Preview nové úrovně výkonu a doplňky úložiště, které nabízejí výhody optimalizace ceny pro zátěže náročné na CPU. S těmi nyní úroveň Standard podporuje až 3 000 DTU.

V tuto chvíli se možná ptáte sami sebe, co přesně je DTU? DTU je databázová transakční jednotka a je směsí CPU, paměti a dat a I/O protokolu transakcí. (Andy Mallon, @AMtwo, to nedávno řešil v „Co to sakra je DTU?“) Limit DTU můžete dosáhnout maximálním vyčerpáním CPU, paměti nebo I/O.

Dříve vrstva Standard nabízela pouze 4 úrovně:15, 30, 50 a 100 DTU s limitem velikosti databáze 250 GB se standardním diskem. Pokud jste měli databázi větší než 250 GB, ale nepotřebovali jste více než 100 DTU pro CPU, paměť nebo I/O, museli jste platit prémiovou cenu jen za velikost databáze. S novými změnami nyní můžete mít až 1TB databázi v úrovni Standard; jen musíte zaplatit dodatečné úložiště. V současné době je úložiště během náhledu účtováno za 0,085 $/GB. Navýšením z 250 GB na 1 TB se zvětší o 774 GB za cenu 65,79 $ měsíčně.

Nové standardní velikosti náhledu DTU podporují 200, 400, 800, 1 600 a 3 000 možností DTU. Pokud máte databázovou zátěž SQL Server, která je více vázána na CPU než I/O, tyto možnosti standardní úrovně vám mohou ušetřit spoustu peněz; pokud je však vaše pracovní zátěž vázána na vstup/výstup, úroveň Premium překoná úroveň Standard.

Rozhodl jsem se vyzkoušet dvě různá pracovní zatížení, abych zjistil, jak se liší úrovně Standard a Premium ve srovnání s ostatními. Chtěl jsem vytvořit jednoduchý a reprodukovatelný test, aby se ostatní mohli sami pokusit ověřit. Pro svůj první test jsem chtěl vytvořit zdravou kombinaci CPU a I/O. Doufal jsem, že budu tlačit více CPU než I/O a budu schopen ukázat, že rozšířená úroveň Standard překoná prémiovou úroveň se stejnou velikostí DTU. Nedostal jsem přesně výsledky, ve které jsem doufal.

Pro nastavení této ukázky jsem vytvořil tabulku se třemi sloupci GUID, vložil 1 milion řádků a poté aktualizoval dva ze tří sloupců novými ID. Ukázkový kód je níže:

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();

Jak jsem procházel sérií testů, výkon se ve standardní vrstvě neustále zlepšoval, dokud jsem se nedostal k možnosti S12, kde se kupodivu zvýšil CPU a uplynulý čas. Test jsem provedl několikrát a S12 trvalo 54 sekund. S mým prvním testem je docela jasné, že úroveň Premium překonala úroveň Standard. Například S9 a P2 jsou si časově nejblíže, nicméně velikost DTU pro Standard je 1 600 ve srovnání s 250 pro P2. Tento test je spíše o schopnostech I/O. Níže uvedený graf ukazuje velikost, úroveň DTU, cenu, CPU, uplynulý čas a čas v sekundách pro každý test:

Během provádění testů jsem na řídicím panelu monitoru pozoroval, že procento datových I/O a log I/O byly hnací silou procenta DTU. Následující graf byl z běhu proti databázi S4:

Poté jsem se rozhodl vyzkoušet další sérii testů, které by byly náročnější na CPU. Pro tento test jsem použil následující 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;

V této sérii testů jsem na řídicím panelu monitoru pozoroval, že procento CPU bylo jediným ovladačem procenta DTU. Když jsem procházel sérií testů na úrovni Standard, zdálo se, že test se ustálil zhruba za 27 sekund a začal na velikosti S4. Přišlo mi zvláštní, že dokončení S4 při 200 DTU trvalo 27 sekund a odpovídající P2 při 250 DTU trvalo 38 sekund; P4 na 500 DTU byl srovnatelnější. Pokud se podíváme na rozdíl v ceně tohoto dema, S4 během náhledu stojí pouze 150,01 $, zatímco P4 stojí 1 860 $; S4 poskytuje úsporu nákladů jen něco málo přes 1 700 $. Představme si, že P2 na 250 DTU fungoval tak, jak jsme očekávali; P2 stojí 930 $ a stále by stál o 780 $ více než S4.

Úplné výsledky všech testů ve druhém demu jsou uvedeny v následující tabulce:

Na rozdíl od prvního dema bylo toto 100% řízeno CPU. Zkoušel jsem zahrnout ještě jedno další křížové spojení, ale demo pak trvalo hodiny na relaci místo minut. Pro budoucí test se pokusím vymyslet několik dalších scénářů, které posouvají realističtější zátěž OLTP; jeden, který má vyšší CPU, a jeden, který je více vázán na I/O, a pak slušná kombinace obou.

Z grafu níže můžete vidět, že při tomto běhu s databází S4 vzrostl CPU téměř o 50 %, zatímco procento DTU přesně odpovídalo:

Ze dvou různých zátěží, které jsem testoval, je velmi zřejmé, že pokud máte nějaké významné I/O zátěže, budete potřebovat úroveň Premium, ale pokud je vaše zátěž většinou vázána na CPU bez jakýchkoli významných I/O potřeb, tím vyšší Standardní úrovně vám mohou poskytnout značné úspory oproti úrovni Premium.

Pokud zvažujete migraci na Azure SQL Database, kalkulačka DTU je skvělým místem, kde začít, abyste získali představu o výchozím bodu pro dimenzování; v době psaní tohoto článku však kalkulačka DTU nebere v úvahu rozšířenou úroveň Standard. Na kalkulátoru DTU je skvělé to, že prolomí využití CPU, IOP a protokolu, abyste věděli, jaký je hnací faktor pro doporučení úrovně DTU. Například jsem spustil poslední demo na virtuálním stroji 4 vCPU, 4 GB a kalkulačka DTU doporučila P2. Když jsem zvolil možnost ‚zobrazit další podrobnosti‘, zobrazily se mi následující zprávy.

Úroveň služeb/úroveň výkonu pro CPU – Pouze na základě využití CPU vám doporučujeme migrovat zátěž SQL Serveru na Premium – P2. Tato úroveň služeb/úroveň výkonu by měla pokrývat přibližně 100,00 % využití vašeho CPU.

Úroveň služeb/úroveň výkonu pro Iops – Pouze na základě využití Iops doporučujeme migrovat zátěž SQL Serveru na základní. Tato úroveň služeb/úroveň výkonu by měla pokrývat přibližně 89,92 % vašeho využití Iops.

POZNÁMKA:Přibližně 10,08 % vaší pracovní zátěže spadá do vyšší úrovně služeb/úrovně výkonu. Po migraci databáze do Azure byste měli vyhodnotit výkon databáze pomocí pokynů uvedených v části s informacemi výše.

Úroveň služeb/úroveň výkonu pro protokol – Pouze na základě využití protokolu vám doporučujeme migrovat zátěž SQL Serveru na základní. Tato úroveň služeb/úroveň výkonu by měla pokrývat přibližně 100,00 % využití vašeho protokolu.

Protože vím, že toto zatížení je silně vázáno na CPU, pokud nemohu vyladit zatížení tak, aby se snížily požadavky na CPU, mám k dispozici až 3 000 DTU ve standardní úrovni. Než utratit 930 $ měsíčně za P2 s 250 DTU, S4 s 200 DTU za 150 $ měsíčně (nebo S6 se 400 DTU za 300,02 $ měsíčně) by byla mnohem ekonomičtější varianta.

Na závěr jsou k dispozici nástroje, které vám pomohou určit dobrý výchozí bod pro velikost migrací Azure SQL Database, ale absolutně nejlepší metodou je otestovat vaši zátěž. Migrace kopie vaší produkční databáze, zachycení produkčního vytížení a přehrání tohoto pracovního vytížení s Azure SQL Database vám umožní mnohem lépe pochopit, jakou velikost DTU skutečně potřebujete.