1

Superfeedr は、フィード解析オンデマンド サービスです。ユーザーに分析を提供したいと考えており、そのための最善の戦略を調査しています。

簡単に言えば、システム内の操作 (特定のフィードへの新規エントリなどのイベント) の数と、集計データ (フィードのサブスクライバーの数) を追跡したいと考えています。

もちろん、集約されたデータは、イベントに基づいて「計算」できます。(フィードの購読者数は、購読の合計から購読解除の合計を引いたものです)。しかし、時間の経過とともに (毎日のサブスクライバーの数) を調査したいので、同じことを何度も再計算するため、イベント化されたアプローチは最適ではない可能性があります。

アプリでそのようなコンポーネントをどのように構築しますか? どんな情報の流れ？何のデータストア？どのグラフ作成ソリューションですか? 等...

これが未解決の問題であることは承知していますが、そのような必要性を持ったのは私たちだけではありません!

[更新]: インフラストラクチャ: XMPP クライアントであり、すべて一緒に対話する一連のワーカーがあります。これらは EventMachine に基づいているため、IO でブロックされません。望ましい目標 : 大量のデータを収集できる必要があります。現在、すでに約 200 ～ 300 メッセージ/秒であり、その 10 倍から 100 倍を目指しています。

4

1 に答える 1

2

インフラストラクチャと必要なスケーリングターゲットに関する詳細情報がないと言うのは難しいです。TwitterがHadoopをどのように使用して教育を行うかについてのこのスライドデッキを見つけることができます。これは、最近のNoSQLEastカンファレンスでKevinWeilによって発表されました。

代替テキスト

Twitterが行っていることからアイデアを借りると、アーキテクチャを収集、分析、レンダリングの各フェーズに分割することを検討できます。

収集フェーズ：超低遅延。非常にスケーラブル。拘束力のある選択肢がたくさん。Facebookで開発されました。

ノードログイベントの処理->スクライブ->HDFS

分析フェーズ：探索的なアドホッククエリも実行できるSQLのようなクエリ言語。

HDFS-> Pig- > MySQL

レンダリングフェーズ：現在のWebフレームワークに実装されています

MySQL-> JSON-> Memcached-> Flash Charting

ワールドワイドウェブ用のフラッシュチャートコンポーネントの選択に関して、SOに関するいくつかの投稿がここにあります。私は個人的にAmChartsで良い成功を収めています。

于 2009-11-22T12:48:43.110 に答える