Udostępnij za pośrednictwem

Dynamiczne skalowanie zasobów bazy danych przy minimalnym przestoju — Azure SQL Database i Azure SQL Managed Instance

Dotyczy:Azure SQL DatabaseAzure SQL Managed Instance

Usługi Azure SQL Database i Azure SQL Managed Instance umożliwiają dynamiczne dodawanie większej liczby zasobów do bazy danych przy minimalnych przestojach. Istnieje jednak przełączenie w okresie, w którym łączność zostanie utracona z bazą danych przez krótki czas, co można ograniczyć przy użyciu logiki ponawiania prób.

Omówienie

Gdy zapotrzebowanie na Twoją aplikację rośnie od kilku urządzeń i klientów do milionów, usługa Azure SQL Database i zarządzana instancja SQL automatycznie skalują się na bieżąco przy minimalnym przestoju. Skalowalność jest jedną z najważniejszych cech platformy jako usługi (PaaS), która umożliwia dynamiczne dodawanie większej liczby zasobów do usługi w razie potrzeby. Usługa Azure SQL Database umożliwia łatwe zmienianie zasobów (moc procesora CPU, pamięć, przepływność we/wy i magazyn) przydzielonych do baz danych.

Możesz rozwiązać problemy z wydajnością z powodu zwiększonego użycia aplikacji, których nie można rozwiązać przy użyciu metod indeksowania lub ponownego zapisywania zapytań. Dodanie większej liczby zasobów umożliwia szybkie reagowanie, gdy baza danych osiągnie bieżące limity zasobów i potrzebuje większej mocy do obsługi obciążenia przychodzącego. Usługa Azure SQL Database umożliwia również skalowanie zasobów w dół, gdy nie są one potrzebne do obniżenia kosztów.

Nie musisz martwić się o zakup sprzętu i zmianę podstawowej infrastruktury. Skalowanie bazy danych można łatwo wykonać za pośrednictwem witryny Azure Portal za pomocą suwaka.

Usługa Azure SQL Database oferuje omówienie modelu zakupów opartego na jednostkach DTU oraz model zakupów oparty na rdzeniach wirtualnych, a usługa Azure SQL Managed Instance oferuje tylko model zakupów oparty na rdzeniach wirtualnych.

  • Model zakupu oparty na jednostkach DTU oferuje połączenie zasobów obliczeniowych, pamięci i operacji we/wy w trzech warstwach usług do obsługi zarówno lekkich, jak i ciężkich obciążeń baz danych: Podstawowa, Standardowa i Premium. Poziomy wydajności w każdej warstwie udostępniają różne kombinacje tych zasobów, do których można dodawać dodatkowe zasoby magazynu.
  • Model zakupów oparty na rdzeniach wirtualnych umożliwia wybranie liczby rdzeni wirtualnych, ilości pamięci oraz ilości i szybkości przechowywania. Ten model zakupów oferuje trzy warstwy usług: Ogólnego przeznaczenia, Krytyczne dla działania firmy i Hiperskala.

W dowolnym momencie można zmienić warstwę usługi, warstwę obliczeniową i limity zasobów dla bazy danych, elastycznej puli lub wystąpienia zarządzanego. Możesz na przykład utworzyć pierwszą aplikację w pojedynczej bazie danych przy użyciu bezserwerowej warstwy obliczeniowej, a następnie zmienić warstwę usługi ręcznie lub programowo w dowolnym momencie na aprowizowaną warstwę obliczeniową, aby zaspokoić potrzeby rozwiązania.

Uwaga

Istotne wyjątki, w których nie można zmienić warstwy usługi bazy danych:

  • Bazy danych korzystające z funkcji, które są dostępne tylko w warstwach usług Krytyczne dla działania firmy/Premium, nie można zmienić tak, aby korzystały z warstwy usługi Ogólnego przeznaczenia/Standardowa. Obecnie jedyną taką funkcją jest OLTP w pamięci.
  • Nie można migrować baz danych pierwotnie utworzonych w warstwie usługi Hiperskala do innych warstw usług. Jeśli migrujesz istniejącą bazę danych w usłudze Azure SQL Database do warstwy usługi Hiperskala, możesz cofnąć migrację do warstwy usługi Ogólnego przeznaczenia w ciągu 45 dni od pierwotnej migracji do warstwy Hiperskala. Jeśli chcesz przeprowadzić migrację bazy danych do innej warstwy usługi, takiej jak Krytyczne dla działania firmy, najpierw przeprowadź migrację odwrotną do warstwy usługi Ogólnego przeznaczenia, a następnie przeprowadź dalszą migrację. Aby uzyskać więcej informacji, zobacz Reverse migrate a database from Hyperscale (Odwrotna migracja bazy danych z warstwy Hiperskala).

