3

私が直面している問題は、何百万ものログをかなり高速に保存および取得することに関連しています。私は、ファイアウォール、侵入検知および防止システム、アプリケーション ログ、ユーザー アクティビティなどから毎日のログを収集し、それらをデータベースに保存し、リアルタイムでレポートを実行し、それらを関連付けて侵入を特定するなどの作業を行っています。およびmysql 現時点でのボトルネックはデータベースであることがわかりました。リレーショナル データベースのみの経験があります。一方、私は存在するすべてのテクノロジーについて完全に迷っており、データベース分野で知識を得ました。

では、NoSQL データベース (mongo、cassandra など) は従来のデータベース (MySQL、Oracle、MSSQL など) よりも優れており、パフォーマンスが優れていますか? 私が今まで読んだことから、集計機能がないため、レポートは実行できません。そうですか?

Dataware Houses は私のニーズに適していますか? レポートには使用されますが、リアルタイムには使用されないことは知っています。それは本当ですか、または許容できるかもしれないほぼリアルタイムをサポートする実装が今日ありますか? これは多かれ少なかれ異なるデータベース スキーマの設計方法であり、従来のデータベースがその優れた候補になる可能性があることがわかりました。これは本当ですか？

また、データベースに存在するデータベース機能を使用せずに、テーブル パーティションを作成することも提案されました。アイデアは、おそらくサイズに基づいて個別のテーブルを使用し、個別のテーブルのインデックスを保存および更新するプロシージャを作成し、一般的にそれらを操作して、結合または集計を実行する必要があるときはいつでも処理を高速化することです。誰かがこれに似たものを聞いたり使用したりしましたか? 最初は、そのような解決策はまったく当てはまらないように思えたからです。

最終的に、上記のテクノロジーのいくつかを移行して、より優れたバランスの取れた結果を得ることができますか?

私はそれが大きな問題であることを知っています。ただし、RDBMS に関する私の最新の知識と経験では、問題を解決するには不十分であることがわかりました。そして、テクノロジーは非常に多いので、意見を聞き、議論し、過去に経験を積んだ人々の指導を受ける必要があります。また、特定のアプローチの長所と短所についても説明します。私に役立つ可能性のある提案できるフォーラムはありますか? 最後にもう 1 つ、データ ボリュームの測定ランクはペタバイトではなくテラバイトになるため、hadoop などの一部のテクノロジが除外される可能性があります。

4

4 に答える 4

2

保存方法を決定する前に、どのような分析を行いたいかが問題になります。

集約指向のワークロードとあなたが話しているボリュームの場合、Oracle、SQL Server、または強力なサーバーで実行される postgresql などの従来の rdbms で十分です。パーティション分割やその他の DWH 手法 (具体化されたビューなど) をネイティブでサポートしているため、自分でまとめてまとめる時間を節約できます。たとえば、Oracle クエリ オプティマイザーは、新しいクエリ プランを生成するときにパーティション分割を考慮します。

レポート フロントエンドとして、市販のものを使用することも、独自のものを作成することもできます。一部のオプションは、obiee、SQL サーバー レポート サービス、cognos、および pentaho (無料) です。これらはすべて、クロス データベース レポート (DWH + オペレーショナル ストアの組み合わせ) をある程度サポートしています。

大規模なボリューム (10 億行のデータセット) の集計を含む任意のクエリに対する即時の回答が必要な場合は、teradata、netezza、vertica などを調べることができます。これらはかなりの費用がかかる傾向があります。

小規模なデータセットでの集計を含む任意のクエリに対する即時の回答が必要なことが多い場合は、を調べてください。強力なインメモリ分析ツールがあります。一人利用なら無料だと思います。

単純に数字を足し合わせるだけではなく、大量の複雑な関係 (分析のようなグラフ) を分析する場合は、うまくいきません。古いソリューションはうまく拡張できなかったり、費用がかかったりします。新しいソリューションは往々にして失敗します。どっちにしろ高額になります。イベントをどのように関連付けたいかを知らなければ、何かを推奨することは困難です。私は一般的な解決策を知りません。

個人的には、postgres (バックエンド) + pentaho と (どちらもフロントエンド) と、従来の ETL 用のケトルと Hadoop またはカスタム コードを使用して、より複雑な分析のために結果を事前計算します。postgres では、データをオペレーショナル ストアと DWH に分割します。

于 2013-08-07T21:32:27.410 に答える
0

たくさんの質問！

Q1: NoSQL には集計がありますか?

A1: Mongo に集計機能があることは知っていますが、前回使用したときは、リレーショナル データベースに比べてそれほど高速ではありませんでした。カサンドラと話せません。多くの人が Mongo を使用して、構造化されたログとレポートを保存しています。

Q2:データ ウェアハウスはどうですか?

A2:データ ウェアハウスがリレーショナル データベースに存在できるというのは、そのとおりです。それは、データを構造化し、それについて考える方法が異なるだけです。

リアルタイムのリレーショナル データベースに時間のスナップショットを保持し、古いログをアーカイブすることを考えたことはありますか?

たとえば、おそらく 1,000 万で、最も古いログ エントリをデータ ウェアハウスに送信し始めます。これにより、常に最新の 1,000 万のログ エントリのみを表示することが保証されます。これは高速である必要があります。

于 2013-07-31T16:20:38.990 に答える
0

「テーブル パーティションを作成することを提案されましたが、データベースに存在するデータベース機能は使用しませんでした。アイデアは、おそらくサイズに基づいて個別のテーブルを使用し、個別のテーブルのインデックスを格納および更新するプロシージャを作成し、一般的にそれらを操作して処理を高速化することです。結合または集計を実行する必要があるときはいつでも」
これは良いアプローチです。負荷に基づいて、新しいテーブルを毎時、毎日作成できます。Mysql はテーブル ロックを使用します。大きなテーブルに対するクエリには時間がかかるため、クエリの待機時間が長くなります。複数のテーブルでは、並列クエリを実行することが推奨されます。たとえば
、テーブルが 1 時間ごとに作成されると仮定すると、1 日の統計を取得するには、2 つのスレッドを使用できます。1 番目のスレッドは 0 時から 6 時までの統計を取得し、2 番目のスレッドは7時から12時。テーブル ロックの待機はありません。
複数のDBサーバーを使用して、より多くの負荷を処理できます

于 2013-08-05T10:10:34.730 に答える