AI エージェント向け: ドキュメントインデックスは https://www.mongodb.com/ja-jp/docs/llms.txt で利用できます。すべてのページの markdown バージョンは、いずれかの URL パスに .md を追加することで利用できます。
Docs Menu

シャードキーの選択

シャードキーを選択する際には、次のことを検討します。

注意

  • MongoDB 5.0 以降では、 reshardCollection コマンドを使用してシャードキーを変更し 、データを再配布できます。

  • refineCollectionShardKeyコマンドを使用して、コレクションのシャードキーを調整できます。 refineCollectionShardKeyコマンドは、既存のキーにサフィックス フィールドを追加して、新しいシャードキーを作成します。

  • シャードキー フィールドが不変の _id フィールドでない限り、ドキュメントのシャードキー値を更新できます。

重要

ドキュメントのシャードキー値を定期的に変更して、値が別のシャードのシャードキー範囲内にあると、シャード間でのドキュメントの移行に関係する追加のリソースが原因で、クラスターのパフォーマンスに影響を与える可能性があります。 詳細については、「 チャンクと db を使用したデータのパーティショニング 」を参照してください。コレクション.updateOne()

シャードキーの濃度によって、バランサーが作成できるチャンクの最大数が決まります。可能な場合は、濃度の高いシャードキーを選択してください。濃度が低いシャードキーでは、クラスター内の水平方向のスケーリングの有効性が低下します。

ユニークなシャードキー値は、それぞれ常に単一のチャンクにしか存在できません。continent フィールドを持つユーザー データを含むデータセットを検討します。continent 上でシャードすることを選択した場合、シャードキーの濃度は 7 になります。濃度が 7 というのは、シャーディングされたクラスター内に 7 個以下のチャンクしか存在できず、各チャンクには 1 つの固有のシャードキー値が格納されるということを意味します。これにより、クラスター内の有効なシャードの数も 7 個に制限されます。7 個を超えるシャードを追加してもメリットはありません。

以下の図は、フィールド X をシャードキーとして使用するシャーディングされたクラスターを示します。X の濃度が低い場合、挿入の分散は以下のようになります。

濃度が低いことでシャードキーの配布が不十分となる図
クリックして拡大します

データモデルで濃度の低いキーをシャーディングする必要がある場合は、濃度を高めるためにインデックス付きの複合フィールドを使用することを検討してください。

濃度の高いシャードキーだけでは、シャードされたクラスター全体へのデータの均等な分散は保証されません。シャードキーの頻度とシャードキー値が単調に変化する可能性も、データの分散に影響します。

シャードキーの frequency は、データ内に特定のシャードキー値が出現する頻度を表します。ドキュメントの大半に、可能なシャードキーの値のサブセットしか含まれていない場合、それらの値を持つドキュメントを格納するチャンクがクラスター内のボトルネックになる可能性があります。さらに、これらのチャンクが大きくなると、それ以上分裂できなくなるため、分割不可チャンクになる可能性があります。これにより、クラスター内の水平スケーリングの有効性が低下します。

以下の図は、フィールド X をシャードキーとして使用するシャーディングされたクラスターを示します。X の値のサブセットが高頻度で発生する場合、挿入の分散は次のようになります。

頻度が高いことでシャードキーの配布が不十分となる図
クリックして拡大します

データモデルで、頻度の高い値を持つキーをシャーディングする必要がある場合は、ユニークな値または低頻度の値を使用する複合インデックスを使うことを検討します。

A shard key with low frequency does not, on its own, guarantee even distribution of data across the sharded cluster. The cardinality of the shard key and the potential for monotonically changing shard key values also contribute to the distribution of the data.

単調に増加または減少する値のシャードキーを使用すると、クラスター内の単一のチャンクに挿入が分散される可能性が高くなります。

これは、すべてのクラスターに MaxKey を上限とする範囲を取得するチャンクがあるために発生します。maxKey は、常に他のすべての値よりも高いとみなされます。同様に、MinKey を下限とする範囲を取得するチャンクもあります。minKey は、常に他のすべての値よりも低いとみなされます。

シャードキー値が常に増加している場合、新しい挿入はすべて maxKey を上限とするチャンクにルーティングされます。シャードキー値が常に減少している場合、新しい挿入はすべて minKey を下限とするチャンクにルーティングされます。そのチャンクを含むシャードが書き込み操作のボトルネックになります。

データ分散を最適化するために、グローバル maxKey(または minKey)を含むチャンクは同じシャード上に留まりません。チャンクが分割されると、maxKey(または minKey)チャンクを含む新しいチャンクは別のシャードに配置されます。

以下の図は、フィールド X をシャードキーとして使用するシャーディングされたクラスターを示します。X の値が単調に増加している場合、挿入の分散は次のようになります。

シャードキーが単調に増加または減少することによるシャードキーの配布不良の図
クリックして拡大します

シャードキーの値が単調に減少している場合は、代わりにすべての挿入は Chunk A にルーティングされます。

データモデルで単調に変化するキーをシャーディングする必要がある場合は、ハッシュされたシャーディングの使用を検討してください。

単調に変化しないシャードキーだけでは、シャーディングされたクラスター全体へのデータの均等な分散は保証されません。シャードキーの濃度と頻度も、データの分散に影響します。

理想的なシャードキーは、シャーディングされたクラスター全体にデータを均等に分散すると同時に、一般的なクエリ パターンを容易にします。シャードキーを選択するときは、最も一般的なクエリパターンと、選択したシャードキーがそれをカバーしているかどうかを検討します。

シャーディングされたクラスターでは、クエリにシャードキーが含まれている場合、mongos は関連データを含むシャードにのみクエリをルーティングします。クエリにシャードキーが含まれていない場合、評価のためにクエリはすべてのシャードにブロードキャストされます。このようなタイプのクエリは、スキャッター ギャザー クエリと呼ばれます。リクエストごとに複数のシャードを含むクエリは効率が悪く、クラスターにシャードを追加しても直線的にスケーリングできません。

これは、大量のデータを操作する集計クエリには適用されません。このような場合、スキャッター ギャザーはすべてのシャードでクエリを並行して実行できる有効なアプローチとなる可能性があります。

7.0 以降、MongoDB では、シャードキーの選択が簡単になります。analyzeShardKey を使用すると、シャーディングされていないコレクションまたはシャーディングされたコレクションのシャードキーを評価するためのメトリクスを計算できます。メトリクスはサンプリングされたクエリに基づいているため、シャードキーについてデータに基づいた選択を行うことができます。

シャードキーを分析するには、ターゲット コレクションでクエリのサンプリングを有効にする必要があります。詳細については、以下を参照してください。

クエリのサンプリング プロセスをモニターするには、$currentOp ステージを使用します。例については、「サンプル クエリ」を参照してください。

シャードキーを分析するには、以下を参照してください。

analyzeShardKey は、シャードキーの主要な特性と、読み取りおよび書込みの分布に関するメトリクスを返します。メトリクスは、サンプリングされたクエリに基づいています。

  • keyCharacteristics フィールドには、シャードキーの濃度、頻度、単調性に関するメトリクスが含まれています。

  • readWriteDistribution フィールドには、クエリ ルーティング パターンとシャードキー範囲の負荷分散に関するメトリクスが含まれます。