Wybieranie między modelami zakupów opartymi na rdzeniu wirtualnych i jednostce DTU — Azure SQL Database i SQL zarządzanego

DOTYCZY: Azure SQL Database Wystąpienie zarządzane usługi Azure SQL

Azure SQL Database usługi Azure SQL Managed Instance umożliwiają łatwe zakup w pełni zarządzanego aparatu bazy danych platformy jako usługi (PaaS), który odpowiada Twoim potrzebom w zakresie wydajności i kosztów. W zależności od modelu wdrażania wybranego do Azure SQL Database możesz wybrać model zakupów, który będzie dla Ciebie:

  • Model zakupów oparty na rdzeniach wirtualnych (zalecane). Ten model zakupów umożliwia wybór między aprowizowana warstwą obliczeniową a warstwą obliczeniową bez serwera. W warstwie aprowizowanych zasobów obliczeniowych możesz wybrać dokładną ilość zasobów obliczeniowych, które są zawsze aprowowane dla obciążenia. W przypadku warstwy obliczeniowej bez serwera można określić skalowanie automatyczne zasobów obliczeniowych w konfigurowalnym zakresie obliczeniowym. Dzięki tej warstwie obliczeniowej możesz również automatycznie wstrzymywać i wznawiać bazę danych na podstawie aktywności obciążenia. Cena jednostkowa rdzeni wirtualnych za jednostkę czasu jest niższa w aprowizowanych warstwach obliczeniowych niż w warstwie bez serwera obliczeniowej.
  • Model zakupów oparty na jednostce transakcji bazy danych (DTU). Ten model zakupów zapewnia pakiety obliczeniowe i magazynowe w pakiecie zrównoważone dla typowych obciążeń.

Istnieją dwa modele zakupów:

W poniższej tabeli i wykresie porównano i porównano modele zakupów oparte na rdzeniu wirtualnych i oparte na jednostkach DTU:

Model zakupów Opis Optymalne zastosowanie
Oparty na jednostkach DTU Ten model jest oparty na powiązanej mierze zasobów obliczeniowych, magazynowych i we/wy. Rozmiary obliczeniowe są wyrażane w jednostkach DTU w przypadku pojedynczych baz danych, a w jednostkach transakcji elastycznej bazy danych (eDTU) w przypadku pul elastycznych. Aby uzyskać więcej informacji na temat jednostek DTU i eDTU, zobacz Co to są jednostki DTU i eDTU?. Klienci, którzy chcą mieć proste, wstępnie skonfigurowane opcje zasobów
Oparty na rdzeniach wirtualnych Ten model umożliwia niezależne wybieranie zasobów obliczeniowych i magazynowych. Model zakupu oparty na rdzeniach wirtualnych umożliwia również obniżenie kosztów dzięki korzyści użycia hybrydowego platformy Azure dla programu SQL Server. Klienci ceniący elastyczność, kontrolę i przejrzystość

Porównanie modeli cen

Chcesz zoptymalizować i zaoszczędzić na wydatkach na chmurę?

Opłaty za usługi platformy Azure. Usługa Azure Cost Management ułatwia określanie budżetów i konfigurowanie alertów w celu utrzymywania wydatków pod kontrolą. Analizowanie i optymalizowanie kosztów platformy Azure oraz zarządzanie nimi za pomocą Cost Management. Aby dowiedzieć się więcej, zobacz Przewodnik Szybki start dotyczący analizowania kosztów.

Koszty obliczeń

Koszty aprowowanych zasobów obliczeniowych

W warstwie aprowizowanych zasobów obliczeniowych koszt obliczeń odzwierciedla łączną pojemność obliczeniową aprowizowana dla aplikacji.

W warstwie Krytyczne dla działania firmy automatycznie przydzielamy co najmniej trzy repliki. Aby odzwierciedlić tę dodatkową alokację zasobów obliczeniowych, cena w modelu zakupów opartym na rdzeniu wirtualnych jest około 2,7 razy wyższa w warstwie usługi Krytyczne dla działania firmy niż w warstwie usługi Ogólnego przeznaczenia. Podobnie wyższa cena magazynu za GB w warstwie Krytyczne dla działania firmy odzwierciedla wyższe limity operacji we/wy i mniejsze opóźnienie magazynu SSD.

