著者：関口宏司

はじめに

Lucene/Solr 4.1.0がリリースされました。本記事は4.0から導入されたCodecに着目し、Codec（Flex API）導入以前の最終バージョンである3.6.2と最新の4.1.0の検索性能比較を行いましたのでその結果を簡単に報告します。

Codec〜Flex APIとは

CodecはLuceneインデックスのセグメントファイルを読み書きする低レベルのプログラムです。提案当時（4.0開発当時）はFlex APIなどと呼ばれ、Luceneインデックス内を自在に（4軸方向に！）イテレートするAPIを提供するとともに、セグメントファイルのフォーマットをより柔軟に切り替えられるよう、Codecレイヤを明確に分離するように大幅に書き換えられました。

これにより新しいCodecを取り込むのが容易になったり、今後の研究で最新のCodecを試すのにLuceneが選ばれることが増えることが期待されます。

ユニークキー検索

Lucene 4.1ではPulsing41が使えるようになりました。Pulsingは低いdocFreqの単語辞書においてdocやpostingリストなどの情報を単語辞書内にインラインに展開することでディスクseekが1回節約できる機能です。LuceneコミッターのMikeさんのブログによれば、セグメントファイルがページキャッシュに載っていない状態では、50%程度もの速度向上が見られたようです。

セグメントファイルがページキャッシュに載っていない状態を作るために、テスト実施時は毎回キャッシュをクリーンアップする必要があります。そのような場面もあるかもしれませんが、ここではより実際の場面に近い、キャッシュをクリーンアップしない通常の状態でテストしてみます。期待する結果としては、seek数が少なくなる分、CPU使用率がわずかでも減るのではないか、というところです。

テストには日本語Wikipediaの記事を使いました。日本語Wikipediaの各記事にはシーケンシャルな整数値のIDを振ってあります。そして検索はstring型としたタイトルフィールドに対して行いました。そのため、ほぼユニークキー検索のテストとなっています。

結果を以下に示します。期待に反し、4.1では検索性能はあがったものの、CPU使用率はわずかながら上昇してしまいました。試験にはSolrを使ったので純粋なLuceneのテストになっていないこと、また、負荷がけクライアントを十分確保できなかったので、サーバー側の余力は残されていることを注記しておきます。

圧縮機能

Codecの切り替えでサポートされるのはpostingリストだけではありません。Lucene 4.1.0ではデフォルトでstoredフィールドがLZ4圧縮されるようになりました。これにより、長いフィールドではI/O時間が短縮されることが期待できます。

実際に計測してみました。同じく日本語Wikipediaの記事を使い、記事部分をインデックスから抽出した適当な単語でハイライトつきで検索しました。

結果を以下に示します。4.1.0ではstoredデータのインデックスサイズが大きく減少し、検索性能はQPS、応答時間ともにわずかですが改善されました。

まとめ

新しいCodecを使ったLucene 4.1.0と、Codec導入以前のLucene 3.6.2の検索性能を簡単なテストによって比較しました。テストでは実際にはSolrを使ったため、純粋なLuceneの負荷試験にはなっていません。そのためかCPU使用率については予想とは異なる結果を得ましたが、単純な検索性能は4.1でわずかに向上し、storedフィールドのインデックスサイズは小さくなるという結果を得ました。今後Lucene単体で追試をしてみたいと思います。なお、Solrのキャッシュはすべてオフにしてあります。

最後にテストで用いた環境を以下に記します。

サーバー仕様

負荷がけクライアント仕様

Tweet