تحسين تكلفة الإنتاجية المقدمة في Azure Cosmos DB

ينطبق على: NoSQL MongoDB كاساندرا العفريت جدول

من خلال تقديم نموذج معدل النقل المقدمة، يقدم Azure Cosmos DB أداء يمكن التنبؤ به على أي نطاق. إن حفظ أو توفير معدل النقل مسبقاً يمحو "أثر الجار المزعج" من أدائك. يمكنك تحديد مقدار معدل النقل التي تحتاجها وAzure Cosmos DB يضمن معدل النقل المكونة، مدعومة من قبل SLA.

يمكنك البدء بحد أدنى من معدل النقل 400 وحدة/ث وتوسيع نطاق عشرات الملايين من الطلبات في الثانية أو أكثر. كل طلب تصدره مقابل حاوية أو قاعدة بيانات Azure Cosmos DB، مثل طلب القراءة وطلب الكتابة وطلب الاستعلام والإجراءات المخزنة لها تكلفة مقابلة يتم خصمها من معدل النقل المقدم. إذا قمت بتوفير 400 وحدة طلب/ثانية وصدرت استعلاما يكلف 40 وحدة طلب/ ثانية، فستتمكن من إصدار 10 استعلامات من هذا القبيل في الثانية. أي طلب يتجاوز ذلك الحصول على معدل محدود ويجب إعادة محاولة الطلب. إذا كنت تستخدم برامج تشغيل العميل، فإنها تدعم منطق إعادة المحاولة التلقائي.

يمكنك توفير معدل النقل على قواعد البيانات أو الحاويات ويمكن أن تساعدك كل إستراتيجية على توفير التكاليف اعتماداً على السيناريو.

التحسين من خلال توفير معدل النقل على مستويات مختلفة

• إذا قمت بتوفير معدل النقل على قاعدة بيانات، يمكن مشاركة جميع الحاويات، على سبيل المثال مجموعات/جداول/رسوم بيانية داخل قاعدة البيانات تلك معدل النقل استناداً إلى التحميل. تتم مشاركة معدل النقل المحجوزة على مستوى قاعدة البيانات بشكل غير متساو، اعتماداً على حمل العمل على مجموعة معينة من الحاويات.

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

وفيما يلي بعض المبادئ التوجيهية لاتخاذ قرار بشأن إستراتيجية معدل النقل المقدمة:

ضع في اعتبارك توفير معدل النقل على قاعدة بيانات Azure Cosmos DB (التي تحتوي على مجموعة من الحاويات) إذا:

1. لديك بضع عشرات من حاويات Azure Cosmos DB وتريد مشاركة معدل النقل عبر بعضها أو كلها.

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

3. تريد استيعاب طفرات غير مخطط لها في أحمال العمل بحكم معدل النقل المجمعة على مستوى قاعدة البيانات المعرضة لارتفاع غير متوقع في حمل العمل.

4. بدلاً من تعيين سرعة نقل محددة على حاويات فردية، يهمك الحصول على معدل النقل الإجمالية عبر مجموعة من الحاويات داخل قاعدة البيانات.

النظر في توفير معدل النقل على حاوية فردية إذا:

1. لديك عدد قليل من حاويات Azure Cosmos DB. نظرا لأن Azure Cosmos DB غير محدد المخطط، يمكن أن تحتوي الحاوية على عناصر تحتوي على مخططات غير متجانسة ولا تتطلب من العملاء إنشاء أنواع حاويات متعددة، واحدة لكل كيان. إنه دائما خيار للنظر في ما إذا كان تجميع الحاويات المنفصلة يعني أن 10-20 حاوية في حاوية واحدة منطقية. مع الحد الأدنى من 400 وحدة طلب/ث للحاويات، يمكن أن يكون تجميع جميع الحاويات البالغ عددها 10-20 في حاوية واحدة أكثر فعالية من حيث التكلفة.

2. تريد التحكم في معدل النقل على حاوية معينة والحصول على معدل النقل المضمونة على حاوية معينة مدعومة من قبل SLA.

ضع باعتبارك مزيجاً من الإستراتيجيتين المذكورتين أعلاه:

1. كما ذكرنا سابقا، يسمح لك Azure Cosmos DB بخلط ومطابقة الاستراتيجيتين المذكورتين أعلاه، بحيث يمكنك الآن الحصول على بعض الحاويات داخل قاعدة بيانات Azure Cosmos DB، والتي قد تشارك معدل النقل المقدم على قاعدة البيانات بالإضافة إلى بعض الحاويات داخل نفس قاعدة البيانات، والتي قد تحتوي على كميات مخصصة من معدل النقل المقدم.

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

كما هو موضح في الجدول التالي، اعتماداً على اختيار واجهة برمجة التطبيقات، يمكنك توفير معدل النقل في التفاصيل المختلفة.

واجهة برمجة التطبيقات (API)	بالنسبة إلى معدل النقل المشتركة، قم بتكوين	للحصول على معدل النقل المخصصة، قم بتكوين
واجهة برمجة التطبيقات ل NoSQL	قاعدة البيانات	الحاوية
واجهة برمجة تطبيقات Azure Cosmos DB ل MongoDB	قاعدة البيانات	المجموعة
واجهة برمجة التطبيقات ل Cassandra	مساحة المفتاح	جدول
واجهة برمجة التطبيقات ل Gremlin	حساب قاعدة البيانات	رسم بياني
واجهة برمجة التطبيقات للجدول	حساب قاعدة البيانات	جدول

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

التحسين مع تحديد السعر لطلباتك

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

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

إعادة محاولة المنطق في SDKs

SDKs الأصلية (.NET/.NET Core, Java, Node.js وPython) تلتقط ضمنياً هذه الاستجابة، اتباع عنوان retry-after المحدد من قبل الخادم ثم أعد محاولة الطلب. ما لم يتمكن عدة عملاء من الوصول إلى حسابك بشكل متزامن، ستنجح إعادة المحاولة التالية.

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

يتم تعيين MaxRetryAttemptsOnThrottledRequests إلى 3، لذا في هذه الحالة، إذا كان معدل عملية الطلب محدوداً بتجاوز معدل النقل المحجوزة للحاوية، تتم إعادة محاولة عملية الطلب ثلاث مرات قبل طرح الاستثناء إلى التطبيق. يتم تعيين MaxRetryWaitTimeInSeconds إلى 60، وفي هذه الحالة إذا كان زمن الانتظار التراكمي لإعادة المحاولة بالثواني منذ الطلب الأول يتجاوز 60 ثانية، يتم طرح الاستثناء.

ConnectionPolicy connectionPolicy = new ConnectionPolicy(); 
connectionPolicy.RetryOptions.MaxRetryAttemptsOnThrottledRequests = 3; 
connectionPolicy.RetryOptions.MaxRetryWaitTimeInSeconds = 60;

استراتيجية التقسيم وتكاليف معدل النقل المتوفر

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

• اختر مفتاح قسم يوزع حمل العمل بالتساوي عبر جميع الأقسام وبالتساوي مع مرور الوقت. وبعبارة أخرى، لا يجب أن يكون لديك بعض المفاتيح مع معظم البيانات وبعض المفاتيح مع بيانات أقل أو معدومة.

• اختر مفتاح قسم يتيح انتشار أنماط الوصول بالتساوي عبر الأقسام المنطقية. حمل العمل معقول حتى عبر جميع المفاتيح. وبعبارة أخرى، فإن غالبية حمل العمل لا ينبغي أن تركز على مفاتيح محددة قليلة.

• اختر مفتاح قسم يحتوي على مجموعة واسعة من القيم.

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

تصميم عناصر أصغر لسرعة نقل أعلى

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

أنماط الوصول إلى البيانات

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

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

التحسين عن طريق تغيير سياسة الفهرسة

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

مراقبة معدل النقل المقدم والمستهلك

يمكنك مراقبة العدد الإجمالي لوحدات الطلب المقدمة وعدد الطلبات محدودة المعدل وعدد وحدات الطلب التي استهلكتها في مدخل Microsoft Azure. لمعرفة المزيد، راجع تحليل مقاييس Azure Cosmos DB. تعرض الصورة التالية مثالاً على قياس الاستخدام:

يمكنك أيضاً تعيين تنبيهات للتحقق مما إذا كان عدد الطلبات محدود السعر يتجاوز عتبة معينة. لمعرفة المزيد حول التنبيهات، راجع تنبيهات Azure Monitor.

مقياس معدل النقل بشكل مرن عند الطلب

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

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

• أحد المجالات التي يجب أن مقياس معدل النقل عند استيعاب البيانات في Azure Cosmos DB، على سبيل المثال، أثناء ترحيل البيانات. بمجرد اكتمال الترحيل، يمكنك تغيير حجم معدل النقل المقدّم لإبقاء الحل في الوضع المستقر.

• تذكر أن الفوترة في نقاوة ساعة واحدة، لذلك لا توفر أي أموال إذا قمت بتغيير معدل النقل المقدم أكثر من ساعة واحدة في كل مرة.

تحديد معدل النقل المطلوب لحمل عمل جديد

لتحديد معدل النقل المخصصة لحمل عمل جديد، يمكنك استخدام الخطوات التالية:

1. إجراء تقييم أولي تقريبي باستخدام مخطط السعة وضبط تقديراتك بمساعدة مستكشف Azure Cosmos DB في مدخل Azure.

2. من المستحسن إنشاء الحاويات ذات معدل أقل العالية مما كان متوقعاً ثم تقليصها حسب الحاجة.

3. من المستحسن استخدام أحد خدمة Azure Cosmos DB SDKs الأصلية للاستفادة من عمليات الإعادة التلقائية عندما تكون الطلبات محدودة السعر. إذا كنت تعمل على نظام أساسي غير مدعوم وتستخدم واجهة برمجة تطبيقات REST ل Azure Cosmos DB، فنفذ نهج إعادة المحاولة الخاص بك باستخدام x-ms-retry-after-ms العنوان.

4. تأكد من أن التعليمات البرمجية للتطبيق الخاص بك تدعم الحالة عند فشل جميع عمليات إعادة المحاولة.

5. يمكنك تكوين التنبيهات من مدخل Azure للحصول على إعلامات لتحديد المعدل. يمكنك البدء بحدود متحفظة مثل 10 طلبات محدودة السعر على مدى الدقائق الـ15 الماضية والتحول إلى قواعد أكثر حرصاً بمجرد معرفة استهلاكك الفعلي. لا ضرر مع وجود قيود الوقت المؤقتة، حيث إنها توضح أنك تتلاعب بالحدود التي وضعتها وهذا بالضبط ما نريد فعله.

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

7. راقب نسبة معدل النقل المتوفرة مقابل المستهلكة بانتظام للتأكد من أنك لم تقم بتوفير أكثر من العدد المطلوب من الحاويات وقواعد البيانات. وجود ما يزيد قليلاً على معدل النقل المقدم هو فحص السلامة جيدة.

أفضل الممارسات لتحسين معدل النقل المقدم

تساعدك الخطوات التالية على جعل حلولك قابلة للتوسعة وفعالة من حيث التكلفة عند استخدام Azure Cosmos DB.

1. إذا كان لديك بشكل ملحوظ معدل النقل الذي تم توفيره عبر حاويات وقواعد البيانات، يجب مراجعة وحدات الطلب/ث التي تم توفيرها مقابل وحدات الطلب/ث المستهلكة وضبط أحمال العمل.

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

3. طريقة أخرى للحصول على العمليات وتكاليفها في وحدات وحدة طلب/ث هي عن طريق تمكين سجلات Azure Monitor، والتي ستعطيك تفاصيل العملية / المدة ورسوم الطلب. يوفر Azure Cosmos DB رسوم طلب لكل عملية، لذلك يمكن تخزين كل شحنة عملية مرة أخرى من الاستجابة ومن ثم استخدامها للتحليل.

4. يمكنك توسيع نطاق مرونة صعوداً وهبوطاً لمعدل النقل المقدم كما تحتاج لتلبية احتياجات حمل العمل الخاص بك.

5. يمكنك إضافة المناطق المقترنة بحساب Azure Cosmos DB الخاص بك وإزالتها حسب حاجتك والتحكم في التكاليف.

6. تأكد من أن لديك توزيع البيانات وأحمال العمل عبر أقسام منطقية من الحاويات الخاصة بك. إذا كان لديك توزيع قسم غير متساو، فقد يؤدي هذا إلى توفير قدر أعلى من معدل النقل من القيمة المطلوبة. إذا قمت بتعريف أن لديك توزيعاً منحرفاً نوصي بإعادة توزيع حمل العمل بالتساوي عبر الأقسام أو إعادة تقسيم البيانات.

7. إذا كان لديك العديد من الحاويات ولا تتطلب هذه الحاويات اتفاقيات مستوى الخدمة، يمكنك استخدام العرض المستند إلى قاعدة البيانات للحالات التي لا تنطبق فيها اتفاقيات مستوى الخدمة لمعدل النقل لكل حاوية. يجب تحديد أي من حاويات Azure Cosmos DB التي تريد ترحيلها إلى عرض معدل النقل على مستوى قاعدة البيانات ثم ترحيلها باستخدام حل يستند إلى موجز التغيير.

8. فكر في استخدام "Azure Cosmos DB Free Tier" (مجانا لمدة عام واحد)، أو جرب Azure Cosmos DB (حتى ثلاث مناطق) أو محاكي Azure Cosmos DB القابل للتنزيل لسيناريوهات التطوير/الاختبار. باستخدام هذه الخيارات لاختبار ديف، يمكنك خفض التكاليف بشكل كبير.

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

10. مع سعة Azure Cosmos DB المحجوزة، يمكنك الحصول على خصومات كبيرة لمدة تصل إلى 65٪ لمدة ثلاث سنوات. إن نموذج Azure Cosmos DB للقدرة المحجوزة هو التزام مقدم على طلبات الوحدات اللازمة مع مرور الوقت. تتدرج الخصومات بحيث كلما زاد عدد وحدات الطلب التي تستخدمها على مدى فترة أطول، كلما زاد الخصم الخاص بك. يتم تطبيق هذه الخصومات على الفور. يتم احتساب أي وحدات طلب/ث مستخدمة فوق القيم المخصصة الخاصة بك استناداً إلى تكلفة السعة غير المحجوزة. راجع سعة Azure Cosmos DB المحجوزة) لمزيد من التفاصيل. فكر في شراء القدرة المحجوزة لزيادة خفض تكاليف معدل النقل المخصصة.

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

بعد ذلك يمكنك المتابعة لمعرفة المزيد حول تحسين التكلفة في Azure Cosmos DB في المقالات التالية:

• هل تحاول القيام بتخطيط السعة للترحيل إلى Azure Cosmos DB؟ يمكنك استخدام معلومات حول نظام مجموعة قاعدة البيانات الموجودة لديك لـ تخطيط السعة.
  • في حال كان كل ما تعرفه هو عدد vcores والخوادم في مجموعة قاعدة البيانات الحالية، فاقرأ عن تقدير وحدات الطلب باستخدام vCores أو vCPUs
  • إذا كان كل ما تعرفه هو عدد vcores والخوادم الموجودة في مجموعة قاعدة البيانات، اقرأ عن تقدير وحدات الطلب باستخدام vCores أو vCPUs
• تعرف على المزيد حول التحسين للتطوير والاختبار
• تعرف على المزيد حول فهم فاتورة Azure Cosmos DB
• تعرف على المزيد حول تحسين تكلفة التخزين
• تعرف على المزيد حول تحسين تكلفة عمليات القراءة والكتابة
• تعرف على المزيد حول تحسين تكلفة الاستعلامات
• تعرف على المزيد حول تحسين تكلفة حسابات Azure Cosmos DB متعددة المناطق