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

  • Cikk

A KÖVETKEZŐKRE VONATKOZIK: Nosql MongoDB Cassandra Gremlin Táblázat

Az Azure Cosmos DB a kiépített átviteli sebességi modell felajánlásával bármilyen léptékben kiszámítható teljesítményt nyújt. Az átviteli sebesség előzetes lefoglalása vagy kiépítése kiküszöböli a "zajos szomszéd hatást" a teljesítményre. Ön határozza meg a szükséges átviteli sebesség pontos mennyiségét, az Azure Cosmos DB pedig 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 felskálázhat. Az Azure Cosmos DB-tárolóval vagy -adatbázissal kapcsolatos minden egyes kérelem, például olvasási kérés, írási kérelem, lekérdezési kérelem, tárolt eljárások, a kiosztott átviteli sebességből levont költségek levonása történik. Ha 400 RU/s-t épít ki, és 40 kérelemegységbe eső lekérdezést ad ki, másodpercenként 10 ilyen lekérdezést tud kibocsátani. Az ezen túli kérések sebességkorlátosak lesznek, ezért próbálkozzon újra 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ő kiosztásával

  • Ha átviteli sebességet oszt ki egy adatbázison, az összes tároló, például gyűjtemények/táblák/grafikonok az adatbázison belül megoszthatják az átviteli sebességet a terhelés alapján. Az adatbázis szintjén fenntartott átviteli sebesség egyenlőtlenül van megosztva 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 elengedhetetlen a tároló összes logikai partíciója közötti egyenletes terheléselosztáshoz. További részletekért lásd: Particionálás és horizontális skálázás .

Az alábbiakban néhány iránymutatást talál a kiosztott átviteli sebesség stratégiájának meghatározásához:

Fontolja meg az átviteli sebesség kiépítését egy (tárolókészletet tartalmazó) Azure Cosmos DB-adatbázison, 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. Egy egybérlős adatbázisból migrál, amelyet IaaS által üzemeltetett virtuális gépeken vagy helyszíni gépeken futtat, például NoSQL-ről vagy relációs adatbázisokról az Azure Cosmos DB-be. Ha pedig sok gyűjteményt/táblát/grafikont használ, és nem szeretne módosítani az adatmodellen. Vegye figyelembe, hogy előfordulhat, hogy az Azure Cosmos DB által kínált előnyök némelyikét veszélybe kell sértenie, ha nem frissíti az adatmodellt a helyszíni adatbázisból való migráláskor. Javasoljuk, hogy mindig újraértékelje az adatmodellt, hogy a lehető legtöbbet hozhassa ki 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ásának van kitéve.

  4. Ahelyett, hogy adott átviteli sebességet állít be az egyes tárolókhoz, az adatbázison belüli tárolók összesítési sebességét kell megkapni.

Fontolja meg az átviteli sebesség kiosztását egy különálló tárolón, 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, egy-egy entitáshoz. Mindig érdemes megfontolni, hogy érdemes-e külön 10-20 tárolót egyetlen tárolóba csoportosítani. A tárolók minimálisan 400 kérelemegységével költséghatékonyabb lehet mind a 10–20 tárolót egybe egyesíteni.

  2. Szeretné szabályozni az átviteli sebességet egy adott tárolón, és le szeretné kapni a garantált átviteli sebességet egy SLA által támogatott adott tárolón.

Vegyünk egy hibridet a fenti két stratégia közül:

  1. Ahogy korábban említettük, az Azure Cosmos DB lehetővé teszi a fenti két stratégia kombinációját és egyezését, így most már 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 ugyanabban az adatbázisban, 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ég dedikált átviteli sebességgel rendelkezik.

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

API Megosztott átviteli sebesség esetén konfigurálja a Dedikált átviteli sebesség esetén konfigurálja a
NOSQL-hez készült API 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 Graph
API a Tablehez 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) esetében vagy együttesen a tárolók egy csoportjában. Az átviteli sebességnek a számítási feladat változásaival való rugalmas skálázásával 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 hagyhatja, 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 ideig 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álkozás logikája 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ási fejlécet, és újrapróbálkoznak a kéréssel. Ha a fiókját nem több ügyfél egyidejűleg éri el, a következő újrapróbálkozás sikeres lesz.

Ha több ügyfél kumulatív módon működik következetesen a kérések aránya felett, 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-es állapotkódot ad az alkalmazásnak. Az alapértelmezett újrapróbálkozási szám a ConnectionPolicy példányon való beállítással 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érelemsebessé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 az alapértelmezett 9 vagy egy 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ásnak küldené. 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ételt a rendszer eldobja.

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 eltérése nincs, 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ókulcsokkal szemben. 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 oszálja el a számítási feladatokat az összes partíción és egyenletesen az idő múlásával. Más szóval nem szabad bizonyos kulcsokkal rendelkeznie az adatok többségéhez, és néhány kulcshoz, amelyekhez kevesebb vagy kevesebb adatot kell használnia.

  • 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 kulcs között is elérhető. 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 olyan partíciókulcsot, amely számos értéket tartalmaz.

Az alapötlet az adatok és a tárolóban lévő tevékenység elosztása a logikai partíciók halmazában, hogy az adattároláshoz és az átviteli sebességhez szükséges erőforrások el legyenek osztva a logikai partíciók között. A partíciókulcsok jelöltjei közé tartozhatnak azok a tulajdonságok, amelyek gyakran jelennek meg szűrőként 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 lesz.

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 összefügg az elem méretével. A nagyméretű elemeken végzett műveletek többe kerülnek, mint a kisebb elemeken végzett műveletek.

Adathozzáférési minták

