8

MySQLデータベースでカスタムOpenX広告サーバーを実行しています。1日あたり100万回のクリック。このクリック情報をすべて保存し、それに基づいて統計を表示する必要があります。

現在、すべてのクリック情報は2日ごとに集計され、特定のクリック情報は削除されます。ただし、アフィリエイトに動的追跡ID（TID）を設定し、基本的にこれに基づいてクリック数とコンバージョン数を追跡できる新機能を提供したいと考えています。

したがって、問題は、クリックテーブルが1日に最低100万エントリ増加することです。このテーブルを検索して、TIDでグループ化された、特定の期間における1人のユーザーのすべてのクリックを表示できる必要があります。上記、またはTIDで検索します。

MySQLのパーティショニングを調べたところ、それは良い解決策のように思えますが、それでも巨大なデータベース（おそらく数十億のエントリ）でうまく機能するかどうかはわかりません。

この問題に対する正しいアプローチは何だと思いますか？

編集：

あなたの答えに基づいて、私は今、混合ソリューションを考えています。

メンテナンス時にクリックが集計されたときにエントリが削除される「LIVE」テーブルがすでにあります。これは次のようになります。

表：クリック数

Viewer_id | ... | date_time | affiliate_id | ... | tid

（この時点で重要でない列はスキップしました）

メンテナンス時に、ほぼ同じように見える別の月次テーブルにすべてを移動できます。たとえば、テーブル：clicks_2012_11は、 date_time、affiliate_id、tidのインデックスを持ち、 affiliate_idでパーティション化されています。

したがって、アフィリエイトが過去2か月間の統計を確認したい場合は、テーブル：clicks_2012_10とテーブル：clicks_2012_11を確認する必要があります（期間は最大2か月に制限されます）。テーブルはaffiliate_idでパーティション化されているため、2つのテーブルから必要なパーティションのみが検索され、過去2か月間にアクティビティが発生したすべてのTIDを一覧表示できるようになりました。

このアプローチについてどう思いますか？明らかな問題はありますか？私は確かな理由なしに物事を複雑にしすぎていますか？

4

2 に答える 2

2

MySQL を失敗させる大きな (「巨大な」) テーブルに固有のものは何もありません。大きなテーブルは、主に次の点で問題になります。

  • ディスクスペース
  • キャッシュの使用量 (メモリ内で実行できない可能性があります)
  • メンテナンス (スキーマの変更、再構築など)

これらすべてに対処する必要があります。

パーティショニングは主に、パーティション全体を削除するなどのバルク データ メンテナンスに役立ちます。大きなテーブルをデフォルトで一部の列だけに分割することは、確かにベスト プラクティスではありません。パーティショニングは、常に特定の理由で導入されます。

于 2012-10-29T14:11:34.857 に答える
1

通常、挿入の最適化と検索の最適化は相互に排他的です。2 つのテーブルを使用する方がよい場合があります。

live data: no (or minimal) keys, myisam to remove transaction overhead, etc...
historical data: indexed up the wazoo, with data moved over from the live data on a periodic basis.
于 2012-10-29T14:16:09.027 に答える