0

Twitter ストリーミング API とPhirehose PHP のドキュメントをすべて読んだ後、データを個別に収集して処理するという、まだ行っていない作業に出くわしました。

その背後にあるロジックは、私の理解が正しければ、収集プロセスをバックアップする処理フェーズでログ ジャムを防止することです。以前に例を見たことがありますが、基本的にコレクションの直後にMySQLデータベースに直接書き込みますが、これはTwitterが推奨していることに反しているようです.

アドバイス/ヘルプが欲しいのは、これを処理する最善の方法と方法です。すべてのデータをテキスト ファイルに直接書き込んでから、別の関数で解析/処理することをお勧めしているようです。しかし、この方法では、メモリを大量に消費する可能性があると思います。

ここにキャッチがあります。すべてがデーモン/バックグラウンド プロセスとして実行されます。では、このような問題、またはより具体的には twitter phirehose ライブラリを解決した経験のある人はいますか? ありがとう!

いくつかのメモ: *接続はソケットを介して行われるため、ファイルは常に追加されると思いますか? 誰かがそれについてフィードバックを持っているかどうかわからない

4

1 に答える 1

1

phirehose ライブラリには、これを行う方法の例が付属しています。見る:

これは非常にスケーラブルで高速なフラット ファイルを使用します。つまり、平均的なハードディスクは 40MB/s+ で順次書き込みができ、線形にスケーリングします (つまり、データベースとは異なり、大きくなっても速度が低下しません)。

ストリームを消費するためにデータベース機能は必要ありません (つまり、次のツイートが必要なだけで、「クエリ」は必要ありません)。

ファイルをかなり頻繁にローテーションすると、ほぼリアルタイムのパフォーマンスが得られます (必要な場合)。

于 2012-05-17T23:32:57.283 に答える