विभाजन कुंजी को निर्दिष्ट करते समय Azure Cosmos के प्रश्नों में उच्च RU क्यों होता है?

Question

मैं एक सवाल के समान है इस एक । मूल रूप से, मैं विभाजन कुंजी का उपयोग करने के लिए विभिन्न तरीकों का परीक्षण कर रहा हूं, और ध्यान दिया है कि किसी भी समय, विभाजन की कुंजी को क्वेरी में संदर्भित किया जाता है, आरयू जितना अधिक होता है। यह काफी सुसंगत है, और यह भी मायने नहीं रखता है कि विभाजन कुंजी का उपयोग कैसे किया जाता है। इसलिए मैंने इसे परीक्षण के लिए बुनियादी प्रश्नों तक सीमित कर दिया।

शुरू करने के लिए, इस डेटाबेस में लगभग 850K दस्तावेज़ हैं, सभी आकार में 1KB से अधिक हैं। विभाजन कुंजी मूल रूप से संख्या के रूप में आईडी का एक 100 मापांक है, / विभाजन के लिए सेट है, और कंटेनर एक डिफ़ॉल्ट अनुक्रमणिका नीति का उपयोग करता है:

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

यहाँ मेरा मूल प्रश्न परीक्षण है:

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 प्रलेखन कहता है कि विभाजन कुंजी के बिना, क्वेरी सभी तार्किक विभाजनों के लिए " फैन आउट " होगी। इसलिए मुझे पूरी उम्मीद होगी कि पहली क्वेरी एक ही पार्टीशन को टारगेट करेगी और दूसरा इन सभी को टारगेट करने के लिए, मतलब पहले वाले को कम यूयू करना चाहिए। मुझे लगता है कि मैं आरयू परिणामों का उपयोग इस बात के प्रमाण के रूप में कर रहा हूं कि क्या कॉसमॉस बाहर विभाजन और प्रत्येक विभाजन को स्कैन कर रहा है या नहीं, और इसकी तुलना यह है कि प्रलेखन क्या होना चाहिए।

मुझे पता है कि ये परिणाम अंतर में सिर्फ 0.1 आरयू हैं। लेकिन मेरी बात क्वेरी जितनी जटिल है, अंतर उतना ही बड़ा है। उदाहरण के लिए, यहां एक और प्रश्न कभी इतना अधिक जटिल है:

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

ध्यान दें कि आरयू लगातार बढ़ता जा रहा है और एक विभाजन कुंजी निर्दिष्ट नहीं होने से अलग है। इसके बजाय मैं उपरोक्त क्वेरी को केवल दो विभाजनों को लक्षित करने की अपेक्षा करूंगा, जिसकी तुलना में कोई विभाजन कुंजी जांच नहीं होगी, जो सभी विभाजनों के प्रशंसक हों।

मुझे संदेह है कि विभाजन कुंजी की जांच अन्य फिल्टर (या प्रत्येक विभाजन स्कैन के अंदर) के बाद हो रही है । उदाहरण के लिए, पहली क्वेरी पर वापस जा रहे हैं लेकिन आईडी को ऐसी चीज़ में बदलना जो मौजूद नहीं है:

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

ध्यान दें कि आरयू बिल्कुल समान हैं, और दोनों ( विभाजन फ़िल्टर के साथ एक सहित ) में दस्तावेज़ मौजूद होने की तुलना में कम आरयू हैं। ऐसा लगता है कि यह विभाजन के फिल्टर का एक लक्षण होगा जो परिणामों पर निष्पादित किया जा सकता है, न कि एक प्रशंसक-आउट को प्रतिबंधित करना। लेकिन यह नहीं है कि प्रलेखन क्या कहता है।

जब एक विभाजन कुंजी निर्दिष्ट की जाती है तो कॉस्मॉस के पास उच्च आरयू क्यों होता है?

Answer 1

जैसे टिप्पणी निर्दिष्ट करती है यदि आप पोर्टल के माध्यम से परीक्षण कर रहे हैं (या कोड के माध्यम से, लेकिन आपके द्वारा प्रदान की गई क्वेरी के साथ) तो यह और अधिक महंगा हो जाएगा, क्योंकि आप एक विशिष्ट विभाजन को क्वेरी नहीं कर रहे हैं, बल्कि सब कुछ क्वेरी कर रहे हैं और फिर एक और फिल्टर शुरू कर रहे हैं, जो अधिक खर्च है।

आपको इसके बजाय क्या करना चाहिए - विभाजन कुंजी में पास करने के लिए कोड में उचित तरीके का उपयोग करें। मेरा परिणाम काफी प्रभावशाली था: PK के साथ 3 ru \ s और PK के बिना 20.000 ru \ s, इसलिए मैं काफी आत्मविश्वासी हूं