ソーシャルネットワーク向けのカサンドラデータモデリング

Question

ソーシャルネットワーク用にDatastax Cassandraを使用しており、私たちが必要とする設計/データモデリングテーブルは、私たちにとっては紛らわしく、いくつかのテーブルを設計する方法はわかりません。小さな問題！

：我々は、すべてのクエリのために理解されるように

カサンドラでは、posts_by_userあるテーブルを有する、

今は異なるテーブルを持っている必要があり、例えば、ユーザAは、ユーザC及びB以下れます

user_id  | post_id  | text | created_on | deleted | view_count 

likes_count | comments_count | user_full_name 

私たちはユーザーのフォロワーに基づいてテーブルを持っています。user_timelineテーブルに投稿情報を挿入します。フォロワーユーザーが最初のWebページを訪問したときにuser_timelineテーブルからデータベースから投稿を取得します。

そして、ここではuser_timelineテーブルです：

follower_id  |  post_id  | user_id (who posted) | likes_count | 

comments_count | location_name | user_full_name 

まず、このデータモデリングはフォローベース（フォロワー、次のアクション）ソーシャルネットワークのための正しいですか？

そして今、我々はあなたが我々は両方のテーブルの同類の数（user_timeline、posts_by_user）を持って見るように、ポストの同類をカウントし、一人のユーザーを想像したくは1000人の信者は、それぞれのような作用によって、私たちはしていましたuser_timelineのすべての1000行を更新し、posts_by_usersの1行を更新します。これは論理的ではありません！

次に、私の2番目の質問はどのようにすべきかです。私はどのように（好きな）テーブルが好きなのですか？

Answer 1

投稿の情報のメタデータとしてposts_by_userを使用してください。これは、あなたがのuser_idを収容することができるようになる、は、MESSAGE_TEXTなどををpost_idのが、あなたはVIEW_COUNT、likes_count、カウンターテーブルにcomments_countを抽象的だろう。これにより、post_idを持っている限り、投稿のメタデータまたはカウンタのいずれかを取得できますが、counter_recordを一度更新するだけで済みます。

DSEカウンタードキュメント： https://docs.datastax.com/en/cql/3.1/cql/cql_using/use_counter_t.html

しかし、

以下の記事では、カサンドラのためのデータモデリングとの関係で本当に良い出発点です。つまり、この質問に答えるときに考慮すべき点がいくつかありますが、その多くはシステムの内部構造とクエリの構造に依存します。

ルール1： 最初の2つのルールが記載されているように均等にクラスタ

ルール2の周りにデータを分散：「検討する瞬間を撮影パーティション読む

の数を最小限に抑えますuser_timeline "テーブル。複合キーとして

1. のuser_idとCREATED_ONは、* - あなたは、特定のユーザーによって、あなたは、ユーザーのまともな数を持っているという前提で記事を照会したかった

   • 場合、これは理想的です。これにより、 が均等にレコードを配布し、クエリは一度に パーティションに当たることになります。

2. USER_IDと複合キー*としてhash_prefix - あなたは、あなたのデータがあることをできるようになるのポストの数が多い、と少数のユーザーを持っていた

   • 場合、これは理想的ですクラスタ に均等に分散します。しかし、 の複数のパーティションでクエリを実行するリスクがあります。

3. 複合キーとしてfollower_idとCREATED_ON * - あなたが特定のフォロワーが続くポストを照会したかった

   • 場合、これは 理想的です。レコードが分散されるだろうと、あなたはパーティション間で クエリ

これらを最小限にする1台のための3例だった、と私は伝えたかったポイントは、あなたが実行したいクエリの周りにあなたのテーブルを設計することです。また、さまざまなクエリを処理するためにセットアップされた複数のテーブルにデータを複製することを恐れないでください。これはCassandraがモデル化されることになった方法です。以下の記事を読んでDataStax Academyデータモデリングコースを見て、ニュアンスを理解してください。また、私が先に指摘していた基本的なカウンター・スキーマをカバーするために、下のサンプル・スキーマを含めました。

*複合キーの理由は、PRIMARY KEYが一意である必要があるためです。そうでない場合は、既存のPRIMARY KEYを持つINSERTがUPDATEになります。

http://www.datastax.com/dev/blog/basic-rules-of-cassandra-data-modeling https://academy.datastax.com/courses

CREATE TABLE IF NOT EXISTS social_media.posts_by_user (
user_id uuid, 
post_id uuid, 
message_text text, 
created_on timestamp, 
deleted boolean, 
user_full_name text, 
PRIMARY KEY ((user_id, created_on)) 
); 
CREATE TABLE IF NOT EXISTS social_media.user_timeline (
follower_id uuid, 
post_id uuid, 
user_id uuid, 
location_name text, 
user_full_name text, 
created_on timestamp, 
PRIMARY KEY ((user_id, created_on)) 
); 
CREATE TABLE IF NOT EXISTS social_media.post_counts (
likes_count counter, 
view_count counter, 
comments_count counter, 
post_id uuid, 
PRIMARY KEY (post_id) 
);