Lekérdezési teljesítménytippek az Azure Cosmos DB SDK-khoz

Alkalmazandó: ✅ NoSQL

Az Azure Cosmos DB egy gyors, rugalmas elosztott adatbázis, amely zökkenőmentesen skálázható, garantált késéssel és átviteli sebességgel. Nem kell jelentős architektúramódosításokat végeznie, és nem kell összetett kódot írnia az adatbázis Azure Cosmos DB-vel való skálázásához. A skálázás fel és le ugyanolyan egyszerű, mint egyetlen API-hívás. További információkért tekintse meg a tároló átviteli sebességének kiépítését vagy az adatbázis átviteli sebességének kiépítését.

Lekérdezésterv-hívások csökkentése

Egyetlen partíciós lekérdezések optimalizálása optimista közvetlen végrehajtással

Az Azure Cosmos DB NoSQL optimalizálása optimista közvetlen végrehajtás (ODE) néven érhető el, amely javíthatja bizonyos NoSQL-lekérdezések hatékonyságát. Pontosabban azok a lekérdezések, amelyek nem igényelnek elosztást, tartalmazzák azokat, amelyek egyetlen fizikai partíción végrehajthatók, vagy olyan válaszokkal rendelkeznek, amelyek nem igényelnek lapozást. Az olyan lekérdezések, amelyek nem igényelnek elosztást, magabiztosan kihagyhatnak bizonyos folyamatokat, például az ügyféloldali lekérdezésterv létrehozását és a lekérdezés újraírását, ami csökkenti a lekérdezési késést és a kérelemegységek (RU) költségeit. Ha magát a kérésben vagy lekérdezésben adja meg a partíciókulcsot (vagy csak egy fizikai partícióval rendelkezik), és a lekérdezés eredményei nem igényelnek lapozást, akkor az ODE javíthatja a lekérdezéseket.

Megjegyzés:

Az ODE, amely jobb teljesítményt nyújt az olyan lekérdezések esetében, amelyek nem igényelnek elosztást, nem szabad összekeverni a közvetlen móddal, amely az alkalmazás háttérreplikákhoz való csatlakoztatásának elérési útja.

Az ODE már elérhető a .NET SDK 3.38.0-s és újabb verziójában. Amikor végrehajt egy lekérdezést, és megad egy partíciókulcsot magában a kérésben vagy lekérdezésben, vagy az adatbázis csak egy fizikai partícióval rendelkezik, a lekérdezés végrehajtása kihasználhatja az ODE előnyeit. Az ODE engedélyezéséhez állítsa EnableOptimisticDirectExecution igaz értékre a QueryRequestOptionsban.

A GROUP BY, ORDER BY, DISTINCT és aggregációs függvényekkel (például összeg, középérték, perc és max) rendelkező egypartíciós lekérdezések jelentősen kihasználhatják az ODE használatát. Azokban az esetekben azonban, amikor a lekérdezés több partíciót céloz meg, vagy lapozást igényel, a lekérdezési válasz és az RU költsége magasabb lehet, mint az ODE használata nélkül. Ezért az ODE használatakor a következőt kell használnia:

Adja meg a partíciókulcsot magában a hívásban vagy lekérdezésben.
Győződjön meg arról, hogy az adatméret nem nőtt-e meg, és nem okozta-e a partíció felosztását.
Győződjön meg arról, hogy a lekérdezés eredményei nem igényelnek lapozást az ODE teljes körű kihasználásához.

Íme néhány példa az ODE előnyeit kihasználó egyszerű egypartíciós lekérdezésekre:

- SELECT * FROM r
- SELECT * FROM r WHERE r.pk == "value"
- SELECT * FROM r WHERE r.id > 5
- SELECT r.id FROM r JOIN id IN r.id
- SELECT TOP 5 r.id FROM r ORDER BY r.id
- SELECT * FROM r WHERE r.id > 5 OFFSET 5 LIMIT 3

Előfordulhat, hogy az önálló partíciólekérdezések továbbra is elosztást igényelnek, ha az adatelemek száma idővel nő, és az Azure Cosmos DB-adatbázis felosztja a partíciót. Ilyen lekérdezések például a következők lehetnek:

- SELECT Count(r.id) AS count_a FROM r
- SELECT DISTINCT r.id FROM r
- SELECT Max(r.a) as min_a FROM r
- SELECT Avg(r.a) as min_a FROM r
- SELECT Sum(r.a) as sum_a FROM r WHERE r.a > 0

Egyes összetett lekérdezések mindig igényelhetnek elosztást, még akkor is, ha egyetlen partíciót céloznak meg. Ilyen lekérdezések például a következők:

- SELECT Sum(id) as sum_id FROM r JOIN id IN r.id
- SELECT DISTINCT r.id FROM r GROUP BY r.id
- SELECT DISTINCT r.id, Sum(r.id) as sum_a FROM r GROUP BY r.id
- SELECT Count(1) FROM (SELECT DISTINCT r.id FROM root r)
- SELECT Avg(1) AS avg FROM root r

Fontos megjegyezni, hogy előfordulhat, hogy az ODE nem mindig kéri le a lekérdezési tervet, ezért nem tudja letiltani vagy kikapcsolni a nem támogatott lekérdezéseket. Például a partíció felosztása után az ilyen lekérdezések már nem jogosultak az ODE használatára, ezért nem fognak futni, mert az ügyféloldali lekérdezésterv kiértékelése letiltja ezeket. A kompatibilitás/szolgáltatás folytonosságának biztosítása érdekében kritikus fontosságú annak biztosítása, hogy csak az ODE nélküli forgatókönyvekben teljes mértékben támogatott lekérdezéseket (azaz az általános többpartíciós esetben a megfelelő eredményt hajtják végre és állítják elő) használják az ODE-t.

Megjegyzés:

Az ODE használata új típusú folytatási jogkivonat létrehozásához vezethet. Az ilyen jogkivonatokat a régebbi SDK-k nem ismerik fel terv szerint, és ez hibásan formázott folytatási jogkivonat-kivételt eredményezhet. Ha olyan forgatókönyve van, amelyben az újabb SDK-kból létrehozott jogkivonatokat egy régebbi SDK használja, javasoljuk a frissítés kétlépéses megközelítését:

Frissítsen az új SDK-ra, és tiltsa le az ODE-t egy üzembe helyezés részeként. Várjon, amíg az összes csomópont frissül.
Az ODE letiltásához állítsa EnableOptimisticDirectExecution hamis értékre a QueryRequestOptionsban.
Engedélyezze az ODE-t az összes csomópont második üzembe helyezésének részeként.

Helyi lekérdezésterv létrehozása

Az SQL SDK tartalmaz egy natív ServiceInterop.dll a lekérdezések helyi elemzéséhez és optimalizálásához. ServiceInterop.dll csak a Windows x64 platformon támogatott. Az alábbi alkalmazások alapértelmezés szerint 32 bites gazdagépfeldolgozást használnak. Ha a gazdagépfeldolgozást 64 bitesre szeretné módosítani, kövesse az alábbi lépéseket az alkalmazás típusától függően:

Végrehajtható alkalmazások esetén módosíthatja a host-feldolgozást úgy, hogy a platformcélt x64 értékre állítja a Projekt tulajdonságai ablakban, a Build lapon.
VSTest-alapú tesztprojektek esetén módosíthatja a gazdagép feldolgozását úgy, hogy a Visual Studio Test menüjében kiválasztja a >>Alapértelmezett processzorarchitektúra lehetőséget X64 értékre.
A helyileg telepített ASP.NET webalkalmazások esetében módosíthatja a gazdagép feldolgozását, ha az IIS Express 64 bites verziójának használatát webhelyekhez és projektekhez választja az Eszközök>Beállítások>Projektek és megoldások>Webprojektek alatt.
Az Azure-ban üzembe helyezett ASP.NET webalkalmazások esetében a 64 bites platform kiválasztásával módosíthatja a gazdagépek feldolgozását az Azure Portal alkalmazásbeállításaiban.

Megjegyzés:

Alapértelmezés szerint az új Visual Studio-projektek bármilyen CPU-ra vannak állítva. Javasoljuk, hogy állítsa a projektet x64-re, hogy ne váltson x86-ra. A Bármely CPU-ra beállított projekt könnyen átválthat x86-ra, ha csak x86-függőséget ad hozzá.

