Megosztás a következőn keresztül:

A kérelmezési költségek optimalizálása az Azure Cosmos DB-ben

  • Cikk

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.