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

A lekérdezési teljesítmény finomhangolása az Azure Cosmos DB-vel

  • Cikk

A KÖVETKEZŐRE VONATKOZIK: NoSQL

Az Azure Cosmos DB egy API-t biztosít a NoSQL-hez az adatok lekérdezéséhez séma vagy másodlagos indexek nélkül. Ez a cikk a következő információkat tartalmazza a fejlesztők számára:

  • Az Azure Cosmos DB SQL-lekérdezésvégrehajtásának működésének magas szintű részletei
  • Tippek és ajánlott eljárások a lekérdezési teljesítményhez
  • Példák az SQL-lekérdezések végrehajtási metrikáinak a lekérdezési teljesítmény hibakeresésére való felhasználására

Tudnivalók az SQL-lekérdezések végrehajtásáról

Az Azure Cosmos DB-ben az adatok tárolókban vannak tárolva, amelyek bármilyen tárolóméretre vagy átviteli sebességre növekedhetnek. Az Azure Cosmos DB zökkenőmentesen skálázza az adatokat a fedelek alatti fizikai partíciók között az adatnövekedés vagy a kiosztott átviteli sebesség növelése érdekében. SQL-lekérdezéseket bármely tárolóba kiadhat a REST API-val vagy a támogatott SQL SDK-k egyikével.

A particionálás rövid áttekintése: meghatároz egy olyan partíciókulcsot, mint a "város", amely meghatározza az adatok fizikai partíciók közötti felosztását. Az egyetlen partíciókulcshoz tartozó adatokat (például "city" == "Seattle") egy fizikai partíció tárolja, és egyetlen fizikai partíció több partíciókulcsból is tárolhat adatokat. Amikor egy partíció eléri a tárterületkorlátot, a szolgáltatás zökkenőmentesen felosztja a partíciót két új partícióra. Az adatok egyenletesen oszlanak el az új partíciók között, így egyetlen partíciókulcs összes adata együtt marad. Mivel a partíciók átmenetiek, az API-k egy partíciókulcs-tartomány absztrakcióját használják, amely a partíciókulcs-kivonatok tartományait jelöli.

Amikor lekérdezést ad ki az Azure Cosmos DB-nek, az SDK a következő logikai lépéseket hajtja végre:

  • Elemezze az SQL-lekérdezést a lekérdezés végrehajtási tervének meghatározásához.
  • Ha a lekérdezés tartalmaz egy szűrőt a partíciókulcshoz, például SELECT * FROM c WHERE c.city = "Seattle"egy partícióhoz van irányítva. Ha a lekérdezés nem rendelkezik szűrővel a partíciókulcson, akkor a rendszer az összes partícióban végrehajtja, és az egyes partíciók eredményei egyesített ügyféloldaliak.
  • A lekérdezést az ügyfélkonfiguráció alapján sorozatban vagy párhuzamosan hajtja végre az egyes partíciókon belül. Az egyes partíciókon belül a lekérdezés a lekérdezés összetettségétől, a konfigurált oldalmérettől és a gyűjtemény kiosztott átviteli sebességétől függően egy vagy több ciklikus utazást is elvégezhet. Minden végrehajtás a lekérdezések végrehajtásának és a lekérdezések végrehajtásának statisztikái által felhasznált kérelemegységek számát adja vissza.
  • Az SDK a partíciók lekérdezési eredményeinek összegzését végzi el. Ha például a lekérdezés egy ORDER BY függvényt tartalmaz a partíciók között, akkor az egyes partíciók eredményei egyesítve lesznek rendezve, hogy globálisan rendezett sorrendben adja vissza az eredményeket. Ha a lekérdezés egy aggregáció, például COUNT, az egyes partíciókból származó számokat összegzi a rendszer a teljes szám létrehozásához.

Az SDK-k különböző lehetőségeket biztosítanak a lekérdezések végrehajtásához. A .NET-ben például ezek a lehetőségek érhetők el az QueryRequestOptions osztályban. Az alábbi táblázat ezeket a beállításokat és a lekérdezések végrehajtási idejét ismerteti.

