JPWO2013018808A1 - 分散ストレージシステムおよび方法 - Google Patents

Abstract

本発明は、分散ストレージにおけるデータ複製において可用性を確保するとともに、書き込み性能と読み出し側の処理性能の両者の向上を可能とする分散ストレージシステムと方法の提供する。それぞれがデータ格納部（１２、２２、３２、４２）を備え、ネットワーク結合される複数のデータノード（１、２、３、４）を備え、データの更新要求に対してデータ複製先のデータノード（１、２、３、４）では、更新対象のデータを一旦書き込み用の中間データ保持構造に格納し、更新要求とは非同期でそれぞれ目的のデータ構造に変換してデータ格納部（１２、２２、３２、４２）に格納する。前記データノードへのアクセスの履歴情報を記憶するアクセス履歴記録部（７１−１〜４）を備え、前記データノードで非同期に行われる前記目的のデータ構造への変換の実行の契機となる契機情報を、前記アクセス履歴記録部に記憶されたアクセス履歴情報に基づき、可変させる。

Description

（関連出願についての記載）
本発明は、日本国特許出願：特願２０１１−１６９５８８号（２０１１年８月２日出願）の優先権主張に基づくものであり、同出願の全記載内容は引用をもって本書に組み込み記載されているものとする。
本発明は、分散ストレージに関し、特に、データ構造の制御が可能な分散ストレージシステム、および方法と装置に関する。

複数の計算機（データノード、あるいは単に「ノード」ともいう）をネットワーク結合し、各計算機のデータ格納部（ＨＤＤ（Ｈａｒｄ Ｄｉｓｋ Ｄｒｉｖｅ）やメモリ等）にデータを格納して利用するシステムを実現する分散ストレージシステム（Ｄｉｓｔｒｉｂｕｔｅｄ Ｓｔｏｒａｇｅ Ｓｙｓｔｅｍ）が利用されている。

一般的な分散ストレージ技術では、
・データをどの計算機（ノード）に配置するか、
・処理をどの計算機（ノード）で行うか、
といった判断をソフトウェアや特別な専用ハードウェア等により実現している。分散ストレージシステムにおいて、システムの状態に対して、その動作を動的に変更することで、システム内のリソース使用量を調整し、システム利用者（クライアント計算機）に対する性能を向上している。

分散ストレージシステムにおいては、データが複数のノードに分散しているため、データにアクセスしようとするクライアントは、まず、当該データを保持しているノードがどれであるかを知る必要がある。またデータにアクセスしようとするクライアントは、当該データをもつノードが複数ある場合、どのノード（一つ以上）にアクセスするかを知る必要がある。

分散ストレージシステムでは、一般に、ファイル管理として、ファイル本体と、当該ファイルのメタデータ（ファイルの格納場所、ファイルサイズ、オウナー等）を別々に保存する方式が用いられている。

分散ストレージシステムにおいて、データを保持しているノードをクライアントが知るための技術の一つとしてメタサーバ方式が知られている。メタサーバ方式では、データの位置情報を管理する、一つ又は複数（ただし、少ない数）の計算機により構成されたメタサーバを設ける。しかしながら、メタサーバ方式の分散ストレージシステムでは、システムの構成の大規模化に伴って、データを保持しているノードの位置を検出する処理を行うメタサーバの処理性能が足りず（メタサーバ１台当りで管理するノード数が膨大となり、該メタサーバの処理性能が追いつかない）、導入したメタサーバがアクセス性能上のボトルネックとなる可能性もある。

＜分散ＫＶＳ＞
データを保持しているノードの位置を知るための別の手法（技術）として、分散関数（例えば、ハッシュ関数）を用いてデータの位置を求めるものがある。この種の手法は、例えば分散ＫＶＳ（Ｋｅｙ Ｖａｌｕｅ Ｓｔｏｒｅ：キー・バリュー・ストア）で利用されている。分散ＫＶＳとは、連想配列のような「Ｋｅｙ（キー）」と「Ｖａｌｕｅ（値）」のペアからなるシンプル（ｓｉｍｐｌｅ）なデータモデルのストレージ機能を、複数ノードで実現する分散ストレージシステムの一種である。分散ＫＶＳ手法に基づく分散ストレージシステム（分散ＫＶＳシステムともいう）では、全てのクライアントで、分散関数と、システムに参加しているノードのリスト（ノードリスト）とを共有する。また、格納データは、固定長あるいは任意長のデータ断片（Ｖａｌｕｅ）に分かれている。各データ断片には、該データ断片を一意に特定可能な識別子が付与され、データ断片の配置場所を識別子と分散関数を用いて決定する。例えば、ハッシュ関数によりキーの値に応じて保存先のノード（サーバ）は異なるため、複数のノードにデータを分散保存することが可能となる。また、分散関数が同一ならば、同一キーに基づく保存先が常に同一となるため、アクセスするクライアントはデータアクセス先を容易に把握することができる。簡潔な分散ＫＶＳシステムでは、Ｋｅｙを識別子とし、Ｋｅｙに対応したＶａｌｕｅを格納データの単位とすることで、ＫｅｙとＶａｌｕｅに基づくデータアクセス機能を実現する。

分散ＫＶＳ手法に基づく分散ストレージシステムでは、各クライアントは、データにアクセスする際、キーを分散関数の入力値とし、分散関数の出力値とノードリストを基に、データを格納しているノードの位置を算術的に求める。

分散ＫＶＳ手法に基づく分散ストレージシステムでは、クライアント間で共有する情報のうち、分散関数は、基本的に、時間が経過しても変化しない（時不変）。一方、ノードリストの内容は、ノードの故障や追加に伴い、随時、変更される。このため、クライアントは、それらの情報に対して任意の方法でアクセス出来ることが、必要である。

＜レプリケーション＞
分散ストレージシステムにおいては、可用性（Ａｖａｉｌａｂｉｌｉｔｙ：システムが連続して動作できる能力）確保のために、データの複製を複数ノードで保持し、データの複製を、負荷分散に活用することが一般的に行われている。

なお、作成するデータの複製を用いて負荷分散を実現する技術が特許文献１に開示されている。また、特許文献２には、サーバが情報構造定義部で情報構造定義体を定義し、登録用クライアントは情報構造定義体によりデータベースを構築し、データベースアクセスツールを生成し、このツールを用いてデータベースに情報を登録する構成が開示されている。また特許文献３には、分散型ストレージシステムにおいて、各複製がそれぞれ固有のロケータ値を介してアクセス可能なオブジェクトの複製を保存するストレージノードと、各オブジェクトに対するそれぞれのキーマップエントリを保存するキーマップインスタンスを含み、所定のオブジェクトについてはそれぞれのキーマップエントリは、オブジェクトの複製と、対応するキー値、各ロケータを含む構成が開示されている。さらに、特許文献４（共同発明者に本願発明者を含む）には、データが更新されるたびに、その変更内容を時系列的に保存し、ストレージに対するデータ書き込みをトラッキング、キャプチャし、データ更新が発生したとき、その変更内容を、二次ストレージ（変更履歴データベース）にジャーナリングしていくことで、過去のどの時点のデータも再現することができ（Any Point In Time（APIT）Recovery）、データ損失を回避することができるＣＤＰ（Ｃｏｎｔｉｎｕｏｕｓ Ｄａｔａ Ｐｒｏｔｅｃｔｉｏｎ；継続的データ保護）が開示されている。特許文献４では、データの更新が発生したとき、変更内容をログとして時系列的に記録していくことで、過去の時点のデータを復元自在としてなる、データ保護機能を具備したストレージシステムであって、ストレージへのアクセスの履歴情報の解析結果、及び／又は、外部から通知された情報に基づき、データ・アクセスに関する所定の契機を抽出し、前記抽出された所定の契機に対応するデータを、前記ストレージに記憶保持されているデータとログ情報とから作成し、該作成したデータを、前記所定の契機に対応したデータとして、前記ストレージに記憶する。

特開２００６−１２００５号公報（特許第４５２８０３９号） 特開平１１−１９５０４４号公報（特許第３９１１８１０号） 特表２００９−５２２６５９号公報 特開２００７−３１７０１７号公報

上記各特許文献の各開示は引用によって本明細書に組み込まれる。以下に関連技術の分析を与える。

関連技術の分散ストレージシステムでは、可用性保持のためにデータの複製を複数ノードで保持するが、複数のノードにおいて同一の物理構造で保持している。これにより、分散ストレージシステムにおいてアクセス応答性能と可用性の保証を実現している。しかしながら、複数のノードにおいて複製データを同一の物理構造で保持しているため、例えばデータを参照（ｒｅａｄ）して解析するアプリケーションのうち、当該データを、保持されている複製データのデータ構造と異なるデータ構造で利用するアプリケーション等に対しては、別のデータ構造への変換、及び、別のデータ構造を保持するためのストレージを用意しなければならない。別のデータ構造への変換は、処理負荷、処理遅延の増大を招き、別のデータ構造を保持するためのストレージ容量の増大となる。

その際、例えばデータのＷｒｉｔｅ（書き込み、更新）と、当該データの目的のデータ構造への変換の実行に関して特別な工夫を施すことで、特段の性能の向上が期待できることを、本願発明者らは知見したので、今回、これを提案する。

本発明の目的は、分散ストレージにおけるデータ複製において可用性を確保するとともに、書き込み性能と読み出し側の処理性能の両者の向上を可能とする、分散ストレージシステムと方法を提供することにある。

本発明によれば、上記問題点の少なくとも１つの解決を図るため、概略以下の構成とされる（ただし、以下に制限されない）。

本発明によれば、それぞれがデータ格納部を備え、ネットワーク結合される複数のデータノードを備え、データ更新要求に対してデータの複製先のデータノードでは、更新対象のデータを一旦、書き込みデータ保持用の中間構造に格納し、更新要求とは非同期で、それぞれ目的のデータ構造に変換して前記データ格納部に格納し、
前記データノードへのアクセスの履歴情報を記憶するアクセス履歴記録部を備え、
前記データノードで非同期に行われる前記目的のデータ構造への変換の実行の契機となる契機情報を、前記アクセス履歴記録部に記録されたアクセス履歴情報に基づき、可変させる手段を備えている、分散ストレージシステムが提供される。

本発明によれば、それぞれがデータ格納部を備え、ネットワーク結合される複数のデータノードを備えた分散ストレージのデータ複製において、
データ更新要求に対応したデータの複製にあたり、複製先のデータノードでは、
更新対象のデータを、一旦、書き込みデータ保持用の中間構造に格納し、更新要求とは非同期で、それぞれ目的のデータ構造に変換して前記データ格納部に格納し、
前記データノードで非同期に行われる前記目的のデータ構造への変換の実行の契機となる契機情報を、前記データノードのアクセス履歴情報に基づき、可変させる、分散ストレージのデータ複製方法が提供される。

本発明によれば、分散ストレージにおけるデータ複製において可用性を確保するとともに、書き込み性能と読み出し側の処理性能の両者の向上を可能としている。

本発明の例示的な一実施の形態のシステム構成を示す図である。 本発明の例示的な一実施形態のデータノードの構成例を示す図である。 本発明の例示的な一実施形態におけるデータ構造管理情報９２１を模式的に示す図である。 本発明の例示的な一実施形態におけるテーブルのデータ保持構造の一例を模式的に示す図である。 本発明の例示的な一実施形態におけるデータ配置特定情報９２２の例を示す図である。 データ保持、非同期更新を模式的に説明する図である。 図６におけるＷｒｉｔｅ処理と解析系の処理を模式的に説明する図である。 本発明の例示的な一実施形態におけるデータ保持、非同期更新を模式的に説明する図である。 本発明の例示的な一実施形態のアクセス履歴記録部と構造情報管理手段の構成例を示す図である。 本発明の例示的な一実施形態におけるクライアント機能実現手段６１におけるアクセス処理の動作を説明するフローチャートである。 本発明の例示的な一実施形態におけるデータノードにおけるアクセス処理の動作を説明するフローチャートである。 本発明の例示的な一実施形態におけるデータ変換処理を説明するフローチャートである。 本発明の例示的な一実施形態におけるＷｒｉｔｅ処理の動作シーケンスを説明する図（その１）である。 本発明の例示的な一実施形態におけるＷｒｉｔｅ処理の動作シーケンスを説明する図（その２）である。 本発明の例示的な別の実施形態を説明する図である。 本発明の例示的なさらに別の実施形態を説明する図である。

発明を実施するための好ましいいくつかの形態について説明する。いくつかの好ましい形態において、それぞれがデータ格納部を備え、ネットワーク結合される複数のデータノードを備え、例えばデータ更新時のデータの複製にあたり、複製先のデータノードでは、更新対象のデータを、一旦、書き込みデータ保持用の中間構造（Ｑｕｅｕｅ（待ち行列）、ＦＩＦＯ（Ｆｉｒｓｔ Ｉｎ Ｆｉｒｓｔ Ｏｕｔ）、Ｌｏｇ（ログ）等）に格納し、更新要求とは非同期で、それぞれ目的のデータ構造に変換して前記データ格納部（１２）に格納する。さらに、前記データノードは、前記データノードへのアクセス頻度の履歴を記憶するアクセス履歴記録部（７１）を備えている。前記データノードにおいて、前記データノードで非同期に行われる前記目的のデータ構造への変換の実行の契機となる契機情報を、前記アクセス履歴記録部（７１）に記憶されたアクセス履歴情報（アクセス頻度）に基づき、可変に設定する。

いくつかの好ましい形態において、複製先の前記データノードは、それぞれ、前記中間構造に、前記データを保持して、応答を返し、前記中間構造に保持されるデータ構造を、前記更新対象のデータの受信から前記契機情報で規定される時間経過時に、目的のデータ構造に非同期で変換した上で前記データ格納部に格納する構成としてもよい。

いくつかの好ましい形態において、予め定められたテーブル単位で、データ配置先のデータノード、配置先のデータノードにおける目的のデータ構造を制御するようにしてもよい。

いくつかの好ましい形態において、格納対象のデータを識別する識別子であるテーブル識別子に対応させて、複製を特定するレプリカ識別子と、前記レプリカ識別子に対応したデータ構造の種類を特定するデータ構造情報と、指定されたデータ構造に変換して格納されるまでのタイマ情報である契機情報と、を、前記データ構造の種類の数に対応させて備えたデータ構造管理情報（図２の９２１：図３）と、
前記テーブル識別子に対応して、前記レプリカ識別子と、前記レプリカ識別子に対応した１つ又は複数のデータ配置先のデータノード情報とを備えたデータ配置特定情報（図２の９２２：図５）と、を記憶管理する構造情報保持部（９２）を有する構造情報管理装置（９）と、前記データ構造管理情報と前記データ配置特定情報とを参照して、更新処理及び参照処理のアクセス先を特定するデータアクセス部を備えたクライアント機能実現部（６１）と、それぞれが前記データ格納部（１２）を備え、前記構造情報管理装置（９）と前記クライアント機能実現部（６１）とに接続される複数の前記データノード（１〜４）と、を備えている。前記データノードは、前記クライアント機能実現部（６１）からのアクセス要求に基づき、更新処理を行う場合に、一旦中間構造にデータを保持した上で前記クライアント機能実現部（６１）に応答を返すアクセス受付・処理部（１１１、１１２）と、前記データ構造管理情報を参照し、指定された更新契機に応答して、前記中間構造に保持されるデータを、前記データ構造管理情報で指定されたデータ構造に変換する処理を行うデータ構造変換部（１１３）とを備えたデータ管理・処理部（１１）構成としてもよい。

いくつかの好ましい形態において、前記アクセス履歴記録部（７１）に記録されたアクセス情報、又は、前記アクセス情報を加工して得た別のアクセス情報を用いて、前記構造情報保持部の前記データ構造管理情報（９２１）の更新契機情報を変更するか否か判定し、前記データ構造管理情報（９２１）の更新契機情報を変更する場合、前記構造情報管理装置に通知する変更判定部（７２）を備え、前記構造情報管理装置（９）は、変更判定部（７２）からの前記更新契機情報の変更の通知を受け、前記データ構造管理情報の更新契機情報を変更する構造情報変更部（９１）を備える。好ましい形態において、前記アクセス履歴記録部（７１）に、アクセス情報としてアクセス頻度を記録するようにしてもよい。

いくつかの好ましい形態において、前記アクセス履歴記録部（７１）に記録されたアクセス情報が、前記データ格納部からの読み出しアクセスと、前記中間構造へのデータの書き込みアクセスの頻度情報を含む（あるいは、アクセスの発生パタン、アクセス発生の傾向を示す情報等であってもよい）。

いくつかの好ましい形態において、前記データノードは、アクセス受付部（１１１）、アクセス処理部（１１２）、及び、データ構造変換部（１１３）を備えている。前記データノードの前記データ格納部（１２）は、構造別データ格納部（１２１〜１２３）を備え、前記アクセス受付部（１１１）は、前記クライアント機能実現部からの更新要求を受け付け、前記データ配置特定情報においてレプリカ識別子に対応して指定されているデータノードに対して更新要求を転送し、さらにアクセス履歴記録部にアクセス要求をログし、前記データノードの前記アクセス処理部（１１２）は、受け取った更新要求の処理を行い、前記データ構造管理情報の情報を参照して更新処理を実行する。その際、前記データ構造管理情報の情報から、前記データノードに対する前記更新契機情報が零の場合、更新データを、前記データ構造管理情報に指定されるデータ構造に変換して、前記構造別データ格納部に格納し、前記更新契機が零でない場合、前記中間構造に、一旦、更新データを書き込み、処理完了を応答し、
前記アクセス受付部（１１１）は、
前記アクセス処理部からの完了通知（図１４）、又は、
前記アクセス処理部からの完了通知、及びレプリカ先の各データノードからの完了通知（図１３）、
を受けると、前記クライアント機能実現部（９）に対して応答し、
前記データ構造変換部（１１３）は、前記中間構造に保持されたデータを、前記データ構造管理情報に指定されているデータ構造に変換し変換先の前記構造別データ格納部（１２１〜１２３）に格納するようにしてもよい。

以下例示的ないくつかの実施形態について説明する。

＜システム構成＞
図１は、本発明の例示的な一実施形態のシステム構成の一例を示す図である。データノード１〜４、ネットワーク５、クライアントノード６、構造情報管理手段（構造情報管理装置）９を備える。

データノード１〜４は、分散ストレージを構成するデータ格納ノードであり、１つ以上の任意の数によって構成される。ネットワーク５は、データノード１〜４を含むネットワークノード間の通信を実現する。クライアントノード６は、分散ストレージにアクセスする計算機ノードである。クライアントノード６は必ずしも独立して存在しなくてもよい。なお、データノード１〜４がクライアント計算機を兼ねる例は、図２を参照して後述される。データノード１〜４は、それぞれ、データ管理・処理手段（データ管理・処理部）１１、２１、３１、４１、データ格納部１２、２２、３２、４２、アクセス履歴記録部７１−１〜７１−４を備える。

データ管理・処理手段Ｘ１（Ｘ＝１、２、３、４）は、分散ストレージに対するアクセス要求を受け付け、処理を実行する。データ格納部Ｘ２（Ｘ＝１、２、３、４）はデータノードの担当するデータの保持、記録を行う。

クライアントノード６は、クライアント機能実現手段（クライアント機能実現部）６１を備える。クライアント機能実現手段６１は、データノード１〜４によって構成される分散ストレージにアクセスする。クライアント機能実現手段６１は、データアクセス手段（データアクセス部）６１１を備える。

データアクセス手段（データアクセス部）６１１は、構造情報管理手段９から構造情報（データ構造管理情報とデータ配置特定情報）を取得し、その構造情報を用いて、アクセス先のデータノードを特定する。

なお、各データノード１〜４やネットワーク５内の任意の装置（スイッチ、中間ノード）において、構造情報管理手段９の構造情報保持部９２に格納される構造情報の一部又は全てを自装置内又は他の装置内のキャッシュ（不図示）に保持するようにしてもよい。

構造情報保持部９２に格納される構造情報に対するアクセスは、自装置内又は予め定められた所定の場所に配設されたキャッシュ（不図示）に対してアクセスするようにしてもよい。キャッシュ（不図示）に格納された構造情報の同期については、公知の分散システムの技術が適用できるため、ここでは詳細は省略する。よく知られているように、キャッシュを利用することでストレージ性能を高速化することが出来る。

構造情報管理手段（構造情報管理装置）９は、構造情報を変更する構造情報変更手段９１と、構造情報を保持する構造情報保持部９２を備える。構造情報保持部９２は、データ構造管理情報９２１（図２参照）とデータ配置特定情報９２２を含む（図４参照）。データ構造管理情報９２１は、後に図３を参照して説明されるが、テーブル識別子に対して、複製を特定するレプリカ識別子と、前記レプリカ識別子に対応したデータ構造の種類を特定するデータ構造情報と、指定されたデータ構造として格納されるまでの時間情報である更新契機からなるエントリをデータの複製数分有する。データ配置特定情報９２２は、後に図５を参照して説明されるが、テーブル識別子に対応して、前記レプリカ識別子と、前記レプリカ識別子に対応した１つ又は複数のデータ配置先のデータノード情報を有する。

アクセス履歴記録部７１−１〜４は、データノード１〜４のＲｅａｄアクセス、Ｗｒｉｔｅアクセスのログ情報を記録する。アクセスのログ情報として、所定期間内のアクセスの回数に対応する頻度情報を格納するようにしてもよい。

なお、図１では、クライアントノード６がデータノード１〜４とは独立に（別々に）設けられているが、クライアントノード６をデータノード１〜４と独立に（分離させて）設けることは必ずしも必要とされない。つまり、以下、変形例として説明するように、データノード１〜４のうち、任意の１つ以上のノードに、クライアント機能実現手段６１を備えた構成としてもよい。

＜データノードの構成例＞
図２は、図１の構成例詳細に説明する図である。図２には、図１のデータノード１〜４を中心に示した構成が示されている。図１のデータノード１〜４は基本的に同一構成とされるため、図２では、データノード１のデータ管理・処理手段１１、データ格納部１２、アクセス履歴記録部７１（図１の７１−１に対応）が示されている。なお、図２等の図面において、簡単化のため、構造情報保持部９２に格納される構造情報は参照符号９２で参照される場合がある。

データノード１のデータ管理・処理手段１１は、アクセス受付手段（アクセス受付部）１１１、アクセス処理手段（アクセス処理部）１１２、データ構造変換手段（データ構造変換部）１１３を備えている。他のデータノード２〜４のデータ管理・処理手段２１、３１、４１も同様の構成とされる。

アクセス受付手段１１１は、データアクセス手段６１１からアクセス要求を受け付け、処理完了後にデータアクセス手段６１１に応答を返す。

アクセス処理手段１１２は、構造情報保持部９２の構造情報（あるいはその任意の場所に保持されるキャッシュ情報）を用い、アクセス処理を、該当するデータ格納部１２Ｘ（Ｘ＝１、２、３）に対して行う。

アクセス受付手段１１１は、アクセス要求（アクセスコマンド）の情報を、例えば受付時間情報とともに、アクセス履歴記録部７１に記録する。

データ構造変換手段１１３は、一定契機毎に構造別データ格納部１２１のデータを用いて、構造別データ格納部１２Ｘ（Ｘ＝１、２、３）に変換する。

データ格納部１２は、複数種の構造別データ格納部を備えている。特に制限されないが、図２では、構造別データ格納部１２１（データ構造Ａ）、構造別データ格納部１２２（データ構造Ｂ）、構造別データ格納部１２３（データ構造Ｃ）を備える。どのようなデータ構造を選択するかは、構造別データ格納部１２Ｘ（Ｘ＝１、２、３）単位で任意である。

構造別データ格納部１２１（例えばデータ構造Ａ）は、データの書き込みを伴う処理（データの追加や更新）に対する応答性能に特化した構造をとる。具体的には、データ変更内容をキュー（例えばＦＩＦＯ（Ｆｉｒｓｔ Ｉｎ Ｆｉｒｓｔ Ｏｕｔ））として高速なメモリ（デュアルポートＲＡＭ（Random Access Memory）等）上に保持するソフトウェア、アクセス要求処理内容を任意の記憶媒体にログとして追記するソフトウェア等が実装される。データ構造Ｂ、データ構造Ｃは、データ構造Ａとは異なるデータ構造であり、互いに異なるデータアクセス特性を持つ。なお、データ格納部１２は、必ずしも単一の記憶媒体でなくてもよい。図４のデータ格納部１２を複数のデータ配置ノードからなる分散ストレージシステムとして実現し、各構造別データ格納部１２Ｘを分散して格納する方式であってもよい。

データ配置特定情報９２２は、分散ストレージに格納するデータ、あるいはデータ断片の格納先を特定するための情報（および情報を格納、取得する手段）である。データの分散配置方式は、前述した通り、例えばメタサーバ方式や分散ＫＶＳ方式が利用される。

メタサーバ方式の場合、データの位置情報を管理する情報（例えばブロックアドレスとその対応するデータノードアドレス）がデータ配置特定情報９２２である。メタサーバは、この情報（メタデータ）を参照することで、必要なデータの配置先を知ることが出来る。

前述した分散ＫＶＳ方式の場合、システムに参加するノードのリストが、このデータ配置特定情報に該当する。データを格納する識別子と、ノードリスト情報を用いることによって、データ格納先のデータノードを決定することが出来る。

データアクセス手段６１１は、構造情報管理手段９におけるデータ配置特定情報９２２、あるいは、予め定められた所定の場所に記憶されるデータ配置特定情報９２２のキャッシュ情報を用いてアクセスすべきデータノード１〜４を特定し、データノードのアクセス受付手段１１１に対して、アクセス要求を発行する。

＜データ構造管理情報＞
図２のデータ構造管理情報９２１は、データの集合毎にデータの格納方式を特定するためのパラメータ情報である。図３は、図２のデータ構造管理情報９２１の一例を示す図である。特に制限されるものではないが、図３に示す例では、データの格納方式を制御する単位を、テーブルとする。そして、テーブル毎（テーブル識別子毎）に、レプリカ識別子、データ構造の種別、更新契機の各情報を、データ複製の複製数分、用意する。

図３（Ａ）では、各テーブルは、可用性確保（保持）のために、３つの複製を保持する（ただし、複製数は３に制限されるものでない）。レプリカ識別子は、それぞれの複製を特定する情報であり、図３（Ａ）では、０、１、２として付与されている。データ構造は、データの格納方式を示す情報である。図３（Ａ）では、３種類のデータ構造（Ａ、Ｂ、Ｃ）をレプリカ識別子毎に異なる方式を指定している。

図３（Ｂ）にデータ構造Ａ、Ｂ、Ｃのデータ格納方式の例を示す（ただし、これらの格納方式に制限されるものでない）。図３（Ｂ）の例では、データの格納方式の種類として、
Ａ：キュー、
Ｂ：ロウストア、
Ｃ：カラムストア
が指定されている。図３（Ｂ）の例では、テーブル識別子「Ｓｔｏｃｋｓ」のレプリカ識別子０は、データ構造Ｂ（ロウストア）として格納される。

データ構造は、それぞれデータを格納するための方式であり、
Ａ：キュー（ｑｕｅｕｅ）は、リンクトリスト（Ｌｉｎｋｅｄ Ｌｉｓｔ）である。

Ｂ：ロウストア（ＲＯＷ ＳＴＯＲＥ）は、テーブルのレコードを行（ＲＯＷ）順に格納する。

Ｃ：カラムストア（ＣＯＬＵＭＮ ＳＴＯＲＥ）は、列（ＣＯＬＵＭＮ）順に格納する。

＜テーブル構成例＞
図４は、テーブルのデータ保持構造の一例を模式的に示す図である。図４の（Ａ）のテーブルは、Ｋｅｙカラムと、３つのＶａｌｕｅカラムを備え、各ローは、Ｋｅｙと３つのＶａｌｕｅのセットからなる。

カラムストア、ロウストアは、それぞれ、記憶媒体上の格納順序を行（ロウ）ベース、列（カラム）ベースに格納されている形式である。テーブル（図４の（Ａ）参照）の格納方式として、
レプリカ識別子０と１のデータとして、データ構造Ｂ（ロウストア）で保持し（図４の（Ｂ）、（Ｃ）参照）、
レプリカ識別子２のデータとして、データ構造Ｃ（カラムストア）として保持する（図４の（Ｄ）参照）。

＜更新契機情報＞
再び図３（Ａ）を参照すると、データ構造管理情報９２１（図２参照）における更新契機は、データを指定されたデータ構造として格納されるまでの時間契機である。Ｓｔｏｃｋｓのレプリカ識別子０の例では３０ｓｅｃと指定されている。したがって、Ｓｔｏｃｋｓのレプリカ識別子０のデータ構造Ｂ（ロウストア）を格納するデータノードにおいて、ロウストア方式の構造別データ格納部１２２に対して、データの更新が反映されるのが３０ｓｅｃ契機であることを示す。データ更新が反映されるまでの間は、キュー等の中間構造としてデータが保持される。また、データノードでは、クライアントからの要求に対しても、中間構造に格納して応答が行われる。本実施形態では、指定されたデータ構造への変換は、更新要求に対して、非同期（Ａｓｙｎｃｈｒｏｎｏｕｓ）で行われる。

以下では、データノード間の更新対象データの転送を同期方式で行い、データ構造のターゲット構造への変換は非同期で行う。非同期でデータ構造を変換する更新契機情報としてタイマを用いた例を説明する（ただし、本発明は、以下の実装に制限されるものでない）。

＜データ配置特定情報＞
図５は、図２のデータ配置特定情報９２２の一例を示す図である。各テーブル識別子のレプリカ識別子０、１、２（図３参照）のそれぞれに対して、配置ノード（データ格納先のデータノード）が指定されている。これは、前述したメタサーバ方式に対応している。分散ＫＶＳ方式の場合、データ配置特定情報９２２は、分散ストレージに参加しているノードリスト情報（不図示）が該当する。このノードリスト情報をデータノード間で共有することによって、例えば「テーブル識別子」＋「レプリカ識別子」をキー情報として、コンシステント・ハッシング方式により、配置ノードを特定することが出来る。また、レプリカの配置先として、コンシステント・ハッシング方式における隣接ノードに格納することができる。

＜Ｗｒｉｔｅ中間構造：比較例＞
図６は、テーブルのデータ保持、非同期更新の基本形式を模式的に説明する図である。図６は、本発明で解決されることになる問題点を説明するための図、したがって、本発明の比較例を説明するための図でもある。

更新契機情報の値が０よりも大きい場合には、各データノードは、Ｗｒｉｔｅ（更新要求）の応答速度に優れた構造を中間構造（「Ｗｒｉｔｅ優先構造」、あるいは「Ｗｒｉｔｅ中間構造」ともいう）として持ち、更新内容を受け付ける。Ｗｒｉｔｅ中間構造に書き込みを行った時点で、更新要求元のクライアントに対して処理完了の応答を返す。

各データノードのＷｒｉｔｅ中間構造に書き込まれた更新データは、各データノードにおいて、変換ターゲットデータ構造にそれぞれ非同期（Ａｓｙｎｃｈｒｏｎｏｕｓ）に更新される。図６に示す例では、Ｗｒｉｔｅにより、レプリカ識別子が０のデータノードにおいて、Ｗｒｉｔｅ中間構造には、データ構造Ａが格納保持され、レプリカ識別子１、２のデータノードに対して同期方式（Ｓｙｎｃｈｒｏｎｏｕｓ）で、Ｗｒｉｔｅ中間構造に保持されたデータ構造Ａのデータがレプリケート（複製）される。レプリカ識別子１、２のデータノードの各々において、Ｗｒｉｔｅ中間構造には、それぞれ、レプリカ識別子０、１のデータノードから転送されたデータ構造Ａのデータが一旦格納保持される。レプリカ識別子０、１、２に対応するデータ構造にそれぞれ対応するデータノードにおいて、ターゲットのデータ構造Ｂ、Ｃへの変換は、図３（Ａ）に示すようなデータ構造管理情報９２１の更新契機情報により指定される。例えばレプリカ識別子０のデータノードにおいては、データ構造ＡをＷｒｉｔｅからタイマをスタートさせ、３０ｓｅｃ（秒）が経過すると（タイムアウト時：更新契機発生）、データ構造Ｂ（Ｒｏｗ−Ｓｔｏｒｅ）に変換する。レプリカ識別子１のデータノードにおいては、レプリカ識別子０のデータノードから同期方式（Ｓｙｎｃ）で転送されたデータ構造Ａを受けとると、タイマをスタートさせ、６０秒が経過すると（タイムアウト時：更新契機発生）、データ構造Ｂ（Ｒｏｗ−Ｓｔｏｒｅ）に変換する。レプリカ識別子２のデータノードにおいては、レプリカ識別子１のデータノードから同期方式（Ｓｙｎｃ）で転送されたデータ構造Ａを受けとると、タイマをスタートさせ、６０秒が経過すると（タイムアウト時：更新契機発生）、データ構造Ｃ（Ｃｏｌｕｍｎ−Ｓｔｏｒｅ）に変換する。

図６に示すように、一つのデータノードのＷｒｉｔｅ中間構造に書き込まれた更新データ（データ構造Ａ）のデータノード間での複製（Ｒｅｐｌｉｃａｔｉｏｎ）は、書き込み（更新）と同期（Ｓｙｎｃ）して行われる。このような構成をとることによって、Ｗｒｉｔｅ（書き込み）データに対して、すぐにＲＥＡＤ（読み出し）系のアクセスがないデータに対してはＷｒｉｔｅの応答速度を高めることが出来る。

ＲＥＡＤ系のアクセスが行われる時には、当該ＲＥＡＤアクセスに必要なデータ構造に既に変換されているため、変換されたデータ構造を用いて、ＲＥＡＤ系アクセスを処理することで、処理の高速化を実現することができる。さらに、ＲＥＡＤ系アクセスの種類によって、適切なデータ構造を選んでアクセス先ノードを使い分けることも出来る。

なお、図６等において、単に説明の簡易化のために、データ構造の種類の数をＡ、Ｂ、Ｃの３つとしたが、データ構造の種類の数は３つに制限されるものでないことは勿論であり、例えば特性の異なる任意の複数種類であってもよい。また、データ構造の例として、キュー、カラムストア、ロウストアの３種を例示したが、かかる例に制限されるものでないことは勿論である。例えば、
・ロウストア構造におけるインデックスの有無、
・インデックスを作成したカラムの種類の違い、
・更新を追記構造で格納するロウストア形式、
等であってもよい。

このように、Ｗｒｉｔｅ優先の中間構造に持ち、非同期に構造を変換することにより、構造変換のボトルネックを回避し、可用性を保持することを可能としている。また、データ配置ノード、データ構造，非同期変換の適用の契機（タイマのタイムアウト時間）を制御可能にすることで、様々なアプリケーションや負荷の変動に対するマージンを拡大している。

同期（Ｓｙｎｃ）方式で異なるデータ構造の複製を採るのはオーバーヘッドが大きいＷｒｉｔｅ中間構造として先入れ先出し（ＦＩＦＯ）方式のキュー／ログのようなデータ構造を用い、一旦、データを、中間構造に格納しておき、あとで反映する方が、変換処理の効率も良く、システムのアクセス性能に与える影響も少ない。

ところで、図６に示した構成において、データの利用状況に応じて、非同期にデータ変換を行うための契機（図６の非同期タイマ（Ａｓｙｎｃ（タイマ））の設定値）は、常に最適であるとは限らない。

図６の非同期タイマの設定値が短く、頻繁にデータ構造の変換を行うことで、システムのＷｒｉｔｅ性能に悪影響を与えてしまう可能性もある。逆に、図６の非同期タイマの設定値（タイムアウト時間：更新契機情報）が長く、データ構造の変換の頻度が低い場合、当該変換されたデータ構造を利用するシステム（解析系）では、最新のデータを解析することが保証されず、解析結果の信頼性に問題が生じることも起りえる。

すなわち、図７のデータノードにおいて、データ構造変換の契機を規定するタイマ（Ａｓｙｎｃ（タイマ））の設定値（タイムアウト時間）が相対的に大きいと、当該データノードでは、Ｗｒｉｔｅ中間構造へデータ蓄積後、目的のデータ構造（図７ではカラムストア形式）への変換が行われるまでの時間が長くなる。すなわち、データノードでは、目的のデータ構造への変換とデータ格納部への格納は殆ど行われず、もっぱら、Ｗｒｉｔｅ中間構造に専らデータを溜めるだけとなる。この場合、Ｗｒｉｔｅ系の性能には有利である。また、Ｗｒｉｔｅ中間構造に蓄積されたデータをまとめてデータ構造（例えばカラムストア形式）を変換すれば良いことから、データ構造変換手段（図２の１１３）による変換処理も効率的となる。

しかしながら、データノードにおいて、データの受信から当該データを目的のデータ構造に変換するまでの時間が長く、予め定められた時刻あるいは時間帯等にバッチ処理等で動作するバッチ処理クライアント（目的のデータ構造に変換されたデータを解析をバッチ処理で行う）は、データ構造が変換済みの古いデータ（旧データ）を解析することになる。最新あるいは新しいデータが必要な場合には、データノードのＷｒｉｔｅ中間構造に蓄積されているデータ（データ構造の変換待ち）を読み込み、そのデータ構造を目的のデータ構造であるカラムストア形式に変換し（新データ）、これらカラムストア形式の新旧のデータの差分を反映させた上で、解析を行うことになる。この場合、クライアント側の負荷が増大する。

一方、データノードにおいて、データ構造の変換の契機を規定する非同期タイマ（Ａｓｙｎｃ（タイマ））の設定値（タイムアウト時間：更新契機情報）が相対的に小さいと、当該データノードでは、受け取ったデータを、短い時間間隔で少しずつ目的のデータ構造に変換しなければならない。このため、非同期タイマ（Ａｓｙｎｃ（タイマ））の設定値が小さい場合、当該データノードのＷｒｉｔｅ性能は、非同期タイマ（Ａｓｙｎｃ（タイマ））の設定値が大きい場合と比べて、不利となる。一方、非同期タイマ（Ａｓｙｎｃ（タイマ））の設定値が小さい場合、例えばバッチ処理でデータの解析を行うクライアント（バッチ処理クライアント）は、常に新しいデータを参照することができる。また、非同期でデータ構造が変換済みのデータは、比較的最近のデータであることから、クライアントが、より新しいデータを参照する際にも、Ｗｒｉｔｅ中間構造から読む出すデータ量は少なく、クライアント側の負荷も小さい。

図６の構成において、各データノードにおける非同期方式によるデータ構造の変換の契機は、例えばクライアント側からのデータの参照（Ｒｅａｄアクセス）の仕方に依存する。

＜Ｗｒｉｔｅ中間構造：実施形態＞
そこで、本実施形態では、図８に示すように、例えば、アクセスの頻度に関連付けてデータ構造の変換の契機（図３（Ａ）の更新契機情報）を調整する。アクセス頻度（Ｒｅａｄアクセスの頻度）が予め定めた閾値以下／以上ならば、非同期タイマ（Ａｓｙｎｃ（タイマ））の設定値（タイムアウト時間）を大きく／小さくする。すなわち、データ構造管理情報９２１（図２）の更新契機情報（非同期タイマ：図３（Ａ）の更新契機情報）の値を、アクセス頻度に合わせて、調整する。

また、Ｗｒｉｔｅ系の負荷が、Ｒｅａｄ系（解析系）の負荷に比して大きい／小さい場合には、非同期タイマ（Ａｓｙｎｃ（タイマ））の設定値（タイムアウト時間）を大きく／小さくする。すなわち、Ｗｒｉｔｅアクセスの頻度がＲｅａｄアクセスの頻度と比べて大きい場合、非同期タイマの設定値（タイムアウト時間）を大きくとる。

あるいは、アクセス履歴情報に基づき、参照アクセス（Ｒｅａｄアクセス）のパタンが定期的であれば（例えばＲｅａｄアクセスが定期的に行われる場合）、参照タイミング（Ｒｅａｄアクセスの日時、時間帯等）に合わせて、Ｗｒｉｔｅ中間構造に蓄積されたデータを目的のデータ構造へ変換して格納し、当該変換後は、非同期タイマ（Ａｓｙｎｃ（タイマ））の設定値（タイムアウト時間）を大きくするようにしてよい。あるいは、定期的に行われる次のＲｅａｄアクセスに間に合えばよいため、非同期タイマ（Ａｓｙｎｃ（タイマ））の設定値（タイムアウト時間）を大とすることで、データ構造の変換回数を減らす。特に制限されるものではないが、当該次のＲｅａｄアクセスが行われる前（直前）に、なるべく最新のデータのデータ構造が変換されているように設定してもよい。

アクセス履歴情報の変更時、例えばこの変更に同期（連動）して、データ構造管理情報９２１（図２）の更新契機情報の値（非同期タイマのタイムアウト時間）を調整するようにしてもよい。

本実施形態によれば、更新契機情報（非同期タイマ）の値の調整を行うだけで、例えばオンライン処理のＷｒｉｔｅ系の性能と、バッチ処理の解析系（Ｒｅａｄ系）の性能バランスの最適化を図ることが出来る。

なお、図８において、アクセス頻度は、非同期（Ａｓｙｎｃ）タイマの設定値の変更との関係を明示するために図示されており、アクセス頻度情報がデータノード内に記憶保持されている構成が示されているが、データノードのアクセス頻度情報をデータノード外部に備えた構成としてもよい。あるいは、複数のデータノードに対して、共通のストレージでデータノードのアクセス頻度情報を記憶管理するようにしてもよい。また、データノードでは、アクセスの履歴（ログ）を採り、アクセス履歴情報に基づき、アクセス頻度を計算し、当該アクセス頻度に基づき、非同期（Ａｓｙｎｃ）タイマの設定値（更新契機情報）を変更するようにしてもよい。あるいは、アクセス頻度（単位期間のアクセスの出願回数）のかわりに、アクセスの傾向、特性を示すアクセスパターン等を用いて非同期（Ａｓｙｎｃ）タイマの設定値（更新契機情報）を変更するようにしてもよい。

＜変更判定手段＞
図９は、データ構造管理情報９２１の更新契機情報の調整を行うための構成の一例を示す図である。図９に示すように、アクセス履歴記録部７１のアクセス情報に基づき、データ構造管理情報９２１の更新契機情報の変更を行うか否かを判断する変更判定手段（変更判定部）７２を備えている。

図２を参照して説明したように、各データノードのアクセス受付手段１１１は、受け付けたアクセス要求を、アクセス履歴記録部７１に記録する。アクセス履歴記録部７１は、アクセス要求（図３（Ａ）のテーブル識別子、当該データノードのレプリカ識別値等を含む）を、当該アクセス要求受付時の時刻情報（日時情報）に関連付けて記録する。

なお、アクセス履歴記録部７１は、各データノード毎に備えているが、複数のデータノードからなるデータノード群に対して１つ備えた構成、あるいはシステム全体で１つ備えたとしてもよい。あるいは、各データノードにアクセス履歴記録部７１を備え、各データノードで個別に集められたアクセス頻度情報を、任意の方法で、集約する仕組みを設けてもよい。

変更判定手段（変更判定部）７２は、アクセス履歴記録部７１に格納されたアクセス履歴情報を用いて、例えば最近（most recent）の過去の所定長さの期間内におけるアクセスの頻度の大小（閾値との比較結果）に応じて、対応するデータノードに関連する更新契機情報を変更するか否かを変体するようにしてもよい。あるいは、最近（most recent）の過去の所定長さの期間内におけるアクセス頻度を算出し、それよりも１つ前の所定長さの期間でのアクセス頻度情報の値からの変動の大小（閾値との比較結果）に応じて、対応するデータノードに関連する更新契機情報を変更するか否かを変体するようにしてもよい。

変更判定手段７２は、関連データノードにおいて非同期で変換するための更新契機情報（非同期タイマのタイムアウト時間の設定値）の変更が必要な場合に、構造情報変更手段９１に対して、非同期タイマの設定値の変更要求を発行する。変更判定手段７２からの変更要求は、データノードに対応するレプリカ識別子、テーブル識別子情報、データノードのノード情報を含む。さらに、変更判定手段７２からの変更要求は、現在の非同期タイマ設定値に対して、変更しない（変更値＝０）、所定単位インクリメント／デクリメントする、又は、所定単位の倍数分増加又は減少させる、という指示を含んでもよい。あるいは、変更判定手段７２で、非同期タイマの設定値の変更値を導出し、変更要求にこの変更値を設定し、構造情報変更手段９１で、現在の非同期タイマの設定値を、変更値で置き換える構成としてもよい。なお、テーブル識別子情報、レプリカ識別子、データノード情報（配置ノードの番号）の関係はデータ配置特定情報９２２に規定されており、構造情報変更手段９１では、変更判定手段７２からの変更要求に応答して、データノード情報（ＩＤ）、レプリカ識別子、テーブル識別子情報から、データ構造管理情報９２１において該当するテーブル識別子情報、レプリカ識別子の更新契機情報を変更する。

なお、図９では、変更判定手段７２を、データノード１のデータ管理・処理手段１１とは別に設ける構成とされているが、変更判定手段７２を各データノードのデータ管理・処理手段内に実装し、アクセス履歴記録部７１で、変更判定手段７２で計算されたアクセス頻度情報を保持するようにしてもよい。

なお、アクセス頻度情報としては、必ずしも、単位期間あたりのＲｅａｄアクセス要求の発生回数／Ｗｒｉｔｅアクセス要求の発生回数等に制限されるものでなく、例えば、Ｒｅａｄ、Ｗｒｉｔｅアクセス要求の発生パタン（Ｒｅａｄ、Ｗｒｉｔｅアクセスが固定の時刻等で発生する場合、その時刻表）の情報であってもよい。

＜クライアントのアクセスフロー＞
図１０は、図１のクライアント機能実現手段６１が、更新先のデータノードに対して命令を発行し、待ち合わせるというクライアント機能実現手段６１の動作を説明するためのフローチャートである。図１０を参照して、クライアントのアクセスフローについて説明する。

クライアント機能実現手段６１が、構造情報保持部９２の情報を、マスタデータ（マスタファイル）、あるいは任意の箇所のキャッシュ（マスタデータの一部の複製を格納したキャッシュメモリ）にアクセスすることで取得する（図１０のステップＳ１０１）。

次に、クライアント機能実現手段６１は、クライアントが発行する命令内容がＷＲＩＴＥ処理であるか参照処理（Ｒｅａｄ）であるかを識別する（ステップＳ１０２）。

これは、発行命令のコマンドにより指定したり、命令の実行コードを解析したりすることで、特定することが出来る。例えば、ＳＱＬを処理するストレージシステムの場合、
・ＩＮＳＥＲＴ命令（テーブルへレコードを追加するＳＱＬ命令）であれば、ＷＲＩＴＥ処理、
・ＳＥＬＥＣＴ命令（テーブルからレコードを参照、検索するＳＱＬ命令）であれば、参照系処理、
である。

あるいは、クライアント機能実現手段６１を用いて、命令を呼び出す際に、明示的に指定するようにしても良い（そのようなＡＰＩ（Ａｐｐｌｉｃａｔｉｏｎ Ｐｒｏｇｒａｍ Ｉｎｔｅｒｆａｃｅ）を準備する）。

ステップＳ１０２の結果、ＷＲＩＴＥ処理であれば、ステップＳ１０３以降に進む。

ＷＲＩＴＥ処理の場合、クライアント機能実現手段６１は、更新が必要なノードをデータ配置特定情報９２２の情報を用いて特定する。

クライアント機能実現手段６１は、特定したデータノードに対して、命令実行要求（更新要求）を発行する（ステップＳ１０３）。

クライアント機能実現手段６１は、更新要求発行先のデータノードからの応答通知を待ち合わせ、更新要求が、各データノードに保持されたことを確認する（ステップＳ１０４）。

ステップＳ１０２の結果、参照処理である場合には、ステップＳ１０５へ進む。

ステップＳ１０５では、クライアント機能実現手段６１は、処理内容の特性を特定（認識）する（ステップＳ１０５）。

次に、クライアント機能実現手段６１は、特定した処理特性と、その他のシステム状況を踏まえて、アクセス対象のデータノードを選択し、命令要求を発行する処理を行う（ステップＳ１０６）。

クライアント機能実現手段６１は、その後、データノードからアクセス処理結果を受け取る（ステップＳ１０７）。

以下、ステップＳ１０５、ステップＳ１０６の処理について説明を補充する。クライアント機能実現手段６１は、データ構造管理情報９２１に格納されている情報から、アクセス対象のデータが保持されているデータ構造の種類を知ることが出来る。例えば、図３（Ａ）の例の場合、ＷＯＲＫＥＲＳテーブルにアクセスする場合、レプリカ識別子０、１は、データ構造Ｂ、レプリカ識別子２は、データ構造Ｃである。なお、アクセス頻度情報には、ＷＯＲＫＥＲＳテーブルへのアクセスが、当該データノードのレプリカ識別子に関連付けて記録される。

そして、クライアント機能実現手段６１では、データノードに対して行われるデータアクセスが、どちらのデータ構造に適しているかを判断し、適している方のデータ構造を選択する。より詳しくは、例えば、クライアント機能実現手段６１では、アクセス要求であるＳＱＬ文を解析し、デーブル識別子が「ＷＯＲＫＥＲＳ」のテーブル内のあるカラムの総和をとるアクセスである場合には、データ構造Ｃ（カラムストア）を選択する。ＳＱＬ文が、ある特定のレコードを取り出すアクセスである場合には、クライアント機能実現手段６１は、データ構造Ｂ（ロウストア）が向いていると判断する。

ある特定のレコードを取り出す命令であった場合、クライアント機能実現手段６１は、レプリカ識別子０、１では、どちらを選択しても良い。なお、必ずしも「最新のデータで処理を行う必要が無い場合」、更新契機情報が大きな値に設定されているレプリカ識別子１を用いることが望ましい。

この「最新のデータで処理を行う必要が無い場合」であることの特定は、アプリケーション・コンテキストに依存する。このため、クライアント機能実現手段６１に受け渡される命令に、利用するデータ構造や、必要なデータの鮮度（データの新しさ）を特定する情報を、明示的に指定する形式としても良い。

クライアント機能実現手段６１は、アクセスすべきレプリカ識別子（データ構造）を特定した後、アクセスすべきデータノードを算出する。このとき、分散ストレージシステムの状況に応じて、アクセスノードの選択を変更できるようにしても良い。例えば、あるテーブルが同一のデータ構造Ｂとして、データノード１、２に格納されている際に、データノード１のアクセス負荷が大きい場合に、クライアント機能実現手段６１では、データノード２を選択する、という動作に変更してもよい。

また、別のデータ構造Ｃとして、データノード３に格納されている際に、データノード３のアクセス負荷が、データノード１、２と比較して小さい際に、処理するアクセス内容がデータ構造Ｂの方が向いていたとしても、クライアント機能実現手段６１では、データノード３（データ構造Ｃ）に対して、アクセス要求を発行するようにしても良い。

クライアント機能実現手段６１では、このようにして算出・選択されたデータノードに対して、アクセス要求を発行し（Ｓ１０６）、該データノードから、アクセス処理結果を受け取る（Ｓ１０７）。

＜データノードの動作＞
図１１は、図２のデータノードにおけるアクセス処理を説明するフローチャートである。図１１、図２を参照して、データノードの動作について詳細に説明する。

まず、データノードのデータ管理・処理手段１１のアクセス受付手段１１１がアクセス処理要求を受け付ける（図１１のステップＳ２０１）。

次に、データノードのデータ管理・処理手段１１のアクセス受付手段１１１は、受け付けた処理要求の内容がＷｒｉｔｅ処理であるか、Ｒｅａｄ（参照）処理であるか判定する（ステップＳ２０２）。

ステップＳ２０２の結果、ＷＲＩＴＥ処理であった場合、データノードのデータ管理・処理手段１１のアクセス処理手段１１２は、構造情報保持部９２におけるデータ構造管理情報９２１の情報を取得する（ステップＳ２０３）。データ構造管理情報９２１の情報取得は、マスタデータにアクセスしてもよいし、任意の箇所にあるキャッシュデータ（マスタデータの一部の複製を格納したキャッシュメモリのデータ）にアクセスするようにしてもよいし、あるいは、図１のクライアント機能実現手段６１が、データノードに対して発行する要求に情報（マスタデータ又はキャッシュデータへのアクセス）を付与し、アクセス処理手段１１２では、その情報を用いてアクセスするようにしてもよい。

次に、アクセス処理手段１１２は、データ構造管理情報９２１の情報から、該データノードに対する処理の更新契機が「０」（零）であるかどうかを判定する（ステップＳ２０４）。

ステップＳ２０４の結果、更新契機が「０」の場合、アクセス処理手段１１２は、構造情報保持部９２の構造情報に指定されたデータ構造を、直接、更新する（ステップＳ２０５）。すなわち、更新データを指定されたデータ構造に変換し対応する構造別データ格納部１２Ｘ（Ｘ＝１、２、３）に格納する。

更新契機が「０」でない場合、アクセス処理手段１１２は、Ｗｒｉｔｅ中間構造（構造別データ格納部１２１）に更新データを格納する（ステップＳ２０６）。

ステップＳ２０５、２０６の場合、いずれも、処理完了後、アクセス受付手段１１１は、要求元のクライアント機能実現手段６１に対して、処理完了通知を応答する（ステップＳ２０７）。

ステップＳ２０２の結果、データの参照処理であった場合、参照処理の実行を行う（ステップＳ２０８）。

Ｒｅａｄ（参照）処理の実行方式として、特に制限されるものでないが、代表的には、以下の３種類の方法を挙げることができる。

（１）第１の方法は、データ構造管理情報９２１に指定されているデータ構造のデータ格納部のデータを利用して処理する。これは最も性能が優れるが、更新契機の時間（サイクル）が大きい場合には、Ｗｒｉｔｅ中間構造のデータが参照処理に反映されていない可能性がある。このため、データの不整合が生じる可能性がある。ただし、アプリケーション開発者が事前に認識していて利用する場合や、Ｗｒｉｔｅ後に、データの読み出しが更新契機内に起きないことがわかっているか、もし新しいデータアクセスが必要な場合には、更新契機が「０」のレプリカ識別子データにアクセスすると決めている場合には、特に、問題はない。

（２）第２の方法は、別途行われる変換処理の適用を待ってから処理する方法である。これは、実装が容易であるが、応答性能が劣化する。応答性能を求めないアプリケーションの場合、問題はない。

（３）第３の方法は、データ構造管理情報９２１に指定されているデータ構造と、Ｗｒｉｔｅ中間構造に保持されているデータの両方を読んで処理する。この場合、常に、最新のデータを応答できるが、第１の方法より性能が劣化する。

上記第１乃至第３のいずれの方法をとってもよい。また、複数の種類を実現し、システムの設定ファイルとして記述する、クライアント機能実現手段６１から発行される処理命令の中に、どの方法で実行するかを指定するようにしてもよい。

＜データ構造変換手段のデータ構造変換動作＞
図１２は、図２のデータ構造変換手段１１３におけるデータ変換処理の動作を示すフローチャートである。図１２、図２を参照して、データ変換処理を説明する。

データ構造変換手段１１３は、定期的に変換処理の必要の有無を判定するため、データノード内のタイマ（不図示）でのタイムアウト発生による呼び出しを待つ（図１２のステップＳ３０１）。なお、このタイマは、専用タイマとしてデータ構造変換手段１１３内に備えるようにしてもよい。タイマのタイムアウト時間は、図３（Ａ）の更新契機情報（ｓｅｃ）の設定値（図６のＡｙｎｃ（タイマ）のタイムアウト時間）に対応する。

次に、構造情報保持部９２の構造情報（データ情報）を取得し（ステップＳ３０２）、変換が必要なデータ構造があるか否かを判定する（ステップＳ３０３）。例えば、タイマで判定が１０秒毎に行われるときに、更新契機が２０秒のデータ構造は、２０秒毎に変換処理を実行するため、１０秒時点では、変換処理を行わなくても良い。変換処理が必要でない場合には、タイマ呼び出し待ち（タイマでのタイムアウト発生により呼び出されるまでウエイト）に戻る（ステップＳ３０１）。

一方、変換処理が必要な際には、更新向け中間データ構造から、変換対象のデータに対する更新処理内容を読み出し（ステップＳ３０４）、変換先の構造別データ格納部１２Ｘ（Ｘ＝１〜３）へ更新情報を反映する処理を行う（ステップＳ３０５）。

＜Ｗｒｉｔｅシーケンス１＞
図１３は、Ｗｒｉｔｅ処理（データの更新を伴う処理）のシーケンスを示す図である。

クライアントノード６のクライアント機能実現手段６１（クライアント計算機）は、構造情報管理手段９の構造情報保持部９２に保持されているデータ配置特定情報９２２（図２）の情報を取得する（あるいは任意場所のキャッシュメモリから情報を取得する）。

クライアント計算機は、取得した情報を用いて、Ｗｒｉｔｅ処理を行うデータの配置先のデータノード（レプリカ識別子０のデータノード１）に対して、Ｗｒｉｔｅアクセス命令を発行する。

データノード１のアクセス受付手段１１１は、Ｗｒｉｔｅアクセス要求を受け付け、レプリカ識別子１、２に指定されているデータノード２、３に対してＷｒｉｔｅアクセスを転送する。レプリカ識別子１、２のデータノードを特定する方法としては、データノード１が構造情報保持部９２（あるいは適切なキャッシュ）にアクセスしても良いし、クライアント機能実現手段６１が発行するＷｒｉｔｅアクセス命令にデータ構造管理情報９２１の全部あるいは一部の情報をともに渡すようにしてもよい。

各データノードのアクセス処理手段１１２は、受け取ったＷｒｉｔｅアクセス要求の処理を行う。

アクセス処理手段１１２は、データ構造管理情報９２１の情報を参照して、Ｗｒｉｔｅ処理を実行する。

更新契機情報の値が「０」より大きい場合には、Ｗｒｉｔｅ処理内容をデータ構造Ａの構造別データ格納部１２１に格納する。

更新契機情報の値が「０」の場合には、データ構造管理情報９２１に指定されているデータ構造の構造別データ格納部１２Ｘに対して格納する。

アクセス処理手段１１２は、Ｗｒｉｔｅ処理完了後、アクセス受付手段１１１に、完了通知を発行し、クライアント計算機に完了応答を返す。

レプリカ先のデータノード（２、３）は、レプリカ元のデータノード１のアクセス受付手段１１１にＷｒｉｔｅ完了応答を返答する。

アクセス受付手段１１１は、データノード１のアクセス処理手段１１２からの完了通知と、各レプリカ先のデータノード２、３の完了通知を待ち合わせ、全て受け取った後に、クライアント計算機に対して応答を返す。

データノード１のデータ構造変換手段１１３（図２参照）は、Ｗｒｉｔｅ中間構造（構造別データ格納部１２１（データ構造Ａ））に格納されたデータを、非同期タイマのタイムアウトに応じて、構造別データ格納部１２Ｘ（データ構造管理情報９２１に指定されている、最終格納先データ構造）に変換して格納する。同様にデータノード２、３も、非同期タイマのタイムアウトに応じて、目的のデータ構造への変換を行う。

＜Ｗｒｉｔｅシーケンス２＞
なお、図１３の例では、データノード１が、レプリカ先のデータノード２、３に対して、Ｗｒｉｔｅ要求を転送しているが、図１４に示すように、クライアント計算機が、格納先のデータノードの全てに対して、Ｗｒｉｔｅ要求を発行するようにしても良い。

図１４の例では、図１３と比較して、Ｗｒｉｔｅアクセス要求の待ち合わせをクライアント計算機で行うことが異なる。図１４の例では、クライアント計算機が格納先のデータノード０、１、２に対して、それぞれＷｒｉｔｅ要求を発行し、格納先のデータノード０、１、２からそれぞれ完了応答を受け取っている。

＜変形例＞
図１５は、図８の構成の一変形例を説明する図である。図１５を参照すると、図８のカラムストア（Ｃｏｌｕｍｎ Ｓｔｏｒｅ）形式のデータノード３を、２つのデータノード３Ａ、３Ｂで構成し、一方のデータノード３ＡでＷｒｉｔｅ中間構造からカラムストア（Ｃｏｌｕｍｎ Ｓｔｏｒｅ）形式のデータ構造への変換を行っている場合、解析系のクライアント（Ｃｌｉｅｎｔ）は、他方のデータノード３Ｂのデータ（Ｗｒｉｔｅ中間構造に格納された変換前のデータとカラムストア形式に変換済みのデータ）を参照して解析を行う。データノード３Ａ、３Ｂでの非同期のタイマの設定は２０秒（Ａｙｎｃ（２０秒））であるが、データノード３Ｂでのデータ構造の変換は、データノード３Ａでのデータ構造の変換よりも１０秒遅れている。例えばデータノード３Ａでは、０秒〜２０秒の時間区間でデータ構造の変換が行われ、続く２０〜４０秒の時間区間でＲｅａｄアクセスを行うクライアント（Ｃｌｉｅｎｔ）によるデータの解析が行われる。データノード３Ｂでは、１０秒〜３０秒の時間区間でＲｅａｄアクセスを行うクライアント（Ｃｌｉｅｎｔ）によるデータの解析が行われ、続く３０〜５０秒の時間区間で、データ構造の変換が行われる。したがって、例えば１０秒と２０秒の中間の１５秒時点では、データノード３Ａではデータ構造の変換、データノード３Ｂではデータの解析が行われる。なお、データノード３Ａ、３Ｂにおける非同期のタイマの設定は、データノード３Ａ、３Ｂのアクセス履歴情報（アクセス頻度）に基づいて設定される。

＜別の変形例＞
図１６は、オンライン処理（Ｗｒｉｔｅ処理を行うオンライン処理システム）とバッチ処理等で行われる解析系（データウエアハウス）間にＥＴＬ（Ｅｘｔｒａｃｔ／Ｔｒａｎｓｆｏｒｍ／Ｌｏａｄ）を配設した例を示している。

データウェアハウス・システムにおいては、基幹系システムからデータ（例えばトランザクション・データ等）を抽出し再構成し情報分析、意思決定のための大規模データベースを含む。基幹系システムのデータベースからデータウェアハウス・データベースへ、データの移行を行う必要があり、この処理は、ＥＴＬ（Ｅｘｔｒａｃｔ／Ｔｒａｎｓｆｏｒｍ／Ｌｏａｄ）と呼ばれている。なお、「Ｅｘｔｒａｃｔ」は部の情報源からデータを抽出、「Ｔｒａｎｓｆｏｒｍ」は抽出したデータをビジネスでの必要に応じて変換・加工、「Ｌｏａｄ」は最終的ターゲット（すなわちデータウェアハウス）に変換・加工済みのデータをロードを表している。図１６では、上記した実施形態を、ＥＴＬのデータ変換に適用している。すなわち、図１６のＥＴＬによる非同期のデータ変換は、図１のデータ構造変換手段１１３によるデータ構造の変換に対応している。

図１６の例において、ＥＴＬは、現用系（オンライン処理）のロウストア（Ｒｏｗ Ｓｔｏｒｅ）形式のデータ（複製データ）を、解析系（データウェアハウス）用のカラムストア（Ｃｏｌｕｍｎ−Ｓｔｏｒｅ）形式に、非同期（Ａｓｙｎｃｈ：Ａｓｙｎｃｈｒｏｎｏｕｓ）で変換している。本実施形態では、アクセス履歴情報（アクセス頻度情報）に基づき、ＥＴＬにおける変換を非同期で行うタイマをアクセス頻度に基つき調整することで、データ構造変換のボトルネックを解消し、ストレージの利用効率を高めることができる。

なお、上記の特許文献の各開示を、本書に引用をもって繰り込むものとする。本発明の全開示（請求の範囲を含む）の枠内において、さらにその基本的技術思想に基づいて、実施形態ないし実施例の変更・調整が可能である。また、本発明の請求の範囲の枠内において種々の開示要素（各請求項の各要素、各実施例の各要素、各図面の各要素等を含む）の多様な組み合わせないし選択が可能である。すなわち、本発明は、請求の範囲を含む全開示、技術的思想にしたがって当業者であればなし得るであろう各種変形、修正を含むことは勿論である。

１〜４ データノード
５ ネットワーク
６ クライアントノード
９ 構造情報管理手段（構造情報管理装置）
１１、２１、３１、４１ データ管理・処理手段（データ管理・処理部）
１２、２２、３２、４２ データ格納部
６１ クライアント機能実現手段（クライアント機能実現部）
７１ アクセス履歴記録部
７２ 変更判定手段（変更判定部）
９１ 構造情報変更手段（構造情報変更部）
９２ 構造情報保持部
１１１ アクセス受付手段（アクセス受付部）
１１２ アクセス処理手段（アクセス処理部）
１１３ データ構造変換手段（データ構造変換部）
１２１、１２２、１２３、１２Ｘ 構造別データ格納部
６１１ データアクセス手段（データアクセス部）
６１２ 構造情報キャッシュ保持部
９２１ データ構造管理情報
９２２ データ配置特定情報

Claims (14)

1. それぞれがデータ格納部を備え、ネットワーク結合される複数のデータノードを備え、
   データの更新要求に対して前記データの複製先のデータノードでは、
   更新対象のデータを、一旦、書き込みデータ保持用の中間構造に格納し、受け取った前記更新要求とは非同期で、それぞれ目的のデータ構造に変換して前記データ格納部に格納し、
   前記データノードへのアクセス頻度の履歴を記憶するアクセス履歴記録部を備え、
   前記データノードで非同期に行われる前記目的のデータ構造への変換の契機となる契機情報を、前記アクセス履歴記録部に記録されたアクセス情報に基づき、可変させる手段を備えている、分散ストレージシステム。
2. 複製先の前記データノードは、それぞれ、前記中間構造に、前記データを保持して、応答を返し、
   前記中間構造に保持されるデータ構造を、前記更新対象のデータの受信から前記契機情報で規定される時間経過時に、前記目的のデータ構造に非同期で変換した上で前記データ格納部に格納する、請求項１記載の分散ストレージシステム。
3. 予め定められたテーブル単位でデータ配置先のデータノード、配置先のデータノードにおける目的のデータ構造を制御する手段を備えた請求項１又は２記載の分散ストレージシステム。
4. 格納対象のデータを識別する識別子であるテーブル識別子に対応させて、複製を特定するレプリカ識別子と、前記レプリカ識別子に対応したデータ構造の種類を特定するデータ構造情報と、指定されたデータ構造に変換して格納されるまでのタイマ情報である契機情報と、を、前記データ構造の種類の数に対応させて備えたデータ構造管理情報と、
   前記テーブル識別子に対応して、前記レプリカ識別子と、前記レプリカ識別子に対応した１つ又は複数のデータ配置先のデータノード情報とを備えたデータ配置特定情報と、
   を記憶管理する構造情報保持部を有する構造情報管理装置と、
   前記データ構造管理情報と前記データ配置特定情報とを参照して、更新処理及び参照処理のアクセス先を特定するデータアクセス部を備えたクライアント機能実現部と、
   それぞれが前記データ格納部を備え、前記構造情報管理装置と前記クライアント機能実現部とに接続される複数の前記データノードと、
   を備え、
   前記データノードは、
   前記クライアント機能実現部からのアクセス要求に基づき、更新処理を行う場合に、中間構造にデータを保持して前記クライアント機能実現部に応答を返すアクセス受付・処理部と、
   前記データ構造管理情報を参照し、指定された更新契機に応答して、前記中間構造に保持されるデータを、前記データ構造管理情報で指定されたデータ構造に変換する処理を行うデータ構造変換部と、
   を備えたデータ管理・処理部を有する、ことを特徴とする、請求項１乃至３のいずれか１項に記載の分散ストレージシステム。
5. 前記アクセス履歴記録部に記録されたアクセス情報、又は、前記アクセス情報を加工して得た別のアクセス情報を用いて、前記構造情報保持部の前記データ構造管理情報の更新契機情報を変更するか否か判定し、
   前記データ構造管理情報の更新契機情報を変更する場合、前記構造情報管理装置に通知する変更判定部を備え、
   前記構造情報管理装置は、前記変更判定部からの前記更新契機情報の変更の通知を受け、前記データ構造管理情報の更新契機情報を変更する構造情報変更部を備えた、請求項４記載の分散ストレージシステム。
6. 前記アクセス履歴記録部に記録されたアクセス情報が、前記データ格納部からの読み出しアクセスと、前記中間構造へのデータの書き込みアクセスの頻度情報を含む、請求項１又は５記載の分散ストレージシステム。
7. 前記データノードにおいて、
   前記アクセス受付・処理部が、
   アクセス受付部、アクセス処理部を備え、
   前記データノードの前記データ格納部は、構造別データ格納部を備え、
   前記アクセス受付部は、
   前記クライアント機能実現部からの更新要求を受け付け、前記データ配置特定情報においてレプリカ識別子に対応して指定されているデータノードに対して更新要求を転送し、
   さらに前記アクセス履歴記録部にアクセス要求を記録し、
   前記データノードの前記アクセス処理部は、
   受け取った更新要求の処理を行い、前記データ構造管理情報の情報を参照して更新処理を実行し、その際、前記データ構造管理情報の情報から、前記データノードに対する前記更新契機情報が零の場合、更新データを、前記データ構造管理情報に指定されるデータ構造に変換して、前記構造別データ格納部に格納し、
   前記更新契機が零でない場合、前記中間構造に、一旦、更新データを書き込み、処理完了を応答し、
   前記アクセス受付部は、
   前記アクセス処理部からの完了通知、又は、
   前記アクセス処理部からの完了通知及びレプリカ先の各データノードからの完了通知、
   を受けると、前記クライアント機能実現部に対して応答し、
   前記データ構造変換部は、前記中間構造のデータを、前記データ構造管理情報に指定されているデータ構造に変換し変換先の前記構造別データ格納部に格納する、請求項５記載の分散ストレージシステム。
8. 前記目的のデータ構造が同一の少なくとも二つのデータノードを備え、
   前記二つのデータノードでは、前記書き込みデータ保持用の中間構造に保持されたデータから前記目的のデータ構造への変換を、設定された前記契機情報に基づき、それぞれ、時間的に重ならないタイミングで行い、一方のデータノードで、前記書き込みデータ保持用の中間構造に保持されたデータを、前記目的のデータ構造に変換しているとき、他方のデータノードでは、前記目的のデータ構造に変換されたデータの読み出しが行われる、請求項１記載の分散ストレージシステム。
9. それぞれがデータ格納部を備え、ネットワーク結合される複数のデータノードを備えた分散ストレージのデータ複製方法において、
   データの更新要求に対応したデータの複製にあたり、複製先のデータノードでは、
   更新対象のデータを、一旦、書き込みデータ保持用の中間構造に格納し、更新要求とは非同期で、それぞれ目的のデータ構造に変換して前記データ格納部に格納し、
   前記データノードで非同期に行われる前記目的のデータ構造への変換の実行の契機となる契機情報を、前記データノードへのアクセスの履歴情報に基づき、可変させる、データ複製方法。
10. 複製先の前記データノードは、前記中間構造に前記データを保持して応答を返し、
    前記中間構造に保持されるデータ構造を、前記更新対象のデータの受信から前記契機情報で規定される時間経過時に、前記目的のデータ構造に非同期で変換する、請求項９記載のデータ複製方法。
11. 予め定められたテーブル単位でデータ配置先のデータノード、配置先のデータノードにおける目的のデータ構造を制御する請求項９又は１０記載のデータ複製方法。
12. 格納対象のデータを識別する識別子であるテーブル識別子に対応させて、複製を特定するレプリカ識別子と、前記レプリカ識別子に対応したデータ構造の種類を特定するデータ構造情報と、指定されたデータ構造に変換して格納されるまでの時間情報である契機情報と、を、前記データ構造の種類の数に対応させて管理するデータ構造管理情報と、
    前記テーブル識別子に対応して、前記レプリカ識別子と、前記レプリカ識別子に対応した１つ又は複数のデータ配置先のデータノード情報とを備えたデータ配置特定情報と、
    を構造情報管理装置の構造情報保持部にて記憶し、
    データアクセス部において、前記データ構造管理情報と前記データ配置特定情報とを参照して、更新処理及び参照処理のアクセス先を特定し、
    前記データノードは、
    前記クライアントからのアクセス要求に基づき、更新処理を行う場合に、中間構造にデータを保持して応答を返し、
    前記データ構造管理情報を参照し、指定された更新契機に応答して、前記中間構造に保持されるデータを、前記データ構造管理情報で指定されたデータ構造に変換する、ことを特徴とする、請求項９乃至１１のいずれか１項に記載のデータ複製方法。
13. 前記アクセスの履歴情報が、前記データ格納部からの読み出しアクセスと、前記中間構造へのデータの書き込みアクセスの頻度情報を含む、請求項９又は１２記載のデータ複製方法。
14. 前記目的のデータ構造が同一の少なくとも二つのデータノードを用意し、
    前記二つのデータノードでは、前記書き込みデータ保持用の中間構造に保持されたデータから前記目的のデータ構造への変換を、設定された前記契機情報に基づき、それぞれ、時間的に重ならないタイミングで行い、一方のデータノードで、前記書き込みデータ保持用の中間構造に保持されたデータを、前記目的のデータ構造に変換しているとき、他方のデータノードでは、前記目的のデータ構造に変換されたデータの読み出しが行われる、請求項９記載のデータ複製方法。

Images