書籍ScalingMongoDBから：
一般的なケース
これをシャードキーの式に一般化できます：{coarseLocality：1、search：1}
だから私の質問は、それは正しいですか？より良い執筆のための反対であるべきではありませんか？
また、本から：
このパターンは続きます。すべてが常に「最後の」チャンクに追加されます。つまり、すべてが1つのシャードに追加されます。このシャードキーは、単一の配布不可能なホットスポットを提供します。
つまり、私のアプリは常にuser_idと、コレクションの最後のエントリで検索します。
私が持っているべき最高のシャードキーは何ですか、これ：
{_id:1, user_id:1}
また：
{user_id:1,_id:1}
Kristina ( Scaling MongoDBの作成者) は、ゲームを装って説明されたいくつかの戦略例を含むブログ投稿を書きました: How to Choose a Shard Key: The Card Game .
アプリケーションの要件とユース ケースに基づいて適切なシャード キーを選択するには、多くの考慮事項があります。
順序に関する一般的なアドバイスは{coarseLocality : 1, search : 1}、読み取り用にデータの局所性を確保することです。
したがって、あなたの場合は、おそらく次のようになります{user_id:1,_id:1}。
これにより、クエリを実行するときに同じデータの局所性が提供され、user_id理想的には、一般的なクエリが単一のシャードからデータを取得できるようになります。
逆の順序は、より良い書き込み分散を提供する可能性があります ( _id がデフォルトのObjectIdのように単調に増加するキーではないことを前提としています) が、潜在的な欠点は信頼性です。読み取りクエリのデータがすべてのシャードに分散している場合、取得の問題が発生する可能性があります。 1 つのシャードがダウンしています。
私のアプリは常にuser_idとコレクションの最後のエントリで検索すると言っています。
user_id一般的に を使用して(および使用せずに)検索する場合、_idこれはシャード キーとインデックスの最適化の選択にも影響します。最後のエントリを見つけるために、MongoDB は並べ替えを行う必要があります。すべてのシャードからデータを収集して並べ替えるのではなく、単一のシャードでその並べ替えを実行する必要があります。_idたまたま日付ベースである場合、最後のエントリを見つけるためにシャード キーの一部として有益です。