Mindig célszerű 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 ritka elérésű 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.

Továbbá ha Az Azure Cosmos DB-t használja, és tudja, hogy bizonyos adatértékek alapján nem fog keresni, vagy ritkán fog hozzáférni hozzájuk, akkor 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, ami 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 automatikusan indexel minden rekord minden tulajdonságát. Ennek célja, hogy megkönnyítse a fejlesztést, és kiváló teljesítményt biztosítson a különböző típusú alkalmi lekérdezések esetében. Ha több ezer tulajdonsággal rendelkező nagy rekordokkal rendelkezik, előfordulhat, hogy nem minden tulajdonság indexelésével fizeti meg az átviteli sebesség költségeit, 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, az útmutatónk az indexszabályzat finomhangolása. Az Azure Cosmos DB indexelési szabályzatával kapcsolatos részletes információk itt találhatók.

Kiosztott és felhasznált átviteli sebesség monitorozása

Megfigyelheti a kiosztott kérelemegységek teljes számát, a korlátozottan korlátozott kérelmek számát, valamint a Azure Portal felhasznált kérelemegységek számát. Az alábbi képen egy használati példametrika látható:

Kérelemegységek monitorozása a Azure Portal

Riasztásokat is beállíthat annak ellenőrzéséhez, hogy a korlátozott sebességű kérelmek száma túllép-e egy adott küszöbértéket. További részletekért lásd: Az Azure Cosmos DB monitorozása című cikk. Ezek a riasztások e-mailt küldhetnek a fiókadminisztrátoroknak, vagy meghívhatnak egy egyéni HTTP-webhookot vagy egy Azure-függvényt a kiosztott átviteli sebesség automatikus növeléséhez.

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ényeihez való igazodásával elkerülheti a fel nem használt átviteli sebesség díjait. A kiosztott átviteli sebességet igény szerint bármikor fel- vagy leskálázhatja. Ha az átviteli sebességnek nagyon kiszámíthatónak kell lennie, használhatja Azure Functions, é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 felhasználásának és a korlátozott arányú kérelmek arányának monitorozása azt eredményezheti, hogy a nap folyamán vagy a héten nem kell állandó állapotban tartania a kiépítést. Előfordulhat, hogy éjszaka vagy a hétvégén kevesebb forgalmat kap. A Azure Portal vagy 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 az átviteli sebességet a kódból a napszaktó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éget az egyik olyan területnek kell skáláznia, amikor az adatokat az Azure Cosmos DB-be betölti, 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ére.

  • Ne feledje, hogy a számlázás egy óra részletességű, így nem fog pénzt megtakarítani, ha a kiosztott átviteli sebességet gyakrabban módosítja, mint egy óra egy időben.

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

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

  1. Végezzen el 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 a Azure Portal.

  2. Javasoljuk, hogy hozza létre a tárolókat a vártnál nagyobb átviteli sebességgel, majd szükség szerint skálázással.

  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 száma korlátozott. Ha olyan platformon dolgozik, amely nem támogatott, és az Azure Cosmos DB REST API-ját használja, a fejléc használatával x-ms-retry-after-ms implementálhatja a saját újrapróbálkozési szabályzatát.

  4. Győződjön meg arról, hogy az alkalmazáskód megfelelően támogatja azt az esetet, amikor minden újrapróbálkozás meghiúsul.

  5. A Azure Portal riasztásokat konfigurálhat, hogy értesítéseket kapjon a sebességkorlátozásról. Az elmúlt 15 percben 10 korlátozott kérelemre vonatkozó 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és segítségével 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 épít ki. A kiosztott átviteli sebesség egy 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ítenek a megoldások magas skálázhatóságában és költséghatékonyságában 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 kiosztott 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 a tipikus műveletek futtatásához kapcsolódó kérelemegység-kérelemegység-díj rögzítése az alkalmazás által használt reprezentatív Azure Cosmos DB-tárolón vagy -adatbázison, majd megbecsülni a 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 módon vagy a portál használatával történő becsléséről a lekérdezések költségeinek 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 lehetővé teszi 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 elemzésre használható.

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

  5. Igény szerint hozzáadhat és eltávolíthat az Azure Cosmos DB-fiókhoz társított régiókat, és szabályozhatja a költségeket.

  6. Győződjön meg arról, hogy egyenletesen elosztotta az adatokat és a számítási feladatokat a tárolók logikai partíciói között. 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 feladatokat egyenletesen osztsa szét a partíciók között, vagy adja meg újra az adatokat.

  7. Ha sok tárolóval rendelkezik, és ezek a tárolók nem igényelnek SLA-kat, használhatja az adatbázis-alapú ajánlatot 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 "Azure Cosmos DB ingyenes szint" (egy évig ingyenes), az Azure Cosmos DB kipróbálása (legfeljebb három régió) vagy a letölthető Azure Cosmos DB emulátor használatát fejlesztési/tesztelési forgatókönyvekhez. Ha ezeket a lehetőségeket a teszteléshez használja, jelentősen csökkentheti a költségeit.

  9. További tevékenységprofil-specifikus költségoptimalizálásokat végezhet, 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. Az Azure Cosmos DB fenntartott kapacitásával három évig jelentős, akár 65%-os kedvezményt is kaphat. Az Azure Cosmos DB fenntartott kapacitásmodell egy előzetes kötelezettségvállalás az idő múlásával szükséges kérési egységekre. A kedvezmények rétegzettek, így 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 kiépített é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 lásd: Fenntartott Azure Cosmos DB-kapacitás). Fontolja meg fenntartott kapacitás vásárlását, hogy tovább csökkentse a kiosztott átviteli sebesség költségeit.

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: