Vícetenancy a Azure Cosmos DB

Na této stránce popisujeme některé funkce Azure Cosmos DB, které jsou užitečné při práci s vícetenantálními systémy, a uvádíme odkazy na pokyny a příklady použití Azure Cosmos DB ve vícetenantových řešeních.

Funkce Azure Cosmos DB, které podporují vícetenancy

Dělení

Pomocí oddílů s kontejnery Cosmos DB můžete vytvářet kontejnery, které se sdílí mezi více tenanty. Identifikátor tenanta se obvykle používá jako klíč oddílu, ale můžete také zvážit použití více klíčů oddílů pro jednoho tenanta. Dobře plánovaná strategie dělení efektivně implementuje model horizontálního dělení. S velkými kontejnery Cosmos DB rozprostíří tenanty mezi několik fyzických uzlů a dosáhne tak vysokého stupně škálování.

Další informace:

Správa jednotek žádostí

Cosmos Cenový model databáze vychází z počtu jednotek žádostí za sekundu, které zřujete nebo využíváte. Jednotka žádosti je logická abstrakce nákladů na databázovou operaci nebo dotaz. Obvykle pro svou úlohu zřickyte definovaný počet jednotek žádostí za sekundu, který se označuje jako propustnost. Cosmos Databáze nabízí několik možností, jak zřídit propustnost. Ve vícetenantovém prostředí má výběr vliv na výkon a cenu vašich prostředků Cosmos DB.

Jeden model tenantů pro Cosmos DB zahrnuje nasazení samostatných kontejnerů pro každého tenanta ve sdílené databázi. Cosmos Databáze umožňuje zřídit jednotky žádostí pro databázi a všechny kontejnery sdílejí jednotky žádostí. Pokud se úlohy vašeho tenanta obvykle nepřekrývají, může to poskytnout užitečný přístup ke snížení provozních nákladů. Upozorňujeme ale, že tento přístup je náchylný k problému s "hlučným sousedem", protože kontejner jednoho tenanta může spotřebovávat neúměrné množství sdílených zřízených jednotek žádosti. Pokud chcete tento případ zmírnit, když jste identifikovali tenanty s šumem, můžete volitelně nastavit zřízenou propustnost pro konkrétní kontejner. Ostatní kontejnery v databázi dál sdílejí svoji propustnost, ale hlučný tenant spotřebovává vlastní vyhrazenou propustnost.

Cosmos Databáze také poskytuje bez serveru úroveň, která se hodí pro úlohy s přerušovaným nebo nepředvídatelným provozem. Automatické škálování také umožňuje nakonfigurovat zásady pro určení škálování zřízené propustnosti. Ve vícetenantových řešeních můžete všechny tyto přístupy kombinovat, abyste podpořili různé typy tenantů.

Poznámka

Při plánování konfigurace Cosmos DB se ujistěte, že vezměte v úvahu kvóty aomezení služby .

Pokud chcete monitorovat a spravovat náklady spojené s jednotlivými tenanty, zahrnuje každá operace Cosmos DB spotřebované jednotky žádostí. Tyto informace můžete použít k agregaci a porovnání skutečných jednotek žádostí spotřebovaných jednotlivými tenanty a pak můžete identifikovat tenanty s různými charakteristikami výkonu.

Další informace:

Klíče spravované zákazníkem

Někteří tenanti můžou vyžadovat použití vlastních šifrovacích klíčů. Cosmos Databáze poskytuje funkci klíče spravovaného zákazníkem. Tato funkce se používá na úrovni účtu Cosmos DB, takže tenanti, kteří potřebují vlastní šifrovací klíče, musí být nasazeni pomocí vyhrazených Cosmos DB.

Další informace:

Modely izolace

Při práci s vícetenantem, který používá Azure Cosmos DB, musíte rozhodnout o úrovni izolace, kterou chcete použít. Azure Cosmos DB podporuje několik modelů izolace:

