JIRAなど、検索システムにLuceneを使用しているツールで、末尾が"s"で終わる単語を検索すると、まれに不便を感じることがある。"solrjs"(SolrのJavaScriptクライアントライブラリ)という単語をnabbleのSolrアーカイブ内で検索してみよう:http://www.nabble.com/forum/Search.jtp?forum=14479&local=y&query=solrjsすると、"solrjs"を検索したにもかかわらず、多数の"SolrJ"(SolrのJavaクライアントライブラリ)が検索に引っかかってしまう。これは、英語圏発のこれらのツールでは、LuceneのAnalyzerにEnglish-Stemmerツールを用いており、そのツールが単語末尾の"s"を機械的に複数形の"s"とみなし、インデクシングや検索時に取り除いているためである。この働きにより、多くの場合は使いやすい検索システムとなるが、まれにこのような不都合に遭遇することとなってしまうのだ。このような「表記揺れ」にはアプリケーション側である程度うまく対応することも可能だ。弊社のデモサイトで示しているように、「松下電器」で検索したときは、「パナソニック」を含むドキュメントも検索できるが、「松下電器」のドキュメントの方を「パナソニック」よりも上位にランキングされるようにする、という調整ができる。これは自分で作成したアプリケーションの場合である。JIRAで"solrjs"を検索するにはどうすればよいだろう。こんなときは、"solrjs*"と、単語の末尾にワイルドカード検索の記号の"*"(アスタリスク)をつけてやるとよい:http://www.nabble.com/forum/Search.jtp?forum=14479&local=y&query=solrjs*すると今度は"solrj"が含まれずに"solrjs"だけが検索結果に含まれるようになる。理由は、LuceneのQueryParserはワイルドカード検索の単語を見つけると、AnalyzerをすっとばしてただちにWildcardQueryを作成するという仕様になっているためである。-solrj"などと頑張ってやってみてもだめだ。solrj"というBooleanQueryになってしまうからだ。3.0から後方互換性のポリシーを変更(緩める)しようかという提案が行われている:https://issues.apache.org/jira/browse/LUCENE-1698現在のポリシーは前の記事を参照していただくとして、ここでは提案されている変更部分を示す:あるバージョンでdeprecatedとなったpublicおよびprotectedのAPIはマイナーバージョンアップを含む1つあとのリリースでは削除可能とする。3.1のAPIが3.2でdeprecatedとなった場合、これまでは4.0のリリースで削除されていたのが3.3のリリースでも削除される可能性が出てきた。そのようなAPIには@deperecatedアノテーションの表示とともに、削除される最小バージョンを明示する。changes)」という項目を設け非互換のAPI変更点を明示する。その際、アプリケーションをどのように書き換えるべきかも解説する(Eclipseのリリースノートのように)。インデックスフォーマットに関するポリシーの変更はない。これまでのLuceneユーザにとって、マイナーバージョン間でのAPIの非互換は結構インパクトが大きいと思われる。本提案はコミッター内での簡単な投票が行われ、上記JIRAでユーザ向けに公開/提案されているものであり、特に反対意見がなければこのようにポリシー変更がなされると思われる。Lucene」をクリック)。入門者向けスライドLuceneとSolrとNutchの入門者向けスライド(英語)。Searchで全文検索システム構築」JBossチームとのコラボによるThinkIT記事第2弾が公開された。Searchでオブジェクトとサーチをマッピング」であったが、長すぎるのかひねりすぎるのかで編集部により上記のようなタイトルに変更されてしまった。私としてはオリジナルの方がキャッチーで好きだが、SEOの関係などがあるのかもしれない。Searchの記事は残暑厳しいころに書いて提出してあって、私としてはほとんど忘れていた。ThinkITの待ち行列に長らく並んでいたようである。今割りと新鮮な気持ちで読み返してみると、「こういう発想もあるんだなあ」と書いた当時思ったことを思い出したりしている。「こういう発想」とは、「全文検索エンジンをRDB的視点からシームレスに使いたいという要望を実現するフレームワークが必要である」、という考え方だ。Searchは近いところがあるかもしれない。Searchというフレームワークをよく表現できていてよかったと思っている)。同じThinkITに掲載されているLudiaの記事によると、Ludiaは(Sennaの特徴を受け継いで)検索対象文書データを二重に持つことを避けるため、文書はPostgreSQLに持たせる、という方針が根底にあるようだ。Searchはどうかというと、Luceneを使っているので、検索対象文書データをRDBで一元管理するのかそれとも検索エンジンにも持たせて二重管理にするのかは選択可能である。この「データの二重管理」は、その言葉から受ける印象はネガティブなものだが、RDBと検索エンジンで二重に持つのはそれなりに意味があり、短絡的な連想は禁物である。これは運用の容易性と検索性能のトレードオフの問題である。RDBで管理しているデータを検索エンジンでも持てば検索結果一覧をすばやく返せるが両者のデータの整合性をどのようにとればいいかという運用を考えなければならない。逆にRDBだけにデータを持たせればデータ管理は楽になるが、検索結果一覧をすばやく返すことができなくなる。この2つの項目はどちらを重要視するかはアプリケーションにより異なるので、「データ管理をストレージエンジンにまかせます」という決め付けを検索エンジンで行ってしまうのはちょっとどうかと思っている。具体的には「検索性能が出ないのではないか」、という心配だ。実用的な検索アプリケーションでは、検索とは転置索引から単語を引いて文書ID一覧を持ってくるだけではなく、その文書の中身をどこからかもってきてユーザに提示するところまでが仕事となる。このとき、文書の中身をRDBから持ってくるのでは遅くなるはずだ。Searchでもってデータを一元管理するか二重に持たせるかのフラグを切り替えるだけでLuceneについては試せるので、これを先にやってもいいかもしれない。EAP+Luceneによる全文検索システム」JBossチームとのコラボによるThinkIT記事が公開された。比較のポイント商用検索エンジンを購入した企業担当者は読まないでください。McCandlessFastVectorHighlighterについて解説記事を寄稿しました。