Azure SQL Database ma obecnie trzy warstwy usług do wyboru dla obciążenia. Te warstwy składają się z Basic, Standard i Premium. Basic obsługuje tylko jeden rozmiar 5 jednostek DTU. Premium zaczyna się od 125 DTU i wzrasta do 4000 DTU. Warstwa Premium to najwyższa warstwa, która jest stworzona z myślą o wyższych obciążeniach we/wy i zapewnia mniejsze opóźnienia na we/wy oraz o rząd wielkości więcej IOPS na jednostkę DTU niż w warstwie Standardowa.
Przed sierpniem 2017 warstwa Standardowa obsługiwała tylko rozmiary jednostek DTU od 15 do 100 jednostek DTU. Obecnie w wersji zapoznawczej dostępne są nowe poziomy wydajności i dodatki pamięci masowej, które oferują korzyści w zakresie optymalizacji cen w przypadku obciążeń intensywnie korzystających z procesora. Dzięki temu warstwa Standardowa obsługuje teraz do 3000 jednostek DTU.
W tym momencie możesz zadać sobie pytanie, czym dokładnie jest DTU? DTU jest jednostką transakcji bazy danych i jest połączeniem procesora, pamięci oraz danych i logów transakcji we/wy. (Andy Mallon, @AMtwo, ostatnio odniósł się do tego w „Co do cholery to DTU?”) Możesz osiągnąć swój limit DTU, maksymalizując procesor, pamięć lub I/O.
Wcześniej warstwa Standardowa oferowała tylko 4 poziomy:15, 30, 50 i 100 jednostek DTU, z limitem rozmiaru bazy danych 250 GB, z dyskiem standardowym. Jeśli masz bazę danych, która jest większa niż 250 GB, ale nie potrzebujesz więcej niż 100 jednostek DTU dla procesora, pamięci lub operacji we/wy, utknąłeś w płaceniu ceny Premium tylko za rozmiar bazy danych. Dzięki nowym zmianom możesz teraz mieć do 1 TB bazy danych w warstwie Standardowa; wystarczy zapłacić za dodatkowe miejsce. Obecnie opłata za miejsce w wersji zapoznawczej wynosi 0,085 USD/GB. Zwiększenie z dołączonego rozmiaru 250 GB do 1 TB zwiększa się o 774 GB przy koszcie 65,79 USD miesięcznie.
Nowe standardowe rozmiary jednostek DTU w wersji zapoznawczej obsługują opcje 200, 400, 800, 1600 i 3000 jednostek DTU. Jeśli masz obciążenie bazy danych SQL Server, które jest bardziej związane z procesorem niż we/wy, te opcje warstwy Standardowa mogą potencjalnie zaoszczędzić dużo pieniędzy; Jeśli jednak obciążenie jest powiązane z operacjami we/wy, warstwa Premium będzie miała wyższą wydajność niż warstwa Standardowa.
Postanowiłem wypróbować dwa różne obciążenia, aby zobaczyć, jak różnią się między sobą warstwy Standardowa i Premium. Chciałem stworzyć prosty i powtarzalny test, aby inni mogli sami spróbować walidować. W moim pierwszym teście chciałem wygenerować zdrową mieszankę procesora i we/wy. Miałem nadzieję, że wykorzystam więcej procesora niż we/wy i będę w stanie wykazać, że rozszerzona warstwa Standardowa przewyższa warstwę Premium przy tym samym rozmiarze DTU. Nie uzyskałem dokładnie wyników, na które liczyłem.
Aby skonfigurować to demo, utworzyłem tabelę z trzema kolumnami GUID, wstawiłem milion wierszy, a następnie zaktualizowałem dwie z trzech kolumn o nowe identyfikatory. Przykładowy kod znajduje się poniżej:
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();
Gdy przeszedłem przez serię testów, wydajność stale się poprawiała w warstwie Standard, aż dotarłem do opcji S12, gdzie, co dziwne, zwiększył się procesor i upływający czas. Przeprowadziłem test wiele razy, a S12 konsekwentnie trwało 54 sekundy. W moim pierwszym teście jest całkiem jasne, że warstwa Premium przewyższała poziom Standard. Na przykład S9 i P2 są najbliższe w czasie, jednak rozmiar DTU dla Standard wynosi 1600 w porównaniu do 250 dla P2. Ten test dotyczy bardziej możliwości we/wy. Poniższy wykres pokazuje rozmiar, poziom DTU, koszt, czas procesora, czas, który upłynął i czas w sekundach dla każdego testu:
Podczas wykonywania testów zaobserwowałem na pulpicie monitora, że dane I/O i procent I/O dziennika były siłą napędową procentu DTU. Poniższy wykres pochodzi z testu z bazą danych S4:
Następnie zdecydowałem się na kolejną serię testów, które będą bardziej obciążać procesor. Do tego testu użyłem następującego skryptu:
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; To, co zaobserwowałem na desce rozdzielczej monitora w tej serii testów, jest takie, że procent procesora był jedynym czynnikiem wpływającym na procent DTU. Kiedy przechodziłem przez serię testów w warstwie Standard, test wydawał się ustabilizować po około 27 sekundach i zaczął się od rozmiaru S4. Wydało mi się dziwne, że ukończenie S4 przy 200 DTU zajęło 27 sekund, a odpowiedni P2 przy 250 DTU zajęło 38 sekund; P4 przy 500 DTU był bardziej porównywalny. Jeśli spojrzymy na różnicę w kosztach tego demo, S4 w wersji zapoznawczej kosztował tylko 150,01 USD, podczas gdy P4 kosztował 1860 USD; S4 zapewnia oszczędności w wysokości nieco ponad 1700 USD. Wyobraźmy sobie, że P2 w 250 DTU działał tak, jak się spodziewaliśmy; P2 kosztuje 930 USD i nadal kosztowałby 780 USD więcej niż S4.
Pełne wyniki wszystkich testów w drugim demo są zawarte w poniższej tabeli:
W przeciwieństwie do pierwszego demo, było to w 100% napędzane procesorem. Próbowałem dodać jedno dodatkowe połączenie krzyżowe, ale demo zajęło wtedy godziny na sesję zamiast minut. Na potrzeby przyszłego testu postaram się wymyślić kilka dodatkowych scenariuszy, które wymuszają bardziej realistyczne obciążenie OLTP; jeden, który ma wyższy procesor i taki, który jest bardziej związany z we/wy, a następnie przyzwoitą mieszankę tych dwóch.
Na poniższym wykresie widać, że podczas tego testu z bazą danych S4, procesor wzrósł o prawie 50%, podczas gdy procent DTU dokładnie się zgadzał:
Z dwóch różnych obciążeń, które przetestowałem, wyraźnie widać, że jeśli masz jakiekolwiek znaczące obciążenie we/wy, będziesz potrzebować warstwy Premium, ale jeśli Twoje obciążenie jest w większości związane z procesorem bez żadnych znaczących potrzeb we/wy, tym wyższy Warstwy Standard zapewniają znaczne oszczędności w porównaniu z warstwą Premium.
Jeśli rozważasz migrację do bazy danych SQL Azure, kalkulator jednostek DTU jest doskonałym miejscem, od którego możesz zacząć, aby uzyskać pomysł na punkt wyjścia do ustalania rozmiaru; jednak w chwili pisania tego kalkulatora DTU nie uwzględnia rozszerzonej warstwy Standard. Wspaniałą rzeczą w kalkulatorze DTU jest to, że rozkłada on procesor, procesory IOP i wykorzystanie dziennika, aby poinformować Cię, jaki jest czynnik napędzający zalecenie dotyczące poziomu DTU. Na przykład ostatnie demo uruchomiłem na 4 vCPU, 4 GB wirtualnej maszynie, a kalkulator DTU zalecił P2. Kiedy wybrałem „wyświetl więcej szczegółów”, otrzymałem następujące wiadomości.
Poziom usług/Poziom wydajności dla procesora — Opierając się wyłącznie na wykorzystaniu procesora, zalecamy migrację obciążenia programu SQL Server do wersji Premium — P2. Ten poziom usług/poziom wydajności powinien obejmować około 100,00% wykorzystania procesora.
Poziom usług/poziom wydajności dla operacji we/wy — w oparciu wyłącznie o wykorzystanie operacji we/wy zalecamy migrację obciążenia programu SQL Server do wersji Basic. Ten poziom usług/poziom wydajności powinien obejmować około 89,92% wykorzystania liczby operacji we/wy.
UWAGA:Około 10,08 % Twojego obciążenia przypada na wyższy poziom usług/poziom wydajności. Po migracji bazy danych na platformę Azure należy ocenić wydajność bazy danych, korzystając ze wskazówek wymienionych w powyższej sekcji informacji.
Poziom usług/Poziom wydajności dziennika — w oparciu wyłącznie o wykorzystanie dzienników zalecamy migrację obciążenia programu SQL Server do wersji Basic. Ten poziom usług/poziom wydajności powinien obejmować około 100,00% wykorzystania dziennika.
Ponieważ wiem, że to obciążenie jest mocno powiązane z procesorem, jeśli nie mogę dostroić obciążenia, aby zmniejszyć wymagania dotyczące procesora, mam do 3000 DTU dostępnych w warstwie Standard. Zamiast wydawać 930 USD miesięcznie na P2 z 250 DTU, S4 z 200 DTU za 150 USD miesięcznie (lub S6 z 400 DTU za 300,02 USD miesięcznie) byłby znacznie bardziej ekonomiczną opcją.
Podsumowując, dostępne są narzędzia, które pomogą Ci określić dobry punkt wyjścia dla rozmiaru migracji Azure SQL Database, jednak absolutnie najlepszą metodą jest przetestowanie obciążenia. Migracja kopii produkcyjnej bazy danych, przechwycenie obciążenia produkcyjnego i odtworzenie tego obciążenia w bazie danych Azure SQL Database pozwoli Ci znacznie lepiej zrozumieć, jakiego rozmiaru jednostki DTU naprawdę potrzebujesz.
