ソーシャルアクティビティストリームを実装する最良の方法は何ですか？[閉まっている]

ソーシャルアクティビティストリームを実装する最良の方法はどれですか（Facebookが最も有名な例です）。関連する問題/課題は次のとおりです。

• さまざまな種類のアクティビティ（投稿、コメントなど）
• さまざまな種類のオブジェクト（投稿、コメント、写真など）
• さまざまな役割に関与する1-nユーザー（「ユーザーxはユーザーZの投稿に対するユーザーyのコメントに返信しました」）
• 同じアクティビティアイテムのさまざまなビュー（「あなたがコメントした..」vs.「あなたの友人xがコメントした」vs.「ユーザーxがコメントした..」=>「コメント」アクティビティの3つの表現）

..その他、特にFacebookのように高度なレベルに進んだ場合、たとえば、複数のアクティビティ項目を1つに結合する（「ユーザーx、y、zがその写真にコメントした」）

そのようなシステム、データモデルなどを実装するための最も柔軟で効率的で強力なアプローチについてのパターンや論文などについての考えや指針は、高く評価されます。

ほとんどの問題はプラットフォームに依存しませんが、Ruby on Railsでこのようなシステムを実装する可能性があります

私はそのようなシステムを作成し、私はこのアプローチをとりました：

次の列を持つデータベーステーブル：id、userId、type、data、time。

• userIdは、アクティビティを生成したユーザーです
• typeはアクティビティのタイプです（つまり、ブログの投稿、写真の追加、ユーザーの写真へのコメント）
• データは、アクティビティのメタデータを含むシリアル化されたオブジェクトであり、好きなように配置できます

これは検索/ルックアップを制限します。フィード、ユーザー、時間、アクティビティタイプで実行できますが、Facebookタイプのアクティビティフィードでは、これは実際には制限されません。そして、テーブルのインデックスが正しい場合、検索は高速です。

この設計では、各タイプのイベントに必要なメタデータを決定する必要があります。たとえば、新しい写真のフィードアクティビティは次のようになります。

{id:1, userId:1, type:PHOTO, time:2008-10-15 12:00:00, data:{photoId:2089, photoName:A trip to the beach}}

ご覧のとおり、写真の名前は写真が含まれている他のテーブルに確実に保存されていますが、そこから名前を取得できますが、メタデータフィールドに名前を複製します。速度が必要な場合は、他のデータベーステーブルの結合。また、50人の異なるユーザーからの200個の異なるイベントを表示するには、速度が必要です。

次に、さまざまなタイプのアクティビティエントリをレンダリングするための基本的なFeedActivityクラスを拡張するクラスがあります。イベントのグループ化は、データベースからの複雑さを避けるために、レンダリングコードにも組み込まれます。

これは、Etsy.comがアクティビティストリームをどのように構築したかを概説する非常に優れたプレゼンテーションです。これは、このトピックで見つけた最良の例ですが、レール固有ではありません。

http://www.slideshare.net/danmckinley/etsy-activity-feeds-architecture

私たちはアプローチをオープンソース化しました：https : //github.com/tschellenbach/Stream-Framework これは現在、この問題の解決を目的とした最大のオープンソースライブラリです。

Stream Frameworkを構築した同じチームは、複雑さを処理するホストされたAPIも提供します。見てgetstream.ioノード、パイソン、RailsとPHPで利用可能なクライアントがあります。

さらに、この高いスケーラビリティに関する投稿を見て、関連する設計上の決定のいくつかを説明します。http： //highscalability.com/blog/2013/10/28/design-decisions-for-scaling-your-high-traffic- feeds.html

このチュートリアルは、PinterestのフィードのようなシステムをRedisを使用して設定するのに役立ちます。始めるのはとても簡単です。

フィードのデザインについて詳しく知るために、Feedlyのベースとなっている記事を読むことを強くお勧めします。

• Yahooリサーチペーパー
• Twitter 2013 Redisベース、フォールバックあり
• InstagramのCassandra
• Etsyフィードのスケーリング
• Facebookの歴史
• Djangoプロジェクト、適切な命名規則。（しかし、データベースのみ）
• http://activitystrea.ms/specs/atom/1.0/（俳優、動詞、オブジェクト、ターゲット）
• ベストプラクティスに関するQuoraの投稿
• ソーシャルネットワークフィードのQuoraスケーリング
• Redisルビーの例
• FriendFeedのアプローチ
• Thoonkのセットアップ
• Twitterのアプローチ

Stream FrameworkはPythonベースですが、Rubyアプリから使用するのはそれほど難しくありません。単にサービスとして実行し、小さなhttp APIをその前に置くことができます。他の言語からFeedlyにアクセスするためのAPIの追加を検討しています。現時点では、自分の役割を担う必要があります。

イベントストリームの最大の問題は、可視性とパフォーマンスです。表示されるイベントを、その特定のユーザーにとって興味深いイベントだけに制限する必要があり、それらのイベントを整理して特定するのにかかる時間を管理しやすくする必要があります。小さめのソーシャルネットワークを構築しました。小規模では、データベースに「イベント」テーブルを保持することは機能しますが、中程度の負荷ではパフォーマンスの問題になることがわかりました。

メッセージとユーザーのストリームが大きい場合、イベントがメッセージとして個々のプロファイルに送信されるメッセージングシステムを使用するのがおそらく最善です。つまり、ユーザーのイベントストリームを簡単にサブスクライブして以前のイベントを簡単に確認することはできませんが、特定のユーザーに対してストリームをレンダリングする必要がある場合は、メッセージの小さなグループをレンダリングするだけです。

これはTwitterの元々の設計上の欠陥だったと思います-彼らがデータベースにアクセスしてイベントを取得し、フィルタリングしていたことを読んだことを覚えています。これはアーキテクチャーとすべて関係があり、Railsとは関係がありませんでした。（残念ながら）「ルビーはスケーリングしない」ミームを生み出しました。私は最近、開発者がAmazonのSimple Queue ServiceをTwitterのようなアプリケーションのメッセージングバックエンドとして使用し、はるかに高いスケーリング機能を備えたプレゼンテーションを見ました-負荷が十分に高い場合、システムの一部としてSQSを調べる価値があるかもしれません。

別のソフトウェアを使用する場合は、アクティビティストリーム（neo4jグラフデータベースの上に構築）の問題を正確に解決するGraphityサーバーをお勧めします。

独自のサーバーをホストしてアクティビティストリームを配信できるように、アルゴリズムはスタンドアロンRESTサーバーとして実装されています。http：//www.rene-pickhardt.de/graphity-server-for-social-activity-streams-released-gplv3 /

論文とベンチマークで、ニュースストリームの取得は、データの非正規化から得られる冗長性なしに、取得するアイテムの量にのみ線形に依存することを示しました。

http://www.rene-pickhardt.de/graphity-an-efficient-graph-model-for-retrieving-the-top-k-news-feeds-for-users-in-social-networks/

上記のリンクには、スクリーンキャストとこのアプローチのベンチマークがあります（graphityは1秒あたり10kを超えるストリームを取得できることを示しています）。

私は昨日このようなシステムを実装し始めました、ここで私がしなければならないところです...

プロパティId、ActorId、TypeId、Date、ObjectIdと追加の詳細キー/値ペアのハッシュテーブルを使用してStreamEventクラスを作成しました。これは、データベースではStreamEventテーブル（Id、ActorId、TypeId、Date、ObjectId）およびStreamEventDetailsテーブル（StreamEventId、DetailKey、DetailValue）によって表されます。

アクターID、型IDとのObjectIdは、件名、動詞オブジェクトイベントがキャプチャ（およびそれ以降の照会）することを可能にします。各アクションにより、複数のStreamEventインスタンスが作成される場合があります。

次に、EventEventの各タイプのイベント（LoginEvent、PictureCommentEventなど）のサブクラスを作成しました。これらの各サブクラスには、PictureId、ThumbNail、CommenTextなどのよりイベント固有のプロパティ（イベントに必要なもの）があり、実際にはハッシュテーブル/ StreamEventDetailテーブルにキー/値のペアとして格納されます。

これらのイベントをデータベースからプルバックするとき、ファクトリーメソッド（TypeIdに基づく）を使用して正しいStreamEventクラスを作成します。

StreamEventの各サブクラスには、渡されたStreamContextクラスに基づいてイベントを画面に出力するRender（context As StreamContext）メソッドがあります。StreamContextクラスを使用すると、ビューのコンテキストに基づいてオプションを設定できます。たとえば、Facebookを見ると、ホームページのニュースフィードには各アクションに関与する全員のフルネーム（およびそのプロフィールへのリンク）が表示されますが、友達のフィードを見ると、ファーストネームしか表示されません（他の俳優のフルネームは表示されます）。 。

私はまだ集約フィード（Facebookホーム）を実装していませんが、ある種の「Hmmmに基づいて入力されるフィールドUserId、StreamEventIdを持つAggregateFeedテーブルを作成すると思います。この興味深いアルゴリズムが見つかるかもしれません。

コメントをいただければ幸いです。

//実際のイベントごとに1つのエントリ
イベント{
  ID、タイムスタンプ、タイプ、データ
}

//イベントごとに、そのイベントを含むフィードごとに1つのエントリ
events_feeds {
  event_id、feed_id
}

イベントが作成されたら、表示するフィードを決定し、それらをevents_feedsに追加します。フィードを取得するには、events_feedsから選択し、イベントに参加し、タイムスタンプ順に並べます。次に、そのクエリの結果に対してフィルタリングと集計を実行できます。このモデルでは、追加の作業なしで、作成後にイベントプロパティを変更できます。

Railsに実装することに決めた場合、おそらく次のプラグインが役立つでしょう。

ActivityStreams：http : //github.com/face/activity_streams/tree/master

他に何もない場合は、データモデルと、プッシュおよびプルアクティビティ用に提供されるAPIの両方の観点から、実装を確認できます。

私はheymanのアプローチと同様のアプローチをとりました-特定のアクティビティストリームに表示されるすべてのデータを含む非正規化テーブル。活動が限られている小さなサイトでは問題なく機能します。

上記のように、サイトの拡大に​​伴い、スケーラビリティの問題に直面する可能性があります。個人的には、今のところスケーリングの問題は心配していません。後で心配します。

Facebookはスケーリングの優れた仕事をしているので、すばらしいコンテンツがたくさんあるので、エンジニアリングブログを読むことをお勧めします-> http://www.facebook.com/notes.php?id=9445547199

私は、上で述べた非正規化されたテーブルよりも優れたソリューションを検討してきました。これを達成するために私が見つけた別の方法は、特定のアクティビティストリームに含まれるすべてのコンテンツを単一の行に圧縮することです。アプリケーションで読み取ることができるXML、JSON、またはシリアル化された形式で保存できます。更新プロセスも簡単です。アクティビティが発生したら、新しいアクティビティをキューに入れ（おそらくAmazon SQSまたは他の何かを使用）、次にキューをポーリングして次のアイテムを探します。そのアイテムを取得して解析し、データベースに保存されている適切なフィードオブジェクトにそのコンテンツを配置します。

この方法の良い点は、一連のテーブルを取得するのではなく、特定のフィードが要求されたときに単一のデータベーステーブルを読み取るだけでよいことです。また、リストを更新するたびに最も古いアクティビティアイテムをポップアウトできるため、アクティビティの有限リストを維持できます。

お役に立てれば！:)

このようなアクティビティストリームについては、2つのレールキャストがあります。

• http://railscasts.com/episodes/406-public-activity（gem public_activityを含むアクティビティフィード）
• http://railscasts.com/episodes/407-activity-feed-from-scratch（最初から同じ）

これらのソリューションにはすべての要件が含まれているわけではありませんが、いくつかのアイデアが得られるはずです。

Plurkのアプローチは興味深いと思います。タイムライン全体を、Google Financeの株価チャートによく似た形式で提供します。

ソーシャルネットワーキングネットワークがどのように機能するかを確認するには、Ningを検討する価値があります。開発者のページには、特に便利に見えます。

私はこれを数か月前に解決しましたが、私の実装はあまりにも基本的だと思います。
次のモデルを作成しました。

HISTORY_TYPE

ID           - The id of the history type
NAME         - The name (type of the history)
DESCRIPTION  - A description

HISTORY_MESSAGES

ID
HISTORY_TYPE - A message of history belongs to a history type
MESSAGE      - The message to print, I put variables to be replaced by the actual values

HISTORY_ACTIVITY

ID
MESSAGE_ID    - The message ID to use
VALUES        - The data to use

例

MESSAGE_ID_1 => "User %{user} created a new entry"
ACTIVITY_ID_1 => MESSAGE_ID = 1, VALUES = {user: "Rodrigo"}

アクティビティストリームを実装してソーシャルフィード、マイクロブログ、およびコラボレーション機能をいくつかのアプリケーションで有効にした後、基本機能はかなり一般的であり、APIを介して利用する外部サービスに変換できることに気付きました。ストリームを本番アプリケーションに構築していて、固有または複雑なニーズがない場合は、実績のあるサービスを利用するのが最善の方法です。リレーショナルデータベースの上に独自のシンプルなソリューションを展開するよりも、本番アプリケーションにこれをお勧めします。

私の会社のCollabinate（http://www.collabinate.com）はこの実現から成長し、それを実現するために、グラフデータベースの上にスケーラブルで高性能なアクティビティストリームエンジンを実装しました。実際にエンジンを構築するために、Graphityアルゴリズムの変形（@RenePickhardtの初期の作業から適応したもの）を実際に使用してエンジンを構築しました。

エンジンを自分でホストする場合、または特殊な機能が必要な場合、コアコードは実際には非営利目的のオープンソースであるため、ぜひご覧ください。