大規模なプロジェクトに着手しようとしています。このプロジェクトでは、エンティティのデータベース全体をループし、Facebook、Twitter、Foursquareなどの複数のAPIを10分ごとに呼び出すスクリプトを実行するためのスケジュールされたタスク（cronジョブ）が必要です。 。このアプリケーションはスケーラブルである必要があります。
最善のオプションは、分散データベースを利用するようにアプリケーションを設計し、それを複数のサーバーにデプロイすることです。
map-reduceアプローチとは異なり、2つの「ランク」のサーバーで動作するように設計できます。クエリを実行して一部のデータを「事前ダイジェスト」する軽量サーバー（「マップ」）と、データを集約するサーバー（「減らす"）。
これを行うと、パフォーマンスベースラインを確立して計算できます。たとえば、1分あたり2000クエリを生成でき、同じ数の応答を処理できる場合は、20,000ユーザーごとに新しいサーバーが必要になります。その「1分あたり2000クエリを生成する」では、次のことを考慮する必要があります。
- データベースからのデータ取得
- 制御サーバーとの間のトラフィック帯域幅
- Facebook、Foursquare、Twitterなどへのトラフィック帯域幅。
- ローカルでログを記録する必要性（そして、ログダイジェストを抽出してコマンドアンドコントロールにアップロードする可能性があります）
このアーキテクチャの利点は、小規模から始めることができることです。テストベッドは、コネクタ、マッパー、レデューサー、コマンドアンドコントロール、および永続性の両方を実行する単一のマシンで構築できます。成長すると、さまざまなサービスをさまざまなサーバーにアウトソーシングするだけです。
いくつかの分散コンピューティングプラットフォームでは、これにより、地理的または接続性の観点からマッパーを慎重に割り当てることでクエリをより高速に実行でき、Amazonの「ゾーン」などで遊んでさまざまなプラットフォーム間のトラフィックコストを削減できます（Amazonにはメッセージサービスもあります。タスク間のコミュニケーションに役立つかもしれません）
注：PHPがこのすべてに適したツールであるかどうかはわかりません。私はむしろPythonだと思います。
ただし、インスタンスあたり20,000ユーザーのトラフィックレベルでは、FacebookやFoursquareなどの人たちと一緒にこれを取り上げたほうがいいと思います。少なくとも、コネクタスクリプトを独立したタスクとして実行する、各コネクタがそのサービスのユーザーIDに基づいてキューを並べ替える、データの局所性がほとんどないことを活用する、パイプラインを利用してより多くの帯域幅を圧縮するなど、いくつかの戦略を収集することができます。サーバーの負荷が少なくなります。せいぜい、彼らはあなたにバルクAPIまたは異なるプロトコルを指し示すか、1兆ドルであなたを買うかもしれません:-)