JP6131907B2 - 分散データベース、データ共有方法、プログラム、装置 - Google Patents

Description

本発明は、複数のノードを構成する複数のデータベースサーバで構成されるピアツーピア型の分散データベースの技術に関する。

背景技術として、ピアツーピアコンピュータ環境の分散データベースを利用するものがある。典型的なピアツーピアコンピュータ環境は、それぞれ様々な接続能力を有するノードとして知られるピアコンピュータシステムにより構成することができる（例えば、特許文献１参照）。

特許文献１に記載されるような代表的な分散データベースは、データを共有するために、ピアツーピアコンピュータ環境と接続する。ユーザコンピュータは、ピアツーピアコンピュータ環境のノードとなることにより、ピアツーピアコンピュータ環境に参加する。ユーザコンピュータは、インターネットを介して他のサーバにアクセスするために、ウェブブラウザアプリケーションにインターネットプロトコル（ＩＰ：Internet Protocol）アドレスを入力する。ウェブブラウザアプリケーションは、ユーザからドメイン名を受信し、ドメイン名システム（ＤＮＳ：Domain Name System）サーバに最初にコンタクトし、そして二値識別子を利用して実際のＩＰアドレスにリダイレクトされる。ウェブブラウザアプリケーションは、サーバファームでホストされたウェブページにアクセスするために利用され、サーバファームの代りにウェブページや他のサービスをホスティングするピアツーピアコンピュータ環境に参加する。

他方、複数のノードと呼ばれる分散データベースを構成する１つ１つのデータベースサーバで構成されるピアツーピア型の分散データベースにおいては、個々のノードがそれぞれですべての他ノードの死活状態を把握する必要がある。動作中のノードにデータを分散させて保存し、停止中のノードには分散対象から除外する。そのため、それぞれのノードがすべてのノードの死活状態等の情報を把握しておく必要がある。
ノード間での情報共有の手法として、ゴシッププロトコルが使われているものがある（例えば、特許文献２参照）。
また、ピアツーピア型のネットワークシステム内において、グループ内の複数のピア（ノード）が他のピアに問い合わせ、登録されているピアのメンバシップ・リストを記憶し情報を共通する技術を開示しているものがある（例えば、特許文献３参照）。

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

上述したような一般的な分散データベースによれば、複数のノードで１つのグループを構成して、そのグループの中で１つのノードが他のノードと通信することにより、通信先のノードが別のノードと通信したときの情報も取得することで、少ない回数の通信によって多数のノードの情報を取得することができる。これを繰り返すことによってグループ全体の情報をそれぞれのノードが取得することができる。通信先の選択はランダムに選択することで一様に広がる。

しかしながら、接続するノードをランダムに選択することによってノード数が増加した場合に、一部のノードに集中して負荷がかかる可能性が考えられる。そのため、負荷のかかったノードのレスポンスが悪くなったり、停止したりする可能性がでてくる場合がある。逆に一部のノードが選択されずなかなか情報共有されない可能性も考えられ、効率がよくないという課題があった。

図５、図６を用いて一般的な情報問い合わせ動作の例について説明しておく。
図５と図６は対応している。図６（ａ）において、ノードが４つと仮定し、ノード（Ｎ１）から他のノード（Ｎ２〜Ｎ４）への情報への問合せＲ１、Ｒ２、Ｒ３は、順序はランダムで定期的に実行する。他のノード（Ｎ２〜Ｎ４）からも同様に実行される。
図５において、図５（ｆ）に凡例として示すように、マーク■は未取得、不明状態、マーク○は取得済み、マーク□は取得予定（リクエスト）、マーク◇は取得予定（被リクエスト）を示す。図５において、各ノード間の問い合わせ状態、情報取得状態を示したリスト１０をノード状態リストという。

図５（ａ）は４つのノード（Ｎ１〜Ｎ４）が、まだどのノードとも情報を共有していない最初の状態を示す。
図５（ｂ）、図６（ｂ）は、次の状態を示し、ノード（Ｎ１）はノード（Ｎ２）に問い合わせ（所得予定（リクエスト））、ノード（Ｎ２）はノード（Ｎ４）に問い合わせ、ノード（Ｎ３）はノード（Ｎ１）に問い合わせ、ノード（Ｎ４）はノード（Ｎ３）に問い合わせる状態を示す。
図５（ｃ）、図６（ｃ）は、更に次の状態を示し、ノード（Ｎ１）はノード（Ｎ３）に問い合わせ、ノード（Ｎ２）はノード（Ｎ１）に問い合わせ、ノード（Ｎ３）はノード（Ｎ４）に問い合わせ、ノード（Ｎ４）はノード（Ｎ２）に問い合わせる状態を示す。
図５（ｄ）、図６（ｄ）は、更に次の状態を示し、ノード（Ｎ１）はノード（Ｎ４）に問い合わせ、ノード（Ｎ２）はノード（Ｎ３）に問い合わせ、ノード（Ｎ３）はノード（Ｎ２）に問い合わせ、ノード（Ｎ４）はノード（Ｎ１）に問い合わせる状態を示す。
図５（ｅ）は、ノード（Ｎ１〜Ｎ４）がすべてのノードの情報を取得し、安定状態になったことを示す。

問い合わせ先はランダムに選択されるので、選択によっては図６（ｅ）に示すように、ノード（Ｎ１）にノード２からノード（Ｎ２〜Ｎ４）の問合せが集中する可能性があり、ノード（Ｎ１）に負荷がかかることが考えられる。ランダムなので連続して同じノードに問合せる可能性もあり、短期的にみると効率が良くない。

本発明は、上記課題を解決するためになされたもので、複数のノードで構成されるピアツーピア型の分散データベースにおいて、個々のノードが他ノードの状態を効率よく取得して共有することを目的とする。

請求項１記載の発明は、
複数のノードでグループが構成されるピアツーピア型の分散データベースにおいて、前記各ノードはノード状態リストを有し、 個々のノードが他ノードの前記ノード状態リストの所定の情報を問い合わせて取得して共有する共有手段と、
決まったルートで前記情報を伝播させていく伝搬手段と、
ノードのグループ登録時に登録された順序で前記ノード状態リストを更新し、前記順序
で最後にあたるノードは前記順序の先頭から前記所定の情報を取得してノードをリング状に接続する手段と、
ノード数が上限値Ｍになったとき、ノード［１］からノード［Ｍ／２］を第１グループ、ノード［Ｍ／２＋１］からノード［Ｍ］を第２グループとして分割し、ノード［Ｍ／２］はノード［１］と接続し、ノード［Ｍ］はノード［Ｍ／２＋１］と接続することによって前記グループを分割する分割手段と、
各グループのノードがグループ内で情報共有したら、別グループのノードに接続先を変更する手段と、
を有することを特徴とする分散データベース。
を、提供するものである。

本発明によれば、複数のノードで構成されるピアツーピア型の分散データベースにおいて、個々のノードが他ノードの状態を効率よく取得して共有することができる。

本発明の一実施の形態におけるノードの登録動作のフローチャートである。 本発明の一実施の形態におけるノードの情報共有処理（リクエスト送信）動作のフローチャートである。 本発明の一実施の形態におけるノードの情報共有処理（リクエスト受信）についてのフローチャートである。 本発明の一実施の形態におけるネットワーク接続構成の概要のブロック図である。 一般的なノード状態リストを示す図である。 一般的な情報問い合わせ動作について説明するための図である。 本発明の一実施の形態におけるノード数４の場合のノード状態リストを示す図である。 本発明の一実施の形態におけるノード数４の場合の情報問い合わせ動作について説明するための図である。 本発明の一実施の形態におけるノード数８の場合のノード状態リストを示す図である。 本発明の一実施の形態におけるノード数８の場合の情報問い合わせ動作について説明するための図である。

以下、複数のノードで構成されるピアツーピア型の分散データベースにおいて、個々のノードが他ノードの死活状態等の情報を取得する手段並びに方法について説明する。
＜構成＞
図４は本発明の一実施の形態であるネットワーク接続構成の概要についてのブロック図である。図４のＡ１〜Ａ４、Ｂは、ネットワーク１００上に接続されたＰＣ（パーソナルコンピュータ）あるいはサーバであり、以降はノード（Ｎｏｄｅ）と称呼する。ノードＡ１からＡ４は、同じグループ（グループＡ）を構成するノードを意味する。ノードＢは、グループAに所属しないノードを意味する。

ノードＡ１、Ａ２、Ａ３、Ａ４は、ノード状態リスト１１、１２、１３、１４、リクエスト送信用ノード情報処理プログラム２１、２２、２３、２４、リクエスト受信用ノード情報処理プログラム３１、３２、３３．３４、ＣＰＵ４１、４２、４３、４４、データメモリ５１、５２、５３、５４を有する。

ノード状態リスト１１、１２、１３、１４は、図５、７、９で説明に使用するように、各ノードが、どのノードに問い合わせ予定（リクエスト）か、どのノードから問い合わせられるのか（被リクエスト）、死活状態等の情報を未取得なのか、取得済みなのか、という状態リストを記憶している。

ＣＰＵ４１〜４４は通信プロトコルを有し、各ノードを制御するもので、リクエスト送信用ノード情報処理プログラム２１〜２４並びにリクエスト受信用ノード情報処理プログラム３１〜３４を実行し、後述するノード情報共有処理を定期的に実行する。このリクエスト送信用ノード情報処理プログラム２１〜２４並びにリクエスト受信用ノード情報処理プログラム３１〜３４は便宜上分けて記載しているが、実際は一体化された１つのプログラムとして構成することができる。このリクエスト送信用ノード情報処理プログラム２１〜２４並びにリクエスト受信用ノード情報処理プログラム３１〜３４は、各ノードにインストールされている。

また、ＮＴＰ（Network Time Protocol）によって各ノードの時刻同期をはかっている。別々のノード で同時期に別の状態のリストを持った場合のコンフリクトを整合化するために、情報を取得したときの時刻も合わせて情報と共に記録しておき、複数のノード情報が入ってきて状態が異なる場合は、取得時刻の新しい方を採用する。

データメモリ５１〜５４は、通常に各種データを記憶すると共に、各ノードから取得したメモリ残量情報、パフォーマンス情報等の一覧も記憶する。その際、情報を取得した時刻も併せて記憶する。前記ノード状態リスト１１、１２、１３、１４をデータメモリ５１〜５４内に構成してもよい。また逆に、各ノードから取得したメモリ残量情報、パフォーマンス情報、時刻情報等をノード状態リスト１１、１２、１３、１４に記憶させてもよい。

＜動作＞
本実施の形態の動作についてはフローチャートを用いて後述するが、はじめに概略説明をする。

１．ノードの登録
（０）ノードの登録は既にグループに登録されているノードから行う。
（１）ノードをグループに登録する。全ノード数をＮとして登録する際に、グループ内で識別するための識別番号を指定する。
（例：Node［１］、Node［２］、Node［３］、…、Node［Ｎ］、…、Node［Ｍ］）
（２）各ノードは全ノードの情報（ノードの死活状態）を保存するリストを持つ。ノードのグループ登録時にリストを作成する。
ノードと接続し情報を取得するのは、Node［Ｎ］→Node［Ｎ＋１］のように順序を決める。
順序で最後にあたるノードは順序の先頭から取得する（Node［N］→Node［１］）、としてリング状にする。
（３）新たなノード状態リストをすべてのノードに配信する。

２．ノードの処理
（４）Node［Ｎ］は、Node［Ｎ＋１］の情報を取得するリクエストを送信する。その際、Node［Ｎ］の持つリストも合わせて送信する。
（５）Node［Ｎ＋１］は、Node［Ｎ］から取得したリストに、Node［Ｎ＋１］の持つリストの情報を追記してレスポンスとして返信する。
（６）Node［Ｎ］は、Node［Ｎ＋１］から取得した情報を自分のリストに追記する。
（７）Node［Ｎ］は、Node［Ｎ−１］から同様にリクエストされるので、上記（５）に該当する部分を行い、レスポンスを返信する。
（８）（４）に戻って繰り返す。

３．ノード数が増加した場合
（９） ノード数Nは、ノードを追加していき、ノード数の上限値Ｍになったとき、Node［１］からNode［Ｍ／２］をＡグループ、Node［Ｍ／２＋１］からNode［Ｍ］をＢグループとして２つのグループに分割する。
（１０）Node［Ｍ／２］はNode［１］と接続し、Node［Ｍ］はNode［Ｍ／２＋１］と接続することでリングを２つに分割する。情報共有は分割する前と同様に行う。
（１１）一定期間（各グループのノードが情報共有できたぐらい、上記の例ならばＭ／２回以上）したら、別グループのノードに接続先を変更する。例えば、ＡグループのNode［Ｎ］は、ＢグループのNode［Ｎ＋Ｍ／２］に接続する。

４．ノードからレスポンスが返らない場合
（１２）K回以上レスポンスが返ってこないNode［ｘ］は、停止したとみなして次の順序のノードに変更（Node［ｘ−１］→Node［ｘ＋１］）して、リクエストを行う。
（１３）同様にK回以上、正常ではないレスポンスが返ってきた場合のNode［ｘ］は、データ保存できない状態とみなして次の順序のノードに変更（Node［ｘ−１］→Node［ｘ＋１］）して、リクエストを行う。
（１４）停止ノードNode［ｘ］には、別途接続を試行して、復活した場合は変更する。

図７はこの実施の形態におけるノード数４の場合のノード状態リストを示す図である。また、図８は同実施の形態におけるノード数４の場合の情報問い合わせ動作について説明するための図である。更に、図９は同実施の形態におけるノード数８の場合のノード状態リストを示す図である。また、図１０は同実施の形態におけるノード数８の場合の情報問い合わせ動作について説明するための図である。
図５、６の一般的なプロトコルの情報問い合わせ動作と対比しやすいように、図７〜１０により本実施の形態における情報問い合わせ動作について説明する。

図７と図８は対応している。図８（ａ）において、ノードが４つと仮定し、ノード（Ｎ１）からノード（Ｎ２）への情報への問合せＲ１、ノード（Ｎ２）からノード（Ｎ３）への情報への問合せＲ２、ノード（Ｎ３）からノード（Ｎ４）への情報への問合せＲ３、ノード（Ｎ４）からノード（Ｎ１）への情報への問合せＲ４は、対等である。

ノード状態リスト１０と、図７（ｅ）に示す凡例は図６と同じである。
図７（ａ）は４つのノード（Ｎ１〜Ｎ４）が、まだどのノードとも情報を共有していない最初の状態を示す。
図７（ｂ）、図８（ｂ）は、次の状態を示し、ノード（Ｎ１）はノード（Ｎ２）に問い合わせ（所得予定（リクエスト））、ノード（Ｎ２）はノード（Ｎ３）に問い合わせ、ノード（Ｎ３）はノード（Ｎ４）に問い合わせ、ノード（Ｎ１）はノード（Ｎ３）に問い合わせる状態を示す。同時にノード（Ｎ１）はノード（Ｎ４）から被リクエストを受け、ノード（Ｎ２）はノード（Ｎ１）から被リクエストを受け、ノード（Ｎ３）はノード（Ｎ２）から被リクエストを受け、ノード（Ｎ４）はノード（Ｎ３）から被リクエストを受けている。

図７（ｃ）、図８（ｃ）は、更に次の状態を示す。
図７（ｄ）は、ノード（Ｎ１〜Ｎ４）がすべてのノードの情報を取得し、安定状態になったことを示す。問い合わせ（リクエスト）、被リクエストの関係は、図８（ｂ）（ｃ）（ｄ）に示されるように、すべて同じになる。

図８（ａ）から分かるように、この実施の形態によれば、ノード（Ｎ１）から見た場合、ノード（Ｎ２）へ問い合わせて、ノード（Ｎ４）から問合せられる。他のノードも同様に行われる。どのノードからみても問合せる数と問合せられる数は一定になる。
ノード（Ｎ１）にノード（Ｎ４）のード情報が入ってくるときは、ノード（Ｎ２）とノード（Ｎ３）経由で入ってくる。各ノードはＮＴＰで同期が取られており、基本的に同時期に取得したものが入ってくる。一般的には、ノード状態リスト１０に取得したときの時刻も合わせて記録しておき、複数のノード情報が入ってきて状態が異なる場合は、取得時刻の新しい方を採用する。

図９、図１０は、ノード数が増加した場合の情報問い合わせ動作について説明するもので、上限値Ｍを８とし、ノード数が８になった場合について説明する。
図９（ａ）は、ノード数が分割前の状態を表す。８つのノード（Ｎ１〜Ｎ８）が、まだどのノードとも情報を共有していない最初の状態を示す。ノード状態リスト１０が、ノード数がＮ１〜Ｎ８に対応して８個に増えている。

図９（ｂ１）は２つのグループに分割した状態を表す。ノード状態リスト１０は、グループ分けする前の状態を保持する。最初の段階のノード情報の取得はノード（Ｎ１〜Ｎ４）のグループで領域２００の情報を更新し、ノード（Ｎ５〜Ｎ８）のグループで領域３００の情報を更新する。
図９（ｂ２）は、グループ内で一通りノード状態を共有した状態を表す。図９（ｂ１）の状態から図９（ｂ２）の状態へ移行する途中の過程は、ノード（Ｎ１〜Ｎ４）については図7（ａ）から図７（ｄ）と同じである。ノード（Ｎ５〜Ｎ８）についても図7（ａ）から図７（ｄ）をＮ１→Ｎ５、Ｎ２→Ｎ６、Ｎ３→Ｎ７、Ｎ４→Ｎ８と読み替えれば同様とみなせる。ノード状態リスト１０は、領域２００を更新した結果が領域２１０となり、領域３００を更新した結果が領域３１０となる。

図９（ｃ）は、図９（ｂ２）の状態に達した後で、各ノードが別グループのノードに問合せることを表す。
図９（ｃ１）は、問合せる前の状態を表しており、ノード（Ｎ１）はノード（Ｎ５）に、ノード（Ｎ６）はノード（Ｎ２）に問合せていることを表す。ノード（Ｎ２）とノード（Ｎ６）、ノード（Ｎ３）とノード（Ｎ７）、ノード（Ｎ４）とノード（Ｎ８）も同様である。

図９（ｃ２）は問合せた後の状態を表しており、ノード（Ｎ１）はノード（Ｎ５）の持つノード状態リスト１０のノード（Ｎ５〜Ｎ８）の領域２４０の情報を領域２３０から取得したことを表す。同様にノード（Ｎ５）は、ノード（Ｎ１）の持つノード状態リスト１０の（Ｎ１〜Ｎ４）の領域３４０の情報を領域３３０から取得したことを表す。ノード（Ｎ２）とノード（Ｎ６）、ノード（Ｎ３）とノード（Ｎ７）、ノード（Ｎ４）とノード（Ｎ８）も同様である。
これにより、すべてのノードはすべてのノード状態を取得したことになる。以降は、図９（ｂ１）に戻って繰り返していく。

図１０は、図９（ａ）（ｂ１）（ｂ２）（ｃ）（ｃ１）（ｃ２）の問い合わせ関係を図示したものである。図１０（ａ）が図９（ａ）に、図１０（ｂ）が図９（ｂ１）（ｂ２）に、図１０（ｃ）が図９（ｃ１）（ｃ２）にそれぞれ対応する。ノードが一定数を越えた場合に、点線４００で分割して２つのグループに分ける。グループを分けた場合、点線４０１、４０２のように、ノード（Ｎ４→Ｎ６）はノード（Ｎ４→Ｎ１）へ、ノード（Ｎ８→Ｎ１）はノード（Ｎ８→Ｎ５）へつなぎ直しとなる。すなわち、ノード数に応じて複数のグループに分割し、グループ内で一回りしたら別グループのノードに問い合わせる。そして再度同じグループ内で問い合わせる。

なお、いずれかのグループのノード数が８を超えたら更に分割し、３つのグループとなる。自グループ内の問い合わせが完了したら他グループへ問い合わせていくことは、グループ数が増えても同じ原理である。上限値８は限定されるものではない。情報を伝搬する決まったルートは、上述した「１．ノードの登録」で説明したように順序を決めるが、これに限定されるものではない。

次に、フローチャートを参照して本実施の形態の動作の詳細について説明する。フローチャートは各ノードのＣＰＵが実行するものである。
図１はノードの登録についてのフローチャートである。

ステップＳ１０１は、グループへノードを登録する処理で、例えば図４のグループＡにノードを登録する処理であり、登録された順にノードに識別番号を付与していく。識別情報はデータメモリ５１〜５４に記憶される。この処理は、ＮｏＳＱＬ（Not only SQL）によって複数のサーバ（ノード）を使って１つのデータベースを作る手法である。

続くステップＳ１０２は、ノード状態リストとして、図６のノード状態リスト１０に相当するもので、ステップＳ１０１で登録されたノードの状態を表す配列として保存し、識別番号に該当する配列を追加する。
続くステップＳ１０３は、変更されたノード状態リストをグループに所属するノードに配信して、すべてのノードで共有する。すべてのノードでノード状態リストを共有したら終了（ステップＳ１０４）となる。
以上がノードの登録となる。

図２は、ノードの情報共有処理（リクエスト送信）についてのフローチャートである。リクエストは定期的に繰り返すものとする。

ステップＳ２０１は、リクエスト用データを作成するために、自分の持つノード状態リスト情報を取得する。
続くステップＳ２０２は、自ノード（Node［Ｎ］）からリクエスト先ノード（Node［Ｎ＋１］）にリクエストを送信する。
続くステップＳ２０３は、リクエスト先からのレスポンスを待ち、レスポンスが返ってきたらステップＳ２０４へ、レスポンスが返ってこなければステップＳ２１２へそれぞれ進む。
ステップＳ２０４は、レスポンスが返ってきた際の結果が、ＯＫならばステップＳ２０５へ、ＮＧならばステップＳ２０７へ、それぞれ進む。

ステップＳ２０５は、レスポンスが正常としてステップＳ２０６へ進む。
ステップＳ２０６は、受信したレスポンスのノード状態リストのデータで更新された部分のデータを自分のノード状態リストに上書き保存して終了する（ステップＳ２１５）。

ステップＳ２０７は、レスポンスが異常としてステップＳ２０８へ進む。
ステップＳ２０８は、受信したレスポンスのノード状態リストのデータでリクエスト先ノードの部分をＮＧとし、他のデータのノード状態リストには更新しない。そしてステップＳ２０９へ進む。
ステップＳ２０９は、連続して失敗した回数のカウンターＥを更新して、ステップＳ２１０へ進む。
ステップＳ２１０は、連続して失敗した回数のカウンター値Ｅが、連続して失敗した回数の上限値Ｋ以上の場合はステップＳ２１１へ、より小さい場合は次の処理（ステップＳ２１５）へ、それぞれ進む。

ステップＳ２１１は、連続して失敗した回数が連続して失敗した回数の上限値以上の場合はノード状態リストからそのリクエスト先のノードを除外して、次のノードを設定する処理である。設定後は終了する（ステップＳ２１５）。

ステップＳ２０３でレスポンス無しのときは、レスポンスが（一定時間）返ってこないのでノード停止として（ステップＳ２１２）、ステップＳ２１３へ進む。
ステップＳ２１３は、レスポンスが受信できないのでリクエスト先ノードの部分を停止とし、他のデータのノード状態リストには更新しない。
続くステップＳ２１４は、連続して失敗した回数のカウンターを更新する。そしてステップＳ２１０へ進む。
以上がノードの情報共有処理（リクエスト送信）となる。

図３は、ノードの情報共有処理（リクエスト受信）についてのフローチャートである。リクエストは待ち受けるものとする。

ステップＳ３０１は、リクエストを監視して待ち受ける処理で、リクエストを受信した場合はステップＳ３０２へ、受信しない場合はステップＳ３０１へ戻る。
ステップＳ３０２は、リクエストに付加されたノード状態リスト情報を取得する。
続くステップＳ３０３は、自ノードのチェックをして状態取得する。
続くステップＳ３０４は、ステップＳ３０２、ステップＳ３０３で取得したノード状態リスト情報並びに自ノードの状態についてのエラーチェックを行い、問題なければＯＫとしてステップＳ３０５へ進み、問題があればＮＧとしてステップＳ３０６へ進む。
ステップＳ３０５は、チェック結果がＯＫであることをノード状態リストへ書き込み、ステップＳ３０６はチェック結果がＮＧであることをノード状態リストへ書き込む。

続くステップＳ３０７は、保存していたノード状態リストからステップＳ３０４の結果を反映してレスポンス作成する。
続くステップＳ３０８は、ステップＳ３０７で作成したレスポンスを送信する。
続くステップＳ３０９は、ステップＳ３０２で取得したノード状態リスト情報のデータで更新された部分のデータを自分のノード状態リストに上書き保存して終了する（ステップＳ３１０）。
以上がノードの情報共有処理（リクエスト受信）となる。

このようにして、複数のノードで構成されるピアツーピア型のデータベースにおいて情報の共有化を実現する。

＜実施の形態の効果＞
本実施の形態によれば、決まったルートで情報を伝播させていくことにより、ノード数が増加してもネットワークの負荷を増やさないことと、ノード数が増えた場合はグループを分割することで一定の時間内に情報共有をすることができる。
また、特定のルートで情報交換を行うことで一部のノードに負荷がかからない。あるいは、すべてのノードに対して一定間隔で情報を共有できる。
更に、リクエストの際リクエスト側からもノード情報を送ることで双方向の情報収集ができて、かつそれぞれの蓄積した情報を共有できる。

以上、この発明の実施形態について説明したが、この発明はこれらに限定されるものではなく、特許請求の範囲に記載された発明とその均等の範囲を含むものである。
以下に、本願出願時の特許請求の範囲を付記する。
＜付記＞

［請求項１］
複数のノードでグループが構成されるピアツーピア型の分散データベースにおいて、
個々のノードが他ノードの所定の情報を問い合わせて取得して共有する共有手段と、
決まったルートで前記情報を伝播させていく伝搬手段と、
ノード数が所定以上増えた場合は前記グループを分割する分割手段と
を有することを特徴とする分散データベース。
［請求項２］
前記分割手段は、前記グループ内で前記情報が伝搬したら、別のグループのノードに前記情報を問い合わせることを特徴とする請求項１記載の分散データベース。
［請求項３］
前記共有手段が問い合わせる前記情報は、ノードの死活情報であることを特徴とする請求項１又は２記載の分散データベース。
［請求項４］
前記共有手段がノードの死活情報問い合わせた結果、不活ノードと判定されたノードは前記グループから排除することを特徴とする請求項３記載の分散データベース。
［請求項５］
前記共有手段が問い合わせる前記情報は、ノードのメモリ残量情報又はノードのパフォーマンス情報であることを特徴とする請求項１又は２記載の分散データベース。
［請求項６］
複数のノードで構成されるピアツーピア型の分散データベースのデータ共有方法であって、
複数のノードをグループに登録する第１工程と、
個々のノードが他ノードの情報を取得して前記グループで共有するために前記グループ内で決まったルートで情報を伝播させていく第２工程と、
ノード数が所定以上増えた場合は前記グループを分割する第３工程と
を実行することを特徴とする方法。
［請求項７］
前記第１工程は、以下の工程を含むことを特徴とする請求項６記載の方法。
（１）ノードを前記グループに登録する工程であって、全ノード数をＮとして登録する際に、グループ内で識別するための識別番号を指定する工程、
（２）各ノードは全ノードの所定の情報を保存するリストを持ち、ノードのグループ登録時に登録された順序でリストを更新し、前記順序で最後にあたるノードは前記順序の先頭から前記所定の情報を取得してリング状にする工程。
（３）前記更新されたリストをすべてのノードに配信する工程。
［請求項８］
前記第２工程は、以下の工程を含むことを特徴とする請求項６記載の方法。
（４）ノード［Ｎ］は、ノード［Ｎ＋１］の情報を取得するリクエストを送信し、該ノード［Ｎ］の持つリストも合わせて送信する工程、
（５）ノード［Ｎ＋１］は、ノード［Ｎ］から取得したリストに、ノード［Ｎ＋１］の持つリストの情報を追記してレスポンスとして返信する工程、
（６）ノード［Ｎ］は、ノード［Ｎ＋１］から取得した情報を自分のリストに追記する工程、
（７）ノード［Ｎ］は、ノード［Ｎ−１］からのリクエストに応じ、前記工程（５）を実行しレスポンスを返信する工程、
（８）前記工程（４）に戻って繰り返す工程。
［請求項９］
前記第３工程は、以下の工程を含むことを特徴とする請求項６記載の方法。
（９） ノード数Nは、ノードを追加していき、ノード数の上限値Ｍになったとき、ノード［１］からノード［Ｍ／２］を第１グループ、ノード［Ｍ／２＋１］からノード［Ｍ］を第２グループとして分割する工程、
（１０）ノード［Ｍ／２］はノード［１］と接続し、ノード［Ｍ］はノード［Ｍ／２＋１］と接続する工程、
（１１）各グループのノードが情報共有できたら、別グループのノードに接続先を変更する工程。
［請求項１０］
前記第２工程は、以下の工程を含むことを特徴とする請求項６記載の方法。
（１２）K回以上レスポンスが返ってこないか、正常ではないレスポンスが返ってきた場合のノード［ｘ］は、次の順序のノードに変更して、リクエストを行う工程。
［請求項１１］
複数のノードで構成されるピアツーピア型の分散データベースの情報を共有するためのプログラムであって、
ノード［Ｎ］のコンピュータに、
複数のノードをグループに登録する登録工程と、
ノード［Ｎ＋１］の情報を取得するリクエストを送信し、該ノード［Ｎ］の持つノードの状態を示すリストも合わせて送信する送信工程と、
ノード［Ｎ＋１］から、ノード［Ｎ］から取得したリストに、ノード［Ｎ＋１］の持つリストの情報を追記したレスポンスを受信する受信工程と、
ノード［Ｎ＋１］から取得した情報を自分のリストに追記する追記工程と、
ノード［Ｎ−１］からのリクエストに応じ、ノード［Ｎ−１］から取得したリストに、当該ノード［Ｎ］の持つリストの情報を追記してレスポンスとしてノード［Ｎ−１］に返信する返信工程と、
ノード数が所定以上増えた場合は前記グループを分割する分割工程と
を実行させることを特徴とするプログラム。
［請求項１２］
複数のノードでグループが構成されるピアツーピア型の分散データベースにおいて、
請求項１１記載のプログラムを実行するコンピュータを備えることを特徴とする装置。

１０、１１、１２、１３、１４ ノード状態リスト
２１、２２、２３、３４ リクエスト送信用ノード情報処理プログラム
３１、３２、３３、３４ リクエスト受信用ノード情報処理プログラム
４１、４２、４３、４４ ＣＰＵ
５１、５２、５３、５４ データメモリ
１００ ネットワーク
Ａ１〜Ａ４ サーバ
Ｎ１〜Ｎ８ ノード
Ａ、Ｂ グループ

Claims (10)

1. 複数のノードでグループが構成されるピアツーピア型の分散データベースにおいて、
   前記各ノードはノード状態リストを有し、
   個々のノードが他ノードの前記ノード状態リストの所定の情報を問い合わせて取得して共有する共有手段と、
   決まったルートで前記情報を伝播させていく伝搬手段と、
   ノードのグループ登録時に登録された順序で前記ノード状態リストを更新し、前記順序で最後にあたるノードは前記順序の先頭から前記所定の情報を取得してノードをリング状に接続する手段と、
   ノード数が上限値Ｍになったとき、ノード［１］からノード［Ｍ／２］を第１グループ、ノード［Ｍ／２＋１］からノード［Ｍ］を第２グループとして分割し、ノード［Ｍ／２］はノード［１］と接続し、ノード［Ｍ］はノード［Ｍ／２＋１］と接続することによって前記グループを分割する分割手段と、
   各グループのノードがグループ内で情報共有したら、別グループのノードに接続先を変更する手段と、
   を有することを特徴とする分散データベース。
2. 前記共有手段が問い合わせる前記情報は、ノードの死活情報であることを特徴とする請求項１記載の分散データベース。
3. 前記共有手段がノードの死活情報問い合わせた結果、不活ノードと判定されたノードは前記グループから排除することを特徴とする請求項２記載の分散データベース。
4. 前記共有手段が問い合わせる前記情報は、ノードのメモリ残量情報又はノードのパフォーマンス情報であることを特徴とする請求項１記載の分散データベース。
5. ノード状態リストを有する複数のノードで構成されるピアツーピア型の分散データベースのデータ共有方法であって、前記ノードのＣＰＵが、
   複数のノードをグループに登録する第１工程と、
   個々のノードが前記他ノードのノード状態リストから所定の情報を取得して前記グループで共有するために、前記グループ内で決まったルートで情報を伝播させていく第２工程と、
   ノード数が所定以上増えた場合は前記グループを分割する第３工程と、
   を含み、
   前記第３工程は、
   （９）ノード数が上限値Ｍになったとき、ノード［１］からノード［Ｍ／２］を第１グループ、ノード［Ｍ／２＋１］からノード［Ｍ］を第２グループとして分割する工程、
   （１０）ノード［Ｍ／２］はノード［１］と接続し、ノード［Ｍ］はノード［Ｍ／２＋１］と接続する工程、
   （１１）各グループのノードがグループ内で情報共有したら、別グループのノードに接続先を変更する工程、
   を実行することを特徴とする方法。
6. 前記第１工程は、以下の工程を含むことを特徴とする請求項５記載の方法。
   （１）ノードを前記グループに登録する工程であって、全ノード数をＮとして登録する際に、グループ内で識別するための識別番号を指定する工程、
   （２）各ノードの前記ノード状態リストは全ノードの所定の情報を保存し、ノードのグループ登録時に登録された順序で前記リストを更新し、前記順序で最後にあたるノードは前記順序の先頭から前記所定の情報を取得して複数のノードを前記ノードのグループ登録時に登録された順序で前記ノードをリング状に接続する工程、
   （３）前記更新されたリストをすべてのノードに配信する工程。
7. 前記第２工程は、以下の工程を含むことを特徴とする請求項５記載の方法。
   （４）ノード［Ｎ］は、ノード［Ｎ＋１］の情報を取得するリクエストを送信し、該ノード［Ｎ］の持つリストも合わせて送信する工程、
   （５）ノード［Ｎ＋１］は、ノード［Ｎ］から取得したリストに、ノード［Ｎ＋１］の持つリストの情報を追記してレスポンスとして返信する工程、
   （６）ノード［Ｎ］は、ノード［Ｎ＋１］から取得した情報を自分のリストに追記する工程、
   （７）ノード［Ｎ］は、ノード［Ｎ−１］からのリクエストに応じ、ノード［Ｎ−１］から取得したリストに、ノード［Ｎ］の持つリストの情報を追記してレスポンスとして返信する工程、
   （８）前記工程（４）に戻って繰り返す工程。
8. 前記第２工程は、以下の工程を含むことを特徴とする請求項５記載の方法。
   （１２）ノード［ｘ］からＫ回以上レスポンスが返ってこないか、正常ではないレスポンスが返ってきた場合は、ノード［ｘ−１］は、次の順序のノード［ｘ＋１］へリクエストを行う工程。
9. 複数のノードで構成されるピアツーピア型の分散データベースの情報を共有するためのプログラムであって、
   ノード［Ｎ］のＣＰＵに、
   複数のノードをグループに登録する登録工程と、
   ノード［Ｎ＋１］の情報を取得するリクエストを送信し、該ノード［Ｎ］の持つノードの状態を示すリストも合わせて送信する送信工程と、
   ノード［Ｎ＋１］から、ノード［Ｎ］から取得したリストに、ノード［Ｎ＋１］の持つリストの情報を追記したレスポンスを受信する受信工程と、
   ノード［Ｎ＋１］から取得した情報を自分のリストに追記する追記工程と、
   ノード［Ｎ−１］からのリクエストに応じ、ノード［Ｎ−１］から取得したリストに、当該ノード［Ｎ］の持つリストの情報を追記してレスポンスとしてノード［Ｎ−１］に返信する返信工程と、
   ノード数が上限値Ｍになったとき、ノード［１］からノード［Ｍ／２］を第１グループ、ノード［Ｍ／２＋１］からノード［Ｍ］を第２グループとして分割する工程と、
   各グループのノードがグループ内で情報共有したら、別グループのノードに接続先を変更する工程と、
   を実行させることを特徴とするプログラム。
10. 複数のノードでグループが構成されるピアツーピア型の分散データベースにおいて、
    請求項９記載のプログラムを実行するコンピュータを備えることを特徴とする装置。

Images