書き込みが多いアプリケーションでは、ObjectId を使用してシャーディング キーを使用することは非常に悪い考えであることを理解しています。ただし、Java のネイティブ *UUID.randomUUID() をシャード キーとして使用することをお勧めします。これは、完全にランダムであり、単一のシャードでホットスポットが発生しないためです。
これらの ID は128 ビット IDで、次のようになります。
- 5842fa92557947f1b020041ff74868a4
- 308947443e564d80b97dd8411b4b727e
- f8a7ee765bed4ce3bcc5800ac3a2a710
- 1bcfd08b89e94c58ae7695b3e7a1bc4f
これは、ObjectId (96 ビット int) に非常に似ています。
さらに、これは _id にインデックスを持つことが必須であるため、シャード キーは _id になり、shard_key 用に別のインデックスを作成することで RAM を節約できます。すべてのコレクションがシャーディングの準備が整います。
Mongod内のパフォーマンスの問題ですか、それともディスク/RAM スペースの問題ですか?
UUID の衝突率は (ウィキペディアから) です。 次の 100 年間、毎秒 10 億の UUID を生成した後でのみ、重複が 1 つだけ作成される確率は約 50% になります。地球上のすべての人が 6 億の UUID を所有している場合、1 つの重複の確率は約 50% になります。