Mengapa kueri Azure Cosmos memiliki RU yang lebih tinggi saat menentukan kunci partisi?

Question

Saya punya pertanyaan serupa dengan yang ini . Pada dasarnya, saya telah menguji berbagai cara untuk menggunakan kunci partisi, dan telah memperhatikan bahwa setiap saat, semakin banyak kunci partisi dirujuk dalam kueri, semakin tinggi RUs. Ini cukup konsisten, dan tidak peduli bagaimana kunci partisi digunakan. Jadi saya mempersempitnya ke kueri dasar untuk pengujian.

Untuk memulai, database ini memiliki sekitar 850K dokumen, semuanya berukuran lebih dari 1KB. Kunci partisi pada dasarnya adalah modulus 100 id dalam bentuk angka, disetel ke / partitionKey, dan penampung menggunakan kebijakan pengindeksan default:

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

Inilah tes kueri dasar saya:

SELECT c.id, c.partitionKey
FROM c
WHERE c.partitionKey = 99 AND c.id = '99999'
-- Yields One Document; Actual Request Charge: 2.95 RUs

SELECT c.id, c.partitionKey
FROM c
WHERE c.id = '99999'
-- Yields One Document; Actual Request Charge: 2.85 RUs

Dokumentasi Azure Cosmos mengatakan tanpa kunci partisi, kueri akan " menyebar " ke semua partisi logis. Oleh karena itu, saya sepenuhnya mengharapkan kueri pertama untuk menargetkan satu partisi dan yang kedua menargetkan semuanya, yang berarti yang pertama harus memiliki RU yang lebih rendah. Saya kira saya menggunakan hasil RU sebagai bukti apakah Cosmos menyebar dan memindai setiap partisi atau tidak, dan membandingkannya dengan apa yang menurut dokumentasi harus terjadi.

Saya tahu hasil ini hanya selisih 0,1 RU. Tapi maksud saya adalah semakin kompleks kueri, semakin besar perbedaannya. Misalnya, berikut adalah kueri lain yang sedikit lebih rumit:

SELECT c.id, c.partitionKey
FROM c
WHERE (c.partitionKey = 98 OR c.partitionKey = 99) AND c.id = '99999'
-- Yields One Document; Actual Request Charge: 3.05 RUs

Perhatikan RU terus tumbuh dan terpisah dari tidak menentukan kunci partisi sama sekali. Sebaliknya saya mengharapkan kueri di atas hanya menargetkan dua partisi, dibandingkan dengan tidak ada pemeriksaan kunci partisi yang seharusnya menyebar ke semua partisi.

Saya mulai mencurigai pemeriksaan kunci partisi terjadi setelah filter lain (atau di dalam setiap pemindaian partisi). Misalnya, kembali ke kueri pertama tetapi mengubah id menjadi sesuatu yang tidak ada:

SELECT c.id, c.partitionKey
FROM c
WHERE c.partitionKey = 99 AND c.id = '99999x'
-- Yields Zero Documents; Actual Request Charge: 2.79 RUs

SELECT c.id, c.partitionKey
FROM c
WHERE c.id = '99999x'
-- Yields Zero Documents; Actual Request Charge: 2.79 RUs

Perhatikan RU yang persis sama, dan keduanya (termasuk yang memiliki filter partisi) memiliki RU yang lebih sedikit daripada saat dokumen ada. Sepertinya ini adalah gejala dari filter partisi yang dijalankan pada hasil, bukan membatasi penyebaran. Tapi bukan ini yang tertulis dalam dokumentasi.

Mengapa Cosmos memiliki RU yang lebih tinggi saat kunci partisi ditentukan?

Answer 1

seperti komentar menentukan jika Anda menguji melalui portal (atau melalui kode, tetapi dengan kueri yang Anda berikan) itu akan menjadi lebih mahal, karena Anda tidak menanyakan partisi tertentu, tetapi menanyakan semuanya dan kemudian memperkenalkan filter lain, yang lebih mahal.

yang harus Anda lakukan - adalah menggunakan cara yang benar dalam kode untuk memasukkan kunci partisi. hasil saya cukup mengesankan: 3 ru \ s dengan PK dan 20.000 ru \ s tanpa PK, jadi saya cukup percaya diri dalam bekerja (saya memiliki kumpulan data yang sangat besar)