 インデックス http://opensedk.sourceforge.jp/pukiwiki.php?%A5%A4%A5%F3%A5%C7%A5%C3%A5%AF%A5%B9 [ リロード ]   [ 新規 | 編集 | 凍結解除 | 差分 | 添付 ]   [ トップ | 一覧 | 単語検索 | 最終更新 | バックアップ | ヘルプ ] --------------------------------------------------------------------------------最新の20件2005-09-16 コンテンツ管理システム RSS/1bの一部としてのkoike 2005-08-13 RSS/1の全体の構造 Open-SEDKプロジェクト 2005-08-07 分散サービスレジストリ 2005-07-31 開発ノート：他DSRのサービス検索 2005-07-12 ストレージシステム 2005-06-16 ConcreteInterfaceFactory SearchEngine 関連システムとの接続インターフェース 全文検索の仕組み サマリー(要約) ドキュメント インデックス 2005-06-11 全文検索システム 2005-06-08 CVSサーバー上のプロジェクト一覧 2005-05-15 提供パッケージの依存関係 2005-04-09 console/shell 2005-04-06 全文検索apサーバー'phalanx' 2005-04-03 testsite  全文検索システムインデックス スタブインターフェース インデクサの動作 インデックスファイルのフォーマット 索引語検索 転置インデックスインデックス全文検索をする前に、事前にインデックス(索引)を作成しておく必要があります。 koikeでは、インデックスファイルのフォーマットや種類について規定していませんので、どんなものでもかまいませんが、ここで説明するためにスタブで採用している方法を例とします。スタブ用のインデクサは、org.logical_paradox.koike.tools.IndexGeneratorです。このインデクサは、docs/stub/isys配下の*.txtを検索し、それぞれについてのインデックスを生成します。インデックスファイルは、data/stub/stub.indexとして記録されます。このファイルは、インデクサを稼動させるごとに毎回削除＆作成されます。data/stub/isys配下についてですが、この階層に対して更に「node0000n」というディレクトリが作成されており、その配下に実際のドキュメント(テキストファイル)が格納されています。 node0000nという名称のディレクトリは、ノードIDを示しています。RSS/1bは、ドキュメントを複数のサーバー(ノード)で管理するため、ドキュメントを特定する情報としてノードIDが必要になります。以降、「docs/stub/isys配下のディレクトリ」を「ノード」と表現し、「stub.index」を「インデックスファイル」と表記します。なお、ドキュメント(テキストファイル)やインデックスは全てUnicode big-endianで記録されています。↑スタブインターフェーススタブ用のインデクサといえども、インデックスシステムとドキュメント管理システムにアクセスするためのインターフェースが必要です。そこで、StubIndexAccessorとStubDocmentAccessorを作成しました。StubIndexAccessorは、インデックスファイルへの読み書きを担当しています。StubDocumentAccessorは、各ノードのドキュメントに対する読み込みを担当しています。これらのスタブインターフェースは、やはりスタブ用の接続インターフェースファクトリ(StubConcreteInterfaceFactory)で生成されるようになっています。↑インデクサの動作インデックスの生成を実行するには、IndexGenerator#execute()を実行します。このメソッドは、各ノードを検索し、格納されているドキュメントをn-gramで分割して索引語とし、インデックスファイルに格納します。n-gram分割の処理は、Parserクラスが担当します。スタブ用インデクサのデフォルトのn-gram長(索引語長)は2です。現在のところ、Parserクラスではn-gram長を可変にすることはできません。Parserクラスは、2-gramに分割した索引語をTermクラスの配列の形で返します。インデクサは、Termクラスの配列をスタブ用IndexAccessorに対して引渡し、インデックスファイルに登録します。↑インデックスファイルのフォーマットインデックスファイルは、java標準のpropertiesファイルの形式で格納されます。キーとして索引語、値として索引語の出現位置情報のカンマ区切りとなっています。テキストエディタ等で開くことができますので、確認してください。位置情報は次のフォーマットで記録されます："ノードID":"ドキュメント番号":"先頭からのオフセット(単位:文字数)"この3項目を1セットとし、カンマ区切りで連結しています。このインデックスファイルは、java.util.Propertiesクラスのload()メソッドで読み込むことができます。↑索引語検索既に説明した通り、インデックスファイルはjava.util.Propertiesクラスで読むことができますので、検索時はPropertiesクラスで読み込んでおきます。索引語はプロパティのキーとして扱われていますから、索引語の位置情報が要求された場合には、Properties#get()で位置情報が取得できます。StubIndexAccessorでは、取得できた位置情報をKoikeIndexResultSetクラスに変換して返します。IndexAccessorは、索引語の位置情報が要求された際、検索結果としてKoikeIndexResultSetを返さなければならないためです。↑転置インデックスKoikeIndexResultSetは、ある索引語に対する検索結果を、転置インデックスのリストとそれに付随する位置情報のリストの形式で格納しています。FTSの際、転置インデックスはlong型で、LSBからMSBに向けて1ドキュメント/1bitのon/offで表現していましたが、RSS/1bの場合、かなり大量のドキュメントを管理することが予想されるため、全てのドキュメントのon/offを管理することは困難です。そのため、1ブロック=64bit(long型)とし、ドキュメントを含むブロックのみをリスト化することで省サイズ化しています。全体のドキュメント数が100,000,000(1億)であったとすると、1億bitのうち必要な部分だけ64bit単位で抽出してリスト化しているイメージです。1億のドキュメント全てに索引語が含まれていると仮定すると、リストのサイズは1,562,500(約156万)です。ドキュメント番号1とドキュメント番号128に索引語が存在する場合、ブロックのリストは2件になります。ブロックのリストの内容は、InvertedIndexクラスです。InvertedIndexクラスには、64個のドキュメントのどれに索引語が含まれているかという情報(documents)、InvertedIndexがどのブロックを管理しているかという情報(blockno)、該当ブロック中の位置情報のリスト(locationMap)などが含まれています。2つの索引語の両方が含まれているドキュメントを探す場合、ノードIDとブロック番号の一致する転置インデックスを取得して、documents値のandをとるとわかります。 --------------------------------------------------------------------------------                       Last-modified: Thu, 16 Jun 2005 22:20:24 JST (100d)Modified by me "PukiWiki" 1.4.3 Copyright © 2001,2002,2003 PukiWiki Developers Team. License is GNU/GPL.Based on "PukiWiki" 1.3 by sng Powered by PHP 4.3.10-16 HTML convert time to 0.261 sec. 