ここに記載されている手順に従って、単一のマシンにシャード クラスターをセットアップしました
:
http://www.mongodb.org/display/DOCS/A+Sample+Configuration+Session
' オプション:
$ ./mongos --configdb localhost:20000 --chunkSize 1 > /tmp/mongos.log &
N 個のシャードでは、各シャードは 1/N 個のドキュメントを持ち、シャード キーの範囲を N 個のほぼ等しい部分に分割する必要がありますよね? これにより、chunkSize/shard-size が自動的に修正されます。上記のコマンドはどのチャンクを扱っていますか?
また、キーの特定の値でコレクションを手動で分割し、チャンクを必要な他のシャードに移行することもできます。これは手動で行うことができ、「バランサー」によって自動的に処理されます。しません
助けてくれてありがとう。
あなたはいくつかのことを混乱させているかもしれません。--chunkSize パラメータは、分割を行うためのチャンク サイズを設定します。_id が「chunksize」の「config」データベース内の「settings」コレクションは、設定されている場合、現在の値を確認します。--chunkSize オプションは、この値のみを設定するか、値がまだ設定されていない場合はシステムに変更を加えます。それ以外の場合は無視されます。
チャンク サイズは、システムがチャンクを保持するメガバイト単位のサイズです。これは、1) 書き込みが mongos インスタンスを通過するとき、および 2) バランシング中にチャンクを別のシャードに移動する前の 2 つの場所で行われます。そのため、「データ サイズ / シャード数」の式には従いません。チャンクあたり 1Mb の例は、ほとんどの場合、悪い考えです。
実際、チャンクを手動で分割して移動することはできます。これにより、チャンクの分散が理想的でなくなる可能性がありますが、構成メタデータとバランサーが混乱したり壊れたりすることはありません。その理由は比較的単純です。バランサーは同じコマンドを使用し、同じコード パスに従います。MongoDB の観点からは、バランサー プロセスがチャンクを分割および移動することと、それを実行することの間に大きな違いはありません。
ただし、チャンクを手動で分割および移動する有効な使用例がいくつかあります。たとえば、コールド スタート (事前分割) からの非常に高いピーク負荷に備えてクラスターを準備するために、手動で行うことができます。通常、これを行うスクリプトを作成するか、すでにうまく機能しているパフォーマンス テストから分割をロードします。また、ホット チャンクを監視して、それらのチャンクを分割/移動して、アプリケーションから監視されている「負荷」に基づいて均等に分散することもできます。
それが役立つことを願っています。
まことにありがとうございます！私は今それを手に入れたと思います..私が間違っている場合は修正してください
.N台のサーバーがある場合、コレクションの最初の1/N部分(=chunk1)がshard1に移動し、2番目の1/N分( =chunk2) は shard2 などに移動します..そのような「式」がないと言ったとき、私はもう少し検索してこれらのリンクを見つけました
MongoDB sharding, 新しいノードを追加するときにどのように再調整しますか?
Mongoで各シャードのシャーディング範囲を定義する方法は?
ドキュメントの「チャンク」の定義から、単なるデータ移行の単位と考えてよいと思います。N 台のサーバー間でコレクションを分割すると、合計数は . チャンクの数は必ずしも N ではありません。また、同じサイズである必要もありません。
1 つのチャンクの最大サイズは、構成データベースの設定コレクションで既定値 (通常は 64MB) として既に設定されているか、上記のコードに示すように --chunkSize パラメーターを使用して値を指定することで手動で設定できます。shard-key の値によっては、一方のシャードが他方よりも多くのチャンクを持つ場合があります。しかし、MongoDB は、これらのチャンクをシャード間で均等に分散しようとするバランサー プロセスを使用します。均等な分散とは、チャンクが制限を超えて大きくなったり、特定のシャードの負荷が高くなったりした場合に、チャンクを分割して他のシャードに移行する傾向があることを意味します。これは、バランサ プロセスが使用するのと同じ一連のコマンドに従って、手動で行うこともできます。