تلميحات حول أداء Azure Cosmos DB Java SDK الإصدار 4
ينطبق على: 
NoSQL
هام
تلميحات الأداء الواردة في هذه المقالة خاصة بـ Azure Cosmos DB Java SDK v4 فقط. الرجاء عرض Azure Cosmos DB Java SDK v4 ملحوظات الإصدار ومستودع Maven وAzure Cosmos DB Java SDK v4 دليل استكشاف الأخطاء وإصلاحها لمزيد من المعلومات. إذا كنت تستخدم حاليّاً إصداراً أقدم من الإصدار 4، فراجع دليل الترحيل إلى حزمة تطوير برامج Java Azure Cosmos DB - الإصدار 4 للمساعدة على الترقية إلى الإصدار 4.
Azure Cosmos DB هي قاعدة بيانات موزعة سريعة ومرنة تتوسع بسلاسة مع زمن انتقال ومعدل انتقال مضمونين. لا يتعين عليك إجراء تغييرات هيكلية كبيرة أو كتابة تعليمات برمجية معقدة لتوسيع نطاق قاعدة البيانات باستخدام Azure Cosmos DB. يعد التوسع لأعلى ولأسفل سهلاً مثل إجراء استدعاء واحد لواجهة برمجة التطبيقات أو استدعاء طريقة SDK. ومع ذلك، نظراً لأنه يتم الوصول إلى Azure Cosmos DB عبر مكالمات الشبكة، هناك تحسينات من جانب العميل يمكنك إجراؤها لتحقيق أعلى أداء عند استخدام Azure Cosmos DB Java SDK v4.
لذلك إذا كنت تسأل «كيف يمكنني تحسين أداء قاعدة البيانات؟» فخذ الخيارات التالية في الاعتبار:
الشبكات
ترتيب العملاء في نفس منطقة Azure للأداء
عندما يكون ذلك ممكنا، ضع أي تطبيقات تستدعي Azure Cosmos DB في نفس المنطقة مثل قاعدة بيانات Azure Cosmos DB. لإجراء مقارنة تقريبية، تكتمل المكالمات إلى Azure Cosmos DB داخل نفس المنطقة في غضون 1-2 مللي ثانية، لكن وقت الاستجابة بين الساحلَين الغربي والشرقي للولايات المتحدة يبلغ >50 مللي ثانية. من المحتمل أن يختلف ومن الانتقال هذا من طلب إلى آخر، اعتمادًا على المسار الذي يسلكه الطلب، حيث ينتقل من العميل إلى حد مركز بيانات Azure. يتم تحقيق أقل زمن انتقال ممكن عن طريق التأكد من أن تطبيق الاستدعاء يقع داخل منطقة Azure نفسها كنقطة نهاية Azure Cosmos DB المتوافرة. للحصول على قائمة بالمناطق المتوافرة، راجع مناطق Azure.
يحتاج التطبيق الذي يتفاعل مع حساب Azure Cosmos DB متعدد المناطق إلى تكوين المواقع المفضلة للتأكد من أن الطلبات ستنتقل إلى منطقة موحدة.
تمكين الشبكات المتسارعة لتقليل زمن الانتقال وتشويه وحدة المعالجة المركزية
نوصي بشدة باتباع الإرشادات لتمكين الشبكات المتسارعة في Windows ( حدد للحصول على الإرشادات) أو Linux (حدد للحصول على الإرشادات) Azure VM لزيادة الأداء إلى أقصى حد عن طريق تقليل زمن الانتقال وتشويه وحدة المعالجة المركزية.
بدون تسريع الشبكات، قد يتم توجيه الإدخال/الإخراج الذي ينتقل بين جهاز Azure الظاهري وموارد Azure الأخرى من خلال مضيف ومحول ظاهري يقع بين الجهاز الظاهري وبطاقة الشبكة الخاصة به. لا يؤدي وجود المضيف والمفتاح الظاهري المضمَّن في مسار البيانات إلى زيادة زمن الوصول والارتعاش في قناة الاتصال فحَسْب، بل يسرق أيضاً دورات وحدة المعالجة المركزية من الجهاز الظاهري. مع الشبكات المتسارعة، يتفاعل الجهاز الظاهري مباشرة مع NIC دون وسطاء. تتم معالجة جميع تفاصيل نهج الشبكة في الأجهزة في NIC، متجاوزا المضيف والتبديل الظاهري. بشكل عام، يمكنك توقع وقت استجابة أقل، وإنتاجية أعلى، فضلاً على زيادة اتساق زمن الانتقال، وانخفاض استخدام وحدة المعالجة المركزية عند تمكين تسريع الشبكة.
القيود: يجب دعم الشبكات المتسارعة على نظام تشغيل VM، ولا يمكن تمكينها إلا عند إيقاف الجهاز الظاهري وإلغاء تخصيصه. لا يمكن نشر الجهاز الظاهري باستخدام Azure Resource Manager. لم يتم تمكين الشبكة المسرعة ل App Service .
لمزيد من المعلومات، راجع إرشادات Windows وLinux.
التوافر العالي
للحصول على إرشادات عامة حول تكوين قابلية وصول عالية في Azure Cosmos DB، راجع قابلية الوصول العالية في Azure Cosmos DB.
بالإضافة إلى الإعداد التأسيسي الجيد في النظام الأساسي لقاعدة البيانات، هناك تقنيات محددة يمكن تنفيذها في Java SDK نفسها، والتي يمكن أن تساعد في سيناريوهات الانقطاع. هناك إستراتيجيتان ملحوظتان هما استراتيجية التوفر المستندة إلى العتبة و قاطع الدوائر على مستوى القسم.
توفر هذه التقنيات آليات متقدمة لمعالجة تحديات زمن الانتقال والتوافر المحددة، والتي تتجاوز قدرات إعادة المحاولة عبر المناطق المضمنة في SDK بشكل افتراضي. من خلال إدارة المشكلات المحتملة بشكل استباقي على مستويات الطلب والتقسيم، يمكن لهذه الاستراتيجيات تعزيز مرونة التطبيق وأدائه بشكل كبير، خاصة في ظل ظروف عالية التحميل أو متدهورة.
استراتيجية التوفر المستندة إلى العتبة
يمكن لاستراتيجية التوفر المستندة إلى العتبة تحسين زمن انتقال الاستجابة والتوافر عن طريق إرسال طلبات قراءة متوازية إلى المناطق الثانوية وقبول أسرع استجابة. يمكن أن يقلل هذا النهج بشكل كبير من تأثير الانقطاعات الإقليمية أو ظروف زمن الانتقال العالي على أداء التطبيق. بالإضافة إلى ذلك، يمكن استخدام إدارة الاتصال الاستباقية لزيادة تحسين الأداء من خلال تجهيز الاتصالات وذاكرة التخزين المؤقت عبر كل من منطقة القراءة الحالية والمناطق البعيدة المفضلة.
مثال على التكوين:
// Proactive Connection Management
CosmosContainerIdentity containerIdentity = new CosmosContainerIdentity("sample_db_id", "sample_container_id");
int proactiveConnectionRegionsCount = 2;
Duration aggressiveWarmupDuration = Duration.ofSeconds(1);
CosmosAsyncClient clientWithOpenConnections = new CosmosClientBuilder()
.endpoint("<account URL goes here")
.key("<account key goes here>")
.endpointDiscoveryEnabled(true)
.preferredRegions(Arrays.asList("sample_region_1", "sample_region_2"))
.openConnectionsAndInitCaches(new CosmosContainerProactiveInitConfigBuilder(Arrays.asList(containerIdentity))
.setProactiveConnectionRegionsCount(proactiveConnectionRegionsCount)
//setting aggressive warmup duration helps in cases where there is a high no. of partitions
.setAggressiveWarmupDuration(aggressiveWarmupDuration)
.build())
.directMode()
.buildAsyncClient();
CosmosAsyncContainer container = clientWithOpenConnections.getDatabase("sample_db_id").getContainer("sample_container_id");
int threshold = 500;
int thresholdStep = 100;
CosmosEndToEndOperationLatencyPolicyConfig config = new CosmosEndToEndOperationLatencyPolicyConfigBuilder(Duration.ofSeconds(3))
.availabilityStrategy(new ThresholdBasedAvailabilityStrategy(Duration.ofMillis(threshold), Duration.ofMillis(thresholdStep)))
.build();
CosmosItemRequestOptions options = new CosmosItemRequestOptions();
options.setCosmosEndToEndOperationLatencyPolicyConfig(config);
container.readItem("id", new PartitionKey("pk"), options, JsonNode.class).block();
// Write operations can benefit from threshold-based availability strategy if opted into non-idempotent write retry policy
// and the account is configured for multi-region writes.
options.setNonIdempotentWriteRetryPolicy(true, true);
container.createItem("id", new PartitionKey("pk"), options, JsonNode.class).block();
كيفية عملها:
الطلب الأولي: في الوقت T1، يتم إجراء طلب قراءة إلى المنطقة الأساسية (على سبيل المثال، شرق الولايات المتحدة). تنتظر SDK استجابة تصل إلى 500 مللي ثانية (
thresholdالقيمة).الطلب الثاني: إذا لم تكن هناك استجابة من المنطقة الأساسية في غضون 500 مللي ثانية، يتم إرسال طلب متوازي إلى المنطقة المفضلة التالية (على سبيل المثال، شرق الولايات المتحدة 2).
الطلب الثالث: إذا لم تستجب المنطقة الأساسية أو الثانوية في غضون 600 مللي ثانية (500 مللي ثانية + 100 مللي ثانية،
thresholdStepالقيمة)، ترسل SDK طلبا موازيا آخر إلى المنطقة المفضلة الثالثة (على سبيل المثال، غرب الولايات المتحدة).أسرع استجابة يفوز: أي منطقة تستجيب أولا، يتم قبول هذه الاستجابة، ويتم تجاهل الطلبات المتوازية الأخرى.
تساعد إدارة الاتصال الاستباقية عن طريق تجهيز الاتصالات وذاكرة التخزين المؤقت للحاويات عبر المناطق المفضلة، والحد من زمن انتقال البدء البارد لسيناريوهات تجاوز الفشل أو الكتابة في الإعدادات متعددة المناطق.
يمكن أن تحسن هذه الاستراتيجية بشكل كبير زمن الانتقال في السيناريوهات التي تكون فيها منطقة معينة بطيئة أو غير متوفرة مؤقتا، ولكنها قد تتحمل تكلفة أكبر من حيث وحدات الطلب عند الحاجة إلى طلبات متوازة عبر المناطق.
إشعار
إذا قامت المنطقة المفضلة الأولى بإرجاع رمز حالة خطأ غير عابر (على سبيل المثال، لم يتم العثور على المستند، وخطأ التخويل، والتعارض، وما إلى ذلك)، فستفشل العملية نفسها بسرعة، حيث لن يكون لاستراتيجية التوفر أي فائدة في هذا السيناريو.
قاطع دائرة على مستوى القسم
يعزز قاطع الدائرة على مستوى القسم زمن انتقال الاستجابة وتوافر الكتابة عن طريق التعقب وطلبات الدوائر القصيرة إلى الأقسام المادية غير السليمة. فهو يحسن الأداء عن طريق تجنب الأقسام المعروفة التي بها مشاكل وإعادة توجيه الطلبات إلى مناطق أكثر صحة.
مثال على التكوين:
لتمكين قاطع الدوائر على مستوى القسم:
System.setProperty(
"COSMOS.PARTITION_LEVEL_CIRCUIT_BREAKER_CONFIG",
"{\"isPartitionLevelCircuitBreakerEnabled\": true, "
+ "\"circuitBreakerType\": \"CONSECUTIVE_EXCEPTION_COUNT_BASED\","
+ "\"consecutiveExceptionCountToleratedForReads\": 10,"
+ "\"consecutiveExceptionCountToleratedForWrites\": 5,"
+ "}");
لتعيين تكرار عملية الخلفية للتحقق من المناطق غير المتوفرة:
System.setProperty("COSMOS.STALE_PARTITION_UNAVAILABILITY_REFRESH_INTERVAL_IN_SECONDS", "60");
لتعيين المدة التي يمكن أن يظل فيها القسم غير متوفر:
System.setProperty("COSMOS.ALLOWED_PARTITION_UNAVAILABILITY_DURATION_IN_SECONDS", "30");
كيفية عملها:
فشل التعقب: تتعقب SDK حالات الفشل الطرفية (على سبيل المثال، 503s، 500s، المهلات) للأقسام الفردية في مناطق معينة.
وضع علامة على أنه غير متوفر: إذا تجاوز قسم في منطقة حدا مكونا من حالات الفشل، يتم وضع علامة عليه على أنه "غير متوفر". يتم قصر دائرة الطلبات اللاحقة إلى هذا القسم وإعادة توجيهها إلى مناطق أخرى أكثر صحة.
الاسترداد التلقائي: يتحقق مؤشر ترابط الخلفية بشكل دوري من الأقسام غير المتوفرة. بعد مدة معينة، يتم وضع علامة مبدئيا على هذه الأقسام على أنها "HealthTentative" وتخضع لطلبات الاختبار للتحقق من صحة الاسترداد.
Health Promotion/Demotion: استنادا إلى نجاح طلبات الاختبار هذه أو فشلها، يتم إما ترقية حالة القسم مرة أخرى إلى "صحي" أو تخفيضه مرة أخرى إلى "غير متوفر".
تساعد هذه الآلية على مراقبة صحة القسم باستمرار وتضمن تقديم الطلبات بأقل زمن انتقال وأقصى توفر، دون أن تتعثر بها الأقسام المسببة للمشاكل.
إشعار
ينطبق قاطع الدائرة فقط على حسابات الكتابة متعددة المناطق، كما هو الحال عند وضع علامة على قسم ك Unavailable، يتم نقل كل من القراءات والكتابة إلى المنطقة المفضلة التالية. هذا لمنع القراءات والكتابة من مناطق مختلفة يتم تقديمها من نفس مثيل العميل، لأن هذا سيكون نمطا مضادا.
هام
يجب أن تستخدم الإصدار 4.63.0 من Java SDK أو أعلى من أجل تنشيط قاطع دائرة مستوى القسم.
مقارنة تحسينات التوفر
استراتيجية التوفر المستندة إلى العتبة:
- الميزة: يقلل من زمن انتقال الاستجابة عن طريق إرسال طلبات قراءة متوازية إلى المناطق الثانوية، ويحسن التوفر عن طريق الطلبات الجاهزة التي ستؤدي إلى مهلات الشبكة.
- المفاضلة: تتحمل تكاليف وحدات الطلب الإضافية (وحدات الطلب) مقارنة بقاطع الدوائر، بسبب الطلبات المتوازية الإضافية عبر المناطق (على الرغم من ذلك فقط خلال الفترات التي يتم فيها اختراق الحدود).
- حالة الاستخدام: الأمثل لأحمال العمل الثقيلة للقراءة حيث يكون تقليل زمن الانتقال أمرا بالغ الأهمية وبعض التكلفة الإضافية (سواء من حيث رسوم وحدة الطلب أو ضغط وحدة المعالجة المركزية للعميل) مقبولة. يمكن أن تستفيد عمليات الكتابة أيضا، إذا تم اختيارها في نهج إعادة محاولة الكتابة غير المتكررة وكان للحساب عمليات كتابة متعددة المناطق.
قاطع دائرة مستوى القسم:
- الميزة: يحسن التوفر وزمن الانتقال عن طريق تجنب الأقسام غير الصحية، وضمان توجيه الطلبات إلى مناطق أكثر صحة.
- المفاضلة: لا تتحمل تكاليف وحدات الطلب الإضافية، ولكن لا يزال بإمكانها السماح ببعض فقدان التوفر الأولي للطلبات التي ستؤدي إلى مهلات الشبكة.
- حالة الاستخدام: مثالية لأحمال العمل الثقيلة أو المختلطة حيث يكون الأداء المتسق ضروريا، خاصة عند التعامل مع الأقسام التي قد تصبح غير صحية بشكل متقطع.
يمكن استخدام كلتا الاستراتيجيتين معا لتحسين توفر القراءة والكتابة وتقليل زمن انتقال الذيل. يمكن لقسم قاطع الدائرة على مستوى التعامل مع مجموعة متنوعة من سيناريوهات الفشل العابرة، بما في ذلك تلك التي قد تؤدي إلى بطء أداء النسخ المتماثلة، دون الحاجة إلى تنفيذ طلبات متوازية. بالإضافة إلى ذلك، ستؤدي إضافة استراتيجية التوفر المستندة إلى العتبة إلى تقليل زمن انتقال الاستجابة وتقليل فقدان التوفر، إذا كانت تكلفة وحدة الطلب الإضافية مقبولة.
من خلال تنفيذ هذه الاستراتيجيات، يمكن للمطورين ضمان أن تظل تطبيقاتهم مرنة، والحفاظ على الأداء العالي، وتوفير تجربة مستخدم أفضل حتى أثناء الانقطاع الإقليمي أو ظروف زمن الانتقال العالي.
تناسق جلسة العمل في نطاق المنطقة
نظرة عامة
لمزيد من المعلومات حول إعدادات التناسق بشكل عام، راجع مستويات التناسق في Azure Cosmos DB. يوفر Java SDK تحسينا لتناسق جلسة العمل لحسابات الكتابة متعددة المناطق، من خلال السماح لها بأن تكون محددة النطاق للمنطقة. يعمل هذا على تحسين الأداء من خلال التخفيف من زمن انتقال النسخ المتماثل عبر المناطق من خلال تقليل عمليات إعادة المحاولة من جانب العميل. ويتحقق ذلك من خلال إدارة رموز الجلسة المميزة على مستوى المنطقة بدلا من المستوى العالمي. إذا كان يمكن تحديد نطاق التناسق في التطبيق الخاص بك لعدد أقل من المناطق، من خلال تنفيذ تناسق الجلسة على نطاق المنطقة، يمكنك تحقيق أداء وموثوقية أفضل لعمليات القراءة والكتابة في حسابات الكتابة المتعددة عن طريق تقليل تأخيرات النسخ المتماثل عبر المناطق وإعادة المحاولة.
المزايا
- زمن الانتقال المنخفض: من خلال ترجمة التحقق من صحة الرمز المميز للجلسة إلى مستوى المنطقة، يتم تقليل فرص إعادة المحاولة المكلفة عبر المناطق.
- الأداء المحسن: يقلل من تأثير تجاوز الفشل الإقليمي وتأخر النسخ المتماثل، مما يوفر تناسقا أعلى للقراءة/الكتابة واستخداما أقل لوحدة المعالجة المركزية.
- الاستخدام الأمثل للموارد: يقلل من حمل وحدة المعالجة المركزية والشبكة على تطبيقات العميل عن طريق الحد من الحاجة إلى إعادة المحاولة والمكالمات عبر المناطق، وبالتالي تحسين استخدام الموارد.
- قابلية وصول عالية: من خلال الحفاظ على الرموز المميزة للجلسة على نطاق المنطقة، يمكن للتطبيقات الاستمرار في العمل بسلاسة حتى إذا واجهت مناطق معينة زمن انتقال أعلى أو فشل مؤقت.
- ضمانات التناسق: يضمن استيفاء ضمانات تناسق الجلسة (قراءة الكتابة والقراءة الرتيبة) بشكل أكثر موثوقية دون إعادة المحاولة غير الضرورية.
- كفاءة التكلفة: تقلل من عدد المكالمات عبر المناطق، ومن ثم من المحتمل أن تخفض التكاليف المرتبطة بنقل البيانات بين المناطق.
- قابلية التوسع: تسمح للتطبيقات بالتوسع بشكل أكثر كفاءة عن طريق تقليل الخلاف والنفقات العامة المرتبطة بالاحتفاظ برمز جلسة عمل عمومي، خاصة في الإعدادات متعددة المناطق.
المفاضلات
- زيادة استخدام الذاكرة: يتطلب عامل تصفية الفتح وتخزين الرمز المميز للجلسة الخاصة بالمنطقة ذاكرة إضافية، والتي قد تكون اعتبارا للتطبيقات ذات الموارد المحدودة.
- تعقيد التكوين: يؤدي ضبط عدد الإدراج المتوقع ومعدل الإيجابيات الخاطئة لعامل تصفية الفتح إلى إضافة طبقة من التعقيد إلى عملية التكوين.
- احتمالية الإيجابيات الزائفة: في حين أن عامل تصفية الفتح يقلل من عمليات إعادة المحاولة عبر المناطق، لا تزال هناك فرصة ضئيلة للإيجابيات الزائفة التي تؤثر على التحقق من صحة الرمز المميز للجلسة، على الرغم من أنه يمكن التحكم في المعدل. تعني النتيجة الإيجابية الخاطئة حل الرمز المميز للجلسة العالمية، مما يزيد من فرصة إعادة المحاولة عبر المناطق إذا لم تمسك المنطقة المحلية بهذه الجلسة العالمية. يتم استيفاء ضمانات الجلسة حتى في وجود إيجابيات خاطئة.
- القابلية للتطبيق: هذه الميزة هي الأكثر فائدة للتطبيقات ذات العلاقة الأساسية العالية للأقسام المنطقية وإعادة التشغيل العادية. قد لا ترى التطبيقات التي تحتوي على أقسام منطقية أقل أو عمليات إعادة تشغيل غير متكررة فوائد كبيرة.
طريقة العمل
تعيين الرمز المميز للجلسة
- إكمال الطلب: بعد اكتمال الطلب، يلتقط SDK رمز الجلسة ويربطه بالمنطقة ومفتاح القسم.
- التخزين على مستوى المنطقة: يتم تخزين الرموز المميزة للجلسة في متداخل
ConcurrentHashMapيحافظ على التعيينات بين نطاقات مفاتيح القسم والتقدم على مستوى المنطقة. - عامل تصفية Bloom: يتتبع عامل تصفية bloom المناطق التي تم الوصول إليها من قبل كل قسم منطقي، مما يساعد على ترجمة التحقق من صحة الرمز المميز للجلسة.
حل الرمز المميز للجلسة
- تهيئة الطلب: قبل إرسال طلب، يحاول SDK حل رمز الجلسة المميز للمنطقة المناسبة.
- التحقق من الرمز المميز: يتم التحقق من الرمز المميز مقابل البيانات الخاصة بالمنطقة للتأكد من توجيه الطلب إلى النسخة المتماثلة الأحدث.
- منطق إعادة المحاولة: إذا لم يتم التحقق من صحة الرمز المميز للجلسة داخل المنطقة الحالية، تعيد SDK المحاولة مع مناطق أخرى، ولكن نظرا للتخزين المترجم، يكون هذا أقل تكرارا.
استخدام SDK
فيما يلي كيفية تهيئة CosmosClient مع تناسق جلسة العمل على نطاق المنطقة:
CosmosClient client = new CosmosClientBuilder()
.endpoint("<your-endpoint>")
.key("<your-key>")
.consistencyLevel(ConsistencyLevel.SESSION)
.buildClient();
// Your operations here
تمكين تناسق جلسة العمل على نطاق المنطقة
لتمكين التقاط جلسة عمل محددة النطاق للمنطقة في التطبيق الخاص بك، قم بتعيين خاصية النظام التالية:
System.setProperty("COSMOS.SESSION_CAPTURING_TYPE", "REGION_SCOPED");
تكوين عامل تصفية bloom
ضبط الأداء عن طريق تكوين الإدراجات المتوقعة ومعدل إيجابي خاطئ لعامل تصفية الفتح:
System.setProperty("COSMOS.PK_BASED_BLOOM_FILTER_EXPECTED_INSERTION_COUNT", "5000000"); // adjust as needed
System.setProperty("COSMOS.PK_BASED_BLOOM_FILTER_EXPECTED_FFP_RATE", "0.001"); // adjust as needed
System.setProperty("COSMOS.SESSION_CAPTURING_TYPE", "REGION_SCOPED");
System.setProperty("COSMOS.PK_BASED_BLOOM_FILTER_EXPECTED_INSERTION_COUNT", "1000000");
System.setProperty("COSMOS.PK_BASED_BLOOM_FILTER_EXPECTED_FFP_RATE", "0.01");
الآثار المترتبة على الذاكرة
فيما يلي الحجم المحتفظ به (حجم العنصر وأيا كان ما يعتمد عليه) لحاوية الجلسة الداخلية (التي تديرها SDK) مع إدخالات متوقعة مختلفة في عامل تصفية الفتح.
| الإدراجات المتوقعة | معدل إيجابي خاطئ | الحجم المحتفظ به |
|---|---|---|
| 10, 000 | 0.001 | 21 كيلوبايت |
| 100, 000 | 0.001 | 183 كيلوبايت |
| 1 مليون | 0.001 | 1.8 ميغابايت |
| 10 مليون | 0.001 | 17.9 ميغابايت |
| 100 مليون | 0.001 | 179 ميغابايت |
| 1 مليار | 0.001 | 1.8 غيغابايت |
هام
يجب أن تستخدم الإصدار 4.60.0 من Java SDK أو أعلى من أجل تنشيط تناسق جلسة العمل على نطاق المنطقة.
ضبط تكوين الاتصال المباشر والبوابة
لتحسين تكوينات الاتصال المباشرة ووضع البوابة، راجع كيفية ضبط تكوينات الاتصال ل Java SDK v4.
استخدام SDK
- تثبيت أحدث إصدار من SDK
يتم تحسين حزم Azure Cosmos DB SDK باستمرار لتوفير أفضل أداء. لتحديد أحدث تحسينات SDK، قم بزيارة Azure Cosmos DB SDK.
كل مثيل عميل Azure Cosmos DB آمن لمؤشر الترابط ويقوم بإدارة اتصال فعالة وتخزين مؤقت للعنوان. للسماح بإدارة اتصال فعالة وأداء أفضل من قبل عميل Azure Cosmos DB، نوصي بشدة باستخدام مثيل واحد من عميل Azure Cosmos DB طوال عمر التطبيق.
عندما تقوم بإنشاء CosmosClient، فإن التناسق الظاهري المستخدم إذا لم يتم تعيينه بشكل صريح هو Session. إذا لم يكن اتساق الجلسة مطلوباً بواسطة منطق التطبيق، فقم بتعيين التناسق على نهائي. ملاحظة: يوصى باستخدام تناسق الجلسة على الأقل في التطبيقات التي تستخدم معالج موجز تغيير Azure Cosmos DB.
- استخدام Async API لتحقيق أقصى قدر من الإنتاجية المقدمة
Azure Cosmos DB Java SDK v4 يجمع بين واجهتي API هما Sync وAsync. بشكل تقريبي، تقوم Async API بتنفيذ وظائف SDK، في حين أن Sync API عبارة عن غلاف رقيق يقوم بإجراء مكالمات حظر إلى Async API. هذا يتعارض مع الإصدار 2 من Azure Cosmos DB Async Java SDK الأقدم، والذي كان غير متزامن فقط، وإلى Azure Cosmos DB Sync Java SDK v2 الأقدم، والذي كان Sync-only وكان له تطبيق منفصل.
يتم تحديد اختيار API في أثناء تكوين العميل؛ في حين أن CosmosAsyncClient يدعم Async API بينما CosmosClient يدعم Sync API.
تنفذ واجهة برمجة التطبيقات غير المتزامنة IO غير محظورة وهي الخيار الأمثل إذا كان هدفك هو الحد الأقصى من معدل النقل عند إصدار الطلبات إلى Azure Cosmos DB.
يمكن أن يكون استخدام واجهة برمجة تطبيقات المزامنة هو الخيار الصحيح إذا كنت تريد أو تحتاج إلى واجهة برمجة تطبيقات، والتي تحظر الاستجابة لكل طلب، أو إذا كانت العملية المتزامنة هي النموذج المهيمن في التطبيق الخاص بك. على سبيل المثال، قد ترغب في مزامنة API عند استمرار البيانات في Azure Cosmos DB في تطبيق الخدمات المصغرة، بشرط ألا تكون سرعة النقل مهمة.
لاحظ انخفاض معدل نقل واجهة برمجة التطبيقات للمزامنة مع زيادة وقت استجابة الطلب، بينما يمكن لواجهة برمجة التطبيقات غير المتزامنة تشبع قدرات النطاق الترددي الكامل للأجهزة الخاصة بك.
يمكن أن يمنحك التجميع الجغرافي معدل نقل أعلى وأكثر اتساقاً عند استخدام Sync API (راجع تجميع العملاء في منطقة Azure نفسها للأداء) ولكن لا يزال من غير المتوقع أن يتجاوز معدل نقل واجهة برمجة التطبيقات Async القابل للتحقيق.
قد يكون بعض المستخدمين أيضا غير معتادين على Project Reactor، إطار عمل Reactive Streams المستخدم لتنفيذ Azure Cosmos DB Java SDK v4 Async API. إذا كان هذا مصدر قلق، فننصحك بقراءة دليل أنماط المفاعل ثم إلقاء نظرة على مقدمة إلى البرمجة التفاعلية حتى تتعرف على نفسك. إذا كنت قد استخدمت Azure Cosmos DB بالفعل مع واجهة غير متزامنة، وكان SDK الذي استخدمته هو Azure Cosmos DB Async Java SDK v2، فقد تكون على دراية ب ReactiveX/RxJava ولكنك غير متأكد مما تغير في Project Reactor. في هذه الحالة، ألق نظرة على مفاعلنا مقابل دليل RxJava لتصبح مألوفة.
توضح مقتطفات التعليمات البرمجية التالية كيفية تهيئة عميل Azure Cosmos DB الخاص بك لواجهة برمجة تطبيقات Async أو عملية Sync API، على التوالي:
Java SDK V4 (Maven com.azure::azure-cosmos) Async API
CosmosAsyncClient client = new CosmosClientBuilder()
.endpoint(HOSTNAME)
.key(MASTERKEY)
.consistencyLevel(CONSISTENCY)
.buildAsyncClient();
- توسيع نطاق عبء عمل العميل
إذا كنت تختبر على مستويات معدل نقل عالية، فقد يصبح تطبيق العميل هو الازدحام بسبب الحد الأقصى للجهاز لاستخدام وحدة المعالجة المركزية أو الشبكة. إذا وصلت إلى هذه النقطة، يمكنك الاستمرار في دفع حساب Azure Cosmos DB بشكل أكبر عن طريق توسيع نطاق تطبيقات العميل عبر خوادم متعددة.
القاعدة الأساسية الجيدة هي عدم تجاوز >استخدام CPU 50% على أي خادم، للحفاظ على زمن الانتقال منخفضًا.
- استخدام برنامج الجدولة المناسب (تجنب سرقة سلاسل الأحداث IO Netty ذات حلقة الأحداث)
تعتمد الوظيفة غير المتزامنة لـ Azure Cosmos DB Java SDK على إدخال/إخراج غير معطل. يستخدم SDK عددًا ثابتًا من مؤشرات ترابط حلقة أحداث IO netty (مثل كثير من نوى CPU التي يمتلكها جهازك) لتنفيذ عمليات IO. ينبعث Flux الذي تم إرجاعه بواسطة API النتيجة على أحد سلاسل أحداث حلقة IO المشتركة. لذلك من المهم عدم حظر مؤشرات ترابط netty حلقة أحداث IO المشتركة. قد يؤدي القيام بعمل مكثف لوحدة المعالجة المركزية أو عملية الحظر على مؤشر ترابط netty لحلقة حدث IO إلى توقف تام أو تقليل معدل نقل SDK بشكل كبير.
على سبيل المثال، تنفذ التعليمة البرمجية التالية عملًا مكثفًا لـ cpu في مؤشر ترابط التكرار الحلقي للأحداث IO netty:
Mono<CosmosItemResponse<CustomPOJO>> createItemPub = asyncContainer.createItem(item);
createItemPub.subscribe(
itemResponse -> {
//this is executed on eventloop IO netty thread.
//the eventloop thread is shared and is meant to return back quickly.
//
// DON'T do this on eventloop IO netty thread.
veryCpuIntensiveWork();
});
بعد تلقي النتيجة، يجب تجنب القيام بأي عمل مكثف لوحدة المعالجة المركزية على النتيجة على مؤشر ترابط IO netty لحلقة الحدث. يمكنك بدلاً من ذلك توفير برنامج الجدولة الخاص بك لتوفير سلسلة المحادثات الخاصة بك لتشغيل عملك، كما هو موضح أدناه (يتطلب import reactor.core.scheduler.Schedulers).
Mono<CosmosItemResponse<CustomPOJO>> createItemPub = asyncContainer.createItem(item);
createItemPub
.publishOn(Schedulers.parallel())
.subscribe(
itemResponse -> {
//this is now executed on reactor scheduler's parallel thread.
//reactor scheduler's parallel thread is meant for CPU intensive work.
veryCpuIntensiveWork();
});
استنادا إلى نوع عملك، يجب عليك استخدام جدولة المفاعلات الموجودة المناسبة لعملك. اقرأ هنا Schedulers.
لمزيد من الفهم لنموذج الترابط والجدولة لمشروع Reactor، راجع منشور المدونة هذا بواسطة Project Reactor.
لمزيد من المعلومات حول Azure Cosmos DB Java SDK v4، انظر إلى دليل Azure Cosmos DB ل Azure SDK ل Java monorepo على GitHub.
- تحسين إعدادات التسجيل في التطبيق الخاص بك
لأسباب مختلفة، يجب إضافة تسجيل الدخول إلى مؤشر ترابط يقوم بإنشاء معدل نقل عالي للطلب. إذا كان هدفك هو التشبع الكامل للإنتاجية المزودة للحاوية بالطلبات التي تم إنشاؤها بواسطة مؤشر الترابط هذا، يمكن أن يؤدي تسجيل التحسينات إلى تحسين الأداء بشكل كبير.
- تكوين مسجل غير متزامن
يؤثر زمن انتقال أداة التسجيل المتزامنة بالضرورة في الحساب الإجمالي لزمن الاستجابة لمؤشر إنشاء الطلب. يوصى باستخدام أداة تسجيل غير متزامنة مثل log4j2 لفصل الحمل عن التسجيل من سلاسل عمليات التطبيق عالية الأداء.
- تعطيل تسجيل netty
تسجيل مكتبة Netty هو دردشة ويجب إيقاف تشغيلها (قد لا يكون منع تسجيل الدخول إلى التكوين كافيا) لتجنب تكاليف وحدة المعالجة المركزية الإضافية. إذا لم تكن في وضع التصحيح، فقم بتعطيل تسجيل netty تماماً. لذلك إذا كنت تستخدم Log4j لإزالة تكاليف وحدة المعالجة المركزية الإضافية التي تكبدتها org.apache.log4j.Category.callAppenders() من netty، فأضف السطر التالي إلى قاعدة التعليمات البرمجية الخاصة بك:
org.apache.log4j.Logger.getLogger("io.netty").setLevel(org.apache.log4j.Level.OFF);
- حد موارد ملفات فتح OS
تحتوي بعض أنظمة Linux (مثل Red Hat) على حد أعلى لعدد الملفات المفتوحة وبالتالي إجمالي عدد الاتصالات. شغل ما يلي لعرض الحدود الحالية:
ulimit -a
يجب أن يكون عدد الملفات المفتوحة (nofile) كبيرا بما يكفي للحصول على مساحة كافية لحجم تجمع الاتصال المكون والملفات المفتوحة الأخرى بواسطة نظام التشغيل. يمكن تعديله للسماح بحجم أكبر لتجمع الاتصال.
افتح ملف limits.conf:
vim /etc/security/limits.conf
قم بإضافة / تعديل الأسطر التالية:
* - nofile 100000
- تحديد مفتاح القسم في عمليات الكتابة النقطية
لتحسين أداء عمليات الكتابة بالنقاط، حدد مفتاح قسم العنصر في استدعاء API الخاص بكتابة النقطة، كما هو موضح أدناه:
Java SDK V4 (Maven com.azure::azure-cosmos) Async API
asyncContainer.createItem(item,new PartitionKey(pk),new CosmosItemRequestOptions()).block();
بدلا من توفير مثيل العنصر فقط، كما هو موضح أدناه:
Java SDK V4 (Maven com.azure::azure-cosmos) Async API
asyncContainer.createItem(item).block();
الأخير مدعوم ولكنه سيضيف زمن انتقال لتطبيقك، يجب على SDK تحليل العنصر واستخراج مفتاح القسم.
عمليات الاستعلام
لعمليات الاستعلام، راجع تلميحات الأداء للاستعلامات.
نهج الفهرسة
- استبعاد المسارات غير المستخدمة من الفهرسة لعمليات كتابة أسرع
يسمح لك نهج الفهرسة في Azure Cosmos DB بتحديد مسارات المستندات التي يجب تضمينها أو استبعادها من الفهرسة باستخدام مسارات الفهرسة (setIncludedPaths و setExcludedPaths). يمكن أن يوفر استخدام مسارات الفهرسة أداء كتابة محسناً وتخزين فهرس أقل للسيناريوهات التي تُعرف فيها أنماط الاستعلام سابقاً، حيث ترتبط تكاليف الفهرسة ارتباطاً مباشراً بعدد المسارات الفريدة المفهرسة. على سبيل المثال، يوضح الكود التالي كيفية تضمين واستبعاد أقسام كاملة من المستندات (تُعرف أيضاً باسم الشجرة الفرعية) من الفهرسة باستخدام حرف البدل "*".
CosmosContainerProperties containerProperties = new CosmosContainerProperties(containerName, "/lastName");
// Custom indexing policy
IndexingPolicy indexingPolicy = new IndexingPolicy();
indexingPolicy.setIndexingMode(IndexingMode.CONSISTENT);
// Included paths
List<IncludedPath> includedPaths = new ArrayList<>();
includedPaths.add(new IncludedPath("/*"));
indexingPolicy.setIncludedPaths(includedPaths);
// Excluded paths
List<ExcludedPath> excludedPaths = new ArrayList<>();
excludedPaths.add(new ExcludedPath("/name/*"));
indexingPolicy.setExcludedPaths(excludedPaths);
containerProperties.setIndexingPolicy(indexingPolicy);
ThroughputProperties throughputProperties = ThroughputProperties.createManualThroughput(400);
database.createContainerIfNotExists(containerProperties, throughputProperties);
CosmosAsyncContainer containerIfNotExists = database.getContainer(containerName);
للحصول على مزيد من المعلومات، راجع خدمة Azure Cosmos DB: نهج الفهرسة.
الإنتاجية
- قياس وضبط وحدات الطلب الأقل / الاستخدام الثاني
يوفر Azure Cosmos DB مجموعة غنية من عمليات قاعدة البيانات بما في ذلك الاستعلامات العلائقية والتسلسلية باستخدام UDFs، والإجراءات المخزنة، والمشغلات - تعمل جميعها على المستندات ضمن مجموعة قاعدة بيانات. تختلف التكلفة المقترنة بكل من هذه العمليات استناداً إلى وحدة المعالجة المركزية، والمدخلات/ المخرجات، والذاكرة المطلوبة لإكمال العملية. بدلًا من التفكير في موارد الأجهزة وإدارتها، يمكنك التفكير في وحدة الطلب (RU) كمقياس واحد للموارد المطلوبة لإجراء عمليات قاعدة بيانات متنوعة وخدمة طلب تطبيق.
يتم توفير معدل النقل بناءً على عدد وحدات الطلب التي تم تعيينها لكل حاوية. يتم تقييم استهلاك وحدة الطلب كمعدل في الثانية. التطبيقات التي تتجاوز معدل وحدة الطلب المخصص لحاوياتها تكون محدودة حتى ينخفض المعدل إلى ما دون المستوى المخصص للحاوية. إذا كان تطبيقك يتطلب مستوى معدل نقل أعلى، يمكنك زيادة معدل نقلك من خلال توفير وحدات طلب إضافية.
يؤثر تعقيد الاستعلام على عدد وحدات الطلب التي يتم استهلاكها لعمليةٍ ما. عدد الدالات وطبيعتها وعدد دالات UDF وحجم مجموعة بيانات المصدر جميعها عوامل تؤثر على تكلفة عمليات الاستعلام.
لقياس النفقات العامة لأي عملية (إنشاء أو تحديث أو حذف)، افحص عنوان x-ms-request-charge لقياس عدد وحدات الطلب التي تستهلكها هذه العمليات. يمكنك أيضًا الاطلاع على خاصية RequestCharge المكافئة في ResourceResponse<T> أو FeedResponse<T>.
Java SDK V4 (Maven com.azure::azure-cosmos) Async API
CosmosItemResponse<CustomPOJO> response = asyncContainer.createItem(item).block();
response.getRequestCharge();
تُعد رسوم الطلب التي تم إرجاعها في هذا العنوان جزءًا صغيرًا من معدل النقل المقدم. على سبيل المثال، إذا كان لديك 2000 وحدة طلب/ثانية تم توفيرها، وإذا قام الاستعلام السابق بإرجاع 1000 مستند 1 كيلوبايت، فإن تكلفة العملية هي 1000. على هذا النحو، في غضون ثانية واحدة، ينفذ الخادم طلبَيْن فقط من هذا القبيل قبل أن يحد المعدل الطلبات اللاحقة. لمزيد من المعلومات، راجع وحدات الطلب وحاسبة وحدات الطلب.
- تقييد معدل المعالجة/معدل الطلب كبير جدًّا
عند محاولة عميل تجاوز معدل النقل المحجوز لأحد الحسابات، فلا يكون هناك انخفاض في الأداء في الخادم ولا استخدام لسعة معدل نقل يتجاوز المستوى المحجوز. سينهي الخادم الطلب بشكل استباقي باستخدام RequestRateTooLarge (رمز حالة HTTP 429) ويعيد عنوان x-ms-retry-after-ms الذي يشير إلى مقدار الوقت، بالمللي ثانية، الذي يجب على المستخدم انتظاره قبل إعادة محاولة الطلب.
HTTP Status 429,
Status Line: RequestRateTooLarge
x-ms-retry-after-ms :100
تلتقط جميع حزم SDK هذه الاستجابة ضمنياً، وتحترم عنواناً بعد إعادة المحاولة المحدد من الخادم، ثم تعيد محاولة الطلب. ما لم يتم الوصول إلى حسابك بشكل متزامن من قبل عدة عملاء، فستنجح المحاولة التالية.
إذا كان لديك أكثر من عميل واحد يعمل بشكل تراكمي بشكل متناسق فوق معدل الطلب، فقد لا يكفي عدد إعادة المحاولة الافتراضي المعين حاليا إلى 9 داخليا من قبل العميل؛ في هذه الحالة، يطرح العميل CosmosClientException مع رمز الحالة 429 إلى التطبيق. يمكن تغيير عدد مرات إعادة المحاولة الافتراضي باستخدام setMaxRetryAttemptsOnThrottledRequests() على المثيل ThrottlingRetryOptions . بشكل ظاهري يتم إرجاع CosmosClientException برمز الحالة 429 بعد وقت انتظار تراكمي قدره 30 ثانية إذا استمر الطلب في العمل فوق معدل الطلب. يحدث هذا حتى عندما يكون عدد عمليات إعادة المحاولة الحالية أقل من الحد الأقصى لعدد مرات إعادة المحاولة، سواء كانت القيمة الظاهرية 9 أو قيمة معرَّفة من قِبَل المستخدم.
في حين أن سلوك إعادة المحاولة الآلي يساعد على تحسين المرونة وسهولة الاستخدام لمعظم التطبيقات، إلا أنه قد يتعارض عند القيام بمعايير الأداء، خاصة عند قياس معدل الانتقال. سوف يرتفع وقت الانتقال الذي يَلْحَظه العميل إذا وصلت التجربة إلى تقييد الخادم وتسببت في إعادة محاولة SDK للعميل بصمت. لتجنب ارتفاع وقت الانتقال أثناء تجارب الأداء، قم بقياس الرسوم التي يتم إرجاعها بواسطة كل عملية وتأكد من أن الطلبات تعمل بأقل من معدل الطلب المحجوز. لمزيد من المعلومات، راجع وحدات الطلب.
- تصميم مستندات أصغر حجمًا للحصول على معدل نقل أعلى
ترتبط رسوم الطلب (تكلفة معالجة الطلب) لعملية معينة ارتباطا مباشرا بحجم المستند. تكلف العمليات على المستندات الكبيرة أكثر من عمليات المستندات الصغيرة. من الناحية المثالية، قم بهندسة التطبيق وسير العمل ليكون حجم العنصر الخاص بك ~1 كيلوبايت، أو ترتيبا أو حجما مشابها. بالنسبة للتطبيقات الحساسة لزمن الانتقال، يجب تجنب العناصر الكبيرة - تبطئ المستندات متعددة ميغابايت تطبيقك.
الخطوات التالية
لمعرفة مزيد حول تصميم تطبيقك بحيث يتناسب مع الحجم والأداء العالي، راجع التقسيم والقياس في Azure Cosmos DB.
هل تحاول القيام بتخطيط السعة للترحيل إلى Azure Cosmos DB؟ يمكنك استخدام معلومات حول نظام مجموعة قاعدة البيانات الموجودة لديك لـ تخطيط السعة.
- إذا لم تكن تعرف سوى عدد vCores والخوادم في نظام مجموعة قاعدة البيانات الحالية فقط، فاقرأ عن تقدير وحدات الطلب باستخدام vCores أو vCPUs
- إذا كان كل ما تعرفه هو عدد vcores والخوادم الموجودة في مجموعة قاعدة البيانات، اقرأ عن تقدير وحدات الطلب باستخدام vCores أو vCPUs