Particionálás és horizontális skálázás az Azure Cosmos DB-ben

Az Azure Cosmos DB particionálással skálázza az adatbázis tárolóit az alkalmazás teljesítményigényeinek megfelelően. A tároló elemei különböző részhalmazokra, úgynevezett logikai partíciókra vannak osztva. A logikai partíciók a tároló minden eleméhez társított partíciókulcs értéke alapján alakulnak ki. A logikai partíció összes eleme ugyanazzal a partíciókulcs-értékkel rendelkezik.

Egy tároló például elemeket tartalmaz. Minden elem egyedi értékkel rendelkezik a UserID tulajdonsághoz. Ha UserID a tároló elemeinek partíciókulcsaként szolgál, és 1000 egyedi UserID érték található, a tárolóhoz 1000 logikai partíció jön létre.

A tároló minden eleme rendelkezik partíciókulcsokkal , amelyek meghatározzák annak logikai partícióját és a partíción belül egyedi elemazonosítót . A partíciókulcs és az elemazonosító kombinálásával létrejön az elem indexe, amely egyedileg azonosítja az elemet. A partíciókulcs kiválasztása fontos döntés, amely befolyásolja az alkalmazás teljesítményét.

Megjegyzés:

Egyes elosztott adatbázisrendszerekben és tananyagokban a szegmenskulcs kifejezés azt a tulajdonságot írja le, amely meghatározza, hogyan oszlanak el az adatok a szegmensek között. Az Azure Cosmos DB-ben ugyanezt a koncepciót nevezzük partíciókulcsnak.

Mindkét kifejezés az adatok terjesztésére és megkeresésére használt értékre vonatkozik, de a partíciókulcs az Azure Cosmos DB dokumentációjában és API-jaiban használt hivatalos és helyes kifejezés.

Ez a cikk ismerteti a logikai és fizikai partíciók közötti kapcsolatot, ismerteti a particionálás ajánlott eljárásait, és részletes áttekintést nyújt a horizontális skálázás működéséről az Azure Cosmos DB-ben. A partíciókulcs kiválasztásához nem kell ismernie ezeket a belső részleteket, de ez a cikk ismerteti őket, hogy tisztázza az Azure Cosmos DB működését.

Logikai partíciók

A logikai partíció olyan elemek készlete, amelyek ugyanazt a partíciókulcsot használják. Egy élelmiszer-táplálkozással kapcsolatos adatokat tartalmazó tárolóban például minden elem tartalmaz egy tulajdonságot foodGroup . Használja foodGroup partíciókulcsként a tárolóhoz. Az olyan elemek csoportjai, amelyek meghatározott értékekkel foodGrouprendelkeznek, például Beef Products, Baked Productsés Sausages and Luncheon Meats, különböző logikai partíciókat alkotnak.

A logikai partíció az adatbázis-tranzakciók hatókörét is meghatározza. A logikai partíción belüli elemeket pillanatkép-elkülönítéssel rendelkező tranzakcióval frissítheti. Amikor új elemeket ad hozzá egy tárolóhoz, a rendszer transzparens módon új logikai partíciókat hoz létre. A mögöttes adatok törlésekor nem kell aggódnia egy logikai partíció törlése miatt.

A tárolóban nincs korlátozva a logikai partíciók száma. Minden logikai partíció legfeljebb 20 GB adatot tárolhat. A hatékony partíciókulcsok számos lehetséges értékkel rendelkeznek. Például egy olyan tárolóban, amelyben minden elem tartalmaz egy tulajdonságot foodGroup , a Beef Products logikai partíción belüli adatok akár 20 GB-ra is növekedhetnek. Ha olyan partíciókulcsot választ ki, amely számos lehetséges értékkel rendelkezik, akkor a tároló méretezhető.

