JP4952276B2 - 分散データ管理システムおよび方法 - Google Patents

Description

本発明は、サーバが存在しないピアツーピアネットワークにおける分散データ管理システムに係り、特に分散ハッシュ表技術を応用した分散データ管理システムおよび方法に関するものである。

サーバが存在せず、任意のノードが任意の時刻に参加することができ、かつ任意のノードが任意の時刻に離脱することができるピアツーピアネットワークにおいて、データ共有を実現する技術として、分散ハッシュ表技術が知られている。ピアツーピアネットワークでは、図４に示すように、複数のノード２００がネットワーク１００を介して接続されている。ネットワーク１００は、多くの場合ＩＰ（Internet Protocol ）ネットワークであるが、ＩＰネットワークに限定するものではない。

図４のようなピアツーピアネットワークに関して、分散ハッシュ表技術の代表例であるＣｈｏｒｄシステムが特許文献１に記載されている。また、分散ハッシュ表技術の応用例であるスキップネットが特許文献２に記載されている。以降では、分散ハッシュ表技術としてＣｈｏｒｄシステムを対象に説明する。

Ｃｈｏｒｄシステムにおいては、データはＩＤ（識別子）と関連づけられて格納される。データに関連づけるＩＤは、データのハッシュ値もしくはデータを特徴づけるキーのハッシュ値とすることが一般的である。当該ハッシュ値を計算するためのハッシュ関数としては、例えばＳＨＡ−１（Secure Hash Algorithm 1 ）ハッシュ関数が使用される。Ｃｈｏｒｄシステムにおいては、ノードには予め前記ハッシュ値の空間と同じ空間にＩＤを定めておき、ノードのＩＤとデータのＩＤの距離を定義してデータを分散管理する。

すなわち、あるデータの管理ノードは、当該データのＩＤに一番距離の小さいＩＤを持つノードとする。データを登録する場合は当該データの管理ノードへ登録し、データを取得する場合は当該データの管理ノードから取得する。距離は、ＩＤ空間の最大値（例えば、２の１６０乗）を法とした除算により定義する。大規模なピアツーピアネットワークにおいても効率的に管理ノードを探すことができるように、Ｃｈｏｒｄシステムでは経路表を管理してオーバレイネットワークを構成する。

Ｃｈｏｒｄシステムのノード２００は、図５に示すように、データ格納手段２０１と、データ処理手段２０２と、通信処理手段２０３と、経路表処理手段２０４と、経路表格納手段２０５とから構成される。ノード２００の動作は以下のとおりである。
まず、経路表処理手段２０４は、データを登録もしくは取得する際に、経路表格納手段２０５に格納された経路表を用いて、当該データのＩＤと最も近いＩＤを持つノードが自ノードであるか否かを判断する。

当該データのＩＤと最も近いＩＤを持つノードが自ノードである場合、データ処理手段２０２は、データ格納手段２０１にデータを登録するか、もしくはデータ格納手段２０１からデータを取得する。
当該データのＩＤと最も近いＩＤを持つノードが自ノードでない場合、通信処理手段２０３は、当該データの登録のメッセージもしくは取得のメッセージを、当該データのＩＤと可能な限り近いＩＤを持つ別のノードに転送する。以降のノードにおいても同様の転送を繰り返すことにより、当該データのＩＤと最も近いＩＤを持つノードにメッセージが到達する。

Ｃｈｏｒｄシステムにおける経路表は、例えば、自ノードのＩＤとの距離が２のｉ乗に最も近いＩＤを持つノードのＩＤ及びアドレスをエントリとして格納している。ただし、距離の最小単位を１とし、２のｉ乗はＩＤ空間を越えないようなｉを用いるものとする。例えばＩＤ空間の最大値を２の１６０乗とすれば、ｉは０≦ｉ≦１５９を満たす。このような経路表の構成法により、Ｃｈｏｒｄシステムでは、任意のノードから別の任意のノードに辿り着くまでのホップ数がＯ（ｌｏｇ（Ｎ））となる。ただし、Ｎはネットワークの大きさ、すなわちネットワークに参加しているノード数を表し、Ｏ（）はオーダを意味する。

実際には、ホップ数の分布には幅があり、ホップ数の平均値はホップ数の最大値のおよそ半分になることが知られている。また、ｌｏｇの底はＩＤ空間のワード数に一致し、前記の例では２となる。すなわち、ホップ数の平均値は、ｌｏｇ（Ｎ）／ｌｏｇ（２）／２となる。Ｏ（ｌｏｇ（Ｎ））のホップ数はＮの増加に対して比較的緩やかに増加するため、Ｃｈｏｒｄシステムはネットワークの大きさに対して効率的である。

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

Ｃｈｏｒｄシステムおよび一般的な分散ハッシュ表技術を用いた分散データ管理システムにおいては、データ取得にＯ（ｌｏｇ（Ｎ））のホップ数を必要とするため、次のような問題点があった。
第１の問題点は、ネットワークがある程度の大きさを超えると、ホップ数による遅延が無視できないほど大きくなることである。例えば、ネットワークに参加しているノード数を１００００００ノード、すなわちＮ＝１００００００とすると、ホップ数の平均値は、ｌｏｇ（１０００００）／ｌｏｇ（２）／２＝９．９６となる。仮に、１ホップにかかるネットワーク遅延が１００ミリ秒とすると、合計で１秒近い遅延になり、用途によっては許容できない場合がある。すなわち、遅延がホップ数に比例しているため、大規模なネットワークではホップ数の増加によりデータ取得にかかる遅延が大きくなるという問題がある。

第２の問題点は、受動的にデータの存在を知る可能性が低いことである。その理由は、データ取得の明示的な要求がない限り、基本的にはデータが配信されないためである。データの登録に際して転送途中に関与するノードは存在するものの少数であり、キーの情報を無くしてデータの存在を知りうるノードの割合は限られる。この問題はネットワークが大きいほど顕著になる。

本発明の目的は、分散ハッシュ表技術を用いた分散データ管理システムにおいて、データ取得にかかる遅延を軽減することができる分散データ管理システムおよび方法を提供することにある。
本発明の他の目的は、分散ハッシュ表技術を用いた分散データ管理システムにおいて、データ取得の要求がなくとも、将来のデータ処理を予測してデータを配信することができる分散データ管理システムおよび方法を提供することにある。

本発明は、ピアツーピアネットワークにおける分散データ管理システムにおいて、ネットワークに接続される各ノードが、他ノードと前記ネットワークを介して通信する通信処理手段と、データを記憶するデータ格納手段と、前記通信処理手段が受信したデータ処理要求に応じて、前記データ格納手段に格納されたデータを処理するデータ処理手段と、前記データ処理要求の履歴を記憶するデータ処理要求履歴格納手段と、前記データ処理要求の履歴を基に他ノードのデータ処理パターンを予測して、このノードにデータを事前に配信するか否かを判断するデータ処理予測手段と、このデータ処理予測手段から配信の指示を受けたときに、指示されたデータを前記他ノードに配信するデータ事前配信手段と、経路表を記憶する経路表格納手段と、この経路表格納手段に格納された経路表の情報に基づいて、前記通信処理手段が受信したメッセージの転送先を決定する経路表処理手段とを備え、前記経路表は、分散ハッシュ表技術を用いて構築され、前記データ処理予測手段は、前記データ処理要求の履歴を基に過去から現在までの前記データ処理パターンを求め、このデータ処理パターンから将来のデータ処理パターンを予測して、事前配信しない場合のデータ取得にかかるコストがデータ事前配信にかかるコストを上回ると判断した場合に、データの事前配信を決定することを特徴とするものである。
データ処理予測手段は、データ処理要求の履歴をデータ処理要求履歴格納手段に格納し、データ処理要求履歴格納手段に格納されたデータ処理要求の履歴をもとに、将来のデータ処理を予測する。例えば、データ取得の分布が時間に対して一様であると仮定すると、あるデータＸに対する単位時間あたりの取得要求数をもとにデータＸに対する将来の取得要求数を予測することができる。この予測に基づき、データＸに対する将来の取得要求にかかるコスト（メッセージ数やメッセージ量）がデータＸを事前に配信するためにかかるコストより多いと判断される場合は、データ事前配信手段によりデータＸはすべてのまたは一部のノードに事前に配信される。このような構成を採用し、データ処理を予測し、必要に応じてデータを事前に配信することで、データ取得にかかる遅延を軽減することができ、本発明の目的を達成することができる。また、データ処理を予測し、必要に応じてデータを事前に配信することで、データ取得要求に関わらずデータを配信することができ、本発明の他の目的を達成することができる。

また、本発明の分散データ管理システムの１構成例において、前記データ事前配信手段は、前記経路表格納手段に格納された経路表の情報を用いてデータを事前に配信するものである。
また、本発明の分散データ管理システムの１構成例において、前記データ処理予測手段は、特定のノードのグループを事前配信範囲として、この事前配信範囲についてのみ前記データ処理パターンを予測し、前記データ事前配信手段は、前記ノードのグループに対してのみデータを事前に配信するものである。
また、本発明の分散データ管理システムの１構成例において、前記データ処理予測手段は、他ノードにおける過去から現在までのデータ取得頻度と将来のデータ取得頻度とが線形の関係にあると仮定して、将来のデータ取得頻度を前記データ処理パターンとして予測するものである。
また、本発明の分散データ管理システムの１構成例において、前記データ処理予測手段は、データ登録時点から現在までの時間をＴ１とし、現在からデータの有効期限までの時間をＴ２とし、データ登録時点から現在までのデータ取得回数をＫとしたときに、将来のデータ取得回数の予測値をＫ×Ｔ２／Ｔ１とするものである。

