適用対象: 
NoSQL MongoDB Cassandra Gremlin Table
階層パーティション キー (サブパーティション分割) を使用すると、パーティション キーに対して最大 3 レベルの階層を構成して、データ分散をさらに最適化し、より高いスケールを実現できます。 この記事では、Azure Cosmos DB の階層パーティション キーに関してよく寄せられる質問に回答します。
既存のコンテナーに階層パーティション キーを追加できますか?
既存のコンテナーへの階層パーティション キーの追加はサポートされていません。 ただし、目的の階層パーティション キーを使用して新しいコンテナーを作成し、コンテナー コピー ジョブを実行して、既存のコンテナーから新しいコンテナーにデータをコピーできます。 データをコピーする方法の詳細については、コンテナー コピー ジョブに関するページを参照してください。
論理パーティション キーのサイズに対してストレージ制限はありますか?
はい。 現在の Azure Cosmos DB と同様に、論理パーティションのサイズはまだ 20 GB に制限されています。 ただし、階層パーティション キーでは、論理パーティションがパーティション キー パスの全体になります。 たとえば、TenantId -> UserId でパーティション分割した場合、論理パーティションの例は Contoso_Alice になります。 サブパーティション分割を利用すると、パーティション キー値が Contoso_Alice である 20 GB のデータを使用できます。 "Contoso" のデータに対して許可されるストレージの量は、実質的に、20 GB に "Contoso" テナントの一意の UserId の数を掛けたものになります。
物理パーティションのストレージと RU/秒の制限に変更はありますか?
いいえ。 現在の Azure Cosmos DB と同様に、物理パーティションは 50 GB のストレージを保持し、最大 10,000 RU/秒を提供できます。 ただし、階層パーティション キーでは、特定のパーティション キー プレフィックス (TenantId など) のデータが複数の物理パーティションに存在する場合、サブパーティション分割により、1 つの TenantId で達成可能な RU/秒の合計が 10,000 RU/秒を超えることができるようになります。
クエリを実行し、パスの "中間" のパーティション キーのみを指定した場合はどうなりますか?
クエリはパーティション間クエリです。 たとえば、TenantId -> UserId でパーティション分割されている場合、クエリで UserId のみを指定すると、このクエリはすべての物理パーティションにファンアウトします。
TenantId -> UserId の例を使用してクエリを効率的にルーティングするには、2 つのオプションがあります。
- TenantId を指定します。 クエリは、TenantId データを含むすべての物理パーティションに送られます。
- TenantId と UserId の両方を指定します。 クエリは、TenantId と特定の UserId を含む単一の物理パーティションに送られます。
この機能を使用するには、ドキュメントに新しいプロパティを作成する必要がありますか?
いいえ。 コンテナーの作成時に、使用するパーティション キー パスの階層を指定します。 たとえば、TenantId -> UserId でパーティション分割する場合、これらの値を連結して新しいプロパティを作成する必要はありません。 各ドキュメントに、プロパティ TenantId とプロパティ UserId があることを確認します。 詳細については、サブパーティション分割のコード例を参照してください。
カーディナリティがそれほど高くないキーの階層を作成しました。 どうすればよいですか。
ワークロードにより、すべてのパーティションのうち数個の物理パーティションしか使用されないシナリオになっているかもしれません。 このシナリオは、階層パーティション キーの 1 つ以上のレベルのカーディナリティが低いことを示している可能性があります。 シナリオをトラブルシューティングするには、常に、階層パーティション キーを再作成することをお勧めします。それにより、DTS を使用してキーを変更し、コンテナーのデータを新しいコンテナーにコピーできます。 この手順を実行できない場合は、データの一様分布が確保される次の 2 つの回避策をお勧めします。
- アプローチ 1:
- RU 数が 10,000 個未満のコンテナーを作成して、確実に 1 つの物理パーティションしか存在しないようにすることができます。
- 約 5 GB のデータを取り込んで、パーティション分割が発生しないことを確認します。
- 目的の RU 数にスケールアップし、データの取り込みを続行すると、Azure Cosmos DB によって確実に物理パーティションが均一に分割されます。
- アプローチ 2:
- 合計のオファーをより多い RU 数に増やし、すべてのデータを取り込むことができます。
- 次に、パーティションのマージを実行して、ワークロードのパーティションが断片化されておらず、均等に分布していることを確認します。
- マージが完了したら、元の目的の RU 数にスケールダウンします。
各パーティションのスループット数をより細かく制御するには、スループット再分散を使用して、ワークロードで使用するパーティションに将来の要求のための十分な RU 数が確実に割り当てられるようにすることもできます。
次の手順
- 階層パーティション キーの詳細を理解してください。