2

現時点では、ファイラーの膨大な量のログ (30G/日 x 3 マシン = 平均 100G) を保存しています。ログは圧縮されています。

そのログを検索する実際のツールは、対応するログを (時間範囲に従って) 検索し、それらをローカルにコピーし、解凍し、xml で情報を検索して表示します。

私たちは、そのログを検索するためのスパンクのようなツールを作成する可能性を研究しています (これは、他のシステムに送信されるメッセージ バス : xml-messages の出力です)。

圧縮されたログファイルを直接クエリする代わりに、mongo のようなデータベースに依存する利点は何ですか? また、データベース内の一部のデータにインデックスを付けて、プログラムに対象の zip ファイルを検索させることもできます...何が mongodb をもたらしますか...または hadoop をさらに ?

4

2 に答える 2

1

私は MongoDB に取り組み、現在は Hadoop に取り組んでいるので、興味深いと思われる相違点をいくつか挙げることができます。

  1. MongoDB では、ファイルを (生のテキスト データではなく) ドキュメントとして保存する必要があります。HDFS はそれをファイルとして保存し、カスタム MapReduce プログラムを使用してそれらを処理できるようにします。
  2. MongoDB では、クラスター全体で負荷を効率的に分散するために、適切なシャーディング キーを選択する必要があります。ログファイルを保存しているので、難しいかもしれません。
  3. ドキュメントにフォーマットされたログを MongoDB に保存できれば、膨大な量のログにわたって非常に短いレイテンシーでデータをクエリできます。私の最後のプロジェクトには MongoDB に基づく組み込みのログがあり、生のテキスト ログの MapReduce 分析と比較して、分析は非常に高速です。ただし、ロギングはゼロから行う必要があります。
  4. Hadoop には、テキスト形式のログを分析するのに役立つ Hive、HBase、Impala などのテクノロジーがありますが、MapReduce のレイテンシーを念頭に置く必要があります (ただし、レイテンシーを最適化する方法はあります)。

要約すると、スタック全体に mongoDB ベースのロギングを実装できる場合は MongoDB を使用しますが、テキスト形式のログが既にある場合は Hadoop を使用します。XML データをリアルタイムで MongoDB ドキュメントに変換できれば、非常に効率的なソリューションを得ることができます。

于 2013-01-25T17:36:15.443 に答える
0

私の Hadoop に関する知識は限られているため、MongoDB に焦点を当てます。

各ログ エントリを MongoDB に保存できます。時間フィールドにインデックスを作成すると、特定の時間範囲を簡単に取得できます。MongoDB はバージョン 2.4 で全文検索をサポートする予定です。これは確かにあなたのユースケースにとって興味深い機能ですが、まだ本番環境には対応していません。それまでは、部分文字列の検索は非常に遅い操作です。そのため、検索に関連する XML ツリーを mongodb オブジェクトに変換し、最も検索されたフィールドのインデックスを作成する必要があります。

ただし、MongoDB にログを保存すると、より多くのハード ドライブ容量が必要になることに注意してください。MongoDB はペイロード データを圧縮せず、独自のメタデータ オーバーヘッドも追加するため、解凍されたログよりもさらに多くのディスク領域が必要になります。また、新しいテキスト検索機能を使用すると、さらに多くのディスク容量が必要になります。私が見たプレゼンテーションでは、テキスト インデックスは、インデックスを作成するデータの 2 倍の大きさでした。確かに、この機能はまだ開発中ですが、最終バージョンで大幅に削減されるとは思えません。

于 2013-01-25T10:29:35.580 に答える