Sdílet prostřednictvím

Víceklientská architektura a Azure Cosmos DB

  • Článek

Na této stránce popisujeme některé funkce služby Azure Cosmos DB, které jsou užitečné při práci s víceklientickými systémy. Propovíme také pokyny a příklady použití služby Azure Cosmos DB ve víceklientských řešeních.

Funkce služby Azure Cosmos DB, které podporují víceklientské prostředí

dělení na části

Pomocí oddílů s kontejnery Azure Cosmos DB můžete vytvářet kontejnery, které jsou sdílené napříč více tenanty. Obvykle používáte identifikátor tenanta 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 služba Azure Cosmos DB rozloží vaše tenanty do několika fyzických uzlů, aby dosáhla vysokého stupně škálování.

Doporučujeme prozkoumat použití hierarchických klíčů oddílů ke zlepšení výkonu víceklientských řešení. Hierarchické klíče oddílů umožňují vytvořit klíč oddílu, který obsahuje více hodnot. Můžete například použít hierarchický klíč oddílu, který obsahuje identifikátor tenanta a typ dat, která ukládáte. Tento přístup umožňuje škálovat nad rámec limitu logického oddílu 20 GB na hodnotu klíče oddílu.

Další informace:

Správa jednotek žádostí

Cenový model služby Azure Cosmos DB vychází z počtu jednotek žádostí za sekundu, které zřídíte nebo využíváte. Jednotka požadavku je logická abstrakce nákladů na operaci databáze nebo dotaz. Obvykle pro úlohu zřídíte definovaný počet jednotek žádostí za sekundu, což se označuje jako propustnost. Azure Cosmos DB nabízí několik možností, jak zřídit propustnost. Výběr ve víceklientských prostředích má vliv na výkon a cenu prostředků Azure Cosmos DB.

Jeden model tenantů pro službu Azure Cosmos DB zahrnuje nasazení samostatných kontejnerů pro každého tenanta ve sdílené databázi. Azure Cosmos DB umožňuje zřídit jednotky žádostí pro databázi a všechny kontejnery sdílejí jednotky žádostí. Pokud se úlohy tenanta obvykle nepřekrývají, může vám tento přístup pomoct snížit provozní náklady. Tento přístup je ale náchylný k problému typu Noisy Neighbor, protože kontejner jednoho tenanta může spotřebovávat nepřiměřenou část jednotek sdílených zřízených žádostí. Pokud chcete tento problém zmírnit, nejprve identifikujte hlučné tenanty. Potom můžete volitelně nastavit zřízenou propustnost pro konkrétní kontejner. Ostatní kontejnery v databázi nadále sdílejí svou propustnost, ale hlučný tenant využívá vlastní vyhrazenou propustnost.

Azure Cosmos DB také poskytuje bezserverovou úroveň, která je vhodná 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. Kromě toho můžete využít výhod nárazové kapacity služby Azure Cosmos DB a maximalizovat využití zřízené kapacity propustnosti, což by jinak bylo omezené rychlostí. Ve víceklientských řešeních můžete kombinovat všechny tyto přístupy pro podporu různých typů tenantů.

Poznámka:

Při plánování konfigurace služby Azure Cosmos DB se ujistěte, že zvažujete kvóty a limity služeb.

Pokud chcete monitorovat a spravovat náklady spojené s každým tenantem, každá operace pomocí rozhraní API služby Azure Cosmos DB zahrnuje 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íčů. Azure Cosmos DB poskytuje funkci klíče spravovaného zákazníkem. Tato funkce se používá na úrovni účtu služby Azure Cosmos DB, takže tenanti, kteří vyžadují vlastní šifrovací klíče, musí být nasazeni pomocí vyhrazených účtů azure Cosmos DB.

Další informace:

Modely izolace

Při práci s víceklientovým systémem, který používá Službu Azure Cosmos DB, musíte rozhodnout o úrovni izolace, kterou chcete použít. B2B (Business-to-Business) odkazuje na prodej podniku. B2C (Business-to-Consumer) odkazuje na prodej přímo individuálnímu zákazníkovi, který produkt nebo službu používá. Azure Cosmos DB podporuje několik modelů izolace:

Potřeba úlohy Klíč oddílu na tenanta Kontejner na tenanta (sdílená propustnost) Kontejner na tenanta (vyhrazená propustnost) Databáze na tenanta Účet databáze na tenanta
Dotazy napříč tenanty Easy (kontejner funguje jako hranice pro dotazy) Závazná Závazná Závazná Závazná
Hustota tenanta Vysoká (nejnižší náklady na tenanta) Střední Nízká Nízká Nízká
Odstranění dat tenanta Závazná Snadné (vyřazení kontejneru po opuštění tenanta) Snadné (vyřazení kontejneru po opuštění tenanta) Snadné (vyřazení databáze po opuštění tenanta) Snadné (vyřazení databáze po opuštění tenanta)
Izolace zabezpečení přístupu k datům Je potřeba implementovat v rámci aplikace. Řízení přístupu na základě role kontejneru Řízení přístupu na základě role kontejneru Řízení přístupu na základě role v databázi RBAC
Geografická replikace Geografická replikace na tenanta není možná. Seskupování tenantů v rámci databázových účtů na základě požadavků Seskupování tenantů v rámci databázových účtů na základě požadavků Seskupování tenantů v rámci databázových účtů na základě požadavků Seskupování tenantů v rámci databázových účtů na základě požadavků
Hlučná prevence souseda Nic Nic Ano Ano Yes
Latence vytváření nového tenanta Okamžité Rychlé Rychlé Střední Pomalá
Výhody modelování dat Nic kolokace entity kolokace entity Více kontejnerů pro modelování entit tenanta Více kontejnerů a databází pro modelování tenantů
Šifrovací klíč Stejné pro všechny tenanty Stejné pro všechny tenanty Stejné pro všechny tenanty Stejné pro všechny tenanty Klíč spravovaný zákazníkem na tenanta
Požadavky na propustnost >0 RU na tenanta >100 RU na tenanta >100 RU na tenanta (pouze s automatickým škálováním, jinak >400 RU na tenanta) >400 RU na tenanta >400 RU na tenanta
Příklady případů použití Aplikace B2C Standardní nabídka pro aplikace B2B Nabídka Premium pro aplikace B2B Nabídka Premium pro aplikace B2B Nabídka Premium pro aplikace B2B

Klíč oddílu na tenanta

Pokud používáte jeden kontejner pro více tenantů, můžete využít podporu dělení služby Azure Cosmos DB. Pomocí samostatných klíčů oddílů pro každého tenanta můžete snadno dotazovat data pro jednoho tenanta. Můžete se také dotazovat na více tenantů, 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 funguje dobře, 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 řešení B2C (Business-to-Consumer). Obecně platí, že pomocí sdílených kontejnerů dosáhnete nejvyšší hustoty tenantů a tedy nejnižší ceny za tenanta.

Je důležité zvážit propustnost kontejneru. Všichni tenanti budou sdílet propustnost kontejneru, takže problém hlučného souseda může způsobit problémy s výkonem, pokud mají vaši tenanti vysoké nebo překrývající se úlohy. Tento problém je někdy možné zmírnit seskupením podmnožinami tenantů do různých kontejnerů a zajištěním toho, aby každá skupina tenantů byla kompatibilní se vzory použití. Alternativně můžete zvážit hybridní model s více tenanty a jeden tenant. Seskupte menší tenanty do sdílených dělených kontejnerů a udělte velkým zákazníkům vyhrazené kontejnery. Existují také funkce, které můžou pomoct řídit problém hlučného souseda při modelování tenanta podle oddílů, jako je například relokace propustnosti, zvýšení kapacity a řízení propustnosti v sadě Java SDK.

Je také důležité vzít v úvahu množství dat, která ukládáte v každém logickém oddílu. Azure Cosmos DB umožňuje, aby se každý logický oddíl zvětšil 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 do více logických oddílů. Například místo jediného klíče oddílu můžete klíče oddílu Contosovysolovat vytvořením více klíčů oddílu pro tenanta, například Contoso1, Contoso2atd. Když se dotazujete na data pro tenanta, můžete použít WHERE IN klauzuli tak, aby odpovídala všem klíčům oddílu. Hierarchické klíče oddílů je také možné použít k podpoře velkých tenantů s úložištěm větším než 20 GB, aniž byste museli používat syntetické klíče oddílů nebo více hodnot klíčů oddílů na tenanta.

Zvažte 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 k zrušení zřízení tenanta, musíte v kontejneru spustit odstraňovací dotaz, který odebere data, a u velkých tenantů může tento dotaz během provádění spotřebovávat značné množství propustnosti.

Kontejner na tenanta

Pro každého tenanta můžete zřídit vyhrazené kontejnery. Vyhrazené kontejnery fungují dobře, když se data, která pro tenanta ukládáte, dají kombinovat do jednoho kontejneru. Tento model poskytuje větší izolaci výkonu než výše uvedený model klíče oddílu na tenanta a poskytuje také zvýšenou izolaci zabezpečení přístupu k datům prostřednictvím Azure RBAC.

Při použití kontejneru pro každého tenanta můžete zvážit sdílení propustnosti s ostatní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 tenanti vyžadují zaručenou úroveň výkonu a jestli jsou náchylné k problému hlučného souseda. Když sdílíte propustnost na úrovni databáze, měla by být úloha nebo úložiště napříč všemi kontejnery relativně jednotná. Jinak může dojít k problému s hlučným sousedem, pokud existuje jeden nebo více velkých tenantů. V případě potřeby naplánujte seskupení těchto tenantů do různých databází, které jsou založené na vzorech úloh.

