JP2008305352A - 全文検索システム - Google Patents

Abstract

【課題】クロール時間の短縮。
【解決手段】システムは、電子文書が蓄積されたＳＭＢサーバ１と、文書の新規作成，削除，部分的な変更の入力、検索対象文書のインデクスを入力するＰＣ２と、索引用インデクスを作成し、作成したインデクスを格納するＰＣ３と、ＰＣ３で作成されたインデクスを格納するＰＣ４と、これらの間を接続する通信路６とを備え、ＰＣ２からサーバ１へアクセスされる情報のうちから、電子文書の新規作成，削除，部分的な変更に関連する更新候補情報を抽出して、格納するＰＣ２０を備えている。ＰＣ３は、インデクスを最初に作成する際にのみ、サーバ１を全体走査し、インデクスの新規作成，部分的な変更および削除に伴う更新は、ＰＣ２０に格納されている更新候補情報に基づいて、サーバ１を照査して、新規作成，削除，部分的な変更が実際に行われた更新実行情報を抽出し、これに基づいてインデクスの更新を行う。
【選択図】図１

Description

この発明は、全文検索システムに関し、特に、全文検索におけるインデクスの更新に関するものであり、大量のテキストデータ群を対象に任意のキーワードを含むデータを探し出す際に用いられ、特に、企業や官公庁など組織内でファイルサーバに蓄積される電子文書（プレーンテキスト、ＨＴＭＬ、Ｗｏｒｄ、Ｅｘｃｅｌ、Ｐｏｗｅｒｐｏｉｎｔ、ＰＤＦなどオフィス系のフォーマット）を組織のメンバが、必要な電子文書をいつでも探し出せるようにする検索エンジンで使われる。本発明は、特に、検索対象となるデータ数が数Ｔ（テラ）クラス以上の大規模ストレッジで顕著な効果を発揮する。大量のテキストデータ群を高速に検索する手法として「転置ファイル法（Ｉｎｖｅｒｔｅｄ ｆｉｌｅ ｉｎｄｅｘｉｎｇ）」が知られており、本発明は、転置ファイル法に代表される「インデクス」を作成するタイプの検索技術にかかわるものである。

大量のテキストデータ群を高速に検索する方法として、転置ファイル法が知られている。この転置ファイル法は、技術文献１にその詳細が説明されているように、各索引語が出現する文書や文書内での出現位置情報を転置ファイルと呼ばれる表構造の索引に格納し、検索時には、この転置ファイルのみにアクセスして、単語を検索する方法である。図６は、転置ファイル法を用いた企業内検索向け検索システムの代表的な構成例を示している。

同図に示した検索システムでは、検索対象となるのがストレッジを持ったＳＭＢサーバ群であり、ここに各種の電子文章がプレーンテキスト、ＨＴＭＬ、Ｗｏｒｄ、Ｅｘｃｅｌ、Ｐｏｗｅｒｐｏｉｎｔ、ＰＤＦなどオフィス系のフォーマットに格納される。

ここで、ＳＭＢサーバとは、マイクロソフト社がファイルアクセスのためのプロトコルとして採用しているＳＭＢ（あるいはＣＩＦＳ）プロトコルによりアクセス可能なファイルサーバである。クライアントＰＣは、組織内の各自が使用するＰＣ、あるいは、特定アプリケーションを実行させるＰＣである。

インデクサ用ＰＣは、転置ファイル法を実現する上で検索対象ファイルのデータからインバーテッドインデクス（以下インデクス）を生成したり、検索対象ファイルのデータの更新（新規作成，部分的な変更，削除）に合わせてインデクスを更新する。

対象となるファイルが大規模な場合には、インデクスの生成や更新を分担して行うために複数のインデクサ用ＰＣが用意される。検索用ＰＣは、インデクサ用ＰＣが生成したインデクスを用いて全文検索サービスを提供する。クライアントＰＣから発行された検索条件に対して検索した結果を返す。

インデクサ用ＰＣでは、図７に示す２種類のプログラムが動作する。ファイルサーバ用クローラとインデクサである。

ファイルサーバ用クローラが、検索対象ファイルを格納するＳＭＢサーバ群の全ファイルを最初全て収集し、インデクサの入力としインデクスを作成する（インデクサ全更新機能）。図７の左側に、１つのＳＭＢサーバのファイル構造の詳細が示されている。

その際に、収集したファイルの一覧をファイルの更新時間（タイムスタンプ）と合わせてタイムスタンプリストとして保存する。図７では、２００７年３月２０日２３時３０分００秒に作成したタイムスタンプリストを同図（ｂ）に一覧表として示している。

２回目以降のクローリングでは、ファイルサーバ用クローラは、ＳＭＢサーバ内の全ファイルについてタイムスタンプを確認し、新しいタイムスタンプリストを作成する。図７では、前回から１日経過した２００７年３月２１日２３時３０分００秒に作成したタイムスタンプリストを同図（ｃ）に一覧表として示している。

