目次
今回はQuerqyのElasticsearchのプラグインがどんなつくりになっているか?をちょっとだけ調べてみました。 SolrでもElasticsearchでも使えるという形なので、どんなつくりになっているのかな?と思ったのが発端です。
GitHubのリポジトリ
GitHubにリポジトリが公開されています。 2つのリポジトリに分かれています。
どちらもJavaのライブラリで、ビルドシステムとしてはMavenを利用しています。 コアのライブラリのリポジトリにはさらに、以下の2つが存在しています。
- lucene向けライブラリ(Solr向けのモジュールもこちらに含まれる)
- コアライブラリ
pom.xmlを読んだところ、次のような依存関係になっています(それ以外にも使ってるライブラリはあるけど)。
Esプラグイン -> Lucene向けライブラリ -> コアライブラリ
Esプラグイン
Es向けのエンドポイントの実装、Esのクエリの組み立てを行なっています。 Rewriterの実装については、Lucene向けライブラリ、コアライブラリを利用する形になります。
querqy用のQueryBuilderを実装しており、EsがクエリをパースするタイミングでRewriterなどを呼び出してクエリの書き換えを行う仕組みです。 なお、Es向けのクエリの組み立てと書きましたが、ほとんどLuceneのクエリの組み立てになっています(そりゃそうだ)。 実際にquerqyのクエリ組み立て処理を行っているのは、Lucene向けライブラリのQueryParsingControllerになります。 いくつかのRewriterは、生のEsクエリをルールなどとして登録することができるようになっています。 これらのクエリのパースをEs側にやらせる処理の部分もこちらで定義されている感じです。
そのほかに、ドキュメントには記載がないエンドポイントが2つ用意されていました。 インデックスに登録してあるRewriterの設定を各ノードでキャッシュする仕組みがあって、そのキャッシュの操作(クリア、リロード)用みたいです。 これらは、Rewriterの追加、削除のアクションの内部で呼び出されているので、ユーザー側で呼び出す必要はなさそうです。
Lucene向けライブラリ
Luceneに関連する処理がまとめられています。 Es内部ではLuceneを使って検索処理が行なわれるため、Luceneのクエリを組み立てる必要があります。 querqyとしてLuceneのクエリを組み立てるときに必要なクラスがこのライブラリに含まれています。
また、Word Break Rewriterの実装はコアライブラリではなくこちらのライブラリに実装されています。 これは、Luceneのタームディクショナリを活用したRewriterになっているため、Lucene必須となっているからのようです。 (まだちゃんと実装を見ていないので、どんな活用の仕方をしているのかまではわかっていませんが。。。)
コアライブラリ
Rewriterの設定のパース処理、クエリのリライト処理の実装がまとめられています。 querqyのクエリが、Rewriterの処理に基づいて、querqyとして定義されたクエリのモデルに一旦変換される作りになっています。 Lucene向けライブラリやEs向けプラグインはこの内部のクエリモデルになったものをもとに、Lucene向けのクエリに書き換えていくというながれになっています。
まとめ
ざっくりですが、どんな構成なのかを見てみました。 Esのプラグインとなっているのですが、プラグインではなく、外部に出すことってできるのかな?と思いつつ、なんとなくソースを読んでみました。 パターンとしては、Lucene向けのクエリからEs向けのクエリを組み立てるとかの無駄な努力が必要になる気もするけど。。。 Luceneを使っていない検索エンジンに対しては、コアライブラリをもとに、それぞれの検索エンジンむけのクエリを組み立てる仕組みを作る形になると思います。 その際、Rewriterの設定を保持する仕組み、querqyが置き換えたクエリのマッピングができるか?といった点を考える必要がありそうです。 デバッグとかするときに、EsのクエリDSLのJSONとして見れるといいなぁと思ってたけど、そんなことできるかなぁ?
comments powered by Disqus
See Also by Hugo
- Querqyの調査(その1)
- Elasticsearch 2.0.0リリース(日本語訳)
- elasticsearch-inquisitorプラグインの紹介
- 機械学習による検索ランキング改善ガイドを読みました
- Elasticsearchの新しいJavaクライアント