A kiosztott átviteli sebesség költségeinek optimalizálása az Azure Cosmos DB-ben

A KÖVETKEZŐKRE VONATKOZIK: NoSQL MongoDB Cassandra Gremlin Asztal

A kiépített átviteli sebességmodell felajánlásával az Azure Cosmos DB bármilyen léptékben kiszámítható teljesítményt nyújt. Az átviteli sebesség idő előtti megőrzése vagy kiépítése megszünteti a "zajos szomszédhatást" a teljesítményre. Megadja a szükséges átviteli sebesség pontos mennyiségét, és az Azure Cosmos DB garantálja a konfigurált átviteli sebességet, amelyet az SLA biztosít.

A minimális átviteli sebesség 400 RU/s lehet, és másodpercenként akár több tízmillió kérést is skálázhat. Az Azure Cosmos DB-tárolóval vagy -adatbázissal kapcsolatos minden egyes kérés, például olvasási kérés, írási kérés, lekérdezési kérelem, tárolt eljárások, a kiosztott átviteli sebességből levont költségek. Ha kiépít 400 RU/s-t, és 40 kérelemegységbe kerül egy lekérdezés, másodpercenként 10 ilyen lekérdezést fog tudni kiadni. Minden olyan kérés, amely túl van korlátozva, és újra meg kell próbálkoznia a kéréssel. Ha ügyfélillesztőket használ, azok támogatják az automatikus újrapróbálkozás logikáját.

Az átviteli sebességet adatbázisok vagy tárolók között is kioszthatja, és a különféle stratégiákkal alacsonyabbak lehetnek a költségek a forgatókönyvtől függően.

Optimalizálás az átviteli sebesség különböző szinteken történő kiépítésével

• Ha átviteli sebességet épít ki egy adatbázisra, az adatbázisban található összes tároló, például gyűjtemények/táblák/grafikonok a terhelés alapján megoszthatják az átviteli sebességet. Az adatbázis szintjén fenntartott átviteli sebesség egyenlőtlenül oszlik meg egy adott tárolókészlet számítási feladataitól függően.

• Ha átviteli sebességet épít ki egy tárolón, az átviteli sebesség garantált az adott tárolóhoz, amelyet az SLA biztosít. A logikai partíciókulcs kiválasztása kulcsfontosságú a tároló összes logikai partíciójának terheléselosztása szempontjából. További részletekért lásd a particionálásról és a horizontális skálázásról szóló cikkeket.

Az alábbiakban néhány iránymutatást talál a kiépített átviteli sebességre vonatkozó stratégia kiválasztásához:

Fontolja meg az átviteli sebesség kiépítését egy Azure Cosmos DB-adatbázison (amely tárolók készletét tartalmazza), ha:

1. Néhány tucat Azure Cosmos DB-tárolóval rendelkezik, és szeretné megosztani az átviteli sebességet néhány vagy mindegyik között.

2. IaaS által üzemeltetett virtuális gépeken vagy helyszíni rendszereken, például NoSQL-en vagy relációs adatbázisokon futó egybérlős adatbázisból migrál az Azure Cosmos DB-be. Ha pedig sok gyűjtemény/táblázat/grafikon van, és nem szeretné módosítani az adatmodellt. Vegye figyelembe, hogy előfordulhat, hogy az Azure Cosmos DB által kínált előnyök némelyikét veszélybe kell sodornia, ha nem frissíti az adatmodellt egy helyszíni adatbázisból való migráláskor. Javasoljuk, hogy mindig újraértékelje az adatmodellt a teljesítmény és a költségek optimalizálása érdekében.

3. A számítási feladatok nem tervezett kiugró csúcsait az adatbázis szintjén a készletezett átviteli sebesség miatt szeretné elnyelni, amely a számítási feladatok váratlan kiugró értékének van kitéve.

4. Ahelyett, hogy konkrét átviteli sebességet állít be az egyes tárolókra, az adatbázison belüli tárolók összes tárolóinak összesített átviteli sebességével kell foglalkoznia.

