نصائح الأداء ل Azure Cosmos DB و .NET SDK v2

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

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

لذا، إذا كنت تحاول تحسين أداء قاعدة بياناتك، فكر في هذه الخيارات:

الترقية إلى حزمة تطوير .NET V3

تم إصدار حزمة تطوير البرمجيات .NET v3 . إذا كنت تستخدم حزمة تطوير .NET v3، راجع دليل أداء .NET v3 للحصول على المعلومات التالية:

  • الوضع الافتراضي لوضع TCP المباشر
  • دعم واجهة برمجة التطبيقات المتدفقة
  • يدعم المتسلسل المخصص للسماح باستخدام System.Text.JSON
  • دعم الدفعات والجملة المتكامل

توصيات الاستضافة

تفعيل جمع القمامة على جانب الخادم (GC)

يمكن أن يساعد تقليل وتيرة تجميع البيانات المهملة في بعض الحالات. في .NET، عيِّن gcServer على true.

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

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

إشعار

يمكن أن يتسبب الاستخدام العالي لوحدة المعالجة المركزية في زيادة زمن الوصول وطلب استثناءات المهلة.

عمليات بيانات التعريف

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

التسجيل والتتبع.

تحتوي بعض البيئات على .NET DefaultTraceListener ممكن. يطرح DefaultTraceListener مشكلات الأداء على بيئات التشغيل ما يسبب ازدحامات عالية في CPU والإدخال/إخراج. تحقق من تعطيل DefaultTraceListener في تطبيقك وتأكد من ذلك عن طريق إزالته من TraceListeners على بيئات التشغيل.

أحدث إصدارات SDK (أكبر من 2.16.2) تزيل الأداة تلقائيا عند اكتشافها، أما في الإصدارات الأقدم يمكنك إزالتها من خلال:

if (!Debugger.IsAttached)
{
    Type defaultTrace = Type.GetType("Microsoft.Azure.Documents.DefaultTrace,Microsoft.Azure.DocumentDB.Core");
    TraceSource traceSource = (TraceSource)defaultTrace.GetProperty("TraceSource").GetValue(null);
    traceSource.Listeners.Remove("Default");
    // Add your own trace listeners
}

Networking

نهج الاتصال: استخدم وضع الاتصال المباشر

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

Uri serviceEndpoint = new Uri("https://contoso.documents.net");
string authKey = "your authKey from the Azure portal";
DocumentClient client = new DocumentClient(serviceEndpoint, authKey,
new ConnectionPolicy
{
   ConnectionMode = ConnectionMode.Direct, // ConnectionMode.Gateway is the default
   ConnectionProtocol = Protocol.Tcp
});

استنفاد المنفذ المؤقت

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

عند التشغيل على بروتوكول TCP، يقوم العميل بتحسين الكمون باستخدام الاتصالات طويلة العمر بدلا من بروتوكول HTTPS الذي ينهي الاتصالات بعد دقيقتين من عدم النشاط.

في الحالات التي يكون فيها الوصول متناثرا وإذا لاحظت زيادة عدد الاتصالات مقارنة بوضع البوابة، يمكنك:

  • تكوين خاصية ConnectionPolicy.PortReuseMode بحيث PrivatePortPool (فعالة مع إصدار> إطار العمل= 4.6.1 و.NET core version >= 2.0): تسمح هذه الخاصية لمجموعة تطوير البرمجيات باستخدام مجموعة صغيرة من المنافذ المؤقتة لنقاط نهاية وجهة مختلفة في Azure Cosmos DB.
  • قم بتكوين خاصية ConnectionPolicy.يجب أن تكون خاصية IdleConnectionTimeout أكبر من أو تساوي 10 دقائق. القيم الموصى بها تتراوح بين 20 دقيقة و24 ساعة.

اتصل ب OpenAsync لتجنب تأخير بدء التشغيل عند الطلب الأول

افتراضيا، يكون للطلب الأول زمن تأخير أعلى لأنه يحتاج إلى جلب جدول توجيه العناوين. عند استخدام SDK V2، اتصل OpenAsync() مرة واحدة أثناء التهيئة لتجنب تأخير بدء التشغيل في الطلب الأول. يبدو أن المكالمة كالتالي: await client.OpenAsync();

إشعار

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

للأداء العام، تجمع العملاء في نفس منطقة Azure

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

سياسة الاتصال Azure Cosmos DB

زيادة عدد الخيوط/المهام

نظرا لأن المكالمات إلى Azure Cosmos DB تتم عبر الشبكة، قد تحتاج إلى تغيير درجة التوازي بين طلباتك بحيث يقضي تطبيق العميل وقتا ضئيلا في الانتظار بين الطلبات. على سبيل المثال، إذا كنت تستخدم .NET Task Parallel Library، فأنشئ مئات المهام التي تُقرأ من Azure Cosmos DB أو تُكتب فيه.

تمكين الشبكات المتسارعة

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

استخدام SDK

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

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

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

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

تجنب الاستدعاءات المحظورة

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

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

لا تنفِّذ ما يلي:

  • منع التنفيذ غير المتزامن من خلال استدعاء Task.Wait أو Task.Result.
  • استخدام Task.Run لمنع تزامن واجهة برمجة التطبيقات المتزامنة.
  • احصل على تأمين في مسارات التعليمات البرمجية الشائعة. Azure Cosmos DB .NET SDK هو الأكثر أداء عند تصميمه لتشغيل التعليمات البرمجية بالتوازي.
  • استدعِ Task.Run وانتظرها على الفور. ASP.NET Core يشغل بالفعل كود التطبيق على خيوط Thread Pool العادية، لذا فإن استدعاء Task.Run يؤدي فقط إلى جدولة إضافية غير ضرورية في Thread Pool. حتى لو كان الكود المجدول سيمنع خيوطا، فإن Task.Run لا يمنع ذلك.
  • استخدم ToList() التي DocumentClient.CreateDocumentQuery(...) تستخدم استدعاءات حجب لاستنزاف الاستعلام بشكل متزامن. استخدم AsDocumentQuery() لتفريغ الاستعلام بشكل غير متزامن.

من المستحسن القيام بما يلي:

  • استدعاء واجهات برمجة تطبيقات Azure Cosmos DB .NET بشكل غير متزامن.
  • مكدس الاستدعاءات بأكمله غير متزامن للاستفادة من أنماط غير متزامن/الانتظار.

يمكن استخدام المحلل، مثل PerfView، للعثور على الخيوط التي تضاف كثيرا إلى مجموعة الخيوط. يشير الحدث Microsoft-Windows-DotNETRuntime/ThreadPoolWorkerThread/Start إلى مؤشر ترابط مُضاف إلى تجمع مؤشرات الترابط.

زيادة System.Net MaxConnections لكل مضيف عند استخدام وضع البوابة

طلبات قاعدة بيانات Azure Cosmos تتم عبر HTTPS/REST عند استخدام وضع البوابة. يخضعون لحد الاتصال الافتراضي لكل اسم مضيف أو عنوان IP. قد تحتاج إلى تعيين MaxConnections قيمة أعلى (من 100 إلى 1000) حتى تتمكن مكتبة العميل من استخدام عدة اتصالات متزامنة إلى قاعدة بيانات Azure Cosmos. في الإصدار 1.8.0 من .NET SDK والإصدارات الأحدث، تكون القيمة الافتراضية لـ ServicePointManager.DefaultConnectionLimit‏ 50. لتغيير القيمة، يمكنك تعيين Documents.Client.ConnectionPolicy.MaxConnectionLimit إلى قيمة أعلى.

تنفيذ التراجع عند فترات RetryAfter

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

تتضمن هذه المجموعات دعم سياسة إعادة المحاولة:

لمزيد من المعلومات، راجع RetryAfter.

في الإصدار 1.19 وما بعده من مجموعة تطوير .NET، هناك آلية لتسجيل معلومات تشخيصية إضافية واستكشاف مشاكل التأخير، كما هو موضح في العينة التالية. يمكنك تسجيل سلسلة التشخيص للطلبات التي لها زمن استجابة أعلى للقراءة. سيساعدك السلسلة التشخيصية الملتقطة على فهم عدد المرات التي تلقيت فيها 429 خطأ لطلب معين.

ResourceResponse<Document> readDocument = await this.readClient.ReadDocumentAsync(oldDocuments[i].SelfLink);
readDocument.RequestDiagnosticsString

ذاكرة مؤقتة لملفات URI للقراءة المنخفضة

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

زيادة عدد مؤشرات الترابط/المهام

انظر زيادة عدد الخيوط/المهام في قسم الشبكات في هذا المقال.

عمليات الاستعلام

لعمليات الاستعلام، راجع نصائح أداء الاستعلامات.

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

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

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

var collection = new DocumentCollection { Id = "excludedPathCollection" };
collection.IndexingPolicy.IncludedPaths.Add(new IncludedPath { Path = "/*" });
collection.IndexingPolicy.ExcludedPaths.Add(new ExcludedPath { Path = "/nonIndexedContent/*");
collection = await client.CreateDocumentCollectionAsync(UriFactory.CreateDatabaseUri("db"), collection);

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

الإنتاجية

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

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

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

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

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

// Measure the performance (Request Units) of writes
ResourceResponse<Document> response = await client.CreateDocumentAsync(collectionSelfLink, myDocument);
Console.WriteLine("Insert of document consumed {0} request units", response.RequestCharge);
// Measure the performance (Request Units) of queries
IDocumentQuery<dynamic> queryable = client.CreateDocumentQuery(collectionSelfLink, queryString).AsDocumentQuery();
while (queryable.HasMoreResults)
    {
        FeedResponse<dynamic> queryResponse = await queryable.ExecuteNextAsync<dynamic>();
        Console.WriteLine("Query batch consumed {0} request units", queryResponse.RequestCharge);
    }

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

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

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

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

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

إذا كان لديك أكثر من عميل يعمل بشكل تراكمي فوق معدل الطلب، فقد لا يكون عدد إعادة المحاولة الافتراضي المعين حاليا على 9 داخليا من قبل العميل كافيا. في هذه الحالة، يرمي العميل DocumentClientException مع رمز الحالة 429 إلى التطبيق.

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

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

لمعدل نقل أعلى، صمم مستندات أصغر حجماً

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

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

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

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

  • Last updated on