مشاركة عبر

استكشاف أخطاء الاستعلام وإصلاحها عند استخدام Azure Cosmos DB

  • مقالة

ينطبق على: NoSQL

توضح هذه المقالة نهجاً عاماً موصى به فيما يتعلق باستكشاف أخطاء الاستعلامات في Azure Cosmos DB وإصلاحها. وعلى الرغم من أنه ينبغي عليك عدم اعتبار الخطوات الموضّحة في هذه المقالة بمثابة حماية كاملة من مشكلات الاستعلام المحتملة، فقد أدرجنا بها نصائح الأداء الأكثر شيوعاً. يجب استخدام هذه المقالة كمكان بداية لاستكشاف أخطاء الاستعلامات البطيئة أو المكلفة وإصلاحها في Azure Cosmos DB ل NoSQL. يُمكنك أيضاً استخدام سجلات التشخيص لتحديد الاستعلامات البطيئة أو التي تستهلك كميات كبيرة من معدل النقل. إذا كنت تستخدم واجهة برمجة تطبيقات Azure Cosmos DB لنظام MongoDB، فينبغي عليك استخدام إرشاد استكشاف أخطاء استعلامات واجهة برمجة تطبيقات Azure Cosmos DB لنظام MongoDB وإصلاحها

يتم تصنيف تحسينات الاستعلام في Azure Cosmos DB بشكل عام على النحو التالي:

  • تحسينات تُقلل من تكلفة وحدة الطلب (RU) للاستعلام
  • تحسينات تُقلل من زمن الانتقال فقط

إذا قللت تكلفة وحدة الطلب لاستعلام ما، فسوف تقلل عادةً زمن الانتقال أيضاً.

تُقدم هذه المقالة أمثلة يمكنك إعادة إنشائها باستخدام مجموعة بيانات التغذية.

مشكلات حزمة SDK الشائعة

قبل قراءة هذا الإرشاد، من المفيد النظر في مشكلات حزمة SDK الشائعة التي لا تتعلق بمحرك الاستعلام.

  • اتبع نصائح أداء SDK في الاستعلام.
  • أحياناً قد يكون للاستعلامات صفحات فارغة حتى عندما تكون هناك نتائج على صفحة مستقبلية. قد تكون أسباب ذلك:
    • قد تجري حزمة SDK استدعاءات شبكة متعددة.
    • قد يستغرق الاستعلام وقتاً طويلاً لاسترداد المستندات.
  • تحتوي جميع الاستعلامات على رمز مميز للمتابعة سيُتيح للاستعلام المتابعة. تأكد من تفريغ الاستعلام تماماً. تعرّف على المزيد حول معالجة صفحات النتائج المتعددة

الحصول على مقاييس الاستعلام

عند تحسين استعلام في Azure Cosmos DB، تكون الخطوة الأولى دائماً هي الحصول على مقاييس الاستعلام لاستعلامك. تتوفر هذه المقاييس أيضاً عبر مدخل Microsoft Azure. بمجرد تشغيل استعلامك في مستكشف البيانات، تكون مقاييس الاستعلام ظاهرة بجوار علامة التبويب Results:

الحصول على مقاييس الاستعلام

بعد الحصول على مقاييس الاستعلام، قارن عدد المستندات التي تم استردادها بعدد مستندات الإخراج لاستعلامك. واستخدم هذه المقارنة لتحديد الأقسام ذات الصلة لمراجعتها في هذه المقالة.

عدد المستندات التي تم استردادها هو عدد المستندات التي يتعين على محرك الاستعلام تحميلها. عدد مستندات الإخراج هو عدد المستندات اللازمة لنتائج الاستعلام. إذا كان عدد المستندات التي تم استردادها أكبر بكثير من عدد مستندات الإخراج، فقد كان هناك جزء واحد على الأقل من استعلامك غير قادر على استخدام فهرس ويحتاج إلى إجراء فحص.

راجع الأقسام التالية لفهم تحسينات الاستعلام ذات الصلة للسيناريو الخاص بك.

تكلفة وحدة طلب الاستعلام مرتفعة جداً

عدد المستندات التي تم استردادها أكبر بكثير من عدد مستندات الإخراج


عدد المستندات التي تم استردادها يساوي تقريباً عدد مستندات الإخراج


تكلفة وحدة طلب الاستعلام مقبولة ولكن زمن الانتقال لا يزال مرتفعاً جداً

الاستعلامات التي يتجاوز فيها عدد المستندات التي تم استردادها عدد مستندات الإخراج

عدد المستندات التي تم استردادها هو عدد المستندات التي يتعين على محرك الاستعلام تحميلها. عدد مستندات الإخراج هو عدد المستندات التي تم إرجاعها بواسطة الاستعلام. إذا كان عدد المستندات التي تم استردادها أكبر بكثير من عدد مستندات الإخراج، فقد كان هناك جزء واحد على الأقل من استعلامك غير قادر على استخدام فهرس ويحتاج إلى إجراء فحص.

يرد فيما يلي مثال على استعلام المسح الضوئي الذي لم يتم تقديمه بالكامل من قبل الفهرس:

الاستعلام:

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

مقاييس الاستعلام:

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

عدد المستندات التي تم استردادها (60,951) أكبر بكثير من عدد مستندات الإخراج (7)، مما يعني أن هذا الاستعلام نتج عنه فحص ضوئي للمستند. في هذه الحالة، لا تستخدم وظيفة النظام UPPER() فهرساً.

تضمين المسارات الضرورية في نهج الفهرسة

ينبغي أن يشمل نهج الفهرسة أي خصائص مضمنة في عبارات WHERE، وعبارات ORDER BY، وJOIN، ومعظم وظائف النظام. وينبغي أن تتطابق المسارات المطلوبة المحددة في نهج الفهرس مع الخصائص الموجودة في مستندات JSON.

إشعار

تتسم الخصائص الموجودة في نهج الفهرسة Azure Cosmos DB بتحسس حالة الأحرف

إذا قمت بتشغيل الاستعلام البسيط التالي على مجموعة بيانات التغذية، سوف تلاحظ أن تكلفة وحدة الطلب تقل كثيراً عند فهرسة الخاصية بعبارة WHERE:

الأصل

الاستعلام:

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

نهج الفهرسة:

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

تكلفة وحدة الطلب: 409.51 وحدة طلب

المحسن

سياسة الفهرسة المحدثة:

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

تكلفة وحدة الطلب: 2.98 وحدة طلب

يُمكنك إضافة خصائص إلى نهج الفهرسة في أي وقت، دون أي تأثير على توافر الكتابة أو القراءة. يُمكنك تعقب التقدم المحرز في تحويل الفهرس.

فهم وظائف النظام التي تستخدم الفهرس

تستخدم معظم وظائف النظام الفهارس. ترد فيما يلي قائمة ببعض دالات السلسلة الشائعة التي تستخدم الفهارس:

  • StartsWith
  • يحتوي على
  • RegexMatch
  • اليسار
  • Substring - لكن فقط إذا كان أول num_expr يساوي 0

فيما يلي بعض وظائف النظام الشائعة التي لا تستخدم الفهرس ويجب تحميل كل مستند عند استخدامه بعبارة WHERE:

وظيفة النظام أفكار التحسين
Upper/Lower تقليل تكرار الغلاف عند الإدراج، بدلاً من استخدام وظيفة النظام لتقليل تكرار البيانات من أجل المقارنات. استعلام مثل SELECT * FROM c WHERE UPPER(c.name) = 'BOB' يصبح SELECT * FROM c WHERE c.name = 'BOB'.
GetCurrentDateTime/GetCurrentTimestamp/GetCurrentTicks حساب الوقت الحالي قبل تنفيذ الاستعلام واستخدام قيمة السلسلة بعبارة WHERE.
دالات رياضية (غير تجميعات) إذا كنت بحاجة لحساب قيمة بشكل متكرر في استعلامك، ففكر في تخزين القيمة باعتبارها خاصية في مستند JSON.

يُمكن أن تستخدم وظائف النظام هذه الفهارس، إلا عند استخدامها في الاستعلامات المتعلقة بالتجميعات:

وظيفة النظام أفكار التحسين
وظائف النظام المكانية تخزين نتيجة الاستعلام بطريقة عرض مجسدة في الوقت الحقيقي

لن تؤثر وظائف النظام غير الفعالة على كيفية استخدام الاستعلامات للفهارس، عند استخدامها بعبارة SELECT.

تحسين تنفيذ وظيفة نظام السلسلة

بالنسبة لبعض وظائف النظام التي تستخدم الفهارس، يُمكنك تحسين تنفيذ الاستعلام عن طريق إضافة عبارة ORDER BY إلى الاستعلام.

وبشكل أكثر تحديداً، قد تستفيد أي وظيفة نظام تزيد تكلفة وحدة الطلب بها عندما تزيد العلاقة الأساسية للخاصية من وجود ORDER BY في الاستعلام. تُجري هذه الاستعلامات فحصاً ضوئياً للفهرس، لذا فإن فرز نتائج الاستعلام يُمكن أن يجعل الاستعلام أكثر كفاءة.

يُمكن أن يُعزز هذا التحسين تنفيذ وظائف النظام التالية:

  • StartsWith (عندما يكون عدم تحسس حالة الأحرف = صواب)
  • StringEquals (عندما يكون عدم تحسس حالة الأحرف = صواب)
  • يحتوي على
  • RegexMatch
  • EndsWith

على سبيل المثال، تأمل الاستعلام الوارد أدناه الذي يستخدم CONTAINS. سوف تستخدم CONTAINS الفهارس ولكن في بعض الأحيان، حتى بعد إضافة الفهرس ذي الصلة، قد لا تزال تلاحظ ارتفاع تكلفة وحدة الطلب للغاية عند تشغيل الاستعلام الوارد أدناه.

الاستعلام الأصلي:

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

يُمكنك تحسين تنفيذ الاستعلام بإضافة ORDER BY:

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

يُمكن أن يساعد التحسين نفسه في الاستعلامات باستخدام عوامل تصفية إضافية. في هذه الحالة، من الأفضل أيضاً إضافة خصائص مع عوامل تصفية المساواة إلى عبارة ORDER BY.

الاستعلام الأصلي:

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

يُمكنك تحسين تنفيذ الاستعلام عن طريق إضافة ORDER BY ومؤشر مُركَّب إلى (c.name، c.town):

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

فهم مجموع الاستعلامات التي تستخدم الفهرس

في معظم الحالات، سوف تستخدم وظائف النظام التجميعية في Azure Cosmos DB الفهرس. ومع ذلك، استناداً إلى عوامل التصفية أو العبارات الإضافية في استعلام تجميعي، قد يلزم وجود محرك الاستعلام لتحميل عددٍ كبيرٍ من المستندات. بشكل عام، سيُطبق محرك الاستعلام عوامل تصفية النطاق والمساواة أولاً. بعد تطبيق عوامل التصفية هذه، يُمكن لمحرك الاستعلام تقييم عوامل التصفية الإضافية واللجوء إلى تحميل المستندات المتبقية لحساب التجميع، إذا لزم الأمر.

على سبيل المثال، بالنظر إلى هاتين العينتين من الاستعلامات، سيكون الاستعلام باستخدام كل من عامل التصفية وظيفة النظام CONTAINS والمساواة بوجه عام أكثر كفاءة من الاستعلام باستخدام عامل التصفية وظيفة النظام CONTAINS فحسب. وذلك بسبب تطبيق عامل التصفية المساواة أولاً واستخدامه الفهرس قبل أن يتعين تحميل المستندات لعامل التصفية CONTAINS الأكثر تكلفة.

الاستعلام باستخدام عامل التصفية CONTAINS فقط - تكلفة أعلى لوحدة الطلب:

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

الاستعلام باستخدام كل من عامل التصفية المساواة وعامل التصفية CONTAINS - تكلفة أقل لوحدة الطلب:

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

ترد فيما يلي أمثلة إضافية للاستعلامات التجميعية التي لن تستخدم الفهرس بالكامل:

الاستعلامات باستخدام وظائف النظام التي لا تستخدم الفهرس

ينبغي عليك الرجوع إلى صفحة وظيفة النظام ذات الصلة لمعرفة إذا ما كانت تستخدم الفهرس.

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

الاستعلامات التجميعية باستخدام الدالات المُعرّفة من قبل المستخدم (UDF)

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

الاستعلامات باستخدام GROUP BY

سوف تزيد تكلفة وحدة الطلب للاستعلامات باستخدام GROUP BY مع زيادة العلاقة الأساسية للخصائص في عبارة GROUP BY. في الاستعلام الوارد أدناه، على سبيل المثال، سوف تزيد تكلفة وحدة الطلب للاستعلام مع زيادة عدد الأوصاف الفريدة.

ستكون تكلفة وحدة الطلب لوظيفة تجميعية مع عبارة GROUP BY أعلى من تكلفة وحدة الطلب لوظيفة تجميعية فقط. في هذا المثال، يجب تحميل محرك الاستعلام كل مستند يطابق عامل التصفية c.foodGroup = "Sausages and Luncheon Meats" بحيث يكون من المتوقع ارتفاع تكلفة وحدة الطلب.

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

إذا كنت تُخطط لتشغيل نفس الاستعلامات التجميعية بشكل متكرر، قد يكون إنشاء طريقة عرض مجسدة في الوقت الحقيقي باستخدام موجز تغيير Azure Cosmos DB أكثر كفاءة من تشغيل الاستعلامات الفردية.

تحسين الاستعلامات التي تحتوي على كلٍ من عامل تصفية وعبارة ORDER BY

على الرغم من أن الاستعلامات التي تحتوي على عامل تصفية وعبارة ORDER BY عادةً ما ستستخدم مؤشر نطاق، فإنها ستكون أكثر كفاءة إذا كان يُمكن تقديمها من مؤشر مُركَّب. وبالإضافة إلى تعديل نهج الفهرسة، ينبغي عليك إضافة جميع الخصائص في المؤشر المُركَّب إلى عبارة ORDER BY. سيضمن هذا التغيير في الاستعلام أنه يستخدم المؤشر المُركَّب. يُمكنك ملاحظة التأثير عن طريق تشغيل استعلام على مجموعة بيانات التغذية:

الأصل

الاستعلام:

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

نهج الفهرسة:

{

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

تكلفة وحدة الطلب: 44.28 وحدة طلب

المحسن

الاستعلام المُحدَّث (يتضمن كلتا الخاصيتين في عبارة ORDER BY):

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

سياسة الفهرسة المحدثة:

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

تكلفة وحدة الطلب: 8.86 وحدة طلب

تحسين تعبيرات JOIN باستخدام استعلام فرعي

يُمكن تحسين الاستعلامات الفرعية متعددة القيم لتعبيرات JOIN عن طريق دفع دالات التقييم بعد كل تعبير select-many وليس بعد جميع الصلات المشتركة في عبارة WHERE.

تأمل هذا الاستعلام:

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

تكلفة وحدة الطلب: 167.62 وحدة طلب

بالنسبة لهذا الاستعلام، سيُطابق الفهرس أي مستند يحتوي على علامة تحمل اسم infant formula، وتكون nutritionValue أكبر من 0، وamount أكبر من 1. سينفذ تعبير JOIN هنا المنتج المتقاطع لجميع عناصر العلامات، والعناصر الغذائية وحصص الصفائف لكل مستند مطابق قبل تطبيق أي عامل تصفية. ثم ستُطبق عبارة WHERE دالة تقييم عامل التصفية على كل مجموعة من مجموعات <c, t, n, s>.

على سبيل المثال، إذا كان مستند مطابق يحتوي على 10 عناصر في كل من الصفائف الثلاثة، سيتم توسيعه إلى 1 × 10 × 10 × 10 (أي، 1,000) مجموعة. يُمكن أن يُساعد استخدام الاستعلامات الفرعية هنا على تصفية عناصر الصفيف المرتبطة قبل الانضمام إلى التعبير التالي.

هذا الاستعلام مكافئ إلى الاستعلام السابق ولكنه يستخدم الاستعلامات الفرعية:

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)

تكلفة وحدة الطلب: 22.17 وحدة طلب

افترض أن عنصراً واحداً فقط في صفيف العلامات يُطابق عامل التصفية وأن هناك خمسة عناصر لكل من العناصر الغذائية وحصص الصفائف. سيتم توسيع تعبيرات JOIN إلى 1 × 1 × 5 × 5 = 25 عنصراً، مقابل 1,000 عنصر في الاستعلام الأول.

الاستعلامات التي يتساوى فيها عدد المستندات التي تم استردادها مع عدد مستندات الإخراج

إذا كان عدد المستندات التي تم استردادها مساوياً تقريباً لعدد مستندات الإخراج، فلن يضطر محرك الاستعلام إلى مسح العديد من المستندات غير الضرورية ضوئياً. بالنسبة للعديد من الاستعلامات، مثل الاستعلامات التي تستخدم الكلمة الأساسية TOP، قد يتجاوز عدد المستندات التي تم استردادها عدد مستندات الإخراج بمقدار 1. لا داعي للقلق بشأن هذا.

تصغير الاستعلامات عبر الأقسام

تستخدم Azure Cosmos DB التقسيم لتغيير حجم الحاويات الفردية عندما يتعين زيادة وحدة الطلب وتخزين البيانات. يحتوي كل قسم فعلي على فهرس منفصل ومستقل. إذا كان استعلامك يحتوي على أحد عوامل تصفية المساواة التي تُطابق مفتاح تقسيم الحاوية، فسيتعين عليك التحقق من فهرس القسم ذي الصلة فقط. يقلل هذا التحسين العدد الإجمالي لوحدات الطلب الذي يتطلب الاستعلام.

إذا كان لديك عدد كبير من وحدات الطلب المتوفرة (أكثر من 30,000) أو كمية كبيرة من البيانات المخزنة (أكثر من 100 غيغابايت تقريباً)، فمن المحتمل أن تكون لديك حاوية كبيرة بما يكفي لرؤية انخفاض كبير في تكاليف وحدة طلب الاستعلام.

على سبيل المثال، إذا قمت بإنشاء حاوية باستخدام مفتاح التقسيم foodGroup، سيتعين أن تتحقق الاستعلامات التالية من قسم فعلي واحد فقط:

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

الاستعلامات التي تحتوي على عامل تصفية IN مع مفتاح التقسيم سوف تحقق فقط من القسم (الأقسام) الفعلي ذي الصلة ولن "توزع المهام إلى عدة وجهات":

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

الاستعلامات التي تحتوي على عوامل تصفية النطاق على مفتاح التقسيم، أو التي لا تحتوي على أي عوامل تصفية على مفتاح التقسيم، سيتعين أن "توزع المهام إلى عدة وجهات" وتتحقق من فهرس كل قسم فعلي للحصول على النتائج:

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"

تحسين الاستعلامات التي تحتوي على عوامل تصفية على الخصائص المتعددة

على الرغم من أن الاستعلامات التي تحتوي على عوامل تصفية على الخصائص المتعددة عادةً ما ستستخدم مؤشر نطاق، فإنها ستكون أكثر كفاءة إذا كان يُمكن تقديمها من مؤشر مُركَّب. بالنسبة لكميات البيانات الصغيرة، لن يكون لهذا التحسين تأثير كبير. ومع ذلك، قد يكون مفيداً بالنسبة لكميات البيانات الكبيرة. لا يمكنك سوى تحسين عامل تصفية واحد غير مستند إلى المساواة لكل مؤشر مُركَّب على أقصى تقدير. إذا كان استعلامك يحتوي على عوامل تصفية متعددة غير مستندة إلى المساواة، اختر واحداً منها سيستخدم المؤشر المُركَّب. وسيواصل بقية عوامل التصفية استخدام فهارس النطاق. يجب تحديد عامل التصفية غير المستند إلى المساواة أخيراً في المؤشر المُركَّب. تعرَّف على المزيد حول المؤشرات المُركَّبة.

فيما يلي بعض الأمثلة على الاستعلامات التي يُمكن تحسينها باستخدام مؤشر مُركَّب:

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

فيما يلي المؤشر المُركَّب ذو الصلة:

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

تحسينات تُقلل من زمن انتقال الاستعلام

