Ajánlott eljárások a kiosztott átviteli sebesség (RU/s) skálázásához
A KÖVETKEZŐKRE VONATKOZIK: 
Nosql MongoDB Cassandra Gremlin Táblázat
Ez a cikk az adatbázis vagy tároló (gyűjtemény, táblázat vagy gráf) átviteli sebességének (RU/s) skálázásához ajánlott eljárásokat és stratégiákat ismerteti. Az alapelvek akkor érvényesek, ha az Azure Cosmos DB API-k bármelyikéhez kiosztott manuális RU/s-t vagy bármely erőforrás automatikus skálázási maximális RU/s-ját növeli.
Előfeltételek
- Ha még nem ismerkedik a particionálással és a skálázással az Azure Cosmos DB-ben, javasoljuk, hogy először olvassa el a particionálás és horizontális skálázás az Azure Cosmos DB-ben című cikket.
- Ha 429 kivétel miatt tervezi skálázni az RU/s-t, tekintse át az Azure Cosmos DB-kérelmek túl nagy (429) kivételeinek diagnosztizálására és hibaelhárítására vonatkozó útmutatót. A ru/s növelése előtt azonosítsa a probléma kiváltó okát, és hogy a ru/s növelése a megfelelő megoldás-e.
Háttér a ru/s skálázásával kapcsolatban
Amikor kérést küld az adatbázis vagy a tároló RU/s-jának növelésére a kért RU/s-októl és az aktuális fizikai partícióelrendezéstől függően, a vertikális felskálázási művelet azonnal vagy aszinkron módon (általában 4–6 óra) fejeződik be.
- Azonnali felskálázás
- Ha a kért ru/s-t az aktuális fizikai partícióelrendezés támogatja, az Azure Cosmos DB-nek nem kell felosztania vagy új partíciókat hozzáadnia.
- Ennek eredményeképpen a művelet azonnal befejeződik, és az RU/s használható.
- Aszinkron felskálázás
- Ha a kért RU/s meghaladja a fizikai partíciók elrendezése által támogatott értéket, az Azure Cosmos DB felosztja a meglévő fizikai partíciókat. Ez a művelet addig zajlik, amíg az erőforrás eléri a kívánt RU/s támogatásához szükséges fizikai partíciók minimális számát.
- Emiatt a művelet eltarthat egy darabig, általában 4–6 órát vesz igénybe. Az egyes fizikai partíciók legfeljebb 10 000 RU/s-os (minden API-t beleértve) átviteli sebesség és 50 GB tárterület támogatására képesek (minden API-t beleértve, kivéve a Cassandrát, amely 30 GB tárterülettel rendelkezik).
Feljegyzés
Ha manuális feladatátvételi műveletet hajt végre, vagy új régiót ad hozzá/távolít el, miközben aszinkron vertikális felskálázási művelet van folyamatban, az átviteli sebesség felskálázási művelete szünetel. A feladatátvétel vagy a régió hozzáadása/eltávolítása művelet befejeződésekor automatikusan folytatódik.
- Azonnali leskálázás
- A vertikális leskálázási művelethez az Azure Cosmos DB-nek nem kell új partíciókat felosztania vagy hozzáadnia.
- Ennek eredményeképpen a művelet azonnal befejeződik, és az RU/s használható,
- A művelet fő eredménye, hogy a fizikai partíciónkénti kérelemegységek csökkennek.
Ru/s vertikális felskálázása partícióelrendezés módosítása nélkül
1. lépés: A fizikai partíciók aktuális számának megkeresése.
Lépjen a Elemzések> Throughput>Normalized RU Consumption (%) by PartitionKeyRangeID (%) elemre. A PartitionKeyRangeIds eltérő számának megszámlálása.
Feljegyzés
A diagramon legfeljebb 50 PartitionKeyRangeId látható. Ha az erőforrás 50-nél többel rendelkezik, az Azure Cosmos DB REST API-val megszámolhatja a partíciók teljes számát.
Minden PartitionKeyRangeId egy fizikai partícióra van leképezésre, és egy lehetséges kivonatértéktartomány adatainak tárolására van hozzárendelve.
Az Azure Cosmos DB a partíciókulcs alapján osztja el az adatokat a logikai és fizikai partíciók között a horizontális skálázás engedélyezéséhez. Az adatok írása során az Azure Cosmos DB a partíciókulcs-érték kivonatával határozza meg, hogy az adatok mely logikai és fizikai partíción élnek.
2. lépés: Az alapértelmezett maximális átviteli sebesség kiszámítása
Az Azure Cosmos DB felosztott partíciókhoz való aktiválása nélkül skálázható legmagasabb RU/s értéke egyenlő Current number of physical partitions * 10,000 RU/s. Ezt az értéket az Azure Cosmos DB-erőforrás-szolgáltatótól szerezheti be. Get kérést hajthat végre az adatbázison vagy a tároló átviteli sebességének beállítási objektumain, és lekérheti a tulajdonságotinstantMaximumThroughput. Ez az érték az adatbázis vagy tároló méretezési és Gépház lapján is elérhető a portálon.
Példa
Tegyük fel, hogy van egy meglévő tárolónk öt fizikai partícióval és 30 000 RU/s manuális kiosztott átviteli sebességgel. Az RU/s értékét azonnal 5 * 10 000 RU/s = 50 000 RU/s értékre növelhetjük. Hasonlóképpen, ha egy 30 000 RU/s automatikus skálázású tárolónk van (3000–30 000 RU/s közötti skálázás), akkor a maximális RU/s értékünket azonnal 50 000 RU/s-ra növelhetjük (5000–50 000 RU/s közötti skálázás).
Tipp.
Ha a kérelemsebesség túl nagy kivételekre (429s) való reagálás érdekében skáláz fel ru/s-t, javasoljuk, hogy először növelje az RU/s értékét a legmagasabb ru/s értékre, amelyet az aktuális fizikai partícióelrendezés támogat, és értékelje, hogy az új RU/s elegendő-e a további növekedés előtt.
Egyenletes adateloszlás biztosítása az aszinkron skálázás során
Háttér
Ha a ru/s értékét a fizikai partíciók jelenlegi számán * 10 000 RU/s fölé növeli, az Azure Cosmos DB felosztja a meglévő partíciókat, amíg az új partíciók száma = ROUNDUP(requested RU/s / 10,000 RU/s). A felosztás során a szülőpartíciók két gyermekpartícióra vannak felosztva.
Tegyük fel például, hogy egy tároló három fizikai partícióval és 30 000 RU/s manuális kiosztott átviteli sebességgel rendelkezik. Ha az átviteli sebességet 45 000 RU/s-ra növeltük, az Azure Cosmos DB a meglévő fizikai partíciók közül kettőt feloszt, így összesen 5 fizikai partíció van ROUNDUP(45,000 RU/s / 10,000 RU/s) .
Feljegyzés
Az alkalmazások a felosztások során továbbra is feldolgozhatják vagy lekérdezhetik az adatokat. Az Azure Cosmos DB ügyféloldali SDK-k és -szolgáltatások automatikusan kezelik ezt a forgatókönyvet, és biztosítják, hogy a kérések a megfelelő fizikai partícióra legyenek irányítva, így nincs szükség további felhasználói műveletre.
Ha olyan számítási feladattal rendelkezik, amely nagyon egyenletesen oszlik el a tárolás és a kérelemmennyiség tekintetében – általában magas számosságú mezők( például /id) particionálásával érhető el –, akkor a vertikális felskálázáskor ajánlott úgy beállítani az RU/s-t, hogy az összes partíció egyenlően legyen felosztva.
Ha meg szeretné tudni, miért, vegyünk egy példát, ahol egy meglévő tárolónk van 2 fizikai partícióval, 20 000 RU/s és 80 GB adattal.
A jó, nagy számosságú partíciókulcs kiválasztásának köszönhetően az adatok nagyjából egyenletesen oszlanak el mindkét fizikai partícióban. Minden fizikai partícióhoz a kulcstér körülbelül 50%-a van hozzárendelve, amely a lehetséges kivonatértékek teljes tartományaként van definiálva.
Emellett az Azure Cosmos DB egyenletesen osztja el az RU/s-t az összes fizikai partíció között. Ennek eredményeképpen minden fizikai partíció 10 000 RU/s-et és 50%-ot (40 GB) a teljes adatból. Az alábbi ábrán az aktuális állapot látható.
Tegyük fel, hogy a ru/s értékét 20 000 RU/s-ról 30 000 RU/s-ra szeretnénk növelni.
Ha egyszerűen 30 000 RU/s-ra növeljük az RU/s értéket, a partíciók közül csak az egyik lesz felosztva. A felosztás után a következő lesz:
- Egy partíció, amely az adatok 50%-át tartalmazza (ez a partíció nem volt felosztva)
- Két partíció, amelyek az adatok 25%-át tartalmazzák (ezek a felosztott szülőből származó gyermekpartíciók)
Mivel az Azure Cosmos DB egyenletesen osztja el az RU/s-t az összes fizikai partíció között, minden fizikai partíció 10 000 RU/s-t kap. Most azonban eltérés van a tárolóban és a kérések elosztásában.
Az alábbi ábrán látható, hogy a 3. és a 4. partíció (a 2. partíció gyermekpartíciói) mindegyike 10 000 RU/s értékkel rendelkezik a 20 GB-os adatkérések kiszolgálásához, míg az 1. partíció 10 000 RU/s értékkel rendelkezik az adatmennyiség kétszeresére (40 GB) vonatkozó kérések kiszolgálásához.
Az egyenletes tárolási eloszlás fenntartása érdekében először vertikálisan felskálázhatjuk az ru/s-t, hogy minden partíció felosztást biztosítson. Ezután a ru/s visszaengedhető a kívánt állapotba.
Tehát, ha két fizikai partícióval kezdjük, hogy garantáljuk, hogy a partíciók még felosztás után is legyenek, olyan ru/s értékeket kell beállítanunk, hogy négy fizikai partícióval fogjuk végezni. Ennek eléréséhez először az RU/s = 4 * 10 000 RU/s értéket állítjuk be partíciónként = 40 000 RU/s. Ezután a felosztás befejeződése után a ru/s értéket 30 000 RU/s-ra csökkenthetjük.
Ennek eredményeképpen az alábbi ábrán látható, hogy minden fizikai partíció 30 000 RU/s / 4 = 7500 RU/s-ot kap 20 GB-os adatkérések kiszolgálásához. Összességében egyenletes tárolást tartunk fenn, és a partíciók közötti eloszlást kérjük.
Általános képlet
1. lépés: Növelje az RU/s-t annak garantálása érdekében, hogy az összes partíció egyenlően oszlik el
Általában, ha a fizikai partíciók Pkezdő száma van megadva, és meg szeretne adni egy kívánt RU/s-t S:
Növelje a ru/s értékét a következőre: 10,000 * P * (2 ^ (ROUNDUP(LOG_2 (S/(10,000 * P)))). Így a legközelebbi RU/s a kívánt értékhez lesz adva, amely biztosítja, hogy az összes partíció egyenlően legyen felosztva.
Feljegyzés
Egy adatbázis vagy tároló ru/s-jainak növelése hatással lehet arra a minimális ru/s-ra, amely a jövőben alacsonyabb lehet. A minimális RU/s általában a MAX(400 RU/s, aktuális tárterület GB-ban * 1 RU/s, valaha kiépített legmagasabb RU/s / 100) értékével egyenlő. Ha például a valaha skálázott legmagasabb RU/s 100 000 RU/s, akkor a jövőben beállítható legalacsonyabb RU/s 1000 RU/s. További információ a minimális RU/s-ról.
2. lépés: A ru/s csökkentése a kívánt RU/s-ra
Tegyük fel például, hogy öt fizikai partíciónk van, 50 000 RU/s, és 150 000 RU/s-ra szeretnénk méretezni. Először a következőt kell beállítani: 10,000 * 5 * (2 ^ (ROUND(LOG_2(150,000/(10,000 * 5)))) = 200 000 RU/s, majd alacsonyabb, mint 150 000 RU/s.
Ha 200 000 RU/s-ra skálázunk, a legkisebb manuális RU/s, amelyet a jövőben beállíthatunk, 2000 RU/s. A legkisebb automatikus skálázási maximális RU/s 20 000 RU/s (skálázás 2000 és 20 000 RU/s között). Mivel a cél RU/s értéke 150 000 RU/s, a minimális RU/s nem érint minket.
Ru/s optimalizálása nagy adatbetöltéshez
Amikor nagy mennyiségű adatot kíván migrálni vagy betölteni az Azure Cosmos DB-be, javasoljuk, hogy állítsa be a tároló ru/s-jait, hogy az Azure Cosmos DB előre kiépíthesse azokat a fizikai partíciókat, amelyek szükségesek ahhoz, hogy előre tárolhassa a betöltendő adatok teljes mennyiségét. Ellenkező esetben előfordulhat, hogy a betöltés során az Azure Cosmos DB-nek fel kell osztania a partíciókat, ami több időt ad az adatbetöltéshez.
Kihasználhatjuk azt a tényt, hogy a tároló létrehozása során az Azure Cosmos DB a kezdő RU/s heurisztikus képletével kiszámítja a kezdéshez használt fizikai partíciók számát.
1. lépés: A partíciókulcs kiválasztásának áttekintése
Kövesse az ajánlott eljárásokat a partíciókulcs kiválasztásához, hogy a kéréskötet és a tárterület elosztása a migrálás után is rendelkezésre álljon.
2. lépés: A szükséges fizikai partíciók számának kiszámítása
Number of physical partitions = Total data size in GB / Target data per physical partition in GB
Minden fizikai partíció legfeljebb 50 GB tárterületet tartalmazhat (a Cassandra API-hoz 30 GB). A választott Target data per physical partition in GB érték attól függ, hogy a fizikai partíciók mennyire legyenek teljesen csomagolva, és hogy a tárolás várhatóan mennyivel fog növekedni a migrálás után.
Ha például arra számít, hogy a tárterület továbbra is növekedni fog, dönthet úgy, hogy 30 GB-ra állítja az értéket. Feltételezve, hogy egy jó partíciókulcsot választott, amely egyenletesen osztja el a tárterületet, minden partíció ~60%-kal megtelik (50 GB-ból 30 GB). A jövőbeli adatok írása során a meglévő fizikai partíciókon tárolhatók anélkül, hogy a szolgáltatásnak azonnal további fizikai partíciókat kellene hozzáadnia.
Ezzel szemben, ha úgy véli, hogy a tárolás nem fog jelentősen növekedni a migrálás után, dönthet úgy, hogy magasabb értéket állít be, például 45 GB-ot. Ez azt jelenti, hogy minden partíció ~90%-ban megtelik (50 GB-ból 45 GB). Ez minimalizálja az adatok között elosztott fizikai partíciók számát, ami azt jelenti, hogy minden fizikai partíció a teljes kiosztott RU/s nagyobb részét kaphatja meg.
3. lépés: Számítsa ki az összes partícióhoz tartozó ru/s számát
Starting RU/s for all partitions = Number of physical partitions * Initial throughput per physical partition.
Kezdjük egy példával, amely a cél RU/s fizikai partíciónkénti tetszőleges számát adja meg.
Initial throughput per physical partition= fizikai partíciónként 10 000 RU/s automatikus skálázás vagy megosztott átviteli sebességű adatbázisok használatakorInitial throughput per physical partition= fizikai partíciónként 6000 RU/s manuális átviteli sebesség használatakor
Példa
Tegyük fel, hogy 1 TB -os (1000 GB-os) adatkészletet tervezünk bevinni, és manuális átviteli sebességet szeretnénk használni. Az Azure Cosmos DB minden fizikai partíciója 50 GB kapacitással rendelkezik. Tegyük fel, hogy a partíciók 80%-os (40 GB- os) megtelésére törekszünk, így teret hagyunk a jövőbeli növekedésnek.
Ez azt jelenti, hogy 1 TB adathoz 1000 GB/ 40 GB = 25 fizikai partícióra lesz szükségünk. Annak érdekében, hogy 25 fizikai partíciót kapjunk, ha manuális átviteli sebességet használunk, először kiépítünk 25 * 6000 RU/s = 150 000 RU/s értéket. Ezután a tároló létrehozása után, a betöltés felgyorsítása érdekében az RU/s értékét 250 000 RU/s-ra növeljük a betöltés megkezdése előtt (azonnal megtörténik, mert már 25 fizikai partíciónk van). Ez lehetővé teszi, hogy minden partíció legfeljebb 10 000 RU/s-t kapjon.
Ha automatikus skálázási átviteli sebességet vagy megosztott átviteli sebességet használó adatbázist használunk, 25 fizikai partíció lekéréséhez először 25 * 10 000 RU/s = 250 000 RU/s értéket építünk ki. Mivel már a legmagasabb RU/s-nál vagyunk, amely 25 fizikai partícióval támogatott, a betöltés előtt nem növelnénk tovább a kiosztott RU/s-t.
Elméletileg 250 000 RU/s és 1 TB adat, ha feltételezzük, hogy 1 kb dokumentum és 10 kérelemegység szükséges az íráshoz, a betöltés elméletileg a következőben fejeződhet be: 1000 GB * (1 000 000 kb / 1 GB) * (1 dokumentum / 1 kb) * (10 RU / dokumentum) * (1 mp / 250 000 RU) * (1 óra / 3600 másodperc) = 11,1 óra.
Ez a számítás egy becslés, amely feltételezi, hogy a betöltést végző ügyfél teljes mértékben képes telíteni az átviteli sebességet, és az írásokat az összes fizikai partíció között elosztja. Ajánlott eljárásként javasoljuk, hogy az ügyféloldalon "keverje el" az adatokat. Ez biztosítja, hogy az ügyfél másodpercenként több különböző logikai (és így fizikai) partícióra írjon.
A migrálás befejezése után csökkentheti az ru/s értéket, vagy szükség szerint engedélyezheti az automatikus skálázást.