BT

最新技術を追い求めるデベロッパのための情報コミュニティ

寄稿

Topics

地域を選ぶ

InfoQ ホームページ ニュース Apache Lucene 2.9 リリース

Apache Lucene 2.9 リリース

原文(投稿日:2009/10/07)へのリンク

Lucene 2.9 ではパフォーマンス向上に重点が置かれているが,大部分はインデックス管理方法に関するローレベルの内部インフラの変更によって実現されている。Lucene のインデックスデータベースは,複数に分割された"セグメント"をそれぞれ独立したファイルに格納する,という構成をとっている。ドキュメントをインデックスに追加するとき,必要があれば新たなセグメントが生成・追加され,場合によってはマージされる。また Lucene はソートのためのフィールド情報を FieldCache にキャッシュしているが,2.4 およびそれ以前のバージョンではキッシュのロードが高価な処理になっていた。2.4 ではフィールドキャッシュ全体を定期的に再ロードしているため,特にそうだ。Lucene チームはリリース2.9 を開発中に,セグメントの変更頻度が概して低いものであることに着目した。セグメントの変更は例えばマージや削除が実行する場合に発生するが,古いセグメントは静的であることが多い。従ってセグメントが変更された部分だけを再ロードすれば,フィールドキャッシュを修正することができるのだ。

Lucene にはまた,複数のセグメントを FieldCache にロードする処理の効率が悪い,という問題もあった。バージョン 2.9 では FieldCache をセグメント単位で管理することにより,かねてから問題であったこの非効率な処理の必要性を回避している。これらの変更による効果には目覚しいものがある。Lucid Imagination 社の Mark Miller 氏は 5,000,000 のユニークな文字列を用いて簡単なベンチマークを実施し,Lucene 2.4 に対するパフォーマンス改善が約15倍に達することを確認している。
Lucene 2.4: 150.726 秒
Lucene 2.9: 9.695 秒

これ以外の重要なパフォーマンス改善点として,再オープンの回数に関するものがある。Lucene 2.9 では新しいメソッド IndexWriter.getReader() が導入された。このメソッドは現在の InderWriter セッションでの変更内容を含んだフルインデックスを検索対象にするリーダ(Reader)を返すことによって,リアルタイムに近い検索機能を提供する。さらに IndexWriter.setMergedSegmentWarmer() を使って,これらのセグメントを即座に使用できるように"暖めて"おくことも可能だ。

もうひとつ大幅に見直されたのは数値操作で,中でも "0.5 から 9.99 英国ポンドの価格範囲のCDをすべて検索する" というような範囲指定クエリのコンテキストに関する部分だ。2.9 より前の Lucene の検索は基本的にテキストベースであるため,数値の操作は最大精度でエンコードされた文字列をベースとして行われていた。多くの場合これは,Lucene が結果セットを完成させるときに走査対象となるようなユニークな項目を大量に生成する。これまでは独自のカスタムエンコーダを作成することで,多くの開発者がこの問題を回避してきた。これに対してバージョン 2.9では Lucene が数値のネイティブエンコードをサポートしている。Field と Query のクラスでは,インデックスと検索でどの程度の精度をエンコードするかを決定するための精度階段(precison step)が導入されている。これによって検索の必要な項目数が大きく削減され,クエリ応答時間を大きく改善することができる。

バージョン2.9ではさらに,新たなクエリ形式,よりスケーラブルな複数項目のクエリ (ワイルドカード,プレフィックス,その他),ペルシア語・アラビア語・中国語用の新アナライザ,などが導入されている。unicode サポート,新たなクエリパーサフレームワーク,距離を基準としてドキュメントのフィルタリングやソートが可能な地理空間(geospatial)検索(我が家から5マイル以内のすべてのクリーニング店を探す,のような)なども改良された点だ。変更点や改良点は他にもたくさんあり,ここからその全リストが参照できる。

Lucene は通常ではメジャーバージョン間の完全な下位互換性を維持しているが,Lucene 2.9 についてはさまざまな面でブレーク(非互換性)がある。これについては CHANGES.txt の”Changes in backwards compatibility policy(下位互換性に関する方針変更について)”の章に記載されている。2.9 へのマイグレーションには再コンパイル,適切なレグレッションテスト,その他しかるべき検査作業が必要になりそうだ。一方で 2.9 用の再コンパイルによって廃止予定のメソッドコールの所在が明らかになるため,開発者はバージョン3に備えてアプリケーションを修正することができる。Lucene 3.0 ではJava 1.4 のサポートが終了され,2.9 バージョンで廃止予告されている機能がすべて削除される予定なので,これは望ましいことだ。

この記事に星をつける

おすすめ度
スタイル

BT