5

迷っている: Hadoop、Hbase、Lucene、Carrot2、Cloudera、Tika、ZooKeeper、Solr、Katta、Cascading、POI...

1 つについて読むと、多くの場合、他のツールのそれぞれが言及されることを確信できます。

すべてのツールについて説明してくれるとは思っていません。私の特定のシナリオでこのセットを絞り込むのを手伝っていただければ、それは素晴らしいことです. これまでのところ、上記のどれが適合するかはわかりません。(いつものように) やるべきことを行う方法は複数あるようです。

シナリオは次のとおりです: 500GB - Hadoop に保存された最大 20 TB のドキュメント。複数の形式のテキスト ドキュメント: 電子メール、doc、pdf、odt。SQL データベースに保存されているドキュメントに関するメタデータ (送信者、受信者、日付、部門など) ドキュメントの主なソースは ExchangeServer (電子メールと添付ファイル) ですが、それだけではありません。検索について: ユーザーは、これらのドキュメントに対して複雑な全文検索を実行できる必要があります。基本的に、検索設定パネル (webapp ではなく Java デスクトップ アプリケーション) が表示されます - 日付範囲、ドキュメント タイプ、送信者/受信者、キーワードなどを設定します - 検索を開始し、ドキュメントの結果リストを取得します(および各ドキュメント情報について、検索結果に含まれる理由、つまり、ドキュメントで見つかったキーワード)。

考慮すべきツールとそうでないツールは? ポイントは、最小限の必要な「グルー」コードのみを使用して、このようなソリューションを開発することです。私は SQLdbs に精通していますが、Apache および関連するテクノロジにはかなり慣れていません。

基本的なワークフローは次のようになります: ExchangeServer/その他のソース -> doc/pdf/... からの変換 -> 重複排除 -> Hadopp + SQL (メタデータ) -> インデックスの構築/更新 <- ドキュメントを検索 (そして迅速に実行) ) -> 検索結果を表示

ありがとうございました！

4

5 に答える 5

3

solrを使用することは良いオプションです。上記と同様のシナリオで使用しました。分散インデックスサーバーとして、実際の巨大なデータにsolrを使用できます。

ただし、これらすべてのドキュメント形式に関するメタ データを取得するには、他のツールを使用する必要があります。基本的にあなたのワークフローはこれになります。

1) Hadoop クラスタを使用してデータを保存します。

2) map/redcue を使用して Hadoop クラスター内のデータを抽出する

3) 文書識別を行う (文書タイプの識別)

4) これらのドキュメントからメタデータを抽出します。

5) solr サーバーでメタデータのインデックスを作成し、他の取り込み情報をデータベースに保存します。

6) Solr サーバーは分散インデックス サーバーであるため、取り込みごとに新しいシャードまたはインデックスを作成できます。

7) 検索が必要な場合は、すべてのインデックスを検索します。

8) Solr はすべての複雑な検索をサポートしているため、独自の検索エンジンを作成する必要はありません。

9) また、ページングも行います。

于 2012-07-24T15:35:09.797 に答える
2

SolrをHBaseの「セカンダリインデクサー」として使用することで、一部のクライアントに対してこれを正確に実行しました。HBaseの更新はSolrに送信され、それに対してクエリを実行できます。通常、人々はHBaseから始めて、次にグラフト検索を続けます。最初から検索が必要なことを知っているように思われるので、HBaseにフィードするパイプラインからセカンダリインデックスを埋め込むことができます。

ただし、Solrを使用するだけで必要なすべてが実行されることに気付くかもしれません。

于 2012-07-19T21:48:02.140 に答える
2

注目すべきもう 1 つのプロジェクトは Lily ( http://www.lilyproject.org/lily/index.html ) で、Solr を分散データベースと統合する作業を既に行っています。

また、このアプリケーションにブラウザーを使用したくない理由がわかりません。ファセット検索とは何かを正確に説明しています。サーバーと通信 (JSON を解析) し、シック クライアント GUI に結果を表示するデスクトップ アプリを設定することは確かに可能ですが、この作業はすべてブラウザーで既に行われています。また、Solr にはすぐに使用できる無料のファセット検索システムが付属しています。チュートリアルに従ってください。

于 2012-08-21T23:48:06.373 に答える
1

Solr（http://lucene.apache.org/solr）を使用することは良い解決策ですが、いくつかの非自明なことに対処する準備ができています。まず、インデックスを適切に計画します。数テラバイトのデータは、ほぼ確実に、任意のレベルの妥当なパフォーマンスのためにSolr上に複数のシャードを必要とし、それらを自分で管理する責任があります。分散検索（複数のシャードからクエリを実行）を提供しますが、それは戦いの半分にすぎません。

ElasticSearch（http://www.elasticsearch.org/）も人気のある代替手段ですが、規模に関してはあまり経験がありません。同じLuceneエンジンを使用しているので、検索機能セットも同様であると思います。

別のタイプのソリューションは、SenseiDB（LinkedInからオープンソース）のようなもので、全文検索機能（これもLuceneベース）と大量のデータの実証済みのスケールを提供します。

http://senseidb.com

彼らは間違いなく向こうの検索で多くの仕事をしてきました、そしてそれの私のカジュアルな使用はかなり有望です。

すべてのデータがすでにHadoopにあると仮定すると、一貫したスキーマに適した形式でデータをSenseiDBにプルするカスタムMRジョブを作成できます。SenseiDBには、確認できるHadoopMRインデクサーが既に用意されています。

唯一の注意点は、セットアップが少し複雑になることですが、特にインデックス作成のパフォーマンスとファセット機能に関して、スケーリングの問題を何度も回避できます。また、HAが重要な場合は、クラスタリングのサポートも提供します。これは、SolrのAlphaのままです（Solr4.xはalphaatmです）。

それがお役に立てば幸いです！

アップデート：

私よりElasticSearchに精通している友人に聞いたところ、ElasticSearchには、使用しているマシンとシャードの数に基づいてクラスタリングとリバランスを行うという利点があります。これは、特にTBのデータを処理している場合、Solrに確実に勝ちます。唯一の欠点は、ElasticSearchのドキュメントの現在の状態が、多くの要望を残していることです。

于 2012-07-19T22:44:06.523 に答える
1

ちなみに、ドキュメントがHadoopに保存されているとは言えません。分散ファイルシステム（Hadoopについて言及したのでおそらくHDFS）に保存されています。

検索/インデックス作成について：Luceneは、シナリオに使用するツールです。インデックス作成と検索の両方に使用できます。これはJavaライブラリです。Webサービスを介して索引付け/検索システムにアクセスできるようにする関連プロジェクト（Solrと呼ばれる）もあります。したがって、Solrもさまざまなタイプのドキュメントの処理を可能にするので、検討する必要があります（Luceneは、ドキュメント（PDF、Wordなど）の解釈の責任を負いますが、おそらく、すでにそれを行うことができます）

于 2012-07-19T00:05:06.810 に答える