Microsoft Azure udostępnia Aparat baz danych Platform as a Service (PaaS) za pośrednictwem platformy Azure SQL Database, dzięki czemu możemy używać tej bazy danych dla aplikacji opartych na chmurze. Główną zaletą Azure SQL Database jest umożliwienie łatwego skalowania przy zerowych przestojach i nie wymaga uaktualniania wersji ani procesu instalowania poprawek. Ponadto nie musimy się martwić problemami sprzętowymi.

Jednak istotnym zagadnieniem dotyczącym Azure SQL Database jest spełnienie wymagań dotyczących wydajności wdrożonej bazy danych przy minimalnych kosztach. Niewątpliwie nikt nie chce płacić za zbędne zasoby lub funkcje, których nie używa lub nie planuje używać.

W tym momencie Microsoft Azure oferuje dwa różne modele zakupów, aby zapewnić opłacalność:

• Model zakupów oparty na bazie danych transakcji (DTU).
• Model zakupów oparty na wirtualnym rdzeniu (vCore)

Decyzja dotycząca modelu zakupu ma bezpośredni wpływ na wydajność bazy danych i łączną kwotę rachunków. Moim zdaniem, jeśli wdrożona baza danych nie będzie zużywać zbyt wielu zasobów, bardziej odpowiedni będzie model zakupu oparty na jednostkach DTU.

Teraz omówimy szczegóły dotyczące tych dwóch modeli zakupów w kolejnych sekcjach.

Model zakupów oparty na jednostce transakcyjnej bazy danych (DTU)

Aby lepiej zrozumieć model zakupu oparty na jednostkach DTU, musimy wyjaśnić, co ma sens DTU w Azure SQL Database. DTU to skrót od „Jednostka transakcji bazy danych” i opisuje metrykę jednostki wydajności dla Azure SQL Database. Możemy po prostu polubić DTU do mocy w samochodzie, ponieważ ma to bezpośredni wpływ na wydajność bazy danych. Jednostka DTU reprezentuje mieszankę następujących metryk wydajności jako pojedynczą jednostkę wydajności dla Azure SQL Database:

• procesor
• Pamięć
• We/wy danych i we/wy dziennika

Główną ideą koncepcji DTU jest oferowanie klientom wstępnie skonfigurowanej konfiguracji zasobów, aby uprościć skalowanie wydajności na podstawie pojedynczej metryki. Na przykład, jeśli potrzebujemy większej wydajności, możemy przesunąć pasek i zwiększyć liczbę jednostek DTU w Azure SQL Database.

Model zakupu oparty na jednostkach DTU zawiera trzy różne warstwy usług, które oferują różne jednostki DTU i opcje funkcji. Poniższa tabela ilustruje warstwy usług, które brały udział w modelu zakupu opartym na jednostkach DTU.

Jak widać, maksymalne jednostki DTU i funkcje różnią się w zależności od ich warstwy usług. Ponadto model cenowy zostanie zmieniony w zależności od warstwy usług. Na przykład następująca konfiguracja dla pojedynczej bazy danych w modelu zakupów opartym na jednostkach DTU będzie wynosić 584,00 USD miesięcznie.

Elastyczny basen

Krótko mówiąc, Elastic Pool pomaga nam automatycznie zarządzać i skalować wiele baz danych, które mają nieprzewidywalne i zmienne zapotrzebowanie na zasoby w ramach udostępnionej puli zasobów. Dzięki elastycznej puli nie musimy stale skalować baz danych pod kątem wahań zapotrzebowania na zasoby. Bazy danych, które biorą udział w puli, zużywają zasoby puli elastycznej, gdy są potrzebne, ale nie mogą przekroczyć ograniczeń zasobów puli elastycznej, aby zapewnić opłacalne rozwiązanie.

Właściwe oszacowanie liczby jednostek DTU dla Azure SQL Database

Po podjęciu decyzji o zastosowaniu modelu zakupu opartego na DTU, musimy znaleźć następujące pytanie-odpowiedź z logicznych powodów:

• Która warstwa usług i ile jednostek DTU jest wymaganych dla mojego obciążenia podczas migracji do Azure SQL?

Kalkulator DTU będzie głównym rozwiązaniem do oszacowania wymagań dotyczących jednostek DTU podczas migracji lokalnych baz danych do Azure SQL Database. Główną ideą tego narzędzia jest przechwytywanie różnych metryk wykorzystania istniejących SQL Server, które wpływają na jednostki DTU, a następnie próba oszacowania przybliżonych jednostek DTU i warstwy usług w świetle zebranych zastosowań wydajności. Kalkulator DTU zbiera następujące metryki za pomocą narzędzia wiersza poleceń lub skryptu PowerShell i zapisuje te metryki w pliku CSV.

• Procesor — % czasu procesora
• Dysk logiczny — odczyty dysku/s
• Dysk logiczny — zapisy na dysku/s
• Baza danych — opróżnione bajty dziennika/s

W tym artykule nauczymy się korzystać z narzędzia wiersza poleceń, ponieważ jest to projekt i kody o otwartym kodzie źródłowym, które są hostowane na GitHub. Dzięki temu możemy łatwo wprowadzić zmiany, jeśli zajdzie taka potrzeba. Po pobraniu i rozpakowaniu narzędzia wiersza poleceń, przed nami pojawią się dwa pliki.

SqlDtuPerfmon.exe.config pomaga nam określić niektóre parametry narzędzia wiersza poleceń:

CsvPath określa ścieżkę pliku CSV, w której będą przechowywane zebrane dane.

SampleInterval określa, ile sekund będą pobierane próbki

MaxSamples określa maksymalną liczbę próbek, które zostaną zebrane.

W tym momencie musimy wziąć pod uwagę kilka uwag dotyczących Kalkulatora DTU. Kalkulator DTU zbiera całkowite wykorzystanie metryk na komputerze. Z tego powodu inne procesy, które wpływają na zużycie procesora, pamięci i dysku, muszą zostać zatrzymane, w przeciwnym razie trudno będzie dokładnie oszacować DTU. Inną kwestią jest, o ile to możliwe, zebranie wykorzystania metryk obejmujących okresy szczytowego obciążenia pracą. W ten sposób Kalkulator DTU oferuje najlepsze rekomendacje i określamy maksymalne wymagania dotyczące DTU z bardziej przybliżonym oszacowaniem. Teraz uruchomimy SqlDtuPerfmon.exe, który bezpośrednio zacznie zbierać wykorzystanie zasobów i zapisywać określony plik CSV.

Po zakończeniu zbierania informacji o wykorzystaniu zasobów, wprowadzimy liczbę rdzeni i prześlemy plik CSV na stronę internetową Kalkulatora DTU.

Po kliknięciu przycisku Oblicz najpierw na ekranie pojawia się wykres kołowy warstwy usług/poziomu wydajności, który przedstawia podzielone sugestie dotyczące szacowanej warstwy usług na wycinki ze szczegółami procentowymi. Według kalkulatora DTU warstwa Standard — S6 zapewni satysfakcjonującą wydajność w przypadku tego obciążenia.

Tuż pod tym wykresem pokazany jest wykres jednostek DTU w czasie, który przedstawia zmiany jednostek DTU w okresie. Przed oceną tego wykresu możemy dodać kilka dodatkowych informacji, aby łatwiej go zinterpretować.

Jak widać, wykres liniowy przedstawia niestabilne obciążenie pracą, ale miało to większy sens, gdy dodaliśmy notatki informacyjne. Moim zdaniem ten wykres jest bardzo przydatny do zrozumienia interakcji między zmianami obciążenia a jednostkami DTU. W ten sposób możemy dokładniej oszacować wymagane DTU. Jak wspomnieliśmy na początku artykułu, naszym głównym celem powinno być znalezienie opłacalnego rozwiązania dla obciążenia pracą.

Jednak te sugestie nie wyrażają dokładnych wymagań jednostki DTU w Azure SQL. Z tego powodu po wdrożeniu bazy danych w Azure SQL może być konieczna zmiana warstwy usług lub modelu zakupu.

Gdy klikniemy Wyświetl więcej szczegółów, zostaną wyświetlone dodatkowe raporty, które przedstawiają indywidualne zalecenia dotyczące wykorzystania zasobów procesora, IOPS i dziennika. Będą bardzo pomocne w zrozumieniu szczególnie tych zastosowań.

Model zakupów oparty na wirtualnym rdzeniu (vCore)

Ta koncepcja jest podobna do tradycyjnego podejścia, ponieważ jesteśmy w stanie decydować o każdym zasobie bazy danych. W tym modelu możemy ręcznie ustawić opcje rdzeni wirtualnych i maksymalnego rozmiaru danych. Nie możemy jednak określić zasobu pamięci. Każdy wirtualny rdzeń jest dostarczany z dedykowaną pamięcią, a dedykowana wartość pamięci zależy od generacji wirtualnych rdzeni.

Na koniec w tym modelu możemy wybrać następujące poziomy usług:

• Ogólny cel.
• Kluczowe znaczenie biznesowe.
• Hiperskala

Wniosek

W tym artykule omówiliśmy modele zakupu bazy danych Azure SQL i poznaliśmy instrukcje użytkowania kalkulatora DTU w celu oszacowania wymaganej liczby jednostek DTU w Azure SQL dla lokalnych baz danych.