適用対象: 
NoSQL MongoDB
Azure Cosmos DB のスループット再配布機能を使用すると、プロビジョニングされたスループットを物理パーティション間に再配布できます。 この記事では、パーティション間での Azure Cosmos DB のスループットの再配布についてよく寄せられる質問に回答します。
この機能はどのリソースで使用できますか?
この機能は、MongoDB アカウントの SQL と API でのみサポートされています。 これは、専用スループット (手動または自動スケーリング) を備えた共有スループット データベースとコンテナーまたはコレクションでサポートされています。 この機能は、サーバーレス アカウントには適用されません。
プレビュー機能に登録する方法
プレビューに登録する必要はありません。 この機能を使うには、単に Azure PowerShell または Azure CLI で関連するコマンドを使って、リソースの物理パーティション全体にスループットを再分散します。
この機能は、Azure PowerShell と Azure CLI の Azure Cosmos DB 機能のどのバージョンでサポートされていますか?
物理パーティション全体で RU/s を再分散する機能は、Azure PowerShell のプレビュー バージョン (バージョン 2.0.2 プレビュー以降)[https://www.powershellgallery.com/packages/Az.CosmosDB/2.0.2-preview] と Azure CLI の最新プレビュー バージョンでのみサポートされています。
1 つの要求で変更できる物理パーティションの最大数はいくつですか?
- 1 つの要求に含めることができるソース パーティションと物理パーティションの最大数は、それぞれ 20 個です。
- 要求ごとに少なくとも 1 つのソースと 1 つのターゲット物理パーティションを指定する必要があります。 ソース パーティションには、ターゲット パーティションに再配布するのに十分な RU/秒が必要です。
- ターゲット物理パーティションごとに必要な RU/秒は、10,000 RU/秒またはリソース全体の合計 RU/秒を超えることはできません。 必要な RU/秒がリソース全体の RU/秒より大きい場合は、RU/秒を再配布する前にまず、全体の RU/秒を増やします。
パーティション間にスループットを再配布する呼び出しを行うことができる頻度に制限はありますか?
1 分間に最大 5 つの要求を行って、パーティション間にスループットを再配布できます。
RU/秒全体を変更すると、RU/秒の配布はどうなりますか?
RU/秒を小さくすると、各物理パーティションは新しい RU/秒を同等の割合で取得します (
current throughput fraction * new RU/s)。 たとえば、コレクションに 6000 RU/秒と 3 つの物理パーティションがあるとします。 それを 3000 RU/秒にスケールダウンします。スケールダウン前 (6000 RU/秒) スケールダウン後 (3000 RU/秒) 合計 RU/秒の割合 P0: 1000 RU/秒 P0: 500 RU/秒 1/6 P1: 4000 RU/秒 P1: 2000 RU/秒 2/3 P2: 1000 RU/秒 P2: 500 RU/秒 1/6 RU/秒を増やすと、各物理パーティションの RU/秒 =
MIN(current throughput fraction * new RU/s, 10,000 RU/s)になります。 物理パーティションの RU/秒が、10,000 RU/秒を超えることはありません。たとえば、コレクションに 6000 RU/秒と 3 つの物理パーティションがあるとします。 最大 12,000 RU/秒にスケールアップします。
スケールアップ前 (6000 RU/秒) スケールアップ後 (12,000 RU/秒) 合計 RU/秒の割合 P0: 1000 RU/秒 P0: 2000 RU/秒 1/6 P1: 4000 RU/秒 P1: 8000 RU/秒 2/3 P2: 1000 RU/秒 P2: 2000 RU/秒 1/6
コンテナーの全体的な RU/秒と、すべての物理パーティションの RU/秒の合計に不一致があるのはなぜですか?
この不一致は、RU/秒全体をスケールアップして、単一のパーティションで
(current RU/s per partition * new container RU/s)/(old container RU/s)が10,000 RU/秒を超えたときに発生する可能性があります。 この不一致は、RU/秒をcurrentNumberOfPartitions * 10,000 RU/sを超えて増やしたためにパーティション分割がトリガーされたか、パーティション分割のトリガーなしで RU/秒を増やしたときに発生する可能性があります。スケールアップ後にスループットを均等に再配布することをお勧めします。 そうしない場合、プロビジョニング済み (かつ課金対象) のすべての RU/秒を使用できなくなる可能性があります。
このシナリオがリソースに適用されるかどうかを確認するには、Azure Monitor メトリックを使用します。 ProvisionedThroughput (手動スループットを使用している場合) または AutoscaleMaxThroughput (自動スケーリングを使用している場合) メトリックの値を、PhysicalPartitionThroughput メトリックの値と比較します。 PhysicalPartitionThroughput の値が ProvisionedThroughput または AutoscaleMaxThroughput より小さい場合は、再配布する前に RU/秒を偶数の配布にリセットするか、リソースのスループットを PhysicalPartitionThroughput の値まで減らします。
たとえば、コレクションに 6000 RU/秒と 3 つの物理パーティションがあるとします。 最大 24,000 RU/秒にスケールアップします。 スケールアップ後、すべてのパーティションの合計スループットはわずか 18,000 RU/秒です。 この配布では、24,000 RU/秒に対して課金される一方で、有効なスループットは 18,000 RU/秒しか得ることができないことを意味します。 RU/秒が均等に再配布されると、各パーティションが 8,000 RU/秒を取得し、必要に応じて RU/秒を再配布できます。 RU/秒全体を 18,000 RU/秒に減らすという選択もできます。
スケールアップ前 (6000 RU/秒) 24,000 RU/秒にスケールアップした後 (有効な RU/秒 = 18,000 RU/秒) 合計 RU/秒の割合 P0: 1000 RU/秒 P0: 4000 RU/秒 1/6 P1: 4000 RU/秒 P1: 10000 RU/秒 (パーティションが 10,000 RU/秒を超えることはありません) 2/3 P2: 1000 RU/秒 P2: 4000 RU/秒 1/6