Megosztás a következőn keresztül:

Több-bérlős és Azure Cosmos DB

  • Cikk

Ezen a lapon az Azure Cosmos DB néhány olyan funkcióját ismertetjük, amelyek hasznosak a több-bérlős rendszerek használatakor. Útmutatásra és példákra is hivatkozunk az Azure Cosmos DB több-bérlős megoldásban való használatához.

Az Azure Cosmos DB több-bérlős szolgáltatást támogató funkciói

Particionálás

Ha partíciókat használ az Azure Cosmos DB-tárolókkal, létrehozhat több bérlő között megosztott tárolókat. A bérlőazonosítót általában partíciókulcsként használja, de érdemes lehet több partíciókulcsot is használni egyetlen bérlőhöz. A jól megtervezett particionálási stratégia hatékonyan implementálja a horizontális skálázási mintát. Nagy tárolók esetén az Azure Cosmos DB több fizikai csomóponton is elterjeszti a bérlőket a nagy léptékű skálázás érdekében.

Javasoljuk, hogy vizsgálja meg a hierarchikus partíciókulcsok használatát a több-bérlős megoldás teljesítményének javítása érdekében. A hierarchikus partíciókulcsokkal több értéket tartalmazó partíciókulcsot hozhat létre. Használhat például egy hierarchikus partíciókulcsot, amely tartalmazza a bérlőazonosítót és a tárolt adatok típusát. Ez a megközelítés lehetővé teszi, hogy a partíciókulcs-értékenkénti 20 GB-os logikai partíciókorlátot túllépve méretezhető legyen.

További információ:

Kérelemegységek kezelése

Az Azure Cosmos DB díjszabási modellje a kiépített vagy felhasznált kérelemegységek másodpercenkénti számán alapul. A kérelemegység egy adatbázisművelet vagy -lekérdezés költségeinek logikai absztrakciója. Általában másodpercenként meghatározott számú kérelemegységet kell kiépítenie a számítási feladathoz, amelyet átviteli sebességnek nevezünk. Az Azure Cosmos DB számos lehetőséget kínál az átviteli sebesség kiépítéséhez. Több-bérlős környezetben az Ön által választott beállítás befolyásolja az Azure Cosmos DB-erőforrások teljesítményét és árát.

Az Azure Cosmos DB egyik bérlői modellje magában foglalja külön tárolók üzembe helyezését minden bérlőhöz egy megosztott adatbázisban. Az Azure Cosmos DB lehetővé teszi a kérelemegységek kiépítését egy adatbázishoz, és az összes tároló osztozik a kérelemegységeken. Ha a bérlői számítási feladatok általában nem fedik egymást, ez a módszer segíthet csökkenteni az üzemeltetési költségeket. Ez a megközelítés azonban érzékeny a Zajos szomszéd problémára , mivel egyetlen bérlő tárolója aránytalan mennyiségű megosztott kiosztott kérelemegységet használ fel. A probléma megoldásához először azonosítsa a zajos bérlőket. Ezután igény szerint beállíthatja a kiosztott átviteli sebességet egy adott tárolón. Az adatbázis többi tárolója továbbra is megosztja az átviteli sebességet, de a zajos bérlő saját dedikált átviteli sebességet használ.

Az Azure Cosmos DB kiszolgáló nélküli szintet is biztosít, amely időszakos vagy kiszámíthatatlan forgalommal rendelkező számítási feladatokhoz alkalmas. Másik lehetőségként az automatikus skálázás lehetővé teszi a szabályzatok konfigurálását a kiosztott átviteli sebesség skálázásának megadásához. Emellett kihasználhatja az Azure Cosmos DB kipukkadási kapacitását, maximalizálva a kiosztott átviteli kapacitás kihasználtságát, ami egyébként korlátozott lett volna. Egy több-bérlős megoldásban ezeket a megközelítéseket kombinálhatja a különböző bérlőtípusok támogatásához.

