Share via

Mendistribusikan ulang throughput di seluruh partisi

  • Artikel

BERLAKU UNTUK: MongoDB

Secara default, Azure Cosmos DB mendistribusikan throughput database atau kontainer yang tersedia secara merata di semua partisi fisik. Namun, skenario mungkin muncul di mana karena beban kerja yang miring atau pilihan kunci partisi, partisi logis tertentu (dan dengan demikian fisik) membutuhkan lebih banyak throughput daripada yang lain. Untuk skenario ini, Azure Cosmos DB memberi Anda kemampuan untuk mendistribusikan ulang throughput yang tersedia di seluruh partisi fisik. Mendistribusikan ulang throughput di seluruh partisi membantu Anda mencapai performa yang lebih baik tanpa harus mengonfigurasi throughput Anda secara keseluruhan berdasarkan partisi terkini.

Fitur distribusi ulang throughput berlaku untuk database dan kontainer menggunakan throughput yang tersedia (manual dan skala otomatis) serta tidak berlaku untuk kontainer tanpa server. Anda dapat mengubah throughput per partisi fisik menggunakan perintah Azure Cosmos DB PowerShell atau Azure CLI.

Waktu penggunaan fitur ini

Secara umum, penggunaan fitur ini direkomendasikan untuk skenario ketika kedua hal berikut ini benar:

  • Anda secara konsisten melihat 100% pemanfaatan yang dinormalisasi pada beberapa partisi koleksi.
  • Anda secara konsisten melihat latensi yang lebih tinggi dari penerimaan.

Jika Anda tidak melihat konsumsi RU 100% dan latensi end to end Anda dapat diterima, maka tidak diperlukan tindakan untuk mengonfigurasi ulang RU/dtk per partisi.
Jika Anda memiliki beban kerja yang memiliki lalu lintas yang konsisten dengan lonjakan sesekali yang tidak dapat diprediksi di semua partisi Anda, disarankan untuk menggunakan kapasitas skala otomatis dan ledakan. Kapasitas skala otomatis dan ledakan akan memastikan Anda dapat memenuhi persyaratan throughput Anda. Jika Anda memiliki sedikit RU/dtk per partisi, Anda juga dapat menggunakan penggabungan partisi untuk mengurangi jumlah partisi dan memastikan lebih banyak RU/dtk per partisi untuk total throughput yang disediakan yang sama.

Contoh skenario

Misalkan kita memiliki beban kerja yang melacak transaksi yang terjadi di toko ritel. Karena sebagian besar kueri kami berdasarkan StoreId, kami mempartisi dengan StoreId. Namun, seiring waktu, kami melihat bahwa beberapa toko memiliki lebih banyak aktivitas daripada yang lain dan membutuhkan lebih banyak throughput untuk melayani beban kerja mereka. Kami melihat konsumsi ru yang dinormalisasi 100% untuk permintaan terhadap StoreIds tersebut. Sementara itu, toko lain kurang aktif dan membutuhkan lebih sedikit throughput. Mari kita lihat bagaimana kita dapat mendistribusikan kembali throughput kita untuk performa yang lebih baik.

Langkah 1: Identifikasi partisi fisik mana yang membutuhkan lebih banyak throughput

Ada dua cara untuk mengidentifikasi apakah ada partisi terkini.

Opsi 1: Menggunakan metrik Azure Monitor

Untuk memverifikasi apakah ada partisi panas, buka Insights>Throughput>Konsumsi RU yang Dinormalisasi (%) Berdasarkan PartitionKeyRangeID. Lakukan pemfilteran ke database dan kontainer tertentu.

Setiap PartitionKeyRangeId dipetakan ke satu partisi fisik. Cari satu PartitionKeyRangeId yang secara konsisten memiliki konsumsi RU yang dinormalisasi lebih tinggi daripada yang lain. Misalnya, satu nilai secara konsisten berada di 100%, tetapi yang lain berada di 30% atau kurang. Pola seperti ini dapat menunjukkan partisi terkini.

Cuplikan layar bagan Konsumsi RU yang Dinormalisasi oleh PartitionKeyRangeId dengan partisi panas.

Opsi 2: Menggunakan Log Diagnostik

Kita dapat menggunakan informasi dari CDBPartitionKeyRUConsumption di Log Diagnostik untuk mendapatkan informasi selengkapnya tentang kunci partisi logis (dan partisi fisik yang sesuai) yang paling banyak menggunakan RU/dtk pada granularitas tingkat kedua. Perhatikan bahwa kueri sampel menggunakan 24 jam hanya untuk tujuan ilustrasi - disarankan untuk menggunakan setidaknya tujuh hari riwayat untuk memahami pola.

Temukan partisi fisik (PartitionKeyRangeId) yang paling banyak menggunakan RU dari waktu ke waktu

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, 1m), PartitionKeyRangeId
| render timechart

