Škálování s Azure SQL databází

Platí pro:Azure SQL Database

Databáze ve službě Azure SQL Database můžete snadno škálovat pomocí nástrojů elastické databáze . Tyto nástroje a funkce umožňují používat databázové prostředky služby Azure SQL Database k vytváření řešení pro transakční úlohy a zejména aplikace Typu software jako služba (SaaS). Funkce elastické databáze se skládají z těchto:

• Klientská knihovna Elastic Database: Klientská knihovna je funkce, která umožňuje vytvářet a udržovat horizontálně dělené databáze. Vizte Začínáme s nástroji Elastic Database Tools.
• Přesun dat mezi škálovanými cloudovými databázemi: přesouvá data mezi databázemi rozdělenými na fragmenty. Tento nástroj je užitečný pro přesun dat z víceklientských databází do databáze s jedním tenantem (nebo naopak). Podívejte se na Nasazení služby pro rozdělení a sloučení pro přesun dat mezi horizontálně dělenými databázemi.
• Elastické úlohy ve službě Azure SQL Database: Používejte úlohy ke správě velkého počtu databází ve službě Azure SQL Database. Snadno provádět operace správy, jako jsou změny schématu, správa přihlašovacích údajů, aktualizace referenčních dat, shromažďování dat o výkonu nebo shromažďování telemetrie tenanta (zákazníka) pomocí úloh.
• Přehled elastických dotazů Azure SQL Database (Preview) (Preview): Umožňuje spustit dotaz Transact-SQL, který zahrnuje více databází. To umožňuje připojení k nástrojům pro vytváření sestav, jako jsou Excel, Power BI, Tableau atd.
• Distribuované transakce napříč cloudovými databázemi: Tato funkce umožňuje spouštět transakce, které zahrnují několik databází. Transakce elastické databáze jsou k dispozici pro aplikace .NET pomocí ADO .NET a integrují se se známým programovacím prostředím pomocí třídy System.Transaction.

Následující obrázek znázorňuje architekturu, která zahrnuje funkce elastické databáze ve vztahu k kolekci databází.

V tomto obrázku představují barvy databáze schémata. Databáze se stejnou barvou sdílejí stejné schéma.

1. Sada databází SQL je hostovaná v Azure pomocí architektury horizontálního dělení.
2. Klientská knihovna Elastic Database slouží ke správě shardů.
3. Podmnožina databází se vloží do elastického fondu.
4. Úloha elastické databáze spouští skripty T-SQL pro všechny databáze.
5. Nástroj rozdělení a sloučení se používá k přesunu dat z jednoho shardu do druhého.
6. Dotaz Elastic Database Query umožňuje napsat dotaz, který zahrnuje všechny databáze v shardovací sadě.
7. Elastické transakce umožňují spouštět transakce, které zahrnují několik databází.

Proč používat nástroje?

Dosažení elasticity a škálování cloudových aplikací je jednoduché pro virtuální počítače a úložiště objektů blob – jednoduše sčítat nebo odečítat jednotky nebo zvýšit výkon. Ale stále se jedná o výzvu pro stavové zpracování dat v relačních databázích. V těchto scénářích se objevily výzvy:

• Zvětšující se a zmenšující se kapacita pro relační databázovou část vaší úlohy
• Správa hotspotů, které mohou vzniknout a ovlivnit konkrétní podmnožinu dat – například zaneprázdněného nájemce (tenanta).

Scénáře podobné těmto scénářům se tradičně řeší tím, že investují do rozsáhlejších serverů na podporu aplikace. Tato možnost je však omezena v cloudu, kde se veškeré zpracování provádí na předdefinovaném komoditních hardwaru. Distribuce dat a zpracování napříč mnoha identickými strukturovanými databázemi (model horizontálního navýšení kapacity označovaný jako horizontální dělení) nabízí alternativu k tradičním přístupům vertikálního navýšení kapacity z hlediska nákladů i elasticity.

Horizontální a vertikální škálování

Následující obrázek znázorňuje vodorovné a svislé rozměry škálování, což jsou základní způsoby škálování elastických databází.

Horizontální škálování označuje přidání nebo odebrání databází za účelem přizpůsobení kapacity nebo celkového výkonu, označovaného také jako horizontální navýšení kapacity. Horizontální dělení dat v kolekci identicky strukturovaných databází představuje běžný způsob implementace horizontálního škálování.

Vertikální škálování označuje zvětšení nebo snížení velikosti výpočetních prostředků jednotlivých databází, označovaných také jako vertikální navýšení kapacity.

Většina databázových aplikací v cloudovém měřítku používá kombinaci těchto dvou strategií. Například aplikace Software jako služba může k zřizování nových koncových zákazníků využívat horizontální škálování, zatímco vertikální škálování umožňuje, aby databáze jednotlivých koncových zákazníků zvětšovala nebo zmenšovala prostředky podle potřeby pracovního zatížení.

• Horizontální škálování se spravuje pomocí klientské knihovny elastické databáze.
• Vertikální škálování se provádí pomocí rutin Azure PowerShellu ke změně úrovně služby nebo umístěním databází do elastického fondu.

Sharding

Horizontální dělení je technika distribuce velkých objemů identicky strukturovaných dat napříč mnoha nezávislými databázemi. Je obzvláště populární u cloudových vývojářů vytvářejících nabídky SAAS (Software as a Service) pro koncové zákazníky nebo firmy. Tito koncoví zákazníci se často označují jako "tenanti". Horizontální dělení se může vyžadovat z libovolného počtu důvodů:

• Celkové množství dat je příliš velké, aby se vešel do omezení jednotlivých databází.
• Propustnost transakcí celkové úlohy překračuje možnosti jednotlivých databází.
• Tenanti můžou vyžadovat fyzickou izolaci od sebe, takže pro každého tenanta jsou potřeba samostatné databáze.
• Různé části databáze se můžou muset nacházet v různých zeměpisných oblastech z důvodu dodržování předpisů, výkonu nebo geopolitických důvodů.

V jiných scénářích, jako je příjem dat z distribuovaných zařízení, lze horizontální dělení použít k naplnění sady databází, které jsou uspořádané dočasně. Samostatná databáze může být například vyhrazená pro každý den nebo týden. V takovém případě může být klíč horizontálního dělení celé číslo představující datum (přítomné ve všech řádcích horizontálně dělených tabulek) a dotazy, které načítají informace o rozsahu kalendářních dat, musí být směrovány aplikací do podmnožiny databází, které pokrývají daný rozsah.

Horizontální dělení funguje nejlépe, když může být každá transakce v aplikaci omezena na jednu hodnotu klíče horizontálního dělení. Tím zajistíte, že všechny transakce budou místní pro konkrétní databázi.

Víceuživatelský a jednouživatelský

Některé aplikace používají nejjednodušší přístup k vytvoření samostatné databáze pro každého tenanta. Tento přístup představuje vzor dělení pro jednoho nájemce, který poskytuje izolaci, schopnost zálohování/obnovení a škálování prostředků na úrovni nájemce. Při šardování s jedním tenantem je každá databáze přidružena ke konkrétní hodnotě ID tenanta (nebo hodnotě klíče zákazníka), přičemž tato hodnota nemusí být přítomna v samotných datech. Je zodpovědností aplikace směrovat každou žádost do příslušné databáze – a klientská knihovna může tuto úlohu zjednodušit.

Jiné scénáře zabalí více tenantů do databází a neizolují je do samostatných databází. Tento vzor je typickým vzorem horizontálního dělení s více tenanty – a může to být založeno na skutečnosti, že aplikace spravuje velký počet malých nájemců. V systému vícenájemního sharding jsou řádky v tabulkách databáze navrženy tak, aby obsahovaly klíč identifikující tenant ID nebo klíč shardování. Znovu platí, že aplikační vrstva zodpovídá za směrování žádosti tenanta do příslušné databáze a to může podporovat klientská knihovna elastické databáze. Kromě toho je možné použít zabezpečení na úrovni řádků k filtrování řádků, ke kterým má každý tenant přístup – podrobnosti najdete v tématu Víceklientských aplikací s nástroji elastické databáze a zabezpečením na úrovni řádků. Redistribuce dat mezi databázemi může být potřeba pomocí modelu horizontálního dělení s více tenanty a usnadňuje ho nástroj pro dělení elastické databáze. Další informace o návrhových vzorech pro SaaS aplikace využívající elastické pooly najdete v tématu Databázové vzory tenancy pro SaaS s více tenanty.

Přesun dat z více databází na jednoklientské databáze

Při vytváření aplikace SaaS je typické nabídnout potenciálním zákazníkům zkušební verzi softwaru. V tomto případě je nákladově efektivní použít víceklientovou databázi pro data. Když se ale potenciální zákazník stane zákazníkem, databáze s jedním tenantem je lepší, protože poskytuje lepší výkon. Pokud zákazník během zkušebního období vytvoří data, pomocí split-merge nástroje přesuňte data z víceklientské do nové jednoklientské databáze.

Poznámka:

Obnovení z víceklientských databází do jednoho tenanta není možné.

Ukázky a výukové programy

Ukázkovou aplikaci, která demonstruje klientskou knihovnu, najdete v tématu Začínáme s nástroji elastické databáze.

Pokud chcete převést existující databáze tak, aby používaly nástroje, přečtěte si téma Migrace existujících databází pro horizontální navýšení kapacity.

Pokud chcete zobrazit specifika elastického fondu, podívejte se na informace o cenách a výkonu elastického fondu nebo vytvořte nový fond s elastickými fondy.

Související obsah

Ještě nepoužíváte nástroje elastické databáze? Podívejte se na naši příručku Začínáme. Pokud máte dotazy, kontaktujte nás na stránce otázek Microsoft Q&A pro SLUŽBU SQL Database a žádosti o funkce, přidejte nové nápady nebo hlasujte pro stávající nápady ve fóru pro zpětnou vazbu ke službě SQL Database.