WO2015097774A1

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

Info

Publication number: WO2015097774A1
Application number: PCT/JP2013/084631
Authority: WO
Inventors: 鵜飼　敏之
Original assignee: 株式会社日立製作所
Priority date: 2013-12-25
Filing date: 2013-12-25
Publication date: 2015-07-02
Also published as: US20160012075A1; US9934248B2; JPWO2015097774A1; JP6034512B2

Abstract

　ネットワークを介して接続される複数の計算機を備える計算機システムであって、複数の計算機の各々は、複数のレコードを含むファイルを一以上格納するストレージ装置と接続し、ファイルシステムと、キーバリュー型データ管理部と、ローダとを有し、検索キー、バリューのサイズ、及びレコードのファイルにおける位置が対応付けられたキーバリュー型データ構造情報を保持し、ローダは、永続化指示を受け付けた場合、更新されたキーバリュー型データを反映させる処理対象のファイルを特定し、処理対象のファイルを格納するストレージ装置と接続する計算機を特定し、計算機に更新されたキーバリュー型データを含むファイルの更新要求を送信し、ファイルシステムは、キーバリュー型データ構造情報に基づいて、更新されたキーバリュー型データに対応するレコードのファイルにおける位置を特定し、更新されたキーバリュー型データを書き込む。

Description

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

　本発明は、分散ＫＶＳが適用された計算機システムに関する。

　近年、計算機システムにおいてアプリケーションプログラムが処理すべきデータ量は爆発的に増えてきている。多数のサーバを使って大量のデータを高速に処理するための技術として、分散メモリキャッシュ技術が知られている（例えば、特許文献１）。分散メモリキャッシュ技術は、複数のサーバのメモリを統合して、大量のデータを格納するメモリ空間（メモリストア）を構成する技術である。複数のサーバへのデータの分割配置による処理の並列化と、メモリにデータを保持することによる入出力の高速化とを実現することができる。

　分散メモリキャッシュ技術では、大量のデータを複数のサーバに分散させるために、キー・バリュー型データ形式のデータを扱う分散キーバリューストア（分散ＫＶＳ）が採用される。キー・バリュー型データは、データの識別子であるキーと、データの本体であるバリュー（値）とを対応づけたデータ構造であり、［キー、バリュー］の組合わせで管理される。

　例えば、複数のレコードから構成されるファイルに分散ＫＶＳを採用する場合、一つのレコードから一つキー・バリュー型データが生成され、キーの範囲（キーレンジ）に応じてキー・バリュー型データが複数のサーバに分割配置される。各サーバ上で稼動するアプリケーションは分割配置されたキー・バリュー型データを並列に処理することによって処理の高速化を実現できる。

　特許文献１には、「分散メモリストレージ管理部が定義情報に従ってファイルを断片化し、各断片を複数の物理メモリ領域を統合して構成される分散メモリストレージに分割配置する。分散メモリストレージアクセス部はＵＡＰからファイルへのアクセス要求を受け付け、ファイル管理情報を参照して自ホスト計算機の物理メモリ領域に断片化して配置された断片へのアクセスを実行する」ことが記載されている。

特開２０１１－１９１８３５号公報

　ファイル（データソース）に対する処理を高速化するために、キー・バリュー型データをキャッシュとして利用することが考えられる。しかし、キー・バリュー型データのソースデータであるファイルを管理するファイルシステム等と、キー・バリュー型データを管理する分散ＫＶＳ管理部等との連携が希薄であるという問題がある。

　分散ＫＶＳでは、キー・バリュー型データの生成時にファイルのレコード構造等の情報が失われるため、キー・バリュー型データをそのままファイルに反映することができない。したがって、分散ＫＶＳにおいて、ストレージ装置はメモリストアのキャッシュ又は冗長化のためのデータのコピーを格納する記憶領域として用いられるため、キー・バリュー型データがそのままストレージ装置に格納される。

　すなわち、従来技術では、キー・バリュー型データとデータソースとが対応付けて管理されていないため、キー・バリュー型データの更新をデータソースに反映するような仕組みは提供されていない。

　また、キー・バリュー型データの格納場所とファイルの格納場所とが対応づけられていないため、分散ファイルシステムによって管理される分散ファイルに分散ＫＶＳを採用した場合、サーバ間の通信負荷が増大するという問題がある。より具体的には、複数のサーバに配置される分散ファイルからキー・バリュー型データを生成し、又は、キー・バリュー型データを分散ファイルに反映する場合、複数のサーバの各々が、キー・バリュー型データの配置又は分散ファイルの配置を把握するために頻繁に通信を行う必要があり、サーバ間の通信負荷が増大するという問題がある。

　本発明は、前述した課題に鑑みてなされた発明である。データソースとキー・バリュー型データとを対応付けて管理することによって、更新されたキー・バリュー型データをデータソースに反映する仕組みを提供する。すなわち、ファイルＩ／Ｏ　ＡＰＩ及びキー・バリュー型データＡＰＩのいずれでも同一の内容のデータにアクセス可能な仕組みを提供する。また、データソースとキー・バリュー型データとを対応付けて管理することによって、分散ファイルに分散ＫＶＳを採用する場合に、サーバ間の通信負荷を抑える仕組みを提供する。

　本発明の代表的な一例を示せば以下の通りである。すなわち、ネットワークを介して接続される複数の計算機を備える計算機システムであって、前記複数の計算機の各々は、プロセッサ、前記プロセッサに接続されるメモリ及び前記プロセッサに接続されるネットワークインタフェースを有し、複数のレコードを含むファイルを一以上格納するストレージ装置と接続し、前記ストレージ装置に格納される前記ファイルを管理するファイルシステムと、前記複数の計算機が有する記憶領域を統合することによってデータ格納領域を一つ以上生成し、前記データ格納領域に配置されたキーバリュー型データを管理するキーバリュー型データ管理部と、前記ファイルを分割して、検索キーと前記レコードの内容を示すバリューとを対応づけることによって前記キーバリュー型データを生成し、前記生成されたキーバリュー型データを前記データ格納領域に分散して格納するローダと、を有し、前記キーバリュー型データ毎に、前記検索キー、前記バリューのサイズ、及び前記キーバリュー型データに対応する前記レコードのファイルにおける位置が対応付けられたキーバリュー型データ構造情報を保持し、前記ローダは、更新された前記キーバリュー型データの前記ファイルへの反映を指示する永続化指示を受け付けた場合、前記複数の計算機の各々の前記キーバリュー型データ管理部に、前記更新されたキーバリュー型データを取得するための読出要求を送信し、前記キーバリュー型データ管理部は、前記読出要求を受信した場合、前記データ格納領域を構成する前記記憶領域に格納される前記キーバリュー型データの中から前記更新されたキーバリュー型データを検索し、前記読出要求を送信した前記ローダに前記更新されたキーバリュー型データを送信し、前記ローダは、前記複数の計算機の各々のキーバリュー型データ管理部から取得された前記更新されたキーバリュー型データに基づいて、前記更新されたキーバリュー型データを反映させる処理対象のファイルを特定し、前記処理対象のファイルを格納する前記ストレージ装置と接続する前記計算機を特定し、前記特定された計算機に、前記更新されたキーバリュー型データを含むファイルの更新要求を送信し、前記ファイルシステムは、前記ファイルの更新要求を受信した場合、前記キーバリュー型データ構造情報に基づいて、前記更新されたキーバリュー型データに対応する前記レコードの前記ファイルにおける位置を特定し、前記特定されたファイルの位置に、前記更新されたキーバリュー型データを書き込むことによって前記ファイルを更新することを特徴とする。

　本発明によれば、キーバリュー型データ管理部がキーバリュー型データ構造情報に基づいて、ファイルとキー・バリュー型データとを対応付けて管理することができ、また、更新されたキーバリュー型データをファイルに反映することができる。したがって、ファイルＩ／Ｏ　ＡＰＩ及びキー・バリュー型データＡＰＩのいずれでも同一の内容のデータにアクセスすることができる。

　上記した以外の課題、構成及び効果は、以下の実施例の説明により明らかにされる。

本発明の実施例１における計算機システムの構成例を示すブロック図である。本発明の実施例１におけるファイルの構成例を示す説明図である。本発明の実施例１におけるＫＶ型データの構成例を示す説明図である。本発明の実施例１におけるファイル管理情報の一例を示す説明図である。本発明の実施例１におけるレコード定義情報の構成例を示す説明図である。本発明の実施例１におけるＵＡＰのソースプログラムの一例を示す説明図である。本発明の実施例１のＫＶ型データ管理情報及びＫＶ型データの一例を示す説明図である。本発明の実施例１のファイル配置情報の一例を示す説明図である。本発明の実施例１のＫＶ型データ構造情報の一例を示す説明図である。本発明の実施例１におけるロード処理を説明するフローチャートである。本発明の実施例１におけるＫＶ型データの更新処理を説明するフローチャートである。本発明の実施例１のＫＶ型データ永続化処理の流れを説明するシーケンス図である。本発明の実施例１における実行サーバ判定処理の一例を説明するフローチャートである。本発明の実施例１のレコード更新処理の一例を説明するフローチャートである。本発明の実施例１の変形例におけるファイル構成情報の一例を示す説明図である。本発明の実施例１の変形例におけるファイル構成情報の登録処理の一例を説明するフローチャートである。本発明の実施例１の変形例におけるロード処理の一例を説明するフローチャートである。本発明の実施例２における計算機システムの構成例を示すブロック図である。本発明の実施例２におけるファイル管理情報の一例を示す説明図である。本発明の実施例２のＫＶ型データ永続化処理の流れを説明するシーケンス図である。本発明の実施例２におけるローダ決定処理の一例を説明するフローチャートである。本発明の実施例２における一時リストの一例を説明する説明図である。本発明の実施例２における実行サーバ判定処理の一例を説明するフローチャートである。本発明の実施例２のレコード更新処理の一例を説明するフローチャートである。

　以下、実施例を図面を参照して詳細に説明する。

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

　実施例１の計算機システムは、サーバ１０１、複数の分散ＫＶＳサーバ１０２、及びストレージ装置１０４、１０５から構成される。

　サーバ１０１は、ネットワーク１０３を介して複数の分散ＫＶＳサーバ１０２の各々と接続される。ネットワーク１０３は、ＬＡＮ及びＷＡＮ等が考えられるが、本発明はネットワーク１０３の種別に限定されない。

　分散ＫＶＳサーバ１０２は、キー・バリュー・ストア（ＫＶＳ）を構成する計算機である。各分散ＫＶＳサーバ１０２は、データソース（ファイル１８１）が格納されるストレージ装置１０５と接続する。ストレージ装置１０５は、例えば、ＨＤＤ等の不揮発性記憶媒体を複数備えるストレージシステム、フラッシュメモリを記憶媒体として用いた半導体ディスク装置及び光ディスク装置等が考えられる。

　以下の説明では、「分散ＫＶＳサーバ１０２が管理するファイル１８１」との表現は、分散ＫＶＳサーバ１０２と接続されるストレージ装置１０５に格納されるファイル１８１を表すものとする。また、「ファイル１８１を管理する分散ＫＶＳサーバ１０２」との表現は、ファイル１８１を格納するストレージ装置１０５と接続される分散ＫＶＳサーバ１０２を表すものとする。

　本実施例では、複数の分散ＫＶＳサーバ１０２の各々が備える記憶領域を統合することによって、一つ以上のキャッシュ領域１６１が生成される。キャッシュ領域１６１には、ファイル１８１から生成されたキー・バリュー型データ１７１が格納される。以下の説明では、キー・バリュー型データ１７１をＫＶ型データ１７１とも記載する。

　ここで、ファイル１８１とＫＶ型データ１７１との関係について説明する。

　図２は、本発明の実施例１におけるファイル１８１の構成例を示す説明図である。図３は、本発明の実施例１におけるＫＶ型データ１７１の構成例を示す説明図である。

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

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

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

　一方、ＫＶ型データ１７１は、ＫＶ型データヘッダ情報３０１、キー３０２、及びバリュー３０３から構成される。

　ＫＶ型データヘッダ情報３０１は、ＫＶ型データの構成、及び同一ファイルから生成された他のＫＶ型データとの関係を示す情報である。ＫＶ型データヘッダ情報３０１の詳細は図９を用いて説明する。キー３０２は、検索キーとなる情報である。バリュー３０３は、ＫＶ型データのデータ本体である。

　ＵＡＰ１４１は、ファイル１８１又はＫＶ型データ１７１を用いて所定の処理を実行する。本実施例では、ファイル１８１は、レコード単位に分割され、一つのレコードについて、任意のフィールドをキーとしてレコード本体をバリューとするＫＶ型データが生成される。図１の説明に戻る。

　キャッシュ領域１６１は、分散ＫＶＳサーバ１０２から共有デバイスと同様にアクセスすることが可能である。また、レコード単位に分割されたファイル１８１のデータ、すなわち、ＫＶ型データ１７１は、複数の分散ＫＶＳサーバ１０２上に配置される。各ＵＡＰ１４１は、それぞれ、自身が稼働する分散ＫＶＳサーバ１０２上に配置されたＫＶ型データ１７１を用いて処理を実行する。

　前述したように、複数のＵＡＰ１４１の各々が、複数のＫＶ型データ１７１を並列に処理することによって、一つのＵＡＰ１４１が処理するデータ量を削減することができる。したがって、処理の高速化を実現できる。

　また、本実施例では処理の対象のデータソースとしてファイル１８１を例に説明するが、本発明はこれに限定されず、データの格納形式は特に問わない。

　サーバ１０１は、プロセッサ１１１、メモリ１１２、及びインタフェース（Ｉ／Ｆ）１１３－１、１１３－２を備える。サーバ１０１は、インタフェース１１３－１を介してストレージ装置１０４と接続され、また、インタフェース１１３－２を介して複数の分散ＫＶＳサーバ１０２と接続される。