Zasoby przydzielone do bazy danych można dostosować, zmieniając cel usługi lub skalowanie w celu spełnienia wymagań dotyczących obciążeń. Umożliwia to również płacenie tylko za potrzebne zasoby, gdy są one potrzebne. Zapoznaj się z notatką dotyczącą potencjalnego wpływu operacji skalowania na aplikację.

Usługa Azure SQL Database oferuje możliwość dynamicznego skalowania baz danych:

  • W przypadku pojedynczej bazy danych można użyć modeli DTU lub modeli vCore, aby zdefiniować maksymalną liczbę zasobów, które będą przypisane do każdej bazy danych.
  • Pule elastyczne umożliwiają zdefiniowanie maksymalnego limitu zasobów na grupę baz danych w puli.

Usługa Azure SQL Managed Instance umożliwia również skalowanie:

  • Usługa SQL Managed Instance używa rdzeni wirtualnych i umożliwia zdefiniowanie maksymalnej liczby rdzeni procesora CPU oraz maksymalnej ilości pamięci masowej przydzielonej do wystąpienia. Wszystkie bazy danych w wystąpieniu zarządzanym będą współdzielić zasoby przydzielone do wystąpienia.

Wskazówka

Dynamiczne skalowanie umożliwia klientom ręczne lub programowe zmienianie alokacji zasobów. Możliwość dynamicznego skalowania jest dostępna dla wszystkich zasobów usługi Azure SQL Database i usługi Azure SQL Managed Instance.

Oprócz obsługi dynamicznego skalowania warstwa obliczeniowa bezserwerowa w usłudze Azure SQL Database obsługuje skalowanie automatyczne. Bazy danych w warstwie bezserwerowej skalują zasoby automatycznie w zakresie określonym przez klienta na podstawie zapotrzebowania na obciążenie robocze. Do skalowania bazy danych nie jest wymagana żadna akcja klienta.

Wpływ operacji skalowania w górę lub w dół

Inicjowanie akcji skalowania w górę lub skalowanie w dół w dowolnej z wymienionych powyżej odmian powoduje ponowne uruchomienie procesu aparatu bazy danych i przeniesienie go do innej maszyny wirtualnej w razie potrzeby. Przeniesienie procesu silnika bazy danych na nową maszynę wirtualną jest procesem online, podczas którego można kontynuować korzystanie z istniejącej usługi Azure SQL Database. Gdy docelowy aparat bazy danych będzie gotowy do przetwarzania zapytań, otwarte połączenia z bieżącym aparatem bazy danych zostaną zakończone, a niezatwierdzone transakcje zostaną wycofane. Nowe połączenia zostaną nawiązane z docelowym silnikiem bazy danych.

Uwaga

Nie zaleca się skalowania wystąpienia zarządzanego, jeśli długotrwała transakcja, taka jak importowanie danych, zadania przetwarzania danych, odbudowa indeksu itp., jest w toku lub jeśli masz aktywne połączenie na wystąpieniu. Aby zapobiec wydłużeniu czasu skalowania bardziej niż zwykle, należy przeprowadzić skalowanie wystąpienia dopiero po zakończeniu wszystkich długotrwałych operacji.

Uwaga

Po zakończeniu procesu skalowania w górę/w dół można oczekiwać krótkiego przerwania połączenia. Jeśli zaimplementowano logikę ponawiania dla standardowych błędów przejściowych, nie zauważysz przełączenia awaryjnego.

Alternatywne metody skalowania

Skalowanie zasobów jest najprostszym i najbardziej efektywnym sposobem poprawy wydajności bazy danych bez konieczności zmieniania kodu bazy danych lub aplikacji. W niektórych przypadkach nawet najwyższe warstwy usług, rozmiary obliczeniowe i optymalizacje wydajności mogą nie obsługiwać obciążenia w sposób efektywny i ekonomiczny. W takim przypadku masz te dodatkowe opcje skalowania bazy danych:

  • Skalowanie odczytu w poziomie to dostępna funkcja, dzięki której uzyskujesz jedną replikę danych tylko do odczytu, przeznaczoną do wykonywania wymagających zapytań, takich jak raporty. Replika tylko do odczytu będzie obsługiwać obciążenie tylko do odczytu bez wpływu na użycie zasobów w podstawowej bazie danych.
  • Fragmentowanie bazy danych to zestaw technik, które umożliwiają podzielenie danych na kilka baz danych i niezależne skalowanie ich.

Operacje skalowania dla replik geograficznych

Jeśli zasób usługi Azure SQL ma replikę geograficzną, weź pod uwagę następujące wskazówki dotyczące operacji skalowania:

Treści powiązane

  • Last updated on