เหตุใดการสืบค้น Azure Cosmos จึงมี RU ที่สูงกว่าเมื่อระบุคีย์พาร์ติชัน

Question

ฉันมีคำถามคล้ายกับคนนี้ โดยทั่วไปฉันได้ทดสอบวิธีต่างๆในการใช้พาร์ติชันคีย์และสังเกตว่าเมื่อใดก็ตามยิ่งมีการอ้างอิงคีย์พาร์ติชันในแบบสอบถามมากเท่าใด RU ก็จะยิ่งสูงขึ้นเท่านั้น ค่อนข้างสอดคล้องกันและไม่สำคัญว่าจะใช้คีย์พาร์ติชันอย่างไร ดังนั้นฉันจึง จำกัด มันให้แคบลงเป็นแบบสอบถามพื้นฐานสำหรับการทดสอบ

ในการเริ่มต้นฐานข้อมูลนี้มีเอกสารประมาณ 850K เอกสารทั้งหมดมีขนาดมากกว่า 1KB คีย์พาร์ติชันนั้นโดยทั่วไปแล้ว 100 โมดูลัสของ id ในรูปแบบตัวเลขถูกตั้งค่าเป็น / partitionKey และคอนเทนเนอร์ใช้นโยบายการสร้างดัชนีเริ่มต้น:

{
    "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 ระบุว่าหากไม่มีคีย์พาร์ติชันแบบสอบถามจะ " ขยาย " ไปยังโลจิคัลพาร์ติชันทั้งหมด ดังนั้นฉันคาดหวังอย่างเต็มที่ว่าแบบสอบถามแรกจะกำหนดเป้าหมายพาร์ติชันเดียวและครั้งที่สองเพื่อกำหนดเป้าหมายทั้งหมดซึ่งหมายความว่าอันแรกควรมี RU ที่ต่ำกว่า ฉันคิดว่าฉันกำลังใช้ผลลัพธ์ RU เป็นหลักฐานว่า Cosmos กำลังพัดออกมาและสแกนแต่ละพาร์ติชันและเปรียบเทียบกับสิ่งที่เอกสารระบุว่าควรเกิดขึ้นหรือไม่

ฉันรู้ว่าผลลัพธ์เหล่านี้มีความแตกต่างเพียง 0.1 RU แต่ประเด็นของฉันคือยิ่งแบบสอบถามซับซ้อนมากเท่าไหร่ความแตกต่างก็ยิ่งมากขึ้นเท่านั้น ตัวอย่างเช่นนี่คือข้อความค้นหาอื่นที่ซับซ้อนกว่าเล็กน้อย:

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 ยังคงเติบโตและแยกออกจากการที่ไม่ได้ระบุคีย์พาร์ติชันเลย แต่ฉันคาดหวังว่าแบบสอบถามข้างต้นจะกำหนดเป้าหมายพาร์ติชันสองพาร์ติชันเท่านั้นเมื่อเทียบกับไม่มีการตรวจสอบคีย์พาร์ติชันซึ่งคาดว่าแฟน ๆ จะออกไปยังพาร์ติชันทั้งหมด

ฉันเริ่มสงสัยว่าการตรวจสอบคีย์พาร์ติชันเกิดขึ้นหลังจากตัวกรองอื่น ๆ (หรือภายในการสแกนแต่ละพาร์ติชัน) ตัวอย่างเช่นกลับไปที่แบบสอบถามแรก แต่เปลี่ยน id เป็นสิ่งที่ไม่มีอยู่:

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 นั้นเหมือนกันทุกประการและทั้งสองอย่าง (รวมถึงอันที่มีตัวกรองพาร์ติชัน) มี RU น้อยกว่าเมื่อมีเอกสารอยู่ นี่ดูเหมือนว่าจะเป็นอาการของตัวกรองพาร์ติชันที่ดำเนินการกับผลลัพธ์ไม่ได้ จำกัด การขยายสัญญาณออก แต่นี่ไม่ใช่สิ่งที่เอกสารระบุไว้

เหตุใด Cosmos จึงมี RU ที่สูงกว่าเมื่อระบุคีย์พาร์ติชัน

Answer 1

เช่นเดียวกับความคิดเห็นที่ระบุว่าคุณกำลังทดสอบผ่านพอร์ทัล (หรือผ่านรหัส แต่ด้วยแบบสอบถามที่คุณระบุ) จะมีราคาแพงกว่าเนื่องจากคุณไม่ได้สอบถามพาร์ติชันเฉพาะ แต่เป็นการสอบถามทุกอย่างแล้วแนะนำตัวกรองอื่นซึ่ง เป็นค่าใช้จ่ายที่มากขึ้น

สิ่งที่คุณควรทำแทน - ใช้วิธีที่เหมาะสมในรหัสเพื่อส่งผ่านในคีย์พาร์ติชัน ผลลัพธ์ของฉันค่อนข้างน่าประทับใจ: 3 ru \ s กับ PK และ 20.000 ru \ s ที่ไม่มี PK ดังนั้นฉันจึงค่อนข้างมั่นใจ intworks (ฉันมีชุดข้อมูลขนาดใหญ่มาก)