Cloudera Search で実現できる検索方式３パターン
どうも！昨日のユーザーガイドの意訳から、Cloudera Search で可能な検索方式を整理しました。
関連：オレオレ意訳。Cloudera Search ユーザーガイド / Introducing Cloudera Searcn - よしだのブログ
検索方式３パターン
User Guide のイントロダクションを噛み砕くと、以下の３パターンの検索方式が可能だと思われます。いずれも特長のある方式で興味深いです。Hadoop / HDFS とのインテグレーションを核に、はやりの Flume を使ったりと面白いです。
１．near-real-time検索パターン
- Flumeで収集したイベントを、SolrとHDFSに放り込むパターンです。
- Solrは受け取ったデータのインデックスにしてHDFSに書き込むとともに、near-real-time検索の機能でオンメモリに保持することで、素早く検索結果に表示することができます。
- ログやPOSデータなどストリームデータの検索には最適かと思われます。
２．バッチ処理パターン（MapReduceでインデックス作成）
- 検索したいデータを予めHDFSに保存しておき、MapReduceを使ってインデックスを作成するパターンです。
- MapReduceを使うので、スケールしやすく大容量のデータのインデキシングを素早くできます。
- ちょっと特殊な用途でしか活きないかもしれない。毎回、全件インデックスする方式になると思うので、そのような具体的なユースケースが思いつかないですが。。
３．HBase検索パターン
- HBaseへの書き込みを LilyHBase Indexer Service*1 で検知し、インデックスを作成するパターンです。
- HBase の更新を Lily が検知して、更新されたデータをSolrに投げつけて、Solrがインデックスを作成します。Solrを直接経由するので、near-real-time検索も可能だと思われます。
- 絵では、Lily が直接インデックスを作成していますが、おそらくSolrに投げつけて（③がSolrを向く）、Solrがインデックスを作成するかたちかと思います。
- サイトの記載通りであれば、かなり高速に更新の検知と検索への反映が可能だと思われます。また、HBaseとSolrの組み合わせで面白いことができそうな印象を受けました。
（共通）HDFSにインデックスデータを保持することで気になること
- HDFSに書き込むことでインデックスデータを安全に運用できます。また、HDFSなのでデータが増えても比較的安心できます。したがって、耐障害性を目的としたインデックスデータのレプリカはいらないと思います。
- HDFS自体はそもそもレスポンスが遅いです。このため、Solr側でかなり大量にインデックスデータをキャッシュとして保持している、保持する必要があると思われます。莫大なメモリが必要になることを避けるためには、インデックスのシャードの数やサイズは、検索用サーバー１台にのっているメモリ量に合わせて決める必要があると思います。
- HDFS上にインデックスを共通で保持することで、検索サーバーの追加はかなり簡単になると思います。特に、検索用のインスタンスはオートスケールで自動構築、とかできるのではないだろうかと？オンメモリでほとんどのインデックスデータを持つことができれば、HDFSのDataNodeの追加や、再バランシングなども不要かもしれませんし。
