تلميحات حول أداء Azure Cosmos DB Sync Java SDK الإصدار 2

  • مقالة

ينطبق على: NoSQL

هام

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

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

هام

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

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

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

الشبكات

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

    إن كيفية اتصال العميل بـ Azure Cosmos DB لها آثار مهمة على الأداء، لا سيما فيما يتعلق بزمن الانتقال الملحوظ من جانب العميل. يتوافر إعداد تكوين مفتاح واحد لتكوين العميل ConnectionPolicy - ConnectionMode. وضعا ConnectionModes المتاحان هما:

    1. البوابة (الظاهرية)

    2. DirectHttps

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

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

      يتم تكوين ConnectionMode أثناء إنشاء مثيل DocumentClientباستخدام معلمة ConnectionPolicy.

    Sync Java SDK الإصدار 2 (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 DB من خلال خدمات الطبقة المتوسطة.

استخدام SDK

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

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

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

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

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

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

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

    يدعم Azure Cosmos DB Sync Java SDK الإصدار 1.9.0 والإصدارات الأحدث الاستعلامات المتوازية، والتي تمكِّنك من الاستعلام عن مجموعة مقسَّمة بشكل متوازٍ. لمزيد من المعلومات، راجع نماذج التعليمات البرمجية المتعلقة بالعمل مع SDKs. تم تصميم الاستعلامات الموازية لتحسين زمن انتقال الاستعلام وإنتاجيته على نظيرتها التسلسلية.

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

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

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

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

  5. تنفيذ التراجع في الفواصل الزمنية getRetryAfterInMilliseconds

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

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

    إذا كنت تختبر بمستويات معدل نقل عالية (>50000 وحدة طلب/ثانية)، فقد يصبح تطبيق العميل مزدحماً بسبب تقييد الجهاز لاستخدام وحدة المعالجة المركزية أو الشبكة. إذا وصلت إلى هذه النقطة، يمكنك الاستمرار في دفع حساب 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 الإصدار 2 (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 الإصدار 2 (Maven com.microsoft.azure::azure-documentdb)

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

response.getRequestCharge();

    تُعد رسوم الطلب التي تم إرجاعها في هذا العنوان جزءًا صغيرًا من معدل النقل المقدم. على سبيل المثال، إذا كان لديك 2000 RU/s تم توفيرها، وإذا كان الاستعلام السابق يرجع 1000 1 كيلوبايت-documents، فإن تكلفة العملية هي 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 . بشكل ظاهري يتم إرجاع DocumentClientException برمز الحالة 429 بعد وقت انتظار تراكمي قدره 30 ثانية، إذا استمر الطلب في العمل فوق معدل الطلب. يحدث هذا حتى عندما يكون عدد عمليات إعادة المحاولة الحالية أقل من الحد الأقصى لعدد مرات إعادة المحاولة، سواء كانت القيمة الظاهرية 9 أو قيمة معرَّفة من قِبَل المستخدم.

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

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

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

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

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