関口宏司のLuceneブログ

OSS検索ライブラリのLuceneおよびそのサブプロジェクト(Solr/Tika/Mahoutなど)について
第6回Solr勉強会の資料公開
Lucene/Solr 3.2-3.4

Apache ManifoldCF



ランチが付いてますます充実のロンウイットのSolrトレーニング・・・Solr 3.3 10月 トレーニング受講者募集中

Solr トレーニングコースパンフレットダウンロードはこちら
| 関口宏司 | Luceneとは? | 02:41 | comments(1) | trackbacks(0) |
Luceneのアーキテクチャを紹介するサイト
ちょっと古い情報もあるが・・・

http://www.codemaps.org/s/Lucene_Core
| 関口宏司 | Luceneとは? | 09:59 | comments(1) | trackbacks(0) |
(メモ)Lucene/Solr/Nutchのアーキテクチャ(図)


元ネタ:

https://issues.apache.org/jira/browse/LUCENE-2412
| 関口宏司 | Luceneとは? | 10:52 | comments(0) | trackbacks(0) |
ワイルドカード検索のちょっと変わった使い方
メーリングリストアーカイブ検索のnabbleやバグ管理システムのAtlassian 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"とみなし、インデクシングや検索時に取り除いているためである。この働きにより、多くの場合は使いやすい検索システムとなるが、まれにこのような不都合に遭遇することとなってしまうのだ。

このような「表記揺れ」にはアプリケーション側である程度うまく対応することも可能だ。たとえば弊社のデモサイトで示しているように、「松下電器」で検索したときは、「パナソニック」を含むドキュメントも検索できるが、「松下電器」のドキュメントの方を「パナソニック」よりも上位にランキングされるようにする、という調整ができる。しかし、これは自分で作成したアプリケーションの場合である。nabbleやAtlassian JIRAで"solrjs"を検索するにはどうすればよいだろう。

こんなときは、"solrjs*"と、単語の末尾にワイルドカード検索の記号の"*"(アスタリスク)をつけてやるとよい:

http://www.nabble.com/forum/Search.jtp?forum=14479&local=y&query=solrjs*

すると今度は"solrj"が含まれずに"solrjs"だけが検索結果に含まれるようになる。理由は、LuceneのQueryParserはワイルドカード検索の単語を見つけると、AnalyzerをすっとばしてただちにWildcardQueryを作成するという仕様になっているためである。

このことを知らずに"solrjs -solrj"などと頑張ってやってみてもだめだ。これだとAnalyzerを通ったあとに"solrj NOT solrj"というBooleanQueryになってしまうからだ。
| 関口宏司 | Luceneとは? | 12:03 | comments(3) | trackbacks(0) |
Luceneバージョンの後方互換性に関するポリシーの変更の提案(3.0)
Lucene 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アノテーションの表示とともに、削除される最小バージョンを明示する。
  • リリースノートに「非互換変更点(Incompatible changes)」という項目を設け非互換のAPI変更点を明示する。その際、アプリケーションをどのように書き換えるべきかも解説する(Eclipseのリリースノートのように)。


なお、インデックスフォーマットに関するポリシーの変更はない。

これまでのLuceneユーザにとって、マイナーバージョン間でのAPIの非互換は結構インパクトが大きいと思われる。本提案はコミッター内での簡単な投票が行われ、上記JIRAでユーザ向けに公開/提案されているものであり、特に反対意見がなければこのようにポリシー変更がなされると思われる。
| 関口宏司 | Luceneとは? | 09:12 | comments(0) | trackbacks(0) |
Lucene in Action (2nd EDITION)
ManningのWebサイトによると、"Lucene in Action, SECOND EDITION"(LIA2)は来年3月出版予定らしい:

Lucene in Action, SECOND EDITION
http://www.manning.com/hatcher3/


そういえば先日、共著者のひとりであるOtisがLIA2に掲載するLucene事例をメーリングリストで募集していた:

Case studies for Lucene in Action 2nd edition

出版予定までまだまだ半年以上なので執筆真っ最中だと思われるが、早くもその第1章がManningのサイトで公開されている(参照するには、上記最初のURLに飛び、「Table of Contents」のChapter-1「Meet Lucene」をクリック)。
| 関口宏司 | Luceneとは? | 02:20 | comments(0) | trackbacks(0) |
EndecaやFASTを検討し、最終的にSolrに行き着いて満足した人
EndecaやFASTといった商用検索エンジンをはじめ多くの検索エンジンを検討し、最終的にSolrを採用して満足している人からのMLへの投稿:
http://www.nabble.com/Zappos%27s-new-Solr-Site-td16637873.html
| 関口宏司 | Luceneとは? | 09:50 | comments(0) | trackbacks(0) |
Lucene/Solr/Nutch - 入門者向けスライド
LuceneとSolrとNutchの入門者向けスライド(英語)。

http://www.slideshare.net/dnaber/apache-lucene-searching-the-web-and-everything-else-jazoon07/
| 関口宏司 | Luceneとは? | 18:57 | comments(0) | trackbacks(0) |
ThinkIT記事「Hibernate Searchで全文検索システム構築」
JBossチームとのコラボによるThinkIT記事第2弾が公開された。

Hibernate Searchで全文検索システム構築

当初この記事のタイトルはJBossチームの方発案による「Hibernate Searchでオブジェクトとサーチをマッピング」であったが、長すぎるのかひねりすぎるのかで編集部により上記のようなタイトルに変更されてしまった。私としてはオリジナルの方がキャッチーで好きだが、SEOの関係などがあるのかもしれない。

このHibernate Searchの記事は残暑厳しいころに書いて提出してあって、私としてはほとんど忘れていた。どうやらThinkITの待ち行列に長らく並んでいたようである。今割りと新鮮な気持ちで読み返してみると、「こういう発想もあるんだなあ」と書いた当時思ったことを思い出したりしている。

「こういう発想」とは、「全文検索エンジンをRDB的視点からシームレスに使いたいという要望を実現するフレームワークが必要である」、という考え方だ。なのでTritonnやLudiaにHibernate Searchは近いところがあるかもしれない。もっとも、Hibernate自身はO/RマッパーであるからRDB的視点というのとはちょっと違うかもしれない(そういう側面もあり「Hibernate Searchでオブジェクトとサーチをマッピング」というタイトルはHibernate Searchというフレームワークをよく表現できていてよかったと思っている)。


同じThinkITに掲載されているLudiaの記事によると、Ludiaは(Sennaの特徴を受け継いで)検索対象文書データを二重に持つことを避けるため、文書はPostgreSQLに持たせる、という方針が根底にあるようだ。

Hibernate Searchはどうかというと、Luceneを使っているので、検索対象文書データをRDBで一元管理するのかそれとも検索エンジンにも持たせて二重管理にするのかは選択可能である。

この「データの二重管理」は、その言葉から受ける印象はネガティブなものだが、RDBと検索エンジンで二重に持つのはそれなりに意味があり、短絡的な連想は禁物である。これは運用の容易性と検索性能のトレードオフの問題である。つまり、RDBで管理しているデータを検索エンジンでも持てば検索結果一覧をすばやく返せるが両者のデータの整合性をどのようにとればいいかという運用を考えなければならない。逆にRDBだけにデータを持たせればデータ管理は楽になるが、検索結果一覧をすばやく返すことができなくなる。この2つの項目はどちらを重要視するかはアプリケーションにより異なるので、「データ管理をストレージエンジンにまかせます」という決め付けを検索エンジンで行ってしまうのはちょっとどうかと思っている。具体的には「検索性能が出ないのではないか」、という心配だ。

実用的な検索アプリケーションでは、検索とは転置索引から単語を引いて文書ID一覧を持ってくるだけではなく、その文書の中身をどこからかもってきてユーザに提示するところまでが仕事となる。このとき、文書の中身をRDBから持ってくるのでは遅くなるはずだ。

この点はいつかTritonnやLudiaとLuceneの検索性能を比較して明らかにしたいと思っているが、Hibernate Searchでもってデータを一元管理するか二重に持たせるかのフラグを切り替えるだけでLuceneについては試せるので、これを先にやってもいいかもしれない。
| 関口宏司 | Luceneとは? | 23:52 | comments(0) | trackbacks(0) |
ThinkIT記事「JBoss EAP+Luceneによる全文検索システム」
JBossチームとのコラボによるThinkIT記事が公開された。

JBoss EAP+Luceneによる全文検索システム
| 関口宏司 | Luceneとは? | 11:35 | comments(2) | trackbacks(0) |
+ Solrによるブログ内検索
+ PROFILE
      1
2345678
9101112131415
16171819202122
23242526272829
3031     
<< December 2018 >>
+ LINKS
検索エンジン製品 - 比較のポイント
商用検索エンジンを購入した企業担当者は読まないでください。ショックを受けますから・・・
>>製品比較 10のポイント
+ Lucene&Solrデモ
+ ThinkIT記事
+ RECOMMEND
Apache Solr入門 ―オープンソース全文検索エンジン
Apache Solr入門 ―オープンソース全文検索エンジン (JUGEMレビュー »)
関口 宏司,三部 靖夫,武田 光平,中野 猛,大谷 純
+ RECOMMEND
Lucene in Action
Lucene in Action (JUGEMレビュー »)
Erik Hatcher,Otis Gospodnetic,Mike McCandless
FastVectorHighlighterについて解説記事を寄稿しました。
+ RECOMMEND
+ SELECTED ENTRIES
+ RECENT COMMENTS
+ RECENT TRACKBACK
+ CATEGORIES
+ ARCHIVES
+ MOBILE
qrcode
+ SPONSORED LINKS