3

顧客が食品を「愛する」多対多の関係をモデル化しようとしています。

私はこれらのリレーションシップを大量 (数百万) 取得することを期待しているので、スケーリングできない 1 つの結合テーブルになってしまうことを望んでいませんでした。

2 つのドキュメント コレクションを作成しました。

Customers
 - name etc 
 - countOfLoves
 - loves [ ... ]

と

Foods
 - name etc
 - countOfLoves
 - loves [ ... ]

各ドキュメント内には、関係を表す「愛」のサブドキュメント コレクションと、合計をすばやく取得するためのカウントがあります。

何百万もの行を持つテーブルに対するクエリの代わりに、単一のドキュメントとそれが部分配列を取得できるため、これは適切にスケーリングされると想定していました。しかし、顧客がたくさんの食べ物を好きになり始めたとき (逆に、食べ物が多くの顧客に愛されたとき) に問題が発生します。

新しい食べ物が気に入ったときに顧客ドキュメントを更新するクエリを次に示します。この場合、顧客はすでに 7000 種類の食品を気に入っています。

 query: { _id: "354286" } 
update: { $push: { loves: { foodID: "354286", location: [ 55.752197, 37.6156 ] } }, $inc: { countOfLoves: 1 } }
nscanned:1 nupdated:1 keyUpdates:0 locks(micros) w:10135199 10137ms

ここで 2 つの質問があります。

a) なぜこれに 10 秒かかるのですか? $push について何かわからないことがありますか?

b) この種の関係をモデル化できる Mongo 用のより優れたスキーマはありますか?

(そして、私は推測します (c) - 最適化しすぎていますか? ラブ結合テーブルを作成するだけで問題ありませんか?)

4

1 に答える 1

1

ドキュメントのサイズが大きくてその場所に収まらない場合、遅くなることがわかっている理由の 1 つは、別の場所に移動されることです。これは 10 秒の理由のオンである可能性があります。ここで同様の議論を見ることができます: https://groups.google.com/forum/?fromgroups=#!topic/mongodb-user/FnL0mDWs5w0。作成中に配列にダミー値を入力し、新しい love を追加せずにそれらを更新する方法を使用する解決策の 1 つです。この場合、Loves としてもう 1 つのコレクションを選択する必要があるかもしれません。それぞれの Love について、顧客 ID と彼が何を愛しているかを保存します。

于 2013-04-04T12:15:42.467 に答える