Megjegyzés
Az oldalhoz való hozzáféréshez engedély szükséges. Megpróbálhat bejelentkezni vagy módosítani a címtárat.
Az oldalhoz való hozzáféréshez engedély szükséges. Megpróbálhatja módosítani a címtárat.
Az Azure Data Explorer több bérlős szolgáltatásának fogalma a különböző bérlők kiszolgálására és az adatok egyetlen fürtben való tárolására vonatkozik.
Important
A több-bérlős megoldás a Microsoft Fabric Real-Time Intelligence számítási feladatában is tervezhető KQL-adatbázisok használatával egy Eventhouse-ban.
A bérlők képviselhetik az ügyfeleket, a felhasználók csoportját vagy a felhasználók bármely besorolását, ahol az adatokat el kell különíteni a bérlők határai mentén. Többszintű több-bérlős rendszert is használhat, például több alkalmazás, amelyek mindegyikének több bérlője van. Ez a cikk nem foglalkozik ezzel a forgatókönyvvel, de hasonló alapelvek érvényesek.
Fontos tényező, hogy a végfelhasználók hogyan férnek hozzá a bérlői adataikhoz. Amikor a végfelhasználók közvetlenül férnek hozzá az Azure Data Explorerhez, a hozzáférés-vezérlést az Azure Data Explorerben kell konfigurálni, hogy elkülönítsék a felhasználó nézetét a saját adataiktól. Amikor egy proxyalkalmazás hozzáfér az adataihoz az Azure Data Explorerben, az alkalmazás elvégezheti az elkülönítést.
Ez a cikk néhány üzembehelyezési architektúrát ismertet, és mindegyikhez biztosít jellemzőket. A jellemzőkkel eldöntheti, hogy melyik architektúra működik a legjobban a megoldáshoz.
Zajos szomszéd
Általánosságban elmondható, hogy a fürt erőforrásainak megosztása számos bérlő között, függetlenül a használt architektúrától, azt jelenti, hogy a különböző bérlők osztoznak a fürt erőforrásain. Ez a zajos szomszéd antipatternhez vezethet.
Ha például egy bérlő sok nagy számítási igényű lekérdezést vagy betöltést hajt végre, a többi bérlőre valószínűleg hatással lesz az erőforrás-éhezés. Ez számítási feladatcsoportok használatával csökkenthető. Szabályzatokat is használhat a gyorsítótárazás és az általános tárolás vezérlésére.
Architektúrák áttekintése
A következő szakaszok részletesen ismertetik az üzembehelyezési architektúrákat. Ez a szakasz összehasonlítja az architektúrákat a döntéshozatal megkönnyítése érdekében.
| Architecture | Strengths |
|---|---|
| Adatbázisonként egy bérlő | - Bérlők elkülönítése: nincs szükség proxyra – Bérlőnként különböző szabályzatok lehetnek, például adatmegőrzési szabályzatok – Rugalmasság a sémafejlődésben bérlőnként – Bérlői adatok egyszerű és gyors eltávolítása |
| Egy tábla több bérlőhöz | - Hatékony adatkonszolidáció és -mértékkezelés - Egyszerűsített sémafejlődés - A materializált nézetekhez leginkább megfelelő - Particionáláshoz ideális |
| Egyetlen adatbázison belül minden egyes táblának egy ügyfele | Nem ajánlott |
Architektúra: Adatbázisonként egy bérlő
Ez egy népszerű és egyenesen előremutató architektúra. Minden bérlő saját adatbázist kap. Minden adatbázis ugyanazzal a sémával rendelkezik.
Az architektúra jellemzői a következők:
Új bérlő kiépítése: Új adatbázis létrehozását és sémaentitások üzembe helyezését igényli.
Bérlő eltávolítása: Az adatbázis törlését igényli. Az adatbázis törlése néhány másodperc alatt elvégezhető. Kevés és állandó erőforrást használ fel, amelyek nem lineárisak a bérlő adatkötetével.
Adatbázisséma-frissítések: Minden klienst különböző időpontokban, egymástól függetlenül lehet frissíteni. Az adatbázisokhoz hozzáférő alkalmazásoknak tisztában kell lenniük az általuk felügyelt adatbázisok verziójával.
Adatmegőrzési és gyorsítótárazási szabályzatok: Minden bérlő saját egyedi szabályzatokkal rendelkezhet, amelyek lehetővé teszik egyéni adatmegőrzési és gyorsítótárazási szabályzatok biztosítását az ügyfelek számára.
Biztonsági határ bérlőnként:
- Több-bérlős alkalmazás (proxy) esetén: Konfigurálja az alkalmazást, hogy az a megfelelő adatbázisra irányuljon. A lekérdezések hozzáférési korlátozásának használatával tiltsa le az adatbázisközi lekérdezéseket.
- Közvetlen hozzáféréssel rendelkező felhasználók számára: A felhasználók az adatbázis szintjén kaphatnak hozzáférést. Ha a felhasználók közvetlen hozzáférést kapnak az adatbázisukhoz, függőséget hoznak létre a megvalósítás részleteihez, ami megnehezíti a megvalósítás módosítását. Ezért erősen javasoljuk, hogy használja a proxy megközelítést az adatbázis eléréséhez.
Több bérlő adatainak összesítése nagy méretekben: Az egyesítő operátor használatával összesítheti az adatokat az adatbázisok között. Ez a módszer azonban nehézkessé válhat a bérlők számának növekedésével. Annak ellenére, hogy az adatok több bérlőből történő összesítése tervezési cél lehet a bérlő szempontjából, a megoldástulajdonos számára fontos lehet az összes bérlő adatainak összesítése a statisztikák gyűjtéséhez.
Terjedelmek töredezettsége: Minden bérlő, amelyik néhány rekordot tölt be adatbázistáblánként, kis terjedelmeket hoz létre, amelyeket később egyesíteni kell. Ez magasabb költséggel jár a mértékkezeléshez. Ezért erősen javasoljuk az adatfolyam-bevitel használatát, például az Event Hubs vagy az Event Grid használata során. A streaming-adatbevitel használatához meg kell győződnie arról, hogy engedélyezve van a fürtön és a táblán.
Materializált nézetek és particionálási szabályzat. A bérlők számának növekedésével fontos megjegyezni, hogy egy fürt hatékony működéséhez a materializált nézetek és partíciószabályzatok száma korlátozott.
Event Grid- és Event Hubs-adatkapcsolatok: Ezek az adatkapcsolatok adatbázisonként jönnek létre. Ezért ehhez az architektúrához szükség van egy adatkapcsolatra és az Event Grid- vagy Event Hubs-példányra bérlőnként, ami növeli a felügyelet összetettségét. Fontolja meg az esemény-útválasztás használatát az Event Hubshoz és az Event Gridhez.
Architektúra: Egy tábla több bérlőhöz
Ez az architektúra agresszívabb a konszolidálás során, és egyetlen adatbázist használ az összes bérlő számára. Az adatbázis minden táblája rendelkezik bérlőazonosító oszloppal vagy azzal egyenértékűvel, amely lehetővé teszi egyetlen bérlő adatainak szűrését. A táblák bérlőnként particionálhatók a lekérdezési teljesítmény javítása érdekében, mivel a legtöbb lekérdezés valószínűleg bérlőnként szűr. Ahol lehetséges, fontolja meg a partíciót egy másik oszlopban egy összetett partíciókulcs használatával. Létrehozhat például egy összetett partíciókulcsot, amely összefűzi a bérlőazonosítót és egy másik oszlop értékeit.
Az architektúra jellemzői a következők:
Új bérlő kiépítése: Az új bérlő kiépítése nem igényel adatbázis-létrehozást vagy sémamódosítást. Az új bérlőazonosítót új rekordokban használják.
Bérlő eltávolítása: A bérlő adatainak helyreállítható törlését vagy törlését igényli. A hét végén például több törlést is kötegethet, hogy korlátozza az erőforrás-felhasználásra gyakorolt hatást.
Az adatbázissémák frissítése: A bérlők sémái egyszerre frissülnek. Mivel az összes bérlő megosztja a táblát, a táblaséma módosítása egyszerre módosítja az összes bérlőt.
Adatmegőrzési és gyorsítótárazási irányelvek: Az irányelvek minden bérlő esetében megegyeznek, mivel mindegyikük megosztja ugyanazt a táblát.
Biztonsági határ bérlőnként:
- Több-bérlős alkalmazás (proxy) esetén: Használja a Korlátozás utasítást
- Közvetlen hozzáféréssel rendelkező felhasználók számára: Használja a sorszintű biztonsági szabályzatot , és ismerkedjen meg a korlátozásokkal. Ha a felhasználók közvetlen hozzáférést kapnak az adatbázisukhoz, függőséget hoznak létre a megvalósítás részleteihez, ami megnehezíti a megvalósítás módosítását. Ezért erősen javasoljuk, hogy használja a proxy megközelítést az adatbázis eléréséhez.
Több bérlő adatainak nagy léptékű összesítése: A megfelelő hozzáférési engedélyekkel rendelkező felhasználók szabványos összesítő lekérdezést futtathatnak több bérlő adatain.
Mértékek töredezettsége: Mivel minden bérlő ugyanabba a táblába betölti az adatokat, az adatok általában egy vagy néhány mértékben konszolidálhatók és hatékonyan betölthetők.
Materializált nézetek és particionálási szabályzat: Ezek több-bérlősű táblákon használhatók. A teljesítmény javítása érdekében az Bérlő ID vagy az azzal egyenértékű oszlop alapján végezhet particionálást. További információt a partíciószabályzatok forgatókönyvei című témakörben talál.
Event Grid- és Event Hubs-adatkapcsolatok: Konszolidált adatkapcsolatok, mivel az összes bérlő adatai egy táblába kerülnek.
Architektúra: Egy bérlő táblánként egyetlen adatbázisban
Ez az architektúra a korábbi architektúrák kombinációja, ahol az összes bérlő adatai egyetlen adatbázisban, de különálló táblákban végződnek. Ez az architektúra nem rögzíti a többi architektúra összes előnyét.
Bár az egyes bérlők adatai külön vannak elkülönítve, mindegyik ugyanabban az adatbázisban található. A többadatbázisos architektúrához hasonlóan ez az architektúra is nagy mértékben töredezettséghez vezethet. A tábla neve minden bérlő esetében eltérő, ezért a lekérdezéseket minden bérlőhöz testre kell szabni.