データ処理（MapReduce / DHT？）フレームワークの推奨事項

Question

各ファイルが key：value のペアのセットである小さなファイルのセット（〜10M）全体で分散検索を実行する必要があります。これには合計56個のCPUコアを備えたサーバーのセットがあります。これらのほとんどはデュアルコアとクアッドコアですが、16コアの大規模なDL785です。

システムはオンラインクエリ用に設計する必要があります。理想的には、フロントエンドからのオンデマンドでJSON出力を返すWebサービスの実装を検討しています。

問題をさらに複雑にするために、特定の検索では、各ファイルの最新バージョンのみを表示したい場合がありますが、他の検索は、特定の日付。

Hadoopを見てきましたが、管理はかなり恐ろしく、デフォルトのジョブ送信方法は遅いです。オフラインの非常に大規模な処理用に設計されているようで、オンラインのデータ処理用ではありません。

CouchDBはドキュメントストアとしては見栄えがよく、 key：value スタイルのドキュメントとバージョン管理およびMapReduceを知っていますが、 distributed MapReduceシステム。すべてのクラスタリングのドキュメントでは、負荷分散のための全体データベースのクラスタリングとレプリケーションの使用について説明していますが、必要なのは負荷分散です。

また、さまざまなDHTを調査しましたが、個々のレコードを実際に保存および取得することは問題ありませんが、一般的にMapReduceの「マップ」部分の実行は貧弱です。ドキュメントセット全体を反復処理することが重要です。

したがって、私の理想的なシステムは、CouchDBのWebサービス機能を備えたHadoopのHDFSのような分散ファイルシステムで構成されます。

誰かが私を助けてくれる何かの方向に向けることができますか？実装言語は、Linux上で実行する必要があることを除いて、あまり気になりません。

Answer 1

Solrのようなソリューションには、問題ドメインの方が適しているようです。 Solrは、 JSON でも、他のアプリケーションへのhttpインターフェースを提供します。検索を複数のマシンに分割するか、ロードバランシング（マスター/スレーブ）のために単一のコピーをマシンに分散できます。それは、データに最適なものに依存します。しかし、リアルタイムの検索結果に関する私の経験では、Lucene / Solrは、map / reduceシステムに基づいたどのシステムよりも優れています。

Solrをアプリケーションに統合し、増分更新を行うのは非常に簡単です。ただし、バージョン管理についてはまったく考えていません。それが本当に必要な場合は、それに取り組む別の方法を見つける必要があるかもしれません。

Answer 2

アプリケーションのニーズについて少し混乱しているかもしれませんが、Solrが優れたアプリケーションであるキー/値のペアを検索できるようにする必要があることに言及しています。ただし、map / reduceのマップ部分を使用する必要があること、および1,000万件のドキュメントをスキャンする必要があることにも言及しています。 1,000万件のドキュメントをスキャンして結果をオンライン形式（ミリ秒単位）で返すソリューションを見つけることができるかどうかわかりません。しかし、別の解決策は、 HBase にも注目しています。これはHDFSの上に構築され、必要な種類の数百万の小さなアイテムのマップリデュースジョブを実行できます。しかし、ジョブは送信可能ではなく、探している時間の近くのどこかで終了するわけではありません。

現在、RSSアイテム（2Mアイテム、アイテムごとに数KB）でセットアップされたテストHBaseがあります。合計DBサイズは最大5Gbです。このDBに対して実行され、すべてのアイテムをスキャンして結果を出力するジョブがいくつかあります。クラスターはアイテムを約5,000 /秒でスキャンしますが、ジョブを完了するには約10分かかります。