Vzory tenantů víceklientské databáze SaaS
Platí pro: 
Azure SQL Database
Tento článek popisuje různé modely tenantů, které jsou k dispozici pro víceklientské aplikace SaaS.
Při navrhování víceklientské aplikace SaaS musíte pečlivě zvolit model tenantů, který nejlépe vyhovuje potřebám vaší aplikace. Model tenantů určuje, jak se data jednotlivých tenantů mapují na úložiště. Váš výběr modelu tenantů má vliv na návrh a správu aplikací. Přechod na jiný model později je někdy nákladný.
A. Koncepty a terminologie SaaS
V modelu Software jako služba (SaaS) vaše společnost neprodává licence k vašemu softwaru. Místo toho každý zákazník provádí splátky pronájmu vaší společnosti, takže každý zákazník je tenantem vaší společnosti.
Za cenu placení pronájmu obdrží každý tenant přístup ke komponentám aplikace SaaS a má svá data uložená v systému SaaS.
Model tenantů označuje způsob uspořádání uložených dat tenantů:
- Jednoklientská architektura: Každá databáze ukládá data pouze z jednoho tenanta.
- Víceklientská architektura: Každá databáze ukládá data z více samostatných tenantů (s mechanismy pro ochranu osobních údajů dat).
- K dispozici jsou také hybridní modely tenantů.
B. Výběr vhodného modelu tenantů
Obecně platí, že model tenantů nemá vliv na funkci aplikace, ale pravděpodobně ovlivňuje další aspekty celkového řešení. K posouzení jednotlivých modelů se používají následující kritéria:
Škálovatelnost:
- Počet tenantů
- Úložiště pro jednotlivé tenanty
- Úložiště v agregaci.
- Pracovní zátěž.
Izolace tenanta: Izolace a výkon dat (jestli úloha jednoho tenanta ovlivňuje ostatní).
Náklady na tenanta: Náklady na databázi.
Složitost vývoje:
- Změny schématu
- Změny dotazů (vyžadované vzorem)
Provozní složitost:
- Monitorování a správa výkonu
- Správa schémat.
- Obnovení tenanta
- Zotavení po havárii.
Přizpůsobitelnost: Usnadnění podpory přizpůsobení schématu, která jsou specifická pro tenanta nebo pro konkrétní třídu tenanta.
Diskuze o tenantech se zaměřuje na datová vrstva. Chvíli ale zvažte aplikační vrstvu. Aplikační vrstva se považuje za monolitickou entitu. Pokud aplikaci rozdělíte na mnoho malých komponent, může se váš výběr modelu tenantů změnit. S některými komponentami můžete zacházet odlišně než s jinými, pokud jde o tenanty i použitou technologii úložiště nebo platformu.
C. Samostatná aplikace s jedním tenantem s databází s jedním tenantem
Izolace na úrovni aplikace
V tomto modelu se celá aplikace nainstaluje opakovaně, jednou pro každého tenanta. Každá instance aplikace je samostatná instance, takže nikdy nekomunikuje s žádnou jinou samostatnou instancí. Každá instance aplikace má pouze jednoho tenanta, a proto potřebuje jenom jednu databázi. Tenant má celou databázi.
Každá instance aplikace je nainstalovaná v samostatné skupině prostředků Azure. Buď dodavatel softwaru, nebo tenant může vlastnit předplatné, které vlastní skupinu prostředků. V obou případech může dodavatel spravovat software pro tenanta. Každá instance aplikace je nakonfigurovaná tak, aby se připojila k příslušné databázi.
Každá databáze tenanta se nasadí jako jedna databáze. Tento model poskytuje největší izolaci databáze. Izolace ale vyžaduje, aby se každému databázi přidělily dostatečné prostředky, aby zvládly zatížení ve špičce. V této části je důležité, aby elastické fondy nebylo možné použít pro databáze nasazené v různých skupinách prostředků nebo pro různá předplatná. Díky tomuto omezení je tento samostatný model aplikace s jedním tenantem nejnákladnější z hlediska celkových nákladů na databázi.
Správa dodavatelů
Dodavatel má přístup ke všem databázím ve všech samostatných instancích aplikací, i když jsou instance aplikací nainstalované v různých předplatných tenantů. Přístup se dosahuje prostřednictvím připojení SQL. Tento přístup mezi instancemi umožňuje dodavateli centralizovat správu schématu a dotaz mezi databázemi pro účely generování sestav nebo analýz. Pokud je tento druh centralizované správy žádoucí, musí se nasadit katalog, který mapuje identifikátory tenanta na identifikátory jednotných prostředků databáze (URI). Azure SQL Database poskytuje knihovnu horizontálního dělení, která se používá společně k poskytování katalogu. Knihovna horizontálního dělení se formálně nazývá klientská knihovna elastické databáze.
D. Víceklientní aplikace s databází na tenanta
Tento další model používá víceklientovou aplikaci s mnoha databázemi, což jsou všechny databáze s jedním tenantem. Pro každého nového tenanta se zřídí nová databáze. Aplikační vrstva se vertikálně navyšuje přidáním dalších prostředků na uzel. Nebo se aplikace horizontálně horizontálně horizontálně navyšuje přidáním dalších uzlů. Škálování je založené na úloze a je nezávislé na počtu nebo škálování jednotlivých databází.
Přizpůsobení pro tenanta
Stejně jako model samostatné aplikace poskytuje použití databází s jedním tenantem silnou izolaci tenanta. V libovolné aplikaci, jejíž model určuje pouze databáze s jedním tenantem, je možné schéma pro libovolnou danou databázi přizpůsobit a optimalizovat pro svého tenanta. Toto přizpůsobení nemá vliv na ostatní tenanty v aplikaci. Tenant možná potřebuje data nad rámec základních datových polí, která potřebují všichni tenanti. Další datové pole navíc může potřebovat index.
Při použití databáze na tenanta je přizpůsobení schématu pro jednoho nebo více jednotlivých tenantů jednoduché. Dodavatel aplikace musí navrhnout postupy pro pečlivou správu přizpůsobení schématu ve velkém měřítku.
Elastické fondy
Když jsou databáze nasazené ve stejné skupině prostředků, je možné je seskupit do elastických fondů. Fondy poskytují nákladově efektivní způsob sdílení prostředků napříč mnoha databázemi. Tato možnost fondu je levnější, než vyžaduje, aby každá databáze byla dostatečně velká, aby vyhovovala špičkám využití, ke kterým dochází. I když databáze ve fondu sdílejí přístup k prostředkům, stále můžou dosáhnout vysoké míry izolace výkonu.
Azure SQL Database poskytuje nástroje potřebné ke konfiguraci, monitorování a správě sdílení. Metriky výkonu na úrovni fondu i databáze jsou k dispozici na webu Azure Portal a prostřednictvím protokolů služby Azure Monitor. Metriky můžou poskytovat skvělé přehledy o agregovaném výkonu i výkonu specifickém pro tenanty. Jednotlivé databáze je možné přesouvat mezi fondy, aby poskytovaly rezervované prostředky konkrétnímu tenantovi. Tyto nástroje umožňují zajistit dobrý výkon nákladově efektivním způsobem.
Škálování operací pro databáze na tenanta
Azure SQL Database má mnoho funkcí pro správu, které jsou navržené pro správu velkého počtu databází ve velkém měřítku, například více než 100 000 databází. Díky těmto funkcím je model databáze na tenanta přijatelný.
Předpokládejme například, že systém má jako jedinou databázi 1000 tenantů. Databáze může mít 20 indexů. Pokud se systém převede na 1 000 databází s jedním tenantem, množství indexů se zvýší na 20 000. V Azure SQL Database jako součást automatického ladění jsou funkce automatického indexování ve výchozím nastavení povolené. Automatické indexování spravuje pro vás všech 20 000 indexů a jejich průběžné vytváření a odstraňování optimalizací. K těmto automatizovaným akcím dochází v rámci jednotlivých databází a nejsou koordinované nebo omezené podobnými akcemi v jiných databázích. Automatické indexování zpracovává indexy v zaneprázdněné databázi jinak než v méně zaneprázdněné databázi. Tento typ přizpůsobení správy indexů by byl nepraktický na úrovni databáze na tenanta, pokud by se tato obrovská úloha správy musela provést ručně.
Mezi další funkce správy, které se dobře škálují, patří:
- Předdefinované zálohy
- Vysoká dostupnost
- Šifrování na disku
- Telemetrie výkonu
Automation
Operace správy se dají skriptovat a nabízet prostřednictvím modelu DevOps . Operace lze dokonce automatizovat a vystavit v aplikaci.
Můžete například automatizovat obnovení jednoho tenanta do dřívějšího bodu v čase. Obnovení stačí obnovit jenom jednu databázi s jedním tenantem, která tenanta ukládá. Toto obnovení nemá žádný vliv na ostatní tenanty, což potvrzuje, že operace správy jsou na jemně členité úrovni každého jednotlivého tenanta.
E. víceklientských aplikací s víceklientských databází
Dalším dostupným vzorem je ukládání mnoha tenantů do víceklientských databází. Instance aplikace může mít libovolný počet víceklientských databází. Schéma víceklientských databází musí mít jeden nebo více sloupců identifikátorů tenanta, aby bylo možné data z libovolného tenanta selektivně načíst. Schéma navíc může vyžadovat několik tabulek nebo sloupců, které používají jenom podmnožina tenantů. Statický kód a referenční data se však ukládají jenom jednou a sdílí je všechny tenanty.
Izolace tenanta je obětována
Data: Víceklientová databáze nutně obětuje izolaci tenanta. Data více tenantů jsou uložená společně v jedné databázi. Během vývoje zajistěte, aby dotazy nikdy nezpřístupnily data z více než jednoho tenanta. SQL Database podporuje zabezpečení na úrovni řádků, které může vynutit, aby data vrácená z dotazu byla vymezena na jednoho tenanta.
Zpracování: Víceklientová databáze sdílí výpočetní prostředky a prostředky úložiště ve všech svých tenantech. Databázi jako celek je možné monitorovat, aby se zajistilo, že funguje přijatelně. Systém Azure ale nemá žádný integrovaný způsob, jak monitorovat nebo spravovat používání těchto prostředků jednotlivými tenanty. Proto víceklientské databáze přináší zvýšené riziko výskytu hlučných sousedů, kdy úloha jednoho nadaktivního tenanta ovlivňuje výkon jiných tenantů ve stejné databázi. Monitorování na úrovni aplikace může monitorovat výkon na úrovni tenanta.
Nižší náklady
Obecně platí, že víceklientských databází má nejnižší náklady na tenanta. Náklady na prostředky pro jednu databázi jsou nižší než u elastického fondu s ekvivalentní velikostí. Kromě toho pro scénáře, kdy tenanti potřebují jenom omezené úložiště, můžou být potenciálně miliony tenantů uloženy v jedné databázi. Žádný elastický fond nemůže obsahovat miliony databází. Řešení obsahující 1 000 databází na fond s 1 000 fondy by však mohlo dosáhnout rozsahu milionů v riziku, že se stát nepraktným řízením.
V následujícím článku jsou popsány dvě varianty modelu víceklientské databáze, přičemž horizontálně dělený víceklientský model je nejflexibilnější a škálovatelný.
F. Víceklientová aplikace s jednou víceklientovou databází
Nejjednodušší vzor víceklientských databází používá jednoúčelovou databázi k hostování dat pro všechny tenanty. Při přidání dalších tenantů se databáze škáluje s větším úložištěm a výpočetními prostředky. Toto vertikální navýšení kapacity může být vše, co je potřeba, i když existuje vždy konečný limit škálování. Ale dlouho před dosažením limitu se databáze stane nepraktným pro správu.
Operace správy zaměřené na jednotlivé tenanty jsou složitější pro implementaci ve víceklientských databázích. A ve velkém měřítku se tyto operace můžou stát nepřijatelně pomalým. Jedním z příkladů je obnovení dat k určitému bodu v čase pouze pro jednoho tenanta.
G. Víceklientská aplikace s horizontálně dělenými víceklientské databázemi
Většina aplikací SaaS přistupuje k datům pouze jednoho tenanta najednou. Tento model přístupu umožňuje distribuci dat tenanta napříč několika databázemi nebo horizontálními oddíly, kde všechna data pro každého tenanta jsou obsažená v jednom horizontálním oddílu. V kombinaci se vzorem víceklientské databáze umožňuje horizontálně dělený model téměř neomezené škálování.
Správa horizontálních oddílů
Horizontální dělení zvyšuje složitost návrhu i provozní správy. Vyžaduje se katalog, ve kterém se má udržovat mapování mezi tenanty a databázemi. Kromě toho se ke správě horizontálních oddílů a základního tenanta vyžadují postupy správy. Například postupy musí být navržené tak, aby přidávaly a odebíraly horizontální oddíly, a přesouvat data tenanta mezi horizontálními oddíly. Jedním ze způsobů škálování je přidání nového horizontálního oddílu a jeho naplnění novými tenanty. Jindy můžete hustě naplněný horizontální oddíl rozdělit do dvou méně hustě naplněných horizontálních oddílů. Po přesunutí nebo ukončení několika tenantů můžete sloučit řídce naplněné horizontální oddíly dohromady. Sloučení by vedlo k nákladově efektivnějšímu využití prostředků. Tenanti se také můžou přesouvat mezi horizontálními oddíly, aby se vyrovnávají úlohy.
SQL Database poskytuje nástroj pro rozdělení nebo sloučení, který funguje s knihovnou horizontálního dělení a databází katalogu. Poskytnutá aplikace může rozdělit a sloučit horizontální oddíly a může přesouvat data tenanta mezi horizontálními oddíly. Aplikace také během těchto operací udržuje katalog a před přesunutím tenantů označí ovlivněné tenanty jako offline. Po přesunutí aplikace znovu aktualizuje katalog novým mapováním a označí tenanta jako back-online.
Menší databáze snadněji spravované
Distribuce tenantů napříč několika databázemi vede k tomu, že horizontálně dělené víceklientské řešení je jednodušší spravovat menší databáze. Například obnovení konkrétního tenanta k určitému bodu v čase teď zahrnuje obnovení jedné menší databáze ze zálohy, nikoli větší databáze, která obsahuje všechny tenanty. Velikost databáze a počet tenantů na databázi je možné zvolit k vyvážení úloh a úsilí o správu.
Identifikátor tenanta ve schématu
V závislosti na použitém přístupu horizontálního dělení může být u schématu databáze vynucena další omezení. Aplikace SQL Database rozdělení nebo sloučení vyžaduje, aby schéma obsahovalo klíč horizontálního dělení, což je obvykle identifikátor tenanta. Identifikátor tenanta je předním prvkem primárního klíče všech horizontálně dělených tabulek. Identifikátor tenanta umožňuje rozdělené nebo slučovací aplikaci rychle vyhledat a přesunout data přidružená ke konkrétnímu tenantovi.
Elastický fond pro horizontální oddíly
Horizontálně dělené víceklientské databáze je možné umístit do elastických fondů. Obecně platí, že mít mnoho databází s jedním tenantem ve fondu je stejně nákladově efektivní jako mít mnoho tenantů v několika víceklientských databázích. Víceklientských databází je výhodné, pokud existuje velký počet relativně neaktivních tenantů.
H. Hybridní víceklientský model víceklientské databáze
V hybridním modelu mají všechny databáze identifikátor tenanta ve schématu. Všechny databáze jsou schopné ukládat více než jednoho tenanta a databáze je možné horizontálně dělit. Takže ve smyslu schématu jsou to všechny víceklientských databází. Některé z těchto databází ale v praxi obsahují pouze jednoho tenanta. Bez ohledu na počet tenantů uložených v dané databázi nemá žádný vliv na schéma databáze.
Přesun tenantů
Kdykoli můžete přesunout konkrétního tenanta do vlastní víceklientové databáze. A kdykoli můžete změnit názor a přesunout tenanta zpět do databáze, která obsahuje více tenantů. Při zřizování nové databáze můžete také přiřadit tenanta k nové databázi s jedním tenantem.
Hybridní model svítí, když existují velké rozdíly mezi potřebami prostředků identifikovatelných skupin tenantů. Předpokládejme například, že tenanti, kteří se účastní bezplatné zkušební verze, nezaručují stejnou vysokou úroveň výkonu, jakou mají přihlášení k odběru tenanti. Zásady můžou být pro tenanty ve fázi bezplatné zkušební verze uložené ve víceklientové databázi, která se sdílí mezi všemi bezplatnými zkušebními tenanty. Když se tenant bezplatné zkušební verze přihlásí k odběru úrovně služby Basic, může být tenant přesunut do jiné víceklientové databáze, která může mít méně tenantů. Předplatitel, který platí za úroveň služby Premium, se dá přesunout do vlastní nové databáze s jedním tenantem.
Skupiny
V tomto hybridním modelu je možné umístit databáze s jedním tenantem pro předplatitele do fondů prostředků, aby se snížily náklady na databázi na tenanta. To se také provádí v modelu databáze pro jednotlivé tenanty.
I. Porovnání modelů tenantů
Následující tabulka shrnuje rozdíly mezi hlavními modely tenantů.
| Měrný systém | Samostatná aplikace | Databáze na tenanta | Horizontálně dělené víceklientské |
|---|---|---|---|
| Měřítko | Střední (1–100 s) | Vysoká (1–100 000 s) | Neomezené (1–1 000 000) |
| Izolace tenanta | Vysoká | Vysoká | Nízký; s výjimkou jednoho tenanta (který je sám v databázi MT). |
| Náklady na databázi na tenanta | Vysoko; je velikost pro špičky. | Nízký; použité fondy. | Nejnižší pro malé tenanty v databázích MT. |
| Monitorování a správa výkonu | Pouze pro jednotlivé tenanty | Aggregate + per-tenant | Agregátní; i když je pro jednotlivé tenanty pouze pro jednotlivé. |
| Složitost vývoje | Nízká | Nízká | Středně; kvůli horizontálnímu dělení. |
| Provozní složitost | Low-High. Individuálně jednoduché, složité ve velkém měřítku. | Nízká-střední. Vzory řeší složitost ve velkém měřítku. | Low-High. Správa jednotlivých tenantů je složitá. |