1

アプリの簡単なアクティビティストリームを作成中です。

現在のテクノロジーレイヤーとロジックは次のとおりです。

**アクティビティに関連するすべてのデータはMYSQLに保存され、すべてのアクティビティIDの配列はすべてのユーザーのRedisに保持されます。**

  1. ユーザーがアクションを実行すると、アクティビティはMYSQLの「activities」テーブルに直接保存され、一意の「activity_id」が返されます。
  2. このユーザーの「フォロワー」の配列がデータベースから取得され、フォロワーごとに、この新しいactivity_idをRedisのリストにプッシュします。

ユーザーがストリームを表示すると、ユーザーIDに基づいてredisからアクティビティIDの配列を取得します。次に、単純なMYSQLWHERE IN($ids)クエリを実行して、これらすべてのアクティビティIDの実際のアクティビティデータを取得します。

クエリは常に非常に単純なINクエリであるため、この種の設定は非常にスケーラブルであると私は信じています。ただし、いくつかの問題があります。

  1. Removing a Follower-ユーザーが誰かのフォローをやめた場合、そのユーザーに対応するすべてのactivity_idをRedisリストから削除する必要があります。これには、Redisリスト内のすべてのIDをループして、削除されたユーザーに対応するIDを削除する必要があります。これは私を非常に不誠実だと思いますが、これを管理するためのより良い方法はありますか？
  2. 'archiving'-Redisリストを最大で1000のactivity_idの長さに保ち、MYSQLアクティビティテーブルから古いデータを頻繁に削除して、管理できないサイズに拡大しないようにします。明らかに、これは、新しいIDを追加するときにユーザーストリームリストから古いIDを削除することで実現できます。ただし、ユーザーが選択した場合に非常に古いアクティビティデータを表示できるように、このデータをアーカイブする方法がわかりません。これを行うための最良の方法は何でしょうか？それとも、この制限を完全に適用して、ユーザーが非常に古いアクティビティデータを表示できないようにする方がよいでしょうか。

要約すると、私が本当に知りたいのは、私の現在のセットアップ/ロジックが良い/悪いアイデアであるかどうかです。完全に再考する必要がありますか？もしそうなら、あなたの推奨モデルは何ですか？すべてが大丈夫だと感じたら、上記の2つの問題にどのように対処すればよいですか？この質問は非常に幅広く、すべての回答は意見に基づいていると思いますが、まさにそれが私が探しているものです。よく形成された意見。

よろしくお願いします。

4

1 に答える 1

1

1の実行はそれほど難しくないようです（ループなし）：

delete Redis from Redis
 join activities on Redis.activity_id = activities.id
                and activities.user_id = 2 
                and Redis.user_id = 1
;

2アーカイブについてはよくわかりません。期間ごとにアーカイブテーブルを作成し、古いアクティビティをメインテーブルからアーカイブテーブルに定期的に移動できます。ただし、適切に正規化された単一のアクティビティテーブルはかなり大きくなるはずです。（「大きな」アクティビティでは、アクティビティデータが別のテーブルに格納されていることを確認してください。メインのアクティビティテーブルは、多くのエントリがあると予想されるため、「狭い」必要があります）

于 2013-01-02T15:12:43.247 に答える