Feljegyzés

Az Azure Cosmos DB-konfiguráció tervezésekor győződjön meg arról, hogy figyelembe veszi a szolgáltatáskvótákat és a korlátokat.

Az egyes bérlőkhöz társított költségek monitorozásához és kezeléséhez az Azure Cosmos DB API-t használó minden művelet tartalmazza a felhasznált kérelemegységeket. Ezekkel az információkkal összesítheti és összehasonlíthatja az egyes bérlők által felhasznált tényleges kérelemegységeket, majd azonosíthatja a különböző teljesítményjellemzőkkel rendelkező bérlőket.

További információ:

Felhasználó által kezelt kulcsok

Előfordulhat, hogy egyes bérlőknek saját titkosítási kulcsokat kell használniuk. Az Azure Cosmos DB egy ügyfél által felügyelt kulcsfunkciót biztosít. Ez a funkció egy Azure Cosmos DB-fiók szintjén van alkalmazva, ezért a saját titkosítási kulcsokat igénylő bérlőket dedikált Azure Cosmos DB-fiókokkal kell üzembe helyezni.

További információ:

Elkülönítési modellek

Az Azure Cosmos DB-t használó több-bérlős rendszer használatakor döntést kell hoznia a használni kívánt elkülönítési szintről. A vállalatközi értékesítés (B2B) egy vállalkozásnak való értékesítést jelenti. Az üzleti felhasználók közötti értékesítés (B2C) a terméket vagy szolgáltatást használó egyéni ügyfélnek való közvetlen értékesítést jelenti. Az Azure Cosmos DB számos elkülönítési modellt támogat:

Számítási feladatokra van szükség Partíciókulcs bérlőnként Tároló bérlőnként (megosztott átviteli sebesség) Tároló bérlőnként (dedikált átviteli sebesség) Bérlőnkénti adatbázis Adatbázisfiók bérlőnként
Bérlők közötti lekérdezések Egyszerű (a tároló a lekérdezések határaként szolgál) Végleges Végleges Végleges Végleges
Bérlői sűrűség Magas (bérlőnkénti legalacsonyabb költség) Közepes Alacsony Alacsony Alacsony
Bérlői adatok törlése Végleges Egyszerű (tároló elvetése a bérlő távozásakor) Egyszerű (tároló elvetése a bérlő távozásakor) Egyszerű (adatbázis elvetése a bérlő távozásakor) Egyszerű (adatbázis elvetése a bérlő távozásakor)
Adathozzáférés biztonsági elkülönítése Az alkalmazáson belül kell implementálnia Tároló RBAC Tároló RBAC Adatbázis RBAC RBAC
Georeplikáció Bérlőnkénti georeplikáció nem lehetséges Bérlők csoportosítása adatbázisfiókokban követelmények alapján Bérlők csoportosítása adatbázisfiókokban követelmények alapján Bérlők csoportosítása adatbázisfiókokban követelmények alapján Bérlők csoportosítása adatbázisfiókokban követelmények alapján
Zajos szomszéd megelőzés Egyik sem Egyik sem Igen Igen Igen
Új bérlőlétrehozási késés Azonnali Gyors Gyors Közepes Lassú
Adatmodellezési előnyök Egyik sem entitások áthelyezése entitások áthelyezése Több tároló bérlői entitások modellezéséhez Több tároló és adatbázis a bérlők modellezéséhez
Titkosítási kulcs Minden bérlő esetében ugyanaz Minden bérlő esetében ugyanaz Minden bérlő esetében ugyanaz Minden bérlő esetében ugyanaz Ügyfél által felügyelt kulcs bérlőnként
Átviteli sebességre vonatkozó követelmények >Bérlőnként 0 kérelemegység >Bérlőnként 100 kérelemegység >Bérlőnként 100 kérelemegység (csak automatikus skálázással, egyébként >bérlőnként 400 kérelemegység) >Bérlőnként 400 kérelemegység >Bérlőnként 400 kérelemegység
Példa használati eset(ek) B2C-alkalmazások Standard ajánlat B2B-alkalmazásokhoz Prémium ajánlat B2B-alkalmazásokhoz Prémium ajánlat B2B-alkalmazásokhoz Prémium ajánlat B2B-alkalmazásokhoz