في كثير من الحالات، قد تكون تكلفة وحدة الطلب مقبولة عندما يكون زمن انتقال الاستعلام مرتفعاً جداً. تعرض الأقسام التالية نظرة عامة عن تلميحات لتقليل زمن انتقال الاستعلام. في حالة تشغيل الاستعلام نفسه عدة مرات في مجموعة البيانات نفسها، عادةً ما تكون تكلفة وحدة الطلب هي نفسها في كل مرة. ولكن قد يختلف زمن انتقال الاستعلام بين عمليات تنفيذ الاستعلام.

تحسين التقارب

سيكون زمن انتقال الاستعلامات التي تُشغَل من منطقة مختلفة عن حساب Azure Cosmos DB أعلى من زمن انتقال الاستعلامات التي تُشغَل داخل المنطقة نفسها. على سبيل المثال، في حالة تشغيل تعليمة برمجية على كمبيوتر سطح المكتب، ينبغي أن تتوقع أن يكون زمن الانتقال أعلى بعشرات أو مئات المللي ثانية (أو أكثر) من زمن انتقال الاستعلام الصادر من جهاز ظاهري داخل منطقة Azure نفسها لخدمة Azure Cosmos DB. إن توزيع البيانات بشكل عمومي في Azure Cosmos DB لضمان إمكانية نقل بياناتك إلى تطبيقك أمر سهل.

زيادة معدل النقل المتوفر

في Azure Cosmos DB، يُقاس معدل النقل المخصص بوحدات الطلب (RU). تخيل أن لديك استعلاماً يستهلك 5 وحدات طلب من معدل النقل. على سبيل المثال، في حالة توفير 1000 وحدة طلب، يُمكنك تشغيل هذا الاستعلام 200 مرة في الثانية. إذا حاولت تشغيل الاستعلام في حالة عدم توفر معدل نقل كافٍ، فسترجع Azure Cosmos DB 429 خطأً في بروتوكول نقل النص التشعبي. سيعيد أي من واجهة برمجة التطبيقات الحالية ل NoSQL SDKs محاولة هذا الاستعلام تلقائيا بعد الانتظار لفترة قصيرة. تستغرق الطلبات المقيدة وقتاً أطول، لذا يُمكن أن تؤدّي زيادة معدل النقل المتوفر إلى تحسين زمن انتقال الاستعلام. يُمكنك مراقبة العدد الإجمالي للطلبات المقيدة على جزء مقاييس مدخل Microsoft Azure.

زيادة MaxConcurrency

تعمل الاستعلامات المتوازية عن طريق الاستعلام عن أقسام متعددة بالتوازي. ولكن يتم إحضار البيانات من مجموعة مقسّمة فردية بشكل تسلسلي فيما يتعلق بالاستعلام. لذلك، إذا قمت بتعيين MaxConcurrency إلى عدد الأقسام، يكون لديك أفضل فرصة لتحقيق الاستعلام الأكثر أداءً، شريطةً أن تظل جميع شروط النظام الأخرى كما هي. إذا كنت لا تعرف عدد الأقسام، يُمكنك تعيين MaxConcurrency (أو MaxDegreesOfParallelism في إصدارات حزمة SDK الأقدم) إلى رقم مرتفع. سيختار النظام الحد الأدنى (عدد الأقسام، الإدخالات المُقدمة من قِبل المستخدم) باعتباره أقصى درجة للتوازي.

زيادة MaxBufferedItemCount

صُممت الاستعلامات للإحضار المسبق للنتائج أثناء معالجة الدُفعة الحالية من النتائج من قِبل العميل. يساعد الإحضار المسبق على تحسين إجمالي زمن انتقال استعلام ما. يؤدّي إعداد MaxBufferedItemCount إلى الحد من عدد النتائج التي تم إحضارها مسبقاً. إذا قمت بتعيين هذه القيمة إلى العدد المتوقع من النتائج التي تم إرجاعها (أو رقم أعلى)، يُمكن للاستعلام أن يحصل على أقصى استفادة من الإحضار المسبق. إذا قمت بتعيين هذه القيمة إلى -1، سيُحدد النظام تلقائياً عدد العناصر لتخزينها مؤقتاً.

الخطوات التالية

راجع المقالات التالية للحصول على معلومات حول كيفية قياس وحدات الطلب لكل استعلام، والحصول على إحصائيات التنفيذ لضبط استعلاماتك، وغير ذلك المزيد: