私が働く会社は、Blackberryプラットフォームのアプリケーションを作成します。スケーラブルなヒット/アナリティクスシステムを設計する最良の方法は？
私たちは、アプリケーション内にコードを埋め込み、実行するたびにいくつかの統計情報を中央サーバに返送することを可能にする独自の「分析システム」に取り組んできました。現在、システムは正常に動作します。しかし、それはベータ版では1時間当たり100〜200ヒットしかありません。 「ヒット」は問題なくサーバーに送信されます。ヒットの受け入れと格納を処理するための非常に堅実なAPI（MySQL DB内）を構築しました。私たちは負荷をテストしました。問題なく時間当たり数十万ヒットに対応できるはずです。それは本当に問題ではありません。
問題は統計情報を示しています。 Mint（haveamint.com）に似たディスプレイパネルを作りました。毎時間、過去の日、月、週、年などのヒット数を表示します。最初のバージョンでは、ヒットテーブルからデータを取り出して即座に解釈するストレートクエリが実行されました。それは非常に長く働かなかった。私たちの現在の解決策は、ヒットが処理のために「キューに入れられる」ということです。そして、5分ごとにヒットを取得し、時間、日、週、月、年などの「キャッシュ」に分類します。これは驚くべきことですが、信じられないほどスケーラブルです。ただし、1つのタイムゾーンでのみ動作します。全社でこれにアクセスできるため、さまざまなタイムゾーンで数百人のユーザーを扱っています。私がサンノゼで「今日」と定義しているのは、ロンドンの私の同僚が今日と定義しているものとはまったく異なります。現在のソリューションは1つのタイムゾーンにしかキャッシュされないため、タイムゾーン以外のデータをチェックしている人にとっては悪夢です。
これを修正する現在の計画は、すべてのタイムゾーン（合計40個）のキャッシュを作成することです。しかし、それはデータの量に40を乗じていることを意味します...私にとっては恐ろしいことですが、キャッシュが非常に大きくなる可能性があることを考えると、さらに、キューを処理するときには、40個の異なるキャッシュに入れるのにもっと多くのCPU時間がかかるでしょう。
他にもこの問題を解決する方法がありますか？複数のタイムゾーンに触れたソフトウェアを設計するとき
は（そのような長いquestion..itのため申し訳ありませんが、説明するのは、正確には容易ではありません。おかげですべての！）
具体的な質問は、実際には非常によく似たものを設計しており、ここに入力する予定です。 +1 –
ヒットハンドリング/ストアAPIを見るのは非常に面白いでしょう:) – Jacco