Hyperškálování úrovně služby

  • Článek
  • 15 min ke čtení

PLATÍ PRO: Azure SQL Database

Azure SQL Database je založená na architektuře databázového stroje SQL Server upravenou pro cloudové prostředí, aby se zajistila 99,99% dostupnost i v případě selhání infrastruktury. Existují tři modely architektury, které se používají v Azure SQL Database:

  • Pro obecné účely/Standard
  • Hyperškálování
  • Pro důležité obchodní informace/Premium

Úroveň služby Hyperscale v Azure SQL Database je nejnovější úrovní služby v nákupním modelu založeném na virtuálních jade. Tato úroveň služby je vysoce škálovatelná úroveň výkonu úložiště a výpočetních prostředků, která využívá architekturu Azure ke škálování prostředků úložiště a výpočetních prostředků pro Azure SQL Database podstatně nad rámec limitů dostupných pro úrovně služby Pro obecné účely a Pro důležité obchodní informace.

Poznámka

  • Podrobnosti o úrovních Pro obecné účely a Pro důležité obchodní informace v nákupním modelu založeném na virtuálních Pro obecné účely a Pro důležité obchodní informace služeb. Porovnání nákupního modelu založeného na virtuálních jade s nákupním modelem založeným na DTU najdete v Azure SQL Database nákupních modelůa prostředků.
  • Úroveň služby Hyperscale je aktuálně dostupná pouze pro Azure SQL Database, a ne pro Azure SQL Managed Instance.

Survey to improve Azure SQL!

Jaké jsou možnosti Hyperscale

Úroveň služby Hyperscale v Azure SQL Database nabízí následující další možnosti:

  • Podpora až 100 TB velikosti databáze
  • Téměř okamžité zálohy databáze (na základě snímků souborů uložených v úložišti objektů blob v Azure) bez ohledu na velikost, která nemá žádný vliv na V/V výpočetní prostředky
  • Rychlá obnovení databáze (na základě snímků souborů) v minutách, nikoli v hodinách nebo dnech (není to velikost datové operace)
  • Vyšší celkový výkon z důvodu vyšší propustnosti transakčního protokolu a rychlejší doby potvrzení transakcí bez ohledu na objemy dat
  • Rychlé horizontální navýšení velikosti – můžete zřídit jednu nebo více replik jen pro čtení pro snižování zátěže čtení a pro použití jako aktivní pohotovostní server.
  • Rychlé škálování nahoru – v konstantním čase můžete v případě potřeby škálovat výpočetní prostředky tak, aby vyhovovaly náročnému zatížení, a pak škálovat výpočetní prostředky zpět, když to není potřeba.

Úroveň služby Hyperscale odstraňuje mnoho praktických limitů, které se v cloudových databázích tradičně odchytá. Pokud je většina ostatních databází omezená prostředky dostupnými v jednom uzlu, nemají databáze na úrovni služby Hyperscale žádná taková omezení. Díky flexibilní architektuře úložiště roste úložiště podle potřeby. Ve skutečnosti se databáze Hyperscale nevy vytvářejí s definovanou maximální velikostí. Databáze Hyperscale roste podle potřeby a účtuje se vám jenom kapacita, kterou využíváte. U úloh náročných na čtení poskytuje úroveň služby Hyperscale rychlé škálování na více než 1, protože podle potřeby zřizuje další repliky pro snižování zátěže čtení.

Kromě toho se čas potřebný k vytvoření záloh databáze nebo škálování nahoru nebo dolů už neváže k objemu dat v databázi. Databáze Hyperscale je možné zálohovat prakticky okamžitě. Databázi můžete také během několika minut škálovat o desítky terabajtů nahoru nebo dolů. Díky této funkci se už obavy o počáteční volby konfigurace netýká.

Další informace o velikostech výpočetních prostředků pro úroveň služby Hyperscale najdete v tématu Charakteristiky úrovně služby.

Kdo byste zvážit úroveň služby Hyperscale.

Úroveň služby Hyperscale je určená pro většinu obchodních úloh, protože poskytuje velkou flexibilitu a vysoký výkon s nezávisle škálovatelnými výpočetními prostředky a prostředky úložiště. Díky možnosti automatického škálování úložiště až na 100 TB je to skvělá volba pro zákazníky, kteří:

  • Místní rozsáhlé databáze a chtějí modernizovat své aplikace přechodem do cloudu
  • Jsou již v cloudu a jsou omezeny maximálními omezeními velikosti databáze jiných úrovní služby (1 až 4 TB).
  • Mají menší databáze, ale vyžadují rychlé vertikální a horizontální škálování výpočetních prostředků, vysoký výkon, okamžité zálohování a rychlé obnovení databáze.

Úroveň služby Hyperscale podporuje širokou škálu úloh SQL Server, od čistého OLTP až po čistou analýzu, ale je primárně optimalizovaná pro ÚLOHY OLTP a HTAP (Hybrid Transaction and Analytical Processing).

Důležité

Elastické fondy nepodporují úroveň služby Hyperscale.

Cenový model Hyperscale

Úroveň služby Hyperscale je dostupná jenom v modelu virtuálních jadek. V souladu s novou architekturou se cenový model mírně liší od cenových úrovní Pro obecné účely Pro důležité obchodní informace služeb:

  • Výpočetní prostředky:

    Cena za výpočetní jednotku Hyperscale je 1 replika. Cena Zvýhodněné hybridní využití Azure se automaticky použije na vysoce dostupné a pojmenované repliky. Ve výchozím nastavení pro každou databázi Hyperscale vytvoříme primární repliku a jednu sekundární repliku s vysokou dostupností. Uživatelé mohou upravit celkový počet replik s vysokou dostupností od 0 do 4 v závislosti na potřebnésla.

  • Storage:

    Při konfiguraci databáze Hyperscale nemusíte zazadat maximální velikost dat. Na úrovni hyperšálování se vám účtuje úložiště pro vaši databázi na základě skutečného přidělení. Storage se automaticky přidělí mezi 40 GB a 100 TB v přírůstcích po 10 GB. V případě potřeby se může současně zvětšovat více datových souborů. Vytvoří se databáze Hyperscale o počáteční velikosti 10 GB a začne každých 10 minut růst o 10 GB, dokud nedosáhne velikosti 40 GB.

Další informace o cenách Hyperscale najdete v tématu Azure SQL Database ceny.

Architektura distribuovaných funkcí

Na rozdíl od tradičních databázových strojů, které centralizovaly všechny funkce správy dat v jednom umístění nebo procesu (i takzvané distribuované databáze v produkčním prostředí mají dnes více kopií monolitického datového stroje), odděluje databáze Hyperscale modul pro zpracování dotazů, kde se sémantika různých datových modulů liší od komponent, které poskytují dlouhodobé ukládání a stálost dat. Tímto způsobem je možné kapacitu úložiště plynule škálovat podle potřeby (počáteční cíl je 100 TB). Vysoká dostupnost a pojmenované repliky sdílejí stejné součásti úložiště, takže ke zduplikování nové repliky se nevyžaduje kopírování dat.

Následující diagram znázorňuje různé typy uzlů v databázi Hyperscale:

Architektura

Databáze Hyperscale obsahuje následující různé typy komponent:

Compute

Na výpočetním uzlu se nachází relační modul. Tady dochází ke zpracování jazyka, dotazu a transakce. Všechny interakce uživatelů s databází Hyperscale procházou prostřednictvím těchto výpočetních uzlů. Výpočetní uzly mají mezipaměti ssd (na předchozím diagramu označené jako RBPEX – Odolné rozšíření fondu vyrovnávacích pamětí), aby se minimalizoval počet síťových přenosů nutných k načtení stránky dat. Existuje jeden primární výpočetní uzel, ve kterém se zpracovávají všechny úlohy a transakce pro čtení i zápis. Existuje jeden nebo několik sekundárních výpočetních uzlů, které pro účely převzetí služeb při selhání vystupují jako aktivní pohotovostní uzly a také jako výpočetní uzly jen pro čtení pro snižování zátěže čtení (pokud je tato funkce požadovaná).

Databázový stroj běžící na výpočetních uzlech Hyperscale je stejný jako v jiných Azure SQL Database úrovních služby. Když uživatelé pracují s databázovým strojem na výpočetních uzlech Hyperscale, je podporované chování plochy a modulu stejné jako u jiných úrovní služby s výjimkou známých omezení.

Stránkový server

Stránkovací servery jsou systémy, které představují modul úložiště s horizontálním navýšením velikosti. Každý stránkový server zodpovídá za podmnožinu stránek v databázi. Nomálně každý stránkový server řídí až 128 GB nebo až 1 TB dat. Na více než jednom stránkačním serveru (mimo repliky stránkového serveru, které se kvůli redundanci a dostupnosti uchovávají) se nesměšují žádná data. Úkolem stránkového serveru je obsluhovat databázové stránky výpočetním uzlům na vyžádání a udržovat stránky aktualizované při aktualizaci dat transakcí. Stránkové servery se uchovávají v aktuálních stavu přehráváním záznamů transakčních protokolů ze služby protokolů. Stránkové servery také udržují pokrytí mezipamětí založených na discích SSD, aby se zvýšil výkon. Dlouhodobé ukládání datových stránek se uchovávají v Azure Storage pro zvýšení spolehlivosti.

Protokolová služba

Služba protokolu přijímá záznamy transakčních protokolů z primární výpočetní repliky, uchová je v odolné mezipaměti a předává záznamy protokolů zbývajícím výpočetním replikám (aby mohli aktualizovat své mezipaměti) a příslušné stránkové servery, aby se tam data aktualizovala. Tímto způsobem se všechny změny dat z primární výpočetní repliky rozšíří prostřednictvím služby protokolu na všechny sekundární výpočetní repliky a stránkovací servery. Nakonec se záznamy transakčních protokolů předá do dlouhodobého úložiště v Azure Storage, což je prakticky nekonečné úložiště úložiště. Tento mechanismus eliminuje potřebu častého zkušení protokolu. Služba protokolů má také místní paměť a mezipaměti SSD pro urychlení přístupu k záznamům protokolu. Přihlášení k hyperšálování je prakticky nekonečné s omezením, že jedna transakce nemůže vygenerovat více než 1TB protokolu.

Azure Storage

Azure Storage obsahuje všechny datové soubory v databázi. Stránkové servery udržují datové soubory Azure Storage aktuální. Toto úložiště se používá pro účely zálohování a také pro replikaci mezi oblastmi Azure. Zálohy se implementuje pomocí snímků úložiště datových souborů. Operace obnovení pomocí snímků jsou rychlé bez ohledu na velikost dat. Data je možné obnovit k libovolnému bodu v čase v rámci doby uchovávání záloh databáze.

Zálohování a obnovení

Zálohy jsou založené na snímcích souborů, a proto jsou téměř okamžité. Storage a výpočetních prostředků umožňuje nasazování operace zálohování a obnovení do vrstvy úložiště, aby se snížilo zatížení primární výpočetní repliky zpracováním. V důsledku toho zálohování databáze nemá vliv na výkon primárního výpočetního uzlu. Obnovení k bodu v čase se podobně provádí vrácením snímků souborů, takže to není velikost datové operace. Obnovení databáze v rámci škálování databáze ve stejné oblasti Azure je operace s konstantním časem a dokonce i více než jeden z nich může být obnoveno v řádu minut, nikoli hodin nebo dnů. Vytvoření nových databází obnovením existující zálohy také využívá tuto funkci: vytváření kopií databáze pro účely vývoje nebo testování, dokonce i z databází s více terabajty, je doable během několika minut.

Informace o geografickém obnovení databází s škálovatelným škálováním najdete v tématu obnovení databáze v rámci škálování do jiné oblasti.

Výhody škálování a výkonu

