JP5485997B2 - 重複排除機能付きデータ格納装置及び当該データ格納装置の検索インデックスを作成する制御装置 - Google Patents

Description

本発明は、多量のデータを格納するデータ格納装置（例えばファイルサーバ）と当該データ格納装置に格納するデータに対する検索サービスを提供する制御装置（例えば検索サーバ）とで構成されるシステムの制御技術に関する。より具体的には、データ格納装置の重複排除機能によって重複排除したファイル群を、検索インデックスの作成対象ファイルとして制御装置に提供することにより、検索インデックスを作成する際の処理負荷の削減と検索インデックスの格納に要する容量の削減とを可能とする仕組みを提供する。

近年、コンピュータシステムの高性能化ならびに低価格化により、様々な業種や用途においてコンピュータシステムの利用が広がっている。これに伴い、従来は紙媒体などで扱っていたデータだけでなく、音楽や動画に至るまでマルチメディア形式のデータに電子化され、データファイルとしてコンピュータシステムに保存されている。さらに、コンピュータシステムは、複数のコンピュータシステムをネットワーク経由で接続した形態での利用も急速に進んでいる。これにより、データの分散管理や分散処理が実現できるようになり、一つのコンピュータシステムだけでは実現することが難しかった大容量保管、ならびに高可用性、高信頼性および高性能を実現することが可能になっている。

また、近年では、コンピュータシステムに保管されるデータファイルの数が膨大になっており、利用者の必要とするファイルがどこに格納されているか分からないという問題も生じている。この問題に対処するため、昨今、全文検索サービスが利用されるようになっている。全文検索サービスは、コンピュータシステムに格納されているファイルのデータを解析し、各データに対応する検索インデックスを検索サーバ内に予め格納しておくことで提供される。検索サービスの提供は、おおよそ以下に示す手順によって進行する。まず、利用者が、検索サーバに対して検索クエリを送信する。検索クエリは、取得したいファイルを検索するための文字列である。検索サーバは、受信した検索クエリに基づいて検索インデックスを検索し、検索結果を利用者に送信する。利用者は、その検索結果に基づいて、対象ファイルにアクセスする。ところで、コンピュータシステムに格納するデータファイルの数は今後ますます増加すると考えられる。これに伴い、利用者自身がどこにどのようなデータファイルを格納しているのかを全て把握することが一層困難になると予想される。従って、検索サービスの重要性は今後ますます増加し、検索サービスの利用が一層広がると予想される。

従来の検索サーバでは、検索インデックスを作成する場合、検索対象とするファイルが格納されているコンピュータシステムにアクセスし、対象ファイルを取得した上で検索インデックスを作成する。ところが、検索対象のファイルが格納されたコンピュータシステムには、同じ内容のデータファイルが重複して格納されているケースが多数認められる。例えばコンピュータシステムが複数のユーザに対してファイル格納サービスを提供している場合、各ユーザは、同じ内容のファイルのコピーをそれぞれ作成し、それらを個別に格納することが起こり得る。このような場合、従来の検索サーバでは、データが重複しているファイル（いわゆる重複ファイル）であったとしても、対象ファイルの一つとして画一的にコンピュータシステムから取得し、検索インデックスを作成している。しかし、この手法は、検索インデックスの処理負荷を増加させると共に、検索インデックスの格納に要する容量を増加させる原因となっている。

このような重複ファイルを対象とした検索インデックスの作成による無駄を無くすための手法として、重複排除技術を利用する技術が開示されている。具体的には、検索サーバの側において、コンピュータシステムから取得したファイルから重複データを削除し、残りのデータファイルに対して検索インデックスを作成する技術が開示されている（特許文献１）。この方式を採用する検索サーバでは、重複データの排除によって、検索インデックスを作成する対象ファイル数を減らすことができ、結果的に、検索インデックスの作成に要する処理負荷の削減と検索インデックスの格納に要する容量の削減とを実現することができる。

また、コンピュータシステムと連携動作する検索サーバが、検索対象とするファイルに関する重複状況をコンピュータシステムから事前に取得しておくことにより、検索サーバによる重複ファイルの重複取得を回避し、重複ファイルを含まない対象ファイルのみについて検索インデックスを作成する技術が開示されている（特許文献２）。この方式を採用する検索サーバでは、重複ファイルをコンピュータシステムから取得せずに済み、コンピュータシステムと検索サーバとの間を流れるファイル数を削減することができる。結果的に、この仕組みを採用する場合には、前述した特許文献１で得られる効果に加え、ネットワーク負荷の軽減をも実現することができる。

米国特許出願公開第2006/0020607号明細書 米国特許出願公開第2008/0155192号明細書

しかしながら、特許文献１に記載の技術では、検索サーバ自身が検索対象ファイルの重複状況を検出し、重複ファイルを削除した上で、検索インデックスを作成することになる。このため、重複状況を検出するための処理負荷が、検索サーバ側で別途発生する問題がある。しかも、検索サーバにおける重複検出のための処理負荷は、コンピュータシステムに格納されているファイル数に比例して大きくなる。従って、検索対象ファイル数が多い環境では、重複排除による検索インデックスの作成処理負荷の低減や検索インデックスのデータ量削減といったメリット以上に、重複検出に要する処理負荷が大きくなるというデメリットを無視できなくなる。

また、特許文献２に記載の技術では、検索対象ファイルの重複状況を検出する処理をコンピュータシステムの側で行う。このため、検索サーバ側の処理負荷を特許文献１に記載の技術と比べて軽減することができる。しかし、検索サーバは、コンピュータシステムからファイルの重複状況に関する情報を取得した上で、当該情報に基づいて検索対象ファイルを選択するという処理が別途必要になる。すなわち、特許文献２に記載の検索サーバの場合には、各コンピュータシステムの重複排除機能と連携するための機能が別途必要になる。ところが、連携のための機能は、連携するコンピュータシステムに特有の機能仕様に従う必要がある。従って、同様の重複排除機能を有する他のコンピュータシステムと連携するためには、別途新たな連携機能を検索サーバに実装する必要がある。このことは、検索サーバの移植性を損なう原因になる。

前述した課題は、取得したファイルから重複ファイルを検出するための処理又はコンピュータシステムで実行される重複排除機能と連携するための特別な処理機能を、検索サーバ上に実装する必要があることに起因する。従って、前述した課題の解決には、検索サーバに特別な連携機能を追加すること無しに、検索サーバにおける検索インデックス作成のための処理負荷を削減できる仕組みが必要になると考えられる。

そこで、本発明においては、以下に示す処理様態や処理機能を採用する仕組みを提供する。本発明は、格納データの重複検出と重複データの削除に関する重複排除機能を具備するデータ格納装置に、以下に示す処理機能を採用することを要旨とする。すなわち、本発明は、検索サービスを提供する制御装置（検索サーバ）が検索インデックスを作成するためのファイル取得に先立って、格納データの重複排除を実行する機能と、検索インデックス作成のためのファイルシステムを自装置上に作成する機能とを、データ格納装置に採用することを要旨とする。

ここでのファイルシステムは、データ格納装置が具備する格納データの重複排除機能を用いて重複データを含まないファイルシステムイメージを提供するファイルシステム管理機能により作成される。このファイルシステム管理機能をデータ格納装置に採用することにより、検索サービスを提供する制御装置（検索サーバ）は、特別な連携機能を搭載しなくても、格納データの重複が排除されたファイルだけを検索対象ファイルとして取得することができ、検索インデックス作成時の対象ファイル数を削減することができる。このように、本発明は、検索インデックスの作成処理を高速化するファイルシステム管理機能をデータ格納装置に具備することを要旨とする。

なお、本発明は、以下に示す処理様態や処理機能を追加的に採用することも可能である。例えばデータ格納装置において、重複ファイルのないファイルシステムイメージの作成後に、検索インデックスを作成する制御装置（検索サーバ）に対して、検索インデックスの作成開始の契機を通知するトリガを送信する機能をデータ格納装置に具備することも可能である。この場合、データ格納装置のトリガ送信機能によってトリガが制御装置（検索サーバ）に通知され、制御装置（検索サーバ）は、かかるトリガ通知の受信を契機として、検索インデックス作成に必要な処理、すなわち、検索対象データをデータ格納装置から取得する処理と取得されたデータから検索インデックスを作成するための処理とを実施する。この際、制御装置（検索サーバ）は、データ格納装置が提供するファイルシステムイメージから検索対象データを取得する。

本発明により、検索サーバ側に特別な連携機能を実装しなくても、制御装置（検索サーバ）における検索インデックスの作成対象ファイル数を削減することができる。これにより、制御装置（検索サーバ）における検索インデックス作成処理を高速化することができる。また、制御装置（検索サーバ）における検索インデックスのデータ量を削減することができる。以上により、多量のデータを扱うデータ格納装置と当該データ格納装置に格納されているファイルの検索サービスを提供する制御装置（検索サーバ）とで構成されるシステムにおいて、制御装置（検索サーバ）における検索インデックスの作成処理コストと制御装置（検索サーバ）における検索インデックスデータの保管コストとを共に削減することができる。

本発明は、前述した制御装置の他に、制御システム又は制御方法として構成することもできる。また、前述した制御装置を実現するコンピュータプログラム、当該プログラムを記録した記録媒体、当該プログラムを含み搬送波内に具現化されたデータ信号など種々の態様で実現することが可能である。

本発明をコンピュータプログラム又はそのプログラムを記録した記録媒体等として構成する場合には、制御装置を制御するプログラムの全体として構成しても良いし、本発明の機能を果たす部分のみを構成するプログラムとして構成しても良い。また、記録媒体としては、フレキシブルディスクやCD-ROM、DVD-ROM、パンチカード、バーコードなどの符号が印刷された印刷物、コンピュータの内部記憶装置及び外部記憶装置等のコンピュータが読み取り可能な種々の揮発性記憶媒体や不揮発性記憶媒体を利用できる。

システム構成例を示す図。 ファイルサーバのハードウェア構成例を示す図。 検索サーバのハードウェア構成例を示す図。 クライアントマシンのハードウェア構成例を示す図。 ファイルの格納、検索インデックスの作成、ファイル検索及びファイルアクセスに関する一連の処理イメージを例示する説明図。 登録ファイル管理表を例示する説明図。 格納ファイル管理表を例示する説明図。 仮想ファイルシステム管理表を例示する説明図。 クローリングファイル管理表を例示する説明図。 検索インデックス管理表を例示する説明図。 ファイル登録処理の一例を説明するフローチャート。 重複排除処理付きファイル格納処理の一例を説明するフローチャート。 ファイル登録時の仮想ファイルシステム更新処理の一例を説明するフローチャート。 クローリングとインデクシング処理の一例を説明するフローチャート。 ファイル検索処理の一例を説明するフローチャート。 ファイル取得処理の一例を説明するフローチャート。 ファイル更新処理の一例を説明するフローチャート。 重複排除処理付き格納ファイル更新処理の一例を説明するフローチャート。 ファイル更新時の仮想ファイルシステム更新処理の一例を説明するフローチャート。 ファイル削除処理の一例を説明するフローチャート。 重複排除処理付き格納ファイル削除処理の一例を説明するフローチャート。 ファイル削除時の仮想ファイルシステム更新処理の一例を説明するフローチャート。 実施例２におけるファイル登録処理の一例を説明するフローチャート。 実施例３におけるファイル登録処理の一例を説明するフローチャート。 実施例４における重複排除ファイルのメタデータ取得処理の一例を説明するフローチャート。 実施例４におけるクローリングとインデクシング処理の一例を説明するフローチャート。 実施例４におけるファイル検索処理の一例を説明するフローチャート。 実施例５におけるファイル登録処理の一例を説明するフローチャート。 実施例５におけるファイル取得処理の一例を説明するフローチャート。 実施例５における重複排除ファイルのメタデータ取得処理の一例を説明するフローチャート。

以下、図面に基づいて、本発明の実施例を説明する。なお、後述する実施例は一例であって、公知又は周知の技術との組み合わせや置換によって他の実施例を実現することもできる。

本実施例では、重複排除された後の重複なきファイル群からなる仮想ファイルシステムをファイルサーバ上に作成し、検索サーバが当該仮想ファイルシステムをクローリングして検索インデックスを作成する処理方式について説明する。

図１は、本発明の実施例におけるシステム構成を例示する説明図である。ネットワーク10を介して、複数のファイルサーバ1100、1200、1300と、複数の検索サーバ2100、2200と、複数のクライアントマシン3100、3200、3300とが接続されている。本システムでは、ファイルサーバに格納されているデータの検索インデックスを検索サーバが作成し、当該検索インデックスを利用して、検索サーバがクライアントマシンに対してファイルサーバ上のファイルに対する検索サービスを提供する。

具体的なサービスの内容は次の通りである。まず、クライアントマシンは、ファイルサーバにデータファイルを登録することができる。ファイルサーバは、登録されたデータファイルの重複排除処理を行った上で自身の外部記憶装置に格納し保管する。検索サーバは、ファイルサーバに登録されたデータファイルをクローリングによって取得し、検索インデックスを作成し、自身の外部記憶装置に格納し保管する。他方で、クライアントマシンは、検索サーバに対して検索クエリを指定の上、検索要求を送信することができる。検索サーバは、かかる検索クエリの条件に合致するデータファイルを、自身が保管する検索インデックスを利用して抽出し、検索結果をクライアントマシンに提供する。クライアントマシンは、かかる検索結果より、アクセス対象ファイルを選定すると共に、かかる検索結果に格納されているファイルアクセス用のファイルパス名を利用してファイルサーバに対して当該ファイルへのアクセスを行う。

各ファイルサーバでは、検索サーバによる検索対象となるファイル1101、1102、1201、1202、1301、1302を格納する。また、各検索サーバでは、検索サービスで利用するための検索インデックス2101、2201を格納する。各クライアントマシンは、ネットワーク10を介し、適切なアクセスプロトコルに基づいて、かかるファイルサーバならびに検索サーバにアクセスする。

なお、図１では、ファイルサーバ、検索サーバおよびクライアントマシンの三種類の構成要素を別装置として記載しているが、この限りではない。可能であれば、三種類のうち二つ、あるいは三つ全てを一つの装置として実現する構成でも良い。また、ネットワーク10による接続形態については、どのようなネットワーク形態でもよく、例えば、インターネット接続でも良いし、ローカルエリアネットワークによるイントラネット接続などでも良い。

図２は、ファイルサーバ1100のハードウェア構成を例示する説明図である。ファイルサーバ1100は、プログラムを実行するプロセッサ1110と、プログラムならびにデータを一時的に格納するメモリ1120と、外部記憶装置1160にアクセスするための外部記憶装置I/F1130と、ネットワークで接続された他装置にアクセスするためのネットワークI/F1140と、それらを接続するバス1150から構成されている。メモリ1120には、外部記憶装置I/F1130を制御するプログラムである外部記憶装置I/F制御プログラム1121と、ネットワークI/F1140を制御するプログラムであるネットワークI/F制御プログラム1122と、当該ファイルサーバ1100において提供するファイルサービスを管理するためのファイルサービス制御プログラム1123と、当該ファイルサーバ1100において、登録されたファイルを管理する機能を提供するためのプログラムであるファイル管理制御プログラム1124と、ファイル管理制御プログラム1124が利用する登録ファイル管理表4100と、格納ファイル管理表4200と、仮想ファイルシステム管理表4300とが格納される。

ファイル管理制御プログラム1124は、その内部に、重複排除制御サブプログラム1125と、仮想ファイルシステム管理制御サブプログラム1126と、トリガ通信制御サブプログラム1127と、仮想パス名変換制御サブプログラム1128と、重複ファイルメタデータ制御サブプログラム1129を持つ。重複排除制御サブプログラム1125は、ファイルサーバ1100に登録されたファイルを、外部記憶装置1160に格納する際に、重複データを削除して格納する処理を行う。重複データの検出には、例えばファイルレベルで照合する処理、ファイルを構成する固定長のブロックレベルで照合する処理等が用いられる。仮想ファイルシステム管理制御サブプログラム1126は、検索サーバ2100に対してファイルサーバ1100に登録されているファイル群の検索インデックス2101を作成してもらうために、ファイルサーバ1100が検索サーバ2100に見せるファイルシステムイメージを作成する処理を行う。トリガ通信制御サブプログラム1127は、ファイルサーバ1100が検索サーバ2100に対して、検索インデックス作成ならびに更新処理を行う契機を明示的に通知するための処理を行う。仮想パス名変換制御サブプログラム1128は、検索サーバ2100における検索インデックス2101の作成用に、仮想ファイルシステム管理制御サブプログラム1126が提供する仮想ファイルシステムでのファイルパス名を、ファイルサーバ1100に実際に格納されているファイルパス名に変換する処理を行う。これにより、クライアントマシン3100から仮想パス名でファイルアクセス要求がファイルサーバ1100に来た場合でも、ファイルサーバ1100内でパス名変換を行うことにより、クライアントマシン3100は所望のファイルにアクセスすることができる。最後に、重複ファイルメタデータ制御サブプログラム1129は、仮想ファイルシステム管理制御サブプログラム1126が提供する仮想ファイルシステムのファイルに対して、当該ファイルとデータが重複している他ファイルがかかるファイルサーバ1100に登録されている場合、ファイルサーバ1100に登録されている当該ファイルとデータが重複する全ての登録ファイルのメタデータ(ファイル所有者、作成日時、アクセス権情報など)の情報を提供する処理を行う。これにより、ファイルサーバ1100外からも、ファイルサーバ1100において重複排除されたファイルに関して、当該ファイルサーバ1100に登録されている他の重複ファイルのメタデータを取得することができるようになる。

なお、登録ファイル管理表4100、格納ファイル管理表4200および仮想ファイルシステム管理表4300については後述する。また、他のファイルサーバ1200、1300の構成は、ファイルサーバ1100の構成と同じであるため説明を割愛する。

図３は、検索サーバ2100のハードウェア構成を例示する説明図である。検索サーバ2100は、プログラムを実行するプロセッサ2110と、プログラムならびにデータを一時的に格納するメモリ2120と、外部記憶装置2160にアクセスするための外部記憶装置I/F2130と、ネットワークで接続された他装置にアクセスするためのネットワークI/F2140と、それらを接続するバス2150とから構成されている。メモリ2120には、外部記憶装置I/F2130を制御するプログラムである外部記憶装置I/F制御プログラム2121と、ネットワークI/F2140を制御するプログラムであるネットワークI/F制御プログラム2122と、当該検索サーバ2100において保管データを管理するために利用するファイルシステム又はデータベースを提供するデータ管理制御プログラム2123と、当該検索サーバ2100において検索サービスを提供するための検索サービス制御プログラム2124と、検索サービス制御プログラム2124が利用するクローリングファイル管理表4400と、検索インデックス管理表4500とが格納される。

検索サービス制御プログラム2124は、その内部に、トリガ通信制御サブプログラム2125と、クローリング制御サブプログラム2126と、インデクシング制御サブプログラム2127と、検索クエリ受付制御サブプログラム2128と、検索制御サブプログラム2129を持つ。トリガ通信制御サブプログラム2125は、ファイルサーバ1100が、検索サーバ2100に対して、検索インデックス作成ならびに更新処理を行う契機を明示的に通知してきたメッセージを受信し、受信を契機に検索インデックスの作成を開始するために必要な処理を行う。クローリング制御サブプログラム2126は、検索インデックスの作成開始要求を受けて、検索インデックスを作成するファイル群が格納されているファイルサーバ1100に対して、検索インデックスを作成するために対象ファイルを取得するための処理を行う。インデクシング制御サブプログラム2127は、クローリング制御サブプログラム2126が取得したファイルをもとに、対象ファイルの内容を解析し、検索インデックス2101を作成する処理を行う。検索クエリ受付制御サブプログラム2128は、クライアントマシン3100から検索クエリを指定した検索要求を受け付け、後述する検索制御サブプログラム2129で必要な処理を行った上で、検索結果を応答する処理を行う。最後に、検索制御サブプログラム2129は、クライアントマシン3100からの検索要求を受けて、当該検索条件に合致するファイルを検索する処理を行う。この検索では、前記のインデクシング制御サブプログラム2127が別途作成した検索インデックス2101を利用する。

なお、クローリングファイル管理表4400ならびに検索インデックス管理表4500については後述する。また、他の検索サーバ2200の構成は、検索サーバ2100の構成と同じであるため説明を割愛する。

図４は、クライアントマシン3100のハードウェア構成を例示する説明図である。クライアントマシン3100は、プログラムを実行するプロセッサ3110と、プログラムならびにデータを一時的に格納するメモリ3120と、外部記憶装置3160にアクセスするための外部記憶装置I/F3130と、ネットワークで接続された他装置にアクセスするためのネットワークI/F3140と、それらを接続するバス3150とから構成されている。メモリ3120には、外部記憶装置I/F3130を制御するプログラムである外部記憶装置I/F制御プログラム3121と、ネットワークI/F3140を制御するプログラムであるネットワークI/F制御プログラム3122と、当該クライアントマシン3100において保管ファイルを管理するために利用するファイルシステムを提供するファイル管理制御プログラム3123と、ファイルサーバ1100が提供するファイルサービスを利用するためのファイルサーバアクセスクライアント制御プログラム3124と、検索サーバ2100が提供する検索サービスを利用するための検索サーバアクセスクライアント制御プログラム3125とが格納される。ここで、ファイルサーバアクセスクライアント制御プログラム3124は、かかるファイルサービスがNFSプロトコルを利用する場合はNFSクライアントプログラム、CIFSプロトコルを利用する場合はCIFSクライアントプログラム、あるいは、HTTPプロトコルを利用する場合はHTTPクライアントプログラム(Webブラウザなど)を利用する。また、検索サーバアクセスクライアント制御プログラム3125は、かかる検索サービスがHTTPプロトコルを利用する場合はHTTPクライアントプログラム(Webブラウザなど)を利用する。

なお、他のクライアントマシン3200、3300の構成も、クライアントマシン3100の構成と同じであるため説明を割愛する。

図５は、ファイル格納、検索インデックス作成、ファイル検索およびファイルアクセスに関する一連の処理イメージを例示する説明図である。具体的には、次に説明する７つの処理ステップからなる。

はじめに、処理ステップ(1)として、クライアントマシン3100は、データファイルをファイルサーバ1100に登録する。ファイルサーバ1100に登録されたファイルは、ファイルサーバ1100上の登録ファイルシステム1170にて管理される。登録ファイルシステム1170は、クライアントマシン3100から見えるファイルシステムイメージである。クライアントマシン3100は、かかる登録ファイルシステム1170のファイルパス名("a”、”b”、”c”など)を利用して、登録ファイルにアクセスすることができる。

次に、処理ステップ(2)として、ファイルサーバ1100は、登録ファイルシステム1170のデータファイル群を重複排除した上で、ファイルサーバ1100上の格納ファイルシステム1171に重複排除後のファイル群を格納する。格納ファイルシステム1171は、かかるファイルサーバ1100において実際にデータファイルの実態が格納されるファイルシステムイメージである。登録ファイルシステム1170は、データファイルの実体そのものを管理せず、登録ファイルのメタデータと格納ファイルシステム1171における格納ファイルパス名の情報を管理する。データファイルの実体は、この格納ファイルシステム1171を利用して管理される。図の例では、登録ファイルシステム1170にて、登録ファイルパス名”a”と”b”のファイルの内容が重複していることを示している。これらのデータファイルの実体は、格納ファイルシステム1171において、格納ファイルパス名”P”という一つのファイルとして管理される。他方、登録ファイルパス名”c”のファイルは、他ファイルと重複していないことを示している。このデータファイルの実体は、格納ファイルパス名”Q”として管理される。

次に、処理ステップ(3)として、ファイルサーバ1100は、検索サーバ2100に提供するファイルシステムイメージとして、仮想ファイルシステム1172を作成する。仮想ファイルシステム1172は、かかるファイルサーバ1100に登録されているファイル群の中から、重複ファイルを削除したファイルシステムイメージのスナップショットに相当する。図の例では、格納ファイルシステム1171にて格納ファイルパス名が”P”と”Q”であるファイルを、仮想ファイルシステム1172にて仮想ファイルパス名”A”と”B”でそれぞれ関連付けていることを示している。この仮想ファイルシステム1172は、データファイルの実体そのものを管理せず、仮想ファイルのメタデータと格納ファイルシステム1171における格納ファイルパス名の情報を管理する。

次に、処理ステップ(4)として、ファイルサーバ1100は、仮想ファイルシステム1172を作成した後で、検索サーバ2100に対して、検索インデックスを作成するための契機であるトリガを通知する。このトリガ通知を契機として検索サーバ2100が検索インデックス作成を行うようにすることで、ファイルサーバ1100側でファイルの更新がない場合に、無駄な検索インデックス作成処理を抑止することが可能になる。

次に、処理ステップ(5)として、検索サーバ2100は、トリガ通信を受信することを契機として、ファイルサーバ1100上の仮想ファイルシステム1172から対象ファイルを取得する処理（クローリング処理）、ならびに取得ファイルから検索インデックス2101を作成する処理（インデクシング処理）を行う。ここで、重複データが含まれない仮想ファイルシステム1172を対象にクローリング処理を行うことで、ファイルサーバ1100から無駄なファイル取得を行う必要がなくなる上に、検索サーバ2100が作成する検索インデックス2101の量も削減することが可能になる。検索インデックス2101は、任意のキーワード文字列と、当該文字列が存在するファイル識別情報との対応を管理することになる。具体的には、ファイル識別情報として、仮想ファイルシステム1172における仮想ファイルパス名("A”、”B”など)を管理する。

次に、処理ステップ(6)として、クライアントマシン3100は、ファイルサーバ1100に登録したファイルを検索するために、検索サーバ2100に対して、検索クエリを指定した上で検索要求を出す。検索要求を受けた検索サーバ2100は、指定された検索クエリをもとに、検索インデックス2101を利用して、条件に該当するファイル群を検索する。検索サーバ2100は、条件に合致するファイル群を抽出できたら、それらを検索結果としてまとめ、要求元であるクライアントマシン3100に提供する。ここで、検索結果には、条件に該当するファイルの一覧表と、当該ファイルにアクセスするために必要なファイル識別情報（ここでは、仮想ファイルパス名）とが含まれる。

最後に、処理ステップ(7)として、クライアントマシン3100は、前記の処理ステップ(6)で取得した検索結果をもとに、実際にアクセスする対象ファイルを決定の上、かかる検索結果に含まれている仮想ファイルパス名を指定して、ファイルサーバ1100に対してファイルアクセス要求を出す。ファイルアクセス要求を受けたファイルサーバ1100は、指定されたファイルパス名が仮想ファイルパス名であれば、当該仮想ファイルパス名を登録ファイルシステム1170の登録ファイルパス名に変換する。この変換を実現するためには、ファイルサーバ1100における管理情報、具体的には、仮想ファイルパス名と格納ファイルパス名の対応関係、ならびに格納ファイルパス名と登録ファイルパス名の対応関係を利用する。仮想ファイルパス名を登録ファイルパス名に変換した後、ファイルサーバ1100は、対象登録ファイルを取得し、要求元であるクライアントマシン3100に当該ファイルを提供する。

図６は、ファイルサーバ1100上で管理する登録ファイル管理表4100の構成を例示する図である。登録ファイル管理表4100では、当該ファイルサーバ1100がクライアントマシン3100から登録されたファイルに関する情報を管理する。具体的に、登録ファイル管理表4100は、登録ファイルID4110と、登録ファイルパス名4120と、登録ファイルのメタデータ4130と、対応格納ファイルID4140という構成要素からなる。

ここで、登録ファイルID4110は、登録ファイルを一意に識別するための識別子であり、ファイル登録時にファイルサーバ1100が付与する通番に相当する。登録ファイルパス名4120は、クライアントマシン3100が対象ファイルを登録する時に指定した識別名であり、ファイル登録時にクライアントマシン3100が指定したファイル名あるいはファイルパス名に相当する。登録ファイルのメタデータ4130は、対象登録ファイルに関連付けられているメタデータの集合である。例えば、ファイル所有者、ファイル作成日時、ファイルサイズ、ファイルへのアクセス権情報などの情報が該当する。対応格納ファイルID4140は、対象登録ファイルに対応するデータファイル本体を格納する場所の識別情報である。この対応格納ファイルID4140は、格納ファイルシステム1171にて対象ファイルが格納される際に付与される。

図７は、ファイルサーバ1100上で管理する格納ファイル管理表4200の構成を例示する図である。格納ファイル管理表4200では、当該ファイルサーバ1100がクライアントマシン3100から登録されたファイルを、実際にファイルサーバ1100上の外部記憶装置1160に、重複排除を行った上で格納するファイルの情報を管理する。具体的に、格納ファイル管理表4200は、格納ファイルID4210と、格納ファイルパス名4220と、格納ファイルのメタデータ4230と、重複参照ファイル数4240と、照合情報4250と、対応登録ファイルID4260という構成要素からなる。

ここで、格納ファイルID4210は、ファイルサーバ1100において重複排除したファイルを実際に外部記憶装置1160に格納するファイルを一意に識別するための識別子であり、ファイル格納時にファイルサーバ1100が付与する通番に相当する。格納ファイルパス名4220は、ファイルサーバ1100が対象ファイルを格納する時に指定する識別名であり、ファイル格納時のファイルパス名に相当する。格納ファイルのメタデータ4230は、対象格納ファイルに関連付けられているメタデータの集合である。例えば、格納ファイルシステム1171へのファイル格納日時、ファイルサイズ、ファイルへのアクセス権情報などの情報が該当する。重複参照ファイル数4240は、対象格納ファイルを参照する登録ファイルの数を示す。重複排除によって、格納ファイルを複数の登録ファイルが共有する場合は、この重複参照ファイル数4240の値は２以上になる。例えば、この値が２である場合は、２つの登録ファイルが当該格納ファイルを参照していることになる。照合情報4250は、対象格納ファイルのデータファイルの内容が重複しているかどうかを判断するための情報である。例えば、対象データファイルのハッシュ値などが相当する。この照合情報4250を利用して、ファイルサーバ1100は、対象ファイルの重複判定を実施する。重複が発見された場合は、どちらか一方のファイルのみを格納することで重複排除を実現する。対応登録ファイルID4260は、対象格納ファイルに対応する登録ファイルの識別情報である。この対応登録ファイルID4260は、前記の通り、登録ファイルシステム1170にて対象ファイルが登録される際に付与される。この登録ファイルID4260の欄には、前述した重複参照ファイル数4240の欄に登録されている数と同じ数の登録ファイルIDが登録される。

図８は、ファイルサーバ1100上で管理する仮想ファイルシステム管理表4300の構成を例示する図である。仮想ファイルシステム管理表4300では、当該ファイルサーバ1100が検索サーバ2100向けに提供する仮想ファイルシステムに関する情報を管理する。具体的に、仮想ファイルシステム管理表4300は、仮想ファイルID4310と、仮想ファイルパス名4320と、仮想ファイルのメタデータ4330と、照合情報4340と、対応格納ファイルID4350という構成要素からなる。

ここで、仮想ファイルID4310は、ファイルサーバ1100上の仮想ファイルシステム1172に登録された仮想ファイルを一意に識別するための識別子であり、仮想ファイルシステム更新時にファイルサーバ1100が付与する通番に相当する。仮想ファイルパス名4320は、検索サーバ2100が、仮想ファイルシステム1172のファイルシステムイメージを通して対象ファイルにアクセスする際に利用するファイルパス名である。この仮想ファイルパス名4320は、仮想ファイルシステム更新時に、ファイルサーバ1100が付与する。仮想ファイルのメタデータ4330は、対象仮想ファイルに関連付けられているメタデータの集合である。例えば、仮想ファイルシステム1172へのファイル登録日時、ファイルサイズ、ファイル最終アクセス日時などの情報が該当する。照合情報4340は、仮想ファイルシステム更新時に、既に登録されている仮想ファイルと、新たに仮想ファイルシステム1172に登録する候補となるファイルの内容が重複しているかどうかを判断するための情報である。例えば、対象データファイルのハッシュ値などが相当する。この照合情報4340を利用して、ファイルサーバ1100は、対象ファイルの重複判定を実施する。重複が発見された場合は、既に仮想ファイルシステム1172に同じ内容のデータファイルが登録されているため、当該候補ファイルは仮想ファイルシステム1172には登録しない。対応格納ファイルID4350は、対象仮想ファイルに対応するデータファイル本体を格納するファイルの識別情報である。この対応格納ファイルID4350は、格納ファイルシステム1171にて対象ファイルが格納される際に付与される。

図９は、検索サーバ2100上で管理するクローリングファイル管理表4400の構成を例示する図である。クローリングファイル管理表4400では、検索サーバ2100が検索インデックスを作成するために、ファイルサーバ1100上より取得したファイルの情報を管理する。具体的に、クローリングファイル管理表4400は、ファイルパス名4410と、作成日時4420と、最終更新日時4430と、メタデータ4440という構成要素からなる。

ここで、ファイルパス名4410は、検索サーバ2100がファイルサーバ1100から対象ファイルを取得した際に、実際にアクセスしたファイルパス名を格納する。この場合、ファイルサーバ1100が提供する仮想ファイルシステム1172上の仮想ファイルパス名がこのファイルパス名となる。作成日時4420は、検索サーバ2100がファイルサーバ1100から取得したファイルの作成日時情報を格納する。最終更新日時4430は、検索サーバ2100がファイルサーバ1100から取得したファイルの最終更新日時情報を格納する。この最終更新日時4430の情報を利用することにより、クローリング処理において、クローリング管理表4400上の最終更新日時4430の情報と、ファイルサーバ1100上の対象ファイルの最終更新日時の情報を比較し、両者が一致すれば、前回クローリングした時から更新がないと判断できる。これにより、クローリング後のインデクシング処理をスキップすることができる。メタデータ4440は、対象ファイルに関連付けられているメタデータの集合である。例えば、ファイルサイズ、対象ファイルの情報がクローリングファイル管理表4400に登録された日時情報などが該当する。

図１０は、検索サーバ2100上で管理する検索インデックス管理表4500の構成を例示する図である。検索インデックス管理表4500では、検索サーバ2100が作成した検索インデックスの情報を管理する。具体的に、検索インデックス管理表4500は、キーワード4510と、該当位置情報4520という構成情報からなる。

キーワード4510は、対象ファイルをインデクシング処理にて解析して得られた文字列を格納する。該当場所情報4520は、当該キーワード4510の文字列が存在するファイルの情報を登録する。この該当場所情報4520は、該当ファイルパス名4521と、該当位置オフセット4522と、重要度情報4523という構成要素からなる。該当ファイルパス名4521は、当該キーワードの文字列が出現するファイルを識別するための情報として、対象ファイルのファイルパス名を登録する。該当位置オフセット4522は、当該ファイルの中で、キーワードの文字列が出現するオフセット情報を登録する。この欄では、一つのファイルで複数箇所出現する場合は、複数個のオフセット情報を登録する。重要度情報4523は、当該ファイルの当該オフセットにおいて、当該キーワードの文字列が出現することによる重要度の値を登録する。この重要度の値は、検索サーバ2100が適宜設定する。この値は、大きければ大きいほど重要だという意味づけを行う。また、この値は、検索結果の絞り込みや整列に利用できるようにする。なお、該当位置情報4520については、一つのキーワード4510に対して複数個登録可能にする。これにより、キーワード文字列に該当するファイルが複数存在する場合にも対応できるようにする。

ここまでに、本発明によって提供するシステムの構成と管理情報の構成について説明した。以降では、本発明によって実現する処理方式について説明する。ここでは、ファイル登録処理（図１１）、重複排除処理付きファイル格納処理（図１２）、ファイル登録時の仮想ファイルシステム更新処理（図１３）、クローリングとインデクシング処理（図１４）、ファイル検索処理（図１５）、ファイル取得処理（図１６）、ファイル更新処理（図１７）、重複排除処理付き格納ファイル更新処理（図１８）、ファイル更新時の仮想ファイルシステム更新処理（図１９）、ファイル削除処理（図２０）、重複排除処理付き格納ファイル削除処理（図２１）、およびファイル削除時の仮想ファイルシステム更新処理（図２２）について説明する。

図１１では、ファイル登録処理における一連の処理の流れを示す。はじめに、クライアントマシン3100は、登録対象ファイルをファイルサーバ1100に送信する(ステップS101)。次に、ファイルサーバ1100は、クライアントマシン3100から送られてきた登録対象ファイルを受信し、当該データをファイルサーバ1100上の一時格納領域に格納する(ステップS102)。次に、ファイルサーバ1100は、登録対象ファイルの情報を登録ファイル管理表4100に登録する(ステップS103)。なお、この段階では、対応格納ファイルID4140の情報は登録ファイル管理表4100に登録しない。次に、ファイルサーバ1100は、当該登録ファイルを対象に、重複排除処理付きファイル格納処理を行う(ステップS104)。この重複排除処理付きファイル格納処理の詳細は後述する。次に、ファイルサーバ1100は、登録ファイル管理表4100における対応格納ファイルID4140の欄に、処理ステップS104で格納した格納ファイルID4210の値を更新する(ステップS105)。次に、ファイルサーバ1100は、ファイル登録時向けの仮想ファイルシステム更新処理を行う(ステップS106)。このファイル登録時向けの仮想ファイルシステム更新処理の詳細は後述する。仮想ファイルシステム更新が終わった後、ファイルサーバ1100は、検索サーバ2100に対して、仮想ファイルシステム更新トリガを送信する(ステップS107)。このトリガを受信することを契機に、検索サーバ2100は、検索インデックス更新処理を行う。トリガを送信した後、ファイルサーバ1100は、登録対象ファイルの登録処理完了を、要求元であるクライアントマシン3100に応答する(ステップS108)。最後に、クライアントマシン3100は、ファイルサーバ1100より送られてきた登録処理完了を受信し、処理を終了する(ステップS109)。

ちなみに、本処理フローは、ファイルサーバ1100におけるファイル登録処理、ファイル格納処理、および仮想ファイルシステム更新処理を同期的に実行する処理フローとなっている。これらの処理を非同期的に実行する処理フローは、別実施例として後述する。

図１２では、重複排除処理付きファイル格納処理における一連の処理の流れを示す。本処理フローは、図１１における処理ステップS104の詳細処理フローに相当する。はじめに、ファイルサーバ1100は、今回の登録対象ファイルより照合情報を生成する(ステップS201)。ここで生成する照合情報は、格納ファイル管理表4200における照合情報4250のエントリ向けに生成する照合情報と同じ生成方法を利用することにする。照合情報を生成した後、ファイルサーバ1100は、生成した照合情報と同じものを持つファイルが既に格納されているかを調べる(ステップS202)。具体的には、格納ファイル管理表4100における照合情報4250のエントリに、今回生成した照合情報と合致するものがあるかどうかを調べる。処理ステップS202にてYesの場合、ファイルサーバ1100は、合致ファイルの格納ファイルID4210を格納ファイル管理表4200から取得する(ステップS203)。次に、ファイルサーバ1100は、格納ファイル管理表4200における当該合致ファイルのエントリを更新し(ステップS204)、処理を終了する。具体的には、当該エントリにおける重複参照ファイル数4240を加算し、対応登録ファイルID4260の欄に当該登録ファイルの登録ファイルID4110を追加登録する。他方、処理ステップS202にてNoの場合、ファイルサーバ1100は、対象ファイルと内容が重複するファイルは格納されていないと判断し、対象ファイルを格納する(ステップS205)。格納した後、ファイルサーバ1100は、格納対象ファイルの情報を格納ファイル管理表4200に登録し(ステップS206)、処理を終了する。

図１３では、ファイル登録時の仮想ファイルシステム更新処理における一連の処理の流れを示す。本処理は、図１１における処理ステップS106の詳細処理フローに相当する。はじめに、ファイルサーバ1100は、格納対象ファイルより照合情報を生成する(ステップS301)。ここで生成する照合情報は、格納ファイル管理表4200における照合情報4250のエントリ向けに生成する照合情報と同じ生成方法を利用することにする。なお、以前の処理において同様の照合情報を既に生成している場合は、改めて照合情報を生成するのではなく、その情報を流用しても良い。照合情報を生成した後、ファイルサーバ1100は、生成した照合情報と同じものを持つファイルが既に仮想ファイルシステムに登録されているかを調べる(ステップS302)。具体的には、仮想ファイルシステム管理表4300における照合情報4340のエントリに、今回生成した照合情報と合致するものがあるかどうかを調べる。処理ステップS302にてYesの場合、仮想ファイルシステムには登録対象ファイルと同じ内容を持つファイルが既に登録済みと判断し、本処理をここで終了する。他方、処理ステップS302にてNoの場合、仮想ファイルシステムには登録対象ファイルと同じ内容を持つファイルは未登録と判断する。この判断のもとに、ファイルサーバ1100は、対象ファイルに対応する仮想ファイルパス名4320を生成する(ステップS303)。次に、ファイルサーバ1100は、対象ファイルの情報を仮想ファイルシステム管理表4300に登録し(ステップS304)、処理を終了する。ここで、仮想ファイルシステム管理表4300において、対応格納ファイルID4350を登録する際、以前の処理で取得している格納ファイルID4210の値を登録する。

図１４では、クローリングとインデクシング処理における一連の処理の流れを示す。本処理フローは、図１１における処理ステップS107によって仮想ファイルシステム更新トリガが送信された後、検索サーバ2100にて実施する処理内容を示す。はじめに、検索サーバ2100は、ファイルサーバ1100から送信された仮想ファイルシステム更新トリガを受信する(ステップS401)。トリガ受信後、検索サーバ2100は、ファイルサーバ1100より、仮想ファイルシステムをクローリングし、任意のファイルを取得する(ステップS402)。ファイル取得後、検索サーバ1100は、対象ファイルは既にクローリングファイル管理表4400に登録済みかどうかを調べる(ステップS403)。処理ステップS403にてNoの場合、検索サーバ2100は、対象ファイルを解析し、その結果を検索インデックス管理表4500に登録する(ステップS404)。もし、処理ステップS403にてYesの場合、検索サーバ2100は、前回の検索インデックス更新時と比べて、対象ファイルが更新されているかどうかを調べる(ステップS406)。処理ステップS406にてYesの場合は、処理ステップS404に進み、Noの場合は、後述する処理ステップS407に進む。

処理ステップS404の後、検索サーバ2100は、対象ファイルの情報をクローリングファイル管理表4400に登録する(ステップS405)。その後、検索サーバは、仮想ファイルシステム上のファイルを調べたかどうかを確認する(ステップS407)。具体的には、検索サーバがクローリングしていないファイルが仮想ファイルシステム上に残っているかどうかを調べる。処理ステップS407にてNoの場合、他にもクローリングすべきファイルが残っているので、処理ステップS402に戻って処理を繰り返す。他方、処理ステップS407にてYesの場合、クローリングすべきファイルは残っていないので、以下の処理を行う。

検索サーバ2100は、クローリングファイル管理表4400の登録ファイルの中で、本処理を実施していないファイルは存在するかどうかを調べる(ステップS408)。具体的には、クローリングファイル管理表4400には登録されているが上記の処理ステップS402からS407にかけての処理を行っていないファイルが存在するかどうかを調べる。処理ステップS408にてNoの場合、本処理を終了する。他方、処理ステップS408にてYesの場合、前回の検索インデックス更新時から、仮想ファイルシステム上にてファイルが削除されている可能性があると判断し、その対応として以下の処理を行う。

検索サーバ2100は、対象ファイルがファイルサーバ1100上の仮想ファイルシステム上に存在するかどうかを調べる(ステップS409)。処理ステップS409にてYesの場合、対象ファイルに関するインデクシング処理は、上述の処理ステップS402からS407にかけての処理にて既に実施済みと判断し、本処理を終了する。他方、処理ステップS409にてNoの場合、検索サーバ2100は、検索インデックス管理表4500における対象ファイルに関する情報を削除する(ステップS410)。削除後、検索サーバ2100は、クローリングファイル管理表4400における対象ファイルに関する情報を削除する(ステップS411)。こちらも削除した後は、処理ステップS408に移り、引き続き同じ処理を行う。

図１５では、ファイル検索処理における一連の処理の流れを示す。はじめに、クライアントマシン3100は、検索クエリを指定して、検索サーバ2100にファイル検索要求を送信する(ステップS501)。ここで指定する検索クエリには、検索したいファイルに含まれる文字列などを含むようにする。次に、検索サーバ2100は、検索要求を受信し、検索インデックス管理表4500に登録されている情報をもとに、当該検索クエリの条件に合致するファイルを抽出する(ステップS502)。具体的には、当該検索クエリに指定されている検索文字列と、検索インデックス管理表4500におけるキーワード4510の欄に登録されている文字列とが一致するかどうかを調べ、一致したエントリを抽出する。抽出後、検索サーバ2100は、検索インデックス管理表4500における抽出エントリに含まれる重要度情報4523をもとに、抽出ファイルの中で対象ファイルを絞り込み、整列する(ステップS503)。具体的に、検索サーバ2100は、抽出ファイルの重要度を算出し、その値が規定値より小さい抽出ファイルを検索結果から除外する。さらに、検索サーバ2100は、残った抽出ファイル群の中で、当該重要度の値が大きい順に抽出ファイルを整列する。次に、検索サーバ2100は、検索クエリに合致するファイル群の情報として、上記処理ステップS503にて得られた結果を、ファイル検索結果として要求元に応答する(ステップS504)。最後に、クライアントマシン3100は、検索サーバ2100からのファイル検索結果を受信し(ステップS505)、処理を終了する。

図１６では、ファイル取得処理における一連の処理の流れを示す。本処理フローは、図１５におけるファイル検索処理によって取得したファイル検索結果をもとに、クライアントマシン3100が取得対象ファイルを選択の上、ファイルサーバ1100に対して当該検索結果に含まれるファイルパス名を用いてファイル取得を要求する時の処理内容を示す。

はじめに、クライアントマシン3100は、取得対象ファイルのファイルパス名を指定して、ファイルサーバ1100に対してファイル取得要求を送信する(ステップS601)。ここで、クライアントマシン3100が取得対象ファイルを指定するために利用するファイルパス名は、ファイルサーバ1100が提供する仮想ファイルシステム1172の仮想ファイルパス名となる。仮想ファイルパス名となる理由は、検索サーバ2100が当該仮想ファイルシステム1172をクローリングして検索インデックス2101を作成しており、当該検索サーバ2100が提供する検索結果には当該仮想ファイルパス名が利用されているためである。次に、ファイルサーバ1100は、ファイル取得要求を受信し、対象ファイル取得要求は、取得対象ファイルを仮想ファイルパス名で指定しているかどうかを調べる(ステップS602)。この処理において、ファイルサーバ1100が、仮想ファイルパス名とそれ以外のファイルパス名とを一意に識別できるようにする必要がある。このため、仮想ファイルパス名には、仮想ファイルパス名ならではの固有の識別情報を付加するようにする。例えば、ファイルシステムのルートディレクトリ名を特別な名前にすることなどが考えられる。この処理ステップS602にてYesの場合、ファイルサーバ1100は、指定された仮想ファイルパス名が仮想ファイルシステム管理表4300に登録されているかどうかを調べる(ステップS603)。処理ステップS603にてNoの場合、ファイルサーバ1100は、正しくない仮想ファイル名によるファイル取得要求と判断し、ファイル取得失敗をファイル要求元に応答し(ステップS606)、処理を終了する。他方、処理ステップS603にてYesの場合、ファイルサーバ1100は、仮想ファイルシステム管理表4300より、指定仮想ファイルパス名に対応する格納ファイルIDを取得する(ステップS604)。具体的には、仮想ファイルシステム管理表4300において、仮想ファイルパス名4320の欄に登録されているパス名が指定仮想ファイルパス名と一致するエントリを探す。その後、当該エントリにおける対応格納ファイルID4350の欄に登録されている格納ファイルIDを取得する。格納ファイルIDを取得した後、ファイルサーバ1100は、格納ファイル管理表4200より、当該格納ファイルIDに対応する登録ファイルIDを取得する(ステップS605)。具体的には、格納ファイル管理表4200において、格納ファイルパス名4220の欄に登録されているパス名が当該格納ファイルパス名と一致するエントリを探す。その後、当該エントリにおける対応登録ファイルID4260の欄に登録されている登録ファイルIDを取得する。登録ファイルIDを取得した後、ファイルサーバ1100は、当該ファイル取得要求者が対象登録ファイルに対するアクセス権を持っているかどうかを調べる(ステップS607)。具体的には、登録ファイル管理表4100において、登録ファイルID4110の欄に登録されているファイルIDが当該登録ファイルIDと一致するエントリを探す。その後、当該エントリにおける登録ファイルのメタデータ4130に登録されている当該ファイルに対するACL(Access Control List)などのアクセス権情報を取得する。その後、ファイルサーバ1100は、本ファイル取得処理を要求したユーザが対象登録ファイルに対するアクセス権を持っているかどうかを調べることになる。

処理ステップS607にてYesの場合、ファイルサーバ1100は、アクセス権があると判断し、取得対象ファイルとして当該登録ファイルをファイル要求元に応答する(ステップS608)。その後、クライアントマシン3100は、ファイルサーバからのファイル取得結果を受信し(ステップS609)、処理を終了する。他方、処理ステップS607にてNoの場合、ファイルサーバ1100は、アクセス権がないと判断し、取得対象ファイルに該当する他の候補となる登録ファイルが存在するかどうかを調べる(ステップS610)。具体的には、処理ステップS605と同じ処理を行う。複数個の登録ファイルが存在すれば、これを他の候補となる登録ファイルとして見なすことができる。処理ステップS610にてYesの場合、処理ステップS605に移る。これにより、ファイルサーバ1100は、他の候補となる登録ファイルの登録ファイルIDを取得し、同様のアクセス権判定処理を再度行うことができるようになる。他方、処理ステップS610にてNoの場合、ファイルサーバ1100は、アクセス権がないファイルに対するファイル取得要求と判断し、ファイル取得失敗をファイル要求元に応答し(ステップS611)、処理を終了する。

さらに、処理ステップS602にてNoの場合、ファイルサーバ1100は、当該ファイル取得要求を登録ファイルシステム1170の登録ファイルパス名を利用したものと判断し、処理ステップS607に移る。以降、ファイルサーバ1100は、登録ファイルシステム1170を利用した通常のファイルサービスにおけるファイル取得処理と同等の処理を行う。

図１７では、ファイル更新処理における一連の処理の流れを示す。本処理フローは、図１１におけるファイル登録処理とほぼ同じ処理の流れになっている。

はじめに、クライアントマシン3100は、更新対象ファイルをファイルサーバ1100に送信する(ステップS701)。次に、ファイルサーバ1100は、クライアントマシン3100から送られてきた更新対象ファイルを受信し、当該データをファイルサーバ1100上の一時格納領域に格納する(ステップS702)。次に、ファイルサーバ1100は、更新対象ファイルの情報を登録ファイル管理表4100に更新する(ステップS703)。なお、この段階では、対応格納ファイルID4140の情報は登録ファイル管理表4100に更新しない。次に、ファイルサーバ1100は、当該更新ファイルを対象に、重複排除処理付き格納ファイル更新処理を行う(ステップS704)。この重複排除処理付き格納ファイル更新処理の詳細は後述する。次に、ファイルサーバ1100は、登録ファイル管理表4100における対応格納ファイルID4140の欄に、処理ステップS704で格納した格納ファイルID4210の値を更新する(ステップS705)。次に、ファイルサーバ1100は、ファイル更新時向けの仮想ファイルシステム更新処理を行う(ステップS706)。この仮想ファイルシステム更新処理の詳細は後述する。仮想ファイルシステム更新処理が終わった後、ファイルサーバ1100は、検索サーバ2100に対して、仮想ファイルシステム更新トリガを送信する(ステップS707)。このトリガを受信することを契機に、検索サーバ2100は、検索インデックス更新処理を行う。トリガを送信した後、ファイルサーバ1100は、更新対象ファイルの更新処理完了を、要求元であるクライアントマシン3100に応答する(ステップS708)。最後に、クライアントマシン3100は、ファイルサーバ1100より送られてきた更新処理完了を受信し(ステップS709)、処理を終了する。

図１８では、重複排除処理付き格納ファイル更新処理における一連の処理の流れを示す。本処理フローは、図１７における処理ステップS704の詳細処理フローに相当する。また、本処理フローは、図１２における重複排除処理付きファイル格納処理とほぼ同じ処理の流れになっている。

はじめに、ファイルサーバ1100は、今回の更新対象ファイルより照合情報を生成する(ステップS801)。ここで生成する照合情報は、格納ファイル管理表4200における照合情報4250のエントリ向けに生成する照合情報と同じ生成方法を利用することにする。照合情報を生成した後、ファイルサーバ1100は、生成した照合情報と同じものを持つファイルが既に格納されているかを調べる(ステップS802)。具体的には、格納ファイル管理表4200における照合情報4250のエントリに、今回生成した照合情報と合致するものがあるかどうかを調べる。処理ステップS802にてYesの場合、ファイルサーバ1100は、合致ファイルの格納ファイルID4210を格納ファイル管理表4200から取得する(ステップS803)。次に、ファイルサーバ1100は、格納ファイル管理表4200における当該合致ファイルのエントリを更新する(ステップS804)する。具体的には、当該エントリにおける重複参照ファイル数4240を加算し、対応登録ファイルID4260の欄に当該登録ファイルの登録ファイルID4110を追加登録する。最後に、ファイルサーバ1100は、格納ファイル管理表4200において、当該更新対象ファイルが元々対応付けられていた格納ファイルのエントリを更新し(ステップS807)、処理を終了する。具体的には、ファイル更新処理に伴い、更新前の登録ファイルと更新後の登録ファイルとでは、対応付けられる格納ファイルが異なることになる。このため、ファイルサーバ1100は、更新前の登録ファイルに対応付けられている格納ファイルのエントリを、格納ファイル管理表4200から探し出し、当該エントリの重複参照ファイル数4240の値を減算し、かつ対応登録ファイルID4260の欄から、当該更新前登録ファイルの登録ファイルIDを削除する。

他方、処理ステップS802にてNoの場合、ファイルサーバ1100は、対象ファイルと内容が重複するファイルは格納されていないと判断し、対象ファイルを格納する(ステップS805)。格納した後、ファイルサーバ1100は、格納対象ファイルの情報を格納ファイル管理表4200に登録する(ステップS806)。最後に、ファイルサーバ1100は、上述の処理ステップS807の処理を行い、処理を終了する。

図１９では、ファイル更新時の仮想ファイルシステム更新処理における一連の処理の流れを示す。本処理フローは、図１７における処理ステップS706の詳細処理フローに相当する。また、本処理フローは、図１３における重複排除処理付きファイル格納処理とほぼ同じ処理の流れになっている。

はじめに、ファイルサーバ1100は、格納対象ファイルより照合情報を生成する(ステップS901)。ここで生成する照合情報は、格納ファイル管理表4200における照合情報4250のエントリ向けに生成する照合情報と同じ生成方法を利用することにする。なお、以前の処理において同様の照合情報を既に生成している場合は、改めて照合情報を生成するのではなく、その情報を流用しても良い。照合情報を生成した後、ファイルサーバ1100は、生成した照合情報と同じものを持つファイルが既に仮想ファイルシステムに登録されているかを調べる(ステップS902)。具体的には、仮想ファイルシステム管理表4300における照合情報4340のエントリに、今回生成した照合情報と合致するものがあるかどうかを調べる。処理ステップS902にてYesの場合、ファイルサーバ1100は、仮想ファイルシステム管理表4300において、当該更新対象ファイルが元々対応づけられていた仮想ファイルのエントリを更新し(ステップS905)、処理を終了する。具体的には、図１８の説明と同様に、ファイル更新処理に伴い、更新前の登録ファイルと更新後の登録ファイルとでは、対応付けられる仮想ファイルが異なることになる。このため、ファイルサーバ1100は、更新前の登録ファイルに対応付けられている格納ファイルのエントリを、格納ファイル管理表4200から探し出し、該当する格納ファイルIDを取得する。その後、ファイルサーバ1100は、当該格納ファイルに対応付けられている仮想ファイルのエントリを、仮想ファイルシステム管理表4300から探し出す。その後、ファイルサーバ1100は、当該エントリの対応格納ファイルID4350の欄において、当該更新前登録ファイルに対応付けられている格納ファイルIDから、当該更新後ファイルに対応付けられている格納ファイルIDに更新する。

他方、処理ステップS902にてNoの場合、仮想ファイルシステムには更新対象ファイルと同じ内容を持つファイルは未登録と判断する。この判断のもとに、ファイルサーバ1100は、対象ファイルに対応する仮想ファイルパス名4320を生成する(ステップS903)。次に、ファイルサーバ1100は、対象ファイルの情報を仮想ファイルシステム管理表4300に登録し(ステップS904)、処理を終了する。ここで、仮想ファイルシステム管理表4300において、対応格納ファイルID4350を登録する際、以前の処理で取得している格納ファイルID4210の値を登録する。

図２０では、ファイル削除処理における一連の処理の流れを示す。本処理フローは、図１１におけるファイル登録処理とほぼ同じ処理の流れになっている。

はじめに、クライアントマシン3100は、削除対象ファイルの情報をファイルサーバ1100に送信する(ステップS1001)。次に、ファイルサーバ1100は、クライアントマシン3100から送られてきた削除対象ファイルの情報を受信し、当該削除ファイルを対象に、重複排除処理付き格納ファイル削除処理を行う(ステップS1002)。この重複排除処理付き格納ファイル削除処理の詳細は後述する。次に、ファイルサーバ1100は、削除対象ファイルの情報を登録ファイル管理表4100から削除する(ステップS1003)。次に、ファイルサーバ1100は、ファイル削除時向けの仮想ファイルシステム更新処理を行う(ステップS1004)。このファイル削除時向けの仮想ファイルシステム更新処理の詳細は後述する。仮想ファイルシステム更新が終わった後、ファイルサーバ1100は、検索サーバ2100に対して、仮想ファイルシステム更新トリガを送信する(ステップS1005)。このトリガを受信することを契機に、検索サーバ2100は、検索インデックス更新処理を行う。トリガを送信した後、ファイルサーバ1100は、削除対象ファイルの削除処理完了を、要求元であるクライアントマシン3100に応答する(ステップS1006)。最後に、クライアントマシン3100は、ファイルサーバ1100より送られてきた削除処理完了を受信し(ステップS1007)、処理を終了する。

図２１では、重複排除処理付き格納ファイル削除処理における一連の処理の流れを示す。本処理フローは、図２０における処理ステップS1002の詳細処理フローに相当する。

はじめに、ファイルサーバ1100は、削除対象対応する格納ファイルIDを取得する(ステップS1101)。具体的には、登録ファイル管理表4100より、削除対象として指定された登録ファイルのエントリを探し、当該エントリにおける対応格納ファイルID4140の値を取得する。その後、ファイルサーバ1100は、格納ファイル管理表4200における当該格納ファイルのエントリを更新する(ステップS1102)。具体的には、格納ファイル管理表4200より、前記の処理ステップS1101によって取得した格納ファイルIDが登録されているエントリを探す。その後、当該エントリにおける重複参照ファイル数4240の値を減算し、かつ当該エントリにおける対応登録ファイルID4260の欄から、今回削除対象となっている対象登録ファイルの登録ファイルIDを削除する。格納ファイル管理表4200のエントリを更新した後、ファイルサーバ1100は、当該格納ファイルの重複参照ファイル数4240の値が0になったかどうかを調べる(ステップS1103)。具体的には、前述した処理ステップS1102の処理にて探したエントリにおける重複参照ファイル数4240の値が0かどうかを調べる。処理ステップS1103にてYesの場合、ファイルサーバ1100は、対象格納ファイルを参照する登録ファイルがなくなったと判断し、当該格納ファイルを削除する(ステップS1104)。削除した後、ファイルサーバ1100は、格納ファイル管理表4200における当該格納ファイルのエントリを削除し(ステップS1105)、処理を終了する。

他方、処理ステップS1103にてNoの場合、ファイルサーバ1100は、対象格納ファイルの削除は現時点で不要と判断し、処理を終了する。

図２２では、ファイル削除時の仮想ファイルシステム更新処理における一連の処理の流れを示す。本処理フローは、図２０における処理ステップS1004の詳細処理フローに相当する。

はじめに、ファイルサーバ1100は、仮想ファイルシステム管理表4300より、削除対象ファイルに対応する格納ファイルIDを取得する(ステップS1201)。具体的には、登録ファイル管理表4100より、削除対象として指定された登録ファイルのエントリを探し、当該エントリにおける対応格納ファイルID4140の値を取得する。その後、ファイルサーバ1100は、格納ファイル管理表4200より、当該格納ファイルIDを持つエントリが存在するかどうかを調べる(ステップS1202)。具体的には、格納ファイル管理表4200より、前記の処理ステップS1201によって取得した格納ファイルIDが登録されているエントリが存在するかどうかを調べる。

処理ステップS1202にてYesの場合、ファイルサーバ1100は、今回のファイル削除処理によって、格納ファイルの削除は行われていない、すなわち仮想ファイルシステム1172への更新は不要であると判断し、処理を終了する。

他方、処理ステップS1202にてNoの場合、ファイルサーバ1100は、今回のファイル削除処理によって、格納ファイルの削除が行われている、すなわち仮想ファイルシステム1172への更新は必要と判断し、削除対象ファイルの情報を仮想ファイルシステム管理表4300から削除し(ステップS1203)、処理を終了する。具体的には、仮想ファイルシステム管理表4300の対応格納ファイルID4350の欄に、前記の処理ステップS1201によって取得した格納ファイルIDが登録されているエントリが存在するかどうかを調べる。もし該当するエントリが存在すれば、当該エントリを仮想ファイルシステム管理表4300から削除する。

以上、本発明の実施例１について説明したが、本発明はこの実施例１に限定されることなくその趣旨を逸脱しない範囲内で種々の構成をとることができることは言うまでもない。

上述した実施例１は、ファイルサーバ1100におけるファイル登録処理、重複排除処理付きファイル格納処理、および仮想ファイルシステム更新処理を同期的に実行する形態を扱っている。しかし、ファイルサーバ1100は、ファイル登録処理と、それ以降の二つの処理を非同期に実行するようにしても良い。これらの処理を非同期に実行することにより、ファイルサーバ1100は、ファイル登録を要求するクライアントマシン3100に対してレスポンスタイムを短くすることができるのに加え、ファイル格納処理や仮想ファイルシステム更新処理をファイルサーバ1100内の負荷状況に応じて実行することができる。そこで、以降では、ファイルサーバ1100におけるファイル登録処理とそれ以降の処理を非同期に実行する場合における制御方式を実施例２として説明する。

上述のように、非同期実行を行うためには、ファイル登録処理の一部内容を変更する必要がある。この変更内容を図２３によって説明する。なお、ここでは、ファイル登録処理の変更内容を説明するが、これ以外にも、ファイル更新処理ならびにファイル削除処理についても同様の変更が必要になる。ただし、これらの処理に対する変更内容は、ファイル登録処理に対する変更内容と同じであるため、ここでは説明を省略する。

図２３では、ファイル登録処理の変更内容を示す。本処理フローは、図１１にて説明したファイル登録処理と比べて、登録対象ファイルの情報を登録ファイル管理表4100に登録するだけで登録処理受付完了をクライアントマシン3100に同期的に応答し、残りの処理は非同期実行する。具体的には、以下で説明する。

はじめに、図１１のファイル登録処理の最初から処理ステップS103まで行った後、ファイルサーバ1100は、ファイル格納処理と仮想ファイルシステム更新処理の非同期実行を要求する(ステップS110)。当該要求は、ファイルサーバ1100内のファイル管理制御プログラム1124で受け付けられる。受け付けられた要求は、ファイルサーバ1100において、ファイル格納と仮想ファイルシステム更新の非同期実行処理として、しかるべき時期に実行される。

このファイル格納と仮想ファイルシステム更新の非同期実行処理では、図１１のファイル登録処理の処理ステップS104、S105、S106およびS107を逐次的に実行する。

処理ステップS110の後、ファイルサーバ1100は、登録対象ファイルの登録受付処理完了をクライアントマシン3100に応答する(ステップS111)。その後、クライアントマシン3100は、登録受付処理完了を受信し(ステップS112)、処理を終了する。なお、この応答では、登録処理を受け付けたということを意味している。したがって、この応答は、登録対象ファイルがファイルサーバ1100上の格納ファイルシステムに格納されること、ならびに仮想ファイルシステムに反映されていることを保証しない。

以上の処理を行うことで、ファイル登録処理とは非同期に、ファイル格納処理ならびに仮想ファイルシステム更新処理を行うことが可能になる。

なお、仮想ファイルシステム更新処理のみをファイル登録処理と非同期に実行し、重複排除処理付きファイル格納処理についてはファイル登録処理と同期的に実行しても良い。

上述した実施例１は、ファイルサーバ1100におけるファイル登録処理、重複排除処理付きファイル格納処理、および仮想ファイルシステム更新処理を同期的に実行する形態を扱っている。しかし、ファイルサーバ1100は、ファイル登録処理、ファイル格納処理、および仮想ファイルシステム更新処理をそれぞれ非同期に実行するようにしても良い。非同期に実行することにより、ファイルサーバ1100は、ファイル登録を要求するクライアントマシン3100に対して、レスポンスタイムを短くすることができるようになる。さらに、上記の実施例２よりも柔軟に、ファイル格納処理や仮想ファイルシステム更新処理をファイルサーバ1100内の負荷状況に応じて実行することができようになる。そこで、以降では、ファイルサーバ1100におけるファイル登録処理、ファイル格納処理、および仮想ファイルシステム更新処理を非同期に実行する場合における制御方式を実施例３として説明する。

上述のように、非同期実行を行うためには、ファイル登録処理の一部内容を変更する必要がある。この変更内容を図２４によって説明する。なお、ここでは、ファイル登録処理の変更内容を説明するが、これ以外にも、ファイル更新処理ならびにファイル削除処理についても同様の変更が必要になる。ただし、これらの処理に対する変更内容は、ファイル登録処理に対する変更内容と同じであるため、ここでは説明を省略する。

図２４では、ファイル登録処理の変更内容を示す。本処理フローは、図１１にて説明したファイル登録処理と比べて、登録対象ファイルの情報を登録ファイル管理表4100に登録するだけで登録処理受付完了をクライアントマシン3100に同期的に応答し、残りの二つの処理はお互いに非同期実行する。具体的には、以下で説明する。

はじめに、図１１のファイル登録処理の最初から処理ステップS103まで行った後、ファイルサーバ1100は、ファイル格納処理の非同期実行を要求する(ステップS113)。当該要求は、ファイルサーバ1100内のファイル管理制御プログラム1124で受け付けられる。受け付けられた要求は、ファイルサーバ1100において、ファイル格納の非同期実行処理として、しかるべき時期に実行される。

このファイル格納の非同期実行処理において、図１１のファイル登録処理の処理ステップS104ならびにS105を逐次的に実行した後で、ファイルサーバ1100は、仮想ファイルシステム更新処理の非同期実行を要求する(ステップS114)。当該要求は、ファイルサーバ1100内のファイル管理制御プログラム1124で受け付けられる。受け付けられた要求は、ファイルサーバ1100において、仮想ファイルシステム更新の非同期実行処理として、しかるべき時期に実行される。この仮想ファイルシステム更新の非同期実行処理では、図１１のファイル登録処理の処理ステップS106ならびにS107を逐次的に実行する。

上述の処理ステップS113の後、ファイルサーバ1100は、登録対象ファイルの登録受付処理完了をクライアントマシン3100に応答する(ステップS111)。その後、クライアントマシン3100は、登録受付処理完了を受信し(ステップS112)、処理を終了する。なお、この応答では、登録処理を受け付けたということを意味している。したがって、この応答は、登録対象ファイルがファイルサーバ1100上の格納ファイルシステムに格納されること、ならびに仮想ファイルシステムに反映されていることを保証しない。

以上の処理を行うことで、ファイル登録処理、ファイル格納処理、および仮想ファイルシステム更新処理をそれぞれ非同期に行うことが可能になる。

上述した実施例１は、検索サーバ2100がファイルサーバ1100上の仮想ファイルシステム1172をクローリングして検索インデックス2101を作成する形態を扱っている。本形態において検索サーバ2100からは、検索インデックス作成対象となるファイルは、仮想ファイルシステム1172を介した仮想ファイルとしてしかアクセスできない。この場合、当該仮想ファイルに対応付けられる登録ファイルに対して、付与されていたメタデータの情報を検索サーバ側からはアクセス困難になるという問題が生じる。例えば、当該登録ファイルに設定されているアクセス権情報を取得することができない。このため、検索サーバ2100は、対象ファイルに設定されているアクセス権情報をもとに、検索結果に含めるファイルに関して、アクセス権があるファイルのみに絞込みを行うことが困難となる。したがって、ファイルサーバ1100は、仮想ファイルシステムを介して、検索対象ファイルとなる仮想ファイルに対応付けられている登録ファイルのメタデータを検索サーバ2100が取得できるようにする手段を提供する必要がある。そこで、以降では、ファイルサーバ1100における重複排除ファイルのメタデータ取得処理に関する制御方式を実施例４として説明する。

上述のように、仮想ファイルに対応付けられた登録ファイルのメタデータを取得できるようにするためには、かかるメタデータの取得処理を実現する必要がある。この処理を、重複排除ファイルのメタデータ取得処理として、処理内容を図２５によって説明する。また、検索サーバ2100は、当該メタデータ取得処理を利用して、検索対象ファイルに設定されているアクセス権情報をもとに、検索結果に含めるファイルの絞込みを行えるようになる。この絞込み処理を行う契機は、検索インデックス作成時ならびにクライアントマシン3100からのファイル検索要求時である。そこで、前者の検索インデックス作成時における実現のために、図１４で前述したクローリングとインデクシング処理の内容を一部変更する必要がある。この変更内容を図26によって説明する。また、後者のファイル検索要求時における実現のために、図１５で前述したファイル検索処理の内容を一部変更する必要がある。この変更内容を図２７によって説明する。

図２５では、重複排除ファイルのメタデータ取得処理における一連の処理の流れを示す。はじめに、ファイルサーバ1100は、ファイルサーバ1100以外の装置から送信されたメタデータ取得要求を受信する(ステップ1301)。ここで、当該メタデータ取得要求の送信方法としては、従来のファイルシステムにおけるファイルのメタデータ取得要求と同じ方法、コマンド、あるいはAPIを利用すれば良い。例えば、従来のメタデータ取得コマンドが、”get-metadata”であるとする。従来のファイルシステム上のファイルに対して当該”get-metadata”コマンドを実行した場合、対象ファイルのメタデータを取得することができる。他方、本発明における仮想ファイルシステム上の仮想ファイルに対して当該コマンドを実行した場合、対象仮想ファイルそのもののメタデータに加えて、当該仮想ファイルに対応付けられている登録ファイルのメタデータについても取得できるようにする。もし、当該仮想ファイルに対して、複数個の登録ファイルが対応付けられている場合は、該当する全ての登録ファイルのメタデータ情報を取得できるようにしても良いし、任意の一つの登録ファイルのメタデータ情報を取得できるようにしても良い。また、当該メタデータ取得コマンドにオプション指定をできるようにすることで、仮想ファイルそのもののメタデータのみを取得することや、仮想ファイルに対応付けられている任意の登録ファイルのメタデータのみを取得することや、仮想ファイルに対応付けられている全ての登録ファイルのメタデータ一式を取得することなどを実行できるようにしても良い。

メタデータ取得要求を受信後、ファイルサーバ1100は、当該メタデータ取得要求が取得対象ファイルを仮想ファイルパス名で指定しているかどうかを調べる(ステップS1302)。もし、処理ステップS1302にてNoの場合、ファイルサーバ1100は、仮想ファイルシステムとは無関係のファイルに対してメタデータ取得処理要求がなされたと判断し、取得処理失敗を要求元に応答して(ステップS1309)、処理を終了する。なお、処理ステップS1309において、メタデータ取得対象として、登録ファイルシステム上に存在する登録ファイルシステムを指定していた場合は、当該登録ファイルのメタデータを提供するようにしても良い。

他方、処理ステップS1302にてYesの場合、ファイルサーバ1100は、指定された仮想ファイルパス名が、仮想ファイルシステム管理表4300に登録されているかどうかを調べる(ステップS1303)。もし、処理ステップS1303にてNoの場合、ファイルサーバ1100は、仮想ファイルシステム上に存在しない仮想ファイルに対してメタデータ取得処理要求がなされたと判断し、前述の処理ステップS1309に移る。他方、処理ステップS1303にてYESの場合、ファイルサーバ1100は、仮想ファイルシステム管理表4300より、指定仮想ファイルパス名に対応する格納ファイルIDを取得する(ステップS1304)。その後、ファイルサーバ1100は、格納ファイル管理表4200より、当該格納ファイルIDに対応する登録ファイルIDを取得する(ステップS1305)。その後、ファイルサーバ1100は、登録ファイル管理表4100より、当該登録ファイルに対応するメタデータ情報を取得する(ステップS1306)。その後、ファイルサーバ1100は、前述の処理ステップS1306にてメタデータを取得した登録ファイルの他に、当該格納ファイルIDに対応する登録ファイルが存在するかどうかを調べる(ステップS1307)。もし、処理ステップS1307にてYesの場合、前述の処理ステップS1305に移り、引き続き対応登録ファイルの情報を取得する。なお、任意の一つの登録ファイルに関するメタデータのみを取得する必要がある場合は、当該処理をスキップし、後述の処理ステップS1308に移っても良い。他方、処理ステップS1307にてNoの場合、ファイルサーバ1100は、取得した登録ファイルIDならびにメタデータ一式を要求元に返送する(ステップS1308)。

以上の処理により、ファイルサーバ1100は、仮想ファイルシステム上の仮想ファイルに対応付けられる登録ファイルのメタデータの情報を提供することができるようになる。

図２６では、クローリングとインデクシング処理の変更内容を示す。本処理フローは、図１４にて説明したクローリングとインデクシング処理と比べて、クローリング対象の仮想ファイルに対し、図２５で前述した重複排除ファイルのメタデータ取得機能を利用することで、当該仮想ファイルに対応付けられている登録ファイルのメタデータの情報も取得することができる。具体的には、以下で説明する。

はじめに、図１４のクローリングとインデクシング処理の最初から処理ステップS405まで行った後、検索サーバ2100は、ファイルサーバに対して、対象ファイルパス名指定で、重複排除ファイルのメタデータ取得を要求する(ステップS412)。ここで、検索サーバ2100からはファイルサーバ1100の仮想ファイルシステム上の仮想ファイルをクローリングしているため、対象ファイルパス名には、当該仮想ファイルシステムの仮想パス名を指定することになる。仮想ファイルパス名でメタデータ取得要求を出すことになるため、ファイルサーバ1100側では、図２５で前述した重複排除ファイルのメタデータ取得処理を行うことになる。要求を出してその応答が返ってきた後、検索サーバ2100は、メタデータを取得できたかどうかを調べる(ステップS413)。もし、処理ステップS413にてNoの場合、検索サーバ2100は、メタデータを取得できていないと判断し、処理ステップS407に移り、以降、図14と同様の処理を行う。他方、処理ステップS413にてYesの場合、検索サーバ2100は、メタデータを取得できたと判断し、取得メタデータをクローリングファイル管理表4400に登録する(ステップS414)。具体的には、クローリングファイル管理表4400において、対象ファイルパス名が合致するエントリを探し、当該エントリのメタデータ4440の欄に、今回取得したメタデータ一式を登録する。取得メタデータを登録した後、処理ステップS407に移り、以降、図１４と同様の処理を行う。

図２７では、ファイル検索処理の変更内容を示す。本処理フローは、図１５にて説明したファイル検索処理と比べて、検索クエリの条件に合致したファイル群に対し、図２５で前述した重複排除ファイルのメタデータ取得機能を利用することで、当該ファイルに対応付けられている登録ファイルのメタデータの情報も取得することができる。これにより、検索結果の中から、アクセス権のないファイルを除外することも可能になる。具体的には、以下で説明する。

はじめに、図１５のファイル検索処理の最初から処理ステップS503まで行った後、検索サーバ2100は、ファイルサーバに対して、対象ファイルパス名指定で、重複排除ファイルのメタデータ取得を要求する(ステップS506)。ここで、検索サーバ2100からはファイルサーバ1100の仮想ファイルシステム上の仮想ファイルをクローリングしているため、対象ファイルパス名には、当該仮想ファイルシステムの仮想パス名を指定することになる。仮想ファイルパス名でメタデータ取得要求を出すことになるため、ファイルサーバ1100側では、図２５で前述した重複排除ファイルのメタデータ取得処理を行うことになる。要求を出してその応答が返ってきた後、検索サーバ2100は、メタデータを取得できたかどうかを調べる(ステップS507)。もし、処理ステップS507にてNoの場合、検索サーバ2100は、メタデータを取得できていないと判断し、処理ステップS504に移り、以降、図１５と同様の処理を行う。他方、処理ステップS507にてYesの場合、検索サーバ2100は、メタデータを取得できたと判断し、取得メタデータをもとに、検索クエリの条件に合致した抽出ファイルの中で対象ファイルを再度絞り込んだ上で整列する(ステップS508)。例えば、取得したメタデータの中のアクセス権情報をもとに、検索クエリを送ってきたユーザがアクセス可能なファイルのみを検索結果に含ませるようにすることも可能である。処理ステップS508の後、処理ステップS407に移り、以降、図１５と同様の処理を行う。

上述した実施例１は、検索サーバ2100がファイルサーバ1100上の仮想ファイルシステム1172をクローリングして検索インデックス2101を作成する形態を扱っている。しかし、仮想ファイルシステム1172のかわりに、ファイルサーバ1100上の格納ファイルシステム1171を提供する形態をとる形態も考えることができる。本形態により、ファイルサーバ1100は、重複なき格納ファイルの集合を検索サーバ2100に提供することが可能である。仮想ファイルシステム1172を提供する形態では、検索サーバ2100によるクローリング処理に特化した形でファイルシステムイメージを提供することができる。その一方で、格納ファイルシステム1171を提供する形態では、特別な仮想ファイルシステム1172を作成する必要がないので、低オーバヘッドでファイルシステムイメージを提供することができる。そこで、以降では、ファイルサーバ1100における格納ファイルシステム1171を検索サーバ2100に提供する形態に関する制御方式を実施例５として説明する。

上述のように、仮想ファイルシステム1172を提供するかわりに、格納ファイルシステム1171を提供するためには、クライアントマシン3100ならびに検索サーバ2100からのファイルアクセス関連処理の内容を一部変更する必要がある。具体的には、ファイル登録処理、ファイル更新処理、ファイル削除処理、ファイル取得処理、および重複排除ファイルのメタデータ取得処理が該当する。ここでは、ファイル登録処理の変更内容を図２８によって説明する。なお、ファイル更新処理ならびにファイル削除処理の変更内容については、ファイル登録処理と重複するため、ここでの説明は省略する。また、ファイル取得処理の変更内容を図２９によって説明する。また、重複排除ファイルのメタデータ取得処理の変更内容を図３０によって説明する。

図２８では、ファイル登録処理の変更内容を示す。本処理フローは、図１１にて説明したファイル登録処理と比べて、仮想ファイルシステムを作成せずに、重複排除を行った後のファイルを保管する格納ファイルシステム1171を検索サーバ2100向けに提供する。具体的には、以下で説明する。

はじめに、図１１のファイル登録処理の最初から処理ステップS105まで行った後、ファイルサーバ1100は、検索サーバ2100に対して、格納ファイルシステム更新トリガを送信する(ステップS115)。具体的には、ファイルサーバ1100上の格納ファイルシステム1171をファイルサーバ1100外の装置からもアクセスできるようにするための設定をした上で、検索サーバ2100に対して、クローリング処理を当該格納ファイルシステム1171に対して行う契機となるトリガを送信する。検索サーバ2100は、当該トリガを受信後、クローリング処理を行うようにする。処理ステップS115の後、処理ステップS108に移り、以降、図１１と同様の処理を行う。

図２９では、ファイル取得処理の変更内容を示す。本処理フローは、図１６にて説明したファイル登録処理と比べて、指定された仮想ファイルパス名から格納ファイルIDを取得する処理が不要になる。具体的には、以下で説明する。

はじめに、図１６のファイル取得処理の最初から処理ステップS603まで行った後、処理ステップS603にてYesの場合、ファイルサーバ1100は、処理ステップS604を行わずに、処理ステップS605に移る。以降、図１５と同様の処理を行う。これは、クライアントマシン3100からファイル取得要求を受ける際、クライアントマシン3100が指定するファイルパス名として、本実施例のケースでは、格納ファイルパス名が指定されるためである。

図３０では、重複排除ファイルのメタデータ取得処理の変更内容を示す。本処理フローは、図２５にて説明した重複排除ファイルのメタデータ取得処理と比べて、指定された仮想ファイルパス名から格納ファイルIDを取得する処理が不要になる。具体的には、以下で説明する。

はじめに、図２５のファイル取得処理の最初から処理ステップS1303まで行った後、処理ステップS1303にてYesの場合、ファイルサーバ1100は、処理ステップS1304を行わずに、処理ステップS1305に移る。以降、図２５と同様の処理を行う。これは、検索サーバ2100から重複排除ファイルのメタデータ取得要求を受ける際、検索サーバ2100が指定するファイルパス名として、本実施例のケースでは、格納ファイルパス名が指定されるためである。

上述した実施例１は、ファイルサーバ1100が検索サーバ2100に対して、ファイル登録処理、ファイル更新処理およびファイル削除処理の中で、トリガを通知する形態を扱っている。しかし、このトリガを検索サーバ2100に送らない形態も考えることができる。本形態により、検索サーバ2100は、ファイルサーバ1100からのトリガ通知を受けずに、自由な契機で対象仮想ファイルシステムをクローリングすることも可能である。トリガを通知する形態では、ファイルサーバ1100上の仮想ファイルシステムの更新が完了している状態でクローリングすることができるため、ファイルサーバ1100と検索サーバ2100との間で整合性をとりやすい。その一方で、トリガを通知しない形態では、ファイルサーバ1100上の仮想ファイルシステムの更新が完了している状態でクローリングすることが必ずしもできないため、整合性をとりにくい。その反面、トリガ送信のオーバヘッドを削減できる特長がある。そこで、ファイルサーバ1100におけるファイル登録処理、ファイル更新処理およびファイル削除処理の中で、検索サーバ2100に対してトリガを通知しない形態に関する制御方式を実施例６として説明する。

上述のように、トリガ通知をしない形態を実現するためには、ファイルサーバ1100におけるファイルアクセス関連処理、ならびに検索サーバ2100におけるクローリングとインデクシング処理の内容を一部変更する必要がある。具体的には、ファイル登録処理、ファイル更新処理、ファイル削除処理、およびクローリングとインデクシング処理が該当する。

ファイル登録処理の変更内容は、次の通りである。図１１、図２３および図２４における処理ステップS107の処理を省略する。また、図２８における処理ステップS115の処理を省略する。これらにより、当該ファイル登録処理の中で、トリガ送信を行わなくなる。

次に、ファイル更新処理の変更内容は、次の通りである。図１７における処理ステップS707の処理を省略する。これにより、当該ファイル更新処理の中で、トリガ送信を行わなくなる。

次に、ファイル削除処理の変更内容は、次の通りである。図２０における処理ステップS1005の処理を省略する。これにより、当該ファイル削除処理の中で、トリガ送信を行わなくなる。

最後に、クローリングとインデクシング処理の変更内容は、次の通りである。図１４ならびに図２６における処理ステップS401の処理を省略する。これらにより、当該クローリングとインデクシング処理の中で、トリガ受信を行わなくなる。なお、図１４ならびに図２６に示す処理については、検索サーバ2100が自身の好きな契機で実行するようにして良い。

上述した実施例１は、ファイルサーバ1100における仮想ファイルシステム更新の契機に関して、ファイル登録処理、ファイル更新処理およびファイル削除処理をその契機としている形態を扱っている。本形態では、検索サーバ2100側の検索インデックス作成処理状況を考慮せずに仮想ファイルシステム更新を行う。しかし、ファイルサーバ1100にて仮想ファイルシステム更新の後でトリガ通知を検索サーバ2100側に行ったとしても、検索サーバ側の処理負荷状況によっては、当該トリガ通知を契機とした検索インデックス作成処理ができない可能性もある。したがって、ファイルサーバ1100側において必要な処理を必要な時期に効率よく実行できるようにするために、検索サーバ2100側の処理状況を考慮した上で、ファイルサーバ1100における仮想ファイルシステム更新を行うといった形態も扱えるようにする必要がある。そこで、検索サーバ2100における検索インデックス作成処理が完了したことを、検索サーバ2100からファイルサーバ1100に検索インデックス作成完了を通知する仕組みを提供することで、検索サーバ2100がファイルサーバ1100に仮想ファイルシステム更新を実施するべく通知する形態に関する制御方式を実施例７として説明する。

上述のように、検索サーバ2100からファイルサーバ1100に対して検索インデックス作成完了を通知する形態を実現するためには、ファイルサーバ1100におけるトリガ通信制御サブプログラム1127ならびに検索サーバ2100におけるトリガ通信制御サブプログラム2125の処理に、以下に述べる処理を追加することで実現する。

追加する処理の内容は、次の二つである。第一に、図１４ならびに図２６におけるクローリングとインデクシング処理の処理フローにおいて、当該処理フローの最後において、検索サーバ2100からトリガ通信制御サブプログラム2125を利用して、ファイルサーバ1100に対して、検索インデックス作成完了を通知する処理を追加する。第二に、図２４における仮想ファイルシステム更新の非同期実行処理の処理フローにおいて、当該処理フローを開始する契機として、ファイルサーバ1100のトリガ通知制御サブプログラム1127が、前述の検索インデックス作成完了通知を受信した契機を加えることである。当該通知を受信した後、ファイルサーバ1100は、図２４で示した仮想ファイルシステム更新の非同期実行処理を行うようにする。以上の処理を追加することにより、ファイルサーバ1100は、仮想ファイルシステム更新を、検索サーバ2100が検索インデックス作成完了した後、すなわち、その次の検索インデックス作成が可能になった状態になった後で行うようにできる。これにより、ファイルサーバ1100における仮想ファイルシステム更新の処理を必要以上に実行しなくても済むようになり、ファイルサーバ1100側のピーク時の負荷低減につながる。

なお、検索サーバ2100からの検索インデックス作成完了通知は、検索インデックス作成処理が実際に完了してから通知するのではなく、もうすぐ処理が完了するような状態(例えば、処理完了まであと１分など)で、通知するようにしても良い。これにより、ファイルサーバ1100の仮想ファイルシステム更新処理と、検索サーバ2100の検索インデックス作成処理をより効果的に連携させることも可能になる。

本発明により、ディジタル形式のデータを保管するファイルサーバならびに当該データの検索サービスを提供する検索サーバからなるシステムにおいて、当該ファイルサーバにおける重複排除機能を利用することで、当該検索サーバにおける検索インデックス作成処理時間を短縮可能になる。また、ファイルサーバにおいて重複排除されたデータを対象に検索サーバが検索インデックスを作成するため、検索サーバにおける検索インデックスに要するデータ容量も削減可能になる。これらにより、検索サーバにおける検索インデックスに関するデータ処理ならびにデータ保管のコスト削減の実現を見込むことができる。

１０・・・ネットワーク
１１００、１２００、１３００・・・ファイルサーバ
１１０１、１１０２、１２０１、１２０２、１３０１、１３０２・・・ファイル
２１００、２２００・・・検索サーバ
２１０１、２２０１・・・検索インデックス
３１００、３２００、３３００・・・クライアントマシン
１１１０、２１１０、３１１０・・・プロセッサ
１１２０、２１２０、３１２０・・・メモリ
１１２１、２１２１、３１２１・・・外部記憶装置I/F制御プログラム
１１２２、２１２２、３１２２・・・ネットワークI/F制御プログラム
１１２３・・・ファイルサービス制御プログラム
１１２４・・・ファイル管理制御プログラム
１１２５・・・重複排除制御サブプログラム
１１２６・・・仮想ファイルシステム管理制御サブプログラム
１１２７・・・トリガ通信制御サブプログラム
１１２８・・・仮想パス名変換制御サブプログラム
１１２９・・・重複ファイルメタデータ制御サブプログラム
１１７０・・・登録ファイルシステム
１１７１・・・格納ファイルシステム
１１７２・・・仮想ファイルシステム
２１２３・・・データ管理制御プログラム
２１２４・・・検索サービス制御プログラム
２１２５・・・トリガ通信制御サブプログラム
２１２６・・・クローリング制御サブプログラム
２１２７・・・インデクシング制御サブプログラム
２１２８・・・検索クエリ受付制御サブプログラム
２１２９・・・検索制御サブプログラム
３１２３・・・ファイル管理制御プログラム
３１２４・・・ファイルサーバアクセスクライアント制御プログラム
３１２５・・・検索サーバアクセスクライアント制御プログラム
１１３０、２１３０、３１３０・・・外部記憶装置I/F
１１４０、２１４０、３１４０・・・ネットワークI/F
１１５０、２１５０、３１５０・・・バス
１１６０、２１６０、３１６０・・・外部記憶装置
４１００・・・登録ファイル管理表
４１１０・・・登録ファイルID
４１２０・・・登録ファイルパス名
４１３０・・・登録ファイルのメタデータ
４１４０・・・対応格納ファイルID
４２００・・・格納ファイル管理表
４２１０・・・格納ファイルID
４２２０・・・格納ファイルパス名
４２３０・・・格納ファイルのメタデータ
４２４０・・・重複参照ファイル数
４２５０・・・照合情報
４２６０・・・対応登録ファイルID
４３００・・・仮想ファイルシステム管理表
４３１０・・・仮想ファイルID
４３２０・・・仮想ファイルパス名
４３３０・・・仮想ファイルのメタデータ
４３４０・・・照合情報
４３５０・・・対応格納ファイルID
４４００・・・クローリングファイル管理表
４４１０・・・ファイルパス名
４４２０・・・作成日時
４４３０・・・最終更新日時
４４４０・・・メタデータ
４５００・・・検索インデックス管理表
４５１０・・・キーワード
４５２０・・・該当位置情報
４５２１・・・該当ファイルパス名
４５２２・・・該当位置オフセット
４５２３・・・重要度情報

Claims (14)

1. コンピュータシステムのデータを格納するデータ格納装置であって、
   検索インデックスの作成に先立って格納データの重複を検出し、重複が検出された格納データを削除する重複排除制御部と、
   前記重複排除制御部による重複排除処理の実行後、かつ、ネットワーク経由で接続された検索サーバによる検索インデックス作成のためのファイル取得に先立って、ファイルシステムを作成するファイル管理制御部と
   を有するデータ格納装置。
2. 前記ファイルシステムは、前記重複排除処理の実行後の実格納ファイルシステムそのものである
   ことを特徴とする請求項１に記載のデータ格納装置。
3. 前記ファイルシステムは、前記重複排除処理の実行後のある時点の実格納ファイルシステムについて作成された仮想ファイルシステムである
   ことを特徴とする請求項１に記載のデータ格納装置。
4. 前記重複排除制御部は、前記格納データの登録処理と同期的に重複排除処理を実行し、
   前記ファイル管理制御部は、前記格納データの登録処理と同期的に前記仮想ファイルシステムを更新する
   ことを特徴とする請求項３に記載のデータ格納装置。
5. 前記重複排除制御部は、前記格納データの登録処理と同期的に重複排除処理を実行し、
   前記ファイル管理制御部は、前記格納データの登録処理と非同期に前記仮想ファイルシステムを更新する
   ことを特徴とする請求項３に記載のデータ格納装置。
6. 前記重複排除制御部は、前記格納データの登録処理と非同期的に重複排除処理を実行し、
   前記ファイル管理制御部は、前記格納データの登録処理と非同期に前記仮想ファイルシステムを更新する
   ことを特徴とする請求項３に記載のデータ格納装置。
7. 前記ファイル管理制御部は、前記仮想ファイルシステムに対応付けられる、前記重複排除処理の実行後の実格納ファイルシステムに関するメタデータを取得する機能部及び又は更新する機能部
   を更に有することを特徴とする請求項３に記載のデータ格納装置。
8. 前記機能部は、前記メタデータを取得又は更新するためのインタフェースを提供する
   ことを特徴とする請求項７に記載のデータ格納装置。
9. 前記機能部は、当該データ格納装置以外の制御装置に対して前記仮想ファイルシステムの更新完了を通知するトリガ通知機能
   を更に有することを特徴とする請求項７に記載のデータ格納装置。
10. 前記ファイル管理制御部は、当該データ格納装置以外の制御装置から前記仮想ファイルシステムの更新要求通知の受信時を契機として、前記仮想ファイルシステムを更新する
    ことを特徴とする請求項３に記載のデータ格納装置。
11. 前記重複排除制御部は、ファイルレベルの照合により、前記格納データの重複を検出する
    ことを特徴とする請求項１〜３のいずれか１項に記載のデータ格納装置。
12. 前記重複排除制御部は、ファイルを構成する固定長のブロックレベルの照合により、前記格納データの重複を検出する
    ことを特徴とする請求項１〜３のいずれか１項に記載のデータ格納装置。
13. コンピュータシステムのデータを格納するデータ格納装置に、ネットワーク経由で接続される制御装置であって、
    前記データ格納装置が、検索インデックスの作成に先立って重複する格納データを削除する重複排除制御部と、前記重複排除制御部による重複排除処理の実行後、かつ、ネットワーク経由で接続された前記制御装置による検索インデックス作成のためのファイル取得に先立って、ファイルシステムを作成するファイル管理制御部とを有するとき、
    前記データ格納装置に格納されている格納データに対する検索インデックスを作成するために、前記データ格納装置から前記ファイルシステムを取得し、記憶装置に格納するクローリング制御部と、
    取得されたファイルシステムに基づいて検索インデックスを作成するインデクシング制御部と
    を有することを特徴とする制御装置。
14. 前記クローリング制御部は、前記ファイルシステムの更新処理の完了を示すトリガ通知を前記データ格納装置から受信したことを契機として前記ファイルシステムを取得する
    ことを特徴とする請求項１３に記載の制御装置。

Images