1

書き込みが多いアプリケーションでは、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% になります。

4

3 に答える 3

2

UUID を使用すると、シャード全体に書き込みアクセスが分散されますが、クエリが分離されないため、クエリで最適な結果が得られません。最速のクエリは、1 つのシャードのみが応答するクエリです。 http://docs.mongodb.org/manual/core/sharding-internals/#sharding-shard-key-query-isolation

それは、あなたのコレクションに何が入っているかを知るのに役立ち、より効率的にするのに役立ちます.

于 2012-12-07T21:37:19.747 に答える
1

UUID の使用はまったく問題ありません (これらのドキュメントをプライマリ/シャード キーでのみ検索する場合)。シャード キーの目的の 1 つは、関連するドキュメントをグループ化することです。たとえば、flickr を構築している場合、シャード キーは で始まるuser_idため、ユーザーの写真が 1 つのシャードにまとめられます。ドキュメントが関連しておらず、主キーもシャード キーである場合、問題はありません。

于 2012-12-07T17:16:59.567 に答える
1

次のリリースで修正される予定のhttps://jira.mongodb.org/browse/JAVA-403が原因で問題が発生する可能性があります。

于 2012-12-08T14:20:02.047 に答える