Memecahkan masalah kueri saat menggunakan Azure Cosmos DB

  • Artikel

BERLAKU UNTUK: NoSQL

Artikel ini berjalan melalui pendekatan umum yang direkomendasikan untuk memecahkan masalah kueri di Azure Cosmos DB. Meskipun Anda tidak boleh mempertimbangkan langkah-langkah yang diuraikan dalam artikel ini pertahanan lengkap terhadap masalah kueri potensial, kami telah menyertakan tips performa yang paling umum di sini. Anda harus menggunakan artikel ini sebagai tempat awal untuk memecahkan masalah kueri lambat atau mahal di Azure Cosmos DB for NoSQL. Anda juga dapat menggunakan log diagnostik untuk mengidentifikasi kueri yang lambat atau yang mengkonsumsi throughput dalam jumlah signifikan. Jika Anda menggunakan API Azure Cosmos DB untuk MongoDB, Anda harus menggunakan API Azure Cosmos DB untuk panduan pemecahan masalah kueri MongoDB

Pengoptimalan kueri di Azure Cosmos DB secara luas dikategorikan sebagai berikut:

  • Pengoptimalan yang mengurangi biaya Unit Permintaan (RU) kueri
  • Pengoptimalan yang hanya mengurangi latensi

Jika Anda mengurangi muatan RU kueri, biasanya Anda juga akan mengurangi latensi.

Artikel ini menyediakan contoh yang dapat Anda buat ulang dengan menggunakan himpunan data nutrisi.

Masalah SDK umum

Sebelum membaca panduan ini, sangat berguna untuk mempertimbangkan masalah SDK umum yang tidak terkait dengan mesin kueri.

  • Ikuti Tips Performa SDK untuk kueri.
  • Terkadang kueri mungkin memiliki halaman kosong bahkan ketika ada hasil di halaman mendatang. Alasan untuk ini bisa:
    • SDK bisa melakukan beberapa panggilan jaringan.
    • Kueri mungkin membutuhkan waktu lama untuk mengambil dokumen.
  • Semua kueri memiliki token kelanjutan yang akan memungkinkan kueri untuk melanjutkan. Pastikan untuk menguras kueri sepenuhnya. Pelajari selengkapnya tentang menangani beberapa halaman hasil

Dapatkan kueri metrik

Saat Anda mengoptimalkan kueri di Azure Cosmos DB, langkah pertama adalah selalu mendapatkan kueri metrik untuk kueri Anda. Metrik ini juga tersedia melalui portal Azure. Setelah Anda menjalankan kueri Anda di Data Explorer, metrik kueri terlihat di samping tab Hasil:

Mendapatkan metrik kueri

Setelah Anda mendapatkan metrik kueri, bandingkan Jumlah Dokumen yang Diperoleh dengan Jumlah Dokumen Output untuk kueri Anda. Gunakan perbandingan ini untuk mengidentifikasi bagian yang relevan untuk ditinjau dalam artikel ini.

Jumlah Dokumen yang Diambil adalah jumlah dokumen yang perlu dimuat oleh mesin kueri. Hitungan Dokumen Keluaran adalah jumlah dokumen yang dibutuhkan untuk hasil kueri. Jika Jumlah Dokumen yang Diperoleh secara signifikan lebih tinggi daripada Jumlah Dokumen Keluaran, setidaknya ada satu bagian dari kueri Anda yang tidak dapat menggunakan indeks dan perlu melakukan pemindaian.

Lihat bagian berikut untuk memahami pengoptimalan kueri yang relevan untuk skenario Anda.

Biaya RU Kueri terlalu tinggi

Jumlah Dokumen yang Diambil secara signifikan lebih tinggi dari Jumlah Dokumen Output


Jumlah Dokumen yang Diambil kira-kira sama dengan Jumlah Dokumen Output


Biaya RU Kueri dapat diterima tetapi latensi masih terlalu tinggi

Kueri di mana Jumlah Dokumen yang Diperoleh melebihi Jumlah Dokumen Keluaran

Jumlah Dokumen yang Diambil adalah jumlah dokumen yang perlu dimuat oleh mesin kueri. Jumlah Dokumen Output adalah jumlah dokumen yang dikembalikan oleh kueri. Jika Jumlah Dokumen yang Diperoleh secara signifikan lebih tinggi daripada Jumlah Dokumen Keluaran, setidaknya ada satu bagian dari kueri Anda yang tidak dapat menggunakan indeks dan perlu melakukan pemindaian.

Berikut ini contoh kueri pemindaian yang tidak sepenuhnya dilayani oleh indeks:

Kueri:

SELECT VALUE c.description
FROM c
WHERE UPPER(c.description) = "BABYFOOD, DESSERT, FRUIT DESSERT, WITHOUT ASCORBIC ACID, JUNIOR"

Kueri metrik:

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

Jumlah Dokumen yang Diambil (60.951) secara signifikan lebih tinggi dari Jumlah Dokumen Output (7), menyiratkan bahwa kueri ini menghasilkan pemindaian dokumen. Dalam hal ini, fungsi sistem UPPER() tidak menggunakan indeks.

Sertakan jalur yang diperlukan dalam kebijakan pengindeksan

Kebijakan pengindeksan Anda harus mencakup semua properti yang termasuk dalam WHEREklausul, ORDER BYklausul, JOIN, dan sebagian besar fungsi sistem. Jalur yang diinginkan yang ditentukan dalam kebijakan indeks harus cocok dengan properti dalam dokumen JSON.

Catatan

Properti dalam kebijakan pengindeksan DB Azure Cosmos peka huruf besar/kecil

Jika Anda menjalankan kueri sederhana berikut pada kumpulan data nutrisi, Anda akan mengamati biaya RU yang jauh lebih rendah saat properti dalam WHEREklausul diindeks:

Asli

Kueri:

SELECT *
FROM c
WHERE c.description = "Malabar spinach, cooked"

Kebijakan pengindeksan:

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

Biaya RU: 409.51 RUs

Dioptimalkan

Kebijakan pengindeksan yang diperbarui:

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

Biaya RU: 2.98 RUs

Anda bisa menambahkan properti ke kebijakan pengindeksan kapan saja, tanpa berpengaruh pada ketersediaan tulis atau baca. Anda dapat melacak kemajuan transformasi indeks.

Pahami fungsi sistem mana yang menggunakan indeks

Sebagian besar fungsi sistem menggunakan indeks. Berikut adalah daftar beberapa fungsi string umum yang menggunakan indeks:

  • MulaiDengan
  • Berisi
  • RegexMatch
  • Kiri
  • Substring - tetapi hanya jika num_expr adalah 0

Berikut ini adalah beberapa fungsi sistem umum yang tidak menggunakan indeks dan harus memuat setiap dokumen saat digunakan dalam WHERE klausul:

Fungsi sistem Ide untuk pengoptimalan
Atas/Bawah Alih-alih menggunakan fungsi sistem untuk menormalkan data untuk perbandingan, normalkan casing setelah penyisipan. Kueri seperti SELECT * FROM c WHERE UPPER(c.name) = 'BOB' menjadi SELECT * FROM c WHERE c.name = 'BOB'.
GetCurrentDateTime/GetCurrentTimestamp/GetCurrentTicks Hitung waktu saat ini sebelum eksekusi kueri dan gunakan nilai string tersebut dalam WHERE klausul.
Fungsi matematika (non-agregat) Jika Anda perlu menghitung nilai secara berkala di kueri Anda, pertimbangkan untuk menyimpan nilai sebagai properti di dokumen JSON Anda.

Fungsi sistem ini dapat menggunakan indeks, kecuali ketika digunakan dalam kueri dengan agregat:

Fungsi sistem Ide untuk pengoptimalan
Fungsi sistem spasial Menyimpan hasil kueri dalam tampilan terwujud secara real-time

