2

コンバージョン率やその他の興味深いデータを測定するのに役立つ Web サイトの統計モジュールを開発しています。

私が使用するメカニズムは、データベースエントリを統計テーブルに保存することです-ユーザーがDBの特定のゾーンに入るたびに（Cookieを使用して重複レコードを回避します）。

たとえば、次のゾーンがあります。

  1. ウェブサイト - 最近 Google アナリティクスを信頼しなくなったので、ユニーク ユーザーをカウントするために使用される一般的なゾーン。
  2. カテゴリ - 自己記述的。
  3. ミニサイト - 自己記述的。
  4. 製品画像 - ユーザーが製品とリード送信フォームを表示したとき。

問題は、1 か月後、統計テーブルが大量の行でいっぱいになり、データの読み込みを解析するために作成した ASP.NET ページが非常に遅くなることです。

何らかの方法でデータを解析するサービスを作成する可能性があると考えましたが、柔軟性を失うことなくそれを行う方法がわかりません。

私の質問:

  1. 大規模なデータ解析アプリケーション (Google アナリティクスなど) は、どのくらい高速にデータをロードしますか?
  2. 私にとって最善の方法は何ですか？
  3. たぶん、私の DB 設計が間違っているので、データを 1 つのテーブルだけに保存​​する必要がありますか?

助けてくれてありがとう、

エイタン。

4

3 に答える 3

3

あなたが探している基本的なアプローチは、集計と呼ばれます。

データに対して計算された特定の関数に関心があり、表示されている Web サイトを起動するときに「オンライン」でデータを計算する代わりに、夜間にバッチ処理を介して、またはログ レコードが書き込まれるときに増分的に計算します。

簡単な拡張は、すべてのヒットを保存してカウントするのではなく、ユーザー/セッションごとにカウントを保存することです。これにより、分析処理の要件が、セッションごとのヒットの順序で 1 分の 1 に削減されます。もちろん、ログ エントリを挿入するときの処理コストが増加します。

別の種類の集計はオンライン分析処理と呼ばれ、データの一部のディメンションに沿ってのみ集計し、ユーザーはブラウジング モードで他のディメンションを集計できます。これは、パフォーマンス、ストレージ、および柔軟性をトレードオフします。

于 2009-01-27T13:23:14.883 に答える
2

2 つのデータベースを使用するとうまくいくようです。1 つはトランザクション データ用で、すべての INSERT ステートメントを処理します。もう 1 つはレポート用で、すべてのクエリ リクエストを処理します。

レポート データベースから鼻先にインデックスを付けたり、データを非正規化したりして、クエリで使用される結合を減らすことができます。トランザクション データベースからレポート データベースに定期的にデータをエクスポートします。この行為は、前述の集計のアイデアとともに、レポートの応答時間を改善します。

于 2009-01-28T06:21:55.763 に答える
1

知っておくべきもう 1 つのトリックは、パーティショニングです。選択したデータベースでそれがどのように行われているかを調べますが、基本的には、テーブルをいくつかのサブテーブルに分割し、それぞれが同じ定義を持つ値に基づいて保持するようにデータベースに指示することです。

あなたの場合、非常に便利なのは「範囲パーティショニング」です。値が入る範囲に基づいてパーティションを選択します。日付範囲で分割する場合は、週ごと (または、データの使用方法とデータの量によっては、日ごと、または月ごと) に個別のサブテーブルを作成できます。

つまり、クエリを発行するときに日付範囲を指定すると、その範囲外のデータは考慮されません。これは、インデックスよりもさらに優れた、非常に大幅な時間の節約につながる可能性があります (インデックスはすべての行を考慮する必要があるため、データと共に成長します。パーティションは 1 日あたり 1 つです)。

これにより、オンライン クエリ (ASP ページにアクセスしたときに発行されるクエリ) と、必要な統計を事前に計算するために使用する集計クエリの両方が大幅に高速化されます。

于 2009-01-27T19:43:10.653 に答える