Share via

Redistribuce propustnosti napříč oddíly (Preview)

  • Článek

PLATÍ PRO: NoSQL MongoDB

Azure Cosmos DB ve výchozím nastavení distribuuje zřízenou propustnost databáze nebo kontejneru rovnoměrně napříč všemi fyzickými oddíly. Můžou ale nastat situace, kdy kvůli nerovnoměrné distribuci v úloze nebo výběru klíče oddílu potřebují určité logické (a tedy fyzické) oddíly větší propustnost než jiné. V těchto scénářích vám Azure Cosmos DB umožňuje distribuovat zřízenou propustnost napříč fyzickými oddíly. Redistribuce propustnosti napříč oddíly vám pomůže dosáhnout lepšího výkonu, aniž byste museli konfigurovat celkovou propustnost na základě nejžhavějšího oddílu.

Funkce redistribuce propustnosti se vztahuje na databáze a kontejnery využívající zřízenou propustnost (ruční a automatické škálování) a nevztahuje se na bezserverové kontejnery. Propustnost na fyzický oddíl můžete změnit pomocí příkazů PowerShellu nebo Azure CLI služby Azure Cosmos DB.

Kdy použít tuto funkci

Obecně platí, že použití této funkce se doporučuje pro scénáře, kdy platí obě tyto podmínky:

  • Konzistentně se zobrazuje vyšší než 1–5 % celkové míry 429 odpovědí
  • Máte konzistentní a předvídatelný horký oddíl

Pokud se odpovědi 429 nezobrazují a vaše koncová latence je přijatelná, není nutná žádná akce pro překonfigurování RU/s na oddíl. Pokud máte úlohu s konzistentními přenosy a občasnými nepředvídatelnými špičkami napříč všemi oddíly, doporučujeme použít automatické škálování a kapacitu shlukového přenosu (Preview). Automatické škálování a kapacita shlukového přenosu zajistí splnění požadavků na propustnost. Pokud máte malé množství RU/s na oddíl, můžete také pomocí sloučení oddílů (Preview) snížit počet oddílů a zajistit více RU/s na oddíl pro stejnou celkovou zřízenou propustnost.

Ukázkový scénář

Předpokládejme, že máme úlohu, která sleduje transakce, které probíhají v maloobchodních prodejnách. Vzhledem k tomu, že většina našich dotazů je podle StoreId, rozdělíme podle StoreId. V průběhu času ale vidíme, že některé obchody mají více aktivit než jiné a vyžadují vyšší propustnost, aby mohly sloužit svým úlohám. Vidíme omezování rychlosti (429) u požadavků na tyto id StorId a naše celková míra 429 odpovědí je větší než 1–5 %. Ostatní úložiště jsou mezitím méně aktivní a vyžadují menší propustnost. Pojďme se podívat, jak můžeme distribuovat propustnost pro lepší výkon.

Krok 1: Určení, které fyzické oddíly potřebují větší propustnost

Existují dva způsoby, jak zjistit, jestli existuje horký oddíl.

Možnost 1: Použití metrik Služby Azure Monitor

Pokud chcete ověřit, jestli existuje horký oddíl, přejděte na Přehledy> Throughput>Normalizovaná spotřeba RU (%) podle PartitionKeyRangeID. Vyfiltrujte konkrétní databázi a kontejner.

Každý PartitionKeyRangeId se mapuje na jeden fyzický oddíl. Vyhledejte jeden PartitionKeyRangeId, který konzistentně má vyšší normalizovanou spotřebu RU než ostatní. Například jedna hodnota je konzistentně na 100 %, ale jiné mají 30 % nebo méně. Vzor, jako je tento, může značit horký oddíl.

Screenshot of Normalized RU Consumption by PartitionKeyRangeId chart with a hot partition.

Možnost 2: Použití diagnostických protokolů

Pomocí informací z CDBPartitionKeyRUConsumption v diagnostických protokolech můžeme získat další informace o klíčích logických oddílů (a odpovídajících fyzických oddílech), které využívají nejvíce RU/s na druhé úrovni členitosti. Všimněte si, že ukázkové dotazy používají pouze 24 hodin pro ilustrativní účely – k pochopení vzoru se doporučuje použít alespoň sedm dnů historie.

Vyhledání fyzického oddílu (PartitionKeyRangeId), který v průběhu času spotřebovává nejvíce 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

V případě daného fyzického oddílu vyhledejte prvních 10 klíčů logického oddílu, které spotřebovávají nejvíce RU/s za každou hodinu.

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

Krok 2: Určení cílového RU/s pro každý fyzický oddíl

Určení aktuálních RU/s pro každý fyzický oddíl

Nejprve určíme aktuální POČET RU/S pro každý fyzický oddíl. Pomocí metriky Azure Monitor PhysicalPartitionThroughput a rozdělením podle dimenze PhysicalPartitionId můžete zjistit, kolik RU/s máte na fyzický oddíl.

Pokud jste ještě nezměnili propustnost pro každý oddíl, můžete použít vzorec: Current RU/s per partition = Total RU/s / Number of physical partitions

Postupujte podle pokynů v článku Osvědčené postupy pro škálování zřízené propustnosti (RU/s) a určete počet fyzických oddílů.

K přečtení aktuálních RU/s v jednotlivých fyzických oddílech můžete použít také PowerShell Get-AzCosmosDBSqlContainerPerPartitionThroughput a Get-AzCosmosDBMongoDBCollectionPerPartitionThroughput příkazy.

Slouží Install-Module k instalaci modulu Az.CosmosDB s povolenými předběžnými funkcemi.

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

Get-AzCosmosDBSqlContainerPerPartitionThroughput Ke čtení aktuálních RU/s v jednotlivých fyzických oddílech použijte příkaz nebo Get-AzCosmosDBSqlDatabasePerPartitionThroughput příkaz.


// 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

Určení RU/s pro cílový oddíl

V dalším kroku se rozhodneme, kolik RU/s chceme poskytnout našim nejžhavějším fyzickým oddílům. Pojďme volat tuto sadu cílových oddílů. Většina RU/s libovolného fyzického oddílu může obsahovat 10 000 RU/s.

Správný přístup závisí na vašich požadavcích na úlohy. Mezi obecné přístupy patří:

  • Zvýšení počtu RU/s o procento, měření rychlosti 429 odpovědí a opakování, dokud nedosáhnete požadované propustnosti.
    • Pokud si nejste jistí, že je správné procento, můžete začít s 10 % konzervativně.
    • Pokud už víte, že tento fyzický oddíl vyžaduje většinu propustnosti úlohy, můžete začít tím, že zvětšíte počet RU/s nebo ho zvýšíte na maximum 10 000 RU/s podle toho, co je nižší.
  • Zvýšení počtu RU/s na Total consumed RU/s of the physical partition + (Number of 429 responses per second * Average RU charge per request to the partition)
    • Tento přístup se snaží odhadnout, jaké skutečné využití RU/s by bylo, kdyby požadavky nebyly omezené rychlostí.

Určení RU/s pro zdrojový oddíl

Nakonec se rozhodneme, kolik RU/s chceme zachovat na dalších fyzických oddílech. Tento výběr určí oddíly, ze kterého má cílový fyzický oddíl propustnost.

V rozhraních API PowerShellu musíme zadat alespoň jeden zdrojový oddíl pro redistribuci RU/s. Můžeme také zadat vlastní minimální propustnost každého fyzického oddílu, který by měl mít po redistribuci. Pokud není ve výchozím nastavení zadáno, Azure Cosmos DB zajistí, že každý fyzický oddíl bude mít po redistribuci alespoň 100 RU/s. Doporučuje se explicitně zadat minimální propustnost.

Správný přístup závisí na vašich požadavcích na úlohy. Mezi obecné přístupy patří:

  • Rovnoměrné převzetí RU/s ze všech zdrojových oddílů (nejlépe v případech, kdy je k <dispozici 10 oddílů)
    • Spočítejte množství, o které potřebujeme posun každého zdrojového fyzického oddílu. Offset = Total desired RU/s of target partition(s) - total current RU/s of target partition(s)) / (Total physical partitions - number of target partitions)
    • Přiřaďte minimální propustnost pro každý zdrojový oddíl = Current RU/s of source partition - offset
  • Převzetí RU/s z nejméně aktivních oddílů
    • Pomocí metrik Azure Monitoru a diagnostických protokolů určete, které fyzické oddíly mají nejmenší objem provozu nebo požadavků.
    • Spočítejte množství, o které potřebujeme posun každého zdrojového fyzického oddílu. Offset = Total desired RU/s of target partition(s) - total current RU/s of target partition) / Number of source physical partitions
    • Přiřaďte minimální propustnost pro každý zdrojový oddíl = Current RU/s of source partition - offset

Krok 3: Programové změny propustnosti napříč oddíly

Propustnost můžete distribuovat pomocí příkazu Update-AzCosmosDBSqlContainerPerPartitionThroughput PowerShellu.

Abychom pochopili následující příklad, podívejme se na příklad, kde máme kontejner, který má celkem 6000 RU/s (6000 ručních RU/s nebo automatické škálování 6000 RU/s) a 3 fyzické oddíly. Na základě naší analýzy chceme rozložení, kde:

  • Fyzický oddíl 0: 1000 RU/s
  • Fyzický oddíl 1: 4000 RU/s
  • Fyzický oddíl 2: 1000 RU/s

Jako zdrojové oddíly zadáme oddíly 0 a 2 a určíme, že po redistribuci by měly mít minimální počet RU/s 1000 RU/s. Oddíl 1 je mimo cílový oddíl, který jsme určili, by měl mít 4000 RU/s.

Update-AzCosmosDBSqlContainerPerPartitionThroughput Použijte kontejnery s vyhrazenými RU/s nebo Update-AzCosmosDBSqlDatabasePerPartitionThroughput příkazem pro databáze se sdílenými RU/s k redistribuci propustnosti napříč fyzickými oddíly. V databázích se sdílenou propustností jsou ID fyzických oddílů reprezentovány řetězcem 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

Po dokončení redistribuce můžete změnu ověřit zobrazením metriky PhysicalPartitionThroughput ve službě Azure Monitor. Rozdělením podle dimenze PhysicalPartitionId zjistíte, kolik RU/s máte na fyzický oddíl.

V případě potřeby můžete také resetovat RU/s na fyzický oddíl tak, aby se RU/s vašeho kontejneru rovnoměrně distribuoval napříč všemi fyzickými oddíly.

Update-AzCosmosDBSqlContainerPerPartitionThroughput Pomocí příkazu pro kontejnery s vyhrazenými RU/s nebo Update-AzCosmosDBSqlDatabasePerPartitionThroughput příkazem pro databáze se sdílenými RU/s s s s parametrem -EqualDistributionPolicy distribuujte RU/s rovnoměrně napříč všemi fyzickými oddíly.


// 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

Krok 4: Ověření a monitorování spotřeby RU/s

Po dokončení redistribuce můžete změnu ověřit zobrazením metriky PhysicalPartitionThroughput ve službě Azure Monitor. Rozdělením podle dimenze PhysicalPartitionId zjistíte, kolik RU/s máte na fyzický oddíl.

Doporučuje se monitorovat celkovou míru 429 odpovědí a spotřeby RU/s. Další informace najdete v kroku 1 a ověřte, že jste dosáhli očekávaného výkonu.

Po změnách za předpokladu, že se vaše celková úloha nezměnila, pravděpodobně uvidíte, že cílové i zdrojové fyzické oddíly mají vyšší normalizovanou spotřebu RU než dříve. Vyšší normalizovaná spotřeba RU je očekávané chování. V podstatě jste přidělili RU/s blíže k tomu, co každý oddíl skutečně potřebuje využívat, takže vyšší normalizovaná spotřeba RU znamená, že každý oddíl plně využívá přidělené RU/s. Měli byste také očekávat nižší celkovou míru 429 výjimek, protože horké oddíly teď mají více RU/s pro obsluhu požadavků.

Omezení

Kritéria způsobilosti pro verzi Preview

Pokud chcete použít verzi Preview, musí váš účet služby Azure Cosmos DB splňovat všechna následující kritéria:

  • Váš účet služby Azure Cosmos DB používá rozhraní API pro NoSQL nebo API pro MongoDB.
    • Pokud používáte rozhraní API pro MongoDB, musí být >verze = 3.6.
  • Váš účet služby Azure Cosmos DB používá zřízenou propustnost (ruční nebo automatické škálování). Distribuce propustnosti napříč oddíly se nevztahuje na bezserverové účty.

K používání verze Preview se nemusíte registrovat. Pokud chcete tuto funkci použít, použijte příkazy PowerShellu nebo Azure CLI k redistribuci propustnosti mezi fyzické oddíly vašich prostředků.

Další kroky

Informace o použití zřízené propustnosti najdete v následujících článcích: