Redistribuce propustnosti napříč oddíly (Preview)
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 do části Insights>Throughput>Normalized RU Consumption (%) 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.
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
- Spočítejte množství, o které potřebujeme posun každého zdrojového fyzického oddílu.
- 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:
- Přečtěte si další informace o zřízené propustnosti.
- Přečtěte si další informace o jednotkách žádostí.
- Potřebujete monitorovat horké oddíly? Viz jednotky žádostí monitorování.
- Chcete se seznámit s osvědčenými postupy? Podívejte se na osvědčené postupy pro škálování zřízené propustnosti.