warstwa usługi hiperskala

Dotyczy:Azure SQL Database

Usługa Azure SQL Database jest oparta na architekturze aparatu bazy danych programu SQL Server dostosowanej dla środowiska chmury w celu zapewnienia wysokiej dostępności nawet w przypadku awarii infrastruktury. W modelu zakupów rdzeni wirtualnych dla usługi Azure SQL Database można wybrać trzy warstwy usług:

• Ogólne przeznaczenie
• Krytyczne dla działania firmy
• Hiperskala

Warstwa usługi Hyperscale jest odpowiednia dla wszystkich typów obciążeń. Architektura natywna dla chmury zapewnia niezależne skalowalne zasoby obliczeniowe i magazynowe do obsługi najszerszej gamy tradycyjnych i nowoczesnych aplikacji. Zasoby obliczeniowe i magazynowe w warstwie Hiperskala znacznie przekraczają zasoby dostępne w warstwach Ogólnego przeznaczenia i Krytyczne dla działania firmy.

Aby uzyskać szczegółowe informacje na temat warstw usług Ogólnego Przeznaczenia i Krytycznych dla Działania Firmy w modelu zakupowym opartym na rdzeniach wirtualnych, zobacz Warstwy Usług Ogólnego Przeznaczenia i Krytycznych dla Działania Firmy. Aby porównać model zakupów oparty na rdzeniach wirtualnych z modelem zakupów opartym na jednostkach DTU, zobacz Porównanie modeli zakupów opartych na rdzeniach wirtualnych i jednostkach DTU w usłudze Azure SQL Database.

Warstwa usługi Hiperskala jest obecnie dostępna tylko dla usługi Azure SQL Database, a nie dla usługi Azure SQL Managed Instance.

Jakie są możliwości Hiperskali

Warstwa usługi Hiperskala w usłudze Azure SQL Database zapewnia następujące dodatkowe możliwości:

• Szybkie skalowanie — możesz szybko zwiększyć zasoby obliczeniowe, aby w razie potrzeby obsłużyć duże obciążenia, a następnie zmniejszyć je, gdy nie są już potrzebne.
• Szybkie skalowanie w poziomie — można aprowizować jedną lub więcej replik tylko do odczytu, aby odciążyć operacje odczytu i używać ich jako ciepłe rezerwy.
• Automatyczne skalowanie w górę, skalowanie w dół i rozliczenia zasobów obliczeniowych na podstawie użycia bezserwerowego.
• Zoptymalizowana cena/wydajność dla grupy baz danych w warstwie Hiperskala z różnym zapotrzebowaniem na zasoby w pulach elastycznych.
• Automatyczne skalowanie magazynu z obsługą do 128 TB bazy danych lub 100 TB elastycznej puli.
• Wyższa ogólna wydajność ze względu na większą przepływność dziennika transakcji i szybsze czasy zatwierdzania transakcji niezależnie od woluminów danych.
• Szybkie kopie zapasowe bazy danych (na podstawie migawek plików) niezależnie od rozmiaru bez wpływu operacji we/wy na zasoby obliczeniowe.
• Szybkie przywracanie lub kopiowanie bazy danych (na podstawie migawek plików) w minutach, a nie godzinach lub dniach.

Warstwa usługi Hiperskala usuwa wiele praktycznych limitów tradycyjnie spotykanych w bazach danych w chmurze. Jeśli większość innych baz danych jest ograniczona przez zasoby dostępne w jednym węźle, bazy danych w warstwie usługi Hiperskala nie mają takich limitów. Dzięki elastycznej architekturze magazynu magazyn rośnie w miarę potrzeb. W rzeczywistości bazy danych w warstwie Hiperskala nie są tworzone przy użyciu zdefiniowanego maksymalnego rozmiaru. Baza danych w trybie Hiperskala rośnie zgodnie z potrzebami — a opłaty są naliczane tylko za przydzieloną pojemność przechowywania. W przypadku obciążeń intensywnie korzystających z odczytu, warstwa usługi Hiperskala zapewnia szybkie skalowanie poziome, udostępniając dodatkowe repliki według potrzeby, aby odciążyć operacje odczytu.

