Redystrybuuj przepływność między partycjami (wersja zapoznawcza)
DOTYCZY: 
Nosql Mongodb
Domyślnie usługa Azure Cosmos DB dystrybuuje aprowizowaną przepływność bazy danych lub kontenera w równym stopniu we wszystkich partycjach fizycznych. Jednak mogą wystąpić scenariusze, w których z powodu niesymetryczności obciążenia lub wyboru klucza partycji niektóre partycje logiczne (a tym samym fizyczne) wymagają większej przepływności niż inne. W tych scenariuszach usługa Azure Cosmos DB umożliwia redystrybucję aprowizowanej przepływności między partycjami fizycznymi. Redystrybucja przepływności między partycjami pomaga osiągnąć lepszą wydajność bez konieczności konfigurowania ogólnej przepływności na podstawie najgorętszej partycji.
Funkcja redystrybucji przepływności dotyczy baz danych i kontenerów przy użyciu aprowizowanej przepływności (ręcznego i automatycznego skalowania) i nie ma zastosowania do kontenerów bezserwerowych. Przepływność na partycję fizyczną można zmienić przy użyciu poleceń programu PowerShell usługi Azure Cosmos DB lub interfejsu wiersza polecenia platformy Azure.
Kiedy należy używać tej funkcji
Ogólnie rzecz biorąc, użycie tej funkcji jest zalecane w scenariuszach, gdy oba te elementy są spełnione:
- Stale obserwujesz większą niż 1–5% ogólną szybkość 429 odpowiedzi
- Masz spójną, przewidywalną partycję gorącą
Jeśli nie widzisz odpowiedzi 429, a opóźnienie końcowe mieści się w dopuszczalnym zakresie, nie jest wymagane podjęcie żadnych działań w celu ponownego skonfigurowania jednostek żądań na partycję. Jeśli masz obciążenie, które ma spójny ruch z okazjonalnymi nieprzewidywalnymi skokami we wszystkich partycjach, zaleca się użycie skalowania automatycznego i zwiększania pojemności (wersja zapoznawcza). Skalowanie automatyczne i zwiększanie pojemności pomogą Ci spełnić wymagania dotyczące przepływności. Jeśli masz niewielką liczbę jednostek RU/s na partycję, możesz również użyć scalania partycji (wersja zapoznawcza), aby zmniejszyć liczbę partycji i zapewnić więcej jednostek RU/s na partycję dla tej samej całkowitej aprowizowanej przepływności.
Przykładowy scenariusz
Załóżmy, że mamy obciążenie, które śledzi transakcje, które odbywają się w sklepach detalicznych. Ponieważ większość naszych zapytań jest według StoreId, dzielimy na partycje według StoreId. Jednak w czasie widzimy, że niektóre sklepy mają więcej aktywności niż inne i wymagają większej przepływności do obsługi obciążeń. Widzimy ograniczanie szybkości (429) dla żądań względem tych identyfikatorów StoreId, a ogólna szybkość odpowiedzi 429 jest większa niż 1–5%.. Tymczasem inne magazyny są mniej aktywne i wymagają mniejszej przepływności. Zobaczmy, jak możemy ponownie dystrybuować przepływność w celu uzyskania lepszej wydajności.
Krok 1. Określenie, które partycje fizyczne wymagają większej przepływności
Istnieją dwa sposoby identyfikowania, czy istnieje gorąca partycja.
Opcja 1. Korzystanie z metryk usługi Azure Monitor
Aby sprawdzić, czy istnieje gorąca partycja, przejdź do pozycji Szczegółowe informacje> Użycie>znormalizowanych jednostek RU (%) według PartitionKeyRangeID. Filtruj do określonej bazy danych i kontenera.
Każda partycja PartitionKeyRangeId mapuje na jedną partycję fizyczną. Poszukaj jednego identyfikatora PartitionKeyRangeId, który stale ma większe znormalizowane użycie jednostek RU niż inne. Na przykład jedna wartość jest spójna na poziomie 100%, ale inne są w 30% lub mniejsze. Wzorzec, taki jak ten, może wskazywać gorącą partycję.
Opcja 2. Korzystanie z dzienników diagnostycznych
Możemy użyć informacji z CDBPartitionKeyRUConsumption w dziennikach diagnostycznych, aby uzyskać więcej informacji na temat kluczy partycji logicznych (i odpowiednich partycji fizycznych), które zużywają najwięcej JEDNOSTEK RU/s na drugim poziomie szczegółowości. Zwróć uwagę, że przykładowe zapytania używają tylko 24 godzin do celów ilustracyjnych — zaleca się użycie co najmniej siedmiu dni historii w celu zrozumienia wzorca.
Znajdź partycję fizyczną (PartitionKeyRangeId), która zużywa najwięcej jednostek RU/s w czasie
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
W przypadku danej partycji fizycznej znajdź 10 najważniejszych kluczy partycji logicznych, które zużywają najwięcej jednostek RU/s w ciągu każdej godziny
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. Określanie docelowej jednostki RU/s dla każdej partycji fizycznej
Określanie bieżących jednostek RU/s dla każdej partycji fizycznej
Najpierw określmy bieżącą wartość RU/s dla każdej partycji fizycznej. Możesz użyć metryki Azure Monitor PhysicalPartitionThroughput i podzielić według wymiaru PhysicalPartitionId , aby zobaczyć, ile jednostek RU/s masz na partycję fizyczną.
Alternatywnie, jeśli wcześniej nie zmieniono przepływności na partycję, możesz użyć formuły: Current RU/s per partition = Total RU/s / Number of physical partitions
Postępuj zgodnie ze wskazówkami w artykule Najlepsze rozwiązania dotyczące skalowania aprowizowanej przepływności (RU/s), aby określić liczbę partycji fizycznych.
Możesz również użyć programu PowerShell Get-AzCosmosDBSqlContainerPerPartitionThroughput i Get-AzCosmosDBMongoDBCollectionPerPartitionThroughput poleceń, aby odczytać bieżące jednostki RU/s na każdej partycji fizycznej.
Użyj Install-Module polecenia , aby zainstalować moduł Az.CosmosDB z włączonymi funkcjami wersji wstępnej.
$parameters = @{
Name = "Az.CosmosDB"
AllowPrerelease = $true
Force = $true
}
Install-Module @parameters
Get-AzCosmosDBSqlContainerPerPartitionThroughput Użyj polecenia orGet-AzCosmosDBSqlDatabasePerPartitionThroughput, aby odczytać bieżące jednostki RU/s na każdej partycji fizycznej.
// 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
Określanie jednostek RU/s dla partycji docelowej
Następnie zdecydujmy, ile jednostek RU/s chcemy przekazać do naszych najgorętszych partycji fizycznych. Wywołajmy to ustawienie partycji docelowych. Najwięcej jednostek RU/s może zawierać dowolna partycja fizyczna to 10 000 RU/s.
Właściwe podejście zależy od wymagań dotyczących obciążenia. Ogólne podejścia obejmują:
- Zwiększenie jednostek RU/s o wartość procentową, zmierz szybkość 429 odpowiedzi i powtórz, aż zostanie osiągnięta żądana przepływność.
- Jeśli nie masz pewności, że odpowiedni procent, możesz zacząć od 10%, aby być konserwatywnym.
- Jeśli wiesz już, że ta partycja fizyczna wymaga większości przepływności obciążenia, możesz zacząć od podwojenia jednostek RU/s lub zwiększenia jej do maksymalnej liczby 10 000 RU/s, w zależności od tego, która z nich jest niższa.
- Zwiększanie liczby jednostek RU/s do
Total consumed RU/s of the physical partition + (Number of 429 responses per second * Average RU charge per request to the partition)- Takie podejście próbuje oszacować, jakie byłoby "rzeczywiste" użycie jednostek RU/s, gdyby żądania nie były ograniczone.
Określanie jednostek RU/s dla partycji źródłowej
Na koniec zdecydujmy, ile jednostek RU/s chcemy zachować na innych partycjach fizycznych. Ten wybór określi partycje, z których docelowa partycja fizyczna pobiera przepływność.
W interfejsach API programu PowerShell musimy określić co najmniej jedną partycję źródłową do ponownego dystrybuowania jednostek RU/s. Możemy również określić niestandardową minimalną przepływność, jaką każda partycja fizyczna powinna mieć po redystrybucji. Jeśli nie zostanie określony, domyślnie usługa Azure Cosmos DB zapewni, że każda partycja fizyczna ma co najmniej 100 RU/s po redystrybucji. Zaleca się jawne określenie minimalnej przepływności.
Właściwe podejście zależy od wymagań dotyczących obciążenia. Ogólne podejścia obejmują:
- Pobieranie jednostek RU/s równie ze wszystkich partycji źródłowych (działa najlepiej, gdy istnieją <= 10 partycji)
- Oblicz kwotę, według którą musimy zrównoważyć każdą źródłową partycję fizyczną.
Offset = Total desired RU/s of target partition(s) - total current RU/s of target partition(s)) / (Total physical partitions - number of target partitions) - Przypisywanie minimalnej przepływności dla każdej partycji źródłowej =
Current RU/s of source partition - offset
- Oblicz kwotę, według którą musimy zrównoważyć każdą źródłową partycję fizyczną.
- Pobieranie jednostek RU/s z najmniej aktywnych partycji
- Użyj metryk usługi Azure Monitor i dzienników diagnostycznych, aby określić, które partycje fizyczne mają najmniejszy ruch/wolumin żądania
- Oblicz kwotę, według którą musimy zrównoważyć każdą źródłową partycję fizyczną.
Offset = Total desired RU/s of target partition(s) - total current RU/s of target partition) / Number of source physical partitions - Przypisywanie minimalnej przepływności dla każdej partycji źródłowej =
Current RU/s of source partition - offset
Krok 3. Programowa zmiana przepływności między partycjami
Możesz użyć polecenia Update-AzCosmosDBSqlContainerPerPartitionThroughput programu PowerShell, aby ponownie dystrybuować przepływność.
Aby zrozumieć poniższy przykład, przyjrzyjmy się przykładowi, w którym mamy kontener o łącznej wartości 6000 RU/s (6000 jednostek RU/s lub autoskalowanie 6000 RU/s) i 3 partycje fizyczne. Na podstawie naszej analizy chcemy mieć układ, w którym:
- Partycja fizyczna 0: 1000 RU/s
- Partycja fizyczna 1: 4000 RU/s
- Partycja fizyczna 2: 1000 RU/s
Określamy partycje 0 i 2 jako partycje źródłowe i określamy, że po redystrybucji powinny mieć minimalną liczbę RU/s 1000 RU/s. Partycja 1 to partycja docelowa, którą określimy, powinna mieć 4000 RU/s.
Update-AzCosmosDBSqlContainerPerPartitionThroughput Użyj polecenia dla kontenerów z dedykowanymi jednostkami RU/s lub Update-AzCosmosDBSqlDatabasePerPartitionThroughput poleceniami dla baz danych z udostępnionymi jednostkami RU/s, aby ponownie dystrybuować przepływność między partycjami fizycznymi. W bazach danych z udostępnioną przepływnością identyfikatory partycji fizycznych są reprezentowane przez ciąg identyfikatora 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 zakończeniu ponownej dystrybucji możesz zweryfikować zmianę, wyświetlając metrykę PhysicalPartitionThroughput w usłudze Azure Monitor. Podziel według wymiaru PhysicalPartitionId , aby zobaczyć liczbę jednostek RU/s na partycję fizyczną.
W razie potrzeby można również zresetować jednostkę RU/s na partycję fizyczną, aby jednostka RU/s kontenera została równomiernie rozłożona na wszystkie partycje fizyczne.
Update-AzCosmosDBSqlContainerPerPartitionThroughput Użyj polecenia dla kontenerów z dedykowanymi jednostkami RU/s lub Update-AzCosmosDBSqlDatabasePerPartitionThroughput poleceniami dla baz danych z udostępnionymi jednostkami RU/s z parametrem -EqualDistributionPolicy , aby równomiernie dystrybuować ru/s we wszystkich partycjach fizycznych.
// 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. Weryfikowanie i monitorowanie użycia jednostek RU/s
Po zakończeniu ponownej dystrybucji możesz zweryfikować zmianę, wyświetlając metrykę PhysicalPartitionThroughput w usłudze Azure Monitor. Podziel według wymiaru PhysicalPartitionId , aby zobaczyć liczbę jednostek RU/s na partycję fizyczną.
Zaleca się monitorowanie ogólnej szybkości 429 odpowiedzi i użycia jednostek RU/s. Aby uzyskać więcej informacji, zapoznaj się z krokiem 1 , aby zweryfikować oczekiwaną wydajność.
Po wprowadzeniu zmian przy założeniu, że ogólne obciążenie nie uległo zmianie, prawdopodobnie zobaczysz, że zarówno partycje docelowe, jak i źródłowe mają wyższe znormalizowane użycie jednostek RU niż wcześniej. Oczekiwane jest wyższe znormalizowane użycie jednostek RU. Zasadniczo przydzielono jednostki RU/s bliżej tego, co każda partycja rzeczywiście musi zużywać, więc wyższe znormalizowane użycie jednostek RU oznacza, że każda partycja w pełni korzysta z przydzielonych jednostek RU/s. Należy również oczekiwać, że ogólna szybkość 429 wyjątków będzie niższa, ponieważ gorące partycje mają teraz więcej jednostek RU/s do obsługi żądań.
Ograniczenia
Kryteria uprawnień wersji zapoznawczej
Aby korzystać z wersji zapoznawczej, konto usługi Azure Cosmos DB musi spełniać wszystkie następujące kryteria:
- Twoje konto usługi Azure Cosmos DB używa interfejsu API dla bazy danych NoSQL lub interfejsu API dla bazy danych MongoDB.
- Jeśli używasz interfejsu API dla bazy danych MongoDB, wersja musi mieć wartość >= 3.6.
- Konto usługi Azure Cosmos DB korzysta z aprowizowanej przepływności (ręcznej lub skalowanej automatycznie). Dystrybucja przepływności między partycjami nie ma zastosowania do kont bezserwerowych.
Nie musisz rejestrować się, aby korzystać z wersji zapoznawczej. Aby użyć tej funkcji, użyj poleceń programu PowerShell lub interfejsu wiersza polecenia platformy Azure, aby ponownie dystrybuować przepływność między partycjami fizycznymi zasobów.
Następne kroki
Dowiedz się, jak używać aprowizowanej przepływności, korzystając z następujących artykułów:
- Dowiedz się więcej o aprowizowanej przepływności.
- Dowiedz się więcej o jednostkach żądań.
- Chcesz monitorować gorącą partycję? Zobacz Monitorowanie jednostek żądań.
- Chcesz poznać najlepsze rozwiązania? Zobacz najlepsze rozwiązania dotyczące skalowania aprowizowanej przepływności.