1

LogParser を使用して IIS ログを SQL Server データベースにダンプするスクリプトをいくつか実行しました。

次に、これをクエリして、ヒット数や使用状況などに関する簡単な統計を取得できます。エラー ログ データベースやパフォーマンス カウンター データベースにリンクして、使用状況とエラーなどを比較する場合にも役立ちます。

これを 1 つのシステムに実装しただけで、過去 2 ~ 3 週間で、約 1,000 万件のレコードを含む 5 GB のデータベースが既にありました。

これにより、このデータベースへのクエリが非常に遅くなり、このままログを記録し続けると、ストレージの問題が発生することは間違いありません。

このようなログに対してより効率的な、このデータに使用できる代替データベースを提案できる人はいますか? Google の BigTable や Amazon の SimbleDB の経験に特に興味があります。

これらのいずれかがクエリのレポートに適していますか? COUNT、GROUP BY、PIVOT?

4

4 に答える 4

1

私も以前に同様の問題に直面しました。ログ ファイルが急速に大きくなったので、IIS ログにデータベースを使用するのが適切かどうかを考え始めました。考慮すべき点が 2 つあります。

  1. ほとんどの場合、IIS ログは有用な情報を直接提供することはできません。統計情報を取得するには、IIS ログを解析する必要があります。
  2. また、ほとんどの場合、IIS ログはクエリ用にデータベースで準備する必要はありません。

以前と同じようにすべてのログをファイルに保存することをお勧めしますが、週次または月次の統計情報 (定期的に処理) をデータベースに保存して、これらの重要なデータをすぐに提供できるようにすることをお勧めします。

于 2010-06-18T15:21:55.300 に答える
0

どのくらいの頻度でインデックスを更新しましたか? データに対してどのようなクエリを実行していますか?

おそらく、毎日の終わりにデータの定期的な照合を実行して、他のクエリを高速化できますか? (この照合された情報を使用して新しいテーブルを作成します)

ページ ヒット テーブルには、そのページがヒットされた回数に関する毎日のレコードがある場合があります。そのようにすれば、すべてのクエリで完全なテーブル スキャンを実行する必要がなく、ページ ヒット テーブルにヒットするだけです。

一意のホスト テーブルには、待ち時間、ヒットしたページの数、ダウンロードされたファイルの数、合計帯域幅、セッションの放棄、一意の Cookie (おそらくプロキシまたはファイアウォールの背後にあるさまざまなユーザー) のレコードが含まれる場合があります。

あるとすれば、どのようなパージ スケジュールを計画していますか?

すべてのデータを永久に保管しておくのは良いことですが、特にまだ考えたことのないものについては、必要なものの大部分は照合されたデータにあります。そのため、それを中心にレポートを作成し、それらの場合の生データを保管してください。あなたは本当にユニークなものが必要です。

いずれにせよ、キー値ストア (simpledb や bigtable など) を使用して構築する必要があるのはこれだけです。

于 2010-06-18T14:51:45.030 に答える
0

保管コストが最大の懸念事項になると思います。クラウド ルートを選択したとしても、その量のデータのコストを管理できるとは思えません。私の提案は、データを超安価なストレージに移動し、そのデータを効率的に操作できるソリューションを展開することです。

たとえば、サーバーから巨大なハード ドライブ (および適切なバックアップ ソリューション) を備えたローカル マシンにログ ファイルを移動し、データを分析できるツールをローカルで実行できます。ログ パーサーは、そのデータの小さなサブセットに対して操作できる場合に効果的です。データベースをローカルで実行できますが、最適化されたクエリでも実行が遅くなる場合があります。

これらのファイルを処理するために、 WebLog Expertなどのログ分析ツールの購入を検討することもできます。

于 2010-06-18T15:10:10.200 に答える
0

私はあなたのインデックスを見ていきます。10M 行は実際にはそれほど多くありません。SQL Server '05 または '08 を実行している場合、'Show Actual Execution Plan' を使用してクエリを実行すると、そのクエリの速度を上げるために作成する必要があるインデックスが提案されます。

その KILLS クエリのパフォーマンスに遭遇したもう 1 つのことは、間違ったデータ型を使用していることです。たとえば、日時を文字列として入力し、クエリで CONVERT を実行する必要がある場合。その時点でコーヒーや夕食をとることもできます (これは、Windows の DB パフォーマンス カウンター ログのデフォルトでした)。

また、バージョン (Development、Enterprise、Standard) によっては、パーティショニングを実装できます。したがって、日付で分割し、特定の時間枠のデータを取得すると、関連するデータのみを照会します。パーティショニングを試してみたい場合は、開発版の SQL サーバーにすべてのエンタープライズ機能が備わっていると思います。MySQL ではパーティショニングも可能です。USB ドライブから 150 GB のデータベースを実行しています。日付(私が信じている日)で分割されており、通常、先週のみクエリを実行します。そのぎこちない分割。

免責事項: 私は DBA ではありませんが、これらは私たちが行ったものであり、うまく機能しているようです。

于 2011-10-28T14:49:21.597 に答える