2017.12.15 Friday
スポンサーサイト
一定期間更新がないため広告を表示しています
| スポンサードリンク | - | | - | - |
関口宏司のLuceneブログOSS検索ライブラリのLuceneおよびそのサブプロジェクト(Solr/Tika/Mahoutなど)について
2008.11.30 Sunday
MemoryIndexを使う(初心者向き)
MemoryIndexは文字通り、メモリー上に持つインデックスである。おなじみのRAMDirectoryとの違いは、RAMDirectoryはLuceneのインデックスディレクトリであるDirectory抽象クラスのサブクラスであるのに対し、MemoryIndexはDirectoryファミリーとはまったく関係ない独立したクラスである。RAMDirectoryはFSDirectoryの代わりにIndexWriterやIndexReaderの引数に使用することができるが、MemoryIndexはそのような使い方ができない(ただし、MemoryIndexにはcreateSearcher()というメソッドがあり、それを使ってIndexSearcherを取得することができる)。
MemoryIndexが特別なのはそれだけではない。MemoryIndexはなんと、Documentがひとつだけしか入れられないのだ。Documentがひとつしか入れられないので、addDocument()というメソッドを持たず、addField()というメソッドを提供している。そしてsearch(Query)というメソッドを使ってfloatのスコアを返す。スコアが0以上であればクエリがヒットしたことがわかる。 MemoryIndexはどういう場面で使われるかというと、たとえば、ニュースサイトなどでユーザが好みのキーワードを登録しておき、そのキーワードがヒットする記事がアップされたことを通知するサービスを提供したいときなどが考えられる。 使い方を次に示す:
実行結果は次の通りとなる:
2008.11.26 Wednesday
Tokenがdeprecatedに!(2.9)
Lucene 2.9ではTokenクラスがdeprecatedとなる予定である。Tokenクラスには直前の単語からの位置増分、その単語の開始と終了位置、単語のタイプおよびPayloadという情報が入っている。TokenはReaderを入力とするTokenizerからTokenStreamが出力され、TokenStreamのnext()メソッドの呼び出しで取り出せるものである。
この状態だとLucene 3.0で目指しているFlexible Indexingと相性が良くない。もっと軽量のインデックスにしようとして単語の位置情報などを不要としても、AnalyzerのほうでTokenを出力している限り、不要な情報を出力するためにCPUが食われてしまうことになる。 そこでLucene 2.9ではTokenをdeprecatedとし、Tokenは単語のテキスト情報まで含めて属性の集合のような扱いにしよう、ということになった。 これまでの次のようなプログラムは:
(実行結果)
Lucene 2.9では次のようになる:
(実行結果)
2008.11.20 Thursday
boostをゼロにして検索すると・・・
次のようなラーメン店のデータがあり、フィールドshopに登録されるとする:
そして同じ文書の別フィールドwardに次のようにラーメン店の場所が登録されるとする:
ここで次のように「江東区または新宿区のラーメン店」を検索するQueryを作成して検索する:
取得したdocsを表示(スコアとDocument内容を整形して)すると、次のようになる:
上記のように「江東区」と「新宿区」ではDocument数が異なるために地域属性のIDFが違ってきてスコアが新宿が高くなってしまう。 地域のような属性フィールドではスコアを計算したくないとき、通常はFilterを使うことが考えられるが、Filterは場合によっては使いたくないときもあるだろう。 そんなときは、上記の検索式の地域属性の項のBOOSTを次のようにゼロに設定するとよい:
これで実行すると、次のように地域間でスコアの違いがなくなる:
2008.11.15 Saturday
Java 1.6.0_10でも直っていないという報告
Java 1.6.0_10で改修されたと見られていた現象がいまだ発生するという報告があった:
https://issues.apache.org/jira/browse/LUCENE-1342 すでにSunに報告済みでAcceptされているとのこと。非常にまれにしか発生せず、再現が難しいバグのようである。 2008.11.14 Friday
Lucene 2.4でバイナリデータがロストするバグ
Lucene 2.4でインデックスに登録したバイナリデータがロストするバグが報告され、早速対応された。Lucene 2.4.1と2.9で修正される:
https://issues.apache.org/jira/browse/LUCENE-1452 2008.11.13 Thursday
過去バージョンの単体テストを実行するAntターゲット(2.9)
現在のLucene trunkではLucene 2.9の開発が行われているが、「過去バージョンの単体テスト」を実行するAntターゲット"test-tag"が追加された。
次のように実行すると、現在のtrunkのディレクトリの下にtags/lucene_2_4_0/というディレクトリが作成されてそこにLucene 2.4の単体テストコードがダウンロードされ、Lucene 2.9のライブラリを使ってLucene 2.4.0のテストが実行される:
2008.11.01 Saturday
コミット時にユーザデータを書き込む(2.9)
Lucene 2.9からIndexWriterのcommit()メソッドにStringの引数が渡せるようになった。この引数は「ユーザデータ」と呼ばれ、コミット(Luceneでコミットといえば、segments_Nファイルを書き込むことである)時にsegments_Nファイルに書き込まれるものである。そのようにして書き込まれたユーザデータはIndexReaderのgetCommitUserData()メソッドで取得できる。
この説明だけで何に使うと便利なのか、ピンと来る人は少ないだろう。 この機能の提案者のやりたかったことは、「2つのインデックスが同じかどうか知りたい」というものであり、メーリングリストの議論によって行き着いたのが、前述のメソッド提供するというものである。 Lucene 2.3より、インデックスのマージはバックグラウンドスレッドで行われることがあり得る(デフォルトでバックグラウンドで実行される)ので、2つのインデックスに対し、同じ順番で同じドキュメントを追加していっても同じファイル構成になっているという保証がない。また、片一方でoptimize()を実行し、もう片一方では行わなかった場合、インデックスの内容が同じかどうかを比較するのは相当に困難で実行時間のかかるプログラムとなってしまう。 結局これを解決するにはLuceneではなくアプリケーションで「インデックスが同じであること」を保証するようにしなければならず、その目印としてコミット時に任意のユーザデータをインデックスに書き込めるようにしよう、となった。optimize()などによりマージが走ってもユーザデータは引き継がれるため、optimize()前後でも同一インデックスかどうかの確認がアプリケーションでとれる仕組みだ。 https://issues.apache.org/jira/browse/LUCENE-1382 |
+ 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 |