14

Recently I'm exploring NoSQL Databases. I need an advice about how to store data in the most optimal and efficient way for a given problem. I'm targeting MongoDB, now. However it should be the same with CouchDB.

Let's say we have these 3 Models:

Story:
 id
 title

User:
 id
 name

Vote:
  id
  story_id
  user_id

I want to be able to ask the database these questions:

  • Who has voted for this Story?
  • What this User has Voted for?

I'm doing simple joins while working with a relational DB. The question is, how should I store the data for those objects in order to be most efficient.

For example, if I store the Vote objects as a subcollection of Stories it wont be easy to get the info - "What a user has voted for".

4

5 に答える 5

7

_id各ユーザーのストーリーのリストとして投票を保存することをお勧めします。そうすれば、リストを見るだけで、ユーザーがどのストーリーに投票したかを知ることができます。ストーリーに投票したユーザーを取得するには、次のようにします。

db.users.find({stories: story_id})

story_id問題の話はどこにあり_idますか。フィールドにインデックスを作成するとstories、これらのクエリは両方とも高速になります。

于 2009-11-29T16:18:33.623 に答える
3
  • 問題が発生するまで、クエリが効率的であるかどうかを心配する必要はありません。
  • 以下の引用によると、あなたはそれを間違っています

私がマインドスイッチについて行ってきた方法は、データベースを完全に忘れることです。リレーショナルデータベースの世界では、データの正規化とテーブル構造について常に心配する必要があります。それをすべて捨てなさい。Webページをレイアウトするだけです。それらをすべて配置します。今それらを見てください。すでに2/3あります。データベースのサイズが重要であり、データが3/4よりも複製されるべきではないという概念を忘れた場合は、コードを記述する必要さえありません。あなたの見解があなたのモデルを決定するようにしましょう。リレーショナルの世界のように、オブジェクトを取得して2次元にする必要はありません。これで、形状のあるオブジェクトを保存できます。

データベースの代わりにデータストアで考える方法

于 2010-01-09T02:44:27.660 に答える
2

さて、SQLセットアップで行うように、正規化されたデータモデルを指定しました。

私の理解では、MongoDBではこれを行いません。参照を保存することはできますが、一般的な場合はパフォーマンス上の理由から保存しません。

私はNoSQL分野の専門家ではありませんが、単にあなたのニーズに従い、ストーリーコレクションにストーリーに投票したユーザー（ID）とユーザーが持っているストーリー（ID）を保存してみませんか？ユーザーコレクションに投票しましたか？

于 2009-11-29T16:13:44.370 に答える
1

CouchDBでは、これは非常に簡単です。1つのビューが発行します：

function(doc) {
 if(doc.type == "vote") {
   emit(doc.story_id, doc.user_id);
 }
}

別のビューが発行します：

function(doc) {
 if(doc.type == "vote") {
   emit(doc.user_id, doc.story_id);
 }
}

結合がないため、どちらも非常に高速なクエリです。ユーザーデータまたはストーリーデータが必要な場合、CouchDBはマルチドキュメントフェッチをサポートします。また、非常に高速で、「参加」を行う1つの方法です。

于 2009-11-29T17:50:12.903 に答える
0

最近、MongoDB と CouchDB をよく調べていますが、私の洞察は限られています。それでも、ストーリー ドキュメント内に投票を保存することを考えると、4 MB のドキュメント サイズ制限に達することを心配する必要があるかもしれません。そうしない場合でも、ドキュメントのサイズを常に大きくして移動させ、書き込みを遅くしている可能性があります (MongoDB でのドキュメントのサイズを参照してください)。

CouchDB に関して言えば、ビュー インデックスが計算されると、これらの種類の処理は非常にシンプルで洗練され、非常に高速になります。ただし、個人的には、CouchDB で同様のプロジェクトを実行することをためらっています。これは、データベースが大きくなる (およびビュー インデックスが大きくなる) につれて、かなりの程度まで速度が徐々に低下することをベンチマークが示しているためです。データベースのサイズが大きくなったときの CouchDB のパフォーマンスを示す最近のベンチマークをいくつか見てみたいと思います。MongoDB や CouchDB を試してみたいと思っていますが、SQL は依然として非常に効率的で論理的であるように思われるので、プロジェクトがその誘惑にうまく適合するまで、SQL を使い続けます。

于 2011-07-08T18:45:58.117 に答える