3

Web サーバーが生成する Web アクセス ログをロードするデータ ウェアハウス システムを構築することを検討しています。アイデアは、データをリアルタイムでロードすることです。

ユーザーにデータの折れ線グラフを表示し、ユーザーがディメンションを使用してドリルダウンできるようにします。

問題は、システムのバランスを取り、設計する方法です。

(1) データを取得し、リアルタイム (<2 秒) でユーザーに表示できます。

(2) データは時間単位および日単位で集計できます。

(2) 大量のデータを倉庫に保存できるため、および

現在のデータレートは約 1 秒あたり約 10 アクセスで、1 日あたり約 80 万行になります。MySQL と単純なスター スキーマを使用した単純なテストでは、行数が 800 万を超えると、クワイアに 2 秒以上かかり始めることがわかりました。

このような「単純な」データ ウェアハウスからリアルタイムのクエリ パフォーマンスを取得し、大量のデータを保存することは可能ですか (データを決して破棄できないと便利です)。

データをより高い解像度のテーブルに集約する方法はありますか?

これは実際には新しい質問ではないと感じました（ただし、かなりグーグルで検索しました）。誰かがこのようなデータ ウェアハウス ソリューションにポイントを与えることができますか? 頭に浮かぶのはSplunkです。

たぶん、私はあまりにも多くのことを把握しています。

アップデート

私のスキーマは次のようになります。

  • 寸法:

    • クライアント (IP アドレス)
    • サーバ
    • URL

  • 事実;

    • タイムスタンプ (秒)
    • 送信されたバイト数
4

4 に答える 4

2

上記のセスの答えは非常に合理的な答えであり、適切な知識とハードウェアに投資すれば、成功する可能性が高いと確信しています.

Mozilla は多くの Web サービス分析を行っています。詳細は 1 時間ごとに追跡し、商用 DB 製品である Vertica を使用しています。このアプローチは非常にうまく機能しますが、独自の商用製品であるため、関連するコストが異なります。

調査したい別のテクノロジは、MongoDB です。これは、このユース ケースに最適な可能性のあるいくつかの機能を備えたドキュメント ストア データベースです。つまり、上限付きコレクション (詳細については、mongodb 上限付きコレクションを検索してください)

また、ページ ビューやヒット数などを追跡するための高速インクリメント操作 。

于 2009-12-31T02:13:29.863 に答える
1

また、特にクエリが主に最新のデータにアクセスする場合は、パーティショニングを検討してください。たとえば、最大550万行の毎週のパーティションを設定できます。

1日および1時間ごとに集計する場合は、日付と時刻のディメンションを設定することを検討してください。これらはリストされていないため、使用しないと思います。アイデアは、HOUR（myTimestamp）やDATE（myTimestamp）のような関数をクエリに含めないことです。日付ディメンションは、ファクトテーブルと同じ方法で分割する必要があります。

これを設定すると、クエリオプティマイザはパーティションプルーニングを使用できるため、テーブルの合計サイズが以前のようにクエリ応答に影響を与えることはありません。

于 2009-12-31T12:24:51.717 に答える
1

問題になるとは思えません。MySQLは非常に高速です。

ログ データを保存するには、MyISAM テーブルを使用します。MyISAM テーブルははるかに高速で、Web サーバー ログに適しています。(最近の新規インストールでは InnoDB がデフォルトだと思います。外部キーと InnoDB の他のすべての機能は、ログ テーブルには必要ありません)。また、マージテーブルの使用を検討することもできます。1 つの大きなテーブルとしてすべてのテーブルにアクセスしながら、個々のテーブルを扱いやすいサイズに保つことができます。

それでも追いつかない場合は、メモリを増やし、より高速なディスク、RAID、またはより高速なシステムをこの順序で入手してください。

また、データを破棄しないことは、おそらく悪い考えです。各行の長さが約 200 バイトの場合、生のログ データだけで、年間最低 50 GB について話していることになります。インデックスがある場合は、少なくとも 2 倍します。バックアップの場合は、(少なくとも) 2 倍します。

必要に応じてすべてを保持することもできますが、生データを数週間、集計データを数年間保存することを検討する必要があります。古いものについては、レポートを保存してください。(つまり、法律で保管が義務付けられている場合を除きます。その場合でも、おそらく 3 ～ 4 年以上は保管されないでしょう)。

于 2009-12-30T22:47:39.653 に答える
0

これは、かなり一般的なデータ ウェアハウジング アプリケーションになりました。私は何年もの間、1 日に 2,000 万から 1 億行をサポートし、(データベースからの) 応答時間は 0.1 秒で、Web サーバーからは 1 秒以上でした。これは巨大なサーバーでもありません。

あなたのデータ ボリュームはそれほど大きくないので、非常に高価なハードウェアは必要ないと思います。しかし、私はまだマルチコア、64 ビット、大量のメモリを使用します。

ただし、特に日、月などの時系列グラフの場合は、詳細データではなく集計データを主にヒットする必要があります。集計データは、非同期プロセスを介してデータベースに定期的に作成するか、通常はこのような場合に機能しますデータを変換する ETL プロセスが集計データを作成する場合に最適です。集計は通常、ファクト テーブルの単なるグループ化であることに注意してください。

他の人が言ったように、詳細データにアクセスするときは、パーティション分割をお勧めします。しかし、これは集計データにとってそれほど重要ではありません。また、事前に作成されたディメンション値への依存は、関数やストアド プロシージャよりもはるかに優れています。これらは両方とも、典型的なデータ ウェアハウジング戦略です。

データベースに関しては、MySQL ではなく Postgresql を試してみます。その理由は、主にオプティマイザの成熟度にあります。postgresql は、実行する可能性が高い種類のクエリをより適切に処理できます。MySQL は 5 方向の結合で混乱する可能性が高く、サブセレクトを実行するとボトムアップになります。このアプリケーションが価値がある場合は、db2、oracle、sql サーバーなどの商用データベースを検討します。次に、クエリの並列処理、集計テーブルに対する自動クエリの書き換え、追加のオプティマイザーの洗練などの追加機能を取得します。

于 2010-01-06T17:57:37.137 に答える