مشاركة عبر

نصائح الأداء ل Azure Cosmos DB Sync Java SDK v2

  • ينطبق على: ✅ NoSQL

مهم

هذا ليس أحدث Java SDK لـ Azure Cosmos DB! يجب عليك ترقية مشروعك إلى Azure Cosmos DB Java SDK v4 ثم قراءة دليل نصائح الأداء Azure Cosmos DB Java SDK v4. اتبع التعليمات في دليل Migration to Azure Cosmos DB Java SDK v4 ودليل Reactor vs RxJava للترقية.

هذه النصائح للأداء مخصصة فقط للعبة Azure Cosmos DB Sync Java SDK v2. يرجى زيارة مستودع Maven لمزيد من المعلومات.

مهم

في 29 فبراير 2024، سيتم إيقاف Azure Cosmos DB Sync Java SDK v2.x؛ ستستمر مجموعة تطوير التطوير وجميع التطبيقات التي تستخدم الحزمة في العمل؛ سيتوقف Azure Cosmos DB ببساطة عن توفير المزيد من الصيانة والدعم لهذه الحزمة SDK. نوصي باتباع الإرشادات المذكورة أعلاه للترحيل إلى Azure Cosmos DB Java SDK v4.

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

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

Networking

  1. وضع الاتصال: استخدم DirectHttps

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

    1. بوابة (افتراضية)

    2. DirectHttps

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

      يستخدم Azure Cosmos DB Sync Java SDK v2 بروتوكول HTTPS كبروتوكول نقل. يستخدم HTTPS نظام TLS للمصادقة الأولية وتشفير حركة المرور. عند استخدام Azure Cosmos DB Sync Java SDK v2، يجب فتح منفذ HTTPS 443 فقط.

      يتم تكوين وضع الاتصال أثناء بناء مثيل DocumentClient باستخدام معامل ConnectionPolicy.

    Sync Java SDK V2 (Maven com.microsoft.azure::azure-documentdb)

    public ConnectionPolicy getConnectionPolicy() {
  ConnectionPolicy policy = new ConnectionPolicy();
  policy.setConnectionMode(ConnectionMode.DirectHttps);
  policy.setMaxPoolSize(1000);
  return policy;
}

ConnectionPolicy connectionPolicy = new ConnectionPolicy();
DocumentClient client = new DocumentClient(HOST, MASTER_KEY, connectionPolicy, null);

    يوضح المخطط سياسة الاتصال في Azure Cosmos DB.

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

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

    يوضح المخطط الطلبات والردود في منطقتين، حيث تتصل الحواسيب بحساب قاعدة بيانات Azure Cosmos عبر خدمات متوسطة المستوى.

استخدام SDK

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

    يتم تحسين حزم Azure Cosmos DB SDK باستمرار لتوفير أفضل أداء. لتحديد أحدث تحسينات SDK، قم بزيارة Azure Cosmos DB SDK.

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

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

  3. زيادة حجم MaxPoolSize لكل مضيف عند استخدام وضع البوابة

    ترسل طلبات قاعدة بيانات Azure Cosmos عبر HTTPS/REST عند استخدام وضع البوابة، وتخضع لحد الاتصال الافتراضي لكل اسم مضيف أو عنوان IP. قد تحتاج إلى ضبط MaxPoolSize على قيمة أعلى (200-1000) حتى تتمكن مكتبة العميل من الاستفادة من عدة اتصالات متزامنة إلى قاعدة بيانات Azure Cosmos. في Azure Cosmos DB Sync Java SDK v2، القيمة الافتراضية ل ConnectionPolicy.getMaxPoolSize هي 100. استخدم setMaxPoolSize لتغيير القيمة.

  4. ضبط الاستعلامات المتوازية للمجموعات المقسمة

    يدعم Azure Cosmos DB Sync Java SDK الإصدار 1.9.0 وما فوق استعلامات متوازية، والتي تتيح لك الاستعلام عن مجموعة مقسمة بالتوازي. لمزيد من المعلومات، راجع عينات الشيفرة المتعلقة بالعمل مع مجموعات تطوير البرمجيات. تم تصميم الاستعلامات المتوازية لتحسين زمن استجابة الاستعلام وسرعة النقل مقارنة بنظيراتها التسلسلية.

    (أ) ضبط مجموعة MaxDegreeOfParallelism: تعمل الاستعلامات المتوازية عن طريق الاستعلام عن عدة أقسام متوازية. ومع ذلك، يتم جلب البيانات من مجموعة مقسمة فردية بشكل تسلسلي بالنسبة للاستعلام. لذا، استخدم setMaxDegreeOfParallelism لتحديد عدد التقسيمات التي لديها أقصى فرصة لتحقيق الاستعلام الأكثر أداء، بشرط أن تبقى جميع شروط النظام الأخرى كما هي. إذا لم تكن تعرف عدد الأقسام، يمكنك استخدام setMaxDegreeOfParallelism لتحديد عدد عال، والنظام يختار الحد الأدنى (عدد الأقسام، المدخلات المقدمة من المستخدم) كأقصى درجة للتوازي.

    من المهم ملاحظة أن الاستعلامات المتوازية تحقق أفضل الفوائد إذا كانت البيانات موزعة بالتساوي عبر جميع الأقسام بالنسبة للاستعلام. إذا تم تقسيم المجموعة المقسمة بحيث تتركز كل أو معظم البيانات المرتجعة من قبل الاستعلام في عدد قليل من الأقسام (قسم واحد في أسوأ الحالات)، فإن أداء الاستعلام سيتعقد بسبب تلك التقسيمات.

    (ب) ضبط setMaxBufferedItemCount: تم تصميم الاستعلام المتوازي لجلب النتائج مسبقا أثناء معالجة الدفعة الحالية من النتائج بواسطة العميل. يساعد الجلب المسبق في تحسين زمن الانتقال الكلي للاستعلام. setMaxBufferedItemCount يحد من عدد النتائج المسبقة الجلب المسبق. من خلال تعيين setMaxBufferedItemCount على العدد المتوقع للنتائج المرتجلة (أو رقم أعلى)، يمكن هذا الاستعلام من الحصول على أقصى فائدة من الجلب المسبق.

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

  5. تنفيذ backoff عند فترات getRetryAfterInMilliseconds

    أثناء اختبار الأداء، يجب زيادة الحمل حتى يتم تقليل معدل الطلبات قليلا. إذا تم التقييد (throttle)، يجب أن يتراجع تطبيق العميل عن التخفيف لفترة إعادة المحاولة المحددة من قبل الخادم. احترام التراجع يضمن أنك تقضي وقتا ضئيلا في الانتظار بين المحاولات. دعم سياسة إعادة المحاولة مشمول في الإصدار 1.8.0 وما فوق من Azure Cosmos DB Sync Java SDK. لمزيد من المعلومات، راجع getRetryAfterInMilliseconds.

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

    إذا كنت تختبر بمستويات إنتاجية عالية (>50,000 RU/s)، فقد يصبح تطبيق العميل هو عنق الزجاجة بسبب انتهاء استخدام الجهاز للمعالج أو الشبكة. إذا وصلت إلى هذه النقطة، يمكنك الاستمرار في دفع حساب Azure Cosmos DB بشكل أكبر عن طريق توسيع نطاق تطبيقات العميل عبر خوادم متعددة.

  7. استخدم العنونة القائمة على الاسم

    استخدم العناوين القائمة على الاسم، حيث تكون الروابط بصيغة dbs/MyDatabaseId/colls/MyCollectionId/docs/MyDocumentId، بدلا من SelfLinks (_self)، التي تحتوي على التنسيق dbs/<database_rid>/colls/<collection_rid>/docs/<document_rid> لتجنب استرجاع ResourceIds لجميع الموارد المستخدمة لبناء الرابط. أيضا، مع إعادة إنشاء هذه الموارد (ربما بنفس الاسم)، قد لا يساعد تخزينها مؤقتا.

  8. قم بضبط حجم الصفحة لتستعلامات/تغذية القراءة لتحسين الأداء

    عند إجراء قراءة جماعية للمستندات باستخدام وظيفة تغذية القراءة (مثل readDocuments) أو عند إصدار استعلام SQL، تعاد النتائج بطريقة مجزأة إذا كانت مجموعة النتائج كبيرة جدا. بشكل افتراضي، يتم إرجاع النتائج على شكل أجزاء من 100 عنصر أو 1 ميجابايت، أيا كان الحد الذي يتم الوصول إليه أولا.

    لتقليل عدد رحلات الشبكة ذهابا وإيابا المطلوبة لاسترجاع جميع النتائج المناسبة، يمكنك زيادة حجم الصفحة باستخدام رأس طلب x-ms-max-item-count إلى ما يصل إلى 1000. في الحالات التي تحتاج فيها إلى عرض عدد قليل فقط من النتائج، على سبيل المثال، إذا كانت واجهة المستخدم أو واجهة التطبيق الخاصة بك تعطي 10 نتائج فقط في كل مرة، يمكنك أيضا تقليل حجم الصفحة إلى 10 لتقليل معدل النقل المستهلك للقراءة والاستعلامات.

    يمكنك أيضا تعيين حجم الصفحة باستخدام طريقة setPageSize.

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

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

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

    Sync Java SDK V2 (Maven com.microsoft.azure::azure-documentdb)

    Index numberIndex = Index.Range(DataType.Number);
numberIndex.set("precision", -1);
indexes.add(numberIndex);
includedPath.setIndexes(indexes);
includedPaths.add(includedPath);
indexingPolicy.setIncludedPaths(includedPaths);
collectionDefinition.setIndexingPolicy(indexingPolicy);

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

الإنتاجية

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

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

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

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

    لقياس العبء الزائد لأي عملية (إنشاء، تحديث، أو حذف)، قم بفحص رأس x-ms-request-charge (أو خاصية RequestCharge المكافئة في ResourceResponse<T> أو FeedResponse<T> لقياس عدد وحدات الطلب التي تستهلكها هذه العمليات).

    Sync Java SDK V2 (Maven com.microsoft.azure::azure-documentdb)

    ResourceResponse<Document> response = client.createDocument(collectionLink, documentDefinition, null, false);

response.getRequestCharge();

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

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

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

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

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

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

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

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

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

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

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

  • Last updated on