JP2013088920A - 計算機システム及びデータ管理方法 - Google Patents

Abstract

【課題】分散メモリキャッシュに配置されるキー・バリュー型データにおいて、複数のアプリケーションが同一のバリューを共有できるように管理する。
【解決手段】データを格納する複数の第１の計算機と、複数の第１の計算機の各々に格納されるデータを管理する第２の計算機とを備える計算機システムであって、計算機システムは、複数の第１の計算機が提供する記憶領域を統合して生成されたストレージを備え、ストレージは、第１のアクセス情報と第１の検索キーとを含む第１の分割データ、及び、第１のファイルのバリューを格納し、第２の計算機は、アプリケーションから第１のファイルの分割データの配置要求を受け付けた場合に、第２の検索キーを生成し、第１のファイルのバリューが共有バリューであるか否かを判定し、共有バリューであると判定された場合、第２の検索キーと第１のアクセス情報とを含む第２の分割データをストレージに格納する。
【選択図】図１

Description

本発明は、データを分散して配置するストレージを備える計算機システム及びデータ管理方法に関する。

近年、計算機システムにおいてアプリケーションプログラムが処理すべきデータ量は爆発的に増えてきている。計算機システムが扱うデータ量の増大に伴う処理時間の増加によって、バッチジョブなどの処理が所定の時間内に終わらないといった問題が生じてきている。このため、大量のデータを高速に処理することが要求されており、これを実現するために、例えば、多数のサーバに大量のデータを並列処理させることによって処理の高速化を図る要求が増大してきている。

従来のアプリケーションプログラムでは、一般に、データをファイル形式またはデータベース（ＤＢ）の表形式で扱っている。アプリケーションプログラム毎に、ファイル及び表の使い方が異なっている。特に、メインフレームが使われるような基幹業務処理では、プログラミング言語としてＣＯＢＯＬを用いて、アプリケーションプログラムが作成される。前述したようなアプリケーションプログラムでは、ファイル及び表をレコードの集合としてデータが扱われる。

レコードは、アプリケーションプログラムが処理するデータの基本単位であり、アプリケーションプログラムは、レコード単位でデータの入出力を行う。１件のレコードには、一連の関連する情報が格納されており、当該情報の各項目はフィールドと呼ばれる。金融機関で扱われるような情報を例にすると、１件の取引情報がレコードに、口座番号、店番号、及び商品コードといった各項目がフィールドに相当する。

アプリケーションプログラムは、ファイルからレコードを１件ずつ順次読み出して所定の処理を実行する。従来のアプリケーションプログラムが前述したような形式のデータを並列して処理する場合、データをレコード単位で分割して処理を実行させる方法が考えられる。

データを分割する理由としては、アプリケーションプログラムはレコードを一件ずつ読み出して処理を実行するため、単にデータの複製を生成し、複数のサーバが当該データを処理するだけでは、各サーバの処理量は変わらないためである。

レコード単位のデータの分割という観点では、データベースをキーによってレコード単位で分割する分散データベース技術がある（例えば、特許文献１参照）。特許文献１には、キーレンジによってデータベースに格納されるデータをレコード毎に分割し、処理の並列化を実現する技術が記載されている。

また、データの並列処理に関する技術として、各サーバが共有するディスク上で稼動する非共有データベースシステムにおいて負荷の平準化を行う技術がある（例えば、特許文献２参照）。特許文献２には、複数のデータベースサーバから構成され、データ領域を細分化し、データベースサーバへの各データ領域の割り当てを変えることによってデータベースサーバ間でのデータの受渡しを可能とし、データ処理の並列性を高める技術が記載されている。

一方、大量のデータを、多数のサーバを使って高速に処理するための技術として、例えば、非特許文献１に示されるような分散メモリキャッシュ技術が提案されている。分散メモリキャッシュ技術は、複数のサーバのメモリを統合して、大量のデータを格納するメモリ空間を構成する技術である。データの分割配置による処理の並列化と、メモリにデータを保持することによる入出力の高速化とを実現することを目的としている。

分散メモリ技術では、大量のデータを複数のサーバに分散させるために、キー・バリュー型データ形式が採用される。キー・バリュー型データは、データの識別子であるキーと、データの本体であるバリュー（値）とを対応づけたデータ構造であり、［キー、バリュー］の組み合わせで管理される。一つのキー・バリュー型データをエントリとも記載する。

分散メモリ技術では、キーの範囲（キーレンジ）に応じてデータを複数のサーバに分割配置し、分割配置されたデータを各サーバ上で稼動するアプリケーションが並列に処理することによって処理を高速化する。

特開平５−３３４１６５号公報 特開２００７−２５７３５号公報

"ＧｅｍＦｉｒｅ Ｅｎｔｅｒｐｒｉｓｅ" Ｔｅｃｈｎｉｃａｌ Ｗｈｉｔｅ Ｐａｐｅｒ ２００７ＧｅｍＳｔｏｎｅ Ｓｙｓｔｅｍｓ Ｉｎｃ．

データソースが表形式又はレコードから構成されるファイルのような構造のデータの場合、アプリケーションプログラム毎に、キーとするフィールドが異なる。例えば、店番号に着目したアプリケーションプログラムは店番号をキーとするキー・バリュー型データを扱うのに対して、口座番号に着目したアプリケーションプログラムは口座番号をキーとするキー・バリュー型データを扱う。

したがって、同一レコードでも、キー・バリュー型データとしては、アプリケーション毎に異なるデータとなる。このとき、あるアプリケーションプログラムからバリューが更新された場合に、他のアプリケーションが扱うキー・バリュー型データのバリューに当該更新が反映されない場合がある。バリューの更新を反映するためには、更新されたエントリに対応するデータソースへバリューの更新を反映し、さらに、当該レコードを参照するアプリケーションプログラムに対して、キーとする別のフィールドを指定して、エントリを生成し直す必要がある。

また、二つのアプリケーションプログラムが同一レコードのそれぞれ異なるレコードのフィールドを更新したとき、データソースへの書き戻し時に、一つのアプリケーションプログラムによって更新されたフィールドが上書きされてしまう場合がある。

本発明の代表的な一例を示せば以下の通りである。すなわち、第１のプロセッサ、前記第１のプロセッサに接続される第１のメモリ及び前記第１のプロセッサに接続される第１のネットワークインタフェースを有し、データを格納する複数の第１の計算機と、第２のプロセッサ、前記第２のプロセッサに接続される第２のメモリ及び前記第２のプロセッサに接続される第２のネットワークインタフェースを有し、前記複数の第１の計算機の各々に格納されるデータを管理する第２の計算機と、を備える計算機システムであって、前記計算機システムは、前記複数の第１の計算機が提供する記憶領域を統合して生成されたストレージを備え、前記第２の計算機は、複数のレコードを含むファイルを分割して、検索キーと、前記レコードの内容を示すバリューとを対応づけた分割データを前記ストレージに分散して格納するローダ処理部、及び、前記ファイルを格納するファイル格納部を有し、前記ストレージを構成する前記記憶領域の情報を含むストレージ構成情報、及び、前記ストレージに格納される前記分割データと前記ファイルとの対応関係を管理する対応情報を格納し、前記複数の第１の計算機の各々は、ファイルデータ単位のデータを処理するアプリケーション、及び、前記ストレージを管理するストレージ管理部を有し、前記分割データを管理する分割データ管理情報を格納し、前記ストレージは、第１のファイルのバリューにアクセスするための第１のアクセス情報と、第１の検索キーとを含む第１の分割データ、及び、前記第１のファイルのバリューを格納し、前記第２の計算機は、前記アプリケーションから、第２の検索キーの情報を含む第１のファイルの前記分割データの配置要求を受け付けた場合に、前記アプリケーションから指定された前記第２の検索キーを生成し、前記第１のファイルのバリューが複数の前記アプリケーションによって共有される共有バリューであるか否かを判定し、前記第１のファイルのバリューが共有バリューであると判定された場合、前記第２の検索キーと前記第１のアクセス情報とを含む第２の分割データを前記ストレージに格納することを特徴とする。

本発明によれば、複数のアプリケーションによって生成されるエントリにおいて、同一のバリューを共有できるようにエントリを構成することによって、ファイルからエントリを生成し直す必要がない。また、同一のバリューを共有できるため、一つのエントリの更新が他のアプリケーションが参照する他のエントリにも反映できる。

本発明の第１の実施形態における計算機システムの構成例を示すブロック図である。 本発明の第１の実施形態におけるデータソースの構成例を示す説明図である。 本発明の第１の実施形態における分散メモリキャッシュ構成情報の構成例を示す説明図である。 本発明の第１の実施形態におけるデータソース情報の構成例を示す説明図である。 本発明の第１の実施形態における対応情報の構成例を示す説明図である。 本発明の第１の実施形態におけるレコード定義情報の構成例を示す説明図である。 本発明の第１の実施形態におけるＵＡＰのソースプログラムの一例を示す説明図である。 本発明の第１の実施形態におけるエントリのデータ構成の一例を示す説明図である。 本発明の第１の実施形態における共有バリュー管理情報の構成例を示す説明図である。 本発明の第１の実施形態における共有領域管理情報の構成例を示す説明図である。 本発明の第１の実施形態におけるエントリの論理的なデータ構成の一例を示す説明図である。 本発明の第１の実施形態におけるエントリの論理的なデータ構成の一例を示す説明図である。 本発明の第１の実施形態におけるエントリの論理的なデータ構成の一例を示す説明図である。 本発明の第１の実施形態におけるロード処理の詳細を説明するフローチャートである。 本発明の第１の実施形態におけるアンロード処理の詳細を説明するフローチャートである。 本発明の第１の実施形態におけるアンロード処理の詳細を説明するフローチャートである。 本発明の第２の実施形態における計算機システムの構成例を示すブロック図である。 本発明が第３の実施形態における計算機システムの構成例を示すブロック図である。 本発明の第３の実施形態におけるエントリの構成例を示す説明図である。 本発明の第３の実施形態におけるアクセス統計情報の構成例を示す説明図である。 本発明の第３の実施形態における移行条件情報の構成例を示す説明図である。 本発明の第３の実施形態におけるデータ移行処理を説明するフローチャートである。 本発明の第３の実施形態におけるエントリの論理的なデータ構成の一例を示す説明図である。 本発明の第３の実施形態におけるエントリの論理的なデータ構成の一例を示す説明図である。

［第１の実施形態］
図１は、本発明の第１の実施形態における計算機システムの構成例を示すブロック図である。

第１の実施形態の計算機システムは、ホストコンピュータ１０１、複数のホストコンピュータ１０２、ストレージ装置１０３及び共有ストレージ装置１０５から構成される。

ホストコンピュータ１０１は、ネットワーク１０４を介してホストコンピュータ１０２と接続される。また、各ホストコンピュータ１０２は共有ストレージ装置１０５と接続される。ネットワーク１０４は、ＬＡＮ及びＷＡＮ等が考えられるが、本発明はネットワーク１０４の種別に限定されない。なお、共有ストレージ装置１０５は、ネットワーク１０４を介して接続されてもよい。

本実施形態では、計算機システムが備える記憶領域を統合して分散メモリキャッシュが生成される。本実施形態の分散メモリキャッシュは、各ホストコンピュータ１０２が備えるメモリ領域から生成される分散領域１７１と、共有ストレージ装置１０５の記憶領域から生成される共有領域１７２とから構成される。

分散メモリキャッシュには、キー・バリュー型データ（エントリ１９１）が格納される。本実施形態では、分散領域１７１にエントリ１９１が格納される。エントリ１９１には、少なくともキーが含まれ、バリューは必ずしも含まれない。この場合、エントリ１９１は、バリュー１９２にアクセスするための情報を含む。本実施形態では、バリュー１９２は、分散領域１７１又は共有領域１７２のいずれかに格納される。なお、エントリ１９１の詳細については後述する。

分散メモリキャッシュは、ホストコンピュータ１０２から共有デバイスと同様にアクセスすることが可能である。処理対象となるデータを分散メモリキャッシュに格納することによって、データがストレージ装置１０３に格納される場合と比較して入出力処理が高速になる。

また、ホストコンピュータ１０１は、ストレージ装置１０３と接続される。ストレージ装置１０３には、処理対象となるデータソース１１７が格納される。ストレージ装置１０３は、データソース１１７を永続的に保持できるものであればどのようなものでもよい。ストレージ装置１０３は、例えば、ＨＤＤ等の記憶媒体を複数備えるストレージシステム、フラッシュメモリを記憶媒体として用いた半導体ディスク装置及び光ディスク装置等が考えられる。

また、本実施形態では、処理の対象とされるデータソース１１７は、ファイル及びＤＢのテーブルを使用するものとして説明する。ただし、本発明はデータソース１１７の格納形式に限定されず、キー・バリュー・ストア（ＫＶＳ）など永続的にデータを保持することができれば、データの格納形式は特に問わない。

ホストコンピュータ１０１は、プロセッサ１１１、メモリ１１３、及びインタフェース（Ｉ／Ｆ）１１５Ａ、１１５Ｂを備える。ホストコンピュータ１０１は、インタフェース１１５Ａを介してストレージ装置１０３と接続され、また、ホストコンピュータ１０１は、インタフェース１１５Ｂを介してホストコンピュータ１０２と接続される。

プロセッサ１１１は、メモリ１１３に格納されるプログラムを実行する。プロセッサ１１１が、メモリ１１３に格納されるプログラムを実行することによって、後述するホストコンピュータ１０１の機能が実現される。

メモリ１１３は、プロセッサ１１１が実行するプログラム及び当該プログラムを実行するために必要なデータを格納する。メモリ１１３は、例えば、ＤＲＡＭのような半導体メモリが考えられ、ストレージ装置１０３に比べ高速にアクセスすることができる。

本実施形態のメモリ１１３は、データソース管理部１２１及びローダ部１３１を実現するためのプログラムを格納し、また、分散メモリキャッシュ構成情報１８１、データソース情報１８２、及び対応情報１８３を格納する。

データソース管理部１２１は、ストレージ装置１０３に格納されたデータソース１１７を管理し、データソース１１７に対する入出力処理を実行する。

ローダ部１３１は、データソース管理部１２１と協調して、ストレージ装置１０３に格納されるデータソース１１７を分散メモリキャッシュへ分散配置し、また、分散メモリキャッシュに格納されるキー・バリュー型データ（エントリ１９１）をストレージ装置１０３へ格納する。ローダ部１３１は、分散メモリキャッシュ構成情報１８１、データソース情報１８２、及び対応情報１８３を参照して前述した処理を実行する。

以下では、ストレージ装置１０３に格納されるデータソース１１７を分散メモリキャッシュに分散して配置する処理をロード処理と記載する。また、分散メモリキャッシュに格納されるキー・バリュー型データを、ストレージ装置１０３へ格納する処理をアンロード処理と記載する。

分散メモリキャッシュ構成情報１８１は、分散メモリキャッシュを構成する分散領域１７１及び共有領域１７２に関する情報を格納する。分散メモリキャッシュ構成情報１８１の詳細については、図３を用いて後述する。

データソース情報１８２は、ファイル及びＤＢの表などのデータソース１１７に関する情報を格納する。データソース情報１８２の詳細については、図４を用いて後述する。

対応情報１８３は、データソース１１７と、分散メモリキャッシュに配置されたエントリ１９１との対応関係に関する情報を格納する。対応情報１８３の詳細については、図５を用いて後述する。

なお、メモリ１１３に格納されるプログラム及びデータは、常にメモリ１１３上に格納される必要はなく、ストレージ装置１０３又は図示しない外部記憶装置等に格納されてもよい。この場合、必要に応じて、プログラム又はデータがストレージ装置１０３又は外部記憶装置からメモリ１１３に読み出される。なお、データを読み出す場合には、データの一部又は全部を読み出すことができる。

なお、データソース管理部１２１及びローダ部１３１は、プログラムによって実現しているが本発明はこれに限定されない。例えば、専用のハードウェアを用いてデータソース管理部１２１及びローダ部１３１が備える機能を実現してもよい。

ホストコンピュータ１０２は、プロセッサ１１２、メモリ１１４、及びインタフェース（Ｉ／Ｆ）１１６を備える。ホストコンピュータ１０２は、インタフェース１１６Ａを介してホストコンピュータ１０１及び他のホストコンピュータ１０２と接続される。また、ホストコンピュータ１０２は、インタフェース１１６Ｂを介して共有ストレージ装置１０５と接続される。

ここでは、ホストコンピュータ１０２は同一の構成であるものとして説明するが、以下に説明する機能及び処理を実現できるものであれば、必ずしも同一の構成でなくてもよい。

プロセッサ１１２は、メモリ１１４に格納されるプログラムを実行する。プロセッサ１１２が、メモリ１１４に格納されたプログラムを実行することによって後述するホストコンピュータ１０２の機能が実現される。

メモリ１１４は、プロセッサ１１２が実行するプログラム及び当該プログラムを実行するために必要なデータを格納する。メモリ１１４は、例えば、ＤＲＡＭのような半導体メモリが考えられ、ストレージ装置１０３に比べ高速にアクセスすることができる。

本実施形態のメモリ１１４は、分散メモリキャッシュ管理部１４１を実現するためのプログラム、及びアプリケーションプログラム（ＵＡＰ）１６１を格納する。また、メモリ１１４は、分散メモリキャッシュを構成する分散領域１７１を含む。

分散メモリキャッシュ管理部１４１は、他のホストコンピュータ１０２の分散メモリキャッシュ管理部１４１と協調して、分散メモリキャッシュを構成する分散領域１７１及び共有領域１７２を管理する。また分散メモリキャッシュ管理部１４１は、分散メモリキャッシュへのアクセスを制御する。

分散メモリキャッシュ管理部１４１は、エントリ配置管理部１４２、共有領域アクセス管理部１４３、共有バリュー管理情報１４４、及び共有領域管理情報１４５を含む。また、図示していないが、分散メモリキャッシュ管理部１４１は、エントリ１９１の配置場所を管理するための情報であるファイル管理情報を含む。

分散メモリキャッシュ管理部（図示省略）は、分散メモリキャッシュの管理機能を提供する。エントリ配置管理部１４２は、エントリ１９１が格納される記憶領域を管理する。共有領域アクセス管理部１４３、共有領域１７２へのアクセスを管理する。

共有バリュー管理情報１４４は、共有領域１７２に格納されるバリュー１９２に関する情報を格納する。なお、共有バリュー管理情報１４４の詳細については、図９を用いて後述する。共有領域管理情報１４５は、共有領域１７２の管理情報を格納する。なお、共有領域管理情報１４５の詳細については、図１０を用いて後述する。また、図示していないファイル管理情報には、データソースの識別子及びエントリの格納位置を示す情報などが格納される。

なお、メモリ１１４に格納されるプログラム及びデータは、常にメモリ１１４上に格納される必要はなく、図示しないストレージ装置、又は図示しない外部記憶装置等に格納されてもよい。この場合、必要に応じて、プログラム又はデータがディスク装置又は外部記憶装置からメモリ１１４に読み出される。なお、データを読み出す場合には、データの一部又は全部を読み出すことができる。

前述したデータソース管理部１２１及び分散メモリキャッシュ管理部１４１は、図示しないオペレーティングシステム（ＯＳ）の一部、又は、図示しないユーザアプリケーションプログラムによって使用される入出力ライブラリとして提供されてもよい。また、専用のハードウェアを用いてデータソース管理部１２１及び分散メモリキャッシュ管理部１４１が備える機能を実現してもよい。

共有ストレージ装置１０５は、記憶媒体としてフラッシュメモリを用いた半導体ディスク装置等、通常のディスク装置よりランダムアクセス特性に優れた装置を用いるものとするが、物理的又は論理的に共有可能なストレージ装置であれば、記憶媒体の種類は問わない。本実施形態では、共有ストレージ装置１０５の記憶領域に、分散メモリキャッシュを構成する共有領域１７２が確保される。

なお、図１のホストコンピュータ１０２は、物理的な計算機である必要はなく、論理計算機でもよい。この場合、プロセッサ１１２、メモリ１１４、及びインタフェース１１６等の計算機リソースは、仮想化プログラム（図示省略）等によって論理的な計算機リソースとして論理計算機に割り当てられる。

図２は、本発明の第１の実施形態におけるデータソース１１７の構成例を示す説明図である。図２では、データソース１１７がファイルである場合について説明する。

ファイル２１００は、ＵＡＰ１６１によって処理されるデータの基本単位となる複数のレコードから構成される。図２に示す例では、ファイル２１００は、レコード２１０１、レコード２１０２、レコード２１０３、レコード２１０４を含む。

各レコード２１０１、２１０２、２１０３、２１０４は、一連の関連する情報を格納する複数のフィールド２１１１、２１１２、２１１３から構成される。図２に示す例では、各レコードは、フィールド２１１１、フィールド２１１２、及びフィールド２１１３を含む。

一般に、システムの制約の範囲内において、１つのファイルは任意の数のレコードを含むことができ、また、１つのレコードは任意の数のフィールドを含むことができる。例えば、商品取引業務で用いられるようなデータの場合、１件の取引における取引情報からレコードが構成され、口座番号、店番号、及び商品コード等の個々の情報（データ）がフィールドに記録される。

ＵＡＰ１６１は、レコードを処理単位としてＩ／Ｏ処理を実行し、ファイルに対してレコードを１件ずつ入出力することによって処理を実行する。本実施形態では、ファイル２１００は、任意のフィールドをキーとして、レコード単位に分割される。なお、レコードは、ＵＡＰ１６１が実行する処理に適合するように分割される。

分割されたファイル２１００のデータ、すなわち、キー・バリュー型データは、複数のホストコンピュータ１０２上のＵＡＰ１６１にそれぞれ割り当てられ、各ＵＡＰ１６１が、割り当てられたキー・バリュー型データを用いて処理を実行する。前述したように、複数のＵＡＰ１６１が、一つのファイル２１００が分割されたキー・バリュー型データを並列に処理することによって、１つのＵＡＰ１６１が処理するデータ量を削減することができる。したがって、処理の高速化を実現できる。

図３は、本発明の第１の実施形態における分散メモリキャッシュ構成情報１８１の構成例を示す説明図である。

分散メモリキャッシュ構成情報１８１は、総サイズ２０１、分散領域サイズ２０２、分散領域使用率２０３、共有領域サイズ２０４及び共有領域使用率２０５を含む。

総サイズ２０１は、分散メモリキャッシュ全体のサイズを格納する。具体的には、分散領域１７１のサイズと、共有領域１７２のサイズとの総和が格納される。本実施形態では、分散領域サイズ２０２及び共有領域サイズ２０４を足し合わせた値が分散メモリキャッシュのサイズとなる。

分散領域サイズ２０２は、分散メモリキャッシュを構成する全ての分散領域１７１の総サイズを格納する。具体的には、分散領域サイズ２０２には、各ホストコンピュータ１０２の分散領域１７１のサイズの総和が格納される。分散領域使用率２０３は、分散領域１７１の使用率を格納する。

共有領域サイズ２０４は、共有領域１７２のサイズを格納する。共有領域使用率２０５は、共有領域１７２の使用率を格納する。

分散メモリキャッシュ構成情報１８１は、ロード処理の実行時に、十分な記憶領域があるか否かの判定するために用いられる。詳細には述べないが、十分な記憶領域がない場合には、記憶領域を確保するための処理が実行される。記憶領域を確保するための処理としては、例えば、アンロード処理、及び、分散領域１７１と共有領域１７２との間のエントリ１９１の移行処理などが考えられる。

図４は、本発明の第１の実施形態におけるデータソース情報１８２の構成例を示す説明図である。

データソース情報１８２は、データソース識別情報３０１、レコード定義情報３０２及び配置指定情報３０３を含む。

データソース識別情報３０１は、ストレージ装置１０３に格納される複数のデータソース１１７を一意に識別するための識別情報を格納する。データソース識別情報３０１には、データソース１１７を一意に識別できる情報であればどのような情報が格納されてもよい。例えば、データソース識別情報３０１には、フルパスのファイル名又はＤＢにおけるテーブル名などが格納される。

なお、データソース１１７の管理方法によっては、データソース１１７を保持するストレージ装置１０３及びホストコンピュータ１０１の識別情報が必要な場合がある。前述のような場合には、データソース識別情報３０１に、ストレージ装置１０３及びホストコンピュータ１０１の識別情報が含まれる。

なお、データソース１１７に対応するデータソース情報１８２が一意に特定できればよいため、データソースの属性など、データソースと１対１で対応づけられるように管理されている場合には、データソース識別情報３０１は必要ない。

レコード定義情報３０２は、データソース１１７におけるレコードの構造に関する情報を格納する。なお、レコード定義情報３０２の詳細については、図６用いて後述する。

配置指定情報３０３は、ロード処理の実行時に、配置先の記憶領域を指定するための情報を格納する。配置指定情報３０３には、例えば、「分散領域」、「共有領域」又は「指定なし」などの情報が格納される。

「分散領域」が格納される場合、エントリ１９１のキーにしたがって、所定のキーレンジのエントリ１９１を管理するホストコンピュータ１０２の分散領域１７１に当該エントリ１９１及びバリュー１９２が優先的に配置される。「共有領域」が格納される場合、所定のホストコンピュータ１０２の分散領域１７１にエントリ１９１が配置され、共有領域１７２にバリュー１９２が優先的に配置される。また、「指定なし」が格納される場合、格納先の記憶領域が指定されていないことを示す。

図５は、本発明の第１の実施形態における対応情報１８３の構成例を示す説明図である。

対応情報１８３は、データソース識別情報４０１、参照数４０２、領域利用情報４０３及びロード識別情報４０４を含む。

データソース識別情報４０１は、データソース１１７を一意に識別するための識別情報を格納する。データソース識別情報４０１は、データソース識別情報３０１と同一ものである。

参照数４０２は、データソース１１７が分散メモリキャッシュにロードされた回数を格納する。すなわち、参照数４０２は、ＵＡＰ１６１によって扱われるキー・バリュー型データの数を示す。本実施形態では、参照数４０２に基づいて１つのデータソースが複数のＵＡＰ１６１によって共有されているか否かが判定される。

領域利用情報４０３は、バリュー１９２が格納される記憶領域の種別を格納する。すなわち、領域利用情報４０３には、バリュー１９２が分散領域１７１又は共有領域１７２のいずれに格納されているかを示す情報が格納される。

ロード識別情報４０４は、ロード処理が実行される毎に、ローダ部１３１が返す識別情報を格納する。本実施形態では、アンロード処理を実行する場合に、ロード識別情報４０５に基づいて、分散メモリキャッシュに格納されるエントリ１９１のうち、どのエントリ１９１がアンロード処理の対象であるかが判定される。

図６は、本発明の第１の実施形態におけるレコード定義情報３０２の構成例を示す説明図である。

レコード定義情報３０２は、データソース１１７におけるレコードを構造に関する情報を格納する。本実施形態では、レコード定義情報３０２に基づいて、データソース１１７をレコード単位に分割できる。レコード定義情報３０２は、レコード構成５０１及びフィールド構成５０２を含む。

レコード構成５０１は、データソース１１７におけるレコード構造を把握するための情報を格納し、レコードデリミタ５１１、レコード種別５１２及びレコード長５１３を含む。

レコードデリミタ５１１は、レコードと他のレコードとの間を区切る文字コードを示す情報を格納する。レコードデリミタ５１１には、例えば、改行を表す文字コードなどを用いることが考えられる。

レコード種別５１２は、データソース１１７におけるレコードが固定長レコード又は可変長レコードのいずれであるかを示す情報を格納する。レコード種別５１２に固定長レコードを示す情報が格納される場合、データソース１１７は、同一かつ所定の長さのレコードから構成される。レコード種別５１２に可変長レコードを示す情報が格納される場合、データソース１１７は、レコードの長さがそれぞれ異なるレコードから構成される。

レコード長５１３は、レコード種別５１２に固定長レコードを示す情報が格納される場合に、１つのレコードの長さを示す情報を格納する。

なお、レコード構成５０１にはレコードの構造を把握することができる情報が含まれていればよく、レコードデリミタ５１１、レコード種別５１２、及びレコード長５１３のすべての情報を含む必要はない。例えば、固定長のレコードである場合、レコードデリミタ５１１はレコード構成５０１に含まれていなくてもよい。

フィールド構成５０２は、レコードに含まれるフィールドを識別するための情報を格納するものであり、フィールドデリミタ５２１、フィールド数５２２、及びフィールド情報５２３を含む。

フィールドデリミタ５２１は、フィールドと他のフィールドとの間を区切る文字コードを示す情報を格納する。フィールドデリミタ５２１には、例えば、空白を表す文字コードなどを用いることが考えられる。

フィールド数５２２は、１つのレコードに含まれるフィールドの数を格納する。

フィールド情報５２３は、対応するフィールドに記録されるデータに関する情報を格納し、フィールド種別５３１、フィールド長５３２及び記述形式５３３を含む。

フィールド種別５３１は、レコード種別５１２に可変長レコードを示す情報が格納される場合、対応するフィールドが可変長フィールド又は固定長フィールドのいずれであるかを示す情報を格納する。

フィールド長５３２は、対応するフィールドの大きさを示す情報を格納する。記述形式５３３は、ＡＳＣＩＩ、バイナリ等、対応するフィールドに記録されたデータの記述形式を格納する。

なお、フィールド構成５０２は、レコードに含まれるフィールドを把握することができればよいため、フィールドデリミタ５２１、フィールド数５２２、及びフィールド情報５２３のすべての情報を含む必要はない。例えば、フィールド情報５２３のフィールド長５３２が指定されていれば、フィールドデリミタ５２１の情報はフィールド構成５０２に含まれなくてもよい。

データソース１１７が固定長レコードから構成される場合、レコード長５１３に設定された値によって個々のレコードを認識することができる。一方、データソース１１７が可変長レコードから構成される場合、各レコードの先頭には、そのレコードの大きさを記録するフィールドが設けられ、当該フィールドに基づいてレコードの区切れを判定することができる。レコードが可変長レコードである場合、フィールド構成５０２に格納される情報に基づいて最初のフィールドが識別され、レコードサイズを算出することができる。レコードが認識された後は、フィールド構成５０２のフィールド数５２２、及びフィールド情報５２３のフィールド長５３２を参照することによってフィールドを把握できる。

図７は、本発明の第１の実施形態におけるＵＡＰ１６１のソースプログラムの一例を示す説明図である。

図７は、ＣＯＢＯＬ言語を用いて記述されたＵＡＰ１６１のソースコードを示す。ＣＯＢＯＬ言語を用いて記述されたＵＡＰ１６１では、プログラム中にデータソースとしてのファイルのレコード構造が定義される。

図７に示す例では、ＤＡＴＡ ＤＩＶＩＳＩＯＮのＦＩＬＥ ＳＥＣＴＩＯＮ６０２においてファイルの構造が定義される。プログラムに用いられる各ファイルは、一つのファイル記述項（ＦＤ）と、それに続く一つ以上のレコード記述項とによって定義される。本実施形態において、レコード定義情報３０２のレコード構成５０１及びフィールド構成５０２には、ＦＩＬＥ ＳＥＣＴＩＯＮ６０２に記述された情報が格納される。

図８は、本発明の第１の実施形態におけるエントリ１９１のデータ構成の一例を示す説明図である。

エントリ１９１は、分散メモリキャッシュ管理部１４１が、ＵＡＰ１６１によって指定されたキーに対応するバリュー１９２を取得するための情報を格納する。エントリ１９１は、キー７０１、領域利用情報７０２、格納位置情報７０３、及び共有バリュー管理情報ポインタ７０５を含む。

キー７０１は、エントリ１９１におけるキーを格納する。

領域利用情報７０２は、エントリ１９１に対応するバリュー１９２が配置される記憶領域に関する情報を格納する。本実施の形態では、領域利用情報７０２には、「分散領域」又は「共有領域」のいずれかが格納される。領域利用情報７０２は、ローダ部１３１がバリュー１９２を配置する場合、又は、分散メモリキャッシュ管理部１４１がバリュー１９２の配置場所を変更する場合に設定される。

領域利用情報７０２に「分散領域」が格納される場合、バリュー１９２が分散領域１７１に格納されることを示す。すなわち、同一のデータソース１１７を扱うＵＡＰ１６１が存在しないことを示す。一方、領域利用情報７０２に「共有領域」が格納される場合、バリュー１９２が共有領域１７２に格納されることを示す。すなわち、複数のＵＡＰ１６１が同一のデータソース１１７を扱うことを示す。

なお、エントリ１９１の論理的なデータ構造については、図１１、図１２及び図１３を用いて後述する。

格納位置情報７０３は、バリューにアクセスするための情報、すなわち、バリューの格納位置を示す情報を格納する。

領域利用情報７０２に「分散領域」が格納される場合、格納位置情報７０３には、自ホストコンピュータ１０２の分散領域１７１に格納されるバリュー１９２、又は、分散領域１７１に格納されるバリュー１９２の格納位置を示す情報が格納される。バリュー１９２の格納位置を示す情報としては、メモリアドレス等が考えられる。

領域利用情報７０２に「共有領域」が格納される場合、格納位置情報７０３には、共有領域１７２に格納されるバリュー１９２の格納位置を示す情報が格納される。

共有バリュー管理情報ポインタ７０４は、共有領域１７２に格納されるバリュー１９２を管理する共有バリュー管理情報１４４へのポインタを格納する。

以下では、共有領域に格納されるバリュー１９２を共有バリュー１９２とも記載する。

図９は、本発明の第１の実施形態における共有バリュー管理情報１４４の構成例を示す説明図である。

共有バリュー管理情報１４４は、ロード処理においてエントリ１９１が生成される時に生成される。また、共有バリュー管理情報１４４は、分散メモリキャッシュからエントリ１９１が消去される時に削除される。

共有バリュー管理情報１４４は、データソース識別情報８０１、レコード識別情報８０２、格納位置情報８０３、共有数８０４、エントリポインタ８０５及び共有領域管理情報ポインタ８０６を含む。

データソース識別情報８０１及びレコード識別情報８０２は、エントリ１９１と、データソース１１７のレコードとを対応付けるための情報である。具体的には、データソース識別情報８０１は、ストレージ装置１０３に格納される複数のデータソース１１７を一意に識別するための識別情報を格納する。データソース識別情報８０１は、データソース識別情報３０１と同一の情報である。

レコード識別情報８０２は、データソース１１７のレコードを識別するための情報を格納する。レコード識別情報８０２には、例えば、データソース１１７に含まれるレコードのレコード番号又は行番号などを用いることが考えられるが、レコードを識別できればどのような情報が格納されてもよい。

格納位置情報８０３は、エントリ１９１のバリュー１９２の格納位置を示す情報を格納する。格納位置情報８０３は、格納位置情報７０３と同一のものである。

共有数８０４は、バリュー１９２を共有するＵＡＰ１６１の数を格納する。

エントリポインタ８０５は、エントリ１９１の格納位置を示すポインタを格納する。

共有領域管理情報ポインタ８０６は、共有領域１７２に格納されたバリュー１９２の一貫性を制御するための情報である共有領域管理情報１４５へのポインタを格納する。

図１０は、本発明の第１の実施形態における共有領域管理情報１４５の構成例を示す説明図である。

共有領域管理情報１４５は、共有領域１７２に格納されたバリュー１９２の一貫性を保つために必要な情報を格納する。共有領域管理情報１４５は、格納位置情報９０１、共有バリュー管理情報ポインタ９０２、更新権管理情報９０３及び参照権管理情報９０４を含む。

格納位置情報９０１は、共有バリュー１９２の格納位置を示す情報を格納する。具体的には、共有領域１７２に格納されるバリュー１９２の格納位置を示す情報が格納される。

共有バリュー管理情報ポインタ９０２は、共有バリュー管理情報１４４へのポインタを格納する。共有バリュー管理情報ポインタ９０２は、共有バリュー管理情報ポインタ７０４と同一のものである。

更新権管理情報９０３は、共有バリュー１９２の更新処理の権限を有するホストコンピュータ１０２の識別情報を格納する。参照権管理情報９０４は、共有バリュー１９２の参照処理の権限を有するホストコンピュータ１０２の識別情報を格納する。更新権管理情報９０３及び参照権管理情報９０４には、例えば、ホストコンピュータ１０２のＩＰアドレス、マックアドレスなどが格納される。なお、ホストコンピュータ１０２を識別できるものであれば、更新権管理情報９０３及び参照権管理情報９０４にはどのような情報が格納されてもよい。

なお、本実施形態では、共有領域管理情報１４５は共有バリュー管理情報１４４からポイントされているが、共有バリュー１９２の一貫性を保つことができるデータ構造であればどのようなものであってもよい。この場合、分散メモリキャッシュ管理部１４１が管理する必要はない。例えば、共有ストレージ装置１０５に構築された共有ファイルシステムを用いて、共有バリュー１９２と共有ファイルシステムのファイルとを対応付けることによって、共有ファイルシステムの管理プログラムが共有バリュー１９２の一貫性制御を行う方法が考えられる。

以下、本発明におけるエントリ１９１の構造について説明する。

図１１、図１２及び図１３は、本発明の第１の実施形態におけるエントリ１９１の論理的なデータ構成の一例を示す説明図である。

図１１は、バリュー１９２が分散領域１７１に格納される場合におけるエントリ１９１の論理的なデータ構成を示す。図１１に示す例では、エントリ１９１は、キー７０１、領域利用情報７０２、及びバリュー１９２を一つの組としたデータとして認識される。

分散メモリキャッシュ管理部１４１は、ＵＡＰ１６１から指定されたキー７０１を含むアクセス要求を受信した場合に、指定されたキーに対応するエントリ１９１の領域利用情報７０２を参照することによって、バリュー１９２が分散領域１７１に格納されていると判定する。さらに、分散メモリキャッシュ管理部１４１は、所定のバリュー１９２にアクセスして、ＵＡＰ１６１に応答する。

図１２は、バリュー１９２が共有領域１７２に格納される場合におけるエントリ１９１の論理的なデータ構成を示す。図１２に示す例では、エントリ１９１は、キー７０１、領域利用情報７０２、共有バリュー格納位置情報１１０３、及び共有バリュー１９２を一つの組としてデータとして認識される。

分散メモリキャッシュ管理部１４１は、ＵＡＰ１６１から指定されたキー７０１を含むアクセスを受信した場合に、指定されたキーに対応するエントリ１９１の領域利用情報７０２を参照することによって、バリュー１９２が共有領域１７２に格納されていると判定する。さらに、分散メモリキャッシュ管理部１４１は、共有バリュー格納位置情報１１０３を参照して共有バリュー１９２の格納位置を特定し、共有バリュー１９２にアクセスして、ＵＡＰ１６１に応答する。共有バリュー格納位置情報１１０３としては、例えば、共有ストレージ装置１０５におけるデータの格納場所を示すブロックアドレス及びバリューのサイズ情報などが考えられる。ただし、共有バリュー１９２の格納位置を一意に識別できるものであれば、共有バリュー格納位置情報１１０３はどのような情報であってもよい。

図１３は、共有領域１７２に格納される場合におけるエントリ１９１の論理的なデータ構成を示す。図１３に示すエントリでは、共有バリュー格納位置情報１１０３の代わりに、共有バリューを一意に識別する共有バリュー識別情報１２０３を用いる点が異なる。

共有バリュー識別情報１２０３としては、例えば、共有ストレージ装置１０５上に構築された共有ファイルシステムにおけるファイル名又はデータソース識別情報３０１と、データソース１１７におけるレコード番号（又は行番号）とを組み合わせたものが考えられる。

図１３に示すように、共有バリュー１９２についても、キー・バリュー型データのエントリ１９１となるように分散メモリキャッシュに格納することによって、同一のデータ構造のエントリ１９１を分散領域１７１及び共有領域１７２に格納することができる。

図１４は、本発明の第１の実施形態におけるロード処理の詳細を説明するフローチャートである。

ローダ処理は、ローダ部１３１によって実行される。ローダ部１３１は、データソース１１７から分散メモリキャッシュへデータをロードする場合に、以下で説明するローダ処理を開始する。

なお、ロード処理の実行時には、ロード対象のデータソース１１７と、キーとすべき情報とが指定される。キーとすべき情報は、ＵＡＰ１６１が何に着目して処理を行うかに依存する。例えば、図２に示すファイル２１００を例にすると、キーとすべきフィールドを指定することが考えられる。

ローダ部１３１は、指定されたロード対象のデータソース１１７及び指定されたキーとすべき情報に基づいて、エントリを生成する（ステップＳ１４０１）。具体的には、以下のような処理が実行される。

ローダ部１３１は、指定されたデータソース１１７の識別情報に基づいてデータソース情報１８２を特定し、データソース情報１８２のレコード定義情報３０２を参照することによってデータソース１１７のレコード構造を把握する。

ローダ部１３１は、把握したレコード構造に基づいてキーが生成し、また、エントリ１９１を生成する。ローダ部１３１は、エントリ１９１のキー７０１に生成されたキーを設定する。以上がステップＳ１４０１の処理である。

次に、ローダ部１３１は、対応情報１８３の参照数４０２を更新する（ステップＳ１４０２）。具体的には、ローダ部１３１は、参照数４０２の値を「１」インクリメントする。ローダ部１３１は、参照数４０２の値に基づいて、現在分散メモリキャッシュ上に同一のデータソース１１７がロードされているか否かを判定できる。

ローダ部１３１は、指定されたデータソース１１７の配置場所が指定されているか否かを判定する（ステップＳ１４０３）。具体的には、以下のような処理が実行される。

ローダ部１３１は、データソース情報１８２の配置指定情報３０３を参照して、配置場所が指定されているか否かを判定する。配置指定情報３０３に「分散領域」又は「共有領域」が格納される場合には、指定されたデータソース１１７の配置場所が指定されていると判定される。一方、配置指定情報３０３に「指定なし」が格納される場合、指定されたデータソース１１７の配置場所が指定されていないと判定される。

指定されたデータソース１１７の配置場所が指定されていないと判定された場合、ローダ部１３１は、参照数４０２が「２」以上であるか否かを判定する（ステップＳ１４０４）。これは、配置場所が指定されていない場合には、ローダ部１３１がデータソース１１７の配置場所を決定するための処理である。

参照数４０２が「２」より小さい場合、複数のＵＡＰ１６１によってバリュー１９２が共有されないため、配置場所として分散領域１７１が選択される。一方、参照数４０２が「２」以上である場合、複数のＵＡＰ１６１によってバリュー１９２が共有されるため、配置場所として共有領域１７２が選択される。

参照数４０２が「２」以上であると判定された場合、ローダ部１３１は、バリュー１９２が共有領域１７２に格納済みであるか否かを判定する（ステップＳ１４０５）。具体的には、ローダ部１３１は、対応情報１８３の領域利用情報４０３を参照して、バリュー１９２が共有領域１７２に格納されているか否かを判定する。

バリュー１９２が共有領域１７２に格納済みであると判定された場合、ローダ部１３１は、エントリ１９１を分散領域１７１に配置し（ステップＳ１４０７）、処理を終了する。具体的には、以下のような処理が実行される。

ローダ部１３１は、エントリ１９１の領域利用情報７０２に「共有領域」を設定し、また、エントリ１９１の格納位置情報７０３に共有バリュー１９２を参照するための情報を設定する。格納位置情報７０３には、共有バリュー格納位置情報１１０３、又は、共有バリュー識別情報１２０３を用いることが考えられる。

さらに、ローダ部１３１は、キーの範囲にしたがって、所定のホストコンピュータ１０２の分散領域１７１に生成されたエントリ１９１を配置する。また、ローダ部１３１は、共有バリュー管理情報１４４及び共有領域管理情報１４５を生成して、各ホストコンピュータ１０２に送信する。以上がステップＳ１４０７の処理である。

バリュー１９２が共有領域１７２に格納済みでないと判定された場合、ローダ部１３１は、共有領域１７２にバリュー１９２を配置し、さらに、分散領域１７１にエントリ１９１を配置して（ステップＳ１４０６）、処理を終了する。具体的には、以下のような処理が実行される。

まず、ローダ部１３１は、共有領域１７２にバリューを格納するための領域を確保する。ローダ部１３１は、データソース１１７からデータを読み出して、共有領域１７２に共有バリュー１９２をロードする。

さらに、ローダ部１３１は、エントリ１９１の領域利用情報７０２に「共有領域」を設定し、また、格納位置情報７０３に共有バリュー１９２を参照するための情報を設定する。さらに、ローダ部１３１は、キーの範囲にしたがって、所定のホストコンピュータ１０２の分散領域１７１に生成されたエントリ１９１を配置する。また、ローダ部１３１は、共有バリュー管理情報１４４及び共有領域管理情報１４５を生成して、各ホストコンピュータ１０２に送信する。

なお、既に、同一のバリュー１９２を共有するエントリ１９１が分散領域１７１に存在する場合、ローダ部１３１は、分散領域１７１から共有領域１７２へ当該エントリ１９１が共有するバリュー１９２をコピーする。その後、ローダ部１３１は、既存のエントリ１９１に対応するバリュー１９２が格納されていた分散領域１７１の領域を無効化する。さらに、新規エントリ１９１、及び、既存のエントリ１９１の領域利用情報７０２に「共有領域」を設定し、また、格納位置情報７０３に共有バリュー１９２を参照するための情報を設定する。なお、新規エントリ１９１は、キーの範囲にしたがって、所定のホストコンピュータ１０２の分散領域１７１に配置される。

ステップＳ１４０３において、指定されたデータソース１１７の配置場所が指定されていると判定された場合、ローダ部１３１は、指定された配置場所が共有領域１７２であるか否かを判定する（ステップＳ１４０８）。具体的には、ローダ部１３１は、データソース情報１８２の配置指定情報３０３に「共有領域」が格納されているか否かを判定する。

指定された配置場所が共有領域１７２であると判定された場合、ローダ部１３１は、ステップＳ１４０５に進む。

指定された配置場所が共有領域１７２でないと判定された場合、ローダ部１３１は、分散領域１７１にエントリ１９１及びバリュー１９２を配置し（ステップＳ１４０９）、処理を終了する。このとき、ローダ部１３１は、エントリ１９１の領域利用情報７０２に「分散領域」を設定し、また、格納位置情報７０３にバリュー１９２にアクセスするための情報が設定される。

なお、配置場所として分散領域１７１が指定された場合には、データソース１１７がロードされた数にかかわらず、エントリ１９１を分散領域１７１にロードする。これによって、従来の分散メモリキャッシュと同様に、複数のＵＡＰ１６１間でバリュー１９２を共有しないエントリ１９１を利用することができる。

なお、ロード処理終了後に、ローダ部１３１が返り値として応答する識別情報が、対応情報１８３のロード識別情報４０５に格納される。

なお、ステップＳ１４０６及びステップＳ１４０７では、ローダ部１３１が必要な情報をホストコンピュータ１０２に送信し、分散メモリキャッシュ管理部１４１が共有バリュー管理情報１４４及び共有領域管理情報１４５を生成してもよい。

エントリ１９１へのアクセス方法については、従来のアクセス方法と同一のものであるため説明を省略する。

図１５Ａ及び図１５Ｂは、本発明の第１の実施形態におけるアンロード処理の詳細を説明するフローチャートである。

分散メモリキャッシュからデータソース１１７へデータをアンロードする場合に、ローダ部１３１が以下で説明するアンロード処理を実行する。ホストコンピュータ１０２上のＵＡＰ１６１がデータ処理を実行した後に、分散メモリキャッシュからストレージ装置１０３のデータソース１１７へアンロードするときに、ホストコンピュータ１０１上のローダ部１３１が実行される。

なお、アンロード処理の実行時には、対応情報１８３のロード識別情報４０４に格納される情報が指定される。これによって、ローダ部１３１は、アンロード対象のエントリ１９１を識別できる。さらに、ローダ部１３１は、対応情報１８３のデータソース識別情報４０１を参照して、アンロード対象となるデータソース１１７を特定できる。

ローダ部１３１は、データソース情報１８２の配置指定情報３０３を参照して、指定されたデータソース１１７の配置場所が指定されているか否かを判定する（ステップＳ１５０１）。

例えば、配置指定情報３０３に「分散領域」又は「共有領域」が格納される場合には、指定されたデータソース１１７の配置場所が指定されていると判定される。一方、配置指定情報３０３に「指定なし」が格納される場合、指定されたデータソース１１７の配置場所が指定されていないと判定される。

データソース１１７の配置場所が指定されていると判定された場合、ローダ部１３１は、指定された配置場所が共有領域１７２であるか否かを判定する（ステップＳ１５０２）。具体的には、ローダ部１３１は、データソース情報１８２の配置指定情報３０３に「共有領域」が格納されているか否かを判定する。

指定された配置場所が共有領域１７２でないと判定された場合、ローダ部１３１は、対応するデータソース１１７に、分散領域１７１に格納されるバリュー１９２の値を反映する（ステップＳ１５０３）。具体的には、ローダ部１３１は、更新されたバリュー１９２の値を対応するデータソース１１７に書き込む。なお、バリュー１９２が更新されていない場合には、当該処理を省略することができる。

ローダ部１３１は、対応情報１８３の参照数４０２を更新する（ステップＳ１５０４）。具体的には、ローダ部１３１は、参照数４０２の値を「１」デクリメントする。これによって、現在のロード回数を管理できる。

さらに、ローダ部１３１は、エントリ１９１を分散メモリキャッシュから削除し（ステップ１５０５）、処理を終了する。このとき、分散領域１７１に格納されるバリュー１９２も合わせて削除される。

ステップＳ１５０２において、指定された配置場所が共有領域１７２であると判定された場合、ローダ部１３１は、参照数４０２が「１」以下であるか否かを判定する（ステップＳ１５０９）。

参照数４０２が「１」以下であると判定された場合、ローダ部１３１はステップＳ１５０３に進み、参照数４０２が「１」より大きいと判定された場合、ローダ部１３１はステップＳ１５０４に進む。

ステップＳ１５０１において、データソース１１７の配置場所が指定されていないと判定された場合、ローダ部１３１は、配置場所の変換処理を実行する（ステップＳ１５０６〜ステップＳ１５０８）。

まず、ローダ部１３１は、参照数４０２が「１」以下であるか否かを判定する（ステップＳ１５０６）。

参照数４０２が「１」以下であると判定された場合、当該アンロード処理によって、同一のデータソース１１７から生成されたエントリ１９１が分散メモリキャッシュから全てが削除される。したがって、ローダ部１３１は、バリュー１９２の更新を反映するためにステップＳ１５０３に進む。なお、ステップＳ１５０４において、ローダ部１３１は、共有バリュー管理情報１４４及び共有領域管理情報１４５の削除命令を各ホストコンピュータ１０２に通知する。

参照数４０２が「１」より大きいと判定された場合、ローダ部１３１は、参照数４０２が「３」以上であるか否かを判定する（ステップＳ１５０７）。

参照数４０２が「３」以上であると判定された場合、ローダ部１３１は、エントリ１９１を削除するためにステップＳ１５０４に進む。

参照数４０２が「３」より小さい、すなわち、参照数４０２が「２」であると判定された場合、ローダ部１３１は、共有バリュー１９２を共有領域１７２から分散領域１７１に移行し（ステップＳ１５０８）、ステップＳ１５０４に進む。これは、指定されたエントリ１９１が削除された後、共有バリュー１９２は、１つのＵＡＰ１６１からのみ参照されるため共有領域１７２に格納する必要がないためである。

なお、このとき、ローダ部１３１は、バリュー１９２の移行に伴ってエントリ１９１を更新する。すなわち、図１２又は図１３に示すようなエントリ１９１から、図１１に示すようなエントリ１９１に変換する。具体的には、領域利用情報７０２に「分散領域」が格納され、共有バリュー管理情報ポインタ７０５が削除される。また、格納位置情報７０３には、分散領域１７１におけるバリュー１９２の格納位置を示す情報が格納される。

また、ステップＳ１５０４において、ローダ部１３１は、共有バリュー管理情報１４４及び共有領域管理情報１４５の削除命令を各ホストコンピュータ１０２に通知する。

なお、第１の実施形態では、ホストコンピュータ１０１が、ローダ部１３１等を備えるものとして説明したが、本発明はこれに限定されない。例えば、少なくとも一つのホストコンピュータ１０２が、ストレージ装置１０３と接続され、また、ローダ部１３１、及びデータソース管理部１２１等を備えていてもよい。

第１の実施形態によれば、異なるアプリケーションによって同一のレコードから生成されたキー・バリュー型データ（エントリ）に対して、複数のアプリケーションがバリューを共有できるようにデータを管理できる。これによって、同一のデータソースからエントリを作成し直す必要なく、一つのアプリケーションによってバリューが更新された場合に、他のアプリケーションがアクセスするエントリにも反映することが可能になる。したがって、分散メモリキャッシュにおけるデータの一貫性を保つことができる。

［第２の実施形態］
第１の実施形態では、ホストコンピュータ１０２に接続される共有ストレージ装置１０５上に共有領域１７２を構成していたが、第２の実施形態では、各ホストコンピュータ１０２のメモリ１１４上に共有領域１７２を構成する点が異なる。以下、第１の実施形態との差異を中心に第２の実施形態について説明する。

図１６は、本発明の第２の実施形態における計算機システムの構成例を示すブロック図である。

ホストコンピュータ１０１の構成は、第１の実施形態と同一であるため説明を省略する。

第２の実施形態における計算機システムは、共有ストレージ装置１０５を備えていない。第２の実施形態では、ホストコンピュータ１０２が、メモリ１１４上に共有領域１６０１を構成する。ここで、分散領域１７１及び共有領域１６０１に格納される情報は、それぞれ、第１の実施形態における分散領域１７１及び共有領域１７２に格納される情報と同一である。なお、図１３に示すエントリ１９１の共有バリュー識別情報１２０３と共有バリュー１１０４とから構成されるキー・バリュー型データを共有領域１６０１に格納することがより望ましい。

通常のキー７０１に加え、共有バリュー識別情報１２０３を、共有バリュー１９２を一意に識別するキーとして利用することによって、キー・バリュー型データを実現するフレームワークにおいて、第１の実施形態よりも容易に共有バリュー１９２を管理することが可能になる。

バリュー１９２の共有が必要のないキー・バリュー型データは分散領域１７１に、バリュー１９２の共有が必要なキー・バリュー型データは共有領域１６０１に配置される。このとき、分散領域１７１には通常のキーを第一段階のキーとしたエントリを配置し、共有領域１６０１には共有バリュー識別情報１２０３を第二段階のキーとしたエントリを配置することによって、多段のキー構造でバリュー１９２の共有が実現できる。すなわち、共有領域１６０１に格納されるバリューについてもエントリ１９１と同様の構成にすることができる。

また、本実施形態では、分散領域１７１及び共有領域１７２を別々に構成しているが、本発明はこれに限定されず、一つの領域においてエントリ１９１とバリュー１９２とを管理してもよい。すなわち、図１２及び図１３のようなエントリ１９１を生成できれば、共有バリュー１９２がどのような記憶領域に格納していてもよい。

なお、その他の構成、及び処理は、第１の実施形態と同一であるため説明を省略する。

第２の実施形態によれば、共有ストレージ装置１０５を利用することなく、複数のアプリケーションによって共有されるバリューを認識することによって、同一のデータソースを介してエントリを作成し直す必要なく、一つのアプリケーションから生成されたエントリへの更新が、他のアプリケーションがアクセスするエントリへ反映することが可能になる。

［第３の実施形態］
第３の実施形態では、ホストコンピュータ１０２のメモリ１１４の分散メモリキャッシュ管理部１４１が、分散メモリキャッシュにおけるエントリ１９１のアクセス統計情報を取得し、当該情報に基づいて分散領域１７１と共有領域１７２との間の移行条件を判定する処理を含む点が第１の及び第２の実施形態と異なる。

以下、第１の実施形態との差異を中心に第３の実施形態について説明する。

図１７は、本発明が第３の実施形態における計算機システムの構成例を示すブロック図である。

分散メモリキャッシュ管理部１４１が、アクセス統計情報１７０１及び移行条件情報１７０２を含む点が第１の実施形態と異なる。

アクセス統計情報１７０１は、分散メモリキャッシュにおけるエントリ１９１へのアクセスに関する統計情報を格納する。移行条件情報１７０２は、バリュー１９２を共有領域１７２に移行するための判定基準、及び、共有バリュー１９２を分散領域１７１に移行するための判定基準に関する情報を格納する。

他の構成は、第１の実施形態と同一であるため説明を省略する。

図１８は、本発明の第３の実施形態におけるエントリ１９１の構成例を示す説明図である。

第３の実施形態の共有バリュー管理情報１４４は、新たにアクセス統計情報ポインタ１８０１を含む。アクセス統計情報ポインタ１８０１は、アクセス統計情報１７０１へのポインタを格納する。アクセス統計情報１７０１にエントリ１９１ごとのアクセス情報を格納することによって、エントリ単位のバリュー１９２の配置場所の変更ができる。

図１９は、本発明の第３の実施形態におけるアクセス統計情報１７０１の構成例を示す説明図である。

アクセス統計情報１７０１は、アクセス回数１９０１及び更新回数１９０２を含む。

アクセス回数１９０１は、対応するエントリ１９１への参照及び更新などのアクセス回数を格納する。更新回数１９０２は、対応するエントリ１９１への更新に関するアクセス回数を格納する。なお、本実施形態では、アクセス統計情報１７０１に格納される情報として、アクセス回数１９０１と更新回数１９０２とを用いているが、本発明はこれに限定されない。

図２０は、本発明の第３の実施形態における移行条件情報１６０２の構成例を示す説明図である。

移行条件情報１６０２は、共有領域移行条件２００１及び分散領域移行条件２００２を含む。

共有領域移行条件２００１は、バリュー１９２が分散領域１７１に格納されている場合に、共有領域１７２に移行させるための条件を格納する。

例えば、共有領域移行条件２００１には、アクセス統計情報１７０１に含まれる更新回数１９０２の閾値が格納される。この場合、設定された閾値を超えるとバリュー１９２が分散領域１７１から共有領域１７２に移行される。また、共有領域移行条件２００１にアクセス回数に対する更新回数の比率の閾値を格納しもよい。

分散領域移行条件２００２は、バリュー１９２が共有領域１７２に格納されている場合に、分散領域１７１に移行させるための条件を格納する。

例えば、分散領域移行条件２００２には、アクセス統計情報１７０１に含まれるアクセス回数１９０１に対する更新回数１９０２の比率の閾値を格納する。この場合、設定された閾値を下回ると共有バリュー１９２が共有領域１７２から分散領域１７１に移行される。

図２１は、本発明の第３の実施形態におけるデータ移行処理を説明するフローチャートである。

データ移行処理は、キー・バリュー型データのエントリがロードされるとき、エントリがデータソース１１７にアンロードされるときに、エントリ配置管理部１４２によって実行される。また、データ移行処理は、エントリのロード及びアンロードのときに限らず、ジョブネット実行時のジョブ実行の合間や、周期的に実行されてもよい。

エントリ配置管理部１４２は、対象とするエントリ１９１のバリュー１９２が共有領域１７２に格納されているか否かを判定する（ステップＳ２１０１）。具体的には、エントリ配置管理部１４２は、エントリ１９１の領域利用情報７０２を参照して、バリュー１９２が共有領域１７２に格納されているか否かを判定する。

バリューが共有領域１７２に格納されていると判定された場合、エントリ配置管理部１４２は、エントリ１９１を参照してアクセス統計情報１７０１を取得し、共有領域移行条件を満たすか否かを判定する（ステップＳ２１０２）。

具体的には、エントリ配置管理部１４２は、エントリ１９１のアクセス統計情報ポインタ１８０１を参照してアクセス統計情報１７０１を取得する。エントリ配置管理部１４２は、移行条件情報１７０２と、取得された１７０１とを参照して、共有領域移行条件を満たすか否かを判定する。これは、仮に共有領域移行条件と、分散領域移行条件とが同時に満たされた場合に、現在格納されている共有領域１７２を優先して使用するための判定処理である。

共有領域移行条件を満たすと判定された場合、エントリ配置管理部１４２は、処理を終了する。

共有領域移行条件を満たさないと判定された場合、エントリ配置管理部１４２は、エントリ１９１を参照してアクセス統計情報１７０１を取得し、分散領域移行条件を満たすか否かを判定する（ステップＳ２１０３）。ステップＳ２１０３の処理は、ステップＳ２１０２の処理と同様の処理であるため説明を省略する。

分散領域移行条件を満たさないと判定された場合、エントリ配置管理部１４２は、処理を終了する。

分散領域移行条件を満たすと判定された場合、エントリ配置管理部１４２は、バリュー１９２を共有領域１７２から分散領域１７１に移行する（ステップＳ２１０４）。このとき、エントリ配置管理部１４２には、エントリ１９１にバリュー１９２が設定される。なお、エントリ１９１にバリュー１９２が設定されなくてもよい。この場合、エントリ配置管理部１４２が、分散領域１７１に格納されるバリュー１９２へのポインタを生成し、生成されたポインタをエントリ配置管理部１４２に設定してもよい。

エントリ配置管理部１４２は、アクセス統計情報１７０１のリセット処理を実行して（ステップＳ２１０５）、処理を終了する。なお、アクセス統計情報１７０１のリセット処理は必ず実行する必要は無く、必要な場合にのみ実行すればよい。

ステップＳ２１０１において、バリューが共有領域１７２に格納されていないと判定された場合、エントリ配置管理部１４２は、エントリ１９１を参照してアクセス統計情報１７０１を取得し、分散領域移行条件を満たすか否かを判定する（ステップＳ２１０６）。

具体的には、エントリ配置管理部１４２は、エントリ１９１のアクセス統計情報ポインタ１８０１を参照してアクセス統計情報１７０１を取得する。エントリ配置管理部１４２は、移行条件情報１７０２と、取得されたアクセス統計情報１７０１とを参照して、分散領域移行条件を満たすか否かを判定する。これは、仮に分散領域移行条件と、共有領域移行条件とが同時に満たされた場合に、現在格納されている分散領域１７１を優先して使用するための判定処理である。

分散領域移行条件を満たすと判定された場合、エントリ配置管理部１４２は、処理を終了する。

分散領域移行条件を満たさないと判定された場合、エントリ配置管理部１４２は、エントリ１９１を参照してアクセス統計情報１７０１を取得し、共有領域移行条件を満たすか否かを判定する（ステップＳ２１０７）。ステップＳ２１０７の処理は、ステップＳ２１０６の処理と同様の処理であるため説明を省略する。

共有領域移行条件を満たさないと判定された場合、エントリ配置管理部１４２は、処理を終了する。

共有領域移行条件を満たすと判定された場合、エントリ配置管理部１４２は、バリュー１９２を分散領域１７１から共有領域１７２に移行し（ステップＳ２１０８）、ステップＳ２１０５に進む。このとき、エントリ配置管理部１４２は、共有領域１７２に格納された共有バリュー１９２へアクセスするための情報を生成し、エントリ１９１の格納位置情報７０３に生成された情報を設定する。

以上の処理によって、同一のデータソースのレコードから生成されたエントリ１９１が複数ある場合に、エントリ１９１の利用状況に応じて最適な分散メモリキャッシュに配置することが可能になる。

第３の実施形態におけるエントリの移行を実現するための構成としては以下のようなものが考えられる。

図２２及び図２３は、本発明の第３の実施形態におけるエントリ１９１の論理的なデータ構成の一例を示す説明図である。

図２２は、同一のデータソース１１７のレコードから生成されたエントリが二つあり、かつ、バリューが共有されない場合のエントリ１９１のデータ構成を示す。図２３は、同一のデータソースのレコードから生成されたエントリが二つあり、かつ、バリューが共有されている場合のエントリ１９１のデータ構成を示す説明図である。

なお、図２２及び図２３に示すようなエントリ１９１の生成方法は、第１の実施形態におけるロード処理と同一であるため説明を省略する。

第３の実施形態によれば、分散メモリキャッシュにおけるエントリへのアクセス統計情報に基づいて、分散領域と共有領域との間のバリューの移行処理を自動化することができる。これによって、バリューの配置場所が設定されていない場合であっても、適切な記憶領域にバリューを配置することができる。

１０１ ホストコンピュータ
１０２ ホストコンピュータ
１０３ ストレージ装置
１０４ ネットワーク
１０５ 共有ストレージ装置
１２１ データソース管理部
１３１ ローダ部
１４１ 分散メモリキャッシュ管理部
１４２ エントリ配置管理部
１４３ 共有領域アクセス管理部
１４４ 共有バリュー管理情報
１４５ 共有領域管理情報
１６１ アプリケーションプログラム（ＵＡＰ）
１７１ 分散領域
１７２ 共有領域
１８１ 分散メモリキャッシュ構成情報
１８２ データソース情報
１８３ 対応情報
１９１ エントリ
１９２ バリュー
１７０１ アクセス統計情報
１７０２ 移行条件情報

Claims (15)

1. 第１のプロセッサ、前記第１のプロセッサに接続される第１のメモリ及び前記第１のプロセッサに接続される第１のネットワークインタフェースを有し、データを格納する複数の第１の計算機と、第２のプロセッサ、前記第２のプロセッサに接続される第２のメモリ及び前記第２のプロセッサに接続される第２のネットワークインタフェースを有し、前記複数の第１の計算機の各々に格納されるデータを管理する第２の計算機と、を備える計算機システムであって、
   前記計算機システムは、前記複数の第１の計算機が提供する記憶領域を統合して生成されたストレージを備え、
   前記第２の計算機は、
   複数のレコードを含むファイルを分割して、検索キーと、前記レコードの内容を示すバリューとを対応づけた分割データを前記ストレージに分散して格納するローダ処理部、及び、前記ファイルを格納するファイル格納部を有し、
   前記ストレージを構成する前記記憶領域の情報を含むストレージ構成情報、及び、前記ストレージに格納される前記分割データと前記ファイルとの対応関係を管理する対応情報を格納し、
   前記複数の第１の計算機の各々は、
   ファイルデータ単位のデータを処理するアプリケーション、及び、前記ストレージを管理するストレージ管理部を有し、
   前記分割データを管理する分割データ管理情報を格納し、
   前記ストレージは、第１のファイルのバリューにアクセスするための第１のアクセス情報と、第１の検索キーとを含む第１の分割データ、及び、前記第１のファイルのバリューを格納し、
   前記第２の計算機は、
   前記アプリケーションから、第２の検索キーの情報を含む第１のファイルの前記分割データの配置要求を受け付けた場合に、前記アプリケーションから指定された前記第２の検索キーを生成し、
   前記第１のファイルのバリューが複数の前記アプリケーションによって共有される共有バリューであるか否かを判定し、
   前記第１のファイルのバリューが共有バリューであると判定された場合、前記第２の検索キーと前記第１のアクセス情報とを含む第２の分割データを前記ストレージに格納することを特徴とする計算機システム。
2. 前記ストレージは、前記複数の第１の計算機の各々が管理する第１のストレージ領域と、前記全ての第１の計算機によって共有される第２のストレージ領域とを含み、
   前記第２の計算機は、
   前記分割データを前記第１のストレージ領域に格納し、
   前記ファイルのバリューが共有バリューでない場合には、前記分割データのソースであるファイルのバリューを前記第１のストレージ領域に格納し、
   前記ファイルのバリューが共有バリューである場合には、前記分割データのソースであるファイルのバリューを前記第２のストレージ領域に格納することを特徴とする請求項１に記載の計算機システム。
3. 前記第２の計算機は、
   前記第１の分割データ、及び、前記第１のファイルのバリューが前記第１のストレージ領域に格納され、前記第１のファイルのバリューが共有バリューであると判定された場合に、前記第１のファイルのバリューを前記第１のストレージ領域から前記第２のストレージ領域に移行し、
   前記第２のストレージ領域に格納される前記第１のファイルのバリューにアクセスするための第２のアクセス情報を生成し、
   前記第１の分割データの前記第１のアクセス情報を前記第２のアクセス情報に更新し、
   前記第２の検索キーと前記第２のアクセス情報とを含む前記第２の分割データを前記第１のストレージ領域に格納することを特徴とする請求項２に記載の計算機システム。
4. 前記複数の第１の計算機の各々は、前記バリューに対するアクセスを監視するアクセス統計情報と、前記ファイルのバリューの格納場所の移行条件に関する移行条件情報とを格納し、
   前記複数の第１の計算機の各々は、
   前記第１のファイルのバリューが前記第１のストレージ領域に格納されている場合に、前記第１のファイルのバリューに対応する前記アクセス統計情報を取得し、
   前記移行条件情報と前記取得されたアクセス統計情報とに基づいて、前記第１のファイルのバリューを前記第２のストレージ領域に移行するか否かを判定し、
   前記第１のファイルのバリューを前記第２のストレージ領域に移行すると判定された場合に、前記第１のファイルのバリューを前記第２のストレージ領域に移行し、
   移行後の前記第２のストレージ領域に格納される前記第１のファイルのバリューにアクセスするための第３のアクセス情報を生成し、前記第１の分割データの前記第１のアクセス情報を前記第３のアクセス情報に更新することを特徴とする請求項３に記載の計算機システム。
5. 前記複数の第１の計算機の各々は、
   前記第１のファイルのバリューが前記第２のストレージ領域に格納されている場合に、前記第１のファイルのバリューに対応する前記アクセス統計情報を取得し、
   前記移行条件情報と前記取得されたアクセス統計情報とに基づいて、前記第１のファイルのバリューを前記第１のストレージ領域に移行するか否かを判定し、
   前記第１のファイルのバリューを前記第１のストレージ領域に移行すると判定された場合に、前記第１のファイルのバリューを前記第１のストレージ領域に移行し、
   移行後の前記第１のストレージ領域に格納される前記第１のファイルのバリューにアクセスするための第４のアクセス情報を生成し、前記第１の分割データの前記第２のアクセス情報を前記第４のアクセス情報に更新することを特徴とする請求項４に記載の計算機システム。
6. 前記第２の計算機は、
   前記第１のアプリケーションから、前記第１の分割データの削除要求を受信した場合に、前記第１のファイルのバリューが共有バリューであるか否かを判定し、
   前記第１のファイルのバリューが共有バリューでないと判定された場合、前記第１のファイルのバリューの更新結果を前記ファイル格納部に格納される前記第１のファイルに反映し、
   前記第１のストレージ領域に格納される前記第１の分割データ及び第１のファイルバリューを削除し、
   前記第１のファイルのバリューが共有バリューであると判定された場合、前記第１のストレージ領域から前記第１の分割データを削除することを特徴とする請求項３に記載の計算機システム。
7. 前記第１のファイルのバリューが共有バリューであると判定された場合に、さらに、前記第１のファイルのバリューが一つの前記アプリケーションからのみアクセスされるか否かを判定し、
   前記第１のファイルのバリューが一つの前記アプリケーションからのみアクセスされると判定された場合には、前記第１のファイルのバリューを前記第２のストレージ領域から前記第１のストレージ領域に移行し、
   移行後の前記第１のストレージ領域に格納された前記第１ファイルのバリューにアクセスするための第５のアクセス情報を生成し、他の前記分割データの前記第２のアクセス情報を前記第５のアクセス情報に更新することを特徴とする請求項６に記載の計算機システム。
8. 前記第１のファイルのバリューが前記共有バリューであるか否かを判定する場合に、前記配置要求に前記第１のファイルのバリューの格納先として前記第２のストレージ領域が指定されているか否かを判定することを特徴とする請求項２に記載の計算機システム。
9. 前記計算機システムは、全ての前記第１の計算機が接続可能な外部記憶装置を備え、
   前記外部記憶装置上に前記第２のストレージ領域が構成されることを特徴とする請求項２に記載の計算機システム。
10. 前記第２のストレージ領域に格納された前記バリューにアクセスするためのアクセス情報は、前記共有バリューの識別情報であり、
    前記第２のストレージ領域には、前記共有バリューの識別情報と前記共有バリューとが対応づけられた前記分割データが格納されることを特徴とする請求項２に記載の計算機システム。
11. 第１のプロセッサ、前記第１のプロセッサに接続される第１のメモリ及び前記第１のプロセッサに接続される第１のネットワークインタフェースを有し、データを格納する複数の第１の計算機と、第２のプロセッサ、前記第２のプロセッサに接続される第２のメモリ及び前記第２のプロセッサに接続される第２のネットワークインタフェースを有し、前記複数の第１の計算機の各々に格納されるデータを管理する第２の計算機と、を備える計算機システムにおけるデータ管理方法であって、
    前記計算機システムは、前記複数の第１の計算機が提供する記憶領域を統合して生成されたストレージを備え、
    前記第２の計算機は、
    複数のレコードを含むファイルを分割して、検索キーと、前記レコードの内容を示すバリューとを対応づけた分割データを前記ストレージに分散して格納するローダ処理部、及び、前記ファイルを格納するファイル格納部を有し、
    前記ストレージを構成する前記記憶領域の情報を含むストレージ構成情報、及び、前記ストレージに格納される前記分割データと前記ファイルとの対応関係を管理する対応情報を格納し、
    前記複数の第１の計算機の各々は、
    ファイルデータ単位のデータを処理するアプリケーション、及び、前記ストレージを管理するストレージ管理部を有し、
    前記分割データを管理する分割データ管理情報を格納し、
    前記ストレージは、第１のファイルのバリューにアクセスするための第１のアクセス情報と、第１の検索キーとを含む第１の分割データ、及び、前記第１のファイルのバリューを格納し、
    前記方法は、
    前記第２の計算機が、前記アプリケーションから、第２の検索キーの情報を含む第１のファイルの前記分割データの配置要求を受け付けた場合に、前記アプリケーションから指定された前記第２の検索キーを生成する第１のステップと、
    前記第２の計算機が、前記第１のファイルのバリューが複数の前記アプリケーションによって共有される共有バリューであるか否かを判定する第２のステップと、
    前記第２の計算機が、前記第１のファイルのバリューが共有バリューであると判定された場合、前記第２の検索キーと前記第１のアクセス情報とを含む第２の分割データを前記ストレージに格納する第３のステップと、
    を含むことを特徴とするデータ管理方法。
12. 前記ストレージは、前記複数の第１の計算機の各々が管理する第１のストレージ領域と、前記全ての第１の計算機によって共有される第２のストレージ領域とを含み、
    前記第１のストレージ領域に前記分割データが格納され、
    前記ファイルのバリューが共有バリューでない場合には、前記第２の計算機によって前記第１のストレージ領域に、前記分割データのソースであるファイルのバリューが格納され、
    前記ファイルのバリューが共有バリューである場合には、前記第２の計算機によって前記第２のストレージ領域に、前記分割データのソースであるファイルのバリューが格納されることを特徴とする請求項１１に記載のデータ管理方法。
13. 前記第３のステップは、
    前記第１の分割データ、及び、前記第１のファイルのバリューが前記第１のストレージ領域に格納され、前記第１のファイルのバリューが共有バリューであると判定された場合に、前記第１のファイルのバリューを前記第１のストレージ領域から前記第２のストレージ領域に移行するステップと、
    前記第２のストレージ領域に格納される前記第１のファイルのバリューにアクセスするための第２のアクセス情報を生成するステップと、
    前記第１の分割データの前記第１のアクセス情報を前記第２のアクセス情報に更新するステップと、
    前記第２の検索キーと前記第２のアクセス情報とを含む前記第２の分割データを前記第１のストレージ領域に格納するステップと、
    を含むことを特徴とする請求項１２に記載のデータ管理方法。
14. 前記複数の第１の計算機の各々は、前記バリューに対するアクセスを監視するアクセス統計情報と、前記ファイルのバリューの格納場所の移行条件に関する移行条件情報とを格納し、
    前記方法は、さらに、
    前記複数の第１の計算機の各々が、前記第１のファイルのバリューが前記第１のストレージ領域に格納されている場合に、前記第１のファイルのバリューに対応する前記アクセス統計情報を取得するステップと、
    前記複数の第１の計算機の各々が、前記移行条件情報と前記取得されたアクセス統計情報とに基づいて、前記第１のファイルのバリューを前記第２のストレージ領域に移行するか否かを判定するステップと、
    前記複数の第１の計算機の各々が、前記第１のファイルのバリューを前記第２のストレージ領域に移行すると判定された場合に、前記第１のファイルのバリューを前記第２のストレージ領域に移行するステップと、
    前記複数の第１の計算機の各々が、移行後の前記第２のストレージ領域に格納される前記第１のファイルのバリューにアクセスするための第３のアクセス情報を生成し、前記第１の分割データの前記第１のアクセス情報を前記第３のアクセス情報に更新するステップと、
    を含み、
    前記複数の第１の計算機の各々が、前記第１のファイルのバリューが前記第２のストレージ領域に格納されている場合に、前記第１のファイルのバリューに対応する前記アクセス統計情報を取得するステップと、
    前記複数の第１の計算機の各々が、前記移行条件情報と前記取得されたアクセス統計情報とに基づいて、前記第１のファイルのバリューを前記第１のストレージ領域に移行するか否かを判定するステップと、
    前記複数の第１の計算機の各々が、前記第１のファイルのバリューを前記第１のストレージ領域に移行すると判定された場合に、前記第１のファイルのバリューを前記第１のストレージ領域に移行するステップと、
    前記複数の第１の計算機の各々が、移行後の前記第１のストレージ領域に格納される前記第１のファイルのバリューにアクセスするための第４のアクセス情報を生成し、前記第１の分割データの前記第２のアクセス情報を前記第４のアクセス情報に更新するステップと、
    を含むことを特徴とする請求項１３に記載のデータ管理方法。
15. 前記方法は、さらに、
    前記第２の計算機が、前記第１のアプリケーションから前記第１の分割データの削除要求を受信した場合に、前記第１のファイルのバリューが共有バリューであるか否かを判定するステップと、
    前記第２の計算機が、前記第１のファイルのバリューが共有バリューでないと判定された場合、前記第１のファイルのバリューの更新結果を前記ファイル格納部に格納される前記第１のファイルに反映するステップと、
    前記第２の計算機が、前記第１のストレージ領域に格納される前記第１の分割データ及び第１のファイルバリューを削除するステップと、
    前記第２の計算機が、前記第１のファイルのバリューが共有バリューであると判定された場合、前記第１のファイルのバリューが一つの前記アプリケーションからのみアクセスされるか否かを判定するステップと、
    前記第２の計算機が、前記第１のファイルのバリューが一つの前記アプリケーションからのみアクセスされると判定された場合には、前記第１のファイルのバリューを前記第２のストレージ領域から前記第１のストレージ領域に移行するステップと、
    前記第２の計算機が、移行後の前記第１のストレージ領域に格納された前記第１ファイルのバリューにアクセスするための第５のアクセス情報を生成し、他の前記分割データの前記第２のアクセス情報を前記第５のアクセス情報に更新するステップと、
    前記第２の計算機が、前記第１のストレージ領域から前記第１の分割データを削除するステップと、
    を含むことを特徴とする請求項１３に記載のデータ管理方法。

Images