Untuk partisi fisik tertentu, temukan 10 kunci partisi logis teratas yang paling banyak mengonsumsi RU/dtk selama setiap jam

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

Langkah 2: Tentukan RU/dtk target untuk setiap partisi fisik

Tentukan RU/dtk saat ini untuk setiap partisi fisik

Pertama, mari kita tentukan RU saat ini untuk setiap partisi fisik. Anda dapat menggunakan metrik Azure Monitor PhysicalPartitionThroughput dan dibagi berdasarkan dimensi PhysicalPartitionId untuk melihat berapa banyak RU/dtk yang Anda miliki per partisi fisik.

Atau, jika Anda belum mengubah throughput per partisi sebelumnya, Anda bisa menggunakan rumus: Current RU/s per partition = Total RU/s / Number of physical partitions

Ikuti panduan dalam artikel Praktik terbaik untuk menskalakan throughput yang tersedia (RU/dtk) untuk menentukan jumlah partisi fisik.

Anda juga dapat menggunakan perintah Get-AzCosmosDBSqlContainerPerPartitionThroughput dan Get-AzCosmosDBMongoDBCollectionPerPartitionThroughput Powershell untuk membaca RU/dtk saat ini pada setiap partisi fisik.

Gunakan Install-Module untuk menginstal modul Az.CosmosDB dengan fitur prarilis diaktifkan.

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

Get-AzCosmosDBMongoDBCollectionPerPartitionThroughput Gunakan perintah untuk membaca RU/dtk saat ini pada setiap partisi fisik.

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

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

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

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

Menentukan RU/dtk untuk partisi target

Selanjutnya, mari kita putuskan berapa banyak RU yang ingin kita berikan ke partisi fisik terpanas. Mari kita sebut ini menetapkan partisi target kita. RU/dtk terbanyak yang dapat dimiliki partisi fisik apa pun adalah 10.000 RU/dtk.

Pendekatan yang tepat tergantung pada persyaratan beban kerja Anda. Pendekatan umum meliputi:

  • Meningkatkan RU sebesar 10 persen, dan ulangi hingga throughput yang diinginkan tercapai.
    • Jika Anda tidak yakin persentase yang tepat, Anda dapat memulai dengan 10% menjadi konservatif.
    • Jika Anda sudah tahu partisi fisik ini membutuhkan sebagian besar throughput beban kerja, Anda dapat mulai dengan menggandakan RU/dtk atau meningkatkannya hingga maksimum 10.000 RU/dtk, mana yang lebih rendah.

Menentukan RU/dtk untuk partisi sumber

Akhirnya, mari kita putuskan berapa banyak RU yang ingin kita simpan di partisi fisik kita yang lain. Pilihan ini akan menentukan partisi mana yang akan diambil throughput-nya oleh partisi fisik target.

Di API PowerShell, kita harus menentukan setidaknya satu partisi sumber untuk mendistribusikan ulang RU/dtk. Kita juga dapat menentukan throughput minimum kustom yang akan dimiliki tiap partisi fisik setelah redistribusi. Jika tidak ditentukan, secara default, Azure Cosmos DB akan memastikan bahwa setiap partisi fisik memiliki setidaknya 100 RU/dtk setelah didistribusikan ulang. Disarankan untuk secara eksplisit menentukan throughput minimum.

Pendekatan yang tepat tergantung pada persyaratan beban kerja Anda. Pendekatan umum meliputi:

  • Mengambil RU/s sama dari semua partisi sumber (berfungsi paling baik ketika ada <= 10 partisi)
    • Hitung jumlah yang kita butuhkan untuk mengimbangi setiap partisi fisik sumber dengan. Offset = Total desired RU/s of target partition(s) - total current RU/s of target partition(s)) / (Total physical partitions - number of target partitions)
    • Tetapkan throughput minimum untuk setiap partisi sumber = Current RU/s of source partition - offset
  • Mengambil RU dari partisi yang paling tidak aktif
    • Gunakan metrik Azure Monitor dan Log Diagnostik untuk menentukan partisi fisik mana yang memiliki volume lalu lintas/permintaan paling sedikit
    • Hitung jumlah yang kita butuhkan untuk mengimbangi setiap partisi fisik sumber dengan. Offset = Total desired RU/s of target partition(s) - total current RU/s of target partition) / Number of source physical partitions
    • Tetapkan throughput minimum untuk setiap partisi sumber = Current RU/s of source partition - offset

Langkah 3: Mengubah throughput secara terprogram di seluruh partisi

Anda dapat menggunakan perintah Update-AzCosmosDBSqlContainerPerPartitionThroughput Powershell untuk mendistribusikan ulang throughput.

Untuk memahami contoh di bawah ini, mari kita ambil contoh di mana kita memiliki kontainer yang memiliki total 6000 RU/dtk (baik 6000 RU manual atau skala otomatis 6000 RU/dtk) dan 3 partisi fisik. Berdasarkan analisis kami, kami menginginkan tata letak di mana:

  • Partisi fisik 0: 1000 RU/dtk
  • Partisi fisik 1: 4000 RU/dtk
  • Partisi fisik 2: 1000 RU/dtk

