(57)【特許請求の範囲】
【請求項１】
共通の大きさの担当範囲Ｈにあるデータｘをそれぞれ保持する複数のノードで構成される分散ハッシュテーブルにおいて、担当範囲Ｈを変化させてデータの配信要求を各ノードに分散させる配信要求分散方法であって、
１つのノードが一定の時間に他のノードにされる配信要求の数を調査するデータ配信数調査ステップと、
前記１つのノードが配信要求を受信したときに、
前記データ配信数調査ステップで取得した前記配信要求の数に基づいて、データｘが配信要求される確率密度分布である配信要求関数ｆ（ｘ）を決定し、データｘを保持するノード数の確率密度分布である包含関数ｇ（ｘ、Ｈ）とｆ（ｘ）との二乗誤差が所望のデータｘの範囲において最小となるように担当範囲Ｈを決定する担当範囲決定ステップと、
を行うことを特徴とする配信要求分散方法。
【請求項２】
分散ハッシュテーブルを構成し、共通の大きさの担当範囲Ｈにあるデータｘを保持するノードであって、
一定の時間に他のノードにされる配信要求の数を調査するデータ配信数調査モジュールと、
配信要求を受信したときに、
前記データ配信数調査モジュールが取得した前記配信要求の数に基づいて、データｘが配信要求される確率密度分布である配信要求関数ｆ（ｘ）を決定し、データｘを保持するノード数の確率密度分布である包含関数ｇ（ｘ、Ｈ）とｆ（ｘ）との二乗誤差が所望のデータｘの範囲において最小となるように担当範囲Ｈを決定する担当範囲決定モジュールと、
を備えることを特徴とするノード。
【請求項３】
コンピュータに請求項１に記載の配信要求分散方法を実行させるためのプログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、複数のノード（ＰＣ）間で構成される分散ハッシュテーブルおいて、膨大なデータを分散管理し配信する際に特定のノードに配信要求が偏らないように配信要求を分散させる配信要求分散方法、ノード、及びプログラムに関する。
【背景技術】
【０００２】
分散ハッシュテーブルとは、ひとつの論理的なＩＤ空間を複数のノードで分担し管理する技術であり、Ｋｅｙ  Ｖａｌｕｅ  Ｓｔｏｒｅ等の分散データベースにて利用されている。分散ハッシュテーブルにデータを配置する場合、当該データの名前をキーとし、当該キーを担当するノードに対して当該データを配置する。データを分散ハッシュテーブルから取得する場合、取得したいデータの名前をキーとし、分散ハッシュテーブル上から当該キーを担当するノードを探し、データを取得する。しかしながら、特定のデータもしくはデータ群に配信要求が集中する場合、当該データ（群）を管理するノードの配信負荷が高くなるという問題が存在している。
【０００３】
本問題に対して、既存手法１（例えば、非特許文献１を参照。）は、特定のデータ群に配信要求が集中する場合、配信要求が少ないノードを当該データ群のＩＤ空間の一部を担当するように、当該ノードを移動させる。図１では、ノードＢ，Ｃに配信要求が集中している分散ハッシュテーブルを既存手法１を用いて配信要求を平滑化している。具体的には、配信要求数が少ないノードＤが配信要求数の多いＢの担当範囲の一部：［１５，２０）を請け負うことで、配信要求数の平滑化を行う。この時、Ｄは自身の担当範囲を隣接するノードＣに対して受け渡す。既存手法２（例えば、非特許文献２を参照。）では、各ノードが配信要求数の上限を超えた場合、自身の担当範囲を隣接するノードに対して譲渡する。図２では、ノードＢ，Ｃが担当範囲を狭め、Ａ，Ｄは担当範囲を広めることで、配信要求数の平滑化を行っている。
【先行技術文献】
【非特許文献】
【０００４】
【非特許文献１】Ａ．  Ｒ．  Ｂｈａｒａｍｂｅ，  Ｍ．  Ａｇｒａｗａｌ，  ａｎｄ  Ｓ．  Ｓｅｓｈａｎ，  “Ｍｅｒｃｕｒｙ：  ｓｕｐｐｏｒｔｉｎｇ  ｓｃａｌａｂｌｅ  ｍｕｌｔｉ−ａｔｔｒｉｂｕｔｅ  ｒａｎｇｅ  ｑｕｅｒｉｅｓ”，ｐｐ．  ３５３−３６６，  ２００４．
【非特許文献２】Ｉ．  Ｋｏｎｓｔａｎｔｉｎｏｕ，  Ｄ．  Ｔｓｏｕｍａｋｏｓ，  ａｎｄ  Ｎ．  Ｋｏｚｉｒｉｓ，  “Ｆａｓｔ  ａｎｄ  ｃｏｓｔ−ｅｆｆｅｃｔｉｖｅ  ｏｎｌｉｎｅ  ｌｏａｄ−ｂａｌａｎｃｉｎｇ  ｉｎ  ｄｉｓｔｒｉｂｕｔｅｄ  ｒａｎｇｅ−ｑｕｅｒｉａｂｌｅ  ｓｙｓｔｅｍｓ”，  ＩＥＥＥ  Ｔｒａｎｓａｃｔｉｏｎｓ  ｏｎ  Ｐａｒａｌｌｅｌ  ａｎｄ  Ｄｉｓｔｒｉｂｕｔｅｄ  Ｓｙｓｔｅｍｓ，  ｖｏｌ．  ２２，  ｎｏ．  ８，  ｐｐ．  １３５０−１３６４，  ２０１１．
【非特許文献３】Ｍ．  Ｈｅｆｅｅｄａ  ａｎｄ  Ｏ．  Ｓａｌｅｈ，  “Ｔｒａｆｆｉｃ  ｍｏｄｅｌｉｎｇ  ａｎｄ  ｐｒｏｐｏｒｔｉｏｎａｌ  ｐａｒｔｉａｌ  ｃａｃｈｉｎｇ  ｆｏｒ  ｐｅｅｒ−ｔｏ−ｐｅｅｒ  ｓｙｓｔｅｍｓ”，  ＩＥＥＥ／ＡＣＭ  Ｔｒａｎｓａｃｔｉｏｎｓ  ｏｎ  Ｎｅｔｗｏｒｋｉｎｇ，  ｖｏｌ．  １６，  ｎｏ．  ６，  ｐｐ．  １４４７−１４６０，  ２００８．
【発明の概要】
【発明が解決しようとする課題】
【０００５】
しかし、既存手法１，２は逐次的かつ非同期で行うため、配信要求数が平滑化されるまでは何度もノードの担当範囲が切り替わり、ノード間でのデータ移動が多発することになる。つまり、既存手法１，２には、ノードの担当範囲の切替わりに伴うノード間でのデータ移動が多発するという課題があった。
【０００６】
そこで、本発明は、上記課題を解決すべく、頻繁なデータの移動を抑制しつつ、各ノード間のデータ配信数を平準化することができる配信要求分散方法、ノード、及びプログラムを提供することを目的とする。
【課題を解決するための手段】
【０００７】
そこで、本発明は、ある時間単位で各ノードに対する配信要求数を計測し、当該結果の元、要求数が多いノードが管理するデータを当該ノードと隣接する複数のノードで分散して管理することとした。
【０００８】
具体的には、本発明に係る配信要求分散方法は、共通の大きさの担当範囲Ｈにあるデータｘをそれぞれ保持する複数のノードで構成される分散ハッシュテーブルにおいて、担当範囲Ｈを変化させてデータの配信要求を各ノードに分散させる配信要求分散方法であって、
１つのノードが一定の時間に他のノードにされる配信要求の数を調査するデータ配信数調査ステップと、
前記１つのノードが配信要求を受信したときに、
前記データ配信数調査ステップで取得した前記配信要求の数に基づいて、データｘが配信要求される確率密度分布である配信要求関数ｆ（ｘ）を決定し、データｘを保持するノード数の確率密度分布である包含関数ｇ（ｘ、Ｈ）とｆ（ｘ）との二乗誤差が所望のデータｘの範囲において最小となるように担当範囲Ｈを決定する担当範囲決定ステップと、
を行うことを特徴とする。
【０００９】
また、本発明に係るノードは、分散ハッシュテーブルを構成し、共通の大きさの担当範囲Ｈにあるデータｘを保持するノードであって、
一定の時間に他のノードにされる配信要求の数を調査するデータ配信数調査モジュールと、
配信要求を受信したときに、
前記データ配信数調査モジュールが取得した前記配信要求の数に基づいて、データｘが配信要求される確率密度分布である配信要求関数ｆ（ｘ）を決定し、データｘを保持するノード数の確率密度分布である包含関数ｇ（ｘ、Ｈ）とｆ（ｘ）との二乗誤差が所望のデータｘの範囲において最小となるように担当範囲Ｈを決定する担当範囲決定モジュールと、
を備える。
【００１０】
本発明は、各ノードの配信要求数から負荷が最も平滑化できるような各ノードの担当範囲を一意に決定する。具体的には、特定の時間間隔にて配信要求数が多いノードのデータは隣接するノード間で共有することにする（図３を参照。）。これにより、配信要求数が平滑化されるまで、担当範囲が切りかわることによる頻繁なデータ転送を抑制することができる。
【００１１】
さらに、本発明に係るプログラムは、コンピュータに前記配信要求分散方法を実行させるためのプログラムである。
【００１２】
本発明に係る配信要求分散方法は、コンピュータとプログラムによっても実現でき、プログラムを記録媒体に記録することも、ネットワークを通して提供することも可能である。
【発明の効果】
【００１３】
本発明は、頻繁なデータの移動を抑制しつつ、各ノード間のデータ配信数を平準化することができる配信要求分散方法、ノード、及びプログラムを提供することができる。
【図面の簡単な説明】
【００１４】
【図１】従来の配信要求分散方法を説明する図である。（ａ）は担当範囲変更前であり、（ｂ）は担当範囲変更後である。
【図２】従来の配信要求分散方法を説明する図である。（ａ）は担当範囲変更前であり、（ｂ）は担当範囲変更後である。
【図３】本発明に係る配信要求分散方法を説明する図である。
【図４】本発明に係るノードを説明する図である。
【図５】本発明に係るノードの動作を説明する図である。
【図６】本発明に係る配信要求分散方法を説明する図である。
【図７】本発明に係る配信要求分散方法の実験結果を説明する図である。
【図８】本発明に係る配信要求分散方法の実験結果を説明する図である。
【図９】本発明に係る配信要求分散方法と従来の配信要求分散方法とを比較するシミュレーション結果である。
【図１０】本発明に係る配信要求分散方法と従来の配信要求分散方法とを比較するシミュレーション結果である。
【発明を実施するための形態】
【００１５】
添付の図面を参照して本願発明の実施形態を説明する。以下に説明する実施形態は本願発明の実施の例であり、本願発明は、以下の実施形態に制限されるものではない。なお、本明細書及び図面において符号が同じ構成要素は、相互に同一のものを示すものとする。また、以下の説明で配信要求数と配信数とは同数であるとする。
【００１６】
図４は、本実施形態のノード１００を説明する図である。
ノード１００は、分散ハッシュテーブルを構成し、共通の大きさの担当範囲Ｈにあるデータｘを保持するノードであって、
一定の時間に他のノードにされる配信要求の数を調査するデータ配信数調査モジュール３０と、
配信要求を受信したときに、
データ配信数調査モジュール３０が取得した前記配信要求の数に基づいて、データｘが配信要求される確率密度分布である配信要求関数ｆ（ｘ）を決定し、データｘを保持するノード数の確率密度分布である包含関数ｇ（ｘ、Ｈ）とｆ（ｘ）との二乗誤差が所望のデータｘの範囲において最小となるように担当範囲Ｈを決定する担当範囲決定モジュール４０と、
を備える。
ノード１００は、さらに、データベース１０と経路制御モジュール２０を備える。
【００１７】
図５は、これらのモジュールの動作例である。
経路制御モジュール２０、データベース１０、およびデータ配信数調査モジュール３０は既存手法と同様の機能である。経路制御モジュール２０は、一般的な構造化オーバレイが持つべきルーティングのモジュールとなっており、ネットワーク上からデータ等を探索／配信する機能を持つ。
【００１８】
データベース１０は、ノードの担当範囲、経路情報（他のノードのＩＰアドレスとＩＤ）、他のノードの配信要求数等を保存している。データベース１０も一般的な構造化オーバレイの必要機能となっている。
【００１９】
データ配信数調査モジュール３０は、既存手法１で提案されている手法を用いて、ネットワーク上の他のノードの配信数を一定時間間隔で調査し（ステップＳ０１）、データベース１０に書き込む（ステップＳ０３）。また、データ配信数調査モジュール３０は、経路制御モジュール２０に対してされた自身への配信要求を受信し（ステップＳ０２）、データベース１０に書き込む（ステップＳ０３）。データベース１０は、配信要求が更新されたことを担当範囲決定モジュール４０に通知する（ステップＳ０４）。担当範囲決定モジュール４０は、他のノード及び自身への配信要求数の調査結果を用いて、自身の担当範囲を決定し（ステップＳ０５）、データベース１０が保持する担当範囲を更新する（ステップＳ０６）。
【００２０】
続いて、担当範囲を決定する手法を説明するが、既存手法と異なる手法は、担当範囲決定モジュール４０でなされるため、以下では担当範囲決定モジュール４０に関する説明を行う。
【００２１】
各ノードはＩＤを持ち、ノードｉ（＞０）のＩＤをＸｉとし、ＩＤ空間上、Ｘｉより大きくもっともＩＤの距離が近いノードをノードｉのＳｕｃｃｅｓｓｏｒと呼び、当該ノードのＩＤをｓｕｃｉとする。この時、ＩＤ空間上のノードｉの担当範囲は［Ｘｉ，ｓｕｃｉ）とする。
【００２２】
本実施形態では、配信要求数が高いノードに対して、多くのノードの担当範囲を広げ、担当範囲を重複させることで、配信数の増加による負荷を分散させる。広げられた担当範囲をＨとすると、ノードの担当範囲は、［Ｘｉ，Ｈ＋Ｘｉ）となる（ただし、ｓｕｃｉ≦Ｈ＋Ｘｉ）。ここで、担当範囲Ｈは全てのノードで同じ値である。
【００２３】
担当範囲Ｈは、各データの配信数の確率密度分布と各データがどれだけのノードの担当範囲に含まれているかを示す確率密度分布との距離を最小化するように決定する。これは、配信要求数が高いノードほど多くのノードに対してデータを多く複製する際の最適な複製数を決定することと同義である。本最小化問題の概要を図６に示す。
【００２４】
ここで、データ配信数調査モジュール３０が、既存手法１を用い、他のノードの配信数を一定間隔で調査した結果、Ｌ個のデータの配信数を取得できたとする。データｘの配信要求数をＬｘとすると、各ノードの配信数の確率密度分布ｆ（ｘ）は、
【数１】
0006353395.tif 000002
と定義できる。
【００２５】
また、データｘがどれだけのノードの担当範囲に含まれているかを示す確率密度分布ｇ（ｘ，Ｈ）は、
【数２】
0006353395.tif 000003
と定義する。Ｎは全ノード数である。
【００２６】
ここで、
【数３】
0006353395.tif 000004
は、ノードｊの担当範囲にデータｘが含まれていれば１となり、そうでなければ０となるカーネル関数となる関数である。本実施形態では
【数４】
0006353395.tif 000005
と定義する。
【００２７】
そして、
【数５】
0006353395.tif 000006
で表現される両確率密度分布の二乗誤差を最小にするＨを求める。但し、Ｑはデータ配信数調査モジュールにて得られた各データの配信数の集合（具体的には、「所定の時間内に配信されたｘ＝ｊのデータ数」であり、「Ｌ個のデータの配信要求数」）である。
【００２８】
Ｈの値域はＩＤ空間の大きさに依存し、一般的に２１６０程度の大きさとなる。そのため、線形探索にてＨを計算することは難しいため、当該二乗誤差の関数を凸関数と見立て、Ｈを二分探索にて求め、ノードｉは自身の担当範囲を［Ｘｉ，Ｈ＋Ｘｉ）と設定し、データベースの担当範囲を更新する。
【００２９】
複数のノードの担当範囲にまたがって管理されるデータに対する配信要求は、当該ノード群内からランダムに選ばれたノードが受信し、要求元に配信する。
【００３０】
（効果）
既存手法１，２との比較実験にて、本実施形態の効果を定量化する。実験パラメータは図９の通りである。なお、各ノードに対するデータ数は一様であり、各ノードのＩＤと各データに対する配信要求数は表２で示す各Ｍａｎｄｅｌｂｒｏｔ−Ｚｉｐｆ  ｄｉｓｔｒｉｂｕｔｉｏｎ（非特許文献３）の値（ｑ，α）に依存するものとする。これらのパラメータを用いて、各ノードは、自身の配信数を１０，０００になるよう、各手法を用いて配信数を平滑化する。
【００３１】
図７に各手法を用いて配信要求数の平滑化を行った後のデータの最大配信数を示す。本実施形態における最大配信数は、他の手法よりも低い値になっていることがわかる。図８にデータの総転送数を示す。既存手法２では最大配信数を平滑化するために本実施形態の８倍程度のデータを転送しなければならない。また既存手法１では、本実施形態の３倍程度のデータ転送を行わなければならない。以上により、本実施形態は少ないデータ転送（複製配置）によって、データ配信数を平滑化できることが分かる。
【符号の説明】
【００３２】
１０：データベース
２０：経路制御モジュール
３０：データ配信数調査モジュール
４０：担当範囲決定モジュール
１００：ノード
【図１】
0006353395.tif 000007
【図２】
0006353395.tif 000008
【図３】
0006353395.tif 000009
【図４】
0006353395.tif 000010
【図５】
0006353395.tif 000011
【図６】
0006353395.tif 000012
【図７】
0006353395.tif 000013
【図８】
0006353395.tif 000014
【図９】
0006353395.tif 000015
【図１０】
0006353395.tif 000016