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

  • Cikk

A KÖVETKEZŐRE VONATKOZIK: 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 vertikális fel- és leskálázás 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

Egy lekérdezés végrehajtásához létre kell készíteni egy lekérdezési tervet. Ez általában egy hálózati kérést jelent az Azure Cosmos DB Gateway felé, amely növeli a lekérdezési művelet késését. Kétféleképpen távolíthatja el a kérést, és csökkentheti a lekérdezési művelet késését:

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, ezáltal csökkentve a lekérdezés késését és a kérelemegységek 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.

Feljegyzés

Az optimista közvetlen végrehajtás (ODE), amely jobb teljesítményt nyújt az olyan lekérdezésekhez, 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 útvonala.

Az ODE alapértelmezés szerint elérhető és engedélyezve van 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 letiltásához állítsa az EnableOptimisticDirectExecution értéket hamis é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 lapszámozá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álata esetén a következőket javasoljuk:

  • 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, és a partíció felosztását okozta.
  • 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 egyszerű egypartíciós lekérdezésekre, amelyek az ODE előnyeit élvezhetik:

- 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ós lekérdezések továbbra is elosztást igényelnek, ha az adatelemek száma idővel megnő, é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 blokkolja azokat. 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.

Feljegyzé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, hogy két lépésből áll a frissítés:

  • 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 az EnableOptimisticDirectExecution értéket hamisra 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 gazdagép feldolgozását úgy, hogy a platformcélt x64-re állítja a Projekt tulajdonságai ablakban, a Build lapon.

  • VSTest-alapú tesztprojektek esetén módosíthatja a gazdagép feldolgozását a Test Test Gépház Default Processor Architecture as X64 (Tesztteszt>Gépház> Default processzorarchitektúra X64-ként) kiválasztásával a Visual Studio Test menüben.

  • A helyileg telepített ASP.NET webalkalmazások esetében módosíthatja a gazdagépek feldolgozását az IIS Express 64 bites verziójának használata webhelyekhez és projektekhez az Eszközök>beállításai>projektek és megoldások>webprojektek területen.

  • 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.

Feljegyzé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

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, DCount, 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")}))
{
    // ...
}

Feljegyzé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. Mindig szívesebben ürítse ki teljesen a lekérdezést, ha a lapozást egy másik hívó összetevő szabályozza:

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
        }
    }
}

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

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. Ha az értéket -1 értékre állítja, az SDK dönti 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 }))
{
    // ...
}

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ékei esetében.

  • (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.

Feljegyzé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.

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élda:

using (FeedIterator<MyItem> feedIterator = container.GetItemQueryIterator<MyItem>(
    "SELECT * FROM c WHERE c.city = 'Seattle'",
    requestOptions: new QueryRequestOptions() { 
        PartitionKey = new PartitionKey("Washington"),
        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

A párhuzamos lekérdezés célja az eredmények előzetes lekérése, miközben az ügyfél feldolgozza az aktuális eredményköteget. Ez az előzetes beolvasá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 lehívott 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őleolvasás maximális előnyeit. 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}))
{
    // ...
}

Az előzetes beolvasás ugyanúgy működik a párhuzamosság mértékétől függetlenü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. Ez általában egy hálózati kérést jelent az Azure Cosmos DB Gateway felé, amely növeli a lekérdezési művelet késését.

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

Az egyetlen partícióra hatókörrel rendelkező lekérdezési terv gyorsítótárazva van az ügyfélen. Í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 sztring. Meg kell győződnie arról, hogy a lekérdezés parametrizált. Ha nem, a lekérdezési terv gyorsítótárának keresése gyakran gyorsítótár-kihagyás lesz, mivel a lekérdezési sztring valószínűleg nem azonos a hívások között. 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, 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);

Feljegyzé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 lassabban lehet.

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 setMaxDegreeOfParallelismCosmosQueryRequestOptions beállításával á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. Ha az értéket -1 értékre állítja, az SDK dönti 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

Az alábbiakban a párhuzamos lekérdezések viselkedésének következményei szerepelnek a P különböző értékei esetében.

  • (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 paramétert a sync API-ban és byPage() az pageSize async API-ban iterableByPage() 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 célja az eredmények előzetes lekérése, miközben az ügyfél feldolgozza az aktuális eredményköteget. Az előzetes beolvasás segít a lekérdezések késésének általános javításában. setMaxBufferedItemCount in CosmosQueryRequestOptions limit the number of pre-fetched results. Az előleolvasás maximalizálásához állítsa a maxBufferedItemCount nagyobb számot a pageSize (MEGJEGYZÉS: Ez nagy memóriahasználatot is eredményezhet). Az előleolvasás minimalizálásához állítsa be az maxBufferedItemCount egyenlőséget a pageSize. 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őzetes beolvasás ugyanúgy működik a párhuzamosság mértékétől függetlenü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. Ez általában egy hálózati kérést jelent az Azure Cosmos DB Gateway felé, amely növeli 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. Ez általában egy hálózati kérést jelent az Azure Cosmos DB Gateway felé, amely növeli 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 való hatókörének meghatározása kétféleképpen végezhető el.

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 a következőre SELECT * FROM todo t WHERE t.partitionKey = 'Bikes, Touring Bikes'épül:

// 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}`);
}

Következő lépések

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