Az Azure Cosmos DB használatakor felmerülő lekérdezési hibák elhárítása

A KÖVETKEZŐRE VONATKOZIK: NoSQL

Ez a cikk végigvezeti a kérelmek Azure Cosmos DB-ben való hibaelhárításának általános javasolt módszerén. Bár a cikkben ismertetett lépéseket nem érdemes teljes védelemként figyelembe venni a lehetséges lekérdezési problémák ellen, a leggyakoribb teljesítménytippeket itt foglaltuk össze. Ezt a cikket érdemes kiindulási pontként használnia a lassú vagy költséges lekérdezések hibaelhárításához az Azure Cosmos DB for NoSQL-ben. A diagnosztikai naplókat is használhatja a lassú vagy jelentős mennyiségű átviteli sebességet használó lekérdezések azonosítására. Ha az Azure Cosmos DB Api for MongoDB-t használja, az Azure Cosmos DB API for MongoDB lekérdezési hibaelhárítási útmutatóját kell használnia

Az Azure Cosmos DB lekérdezésoptimalizálásai a következőképpen vannak kategorizálva:

• Optimalizálások, amelyek csökkentik a lekérdezés kérelemegység-díját
• Optimalizálási megoldások, amelyek csökkenti a késést

Ha csökkenti egy lekérdezés RU-díját, általában a késést is csökkenti.

Ez a cikk példákat tartalmaz, amelyeket újra létrehozhat a táplálkozási adatkészlet használatával.

Gyakori SDK-problémák

Az útmutató elolvasása előtt érdemes megfontolni a lekérdezési motorhoz nem kapcsolódó gyakori SDK-problémákat.

• Kövesse az alábbi SDK-teljesítménnyel kapcsolatos tippeket a lekérdezéshez.
• A lekérdezésekben olykor üres oldalak szerepelnek még akkor is, ha egy későbbi oldalon vannak eredmények. Ennek oka a következők egyike lehet:
  • Az SDK több hálózati hívást is kezdeményezhet.
  • Előfordulhat, hogy a lekérdezés sok időt vesz igénybe a dokumentumok lekéréséhez.
• Minden lekérdezés rendelkezik egy folytatási tokennel, amely lehetővé teszi a lekérdezés folytatását. Mindig ürítse ki teljesen a lekérdezést. További információ a többoldalos eredmények kezeléséről

Lekérdezésmetrikák megállapítása

Amikor optimalizál egy lekérdezést az Azure Cosmos DB-ben, az első lépés mindig a lekérdezéshez tartozó lekérdezési metrikák lekérése . Ezek a metrikák a Azure Portal keresztül is elérhetők. Miután futtatta a lekérdezést a Data Explorer, a lekérdezési metrikák az Eredmények lap mellett láthatók:

A lekérdezési metrikák lekérdezése után hasonlítsa össze lekérdezéshez tartozó Beérkezett dokumentumok száma és Kimenő dokumentumok száma értéket. Ebből az összehasonlításból kiderül, hogy jelen cikk mely szakaszait érdemes áttekinteni.

A Lekért dokumentumok száma a lekérdezési motor által betöltendő dokumentumok száma. A Kimeneti dokumentumok száma a lekérdezés eredményeihez szükséges dokumentumok száma. Ha a lekért dokumentumszám jelentősen meghaladja a kimeneti dokumentumok számát, a lekérdezés legalább egy része nem tudott indexet használni, és vizsgálatra volt szükség.

A forgatókönyvhöz kapcsolódó lekérdezésoptimalizálások megismeréséhez tekintse meg az alábbi szakaszokat.

A lekérdezés ru-díja túl magas

A lekért dokumentumok száma jelentősen magasabb, mint a kimeneti dokumentumok száma

• Adja meg a szükséges elérési utakat az indexelési szabályzatban.

• Az indexet használó rendszerfüggvények ismertetése.

• A sztringrendszerfüggvények végrehajtásának javítása.

• Annak megismerése, hogy mely összesítő lekérdezések használják az indexet.

• Optimalizálja a szűrőt és az ORDER BY záradékot is tartalmazó lekérdezéseket.

• A JOIN-kifejezések optimalizálása egy alkérdezés használatával.

A beolvasott dokumentumok száma körülbelül megegyezik a kimeneti dokumentumok számával

• Minimalizálja a több partícióra kiterjedő lekérdezések számát.

• Optimalizálja a több tulajdonságra vonatkozó szűrőkkel rendelkező lekérdezéseket.

• Optimalizálja a szűrőt és az ORDER BY záradékot is tartalmazó lekérdezéseket.

A lekérdezés ru-díja elfogadható, de a késés továbbra is túl magas

• A közelség javítása.

• Növelje a kiosztott átviteli sebességet.

• Növelje a MaxConcurrency értékét.

• MaxBufferedItemCount növelése.

Lekérdezések, ahol a lekért dokumentumok száma meghaladja a kimeneti dokumentumok számát

A Lekért dokumentumok száma a lekérdezési motor által betöltendő dokumentumok száma. A Kimeneti dokumentumok száma a lekérdezés által visszaadott dokumentumok száma. Ha a lekért dokumentumszám jelentősen meghaladja a kimeneti dokumentumok számát, a lekérdezés legalább egy része nem tudott indexet használni, és vizsgálatra volt szükség.

Íme egy példa az index által nem teljes mértékben kiszolgált vizsgálati lekérdezésre:

Lekérdezés:

SELECT VALUE c.description
FROM c
WHERE UPPER(c.description) = "BABYFOOD, DESSERT, FRUIT DESSERT, WITHOUT ASCORBIC ACID, JUNIOR"

Lekérdezési metrikák:

Retrieved Document Count                 :          60,951
Retrieved Document Size                  :     399,998,938 bytes
Output Document Count                    :               7
Output Document Size                     :             510 bytes
Index Utilization                        :            0.00 %
Total Query Execution Time               :        4,500.34 milliseconds
  Query Preparation Times
    Query Compilation Time               :            0.09 milliseconds
    Logical Plan Build Time              :            0.05 milliseconds
    Physical Plan Build Time             :            0.04 milliseconds
    Query Optimization Time              :            0.01 milliseconds
  Index Lookup Time                      :            0.01 milliseconds
  Document Load Time                     :        4,177.66 milliseconds
  Runtime Execution Times
    Query Engine Times                   :          322.16 milliseconds
    System Function Execution Time       :           85.74 milliseconds
    User-defined Function Execution Time :            0.00 milliseconds
  Document Write Time                    :            0.01 milliseconds
Client Side Metrics
  Retry Count                            :               0
  Request Charge                         :        4,059.95 RUs

A lekért dokumentumok száma (60 951) jelentősen magasabb, mint a kimeneti dokumentumok száma (7), ami azt jelenti, hogy ez a lekérdezés dokumentumvizsgálatot eredményezett. Ebben az esetben az UPPER() rendszerfüggvény nem használ indexet.

A szükséges elérési utak belefoglalása az indexelési szabályzatba

Az indexelési szabályzatnak ki kell terjednie a záradékokban, záradékokban, JOINORDER BY és a legtöbb rendszerfüggvényben WHERE szereplő tulajdonságokra. Az indexelési szabályzatban megadott kívánt elérési utaknak egyezniük kell a JSON-dokumentumokban szereplő tulajdonságokkal.

Megjegyzés

Az Azure Cosmos DB indexelési szabályzatának tulajdonságai megkülönböztetik a kis- és nagybetűket

Ha a következő egyszerű lekérdezést futtatja a táplálkozási adatkészleten, sokkal alacsonyabb ru-díjat fog megfigyelni, amikor a WHERE záradékban lévő tulajdonság indexelt:

Eredeti

Lekérdezés:

SELECT *
FROM c
WHERE c.description = "Malabar spinach, cooked"

Indexelési szabályzat:

{
    "indexingMode": "consistent",
    "automatic": true,
    "includedPaths": [
        {
            "path": "/*"
        }
    ],
    "excludedPaths": [
        {
            "path": "/description/*"
        }
    ]
}

RU-díj: 409,51 KÉRELEM

Optimalizált

Frissített indexelési szabályzat:

{
    "indexingMode": "consistent",
    "automatic": true,
    "includedPaths": [
        {
            "path": "/*"
        }
    ],
    "excludedPaths": []
}

RU-díj: 2,98 kérelemegység

Az indexelési szabályzathoz bármikor hozzáadhat tulajdonságokat, és nincs hatással az írási és olvasási rendelkezésre állásra. Nyomon követheti az indexátalakítás előrehaladását.

Annak ismertetése, hogy mely rendszerfüggvények használják az indexet

A legtöbb rendszerfüggvény indexeket használ. Íme az indexeket használó gyakori sztringfüggvények listája:

• StartsWith
• Contains
• RegexMatch
• Bal
• Részszúrás – de csak akkor, ha az első num_expr 0

Az alábbiakban néhány gyakori rendszerfüggvényt talál, amelyek nem használják az indexet, és minden dokumentumot be kell tölteni, amikor záradékban WHERE használják:

Rendszerfüggvény	Optimalizálási ötletek
Felső/alsó	Ahelyett, hogy a rendszerfüggvénnyel normalizálja az összehasonlításhoz szükséges adatokat, a beszúráskor normalizálja a burkolatot. Egy lekérdezés, például SELECT * FROM c WHERE UPPER(c.name) = 'BOB' válik.SELECT * FROM c WHERE c.name = 'BOB'
GetCurrentDateTime/GetCurrentTimestamp/GetCurrentTicks	Számítsa ki a lekérdezés végrehajtása előtti aktuális időt, és használja ezt a sztringértéket a WHERE záradékban.
Matematikai függvények (nem aggregátumok)	Ha gyakran kell kiszámolnia egy értéket a lekérdezésben, fontolja meg az érték tulajdonságként való tárolását a JSON-dokumentumban.

Ezek a rendszerfüggvények indexeket használhatnak, kivéve az összesítő lekérdezésekben:

Rendszerfüggvény	Optimalizálási ötletek
Térbeli rendszerfüggvények	A lekérdezés eredményének tárolása valós idejű materializált nézetben

Ha a záradékban használják, a SELECT nem hatékony rendszerfüggvények nem befolyásolják, hogy a lekérdezések hogyan használhatják az indexeket.

A sztringrendszerfüggvények végrehajtásának javítása

Az indexeket használó egyes rendszerfüggvények esetében javíthatja a lekérdezés végrehajtását, ha hozzáad egy záradékot ORDER BY a lekérdezéshez.

Pontosabban minden olyan rendszerfüggvény, amelynek kérelemegység-díja a tulajdonság számosságának növekedésével nő, előnyös ORDER BY lehet a lekérdezésben. Ezek a lekérdezések indexvizsgálatot végeznek, így a lekérdezés eredményeinek rendezése hatékonyabbá teheti a lekérdezést.

Ez az optimalizálás javíthatja a végrehajtást a következő rendszerfüggvények esetében:

• StartsWith (ahol a kis- és nagybetűk nem különböztetik meg = igaz)
• StringEquals (ahol a kis- és nagybetűk megkülönböztetése = igaz)
• Contains
• RegexMatch
• EndsWith

Vegyük például az alábbi lekérdezést a következővel CONTAINS: . CONTAINS indexeket fog használni, de néha még a megfelelő index hozzáadása után is nagyon magas kérelemegység-díjat tapasztalhat az alábbi lekérdezés futtatásakor.

Eredeti lekérdezés:

SELECT *
FROM c
WHERE CONTAINS(c.town, "Sea")

A lekérdezések végrehajtásának javításához vegye fel a következőt ORDER BY:

SELECT *
FROM c
WHERE CONTAINS(c.town, "Sea")
ORDER BY c.town

Ugyanez az optimalizálás segíthet a további szűrőkkel rendelkező lekérdezésekben. Ebben az esetben a legjobb, ha egyenlőségi szűrőkkel rendelkező tulajdonságokat is hozzáad a ORDER BY záradékhoz.

Eredeti lekérdezés:

SELECT *
FROM c
WHERE c.name = "Samer" AND CONTAINS(c.town, "Sea")

Javíthatja a lekérdezések végrehajtását a (c.name, c.town) összetett indexének hozzáadásávalORDER BY:

SELECT *
FROM c
WHERE c.name = "Samer" AND CONTAINS(c.town, "Sea")
ORDER BY c.name, c.town

Annak ismertetése, hogy mely összesítési lekérdezések használják az indexet

A legtöbb esetben az Azure Cosmos DB összesítő rendszerfüggvényei az indexet fogják használni. Az összesítő lekérdezések szűrőitől vagy további záradékaitól függően azonban előfordulhat, hogy a lekérdezési motor nagy számú dokumentum betöltéséhez szükséges. A lekérdezési motor általában először egyenlőség- és tartományszűrőket alkalmaz. A szűrők alkalmazása után a lekérdezési motor kiértékelheti a további szűrőket, és szükség esetén betöltheti a fennmaradó dokumentumokat az összesítés kiszámításához.

A két mintalekérdezés alapján például az egyenlőségi és CONTAINS a rendszerfüggvény-szűrővel rendelkező lekérdezések általában hatékonyabbak lesznek, mint a CONTAINS csak rendszerfüggvény-szűrővel rendelkező lekérdezések. Ennek az az oka, hogy a rendszer először az egyenlőségi szűrőt alkalmazza, és az indexet használja, mielőtt a dokumentumokat be kellene tölteni a drágább CONTAINS szűrőhöz.

Lekérdezés csak CONTAINS szűrővel – magasabb kérelemegység-díj:

SELECT COUNT(1)
FROM c
WHERE CONTAINS(c.description, "spinach")

Lekérdezés egyenlőségszűrővel és CONTAINS szűrővel – alacsonyabb KÉRELEMEGYSÉG-díj:

SELECT AVG(c._ts)
FROM c
WHERE c.foodGroup = "Sausages and Luncheon Meats" AND CONTAINS(c.description, "spinach")

Íme néhány további példa az indexet nem teljes mértékben használó összesítő lekérdezésekre:

Olyan rendszerfüggvényekkel rendelkező lekérdezések, amelyek nem használják az indexet

Tekintse meg a megfelelő rendszerfüggvény oldalát , és ellenőrizze, hogy az indexet használja-e.

SELECT MAX(c._ts)
FROM c
WHERE CONTAINS(c.description, "spinach")

Lekérdezések összesítése felhasználó által definiált függvényekkel (UDF-ek)

SELECT AVG(c._ts)
FROM c
WHERE udf.MyUDF("Sausages and Luncheon Meats")

Lekérdezések a GROUP BY használatával

A lekérdezések GROUP BY kérelemegység-díja a záradékban lévő GROUP BY tulajdonságok számosságának növekedésével nő. Az alábbi lekérdezésben például a lekérdezés kérelemegység-díja nő, ahogy az egyedi leírások száma nő.

Az aggregátumfüggvények RU-díja egy GROUP BY záradékkal magasabb lesz, mint egy összesítő függvény kérelemegység-díja. Ebben a példában a lekérdezési motornak minden olyan dokumentumot be kell töltenie, amely megfelel a c.foodGroup = "Sausages and Luncheon Meats" szűrőnek, hogy a kérelemegység-terhelés várhatóan magas legyen.

SELECT COUNT(1)
FROM c
WHERE c.foodGroup = "Sausages and Luncheon Meats"
GROUP BY c.description

Ha gyakran tervezi ugyanazokat az összesítő lekérdezéseket futtatni, hatékonyabb lehet egy valós idejű materializált nézet létrehozása az Azure Cosmos DB változáscsatornájával , mint az egyes lekérdezések futtatása.

Szűrővel és ORDER BY záradékkal rendelkező lekérdezések optimalizálása

Bár a szűrővel és záradékkal ORDER BY rendelkező lekérdezések általában tartományindexet használnak, hatékonyabbak lesznek, ha összetett indexből is kiszolgálhatók. Az indexelési szabályzat módosítása mellett az összetett index összes tulajdonságát hozzá kell adnia a ORDER BY záradékhoz. A lekérdezés ezen módosítása biztosítja, hogy a lekérdezés az összetett indexet használja. A hatás megfigyeléséhez futtasson egy lekérdezést a táplálkozási adathalmazon:

Eredeti

Lekérdezés:

SELECT *
FROM c
WHERE c.foodGroup = "Soups, Sauces, and Gravies"
ORDER BY c._ts ASC

Indexelési szabályzat:

{

        "automatic":true,
        "indexingMode":"Consistent",
        "includedPaths":[  
            {  
                "path":"/*"
            }
        ],
        "excludedPaths":[]
}

KÉRELEMEGYSÉG-díj: 44,28 kérelemegység

Optimalizált

Frissített lekérdezés (mindkét tulajdonságot tartalmazza a ORDER BY záradékban):

SELECT *
FROM c
WHERE c.foodGroup = "Soups, Sauces, and Gravies"
ORDER BY c.foodGroup, c._ts ASC

Frissített indexelési szabályzat:

{  
        "automatic":true,
        "indexingMode":"Consistent",
        "includedPaths":[  
            {  
                "path":"/*"
            }
        ],
        "excludedPaths":[],
        "compositeIndexes":[  
            [  
                {  
                    "path":"/foodGroup",
                    "order":"ascending"
        },
                {  
                    "path":"/_ts",
                    "order":"ascending"
                }
            ]
        ]
    }

KÉRELEMEGYSÉG-díj: 8,86 kérelemegység

JOIN-kifejezések optimalizálása segédlekérdezés használatával

A többértékű al lekérdezések optimalizálhatják JOIN a kifejezéseket úgy, hogy predikátumokat nyomnak le minden select-many kifejezés után, nem pedig a WHERE záradék összes keresztillesztése után.

Fontolja meg ezt a lekérdezést:

SELECT Count(1) AS Count
FROM c
JOIN t IN c.tags
JOIN n IN c.nutrients
JOIN s IN c.servings
WHERE t.name = 'infant formula' AND (n.nutritionValue > 0
AND n.nutritionValue < 10) AND s.amount > 1

KÉRELEMEGYSÉG-díj: 167,62 kérelemegység

Ebben a lekérdezésben az index megfelel minden olyan dokumentumnak, amelynek címkéje 0-nál nagyobb és amount 1-nél nagyobb.infant formulanutritionValue Az JOIN itt látható kifejezés a címkék, tápanyagok és adagtömbök összes elemének kereszttermékét hajtja végre az egyes egyező dokumentumokhoz, mielőtt szűrőt alkalmaz. A WHERE záradék ezután minden rekordra <c, t, n, s> alkalmazza a szűrő predikátumot.

Ha például egy egyező dokumentum mind a három tömbben 10 elemet tartalmaz, az 1 x 10 x 10 x 10 (azaz 1000) rekordokra fog kiterjeszteni. Az itt található segéd lekérdezések segíthetnek kiszűrni az összekapcsolt tömbelemeket, mielőtt a következő kifejezéshez csatlakozna.

Ez a lekérdezés egyenértékű az előzővel, de segéd lekérdezéseket használ:

SELECT Count(1) AS Count
FROM c
JOIN (SELECT VALUE t FROM t IN c.tags WHERE t.name = 'infant formula')
JOIN (SELECT VALUE n FROM n IN c.nutrients WHERE n.nutritionValue > 0 AND n.nutritionValue < 10)
JOIN (SELECT VALUE s FROM s IN c.servings WHERE s.amount > 1)

KÉRELEMEGYSÉG-díj: 22,17 kérelemegység

Tegyük fel, hogy a címketömbben csak egy elem felel meg a szűrőnek, és hogy a tápanyag- és a adagtömbhöz is öt elem tartozik. A JOIN kifejezések 1 x 1 x 5 x 5 = 25 elemre lesznek kiterjesztve, szemben az első lekérdezés 1000 elemével.

Olyan lekérdezések, ahol a beérkezett dokumentumok száma egyenlő a kimenő dokumentumok számával

Ha a Beérkezett dokumentumok száma körülbelül egyenlő a Kimenő dokumentumok számával, a lekérdezési motornak nem kellett sok szükségtelen dokumentumot megvizsgálnia. A kulcsszót használó lekérdezésekhez hasonlóan a TOPLekért dokumentumok száma 1-re is meghaladhatja a kimeneti dokumentumok számát . Ezzel nem kell törődnie.

A több partícióra kiterjedő lekérdezések számának minimalizálása

Az Azure Cosmos DB particionálással skálázza az egyes tárolókat a kérelemegységek és az adattárolási igények növekedésével. Minden egyes fizikai partíció önálló, független indexszel rendelkezik. Ha a lekérdezés olyan egyenlőségi szűrővel rendelkezik, amely megfelel a tároló partíciókulcsának, csak a megfelelő partíció indexét kell ellenőriznie. Ez az optimalizálás csökkenti a lekérdezéshez szükséges kérelemegységek teljes számát.

Ha nagy számú kiosztott kérelemegysége van (több mint 30 000), vagy nagy mennyiségű (körülbelül 100 GB-nál több) adatot tárol, valószínűleg elég nagy tárolóval rendelkezik ahhoz, hogy jelentős mértékben csökkenjenek a lekérdezési kérelemegységek díjai.

Ha például a foodGroup partíciókulcsú tárolót hoz létre, a következő lekérdezésekhez csak egyetlen fizikai partíciót kell ellenőriznie:

SELECT *
FROM c
WHERE c.foodGroup = "Soups, Sauces, and Gravies" and c.description = "Mushroom, oyster, raw"

A partíciókulccsal rendelkező szűrővel rendelkező IN lekérdezések csak a megfelelő fizikai partíció(ka)t ellenőrzik, és nem fogják "kiradulni":

SELECT *
FROM c
WHERE c.foodGroup IN("Soups, Sauces, and Gravies", "Vegetables and Vegetable Products") and c.description = "Mushroom, oyster, raw"

Azok a lekérdezések, amelyek tartományszűrőkkel rendelkeznek a partíciókulcson, vagy amelyek nem rendelkeznek szűrővel a partíciókulcson, "ki kell kapcsolni" a lekérdezést, és minden fizikai partíció indexében ellenőrizni kell az eredményeket:

SELECT *
FROM c
WHERE c.description = "Mushroom, oyster, raw"

SELECT *
FROM c
WHERE c.foodGroup > "Soups, Sauces, and Gravies" and c.description = "Mushroom, oyster, raw"

Több tulajdonság alapján szűrt lekérdezések optimalizálása

Bár a több tulajdonságra vonatkozó szűrőkkel rendelkező lekérdezések általában tartományindexet használnak, hatékonyabbak lesznek, ha összetett indexből is kiszolgálhatók. Kis mennyiségű adat esetén ez az optimalizálás nem lesz jelentős hatással. Nagy mennyiségű adat esetén azonban hasznos lehet. Összetett indexenként legfeljebb egy nem egyenlőségi szűrőt optimalizálhat. Ha a lekérdezés több nem egyenlőségi szűrővel rendelkezik, válasszon egyet közülük, amely az összetett indexet fogja használni. A többi továbbra is tartományindexeket fog használni. A nem egyenlőségi szűrőt utoljára az összetett indexben kell meghatározni. További információ az összetett indexekről.

Íme néhány példa az összetett indexszel optimalizálható lekérdezésekre:

SELECT *
FROM c
WHERE c.foodGroup = "Vegetables and Vegetable Products" AND c._ts = 1575503264

SELECT *
FROM c
WHERE c.foodGroup = "Vegetables and Vegetable Products" AND c._ts > 1575503264

Íme a releváns összetett index:

{  
        "automatic":true,
        "indexingMode":"Consistent",
        "includedPaths":[  
            {  
                "path":"/*"
            }
        ],
        "excludedPaths":[],
        "compositeIndexes":[  
            [  
                {  
                    "path":"/foodGroup",
                    "order":"ascending"
                },
                {  
                    "path":"/_ts",
                    "order":"ascending"
                }
            ]
        ]
}

Optimalizálások, amelyek csökkentik a lekérdezések késését

Sok esetben a kérelemegységek díja elfogadható lehet, ha a lekérdezés késése még mindig túl magas. A következő szakaszok a lekérdezési késleltetés csökkentésére vonatkozó tippek áttekintését tartalmazzák. Ha ugyanazt a lekérdezést többször futtatja ugyanazon az adathalmazon, akkor általában minden alkalommal ugyanaz a kérelemegységdíj lesz felszámítva. A lekérdezések késése azonban lekérdezés-végrehajtásonként eltérő lehet.

A közelség javítása

Az Azure Cosmos DB-fióktól eltérő régióból futtatott lekérdezések késése nagyobb lesz, mint ha ugyanabban a régióban futnának. Ha például a kódot az asztali számítógépén futtatja, számolnia kell azzal, hogy a késés mértéke több tíz vagy száz ezredmásodperccel (vagy még többel) nagyobb lesz, mintha a lekérdezést az Azure Cosmos DB-vel azonos Azure-régióban lévő virtuális gépről futtatná. Az Azure Cosmos DB-ben egyszerűen oszthatja el globálisan az adatokat , így közelebb hozhatja az adatokat az alkalmazáshoz.

Kiosztott átviteli sebesség növelése

Az Azure Cosmos DB-ben a kiosztott átviteli sebességet kérelemegységek (RU-k) mérik. Tegyük fel, hogy van egy lekérdezés, amelynek átviteli sebessége 5 RU. Ha például 1000 kérelemegységet oszt ki, a lekérdezést másodpercenként 200-szor futtathatja. Ha a lekérdezést akkor próbálta futtatni, amikor nem volt elég rendelkezésre álló átviteli sebesség, az Azure Cosmos DB HTTP 429-hibajelzést ad vissza. A NoSQL SDK-k aktuális API-ja automatikusan újrapróbálkozott a lekérdezéssel, miután rövid ideig várakozott. A szabályozott kérések hosszabb időt vesznek igénybe, így a kiosztott átviteli sebesség növelése javíthatja a lekérdezések késését. A szabályozott kérelmek teljes számát a Azure Portal Metrikák paneljén figyelheti meg.

MaxConcurrency növelése

A párhuzamos lekérdezések több partíció párhuzamos lekérdezésével működnek. Az egyes particionált gyűjteményekből származó adatok azonban a lekérdezés szempontjából soros módon lesznek lekérve. Ha tehát a MaxConcurrency értékét a partíciók számára állítja be, akkor a legjobb esélye van a legteljesebb lekérdezés elérésére, feltéve, hogy minden más rendszerfeltétel változatlan marad. Ha nem tudja a partíciók számát, a MaxConcurrency (vagy a régebbi SDK-verziókban a MaxDegreesOfParallelism) beállítást magas számra állíthatja. A rendszer a minimális (partíciók száma, felhasználó által megadott bemenet) választja ki a párhuzamosság maximális fokát.

MaxBufferedItemCount növelése

A lekérdezések úgy vannak kialakítva, hogy előre lekérje az eredményeket, miközben az ügyfél feldolgozza az aktuális eredményköteget. Az előleolvasás segít a lekérdezések teljes késésének javításában. A MaxBufferedItemCount beállítása korlátozza az előre lekért eredmények számát. Ha ezt az értéket a visszaadott eredmények várt számára (vagy magasabb számra) állítja be, a lekérdezés a lehető legjobban kihasználhatja az előre beolvasás előnyeit. Ha ezt az értéket -1 értékre állítja, a rendszer automatikusan meghatározza a pufferelendő elemek számát.

Következő lépések

Az alábbi cikkekből megtudhatja, hogyan mérheti a kérelemegységeket lekérdezésenként, hogyan kérhet le végrehajtási statisztikákat a lekérdezések hangolásához, és további tudnivalókat:

• SQL-lekérdezés-végrehajtási metrikák lekérése a .NET SDK használatával
• A lekérdezési teljesítmény finomhangolása az Azure Cosmos DB-vel
• Teljesítménnyel kapcsolatos tippek .NET SDK-hoz
• Teljesítménytippek a Java v4 SDK-hoz