ServiceInterop.dll abban a mappában kell lennie, amelyből az SDK DLL-t végrehajtják. Ez csak akkor lehet aggodalomra ad okot, ha manuálisan másolja a DLL-eket, vagy egyéni build-/üzembehelyezési rendszerekkel rendelkezik.

Egyetlen partíciós lekérdezések használata

V3 .NET SDK
V2 .NET SDK

A partíciókulcsot megcélzó lekérdezések esetében a PartitionKey tulajdonságot QueryRequestOptions úgy kell beállítani, hogy ne tartalmazzon összesítéseket (beleértve a Distinct, a DCount vagy a Group By tulajdonságot). Ebben a példában a partíciókulcs mezője /state az értékre Washingtonlesz szűrve.

using (FeedIterator<MyItem> feedIterator = container.GetItemQueryIterator<MyItem>(
    "SELECT * FROM c WHERE c.city = 'Seattle' AND c.state = 'Washington'"
{
    // ...
}

Igény szerint a partíciókulcsot a kérésbeállítások objektum részeként is megadhatja.

using (FeedIterator<MyItem> feedIterator = container.GetItemQueryIterator<MyItem>(
    "SELECT * FROM c WHERE c.city = 'Seattle'",
    requestOptions: new QueryRequestOptions() { PartitionKey = new PartitionKey("Washington")}))
{
    // ...
}

Fontos

A nem Windows operációs rendszert futtató ügyfeleken, például Linuxon és macOS-en a partíciókulcsot mindig meg kell adni a kérésbeállítások objektumban.

Partíciókulcsot megcélzó lekérdezések esetén a PartitionKey tulajdonság FeedOptions beállításakor és nem tartalmaz összesítéseket (beleértve a Distinct, DCount vagy Group By tulajdonságot):

IDocumentQuery<dynamic> query = client.CreateDocumentQuery(
    UriFactory.CreateDocumentCollectionUri(DatabaseName, CollectionName), 
    "SELECT * FROM c WHERE c.city = 'Seattle'", 
    new FeedOptions 
    { 
        PartitionKey = new PartitionKey("Washington")
    }).AsDocumentQuery();

Megjegyzés:

A partíciók közötti lekérdezésekhez az SDK-nak meg kell látogatnia az összes meglévő partíciót az eredmények kereséséhez. Minél több fizikai partícióval rendelkezik a tároló, annál lassabb lehet.

Ne helyezze újra feleslegesen az iterátort

Ha az aktuális összetevő az összes lekérdezési eredményt felhasználja, nem kell újra létrehoznia az iterátort minden oldal folytatásával. Előnyben részesítsük a lekérdezés teljes kiürítését, kivéve, ha a lapozást egy másik hívó komponens irányítja.

V3 .NET SDK
V2 .NET SDK

using (FeedIterator<MyItem> feedIterator = container.GetItemQueryIterator<MyItem>(
    "SELECT * FROM c WHERE c.city = 'Seattle'",
    requestOptions: new QueryRequestOptions() { PartitionKey = new PartitionKey("Washington")}))
{
    while (feedIterator.HasMoreResults) 
    {
        foreach(MyItem document in await feedIterator.ReadNextAsync())
        {
            // Iterate through documents
        }
    }
}

IDocumentQuery<dynamic> query = client.CreateDocumentQuery(
    UriFactory.CreateDocumentCollectionUri(DatabaseName, CollectionName), 
    "SELECT * FROM c WHERE c.city = 'Seattle'", 
    new FeedOptions 
    { 
        PartitionKey = new PartitionKey("Washington")
    }).AsDocumentQuery();
while (query.HasMoreResults) 
{
    foreach(Document document in await queryable.ExecuteNextAsync())
    {
        // Iterate through documents
    }
}

Lekérdezések esetén hangolja be a MaxConcurrency tulajdonságot QueryRequestOptions az alkalmazás legjobb konfigurációinak azonosításához, különösen akkor, ha partíciók közötti lekérdezéseket hajt végre (a partíciókulcs értékének szűrése nélkül). MaxConcurrency a párhuzamos feladatok maximális számát szabályozza, azaz a párhuzamosan látogatható partíciók maximális számát. Az érték -1 értékre állítása lehetővé teszi, hogy az SDK döntse el az optimális egyidejűséget.

using (FeedIterator<MyItem> feedIterator = container.GetItemQueryIterator<MyItem>(
    "SELECT * FROM c WHERE c.city = 'Seattle'",
    requestOptions: new QueryRequestOptions() { 
        PartitionKey = new PartitionKey("Washington"),
        MaxConcurrency = -1 }))
{
    // ...
}

Lekérdezések esetén állítsa be a MaxDegreeOfParallelism tulajdonságot FeedOptions az alkalmazás legjobb konfigurációinak azonosításához, különösen akkor, ha partíciók közötti lekérdezéseket hajt végre (a partíciókulcs értékének szűrése nélkül). MaxDegreeOfParallelism a párhuzamos feladatok maximális számát szabályozza, azaz a párhuzamosan látogatható partíciók maximális számát. Az érték -1 értékre állítása lehetővé teszi, hogy az SDK döntse el az optimális egyidejűséget.

IDocumentQuery<dynamic> query = client.CreateDocumentQuery(
    UriFactory.CreateDocumentCollectionUri(DatabaseName, CollectionName), 
    "SELECT * FROM c WHERE c.city = 'Seattle'", 
    new FeedOptions 
    { 
        MaxDegreeOfParallelism = -1, 
        EnableCrossPartitionQuery = true 
    }).AsDocumentQuery();

Tegyük fel, hogy:

D = A párhuzamos feladatok alapértelmezett maximális száma (= az ügyfélszámítógép processzorainak teljes száma)
P = Felhasználó által megadott párhuzamos feladatok maximális száma
N = A lekérdezés megválaszolásához meglátogatandó partíciók száma

Az alábbiakban a párhuzamos lekérdezések viselkedésének következményei szerepelnek a P különböző értékeire vonatkozóan.

(P == 0) => Soros mód
(P == 1) => Egy tevékenység maximális száma
(P > 1) => Min (P, N) párhuzamos feladatok
(P < 1) => Minimum (N, D) párhuzamos feladatok

Az oldal méretének finomhangolása

SQL-lekérdezés kiadásakor a rendszer szegmentált módon adja vissza az eredményeket, ha az eredményhalmaz túl nagy.

Megjegyzés:

A MaxItemCount tulajdonságot nem szabad csak lapozáshoz használni. Fő célja a lekérdezések teljesítményének javítása az egyetlen oldalon visszaadott elemek maximális számának csökkentésével.

V3 .NET SDK
V2 .NET SDK

Az oldalméretet az elérhető Azure Cosmos DB SDK-k használatával is beállíthatja. A MaxItemCount tulajdonság lehetővé QueryRequestOptions teszi az enumerálási műveletben visszaadandó elemek maximális számának beállítását. Ha MaxItemCount-1 értékre van állítva, az SDK a dokumentum méretétől függően automatikusan megkeresi az optimális értéket. Például:

using (FeedIterator<MyItem> feedIterator = container.GetItemQueryIterator<MyItem>(
    "SELECT * FROM c WHERE c.city = 'Seattle'",
    requestOptions: new QueryRequestOptions() { 
        PartitionKey = new PartitionKey("Washington"),
        MaxItemCount = 1000}))
{
    // ...
}

Az oldalméretet az elérhető Azure Cosmos DB SDK-k használatával is beállíthatja. A MaxItemCount tulajdonság lehetővé FeedOptions teszi az enumerálási műveletben visszaadandó elemek maximális számának beállítását. Ha MaxItemCount-1 értékre van állítva, az SDK a dokumentum méretétől függően automatikusan megkeresi az optimális értéket. Például:

IQueryable<dynamic> authorResults = client.CreateDocumentQuery(
    UriFactory.CreateDocumentCollectionUri(DatabaseName, CollectionName), 
    "SELECT p.Author FROM Pages p WHERE p.Title = 'About Seattle'", 
    new FeedOptions { MaxItemCount = 1000 });

Lekérdezés végrehajtásakor az eredményül kapott adatok egy TCP-csomagban lesznek elküldve. Ha túl alacsony értéket MaxItemCountad meg, akkor a TCP-csomagon belüli adatküldéshez szükséges utazások száma magas, ami hatással van a teljesítményre. Ha tehát nem biztos abban, hogy milyen értéket kell beállítania a MaxItemCount tulajdonsághoz, a legjobb, ha -1 értékre állítja, és hagyja, hogy az SDK válassza ki az alapértelmezett értéket.

A puffer méretének finomhangolása

V3 .NET SDK
V2 .NET SDK

A párhuzamos lekérdezés úgy lett kialakítva, hogy előre leküldje az eredményeket, miközben az ügyfél feldolgozza az aktuális eredményköteget. Ez az előkezelés segít a lekérdezések általános késésének javításában. A MaxBufferedItemCount tulajdonság korlátozza QueryRequestOptions az előre megadott eredmények számát. Állítsa be MaxBufferedItemCount a visszaadott eredmények várt számát (vagy egy magasabb számot), hogy a lekérdezés megkapja az előkezelésből származó maximális előnyt. Ha ezt az értéket -1 értékre állítja, a rendszer automatikusan meghatározza a pufferelendő elemek számát.

using (FeedIterator<MyItem> feedIterator = container.GetItemQueryIterator<MyItem>(
    "SELECT * FROM c WHERE c.city = 'Seattle'",
    requestOptions: new QueryRequestOptions() { 
        PartitionKey = new PartitionKey("Washington"),
        MaxBufferedItemCount = -1}))
{
    // ...
}

A párhuzamos lekérdezés úgy lett kialakítva, hogy előre leküldje az eredményeket, miközben az ügyfél feldolgozza az aktuális eredményköteget. Ez az előkezelés segít a lekérdezések általános késésének javításában. A MaxBufferedItemCount tulajdonság korlátozza FeedOptions az előre megadott eredmények számát. Állítsa be MaxBufferedItemCount a visszaadott eredmények várt számát (vagy egy magasabb számot), hogy a lekérdezés megkapja az előkezelésből származó maximális előnyt. Ha ezt az értéket -1 értékre állítja, a rendszer automatikusan meghatározza a pufferelendő elemek számát.

IQueryable<dynamic> authorResults = client.CreateDocumentQuery(
    UriFactory.CreateDocumentCollectionUri(DatabaseName, CollectionName), 
    "SELECT p.Author FROM Pages p WHERE p.Title = 'About Seattle'", 
    new FeedOptions { MaxBufferedItemCount = -1 });

Az előkezelés ugyanúgy működik, függetlenül a párhuzamosság mértékétől, és az összes partíció adatainak egyetlen puffere van.

Következő lépések

További információ a teljesítményről a .NET SDK használatával:

Lekérdezésterv-hívások csökkentése

Egy lekérdezés végrehajtásához létre kell készíteni egy lekérdezési tervet. Az Azure Cosmos DB Gateway felé irányuló hálózati kérések növelik a lekérdezési művelet késését.

Lekérdezésterv gyorsítótárazásának használata

Az egy partícióra korlátozódó lekérdezési terv kliensoldalon van gyorsítótárazva. Így nem szükséges hívást kezdeményezni az átjáróhoz, hogy lekérje a lekérdezési tervet az első hívás után. A gyorsítótárazott lekérdezési terv kulcsa az SQL-lekérdezési karakterlánc. Meg kell győződnie arról, hogy a lekérdezés parametrizált. Ha nem, akkor a lekérdezési terv gyorsítótárának keresése gyakran eredményez gyorsítótár-kihagyást, mivel a lekérdezési karakterlánc valószínűleg nem lesz azonos minden hívás során. A lekérdezéstervek gyorsítótárazása alapértelmezés szerint engedélyezve van a Java SDK 4.20.0-s és újabb verzióihoz, valamint a Spring Data Azure Cosmos DB SDK 3.13.0-s vagy újabb verziójához.

Parametrizált egypartíciós lekérdezések használata

Az olyan parametrizált lekérdezések esetében, amelyek a setPartitionKeyCosmosQueryRequestOptions paraméterrel rendelkező partíciókulcsra vannak hatókörítve, és nem tartalmaznak összesítéseket (beleértve a Distinct, DCount vagy Group By függvényt), a lekérdezési terv elkerülhető:

CosmosQueryRequestOptions options = new CosmosQueryRequestOptions();
options.setPartitionKey(new PartitionKey("Washington"));

ArrayList<SqlParameter> paramList = new ArrayList<SqlParameter>();
paramList.add(new SqlParameter("@city", "Seattle"));
SqlQuerySpec querySpec = new SqlQuerySpec(
        "SELECT * FROM c WHERE c.city = @city",
        paramList);

//  Sync API
CosmosPagedIterable<MyItem> filteredItems = 
    container.queryItems(querySpec, options, MyItem.class);

//  Async API
CosmosPagedFlux<MyItem> filteredItems = 
    asyncContainer.queryItems(querySpec, options, MyItem.class);

Megjegyzés:

A párhuzamosság fokának finomhangolása

A párhuzamos lekérdezések több partíció párhuzamos lekérdezésével működnek. Az egyes particionált tárolókból származó adatok azonban a lekérdezés szempontjából sorosan lesznek beolvasva. Ezért a setMaxDegreeOfParallelismállítsa be a partíciók számát. Ha nem ismeri a partíciók számát, magas számot állíthat setMaxDegreeOfParallelism be, és a rendszer a minimálisat (a partíciók számát, a felhasználó által megadott bemenetet) választja a párhuzamosság maximális fokaként. Az érték -1 értékre állítása lehetővé teszi, hogy az SDK döntse el az optimális egyidejűséget.

Fontos megjegyezni, hogy a párhuzamos lekérdezések akkor biztosítják a legjobb előnyöket, ha az adatok egyenletesen oszlanak el az összes partíció között a lekérdezés szempontjából. Ha a particionált tárolót úgy particionálják, hogy a lekérdezés által visszaadott adatok teljes vagy nagy része néhány partícióra koncentrálódik (legrosszabb esetben egy partícióra), akkor a lekérdezés teljesítménye csökkenne.

CosmosQueryRequestOptions options = new CosmosQueryRequestOptions();
options.setPartitionKey(new PartitionKey("Washington"));
options.setMaxDegreeOfParallelism(-1);

// Define the query

//  Sync API
CosmosPagedIterable<MyItem> filteredItems = 
    container.queryItems(querySpec, options, MyItem.class);

//  Async API
CosmosPagedFlux<MyItem> filteredItems = 
    asyncContainer.queryItems(querySpec, options, MyItem.class);

Tegyük fel, hogy:

D = A párhuzamos feladatok alapértelmezett maximális száma (= az ügyfélszámítógép processzorainak teljes száma)
P = Felhasználó által megadott párhuzamos feladatok maximális száma
N = A lekérdezés megválaszolásához meglátogatandó partíciók száma

A párhuzamos lekérdezések viselkedésének következményei a P különböző értékeire nézve az alábbiak:

(P == 0) => Soros mód
(P == 1) => Egy tevékenység maximális száma
(P > 1) => Min (P, N) párhuzamos feladatok
(P == -1) => Min (N, D) párhuzamos feladatok

Az oldal méretének finomhangolása

SQL-lekérdezés kiadásakor a rendszer szegmentált módon adja vissza az eredményeket, ha az eredményhalmaz túl nagy. Alapértelmezés szerint a rendszer 100 elemből vagy 4 MB-ból álló adattömbökben adja vissza az eredményeket, attól függően, hogy melyik korlátot éri el először a rendszer. Az oldalméret növelése csökkenti a szükséges körutazások számát, és növeli a 100-nál több elemet visszaküldött lekérdezések teljesítményét. Ha nem biztos abban, hogy milyen értéket kell beállítania, az 1000 általában jó választás. A memóriahasználat az oldalméret növekedésével nő, ezért ha a számítási feladat memóriaérzékeny, fontolja meg az alacsonyabb értéket.

A pageSize paramétert a sync API-ban és az iterableByPage() async API-ban byPage() használhatja az oldalméret meghatározásához.

//  Sync API
Iterable<FeedResponse<MyItem>> filteredItemsAsPages =
    container.queryItems(querySpec, options, MyItem.class).iterableByPage(continuationToken,pageSize);

for (FeedResponse<MyItem> page : filteredItemsAsPages) {
    for (MyItem item : page.getResults()) {
        //...
    }
}

//  Async API
Flux<FeedResponse<MyItem>> filteredItemsAsPages =
    asyncContainer.queryItems(querySpec, options, MyItem.class).byPage(continuationToken,pageSize);

filteredItemsAsPages.map(page -> {
    for (MyItem item : page.getResults()) {
        //...
    }
}).subscribe();

A puffer méretének finomhangolása

A párhuzamos lekérdezés úgy lett kialakítva, hogy előre leküldje az eredményeket, miközben az ügyfél feldolgozza az aktuális eredményköteget. Az előkezelés segít a lekérdezések késésének általános javításában. setMaxBufferedItemCount az CosmosQueryRequestOptions előre megadott eredmények számát korlátozza. Az előtöltés maximalizálásához állítsa be a maxBufferedItemCount egy nagyobb számra, mint a pageSize (MEGJEGYZÉS: Ez magas memóriahasználatot is okozhat). Az előtöltés minimalizálásához állítsa az maxBufferedItemCount-t egyenlővé a pageSize-vel. Ha ezt az értéket 0 értékre állítja, a rendszer automatikusan meghatározza a pufferelendő elemek számát.

CosmosQueryRequestOptions options = new CosmosQueryRequestOptions();
options.setPartitionKey(new PartitionKey("Washington"));
options.setMaxBufferedItemCount(-1);

// Define the query

//  Sync API
CosmosPagedIterable<MyItem> filteredItems = 
    container.queryItems(querySpec, options, MyItem.class);

//  Async API
CosmosPagedFlux<MyItem> filteredItems = 
    asyncContainer.queryItems(querySpec, options, MyItem.class);

Az előkezelés ugyanúgy működik, függetlenül a párhuzamosság mértékétől, és az összes partíció adatainak egyetlen puffere van.

Következő lépések

További információ a Teljesítményről a Java SDK használatával:

Lekérdezésterv-hívások csökkentése

Egy lekérdezés végrehajtásához létre kell készíteni egy lekérdezési tervet. Az Azure Cosmos DB Gateway felé irányuló hálózati kérések növelik a lekérdezési művelet késését. Lehetőség van a kérés eltávolítására és az egyetlen partíciós lekérdezési művelet késésének csökkentésére. Egyetlen partíciós lekérdezés esetén adja meg az elem partíciókulcs-értékét, és adja meg partition_key argumentumként:

items = container.query_items(
        query="SELECT * FROM r where r.city = 'Seattle'",
        partition_key="Washington"
    )

Az oldal méretének finomhangolása

SQL-lekérdezés kiadásakor a rendszer szegmentált módon adja vissza az eredményeket, ha az eredményhalmaz túl nagy. A max_item_count lehetővé teszi az enumerálási műveletben visszaadandó elemek maximális számának beállítását.

items = container.query_items(
        query="SELECT * FROM r where r.city = 'Seattle'",
        partition_key="Washington",
        max_item_count=1000
    )

Következő lépések

További információ a Python SDK for API for NoSQL használatáról:

Lekérdezésterv-hívások csökkentése

Egy lekérdezés végrehajtásához létre kell készíteni egy lekérdezési tervet. Az Azure Cosmos DB Gateway felé irányuló hálózati kérések növelik a lekérdezési művelet késését. Lehetőség van a kérés eltávolítására és az egyetlen partíciós lekérdezési művelet késésének csökkentésére. Egyetlen partíciós lekérdezések esetén a lekérdezések egyetlen partícióra történő hatókörkezelése kétféleképpen valósítható meg.

Paraméteres lekérdezési kifejezés használata és partíciókulcs megadása a lekérdezési utasításban. A lekérdezés programozottan van összeállítva a következőre SELECT * FROM todo t WHERE t.partitionKey = 'Bikes, Touring Bikes'.

// find all items with same categoryId (partitionKey)
const querySpec = {
    query: "select * from products p where p.categoryId=@categoryId",
    parameters: [
        {
            name: "@categoryId",
            value: "Bikes, Touring Bikes"
        }
    ]
};

// Get items 
const { resources } = await container.items.query(querySpec).fetchAll();

for (const item of resources) {
    console.log(`${item.id}: ${item.name}, ${item.sku}`);
}

Vagy adja meg a partitionKey értéket FeedOptions, és adja meg argumentumként:

const querySpec = {
    query: "select * from products p"
};

const { resources } = await container.items.query(querySpec, { partitionKey: "Bikes, Touring Bikes" }).fetchAll();

for (const item of resources) {
    console.log(`${item.id}: ${item.name}, ${item.sku}`);
}

Az oldal méretének finomhangolása

SQL-lekérdezés kiadásakor a rendszer szegmentált módon adja vissza az eredményeket, ha az eredményhalmaz túl nagy. A maxItemCount lehetővé teszi az enumerálási műveletben visszaadandó elemek maximális számának beállítását.

const querySpec = {
    query: "select * from products p where p.categoryId=@categoryId",
    parameters: [
        {
            name: "@categoryId",
            value: items[2].categoryId
        }
    ]
};

const { resources } = await container.items.query(querySpec, { maxItemCount: 1000 }).fetchAll();

for (const item of resources) {
    console.log(`${item.id}: ${item.name}, ${item.sku}`);
}

Továbbfejlesztett lekérdezésvezérlő

A Cosmos DB JS SDK 4.3.0-s és újabb verziójához bevezették a jelölőt, enableQueryControl amely nagyobb ellenőrzést biztosít a lekérdezések végrehajtása felett, és nagyobb rugalmasságot biztosít a kérelemegység-használat kezelésében.

Alapértelmezés szerint a enableQueryControl értéke false, és az SDK garantálja, hogy minden fetchNext hívás maxItemCount számú eredményt ad vissza, feltéve, hogy ennyi eredmény létezik a háttérrendszerben. A garantált eredményszám elérése érdekében azonban az SDK több alkalommal is lekérdezheti a háttérpartíciókat egyetlen fetchNext iterációban. Ez néha kiszámíthatatlan késéshez vezethet, és a ru leürülhet felhasználói vezérlés nélkül, különösen akkor, ha az eredmények a partíciók között vannak szétszórva.

Ha enableQueryControl be van állítva true, minden egyes fetchNext hívás lekérdezi akár a maxDegreeOfParallelism fizikai partíciókat. Ha nem található találat, vagy az eredmények még nem állnak készen a kézbesítésre, az SDK üres oldalakat ad vissza ahelyett, hogy folytatná a keresést a háttérben lévő összes partícióban. Így a felhasználók jobban szabályozhatják a lekérdezések végrehajtását kiszámítható késéssel és részletes RU-használati adatokkal.

const options = {
  enableQueryControl: true, // Flag to enable new query pipeline.
  maxItemCount: 100,
  maxDegreeOfParallelism: 6
};

const querySpec = {
    query: "select * from products p where p.categoryId=@categoryId",
    parameters: [
        {
            name: "@categoryId",
            value: items[2].categoryId
        }
    ]
};
const queryIterator = container.items.query(querySpec, options);
// use this iterator to fetch results.

Következő lépések

További információ a Node.js SDK for API for NoSQL használatáról:

Visszacsatolás

Hasznos volt ez az oldal?

Last updated on 2025-12-19

Megosztás:

Lekérdezési teljesítménytippek az Azure Cosmos DB SDK-khoz

Lekérdezésterv-hívások csökkentése

Egyetlen partíciós lekérdezések optimalizálása optimista közvetlen végrehajtással

Helyi lekérdezésterv létrehozása

Egyetlen partíciós lekérdezések használata

Ne helyezze újra feleslegesen az iterátort

A párhuzamosság fokának finomhangolása

Az oldal méretének finomhangolása

A puffer méretének finomhangolása

Következő lépések

Lekérdezésterv-hívások csökkentése

Lekérdezésterv gyorsítótárazásának használata

Parametrizált egypartíciós lekérdezések használata

A párhuzamosság fokának finomhangolása

Az oldal méretének finomhangolása

A puffer méretének finomhangolása

Következő lépések

Lekérdezésterv-hívások csökkentése

Az oldal méretének finomhangolása

Következő lépések

Lekérdezésterv-hívások csökkentése

Az oldal méretének finomhangolása

Továbbfejlesztett lekérdezésvezérlő

Következő lépések

Visszacsatolás

További források