Sdílet prostřednictvím


Horizontální navýšení kapacity s Azure SQL Database

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:

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ě sady horizontálních oddílů.
  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 pro rozdělení sloučení slouží k přesunu dat z jednoho horizontálního oddílu do druhého.
  6. Dotaz elastické databáze umožňuje napsat dotaz, který zahrnuje všechny databáze v sadě horizontálních oddílů.
  7. Elastické transakce umožňují spouštět transakce, které zahrnují několik databází.

Diagram nástrojů elastické databáze

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:

  • Rostoucí a zmenšující se kapacita pro část relační databáze vaší úlohy
  • Správa hotspotů, které můžou nastat, ovlivňuje určitou podmnožinu dat – například zaneprázdněného koncového zákazníka (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í.

Diagram vysvětlující horizontální a vertikální horizontální navýšení kapacity

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 pomocí horizontálního škálování zřizovat nové koncové zákazníky a vertikální škálování, aby databáze jednotlivých koncových zákazníků mohla podle potřeby zvětšit nebo zmenšit prostředky podle potřeby.

  • 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íceklient a jeden tenant

Některé aplikace používají nejjednodušší přístup k vytvoření samostatné databáze pro každého tenanta. Tento přístup představuje model horizontálního dělení jednoho tenanta, který poskytuje izolaci, schopnost zálohování/obnovení a škálování prostředků v členitosti tenanta. S horizontálním dělením jednoho tenanta je každá databáze přidružená ke konkrétní hodnotě ID tenanta (nebo hodnotě klíče zákazníka), ale tento klíč nemusí být 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.

Diagram jednoho tenanta a víceklientů

Jiné scénáře zabalí více tenantů do databází a neizolují je do samostatných databází. Tento model je typický model horizontálního dělení s více tenanty – a může to být řízené skutečností, že aplikace spravuje velký počet malých tenantů. V případě víceklientských horizontálních oddílů jsou řádky v tabulkách databáze navržené tak, aby přenášely klíč identifikující ID tenanta nebo klíč horizontálního dělení. 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 vzorech návrhu pro aplikace SaaS využívající elastické fondy najdete v tématu Vzory tenantů databáze 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í nástroje pro rozdělení sloučení přesuňte data z víceklienta do nové databáze s jedním tenantem.

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.

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.