Lehetőség Leírás
EnableScanInQuery Csak akkor alkalmazható, ha a kért szűrőútvonal indexelése le van tiltva. Igaz értékre kell állítani, ha nem indexelt, és teljes vizsgálattal szeretne lekérdezéseket futtatni.
MaxItemCount A kiszolgálóra való oda-visszaútonként visszaadandó elemek maximális száma. Beállíthatja -1 értékre, hogy a kiszolgáló kezelje a visszaadni kívánt elemek számát.
MaxBufferedItemCount Az ügyféloldali pufferelhető elemek maximális száma a párhuzamos lekérdezés végrehajtása során. A pozitív tulajdonságérték a pufferelt elemek számát a beállított értékre korlátozza. 0-nál kisebb értékre állíthatja, hogy a rendszer automatikusan eldöntse a pufferelendő elemek számát.
MaxConcurrency Lekéri vagy beállítja az egyidejűleg futtatott műveletek számát az ügyféloldalon a párhuzamos lekérdezés végrehajtása során. A pozitív tulajdonság értéke az egyidejű műveletek számát a beállított értékre korlátozza. 0-nál kisebb értékre állíthatja, hogy a rendszer automatikusan eldöntse az egyidejűleg futtatandó műveletek számát.
PopulateIndexMetrics Lehetővé teszi az indexmetrikák gyűjtését annak megértéséhez, hogy a lekérdezési motor hogyan használta a meglévő indexeket, és hogyan használhatja a potenciális új indexeket. Ez a beállítás többletterheléssel jár, ezért csak lassú lekérdezések hibakeresése esetén szabad engedélyezni.
ResponseContinuationTokenLimitInKb Korlátozhatja a kiszolgáló által visszaadott folytatási jogkivonat maximális méretét. Előfordulhat, hogy ezt be kell állítania, ha az alkalmazásgazda korlátozza a válaszfejléc méretét, de növelheti a lekérdezés teljes időtartamát és kérelemegységeit.

Íme például egy lekérdezés a .NET SDK használatával /city particionált tárolón:

QueryDefinition query = new QueryDefinition("SELECT * FROM c WHERE c.city = 'Seattle'");
QueryRequestOptions options = new QueryRequestOptions()
{
    MaxItemCount = -1,
    MaxBufferedItemCount = -1,
    MaxConcurrency = -1,
    PopulateIndexMetrics = true
};
FeedIterator<dynamic> feedIterator = container.GetItemQueryIterator<dynamic>(query);

FeedResponse<dynamic> feedResponse = await feedIterator.ReadNextAsync();

Minden lekérdezés végrehajtása egy REST API-nak POST felel meg, amelynek fejlécei a lekérdezési kérelmek beállításaihoz és a törzsben lévő SQL-lekérdezéshez vannak beállítva. A REST API-kérés fejléceinek és beállításainak részleteiért lásd : Erőforrások lekérdezése a REST API használatával.

Ajánlott eljárások a lekérdezési teljesítményhez

Az alábbi tényezők általában a legnagyobb hatással vannak az Azure Cosmos DB lekérdezési teljesítményére. Ebben a cikkben részletesebben is bemutatjuk ezeket a tényezőket.

Szorzó Tipp.
Kiosztott átviteli sebesség Mérje meg a lekérdezésenkénti ru-t, és győződjön meg arról, hogy rendelkezik a lekérdezésekhez szükséges kiosztott átviteli sebességgel.
Particionálási és partíciókulcsok A szűrési záradékban a partíciókulcs-értékkel rendelkező lekérdezések előnyben részesítése az alacsony késés érdekében.
SDK és lekérdezési beállítások Kövesse az SDK ajánlott eljárásait, például a közvetlen kapcsolatot, és hangolja az ügyféloldali lekérdezés-végrehajtási beállításokat.
Hálózati késleltetés Az alkalmazás futtatása az Azure Cosmos DB-fiókkal azonos régióban, ahol csak lehetséges, a késés csökkentése érdekében.
Indexelési szabályzat Győződjön meg arról, hogy rendelkezik a lekérdezéshez szükséges indexelési útvonalokkal/szabályzatokkal.
Lekérdezésvégrehajtási metrikák A lekérdezés-végrehajtási metrikák elemzése a lekérdezések és adatalakzatok lehetséges átírásainak azonosításához.

Kiosztott átviteli sebesség

Az Azure Cosmos DB-ben olyan adattárolókat hozhat létre, amelyben a fenntartott átviteli sebesség kérelemegységekben (RU) kifejezve másodpercenként. Egy 1 KB-os dokumentum olvasása egy RU, és minden művelet (beleértve a lekérdezéseket is) az összetettsége alapján rögzített számú kérelemegységre van normalizálva. Ha például 1000 RU/s van kiépítve a tárolóhoz, és olyan lekérdezése van, amely SELECT * FROM c WHERE c.city = 'Seattle' 5 kérelemegységet használ fel, akkor végrehajthat (1000 RU/s) / (5 RU/query) = 200 ilyen lekérdezést másodpercenként.

Ha több mint 200 lekérdezést küld el másodpercenként (vagy más olyan műveletet, amely az összes kiosztott kérelemegységet telítette), a szolgáltatás sebességkorlátozást indít el a bejövő kérelmeknél. Az SDK-k automatikusan kezelik a sebességkorlátozást egy visszalépés/újrapróbálkozás végrehajtásával, ezért nagyobb késést tapasztalhat ezeknél a lekérdezéseknél. A kiosztott átviteli sebességnek a szükséges értékre történő növelése javítja a lekérdezés késését és átviteli sebességét.

A kérelemegységekről további információt a Kérelemegységek című témakörben talál.

Particionálási és partíciókulcsok

Az Azure Cosmos DB-vel az adatok olvasására vonatkozó alábbi forgatókönyvek a jellemzően leggyorsabb/leghatékonyabbtól a leglassabb/legkevésbé hatékonyig vannak rendezve.

  • GET egyetlen partíciókulcsra és elemazonosítóra, más néven pontolvasásra
  • Lekérdezés egy szűrési záradékkal egyetlen partíciókulcson
  • Lekérdezés egyenlőségi vagy tartományszűrő záradékkal bármely tulajdonságon
  • Lekérdezés szűrők nélkül

Az összes partíción végrehajtandó lekérdezések nagyobb késéssel rendelkeznek, és magasabb kérelemegységeket használhatnak fel. Mivel minden partíció automatikus indexelést alkalmaz az összes tulajdonsághoz, a lekérdezés ebben az esetben hatékonyan kiszolgálható az indexből. A partíciókra kiterjedő lekérdezéseket gyorsabbá teheti a párhuzamossági beállítások használatával.

További információ a particionálásról és a partíciókulcsokról: Particionálás az Azure Cosmos DB-ben.

SDK és lekérdezési beállítások

Tekintse meg a lekérdezési teljesítményre vonatkozó tippeket és a teljesítménytesztelést , hogy miként szerezheti be a legjobb ügyféloldali teljesítményt az Azure Cosmos DB-ből az SDK-k használatával.

Hálózati késleltetés

A globális disztribúció beállításáról és a legközelebbi régióhoz való csatlakozásról az Azure Cosmos DB globális disztribúciója című témakörben olvashat. A hálózati késés jelentős hatással van a lekérdezési teljesítményre, ha több fordulót kell elvégeznie, vagy nagy eredményhalmazt kell lekérnie a lekérdezésből.

Lekérdezésvégrehajtási metrikák használatával lekérheti a lekérdezések kiszolgálói végrehajtási idejét, így megkülönböztetheti a lekérdezés végrehajtásával töltött időt a hálózati átvitel során töltött időtől.

Indexelési szabályzat

Tekintse meg az indexelési szabályzat konfigurálását az elérési utak, a típusok és a módok indexeléséhez, valamint a lekérdezések végrehajtására gyakorolt hatásukról. Az Azure Cosmos DB alapértelmezés szerint automatikus indexelést alkalmaz az összes adatra, és tartományindexeket használ sztringekhez és számokhoz, ami hatékony az egyenlőségi lekérdezésekhez. A nagy teljesítményű beszúrási forgatókönyvek esetében fontolja meg az útvonalak kizárását az egyes beszúrási műveletek ru-költségeinek csökkentése érdekében.

Az indexmetrikák segítségével azonosíthatja, hogy mely indexeket használja az egyes lekérdezésekhez, és hogy vannak-e hiányzó indexek, amelyek javítanák a lekérdezés teljesítményét.

Lekérdezésvégrehajtási metrikák

A rendszer részletes metrikákat ad vissza a kérés diagnosztikája minden egyes lekérdezés-végrehajtáshoz. Ezek a metrikák azt írják le, hogy a lekérdezés végrehajtása során hol történik az idő, és hogyan lehet speciális hibaelhárítást végezni.

További információ a lekérdezési metrikák beszerzéséről.

Metrika Unit (Egység) Leírás
TotalTime ezredmásodperc Lekérdezések végrehajtásának teljes ideje
DocumentLoadTime ezredmásodperc Dokumentumok betöltésével töltött idő
DocumentWriteTime ezredmásodperc A kimeneti dokumentumok írásával és szerializálásával töltött idő
IndexLookupTime ezredmásodperc Fizikai indexrétegben töltött idő
QueryPreparationTime ezredmásodperc A lekérdezés előkészítésével töltött idő
RuntimeExecutionTime ezredmásodperc Lekérdezés futásideje teljes végrehajtási ideje
VMExecutionTime ezredmásodperc A lekérdezés végrehajtásával töltött idő a lekérdezés futtatókörnyezetében
OutputDocumentCount darabszám Kimeneti dokumentumok száma az eredményhalmazban
OutputDocumentSize darabszám A kimeneti dokumentumok teljes mérete bájtban
RetrievedDocumentCount darabszám Beolvasott dokumentumok teljes száma
RetrievedDocumentSize bájt A beolvasott dokumentumok teljes mérete bájtban
IndexHitRatio arány [0,1] A szűrővel egyeztetett dokumentumok számának és a betöltött dokumentumok számának aránya

Az ügyféloldali SDK-k belsőleg több lekérdezési kérést is intézhetnek a lekérdezés kiszolgálásához az egyes partíciókon belül. Az ügyfél partíciónként egynél több hívást indít, ha a teljes eredmény meghaladja a maximális elemszám-kérési beállítást, ha a lekérdezés meghaladja a partícióhoz kiosztott átviteli sebességet, ha a lekérdezés hasznos adatai elérik az oldalenkénti maximális méretet, vagy ha a lekérdezés eléri a rendszer által lefoglalt időtúllépési korlátot. Minden részleges lekérdezésvégrehajtás az adott lap lekérdezési metrikáit adja vissza.

Íme néhány minta lekérdezés, és a lekérdezés végrehajtásából visszaadott metrikák értelmezése:

Lekérdezés Mintametrika Leírás
SELECT TOP 100 * FROM c "RetrievedDocumentCount": 101 A lekért dokumentumok száma 100+1 a TOP záradéknak megfelelően. A lekérdezési időt többnyire beolvasják WriteOutputTime , és DocumentLoadTime mivel vizsgálatról van szó.
SELECT TOP 500 * FROM c "RetrievedDocumentCount": 501 A RetrievedDocumentCount mostantól magasabb (a TOP záradéknak megfelelő 500+1).
SELECT * FROM c WHERE c.N = 55 "IndexLookupTime": "00:00:00.0009500" A kulcskeresés körülbelül 0,9 ms-ot tölt az IndexLookupTime-ban, mivel ez egy indexkeresés./N/?
SELECT * FROM c WHERE c.N > 55 "IndexLookupTime": "00:00:00.0017700" Valamivel több időt (1,7 ms) töltött az IndexLookupTime egy tartományvizsgálat során, mert ez egy indexkeresés./N/?
SELECT TOP 500 c.N FROM c "IndexLookupTime": "00:00:00.0017700" Ugyanaz az idő, mint a DocumentLoadTime korábbi lekérdezések, de alacsonyabb DocumentWriteTime , mert csak egy tulajdonságot vetünk ki.
SELECT TOP 500 udf.toPercent(c.N) FROM c "RuntimeExecutionTime": "00:00:00.2136500" Körülbelül 213 ms-t költünk az UDF végrehajtására RuntimeExecutionTime az egyes értékeken c.N.
SELECT TOP 500 c.Name FROM c WHERE STARTSWITH(c.Name, 'Den') "IndexLookupTime": "00:00:00.0006400", "RuntimeExecutionTime": "00:00:00.0074100" Körülbelül 0,6 ms van töltve IndexLookupTime /Name/?. A lekérdezések végrehajtási idejének nagy része (~7 ms) a következőben: RuntimeExecutionTime.
SELECT TOP 500 c.Name FROM c WHERE STARTSWITH(LOWER(c.Name), 'den') "IndexLookupTime": "00:00:00", "RetrievedDocumentCount": 2491, "OutputDocumentCount": 500 A lekérdezés vizsgálatként történik, mert használja LOWER, és 2491 beolvasott dokumentumból 500 lesz visszaadva.

Következő lépések

  • A támogatott SQL-lekérdezési operátorokról és kulcsszavakról az SQL-lekérdezésben olvashat.
  • A kérelemegységekről további információt a kérelemegységek című témakörben talál.
  • Az indexelési szabályzatról további információt az indexelési szabályzatban talál