以下、本発明の実施の形態について、図面を用いて説明する。尚、すべての図面において、同様な構成要素には同様の符号を付し、適宜説明を省略する。
本発明の情報システムは、複数のノードに分散して格納されるデータへのデータアクセス時の宛先管理を行うものであり、たとえば、範囲検索等の連続性や順序性の必要なデータアクセス処理を効率的に行うことを可能にする。そして、本発明の情報システムは、複数の格納先に格納されたデータに対して、格納先を追加してもアクセスできる規模拡張性の高い(スケーラブルな)宛先管理を行うことができる。
すなわち、本発明の情報システムは、上述した課題であるノードのデータ分布変化に伴う性能や信頼性の低下の問題点を解決することができる。
(第1の実施の形態)
図1は、本発明の実施の形態に係る情報システム1の構成を示すブロック図である。
本発明の実施の形態の情報システム1は、互いにネットワーク3を介して接続される複数のコンピュータ、たとえば、複数のデータ操作クライアント104(図1では、データ操作クライアントB1〜Bnと示す。以下、nは自然数であり、以下、それぞれ異なる値をとってもよい。)と、複数のデータ格納サーバ106(図1では、データ格納サーバC1〜Cnと示す。)と、複数の操作要求中継サーバ108(図1では、操作要求中継サーバD1〜Dnと示す。)と、を備える。
データ格納サーバ106は、少なくとも1つのノードを含み、各ノードにデータ群を分散して格納する。データ格納サーバ106は、アプリケーションやクライアントからの要求に応じて、各ノードに格納されているデータへのアクセスの管理を行う。データ格納サーバ106の各ノードには、ネットワーク上で特定可能な宛先、たとえば、IPアドレスが割り当てられる。
なお、本情報システム1をデータベースシステムではなく、データストリームシステムやPublish/Subscribe(Pub/Sub)システムとして利用する場合には、データ格納サーバ106には、データそのものではなく条件式等が格納される。
このとき、データストリームでは、データを範囲として扱い、条件式を値として扱ってもよい。たとえば、属性の次元数をDとすると、D次元属性範囲を持つSubscribe条件式は2D次元属性値のデータとして扱うことができ、D次元属性値を持つデータは2D次元の属性範囲として扱うことができる。データが登録された際には、そのデータに対応する2D次元の属性範囲に含まれるような、2D次元の属性値であるSubscribe条件式を列挙し、その条件式にデータの登録を通知する。あるいは、Subscribe条件式を属性範囲とし、データを属性値として扱う場合には、格納される属性範囲を複数のノードに分割し、各々の属性範囲をさらにノード内のデータの格納単位(例えば、ブロックなど)の単位に分割して、各々のブロック毎にSubscribe属性範囲が格納され、属性範囲のデータがあるブロックに登録される際に対応する属性範囲に含まれるかが監視され、通知されるかの判断がなされてもよい。
データ操作クライアント104は、少なくとも1つのノードを含み、アプリケーションプログラムまたはユーザからデータへのアクセス要求を受け付け、データ格納サーバ106に格納されているデータを要求に応じて操作する。データ操作クライアント104は、アクセス要求された目的のデータが格納されているノードを特定する機能を有する。
操作要求中継サーバ108は、少なくとも1つのノードを含み、データ操作クライアント104からのアクセス要求をノード間で転送しながら目的のノードに到達させる機能を有する。たとえば、自ノードが管理していないデータに対するアクセス要求を受け付けたデータ格納サーバ106が、操作要求中継サーバ108として機能する。
なお、後述する宛先解決部のアルゴリズムがDHTのようにノード間転送を行うものではなく、フルメッシュで通信を行うアルゴリズムである場合は、操作要求中継サーバ108は不要である。
本実施の形態の情報システム1は、CPU(Central Processing Unit)と、メモリと、メモリにロードされた各図の構成要素を実現するプログラムと、そのプログラムを格納するハードディスクなどの記憶ユニットと、ネットワーク接続用インタフェースとを備える任意のコンピュータのハードウェアとソフトウェアの任意の組合せにより実現される。そして、その実現方法、装置にはいろいろな変形例があることは、当業者には理解されるところである。
以下に説明する各図は、ハードウェア単位の構成ではなく、機能単位のブロックを示している。なお、各図において、本発明の本質に関わらない部分の構成については省略してあり、図示されていない。
また、本実施の形態の情報システム1を構成する各サーバおよびクライアントは、仮想マシンなど仮想化されたコンピュータ、あるいは、クラウドなどネットワーク越しに利用者にサービスを提供するサーバ群などであってもよい。
本発明の情報システム1は、異なるコンピュータに分散して格納されたデータを、1次元以上の属性の範囲検索が可能な表構造形式で、多様なアプリケーションソフトウェアに対してデータへのアクセス機能を提供するデータベースといった用途に適用できる。
コンピュータが参照および操作できるリレーショナルデータベースは、複数の列(属性)からなる行(タプル)がある。本実施形態をプライマリー・インデックスとして適用する場合には、このうち、行のキーとなる1以上の属性に対して適用する。セカンダリー・インデックスとして適用する場合には、行のキー以外の1以上の属性に対して適用する。これらは、指定された列の検索を速くするために、1つの属性に対する単一インデックス、あるいは、複数の属性に対する複合インデックスとして予め設定される。複数の属性の例としては、たとえば、緯度と経度、温度と湿度、あるいは、商品の金額、メーカ、型番、発売時期、および仕様などである。
また、分散したコンピュータに送信されたメッセージやイベントに対して、1次元以上の属性の範囲に関する条件指定を用いて、データの発生の検知や通知を設定するPub/Subといったメッセージ送受信形態の用途にも適用可能である。あるいは、発生するイベントを列(属性)からなる行(タプル)としてモデル化し、これに対する検索として継続的クエリ(ContinuousQuery)を実行するデータストリーム・マネジメントシステムにも適用可能である。
本実施形態の情報システム1を、リレーショナルデータベースとして利用する形態には、オンライントランザクション処理(Online Transaction Processing:OLTP)としての形態と、オンライン分析処理(Online Analytical Processing:OLAP)としての形態がある。OLTPの形態とは、たとえば、ウェブサイトのショッピングモールにクライアントがアクセスし、商品を検索するために複数の条件、たとえば、金額範囲、発売時期などを入力して、該当する商品を検索するような利用形態である。
なお、ウェブサイトへのクライアントからの検索要求などは、何万件/秒で発生するものである。一方で、OLAPの形態とは、たとえば、OLTPによって格納された過去の全データから、ウェブサイトの管理者が、売上動向を把握するために、購入者の年令、購入金額、購入時間帯などの複数の条件を指定して、その件数を取得するような利用形態である。また、Pub/Subあるいは、データストリーム・マネジメントシステムとして利用する形態では、たとえば、通知を受けたい緯度・経度などの範囲を指定すると、その属性範囲に含まれるデータが発生した際に通知を受けることができるような利用形態である。
本実施形態の情報システム1は、1次元以上の属性のデータを担う複数のコンピュータ(たとえば、図1のデータ格納サーバ106)からなる分散環境で用いることができる。このような環境において、本実施形態の情報システム1は、1次元以上の属性値に対応するコンピュータ(データ格納サーバ106または操作要求中継サーバ108)を決定する際、以下のように宛先決定を行うことができる。あるいは、本実施形態の情報システム1は、範囲検索などの1次元以上の属性の空間に対して複数のコンピュータ(データ格納サーバ106または操作要求中継サーバ108)を決定する際、以下のように宛先決定を行うことができる。
まず、予めデータを格納するサーバ(データ格納サーバ106)には、有限の論理識別子ID空間における一意な識別子(以下、論理識別子IDと呼ぶ)が割当てられる。そして、各サーバ(データ格納サーバ106)は論理識別子IDが近い他のサーバ(データ格納サーバ106)に対して、属性毎のデータ量の負荷分散のためにデータ移動と値域の変更を行う。この値域の変更は、ノード間の論理識別子IDに基づいて決定されるノード間の送受信依存関係に従って、他のノードが管理する属性毎の宛先表に反映される。
属性値に対応するコンピュータ(データ格納サーバ106または操作要求中継サーバ108)の決定、あるいは属性の空間に対応する複数コンピュータ(データ格納サーバ106または操作要求中継サーバ108)の決定を行う際には、この属性毎の宛先表を参照して、決定することができる。それにより、データの分布の変化に対しても、特定のコンピュータ(データ格納サーバ106)への負荷の偏りを伴わないようになる。さらに、ノード間で構成される送受信関係の数である次数を増加させずに、属性値の順序にデータを均等にコンピュータ(データ格納サーバ106)に格納できる。したがって、範囲検索等の柔軟な検索を行うことができる。
本実施の形態の情報システム1は、たとえば、図2に示すように、互いにネットワーク3を介して接続された、主にデータの格納を担う複数のデータコンピュータ208(図2では、データコンピュータF1〜Fnと示す。)と、主にデータへの操作要求を発行するアクセスコンピュータ202(図2では、アクセスコンピュータE1〜Enと示す。)と、がスイッチ206を介して接続された構成であってもよい。また、さらにデータコンピュータ208に格納されるデータ構造に関する情報(スキーマ)を保持するメタデータコンピュータ204を加えた構成としてもよい。
図4は、本実施形態の情報システム1の構成を示す機能ブロック図である。
本実施形態の情報システム1は、データ群を分散して管理する複数のノード(データ格納サーバ106)を備え、複数のノード(データ格納サーバ106)は、それぞれネットワーク上で識別可能な宛先アドレスを有し、複数のノード(データ格納サーバ106)に対し、論理識別子空間上で論理識別子を付与する識別子付与部(宛先表管理部400)と、論理識別子空間と、データ群におけるデータの値の範囲と、を対応付け、各ノード(データ格納サーバ106)が管理するデータの値域を、各ノード(データ格納サーバ106)の論理識別子に対応させて決定する値域決定部(宛先表管理部400)と、ある属性値または属性範囲のデータの格納先のノード(データ格納サーバ106)の宛先を探索するとき、各ノード(データ格納サーバ106)のデータの値域と、論理識別子と、宛先アドレスとの対応関係に基づき、属性値または属性範囲の少なくとも一部が一致するデータの値域に対応する論理識別子を求め、当該論理識別子に対応するノード(データ格納サーバ106)の宛先アドレスを宛先として決定する宛先決定部(宛先解決部340)と、を備える。
具体的には、図4に示すように、本実施形態の情報システム1は、宛先解決部340と、操作要求部360と、中継部380と、宛先表管理部400と、負荷分散部420と、データ管理部440と、を備える。
本実施形態において、宛先解決部340、操作要求部360、および宛先表管理部400は、データ操作クライアント104の各ノードに含まれる。また、宛先解決部340、中継部380、および宛先表管理部400は、操作要求中継サーバ108の各ノードに含まれる。負荷分散部420およびデータ管理部440は、データ格納サーバ106の各ノードに含まれる。
図5は、サーバ間通信のプロトコルスタックを示すブロック図である。
図5(a)は、データ操作クライアント104における宛先解決処理において、ノードが格納するデータの属性値とノードの通信アドレスとを対応付けた宛先表を用いる分散システムの例を示す図である。
この例では、コンピュータ間の接続関係は各ノードがそれぞれ保持する宛先表10に記述される。各ノードは、それぞれ異なるノードの宛先を含む宛先表10を有する。どのノード(N1、N2、N3、・・・)の宛先表10にどのノードを含めるかは、格納データの属性分布に応じて決定される。
この場合、負荷分散のために、属性の分布に応じて論理識別子ID空間でのノードの分布が適応的に変化する。これによってノード間の接続関係が決定される。すなわち、ノード間の送受信関係を決定する層が、図5(a)の20で示される部分となる。アプリケーションプログラムからのデータアクセス要求22に基づいて、宛先解決部(不図示)は、属性値12と通信アドレス(IPアドレス14)の対からなる宛先表10を参照し、データ格納場所(図5(a)ではノードN3)までの宛先を解決する。これにより、データアクセス要求22がデータ格納先まで転送され、アプリケーションプログラムが目的のデータ24にアクセスできることになる。
図5(b)は、データ操作クライアント104における宛先解決処理において、ノード(N1、N2、N3、・・・)が格納するデータの属性値を論理識別子IDに変換し、論理識別子IDとノードの通信アドレスIPとを対応付けた宛先表30を用いる分散システムの例を示す図である。
この例では、属性値が均一になるように論理識別子IDに変換する場合は、属性の分布に応じてこの変換を変更する必要がある。すなわち、ノード間の送受信関係を決定する層が、図5(b)の40で示される部分となる。アプリケーションプログラムからのデータアクセス要求22に基づいて、宛先解決部(不図示)が、データの属性値を論理識別子IDに変換し、論理識別子IDと通信アドレスIPの対からなる宛先表30を参照して、データ格納場所まで(図5(b)ではノードN3)の宛先を解決する。これにより、データアクセス要求22がデータ格納先まで転送され、アプリケーションプログラムが目的のデータ24にアクセスできることになる。
図6は、本実施形態の情報システム1のサーバ間通信のプロトコルスタックを示すブロック図である。
図6の本実施形態の情報システム1では、データ操作クライアント104における宛先解決処理において、ノード(N1、N2、N3、・・・)間の接続関係を決定するID宛先表30だけではなく、アクセスされる属性毎に、その属性空間での範囲(値域)と通信アドレスIPの対応を属性宛先表50として保持する。宛先解決部(不図示)が、これらのID宛先表30および属性宛先表50を参照して、データ格納場所(図6ではノードN3)までの宛先を解決する。すなわち、ノード間の送受信関係を決定する層が、図6の60で示される部分となる。これにより、アプリケーションからのデータアクセス要求22がデータ格納先まで転送され、アプリケーションプログラムが目的のデータ24にアクセスできることになる。
次に、本実施形態の情報システム1の構成の詳細について、図7および図8を用いて説明する。
図7および図8は、本実施形態の情報システム1の要部構成を示す機能ブロック図である。
図7に示す操作要求部360、宛先解決部340、および宛先表管理部400は、上述したように、図4のデータ操作クライアント104の各ノードに含まれる。宛先表管理部400は、図4の操作要求中継サーバ108の各ノードにも含まれる。また、図8に示す負荷分散部420およびデータ管理部440は図4のデータ格納サーバ106の各ノードに含まれる。
図7に示すように、宛先表管理部400は、ID宛先表格納部402と、属性宛先表格納部404と、値域更新部406と、ID検索部408と、ID宛先表構築部410と、を含む。
ID宛先表格納部402は、図11に示すID宛先表412を記憶する。
図11に示すように、ID宛先表412は、論理識別子ID(ハッシュ値)と、通信アドレス(図では、サーバIPアドレス)とを対応付けて記憶する。通信アドレスは、ネットワークに接続された、属性を有するデータ群を分散して格納する複数のコンピュータ(ノード)間でネットワークを介して互いに通信を行うときの宛先となるコンピュータ(ノード)の通信アドレスである。本実施形態では、論理識別子IDは、有限なハッシュ空間(たとえば、2の160乗)にて、各ノードに一意にかつ確率的に均一に分布するように割当てられる。詳細については後述する。
また、図7のID宛先表格納部402に格納されるノードの情報は、宛先解決部340のアルゴリズムにより異なる。中継部380を持たないフルメッシュのアルゴリズムにおいては、図11に示すように、任意のノードは全ノードの論理識別子IDと通信アドレスをID宛先表412として持つ。なお、自ノードの情報はID宛先表412に含まなくてもよい。
後述する実施形態のChordアルゴリズムにおいては、論理識別子ID空間において、図57に示すように、ID宛先表452は、自ノードより大きい論理識別子IDを有するSuccessorノードをSuccessorListとして有し、さらに、自ノードより2のべき乗の距離離れたノードをFingerノードとして複数有する。ここで、各ノードの論理識別子IDの大小の比較、およびノード間の距離の算出は、Consistent Hashingにて一般に定義される比較演算および距離演算の処理によりそれぞれ行われる。
また、後述する実施形態のKoordeアルゴリズムにおいては、Successorノードと自ノードの論理識別子IDの整数倍の論理識別子IDを有すノードをFingerノードとして複数持つ。
また、図7の属性宛先表格納部404は、図12に示す属性宛先表414を記憶する。属性宛先表414は、属性毎に設けることができる。図12に示すように、属性宛先表414は、各ノードの論理識別子417または通信アドレス(サーバIPアドレス418)と、属性空間内でそのノードが担当する部分空間である値域の値域端点416と、を対応付けて記憶する。
本実施形態では、ID宛先表412(図11)および属性宛先表414(図12)により、複数のノード(図4のデータ格納サーバ106または操作要求中継サーバ108)の宛先と、各ノード(データ格納サーバ106または操作要求中継サーバ108))に論理識別子空間上で確率的に均一に割り当てられた論理識別子IDと、ノード(データ格納サーバ106または操作要求中継サーバ108))が管理しているデータの属性の値域との対応関係をID宛先表格納部402および属性宛先表格納部404にそれぞれ保持することができる。ただし、確率の期待値としては、各ノードはノード数分の1のデータ量を持つが、厳密にノード数分の1のデータ量を持つことは保証しなくてよい。各ノードの負荷が、確率的には均一に割り振られることとなる。
図7に戻り、値域更新部406は、自ノードmの属性宛先表414を、他のノードが処理可能な属性空間内の部分空間である値域の変更に応じて更新する。たとえば、後述するように、データ格納サーバ106の負荷分散部420(図8)により値域が変更された場合、ネットワーク3を介して負荷分散部420から値域変更通知が値域更新部406に送信される。あるいは、ノード(図4のデータ格納サーバ106)から送信された値域変更通知が中継部380(図4の操作要求中継サーバ108)を経由して値域更新部406に送信される。
あるいは、中継部380が他ノードの障害などに応じて、そのノードのID宛先表412(図11)および属性宛先表414(図12)を更新する場合も、その変更が値域更新部406に通知されうる。
値域更新部406は、他のノード(データ格納サーバ106または操作要求中継サーバ108)から送信された値域変更通知に呼応して、属性宛先表414を更新する。
さらに、値域更新部406は、各ノード(データ格納サーバ106)に対し、死活監視(ヘルスチェック)を定期的に実行し、各属性の値域に変更がないかを確認し、属性宛先表414を非同期に更新することもできる。
この構成により、データ格納ノード(データ格納サーバ106)側で値域を変更した場合に、たとえ非同期にクライアント(データ操作クライアント104)側に伝えても、両者間(データ操作クライアント104とデータ格納サーバ106の間)または各ノード間(データ操作クライアント104同士、またはデータ格納サーバ106同士)のデータの一貫性を保つことができる。
ID検索部408は、ハッシュ空間内のある論理識別子IDを有するノードが管理するデータにアクセスする要求を処理可能とするために宛先を検索する。ID検索部408は、要求に呼応して、ID宛先表格納部402に格納されているID宛先表412を参照し、その要求を処理すべき宛先(ノードの通信アドレス等)を検索して決定する。
ID宛先表構築部410は、各ノードが有限のID(Identifier)空間における値を論理識別子ID(宛先、アドレス、または識別子)として持ち、そのIDに応じて、そのノードが担当するデータのID空間を決定する。データのIDは、DHTでは登録または取得したいデータのキーのハッシュ値を用いる。また、各ノードのIDは、ランダムあるいはノードに予め付された一意な識別子(たとえば、IPアドレスとポート)のハッシュ値を用いることができる。これにより負荷分散を図ることができる。ID空間は、リング型をとる方式、HyperCubeをとる方式などがある。上述したChordとKoordeなどは、リング型をとる方式のID空間を用いる。
このリング型をとる場合の、ノードとデータとの対応付け方式であるConsistent Hashingでは、任意の自然数をmとして、ID空間は1次元の[0,2m)を取り、各ノードiは、このID空間における値xiをIDとして取る。ただし、iはノード数Nまでの自然数で、xiの順に識別されているとする。
この時、ノードiは[xi,x(i+1))に含まれるデータを管理する。ただし、i=Nであるコンピュータは[0,x0)と[xN,2m)に含まれるデータを管理する。
さらに、ID宛先表構築部410は、すべてのノードの情報をID宛先表412に含めず、中継部380を必要とするアルゴリズム(たとえば、ChordやKoordeアルゴリズム)の場合、ID検索部408を用いながら、自ノードmのID宛先表412に他のどのノードを含めるかを決定し、ID宛先表412を作成または更新し、ID宛先表格納部402に記憶する。
図7に示すように、宛先解決部340は、単一宛先解決部342と、範囲宛先解決部344と、を備える。
単一宛先解決部342は、与えられたデータの1次元以上の属性値を入力として、属性宛先表格納部404に記憶された属性宛先表414(図12)を参照しながら、そのデータに関する操作要求を送信すべき先のコンピュータ(図4のデータ格納サーバ106のノード)の宛先(たとえば、通信アドレス)を取得する。
範囲宛先解決部344は、与えられた1次元以上の属性の範囲を入力として、属性宛先表414(図12)を参照しながら、そのデータに関する操作要求を送信すべき先のコンピュータ(図4のデータ格納サーバ106のノード)の宛先(たとえば、通信アドレス)を複数取得する。
なお、本実施形態では、情報システム1は、単一宛先解決部342と範囲宛先解決部344を両方備える構成としているが、特に限定されるものではなく、いずれか一方であってもよい。
本実施形態の情報システム1において、データへのアクセス要求とともに、アクセス対象のデータに対する属性値または属性範囲を受け付ける受付部(操作要求部360)と、操作要求部360が受け付けたアクセス要求とデータに対する属性値または属性範囲をノード(図4のデータ操作クライアント104または図4の操作要求中継サーバ108)に転送する転送部(中継部380)と、をさらに備えることができる。宛先決定部(宛先解決部340)は、操作要求部360がアクセス要求を受け付けたとき、属性値または属性範囲を有するデータにアクセスするためのノードの宛先を決定し、中継部380に受け渡し、中継部380は、宛先解決部340が決定した宛先のノード(データ操作クライアント104または操作要求中継サーバ108)にアクセス要求とデータに対する属性値または属性範囲を転送する。
図7に示されるように、操作要求部360は、データ追加削除部362と、データ検索部364と、を備える。
データ追加削除部362は、外部のアプリケーションプログラム、あるいはデータベースシステムを構成するプログラムに対して、データの追加削除操作サービスを提供する役割を担う。データ追加削除部362は、ある属性値を持つデータの追加あるいは削除要求を受付け、単一宛先解決部342が解決する宛先ノードの中継部380あるいはデータ管理部440(図4のデータ格納サーバ106に含まれる)にネットワーク3を介してアクセスを行い、要求された処理を実行して要求元に結果を返す。
データ検索部364は、データの検索操作サービスを提供する役割を担う。データ検索部364は、属性空間内のある属性範囲に対するデータ検索要求を受付け、範囲宛先解決部344が解決する複数の宛先ノードの中継部380あるいはデータ管理部440にネットワーク3を介してアクセスを行い、要求された処理を実行して要求元に結果を返す。いずれも、その結果に値域変更通知が含まれる際には、宛先表管理部400の値域更新部406に対して値域更新を指示する。
中継部380は、図4のデータ操作クライアント104の他のノードの操作要求部360あるいは図4の操作要求中継サーバ108の他のノードの中継部380から、ある属性値、あるいはある属性範囲に対するデータアクセス要求を受付ける。そして、中継部380は、その応答のために、属性値については単一宛先解決部342が解決する宛先ノードを取得し、属性空間内のある属性範囲については、範囲宛先解決部344が解決する1以上の宛先ノードを取得する。そして、中継部380は、図4のデータ格納サーバ106のノードまたは図4の操作要求中継サーバ108の他のノードにアクセスして得られた結果に値域変更通知が含まれる場合には、値域更新部406に対して値域更新を指示する。
また、あるノード(データ格納サーバ106)のデータアクセス部444が、属性宛先表414を参照して中継処理を実行したノード(操作要求中継サーバ108)が認識する値域と、それを受けたノード(データ操作クライアント104または操作要求中継サーバ108)が認識する値域が異なることを認識した場合に、データアクセス部444からデータアクセスを実行したノード(データ操作クライアント104)に値域変更通知が返信される。中継部380は、この値域変更通知を受信し、リダイレクト先に転送する機能も有する。
また、操作要求部360がデータ格納サーバ106のデータにアクセスするために関与する中継部380の役割およびシーケンスは、一通りではない。データ追加削除部362のシーケンスを図9に示し、データ検索部364のシーケンスを図10に示す。図9および図10に示すように、シーケンスは、大きく分類して反復パターン(図9(e)および図10(e))と、再帰パターン(図9(a)〜図9(d)および図10(a)〜図10(d))がある。
反復パターン(図9(e)および図10(e))では、データ操作クライアント104における操作要求部360が、操作要求中継サーバ108から次の操作要求中継サーバ108あるいはデータ格納サーバ106の通信アドレスを反復的に取得する。再帰パターン(図9(a)〜図9(d)および図10(a)〜図10(d))では、データ操作クライアント104から要求を受付けた操作要求中継サーバ108が、その要求処理のために別の通信を再帰的に実行する。
さらに、再帰パターンには、非同期方式(図9(c)、図9(d)、図10(c)、および図10(d))と、同期方式(図9(a)、図9(b)、図10(a)、および図10(b))がある。非同期方式(図9(c)、図9(d)、図10(c)、および図10(d))では、操作要求中継サーバ108が、要求を送信したデータ操作クライアント104あるいは操作要求中継サーバ108に、要求を受信したとの応答を返す。同期方式(図9(a)、図9(b)、図10(a)、および図10(b))では、応答を返さず要求者の処理をブロックする。
また、再帰パターンには、1相式(図9(a)、図9(c)、図10(a)、図10(c))と、2相式(図9(b)、図9(d)、図10(b)、および図10(d))がある。1相式(図9(a)、図9(c)、図10(a)、図10(c))では、操作要求中継サーバ108が要求されたデータの格納先であるデータ格納サーバ106を特定したら、操作要求中継サーバ108自体がそのデータアクセス処理を実行する。2相式(図9(b)、図9(d)、図10(b)、および図10(d))では、操作要求中継サーバ108自体はそのデータアクセス処理を実行せずにデータ操作クライアント104にそのデータ格納サーバ106の通信アドレスを返し、データ操作クライアント104がそのデータ格納サーバ106に対してデータアクセス処理を実行する。
本実施形態では、主に再帰、同期、2相の方式(図9(b))について説明するが、いずれの方式でもよい。この方式の場合には、以下のように動作する。たとえば、あるノードの中継部(ここでは、仮に中継部380aと呼ぶ)は、他ノードの中継部(ここでは、仮に中継部380bと呼ぶ)あるいは操作要求部360から要求を受付け、宛先解決部340に次にアクセスすべき中継部(ここでは、仮に中継部380cと呼ぶ)あるいはデータ格納サーバ106の通信アドレスを問い合わせる。
そして、中継部380cの通信アドレスが返ってきた場合には、あるノードの中継部380aは、返信された通信アドレスの中継部380cにデータアクセス要求を送信する。そして、中継部380aは、返ってきたデータ格納サーバ106の通信アドレスを、要求を送信してきた中継部380bあるいは操作要求部360に返す。データ格納サーバ106の通信アドレスが返ってきた場合には、中継部380aは、要求を送信してきた中継部380bあるいは操作要求部360に、データ格納サーバ106の通信アドレスを返す。
図8に示すように、データ管理部440は、データ格納部442と、データアクセス部444と、を備える。
データ格納部442は、本情報システム1に格納/通知されるデータの一部のデータを記憶する記憶部を含む。さらに、データ格納部442は、負荷分散部420からの要求に応じて、指定された属性のデータ量またはデータ数を返し、他のノードへのデータ移動指示に応じてデータの入出力を行う機能を備える。
データアクセス部444は、操作要求部360または中継部380から、同一ノードのデータ格納部442に記憶されたデータに対する取得、追加、削除、または検索等の要求を受付け、データ格納部442に対してその処理を実行して、その結果を要求送信元に返す。
データアクセス部444は、さらに、操作要求部360、あるいは中継部380からの要求に対して、データに対するアクセスを実行する前に、負荷分散部420における値域格納部424を参照して、その要求が妥当か否かの判断を行う役割を担う。この判断は、同一のノードに格納されたデータ格納部442に格納されたデータの属性範囲に、要求されたデータアクセスにて指定された属性値あるいは属性範囲が含まれるか否かの判定により行われる。すなわち、データアクセス部444は、属性宛先表格納部404の属性宛先表414を参照してデータアクセスを実行したノードが認識する値域と、自身が認識する値域が異なるか否かを判定する。また、データアクセス部444は、要求を送信したノードを識別する情報を負荷分散部420の通知先格納部426に格納する役割を担ってもよい。
さらに、データアクセス部444は、前記判定結果で値域が一致しなかった場合、その妥当でない値域へのアクセスに対して、値域変更通知とリダイレクト先を要求元のノードに通知する。データアクセス部444は、自身が認識する値域とアクセス要求されたデータの属性値を比較し、比較結果に基づいて、アクセス要求を受け付けたデータに対応する属性の値域のデータを管理する隣接ノードを判別する。判別された隣接ノードがリダイレクト先として通知される。
リダイレクト先は、アクセス要求されたデータを担当すると想定されるノードの宛先の通信アドレスである。このように、データアクセス部444は、要求元のノードの属性宛先表414が値域変更通知で通知された値に更新されるように制御する機能も有する。
後述するように、各ノードが担当する値域は負荷を平滑化するために更新されることがあり、その更新内容はノード間で非同期に各ノードの属性宛先表414に反映される。そのため、ノード毎に管理している属性宛先表414は互いに異なる可能性がある。したがって、アクセス時に、アクセス要求元が認識しているノードが担当する値域と、実際にノードが格納している値域が一致しない可能性がある。そのため、この状態でアクセスを許可すると、異なる2つの要求元のノードが、同一のデータにアクセスする際にも、各々が別々のノードをデータ担当ノードと認識してしまい、アクセス側のノード間で一貫性のないデータ処理がされる可能性があるからである。
本実施形態のように、要求元のクライアントまたはアクセス要求を転送したノードは、リダイレクト先にアクセス要求を転送することで、値域が更新された後に、データアクセス要求を正しいノードに到達させることができる。
なお、本情報システム1をデータベースシステムではなく、データストリームシステムやPub/Subシステムとして利用する場合には、データ格納部442には、データではなく条件式が格納される。
たとえば、データ検索部364が受け付けた継続的クエリあるいはSubscribe条件で指定された属性範囲が条件式として格納される複数のノードのデータ格納部442に、データアクセス部444はアクセスする。また、データ追加削除部362が受け付けたデータ登録要求(Publish要求)については、データアクセス部444は与えられた属性値を含むノードのデータ格納部442にアクセスし、そこに格納された属性範囲の条件式を取得する。そして、データアクセス部444は、得られた継続的クエリあるいはSubscribe条件に基づいて、その内容に応じた通知処理や継続的クエリの実行を行う。
なお、このように、情報システム1をデータストリームシステムやPub/Subシステムとして利用する場合、データ格納部442にはデータは記録されていないため、負荷分散の尺度となる、属性のデータ量を取得することができない。したがって、この場合、ある属性のデータ量に替えて、単位時間当たりにデータ格納部442に登録要求されたデータ数を用いる。
あるいは、たとえば、データ検索部364が受け付けた継続的クエリあるいはSubscribe条件で指定されたD次元属性範囲を、2D次元属性値とし、これを格納するノードのデータ格納部442に、データアクセス部444は、アクセスする。また、データ追加削除部362が受け付けたデータ登録要求(Publish要求)については、データアクセス部444は与えられたD次元属性値を2D次元属性範囲とし、この範囲を担当する複数のノードのデータ格納部442にアクセスし、そこに格納された2D次元属性値であるD次元属性範囲の条件式を取得する。そして、データアクセス部444は、得られた継続的クエリあるいはSubscribe条件に基づいて、その内容に応じた通知処理や継続的クエリの実行を行う。
なお、この場合、データ格納部442には条件式が登録されるため、各ノードが保持する条件式の量が、負荷分散の尺度となる。
図8に示されるように、負荷分散部420は、平滑化制御部422と、値域格納部424と、通知先格納部426と、を含む。
値域格納部424は、同一ノードmのデータ管理部440のデータ格納部442に記憶されたデータの属性毎の値域の端点を、自ノードmと自ノードmのSuccessorノードおよびPredecessorノードの論理識別子IDまたはサーバIPアドレスをとともに記憶する値域表428(図13)を格納する。ここで、Successorノードとは、自ノードmより大きい論理識別子IDを有する隣接ノードである。Predecessorノードとは、自ノードmより小さい論理識別子IDを有する隣接ノードである。
通知先格納部426は、あるノードmのデータ管理部440のデータ格納部442に格納されるデータの値域に変更が発生したときに、その変更を通知すべき他のノードを識別する情報(たとえば、IPアドレス)を記憶した通知先表430(図14)を格納する。この通知先表430に情報が含まれるノード(各ノードmが変更を通知すべき他のノード)の選択方法は、各アルゴリズムによって異なる。詳細については後述する。
平滑化制御部422は、論理識別子IDが互いに隣接するノード間で、データの負荷が分散するように、少なくとも一部のデータを移動するとともに、移動に伴う値域の管理を行う。
平滑化制御部422は、同一ノードmのデータ管理部440のデータ格納部442に記憶されたある属性のデータ量またはデータ数と、他ノードのデータ格納部442に記憶された同一属性のデータ量またはデータ数とを比較し、その結果に応じてノード間にてデータ格納部442に記憶されたデータを移動させる指示を行う。また、前述した値域更新部406(図7)は、平滑化制御部422によるデータの移動に伴い、移動されたデータの属性の値域を更新する。また、平滑化制御部422は、データ移動と値域更新を行った際に、そのノードに通信する可能性のある一定のノードに対して、値域の更新を通知する。通知先は、たとえば、通知先表430に含まれるノードとすることができる。このように、平滑化制御部422のデータ移動によりデータの分布に変化が生じた場合にも、変化に応じて動的に値域が更新され、さらに、値域変更通知によってその更新情報を速く各ノードの属性宛先表414に反映させることで、データアクセス時の性能劣化問題が解消されることになる。
図13に示すように、値域表428は、Predecessorノードの値域端点ap(図では「18」)と、自ノードmの値域端点am(図では「32」)と、Successorノードの値域端点as(図では「63」)を保持する。また、各ノードmに対する値域の割当ては、Predecessorノードの値域端点apより大きく、自ノードmの値域端点amまでの範囲(ap,am]とする。
ここで、各ノードmへの値域の割当てを範囲(ap,am]とする場合、各ノードmのSuccessorノードの値域の割り当ては、範囲(am,as]となる。
本実施形態では、各ノードmに登録されるデータ属性の値域を決定する処理に際し、自ノードmの値域の割り当てとSuccessorノードの値域の割り当てが必要となるため、値域表428には、これらの範囲を特定するのに必要な、ノード(Predecessorノード、自ノードm、およびSuccessorノード)の値域端点が含まれる。しかし、本実施形態とは異なる規則で各ノードmに登録されるデータ属性の値域を決定する場合は、値域表428は、その規則に応じて必要なノードの情報を含むことができる。
また、図13の値域表428には、値域端点とともに通信アドレスも含まれるが、これに限定されない。たとえば、値域表428には、属性毎に値域の端点のみが記憶され、Predecessorノード、自ノードm、およびSuccessorノードの通信アドレスは別の管理表に記憶されて管理されていてもよい。
図14の通知先表430には、そのノードが通信するために必要な情報が記憶されていればよい。たとえば、通信アドレス(IPアドレス、ポート番号など)に替えて、図7の通知先格納部426には、通信アドレスとの対応付けが可能なノードの論理識別子IDが記憶されてもよい。
また、本実施形態では、図14の通知先表430には、上述したように図8のデータアクセス部444から通知された情報が登録されているが、これに限定されず、予め通知先が与えられていてもよい。なお、データストリームシステムあるいはPub/Subシステムにおいては、平滑化制御部422はデータ格納部442に格納されたデータを移動させる代わりに、要求された継続的クエリあるいはSubscribe条件について、その属性範囲を適宜分割し、ノード間で移動させる処理を行うことができる。
上述のような構成において、本発明の実施の形態に係る管理装置(図4のデータ操作クライアント104)のデータ処理方法を以下に説明する。
図58および図59は、本発明の実施の形態に係るデータ操作クライアント104の動作の一例を示すフローチャートである。以下、図4、図58、および図59を用いて説明する。
本発明の実施の形態に係るデータ処理方法は、データ群を分散して管理する複数のノード(データ格納サーバ106)を管理する管理装置(図4のデータ操作クライアント104)のデータ処理方法であって、複数のデータ格納サーバ106は、それぞれネットワーク上で識別可能な宛先アドレス(IPアドレス)を有し、データ操作クライアント104が、複数のデータ格納サーバ106に対し、論理識別子空間上で論理識別子IDを付与し(図58のステップS11)、論理識別子空間と、データ群におけるデータの値の範囲と、を対応付け、各データ格納サーバ106が管理するデータの値域を、各データ格納サーバ106の論理識別子IDに対応させて決定する(図58のステップS13)。さらに、データ操作クライアント104が、ある属性値または属性範囲のデータの格納先のデータ格納サーバ106の宛先を探索するとき(図59のステップS21のYES)、各データ格納サーバ106のデータの値域と、論理識別子IDと、宛先アドレスとの対応関係に基づき、属性値または属性範囲の少なくとも一部が一致するデータの値域に対応する論理識別子IDを求め、当該論理識別子IDに対応するデータ格納サーバ106の宛先アドレスを宛先として決定する(図59のステップS23)。
さらに、本発明の実施の形態に係るデータ処理方法は、上記管理装置(データ操作クライアント104)に接続され、データ操作クライアント104を介してデータにアクセスする端末装置(外部アプリケーションプログラムからのサービス提供を受けている端末(不図示))のデータ処理方法であって、端末装置が、属性値または属性範囲を有するデータへのアクセス要求をデータ操作クライアント104に通知し、データ操作クライアント104を介して、複数のデータ格納サーバ106の宛先アドレスと、各データ格納サーバ106に割り当てられた論理識別子と、各データ格納サーバ106が管理しているデータの値域との対応関係に基づいて、アクセス要求された属性値または属性範囲の少なくとも一部が一致する値域のデータを管理するデータ格納サーバ106の宛先にアクセスしてデータを操作する。
また、本発明の実施の形態に係るコンピュータプログラムは、本実施形態のデータの管理装置(図4のデータ操作クライアント104)を実現するコンピュータに、複数のノード(図4のデータ格納サーバ106)に対し、論理識別子空間上で論理識別子を付与する手順、論理識別子空間と、データ群におけるデータの値の範囲とを対応付け、各データ格納サーバ106が管理するデータの値域を、各データ格納サーバ106の論理識別子に対応させて決定する手順、ある属性値または属性範囲のデータの格納先のデータ格納サーバ106の宛先を探索するとき、各データ格納サーバ106のデータの値域と、論理識別子と、宛先アドレスとの対応関係に基づき、属性値または属性範囲の少なくとも一部が一致するデータの値域に対応する論理識別子を求め、当該論理識別子に対応するデータ格納サーバ106の宛先アドレスを宛先として決定する手順を実行させるように記述されている。
本実施形態のコンピュータプログラムは、コンピュータで読み取り可能な記録媒体に記録されてもよい。記録媒体は特に限定されず、様々な形態のものが考えられる。また、プログラムは、記録媒体からコンピュータのメモリにロードされてもよいし、ネットワークを通じてコンピュータにダウンロードされ、メモリにロードされてもよい。
このように構成された本実施形態の情報システム1の動作について、以下に説明する。以下の順で各処理について説明する。
(1)各ノード(データ格納サーバ106)が負荷を平滑化する処理(負荷の平滑化処理)
(2)アプリケーションプログラムからノード(データ操作クライアント104)がデータアクセス要求を受け付ける処理(データアクセス要求受付処理)
(3)ノード(データ操作クライアント104)が、属性宛先表414の値域を更新する処理(値域更新処理)
(4)ノード(データ操作クライアント104)が受け付けたデータアクセス要求に従い、データアクセスを実行する処理(データ追加削除処理、データ検索処理)
(5)ノード(データ操作クライアント104)が、目的データの格納先のノード(データ格納サーバ106、または、途中、目的のノードを見つけるまでは、操作要求中継サーバ108)の宛先を見つけるまでの処理(宛先解決処理)
まず、本実施形態の情報システム1における負荷の平滑化処理について説明する。図15は、本実施形態の情報システム1における隣接ノード間との負荷の平滑化処理S100の手順の一例を示すフローチャートである。この平滑化処理S100は、データ格納サーバ106(図4)の負荷分散部420の平滑化制御部422(図8)が行う。以下、図8、図13乃至図15を用いて説明する。
なお、この平滑化処理S100は、本実施形態の情報システム1の起動時、または定期的に、自動的に実行され、あるいは、情報システム1の利用者の手動操作により、またはアプリケーションからの要求に呼応して実行される。
まず、ノードm(データ格納サーバ106)の負荷分散部420の平滑化制御部422が、自ノードmの値域格納部424に格納される値域表428(図13)に、通信アドレスが記憶されたSuccessorノードから、Successorノードのデータ管理部440のデータ格納部442に格納された全属性について属性毎にデータ量またはデータ数(図中、「データ数」と示す)を取得する(ステップS101)。
具体的には、ノードmの平滑化制御部422が、Successorノードに問い合わせる。そして、Successorノードが、自ノードのデータ管理部440のデータ格納部442を参照し、格納されている全属性のデータについて、属性毎にデータ量またはデータ数を取得する。そして、Successorノードがノードmにこれらの情報を返信する。
次いで、平滑化制御部422が、得られた複数の属性の各々について、ステップS103〜ステップS119の間のループ処理を行う。すべての属性について処理が終了したら本ループ処理を終了する。
ループ処理では、平滑化制御部422が、自ノードからその属性のデータ量またはデータ数(図中、「データ数」と示す)を取得し(ステップS105)、Successorノードとの負荷分散計画を算出する(ステップS107)。この負荷分散計画処理については、後述する。
変更計画がない場合(ステップS109の「変更なし」)、次の属性の処理に移る。データをSuccessorノードから自ノードに入力する(Import)計画がある場合(ステップS109のImport)、その計画に基づき、平滑化制御部422が、Successorノードのデータ格納部442から自ノードのデータ格納部442にデータを移動させる(ステップS113)。データを自ノードからSuccessorノードに出力する(Export)計画がある場合(ステップS109のExport)、その計画に基づき、平滑化制御部422が、自ノードのデータ格納部442からSuccessorノードのデータ格納部442にデータを移動させる(ステップS111)。
ステップS113またはステップS111でImportまたはExportを行った場合は、それに応じて、自ノードの値域が変更になるので、平滑化制御部422が、値域格納部424に格納された値域表428(図13)の自ノードの値域端点を変更する(ステップS115)。そして、Successorノードに、自ノードの値域端点の変更を通知して、Successorノードの値域格納部424のPredecessorノード(自ノードに相当)の値域端点を変更させる。さらに、この自ノードの値域端点の変更は、通知先格納部426の通知先表430(図14)に格納された通信アドレスのノードに対しても、更新された値域端点の情報を値域変更通知として送信する(ステップS117)。
図16は、図15のステップS107の負荷分散計画算出処理(S200)の手順の一例を示すフローチャートである。
まず、隣接ノードとのデータ量またはデータ数(図中、「データ量」と示す)に基づいて、移動すべきデータの変更量dNを求める(ステップS201)。ここでは、自ノードとSuccessorノードのデータ格納部442に格納されたデータ量またはデータ数をそれぞれNm、Nsとする。また、自ノードとSuccessorノードが担当する論理識別子IDの範囲の幅を|IDm−IDp|と|IDs−IDm|とする。このとき、好ましくは、Nm:Ns=|IDm−IDp|:|IDs−IDm|となるように、平滑化制御部422は、自ノードからSuccessorノードに移動すべき変更量dNを求める。
なお、|IDm−IDp|は、論理識別子ID空間2mを用いて、IDm−IDp mod 2mにより算出され、その答えは非負である。たとえば、2mが1024であり、IDmが10、IDpが1000の時には、|IDm−IDp|は34である。
好適には自ノードとSuccessorノードのデータ量またはデータ数自体を均一化させるのではなく、|IDm−IDp|と|IDs−IDm|との比に応じて配分されるように、変更量が決定されるとよい。何故なら、本実施形態の情報システム1には、ノードの追加がなされるスケールアウト(サーバ(ノード)の数を増やすことでシステム全体の性能を向上させること)が行われることを想定しているからである。このとき追加されるノードの論理識別子IDは、ID宛先表構築部410により、論理識別子ID空間において、確率的に均一にランダムに割当てられる。
そして、追加されるノードに割当てられた論理識別子IDのSuccessorとなるノードからデータの移動を受ける。そのため、論理識別子ID範囲の幅の大きなノードは、新たに追加されるノードにデータを移動できる確率が高くなる。そして、属性の値域を決定する際にも、論理識別子ID範囲の広さに応じて、論理識別子ID範囲の幅の大きなノードに広い値域を担当させれば、スケールアウトを想定したシステムでも、確率的に均一にデータの値域を決定することができることになる。
たとえば、平滑化制御部422は、下記の(式1)で変更量dNを算出してもよい。
この場合、変更量dNの絶対値が、予め与えられたある正の閾値以下である場合(ステップS203のYES)、平滑化制御部422は、計画種別を「変更なし」として負荷分散計画を返し(ステップS205)、図15のステップS109に戻る。
変更量dNの絶対値が、閾値より大きい場合(ステップS203のNO)、変更量dNの符号が正である場合(ステップS207の「正」)、計画種別を「Export」として、この計画種別と変更量dNを合わせて負荷分散計画を返し(ステップS209)、図15のステップS109に戻る。負である場合(ステップS207の「負」)、平滑化制御部422は、計画種別を「Import」として、この計画種別と変更量dNを合わせて負荷分散計画を返し(ステップS211)、図15のステップS109に戻る。
このようにして算出された負荷分散計画に基づいて、図15のステップS109以降の処理が行われる。
以上、図15および図16を用いて説明した負荷分散部420の動作により、本実施形態の情報システム1は、ノード(データ格納サーバ106)へのデータの追加または削除、あるいは、ノード(データ格納サーバ106)の増設や撤去などによって、ノードのデータ分布が変化した場合に、ノード間でデータを移動し、負荷を分散させて平滑化させることができる。さらに、このデータ移動に伴う値域の変更を他のノードに通知することができる。
次に、本実施形態の情報システム1において、ノードがデータのアクセス要求を受け付けた時の処理について説明する。
図17および図18は、本実施形態の情報システム1のデータアクセス要求受付処理S300の手順の一例を示すフローチャートである。以下、図4、図8、図13、図17、図18を用いて説明する。
このデータアクセス要求受付処理S300は、本実施形態の情報システム1のノード(図4のデータ格納サーバ106)のデータ管理部440のデータアクセス部444が行う。そして、本処理S300は、データアクセス部444が、データ操作クライアント104(図4)の操作要求部360から送信された、または操作要求中継サーバ108(図4)の中継部380から転送されたデータアクセス要求とともに、そのノードの値域端点を受け付けると開始する。なお、アクセス要求とともに送られるそのノードの値域端点とは、アクセス要求元のノードが管理している、そのノードの値域端点である。本処理S300では、アクセス要求元が管理している、そのノードの値域端点と自ノードが管理している値域端点が一致しているか否かを検証する。そのため、アクセス要求元から、そのノードの値域端点を受信する。
また、本処理S300では、データアクセス部444が値域格納部424の値域表428(図13)を参照しながら、その要求の妥当性を判定し、妥当である要求についてデータ格納部442に記憶されるデータに対する処理、たとえば、データの追加、削除、または検索などの処理を実行する。さらに、本処理S300では、アクセス要求を、中継部380を介して転送していく宛先を決定するのに必要な情報を作成して返す処理も行う。
まず、アクセス要求を受け付けたノードmのデータ管理部440のデータアクセス部444が、アクセス要求の種別を判別する(ステップS301)。アクセス要求の種別が属性値である場合には、データアクセス部444が、値域格納部424の値域表428を参照して自ノードmの値域(ap,am]を取得し、属性値aと、自ノードmの値域(ap,am]を比較する(ステップS303)。
属性値aの方が小さい場合(ステップS303のcase1)、データアクセス部444が、値域格納部424の値域表428を参照してPredecessorノードの論理識別子IDと値域端点を取得し、それらのPredecessorノードの情報を値域変更通知に含める。さらに、データアクセス部444は、値域格納部424の値域表428を参照してPredecessorノードの通信アドレスを取得し、そのPredecessorノードの通信アドレスをリダイレクト先(転送先)とする。
そして、データアクセス部444は、これらのPredecessorノードの情報を値域変更通知およびリダイレクト先として、アクセス要求を受け付けた操作要求部360または中継部380のノードに返し(ステップS305)、本処理を終了する。
属性値aの方が大きい場合(am∈(ap,a])(ステップS303のcase2)、データアクセス部444が、ステップS305と同様に自ノードmの論理識別子IDと値域端点、およびSuccessorノードの通信アドレスを取得し、自ノードmの情報を値域変更通知として、Successorノードの通信アドレスをリダイレクト先として、アクセス要求を受け付けた操作要求部360または中継部380のノードに返し(ステップS307)、本処理を終了する。属性値aが値域に含まれる場合(a∈(ap,am])(ステップS303のcase3)には、データアクセス部444が、データ格納部442に記憶されるデータに対する処理を実行し(ステップS309)、図18のステップS323に進む。
ここで、上述した属性値aと値域(ap,am]の比較を図19(a)〜図19(c)にまとめて概念図とともに示す。ここでいう、「小さい」とはその属性値そのものの値の小ささを表す比較演算ではない。属性値aが値域(ap,am]に含まれず、値域(ap,am]から見てリングの反時計回り側、すなわち、Predecessorノードに格納されている可能性が、リングの時計回り側、すなわち、Successorノード側に格納されている可能性より高い状態である。
たとえば、属性値aと自ノードmの値域端点amの差|a−am|が|ap−a|より大きい場合を表す。ここで用いた属性値間の差|a−am|も非負である。たとえば[−128,127]の値をとるsigned char型の数値−110と100の差は、((−110)−(100)) mod 256=46である。文字列属性の場合も、辞書順の最後と最初の連続性を持たせる任意の規則で同様の差分処理を実現できる。
図17に戻り、ステップS301において、種別が属性範囲である場合には、データアクセス部444は、属性範囲(af,at]とこのノードmの値域(ap,am]を比較する(ステップS311)。属性範囲(af,at]の方が値域(ap,am]より小さい場合(ステップS311のcase4)、データアクセス部444は、値域格納部424の値域表428を参照し、Predecessorノードの論理識別子IDと値域端点と通信アドレスを取得する。そして、データアクセス部444が、Predecessorノードの論理識別子IDと値域端点を値域変更通知として、Predecessorノードの通信アドレスをリダイレクト先としてアクセス要求を受け付けた操作要求部360または中継部380に返し(ステップS305)、本処理を終了する。
属性範囲(af,at]の方が値域(ap,am]より大きい場合(ステップS311のcase5)、データアクセス部444が、自ノードmの論理識別子ID、値域端点を値域変更通知として、Successorノードの通信アドレスをリダイレクト先としてアクセス要求を受け付けた操作要求部360または中継部380に返し(ステップS307)、本処理を終了する。
属性範囲(af,at]が値域(ap,am]に含まれる場合(ステップS311のcase6)、データアクセス部444が、データ格納部442に記憶されるデータに対する処理を実行し(ステップS309)、図18のステップS323に進む。
属性範囲(af,at]と、値域(ap,am]に共通部分があり、重なる場合((af,at]∩(ap,am]≠空集合)には(ステップS311のcase7)、図18のステップS313に進む。そして、データアクセス部444が、共通範囲((af,at]∩(ap,am])についてデータ格納部442に記憶されるデータに対する処理を実行する(ステップS313)。
ステップS313の後、共通範囲以外において、自ノードmの値域(ap,am]より小さい属性範囲(af,at]が存在する場合(ap∈(af,at])(ステップS315のYES)には、データアクセス部444が、Predecessorノードの論理識別子IDと値域端点を値域変更通知に、通信アドレスをリダイレクト先に加え(ステップS317)、ステップS319に進む。自ノードmの値域より小さい属性範囲が存在しない場合(ステップS315のNO)にも、次のステップS319に進む。
さらに、自ノードmの値域(ap,am]より大きい属性範囲(af,at]が存在する場合(am∈(af,at])(ステップS319のYES)には、データアクセス部444が、自ノードmの論理識別子IDと値域端点を値域変更通知に、Successorノードをリダイレクト先に加え(ステップS321)、次のステップS323に進む。自ノードmの値域より大きい属性範囲が存在しない場合(ステップS319のNO)にも、次のステップS323に進む。
そして、呼び出し元から通知された値域端点と、自ノードmの値域端点が一致していない場合(ステップS323のNO)、データアクセス部444が、自ノードmの値域端点を値域変更通知に加え(ステップS325)、ステップS327に進む。通知された値域端点と、自ノードmの値域端点が一致している場合(ステップS323のYES)、ステップS327に進む。データアクセス部444が、データアクセス実行結果とともに、値域変更通知とリダイレクト先を呼び出し元に返し(ステップS327)、本処理を終了する。
なお、ステップS309でデータアクセス処理が行われ、かつ、通知された値域端点とこのノードmの値域端点が一致している場合(ステップS323のYES)は、データアクセス部444は、ステップS327で値域変更通知とリダイレクト先は返信しない。また、データアクセス実行結果は、たとえば、データアクセスの正否や、データ検索の場合、検索結果を含む。
ここで、上述した属性範囲(af,at]と値域(ap,am]の比較を、図19(d)〜図19(i)にまとめて概念図とともに示す。
以上、図17および図18を用いて説明したデータアクセス部444の動作により、本実施形態の情報システム1は、ノード(データ操作クライアント104)が受け付けて転送してきたアプリケーションプログラムなどからのデータアクセス要求に基づいて、要求されたデータにノード(データ格納サーバ106)がアクセスできる。さらに、データアクセス要求の妥当性も判断し、その結果を通知することができる。
次に、本実施形態の情報システム1において、ノードが値域を更新する処理について説明する。
この値域更新処理は、データ操作クライアント104(図4)の宛先表管理部400の値域更新部406(図7)が行う。値域更新処理には、データ操作クライアント104の操作要求部360(図7)や操作要求中継サーバ108(図4)の中継部380(図7)、またはデータ格納サーバ106(図4)の負荷分散部420(図8)からの値域変更通知の受信を契機として実行される処理と、他の構成要素によらずに値域更新部406により自律的に実行される処理がある。
前者の他の構成要素からの値域変更通知の受信を契機として実行される処理では、値域変更通知に含まれる論理識別子IDと、属性ならびに値域端点の情報に基づいて、属性宛先表414(図12)に対する更新処理を行う。
これら実行契機が違う処理における役割の違いを説明する。
たとえば、データ格納サーバ106の負荷分散部420からの値域変更通知は、データ格納サーバ106のデータ管理部440における実際の値域変更を契機とするため、データ操作クライアント104、あるいは操作要求中継サーバ108の属性宛先表414(図12)の情報の鮮度を高めることができるので有効である。
しかしながら、データ格納サーバ106または操作要求中継サーバ108等の複数の他のノードの属性宛先表格納部404の属性宛先表414を同期的に更新し、その間の属性宛先表格納部404の属性宛先表414を操作要求部360や中継部380が宛先解決部340を介して参照されないようにすると、データ操作クライアントからのデータアクセス要求の応答時間やスループットが劣化する可能性がある。
したがって、各ノードの属性宛先表414は非同期に更新し、操作要求部360や中継部380が異なるノードあるいはプロセス上で非同期に動作することが望ましい。しかし、その際、宛先解決部340により宛先解決された直後に値域が更新されることが起こり得る。そのため、操作要求部360や中継部380が、他のノードの中継部380やデータ管理部440にアクセスした際に、妥当な宛先解決結果でなくなった旨を受け取る必要がある。そして、さらに、操作要求部360や中継部380が、その結果を受付けて、適切な宛先にリダイレクトされる必要がある。
ただし、操作要求部360や中継部380からの値域変更通知は、アプリケーションプログラムからの要求実行中に処理されるものであり、その処理中に更新を行うことは、アプリケーションプログラムへの応答時間あるいはスループットの劣化原因となる。そのため、前述の負荷分散部420からの値域変更指示、あるいは、値域更新部406自体が値域更新を実行し、属性宛先表414の情報の鮮度を高める処理があることが、好適には望ましい。
図20は、本実施形態の情報システム1の値域更新処理S400の手順の一例を示すフローチャートである。以下、図4、図7、図12、および図20を用いて説明する。
この値域更新処理S400は、本実施形態の情報システム1のノード(図4のデータ操作クライアント104)の宛先表管理部400の値域更新部406(図7)が行う。本処理S400において、値域更新部406自体が自律的に属性宛先表414(図12)の値域更新を行うことで、属性宛先表414の情報の鮮度を高めることができる。
本処理S400は、本実施形態の情報システム1の起動時、または定期的に、自動的に実行され、あるいは、情報システム1の利用者の手動操作により、またはアプリケーションプログラムからの要求に応じて実行される。
あるノードm(データ操作クライアント104)は、宛先表管理部400の属性宛先表格納部404(図7)に格納されている属性宛先表414から任意のノードn(データ格納サーバ106)を取り出す(ステップS401)。そして、自ノードmが管理している全属性の属性宛先表414のノードnの値域端点をそのノードnに送信する(ステップS403)。送信先ノードnでは、受信した各属性の値域端点について、その送信先ノードnが実際に格納している属性の値域端点と比較し、差異のある値域端点についてその情報をノードmに返す(ステップS405)。ノードmでは、返信されたノードnの属性の値域端点に基づき、自ノードmの属性宛先表414におけるノードnの値域の更新を行う(ステップS407)。
以上の自律的値域更新処理S400により、データ格納サーバ106のノード側で値域を変更した場合に、たとえ非同期にデータ操作クライアント104のノード側に値域変更を伝えても、両者間(データ操作クライアント104とデータ格納サーバ106の間)または各ノード間(データ操作クライアント104同士、またはデータ格納サーバ106同士)のデータの一貫性を保つことができる。定期的にこの処理S400を行うことで、各データ操作クライアント104のノードは、属性宛先表414の情報の鮮度を高めることができる。
以上、図20を用いて説明した値域更新部406の動作により、本実施形態の情報システム1は、ノード(データ格納サーバ106)に対して値域確認を行い、返信された結果に基づいて属性宛先表414の情報を更新できる。すなわち、本実施形態では、上述したようにデータ格納サーバ106が自律的にデータを移動し、各ノードが担当する値域が変更され、データ操作クライアント104に非同期に通知されたとしても、データ操作クライアント104とデータ格納サーバ106の間で整合がとれることとなる。
次に、本実施形態の情報システム1のデータ操作クライアント104において、アプリケーションプログラムからのデータアクセス要求に基づいて、データの追加または削除、あるいは、データの検索を行う処理について説明する。
まず、本実施形態の情報システム1におけるデータ追加削除処理について説明する。図21は、本実施形態の情報システム1におけるデータ追加削除処理S410の手順の一例を示すフローチャートである。このデータ追加削除処理S410は、データ操作クライアント104(図4)の操作要求部360のデータ追加削除部362(図7)が行う。以下、図4、図7、図9、図12、および図21を用いて説明する。
なお、ここでは図9に示した再帰の2相(図9(b)、図9(d)等)、あるいは反復(図9(e)等)の方式のように、属性値からノード(図4のデータ格納サーバ106)を特定する処理と、そのノード(データ格納サーバ106)に対してデータアクセスを行う処理とが分かれている形態についてのみ説明する。また、以下の説明では、データ追加または削除の処理を行うデータが属性値で指定された場合について説明するが、属性範囲を指定することもできる。属性範囲が指定された場合、後述するデータ検索処理と同様な処理が行われる。ただし、ステップS437がデータ検索処理ではなく、データ追加または削除処理となる。
本処理S410は、アプリケーションプログラムから受信した、または他のデータ操作クライアント104または操作要求中継サーバ108のノードから転送された、データ追加または削除のアクセス要求を、ノードm(データ操作クライアント104)が受け付けた時に開始する。
まず、ノードm(データ操作クライアント104)の操作要求部360のデータ追加削除部362(図7)が、アクセス要求で指定された追加あるいは削除されるデータの属性値を取得する(ステップS411)。そして、データ追加削除部362は、宛先解決部340の単一宛先解決部342(図7)に取得した属性値を通知し、単一宛先解決部342から、その属性値に対応するノードnの通信アドレスを取得する(ステップS413)。
このとき、単一宛先解決部342は、データ追加削除部362から通知された属性値について、宛先表管理部400の属性宛先表格納部404に格納されている属性宛先表414(図12)を参照して、その属性値に対応するノードnの通信アドレスを取得し、データ追加削除部362に返信する。この単一宛先解決部342の宛先解決処理については後述する。
そして、データ追加削除部362が、取得したノードnに対してデータの追加または削除といったデータアクセスを行う(ステップS415)。その際に、データ追加削除部362は、自ノードmのその属性の値域端点をノードnに通知する。
このとき、ノードnでは、図17および図18を用いて説明したデータアクセス要求処理S300が実行されることとなる。このデータアクセス要求処理S300の結果、ノードnからノードmに、データアクセス実行結果、値域変更通知、またはリダイレクト先が返信される。そして、ノードmのデータ追加削除部362が、データの追加または削除の処理を行った実行結果をノードnから受信する。
その実行結果に、値域変更通知が含まれる場合(ステップS417のYES)、データ追加削除部362は、値域変更通知に含まれるノードの論理識別子IDと値域端点の情報を取得する。そして、データ追加削除部362は、自ノードmの宛先表管理部400の値域更新部406(図7)に対して、これらの情報を通知し、当該属性の属性宛先表414(図12)を更新するよう指示し(ステップS419)、ステップS421に進む。
実行結果に値域変更通知が含まれない場合(ステップS417のNO)、ステップS421に進む。さらに、実行結果にリダイレクト先が含まれる場合(ステップS421のYES)、ノードnに対するデータアクセスに失敗したことになる。したがって、リダイレクト先を次のアクセス先のノードnとして(ステップS423)、ステップS415に戻り、データ追加削除部362がそのノードnに対してデータアクセス処理を実行する。
一方、実行結果にリダイレクト先が含まれない場合(ステップS421のNO)、本処理を終了する。なお、ステップS413の属性宛先表414を参照して通信アドレスを取得する方式は、後述するように、宛先解決部340のアルゴリズムにより異なる。
次に、本実施形態の情報システム1におけるデータ検索処理について説明する。図22は、本実施形態の情報システム1におけるデータ検索処理S430の手順の一例を示すフローチャートである。このデータ検索処理S430は、データ操作クライアント104(図4)の操作要求部360のデータ検索部364(図7)が行う。以下、図4、図7、図9、図12、および図22を用いて説明する。
ここでも、図9に示した再帰の2相(図9(b)、図9(d)等)、あるいは反復(図9(e)等)の方式のように、属性範囲から複数のノード(図4のデータ格納サーバ106)を特定する処理と、それらノード(データ格納サーバ106)に対してデータアクセスを行う処理とが分かれている形態についてのみ説明する。
また、以下の説明では、検索式で属性範囲が指定された場合について説明しているが、属性値を指定することもできる。属性値が指定された場合は、図21で説明したデータ追加削除処理と同様な処理が行われる。ただし、ステップS415がデータ追加削除処理ではなく、データ検索処理となる。
本処理S430は、アプリケーションプログラムから受信した、または他のデータ操作クライアント104または操作要求中継サーバ108のノードから転送された、データ検索のアクセス要求をノードm(データ操作クライアント104)が受け付けた時に開始する。
まず、ノードm(データ操作クライアント104)の操作要求部360のデータ検索部364が、アクセス要求で指定された検索されるデータの属性範囲arを取得する(ステップS431)。そして、データ検索部364は、宛先解決部340の範囲宛先解決部344(図7)に取得した属性範囲arを通知し、範囲宛先解決部344から、その属性範囲arの部分集合である属性範囲asと対応するノードnの対を複数取得する(ステップS433)。
このとき、範囲宛先解決部344は、データ検索部364から通知された属性範囲arについて、宛先表管理部400の属性宛先表格納部404に格納されている属性宛先表414(図12)を参照して、その属性範囲arの部分集合である属性範囲asと対応するノードnの対を複数取得し、データ検索部364に返信する。この範囲宛先解決部344の宛先解決処理については後述する。
そして、得られた複数の結果の各ノードnおよび属性範囲asについて、データ検索部364がステップS435〜ステップS447の間のループ処理を行う。すべてのノードnについて処理が終了したら本ループ処理を終了し、本処理S430も終了する。
ループ処理が開始すると、まず、ノードnに対し、そのノードnの属性範囲asのデータ検索を実行する(ステップS437)。その際に、データ検索部364は、自ノードmのその属性の値域端点をノードnに通知する。
このとき、ノードnでは、図17および図18を用いて説明したデータアクセス要求処理S300が実行されることとなる。このデータアクセス要求処理S300の結果、ノードnからノードmに、データアクセス実行結果、値域変更通知、またはリダイレクト先が返信される。ここでは、データアクセス実行結果として、検索されたデータが返信される。そして、ノードmのデータ検索部364が、データ検索処理を行った実行結果をノードnから受信する。
その実行結果に値域変更通知が存在する場合(ステップS439のYES)、データ検索部364は、値域変更通知に含まれるノードの論理識別子IDと値域端点の情報を取得する。そして、データ検索部364は、そのノードmの宛先表管理部400の値域更新部406(図7)に対して当該属性の属性宛先表414(図12)を更新するよう指示し(ステップS441)、ステップS443に進む。
実行結果に値域変更通知が存在しない場合(ステップS439のNO)、ステップS443に進む。さらに、実行結果にリダイレクト先が含まれる場合(ステップS443のYES)、ノードnに対するデータアクセスに失敗したことになる。したがって、リダイレクト先を次のノードnとして(ステップS445)、ステップS437に戻り、属性範囲asのデータアクセスを実行する。一方、実行結果にリダイレクト先が含まれない場合(ステップS443のNO)、本処理を終了する。なお、ステップS433の属性宛先表414を参照して通信アドレスを取得する方式は、後述するように、宛先解決部340のアルゴリズムにより異なる。
以上、図21および図22を用いて説明した操作要求部360の動作により、本実施形態の情報システム1は、アプリケーションプログラムからのデータへのアクセス要求に応じた処理を行うことができる。
次に、本実施形態の情報システム1において、データ格納先のノードの宛先を探索する宛先解決処理について説明する。本宛先解決処理は、データ操作クライアント104(図4)の宛先解決部340(図7)が行う。また、本実施形態では、宛先解決部340のアルゴリズムはフルメッシュである。
宛先解決処理は、単一宛先解決部342(図7)が行う単一宛先解決処理と、範囲宛先解決処理とを含む。単一宛先解決処理は、属性値に対するデータを格納する単一のノードの宛先を探索する処理である。範囲宛先解決処理は、範囲宛先解決部344(図7)が行う属性範囲に対するデータを格納する複数のノードの宛先を探索する処理である。
なお、これらの宛先解決処理は、上述したデータ追加削除処理またはデータ検索処理を実行しているノードm(データ操作クライアント104)の操作要求部360から宛先解決処理要求として属性値または属性範囲を受信した時、または、中継部380を介して、他のノードの宛先解決部340から宛先解決処理要求が転送された時などに開始する。
まず、宛先解決部340の単一宛先解決部342が行う単一宛先解決処理について説明する。図23は、本実施形態の情報システム1における単一宛先解決処理S450の手順の一例を示すフローチャートである。以下、図4、図7、図12、および図23を用いて説明する。
まず、ノードm(データ操作クライアント104)の宛先解決部340の単一宛先解決部342が、宛先表管理部400の属性宛先表格納部404に格納されている属性宛先表414(図12)を参照し、呼び出し元から指定された属性値aのSuccessorとなるノードの通信アドレスを取得し、呼び出し元に返す(ステップS451)。
次に、宛先解決部340の範囲宛先解決部344が行う範囲宛先解決処理について説明する。
本範囲宛先解決処理では、ノードm(データ操作クライアント104)の宛先解決部340の範囲宛先解決部344が、宛先表管理部400の属性宛先表格納部404に格納されている属性宛先表414(図12)を参照し、指定された属性範囲(af,at]を属性宛先表414に登録された値域端点で分割し、属性範囲と分割に用いたノードの対を複数得る。
この範囲宛先解決処理の具体例について以下説明する。図24は、本実施形態の情報システム1における範囲宛先解決処理S460の手順の一例を示すフローチャートである。以下、図4、図7、図12、および図24を用いて説明する。
まず、ノードm(データ格納サーバ106)の宛先解決部340の範囲宛先解決部344が、属性範囲(af,at]の起点afのSuccessorノードとなる値域端点aを、属性宛先表格納部404に格納されている属性宛先表414から取得し(ステップS461)、属性範囲の起点afを属性値a0として保持する(ステップS463)。そして、範囲宛先解決部344が、属性値aと属性範囲の終点atを比較し、属性値aが属性範囲の終点atより小さい場合(ステップS465のNO)、属性範囲(a0,a]と、その値域端点aのノードnとの対を結果として残す(ステップS467)。そして、範囲宛先解決部344は、属性宛先表414から次の値域端点aを取得し、前の値域端点をa0として保持する(ステップS469)。そして、ステップS465に戻り、次の属性値aと属性範囲の終点atを比較する。
属性値aが属性範囲の終点atより大きい場合(ステップS465のYES)、範囲宛先解決部344は、属性範囲(a0,at]と値域端点aのノードnとの対を結果として残し(ステップS471)、得られた複数の対を結果として呼び出し元に返す(ステップS472)。
以上、図23および図24を用いて説明した宛先解決部340の動作により、本実施形態の情報システム1は、データアクセス要求されたデータの属性値からアクセス要求の宛先のノードを特定できる。
以上説明したように、本発明によれば、ノードのデータ分布が変化しても性能および信頼性を維持する情報システム、データ管理方法、データ処理方法、データ構造、およびプログラムが提供される。
本発明の実施の形態に係る情報システム1は、特に範囲検索などを実現するために、データ格納先のノードに確率的に均一な論理識別子IDが割り振られ、その論理識別子IDと格納先のノードの宛先アドレスの他に、属性毎の値域と格納先のノードの論理識別子IDとの宛先表を管理する。そして、格納先のノードが論理識別子IDの隣接性に基づいて負荷分散のために値域を変更する。その変更によって属性毎の宛先表が更新される。そして、データアクセス要求に応じて、その宛先表を参照し、そのデータアクセスの処理に必要な格納先のノードの宛先アドレスを決定する。
これにより、本発明の実施の形態に係る情報システム1によれば、ノード間の通信到達性を維持するための死活監視(ヘルスチェック)に伴い生じる負荷や、ノード間の頻繁な接続性の変更に伴うシステム障害の可能性が低減するという効果を奏する。
その理由は、本実施形態の情報システム1では、各ノード(データ操作クライアント104または操作要求中継サーバ108)がそれぞれ宛先表にて管理しているノード(データ格納サーバ106)が、ノード(データ格納サーバ106)に登録されるデータの分布変化に伴って変化しないからである。
これは、本発明の情報システム1では、ノード間の論理識別子IDの関係で構築した送受信関係を表す宛先表(ID宛先表412)とは別に属性毎に宛先表(属性宛先表414)を構築したことにある。そして、本実施形態の情報システム1は、この宛先表(属性宛先表414)を変更することによって、分布の変化に柔軟に対応することができるため、送受信関係を構築する宛先表(ID宛先表412)に対する変更は必要としないことにある。
システムを構成するコンピュータ、ディスク、メモリ等の格納先を増やすことで負荷増加に対応する技術として、特定のコンピュータが木構造を管理するなどの集中型の要素を持たず、データの格納先のアドレス(ID)をハッシュ値によって決定し、それを参照して、データのハッシュ値から格納先を決定する方式(Consistent Hashing)がある。しかし、このような方式は、データの順序性や連続性が必要となる範囲検索などには適さない。属性値を格納先の論理識別子IDとして用いることで、格納先を決定できるが、格納先の負荷がその属性の分布に依存し、格納先の論理識別子IDを適応させると、複数の属性を扱う際に、ある属性の分布の変化が他の属性の負荷に影響を与える。また、データの属性値の値域によりコンピュータを決定する方式では、その負荷の均一性が課題となる。属性の分布情報を用いて、属性値が格納先の確率的な均一性に適合するよう、IDを決定する方式では、分布が変化する場合に問題となる。
上述したように、構造化P2Pは、範囲検索を可能にするためのアプローチとして、以下の2つのアプローチが考えられる。
第1のアプローチは、システムが、ノードに格納されるデータの属性の値域に応じて、他のどのノードを自ノードが管理する宛先表に格納するかを決定し(送受信関係を構築し)、データへのアクセス要求の宛先を決定する際に、要求されたデータの属性値と宛先表とを参照し、決定した宛先に、そのデータへのアクセス要求を転送する。
第2のアプローチは、システムが、ノードのIDに応じて、他のどのノードを自ノードが管理する宛先表に格納するか決定し(送受信関係を構築し)、データの属性値をID空間に変換した値と宛先表とを参照して、そのデータへのアクセス要求の宛先を決定する。
上記第1のアプローチでは、各ノードでの宛先表の更新(ノード間の送受信関係の変更)と、それに伴う通信到達性維持のための処理や、通信路変更時に必要となる処理の一時的な停止が必要となる可能性、さらには通信路の障害として扱われる可能性が高まるといった問題点があった。
その理由は、以下の通りである。複数のノードへのデータ登録に伴い、データの分布は変化する。そして、そのデータの分布の変化に応じて、ノード間でデータがほぼ均一のデータ量を持つように値域を変更すると、その変更に応じて、他のどのノードと接続するかを格納した宛先表も変更する必要が発生するからである。
本発明によれば、各ノードの宛先表に格納されるノードが、登録されるデータの分布変化によって変化せず、それによりノード間の通信到達性の維持が減り、ノード間の頻繁な接続性の変更に伴うシステム障害の可能性を減らすことができる。
さらに、上記第1のアプローチでは、各ノードでの宛先表が確率的な均一性を持たなくなり、その均一性を前提としたデータアクセス要求の転送処理の効率性が低下し、ホップ数の増加、すなわち応答時間の低下や、転送負荷の偏りとなって、システムに影響を与えるといった問題点があった。
その理由は、以下の通りである。複数のノードへのデータ登録に伴い、データの分布は変化する。そして、そのデータの分布の変化に応じて、ノード間でデータがほぼ均一のデータ量を持つように値域を変更すると、宛先表に格納される論理識別子の確率的な分布がその属性の分布に応じて、偏るからである。
さらに、上記第2のアプローチでは、その対応づけの際に用いる分布情報の更新と、それに応じたデータの再配置が必要になるといった問題点があった。
その理由は、以下の通りである。ノードのIDに応じて構築される宛先表は、データがID空間に均一に割当てられることを想定して静的に保持される。そして、データのIDの方を、データが均一に分布するように、分布情報を用いて算出する。したがって、データの分布が変化すると、算出されるデータのIDも更新される必要がある。そして、データを格納する時点におけるIDと取得する時点でのIDが異なると、データが取得できなくなることがある。これを避けるため、新たなIDにデータを再配置する必要があるためである。
本発明によれば、属性値を、確率的な均一性を有したノードのIDや宛先表に格納されるIDと整合させるために分布情報を要することなく、分布が変化しても、属性値とIDの対応付けの変化に伴う、再配置といった問題を回避することができる。
その理由は、以下の通りである。本発明の情報システムは、分布情報を用いて属性値をIDに変換させ、これとノード間のIDの関係で構築した送受信関係を表す宛先表とから、宛先を決定するのではなく、宛先表におけるノード間の送受信関係に沿って、属性毎の宛先表を生成し、これと属性値とを比較して宛先を決定する。そのため、分布に相当する情報は、その送受信関係に沿って、適切に更新され、属性毎の宛先表が更新されるからである。
(第2の実施の形態)
本発明の実施の形態に係る情報システムは、上記実施形態の情報システム1とは、宛先解決処理にDHTのChordアルゴリズムを用いる点で相違する。なお、上記実施形態で図面を用いた各構成要素が行う処理の手順が、本実施形態と上記実施形態とは異なるが、構成については同じであるので上記実施形態と同じ図面と同じ符号を用いて以下説明する。
本実施形態は、宛先解決部340、値域更新部406の処理手順が上記実施形態とは異なり、また、ID宛先表格納部402に格納されるID宛先表412と属性宛先表格納部404に格納される属性宛先表414が上記実施形態とは異なる。本実施形態では、ID宛先表格納部402にはID宛先表452(図57)が格納され、属性宛先表格納部404には属性宛先表454(図45〜図47)が格納されるものとする。それ以外は上記実施形態と同様とすることができる。
本発明の実施の形態に係る情報システム1は、ID宛先表格納部402に記憶されるID宛先表452を生成するID宛先表構築部410およびID検索部408が、Chordアルゴリズムに基づいてノード間の送受信関係を構築する。そして、上記実施形態のような、データのハッシュ値の属性値を用いた完全一致検索ではなく、本実施形態では、データの属性値を用いた範囲検索を可能とする。
本実施形態のような、Chordアルゴリズムに基づいた送受信関係を用いると以下のような利点がある。
第1に、フルメッシュのアルゴリズムの場合に比較して、各ノードが保持する他ノードの通信アドレス数が少なくなるためにスケーラビリティに優れる。第2に、各ノードからある他ノードへの通信経路が複数経路となり、かつ、アルゴリズムにより自動的に経路が選択されるために、経路障害に強い。
さらに、本実施形態においては、データ分布の変化により更新する必要のある属性宛先表454の更新負荷や更新不足に伴う性能問題や一貫性問題が少なくなるという本実施形態に特有な利点がある。すなわち、上記実施形態のフルメッシュのアルゴリズムにおいては、あるノードが保持するデータの値域が変更された場合に、他の全てのノードにおいて、そのノード値域端点を属性宛先表414で反映させる必要がある。しかし、本実施形態のChordアルゴリズムにおいては、Chordアルゴリズムが生成するノード間の送受信関係上であれば、更新されるべき属性宛先表454に記憶される値域端点が少なくなる。そのため、本実施形態では、上記実施形態に比べ、更新負荷や、更新不足に伴う性能の問題や一貫性の問題が低減される。
このように、本実施形態の情報システム1によれば、ChordなどDHTに基づく送受信関係の構築により、その上で形成する属性宛先表の更新に伴う問題が軽減される。
本実施形態の情報システム1において、各ノード(データ格納サーバ106または操作要求中継サーバ108のID宛先表構築部410)は、論理識別子空間において、自ノードと他ノードとの論理識別子IDの差を、論理識別子空間のサイズで除した余りとして、自ノードと他ノードとの距離を求め、距離が最小であるノードを隣接ノード(Successorノード)とし、および、距離が2のべき乗ずつ離れた識別子以上の中で自ノードに最も近い他ノードを、自ノードのリンク先(Fingerノード)として選択する。
そして、各ノードは、自ノードで少なくとも選択されたリンク先(Fingerノード)と隣接ノード(Successorノード)を宛先ノードとして、宛先ノードと、宛先ノードの論理識別子IDとの第1の対応関係(ID宛先表452)と、宛先ノードの論理識別子IDと、そのノードが管理しているデータの属性毎の値域と、の第2の対応関係(属性宛先表454)と、を対応関係として保持する。
上述したように、本実施形態の情報システム1では、宛先解決部のアルゴリズムがDHTのようにノード間転送を行うものであり、自ノードが管理していないデータに対するアクセス要求を受け付けたデータ格納サーバ106が、操作要求中継サーバ108として機能する。
以下、本実施形態の情報システム1の動作について、説明する。
まず、本実施形態の情報システム1における単一宛先解決処理について説明する。図25および図26は、本実施形態の情報システム1における単一宛先解決処理S500の手順の一例を示すフローチャートである。この単一宛先解決処理S500は、データ操作クライアント104(図4)の宛先解決部340の単一宛先解決部342(図7)が行う。以下、図4、図7、図25および図26を用いて説明する。
本単一宛先解決処理S500は、自ノードm(データ操作クライアント104)のデータ追加削除部362(図7)またはデータ検索部364(図7)から実行される場合と、中継部380(図4の操作要求中継サーバ108)を介して、他ノード(データ操作クライアント104)の単一宛先解決部342から実行される場合とがある。
はじめに、この単一宛先解決処理S500が、自ノードmの操作要求部360のデータ追加削除部362から呼び出された場合について説明する。
この時、データ追加削除部362は、属性値aに対応する通信アドレスを取得するための宛先解決要求とともに、呼び出し元の値域端点acと呼び出し元が認識する呼び出し先の値域端点aeを単一宛先解決部342に通知する。
あるノードm(データ操作クライアント104)の単一宛先解決部342が、通知された呼び出し先の値域端点aeと、自ノードmの値域端点amが等しいか否か判定する(ステップS501)。ここでは、あるノードmにおいて、自ノードmのデータ追加削除部362から本処理S500が呼び出されているので、呼び出し元と呼び出し先は同一ノードであるため値域端点acとaeとamは等しくなり(ステップS501のYES)、ステップS503に進む。
次いで、単一宛先解決部342は、その属性値aが自ノードmの値域端点amとSuccessorノードの値域端点asとの間(am,as]に含まれるか否か判定する(ステップS503)。
属性値aが含まれる場合(ステップS503のYES)、単一宛先解決部342は、そのSuccessorノードの通信アドレスを呼び出し元に返し(ステップS505)、本処理を終了する。
一方、属性値aが含まれない場合(ステップS503のNO)、図26のステップS507に進み、ステップS507からステップS521の間のループ処理を行う。
ここで、図57に示すように、Chordアルゴリズムにおいては、論理識別子ID空間において、ID宛先表452に、自ノードmより大きい論理識別子IDを有するSuccessorノードの通信アドレスがSuccessorListとして含まれる。さらに、ID宛先表452には、自ノードmより2のべき乗の距離離れたノードの通信アドレスがFingerノードとして複数含まれる。そして、属性宛先表454も、ID宛先表452に含まれるSuccessorノードおよび複数のFingerノードの情報を含む。
宛先表管理部400の属性宛先表格納部404に格納されている属性宛先表454におけるFingerエントリiの値域端点aiを自ノードmの値域端点amから遠い順で(Finger表のサイズから1まで変化させ)、iが1になるまで各々について処理を繰り返す。まず、そのノードiの値域端点aiが、自ノードmの値域端点amと属性値aの間(am,a)に含まれるか否かを判定する(ステップS509)。
そのノードの値域端点amと属性値aの間(am,a)に含まれるFingerエントリiが見つかった場合(ステップS509のYES)、ステップS511に進む。見つかるまでステップS509を繰り返し、iが1になったら終了する。
見つかったFingerエントリiのノードに対して、中継部380を介して図23で説明した単一宛先解決処理S450を実行し、そこで属性値aに対応するノードの通信アドレスを取得する(ステップS511)。なお、この時、範囲宛先解決部344は、Fingerエントリiのノードに、自ノードmの値域端点amと自ノードmの属性宛先表454に格納されているFingerエントリiのノードの値域端点aiを、中継部380を介して通知する。
ステップS511で得られた結果に、値域変更通知が含まれる場合(ステップS513のYES)、Fingerエントリiのノードの値域更新部406がその通知に含まれるノードの情報に基づいて属性宛先表格納部404に格納されている属性宛先表454を更新し(ステップS515)、ステップS517に進む。値域変更通知が含まれない場合(ステップS513のNO)、ステップS517に進む。
ここで、ステップS511で得られた結果にリダイレクト先が含まれる場合、ノードiに対するデータアクセスに失敗したことになる。失敗でなければ(ステップS517のNO)、Fingerエントリiのノードは、取得した通信アドレスを呼び出し元、すなわち、自ノードmに中継部380を介して返し(ステップS519)、本処理を終了する。失敗であれば(ステップS517のYES)、ステップS509に戻り、次のFingerエントリiについて、ループ処理の続きを行う。
一方、単一宛先解決処理S500が、自ノードmとは異なる他のノードの中継部380を介して呼び出された場合について説明する。
あるノードm(データ操作クライアント104)の単一宛先解決部342が、通知された呼び出し先の値域端点aeと、自ノードの値域端点amが等しいか否か判定する(ステップS501)。
ここでは、自ノードmとは異なる他のノードの中継部380から本処理S500が呼び出されているので、呼び出し元のノードの宛先表管理部400の属性宛先表格納部404に格納された属性宛先表454に含まれるFingerエントリiの値域端点aiと、呼び出された先の自ノードmの値域端点amが異なる場合がある。したがってこの場合には呼び出し先の値域端点aeと、自ノードmの値域端点amは等しくないので(ステップS501のNO)、単一宛先解決部342は、値域端点amを値域変更通知として呼び出し元に返す情報に含める(ステップS531)。
次に、自ノードmの値域端点amが、値域(ac,a)に含まれる場合(ステップS533のYES)、ステップS503に処理を進める。値域端点amが含まれない場合(ステップS533のNO)、失敗を呼び出し元に返し(ステップS535)、本処理を終了する。
次に、本実施形態の情報システム1における範囲宛先解決処理について説明する。図27および図28は、本実施形態の情報システム1における範囲宛先解決処理S550の手順の一例を示すフローチャートである。この範囲宛先解決処理は、データ操作クライアント104(図4)の宛先解決部340の範囲宛先解決部344が行う。以下、図4、図7、図27および図28を用いて説明する。
本範囲宛先解決処理S550は、自ノードm(データ操作クライアント104)のデータ追加削除部362(図7)またはデータ検索部364(図7)から実行される場合と、中継部380(図4の操作要求中継サーバ108)を介して、他ノード(データ操作クライアント104)の範囲宛先解決部344から実行される場合とがある。
はじめに、この範囲宛先解決処理S550が、自ノードmのデータ検索部364(図7)から呼び出された場合について説明する。
この時、データ検索部364は、属性範囲(af,at)に対応する通信アドレスを複数取得するための宛先解決要求とともに、呼び出し元の値域端点acと呼び出し元が認識する呼び出し先の値域端点aeを範囲宛先解決部344に通知する。
あるノードm(データ操作クライアント104)の範囲宛先解決部344が、通知された呼び出し先の値域端点aeと、自ノードmの値域端点amが等しいか否か判定する(ステップS551)。ここでは、あるノードmにおいて、自ノードmのデータ検索部364から呼び出されているので、呼び出し元と呼び出し先は同一ノードであるため値域端点ac、ae、amは等しくなり(ステップS551のYES)、ステップS553に進む。
次いで、範囲宛先解決部344は、その属性範囲arを、属性範囲(af,at]とする(ステップS553)。そして、範囲宛先解決部344は、その属性範囲arを、自ノードmの値域端点amとSuccessorノードの値域端点asとの間(am,as]に含まれる範囲内属性範囲aiと、範囲外属性範囲aoに分割する(ステップS555)。そして、範囲宛先解決部344は、範囲内属性範囲aiが存在すれば、Successorノード(通信アドレス、値域端点)を結果リストに含めて保持する(ステップS557)。
次いで、範囲宛先解決部344は、未決定範囲集合anを、範囲外属性範囲aoとする(ステップS559)。次いで、図28に進み、ステップS561〜ステップS571の間のループ処理を行う。なお、本実施形態では、属性範囲は、2つの範囲を含む場合もあり、「属性範囲」または「属性範囲集合」と呼ぶものとする。
宛先表管理部400の属性宛先表格納部404に格納されている属性宛先表454におけるFingerエントリiを自ノードmの値域端点amから遠い順で(Finger表のサイズから1まで変化させ)iが1になるまで各々について処理を繰り返す。
まず、範囲宛先解決部344は、未決定範囲集合anを、自ノードmの値域端点amとFingerエントリiのafiの間(am,afi]に含まれるFinger範囲内属性範囲afi2と、含まれないFinger範囲外属性範囲afo2に分ける(ステップS563)。そして、範囲宛先解決部344は、未決定範囲集合anを、Finger範囲内属性範囲afi2とする(ステップS565)。そして、Finger範囲外属性範囲afo2が空でなければ(ステップS567のNO)、範囲宛先解決部344は、後述する図29のFingerエントリ宛先解決処理S580を行う(ステップS580)。Finger範囲外属性範囲afo2が空の場合(ステップS567のYES)、ステップS571に進む。Finger表内のすべてのFingerエントリについて処理が終了したら本ループ処理を終了する(ステップS571)。そして、範囲宛先解決部344は、値域変更通知、失敗範囲、および結果リストを読み出し元に返す(ステップS573)。
一方、範囲宛先解決処理S550が、自ノードmとは異なる他のノードの中継部380を介して呼び出された場合について説明する。
ここでは、自ノードmとは異なる他のノードの中継部380から本処理S550が呼び出されているので、呼び出し元のノードの宛先表管理部400の属性宛先表格納部404に格納された属性宛先表454に含まれるFingerエントリiの値域端点aiと、呼び出された先の自ノードmの値域端点amが異なる場合がある。
ここで、呼び出されたノードにおける値に「’」を付して記述すると、呼び出し元の値域端点ac’=am、呼び出し元が認識する呼び出し先の値域端点ae’=afiとなる。
そして、範囲宛先解決部344が、自ノードmの値域端点am’と通知された呼び出し先の値域端点ae’とを比較する(ステップS551)。値域端点am’と値域端点ae’とが異なる場合(ステップS551のNO)、範囲宛先解決部344は、自ノードmの値域端点am’を値域変更通知に格納する(ステップS575)。
そして、範囲宛先解決部344は、属性範囲(af’,at’]を、値域(ac’,am’]に含まれない範囲ar’と含まれる範囲ari’に分ける(ステップS577)。そして、範囲宛先解決部344は、含まれる範囲ari’を失敗範囲とする(ステップS579)。以降、ステップS555に進み、上述した手順を同様に進める。
その結果、値域変更通知と、失敗範囲、結果リストが範囲宛先解決部344から呼び出し元に返され(ステップS573)、本処理を終了する。
次に、図29を用いて、図28のステップS580のFingerエントリ宛先解決処理の手順について説明する。
まず、範囲宛先解決部344が、Fingerエントリiのノードに対して、中継部380を介して図24で説明した範囲宛先解決処理S460を実行し、そこで範囲宛先解決処理S550で得られたFinger範囲外属性範囲afo2に対応するノードの宛先(通信アドレス)と属性範囲の対を複数取得する(ステップS581)。なお、この時、範囲宛先解決部344は、Fingerエントリiのノードに、呼び出し元の値域端点amと、呼び出し元が認識する呼び出し先の値域端点afiとを中継部380を介して通知する。
そして、この処理を呼び出した元の呼び出し元のノードでは、値域変更通知が含まれる場合(ステップS583のYES)、その通知に含まれるノードの情報に基づいて属性宛先表格納部404に格納されている属性宛先表454を更新し(ステップS585)、ステップS587に進む。値域変更通知が含まれない場合(ステップS583のNO)、ステップS587に進む。
ステップS581で得られた結果に失敗範囲が含まれている場合は、元の呼び出し元のノードは、その失敗範囲を未決定範囲anに加える(ステップS587)。
そして、元の呼び出し元のノードは、結果として得られたSuccessorノードと属性範囲を結果リストに格納し(ステップS589)、本処理を終了して、図28のフローに戻る。続いて、次のFingerエントリiに関して、未決定範囲集合anを同様に処理し、最終的に得られた結果リストを呼び出し元に返す(ステップS573)。
以上の処理により、本実施形態の情報システム1は、データアクセス要求されたデータの属性値からアクセス要求の宛先のノードを特定できる。
以上説明したように、本実施形態の情報システム1によれば、Chordアルゴリズムに基づいてノード間の送受信関係を構築することで、以下の効果を有する。
第1に、フルメッシュのアルゴリズムの場合に比較して、各ノードが保持する他ノードの通信アドレス数が少なくなるためにスケーラビリティに優れる。第2に、各ノードからある他ノードへの通信経路が複数経路となり、かつ、アルゴリズムにより自動的に経路が選択されるために、経路障害に強い。
さらに、本実施形態においては、データ分布の変化により更新する必要のある属性宛先表454の更新負荷や更新不足に伴う性能問題や一貫性問題が少なくなるという本実施形態に特有な利点がある。すなわち、上記実施形態のフルメッシュのアルゴリズムにおいては、あるノードが保持するデータの値域が変更された場合に、他の全てのノードにおいて、そのノード値域端点を属性宛先表414で反映させる必要がある。しかし、本実施形態のChordアルゴリズムにおいては、Chordアルゴリズムが生成するノード間の送受信関係上であれば、更新されるべき属性宛先表454に記憶される値域端点が少なくなる。そのため、本実施形態では、上記実施形態に比べ、更新負荷や、更新不足に伴う性能の問題や一貫性の問題が低減される。
このように、本実施形態の情報システム1によれば、ChordなどDHTに基づく送受信関係の構築により、その上で形成する属性宛先表の更新に伴う問題が軽減される。
さらに、本発明によれば、データアクセス要求の転送に要するホップ数が低減せず、転送負荷の偏りが、登録されるデータの分布によって変化しないようにすることができる。
その理由は、以下の通りである。本発明の情報システム1では、ノード間のIDの関係で構築した送受信関係を表す宛先表とは別に属性毎に宛先表を構築する。そして、この宛先表の変化によって、分布の変化を反映させるため、送受信関係を構築する宛先表に対する変更は必要としないからである。
さらに、上記第1のアプローチでは、複数の属性を扱う際に、ある属性のデータの分布の変化に応じて、他の属性のデータアクセス特性が影響を受ける、あるいは、属性数に応じて宛先表に登録される他ノードの数が増加するといった問題点があった。そして、宛先表に登録される他ノードの数が増加すると、クラスタが密に結合し、あるノードでの障害が広範囲に影響したり、ノード上での通信資源(Socketなど)が枯渇するといった問題点があった。
その理由は、以下の通りである。本発明の情報システム1では、格納するデータの属性の分布に応じて宛先表を決定する。そのため、複数の属性の間で単一の宛先表で共有すると、ある属性の分布の変化に応じて宛先表が更新されて、それを介して他の属性のホップ数や次数に影響を与えてしまうからである。また、複数の属性毎に宛先表を設け、異なるノードを登録すれば、影響を受けないが、属性数に応じて宛先表のサイズが増加するといった問題点が生じる。
本発明によれば、様々な用途で複数の属性を扱う際にも、その属性毎に異なるノードからなる宛先表を作り、関与するノードの数を増加させず、またある属性に関して登録されるデータの分布の変化が、宛先表の更新を介して、他の属性の宛先取得の性能に影響を与えないようにすることができる。
その理由は、以下の通りである。本発明の情報システム1では、ノード間のIDの関係で構築した送受信関係を表す宛先表とは別に属性毎に宛先表を構築する。そして、本発明の情報システム1では、ある属性の変化はその属性のみの宛先表にだけ変化を与え、IDから構築した宛先表に変更を加えることがないことによる。
(第3の実施の形態)
本発明の実施の形態に係る情報システムは、上記実施形態の情報システムとは、宛先解決処理にDHTのKoordeアルゴリズムを用いる点で相違する。なお、上記実施形態で図面を用いた各構成要素が行う処理の手順が、本実施形態と上記実施形態とは異なるが、構成については同じであるので上記実施形態と同じ図面と同じ符号を用いて以下説明する。
本実施形態は、宛先解決部340、値域更新部406の処理手順が上記実施形態とは異なり、また、ID宛先表格納部402に格納されるID宛先表412と属性宛先表格納部404に格納される属性宛先表414が上記実施形態とは異なる。本実施形態では、ID宛先表格納部402にはID宛先表462(不図示)が格納され、属性宛先表格納部404には属性宛先表464(図30)が格納されるものとする。それ以外は上記実施形態と同様とすることができる。
本実施形態の情報システム1は、ID宛先表格納部402に記憶されるID宛先表412を生成するID宛先表構築部410やID検索部408がKoordeアルゴリズムに基づいてノード間の送受信関係を構築する。そして、上記実施形態のような、データのハッシュ値の属性値を用いた完全一致検索ではなく、データの属性値を用いた範囲検索を可能とする。
さらに、本実施形態の情報システム1において、Koordeアルゴリズムに基づいた送受信関係を用いる利点は、Chordアルゴリズムとは異なり、各ノードの宛先表に格納するノード数(次数)を可変にできる点にある。さらに同じ次数において、中継部の仲介するホップ数が少なくなる傾向となる点にある。すなわち、Chordアルゴリズムでは、次数とホップ数が全ノード数Nに対してO(log2(N))であるのに対して、Koordeアルゴリズムでは、次数をkとした時にホップ数がO(logk(N))であり、kをO(log2(N))とした時には、次数O(log(N))に対してホップ数がO(log(N)/log(log(N)))となる。
さらに、本発明に特有な利点として、本発明の各ノードで更新される必要のある属性宛先表内のノード数が少なくて済むため、自律的な値域変更の確認の頻度や、平滑化制御部から通知するノード数を増やすことができる。
本実施形態では、Chordアルゴリズムの上記実施形態と異なり、属性宛先表格納部404に記憶される属性宛先表464の種別が異なる。これはID宛先表構築部410により生成されるID宛先表462が持つノード間の送受信関係を、ChordアルゴリズムとKoordeアルゴリズムとが、どのように使っているかに由来する。いずれも、探索対象のデータを格納したノードを特定するため、中継部による中継の度に、全データ集合の中から格納先を絞り込んでいく。たとえば、中継の度に探索空間が1/2となる時、最初の中継で100ノードから50ノードに絞り込まれ、次の中継で50ノードから25ノード、25ノードから12ノードへと絞り込まれる。
ChordアルゴリズムとKoordeアルゴリズムとでは、その実現方法が異なる。Chordアルゴリズムでは、中継部の中継ではID宛先表の探索空間の広いFingerが選択され、絞り込みが進むに従って探索空間の狭いFingerが選択されるようになる。すなわち、Chordアルゴリズムでは、ある1つのノードのID宛先表に格納されるFingerノードの役割が異なる。あるFingerノードは100ノードから50ノードに狭める役割を担い、別のFingerノードは25ノードから12ノードに狭める。
これに対しKoordeアルゴリズムでは、ID宛先表に記憶される各Fingerが担う探索空間を狭める役割は、どのFingerもほぼ同じである。すなわち、どのFingerノードも、ある時は、全てのFingerノードが100ノードから50ノードに狭める役割を担い、別の時には、全てのFingerノードが50ノードから25ノードに狭める役割を担う。
それにも関わらず、最初の中継では探索空間が100ノードから50ノードに狭まり、中継が進むに従って、25ノードから12ノードなどより狭い絞り込みができるようにするために、データアクセス要求の中継メッセージ内に中継回数に応じた情報を含め、これを適宜更新または参照しながらID宛先表を参照する。このようなID参照表を参照することで、データのハッシュ値に基づく完全一致検索においては、KoordeアルゴリズムはChordアルゴリズムよりも、次数に対するホップ数に関する性質が優れている。より具体的には、アクセスするデータのハッシュ値の先頭何ビット目を考慮しているかに関する情報が中継回数に応じて参照または更新される。
本実施形態の情報システム1では、Koordeアルゴリズムが目的とするハッシュ値に基づく完全一致検索ではなく、属性範囲に基づく範囲検索など属性の順序性に基づいた処理を行うため、その確率的な均一性が保証されたハッシュ値の場合には機能していた宛先表の設計と参照の仕方が、その均一性の保証がないために変更される必要がある。
すなわち、Koordeアルゴリズムでは、中継部の中継した回数に非依存なID宛先表を構築し、ID検索部では中継回数に依存したID宛先表の参照がなされるよう中継されるデータアクセス要求を含めていたが、本実施の形態では、中継部の中継回数に依存した属性宛先表を構築する必要がある。その理由は、以下の通りである。ハッシュ値の場合は、その確率的な均一性という特徴のため、ある上位ビットまでが特定され下位ビットが任意である状態で、任意な下位ビットの先頭数ビットに応じてデータを振り分ける際に、その振り分け配分は、特定されているビットの位置によらず、ほぼ一定であることが期待できる。しかし、属性値の場合は、分布情報が存在しないために、それが期待できないことによる。
たとえば、8ビットのハッシュ値に上位の2ビットまでが10に特定されている情報(10******)が1万件あり、次の2ビットを00、01、10、11のパターンで分割する(Fingerノードに振り分ける)ことを考えると、その割合はほぼ25%ずつであり、これは上位の4ビットまでが1011に特定された1011****の次の2ビットを特定する場合の割り振り配分でも同じであることが、ハッシュ値の確率的な均一性から判断できる。
これに対して、任意の分布を持った属性、たとえば、年令を8ビット値として扱うと、先頭が10に特定されている値10******(128〜191)にて次の2ビットを振り分ける割合と、先頭が0001に特定された値0001****(16〜31)にて次の2ビットを振り分ける割合とが、異なることは、登録されるデータが年令という分布であることから想定されうる。このため、本実施の形態では、中継部の中継回数に依存した属性宛先表を構築する必要があるため、本実施形態の属性宛先表と、値域更新部が構築する属性宛先表の動作を明らかにする。
本実施形態の属性宛先表464について、図30の表を参照して説明する。
属性宛先表464では、Koordeアルゴリズムにより構築され、ID宛先表462に記憶されるSuccessorノードと、Fingerノード毎に複数の値域端点を持つ。ここでのFingerノードは、順序付けされており、自ノードmの整数倍のPredecessorであるノードをFingerノード1とし、そのSuccessorノードをFingerノード2とする。また、属性宛先表464は階層に分類され、階層とIDから、値域端点が取得できる状態として記憶されている。各Fingerについて値域端点が階層毎に格納されるが、Fingerノード数Nとして、FingerノードNからはそのSuccessorノードの値域端点が得られているとし、これを便宜上FingerノードN’とする。この情報は、Fingerノード数を増やし、ノードmが取得してもよいが、その場合は次数が1増えると判断してよい。
また、各階層には階層値域が定義される。階層1における階層値域の起点はそのノードの値域端点amであり、終点はSuccessorノードの値域端点asであり、(am,as]となる。階層2以上では階層値域の起点alfはFingerノード1の値域端点である。終点はSuccessorノードの値域端点als、あるいはFingerN’の値域端点alf’とする。好適には、終点はSuccessorノードの値域端点alsと、FingerN’の値域端点alf’のうち、Fingerノード1の値域端点から遠い方の値となる。すなわち、alsが(alf,alf’]に含まれるならばalf’であり、逆にalf’が(alf,als]に含まれるならばalsとするのがよい。
なお、この階層値域に含まれるか否かの判定はKoordeアルゴリズムにおけるImaginaryNode(仮想ノード)が自ノードmとSuccessorノードの間に含まれるか否かを判定する処理と対応するが、Koordeアルゴリズムとは異なり必要となってしまう階層ごとの値域情報を有しているため、可能となる。
本実施形態の情報システム1において、各ノード(データ格納サーバ106または操作要求中継サーバ108のID宛先表構築部410)は、論理識別子空間において、自ノードと他ノードとの論理識別子IDの差を、論理識別子空間のサイズで剰した余りとして、前記自ノードと前記他ノードとの距離を求め、距離が最小であるノードを隣接ノード(Successorノード)とし、ならびに、自ノードの整数倍の論理識別子IDを、論理識別子空間のサイズで除した余りの論理識別子IDから最も距離の近いノード、およびそのノードから最も距離の近い一定数のノードを、自ノードのリンク先(Fingerノード)として選択する。
そして、各ノードは、自ノードで少なくとも選択されたリンク先(Fingerノード)を宛先ノードとし、宛先ノードと、宛先ノードの論理識別子IDとの第1の対応関係(ID宛先表462)と、宛先ノードの論理識別子IDと、そのノードが管理しているデータの属性毎の値域と、の第2の対応関係(属性宛先表464)と、を対応関係として保持し、第2の対応関係は、さらに、宛先ノードの階層毎に、データの属性毎の値域を保持する。
上述したように、本実施形態の情報システム1では、宛先解決部のアルゴリズムがDHTのようにノード間転送を行うものであり、自ノードが管理していないデータに対するアクセス要求を受け付けたデータ格納サーバ106が、操作要求中継サーバ108として機能する。
以下、本実施形態の情報システム1の動作について、説明する。
まず、本実施形態の情報システム1において、属性宛先表464を構築する処理について説明する。図31は、本実施形態の属性宛先表構築処理S600の手順の一例を示すフローチャートである。この属性宛先表構築処理S600は、データ操作クライアント104(図4)の宛先表管理部400の値域更新部406(図7)が行う。以下、図4、図7、図30、図31を用いて説明する。
この処理S600は、このデータ管理システムに対して、ユーザから指定された属性が格納する定義がなされた際、各データ格納サーバに対して値域の割当てが行われた後に実行される。
まず、あるノードm(データ操作クライアント104)の値域更新部406が、属性宛先表464を構築する属性について、Successorノードに値域端点asを問い合わせて取得する。値域更新部406が、このノードmの値域端点amとの範囲(am,as]を階層1における階層値域として属性宛先表464に格納する(ステップS601)。
次に、階層levを2から1ずつ増加させながら、ステップS603〜ステップS621の間のループ処理を行う。値域更新部406は、階層levを2として、Successorノードiから階層lev−1の値域端点を取得する(ステップS605)。そして、値域更新部406は、得られた値域端点をSuccessorノードiのノードの階層levの値域端点とする(ステップS607)。
そして、ID宛先表462に格納されるFingerノードのそれぞれについて、ステップS609〜ステップS615のループ処理を行う。ID宛先表462に含まれるすべてのFingerノードについて処理が終了したら本ループ処理を終了する(ステップS615)。
値域更新部406は、Fingerノードiから、階層lev−1について階層値域を取得する値域端点取得処理S630(図32)を行う(ステップS611)。この処理については図32を用いて後述する。
ステップS611で、Fingerノードiから得られたそれぞれの階層値域の起点をこのFingerノードiのこの階層における値域端点として属性宛先表464に格納する(ステップS613)。
この時、ステップS611で呼び出されたFingerノードiでは、値域端点取得処理S630が行われる。図32は、本実施形態の情報システム1における値域端点取得処理の手順の一例を示すフローチャートである。Fingerノードiでは、本処理は、宛先表管理部400の値域更新部406が行う。
まず、Fingerノードi(図4のデータ操作クライアント104)は、呼び出し元のノードnから当該属性の階層levの値域端点を取得する(ステップS631)。そして、Fingerノードiは、階層levの値域端点を返すために、宛先表管理部400の属性宛先表格納部404に格納されている属性宛先表464から、当該階層levの1番目のFingerノード1の値域端点が存在する場合(ステップS633のYES)、その値域端点を取得する(ステップS635)。
値域端点が存在しない場合(ステップS633のNO)、その1番目のFingerノード1に対して、階層lev−1の値域端点を問い合わせて取得する(ステップS637)。そして、ステップS635とステップS637で得られた結果を呼び出し元のノードnに返す(ステップS639)。
図31に戻り、ここでFingerノード数N’まで繰り返すとしているが、これは実際のFingerノードNに対して、そのSuccessorノードを問い合わせて得たものと同じとして扱っている。続いて、階層levの階層値域の起点をFingerノード1の起点とし、終点を、この階層のFingerノードN’とSuccessorノードのうちで起点から最も遠い値域端点とする(ステップS617)。
このように各階層についてループ処理を繰り返し、階層levまでの階層値域の和集合が属性空間全体を含むまで続ける。階層levまでの階層値域の和集合が属性空間全体を含んだら(ステップS619のYES)、ループ処理を終了し(ステップS621)、本処理を終了する。
次に、本実施形態の情報システム1における単一宛先解決処理について説明する。
図33〜図36は、本実施形態の情報システム1における単一宛先解決処理S650の手順の一例を示すフローチャートである。この単一宛先解決処理S650は、データ操作クライアント104(図4)の宛先解決部340の単一宛先解決部342(図7)が行う。以下、図4、図7、図33〜図36を用いて説明する。
本単一宛先解決処理S650は、自ノードm(データ操作クライアント104)のデータ追加削除部362(図7)またはデータ検索部364(図7)から実行される場合と、中継部380(図4の操作要求中継サーバ108)を介して、他ノード(データ操作クライアント104)の単一宛先解決部342から実行される場合とがある。
ここでは、この単一宛先解決処理S650が、自ノードmの操作要求部360のデータ追加削除部362から呼び出された場合について説明する。
この時、データ追加削除部362は、属性値aに対応する通信アドレスを取得するための宛先解決要求とともに、呼び出し元の値域端点acと呼び出し元が認識する呼び出し先の値域端点aeを単一宛先解決部342に通知する。
本処理S650では、階層levを1から1ずつ増加させ、与えられた階層Lに到達するまで、各階層levについて、ステップS651〜ステップS659の間のループ処理を行う。すべての階層levについて処理が終了したら本ループ処理を終了し、本処理も終了する。
はじめに、あるノードm(データ操作クライアント104)の単一宛先解決部342が、階層levにおける階層値域に値域aが含まれるか否かを判定する(ステップS653)。値域aが含まれない場合(ステップS653のNO)、図34に進み、属性値aが含まれる階層値域を特定するための階層値域特定処理S660を行う。
図34に示す階層値域特定処理S660では、階層Lまで達している場合(ステップS661のYES)、単一宛先解決部342は、自ノードmのSuccessorノードに対して、その階層levで属性値aに対応する通信アドレスを得る処理を問い合わせる(ステップS663)。
このとき、単一宛先解決部342は、自ノードmで認識している階層levの1番目のFingerノード1の値域端点af1と、Successorノードの値域端点aiをSuccessorノードに通知する。Successorノードでは、属性宛先表464を参照し、通知された階層levで属性値aに対応する通信アドレスを取得して返信する。このとき、Successorノードでは、通知された値域端点の情報に基づいて、属性宛先表464の値域端点と通知された値域端点とを比較し、違いがある場合、値域変更通知を返す。
そして、Successorノードから返信された実行結果に値域変更通知が含まれる場合(ステップS665のYES)、単一宛先解決部342は、値域変更通知の情報を属性宛先表464に反映させて更新し(ステップS667)、ステップS669に進む。値域変更通知が含まれない場合(ステップS665のNO)、ステップS669に進む。
ここで、ステップS663で得られた結果にリダイレクト先が含まれる場合、ノードに対するデータアクセスに失敗したことになる。成功であれば(ステップS669のNO)、得られた結果を呼び出し元に返し(ステップS671)、単一宛先解決処理を終了する。失敗であれば(ステップS669のYES)、図33のフローに戻り、階層levを1増加し、次の階層lev(階層Lより大きい階層)についてループ処理を繰り返し、階層値域に含まれるかの判定を行う(ステップS653)。なお、階層Lまで達していない場合(ステップS661のNO)、図33のフローに戻り、階層levを1増加し、次の階層levについてループ処理を繰り返す。
図33では、図34の処理で属性値aが含まれる階層levが特定されると(ステップS653のYES)、ステップS655に進む。階層levが1である場合には、単一宛先解決部342は、Successorノードの通信アドレスを呼び出し元に返す(ステップS657)。階層levがLである場合には、図35の自ノードmの値域確認処理S680に進む。
図35に示す自ノードの値域確認処理S680では、単一宛先解決部342が、通知された値域端点aeと、自ノードmの階層LのFingerノード1の値域端点af1が一致しているか否かを判定する(ステップS681)。一致していない場合(ステップS681のNO)、自ノードmの階層LのFingerノード1の値域端点af1を値域変更通知に格納する(ステップS683)。そして、値域端点af1が値域[ac,a)に含まれるか否かを判定する(ステップS685)。値域端点af1が含まれない場合(ステップS685のNO)、宛先解決の失敗を呼び出し元に返し(ステップS687)、単一宛先解決処理を終了する。
通知された値域端点aeと値域端点af1が一致している場合(ステップS681のYES)、または、値域端点af1が値域[ac,a)に含まれる場合(ステップS685のYES)、図33のフローに戻り、ステップS700に進み、処理を続ける。
図33において、ステップS655の判定で、階層levが1またはL以外の場合(ステップS655のそれ以外)、または、図35の自ノードの値域確認処理S680の後に、ステップS700に進み、図36のFingerノードでの宛先探索処理S700を行う。
単一宛先解決部342は、FingerノードサイズをNとして、Fingerノードiを、FingerノードNから1までについて、ステップS701〜ステップS715の間のループ処理を行う。すべてのFingerノードについて処理が終了したら本ループ処理を終了する。
単一宛先解決部342は、Fingerノードiの値域端点afiが、Fingerノード1の値域端点af1と、属性値aの範囲[af1,a)に含まれるか否かを判定する(ステップS703)。値域端点afiが含まれない場合(ステップS703のNO)、次のFingerについて処理を続ける。
値域端点afiが含まれる場合(ステップS703のYES)、単一宛先解決部342は、そのFingerノードiに対し、その階層lev−1で属性値aに対応する通信アドレスを問い合わせて取得する(ステップS705)。その際、単一宛先解決部342は、自ノードmが認識している値域端点af1と値域端点aiをFingerノードiに通知する。
Fingerノードiから返信された結果に値域変更通知が含まれる場合(ステップS707のYES)、単一宛先解決部342は、値域変更通知の情報に基づいて、属性宛先表464を更新する(ステップS709)。
また、ステップS705での問い合わせ結果が失敗でなければ(ステップS711のNO)、Fingerノードiから取得したアドレスを呼び出し元に返し(ステップS713)、単一宛先解決処理を処理する。ステップS705での問い合わせが失敗であれば(ステップS711のYES)、次のFingerノードに対する処理を進める。このように、各ノードが、低い階層の属性宛先表464から参照し、さらに各階層では目的とする属性値が、その階層のどのFingerノードの間の値域に属するかを探索し、ネットワークを介して、Fingerノードに問い合わせることで、最終的に、宛先に到達することができる。
次に、本実施形態の情報システム1における範囲宛先解決処理について説明する。図37〜図40は、本実施形態の情報システム1における範囲宛先解決処理S730の手順の一例を示すフローチャートである。
この範囲宛先解決処理S730は、データ操作クライアント104(図4)の宛先解決部340の範囲宛先解決部344(図7)が行う。以下、図4、図7、図37〜図40を用いて説明する。
本範囲宛先解決処理S730は、自ノードm(データ操作クライアント104)のデータ追加削除部362(図7)またはデータ検索部364(図7)から実行される場合と、中継部380(図4の操作要求中継サーバ108)を介して、他ノード(データ操作クライアント104)の範囲宛先解決部344から実行される場合とがある。
この手順では、ある階層の値域端点が通知され得るが、あるノードmにてデータ検索部364から、属性範囲(af,at]に対応する通信アドレスを複数取得する処理が実行される際には、同一ノードであるためこの情報は与えられない。
ここでは、この範囲宛先解決処理S730が、自ノードmのデータ検索部364(図7)から呼び出された場合について説明する。
この時、データ検索部364は、属性範囲(af,at]に対応する通信アドレスを複数取得するための宛先解決要求とともに、呼び出し元の値域端点acと呼び出し元が認識する呼び出し先の値域端点aeを範囲宛先解決部344に通知する。
まず、あるノードm(データ操作クライアント104)の範囲宛先解決部344が、未決定範囲集合anを属性範囲(af,at]とする(ステップS731)。階層levを1から1ずつ増加させ、各階層levについて、ステップS733〜ステップS749の間のループ処理を行う。すべての階層levについて処理が終了したら本ループ処理を処理し、本処理も終了する。本処理では、階層毎に処理を繰り返すことで、属性範囲(af,at]を各階層の値域に分割する。
範囲宛先解決部344は、階層levにおいて、決定範囲集合an(属性範囲(af,at])を、その階層levの階層値域に含まれる範囲内属性範囲aiと、含まれない範囲外属性範囲aoに分割する(ステップS735)。
範囲内属性範囲aiが空の場合(ステップS737のYES)、ステップS743に進む。範囲内属性範囲aiが空でなく(ステップS737のNO)、かつ、階層levが1である場合(ステップS739の1である)、範囲宛先解決部344は、範囲内属性範囲aiとSuccessorノードを結果リストに格納する(ステップS741)。そして、範囲宛先解決部344は、範囲外属性範囲aoを未決定範囲集合anとする(ステップS743)。未決定範囲集合anが空集合であれば(ステップS745のYES)、結果リストを呼び出し元に返して(ステップS747)、範囲宛先解決処理を終了する。未決定範囲集合anが空集合でなければ(ステップS745のNO)、範囲宛先解決部344は、階層levを1増加させ、この未決定範囲集合anについて、次の階層のループ処理を行う。
ステップS739の判定で、階層levが階層Lである場合には、図38の自ノードの値域確認処理S750に進む。図38の自ノードの値域確認処理S750では、まず、範囲宛先解決部344が、値域端点aeと自ノードmの階層Lの1番目のFingerノード1の値域端点af1が等しいか判定する(ステップS751)。値域端点aeと値域端点af1が等しくない場合(ステップS751のNO)、範囲宛先解決部344は、自ノードmの値域端点af1を値域変更通知に格納する(ステップS753)。続いて、範囲宛先解決部344は、範囲内属性範囲aiを(ac,af1]に含まれる範囲と含まれない範囲に分割する。そして、範囲宛先解決部344は、含まれる範囲を失敗範囲とし、含まれない範囲をaiとする(ステップS755)。値域端点aeと値域端点af1が等しい場合(ステップS751のYES)、またはステップS755の後、本処理S750を終了し、図37のフローに戻り、ステップS760に進む。
図37に戻り、ステップS739の判定で、階層levが1またはL以外の場合(ステップS739のそれ以外)、図39に示すFingerノードでの範囲宛先探索処理S760を行う。また、上述した自ノードの値域確認処理S750の後もこの処理S760を行う。
図39に示すように、Fingerノードでの範囲宛先探索処理S760において、まず、範囲宛先解決部344は、未決定範囲集合an2を範囲内属性範囲aiとする(ステップS761)。そして、範囲宛先解決部344は、FingerノードiをFingerノード数Nから1まで変化させ、各FingerノードについてステップS763〜ステップS779の間のループ処理を行う。すべてのFingerノードについて処理が終了したら本ループ処理も終了する。
ループ処理において、まず、範囲宛先解決部344が、未決定範囲集合an2をFingerノード1の値域端点af1と、Fingerノードiの値域端点afiとの範囲(af1,afi]に含まれる範囲と含まれない範囲に分割する。そして、範囲宛先解決部344は、含まれる範囲をai2、含まれない範囲をao2とする(ステップS765)。
続いて、範囲宛先解決部344は、Fingerノードiに対し、範囲外属性範囲ao2に対応する通知アドレスを問い合わせる(ステップS767)。このとき、範囲宛先解決部344は、自ノードmが認識している値域端点af1と値域端点afiをFingerノードに通知する。Fingerノードiは、属性宛先表464を参照し、範囲外属性範囲ao2に対応する通知アドレスの結果リストを返信する。
Fingerノードiから得られた結果に値域変更通知が含まれる場合(ステップS769のYES)、範囲宛先解決部344は、値域変更通知の情報を属性宛先表464に反映する(ステップS771)。値域変更通知が含まれない場合(ステップS769のNO)、ステップS773に進む。
そして、範囲宛先解決部344は、Fingerノードから得られた通信アドレスの結果リストを、この手順での結果リストに追加し(ステップS773)、未決定範囲集合an2を、範囲内属性範囲ai2と失敗範囲との和集合とする(ステップS775)。
未決定範囲an2が存在しない(空集合)場合(ステップS777のYES)、Fingerノードに関するループ処理を抜け、ステップS781に進む。未決定範囲an2が存在する場合(ステップS777のNO)、次のFingerノードについてのループ処理を行う。
未決定範囲an2が空集合の場合(ステップS777のYES)、範囲宛先解決部344は、階層levがL以上であるか否かを判定する(ステップS781)。階層levがL以上である場合(ステップS781のYES)、範囲宛先解決部344は、図40のSuccessorノードの値域確認処理S790を行う。
図40に示すSuccessorノードの値域確認処理S790において、まず、範囲宛先解決部344が、Successorノードに対して、範囲外属性範囲aoに対応する通信アドレスを問い合わせて取得する(ステップS791)。その際、範囲宛先解決部344は、自ノードが認識している同じ階層levでの1番目のFingerノード1の値域端点af1とSuccessorノードの値域端点aiをSuccessorノードに通知する。
そして、Successorノードから得られた結果に値域変更通知が含まれる場合、範囲宛先解決部344は、値域変更通知の情報を属性宛先表464に反映して更新する(ステップS793)。そして、範囲宛先解決部344は、Successorノードから得られた結果リストをこの手順での結果リストに追記する(ステップS795)。そして、範囲宛先解決部344は、失敗範囲を未決定範囲集合anとして(ステップS797)、図39のフローに戻る。
図39において、階層levがL以上でない場合(ステップS781のNO)、または、ステップS790の後、処理S760から図37のフローに戻り、上述したステップS743に進む。
以上の処理により、本実施形態の情報システム1は、データアクセス要求されたデータの属性値からアクセス要求の宛先のノードを特定できる。
以上説明したように、本実施形態の情報システム1によれば、Koordeアルゴリズムに基づいてノード間の送受信関係を構築することで、以下の効果を有する。
各ノードの宛先表に格納するノード数(次数)を可変にできる。さらに同じ次数において、中継部の仲介するホップ数が少なくなる傾向となる。このように、本実施形態の情報システム1によれば、各ノードで更新される必要のある属性宛先表内のノード数が少なくて済むため、自律的な値域変更の確認の頻度や、平滑化制御部から通知するノード数を増やすことができる。
(第4の実施の形態)
本発明の実施の形態に係る情報システムは、上記実施形態の情報システムとは、多次元の属性について、範囲検索や範囲指定による通知条件設定ができる点で相違する。
上記実施の形態の属性宛先表414、単一宛先解決部342ならびに範囲宛先解決部344、値域更新部406において扱われる値域端点や属性値、属性範囲のうち、属性宛先表414に格納される値域端点や、単一宛先解決部342に入力される属性値や比較対象となる値域端点は、多次元属性値を空間充填曲線処理により1次元属性値に変換された値を扱う。範囲宛先解決部344に入力される属性範囲は、元の多次元属性範囲として扱われ、データアクセス対象の属性範囲の分割や、比較演算が第1〜第3の実施の形態の1次元属性範囲の分割や、比較演算と異なる。
本実施形態は、上記実施形態のように、1次元の属性についての範囲検索や範囲指定による通知条件設定ではなく、多次元の属性についての範囲検索や範囲指定による通知条件設定を可能とすることができる。それにより、本実施形態は、複数の1次元属性による範囲検索を実行するより、1回の多次元属性による範囲検索の方が、処理すべきデータ量またはデータ数を少なくすることができる。
たとえば、緯度と経度とで別々にインデックス付けされたデータ(単一インデックス)に関して、緯度に関する範囲検索で得られるデータ集合と、経度に関する範囲検索で得られるデータ集合の積集合をとることと、緯度と経度とを共にインデックス付けされたデータ(複合インデックス)に関して、緯度と経度とで範囲検索して得られるデータ集合とは結果としては同一だが、前者の方が後者より処理するデータ量またはデータ数は少ない。
本実施形態の情報システム1は、図4の上記実施形態の構成に加え、さらに、多次元属性値を空間充填曲線処理により1次元属性値に変換された値を値域として算出し、後述する属性宛先表474を生成する事前処理部320を備えてもよい。
図60は、本実施形態の情報システム1の事前処理部320の構成を示す機能ブロック図である。
本実施形態の情報システム1において、事前処理部320は、宛先サーバ情報格納部322と、逆関数部324と、空間充填曲線サーバ変換部326と、空間充填曲線サーバ情報格納部328と、を備え、空間充填曲線サーバ情報を作成する機能を有することができる。
ここで、本実施形態では、事前処理部320を設けることで、システム初期化時にヒストグラムに基づく逆関数処理によって静的に負荷分散を図り、その後、オンラインでシステム利用中には、本発明の値域変更により動的に負荷分散を図ることができる。
宛先サーバ情報格納部322には、上述したデータの格納先やメッセージ転送先を決定するための論理識別子の集合と、ノードの宛先アドレスとの対応が複数格納されている。たとえば、コンシステントハッシング(Consistent Hashing)や分散ハッシュテーブルの場合は、ハッシュ値と宛先ノードのIPアドレスなどである。宛先サーバ情報格納部322は、ノード毎に設けられる。
空間充填曲線サーバ情報格納部328には、多次元属性空間の部分空間に対する、他のコンピュータの宛先アドレスが複数格納される。多次元属性空間の部分空間を表現する形式は、たとえば、多次元属性空間の起点の1次元値を列挙して表現してもよく、次元数分の属性範囲の和集合を列挙して表現してもよく、どの次元の何ビット目の値などの条件の和集合を列挙して表現してもよい。
本実施形態では、空間充填曲線サーバ情報格納部328は、図61に示すような空間充填曲線サーバ情報テーブル332が格納される。空間充填曲線サーバ情報テーブル332は、宛先アドレス(IP)に対応する論理識別子(ID)の範囲(属性空間)の起点を1次元で表現した値を宛先アドレスと対応付けている。なお、図61では、空間充填曲線サーバ情報テーブル332に論理識別子(ID)が含まれているが、含まれなくてもよい。
本実施形態では、空間充填曲線サーバ情報格納部328は、図61に示すような空間充填曲線サーバ情報テーブル332が格納される。空間充填曲線サーバ情報テーブル332は、多次元属性空間を1次元に変換して得られる1次元属性範囲の起点の値を、宛先アドレス(IP)と対応づけ、さらに、論理識別子(ID)と対応付けている。なお、図61では、空間充填曲線サーバ情報テーブル332に論理識別子(ID)が含まれているが、含まれなくてもよい。また、論理識別子(ID)と宛先アドレス(IP)の対応テーブルを別途有している場合は、空間充填曲線サーバ情報テーブル332は、論理識別子(ID)と宛先アドレス(IP)のいずれか一方を含めばよい。
逆関数部324は、データ群のデータの分布情報を表す分布関数を求め、各前記ノードの前記論理識別子を入力として、当該分布関数の逆関数を施し、1次元値を出力する。
逆関数部324は、分布情報格納部310に格納されている累積分布情報を用いて、これを関数として表した累積分布関数r=CDF(v)の逆関数v=ICDF(r)を施すことで得られる値に対応するように、入力値に対して1次元値を出力する。累積ヒストグラムを用いる場合、この区分iの累積分布割合をr[i]、1次元値をv[i]とする。
たとえば、予め昇順にソートされた表から、与えられた入力値がrであるとすると、r[i]=rである区分iが存在する場合は、v[i]を出力する。そうでない場合、r[i−1]<r<r[i]であるような区分iを見つけ、次の式(1)で対応する1次元値を算出する。
空間充填曲線サーバ変換部326は、逆関数部324で算出された宛先サーバ毎の1次元値を入力として、空間充填曲線変換処理により多次元値に変換する。さらに、空間充填曲線サーバ変換部326は、空間充填曲線サーバ情報格納部328に格納される空間充填曲線サーバ情報テーブル332の上述した形式に応じて、サーバ毎の1次元値を予め定められた空間充填曲線サーバ情報の形式に変換し、空間充填曲線サーバ情報テーブル332を作成し、空間充填曲線サーバ情報格納部328に格納する。なお、形式の変換は行われず、各サーバのアドレスと、逆関数部324により得られた1次元値との対を含む情報のままでもよい。
本実施形態では、このようにして生成された空間充填曲線サーバ情報テーブル332を元に、値域更新部406が属性宛先表を生成し、属性宛先表格納部404に格納する。ここでは、まず、空間充填曲線サーバ情報テーブル332を生成した上で、属性宛先表を生成する構成としているが、これに限定されない。空間充填曲線サーバ変換部326が生成した1次元値と論理識別子IDとの対応関係に基づき、属性宛先表を生成し、属性宛先表格納部404に格納してもよい。
図62は、本実施形態の情報システム1の要部構成を示す機能ブロック図である。
図62に示すように、宛先解決部340は、図7の上記実施形態の構成に加え、宛先解決部340が、空間充填曲線サーバ決定部346をさらに有する。
空間充填曲線サーバ決定部346は、空間充填曲線サーバ情報格納部328に格納された空間充填曲線サーバ情報を取得し、これを参照しながら、単一宛先解決部342または範囲宛先解決部344から通知された多次元属性値の値または多次元属性の範囲と対応する1つまたは複数のコンピュータの宛先を単一宛先解決部342または範囲宛先解決部344にそれぞれ返す。
このように構成された本実施形態の情報システム1の動作について、以下に説明する。
ここでは、本実施形態の情報システム1の事前処理部320の動作について説明する。図63は、本実施形態の情報システム1の事前処理部320における空間充填曲線サーバ情報を生成する処理(ステップS31)の一例を示すフローチャートである。以下、図60、および図63を用いて説明する。
まず、事前処理部320(図60)において、宛先サーバ情報格納部322(図60)に格納された宛先のサーバ情報それぞれについて、以下のステップS35およびステップS37を繰り返し実行する(ステップS33)。逆関数部324(図60)が、宛先の論理識別子を正規化し、これに逆関数を施し、1次元の値を得る(ステップS35)。そして、ステップS35で得られた1次元値を空間充填曲線サーバ変換部326(図60)が、多次元属性値とし、これを全てのサーバ情報について処理することで得られる空間充填サーバ情報を、空間充填曲線サーバ情報格納部328(図60)に格納する(ステップS37)。
本実施形態において、多次元属性値を空間充填曲線処理により1次元属性値に変換された値を値域端点とする以外は、上記実施形態と同様であるので、以下、詳細な動作の説明は省略する。
以上説明したように、本発明の実施の形態に係る情報システム1によれば、多次元の属性についての範囲検索や範囲指定による通知条件設定を可能とすることができる。それにより、本実施形態は、複数の1次元属性による範囲検索を実行するより、1回の多次元属性による範囲検索の方が、処理すべきデータ量またはデータ数を少なくすることができる。
以上、説明したように、本発明によれば、格納や通知されるデータの分布が変化するシステムにおいても、効率的な属性の順序性に基づく処理を実行することができる。
以上、図面を参照して本発明の実施形態について述べたが、これらは本発明の例示であり、上記以外の様々な構成を採用することもできる。
実施例1
上記第1の実施形態の実施例について、以下説明する。
本実施例では、情報システム1において、宛先解決処理がフルメッシュアルゴリズムを用いる。
図2に示すように、アクセスコンピュータ202から、複数のデータコンピュータ208に格納されたデータを操作する例を示す。アクセスコンピュータ202には図1のデータ操作クライアント104が存在し、データコンピュータ208には、図1のデータ格納サーバ106が存在するとする。
本実施例では、データコンピュータ208として、図11のID宛先表412に示されたコンピュータが存在しているとし、アクセスコンピュータ202にはリレーショナルデータベース管理システム(RDBMS)がこのデータコンピュータ208にアクセスするために、図11のID宛先表412を予め構築しているとする。
アクセスコンピュータ202のRDBMSでは、データベース管理者から、スキーマを宣言する言語(SQL言語におけるDDL(Data Definition Language))でデータコンピュータ208に格納されるデータの情報が与えられるとする。たとえば、8ビットの符号なしの整数値として年令属性を有する会員テーブルが宣言され、年令属性についてインデックス付けが行われ、年令属性からテーブルのプライマリキーとなる会員IDを取得できるよう宣言される。
RDBMSは、データアクセスされる前の任意の契機で、年令属性インデックスをデータコンピュータ208に格納する。そのため、属性宛先表414は、値域端点を設定し、図41に示されるように、8ビットの整数空間を、ID宛先表から得られる各ノードの論理識別子ID幅に比例するように分割することで、構築される。このRDBMSのこの会員テーブルに、日本人のデータ214万件が格納されると、図42に図示すように、各ノードに格納されるデータ量またはデータ数には偏りが発生する。たとえば、初期(図41)に値域(245,255]と(0,18]を担当する論理識別子IDが70であるノードには37万件、値域(0,18]を担当する論理識別子IDが129のノードには35万件、値域(32,63]を担当する論理識別子IDが250のノードには91万件のデータが格納される。一方で、値域(201,245]を担当する論理識別子IDが980であるノードなど、4つのノードにはデータが登録されない。
平滑化制御部422(図8)が、論理識別子IDの隣接するSuccessorノードとデータ格納量を、ID幅に比例するように動作することで、図42に示したデータ量またはデータ数の不均衡は、図43に示すデータ移動と移動後のデータ量またはデータ数により是正される。たとえば、論理識別子IDが980であるノードにて、図15に示す平滑化制御部422の動作では、そのSuccessorである論理識別子IDが70であるノードにデータ量またはデータ数を問い合わせ、データ数37万件を得る。図16に示す時ノード平滑化制御部422の動作では、上記の(式1)に基づき、自ノードからSuccessorノードに移動すべきデータ量またはデータ数を算出すると(ステップS201)、(0×(70−980)−37×(980−803))/(70−803)=−22となる。
したがって、Importとして負荷分散計画が算出され(ステップS211)、論理識別子IDが70であるから22万件のデータを受け取る。論理識別子IDが70であるノード内部に格納されたデータの中での移動対象のデータは、この場合、値の小さな方から22万件目のデータであり、その境界の属性値が新たな値域端点として扱われる。
この時、論理識別子IDが980であるデータコンピュータ208の通知先表430(図14)に全てのアクセスコンピュータ202が予め登録されている場合であっても、アクセスコンピュータ202は、図43の属性宛先表414と同一の属性宛先表414を保持している保証はない。値域変更通知が反映される前にデータアクセス処理が発生するアクセスコンピュータ202では、属性値0のデータにアクセスするために、図20の動作に従い、古い属性宛先表414(図41)を参照することになり、論理識別子IDが70であるノードにアクセスすることになる。
しかし、論理識別子IDが70であるデータアクセス部における図17に示す動作により、更新された値域端点と次にアクセスすべきノードの情報を得る。すなわち、論理識別子IDが70であるノードでは、受け付けた属性値0と、新たな値域(10,18]との比較が行われ、この比較では属性値の方が小さいために、Predecessorノードである論理識別子IDが980を、値域端点10を値域変更通知として、その通信アドレスをリダイレクト先として返される。
たとえば、図21では、値域変更通知を受けた場合には(ステップS417のYES)、これを属性宛先表414に反映させ(ステップS419)、データアクセスが失敗であっても(ステップS421のYES)、リダイレクト先であるノード980にアクセスできるため(ステップS423)、負荷の平滑化動作後の値域が更新された状況でも、アクセスコンピュータ202は属性値0に対するデータアクセス処理を行うことができる。
また、論理識別子IDが980であるデータコンピュータ208から値域変更通知を受けていない別のアクセスコンピュータ202も、図20の動作により、図42に示される属性宛先表414から、図43に示される属性宛先表414を得ることができる。すなわち、このノードは属性宛先表414から一定間隔でランダムにノードを取得し、ある時に論理識別子IDが980であるノードが取り出されると、そのノードに値域端点245を送信する。論理識別子IDが980であるノードでは、自ノードの値域端点が10になっており異なっているため、その値域端点10が返され、これにより、図42の属性宛先表414は更新される。
このように、平滑化制御部422の動作によって、図41に示される各ノードの値域の分担状況が、図42〜図44のように変化し各ノードのデータ量またはデータ数は均一化される。その際に、各アクセスコンピュータ202にて保持する属性宛先表414も、データアクセス時や、自律的な更新確認、平滑化制御からの通知などにより、更新されていく。
実施例2
上記第2の実施形態の実施例について、以下説明する。
本実施例では、情報システム1において、宛先解決処理がChordアルゴリズムを用いる。
本実施例では、図3に示すように、複数のピアコンピュータ210に格納されたデータを、ピアコンピュータ210が互いに操作する例を示す。ピアコンピュータ210にはデータ操作クライアント104と操作要求中継サーバ108、データ格納サーバ106とが存在するとする。
情報システム1に格納されるデータは、図45〜図47に示されたデータであり、平滑化制御部422により論理識別子ID空間上で隣接するノードとデータ移動を行われ、特に、各ノードが担当する値域が図45の状態から、図46に示したデータ移動により、図47の状態に変わる途中であるとする。
図45〜図47には、本実施形態の属性宛先表格納部404に格納される属性宛先表も示されている。各属性宛先表は、1行目にSuccessorノードが、2行目以降にFingerノードがそれぞれ含まれる。たとえば、図45には、論理識別子IDが980のノードの属性宛先表が示されている。
ここで、図48のシーケンス図を参照しながら、論理識別子IDが980であるノードが属性値50というデータを登録、取得し、また別の論理識別子IDが70であるノードがそのデータを含む範囲を検索する手順を示し、属性格納部に格納される値域端点の更新について説明する。
平滑化制御部422(図8)によるデータ移動前の動作を示すと、論理識別子IDが980であるノードが属性値50というデータを登録するために単一宛先解決部342(図7)を呼び出す。まず、単一宛先解決部342は、属性宛先表のSuccessorノードを参照し、自ノードの値域端点10とSuccessorである論理識別子ID70のノードの値域端点25との間(10,25]に、属性値50が含まれるか否かを判定する。
図45に示すように、ここでは含まれないため、単一宛先解決部342は、属性宛先表のうちFinger表を参照し、自ノード10と属性値50の間(10,50)に、もっとも離れた論理識別子ID551のノードの値域端点138が含まれるか否かを判定する。ここでも含まれないため、単一宛先解決部342は、次のFingerである論理識別子ID250のノードの値域端点53が(10,50)に含まれるかを判定する。
ここでも含まれないため、単一宛先解決部342は、次のFingerである論理識別子IDが129であるノードの値域端点32と比較する。ここで含まれるため、単一宛先解決部342は、そのFingerである論理識別子IDが129であるノードに、属性値50に対する宛先を取得しにいく。論理識別子IDが129であるノードでは、図46の属性宛先表が管理されており、自ノードの値域端点32と、論理識別子IDが250であるSuccessorノードの値域端点53との間(32,53]の間に属性値50が含まれるかを判定する。ここでは属性値50が含まれるため、Successorノード(250)の通信アドレスを含んだ情報を、呼び出し元の論理識別子ID980のノードに返す。論理識別子ID980のノードは、そのSuccessorノード(250)を受信し、そのSuccessorノード(250)に属性値50に関するデータ登録を行う。
この論理識別子IDが980であるノードによる登録の後、図46に示したデータ移動が行われるとする(属性値50に相当するデータは論理識別子ID250のノードから、論理識別子ID413のノードに移動される)。そして、その後に再度論理識別子IDが980であるノードが属性値50に関するデータを取得するものとする。ただし、自ノード(980)の属性宛先表には反映されていないとする。
その場合、同じ手順で、論理識別子IDが250である通信アドレスが取得される。そのノードに属性値50でアクセスを行うと、値域変更通知として論理識別子IDが250であるノードの新たな値域端点として46が得られ、リダイレクト先としてその論理識別子ID413のノードが返される。このようにして、論理識別子IDが980であるノードは、データ移動された先に対してデータアクセスを行うことができる。
また、論理識別子IDが70であるノードが、属性範囲(45,55]を検索するために属性範囲宛先解決部に対して、その範囲のデータを格納した通信先アドレスを複数問い合わせたとする。まず、属性範囲(45,55]を、自ノードと値域端点25とSuccessorノードの値域端点32の範囲(25,32]に含まれる範囲と含まれない範囲に分割するが、ここでは全て含まれない範囲に分けられる。次に、Finger表を用い、この属性範囲(45,55]が、最も遠いFingerノードである論理識別子IDが640であるノードの値域端点160と自ノードの値域端点(25,160]に含まれる範囲と含まれない範囲に分割する。
ここでは全て含まれるため、次の論理識別子ID413であるノードについて(25,67]に含まれる範囲と含まれない範囲に分割する。ここでも全て含まれるため、次の論理識別子ID250であるノードについて(25,53]に含まれる範囲と含まれない範囲に分割され、それぞれ含まれる範囲(45,53]と含まれない範囲(53,55]となる。ここで、属性範囲(53,55]について、論理識別子ID250のFingerノードに中継部を介してデータアクセス要求が転送される。
次の論理識別子ID250であるノードで、属性範囲(53,55]に対応する宛先の問い合わせが処理される際には、呼び出し元の論理識別子ID70の値域端点25と呼び出し元の認識する呼び出し先の値域端点53が与えられる。この時、論理識別子ID250の値域端点は46に変わっているため、値域変更通知に格納される。続いて、呼び出し元の値域端点25と、呼び出し先の値域端点46との範囲(25,46]に含まれる範囲と含まれない範囲に分割される。ここでは全て含まれないため、失敗範囲はなく、この範囲(53,55]についての処理が続けられる。受け付けた属性範囲(53,55]は、自ノードとSuccessorノードの間(46,67]に含まれるため、そのSuccessorである論理識別子ID413が、論理識別子ID70であるノードに返される。
次に、図47を用いて説明すると、論理識別子ID250を呼び出した論理識別子ID70のノードでは、Fingerとの間に含まれる範囲(45,53]について、次の論理識別子ID129であるノードとの属性範囲(25,32]に含まれる範囲と含まれない範囲に分割される。ここでは全て含まれないため、論理識別子ID129であるノードに属性範囲(45,53]に関する問い合わせが行われる。この時値域端点が通知されるが、呼び出し元と先の値域端点は変わらないため、値域変更通知はされない。
この論理識別子ID129のノードでは自ノードとSuccessorノードの間(32,46]で分割され、属性範囲(45,46]に対してはSuccessorである論理識別子ID250のノードが返される。残る範囲(46,53]はFinger表を用いて分割される。しかし、全て論理識別子ID250のFingerノードに中継され、論理識別子ID250のノードでは、全て自ノードとSuccessorノード(413)の間(46,67]に含まれる。そのため、この範囲(46,53]に対してはこのSuccessorである論理識別子ID413のノードが返される。
これらの結果、範囲検索を実行した論理識別子IDが70では、属性範囲(46,53]と属性範囲(53,55]については論理識別子ID413のノードに、属性範囲(45,46]については論理識別子ID250のノードにアクセスする。それぞれのアクセス結果は、各ノードの値域に含まれるため、検索処理が実行される。そして、その結果が、論理識別子IDが70であるノードに返される。
実施例3
上記第3の実施形態の実施例について、以下説明する。
本実施例では、情報システム1において、宛先解決処理がKoordeアルゴリズムを用いる。
本実施例では、上記実施例2と同様に、図3のピアコンピュータ210からなる構成と、情報システム1に格納されるデータが、図33に示したデータ移動により、図33の状態に変わる途中であるとする。
値域更新部における動作の例を示すために、属性宛先表の具体例を用いて、各ノードの属性宛先表ならびに、その構築手順を示す。
図30には、論理識別子IDが129、640、551、250、413の各ノードの構築された属性宛先表464を示す。図49に示すように論理識別子IDが129であるノードが、階層1で自ノードとSuccessorである論理識別子IDが250のノードの値域端点53を取得し、これを階層1での階層値域とする。続いて、階層2について、予め構築されているID宛先表を参照して得られる自身のFingerノードに対して、そのノードの値域端点を問い合わせる。
Sucessorに対して階層2の値域端点を問い合わせると、論理識別子IDが250であるSuccessorノードは、自身のFingerノードである論理識別子IDが413に階層1での値域端点を問い合わせ、論理識別子IDが413であるノードは67を返す。この値67を、論理識別子ID250のノードは階層1での論理識別子ID413に対する値域端点として保持するとともに、呼び出し元である論理識別子ID129のノードに返し、論理識別子ID129はこれをSuccessorノードの階層2での値域端点として保持する。
続いて、論理識別子ID129のノードは、1番目のFingerノードである論理識別子ID250に階層1での値域端点を問い合わせ、論理識別子ID250であるこのノードは、先に格納した値を返す。このように、階層3まで続けると階層1から階層3までの階層値域の和集合が、属性空間全体を含むため、終了する。このように構築された属性宛先表は、平滑化制御部422による図49から図51の変化に伴い、図30に示した下線で示した値域端点は変更されているものとする。さらに、各ノードの属性宛先表では、自ノードならびにSuccessorノードとなっているノードの情報のみ更新されており、他は更新されていない状態とする。
単一宛先解決部342における動作の例を示すために、各ノードの属性宛先表を図30に示す。
論理識別子ID129であるノードが、属性値15と属性値0に対するデータアクセスを行うために単一宛先解決部342に問い合わせる例について説明する。
論理識別子ID129であるノードにて、まず属性値15が、階層1の階層値域である自ノードとSuccessorノードの間(32,46]に含まれるか判定する。図30ではSuccessorノードの値域端点は53であるが、このノードはSuccessorであるため更新されているものとする。この判定では、属性値15は含まれないため、階層2の値域階層(46,160]に含まれるか否かを判定する。
論理識別子ID250のノードはFingerノードであるが、Successorノードでもあるため変更は反映されている。この判定でも属性値15は含まれないため、階層3の階層値域(67,67]に含まれるか判定するが、これは全属性の範囲であるため、属性値15が含まれることが分かり、階層3について、各Fingerの担当領域に含まれるか否かを判定する。1番目のFingerと属性値の範囲[67,15)に、3番目のFingerの値域端点25は含まれないため、2番目のFingerの属性範囲3がこの範囲に含まれるか判定する。ここで属性範囲3が含まれるため、この2番目のFingerである論理識別子ID413のノードに対して、階層2でもって属性値15の宛先解決を問い合わせる。
論理識別子IDが413のノードでは、同じ手順が実行され、まず階層1の階層値域である(67,138]に含まれるか否かを判定する。ここでは属性値15は含まれないため、続いて階層2の階層値域(3,32]に含まれるか否かを判定する。ここでは属性値15が含まれるため、階層2について1番目のFingerの値域端点3と属性値15の間[3,15)に3番目のFingerの値域端点25が含まれるか否かを判定する。ここでは値域端点25が含まれないため2番目のFingerの値域端点10が含まれるか否かを判定する。ここでは値域端点10が含まれるため、2番目のFingerである論理識別子IDが980であるノードに階層1でもって属性値15の問い合わせを行う。この時、1番目のFingerノードの値域端点3と、論理識別子ID980の値域端点10も付して問い合わせる。
論理識別子IDが980のノードでは、受け付けた属性値15が、階層1の値域(17,25]に含まれるか否かを判定される処理が行われるが、その前に値域変更の確認が行われる。すなわち、ここでは自ノードの値域端点は、10から17に更新されている。そして、図33の単一宛先解決処理S650の手順では、受付けたFingerノードの値域端点3と論理識別子ID980の階層1における属性値15の間[3,15)に、自ノードの値域端点17が含まれるか判定する。ここでは値域端点17が含まれないため、値域端点17を値域変更通知に格納し、論理識別子ID413のノードに失敗として返す。
論理識別子IDが413のノードでは、属性変更通知を反映させ、失敗であるので、次のFingerである1番目のFingerノードと属性値15の間[3,15)にFingerノード1が含まれるか判定する。ここではFingerノード1が含まれるため、論理識別子IDが803のノードに対して属性値が15であるアクセス要求が中継(転送)される。
論理識別子IDが803であるノードでは、階層0の階層値域である自ノードとSuccessorノードの間(3,17]に含まれるため、そのSuccessorノードである論理識別子IDが413の通信アドレスが、この属性値15に対するアクセス要求として返される。
また、論理識別子ID129であるノードが属性値0に対するデータアクセスを行うと、その属性値が階層1の範囲(32,46]に含まれるか否か、階層2の範囲(46,160]に含まれるか否か、階層3の範囲(67,67]に含まれるか否かが、逐次確認される。そして、階層3であるため、さらに同じ手順により論理識別子ID250のFingerノードに対して要求が行われる。論理識別子ID250であるノードは、階層2の範囲(67,3]に含まれ、一方、Fingerノード3の値域端点160は[67,0)に含まれない。そのため、Fingerノード3である論理識別子ID640のノードに要求が行われる。
論理識別子ID640のノードでは、階層1の階層値域(160,175]に含まれるか否かを判定するが、ここでは属性値0は含まれない。しかし、論理識別子ID250から与えられた階層Lは1であるため、Successorである論理識別子ID698のノードにて階層1で、その属性0に対応する通信アドレスを取得する要求を送信する。論理識別子ID698のノードは、自ノードの値域端点とSuccessorノードの値域端点の間(175,3]に属性値0は含まれるため、その論理識別子ID803を属性値0に対する通信アドレスとして返す。
このように、論理識別子ID129からは、図38〜図40に示すように、全属性空間に対して、1回〜4回の通信で到達することができる。なお、論理識別子ID129自体が格納するデータは、Predecessorノードの値域端点の一貫性を持って更新されるようにしていれば、階層0として階層1より前に宛先解決してもよい。
続いて、範囲宛先解決部344における動作の例を示すために、各ノードの属性宛先表を図30に示す。
論理識別子ID129であるノードが属性範囲(5、20]に対する範囲検索を行ったとする。まず、未決定範囲集合anをこの範囲とし、階層1の階層値域(32,46]に含まれている範囲と含まれていない範囲aoに分割する。ここでは全て含まれていない範囲aoとなるので、これを再度未決定範囲とし、階層2の階層値域(46,138]に含まれている範囲といない範囲に分割する。そして、階層2の階層値域(46,138]に含まれていないため、階層3の階層値域(67,67]に含まれている範囲と含まれていない範囲に再度分割し、ここでは全て含まれるため、これを未決定範囲集合an2とし、Fingerノード1とFingerノード3である論理識別子ID551のノードの範囲(67,25]に含まれる範囲と含まれない範囲に分割する。
ここでは全て含まれるため、含まれない範囲に対する問い合わせは行われない。そして、次のFingerノードである論理識別子ID413のノードについて(67,3]に含まれる範囲と含まれない範囲に分割する。ここでは全て含まれないため、このFingerノード3である論理識別子ID413に階層2で属性範囲(5,20]に対する問い合わせが行われる。論理識別子ID413のノードでは、階層1には含まれず、階層2に含まれる。さらにFingerノード1とFingerノード3の範囲(3,25]に含まれる範囲と含まれない範囲に分割される。そして、全て含まれるので、Fingerノード1とFingerノード2の範囲(3,10]に含まれる範囲(5,10」と含まれない範囲(10,20]に分割される。一方、含まれない範囲についてはFingerノード2である論理識別子ID980のノードに(10,20]の範囲で、階層1で問い合わせが行われる。
この時、Fingerノード1の値域端点3と、Fignerノード2の値域端点10が通知される。論理識別子ID980のノードでは、階層1の階層値域(17,25]に含まれるか否か判定される。しかし、ここでは値域端点3と値域端点10は含まれず、さらに論理識別子ID980から階層L=1として与えられているため、通知されたFingerノード2としての値域端点10が、自ノードの階層1の階層値域の起点、すなわち自ノードの値域端点17と一致しているか判定する。そして、一致していないため、これを値域変更通知に含める。そして値域(3,17]に含まれる範囲(10,17]と含まれない範囲(17,20]に分割し、含まれる範囲(10,17]を失敗範囲とする。
また、含まれる範囲は(17,20]については、その範囲とSuccessorノードの通信アドレスを結果リストに含める。これらは論理識別子ID413のノードに返され、値域変更通知に従いFingerノード2の値域端点は17に更新する。そして、失敗範囲(10,17]は、Fingerノード2に関する範囲に含まれる範囲(5,10]とともに、未決定範囲集合an2となる。未決定範囲集合an2は、次のFinger範囲である(3,3]には全て含まれないため、論理識別子ID803のノードにて、その範囲に対応する宛先の問い合わせが行われる。論理識別子ID803のノードでは、自ノードの値域端点3とSuccessorノードの値域端点である階層1の階層値域(3,17]に含まれる否かを判定する。ここでは、全て含まれるため、この範囲を論理識別子ID980のノードとする。
実施例4
上記第4の実施形態の実施例について、以下説明する。
本実施例では、情報システム1において、多次元属性値を空間充填曲線処理により1次元属性値に変換された値を値域として算出し、属性宛先表を生成する。
図52〜図56に示すように、本実施例では、属性宛先表は、多次元属性値を空間充填曲線処理により1次元属性値に変換された値が値域端点として記憶される。
図52および図53では、宛先解決処理のアルゴリズムが、上記第1実施形態のフルメッシュアルゴリズムに相当し、操作要求中継サーバ108を備えない例であり、全ノードが共通の属性宛先表を有する。
情報システム1に多次元属性が格納されると定義された際に、そのデータの分布情報が得られており、図52の表に示された値域端点が得られていたとする。この表は、各ノードのIPアドレスと、そのノードの担当する値域の端点とを対応づける属性宛先表であり、値域端点は各ノードの論理識別子IDと分布情報から、逆関数部が算出した1次元値とする。なお、ここで各ノードの値域端点である1次元値を空間充填曲線処理により多次元値とした場合、各ノードが管理する値域である多次元の部分空間が、図52に示される。ここで図示される多次元範囲を属性宛先表として格納してもよい。データが登録されるに従い、分布が変化し、各ノードの管理するデータ量が変化すると、図53に示すように、各ノードは隣接ノードと値域の変更を行う。ここでは値域端点である1次元値が変更され、各ノードが保持するデータ量が変更される。
図54〜図56は、ノード980が、例えば、2ビット表記2次元属性値(011,100)にデータアクセスする際の要求経路を示している。なお、これと対応する1次元値は011111(31)である。ノード980が保持する属性宛先表は図54に示される。ここで、属性宛先表は、上の表がノード980の複数のFingerノードのリストであり、下の表がSuccessorノードを含んでいる。
この多次元属性値(0111,1000)の宛先が、属性宛先表の最後のエントリである1次元値011101以降と対応するか否かを、空間充填曲線処理を行うことで確認する。ここでは対応するため、このエントリのノード551に要求を送信する。ノード551が保持する属性宛先表は図55に示される。ここでも多次元属性値が、属性宛先表の最後のエントリ000100以降と対応するか否かを確認し、対応しないことが分かる。続いて値域端点が101110、100001、011110であるエントリと比較し、011110以降であるため、ノード640に要求が転送される。ノード640の属性宛先表を図56に示す。ここでは、Successorノード698の値域端点100001と自ノード640の値域端点011101の間に目的の多次元属性値(0111,1000)が存在するため、このノードにデータアクセスが行われる。
以上、実施形態および実施例を参照して本願発明を説明したが、本願発明は上記実施形態および実施例に限定されるものではない。本願発明の構成や詳細には、本願発明のスコープ内で当業者が理解し得る様々な変更をすることができる。
この出願は、2011年9月27日に出願された日本出願特願2011−211132号を基礎とする優先権を主張し、その開示の全てをここに取り込む。
まず、範囲宛先解決部344は、未決定範囲集合anを、自ノードmの値域端点amとFingerエントリiのafiの間(am,afi]に含まれるFinger範囲内属性範囲afi2と、含まれないFinger範囲外属性範囲afo2に分ける(ステップS563)。そして、範囲宛先解決部344は、未決定範囲集合anを、Finger範囲内属性範囲afi2とする(ステップS565)。そして、Finger範囲外属性範囲afo2が空でなければ(ステップS567のNO)、範囲宛先解決部344は、後述する図29のFingerエントリ宛先解決処理S580を行う(ステップS580)。Finger範囲外属性範囲afo2が空の場合(ステップS567のYES)、ステップS571に進む。Finger表内のすべてのFingerエントリについて処理が終了したら本ループ処理を終了する(ステップS571)。そして、範囲宛先解決部344は、値域変更通知、失敗範囲、および結果リストを呼び出し元に返す(ステップS573)。
本実施形態の情報システム1において、各ノード(データ格納サーバ106または操作要求中継サーバ108のID宛先表構築部410)は、論理識別子空間において、自ノードと他ノードとの論理識別子IDの差を、論理識別子空間のサイズで除した余りとして、前記自ノードと前記他ノードとの距離を求め、距離が最小であるノードを隣接ノード(Successorノード)とし、ならびに、自ノードの整数倍の論理識別子IDを、論理識別子空間のサイズで除した余りの論理識別子IDから最も距離の近いノード、およびそのノードから最も距離の近い一定数のノードを、自ノードのリンク先(Fingerノード)として選択する。
まず、あるノードm(データ操作クライアント104)の範囲宛先解決部344が、未決定範囲集合anを属性範囲(af,at]とする(ステップS731)。階層levを1から1ずつ増加させ、各階層levについて、ステップS733〜ステップS749の間のループ処理を行う。すべての階層levについて処理が終了したら本ループ処理を終了し、本処理も終了する。本処理では、階層毎に処理を繰り返すことで、属性範囲(af,at]を各階層の値域に分割する。
たとえば、予め昇順にソートされた表から、与えられた入力値がrであるとすると、r[i]=rである区分iが存在する場合は、v[i]を出力する。そうでない場合、r[i−1]<r<r[i]であるような区分iを見つけ、次の式(2)で対応する1次元値を算出する。