Partíciókulcs bérlőnként

Ha egyetlen tárolót használ több bérlőhöz, használhatja az Azure Cosmos DB particionálási támogatását. Ha minden bérlőhöz külön partíciókulcsokat használ, egyszerűen lekérdezheti egyetlen bérlő adatait. Több bérlőt is lekérdezhet, még akkor is, ha külön partíciókban vannak. A partíciók közötti lekérdezések azonban magasabb kérelemegység-költségekkel (RU) rendelkeznek, mint az egypartíciós lekérdezések.

Ez a megközelítés általában akkor működik jól, ha az egyes bérlők számára tárolt adatok mennyisége kicsi. Jó választás lehet olyan tarifamodellek létrehozásához, amelyek ingyenes szintet tartalmaznak, valamint üzleti felhasználók számára készült (B2C) megoldásokhoz. Általában a megosztott tárolók használatával éri el a bérlők legnagyobb sűrűségét, ezért a bérlőnkénti legalacsonyabb árat.

Fontos figyelembe venni a tároló átviteli sebességét. Minden bérlő osztozik a tároló átviteli sebességén, így a Zajos szomszéd probléma teljesítményproblémákat okozhat, ha a bérlők magas vagy átfedésben lévő számítási feladatokkal rendelkeznek. Ez a probléma olykor enyhíthető a bérlők részhalmazainak különböző tárolókba való csoportosításával, valamint annak biztosításával, hogy minden bérlőcsoport kompatibilis használati mintákkal rendelkezzen. Alternatív megoldásként hibrid több- és egybérlős modellt is használhat. Csoportosítson kisebb bérlőket megosztott particionált tárolókba, és adjon dedikált tárolókat a nagy ügyfeleknek. Vannak olyan funkciók is, amelyek segíthetnek szabályozni a zajos szomszéd problémát a bérlő partícióval történő modellezésekor, például az átviteli sebesség újraelosztása, a kipukkasztott kapacitás és az átviteli sebesség vezérlése a Java SDK-ban.

Fontos figyelembe venni az egyes logikai partíciókban tárolt adatok mennyiségét is. Az Azure Cosmos DB lehetővé teszi, hogy minden logikai partíció akár 20 GB-ra is nőjön. Ha egyetlen bérlővel rendelkezik, amely több mint 20 GB adatot kell tárolnia, fontolja meg az adatok több logikai partíción való terjesztését. Például ahelyett, hogy egyetlen partíciókulcsot Contosohasználna, a partíciókulcsokat sózhatja úgy, hogy több partíciókulcsot hoz létre egy bérlőhöz, például Contoso1, Contoso2és így tovább. Amikor lekérdezi egy bérlő adatait, a WHERE IN záradék használatával megfelelhet az összes partíciókulcsnak. A hierarchikus partíciókulcsok nagy méretű, 20 GB-nál nagyobb tárterülettel rendelkező bérlők támogatására is használhatók anélkül, hogy bérlőnként szintetikus partíciókulcsokat vagy több partíciókulcs-értéket kellene használniuk.

Vegye figyelembe a megoldás működési szempontjait és a bérlői életciklus különböző fázisait. Ha például egy bérlő egy dedikált tarifacsomagra költözik, valószínűleg át kell helyeznie az adatokat egy másik tárolóba. Ha egy bérlő ki van bontva, le kell futtatnia egy törlési lekérdezést a tárolón az adatok eltávolításához, és a nagy méretű bérlők esetében ez a lekérdezés jelentős átviteli sebességet igényelhet a végrehajtás során.

Tároló bérlőnként

Minden bérlőhöz létrehozhat dedikált tárolókat. A dedikált tárolók akkor működnek jól, ha a bérlő számára tárolt adatok egyetlen tárolóba egyesíthetők. Ez a modell nagyobb teljesítményelkülönítést biztosít, mint a fenti partíciókulcs-bérlőnkénti modell, és az Azure RBAC-en keresztül nagyobb adathozzáférési biztonsági elkülönítést is biztosít.

Ha minden bérlőhöz tárolót használ, fontolja meg az átviteli sebesség más bérlőkkel való megosztását az átviteli sebesség adatbázisszinten történő kiépítésével. Vegye figyelembe az adatbázishoz tartozó kérelemegységek minimális száma és az adatbázisban található tárolók maximális száma körüli korlátozásokat és korlátokat. Azt is mérlegelje, hogy a bérlőknek garantált teljesítményszintre van-e szükségük, és hogy érzékenyek-e a Zajos szomszéd problémára. Ha az átviteli sebességet adatbázisszinten osztja meg, a számítási feladatnak vagy a tárolók tárterületének viszonylag egységesnek kell lennie. Ellenkező esetben zajos szomszédproblémát tapasztalhat, ha egy vagy több nagy bérlő van. Szükség esetén tervezze meg, hogy ezeket a bérlőket különböző, számítási feladatokon alapuló adatbázisokba csoportosítsa.

Másik lehetőségként dedikált átviteli sebességet is kioszthat az egyes tárolókhoz. Ez a megközelítés jól működik a nagyobb bérlők és a zajos szomszéd probléma kockázatának kitett bérlők esetében. Az egyes bérlők alapkonfigurációs átviteli sebessége azonban magasabb, ezért vegye figyelembe a modell minimális követelményeit és költségkövetelményeit.

Ha a bérlői adatmodell egynél több entitást igényel, mindaddig, amíg minden entitás ugyanazt a partíciókulcsot használhatja, ugyanabban a tárolóban helyezhetők el. Ha azonban a bérlői adatmodell összetettebb, és olyan entitásokat igényel, amelyek nem tudják ugyanazt a partíciókulcsot megosztani, tekintse meg az alábbi adatbázis-bérlőnkénti vagy adatbázis-fiókonkénti modelleket. Tekintse meg az Azure Cosmos DB adatainak modellezéséről és particionálásáról szóló cikkünket egy valós példán keresztül, amely további útmutatást nyújt.

Az életciklus-kezelés általában egyszerűbb, ha a tárolók bérlőknek vannak szentelve. A bérlők egyszerűen áthelyezhetők megosztott és dedikált átviteli sebességmodellek között, és a bérlők megszüntetésekor gyorsan törölheti a tárolót.

Bérlőnkénti adatbázis

Minden bérlőhöz kiépítheti az adatbázisokat ugyanabban az adatbázisfiókban. A fenti tárolónkénti modellhez hasonlóan ez a modell nagyobb teljesítményelkülönítést biztosít, mint a partíciókulcs-bérlőnkénti modell, és az Azure RBAC-vel is nagyobb adathozzáférési biztonsági elkülönítést biztosít.

Az alábbi fiókonkénti modellhez hasonlóan ez a megközelítés a legmagasabb szintű teljesítményelkülönítést biztosítja, de a legalacsonyabb bérlői sűrűséget biztosítja. Ez a lehetőség azonban akkor a legjobb, ha minden bérlő bonyolultabb adatmodellt igényel, mint a bérlőnkénti tárolómodellben megvalósítható. Ezt a megközelítést akkor is érdemes követnie, ha az új bérlők létrehozásának előfeltétele, hogy gyorsan és/vagy bármilyen többletterhelés nélkül hozza létre a bérlői fiókokat. A használt szoftverfejlesztési keretrendszer esetében is előfordulhat, hogy a bérlőnkénti adatbázis az egyetlen, a keretrendszerben felismert teljesítményelkülönítési szint. Az entitások (tárolók) szintű elkülönítése és az entitások áthelyezése általában nem támogatott natív módon az ilyen keretrendszerekben.

