シャーディング、シャードキー、チャンクの移行に関するドキュメントを読んだ後でも、1つの概念を理解することはできません。
自動インクリメントシャードキーを選択しない理由の概念を説明しようとしている人は、これはmongoが常に同じシャードに書き込み続けるという結果によるものであり、したがって、そのシャードが両方を行うため、負荷が増加することを教えてくれます。連続した書き込みを処理し、チャンクも移行します。
私の質問は、なぜこれが当てはまるのかということです。値の自動インクリメントにより、書き込み要求が常に1つの特定のシャードにルーティングされるのはなぜですか？モンゴスが「最もバランスの取れていない」シャードを認識し、代わりにこのシャードに書き込む必要があるというシャーディングの全体的なポイントではありませんか、それとも私はそれを間違って理解していますか？
前もって感謝します
問題は、単調に増加するキーを使用すると、Mongo がシャーディングのキー範囲を決定できないことです。サンプルは次のとおりです。
キーが 10,20,30,40,50,60 のコレクションがあるとします。mongo が 2 つのシャードを作成する必要がある場合、キーの範囲を [10,30] と [31,60] (または類似) と見なす場合があります。しかし、より大きなキーを書き続けると、常に 2 番目の範囲に移動します。Mongo は範囲を調整しますが、次のキーが何であるかを知ることはできず、常に最後の範囲に入ります。一方、適切に分散されたキーを使用すると、書き込みシーケンスは 10、60、30、40、50 のようになります。最初の 2 つのキーを書き込んだ直後に、mongo は上記の範囲を作成し、次のキーは、最初または 2 番目のいずれかに収まります。これにより、mongo 間でパフォーマンスが共有され、mongo にリバランスを強制することもありません。
現在のシャード メカニズムにはこの問題があります。基本的に、各シャードはキーが連続した範囲にあるデータを提供します。自動増分キーを選択すると、すべての書き込み操作が 1 つのシャードのみにルーティングされ、他のすべてのシャードよりも大きなキーを持つデータが提供されます。
これは、自動増分キーを使用したコレクションの問題です。幸いなことに、任意の属性をシャーディング キーとして選択できます。ほとんどの場合、「_id」をシャーディング キーとして使用する必要はありません。オブジェクトに適切な属性 (ブログ アプリケーションの「ユーザー名」など) がある場合、それをシャーディング キーとして使用できます。適切な属性がない場合は、各オブジェクトに 1 つの属性列をシャーディング キーとして追加できます。この属性は、単純なハッシュ アルゴリズムを使用して計算できます。たとえば、自動インクリメンタル _id がある場合、シャーディング キーは次のように簡単に計算できます。
sharding_key = _id % 257
シャードが 257 を超える前に、上記のハッシュで十分なはずです。
ところで、自動生成された ObjectId は、時間ベースであるため、シャーディング キーには適していません。
また、MongoDB 2.3 には、ハッシュ キーをサポートする新機能があります ( https://jira.mongodb.org/browse/SERVER-2001およびMongoDB 2.4 リリース ノートを参照)。