また、本発明の分散データ管理方法において、ネットワークに接続される各ノードは、自ノードの通信処理手段が受信したデータ処理要求に応じて、自ノードのデータ格納手順に格納されたデータを処理するデータ処理手順と、前記データ処理要求の履歴を記憶するデータ処理要求履歴格納手順と、前記データ処理要求の履歴を基に他のノードのデータ処理パターンを予測して、このノードにデータを事前に配信するか否かを判断するデータ処理予測手順と、このデータ処理予測手順で事前配信が決定されたデータを前記他のノードに配信するデータ事前配信手順と、経路表格納手段に格納された経路表の情報に基づいて、前記通信処理手段が受信したメッセージの転送先を決定する経路表処理手順とを実行し、前記経路表は、分散ハッシュ表技術を用いて構築され、前記データ処理予測手順は、前記データ処理要求の履歴を基に過去から現在までの前記データ処理パターンを求め、このデータ処理パターンから将来のデータ処理パターンを予測して、事前配信しない場合のデータ取得にかかるコストがデータ事前配信にかかるコストを上回ると判断した場合に、データの事前配信を決定するようにしたものである。

本発明によれば、データ処理要求の履歴を基に他ノードのデータ処理パターンを予測して、このノードにデータを事前に配信するか否かを判断し、事前配信が決定されたデータを他ノードに配信するようにしたので、データ取得にかかる遅延を軽減することができる。その理由は、将来のデータ処理を予測して、必要に応じてデータを他ノードに事前に配信することで、事前配信されたノードでは、当該データの取得要求が発生した場合に、データを自ノードのデータ格納手段から即座に取得できるためである。また、本発明では、データ取得要求を行わないノードにもデータを配信することができる。その理由は、将来のデータ処理を予測して、必要に応じてデータを事前に配信することで、全てのもしくは一部のノードに能動的にデータが配信されるためである。

また、本発明では、経路表格納手段に格納された経路表の情報を用いてデータを事前に配信することにより、データ事前配信手段が別途配信のための情報を管理する必要がなくなる。

また、本発明では、データ処理要求の履歴を基に過去から現在までのデータ処理パターンを求め、このデータ処理パターンから将来のデータ処理パターンを予測して、事前配信しない場合のデータ取得にかかるコストとデータ事前配信にかかるコストとを比較することにより、データ処理予測手段はデータを事前に配信するか否かを判断することができる。

また、本発明では、特定のノードのグループを事前配信範囲として、この事前配信範囲についてのみデータ処理パターンを予測することにより、特定のノードのグループに対してのみデータを事前に配信することができる。

また、本発明では、他ノードにおける過去から現在までのデータ取得頻度と将来のデータ取得頻度とが線形の関係にあると仮定することにより、過去から現在までのデータ取得頻度から将来のデータ取得頻度をデータ処理パターンとして予測することができる。

［第１の実施の形態］
次に、本発明を実施するための最良の形態について図面を参照して詳細に説明する。図１は本発明の第１の実施の形態に係る分散データ管理システムにおけるノードの構成を示すブロック図である。本実施の形態の分散データ管理システムを適用するピアツーピアネットワークの構成は図４に示したとおりであるので、ネットワークを１００、ノードを２００とする。図１では、１つのノード２００についてのみ記載しているが、図４に示したように、同様の構成のノード２００が複数存在することは言うまでもない。

図１に示すように、ノード２００は、データ格納手段２０１と、データ処理手段２０２と、通信処理手段２０３と、経路表処理手段２０４と、経路表格納手段２０５と、データ処理予測手段２０６と、データ処理要求履歴格納手段２０７と、データ事前配信手段２０８とから構成されている。このノード２００の各手段は、それぞれ概略つぎのように動作する。

データ格納手段２０１は、分散ハッシュ表全体に格納されるデータの一部、すなわち自ノードが管理するデータを記憶している。
データ処理手段２０２は、通信処理手段２０３からデータ処理要求を受けたときに、このデータ処理要求をデータ処理予測手段２０６へ出力すると共に、データ処理要求に応じてデータ処理を実行し、必要であればデータ処理の結果を通信処理手段２０３を通じて要求元のノード２００もしくはクライアント（不図示）に返送する。

