web-dev-qa-db-ja.com

_idフィールドを持つ複合シャードキー

私は次のような文書を持っています:

{_id: "someid1", "bar": "somevaluebar1"}
{_id: "someid2", "foo": "somevaluefoo2", "bar": "somevaluebar2"}
{_id: "someid3", "foo": "somevaluefoo3", "Zoo": "somevaluezoo3"}
{_id: "someid4", "Zoo": "somevaluezoo4"}

ドキュメントを最も「foo」で、2番目に「bar」でクエリする場合、「foo」と「bar」も欠落している可能性があるため、{ "foo" : 1, "bar" : 1, "_id" : 1 }のような複合シャードキーを作成することには意味がありますか?

このコマンドを実行しようとしたとき

sh.shardCollection("<your-db>", {{ "foo" : 1, "bar" : 1, "_id" : 1 }:"hashed"})

構文エラーが発生しました。

1
angelokh

シャードキーのアプローチを再考する必要があります。

MongoDB 3.2と同様:

  • 複合シャードキー のすべてのフィールドは、すべてのドキュメントに存在する必要があり、不変です(つまり、既存のドキュメントのシャードキーは変更できません)。

  • ハッシュシャードキー は単一のフィールドに基づいており、範囲クエリをサポートしていません。

一般に、一般的なクエリをサポートするシャードキーを用意して、関連データで シャードのサブセットを対象とする にすることができますが、両方の場合、これは可能ではないようですfooおよびbarはオプションのフィールドです。

_idフィールドが良好なカーディナリティを提供する(つまり、値の数が多い)が単調増加している場合(たとえば、デフォルトのObjectID)、_idフィールドのハッシュされたシャードインデックスを適切な書き込み分散と見なすことができます。ハッシュ化されたインデックスは、一般的な読み取りクエリをサポートしないため(特定の_id値による場合を除く)、fooおよびbar(つまり、{foo:1, bar:1})。推奨されるセカンダリインデックスと順序は、一般的なクエリと並べ替え順序によって異なります。

詳細な背景情報については、以下を確認することをお勧めします。

2
Stennie