2017.12.15 Friday
スポンサーサイト
一定期間更新がないため広告を表示しています
| スポンサードリンク | - | | - | - |
関口宏司のLuceneブログOSS検索ライブラリのLuceneおよびそのサブプロジェクト(Solr/Tika/Mahoutなど)について
2006.03.31 Friday
Luke - Luceneインデックスブラウザ
LukeはLuceneインデックスのブラウザである。次のような機能がある:
・Document番号または単語指定によるブラウズ ・Documentの表示とクリップボードへのコピー ・頻出語のランク付けされたリストの取得 ・検索の実行と結果のブラウズ ・検索結果の分析 ・Documentの削除 ・ドキュメントフィールドの再構成と再挿入 ・インデックスの最適化 Lukeを起動するには、LukeのサイトからLukeのJarファイル(執筆時はluke-0.6.jar)を入手し、Luceneアプリの実行時クラスパスにLukeのJarファイルを加えた状態で、次のように行う:
すでにLuceneのインデックスがある場合は、-indexオプションでインデックスのディレクトリを指定しながらLukeを起動できる:
次はHelloLucene.javaで作成したインデックスをLukeで参照しているときの画面である: ただし、HelloLucene.javaはRAMDirectoryを使っているので、ハードディスク上にインデックスを作るよう、FSDirectoryを使うように変更しなければならない。 次は同じLukeの画面だが、JapaneseAnalyzerではなく、CJKAnalyzerを使って作ったインデックスをブラウザしている様子である。単語がbi-gramで抽出されている様子がわかるだろう: 2006.03.30 Thursday
Luceneアプリケーションの開発環境の紹介
Luceneアプリケーションの開発環境を紹介する。私は「Apache Ant」のまえがきにも書いたとおりのAnt大好き人間なので、Luceneアプリの開発環境も迷うことなくAntである。
ここで紹介するのは、Luceneアプリのコンパイルと実行が簡単に行えるような開発環境である。開発環境のディレクトリ構造は、次の通りである:
開発環境の「ホーム」ディレクトリに、build.xmlと2つのプロパティファイルmyenv.propertiesおよびbuild.propertiesファイルがある。 また、「ホーム」ディレクトリの下にsrcディレクトリがあり、このディレクトリ以下にLuceneアプリケーションのソースコードを配置する。 Antのビルドファイルであるbuild.xmlは、冒頭で上記2つのプロパティファイルを次のようにインポートしている:
これらのプロパティファイルでは、build.xmlで使用するプロパティを設定している。 プロパティファイルを2つに分けている理由は、開発環境依存のものとそうでないものにプロパティ設定を分けるためである。 myenv.propertiesの方は開発環境に依存する設定がなされており、build.propertiesの方には開発環境には依存せず普遍的なプロパティ設定が集められている。 myenv.propertiesは私の現在の環境では、次のようになっている:
上から順にLucene 1.9.1のインストールディレクトリ、Lucene-jaのインストールディレクトリ、Sen 1.2.1のインストールディレクトリである。 イコールの左辺のプロパティ名は、build.xmlにて次にインポートされるbuild.propertiesの中で参照されている。 build.propertiesは次のようである:
build.properties中で、いくつかのプロパティ設定の右辺がmyenv.propertiesで設定しているプロパティを参照していることがわかるだろう。 したがって、build.xmlの中で2つのプロパティファイルをインポートする順番に注意する必要がある。 build.xmlは次のようになっている:
主要なターゲットはcompileとrunである。これらのターゲットで使用しているクラスパスは、次のようにbuild.xmlの中で設定している。
これにより、日本語Luceneアプリケーション(JapaneseAnalyzerを使うという意味で)のコンパイルと実行に必要なクラスパス設定を行っている。 ちなみに上記の最後のfilesetでは、Jakarta Commons LoggingのJarファイルを指定しているが、これはLuceneアプリケーションのコンパイル時には必要ない。実行時に必要となってくるものである。 Jakarta Commons LoggingはLuceneアプリケーションのコンパイル時には不要なので(アプリの中でLoggingを使っていなければ)、実行時にクラスパスに指定することをつい忘れがちである。 このJarファイルをクラスパスに含めずにJapaneseAnalyzerのインスタンスを作成するアプリケーションを実行すると、次のようなエラーが発生する:
これは、JapaneseAnalyzerが使用しているSenのライブラリがJakarta Commons Loggingを使用しており、そのためJakarta Commons LoggingのJarをクラスパスに含めないで実行すると、JapaneseAnalyzerのtokenStream()メソッドの中でSenのクラスのインスタンスの取得に失敗するためである。 このbuild.xmlを使ってLuceneアプリケーションのコンパイルを行うには、srcディレクトリの下にソースを配置し、次のようにAntを実行すればよい:
すると、classesというディレクトリが作成され、コンパイルされたバイトコードがそのディレクトリの下に作られる:
このようにしてコンパイルしたLuceneアプリケーションHelloLuceneをAntから実行するには、次のように行う:
Antを実行するときのコマンドラインに指定した引数"-Dp=HelloLucene"の意味は、プロパティ p にHelloLuceneを設定する、ということである。 runターゲットの<java>Antタスクでは実行するクラス名を${p}で参照しているので、このように呼び出すことにより、あらゆるLuceneアプリケーションを起動できるようにしている。 "-Dp="を忘れてAntのrunターゲットを呼び出した場合、runターゲットの最初のAntタスク<fail>のチェックにひっかかるので、次のようにrunの実行が失敗する:
2006.03.29 Wednesday
はじめてのLucene全文検索プログラム
子供のころ、日曜日の夕方になるとしばしば不安感に襲われたことを思い出す。
それは「月曜日からまた学校が始まる」ということのほかに、あるテレビ番組も原因のひとつだったように思う。 それは「サザエさん」である。 思えばフシギな番組であった(今でも続いているが・・・)。何がフシギかというと、カツオとタラちゃん、ワカメとタラちゃんは兄弟(姉弟)ではない、ということだ。 これは子供心にとても理解しがたい事実であった。あの三人はどうみても兄弟であろう。しかしどうだ。実際はサザエ・カツオ・ワカメが兄弟姉妹の関係なのだ。 カツオとワカメは小学生のようだが、彼らの姉は結婚して子供もいるのである。サザエさんとその下の二人はとても歳が離れているのだ。サザエさんが生まれた後、十年ほど経ってからカツオとワカメが相次いで生まれた計算だ。 そのとき波平と舟の間に何があったのだろう。小学生のころはそんなことは考えなかったと思うが、今はとても気になる。 ・・・そういうことなので、タラちゃんにとってカツオはお兄さんではなく、ワカメはお姉さんではなく、おじさん、おばさんであり、カツオやワカメから見てタラちゃんは弟ではなく甥、ということを子供のころに学習した。 また、作者の「長谷川町子」という名前、子供のころはこの苗字も最初はなんと読むのかさっぱりわからなかった(ほかにも「東海林さだお」もよくわからなかった)。そんなことがあり、「サザエさん」は子供のころの教材であった。 もっとも、無垢な子供のころはなんでも教材になるものだ。 そういうわけで、Luceneの入門用プログラムにもサザエさんをコンテンツに選択する。サザエさんのコンテンツは、次のようなものである:
上記のように、contentsという文字列配列に、サザエさんファミリーの人間関係を表した短い文を設定している。ここではこのひとつひとつがドキュメントである。 ドキュメントは、全文検索の対象となるオブジェクトで、この例で言えばひとつの要素contents[i]がひとつのHTMLファイルなりPDFファイルの代わりである。 入門用プログラムなので、全文検索対象となるドキュメントは、HTMLやPDFではなくこのような簡単な文字列にしよう、ということだ。 上記のようなコンテンツに対し、検索質問の文字列も次のような文字列配列で用意する:
プログラムでは、contentsのドキュメントでインデックスを作成し、次に検索質問語であるqueriesの分だけforループをまわし、インデックスを検索する。 ではプログラムを紹介する前に、実行結果を先に見ておこう。それは、次のようになる:
実行結果は、queries[0]の"カツオ"を検索したときにcontents[]のドキュメントのうち6件がヒットし、その内容を表示している。以下、queries[1]の検索結果の表示、queries[2]の検索結果の表示、・・・と続く。 プログラムの全体は、次のようである:
プログラムのメインストリーム(main()の中)は、最初にmakeIndex()を呼んでインデックスを作成し、次にqueries[]の大きさだけforループをまわしてqueries[]要素を引数にしてsearchIndex()を呼んで検索を実行している。 makeIndex()では、IndexWriterのインスタンスを作成し、addDocument()でDocumentをインデックスに登録している。Documentはcontents[]の要素である。 FieldはDocumentを構成する要素で、ここでは次のようにDocumentにadd()している:
ここで、FIELD_CONTENTはフィールド名、contents[i]はフィールドの文字列である。Field.Store.YESはフィールドの文字列をインデックスに登録することを示し、Field.Index.TOKENIZEDはフィールド文字列をアナライザーで分析しながら単語を索引付けすることを示している。 searchIndex()では、IndexSearcherインスタンスを作成し、search()メソッドで全文検索を実行している。検索結果はHitsオブジェクトで返るので、ヒット件数(hits.length())とその内容を表示している。 2006.03.12 Sunday
郵便番号のインクリメンタルサーチのデモ
郵便局の「大口事業所等個別番号データ」を使った郵便番号のインクリメンタルサーチ(逐次検索)のデモを作成した。Flashのアニメーションを作成し、ViewletCentral.comにアップロードしたので、まずは次のURLをクリックして動作を見ていただきたい:
http://www.viewletcentral.com/vc/viewlet.html?id=51484175 環境は、サーバ側にTomcat+Lucene+DWR、クライアント側はAjax(というかJavaScriptか?)である。JavaScript側では、3文字以上郵便番号が入力されたらサーバに問い合わせるようになっており、サーバ側は問い合わせを受けたらIndexSearcherを使ってPrefixQueryで検索している。 今日は忙しいので、プログラムは整理して近日中に掲載したいと思う。 Lucene+Ajaxは検索の利便性向上に大いに貢献しそうだ。 2006.03.11 Saturday
情報処理学会 第68回全国大会
昨日工学院大学で行われた「情報処理学会 第68回全国大会」に行ってきた。
Lucene、Namazu、Senna、Estraier、Hyper Estraierの速度性能比較の実験の発表があるというので、Luceneコンサルタントとしては聴いておきたい発表である。 結果を先に述べると、500万件の文書数で、インデックス作成時間はLuceneは4位、検索時間は1位ということであった。 私は他の検索エンジン・検索ライブラリはよく知らないので、Luceneについてだけこの発表内容について簡単に考察を述べたいと思う。 この発表の中で、Luceneの計測に当たってはLuceneに付属のデモをJapaneseAnalyzerに置き換えて使用したとのことであった。したがって、IndexWriterには速度性能に影響が大きいパラメータを一切設定せずに行ったことになる。このパラメータは設定するだけでインデックス作成時間を2〜8倍も高速にするものであり、速度性能比較をするのであれば、必ず設定しなければならない重要なものである。もしこれを設定して計測していれば、Luceneはインデックス作成時間においても1位になったことは間違いない。しかしながら、他の検索エンジン・検索ライブラリにおいてもそのようなパラメータがあれば同様のことがいえるので、もしかしたら全体的にインデックス作成時間はもっと短くなったかもしれない。 Luceneのインデックス作成についてもう少し言及すれば、インデックス作成時のCPU使用率について触れられていなかったのが残念である。Luceneデモプログラムを使用したとのことであるから、おそらくCPU使用率はそれほどでもなかったのではないかと思われる。異なる製品同士の性能比較をするのであれば、その製品の可能性を最大限引き出した状態で比較しないとだめである。そうしなかった場合、その比較は「デフォルト状態の比較」という断りをいれないとフェアではないだろう。CPU使用率に戻ると、インデックス作成のようにI/Oが多く発生するプログラムでは性能が出るようにマルチスレッドで書くとか、CPUをアプリケーションが使い切るような書き方をしないとだめなのであって、Luceneはそのようなプログラムが書けるのであるから、Luceneはさらに速くなっていたに違いない。 次に検索についてであるが、一部の検索速度結果において、文書数が大きくなるほどLuceneはレスポンスが悪くなる場合がある、という発表であった。B-treeであることを考えると、なぜこのような結果になるのか考えていただくべきであった。検索に使用するIndexSearcherはキャッシュされるべきなのであって、プログラムの詳細を見てみなければわからないが、はたしてどうだったのか。 以上については、一部だけだが限られた質疑応答時間の中で指摘させていただいた。発表者は学生の方で、社会人コンサルタントがいじめたみたいになってしまったのは申し訳なかった。もちろん、そんなつもりは毛頭ないので、言ってみればLuceneは私にとって「わが弟です。息子です」という感情なので(ん〜、なんか聞いたことあるセリフ?)、いやメシの種なので、もっと速度性能はよいことを断っておく必要があったので勘弁してください。 速度性能を比較するというのはなかなか大変なテーマであり、それぞれのプロダクトについて深い洞察と経験がないと、簡単にはいかない。しかしながら今回はそれぞれのプロダクトのデフォルト状態での速度比較としてみれば十分ためになった発表であった。 2006.03.09 Thursday
Luceneスコアリングの大雑把な説明
Lucene scoring for Dummies!
1.検索質問語をなるべく多く含むFieldのDocumentがよいスコアを獲得する 2.検索質問語を繰り返し含むFieldのDocumentがよいスコアを獲得する 3.検索質問語の中でも希少語を含むFieldのDocumentがよいスコアを獲得する 4.検索質問語を同じように含む2つのDocumentがあるとき、Fieldの短いほうが長いほうよりもよりよいスコアを獲得する 1.、2.は言うまでもないだろう。検索質問語をなるべく多く、しかも繰り返し出現するFieldを持つDocumentが検索語を主題に述べているDocumentであることが期待できるからである。 3.はたとえばこういうことである。書籍を全文検索するシステムがあるとする。そこで、Javaのプログラミングに関する書籍を検索するために、次のように検索フィールドに入力する: Java プログラミング すると、(LuceneのQueryParserのデフォルトがORなので)Javaまたはプログラミングという単語を含むFieldのDocumentが検索される。その中には、Visual BasicやPHP、Perlなどのプログラミングに関する書籍も多数混じっており、Javaプログラミングの書籍はその中に埋没している状態だ。しかし、Javaとプログラミングという単語はJavaが希少語になり、プログラムを含むFieldのDocumentよりもJavaを含むFieldのDocumentがより高いスコアを獲得し、これによりVisual BasicやPHPのプログラミングの本よりもJavaが上位を獲得しやすくなる。 4.は長いFieldを持つDocumentよりも短いFieldのDocumentに検索質問語が含まれていれば、短いほうが長いほうよりも検索質問語を主題にした内容であることが期待できる、ということを考慮したものである。 2006.03.02 Thursday
Lucene 1.9リリース
Lucene 1.9がリリースされた。下記よりダウンロードできる:
http://www.apache.org/dyn/closer.cgi/lucene/java/ 先日発表のあった1.9 RC1からの変更点は: 1.不具合修正でIndexWriterのsetMaxBufferedDocs()メソッドにて1以下の数字を設定できなくなった。設定するとIllegalArgumentExceptionがスローされる。これは、1.4.3から1.9RC1の時に一時、「setMaxBufferedDocs(1)が思った効果が得られない」ことに対して不具合修正があったが、最終的にsetMaxBufferedDocs(1)はインデックス作成時によい性能を得られないと結論付けられ、同メソッドに1以下の数値を設定できないように戻された(revert)ものである。ちなみにこのメソッドは、インデックスに書き込むときのバッファ中のドキュメントの数を設定するもので、大きくするとインデックス作成の時間が短くなり、小さくするとインデックス更新がよりリアルタイムになる。 2.性能改善で、BufferedIndexOutput.writeBytes()メソッドにて1バイトずつのコピーの代わりにSystem.arraycopy()を使うようにした。 2006.03.02 Thursday
Ajaxを使ったLucene Javadocナビゲーションサイトの紹介
このカテゴリ"Luceneツール"では、Luceneに関連したツールを紹介していきたい。
その第一弾として、Lukeを紹介しようと思ったが、本日Luceneメーリングリストに流れていたAjaxを使ったJavadocのナビゲーションサイトを紹介することにした。 以下のリンクをクリックすると、JDK、J2EE、LuceneのJavadocのクラスのインクリメンタルサーチが行える: http://jdk.representqueens.com:9090/s/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 |