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

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

  • Cikk

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 vennie 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álni 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 a MongoDB-hez készült Azure Cosmos DB API-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 az alábbiak szerint vannak kategorizálva:

  • Optimalizálások, amelyek csökkentik a lekérdezés kérelemegységének (RU) 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énytippeket 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 okai a következőek lehetnek:
    • 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ó több oldalnyi eredmény 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 az Azure Portalon is elérhetők. Miután futtatta a lekérdezést az Adatkezelőben, a lekérdezési metrikák az Eredmények lap mellett láthatók:

Lekérdezési metrikák lekérése

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 dokumentumszám 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 magasabb a kimeneti dokumentumszámnál, 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


A beolvasott dokumentumszám körülbelül egyenlő a kimeneti dokumentumszámokkal


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

Lekérdezések, ahol a beolvasott dokumentum száma meghaladja a kimeneti dokumentum számát

A lekért dokumentumszám a lekérdezési motor által betöltendő dokumentumok száma. A kimeneti dokumentum száma a lekérdezés által visszaadott dokumentumok száma. Ha a lekért dokumentumszám jelentősen magasabb a kimeneti dokumentumszámnál, 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 dokumentumszám (60 951) jelentősen magasabb, mint a kimeneti dokumentum 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, ORDER BY záradékokban és a legtöbb rendszerfüggvényben WHERE található tulajdonságokraJOIN. Az indexelési szabályzatban megadott kívánt elérési utaknak egyezniük kell a JSON-dokumentumokban szereplő tulajdonságokkal.

Feljegyzés

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

Ha az alábbi egyszerű lekérdezést futtatja a táplálkozási adatkészleten, sokkal alacsonyabb RU-díjat fog megfigyelni, amikor a WHERE záradék tulajdonsága 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 RU

Optimalizált

Frissített indexelési szabályzat:

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

RU-díj: 2,98 RU

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
  • Left
  • Részszúrás – de csak akkor, ha az első num_expr 0

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

Rendszerfüggvény Optimalizálási ötletek
Felső/alsó Ahelyett, hogy a rendszerfüggvény használatával normalizálja az összehasonlítási adatokat, a beszúráskor normalizálja a burkolatot. Egy lekérdezés, mint lesz SELECT * FROM c WHERE UPPER(c.name) = 'BOB' 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ámítania 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, ha a lekérdezésekben aggregátumokat használnak:

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

Egyes indexeket használó rendszerfüggvények esetében egy záradék hozzáadásával ORDER BY javíthatja a lekérdezés végrehajtását.

Pontosabban minden olyan rendszerfüggvény, amelynek ru-díja a tulajdonság számossága növekedésével növekszik, 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 a következő rendszerfüggvények végrehajtását javíthatja:

  • StartsWith (ahol a kis- és nagybetűk nem érzékenyek = igaz)
  • StringEquals (ahol a kis- és nagybetűk érzéketlenek = 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 RU-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 további szűrőkkel rendelkező lekérdezésekben is segíthet. Ebben az esetben a legjobb, ha egyenlőségszű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")

A lekérdezések végrehajtásának javításához adjon hozzá ORDER BY egy összetett indexet (c.name, c.town):

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és 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 további szűrőket értékelhet ki, és szükség esetén betöltheti a fennmaradó dokumentumokat az összesítés kiszámításához.

A két minta lekérdezés alapján például az egyenlőség- és CONTAINS a rendszerfüggvény-szűrővel rendelkező lekérdezések általában hatékonyabbak lesznek, mint a csak CONTAINS 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 kell tölteni a drágább CONTAINS szűrőhöz.

Lekérdezés csak CONTAINS szűrővel – magasabb RU-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 RU-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 összesítő lekérdezésekre, amelyek nem használják teljes mértékben az indexet:

Lekérdezések olyan rendszerfüggvényekkel, amelyek nem használják az indexet

Tekintse meg a megfelelő rendszerfüggvény lapját , hogy lássa, használja-e az indexet.

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 ru-díja a záradék tulajdonságainak GROUP BY számossága növekedésével GROUP BY nő. Az alábbi lekérdezésben például az egyedi leírások számának növekedésével nő a lekérdezés ru-díja.

Az aggregátumfüggvény ru-díja egy GROUP BY záradékkal magasabb lesz, mint az összesítő függvény ru-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 az RU-díj várhatóan magas legyen.

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

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

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

Bár a szűrővel és ORDER BY záradékkal 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ást megfigyelheti egy lekérdezés futtatásával a táplálkozási adatkészleten:

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":[]
}

RU-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"
                }
            ]
        ]
    }

RU-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 úgy optimalizálhatják JOIN a kifejezéseket, hogy predikátumokat nyomnak az egyes select-many kifejezések után, nem pedig a WHERE záradékban lévő keresztcsatlakozások 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

RU-díj: 167,62 KÉRELEM

Ebben a lekérdezésben az index megfelel minden olyan dokumentumnak, amelynek neve infant formulanutritionValue 0-nál nagyobb, és amount 1-nél nagyobb. Az JOIN itt található kifejezés a címkék, tápanyagok és adagok tömbjeinek összes elemének kereszttermékét fogja elvégezni minden egyező dokumentumhoz, mielőtt bármilyen szűrőt alkalmaz. A WHERE záradék ezután alkalmazza a szűrő predikátumot minden egyes <c, t, n, s> rekordra.

Ha például egy egyező dokumentum 10 elemet tartalmaz a három tömb mindegyikében, az 1 x 10 x 10 x 10 (azaz 1000) skálára bővül. Az al lekérdezések használata segíthet 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 al 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)

RU-díj: 22.17 kérelemegység

Tegyük fel, hogy a címkék tömbjének csak egy eleme felel meg a szűrőnek, és hogy a tápanyag- és a kiszolgálótömbhöz egyaránt öt elem tartozik. A JOIN kifejezések 1 x 1 x 5 x 5 = 25 elemre bővülnek, 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 TOP lekért dokumentumszám 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ég é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ú kiépített kérelemegységtel (több mint 30 000) vagy nagy mennyiségű tárolt adatmal rendelkezik (körülbelül 100 GB-nál több), akkor valószínűleg elég nagy tárolóval rendelkezik ahhoz, hogy jelentős mértékben csökkenjenek a lekérdezésIR-díjak.

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

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

A partíciókulcsot tartalmazó szűrővel rendelkező IN lekérdezések csak a megfelelő fizikai partíció(ka)t ellenőrzik, és nem lesznek "kirakva":

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ővel rendelkeznek a partíciókulcson, vagy amelyek nem rendelkeznek szűrővel a partíciókulcson, "ki kell kapcsolni" és ellenőrizniük kell az összes fizikai partíció indexét az eredményekért:

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ágon 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ég szűrőt utoljára az összetett indexben kell definiálni. További információ az összetett indexekről.

Íme néhány példa az összetett indexekkel 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

A releváns összetett index a következő:

{  
        "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és 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 nagyobb késéssel rendelkeznek, 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 Adatok globális elosztása az Azure Cosmos DB-ben egyszerű, így az adatok közelebb kerülhetnek az alkalmazáshoz.

Kiosztott átviteli sebesség növelése

Az Azure Cosmos DB-ben a kiosztott átviteli sebesség a kérelemegységekben (RU-kban) van mérve. 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-hibát ad vissza. A NoSQL SDK-k aktuális API-ja rövid várakozás után automatikusan újrapróbálkozza ezt a lekérdezést. 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. Az Azure Portal Metrikák paneljén megfigyelheti a szabályozott kérelmek teljes számát.

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ó adatokat azonban a rendszer sorozatosan lekéri a lekérdezéssel kapcsolatban. Így ha a MaxConcurrency értéket a partíciók számára állítja be, akkor a legjobb esélye van a leghasznosabb lekérdezés elérésére, feltéve, hogy az összes többi 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ását magas értékre állíthatja. A rendszer a minimális értéket (a partíciók számát, a felhasználó által megadott bemenetet) választja ki a párhuzamosság maximális fokaként.

MaxBufferedItemCount számának 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őzetes beolvasás segít a lekérdezések általános 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ának (vagy magasabb számának) állítja be, akkor a lekérdezés az előre beolvasás előnyeit élvezheti a legjobban. 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

A lekérdezésenkénti kérelemegységek méréséről, a lekérdezések hangolásához szükséges végrehajtási statisztikák lekéréséről és egyebekről az alábbi cikkekben olvashat bővebben: