Przegląd modelu zakupowego opartego na jednostkach DTU
Dotyczy:
Azure SQL Database
Ten artykuł zawiera omówienie modelu zakupów opartego na jednostkach DTU dla usługi Azure SQL Database. Model zakupów oparty na jednostkach DTU jest prostą, zintegrowaną miarą zasobów obliczeniowych, przechowywania i operacji wejścia/wyjścia. Najlepiej nadaje się dla większości klientów z typowymi obciążeniami. Model zakupów oparty na jednostkach DTU jest dostępny w warstwach usług Podstawowa, Standardowa i Premium. Model zakupów oparty na jednostkach DTU jest również dostępny dla elastycznych pul.
Model zakupów oparty na jednostkach DTU różni się od modelu zakupów opartego na rdzeniach wirtualnych, więc można porównać modele zakupów.
Jednostki transakcji bazy danych (DTU)
Jednostka transakcji bazy danych (DTU) reprezentuje połączoną miarę procesora, pamięci, odczytów i zapisów. Poziomy usług w modelu zakupowym opartym na jednostkach DTU są rozróżniane przez szereg rozmiarów obliczeniowych ze stałą ilością dołączonej przestrzeni magazynowej, stały okres przechowywania kopii zapasowych i stałą cenę. Wszystkie warstwy usług w modelu zakupów opartym na jednostkach DTU zapewniają elastyczność zmiany rozmiarów obliczeniowych przy minimalnych przestojach. Istnieje jednak okres przełączenia, w którym łączność z bazą danych jest tracona na krótki czas, co można zminimalizować przy użyciu logiki ponawiania prób. Opłaty za pojedyncze bazy danych i pule elastyczne są naliczane co godzinę na podstawie warstwy usług i rozmiaru obliczeniowego.
W przypadku pojedynczej bazy danych o określonym rozmiarze obliczeniowym w warstwie usługi usługa Azure SQL Database gwarantuje określony poziom zasobów dla tej bazy danych (niezależnie od każdej innej bazy danych). Ta gwarancja zapewnia przewidywalny poziom wydajności. Ilość zasobów przydzielonych dla bazy danych jest obliczana jako liczba jednostek DTU i jest w pakiecie miarą zasobów obliczeniowych, magazynowych i we/wy.
Stosunek między tymi zasobami jest pierwotnie określany przez obciążenie porównawcze przetwarzania transakcji online (OLTP), które ma być typowe dla rzeczywistych obciążeń OLTP. Gdy obciążenie przekracza ilość dowolnego z tych zasobów, przepływność jest ograniczana, co skutkuje wolniejszymi wydajnościami i limitami czasu.
W przypadku pojedynczych baz danych zasoby używane przez obciążenie nie mają wpływu na zasoby dostępne dla innych baz danych w chmurze platformy Azure. Podobnie zasoby używane przez inne obciążenia nie mają wpływu na zasoby dostępne dla bazy danych.
Jednostki DTU są najbardziej przydatne do zrozumienia względnych zasobów przydzielonych dla baz danych o różnych rozmiarach obliczeniowych i warstwach usług. Na przykład:
- Podwojenie jednostek DTU przez zwiększenie rozmiaru obliczeniowego bazy danych oznacza podwojenie zestawu zasobów dostępnych dla tej bazy danych.
- Baza danych P11 w warstwie Premium z 1750 jednostkami DTU zapewnia 350 razy większą moc obliczeniową jednostek DTU niż podstawowa baza danych warstwy usług z 5 jednostkami DTU.
Aby uzyskać lepszy wgląd w zużycie zasobów (DTU) przez obciążenie, użyj wglądu w wydajność zapytań, aby:
- Zidentyfikuj najważniejsze zapytania według zużycia CPU, czasu trwania i liczby wykonań, które mogą być potencjalnie dostrojone w celu zwiększenia wydajności. Na przykład zapytanie intensywnie korzystające z operacji we/wy może skorzystać z technik optymalizacji w pamięci, aby lepiej wykorzystać dostępną pamięć w określonej warstwie usługi i rozmiarze obliczeniowym.
- Przejdź do szczegółów zapytania, aby wyświetlić jego tekst i historię użycia zasobów.
- Wyświetlanie zaleceń dotyczących dostrajania wydajności, które pokazują akcje podejmowane przez usługę Database Advisor.
Elastyczne jednostki transakcji bazy danych (eDTU)
Zamiast udostępniać dedykowany zestaw zasobów (DTU), który może nie zawsze być potrzebny, można umieścić te bazy danych w elastycznej puli. Bazy danych w elastycznej puli używają jednego wystąpienia silnika bazy danych i współdzielą wspólną pulę zasobów.
Udostępnione zasoby w elastycznej puli są mierzone przez elastyczne jednostki transakcji bazy danych (eDTU). Elastyczne pule zapewniają proste, ekonomiczne rozwiązanie do zarządzania celami wydajności dla wielu baz danych, które mają znacznie różne i nieprzewidywalne wzorce użycia. Elastyczna pula gwarantuje, że wszystkie zasoby nie mogą być używane przez jedną bazę danych w puli, zapewniając jednocześnie, że każda baza danych w puli zawsze ma minimalną ilość niezbędnych zasobów.
Pula ma ustaloną liczbę jednostek eDTU dla określonej ceny. W elastycznej puli poszczególne bazy danych mogą automatycznie skalować w skonfigurowanych granicach. Baza danych w większym obciążeniu zużywa więcej jednostek eDTU, aby zaspokoić zapotrzebowanie. Bazy danych w przypadku mniejszych obciążeń zużywają mniej jednostek eDTU. Bazy danych bez obciążenia nie zużywają jednostek eDTU. Ponieważ zasoby są aprowidowane dla całej puli, a nie dla bazy danych, elastyczne pule upraszczają zadania zarządzania i zapewniają przewidywalny budżet dla puli.
Możesz dodać więcej jednostek eDTU do istniejącej puli z minimalnym przestojem bazy danych. Podobnie, jeśli nie potrzebujesz już dodatkowych jednostek eDTU, usuń je z istniejącej puli w dowolnym momencie. Można również dodawać bazy danych do puli lub usuwać je z puli w dowolnym momencie. Aby zarezerwować jednostki eDTU dla innych baz danych, ogranicz liczbę eDTU, które mogą być używane przez bazy danych w przypadku dużego obciążenia. Jeśli baza danych ma stale wysokie wykorzystanie zasobów, które ma wpływ na inne bazy danych w puli, przenieś ją z puli i skonfiguruj jako pojedynczą bazę danych z przewidywalną ilością wymaganych zasobów.
Obciążenia, które korzystają z elastycznej puli zasobów
Pule są odpowiednie dla baz danych z niską średnią wykorzystania zasobów i stosunkowo rzadkimi skokami w ich wykorzystaniu. Aby uzyskać więcej informacji, zobacz Elastic pools in Azure SQL Database (Pule elastyczne w usłudze Azure SQL Database)
Określanie liczby jednostek DTU wymaganych przez obciążenie
Jeśli chcesz przeprowadzić migrację istniejącego obciążenia lokalnego lub maszyny wirtualnej programu SQL Server do usługi SQL Database, zobacz zalecenia dotyczące SKU, aby oszacować wymaganą liczbę jednostek DTU. W przypadku istniejącego obciążenia usługi SQL Database użyj szczegółowych informacji o wydajności zapytań, aby zrozumieć użycie zasobów bazy danych (DTU) i uzyskać bardziej szczegółowe informacje na temat optymalizowania obciążenia. Dynamiczny widok zarządzania (DMV) sys.dm_db_resource_stats umożliwia wyświetlanie zużycia zasobów w ciągu ostatniej godziny. Widok wykazu sys.resource_stats wyświetla zużycie zasobów w ciągu ostatnich 14 dni, ale przy niższej wierności średnich pięciu minut.
Określanie wykorzystania DTU
Aby określić średni procent użycia jednostek DTU/eDTU względem limitu jednostek DTU/eDTU bazy danych lub elastycznej puli, użyj następującej formuły:
avg_dtu_percent = MAX(avg_cpu_percent, avg_data_io_percent, avg_log_write_percent)
Wartości wejściowe dla tej formuły można uzyskać z widoków DMV sys.dm_db_resource_stats, sys.resource_stats i sys.elastic_pool_resource_stats. Innymi słowy, aby określić procent zużycia DTU/eDTU w stosunku do limitu DTU/eDTU bazy danych lub elastycznej puli, wybierz największą wartość procentową z następujących: avg_cpu_percent, avg_data_io_percent i avg_log_write_percent w danym momencie.
Uwaga
Limit DTU bazy danych jest określany przez CPU, odczyty, zapisy i pamięć dostępne dla bazy danych. Jednak ze względu na to, że aparat usługi SQL Database zwykle używa całej dostępnej pamięci podręcznej danych w celu zwiększenia wydajności, avg_memory_usage_percent wartość zwykle będzie zbliżona do 100 procent, niezależnie od bieżącego obciążenia bazy danych. W związku z tym, mimo że pamięć pośrednio wpływa na limit jednostek DTU, nie jest używana w formule wykorzystania jednostek DTU.
Konfiguracja sprzętu
W modelu zakupów opartym na jednostkach DTU klienci nie mogą wybrać konfiguracji sprzętowej używanej dla baz danych. Chociaż dana baza danych zwykle pozostaje na określonym typie sprzętu przez długi czas (często przez wiele miesięcy), istnieją pewne zdarzenia, które mogą spowodować przeniesienie bazy danych do innego sprzętu.
Na przykład bazę danych można przenieść do innego sprzętu, jeśli jest skalowana w górę lub w dół do innego celu usługi, lub jeśli bieżąca infrastruktura w centrum danych zbliża się do limitów pojemności, lub jeśli obecnie używany sprzęt jest likwidowany ze względu na jego koniec życia.
Jeśli baza danych zostanie przeniesiona na inny sprzęt, wydajność obciążenia może ulec zmianie. Model DTU gwarantuje, że przepływność i czas odpowiedzi obciążenia porównawczego DTU pozostaną praktycznie identyczne, pod warunkiem, że baza danych jest przenoszona na inny typ sprzętu i cel usługi (liczba jednostek DTU) pozostaje taki sam.
Jednak w szerokim spektrum obciążeń klientów działających w usłudze Azure SQL Database wpływ użycia innego sprzętu dla tego samego celu usługi może być bardziej wyraźny. Różne obciążenia mogą korzystać z różnych konfiguracji i funkcji sprzętowych. W związku z tym, w przypadku obciążeń innych niż benchmark DTU, można zauważyć różnice w wydajności, jeśli baza danych zostanie przeniesiona z jednego typu sprzętu na inny.
Klienci mogą użyć modelu vCore, aby wybrać preferowaną konfigurację sprzętową podczas tworzenia i skalowania bazy danych. W modelu rdzeni wirtualnych szczegółowe limity zasobów każdego celu usługi w każdej konfiguracji sprzętu są udokumentowane dla pojedynczych baz danych i pul elastycznych. Aby uzyskać więcej informacji, zobacz Konfiguracja sprzętu.
Porównanie warstw usług
Uwaga
Możesz uzyskać bezpłatną bazę danych w Azure SQL Database na poziomie usługi Podstawowa, korzystając z bezpłatnego konta platformy Azure. Aby uzyskać informacje, zobacz Tworzenie zarządzanej bazy danych w chmurze przy użyciu bezpłatnego konta platformy Azure.
Wybór warstwy usługi zależy przede wszystkim od wymagań dotyczących ciągłości działania, magazynu i wydajności.
| Podstawowa | Standard | Wysokiej jakości | |
|---|---|---|---|
| Obciążenie docelowe | Rozwój i produkcja | Rozwój i produkcja | Rozwój i produkcja |
| Umowa SLA dotycząca czasu dostępności | 99,99% | 99,99% | 99,99% |
| Tworzenie kopii zapasowych | Wybór geograficznie nadmiarowego, strefowo nadmiarowego lub lokalnie nadmiarowego magazynu kopii zapasowych, przechowywania 1–7 dni (domyślnie 7 dni) Długoterminowe przechowywanie dostępne do 10 lat |
Wybór geograficznie nadmiarowego, strefowo nadmiarowego lub lokalnie nadmiarowego magazynu kopii zapasowych, przechowywania 1–35 dni (domyślnie 7 dni) Długoterminowe przechowywanie dostępne do 10 lat |
Wybór magazynu lokalnie nadmiarowego (LRS), strefowo nadmiarowego (ZRS) lub magazynu geograficznie nadmiarowego (GRS) Przechowywanie przez 1–35 dni (domyślnie 7 dni) z dostępnym okresem przechowywania długoterminowego do 10 lat |
| CPU | Niski | Niski, średni, wysoki | Średnie, wysokie |
| IOPS (Liczba operacji we/wy na sekundę) (przybliżona)1 | 1–4 IOPS (operacji we/wy na sekundę) na jednostkę DTU | 1–4 IOPS na jednostkę DTU | >25 IOPS na jednostkę DTU |
| Opóźnienie IO (przybliżone) | 5 ms (odczyt), 10 ms (zapis) | 5 ms (odczyt), 10 ms (zapis) | 2 ms (odczyt/zapis) |
| Indeksowanie kolumnowe2 | Nie dotyczy | Standardowa S3 i nowsze | Obsługiwane |
| OlTP w pamięci | Nie dotyczy | Nie dotyczy | Wspierane |
1 Wszystkie operacje IOPS odczytu i zapisu na sekundę względem plików danych, w tym operacje IO w tle (punkt kontrolny i leniwy zapisujący).
2 Aby uzyskać więcej informacji, zobacz Zmienianie poziomów usług baz danych zawierających kolumnowe indeksy.
Ważne
Cele usługi w warstwie Podstawowa, S0, S1 i S2 zapewniają mniej niż jeden rdzeń wirtualny (procesor CPU). W przypadku obciążeń intensywnie korzystających z CPU zalecany jest poziom usługi S3 lub wyższy.
W przypadku celów usługi Podstawowa, S0 i S1 pliki bazy danych są przechowywane w usłudze Azure Standard Storage, która używa nośnika magazynu opartego na dysku twardym (HDD). Te cele usługi najlepiej nadają się do tworzenia, testowania i innych rzadko używanych obciążeń, które są mniej wrażliwe na zmienność wydajności.
Napiwek
Aby wyświetlić rzeczywiste limity zarządzania zasobami dla bazy danych lub elastycznej puli, zapytaj o widok sys.dm_user_db_resource_governance. W przypadku pojedynczej bazy danych zwracany jest jeden wiersz. W przypadku bazy danych w elastycznej puli wiersz jest zwracany dla każdej bazy danych w puli.
Limity zasobów
Limity zasobów różnią się w przypadku pojedynczych baz danych i baz danych w puli.
Limity magazynu pojedynczej bazy danych
W usłudze Azure SQL Database rozmiary obliczeniowe są wyrażane w jednostkach transakcji bazy danych (DTU) dla pojedynczych baz danych i elastycznych jednostek transakcji bazy danych (eDTU) dla pul elastycznych. Aby dowiedzieć się więcej, zapoznaj się z tematem Limity zasobów dla pojedynczych baz danych.
| Podstawowa | Standard | Wysokiej klasy | |
|---|---|---|---|
| Maksymalny rozmiar magazynu | 2 GB | 1 TB | 4 TB |
| Maksymalna liczba jednostek DTU | 5 | 3000 | 4000 |
Ważne
W pewnych okolicznościach może być konieczne zmniejszenie bazy danych w celu odzyskania nieużywanego miejsca. Aby uzyskać więcej informacji, zobacz Zarządzanie miejscem na pliki dla baz danych w usłudze Azure SQL Database.
Limity puli elastycznej
Aby dowiedzieć się więcej, zapoznaj się z tematem Limity zasobów dla pul elastycznych przy użyciu modelu zakupu DTU.
| Podstawowa | Standard | Premium | |
|---|---|---|---|
| Maksymalny rozmiar magazynu na bazę danych | 2 GB | 1 TB | 1 TB |
| Maksymalny rozmiar przechowywania na każdą pulę | 156 GB | 4 TB | 4 TB |
| Maksymalna liczba jednostek eDTU na bazę danych | 5 | 3000 | 4000 |
| Maksymalna liczba jednostek eDTU na pulę | 1600 | 3000 | 4000 |
| Maksymalna liczba baz danych na pulę | 500 | 500 | 100 |
Ważne
Ponad 1 TB magazynu w warstwie Premium jest obecnie dostępne we wszystkich regionach, z wyjątkiem: Chiny Wschodnie, Chiny Północne, Niemcy Środkowe i Niemcy Północno-Wschodnie. W tych regionach maksymalna wielkość magazynu w warstwie Premium jest ograniczona do 1 TB. Aby uzyskać więcej informacji, zobacz bieżące ograniczenia P11–P15.
Ważne
W pewnych okolicznościach może być konieczne zmniejszenie bazy danych w celu odzyskania nieużywanego miejsca. Aby uzyskać więcej informacji, zobacz zarządzanie miejscem na pliki w usłudze Azure SQL Database.
Test porównawczy jednostek DTU
Cechy fizyczne (procesor CPU, pamięć, operacje we/wy) skojarzone z każdą miarą DTU są skalibrowane przy użyciu testu porównawczego, który symuluje rzeczywiste obciążenie bazy danych.
Dowiedz się więcej na temat schematu, typów transakcji używanych, mieszanki obciążeń, użytkowników i tempa, zasad skalowania oraz metryk powiązanych z benchmarkiem DTU.
Porównanie modeli zakupów opartych na jednostkach DTU i rdzeni wirtualnych
Chociaż model zakupów oparty na jednostkach DTU wiąże zasoby obliczeniowe, magazynowe i wejścia/wyjścia, w porównaniu do niego model zakupów rdzeni wirtualnych dla usługi Azure SQL Database umożliwia niezależny wybór i skalowanie zasobów obliczeniowych i magazynowych.
Model zakupów oparty na rdzeniach wirtualnych umożliwia również korzystanie z Korzyści użycia hybrydowego platformy Azure dla programu SQL Server w celu oszczędzania kosztów oraz oferuje bezserwerową warstwę obliczeniową dla Azure SQL Database oraz opcje warstwy usługi Hyperscale dla Azure SQL Database, które nie są dostępne w modelu zakupów opartym na jednostkach DTU.
Dowiedz się więcej w artykule Porównanie modeli zakupów opartych na vCore i DTU w usłudze Azure SQL Database.