Particionálás és horizontális skálázás az Azure Cosmos DB-ben
A KÖVETKEZŐKRE VONATKOZIK: 
NoSQL MongoDB Cassandra Gremlin Asztal
Az Azure Cosmos DB particionálással skálázza az egyes tárolókat az adatbázisban az alkalmazás teljesítményigényének 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 jönnek létre. 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.
Az elem logikai partícióját meghatározó partíciókulcs mellett a tároló minden eleme rendelkezik egy elemazonosítóval (amely egy logikai partíción belül egyedi). 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.
Ez a cikk a logikai és a fizikai partíciók közötti kapcsolatot ismerteti. Emellett 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 szükséges megérteni ezeket a belső részleteket, de ezeket lefedjük, hogy egyértelmű legyen az Azure Cosmos DB működése.
Logikai partíciók
A logikai partíciók olyan elemekből állnak, amelyek ugyanazt a partíciókulcsot tartalmazzák. Egy élelmiszer-táplálkozással kapcsolatos adatokat tartalmazó tárolóban például minden elem tartalmaz egy tulajdonságot foodGroup . A tároló partíciókulcsaként is használható foodGroup . 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 jó partíciókulcs-választás számos lehetséges értékkel rendelkezik. 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ő.
Az Azure Monitor-riasztások segítségével figyelheti, hogy egy logikai partíció mérete megközelíti-e a 20 GB-ot.
Fizikai partíciók
A tárolók méretezése az adatok és az átviteli sebesség fizikai partíciók közötti elosztásával történik. 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 a rendszer belső implementációi, és az Azure Cosmos DB teljes mértékben kezeli a fizikai partíciókat.
A tárolóban lévő fizikai partíciók száma a következő 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 GB adatot tárolhat).
Feljegyzés
A fizikai partíciók a rendszer belső implementációi, és teljes mértékben az Azure Cosmos DB kezeli őket. A megoldások fejlesztésekor ne a fizikai partíciókra koncentráljon, mert nem tudja vezérelni őket. Ehelyett koncentráljon a partíciókulcsokra. Ha olyan partíciókulcsot választ, amely egyenletesen osztja el az átviteli sebesség használatát a logikai partíciók között, akkor gondoskodni fog arról, hogy a fizikai partíciók átviteli sebességének felhasználása kiegyensúlyozott legyen.
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óhoz kiosztott átviteli sebesség 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 eredményezik, 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á, akkor a három fizikai partíció mindegyike a teljes kiosztott átviteli sebesség 1/3-át használhatja. 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 transzparens módon és automatikusan kezeli a logikai partíciók fizikai partíciókon való elhelyezését, hogy hatékonyan kielégítse a tároló méretezhetőségét és teljesítményigényét. Az alkalmazások átviteli sebességének és tárolási követelményeinek növekedésével az Azure Cosmos DB áthelyezi a logikai partíciókat, hogy automatikusan eloszthassa a terhelést nagyobb számú fizikai partíció között. 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 lefoglalja a partíciókulcs-kivonatok kulcsterét a fizikai partíciók között.
A tranzakciók (tárolt eljárásokban vagy eseményindítókban) csak egyetlen logikai partíció elemein 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ót alkotó replikák öröklik a partíció tárolási kvótáját. A fizikai partíció összes replikája együttesen támogatja a fizikai partícióhoz lefoglalt átviteli sebességet. Az Azure Cosmos DB automatikusan kezeli a replikakészleteket.
A kisebb tárolók általában csak egyetlen fizikai partíciót igényelnek, de legalább négy replikával rendelkeznek.
Az alábbi képen látható, hogy a logikai partíciók hogyan vannak leképezve 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 vá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.
A partíciókulcs átviteli sebességére, tárolására és hosszára vonatkozó korlátokról az Azure Cosmos DB szolgáltatáskvóta-cikkében olvashat.
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 lehet helyben módosítani. Ha módosítania kell a partíciókulcsot, helyezze át az adatokat egy új tárolóba az új kívánt partíciókulcs használatával. (A tárolómásolási feladatok segítenek ebben a folyamatban.)
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 a partíciókulcs, nem frissítheti a tulajdonság értékét.
Csak értékeket kell tartalmaznia
String, vagy a számokat ideális esetben konvertálniStringkell, ha van rá esély, hogy az IEEE 754 bináris64 szerint a kettős pontosságú számok határain kívül vannak. A Json-specifikáció felhívja azokat az okokat, amelyek miatt a határokon kívüli számok használata általában rossz gyakorlat, mivel valószínűleg együttműködési problémákat okoz. Ezek az aggodalmak különösen fontosak a partíciókulcs oszlopában, mivel nem módosítható, és az adatmigrálást igényli a későbbi módosításhoz.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 a felosztás még a fizikai partíciók ru-használatát és tárolási elosztását is biztosítja.
Általában 2048 bájtnál nem nagyobb értékek, vagy 101 bájt, 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.
Feljegyzés
Ha csak egy fizikai partícióval rendelkezik, előfordulhat, hogy a partíciókulcs értéke nem releváns, mivel minden lekérdezés ugyanazt a fizikai partíciót célozza meg.
Partíciókulcsok írásvédett tárolókhoz
A legtöbb tároló esetében csak a fenti kritériumokat kell figyelembe vennie egy 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 lekérdezések hatékonyan irányíthatók csak a megfelelő fizikai partíciókra a partíciókulcs szűrő predikátumba való belefogadásával.
Ez a tulajdonság akkor lehet jó partíciókulcs-választás, ha a számítási feladat legtöbb kérése lekérdezés, és a legtöbb lekérdezés egyenlőségi szűrővel rendelkezik ugyanazon a tulajdonságon. Ha például gyakran futtat egy olyan lekérdezést, amely szűrUserID, akkor a partíciókulcsként való UserID kijelölés csökkenti a partíciók közötti lekérdezések számát.
Ha azonban a tároló kicsi, akkor valószínűleg nem rendelkezik elegendő fizikai partícióval ahhoz, hogy aggódnia kell a partíciók közötti lekérdezések teljesítményével kapcsolatban. 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ó több fizikai partíciót igényel, ha az alábbiak bármelyike igaz:
A tárolóban több mint 30 000 kérelemegység van kiépítve
A tároló több mint 100 GB adatot tárol
Elemazonosító használata partíciókulcsként
Feljegyzé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ó olyan tulajdonságot tartalmaz, amely számos lehetséges értékkel rendelkezik, valószínűleg nagyszerű partíciókulcs-választás. Az ilyen tulajdonságok egyik lehetséges példája az elemazonosító. Kis méretű írásvédett vagy írási nehéz tárolók esetén az elemazonosító (/id) természetesen kiváló választás a partíciókulcshoz.
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 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.
A partíciókulcsként az elemazonosító kiválasztásakor megfontolandó szempontok a következők:
- Ha az elemazonosító a partíciókulcs, az a teljes tárolóban egyedi azonosítóvá válik. Nem hozhat létre ismétlődő elemazonosítókkal rendelkező elemeket.
- Ha sok fizikai partícióval rendelkező írásvédett tárolóval rendelkezik, a lekérdezések hatékonyabbak, ha egyenlőségszűrővel rendelkeznek az elemazonosítóval.
- Nem futtathat olyan tárolt eljárásokat vagy eseményindítókat, amelyek több logikai partíciót céloznak meg.