Ha rendelkezel olyan forgatókönyvekkel, amelyekben a partíciókulcsok meghaladják a 20 GB-nyi adatot, hierarchikus partíciókulcsok használata segíthet. Ha ezt a funkciót használja, akár háromszintű hierarchiát is konfigurálhat a partíciókulcsokhoz az adatterjesztés további optimalizálásához és a magasabb szintű skálázáshoz. Tekintse mega hierarchikus partíciókulcsok áttekintését.

Az Azure Monitor-riasztásokkal figyelheti, hogy egy logikai partíció mérete megközelíti-e a 20 GB-ot.

Fizikai partíciók

A tároló méretezhető az adatok és az átviteli sebesség fizikai partíciók közötti elosztásával. Belsőleg egy vagy több logikai partíció egyetlen fizikai partícióra van leképezve. A kisebb tárolók általában sok logikai partícióval rendelkeznek, de csak egyetlen fizikai partíciót igényelnek. A logikai partíciókkal ellentétben a fizikai partíciók belső rendszer-implementációk, és az Azure Cosmos DB teljes mértékben kezeli őket.

A tárolóban lévő fizikai partíciók száma az alábbi jellemzőktől függ:

• A kiosztott átviteli sebesség mennyisége (minden egyes fizikai partíció másodpercenként legfeljebb 10 000 kérelemegységet képes biztosítani). A fizikai partíciók 10 000 RU/s korlátja azt jelenti, hogy a logikai partíciók 10 000 RU/s korlátot is tartalmazhatnak, mivel minden logikai partíció csak egy fizikai partícióra van leképezve.

• A teljes adattárolás (minden egyes fizikai partíció legfeljebb 50 gigabájtnyi adatot tárolhat).

Megjegyzés:

A fizikai partíciók az Azure Cosmos DB által teljes körűen felügyelt belső rendszer-implementációk. A megoldások fejlesztésekor ne a fizikai partíciókra koncentráljon, mert nem tudja vezérelni őket. Ehelyett a partíciókulcsokra koncentráljon. Ha olyan partíciókulcsot választ, amely egyenletesen osztja el az átviteli sebességet a logikai partíciók között, biztosítja a fizikai partíciók közötti kiegyensúlyozott átviteli sebesség használatát.

A tárolóban nincs korlátozva a fizikai partíciók teljes száma. A kiosztott átviteli sebesség vagy adatméret növekedésével az Azure Cosmos DB automatikusan új fizikai partíciókat hoz létre a meglévők felosztásával. A fizikai partíciófelosztások nem befolyásolják az alkalmazás rendelkezésre állását. A fizikai partíció felosztása után az egyetlen logikai partíción belüli összes adat továbbra is ugyanazon a fizikai partíción lesz tárolva. A fizikai partíciók felosztása egyszerűen létrehozza a logikai partíciók új leképezését a fizikai partíciókhoz.

A tároló kiosztott átviteli sebessége egyenlően oszlik el a fizikai partíciók között. A partíciókulcsok olyan kialakítása, amely nem egyenletesen osztja el a kéréseket, túl sok kérést eredményezhet, amelyek a partíciók egy kis részhalmazára irányulnak, és "gyakori elérésűvé" válnak. A gyakori elérésű partíciók a kiosztott átviteli sebesség nem hatékony használatát okozzák, ami sebességkorlátozást és magasabb költségeket eredményezhet.

Vegyük például a partíciókulcsként megadott elérési utat /foodGroup tartalmazó tárolót. A tároló tetszőleges számú fizikai partícióval rendelkezhet, de ebben a példában feltételezzük, hogy három partícióval rendelkezik. Egyetlen fizikai partíció több partíciókulcsot is tartalmazhat. A legnagyobb fizikai partíció például a három legjelentősebb méretű logikai partíciót tartalmazza: Beef Products, Vegetable and Vegetable Productsés Soups, Sauces, and Gravies.

