NoSQL / MongoDbおよびデータ/モデル構造に関するアドバイスが必要です

Question

最近、NoSQLデータベースを調査しています。特定の問題に対して最も最適で効率的な方法でデータを保存する方法に関するアドバイスが必要です。現在、MongoDBをターゲットにしています。ただし、CouchDBと同じでなければなりません。

次の3つのモデルがあるとします：

Story:
 id
 title

User:
 id
 name

Vote:
  id
  story_id
  user_id

これらの質問をデータベースに問い合わせることができます。

• このストーリーに投票したのは誰ですか
• このユーザーが投票したもの

リレーショナルDBでの作業中に単純な結合を行っています。問題は、最も効率的にするために、これらのオブジェクトのデータをどのように保存すればよいかです。

たとえば、投票オブジェクトをStoriesのサブコレクションとして保存すると、「ユーザーが投票したもの」という情報を簡単に取得できません。

Answer 1

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

db.users.find（{stories：story_id}）

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

Answer 2

• 重要になるまでクエリが効率的かどうか心配しないでください
• 以下の引用によると、あなたは間違っています

  

私が行ってきた方法   心のスイッチは忘れることです   データベース全体。の中に   リレーショナルデータベースの世界では、常にする必要があります   データの正規化を心配し、   テーブル構造。それをすべて捨てる。   Webページをレイアウトするだけです。それらを置きます   全く。今それらを見てください。きみの   すでに2/3あります。忘れたら   データベースのサイズが重要であるという概念と   データはあなたよりも複製されるべきではありません   そこに3/4、あなたもする必要はありません   コードを書く！あなたの意見を決めましょう   あなたのモデル。取る必要はありません   あなたのオブジェクトとそれらを作ります2   のようにもう次元   リレーショナルの世界。収納できます   シェイプ付きのオブジェクト。

how-to-think-in-data-stores -instead-of-databases

Answer 3

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

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

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

Answer 4

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つの方法です。

Answer 5

最近MongoDBとCouchDBをよく調べていますが、私の洞察は限られています。それでも、ストーリードキュメント内に投票を保存することを検討する場合、4MBのドキュメントサイズ制限に達することを心配する必要があります。そうしなくても、ドキュメントのサイズを絶えず増加させて移動させるため、書き込み速度が低下する可能性があります（MongoDBでのドキュメントのサイズ設定方法を参照）。

CouchDBに関しては、これらの種類のものは非常にシンプルでエレガントで、ビューインデックスが計算されると非常に高速です。ただし、個人的には、データベースが大きくなる（およびビューインデックスが大きくなる）につれて、かなりの程度まで速度が徐々に低下することが示されているため、CouchDBで同様のプロジェクトを行うことをためらっています。データベースサイズが大きくなるにつれて、CouchDBのパフォーマンスを示す最新のベンチマークをいくつか見たいと思います。 MongoDBまたはCouchDBを試してみたいのですが、SQLはまだ非常に効率的で論理的なようですので、プロジェクトがちょうどその誘惑に合うまで、SQLを使い続けます。