JPWO2010100733A1 - 統合重複排除システム、データ格納装置、及びサーバ装置 - Google Patents

Abstract

最初に、重複排除効果と処理負荷が共に低い第一の重複排除処理による重複排除処理を実行する。次に、重複排除効果と処理負荷が共に高い第二の重複排除処理の実行に先立って、第一の重複排除処理による重複排除処理の処理結果に関する情報を取得する。そして、取得された情報に基づいて、第二の重複排除処理を実行するデータ対象を絞り込む。その後、絞り込まれたデータ対象に対してのみ第二の重複排除処理を実行する。これにより、高い重複排除効果を得ながら従来方式に比して処理負荷が小さい統合重複排除システムを実現する。

Description

本発明は、多量のデータを格納するストレージシステムの制御技術のうち、重複して格納されたデータを重複排除してストレージ容量の有効活用を可能にする制御技術に関する。

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

また、近年では、通信ネットワークの広帯域化、ネットワーク接続料金の定額化と低価格化により、インターネットを利用したサービスも広く利用されるようになってきている。当初は、 Webページの閲覧や、電子メールの送受信といったサービスが主流であった。しかし、最近では、インターネットを介したデータのバックアップサービスやデータ共有サービスといった大容量データをやり取りするサービスも利用されるようになってきている。データのバックアップや共有を行う際、従来ユーザは、バックアップ装置や共有サーバを個別に用意した上で、ユーザ自身で当該装置を管理する必要があった。しかし、このインターネットを介したバックアップサービスやデータ共有サービスを利用する場合、ユーザは、インターネット経由でアクセス可能なサービスに対してアクセスするだけで、自身のデータをバックアップあるいは共有できるようになる。さらに、各ユーザは、インターネットへの接続環境のみを用意すればよく、バックアップ装置や共有サーバを用意することも管理することも不要となるという利点もある。このため、今後、このような形態のサービスの利用がさらに広がるものと考えられる。

従来、複数ユーザのデータをデータセンタのストレージシステムに集約する際、当該ストレージシステムでは、重複して送られてきた全く同じデータを保管するケースがある。例えば、インターネットショップなどで購入した音楽ファイルなど、多数のユーザが同じ音楽ファイルを持っていることが考えられる。このため、ストレージシステムに、同じデータが重複して格納されることが十分考えられる。そこで、ストレージシステムにおけるストレージの利用効率を向上させるため、同じ内容のデータの重複排除を行うための技術が開示されている（特許文献１）。この方式は、ストレージシステムの格納データの重複をブロック単位で検出し、冗長な重複データを削除することによって重複排除を実現している。
米国特許第7,143,251号

しかし、この方式では、同じコンテンツに関するデータでも、フォーマットやビットレートなどの品質が異なると、重複データとして排除できないため、重複排除効果が低いという問題がある。そこで、コンテンツ単位でデータの重複を検出し、冗長な重複データを削除する方式（以下、第２の方式という。）の採用が考えられる。

この第２の方式は、特許文献１記載の技術よりも高い重複排除効果を実現することができる。しかし、その一方で、コンテンツ単位での重複を検出するための処理負荷が大きいという問題がある。具体的には、コンテンツの内容を解析し、重複を検出するためのCPU処理などの処理負荷が、ブロック単位でビット列レベルでの内容を解析し、重複を検出するための処理負荷よりも大きくなる。

上述の課題は、本来ならブロック単位による低処理負荷の重複排除処理によって重複排除可能なデータに対して、コンテンツ単位による高処理負荷の重複排除処理を適用して重複排除を行うことに起因する。この場合、コンテンツ単位での重複排除処理を実行する前の段階で、重複排除対象データに対して、事前にブロック単位での重複排除処理を行った上で、ブロック単位では重複排除しきれなかったデータのみコンテンツ単位で重複排除処理を行うようにすればよい。しかし、従来の方式では、どのデータがどのような重複排除処理を適用されたのかどうかという情報を知ることが困難である。

そこで、発明者は、データ格納装置のデータを対象として重複排除処理を実行する、重複排除効果と処理負荷が共に低い第一の重複排除部と、第一の重複排除部による重複排除処理後に重複排除処理が実行される、重複排除効果と処理負荷が共に高い第二の重複排除部であって、データ格納装置のデータを対象とした重複排除処理の実行に先立って第一の重複排除部の処理結果を取得し、少なくともデータ格納装置から既に重複排除されたデータ以外を処理対象として重複排除処理を実行する第二の重複排除部とを有する統合重複排除システムを提案する。

ここで、第一の重複排除部は、処理レベル（例えばファイルレベルやブロックレベル）のデータの内容を一意に識別するダイジェスト情報の比較によって重複排除を実行する。また、第二の重複排除部は、処理レベル（例えばコンテンツレベル）のデータからその内容を一意に識別する特徴情報を抽出し、その比較によって重複排除を実行する。

なお、本発明は、前述したシステム構成に限らず、制御装置又は制御方法として構成することもできる。また、前述したシステムを実現するコンピュータプログラム、当該プログラムを記録した記録媒体、当該プログラムを含む放送信号又は通信信号その他の種々の態様で実現することができる。

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

前述した統合重複排除システムの採用により、処理負荷が高い第二の重複排除部の重複排除処理の実行を開始する前に、処理対象とするデータ範囲を従来システムよりも絞り込むことができる。すなわち、処理負荷の高い一部の重複排除処理を処理負荷の低い重複排除処理で置換することができる。これにより、高い重複排除効果を実現しつつも、その実現に必要なシステム内の処理負荷を低減することができる。

図１はシステム構成の一例を示す図である。 図２はコンテンツサーバのハードウェア構成例を示す図である。 図３はファイルサーバのハードウェア構成例を示す図である。 図４はストレージのハードウェア構成例を示す図である。 図５はクライアントマシンのハードウェア構成例を示す図である。 図６はコンテンツレベルの重複排除処理とファイルレベルの重複排除処理を組み合わせた統合重複排除の処理イメージを例示する説明図である。 図７はコンテンツ管理表を例示する説明図である。 図８はファイル管理表を例示する図である。 図９はデータブロック管理表を例示する説明図である。 図１０はコンテンツ登録処理の一例を示すフローチャートである。 図１１はファイル登録処理の一例を示すフローチャートである。 図１２はデータブロック登録処理の一例を示すフローチャートである。 図１３は統合重複排除処理の一例を示すフローチャートである。 図１４はコンテンツ取得処理の一例を示すフローチャートである。 図１５はコンテンツ削除処理の一例を示すフローチャートである。 図１６はファイル削除処理の一例を示すフローチャートである。 図１７はデータブロック削除処理の一例を示すフローチャートである。 図１８は統合重複排除管理画面例を示す図である。 図１９はファイル登録処理を説明するフローチャートである（実施例２）。 図２０はファイルレベル重複排除処理を説明するフローチャートである（実施例２）。 図２１はコンテンツレベルの重複排除処理とブロックレベルの重複排除処理を組み合わせた統合重複排除の処理イメージを例示する図である（実施例３）。 図２２はコンテンツサーバのハードウェア構成例を示す図である（実施例３）。 図２３はストレージのハードウェア構成例を示す図である（実施例３）。 図２４はデータブロック管理表を例示する図である（実施例３）。 図２５はデータブロック登録処理の一例を示すフローチャートである（実施例３）。 図２６は統合重複排除処理の一例を説明するフローチャートである（実施例３）。 図２７はデータブロック削除処理の一例を説明するフローチャートである（実施例３）。 図２８は統合重複排除管理画面例を示す図である（実施例３）。 図２９はデータブロック管理表を例示する図である（実施例４）。 図３０はデータブロック格納アドレス管理表を例示する図である（実施例４）。 図３１はブロックレベル重複排除処理の一例を示すフローチャートである（実施例４）。

符号の説明

１０・・・インターネット
１００、２００・・・データセンタ
１１０、１２０、２１０、２２０・・・ネットワーク
１１００、１２００、１３００、１４００・・・コンテンツサーバ
２１００、２２００、２３００、２４００・・・ファイルサーバ
３１００、３２００、３３００、３４００・・・ストレージ
４１００、４２００、４３００・・・クライアントマシン
１１１０、２１１０、３１１０、４１１０・・・プロセッサ
１１２０、２１２０、３１２０、４１２０・・・メモリ
１１２１、２１２１、３１２１、４１２１・・・外部記憶装置I/F制御プログラム
１１２２、２１２２、３１２２、４１２２・・・ネットワークI/F制御プログラム
１１２３・・・コンテンツ管理制御プログラム
１１２４・・・ファイルサーバアクセスクライアントプログラム
１１２５・・・コンテンツレベル重複排除制御プログラム
１１２６・・・統合重複排除制御プログラム
１１２７・・・ファイル管理表アクセスクライアントプログラム
１１２８・・・データブロック管理表アクセスクライアントプログラム
２１２３・・・ファイル管理制御プログラム
２１２４・・・ストレージアクセスクライアントプログラム
２１２５・・・ファイルレベル重複排除制御プログラム
３１２３・・・ブロックストレージ管理制御プログラム
４１２３・・・ローカルファイルシステム管理制御プログラム
４１２４・・・コンテンツサーバアクセスクライアントプログラム
１１３０、２１３０、３１３０、４１３０・・・外部記憶装置I/F
１１４０、２１４０、３１４０、４１４０・・・ネットワークI/F
１１５０、２１５０、３１５０、４１５０・・・バス
１１６０、２１６０、３１６０、４１６０・・・外部記憶装置
５１００・・・コンテンツ管理表
５１１０・・・コンテンツID
５１２０・・・コンテンツ名
５１３０・・・コンテンツメタデータ
５１４０・・・コンテンツ重複フラグ
５１５０・・・参照コンテンツID
５１６０・・・格納ファイルID
５１７０・・・コンテンツ被参照数
５１８０・・・コンテンツ照合情報
５２００・・・ファイル管理表
５２１０・・・ファイルID
５２２０・・・ファイル名
５２３０・・・ファイルメタデータ
５２４０・・・ファイル重複フラグ
５２５０・・・参照ファイルID
５２６０・・・格納ブロックID
５２７０・・・ファイル被参照数
５２８０・・・ファイル照合情報
５３００・・・データブロック管理表
５３１０・・・ブロックID
５３２０・・・ブロック格納アドレス
５３３０・・・ブロックメタデータ
５３４０、５４３０・・・ブロック被参照数
５３５０、５４４０・・・ブロック照合情報
５４００・・・データブロック格納アドレス管理表
５４１０・・・ブロック格納アドレス
５４２０・・・ブロック重複フラグ
６１００、６２００、６３００、６４００、６５００・・・コンテンツ
６１１０、６２１０、６３１０、６４１０、６５１０・・・ファイル
７０００・・・統合重複排除管理画面
７１００・・・コンテンツレベル重複排除有効化チェックボックス
７２００・・・ファイルレベル重複排除有効化チェックボックス
７３００・・・OKボタン
７４００・・・キャンセルボタン
７５００・・・ブロックレベル重複排除有効化チェックボックス
７６００・・・コンテンツレベル重複排除実行しきい値

［実施例１］
本実施例では、ファイルサーバによるファイルレベルでの重複排除処理と、コンテンツサーバによるコンテンツレベルでの重複排除処理を組み合わせることによる統合重複排除処理について説明する。

図１は、本発明の実施例におけるシステム構成を例示する説明図である。インターネット10を介して、複数のクライアントマシン4100、4200、4300と、複数のデータセンタ100、200が接続されている。本システムでは、一つ以上のデータセンタを利用して、一台以上のコンテンツサーバ、一台以上のファイルサーバ、および一台以上のストレージからなるデータ格納サービスをクライアントマシンに提供するものとする。各データセンタでは、以下に説明する構成と同じ構成を持つ。データセンタ100では、複数のコンテンツサーバ1100、1200がインターネット10と接続されている。コンテンツサーバ1100、1200は、内部のネットワーク110を介して、複数のファイルサーバ2100、2200と接続されている。ファイルサーバ2100、2200は、内部のネットワーク120を介して、複数のストレージ3100、3200と接続されている。

なお、図１では、コンテンツサーバ、ファイルサーバおよびストレージの三種類の構成要素を別装置として記載しているが、この限りではない。可能であれば、三種類のうち二つ、あるいは三つ全てを一つの装置として実現する構成でもよい。また、インターネット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において、ファイルサーバ2100、2200に対してファイルアクセス要求を発行する機能を提供するためのプログラムであるファイルサーバアクセスクライアントプログラム1124と、当該コンテンツサーバ1100において、コンテンツレベルの重複排除機能を提供するためのプログラムであるコンテンツレベル重複排除制御プログラム1125と、複数レベルの重複排除機能を統合的に実行する機能を提供するためのプログラムである統合重複排除制御プログラム1126と、かかるコンテンツ管理制御プログラム1123が利用するコンテンツ管理表5100が格納される。

統合重複排除制御プログラム1126は、その内部に、ファイル管理表アクセスクライアントプログラム1127を持つ。ファイル管理表アクセスクライアントプログラム1127は、当該コンテンツサーバ1100においてコンテンツレベルの重複排除を実行する前に、対象コンテンツに対応するファイルが、別途後述するファイルサーバにて、別途後述するファイルレベルの重複排除処理がなされたかどうかを確認する処理を行う。コンテンツ管理表5100については後述する。なお、他のコンテンツサーバもここで説明する構成と同じであるため、説明を割愛する。

図３は、ファイルサーバ2100のハードウェア構成を例示する説明図である。ファイルサーバ2100は、プログラムを実行するプロセッサ2110と、プログラムならびにデータを一時的に格納するメモリ2120と、外部記憶装置2160にアクセスするための外部記憶装置I/F2130と、ネットワークで接続された他装置にアクセスするためのネットワークI/F2140と、それらを接続するバス2150から構成されている。メモリ2120には、外部記憶装置I/F2130を制御するプログラムである外部記憶装置I/F制御プログラム2121と、ネットワークI/F2140を制御するプログラムであるネットワークI/F制御プログラム2122と、当該ファイルサーバ2100において扱うファイルデータを管理するためのファイル管理制御プログラム2123と、当該ファイルサーバ2100において、ストレージ3100、3200に対してデータブロックアクセス要求を発行する機能を提供するためのプログラムであるストレージアクセスクライアントプログラム2124と、当該ファイルサーバ2100において、ファイルレベルの重複排除機能を提供するためのプログラムであるファイルレベル重複排除制御プログラム2125と、かかるファイル管理制御プログラム2123が利用するファイル管理表5200が格納される。なお、他のファイルサーバもここで説明する構成と同じであるため、説明を割愛する。

図４は、ストレージ3100のハードウェア構成を例示する説明図である。ストレージ3100は、プログラムを実行するプロセッサ3110と、プログラムならびにデータを一時的に格納するメモリ3120と、外部記憶装置3160にアクセスするための外部記憶装置I/F3130と、ネットワークで接続された他装置にアクセスするためのネットワークI/F3140と、それらを接続するバス3150から構成されている。メモリ3120には、外部記憶装置I/F3130を制御するプログラムである外部記憶装置I/F制御プログラム3121と、ネットワークI/F3140を制御するプログラムであるネットワークI/F制御プログラム3122と、当該ストレージ3100において扱うデータブロックを管理するためのブロックストレージ管理制御プログラム3123と、かかるブロックストレージ管理制御プログラム3123が利用するデータブロック管理表5300が格納される。なお、他のストレージもここで説明する構成と同じであるため、説明を割愛する。

図５は、クライアントマシン4100のハードウェア構成を例示する説明図である。クライアントマシン4100は、プログラムを実行するプロセッサ4110と、プログラムならびにデータを一時的に格納するメモリ4120と、外部記憶装置4160にアクセスするための外部記憶装置I/F4130と、ネットワークで接続された他装置にアクセスするためのネットワークI/F4140と、それらを接続するバス4150から構成されている。メモリ4120には、外部記憶装置I/F4130を制御するプログラムである外部記憶装置I/F制御プログラム4121と、ネットワークI/F4140を制御するプログラムであるネットワークI/F制御プログラム4122と、当該クライアントマシン4100におけるデータを管理するためのファイルシステムを制御するプログラムであるローカルファイルシステム制御プログラム4123と、当該クライアントマシン4100において、コンテンツサーバ1100、1200に対してコンテンツアクセス要求を発行する機能を提供するためのプログラムであるコンテンツサーバアクセスクライアントプログラム4124が格納される。なお、他のクライアントマシンもここで説明する構成と同じであるため、説明を割愛する。

図６は、ファイルレベルの重複排除とコンテンツレベルの重複排除を組み合わせた統合重複排除を適用した場合の重複排除イメージを例示する説明図である。例として、以下に説明する5つの音楽コンテンツ6100、6200、6300、6400、6500をサンプルとして考える。5つの音楽コンテンツは、全て同じ楽曲（曲名”AAA”）をもとに作成されているとする。音楽コンテンツ6100は、再生時のビットレートが128Kbpsで、当該コンテンツ長が当該コンテンツのオリジナルバージョンの先頭から末尾までが一致するフルバージョンで、フォーマット形式がmp3形式であるとする。音楽コンテンツ6200は、音楽コンテンツ6100と同一のものとする。音楽コンテンツ6300は、音楽コンテンツ6100と比較して、ビットレートとフォーマット形式は同じであるが、当該コンテンツ長が当該コンテンツのオリジナルバージョンの先頭から途中までが一致するバージョンであるとする。これは、例えば、音楽コンテンツ6100が3分の再生時間であるコンテンツの場合、音楽コンテンツ6300が、当該音楽コンテンツ6100の先頭1分部分と一致する1分の再生時間を持つコンテンツであるケースが該当する。音楽コンテンツ6400は、音楽コンテンツ6100と比較して、当該コンテンツ長とフォーマット形式は同じであるが、ビットレートが64Kbpsと異なるものであるとする。音楽コンテンツ6500は、音楽コンテンツ6100と比較して、ビットレートと当該コンテンツ長は同じであるが、フォーマット形式がaac形式と異なるものであるとする。音楽コンテンツ6100、6200、6300、6400、6500は、それぞれのデジタルデータを格納するためのファイル6110、6120、6130、6140、6150とそれぞれ1対1で対応づけられる。これらのファイル6110、6120、6130、6140、6150が実際のストレージに格納されることになる。

上記のようなサンプル扱う場合、ファイルレベルでの重複排除処理のみを行うケース、コンテンツレベルでの重複排除処理のみを行うケース、およびコンテンツレベルの重複排除処理とファイルレベルの重複排除処理を組み合わせて行うケースについて、それぞれ説明する。

第一に、ファイルレベルでの重複排除処理のみを行うケースについて説明する。このケースでは、ファイルサーバにおけるファイルレベル重複排除処理によって、音楽コンテンツ6100に対応したファイル6110と、音楽コンテンツ6200に対応したファイル6210の重複を検出し、どちらか一方を削除することができる。ファイルレベルによる重複検出方式は、多々あると考えられるが、対象ファイルのデータからSHA-1のような一方向関数により生成されたハッシュ値を比較することにより、重複を検出することが一般的であると考えられる。この方法は、入力となるデータが同じであれば生成されるハッシュ値が同じになること、ならびに入力となるデータ異なるものであれば生成されるハッシュ値が同じにならないこと、という一方向関数の性質を利用している。

このように、ファイルレベルでの重複排除処理では、ファイルのデータ内容が全く同一のものに関して重複を検出し、冗長ファイルを削除することが可能である。しかし、対象ファイルが音楽ファイルや動画ファイルといったマルチメディアデータの場合、対象ファイルのフォーマットやビットレートなどの品質が異なるファイルは、全く別物と認識されることになり、その重複を検出し、冗長ファイルを削除することは困難である。

第二に、コンテンツレベルでの重複排除処理のみを行うケースについて説明する。このケースでは、コンテンツサーバにおけるコンテンツレベル重複排除処理によって、音楽コンテンツに対応したファイルから音の波形情報を解析した上で、音の特徴点に関する情報を抽出する。抽出した特徴点の情報を照合することにより、対象音楽コンテンツ同士が同じ内容のコンテンツであるかどうかを判断することで、重複を検出し、削除対象をどちらにするか選択の上、削除対象コンテンツを復元するために必要な情報（コンテンツに関するメタデータが該当。例えば、ビットレートやフォーマット、再生時間など）のみを保存した後で、データそのものを削除することができる。削除対象コンテンツを復元したい場合は、重複していると検知されたコンテンツから、削除対象コンテンツが削除される前に保存された情報をもとに、対象コンテンツの変換処理を行う。この変換処理によって、コンテンツレベルでの重複排除によって削除されたコンテンツを復元することが可能になる。このコンテンツレベルでの重複排除処理では、照合のために識別可能な特徴点を抽出可能なコンテンツの種類であれば、どんな種類のコンテンツにも適用することが可能である。例えば、音の特徴点を抽出可能な音楽コンテンツ、画像の特徴点を抽出可能な画像コンテンツ、静止画像を複数個重ね合わせたものに音の情報を追加したものを動画と考えれば、動画コンテンツなどもあてはまる。

このように、コンテンツレベルでの重複排除処理では、ファイルのデータ内容が異なっていても、コンテンツレベルで内容が同じものに関して重複を検出し、冗長ファイルを削除することが可能である。また、ファイルレベルでの重複排除処理によって重複排除可能なコンテンツに対し、コンテンツレベルでの重複排除処理でも同じように重複を検出し、冗長ファイルを削除することが可能である。すなわち、ファイルレベルでの重複排除処理より、高い重複排除効果を見込むことが可能になる。しかし、コンテンツレベルでの重複排除処理は、重複検出に利用する特徴点の抽出処理に必要となる処理ステップ数が多くなる。具体的には、対象コンテンツのデータを波形情報に変換するデコード処理、波形情報から特徴点を抽出する抽出処理、抽出した情報を照合する照合処理などに多くの処理ステップ数が必要になる。ここで、単純なファイルレベルの重複排除処理と比較して、波形情報から特徴点を抽出する処理は、一方向関数によるハッシュ値の生成と対応し、抽出した情報を照合する照合処理は、ハッシュ値の照合処理と対応すると考えることができる。しかし、対象コンテンツのデータを波形情報に変換するデコード処理に相当する部分がファイルレベルでの重複排除処理には存在しない。このため、この処理のデコード部分が、コンテンツレベルでの重複排除処理に伴う処理ステップ増加に寄与しているということも可能である。

第三に、コンテンツレベルの重複排除処理とファイルレベルの重複排除処理を組み合わせて行うケースについて説明する。このケースでは、図6に示す通り、次の4つのステップにて処理を行う。まず、第一に、ファイルレベルでの重複排除処理による照合処理を行う。ここで行う照合処理は、重複排除対象候補ファイル全てに対して行う。この例では、ファイル6110とファイル6210がファイルレベルで重複すると判断される。第二に、ファイルレベルでの重複排除処理により、重複ファイルを削除する。この例では、ファイル6210を削除対象として選択したものとして、ファイル6210を削除する。第三に、コンテンツレベルでの重複排除処理による照合処理を行う。ここで行う照合処理は、前述のファイルレベルでの重複排除処理によって、重複していると判断されたファイルに対応するコンテンツは含めないようにする。この例では、コンテンツ6200以外のコンテンツ6100、6300、6400、6500の4つが対象となる。この例では、全てのコンテンツがコンテンツレベルで重複すると判断される。最後、第四に、コンテンツレベルでの重複排除処理により、重複コンテンツに対応するファイルを削除する。この例では、他のコンテンツを復元するために必要な高品質なデータを持つコンテンツ6100に対応するファイル6110のみを残し、それ以外を削除対象として選択する。ここで、削除の前に、削除対象コンテンツを復元するために必要な情報をそれぞれのコンテンツについて保存しておく。以上の処理ステップにより、コンテンツレベルとファイルレベルを組み合わせた重複排除処理を実現する。

このように、二つを組み合わせた重複排除処理では、コンテンツレベルでの重複排除処理を行うケースと同等の重複排除効果を達成できる上に、コンテンツレベルでの重複排除を行うために必要な処理ステップ数を削減することが可能になる。具体的には、二つを組み合わせた重複排除処理では、コンテンツ6200に対するコンテンツレベルでの重複排除処理による照合をスキップできる。これにより、ファイルレベルでの重複検出と冗長ファイルの削除が可能であるものに対しては、先行してファイルレベルでの重複排除処理を行うようにして、残ったコンテンツに対してのみコンテンツレベルでの重複検出と冗長コンテンツの削除を行うことが可能になる。

以降、コンテンツレベルでの重複排除処理とファイルレベルでの重複排除処理を組み合わせた統合重複排除処理を実現するために管理が必要な情報と、具体的な処理内容について説明する。

図７は、コンテンツサーバ1100上で管理するコンテンツ管理表5100の構成を例示する図である。コンテンツ管理表5100では、当該コンテンツサーバ1100がクライアントマシンから格納要求を受けたコンテンツに関する情報を管理する。具体的に、コンテンツ管理表5100は、コンテンツID5110と、コンテンツ名5120と、コンテンツメタデータ5130と、コンテンツ重複フラグ5140と、参照コンテンツID5150と、格納ファイルID5160と、コンテンツ被参照数5170と、コンテンツ照合情報5180という構成要素からなる。

ここで、コンテンツID5110とは、当該コンテンツサーバに格納要求がなされたコンテンツに対して、システムが付与する一意な識別子である。コンテンツ名5120とは、コンテンツ格納時において、ユーザが格納対象コンテンツに付与していた名前である。コンテンツメタデータ5130とは、格納対象コンテンツが持つ当該コンテンツそのものに関する情報である。例えば、当該コンテンツの作成日時、所有者、アクセス制御リスト、コンテンツのサイズなどの情報が該当する。コンテンツ重複フラグ5140とは、当該コンテンツが、コンテンツレベルでの重複排除処理によって、別のコンテンツとの重複が検出され、当該コンテンツが削除されたか否かを示すフラグである。Yesであれば、当該コンテンツの実体は格納されずに別コンテンツを参照していることを示す。Noであれば、当該コンテンツの実体が格納されていることを示す。なお、重複排除処理による判定がなされていない場合は、当該フラグはNull値となる。参照コンテンツID5150とは、当該コンテンツがコンテンツレベルでの重複排除処理により、自コンテンツの実体が格納されずに別コンテンツを参照している場合において、その参照先コンテンツを識別するための情報である。もし、当該コンテンツがコンテンツレベルでの重複排除処理による重複検証がなされていない場合は、本エントリにはNull値を格納する。格納ファイルID5160とは、当該コンテンツに対応する格納ファイルを識別するために利用する識別子である。この格納ファイルID5160は、対象ファイル格納時にファイルサーバによって付与される。詳細は後述する。コンテンツ被参照数5170とは、当該コンテンツの実体が参照されている数を示す。具体的には、自コンテンツによる参照と、コンテンツレベルでの重複排除処理によってコンテンツレベルで重複と判断されたコンテンツから参照されている数の合計を示している。コンテンツ照合情報5180とは、当該コンテンツより抽出されるコンテンツレベルの特徴点に関する情報を示す。この情報は、コンテンツレベルでの重複排除処理において、重複検出処理の際に利用する。対象コンテンツが音楽である場合は、音の特徴点に関する情報を格納し、対象コンテンツが画像である場合は、画像の特徴点に関する情報を格納する。

図８は、ファイルサーバ2100上で管理するファイル管理表5200の構成を例示する図である。ファイル管理表5200では、当該ファイルサーバ2100がコンテンツサーバから格納要求を受けたファイルに関する情報を管理する。具体的に、ファイル管理表5200は、ファイルID5210と、ファイル名5220と、ファイルメタデータ5230と、ファイル重複フラグ5240と、参照ファイルID5250と、格納ブロックID5260と、ファイル被参照数5270と、ファイル照合情報5280という構成要素からなる。

ここで、ファイルID5210とは、当該ファイルサーバに格納要求がなされたファイルに対して、システムが付与する一意な識別子である。ファイル名5220とは、ファイル格納時において、要求元が格納対象ファイルに付与していた名前である。ファイルメタデータ5230とは、格納対象ファイルが持つ当該ファイルそのものに関する情報である。例えば、当該ファイルの作成日時、所有者、アクセス制御リスト、ファイルのサイズなどの情報が該当する。ファイル重複フラグ5240とは、当該ファイルが、ファイルレベルでの重複排除処理によって、別のファイルとの重複が検出され、当該ファイルが削除されたか否かを示すフラグである。Yesであれば、当該ファイルの実体は格納されずに別ファイルを参照していることを示す。Noであれば、当該ファイルの実体が格納されていることを示す。もし、当該ファイルがファイルレベルでの重複排除処理による重複検証がなされていない場合は、本エントリにはNull値を格納する。参照ファイルID5250とは、当該ファイルがファイルレベルでの重複排除処理により、自ファイルの実体が格納されずに別ファイルを参照している場合において、その参照先ファイルを識別するための情報である。もし、当該ファイルがファイルレベルでの重複排除処理によって重複排除されていない場合は、本エントリにはNull値を格納する。格納ブロックID5260とは、当該ファイルに対応するデータブロックを識別するために利用する識別子である。データブロックとは、可変長あるいは固定長のデータ格納領域のことである。一つのファイルに対して、複数個のデータブロックが存在する場合がある。このため、格納ブロックID5260欄には、複数個のブロックIDが登録される場合がある。この格納ブロックID5260は、対象データブロック格納時にストレージによってそれぞれ付与される。詳細は後述する。ファイル被参照数5270とは、当該ファイルの実体が参照されている数を示す。具体的には、自ファイルによる参照と、ファイルレベルでの重複排除処理によってファイルレベルで重複と判断されたファイルから参照されている数の合計を示している。ファイル照合情報5280とは、当該ファイルより一方向関数を利用して生成されるハッシュ値に関する情報を示す。この情報は、ファイルレベルでの重複排除処理において、重複検出処理の際に利用する。

図９は、ストレージ3100上で管理するデータブロック管理表5300の構成を例示する図である。データブロック管理表5300では、当該ストレージ3100がファイルサーバから格納要求を受けたデータブロックに関する情報を管理する。具体的に、データブロック管理表5300は、ブロックID5310と、ブロック格納アドレス5320と、ブロックメタデータ5330という構成要素からなる。

ここで、ブロックID5310とは、当該ストレージに格納要求がなされたデータブロックに対して、システムが付与する一意な識別子である。ブロック格納アドレス5320とは、データブロック格納時において、記録媒体上の格納場所を特定するためのアドレスである。ブロックメタデータ5330とは、格納対象データブロックが持つ当該データブロックそのものに関する情報である。例えば、当該データブロックの作成日時、最終のアクセス日時などの情報が該当する。

ここまでに、本発明によって提供するシステムの構成と管理情報の構成について説明した。以降では、本発明によって実現する処理方式について説明する。ここでは、コンテンツ登録処理（図１０）、ファイル登録処理（図１１）、データブロック格納処理（図１２）、統合重複排除処理（図１３）、コンテンツ取得処理（図１４）、コンテンツ削除処理（図１５）、ファイル削除処理（図１６）およびデータブロック削除処理（図１７）について説明する。

図１０では、コンテンツサーバ1100におけるコンテンツ登録処理における一連の処理の流れを示す。はじめに、コンテンツサーバ1100では、コンテンツ管理表5100の中から未使用エントリを探し、そのエントリを確保する(ステップS101)。次に、登録対象コンテンツに対応するファイルの登録要求をファイルサーバ2100へ発行する(ステップS102)。ファイル登録処理の詳細は後述する。次に、処理ステップS101で確保したコンテンツ管理表5100のエントリに、登録対象コンテンツの情報を登録する(ステップS103)。この段階で、当該登録対象コンテンツにコンテンツIDが付与されることになる。最後に、コンテンツサーバ1100において、登録対象コンテンツを対象とした統合重複排除処理を統合重複排除制御プログラム1126に対して要求する(処理ステップS104)。統合重複排除処理の詳細は後述する。

図１１では、ファイルサーバ2100におけるファイル登録処理における一連の処理の流れを示す。はじめに、ファイルサーバ2100では、ファイル管理表5200の中から未使用エントリを探し、そのエントリを確保する(ステップS201)。次に、登録対象ファイルの内容より、ファイル照合情報を生成する(ステップS202)。ここでは、対象ファイルのハッシュ値を生成する。次に、生成したファイル照合情報と同じものを持つファイルが既に当該ファイル管理表5200に登録されているか否かを調べる(ステップS203)。もし、登録されている場合は、合致したファイルのファイルIDをファイル管理表5200から取得する(ステップS204)。次に、ファイル管理表5200における、当該合致ファイルのエントリにおけるファイル被参照数の値を加算する(ステップS205)。次に、処理ステップS201で確保したファイル管理表5200のエントリに、登録対象ファイルの情報を登録する(ステップS206)。この段階で、当該登録対象ファイルにファイルIDが付与されることになる。最後に、登録ファイルに付与されたファイルIDを要求元に応答する(ステップS207)。

もし、処理ステップS203において、登録されていない場合は、登録対象ファイルに対応するデータブロックの登録要求をストレージ3100へ発行する(ステップS208)。データブロック登録処理の詳細は後述する。処理ステップS208は、登録対象ファイルに対応する全てのデータブロックを登録するまで繰り返す(ステップS209)。全て登録が終わった後、処理ステップS201で確保したファイル管理表5200のエントリに、登録対象ファイルの情報を登録する(ステップS210)。この段階で、処理ステップS206と同様に、当該登録対象ファイルにファイルIDが付与されることになる。最後に、登録ファイルに付与されたファイルIDを要求元に応答する(ステップS207)。

図１２では、ストレージ3100におけるデータブロック登録処理における一連の処理の流れを示す。はじめに、ストレージ3100では、データブロック管理表5300の中から未使用エントリを探し、そのエントリを確保する(ステップS301)。次に、ストレージ3100では、一つのデータブロックを格納可能な記録媒体上のデータ格納領域を確保する(ステップS302)。次に、処理ステップS302で確保したデータ格納領域に、格納対象データを格納する(ステップS303)。次に、処理ステップS301で確保したデータブロック管理表5300のエントリに、登録対象データブロックの情報を登録する(ステップS304)。最後に、登録データブロックに付与されたブロックIDを要求元に応答する(ステップS305)。

図１３では、コンテンツサーバ1100における統合重複排除処理における一連の処理の流れを示す。はじめに、コンテンツサーバ1100では、格納されているコンテンツの中から重複排除対象コンテンツを選択する(ステップS401)。次に、処理ステップS401で選択した対象コンテンツの情報をコンテンツ管理表5100から取得する(ステップS402)。ここで、対象コンテンツに対応したファイルのファイルIDを特定する。次に、処理ステップS402で取得した情報をもとに特定したファイルの情報をファイル管理表5200から取得する(ステップS403)。この処理では、ファイル管理表アクセスクライアントプログラム1127を利用し、ファイルサーバ2100に対して要求を発行し、その結果を受け取ることでファイル管理表5200に登録されている当該ファイルに関する情報を取得する。ここで、対象コンテンツに対応するファイルが、ファイルレベルで重複排除されているか否かといった情報を取得することができる。次に、処理ステップS403で取得した情報をもとに、対象コンテンツに対してファイルレベル重複排除処理が試行されたかどうかを判定する(ステップS404)。ここでは、対象コンテンツに対応するファイルのファイル重複フラグ5240の値が、Nullかそれ以外かで以降の処理が分かれる。もし、Nullであれば、当該ファイルに対してファイルレベルでの重複排除処理が試行されていないと判断し、対象コンテンツに対するコンテンツレベル重複排除処理をペンディングして終了する(ステップS414)。ペンディングとなったコンテンツについては、別の時期に再度統合重複排除処理を行う。もし、Null以外であれば、対象コンテンツに対してファイルレベル重複排除処理で重複排除されたかどうかを判定する(ステップS405)。ここでは、対象コンテンツに対応するファイルのファイル重複フラグ5240の値が、YesかNoかで以降の処理が分かれる。もし、Yesであれば、当該ファイルに対してファイルレベルでの重複排除が実行済、かつコンテンツレベルでの重複排除が不要と判断し、対象コンテンツに対するコンテンツレベルでの重複排除処理を実施せずに終了する(ステップS415)。もし、Noであれば、コンテンツサーバ1100は、対象コンテンツのコンテンツ照合情報を生成する(ステップS406)。次に、生成したコンテンツ照合情報と同じものを持つコンテンツが既に当該コンテンツ管理表5100に登録されているか否かを調べる(ステップS407)。もし、登録されていない場合は、コンテンツレベルで重複するコンテンツは存在しないと判断し、対象コンテンツに対するコンテンツレベルでの重複排除処理を終了する(ステップS416)。もし、登録されている場合は、合致コンテンツのコンテンツIDをコンテンツ管理表5100から取得する(ステップS408)。次に、当該重複コンテンツの削除をすべきか否かの判断を行う(ステップS409)。ここでは、コンテンツレベルでの重複排除によるストレージ容量削減効果と、コンテンツレベルでの重複排除に必要な処理リソース量ならびに重複排除処理を行うコンテンツサーバ1100や、関係するファイルサーバ2100、ストレージ3100、および各種ネットワークなどの負荷状況をもとに判断を行う。例えば、システム内のストレージ容量にまだ十分な空きがある一方で各種サーバやネットワークの負荷が高い状態であれば、かかる重複コンテンツの重複排除を見送る判断を行うことが考えられる。逆に、システム内のストレージ容量に十分な空きがない一方で各種サーバやネットワークの負荷が低い状態であれば、かかる重複コンテンツの重複排除を実行する判断を行うことが考えられる。もし、処理ステップS409にて削除すべきでないと判断した場合は、対象コンテンツに対するコンテンツレベルでの重複排除処理をペンディングして終了する(ステップS417)。この場合、対象コンテンツのコンテンツ重複フラグ5140の値はNullのままとなる。もし、処理ステップS409にて削除すべきと判断した場合は、合致した二つのコンテンツの一方を削除コンテンツ、もう一方を残存コンテンツとして決定する。ここでは、重複排除後も、重複排除によって削除したコンテンツを復元可能なコンテンツを残すよう選択するものとする。すなわち、より高品質でより情報量を持った方のコンテンツを残存コンテンツとして選択する。次に、コンテンツ管理表5100における当該残存コンテンツのコンテンツ被参照数を加算する(ステップS411)。ここでは、削除コンテンツのコンテンツ被参照数の値を残存コンテンツのコンテンツ被参照数に加算する。次に、コンテンツ管理表5100を更新する(ステップS412)。具体的には、コンテンツ管理表5100における残存コンテンツのエントリと、削除コンテンツのエントリの内容を更新する。残存コンテンツのエントリでは、コンテンツ重複フラグをNoと更新する。削除コンテンツのエントリでは、コンテンツ重複フラグをYesと更新し、参照コンテンツIDを残存コンテンツのコンテンツIDに更新し、格納ファイルIDならびにコンテンツ被参照数をNullに更新する。最後に、削除対象コンテンツに対応するファイルを削除する(ステップS413)。ファイル削除処理については後述する。

図１４では、クライアントマシンからのコンテンツ取得処理における一連の処理の流れを示す。はじめに、コンテンツサーバ1100は、クライアントマシン4100からのコンテンツ取得要求を受信する(ステップS501)。次に、取得要求された対象コンテンツの情報をコンテンツ管理表5100から取得する(ステップS502)。ここで、取得対象コンテンツに対応するファイルを特定することができる。次に、対象コンテンツに対応するファイル取得をファイルサーバ2100に要求する。次に、ファイルサーバ2100では、取得要求された対象ファイルの情報をファイル管理表5200から取得する(ステップS504)。ここで、取得対象ファイルに対応するデータブロックを特定することができる。次に、対象ファイルに対応するデータブロック取得ストレージ3100に要求する。ここでは、複数のデータブロックを一括して取得要求してもよいし、逐次的に取得要求してもよい。次に、ストレージ3100では、取得要求された対象データブロックの情報をデータブロック管理表5300から取得する(ステップS506)。ここで、取得対象データブロックが実際に格納されている場所を特定することができる。次に、対象データブロックの内容を取得し、結果を要求元へ応答する(ステップS507)。次に、ファイルサーバ2100では、取得したデータブロックと、取得要求された対象ファイルのメタデータ（ファイル管理表5200の対象ファイルのエントリに登録されている情報）を要求元に応答する(ステップS508)。次に、コンテンツサーバ1100では、取得対象コンテンツへの変換処理すなわちTranscoding処理が必要か否かを判断する(ステップS509)。ここでは、取得対象コンテンツがコンテンツレベルでの重複排除がなされている場合、対象コンテンツを復元するためのコンテンツ変換処理を行うか否かの判断をする。具体的に、取得したファイルに対応するコンテンツのメタデータと、取得対象コンテンツのメタデータを比較し、内容が異なる場合は、コンテンツ変換処理が必要と判断する。もし、処理ステップS509にてTranscoding処理が必要と判断した場合は、対象コンテンツへのTranscoding処理を行う(ステップS510)。ここでは、対象コンテンツに対応するファイルに対し、取得対象コンテンツのメタデータと整合がとれた状態に復元するためのコンテンツ変換処理を行う。例えば、音楽コンテンツの場合は、必要に応じてビットレートの変換、フォーマット形式変換、再生時間の変更などを行う。最後に、コンテンツサーバ1100は、取得対象コンテンツと当該コンテンツのメタデータ（コンテンツ管理表5100の対象コンテンツのエントリに登録されている情報）を要求元へ応答する。もし、処理ステップS509にてTranscoding処理が不要と判断した場合は、上述の処理ステップS510をスキップし、処理ステップS511の処理を行う。

図１５では、コンテンツサーバ1100におけるコンテンツ削除処理における一連の処理の流れを示す。はじめに、コンテンツサーバ1100は、クライアントマシン4100からのコンテンツ削除要求を受信する(ステップS601)。次に、削除要求された対象コンテンツの情報をコンテンツ管理表5100から取得する(ステップS602)。次に、削除対象コンテンツは、コンテンツレベルの重複排除によって、別コンテンツを参照しているかどうかを確認する(ステップS603)。これは、処理ステップS602で取得した情報を利用して確認する。もし、処理ステップS603にて別コンテンツを参照していると判断した場合は、当該参照コンテンツのコンテンツ被参照数を減算する(ステップS604)。次に、当該参照コンテンツのコンテンツ被参照数の値が0になったかどうかを確認する(ステップS605)。もし、0になっていた場合は、当該参照コンテンツに対応するファイルの削除をファイルサーバ2100に要求する(ステップS606)。ファイル削除処理の詳細については後述する。ファイル削除の後、コンテンツ管理表5100での当該参照コンテンツのエントリを解放する(ステップS607)。最後に、コンテンツ管理表5100での削除対象コンテンツのエントリを解放(ステップS608)して終了する。もし、処理ステップS605にて、当該参照コンテンツのコンテンツ被参照数の値が0になっていなかった場合は、利用ファイルの削除をせず、コンテンツ管理表5100での削除対象コンテンツのエントリを解放(ステップS609)して終了する。もし、処理ステップS603にて、別コンテンツを参照していないと判断した場合は、削除対象コンテンツのコンテンツ被参照数を減算する(ステップS610)。次に、削除対象コンテンツのコンテンツ被参照数の値が0になったかどうかを確認する(ステップS611)。もし、0になっていた場合は、削除対象コンテンツに対応するファイルの削除をファイルサーバ2100に要求する(ステップS612)。ファイル削除処理の詳細については後述する。ファイル削除の後、コンテンツ管理表5100での削除対象コンテンツのエントリを解放(ステップS613)して終了する。もし、処理ステップS611にて、削除対象コンテンツのコンテンツ被参照数の値が0になっていなかった場合は、利用ファイルの削除をせず、そのまま終了する。

図１６では、ファイルサーバ2100におけるファイル削除処理における一連の処理の流れを示す。はじめに、ファイルサーバ2100は、コンテンツサーバ1100からのファイル削除要求を受信し、削除要求された対象ファイルの情報をファイル管理表5200から取得する(ステップS701)。次に、削除対象ファイルは、ファイルレベルの重複排除によって、別ファイルを参照しているかどうかを確認する(ステップS702)。これは、処理ステップS701で取得した情報を利用して確認する。もし、処理ステップS702にて別ファイルを参照していると判断した場合は、当該参照ファイルのファイル被参照数を減算する(ステップS703)。次に、当該参照ファイルのファイル被参照数の値が0になったかどうかを確認する(ステップS704)。もし、0になっていた場合は、当該参照ファイルに対応するデータブロックの削除をストレージ3100に要求する(ステップS705)。データブロック削除処理の詳細については後述する。処理ステップS705は、対象ファイルに対応する全てのデータブロックを削除するまで繰り返す(ステップS706)。データブロック削除の後、ファイル管理表5200での当該参照ファイルのエントリを解放する(ステップS707)。最後に、ファイル管理表5200での削除対象ファイルのエントリを解放(ステップS708)して終了する。もし、処理ステップS704にて、当該参照ファイルのファイル被参照数の値が0になっていなかった場合は、利用データブロックの削除をせず、ファイル管理表5200での削除対象ファイルのエントリを解放(ステップS709)して終了する。もし、処理ステップS702にて、別ファイルを参照していないと判断した場合は、削除対象ファイルのファイル被参照数を減算する(ステップS710)。次に、削除対象ファイルのファイル被参照数の値が0になったかどうかを確認する(ステップS711)。もし、0になっていた場合は、削除対象ファイルに対応するデータブロックの削除をストレージ3100に要求する(ステップS712)。データブロック削除処理の詳細については後述する。処理ステップS712は、対象ファイルに対応する全てのデータブロックを削除するまで繰り返す(ステップS713)。データブロック削除の後、ファイル管理表5200での削除対象ファイルのエントリを解放(ステップS714)して終了する。もし、処理ステップS711にて、削除対象ファイルのファイル被参照数の値が0になっていなかった場合は、利用データブロックの削除をせず、そのまま終了する。

図１７では、ストレージ3100におけるデータブロック削除処理における一連の処理の流れを示す。はじめに、ストレージ3100は、ファイルサーバ2100からのデータブロック削除要求を受信し、削除要求された対象データブロックの情報をデータブロック管理表5300から取得する(ステップS801)。次に、取得した情報をもとに削除対象データブロックのデータ格納領域を特定し、当該領域を解放する(ステップS802)。次に、データブロック管理表5300での削除対象データブロックのエントリを解放して終了する(ステップS803)。

図１８では、コンテンツサーバ1100における統合重複排除制御プログラム1126によって提供される統合重複排除管理画面7000のイメージ図を示す。統合重複排除管理画面7000は、Webブラウザなどを利用してアクセスできるようにした上で、コンテンツレベルでの重複排除処理の有効化と無効化、ならびにファイルレベルでの重複排除処理の有効化と無効化を設定できるようにする。コンテンツレベルでの重複排除を有効化する場合は、コンテンツレベル重複排除有効化のチェックボックス7100にチェックをつけて、OKボタン7300を押下することで有効化される。同様に、ファイルレベルでの重複排除を有効化する場合は、ファイルレベル重複排除有効化のチェックボックス7200を利用する。無効化する場合は、チェックボックスのチェックを外した上で、OKボタン7300を押下する。入力内容をキャンセルしたい場合は、キャンセルボタン7400を押下する。この統合重複排除管理画面7000により、コンテンツレベルとファイルレベルを組み合わせた統合重複排除、コンテンツレベルでの重複排除、およびファイルレベルでの重複排除を設定できるようになる。どちらか一方のみ有効化した場合、前述した処理フローにおいて、無効化されているレベルでの重複排除処理は省略される。

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

上述した実施例１は、ファイル登録処理と同期して、ファイルサーバ2100におけるファイルレベルでの重複排除処理を行う形態を扱っている。しかし、ファイルサーバ2100は、ファイル登録処理とは非同期にファイルレベルでの重複排除処理を行うようにしてもよい。そこで、以降では、ファイルサーバ2100におけるファイルレベルでの重複排除処理をファイル登録処理とは非同期に実行する場合における制御方式を実施例２として説明する。

上述のように、ファイルレベルでの重複排除処理を非同期に実行するためには、ファイル登録処理の一部内容を変更する必要がある。この変更内容と、ファイル登録処理とは非同期に実行するファイルレベル重複排除処理の内容を、図１９ならびに図２０によって説明する。

図１９では、ファイルサーバ2100におけるファイル登録処理の変更内容を示す。本処理フローは、図１１にて説明したファイル登録処理と比べて、ファイルレベルでの重複排除処理を行う部分を省略した処理フローとなっている。具体的には、以下で説明する。はじめに、ファイル登録要求を受信したファイルサーバ2100では、ファイル管理表5200の中から未使用エントリを探し、そのエントリを確保する(ステップS201)。次に、登録対象ファイルに対応するデータブロックの登録要求をストレージ3100へ発行する(ステップS208)。処理ステップS208は、登録対象ファイルに対応する全てのデータブロックを登録するまで繰り返す(ステップS209)。全て登録が終わった後、処理ステップS201で確保したファイル管理表5200のエントリに、登録対象ファイルの情報を登録する(ステップS210)。この段階で、当該登録対象ファイルにファイルIDが付与されることになる。最後に、登録ファイルに付与されたファイルIDを要求元に応答する(ステップS207)。以上が、ファイル登録処理となる。

図２０では、ファイルサーバ2100におけるファイルレベルでの重複排除処理における一連の処理の流れを示す。この処理は、ファイルサーバ2100の中で、任意の契機に実行するようにしてよい。例えば、一定間隔で実行してもよいし、何かのイベントを契機に実行するようにしてもよい。後者の例では、コンテンツサーバ1100上のファイル管理表アクセスクライアントプログラム1127からのファイル管理表5200へのアクセス要求時に実行するようにしてもよい。この処理では、はじめに、ファイルサーバ2100では、格納されているファイルの中から重複排除対象ファイルを選択する(ステップS901)。次に、対象ファイルの内容より、ファイル照合情報を生成する(ステップS902)。ここでは、対象ファイルのハッシュ値を生成する。次に、生成したファイル照合情報と同じものを持つファイルが既に当該ファイル管理表5200に登録されているか否かを調べる(ステップS903)。もし、登録されている場合は、合致したファイルのファイルIDをファイル管理表5200から取得する(ステップS904)。次に、合致した二つのファイルの一方を削除ファイル、もう一方を残存ファイルとして決定する(ステップS905)。ここでは、二つのうちどちらを削除するようにしてもよい。次に、ファイル管理表5200における当該残存ファイルのファイル被参照数を加算する(ステップS906)。ここでは、削除ファイルのファイル被参照数の値を残存ファイルのファイル被参照数に加算する。次に、ファイル管理表5200を更新する(ステップS907)。具体的には、ファイル管理表5200における残存ファイルのエントリと、削除ファイルのエントリの内容を更新する。残存ファイルのエントリでは、ファイル重複フラグをNoと更新する。削除ファイルのエントリでは、ファイル重複フラグをYesと更新し、参照ファイルIDを残存ファイルのファイルIDに更新し、格納ブロックIDならびにファイル被参照数をNullに更新する。最後に、削除対象ファイルに対応するデータブロックの削除をストレージ3100に要求する(ステップS908)。処理ステップS908は、対象ファイルに対応する全てのデータブロックを削除するまで繰り返し(ステップS909)、終了する。もし、処理ステップS903にて、同じ照合情報を持つファイルが登録されていない場合は、ファイル管理表5200における対象ファイルのエントリを更新(ステップS910)し、終了する。具体的には、対象ファイルのエントリのファイル重複フラグをNoと更新する。

以上の処理を行うことで、非同期にファイルレベルの重複排除処理を実行することが可能になる。
［実施例３］

上述した実施例1は、コンテンツレベルでの重複排除処理と、ファイルレベルでの重複排除処理を行う形態を扱っている。しかし、ストレージ3100において、ブロックレベルでの重複排除処理も行うようにすることで、ブロックレベルならびにコンテンツレベルでの統合重複排除を行うようにしてもよい。そこで、以降では、ブロックレベルでの重複排除処理も行う場合における統合重複排除の制御方式を実施例３として説明する。

上述のように、ブロックレベルでの重複排除処理も行う場合における統合重複排除を実行するためには、コンテンツサーバの構成、ストレージの構成、データブロック管理表、データブロック登録処理、統合重複排除処理、データブロック削除処理および統合重複排除管理画面の一部内容を変更する必要がある。以降では、ブロックレベルとコンテンツレベルの重複排除処理を組み合わせた重複排除イメージを図２１で説明し、これらの変更内容を、図２２、図２３、図２４、図２５、図２６、図２７及び図２８によって説明する。

図２１は、ブロックレベルの重複排除とコンテンツレベルの重複排除を組み合わせた統合重複排除を適用した場合の重複排除イメージを例示する説明図である。例として用いるサンプルは、図６で説明したものと同じである。図２１では、ファイル6110に対応するデータブロックとして、ブロックb1、ブロックb2およびブロックb3がある。ファイル6110と同じ内容を持つファイル6210に対応するデータブロックとして、ブロックb1、ブロックb2およびブロックb3がある。ファイル6110の一部と同じ内容を持つファイル6310に対応するデータブロックとして、ブロックb1と、新たな別データを持つブロックb4がある。残りも同様に、対応するデータブロックとして、ファイル6410はブロックb5とブロックb6、ファイル6510はブロックb7とブロックb8とブロックb9がある。ファイルあたりのデータブロックの数は、対象ファイルのサイズに依存する。

ブロックレベルでの重複排除は、ファイルレベルでの重複排除と同様に、対象データブロックのハッシュ値を生成し、その値を照合することで重複を検出し、冗長な重複データブロックを削除することによって実現する。

ここで、コンテンツレベルの重複排除処理と、ファイルレベルの重複排除処理のかわりにブロックレベルの重複排除処理を組み合わせて行うケースについて説明する。このケースでは、図２１に示す通り、次の4つのステップにて処理を行う。まず、第一に、ブロックレベルでの重複排除処理による照合処理を行う。ここで行う照合処理は、重複排除対象候補データブロック全てに対して行う。この例では、ブロックb1とブロックb2とブロックb3がブロックレベルで重複すると判断される。第二に、ブロックレベルでの重複排除処理により、重複データブロックを削除する。この例では、ファイル6110に対応するデータブロックを残すよう選択したものとして、残りの重複データブロックを削除する。第三に、コンテンツレベルでの重複排除処理による照合処理を行う。ここで行う照合処理は、前述のブロックレベルでの重複排除処理によって、重複していると判断されたデータブロックを一定数以上持つコンテンツは含めないようにする。この例では、コンテンツレベルでの重複排除処理による照合対象として、対応する全データブロックの50％以上のデータブロックがブロックレベルでの重複排除によって削除されているコンテンツを含めないことと考える。この場合、コンテンツ6200、6300以外のコンテンツ6100、6400、6500の3つが対象となる。この例では、全てのコンテンツがコンテンツレベルで重複すると判断される。最後、第四に、コンテンツレベルでの重複排除処理により、重複コンテンツに対応するファイルならびにデータブロックを削除する。この例では、他のコンテンツを復元するために必要な高品質なデータを持つコンテンツ6100に対応するファイル6110ならびにそれに対応するデータブロックとしてブロックb1、ブロックb2、ブロックb3のみを残し、それ以外を削除対象として選択する。ここで、削除の前に、削除対象コンテンツを復元するために必要な情報をそれぞれのコンテンツについて保存しておく。以上の処理ステップにより、コンテンツレベルとブロックレベルを組み合わせた重複排除処理を実現する。

このように、二つを組み合わせた重複排除処理では、実施例１と同様に、コンテンツレベルでの重複排除処理を行うケースと同じような重複排除効果を達成できる上に、コンテンツレベルでの重複排除を行うために必要な処理ステップ数を削減することが可能になる。具体的には、二つを組み合わせた重複排除処理では、コンテンツ6200ならびにコンテンツ6300に対するコンテンツレベルでの重複排除処理による照合をスキップできる。これにより、ブロックレベルでの重複検出と冗長データブロックの削除が可能であるものに対しては、先行してブロックレベルでの重複排除処理を行うようにして、残ったコンテンツに対してのみコンテンツレベルでの重複検出と冗長コンテンツの削除を行うことが可能になる。さらに、ブロックレベルでの重複排除処理を利用することで、ファイルレベルでの重複排除処理では重複排除ができなかった部分的にデータが重複するケースについて、コンテンツレベルでの重複排除処理を行うために必要な処理ステップ数を削減することも可能になると考えられる。

図２２では、図２で示したコンテンツサーバ1100における構成の変更内容について示す。図２２では、図２と比べて、統合重複排除制御プログラム1126上にデータブロック管理表アクセスクライアントプログラム1128を新たに追加している。データブロック管理表アクセスクライアントプログラム1128は、当該コンテンツサーバ1100においてコンテンツレベルの重複排除を実行する前に、対象コンテンツに対応するデータブロックが、ストレージにてブロックレベルの重複排除処理がなされたかどうかを確認する処理を行う。ここで、対象コンテンツに対応するデータブロックを特定するためには、一度ファイル管理表アクセスクライアントプログラム1127を利用してファイルサーバのファイル管理表5200にアクセスし、対象コンテンツに対応するファイルを特定する。その後で、データブロック管理表アクセスクライアントプログラム1128を利用してストレージのデータブロック管理表5300にアクセスし、対象ファイルに対応するデータブロックを特定する。

図２３では、図４で示したストレージ3100における構成の変更内容について示す。図２３では、図４と比べて、メモリ3120上にブロックレベル重複排除制御プログラム3124を新たに追加している。ブロックレベル重複排除制御プログラム3124は、ブロックレベルの重複排除機能を提供するためのプログラムである。

図２４では、図９で示したデータブロック管理表5300における構成の変更内容について示す。図２４では、図９と比べて、ブロック被参照数5340、ブロック照合情報5350の二つの属性を新たに追加している。ブロック被参照数5340とは、当該データブロックの実体が参照されている数を示す。ブロック照合情報5350とは、当該データブロックより一方向関数を利用して生成されるハッシュ値に関する情報を示す。この情報は、ブロックレベルでの重複排除処理において、重複検出処理の際に利用する。

図２５では、図１２で示したストレージ3100におけるデータブロック登録処理の変更内容について示す。図２５では、図１２と比べて、処理ステップS306、S307、S308、S309を新たに追加している。以下、順を追って処理フローを説明する。

はじめに、ストレージ3100では、データブロック登録要求を受信後、対象データブロックの内容より、ブロック照合情報を生成する(ステップS306)。ここでは、対象データブロックに格納されるデータのハッシュ値を生成する。次に、生成したブロック照合情報と同じものを持つデータブロックが既に当該データブロック管理表5300に登録されているのか否かを調べる(ステップS307)。もし、登録されている場合は、合致したデータブロックのブロックIDをデータブロック管理表5300から取得する(ステップS308)。次に、データブロック管理表5300における当該合致データブロックのエントリにて、ブロック被参照数を加算する(ステップS309)。最後に、当該合致データブロックに付与されたブロックIDを要求元に応答する(ステップS305)。もし、処理ステップS307にて、同じブロック照合情報を持つデータブロックが登録されていない場合は、図１２で説明した処理ステップS301、S302、S303、S304およびS305の処理を行い、対象データブロックの登録を行う。以上の処理により、ブロック登録処理において、同期的にブロックレベルでの重複排除処理を行うことができるようになる。

図２６では、図１３で示したコンテンツサーバ1100における統合重複排除処理の変更内容について示す。図２６では、図１３と比べて、処理ステップS418、S421を新たに追加し、既存フローの一部を処理ステップS419、S420として更新している。以下、変更部分を中心に説明する。

まず、処理ステップS403の後に、コンテンツサーバ1100は、重複排除処理対象ファイルを格納するデータブロックの情報をデータブロック管理表5300から取得するよう、ストレージ3100に要求する処理(ステップS418)を追加している。この取得要求は、データブロック管理表アクセスクライアントプログラム1128を利用して実行する。ここで、対象コンテンツに対応するデータブロックが、ブロックレベルで重複排除されているか否かといった情報を取得することができる。情報取得後、コンテンツサーバ1100は、処理ステップS418で取得した情報をもとに、対象コンテンツに対してブロックレベルで重複排除処理が試行されたかどうかを判定する(ステップS419)。ここでは、対象コンテンツに対応するデータブロックのブロック被参照数5340の値がNullかそれ以外かで以降の処理が分かれる。もし、Nullであれば、当該データブロックに対してブロックレベルでの重複排除処理が試行されていないと判断し、対象コンテンツに対するコンテンツレベル重複排除処理をペンディングして終了する(ステップS414)。ただし、ブロックレベルでの重複排除処理をブロック登録時に同期的に実行するケースでは、このような状態にはならない。もし、処理ステップS419にて、Null以外であれば、対象コンテンツに対してブロックレベル重複排除処理で重複排除されたかどうかを判定する(ステップS420)。ここでは、対象コンテンツに対応するデータブロックのブロック被参照数5340の値が、2以上か否かで以降の処理が分かれる。もし、2以上すなわち重複排除されていると判断されれば、当該データブロックに対してブロックレベルでの重複排除が実行済と判断し、対象コンテンツに対して規定の割合以上のサイズでブロックレベルでの重複排除がされているかどうかを確認する(ステップS421)。ここで利用する割合の値は、後で説明する統合重複排除管理画面7000にて設定するコンテンツレベル重複排除実行しきい値7600を利用するものとする。具体的には、コンテンツレベル重複排除実行しきい値7600として50%という値が指定されている場合で、コンテンツのサイズが10MB、データブロック長が1MBとした場合、当該コンテンツは10個のデータブロックが存在することになる。この状態で、当該コンテンツに対応するデータブロックのうち、5つ以上がブロックレベルで重複排除されていた場合、処理ステップS421の判断がYesになる。もし、処理ステップS421にてYesと判断された場合は、処理ステップS415に進み終了する。もし、処理ステップS421にてNoと判断された場合は、処理ステップS406に進み、以降、図１３と同じ処理を行う。ここで、Noと判断されるということは、ブロックレベルでの重複排除効果が十分ではないため、さらにコンテンツレベルでの重複排除処理の試行対象となったことを意味する。もし、処理ステップS420にて、ブロック被参照数5340の値が2以上ではない、すなわち重複排除されていないと判断されれば、処理ステップS406に進み、以降、図１３と同じ処理を行う。

図２７では、図１７で示したストレージ3100におけるデータブロック削除処理の変更内容について示す。図２７では、図１７と比べて、処理ステップS804、S805を新たに追加している。以下、変更部分を中心に説明する。

処理ステップS801の後で、ストレージ3100は、データブロック管理表5300での削除対象データブロックのエントリにおけるブロック被参照数5340の値を減算する(ステップS804)。次に、削除対象データブロックのブロック被参照数5340の値が0か否かを確認する(ステップS805)。もし0であれば、処理ステップS802に進み、以降、図１７と同じ処理を行う。もし0でなければ、そのまま処理を終了する。

図２８では、図１８で示したコンテンツサーバ1100における統合重複排除管理画面7000の変更内容について示す。図２８では、図１８と比べて、次の二つを新たに追加している。

第一には、ブロックレベル重複排除有効化のチェックボックス7500である。これは、ブロックレベルでの重複排除処理を有効化ならびに無効化を設定する時に利用する。設定の仕方は、他の二つのチェックボックスと同じである。第二には、コンテンツレベル重複排除実行しきい値7600である。これは、ブロックレベルでの重複排除処理とコンテンツレベルでの重複排除処理の両方を組み合わせて統合重複排除を行う場合、コンテンツレベルでの重複排除処理を試行するか否かを判断するためのしきい値である。任意のコンテンツに対して、当該コンテンツに対応する全データブロックの中で、このコンテンツレベル重複排除実行しきい値7600以上の割合でブロックレベルでの重複排除がなされている場合は、当該コンテンツに対するコンテンツレベルでの重複排除処理をスキップする。この値を設定する場合、統合重複排除管理画面7000の該当欄に値を入力の上、OKボタン7300を押下することで有効化される。この統合重複排除管理画面7000により、コンテンツレベルとブロックレベルを組み合わせた統合重複排除、コンテンツレベルとファイルレベルとブロックレベルを組み合わせた統合重複排除といった設定ができるようになる。
［実施例４］

上述した実施例３は、データブロック登録処理と同期して、ストレージ3100におけるブロックレベルでの重複排除処理を行う形態を扱っている。しかし、ストレージ3100は、データブロック登録処理とは非同期にブロックレベルでの重複排除処理を行うようにしてもよい。そこで、以降では、ストレージ3100におけるブロックレベルでの重複排除処理をデータブロック登録処理とは非同期に実行する場合における制御方式を実施例４として説明する。

上述のように、ブロックレベルでの重複排除処理を非同期に実行するためには、データブロック管理表の構成、データブロック登録処理、統合重複排除処理の一部内容を変更する必要がある。この変更内容と、データブロック登録処理とは非同期に実行するブロックレベル重複排除処理の内容を、図２９、図３０および図３１によって説明する。

はじめに、データブロック管理表5300の構成の変更内容について説明する。ここでは、データブロック管理表5300の他に、データブロック格納アドレス管理表5400を新たに作成する。

図２９は、データブロック管理表5300の構成を例示する図である。構成そのものは、図９で示した構成と同じである。ただし、ブロック格納アドレス5320の欄に登録されるアドレス値が、他のエントリが持つ値と重複した値を登録できるようにする。

図３０は、データブロック格納アドレス管理表5400の構成を例示する図である。構成要素は、ブロック格納アドレス5410、ブロック重複フラグ5420、ブロック被参照数5430、ブロック照合情報5440である。ブロック格納アドレス5320とは、データブロック格納時において、記録媒体上の格納場所を特定するためのアドレスである。ブロック重複フラグ5420とは、当該ブロック格納アドレスが示すブロック格納アドレス領域に格納されるデータブロックが、ブロックレベルでの重複排除処理によって、別のデータブロックとの重複が検出され、当該ブロック格納アドレス領域が他から共有されているか否かを示すフラグである。Yesであれば、当該ブロック格納アドレス領域は他からも参照されていることを示す。Noであれば、当該ブロック格納アドレス領域は他から参照されていないことを示す。もし、当該ブロック格納アドレス領域がブロックレベルでの重複排除処理による重複検証がなされていない場合、あるいは当該ブロック格納アドレス領域にデータが格納されていない場合は、本エントリにはNull値を格納する。

ブロック被参照数5430とは、当該ブロック格納アドレス領域が参照されている数を示す。具体的には、自データブロックによる参照と、ブロックレベルでの重複排除処理によってブロックレベルで重複と判断された他データブロックから参照されている数の合計を示している。ブロック照合情報5440とは、当該ブロック格納アドレス領域に格納されているデータより一方向関数を利用して生成されるハッシュ値に関する情報を示す。この情報は、ブロックレベルでの重複排除処理において、重複検出処理の際に利用する。

コンテンツサーバ1100からデータブロック管理表アクセスクライアントプログラム1128を介して情報取得要求があった場合、従来のデータブロック管理表5300の内容だけでなく、データブロック格納アドレス管理表5400の内容も一緒に提供するようにする。

次に、データブロック登録処理の変更内容について説明する。この実施例のケースでは、図１２で示した処理フローそのままでデータブロック登録処理を行うようにする。ただし、処理ステップS304にて、データブロック管理表5300への登録を行う際、データブロック格納アドレス管理表5400への登録も行うようにする。

次に、ブロックレベル重複排除処理について説明する。

図３１では、ストレージ3100におけるブロックレベルでの重複排除処理における一連の処理の流れを示す。この処理は、ストレージ3100の中で、任意の契機に実行するようにしてよい。例えば、一定間隔で実行してもよいし、何かのイベントを契機に実行するようにしてもよい。後者の例では、コンテンツサーバ1100上のデータブロック管理表アクセスクライアントプログラム1128からのデータブロック管理表5300へのアクセス要求時に実行するようにしてもよい。この処理では、はじめに、ストレージ3100では、格納されているデータブロックの中から重複排除対象データブロックを選択する(ステップS1001)。次に、対象データブロックの内容より、ブロック照合情報を生成する(ステップS1002)。ここでは、対象データブロックのブロック格納アドレス領域に格納されているデータのハッシュ値を生成する。次に、生成したブロック照合情報と同じものを持つデータブロックが既に当該データブロック格納アドレス管理表5400に登録されているか否かを調べる(ステップS1003)。もし、登録されている場合は、合致したデータブロックのブロック格納アドレスをデータブロック格納アドレス管理表5400から取得する(ステップS1004)。次に、合致した二つのデータブロックの一方を削除ブロック、もう一方を残存ブロックとして決定する(ステップS1005)。ここでは、二つのうちどちらを削除するようにしてもよい。次に、データブロック格納アドレス管理表5400における当該残存ブロックに相当するエントリのブロック被参照数を加算する(ステップS1006)。ここでは、削除ブロックのブロック被参照数の値を残存ブロックのブロック被参照数に加算する。次に、データブロック管理表5300とデータブロック格納アドレス管理表5400を更新する(ステップS1007)。具体的には、二つの管理表における残存ブロックのエントリと、削除ブロックのエントリの内容を更新する。データブロック管理表5300について、削除ブロックのエントリでは、ブロック格納アドレスを残存ブロックのものに更新する。データブロック格納アドレス管理表5400について、残存ブロックのエントリでは、ブロック重複フラグをYesと更新する。削除ブロックのエントリでは、ブロック重複フラグをNullと更新し、ブロック被参照数ならびにブロック照合情報をNullに更新する。最後に、削除対象データブロックに対応するデータブロック格納アドレス領域に登録されているデータを削除し、領域を解放する(ステップS1008)。もし、処理ステップS1003にて、同じ照合情報を持つデータブロックが登録されていない場合は、データブロック格納アドレス管理表5400における対象データブロックのエントリを更新(ステップS1009)し、終了する。具体的には、対象データブロックのエントリのブロック重複フラグをNoと更新する。

最後に、統合重複排除処理の変更内容について説明する。本実施例におけるコンテンツサーバ1100における統合重複排除処理の内容は、図２６で説明した処理フローとほぼ同じである。ただし、次に説明する3つの点が異なるため、以下で説明する。

第一に、処理ステップS418において、コンテンツサーバ1100が、データブロック管理表アクセスクライアントプログラム1128を利用して、ストレージ3100のデータブロック管理表5300にアクセスして情報を取得する場合、同じ機能を利用してストレージ3100のデータブロック格納アドレス管理表5400にもアクセスして必要な情報を取得できるようにする。

第二に、処理ステップS419において、対象コンテンツに対してブロックレベルで重複排除処理が試行されたかどうかを判定する際、ここでは、データブロック格納アドレス管理表5400に格納されているブロック重複フラグ5420の値を利用する。この値がNullである場合は、当該データブロックに対してブロックレベルでの重複排除処理が試行されていないと判断し、もしNull以外の場合は、試行されていると判断する。

第三に、処理ステップS420において、対象コンテンツに対してブロックレベルで重複排除されたかどうかを判定する際、ここでは、データブロック格納アドレス管理表5400に格納されているブロック重複フラグ5420の値を利用する。この値がYesである場合は、当該データブロックに対しいてブロックレベルでの重複排除処理によって重複排除がなされたと判断し、もしNoである場合は、重複排除がなされていないと判断する。

以上の処理を行うことで、非同期にブロックレベルの重複排除処理を実行することが可能になる。
［実施例５］

上述した実施例は、コンテンツレベルでの重複排除処理とファイルレベルでの重複排除処理の組合せ、あるいはコンテンツレベルでの重複排除処理とブロックレベルでの重複排除処理の組合せを行う形態を扱っている。しかし、三つのレベルの重複排除処理の組合せを行う形態を扱うようにしてよい。また、組合せ時における各レベルにおける重複排除処理の実行契機も任意の組合せによって実現するようにしてよい。例えば、三つのレベルの重複排除処理を、コンテンツ登録処理と全て同期的に実行することにしてもよい。また、三つのレベルのうち、一つあるいは二つをコンテンツ登録処理と同期的に実行し、残りを非同期的に実行することにしてもよい。また、三つのレベル全てを、コンテンツ登録処理と非同期的に実行することにしてもよい。これらの組合せを実現する時の処理フローは、ここまでで説明してきた処理フローの任意の組合せによって実現することが可能である。

本発明により、ディジタル形式のデータを保管するストレージシステムならびにコンピューティングシステムにおいて、かかる保管データの重複排除によって、保管に要するストレージ利用容量を削減することが可能になる。ストレージ利用容量削減により、同じストレージ利用容量を使う場合におけるより多量のデータ保管や、データ保管コスト低減の実現を見込むことができる。

Claims (9)

1. データ格納装置のデータを対象として重複排除処理を実行する、重複排除効果と処理負荷が共に低い第一の重複排除部と、
   前記第一の重複排除部による重複排除処理後に重複排除処理が実行される、重複排除効果と処理負荷が共に高い第二の重複排除部であって、前記データ格納装置のデータを対象とした重複排除処理の実行に先立って前記第一の重複排除部の処理結果を取得し、少なくとも前記データ格納装置から既に重複排除されたデータ以外を処理対象として重複排除処理を実行する第二の重複排除部と
   を有する統合重複排除システム。
2. 前記第二の重複排除部は、前記データ格納装置におけるデータの重複を、データ内容の重複を検出するコンテンツレベルでの重複排除処理である
   請求の範囲１に記載の統合重複排除システム。
3. 前記第一の重複排除部は、前記データ格納装置に対するデータの格納時に、格納対象のデータと１対１に論理的に対応付けられる格納単位で内容の重複を検出するファイルレベルでの重複排除処理である
   請求の範囲１又は２に記載の統合重複排除システム。
4. 前記第一の重複排除部は、前記データ格納装置に対するデータの格納時に、格納対象のデータを固定長又は可変長の単位に分割されたそれぞれの断片の単位で内容の重複を検出するブロックレベルでの重複排除処理である
   請求の範囲１又は２に記載の統合重複排除システム。
5. 前記第一の重複排除部による重複排除処理と、前記第二の重複排除部による重複排除処理とは、データの格納時に同期的に実行される
   請求の範囲１又は２に記載の統合重複排除システム。
6. 前記第一の重複排除部による重複排除処理と、前記第二の重複排除部による重複排除処理とは、データの格納処理と非同期的に実行される
   請求の範囲１又は２に記載の統合重複排除システム。
7. 格納データを対象として重複排除処理を実行する、重複排除効果と処理負荷が共に低い第一の重複排除部と、
   前記第一の重複排除部による重複排除処理後に重複排除処理が実行される、重複排除効果と処理負荷が共に高い第二の重複排除部であって、前記格納データを対象とした重複排除処理の実行に先立って前記第一の重複排除部の処理結果を取得し、少なくとも前記データ格納装置から既に重複排除されたデータ以外を処理対象として重複排除処理を実行する第二の重複排除部と
   を有するデータ格納装置。
8. データ格納装置のデータを対象として重複排除処理を実行する、重複排除効果と処理負荷が共に低い第一の重複排除部と、
   前記第一の重複排除部による重複排除処理後に重複排除処理が実行される、重複排除効果と処理負荷が共に高い第二の重複排除部であって、前記データ格納装置のデータを対象とした重複排除処理の実行に先立って前記第一の重複排除部の処理結果を取得し、少なくとも前記データ格納装置から既に重複排除されたデータ以外を処理対象として重複排除処理を実行する第二の重複排除部と
   を有するサーバ装置。
9. 格納データを対象として重複排除処理を実行する、重複排除効果と処理負荷が共に低い第一の重複排除部と、当該第一の重複排除部による重複排除処理の結果を提供する情報提供部とを有するデータ格納装置との通信を通じ、前記情報提供部から前記第一の重複排除部による重複排除処理の結果を取得するインターフェースと、
   前記第一の重複排除部による重複排除処理後に重複排除処理を実行する、重複排除効果と処理負荷が共に高い第二の重複排除部であって、前記インターフェースを通じて前記第一の重複排除部の処理結果を取得し、少なくとも前記データ格納装置から既に重複排除されたデータ以外を処理対象として重複排除処理を実行する第二の重複排除部と
   を有するサーバ装置。

Images