Případně můžete zřídit vyhrazenou propustnost pro každý kontejner. Tento přístup funguje dobře pro větší tenanty a pro tenanty, kteří jsou ohroženi problémem Hlučný soused. Propustnost směrného plánu pro každého tenanta je ale vyšší, proto zvažte minimální požadavky a dopad na náklady tohoto modelu.

Pokud datový model tenanta vyžaduje více než jednu entitu, pokud všechny entity můžou sdílet stejný klíč oddílu, dají se společně přidělit do stejného kontejneru. Pokud je ale datový model tenanta složitější a vyžaduje entity, které nemůžou sdílet stejný klíč oddílu, zvažte níže uvedené modely databáze pro jednotlivé tenanty nebo databázové účty. Podívejte se na náš článek o modelování a dělení dat ve službě Azure Cosmos DB s využitím příkladu z reálného světa, kde najdete další pokyny.

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

Databáze na tenanta

Databáze můžete zřídit pro každého tenanta ve stejném databázovém účtu. Stejně jako výše uvedený model kontejneru pro tenanty poskytuje tento model větší izolaci výkonu než model klíče oddílu na tenanta a poskytuje také zvýšenou izolaci zabezpečení přístupu k datům prostřednictvím Azure RBAC.

Podobně jako model účtů na tenanta níže poskytuje tento přístup nejvyšší úroveň izolace výkonu, ale poskytuje nejnižší hustotu tenanta. Tato možnost je ale nejlepší, když každý tenant vyžaduje složitější datový model, než je možné v modelu kontejneru na tenanta. Nebo byste měli postupovat podle tohoto přístupu, pokud je potřeba, aby vytvoření nového tenanta bylo rychlé nebo bez jakýchkoli režijních nákladů při vytváření účtů tenantů předem. Může se jednat také o případ, kdy se používá konkrétní architektura vývoje softwaru, je databáze pro jednotlivé tenanty jedinou úrovní izolace výkonu, která je v této rámci rozpoznána. Izolace na úrovni entity (kontejneru) a kolokace entit se v takových architekturách obvykle nepodporují nativně.

Účet databáze na tenanta

Azure Cosmos DB umožňuje zřídit samostatné databázové účty pro každého tenanta, což poskytuje nejvyšší úroveň izolace, ale nejnižší hustotu. Stejně jako modely kontejnerů na tenanta a databáze pro tenanty výše poskytuje tento model větší izolaci výkonu než model klíče oddílu na tenanta. Poskytuje také zvýšenou izolaci zabezpečení přístupu k datům prostřednictvím Azure RBAC. Kromě toho tento model poskytuje izolaci zabezpečení šifrování databáze na úrovni tenanta prostřednictvím klíčů spravovaných zákazníkem.

Jeden účet databáze je vyhrazený pro tenanta, což znamená, že nejsou předmětem problému hlučného souseda. Umístění databázového účtu můžete nakonfigurovat podle požadavků tenanta. Můžete také ladit konfiguraci funkcí služby Azure Cosmos DB, jako je 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 služby Azure Cosmos DB na tenanta zvažte maximální počet účtů Azure Cosmos DB na předplatné Azure.

Pokud používáte tento model, měli byste zvážit, jak rychle bude vaše aplikace schopná generovat nové tenanty. Vytvoření účtu ve službě Azure Cosmos DB může trvat několik minut, takže možná budete muset vytvořit účty předem. Pokud tento přístup není možný, zvažte model databáze pro jednotlivé tenanty.

Pokud klientům povolíte migraci ze sdíleného účtu na vyhrazený účet Azure Cosmos DB, zvažte přístup migrace, 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 vyhovovaly požadavkům různých tenantů a cenovému modelu. Příklad:

  • Zřízení všech bezplatných zkušebních verzí zákazníků ve sdíleném kontejneru a použití ID tenanta nebo syntetického klíče oddílu.
  • Nabízí placenou úroveň Bronze , která nasadí 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ídnout nejvyšší úroveň Gold a poskytnout vyhrazený databázový účet pro tenanta, který také umožňuje tenantům vybrat zeměpisnou oblast pro jejich nasazení.

Přispěvatelé

Tento článek spravuje Microsoft. Původně byla napsána následujícími přispěvateli.

Hlavní autoři:

  • Paul Burpo | Hlavní zákaznický inženýr, FastTrack pro Azure
  • John Downs | Hlavní zákaznický inženýr, FastTrack pro Azure

Další přispěvatelé:

Pokud chcete zobrazit neveřejné profily LinkedIn, přihlaste se na LinkedIn.

Další kroky

Projděte si přístupy k úložišti a datům pro víceklientské prostředí.

Další informace o víceklientské službě a službě Azure Cosmos DB:

Podívejte se na některé z našich dalších scénářů architektury Cosmos DB: