JP4559158B2 - データにアクセスするための方法及びシステム - Google Patents

Description

本発明はコンピュータファイルのアクセスに関連し、具体的には検索エンジンでのインデックス保守の性能向上に関連する。

インターネットは一般に“Ｗｅｂ”(World Wide Web)に関連している。このＷｅｂは、Ｗｅｂにアクセスする何百万のユーザに対して、爆発的に増大する情報を提供してきた。この情報はＷｅｂサーバによって、ファイルの形で提供されてきた。しかしながら、インターネットは、Ｗｅｂ以前から掲示板やＦＴＰサイト等の形で、ファイルサーバによって提供されるファイルへのアクセスを可能にしてきた。

イントラネットも又会社やその他の組織で、私的ネットワークとしてファイル共用の為に使用されている。このケースでは、ファイルサーバ又はＮＡＳ(Network Attached Storage：ネットワーク接続ストレージ)が、ファイルを保存したり取得したりするのに共通に用いられている。ＮＦＳ及びＣＩＦＳプロトコルがファイルへのアクセスに使用されている。

検索エンジンは、インターネット検索やファイルサーバに於いて、貴重なツールになってきている。検索エンジンは、インターネットやファイルサーバ上の何百万と言うファイルにアクセスする為に一般に使用されるツールである。典型的には、検索エンジンはユーザからの検索要求を受付けて検索条件にマッチするファイルのリストを取得し送信する。

検索エンジンに必須なコンポーネントの一つは“インデックス”である。インデックスは、ファイルを精査し又は解析して得られる情報の集合で、検索エンジンがファイル検索し易くする為のキーワードや関連情報を含んでいる。このインデックスの具体的情報構成やデータ構造は検索エンジン毎に異なり、本発明の範囲外である。

しかしながら、典型的検索エンジンによってなされる共通的操作があり、それには、インデックスの生成とその後に必要な更新等の保守作業がある。インデックスの生成では、典型的に、検索エンジンが各ファイルの更新日をチェックし、インターネット上やファイルサーバ上の全ての更新ファイルを読み込みその内容を精査して、インデックスを構築する。

ファイルの内容が時と共に更新される事は、不変の事実である。従って、検索エンジンはインデックスが常に現状を表すように、インデックスの更新を行わなければならない。この為には、Ｗｅｂやファイルサーバを這い回って、各ファイルの属性にアクセスして、当該ファイルが前回のインデックス更新以後更新されたか否か、又は最初のインデックス更新の場合はいつインデックスが生成されたかを判定しなければならない。この判定は例えば、前回のファイル更新日にアクセスして、インデックスとの比較をすることによって達成される。全てのフアイルを再インデックスするのではなく、インデックス更新時刻以降に更新されたファイルのみが対象となれば、更新負荷を減少させ、更新時間を改善させることが出来る。

それでも、全てのファイルの更新日はチェックしなければならず、この更新作業は厄介な仕事である。この為に、即ちファイルの属性をチェックするだけの為に、大きなボリュームの転送が必要となる。従って、インデックス操作の為のインターネットやイントラネットの転送量を減少させることは大変望ましい事である。インデックスの更新時間を更に減少させて更新負荷を更に減少させることも又望ましい事である。

本発明の一態様では、ファイルサーバ内に更新済ファイルリストが維持される。この更新済ファイルリストに基づく更新情報が、検索エンジンに伝えられる。この更新情報には、この検索エンジンでの前回のインデックス更新操作後に更新されたファイルのみが記されている。

本発明のこの態様は、更新済ファイルリストに関連した議論と類似している事に注意願いたい。検索エンジンは、既に議論したように、ファイルシステムでのインデックスの更新を行おうとするときには、ファイルシステムに関連した更新済ファイルリストを調査する。かくのごとく、検索エンジンがインデックス更新を行う時には、更新済ファイルリスト内の参照されたファイルをアクセスして精査するのみでよい。

図１は、本発明に従う、検索エンジン環境の一実施例についての基本アーキテクチュアの概略を説明する上位レベルのブロックダイアグラムである。この図にはネットワーク０１０３上のユーザがアクセス可能な一つ以上のファイルを持つ少なくとも一式のファイルサーバ０１０４が存在する。ファイルサーバ制御部０１０４０３に依ってファイルサーバに関連する慣用的な処理の実行が可能になる。この制御部には中央処理ユニット(ＣＰＵ)、メモリ、及びこのＣＰＵを稼動させるプログラムコードを保存するストレージが存在する。

