Bagikan melalui


Tips performa kueri untuk SDK Azure Cosmos DB

BERLAKU UNTUK: NoSQL

Azure Cosmos DB adalah database terdistribusi yang cepat dan fleksibel yang menskalakan dengan mulus dengan tingkat latensi dan throughput terjamin. Anda tidak perlu membuat perubahan arsitektur besar atau menulis kode kompleks untuk menskalakan database dengan Azure Cosmos DB. Peningkatan atau penurunan skala semudah memerintahkan satu API. Untuk mempelajari lebih lanjut, lihat sediakan throughput kontainer atau sediakan throughput database.

Mengurangi panggilan Rencana Kueri

Untuk menjalankan kueri, rencana kueri perlu dibuat. Hal ini secara umum mewakili permintaan jaringan ke Gateway Azure Cosmos DB, yang menambah latensi operasi kueri. Ada dua cara untuk menghapus permintaan ini dan mengurangi latensi operasi kueri:

Mengoptimalkan kueri partisi tunggal dengan Eksekusi Langsung Optimis

Azure Cosmos DB NoSQL memiliki pengoptimalan yang disebut Optimis Eksekusi Langsung (ODE), yang dapat meningkatkan efisiensi kueri NoSQL tertentu. Secara khusus, kueri yang tidak memerlukan distribusi mencakup kueri yang dapat dijalankan pada satu partisi fisik atau yang memiliki respons yang tidak memerlukan penomoran halaman. Kueri yang tidak memerlukan distribusi dapat dengan percaya diri melewati beberapa proses, seperti pembuatan rencana kueri sisi klien dan penulisan ulang kueri, sehingga mengurangi latensi kueri dan biaya RU. Jika Anda menentukan kunci partisi dalam permintaan atau kueri itu sendiri (atau hanya memiliki satu partisi fisik), dan hasil kueri Anda tidak memerlukan penomoran halaman, maka ODE dapat meningkatkan kueri Anda.

Catatan

Eksekusi Langsung Optimis (ODE), yang menawarkan peningkatan performa untuk kueri yang tidak memerlukan distribusi, tidak boleh bingung dengan Mode Langsung, yang merupakan jalur untuk menghubungkan aplikasi Anda ke replika backend.

ODE sekarang tersedia di .NET SDK versi 3.38.0 dan yang lebih baru. Saat Anda menjalankan kueri dan menentukan kunci partisi dalam permintaan atau kueri itu sendiri, atau database Anda hanya memiliki satu partisi fisik, eksekusi kueri Anda dapat memanfaatkan manfaat ODE. Untuk mengaktifkan ODE, atur EnableOptimisticDirectExecution ke true di QueryRequestOptions.

Kueri partisi tunggal yang menampilkan fungsi GROUP BY, ORDER BY, DISTINCT, dan agregasi (seperti jumlah, rata-rata, min, dan maks) dapat secara signifikan mendapat manfaat dari penggunaan ODE. Namun, dalam skenario di mana kueri menargetkan beberapa partisi atau masih memerlukan penomoran halaman, latensi respons kueri dan biaya RU mungkin lebih tinggi daripada tanpa menggunakan ODE. Oleh karena itu, saat menggunakan ODE, kami sarankan untuk:

  • Tentukan kunci partisi dalam panggilan atau kueri itu sendiri.
  • Pastikan ukuran data Anda belum tumbuh dan menyebabkan partisi terpisah.
  • Pastikan bahwa hasil kueri Anda tidak memerlukan penomoran halaman untuk mendapatkan manfaat penuh dari ODE.

Berikut adalah beberapa contoh kueri partisi tunggal sederhana yang dapat memperoleh manfaat dari ODE:

- 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 

Mungkin ada kasus di mana kueri partisi tunggal mungkin masih memerlukan distribusi jika jumlah item data meningkat dari waktu ke waktu dan database Azure Cosmos DB Anda membagi partisi. Contoh kueri di mana hal ini dapat terjadi meliputi:

- 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 