Ponadto czas wymagany do utworzenia kopii zapasowych bazy danych lub skalowania w górę lub w dół nie jest już powiązany z ilością danych w bazie danych. Bazy danych hiperskala są kopiowane zapasowo praktycznie natychmiast. Bazę danych można również skalować w dziesiątkach terabajtów w górę lub w dół w ciągu kilku minut w aprowizowanej warstwie obliczeniowej lub używać bezserwerowej do automatycznego skalowania zasobów obliczeniowych. Ta funkcja uwalnia Cię od obaw związanych z ograniczeniami wynikającymi z początkowych wyborów dotyczących konfiguracji.

Aby uzyskać więcej informacji na temat rozmiarów obliczeniowych dla warstwy usługi Hiperskala, zobacz Właściwości warstwy usługi.

Kto powinien rozważyć warstwę usługi Hiperskala

Warstwa usługi Hiperskala jest przeznaczona dla wszystkich klientów, którzy wymagają wyższej wydajności i dostępności, szybkiej kopii zapasowej i przywracania oraz/lub szybkiego magazynu i skalowalności obliczeniowej. Obejmuje to klientów, którzy przechodzą do chmury, aby zmodernizować swoje aplikacje, oraz klientów, którzy już korzystają z innych warstw usług w usłudze Azure SQL Database. Warstwa usługi Hiperskala obsługuje szeroką gamę obciążeń baz danych— od czystego OLTP po czystą analizę. Jest zoptymalizowany pod kątem obciążeń OLTP i hybrydowych transakcji i przetwarzania analitycznego (HTAP).

Model cen hiperskala

Warstwa usługi Hiperskala jest dostępna tylko w modelu vCore. Aby dostosować się do nowej architektury, model cenowy różni się nieco od warstw Ogólnego Przeznaczenia lub Krytycznych dla Biznesu warstw usług:

• Provisioning zasobów obliczeniowych:

  Cena jednostek obliczeniowych w warstwie Hiperskala jest naliczana za replikę. Użytkownicy mogą dostosować liczbę kopii zapasowych o wysokiej dostępności od 0 do 4, w zależności od wymagań dotyczących dostępności i skalowalności, oraz utworzyć maksymalnie 30 nazwanych kopii, aby obsługiwać różne obciążenia w poziomie odczytu.

• Obliczenia bezserwerowe:

  Rozliczenia za użycie technologii bezserwerowej są oparte na rzeczywistym wykorzystaniu. Aby uzyskać więcej informacji, zobacz Warstwa obliczeniowa bezserwerowa dla usługi Azure SQL Database.

• Przechowywanie:

  Podczas konfigurowania bazy danych w warstwie Hiperskala nie trzeba określać maksymalnego rozmiaru danych. W warstwie Hiperskala opłaty za przechowywanie bazy danych są naliczane na podstawie rzeczywistej alokacji. Magazyn jest przydzielany automatycznie w zakresie od 10 GB do 128 TB i zwiększa się o 10 GB w razie potrzeby.

Aby uzyskać więcej informacji na temat cennika hiperskala, zobacz Cennik usługi Azure SQL Database.

Architektura funkcji rozproszonych

Hiperskala oddziela aparat przetwarzania zapytań od składników, które zapewniają długoterminowe przechowywanie i trwałość danych. Ta architektura umożliwia płynne skalowanie pojemności magazynu w zależności od potrzeb (do 128 TB) oraz możliwość szybkiego skalowania zasobów obliczeniowych.

Na poniższym diagramie przedstawiono funkcjonalną architekturę hiperskala:

Dowiedz się więcej o architekturze Hiperskali dla funkcji rozproszonych.

Zalety skalowania i wydajności

Dzięki możliwości szybkiego uruchamiania dodatkowych węzłów obliczeniowych tylko do odczytu architektura hiperskala umożliwia znaczne możliwości skalowania odczytu i może również zwolnić podstawowy węzeł obliczeniowy do obsługi większej liczby żądań zapisu. Ponadto węzły obliczeniowe można szybko skalować w górę/w dół ze względu na architekturę współdzielonego magazynu architektury hiperskalowalnej. Węzły obliczeniowe tylko do odczytu w warstwie Hiperskala są również dostępne w bezserwerowej warstwie obliczeniowej, która automatycznie skaluje zasoby obliczeniowe na podstawie zapotrzebowania na obciążenia.

Wysoka dostępność bazy danych w przypadku Hiperskali

Podobnie jak we wszystkich innych warstwach usług, Hiperskala gwarantuje trwałość danych dla zatwierdzonych transakcji niezależnie od dostępności replik obliczeniowych. Zakres przestoju spowodowany tym, że replika podstawowa staje się niedostępna, zależy od typu trybu failover (planowanego lub nieplanowanego), czy nadmiarowość strefy jest skonfigurowana, oraz od obecności co najmniej jednej repliki o wysokiej dostępności. W przypadku planowanego przejścia w tryb failover (na przykład zdarzenia konserwacji) system tworzy nową replikę podstawową przed zainicjowaniem trybu failover lub używa istniejącej repliki o wysokiej dostępności jako celu trybu failover. W przypadku nieplanowanego odtwarzania awaryjnego (takiego jak awaria sprzętowa repliki podstawowej), system używa repliki o wysokiej dostępności jako celu odtwarzania awaryjnego, jeśli taka istnieje, lub tworzy nową replikę podstawową z dostępnej puli zasobów obliczeniowych. W tym ostatnim przypadku czas trwania przestoju jest dłuższy z powodu dodatkowych kroków wymaganych do utworzenia nowej repliki podstawowej.

Możesz wybrać okno konserwacji, które pozwala na przewidywalne i mniej zakłócające wydarzenia dla Twojego obciążenia.

Aby uzyskać informacje na temat umowy SLA w warstwie Hiperskala, zobacz Umowa SLA dla usługi Azure SQL Database.

Pula buforów, odporne rozszerzenie puli buforów i ciągłe przygotowywanie

W Azure Database Hyperscale istnieje wyraźna separacja między obliczeniami a pamięcią. Przechowywanie zawiera wszystkie strony bazy danych w jednej bazie danych i może być przydzielone na różne maszyny w miarę rozwoju bazy danych. Węzeł obliczeniowy buforuje jednak tylko to, co jest ostatnio używane. Najważniejsze strony w obliczeniach komputerowych są przechowywane w pamięci w strukturze nazywanej pulą buforów (BP). Jest także przechowywany na lokalnym dysku SSD, w odpornym rozszerzeniu puli buforowej (RBPEX), co pozwala na szybsze pobranie danych w przypadku ponownego uruchomienia procesu obliczeniowego.

W systemie w chmurze obliczenia mogą przejść do różnych maszyn zgodnie z potrzebami. Warstwa obliczeniowa może mieć wiele replik. Jeden jest główny i odbiera wszystkie aktualizacje, podczas gdy inne są replikami wtórnymi. W przypadku awarii podstawowej jeden z replik pomocniczych o wysokiej dostępności można szybko awansować do podstawowej w procesie nazywanym trybem failover. Replika pomocnicza może nie mieć zoptymalizowanej pamięci podręcznej w BP i RBPEX pod kątem głównego obciążenia.

Ciągłe primowanie to proces, który zbiera informacje o tym, które strony są najbardziej obciążone we wszystkich replikach obliczeniowych. Ta informacja jest agregowana, a wysokodostępne repliki pomocnicze używają listy najczęściej używanych stron odpowiadających typowemu obciążeniu klienta. To stale wypełnia zarówno BP, jak i RBPEX najbardziej aktualnymi stronami, aby nadążać za zmianami w obciążeniu klienta.

Bez ciągłego inicjowania, zarówno BP, jak i RBPEX nie są dziedziczone przez nowe repliki wysokiej dostępności i mogą być odtwarzane tylko podczas obciążenia użytkownika. Ciągłe zapełnianie oszczędza czas i zapobiega niespójnej wydajności, ponieważ nie ma oczekiwania, zanim pamięci podręczne zostaną ponownie w pełni nawodnione. Dzięki ciągłemu zasypowaniu nowe repliki pomocnicze o wysokiej dostępności natychmiast zaczną priming ich BP i RBPEX. Dzięki temu wydajność będzie bardziej spójna podczas występowania awarii.

Ciągłe buforowanie działa na oba sposoby: repliki pomocnicze o wysokiej dostępności będą buforować strony używane w replice podstawowej, a podstawowa replika będzie buforować strony związane z obciążeniem replik pomocniczych.

Kopia zapasowa i przywracanie

