1

私は Facebook のようなソーシャル ネットワーキング サイトを開発しています。通知テーブルの構造を作成する方法がわかりません。ユーザーごとに個別にする必要がありますか、それとも頻繁に追加および削除されるすべてのレコードに対して巨大なものにする必要がありますか?

4

1 に答える 1

2

私はあなたと同じ問題を抱えており、与えられたテーブル構造がどこにあるかを調査したところ、これを見つけました（これを見つけました） ：

id             
user_id       (int)
activity_type (tinyint)
source_id     (int)  
parent_id     (int)
parent_type   (tinyint)
time          (datetime but a smaller type like int would be better)

どこ：

activity_typeはアクティビティのタイプを示し、source_idはアクティビティが関連するレコードを示します。したがって、アクティビティ タイプが「追加されたお気に入り」を意味する場合、source_idがお気に入りレコードの ID を参照していることがわかります。

parent_id/parent_typeは私のアプリに役立ちます。アクティビティが何に関連しているかを教えてくれます。本がお気に入りに登録されている場合、parent_id/parent_type は、アクティビティが特定の主キー (id) を持つ本 (タイプ) に関連していることを教えてくれます。

(user_id, time)にインデックスを付け、user_id IN (...friends...) AND time > some-cutoff-point であるアクティビティをクエリします。ID を捨てて別のクラスター化インデックスを選択するのは良い考えかもしれません - 私はそれを試していません。

かなり基本的なものですが、機能し、シンプルで、ニーズの変化に合わせて簡単に操作できます. また、MySQL を使用していない場合は、より適切にインデックスを作成できる可能性があります。

また、最新のアクティビティにすばやくアクセスするためにRedisを使用することも提案されています。Redis を組み合わせると、次のように動作する可能性があります。

  • MySQL アクティビティ レコードを作成する
  • アクティビティを作成したユーザーのフレンドごとに、ID を Redis のアクティビティ リストにプッシュします。
  • 各リストを最後の X 項目にトリムする

Redis は高速で、1 つの接続でコマンドをパイプライン処理する方法を提供します。そのため、アクティビティを 1000 人の友人にプッシュするのに数ミリ秒かかります。

私が話していることのより詳細な説明については、Redis の Twitter の例を参照してください: http://code.google.com/p/redis/wiki/TwitterAlikeExample

これがあなたにも役立つことを願っています

于 2013-08-20T09:38:21.337 に答える