مشاركة عبر

نصائح الأداء ل Azure Cosmos DB Python SDK

  • مقالة

ينطبق على: NoSQL

هام

تلميحات الأداء في هذه المقالة مخصصة ل Azure Cosmos DB Python SDK فقط. يرجى الاطلاع على ملاحظات إصدار Azure Cosmos DB Python SDK Readme وحزمة (PyPI) وحزمة (Conda) ودليل استكشاف الأخطاء وإصلاحها لمزيد من المعلومات.

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

لذلك إذا كنت تسأل «كيف يمكنني تحسين أداء قاعدة البيانات؟» فخذ الخيارات التالية في الاعتبار:

الشبكات

  • ترتيب العملاء في نفس منطقة Azure للأداء

عندما يكون ذلك ممكنا، ضع أي تطبيقات تستدعي Azure Cosmos DB في نفس المنطقة مثل قاعدة بيانات Azure Cosmos DB. لإجراء مقارنة تقريبية، تكتمل المكالمات إلى Azure Cosmos DB داخل نفس المنطقة في غضون 1-2 مللي ثانية، لكن وقت الاستجابة بين الساحلَين الغربي والشرقي للولايات المتحدة يبلغ >50 مللي ثانية. من المحتمل أن يختلف ومن الانتقال هذا من طلب إلى آخر، اعتمادًا على المسار الذي يسلكه الطلب، حيث ينتقل من العميل إلى حد مركز بيانات Azure. يتم تحقيق أقل زمن انتقال ممكن عن طريق التأكد من أن تطبيق الاستدعاء يقع داخل منطقة Azure نفسها كنقطة نهاية Azure Cosmos DB المتوافرة. للحصول على قائمة بالمناطق المتوافرة، راجع مناطق Azure.

رسم توضيحي لنهج اتصال Azure Cosmos DB.

يحتاج التطبيق الذي يتفاعل مع حساب Azure Cosmos DB متعدد المناطق إلى تكوين المواقع المفضلة للتأكد من أن الطلبات ستنتقل إلى منطقة موحدة.

تمكين الشبكات المتسارعة لتقليل زمن الانتقال وتشويه وحدة المعالجة المركزية

يوصى باتباع الإرشادات لتمكين الشبكات المتسارعة في Windows ( حدد للحصول على الإرشادات) أو Linux (حدد للحصول على الإرشادات) Azure VM، من أجل زيادة الأداء إلى أقصى حد (تقليل زمن الانتقال وتشويه وحدة المعالجة المركزية).

بدون تسريع الشبكات، قد يتم توجيه الإدخال /الإخراج الذي ينتقل بين جهاز Azure الظاهري وموارد Azure الأخرى دون داع من خلال مضيف ومحول ظاهري يقع بين الجهاز الظاهري وبطاقة الشبكة الخاصة به. لا يؤدي وجود المضيف والمفتاح الظاهري المضمَّن في مسار البيانات إلى زيادة زمن الوصول والارتعاش في قناة الاتصال فحَسْب، بل يسرق أيضاً دورات وحدة المعالجة المركزية من الجهاز الظاهري. مع الشبكات المتسارعة، واجهات الجهاز الظاهري مباشرة مع NIC دون وسطاء؛ أي تفاصيل سياسة الشبكة التي كان يتم التعامل معها من قبل المضيف والمحول الظاهري يتم التعامل معها الآن في الأجهزة في NIC؛ يتم تجاوز المضيف والمحول الظاهري. بشكل عام، يمكنك توقع وقت استجابة أقل، وإنتاجية أعلى، فضلاً على زيادة اتساق زمن الانتقال، وانخفاض استخدام وحدة المعالجة المركزية عند تمكين تسريع الشبكة.

القيود: يجب دعم الشبكات المتسارعة على نظام تشغيل VM، ولا يمكن تمكينها إلا عند إيقاف الجهاز الظاهري وإلغاء تخصيصه. لا يمكن نشر الجهاز الظاهري مع Azure Resource Manager. لم يتم تمكين الشبكة المسرعة ل App Service .

الرجاء مراجعة إرشادات Windows وLinux للحصول على مزيد من التفاصيل.

استخدام SDK

  • تثبيت أحدث إصدار من SDK

يتم تحسين حزم Azure Cosmos DB SDK باستمرار لتوفير أفضل أداء. راجع ملاحظات إصدار Azure Cosmos DB SDK لتحديد أحدث SDK ومراجعة التحسينات.

  • استخدم عميل قاعدة بيانات أحادية Azure Cosmos DB طوال عمر تطبيقك

كل مثيل عميل Azure Cosmos DB آمن لمؤشر الترابط ويقوم بإدارة اتصال فعالة وتخزين مؤقت للعنوان. للسماح بإدارة اتصال فعالة وأداء أفضل من قبل عميل Azure Cosmos DB، يوصى باستخدام مثيل واحد لعميل Azure Cosmos DB طوال عمر التطبيق.

  • ضبط المهلة وإعادة محاولة التكوينات

يمكن تخصيص تكوينات المهلة ونهج إعادة المحاولة استنادا إلى احتياجات التطبيق. راجع مستند التكوين المهلة وإعادة المحاولة للحصول على قائمة كاملة بالتكوينات التي يمكن تخصيصها.

  • استخدم أقل مستوى توافق مطلوب لتطبيقك

عند إنشاء CosmosClient، يتم استخدام تناسق مستوى الحساب إذا لم يتم تحديد أي شيء في إنشاء العميل. لمزيد من المعلومات حول مستويات التناسق، راجع مستند مستويات التناسق.

  • توسيع نطاق عبء عمل العميل

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

القاعدة الأساسية الجيدة هي عدم تجاوز >استخدام CPU 50% على أي خادم، للحفاظ على زمن الانتقال منخفضًا.

  • حد موارد ملفات فتح OS

تحتوي بعض أنظمة Linux (مثل Red Hat) على حد أعلى لعدد الملفات المفتوحة وبالتالي إجمالي عدد الاتصالات. شغل ما يلي لعرض الحدود الحالية:

ulimit -a

يجب أن يكون عدد الملفات المفتوحة (nofile) كبيرا بما يكفي للحصول على مساحة كافية لحجم تجمع الاتصال المكون والملفات المفتوحة الأخرى بواسطة نظام التشغيل. يمكن تعديله للسماح بحجم أكبر لتجمع الاتصال.

افتح ملف limits.conf:

vim /etc/security/limits.conf

قم بإضافة / تعديل الأسطر التالية:

* - nofile 100000

عمليات الاستعلام

لعمليات الاستعلام، راجع نصائح أداء الاستعلامات.

سياسة الفهرسة

  • استبعاد المسارات غير المستخدمة من الفهرسة لعمليات كتابة أسرع

تتيح لك سياسة الفهرسة في Azure Cosmos DB تحديد مسارات المستندات التي يجب تضمينها أو استبعادها من الفهرسة عن طريق الاستفادة من مسارات الفهرسة (setIncludedPaths وsetExcludedPaths). يمكن أن يوفر استخدام مسارات الفهرسة أداء كتابة محسناً وتخزين فهرس أقل للسيناريوهات التي تُعرف فيها أنماط الاستعلام سابقاً، حيث ترتبط تكاليف الفهرسة ارتباطاً مباشراً بعدد المسارات الفريدة المفهرسة. على سبيل المثال، يوضح الكود التالي كيفية تضمين واستبعاد أقسام كاملة من المستندات (تُعرف أيضاً باسم الشجرة الفرعية) من الفهرسة باستخدام حرف البدل "*".

container_id = "excluded_path_container"
indexing_policy = {
        "includedPaths" : [ {'path' : "/*"} ],
        "excludedPaths" : [ {'path' : "/non_indexed_content/*"} ]
        }
db.create_container(
    id=container_id,
    indexing_policy=indexing_policy,
    partition_key=PartitionKey(path="/pk"))

للحصول على مزيد من المعلومات، راجع خدمة Azure Cosmos DB: نهج الفهرسة.

الإنتاجية

  • قياس وضبط وحدات الطلب الأقل / الاستخدام الثاني

يوفر Azure Cosmos DB مجموعة غنية من عمليات قاعدة البيانات بما في ذلك الاستعلامات العلائقية والتسلسلية باستخدام UDFs، والإجراءات المخزنة، والمشغلات - تعمل جميعها على المستندات ضمن مجموعة قاعدة بيانات. تختلف التكلفة المقترنة بكل من هذه العمليات استناداً إلى وحدة المعالجة المركزية، والمدخلات/ المخرجات، والذاكرة المطلوبة لإكمال العملية. بدلًا من التفكير في موارد الأجهزة وإدارتها، يمكنك التفكير في وحدة الطلب (RU) كمقياس واحد للموارد المطلوبة لإجراء عمليات قاعدة بيانات متنوعة وخدمة طلب تطبيق.

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

يؤثر تعقيد الاستعلام على عدد وحدات الطلب التي يتم استهلاكها لعمليةٍ ما. عدد الدالات وطبيعتها وعدد دالات UDF وحجم مجموعة بيانات المصدر جميعها عوامل تؤثر على تكلفة عمليات الاستعلام.

لقياس النفقات العامة لأي عملية (إنشاء أو تحديث أو حذف)، افحص عنوان x-ms-request-charge لقياس عدد وحدات الطلب التي تستهلكها هذه العمليات.

document_definition = {
    'id': 'document',
    'key': 'value',
    'pk': 'pk'
}
document = container.create_item(
    body=document_definition,
)
print("Request charge is : ", container.client_connection.last_response_headers['x-ms-request-charge'])

تُعد رسوم الطلب التي تم إرجاعها في هذا العنوان جزءًا صغيرًا من معدل النقل المقدم. على سبيل المثال، إذا كان لديك 2000 RU/s متوافرة، وإذا كان الاستعلام السابق يُرجع مستندات 1000 1KB، فإن تكلفة العملية تكون 1000. على هذا النحو، في غضون ثانية واحدة، ينفذ الخادم طلبَيْن فقط من هذا القبيل قبل أن يحد المعدل الطلبات اللاحقة. لمزيد من المعلومات، راجع وحدات الطلب وحاسبة وحدات الطلب.

  • تقييد معدل المعالجة/معدل الطلب كبير جدًّا

عند محاولة عميل تجاوز معدل النقل المحجوز لأحد الحسابات، فلا يكون هناك انخفاض في الأداء في الخادم ولا استخدام لسعة معدل نقل يتجاوز المستوى المحجوز. سينهي الخادم الطلب بشكل استباقي باستخدام RequestRateTooLarge (رمز حالة HTTP 429) ويعيد عنوان x-ms-retry-after-ms الذي يشير إلى مقدار الوقت، بالمللي ثانية، الذي يجب على المستخدم انتظاره قبل إعادة محاولة الطلب.

HTTP Status 429,
Status Line: RequestRateTooLarge
x-ms-retry-after-ms :100

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

إذا كان لديك أكثر من عميل واحد يعمل بشكل تراكمي بشكل متناسق فوق معدل الطلب، فقد لا يكفي عدد إعادة المحاولة الافتراضي المعين حاليا إلى 9 داخليا من قبل العميل؛ في هذه الحالة، يطرح العميل CosmosHttpResponseError مع رمز الحالة 429 إلى التطبيق. يمكن تغيير عدد مرات إعادة المحاولة الافتراضي عن retry_total طريق تمرير التكوين إلى العميل. بشكل افتراضي، يتم إرجاع CosmosHttpResponseError مع رمز الحالة 429 بعد وقت انتظار تراكمي لمدة 30 ثانية إذا استمر الطلب في العمل فوق معدل الطلب. يحدث هذا حتى عندما يكون عدد عمليات إعادة المحاولة الحالية أقل من الحد الأقصى لعدد مرات إعادة المحاولة، سواء كانت القيمة الظاهرية 9 أو قيمة معرَّفة من قِبَل المستخدم.

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

  • تصميم مستندات أصغر حجمًا للحصول على معدل نقل أعلى

ترتبط رسوم الطلب (تكلفة معالجة الطلب) لعملية معينة ارتباطا مباشرا بحجم المستند. تكلف العمليات على المستندات الكبيرة أكثر من عمليات المستندات الصغيرة. من الناحية المثالية، صمم التطبيق وسير العمل بحيث يكون حجم العنصر الخاص بك 1 كيلوبايت تقريباً، أو ترتيباً أو حجماً مشابهاً. بالنسبة للتطبيقات الحساسة لزمن الانتقال، يجب تجنب العناصر الكبيرة - ستؤدي المستندات متعددة الميغابايت إلى إبطاء تطبيقك.

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

لمعرفة مزيد حول تصميم تطبيقك بحيث يتناسب مع الحجم والأداء العالي، راجع التقسيم والقياس في Azure Cosmos DB.

هل تحاول القيام بتخطيط السعة للترحيل إلى Azure Cosmos DB؟ يمكنك استخدام معلومات حول نظام مجموعة قاعدة البيانات الموجودة لديك لـ تخطيط السعة.