Ha másodpercenként 18 000 kérelemegységet (RU/s) rendel hozzá, a három fizikai partíció mindegyike a teljes kiosztott átviteli sebesség egyharmadát használja. A kijelölt fizikai partíción belül a logikai partíciókulcsok Beef Productsegyüttesen Vegetable and Vegetable ProductsSoups, Sauces, and Gravies használhatják a fizikai partíció 6000 kiosztott RU/s-ját. Mivel a kiosztott átviteli sebesség egyenlően oszlik el a tároló fizikai partíciói között, fontos olyan partíciókulcsot választani, amely egyenletesen osztja el az átviteli sebesség használatát. További információ: A megfelelő logikai partíciókulcs kiválasztása.

Logikai partíciók kezelése

Az Azure Cosmos DB automatikusan kezeli a logikai partíciók fizikai partíciókon való elhelyezését, hogy megfeleljen a tároló méretezhetőségi és teljesítményigényének. Amikor egy alkalmazás átviteli sebessége és tárolási követelményei megnőnek, az Azure Cosmos DB logikai partíciókat helyez át, hogy a terhelést több fizikai partíció között terjessze el. További információ a fizikai partíciókról.

Az Azure Cosmos DB kivonatalapú particionálást használ a logikai partíciók fizikai partíciók közötti elosztásához. Az Azure Cosmos DB kivonatot ad egy elem partíciókulcs-értékéről. A kivonatolt eredmény határozza meg a logikai partíciót. Ezután az Azure Cosmos DB egyenletesen elosztja a partíciókulcsok hash értékeinek kulcsterét a fizikai partíciók között.

A tárolt eljárásokban vagy eseményindítókban lévő tranzakciók csak egyetlen logikai partíció elemeire engedélyezettek.

Replikakészletek

Minden fizikai partíció replikák készletéből áll, más néven replikakészletből. Minden replika az adatbázismotor egy példányát üzemelteti. A replikakészletek tartóssá, magas rendelkezésre állásúvá és konzisztenssé teszik a fizikai partíción belüli adattárat. A fizikai partíció minden replikája örökli a partíció tárolási kvótáját. A fizikai partíció összes replikája együttesen támogatja az adott fizikai partícióhoz lefoglalt átviteli sebességet. Az Azure Cosmos DB automatikusan kezeli a replikakészleteket.

A kisebb tárolók általában egyetlen fizikai partíciót igényelnek, de még mindig legalább négy replikával rendelkeznek.

Ez a kép azt mutatja be, hogy a logikai partíciók hogyan képezhetők le a globálisan elosztott fizikai partíciókra. A képen látható partíciókészlet olyan fizikai partíciók csoportjára utal, amelyek ugyanazt a logikai partíciókulcsot kezelik több régióban:

Partíciókulcs kiválasztása

A partíciókulcsnak két összetevője van: a partíciókulcs elérési útja és a partíciókulcs értéke. Ha például a "userId" elemet { "userId" : "Andrew", "worksFor": "Microsoft" } választja partíciókulcsként, akkor a következő két partíciókulcs-összetevőt kell figyelembe vennie:

• A partíciókulcs elérési útja (például: "/userId"). A partíciókulcs elérési útja alfanumerikus és aláhúzásjeles (_) karaktereket fogad el. Beágyazott objektumokat a szabványos elérési út jelölésével(/) is használhat.

• A partíciókulcs értéke (például "András"). A partíciókulcs értéke sztring- vagy numerikus típusú lehet.

Az Azure Cosmos DB szolgáltatáskvóta-cikkében megismerheti az átviteli sebesség, a tárolás és a partíciókulcs hosszának korlátait.

A partíciókulcs kiválasztása egyszerű, de fontos tervezési választás az Azure Cosmos DB-ben. Miután kiválasztotta a partíciókulcsot, nem változtathatja meg. Ha módosítania kell a partíciókulcsot, helyezze át az adatokat egy új tárolóba a kívánt partíciókulcs használatával. A tárolómásolási feladatok segítenek ebben a folyamatban. Alternatív megoldásként globális másodlagos indexeket (előzetes verziót) is hozzáadhat az adatok másolatának létrehozásához, amelyek különböző, adott lekérdezési mintákhoz optimalizált partíciókulcsokkal lettek optimalizálva.

Minden tároló esetében a partíciókulcsnak a következőnek kell lennie:

• Legyen olyan tulajdonság, amelynek értéke nem változik. Ha egy tulajdonság partíciókulcs, nem frissíthető az értéke.

• Csak String értékeket tartalmazzon, vagy alakítsa a számokat String formátummá, amennyiben túlléphetik a kettős pontosságú számok határait az Institute of Electrical and Electronics Engineers (IEEE) 754 bináris64 szerint. A Json-specifikáció elmagyarázza, hogy miért rossz gyakorlat az ezen a határon kívüli számok használata az együttműködési problémák miatt. Ezek az aggodalmak különösen relevánsak a partíciókulcs oszlopa szempontjából, mert nem módosítható, és a módosításhoz adatmigrálás szükséges.

• Magas számossággal rendelkezik. Más szóval a tulajdonságnak számos lehetséges értékkel kell rendelkeznie.

• A kérelemegység (RU) használata és az adattárolás egyenlően oszlik el az összes logikai partíción. Ez az elosztás biztosítja az egyenletes RU-fogyasztást és a tárolási eloszlást a fizikai partíciók között.

• Az értékek általában nem lehetnek nagyobbak 2048 bájtnál, vagy 101 bájtnál, ha a nagy partíciókulcsok nincsenek engedélyezve. További információ: nagyméretű partíciókulcsok

Ha többtételes ACID-tranzakciókra van szüksége az Azure Cosmos DB-ben, tárolt eljárásokat vagy eseményindítókat kell használnia. Minden JavaScript-alapú tárolt eljárás és eseményindító egyetlen logikai partícióra terjed ki.

Megjegyzés:

Ha csak egy fizikai partícióval rendelkezik, vagy a partíciók száma kicsi, például <= 5, előfordulhat, hogy a partíciókulcs értéke nem releváns. Lekérdezések esetén, ha a partíciókulcs nincs megadva, az egyes további fizikai partíciók ellenőrzésének többletterhelése fizikai partíciónként 2–3 RU. További információ a fizikai partíciókról.

A partíciókulcsok típusai

Particionálási stratégia	Mikor érdemes használni?	Előnyök	Hátrányok
Normál partíciókulcs (például VevőAz, RendelésAz)	Akkor használható, ha a partíciókulcs nagy számossággal rendelkezik, és megfelel a lekérdezési mintáknak (például a CustomerId szerinti szűrésnek). Olyan számítási feladatokhoz alkalmas, ahol a lekérdezések többnyire egyetlen ügyfél adatait célják meg (például egy ügyfél összes rendelésének lekérése).	Egyszerűen kezelhető. Hatékony lekérdezések, ha a hozzáférési minta megfelel a partíciókulcsnak (például az összes rendelést a CustomerId alapján kérdezi le). Megakadályozza a partíciók közötti lekérdezéseket, ha a hozzáférési minták konzisztensek.	Forró partíciók kockázata áll fenn, ha egyes értékek (például néhány nagy forgalmú ügyfél) több adatot generálnak, mint mások. A logikai partíciónkénti 20 GB-os korlátot akkor érheti el, ha egy adott kulcs adatmennyisége gyorsan növekszik.
Szintetikus partíciókulcs (például CustomerId + OrderDate)	Akkor használható, ha egyetlen mező sem rendelkezik magas számossággal, és megfelel a lekérdezési mintáknak. Kiválóan alkalmas olyan írási feladatokhoz, ahol az adatokat egyenletesen kell elosztani a fizikai partíciók között (például az ugyanazon a napon leadott megrendelések száma).	Segít egyenletesen elosztani az adatokat a partíciók között, csökkentve a nyomáspontokat (például a rendeléseket mind a CustomerId, mind az OrderDate szerint is). Az írás több partícióra oszlik és növeli az adatátviteli kapacitást.	Azok a lekérdezések, amelyek csak egy mező alapján szűrnek (például csak CustomerId) keresztpartíciós lekérdezéseket eredményezhetnek. A partíciók közötti lekérdezések magasabb ru-használathoz (minden létező fizikai partícióhoz 2-3 RU/s többletköltséget) és további késést eredményezhetnek.
Hierarchikus partíciókulcs (HPK) (például VevőId/RendelésId, BoltId/TermékId)	Akkor használható, ha többszintű particionálásra van szüksége a nagy méretű adathalmazok támogatásához. Ideális, ha a lekérdezések a hierarchia első és második szintjén szűrnek.	Több particionálási szint létrehozásával elkerülheti a 20 GB-os korlátot. Hatékony lekérdezés mindkét hierarchikus szinten (például először a CustomerID, majd az OrderID alapján történő szűrés). Minimálisra csökkenti a legfelső szintet megcélzó lekérdezések partícióközi lekérdezéseit (például az összes adat lekérése egy adott CustomerID-ből).	Gondos tervezést igényel annak biztosításához, hogy az első szintű kulcs magas kardinalitással rendelkezzen, és a legtöbb lekérdezésnél szerepeljen. Összetettebb a kezelése, mint egy hagyományos partíciókulcsnak. Ha a lekérdezések nem összhangban vannak a hierarchiával (például csak az OrderID alapján szűrnek, ha a CustomerID az első szint), akkor a lekérdezési teljesítmény szenvedhet.
Globális másodlagos index (GSI) – előzetes verzió (például a forrás a CustomerId azonosítót használja, a GSI az OrderId azonosítót használja)	Akkor használja, ha nem talál egyetlen partíciókulcsot, amely minden lekérdezési mintához működik. Ideális olyan számítási feladatokhoz, amelyeknek több független tulajdonsággal kell hatékonyan lekérdezni, és nagy számú fizikai partícióval kell rendelkezniük.	Megszünteti a partíciók közötti lekérdezéseket a GSI partíciókulcs használatakor. Több lekérdezési mintát is engedélyez ugyanazon az adaton a forrástároló automatikus szinkronizálásával. Teljesítményelkülönítés a számítási feladatok között.	Minden GSI-nek további tárolási és ru-költségei vannak. A GSI-ben lévő adatok végül konzisztensek a forrástárolóval.

Partíciókulcsok olvasás-intenzív tárolókhoz

A legtöbb tároló esetében csak ezeket a feltételeket kell figyelembe vennie a partíciókulcs kiválasztásakor. A nagy méretű írásvédett tárolók esetében azonban érdemes lehet olyan partíciókulcsot választania, amely szűrőként gyakran jelenik meg a lekérdezésekben. A szűrési predikátum partíciókulcsának használatával a lekérdezések hatékonyan irányíthatók csak a megfelelő fizikai partíciókra.

Ez a tulajdonság jó partíciókulcs-választás, ha a számítási feladat legtöbb kérése lekérdezés, és a lekérdezések többsége egyenlőségszűrőt használ ugyanazon a tulajdonságon. Ha például gyakran futtat egy olyan lekérdezést, amely -re szűr, akkor kiválasztása partíciókulcsként csökkenti a partíciók közötti lekérdezések számát.

Ha a tároló kicsi, valószínűleg nincs elegendő fizikai partíció, mely miatt aggódnia kellene a partíciók közötti lekérdezések teljesítménye miatt. Az Azure Cosmos DB kis tárolóinak többsége csak egy vagy két fizikai partíciót igényel.

Ha a tároló több fizikai partícióra is nőhet, akkor mindenképpen válasszon olyan partíciókulcsot, amely minimalizálja a partíciók közötti lekérdezéseket. A tárolónak több fizikai partícióra van szüksége, ha az alábbi forgatókönyvek valamelyike igaz:

