JP5898026B2 - 分散検索システムにおけるストレージ容量平準化方法 - Google Patents

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

特許文献１によれば、確率的に分割されたインデクスに登録されるドキュメント数が均等となることから、インデクスのサイズも平準化されることが期待されているが、企業で利用するデータにはドキュメント以外のデータも数多く含まれる。例えば、サーバログやメールアーカイブデータ等は、著しくファイルサイズが大きいものが含まれることがあり、分割インデクスのサイズが平準化されない問題がある。そのため、各検索サーバのディスクサイズを見積もることが難しく、見積もったとしてもインデクスサイズの偏りにより、ディスク容量を無駄にする可能性が出てくる。

この技術課題を解決するために、本発明は、検索用のインデクスの生成に際し、ファイルデータからメタ情報とコンテンツを分離し、コンテンツは１つ又は複数のコンテンツサーバに格納し、メタ情報は分割インデクスに配置する。この際、メタ情報の割り当て先をコンシステントハッシュ法に基づいて決定する。

本発明によれば、ファイルのメタ情報で構成される分割インデクスのサイズは、ファイルのサイズ（特に、コンテンツのサイズ）によらず、割り当てられたファイル数に応じて一定となる。このため、全ての分割インデクスを概ね同じサイズに揃えることができる。かくして、本発明では、検索サーバにおけるディスク容量の見積もりが容易になり、かつ、ディスク容量に無駄が生じる可能性を低減することができる。なお、上述した以外の課題、構成及び効果は、以下の実施例の説明により明らかにされる。

実施の形態に係る検索システムの概念構成を示す図。 検索サーバの機能構成例を示す図。 分散処理サーバの機能構成例を示す図。 コンテンツサーバの機能構成例を示す図。 管理サーバの機能構成例を示す図。 インデクスＩＤテーブルのデータ構造例を示す図。 検索サーバ管理テーブルのデータ構造例を示す図。 ファイル管理テーブルのデータ構造例を示す図。 インデクスリストのデータ構造例を示す図。 インデクススキーマのデータ構造例を示す図。 コンテンツ管理テーブルのデータ構造例を示す図。 検索サーバ管理テーブルの初期化フローを示す図。 インデクスＩＤテーブルの初期化フローを示す図。 初期化終了後のインデクスＩＤテーブル例を説明する図。 スキャナモジュールによるインデクスリストの生成フローを示す図。 インデクス生成モジュールによる分割インデクスの生成フローを示す図。 検索サーバへの分割インデクスの配置フローを示す図。 検索サーバ内の検索フローを示す図。 コンテンツ配置変更フローを示す図。

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

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

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

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

［検索システムの全体構成］
図１に、本実施例に係る検索システムの構成例を示す。本実施例に係る検索システムは、検索クライアント１００、検索サーバ１０１、ファイルサーバ１０２、分散処理サーバ１０３、コンテンツサーバ１０４、管理サーバ１０５から構成され、それらがネットワーク１０６を通じて互いに接続されている。ネットワーク１０６は、ローカルエリアネットワーク（ＬＡＮ）、ワイドエリアネットワーク（ＷＡＮ）等として一般に知られるネットワークを用いて実現することができる。なお、ネットワーク１０６は、有線ネットワークでも無線ネットワークでも構わない。また、検索システムは、１つの領域・国内に構築される必要は無く、複数の地域・国間を跨いで構築されてもよい。

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

［検索サーバの構成］
図２に、検索サーバ１０１の内部構成例を示す。検索サーバ１０１は、検索クライアント１００から検索クエリを受信して検索処理を実行し、検索結果を返信するサーバコンピュータである。検索サーバ１０１は、検索システム内に複数台存在し、それぞれがローカルストレージ２０１を保持している。ローカルストレージ２０１内には、ファイルサーバ１０２に保存されるファイル群に基づいて生成された検索用の分割インデクス２０２が保存されている。検索サーバ１０１には、インデクス管理モジュール２０３と検索モジュール２０４がインストールされている。インデクス管理モジュール２０３は、分割インデクス２０２の管理・更新用のプログラムである。検索モジュール２０４は、検索用の分割インデクスを用いて検索処理を実行するプログラムである。因みに、インデクス管理モジュール２０３と検索モジュール２０４は、検索サーバ１０１のそれぞれにインストールされている。また、検索サーバ１０１にはコンテンツ監視モジュール２０５がインストールされており、ローカルストレージ２０１の容量をチェック・取得する機能と、その取得したディスク情報を基に、後述するコンテンツ管理モジュール５０７（図５）と連携して分割インデクス内のコンテンツデータの管理を行う機能とを備えている。

分割インデクス２０２は、ファイルサーバ１０２上に保存されているファイル群に基づいて、管理サーバ１０５上のインデクス生成管理モジュール５０２（図５）及び分散処理サーバ１０３のインデクス生成モジュール３０５（図３）により生成される検索用のインデクスである。後述するように、分割インデクス２０２は、コンシステントハッシュ法に基づいて、インデクスＩＤ毎に分割されたインデクスである。なお、インデクスＩＤには分割インデクス２０２が紐付けられており、この紐付きを通じ、検索サーバ１０１に分割インデクス２０２が配置される。検索サーバ１０１上に配置させる分割インデクス２０２の数（インデクスの分割数）は、あらかじめ管理者が決定する。また、分割インデクス２０２は、後述するスキーマで定義される検索インデクスである。なお、分割インデクス２０２を生成する場合、ファイルに含まれるコンテンツデータを格納する／しないを選択的に実行することが可能である。コンテンツデータを格納しない場合、ファイルメタ情報のみを含む分割インデクスが生成される。この場合、分割インデクス２０２のサイズは、登録されたドキュメント数に応じて一定となる。しかも、コンシステントハッシュ法を用いると、分割インデクスに割り当てられる登録ドキュメント数（すなわち、ファイルメタ情報の数）が平準化されるため、分割インデクス２０２の配置に必要なディスクサイズの見積もりが容易になる。

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

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

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

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

コンテンツ監視モジュール２０５は、ローカルストレージ２０１のディスク空き容量をチェックする機能を備えている。また、コンテンツ監視モジュール２０５は、分割インデクス内の情報を使って、当該分割インデクスに登録されているファイルのコンテンツデータの合計サイズを計算する機能も備えている。なお、ファイルメタ情報には、ファイルサイズ情報が含まれているものとする。これらの機能を使い、コンテンツ監視モジュール２０５は、後述するコンテンツ管理モジュール５０７（図５）と連携し、各検索サーバ１０１上のローカルストレージ２０１に空き容量がある場合は、コンテンツサーバ１０４からコンテンツデータを分割インデクス２０２内に配置変更し、各検索サーバ１０１のディスク容量に最適な分割インデクスの配置を可能している。

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

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

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

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

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

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

インデクスリスト３０６は、スキャナモジュール３０４がファイル管理テーブル５０６（図５）に格納したファイルメタ情報と、インデクス処理対象のファイルを特定するファイルパスと、処理ステータスとが書き込まれた一時ファイルであり、後述するインデクス生成モジュール３０５により利用される。

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

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

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

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

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

[コンテンツサーバの構成]
図４にコンテンツサーバ１０４の内部構成例を示す。コンテンツサーバ１０４には、ローカルストレージ４０１が設けられている。ローカルストレージ４０１には、分散データベース４０２がインストールされている。分散データベース４０２上には、コンテンツ管理テーブル４０３がある。コンテンツ管理テーブル４０３は、コンテンツデータから生成したハッシュ値をキーとして、そのファイルのコンテンツデータを格納しておくテーブルである。コンテンツサーバ１０４は、検索サーバ１０１からの要求に応じて、コンテンツ情報の取得・送信を行う。また、後述する管理サーバ１０５上のコンテンツ管理モジュール５０７（図５）からの要求で、コンテンツ情報を取得して、検索サーバ１０１上の分割インデクス２０２へコンテンツデータを移動させる機能も備えている。また、分散データベース４０２にコンテンツデータを格納する際、コンテンツデータのハッシュ値をキーとして管理することで、ファイルサーバ上で異なるファイルパスで保存されている、同じコンテンツ情報を持つファイルの重複を検出・排除し、ストレージ要領を削減することが可能になっている。なお、コンテンツサーバ１０４上に配置される分散データベース４０２は、一般的にスケーラブルなソフトウェアであり、複数のコンテンツサーバに対して一つのデータベースを構築することが可能である。その場合、分散データベースプログラムは、各コンテンツサーバのストレージ容量を均等に利用するため、分散データベースを利用する外部プログラムは、ストレージ分散を考慮することなくデータを格納することが可能である。

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

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

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

コンテンツ管理モジュール５０７は、検索サーバ１０１上のコンテンツ監視モジュール２０５と連携し、検索サーバ１０１上のディスクの空き容量に余裕がある場合は、コンテンツサーバ１０４上から、分割インデクス２０２へコンテンツデータを移動させるモジュールである。また、逆に、検索サーバ１０１上のディスク容量に空きが少なくなった場合、または、管理者により実行操作が行われた場合に、分割インデクス２０２からコンテンツデータをコンテンツサーバ１０４へ移動させる機能を持つモジュールである。

［テーブル等のデータ構造］
図６に、インデクスＩＤテーブル５０４の例を示す。インデクスＩＤテーブル５０４は、仮想インデクスＩＤ６０１とインデクスＩＤ６０２を格納するテーブルであり、ファイルパスからインデクスＩＤを取得するために用いられる。インデクスＩＤテーブル５０４は、コンシステントハッシュ法の実現手段として利用される。

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

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

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

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

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

図８に、ファイル管理テーブル５０６の例を示す。ファイル管理テーブル５０６は、ファイルサーバ１０２上に存在するファイルパス８０１の一覧と、それらの属性情報であるファイルメタ情報８０２、及び、その属性情報から生成したハッシュ値８０３を保存・管理するためのテーブルである。

スキャナモジュール３０４は、このテーブルに保存されているハッシュ値８０３と、スキャナモジュール３０４のスキャン実行時に取得したファイルメタ情報から生成されるハッシュ値を比較し、ファイルの更新状態をチェックして、処理ステータス８０４のカラムに格納する。また、インデクス生成時にコンテンツデータから生成されるコンテンツデータハッシュ値８０５も格納されている。

図９に、インデクスリスト３０６の例を示す。インデクスリスト３０６は、スキャナモジュール３０４によるファイルサーバのスキャンが終了し、かつ、処理ステータス８０４がファイル管理テーブル５０６に格納された後、インデクス処理対象のファイルパス８０１及び処理ステータス８０４をファイル管理テーブル５０６から抜き出すことにより生成される。インデクスリスト３０６は、ファイルパス９０１、処理ステータス９０２、ファイルメタ情報９０３により構成される。生成されたインデクスリスト３０６は、分散処理サーバ１０３のインデクス生成モジュール３０５に渡され、分割インデクス２０２の生成に利用される。

図１０に、分割インデクス２０２のインデクススキーマ１０００の例を示す。インデクススキーマ１０００には、ファイルパス１００１をユニークキーとして、ファイルメタ情報１００２、コンテンツデータハッシュ値１００３、コンテンツデータ１００４が定義されている。ファイルメタ情報１００２は、ファイルの構成情報に関するデータであり、ファイル固有のメタ情報、及び、ＯＳにより管理されるメタ情報の両方を含む複数の情報である。コンテンツデータハッシュ値１００３は、コンテンツデータ１００４からハッシュ関数により生成されたハッシュ値である。コンテンツデータ１００４はファイル内の本文にあたるデータである。

図１１に、コンテンツ管理テーブル４０３のコンテンツ管理スキーマの例を示す。コンテンツ管理スキーマは、コンテンツデータハッシュ値１１０１をユニークキーとして、コンテンツデータ１１０２及び参照カウント１１０３が定義されている。コンテンツデータ１１０２は、ファイルサーバ１０２上に保存されているドキュメントの本文にあたるデータである。参照カウント１１０３は、このエントリが参照されているカウントを示しており、２以上の値である場合、内容が重複したファイルがファイルサーバ１０２上にあり、それらのファイルが分割インデクス２０２に登録されたことを示す。

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

まず、管理者は、検索サーバ管理テーブル５０５の初期化を行うために、検索サーバ１０１の台数、及び、インデクスの分割数を設定する（Ｓ１２０１）。これらの情報の入力には、不図示の入力装置が用いられる。インデクスの分割数は、前述したように、各検索サーバ１０１に配置する分割インデクス２０２の数に応じて定まる。この説明では、１つの検索サーバ１０１に２つの分割インデクス２０２が配置されるので、システム全体におけるインデクスの分割数は４である。

管理者がこれらの情報をシステム管理モジュール５０３に入力すると、システム管理モジュール５０３は、各分割インデクス２０２に対して割り振るインデクスＩＤを決定する（Ｓ１２０２）。本明細書の場合、インデクスＩＤは０から始まる昇順の数字とする。すなわち、システム管理モジュール５０３は、「０」、「１」、「２」、「３」の順番にインデクスＩＤを割り振る。

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

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

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

まず、管理者が検索サーバ１０１の台数とインデクスの分割数を設定する（Ｓ１３０１）。ここでも、これらの情報の入力には不図示の入力装置が用いられる。インデクスの分割数は、各検索サーバ１０１に配置する分割インデクスの数に応じて定まる。

管理者がこれらの情報をシステム管理モジュール５０３に入力すると、システム管理モジュール５０３は、インデクスＩＤを決定する（Ｓ１３０２）。ここでも、インデクスＩＤは、「０」、「１」、「２」、「３」の４つであるものとする。

次に、システム管理モジュール５０３は、１つのインデクスＩＤに対して任意の仮想インデクスＩＤを生成する（Ｓ１３０３）。仮想インデクスＩＤの数は、一つのインデクスＩＤに対して２であるものとする。仮想インデクスＩＤの数は、最終的にインデクスＩＤに紐付けられるファイル数が平準化されるように定められる任意の固定値である。本実施例では、インデクスＩＤ「０」に紐付ける仮想インデクスＩＤを「０−０」、「０−１」、インデクスＩＤ「１」に紐付ける仮想インデクスＩＤを「１−０」、「１−１」、インデクスＩＤ「２」に紐付ける仮想インデクスＩＤを「２−０」、「２−１」、インデクスＩＤ「３」に紐付ける仮想インデクスＩＤを「３−０」、「３−１」とする。

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

図１４に、初期化が終了したインデクスＩＤテーブル５０４の例を示す。このテーブルを利用することにより、ファイルパスが与えられたとき、そのファイルパスがどのインデクスＩＤに紐付けるかを知ることが可能となる。例えばファイルパス「／ＦｉｌｅＳｅｒｖｅｒ１／ｔｅｓｔ．ｔｘｔ」のハッシュ値を求めたところ「２９９９９９９９９９９」であった場合、このハッシュ値は、項番３と項番４の点の間に配置され、項番３のエントリの点にヒットする（コンシステントハッシュの円周上で左に回る場合）。項番３のインデクスＩＤは「３」であるので、ファイルパス「／ＦｉｌｅＳｅｒｖｅｒ１／ｔｅｓｔ．ｔｘ」”のインデクスＩＤは「３」となることが分かる。

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

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

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

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

Ｆｉｎｄコマンドにより取得したファイルパスとそのメタ情報を取得すると、スキャナモジュール３０４は、それぞれのメタ情報に基づいてハッシュ値を取得する（Ｓ１５０４）。

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

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

具体的には、スキャナモジュール３０４は、ファイル管理テーブル５０６からファイルパス８０１が一致するエントリのファイルメタ情報ハッシュ８０３を取得し、Ｆｉｎｄコマンドにより取得したハッシュ値と比較する。

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

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

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

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

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

［分割インデクス生成のフロー］
図１６に、インデクス生成モジュール３０５による分割インデクス２０２の生成フローを示す。インデクス生成モジュール３０５は、スキャナモジュール３０４から転送されてくるインデクスリスト３０６に基づいて分割インデクス２０２を生成する。インデクス生成モジュール３０５の処理は、インデクスリスト３０６に対して、タスクと呼ばれる複数の処理単位に分割され、複数の分散処理サーバ１０３上で分散的に処理される。以下、タスク生成及び分散処理サーバ上での処理を示す。

インデクス生成モジュール３０５は、スキャナモジュール３０４からインデクスリスト３０６を取得する（Ｓ１６０１）。次に、インデクス生成モジュール３０５は、第一の分散処理として、以下に示すＳ１６０３とＳ１６０４の処理をインデクスリストのエントリ数分だけ行う。まず、インデクス生成モジュール３０５は、インデクスリスト３０６を任意の数に分割する（Ｓ１６０２）。ここでの数は、分散処理サーバ１０３の台数及び処理性能から決定される数である。インデクスリスト３０６は、インデクス処理対象のファイルパス９０１、処理ステータス９０２が記述されたテキストファイルであり、このファイルを分割する際には、分割数に応じて単純に任意の行で区切って複数のインデクスリストが生成されることとなる。

分割された各々のインデクスリスト３０６は、それぞれが、分散処理サーバ１０３上で複数のタスクとして処理される。第一の分散処理における各々のタスク処理は、分割されたインデクスリストに記述されているファイルパスを取得して、そのハッシュ値を計算する（Ｓ１６０３）。その後、コンシステントハッシュ法に従い、インデクスＩＤテーブルに問い合わせを行って、ファイルパスのハッシュ値に対応する仮想インデクスＩＤとインデクスＩＤの両方を取得する（Ｓ１６０４）。以上で第一のタスク処理が完了する。

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

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

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

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

次に、インデクス生成モジュール３０５は、処理ステータスをチェックする（Ｓ１６０７）。ここで、処理ステータスが、「０」（＝ファイル新規生成）又は「２」（＝ファイル更新）の場合、インデクス生成モジュール３０５は、各タスクについて、ファイルサーバ１０２からファイルをダウンロード（Ｓ１６０８）し、ファイルからコンテンツデータを抽出し（Ｓ１６０９）、コンテンツデータからハッシュ値を取得する(Ｓ１６１０)。インデクス生成モジュール３０５は、抽出したコンテンツデータを、コンテンツデータハッシュ値をキーとしてコンテンツサーバへ登録する（Ｓ１６１１）。

次に、インデクス生成モジュール３０５は、処理ステータスを再度チェックする（Ｓ１６１２）。ここで、「０」（＝ファイル新規生成）だった場合、インデクス生成モジュール３０５は、登録したコンテンツサーバのエントリの参照カウントをアップさせる(Ｓ１６１３)。この後、インデクス生成モジュール３０５は、分割インデクスに対し、ファイルパスをユニークキーとして各フィールドへデータを登録して分割インデクスを生成する（Ｓ１６１４）。なお、このとき生成される分割インデクスは、分散処理サーバ１０３のローカルストレージ３０１上に一時的に生成される。その後、Ｓ１６１０で取得したコンテンツデータハッシュ値８０５をファイル管理テーブル５０６上の、ファイルパスに対応するコンテンツデータハッシュ値フィールド８０５へ格納する(Ｓ１６１５)。

Ｓ１６１２で処理ステータスが「２」（＝ファイル更新）の場合、インデクス生成モジュール３０５は、ファイル管理テーブル５０６からコンテンツデータハッシュ値８０５を取得する（Ｓ１６１６）。なお、ここで取得したコンテンツデータハッシュ８０５は、古いファイルデータのハッシュ値である。

次に、インデクス生成モジュール３０５は、Ｓ１６１１で登録されたコンテンツデータのエントリの参照カウントをアップし(Ｓ１６１７)、Ｓ１６１６で取得したコンテンツデータハッシュ値８０５に対応するコンテンツサーバ上のエントリ(このエントリは、古いコンテンツデータが格納されたエントリである)の参照カウントをダウンする(Ｓ１６１８)。ここで、参照カウントが０となった場合(Ｓ１６１９が肯定)、そのエントリへの参照が無くなったため、インデクス生成モジュール３０５は、コンテンツサーバからエントリを削除する(Ｓ１６２０)。その後、インデクス生成モジュール３０５は、ファイルパス、ファイルメタ情報、コンテンツデータハッシュ値、コンテンツデータを分割インデクスに登録する（Ｓ１６１４）。Ｓ１６１９が否定の場合、これは、コンテンツサーバ上に格納されているコンテンツのエントリが他から参照されていることを意味する。従って、インデクス生成モジュール３０５は、エントリを削除せずに分割インデクスを生成し(Ｓ１６１４)、コンテンツデータハッシュ値をファイル管理テーブル５０６に登録する(Ｓ１６１５)。

Ｓ１６０７で処理ステータスが「１」の場合、既にコンテンツサーバ上にファイルコンテンツが格納されていることを意味する。このため、インデクス生成モジュール３０５は、取得したコンテンツデータハッシュ値のエントリの参照カウントをアップさせて（Ｓ１６１３）、ファイルパス、ファイルメタ情報、メタ情報ハッシュ値を分割インデクスに登録し（Ｓ１６１４）、コンテンツデータハッシュ値をファイル管理テーブル５０６に格納する(Ｓ１６１５)。

Ｓ１６０７で処理ステータスが「−１」の場合、ファイルが削除されたことを意味する。このため、インデクス生成モジュール３０５は、取得したコンテンツデータハッシュ値をキーとして、コンテンツサーバ上のコンテンツ管理テーブル４０３に問い合わせを行い、対象となるエントリの参照カウントをダウンさせる（Ｓ１６２１）。

参照カウントが０になった場合（Ｓ１６２２）、インデクス生成モジュール３０５は、分散データベース上で当該コンテンツデータハッシュ値のエントリを削除する（Ｓ１６２３）。その後、インデクス生成モジュール３０５は、第三のタスク処理により生成された分割インデクスと、インデクスＩＤをキーとするインデクスリストをセット（一組）として、検索サーバ１０１上のインデクス管理モジュール２０３に対して転送し(Ｓ１６２４)、インデクス生成管理モジュール５０２に分割インデクス生成完了通知を出して処理を終了する（Ｓ１６２５）。

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

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

インデクス管理モジュール２０３は、既に分割インデクスが存在するか否かをチェックする（Ｓ１７０２）。既に分割インデクス２０２が同じ検索サーバ１０１上に存在する場合（Ｓ１７０２で肯定結果）、インデクス管理モジュール２０３は、インデクスリストからレコードを取得して処理ステータスをチェックする。

処理ステータスが、更新、または、削除の場合、インデクス管理モジュール２０３は、既存の分割インデクスに対して削除処理を行う（Ｓ１７０３）。処理ステータスが更新になっている場合に、既存の分割インデクスに対して削除処理を行う理由は、重複したレコードが存在しないようにするためである。

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

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

[検索フロー]
図１８に、検索時に各検索サーバ内で実行される処理フローを示す。図１８に示すフローは、利用者が検索クライアント１００から検索サーバ１０１へ検索クエリが送信されることにより開始される(Ｓ１８０１)。

検索サーバ１０１は、検索クエリを受信すると(Ｓ１８０２)、そのクエリに基づいて、検索モジュール２０４が分割インデクス２０２を使って検索を行い(Ｓ１８０３)、検索ワード・検索条件にヒットする分割インデクス２０２内のユニークキー(図１０のファイルパスがユニークキーに相当する)とそのエントリの情報を取得する(Ｓ１８０４)。この時、検索サーバ１０１は、検索条件でコンテンツデータが必要な場合(Ｓ１８０５)、当該エントリのコンテンツデータハッシュ値を取得して(Ｓ１８０６)、コンテンツサーバ１０４へ問い合わせを行う(Ｓ１８０７)。

コンテンツサーバ１０４は、問い合わせ対象とするコンテンツデータハッシュ値１１０１でコンテンツ管理テーブル４０３のエントリを検索し、問い合わせに一致するエントリに対応付けられたコンテンツデータ１１０２を検索モジュール２０４に送信する(Ｓ１８０８)。検索モジュール２０４は、取得した情報を検索クライアント１００に送信して処理を完了する(Ｓ１８０９)。なお、コンテンツの取得が不要な場合（Ｓ１８０５で否定結果の場合）、検索サーバ１０１は、検索結果のみを検索クライアント１００に送信して処理を終了する（Ｓ１８０９）。

[コンテンツ配置変更フロー]
図１９に、コンテンツ配置の変更フローを示す。図１９に示すフローは、主に検索サーバ１０１にディスクを追加した後に自動で行われる。ただし、当該変更フローは、システム管理者が任意のタイミングで実行しても良く、スケジューリングにより定期的に実行しても良い。

まず、コンテンツ管理モジュール５０７は、各検索サーバ１０１上のコンテンツ監視モジュール２０５にコンテンツ配置変更クエリを送信する（Ｓ１９０１）。

次に、コンテンツ監視モジュール２０５は、ローカルストレージ２０１の空き容量をチェックする(Ｓ１９０２)。コンテンツ監視モジュール２０５は、分割インデクス２０２の各エントリのファイルメタ情報のうち、ファイルサイズ(コンテンツサイズ)を取得し、その合計を求める(Ｓ１９０３)。

合計サイズがローカルストレージ２０１の空き容量より小さい場合(Ｓ１９０４)、コンテンツ監視モジュール２０５は、各エントリのコンテンツデータハッシュ１００３を取得した後(Ｓ１９０５)、コンテンツサーバ１０４へ問い合わせて、コンテンツ管理テーブル４０３に格納されている対応するコンテンツデータ１１０２を取得し(Ｓ１９０６)、分割インデクス２０２内の対応するコンテンツデータフィールド１００４を追加しなおす(Ｓ１９０７)。全エントリに対してコンテンツ取得と追加が完了したら、コンテンツ管理モジュール５０７に、全コンテンツの配置変更が完了したことを通知する(Ｓ１９０８)。合計サイズがローカルストレージ２０１の空き容量より大きい場合(Ｓ１９０４)、コンテンツ監視モジュール２０５は、コンテンツ管理モジュール５０７にコンテンツデータの配置変更が不能なことを通知して処理を終了する(Ｓ１９０８)。

［実施例の効果］
本実施例に係る検索システムの場合、基本的に、分割インデクスはファイルのメタ情報のみを含む。この場合、ファイルパスのハッシュ値をコンシステントハッシュ法に基づいて各インデクスＩＤに割り当てた分割インデクスのサイズは、ファイルの実サイズによらず、分割インデクスで管理するドキュメント数に応じて一定となる。このため、全ての分割インデクスは、概ね同じサイズとなる。よって、本実施例に係る検索システムでは、検索サーバにおけるディスク容量の見積もりが容易になり、かつ、ディスク容量に無駄が生じる可能性を低減することができる。

なお、コンテンツデータは、検索サーバ１０１上の分割インデクス内に存在する場合に検索性能が最も良い。このため、検索サーバのディスク容量に余裕がある場合には、コンテンツサーバ１０４から検索サーバ１０１上にコンテンツデータを再配置して検索性能を向上させることもできる。

また、本実施例においては、コンテンツデータをコンテンツサーバ１０４に分散して格納する際に、コンテンツデータからハッシュ値を求め、そのハッシュ値をキーに使用してデータベースに登録する。このため、同じコンテンツの検出と重複データの複数登録を効果的に回避することができる。また、前述の通り、ハッシュ値を使用して重複したコンテンツデータを排除することにより、コンテンツサーバ１０４のディスク容量を削減することができる。

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

Claims (2)

1. 大規模ファイルシステムを検索対象とする分散検索システムにおけるストレージ容量平準化方法において、
   検索用のインデクスの生成に際し、
   ファイルデータからメタ情報とコンテンツを分離する処理と、
   分離された前記コンテンツを１つ又は複数のコンテンツサーバに格納する処理と、
   前記メタ情報を検索サーバに対応付けられた分割インデクスに割り当てる処理であって、前記メタ情報の割り当て先をコンシステントハッシュ法に基づいて決定する処理と
   を有し、
   前記メタ情報を分割インデクスに割り当てる前記処理は、
   前記コンテンツの格納先を示すファイルパスから一意に算出されるハッシュ値をマッピングするコンシステントハッシュ空間上に設定された仮想インデクスＩＤのハッシュ値とインデクスＩＤとの対応関係を定めたテーブルとに基づいてメタ情報に対応付けるインデクスＩＤを決定するサブ処理と、当該インデクスＩＤに対応付けられた分割インデクスを前記メタ情報の割り当て先に決定するサブ処理とを有する
   ことを特徴とするストレージ容量標準化方法。
2. 大規模ファイルシステムを検索対象とする分散検索システムにおけるストレージ容量平準化方法において、
   検索用のインデクスの生成に際し、
   ファイルデータからメタ情報とコンテンツを分離する処理と、
   分離された前記コンテンツを１つ又は複数のコンテンツサーバに格納する処理と、
   前記メタ情報を検索サーバに対応付けられた分割インデクスに割り当てる処理であって、前記メタ情報の割り当て先をコンシステントハッシュ法に基づいて決定する処理と
   を有し、
   前記分割インデクスが格納される前記検索サーバにおけるストレージ容量の空きサイズに応じ、コンテンツデータを前記コンテンツサーバから前記検索サーバにアップロード又は前記検索サーバから前記コンテンツサーバにダウンロードする
   ことを特徴とするストレージ容量標準化方法。

Images