MongoDB4.2を使用する3つのシャードを持つクラスターがあります。シャーディングをチェックする前に、600000個のドキュメントがあるコレクション(ユーザー)があります。
mongos> db.users.count()
600000
次に、通常のコマンド(最初のDB、次のコレクション)でシャーディングします。
mongos> sh.enableSharding("app")
mongos> sh.shardCollection("app.users", {"name.first": 1})
数分後、シャード間でチャンクが均等に分散します。
chunks:
shard0000 3
shard0001 2
shard0002 3
ここまでは順調ですね。
ただし、この直後にカウントを取得すると、コレクション内のドキュメントの数よりも多い奇妙な値が取得されます。
mongos> db.users.count()
994243
mongos> db.users.find({}).count()
994243
さらに、getShardDistribution()
コレクションの結果も奇妙で、1つのシャードにすべてのドキュメントの総数が表示されます(一部が他の2つのシャードに配布されているため、意味がありません)。
mongos> db.users.getShardDistribution()
Shard shard0000 at localhost:27018
data : 95.85MiB docs : 236611 chunks : 3
estimated data per chunk : 31.95MiB
estimated docs per chunk : 78870
Shard shard0001 at localhost:27019
data : 64.06MiB docs : 157632 chunks : 2
estimated data per chunk : 32.03MiB
estimated docs per chunk : 78816
Shard shard0002 at localhost:27020
data : 243.69MiB docs : 600000 chunks : 3
estimated data per chunk : 81.23MiB
estimated docs per chunk : 200000
Totals
data : 403.62MiB docs : 994243 chunks : 8
Shard shard0000 contains 23.74% data, 23.79% docs in cluster, avg obj size on shard : 424B
Shard shard0001 contains 15.87% data, 15.85% docs in cluster, avg obj size on shard : 426B
Shard shard0002 contains 60.37% data, 60.34% docs in cluster, avg obj size on shard : 425B
興味深いことに、しばらく待つと(どれくらいかはわかりませんが、30分以内)、数えgetShardDistribution()
て正常に戻ります。
mongos> db.users.count()
600000
mongos> db.users.getShardDistribution()
Shard shard0001 at localhost:27019
data : 64.06MiB docs : 157632 chunks : 2
estimated data per chunk : 32.03MiB
estimated docs per chunk : 78816
Shard shard0002 at localhost:27020
data : 83.77MiB docs : 205757 chunks : 3
estimated data per chunk : 27.92MiB
estimated docs per chunk : 68585
Shard shard0000 at localhost:27018
data : 95.85MiB docs : 236611 chunks : 3
estimated data per chunk : 31.95MiB
estimated docs per chunk : 78870
Totals
data : 243.69MiB docs : 600000 chunks : 8
Shard shard0001 contains 26.28% data, 26.27% docs in cluster, avg obj size on shard : 426B
Shard shard0002 contains 34.37% data, 34.29% docs in cluster, avg obj size on shard : 426B
Shard shard0000 contains 39.33% data, 39.43% docs in cluster, avg obj size on shard : 424B
なんでこんなことが起こっているの?この影響を回避するにはどうすればよいですか?(たぶん、コマンドで何らかの同期を強制しますか?)
ありがとう!
PD:関連がある場合は、スタンドアロンmongod
プロセスを使用して各シャードを実装するテスト環境のセットアップを使用しています。構成サーバーは、モノノードレプリカセット構成を使用します。
count
推定数を提供し、正確でない場合があります。countDocuments
正確なカウントを取得するために使用します。
シェルにgetShardDistribution
入力するdb.users.getShardDistribution
と、のソースを読み取ることができます。設定データベースに保存されている情報を使用しているようです。
データベースによって保存された統計が正確ではないと予想することは非常に合理的です。これは、クラスター内のどこかで操作が実行されるたびに、それらを最新の状態に保つにはコストがかかるためです。
一部のチャンクが1つのシャードから別のシャードにコピーされた後、これらのチャンクが元のシャードから削除される前のある時点で統計を確認しているようです。この状況では、データはクラスターに2回保存されます。この場合、統計は正確ではありません。正確なカウントを取得するには、を使用しますcountDocuments
。
この記事はインターネットから収集されたものであり、転載の際にはソースを示してください。
侵害の場合は、連絡してください[email protected]
コメントを追加