Beberapa kueri kompleks selalu memerlukan distribusi, bahkan jika menargetkan satu partisi. Contoh kueri tersebut meliputi:

- 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 

Penting untuk dicatat bahwa ODE mungkin tidak selalu mengambil rencana kueri dan, akibatnya, tidak dapat melarang atau menonaktifkan untuk kueri yang tidak didukung. Misalnya, setelah pemisahan partisi, kueri tersebut tidak lagi memenuhi syarat untuk ODE dan, oleh karena itu, tidak akan berjalan karena evaluasi rencana kueri sisi klien akan memblokirnya. Untuk memastikan kompatibilitas/kelangsungan layanan, sangat penting untuk memastikan bahwa hanya kueri yang sepenuhnya didukung dalam skenario tanpa ODE (yaitu, mereka mengeksekusi dan menghasilkan hasil yang benar dalam kasus multi-partisi umum) yang digunakan dengan ODE.

Catatan

Menggunakan ODE berpotensi menyebabkan jenis token kelanjutan baru dihasilkan. Token seperti itu tidak dikenali oleh SDK yang lebih lama berdasarkan desain dan ini dapat mengakibatkan Pengecualian Token Kelanjutan Cacat. Jika Anda memiliki skenario di mana token yang dihasilkan dari SDK yang lebih baru digunakan oleh SDK yang lebih lama, kami merekomendasikan pendekatan 2 langkah untuk meningkatkan:

  • Tingkatkan ke SDK baru dan nonaktifkan ODE, keduanya bersama-sama sebagai bagian dari satu penyebaran. Tunggu hingga semua simpul ditingkatkan.
    • Untuk menonaktifkan ODE, atur EnableOptimisticDirectExecution ke false di QueryRequestOptions.
  • Aktifkan ODE sebagai bagian dari penyebaran kedua untuk semua simpul.

Menggunakan pembuatan Rencana Kueri lokal

SQL SDK mencakup ServiceInterop.dll asli untuk memilah dan mengoptimalkan kueri secara lokal. ServiceInterop.dll hanya didukung pada platform Windows x64. Jenis aplikasi berikut menggunakan pemrosesan hos 32-bit secara default. Untuk mengubah pemrosesan hos menjadi pemrosesan 64-bit, ikuti langkah-langkah ini, berdasarkan jenis aplikasi Anda:

  • Untuk aplikasi yang dapat dieksekusi, Anda dapat mengubah pemrosesan hos dengan mengatur target platform ke x64 di jendela Properti Proyek, pada tab Bangun.

  • Untuk proyek pengujian berbasis VSTest, Anda dapat mengubah pemrosesan hos dengan memilih Uji > Pengaturan Pengujian> Arsitektur Prosesor Default sebagai X64 pada menu Uji Visual Studio.

  • Untuk aplikasi web ASP.NET yang disebarkan secara lokal, Anda dapat mengubah pemrosesan hos dengan memilih Gunakan versi 64-bit IIS Express untuk situs web dan proyek di bawah Alat>Opsi>Proyek dan Solusi>Proyek Web.

  • Untuk aplikasi ASP.NET web yang disebarkan pada Azure, Anda dapat mengubah pemrosesan hos dengan memilih platform 64-bit dalam Pengaturan aplikasi di portal Azure.

Catatan

Secara default, proyek Visual Studio baru diatur ke CPU mana pun. Kami menyarankan agar Anda mengatur proyek ke x64 sehingga tidak beralih ke x86. Proyek yang diatur ke CPU mana pun dapat dengan mudah beralih ke x86 jika dependensi hanya x86 ditambahkan.
ServiceInterop.dll harus ada di folder tempat SDK DLL dijalankan. Ini sebaiknya menjadi perhatian hanya jika Anda menyalin DLL secara manual atau memiliki sistem bangun/penyebaran kustom.

Menggunakan kueri partisi tunggal

Untuk kueri yang menargetkan Kunci Partisi dengan mengatur properti PartitionKey di dan QueryRequestOptions tidak berisi agregasi (termasuk Distinct, DCount, Group By). Dalam contoh ini, bidang /state kunci partisi difilter pada nilai Washington.

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

Secara opsional, Anda dapat memberikan kunci partisi sebagai bagian dari objek opsi permintaan.

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

Penting

Pada klien yang menjalankan OS non-Windows, seperti Linux dan MacOS, kunci partisi harus selalu ditentukan dalam objek opsi permintaan.

Catatan

Kueri lintas partisi memerlukan SDK untuk mengunjungi semua partisi yang ada untuk memeriksa hasilnya. Semakin banyak partisi fisik yang dimiliki kontainer, kontainer berpotensi menjadi semakin lambat.

Hindari membuat ulang iterator yang tidak perlu

Saat semua hasil kueri digunakan oleh komponen saat ini, Anda tidak perlu membuat ulang iterator dengan kelanjutan untuk setiap halaman. Sebaiknya hapus kueri sepenuhnya kecuali penomoran halaman dikendalikan oleh komponen panggilan lain:

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

Mengatur derajat paralelisme

Untuk kueri, sesuaikan properti MaxConcurrency di QueryRequestOptions untuk mengidentifikasi konfigurasi terbaik untuk aplikasi Anda, terutama jika Anda melakukan kueri lintas partisi (tanpa filter pada nilai kunci partisi). MaxConcurrency mengontrol jumlah maksimum tugas paralel, yaitu, maksimum partisi yang akan dikunjungi secara paralel. Mengatur nilai ke -1 akan membuat SDK memutuskan konkurensi yang optimal.

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

Mari kita asumsikan bahwa

  • D = Jumlah maksimum default tugas paralel (= jumlah total prosesor di mesin klien)
  • P = Jumlah maksimum tugas paralel yang ditentukan pengguna
  • N = Jumlah partisi yang perlu dikunjungi untuk menjawab kueri

Berikut adalah implikasi tentang bagaimana kueri paralel akan berperilaku untuk nilai P yang berbeda.

  • (P == 0) => Mode Seri
  • (P == 1) => Maksimum satu tugas
  • (P > 1) => Min (P, N) tugas paralel
  • (P < 1) => Min (N, D) tugas paralel

Menyetel ukuran halaman

Saat Anda mengeluarkan kueri SQL, hasilnya ditampilkan secara tersegmentasi jika tataan hasil terlalu besar.

Catatan

Properti MaxItemCount sebaiknya tidak digunakan untuk paginasi saja. Penggunaan utamanya adalah untuk meningkatkan kinerja kueri dengan mengurangi jumlah maksimum item yang dikembalikan dalam satu halaman.

Anda juga dapat mengatur ukuran halaman dengan menggunakan SDK Azure Cosmos DB yang tersedia. Properti MaxItemCount dalam QueryRequestOptions memungkinkan Anda mengatur jumlah maksimum item yang akan dikembalikan dalam operasi pencacahan. Ketika MaxItemCount diatur ke -1, SDK secara otomatis menemukan nilai optimal, tergantung pada ukuran dokumen. Contohnya:

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

Saat kueri dijalankan, data yang dihasilkan dikirim dalam paket TCP. Jika Anda menentukan nilai yang terlalu rendah untuk MaxItemCount, jumlah perjalanan yang diperlukan untuk mengirim data dalam paket TCP menjadi tinggi, yang memengaruhi kinerja. Jadi, jika Anda tidak yakin nilai apa yang akan diatur untuk properti MaxItemCount, cara terbaik adalah mengaturnya ke -1 dan biarkan SDK memilih nilai default.

Menyetel ukuran buffer

Kueri paralel dirancang untuk pra-ambil hasil saat batch hasil saat ini sedang diproses oleh klien. Pra-pengambilan ini membantu meningkatkan latensi keseluruhan kueri. Properti MaxBufferedItemCount di QueryRequestOptions membatasi jumlah hasil yang diambil sebelumnya. Atur MaxBufferedItemCount ke jumlah hasil yang ingin dikembalikan (atau angka yang lebih tinggi) agar kueri menerima manfaat maksimum dari pra-pengambilan. Jika Anda menyetel nilai ini ke -1, sistem akan secara otomatis menentukan jumlah unsur yang akan disangga.

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

Pra-pengambilan bekerja dengan cara yang sama terlepas dari derajat paralelisme, dan ada satu buffer untuk data dari semua partisi.

Langkah berikutnya

Untuk mempelajari selengkapnya tentang performa menggunakan SDK .NET:

Mengurangi panggilan Rencana Kueri

Untuk menjalankan kueri, rencana kueri perlu dibuat. Hal ini secara umum mewakili permintaan jaringan ke Gateway Azure Cosmos DB, yang menambah latensi operasi kueri.

Menggunakan penembolokan Rencana Kueri

Rencana kueri, untuk kueri yang dicakup ke satu partisi, disimpan di klien. Hal ini menghilangkan kebutuhan untuk melakukan panggilan ke gateway untuk mengambil rencana kueri setelah panggilan pertama. Kunci untuk rencana kueri yang disimpan adalah string kueri SQL. Anda harus memastikan kueri bahwa berparameter. Jika tidak, pencarian cache rencana kueri akan sering menjadi cache yang hilang karena string kueri tidak mungkin identik di seluruh panggilan. Penembolokan paket kueri diaktifkan secara default untuk Java SDK versi 4.20.0 ke atas dan untuk Spring Data Azure Cosmos DB SDK versi 3.13.0 ke atas.

Menggunakan kueri partisi tunggal berparameter

Untuk kueri berparameter yang dicakup ke kunci partisi dengan setPartitionKey di CosmosQueryRequestOptions dan tidak berisi agregasi (termasuk Distinct, DCount, Group By), rencana kueri dapat dihindari:

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);

Catatan

Kueri lintas partisi memerlukan SDK untuk mengunjungi semua partisi yang ada untuk memeriksa hasilnya. Semakin banyak partisi fisik yang dimiliki kontainer, kontainer dapat menjadi semakin lambat.

Mengatur derajat paralelisme

Kueri paralel bekerja dengan mengkueri beberapa partisi secara paralel. Tetapi, data dari masing-masing kontainer yang dipartisi diambil secara serial sehubungan dengan kueri. Jadi, gunakan setMaxDegreeOfParallelism pada CosmosQueryRequestOptions untuk mengatur nilai ke jumlah partisi yang Anda miliki. Jika Anda tidak mengetahui jumlah partisi, Anda dapat menggunakan setMaxDegreeOfParallelism untuk menetapkan angka tinggi, dan sistem memilih minimum (jumlah partisi, input yang diberikan pengguna) sebagai derajat paralelisme maksimum. Mengatur nilai ke -1 akan membuat SDK memutuskan konkurensi yang optimal.

Perlu diingat bahwa kueri paralel menghasilkan manfaat terbaik jika data didistribusikan secara merata di semua partisi sehubungan dengan kueri. Jika kontainer berpartisi dipartisi sedemikian rupa sehingga semua atau sebagian besar data yang dikembalikan oleh kueri terkonsentrasi di beberapa partisi (dalam kasus terburuk satu partisi), maka performa kueri akan menurun.

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);

Mari kita asumsikan bahwa

  • D = Jumlah maksimum default tugas paralel (= jumlah total prosesor di mesin klien)
  • P = Jumlah maksimum tugas paralel yang ditentukan pengguna
  • N = Jumlah partisi yang perlu dikunjungi untuk menjawab kueri

Berikut adalah implikasi tentang bagaimana kueri paralel akan berperilaku untuk nilai P yang berbeda.

  • (P == 0) => Mode Seri
  • (P == 1) => Maksimum satu tugas
  • (P > 1) => Min (P, N) tugas paralel
  • (P == -1) => Min (N, D) tugas paralel

Menyetel ukuran halaman

Saat Anda mengeluarkan kueri SQL, hasilnya ditampilkan secara tersegmentasi jika tataan hasil terlalu besar. Secara default, hasil dikembalikan dalam gugus 100 item atau 4 MB, batas mana saja yang tercapai lebih dulu. Meningkatkan ukuran halaman akan mengurangi jumlah perjalanan pulang pergi yang diperlukan dan meningkatkan performa untuk kueri yang mengembalikan lebih dari 100 item. Jika Anda tidak yakin nilai apa yang akan ditetapkan, 1000 biasanya merupakan pilihan yang baik. Konsumsi memori akan meningkat saat ukuran halaman meningkat, jadi jika beban kerja Anda sensitif terhadap memori, pertimbangkan nilai yang lebih rendah.

Anda dapat menggunakan parameter pageSize di iterableByPage() untuk API sinkronisasi dan byPage() untuk API asinkron, guna menentukan ukuran halaman:

//  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();

Menyetel ukuran buffer

Kueri paralel dirancang untuk pra-ambil hasil saat batch hasil saat ini sedang diproses oleh klien. Pengambilan sebelumnya membantu dalam peningkatan latensi kueri keseluruhan. setMaxBufferedItemCount di CosmosQueryRequestOptions membatasi jumlah hasil yang diambil sebelumnya. Untuk memaksimalkan pra-pengambilan, atur maxBufferedItemCount ke angka yang lebih tinggi dari pageSize (CATATAN: Ini juga dapat mengakibatkan konsumsi memori tinggi). Untuk meminimalkan pra-pengambilan, atur maxBufferedItemCount sama dengan pageSize. Jika Anda menetapkan nilai ini ke 0, sistem akan secara otomatis menentukan jumlah item untuk buffer.

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);

Pra-pengambilan bekerja dengan cara yang sama terlepas dari derajat paralelisme, dan ada satu buffer untuk data dari semua partisi.

Langkah berikutnya

Untuk mempelajari selengkapnya tentang performa menggunakan SDK Java:

Mengurangi panggilan Rencana Kueri

Untuk menjalankan kueri, rencana kueri perlu dibuat. Hal ini secara umum mewakili permintaan jaringan ke Gateway Azure Cosmos DB, yang menambah latensi operasi kueri. Ada cara untuk menghapus permintaan ini dan mengurangi latensi operasi kueri partisi tunggal. Untuk kueri partisi tunggal, tentukan nilai kunci partisi untuk item dan teruskan sebagai argumen partition_key :

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

Menyetel ukuran halaman

Saat Anda mengeluarkan kueri SQL, hasilnya ditampilkan secara tersegmentasi jika tataan hasil terlalu besar. max_item_count memungkinkan Anda mengatur jumlah maksimum item yang akan dikembalikan dalam operasi enumerasi.

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

Langkah berikutnya

Untuk mempelajari selengkapnya tentang menggunakan Python SDK untuk API untuk NoSQL:

Mengurangi panggilan Rencana Kueri

Untuk menjalankan kueri, rencana kueri perlu dibuat. Hal ini secara umum mewakili permintaan jaringan ke Gateway Azure Cosmos DB, yang menambah latensi operasi kueri. Ada cara untuk menghapus permintaan ini dan mengurangi latensi operasi kueri partisi tunggal. Untuk kueri partisi tunggal yang mencakup kueri ke satu partisi dapat dicapai dengan dua cara.

Menggunakan ekspresi kueri berparameter dan menentukan kunci partisi dalam pernyataan kueri. Kueri secara terprogram terdiri dari 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}`);
}

Atau tentukan partitionKey masuk FeedOptions dan berikan sebagai argumen:

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

Menyetel ukuran halaman

Saat Anda mengeluarkan kueri SQL, hasilnya ditampilkan secara tersegmentasi jika tataan hasil terlalu besar. maxItemCount memungkinkan Anda mengatur jumlah maksimum item yang akan dikembalikan dalam operasi enumerasi.

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

Langkah berikutnya

Untuk mempelajari selengkapnya tentang menggunakan SDK Node.js untuk API untuk NoSQL: