Warstwa usługi Hiperskala

DOTYCZY: Azure SQL Database

Azure SQL Database opiera się na architekturze aparatu bazy danych SQL Server dostosowanej dla środowiska chmury w celu zapewnienia wysokiej dostępności nawet w przypadku awarii infrastruktury. Istnieją trzy modele architektury, które są używane w Azure SQL Database:

  • Ogólnego przeznaczenia/Standardowa
  • Hiperskala
  • Krytyczne dla działania firmy/Premium

Warstwa usługi Hiperskala w Azure SQL Database to najnowsza warstwa usługi w modelu zakupów opartym na rdzeniach wirtualnych. Ta warstwa usługi to wysoce skalowalna warstwa wydajności magazynu i zasobów obliczeniowych, która wykorzystuje architekturę platformy Azure do skalowania w poziomie zasobów magazynu i zasobów obliczeniowych na potrzeby Azure SQL Database znacznie poza limity dostępne dla warstw usług Ogólnego przeznaczenia i Krytyczne dla działania firmy.

Uwaga

Jakie są możliwości warstwy Hiperskala

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

  • Obsługa do 100 TB rozmiaru bazy danych.
  • Niemal natychmiastowe kopie zapasowe bazy danych (na podstawie migawek plików przechowywanych w usłudze Azure Blob Storage) niezależnie od rozmiaru bez wpływu operacji we/wy na zasoby obliczeniowe.
  • Szybkie przywracanie bazy danych (na podstawie migawek plików) w minutach, a nie godzinach lub dniach (nie rozmiarze operacji na danych).
  • 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 skalowanie w poziomie — można aprowizować co najmniej jedną replikę tylko do odczytu na potrzeby odciążania obciążenia odczytu i używać ich jako rezerw na gorąco.
  • Szybkie skalowanie w górę — w stałym czasie można skalować zasoby obliczeniowe w górę, aby obsłużyć duże obciążenia w razie potrzeby, a następnie skalować zasoby obliczeniowe w dół, gdy nie są potrzebne.

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 warstwie Hiperskala rośnie zgodnie z potrzebami — opłaty są naliczane tylko za używaną pojemność. W przypadku obciążeń intensywnie korzystających z odczytu warstwa usługi Hiperskala zapewnia szybkie skalowanie w poziomie przez aprowizację dodatkowych replik w razie potrzeby na potrzeby odciążania obciążeń 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. Kopie zapasowe baz danych w warstwie Hiperskala można utworzyć 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. Ta funkcja pozwala uwolnić Cię od obaw związanych z tym, że są wywłaszczone przez początkowe opcje konfiguracji.

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

KtoTo należy wziąć pod uwagę warstwę usługi Hiperskala

Warstwa usługi Hiperskala jest przeznaczona dla większości obciążeń biznesowych, ponieważ zapewnia dużą elastyczność i wysoką wydajność z niezależnie skalowalnymi zasobami obliczeniowymi i magazynowymi. Dzięki możliwości automatycznego skalowania magazynu do 100 TB jest to doskonały wybór dla klientów, którzy:

  • Lokalne duże bazy danych i chcą zmodernizować swoje aplikacje, przechodząc do chmury
  • Są już w chmurze i są ograniczone przez maksymalne ograniczenia rozmiaru bazy danych innych warstw usług (1–4 TB)
  • Mają mniejsze bazy danych, ale wymagają szybkiego skalowania w pionie i w poziomie, wysokiej wydajności, natychmiastowej kopii zapasowej i szybkiego przywracania bazy danych.

Warstwa usługi Hiperskala obsługuje szeroką gamę obciążeń SQL Server, od czystego OLTP po czystą analizę, ale jest ona przede wszystkim zoptymalizowana pod kątem przetwarzania OLTP i hybrydowych obciążeń przetwarzania transakcyjnego i analitycznego (HTAP).

Ważne

Pule elastyczne nie obsługują warstwy usługi Hiperskala.

Model cen warstwy Hiperskala

Warstwa usługi Hiperskala jest dostępna tylko w modelu rdzeni wirtualnych. Aby dopasować go do nowej architektury, model cen różni się nieco od warstw usług Ogólnego przeznaczenia lub Krytyczne dla działania firmy:

  • Obliczenia:

    Cena jednostek obliczeniowych w warstwie Hiperskala jest naliczana za replikę. Cena Korzyść użycia hybrydowego platformy Azure jest stosowana do replik o wysokiej dostępności i nazwanych replik automatycznie. Użytkownicy mogą dostosować całkowitą liczbę replik pomocniczych o wysokiej dostępności z zakresu od 0 do 4, w zależności od wymagań umowy SLA .

  • Storage:

    Nie trzeba określać maksymalnego rozmiaru danych podczas konfigurowania bazy danych w warstwie Hiperskala. W warstwie Hiperskala opłaty są naliczane za magazyn dla bazy danych na podstawie rzeczywistej alokacji. Storage jest automatycznie przydzielana między 40 GB a 100 TB, w przyrostach 10 GB. W razie potrzeby wiele plików danych może rosnąć w tym samym czasie. Baza danych w warstwie Hiperskala jest tworzona z rozmiarem początkowym 10 GB i zaczyna rosnąć o 10 GB co 10 minut, aż osiągnie rozmiar 40 GB.

Aby uzyskać więcej informacji na temat cen w warstwie Hiperskala, zobacz cennik Azure SQL Database

Porównanie limitów zasobów

Warstwy usług oparte na rdzeniach wirtualnych są zróżnicowane na podstawie dostępności bazy danych i typu magazynu, wydajności i maksymalnego rozmiaru magazynu, zgodnie z opisem w poniższej tabeli:

Ogólnego przeznaczenia Hiperskala Krytyczne dla działania firmy
Optymalne zastosowanie Oferuje opcje zasobów obliczeniowych i magazynu o zrównoważonym budżecie. Większość obciążeń biznesowych. Skalowanie automatyczne rozmiaru magazynu do 100 TB, szybkie skalowanie w pionie i w poziomie, szybkie przywracanie bazy danych. Aplikacje OLTP z dużą szybkością transakcji i małym opóźnieniem we/wy. Zapewnia najwyższą odporność na awarie i szybkie przechodzenie w tryb failover przy użyciu wielu synchronicznie zaktualizowanych replik.
Rozmiar obliczeniowy Od 1 do 80 rdzeni wirtualnych Od 1 do 80 rdzeni wirtualnych1 Od 1 do 80 rdzeni wirtualnych
Typ magazynu Premium magazynu zdalnego (na wystąpienie) Magazyn rozdzielony z lokalną pamięcią podręczną SSD (na wystąpienie) Superszybki lokalny magazyn SSD (na wystąpienie)
Storage rozmiar1 5 GB – 4 TB Do 100 TB 5 GB – 4 TB
Liczba operacji we/wy na sekundę 500 operacji we/wy na sekundę na rdzeń wirtualny z maksymalną 7000 operacjami we/wy na sekundę Hiperskala to wielowarstwowa architektura z buforowaniem na wielu poziomach. Skuteczne operacje we/wy na sekundę będą zależeć od obciążenia. 5000 operacji we/wy na sekundę z maksymalną 200 000 operacji we/wy na sekundę
Dostępność 1 replika, brak skalowania odczytu, strefowo nadmiarowa wysoka dostępność (wersja zapoznawcza), brak lokalnej pamięci podręcznej Wiele replik, do 4 skalowania odczytu w poziomie, strefowo nadmiarowa wysoka dostępność (wersja zapoznawcza), częściowa lokalna pamięć podręczna 3 repliki, 1 skalowanie odczytu, strefowo nadmiarowa wysoka dostępność, pełny magazyn lokalny
Tworzenie kopii zapasowych Wybór geograficznie nadmiarowego, strefowo nadmiarowego lub lokalnie nadmiarowego magazynu kopii zapasowych, przechowywania 1–35 dni (domyślnie 7 dni) Wybór geograficznie nadmiarowego, strefowo nadmiarowego lub lokalnie nadmiarowego magazynu kopii zapasowych, przechowywania 1–35 dni (domyślnie 7 dni) Wybór geograficznie nadmiarowego, strefowo nadmiarowego lub lokalnie nadmiarowego magazynu kopii zapasowych, przechowywania 1–35 dni (domyślnie 7 dni)

1 Pule elastyczne nie są obsługiwane w warstwie usługi Hiperskala.

Uwaga

Krótkoterminowe przechowywanie kopii zapasowych przez 1–35 dni dla baz danych w warstwie Hiperskala jest teraz dostępne w wersji zapoznawczej.

Architektura funkcji rozproszonych

Hiperskala oddziela aparat przetwarzania zapytań od składników, które zapewniają długoterminowe przechowywanie i trwałość danych. Ta architektura zapewnia możliwość bezproblemowego skalowania pojemności magazynu w razie potrzeby (początkowy cel wynosi 100 TB), a także możliwość szybkiego skalowania zasobów obliczeniowych.

Na poniższym diagramie przedstawiono różne typy węzłów w bazie danych hiperskala:

architecture

Dowiedz się więcej o architekturze funkcji rozproszonych w warstwie Hiperskala.

Zalety skalowania i wydajności

Dzięki możliwości szybkiego uruchamiania w górę/w dół 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ę magazynu współdzielonego architektury hiperskala.

Tworzenie baz danych w warstwie Hiperskala i zarządzanie nimi

Bazy danych w warstwie Hiperskala można tworzyć i zarządzać nimi przy użyciu Azure Portal, transact-SQL, programu PowerShell i interfejsu wiersza polecenia platformy Azure.

Operacja Szczegóły Dowiedz się więcej
Tworzenie bazy danych w warstwie Hiperskala Bazy danych w warstwie Hiperskala są dostępne tylko przy użyciu modelu zakupów opartego na rdzeniach wirtualnych. Znajdź przykłady tworzenia bazy danych hiperskala w przewodniku Szybki start: tworzenie bazy danych w warstwie Hiperskala w Azure SQL Database.
Uaktualnianie istniejącej bazy danych do warstwy Hiperskala Migrowanie istniejącej bazy danych w Azure SQL Database do warstwy Hiperskala jest rozmiarem operacji danych. Dowiedz się , jak przeprowadzić migrację istniejącej bazy danych do warstwy Hiperskala.
Odwrotna migracja bazy danych hiperskala do warstwy usługi Ogólnego przeznaczenia (wersja zapoznawcza) Jeśli wcześniej przeprowadzono migrację istniejącej Azure SQL Database do warstwy usługi Hiperskala, możesz cofnąć migrację bazy danych do warstwy usługi Ogólnego przeznaczenia w ciągu 45 dni od oryginalnej migracji do warstwy Hiperskala.

Jeśli chcesz przeprowadzić migrację bazy danych do innej warstwy usług, takiej jak Krytyczne dla działania firmy, najpierw przeprowadź migrację odwrotną do warstwy usługi Ogólnego przeznaczenia, a następnie zmień warstwę usługi.
Dowiedz się , jak cofnąć migrację z warstwy Hiperskala, w tym ograniczenia dotyczące migracji odwrotnej.

Wysoka dostępność bazy danych w warstwie Hiperskala

Podobnie jak we wszystkich innych warstwach usług, hiperskala gwarantuje trwałość danych dla zatwierdzonych transakcji niezależnie od dostępności repliki obliczeniowej. Zakres przestoju z powodu niedostępności repliki podstawowej zależy od typu trybu failover (planowanego, a nieplanowanego), czy jest skonfigurowana nadmiarowość strefy, oraz obecność co najmniej jednej repliki o wysokiej dostępności. W przypadku planowanego przejścia w tryb failover (tj. zdarzenia konserwacji) system tworzy nową replikę podstawową przed zainicjowaniem trybu failover lub używa istniejącej repliki o wysokiej dostępności jako elementu docelowego trybu failover. W nieplanowanym trybie failover (tj. awarii sprzętowej repliki podstawowej) system używa repliki o wysokiej dostępności jako elementu docelowego trybu failover, jeśli istnieje, lub tworzy nową replikę podstawową z puli dostępnej pojemności obliczeniowej. W drugim przypadku czas trwania przestoju jest dłuższy ze względu na dodatkowe kroki wymagane do utworzenia nowej repliki podstawowej.

Aby zapoznać się z umową SLA w warstwie Hiperskala, zobacz Umowa SLA dla Azure SQL Database.

Tworzenie kopii zapasowej 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 hiperskala wykorzystuje warstwę magazynu do tworzenia kopii zapasowych i przywracania, obciążenie przetwarzania i wpływ wydajności na repliki obliczeniowe są znacznie zmniejszone. Dowiedz się więcej w temacie Tworzenie kopii zapasowych w warstwie Hiperskala i nadmiarowość magazynu.

Odzyskiwanie po awarii dla baz danych w warstwie Hiperskala

Jeśli musisz przywrócić bazę danych w warstwie Hiperskala w Azure SQL Database do regionu innego niż aktualnie hostowany, w ramach operacji odzyskiwania po awarii lub przechodzenia do szczegółów, relokacji lub innej przyczyny, podstawowa metoda polega na przywróceniu geograficznej bazy danych. Przywracanie geograficzne jest dostępne tylko wtedy, gdy magazyn geograficznie nadmiarowy (RA-GRS) został wybrany do nadmiarowości magazynu.

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

Dostępne regiony

Warstwa Azure SQL Database Hiperskala jest włączona w zdecydowanej większości regionów platformy Azure. Jeśli chcesz utworzyć bazę danych hiperskala w regionie, w którym hiperskala nie jest domyślnie włączona, możesz wysłać żądanie dołączania za pośrednictwem Azure Portal. Aby uzyskać instrukcje, zobacz Request quota increases for Azure SQL Database (Zwiększenie limitu przydziału żądań dla Azure SQL Database). Podczas przesyłania żądania użyj następujących wskazówek:

  • Użyj typu limitu przydziału SQL Database dostęp do regionu.
  • W opisie dodaj jednostkę SKU/łączną liczbę rdzeni obliczeniowych, w tym wysoką dostępność i nazwane repliki, i wskaż, że żądasz pojemności hiperskala.
  • Określ również projekcję całkowitego rozmiaru wszystkich baz danych w czasie w TB.

Znane ograniczenia

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

Problem Description
Przechowywanie kopii zapasowych wynosi obecnie siedem dni; Zasady przechowywania długoterminowego nie są jeszcze obsługiwane. Hiperskala ma unikatową metodę zarządzania kopiami zapasowymi, więc nie można przywrócić bazy danych w warstwie Hiperskala jako bazy danych w warstwie Hiperskala, a baza danych hiperskala nie może zostać przywrócona jako baza danych innej niż Hiperskala.

W przypadku baz danych migrowanych do hiperskala z innych warstw usług Azure SQL Database kopie zapasowe przed migracją są przechowywane przez okres przechowywania kopii zapasowych źródłowej bazy danych, w tym zasady przechowywania długoterminowego. Przywracanie kopii zapasowej przed migracją w okresie przechowywania kopii zapasowej bazy danych jest obsługiwane programowo. Te kopie zapasowe można przywrócić do dowolnej warstwy usługi innej niż Hiperskala.
Zmiana warstwy usługi z warstwy Hiperskala na inną warstwę nie jest obsługiwana bezpośrednio Migracja odwrotna do warstwy usług Ogólnego przeznaczenia umożliwia klientom, którzy niedawno zmigrowali istniejącą bazę danych w Azure SQL Database do warstwy usługi Hiperskala, aby powrócić w nagłych wypadkach, jeśli hiperskala nie spełnia swoich potrzeb. Podczas gdy migracja odwrotna jest inicjowana przez zmianę warstwy usługi, zasadniczo jest to przenoszenie danych o rozmiarze między różnymi architekturami. Bazy danych utworzone w warstwie usługi Hiperskala nie kwalifikują się do migracji odwrotnej. Poznaj ograniczenia dotyczące migracji odwrotnej.

W przypadku baz danych, które nie kwalifikują się do migracji odwrotnej, jedynym sposobem migracji z warstwy hiperskala do warstwy usługi innej niż Hiperskala jest eksportowanie/importowanie przy użyciu pliku bacpac lub innych technologii przenoszenia danych (Kopiowanie zbiorcze, Azure Data Factory, Azure Databricks, SSIS itp.) Program Bacpac export/import from Azure Portal, from PowerShell using New-AzSqlDatabaseExport or New-AzSqlDatabaseImport, from Azure CLI using az sql db export and az sql db import, and from REST API is not supported. Importowanie/eksportowanie pliku Bacpac dla mniejszych baz danych w warstwie Hiperskala (do 200 GB) jest obsługiwane przy użyciu programów SSMS i SqlPackage w wersji 18.4 lub nowszej. W przypadku większych baz danych eksportowanie/importowanie pliku bacpac może zająć dużo czasu i może zakończyć się niepowodzeniem z różnych powodów.
Podczas zmiany warstwy usługi Azure SQL Database na Hiperskala operacja kończy się niepowodzeniem, jeśli baza danych ma pliki danych większe niż 1 TB W niektórych przypadkach może być możliwe obejście tego problemu przez zmniejszenie rozmiaru dużych plików o mniej niż 1 TB przed próbą zmiany warstwy usługi na hiperskala. Użyj następującego zapytania, aby określić bieżący rozmiar plików bazy danych. SELECT file_id, name AS file_name, size * 8. / 1024 / 1024 AS file_size_GB FROM sys.database_files WHERE type_desc = 'ROWS';
Wystąpienie zarządzane SQL Azure SQL Managed Instance nie jest obecnie obsługiwane w przypadku baz danych w warstwie Hiperskala.
Pule elastyczne Pule elastyczne nie są obecnie obsługiwane w warstwie Hiperskala.
Migracja baz danych z obiektami OLTP In-Memory Hiperskala obsługuje podzestaw obiektów OLTP In-Memory, w tym typy tabel zoptymalizowane pod kątem pamięci, zmienne tabeli i moduły skompilowane natywnie. Jeśli jednak w migrowanej bazie danych znajdują się obiekty OLTP In-Memory, migracja z warstw usług Premium i Krytyczne dla działania firmy do warstw hiperskala nie jest obsługiwana. Aby przeprowadzić migrację takiej bazy danych do warstwy Hiperskala, należy usunąć wszystkie obiekty OLTP In-Memory i ich zależności. Po przeprowadzeniu migracji bazy danych te obiekty można odtworzyć. Trwałe i nietrwałe tabele zoptymalizowane pod kątem pamięci nie są obecnie obsługiwane w warstwie Hiperskala i muszą zostać zmienione na tabele dysków.
Replikacja geograficzna Replikacja geograficzna i grupy automatycznego trybu failover w warstwie Hiperskala są teraz dostępne w publicznej wersji zapoznawczej.
Inteligentne funkcje bazy danych Z wyjątkiem opcji "Wymuś plan" wszystkie inne opcje automatycznego dostrajania nie są jeszcze obsługiwane w warstwie Hiperskala: opcje mogą być włączone, ale nie będzie żadnych zaleceń ani akcji.
Analiza wydajności zapytań Wydajność zapytań Szczegółowe informacje nie jest obecnie obsługiwana w przypadku baz danych w warstwie Hiperskala.
Zmniejszanie bazy danych Baza danych DBCC SHRINKDATABASE lub DBCC SHRINKFILE nie jest obecnie obsługiwana w przypadku baz danych w warstwie Hiperskala.
Sprawdzanie integralności bazy danych Baza danych DBCC CHECKDB nie jest obecnie obsługiwana w przypadku baz danych w warstwie Hiperskala. DBCC CHECKTABLE ('TableName') WITH TABLOCK i DBCC CHECKFILEGROUP WITH TABLOCK może być używany jako obejście. Aby uzyskać szczegółowe informacje na temat zarządzania integralnością danych w Azure SQL Database, zobacz Integralność danych w Azure SQL Database.
Zadania elastyczne Skorzystaj z bazy danych w hiperskali, ponieważ baza danych zadań nie jest obsługiwana. Jednak zadania elastyczne mogą być przeznaczone dla baz danych w warstwie Hiperskala w taki sam sposób, jak każda inna baza danych w Azure SQL Database.
Synchronizacja danych Używanie bazy danych hiperskala jako bazy danych centrum lub metadanych synchronizacji nie jest obsługiwane. Jednak baza danych hiperskala może być bazą danych składowych w topologii Data Sync.
Importowanie i eksportowanie usługa Import-Export nie jest obecnie obsługiwana w przypadku baz danych w warstwie Hiperskala.

Następne kroki

Dowiedz się więcej o hiperskalach w Azure SQL Database w następujących artykułach: