GridFS と、それを異なるマシン間で分割する可能性について文書化しています。
こちらのドキュメントを読むと、推奨されるシャード キーは chunks.files_id です。このキーはファイル コレクションの _id にリンクされるため、この _id はインクリメンタルです。グリッドに保存するすべての新しいファイルには、新しいインクリメンタル _id があります。
O'Reilly の「Scaling MongoDB」本では、HotSpots を回避するために、増分シャード キーの使用は推奨されていません (最後のシャードがすべての書き込みと読み取りを受け取ります)。
GridFS コレクションをシャーディングするための提案は何ですか?
ホットスポットの問題を経験した人はいますか?
ありがとうございました。
files_idファイルのチャンクをまとめておくために断片化する必要がありますが、それがホットスポットを作成することは正しいです。可能であれば、 fs.files_idコレクションの s にObjectId 以外のものを使用します(おそらく、ObjectId よりも MD5 の方が優れているでしょう)。
シャーディング用のハッシュを追加する予定です。これにより、これは解決されますが、少なくとも 2.0 までは解決されません。
gridfs はチャンクとファイルの 2 つのコレクションだけであるため、gridfs データを分割できます。そして、gridfs シャーディングは非常に便利で素晴らしいことです。gridfs シャード キーについては、データがシャード間で均等に分散されないため、ランダムまたはインクリメンタル シャード キーを選択することは常に不適切です。増分シャード キーの場合、すべての書き込みが最後のシャードに行われ、そのシャードが成長し、その差が 10 以上のチャンクになると、バランサーはデータを別のシャードに移動します。データを別のシャードに移動することは常に困難な作業であり、可能な限り避ける必要があります。
したがって、シャード キーを選択するときは、データの均一な分散に注意する必要があります。
また、運が良ければ、「Scaling MongoDB」の著者であるkristina (シャード キーの優れたスペシャリスト) があなたの質問に答えてくれます。fileId:1,n:1ドキュメントによると、一般的なケースでは、デフォルトのインデックスをシャード キーとして
選択する必要があります。
必要に応じて、GridFS をシャーディングする方法はいくつかあります。既存のインデックスに基づいてシャードする一般的な方法の 1 つは、次のとおりです。
「files」コレクションはシャーディングされません。すべてのファイル レコードは 1 つのシャードに存在します。そのシャードを非常に回復力のあるものにすることを強くお勧めします (少なくとも 3 ノードのレプリカ セット) "チャンク" コレクションは、既存のインデックス "files_id: 1, n: 1" を使用してシャーディングされます。範囲の終わりにある一部のファイルは、チャンクが複数のシャードに分割されている場合がありますが、ほとんどのファイルは同じシャード内に完全に含まれています。
現在、バージョン 1.8.1 の MongoDB は、アップロードの検証に md5 を使用しているため、「file_id」フィールドでのシャーディングのみをサポートしていますが、シャード間ではまだ機能しません。したがって、単一のファイルを複数のシャードに分割することはできません。 Google グループ7で回答