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

seratch's weblog in Japanese

About Scala, Java and Ruby programming in Japaense. If you need English information, go to http://blog.seratch.net/

第1回 ElasticSearch 勉強会に参加 #elasticsearchjp

@yusuke さんがブログを書いていたので、思い出したように書いてみます。

http://atnd.org/event/E0018616

主催していただいた @johtani さん、会場提供してくださったリクルート社に感謝します。@johtani さんとは懇親会で初めてお話しできてよかったです。

今回は同僚の @cbirchall(GitHub やSlideshare は @cb372) が ES を使った開発の tips やテストフレームワークの紹介などを発表していました。

発表にもある通り、弊社ではこれまで各サービスごとに Solr を使っているケースが多かったですが @cbirchall がリードしてくれて、新しく立てるものは ES(ElasticSearch)が利用されています。ES を実際使い始めたのは今年の 3 月くらいからです。

たいした内容ではないですが @cbirchall の発表になかった内容を少しだけ紹介します。

JDBC River Plugin を検討したが使わなかった

マスターデータが DB に保存されている文書を検索インデックスに定期的に反映したい場合、Solr だと DIH(Data Import Handler)を使いますが、現時点では ES 本体に同等の機能は存在しません。

ただ River という拡張ポイントがあって、これを実装した JDBC River Plugin というのを 3rd party で開発している方がいます。

https://github.com/jprante/elasticsearch-river-jdbc

当初、これを使おうと思い、評価していたのですが、どうも import の途中で ES のインスタンスを落とすとインデックスが壊れてしまうという割とクリティカルな事象が比較的頻繁に発生したので、途中で利用を見送りました。これは 3 月時点での話でしたが JDBC River の commit history を見ても fix されている様子はなさそうに見えます。原因追及して pull request できればベストなのですが、そこまではできていません。

当方では自作の Ruby スクリプトで対応しました。ActiveRecord をラップしたちょっとした共通 module を書いて、それを使ったコードは #find_in_batches の中で JSON をつくって ES の Bulk API に投げるというイメージです。

API に渡した JSON を管理

動的にフィールドが確定されるの怖い、という話題がありましたが Mapping API を使って事前に各フィールドの型を確定させるようにしています。

http://www.elasticsearch.org/guide/reference/mapping/

Solr のように schema.xml を置いておく必要がないので、万が一のリカバリに困らないよう API コールに使用した JSON の内容を上記のオレオレ DIH スクリプトを含む ES の管理プロジェクトに保存するようにしています。利用 plugin も管理するようにしています。現状だと head、bigdesk、kuromoji くらいなのですが。

unicast discovery

台数もそれほど多くなく、管理上把握しやすいということで unicast discovery で設定されています。

http://www.elasticsearch.org/guide/reference/modules/discovery/zen/

まだまだこれから

@cbirchall はかなり詳しいのですが、私自身はまだまだこれからです。

エンジニア募集中なので @cbirchall (や私)と一緒に ES 触りたい方はお気軽にご連絡ください。

http://at.m3.com/job