Koszt magazynu kopii zapasowych jest taki sam dla warstwy Krytyczne dla działania firmy i warstwy usługi Ogólnego przeznaczenia, ponieważ obie warstwy używają magazynu w warstwie Standardowa do tworzenia kopii zapasowych.

Koszty zasobów obliczeniowych bez serwera

Opis sposobu definiowania pojemności obliczeniowej i obliczania kosztów dla warstwy zasobów obliczeniowych bez serwera znajduje się w te SQL Database bez serwera.

Koszty magazynowania

Różne typy magazynów są rozliczane w różny sposób. W przypadku magazynu danych opłata jest naliczana za aprowizowany magazyn na podstawie maksymalnego rozmiaru wybranej bazy danych lub puli. Koszt nie zmienia się, chyba że zmniejszysz lub zwiększysz to maksimum. Magazyn kopii zapasowych jest skojarzony z automatycznymi kopiami zapasami wystąpienia i jest przydzielany dynamicznie. Zwiększenie okresu przechowywania kopii zapasowych zwiększa magazyn kopii zapasowych, który jest zużywany przez wystąpienie.

Domyślnie automatyczne kopie zapasowe baz danych są kopiowane do standardowego konta magazynu obiektów blob dostępnego do odczytu magazynu geograficznie nadmiarowego (RA-GRS). Ten magazyn jest używany przez cotygodniowe pełne kopie zapasowe, codzienne różnicowe kopie zapasowe i kopie zapasowe dziennika transakcji, które są kopiowane co pięć minut. Rozmiar dzienników transakcji zależy od szybkości zmiany bazy danych. Minimalna ilość miejsca do magazynowania równa 100% rozmiaru bazy danych jest dostarczana bez dodatkowych opłat. Opłata za dodatkowe zużycie magazynu kopii zapasowych jest naliczana w GB miesięcznie.

Aby uzyskać więcej informacji na temat cen magazynu, zobacz stronę cennika.

Model zakupów oparty na rdzeniach wirtualnych

Rdzeń wirtualny (vCore) reprezentuje procesor logiczny i oferuje opcję wyboru między generacjami sprzętu a fizycznymi cechami sprzętu (na przykład liczbą rdzeni, pamięcią i rozmiarem magazynu). Model zakupów oparty na rdzeniu wirtualnych zapewnia elastyczność, kontrolę, przejrzystość użycia poszczególnych zasobów oraz prosty sposób transliowania wymagań obciążeń lokalnych na chmurę. Ten model umożliwia wybieranie zasobów obliczeniowych, pamięci i magazynu w zależności od potrzeb obciążeń.

W modelu zakupów opartym na rdzeniu wirtualnych można wybrać między warstwami usług Ogólnego przeznaczenia i Krytyczne dla działania firmy dla SQL Database i SQL Managed Instance. W przypadku pojedynczych baz danych można również wybrać warstwę usługi Hiperskala.

Model zakupów oparty na rdzeniu wirtualnych umożliwia niezależne wybieranie zasobów obliczeniowych i magazynowych, dopasowanie wydajności lokalnej i optymalizację ceny. W modelu zakupów opartym na rdzeniu wirtualnych płacisz za:

  • Zasoby obliczeniowe (warstwa usług + liczba rdzeni wirtualnych i ilość pamięci + generacja sprzętu).
  • Typ i ilość danych oraz magazynu dzienników.
  • Magazyn kopii zapasowych (RA-GRS).

Ważne

Opłaty za zasoby obliczeniowe, we/wy oraz magazyn danych i dzienników są naliczane za bazę danych lub pulę elastyczną. Opłaty za magazyn kopii zapasowych są naliczane za każdą bazę danych. Aby uzyskać więcej informacji o opłatach SQL wystąpienia zarządzanego, zobacz SQL Wystąpienie zarządzane. Ograniczenia dotyczące regionów: Aby uzyskać bieżącą listę obsługiwanych regionów, zobacz dostępne produkty według regionów. Aby utworzyć wystąpienie zarządzane w regionie, który obecnie nie jest obsługiwany, wyślij żądanie pomocy technicznej za pośrednictwem Azure Portal.

Jeśli baza danych zużywa więcej niż 300 jednostek DTU, konwersja na model zakupów oparty na rdzeniu wirtualnych może obniżyć koszty. Konwersję można konwertować przy użyciu wybranego interfejsu API lub przy użyciu Azure Portal bez przestojów. Jednak konwersja nie jest wymagana i nie jest wykonywana automatycznie. Jeśli model zakupów oparty na jednostce DTU spełnia Twoje wymagania dotyczące wydajności i działalności biznesowej, należy nadal z niego korzystać.

Aby przekonwertować model zakupów oparty na jednostce DTU na model zakupów oparty na rdzeniu wirtualnych, zobacz Migrowanie z jednostek DTU do rdzeni wirtualnych.

Model zakupów oparty na jednostkach DTU

Jednostka transakcji bazy danych (DTU) reprezentuje połączoną miarę procesora, pamięci, odczytów i zapisów. Model zakupów oparty na jednostkach DTU oferuje zestaw wstępnie skonfigurowanych pakietów zasobów obliczeniowych i uwzględniony magazyn, który umożliwia stosowanie różnych poziomów wydajności aplikacji. Jeśli wolisz prostotę wstępnie skonfigurowanego pakietu i płatności stałych w każdym miesiącu, model oparty na jednostce DTU może być bardziej odpowiedni dla Twoich potrzeb.

W modelu zakupów opartym na jednostkach DTU można wybrać warstwę usług Podstawowa, Standardowa i Premium dla Azure SQL Database. Model zakupów oparty na jednostce DTU nie jest dostępny dla usługi Azure SQL Managed Instance.

Jednostki transakcji bazy danych (DTU)

W przypadku pojedynczej bazy danych o określonym rozmiarze obliczeniowym w warstwie usługiplatforma Azure gwarantuje określony poziom zasobów dla tej bazy danych (niezależnie od innych baz danych w chmurze platformy Azure). Ta gwarancja zapewnia przewidywalny poziom wydajności. Ilość zasobów przydzielonych dla bazy danych jest obliczana jako liczba jednostek DTU i jest miarą w pakiecie zasobów obliczeniowych, magazynowych i we/wy.

Stosunek między tymi zasobami jest pierwotnie określany przez obciążenie testu porównawczego przetwarzania transakcji online (OLTP) zaprojektowane tak, aby było typowe dla rzeczywistych obciążeń OLTP. Gdy obciążenie przekracza ilość dowolnego z tych zasobów, przepływność jest ograniczana, co zwiększa wydajność i przekracza limity czasu.

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 wpływają na zasoby dostępne dla bazy danych.

Obwiedni

Jednostki DTU są najbardziej przydatne do zrozumienia zasobów względnych przydzielonych dla baz danych o różnych rozmiarach obliczeniowych i warstwach usług. Przykład:

  • Podwojenie liczby jednostek DTU przez zwiększenie rozmiaru obliczeniowego bazy danych jest równoznaczne z podwojenie zestawu zasobów dostępnych dla tej bazy danych.
  • Baza danych warstwy usługi Premium P11 ze 1750 jednostkami DTU zapewnia 350-krotnie większą moc obliczeniową jednostek DTU niż podstawowa baza danych warstwy usługi z 5 jednostkami DTU.

Aby uzyskać lepszy wgląd w użycie zasobów (DTU) obciążenia, użyj szczegółowych informacji o wydajności zapytań, aby:

  • Zidentyfikuj najważniejsze zapytania według procesora CPU/czasu trwania/liczby wykonań, które potencjalnie można dostroić w celu poprawy wydajności. Na przykład zapytanie intensywnie obciążane 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.
  • Uzyskaj dostęp do zaleceń dotyczących dostrajania wydajności, które pokazują akcje podjęte przez SQL Database Advisor.

Jednostki transakcji elastycznej bazy danych (eDKU)

W przypadku baz danych, które są zawsze dostępne, zamiast zapewniać dedykowany zestaw zasobów (DTU), które mogą nie zawsze być potrzebne, możesz umieścić te bazy danych w elastycznej puli. Bazy danych w elastycznej puli znajdują się na jednym serwerze i współdzielą pulę zasobów.

Zasoby udostępnione w elastycznej puli są mierzone za pomocą jednostek eDT (Elastic Database Transaction Units). Pule elastyczne zapewniają proste, ekonomiczne rozwiązanie do zarządzania celami wydajności dla wielu baz danych o znacznie zróżnicowanych i nieprzewidywalnych wzorcach użycia. Elastyczna pula gwarantuje, że wszystkie zasoby nie mogą być używane przez jedną bazę danych w puli, przy jednoczesnym zapewnieniu, że każda baza danych w puli zawsze ma minimalną ilość niezbędnych zasobów.

Pula ma ustawioną liczbę eDKU za ustawioną cenę. W elastycznej puli poszczególne bazy danych mogą być automatycznie skalowane w skonfigurowanych granicach. Baza danych o większych obciążeniach będzie zużywać więcej eDKU, aby zaspokoić zapotrzebowanie. Bazy danych o mniejszych obciążeniach będą zużywać mniej eDKU. Bazy danych bez obciążenia nie będą korzystać z żadnych eDKU. Ponieważ zasoby są aprowowane dla całej puli, a nie dla 1 bazy danych, pule elastyczne upraszczają zadania zarządzania i zapewniają przewidywalny budżet dla puli.

Możesz dodać kolejne eDKU do istniejącej puli bez przestojów bazy danych i bez wpływu na bazy danych w puli. Podobnie, jeśli nie potrzebujesz już dodatkowych eDKU, usuń je z istniejącej puli w dowolnym momencie. W dowolnym momencie możesz również dodać bazy danych do puli lub odjąć je od puli. Aby zarezerwować liczbę eDTY dla innych baz danych, ogranicz liczbę eDTY, których baza danych może używać pod dużym obciążeniem. Jeśli baza danych stale nie zużyje zasobów, przenieś ją z puli i skonfiguruj jako pojedynczą bazę danych z przewidywalną ilością wymaganych zasobów.

Określanie liczby jednostek DTU wymaganych przez obciążenie

Jeśli chcesz przeprowadzić migrację istniejącego obciążenia lokalnej lub SQL Server maszyny wirtualnej do usługi SQL Database, użyj kalkulatora jednostek DTU w celu przybliżonej liczby potrzebnych jednostek DTU. W przypadku istniejącego 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 dotyczące optymalizacji obciążenia. Dynamiczny sys.dm_db_resource_stats zarządzania (DMV) umożliwia wyświetlanie zużycia zasobów w ciągu ostatniej godziny. Widok sys.resource_stats katalogów wyświetla zużycie zasobów w ciągu ostatnich 14 dni, ale z niższą dokładnością średnich z pięciu minut.

Określanie wykorzystania jednostek DTU

Aby określić średnią wartość procentową 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 sys.dm_db_resource_stats , sys.resource_statsi sys.elastic_pool_resource_stats DMV. Innymi słowy, aby określić procent wykorzystania jednostek DTU/eDTU w kierunku limitu jednostek DTU/eDTU bazy danych lub elastycznej puli, wybierz największą wartość procentową z następujących wartości: , i w danym momencie avg_cpu_percent avg_data_io_percent w avg_log_write_percent czasie.

Uwaga

Limit jednostek DTU bazy danych jest określany przez procesor CPU, odczyty, zapis i pamięć dostępne dla bazy danych. Jednak ponieważ aparat SQL Database zwykle używa całej dostępnej pamięci dla swojej pamięci podręcznej danych w celu zwiększenia wydajności, wartość zwykle będzie zbliżyć się do 100%, niezależnie od bieżącego obciążenia bazy avg_memory_usage_percent danych. W związku z tym, mimo że pamięć pośrednio wpływa na limit jednostek DTU, nie jest używana w formule użycia jednostek DTU.

Obciążenia, które korzystają z elastycznej puli zasobów

Pule są odpowiednie dla baz danych o niskim średnim wykorzystaniu zasobów i stosunkowo rzadkich skokach wykorzystania. Aby uzyskać więcej informacji, zobacz Kiedy należy rozważyć SQL Database pulę elastyczną?.

Generacje sprzętu w modelu zakupów opartym na dtu

