مشاركة عبر

تحسين تكلفة الطلب في Azure Cosmos DB

  • مقالة

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

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

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

قياس رسوم وحدة الطلب لطلب ما

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

قراءة البيانات: قراءة النقاط والاستعلامات

عادة ما يتم طلب عمليات القراءة في Azure Cosmos DB من الأسرع /الأكثر كفاءة إلى أبطأ / أقل كفاءة من حيث استهلاك وحدات الطلب على النحو التالي:

  • تقرأ النقطة (مفتاح / قيمة البحث على معرف عنصر واحد ومفتاح القسم).
  • الاستعلام باستخدام عبارة عامل تصفية ضمن مفتاح قسم واحد.
  • الاستعلام دون عبارة تصفية مساواة أو نطاق على أي خاصية.
  • الاستعلام دون عوامل تصفية.

دور مستوى التناسق

عند استخدام مستويات تناسق ثبات قوية أو محددة، يتم مضاعفة تكلفة وحدات الطلب لأي عملية قراءة (قراءة النقطة أو الاستعلام).

قراءة النقطة

العامل الوحيد الذي يؤثر على شحن وحدات الطلب لقراءة نقطة (بالإضافة إلى مستوى التناسق المستخدم) هو حجم العنصر المسترد. يعرض الجدول التالي تكلفة وحدات الطلب من القراءات نقطة للعناصر التي هي 1 كيلوبايت و 100 كيلوبايت في الحجم.

حجم العنصر تكلفة قراءة نقطة واحدة
1 KB وحدة الطلب
100 KB 10 وحدات وحدات الطلب

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

إشعار

في واجهة برمجة التطبيقات ل NoSQL، يمكن إجراء قراءات النقاط فقط باستخدام REST API أو SDKs. لا تعتبر الاستعلامات التي تقوم بالتصفية على معرف عنصر واحد ومفتاح القسم قراءة نقطة. للاطلاع على مثال باستخدام .NET SDK، راجع قراءة عنصر في Azure Cosmos DB ل NoSQL.

الاستعلامات

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

في بعض الحالات قد تشاهد تسلسل استجابات 200 و 429 ووحدات طلب متغير في تنفيذ الاستعلامات المقسمة إلى صفحات، وذلك لأن الاستعلامات سيتم تشغيلها بأسرع وقت ممكن استناداً إلى وحدات البحث والتطوير المتوفرة. قد تشاهد فاصل تنفيذ استعلام إلى صفحات متعددة/رحلات دائرية بين الخادم والعميل. على سبيل المثال، قد يتم إرجاع 10,000 عنصر كصفحات متعددة، كل منها مشحون بناء على الحساب الذي تم إجراؤه لتلك الصفحة. عند جمع عبر هذه الصفحات، يجب أن تحصل على نفس عدد وحدات البحث عن وحدات الطلب كما ستحصل على الاستعلام بأكمله.

مقاييس لاستكشاف الاستعلامات وإصلاحها

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

Retrieved Document Count                 :               1              
Retrieved Document Size                  :           9,963 bytes        
Output Document Count                    :               1              
Output Document Size                     :          10,012 bytes        
Index Utilization                        :          100.00 %            
Total Query Execution Time               :            0.48 milliseconds 
  Query Preparation Times 
    Query Compilation Time               :            0.07 milliseconds 
    Logical Plan Build Time              :            0.03 milliseconds 
    Physical Plan Build Time             :            0.05 milliseconds 
    Query Optimization Time              :            0.00 milliseconds 
  Index Lookup Time                      :            0.06 milliseconds 
  Document Load Time                     :            0.03 milliseconds 
  Runtime Execution Times 
    Query Engine Execution Time          :            0.03 milliseconds 
    System Function Execution Time       :            0.00 milliseconds 
    User-defined Function Execution Time :            0.00 milliseconds 
  Document Write Time                    :            0.00 milliseconds 
  Client Side Metrics 
    Retry Count                          :               1              
    Request Charge                       :            3.19 RUs  

أفضل الممارسات لتحسين تكلفة الاستعلامات

خذ بعين الاعتبار أفضل الممارسات التالية عند تحسين الاستعلامات للتكلفة:

  • تنظيم أنواع كيانات متعددة

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

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

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

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

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

كتابة البيانات

تعتمد تكلفة وحدات الطلب لكتابة عنصر على:

  • حجم العنصر.
  • عدد الخصائص التي يغطيها نهج الفهرسة وتحتاج إلى فهرستها.

إدراج عنصر 1 كيلوبايت دون فهرسة التكاليف حول قرابة 5.5 وحدات الطلب. استبدال عنصر تكاليف ضعف المصاريف المطلوبة لإدراج نفس العنصر.

تحسين عمليات الكتابة

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

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

عند تنفيذ إدخال الجزء الأكبر من البيانات، فمن المستحسن أيضاً استخدام مكتبة المنفذ الأكبر Azure Cosmos DB كما أنها مصممة لتحسين استهلاك وحدات الطلب في هذه العمليات. اختيارياً، يمكنك أيضاً استخدام Azure Data Factory الذي تم إنشاؤه على نفس المكتبة.

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

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