A kérelmezési költségek optimalizálása az Azure Cosmos DB-ben
A KÖVETKEZŐKRE VONATKOZIK: NoSQL MongoDB Cassandra Gremlin Asztal
Ez a cikk bemutatja, hogyan fordíthatók le az olvasási és írási kérések a kérelemegységekre , és hogyan optimalizálhatók ezeknek a kéréseknek a költségei. Az olvasási műveletek közé tartoznak a pontolvasások és a lekérdezések. Az írási műveletek magukban foglalják az elemek beszúrását, cseréjét, törlését és frissítését.
Az Azure Cosmos DB számos adatbázisműveletet kínál, amelyek a tároló elemein működnek. Az egyes ilyen műveletekhez kapcsolódó költségek a művelet végrehajtásához szükséges CPU, IO és memória függvényében változnak. A hardvererőforrások átgondolása és kezelése helyett a kérelemegységet (RU) egyetlen mértékként tekintheti a különböző adatbázisműveletek végrehajtásához szükséges erőforrásokra a kérések kiszolgálásához.
Kérelem ru-díjának mérése
Fontos a kérések ru-díjának mérése a tényleges költségek megértéséhez és az optimalizálások hatékonyságának értékeléséhez. Ezt a költséget lekérheti az Azure Portal használatával, vagy megvizsgálhatja az Azure Cosmos DB-ből az egyik SDK-on keresztül küldött választ. Ennek elérésére vonatkozó részletes útmutatásért tekintse meg az Azure Cosmos DB kérelemegység-díjának megkeresését.
Adatok olvasása: pontolvasások és lekérdezések
Az Azure Cosmos DB olvasási műveletei általában a leggyorsabb/leghatékonyabbtól a lassabb/kevésbé hatékonyig vannak rendezve a ru-használat szempontjából az alábbiak szerint:
- Pontolvasások (kulcs/érték keresése egyetlen elemazonosítón és partíciókulcson).
- Lekérdezés egy szűrőzáradékkal egyetlen partíciókulcson belül.
- Lekérdezés egyenlőség vagy tartományszűrő záradék nélkül bármely tulajdonságon.
- Lekérdezés szűrők nélkül.
A konzisztenciaszint szerepe
Ha az erős vagy a korlátozott elavultsági konzisztenciaszinteket használja, az olvasási műveletek (pontolvasás vagy lekérdezés) ru-költsége megduplázódik.
Pontolvasások
Az egyetlen tényező, amely befolyásolja a pontolvasás ru-díját (a használt konzisztenciaszint mellett) a lekért elem mérete. Az alábbi táblázat az 1 KB és 100 KB méretű elemek pontolvasási ru-költségét mutatja.
Elem mérete | Egy pont olvasási költsége |
---|---|
1 KB | 1 RU |
100 KB | 10 RU |
Mivel a pontolvasások (az elemazonosítón és a partíciókulcson található kulcs-/értékkeresések) a leghatékonyabb olvasási mód, érdemes gondoskodnia arról, hogy az elemazonosító értelmes értékkel rendelkezzen, így lehetőség szerint pontolvasással (lekérdezés helyett) is lekérheti az elemeket.
Feljegyzés
A NoSQL API-ban a pontolvasások csak REST API-k vagy SDK-k használatával végezhetők el. Az egy elem azonosítójára és partíciókulcsára szűrő lekérdezések nem minősülnek pontolvasási pontnak. A .NET SDK-t használó példa megtekintéséhez olvassa el az elemet az Azure Cosmos DB for NoSQL-ben.
Lekérdezések
A lekérdezések kérelemegységei számos tényezőtől függenek. Például a betöltött/visszaadott Azure Cosmos DB-elemek száma, az indexhez tartozó keresések száma, a lekérdezés fordítási ideje stb. Az Azure Cosmos DB garantálja, hogy ugyanazon adatokon végrehajtott lekérdezések mindig ugyanannyi kérelemegységet használnak fel, még ismétlődő végrehajtások esetén is. A lekérdezés-végrehajtási metrikákat használó lekérdezésprofil jó képet ad a kérelemegységek felhasználásáról.
Bizonyos esetekben 200 és 429 válaszból és változó kérelemegységből álló sorozat jelenhet meg a lekérdezések lapszámozott végrehajtásában, ezért a lekérdezések a lehető leggyorsabban fognak futni a rendelkezésre álló kérelemegységek alapján. Előfordulhat, hogy egy lekérdezés végrehajtása több lapra vagy a kiszolgáló és az ügyfél közötti ciklikus utakra oszlik. 10 000 elem például több oldalként is visszaadható, amelyek mindegyike az adott lap számítása alapján kerül felszámításra. Ha ezeket az oldalakat összegzi, ugyanannyi kérelemegységet kell kapnia, mint a teljes lekérdezéshez.
Metrikák a lekérdezések hibaelhárításához
A lekérdezések által felhasznált teljesítmény és átviteli sebesség (beleértve a felhasználó által definiált függvényeket) többnyire a függvény törzsétől függ. A lekérdezési metrikák engedélyezésével a legegyszerűbben úgy állapítható meg, hogy mennyi időt tölt a lekérdezés végrehajtása az UDF-ben és a felhasznált kérelemegységek számával. Ha a .NET SDK-t használja, az alábbi minta lekérdezési metrikákat adja vissza az SDK:
Retrieved Document Count : 1
Retrieved Document Size : 9,963 bytes
Output Document Count : 1
Output Document Size : 10,012 bytes
Index Utilization : 100.00 %
Total Query Execution Time : 0.48 milliseconds
Query Preparation Times
Query Compilation Time : 0.07 milliseconds
Logical Plan Build Time : 0.03 milliseconds
Physical Plan Build Time : 0.05 milliseconds
Query Optimization Time : 0.00 milliseconds
Index Lookup Time : 0.06 milliseconds
Document Load Time : 0.03 milliseconds
Runtime Execution Times
Query Engine Execution Time : 0.03 milliseconds
System Function Execution Time : 0.00 milliseconds
User-defined Function Execution Time : 0.00 milliseconds
Document Write Time : 0.00 milliseconds
Client Side Metrics
Retry Count : 1
Request Charge : 3.19 RUs
Ajánlott eljárások a lekérdezések költségoptimalizáló használatához
A lekérdezések költségre való optimalizálása során vegye figyelembe az alábbi ajánlott eljárásokat:
Több entitástípus együttes áthelyezése
Próbáljon meg több entitástípust egy vagy kevesebb tárolón belül áthelyezni. Ez a módszer nemcsak a díjszabás szempontjából nyújt előnyöket, hanem a lekérdezések végrehajtására és a tranzakciókra is. A lekérdezések hatóköre egyetlen tárolóra terjed ki; és az atomi tranzakciók több rekordon tárolt eljárásokon/eseményindítókon keresztül egy partíciókulcsra terjednek ki egyetlen tárolón belül. Ha az entitásokat ugyanabban a tárolóban helyezi el, csökkentheti a hálózati kerek utak számát a rekordok közötti kapcsolatok feloldásához. Így növeli a végpontok közötti teljesítményt, lehetővé teszi az atomi tranzakciókat több rekordon keresztül egy nagyobb adathalmaz esetében, és ezáltal csökkenti a költségeket. Ha egy vagy kevesebb tárolón belül több entitástípust is áthelyez, az általában azért van nehéz, mert egy meglévő alkalmazást migrál, és nem szeretne kódmódosításokat végrehajtani – ezt követően érdemes az adatbázis szintjén kiépíteni az átviteli sebességet.
Kisebb kérelemegységek/másodperces használat mérése és finomhangolása
A lekérdezések összetettsége hatással van arra, hogy egy művelet hány kérelemegységet (kérelemegységet) használ fel. A predikátumok száma, a predikátumok jellege, az UDF-ek száma és a forrásadatkészlet mérete. Mindezek a tényezők befolyásolják a lekérdezési műveletek költségeit.
Az Azure Cosmos DB kiszámítható teljesítményt biztosít az átviteli sebesség és a késés szempontjából egy kiépített átviteli modell használatával. A kiosztott átviteli sebesség másodpercenkénti kérelemegységekben vagy RU/s-ban jelenik meg. A kérelemegység (RU) egy logikai absztrakció a kérelem végrehajtásához szükséges számítási erőforrások, például a CPU, a memória, az I/O stb. felett. A kiosztott átviteli sebesség (RU-k) félre lesznek állítva, és dedikáltak a tárolóhoz vagy az adatbázishoz, hogy kiszámítható átviteli sebességet és késést biztosítsanak. A kiosztott átviteli sebesség lehetővé teszi az Azure Cosmos DB számára, hogy kiszámítható és konzisztens teljesítményt, garantált alacsony késést és magas rendelkezésre állást biztosítson bármilyen szinten. A kérelemegységek a normalizált pénznemet jelölik, amely leegyszerűsíti az alkalmazás által igényelt erőforrásokra vonatkozó érvelést.
A kérelem fejlécében visszaadott kérelemdíj egy adott lekérdezés költségét jelzi. Ha például egy lekérdezés 1000 1 KB-os elemet ad vissza, a művelet költsége 1000. Így egy másodpercen belül a kiszolgáló csak két ilyen kérést tart tiszteletben, mielőtt a sebesség korlátozza a későbbi kéréseket. További információt a kérelemegységek cikkében és a kérelemegység-kalkulátorban talál.
Adatok írása
Az elem írásának ru-költsége a következőtől függ:
- Az elem mérete.
- Az indexelési szabályzat által lefedett és indexelendő tulajdonságok száma.
1 KB-os elem beszúrása a költségek indexelése nélkül körülbelül ~5,5 kérelemegység körül. Az elem cseréje kétszer annyiba kerül, mint az ugyanazon elem beszúrásához szükséges díj.
Írások optimalizálása
Az írási műveletek ru-költségének optimalizálásához a legjobb módszer az elemek és az indexelt tulajdonságok számának jogosultsági beállítása.
- Ha nagyon nagy elemeket tárol az Azure Cosmos DB-ben, az magas RU-díjakat eredményez, és mintának tekinthető. Különösen ne tároljon bináris tartalmat vagy nagy méretű szövegrészeket, amelyekről nem kell lekérdeznie. Az ajánlott eljárás az ilyen típusú adatok elhelyezése az Azure Blob Storage-ban, és az Azure Cosmos DB-be írt elem blobjára mutató hivatkozás (vagy hivatkozás) tárolása.
- Ha az indexelési szabályzatot úgy optimalizálja, hogy csak azokat a tulajdonságokat indexelje, amelyekre a lekérdezések szűrnek, jelentős különbséget tehet az írási műveletek által felhasznált kérelemegységekben. Új tároló létrehozásakor az alapértelmezett indexelési szabályzat indexeli az elemekben található összes tulajdonságot. Bár ez jó alapértelmezett fejlesztési tevékenységekhez, erősen ajánlott újraértékelni és testre szabni az indexelési szabályzatot , amikor éles üzemre készül, vagy amikor a számítási feladat jelentős forgalmat kezd kapni.
Az adatok tömeges betöltésekor az Azure Cosmos DB tömeges végrehajtói kódtár használata is ajánlott, mivel az ilyen műveletek ru-felhasználásának optimalizálására lett tervezve. Igény szerint használhatja az Azure Data Factoryt is, amely ugyanarra a kódtárra épül.
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:
- 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ó az átviteli sebesség költségeinek optimalizálásáról
- További információ a tárolási költségek 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
- További információ a fenntartott Azure Cosmos DB-kapacitásról
- 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