Facebookのような複雑な壁のためのDBを設計する方法

Question

私はFacebookのようなソーシャルネットワークのウェブサイトを作成しています。 私の「壁」には、ステータス、メッセージ、ユーザーがページを好き嫌いするなど、さまざまな種類の情報があります。

DBの設計方法を知っています壁関連のテーブルを取得するときにできるだけ効率的に（速度に関して）効率的になるようにします。

ありがとうございます！

EDITは：

1. は、あらゆる可能性を処理するのに十分なカラムを持つ大きなテーブルを持っている（USER_A、USER_A、メッセージ、ページ、is_like、is_dislike、...）：私は2つのアイデアを持っています。これは高速ですが、多くの 'NULL'値を持ち、DBに多くのスペースをとります。
2. 壁アイテムの種類ごとに3つの列（id、user_a、user_b）とテーブルを持つ 'wall_item'メッセージ、好きなもの、ステータスなど）。これは正規化されますが、すべての情報を取得するために必要な左結合の数のためにはるかに時間がかかるでしょう。

Answer 1

私は、2つのテーブルがあることを提案します.1つはコンテンツ用、もう1つは好き嫌い用です。多くのヌル値を持つことは問題ではありません - ヌルはスペースを取らないでしょう。好き嫌いを別々に保つことはおそらく必要になるでしょう。なぜなら、彼らは多くのことが起こり、自分自身に満足していないからです。

システムをスケーラブルにしたい場合は、JOIN-sを避けてください。多くのJOIN-sを使用する1つの大規模な大量クエリよりも、2〜3回のクエリを連続して実行する方が良いです。また、多くのWRITE（数やREADと比較して）ではなく、多くのREAD操作がある場合は、WRITE中に追加の操作を行うのが賢明です。

たとえば、壁（ユーザーIDと投稿IDを含む）用に別のテーブルを作成することができます。誰かが新しい投稿をすると、投稿のIDが各友達のテーブルWALLに書き込まれます。だから、壁を表示することは、表示中にすべてのユーザーの投稿からコンテンツを検索するのではなく、テーブルWALLからポストIDを読み取ってコンテンツをプルすることです。

新しい人が友人になれば、最近の投稿のID-sをお互いの壁にコピーするだけです。プロジェクトに幸運を祈る！

Answer 2

私は、パフォーマンスを得るためにNOSQLが使用されていると思います。大規模なテーブルのdbアクセスは、結合されたテーブルだけでなく、この種のアプリケーションでは遅くなります。