次に、今回の収集により作成したリスト（ｃ）と、前回収集したリスト（ｂ）と照らし合わせる。照らし合わせた結果、新たに追加されたファイル、更新されたファイル、削除されたファイルを見つけ出し、差分リスト（ｄ）を作成する。

差分リスト（ｄ）には、変化のあったファイルについて、それが新たに追加されたファイル（Ｎｅｗ）なのか、更新されたファイル（Ｕｐｄａｔｅ）なのか、削除されたファイル（Ｄｅｌｅｔｅ）なのかを示す印とともに、フアイルのパスとタイムスタンプが列挙される。

その結果「新たに追加されたファイル」と「更新されたファイル」は、クローラによりファイルの本体を収集する。収集したファイルと差分リストを用いて、それまでに使われてきたインデクスを更新する。

しかしながら、このような従来の全文検索システムには、特に、インデクスを更新する際に、以下に説明する技術的な課題があった。

北研二 他著、「情報検索技術」２００５年１１月２０日北立出版発行 ｐｐ．１６０−１７９ 第６章６．２ 「転置ファイルを用いた全文検索」

すなわち、図６に示した従来の全文検索システムでは、検索対象となるストレッジの大規模化に対応が困雄になるという問題と、クローリングに時間がかかるという問題があった。

その理由は、上述したシステムでは、インデクスを更新するために毎回全ての検索対象ファイル群をクローリングしてタイムスタンプを確認しなくてはならないため、この処理がＳＭＢサーバの持つストレッジのサイズに比例して時間がかかり、非就業中の夜中のうちに昨日の変化分を処理できないことも起き得る。 ここで、クローリング時間を短縮するためには、複数のインデクサ用ＰＣから異なるストレッジに分散して、複数スレッドにてクローリングすることで対処できるが、この方法では、本来のアプリケーションの処理に使われるべきストレッジの処理能力を、クローリングのために使ってしまうことになり、システム全体のパフォーマンスが低下することになる。

さらに、上記システムでは、全てのファイルをクローリングして初めて更新を行うことになるために、更新状況を即時にインデクスに反映することが困難になり、タイムリーな更新ができないという問題があった。

本発明は、このような従来の問題点に鑑みてなされたものであって、その目的とするところは、検索対象ストレッジの大規模化に容易に対応することができるとともに、ファイルサーバの負荷を増加することなく、クローリング時間の短縮化して、短時間にインデクスに反映することができる全文検索システムを提供することにある。

上記目的を達成するために、本発明は、検索対象となる電子文書が蓄積されたデータベースを有するファイルサーバ群と、前記電子文書の新規作成，削除，部分的な変更を入力するとともに、検索対象文書のインデクスを入力するクライアントＰＣ群と、前記ファイルサーバ群の前記電子文書を照査して、当該電子文書に含まれている文言の索引用インデクスを作成するとともに、作成したインデクスを格納するインデクスデータベースを有するインデクサ用ＰＣ群と、前記インデクサ用ＰＣ群で作成されたインデクスを格納する検索用ＰＣとを有し、前記ファイルサーバ群，クライアントＰＣ群，インデクサ用ＰＣ群，検索用ＰＣの間のそれぞれがスイッチイングハブを介して接続される通信路とを備え、任意のクライアントＰＣから入力された検索対象インデクスに基づいて、前記検索用ＰＣから前記検索対象インデクスに該当するインデクスを抽出して、当該クライアントＰＣに出力する全文検索システムにおいて、前記クライアントＰＣ群から前記ファイルサーバ群へアクセスされる情報のうちから、前記前記電子文書の新規作成，削除，部分的な変更に関連する更新候補情報を抽出して、格納するキャプチャ用ＰＣを備え、前記インデクサ用ＰＣ群は、前記インデクスを最初に作成する際にのみ、前記ファイルサーバ群を全体走査し、前記インデクスの新規作成，部分的な変更および削除に伴う更新は、前記キャプチャＰＣに格納されている前記更新候補情報に基づいて、前記ファイルサーバ群を照査して、新規作成，削除，部分的な変更が実際に行われた更新実行情報を抽出し、当該更新実行情報に基づいて前記インデクスの更新を行うようにした。

このように構成した全文検索システムでは、ファイルサーバ群（ストレッジ）へのアクセスをイベントとして捕らえる。本発明では、毎回全ファイルをクロール（走査）することはしないで、最初の１回だけ全ファイルをクロールしてインデクスを作成し、２回目からは、ファイルに対するアクセス（新規作成、部分的な更新、削除、アクセス権の変更）をイベントとして捕らえ、各イベントの対象となったファイルのみインデクス更新の対象とする。