Adatbázisfiók bérlőnként

Az Azure Cosmos DB lehetővé teszi, hogy minden bérlőhöz külön adatbázisfiókokat építsen ki, amelyek a legmagasabb szintű elkülönítést, de a legalacsonyabb sűrűséget biztosítják. A fenti tároló-bérlőnkénti és az adatbázis-bérlőnkénti modellekhez hasonlóan ez a modell nagyobb teljesítményelkülönítést biztosít, mint a partíciókulcs-bérlőnkénti kulcsmodell. Emellett nagyobb adathozzáférési biztonsági elkülönítést biztosít az Azure RBAC-vel. Emellett ez a modell az ügyfél által felügyelt kulcsok használatával biztosít adatbázis-titkosítási biztonsági elkülönítést a bérlői szinten.

Egyetlen adatbázisfiók dedikált egy bérlőnek, ami azt jelenti, hogy nincsenek kitéve a zajos szomszédproblémáknak. Az adatbázisfiók helyét a bérlő igényei szerint konfigurálhatja. Az Azure Cosmos DB-funkciók konfigurációját, például a georeplikálást és az ügyfél által felügyelt titkosítási kulcsokat is finomhangolhatja az egyes bérlők igényeinek megfelelően. Ha bérlőnként dedikált Azure Cosmos DB-fiókot használ, vegye figyelembe az Azure Cosmos DB-fiókok azure-előfizetésenkénti maximális számát.

Ha ezt a modellt használja, érdemes megfontolnia, hogy az alkalmazásnak milyen gyorsan kell tudnia új bérlőket létrehozni. A fióklétrehozás az Azure Cosmos DB-ben eltarthat néhány percig, ezért előfordulhat, hogy előre kell létrehoznia a fiókokat. Ha ez a megközelítés nem megvalósítható, fontolja meg a bérlőnkénti adatbázismodellt.

Ha engedélyezi a bérlők számára, hogy megosztott fiókból dedikált Azure Cosmos DB-fiókba migráljanak, fontolja meg a bérlő adatainak áthelyezésére használt migrálási módszert a régi és az új fiókok között.

Hibrid megközelítések

A fenti megközelítések kombinációját a különböző bérlők követelményeinek és a tarifamodellnek megfelelően használhatja. Példa:

  • Kiépíthet minden ingyenes próbaverziós ügyfelet egy megosztott tárolóban, és használhatja a bérlőazonosítót vagy egy szintetikus kulcs partíciókulcsát.
  • Kínáljon fizetős bronzszintet , amely bérlőnként egy dedikált tárolót helyez üzembe, de megosztott átviteli sebességgel egy adatbázisban.
  • Magasabb Silver szintet kínál, amely dedikált átviteli sebességet biztosít a bérlő tárolója számára.
  • A legmagasabb aranyszintet kínálhatja, és dedikált adatbázisfiókot biztosíthat a bérlő számára, amely lehetővé teszi a bérlők számára az üzembe helyezés földrajzi helyének kiválasztását is.

Közreműködők

Ezt a cikket a Microsoft tartja karban. Eredetileg a következő közreműködők írták.

Fő szerzők:

  • Paul Burpo | Az Azure-hoz készült FastTrack vezető ügyfélmérnöke
  • John Downs | Az Azure-hoz készült FastTrack vezető ügyfélmérnöke

Egyéb közreműködők:

A nem nyilvános LinkedIn-profilok megtekintéséhez jelentkezzen be a LinkedInbe.

Következő lépések

A több-bérlős tárolás és az adatok megközelítéseinek áttekintése.

További információ a több-bérlősségről és az Azure Cosmos DB-ről:

Tekintse meg a Cosmos DB egyéb architekturális forgatókönyveit: