1

リレーショナル用語で考えることに慣れた私は、「noSQLのやり方」で考えることを理解しようとしています。

次のシナリオを想定します。

多くの投稿と登録ユーザーがいるブログ（例：9gag.com）があります。すべての投稿は、各ユーザーが高く評価することができます。レコメンデーションエンジンを構築したいので、以下を追跡する必要があります。

  • ユーザーが閲覧したすべての投稿
  • ユーザーが高く評価したすべての投稿

投稿には、タイトル、本文、カテゴリがあります。ユーザーには、ユーザー名、パスワード、電子メール、その他のデータがあります。

リレーショナルDBには、、、、、のようなものがpostsありusersます。posts_users_views (post_id, users_id, view_date)posts_users_likes (post_id, user_id, like_date)

質問

ドキュメント/列指向のnoSQLデータベースの「正しい」構造とは何ですか？

明確化：ユーザー内のすべての表示/高評価の投稿ID（または投稿内のユーザーID）の配列を保存する必要がありますか？もしそうなら、行サイズが大きくなるという問題はありませんか？

4

1 に答える 1

0

CouchDB では、ユーザー、投稿、表示などに個別のドキュメントを作成できます。ユーザーごとのビュー/いいね! の表示は、配列キーを発行する map 関数を使用した「ビュー」(マテリアライズド マップ/リデュース クエリ) によって配置できます[user_id, post_id]。その結果、ソートされた辞書 (キーによって辞書順に並べられたもの) が得られるため、すべてのビューを取得すると、user='ID'から[ID]までのキーを持つクエリになります[ID,{}]。最適化することはできますが、基本的な解決策は非常に単純です。

CouchDB wikiには、リレーショナルにモデル化された設計とビューの照合メカニズム (いくつかの単純な結合を置き換えることができます)の使用に関するコメントがあります。直感をつかむために、投稿とコメントの問題を研究することをお勧めします。これも非常に単純ですが、ビューやいいねのように些細なことではありません:)

NoSQL の方法はないかもしれませんが、ほとんどの map/reduce システムは同様の考え方を共有していると思います。CouchDB は非常に限られているため、開始するのに適したツールです:) 分散環境で非効率的なクエリを実行することは困難であり、その map および reduce クエリ関数には副作用がありません (ドキュメントセットが変更され、結果がドキュメントの更新の順序に依存してはなりません)。

于 2013-01-07T10:22:15.860 に答える