2

シャードしたいmongodbコレクションがあります。このコレクションはユーザーからのメッセージを保持し、コレクションのドキュメントには次のプロパティがあります

{
     _id : ObjectId,
     conversationId: ObjectId,
     created: DateTime         
}

すべてのクエリは、converstionIdプロパティと、createdによるソーターを使用して実行されます。

  • conversationIdでクエリを実行する必要があるため、 _idによるシャーディングは明らかに機能しません(さらに、_idは ObjectId 型であり、多くの挿入にうまく対応できません)。

  • conversationId によるシャーディングは、クエリの分離という点では論理的な選択ですが、多くの挿入をうまくスケーリングできないのではないかと心配しています (conversationId でハッシュ化されたシャード キーを使用したり、ObjectIdからプロパティのタイプを変更したりしても)。GUID のようにインクリメンタルではない他のタイプに) ある会話は他の会話よりもはるかにアクティブである可能性があるため (つまり、より多くのメッセージが追加されている)

私がmongoのドキュメントで見たものから、シャードキーは、コレクション内のすべてのドキュメントに存在するインデックス付きフィールドまたはインデックス付き複合フィールドのいずれかです。

これは、複合インデックスでシャード キーを作成できるということですか?

要点は次のとおりです。

  • _idプロパティからハッシュ化されたシャード キーを作成すると、データが適切に分散されます。

  • conversationIdでシャード キーを作成すると、適切なクエリ分離が提供されます

したがって、これら2つのことの組み合わせが実現できれば、素晴らしいことです。

何か案は？

ありがとう

4

1 に答える 1

4

あなたの場合、どちらのフィールドもシャーディングに適していないようです。たとえば、conversationId をシャードすると、ホット スポットが発生します。つまり、conversationId が時間の経過とともに単調に増加するため、ほとんどの挿入が最後のシャードに発生します。他の 2 つのフィールドでも同じ問題が発生します。

また、conversationId は時間の経過とともに単調に増加するため、高度な分離は提供されません。(新しい会話は非常に古い会話よりも頻繁に更新されるため)

あなたの場合、conversationId よりも「ハッシュされたシャード キー」(バージョン 2.4 以降) が賢明な選択です。大量の会話が並行して行われている可能性があると想像できます。

ハッシュ化されたシャード キーの作成の詳細については、次のリンクを参照してください: [ http://docs.mongodb.org/manual/tutorial/shard-collection-with-a-hashed-shard-key/ ]

于 2013-09-05T13:43:25.917 に答える