Poznámka:
Přístup k této stránce vyžaduje autorizaci. Můžete se zkusit přihlásit nebo změnit adresáře.
Přístup k této stránce vyžaduje autorizaci. Můžete zkusit změnit adresáře.
Koncept víceklientské architektury v Azure Data Exploreru označuje obsluhu různých tenantů a ukládání dat do jednoho clusteru.
Important
Víceklientské řešení lze také navrhnout v pracovních zátěžích Microsoft Fabric pro Real-Time Intelligence s využitím databází KQL uvnitř Eventhouse.
Nájemce může představovat zákazníka, skupinu uživatelů nebo jakoukoli klasifikaci uživatelů, u kterých je potřeba oddělit data podél hranic jednotlivých nájemců. Můžete mít také víceúrovňový scénář s více tenanty, například více aplikací, které mají více tenantů. Tento článek se nezabývá tímto scénářem, ale platí podobné principy.
Důležitým faktorem je způsob, jakým koncoví uživatelé přistupují k datům tenanta. Když koncoví uživatelé přistupují přímo k Azure Data Exploreru, musí být v Azure Data Exploreru nakonfigurované řízení přístupu, aby bylo možné izolovat zobrazení uživatele s vlastními daty. Když proxy aplikace přistupuje ke svým datům v Azure Data Exploreru, může tato aplikace provést izolaci.
Tento článek popisuje některé architektury nasazení a poskytuje charakteristiky pro každý z nich. Vlastnosti vám pomůžou rozhodnout, která architektura je pro vaše řešení nejvhodnější.
Hlučný soused
Obecně platí, že sdílení clusteru mezi mnoha tenanty bez ohledu na použitou architekturu znamená, že různé tenanty sdílejí prostředky clusteru. To může vést k antipatternu hlučného souseda .
Pokud například tenant provádí mnoho dotazů náročných na výpočetní výkon nebo příjem dat, ostatní tenanti budou pravděpodobně ovlivněni hladověním prostředků. To je možné zmírnit pomocí skupin úloh. Zásady můžete také použít k řízení ukládání do mezipaměti a celkového úložiště.
Přehled architektur
V dalších částech se podrobně seznámíte s architekturami nasazení. Tato část kontrastuje s architekturami, které usnadňují rozhodování.
| Architecture | Strengths |
|---|---|
| Jeden tenant na databázi | – Izolace tenantů: nevyžaduje proxy server. – Může mít různé zásady, jako jsou zásady uchovávání informací, na úrovni nájemce. – Flexibilita vývoje schématu pro každého nájemce - Snadné a rychlé odebrání dat tenanta |
| Jedna tabulka pro mnoho tenantů | - Efektivní konsolidace dat a správa rozsahu – Vývoj zjednodušeného schématu - Nejvhodnější pro materializovaná zobrazení - Ideální pro dělení |
| Jeden tenant na tabulku v jedné databázi | Nedoporučuje se |
Architektura: Jeden tenant na databázi
Jedná se o populární a jednoduchou architekturu. Každý tenant získá vlastní databázi. Každá databáze má stejné schéma.
Charakteristiky této architektury jsou:
Zřízení nového tenanta: Vyžaduje vytvoření nové databáze a nasazení schematických entit na ní.
Odebrání tenanta: Vyžaduje odstranění databáze. Odstranění databáze je možné provést během několika sekund. Spotřebovává málo a konstantní prostředky, které nejsou lineární s objemem dat tenanta.
Aktualizace schémat databáze: Každý tenant může být v různých časech nezávisle aktualizován. Aplikace, které přistupují k databázím, musí znát verzi každé databáze, se kterou pracují.
Zásady uchovávání informací a ukládání do mezipaměti: Každý tenant může mít své vlastní jedinečné zásady, které zákazníkům umožňují poskytovat vlastní zásady uchovávání informací a ukládání do mezipaměti.
Hranice zabezpečení na tenanta:
- U víceklientských aplikací (proxy): Nakonfigurujte aplikaci tak, aby cílila na příslušnou databázi. Pomocí omezení přístupu u dotazů zakážete dotazy napříč databázemi.
- Pro uživatele s přímým přístupem: Uživatelům se dá udělit přístup na úrovni databáze. Poskytnutí přímého přístupu k databázi uživatelům vytvoří závislost na podrobnostech implementace, což ztěžuje změnu implementace. Proto důrazně doporučujeme použít přístup proxy pro přístup k databázi.
Agregace dat z více tenantů ve velkém měřítku: Pomocí operátoru sjednocení agregujte data mezi databázemi. Tato metoda se ale může stát těžkopádnou při nárůstu počtu tenantů. I když agregace dat z více tenantů může být cílem návrhu z pohledu tenanta, může být zajímavé, aby vlastník řešení agregoval data ze všech tenantů, aby shromáždil statistiky.
Fragmentace rozsahů: Každý tenant, který ingestuje několik záznamů na tabulku databáze, vede k vytvoření malých rozsahů , které je potřeba později sloučit. Výsledkem jsou vyšší náklady na správu rozsahu. Proto důrazně doporučujeme používat příjem streamování, jako je příjem z Event Hubs nebo Event Grid. Pokud chcete používat příjem dat ze streamování, musíte se ujistit, že je povolen v clusteru i tabulce.
Materializovaná zobrazení a politika particionování S rostoucím počtem tenantů je důležité si uvědomit, že existuje omezení počtu materializovaných zobrazení a zásad rozdělení, které může cluster efektivně spouštět.
Datová připojení Event Gridu a Event Hubs: Tato datová připojení se vytvářejí pro každou databázi. Tato architektura proto vyžaduje datové připojení a instanci Event Gridu nebo Event Hubs na tenanta, což zvyšuje složitost správy. Zvažte použití směrování událostí pro službu Event Hubs a Event Grid.
Architektura: Jedna tabulka pro mnoho nájemníků
Tato architektura je při konsolidaci agresivnější a používá jednu databázi pro všechny tenanty. Každá tabulka v databázi má sloupec ID tenanta nebo ekvivalent, který umožňuje filtrovat data jednoho tenanta. Tabulky můžete rozdělit podle tenanta, aby se zlepšil výkon dotazů, protože většina dotazů bude pravděpodobně filtrovat podle tenanta. Pokud je to možné, měli byste zvážit oddíl s jiným sloupcem pomocí složeného klíče oddílu. Můžete například vytvořit složený klíč oddílu, který zřetězí ID tenanta a hodnotami dalších sloupců.
Charakteristiky této architektury jsou:
Zřízení nového tenanta: Zřízení nového tenanta nevyžaduje žádné vytvoření databáze ani úpravy schématu. Nové ID tenanta se používá v nových záznamech.
Odebrání nájemce: Vyžaduje soft delete nebo vymazání dat nájemce. Můžete na konci týdne dávkovat několik pročištění, abyste omezili dopad na spotřebu prostředků.
Aktualizace schémat databáze: Schéma všech tenantů se upgraduje současně. Vzhledem k tomu, že všechny tenanty sdílejí tabulku, změna schémat tabulek změní všechny tenanty najednou.
Zásady uchovávání informací a ukládání do mezipaměti: Zásady jsou stejné pro všechny tenanty, protože všechny sdílejí stejnou tabulku.
Hranice zabezpečení na tenanta:
- Pro víceklientskou aplikaci (proxy): Použijte příkaz Restrict.
- Pro uživatele s přímým přístupem: Použijte Zásady zabezpečení na úrovni řádku a seznamte se s jejich omezeními. Poskytnutí přímého přístupu k databázi uživatelům vytvoří závislost na podrobnostech implementace, což ztěžuje změnu implementace. Proto důrazně doporučujeme použít přístup proxy pro přístup k databázi.
Agregace dat z více tenantů ve velkém měřítku: Uživatelé s dostatečnými přístupovými oprávněními můžou spustit standardní agregační dotaz na data více tenantů.
Fragmentace rozsahů: Vzhledem k tomu, že všichni tenanti ingestují data do stejné tabulky, můžou se data obvykle konsolidovat a efektivně ingestovat v jednom nebo několika rozsahech.
Materializovaná zobrazení a strategie rozdělení: Ty lze použít u multitenantních tabulek. Výkon můžete zlepšit rozdělením podle ID nájemce nebo ekvivalentního sloupce. Další informace naleznete v tématu Scénáře zásad oddílů.
Datová připojení Event Grid a Event Hubs: Konsolidovali jste datová připojení, protože data všech tenantů končí v jedné tabulce.
Architektura: Jeden tenant na tabulku v jedné databázi
Tato architektura je kombinací předchozích architektur, kde data všech tenantů končí v jedné databázi, ale v samostatných tabulkách. Tato architektura nedokáže zachytit všechny výhody ostatních architektur.
I když jsou data každého tenanta oddělená, všechny se nacházejí ve stejném kontextu zabezpečení stejné databáze. Podobně jako u architektury s více databázemi může tato architektura vést k fragmentaci. Název tabulky se pro každého tenanta liší, a proto se dotazy musí přizpůsobit pro každého tenanta.