読者です 読者をやめる 読者になる 読者になる

よしだのブログ

サブタイトルはありません。

Cloudera Search で実現できる検索方式3パターン

IT、プログラミング AWS、クラウド、IaaS 検索エンジン

どうも!昨日のユーザーガイドの意訳から、Cloudera Search で可能な検索方式を整理しました。
 関連:オレオレ意訳。Cloudera Search ユーザーガイド / Introducing Cloudera Searcn - よしだのブログ

検索方式3パターン

User Guide のイントロダクションを噛み砕くと、以下の3パターンの検索方式が可能だと思われます。いずれも特長のある方式で興味深いです。Hadoop / HDFS とのインテグレーションを核に、はやりの Flume を使ったりと面白いです。

1.near-real-time検索パターン

f:id:yoshi0309:20140326154301j:plain

  • Flumeで収集したイベントを、SolrとHDFSに放り込むパターンです。
  • Solrは受け取ったデータのインデックスにしてHDFSに書き込むとともに、near-real-time検索の機能でオンメモリに保持することで、素早く検索結果に表示することができます。
  • ログやPOSデータなどストリームデータの検索には最適かと思われます。

2.バッチ処理パターン(MapReduceでインデックス作成)

f:id:yoshi0309:20140326154305j:plain

  • 検索したいデータを予めHDFSに保存しておき、MapReduceを使ってインデックスを作成するパターンです。
  • MapReduceを使うので、スケールしやすく大容量のデータのインデキシングを素早くできます。
  • ちょっと特殊な用途でしか活きないかもしれない。毎回、全件インデックスする方式になると思うので、そのような具体的なユースケースが思いつかないですが。。

3.HBase検索パターン

f:id:yoshi0309:20140326154258j:plain

  • HBaseへの書き込みを LilyHBase Indexer Service*1 で検知し、インデックスを作成するパターンです。
  • HBase の更新を Lily が検知して、更新されたデータをSolrに投げつけて、Solrがインデックスを作成します。Solrを直接経由するので、near-real-time検索も可能だと思われます。
  • 絵では、Lily が直接インデックスを作成していますが、おそらくSolrに投げつけて(③がSolrを向く)、Solrがインデックスを作成するかたちかと思います。
  • サイトの記載通りであれば、かなり高速に更新の検知と検索への反映が可能だと思われます。また、HBaseとSolrの組み合わせで面白いことができそうな印象を受けました。

(共通)HDFSにインデックスデータを保持することで気になること

  • HDFSに書き込むことでインデックスデータを安全に運用できます。また、HDFSなのでデータが増えても比較的安心できます。したがって、耐障害性を目的としたインデックスデータのレプリカはいらないと思います。
  • HDFS自体はそもそもレスポンスが遅いです。このため、Solr側でかなり大量にインデックスデータをキャッシュとして保持している、保持する必要があると思われます。莫大なメモリが必要になることを避けるためには、インデックスのシャードの数やサイズは、検索用サーバー1台にのっているメモリ量に合わせて決める必要があると思います。
  • HDFS上にインデックスを共通で保持することで、検索サーバーの追加はかなり簡単になると思います。特に、検索用のインスタンスはオートスケールで自動構築、とかできるのではないだろうかと?オンメモリでほとんどのインデックスデータを持つことができれば、HDFSのDataNodeの追加や、再バランシングなども不要かもしれませんし。