Díky možnosti rychlého zprovoznění dalších výpočetních uzlů jen pro čtení a architektury škálování je možné využít významné možnosti škálování pro čtení a můžou také uvolnit primární výpočetní uzel pro poskytování dalších požadavků na zápis. Také je možné rychle škálovat nebo snížit kapacitu výpočetních uzlů v důsledku architektury sdíleného úložiště architektury s architekturou škálování.

Vytvoření databáze s škálovatelným škálováním

databázi škálování na více systému je možné vytvořit pomocí Azure Portal, T-SQL, powershellunebo rozhraní příkazového řádku. Databáze s škálovatelným škálováním jsou dostupné jenom pomocí nákupního modelu založeného na Vcore.

následující příkaz T-SQL vytvoří databázi s měřítkem. V příkazu je nutné zadat jak edici, tak i cíl služby CREATE DATABASE . Seznam platných cílů služeb najdete v tématu omezení prostředků .

-- Create a Hyperscale Database
CREATE DATABASE [HyperscaleDB1] (EDITION = 'Hyperscale', SERVICE_OBJECTIVE = 'HS_Gen5_4');
GO

Tím se vytvoří databáze s Gen5 na hardwaru se čtyřmi jádry.

Upgrade existující databáze na škálovatelný

stávající databáze můžete v Azure SQL Database přesunout do škálování pomocí Azure Portal, T-SQL, powershellunebo rozhraní příkazového řádku. Tato možnost je v současnosti jednosměrnou migrací. Databáze nemůžete přesouvat z škálování na jinou úroveň služby, a to i z exportu a importu dat. V případě potřeby konceptu (POCs) doporučujeme vytvořit kopii produkčních databází a migrovat kopii do škálování na velká. migrace stávající databáze v Azure SQL Database do vrstvy škálování je velikost datové operace.

následující příkaz T-SQL přesune databázi do vrstvy služby s škálováním na úrovni služeb. V příkazu je nutné zadat jak edici, tak i cíl služby ALTER DATABASE .

-- Alter a database to make it a Hyperscale Database
ALTER DATABASE [DB2] MODIFY (EDITION = 'Hyperscale', SERVICE_OBJECTIVE = 'HS_Gen5_4');
GO

Poznámka

Pokud chcete přesunout databázi, která je součástí vztahu geografické replikace , jako je primární nebo sekundární, do škálování, musíte zastavit replikaci. Databáze ve skupině převzetí služeb při selhání se musí nejdřív odebrat ze skupiny.

Po přesunutí databáze do škálování můžete pro tuto databázi vytvořit novou geografickou repliku s měřítkem. Geografická replikace pro škálování na více verzí je ve verzi Preview s určitými omezeními.

Vysoká dostupnost databáze v měřítku

Stejně jako u všech ostatních úrovní služeb zajišťuje ochranná škála odolnost dat pro potvrzené transakce bez ohledu na dostupnost repliky Compute. Rozsah výpadku, který se stane nedostupnou primární replikou, závisí na typu převzetí služeb při selhání (plánované vs. neplánované) a na přítomnosti alespoň jedné repliky s vysokou dostupností. V plánovaném převzetí služeb při selhání (tj. události údržby) systém buď vytvoří novou primární repliku před spuštěním převzetí služeb při selhání, nebo jako cíl převzetí služeb při selhání použije stávající repliku s vysokou dostupností. V neplánovaném převzetí služeb při selhání (tj. selhání hardwaru primární repliky) systém používá repliku s vysokou dostupností jako cíl převzetí služeb při selhání, pokud existuje, nebo vytvoří novou primární repliku z fondu dostupné výpočetní kapacity. V druhém případě je doba výpadku delší než v důsledku dalších kroků potřebných k vytvoření nové primární repliky.

Informace o smlouvě SLA pro škálování na úrovni najdete v tématu SLA pro Azure SQL Database.

Zotavení po havárii pro databáze s škálovatelným škálováním

Obnovení databáze v rámci škálování na jiné oblasti