ファイルサーバに保存されているファイルは、ファイルシステム０１０４０１に組織化されている。本発明の一実施例では、ファイルサーバは更新済ファイルリスト０１０４０２にアクセスできる。一般的に、この更新済ファイルリストは相応しいロケーションに存在する物理ストレージに保存される。もっと一般的に言えば、図に示されるファイルサーバ要素０１０４は各々自分のファイルセットを保持している複数のファイルサーバを表している。ファイルサーバが使用する典型的なプロトコルは、ＮＦＳ(Network File System)プロトコルである。もう一つの慣用的なプロトコルはＣＩＦＳ(Common Internet File System)プロトコルである。更に、ＨＴＴＰ等の他のプロトコルもファイルサーバが使用可能である。

このアーキテクチュアには、ファイルサーバ内のファイルを読み書きする為に、ネットワーク０１０３上でＮＦＳ又はＣＩＦＳプロトコルを通して、ファイルサーバ０１０４と交信する、少なくとも一式のＮＦＳ／ＣＩＦＳクライアント０１０１が存在する。クライアントにはファイルの生成者と、ファイルの読み取り、更新のいずれかの為に又はファイルの読み書きの為にファイルにアクセスするユーザが存在する。より一般的に言えば、図１のクライアント要素０１０１は、各々一式以上のファイルサーバにアクセス可能な複数のユーザを示す。

検索エンジンサーバ０１０５は、ネットワーク０１０３を通して交信する。検索エンジン制御部０１０５０２は検索エンジンに関連する慣用的な処理を可能とする。この制御部には、中央処理ユニット(ＣＰＵ)、メモリ、及びこのＣＰＵを稼動させるプログラムコードを保存するストレージが存在する。本発明の実施例は検索エンジンを使用することで述べているが、本発明の態様がネットワーク環境でファイルを追跡し更新する全てのマシンに適用できる事は、以下の記述から明らかであろう。検索エンジンは、コンピュータネットワークで交信する多くの人にはよく知られ馴染み深い為に、単に簡便な例として用いているに過ぎない。

多くの検索エンジンの典型的な仕事は、インデックスを生成しその保守をすることである。インデックスの具体的内容、それを構成する情報構造、及び具体的精査機能等は本発明の範囲外である。議論の目的の為に、特定ファイルシステムでのインデックス又はファイルシステムに関連するインデックスを参照するが、このことは、通常のスキルを持った人には明らかであろう。インデックス情報は、一般性を失う事無く、通常インデックスデータベース０１０５０１の形で表現される。

インデックスは検索エンジンで生成され、続いて更新され或いは保守される。この作業には、インデックスデータベースを生成する為に、ファイルサーバ０１０４内のファイルを精査し、又は情報を生成することが含まれる。検索エンジンがファイルサーバ内のファイルにアクセスするのに、同じＮＦＳ又はＣＩＦＳプロトコルを使用できることに注意願いたい。

このアーキテクチュアには、少なくとも一式のファイル検索クライアント０１０２が存在する。これらは、検索エンジンにアクセスしてファイル検索要求を発行するユーザである。ここで、“ユーザ”は、人又はマシンの何れでも良いことに注意願いたい。サービスを受けるユーザの種類に相応しいインターフェースを、検索エンジンが認識し、提供する。一般的に、図１でのファイル検索クライアント要素０１０２は複数の検索クライアントを示す。

ネットワーク０１０３は、一般的に、上述した各種サーバとクライアント間での交信を可能にする、相応しい通信ネットワークでよい。図では、ＬＡＮ(Local Area Network)を示すが、他の通信ネットワークでも等しく使用可能なことに注意願いたい。ＬＡＮネットワークへの結合は、ＴＣＰ／ＩＰプロトコルを使用したイーサネットで典型的に提供される。

ファイルサーバ０１０４と検索エンジンサーバ０１０５は慣用的なコンピュータハードウエア(例えば、適切なＣＰＵ、メモリ、ストレージデバイス、等で構成される)で実現される。慣用的なソフトウエアプラットフォーム、例えば、Ｕｎｉｘ、又は他のＵｎｉｘベースのＯＳ、マッキントシュＯＳ、各種のマイクロソフトＯＳ等が、サーバをサポートする為に使用される。更に又、ファイルサーバと検索エンジンサーバは同じハードウエアとソフトウエアプラットフォーム上で稼動する事も可能である。例えば、ＮＦＳサーバと検索エンジンソフトウエアは、Ｌｉｎｕｘ ＯＳ上で稼動可能である。

図２を参照するに、検索エンジン内での処理にはインデックスデータベースの生成が含まれる。“インデックス”は、検索要求を処理する時に検索エンジンで使用される。このインデックスは、クライアントからの検索要求を満たすファイルがもしあれば、それらを特定する為に調べられる。“インデックス”なる用語は、一つの特定の検索エンジンが使用する所定のデータを参照する為の非常に一般的なものであることを理解願いたい。“インデックス”を構成する特定のデータ構造やストレージフォーマットは、検索エンジン毎に変わり得るものであることを理解願いたい。しかしながら、検索エンジン用のインデックスは、ファイル及びその内容(例えばキーワード)に関する情報を持つことは変わらない。

一実施例では、インデックスは、全ファイルサーバを代表するデータの一式の巨大データベースか、又は何か他の単一データ構造である。しかしながら、論理的には、各ファイルサーバは、各々自身の関連付けられたインデックスを持つものとして参照可能である。即ち、参照は、ファイルサーバに関連するインデックス構造の部分に対してなされると理解される。

かくして、検索エンジンが初めてオンラインになるときには、ファイルサーバ内でアクセスされる全てのファイルについて、インデックスが生成される。このことは、検索エンジンに知られている全てのファイルサーバについて実行される。更に又、既にオンラインにある検索エンジンが新しいファイルサーバを認識したら、このファイルサーバに含まれるアクセス可能なファイルに対して、インデックスを生成しなければならない。このことは図２のステップ０２０１の判定ステップに示され、ある所定のファイルサーバに対して、インデックス生成の要否が判定される。

新規ファイルサーバに対しては、検索エンジンは初期化要求(図４を参照)をファイルサーバに送信する(ステップ０２０２)。これによって、ファイルサーバは関連する更新済ファイルリスト０１０４０２をクリアする。本実施例では、一般性を失う事無く、一式のファイルサーバを例として取り上げる。かくして、ステップ０２０１は最初のインデックス生成を行う為のものである。多数のファイルサーバの場合は、検索エンジンがどのファイルサーバに何時インデックスを生成したかを管理するテーブルが用意される。一例として図２Ａを示す。この例では、一式のファイルサーバは多重のエクスポートポイントを持っている。

判定ステップ０２０１を参照するに、一式のファイルサーバに対して、インデックスが生成済であれば、検索エンジンは当ファイルサーバに関連する更新済ファイルリスト０１０４０２に含まれる更新情報にアクセスする(ステップ０２０３)。次いで、ステップ０２０４にて、検索エンジンは更新情報で参照されるファイルにアクセスする(図４を参照)。検索エンジンは、各ファイルに対して、ファイル内容を精査(或いは解析)して、このインデックスに相応しいインデックス情報を生成する。検索エンジンは、一時には一ファイルにアクセスして精査を実行する。或いは又、検索エンジンは一時にファイルのグループにアクセスして、このグループに対して精査を実行する。

一実施例では、この更新済ファイルリストには、他のファイルと同様に検索エンジンがアクセス可能である。このようにして、ファイルサーバは更新済ファイルのリストを含む特殊ファイルを生成して、検索エンジンはファイルサーバからこのファイルのコピーを取得して、ローカルコピーとして格納する。検索エンジンはこの特殊ファイルの内容を削除することも行う。検索エンジンは従ってローカルコピーで動作することができ、例えば精査するファイルを特定する為に、このファイルを読み取ることができる。或いは又、更新済ファイルリストに含まれる情報を取得する為に、検索エンジンとファイルサーバとの間に一つのプロトコルを定義する事が出来る。例えば、ファイルサーバは、検索エンジンにて処理されるべく、更新済ファイル中の各ファイル名又は更新済ファイルリスト中の各ファイル名のリストを検索エンジンに伝える事が出来る。或いは又、検索エンジンは、ファイルサーバからのファイル名のリストに代わって、更新済ファイルリスト中のファイル自身を受信することができる。

図３を参照するに、ファイルサーバはファイル操作の為に多数の要求を受け取る。例えば、典型的操作として、ファイル生成、ファイルオープン、ファイル読み取り、ファイル書き込み、ディレクトリリスティング等である。提供される具体的ファイル操作内容は、ファイルシステムやファイルサーバと交信するプロトコル(例えばＮＦＳ、ＣＩＦＳ等)に依存する。

かくして、ステップ０３０１にて、ファイルサーバはクライアントからファイル操作要求を受信する。判定ステップ０３０２にて、この要求は対応するハンドラに渡される。例えば、ファイルオープン要求はファイルオープンハンドラ０３０３で処理される。ファイル読み取り要求はファイル読み取りハンドラ０３０４で処理される。ファイル書き込み要求は、本発明の一実施例に従い、ファイル書き込みハンドラ０３０５で処理される。本発明のこの態様については以下に議論する。ディレクトリリスティング要求は、本発明の他の一実施例に従い、ディレクトリリスティングハンドラ０３０６で処理される。ディレクトリリスティング要求については更に以下に議論する。“更新済ファイルリスト取得”要求はハンドラ０３０７にて処理される。この機能は本発明の一実施例に従って提供され、後に議論される。

図５を参照するに、本発明によるファイルサーバでのファイル書き込み操作の処理が述べられている。ファイル書き込み操作は指定ファイルの内容を変更する。ファイルサーバはステップ０５０１の判定ステップにて、この要求はファイルオープン以降の最初のファイル書き込み操作か否かを判定する。ファイルオープン以降での最初のファイル書き込み操作の場合には、ステップ０５０２にて、このファイルサーバに関連する更新済ファイルリスト０１０４０２の中に当該ファイルへの参照が記録される。反対にファイルオープン以降での最初の書き込み操作ではない場合には、処理は次のステップに進む。典型的には、次のステップ(０５０３)は要求された書き込み操作をもたらすもので、詳細は個別のファイルサーバに依存する。

ステップ０５０１で最初の書き込み操作のチェックを行う目的は、同一ファイルに対して、更新済ファイルリスト０１０４０２内に重複するエントリを作るのを防止する為である。この為の一方法がステップ０５０２に開示されている。この代わりとして、更新済ファイルリストへの登録時に、対象ファイルがリスト中に既に存在するか否かを毎回チェックすることでも重複エントリを回避できる。

ファイル生成の場合には、生成されたファイルには最初はデータは存在しない。従って、ファイルサーバは更新済ファイルリストの中に新規生成ファイルを参照する為のエントリを作成する必要はない。このファイルの中に内容が置かれるのは、ファイル書き込み操作に伴ってである。しかしながら、ある種のファイルシステムでは、ファイル生成操作に伴って、引き続く書き込み操作が実行できる状態に保持して、ファイルオープン操作を不要にしている。従って、図５の判定ステップ０５０１では、テストは、ファイルオープン又はファイル生成にひき続く最初の書き込み操作のテストを含めるように変更する事が出来る事を理解願いたい。

図８を一見するに、更新済ファイルリストに含まれる情報は、書込み操作の対象としてのファイルを特定している。例えば、階層型ディレクトリ構成ではファイルに対する完全なパス名だけで十分である。他の命名方式がより相応しいかもしれない。具体的情報は、対象となるファイルサーバ又はファイルシステム等の特性に依存する。かくして図８には、典型的な更新済ファイルリスト例０１０４０２が記されている。図示される実装例はファイル名のリストで構成されている。この更新済ファイルリストが参照している各ファイルが更新済である。各エントリ０８０１０１は完全パス名を含むファイル名で構成されている。

図４を参照するに、“更新済ファイルリスト取得”要求には、二種類の操作が存在する。ファイルサーバが更新済ファイルリスト取得要求をステップ０４０１で受信すると、判定ステップ０４０２にて、この要求は初期化要求か或いは更新済ファイルリストの取得要求かを判定する。要求が初期化要求なら、ステップ０４０３にて、ファイルサーバは存在する更新済ファイルリストを単純にクリアする。更新済ファイルリストが存在しなければ、ファイルサーバは更新済ファイルリストを生成する。本発明のこの態様については更に以下で議論する。

図４に示す具体的実装例では、更新済ファイルリストについて交信するのに、ファイルサーバと検索エンジンとの間で特殊なプロトコルを使用している。他の実装例では、検索エンジンは標準的ＮＦＳ／ＣＩＦＳプロトコルを使用して、ファイルサーバから更新済ファイルリストを取得できる事を理解願いたい。そのような実装例では、更新済ファイルリストはファイルサーバ内に一つのファイルとして保存されている。従って、検索エンジンは標準的ＮＦＳ／ＣＩＦＳプロトコルを使用して、このファイルを読み取り、更新されたファイル名を知る事が出来る。この特殊ファイルの内容は、検索エンジンに読み取られた後には、クリアされなければならない。

この図を続けると、要求が更新済ファイルリストの取得（get_file_list）操作の場合には、ファイルサーバは、検索エンジンに対して更新済ファイルリストを送信する(ステップ０４０４)。他のファイルの場合と同様に、このファイルのコピーを検索エンジンに送信しても良い。或いは又、ファイルサーバは、一時に一ファイルずつ又はグループ単位で又は他の相応しい方法で、検索エンジンに実際のファイルを送信してもよい。検索エンジンは、更新済ファイルリスト内の各ファイルを解析して、解析により生成した情報を基にインデックスを更新する。

更新済ファイルリストが検索エンジンに送信されると、この更新済ファイルリストはステップ０４０５にてクリアされる。このように、更新済ファイルリストが単一ファイルとして検索エンジンに送信されると、この更新済ファイルリストはこの送信が完了し次第クリア可能である。もしファイルサーバが検索エンジンにファイル自体を送信した場合には、更新済ファイルリスト内で参照されている各ファイル名は、検索エンジンに送信後この更新済ファイルリストから削除可能である。

更新済ファイルリストがクリアされた後には、このリストはその後更新されたファイルへの参照で再度補充される。この更新済ファイルリストで参照されるファイルは、この更新済ファイルリストが最近にクリアされた後に、更新を受けたことを表示している。別の言い方をすると、この更新済ファイルリストは、前回当該更新済ファイルリストが検索エンジンによって受け取られた以降に更新されたファイルへの参照をリストしていることになる。

検索エンジンの観点からは、更新済ファイルリスト内でのファイル参照は、前回インデックスが更新された時点以降に更新されたファイルを示していることになる。インデックス更新は時間を消費する操作である事を理解願いたい。かくして実際に、ファイルサーバによる更新済ファイルリストのクリア(ファイルリスト取得要求（get_file_list要求）による)は、検索エンジンによるインデックス更新の完了に先立って都合よく実施される。

次に、検索エンジンがインデックスの更新を実行する為に更新済ファイルリストを取得する時には、前回のインデックス更新以降に更新されたファイルを精査するだけでよい事になる。この更新済ファイルリストによって、検索エンジンは、インデックス更新の為に、所定のファイルサーバ内の全ファイルにアクセスして精査する暴力的作業の実行を免れる事になる。

インデックスは未だ持ち合わせていないファイルについては生成することが出来る。このような事態は、検索エンジンがファイルシステムを認識していなかった場合、又は何かの原因でファイルシステムに存在していた既存のインデックスを削除したと判断した場合に発生する。検索エンジンがインデックス生成のプロセスを完了したら、初期化操作の為にファイルリスト取得（get_file_list）要求を送信する。これによって、更新済ファイルリストが生成されるか既存の更新済ファイルリストがクリアされる。もしファイルシステムが事前に知られていなければ、ファイルシステムは更新済ファイルリストを持っているとは思えない。この場合には、更新済ファイルリストが生成される。もし、ファイルシステムが既に更新済ファイルリストを持っておれば、初期化操作はこのリストをクリアする効果を持つ。

これまでの議論に基づいて、各ファイルサーバは自分に固有の更新済ファイルリストを持っていることを理解願いたい。しかしながら他の実装方式として、複数のファイルサーバからアクセスされ、この複数のファイルサーバからの更新済ファイルへの参照を持つ更新済ファイルリストが実装されることが考えられる。最も一般的なケースとして、グローバル更新済ファイルリストを用いる事が考えられる。しかしながら、このタイプの更新済ファイルリストは、性能、実装等の条件により、好ましいか否かが分かれる。もう一つの代替として、一式のファイルサーバが複数の更新済ファイルリストを持つことが考えられる。一式の更新済ファイルリストはこの一式のファイルサーバの一つのエクスポート点に関連付けられる。

図１０を参照するに、本発明のもう一つの実施例に於いては、ファイルサーバは、異なるクライアントに対して、異なったファイルシステムをエクスポートするように構成できる。ＮＦＳやＣＩＦＳ環境に於いては、クライアントはファイルシステムのエクスポートを“マウント”する。マウントは、ＮＦＳ／ＣＩＦＳクライアントとファイルサーバが交信して、ＮＦＳ／ＣＩＦＳクライアントがエクスポートをアクセスできるようにする為の手続きである。エクスポートとは、ＮＦＳ／ＣＩＦＳクライアントが共有できるようにする為のファイルシステムやディレクトリの名前である。

図１０で分かるように、ファイルシステム０１０４は、検索エンジン以外のクライアントがマウントできる第一のエクスポート１００１を提供する。ファイルサーバは、検索エンジンがマウントできるように第二のエクスポート１００２を提供する。どちらのエクスポートも同じファイルシステム又はディレクトリ０１０４０１上にある。ファイルサーバは検索エンジンがどのエクスポートをマウントしたかを知ることが出来る。例えば、マッピング関係をファイルサーバ内の特殊ファイルに記述することができる。

本発明の実施例では、検索エンジンは、ファイルサーバ内のファイルのインデックスを生成するかインデックスを更新する為に、慣用的なプロセスを実行する。検索エンジンは、ファイルサーバによって使用可能になっているエクスポートをマウントする。ファイルサーバの管理者は検索エンジンの為にエクスポートを生成する。検索エンジンの管理者は、検索エンジンがインデックスを生成するのに必要なエクスポートのリストを指定する。このことは、例えば、検索エンジン内の特殊ファイルを編集する事によってなされる。ディレクトリサービスを使用することにより、この構成は組織的に実行できる。検索エンジンは次いで、例えば、ＮＦＳやＣＩＦＳのプロトコルで提供される標準の要求を使用して、ファイルサーバ内のファイルのディレクトリリスティングを一つ以上要求する。

ファイルシステムの為にインデックスを生成する場合には、ディレクトリリスティング内で特定されている各ファイルが精査されインデックス付けされる。インデックスを更新する場合には、検索エンジンは、ファイルの更新日(又は他の同等情報)に基づいて、当該ファイルは、インデックス付けの為に精査されるべきか否かを判定する。ファイルが、このファイルシステムでの前回のインデックス付け以降更新されていたら、当該ファイルは精査されインデックス付けされる。そうでなければ精査されない。

本発明のこの態様によれば、ファイルサーバが検索エンジンにディレクトリリスティングを通じて使用可能にするファイルのリストは、他のクライアントに対してディレクトリリスティング内で使用可能にするファイルの一部分である。このことは、検索エンジンがマウントするエクスポートは、検索エンジン以外のクライアントがマウントするエクスポートとは異なっているから可能になる。すぐに述べる様に、ファイルサーバは、ファイルサービス要求(例えばディレクトリリスティングサービス要求)がなされているエクスポートによって異った処理を受けるように構成されている。

図９を参照するに、本発明のこの態様で構成されたファイルサーバは、ファイル選別テーブル０９０１を装備する。テーブルは、検索エンジンによってマウントされているエクスポートにどの種類のファイルを開放すべきかの条件(基準)０９０１０１を保持している。例えば、検索エンジンのユーザは、ファイルタイプに基づいて検索対象ファイルを限定しようとしているかもしれない。ファイルのタイプは、.ｐｐｔ、.ｄｏｃ、.ｘｌｓ等のファイル拡張子で判定される。この場合、指定の拡張子のファイルが検索の候補として特定される。検索対象を決める他の基準は、ファイル所有者、ファイル生成日時、ファイルサイズ等である。

図９で示されるファイル選別テーブルの実施例は包含テーブルである。この意味は、ファイル選別テーブルは、ディレクトリリスティング時に含めるべきファイルを指定するということである。例えば、全ての“.ｄｏｃ”ファイルは、指定されたディレクトリに対するディレクトリリスティングに含まれる候補である。しかしながら、“.ｅｘｅ”ファイルは、このリストから除外されており含まれない。このファイル選別テーブルは“除外”方式であっても良いことに注意願いたい。この場合には、このテーブルは、ディレクトリリストから除外すべきファイルを指定する。かくして例えば、除外テーブルが、“.ｅｘｅ”を含んでいるとすれば、“.ｅｘｅ”ファイルは除外されるべき事を意味する。更に又、このファイル選別テーブルは、包含すべきファイルと除外すべきファイルを指定するようにすることも出来る。

典型的には、インデックス付けされるファイルはテキストを含むものである。ある種の検索エンジンは、グラフィックスやある種のイメージデータが存在しても、その中に対応するテキストがあれば、インデックスを付与する。ファイル選別テーブルは、実行型ファイルや検索されるデータを含んでいないファイルを予め除外しておいて、検索エンジンが考慮しなければならないファイルのセットを減少させることが出来る。

図７は、検索エンジンがマウントしたエクスポートになされるディレクトリ要求を処理する例である。ファイルサーバは、ディレクトリリスティング要求が検索エンジンから発行されたか否かをステップ０７０１で判定する。ディレクトリリスティング要求には、どのエクスポートに要求がなされたかを示す情報が含まれている。ファイルサーバは、検索エンジンがどのエクスポートをマウントしたかを認知できる為、ファイルサーバはこの判定をなす事が出来る。この要求が検索エンジンから来たものでなければ、ステップ０７０７にて、要求クライアントに対して、慣用的なディレクトリリスティングが生成され、送信される。

検索エンジンから要求されたものなら、ステップ０７０２にて、ファイルサーバはファイル選別テーブル０９０１を調べて、ディレクトリ内の各ファイルに対して、ディレクトリリスティング情報の中に含まれるか否かを判定する（ステップ０７０３）。ファイルが、ファイル選別テーブルに設定されている条件を満たすなら、当該ファイルへの参照が一時リスト内に付加される(ステップ０７０４)。ファイルサーバは、要求が検索エンジンから来たか、クライアントから来たかを、この要求が発行されたエクスポート又は要求者のＩＰアドレスを調べ又はその他の相応しい識別技術によって、判定する事ができる。更にファイルサーバは、ディレクトリ要求を満足させるのに、ファイル選別テーブルを使用する一つ以上のコンピュータシステム(例えば検索エンジン)を特定する相応しいリストを維持する事も出来る。

ファイルがファイル選別テーブルの選別条件にマッチしなければ、一時リストに付加されることはない。ステップ０７０５にて、全てのファイルがファイル選別テーブルの条件に対してチェックされたか否かを判定する。更にファイルのチェックが必要なら、ステップ０７０２に戻る。他の場合には、一時リストがステップ０７０６にて更に処理されて、相応しいディレクトリリスティングが生成され、検索エンジンに返送される。これには、一時リストにサブディレクトリのリスティングを追加することもあり得る。一時リストに含まれるファイルのファイル属性を付加する必要があるかも知れない。これには、ファイルサイズ、生成日、更新日、許可情報、等が該当する。ディレクトリ情報は、ディレクトリリスティング要求に対する応答として、検索エンジンに送信される。

検索エンジンが受信したディレクトリリスティングはファイル選別テーブルによって選別されており、この結果は、非検索エンジンクライアントが受信するファイルの一部分であることを、理解願いたい。この縮小ファイルリストのおかげで、選別されていないディレクトリリスティングがより多数のファイルを含む従来型処理に比べて、検索エンジンがファイルシステムに対してインデックスの生成又は更新に要する処理は減少する。

図６を参照するに、本発明の更に他の態様が、ファイルサーバによる書き込み要求の処理に向けられている。ファイルサーバが書き込み要求を受信すると、この書き込み要求は、このファイルが前回オープンされてからの最初の書き込み要求か否かを、ステップ０６０１で判定する。この要求が最初の書き込み要求でなければ、この要求はこのファイルサーバの特性に応じて慣用的方法で処理される(ステップ０６０４)。

この要求が、前回のファイルオープン後での最初の書き込み要求なら、処理は判定ステップ０６０２に向かう。ここで、ファイル選別テーブル０９０１を調べる。このテーブルは既に述べたと同様な方法で使用される。この書き込み要求の対象ファイルが、このファイル選別テーブルの基準を満たせば、当該ファイルへの参照が更新済ファイルリスト０１０４０２に追加される(ステップ０６０３)。基準が満たされなければ、この書き込み処理はステップ０６０４にて慣用的な方法で実行される。

図５で注記した様に、ファイル生成に於いて生成されたファイルは、初めにはデータは含んでいない。従って、ファイルサーバが、更新済ファイルリストにエントリを作成して、新規生成ファイルを参照する必要はない。ファイルへの内容は、ファイル書き込み処理を契機に書き込まれる。しかしながら、ある種のファイルシステムでは、ファイル生成処理後次の書き込み処理が実行できる状態にファイルを維持して、ファイルオープンを不要にしている。従って、図６の判定ステップ０６０１に関連して、このテストがファイルオープン処理又はファイル生成処理に続く最初の書き込み処理のテストを包含するように、修正できる事を理解願いたい。本発明の態様、効果と新規な機能が本発明の以下の付属図面と共になされる説明によって明らかになる。

本発明の実施例を説明する上位レベルの一般的ブロックダイアグラムである。 インデックス生成処理を説明する一般的フローダイアグラムである。 検索エンジンがどのファイルサーバに何時インデックスを生成したかを管理するテーブルである。 ファイルサーバでのファイルサービス要求の処理を説明する。 ファイルサーバでの更新済ファイルリスト処理の為の上位レベルのフローダイアグラムである。 ファイルサーバでの書き込み要求の処理を説明するフローダイアグラムである。 本発明の他の実施例に於ける、ファイルサーバでの書き込み要求の処理を説明するフローダイアグラムである。 ファイルサーバでのディレクトリリスティング要求の処理を説明する一般的フローダイアグラムである。 更新済ファイルリストの実施例を示す。 ファイル選別テーブルの実施例を示す。 多重エクスポートを示す。

符号の説明

０１０１ ＮＦＳ／ＣＩＦＳクライアント
０１０２ ファイル検索クライアント
０１０３ ＬＡＮ
０１０４ ＮＦＳ／ＣＩＦＳサーバ
０１０５ 検索エンジンサーバ
０１０４０１ ファイルシステム
０１０４０２ 更新済ファイルリスト
０１０４０３ ファイルサーバ制御部
０１０５０１ インデックスデータベース
０１０５０２ 検索エンジン制御部

Claims (6)

1. 複数のファイルを保存するファイルサーバと、該ファイルサーバに保存された各前記ファイルのインデックス情報からなるインデックスを生成し、クライアントからの検索要求に応じて、前記ファイルサーバに保存されたファイルの中から該検索要求を満たすファイルを該インデックスを用いて検索する検索エンジンサーバとを有するシステムにおいてデータにアクセスするための方法であって、
   前記検索エンジンサーバが、前記ファイルサーバ内の各前記ファイルをそれぞれ解析することにより得られた該ファイルごとのインデックス情報からなる前記インデックスを生成する第１のステップと、
   前記ファイルサーバが、自サーバ内の前記ファイルへの操作をモニタし、自サーバ内の前記ファイルが更新された場合であって、該ファイルが所定の更新済ファイルリストに登録されていないときには、該ファイルを該更新済ファイルリストに登録する第２のステップと、
   前記ファイルサーバが、前記検索エンジンサーバからの要求に応じて前記更新済ファイルリストを該検索エンジンサーバに送信すると共に、自己が保持する前記更新済ファイルリストの内容を削除する第３のステップと、
   前記検索エンジンサーバが、前記ファイルサーバから送信される前記更新済ファイルリストに登録された前記ファイルを解析することにより該ファイルの新たなインデックス情報を生成し、生成した該インデックス情報に基づいて前記インデックスを更新する第４のステップと
   を備えることを特徴とするデータにアクセスするための方法。
2. 前記更新済ファイルリストには、登録された前記ファイルへのパス情報が格納される
   ことを特徴とする請求項１に記載の方法。
3. 前記インデックスは前記検索エンジンサーバ内に保存される
   ことを特徴とする請求項１に記載の方法。
4. 複数のファイルを保存するファイルサーバと、
   該ファイルサーバに保存された各前記ファイルのインデックス情報からなるインデックスを生成し、クライアントからの検索要求に応じて、前記ファイルサーバに保存されたファイルの中から該検索要求を満たすファイルを該インデックスを用いて検索する検索エンジンサーバと
   を備え、
   前記検索エンジンサーバは、
   前記ファイルサーバ内の各前記ファイルをそれぞれ解析することにより得られた該ファイルごとのインデックス情報からなる前記インデックスを生成し、
   前記ファイルサーバは、
   自サーバ内の前記ファイルへの操作をモニタし、自サーバ内の前記ファイルが更新された場合であって、該ファイルが所定の更新済ファイルリストに登録されていないときには、該ファイルを該更新済ファイルリストに登録する一方、前記検索エンジンサーバからの要求に応じて前記更新済ファイルリストを該検索エンジンサーバに送信すると共に、自己が保持する前記更新済ファイルリストの内容を削除し、
   前記検索エンジンサーバは、
   前記ファイルサーバから送信される前記更新済ファイルリストに登録された前記ファイルを解析することにより該ファイルの新たなインデックス情報を生成し、生成した該インデックス情報に基づいて前記インデックスを更新する
   ことを特徴とするシステム。
5. 前記更新済ファイルリストには、登録された前記ファイルへのパス情報が格納される
   ことを特徴とする請求項４に記載のシステム。
6. 前記インデックスは前記検索エンジンサーバ内に保存される
   ことを特徴とする請求項４に記載のシステム。

Images