نصائح بخصوص أداء الاستعلام لـ Azure Cosmos DB SDKS
ينطبق على: 
NoSQL
Azure Cosmos DB عبارة عن قاعدة بيانات سريعة ومرنة موزعة تتوسع بسلاسة مع مستويات إنتاجية وزمن وصول مضمونة. لا يتعين عليك إجراء تغييرات هيكلية كبيرة أو كتابة تعليمات برمجية معقدة لتوسيع نطاق قاعدة البيانات باستخدام Azure Cosmos DB. يُعد توسيع النطاق وتقليصه أمراً سهلاً مثل استدعاء واجهة برمجة التطبيقات للنظام. لمعرفة مزيد، راجع توفير معدل نقل الحاوية أو توفير معدل نقل قاعدة البيانات.
تقليل مكالمات خطة الاستعلام
لتنفيذ استعلام، يجب إنشاء خطة استعلام. يمثل هذا بوجهٍ عام طلب شبكة إلى Azure Cosmos DB Gateway، مما يضيف إلى زمن انتقال عملية الاستعلام. هناك طريقتان لإزالة هذا الطلب وتقليل زمن انتقال عملية الاستعلام:
تحسين استعلامات القسم الواحد مع التنفيذ المباشر المتفائل
يحتوي Azure Cosmos DB NoSQL على تحسين يسمى التنفيذ المباشر المتفائل (ODE)، والذي يمكن أن يحسن كفاءة بعض استعلامات NoSQL. على وجه التحديد، تتضمن الاستعلامات التي لا تتطلب التوزيع تلك التي يمكن تنفيذها على قسم فعلي واحد أو التي تحتوي على استجابات لا تتطلب ترقيم الصفحات. يمكن للاستعلامات التي لا تتطلب التوزيع تخطي بعض العمليات بثقة، مثل إنشاء خطة الاستعلام من جانب العميل وإعادة كتابة الاستعلام، وبالتالي تقليل زمن انتقال الاستعلام وتكلفة RU. إذا حددت مفتاح القسم في الطلب أو الاستعلام نفسه (أو كان لديك قسم فعلي واحد فقط)، ولا تتطلب نتائج الاستعلام ترقيم الصفحات، فيمكن ل ODE تحسين الاستعلامات الخاصة بك.
إشعار
يجب عدم الخلط بين التنفيذ المباشر المتفائل (ODE)، الذي يوفر أداء محسنا للاستعلامات التي لا تتطلب التوزيع، مع الوضع المباشر، وهو مسار لتوصيل التطبيق الخاص بك بالنسخ المتماثلة الخلفية.
يتوفر ODE الآن في الإصدار 3.38.0 من .NET SDK والإصدارات الأحدث. عند تنفيذ استعلام وتحديد مفتاح قسم في الطلب أو الاستعلام نفسه، أو تحتوي قاعدة البيانات الخاصة بك على قسم فعلي واحد فقط، يمكن أن يستفيد تنفيذ الاستعلام من فوائد ODE. لتمكين ODE، قم بتعيين EnableOptimisticDirectExecution إلى true في QueryRequestOptions.
يمكن أن تستفيد استعلامات القسم الفردي التي تتميز بدالات GROUP BY و ORDER BY و DISTINCT والتجميع (مثل المجموع والمتوسط والحد الأدنى والحد الأقصى) بشكل كبير من استخدام ODE. ومع ذلك، في السيناريوهات التي يستهدف فيها الاستعلام أقساما متعددة أو لا يزال يتطلب ترقيم الصفحات، قد يكون زمن انتقال استجابة الاستعلام وتكلفة RU أعلى من دون استخدام ODE. لذلك، عند استخدام ODE، نوصي بما يلي:
- حدد مفتاح القسم في الاستدعاء أو الاستعلام نفسه.
- تأكد من أن حجم البيانات لم ينمو وتسبب في تقسيم القسم.
- تأكد من أن نتائج الاستعلام لا تتطلب ترقيم الصفحات للحصول على الفائدة الكاملة من ODE.
فيما يلي بعض الأمثلة على استعلامات القسم الفردية البسيطة التي يمكن أن تستفيد من ODE:
- SELECT * FROM r
- SELECT * FROM r WHERE r.pk == "value"
- SELECT * FROM r WHERE r.id > 5
- SELECT r.id FROM r JOIN id IN r.id
- SELECT TOP 5 r.id FROM r ORDER BY r.id
- SELECT * FROM r WHERE r.id > 5 OFFSET 5 LIMIT 3
قد تكون هناك حالات قد تتطلب فيها استعلامات القسم الواحد التوزيع إذا زاد عدد عناصر البيانات بمرور الوقت وتقسيم قاعدة بيانات Azure Cosmos DB للقسم. تتضمن أمثلة الاستعلامات التي يمكن أن يحدث فيها ذلك ما يلي:
- SELECT Count(r.id) AS count_a FROM r
- SELECT DISTINCT r.id FROM r
- SELECT Max(r.a) as min_a FROM r
- SELECT Avg(r.a) as min_a FROM r
- SELECT Sum(r.a) as sum_a FROM r WHERE r.a > 0
يمكن أن تتطلب بعض الاستعلامات المعقدة دائما التوزيع، حتى إذا كانت تستهدف قسما واحدا. ومن أمثلة هذه الاستعلامات ما يلي:
- SELECT Sum(id) as sum_id FROM r JOIN id IN r.id
- SELECT DISTINCT r.id FROM r GROUP BY r.id
- SELECT DISTINCT r.id, Sum(r.id) as sum_a FROM r GROUP BY r.id
- SELECT Count(1) FROM (SELECT DISTINCT r.id FROM root r)
- SELECT Avg(1) AS avg FROM root r
من المهم ملاحظة أن ODE قد لا يسترد دائما خطة الاستعلام، ونتيجة لذلك، غير قادر على عدم السماح بالاستعلامات غير المدعومة أو إيقاف تشغيلها. على سبيل المثال، بعد تقسيم القسم، لم تعد هذه الاستعلامات مؤهلة ل ODE، وبالتالي، لن يتم تشغيلها لأن تقييم خطة الاستعلام من جانب العميل سيمنعها. لضمان التوافق/استمرارية الخدمة، من الضروري التأكد من استخدام الاستعلامات المدعومة بالكامل فقط في السيناريوهات بدون ODE (أي تنفيذها وإنتاج النتيجة الصحيحة في حالة الأقسام المتعددة العامة) مع ODE.
إشعار
يمكن أن يؤدي استخدام ODE إلى إنشاء نوع جديد من رمز المتابعة المميز. لا يتم التعرف على مثل هذا الرمز المميز من قبل SDKs القديمة حسب التصميم وقد يؤدي هذا إلى استثناء رمز متابعة غير صحيح. إذا كان لديك سيناريو حيث يتم استخدام الرموز المميزة التي تم إنشاؤها من SDKs الأحدث بواسطة SDK أقدم، نوصي باتباع نهج خطوتين للترقية:
- قم بالترقية إلى SDK الجديد وتعطيل ODE، وكلاهما معا كجزء من عملية نشر واحدة. انتظر حتى يتم ترقية كافة العقد.
- لتعطيل ODE، قم بتعيين EnableOptimisticDirectExecution إلى false في QueryRequestOptions.
- تمكين ODE كجزء من النشر الثاني لجميع العقد.
استخدام إنشاء خطة استعلام محلية
يتضمن SQL SDK ServiceInterop.dll أصلي لتحليل الاستعلامات وتحسينها محلياً. يتم دعم ServiceInterop.dll فقط على النظام الأساسي Windows x64. تستخدم الأنواع التالية من التطبيقات معالجة مضيف 32 بت بشكل افتراضي. لتغيير معالجة المضيف إلى معالجة 64 بت، اتبع هذه الخطوات، حسب نوع التطبيق المستخدم:
بالنسبة للتطبيقات القابلة للتنفيذ، يمكنك تغيير معالجة المضيف عن طريق تعيين هدف النظام الأساسي إلى x64 في نافذة خصائص المشروع، في علامة التبويب البنية.
بالنسبة لمشروعات الاختبار المستندة إلى VSTest، يمكنك تغيير معالجة المضيف عن طريق تحديد اختبار>إعدادات الاختبار>بنية المعالج الافتراضية مثل X64 في قائمة الاختبار في Visual Studio.
بالنسبة لتطبيقات الويب ASP.NET المُستخدمة محليًّا، يمكنك تغيير معالجة المضيف عن طريق تحديد استخدام الإصدار 64 بت من IIS Express لمواقع الويب والمشروعات ضمن الأدوات>الخيارات>المشروعات والحلول>مشروعات الويب.
بالنسبة لتطبيقات الويب ASP.NET المُستخدمة على Azure، يمكنك تغيير معالجة المضيف عن طريق تحديد النظام الأساسي 64 بت في إعدادات التطبيق في مدخل Azure.
إشعار
تُعيَن مشروعات Visual Studio الجديدة على أي وحدة معالجة مركزية افتراضياً. نوصي بتعيين مشروعك على x64 حتى لا يتحول إلى x86. يمكن أن يتحول مشروع معين على أي وحدة معالجة مركزية بسهولة إلى x86 في حالة إضافة تبعية x86 فقط.
يجب أن يكون ServiceInterop.dll في المجلد الذي يُنفَذ SDK DLL منه. لا ينبغي القلق بشأن هذا إلا في حالة نسخ ملفات DLL يدويًّا، أو وجود أنظمة إنشاء/استخدام مخصصة فقط.
استخدام استعلامات قسم واحد
بالنسبة للاستعلامات التي تستهدف مفتاح القسم عن طريق تعيين الخاصية PartitionKey في QueryRequestOptions ولا تحتوي على تجميعات (بما في ذلك Distinct وDCount وGroup By). في هذا المثال، تتم تصفية حقل مفتاح القسم الخاص /state بالقيمة Washington.
using (FeedIterator<MyItem> feedIterator = container.GetItemQueryIterator<MyItem>(
"SELECT * FROM c WHERE c.city = 'Seattle' AND c.state = 'Washington'"
{
// ...
}
اختياريا، يمكنك توفير مفتاح القسم كجزء من كائن خيارات الطلب.
using (FeedIterator<MyItem> feedIterator = container.GetItemQueryIterator<MyItem>(
"SELECT * FROM c WHERE c.city = 'Seattle'",
requestOptions: new QueryRequestOptions() { PartitionKey = new PartitionKey("Washington")}))
{
// ...
}
هام
على العملاء الذين يقومون بتشغيل نظام تشغيل غير Windows، مثل Linux وMacOS، يجب تحديد مفتاح القسم دائما في عنصر خيارات الطلب.
إشعار
تتطلب الاستعلامات عبر الأقسام SDK لزيارة جميع الأقسام الموجودة للتحقق من النتائج. كلما زادت الأقسام المادية التي تحتوي عليها الحاوية، كان من المحتمل أن تكون أبطأ.
تجنب إعادة إنشاء المكرر دون داعٍ
عندما يستهلك المكون الحالي جميع نتائج الاستعلام، فلن تحتاج إلى إعادة إنشاء المكرر مع استمرار كل صفحة. يُفضل دائماً استنزاف الاستعلام بالكامل ما لم يتم التحكم في ترقيم الصفحات بواسطة مكون استدعاء آخر:
using (FeedIterator<MyItem> feedIterator = container.GetItemQueryIterator<MyItem>(
"SELECT * FROM c WHERE c.city = 'Seattle'",
requestOptions: new QueryRequestOptions() { PartitionKey = new PartitionKey("Washington")}))
{
while (feedIterator.HasMoreResults)
{
foreach(MyItem document in await feedIterator.ReadNextAsync())
{
// Iterate through documents
}
}
}
ضبط درجة التوازي
بالنسبة إلى الاستعلامات، اضبط الخاصية MaxConcurrency في QueryRequestOptions لتحديد أفضل التكوينات لتطبيقك، خاصةً إذا كنت تجري استعلامات عبر الأقسام (دون عامل تصفية على قيمة مفتاح القسم). MaxConcurrency يتحكم في الحد الأقصى لعدد المهام المتوازية، أي الحد الأقصى من الأقسام التي يجب زيارتها على نحوٍ متوازٍ. سيؤدي تعيين القيمة إلى -1 إلى السماح لـ SDK بتحديد التزامن الأمثل.
using (FeedIterator<MyItem> feedIterator = container.GetItemQueryIterator<MyItem>(
"SELECT * FROM c WHERE c.city = 'Seattle'",
requestOptions: new QueryRequestOptions() {
PartitionKey = new PartitionKey("Washington"),
MaxConcurrency = -1 }))
{
// ...
}
لنفترض أن
- D = الحد الأقصى الافتراضي لعدد المهام المتوازية (= العدد الإجمالي لوحدات المعالجة في جهاز العميل)
- P = العدد الأقصى المحدد من قبل المستخدم للمهام المتوازية
- N = عدد الأقسام التي يجب زيارتها للإجابة عن استعلام
فيما يلي الآثار المترتبة على كيفية تصرف الاستعلامات المتوازية مع القيم المختلفة لـ P.
- (P == 0) => Serial Mode
- (P == 1) => مهمة واحدة كحد أقصى
- (P > 1) => Min (P، N) مهام متوازية
- (P < 1) => المهام الموازية (N، D) كحد أدنى
ضبط حجم الصفحة
عند إصدار استعلام SQL، يتم إرجاع النتائج بطريقة مجزأة إذا كانت مجموعة النتائج كبيرة جداً.
إشعار
يجب عدم استخدام الخاصية MaxItemCount فقط لفصل الصفحات. استخدامها الرئيسي هو تحسين أداء الاستعلامات عن طريق تقليل الحد الأقصى لعدد العناصر التي تُعرَض في صفحة واحدة.
يمكنك أيضاً تعيين حجم الصفحة باستخدام أدوات SDK لـ Azure Cosmos DB المتوفرة. تسمح لك الخاصية MaxItemCount في QueryRequestOptions بتعيين الحد الأقصى لعدد العناصر التي تنتج في عملية التعداد. عند ضبط MaxItemCount على -1، تعثر أداة SDK تلقائياً على القيمة المثلى، اعتماداً على حجم المستند. على سبيل المثال:
using (FeedIterator<MyItem> feedIterator = container.GetItemQueryIterator<MyItem>(
"SELECT * FROM c WHERE c.city = 'Seattle'",
requestOptions: new QueryRequestOptions() {
PartitionKey = new PartitionKey("Washington"),
MaxItemCount = 1000}))
{
// ...
}
عند تنفيذ استعلام، تُرسَل البيانات الناتجة ضمن حزمة TCP. إذا حددت قيمة منخفضة جداً لـ MaxItemCount، فإن عدد الانتقالات المطلوبة لإرسال البيانات في داخل حزمة TCP يكون مرتفعاً، وهو ما يؤثر في الأداء. لذلك إذا لم تكن متأكداً من القيمة التي يجب تعيينها للخاصية MaxItemCount، فمن الأفضل تعيينها على -1 والسماح لـ SDK باختيار القيمة الافتراضية.
ضبط حجم المخزن المؤقت
صُمِم الاستعلام الموازي لجلب النتائج مسبقاً في أثناء معالجة العميل لمجموعة النتائج الحالية. يساعد الجلب المسبق هذا في تحسين وقت الاستجابة الكلي للاستعلام. يؤدّي إعداد MaxBufferedItemCount في QueryRequestOptions إلى الحد من عدد النتائج التي تم إحضارها مسبقاً. عيِّن MaxBufferedItemCount على عدد النتائج المتوقع التي تُنتَج (أو عدد أعلى) للسماح للاستعلام بالحصول على أقصى فائدة من عملية الجلب مسبقاً. إذا قمت بتعيين هذه القيمة إلى -1، سيُحدد النظام تلقائياً عدد العناصر لتخزينها مؤقتاً.
using (FeedIterator<MyItem> feedIterator = container.GetItemQueryIterator<MyItem>(
"SELECT * FROM c WHERE c.city = 'Seattle'",
requestOptions: new QueryRequestOptions() {
PartitionKey = new PartitionKey("Washington"),
MaxBufferedItemCount = -1}))
{
// ...
}
يعمل الجلب المسبق بنفس الطريقة بغض النظر عن درجة التوازي، وهناك مخزن مؤقت واحد للبيانات من جميع الأقسام.
الخطوات التالية
لمعرفة المزيد عن الأداء باستخدام .NET SDK:
تقليل مكالمات خطة الاستعلام
لتنفيذ استعلام، يجب إنشاء خطة استعلام. يمثل هذا بوجهٍ عام طلب شبكة إلى Azure Cosmos DB Gateway، مما يضيف إلى زمن انتقال عملية الاستعلام.
استخدام التخزين المؤقت لخطة الاستعلام
تُخزَّن خطة الاستعلام، لاستعلام تم تحديد نطاقه إلى قسم واحد، مؤقتاً على العميل. هذا يلغي الحاجة إلى إجراء مكالمة إلى البوابة لاسترداد خطة الاستعلام بعد المكالمة الأولى. مفتاح خطة الاستعلام المُخزَّنة مؤقتاً هو سلسلة استعلام SQL. تحتاج إلى التأكد من أن الاستعلام مُطابق للمعلمات . إذا لم يكن الأمر كذلك، فغالباً ما يكون البحث عن ذاكرة التخزين المؤقت لخطة الاستعلام نقصاً في ذاكرة التخزين المؤقت حيث من غير المرجح أن تكون سلسلة الاستعلام متطابقة عبر المكالمات. يتم تمكين التخزين المؤقت لخطة الاستعلام بشكل افتراضي ل Java SDK الإصدار 4.20.0 والإصدارات الأحدث ول Spring Data Azure Cosmos DB SDK الإصدار 3.13.0 والإصدارات الأحدث.
استخدام استعلامات القسم الواحد المُطابق للمعلمات
بالنسبة للاستعلامات المُطابقة للمعلمات التي يتم تحديد نطاقها إلى مفتاح قسم مع setPartitionKey في CosmosQueryRequestOptions ولا تحتوي على تجميعات (بما في ذلك Distinct وDCount وGroup By)، يمكن تجنب خطة الاستعلام:
CosmosQueryRequestOptions options = new CosmosQueryRequestOptions();
options.setPartitionKey(new PartitionKey("Washington"));
ArrayList<SqlParameter> paramList = new ArrayList<SqlParameter>();
paramList.add(new SqlParameter("@city", "Seattle"));
SqlQuerySpec querySpec = new SqlQuerySpec(
"SELECT * FROM c WHERE c.city = @city",
paramList);
// Sync API
CosmosPagedIterable<MyItem> filteredItems =
container.queryItems(querySpec, options, MyItem.class);
// Async API
CosmosPagedFlux<MyItem> filteredItems =
asyncContainer.queryItems(querySpec, options, MyItem.class);
إشعار
تتطلب الاستعلامات عبر الأقسام SDK لزيارة جميع الأقسام الموجودة للتحقق من النتائج. كلما زادت الأقسام المادية التي تحتوي عليها الحاوية، كان من المحتمل أن تكون أبطأ.
ضبط درجة التوازي
تعمل الاستعلامات المتوازية عن طريق الاستعلام عن أقسام متعددة بالتوازي. ومع ذلك، يتم جلب البيانات من حاوية مقسَّمة فردية بشكل تسلسلي فيما يتعلق بالاستعلام. لذا، استخدم setMaxDegreeOfParallelism على CosmosQueryRequestOptions لتعيين القيمة على عدد الأقسام لديك. إذا كنت لا تعرف عدد الأقسام، يمكنك استخدام setMaxDegreeOfParallelism لتعيين رقم كبير، ويختار النظام الحد الأدنى (عدد الأقسام، المدخلات المقدمة من المستخدم) كأقصى درجة للتوازي. سيؤدي تعيين القيمة إلى -1 إلى السماح لـ SDK بتحديد التزامن الأمثل.
من المهم ملاحظة أن الاستعلامات المتوازية تنتج أفضل الفوائد إذا تم توزيع البيانات بالتساوي عبر جميع الأقسام فيما يتعلق بالاستعلام. إذا تم تقسيم الحاوية المقسّمة بطريقة تجعل كل البيانات التي يتم إرجاعها بواسطة استعلام أو معظمها مركزة في أقسام قليلة (قسم واحد في أسوأ الحالات)، فإن أداء الاستعلام سيُخفَّض.
CosmosQueryRequestOptions options = new CosmosQueryRequestOptions();
options.setPartitionKey(new PartitionKey("Washington"));
options.setMaxDegreeOfParallelism(-1);
// Define the query
// Sync API
CosmosPagedIterable<MyItem> filteredItems =
container.queryItems(querySpec, options, MyItem.class);
// Async API
CosmosPagedFlux<MyItem> filteredItems =
asyncContainer.queryItems(querySpec, options, MyItem.class);
لنفترض أن
- D = الحد الأقصى الافتراضي لعدد المهام المتوازية (= العدد الإجمالي لوحدات المعالجة في جهاز العميل)
- P = العدد الأقصى المحدد من قبل المستخدم للمهام المتوازية
- N = عدد الأقسام التي يجب زيارتها للإجابة عن استعلام
فيما يلي الآثار المترتبة على كيفية تصرف الاستعلامات المتوازية مع القيم المختلفة لـ P.
- (P == 0) => Serial Mode
- (P == 1) => مهمة واحدة كحد أقصى
- (P > 1) => Min (P، N) مهام متوازية
- (P == -1) => المهام الموازية (N, D) كحد أدنى
ضبط حجم الصفحة
عند إصدار استعلام SQL، يتم إرجاع النتائج بطريقة مجزأة إذا كانت مجموعة النتائج كبيرة جداً. بشكل ظاهري يتم إرجاع النتائج في أجزاء من 100 عنصر أو 4 ميغابايت، أيهما يتم الوصول إليه أولاً. ستؤدي زيادة حجم الصفحة إلى تقليل عدد الرحلات ذهابا وعودة المطلوبة وزيادة أداء الاستعلامات التي ترجع أكثر من 100 عنصر. إذا لم تكن متأكدا من القيمة التي يجب تعيينها، فإن 1000 عادة ما يكون خيارا جيدا. سيزداد استهلاك الذاكرة مع زيادة حجم الصفحة، لذلك إذا كان حمل العمل الخاص بك حساسا للذاكرة، ففكر في قيمة أقل.
يمكنك استخدام المعلمة pageSize في iterableByPage() لواجهة برمجة تطبيقات المتزامنة و byPage() لواجهة برمجة التطبيقات غير المتزامنة، لتحديد حجم الصفحة:
// Sync API
Iterable<FeedResponse<MyItem>> filteredItemsAsPages =
container.queryItems(querySpec, options, MyItem.class).iterableByPage(continuationToken,pageSize);
for (FeedResponse<MyItem> page : filteredItemsAsPages) {
for (MyItem item : page.getResults()) {
//...
}
}
// Async API
Flux<FeedResponse<MyItem>> filteredItemsAsPages =
asyncContainer.queryItems(querySpec, options, MyItem.class).byPage(continuationToken,pageSize);
filteredItemsAsPages.map(page -> {
for (MyItem item : page.getResults()) {
//...
}
}).subscribe();
ضبط حجم المخزن المؤقت
صُمِم الاستعلام الموازي لجلب النتائج مسبقاً في أثناء معالجة العميل لمجموعة النتائج الحالية. يساعد الجلب المسبق في تحسين وقت الانتقال الكلي للاستعلام. setMaxBufferedItemCount فيCosmosQueryRequestOptions تحدد عدد النتائج التي تم جلبها سابقاً. لتحقيق أقصى قدر من الإحضار المسبق، قم بتعيين maxBufferedItemCount إلى رقم أعلى من pageSize (ملاحظة: يمكن أن يؤدي هذا أيضا إلى استهلاك ذاكرة مرتفع). لتقليل الجلب المسبق، قم بتعيين maxBufferedItemCount يساوي pageSize. إذا عيَّنت هذه القيمة إلى -0، سيُحدد النظام تلقائياً عدد العناصر لتخزينها مؤقتاً.
CosmosQueryRequestOptions options = new CosmosQueryRequestOptions();
options.setPartitionKey(new PartitionKey("Washington"));
options.setMaxBufferedItemCount(-1);
// Define the query
// Sync API
CosmosPagedIterable<MyItem> filteredItems =
container.queryItems(querySpec, options, MyItem.class);
// Async API
CosmosPagedFlux<MyItem> filteredItems =
asyncContainer.queryItems(querySpec, options, MyItem.class);
يعمل الجلب المسبق بنفس الطريقة بغض النظر عن درجة التوازي، وهناك مخزن مؤقت واحد للبيانات من جميع الأقسام.
الخطوات التالية
لمعرفة المزيد عن الأداء باستخدام Java SDK:
تقليل مكالمات خطة الاستعلام
لتنفيذ استعلام، يجب إنشاء خطة استعلام. يمثل هذا بوجهٍ عام طلب شبكة إلى Azure Cosmos DB Gateway، مما يضيف إلى زمن انتقال عملية الاستعلام. هناك طريقة لإزالة هذا الطلب وتقليل زمن انتقال عملية استعلام القسم الواحد. بالنسبة إلى استعلامات القسم الفردي، حدد قيمة مفتاح القسم للعنصر وتمريره كوسيطة partition_key :
items = container.query_items(
query="SELECT * FROM r where r.city = 'Seattle'",
partition_key="Washington"
)
ضبط حجم الصفحة
عند إصدار استعلام SQL، يتم إرجاع النتائج بطريقة مجزأة إذا كانت مجموعة النتائج كبيرة جداً. يسمح لك max_item_count بتعيين الحد الأقصى لعدد العناصر التي سيتم إرجاعها في عملية التعداد.
items = container.query_items(
query="SELECT * FROM r where r.city = 'Seattle'",
partition_key="Washington",
max_item_count=1000
)
الخطوات التالية
لمعرفة المزيد حول استخدام Python SDK لواجهة برمجة التطبيقات ل NoSQL:
تقليل مكالمات خطة الاستعلام
لتنفيذ استعلام، يجب إنشاء خطة استعلام. يمثل هذا بوجهٍ عام طلب شبكة إلى Azure Cosmos DB Gateway، مما يضيف إلى زمن انتقال عملية الاستعلام. هناك طريقة لإزالة هذا الطلب وتقليل زمن انتقال عملية استعلام القسم الواحد. بالنسبة لاستعلامات القسم الواحد التي تحدد نطاق استعلام إلى قسم واحد، يمكن إنجاز طريقتين.
استخدام تعبير استعلام معلمات وتحديد مفتاح القسم في عبارة الاستعلام. يتكون الاستعلام برمجيا إلى SELECT * FROM todo t WHERE t.partitionKey = 'Bikes, Touring Bikes':
// find all items with same categoryId (partitionKey)
const querySpec = {
query: "select * from products p where p.categoryId=@categoryId",
parameters: [
{
name: "@categoryId",
value: "Bikes, Touring Bikes"
}
]
};
// Get items
const { resources } = await container.items.query(querySpec).fetchAll();
for (const item of resources) {
console.log(`${item.id}: ${item.name}, ${item.sku}`);
}
أو حدد partitionKey في FeedOptions وتمريره كوسيطة:
const querySpec = {
query: "select * from products p"
};
const { resources } = await container.items.query(querySpec, { partitionKey: "Bikes, Touring Bikes" }).fetchAll();
for (const item of resources) {
console.log(`${item.id}: ${item.name}, ${item.sku}`);
}
ضبط حجم الصفحة
عند إصدار استعلام SQL، يتم إرجاع النتائج بطريقة مجزأة إذا كانت مجموعة النتائج كبيرة جداً. يسمح لك maxItemCount بتعيين الحد الأقصى لعدد العناصر التي سيتم إرجاعها في عملية التعداد.
const querySpec = {
query: "select * from products p where p.categoryId=@categoryId",
parameters: [
{
name: "@categoryId",
value: items[2].categoryId
}
]
};
const { resources } = await container.items.query(querySpec, { maxItemCount: 1000 }).fetchAll();
for (const item of resources) {
console.log(`${item.id}: ${item.name}, ${item.sku}`);
}
الخطوات التالية
لمعرفة المزيد حول استخدام Node.js SDK لواجهة برمجة التطبيقات ل NoSQL: