Querqyの調査（その2：アーキテクチャ）

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として見れるといいなぁと思ってたけど、そんなことできるかなぁ？

Querqyの調査（その2：アーキテクチャ）

目次

GitHubのリポジトリ

Esプラグイン

Lucene向けライブラリ

コアライブラリ

まとめ

See Also by Hugo

Related by prelims-cli

FEATURED TAGS