مشاركة عبر

إعادة توزيع معدل النقل عبر الأقسام (إصدار أولي)

  • مقالة

ينطبق على: NoSQL MongoDB

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

تنطبق ميزة إعادة توزيع معدل النقل على قواعد البيانات والحاويات باستخدام معدل النقل المتوفر (يدوياً وبالتحجيم التلقائي) ولا تنطبق على الحاويات بلا خادم. يمكنك تغيير معدل النقل لكل قسم فعلي باستخدام أوامر Azure Cosmos DB PowerShell أو Azure CLI.

متى يتم استخدام هذه الميزة

بشكل عام، يوصى باستخدام هذه الميزة لسيناريوهات يكون فيها كلا الأمرين التاليين صحيحاً:

  • ترى باستمرار أن المعدل الإجمالي لاستجابات 429 يزيد عن 1-5%
  • لديك قسم مزدحم متناسق ويمكن التنبؤ به

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

سيناريو مثال

لنفترض أن لدينا حمل عمل يتعقب العمليات التي تحدث في متاجر البيع بالتجزئة. نظراً لأن معظم استعلاماتنا حسب StoreId، فإننا نقسم حسب StoreId. ومع ذلك، وبمرور الوقت، نرى أن بعض المتاجر لديها نشاط أكثر من غيرها وتتطلب معدل نقل أكبر لخدمة أحمال العمل الخاصة بها. نرى تحديد المعدل (429) للطلبات مقابل StoreIds هذه، ومعدلنا الإجمالي البالغ 429 استجابة أكبر من 1-5٪. وفي الوقت نفسه، تتطلب المتاجر الأخرى الأقل نشاطاً معدل نقل أقل. دعونا نرَ كيف يمكننا إعادة توزيع معدل النقل للحصول على أداء أفضل.

الخطوة 1: تحديد الأقسام الفعلية التي تحتاج إلى زيادة معدل النقل

هناك طريقتان لتحديد ما إذا كان هناك قسم مزدحم.

الخيار 1: استخدام مقاييس Azure Monitor

للتحقق مما إذا كان هناك قسم فعال، انتقل إلى Insights > معدل النقل > استهلاك RU الطبيعي (٪) بواسطة PartitionKeyRangeID . قم بتصفية إلى قاعدة بيانات وحاوية معينة.

يتم تعيين كل معرف نطاق رئيسي للقسم إلى قسم مادي واحد. ابحث عن PartitionKeyRangeId الذي يحتوي باستمرار على استهلاك RU معدّل أعلى من غيره. على سبيل المثال، قيمة واحدة بشكل ثابت عند 100٪، والقيم الأخرى عند 30٪ أو أقل. يمكن أن يشير نمط مثل هذا إلى قسم مزدحم.

لقطة شاشة لمخطط استهلاك RU الذي تمت تسويته بواسطة PartitionKeyRangeId مع قسم ساخن.

الخيار 2: استخدام سجلات التشخيص

يمكننا استخدام المعلومات من CDBPartitionKeyRUConsumption في سجلات التشخيص للحصول على مزيد من المعلومات حول مفاتيح الأقسام المنطقية (والأقسام الفعلية المقابلة) التي تستهلك معظم RU/s بدقة من المستوى الثاني. لاحظ أن نماذج الاستعلامات تستخدم 24 ساعة لأغراض توضيحية فقط - يوصى باستخدام سبعة أيام على الأقل من المحفوظات لفهم النمط.

ابحث عن القسم الفعلي (PartitionKeyRangeId) الذي يستهلك معظم RU/s بمرور الوقت

CDBPartitionKeyRUConsumption 
| where TimeGenerated >= ago(24hr)
| where DatabaseName == "MyDB" and CollectionName == "MyCollection" // Replace with database and collection name
| where isnotempty(PartitionKey) and isnotempty(PartitionKeyRangeId)
| summarize sum(RequestCharge) by bin(TimeGenerated, 1s), PartitionKeyRangeId
| render timechart

بالنسبة إلى قسم فعلي معين، ابحث عن أهم 10 مفاتيح أقسام منطقية تستهلك معظم وحدات الطلب/ثانية (RU/s) على مدار كل ساعة

CDBPartitionKeyRUConsumption 
| where TimeGenerated >= ago(24hour)
| where DatabaseName == "MyDB" and CollectionName == "MyCollection" // Replace with database and collection name
| where isnotempty(PartitionKey) and isnotempty(PartitionKeyRangeId)
| where PartitionKeyRangeId == 0 // Replace with PartitionKeyRangeId 
| summarize sum(RequestCharge) by bin(TimeGenerated, 1hour), PartitionKey
| order by sum_RequestCharge desc | take 10

الخطوة 2: تحديد RU/s الهدف لكل قسم فعلي

تحديد RU/s الحالية لكل قسم فعلي

أولاً، دعونا نحدد RU/s الحالية لكل قسم فعلي. يمكنك استخدام مقياس Azure Monitor PhysicalPartitionThroughput وتقسيمه حسب البعد PhysicalPartitionId لمعرفة عدد وحدات الطلب/ الثانية لديك لكل قسم فعلي.

بدلاً من ذلك، إذا لم تقم بتغيير معدل النقل لكل قسم من قبل، يمكنك استخدام الصيغة: Current RU/s per partition = Total RU/s / Number of physical partitions

اتبع الإرشادات الواردة في المقالة أفضل الممارسات لتوسيع نطاق معدل النقل المتوفر (RU/s) لتحديد عدد الأقسام الفعلية.

يمكنك أيضا استخدام PowerShell Get-AzCosmosDBSqlContainerPerPartitionThroughput وGet-AzCosmosDBMongoDBCollectionPerPartitionThroughputالأوامر لقراءة RU/s الحالية على كل قسم مادي.

استخدم Install-Module لتثبيت الوحدة النمطية Az.CosmosDB مع تمكين ميزات الإصدار التجريبي.

$parameters = @{
    Name = "Az.CosmosDB"
    AllowPrerelease = $true
    Force = $true
}
Install-Module @parameters

Get-AzCosmosDBSqlContainerPerPartitionThroughput استخدم الأمر أو Get-AzCosmosDBSqlDatabasePerPartitionThroughput لقراءة وحدات الطلب/الثانية الحالية على كل قسم فعلي.


// Container with dedicated RU/s
$somePartitionsDedicatedRUContainer = Get-AzCosmosDBSqlContainerPerPartitionThroughput `
                    -ResourceGroupName "<resource-group-name>" `
                    -AccountName "<cosmos-account-name>" `
                    -DatabaseName "<cosmos-database-name>" `
                    -Name "<cosmos-container-name>" `
                    -PhysicalPartitionIds ("<PartitionId>", "<PartitionId">)

$allPartitionsDedicatedRUContainer = Get-AzCosmosDBSqlContainerPerPartitionThroughput `
                    -ResourceGroupName "<resource-group-name>" `
                    -AccountName "<cosmos-account-name>" `
                    -DatabaseName "<cosmos-database-name>" `
                    -Name "<cosmos-container-name>" `
                    -AllPartitions

// Database with shared RU/s
$somePartitionsSharedThroughputDatabase = Get-AzCosmosDBSqlDatabasePerPartitionThroughput `
                    -ResourceGroupName "<resource-group-name>" `
                    -AccountName "<cosmos-account-name>" `
                    -DatabaseName "<cosmos-database-name>" `
                    -PhysicalPartitionIds ("<PartitionId>", "<PartitionId">)

$allPartitionsSharedThroughputDatabase = Get-AzCosmosDBSqlDatabasePerPartitionThroughput `
                    -ResourceGroupName "<resource-group-name>" `
                    -AccountName "<cosmos-account-name>" `
                    -DatabaseName "<cosmos-database-name>" `
                    -AllPartitions

تحديد RU/s للقسم الهدف

بعد ذلك، دعونا نقرر عدد RU/s التي نريد أن نعطيها إلى القسم (الأقسام) الفعلية الأكثر ازدحاماً. لنسمِّ هذه المجموعة القسم (الأقسام) الهدف. أكبر عدد من وحدات RU/s يمكن أن يحتوي عليها أي قسم مادي هو 10000 RU/s.

يعتمد النهج الصحيح على متطلبات حمل العمل الخاص بك. تشمل النُهج العامة ما يلي:

  • زيادة RU/s بنسبة مئوية، وقياس معدل 429 استجابة، والتكرار حتى تحقيق معدل النقل المطلوب.
    • إذا لم تكن متأكداً من النسبة المئوية الصحيحة، يمكنك البدء بنسبة 10٪ لتكون معتدلاً.
    • إذا كنت تعرف أن هذا القسم الفعلي يتطلب معظم معدل نقل حمل العمل، يمكنك البدء بمضاعفة RU/s أو زيادتها إلى الحد الأقصى البالغ 10,000 RU/s، أيهما أقل.
  • زيادة وحدات الطلب/ثانية (RU/s) إلى Total consumed RU/s of the physical partition + (Number of 429 responses per second * Average RU charge per request to the partition)
    • يحاول هذا النهج تقدير ما كان يمكن أن يكون عليه استهلاك RU/s "الحقيقي" إذا لم تكن الطلبات محدودة المعدل.

تحديد RU/s للقسم المصدر

وأخيراً، دعونا نقرر عدد RU/s التي نريد الاحتفاظ بها على أقسامنا الفعلية الأخرى. سيقرر هذا التحديد الأقسام التي يأخذ منها القسم الفعلي الهدف معدل النقل.

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

يعتمد النهج الصحيح على متطلبات حمل العمل الخاص بك. تشمل النُهج العامة ما يلي:

  • أخذ RU/s بالتساوي من جميع أقسام المصدر (يعمل بشكل أفضل عندما يكون هناك <= 10 أقسام)
    • حساب المقدار الذي نحتاجه لإزاحة كل قسم فعلي مصدر. Offset = Total desired RU/s of target partition(s) - total current RU/s of target partition(s)) / (Total physical partitions - number of target partitions)
    • تعيين الحد الأدنى من معدل النقل لكل قسم مصدر = Current RU/s of source partition - offset
  • أخذ RU/s من الأقسام (الأقسام) الأقل نشاطا
    • استخدام مقاييس Azure Monitor وسجلات التشخيص لتحديد القسم (الأقسام) الفعلية التي تحتوي على أقل حجم نسبة استخدام شبكة/طلب
    • حساب المقدار الذي نحتاجه لإزاحة كل قسم فعلي مصدر. Offset = Total desired RU/s of target partition(s) - total current RU/s of target partition) / Number of source physical partitions
    • تعيين الحد الأدنى من معدل النقل لكل قسم مصدر = Current RU/s of source partition - offset

الخطوة 3: تغيير معدل النقل برمجياً عبر الأقسام

يمكنك استخدام الأمر PowerShell Update-AzCosmosDBSqlContainerPerPartitionThroughput لإعادة توزيع معدل النقل.

لفهم المثال أدناه، دعنا نأخذ مثالاً حيث لدينا حاوية تحتوي على إجمالي 6000 وحدة طلب/ثانية (RU/s) (إما 6000 وحدة طلب/ثانية (RU/s) يدوية أو 6000 وحدة طلب/ثانية (RU/s) تحجيم تلقائي) و3 أقسام فعلية. بناءً على تحليلنا، نريد تخطيطاً حيث:

  • القسم الفعلي 0: 1000 وحدة طلب/ثانية (RU/s)
  • القسم الفعلي 1: 4000 وحدة طلب/ثانية (RU/s)
  • القسم الفعلي 2: 1000 وحدة طلب/ثانية (RU/s)

نحدد الأقسام 0 و2 كأقسام المصدر الخاصة بنا، ونحدد أنه يجب أن يكون لهما حد أدنى من وحدات الطلب/ثانية (RU/s) يبلغ 1000 وحدة طلب/ثانية (RU/s) بعد إعادة التوزيع. القسم 1 خارج القسم الهدف، والذي نحدده حيث يجب أن يحتوي على 4000 وحدة طلب/ثانية (RU/s).

Update-AzCosmosDBSqlContainerPerPartitionThroughput استخدم للحاويات ذات وحدات الطلب/ الثانية المخصصة أو Update-AzCosmosDBSqlDatabasePerPartitionThroughput الأمر لقواعد البيانات ذات وحدات الطلب/الثانية المشتركة لإعادة توزيع معدل النقل عبر الأقسام المادية. في قواعد بيانات معدل النقل المشتركة، يتم تمثيل معرفات الأقسام الفعلية بواسطة سلسلة GUID.

$SourcePhysicalPartitionObjects =  @()
$SourcePhysicalPartitionObjects += New-AzCosmosDBPhysicalPartitionThroughputObject -Id "0" -Throughput 1000
$SourcePhysicalPartitionObjects += New-AzCosmosDBPhysicalPartitionThroughputObject -Id "2" -Throughput 1000

$TargetPhysicalPartitionObjects =  @()
$TargetPhysicalPartitionObjects += New-AzCosmosDBPhysicalPartitionThroughputObject -Id "1" -Throughput 4000

// Container with dedicated RU/s
Update-AzCosmosDBSqlContainerPerPartitionThroughput `
    -ResourceGroupName "<resource-group-name>" `
    -AccountName "<cosmos-account-name>" `
    -DatabaseName "<cosmos-database-name>" `
    -Name "<cosmos-container-name>" `
    -SourcePhysicalPartitionThroughputObject $SourcePhysicalPartitionObjects `
    -TargetPhysicalPartitionThroughputObject $TargetPhysicalPartitionObjects

// Database with shared RU/s
Update-AzCosmosDBSqlDatabasePerPartitionThroughput `
    -ResourceGroupName "<resource-group-name>" `
    -AccountName "<cosmos-account-name>" `
    -DatabaseName "<cosmos-database-name>" `
    -SourcePhysicalPartitionThroughputObject $SourcePhysicalPartitionObjects `
    -TargetPhysicalPartitionThroughputObject $TargetPhysicalPartitionObjects

بعد الانتهاء من إعادة التوزيع، يمكنك التحقق من التغيير عن طريق عرض مقياس PhysicalPartitionThroughput في Azure Monitor. التقسيم حسب البُعد PhysicalPartitionId لمعرفة عدد وحدات الطلب/الثانية (RU/s) لكل قسم فعلي.

إذا لزم الأمر، يمكنك أيضا إعادة ضبط RU/s لكل قسم مادي بحيث يتم توزيع وحدات RU/s من الحاوية بالتساوي عبر جميع الأقسام المادية.

Update-AzCosmosDBSqlContainerPerPartitionThroughput استخدم الأمر للحاويات ذات وحدات الطلب/ الثانية المخصصة أو Update-AzCosmosDBSqlDatabasePerPartitionThroughput الأمر لقواعد البيانات مع RU/s المشتركة مع المعلمة -EqualDistributionPolicy لتوزيع RU/s بالتساوي عبر جميع الأقسام المادية.


// Container with dedicated RU/s
$resetPartitionsDedicatedRUContainer = Update-AzCosmosDBSqlContainerPerPartitionThroughput `
                    -ResourceGroupName "<resource-group-name>" `
                    -AccountName "<cosmos-account-name>" `
                    -DatabaseName "<cosmos-database-name>" `
                    -Name "<cosmos-container-name>" `
                    -EqualDistributionPolicy

// Database with dedicated RU/s
$resetPartitionsSharedThroughputDatabase = Update-AzCosmosDBSqlDatabasePerPartitionThroughput `
                    -ResourceGroupName "<resource-group-name>" `
                    -AccountName "<cosmos-account-name>" `
                    -DatabaseName "<cosmos-database-name>" `
                    -EqualDistributionPolicy

الخطوة 4: التحقق من استهلاك RU/s ومراقبته

بعد الانتهاء من إعادة التوزيع، يمكنك التحقق من التغيير عن طريق عرض مقياس PhysicalPartitionThroughput في Azure Monitor. التقسيم حسب البُعد PhysicalPartitionId لمعرفة عدد وحدات الطلب/الثانية (RU/s) لكل قسم فعلي.

يوصى بمراقبة المعدل الإجمالي لـ 429 استجابة واستهلاك RU/s. لمزيد من المعلومات، راجع الخطوة 1 للتأكد من تحقيق الأداء الذي تتوقعه.

بعد التغييرات، بافتراض أن حمل العمل الإجمالي لم يتغير، من المحتمل أن ترى أن كلاً من الأقسام الفعلية الهدف والمصدر لديها استهلاك وحدات طلب (RU) معدّل أعلى من السابق. إن استهلاك وحدات طلب (RU) معدّل أعلى هو السلوك المتوقع. بشكل أساسي، قمت بتخصيص RU/s أقرب إلى ما يحتاج كل قسم بالفعل إلى استهلاكه، لذا فإن استهلاك RU المعدّل الأعلى يعني أن كل قسم يستخدم RU/s المخصصة بشكل كامل. يجب أن تتوقع أيضاً أن ترى معدل إجمالي أقل من 429 استثناء، حيث تحتوي الأقسام المزدحمة الآن على المزيد من RU/s لخدمة الطلبات.

القيود

معاينة معايير الأهلية

لاستخدام المعاينة، يجب أن يفي حساب Azure Cosmos DB بجميع المعايير التالية:

  • يستخدم حساب Azure Cosmos DB الخاص بك واجهة برمجة التطبيقات ل NoSQL أو API ل MongoDB.
    • في حال كنت تستخدم واجهة برمجة تطبيقات MongoDB، فيجب أن يكون الإصدار >= 3.6.
  • يستخدم حساب Azure Cosmos DB معدل النقل المقدم (يدويا أو تلقائيا). لا يطبق توزيع معدل النقل عبر الأقسام على الحسابات دون خادم.

لا تحتاج إلى التسجيل لاستخدام المعاينة. لاستخدام الميزة، استخدم أوامر PowerShell أو Azure CLI لإعادة توزيع معدل النقل عبر الأقسام الفعلية لمواردك.

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

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