0

たとえば、 A <-> interact <-> B などのプロファイル インタラクションのモデルを設計したいと考えています。インタラクションには、A と B の共通フィールドが含まれています
。Interactions というコレクションがあるとします。ベスト プラクティス ソリューションの場合。

  1. インタラクションをプロファイルごとに 1 つずつ、2 つの異なるドキュメントに分けます。

    {
  pid:"A ID"
  commonField1:""
  commonField2:""
  ..

}
{
  pid:"B ID"
  commonField1:""
  commonField2:""
  ..
}

    長所: 高速読み取り
    短所: 共通フィールドの各更新は、両方のドキュメントで実行する必要があります

  2. インタラクション用に 1 つの文書を維持する

    {
 pids:['A ID','B ID']
 commonField1:""
 commonField2:""
 ..
}

    長所: 共通フィールドを 1 回だけ更新する
    短所: トリッキーな読み取り

問題は、多くの読み取りがあるだけでなく、多くの更新もあり、このコレクションは何百万ものドキュメント用に設計されている必要があるということです.

私のシナリオでの一般的なクエリ:

  • プロファイル インタラクションを取得する
  • 特定のプロファイル インタラクションを更新する

私は pid のマルチキー インデックスに依存して高速なドキュメント検索を行う 2 番目の選択肢に傾いています。

シャード コレクションの経験はありませんが、マルチキー インデックスがシャーディング キーとしてサポートされていないことに気付きました。
その種のインデックスで読み取りは十分に高速ですか？私のユースケースでは他の選択肢がありますか？

あなたの答えは高く評価されています。

4

1 に答える 1

0

更新の重複を避けるには、後者の形式の方が理にかなっていると思います。

相互作用のペアについては、配列ではなく複合インデックスを使用する必要があります。複合インデックスは、シャード キーとしても使用でき_idます (配列はどちらにも有効ではありません)。

したがって、ドキュメントは次のようになります。

{
    _id: { pid1: 'A', pid2: 'B' },
    commonField1: '',
    commonField2: '',
}

ペアの重複を避けたい場合は、ID を予測可能な順序で並べ替えることができます。たとえば、pid1常に 2 つの値の小さい方になる場合があります。

デフォルトの_idインデックスを使用すると、(pid1,pid2) または (pid1) の相互作用を効率的に検索できますが、おそらく に追加のインデックスを追加することをお勧めします{'_id.pid2': 1}。

于 2014-03-24T02:50:37.850 に答える