pokud potřebujete obnovit databázi v prostředí Azure SQL Database do jiné oblasti, než je ta, která je aktuálně hostovaná v rámci operace zotavení po havárii, přemístění, přemístění nebo jakéhokoli jiného důvodu, je primární metodou provést geografickou obnovu databáze. to zahrnuje přesně stejný postup jako v případě, že byste použili k obnovení jakékoli jiné databáze v SQL Database do jiné oblasti:

  1. Pokud ještě nemáte příslušný server, vytvořte Server v cílové oblasti. Tento server by měl vlastnit stejné předplatné jako původní (zdrojový) Server.
  2. postupujte podle pokynů uvedených v tématu geografické obnovení stránky stránky při obnovení databáze v Azure SQL Database z automatických záloh.

Poznámka

Vzhledem k tomu, že zdroj a cíl jsou v samostatných oblastech, nemůže databáze sdílet snímkové úložiště se zdrojovou databází jako v negeografických obnoveních, což dokončí rychle bez ohledu na velikost databáze. V případě geografického obnovení databáze s měřítkem dat se bude jednat o velikost operace, i když je cíl v spárované oblasti geograficky replikovaného úložiště. Proto bude geografické obnovení trvat v čase úměrné velikosti obnovené databáze. Pokud je cíl v spárované oblasti, přenos dat bude v rámci oblasti, která bude výrazně rychlejší než přenos dat mezi oblastmi, ale bude stále i operací velikosti dat.

Dostupné oblasti

Azure SQL Databaseá úroveň škálování je povolená v převážné většině oblastí Azure. Pokud chcete vytvořit databázi v rámci škálování na úrovni služby v oblasti, ve které není ve výchozím nastavení povolené škálování na úrovni služby, můžete odeslat požadavek na registraci prostřednictvím Azure Portal. pokyny najdete v tématu zvýšení kvóty žádostí o Azure SQL Database . Při odesílání vaší žádosti postupujte podle následujících pokynů:

  • použijte typ kvóty SQL Database přístupu k oblasti .
  • V popisu přidejte výpočetní SKU/celkový počet jader, včetně vysoce dostupných a pojmenovaných replik, a určete, že požadujete kapacitu s měřítkem.
  • Také zadejte projekci celkové velikosti všech databází v čase v TB.

Známá omezení

Jedná se o aktuální omezení úrovně služby škálování na úrovni služeb (GA). Aktivně pracujeme na odebrání tolika těchto omezení, co je možné.

Problém Description
Podokno Správa zálohování serveru nezobrazuje databáze s škálovatelnými škálováními. Budou filtrovány ze zobrazení. Vlastní škálování má samostatnou metodu pro správu záloh, takže nastavení uchovávání Long-Term a nastavení uchovávání záloh v určitém časovém okamžiku neplatí. Proto se databáze s škálovatelným škálováním nezobrazí v podokně Správa zálohování.

