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

  • Cikk
  • 9 perc alatt elolvasható

A KÖVETKEZŐKRE VONATKOZIK: SQL API Cassandra API Gremlin API Table API Azure Cosmos DB API for MongoDB

Az Azure Cosmos DB particionálással skálázza az adatbázis egyes tárolóit az alkalmazás teljesítményigényeinek megfelelően. A particionálás során 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ó, 1000 logikai partíció jön létre a tárolóhoz.

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 hatással lesz az alkalmazás teljesítményére.

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észletesen bemutatja, hogyan működik a horizontális skálázás az Azure Cosmos DB-ben. A partíciókulcs kiválasztásához nem szükséges tisztában lenni ezekkel a belső részletekkel, de már foglalkoztunk velük, hogy egyértelmű legyen az Azure Cosmos DB működése.

Logikai partíciók

A logikai partíció olyan elemekből áll, amelyek azonos partíciókulccsal rendelkeznek. Például egy élelmiszer-táplálkozással kapcsolatos adatokat tartalmazó tárolóban minden elem tartalmaz egy tulajdonságot foodGroup . A tároló partíciókulcsaként is használható foodGroup . Az olyan elemek csoportjai, amelyek adott é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ók elemeit 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 hozza létre az új logikai partíciókat. 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 adat tárolására képes. 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. A lehetséges értékek széles skáláját tartalmazó partíciókulcs kiválasztása biztosítja, hogy a tároló skálázható legyen.

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 teljes egészében az Azure Cosmos DB kezeli őket.

A tárolóban lévő fizikai partíciók száma a következő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-os adatokat tárolhat).

Megjegyzés

A fizikai partíciók a rendszer belső implementációi, amelyeket teljes egészében az Azure Cosmos DB kezel. A megoldások fejlesztésekor ne a fizikai partíciókra koncentráljon, mert nem tudja szabályozni ő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, gondoskodni fog arról, hogy a fizikai partíciók átviteli sebességének felhasználása egyensúlyban legyen.

A tárolóban nincs korlátozva a fizikai partíciók teljes száma. A kiosztott átviteli sebesség vagy az 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ók felosztása nem befolyásolja 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 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 fizikai partíciókhoz való új leképezését.

A tárolóhoz kiosztott átviteli sebesség egyenlően oszlik el a fizikai partíciók között. Egy olyan partíciókulcs-kialakítás, 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ához vezetnek, ami sebességkorlátozást és magasabb költségeket eredményezhet.

A tároló fizikai partícióit a Azure Portal Metrikák paneljénekStorage szakaszában tekintheti meg:

Fizikai partíciók számának megtekintése

A fenti képernyőképen egy tároló rendelkezik /foodGroup partíciókulcsként. A gráf mindhárom sávja egy fizikai partíciót jelöl. A képen a partíciókulcs-tartomány megegyezik a fizikai partícióval. A kijelölt fizikai partíció a 3 legjelentősebb 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) épít ki, akkor a három fizikai partíció mindegyike a teljes kiosztott átviteli sebesség 1/3-át használhatja. A kiválasztott fizikai partíción belül a logikai partíciókulcsok Beef ProductsVegetable and Vegetable ProductsSoups, Sauces, and Gravies együttesen 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 felhasználását a megfelelő logikai partíciókulcs kiválasztásával.

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 a tároló skálázhatósági és teljesítményigényének hatékony kielégítése érdekében. 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 elosztsa a terhelést több 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 fizikai 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 tárolja. A replikakészletek tartóssá, magas rendelkezésre állásúvá és konzisztenssé teszik a fizikai partíción tárolt adatokat. A fizikai partíciót alkotó replikák öröklik a partíció tárolási kvótáját. Egy 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 4 replikával rendelkeznek.

Az alábbi kép bemutatja, hogyan vannak leképezve a logikai partíciók 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:

Az Azure Cosmos DB particionálását bemutató kép

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, vegye figyelembe az alábbi két partíciókulcs-összetevőt:

  • 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 is használhat a szabványos elérésiút-jelölés(/) használatával.

  • 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átozásokról az Azure Cosmos DB szolgáltatáskvóta-cikkében tájékozódhat.

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ókulccsal.

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

  • Olyan tulajdonságnak kell lennie, 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 át kell alakítani egy számmá String, ha fennáll annak a valószínűsége, hogy az IEEE 754 bináris64 szerint kívül esnek a dupla pontosságú számok határain. A JSON-specifikáció felhívja azokat az okokat, amelyek miatt a határokon kívül eső számok használata általában rossz gyakorlat, mivel valószínűleg együttműködési problémák jelentkeznek. Ezek az aggodalmak különösen fontosak a partíciókulcs-oszlop esetében, mivel nem módosítható, és az adatmigrálást igényli a későbbi módosításukhoz.

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

  • A kérelemegységek (RU) felhasználása és az adattárolás egyenletesen oszlik el az összes logikai partíción. Ez biztosítja az ru-használatot és a tárolók elosztását a fizikai partíciók között.

Ha többelemű 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, 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 a fenti kritériumokat kell figyelembe vennie egy partíciókulcs kiválasztásakor. A nagyméretű, nehezen olvasható tárolók esetében azonban érdemes lehet olyan partíciókulcsot választani, amely gyakran jelenik meg szűrőként a lekérdezésekben. A lekérdezések hatékonyan irányíthatók csak a megfelelő fizikai partíciókra , ha belefogják a partíciókulcsot a szűrő predikátumba.

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, ez a tulajdonság jó partíciókulcs-választás lehet. Ha például gyakran futtat egy olyan lekérdezést, amely szűr UserID, akkor UserID a partíciókulcs kiválasztása csökkenti a partíciók közötti lekérdezések számát.

Ha azonban a tároló kicsi, valószínűleg nincs elég fizikai partíciója ahhoz, hogy aggódnia kell a partíciók közötti lekérdezések teljesítményre gyakorolt hatása miatt. Az Azure Cosmos DB legtöbb kis tárolója 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 olyan partíciókulcsot kell választania, amely minimalizálja a partíciók közötti lekérdezéseket. A tárolóhoz több fizikai partícióra lesz szükség, ha az alábbiak bármelyike igaz:

  • A tárolóban több mint 30 000 RU lesz kiépítve

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

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

Ha a tároló rendelkezik egy olyan tulajdonságtal, amely számos lehetséges értékkel rendelkezik, akkor valószínűleg remek partíciókulcs-választás. Ilyen tulajdonság például az elemazonosító. Kis méretű írásvédett vagy írási nehéz tárolók esetén az elemazonosító 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. Sok esetben ezek is nagyszerű partíciókulcs-lehetőségek az elemazonosítóval azonos okokból.

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

  • Számos lehetséges érték létezik (elemenként egy egyedi elemazonosító ).
  • Mivel elemenként egyedi elemazonosító van, az elemazonosító kiválóan működik a kérelemegység-használat és az adattárolás egyenletes elosztásakor.
  • A pontolvasások egyszerűen elvégezhetők, mivel mindig ismerni fogja az elemek partíciókulcsát, ha ismeri annak elemazonosítóját.

Az elemazonosító partíciókulcsként való kiválasztásakor figyelembe kell venni a következőket:

  • Ha az elemazonosító a partíciókulcs, az a teljes tárolóban egyedi azonosítóvá válik. Nem rendelkezhet ismétlődő elemazonosítóval rendelkező elemekkel.
  • Ha sok fizikai partícióval rendelkező írásvédett tárolóval rendelkezik, a lekérdezések hatékonyabbak lesznek, ha egyenlőségszűrővel rendelkeznek az elemazonosítóval.
  • Nem futtathat tárolt eljárásokat vagy eseményindítókat több logikai partíción.

Következő lépések