このため、更新の度ごとに全ファイルをクロールする従来の方式に対して、クローリング時間の大幅な短縮化が可能になり、ストレッジの大規模化も簡単に対応することができ、しかも、このような効果は、アプリケーションの処理に使われるべきストレッジの処理能力を、クローリングのために消費することなく得られるので、システム全体のパフォーマンスの低下を回避することができ、さらには、更新状況を即時にインデクスに反映することが可能になり、タイムリーな更新をも可能にする。

前記更新候補情報は、前記通信路から取得することができる。

また、前記更新候補情報は、前記クライアントＰＣ群から前記ファイルサーバ群へアクセスされた情報が、前記ファイルサーバ群に残されているアクセルログから取得することができる。

前記キャプチャ用ＰＣは、前記通信路に設置されたタップを介して、前記クライアントＰＣ群から前記ファイルサーバ群へアクセスされる情報を取得して、前記更新候補情報を抽出するパケット判別モジュールと、前記更新候補情報を格納するパケトログと、前記判別モジュールの制御用ファイルとを有することができる。

前記インデクスには、前記検索対象となる電子文書へのアクセス権の作成、および、同アクセス権の新規作成，削除，部分的な変更などの更新情報を含ませることができる。

本発明に係る全文検索システムによれば、クローリング時間の大幅な短縮化が可能になり、ストレッジの大規模化も簡単に達成することができ、しかも、このような効果は、アプリケーションの処理に使われるべきストレッジの処理能力を、クローリングのために消費することなく得られるので、システム全体のパフォーマンスの低下を回避することができ、さらには、更新状況を即時にインデクスに反映することが可能になり、タイムリーな更新をも可能にする。

以下に、本発明を実施するための最良の形態を実施例に基づいて説明する。図１から図３は、本発明に係る全文検索システムの一実施例を示している。図１は、システムの全体構成図である。本実施例の全文検索システムは、ＳＭＢサーバ１と、クライアントＰＣ２と、インデクサ用ＰＣ３と、検索用ＰＣ４と、スイッチングハブ５を備えた通信路６を備えている。

ＳＭＢサーバ１は、複数がスイッチングハブ５に並列接続されていて、これらがファイルサーバ群を構成している。各ＳＭＢサーバ１には、検索対象となる電子文書が蓄積されたデータベース７と、自サイトにアクセスされた文書の名前や時間，数などを記憶しておくアクセルログ８を有している。具体的には、ストレッジを持ったＷｉｎｄｏｗｓ ＳｅｒｖｅｒやＳａｍｂａサーバ、あるいはＮＡＳ（Ｎｅｔｗｏｒｋ Ａｔｔａｃｈｅｄ Ｓｔｏｒａｇｅ）がこれに相当する。

クライアントＰＣ２は、複数がスイッチングハブ５に並列接続されていて、これらがクライアントＰＣ群を構成しており、ＳＭＢサーバ１に格納する文書の新規作成，削除，部分的な変更を入力し、ＳＭＢサーバ１上のデータを操作するアプリケーションブログラムを実行するとともに、検索対象文書のインデクスが入力される。

インデクサ用ＰＣ３は、複数がスイッチングハブ５に並列接続されていて、これらがインデクサ用ＰＣ群を構成している。各インデクサ用ＰＣ３には、インデクスを格納するインデクスＤＢ９を有している。

インデクサ用ＰＣ３は、ファイルサーバ群（ＳＭＢサーバ１群）の電子文書（デレクトリとファイル）を巡回走査して、検索対象となるファイルの属性（更新日時、アクセス権、ファイルの種別）を読み出す。ファイルの属性からインデクスの作成に必要なファイルを読み出す。これらを用いて検索用のインデクスを作成する。

検索用ＰＣ４は、各インデクサ用ＰＣ３で作成されたインデクスのコピーを格納するデータベース１０を有しており、これを用いて検索処理機能を提供する。インデクスのコピーは、インデクサ用ＰＣ３が新規の更新を終わるごとに作られ、それまで使っていた古いインデクスと交換される。

スイッチングハブ５を備えた通信路６は、ギガビットイーサーなどのＰＣ間通信路であって、例えば、企業などで採用されているイントラネットがこれに相当する。このような検索システムでは、任意のクライアントＰＣ２から入力された検索対象インデクスに基づいて、検索用ＰＣ４から検索対象インデクスに該当するインデクスを抽出して、当該クライアントＰＣ２に出力することになる。

以上のような全文検索システムとしての基本的な構成は、前述した従来のシステムと相違はないが、本実施例の全文検索システムは、以下に説明する点に顕著な特徴がある。

すなわち、本実施例の場合には、クライアントＰＣ２群からＳＭＢサーバ１群（ファイルサーバ群）へアクセスされる情報のうちから、電子文書の新規作成，削除，部分的な変更に関連する更新候補情報を抽出して、格納するキャプチャ用ＰＣ２０を備えている。

キャプチャ用ＰＣ２０は、タップ２１を介して通信路６に接続されている。タップ２１は、通信路６に影響を与えることなく、通信路６を通過するパケットを取り出すための機器であり、例えば、シスコムｅｔｈｅｒｇａｚｅｒ１０００（市販商品名）を用いることができる。

また、キャプチャ用ＰＣ２０には、ネットワークインターフェイス２０ａ，トランスポート層２０ｂ，パケットフィルタ２０ｃ，パケット判別モジュール２０ｄ，キャプチャ制御用ファイル２０ｅ，メモリ領域２０ｆ，パケットログ２０ｇを備えている。

このように構成されたキャプチャ用ＰＣ２０では、タップ２１で取り出した通信パケットを解析し、ＳＭＢサーバ１上のファイルに対する操作（その中でも検索用インデクスの更新に関連するもの）履歴をアクセスパケットとしてパケットログ２０ｇに出力する。 タップ２１と繋がるポートは、パケットの受信専用であるが、図１の右側のスイッチングハブ５に繋がるポートには、ＩＰアドレスを割り当て、インデクサ用ＰＣ３と通信可能とする。より具体的には、スイッチングハブ５とキャプチャ用ＰＣ２０のオペレーティングシステム２０ｈとを介して、パケットログ２０ｇにアクセス可能になっていて、この機能が実現される。 これにより、アクセスパケットログ２０ｇは、インデクサ用ＰＣ３からこの通信経路を介して、参照できるようになっている。キャプチャ用ＰＣ２０には、キャプチャ（抽出）しないＩＰアドレスの一覧を予め設定しておくことができる。

キャプチャするのは、クライアントＰＣ２からＳＭＢサーバ１上のファイル操作を行っているパケットに限られる。従って、インデクサ用ＰＣ３によるクローリング（走査）のためのパケットなどを抽出することがないようにしておく必要があるので、キャプチャの対象外とすべきＩＰアドレスを設定できるようにしておく。

ここで、キャプチャ対象とすべきパケットの情報は、ログとしてファイルに出力される前にまずメモリ（メモリ領域２０ｆ）上に格納され、複数まとめてファイル出力するようになっている。

これは、ファイルアクセスの性能を向上させる目的と、メモリ上で「同一ファイルやディレクトリに対する同一アクセスのログを一つにまとめる」処理を行うためである。この際にメモリ上に格納するログ数の上限を、実際に使うサーバのメモリ量に合せて設定できるようにする。

ログファイル（パケットログ２０ｆ）に出力する間隔の最長時間は、以下のように設定する。メモリ上に格納されたログが、ある一定時間たった場合、「ログ数上限」に達しなくても強制的にログファイルに吐き出させるため、出力する間隔の最長時間を設定する。

パケット判別モジュール２０ｄでは、電子文書の新規作成，削除，部分的な変更に関連する更新候補情報の抽出が、以下の記号とフォーマットによりどのアクセスが行われたかが判別される。
Ｔ（パス名）←タッチ：そのファイルやディレクトリに触れた
Ｄ（パス名）← 削除：そのファイルやディレクトリを削除した
Ｒ（パス名，ｏｌｄ）（パス名，ｎｅｗ）← ファイル名やディレクトリ名を変更した
Ｍ（パス名，ｏｌｄ）（パス名，ｎｅｗ）← ファイルやデイレクトを移動した

すなわち、本実施例の場合、電子文書の新規作成，削除，部分的な変更に関連する更新候補情報として、Ｔ（タッチ），Ｄ（削除），Ｒ（ｏｌｄ，ｎｅｗ），Ｍ（ｏｌｄ，ｎｅｗ）が抽出されることになる。

インデクサ用ＰＣ３は、インデクスを最初に作成する際にのみ、ＳＭＢサーバ１群（ファイルサーバ群）を全体走査する。すなわち、一番最初にインデクスを作成するときには、検索対象となる全てのファイルを基点リスト（「ファイル巡回」＆「インデクス」制御ファイル内で定義）からたどり、ファイル属性を読み出しタイムスダンプリストをつくる。
またその際に列挙した全ての検索対象ファイルをインデクサ用ＰＣに読み出す。これらを用いてインデクスを作成する。なお、インデクサ用ＰＣ３は、負荷分散によるインデクス作成／更新時間の短縮のために複数の存在が可能であり、各インデクサＰＣ３に走査対象となるＳＭＢサーバ１を割り当てればよい。

また、「ファイル巡回」＆「インデクス」制御ファイルには、インデクサ用ＰＣ３における処理の設定を可能にするために、以下の内容を含む。
・基点リスト ツリー型のディレクトリ構造を持ったファイル
システム内を巡回する基点となるパス名の列
・検索非対称パス列 基点リストからツリーを巡る際に「その部分だけは検索対象にしない」パス列
・検索対象サフィックス ｔｘｔ，ｈｔｍ，ｈｔｍｌ，ｐｄｆなど検索対象とするファイルのサフィクス列
・ログ確認周期
キャプチャ用ＰＣ２０の出力する「アクセスパケットログ」を確認する周期

一方、インデクサ用ＰＣ３は、インデクスの新規作成，部分的な変更および削除に伴う更新は、キャプチャＰＣ２０に格納されている更新候補情報に基づいて、ＳＭＢサーバ１群を照査して、新規作成，削除，部分的な変更が実際に行われた更新実行情報に基づいてインデクスの更新を行う。

以上のより具体的な手順について、図２および３を参照にして説明する。図２は、キャプチャ用ＰＣ２０による更新候補情報を取得する手順が示されている。 クライアントＰＣ２において、アプリケーション（ワープロ、スプレッドシート、等々）からネットワークファイルアクセスが発生した場合に、まずファイル共有サービス層（Ｗｉｎｄｏｗｓ システムの場合にはＳＭＢあるいはＣＩＦＳと呼ばれるプロトコルが使われる）を経由し、ネットワークの通信プロトコルをサポートするトランスポート層を経由しＴＣＰ／ＩＰの規約に従ったパケットが作られ、ネットワークインターフェイス２０ａで物理的なネットワークアクセスがなされる。

ＳＭＢサーバ１は、この逆の順序で各層にて処理が行われファイル共有サービスがＳＭＢサーバ１に接続されているディスクに対応する処理を行う。このようなネットワーク経由のファイルアクセスが行われている状況において、キャプチャ用ＰＣ２０は、タップ２１を使い、ネットワーク上を流れるパケットをキャプチャする。

キャプチャ用ＰＣ２０の内部においてネットワークインターフェイス層およびトランスポート層は、オペレーティングシステム（ＷｉｎｄｏｗｓサーバＯＳなど）の機能が使われる。そこからパケットを選別して取組むためのパケットフィルタ２０ｃとしては、１ｉｂｃａｐのような標準品を用いる。パケットフィルタ２０ｃにおいて、ＳＭＢ／ＣＩＦＳに関連するパケットに絞って取り込むためにＴＣＰポート４４５番だけを取り出すように設定する。

これを図２に基づいて具体的に説明すると、手順がスタートすると、ｓ１で、パケットフィルタ２０ｃを用い、ネットワーク（通信路６）からパケットが抽出される。

次いで、ｓ２で、抽出したパケットのＩＰアドレスが、インデクサ用ＰＣ３のものか、否か判断され、インデクサ用ＰＣ３のものでなければ、ｓ３に移行する。ｓ３では、抽出したパケットの処理がＳＭＢ／ＣＩＦＳに関連するものか、否かが判断され、これがＳＭＢ／ＣＩＦＳに関連するものであれば、ｓ４が実行される。

ｓ４では、パケット判断モジュール２０ｄにより、ＳＭＢプロトコルとして、前述したＴ（タッチ），Ｄ（削除），Ｒ（変更），Ｍ（移動）であれば、これらが抽出され更新候補情報として、処理を表す記号と処理対象（ファイル，フォルダ）をメモリ領域２０ｆに記録する。

続くｓ５では、メモリ領域２０ｆで、同一の対象に同一の処理を施すものは、複数残さず、単一にする処理が行われる。次のｓ６では、メモリ領域２０ｆ上の記録が、メモリ上に格納するログ数の条件を越えたか否かが判断され、これが超えている場合には、ｓ７で、メモリ領域２０ｆ上の全記録をパケットログ２０ｇに出力して、ここに格納する。

ｓ６で、メモリ領域２０ｆ上の記録が、メモリ上に格納するログ数の条件を越えていないと判断された場合には、ｓ８で、メモリ領域２０ｆ上の記録が１つ以上あって、前回ログ出力して以来「パケットログ２０ｇに出力する間隔時間が最長時間を超えたか否かが判断され、越えている場合には、ｓ７に移行して、メモリ領域２０ｆ上の全記録をパケットログ２０ｇに出力して、ここに格納する。

一方、ｓ８で、バケットログ２０ｇに出力する間隔時間が最長時間を超えていないと判断されると、ｓ１に戻って処理が続行される。なお、ｓ２で、抽出したパケットのＩＰアドレスが、インデクサ用ＰＣ３のものであると判断された場合と、ｓ３で、抽出したパケットの処理がＳＭＢ／ＣＩＦＳに関連するものでないと判断された場合には、ｓ８に移行する。

