0

Apache リクエスト ログによく似た、約 5,000 万行のリクエスト データの 1 つの大きなデータベース テーブルがあります。

request_url
user_agent
created

次のようなデータが含まれています。

/profile/Billy
Mozilla.....
2012-06-17...

/profile/Jane
Mozilla.....
2012-06-17...

次に、ユーザー名を含むすべてのユーザー データを含むユーザー データベース テーブルを作成します。

現在、毎晩、前日のリクエスト データを 1 行ずつ処理し、users テーブル内のユーザー名の 1 つに一致する URL が含まれているかどうかを確認しています。そうであれば、ユーザーが特定の日のページビュー数を確認できる統計を保存する別のテーブルの合計を増やします。

ただし、データセットが大きくなるにつれて、これはリソースを集中的に使用するようになり、要求データを URL でグループ化し、そのグループのカウントを取得する場合でも、完了するまでに長い時間がかかる可能性があります。

必要な最終結果を得るために、この情報を処理するより良い方法はありますか? いずれにせよ、リクエスト データはログに記録されるため、ページ ビューごとに合計をインクリメントするよりも、事後に統計を生成する方が望ましいでしょう。

これを 1 つのサーバーで実行しているため、複数のサーバーでデータを分散処理する必要はありません。

4

3 に答える 3

1

毎日新しいログテーブルから始めます。その日が終わったら、それを使用して合計を増やし、それをその巨大なメイン​​ログテーブルに追加して削除します。

于 2012-06-17T17:25:22.680 に答える
1

ページ ビューごとに合計を増やすことが最善の選択肢です。ユーザーごとに分けて後から「検索」する手間を省きます。これは、ページビューごとに 1 つの追加の更新クエリであるため、処理負荷は 1 回ではなく 1 日を通して分散されます (さらに、統計は毎日更新されるのではなく、常に更新されたままになります)

SQL で行うことに固執している場合は、次のことを検討してください。

SELECT COUNT(request_url) FROM your_table WHERE request_url LIKE %/profile/username%

（それがあなたがすでにしていることかどうかはわかりませんが？）

于 2012-06-17T17:22:18.800 に答える
0

Infobright のような分析データベースの調査を開始します。列ベースのストレージ エンジンは、ビッグ データ イニシアチブにおいて非常に重要であり、集計のイン メモリ分析やアドホック クエリを実行するために構築されています。

免責事項: 著者は Infobright と提携しています。

于 2012-06-18T16:42:58.763 に答える