通信処理手段２０３は、ネットワーク１００を介して他のノード２００もしくはクライアントからメッセージを受けたときに、当該メッセージがデータ処理要求であればデータ処理手段２０２に当該要求を出力し、当該メッセージが経路表更新要求であれば経路表処理手段２０４に当該要求を出力し、いずれの要求であっても必要であれば当該要求を別のノード２００に転送する。

経路表処理手段２０４は、通信処理手段２０３から経路表更新要求を受けたときに、経路表格納手段２０５に格納された経路表を更新し、必要であれば、別のノード２００に対して新規に経路表更新要求を送信する。また、経路表処理手段２０４は、メッセージの転送の必要性および転送先を判断する。
経路表格納手段２０５は、経路表処理手段２０４により管理される経路表を記憶している。経路表は、分散ハッシュ表技術を用いて構築される。

データ処理予測手段２０６は、データ処理手段２０２から逐次もしくは定期的にデータ処理要求を受けて、このデータ処理要求を履歴としてデータ処理要求履歴格納手段２０７に格納する。また、データ処理予測手段２０６は、データ処理要求履歴格納手段２０７に格納されているデータ処理要求履歴に基づいて将来のデータ処理を予測し、あるデータを事前に配信すべきと判断すれば、データ事前配信手段２０８に対して当該データの事前配信を指示する。

データ事前配信手段２０８は、データ処理予測手段２０６からデータ事前配信の指示を受けたときに、指示されたデータをデータ格納手段２０１から取り出して、このデータをネットワーク１００を介して自ノード以外の全てのノード２００もしくは一部のノード２００のデータ事前配信手段２０８に事前配信する。
事前配信されたデータを受信したノード２００では、データ事前配信手段２０８が受信したデータをデータ格納手段２０１に格納する。

あるデータを事前に配信すべきか否かを判断するための参考情報としては、例えば当該データの単位時間あたりの取得回数（配信側から見た場合には配信回数）や、当該データの残りの有効時間内での線形予測取得回数がある。また、当該データが更新されたデータである場合には、更新前の古いデータの取得頻度（配信頻度）を参考情報として用いてもよいし、データの類似性が判定できる場合には、当該データの類似データの取得頻度を参考情報として用いてもよい。

また、データの事前配信範囲、すなわち事前配信先のノードを予め限定し、この事前配信範囲のみに関する当該データの前記参考情報を用いて、データを事前に配信すべきか否かを判断するようにしてもよい。
なお、データ取得頻度とデータ取得回数は前記参考情報として同等の意味を有するが、データ取得の数を明確な期間を定めずに求めた場合はデータ取得頻度とし、ある特定の期間について求めた場合はデータ取得回数とする。

次に、図１及び図２のフローチャートを参照して本実施の形態の全体の動作について詳細に説明する。
まず、ノード２００の通信処理手段２０３は、ネットワーク１００を介して別のノード２００もしくはクライアントからメッセージを受信する（ステップＡ１）。メッセージを受信した通信処理手段２０３は、このメッセージに含まれる要求の種類に応じて要求を振り分ける。すなわち、メッセージに含まれる要求がデータ処理要求の場合はデータ処理手段２０２に出力し、経路表更新要求の場合は経路表処理手段２０４に出力する（ステップＡ２）。

データ処理手段２０２は、通信処理手段２０３からデータ処理要求を受けた場合に、このデータ処理要求に応じてデータを処理する（ステップＡ３）。データ処理要求には、データ登録要求とデータ取得要求の２種類がある。

データ処理手段２０２は、データ登録要求を受けた場合、この要求に含まれるデータをデータ格納手段２０１に登録し、要求に対する返信が必要な場合は（例えば返信すべきことが予め定められている場合など）、データ登録が完了したことを示すデータ処理結果を通信処理手段２０３及びネットワーク１００を介して要求元のノード２００もしくはクライアントに返信する。また、データ処理手段２０２は、データ取得要求を受けた場合、この要求に該当するデータをデータ格納手段２０１から取得し、取得したデータを通信処理手段２０３及びネットワーク１００を介して要求元のノード２００もしくはクライアントに返信する。

次に、データ処理手段２０２は、通信処理手段２０３から受けたデータ処理要求をデータ処理予測手段２０６に出力し、データ処理予測手段２０６は、このデータ処理要求を履歴としてデータ処理要求履歴格納手段２０７に格納する（ステップＡ４）。
続いて、データ処理予測手段２０６は、データ処理要求履歴格納手段２０７に格納されているデータ処理要求の履歴を参照して、あるデータについて過去から現在までのデータ取得パターン（データ取得回数又はデータ取得頻度）を履歴から求め、このデータについての将来のデータ取得パターンを予測し、事前配信しない場合のデータ取得にかかるコスト（メッセージ数やメッセージ量）がデータ事前配信にかかるコストを上回ると判断した場合には、データ事前配信手段２０８に当該データの事前配信を指示する（ステップＡ５）。

データ事前配信手段２０８は、データ事前配信の指示を受けると、指示されたデータをネットワーク１００を介して自ノード以外の全てのノード２００もしくは一部のノード２００へ事前配信する（ステップＡ６）。
事前配信されたデータを受信したノード２００では、データ事前配信手段２０８が受信したデータを自ノードのデータ格納手段２０１に格納する。

一方、経路表処理手段２０４は、通信処理手段２０３から経路表更新要求を受けた場合に、経路表格納手段２０５に格納された経路表を経路表更新要求に応じて更新する（ステップＡ７）。経路表更新要求は、例えば新たなノード２００がネットワーク１００に追加されたときに生成される。続いて、経路表処理手段２０４は、新たに経路表を更新する必要があるか否かを判断する（ステップＡ８）。通信処理手段２０３は、経路表処理手段２０４により新たに経路表を更新する必要があると判断された場合、新たな経路表更新要求をネットワーク１００を介して送信する（ステップＡ９）。

次に、経路表処理手段２０４は、ステップＡ１で通信処理手段２０３が受けたメッセージの転送が必要か否かを判断する（ステップＡ１０）。メッセージの転送が必要な場合としては、例えばメッセージが自ノード宛でない場合がある。経路表処理手段２０４は、メッセージの転送が必要と判断した場合、経路表格納手段２０５に格納された経路表の情報に基づいてメッセージの転送先を決定する。通信処理手段２０３は、経路表処理手段２０４により転送が必要と判断された場合、メッセージをネットワーク１００を介して転送先のノード２００に転送する（ステップＡ１１）。

なお、図２のステップＡ２において、通信処理手段２０３が受信した１つのメッセージに複数の要求が含まれる場合もある。また、ステップＡ５およびステップＡ８については、メッセージを受信する以外のイベント、例えば定期的なイベントにより実行される場合もある。

次に、本実施の形態の効果について説明する。本実施の形態では、データ処理要求の履歴をデータ処理要求履歴格納手段２０７に格納し、データ処理予測手段２０６がデータ処理要求の履歴を利用して将来のデータ取得要求のパターンを予測し、データを事前に配信するとコスト（メッセージ数やメッセージ量）が少なく済むと判断される場合に、データを事前配信することにより、データが事前配信されたノードにおいては以後の当該データの取得が即座に完了するので、全体としてデータ取得にかかる時間を軽減することができる。

Ｃｈｏｒｄシステムおよび一般的な分散ハッシュ表技術を用いた分散データ管理システムにおいて、一回のデータ取得にかかるコストはＯ（ｌｏｇ（Ｎ））であり、一般的なデータ配信にかかるコストはＯ（Ｎ）であるから、あるデータの取得回数が将来にわたってＯ（Ｎ／ｌｏｇ（Ｎ））回見込まれる場合は、データを事前配信することによるコストの増加はない。

［第２の実施の形態］
次に、本発明の第２の発明を実施するための最良の形態について図面を参照して詳細に説明する。図３は本発明の第２の実施の形態に係る分散データ管理システムにおけるノードの構成を示すブロック図であり、図１と同一の構成には同一の符号を付してある。
本実施の形態は、図１に示した第１の実施の形態の構成と比較して、経路表格納手段２０５とデータ事前配信手段２０８ａとが接続している点で異なる。

本実施の形態においては、データ事前配信手段２０８ａは、データを事前配信する際に、経路表格納手段２０５に格納されている経路表の情報を用いて、データの事前配信先を決定する。
第１の実施の形態では、データ事前配信手段２０８が事前配信のための情報を管理している必要があるが、本実施の形態では、データ事前配信手段２０８ａが経路表格納手段２０５に格納されている経路表の情報を用いることにより、データ事前配信手段２０８ａが別途配信のための情報を管理する必要がなくなるという効果がある。

一般に、分散ハッシュ表技術では、任意のノードにＯ（ｌｏｇ（Ｎ））ホップで到達するために経路表を管理してネットワークを構成するが、このネットワークは任意のノードを根とした木とみなせることが多い。そこで、本実施の形態では、データ事前配信手段２０８ａがデータを事前配信する際にその木を使って事前配信することにより、新たにネットワーク構造を用意する必要がなくなる。

［第３の実施の形態］
次に、具体的な例を用いて本発明を実施するための最良の形態の動作を説明する。本実施の形態は、第１の実施の形態をより具体的に説明するものである。本実施の形態では、分散ハッシュ表技術の例としてＣｈｏｒｄシステムを想定し、データを事前配信する技術としては二分木の構造をもったアプリケーションレイヤマルチキャストを想定している。分散ハッシュ表技術の他の例としては、ＫａｄｅｍｌｉａやＰａｓｔｒｙなどが知られている。データの事前配信の技術としては、アプリケーションレイヤマルチキャストだけでなく、ＩＰマルチキャストも利用することができる。

図１に示したデータ格納手段２０１とデータ処理手段２０２と通信処理手段２０３と経路表処理手段２０４と経路表格納手段２０５は、Ｃｈｏｒｄシステムの構成要素である。Ｃｈｏｒｄシステムの詳細は例えば特許文献１に開示されている。
本実施の形態においては、通常のＣｈｏｒｄシステムと異なり、事前に配信されたデータを取得すること、および履歴を記録することの２つの理由により、データ処理要求が常にデータ処理手段２０２に出力されるようにする。

以下では、Ｃｈｏｒｄシステムの構成要素を除いたデータ処理予測手段２０６と、データ処理要求履歴格納手段２０７と、データ事前配信手段２０８とについて詳細に説明する。データ処理要求履歴格納手段２０７は、メモリもしくはファイルシステム上のデータベースであり、例えばＣＳＶ（Comma Separated Values）形式のファイルを保存する。ＣＳＶファイルの一行は、＜時刻＞，＜取得／登録＞，＜ノード情報＞，＜キー＞，＜データ＞，＜有効期限＞とする。ただし、＜データ＞および＜有効期限＞はデータ登録要求の場合のみ必要である。また、＜データ＞および＜有効期限＞はデータ格納手段２０１と重複する場合は省略することもできる。＜ノード情報＞はＩＰアドレスに加え、分散ハッシュ表（経路表）が提供するＩＤやグループの情報などによって構成される。

データ処理予測手段２０６は、データ処理手段２０２からデータ処理要求を受けると、このデータ処理要求を逐次にもしくは定期的にデータ処理要求履歴格納手段２０７のＣＳＶファイルに追記する。また、データ処理予測手段２０６は、ＣＳＶファイルへの追記と同期的もしくは非同期的に、データ処理要求に対応したデータもしくはデータ格納手段２０１に格納されている全てのデータについて、それらのデータを事前に配信すべきか否かを判断する。

データを事前に配信すべきか否かを判断するためには、予めもしくは動的に配信にかかるコストを見積もる必要がある。ここで、データのサイズは十分に小さいと仮定し、ストレージコストを無視すると、コストはメッセージ送受信の量となる。データサイズが固定の場合は、メッセージ送受信の量はメッセージ数と同等であり、以下ではコストとしてメッセージ数を考える。

二分木によるマルチキャストでは、すべてのノードが厳密に１回メッセージを受信するため、Ｎ個のノードにデータを事前配信するコストはＮである。ところで、分散ハッシュ表を用いた場合には、一般にデータ取得にＯ（ｌｏｇ（Ｎ））のコストがかかり、Ｃｈｏｒｄシステムでは、データ取得に平均的にｌｏｇ（Ｎ）／ｌｏｇ（２）／２のコストがかかる。仮に、あるデータについて今後の取得回数もしくは取得ノード数がＭであるとすると、このデータ取得にかかるコストの合計の期待値は、Ｍ×ｌｏｇ（Ｎ）／ｌｏｇ（２）／２になる。

データ事前配信手段２０８は、このコストの合計の期待値Ｍ×ｌｏｇ（Ｎ）／ｌｏｇ（２）／２がデータの事前配信コストＮより大きければ、データを事前配信すべきと判断する。データ事前配信手段２０８で利用されるネットワークは、すべてのノード２００によって一つの二分木を構成する。データは二分木の根に相当するノード２００から事前配信される。根に相当するノード２００に負荷が集中しないように、複数の二分木を構成する場合もある。

データの事前配信を受けたノード２００では、事前配信されたデータがデータ格納手段２０１に格納される。以後、このノード２００において当該データの取得要求が発生した場合には、データ格納手段２０１から当該データを取得することができるので、データ取得が即座に完了する。

次に、データ事前配信手段２０８が将来のデータ取得頻度（データ取得回数）Ｍを予測する方法について説明する。Ｍの予測方法には２種類ある。第一の方法は、過去から現在までのデータ取得頻度と将来のデータ取得頻度とが線形の関係にあると仮定する方法である。この方法では、例えばデータ登録時点から現在までの時間をＴ１とし、現在からデータの有効期限までの時間をＴ２とし、データ登録時点から現在までのデータ取得回数をＫとすると、現在からデータの有効期限までのデータ取得回数はＭ＝Ｋ×Ｔ２／Ｔ１と予測することができる。また、例えば単位時間Ｔ（例えば１分）におけるデータ取得回数の平均値をＬとし、前記のＴ２を用いると、現在からデータの有効期限までのデータ取得回数はＭ＝Ｌ×Ｔ２／Ｔと予測することができる。

Ｍ＝Ｋ×Ｔ２／Ｔ１又はＭ＝Ｌ×Ｔ２／Ｔの予測例では、現在からデータの有効期限までの時間Ｔ２が必要であるが、Ｔ２が定められていない場合は、例えばＴ２をＴ１の半分とすればよい。また、例えばあるデータを更新する場合には、当該データの過去の取得頻度を今後の取得頻度としてＭを予測することができる。また、例えばデータの類似性が判定できる場合には、当該データに類似したデータの過去の取得頻度を当該データの今後の取得頻度としてＭを予測することができる。

第二の方法は、過去から現在までのデータ取得頻度と将来のデータ取得頻度とが非線形の関係にあると仮定する方法である。この方法では、例えばデータ登録時点から現在までのデータ取得回数をＫとすると、将来のデータ取得回数はＭ＝Ｋ／２と予測することができる。また、例えばデータ取得頻度が単調減少するものとして、データ登録時点から現在までのデータ取得パターンよりデータ取得頻度の減少の傾きＪを推定する。現在のデータ取得頻度をＬとすれば、将来のデータ取得頻度はＭ＝Ｌ×Ｌ／Ｊ／２と予測することができる。また、例えばデータ取得頻度は２次関数に従って減少するものとして、データ登録時点から現在までのデータ取得パターンより最少二乗法により２次関数を推定して、将来のデータ取得頻度Ｍを予測することもできる。

また、前記第一の方法、および第二の方法の両方の場合において、データの事前配信範囲を限定し、この事前配信範囲のみの取得パターンを利用して将来のデータ取得頻度（データ取得回数）Ｍを予測するようにしてもよい。この場合、データ事前配信手段２０８は、事前配信範囲のみのデータ事前配信コストよりも事前配信しない場合のデータ取得にかかるコストの合計の期待値Ｍ×ｌｏｇ（Ｎ）／ｌｏｇ（２）／２が大きければ、データを事前配信すべきと判断し、当該範囲にデータを事前配信する。

事前配信範囲としては、例えばＩＰネットワークのサブネットを用いてグループ化したノード２００のグループや、ＩＰマルチキャストのグループ、あるいは分散ハッシュ表（経路表）が提供するグループ情報を用いてグループ化したノード２００のグループなどがある。

ＩＰネットワークのサブネットを用いてグループ化する場合は、ＩＰアドレスをビット列とみなして、あるプレフィックス長を用いプレフィックスが一致するＩＰアドレスを持つノードをグループ化する。データ事前配信手段２０８は、グループ毎にデータ取得頻度Ｍを予測し、事前配信しない場合のデータ取得にかかるコストの合計の期待値Ｍ×ｌｏｇ（Ｎ’）／ｌｏｇ（２）／２が事前配信範囲のデータ事前配信コストＮ’より大きければ、データを事前配信すべきと判断し、当該事前配信範囲のグループにデータを事前配信する。ただし、Ｎ’は当該グループ中のノード数である。

また、ＩＰアドレスのプレフィックスを用いたデータの事前配信を行う場合、アプリケーションレイヤマルチキャストの二分木は、ＩＰアドレスのプレフィックス一致長が長いノード同士を近くに接続するように構成する。

なお、第１〜第３の実施の形態におけるノード２００は、例えばＣＰＵ、記憶装置およびインタフェースを備えたコンピュータとこれらのハードウェア資源を制御するプログラムによって実現することができる。このようなコンピュータを動作させるためのプログラムは、フレキシブルディスク、ＣＤ−ＲＯＭ、ＤＶＤ−ＲＯＭ、メモリカードなどの記録媒体に記録された状態で提供される。ＣＰＵは、読み込んだプログラムを記憶装置に書き込み、このプログラムに従って第１〜第３の実施の形態で説明した処理を実行する。

本発明は、ネットワーク上で、あるノードから別のノードへ情報を配信するといった用途に適用できる。また、受信ノードを特定しないで情報を配信するといった用途にも適用可能である。

本発明の第１の実施の形態に係る分散データ管理システムにおけるノードの構成を示すブロック図である。 本発明の第１の実施の形態に係る分散データ管理システムの動作を示すフローチャートである。 本発明の第２の実施の形態に係る分散データ管理システムにおけるノードの構成を示すブロック図である。 ピアツーピアネットワークの構成例を示すブロック図である。 従来のＣｈｏｒｄシステムにおけるノードの構成を示すブロック図である。

符号の説明

１００…ネットワーク、２００…ノード、２０１…データ格納手段、２０２…データ処理手段、２０３…通信処理手段、２０４…経路表処理手段、２０５…経路表格納手段、２０６…データ処理予測手段、２０７…データ処理要求履歴格納手段、２０８，２０８ａ…データ事前配信手段。

Claims (6)

1. ピアツーピアネットワークにおける分散データ管理システムにおいて、
   ネットワークに接続される各ノードは、
   他ノードと前記ネットワークを介して通信する通信処理手段と、
   データを記憶するデータ格納手段と、
   前記通信処理手段が受信したデータ処理要求に応じて、前記データ格納手段に格納されたデータを処理するデータ処理手段と、
   前記データ処理要求の履歴を記憶するデータ処理要求履歴格納手段と、
   前記データ処理要求の履歴を基に他ノードのデータ処理パターンを予測して、このノードにデータを事前に配信するか否かを判断するデータ処理予測手段と、
   このデータ処理予測手段から配信の指示を受けたときに、指示されたデータを前記他ノードに配信するデータ事前配信手段と、
   経路表を記憶する経路表格納手段と、
   この経路表格納手段に格納された経路表の情報に基づいて、前記通信処理手段が受信したメッセージの転送先を決定する経路表処理手段とを備え、
   前記経路表は、分散ハッシュ表技術を用いて構築され、
   前記データ処理予測手段は、前記データ処理要求の履歴を基に過去から現在までの前記データ処理パターンを求め、このデータ処理パターンから将来のデータ処理パターンを予測して、事前配信しない場合のデータ取得にかかるコストがデータ事前配信にかかるコストを上回ると判断した場合に、データの事前配信を決定することを特徴とする分散データ管理システム。
2. 請求項１記載の分散データ管理システムにおいて、
   前記データ事前配信手段は、前記経路表格納手段に格納された経路表の情報を用いてデータを事前に配信することを特徴とする分散データ管理システム。
3. 請求項１又は２記載の分散データ管理システムにおいて、
   前記データ処理予測手段は、特定のノードのグループを事前配信範囲として、この事前配信範囲についてのみ前記データ処理パターンを予測し、
   前記データ事前配信手段は、前記ノードのグループに対してのみデータを事前に配信することを特徴とする分散データ管理システム。
4. 請求項１乃至３のいずれか１項に記載の分散データ管理システムにおいて、
   前記データ処理予測手段は、他ノードにおける過去から現在までのデータ取得頻度と将来のデータ取得頻度とが線形の関係にあると仮定して、将来のデータ取得頻度を前記データ処理パターンとして予測することを特徴とする分散データ管理システム。
5. 請求項４記載の分散データ管理システムにおいて、
   前記データ処理予測手段は、データ登録時点から現在までの時間をＴ１とし、現在からデータの有効期限までの時間をＴ２とし、データ登録時点から現在までのデータ取得回数をＫとしたときに、将来のデータ取得回数の予測値をＫ×Ｔ２／Ｔ１とすることを特徴とする分散データ管理システム。
6. ピアツーピアネットワークにおける分散データ管理方法において、
   ネットワークに接続される各ノードは、
   自ノードの通信処理手段が受信したデータ処理要求に応じて、自ノードのデータ格納手段に格納されたデータを処理するデータ処理手順と、
   前記データ処理要求の履歴を記憶するデータ処理要求履歴格納手順と、
   前記データ処理要求の履歴を基に他のノードのデータ処理パターンを予測して、このノードにデータを事前に配信するか否かを判断するデータ処理予測手順と、
   このデータ処理予測手順で事前配信が決定されたデータを前記他のノードに配信するデータ事前配信手順と、
   経路表格納手段に格納された経路表の情報に基づいて、前記通信処理手段が受信したメッセージの転送先を決定する経路表処理手順とを実行し、
   前記経路表は、分散ハッシュ表技術を用いて構築され、
   前記データ処理予測手順は、前記データ処理要求の履歴を基に過去から現在までの前記データ処理パターンを求め、このデータ処理パターンから将来のデータ処理パターンを予測して、事前配信しない場合のデータ取得にかかるコストがデータ事前配信にかかるコストを上回ると判断した場合に、データの事前配信を決定することを特徴とする分散データ管理方法。

Images