INFORMATION
サブスクリプション

Solr サブスクリプションパッケージ 2.3 LengthAwareEDisMaxQParserPlugin プレビュー

まもなくリリース予定の Solr サブスクリプションパッケージ 2.3(RCSS 2.3)に含まれる LengthAwareEDisMaxQParserPlugin の負荷試験を実施したので紹介しよう。

はじめに

まもなくリリース予定の RCSS 2.3 は Lucene/Solr 6.2 を取り込んだ Solr サブスクリプションパッケージだ。それ以外にも新機能として LengthAwareEDisMaxQParserPlugin が提供される。これは(処理速度という意味での)検索性能を重視した edismax のラッパーである。普通に使っていてもフレーズ検索が発生しやすい日本語環境で威力を発揮する。

今日、Solr を使ったほとんどの検索システムでは、edismax を標準で使っている。日本語環境では再現率と精度の両取りを狙って、N-gram と形態素解析のフィールドを用意するのが通例である。さらに検索漏れが心配な場合、1-gram フィールドを用意して次のような qf を設定する(よくある title と body フィールドの横断検索の場合)。

<lst name="defaults">
  <str name="qf">
    title_1g^5 title_2g^5 title^10 body_1g body_2g body^2
  </str>
</lst>
なお、_1g や _2g が末尾に付いているのはそれぞれ 1-gram、2-gram フィールドを表す。また何も付いていないものは形態素解析のフィールドを表している。「^数字」はそれぞれのフィールドへの重みを指定している。body より title を重視し、かつ N-gram フィールドより形態素解析フィールドを重要視するというごく一般的な設定である。

フィールドの横断検索を行いたい場合、edismax は自分で OR 検索を組み立てるのよりも(通常は)ランキングが好ましくなるのでよく使われるが、一方で日本語検索の場合はフレーズ検索を誘発しやすいという副作用もある。フレーズ検索は単語検索よりも重い検索となり、検索性能に大きく影響する。

LengthAwareEDisMaxQParserPlugin は検索キーワードの文字列長を見て、「なるべくフレーズ検索が発生しないように」 edismax を呼び出すラッパーとなっている。LengthAwareEDisMaxQParserPlugin がこれまでの edismax と比べてどの程度速く軽くなるのか検証を行ったので本稿でレポートする。

なお、今回のリリースで LengthAwareEDisMaxQParserPlugin が追加されたことにより、旧来の同様の効果を狙った(名前が似ている) LengthAwareQParserPlugin は deprecated となった。新しい LengthAwareEDisMaxQParserPlugin は断然使い勝手がいいので、もし LengthAwareQParserPlugin を使っている場合は、早速乗り換えることをお勧めしたい。

負荷試験結果

ロンウイットの「Solr 応用1」トレーニングコースでは、Solr のアンチパターン(避けた方がよい Solr の利用方法)のひとつとして「フレーズ検索の発生を避ける」という項目を紹介している。そこでは昔の弊社での負荷試験結果を引用して「フレーズ検索は単語検索の40倍遅い」という数値を示している(・・・かどうかは担当講師による)。当時から Lucene/Solr のバージョンも相当上がっているので、似たような数値が出るかどうかも今回注目した点である。

今回使用したサーバースペックは以下の通り。

ベンダー DELL PowerEdge T410
CPU Intel(R) Xeon(R) CPU E5620 @ 2.40GHz 8コア
メモリ 16GB
ハードディスク 3.5 インチ SATA (7,200 rpm): 500 GB
OS Ubuntu Server 16.04.1 LTS

負荷試験に使ったデータであるが、日本語 Wikipedia(約190万件)を RCSS 2.3 に登録し、形態素解析フィールドから df を考慮しつつ(←超レアな単語は避けつつ)文字列長が1〜4の長さになるキーワードを抽出し、JMeter で負荷をかけた。負荷がけクライアント(Mac OSX)はスレッド数20、Ramp Up time 30 秒で各テストケースで 5 分間ずつ負荷をかけた。負荷試験中、クライアント側は CPU 的にも余裕がある状態であることを確認している。

テストケースは edismax-3, edismax-4, la-3, la-4 の 4 つ。edismax-* は edismax を la-* は LengthAwareEDisMaxQParserPlugin を使った場合である。末尾の 3 または 4 は、それぞれ負荷試験時に 1 から 3 または 1 から 4 の文字列長のクエリを(混ぜて)使用したことを示している。LengthAwareEDisMaxQParserPlugin は solrconfig.xml に次のように設定した。

<queryParser name="lengthAwareEDisMax" class="com.rondhuit.solr.search.LengthAwareEDisMaxQParserPlugin">
  <lst name="qf">
    <str name="1">title_k1^5 title^10 body_k1 body^2</str>
    <str name="2">title_2g^5 title^10 body_2g body^2</str>
    <str name="3">title_3g^5 title^10 body_3g body^2</str>
  </lst>
</queryParser>
title は Wikipedia の見出し語を、body は説明文を登録したフィールドである。この設定により、la-3 はフレーズ検索が一切発生せず、la-4 でも文字列長 4 のキーワードのみフレーズ検索が発生するだけとなり、次のように設定されフレーズ検索の発生が避けられない edismax と比べると大幅な高速化が期待できる。
<lst name="defaults">
  <str name="qf">
    title_1g^5 title_2g^5 title_3g^5 title^10 body_1g body_2g body_3g body^2
  </str>
</lst>

それでは早速結果を見てみよう。JMeter 側でのレスポンスタイムは次のようになった。

edismax-3 edismax-4 la-3 la-4
Ave (ms) 525 787 16 19
Median (ms) 110 146 11 11
90% Line (ms) 1593 2508 34 39
Max (ms) 11118 14563 5472 5117
CPU Usage (%) 99 99 91 90
平均応答時間(Ave の行)で見れば、la-3 は edismax-3 の 32.8 倍、la-4 は edismax-4 の 41.4 倍高速、という結果となり、弊社で数年前に検証した「フレーズ検索は単語検索よりも 40 倍遅い」が現在でもあらためて裏付けらた格好となった。一方で CPU 使用率は edismax はほぼ 100%、LengthAwareEDisMaxQParserPlugin でも 90% を超えた。

LengthAwareEDisMaxQParserPlugin の制限事項

LengthAwareEDisMaxQParserPlugin は edismax を呼び出す前にキーワードの長さ毎に最適なフィールド指定の調整を行う。そのため、フレーズ検索を生成しようとする「pf/ps 系パラメータ」が効かなくなるので注意されたい。しかし日本語環境では検索キーワードとして入力した文字列から、「フレーズ検索を形成したい」気持ちは英語などよりも高くないと(弊社の経験上)考えられる。よってこの制限事項自体はあまり問題にならないと思われる。また理論上、検索結果件数は edismax と同じになるはずであるが、ランキングは異なる。そのため、既存のサービスが edismax で動いているところに LengthAwareEDisMaxQParserPlugin で置き換えようとする場合、検索結果表示順が変わることを考慮する必要がある。

まとめ

まもなくリリースの RCSS 2.3 に含まれる LengthAwareEDisMaxQParserPlugin についてその検索性能の検証結果をレポートした。LengthAwareEDisMaxQParserPlugin は同様の効果を狙った従来からある LengthAwareQParserPlugin の後継モジュールである。今日、Solr では edismax を標準で使うことが多いことから、edismax のいいところを残しつつ処理の重いフレーズ検索を極力避けられるように再設計したのが LengthAwareEDisMaxQParserPlugin である。

その結果は前述の通り、アンチパターンでもいわれている 40 倍の高速性能が確認できたものとなった。LengthAwareEDisMaxQParserPlugin の制限事項である「pf/ps が機能しなくなる」点に問題がなければ(日本語環境では通常問題ないはず)ぜひ使ってみてはいかがだろう。


トレーニングコース

ロンウイットのトレーニングは、Lucene/Solrの経験豊富なコミッターの
監修のもと開発されたハンズオン(実習)形式のコースです。

セミナー

ロンウイットのApache Software Foundationコミッターが、情報検索の基礎、自然言語処理、そして、ユーザにとっての効果についてご説明させていただきます。