• A konténerben több mint 30 000 kérelemegység van biztosítva

• A tároló több mint 100 GB adatot tárol

Globális másodlagos indexek keresztpartíciós lekérdezésekhez

Ha az alkalmazásnak több különböző tulajdonsággal kell hatékonyan lekérdeznie az adatokat, a globális másodlagos indexek (előzetes verzió) alternatívát kínálnak egy partíciókulcs-stratégia használatára az adathalmazhoz. A globális másodlagos indexek további tárolók különböző partíciókulcsokkal, amelyek automatikusan szinkronizálódnak a forrástároló adataival.

A globális másodlagos indexeket akkor érdemes figyelembe venni, ha:

• Több olyan lekérdezési mintával rendelkezik, amelyeket egyetlen partíciókulcs-stratégia nem tud kielégíteni
• A meglévő partíciókulcs módosítása zavaró lenne
• El kell különítenie az elemzési vagy keresési számítási feladatokat a tranzakciós műveletektől

A globális másodlagos indexek segítenek elkerülni a partíciók közötti lekérdezéseket azáltal, hogy ugyanazokat az adatokat különböző, adott lekérdezési mintákhoz optimalizált partíciókulcsokkal tárolja. Ez a megközelítés jelentősen csökkentheti az ru-használatot, és javíthatja a lekérdezési teljesítményt olyan helyzetekben, ahol a partíciókulcs optimalizálása önmagában nem elegendő.

Elemazonosító használata partíciókulcsként

Megjegyzés:

Ez a szakasz elsősorban a NoSQL API-ra vonatkozik. Más API-k, például a Gremlin API nem támogatják az egyedi azonosítót partíciókulcsként.

Ha a tároló rendelkezik olyan tulajdonsággal, amely számos lehetséges értékkel rendelkezik, valószínűleg nagyszerű partíciókulcs-választás. Ilyen tulajdonság például az elemazonosító. Kis méretű, olvasásintenzív vagy bármilyen méretű írásintenzív tárolók esetén az elemazonosító (/id) természetesen kiváló választás a partíció kulcsának.

A rendszertulajdonság-elem azonosítója a tároló minden elemében megtalálható. Előfordulhat, hogy más tulajdonságai is vannak, amelyek az elem logikai azonosítóját jelölik. Ezek az egyedi azonosítók sok esetben kiváló partíciókulcs-választást is jelentenek az elemazonosítóval azonos okokból.

Az elemazonosító kiváló partíciókulcs-választás a következő okokból:

• A lehetséges értékek széles skálája létezik (elemenként egy egyedi elemazonosító ).
• Mivel elemenként egyedi elemazonosító van, az elemazonosító kiválóan működik az ru-használat és az adattárolás egyenlő kiegyenlítésében.
• A pontolvasások egyszerűen elvégezhetők, mivel mindig ismeri az elemek partíciókulcsát, ha ismeri annak elemazonosítóját.

Az elemazonosító partíciókulcsként való kiválasztásakor vegye figyelembe az alábbi kifogásokat:

• Ha az elemazonosító a partíciókulcs, az a teljes tároló egyedi azonosítójává válik. Ismétlődő azonosítókkal rendelkező elemek nem hozhatók létre.
• Ha van egy olvasás-intenzív tároló sok fizikai partícióval, a lekérdezések hatékonyabbak, ha egyenlőségszűrővel rendelkeznek az elemazonosítóval.
• A tárolt eljárások vagy triggerek nem célozhatnak meg több logikai partíciót.

Kapcsolódó tartalom

• Kiosztott átviteli sebesség az Azure Cosmos DB-ben
• Globális terjesztés az Azure Cosmos DB-ben
• Oktatás: adatok modellezése és particionálása az Azure Cosmos DB-ben