Bölüm anahtarını belirtirken Azure Cosmos sorguları neden daha yüksek RU'lara sahip?

Question

Ben benzer bir sorum var bu bir . Temel olarak, bölüm anahtarını kullanmanın farklı yollarını test ediyorum ve herhangi bir zamanda, bir sorguda bir bölüm anahtarına ne kadar çok başvurulursa, RU'ların o kadar yüksek olduğunu fark ettim. Oldukça tutarlıdır ve bölüm anahtarının nasıl kullanıldığı önemli değildir. Bu yüzden test için temel sorgulara indirgedim.

Başlangıç ​​olarak, bu veritabanında tümü 1KB'den büyük olan yaklaşık 850K belge vardır. Bölüm anahtarı, temelde sayı biçimindeki kimliğin 100 modülüdür, / partitionKey olarak ayarlanır ve kapsayıcı bir varsayılan dizin oluşturma politikası kullanır:

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

İşte temel sorgu testim:

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

Azure Cosmos dokümantasyon sorgusu istek "bölme anahtarı olmadan diyor dağılın tüm mantıksal bölümleri için". Bu nedenle, ilk sorgunun tek bir bölümü hedeflemesini ve ikincisinin hepsini hedeflemesini beklerim, yani ilk sorgu daha düşük RU'lara sahip olmalıdır. Sanırım RU sonuçlarını Cosmos'un her bir bölümü havalandırıp taramadığına ve belgelerin olması gerektiğini söylediği şeyle karşılaştırıp karşılaştırmadığına dair kanıt olarak kullanıyorum.

Bu sonuçların sadece 0.1 RU olduğunu biliyorum. Ama benim açımdan, sorgu ne kadar karmaşıksa, fark o kadar büyük. Örneğin, burada her zamankinden biraz daha karmaşık olan başka bir sorgu var:

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

RU'ların büyümeye ve bir bölüm anahtarı belirtmemekten ayrılmaya devam ettiğine dikkat edin. Bunun yerine, yukarıdaki sorgunun, tüm bölümlere yayıldığı varsayılan bölüm anahtarı kontrolüne kıyasla yalnızca iki bölümü hedeflemesini beklerdim.

Diğer filtrelerden sonra (veya her bölüm taramasında) bölüm anahtarı kontrolünün gerçekleştiğinden şüphelenmeye başlıyorum . Örneğin, ilk sorguya geri dönüp kimliği var olmayan bir şeye değiştirmek:

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

RU'ların tamamen aynı olduğuna ve her ikisinin de ( bölüm filtresine sahip olan dahil ) bir belgenin mevcut olduğu duruma göre daha az RU'ya sahip olduğuna dikkat edin . Bu, yayılmayı kısıtlamayan, sonuçlarda yürütülen bölüm filtresinin bir belirtisi gibi görünüyor. Ancak belgelerin söylediği bu değil.

Bir bölüm anahtarı belirtildiğinde Cosmos neden daha yüksek RU'lara sahip?

Answer 1

Yorumun portal üzerinden mi (veya kod aracılığıyla, ancak sağladığınız sorgu ile) test edip etmediğinizi belirttiği gibi, belirli bir bölümü sorgulamak yerine her şeyi sorgulamak ve ardından başka bir filtreyi tanıtmak daha pahalı hale gelecektir. daha masraflıdır.

bunun yerine yapmanız gereken - bölüm anahtarını geçmek için kodda doğru yolu kullanmaktır. Sonucum oldukça etkileyiciydi: PK ile 3 ru ve PK olmadan 20.000 ru, bu yüzden intworks'ten oldukça eminim (gerçekten büyük bir veri kümesine sahip oldum)