(57)【要約】【課題】限られた記憶容量でデータ取得要求に迅速に対応する。【解決手段】記憶装置に記憶した機器の情報に関するインデックス情報をテーブルに記憶し、所定距離内の中継器に、インデックス情報を通知するインデックス管理部と、機器の情報の取得要求を受けたときに取得要求を受けた機器の情報又は該機器の情報の格納場所情報を返信する応答部と、前記取得要求を受けたときにインデックス情報毎の取得要求の回数を記憶する第１カウンタを更新し、中継器から通知を受けたときにインデックス情報毎の該通知の回数を記憶する第２カウンタを更新し、第１及び第２カウンタの比較により、受けたインデックス情報を、機器の情報の格納場所情報を記憶する第１記憶部又は機器の情報の送信元の中継器の情報を記憶する第２記憶部に記憶するかを判定し、記憶するサブディレクトリ管理部とを有する分散データ管理装置が提供される。【選択図】図３
2018092271.tif 000002
【特許請求の範囲】
【請求項１】
所定の記憶装置に記憶した機器の情報に関するインデックス情報をインデックス管理テーブルに記憶するとともに、所定の距離内にいる中継器に、前記インデックス情報の通知を行うインデックス管理部と、
前記機器の情報の取得要求を受けたときに、該取得要求を受けた前記機器の情報又は該機器の情報の格納場所情報を返信する応答部と、
前記機器の情報の取得要求を受けたときに、前記インデックス情報毎の取得要求の回数を記憶する第１カウンタを更新し、中継器から前記通知を受けたときに、前記インデックス情報毎の該通知の回数を記憶する第２カウンタを更新し、前記第１カウンタと前記第２カウンタとの比較に基づいて、受けた通知の前記インデックス情報を、前記機器の情報の格納場所情報を記憶する第１記憶部に記憶するか、又は、該機器の情報の送信元の中継器の情報を記憶する第２記憶部に記憶するかを判定し、判定結果に基づき記憶するサブディレクトリ管理部と、
を有する分散データ管理装置。
【請求項２】
前記サブディレクトリ管理部は、前記第１カウンタの示す値が前記第２カウンタの示す値よりも小さい場合、受けた通知の前記インデックス情報を前記第２記憶部に記憶すると判定する、
請求項１に記載の分散データ管理装置。
【請求項３】
前記サブディレクトリ管理部は、前記第１カウンタの示す値が前記第２カウンタの示す値以上の場合、受けた通知の前記インデックス情報を前記第１記憶部に記憶すると判定する、
請求項１又は２に記載の分散データ管理装置。
【請求項４】
前記サブディレクトリ管理部は、前記第１カウンタが記憶する取得要求の回数の１／ｎ（ｎ≧２）の頻度で取得要求の回数を記憶する第３カウンタを更新し、
前記サブディレクトリ管理部は、前記第１カウンタと前記第２カウンタと前記第３カウンタとの比較に基づいて、受けた通知の前記インデックス情報を、前記第１記憶部に記憶するか、前記第２記憶部に記憶するか、又は、前記機器の情報の格納場所情報を記憶する第３記憶部に記憶するかを判定し、判定結果に基づき記憶する、
請求項１〜３のいずれか一項に記載の分散データ管理装置。
【請求項５】
前記インデックス管理部は、所定の距離内にいる前記中継器のうち、最近傍の中継器に、前記機器の情報に関するインデックス情報が前記第２記憶部に記憶されている場合であっても、該インデックス情報を前記第１記憶部に記憶するように通知を行い、
前記サブディレクトリ管理部は、最近傍の中継器から前記通知を受けたときに、前記インデックス情報を前記第１記憶部に記憶すると判定する、
請求項１〜４のいずれか一項に記載の分散データ管理装置。
【請求項６】
所定の記憶装置に記憶した機器の情報に関するインデックス情報をインデックス管理テーブルに記憶するとともに、所定の距離内にいる中継器に、前記インデックス情報の通知を行い、
前記機器の情報の取得要求を受けたときに、該取得要求を受けた前記機器の情報又は該機器の情報の格納場所情報を返信し、
前記機器の情報の取得要求を受けたときに、前記インデックス情報毎の取得要求の回数を記憶する第１カウンタを更新し、
中継器から前記通知を受けたときに、前記インデックス情報毎の該通知の回数を記憶する第２カウンタを更新し、
前記第１カウンタと前記第２カウンタとの比較に基づいて、受けた通知の前記インデックス情報を、前記機器の情報の格納場所情報を記憶する第１記憶部に記憶するか、又は、該機器の情報の送信元の中継器の情報を記憶する第２記憶部に記憶するかを判定し、判定結果に基づき記憶する、
処理をコンピュータに実行させるための分散データ管理プログラム。
【請求項７】
所定の記憶装置に記憶した機器の情報に関するインデックス情報をインデックス管理テーブルに記憶するとともに、所定の距離内にいる中継器に、前記インデックス情報の通知を行い、
前記機器の情報の取得要求を受けたときに、該取得要求を受けた前記機器の情報又は該機器の情報の格納場所情報を返信し、
前記機器の情報の取得要求を受けたときに、前記インデックス情報毎の取得要求の回数を記憶する第１カウンタを更新し、
中継器から前記通知を受けたときに、前記インデックス情報毎の該通知の回数を記憶する第２カウンタを更新し、
前記第１カウンタと前記第２カウンタとの比較に基づいて、受けた通知の前記インデックス情報を、前記機器の情報の格納場所情報を記憶する第１記憶部に記憶するか、又は、該機器の情報の送信元の中継器の情報を記憶する第２記憶部に記憶するかを判定し、判定結果に基づき記憶する、
処理をコンピュータが実行する分散データ管理方法。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、分散データ管理装置、分散データ管理プログラム及び分散データ管理方法に関する。
【背景技術】
【０００２】
ＩｏＴ(Internet  of  Things)では、ＰＣ，サーバ、スマートデバイスの他、あらゆるモノがインターネットに接続される。そこで、例えばインターネットに接続された多数のデバイスからの情報を利用する技術が知られている（例えば、特許文献１、２参照）。
【０００３】
例えば、図１に示すように、計測器３ａやスマートフォン３ｂ等の多数のデバイスから取得したデータ（以下、「デバイスデータ」という。）を、インターネット４０に接続されたデータセンタ１０で一括して管理する方法がある。これに対して、デバイスデータをデータセンタ１０ではなく、ユーザが有するデバイス近傍(エッジ)のゲートウェイ２０（以下、「ＧＷ２０」という。）やエッジサーバ等の中継器で分散して記憶することで、通信遅延やネットワークトラヒックを削減することができる。また、データセンタ１０で行っていた処理を、ＧＷ２０で行うことでデータセンタ１０の負荷軽減を図り、システム全体の処理能力を向上させることができる。
【先行技術文献】
【特許文献】
【０００４】
【特許文献１】特開２００６−１９５７８８号公報
【特許文献２】特開２０１１−１１８９５０号公報
【特許文献３】特開平８−３３９３２３号公報
【特許文献４】特開２０１１−１９８１８９号公報
【特許文献５】特開２００１−１６８９２１号公報
【発明の概要】
【発明が解決しようとする課題】
【０００５】
しかしながら、上記システムでは、デバイスデータの取得要求を受け付けたＧＷ２０は、自身が管理するデータ記憶領域に、取得すべきデバイスデータが記憶されていないときには、データセンタ１０にそのデバイスデータの所在を問い合わせることになる。データセンタ１０は、ディレクトリＤＢ１１を参照して、取得要求されたデバイスデータを記憶しているＧＷ２０を特定し、特定したＧＷ２０からデバイスデータの取得要求を受けたＧＷ２０へそのデバイスデータを転送する。このようにデバイスデータの取得要求を受けたＧＷ２０自身が保持していないデバイスデータについては、データセンタ１０への問い合わせやＧＷ２０間でのデータ転送が発生してしまう。
【０００６】
特に、デバイスが固定されている場合と比べて、デバイスが移動している場合、移動に応じて、同一のデバイスから送られるデバイスデータが異なる複数のＧＷ２０に格納されることが生じ易い。このような場合、広域なデバイスデータの格納場所のどこに、取得要求対象のデバイスデータが格納されているかの管理はより煩雑になる。このため、デバイスデータの取得に時間がかかり、かつネットワークの負荷が高くなる。
【０００７】
これに対して、近隣のＧＷ２０に記憶しているデバイスデータを通知して近隣のＧＷ２０間で相互に同一のデバイスデータを保持することが考えられる。しかし、近隣のＧＷ２０同士ですべて同一のデバイスデータを記憶することは、膨大なデータ量を考慮すると極めて困難であり、現実的でない。
【０００８】
そこで、一側面では、本発明は、限られた記憶容量でデータ取得要求に迅速に対応することを目的とする。
【課題を解決するための手段】
【０００９】
一つの案では、所定の記憶装置に記憶した機器の情報に関するインデックス情報をインデックス管理テーブルに記憶するとともに、所定の距離内にいる中継器に、前記インデックス情報の通知を行うインデックス管理部と、前記機器の情報の取得要求を受けたときに、該取得要求を受けた前記機器の情報又は該機器の情報の格納場所情報を返信する応答部と、前記機器の情報の取得要求を受けたときに、前記インデックス情報毎の取得要求の回数を記憶する第１カウンタを更新し、中継器から前記通知を受けたときに、前記インデックス情報毎の該通知の回数を記憶する第２カウンタを更新し、前記第１カウンタと前記第２カウンタとの比較に基づいて、受けた通知の前記インデックス情報を、前記機器の情報の格納場所情報を記憶する第１記憶部に記憶するか、又は、該機器の情報の送信元の中継器の情報を記憶する第２記憶部に記憶するかを判定し、判定結果に基づき記憶するサブディレクトリ管理部と、を有する分散データ管理装置が提供される。
【発明の効果】
【００１０】
一側面によれば、限られた記憶容量でデータ取得要求に迅速に対応することができる。
【図面の簡単な説明】
【００１１】
【図１】一実施形態に係る分散データ管理システムの全体構成の一例を示す図。
【図２】一実施形態に係るディレクトリＤＢの一例を示す図。
【図３】一実施形態に係るＧＷの機能構成の一例を示す図。
【図４】第１実施形態に係るインデックス管理テーブルの一例を示す図。
【図５】一実施形態に係る生データＤＢの一例を示す図。
【図６】一実施形態に係る第２キャッシュ管理テーブルの一例を示す図。
【図７】一実施形態に係る第１キャッシュテーブルの一例を示す図。
【図８】一実施形態に係る第２キャッシュテーブルの一例を示す図。
【図９】一実施形態に係る隣接ＧＷ及び最近傍ＧＷを説明するための図。
【図１０】一実施形態に係る分散データ管理処理の一例を示すフローチャート。
【図１１】第１実施形態に係るデータ取得処理の一例を示すフローチャート。
【図１２】第１実施形態に係るデータ登録処理の一例を示すフローチャート。
【図１３】第１実施形態に係るサブディレクトリ更新処理の一例を示すフローチャート。
【図１４】一実施形態に係る最近傍ＧＷの更新処理の一例を示すフローチャート。
【図１５】一実施形態に係る分散データ管理処理の効果の一例を示す図。
【図１６】第２実施形態に係るインデックス管理テーブルの一例を示す図。
【図１７】第２実施形態に係る第３キャッシュテーブルの一例を示す図。
【図１８】第２実施形態に係るデータ取得処理の一例を示すフローチャート。
【図１９】第２実施形態に係るデータ登録処理の一例を示すフローチャート。
【図２０】第２実施形態に係るサブディレクトリ更新処理の一例を示すフローチャート。
【図２１】一実施形態に係るＧＷのハードウェア構成の一例を示す図。
【発明を実施するための形態】
【００１２】
以下、本発明の実施形態について添付の図面を参照しながら説明する。なお、本明細書及び図面において、実質的に同一の機能構成を有する構成要素については、同一の符号を付することにより重複した説明を省く。
【００１３】
［分散データ管理システムの全体構成］
まず、本発明の一実施形態に係る分散データ管理システム１の構成の一例について、図１を参照しながら説明する。図１は、本実施形態に係る分散データ管理システム１の構成の一例を示す。本実施形態に係る分散データ管理システム１は、計測器３ａやスマートフォン３ｂ等の多数のデバイス（総称して、「デバイス３」と表記する。）から取得したデバイスデータをＧＷ２０配下の記憶領域に格納する。デバイス３は、計測器３ａやスマートフォン３ｂに限らず、温度センサ、湿度センサ等の環境センサ，ビーコン発信器，車，家電等、インターネット４０に接続されるあらゆるセンサが含まれる。また、デバイス３には、固定されたデバイス３だけでなく、移動可能なデバイス３が含まれる。このため、フィールドには、デバイス３から取得したデバイスデータの格納場所が広域に分散している。デバイスデータの一例としては、温度、湿度、輝度、位置，時間，機能等、各種センサから得られる各種データが挙げられる。
【００１４】
デバイス３は、Ｗｉ−Ｆｉ  ｄｉｒｅｃｔ（登録商標）やＢＬＥ（Bluetooth（登録商標）  Low  Energy）によりＧＷ２０に接続されている。ＧＷ２０は、広域に分散するデバイス３からデバイスデータを取得し、記憶する。このように、本実施形態では、デバイスデータは、ＧＷ２０、エッジサーバ、Ｗｉ−Ｆｉ（登録商標）  ＡＰ（アクセスポイント）やモバイル網の基地局等の複数の分散データ管理装置に分散して記憶される。以下では、分散データ管理装置の一例としてＧＷ２０を挙げて説明する。また、複数のＧＷ２０のうちの一つを分散データ管理装置としたとき、所定の距離に存在するＧＷ２０を中継器とする。つまり、すべてのＧＷ２０は、分散データ管理装置になり得る。また、分散データ管理装置から所定の距離に存在する場合には中継器になり得る。
【００１５】
デバイス３は、ＧＷ２０に十分な記憶領域があればＧＷ２０に直接接続される構成であってもよい。本実施形態のように、シンク４を介してＧＷ２０に接続され、シンク４がデバイス３からデバイスデータを受信し、所定のＤＢにデバイスデータを蓄積する構成であってもよい。シンクノードのアドレス（以下、「シンクアドレス」という。）は、シンク４が管理するデバイスデータ（生データ）の格納場所を示す。一のＧＷ２０に接続されるシンク４は複数であってもよい。シンク４はいずれかのＧＷ２０に管理される。デバイス３は、複数のシンク４及びＧＷ２０間を移動することができる。
【００１６】
ＧＷ２０は、インターネット４０によりデータセンタ（ＤＣ：Ｄａｔａ  Ｃｅｎｔｅｒ）１０と接続されている。データセンタ１０の機能は、インターネット４０に接続されているクラウド上のコンピュータにより実現されてもよい。
【００１７】
本実施形態では、データセンタ１０やクラウド上のコンピュータで行っていた処理を，ユーザ近傍(エッジ)のＧＷ２０で行う。また、デバイス３等の端末側で行っていた処理をＧＷ２０で行う。ＧＷ２０に配備される処理は，エンドユーザの要求時または，周期的にデバイスデータを取得したときに実行される。その際、デバイスデータの格納場所の情報が必要となる。ＧＷ２０が保持するインデックス管理テーブル３０に記憶されているインデックス情報は、デバイスデータの格納場所を管理し、処理に使用するデバイスデータを検索するために使用される。
【００１８】
データセンタ１０は、インデックス情報を集約し、ディレクトリＤＢ１１に保持する。ディレクトリＤＢ１１は、処理をどこに配備するか、その配備先を決定するために使用される。図２は、本実施形態に係るディレクトリＤＢ１１の一例を示す。ディレクトリＤＢ１１には、ＧＷ  ＩＤ１１ａ、インデックス１１ｂ、ＧＷアドレス１１ｃ及び更新時間１１ｄが記憶されている。データセンタ１０は、ディレクトリＤＢ１１のインデックス１１ｂ及びＧＷアドレス１１ｃを検索し、必要なデバイスデータがどのＧＷに管理されているかを特定できる。
【００１９】
［機能構成］
次に、本実施形態に係るＧＷ２０の機能構成の一例について、図３を参照しながら説明する。図３は、本実施形態に係るＧＷ２０の機能構成の一例を示す。本実施形態に係るＧＷ２０は、リクエスト応答部２１、インデックス管理部２２、サブディレクトリ管理部２３、記憶部２４、データ取得部２５、インデックス受信部２６及び処理実行部２７を有する。
【００２０】
リクエスト応答部２１は、配備された処理からのデータ取得要求に応じて、取得要求されたデバイスデータを返信する。インデックス管理部２２は、インデックス管理テーブル３０を管理する。
【００２１】
図４は、本実施形態に係るインデックス管理テーブル３０の一例を示す。インデックス管理テーブル３０は、インデックス３０ａ、更新時間３０ｂ及びシンクアドレス３０ｃを記憶する。シンクアドレス３０ｃは、インデックス３０ａに対応するデバイスデータの格納場所の一例である。
【００２２】
本実施形態では、デバイスデータは、生データＤＢ６に記憶され、デバイスデータのインデックス情報とその格納場所は、インデックス管理テーブル３０に記憶されている。所望のデバイスデータがどのシンク４に保存されているかを知るためには、インデックス管理テーブル３０が、所望のデバイスデータのインデックス３０ａに対応したシンクアドレス３０ｃを記憶している必要がある。
【００２３】
図５は、一実施形態に係る生データＤＢ６の一例を示す。生データＤＢ６は、デバイスＩＤ６ａ、デバイス３から取得した実際のデータ（生データ、ｂｏｄｙ）６ｂ及びタイムスタンプ６ｃを記憶する。
【００２４】
例えば、図４に示すように、インデックス管理テーブル３０の一行目に記憶されたインデックス３０ａが、｛ＩＤ⇒Ｄｅｖ−Ａ、ｂｏｄｙ⇒気温｝の場合、このインデックスに対する実際のデータは、図５の生データＤＢ６の例では、デバイスＩＤ６ａが「Ｄｅｖ−Ａ」に対応する一行目と三行目の生データ６ｂ「気温⇒２０℃」及び「気温⇒２１℃」である。
【００２５】
図３に戻り、サブディレクトリ管理部２３は、第１キャッシュ管理部２８及び第２キャッシュ管理部２９を有し、複数のキャッシュテーブルとサブディレクトリとを管理する。記憶部２４には、インデックス管理テーブル３０、第２キャッシュ管理テーブル３１、第１キャッシュテーブル３２及び第２キャッシュテーブル３３が記憶されている。第２キャッシュ管理テーブル３１、第１キャッシュテーブル３２、第２キャッシュテーブル３３は、自身のＧＷ２０とは異なるＧＷ２０が管理するデータまたはデータ格納場所を取得させるための情報を管理するサブディレクトリの一例である。ここで、自身のＧＷ２０とは異なるＧＷ２０とは、自身のＧＷ２０と所定の距離内にいる中継器であり、本実施形態では「隣接ＧＷ２０’」と表記する。
【００２６】
サブディレクトリ管理部２３の第１キャッシュ管理部２８は、第１キャッシュテーブル３２を管理する。第２キャッシュ管理部２９は、第２キャッシュ管理テーブル３１及び第２キャッシュテーブル３３を管理する。
【００２７】
図６は、一実施形態に係る第２キャッシュ管理テーブル３１の一例を示す。ＧＷ２０から隣接ＧＷ２０’に対して第２キャッシュテーブル３３が更新されたことの通知（サブディレクトリ更新の通知）があったとき、隣接ＧＷ２０’の第２キャッシュ管理テーブル３１に第２キャッシュテーブル３３に保持されているデバイスデータに関する情報（インデックス情報）がエントリ登録される。
【００２８】
つまり、第２キャッシュ管理テーブル３１にエントリされている情報は、隣接ＧＷ２０’にて第２キャッシュテーブル３３に保持されているインデックス情報である。よって、第２キャッシュ管理テーブル３１に記憶されているインデックス情報については、第２キャッシュテーブル３３に持っているので第１キャッシュテーブルを更新する必要がないことがわかる。
【００２９】
第２キャッシュ管理テーブル３１は、インデックス３１ａ、データ登録要求数Ｎput３１ｂ、データ取得要求数Ｎreq３１ｃ及び最近傍ＧＷ３１ｄを記憶する。データ登録要求数Ｎput３１ｂには、第２キャッシュテーブル３３への登録要求が何回あったかをカウントする。データ取得要求数Ｎreq３１ｃには、隣接ＧＷ２０’から第２キャッシュテーブル３３へのデータの取得要求が何回あったかをＧＷ毎にカウントする。最近傍ＧＷ３１ｄは、自身のＧＷ２０から最も距離の近いＧＷを記憶する。
【００３０】
図３に戻り、データ取得部２５は、データ取得要求に応じて、シンク４が保持する実際のデータ格納場所である生データＤＢ６からデバイスデータを取得する。
【００３１】
インデックス受信部２６は、シンク４から生データＤＢ６に格納されているデバイスデータのインデックス登録を受信する。処理実行部２７は、配備された処理を実行する。配備される処理の一例としては、監視サービスを行うシステムにおいて、カメラであるデバイス３の撮像データ（デバイスデータの一例）を取得する処理や、取得したデバイスデータを使用して解析する処理等が挙げられる。
【００３２】
［ＧＷ跨ぎのインデックス検索］
サブディレクトリ管理部２３は、インデックス管理テーブル３０に記憶した情報とサブディレクトリの情報とを使用して、自身のＧＷ２０が管理しているインデックス情報以外であって、他のＧＷ２０が管理しているデータ格納場所からデバイスデータを取得するためのインデックス情報の検索（以下、「ＧＷ跨ぎのインデックス検索」という。）を行う。サブディレクトリの情報には、第１キャッシュテーブル３２及び第２キャッシュテーブル３３に記憶されている情報が含まれる。
【００３３】
図７は、本実施形態に係る第１キャッシュテーブル３２の一例を示す。ＧＷ２０から所定の距離内にある隣接ＧＷ２０’に対して行うサブディレクトリの更新要求に応じて、隣接ＧＷ２０’にて管理される第１キャッシュテーブル３２が更新される。第１キャッシュテーブル３２は、機器の情報のインデックス情報と、機器の情報の格納場所情報とを記憶する第１記憶部の一例である。
【００３４】
第１キャッシュテーブル３２は、インデックス３２ａ、データ登録要求数Ｎput３２ｂ、データ取得要求数Ｎreq３２ｃ、シンクアドレス３２ｄ、ＴＴＬ（Time  To  Live）３２ｅ及び更新時間３２ｆを記憶する。第１キャッシュテーブル３２では、インデックス３２ａを検索すると、自身のＧＷ２０の配下ではないが、目的のデバイスデータを保持するシンクアドレス３２ｄ、つまり目的のデバイスデータの格納場所を特定できる。
【００３５】
ＴＴＬ３２ｅは、第１キャッシュテーブル３２に記憶されたインデックス３２ａの有効期限を示す。具体的には、ＴＴＬ３２ｅの値が「０」になると、対応するインデックス３２ａは有効期限切れと判断され、第１キャッシュテーブル３２から削除される。これにより、サブディレクトリ内の不要なインデックス情報を削除することができ、ＧＷ２０側において管理するデータ量が増大することを抑制できる。
【００３６】
また、ＧＷ跨ぎのインデックス検索が行われる際、該当インデックス情報に対応するＴＴＬ３２のインクリメントが実行される。これにより、データ取得要求の多い、人気のあるデバイスデータは、有効期限切れとなり難い、つまり、第１キャッシュテーブル３２から削除され難いようになっている。また、処理がＧＷ２０に再配備されれば、自動的に有効期限切れとなり、第１キャッシュテーブル３２から削除される。
【００３７】
図８は、本実施形態に係る第２キャッシュテーブル３３の一例を示す。ＧＷ２０から所定の距離内にある隣接ＧＷ２０’に対して行うサブディレクトリの更新要求（登録要求）に応じて、データ登録要求数がデータ取得要求数よりも大きくなったとき、隣接ＧＷ２０’にて管理される第２キャッシュテーブル３３が更新される。第２キャッシュテーブル３３は、デバイスデータのインデックス情報と、デバイスデータの送信元の中継器（隣接ＧＷ２０’）の情報を記憶する第２記憶部の一例である。
【００３８】
第２キャッシュテーブル３３は、インデックス３３ａ、インデックスＧＷ３３ｂ、ＴＴＬ３３ｃ及び更新時間３３ｄを記憶する。第２キャッシュテーブル３３では、インデックス３３ａを探索し、所望のインデックス３３ａが見つかると、そのインデックスに対応するインデックスＧＷ３３ｂにより、取得要求のあったインデックス情報を管理するＧＷ２０がわかる。よって、そのＧＷ２０が管理する第１キャッシュテーブル３２にて再度インデックス情報の検索を行うことで、該当するデバイスデータの格納場所を示すシンクアドレス３２ｄが得られる。なお、ＴＴＬ３３ｃは、第２キャッシュテーブル３３に記憶されたインデックス３３ａの有効期限を示す。
【００３９】
インデックス管理テーブル３０は、自身のＧＷ２０が管理するインデックス３０ａが示すデバイスデータの格納場所のみを保持する。よって、本実施形態のように、ＧＷ２０がサブディレクトリの情報を管理していない場合、その都度、データセンタ１０へディレクトリの問い合わせが必要になる。その結果、データセンタ１０とのトラヒック量が増大し、レスポンス時間が悪化する。そこで、本実施形態では、サブディレクトリ管理部２３がサブディレクトリの情報を管理することで、隣接ＧＷ２０’に記憶されているデバイスデータの格納場所をデータセンタ１０へ問い合わせすることなく取得することを可能とする。
【００４０】
なお、前提として、ＧＷ２０及びシンク４は固定して設置され、移動しない。これに対して、デバイス３は移動する。よって、ＧＷ２０及びデバイス３間、並びに、シンク４及びデバイス３間は動的に変化する。したがって、一のデバイス３から取得するデバイスデータは、一のＧＷ２０の管理下のデバイスデータから、隣接ＧＷ２０’の管理下のデバイスデータに移ることが起こり得る。特に、デバイスの移動が大きい場合、配備された処理を実行するために取得すべきデバイスデータのＧＷ跨ぎのインデックス検索が行われる可能性が高まる。
【００４１】
負荷分散の目的で、配備された処理が、自身のＧＷ２０が管理するデバイスデータ以外のＧＷ２０に配備されることがある。また、デバイス３自体が、処理が配備されていたＧＷ２０から他の隣接ＧＷ２０’の管理下に移動したため、処理が配備されていたＧＷ２０にあるデバイスデータが欲しい場合がある。
【００４２】
この場合、本実施形態に係るＧＷ２０は、第１キャッシュテーブル３２及び第２キャッシュテーブル３３を参照して、ＧＷ跨ぎのインデックス検索が行われる。このとき、本実施形態では、各ＧＷ２０が行うサブディレクトリの管理によりトラヒックが増大しないように、サブディレクトリのインデックス情報の収集範囲は、自身のＧＷ２０から所定の距離内にある隣接ＧＷ２０’に限定する。その理由は、デバイス３はＧＷ２０の管理エリアを連続的に移動することが想定されるため、インデックス情報が自身のＧＷ２０に登録された際に、隣接ＧＷ２０’にその旨を通知すれば、隣接ＧＷ２０’の第１キャッシュテーブル３２にデータ格納場所のシンクアドレスが記憶されるか、隣接ＧＷ２０’の第２キャッシュテーブル３３に送信元（通知元）のＧＷ２０が記憶される。これにより、ＧＷ跨ぎのインデックス検索が発生した場合、第１キャッシュテーブル３２及び第２キャッシュテーブル３３を使用して、取得要求のあったデバイスデータの格納場所を特定することができる。
【００４３】
しかしながら、ＧＷ跨ぎのインデックス検索が発生した場合にもＧＷ２０間にて通信が発生する。つまり、各ＧＷ２０が行うサブディレクトリ管理のためのメッセージによるトラヒック量と、データ取得要求に対するレスポンス時間との間にはトレードオフの関係がある。
【００４４】
そこで、本実施形態では、各ＧＷ２０が行うサブディレクトリ管理に使用する情報の記憶領域が、第１キャッシュテーブル３２及び第２キャッシュテーブル３３という２つのデータ構造を有している。そして、データ取得要求とデータ登録要求との頻度に応じて第１キャッシュテーブル３２又は第２キャッシュテーブル３３に情報を記憶するようになっている。
【００４５】
第１キャッシュテーブル３２では、データ取得要求対象のデバイスデータを保持するシンク４のアドレスが管理される。第１キャッシュテーブル３２は、インデックス管理テーブル３０へのインデックス情報の登録毎に更新される。よって、第１キャッシュテーブル３２を参照することで、常に最新のシンクアドレスを得ることができる。
【００４６】
第２キャッシュテーブル３３には、データ取得要求対象のデバイスデータのインデックス情報を保持するＧＷ２０のアドレスが管理される。第２キャッシュテーブル３３は、初回及び閾値が変化するときのみ更新され、インデックス管理テーブル３０へのインデックス情報の登録毎に更新されることはない。
【００４７】
つまり、第１キャッシュテーブル３２で管理されるのは詳細なインデックス情報となり、第２キャッシュテーブル３３で管理されるのは、第１キャッシュテーブル３２と比較して粗いインデックス情報となる。
【００４８】
よって、第１キャッシュテーブル３２を、取得要求があったデータの探索に用いる場合、例えば自身のＧＷ２０のインデックス管理テーブル３０の探索→サブディレクトリの探索→デバイスデータへのアクセスというように探索場所が少なくなる。このため、データの取得要求が多い場合に有利になる。他方、データの登録要求が多い場合、第２キャッシュテーブル３３を用いて粗いインデックス情報を集約する場合と比べて不利になる。つまり、第１キャッシュテーブル３２を用いて詳細なインデックス情報を集約すると、トラヒック量は大きくなるが、データの取得要求が多い場合にレスポンス時間が小さくなる。
【００４９】
これに対して、第２キャッシュテーブル３３を、取得要求があったデータの探索に用いる場合、例えば自身のＧＷ２０のインデックス管理テーブル３０の探索→サブディレクトリの探索→隣接ＧＷ２０’の探索→デバイスデータへのアクセスというように探索場所が多くなる。このため、データの取得要求が多い場合に不利になる。つまり、第２キャッシュテーブル３３を用いて粗いインデックス情報を集約すると、トラヒック量は小さくなるが、データの取得要求が多い場合にレスポンス時間が大きくなる。
【００５０】
よって、データの取得要求がデータの登録要求よりも多い場合、第１キャッシュテーブル３２にて管理されている詳細なインデックス情報を用いるとよい。また、データの登録要求がデータの取得要求よりも多い場合、第２キャッシュテーブル３３にて管理されている粗いインデックス情報を用いるとよい。これにより、ＧＷ２０が行うサブディレクトリ管理のためのメッセージによるトラヒック量と、データ取得要求に対するレスポンス時間とのバランスを考慮し、限られた記憶容量でデータ取得要求に迅速に対応することができる。
【００５１】
以上の処理を実行するために、本実施形態では、データ登録要求頻度を示す指標としてデータ登録要求数Ｎputを記憶する。また、データ取得要求頻度を示す指標としてデータ取得要求数Ｎreqを記憶する。
【００５２】
そして、αＮput−βＮreq≦０の場合、つまり、データの取得要求がデータの登録要求以上である場合には、データの登録時には第１キャッシュテーブル３２を更新する。また、データ取得部２５は、データ取得時には第１キャッシュテーブル３２に格納されたシンクアドレス３２ｄが示す格納場所から直接デバイスデータを取得する。
【００５３】
また、αＮput−βＮreq＞０の場合、つまり、データの登録要求がデータの取得要求よりも多い場合には、データの登録時には第２キャッシュテーブル３３を更新する。また、データ取得部２５は、データ取得時には第２キャッシュテーブル３３に格納されたインデックスＧＷ３３ｂが示すＧＷ２０を探索してデバイスデータを取得する。
【００５４】
ただし、αＮput−βＮreq＞０の場合であっても、最近傍ＧＷに対してのみデータの登録時に第１キャッシュテーブル３２を更新する。これについては後述する。
【００５５】
α，βは、データ登録要求数Ｎputとデータ取得要求数Ｎreqとの比較において正規化するための重み付けの値であり、データ取得時及びデータ登録時のメッセージサイズに応じた値に設定される。
【００５６】
なお、データ取得要求数Ｎreqは、データ取得要求を受けたときにインデックス情報毎の取得要求の回数を記憶する第１カウンタの一例である、また、データ登録要求数Ｎputは、隣接ＧＷ２０’から通知を受けたときに該通知の回数を記憶する第２カウンタの一例である。
【００５７】
［隣接ＧＷ／最近傍ＧＷ］
図９に示すように、各ＧＷ２０が管理するエリアに重なりがないことを前提として、本実施形態では、ＧＷ２０に対して隣接するエリアを持つＧＷを「隣接ＧＷ２０’」と定義する。図９の例では、隣接ＧＷ２０’は、ＧＷ２０の周りに６つ存在するが、これに限らない。隣接ＧＷ２０’は、ＧＷ２０に対して所定の距離内にあるＧＷの一例である。ＧＷ２０に対して所定の距離内にあるＧＷであれば、ＧＷ２０と隣接するエリアを持たないＧＷであっても隣接ＧＷ２０’に成り得る。
【００５８】
最近傍ＧＷは、隣接ＧＷ２０’のうち、デバイス３の位置から距離が最も近いＧＷである。データ取得要求に地理的な局所性があることを仮定すると、隣接ＧＷ２０’のうち最近傍ＧＷのエリアからデータ取得要求がある可能性は他の隣接ＧＷ２０’よりも大きいと考えられる。
【００５９】
よって、αＮput−βＮreq＞０の場合であっても、最近傍ＧＷに対してのみ第１キャッシュテーブル３２を更新する。これにより、デバイス３がＧＷエリアを連続的に移動すると仮定した場合に、デバイス３の移動に追従して、データの登録及び効率的なデータの取得が可能になり、トラヒック量の発散の抑制が期待できる。また、移動直後はデータ登録要求数Ｎputが多く、αＮput−βＮreq＞０が成り立つが、徐々にデータ取得要求数Ｎreqが大きくなり、ある時点でαＮput−βＮreq≦０となる。そのとき、第１キャッシュテーブル３２を用意しておくことでレスポンス時間の急な増大を抑制することができる。
【００６０】
なお、最近傍ＧＷは、デバイス３に最も近い一のＧＷに限らず、例えば、中心のＧＷ２０よりもデバイス３側にある複数のＧＷであってもよい。図９では、ＧＷ２０を中心にしてＡ−Ａ線よりもデバイス３側にある３つの隣接ＧＷ２０’を最近傍ＧＷとしてもよい。また、隣接ＧＷ２０’のうち、デバイス３の位置から距離が最も近いＧＷとそのＧＷから最も近い両側のＧＷを含めて最近傍ＧＷとしてもよい。
【００６１】
＜第１実施形態＞
［分散データ管理処理］
次に、第１実施形態に係る分散データ管理処理の一例について、図１０を参照して説明する。図１０は、本実施形態に係る分散データ管理処理の一例を示したフローチャートである。図１０に示す処理は、分散データ管理システム１内のすべてのＧＷ２０がそれぞれ実行する。
【００６２】
まず、リクエスト応答部２１は、データ取得要求を受信したかを判定する（ステップＳ１）。リクエスト応答部２１は、データ取得要求を受信したと判定した場合、図１１のデータ取得処理を実行し（ステップＳ２）、本処理を終了する。
【００６３】
リクエスト応答部２１が、データ取得要求を受信しないと判定した場合、データ取得部２５は、データ取得要求を受信したかを判定する（ステップＳ３）。データ取得部２５は、データ取得要求を受信したと判定した場合、図１２のデータ登録処理を実行し（ステップＳ４）、本処理を終了する。
【００６４】
データ取得部２５が、データ登録要求を受信しないと判定した場合、サブディレクトリ管理部２３は、サブディレクトリ更新要求を受信したかを判定する（ステップＳ５）。サブディレクトリ管理部２３は、サブディレクトリ更新要求を受信したと判定した場合、図１３のサブディレクトリ更新処理を実行し（ステップＳ６）、本処理を終了する。
【００６５】
サブディレクトリ管理部２３は、サブディレクトリ更新要求を受信しないと判定した場合、一定時間経過していれば（ステップＳ７）、図１４の最近傍ＧＷ更新処理を実行し（ステップＳ８）、本処理を終了する。他方、一定時間経過していなければ、そのまま本処理を終了する。
【００６６】
［データ取得処理］
次に、第１実施形態に係るデータ取得処理の一例について、図１１を参照して説明する。図１１は、第１実施形態に係るデータ取得処理の一例を示すフローチャートである。
【００６７】
リクエスト応答部２１は、データ取得要求を受信する（ステップＳ１０）。データ取得要求には、例えば、「Ｄｅｖｉｃｅ＝〇〇、Ｂｏｄｙ＝△△」というようにインデックス条件が指定されていて、そのインデックス条件のデバイスデータの取得が要求される。
【００６８】
次に、インデックス管理部２２及びサブディレクトリ管理部２３は、上記インデックス条件を探索する（ステップＳ１１）。具体的には、インデックス管理部２２は、インデックス管理テーブル３０のインデックス３０ａを探索し、上記インデックス条件を満たすインデックス３０ａのエントリを選び出す。また、サブディレクトリ管理部２３は、第１キャッシュテーブル３２のインデックス３２ａを探索し、上記インデックス条件を満たすインデックス３２ａのエントリを選び出す。また、サブディレクトリ管理部２３は、第２キャッシュテーブル３３のインデックス３３ａを探索し、上記インデックス条件を満たすインデックス３３ａのエントリを抽出する。
【００６９】
次に、サブディレクトリ管理部２３は、ＧＷ跨ぎのインデックス検索があるか否かを判定する（ステップＳ１２）。サブディレクトリ管理部２３は、第１キャッシュテーブル３２又は第２キャッシュテーブル３３のエントリを抽出した場合、ＧＷ跨ぎのインデックス検索があると判定し、それ以外の場合、ＧＷ跨ぎのインデックス検索はないと判定する。
【００７０】
ＧＷ跨ぎのインデックス検索はないと判定された場合、データ取得部２５は、インデックス管理テーブル３０のうちから抽出したエントリのシンクアドレス３０ｃが示すシンク４が管理する生データＤＢ６からデバイスデータ（生データ）を取得する（ステップＳ１３）。リクエスト応答部２１は、取得したデバイスデータを、データ取得要求を行った処理に返信し（ステップＳ１４）、本処理を終了する。
【００７１】
ステップＳ１２において、ＧＷ跨ぎのインデックス検索があると判定された場合、サブディレクトリ管理部２３は、抽出したエントリは第１キャッシュテーブル３２又は第２キャッシュテーブル３３のいずれかを判定する（ステップＳ１５）。
【００７２】
サブディレクトリ管理部２３は、第１キャッシュテーブル３２であると判定すると、第１キャッシュテーブル３２のうちから抽出したエントリのＴＴＬ３２ｅ及びデータ取得要求数Ｎreq３２ｃを更新する（ステップＳ１６）。次いで、データ取得部２５は、第１キャッシュテーブル３２の当該エントリのシンクアドレス３２ｄが示すシンク４からデバイスデータを取得する（ステップＳ１３）。リクエスト応答部２１は、取得したデバイスデータを、データ取得要求を行った処理に返信し（ステップＳ１４）、本処理を終了する。
【００７３】
ステップＳ１５において、サブディレクトリ管理部２３は、第２キャッシュテーブル３３であると判定すると、第２キャッシュテーブル３３の当該エントリのＴＴＬ３３ｃを更新する（ステップＳ１７）。
【００７４】
次いで、サブディレクトリ管理部２３は、隣接ＧＷ２０’へ第２キャッシュテーブル３３を更新したことを通知する。隣接ＧＷ２０’のサブディレクトリ管理部２３は、第２キャッシュ管理テーブル３１のデータ取得要求数Ｎreq３１ｃを１インクリメントする（ステップＳ２０）。このとき、通知元のＧＷ毎にデータ取得要求数Ｎreq３１ｃの更新が行われる。
【００７５】
次に、隣接ＧＷ２０’のサブディレクトリ管理部２３は、αＮput−βＮreq≦０が成立するか否かを判定し（ステップＳ２１）その判定結果を、ステップＳ１７にて通知を行った、ローカル側（通知元）のＧＷ２０に通知する。
【００７６】
隣接ＧＷ２０’からαＮput−βＮreq≦０が成立するとの判定結果を受けた場合、ローカル側のＧＷ２０のサブディレクトリ管理部２３は、第１キャッシュテーブル３２に、第２キャッシュテーブル３３で抽出したエントリを追加し（ステップＳ１８）、ステップＳ１３に進む。他方、隣接ＧＷ２０’からαＮput−βＮreq≦０が成立しないとの判定結果を受けた場合、ローカル側のＧＷ２０のサブディレクトリ管理部２３は、そのままステップＳ１３に進む。
【００７７】
ステップＳ１３において、データ取得部２５は、第２キャッシュテーブル３３から抽出したエントリのインデックスＧＷ３３ｂが示すＧＷ２０にアクセスする。そして、データ取得部２５は、アクセスしたＧＷ２０のインデックス管理テーブル３０のシンクアドレス３０ｃが示すシンク４からデバイスデータを取得する（ステップＳ１３）。リクエスト応答部２１は、デバイスデータを返信し（ステップＳ１４）、本処理を終了する。
【００７８】
［データ登録処理］
次に、第１実施形態に係るデータ登録処理の一例について、図１２を参照して説明する。図１２は、第１実施形態に係るデータ登録処理の一例を示すフローチャートである。リクエスト応答部２１は、データ登録要求を受信する（ステップＳ３０）。
【００７９】
次に、サブディレクトリ管理部２３は、登録要求対象のデータが第２キャッシュ管理テーブル３１にエントリされているか否かを検索する（ステップＳ３１）。第２キャッシュ管理テーブル３１にエントリされていない情報は、隣接ＧＷ２０’にて第２キャッシュテーブル３３に保持されていないインデックス情報である。よって、サブディレクトリ管理部２３は、登録要求対象のデータが第２キャッシュ管理テーブル３１にエントリされていないと判定した場合、隣接ＧＷ２０’の第１キャッシュテーブル３２にエントリするために、隣接ＧＷ２０’に対してサブディレクトリの更新要求を行う（ステップＳ３２）。次に、インデックス管理部２２は、データ登録要求に応じてインデックス管理テーブル３０にエントリを追加し（ステップＳ３３）、本処理を終了する。
【００８０】
他方、ステップＳ３１において、サブディレクトリ管理部２３は、登録要求対象のデータが第２キャッシュ管理テーブル３１にエントリされていると判定した場合、隣接ＧＷ２０’にて第２キャッシュテーブル３３に保持されているインデックス情報であるため、隣接ＧＷ２０’の第１キャッシュテーブル３２にエントリする必要はないと判定する。よって、この判定の結果、サブディレクトリ管理部２３は、隣接ＧＷ２０’に対してサブディレクトリの更新要求は行わない。ただし、最近傍ＧＷに対してのみサブディレクトリの更新要求を行う（ステップＳ３４）。
【００８１】
これは、デバイス３が移動する場合、デバイス３は、最近傍ＧＷに移動する確率が最も高いため、最近傍ＧＷの場合のみ隣接ＧＷ２０’の第１キャッシュテーブル３２を更新することで、デバイス３が最近傍ＧＷに移動するしたときに、隣接ＧＷ２０’の第１キャッシュテーブル３２におけるインデックス情報のヒット率を上げ、レスポンス時間を短くするためである。なお、ステップＳ３２のサブディレクトリ更新要求に対して隣接ＧＷ２０’が行う処理、及びステップＳ３４のサブディレクトリ更新要求に対して最近傍ＧＷが行う処理は、図１３のサブディレクトリ更新処理において説明する。
【００８２】
図１２に戻り、ステップＳ３４の処理の後、サブディレクトリ管理部２３は、第２キャッシュ管理テーブル３１のデータ登録要求数（Ｎput）３１ｂを１インクリメントする（ステップＳ３５）。次に、インデックス管理部２２は、データ登録要求に応じてインデックス管理テーブル３０にエントリを追加し（ステップＳ３３）、本処理を終了する。
【００８３】
［サブディレクトリ更新処理］
次に、図１３のサブディレクトリ更新処理について説明する。図１３のサブディレクトリ更新処理は、図１２のステップＳ３２においてＧＷ２０が送信したサブディレクトリ更新要求を受けつけた隣接ＧＷ２０’により実行される。また、図１２のステップＳ３４においてＧＷ２０が送信したサブディレクトリ更新要求を受けつけた最近傍ＧＷにより実行される。以下は、ステップＳ３２にてサブディレクトリ更新要求を受けつけた隣接ＧＷ２０’が実行する場合について説明し、ステップＳ３４にてサブディレクトリ更新要求を受けつけた最近傍ＧＷが実行する場合については同一処理であるため、説明を省略する。
【００８４】
本処理では、まず、隣接ＧＷ２０’にてサブディレクトリ更新要求が受信される（ステップＳ４０）。受信した隣接ＧＷ２０’のサブディレクトリ管理部２３は、データ登録要求に応じた第１キャッシュテーブル３２のインデックス３２ａに対応するデータ登録要求数（Ｎput）３２ｂを１インクリメントする。また、隣接ＧＷ２０’のサブディレクトリ管理部２３は、登録要求されたデータの格納場所であるシンクアドレス３２ｄを記憶し、ＴＴＬ３２ｅをセットする（ステップＳ４１）。
【００８５】
次に、サブディレクトリ管理部２３は、αＮput−βＮreq＞０が成立するか否かを判定する（ステップＳ４２）。サブディレクトリ管理部２３は、αＮput−βＮreq＞０が成立すると判定した場合、つまり、データの登録要求がデータの取得要求よりも多い場合には、第２キャッシュテーブル３３に登録要求に応じたデータのエントリを追加する（ステップＳ４３）。そして、サブディレクトリ更新要求を送信した送信元のＧＷ２０に対して、第２キャッシュ管理テーブル３１に該当エントリを追加させ（ステップＳ４４）、本処理を終了する。
【００８６】
ステップＳ４２において、αＮput−βＮreq＞０が成立しないと判定された場合、直ちに本処理を終了する。
【００８７】
［最近傍ＧＷ更新処理］
次に、一実施形態に係る最近傍ＧＷ更新処理の一例について、図１４を参照して説明する。図１４は、一実施形態に係る最近傍ＧＷの更新処理の一例を示すフローチャートである。
【００８８】
最近傍ＧＷの更新処理が開始されると、サブディレクトリ管理部２３は、第２キャッシュ管理テーブル３１からインデックス３１ａを１つ選択する（ステップＳ５１）。次に、サブディレクトリ管理部２３は、デバイス３の現在の位置を取得し、最近傍ＧＷを更新する（ステップＳ５２）。次に、サブディレクトリ管理部２３は、未選択のインデックス３１ａがあるか否かを判定し、未選択のインデックス３１ａがあると判定した場合にはステップＳ５１に戻り、ステップＳ５１以降の処理を繰り返す。一方、ステップＳ５３において、未選択のインデックス３１ａはないと判定された場合、本処理を終了する。
【００８９】
以上、第１実施形態に係る分散データ管理処理について説明した。これによれば、インデックス管理テーブル３０を参照してデータ格納場所が特定できる場合、データ取得部２５は、そのデータ格納場所からデバイスデータの取得を行う。一方、インデックス管理テーブル３０を参照してもデータ格納場所を特定できない場合、サブディレクトリ管理部２３が、第１キャッシュテーブル３２及び第２キャッシュテーブル３３を参照してデータ格納先を特定する。この結果、データ取得部２５は、特定したデータ格納先から取得要求に応じたデバイスデータを取得する。
【００９０】
また、デバイス３からのデータ登録要求に応じて、第１キャッシュテーブル３２又は第２キャッシュテーブル３３の少なくともいずれを更新するか否かが判定される。その場合、データ取得要求数Ｎreqとデータ登録要求数Ｎputとを比較して、第１キャッシュテーブル３２の更新を行うか否か、第２キャッシュテーブル３３の更新を行うか否かが判定され、判定結果に基づき該当キャッシュテーブルが更新される。
【００９１】
このとき、サブディレクトリ管理部２３が行う第１キャッシュテーブル３２及び第２キャッシュテーブル３３の管理のためのＧＷ間のトラヒック量は、式（１）で定められる。
【００９２】
ＧＷ間トラヒック量＝データ登録時ＧＷ間トラヒック量＋データ取得時ＧＷ間トラヒック量・・（１）
ここで、データ登録時ＧＷ間トラヒック量は、第１キャッシュテーブル３２の更新メッセージ量に等しい。また、データ取得時ＧＷ間トラヒック量は、リモートindex探索メッセージ量、つまり、隣接ＧＷ２０’及びＧＷ２０により行われる、取得したいデータのインデックス探索時に使用されるメッセージ量に等しい。
【００９３】
すなわち、式（１）は以下のように書き替えられる。
【００９４】
ＧＷ間トラヒック量＝第１キャッシュテーブル更新メッセージ量＋リモートindex探索メッセージ量
次に、データ取得要求時のレスポンス時間は、以下の式（２）で定められる。
【００９５】
レスポンス時間の平均＝Ｔreq＋ｘＴindex
ここで、Ｔreqは、第１キャッシュテーブル３２利用時のレスポンス時間の平均を示し、Ｔindexは、第２キャッシュテーブル３３利用時のレスポンス時間の増分平均を示す。また、ｘは、第２キャッシュテーブル３３利用要求の割合を示す。
【００９６】
データ取得要求がパレート即に従いばらつくとするとｘ＝０．２と仮定でき、レスポンス時間の平均値の増加はそれほど大きくないと言える。
【００９７】
本実施形態にて説明したように、αＮput−βＮreq≦０の場合、つまり、データの取得要求がデータの登録要求以上である場合、サブディレクトリ管理部２３は、データの登録時に第１キャッシュテーブル３２を更新する。また、データ取得部２５は、データ取得時は第１キャッシュテーブル３２に格納されたシンクアドレス３２ｄが示す格納場所から直接デバイスデータを取得する。
【００９８】
他方、αＮput−βＮreq＞０の場合、つまり、データの登録要求がデータの取得要求よりも多い場合、サブディレクトリ管理部２３は、データの登録時に第２キャッシュテーブル３３を更新する。また、データ取得部２５は、データ取得時に第２キャッシュテーブル３３に格納されたインデックスＧＷ３３ｂが示すＧＷ２０を探索してデバイスデータを取得する。
【００９９】
これにより、図１５の線Ｂに示すように、第１キャッシュテーブル３２又は第２キャッシュテーブル３３のみを有する場合と比較して、サブディレクトリ管理のためのＧＷ２０間に発生するトラヒック量の増大を抑えることができる。この結果、データ取得要求に対するレスポンス時間を短くすることができる。
【０１００】
＜第２実施形態＞
次に、第２実施形態に係る分散データ管理処理について説明する。第１実施形態では第１キャッシュテーブル３２及び第２キャッシュテーブル３３の２つのデータ構造を有するのに対して、第２実施形態では第１キャッシュテーブル３２、第２キャッシュテーブル３３及び第３キャッシュテーブル３４の３つのデータ構造を有する。
【０１０１】
第１キャッシュテーブル３２は、取得要求対象のデバイスデータを保持するシンクアドレスを常に更新する。第２キャッシュテーブル３３は、取得要求対象のデバイスデータのインデックス情報を保持するＧＷのアドレスを更新する。第３キャッシュテーブル３４は、第１キャッシュテーブル３２をｎ回更新したときに１回だけ更新される。ｎは、２以上の整数である。
【０１０２】
Ｔ１＜０＜Ｔ２として、本実施形態では、γＮput−δＮreq≦Ｔ１が成立する場合、第１キャッシュテーブル３２が更新される。Ｔ１＜γＮput−δＮreq≦Ｔ２が成立する場合、第３キャッシュテーブル３４が更新される。Ｔ２＜γＮput−δＮreqが成立する場合，第２キャッシュテーブル３３が更新される。
【０１０３】
これにより、第１キャッシュテーブル３２が最も詳細なデータ、第３キャッシュテーブル３４が次に詳細なデータ、第２キャッシュテーブル３３が最も粗いデータを有することになる。
【０１０４】
なお、γ，δは、データ登録要求数Ｎputとデータ取得要求数Ｎreqとの比較において正規化するための重み付けの値であり、データ取得時及びデータ登録時のメッセージサイズに応じた値である。
【０１０５】
（インデックス管理テーブル）
図１６は、第２実施形態に係るインデックス管理テーブル３０の一例を示す。インデックス管理テーブル３０は、インデックス３０ａ、更新時間３０ｂ、シンクアドレス３０ｃ及びカウンタｎ３０ｄを記憶する。カウンタｎ３０ｄは、第１キャッシュテーブル３２への登録回数をカウントする。
【０１０６】
第２キャッシュ管理テーブル３１、第１キャッシュテーブル３２及び第２キャッシュテーブル３３の構成は、図６〜図８に示す各テーブルと同一である。
【０１０７】
（第３キャッシュテーブル）
図１７は、第２実施形態に係る第３キャッシュテーブル３４の一例を示す。第３キャッシュテーブル３４の構成は、第１キャッシュテーブル３２の構成と同一である。本実施形態では、第３キャッシュテーブル３４は、第１キャッシュテーブル３２をｎ回更新したときに１回だけ、第１キャッシュテーブル３２と同じエントリの内容で更新される。
【０１０８】
第３キャッシュテーブル３４は、機器の情報のインデックス情報と、機器の情報の格納場所情報とを、第１キャッシュテーブル３２よりも少ない頻度で記憶する第３記憶部の一例である。
【０１０９】
［分散データ管理処理］
次に、第２実施形態に係る分散データ管理処理の一例について説明する。第２実施形態に係る分散データ管理処理は、図１０に示した一実施形態に係る分散データ管理処理と同じであるため、ここでは説明を省略する。
【０１１０】
本実施形態では、図１０のステップＳ２で実行されるデータ取得処理（図１１）に替わって、図１８に示す第２実施形態に係るデータ取得処理が実行される。また、図１０のステップＳ４で実行されるデータ登録処理（図１２）に替わって、図１９に示す第２実施形態に係るデータ登録処理が実行される。更に、図１０のステップＳ６で実行されるサブディレクトリ更新処理（図１３）に替わって、図２０に示す第２実施形態に係るサブディレクトリ更新処理が実行される。なお、第２実施形態に係る最近傍ＧＷの更新処理は、図１０のステップＳ８で実行される最近傍ＧＷの更新処理（図１４）と同じであるため、ここでは説明を省略する。
【０１１１】
［データ取得処理］
第２実施形態に係るデータ取得処理の一例について、図１８を参照して説明する。なお、図１１に示す第１実施形態に係るデータ取得処理と同一処理ステップ（Ｓ１０〜Ｓ１４、Ｓ１６、Ｓ１７、Ｓ２０）については、同一ステップ番号を付与することで説明を簡略化する。
【０１１２】
データ取得要求を受信すると（ステップＳ１０）、インデックス探索による該当エントリの抽出（ステップＳ１１）、ＧＷ跨ぎのインデックス検索か否かの判定（ステップＳ１２）が行われる。ＧＷ跨ぎのインデックス検索でないと判定された場合、データ取得部２５は、インデックス管理テーブル３０のシンクアドレス３０ｃが示すシンク４が管理する生データＤＢ６からデバイスデータを取得する（ステップＳ１３）。リクエスト応答部２１は、取得したデバイスデータを返信して（ステップＳ１４）、本処理を終了する。
【０１１３】
ステップＳ１２において、ＧＷ跨ぎのインデックス検索があると判定された場合、サブディレクトリ管理部２３は、第１キャッシュテーブル３２であるかを判定する（ステップＳ６１）。第１キャッシュテーブル３２であると判定された場合、サブディレクトリ管理部２３は、第１キャッシュテーブル３２の対応するＴＴＬ３２ｅ及びデータ取得要求数（Ｎreq）３２ｃを更新する（ステップＳ１６）。次に、データ取得部２５は、第１キャッシュテーブル３２のシンクノードからデバイスデータを取得し（ステップＳ１３）、リクエスト応答部２１は、取得したデバイスデータを返信して（ステップＳ１４）、本処理を終了する。
【０１１４】
ステップＳ６１において、第１キャッシュテーブル３２でないと判定された場合、サブディレクトリ管理部２３は、第２キャッシュテーブル３３であるかを判定する（ステップＳ６２）。サブディレクトリ管理部２３は、第２キャッシュテーブル３３であると判定した場合、第２キャッシュテーブル３３の対応するＴＴＬ３３ｃを更新する（ステップＳ１７）。
【０１１５】
次いで、ＧＷ２０から通知を受けた隣接ＧＷ２０’のサブディレクトリ管理部２３は、第２キャッシュ管理テーブル３１のデータ取得要求数（Ｎreq）３１ｃを１インクリメントする（ステップＳ２０）。次に、隣接ＧＷ２０’のサブディレクトリ管理部２３は、Ｔ１＜γＮput−δＮreq≦Ｔ２が成立するか否かを判定し（ステップＳ７２）、その判定結果をローカル側のＧＷ２０に通知する。
【０１１６】
ローカル側のＧＷ２０のサブディレクトリ管理部２３は、隣接ＧＷ２０’からＴ１＜γＮput−δＮreq≦Ｔ２が成立するとの判定結果を受けた場合、第３キャッシュテーブル３４に、第２キャッシュテーブル３３で抽出したエントリを追加し（ステップＳ６６）、ステップＳ１３に進む。他方、ローカル側のＧＷ２０のサブディレクトリ管理部２３は、隣接ＧＷ２０’からＴ１＜γＮput−δＮreq≦Ｔ２が成立しないとの判定結果を受けた場合、そのままステップＳ１３に進む。
【０１１７】
ステップＳ１３において、データ取得部２５は、第２キャッシュテーブル３３の当該エントリのインデックスＧＷ３３ｂが示すＧＷ２０にアクセスする。そして、データ取得部２５は、アクセスしたＧＷ２０のインデックス管理テーブル３０のシンクアドレス３０ｃが示すシンク４からデバイスデータを取得する（ステップＳ１３）。リクエスト応答部２１は、取得したデバイスデータを返信し（ステップＳ１４）、本処理を終了する。
【０１１８】
ステップＳ６２において、サブディレクトリ管理部２３は、第２キャッシュテーブル３３でないと判定した場合、第３キャッシュテーブル３４の対応するＴＴＬ３４ｅ及びデータ取得要求数（Ｎreq）３４ｃを更新する（ステップＳ６３）。次に、サブディレクトリ管理部２３は、γＮput−δＮreq≦Ｔ１が成立するか否かを判定する（ステップＳ６４）。サブディレクトリ管理部２３は、γＮput−δＮreq≦Ｔ１が成立すると判定した場合、第１キャッシュテーブル３２の該当エントリを追加し（ステップＳ６５）、これを隣接ＧＷ２０’に通知する。通知を受けた隣接ＧＷ２０’のサブディレクトリ管理部２３は、カウンタｎに１を設定する。ローカル側のデータ取得部２５は、該当シンクノードからデバイスデータを取得し（ステップＳ１３）、リクエスト応答部２１は、取得したデバイスデータを返信し（ステップＳ１４）、本処理を終了する。
【０１１９】
ステップＳ６４において、サブディレクトリ管理部２３は、γＮput−δＮreq≦Ｔ１が成立しないと判定した場合、該当シンクノードからデバイスデータを取得し（ステップＳ１３）、取得したデバイスデータを返信し（ステップＳ１４）、本処理を終了する。
【０１２０】
［データ登録処理］
次に、第２実施形態に係るデータ登録処理の一例について、図１９を参照して説明する。なお、図１２に示す第１実施形態に係るデータ登録処理と同一処理ステップ（Ｓ３０〜Ｓ３５）については、同一ステップ番号を付与することで説明を簡略化する。
【０１２１】
データ登録要求を受信すると（ステップＳ３０）、データ登録要求に応じたエントリが第２キャッシュ管理テーブル３１にあるか否かの検索（ステップＳ３１）が行われる。第２キャッシュ管理テーブル３１にエントリされていると判定された場合、サブディレクトリ管理部２３は、カウンタｎを１ディクリメントし、カウンタｎが０か否かを判定する（ステップＳ８１）。カウンタｎが０でないと判定された場合、サブディレクトリ管理部２３は、インデックス管理テーブル３０を更新し（ステップＳ３３）、本処理を終了する。
【０１２２】
ステップＳ８１において、カウンタｎが０であると判定された場合、サブディレクトリ管理部２３は、最近傍ＧＷに対してサブディレクトリの更新要求を行い（ステップＳ３４）、第２キャッシュ管理テーブル３１のデータ登録要求数（Ｎput）３１ｂを更新する（ステップＳ３５）。次いで、サブディレクトリ管理部２３は、インデックス管理テーブル３０を更新し（ステップＳ３３）、本処理を終了する。
【０１２３】
ステップＳ３１において、第２キャッシュ管理テーブル３１にエントリされていないと判定された場合、サブディレクトリ管理部２３は、カウンタｎを１ディクリメントし、カウンタｎが０か否かを判定する（ステップＳ８０）。カウンタｎが０でないと判定された場合、サブディレクトリ管理部２３は、インデックス管理テーブル３０を更新し（ステップＳ３３）、本処理を終了する。
【０１２４】
ステップＳ８０において、カウンタｎが０であると判定された場合、サブディレクトリ管理部２３は、隣接ＧＷ２０’に対してサブディレクトリの更新要求を行い（ステップＳ３２）、インデックス管理テーブル３０を更新し（ステップＳ３３）、本処理を終了する。
【０１２５】
［サブディレクトリ更新処理］
次に、第２実施形態に係るサブディレクトリ更新処理の一例について、図２０を参照して説明する。なお、図１３に示す第１実施形態に係るサブディレクトリ更新処理と同一処理ステップ（Ｓ４０、Ｓ４１，Ｓ４３，Ｓ４４）については、同一ステップ番号を付与することで説明を簡略化する。
【０１２６】
隣接ＧＷ２０’にてサブディレクトリ更新要求が受信されると（ステップＳ４０）、隣接ＧＷ２０’のサブディレクトリ管理部２３は、第１キャッシュテーブル３２又は第３キャッシュテーブル３４のいずれの更新要求かを判定する（ステップＳ９０）。第１キャッシュテーブル３２の更新であると判定された場合、隣接ＧＷ２０’のサブディレクトリ管理部２３は、第１キャッシュテーブル３２の対応するデータ登録要求数（Ｎput）３２ｂ、シンクアドレス３２ｄ、ＴＴＬ３２ｅを更新し（ステップＳ４１）、ステップＳ９２に進む。
【０１２７】
ステップＳ９０において、第３キャッシュテーブル３４の更新であると判定された場合、隣接ＧＷ２０’のサブディレクトリ管理部２３は、第３キャッシュテーブル３４の対応するデータ登録要求数（Ｎput）３４ｂ、シンクアドレス３４ｄ、ＴＴＬ３４ｅを更新し（ステップＳ９４）、ステップＳ９５に進む。
【０１２８】
ステップＳ９２では、Ｔ１＜γＮput−δＮreq≦Ｔ２が成立するか否かが判定され，成立しない場合、本処理は終了する。γＮput−δＮreq≦Ｔ１が成立する場合、隣接ＧＷ２０’のサブディレクトリ管理部２３は、第２キャッシュテーブル３３にデータ登録要求に応じたエントリを追加し（ステップＳ９３）、本処理を終了する。
【０１２９】
ステップＳ９５では、Ｔ２＜γＮput−δＮreqが成立するか否かが判定され，成立しない場合、本処理は終了する。Ｔ２＜γＮput−δＮreqが成立する場合、隣接ＧＷ２０’のサブディレクトリ管理部２３は、第２キャッシュテーブル３３にデータ登録要求に応じたエントリを追加する（ステップＳ４３）。そして、サブディレクトリ更新要求を送信した送信元のＧＷ２０の第２キャッシュ管理テーブル３１に、データ登録要求に応じたエントリを追加させ（ステップＳ４４）、本処理を終了する。
【０１３０】
以上に説明したように、第２実施形態によれば、第１キャッシュテーブル３２が最も詳細なデータ、第３キャッシュテーブル３４が次に詳細なデータ、第２キャッシュテーブル３３が最も粗いデータを有する３つのデータ構造にする。これにより、データ登録要求が一番多い場合は第１キャッシュテーブル３２、データ登録要求が下がってくると第３キャッシュテーブル３４、データ登録要求よりもデータ取得要求が多くなると第２キャッシュテーブル３３が更新される。これにより、第１実施形態よりもさらにトラヒック量を少なく、かつさらにレスポンス時間を短くするように制御できる。
【０１３１】
以上、各実施形態に係る分散データ管理処理について説明した。これによれば、限られた記憶容量でデータ取得要求に迅速に対応することができる。なお、以上の説明では、配備された処理には、ＧＷ２０から所望のデバイスデータが返信された。しかし、これに限らず、ＧＷ２０は、配備された処理に、デバイスデータの格納場所（シンクアドレス）を送信し、処理自身がデバイスデータの格納場所にアクセスして取得要求対象のデバイスデータを取得してもよい。
【０１３２】
［ハードウェア構成］
最後に、本実施形態に係るＧＷ２０のハードウェア構成について、図２１を参照して説明する。図２１は、本実施形態に係るＧＷ２０のハードウェア構成の一例を示す。ＧＷ２０は、入力装置１０１、表示装置１０２、外部Ｉ／Ｆ１０３、ＲＡＭ（Random  Access  Memory）１０４、ＲＯＭ（Read  Only  Memory）１０５、ＣＰＵ（Central  Processing  Unit）１０６、通信Ｉ／Ｆ１０７、及びＨＤＤ（Hard  Disk  Drive）１０８などを備え、それぞれがバスＢで相互に接続されている。
【０１３３】
入力装置１０１は、キーボードやマウスなどを含み、ＧＷ２０に各操作信号を入力するために用いられる。表示装置１０２は、ディスプレイなどを含み、各種の処理結果を表示する。通信Ｉ／Ｆ１０７は、ＧＷ２０をネットワークに接続するインターフェースである。これにより、ＧＷ２０は、通信Ｉ／Ｆ１０７を介して、他の機器（隣接ＧＷ２０’、シンク４、デバイス３等）とデータ通信を行うことができる。
【０１３４】
ＨＤＤ１０８は、プログラムやデータを格納している不揮発性の記憶装置である。格納されるプログラムやデータには、ＧＷ２０の全体を制御する基本ソフトウェア及びアプリケーションソフトウェアがある。例えば、ＨＤＤ１０８には、各種のデータベースやプログラム等が格納されてもよい。
【０１３５】
外部Ｉ／Ｆ１０３は、外部装置とのインターフェースである。外部装置には、記録媒体１０３ａなどがある。これにより、ＧＷ２０は、外部Ｉ／Ｆ１０３を介して記録媒体１０３ａの読み取り及び／又は書き込みを行うことができる。記録媒体１０３ａには、ＣＤ（Compact  Disk）、及びＤＶＤ（Digital  Versatile  Disk）、ならびに、ＳＤメモリカード（SD  Memory  card）やＵＳＢメモリ（Universal  Serial  Bus  memory）等がある。
【０１３６】
ＲＯＭ１０５は、電源を切っても内部データを保持することができる不揮発性の半導体メモリである。ＲＯＭ１０５には、ネットワーク設定等のプログラム及びデータが格納されている。ＲＡＭ１０４は、プログラムやデータを一時保持する揮発性の半導体メモリである。ＣＰＵ１０６は、ＨＤＤ１０８やＲＯＭ１０５などの記憶装置から、プログラムやデータをＲＡＭ１０４上に読み出し、処理を実行することで、装置全体の制御や搭載機能を実現する演算装置である。
【０１３７】
かかる構成により、本実施形態に係るＧＷ２０では、ＣＰＵ１０６が、例えばＲＡＭ１０４、ＲＯＭ１０５、ＨＤＤ１０８内に格納されたプログラム及びデータを用いて分散データ管理処理、データ取得処理、データ登録処理、サブディレクトリ更新処理及び最近傍ＧＷ更新処理を実行する。ただし、サブディレクトリ更新処理は、ＧＷ２０が隣接ＧＷ２０’として機能するときに実行される。
【０１３８】
記憶部２４の機能は、例えばＲＡＭ１０４、ＲＯＭ１０５、ＨＤＤ１０８により実現される。また、リクエスト応答部２１、データ取得部２５、インデックス受信部２６の機能は、例えば通信Ｉ／Ｆ１０７により実現される。また、リクエスト応答部２１、インデックス管理部２２、サブディレクトリ管理部２３、データ取得部２５及び処理実行部２７の機能は、例えばＣＰＵ１０１により実現される。つまり、分散データ管理処理、データ取得処理、データ登録処理、サブディレクトリ更新処理及び最近傍ＧＷ更新処理は、分散データ管理プログラムが、ＣＰＵ１０１に実行させる処理により実現される。
【０１３９】
以上、分散データ管理装置、分散データ管理プログラム及び分散データ管理方法は上記実施形態に限定されるものではなく、本発明の範囲内で種々の変形及び改良が可能である。また、上記実施形態及び変形例が複数存在する場合、矛盾しない範囲で組み合わせることができる。
【０１４０】
以上の説明に関し、更に以下の項を開示する。
（付記１）
所定の記憶装置に記憶した機器の情報に関するインデックス情報をインデックス管理テーブルに記憶するとともに、所定の距離内にいる中継器に、前記インデックス情報の通知を行うインデックス管理部と、
前記機器の情報の取得要求を受けたときに、該取得要求を受けた前記機器の情報又は該機器の情報の格納場所情報を返信する応答部と、
前記機器の情報の取得要求を受けたときに、前記機器の情報毎の取得要求の回数を記憶する第１カウンタを更新し、
中継器から前記通知を受けたときに、前記中継器毎の該通知の回数を記憶する第２カウンタを更新し、前記第１カウンタと前記第２カウンタとの比較に基づいて、受けた通知の前記インデックス情報を、前記機器の情報の格納場所情報を記憶する第１記憶部に記憶するか、又は、該機器の情報の送信元の中継器の情報を記憶する第２記憶部に記憶するかを判定し、判定結果に基づき記憶するサブディレクトリ管理部と、
を有する分散データ管理装置。
（付記２）
前記サブディレクトリ管理部は、前記第１カウンタの示す値が前記第２カウンタの示す値よりも小さい場合、受けた通知の前記インデックス情報を前記第２記憶部に記憶すると判定する、
付記１に記載の分散データ管理装置。
（付記３）
前記サブディレクトリ管理部は、前記第１カウンタの示す値が前記第２カウンタの示す値以上の場合、受けた通知の前記インデックス情報を前記第１記憶部に記憶すると判定する、
付記１又は２に記載の分散データ管理装置。
（付記４）
前記サブディレクトリ管理部は、前記第１カウンタが記憶する取得要求の回数の１／ｎ（ｎ≧２）の頻度で取得要求の回数を記憶する第３カウンタを更新し、
前記サブディレクトリ管理部は、前記第１カウンタと前記第２カウンタと前記第３カウンタとの比較に基づいて、受けた通知の前記インデックス情報を、前記第１記憶部に記憶するか、前記第２記憶部に記憶するか、又は、前記機器の情報の格納場所情報を記憶する第３記憶部に記憶するかを判定し、判定結果に基づき記憶する、
付記１〜３のいずれか一項に記載の分散データ管理装置。
（付記５）
前記インデックス管理部は、所定の距離内にいる前記中継器のうち、最近傍の中継器には、前記機器の情報に関するインデックス情報が前記第２記憶部に記憶されている場合であっても、該インデックス情報を前記第１記憶部に記憶するように通知を行い、
前記サブディレクトリ管理部は、最近傍の中継器から前記通知を受けたときに、前記インデックス情報を前記第１記憶部に記憶すると判定する、
付記１〜４のいずれか一項に記載の分散データ管理装置。
（付記６）
所定の記憶装置に記憶した機器の情報に関するインデックス情報をインデックス管理テーブルに記憶するとともに、所定の距離内にいる中継器に、前記インデックス情報の通知を行い、
前記機器の情報の取得要求を受けたときに、該取得要求を受けた前記機器の情報又は該機器の情報の格納場所情報を返信し、
前記機器の情報の取得要求を受けたときに、前記機器の情報毎の取得要求の回数を記憶する第１カウンタを更新し、
中継器から前記通知を受けたときに、前記中継器毎の該通知の回数を記憶する第２カウンタを更新し、
前記第１カウンタと前記第２カウンタとの比較に基づいて、受けた通知の前記インデックス情報を、前記機器の情報の格納場所情報を記憶する第１記憶部に記憶するか、又は、該機器の情報の送信元の中継器の情報を記憶する第２記憶部に記憶するかを判定し、判定結果に基づき記憶する、
処理をコンピュータに実行させるための分散データ管理プログラム。
（付記７）
前記第１カウンタの示す値が前記第２カウンタの示す値よりも小さい場合、受けた通知の前記インデックス情報を前記第２記憶部に記憶すると判定する、
付記６に記載の分散データ管理プログラム。
（付記８）
前記第１カウンタの示す値が前記第２カウンタの示す値以上の場合、受けた通知の前記インデックス情報を前記第１記憶部に記憶すると判定する、
付記６又は７に記載の分散データ管理プログラム。
（付記９）
記第１カウンタが記憶する取得要求の回数の１／ｎ（ｎ≧２）の頻度で取得要求の回数を記憶する第３カウンタを更新し、
前記第１カウンタと前記第２カウンタと前記第３カウンタとの比較に基づいて、受けた通知の前記インデックス情報を、前記第１記憶部に記憶するか、前記第２記憶部に記憶するか、又は、前記機器の情報の格納場所情報を記憶する第３記憶部に記憶するかを判定し、判定結果に基づき記憶する、
付記６〜８のいずれか一項に記載の分散データ管理プログラム。
（付記１０）
所定の距離内にいる前記中継器のうち、最近傍の中継器には、前記機器の情報に関するインデックス情報が前記第２記憶部に記憶されている場合であっても、該インデックス情報を前記第１記憶部に記憶するように通知を行い、
最近傍の中継器から前記通知を受けたときに、前記インデックス情報を前記第１記憶部に記憶すると判定する、
付記６〜９のいずれか一項に記載の分散データ管理プログラム。
（付記１１）
所定の記憶装置に記憶した機器の情報に関するインデックス情報をインデックス管理テーブルに記憶するとともに、所定の距離内にいる中継器に、前記インデックス情報の通知を行い、
前記機器の情報の取得要求を受けたときに、該取得要求を受けた前記機器の情報又は該機器の情報の格納場所情報を返信し、
前記機器の情報の取得要求を受けたときに、前記機器の情報毎の取得要求の回数を記憶する第１カウンタを更新し、
中継器から前記通知を受けたときに、前記中継器毎の該通知の回数を記憶する第２カウンタを更新し、
前記第１カウンタと前記第２カウンタとの比較に基づいて、受けた通知の前記インデックス情報を、前記機器の情報の格納場所情報を記憶する第１記憶部に記憶するか、又は、該機器の情報の送信元の中継器の情報を記憶する第２記憶部に記憶するかを判定し、判定結果に基づき記憶する、
処理をコンピュータが実行する分散データ管理方法。
（付記１２）
前記第１カウンタの示す値が前記第２カウンタの示す値よりも小さい場合、受けた通知の前記インデックス情報を前記第２記憶部に記憶すると判定する、
付記１１に記載の分散データ管理方法。
（付記１３）
前記第１カウンタの示す値が前記第２カウンタの示す値以上の場合、受けた通知の前記インデックス情報を前記第１記憶部に記憶すると判定する、
付記１１又は１２に記載の分散データ管理方法。
（付記１４）
記第１カウンタが記憶する取得要求の回数の１／ｎ（ｎ≧２）の頻度で取得要求の回数を記憶する第３カウンタを更新し、
前記第１カウンタと前記第２カウンタと前記第３カウンタとの比較に基づいて、受けた通知の前記インデックス情報を、前記第１記憶部に記憶するか、前記第２記憶部に記憶するか、又は、前記機器の情報の格納場所情報を記憶する第３記憶部に記憶するかを判定し、判定結果に基づき記憶する、
付記１１〜１３のいずれか一項に記載の分散データ管理方法。
（付記１５）
所定の距離内にいる前記中継器のうち、最近傍の中継器には、前記機器の情報に関するインデックス情報が前記第２記憶部に記憶されている場合であっても、該インデックス情報を前記第１記憶部に記憶するように通知を行い、
最近傍の中継器から前記通知を受けたときに、前記インデックス情報を前記第１記憶部に記憶すると判定する、
付記１１〜１４のいずれか一項に記載の分散データ管理方法。
【符号の説明】
【０１４１】
１    分散データ管理システム
３    デバイス
４    シンク
６    生データＤＢ
１０  データセンタ
１１  ディレクトリＤＢ
２０  ＧＷ
２０’  隣接ＧＷ
２１  リクエスト応答部
２２  インデックス管理部
２３  サブディレクトリ管理部
２４  記憶部
２５  データ取得部
２６  インデックス受信部
２７  処理実行部
２８  第１キャッシュ管理部
２９  第２キャッシュ管理部
３０  インデックス管理テーブル
３１  第２キャッシュ管理テーブル
３２  第１キャッシュテーブル
３３  第２キャッシュテーブル
３４  第３キャッシュテーブル
４０  インターネット
【図１】
2018092271.tif 000003
【図２】
2018092271.tif 000004
【図３】
2018092271.tif 000005
【図４】
2018092271.tif 000006
【図５】
2018092271.tif 000007
【図６】
2018092271.tif 000008
【図７】
2018092271.tif 000009
【図８】
2018092271.tif 000010
【図９】
2018092271.tif 000011
【図１０】
2018092271.tif 000012
【図１１】
2018092271.tif 000013
【図１２】
2018092271.tif 000014
【図１３】
2018092271.tif 000015
【図１４】
2018092271.tif 000016
【図１５】
2018092271.tif 000017
【図１６】
2018092271.tif 000018
【図１７】
2018092271.tif 000019
【図１８】
2018092271.tif 000020
【図１９】
2018092271.tif 000021
【図２０】
2018092271.tif 000022
【図２１】
2018092271.tif 000023