Operacje tworzenia kopii zapasowych i przywracania baz danych w warstwie Hiperskala są oparte na migawkach plików. Dzięki temu te operacje mogą być niemal natychmiastowe. Ponieważ architektura hyperscale korzysta z warstwy pamięci w celu tworzenia kopii zapasowych i przywracania, zmniejsza to obciążenie przetwarzania i wpływ na wydajność replik obliczeniowych. Dowiedz się więcej na temat kopii zapasowych w systemie Hiperskala i nadmiarowości przechowywania.

Zarządzanie awariami dla baz danych w warstwie Hiperskala

Jeśli musisz przywrócić bazę danych w warstwie Hiperskala w usłudze Azure SQL Database do regionu innego niż ten, w którym jest obecnie hostowana, w ramach operacji odzyskiwania po awarii, ćwiczeń, relokacji lub z jakiegokolwiek innego powodu, podstawową metodą jest wykonanie przywracania geograficznego bazy danych. Przywracanie geograficzne jest dostępne tylko wtedy, gdy przechowywanie geograficznie nadmiarowe (RA-GRS) zostało wybrane jako nadmiarowość magazynu.

Dowiedz się więcej na temat przywracania bazy danych w warstwie Hiperskala do innego regionu.

Porównanie limitów zasobów

Warstwy usług oparte na rdzeniach wirtualnych (vCore) są zróżnicowane na podstawie dostępności bazy danych, typu przechowywania, wydajności i maksymalnego rozmiaru przechowywania. Te różnice opisano w poniższej tabeli:

¹ Uproszczone ceny dla SQL Database Hyperscale pojawiły się w grudniu 2023 r. Zapoznaj się z blogiem o cenach hiperskalowych dla szczegółów.

² Od grudnia 2023 r. Azure Hybrid Benefit nie jest dostępny dla nowych baz danych w warstwie hiperskala ani w subskrypcjach deweloperskich/testowych. Istniejące pojedyncze bazy danych w warstwie Hiperskala z przydzielonymi zasobami obliczeniowymi mogą nadal korzystać z Korzyści hybrydowej platformy Azure, aby zaoszczędzić na kosztach obliczeń aż do grudnia 2026 roku. Aby uzyskać więcej informacji, zapoznaj się z blogiem dotyczącym cen hiperskalowego.

Zasoby obliczeniowe

¹ W widoku zarządzania dynamicznego sys.dm_user_db_resource_governance generowanie sprzętu dla baz danych przy użyciu procesorów Intel® SP-8160 (Skylake) jest wyświetlane jako Gen6, generacja sprzętu dla baz danych korzystających z technologii Intel® 8272CL (Cascade Lake) jest wyświetlana jako Gen7, a generacja sprzętu dla baz danych korzystających z technologii Intel® Xeon® Platinum 8370C (Ice Lake) lub AMD® EPYC® 7763v (Milan) jest wyświetlana jako Gen8. W przypadku danego rozmiaru obliczeniowego i konfiguracji sprzętu limity zasobów są takie same niezależnie od typu procesora CPU. Aby uzyskać więcej informacji, zobacz Limity zasobów dla pojedynczych baz danych i pul elastycznych.

Usługi Serverless są obsługiwane tylko na sprzęcie z serii Standard (Gen5).

Tworzenie baz danych w warstwie Hiperskala i zarządzanie nimi

Bazy danych hiperskala można tworzyć i zarządzać nimi przy użyciu witryny Azure Portal, języka Transact-SQL, programu PowerShell i interfejsu wiersza polecenia platformy Azure. Aby uzyskać więcej informacji, zobacz Szybki start: tworzenie bazy danych w warstwie Hiperskala.

Ograniczenia

Są to bieżące ograniczenia warstwy usługi Hiperskala. Aktywnie pracujemy nad usunięciem jak największej liczby tych ograniczeń.

Powiązana zawartość

• Często zadawane pytania dotyczące hiperskala
• Porównaj modele zakupu oparte na rdzeniach wirtualnych (vCore) i jednostkach DTU w Azure SQL Database
• Zarządzanie zasobami w usłudze Azure SQL Database
• Limity zasobów dla pojedynczych baz danych podczas używania modelu zakupu opartego na rdzeniach wirtualnych
• Porównanie funkcji: Azure SQL Database i Azure SQL Managed Instance
• Architektura hiperskalowalnych funkcji rozproszonych
• Jak zarządzać bazą danych w warstwie Hiperskala