Ketika digunakan dalam SELECT klausul, fungsi sistem yang tidak efisien tidak akan mempengaruhi bagaimana kueri dapat menggunakan indeks.

Meningkatkan eksekusi fungsi sistem string

Untuk beberapa fungsi sistem yang menggunakan indeks, Anda bisa meningkatkan eksekusi kueri dengan menambahkan ORDER BY klausul ke kueri.

Lebih khusus lagi, fungsi sistem apa pun yang biaya RU-nya meningkat karena kardinalitas properti meningkat dapat mengambil manfaat dari memiliki ORDER BY dalam kueri. Kueri ini melakukan pemindaian indeks, sehingga hasil kueri diurutkan bisa membuat kueri lebih efisien.

Pengoptimalan ini dapat meningkatkan eksekusi untuk fungsi sistem berikut:

  • StartsWith (di mana case-insensitive = true)
  • StringEquals (di mana case-insensitive = true)
  • Berisi
  • RegexMatch
  • BerakhirDengan

Misalnya, pertimbangkan kueri di bawah ini dengan CONTAINS. CONTAINS akan menggunakan indeks tetapi kadang-kadang, bahkan setelah menambahkan indeks yang relevan, Anda mungkin masih mengamati muatan RU yang sangat tinggi saat menjalankan kueri di bawah ini.

Kueri asli:

SELECT *
FROM c
WHERE CONTAINS(c.town, "Sea")

Anda bisa meningkatkan eksekusi kueri dengan menambahkan ORDER BY :

SELECT *
FROM c
WHERE CONTAINS(c.town, "Sea")
ORDER BY c.town

Pengoptimalan yang sama dapat membantu dalam kueri dengan filter tambahan. Dalam hal ini, yang terbaik adalah juga menambahkan properti dengan filter kesetaraan ke ORDER BY klausul.

Kueri asli:

SELECT *
FROM c
WHERE c.name = "Samer" AND CONTAINS(c.town, "Sea")

Anda dapat meningkatkan eksekusi kueri dengan ORDER BY menambahkan dan indeks komposit untuk (c.name, c.town):

SELECT *
FROM c
WHERE c.name = "Samer" AND CONTAINS(c.town, "Sea")
ORDER BY c.name, c.town

Pahami kueri agregat mana yang menggunakan indeks

Dalam kebanyakan kasus, fungsi sistem agregat di Azure Cosmos DB akan menggunakan indeks. Namun, tergantung pada filter atau klausul tambahan dalam kueri agregat, mesin kueri mungkin diperlukan untuk memuat sejumlah besar dokumen. Biasanya, mesin kueri akan menerapkan filter persamaan dan rentang terlebih dahulu. Setelah menerapkan filter ini, mesin kueri dapat mengevaluasi filter tambahan dan menggunakan pemuatan dokumen yang tersisa untuk menghitung agregat, jika diperlukan.

Misalnya, mengingat dua kueri sampel ini, kueri dengan kesetaraan dan CONTAINS filter fungsi sistem umumnya akan lebih efisien daripada kueri hanya dengan CONTAINS filter fungsi sistem. Ini karena filter kesetaraan diterapkan terlebih dahulu dan menggunakan indeks sebelum dokumen perlu dimuat untuk filter yang lebih CONTAINS mahal.

Kueri dengan CONTAINS hanya filter - biaya RU yang lebih tinggi:

SELECT COUNT(1)
FROM c
WHERE CONTAINS(c.description, "spinach")

Kueri dengan filter CONTAINS dan filter kesetaraan - biaya RU yang lebih rendah:

SELECT AVG(c._ts)
FROM c
WHERE c.foodGroup = "Sausages and Luncheon Meats" AND CONTAINS(c.description, "spinach")

Berikut adalah contoh tambahan kueri agregat yang tidak akan sepenuhnya menggunakan indeks:

Kueri dengan fungsi sistem yang tidak menggunakan indeks

Anda harus merujuk ke halaman fungsi sistem yang relevan untuk melihat apakah ia menggunakan indeks.

SELECT MAX(c._ts)
FROM c
WHERE CONTAINS(c.description, "spinach")

Kueri agregat dengan fungsi yang ditentukan pengguna (UDF)

SELECT AVG(c._ts)
FROM c
WHERE udf.MyUDF("Sausages and Luncheon Meats")

Kueri dengan GRUP OLEH

Muatan RU pertanyaan GROUP BY dengan akan meningkat ketika kardinalitas properti dalam GROUP BY klausul meningkat. Dalam kueri di bawah ini, misalnya, muatan RU kueri akan meningkat saat deskripsi unik angka meningkat.

Muatan RU dari fungsi agregat dengan GROUP BY klausul akan lebih tinggi daripada muatan RU dari fungsi agregat saja. Dalam contoh ini, mesin kueri harus memuat setiap dokumen yang cocok c.foodGroup = "Sausages and Luncheon Meats" dengan filter sehingga muatan RU diperkirakan tinggi.

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

Jika Anda berencana untuk sering menjalankan kueri agregat yang sama, mungkin lebih efisien untuk membuat tampilan terwujud waktu nyata dengan umpan perubahan Azure Cosmos DB daripada menjalankan kueri individual.

Mengoptimalkan kueri yang memiliki filter dan klausul ORDER BY

Meskipun kueri yang memiliki filter dan ORDER BY klausul biasanya akan menggunakan indeks rentang, kueri tersebut akan lebih efisien jika dapat disajikan dari indeks komposit. Selain mengubah kebijakan pengindeksan, Anda harus menambahkan semua properti dalam indeks komposit ke ORDER BY klausul. Perubahan pada kueri ini akan memastikan bahwa ia menggunakan indeks komposit. Anda dapat mengamati dampaknya dengan menjalankan kueri pada kumpulan data nutrisi:

Asli

Kueri:

SELECT *
FROM c
WHERE c.foodGroup = "Soups, Sauces, and Gravies"
ORDER BY c._ts ASC

Kebijakan pengindeksan:

{

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

Biaya RU: 44.28 RUs

Dioptimalkan

Kueri yang diperbarui (menyertakan kedua properti dalam klausul ORDER BY):

SELECT *
FROM c
WHERE c.foodGroup = "Soups, Sauces, and Gravies"
ORDER BY c.foodGroup, c._ts ASC

Kebijakan pengindeksan yang diperbarui:

{  
        "automatic":true,
        "indexingMode":"Consistent",
        "includedPaths":[  
            {  
                "path":"/*"
            }
        ],
        "excludedPaths":[],
        "compositeIndexes":[  
            [  
                {  
                    "path":"/foodGroup",
                    "order":"ascending"
        },
                {  
                    "path":"/_ts",
                    "order":"ascending"
                }
            ]
        ]
    }

Biaya RU: 8.86 RUs

Optimalkan ekspresi GABUNG dengan menggunakan subkueri

Subkueri multi-nilai dapat mengoptimalkan JOIN ekspresi dengan mendorong predikat setelah setiap ekspresi pilih-banyak daripada setelah semua gabungan silang dalam klausul WHERE.

Pertimbangkan kueri ini:

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

Biaya RU: 167.62 RUs

Untuk kueri ini, indeks akan cocok dengan dokumen apa pun yang memiliki tag dengan nama infant formula, nutritionValue lebih besar dari 0, dan amount lebih besar dari 1. Ekspresi JOIN di sini akan melakukan produk silang dari semua item larik tag, nutrisi, dan penyajian untuk setiap dokumen yang cocok sebelum filter apa pun diterapkan. klausul WHERE tersebut kemudian akan menerapkan predikat filter pada setiap<c, t, n, s> tupel.

Misalnya, jika dokumen yang cocok memiliki 10 item di masing-masing dari tiga array, dokumen tersebut akan berkembang menjadi 1 x 10 x 10 x 10 (yaitu, 1.000) tuple. Penggunaan subkueri di sini dapat membantu memfilter item array yang digabungkan sebelum bergabung dengan ekspresi berikutnya.

Kueri ini setara dengan yang sebelumnya tetapi menggunakan subkueri:

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)

