مشاركة عبر

تلميحات حول أداء 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

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

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

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

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

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

لمزيد من المعلومات، راجع إرشادات Windows وLinux.

ضبط تكوين الاتصال المباشر والبوابة

لتحسين تكوينات الاتصال المباشرة ووضع البوابة، راجع كيفية ضبط تكوينات الاتصال ل java sdk v4.

استخدام SDK

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

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

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

كل مثيل عميل 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؟ يمكنك استخدام معلومات حول نظام مجموعة قاعدة البيانات الموجودة لديك لـ تخطيط السعة.