　プロセッサ１１１は、メモリ１１２に格納されるプログラムを実行する。プロセッサ１１１が、メモリ１１２に格納されるプログラムを実行することによって、サーバ１０１の機能が実現される。

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

　本実施例のメモリ１１２は、ファイルシステム１３１を実現するプログラムを格納する。ファイルシステム１３１は、ファイル単位のデータを管理する。本実施例のファイルシステム１３１は、各分散ＫＶＳサーバ１０２に接続されるストレージ装置１０５に格納されるファイル１８１を一元管理する。

　ストレージ装置１０４は、各種情報を格納し、例えば、ＨＤＤ等の記憶媒体を複数備えるストレージシステム、フラッシュメモリを記憶媒体として用いた半導体ディスク装置及び光ディスク装置等が考えられる。本実施例のストレージ装置１０４には、複数のファイル管理情報１３２、及び複数のレコード定義情報１３３が格納される。

　ファイル管理情報１３２は、ファイル１８１のメタデータ等の管理情報を格納する。一つのファイル１８１に対して一つのファイル管理情報１３２が存在する。レコード定義情報１３３は、ファイル１８１を構成するレコードの管理情報を格納する。レコード定義情報１３３は、一つのファイル管理情報１３２と対応付けられて管理される。ファイル管理情報１３２及びレコード定義情報１３３の詳細は、図４、図５及び図６を用いて後述する。

　分散ＫＶＳサーバ１０２は、プロセッサ１２１、メモリ１２２、及びインタフェース（Ｉ／Ｆ）１２３－１、１２３－２を備える。分散ＫＶＳサーバ１０２は、インタフェース１２３－１を介してサーバ１０１及び他の分散ＫＶＳサーバ１０２と接続される。また、分散ＫＶＳサーバ１０２は、インタフェース１２３－２を介してストレージ装置１０５と接続される。

　本実施例では、各分散ＫＶＳサーバ１０２は同一の構成であるものとして説明するが、以下に説明する機能及び処理を実現できるものであれば、必ずしも同一の構成でなくてもよい。

　プロセッサ１２１は、メモリ１２２に格納されるプログラムを実行する。プロセッサ１２１が、メモリ１２２に格納されたプログラムを実行することによって後述する分散ＫＶＳサーバ１０２の機能が実現される。

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

　本実施例のメモリ１２２は、ＵＡＰ（ユーザアプリケーションプログラム）１４１、並びに、分散ＫＶＳ管理部１４２、ローダ１４３、及びファイルシステム１４４を実現するプログラムを格納する。また、メモリ１２２は、ＫＶ型データ管理情報１５１、ファイル配置情報１５２、及びＫＶ型データ構造情報１５３を格納する。

　ＵＡＰ１４１は、各種処理を実行する。ファイルシステム１４４は、ファイルシステム１３１と同一のものである。分散ＫＶＳ管理部１４２は、他の分散ＫＶＳサーバ１０２の分散ＫＶＳ管理部１４２と協調して、キャッシュ領域１６１を管理する。また、分散ＫＶＳ管理部１４２は、キャッシュ領域１６１へのアクセスを制御する。ローダ１４３は、ストレージ装置１０５に格納されるファイル１８１からＫＶ型データ１７１を生成し、ＫＶ型データ１７１をキャッシュ領域１６１に分散配置し、また、キャッシュ領域１６１に格納されるＫＶ型データ１７１をストレージ装置１０５に格納する。

　以下の説明では、ストレージ装置１０５に格納されるファイル１８１をキャッシュ領域１６１に分散して配置する処理をロード処理と記載する。また、キャッシュ領域１６１に格納されるＫＶ型データ１７１を、ストレージ装置１０５へ格納する処理をアンロード処理と記載する。

　ＫＶ型データ管理情報１５１は、キャッシュ領域１６１を構成する分散ＫＶＳサーバ１０２の記憶領域に格納されるＫＶ型データ１７１を管理するための情報である。ファイル配置情報１５２は、キャッシュ領域１６１及びファイル１８１の対応関係を管理するための情報である。ＫＶ型データ構造情報１５３は、ファイル１８１のレコード及びＫＶ型データ１７１の対応関係を管理するための情報である。

　ＫＶ型データ管理情報１５１、ファイル配置情報１５２、及びＫＶ型データ構造情報１５３の詳細については、図７、図８、及び図９を用いて後述する。

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

　なお、ファイルシステム１３１、１４４、分散ＫＶＳ管理部１４２は、図示しないオペレーティングシステム（ＯＳ）の一部、又は、図示しないユーザアプリケーションプログラムによって使用される入出力ライブラリとして提供されてもよい。

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

　なお、サーバ１０１は分散ＫＶＳサーバ１０２であってもよい。この場合、少なくとも一つの分散ＫＶＳサーバ１０２がファイル管理情報１３２及びレコード定義情報１３３を保持すればよい。また、図１では全ての分散ＫＶＳサーバ１０２がローダ１４３を備えているが、本発明はこれに限定されず、少なくとも一つの分散ＫＶＳサーバ１０２がローダ１４３を備えていればよい。

　図４は、本発明の実施例１におけるファイル管理情報１３２の一例を示す説明図である。

　ファイル管理情報１３２は、ファイルＩＤ４０１、パーミション４０２、オーナ４０３、サイズ４０４、タイムスタンプ４０５、レコード定義情報へのポインタ４０６、及び格納場所情報４０７を含む。

　ファイルＩＤ４０１は、ストレージ装置１０５に格納されるファイル１８１の識別情報を格納する。ファイルＩＤ４０１には、ファイル１８１を一意に識別できる情報であればどのような情報が格納されてもよい。例えば、フルパスのファイル名又はＤＢにおけるテーブル名などが格納される。本実施例ではファイルＩＤ４０１にはファイル名が格納されるものとする。

　パーミション４０２は、ファイル１８１のアクセス権限に関する情報を格納する。オーナ４０３は、ファイル１８１の所有者を示す情報を格納する。サイズ４０４は、ファイル１８１のサイズを示す情報を格納する。タイムスタンプ４０５は、ファイル１８１の更新日時を示す情報を格納する。

　レコード定義情報へのポインタ４０６は、ファイル１８１に対応するレコード定義情報１３３へのポインタを格納する。格納場所情報４０７は、ファイル１８１の格納場所に関する情報を格納する。本実施例では、各分散ＫＶＳサーバ１０２に接続されるストレージ装置１０５に複数のファイル１８１が格納されるため、格納場所情報４０７には、例えば、分散ＫＶＳサーバ１０２の識別子及びストレージ装置１０５の識別情報が格納される。

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

　レコード定義情報１３３は、レコード構成５０１、フィールド構成５０２及びキー・フィールド番号５０３を含む。

　レコード構成５０１は、ファイル１８１におけるレコード構造を把握するための情報を格納し、レコード種別５１１及びレコード長５１２を含む。なお、レコード構成５０１には、レコード種別５１１及びレコード長５１２以外の情報が含まれてもよい。

　レコード種別５１１は、ファイル１８１におけるレコードが固定長レコード又は可変長レコードのいずれであるかを示す情報を格納する。レコード種別５１１に固定長レコードを示す情報が格納される場合、ファイル１８１は、同一かつ所定の長さのレコードから構成される。レコード種別５１１に可変長レコードを示す情報が格納される場合、ファイル１８１は、長さが異なるレコードから構成される。

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

　なお、レコード構成５０１にはレコードの構造を把握することができる情報が含まれていればよく、レコード種別５１１及びレコード長５１２の全ての情報を含む必要はない。フィールド構成５０２は、レコードに含まれるフィールドを識別するための情報を格納するものであり、フィールド数５２１及びフィールド情報５２２を含む。

　フィールド数５２１は、一つのレコードに含まれるフィールドの数を格納する。フィールド情報５２２は、各フィールドに記録されるデータに関する情報を格納し、フィールド種別５３１、サイズ５３２及び記述形式５３３を含む。

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

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

　なお、フィールド構成５０２は、レコードに含まれるフィールドを把握できればよいため、フィールド数５２１、及びフィールド情報５２２のすべての情報を含む必要はない。

　ファイル１８１が固定長レコードから構成される場合、レコード長５１２に設定された値によって個々のレコードを認識することができる。一方、ファイル１８１が可変長レコードから構成される場合、各レコードの先頭には、そのレコードの大きさを記録するフィールドが設けられ、当該フィールドに基づいてレコードの区切れを判定することができる。

　また、レコードが可変長レコードである場合、フィールド構成５０２に格納される情報に基づいて最初のフィールドが識別され、レコードサイズを算出することができる。レコードが認識された後は、フィールド構成５０２のフィールド数５２１、及びフィールド情報５２２のサイズ５３２を参照することによってフィールドを把握できる。

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

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

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

　図７は、本発明の実施例１のＫＶ型データ管理情報１５１及びＫＶ型データ１７１の一例を示す説明図である。

　ＫＶ型データ管理情報１５１は、各分散ＫＶＳサーバ１０２にＫＶ型データ１７１を配置されるときに生成される。このとき、ＫＶ型データリストも生成される。ＫＶ型データリストは、各分散ＫＶＳサーバ１０２に配置されたＫＶ型データ１７１をキーの順番に並べたリストである。また、本実施例では、ＫＶ型データ１７１の更新時にダーティリストが生成又は更新される。分散ＫＶＳ管理部１４２又はローダ１４３等は、ダーティリストに基づいて更新されたＫＶ型データ１７１を把握することができる。

　まず、ＫＶ型データヘッダ情報３０１について説明する。ＫＶ型データヘッダ情報３０１は、フラグ７１１、ｎｅｘｔ７１２、及びダーティリストｎｅｘｔ７１３を含む。

　フラグ７１１は、ＫＶ型データ１７１が更新されたことを示すフラグを格納する。本実施例では、ＫＶ型データ１７１の更新前のフラグ７１１には「０」が設定され、ＫＶ型データ１７１の更新後のフラグ７１１には「１」が設定されるものとする。

　ｎｅｘｔ７１２は、ＫＶ型データリストにおける当該ＫＶ型データ１７１の次のＫＶ型データ１７１へのポインタを格納する。これによって、ＫＶ型データリストに含まれる全てのＫＶ型データ１７１をたどることができる。ダーティリストｎｅｘｔ７１３は、後述するダーティリストにおける当該ＫＶ型データ１７１の次のＫＶ型データ１７１へのポインタを格納する。

　本実施例では、ＫＶ型データリスト及びダーティリストのそれぞれ独立した二つのリストが生成される。ＫＶ型データリストに基づいて、一つのファイル１８１から生成され、分散配置されたＫＶ型データ１７１を把握できる。また、ダーティリストに基づいて、一つのファイル１８１から生成され、分散配置されたＫＶ型データ１７１のうち、更新されたＫＶ型データ１７１を把握できる。

　次に、ＫＶ型データ管理情報１５１について説明する。ＫＶ型データ管理情報１５１は、キャッシュ領域ＩＤ７０１、ファイルＩＤ７０２、ＫＶ型データリストポインタ７０３、及びダーティリストポインタ７０４を含む。

　キャッシュ領域ＩＤ７０１は、キャッシュ領域１６１の識別情報を格納する。ファイルＩＤ７０２は、ＫＶ型データ１７１のソースであるファイル１８１の識別情報を格納する。ＫＶ型データリストポインタ７０３は、ＫＶ型データリストにおける最初のＫＶ型データ１７１へのポインタを格納する。ダーティリストポインタ７０４は、ダーティリストにおける最初のＫＶ型データ１７１へのポインタを格納する。

　図８は、本発明の実施例１のファイル配置情報１５２の一例を示す説明図である。

　ファイル配置情報１５２は、キャッシュ領域１６１毎に、当該キャッシュ領域１６１に格納されるＫＶ型データ１７１のソースであるファイル１８１の情報を格納する。具体的には、ファイル配置情報１５２は、キャッシュ領域ＩＤ８０１、ファイルＩＤ８０２、及び、ＫＶ型データ構造情報へのポインタ８０３を含む。

　キャッシュ領域ＩＤ８０１は、キャッシュ領域１６１を識別するための識別情報を格納する。ファイルＩＤ８０２は、キャッシュ領域ＩＤ８０１に対応するキャッシュ領域１６１にＫＶ型データ１７１として格納されるファイル１８１の識別情報を格納する。本実施例では、ファイル名が格納される。ＫＶ型データ構造情報へのポインタ８０３は、ファイル配置情報１５２のエントリに対応するＫＶ型データ構造情報１５３へのポインタを格納する。

　図９は、本発明の実施例１のＫＶ型データ構造情報１５３の一例を示す説明図である。

　ＫＶ型データ構造情報１５３は、ＫＶ型データ１７１毎に、当該ＫＶ型データ１７１に対応するレコードの構造に関する情報を格納する。具体的には、ＫＶ型データ構造情報１５３は、ＩＤ９０１、キー９０２、バリューサイズ９０３、及びオフセット９０４を含む。

　ＩＤ９０１は、ＫＶ型データ構造情報１５３のエントリを一意に識別するための識別番号を格納する。ＫＶ型データ構造情報１５３のエントリは、ファイルＩＤ８０２に対応するファイル１８１から生成された一つのＫＶ型データ１７１に対応する。

　キー９０２は、ファイルＩＤ８０２に対応するファイル１８１から生成されたＫＶ型データ１７１のキーの情報を格納する。バリューサイズ９０３は、ＫＶ型データ１７１のサイズを格納する。オフセット９０４は、ファイルＩＤ８０２に対応するファイル１８１上の、ＫＶ型データ１７１に対応するレコードの位置を示す情報を格納する。

　図１０は、本発明の実施例１におけるロード処理を説明するフローチャートである。

　ローダ１４３は、ＵＡＰ１４１から任意のファイル１８１のキャッシュ領域１６１へのロード指示を受け付けると処理を開始する。ロード指示には、処理対象のファイル１８１の識別情報（ファイルＩＤ）及びＫＶ型データ１７１のキーとして用いるフィールドの情報が含まれる。また、ロード指示には、ＫＶ型データ１７１を配置するキャッシュ領域１６１の識別情報（キャッシュ領域ＩＤ）も含まれる。

　なお、以下の説明ではＫＶ型データ１７１が配置されるキャッシュ領域１６１が生成されていないものとする。

　ローダ１４３は、処理対象のファイル１８１のファイル管理情報１３２及びレコード定義情報１３３を取得する（ステップＳ１００１）。具体的には以下のような処理が実行される。

　ローダ１４３は、ファイルシステム１４４に処理対象のファイルオープンを指示する。ファイルシステム１４４は、当該ファイルオープンの指示を受け付けると、処理対象のファイルのファイル管理情報１３２及びレコード定義情報１３３のキャッシュを保持しているか否かを判定する。

　処理対象のファイル１８１のファイル管理情報１３２及びレコード定義情報１３３のキャッシュを保持していると判定された場合、ファイルシステム１４４は、ローダ１４３に対して、ファイルオープンに対する戻り値とともに、キャッシュされているファイル管理情報１３２及びレコード定義情報１３３を応答する。

　一方、処理対象のファイルのファイル管理情報１３２及びレコード定義情報１３３のキャッシュを保持していないと判定された場合、ファイルシステム１４４は、サーバ１０１のファイルシステム１３１にファイル管理情報１３２及びレコード定義情報１３３の取得要求を送信する。当該取得要求には、ファイルＩＤが含まれる。

　サーバ１０１のファイルシステム１３１は、ファイルＩＤ４０１が取得要求に含まれるファイルＩＤと一致するファイル管理情報１３２を検索する。ファイルシステム１３１は、検索されたファイル管理情報１３２のレコード定義情報へのポインタ４０６に基づいて、ファイル管理情報１３２に対応するレコード定義情報１３３を取得する。ファイルシステム１３１は、分散ＫＶＳサーバ１０２のファイルシステム１４４に、ファイル管理情報１３２及びレコード定義情報１３３を送信する。

　ファイルシステム１４４は、ファイル管理情報１３２及びレコード定義情報１３３を受信すると、受信したファイル管理情報１３２及びレコード定義情報１３３をキャッシュに保持する。また、ファイルシステム１４４は、ローダ１４３に対して、ファイルオープンに対する戻り値とともに、ファイル管理情報１３２及びレコード定義情報１３３を応答する。

　なお、戻り値としては処理対象のファイル１８１へのアクセスに必要な情報が含まれる。例えば、ファイル管理情報１３２の格納場所情報４０７が戻り値として格納される。以上がステップＳ１００１の処理の説明である。

　次に、ローダ１４３は、取得されたファイル管理情報１３２の格納場所情報４０７に基づいて処理対象のファイル１８１を取得する（ステップＳ１００２）。具体的には、以下のような処理が実行される。

　ローダ１４３は、ファイルシステム１４４にファイルＩＤ及び格納場所情報４０７を含む読出要求を発行する。このとき、ファイルシステム１４４は以下のような処理を実行する。

　ファイルシステム１４４は、ロード処理を実行するローダ１４３が稼働する分散ＫＶＳサーバ１０２が処理対象のファイル１８１を管理しているか否かを判定する。以下の説明では、ロード処理を実行するローダ１４３が稼働する分散ＫＶＳサーバ１０２を自分散ＫＶＳサーバ１０２とも記載する。

　自分散ＫＶＳサーバ１０２が処理対象のファイル１８１を管理する場合、ファイルシステム１４４は、ファイルＩＤ及び格納場所情報４０７に基づいて、自分散ＫＶＳサーバ１０２と接続されるストレージ装置１０５から処理対象のファイル１８１を読み出し、ローダ１４３に応答する。

　一方、自分散ＫＶＳサーバ１０２が処理対象のファイル１８１を管理していない場合、ファイルシステム１４４は、格納場所情報４０７に基づいて、処理対象のファイル１８１を管理する分散ＫＶＳサーバ１０２を特定する。

　さらに、ファイルシステム１４４は、特定された分散ＫＶＳサーバ１０２のファイルシステム１４４に読出要求を送信する。読出要求には、格納場所情報４０７及びファイルＩＤが含まれる。ここでは、読出要求を送信したファイルシステム１４４をリクエスト側ファイルシステム１４４と記載し、読出要求を受信したファイルシステム１４４をレスポンス側ファイルシステム１４４と記載する。

　レスポンス側ファイルシステム１４４は、読出要求を受け付けつけると、当該読出要求に含まれるファイルＩＤ及び格納場所情報４０７に基づいて、ストレージ装置１０５から処理対象のファイル１８１を読み出す。レスポンス側ファイルシステム１４４は、リクエスト側ファイルシステム１４４に、読み出された処理対象のファイル１８１を送信する。リクエスト側ファイルシステム１４４は、ローダ１４３に読み出されたファイル１８１を応答する。以上の処理によって、ローダ１４３は、自分散ＫＶＳサーバ１０２以外の分散ＫＶＳサーバ１０２が管理するファイル１８１を取得できる。以上がステップＳ１００２の説明である。

　次に、ローダ１４３は、分散ＫＶＳ管理部１４２にキャッシュ領域１６１の生成要求を送信する（ステップＳ１００３）。その後、ローダ１４３は、分散ＫＶＳ管理部１４２からの応答を受け付けるまで待ち状態となる。生成要求には、ロード指示に含まれるキャッシュ領域１６１の識別情報を生成要求に含める。

　なお、分散ＫＶＳ管理部１４２は、他の分散ＫＶＳサーバ１０２の分散ＫＶＳ管理部１４２と連携してキャッシュ領域を生成する。キャッシュ領域１６１の生成処理は公知の技術を用いればよいため詳細な説明は省略する。このとき、キャッシュ領域１６１の管理情報（図示省略）もあわせて生成される。キャッシュ領域１６１の管理情報（図示省略）には、キャッシュ領域１６１の識別情報、キャッシュ領域１６１の全容量、分散ＫＶＳサーバ１０２の識別情報、及び当該分散ＫＶＳサーバ１０２におけるキャッシュ領域１６１を構成する記憶領域の容量等が格納される。

　ローダ１４３は、キャッシュ領域１６１が正常に生成されたか否かを判定する（ステップＳ１００４）。例えば、ローダ１４３は、分散ＫＶＳ管理部１４２から生成完了の通知を受けつけた場合、キャッシュ領域１６１が正常に生成されたと判定する。一方、ローダ１４３は、分散ＫＶＳ管理部１４２から生成失敗の通知を受けつけた場合、又は、分散ＫＶＳ管理部１４２から一定時間応答がない場合、キャッシュ領域１６１が正常に生成されなかったと判定する。

　キャッシュ領域１６１が正常に生成されなかったと判定された場合、ローダ１４３は、異常終了する（ステップＳ１０１１）。例えば、ローダ１４３は、ロード処理が失敗した旨をＵＡＰ１４１に通知する。

　キャッシュ領域１６１が正常に生成されたと判定された場合、ローダ１４３は、ファイル配置情報１５２に処理対象のファイル１８１のエントリを登録する（ステップＳ１００５）。具体的には、ローダ１４３は、ファイル配置情報１５２にエントリを追加する。ローダ１４３は、追加されたエントリのキャッシュ領域ＩＤ８０１に新たに生成されたキャッシュ領域１６１の識別情報を設定し、ファイルＩＤ８０２にファイル管理情報１３２のファイルＩＤ４０１に格納される情報を設定する。

　ローダ１４３は、取得されたファイル１８１及びキーとして用いられるフィールドの情報に基づいて、ＫＶ型データ１７１を生成し（ステップＳ１００６）、また、ＫＶ型データ構造情報１５３を生成する（ステップＳ１００７）。具体的には、以下のような処理が実行される。

　ローダ１４３は、レコード定義情報１３３を参照してファイル１８１のレコード構造を把握する。ローダ１４３は、把握したレコードの構造に基づいて、指定されたフィールドからキーを生成し、また、ＫＶ型データ１７１を生成する。

　また、ローダ１４３は、キーの値に基づいてＫＶ型データ１７１を配置する分散ＫＶＳサーバ１０２を決定する。このとき、分散ＫＶＳ管理部１４２は、キーの範囲及び分散ＫＶＳサーバ１０２の識別子が対応付けられるマップを生成する。

　なお、キーの範囲は、例えば、コンシステント・ハッシュ法を用いて決定する方法が考えられる。また、予め、キーの範囲を決定し、キーの範囲に関する情報を保持してもよい。

　ローダ１４３は、生成されたＫＶ型データ１７１の数だけ、ＫＶ型データ構造情報１５３にエントリを生成し、生成されたエントリのＩＤ９０１に「１」から順に識別番号を設定する。

　ローダ１４３は、生成されたＫＶ型データ１７１を一つ選択する。ローダ１４３は、レコード定義情報１３３を参照して、選択されたＫＶ型データ１７１に対応するレコードのデータサイズ、及び処理対象のファイル１８１におけるレコードの位置を特定する。

　ローダ１４３は、空のエントリのキー９０２に選択されたＫＶ型データ１７１のキーを設定し、バリューサイズ９０３にＫＶ型データ１７１のサイズを設定し、また、オフセット９０４にＫＶ型データ１７１に対応するレコードのファイル１８１における位置を示す情報を設定する。以上が、ステップＳ１００６及びステップＳ１００７の処理の説明である。

　ローダ１４３は、キーの範囲にしたがって生成されたＫＶ型データ１７１の配置先となる分散ＫＶＳサーバ１０２を決定し、決定された分散ＫＶＳサーバ１０２にＫＶ型データ１７１の配置要求を送信する（ステップＳ１００８）。具体的には、ローダ１４３は、決定された分散ＫＶＳサーバ１０２のローダ１４３に配置要求を送信する。なお、配置要求には、マップ、所定のキーの範囲に含まれるＫＶ型データ１７１、ファイル配置情報１５２、及びＫＶ型データ構造情報１５３が含まれるものとする。

　ローダ１４３は、キャッシュ領域１６１を構成する記憶領域に自身が担当するキーの範囲のＫＶ型データ１７１を配置する（ステップＳ１００９）。このとき、ローダ１４３は、ＫＶ型データリスト及びＫＶ型データ管理情報１５１を生成する。具体的には、ローダ１４３は、ＫＶ型データヘッダ情報３０１をキーの順番に従ってソートし、当該ソートの結果に基づいて、各ＫＶ型データヘッダ情報３０１のｎｅｘｔ７１２に他のＫＶ型データ１７１へのポインタを設定する。さらに、分散ＫＶＳ管理部１４２は、ＫＶ型データ管理情報１５１を生成し、ファイルＩＤ７０２にファイル１８１の識別情報を設定し、ＫＶ型データリストポインタ７０３にＫＶ型データリストにおける最初のＫＶ型データ１７１へのポインタを設定する。

　ローダ１４３は、ファイル配置情報１５２のＫＶ型データ構造情報へのポインタ８０３に、ＫＶ型データ構造情報１５３へのポインタを設定し（ステップＳ１０１０）、処理を終了する。

　なお、他の分散ＫＶＳサーバ１０２のローダ１４３は、配置要求を受信した場合、ステップＳ１００９及びステップＳ１０１０と同一の処理を実行する。

　図１１は、本発明の実施例１におけるＫＶ型データ１７１の更新処理を説明するフローチャートである。

　分散ＫＶＳ管理部１４２は、ＵＡＰ１４１からＫＶ型データ１７１の更新要求を受け付ける（ステップＳ１１０１）。更新要求には、更新対象のＫＶ型データ１７１のキー及び更新データが含まれる。

　分散ＫＶＳ管理部１４２は、当該分散ＫＶＳ管理部１４２が更新対象のＫＶ型データ１７１を管理するか否かを判定する（ステップＳ１１０２）。具体的には、分散ＫＶＳ管理部１４２は、キーに基づいてマップを参照し、更新対象のＫＶ型データ１７１を管理する分散ＫＶＳサーバ１０２を特定し、特定された分散ＫＶＳサーバ１０２が当該分散ＫＶＳ管理部１４２が稼働する分散ＫＶＳサーバ１０２であるか否かを判定する。

　分散ＫＶＳ管理部１４２が更新対象のＫＶ型データ１７１を管理すると判定された場合、分散ＫＶＳ管理部１４２は、更新対象のＫＶ型データ１７１の更新処理を実行する（ステップＳ１１０３）。ＫＶ型データ１７１の更新処理は公知の処理であるため詳細な説明を省略する。

　分散ＫＶＳ管理部１４２は、更新されたＫＶ型データ１７１にフラグを設定し、また、ダーティリストに当該ＫＶ型データ１７１を登録する（ステップＳ１１０４）。具体的には、以下のような処理が実行される。

　分散ＫＶＳ管理部１４２は、ＫＶ型データヘッダ情報３０１のフラグ７１１に「１」を設定し、ダーティリストが生成されているか否かを確認する。

　ダーティリストが生成されていない場合、分散ＫＶＳ管理部１４２は、ダーティリストを生成する。分散ＫＶＳ管理部１４２は、ダーティリストにステップＳ１１０３において更新されたＫＶ型データ１７１を追加する。

　ダーティリストが生成されている場合、分散ＫＶＳ管理部１４２は、ダーティリストの最後のＫＶ型データ１７１のダーティリストｎｅｘｔ７１３に、更新されたＫＶ型データ１７１へのポインタを設定し、また、ダーティリストの最後に更新されたＫＶ型データ１７１を追加する。以上がステップＳ１１０４の処理の説明である。

　ステップＳ１１０２において、他の分散ＫＶＳサーバ１０２が更新対象のＫＶ型データ１７１を管理する場合、分散ＫＶＳ管理部１４２は、他の分散ＫＶＳサーバ１０２にＫＶ型データ１７１の更新要求を送信し（ステップＳ１１０５）、その後ステップＳ１１０６に進む。ＫＶ型データ１７１の更新要求には、更新対象のＫＶ型データ１７１のキー及び更新データが含まれる。

　他の分散ＫＶＳサーバ１０２の分散ＫＶＳ管理部１４２は、ＫＶ型データ１７１の更新要求を受信すると、ステップＳ１１０３及びステップＳ１１０４と同一の処理を実行し、更新要求を送信した分散ＫＶＳ管理部１４２に実行結果を送信する。

　分散ＫＶＳ管理部１４２は、ＫＶ型データ１７１を正常に更新できたか否かを判定する（ステップＳ１１０６）。

　ＫＶ型データ１７１を正常に更新できたと判定された場合、分散ＫＶＳ管理部１４２は、処理を終了する。ＫＶ型データ１７１を正常に更新できなかったと判定された場合、分散ＫＶＳ管理部１４２は、異常終了する（ステップＳ１１０７）。例えば、分散ＫＶＳ管理部１４２は、ＫＶ型データ１７１の更新処理が失敗した旨をＵＡＰ１４１に通知する。

　本実施例では、図１１を用いて説明したように、分散ＫＶＳ管理部１４２は、更新されたＫＶ型データ１７１に更新されたことを示すフラグを付与し、また、更新されたＫＶ型データ１７１のリスト（ダーティリスト）を生成する。これによって、更新されたＫＶ型データ１７１を特定することが可能となる。

　図１２は、本発明の実施例１のＫＶ型データ永続化処理の流れを説明するシーケンス図である。

　一つの分散ＫＶＳサーバ１０２上のＵＡＰ１４１が、ローダ１４３に対して、更新されたＫＶ型データ１７１のファイル１８１への反映を指示する永続化指示を送信する（ステップＳ１２０１）。永続化指示には処理対象のキャッシュ領域１６１の識別情報が含まれる。

　以下の説明において、永続化指示を最初に受け付けた分散ＫＶＳサーバ１０２に含まれるローダ１４３、分散ＫＶＳ管理部１４２、及びファイルシステム１４４をマスタローダ１４３、マスタ分散ＫＶＳ管理部１４２、及びマスタファイルシステム１４４とも記載する。また、それ以外の分散ＫＶＳサーバ１０２に含まれるローダ１４３、分散ＫＶＳ管理部１４２、及びファイルシステム１４４をスレーブローダ１４３、スレーブ分散ＫＶＳ管理部１４２、及びスレーブファイルシステム１４４とも記載する。なお、マスタローダ１４３及びスレーブローダ１４３を区別しない場合にはローダ１４３と記載し、マスタ分散ＫＶＳ管理部１４２及びスレーブ分散ＫＶＳ管理部１４２を区別しない場合には分散ＫＶＳ管理部１４２と記載し、マスタファイルシステム１４４及びスレーブファイルシステム１４４を区別しない場合にはファイルシステム１４４と記載する。

　マスタローダ１４３は、処理対象のキャッシュ領域１６１に格納されるＫＶ型データ１７１の読出要求をマスタ分散ＫＶＳ管理部１４２に送信する（ステップＳ１２０２）。読出要求には処理対象のキャッシュ領域１６１の識別情報が含まれる。

　マスタ分散ＫＶＳ管理部１４２は、処理対象のキャッシュ領域１６１を構成する分散ＫＶＳサーバ１０２を特定し、特定された分散ＫＶＳサーバ１０２の分散ＫＶＳ管理部１４２に読出要求を送信する（ステップＳ１２０３）。読出要求には処理対象のキャッシュ領域１６１の識別情報が含まれる。

　例えば、マスタ分散ＫＶＳ管理部１４２は、キャッシュ領域１６１の管理情報（図示省略）に基づいて、処理対象のキャッシュ領域１６１を構成する分散ＫＶＳサーバ１０２を特定できる。なお、マスタ分散ＫＶＳ管理部１４２が処理対象のキャッシュ領域１６１を構成する場合、マスタ分散ＫＶＳ管理部１４２は自分自身にも読出要求を送信する。ここでは、マスタ分散ＫＶＳ管理部１４２及びスレーブ分散ＫＶＳ管理部１４２の両方に読出要求が送信されるものとする。

　分散ＫＶＳ管理部１４２は、読出要求を受け付けると、処理対象のキャッシュ領域１６１に格納されるＫＶ型データ１７１の中から更新されたＫＶ型データ１７１を特定する（ステップＳ１２０４）。具体的には、分散ＫＶＳ管理部１４２は、ＫＶ型データ管理情報１５１を参照して、キャッシュ領域ＩＤ７０１に処理対象のキャッシュ領域１６１の識別情報が格納されるＫＶ型データ管理情報１５１を検索する。分散ＫＶＳ管理部１４２は、検索されたＫＶ型データ管理情報１５１のダーティリストポインタ７０４に基づいて、ダーティリストに登録されるＫＶ型データ１７１を特定する。

　マスタ分散ＫＶＳ管理部１４２及びスレーブ分散ＫＶＳ管理部１４２は、特定されたＫＶ型データ１７１をマスタ分散ＫＶＳ管理部１４２に送信する（ステップＳ１２０５）。

　マスタ分散ＫＶＳ管理部１４２は、更新されたＫＶ型データ１７１の読み出しが完了した旨をマスタローダ１４３に応答する（ステップＳ１２０６）。

　マスタローダ１４３は、実行サーバ判定処理を実行する（ステップＳ１２０７）。実行サーバ判定処理は、更新されたＫＶ型データ１７１をファイル１８１に反映させる実行サーバ（分散ＫＶＳサーバ１０２）を決定するための処理である。実行サーバ判定処理の詳細は、図１３を用いて後述する。

　マスタローダ１４３は、実行サーバ判定処理によって決定された分散ＫＶＳサーバ１０２にレコード更新要求を送信する（ステップＳ１２０８）。レコード更新要求には、処理対象のファイル１８１の識別情報、及び更新されたＫＶ型データ１７１が含まれる。

　マスタローダ１４３が含まれる分散ＫＶＳサーバ１０２が実行サーバとして決定された場合、マスタローダ１４３は、マスタファイルシステムに１４４にレコード更新要求を送信する。また、他の分散ＫＶＳサーバ１０２が実行サーバとして決定された場合、マスタローダ１４３は、他の分散ＫＶＳサーバ１０２のスレーブローダ１４３にレコード更新要求を送信する。スレーブローダ１４３は、当該要求をスレーブファイルシステム１４４に送信する。

　ファイルシステム１４４は、レコード更新要求を受信すると、更新されたＫＶ型データ１７１をファイル１８１に反映させためにレコード更新処理を実行する（ステップＳ１２０９）。レコード更新処理の詳細については、図１４を用いて後述する。

　ファイルシステム１４４は、レコード更新処理が終了した後、マスタローダ１４３に処理が完了した旨を通知してもよい。この場合、マスタローダ１４３は、ＵＡＰ１４１に処理が正常に終了した旨を通知する。

　図１３は、本発明の実施例１における実行サーバ判定処理の一例を説明するフローチャートである。

　マスタローダ１４３は、マスタ分散ＫＶＳ管理部１４２からＫＶ型データ１７１の読み出しが完了した旨の応答を受け付けると実行サーバ判定処理を開始する。まず、マスタローダ１４３は、処理対象のキャッシュ領域１６１に格納されるＫＶ型データ１７１に対応するファイル１８１を特定する（ステップＳ１３０１）。具体的には、以下のような処理が実行される。

　マスタローダ１４３は、ファイル配置情報１５２を参照し、キャッシュ領域ＩＤ８０１が処理対象のキャッシュ領域１６１の識別情報と一致するエントリを検索する。マスタローダ１４３は、検索されたエントリのファイルＩＤ８０２に基づいてＫＶ型データ１７１に対応するファイル１８１を特定する。

　マスタローダ１４３は、マスタファイルシステム１４４に処理対象のファイル１８１のオープンを指示する。ファイルシステム１４４は、ファイルオープンに対する戻り値とともに、キャッシュされているファイル管理情報１３２及びレコード定義情報１３３を応答する。以上がステップＳ１３０１の処理の説明である。

　次に、マスタローダ１４３は、ファイル管理情報１３２の格納場所情報４０７を参照して、処理対象のファイル１８１を管理する分散ＫＶＳサーバ１０２を特定し、特定された分散ＫＶＳサーバ１０２を実行サーバとして決定する（ステップＳ１３０２）。また、マスタローダ１４３は、実行サーバとして決定された分散ＫＶＳサーバ１０２のローダ１４３にレコード更新要求を送信し（ステップＳ１３０３）、処理を終了する。

　図１４は、本発明の実施例１のレコード更新処理の一例を説明するフローチャートである。

　ファイルシステム１４４は、ローダ１４３からレコード更新要求を受信するとレコード更新処理を開始する。まず、ファイルシステム１４４は、処理対象のファイル１８１に対応するＫＶ型データ構造情報１５３を取得する（ステップＳ１４０１）。具体的には、ファイルシステム１４４は、ファイル配置情報１５２を参照し、ファイルＩＤ８０２が処理対象のファイル１８１の識別情報と一致するエントリを検索する。ファイルシステム１４４は、検索されたエントリのＫＶ型データ構造情報１５３へのポインタ８０３を参照して、ＫＶ型データ構造情報１５３を取得する。

　ファイルシステム１４４は、ＫＶ型データ１７１のループ処理を開始する（ステップＳ１４０２）。ファイルシステム１４４は、レコード更新要求に含まれるＫＶ型データ１７１を一つ選択する。

　ファイルシステム１４４は、ＫＶ型データ１７１に対応するレコードの処理対象のファイル１８１における位置を特定し、特定された位置にＫＶ型データ１７１を書き込む（ステップＳ１４０３）。具体的には、以下のような処理が実行される。

　ファイルシステム１４４は、取得されたＫＶ型データ構造情報１５３を参照し、キー９０２が選択されたＫＶ型データ１７１のキー３０２と一致するエントリを検索する。ファイルシステム１４４は、検索されたエントリのバリューサイズ９０３及びオフセット９０４に基づいて、更新されたＫＶ型データ１７１に対応するレコードの処理対象のファイル１８１における位置を特定する。

　ファイルシステム１４４は、更新されたＫＶ型データ１７１を特定された位置に上書きすることによって、更新されたＫＶ型データ１７１を処理対象のファイル１８１に反映させる。以上がステップＳ１４０３の処理の説明である。

　次に、ファイルシステム１４４は、レコード更新要求に含まれる全てのＫＶ型データ１７１について処理が完了した否かを判定する（ステップＳ１４０４）。

　全てのＫＶ型データ１７１について処理が完了していないと判定された場合、ファイルシステム１４４は、ステップＳ１４０２に戻り同様の処理を実行する。全てのＫＶ型データ１７１について処理が完了したと判定された場合、ファイルシステム１４４は、処理を終了する。

　ここまで、既存のＫＶ型データ１７１の更新について説明したが、新たなＫＶ型データ１７１の追加及びＫＶ型データ１７１の削除についても同様の処理を適用することができる。

　（ＫＶ型データ１７１の追加）
　ＫＶ型データの追加処理は、図１１に示すＫＶ型データ更新処理とほぼ同様であるが、一部処理が異なる。

　まず、ＫＶ型データの追加処理では、ＵＡＰ１４１は分散ＫＶＳ管理部１４２及びローダ１４３に新規ＫＶ型データ１７１の追加要求を送信する。

　ステップＳ１１０１、ステップＳ１１０２の処理は同一の処理である。

　ステップＳ１１０３において、分散ＫＶＳ管理部１４２は、キャッシュ領域１６１にＫＶ型データ１７１を追加する。

　ステップＳ１１０４において、分散ＫＶＳ管理部１４２は、ＫＶ型データヘッダ情報３０１のフラグ７１１に「１」を設定する。ＫＶ型データリストへの新規ＫＶ型データ１７１の追加処理はステップＳ１１０４において説明した処理と同一である。

　ステップＳ１１０５以降の処理は図１１に示す処理と同一の処理である。

　一方、ローダ１４３は、新規ＫＶ型データ１７１の追加要求の受信後、ＫＶ型データ構造情報１５３にエントリを追加し、追加されたエントリのＩＤ９０１に識別番号を設定し、キー９０２及びバリューサイズ９０３のそれぞれに値を設定する。分散ＫＶＳ管理部１４２は、追加されたエントリの一つ上のエントリのバリューサイズ９０３及びオフセット９０４に基づいて、追加されたＫＶ型データ１７１のファイルにおけるオフセットを算出する。以下の説明では、追加されたエントリの一つ上のエントリを上位エントリとも記載する。

　例えば、上位エントリのオフセット９０４にバリューサイズ９０３を加算することによって算出された値を追加されたエントリのオフセット９０４に設定する方法が考えられる。

　その他の処理は実施例１の処理と同一であるため説明を省略する。

　（ＫＶ型データ１７１の削除）
　ＫＶ型データの削除処理は、図１１に示す処理とほぼ同様であるが、一部処理が異なる。

　ステップＳ１１０１、ステップＳ１１０２の処理は図１１に示す処理と同一の処理である。

　ステップＳ１１０３において、分散ＫＶＳ管理部１４２は、キャッシュ領域１６１からＫＶ型データ１７１を削除する。このとき、分散ＫＶＳ管理部１４２は、バリュー３０３のみを削除し、キー３０２及びＫＶ型データヘッダ情報３０１はそのまま保持する。前述した処理以外に、バリュー３０３を無効化する処理、又はバリュー３０３に「０」等のデータを書き込むなどの処理が考えられる。

　ステップＳ１１０４において、分散ＫＶＳ管理部１４２は、ＫＶ型データヘッダ情報３０１のフラグ７１１に、ＫＶ型データの削除を示す「－１」を設定する。また、分散ＫＶＳ管理部１４２は、ＫＶ型データリストからＫＶ型データ１７１を削除する。ＫＶ型データリストの更新方法は公知のものであるため詳細な説明を省略するが、削除されたＫＶ型データ１７１へのポインタを他のＫＶ型データ１７１へのポインタに変更する方法が考えられる。

　ＫＶ型データ永続化処理は、図１２に示す処理とほぼ同様であるが、一部処理が異なる。

　ステップＳ１２０１からステップＳ１２０３の処理は図１２に示す処理と同一の処理である。

　ステップＳ１２０４において、マスタ分散ＫＶＳ管理部１４２及びスレーブ分散ＫＶＳ管理部１４２は、それぞれ、ダーティリストを参照して、更新されたＫＶ型データ１７１及び削除されたＫＶ型データ１７１を特定し、キャッシュ領域１６１から特定されたＫＶ型データ１７１を読み出す。

　ステップＳ１２０５において、マスタ分散ＫＶＳ管理部１４２及びスレーブ分散ＫＶＳ管理部１４２は、それぞれ、特定されたＫＶ型データ１７１をマスタ分散ＫＶＳ管理部１４２に送信した後、フラグ７１１に「－１」が設定されるＫＶ型データ１７１をキャッシュ領域１６１から削除する。ステップＳ１２０６以降の処理の流れは実施例１と同一であるが、実行サーバ判定処理及びレコード更新処理の一部内容が異なる。

　実行サーバ判定処理では、マスタローダ１４３は、読み出されたＫＶ型データ１７１を、更新されたＫＶ型データ１７１と、削除されたＫＶ型データ１７１とに分ける。具体的には、マスタローダ１４３は、ＫＶ型データ１７１のＫＶ型データヘッダ情報３０１のフラグ７１１を参照して、フラグ７１１が「１」であるＫＶ型データ１７１と、フラグ７１１が「－１」であるＫＶ型データ１７１とに分ける。

　マスタローダ１４３は、更新されたＫＶ型データ１７１に対してステップＳ１３０１からステップＳ１３０３の処理を実行し、また、削除されたＫＶ型データ１７１に対してステップＳ１３０１からステップＳ１３０３の処理を実行する。すなわち、ファイル１８１のレコードの更新を指示するレコード更新要求と、ファイル１８１からのレコードの削除を指示するレコード更新要求との二つのレコード更新要求が送信されることとなる。

　分散ＫＶＳサーバ１０２がファイル１８１のレコードの更新を指示するレコード更新要求を受信した場合、実施例１と同一の処理が実行される。一方、分散ＫＶＳサーバ１０２がファイル１８１のレコードの削除を指示するレコード更新要求を受け付けた場合以下のような処理が実行される。

　ステップＳ１４０１及びステップＳ１４０２の処理は図１４に示す処理と同一の処理である。

　ステップＳ１４０３において、ファイルシステム１４４は、削除されたＫＶ型データ１７１に対応するレコードの処理対象のファイル１８１における位置を特定し、特定された位置からバリューサイズ９０３分のデータを削除する。

　具体的には、ファイルシステム１４４は、検索されたエントリのバリューサイズ９０３及びオフセット９０４に基づいて、削除されたＫＶ型データ１７１に対応するレコードの処理対象のファイル１８１における位置を特定する。

　ファイルシステム１４４は特定された位置（オフセット）からバリューサイズ９０３分のデータを削除する。さらに、ファイルシステム１４４は、ＫＶ型データ構造情報１５３から検索されたエントリを無効化する。

　実施例１によれば、ＫＶ型データ１７１の更新又は削除結果をファイル（データソース）に反映することができる。これによって、ファイルシステムと分散ＫＶＳとの連携が可能となり、ファイルＩ／Ｏ　ＡＰＩ及びＫＶ型データＡＰＩのいずれを用いても同一内容のデータにアクセスすることが可能となる。

　（変形例）
　実施例１では、ファイル管理情報１３２及びレコード定義情報１３３を用いてファイル１８１のレコード構造を把握していたが、予め、分散ＫＶＳサーバ１０２にファイル１８１のレコード定義情報を設定してもよい。

　図１５は、本発明の実施例１の変形例におけるファイル構成情報１５００の一例を示す説明図である。

　ファイル構成情報１５００は、ファイル１８１、レコード、及びＫＶ型データ１７１のキーとして用いられたフィールドの対応関係を管理する情報であり、ファイルＩＤ１５０１、レコード定義情報１５０２、及びキー・フィールド番号１５０３を含む。変形例では、ファイル構成情報１５００が予め分散ＫＶＳサーバ１０２に登録される。

　ファイルＩＤ１５０１は、ストレージ装置１０５に格納されるファイル１８１の識別情報を格納する。ファイルＩＤ１５０１は、ファイルＩＤ４０１と同一のものである。レコード定義情報１５０２は、ファイル１８１を構成するレコードの管理情報を格納する。レコード定義情報１５０２は、レコード定義情報１３３と同一のものである。キー・フィールド番号１５０３は、ファイル１８１から生成されたＫＶ型データ１７１のキーとして用いられたフィールドの識別番号を格納する。ＫＶ型データ１７１が生成される前は、キー・フィールド番号１５０３は空欄である。

　図１６は、本発明の実施例１の変形例におけるファイル構成情報１５００の登録処理の一例を説明するフローチャートである。

　ファイル１８１がストレージ装置１０５に格納される場合に、ファイル構成情報１５００の登録処理が実行される。

　ファイルシステム１４４は、ファイル１８１及びユーザによって定義されたファイル１８１のレコード定義情報を受け付ける（ステップＳ１６０１）。

　ファイルシステム１４４は、ファイル１８１の内容とレコード定義情報とを比較し、整合性を確認し（ステップＳ１６０２）、ファイル１８１の内容とレコード定義情報とが整合しているか否かを判定する（ステップＳ１６０３）。

　ファイル１８１の内容とレコード定義情報とが整合していないと判定された場合、ファイルシステム１４４は、ファイル構成情報１５００の登録が失敗した旨を通知し（ステップＳ１６０５）、処理を終了する。

　ファイル１８１の内容とレコード定義情報とが整合していると判定された場合、ファイルシステム１４４は、ファイル構成情報１５００にファイル１８１及びレコード定義情報を対応付けて登録し（ステップＳ１６０４）、処理を終了する。具体的には、ファイルシステム１４４はファイル構成情報１５００にエントリを追加する。ファイルシステム１４４は、追加されたエントリのファイルＩＤ１５０１にファイル１８１の識別情報を設定し、また、追加されたエントリのレコード定義情報１５０２に受け付けたレコード定義情報を設定する。この時点では、ファイル１８１に対応するＫＶ型データ１７１が生成されていないため、キー・フィールド番号１５０３は空欄となっている。

　なお、ファイルシステム１４４は、他の分散ＫＶＳサーバ１０２のファイルシステム１４４に追加されたエントリの情報を通知する。他の分散ＫＶＳサーバ１０２のファイルシステム１４４は、当該通知に従って、ファイル構成情報１５００を更新する。

　図１７は、本発明の実施例１の変形例におけるロード処理の一例を説明するフローチャートである。以下、実施例１との差異を中心に説明する。

　変形例では、ファイル管理情報１３２及びレコード定義情報１３３の代わりに、ファイル構成情報１５００を用いるため、ステップＳ１００１の処理は省略される。

　ローダ１４３は、ファイル１８１を取得した後、ファイル１８１の内容とキーとして用いられるフィールドの情報との整合性を確認し（ステップＳ１７０１）、ファイル１８１の内容とフィールドの情報とが整合しているか否かを判定する（ステップＳ１７０２）。

　ファイル１８１の内容とフィールドの情報とが整合していないと判定された場合、ローダ１４３は、ステップＳ１０１１に進む。

　ファイル１８１の内容とフィールドの情報とが整合していると判定された場合、ローダ１４３は、ファイル構成情報を更新し、さらに、分散ＫＶＳ管理部１４２にキャッシュ領域１６１の生成要求を送信する（ステップＳ１７０３）。具体的には、ローダ１４３は、ファイル構成情報１５００を参照し、ファイルＩＤ１５０１が処理対象のファイル１８１の識別情報と一致するエントリを検索する。ローダ１４３は、検索されたエントリのキー・フィールド番号１５０３に指定されたフィールドの情報を設定する。

　ステップＳ１００７では、ファイル構成情報１５００に基づいてＫＶ型データ１７１が生成される。その他の処理は実施例１と同一であるため説明を省略する。

　［実施例２］
　実施例２では、一つのファイル１８１が複数のサブファイル１８１１に分割され、複数の分散ＫＶＳサーバ１０２に接続されるストレージ装置１０５にサブファイル１８１１が格納される点が異なる。以下、実施例１との差異を中心に実施例２について説明する。

　図１８は、本発明の実施例２における計算機システムの構成例を示すブロック図である。実施例２の計算機システムは、実施例１の計算機システムと同一の構成である。実施例２では、ストレージ装置１０５にサブファイル１８１１が格納される点が異なる。また、実施例１では少なくとも一つの分散ＫＶＳサーバ１０２がローダ１４３を備えていればよいが、実施例２では、全ての分散ＫＶＳサーバ１０２がローダ１４３を備えていることを前提とする。

　サブファイル１８１１は、一つのファイル１８１が分割されたファイルデータであり、当該ファイル１８１をブロック単位に分割したデータ（ブロックデータ）から構成される。一つのブロックデータには、複数のレコードを含むことができる。ただし、ブロックのサイズとレコードのサイズとは一致しない場合があるため、一つのレコードのデータが複数のブロックデータに含まれる場合がある。

　本実施例では、ファイルシステム１３１が、ファイル１８１をストレージ装置１０５に格納する場合、ファイル１８１を所定の大きさのブロックデータに分割し、アドレスが連続する所定の数のブロックデータ群を複数のストレージ装置１０５に分散して格納する。本実施例では、一般的なストライピングを適用するものとする。なお、ファイル１８１の最初のレコードから順に分割されるものとする。

　ここで、四つのストレージ装置１０５にファイル１８１を分散して格納する場合、すなわち、ストライプ数が「４」の場合を例に説明する。以下の説明では、四つのストレージ装置１０５をストレージ装置Ａ、ストレージ装置Ｂ、ストレージ装置Ｃ及びストレージ装置Ｄと仮定し、また、ブロックのサイズを「６４ＫＢ」と仮定し、また、ストライプサイズを「１６ブロック」と仮定する。

　この場合、ファイルシステム１３１は、ファイル１８１を「６４ＫＢ」単位のブロックデータに分割し、ブロックの番号が「１」から「１６」のブロックデータをストレージ装置Ａに、ブロックの番号が「１７」から「３２」のブロックデータをストレージ装置Ｂに、ブロックの番号が「３３」から「４８」のブロックデータをストレージ装置Ｃに、ブロックの番号が「４９」から「６４」のブロックデータをストレージ装置Ｄに格納する。以下同様の手順に従って、ストレージ装置Ａ、ストレージ装置Ｂ、ストレージ装置Ｃ及びストレージ装置Ｄの順にブロックデータ群が格納される。

　ファイル１８１の先頭からのオフセットが分かれば、ブロックの番号及び当該ブロックの番号に対応するブロックデータを格納するストレージ装置１０５を特定することができる。

　図１９は、本発明の実施例２におけるファイル管理情報１３２の一例を示す説明図である。

　実施例２では、一つのファイル１８１が複数のサブファイル１８１１として複数のストレージ装置１０５に格納されるため、ファイル管理情報１３２の格納場所情報４０７には、サブファイル１８１１の格納場所に関する情報が格納される。

　格納場所情報４０７は、サブファイル１８１１の構成を管理するための情報であり、ストライプ数１９０１、ストライプサイズ１９０２、及び分散ＫＶＳサーバＩＤ１９０３を含む。

　ストライプ数１９０１は、一つのファイル１８１が分散して配置されるサブファイル１８１１の数である。ストライプサイズ１９０２は、ブロックデータ群のサイズ（ブロック数）を表す。

　分散ＫＶＳサーバＩＤ１９０３は、サブファイル１８１１を管理する分散ＫＶＳサーバ１０２の識別情報を格納する。本実施例では、サブファイル１８１１には「１」から順に識別番号が付与されているものとする。この場合、分散ＫＶＳサーバＩＤ１９０３には、例えば、サブファイル１８１１の識別番号及びサブファイル１８１１を管理する分散ＫＶＳサーバ１０２の識別情報が対応付けられて格納される。

　実施例２のファイル配置情報１５２のファイルＩＤ８０２にはサブファイル１８１１の識別番号が格納される点が実施例１と異なる。実施例２のＫＶ型データ構造情報１５３は、実施例１と同一のものである。

　実施例１では、一つのストレージ装置１０５に一つのファイル１８１が格納されていたため、一つのローダ１４３がロード処理を実行していた。しかし、実施例２では、一つのファイル１８１から生成された複数のサブファイル１８１１が複数のストレージ装置１０５に格納される。そのため、各分散ＫＶＳサーバ１０２上のローダ１４３が並列的にロード処理を実行する。したがって、実施例２では、ＫＶ型データ１７１をキャッシュ領域１６１に配置する場合に、ロード処理を実行する分散ＫＶＳサーバ１０２を決定するための処理が実行される。

　図２０は、本発明の実施例２のＫＶ型データ永続化処理の流れを説明するシーケンス図である。

　ステップＳ１２０１からステップＳ１２０６の処理は同一である。

　マスタローダ１４３は、実行サーバ判定処理を実行する（ステップＳ２００７）。実施例２の実行サーバ判定処理は、更新されたＫＶ型データ１７１を反映させる複数のサブファイル１８１１が特定され、さらに、複数のサブファイル１８１１の各々を管理する分散ＫＶＳサーバ１０２が実行サーバとして決定される。実施例２では、複数の分散ＫＶＳサーバ１０２が実行サーバとして決定される。実施例２の実行サーバ判定処理の詳細は、図２１を用いて後述する。

　マスタローダ１４３は、実行サーバ判定処理の処理結果によって決定された複数の分散ＫＶＳサーバ１０２にレコード更新要求を送信する（ステップＳ２００８）。レコード更新要求には、サブファイル１８１１の識別情報、及び抽出されたＫＶ型データ１７１が含まれる。

　マスタローダ１４３が含まれる分散ＫＶＳサーバ１０２自身にレコード更新要求を送信する場合、マスタローダ１４３は、マスタファイルシステムに１４４にレコード更新要求を送信する。一方、他の分散ＫＶＳサーバ１０２にレコード更新要求を送信する場合、マスタローダ１４３は、他の分散ＫＶＳサーバ１０２のスレーブローダ１４３にレコード更新要求を送信する。スレーブローダ１４３は、当該要求をスレーブファイルシステム１４４に送信する。

　ファイルシステム１４４は、レコード更新要求を受信すると、更新されたＫＶ型データ１７１をファイル１８１に反映させるためにレコード更新処理を実行する（ステップＳ２００９）。実施例２のレコード更新処理の詳細については、図２４を用いて後述する。

　図２１は、本発明の実施例２におけるローダ決定処理の一例を説明するフローチャートである。図２２は、本発明の実施例２における一時リストの一例を説明する説明図である。

　ローダ１４３は、ＵＡＰ１４１から任意のファイル１８１のキャッシュ領域１６１へのロード指示を受け付けると以下で説明するローダ決定処理を開始する。ロード指示には処理対象のファイル１８１の識別情報（ファイルＩＤ）及びＫＶ型データ１７１のキーとして用いられるフィールドの情報が含まれる。また、ロード指示には、ＫＶ型データ１７１を配置するキャッシュ領域１６１の識別情報（キャッシュ領域ＩＤ）も含まれる。

　ローダ１４３は、対象ファイル１８１のサブファイル１８１１を管理する分散ＫＶＳサーバ１０２を特定する（ステップＳ２１０１）。具体的には、以下のような処理が実行される。

　ローダ１４３は、ファイルシステム１４４に処理対象のファイルオープンを指示する。ファイルシステム１４４は、ファイルオープンに対する戻り値とともに、ファイル管理情報１３２及びレコード定義情報１３３を応答する。なお、ファイルシステム１４４が実行する処理は、ステップＳ１００１と同一の処理であるため説明を省略する。

　ローダ１４３は、ファイル管理情報１３２の格納場所情報４０７を参照して、サブファイル１８１１を管理する分散ＫＶＳサーバ１０２を特定する。本実施例では格納場所情報４０７の分散ＫＶＳサーバＩＤ１９０３に基づいて、前述した分散ＫＶＳサーバ１０２を特定することができる。

　本実施例では、特定された複数の分散ＫＶＳサーバ１０２に対してロード処理の実行が指示される。このとき、ローダ１４３は、図２２に示すような一時リスト２２００を生成する。ここで、一時リスト２２００について説明する。

　一時リスト２２００は、サブファイルＩＤ２２０１、分散ＫＶＳサーバＩＤ２２０２、レコードＩＤ２２０３、及び担当フラグ２２０４を含む。

　サブファイルＩＤ２２０１は、サブファイル１８１１の識別番号を格納する。分散ＫＶＳサーバＩＤ２２０２は、サブファイル１８１１を管理する分散ＫＶＳサーバ１０２の識別情報を格納する。レコードＩＤ２２０３は、サブファイル１８１１に含まれるレコードの識別情報である。担当フラグ２２０４は、分散ＫＶＳサーバ１０２がロード処理を担当するレコードであるか否かを示す情報を格納する。例えば、分散ＫＶＳサーバ１０２がロード処理を担当するレコードの場合、担当フラグ２２０４には「１」が格納され、分散ＫＶＳサーバ１０２がロード処理を担当するレコードの場合、担当フラグ２２０４には「０」が格納される。

　ステップＳ２１０１において、ローダ１４３は、一時リスト２２００にサブファイル１８１１の数だけエントリを生成し、生成されたエントリのサブファイルＩＤ２２０１にサブファイル１８１１の識別番号を設定する。また、ローダ１４３は、生成されたエントリの分散ＫＶＳサーバＩＤ２２０２に特定された分散ＫＶＳサーバ１０２の識別情報を設定する。この時点では、レコードＩＤ２２０３及び担当フラグ２２０４は空欄のままである。以上がステップＳ２１０１の処理の説明である。

　本実施例では、一つのレコードのデータが複数のブロックデータに含まれている可能性がある。そのため、当該レコードのロード処理をどの分散ＫＶＳサーバ１０２が担当するかを決定する必要がある。そこで、ステップＳ２１０３からステップＳ２１１０までの処理が実行される。

　まず、ローダ１４３は、各サブファイル１８１１に含まれるレコードを特定する（ステップＳ２１０２）。具体的には、ローダ１４３は、レコード定義情報１３３及び格納場所情報４０７を参照して、各サブファイル１８１１に含まれるレコードを算出する。例えば、以下のような処理が考えられる。

　ローダ１４３は、サブファイル１８１１を一つ選択する。レコード定義情報１３３のレコード構成５０１に基づいてレコードの長さ把握する。次に、ローダ１４３は格納場所情報４０７のストライプ数１９０１及びストライプサイズ１９０２に基づいてサブファイル１８１１に含まれるブロックデータ群を特定する。さらに、ローダ１４３は、レコードの長さ、ストライプ数、及びストライプサイズからサブファイル１８１１に含まれるレコードを特定する。

　ローダ１４３は、選択されたサブファイル１８１１に対応する一時リスト２２００のエントリのレコードＩＤ２２０３に特定されたレコードの識別情報を設定し、さらに、担当フラグ２２０４に「０」を設定する。

　ローダ１４３は、全てのサブファイル１８１１に対して前述した処理を繰り返し実行する。以上がステップＳ２１０２の処理の説明である。

　次に、ローダ１４３は、サブファイル１８１１のループ処理を開始する（ステップＳ２１０３）。具体的には、ローダ１４３は、一時リスト２２００から処理対象のサブファイル１８１１を一つ選択する。ここでは、サブファイル１８１１の識別番号順に選択されるものとする。

　ローダ１４３は、選択されたサブファイル１８１１に含まれるレコードのループ処理を開始する（ステップＳ２１０４）。具体的には、ローダ１４３は、選択されたサブファイル１８１１に対応する一時リスト２２００のエントリのレコードＩＤ２２０３の中から処理対象のレコードを一つ選択する。

　ローダ１４３は、選択されたレコードの担当フラグ２２０４が「１」であるか否かを判定する（ステップＳ２１０５）。すなわち、ステップＳ２１０３において選択されたエントリの分散ＫＶＳサーバＩＤ２２０２に対応する分散ＫＶＳサーバ１０２が、当該レコードのロード処理を担当することが決定済みであるか否かが判定される。

　選択されたレコードの担当フラグ２２０４が「１」であると判定された場合、ローダ１４３は、ステップＳ２１０９に進む。

　選択されたレコードの担当フラグ２２０４が「１」でないと判定された場合、ローダ１４３は、当該レコードのデータが複数の分散ＫＶＳサーバ１０２に分散して配置されているか否かを判定する（ステップＳ２１０６）。具体的には、ローダ１４３は、一時リスト２２００の他のサブファイル１８１１のエントリのレコードＩＤ２２０３を参照し、選択されたレコードの識別情報と同一の識別情報が存在するか否かを判定する。他のサブファイル１８１１のエントリのレコードＩＤ２２０３に選択されたレコードの識別情報と同一の識別情報が存在する場合、ローダ１４３は、当該レコードのデータが複数の分散ＫＶＳサーバ１０２に分散して配置されていると判定する。

　選択されたレコードのデータが複数の分散ＫＶＳサーバ１０２に分散して配置されていないと判定された場合、ローダ１４３は、当該レコードの担当フラグ２２０４に「１」を設定し（ステップＳ２１０８）、ステップＳ２１０９に進む。

　選択されたレコードが複数の分散ＫＶＳサーバ１０２に分散して配置されていると判定された場合、ローダ１４３は、当該レコードのロード処理を担当する分散ＫＶＳサーバ１０２を決定する（ステップＳ２１０７）。その後、ローダ１４３は、ステップＳ２１０９に進む。

　例えば、ローダ１４３は、レコードの先頭のデータが含まれるサブファイル１８１１を管理する分散ＫＶＳサーバ１０２を当該レコードのロード処理を担当する分散ＫＶＳサーバ１０２として決定する方法が考えられる。また、レコードの全体のデータ量に対し、レコードのデータを最も多く含むサブファイル１８１１を管理する分散ＫＶＳサーバ１０２を当該レコードのロード処理を担当する分散ＫＶＳサーバ１０２として決定する方法も考えられる。なお、本発明は、レコードのロード処理を担当する分散ＫＶＳサーバ１０２の決定方法に限定されない。

　選択されたレコードのロード処理を担当する分散ＫＶＳサーバ１０２が選択されたサブファイル１８１１を管理する分散ＫＶＳサーバ１０２の場合、ローダ１４３は、選択されたレコードの担当フラグ２２０４に「１」を設定する。また、ローダ１４３は、他のサブファイル１８１１のエントリから当該レコードの識別情報を削除する。

　選択されたレコードのロード処理を担当する分散ＫＶＳサーバ１０２が選択されたサブファイル１８１１を管理する分散ＫＶＳサーバ１０２とは異なる分散ＫＶＳサーバ１０２の場合、ローダ１４３は、他の分散ＫＶＳサーバ１０２が管理するサブファイル１８１１に対応するエントリの当該レコードの担当フラグ２２０４に「１」を設定する。また、ローダ１４３は、他のサブファイル１８１１のエントリから当該レコードの識別情報を削除する。以上がステップＳ２１０７の処理の一例である。

　次に、ローダ１４３は、選択されたサブファイル１８１１に含まれる全てのレコードについて処理が完了したか否かを判定する（ステップＳ２１０９）。具体的には、ローダ１４３は、一時リスト２２００を参照して、選択されたサブファイル１８１１のエントリの担当フラグ２２０４が「０」であるレコードが存在するか否かを判定する。担当フラグ２２０４が「０」であるレコードが存在する場合、ローダ１４３は、全てのレコードについて処理が完了していないと判定する。

　選択されたサブファイル１８１１に含まれる全てのレコードについて処理が完了していないと判定された場合、ローダ１４３は、ステップＳ２１０４に戻り同様の処理を実行する。

　選択されたサブファイル１８１１に含まれる全てのレコードについて処理が完了したと判定された場合、ローダ１４３は、選択されたサブファイル１８１１を管理する分散ＫＶＳサーバ１０２が担当するレコード（レコードのレンジ）を決定する（ステップＳ２１１０）。具体的には、ローダ１４３は、選択されたサブファイル１８１１に対応する一時リスト２２００のエントリを参照し、当該エントリのレコードＩＤ２２０３に登録されるレコードを担当するレコードとして決定する。

　ローダ１４３は、全てのサブファイル１８１１について処理が完了したか否かを判定する（ステップＳ２１１１）。全てのサブファイル１８１１について処理が完了していないと判定された場合、ローダ１４３は、ステップＳ２００３に戻り同様の処理を実行する。

　全てのサブファイル１８１１について処理が完了したと判定された場合、ローダ１４３は、サブファイル１８１１を管理する分散ＫＶＳサーバ１０２に対してロード処理の実行指示を送信する（ステップＳ２１１２）。

　ロード処理の実行指示には、サブファイル１８１１の識別番号及び担当するレコードの識別情報（レンジの情報）が含まれる。分散ＫＶＳサーバ１０２のローダ１４３は、ロード処理の実行指示を受け付けると、図１０に示すロード処理を実行する。なお、ステップＳ１００２において、サブファイル１８１１に分散配置されたレコードのデータが含まれる場合、ローダ１４３は、分散配置されたレコードのデータを含む他のサブファイル１８１１を管理する分散ＫＶＳサーバ１０２に当該レコードのデータの読み出しを要求する。その他の処理は実施例１と同一であるため説明を省略する。

　ＫＶ型データ更新処理は実施例１と同一であるため説明を省略する。

　図２３は、本発明の実施例２における実行サーバ判定処理の一例を説明するフローチャートである。

　ステップＳ１３０１は同一の処理である（ステップＳ１３０１）。マスタローダ１４３は、ファイル管理情報１３２の格納場所情報４０７を参照して、処理対象のファイル１８１から生成されるサブファイル１８１１を管理する分散ＫＶＳサーバ１０２を特定する（ステップＳ２３０２）。

　マスタローダ１４３は、ＫＶ型データ１７１のループ処理を開始する（ステップＳ２３０３）。具体的には、マスタローダ１４３は、更新されたＫＶ型データ１７１の中から、処理対象のＫＶ型データ１７１を一つ選択する。

　マスタローダ１４３は、ＫＶ型データ構造情報１５３及びファイル管理情報１３２の格納場所情報４０７を参照して、選択されたＫＶ型データ１７１に対応するレコードのデータを含むサブファイル１８１１を特定する（ステップＳ２３０４）。具体的には以下のような処理が実行される。

　マスタローダ１４３は、選択されたＫＶ型データ１７１に対応するＫＶ型データ構造情報１５３のエントリのバリューサイズ９０３及びオフセット９０４を取得する。

　マスタローダ１４３は、オフセット９０４に基づいて、選択されたＫＶ型データ１７１に対応するレコードの先頭のデータが含まれるブロックデータの番号を特定する。例えば、マスタローダ１４３は、オフセット９０４の値をブロックデータのサイズで除算することによって、レコードのデータを含むブロックデータの番号を算出する。

　さらに、マスタローダ１４３は、バリューサイズ９０３に基づいて特定されたブロックデータに、選択されたＫＶ型データ１７１に対応するレコードの全てのデータが含まれるか否かを判定する。

　特定されたブロックデータに選択されたＫＶ型データ１７１に対応するレコードの全てのデータが含まれる場合、当該ブロックデータの番号を処理結果として出力する。一方、特定されたブロックデータに選択されたＫＶ型データ１７１に対応するレコードの全てのデータが含まれない場合、マスタローダ１４３は、バリューサイズ９０３に基づいて、当該レコードのデータを含むブロックデータの番号を特定する。

　マスタローダ１４３は、格納場所情報４０７のストライプ数１９０１及びストライプサイズ１９０２に基づいて、特定されたブロックデータの番号がどのブロックデータ群に含まれるかを特定し、また、当該ブロックデータ群を含むサブファイル１８１１を特定する。

　このとき、マスタローダ１４３は、ＫＶ型データ１７１のキーと、特定されたサブファイル１８１１を管理する分散ＫＶＳサーバ１０２の識別情報とを対応付けたリストを生成する。以上がステップＳ２３０４の処理の説明である。

　次に、マスタローダ１４３は、全てのＫＶ型データ１７１について処理が完了したか否かを判定する（ステップＳ２３０５）。全てのＫＶ型データ１７１について処理が完了していないと判定された場合、マスタローダ１４３は、ステップＳ２３０３に戻り、同様の処理を実行する。

　全てのＫＶ型データ１７１について処理が完了したと判定された場合、マスタローダ１４３は、特定された各分散ＫＶＳサーバ１０２にレコード更新要求を送信し（ステップＳ２３０６）、処理を終了する。具体的には、以下のような処理が実行される。

　マスタローダ１４３は、処理対象のサブファイル１８１１を選択する。マスタローダ１４３は、ステップＳ２３０４において生成されたリストを参照して、選択されたサブファイル１８１１を管理する分散ＫＶＳサーバ１０２に送信するＫＶ型データ１７１を抽出する。

　マスタローダ１４３は、選択されたサブファイル１８１１を管理する分散ＫＶＳサーバ１０２に、処理対象のサブファイル１８１１の識別情報、及び抽出されたＫＶ型データ１７１が含まれるレコード更新要求を送信する。以上がステップＳ２３０６の処理の説明である。

　図２４は、本発明の実施例２のレコード更新処理の一例を説明するフローチャートである。

　ファイルシステム１４４は、レコード更新要求を受信するとレコード更新処理を開始する。まず、ファイルシステム１４４は、処理対象のサブファイル１８１１に対応するＫＶ型データ構造情報１５３を取得する（ステップＳ２４０１）。ステップＳ２４０１の処理は、ステップＳ１４０１と同一の処理を用いる。

　ファイルシステム１４４は、ＫＶ型データ１７１のループ処理を開始する（ステップＳ２４０２）。ファイルシステム１４４は、レコード更新要求に含まれるＫＶ型データ１７１を一つ選択する。

　ファイルシステム１４４は、ＫＶ型データ１７１に対応するレコードの処理対象のサブファイル１８１１における位置を特定し、特定された位置にＫＶ型データ１７１を書き込む（ステップＳ２４０３）。具体的には、以下のような処理が実行される。

　ファイルシステム１４４は、取得されたＫＶ型データ構造情報１５３を参照し、キー９０２が選択されたＫＶ型データ１７１のキー３０２と一致するエントリを検索する。ファイルシステム１４４は、検索されたエントリのオフセット９０４に基づいて、選択されたＫＶ型データ１７１に対応するレコードの先頭のデータが含まれるブロックデータの番号を特定する。さらに、ファイルシステム１４４は、バリューサイズ９０３に基づいて特定されたブロックデータに含まれるレコードのデータを特定する。これによって、ＫＶ型データ１７１の位置及び書き込むデータが特定される。

　ファイルシステム１４４は、特定された位置に、特定されたデータ分だけＫＶ型データ１７１を上書きすることによって、更新されたＫＶ型データ１７１を処理対象のファイル１８１に反映させる。以上がステップＳ２４０３の処理の説明である。

　次に、ファイルシステム１４４は、レコード更新要求に含まれる全てのＫＶ型データ１７１について処理が完了した否かを判定する（ステップＳ２４０４）。

　全てのＫＶ型データ１７１について処理が完了していないと判定された場合、ファイルシステム１４４は、ステップＳ２４０２に戻り同様の処理を実行する。全てのＫＶ型データ１７１について処理が完了したと判定された場合、ファイルシステム１４４は、処理を終了する。

　実施例２によれば、ファイルのデータが複数のサーバにサブファイル１８１１として分散配置される場合でも、ＫＶ型データ１７１の更新又は削除結果をサブファイル１８１１に反映することができる。これによって、分散ファイルシステムと分散ＫＶＳとの連携が可能となり、ファイルＩ／Ｏ　ＡＰＩ及びＫＶ型データＡＰＩのいずれを用いても同一内容のデータにアクセスすることが可能となる。また、更新されたＫＶ型データ１７１をサブファイル１８１１に反映する場合、各分散ＫＶＳサーバ１０２が担当するレコードを決定しているため、サーバ間の通信量の増加を抑制し、分散ＫＶＳと分散ファイルシステムとの間の高速なデータ転送を実現することができる。

　なお、本発明は上記した実施例に限定されるものではなく、様々な変形例が含まれる。例えば、上記した実施例は本発明を分かりやすく説明するために詳細に説明したものであり、必ずしも説明した全ての構成を備えるものに限定されるものではない。また、ある実施例の構成の一部を他の実施例の構成に置き換えることが可能であり、また、ある実施例の構成に他の実施例の構成を加えることも可能である。また、各実施例の構成の一部について、他の構成の追加・削除・置換をすることが可能である。

　また、上記の各構成、機能、処理部、処理手段等は、それらの一部又は全部を、例えば集積回路で設計する等によりハードウェアで実現してもよい。また、上記の各構成、機能等は、プロセッサがそれぞれの機能を実現するプログラムを解釈し、実行することによりソフトウェアで実現してもよい。各機能を実現するプログラム、テーブル、ファイル等の情報は、メモリや、ハードディスク、ＳＳＤ（Ｓｏｌｉｄ　Ｓｔａｔｅ　Ｄｒｉｖｅ）等の記憶装置、又は、ＩＣカード、ＳＤカード、ＤＶＤ等の記憶媒体に置くことができる。

　また、制御線や情報線は説明上必要と考えられるものを示しており、製品上必ずしも全ての制御線や情報線を示しているとは限らない。実際には殆ど全ての構成が相互に接続されていると考えてもよい。

Claims

　ネットワークを介して接続される複数の計算機を備える計算機システムであって、
　前記複数の計算機の各々は、
　プロセッサ、前記プロセッサに接続されるメモリ及び前記プロセッサに接続されるネットワークインタフェースを有し、
　複数のレコードを含むファイルを一以上格納するストレージ装置と接続し、
　前記ストレージ装置に格納される前記ファイルを管理するファイルシステムと、
　前記複数の計算機が有する記憶領域を統合することによってデータ格納領域を一つ以上生成し、前記データ格納領域に配置されたキーバリュー型データを管理するキーバリュー型データ管理部と、
　前記ファイルを分割して、検索キーと前記レコードの内容を示すバリューとを対応づけることによって前記キーバリュー型データを生成し、前記生成されたキーバリュー型データを前記データ格納領域に分散して格納するローダと、を有し、
　前記キーバリュー型データ毎に、前記検索キー、前記バリューのサイズ、及び前記キーバリュー型データに対応する前記レコードのファイルにおける位置が対応付けられたキーバリュー型データ構造情報を保持し、
　前記ローダは、更新された前記キーバリュー型データの前記ファイルへの反映を指示する永続化指示を受け付けた場合、前記複数の計算機の各々の前記キーバリュー型データ管理部に、前記更新されたキーバリュー型データを取得するための読出要求を送信し、
　前記キーバリュー型データ管理部は、
　前記読出要求を受信した場合、前記データ格納領域を構成する前記記憶領域に格納される前記キーバリュー型データの中から前記更新されたキーバリュー型データを検索し、
　前記読出要求を送信した前記ローダに前記更新されたキーバリュー型データを送信し、
　前記ローダは、
　前記複数の計算機の各々のキーバリュー型データ管理部から取得された前記更新されたキーバリュー型データに基づいて、前記更新されたキーバリュー型データを反映させる処理対象のファイルを特定し、
　前記処理対象のファイルを格納する前記ストレージ装置と接続する前記計算機を特定し、
　前記特定された計算機に、前記更新されたキーバリュー型データを含むファイルの更新要求を送信し、
　前記ファイルシステムは、
　前記ファイルの更新要求を受信した場合、前記キーバリュー型データ構造情報に基づいて、前記更新されたキーバリュー型データに対応する前記レコードの前記ファイルにおける位置を特定し、
　前記特定されたファイルの位置に、前記更新されたキーバリュー型データを書き込むことによって前記ファイルを更新することを特徴とする計算機システム。
　請求項１に記載の計算機システムであって、
　前記読出要求は処理対象のデータ格納領域の識別情報を含み、
　前記複数の計算機の各々は、前記データ格納領域の識別情報を含む前記データ格納領域に格納される前記キーバリュー型データを管理するためのキーバリュー型データ管理情報を保持し、
　前記キーバリュー型データ管理部は、
　前記キーバリュー型データの更新要求を受け付けた場合、前記データ格納領域を構成する前記記憶領域に格納される前記キーバリュー型データを更新し、
　前記更新されたキーバリュー型データのリストであるダーティリストが生成されているか否かを判定し、
　前記ダーティリストが生成されていると判定された場合、新たに更新されたキーバリュー型データを前記ダーティリストに追加し、
　前記ダーティリストが生成されていないと判定された場合、前記ダーティリストを生成して、前記生成されたダーティリストへのポインタを前記キーバリュー型データ管理情報に設定し、
　前記読出要求を受信した場合、前記読出要求に含まれる前記データ格納領域の識別情報に一致する前記キーバリュー型データ管理情報を検索し、
　前記検索されたキーバリュー型データ管理情報の前記ダーティリストへのポインタに基づいて前記ダーティリストを参照して、前記処理対象のデータ格納領域に格納される前記キーバリュー型データの中から前記更新されたキーバリュー型データを取得することを特徴とする計算機システム。
　請求項２に記載の計算機システムであって、
　少なくとも一つの計算機は、前記ファイルの構成を管理するためのファイル管理情報を保持し、
　前記ファイル管理情報は、前記ファイルの識別情報及び前記ファイルを格納するストレージ装置の情報を含み、
　前記複数の計算機の各々は、前記データ格納領域の識別情報と、前記データ格納領域に格納される前記キーバリュー型データの元データである前記ファイルの識別情報とを対応付けたファイル配置情報を保持し、
　前記永続化指示には処理対象のデータ格納領域の識別情報が含まれ、
　前記ローダは、
　前記更新されたキーバリュー型データを取得した後、前記ファイル管理情報を取得し、
　前記永続化指示に含まれる前記処理対象のデータ格納領域の識別情報に対応する前記ファイル配置情報を参照して、前記処理対象のファイルを特定し、
　前記処理対象のファイルに対応する前記ファイル管理情報を取得し、
　前記処理対象のファイルに対応するファイル管理情報を参照して、前記処理対象のファイルを格納する前記ストレージ装置と接続する前記計算機を特定することを特徴とする計算機システム。
　請求項３に記載の計算機システムであって、
　前記少なくとも一つの計算機は、
　前記ファイルにおけるレコードの構造を定義するレコード定義情報を保持し、
　前記ファイル管理情報と前記レコード定義情報とを対応付けて管理し、
　前記ローダは、
　前記データ格納領域への新規ファイルの配置を指示するロード指示を受け付けた場合、前記ファイル管理情報及び前記レコード定義情報を取得し、
　前記ファイル管理情報を参照して、前記新規ファイルを格納する前記ストレージ装置と接続される前記計算機から当該新規ファイルを取得し、
　前記データ格納領域の識別情報と、前記新規ファイルの識別情報とを対応付けることによって前記ファイル配置情報を生成し、
　前記新規ファイルに含まれる前記複数のレコードの各々から前記複数のキーバリュー型データを生成し、
　前記レコード定義情報に基づいて、前記複数のレコードの各々の前記検索キー、前記バリューのサイズ、及び前記ファイルにおける前記レコードの位置を対応付けることによって、前記キーバリュー型データ構造情報を生成し、
　前記複数のキーバリュー型データ管理部の各々に、前記複数の前記データ格納領域への前記複数のキーバリュー型データの配置要求を送信し、
　前記複数の計算機に、前記ファイル配置情報及び前記キーバリュー型データ構造情報を送信することを特徴とする計算機システム。
　請求項２に記載の計算機システムであって、
　前記ストレージ装置に格納されるファイルは、一つのソースファイルが分割されたサブファイルであって、
　少なくとも一つの計算機は、前記サブファイルの構成を管理するためのファイル管理情報を保持し、
　前記ファイル管理情報は、前記サブファイルの識別情報及び前記サブファイルを格納するストレージ装置の識別情報を含み、
　前記複数の計算機の各々は、前記データ格納領域の識別情報と、前記データ格納領域に格納される前記キーバリュー型データの元データである前記サブファイルの識別情報とを対応付けたファイル配置情報を保持し、
　前記永続化指示には処理対象のデータ格納領域の識別情報が含まれ、
　前記ローダは、
　前記更新されたキーバリュー型データを取得した後、前記ファイル管理情報を取得し、
　前記永続化指示に含まれる前記処理対象のデータ格納領域の識別情報に基づいて前記ファイル配置情報を参照して、前記処理対象のソースファイルを特定し、
　前記処理対象のソースファイルに対応する前記ファイル管理情報を取得し、
　前記処理対象のソースファイルに対応するファイル管理情報を参照して、前記処理対象のソースファイルに対応する前記サブファイルを格納する前記ストレージ装置と接続する前記計算機を特定することを特徴とする計算機システム。
　請求項５に記載の計算機システムであって、
　前記少なくとも一つの計算機は、
　前記ファイルにおけるレコードの構造を定義するレコード定義情報を保持し、
　前記ファイル管理情報と前記レコード定義情報とを対応付けて管理し、
　前記ローダは、
　前記データ格納領域への新規ソースファイルの配置を指示するロード指示を受け付けた場合、前記ファイル管理情報及び前記レコード定義情報を取得し、
　前記ファイル管理情報に基づいて、前記新規ソースファイルが分割された前記複数のサブファイルを特定し、
　前記複数のサブファイル毎に、前記サブファイルを格納する前記ストレージ装置と接続する前記計算機を特定し、
　前記複数のサブファイル毎に、前記サブファイルに含まれる前記レコードを特定することによって、当該サブファイルを格納する前記ストレージ装置と接続する前記計算機が担当するレコードを決定し、
　前記決定されたレコードの情報を含む前記サブファイルの配置を指示するロード指示を前記計算機に送信し、
　前記ロード指示を受け付けた場合、前記ファイル管理情報及び前記レコード定義情報を取得し、
　前記ファイル管理情報を参照して、前記ストレージ装置から前記決定されたレコードを含む前記サブファイルを取得し、
　前記データ格納領域の識別情報と、前記サブファイルの識別情報とを対応付けることによって前記ファイル配置情報を生成し、
　前記サブファイルに含まれる前記複数のレコードの各々から前記複数のキーバリュー型データを生成し、
　前記レコード定義情報に基づいて、前記複数のレコードの各々の前記検索キー、前記バリューのサイズ、及び前記ファイルにおける前記レコードの位置を対応付けることによって、前記キーバリュー型データ構造情報を生成し、
　前記複数のキーバリュー型データ管理部の各々に、前記複数の前記データ格納領域への前記複数のキーバリュー型データの配置要求を送信し、
　前記複数の計算機に、前記ファイル配置情報及び前記キーバリュー型データ構造情報を送信することを特徴とする計算機システム。
　ネットワークを介して接続される複数の計算機を有する計算機システムにおけるデータ管理方法であって、
　前記複数の計算機の各々は、
　プロセッサ、前記プロセッサに接続されるメモリ及び前記プロセッサに接続されるネットワークインタフェースを有し、
　複数のレコードを含むファイルを一以上格納するストレージ装置と接続し、
　前記ストレージ装置に格納される前記ファイルを管理するファイルシステムと、
　前記複数の計算機が有する記憶領域を統合することによってデータ格納領域を一つ以上生成し、前記データ格納領域に配置されたキーバリュー型データを管理するキーバリュー型データ管理部と、
　前記ファイルを分割して、検索キーと前記レコードの内容を示すバリューとを対応づけることによって前記キーバリュー型データを生成し、前記生成されたキーバリュー型データを前記データ格納領域に分散して格納するローダと、を有し、
　前記キーバリュー型データ毎に、前記検索キー、前記バリューのサイズ、及び前記キーバリュー型データに対応する前記レコードのファイルにおける位置が対応付けられたキーバリュー型データ構造情報を保持し、
　前記データ管理方法は、
　前記ローダが、更新された前記キーバリュー型データの前記ファイルへの反映を指示する永続化指示を受け付けた場合、前記複数の計算機の各々の前記キーバリュー型データ管理部に、前記更新されたキーバリュー型データを取得するための読出要求を送信する第１のステップと、
　前記キーバリュー型データ管理部が、前記読出要求を受信した場合、前記データ格納領域を構成する前記記憶領域に格納される前記キーバリュー型データの中から前記更新されたキーバリュー型データを検索する第２のステップと、
　前記キーバリュー型データ管理部が、前記読出要求を送信した前記ローダに前記更新されたキーバリュー型データを送信する第３のステップと、
　前記ローダが、前記複数の計算機の各々のキーバリュー型データ管理部から取得された前記更新されたキーバリュー型データに基づいて、前記更新されたキーバリュー型データを反映させる処理対象のファイルを特定して、前記処理対象のファイルを格納する前記ストレージ装置と接続する前記計算機を特定する第４のステップと、
　前記ローダが、前記特定された計算機に、前記更新されたキーバリュー型データを含むファイルの更新要求を送信する第５のステップと、
　前記ファイルシステムが、前記ファイルの更新要求を受信した場合、前記キーバリュー型データ構造情報に基づいて、前記更新されたキーバリュー型データに対応する前記レコードの前記ファイルにおける位置を特定する第６のステップと、
　前記ファイルシステムが、前記特定されたファイルの位置に、前記更新されたキーバリュー型データを書き込むことによって前記ファイルを更新する第７のステップと、を含むことを特徴とするデータ管理方法。
　請求項７に記載のデータ管理方法であって、
　前記読出要求は処理対象のデータ格納領域の識別情報を含み、
　前記複数の計算機の各々は、前記データ格納領域の識別情報を含む前記データ格納領域に格納される前記キーバリュー型データを管理するためのキーバリュー型データ管理情報を保持し、
　前記データ管理方法は、
　前記キーバリュー型データ管理部が、前記キーバリュー型データの更新要求を受け付けた場合、前記データ格納領域を構成する前記記憶領域に格納される前記キーバリュー型データを更新するステップと、
　前記キーバリュー型データ管理部が、前記更新されたキーバリュー型データのリストであるダーティリストが生成されているか否かを判定するステップと、
　前記キーバリュー型データ管理部が、前記ダーティリストが生成されていると判定された場合、新たに更新されたキーバリュー型データを前記ダーティリストに追加するステップと、
　前記キーバリュー型データ管理部が、前記ダーティリストが生成されていないと判定された場合、前記ダーティリストを生成して、前記生成されたダーティリストへのポインタを前記キーバリュー型データ管理情報に設定するステップと、を含み、
　前記第２のステップは、
　前記読出要求に含まれる前記データ格納領域の識別情報に一致する前記キーバリュー型データ管理情報を検索するステップと、
　前記検索されたキーバリュー型データ管理情報の前記ダーティリストへのポインタに基づいて前記ダーティリストを参照して、前記処理対象のデータ格納領域に格納される前記キーバリュー型データの中から前記更新されたキーバリュー型データを取得するステップと、を含むことを特徴とするデータ管理方法。
　請求項８に記載のデータ管理方法であって、
　少なくとも一つの計算機は、前記ファイルの構成を管理するためのファイル管理情報を保持し、
　前記ファイル管理情報は、前記ファイルの識別情報及び前記ファイルを格納するストレージ装置の情報を含み、
　前記複数の計算機の各々は、前記データ格納領域の識別情報と、前記データ格納領域に格納される前記キーバリュー型データの元データである前記ファイルの識別情報とを対応付けたファイル配置情報を保持し、
　前記永続化指示には処理対象のデータ格納領域の識別情報が含まれ、
　前記第４のステップは、
　前記ファイル管理情報を取得するステップと、
　前記永続化指示に含まれる前記処理対象のデータ格納領域の識別情報に対応する前記ファイル配置情報を参照して、前記処理対象のファイルを特定するステップと、
　前記処理対象のファイルに対応する前記ファイル管理情報を取得するステップと、
　前記処理対象のファイルに対応するファイル管理情報を参照して、前記処理対象のファイルを格納する前記ストレージ装置と接続する前記計算機を特定するステップと、を含むことを特徴とするデータ管理方法。
　請求項９に記載のデータ管理方法であって、
　前記少なくとも一つの計算機は、
　前記ファイルにおけるレコードの構造を定義するレコード定義情報を保持し、
　前記ファイル管理情報と前記レコード定義情報とを対応付けて管理し、
　前記データ管理方法は、
　前記ローダが、前記データ格納領域への新規ファイルの配置を指示するロード指示を受け付けた場合、前記ファイル管理情報及び前記レコード定義情報を取得するステップと、
　前記ローダが、前記ファイル管理情報を参照して、前記新規ファイルを格納する前記ストレージ装置と接続される前記計算機から当該新規ファイルを取得するステップと、
　前記ローダが、前記データ格納領域の識別情報と、前記新規ファイルの識別情報とを対応付けることによって前記ファイル配置情報を生成するステップと、
　前記ローダが、前記新規ファイルに含まれる前記複数のレコードの各々から前記複数のキーバリュー型データを生成するステップと、
　前記ローダが、前記レコード定義情報に基づいて、前記複数のレコードの各々の前記検索キー、前記バリューのサイズ、及び前記ファイルにおける前記レコードの位置を対応付けることによって、前記キーバリュー型データ構造情報を生成するステップと、
　前記ローダが、前記複数のキーバリュー型データ管理部の各々に、前記複数の前記データ格納領域への前記複数のキーバリュー型データの配置要求を送信するステップと、
　前記ローダが、前記複数の計算機に、前記ファイル配置情報及び前記キーバリュー型データ構造情報を送信するステップと、を含むことを特徴とするデータ管理方法。
　請求項８に記載のデータ管理方法であって、
　前記ストレージ装置に格納されるファイルは、一つのソースファイルが分割されたサブファイルであって、
　少なくとも一つの計算機は、前記サブファイルの構成を管理するためのファイル管理情報を保持し、
　前記ファイル管理情報は、前記サブファイルの識別情報及び前記サブファイルを格納するストレージ装置の識別情報を含み、
　前記複数の計算機の各々は、前記データ格納領域の識別情報と、前記データ格納領域に格納される前記キーバリュー型データの元データである前記サブファイルの識別情報とを対応付けたファイル配置情報を保持し、
　前記永続化指示には処理対象のデータ格納領域の識別情報が含まれ、
　前記第４のステップは、
　前記更新されたキーバリュー型データを取得した後、前記ファイル管理情報を取得するステップと、
　前記永続化指示に含まれる前記処理対象のデータ格納領域の識別情報に基づいて前記ファイル配置情報を参照して、前記処理対象のソースファイルを特定するステップと、
　前記処理対象のソースファイルに対応する前記ファイル管理情報を取得するステップと、
　前記処理対象のソースファイルに対応するファイル管理情報を参照して、前記処理対象のソースファイルに対応する前記サブファイルを格納する前記ストレージ装置と接続する前記計算機を特定するステップと、を含むことを特徴とするデータ管理方法。
　請求項１１に記載のデータ管理方法であって、
　前記少なくとも一つの計算機は、
　前記ファイルにおけるレコードの構造を定義するレコード定義情報を保持し、
　前記ファイル管理情報と前記レコード定義情報とを対応付けて管理し、
　前記データ管理方法は、
　前記ローダが、前記データ格納領域への新規ソースファイルの配置を指示するロード指示を受け付けた場合、前記ファイル管理情報及び前記レコード定義情報を取得するステップと、
　前記ローダが、前記ファイル管理情報に基づいて、前記新規ソースファイルが分割された前記複数のサブファイルを特定するステップと、
　前記ローダが、前記複数のサブファイル毎に、前記サブファイルを格納する前記ストレージ装置と接続する前記計算機を特定するステップと、
　前記ローダが、前記複数のサブファイル毎に、前記サブファイルに含まれる前記レコードを特定することによって、当該サブファイルを格納する前記ストレージ装置と接続する前記計算機が担当するレコードを決定するステップと、
　前記ローダが、前記決定されたレコードの情報を含む前記サブファイルの配置を指示するロード指示を前記計算機に送信するステップと、
　前記ローダが、前記ロード指示を受け付けた場合、前記ファイル管理情報及び前記レコード定義情報を取得するステップと、
　前記ローダが、前記ファイル管理情報を参照して、前記ストレージ装置から前記決定されたレコードを含む前記サブファイルを取得するステップと、
　前記ローダが、前記データ格納領域の識別情報と、前記サブファイルの識別情報とを対応付けることによって前記ファイル配置情報を生成するステップと、
　前記ローダが、前記サブファイルに含まれる前記複数のレコードの各々から前記複数のキーバリュー型データを生成するステップと、
　前記ローダが、前記レコード定義情報に基づいて、前記複数のレコードの各々の前記検索キー、前記バリューのサイズ、及び前記ファイルにおける前記レコードの位置を対応付けることによって、前記キーバリュー型データ構造情報を生成するステップと、
　前記ローダが、前記複数のキーバリュー型データ管理部の各々に、前記複数の前記データ格納領域への前記複数のキーバリュー型データの配置要求を送信するステップと、
　前記複数の計算機に、前記ファイル配置情報及び前記キーバリュー型データ構造情報を送信するステップと、を含むことを特徴とするデータ管理方法。