Biaya RU: 22.17 RUs

Asumsikan bahwa hanya satu item dalam larik tag yang cocok dengan filter dan ada lima item untuk larik nutrien dan penyajian. Ekspresi JOIN akan diperluas menjadi 1 x 1 x 5 x 5 = 25 item, berbeda dengan 1.000 item di kueri pertama.

Kueri di mana Jumlah Dokumen yang Diperoleh sama dengan Jumlah Dokumen Output

Jika Jumlah Dokumen yang Diperoleh kira-kira sama dengan Jumlah Dokumen Keluaran, mesin kueri tidak perlu memindai banyak dokumen yang tidak perlu. Untuk banyak kueri, seperti yang menggunakan kata TOP kunci, Jumlah Dokumen yang Diambil mungkin melebihi Jumlah Dokumen Output dengan 1. Anda tidak perlu khawatir tentang hal ini.

Mengecilkan kueri lintas partisi

Azure Cosmos DB menggunakan partisi untuk menskalakan masing-masing kontainer karena Unit Permintaan dan kebutuhan penyimpanan data meningkat. Setiap partisi fisik memiliki indeks yang terpisah dan independen. Jika kueri Anda memiliki filter kesetaraan yang cocok dengan kunci partisi kontainer, Anda hanya perlu memeriksa indeks partisi yang relevan. Pengoptimalan ini mengurangi jumlah total RUs yang diperlukan kueri.

Jika Anda memiliki sejumlah besar RUs yang disediakan (lebih dari 30.000) atau sejumlah besar data yang disimpan (lebih dari sekitar 100 GB), Anda mungkin memiliki wadah yang cukup besar untuk melihat pengurangan biaya RU kueri yang signifikan.

Misalnya, jika Anda membuat wadah dengan kunci partisi foodGroup, kueri berikut hanya perlu memeriksa satu partisi fisik:

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

Kueri yang memiliki IN filter dengan kunci partisi hanya akan memeriksa partisi fisik yang relevan dan tidak akan "fan-out":

SELECT *
FROM c
WHERE c.foodGroup IN("Soups, Sauces, and Gravies", "Vegetables and Vegetable Products") and c.description = "Mushroom, oyster, raw"

Kueri yang memiliki filter rentang pada kunci partisi, atau yang tidak memiliki filter apa pun pada kunci partisi, perlu "fan-out" dan memeriksa setiap indeks partisi fisik untuk hasil:

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"

Mengoptimalkan kueri yang memiliki filter pada beberapa properti

Meskipun kueri yang memiliki filter pada beberapa properti biasanya akan menggunakan indeks rentang, mereka akan lebih efisien jika dapat disajikan dari indeks gabungan. Untuk jumlah data yang kecil, pengoptimalan ini tidak akan berdampak signifikan. Ini bisa berguna, bagaimanapun, untuk sejumlah besar data. Anda hanya dapat mengoptimalkan, paling banyak, satu filter non-kesetaraan per indeks komposit. Jika kueri Anda memiliki beberapa filter non-kesetaraan, pilih salah satunya yang akan menggunakan indeks komposit. Sisanya akan terus menggunakan indeks rentang. Filter non-kesetaraan harus didefinisikan terakhir dalam indeks komposit. Pelajari lebih lanjut tentang indeks komposit.

Berikut adalah beberapa contoh kueri yang dapat dioptimalkan dengan indeks komposit:

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

Berikut indeks komposit yang relevan:

{  
        "automatic":true,
        "indexingMode":"Consistent",
        "includedPaths":[  
            {  
                "path":"/*"
            }
        ],
        "excludedPaths":[],
        "compositeIndexes":[  
            [  
                {  
                    "path":"/foodGroup",
                    "order":"ascending"
                },
                {  
                    "path":"/_ts",
                    "order":"ascending"
                }
            ]
        ]
}