Fontolja meg az átviteli sebesség kiépítését az egyes tárolókon, ha:

1. Van néhány Azure Cosmos DB-tárolója. Mivel az Azure Cosmos DB sémafüggetlen, a tárolók heterogén sémákkal rendelkező elemeket tartalmazhatnak, és nem követelik meg az ügyfelektől, hogy több tárolótípust hozzanak létre, amelyek mindegyik entitáshoz tartoznak. Mindig érdemes megfontolni, hogy a különálló, mondjuk 10-20 tárolók egyetlen tárolóba történő csoportosítása logikus-e. A tárolók esetében 400 kérelemegység minimális értékével költséghatékonyabb lehet mind a 10–20 tárolót egybe egyesíteni.

2. Egy adott tároló átviteli sebességét szeretné szabályozni, és az SLA által támogatott adott tároló garantált átviteli sebességét lekérni.

Vegye figyelembe a fenti két stratégia hibrid verzióját:

1. Ahogy korábban említettük, az Azure Cosmos DB lehetővé teszi a fenti két stratégia keverését és egyeztetését, így mostantól rendelkezhet néhány tárolóval az Azure Cosmos DB-adatbázisban, amelyek megoszthatják az adatbázison kiosztott átviteli sebességet, valamint egyes tárolókat ugyanazon az adatbázison belül, amelyek dedikált mennyiségű kiosztott átviteli sebességgel rendelkezhetnek.

2. A fenti stratégiákat alkalmazhatja egy hibrid konfiguráció létrehozásához, ahol mindkét adatbázisszintű kiosztott átviteli sebességgel rendelkezik, és egyes tárolók dedikált átviteli sebességgel rendelkeznek.

Ahogy az alábbi táblázatban látható, az API kiválasztásától függően az átviteli sebességet különböző részletességekkel építheti ki.

API	Megosztott átviteli sebesség esetén konfigurálja a	Dedikált átviteli sebesség esetén konfigurálja a
API a NoSQL-hez	Adatbázis	Tároló
MongoDB-hez készült Azure Cosmos DB API	Adatbázis	Gyűjtemény
API a Cassandra-hoz	Kulcstér	Tábla
API a Gremlinhez	Adatbázisfiók	Grafikon
API for Table	Adatbázisfiók	Tábla

Az átviteli sebesség különböző szinteken történő kiépítésével a számítási feladat jellemzői alapján optimalizálhatja a költségeket. Ahogy korábban említettük, programozott módon és bármikor növelheti vagy csökkentheti a kiosztott átviteli sebességet az egyes tárolók(ok) esetében, vagy együttesen több tárolóban. Ha rugalmasan skálázhatja az átviteli sebességet a számítási feladatok változásakor, csak a konfigurált átviteli sebességért kell fizetnie. Ha a tároló vagy tárolókészlet több régióban van elosztva, akkor a tárolón vagy tárolókészleten konfigurált átviteli sebesség garantáltan elérhetővé válik az összes régióban.

Optimalizálás a kérések sebességének korlátozásával

A késésre nem érzékeny számítási feladatok esetében kevesebb átviteli sebességet építhet ki, és lehetővé teheti, hogy az alkalmazás kezelje a sebességkorlátozást, ha a tényleges átviteli sebesség meghaladja a kiosztott átviteli sebességet. A kiszolgáló előre befejezi a kérést RequestRateTooLarge (HTTP-állapotkód: 429), és visszaadja a x-ms-retry-after-ms fejlécet, amely jelzi, hogy a felhasználónak mennyi időt kell várnia a kérés újrapróbálkozása előtt.

HTTP Status 429, 
 Status Line: RequestRateTooLarge 
 x-ms-retry-after-ms :100

Újrapróbálkozott logika SDK-kban

A natív SDK-k (.NET/.NET Core, Java, Node.js és Python) implicit módon elkapják ezt a választ, tiszteletben tartják a kiszolgáló által megadott újrapróbálkozást a fejléc után, és újrapróbálkoznak a kéréssel. Ha több ügyfél nem fér hozzá egyszerre a fiókjához, a következő újrapróbálkozás sikeres lesz.

Ha több ügyfél kumulatív működése következetesen meghaladja a kérések arányát, előfordulhat, hogy az alapértelmezett újrapróbálkozási szám, amely jelenleg 9-re van állítva, nem elegendő. Ilyen esetekben az ügyfél egy RequestRateTooLargeException 429-ben megadott állapotkódot ad az alkalmazásnak. Az alapértelmezett újrapróbálkozási szám a ConnectionPolicy-példány beállításával RetryOptions módosítható. Alapértelmezés szerint a RequestRateTooLargeException 429-es állapotkód 30 másodperces kumulatív várakozási idő után lesz visszaadva, ha a kérés továbbra is a kérési sebesség felett működik. Ez akkor is előfordul, ha az újrapróbálkozások aktuális száma kisebb, mint a maximális újrapróbálkozások száma, legyen az alapértelmezett érték 9 vagy felhasználó által megadott érték.

A MaxRetryAttemptsOnThrottledRequests értéke 3, ezért ebben az esetben, ha egy kérelemművelet sebessége a tároló fenntartott átviteli sebességének túllépésével van korlátozva, a kérelemművelet háromszor újrapróbálkozott, mielőtt a kivételt az alkalmazásra dobta volna. A MaxRetryWaitTimeInSeconds értéke 60, ezért ebben az esetben, ha az összesítő újrapróbálkozási várakozási idő másodpercben meghaladja a 60 másodpercet, a kivétel ki lesz dobva.

ConnectionPolicy connectionPolicy = new ConnectionPolicy(); 
connectionPolicy.RetryOptions.MaxRetryAttemptsOnThrottledRequests = 3; 
connectionPolicy.RetryOptions.MaxRetryWaitTimeInSeconds = 60;

A particionálási stratégia és a kiosztott átviteli sebesség költségei

A jó particionálási stratégia fontos az Azure Cosmos DB költségeinek optimalizálásához. Győződjön meg arról, hogy a tárolómetrikákon keresztül elérhető partíciók nem térnek el. Győződjön meg arról, hogy a partíciók átviteli sebességének nincs eltérése, amely átviteli metrikákkal van elérhetővé téve. Győződjön meg arról, hogy nincs eltérés az adott partíciókulcsok felé. A tárolóban lévő domináns kulcsok metrikákon keresztül érhetők el, de a kulcs az alkalmazás hozzáférési mintájától függ. Érdemes átgondolni a megfelelő logikai partíciókulcsot. Egy jó partíciókulcsnak a következő jellemzőkkel kell rendelkeznie:

• Válasszon egy partíciókulcsot, amely egyenletesen elosztja a számítási feladatokat az összes partíción és egyenletesen az idő függvényében. Más szóval nem szabad, hogy legyen néhány kulcs az adatok többségéhez, és néhány olyan kulcshoz, amely kevesebb vagy kevesebb adattal rendelkezik.

• Válasszon egy partíciókulcsot, amely lehetővé teszi a hozzáférési minták egyenletes elosztását a logikai partíciók között. A számítási feladat ésszerűen az összes kulcsra is kiterjed. Más szóval a számítási feladatok többségének nem szabad néhány konkrét kulcsra összpontosítania.

• Válasszon egy olyan partíciókulcsot, amely számos értékkel rendelkezik.

Az alapötlet az, hogy a tárolóban lévő adatokat és tevékenységeket elosztja a logikai partíciók halmazában, hogy az adattároláshoz és az átviteli sebességhez szükséges erőforrások eloszthatók legyenek a logikai partíciók között. A partíciókulcsok jelöltjei közé tartozhatnak azok a tulajdonságok, amelyek szűrőként gyakran jelennek meg a lekérdezésekben. A lekérdezések hatékony átirányításához a partíciókulcsot foglalja bele a szűrő predikátumába. Egy ilyen particionálási stratégiával a kiosztott átviteli sebesség optimalizálása sokkal egyszerűbb.

Kisebb elemek tervezése a nagyobb átviteli sebesség érdekében

Egy adott művelet kérelemdíja vagy kérelemfeldolgozási költsége közvetlenül korrelál az elem méretével. A nagyméretű elemek műveletei többe kerülnek, mint a kisebb elemeken végzett műveletek.

Adathozzáférési minták

Mindig ajánlott logikai kategóriákba sorolni az adatokat attól függően, hogy milyen gyakran fér hozzá az adatokhoz. A gyakori, közepes vagy hideg adatok besorolásával finomhangolhatja a felhasznált tárterületet és a szükséges átviteli sebességet. A hozzáférés gyakoriságától függően az adatokat külön tárolókba (például táblákba, grafikonokba és gyűjteményekbe) helyezheti, és finomhangolhatja a kiosztott átviteli sebességet az adott adatszegmens igényeinek megfelelően.

Ezenkívül ha az Azure Cosmos DB-t használja, és tudja, hogy nem fog bizonyos adatértékek alapján keresni, vagy ritkán éri el őket, ezeknek az attribútumoknak a tömörített értékeit kell tárolnia. Ezzel a módszerrel tárhelyet, indexterületet és kiosztott átviteli sebességet takaríthat meg, és alacsonyabb költségeket eredményez.

Optimalizálás az indexelési szabályzat módosításával

Alapértelmezés szerint az Azure Cosmos DB minden rekord minden tulajdonságát automatikusan indexeli. Ennek célja, hogy megkönnyítse a fejlesztést, és kiváló teljesítményt biztosítson számos különböző típusú alkalmi lekérdezés esetében. Ha több ezer tulajdonsággal rendelkező nagy rekordokkal rendelkezik, előfordulhat, hogy az összes tulajdonság indexelésének átviteli sebességköltsége nem lesz hasznos, különösen akkor, ha csak 10 vagy 20 tulajdonságot kérdez le. Ahogy közelebb kerül az adott számítási feladathoz, útmutatásunk az indexszabályzat finomhangolása. Az Azure Cosmos DB indexelési szabályzatának részletes leírását itt találja.

Kiosztott és felhasznált átviteli sebesség figyelése

Nyomon követheti a kiosztott kérelemegységek teljes számát, a korlátozott díjszabású kérelmek számát és az Azure Portalon felhasznált kérelemegységek számát. További információ: Azure Cosmos DB-metrikák elemzése. Az alábbi képen egy használati példametrika látható:

Riasztásokat is beállíthat annak ellenőrzésére, hogy a korlátozott sebességű kérelmek száma túllép-e egy adott küszöbértéket. A riasztásokkal kapcsolatos további információkért tekintse meg az Azure Monitor-riasztásokat.

Az átviteli sebesség rugalmas és igény szerinti skálázása

Mivel a kiosztott átviteli sebességért kell fizetnie, a kiosztott átviteli sebességnek az igényeinek megfelelően elkerülheti a fel nem használt átviteli sebesség díjait. Igény szerint bármikor fel- vagy leskálázhatja a kiosztott átviteli sebességet. Ha az átviteli sebességre nagyon kiszámítható igény van, használhatja az Azure Functionst, és időzítő eseményindítóval növelheti vagy csökkentheti az átviteli sebességet egy ütemezés szerint.

• A kérelemegységek fogyasztásának és a korlátozott sebességre vonatkozó kérések arányának monitorozása azt eredményezheti, hogy a nap vagy a hét folyamán nem kell folyamatosan kiépítenie a kiépítést. Előfordulhat, hogy éjszaka vagy a hétvégén kevesebb forgalmat kap. Az Azure Portal, az Azure Cosmos DB natív SDK-k vagy a REST API használatával bármikor skálázhatja a kiosztott átviteli sebességet. Az Azure Cosmos DB REST API-ja végpontokat biztosít a tárolók teljesítményszintjének programozott frissítéséhez, így egyszerűen módosíthatja a kód átviteli sebességét a nap időpontjától vagy a hét napjától függően. A művelet állásidő nélkül történik, és általában kevesebb mint egy perc alatt érvénybe lép.

• Az átviteli sebesség skálázásának egyik területe az, amikor adatokat telepít be az Azure Cosmos DB-be, például az adatmigrálás során. A migrálás befejezése után leskálázhatja a kiosztott átviteli sebességet a megoldás állandó állapotának kezeléséhez.

• Ne feledje, hogy a számlázás egy óra részletességű, így nem takaríthat meg pénzt, ha többször módosítja a kiosztott átviteli sebességet, mint egy óra.

Az új számítási feladatokhoz szükséges átviteli sebesség meghatározása

Az új számítási feladatok kiosztott átviteli sebességének meghatározásához kövesse az alábbi lépéseket:

1. Végezzen egy kezdeti, durva értékelést a kapacitástervezővel, és módosítsa a becsléseket az Azure Cosmos DB Explorer segítségével az Azure Portalon.

2. Javasoljuk, hogy a vártnál nagyobb átviteli sebességgel hozza létre a tárolókat, majd igény szerint skálázzák le.

3. Javasoljuk, hogy használja az egyik natív Azure Cosmos DB SDK-t, hogy kihasználhassa az automatikus újrapróbálkozások előnyeit, ha a kérések sebessége korlátozott. Ha olyan platformon dolgozik, amely nem támogatott, és az Azure Cosmos DB REST API-ját használja, implementálja a saját újrapróbálkozési szabályzatát a x-ms-retry-after-ms fejléc használatával.

4. Győződjön meg arról, hogy az alkalmazáskód jól támogatja az esetet, ha minden újrapróbálkozás sikertelen.

5. Az Azure Portalon riasztásokat konfigurálhat, hogy értesítéseket kapjon a sebességkorlátozásról. Az elmúlt 15 percben 10 korlátozott kérelemhez hasonló konzervatív korlátozásokkal kezdhet, és a tényleges fogyasztás megállapítását követően válthat lelkesebb szabályokra. Az alkalmi sebességkorlátozások rendben vannak, azt mutatják, hogy a beállított korlátokkal játszik, és pontosan ezt szeretné tenni.

6. A figyeléssel megismerheti a forgalmi mintát, így megfontolhatja az átviteli sebesség kiépítésének dinamikus módosítását a nap vagy egy hét során.

7. Rendszeresen monitorozza a kiosztott és a felhasznált átviteli sebesség arányát, hogy meggyőződjön arról, hogy a szükségesnél több tárolót és adatbázist nem hozott létre. Egy kicsit túlterjedt a kiosztott átviteli sebesség, jó biztonsági ellenőrzés.

Ajánlott eljárások a kiosztott átviteli sebesség optimalizálásához

Az alábbi lépések segítségével magas skálázhatóvá és költséghatékonysá teheti megoldásait az Azure Cosmos DB használatakor.

1. Ha jelentősen túllépte a tárolók és adatbázisok közötti átviteli sebességet, tekintse át a kiépített kérelemegységeket és a felhasznált kérelemegységeket, és finomhangolja a számítási feladatokat.

2. Az alkalmazás által igényelt fenntartott átviteli sebesség becslésének egyik módszere az, ha rögzíti az alkalmazás által használt reprezentatív Azure Cosmos DB-tárolón vagy -adatbázison végzett tipikus műveletek futtatásával járó kérelemegység-díjat, majd megbecsüli az egyes másodpercenként végrehajtandó műveletek számát. Ügyeljen arra, hogy a tipikus lekérdezéseket és azok használatát is mérje és tartalmazza. A lekérdezések ru-költségeinek programozott vagy a portál használatával történő becsléséről a lekérdezések költségének optimalizálása című témakörben olvashat.

3. A műveletek és költségeik kérelemegységekben való lekérésének másik módja az Azure Monitor-naplók engedélyezése, amely megadja a művelet/időtartam és a kérelem díjának lebontását. Az Azure Cosmos DB minden művelethez kérési díjat biztosít, így minden műveletdíj visszatárható a válaszból, majd felhasználható elemzésre.

4. Rugalmasan fel- és leskálázhatja a kiosztott átviteli sebességet a számítási feladatok igényeinek megfelelően.

5. Szükség szerint hozzáadhatja és eltávolíthatja az Azure Cosmos DB-fiókjához társított régiókat, és szabályozhatja a költségeket.

6. Győződjön meg arról, hogy a tárolók logikai partíciói között egyenletesen elosztotta az adatokat és a számítási feladatokat. Egyenetlen partícióeloszlás esetén ez nagyobb átviteli sebességet eredményezhet, mint a szükséges érték. Ha azt állapítja meg, hogy ferde eloszlással rendelkezik, javasoljuk, hogy a számítási feladatot egyenletesen terjesszen át a partíciók között, vagy adja újra az adatokat.

7. Ha sok tárolóval rendelkezik, és ezek a tárolók nem igényelnek SLA-kat, akkor az adatbázis-alapú ajánlatot használhatja azokra az esetekre, amikor a tárolónkénti átviteli sebesség SLA-k nem érvényesek. Meg kell határoznia, hogy melyik Azure Cosmos DB-tárolót szeretné áttelepíteni az adatbázisszintű átviteli sebesség ajánlatba, majd egy változáscsatorna-alapú megoldással migrálni őket.

8. Fontolja meg az "Ingyenes Azure Cosmos DB-szint" használatát (egy évig ingyenes), próbálja ki az Azure Cosmos DB-t (legfeljebb három régióban) vagy a letölthető Azure Cosmos DB emulátort fejlesztési/tesztelési forgatókönyvekhez. Ha ezeket a lehetőségeket használja a teszteléshez, jelentősen csökkentheti a költségeit.

9. Tovább végezhet számítási feladatspecifikus költségoptimalizálásokat– például növelheti a kötegméretet, a terheléselosztási olvasásokat több régióban, és szükség esetén megszüntetheti az adatok duplikálását.

10. A fenntartott Azure Cosmos DB-kapacitással három évig jelentős, akár 65%-os kedvezményeket is kaphat. A fenntartott Azure Cosmos DB-kapacitásmodell előzetes kötelezettségvállalás az idő múlásával szükséges kérésegységek esetében. A kedvezmények rétegzett, hogy minél több kérelemegységet használ egy hosszabb időszak alatt, annál nagyobb lesz a kedvezménye. Ezeket a kedvezményeket a rendszer azonnal alkalmazza. A kiosztott értékek felett használt kérelemegységek a nem fenntartott kapacitás költségei alapján kerülnek felszámításra. További részletekért tekintse meg a fenntartott Azure Cosmos DB-kapacitást. Fontolja meg fenntartott kapacitás vásárlását a kiosztott átviteli sebesség költségeinek további csökkentése érdekében.

Következő lépések

A következő cikkekkel további információt tudhat meg a költségoptimalizálásról az Azure Cosmos DB-ben:

• Kapacitástervezést szeretne végezni az Azure Cosmos DB-be való migráláshoz? A kapacitástervezéshez használhatja a meglévő adatbázisfürt adatait.
  • Ha csak annyit tud, hogy hány virtuális mag és kiszolgáló található a meglévő adatbázisfürtben, olvassa el a kérelemegységek becslését virtuális magok vagy vCPU-k használatával
  • Ha ismeri az aktuális adatbázis számítási feladataira vonatkozó tipikus kérési arányokat, olvassa el a kérelemegységek becslését az Azure Cosmos DB kapacitástervezővel
• További információ a fejlesztés és tesztelés optimalizálásáról
• További információ az Azure Cosmos DB-számla értelmezéséről
• További információ a tárolási költségek optimalizálásáról
• További információ az olvasási és írási költségek optimalizálásáról
• További információ a lekérdezések költségeinek optimalizálásáról
• További információ a többrégiós Azure Cosmos DB-fiókok költségeinek optimalizálásáról