まもなくリリース予定の 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 応用１」トレーニングコースでは、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 が機能しなくなる」点に問題がなければ（日本語環境では通常問題ないはず）ぜひ使ってみてはいかがだろう。