Pengoptimalan yang mengurangi latensi kueri

Dalam banyak kasus, biaya RU mungkin dapat diterima ketika latensi kueri masih terlalu tinggi. Bagian berikut ini memberikan gambaran umum tips untuk mengurangi latensi kueri. Jika Anda menjalankan kueri yang sama beberapa kali pada set data yang sama, biasanya akan memiliki biaya RU yang sama setiap kali. Tetapi latensi kueri mungkin berbeda di antara eksekusi kueri.

Meningkatkan kedekatan

Kueri yang dijalankan dari wilayah yang berbeda dari akun Azure Cosmos DB akan memiliki latensi yang lebih tinggi daripada jika dijalankan di dalam wilayah yang sama. Misalnya, jika Anda menjalankan kode di komputer desktop, Anda harus mengharapkan latensi menjadi puluhan atau ratusan milidetik lebih tinggi (atau lebih) daripada jika kueri berasal dari mesin virtual dalam wilayah Azure yang sama dengan Azure Cosmos DB. Sangat mudah untuk mendistribusikan data secara global di Azure Cosmos DB untuk memastikan Anda dapat membawa data Anda lebih dekat ke aplikasi Anda.

Meningkatkan throughput yang disediakan

Di Azure Cosmos DB, throughput yang disediakan diukur dalam Unit Permintaan (RUs). Bayangkan Anda memiliki kueri yang menggunakan 5 RUs throughput. Misalnya, jika Anda menyediakan 1.000 RUs, Anda akan dapat menjalankan kueri tersebut 200 kali per detik. Jika Anda mencoba menjalankan kueri saat tidak tersedia cukup throughput, Azure Cosmos DB akan mengembalikan kesalahan HTTP 429. Salah satu API saat ini untuk NoSQL SDK akan secara otomatis mencoba kembali kueri ini setelah menunggu beberapa saat. Permintaan yang dicekik membutuhkan waktu lebih lama, sehingga meningkatkan throughput yang disediakan dapat meningkatkan latensi kueri. Anda dapat mengamati jumlah total permintaan yang dibatasi pada bilah Metrik portal Azure.

Tingkatkan MaxConcurrency

Kueri paralel bekerja dengan mengkueri beberapa partisi secara paralel. Tetapi data dari tiap partisi diambil secara serial terkait dengan kueri. Jadi, jika Anda menyetel MaxConcurrency ke jumlah partisi, Anda memiliki peluang terbaik untuk mendapatkan kueri yang paling berkinerja, asalkan semua kondisi sistem lainnya tetap sama. Jika Anda tidak mengetahui jumlah partisi, Anda dapat mengatur MaxConcurrency (atau MaxDegreesOfParallelism dalam versi SDK yang lebih lama) ke angka tinggi. Sistem akan memilih minimum (jumlah partisi, input yang disediakan pengguna) sebagai tingkat paralelisme.

Tingkatkan MaxBufferedItemCount

Kueri dirancang untuk mengambil hasil terlebih dahulu saat kumpulan hasil saat ini sedang diproses oleh klien. Pra-pengambilan ini membantu meningkatkan latensi keseluruhan kueri. Pengaturan MaxBufferedItemCount membatasi jumlah hasil yang diambil sebelumnya. Jika Anda menetapkan nilai ini ke jumlah hasil yang diharapkan yang dikembalikan (atau angka yang lebih tinggi), kueri bisa mendapatkan manfaat maksimal dari pra-pengambilan. Jika Anda menyetel nilai ini ke -1, sistem akan secara otomatis menentukan jumlah unsur yang akan disangga.

Langkah berikutnya

Lihat artikel berikut ini untuk informasi tentang cara mengukur RUs per kueri, mendapatkan statistik eksekusi untuk menyetel kueri Anda, dan lainnya: