2017.12.15 Friday
スポンサーサイト
一定期間更新がないため広告を表示しています
| スポンサードリンク | - | | - | - |
関口宏司のLuceneブログOSS検索ライブラリのLuceneおよびそのサブプロジェクト(Solr/Tika/Mahoutなど)について
2011.09.13 Tuesday
第6回Solr勉強会の資料公開
Lucene/Solr 3.2-3.4
Apache ManifoldCF ランチが付いてますます充実のロンウイットのSolrトレーニング・・・Solr 3.3 10月 トレーニング受講者募集中 Solr トレーニングコースパンフレットダウンロードはこちら 2009.07.29 Wednesday
ワイルドカード検索のちょっと変わった使い方
メーリングリストアーカイブ検索の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になってしまうからだ。 2009.06.20 Saturday
Luceneバージョンの後方互換性に関するポリシーの変更の提案(3.0)
Lucene 3.0から後方互換性のポリシーを変更(緩める)しようかという提案が行われている:
https://issues.apache.org/jira/browse/LUCENE-1698 現在のポリシーは前の記事を参照していただくとして、ここでは提案されている変更部分を示す:
なお、インデックスフォーマットに関するポリシーの変更はない。 これまでのLuceneユーザにとって、マイナーバージョン間でのAPIの非互換は結構インパクトが大きいと思われる。本提案はコミッター内での簡単な投票が行われ、上記JIRAでユーザ向けに公開/提案されているものであり、特に反対意見がなければこのようにポリシー変更がなされると思われる。 2008.08.17 Sunday
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」をクリック)。 2008.04.12 Saturday
EndecaやFASTを検討し、最終的にSolrに行き着いて満足した人
EndecaやFASTといった商用検索エンジンをはじめ多くの検索エンジンを検討し、最終的にSolrを採用して満足している人からのMLへの投稿:
http://www.nabble.com/Zappos%27s-new-Solr-Site-td16637873.html 2008.01.12 Saturday
Lucene/Solr/Nutch - 入門者向けスライド
LuceneとSolrとNutchの入門者向けスライド(英語)。
http://www.slideshare.net/dnaber/apache-lucene-searching-the-web-and-everything-else-jazoon07/ 2007.11.12 Monday
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については試せるので、これを先にやってもいいかもしれない。 |
+ Solrによるブログ内検索
+ PROFILE
+ LINKS
+ Lucene&Solrデモ
+ ThinkIT記事
+ RECOMMEND
+ RECOMMEND
Lucene in Action (JUGEMレビュー »)
Erik Hatcher,Otis Gospodnetic,Mike McCandless FastVectorHighlighterについて解説記事を寄稿しました。
+ RECOMMEND
+ SELECTED ENTRIES
+ RECENT COMMENTS
+ RECENT TRACKBACK
+ CATEGORIES
+ ARCHIVES
+ MOBILE
+ SPONSORED LINKS
|
(C) 2024 ブログ JUGEM Some Rights Reserved.
|
PAGE TOP |