Sdílené kontejnery s klíči oddílů na tenanta Kontejner se sdílenou propustností na tenanta Kontejner s vyhrazenou propustností na tenanta Účet databáze na tenanta
Možnosti izolace
  • Sdílejte propustnost mezi tenanty seskupených podle kontejneru (skvělé pro snížení nákladů na "nesnícené" tenanty).
  • Umožňuje snadné dotazy napříč tenanty (kontejnery se pro dotazy chová jako hranice). Zmírnění poloměru hlučného souseda (seskupení tenantů podle kontejneru)
  • Sdílejte propustnost mezi tenanty seskupených podle databáze (což je skvělé pro snížení nákladů na "nesnížující" tenanty).
  • Snadná správa tenantů (když tenant opustí tenanta, zahodí kontejner).
  • Zmírnění poloměru "hlučného souseda" (seskupení tenantů podle databáze)
  • Možnosti nezávislé propustnosti (vyhrazená propustnost eliminuje hlučné sousedy).
  • Seskupte tenanty v rámci databázových účtů podle místních potřeb.
  • Nezávislé ovladače geografické replikace.
  • Více možností propustnosti (vyhrazená propustnost eliminuje hlučné sousedy).
Požadavky na propustnost >0 REZERVOVANÝCH Ů na tenanta >100 REZERVOVANÝCH Ů na tenanta >400 REZERVOVANÝCH Ů na tenanta >400 REZERVOVANÝCH Ů na tenanta
Příklad případu použití Aplikace B2C Standardní nabídka pro aplikace B2B Premium nabídky pro aplikace B2B Premium nabídky pro aplikace B2B

Sdílený kontejner s klíči oddílů na tenanta

Pokud používáte jeden kontejner pro více tenantů, můžete využít podporu Cosmos dělení databáze. Pomocí samostatných klíčů oddílů pro každého tenanta můžete snadno dotazovat data pro jednoho tenanta. Můžete se také dotazovat napříč více tenanty, i když jsou v samostatných oddílech. Dotazy napříč oddíly ale mají vyšší náklady na jednotku žádosti (RU) než dotazy s jedním oddílem.

Tento přístup obvykle dobře funguje, když je množství dat uložených pro každého tenanta malé. Může být dobrou volbou pro vytvoření cenového modelu, který zahrnuje bezplatnou úroveň, a pro řešení B2C (Business-to-Consumer). Obecně platí, že použitím sdílených kontejnerů dosáhnete nejvyšší hustoty tenantů a tím i nejnižší ceny za tenanta.

Je důležité vzít v úvahu propustnost kontejneru. Všichni tenanti budou sdílet propustnost kontejneru, takže problém s hlučným sousedem může způsobit problémy s výkonem, pokud vaši tenanti mají vysoké nebo překrývající se úlohy. Tento problém lze někdy zmírnit seskupením podmnožiny tenantů do různých kontejnerů a zajištěním, že každá skupina tenantů má kompatibilní vzory použití. Alternativně můžete zvážit hybridní model s více tenanty a jedním tenantem, ve kterém jsou menší tenanti seskupeni do sdílených rozdělených kontejnerů a rozsáhlí zákazníci mají vyhrazené kontejnery.

Je také důležité vzít v úvahu množství dat, která ukládáte v jednotlivých logických oddílech. Azure Cosmos DB umožňuje každému logickému oddílu růst až na 20 GB. Pokud máte jednoho tenanta, který potřebuje uložit více než 20 GB dat, zvažte rozložení dat napříč několika logickými oddíly. Například místo jediného klíče oddílu typu můžete vytvořit více klíčů oddílů pro tenanta, například , a Contoso Contoso1 tak Contoso2 dále. Při dotazování dat pro tenanta můžete použít klauzuli , WHERE IN která odpovídá všem klíčům oddílu. K podpoře velkých tenantů je také možné použít hierarchické klíče oddílů.

Vezměte v úvahu provozní aspekty vašeho řešení a různé fáze životního cyklu tenanta. Když se například tenant přesune na vyhrazenou cenovou úroveň, budete pravděpodobně muset přesunout data do jiného kontejneru. Když dojde ke zřízení tenanta, musíte na kontejneru spustit dotaz pro odstranění, který data odebere, a u velkých tenantů může tento dotaz spotřebovávat během provádění značné množství propustnosti.

