2017.12.15 Friday
スポンサーサイト
一定期間更新がないため広告を表示しています
| スポンサードリンク | - | | - | - |
関口宏司のLuceneブログOSS検索ライブラリのLuceneおよびそのサブプロジェクト(Solr/Tika/Mahoutなど)について
2006.02.27 Monday
Hitsクラス
HitsはIndexSearcherのsearch()メソッドを呼んで検索を行った結果を戻すために使われるクラスである。Hitsオブジェクトはイメージとしては検索にヒットしたすべてのDocument情報を保持する配列オブジェクトのようなもので、インタフェースだけを示せば、次のようになる:
length()メソッドはヒットしたドキュメントの件数を表す。id()、score()、doc()メソッドの引数には0〜length()-1の値を渡し、それぞれ、Documentの番号、スコアおよびDocumentオブジェクトを取得する。なお、この順番はスコアの高い順から取り出せるようにソートされている。iterator()メソッドはイテレータでHitsにアクセスするためのHitIteratorを返す。 Hitsの概観は上記のとおりだが、実際にはHitsオブジェクトは検索にヒットしたすべてのDocumentを保持してはおらず、次のようなHitDocクラスに検索にヒットした個々のDocumentの情報が入れられている:
上記の2つのHitDocクラスへのリファレンスを使って、一部のHitDocオブジェクトはLRUリストを構成している。また、すべてのHitDocオブジェクトはhitDocsという管理テーブルで管理されている。search()が実行された直後は最大100個のHitDocオブジェクトが生成される。このとき、HitDocオブジェクトのdoc変数はnullとなっており、Documentオブジェクトの情報はHitsオブジェクトには取り込まれていない。Hitsオブジェクトのdoc()メソッドが呼ばれると、初めてDocumentがインデックスから取得されてdoc変数に入れられる。同時にLRUリストの先頭に該当のHitDocオブジェクトがつながれる。 2006.02.27 Monday
Queryクラス
Queryクラスは検索質問を表現するクラスで、IndexSearcherのsearch()メソッドの引数にそのオブジェクトが渡されて検索を実行するために使われる。
Queryオブジェクトの作り方は、次の2通りがある: 1.プログラムでQueryクラスのサブクラスを使って作成 2.QueryParserを使って作成 1.はアプリケーションプログラムで、QueryクラスのサブクラスであるTermQueryやPhraseQueryなどのクラスのオブジェクトを生成する方法である。たとえば、フィールド名"content"のフィールドに"試験"という単語を含むDocumentを検索するためのQueryを取得するコードは、TermQueryを用いて次のようになる:
同様に、"国家試験"という単語を含むDocumentを検索するためのQueryを取得するコードは、上記の"試験"を"国家試験"に置き換えればよい・・・というのは誤りである(JapaneseAnalyzerを使用したと仮定して)。なぜなら、"国家試験"という語はJapaneseAnalyzerによって"国家"と"試験"という2つの単語に分割されるため、プログラムでQueryオブジェクトを作成する場合はTermQueryではなくPhraseQueryを使わなければならない。 ユーザの検索入力語をプログラムで判断しTermQueryやPhraseQueryを使い分ける、ということはできないので、通常は前記2.の方法を用いてQueryオブジェクトを取得する:
こうすると、queryには"国家"と"試験"という2つの単語からなるフレーズを検索するためのPhraseQueryによって作成されたQueryオブジェクトが代入される。 2006.02.27 Monday
IndexReaderクラス
IndexReaderクラスは、インデックスから単語や特定のDocumentを取得するのに使用する。さらに、(その名前から想像するのは困難だが)Documentを削除するのにもIndexReaderクラスは使用される。
IndexReaderを使用するために、staticのopen()メソッドを用いてIndexReaderインスタンスを取得する。 IndexReaderのメソッドは次の表のとおりである。
2006.02.26 Sunday
IndexWriterクラス
IndexWriterクラスはDocumentをインデックスに追加するのに使用する。
IndexWriterを使ってDocumentをインデックスに追加するには、次のような手順で行う。 1. IndexWriterのインスタンスを作成する。 2. IndexWriterのaddDocument()メソッドを使ってDocumentをインデックスに追加する。この操作はDocumentがあるだけ繰り返す。 3. IndexWriterをclose()する。 IndexWriterのインスタンスを作成するには、IndexWriterのコンストラクタを用いる。コンストラクタは3つの引数を取り、最初の引数にインデックスのディレクトリをDirectoryまたはディレクトリのFileやパスのStringで指定する。2番目の引数にはAnalyzerを指定する。ここで指定したAnalyzerは、Fieldのフィールド値を分析するとき(Field.Index.TOKENIZEDが指定されているとき)に使用される。3番目の引数にはインデックスを新規作成するか(true)、既存のインデックスにDocumentを追加するのか(false)を指定する。 IndexWriterをclose()する前に、インデックスの検索処理性能を維持するために、最適化を行っておくとよい。インデックスの最適化は簡単で、IndexWriterのoptimize()メソッドを呼び出すだけでよい。optimize()を呼び出すことで、最大マージドキュメント数を超えない範囲でセグメントファイルがマージされ、検索時のオープンしなければならないファイル数が小さく抑えられ、検索処理が高速になる。 2006.02.24 Friday
Fieldクラス
FieldはDocumentを構成する要素である。Documentインスタンスがドキュメントファイル全体を表すのに対し、Fieldインスタンスはドキュメントファイルの一部分を表す。
典型的なFieldは適当に名前付けされたフィールド名と、そのフィールド名に対応したドキュメントファイルから取り出されたテキスト文字列を保持する。 図にDocumentとFieldの関係を示す。FieldはDocumentのadd()メソッドでDocumentのインスタンスに追加される。また、Documentのインスタンスに属するFieldはfields()メソッドによりEnumeration型で取得できる。 2006.02.24 Friday
Documentクラス
Documentクラスは全文検索の対象となるドキュメントファイルを表現する(便宜上「ファイル」と呼んでいるが、必ずしもファイルである必要はない)。通常、Documentのひとつのインスタンスがひとつのドキュメントファイルを表す。その様子を示したのが図である。図では、ハードディスク(またはリモートのWebサーバから取得できるのでもよい)上にあるindex.htmlというドキュメントファイルがひとつのDocumentインスタンスに対応し、そのDocumentインスタンスがLuceneのインデックスに保存されていることを示している。
Documentのインスタンスの作成は、単純に次のようにコンストラクタを呼び出すだけである:
そして、実際のドキュメントファイルとDocumentインスタンスを関連付けるには、ドキュメントファイルから取り出したテキスト文字列でFieldのインスタンスを作成し、そのFieldのインスタンスをDocumentのadd()メソッドでDocumentに追加する。 2006.02.24 Friday
Directoryクラス
org.apache.lucene.storeパッケージのDirectoryはインデックスを格納する場所を表す抽象クラスである。同パッケージにはDirectoryの実装クラスであるFSDirectoryとRAMDirectoryがあり、それぞれ、インデックスをファイルシステム上に作る場合とRAM(ヒープメモリー)上に作る場合とで使い分けるようになっている。
FSDirectoryを使うためにFSDirectoryのインスタンスを取得するには、次のいずれかのstaticメソッドを用いる:
どちらのメソッドを使った場合でも、最初の引数にはインデックスのディレクトリを指定し、2番目の引数はインデックスを新規作成する(true)か既存のインデックスを使用する(false)かのbooleanを指定する。 RAMDirectoryはRAM(ヒープメモリー)上にインデックスを格納するときに使用するDirectoryである。ヒープメモリーにインデックスを格納するので、プログラムが終了するとせっかく作成したインデックスは消失してしまう。しかしながら、ファイルI/Oが発生するFSDirectoryよりも高速にインデックスの処理ができるので、工夫次第でいろいろな用途がある。 (RAMDirectoryの使用例) 1.テストプログラム 2.FSDirectoryをRAMDirectoryに読み込んで、RAMDirectory上で高速に検索 3.マルチスレッドプログラムで複数のRAMDirectory上にインデックスを作成し、最後にFSDirectoryにマージして、高速にインデックスを作成する RAMDirectoryのインスタンスを作成するには、次のように引数なしのコンストラクタを用いる:
RAMDirectoryはヒープメモリ上にインデックスを作成するため、FSDirectoryのインスタンスを作成した時のようにディレクトリパスなどを指定する引数は必要なく、また、常に新規作成となるため、createフラグもない。 前記使用例2.のようにRAMDirectoryを使う場合、既存のFSDirectoryのインデックスを読み込むために、RAMDirectoryのインスタンスを次のコンストラクタを使って取得する:
また、前記使用例3.を実行するには、IndexWriterのaddIndexes()メソッドを用いてRAMDirectoryのインデックスをFSDirectoryにマージする。 2006.02.24 Friday
CJKAnalyzerクラス
CJKAnalyzerは文章が分かち書きされない言語である中国語、日本語および韓国語向けに開発されたbi-gramのAnalyzerであり、文字列を2文字ずつの単語に分割する。隣り合った単語は、1文字ずつ重なるようにして切り出される。たとえば、「わが弟です」は「わが」「が弟」「弟で」「です」となる。「東京都」は「東京」と「京都」に単語分割されてしまうので、「東京」だけでなく「京都」という検索語でも「東京都」を含むドキュメントがヒットしてしまうという弊害がある。また、「都」や「区」などの一文字の検索語はヒットしにくい。JapaneseAnalyzerより優位な点は、辞書を必要としないため流行語に強いこと、速度面でも優位なことが上げられる。さらに、JapaneseAnalyzerが形態素解析できないために単語が長くなってしまいがちなフィールドがDocumentにある場合は、そのフィールドだけCJKAnalyzerを使うということも可能である。
スペースで分かち書きされる文章(英文など)を読み込んだ場合は、アルファベットの単語を認識してトークンとする。 CJKAnalyzerを使用するには、他のAnalyzerと同様、次のようにCJKAnalyzerのインスタンスを取得すればよい:
2006.02.24 Friday
JapaneseAnalyzerクラス
JapaneseAnalyzerはSen(http://ultimania.org/sen/)という形態素解析器を使って、辞書を用いて形態素解析を行い、日本語テキスト文字列から単語抽出を行うという、Lucene Analyzerのなかでも大変特殊な部類に入るAnalyzerであり、異彩を放っている。
JapaneseAnalyzerの使い方は他の多くのAnalyzerと同じように、デフォルトコンストラクタを次のように呼び出せばよい:
ただし、上記のように呼び出す前に、次のシステムプロパティが設定されている必要がある: ・sen.home sen.homeには通常、Senのインストールディレクトリを指定する。するとJapaneseAnalyzerは、sen.home/conf/sen.xmlというSenの設定ファイルを探して使用する。JapaneseAnalyzerのコンストラクタの引数にSenの設定ファイルのフルパスを指定することもでき、その場合はsen.homeのシステムプロパティの設定よりも優先される。 また、次のオプションのシステムプロパティも設定できる: ・org.apache.lucene.ja.config.file このシステムプロパティにはJapaneseAnalyzer自身の設定ファイルのパスを指定する(クラスパスからの相対指定)。指定しない場合のデフォルトは、JapaneseAnalyzerのパッケージと同じディレクトリにあるファイル(analyzer-sen.xml)が使われる。analyzer-sen.xmlで設定する情報は、次のようなものである: ・Tokenizerのクラス名(デフォルトはSenを使って単語抽出を行うSenTokenizer) ・ストップワードの単語のリスト ・単語抽出をする品詞のリスト 2006.02.23 Thursday
Lucene 1.9 RC1 リリース
Lucene 1.9 RC1がリリースされた。下記よりダウンロードできる:
http://www.apache.org/dyn/closer.cgi/lucene/java/ 前回のリリース1.4.3からパフォーマンス改善や不具合修正がなされている。RC1と謙虚だが、Luceneメーリングリストの情報を日々眺めている感じからすると、1.9 RC1の安定度はバツグンなので1.4.3ではなく1.9 RC1を使うべきだろう。 変更点の詳細は: http://svn.apache.org/viewcvs.cgi/*checkout*/lucene/java/branches/lucene_1_9/CHANGES.txt?rev=379190 1.9では数多のメソッドやクラスがdeprecatedとされており、これらdeprecated扱いになったものはLucene 2.0リリースからは削除される予定だ。そういうこともあるので、ぜひ早めに1.9への乗換えをすべきである。 |
+ 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 |