3

私は自分のデータに最適なシャード キーを (複合インデックスを介して) 選択することを考えていて、ドキュメントの作成日と顧客番号の組み合わせを考えていました。(または請求書番号) の組み合わせが適切です。IF MongoDB は、顧客番号を逆方向の文字列と見なします。

90043 => 34009
90044 => 44009
90045 => 54009
etc.

作成日のインデックスは、比較的新しいデータがメモリに保持されることを保証し、後方の顧客番号は、MongoDB がクラスター全体にデータ/負荷を分散するのに役立ちます。

これは正しい仮定ですか？もしそうなら...期待どおりに配布するには、顧客をリバースしないで保存する必要がありますか?

4

3 に答える 3

1

「私が期待する方法で顧客を配布するために、顧客を逆転させないようにする必要があるか」というあなたの特定の質問に関して、いいえ、あなたはそうしません。

リストした顧客番号の値の広がりが比較的狭い場合でもcustomerNumber、複合キーで使用する場合、MongoDBはデータをチャンクに分割し、それに応じてこれらを分散します。に関連付けられたデータcustomerNumberが比較的均等に分散されている限り（たとえば、1人のユーザーがシステムを支配していない場合）、必要なシャードのバランスをとることができます。

複合キーの適切な候補として、元の選択（文字列の反転を除く）またはDanの選択（タイムスタンプの代わりに組み込みのObjectIdを使用）のいずれかを検討します。

于 2012-12-20T16:58:41.083 に答える
0

ドキュメントで読んだことから、MongoIdはすでに時間ベースです。したがって、次のように _id を複合キーに追加できます: (_id, customerid)。アプリケーションで日付が必要ない場合は、フィールドをドロップするだけでストレージを節約できます。

MongoDB は、最近使用されたデータセットをメモリに保存します。コレクションのインデックスは、常に RAM に格納しようとします。

インデックスが大きすぎて RAM に収まらない場合、MongoDB はディスクからインデックスを読み取る必要があります。これは、RAM から読み取るよりもはるかに遅い操作です。サーバーが残りの作業セットと組み合わせてインデックスに使用できる RAM を持っている場合、インデックスは RAM に収まることに注意してください。

お役に立てれば。

乾杯団

于 2012-12-20T16:18:26.957 に答える