以上のような手順を順次実行することにより、キャプチャＰＣ２０のパケットログ２０ｇには、更新候補情報として、Ｔ（タッチ），Ｄ（削除），Ｒ（変更），Ｍ（移動）と処理対象（ファイル，フォルダ）とが蓄積されることになる。 このようにしてパケットログ２０ｇに蓄積された更新候補情報は、インデクサ用ＰＣ３から定期的ないしは不定期に読まれて、インデクスの更新に使用される。この際には、インデクスの新規作成，部分的な変更および削除に伴う更新は、更新候補情報に基づいて、ＳＭＢサーバ１群を照査して、新規作成，削除，部分的な変更が実際に行われた更新実行情報を抽出し、この更新実行情報に基づいてインデクスの更新が行われる。

この際に行われる具体的な手順を図３に示している。なお、図３に示した手順では、初回にインデクサＰＣ３で全ＳＭＢサーバ１を走査して、インデクスを作成するステップを含んでいる。

同図に示した手順がスタートすると、まず、ｓ１０で、検索対象とする全ファイル（全ＳＭＢサーバ１群のファイル）を「ファイル巡回」で取得し、インデクスを作成する（最初ないしは初回だけ）。作成したインデクスは、データベース９に格納する。同時にタイムスタンプリストを作成する。

続くｓ１１では、ファイルアクセルパケツトログ２０ｇが新規に追加されたか否かが判断され、新規に追加されたと判断された場合には、ｓ１２に移行する。ｓ１２では、新規に追加されたアクセスログの内容を参照して、対象となるファイル，フォルダおよびフォルダ下の全ファイルを巡回し、変化があった対象を差分リストとして出力する。また、タイムスタンプリストをこの差分リストで更新する。

続くｓ１３では、巡回の結果、実際に、新規追加，削除および変更のあったファイル情報を取得し、差分リストと合わせて実際に新規追加，削除および変更のあった更新実行情報に基づいて、インデクスを更新する。次のｓ１４では、一定時間待機して、ｓ１１に戻ることになる。また、ｓ１１で、パケットログに新規追加がないと判断された場合も、ｓ１４の一定時間の待機を経てｓ１１に戻ることになる。

さて、以上のように構成した全文検索システムによれば、クライアントＰＣ２群からＳＭＢサーバ１群（ファイルサーバ群）へアクセスされる情報のうちから、電子文書の新規作成，削除，部分的な変更に関連する更新候補情報を抽出して、格納するキャプチャ用ＰＣ２０を備え、インデクサ用ＰＣ３群は、インデクスを最初に作成する際にのみ、ＳＭＢサーバ１群（ファイルサーバ群）を全体走査し、インデクスの新規作成，部分的な変更および削除に伴う更新は、キャプチャＰＣ２０に格納されている更新候補情報に基づいて、ＳＭＢサーバ１群（ファイルサーバ群）を照査して、新規作成，削除，部分的な変更が実際に行われた更新実行情報を抽出し、当該更新実行情報に基づいてインデクスの更新を行うようにした。

このため、更新の度ごとに全ファイルをクロールする従来の方式に対して、クローリング時間の大幅な短縮化が可能になり、ストレッジの大規模化も簡単に達成することができ、しかも、このような効果は、アプリケーションの処理に使われるべきストレッジの処理能力を、クローリングのために消費することなく得られるので、システム全体のパフォーマンスの低下を回避することができ、さらには、更新状況を即時にインデクスに反映することが困難になり、タイムリーな更新をも可能にする。

なお、上記実施例で示したインデクスの作成および更新には、電子文書だけでなく、検索対象となる電子文書へのアクセス権の作成、および、同アクセス権の新規作成，削除，部分的な変更などの更新情報を含ませることができる。

また、上記実施例で示した更新候補情報は、通信路６からタップ２１を介して取得すること以外に、ＳＭＢサーバ１のログ出力（図１に示したアクセスログ８）から抽出することができる。 図４，５は、ＳＭＢサーバ１のログ出力から更新候補情報を抽出する場合の実施例を示しており、この実施例においては、上記実施例と同一もしくは相当する部分に同一符号を付して、その説明を省略するとともに、以下にその特徴点についてのみ説明する。

図４は、この実施例に係る全文検索システムの全体構成を示しており、この実施例では、クライアントＰＣ２群からＳＭＢサーバ１群（ファイルサーバ群）へアクセスされる情報のうちから、電子文書の新規作成，削除，部分的な変更に関連する更新候補情報を抽出して、格納するキャプチャ用ＰＣ２０に替えて、ほぼ同一機能を有するログ収集用ＰＣ３０を備えている。

ログ収集用ＰＣ３０は、ＳＭＢサーバ１群が並列接続されたスイッチングハブ５に電気的に接続され、ログ収集ルーチン３０ａと、アクセルログフィルタ３０ｂと、ログ判定モジュール３０ｃと、メモリ領域３０ｄと、パケットログファイル３０ｅとを備えている。

このように構成されたログ収集用ＰＣ３０では、ログ収集ルーチン３０ａで収集した情報は、アクセルログフィルタ３０ｂとログ判別モジュール３０ｃとにより判別されて、電子文書の新規作成，削除，部分的な変更に関連する更新候補情報の抽出が行われる。

ここで、キャプチャ対象とすべき情報は、ログとしてファイルに出力される前にまずメモリ（メモリ領域２０ｆ）上に格納され、複数まとめてファイル出力するようになっている。

これは、上記実施例で説明したように、ファイルアクセスの性能を向上させる目的と、メモリ上で「同一ファイルやディレクトリに対する同一アクセスのログを一つにまとめる」処理を行うためである。この際にメモリ上に格納するログ数の上限を、実際に使うサーバのメモリ量に合せて設定できるようにする。

ログファイル（パケットログファイル３０ｅ）に出力する間隔の最長時間は、以下のように設定する。メモリ上に格納されたログが、ある一定時間たった場合、「ログ数上限」に達しなくても強制的にログファイルに吐き出させるため、出力する間隔の最長時間を設定する。

本実施例においても、上記実施例と同様に、インデクサ用ＰＣ３は、インデクスを最初に作成する際にのみ、ＳＭＢサーバ１群（ファイルサーバ群）を全体走査し、一番最初にインデクスを作成するときには、検索対象となる全てのファイルを基点リスト（「ファイル巡回」＆「インデクス」制御ファイル内で定義）からたどり、ファイル属性を読み出しタイムスダンプリストをつくる。

また、インデクサ用ＰＣ３は、上記実施例と同様に、インデクスの新規作成，部分的な変更および削除に伴う更新は、ログ収集用ＰＣ３０に格納されている更新候補情報に基づいて、ＳＭＢサーバ１群を照査して、新規作成，削除，部分的な変更が実際に行われた更新実行情報に基づいてインデクスの更新を行う。

図５は、更新候補情報をログ出力から抽出して、蓄積する際のログ収集用ＰＣ３０の手順を示している。図５の手順がスタートすると、ｓ３０で、ログ収集ルーチン３０ａにて、ネットワークを経由して、ＳＭＢサーバ１群のログ出力８が収集される。

次いで、ｓ３１で、収集したログ情報のうち、ＳＭＢサーバ１に対する書込み，更新，作成，属性変更に関するもののみが、アクセルログフィルタ３０ｂにより抽出される。続く、ｓ３２では、ログ判別モジュール３０ｃにより、メモリ領域３０ｄ上に、ＳＭＢサーバ１に対する同一の対象，同一の処理を一つにまとめて書き出す処理が行われる。

次のｓ３３では、メモリ領域３０ｄ上の記録が、メモリ上に格納するログ数の条件を越えたか否かが判断され、これが超えている場合には、ｓ３４で、メモリ領域３０ｄ上の全記録をパケットログファイル３０ｅに出力して、ここに格納して、ｓ３６に移行する。

ｓ３３で、メモリ領域３０ｄ上の記録が、メモリ上に格納するログ数の条件を越えていないと判断された場合には、ｓ３５で、前回ログ出力して以来パケットログファイル３０ｅに出力する間隔時間が設定値を超えたか否かが判断され、越えている場合には、ｓ３４に移行して、メモリ領域３０ｄ上の全記録をパケットログファイル３０ｅに出力して、ここに格納して、ｓ３６に移行する。

一方、ｓ３５で、パケットログファイル３０ｅに出力する間隔時間が設定時間を超えていないと判断されると、ｓ３６により一定時間待機して、ｓ３０に戻って処理が続行される。

以上のような手順を順次実行することにより、ログ収集用ＰＣ３０のパケットログファイル３０ｅには、更新候補情報が蓄積されることになる。このようにしてパケットログファイル３０ｅに蓄積された更新候補情報は、インデクサ用ＰＣ３から定期的ないしは不定期に読まれて、インデクスの更新に使用される。

この際には、インデクスの新規作成，部分的な変更および削除に伴う更新は、更新候補情報に基づいて、ＳＭＢサーバ１群を照査して、新規作成，削除，部分的な変更が実際に行われた更新実行情報を抽出し、この更新実行情報に基づいてインデクスの更新が行われる。

この際に行われる具体的な手順は、上記実施例の図３に示したものと同一である。以上のように構成した実施例でも、上記実施例と同等の作用効果が得られる。

なお、最近のＯＳでは、セキュリティ管環や内部統制的な要請から、どのような処理が内部的に行われたかをログファイルとして残す機能を持つものが多い。このログファイルをもとに、その中からファイルのアクセスに関するものだけを選択することで上記実施例と同様にイベントを抽出することが可能となる。

