1

私の文書構造は次のとおりです。

"_id": ObjectId("50c41fae0e708237dc7a5187"),
"uid": "999",
"appname": "authentication",
"activityId": "login",
"activityName": "login",
"date": ISODate("2012-12-09T05: 20: 46.117Z"),
"yearmonth": "201212"

uid は、RDMS シーケンスから他のアプリケーションによって生成されたユーザー ID です。yearmonth は、より良いシャード キーを目的としてアプリで作成した人工的なフィールドです。

書き込みパターン: ユーザーがログインするか、サイトで特定のアクションを実行すると、イベントを mongoDB に書き込みます。これは、uid が非常に高いカーディナリティで比較的ランダムであることを意味します。同じ uid に対して、何百ものイベントを記述できます。

読み取りパターン: ほとんどのクエリは、最初のクエリ パラメータとして uid に基づいています。{uid:"9999",date:{$gt: ....}, activityId:'login'}

私の最初のシャード キーは {uid:1, date:1} でした。- 優れたクエリ分離を提供し、いずれかの uid にドキュメントが多すぎる場合に分割可能なチャンクを提供します。ここで、シャード キーの選択方法: カード ゲームの記事といくつかのウェビナー、およびこのフォーラムのコメントに基づいて、より良いキーは {coarse timestamp:1 , search criteria:1} を持つものである必要があることに気付きました。アイデアは、書き込みパフォーマンスを向上させるために、シャード キーの局所性を向上させることです。yearmonth フィールドを作成し、シャード キーを {yearmonth:1, uid:1} に変更することを考えています。

問題は、変更によってクエリの分離と読み取り操作のパフォーマンスが低下するかどうかです。クエリ パラメータがシャード キーの最初の要素と一致しなくなりました。

4

1 に答える 1

0

データをフェッチするために使用するキーはuidであるため、私はuidを使用します。

シャードキー-uid

特に、ランダムなuidベースのイベントの挿入と読み取りの場合、uidをシャードキーとして保持することが非常に最適です。

チャンクが大きくなると、MongoDBのバランサーが異なるシャードサーバー間でチャンクのバランスを自動的に調整します。したがって、ここでも説明します（自動バランスにより、大きくなりすぎるシャードサーバーが処理されるため）。

お役に立てれば。

于 2012-12-20T18:57:12.623 に答える