pro databáze migrované do škálování z jiných Azure SQL Database úrovní služeb se zálohy před migrací uchovávají po dobu uchovávání záloh zdrojové databáze. Tyto zálohy lze použít k obnovení zdrojové databáze k určitému bodu v čase před migrací.
Obnovení k určitému bodu v čase Nemůžete obnovit databázi s neškálovatelným škálováním jako databázi s škálovatelnými škálováními a databázi s měřítkem ve formátu. V případě databáze bez škálování na úrovni služby, která byla migrována do škálování, změnou její úrovně služeb, obnovení do bodu v čase před migrací a v rámci doby uchovávání záloh databáze je programověpodporována. Obnovená databáze nebude škálovatelná.
při změně Azure SQL Database úrovně služby na škálovatelné, operace dojde k chybě, pokud má databáze nějaké datové soubory větší než 1 TB. V některých případech je možné tento problém obejít tak, že velké soubory zmenšíte na méně než 1 TB předtím, než se pokusíte změnit úroveň služby na škálování. Pomocí následujícího dotazu určete aktuální velikost databázových souborů. SELECT file_id, name AS file_name, size * 8. / 1024 / 1024 AS file_size_GB FROM sys.database_files WHERE type_desc = 'ROWS';
Spravovaná instance SQL Azure SQL Managed Instance se v současnosti nepodporuje u databází s podporou škálování na více instancí.
Elastické fondy Elastické fondy se v současné době nepodporují s měřítkem.
Migrace do škálování je momentálně jednosměrnou operací. Jakmile se databáze migruje do škálování, nejde ji migrovat přímo na úroveň služby, která není na úrovni služby. V současné době jediný způsob, jak migrovat databázi z velkého měřítka do neškálovatelného škálování, je exportovat a importovat pomocí souboru BacPac nebo jiných technologií pro přesun dat (hromadné kopírování, Azure Data Factory, Azure Databricks, SSIS atd.). BacPac exportujte/Azure Portal importujte z prostředí PowerShell pomocí rutiny New-AzSqlDatabaseExport nebo New-AzSqlDatabaseImportz Azure CLI pomocí příkazového řádku AZ SQL DB export a AZ SQL DB importa z REST API se nepodporuje. Import/export BacPac pro menší databáze s více škálováními (až 200 GB) se podporuje pomocí SSMS a SqlPackage verze 18,4 a novější. Pro větší databáze může BacPac export/import trvat delší dobu a může dojít k selhání z různých důvodů.
Migrace databází s In-Memory objekty OLTP Měřítko podporuje podmnožinu objektů In-Memory OLTP, včetně paměťově optimalizovaných typů tabulek, proměnných tabulky a nativně kompilovaných modulů. pokud se ale v databázi, kterou migrujete, vyskytuje libovolný druh In-Memory objektů OLTP, migrace z Premium a Pro důležité obchodní informace úrovně služeb do škálování není podporovaná. Chcete-li migrovat takovou databázi do škálování, je nutné vyřadit všechny In-Memory objekty OLTP a jejich závislosti. Po migraci databáze je možné tyto objekty znovu vytvořit. Odolné a netrvanlivé paměťově optimalizované tabulky se v současné době nepodporují a musí se měnit na diskové tabulky.
Geografická replikace Geografická replikace na úrovni cloudu je teď ve verzi Public Preview.
Funkce inteligentní databáze S výjimkou možnosti "vynutit plán" nejsou všechny ostatní možnosti automatického ladění zatím podporovány v rámci škálování: možnosti mohou být povoleny, ale nebudou zde učiněna žádná doporučení ani akce.
Query Performance Insights Přehledy výkonu dotazů se v současné době nepodporuje u databází s podporou škálování.
Zmenšit databázi Příkaz DBCC SHRINKDATABASE nebo DBCC SHRINKFILE není aktuálně podporován pro databáze s měřítkem.
Kontrola integrity databáze Příkaz DBCC CHECKDB není v současné době podporován pro databáze s měřítkem. Příkaz DBCC CHECKTABLE ("TableName") s byla TABLOCK a DBCC CHECKFILEGROUP WITH byla TABLOCK lze použít jako alternativní řešení. podrobnosti o správě Integrity dat v Azure SQL Database najdete v tématu integrita dat v Azure SQL Database .
Elastické úlohy Použití databáze v rámci škálování na úrovni databáze se nepodporuje. elastické úlohy ale můžou cílit na databáze ve formátu velkého rozsahu stejným způsobem jako jakékoli jiné databáze služby Azure SQL.

Další kroky

  • Nejčastější dotazy k Hyperscale najdete v nejčastějších dotazech k Hyperscale.
  • Informace o úrovních služby najdete v tématu Úrovně služeb.
  • Informace o omezeních na úrovni serveru a předplatného najdete v tématu Přehled omezení prostředků na serveru.
  • Informace o omezeních nákupního modelu pro jednu databázi najdete Azure SQL Database nákupního modelu založeného na virtuálních jade pro jednu databázi.
  • Seznam funkcí a porovnání najdete v tématu SQL běžné funkce.