2

データ モデルの観点から、ユーザー トラッキングのポイントからライブ フィードまでの流れを説明してもらえますか? 私の開発チームはこれに問題を抱えています:

ユーザーがアクティビティを実行すると、すべてのユーザー フットプリントのマスター テーブルである user_activity テーブルにフットプリントが記録されます。これは、追跡する必要があるすべてのユーザーによるすべてのアクションがここに書き込まれることを意味します。

問題:
1) 活動は 1:M です。1枚の写真に10人をタグ付けできるように。したがって、明らかに、このためにアクティビティ テーブルに 10 個の足跡を書きません。したがって、アクティビティの詳細を保存するために別のテーブルが必要ですか?

2) このテーブルは、アクティビティ フィード テーブルにフィードされてアクティビティ フィードに出力されるすべてのオブジェクトのすべてのアクティビティをログに記録しているため、フィードはアクティビティに関係するすべてのオブジェクトを認識する必要があるため、「X のタグが付けられた」と言うことができます。ティムの写真のマーク、ジョン、サラ。」ここで、Mark、John、Sarah は基本的に、それぞれのプロファイルにリンクするユーザー オブジェクトです。写真は、写真テーブルにリンクする写真オブジェクトです...

上記は一例ですが、映画、音楽、ブランド、都市などの多くのオブジェクトがあります。そのため、システムはログ テーブルからアクティビティ フィードまで、どのオブジェクトが何で、どこにあるのかを把握してプルできるようにする必要があります。関連データをフィードに追加します。これを行うには、object_id と object_type_id の 2 つの列があります。ここで、object_type は「ユーザー、写真、ブランドなど」のようなもので、object_id はオブジェクトの ID です。しかし、これを実際のテーブルに接続するにはどうすればよいでしょうか。

3) 最後に、この設計は、追跡されたデータからフィード、つまりログからログ テーブルに移動するための最良の方法ですか。ログ テーブルには詳細テーブルがあり、ログ テーブルはセッション テーブルと結合されます。2 分ごとに、このデータを非正規化されたアクティビティ フィード テーブルにプルする corn ジョブがスケジュールされ、ライブ フィードに直接読み取るために、これらとオブジェクト テーブルからデータをプルします。

  • The 2 min corn job also scares me because if there a lot of records then the system may take longer than 2 min to finish the job and there will be a backlog then. So any other methods i can use?
4

1 に答える 1

1

  1. 10 個のアクションをそれぞれログに記録しますが、同時に発生したアクションを追跡できるように、すべてのアクションに共通の activitybatchid を追加します。

  2. また、処理のために activitybatchid をキュー テーブルに書き込みます。これは、フィード テーブルに項目を追加するために cron ジョブが読み取るものです。activitybatchid を処理した後、それは削除されます。

  3. このような状況では、再帰的な cron ジョブを使用することをお勧めします。これは、一度に 1 行または行のバッチを読み取り、ロックを維持しながら処理し、他のプロセスがこのテーブルを読み取ることができないようにします。パフォーマンスのために、一度に処理される行数をチークできます。また、このプロセスが停止した場合、ロックは一定のアイドル時間後に解放されます。

  4. activitybatchid の処理により、アクティビティ テーブルから関連データが読み取られ、必要なフィードの詳細が作成されます。これは一度行われるため、アプリケーションが記憶する必要はありません。

したがって、基本的には、生データを含むアクティビティ テーブル、フィードに変換されるアクティビティを含むキュー テーブル、表示またはレンダリング用に生成されたフィードを含むフィード テーブルになります。

于 2012-03-01T18:51:58.400 に答える