Kami menentukan partisi 0 dan 2 sebagai partisi sumber kami, dan menentukan bahwa setelah didistribusikan ulang, mereka harus memiliki RU/dtk minimum 1000 RU/dtk. Partisi 1 keluar dari partisi target, yang kita tentukan harus memiliki 4000 RU/dtk.

Update-AzCosmosDBMongoDBCollectionPerPartitionThroughput Gunakan untuk koleksi dengan RU/dtk khusus atau Update-AzCosmosDBMongoDBDatabasePerPartitionThroughput perintah untuk database dengan RU/dtk bersama untuk mendistribusikan ulang throughput di seluruh partisi fisik. Dalam database throughput bersama, Id partisi fisik diwakili oleh string GUID.

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

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

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

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

Setelah menyelesaikan didistribusikan ulang, Anda dapat memverifikasi perubahan dengan melihat metrik PhysicalPartitionThroughput di Azure Monitor. Pisahkan menurut dimensi PhysicalPartitionId untuk melihat berapa banyak RU/dtk yang Anda miliki per partisi fisik.

Jika perlu, Anda juga dapat mengatur ulang RU/dtk per partisi fisik sehingga RU/dtk kontainer Anda terdistribusi secara merata di semua partisi fisik.

Update-AzCosmosDBMongoDBCollectionPerPartitionThroughput Gunakan perintah untuk koleksi dengan RU/dtk khusus atau Update-AzCosmosDBMongoDBDatabasePerPartitionThroughput perintah untuk database dengan RU/dtk bersama dengan parameter -EqualDistributionPolicy untuk mendistribusikan RU secara merata di semua partisi fisik.

// Collection with dedicated RU/s
Update-AzCosmosDBMongoDBCollectionPerPartitionThroughput `
    -ResourceGroupName "<resource-group-name>" `
    -AccountName "<cosmos-account-name>" `
    -DatabaseName "<cosmos-database-name>" `
    -Name "<cosmos-collection-name>" `
    -EqualDistributionPolicy

// Database with shared RU/s
Update-AzCosmosDBMongoDBDatabasePerPartitionThroughput `
    -ResourceGroupName "<resource-group-name>" `
    -AccountName "<cosmos-account-name>" `
    -DatabaseName "<cosmos-database-name>" `
    -EqualDistributionPolicy

Langkah 4: Verifikasi dan pantau konsumsi RU/dtk Anda

Setelah menyelesaikan didistribusikan ulang, Anda dapat memverifikasi perubahan dengan melihat metrik PhysicalPartitionThroughput di Azure Monitor. Pisahkan menurut dimensi PhysicalPartitionId untuk melihat berapa banyak RU/dtk yang Anda miliki per partisi fisik.

Disarankan untuk memantau konsumsi ru yang dinormalisasi per partisi. Untuk informasi selengkapnya, tinjau Langkah 1 untuk memvalidasi bahwa Anda telah mencapai performa yang Anda harapkan.

Setelah perubahan, dengan asumsi beban kerja Keseluruhan Anda tidak berubah, Anda mungkin akan melihat bahwa partisi fisik target dan sumber memiliki konsumsi RU yang Dinormalisasi yang lebih tinggi daripada sebelumnya. Konsumsi RU yang dinormalisasi yang lebih tinggi adalah perilaku yang diharapkan. Pada dasarnya, Anda telah mengalokasikan RU lebih dekat dengan apa yang sebenarnya perlu dikonsumsi setiap partisi, sehingga konsumsi RU yang dinormalisasi yang lebih tinggi berarti bahwa setiap partisi sepenuhnya menggunakan RU/dtk yang dialokasikan. Anda juga harus berharap untuk melihat tingkat keseluruhan yang lebih rendah dari pengecualian 429, karena partisi terkini sekarang memiliki lebih banyak RU untuk melayani permintaan.

Batasan

Kriteria kelayakan pratinjau

Untuk menggunakan pratinjau, akun Azure Cosmos DB Anda harus memenuhi semua kriteria berikut:

  • Akun Azure Cosmos DB Anda menggunakan API untuk MongoDB.
    • Versi harus >= 3.6.
  • Akun Azure Cosmos DB menggunakan throughput yang disediakan (manual atau skala otomatis). Distribusi throughput di seluruh partisi tidak berlaku untuk akun tanpa server.

Anda tidak perlu mendaftar untuk menggunakan pratinjau. Untuk menggunakan fitur ini, gunakan perintah PowerShell atau Azure CLI untuk mendistribusikan ulang throughput di seluruh partisi fisik sumber daya Anda.

Langkah berikutnya

Pelajari tentang cara menggunakan throughput yang tersedia dengan artikel berikut: