JP2013210698A - ファイル検索システム及びプログラム - Google Patents

Abstract

【課題】複数の検索サーバを有するファイル検索システムに対し、新たな検索サーバを追加してインデクスの再配置を実行する際、分割インデクスの再配置の迅速化実現する手法を提供する。
【解決手段】ファイル検索システムを構成する管理用サーバに、ファイル・ディレクトリパスに対し、コンシステントハッシュ空間上にマッピングするハッシュ値を算出する処理部と、前記テーブルを参照し、前記ファイル・ディレクトリパスに対応付ける仮想インデクスＩＤとインデクスＩＤを決定する処理部と、インデクスＩＤ毎に、ファイル・ディレクトリパスと仮想インデクスＩＤの情報を含む分割インデクスを生成する処理部と、生成された分割インデクスを対応する検索サーバに転送する処理部とを設ける。
【選択図】図１

Description

本発明は、ファイル検索システム及びそのプログラムに関し、特に検索用インデクスの効率的な管理技術に関する。

近年におけるアプリケーションの多様化やストレージの低価格化に伴い、ストレージに保存されるデータ量は爆発的に増加している。これに伴い、企業内で扱うデータ量も膨大になっている。このため、大量に存在するデータを有効活用するためのファイル検索システムの重要性が増大している。

通常、検索対象とするファイル数が膨大である場合、検索インデクス（索引データ）を事前に生成して、検索パフォーマンスの向上を図る手法が用いられる。この他、同じ検索インデクスを複数の検索サーバに設置して負荷を分散する方法、複数の検索サーバ上に検索インデクスを分割して配置し、検索処理を分散する方法等も、検索パフォーマンスの向上を図る方法として一般に採用されている。

このような技術背景において、検索インデクスの生成方法についても、様々な技術が提案されている。例えば特許文献１には、分割された検索インデクスのサイズの偏りをなるべく低減する手法が開示されている。

特開２０１１−７０２５７号公報

Consistent Hashing and Random Trees: Distributed Caching Protocols for Relieving Hot Spots on the World Wide Webhttp://www.akamai.com/dl/technical_publications/ConsistenHashingandRandomTreesDistributedCachingprotocolsforrelievingHotSpotsontheworldwideweb.pdf

しかし、ＩＴ（Information Technology）技術の発展に伴い、現在、ＮＡＳ（Network Attached Storage）上で管理されるファイル数が急増している。この状況に対応するため、迅速な検索サーバの追加が求められている。

本出願人は、このような認識の下、ＮＡＳをクローリングして得た更新用のファイル・ディレクトリパスに対してハッシュ値を計算し、当該ハッシュ値に対してコンシステントハッシュ法を適用して検索インデクスを複数の検索サーバに分散配置する手法を提案している（特願２０１１−２１７８８１号）。

ところで、この先行方式は、検索サーバの追加時に、分割インデクスを構成する全てのファイル・ディレクトリパスについてハッシュ値を計算して、それらをコンシステントハッシュ空間にマッピングし、各ファイル・ディレクトリパスの配置先となるインデクスＩＤを計算する必要がある。

しかし、分割インデクスを構成する全てのファイル・ディレクトリパスに対応するハッシュ値の計算は、計算機に与える演算負荷が大きい。そして、分割インデクスのサイズが大きいほど、再配置に必要な計算時間が長くなる。

本発明は、以上の技術的課題を考慮してなされたものであり、少なくとも、新規の検索サーバをファイル検索システムに追加する場合における分割インデクスの再配置の迅速化実現する手法を提供する。

このような技術的課題を解決するために、本発明者は、例えば特許請求の範囲に記載のシステム構成やプログラムを提案する。

その一例として、複数の検索サーバを有するファイル検索システムであって、(1) コンシステントハッシュ空間上に設定される仮想インデクスＩＤと、検索サーバに対応付けられるインデクスＩＤとの対応関係を記憶するテーブルと、(2) ファイル・ディレクトリパスに対し、前記コンシステントハッシュ空間上にマッピングするハッシュ値を算出する処理部と、前記テーブルを参照し、前記ファイル・ディレクトリパスに対応付ける仮想インデクスＩＤとインデクスＩＤを決定する処理部と、インデクスＩＤ毎に、ファイル・ディレクトリパスと仮想インデクスＩＤの情報を含む分割インデクスを生成する処理部と、生成された分割インデクスを対応する検索サーバに転送する処理部とを有する管理用サーバとを有するものを提案する。

また、他の一例として、複数の検索サーバを有するファイル検索システムであって、(1) コンシステントハッシュ空間上に設定される仮想インデクスＩＤと、検索サーバに対応付けられるインデクスＩＤとの対応関係を記憶するテーブルと、(2) ファイル・ディレクトリパスに対し、前記コンシステントハッシュ空間上にマッピングするハッシュ値を算出する処理部と、前記テーブルを参照し、前記ファイル・ディレクトリパスに対応付ける仮想インデクスＩＤとインデクスＩＤを決定する処理部と、インデクスＩＤ毎に、ファイル・ディレクトリパスとそのハッシュ値の情報を含む分割インデクスを生成する処理部と、生成された分割インデクスを対応する検索サーバに転送する処理部とを有する管理用サーバとを有するものを提案する。

本発明によれば、既存の検索サーバ内における分割インデクスの再分割に際し、計算負荷の大きい演算処理を一部のレコードに限定することができる、又は、そのような演算処理を無くすことができる。このため、分割インデクスの再配置を大幅に効率化することができる。なお、前述した以外の課題、構成及び効果は、以下の実施の形態の説明により明らかにされる。

実施の形態に係る検索システムの概念構成を示す図。 検索サーバの機能構成例を示す図。 分散処理サーバの機能構成例を示す図。 管理サーバの機能構成例を示す図。 インデクスＩＤテーブルのデータ構造例を示す図。 検索サーバ管理テーブルのデータ構造例を示す図。 ファイル管理テーブルのデータ構造例を示す図。 インデクスリストのデータ構造例を示す図。 インデクススキーマのデータ構造例を示す図（第一の形態例）。 システムの初期化フローを示す図。 インデクスＩＤテーブルの初期化フローを示す図。 初期化が終了したインデクスＩＤテーブルの例を説明する図。 スキャナモジュールによるインデクスリストの生成フローを示す図。 インデクス生成モジュールによる分割インデクスの生成フローを示す図。 検索サーバへの分割インデクスの配置フローを示す図。 検索サーバ追加時の処理フローを示す図（第一の形態例）。 検索サーバ追加時の初期化が終了したインデクスＩＤテーブルの例を示す図（第一の形態例）。 検索サーバ追加により影響を受ける仮想インデクスＩＤとインデクスＩＤを格納した一時テーブルの例を示す図（第一の形態例）。 検索サーバの削除時の処理フローを示す図（第一の形態例）。 検索サーバの追加時の処理フローを示す図（第二の形態例）。 検索サーバの追加時に利用されるインデクススキーマのデータ構造例を示す図（第二の形態例）。 検索サーバ追加時に利用される一時テーブルの例を示す図（第二の形態例）。 検索サーバ削除時に実行される処理フローを示す図（第二の形態例）。 検索サーバ削除時の初期化が終了したインデクスＩＤテーブルの例を示す図（第二の形態例）。 検索サーバ削除時に利用される一時テーブルの例を示す図（第二の形態例）。

以下の実施の形態においては、複数のセクションに分割して、実施の形態に係る検索システムの実現に必要な処理機能を説明する。以下の実施の形態において、要素の数等（個数、数値、量、範囲等を含む）に言及する場合、特に明示した場合および原理的に明らかに特定の数に限定される場合等を除き、その特定の数に限定されるものではなく、特定の数以上でも以下でもよい。以下の実施の形態において、その構成要素（要素ステップ等も含む）は、特に明示した場合および原理的に明らかに必須であると考えられる場合等を除き、必ずしも必須のものではない。

また、以下の実施の形態において、各構成、機能、処理部、処理手段等は、それらの一部又は全部を、例えば集積回路その他のハードウェアとして実現しても良い。また、前述した各構成、機能等は、プロセッサがそれぞれの機能を実現するプログラムを解釈し、実行することにより実現しても良い。すなわち、ソフトウェアとして実現しても良い。各機能を実現するプログラム、テーブル、ファイル等の情報は、メモリやハードディスク、SSD（Solid State Drive）等の記憶装置、ICカード、SDカード、DVD等の記憶媒体に格納することができる。

また、制御線や情報線は、説明上必要と考えられるものを示すものであり、製品上必要な全ての制御線や情報線を表すものでない。実際にはほとんど全ての構成が相互に接続されていると考えて良い。

以下、本発明の実施の形態を図面に基づいて詳細に説明する。なお、実施の形態を説明するための全図において、同一の機能を有する部材には同一または関連する符号を付し、その繰り返しの説明は省略する。また、以下の実施の形態では、特に必要なとき以外は同一または同様な部分の説明を原則として繰り返さない。

［形態例１］
［検索システムの全体構成］
図１に、形態例１に係るファイル検索システム（以下「検索システム」という）の構成例を示す。本形態例に係る検索システムは、検索クライアント１００、検索サーバ１０１、ファイルサーバ１０２、分散処理サーバ１０３、管理サーバ１０４から構成され、それらがネットワーク１０５を通じて互いに接続されている。本明細書では、分散処理サーバ１０３、管理サーバ１０４を管理用サーバともいう。

ネットワーク１０５は、ローカルエリアネットワーク（ＬＡＮ）、ワイドエリアネットワーク（ＷＡＮ）等として一般に知られるネットワークを用いて実現することができる。なお、ネットワーク１０５は、有線ネットワークでも無線ネットワークでも構わない。また、検索システムは、１つの領域・国内に構築される必要は無く、複数の地域・国間を跨いで構築されてもよい。なお、図１に示す検索システムの構成は、形態例２に係る検索システムでも共通である。

［検索クライアントの構成］
検索クライアント１００は、Ｗｅｂブラウザを動作させることができる環境がインストールされたコンピュータであり、据え置き型に限らず、携帯型のコンピュータ、携帯情報端末、携帯電話機などの端末を含む。検索クライアント１００は、ＨＴＴＰ（Hypertext Transfer Protocol）等を使用して検索サーバ１０１に対して検索クエリを送信する機能と、検索サーバ１０１から検索結果を取得する機能と、取得した検索結果を利用者に表示する機能とを有している。検索クライアント１００は、検索システム上に複数存在する。

［検索サーバの構成］
図２に、検索サーバ１０１の内部構成例を示す。検索サーバ１０１は、検索クライアント１００から検索クエリを受信して検索処理を実行し、検索結果を返信するサーバである。検索サーバ１０１は、コンピュータを基本構成とする。検索サーバ１０１は、検索システム内に複数台存在し、それぞれがローカルストレージ２０１を保持している。ローカルストレージ２０１内には、ファイルサーバ１０２に保存されるファイル群に基づいて生成された検索用の分割インデクス２０２が保存されている。

検索サーバ１０１には、インデクス管理モジュール２０３と検索モジュール２０４がインストールされている。インデクス管理モジュール２０３は、分割インデクス２０２の管理・更新用のプログラムである。検索モジュール２０４は、検索用の分割インデクスを用いて検索処理を実行するプログラムである。因みに、インデクス管理モジュール２０３と検索モジュール２０４は、検索サーバ１０１のそれぞれにインストールされている。

分割インデクス２０２は、ファイルサーバ１０２上に保存されているファイル群に基づいて、管理サーバ１０４上のインデクス生成管理モジュール４０２及び分散処理サーバ１０３のインデクス生成モジュール３０５により生成される検索用のインデクスである。後述するように、分割インデクス２０２は、コンシステントハッシュ法に基づいて、インデクスＩＤ毎に分割されたインデクスである。なお、インデクスＩＤには分割インデクス２０２が紐付けられており、この紐付きを通じ、検索サーバ１０１に分割インデクス２０２が配置される。検索サーバ１０１上に配置させる分割インデクス２０２の数（インデクスの分割数）は、あらかじめ管理者が決定する。また、分割インデクス２０２は、図９に示すインデクススキーマにより定義される検索インデクスである。

インデクス管理モジュール２０３は、分割インデクス２０２を、検索サーバ１０１に配置・管理するモジュールである。検索サーバ１０１に分割インデクス２０２が既に存在し、その分割インデクス２０２の更新操作を実行する場合、インデクス管理モジュール２０３は、既存の分割インデクス２０２に対して、新規に生成された分割インデクスをマージし、最新の分割インデクスを生成する。

検索サーバ１０１の追加により、システム全体で保持している分割インデクスの数が増加した場合、インデクス管理モジュール２０３は、それぞれの検索サーバ１０１に保存されている既存の分割インデクス２０２をさらに分割する機能を有する。なお、新たに追加された検索サーバ１０１のインデクス管理モジュール２０３は、他の検索サーバ１０１で新規に分割されたインデクスを集約して１つの分割インデクス２０２を生成する機能を有する。

削除対象の検索サーバ１０１におけるインデクス管理モジュール２０３は、自サーバに保持されていた分割インデクス２０２をインデクスＩＤに従って再度分割し、他の検索サーバ１０１の分割インデクス２０２に対して割り振る機能を有する。

検索モジュール２０４は、検索サーバ１０１に配置された分割インデクス２０２を使用して、検索クライアント１００から受け取った検索クエリに対する検索結果を生成し、検索クライアント１００に検索結果を返信する機能を有する検索エンジンである。検索モジュール２０４は、他の検索サーバ群にインストールされているそれぞれの検索モジュール２０４と連携し、検索処理を分散的に実行する機能も有している。

［ファイルサーバの構成］
ファイルサーバ１０２は、企業内等において作成された大量のドキュメントデータを保存するサーバである。ファイルサーバ１０２は、コンピュータを基本構成とする。ファイルサーバ１０２は、検索システム内に複数台存在する。各ファイルサーバ１０２は、分散処理サーバ１０３及び管理サーバ１０４と、ＮＦＳ（Network File System）やＣＩＦＳ（Common Internet File System）等のプロトコルを通じて接続されている。これにより、分散処理サーバ１０３及び管理サーバ１０４上の各モジュールは、ファイルサーバ１０２上に存在するファイルへのアクセス及びファイル情報の取得が可能である。

［分散処理サーバの構成］
図３に、分散処理サーバ１０３の内部構成例を示す。分散処理サーバ１０３は、コンピュータを基本構成とする。分散処理サーバ１０３は、検索システム内に複数台存在する。これら複数の分散処理サーバ１０３は、一つの処理命令を他の分散処理サーバとの連携により分散的に処理する機能を有するサーバ群である。

分散処理サーバ１０３には、分散ファイルシステム３０２と分散処理モジュール３０３と分割インデクスの生成を制御するためのスキャナモジュール３０４、インデクス生成モジュール３０５がインストールされている。分散処理サーバ１０３には、ローカルストレージ３０１が設けられている。

分散ファイルシステム３０２は、ローカルストレージ３０１を用い、共通する一つのファイルシステムを全ての分散処理サーバ１０３から利用可能とするモジュールである。

分散処理モジュール３０３は、管理サーバ１０４のインデクス生成管理モジュール４０２から命令を受けた場合、他の分散処理サーバ１０３上のスキャナモジュール３０４及びインデクス生成モジュール３０５と連携し、分割インデクス２０２を分散的に生成する機能を有するモジュールである。

スキャナモジュール３０４は、ファイルサーバ１０２上のファイル・ディレクトリをスキャンして、ファイル・ディレクトリパス名の一覧とそれらの属性情報を取得する機能と、それらのファイル・ディレクトリが新規生成・更新・削除のいずれの状態であるかを判定し、インデクスリスト３０６を生成する機能とを有するモジュールである。なお、スキャナモジュール３０４は、管理サーバ１０４上のインデクス生成管理モジュール４０３からの命令により動作する。

インデクスリスト３０６は、スキャナモジュール３０４がファイル管理テーブル４０６から、インデクス処理対象のファイル・ディレクトリパス、処理ステータスを抜き出して生成する一時ファイルであり、後述するインデクス生成モジュール３０５により利用される。

スキャナモジュール３０４の機能は、以下の処理機能の実行を通じ実現することができる。例えばＬｉｎｕｘのＦｉｎｄコマンドを利用し、ファイルサーバ１０２上のファイル・ディレクトリパスの一覧とそれらの属性情報を取得する。この後、取得したファイル属性情報のハッシュ値を計算する。次に、任意のタイミングに取得しておいたファイル管理テーブル４０６（後述）に格納されているファイル属性情報のハッシュ値７０２（図７）と計算されたハッシュ値を比較し、その一致・不一致により、インデクス対象となるか否かを判定する。

ハッシュ値が同じであった場合、スキャナモジュール３０４は、該当するファイル・ディレクトリに更新が無いと判定し、インデクシングの対象外とする。ハッシュ値が異なる場合、スキャナモジュール３０４は、ファイル・ディレクトリに更新があったと判定し、インデクスリスト３０６に情報を書き出す。

ファイル管理テーブル４０６にファイル・ディレクトリパス７０１（図７）が存在するにもかかわらず、Ｆｉｎｄコマンドによって該当する情報を取得できない場合、スキャナモジュール３０４は、当該ファイル・ディレクトリパスが「ファイル削除」を示すように、インデクスリスト３０６に情報を書き出す。

インデクス生成モジュール３０５は、スキャナモジュール３０４が出力したインデクスリスト３０６に基づいて、分散処理サーバ１０３上でインデクスを分散的に生成する機能を有するモジュールである。インデクス生成モジュール３０５は、コンシステントハッシュ法に基づいてファイル・ディレクトリパスに対応するハッシュ値を算出し、当該ハッシュ値から対応するインデクスＩＤを求める。また、インデクス生成モジュール３０５は、インデクスＩＤ毎に分割インデクスを生成する。なお、インデクス生成モジュール３０５は、スキャナモジュール３０４と同様に、管理サーバ１０４上のインデクス生成管理モジュール４０２からの命令により動作するモジュールである。

インデクス生成モジュール３０５の処理は、タスクと呼ばれる処理単位に分割され、複数の分散処理サーバ１０３に分散される。なお、タスクは、分散処理サーバ１０３上において、第一の分散処理と第二の分散処理と第三の分散処理に分けて実行される。これらの処理は、大規模分散処理の技術として知られるＭａｐＲｅｄｕｃｅを使用することでも実現できる。その場合、第一の分散処理をＭａｐ処理、第二の分散処理をＳｈｕｆｆｌｅ処理、第三の分散処理をＲｅｄｕｃｅ処理として実現する。詳細動作については後述する。

［管理サーバの構成］
図４に、管理サーバ１０４の内部構成例を示す。管理サーバ１０４は、コンピュータを基本構成とする。管理サーバ１０４は、検索システムを構成する検索サーバ１０１、ファイルサーバ１０２、分散処理サーバ１０３等のサーバ管理機能を有するサーバである。管理サーバ１０４のローカルストレージ４０１には、分割インデクスの生成を制御するためのインデクス生成管理モジュール４０２、システム管理モジュール４０３、インデクスＩＤテーブル４０４、検索サーバ管理テーブル４０５、ファイル管理テーブル４０６がインストールされている。これらのモジュールは、管理サーバ１０４以外に存在してもよい。例えばこれらのモジュールの全部又は一部は、分散処理サーバ１０３上で直接動作可能であってもよい。

インデクス生成管理モジュール４０２は、分散処理サーバ１０３上における分散処理モジュール３０３、スキャナモジュール３０４、及び、インデクス生成モジュール３０５による分割インデクスの生成処理の開始・終了を管理するモジュールである。

システム管理モジュール４０３は、検索システム上に存在するサーバ群の管理や各種テーブルの初期化を実行する機能と、システムの初期化に係るパラメータを管理者が入力するためのユーザインターフェースを提供する機能とを有するモジュールである。

インデクスＩＤテーブル４０４の例を図５に示す。インデクスＩＤテーブル４０４は、仮想インデクスＩＤ５０１とインデクスＩＤ５０２を格納するテーブルであり、ファイル・ディレクトリパスからインデクスＩＤを取得する際に参照される。インデクスＩＤテーブル４０４は、コンシステントハッシュ法の実現手段として利用される。

以下、コンシステントハッシュ法について解説する。コンシステントハッシュ法は、０〜２＾１２８−１（２＾１２８はＭＤ５ハッシュ法に基づく値。ＭＤ５は一例であって、任意のハッシュアルゴリズムを利用することが可能である）の整数の目盛りが振られた円周上にインデクスＩＤのハッシュ値を配置し、円周上を複数の範囲に分割する方法をいう。なお、インデクスＩＤのハッシュ値は、インデクスＩＤを文字列としてＭＤ５等のハッシュ関数を適用することにより求めることができる。

ファイル・ディレクトリパスからインデクスＩＤを取得するには、ファイル・ディレクトリパスから同じハッシュ関数（この例ではＭＤ５）を利用してハッシュ値を求めて円周上に配置し、その位置から反時計回りに回って最初に遭遇するハッシュ値に対応するインデクスＩＤが、ファイル・ディレクトリパスに紐付けるインデクスＩＤとなる。以上が基本的なコンシステントハッシュの概念である。ただし、単純なコンシステントハッシュ法は、各インデクスＩＤに割り当てられるファイル数は、円周上で分割される間隔に依存する。

このため、インデクスＩＤのハッシュ値だけで分割すると、インデクスＩＤの追加・削除を行った場合に、各インデクスＩＤに割り当てられるファイル数に偏りが生じてしまう。これは、インデクスサイズが分割インデクス間で偏ることを意味し、検索パフォーマンスの劣化を招くことになる。このため、インデクスサイズを平準化する必要がある。

インデクスサイズの平準化を行うには、円周上に配置されるインデクスＩＤに対応する点の間隔を短くすることが必要となる。そこで、コンシステントハッシュ法の仮想ノードに相当する仮想インデクスＩＤを生成する。仮想インデクスＩＤは、インデクスＩＤに紐付けられるハッシュ値である。１インデクスＩＤ当たりｎ（ｎは自然数。好ましくは２個以上）個の仮想インデクスＩＤを生成することにより、システム上に存在する分割インデクスのサイズを平準化させる。仮想インデクスＩＤの生成と使用方法については後述する。

検索サーバ管理テーブル４０５の例を図６に示す。検索サーバ管理テーブル４０５は、インデクスＩＤ６０１と、そのインデクスＩＤが紐付けられている分割インデクスが配置されている配置先検索サーバ名６０２が格納されたテーブルである。

ファイル管理テーブル４０６の例を図７に示す。ファイル管理テーブル４０６は、ファイルサーバ１０２上に存在するファイル・ディレクトリパス名７０１の一覧と、それらの属性情報及びその属性情報から生成したファイルハッシュ値７０２を保存・管理するためのテーブルである。スキャナモジュール３０４は、このテーブルに保存されているファイルハッシュ値７０２と、スキャナモジュール３０４のスキャン実行時に取得したファイルの属性情報から生成されるファイルハッシュ値とを比較し、ファイルの更新状態をチェックして、処理ステータス７０３のフィールドに格納する。

インデクスリスト３０６の例を図８に示す。インデクスリスト３０６は、スキャナモジュール３０４が、ファイルサーバのスキャン後にファイル管理テーブル４０６へ処理ステータス７０３を格納し終えた時、インデクス処理対象のファイル・ディレクトリパス、処理ステータスを抜き出すことで生成される。生成後は、インデクス生成モジュール３０５に渡され、分割インデクス２０２の生成に利用される。

図９は、分割インデクス２０２のインデクススキーマ９００の例を示す図である。インデクススキーマ９００には、ファイル・ディレクトリパス９０１をユニークキーとして、ファイルメタ情報９０２、コンテンツデータ９０３、仮想インデクスＩＤ９０４が定義されている。ファイルメタ情報９０２は、ファイルの構成情報に関するデータであり、ファイル固有のメタ情報、及び、ＯＳにより管理されるメタ情報の両方を含む複数の情報である。コンテンツデータ９０２は、ファイル内の本文にあたるデータである。仮想インデクスＩＤ９０４は、コンシステントハッシュ法により得られる仮想インデクスＩＤの値である。仮想インデクスＩＤ９０４をインデクススキーマ９００内で管理することにより、検索サーバ１０１の追加に伴う分割インデクスの再配置を実行する場合にも、再配置に必要なレコード情報のみを既存の分割インデクスの中から効率的に抜き出すことが可能になる。具体的な使い方については後述する。このデータ構造が、本形態例に特徴の一つである。

［検索サーバ管理テーブルの初期化フロー］
図１０に、検索サーバ管理テーブル４０５の初期化フローを示す。ここでは、検索サーバ１０１が２台存在し、各検索サーバ１０１上に２つ分割インデクス２０２を配置する場合を想定する。すなわち、検索システム全体におけるインデクスの分割数は４（＝２×２）である場合を想定する。また、２台の検索サーバ名は、”Ｓｅａｒｃｈ１”と”Ｓｅａｒｃｈ２”であるものとする。

まず、管理者は、検索サーバ管理テーブル４０５の初期化を行うために、検索サーバ１０１の台数、及び、各検索サーバ１０１上に配置する分割インデクス２０２の数からインデクスの分割数を設定する（Ｓ１００１）。

前述したように、この説明では、２台の検索サーバ１０１上に２つずつ分割インデクス２０２を配置する。このため、検索システム全体におけるインデクスの分割数は「４」である。この分割数は、システム管理モジュール４０３に入力される。分割数が入力されると、システム管理モジュール４０３は、各分割インデクス２０２に割り当てるインデクスＩＤを決定する（Ｓ１００２）。本形態例の場合、インデクスＩＤは「０」から始まる昇順の数字とする。すなわち、システム管理モジュール４０３は、「０」、「１」、「２」、「３」の順番にインデクスＩＤを割り振る。

次に、システム管理モジュール４０３は、各インデクスＩＤと検索サーバ１０１との紐付けを実行し（Ｓ１００３）、その結果を検索サーバ管理テーブル４０５に格納する（Ｓ１００４）。本形態例の場合、システム管理モジュール４０３が自動的にインデクスＩＤと検索サーバの紐付けを実行するが、管理者が手動で設定してもよい。