W modelu zakupów opartym na dtu klienci nie mogą wybrać generacji sprzętu używanej dla swoich baz danych. Chociaż dane bazy danych zwykle pozostają w konkretnej generacji sprzętu przez długi czas (często przez wiele miesięcy), istnieją pewne zdarzenia, które mogą spowodować, że baza danych zostanie przeniesiona na inną generację sprzętu.

Na przykład bazę danych można przenieść na inną generację 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 aktualnie używany sprzęt jest likwidowany z powodu zakończenia okresu eksploatacji.

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 testu porównawczego jednostek DTU pozostaną w znacznym stopniu identyczne, ponieważ baza danych przechodzi na inną generację sprzętu, o ile jej cel usługi (liczba jednostek DTU) pozostaje taki sam.

Jednak w szerokim zakresie obciążeń klientów działających w usługach Azure SQL Database wpływ użycia innego sprzętu dla tego samego celu usługi może być bardziej wyeksymatywny. Różne obciążenia będą korzystać z różnych konfiguracji i funkcji sprzętu. W związku z tym w przypadku obciążeń innych niż test porównawczy jednostek DTU można zobaczyć różnice wydajności, jeśli baza danych przechodzi z jednej generacji sprzętu do innej.

Na przykład aplikacja wrażliwa na opóźnienie sieci może zobaczyć lepszą wydajność sprzętu 5. generacji w porównaniu z 4. generacjią ze względu na użycie przyspieszonej sieci w generacji 5. generacji, ale aplikacja korzystająca z intensywnie korzystających operacji we/wy odczytu może zobaczyć lepszą wydajność sprzętu Gen4 w porównaniu z 5. generacjią ze względu na wyższy współczynnik pamięci na rdzeń w generacji 4.

Klienci z obciążeniami wrażliwymi na zmiany sprzętu lub klienci, którzy chcą kontrolować wybór generacji sprzętu dla bazy danych, mogą użyć modelu rdzeni wirtualnych, aby wybrać preferowaną generację sprzętu podczas tworzenia i skalowania bazy danych. W modelu rdzeni wirtualnych udokumentowano limity zasobów dla każdego celu usługi w każdej generacji sprzętu, zarówno dla pojedynczych baz danych, jak i pul elastycznych. Aby uzyskać więcej informacji na temat generacji sprzętu w modelu rdzeni wirtualnych, zobacz Generacje sprzętu dla maszyn wirtualnych SQL Database lub Generacje sprzętu dla SQL zarządzanego.

Często zadawane pytania

Czy muszę przesłonić moją aplikację w tryb offline, aby przekonwertować warstwę usługi opartą na jednostce DTU na warstwę usługi opartą na rdzeniu rdzeni wirtualnych?

Nie. Nie musisz przesłonić aplikacji w tryb offline. Nowe warstwy usług oferują prostą metodę konwersji online podobną do istniejącego procesu uaktualniania baz danych ze standardowej do warstwy usługi Premium i na drugi sposób. Tę konwersję można rozpocząć przy użyciu interfejsu Azure Portal, programu PowerShell, interfejsu wiersza polecenia platformy Azure, interfejsu SQL lub interfejsu API REST. Zobacz Zarządzanie pojedynczymi bazami danych i Zarządzanie elastycznymi pulami.

Czy mogę przekonwertować bazę danych z warstwy usług w modelu zakupów opartym na rdzeniu rdzeni wirtualnych na warstwę usługi w modelu zakupów opartym na dtu?

Tak, bazę danych można łatwo przekonwertować na dowolny obsługiwany cel wydajności przy użyciu interfejsu Azure Portal, programu PowerShell, interfejsu wiersza polecenia platformy Azure, interfejsu SQL lub interfejsu API REST. Zobacz Zarządzanie pojedynczymi bazami danych i Zarządzanie elastycznymi pulami.

Następne kroki

  • Aby uzyskać więcej informacji na temat modelu zakupów opartego na rdzeniu wirtualnych, zobacz Model zakupów oparty na rdzeniu rdzeni wirtualnych.
  • Aby uzyskać więcej informacji na temat modelu zakupów opartego na dtu, zobacz Model zakupów oparty na dtu.