BT

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

寄稿

Topics

地域を選ぶ

InfoQ ホームページ ニュース Lucene 3.5 と Solr 3.5 - 大幅な RAM 削減,SearchManager,ディープページングのサポート

Lucene 3.5 と Solr 3.5 - 大幅な RAM 削減,SearchManager,ディープページングのサポート

ブックマーク

原文(投稿日:http://www.infoq.com/news/2011/12/lucene-3.5-and-solr-3.5)へのリンク

Lucene PMC (Project Management Committee / プロジェクト管理委員会) は Apache Lucene 3.5.0 と Apache Solr 3.5.0 のリリースを発表した。Lucene は豊富な機能を持った高性能なテキスト検索ライブラリ,Solr はインデックス作成と検索処理のコアとして Lucene を使用するスタンドアロンの検索サーバである。

Lucene 3.5.0 リリースの主な変更点は次のとおり。

  • メモリ消費量の削減 。 テキストインデックス保持に必要なメモリ量を大幅に削減 (3~5X) した。これはターム(Term) を保持するための,メモリ効率のよいデータ構造の開発によって実現されている。
  • ディープページング (Deep Paging) のサポート。指定した ScoreDoc 以降の検索結果を返す IndexSearcher.searchAfter が追加された。前回ページの最後のドキュメントを searchAfter メソッドに渡すことにより,検索結果の次のページを取得できる。
  • SearcherManager。複数の検索スレッドによる IndexSearcher の共有と再オープン処理を簡略化するための org.apache.lucene.search.SearcherManager クラスが追加された。IndexReader の参照カウンタを使用することにより,IndexReader インスタンスが参照されなくなったときに安全にクローズする。IndexSercher の取得には acquire メソッドを,取得した IndexSearcher のクローズには release メソッドを使用する。
  • SearcherLifetimeManager。複数のリクエストに渡って一貫性のあるインデックスビューを提供するためのクラス org.apache.lucene.search.SearcherLifetimeManager が追加された。リクエスト間での IndexSearcher インスタンスの共用が簡単になり,検索結果のページングあるいはドリルダウン/アップ操作において,よりよいユーザエクスペリエンスを提供する。
  • IndexWriter.optimize() の非推奨IndexWriter.optimize が非推奨扱いになり,forceMerge に名称変更された。実行コストが非常に高い操作である上に,正しい結果が得られるのはインデックスが静的な場合のみであるため,利用を抑制することが目的だ。
  • IndexReader.reopen() の名称変更IndexWriter.reopen が openIfChanged に置き換えられた。インデックスが更新されていない場合,IndexReader.openIfChanged は null を返す。このメソッドは通常,新たに IndexReader をオープンするよりもコストが低い。
  • NGramPhraseQueryorg.apache.lucene.search.NGramPhraseQuery は N-gram フレーズクエリ用に最適化された PhraseQuery である。N-gram 解析を使用する場合には, クエリの速度が 30~50% 向上する。

Lucene 3.5 でのすべての変更点は Lucene 3.5 リリースノート を参照してほしい。

 

Solr 3.5.0リリースの主な変更点は次のとおり。

  • Lucene 3.5.0。Lucene 3.5.0 の修正と拡張,特にタームインデックスの保持に必要なメモリ量の大幅な削減。
  • 分散型の結果グループ化 。分散検索の結果グループ化 (result grouping,field collapsing とも呼ばれる) をサポートする。この機能は,表示されるドキュメントの数を,フィールドのユニーク値によって定義される "グループ" 毎に制限するものだ。これが分散検索でも機能するようになった。
  • 言語検出。新たなユーザ提供モジュールである "langid" によって,インデックス処理に先立ってドキュメントの言語を検出できるようになり,適切な判断が可能になった。この機能は Apache Tika の LanguageIdentifier あるいは Cybozu の language-detection ライブラリを使用した UpdateRequestProcessor として実装されている。
  • 数値に関する sortMissingFirst と sortMissingLast のサポート。Trie フィールド型や日付を含む数値型で sortMissingFirst と sortMissingLast がサポートされた。
  • HunspellStemFilterFactory。99 言語の語幹解析をサポートする Lucene の HunspellStemmerFilter サポートが追加された。Hunspell はもともと,OpenOffice スイートが使用していることでもっとも有名な高機能スペルチェッカだが,Solr では語幹解析に利用されている。
  • hl.q パラメータ. Highlighter (HighlightComponent) の q パラメータをオーバーライドする hl.q オプションパラメータが追加された。

Solr 3.5 でのすべての変更点は Solr 3.5 リリースノート を参照してほしい。

 

InfoQ は Apache Solr の開発者であり,Lucid Imagnination のチーフ・オープンソース・アーキテクトで共同創立者でもある Yonik Seeley 氏に,最新の Lucene および Solr リリースについて聞いた。

今回のリリースの変更で,Lucene あるいは Solr のユーザに対して即座にメリットのあるものは何でしょう?

Lucene/Solr ユーザに喜んでもらえるのは,タームインデックス用のメモリ使用量が大きく減少したこと,ベクタハイライトが改善されたこと,この2点でしょう。Solr には分散グループ化のサポートと,欠損値を先頭または最後にすることを指定して数値フィールドをソートする機能が追加されました。Lucene にはディープページングの最適化も追加されています。

 

開発者に対して,新しい SearchManager をデフォルトとして使用するように推奨しますか?

Lucene で新たに導入された SearchManager は,新規に Lucene ベースのプロジェクトを開発する人にとっては,出発点として適当なものでしょう。しかし既存の検索マネージャコードを移行する必要はありません。Solr ユーザにとってサーチャー管理は,最初から存在している内部実装の詳細に過ぎないのです。

 

次の Lucene 3.6 と Solr 3.6 は,どのようなものになるのでしょう?

オープンソースについてその話をするのはいつも難しいです。公式なロードマップがないのですから。画期的といえる変更のほとんどは "trunk",つまり 4.0 としてリリースされるものに含まれます。Lucene では,インデックス処理がコーデックのサポートによって完全に変更されます。また Solr は,先進的な分散インデックス機能を持つことで,NoSQL データストアに変容しつつあります。

 

NRT 機能を持った Solr が製品レベルでリリースされるのは,いつ頃になりそうですか?

Apache Solr の商業的ディストリビューションである LucidWorks は trunk(4.0-dev) の安定バージョンをベースとしています。そのため NRT 機能も備えています。NRT 機能を Solr 3.x ラインへバックポートするかどうかは,現時点では明確に決まっていません。Lucene/Solr 4.0 は,2012 年のどこかでリリースされると思います。

 

Lucene あるいは Solr を始めるなら,Lucene 3.5Solr 3.5 が Apache ミラーサイトからダウンロードできる。Maven ユーザであれば,Lucene には groupId に org.apache.lucene を,artifactId パターンに lucene-* を,バージョンには 3.5.0 を指定する。最新情報は Lucene および Solr メーリングリスト から入手可能だ。

この記事に星をつける

おすすめ度
スタイル

BT