また、ＮＡＳ：Ｎｅｔｗｏｒｋ Ａｔｔａｃｈｅｄ Ｓｔｏｒａｇｅなどの専用ストレッジそれ自身が一種のコンピュータであり、そこへのアクセスをログとして出力したり、内部アクセス状況をプログラムインターフェイスから取り出すことができるものがある。このようなＮＡＳを使う場合には、ＮＡＳ自身の機能からイベントの抽出が可能となる。

ＳＭＢサーバ１がこのようにアクセスログを抽出する機能を持つ場合には、上記実施例で示したパケットをキャプチャする処理は不要となり、このようなアクセスログを用いて上記実施例と同様の処理が可能になる。

本発明にかかる全文検索システムによれば、クローリング時間の大幅な短縮化が可能になり、ストレッジの大規模化も簡単に達成することができ、しかも、このような効果は、アプリケーションの処理に使われるべきストレッジの処理能力を、クローリングのために消費することなく得られるので、システム全体のパフォーマンスの低下を回避することができ、さらには、更新状況を即時にインデクスに反映することが可能になり、タイムリーな更新をも可能にするので、全文検索の分野において有効に活用することができる。

本発明にかかる全文検索システムの全体構成を示すブロック図である。 図１に示したシステムで、更新候補情報を取得・格納する際に手順の一例を示すフローチャート図である。 図１に示したシステムで、取得した更新候補情報に基づいて、実際に更新されたファイルを確認し、その後インデクス更新する手順を示したフローチャート図である。 本発明にかかる全文検索システムの他の実施例を示す全体構成を示すブロック図である。 図４に示したシステムで、更新候補情報を取得・格納する際に手順の一例を示すフローチャート図である。 従来の全文検索システムの全体構成を示すブロック図である。 図４に示したシステムでインデクスを更新する際の説明図である。

符号の説明

１ ＳＭＢサーバ
２ クライアントＰＣ
３ インデクサＰＣ
４ 検索用ＰＣ
５ スイッチングハブ
６ 通信路
２０ キャプチャ用ＰＣ
２０ｃ パケットフィルタ
２０ｄ パケット判別モジュール
２０ｅ キャプチャ制御ファイル
２０ｆ メモリ領域
２０ｇ パケットログ
２１ タップ

Claims (5)

1. 検索対象となる電子文書が蓄積されたデータベースを有するファイルサーバ群と、
   前記電子文書の新規作成，削除，部分的な変更を入力するとともに、検索対象文書のインデクスを入力するクライアントＰＣ群と、
   前記ファイルサーバ群の前記電子文書を照査して、当該電子文書に含まれている文言の索引用インデクスを作成するとともに、作成したインデクスを格納するインデクスデータベースを有するインデクサ用ＰＣ群と、
   前記インデクサ用ＰＣ群で作成されたインデクスを格納する検索用ＰＣとを有し、
   前記ファイルサーバ群，クライアントＰＣ群，インデクサ用ＰＣ群，検索用ＰＣの間のそれぞれがスイッチイングハブを介して接続される通信路とを備え、
   任意のクライアントＰＣから入力された検索対象インデクスに基づいて、前記検索用ＰＣから前記検索対象インデクスに該当するインデクスを抽出して、当該クライアントＰＣに出力する全文検索システムにおいて、
   前記クライアントＰＣ群から前記ファイルサーバ群へアクセスされる情報のうちから、前記前記電子文書の新規作成，削除，部分的な変更に関連する更新候補情報を抽出して、格納するキャプチャ用ＰＣを備え、
   前記インデクサ用ＰＣ群は、前記インデクスを最初に作成する際にのみ、前記ファイルサーバ群を全体走査し、
   前記インデクスの新規作成，部分的な変更および削除に伴う更新は、前記キャプチャＰＣに格納されている前記更新候補情報に基づいて、前記ファイルサーバ群を照査して、新規作成，削除，部分的な変更が実際に行われた更新実行情報を抽出し、当該更新実行情報に基づいて前記インデクスの更新を行うこと特徴とする全文検索システム。
2. 前記更新候補情報は、前記通信路から取得することを特徴とする請求項１記載の全文検索システム。
3. 前記更新候補情報は、前記クライアントＰＣ群から前記ファイルサーバ群へアクセスされた情報が、前記ファイルサーバ群に残されているアクセルログから取得することを特徴とする請求項１記載の全文検索システム。
4. 前記キャプチャ用ＰＣは、前記通信路に設置されたタップを介して、前記クライアントＰＣ群から前記ファイルサーバ群へアクセスされる情報を取得して、前記更新候補情報を抽出するパケット判別モジュールと、
   前記更新候補情報を格納するパケトログと、
   前記判別モジュールの制御用ファイルとを有することを特徴とする請求項２記載の全文検索システム。
5. 前記インデクスには、前記検索対象となる電子文書へのアクセス権の作成、および、同アクセス権の新規作成，削除，部分的な変更などの更新情報を含ませることを特徴とする請求項１〜５のいずれか１項記載の全文検索システム。

Images