例えば本実施例の場合、検索サーバ管理テーブル４０５のエントリは、「インデクスＩＤ＝０，配置先検索サーバ名＝Ｓｅａｒｃｈ１」、「インデクスＩＤ＝１，配置先検索サーバ名＝Ｓｅａｒｃｈ１」、「インデクスＩＤ＝２，配置先検索サーバ名＝Ｓｅａｒｃｈ２」、「インデクスＩＤ＝３，配置先検索サーバ名＝Ｓｅａｒｃｈ２」の４つとなる。以上で、検索サーバ管理テーブル４０５の初期化が完了する。

［インデクスＩＤテーブルの初期化フロー］
図１１に、インデクスＩＤテーブル４０４の初期化フローを示す。インデクスＩＤテーブル４０４の初期化も検索サーバ管理テーブル４０５の初期化と同様のタイミングで実行される。

まず、管理者が検索サーバ１０１の台数と各検索サーバ１０１上に配置する分割インデクスの数に基づいてインデクスの分割数を設定し（Ｓ１１０１）、インデクスＩＤを決定する（Ｓ１１０２）。

ここでも、インデクスＩＤは、「０」、「１」、「２」、「３」の４つであるものとする。なお、仮想インデクスＩＤの数は、一つのインデクスＩＤに対して２つであるものとする。仮想インデクスＩＤの数は、インデクスＩＤに紐付けられるファイルの数が、最終的に平準化するように定められる任意の固定値である。

次に、システム管理モジュール４０３は、１つのインデクスＩＤに対して任意の仮想インデクスＩＤを生成する（Ｓ１１０３）。例えばインデクスＩＤ「０」に紐付ける仮想インデクスＩＤを「０−０」、「０−１」、インデクスＩＤ「１」に紐付ける仮想インデクスＩＤを「１−０」、「１−１」、インデクスＩＤ「２」に紐付ける仮想インデクスＩＤを「２−０」、「２−１」、インデクスＩＤ「３」に紐付ける仮想インデクスＩＤを「３−０」、「３−１」とする。

続いて、システム管理モジュール４０３は、仮想インデクスＩＤの文字列からハッシュ値を取得する（Ｓ１１０４）。この後、システム管理モジュール４０３は、取得されたハッシュ値をインデクスＩＤテーブル４０４の仮想インデクスＩＤ５０１のフィールドに格納し、そのエントリのインデクスＩＤ５０２のフィールドにこの仮想インデクスＩＤが紐付けられるインデクスＩＤを格納する（Ｓ１１０５）。

図１２に、初期化が終了したインデクスＩＤテーブル４０４（図５）の例を示す。このテーブルを利用することにより、与えられたファイル・ディレクトリパスを、どのインデクスＩＤに紐付けるかを知ることが可能となる。

例えばファイル・ディレクトリパス「／ＦｉｌｅＳｅｒｖｅｒ１／ｔｅｓｔ．ｔｘｔ」のハッシュ値を求めたところ「２９９９９９９９９９９」であった場合、このハッシュ値は、項番３と項番４の間の点に配置される。ここで、コンシステントハッシュ法によるインデクスＩＤの紐付けを、円周上のハッシュ値から反時計周りに最初に遭遇するエントリ点により行うとすると、項番３のエントリの点がヒットする。項番３のインデクスＩＤは「３」であるので、ファイル・ディレクトリパス「／ＦｉｌｅＳｅｒｖｅｒ１／ｔｅｓｔ．ｔｘ」”のインデクスＩＤは「３」となる。

このテーブルはコンシステントハッシュ法の実現方式であり、このテーブルに基づいてファイル・ディレクトリパスからインデクスＩＤを取得し、インデクスＩＤ毎に分割インデクスを生成すると、各々の分割インデクスのサイズ又は紐付けられるファイル数を平準化することができる。

［インデクスリストの生成フロー］
図１３に、スキャナモジュール３０４によるインデクスリストの生成フローを示す。まず、インデクス生成管理モジュール４０２は、スキャナモジュール３０４に対し、インデクスリスト生成開始を指示する（Ｓ１３０１）。

次に、スキャナモジュール３０４は、ファイル管理テーブル４０６にアクセスし、処理ステータスのフィールドに削除を示す「−１」を設定する（Ｓ１３０２）。

その後、スキャナモジュール３０４は、ファイルサーバ１０２に対してＦｉｎｄコマンドを実行する（Ｓ１３０３）。すなわち、スキャンを開始する。

Ｆｉｎｄコマンドにより取得したファイル・ディレクトリパスとその属性情報を取得すると、スキャナモジュール３０４は、各々の属性情報に基づいてハッシュ値を取得する（Ｓ１３０４）。

続いて、スキャナモジュール３０４は、Ｆｉｎｄコマンドにより取得したファイル・ディレクトリパスをキーに使用し、ファイル・ディレクトリパスの有無をファイル管理テーブル４０６に問い合わせる（Ｓ１３０５）。

ファイル・ディレクトリパスがファイル管理テーブル４０６に存在しない場合（Ｓ１３０５で否定結果）、当該ファイルは新規作成であることを意味する。従って、この場合、スキャナモジュール３０４は、ファイル管理テーブル４０６に新たにそのファイル・ディレクトリパス７０１をキーとするエントリを生成し、ファイルハッシュ値７０２と処理ステータス７０３を追加する（Ｓ１３０６）。処理ステータス７０３には、新規生成を示す「１」を追加する。

一方、ファイル・ディレクトリパス７０１がファイル管理テーブル４０６に存在する場合（Ｓ１３０５で肯定結果）、当該ファイルは既にファイル管理テーブル４０６に登録されていることを意味する。この場合、スキャナモジュール３０４は、ハッシュ値のチェックを実行する（Ｓ１３０７）。具体的には、スキャナモジュール３０４は、ファイル管理テーブル４０６からファイル・ディレクトリパス７０１が一致するエントリのファイルハッシュ値７０２を取得し、Ｆｉｎｄコマンドにより取得したハッシュ値と比較する。

ハッシュ値が一致した場合（Ｓ１３０７で肯定結果）、ファイルの更新がなかったことを意味する。従って、この場合、スキャナモジュール３０４は、ファイル・ディレクトリパスが一致するエントリの処理ステータスに「０」を設定する（Ｓ１３０８）。

ハッシュ値が一致しなかった場合（Ｓ１３０７で否定結果）、ファイル更新があったことを意味する。従って、この場合、スキャナモジュール３０４は、ファイルハッシュ値７０２を新たなハッシュ値で上書きし、処理ステータス７０３にファイル更新があったことを示す「２」を上書きする（Ｓ１３０９）。

以上の処理により、指定された階層のファイル処理（「０」＝処理なし、「１」＝インデクス新規生成、「２」＝インデクス更新、「−１」＝インデクスから削除）が確定する。

次に、スキャナモジュール３０４は、ファイル管理テーブル４０６の全てのレコードからファイル・ディレクトリパスと処理ステータスを取得し、インデクスリスト３０６へ書き出す（Ｓ１３１０）。このとき、インデクスリスト３０６には、スキャナモジュール３０４で処理した全てのファイル・ディレクトリパスとファイル処理（「０」、「１」、「２」、「−１」）が書かれている。なお、上記の処理は、Ｆｉｎｄコマンドのオプションパラメータでファイルツリーの階層の範囲を特定して実行することも可能である。

この後、スキャナモジュール３０４は、生成されたインデクスリスト３０６をインデクス生成モジュール３０５に転送すると共に、スキャニングの終了をインデクス生成管理モジュール４０２に通知する（Ｓ１３１１）。インデクス生成モジュール３０５は、インデクスリスト３０６を受け取った後、インデクス生成を開始する。

［分割インデクスの生成フロー］
図１４に、インデクス生成モジュール３０５による分割インデクス２０２の生成フローを示す。なお、図１４に示す処理は、初回実行時の動作である。

インデクス生成モジュール３０５は、スキャナモジュール３０４から転送を受けたインデクスリスト３０６に基づいて、分割インデクス２０２を生成する。インデクス生成モジュール３０５によるインデクスリスト３０６に対する処理は、タスクと呼ばれる複数の処理単位に分割され、複数の分散処理サーバ１０３において分散的に実行される。以下、タスクの生成と、分散処理サーバ１０３で実行される処理動作について説明する。

インデクス生成モジュール３０５は、スキャナモジュール３０４からインデクスリスト３０６を取得する（Ｓ１４０１）。次に、インデクス生成モジュール３０５は、第一の分散処理として、以下に示すＳ１４０３とＳ１４０４の処理をインデクスリスト３０６のエントリ数だけ行う。

まず、インデクス生成モジュール３０５は、インデクスリスト３０６を任意の数に分割する（Ｓ１４０２）。ここでの数は、分散処理サーバ１０３の台数及び処理性能に基づいて決定される。インデクスリスト３０６は、処理対象であるファイル・ディレクトリパス８０１と処理ステータス８０２を記述したテキストファイルである。従って、このファイルを分割する際には、分割数に応じ、単純に任意の行で区切れば、複数のインデクスリストを生成することができる。

分割後のインデクスリスト３０６は、それぞれが、分散処理サーバ１０３上における複数のタスクとして処理される。第一の分散処理における各々のタスク処理では、分割後のインデクスリストに記述されているファイル・ディレクトリパスが取得され、それぞれについてハッシュ値が計算される（Ｓ１４０３）。その後、インデクス生成モジュール３０５は、インデクスＩＤテーブル（図５）への問い合わせにより、計算されたハッシュ値に対応する仮想インデクスＩＤとインデクスＩＤを取得する（Ｓ１４０４）。この際、コンシステントハッシュ法に基づいて、計算されたハッシュ値に対応する仮想インデクスＩＤとインデクスＩＤを決定する。以上で第一のタスク処理が完了する。

第一のタスク処理が全て完了すると、第二のタスク処理が開始される。第二のタスク処理において、インデクス生成モジュール３０５は、インデクスＩＤによるグルーピングを行う。すなわち、インデクス生成モジュール３０５は、インデクスＩＤをキーとし、ファイル・ディレクトリパスと仮想インデクスＩＤと処理ステータスをレコードにもつインデクスリスト３０６に変換する（Ｓ１４０５）。

次に、第三の分散処理において、インデクス生成モジュール３０５は、以下に示すＳ１４０６〜Ｓ１４０９までの処理を実行する。

まず、インデクス生成モジュール３０５は、インデクスＩＤをキーとするインデクスリスト（インデクスＩＤ分だけリストが存在する）に対し、分散処理サーバ１０３上での複数のタスク処理を開始する。

第三の分散処理におけるタスク処理として、インデクス生成モジュール３０５は、インデクスＩＤをキーとするインデクスリストからファイル・ディレクトリパス、仮想インデクスＩＤ、処理ステータスを取得する（Ｓ１４０６）。

次のタスク処理として、インデクス生成モジュール３０５は、処理ステータスをチェックする（Ｓ１４０７）。ここで、処理ステータスが、「１」（＝ファイル新規生成）又は「２」（＝ファイル更新）の場合、各インデクス生成モジュール３０５は、ファイルサーバ１０２からファイルをダウンロードし、コンテンツデータとファイル固有のメタ情報を各ファイルから抽出する（Ｓ１４０８）。

この後、インデクス生成モジュール３０５は、インデクスＩＤをキーとするインデクスリストから取得した仮想インデクスＩＤと共に、ファイル・ディレクトリパスをユニークキーとする各フィールドのデータを登録し、分割インデクスを生成する（Ｓ１４０９）。なお、このとき生成される分割インデクスは、分散処理サーバ１０３のローカルストレージ３０１上に一時的に生成される。

その後、インデクス生成モジュール３０５は、第三のタスク処理により生成された分割インデクスと、インデクスＩＤをキーとするインデクスリストとを１組とし、検索サーバ１０１上のインデクス管理モジュール２０３に転送する（Ｓ１４１０）。最後に、インデクス生成モジュール３０５は、インデクス生成管理モジュール４０２に分割インデクス生成完了通知を出力する（Ｓ１４１１）。この後、インデクス生成モジュール３０５は、処理を終了する。

［検索サーバへの分割インデクスの配置フロー］
図１５に、インデクス生成モジュール３０５により生成された分割インデクスを、検索サーバ１０１上のインデクス管理モジュール２０３が、検索サーバ１０１に配置する際に実行する処理フローを示す。

図１５に示す処理フローは、検索サーバ１０１のインデクス管理モジュール２０３が、インデクス生成モジュール３０５から分割インデクスの転送を受けることで開始される（Ｓ１５０１）。

インデクス管理モジュール２０３は、同じ検索サーバ１０１内に、既に分割インデクスが存在するか否かをチェックする（Ｓ１５０２）。既に分割インデクス２０２が同じ検索サーバ１０１上に存在する場合（Ｓ１５０２で肯定結果）、インデクス管理モジュール２０３は、受信したインデクスリストからレコードを取得し、処理ステータスをチェックする。処理ステータスが、更新、または、削除の場合、既存の分割インデクスから該当するレコードを削除する（Ｓ１５０３）。処理ステータスが更新の場合に、既存の分割インデクスから該当レコードを削除する理由は、分割インデクス２０２上に重複するレコードが存在しないようにするためである。

次に、インデクス管理モジュール２０３は、インデクス生成モジュール３０５から転送されてきた新規の分割インデクス２０２を、既存の分割インデクス２０２にマージし（Ｓ１５０４）、その後、マウントする（Ｓ１５０５）。

一方、分割インデクス２０２が同じ検索サーバ１０１上に存在しなかった場合（Ｓ１５０２で否定結果）、インデクス管理モジュール２０３は、インデクス生成モジュール３０５から転送されてきた分割インデクスを、モジュール２０４にマウントするように要求する（Ｓ１５０５）。これにより、検索モジュール２０４に分割インデクスがマウントされ、検索の実行が可能となる。最後に、インデクス管理モジュール２０３は、インデクス生成管理モジュール４０２に対してマウントの完了を通知する（Ｓ１５０６）。これにより、インデクス管理モジュール２０３による検索サーバ１０１への分割インデクスの配置処理を終了する。

［検索サーバ追加時のフロー］
図１６に、検索システム（図１）に対し、新たな検索サーバ１０１が追加された場合に実行される処理フローを示す。

この処理フローは、システム管理モジュール４０３に対し、管理者が、検索サーバ１０１の追加を入力することで開始される（Ｓ１６０１）。

検索サーバ１０１の追加の入力を受けたシステム管理モジュール４０３は、新規に追加された検索サーバ１０１に対し、新規にインデクスＩＤを割り当てる（Ｓ１６０２）。例えば図１０に示す検索サーバ管理テーブル４０７の初期化フローの状況において、新たに１台の検索サーバ１０１を追加する場合、システム管理モジュール４０３は、インデクスＩＤ「４」、「５」を割り当てる。

次に、システム管理モジュール４０３は、検索サーバ管理テーブル４０５（図６）に、新規に生成されたインデクスＩＤ６０１に対応するエントリを作成し、そのエントリに配置先検索サーバ名６０２を設定する（Ｓ１６０３）。すなわち、検索サーバ管理テーブル４０５の初期化を実行する。

次に、システム管理モジュール４０３は、インデクスＩＤテーブル４０４（図５）に、新規に生成されたインデクスＩＤ５０２に対応付ける仮想インデクスＩＤ５０１のハッシュ値を格納する（Ｓ１６０４）。すなわち、インデクスＩＤテーブル４０４を初期化する。

図１７に、検索サーバ追加時における初期化後のインデクスＩＤテーブル４０４の例を示す。なお、網掛けを付して示すレコードが新たに追加されるレコードであり、白抜きで示すレコードは既存のレコードである。

例えば新たに追加される検索サーバ１０１の検索サーバ名に「Ｓｅａｒｃｈ３」が付与されるものとし、その検索サーバにはインデクスＩＤ「４」、「５」が紐付けられるものとする。このとき、システム管理モジュール４０３は、ＩＤ「４」に紐付けられる文字列「４−０」と「４−１」と、ＩＤ「５」に紐付けられる文字列「５−０」と「５−１」のそれぞれについてハッシュ値を計算する。

図１７は、文字列「４−０」と「４−１」のハッシュ値が例えば「１４５６７８９００００」と「７０１２３４５６７８９」で与えられ、文字列「５−０」と「５−１」のハッシュ値が例えば「０４５６７８９００００」と「４０１２３４５６７８９」で与えられる場合を示している。

このことは、項番３の仮想インデクスＩＤ「１２３４４５６６７８９」、項番５の仮想インデクスＩＤ「２３４５６７８８０００」、項番８の仮想インデクスＩＤ「４５６７８９０００００」、項番１２の仮想インデクスＩＤ「７３８１９１２３２９２」の仮想インデクスＩＤに紐付けられていたファイルが、検索サーバの追加により登録先の変更対象ファイルになることを意味する。

システム管理モジュール４０３は、このＳ１６０４においてインデクスＩＤテーブルを初期化する際、検索サーバの追加により影響を受ける仮想インデクスＩＤとインデクスＩＤの情報を保存し、インデクスＩＤをキーとして、仮想インデクスＩＤを対応付けた図１８に示す一時的なテーブルを生成する（Ｓ１６０５）。図１８の例では、インデクスＩＤに対する仮想インデクスＩＤは一つであるが、実際は複数存在する。このため、実際には、マルチバリュー形式のテーブルとなる。

次に、システム管理モジュール４０３は、検索サーバの追加により影響を受けるインデクスＩＤに対応する検索サーバ上のインデクス管理モジュール２０３に対し、図１８のテーブルで関連付けられている仮想インデクスＩＤの情報を送信し、インデクス管理モジュール２０３が管理する分割インデクスの分割処理の開始を命令する（Ｓ１６０６）。ここで通知される仮想インデクスＩＤは、新たな検索サーバ（すなわち「Ｓｅａｒｃｈ３」）が追加される前の対応付けによる仮想インデクスＩＤである。

システム管理モジュール４０３から仮想インデクスＩＤの情報の通知を受けたインデクス管理モジュール２０３は、受け取った仮想インデクスＩＤの情報に基づいて、既存の分割インデクスを検索する（Ｓ１６０７）。例えばインデクスＩＤ「１」に対し、インデクス管理モジュール２０３は、仮想インデクスＩＤ「１２３４４５６６７８０」を検索し、登録先の変更対象となるファイル・ディレクトリパス、コンテンツデータ、及び、ファイルメタ情報を取得する（Ｓ１６０８）。

さらに、インデクス管理モジュール２０３は、取得したファイル・ディレクトリパスからハッシュ値を計算する（Ｓ１６０９）。また、インデクス管理モジュール２０３は、検索サーバの追加に伴い変化したインデクスＩＤ、及び、仮想インデクスＩＤの情報を、インデクスＩＤテーブル４０４（図５）から取得する（Ｓ１６１０）。このように、本形態例の場合、ファイル・ディレクトリパスに対するハッシュ値の計算は、登録先の変更対象となるファイル・ディレクトリパスについてのみ実行される。

この後、インデクス管理モジュール２０３は、Ｓ１６０８で取得したファイル・ディレクトリパス、ファイルメタ情報、コンテンツデータ、及び、Ｓ１６１０で取得した更新後の仮想インデクスＩＤに基づいて、ローカルストレージ２０１上でインデクスＩＤ毎の分割インデクスを生成する（Ｓ１６１１）。すなわち、ローカルな分割インデクスを生成する。

その後、インデクス管理モジュール２０３は、ローカルストレージ２０１上で生成された分割インデクスを、インデクス生成モジュール３０５を経由して、新たに追加された検索サーバに転送する（Ｓ１６１２）。

この後、インデクス管理モジュール２０３は、新たに追加された検索サーバに転送した分割インデクスに対応するレコード（すなわち、既存の分割インデクスから抜き出したレコード）を既存の分割レコードから削除する（Ｓ１６１３）。削除後、インデクス管理モジュール２０３は、分割インデクスの再分割と転送の完了をインデクス生成管理モジュール４０２に通知する（Ｓ１６１４）。

インデクス生成管理モジュール４０２は、全ての検索サーバ上で分割作業が終了したことを確認すると、新規に追加された検索サーバに対し、複数の分割インデクスをマージするように命令する（Ｓ１６１５）。この命令の受信した検索サーバ１０１においてマージ処理が完了すると、マージされた分散インデクス２０２による検索が可能な状態になる（Ｓ１６１６）。

［検索サーバ削除時のフロー］
図１９に、検索システム（図１）から検索サーバ１０１が削減された場合の処理フローを示す。

この処理フローは、管理者が、検索サーバ１０１の削減をシステム管理モジュール４０３に入力することで開始される（Ｓ１９０１）。なお、削除される検索サーバ上にある分割インデクスは、検索サーバの追加フロー（図１６）の場合とは異なり、仮想インデクスＩＤの全てが変更されるため、全てのレコードに対して仮想インデクスＩＤの再計算が必要となる。

次に、システム管理モジュール４０３は、削減対象としての配置先検索サーバ名に対応付けられているインデクスＩＤ６０１を検索サーバ管理テーブル４０５（図６）から取得し、そのインデクスＩＤに紐付けられている仮想インデクスＩＤをインデクスＩＤテーブル４０４（図５）から取得する（Ｓ１９０２）。その後、システム管理モジュール４０３は、Ｓ１９０２で取得した仮想インデクスＩＤをインデクスＩＤテーブル４０４（図５）から削除する（Ｓ１９０３）。

次に、システム管理モジュール４０３は、削減対象である検索サーバ１０１上のインデクス管理モジュール２０３に対し、分割インデクスの再分割を指示する（Ｓ１９０４）。

再分割指示を受けたインデクス管理モジュール２０３は、分割インデクス２０２に登録されているファイル・ディレクトリパスを先頭から終端まで順に取得する（Ｓ１９０５）。

次に、インデクス管理モジュール２０３は、取得したファイル・ディレクトリパスからハッシュ値を計算し（Ｓ１９０６）、検索サーバの削除に伴い更新されるインデクスＩＤと仮想インデクスＩＤの情報を、インデクスＩＤテーブル４０４（図５）から取得する（Ｓ１９０７）。

その後、削除対象であるインデクス管理モジュール２０３は、分割インデクス２０２から、ファイル・ディレクトリパスのエントリのインデクスデータを抜き出し、取得したインデクスＩＤに紐付ける新規の分割インデクスを生成、または、その分割インデクスにインデクスデータを追加し、再配置先でのマージ用の分割インデクスを生成する（Ｓ１９０８）。

この分割処理が終わった時点において、削除対象である検索サーバ１０１のローカルストレージ２０１上には、インデクスＩＤ毎のマージ用の分割インデクスが複数存在している。その後、削除対象である検索サーバ１０１にあるインデクス管理モジュール２０３は、検索サーバ管理テーブル４０５に問い合わせを行い、インデクスＩＤに紐付ける検索サーバ上のインデクス管理モジュール２０３に対し、マージ用の分割インデクスを転送する（Ｓ１９０９）。

続いて、削除対象である検索サーバ１０１のインデクス管理モジュール２０３は、システム管理モジュール４０３に対し、インデクスＩＤ毎の分割インデクスの生成処理が完了したことを通知する（Ｓ１９１０）。

この通知を受信したシステム管理モジュール４０３は、再配置対象となる全ての検索サーバ１０１上のインデクス管理モジュール２０３に対し、インデクスのマージ処理を指示する（Ｓ１９１１）。

指示を受けた各インデクス管理モジュール２０３は、受信した分割インデクスのマージ処理を実行し、最新の分割インデクス２０２を生成する（Ｓ１９１２）。以上の処理が全て完了すると、削除対象である検索サーバ１０１をシステム上から削除する（Ｓ１９１３）。すなわち、削除対象である検索サーバ１０１を、ネットワーク１０５から物理的又は電気的に切り離す。

［形態例１の効果］
前述したように、形態例１の場合には、分割インデクス２０２のデータ構造を規定するインデクススキーマ９００として、図９に示すデータ構造のインデクススキーマを使用する。このため、分割インデクス２０２を構成する各レコードのフィールドには、ファイル・ディレクトリパスと、仮想インデクスＩＤが含まれる。

従って、既存の検索サーバ１０１は、システム管理モジュール４０３から通知を受けた仮想インデクスＩＤに基づいて自身が管理する各分割インデクスを検索し、再配置対象のファイル・ディレクトリパスを特定することができる。このように、本形態例の場合には、ハッシュ値を計算する前に、再配置の影響を受けるファイル・ディレクトリパスを特定することができる。

このため、分割インデクスの再分割に関連して検索サーバ１０１で実行されるハッシュ値の計算処理は、分割インデクス２０２の一部のレコードだけに限定することができる。勿論、本実施例の場合、分割インデクス２０２の再分割に伴うハッシュ値の計算に必要とされる計算負荷は、分割インデクス２０２の全レコードについてハッシュ値を計算する場合に比して格段に小さく済む。結果的に、分割インデクスの再配置処理の効率化を実現することができる。

［形態例２］
続いて、形態例２に係る検索システムについて説明する。なお、形態例２に係る検索システムのハードウェア構成は、基本的に、形態例１と同様である。形態例２に係る検索システムと、形態例１に係る検索システムとの違いは、検索サーバ１０１を検索システムに追加する場合の処理動作と、検索サーバ１０１を検索システムから削除する（取り外す）場合の処理動作である。以下では、形態例２に特有の処理機能についてのみ説明する。

［検索サーバ追加時のフロー］
形態例１の処理動作の場合（図１６）、新たに追加された検索サーバ１０１に管理を移行するファイル・ディレクトリパスのみに限るものの、分割インデクスの分割元となる各検索サーバ１０１において、ファイル・ディレクトリパスからハッシュ値を計算する必要があった。

本形態例においては、分割インデクス２０２の再分割に際し、検索サーバ１０１におけるハッシュ値の計算を不要とする仕組みを説明する。

図２０に、検索システム（図１）に対し、新たな検索サーバ１０１が追加された場合に実行される本形態例の処理フローを示す。検索サーバ１０１におけるハッシュ値の計算を不要とするために、本形態例に係る検索サーバ１０１は、図９に示す構造のインデクススキーマ９００に代え、図２１に示す構造のインデクススキーマ２１００を使用する。ここで、インデクススキーマ２１００は、仮想インデクスＩＤ９０４に代え、ファイル・ディレクトリパスから計算したハッシュ値２１０４を格納する。この点が、図９に示すインデクススキーマ９００との違いである。

図２０に示す処理フローは、システム管理モジュール４０３に対し、管理者が、検索サーバ１０１の追加を入力することで開始される（Ｓ２００１）。

検索サーバ１０１の追加の入力を受けたシステム管理モジュール４０３は、新規に追加された検索サーバ１０１に対し、新規にインデクスＩＤを割り当てる（Ｓ２００２）。例えば図１０に示す検索サーバ管理テーブル４０７の初期化フローの状況において、新たに１台の検索サーバ１０１を追加する場合、システム管理モジュール４０３は、インデクスＩＤ「４」、「５」を割り当てる。

次に、システム管理モジュール４０３は、検索サーバ管理テーブル４０５（図６）に、新規に生成されたインデクスＩＤ６０１のエントリを作成し、そのエントリに配置先検索サーバ名６０２を設定する（Ｓ２００３）。すなわち、検索サーバ管理テーブル４０５の初期化を実行する。

その後、システム管理モジュール４０３は、インデクスＩＤテーブル４０４（図５）に、新規に生成されたインデクスＩＤ５０２に対応付ける仮想インデクスＩＤ５０１のハッシュ値を格納する（Ｓ２００４）。すなわち、インデクスＩＤテーブル４０４を初期化する。この初期化処理により、インデクスＩＤテーブル４０４は、図１７に示す状態になったものとする。

なお、システム管理モジュール４０３は、インデクスＩＤテーブル４０４の初期化に際し、検索サーバの追加により再配置の対象となるハッシュ空間と、そのハッシュ空間のハッシュ値に紐付けられるインデクスＩＤと仮想インデクスＩＤとを、再配置のターゲットとなるインデクスＩＤをキーとして関連付けた一時的なテーブルを生成する（Ｓ２００５）。図２２に、Ｓ２００５で生成されるテーブル例２２００を示す。

図２２に示すテーブル例２２００では、検索サーバ１０１の追加により再配置の対象となるインデクスＩＤを「再配置ターゲットインデクスＩＤ２２０１」と示し、同じく再配置の対象となるハッシュ空間を「再配置ターゲットハッシュ空間２２０２」と示し、そのハッシュ空間に紐付ける仮想インデクスＩＤを「変更後仮想インデクスＩＤ２２０３」と示し、同じくハッシュ空間に紐付けるインデクスＩＤを「変更後インデクスＩＤ２２０４」と示す。図２２の場合、インデクスＩＤに対する仮想インデクスＩＤは一つであるが、実際は複数存在する。このため、実際には、マルチバリュー形式のテーブルとなる。

次に、システム管理モジュール４０３は、再配置ターゲットインデクスＩＤに対応する検索サーバ上のインデクス管理モジュール２０３に対し、再配置ターゲットハッシュ空間２２０２、変更後仮想インデクスＩＤ２２０３、変更後インデクスＩＤ２２０４を１組とする情報を送信し、分割開始命令を出す。（Ｓ２００６）。

システム管理モジュール４０３から情報の通知を受けたインデクス管理モジュール２０３は、受け取った再配置ターゲットハッシュ空間２２０２の情報に基づいて、既存の分割インデクスのファイル・ディレクトリパスハッシュ値２１０４のフィールドを数値範囲検索する（Ｓ２００７）。この際、インデクス管理モジュール２０３は、受け取った再配置ターゲットハッシュ空間２２０２に含まれるファイル・ディレクトリパスハッシュ値２１０４を有するレコードの情報を取得する（Ｓ２００８）。

次に、インデクス管理モジュール２０３は、Ｓ２００８で取得したレコード内のファイル・ディレクトリパス９０１、ファイルメタ情報９０２及びコンテンツデータ９０３と、システム管理モジュール４０３から取得した変更後仮想インデクスＩＤ２２０３とに基づいて、ローカルストレージ上でインデクスＩＤ毎の分割インデクスを生成する（Ｓ２００９）。この分割処理の終了時点において、削除ターゲットである検索サーバ１０１のローカルストレージ２０１上には、インデクスＩＤ毎の分割インデクスが複数存在する。

その後、インデクス管理モジュール２０３は、ローカルストレージ２０１上で生成された分割インデクスを、インデクス生成モジュール３０５を経由して、新たに追加された検索サーバに転送する（Ｓ２０１０）。

この後、インデクス管理モジュール２０３は、新たに追加された検索サーバに転送した分割インデクスに対応するレコード（すなわち、既存の分割インデクスから抜き出したレコード）を既存の分割レコードから削除する（Ｓ２０１１）。削除後、インデクス管理モジュール２０３は、分割インデクスの再分割と転送の完了をインデクス生成管理モジュール４０２に通知する（Ｓ２０１２）。

インデクス生成管理モジュール４０２は、全ての検索サーバ上で分割作業が終了したことを確認すると、新規に追加された検索サーバに対し、複数の分割インデクスをマージするように命令する（Ｓ２０１３）。この命令を受信した検索サーバ１０１においてマージ処理が完了すると、マージされた分散インデクス２０２による検索が可能な状態になる（Ｓ２０１４）。

［検索サーバ削除時のフロー］
図２３に、検索システム（図１）から検索サーバ１０１が削減された場合の処理フローを示す。この形態例の場合、検索サーバの削除時にも、ハッシュ値の計算は不要となる。

この処理フローは、管理者が、検索サーバ１０１の削減をシステム管理モジュール４０３に入力することで開始される（Ｓ２３０１）。

次に、システム管理モジュール４０３は、検索サーバ管理テーブル４０５（図６）から削減される検索サーバが、配置先検索サーバ名になっているエントリのインデクスＩＤ６０１を取得し、そのインデクスＩＤに紐付けられている仮想インデクスＩＤを取得する（Ｓ２３０２）。

その後、システム管理モジュール４０３は、Ｓ２３０２で取得した仮想インデクスＩＤをインデクスＩＤテーブル４０４（図５）から削除する（Ｓ２３０３）。図１７に対応する図２４に、インデクスＩＤテーブル４０４から検索サーバ「Ｓｅａｒｃｈ３」を削除した場合のインデクスＩＤテーブルの状態を示す。

なお、システム管理モジュール４０３は、インデクスＩＤテーブル４０４の初期化に際し、検索サーバの削除により再配置の対象となるハッシュ空間と、そのハッシュ空間のハッシュ値に紐付けられるインデクスＩＤと仮想インデクスＩＤとを、再配置のターゲットとなるインデクスＩＤをキーとして関連付けた一時的なテーブルを生成する（Ｓ２３０４）。図２５に、Ｓ２３０４で生成されるテーブル例２２００を示す。このテーブルの構造は、図２２と同じである。

次に、システム管理モジュール４０３は、再配置ターゲットインデクスＩＤに対応する検索サーバ上のインデクス管理モジュール２０３に対し、再配置ターゲットハッシュ空間２２０２、変更後仮想インデクスＩＤ２２０３、変更後インデクスＩＤ２２０４を１組とする情報を送信し、分割開始命令を出す（Ｓ２３０５）。

システム管理モジュール４０３から情報の通知を受けたインデクス管理モジュール２０３は、受け取った再配置ターゲットハッシュ空間２２０２の情報に基づいて、既存の分割インデクスのファイル・ディレクトリパスハッシュ値２１０４のフィールドを数値範囲検索する（Ｓ２３０６）。この際、インデクス管理モジュール２０３は、受け取った再配置ターゲットハッシュ空間２２０２に含まれるファイル・ディレクトリパスハッシュ値２１０４を有するレコードの情報を取得する（Ｓ２３０７）。

次に、インデクス管理モジュール２０３は、Ｓ２３０７で取得したレコード内のファイル・ディレクトリパス９０１、ファイルメタ情報９０２及びコンテンツデータ９０３と、システム管理モジュール４０３から取得した変更後仮想インデクスＩＤ２２０３とに基づいて、ローカルストレージ上でインデクスＩＤ毎の分割インデクスを生成する（Ｓ２３０８）。この分割処理の終了時点において、削除ターゲットである検索サーバ１０１のローカルストレージ２０１上には、インデクスＩＤ毎の分割インデクスが複数存在する。

その後、削除対象である検索サーバ１０１にあるインデクス管理モジュール２０３は、検索サーバ管理テーブル４０５に問い合わせを行い、インデクスＩＤに紐付ける検索サーバ上のインデクス管理モジュール２０３に対し、分割インデクスを転送する（Ｓ２３０９）。

続いて、インデクス管理モジュール２０３は、システム管理モジュール４０３に対し、インデクスＩＤ毎の分割インデクスの生成処理が完了したことを通知する（Ｓ２３１０）。

この通知を受信したシステム管理モジュール４０３は、再配置対象となる全ての検索サーバ１０１上のインデクス管理モジュール２０３に対し、インデクスのマージ処理を指示する（Ｓ２３１１）。

指示を受けた、各インデクス管理モジュール２０３は、マージ処理を実行し、最新の分割インデクス２０２を生成する（Ｓ２３１２）。以上の処理が全て完了すると、削除対象である検索サーバ１０１をシステム上から削除する（Ｓ２３１３）。すなわち、削除対象である検索サーバ１０１を、ネットワーク１０５から物理的又は電気的に切り離す。

［形態例２の効果］
前述したように、形態例２の場合には、分割インデクス２０２のデータ構造を規定するインデクススキーマ２１００として、図２１に示すデータ構造のインデクススキーマを使用する。このため、分割インデクス２０２を構成する各レコードのフィールドには、ファイル・ディレクトリパスと、ファイル・ディレクトリパスのハッシュ値が含まれている。

この形態例２の場合、システム管理モジュール４０３は、仮想インデクスＩＤではなく、再配置ターゲットハッシュ空間２２０２の情報を、インデクス管理モジュール２０３に与える。そして、インデクス管理モジュール２０３は、受け取った再配置ターゲットハッシュ空間２２０２に属するファイル・ディレクトリパスハッシュ値を有するレコードを分割インデクス２０２から検索し、移行対象のファイル・ディレクトリパスを特定する。

このように、本形態例の場合には、分割インデクスの再分割に際し（検索サーバ１０１の追加時だけでなく、削除時にも）、検索サーバ１０１におけるハッシュ値の計算処理が不要となる。このため、分割インデクス２０２の全レコードについてハッシュ値を計算する場合に比して、分割インデクスの再配置処理を一段と効率化することができる。

１００…検索クライアント
１０１…検索サーバ
１０２…ファイルサーバ
１０３…分散処理サーバ
１０４…管理サーバ
１０５…ネットワーク
２０１…ローカルストレージ
２０２…分割インデクス
２０３…インデクス管理モジュール
２０４…検索モジュール
３０１…ローカルストレージ
３０２…分散ファイルシステム
３０３…分散処理モジュール
３０４…スキャナモジュール
３０５…インデクス生成モジュール
３０６…インデクスリスト
４０１…ローカルストレージ
４０２…インデクス生成管理モジュール
４０３…システム管理モジュール
４０４…インデクスＩＤテーブル
４０５…検索サーバ管理テーブル
４０６…ファイル管理テーブル

Claims (8)

1. 複数の検索サーバを有するファイル検索システムにおいて、
   コンシステントハッシュ空間上に設定される仮想インデクスＩＤと、検索サーバに対応付けられるインデクスＩＤとの対応関係を記憶するテーブルと、
   ファイル・ディレクトリパスに対し、前記コンシステントハッシュ空間上にマッピングするハッシュ値を算出する処理部と、前記テーブルを参照し、前記ファイル・ディレクトリパスに対応付ける仮想インデクスＩＤとインデクスＩＤを決定する処理部と、インデクスＩＤ毎に、ファイル・ディレクトリパスと仮想インデクスＩＤの情報を含む分割インデクスを生成する処理部と、生成された分割インデクスを対応する検索サーバに転送する処理部とを有する管理用サーバと
   を有するファイル検索システム。
2. 請求項１に記載のファイル検索システムにおいて、
   検索サーバの追加時、
   前記管理用サーバが、追加に伴い対応関係に変更が生じる仮想インデクスＩＤとインデクスＩＤの情報を取得し、分割インデクスの分割命令と共に既存の検索サーバに通知し、
   分割インデクスの分割命令の通知を受けた前記既存の検索サーバが、通知を受けた仮想インデクスＩＤに基づいて前記分割インデクスのレコードを検索し、検索にヒットしたレコードについてのみファイル・ディレクトリパスのハッシュ値を計算し、当該ハッシュ値と前記管理用サーバから取得した変更後の仮想インデクスＩＤとインデクスＩＤの対応関係に基づいて、更新後のインデクスＩＤ用のローカルな分割インデクスを生成する
   ことを特徴とするファイル検索システム。
3. 複数の検索サーバを有するファイル検索システムにおいて、
   コンシステントハッシュ空間上に設定される仮想インデクスＩＤと、検索サーバに対応付けられるインデクスＩＤとの対応関係を記憶するテーブルと、
   ファイル・ディレクトリパスに対し、前記コンシステントハッシュ空間上にマッピングするハッシュ値を算出する処理部と、前記テーブルを参照し、前記ファイル・ディレクトリパスに対応付ける仮想インデクスＩＤとインデクスＩＤを決定する処理部と、インデクスＩＤ毎に、ファイル・ディレクトリパスとそのハッシュ値の情報を含む分割インデクスを生成する処理部と、生成された分割インデクスを対応する検索サーバに転送する処理部とを有する管理用サーバと
   を有するファイル検索システム。
4. 請求項３に記載のファイル検索システムにおいて、
   検索サーバの追加時、
   前記管理用サーバが、追加に伴い再配置の対象となるハッシュ空間と、変更後に当該空間に紐付けられる仮想インデクスＩＤ及びインデクスＩＤの情報を取得し、分割インデクスの分割命令と共に既存の検索サーバに通知し、
   分割インデクスの分割命令の通知を受けた前記既存の検索サーバが、通知を受けたハッシュ空間に基づいて前記分割インデクスのレコードを検索し、前記ハッシュ空間に属するハッシュ値を有するレコードの情報と、前記管理用サーバから通知を受けた変更後の仮想インデクスＩＤとに基づいて、更新後のインデクスＩＤ用のローカルな分割インデクスを生成する
   ことを特徴とするファイル検索システム。
5. 複数の検索サーバと、コンシステントハッシュ空間上に設定される仮想インデクスＩＤと、検索サーバに対応付けられるインデクスＩＤとの対応関係を記憶するテーブルとを有するファイル検索システムを構成するコンピュータに、
   ファイル・ディレクトリパスに対し、前記コンシステントハッシュ空間上にマッピングするハッシュ値を算出する処理、
   前記テーブルを参照し、前記ファイル・ディレクトリパスに対応付ける仮想インデクスＩＤとインデクスＩＤを決定する処理、
   インデクスＩＤ毎に、ファイル・ディレクトリパスと仮想インデクスＩＤの情報を含む分割インデクスを生成する処理、
   生成された分割インデクスを対応する検索サーバに転送する処理
   を実行させるプログラム。
6. 請求項５に記載のプログラムにおいて、
   検索サーバの追加時、
   管理用サーバとしてのコンピュータに、追加に伴い対応関係に変更が生じる仮想インデクスＩＤとインデクスＩＤの情報を取得し、分割インデクスの分割命令と共に既存の検索サーバに通知する処理を実行させ、
   分割インデクスの分割命令の通知を受けた既存の検索サーバとしてのコンピュータに、通知を受けた仮想インデクスＩＤに基づいて前記分割インデクスのレコードを検索し、検索にヒットしたレコードについてのみファイル・ディレクトリパスのハッシュ値を計算し、当該ハッシュ値と前記管理用サーバから取得した変更後の仮想インデクスＩＤとインデクスＩＤの対応関係に基づいて、更新後のインデクスＩＤ用のローカルな分割インデクスを生成する処理を実行させる
   ことを特徴とするプログラム。
7. 複数の検索サーバと、コンシステントハッシュ空間上に設定される仮想インデクスＩＤと、検索サーバに対応付けられるインデクスＩＤとの対応関係を記憶するテーブルとを有するファイル検索システムを構成するコンピュータに、
   ファイル・ディレクトリパスに対し、前記コンシステントハッシュ空間上にマッピングするハッシュ値を算出する処理、
   前記テーブルを参照し、前記ファイル・ディレクトリパスに対応付ける仮想インデクスＩＤとインデクスＩＤを決定する処理、
   インデクスＩＤ毎に、ファイル・ディレクトリパスとそのハッシュ値の情報を含む分割インデクスを生成する処理、
   生成された分割インデクスを対応する検索サーバに転送する処理
   を実行させるプログラム。
8. 請求項７に記載のプログラムにおいて、
   検索サーバの追加時、
   管理用サーバとしてのコンピュータに、追加に伴い再配置の対象となるハッシュ空間と、変更後に当該空間に紐付けられる仮想インデクスＩＤ及びインデクスＩＤの情報を取得し、分割インデクスの分割命令と共に既存の検索サーバに通知する処理を実行させ、
   分割インデクスの分割命令の通知を受けた既存の検索サーバとしてのコンピュータに、通知を受けたハッシュ空間に基づいて前記分割インデクスのレコードを検索し、前記ハッシュ空間に属するハッシュ値を有するレコードの情報と、前記管理用サーバから通知を受けた変更後の仮想インデクスＩＤとに基づいて、更新後のインデクスＩＤ用のローカルな分割インデクスを生成する処理を実行させる
   ことを特徴とするプログラム。

Images