Kontejner na tenanta

Pro každého tenanta můžete zřídit vyhrazené kontejnery. To může dobře fungovat, když data, která ukládáte pro vašeho tenanta, je možné zkombinovat do jednoho kontejneru.

Při použití kontejneru pro každého tenanta můžete zvážit sdílení propustnosti s jinými tenanty zřízením propustnosti na úrovni databáze. Zvažte omezení a omezení týkající se minimálního počtu jednotek žádostí pro vaši databázi a maximálního počtu kontejnerů v databázi. Zvažte také, jestli vaši tenanti vyžadují zaručenou úroveň výkonu a jestli jsou náchylní k problému s hlučným sousedem. V případě potřeby naplánujte seskupení tenantů do různých databází založených na vzorech úloh.

Alternativně můžete pro každý kontejner zřídit vyhrazenou propustnost. To funguje dobře u větších tenantů a u tenantů, u které hrozí riziko problému "Hlučný soused". Základní propustnost pro každého tenanta je však vyšší, proto zvažte minimální požadavky a vliv tohoto modelu na náklady.

Správa životního cyklu je obecně jednodušší, když jsou kontejnery vyhrazené pro tenanty. Tenanty můžete snadno přesouvat mezi modelysdílené a vyhrazené propustnosti a při zrušení zřízení tenanta můžete kontejner rychle odstranit.

Účet databáze na tenanta

Cosmos Databáze umožňuje zřídit samostatné databázové účty pro každého tenanta, což poskytuje nejvyšší úroveň izolace, ale nejnižší hustotu. Jeden databázový účet je vyhrazený pro tenanta, což znamená, že nejsou předmětem problému s hlučným sousedem. Můžete také nakonfigurovat umístění účtu databáze podle požadavků tenanta a vyladit konfiguraci funkcí služby Cosmos DB, jako jsou geografická replikace a šifrovací klíče spravované zákazníkem, aby vyhovovaly požadavkům jednotlivých tenantů. Při použití vyhrazeného účtu Cosmos DB na tenanta zvažte maximální počet účtů Cosmos DB na předplatné Azure.

Pokud tenantům povolíte migraci ze sdíleného účtu na vyhrazený účet Cosmos DB, zvažte přístup k migraci, který použijete k přesunu dat tenanta mezi starými a novými účty.

Hybridní přístupy

Můžete zvážit kombinaci výše uvedených přístupů tak, aby vyhovovala požadavkům různých tenantů a cenového modelu. Příklad:

  • Zřízení všech zákazníků bezplatné zkušební verze v rámci sdíleného kontejneru a použití ID tenanta nebo syntetického klíče klíče klíče oddílu.
  • Nabízí placenou bronzovou úroveň, která nasazovat vyhrazený kontejner na tenanta, ale se sdílenou propustností v databázi.
  • Nabízí vyšší úroveň Silver, která zřídí vyhrazenou propustnost pro kontejner tenanta.
  • Nabídnou nejvyšší úroveň Gold a poskytnete pro tenanta vyhrazený databázový účet, který také umožňuje tenantům vybrat geografickou oblast pro své nasazení.

Další kroky

Přehled zdrojů informací pro architekty a vývojáře vícetenantových řešení

  • Azure Cosmos DB a vícetenantovésystémy: Blogový příspěvek, který popisuje, jak vytvořit vícetenantový systém, který používá Azure Cosmos DB.
  • Vícetenantové aplikace s Azure Cosmos DB (video)
  • Vytvoření saaS s více tenanty pomocí Azure Cosmos DB a Azure (video): Případová studie z reálného světa, ve které se v Azure Cosmos DB a Azure vybudovala moderní platforma od začátku. Ukazuje rozhodnutí o návrhu a implementaci, která se týkají dělení, modelování dat, zabezpečené vícetenancy, výkonu, streamování z kanálu změn do SignalR v reálném čase a další, a to vše pomocí ASP.NET Core v Azure App Services.