مشاركة عبر

أفضل الممارسات لـ Azure Cosmos DB Java SDK

  • مقالة

ينطبق على: NoSQL

تستعرض هذه المقالة أفضل الممارسات لاستخدام Azure Cosmos DB Java SDK. باتباع هذه الممارسات، سيساعدك في تحسين زمن الانتقال والتوفر وتعزيز الأداء الكلي.

قائمة الاختيار

محدد الموضوع التفاصيل/الارتباطات
إصدار SDK استخدم دائما أحدث إصدار من Azure Cosmos DB SDK المتوفر للحصول على الأداء الأمثل.
عميل قاعدة بيانات أحادية استخدم مثيلاً واحداً لـ CosmosClient طوال فترة عمل تطبيقك للحصول على أفضل أداء.
المناطق تأكد من تشغيل تطبيقك في منطقة Azure نفسها الموجودة في حساب Azure Cosmos DB، لتقليل زمن الانتقال إن أمكن ذلك. مكِّن منطقتين إلى 4 مناطق وانسخ حساباتك في مناطق متعددة للحصول على أفضل إمكانية توافر. بالنسبة لأحمال عمل الإنتاج، قم بتمكين تجاوز الفشل المدار بواسطة الخدمة. في حالة عدم وجود هذا التكوين، سيواجه الحساب فقدان إمكانية الكتابة طوال مدة انقطاع منطقة الكتابة، حيث لن ينجح تجاوز الفشل اليدوي بسبب نقص اتصال المنطقة. لمعرفة كيفية إضافة مناطق متعددة باستخدام Java SDK تفضل بزيارة هنا
التوفر وتجاوز الفشل قم بتعيين FavoritesRegions في الإصدار 4 SDK. أثناء تجاوز الفشل، تُرسَل عمليات الكتابة إلى منطقة الكتابة الحالية وتُرسَل عمليات القراءة إلى المنطقة الأولى ضمن قائمة المناطق المفضلة. لمزيد من المعلومات حول آليات تجاوز الفشل الإقليمية، راجع دليل تحري الخلل وإصلاحه في التوفر.
CPU قد تواجه مشكلات في الاتصال/التوفر بسبب عدم وجود موارد على جهاز العميل. راقب استخدام وحدة المعالجة المركزية في العقد التي تشغِّل عميل DB Cosmos Azure، ووسِّع/ضيِّق النطاق إذا كان الاستخدام عالياً جداً.
الاستضافة بالنسبة لمعظم حالات أحمال العمل الإنتاجية الشائعة، نوصي بشدة باستخدام أجهزة ظاهرية ذات 4 مراكز وذاكرة 8 غيغابايت على الأقل كلما أمكن ذلك.
أوضاع الاتصال استخدم الوضع المباشر للحصول على أفضل أداء. للحصول على إرشادات حول كيفية القيام بذلك، راجع وثائق V4 SDK.
الشبكات في حالة استخدام جهاز ظاهري لتشغيل التطبيق، مكِّن الشبكات المتسارعة على الجهاز الظاهري للمساعدة في تخفيف الازدحامات بسبب ارتفاع نسبة استخدام الشبكة وتقليل زمن الانتقال أو توتر وحدة المعالجة المركزية. قد ترغب أيضاً في النظر في استخدام جهاز ظاهري بنهاية عالية حيث يبلغ الحد الأقصى لاستخدام وحدة المعالجة المركزية أقل من 70٪.
استهلاك المنفذ المؤقت للاتصالات المتفرقة أو المتقطعة، نوصي بتعيين idleEndpointTimeout على قيمة أعلى. تساعد خاصية idleEndpointTimeout في DirectConnectionConfig في التحكم في وقت إغلاق الاتصالات غير المستخدمة. سيؤدي هذا إلى تقليل عدد الاتصالات غير المستخدمة. بشكل افتراضي، تظل الاتصالات الخاملة بنقطة النهاية مفتوحة لمدة ساعة واحدة. إذا لم تكن هناك طلبات إلى نقطة نهاية محددة لمدة مهلة نقطة النهاية الخاملة، يقوم العميل المباشر بإغلاق جميع الاتصالات بنقطة النهاية هذه لحفظ الموارد وتكلفة الإدخال/الإخراج.
استخدام برنامج الجدولة المناسب (تجنب سرقة سلاسل الأحداث IO Netty ذات حلقة الأحداث) تجنب منع الاستدعاءات: .block(). مكدس الاستدعاءات بالكامل غير متزامن للاستفادة من أنماط واجهة برمجة التطبيقات غير المتزامنة واستخدام سلاسل الرسائل وجدولة
المهلات الشاملة للحصول على المهلات من طرف إلى طرف، قم بتنفيذ نهج المهلة من طرف إلى طرف في Java SDK. لمزيد من التفاصيل حول المهلات مع زيارة Azure Cosmos DB هنا
منطق إعادة المحاولة خطأ عابر هو خطأ يحدث بسبب أساسي يحل نفسه قريباً. يجب إنشاء التطبيقات التي تتصل بقاعدة البيانات لتوقع هذه الأخطاء عابرة. لمعالجتها، استخدم منطق إعادة المحاولة في التعليمات البرمجية بدلاً من الظهور للمستخدمين كأخطاء في التطبيق. تتبع أداة SDK منطقاً مضمناً لمعالجة هذه الفشل العابر في الطلبات القابلة لإعادة المحاولة مثل عمليات القراءة أو الاستعلام. لن تعيد عدة تطوير البرامج محاولة الكتابة في حالات الفشل العابر لأن عمليات الكتابة ليست عديمة الفعالية. تسمح أداة SDK للمستخدمين بتكوين منطق إعادة المحاولة لعمليات التقييد. للحصول على تفاصيل حول الأخطاء التي يجب إعادة المحاولة عليها تفضل بزيارة هنا
التخزين المؤقت لقاعدة البيانات/أسماء المجموعات استرد أسماء قواعد البيانات والحاويات من التكوين أو خزِّنها مؤقتًا في البداية. ستؤدي الاستدعاءات مثل CosmosAsyncDatabase#read() أو CosmosAsyncContainer#read() إلى استدعاءات بيانات التعريف للخدمة، والتي تستهلك من حد RU المخصص للنظام. يجب استخدام createDatabaseIfNotExists() أيضاً مرة واحدة لإعداد قاعدة البيانات فقط. عامة ينبغي تنفيذ هذه العمليات بشكل غير منتظم.
استعلامات متوازية يدعم Azure Cosmos DB SDK تشغيل الاستعلامات بالتوازي للحصول على زمن انتقال ومعدل نقل أفضل في استعلاماتك. نوصي بتعيين الخاصية maxDegreeOfParallelism ضمن CosmosQueryRequestsOptions إلى عدد الأقسام لديك. إذا لم تكن على علم بعدد الأقسام، فعيّن القيمة على -1 التي ستمنحك أفضل وقت استجابة. عيِّن أيضاً maxBufferedItemCount على العدد المتوقع من النتائج الظاهرة للحد من عدد النتائج التي تُجلب مسبقاً.
التراجع عن اختبار الأداء عند إجراء الاختبار على التطبيق الخاص بك، يجب عليك تنفيذ فترات التراجع على فترات زمنية تبلغ RetryAfter. يساعد الالتزام بحالة التراجع في التأكد من الانتظار لأدنى فترة بين عمليات إعادة المحاولة.
الفهرسة تسمح لك نهج الفهرسة Azure Cosmos DB أيضاً بتحديد مسارات المستندات المراد تضمينها أو استبعادها من الفهرسة باستخدام مسارات الفهرسة IndexingPolicy#getIncludedPaths() وIndexingPolicy#getExcludedPaths(). تأكد من استبعاد المسارات غير المستخدمة من الفهرسة للكتابة بشكل أسرع. للحصول على نموذج حول كيفية إنشاء الفهارس باستخدام عدة تطوير البرامج تفضل بزيارة هنا
حجم المستند يرتبط رسم الطلب لعملية محددة بحجم المستند مباشرة. نوصي بتقليل حجم المستندات حيث تكلف العمليات التي تُجرى على المستندات الكبيرة مبلغاً أكبر من العمليات التي تُجرى على المستندات الأصغر.
حجم الصفحة بشكل افتراضي، يتم إرجاع نتائج الاستعلام في مجموعات من 100 عنصر أو 4 ميغابايت، أيهما يصل أولا. إذا كان الاستعلام سيرجع أكثر من 100 عنصر، فقم بزيادة حجم الصفحة لتقليل عدد الرحلات ذهابا و إيابا المطلوبة. سيزداد استهلاك الذاكرة مع زيادة حجم الصفحة.
تمكين مقاييس الاستعلام للحصول على تسجيل إضافي لعمليات تنفيذ استعلام الواجهة الخلفية، اتبع الإرشادات حول كيفية تسجيل قياسات استعلام SQL باستخدام Java SDK
تسجيل SDK استخدم تسجيل SDK للحصول على معلومات تشخيص إضافية واستكشاف أخطاء زمن الانتقال وإصلاحها. سجل CosmosDiagnostics في Java SDK للحصول على معلومات تشخيصية أكثر تفصيلا ل Azure Cosmos DB للطلب الحالي إلى الخدمة. كمثال لحالة الاستخدام، التقط بيانات التشخيص في أي استثناء وفي العمليات المكتملة إذا كانت CosmosDiagnostics#getDuration() أكبر من قيمة الحد المعين (أي إذا كان لديك اتفاقية مستوى الخدمة لمدة 10 ثوانٍ، فاحصل على التشخيصات عند getDuration()> 10 ثوانٍ ). يُنصح باستخدام هذه التشخيصات فقط أثناء اختبار الأداء. لمزيد من المعلومات، اتبع التقاط التشخيصات على Java SDK
تجنب استخدام أي أحرف خاصة في المعرفات بعض الأحرف مقيدة ولا يمكن استخدامها في بعض المعرفات: '/'، '\'، '?'، '#'. التوصية العامة هي عدم استخدام أي أحرف خاصة في معرفات مثل اسم قاعدة البيانات أو اسم المجموعة أو معرف العنصر أو مفتاح القسم لتجنب أي سلوك غير متوقع.

أفضل الممارسات عند استخدام وضع البوابة

تُجرى طلبات Azure Cosmos DB عبر بروتوكول HTTPS/RESTREST عند استخدام وضع البوابة. إنها تخضع لحد الاتصال الافتراضي لكل اسم مضيف أو عنوان IP. قد تحتاج إلى تعديل maxConnectionPoolSize إلى قيمة مختلفة (من 100 إلى 1000) بحيث يمكن لمكتبة العميل استخدام اتصالات متزامنة متعددة مع Azure Cosmos DB. في Java v4 SDK، القيمة الافتراضية لـ GatewayConnectionConfig#maxConnectionPoolSize هي 1000. لتغيير القيمة، يمكنك تعيين GatewayConnectionConfig#maxConnectionPoolSize على قيمة مختلفة.

أفضل الممارسات لعمليات سير العمل المليئة بالكتابة

بالنسبة لعمليات سير العمل التي تحتوي على أعباء إنشاء كبيرة، عيِّن خيار الطلب CosmosClientBuilder#contentResponseOnWriteEnabled() على false. لن تقوم الخدمة بعد الآن بإرجاع المورد الذي تم إنشاؤه أو تحديثه إلى SDK. عادة بسبب احتواء التطبيق على الكائن المُكوَن، لن يحتاج إلى الخدمة لإعادته. لا يزال الوصول إلى قيم العنوان ممكناً مثل رسوم الطلب. يمكن أن يساعد تعطيل استجابة المحتوى في تحسين الأداء، لأن SDK لا تحتاج إلى تخصيص الذاكرة أو تحديد تسلسل نص الاستجابة بعد الآن. كما أنه يقلل من استخدام النطاق الترددي للشبكة للمساعدة في الأداء بشكل أكبر.

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

لمعرفة المزيد حول نصائح الأداء لـ Java SDK، راجع تلميحات الأداء لـ Azure Cosmos DB Java SDK الإصدار رقم 4.

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

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