ドキュメントを調べましたが、明確な答えが見つかりませんでした
[a,b,c] にスパース インデックスがあるとします。
"a" "b" フィールドを持ち、"c" フィールドを持たないドキュメントはインデックスに挿入されますか?
最新のmongodbバージョンでは、シャードキーにインデックスを付けることが義務付けられていますか?
もしそうなら、上記の複合スパースインデックスを使用して[a]をシャードすることは可能ですか? (a、bは常に存在するとします)
c
が存在せず、クエリがクエリプランでインデックスを使用している場合c
、ドキュメントはインデックスに存在しないため、ドキュメントは見つかりません。shard key
のメモもご覧ください。理想的なシャードキー:
は簡単に分割できるため、MongoDBはシャード間でコンテンツを簡単に配布できます。可能な値の数が限られているシャードキーは、「分割できない」チャンクになる可能性があるため、理想的ではありません。詳細については、カーディナリティのセクションを参照してください。単一のシャードがボトルネックになるのを防ぐために、書き込み操作をクラスター間で分散します。このため、挿入時間との相関が高いシャードキーは適切な選択ではありません。ただし、「ランダム性」が高いシャードキーは、この要件をより適切に満たします。追加の背景については、書き込みスケーリングのセクションを参照してください。これにより、mongosは、単一の特定のmongodインスタンスからほとんどのクエリ操作を直接返すことができます。シャードキーは、クエリで使用される主要なフィールドである必要があります。このため、「ランダム性」の高いフィールドは適切な選択ではありません。具体的な例については、「クエリの分離」セクションを参照してください。
したがって、仮に、mongoがスパースインデックスをシャードキーとして受け入れる場合、mongoはインデックスに収まらないドキュメントをどこに配置するかを知りません。この目的のために、それらすべてを別のシャードに入れると主張することができます。反論は、それが大きくなった場合にどうなるかということです...したがって、それが許可されていても、それを行うことは意味がないと思います。
3-シャードには一意のインデックスが必要であり、スパースインデックスは基準を満たしていないため、スパースインデックスが機能するとは思えません。一意のインデックス要件は、ドキュメントにはありませんが、mongo adminシェルヘルプを使用すると、それについて説明されます。