JP2018049332A - データ検索システムおよびデータ検索方法 - Google Patents

Abstract

【課題】処理負荷を軽減させる。【解決手段】実施形態のデータ検索システムは、第１の装置と、第２の装置とを持つ。第１の装置は、配信部と、処理状態受信部と、完了判定部とを持つ。配信部は、データを保持可能な１以上の機器に対して、クエリを配信する。処理状態受信部は、前記第２の装置から、前記機器の前記クエリに対する処理状態を示す情報を受信する。完了判定部は、受信された処理状態から前記クエリが完了したか否かを判定する。第２の装置は、送受信部と、処理状態管理部と、処理状態送信制御部とを持つ。送受信部は、前記第１の装置により配信されたクエリを受信して、前記機器に送信する。処理状態管理部は、受信された前記機器ごとの前記クエリの処理結果に基づいて、前記機器のそれぞれが前記クエリを完了したか否かを示す処理状態を管理する。処理状態送信制御部は、管理された前記クエリの処理状態を、前記第１の装置に送信する。【選択図】図１

Description

本発明の実施形態は、データ検索システムおよびデータ検索方法に関する。

従来、データを保持可能な複数のＩｏＴ（Internet of Things）機器に接続されたサーバ装置から、各ＩｏＴ機器に保持されたデータに対して検索を行うデータ検索システムが存在する。しかしながら、従来の検索システムでは、サーバ装置に多数のＩｏＴ機器が接続されるため、機器の故障やネットワーク障害等により、検索に失敗したＩｏＴ機器がある場合に、全体の検索処理がエラー制御となる場合があった。また、従来の検索システムでは、サーバ装置に処理が集中されるため、処理負荷が増大する場合があった。

特表２０１６−５０９２９４号公報

本発明が解決しようとする課題は、処理負荷を軽減させることができるデータ検索システムおよびデータ検索方法を提供することである。

実施形態のデータ検索システムは、第１の装置と、第２の装置とを持つ。第１の装置は、配信部と、処理状態受信部と、完了判定部とを持つ。配信部は、データを保持可能な１以上の機器に対して、クエリを配信する。処理状態受信部は、前記第２の装置から、前記１以上の機器により前記クエリに対する処理状態を示す情報を受信する。完了判定部は、前記処理状態受信部により受信された処理状態から前記クエリが完了したか否かを判定する。第２の装置は、送受信部と、処理状態管理部と、処理状態送信制御部とを持つ。送受信部は、前記第１の装置により配信されたクエリを受信して、前記１以上の機器に送信する。処理状態管理部は、前記送受信部により受信された、前記１以上の機器ごとの前記クエリの処理結果に基づいて、前記１以上の機器のそれぞれが前記クエリを完了したか否かを示す処理状態を管理する。処理状態送信制御部は、前記処理状態管理部により管理された前記クエリの処理状態を、前記送受信部を用いて前記第１の装置に送信する。

実施形態のデータ検索システム１の機能構成例を示す図。 ＧＷクエリ管理テーブル１５４のデータの内容を示す図。 機器クエリ管理テーブル２４２のデータ例を示す図。 サーバ装置１００からのクエリ配信の様子を説明するための図。 配下の機器３００から処理状態を取得した機器クエリ管理テーブル２４２の一例を示す図。 配下のゲートウェイ装置２００から処理状態を取得した機器クエリ管理テーブル２４２の一例を示す図。 データベースサイズを含む機器クエリ管理テーブル２４２Ａの一例を示す図。 テーブルサイズを含む機器クエリ管理テーブル２４２Ｂの一例を示す図。 実施形態のサーバ装置１００における処理内容の一例を示すフローチャート。 実施形態のゲートウェイ装置２００における処理内容の一例を示すフローチャート。 実施形態の機器３００における処理内容の一例を示すフローチャート。

以下、実施形態のデータ検索システムおよびデータ検索方法を、図面を参照して説明する。

図１は、実施形態のデータ検索システム１の機能構成例を示す図である。図１に示すデータ検索システム１は、例えば、サーバ装置（第１の装置）１００と、１以上のゲートウェイ装置（第２の装置）２００−１〜２００−ｎと、１以上の機器３００−１〜３００−ｋ（またはｍ）とを備える。ｋ，ｍは、同一の数でもよく異なる数でもよい変数である。サーバ装置１００と、ゲートウェイ装置２００と、機器３００とは、インターネットやＬＡＮ（Local Area Network）、ＷＡＮ（Wide Area Network）等を含むネットワークＮＷを介して通信する。なお、以下の説明において、ゲートウェイ装置２００−１〜２００−ｎは、それぞれ同様の構成とし、いずれのゲートウェイ装置であるかを区別しないときは、いずれのゲートウェイ装置であるかを示すハイフン以降の符号を省略し、「ゲートウェイ装置２００」と称して説明する。また、ハイフンで示された他の構成についても同様とする。また、実施形態のデータ検索システム１は、サーバ装置１００を複数備えてもよく、ゲートウェイ装置２００が複数階層に構成されてもよい。

まず、サーバ装置１００の機能構成例について説明する。サーバ装置１００は、例えば、検索実行部１１０と、配信部１２０と、処理状態受信部１３０と、完了判定部１４０と、記憶部１５０とを備える。検索実行部１１０、処理状態受信部１３０、及び完了判定部１４０は、ＣＰＵ（Central Processing Unit）等のプロセッサが記憶部１５０に記憶されたプログラム（例えば、検索アプリ１５２）を実行することにより実現される。プログラムは、例えば、ネットワークＮＷを介してアプリケーションサーバ（不図示）からダウンロードされてもよいし、ＳＤカード等の可搬型記憶媒体に格納されたものがサーバ装置１００にインストールされてもよい。また、上述した各機能のうち一部または全部は、ＬＳＩ（Large Scale Integration）、ＡＳＩＣ（Application Specific Integrated Circuit）、ＦＰＧＡ（Field-Programmable Gate Array）等のハードウェアによって実現されてもよいし、ソフトウェアとハードウェアとの協働によって実現されてもよい。

検索実行部１１０は、１以上の機器３００に保持されているデータを取得するためのクエリを発行する。クエリとは、例えば、機器３００に保持されているデータに対する操作を表す命令である。クエリは、例えば、ＳＱＬ（Standard Query Language）で記述されたコマンドである。クエリは、例えば、機器３００から時間情報に対応させて２０１６年の９月１４日から９月２１日までの消費電力量、ガス使用量、水道使用量等を取得するためのコマンドでもよく、現時点での温度や湿度等を取得するためのコマンドでもよい。また、クエリは、時間情報に関係なく機器３００が保持する全てのデータを取得するコマンドでもよい。

検索実行部１１０は、機器３００に実行させるクエリと、クエリを識別するためのクエリＩＤとを配信部１２０に出力する。また、検索実行部１１０は、ゲートウェイ装置２００ごとのクエリ状態を管理するためのＧＷクエリ管理テーブル１５４を作成する。

図２は、ＧＷクエリ管理テーブル１５４のデータの内容を示す図である。ＧＷクエリ管理テーブル１５４は、例えば、「クエリＩＤ」および「ゲートウェイＩＤ」に対し、「処理状態」および「充足度」が対応付けられた情報である。「クエリＩＤ」は、検索実行部１１０により実行指示されたクエリの識別情報である。「ゲートウェイＩＤ」は、ゲートウェイ装置２００の識別情報である。「処理状態」は、ゲートウェイ装置２００ごとのクエリの処理状態を示す情報である。例えば、処理状態受信部１３０がゲートウェイ装置２００からＧＷクエリ完了メッセージを受信した場合に、処理状態は、「完了」を示す情報となる。また、ＧＷクエリ完了メッセージを受信していない場合に、処理状態は、「未完了」を示す情報となる。

「充足度」は、処理状態を受信した後に、完了判定部１４０により判定されるクエリの処理結果に対する充足度合である。充足度は、例えば、正しくクエリを完了できた機器数を、クエリを処理すべき機器数で除算することで算出することができる。検索実行部１１０は、クエリを配信部１２０から配信させる場合に、上述したクエリＩＤと、ゲートウェイＩＤ、処理状態、および充足度を１つの組としてＧＷクエリ管理テーブル１５４に記憶させる。このとき、初期値として、処理状態には、「未完了」が記憶され、充足度には、「０」が記憶される。

配信部１２０は、検索実行部１１０から得られたクエリおよびクエリＩＤをゲートウェイ装置２００に配信する。

処理状態受信部１３０は、配信部１２０によりクエリをゲートウェイ装置２００に配信した後、ゲートウェイ装置２００から１以上の機器３００によるクエリの処理結果または処理状態を受信する。クエリの処理結果を受信した場合に、処理状態受信部１３０は、クエリの処理結果を、クエリ結果データベース１５６に記憶する。処理状態受信部１３０は、受信した各ゲートウェイ装置２００からの処理状態に基づいて、記憶部１５０に記憶されたＧＷクエリ管理テーブル１５４の処理状態を更新する。

完了判定部１４０は、処理状態受信部１３０により受信された処理状態からクエリが完了したか否かを判定する。例えば、完了判定部１４０は、記憶部１５０に記憶されたＧＷクエリ管理テーブル１５４を参照し、各ゲートウェイの処理状態から充足度を算出する。また、完了判定部１４０は、算出された充足度が所定の閾値（例えば、８０％）以上の場合に、実行したクエリが成功したと判定する。クエリが成功したとは、例えば、クエリの実行により取得した処理結果が正当な結果として判定することである。

記憶部１５０は、ＲＡＭ（Random Access Memory）やＲＯＭ（Read Only Memory）、ＨＤＤ（Hard Disk Drive）、フラッシュメモリ等により実現される。記憶部１５０には、例えば、検索アプリ１５２、ＧＷクエリ管理テーブル１５４、およびクエリ結果データベース１５６の各情報が記憶される。サーバ装置１００は、例えば、ＰＣ（Personal Computer）でもよく、複数の情報処理装置により構成されるクラウドサーバでもよい。

次に、ゲートウェイ装置２００の機能構成について説明する。ゲートウェイ装置２００は、例えば、送受信部２１０と、処理状態管理部２２０と、処理状態送信制御部２３０と、記憶部２４０とを備える。また、上述した処理状態管理部２２０および処理状態送信制御部２３０のうち一部または全部は、ＬＳＩ、ＡＳＩＣ、ＦＰＧＡ等のハードウェアによって実現されてもよいし、ソフトウェアとハードウェアとの協働によって実現されてもよい。

送受信部２１０は、サーバ装置１００により配信されたクエリを受信する。また、送受信部２１０は、受信したクエリを、ゲートウェイ装置２００の配下にある１以上の機器３００に送信する。

処理状態管理部２２０は、送受信部２１０により受信された、１以上の機器３００ごとのクエリの処理結果を、記憶部２４０に記憶される機器クエリ管理テーブル２４２により管理する。

図３は、機器クエリ管理テーブル２４２のデータ例を示す図である。機器クエリ管理テーブル２４２は、例えば、「クエリＩＤ」および「機器ＩＤ」に対し、「処理状態」が対応付けられた情報である。「機器ＩＤ」は、機器を識別するための情報である。「処理状態」は、機器ＩＤごとのクエリの処理状態である。

例えば、処理状態管理部２２０は、クエリを各機器３００に配信した直後は、クエリに対する処理が完了していないため、「未完了」を設定する。また、処理状態管理部２２０は、機器３００から処理結果を受信した場合に、対象の機器３００の処理状態に「完了」を設定する。また、処理状態管理部２２０は、クエリを機器３００に配信した後、所定時間を経過しても処理結果が得られた場合に、処理状態にタイムアウトエラーまたは通信エラー等を示す情報を設定する。なお、所定時間は、例えば、クエリごとに設定されてよい。

処理状態送信制御部２３０は、処理状態管理部２２０により管理されたクエリの処理状態を、送受信部２１０を用いてサーバ装置１００に送信する。

記憶部２４０は、ＲＡＭやＲＯＭ、ＨＤＤ、フラッシュメモリ等により実現される。記憶部２４０には、例えば、機器クエリ管理テーブル２４２の情報が記憶される。ゲートウェイ装置２００は、例えばネットワーク間でプロトコル変換を行う機能を有してもよい。また、ゲートウェイ装置２００は、ルータ装置やハブ装置等の中継装置でもよい。

次に、機器３００の機能構成例について、説明する。機器３００は、例えば、送受信部３１０と、クエリ実行部３２０と、記憶部３３０とを備える。クエリ実行部３２０は、ＬＳＩ、ＡＳＩＣ、ＦＰＧＡ等のハードウェアによって実現されてもよいし、ソフトウェアとハードウェアとの協働によって実現されてもよい。

送受信部３１０は、ゲートウェイ装置２００により配信されたクエリを受信する。また、送受信部３１０は、クエリ実行部３２０で実行されたクエリ結果を、クエリを配信したゲートウェイ装置２００に出力する。

クエリ実行部３２０は、送受信部３１０により受信したクエリを実行する。例えば、クエリ実行部３２０は、記憶部３３０に記憶されたセンサデータ３３２のうち、クエリに対応するデータの抽出を行う。センサデータ３３２とは、例えば、機器３００が設置されている場所で所定時間毎に取得している温度や湿度、消費電力、ガス使用量、水道使用量等のデータのうち、少なくとも１つのデータである。センサデータ３３２は、時間情報とともに記憶されてもよい。

記憶部３３０は、ＲＡＭやＲＯＭ、ＨＤＤ、フラッシュメモリ等により実現される。記憶部３３０には、例えば、センサデータ３３２の情報が記憶される。機器３００は、例えば、ＩｏＴ機器である。

以下、サーバ装置１００における検索処理の各種動作について説明する。図４は、サーバ装置１００からのクエリ配信の様子を説明するための図である。なお、図４の例では、説明を簡略化するため、サーバ装置１００と、ゲートウェイ装置２００と、機器３００とがそれぞれ１台接続されている例を示している。

サーバ装置１００の検索アプリ１５２は、クエリＩＤとクエリとをサーバ側メッセージブローカ４１０により、全ゲートウェイ装置２００へ送信させる（図示の（１））。なお、サーバ側メッセージブローカ４１０は、例えば、配信部１２０に相当する。また、検索アプリ１５２は、自己のライブラリ（クライアントライブラリ）に、ＧＷクエリ管理テーブル１５４を生成する（図示の（２））。

次に、ゲートウェイ装置２００のゲートウェイ側メッセージブローカ４２０により、サーバ装置１００からのクエリＩＤおよびクエリを受信すると、受信した情報をクエリ制御プロセス４３０に出力する（図示の（３））。ゲートウェイ側メッセージブローカ４２０は、例えば、送受信部２１０に相当する。また、クエリ制御プロセス４３０は、例えば、処理状態管理部２２０および処理状態送信制御部２３０に相当する。

クエリ制御プロセスは、送信を受けたクエリＩＤを機器クエリ管理テーブル２４２に記憶し、データエントリを行う（図示の（４））。次に、ゲートウェイ側メッセージブローカ４２０は、クエリＩＤおよびクエリを機器３００に送信する（図示の（５））。

機器３００の送受信部３１０は、ゲートウェイ装置２００からのクエリＩＤおよびクエリを受信する（図示の（６））。クエリ実行部３２０は、クエリを実行し、センサデータ３３２からクエリに対応するデータを取得するともに、検索結果のResultSetを作成する（図示の（７））。ResultSetとは、クエリに対するＤＢＭＳ（Data Base Management System）等の応答であり、例えばＳＱＬクエリの実行結果を含むオブジェクトである。ＤＢＭＳを検索した結果として、例えば、テーブルの一部を表すデータがResultSetとなる。

次に、クエリ実行部３２０は、作成したResultSetを送受信部３１０により、ゲートウェイ装置２００を介してサーバ装置１００に送信する（図示の（８））。サーバ装置１００は、ResultSetを受信する（図示の（９））。受信されたResultSetに対応するデータは、クエリ結果データベース１５６に記憶される。次に、クエリ実行部３２０は、クエリが完了した場合に、クエリ完了メッセージをクエリ制御プロセス４３０へ送信する（図示（１０））。

次に、ゲートウェイ側メッセージブローカ４２０は、クエリ完了メッセージをクエリ制御プロセス４３０に出力する。クエリ制御プロセス４３０は、配下の全機器３００について、クエリ完了メッセージを受信またはタイムアウトエラーを検出したか否かを判定する（図示の（１１））。また、クエリ制御プロセス４３０は、配下の全機器３００に対してクエリ完了メッセージを受信またはタイムアウトエラーを検出した場合に、ＧＷクエリ完了メッセージをサーバ装置１００に送信する（図示の（１２））。クエリ制御プロセス４３０から送信されるＧＷクエリ完了メッセージには、配下の機器３００のクエリの成功または失敗の割合に関する情報を含む。

図５は、配下の機器３００から処理状態を取得した機器クエリ管理テーブル２４２の一例を示す図である。例えば、クエリ制御プロセス４３０は、ゲートウェイ装置２００の配下の機器３００として機器ＩＤ「ｄｅｖｉｃｅ−１」〜「ｄｅｖｉｃｅ−３」を有する。この場合、クエリ制御プロセス４３０は、クエリＩＤ「ｑｕｅｒｙ−１」に対し、機器ＩＤ「ｄｅｖｉｃｅ−１」および「ｄｅｖｉｃｅ−２」の処理状態が「完了」で、機器ＩＤ「ｄｅｖｉｃｅ−３」の処理状態がタイムアウトエラーだったとする。この場合、３つの機器３００のうち２つの機器３００が成功していることになるため、クエリ制御プロセス４３０は、ＧＷクエリ完了メッセージに関する情報に、成功率２／３≒０．６６７等の割合に関する情報を出力する。なお、上述した割合に関する情報は、「充足度」の一例である。

次に、検索アプリ１５２は、配下の全ゲートウェイについてのＧＷクエリ完了メッセージを受信し、受信したＧＷクエリ完了メッセージに基づいて、クエリの成功または不成功を判定する。

図６は、配下のゲートウェイ装置２００から処理状態を取得した機器クエリ管理テーブル２４２の一例を示す図である。例えば、サーバ装置１００は、配下に３台のゲートウェイ装置（ＧＷ１〜ＧＷ３）を有しているとする。また、あるゲートウェイＩＤ「ＧＷ−１」が、その配下の３台の機器３００のうち、１台でクエリ処理に失敗していたとする。この場合、ゲートウェイＩＤ「ＧＷ−１」の充足度は０．６６７となる。また、他のゲートウェイＩＤ「ＧＷ−２」、「ＧＷ−３」は、その配下の全ての機器３００からの正常な処理結果を取得している。そのため、ゲートウェイＩＤ「ＧＷ−２」、「ＧＷ−３」の充足度は、１となる。したがって、トータルのクエリ結果の充足度は、各ゲートウェイ装置２００の全ての充足度の総和をゲートウェイ装置２００の数で除算し、２．６６７／３≒０．８９となる。

ここで、検索アプリ１５２は、予め設定された閾値（例えば、０．８）以上の場合に、そのクエリは成功したと判定する。この場合、上述の０．８９は、０．８以上であるため、検索アプリ１５２は、クエリが成功したと判定する。

ここで、上述の処理では、クエリ結果の充足度をゲートウェイ装置２００ごとに求めたが、実施形態においては、これに限定されるものではない。例えば、ゲートウェイ装置２００は、配下の機器３００の数に応じて充足度を求めてもよい。この場合、ゲートウェイ装置２００は、サーバ装置１００に、クエリ結果の充足度Ｓｎと、配下にある機器数Ｎｎとを送信する（例えば、ｎは、ｎ番目の意味である）。

サーバ装置１００の検索アプリ１５２は、ゲートウェイ装置２００ごとのクエリ結果の充足度Ｓｎと、配下にある機器数Ｎｎとの積の和を、機器数Ｎｎの和で除算し（Σ（Ｓｎ×Ｎｎ）／ΣＮｎ）、除算した値が閾値以上である場合に、クエリが成功したと判定する。

また、ゲートウェイ装置２００は、機器３００が保持するセンサデータ３３２のデータサイズに基づいて、充足度を算出してもよい。データサイズは、例えば、データベースサイズでもよく、テーブルサイズでもよい。例えば、データベースサイズに基づいて充足度を算出する場合には、全体のデータベースサイズに対して何割成功したか否かにより充足度を判定する。この場合、ゲートウェイ装置２００は、クエリ発行時点での配下の機器が保持するデータベースサイズＤｍを予め受信する。なお、データベースサイズは、クエリ発行時に、同時にデータベースサイズの取得クエリを発行することで取得することができる。取得されたデータベースサイズは、機器クエリ管理テーブル２４２の各エントリに追加される。

図７は、データベースサイズを含む機器クエリ管理テーブル２４２Ａの一例を示す図である。機器クエリ管理テーブル２４２Ａには、クエリＩＤ、機器ＩＤ、処理状態の他に、各機器ＩＤに対応する機器３００のセンサデータ３３２のデータベースサイズが格納される。

ゲートウェイ装置２００は、クエリ完了時に、クエリが成功した機器３００が保持するデータベースサイズの和Ｅｎ（＝ΣＤｍ’（ｍ’は成功した機器３００）と、クエリを処理すべき機器３００が保持するデータベースサイズの和Ｄｎ（＝ΣＤｍ）とを、サーバ装置１００に送信する。サーバ装置１００は、得られた二つの値に基づいて、クエリ結果の充足度を「ΣＥｎ／ΣＤｎ」を算出することで取得する。なお、上述したクエリ結果の充足度は、ゲートウェイ装置２００で算出し、算出した結果をサーバ装置１００に送信してもよい。

また、クエリに関連するテーブルサイズに基づいてクエリ結果の充足度を算出する場合、ゲートウェイ装置２００は、クエリに関するテーブルのテーブルサイズＴｍを予め取得しておく。取得したテーブルサイズは、機器クエリ管理テーブル２４２の各エントリに追加される。

図８は、テーブルサイズを含む機器クエリ管理テーブル２４２Ｂの一例を示す図である。機器クエリ管理テーブル２４２Ｂには、クエリＩＤ、機器ＩＤ、処理状態の他に、各機器ＩＤに対応する機器３００のテーブルサイズが格納される。

ゲートウェイ装置２００は、クエリが成功した機器３００に関するテーブルサイズの和Ｔｎ（＝ΣＴｍ’）と、クエリを処理すべき機器３００に関するテーブルサイズの和Ｕｎ（＝ΣＴｍ）をサーバ装置１００へ送信する。

サーバ装置１００は、得られた二つの値に基づいて、クエリ結果の充足度を「ΣＴｎ／ΣＵｎ」を算出することで取得する。上述したクエリ結果の充足度は、ゲートウェイ装置２００で算出し、算出した結果をサーバ装置１００に送信してもよい。なお、上述したデータベースサイズやテーブルサイズを考慮したクエリ結果の充足度の算出手法は、固定長のデータ構造等の場合には、データサイズが共通化できるため、上述したクエリ結果の充足度の算出を容易に行うことができる。また、上述したデータサイズにより得られるクエリ結果の充足度に基づいて、クエリ結果が成功したか否かをより適切に判定することができる。

また、実施形態では、ゲートウェイ装置２００の配下にある複数の機器３００から、所定のグループ条件により機器３００を抽出し、抽出した機器で少なくとも１つのグループを形成し、形成されたグループ単位でクエリを実行させたり、充足度等を算出させてもよい。所定のグループ条件としては、例えば地域ごとでもよく、機器３００の種類や数でもよい。また、実施形態では、機器ＩＤ単位でグループ化を行ってもよく、ゲートウェイＩＤ単位でグループ化を行ってもよい。

例えば、サーバ装置１００の管理者等は、「川崎市にある機器３００の全て」等のように予めグルーピングを設定しておく。サーバ側メッセージブローカ４１０は、送信するクエリにグループを識別する情報を含めて、ゲートウェイ装置２００に送信する。これにより、ゲートウェイ側メッセージブローカ４２０は、設定されたグループに含まれる機器３００のみにクエリを送信させることができる。

次に、実施形態のサーバ装置１００の各種処理内容について、フローチャートを用いて具体的に説明する。図９は、実施形態のサーバ装置１００における処理内容の一例を示すフローチャートである。図９に示す処理は、クエリが実行されるごとに繰り返し実行される。

図９の例において、検索実行部１１０は、実行させるクエリを発行し（ステップＳ１００）し、発行するクエリに対応するクエリＩＤを生成する（ステップＳ１０２）。

次に、配信部１２０は、ＧＷクエリ管理テーブルを初期化し、クエリＩＤとクエリとをゲートウェイ装置２００に配信する（ステップＳ１０４）。次に、処理状態受信部１３０は、ゲートウェイ装置２００からクエリに対する処理結果、または、ＧＷクエリ完了メッセージを受信したか否かを判定する（ステップＳ１０６）。

ゲートウェイ装置２００からクエリに対する処理結果（クエリ結果）、または、ＧＷクエリ完了メッセージを受信した場合、処理状態受信部１３０は、処理結果を受信したか否かを判定する（ステップＳ１０８）。処理結果を受信した場合、受信した処理結果を記憶部１５０に記憶させる（ステップＳ１１０）。また、ステップＳ１０８において、処理結果を受信していない場合、ＧＷクエリ完了メッセージを受信したため、処理状態受信部１３０は、ＧＷクエリ完了メッセージをＧＷクエリ管理テーブルに記憶する（ステップＳ１１２）。ＧＷクエリ完了メッセージとは、例えば、ゲートウェイ装置２００に対応する充足度である。

ステップＳ１１０およびステップＳ１１２の処理後、処理状態受信部１３０は、全てのゲートウェイ装置２００からＧＷクエリ完了メッセージを受信したか、または、タイムアウトエラーになったか否かを判定する。タイムアウトエラーとは、例えば、クエリをゲートウェイ装置２００に配信してから、ＧＷクエリ完了メッセージを受信するまでの時間を設定しておき、その時間を超えたものをタイムアウトエラーとして判定する。

全てのゲートウェイ装置２００からＧＷクエリ完了メッセージを受信した場合、または、タイムアウトエラーになった場合、完了判定部１４０は、クエリ全体における充足度を算出し（ステップＳ１１６）、算出された値と閾値と基づいてクエリの成功または失敗を判定する（ステップＳ１１８）。なお、例えば、算出したクエリ結果の充足度が閾値以上である場合に、クエリが成功したと判定することができる。これにより、本フローチャートの処理は終了する。

なお、上述したステップＳ１１４の処理において、全てのゲートウェイ装置からＧＷクエリ完了メッセージを受信したり、タイムアウトエラーになっていない場合、処理状態受信部１３０は、所定時間待機し（ステップＳ１２０）、ステップＳ１０６の処理に戻る。

次に、実施形態のゲートウェイ装置２００の各種処理内容について、フローチャートを用いて具体的に説明する。図１０は、実施形態のゲートウェイ装置２００における処理内容の一例を示すフローチャートである。図１０に示す処理は、ゲートウェイ装置２００がサーバ装置１００から配信されたクエリを受信するごとに繰り返し実行される。

図１０の例において、送受信部２１０は、サーバ装置１００からクエリとクエリＩＤに関する情報を受信する（ステップＳ２００）、次に、処理状態管理部２２０は、送受信部２１０により、配下の全機器３００にクエリを送信させる（ステップＳ２０２）。次に、処理状態管理部２２０は、受信したクエリＩＤに基づいて、機器クエリ管理テーブル２４２を作成する（ステップＳ２０４）。

次に、処理状態管理部２２０は、機器３００からクエリ処理結果、または、クエリ処理完了メッセージを受信したか否かを判定する（ステップＳ２０６）。クエリ処理結果、または、クエリ処理完了メッセージを受信した場合、処理状態管理部２２０は、受信した情報がクエリ処理完了メッセージであるか否かを判定する（ステップＳ２０８）。受信した情報がクエリ処理完了メッセージでない場合、受信した情報は、クエリ処理結果であるため、送受信部２１０は、サーバ装置１００にクエリ処理結果を送信し（ステップＳ２１０）、ステップＳ２０６の処理に戻る。

受信した情報がクエリ処理完了メッセージである場合（ステップＳ２０８）、処理状態管理部２２０は、受信したクエリ処理完了メッセージを機器クエリ管理テーブル２４２に記憶させる（ステップＳ２１２）。

次に、処理状態管理部２２０は、全機器３００のクエリ処理完了メッセージが揃ったか、または、タイムアウトエラーになったか否かを判定する（ステップＳ２１４）。全機器３００のクエリ処理完了メッセージが揃ったか、または、タイムアウトエラーになった場合、処理状態送信制御部２３０は、配下の機器３００におけるクエリ結果に対する充足度を算出し（ステップＳ２１６）、クエリ結果の充足度を含むＧＷクエリ完了メッセージを、送受信部２１０によりサーバ装置１００に送信させる（ステップＳ２１８）。これにより、本フローチャートの処理は終了する。

なお、上述したステップＳ２１４の処理において、全機器からクエリ処理完了メッセージが揃ってなく、タイムアウトエラーになっていない場合、処理状態管理部２２０は、所定時間待機し（ステップＳ２２０）、ステップＳ２０６の処理に戻る。

次に、実施形態の機器３００の各種処理内容について、フローチャートを用いて具体的に説明する。図１１は、実施形態の機器３００における処理内容の一例を示すフローチャートである。図１１に示す処理は、機器３００がゲートウェイ装置２００から送信されたクエリを受信するごとに繰り返し実行される。

図１１の例において、ゲートウェイ装置２００からクエリを受信すると、クエリ実行部３２０は、受信したクエリを実行する（ステップＳ３００）。次に、クエリ実行部３２０は、クエリの処理結果として得られたデータ量が、所定量以上であるか否かを判定する（ステップＳ３０２）。所定量とは、例えば、送信するメッセージで規格化されたデータ量であるが、これに限定されるものではない。データ量が所定量以上である場合、クエリ実行部３２０は、処理結果として得られたデータ量を複数のデータに分割する（ステップＳ３０４）。

次に、送受信部３１０は、クエリの処理結果を、ゲートウェイ装置に送信する（ステップＳ３０６）。上述したステップＳ３０４の処理において、データが分割されている場合、送受信部３１０は、分割されているデータごとにゲートウェイ装置２００に送信する。

次に、クエリ実行部３２０は、クエリの処理結果を全て送信したか否かを判定する（ステップＳ３０８）。クエリの処理結果を全て送信していない場合、ステップＳ３０２の処理に戻る。また、クエリの処理結果を全て送信した場合、クエリ完了メッセージをゲートウェイ装置２００に送信する（ステップＳ３１０）。これにより、本フローチャートの処理は終了する。

ここで、実施形態のデータ検索システム１において、例えば、ある機器３００がＣ送信中にダウンしたり、接続が切断された場合、処理状態受信部１３０は、それまでに送信済みのクエリ結果の一部を有効にしてもよく、また無効にしてもよい。また、データ検索システム１は、ゲートウェイ装置２００において、上述した図４に示すクエリ制御プロセス４３０の代わりに、ブリッジプロセスを設け、機器３００からのクエリ結果のバッファリングを行ってもよい。この場合、ゲートウェイ装置２００は、ブリッジプロセスによりクエリ結果を一時的に保持しておき、機器３００からのクエリ処理完了メッセージを受け取った場合に、保持されたクエリ結果をまとめてサーバ装置１００に送信する。これにより、サーバ装置１００は、機器３００ごとに全てのクエリ結果を取得できるため、クエリ結果の充足度の精度を向上させることができる。

上述した実施形態のデータ検索システム１を用いることで、例えば、以下のような判定を行うことができる。例えば、サーバ装置１００の検索実行部１１０は、機器３００に対して現時点の消費電力量を取得するクエリをゲートウェイ装置２００に配信させる。また、サーバ装置１００は、ゲートウェイ装置２００からクエリを配信した地域の９割の機器３００からクエリ結果が取得できたとする。９割は、予め設定した閾値（例えば、８割）以上であるため、サーバ装置１００の完了判定部１４０は、このクエリは、成功したと判定する。

また、完了判定部１４０は、９割の機器３００の合計消費電力量が１．２［ＭＷｈ］であった場合、全機器３００の合計消費電力量を１．２×１０／９≒１．３３［ＭＷｈ］であると推定する。また、完了判定部１４０は、推定した消費電力量を、消費電力量に関する閾値と比較することで、電力を使い過ぎているか否かを判定する。例えば、推定した消費電力量が閾値以上である場合、完了判定部１４０は、電力を使いすぎていると判定し、節電協力金のレートを一時的に引き上げる等の処理を行ってもよい。このように、実施形態のデータ検索システム１によれば、例えば、現時点での消費電力量の概況を得ることができ、一部のクエリ結果が得られなくても、ある範囲での概況を把握することで、システム全体に対する適切な処理を行うことができる。

なお、上述の例において、ゲートウェイ装置２００からクエリを配信した地域の７割の機器３００からしかクエリ結果が取得できなかった場合、閾値（例えば、８割）以下であるため、サーバ装置１００の完了判定部１４０は、このクエリは、失敗したと判定、その後の処理を行わない。これにより、データ検索システム１は、信頼性がないデータを用いた処理を抑制することができ、システム全体の処理負荷を軽減することができる。

以上説明した少なくとも一つの実施形態によれば、サーバ装置１００と、ゲートウェイ装置２００とを備えるデータ検索システム１であって、サーバ装置１００は、データを保持可能な１以上の機器３００に対して、クエリを配信する配信部１２０と、ゲートウェイ装置２００から、１以上の機器３００のクエリに対する処理状態を示す情報を受信する処理状態受信部１３０と、処理状態受信部１３０により受信された処理状態からクエリが完了したか否かを判定する完了判定部１４０と、を持ち、ゲートウェイ装置２００は、サーバ装置１００により配信されたクエリを受信して、１以上の機器３００に送信する送受信部２１０と、送受信部２１０により受信された、１以上の機器３００ごとのクエリの処理結果に基づいて、１以上の機器のそれぞれがクエリを完了したか否かを示す処理状態を管理する処理状態管理部２２０と、処理状態管理部２２０により管理されたクエリの処理状態を、送受信部２１０を用いてサーバ装置１００に送信する処理状態送信制御部２３０とを持つことにより、機器３００に分散したデータを効率よく検索することができ、サーバ装置１００の処理負荷を軽減させることができる。

具体的には、少なくとも一つの実施形態によれば、サーバ装置１００は、クエリ管理をゲートウェイ装置２００で行うことができる。また、少なくとも一つの実施形態によれば、ゲートウェイ装置２００ごとに算出される充足度合に基づいて、クエリが成功したか否かを迅速に把握することができる。これにより、サーバ装置１００は、全機器３００の処理状態を管理する必要がなくなる。そのため、サーバ装置１００の処理負荷を軽減させることができる。

また、少なくとも一つの実施形態によれば、多数の機器３００に対する並列検索処理を迅速に行うことができる。また、少なくとも一つの実施形態によれば、クエリ結果に対する「質」の管理を適切に行うことができる。また、少なくとも一つの実施形態によれば、どの機器がクエリ処理を完了したのかを管理することができるとともに、クエリ結果の信頼性を判定することができる。

本発明のいくつかの実施形態を説明したが、これらの実施形態は、例として提示したものであり、発明の範囲を限定することは意図していない。これら実施形態は、その他の様々な形態で実施されることが可能であり、発明の要旨を逸脱しない範囲で、種々の省略、置き換え、変更を行うことができる。これら実施形態やその変形は、発明の範囲や要旨に含まれると同様に、特許請求の範囲に記載された発明とその均等の範囲に含まれるものである。

１…データ検索システム、１００…サーバ装置、１１０…検索実行部、１２０…配信部、１３０…処理状態受信部、１４０…完了判定部、１５０、２４０、３３０…記憶部、２００…ゲートウェイ装置、２１０，３１０…送受信部、２２０…処理状態管理部、２３０…処理状態送信制御部、３００…機器、３２０…クエリ実行部

Claims (8)

1. 第１の装置と、第２の装置とを備えるデータ検索システムであって、
   前記第１の装置は、
   データを保持可能な１以上の機器に対して、クエリを配信する配信部と、
   前記第２の装置から、前記１以上の機器の前記クエリに対する処理状態を示す情報を受信する処理状態受信部と、
   前記処理状態受信部により受信された処理状態から前記クエリが完了したか否かを判定する完了判定部と、を備え、
   前記第２の装置は、
   前記第１の装置により配信されたクエリを受信して、前記１以上の機器に送信する送受信部と、
   前記送受信部により受信された、前記１以上の機器ごとの前記クエリの処理結果に基づいて、前記１以上の機器のそれぞれが前記クエリを完了したか否かを示す処理状態を管理する処理状態管理部と、
   前記処理状態管理部により管理された前記クエリの処理状態を、前記送受信部を用いて前記第１の装置に送信する処理状態送信制御部と、を備える、
   データ検索システム。
2. 前記処理状態管理部は、前記クエリを送信した１以上の機器のうち、前記クエリに対する処理が完了したものの割合に基づいて、前記クエリの結果に対する充足度合を算出し、
   前記処理状態送信制御部は、前記充足度合を前記処理状態として、前記送受信部を用いて前記第１の装置に送信する、
   請求項１に記載のデータ検索システム。
3. 前記完了判定部は、前記第２の装置ごとの前記クエリの結果に対する充足度合に基づいて、前記クエリが成功したか否かを判定する、
   請求項２に記載のデータ検索システム。
4. 前記完了判定部は、前記第２の装置ごとの前記クエリの結果に対する充足度合の総和を前記第２の装置の数で除算した値が閾値以上である場合に、前記クエリが成功したと判定する、
   請求項２または３に記載のデータ検索システム。
5. 前記処理状態送信制御部は、前記充足度合とともに、前記クエリを送信した１以上の機器の数に関する情報を前記処理状態として、前記送受信部を用いて前記第１の装置に送信し、
   前記完了判定部は、前記第２の装置ごとの充足度合と前記機器の数との積の和を、前記第２の装置ごとの前記機器の数の和で除算した値が閾値以上の場合に、前記クエリが成功したと判定する、
   請求項２から４のうち、いずれか１項に記載のデータ検索システム。
6. 前記処理状態管理部は、前記１以上の機器ごとに保持されたデータのデータサイズと、前記クエリに対する処理を完了した機器に保持されたデータのデータサイズとに基づいて、前記クエリの結果に対する充足度合を算出する、
   請求項２から５のうち、いずれか１項に記載のデータ検索システム。
7. 前記配信部は、前記データを保持可能な１以上の機器のうち、所定のグループ条件によりグループ化された機器に対して前記クエリを配信する、
   請求項１から６のうち、何れか１項に記載のデータ検索システム。
8. 第１の装置が、
   データを保持可能な１以上の機器に対して、クエリを配信し、
   第２の装置から、前記１以上の機器の前記クエリに対する処理状態を示す情報を受信し、
   受信された処理状態から前記クエリが完了したか否かを判定し、
   前記第２の装置が、
   前記第１の装置により配信されたクエリを受信して、前記１以上の機器に送信し、
   前記１以上の機器から受信された、前記１以上の機器ごとの前記クエリの処理結果に基づいて、前記１以上の機器のそれぞれが前記クエリを完了したか否かを示す処理状態を管理し、
   管理された前記クエリの処理状態を、前記第１の装置に送信する、
   データ検索方法。

Images