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 Táblázat

Ez a cikk azt ismerteti, hogyan fordítják le az olvasási és írási kérelmeket kérelemegységekké , és hogyan optimalizálható ezeknek a kéréseknek a költsége. Az olvasási műveletek pontolvasásokat és lekérdezéseket tartalmaznak. Az írási műveletek közé tartozik az elemek beszúrása, cseréje, törlése és beillesztése.

Az Azure Cosmos DB számos adatbázis-mű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 hardveres erő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ázis-műveletek végrehajtásához szükséges erőforrásokra a kérések kiszolgálásához.

Kérelem kérelemegység-díjának mérése

Fontos a kérések kérelemegység-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 a Azure Portal vagy az Azure Cosmos DB-ből az egyik SDK-on keresztül visszaküldött válasz vizsgálatával lehet lekérni. Ennek elérésére vonatkozó részletes útmutatásért tekintse meg a kérelemegység díjának megkeresését az Azure Cosmos DB-ben .

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 kérelemegység-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őfeltétellel 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ágikonzisztenciaszinteket használja, az olvasási műveletek (pontolvasás vagy lekérdezés) kérelemegység-költsége megduplázódik.

Pontolvasások

A pontolvasás ru-díját befolyásoló egyetlen tényező (a konzisztenciaszinten kívül) a lekért elem mérete. Az alábbi táblázat az 1 KB és 100 KB méretű elemek pontolvasási kérelemegység-költségeit mutatja be.

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 végzett kulcs-/értékkeresések) a leghatékonyabb olvasási mód, győződjön meg arról, hogy az elemazonosító értelmes értékkel rendelkezik, így lehetőség szerint pontolvasással (lekérdezés helyett) lekérheti az elemeket.

Megjegyzés

A NoSQL-hez készült API-ban a pontolvasások csak REST API vagy SDK használatával végezhetők el. Azok a lekérdezések, amelyek egy elem azonosítójára és partíciókulcsára szűrnek, nem minősülnek pontolvasási pontnak. A .NET SDK-t használó példa megtekintéséhez tekintse meg az Azure Cosmos DB for NoSQL egy elemének olvasását ismertető cikket.

Lekérdezések

A lekérdezések kérelemegységei számos tényezőtől függnek. Például a betöltött/visszaadott Azure Cosmos DB-elemek száma, az indexen végrehajtott keresések száma, a lekérdezés fordítási ideje stb. Részletek. Az Azure Cosmos DB garantálja, hogy ugyanazon lekérdezés ugyanazon adatokon való végrehajtásakor mindig ugyanannyi kérelemegységet fog használni, 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 lapozott végrehajtásában, ennek az az oka, hogy a lekérdezések a lehető leggyorsabban futnak az elérhető kérelemegységek alapján. Előfordulhat, hogy a lekérdezés-végrehajtás több oldalra vagy a kiszolgáló és az ügyfél közötti váltásokra tör. Például 10 000 elemet lehet több oldalként visszaadni, amelyek mindegyike az adott lapra vonatkozó számítás 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íthatja 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 mintalekérdezés-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 költségoptimalizált lekérdezésekhez

A lekérdezések költségoptimalizálásához vegye figyelembe az alábbi ajánlott eljárásokat:

  • Több entitástípus közös elhelyezése

    Próbáljon meg több entitástípust együtttelepíteni egyetlen vagy kisebb számú tárolóban. Ez a módszer nemcsak a díjszabás szempontjából előnyös, hanem a lekérdezések végrehajtásához és a tranzakciókhoz is. A lekérdezések hatóköre egyetlen tárolóra terjed ki; és több rekordon tárolt eljárásokon/eseményindítókon keresztül végrehajtott atomi tranzakciók egyetlen tárolón belüli partíciókulcsra terjednek ki. Ha az entitásokat ugyanabban a tárolóban helyezi el, azzal csökkentheti a hálózati adatváltások számát a rekordok közötti kapcsolatok feloldása érdekében. Így növeli a végpontok közötti teljesítményt, lehetővé teszi az atomi tranzakciókat több rekordon egy nagyobb adathalmaz esetében, és ezáltal csökkenti a költségeket. Ha több entitástípust helyez el egyetlen vagy kisebb számú tárolóban, 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 – érdemes megfontolnia az átviteli sebesség adatbázisszinten történő kiépítését.

  • 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 (RU-t) 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 átvitelisebesség-modell használatával. A kiosztott átviteli sebesség másodpercenkénti kérelemegységekben vagy RU/s-ben jelenik meg. A kérelemegység (RU) logikai absztrakció a számítási erőforrások, például a CPU, a memória, az I/O stb. felett. a kérés végrehajtásához szükséges. A kiosztott átviteli sebességet (RU-kat) a rendszer elkülöníti, és a tároló vagy az adatbázis számára dedikáltan biztosítja a kiszámítható átviteli sebességet és késést. A kiosztott átviteli sebesség lehetővé teszi, hogy az Azure Cosmos DB kiszámítható és konzisztens teljesítményt, garantált alacsony késést és magas rendelkezésre állást biztosítson bármilyen léptékben. A kérelemegységek a normalizált pénznemet jelölik, amely leegyszerűsíti az alkalmazás által igényelt erőforrások számát.

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átozná a későbbi kéréseket. További információkért lásd a kérelemegységek cikkét és a kérelemegység-kalkulátort.

Adatok írása

Az elem írásának kérelemegység-költsége a következőtől függ:

1 KB-os elem beszúrása körülbelül 5,5 kérelemegység körüli indexelés nélkül. Egy cikk cseréje kétszer annyiba kerül, mint az ugyanazon cikk beszúrásához szükséges díj.

Írások optimalizálása

Az írási műveletek kérelemegység-költségének optimalizálásának legjobb módja az elemek és az indexelt tulajdonságok számának jogosultsága.

  • Ha nagyon nagy elemeket tárol az Azure Cosmos DB-ben, az magas kérelemegység-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érdezést elvégeznie. Az ajánlott eljárás az ilyen típusú adatok elhelyezése Azure Blob Storage, és az Azure Cosmos DB-be írt elem blobjára mutató hivatkozás (vagy hivatkozás) tárolása.
  • Ha úgy optimalizálja az indexelési szabályzatot, 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 az elemekben található minden tulajdonságot indexel. Bár ez egy jó alapértelmezett fejlesztési tevékenység, erősen ajánlott újraértékelődni é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 javasoljuk az Azure Cosmos DB tömeges végrehajtói kódtár használatát is, mivel az ilyen műveletek kérelemegység-felhasználásának optimalizálására lett tervezve. Igény szerint használhat Azure Data Factory is, amely ugyanarra a kódtárra épül.

Következő lépések

A következő cikkekből többet is megtudhat a költségoptimalizálásról az Azure Cosmos DB-ben: