JP2011034255A - 計算機システム及び複数計算機によるストリームデータ分散処理方法 - Google Patents

Abstract

【課題】 計算機システムにおいて、複数台の計算機を用いてクエリを分散処理するように構成する際に、特に端末同士の位置関係を処理する場合は分割キーを座標とするべきだが、この場合は端末の移動に伴い割り当てデータ演算装置が変わる。解決しようとする問題点は、このとき、主キーに関する制約を含むクエリはCPUやメモリを無駄に消費してしまう点である。
【解決手段】 複数台の計算機を含む計算機システムで、クエリの分散処理を行う場合、異なる計算機間でクエリとウインドウを引き継ぐ。
クエリ実行時に、初見の主キー値を持つタプルを検出した際に、関連する個別クエリとそのウインドウを計算機間で引き継ぎ、さらに関連する共通クエリのウインドウを計算機間で引き継ぐ。
【選択図】 図１

Description

本発明は、情報処理システムに関し、特に、複数の計算機の分散処理によるストリームデータ処理に関するものである。

従来のデータ処理技術では一般的に関連データベース（以下RDBと略す）技術が用いられてきた。RDBを用いて大量のデータを短いレスポンスタイムで処理する際の問題点は、主に一度データを主記憶より遅いディスクに保存する点と、保存したデータに対して後からバッチ的にクエリを適用する点である。近年、主記憶のコストが下がりデータを主記憶上に保存する技術が普及した事からディスクに保存する事によるレスポンスタイム増加の影響は少なくなっているものの、RDBを用いてバッチ的にクエリを適用する事によるレスポンスタイムは、増加する。

ストリームデータ処理技術は、あらかじめクエリをシステムに登録し、データがシステムに到来すると、差分的にクエリを適用する事によってRDBの欠点を解消する。また、CQLと呼ばれる宣言型のクエリ定義言語を用いることで、クエリを容易に記述できる。

ストリームデータ処理技術は、スライディングウインドウを用いてストリームデータとリレーショナルデータに効率よく変換する。またストリームデータ処理技術は、リレーショナルデータに対してSQLと同等の処理を容易に記述できるよう、SQLにストリームデータとリレーショナルデータの変換演算を追加したCQLというクエリ記述言語を用いる。さらに、ストリームデータ処理技術は、リレーショナルデータに対する処理のうち特に集計処理が高速に行えるよう、集計演算をインメモリで差分を演算する

A.Arasu et al、「STREAM : The Stanford Stream Data Manager」IEEE Data Engineering Bulletin, Vol. 26、2003年

ストリームデータ処理は、メモリ上で差分演算を行うため、1台の分散計算機だけを用いても処理能力が非常に高いが、それでも処理能力が不足する場合には複数のデータ演算装置に処理を分割させる。

ここでストリームデータ処理は、ウインドウ長分の状態を持つ処理のため、状態を考慮して処理を分割させる必要がある。

ストリームデータ処理システムを構成する計算機は、時間ウインドウに代表される時刻をトリガにクエリ内部で発火するイベントを処理する。そのため、計算機の実装は完全なイベントドリブン処理にはならず、ストリームデータ処理システムにイベントであるデータが到着しない時にも時間の管理などの処理を行う必要がある。この処理の過程でデータの有無にかかわらず全ての時間ウインドウを持つクエリおよび時間ウインドウを持つクエリの出力を入力に取るクエリを実行する必要がある。したがって、ストリームデータ処理システムに時間ウインドウを持つクエリを登録すると、データの有無に依らずCPUリソースと場合によってはメモリリソースを消費する。ここでは、時間ウインドウを持つクエリによるCPUリソースおよびメモリリソースの消費を空振りと呼ぶ。

したがって、ストリームデータ処理を、複数台の計算機を用いて分散処理するように構成する際に、特に端末同士の位置関係を処理する場合は分割キーを座標とするべきだが、この場合は端末の移動に伴い割り当て計算機が変わり、計算機それぞれでクエリやウインドウを管理する必要がある。また、主キーに関する制約を含むクエリの場合は、CPUやメモリを無駄に消費してしまう。

上記課題の少なくとも一を解決するために、本発明の一態様は、クエリを実行する複数の計算機のうち一の計算機であって、タプルを受信した場合、他の計算機からクエリの実行に必要なデータやクエリそのものを取得する。また、別の態様は、その取得先の候補を計算機それぞれが管理する。

より具体的には、クエリ実行時に初見の主キー値を持つタプルを検出した際に、そのクエリに関係するウインドウを計算機間で引き継ぐ態様としてもよい。さらには、関連する他のクエリと他のクエリに関係するウインドウを計算機間で引き継ぐ態様としてもよい。その他の態様は、後述する実施の形態で明らかにされる。

本発明の一態様によると、異なる計算機間でのクエリ処理の分散が可能となる。

位置情報処理システムの構成例を示す図である。 領域の分割とサーバの割り当ての関係を模式的に示す図である。 実施例１におけるクエリ登録処理フロー示す図である。 実施例１における共通クエリの処理フロー示す図である。 実施例１におけるウインドウ取得部の処理フローを示す図である。 ウインドウ送信部の処理フローを示す図である。 ウインドウ削除処理の処理フローを示す図である。 実施例２における管理計算機１０３の構成例を示す図である 実施例２におけるクエリ登録処理フロー示す図である。 実施例２における共通クエリの処理フロー示す図である。 個別クエリ取得部の処理フローを示す図である。 個別クエリ送信部の処理フローを示す図である。 実施例２におけるウインドウ取得部の処理フローを示す図である。 個別クエリ送信管理部の処理フローを示す図である。 ウインドウ送信管理部の処理フローを示す図である。 個別クエリdrop処理の処理フロー示す図である。 ウインドウ削除処理を示すフロー図である。 削除命令データを受け取った場合の処理フローを示す図である。 実施例３の全体構成を示す図である。 実施例２の変形例におけるクエリを登録する処理フローを示す図である。 遷移元管理表を示す図である。 実施例１における分散計算機１０２の構成を示す図である。 実施例２における分散計算機１０３の構成ｔを示す図である。

複数台の分散計算機を含むストリームデータ処理を行う例として、位置情報処理を例にして説明する。

位置情報処理では「〜の近所に」という条件を含むクエリが頻出する。そのため、複数の分散計算機に処理を分割させる場合、これらのクエリを処理する際の分散計算機間での通信が少なくなるように処理を分割する方式が望ましい。このような分割方式として座標による分割が知られている。

図２は、領域の分割とサーバの割り当ての関係を模式的に示す図である。図２に座標による処理の分割方式の例を示す。この例ではある地域を6つの領域１６１−１６６に分割し、それぞれの領域に分散計算機１０２a-fを1つずつ割り当てている。このように処理を分割することで「〜の近所に」という条件を含むクエリを効率よく処理できる。つまり、0<=lat<30かつ0<=lon<30であるエリア１６１から発生するデータが分散計算機#1に、0<=lat<30かつ30<=lon<60であるエリア１６２から発生するデータが分散計算機#2に、0<=lat<30かつ60<=lon<=90であるエリア１６３から発生するデータが分散計算機#３に、30<=lat<60かつ0<=lon<30であるエリア１６４から発生するデータが分散計算機#4に、30<=lat<=90かつ30<=lon<=90であるエリア１６５から発生するデータが分散計算機#5に、60<=lat<=90かつ0<=lon<30であるエリア１６６から発生するデータが分散計算機#6に分配される。分配されたデータについて、分散計算機１０２a-fはそれぞれストリーム処理を行う。

具体的には、デバイスであるGPS付き携帯電話のような移動体を追跡するシステムにおいて、電話番号000-0000-0000の携帯電話と電話番号111-1111-1111の携帯電話が100m以内に接近した事を検出するクエリ1は、6つの分散計算機全てに割り当てることで、分散計算機間での通信を行うことなくクエリを処理できる。
また、全ての携帯電話について携帯電話の移動速度を算出するクエリ2も6つの分散計算機全てに割り当てることで、分散計算機間での通信を行うことなくクエリを処理できる。さらに北緯aaa東経bbbである地点に来た携帯電話にメッセージを送るクエリ3は北緯aaa東経bbbである地点が割りあたった分散計算機#5に割り当てることで、分散計算機間での通信を行うことなくクエリを処理できる。

しかし、座標による分割を行った場合にも、移動体を追跡するシステムでは、分散計算機のCPUおよび主記憶リソースを不要に多く使ってしまうという課題がある。具体的には、先の携帯電話の例を再び取り上げると、電話番号000-0000-0000の携帯電話移動に伴い実際に処理を行う分散計算機が変わるため、クエリ1やクエリ2においてROWウインドウを使った場合は、過去に処理を行った分散計算機に不要なROWウインドウが残る。また、クエリ1のように特定の端末に関するクエリは全ての分散計算機に割り当てられるため、電話番号000-0000-0000の携帯電話および電話番号111-1111-1111の携帯電話が存在しない領域に割り当てられた分散計算機上では空振りしてしまい、無駄にCPUおよび主記憶リソースを消費してしまう。

ここで携帯電話を追跡するシステムにおいて、電話番号はここの携帯電話を一意に識別できる値であり、RDBにおける外部キーと言い換えることができる。本明細書では外部キーという用語を用いて、上記のクエリ1からクエリ3を個別クエリ、共通クエリ、一般クエリの3種類に分けて扱う。

個別クエリとはRDBにおける外部キーに関する等号条件もしくは不等号条件を持つクエリを指す。具体的にはクエリ1のように電話番号の等号条件を含むクエリが個別クエリとなる。

共通クエリとは外部キー値ごとの集計演算を行うクエリを指す。具体的にはクエリ2のように電話番号ごとに集計を行うクエリが共通クエリとなり、CQLには外部キーによるpartition by制約が付加される。

一般クエリとは個別クエリにも共通クエリにも属さないクエリの事を指す。具体的には制約を持たないか、クエリ3のように外部キーとは無関係な座標による制約を持つクエリなどが一般クエリとなる。

実施例１は、位置情報であるGPS情報を定期的に発信する携帯電話をデータソースとし、かつ個別クエリを使わない位置情報処理システムの例である。携帯電話が発信するデータは、携帯電話番号を特定するid（identifier、識別子）列と現在地の緯度経度をそれぞれ表すlon列およびlat列を含む位置情報とを有する。本実施例のid列はRDBにおける外部キーの役割を果たしている。

図１は、本実施例による位置情報処理システム101の構成を示す。位置情報処理システム101は、複数の分散計算機102と管理計算機103とデータ分配装置104とを有する計算機システムである。各分散計算機１０２、管理計算機１０３、データ分配装置１０４は、ネットワーク１９０を介して接続される。

管理計算機103は、CPU116と主記憶117とストレージ119とネットワークインターフェース１５１を有し、それぞれバスを介して接続される。主記憶１１７は、プログラムである遷移元管理表管理部１１８を保持する。ストレージ１１９は、遷移元管理表１１４を格納している。CPU１１６は、主記憶117上の遷移元管理表管理部118を実行する。またCPU１１６は、ストレージ119上に遷移元管理表114を保存する。

遷移元管理表114は、データを処理すべき分散計算機102a-fへの割当てを管理する。遷移元管理表114は、あるデータ分散計算機に対して地理的に隣接したデータ装置の識別子である名前を管理する。

図2に領域の分割と分散計算機の割り当ての例を示す。ここでは領域201を6つの領域に分割し、そこへ分散計算機#1(１０２a)から分散計算機#6(102f)を1つずつ割り当てている。これら6つの分散計算機102a-fの地理的な隣接関係を図１や図２１の遷移元管理表１１４で管理する。

データ分配装置104は、各分散計算機１０２a-fとネットワークを介して接続される。各携帯電話＃1-#6からのデータをlat列およびlon列の値に従い複数の分散計算機102に分配する。本実施例では、図２に示されるように、0<=lat<30かつ0<=lon<30であるエリア１６１から発生するデータが分散計算機#1に、0<=lat<30かつ30<=lon<60であるエリア１６２から発生するデータが分散計算機#2に、0<=lat<30かつ60<=lon<=90であるエリア１６３から発生するデータが分散計算機#３に、30<=lat<60かつ0<=lon<30であるエリア１６４から発生するデータが分散計算機#4に、30<=lat<=90かつ30<=lon<=90であるエリア１６５から発生するデータが分散計算機#5に、60<=lat<=90かつ0<=lon<30であるエリア１６６から発生するデータが分散計算機#6に分配される。データの分配処理は、データ分配装置１０４により、既存のルータ技術を用いて容易に実現できる。また、携帯電話の通信方式によっては、分散計算機に相当する処理を携帯電話の基地局が行うことで、データ分配装置が不要になることも考えられる。 分散計算機102（a-f）は、データ分配装置１０４から分配されるデータについて、ストリームデータ処理に基づく演算を行う。

図２２は、分散計算機１０２の構成を示す図である。分散計算機102は、CPU120と主記憶121とストレージ122とネットワークインターフェース１２５と有し、それぞれバスを介して接続される。主記憶121上のクエリ実行制御部105とウインドウ取得部107とウインドウ送信部109の各プログラムと、一般クエリ格納部110と共通クエリ格納部112と、を保持する。CPU120は、主記憶で保持される各プログラムを実行する制御部である。ＣＰＵ１２０は、ウインドウ格納部113にウインドウデータを主記憶１２１に保存する。またストレージ122上の一般クエリ格納部110と共通クエリ格納部112にそれぞれ、一般クエリ、共通クエリを保存する。なお、各プログラムは、ストレージ１２２などの不揮発性記憶媒体に格納されていてもよい。ＣＰＵ１２０がプログラムを実行するときに、プログラムは、主記憶１２１に展開される。ネットワークインターフェース１２５は、ネットワークに接続し、管理計算機１０３や分配装置１０４からのデータや制御命令の送受信を行う。

クエリ実行制御部105は、データ分配装置104からデータを受け取り、一般クエリ格納部110および共通クエリ格納部112に格納された各クエリを実行し、結果を生成するプログラムである。結果は、位置情報処理システム101の外に出力されるが、処理内容によって結果を他の分散計算機102へ送信し、他の分散計算機１０２の入力とすることもできる。また、クエリ実行制御部105は、ウインドウ取得部107を介して他の分散計算機102もしくは管理計算機103からウインドウを受け取る。

ウインドウ取得部107は、クエリ実行制御部105の指示に従い、他の分散計算機102のウインドウ送信部109と通信し、ウインドウを受け取る。ウインドウ取得部１０７は、受け取ったウインドウをウインドウ格納部111に格納する。

ウインドウ送信部109は、他の分散計算機102のウインドウ取得部107の指示に従い、ウインドウ納部111に格納されたウインドウを他の分散計算機102のウインドウ取得部107に送信する機能を持つ。

一般クエリ格納部110は、分散計算機102で実行すべき一般クエリを格納する記憶領域である。ここではストリームデータ処理技術において一般的に用いられるCQLで書かれたクエリを文字列として保存する。クエリを実行する際には、クエリ実行制御部105によって、クエリ文字列が実行可能なプログラムに変換される。

共通クエリ格納部112は、共通クエリを格納する記憶領域である。

ウインドウ格納部113は、クエリ実行制御部が実行するプログラム（クエリ）中で使用するウインドウのデータを保持する保持領域で、例えば、主記憶（メモリ）に構成される。つまり、ウインドウ格納部１１３は、ウインドウのデータを格納する記憶領域である。ウインドウのデータは、例えば、外部から受信したデータタプルや、クエリの実行により生成された集計タプルまたは二次タプルや、制御タプルである。ウインドウに保持されるタプルは、クエリの実行時に再利用される。

図２１に、遷移元管理表１１４を示す。遷移元管理表１１４は、遷移先識別子209と遷移元識別子リスト210の2列からなる表である。本実施例では、遷移元管理表はシステム構築時の初期設定としてユーザが与えることを想定しているが、遷移元管理表を管理するモジュールを追加して、計算機やデータ分配装置の動的な構成変更に対応させることも容易である。

続いて位置情報処理システム101を用いた運用例を記す。図３は、位置情報処理システム101が、クエリを登録する際の処理フローを示す図である。外部から入力されたクエリを、管理計算機103が受け付ける。クエリ登録処理フロー開始後（301）、ＣＰＵ１１６は、まず、受け付けたクエリが共通クエリか否かを判断する（304）。共通クエリであった場合は、ＣＰＵ１１６は、全ての分散計算機102の共通クエリ格納部112にクエリをネットワークを介して登録する（305）。共通クエリではない場合は、単一もしくは複数の分散計算機102で実行すべき一般クエリであるため、ＣＰＵ１１６は、ネットワークを介して、該当する分散計算機102の一般クエリ格納部110にクエリを登録する（306）。各登録処理305、306が終了したらクエリ登録処理を終了する（307）。

続いて、携帯電話からデータを受信した際の、各分散計算機102の処理フローを記す。前述のとおりデータを受信した場合、分散計算機１０２は、一度キューに保存され、クエリ実行制御部105が各クエリを実行するタイミングでクエリごとに必要なキューからデータがプルされる。

図4に共通クエリの処理フローを示す。共通クエリ処理フローはクエリ実行制御部１０５が共通クエリ格納部112を参照し、格納された個々のクエリの実行を開始することから始まる。クエリ実行制御部１０５は、共通クエリ処理フローを開始し、適等なキューからデータを取得する（401）。ここで取得したデータのid列の値は"000-0000-0000"であるとする。続いて、クエリ実行制御部１０５は、該データのid列に相当するウインドウがあるか否かを判断する（402）。ウインドウが既にあった場合は、クエリ実行制御部１０５は、クエリを実行し（405）、処理を終了する（406）。クエリの実行処理405は従来技術と同等である。判断（402）の結果、クエリ実行制御部１０５は、概データのid列に相当するウインドウがなかった場合は、列名と値すなわちここでは"id,000-0000-0000"を引数にウインドウ取得部を実行する（404）。ウインドウ取得部107の処理フロー詳細は図５に後述する。その後、取得したウィンドウを用いて、クエリを実行し（405）、処理を終了する（406）。

なお、共通クエリ処理フローの判断ステップ402において、ウインドウなしと判断される場合とは、たとえば、携帯電話が、他の分散計算機の管轄（エリア）から自らの管轄に移動してきた場合である。例外的にトンネルなど電波状況の悪いところから電波状況の良いところに移動した場合や、電源を切っていたものを入れた場合なども考えられるが、これらもまとめて自らの管轄に移動してきた場合の一種として扱うことが出来る。つまり、ウインドウの移動は、携帯電話の移動を契機に実行される。

図5にウインドウ取得部１０７の処理フローを示す。ウインドウ取得部107は、列名と値を引数に処理開始後（501）、ループ処理の為にカウンターとなる変数iに1を代入し（502）、続いて本取得処理によりウインドウを取得できたか否か判断するための変数iにfalseを代入する（503）。その後、ウインドウ取得部１０７は、jがtrueであるか判断し（504）、trueであれば処理を終える（510）。

jがtrueではない場合は、ウインドウ取得部１０７は、管理計算機103から遷移元管理表114に記載されたi番目の遷移元識別子を取得する（505）。ここで変数iが十分に大きい値をとる場合や、取得ステップ505の結果、i番目の遷移元識別子が取得できない場合は、ウインドウ取得部１０７は、i番目の遷移元識別子を取得できたか否か判断する（506。取得できていた場合は、ウインドウ取得部１０７は、i番目の遷移元分散計算機のウインドウ送信部に列名と値 ("id, 000-0000-0000") を送信する。

そして、ウインドウ取得部１０７は、クエリ名とウインドウ内容のセットのリストを受信する（507）。受信(507)の結果、ウインドウ取得部１０７は、i番目の遷移元分散計算機のウインドウ送信部から、クエリ名とウインドウの内容を受信できたか否か判断し（508）、受信できた場合、ウインドウ取得部１０７は、jにtrueを代入する（509）。

ウインドウ取得部１０７は、その後カウンター変数iをインクリメントし（510）、判断（504）に戻る。判断506の結果、i番目の遷移元識別子を取得できなかった場合には、概列名と値に対応する携帯電話が電源を切って移動してきたなど、地理的に非連続な領域から移動してきた可能性がある。本実施例ではこの場合はウインドウの取得をあきらめ、その後処理を終える512。

図６は、ウインドウ送信部１０８の処理フローを示す。ウインドウ送信部108は、列名と値 ("id, 000-0000-0000") を引数に処理開始後（601）、共通クエリ格納部112に該列名に関連するクエリがあるか否か判断する（602）。たとえば、本実施例の場合、partition by idを含むクエリが関連するクエリである。ウインドウ送信部１０８は、判断602の結果関連するクエリがなかった場合は、空のリストを返信し（603）、処理を終える（609）。

判断ステップ602の結果関連するクエリがあった場合、ウインドウ送信部１０８は、該クエリが該列名と値に関するウインドウをもつか否か判断する（604）。判断の結果、関連するウインドウがなかった場合は、ウインドウ送信部１０８は、空のリストを返信する（603）。

判断ステップ604の結果関連するウインドウがあった場合、ウインドウ送信部１０８は、該クエリのクエリ名を取得し（605）、該クエリの実行時オブジェクトのウインドウをダンプする（606）。クエリ名とウインドウのダンプのセットを個別クエリ取得部へ返信し（607）、ウインドウを削除し（608）、処理を終える（609）。ウインドウの削除607処理の詳細は後述する。

ウインドウ削除処理を図７に示す。ウインドウ削除処理開始後（1001）、該共通クエリの出力として削除命令データを出力し（1002）、その後、該ウインドウを削除1003し、処理を終える（1004）。
上述の実施例により、データソースである端末からのネットワークを介して受信するデータのストリーム処理を分散して実行することができる。

実施例２は、GPS情報を定期的に発信する携帯電話をデータソースとし、個別クエリを使うことが出来る位置情報処理システムの例である。携帯電話が発信するデータは、携帯電話番号を表すid列と現在地の緯度経度をそれぞれ表すlon列およびlat列からなる。本実施例のid列はRDBにおける外部キーの役割を果たしている。

図８に実施例２における管理計算機１０３の構成例を示す。管理計算機１０３の主記憶１１７には、個別クエリ送信管理部824、ウインドウ送信管理部825が保持される。ストレージ１１９には、分散計算機一覧表８２６、個別クエリマスタレポジトリ815、遷移元管理表１１４が格納されている。

分散計算機一覧表826には、管理計算機１０３の管理対象である分散計算機の一覧が記される。本実施例では、システム構築時の初期設定としてユーザが与えることを想定しているが、分散計算機一覧表を管理するモジュールを追加して、分散計算機の動的な構成変更に対応させてもよい。
個別クエリマスタレポジトリ815は、情報処理システム801に登録された個別クエリのうち、いずれの分散計算機102でも実行されていないクエリを保存するレポジトリである。

図２３は、実施例２における分散計算機１０２の構成例である。図２２に示す実施例１における分散計算機１０２の構成にさらに、個別クエリ送信部808と、個別クエリを扱うために個別クエリ取得部806とが主記憶１２１に保持され、ＣＰＵ１２０が各部を実行する。個別クエリ送信部808と、個別クエリ取得部806は、ストレージ１２２にプログラムとして格納されて、ＣＰＵ１２０が実行するときに、プログラムが主記憶１２１に展開される。ストレージ１２２には、個別クエリ格納部811が構成されている。

以下、本実施例で個別クエリを扱うために追加した個別クエリ取得部806、個別クエリ送信部808、個別クエリ格納部811および個別クエリマスタレポジトリ815に関する部分について主に説明する。

個別クエリ取得部806は、クエリ実行制御部105の指示に従い、他の分散計算機102の個別クエリ送信部808と通信しクエリを受け取り、受け取ったクエリをクエリ格納部811に格納するプログラムである。

個別クエリ送信部808は、他の分散計算機102の個別クエリ取得部806の指示に従い、クエリ格納部811に格納されたクエリを他の分散計算機102の個別クエリ取得部806に送信するプログラムである。

個別クエリ格納部811は分散計算機102で実行すべき個別クエリを格納する記憶領域である。ここではストリームデータ処理技術において一般的に用いられるCQLで書かれたクエリを文字列として保存する。クエリを実行する際には、クエリ実行制御部105によってクエリ文字列が実行可能なプログラムに変換される。

情報処理システム801に、クエリを登録する際の処理フローを図9に記す。本実施例では、ＣＰＵ１１６は、クエリ登録処理開始301の後、まずクエリが個別クエリか否か判断する（902）。判断ステップ（902）の結果、ＣＰＵ１１６は、個別クエリであればクエリを個別クエリマスタレポジトリ８１５に登録する（903）。ＣＰＵ１１６は、個別クエリマスタレポジトリ８１５に、該クエリのクエリ定義文を登録する。

続いて、各分散計算機102に携帯電話からデータを受信した際の処理フローを記す。

共通クエリの処理フローを図10に示す。図１０の４０１と４０２の処理は、図４と同様で、ある。４０２の判断結果、クエリ実行制御部１０５は、受信したデータタプルのuidに該当するウインドウがある場合は、ウインドウ取得部を実行404する前に、uid=a、つまり列名と値を引数に、個別クエリ取得部を実行する（1003）。

次に、図１０の処理１００３に対応する個別クエリ取得部８０６の処理フローを図11に示す。個別クエリ取得部８０６は列、名と値を引数に処理開始1101後、ループ処理の為にカウンターとなる変数iに1を代入1102し、続いて本取得処理によりクエリを取得できたか否か判断するための変数iにfalseを代入1103する。その後jがtrueであるか判断し（1104）、trueであれば処理を終える（1112）。jがtrueではない場合は、個別クエリ取得部８０６は、管理計算機１０３に対して、遷移元識別子の取得要求し、管理計算機103から遷移元管理表114に記載されたi番目の遷移元識別子を取得する（1105）。

ここで変数iが十分に大きい値をとる場合には取得1105の結果、i番目の遷移元識別子が取得できないこともあるため、i番目の遷移元識別子を取得できたか否か判断する（1106）。取得できていた場合は、個別クエリ取得部８０６は、i番目の遷移元計算機の個別クエリ送信部に列名と値 ("id, 000-0000-0000") を渡し、クエリ定義文字列とウインドウ内容のセットのリストを受信する（1107）。

受信ステップ1107の結果、個別クエリ取得部８０６は、クエリ定義文字列とウインドウの内容を受信できたか否か判断する（1108）。判断結果、受信できた場合、個別クエリ取得部８０６は、jにtrueを代入し（1109）、カウンター変数iをインクリメントし（1110）、判断ステップ1104に戻る。

判断ステップ1106の結果、i番目の遷移元識別子を取得できなかった場合には、概列名と値に対応する携帯電話が電源を切って移動してきたなど、地理的に非連続な領域から移動してきた可能性や、クエリが情報処理システム801に登録されたばかりでまだ個別クエリマスタレポジトリ815に入っている可能性がある。本実施例ではこの場合の取得処理は管理計算機１０３に概列名と値を渡しクエリ定義文字列とウインドウ内容のセットのリストを受信する（1111）。管理計算機側での処理の詳細は後述する。その後処理を終える（1112）。

図１１に対応する、管理計算機１０３側の個別クエリ送信部808の処理フローを図12に示す。個別クエリ送信部808は、列名と値 ("id, 000-0000-0000") を引数に処理開始後（1201）、個別クエリ格納部111に該列名と値に関連するクエリがあるか否か判断する（1202）。たとえば、本実施例の場合、where id="000-0000-0000"を含むクエリが関連するクエリであるが、id列が整数型であるようなデータの場合に"id, 100"に関連するクエリとしてwhere id > 10やwhere id < 1000を含むクエリがある。

判断ステップ1202の結果、関連するクエリがなかった場合、個別クエリ送信部８０８は、空のリストを返信し（1203）、処理を終える（1208）。関連するクエリがあった場合、該クエリのクエリ定義文を取得し（1204）、該クエリの実行時オブジェクトのウインドウをダンプする（1205）。そして、個別クエリ送信部８０８は、個別クエリ定義文とウインドウのダンプのセットを個別クエリ取得部へ返信し（1206）、クエリをdropし（1207）、処理を終える（1208）。クエリのdrop処理1207の詳細は図１６で後述する。
また、図１３は、実施例２におけるウインドウ取得部１０７の処理を示す。 本実施例では、ウインドウ取得部が、図７における判断ステップ706で否であった場合、つまりどの遷移元分散計算機１０２からもウインドウ受信部からも受信できなかった場合に、個別クエリ取得部の処理フロー (図11) と同様に、管理計算機１０３に概列名と値を渡しクエリ定義文字列とウインドウ内容のセットのリストを受信する（1311）。
なお、ウインドウ送信部の動作は、実施例１の図６と同様である。

図１４は、個別クエリ送信管理部824の処理フローを示す。個別クエリ送信管理部824は、遷移元管理表１１４に記載された分散計算機から個別クエリを取得できなかった際に、個別クエリ取得部８０６から呼び出される。処理開始1401後、個別クエリ送信管理部８２４は、個別クエリマスタレポジトリ８１５から該個別クエリ定義文字列を取得1402し、取得できたか否か判断する（1403）。判断の結果、取得できていれば、個別クエリ送信管理部８２４は、空のウインドウを生成し（1404）、クエリ定義文字列とウインドウのセットを個別クエリ取得部に送信1406し、処理を終了1407する。取得できていなかった場合は、計算機一覧表に記された全計算機の個別クエリ送信部から該個別クエリ定義文字列とウインドウを取得し（1405）、クエリ定義文字列とウインドウのセットを個別クエリ取得部806に送信し（1406）、処理を終了する（1407）。

図１５は、ウインドウ送信管理部８２５の処理フローを示す。この処理は、遷移元管理表に記載された分散計算機１０２からウインドウを取得できなかった際に、ウインドウ取得部１０７から呼びだされる処理である。処理開始後（1501）、ウインドウ送信管理部８２５は、計算機一覧表に記された全計算機のウインドウ送信部からクエリ名とウインドウ内容のセットを取得し（1502）、ウインドウ取得部にクエリ名とウインドウ内容のセットを送信し（1503）、処理を終了する（1504）。

図16は、図１２のステップ１２０７の詳細、つまり、個別クエリのdrop処理を示す。個別クエリのdrop準備処理開始後（1601）、個別クエリ送信部８０８は、該個別クエリの出力として削除命令データを出力し（1602）、その後該個別クエリを削除し（1603）、処理を終える（1604）。ここで削除命令データは管理用の特別なデータであり、削除対象となるウインドウ内のデータを識別できるように列名と値との組み合わせ ("id, 000-0000-0000") を含む。削除命令データを受け取ったクエリの動作は、図１８で後述する。

ウインドウ削除処理を図17に示す。ウインドウ削除処理開始1701後、該共通クエリの出力として削除命令データを出力し（1702）、その後該ウインドウを削除し（1703）、処理を終える（1704）。

削除命令データを受け取った場合の処理フローをを図18に示す。分散計算機１０２は、削除命令データを受け取った場合、削除命令データに該当するクエリ内の全てのウインドウに対してウインドウ内の不要なデータの削除処理1801を行う。ウインドウ内の不要なデータの削除処理（１８０１）開始後、該削除命令データに含まれる列名と値の組み合わせを参照し、ウインドウ内に同列が同じ値であるデータがあるか否か判断にする（1802）。判断ステップ1802の結果、データがなかった場合は処理を終える（1805）。判断ステップ1802の結果、1つまたは複数のデータがあった場合は、該データを全て削除し（1803）、必要に応じて集計演算をやり直し（1804）、処理を終える（1805）。

次に、実施例２の変形例を説明する。実施例２では、実施例1を元に個別クエリを扱えるようにするために個別クエリマスタレポジトリなどを追加したが、変形例では、分散計算機１０２の空振り増加が許容できるのであれば、実施例1の構成において、個別クエリを共通クエリとして同様に扱う。

本変形例では、図20の処理フローに従い位置情報処理システム101にクエリを登録する。図20の処理フローは実施例１の図3の処理フローと主要な動作は同様であるが、クエリ登録処理開始後（301）、まず個別クエリか否かを判断し（2002）、個別クエリであった場合は、全ての計算機の共通クエリ格納部に登録する（305）。

その他の部分は実施例1の場合と同様である。

実施例３は、株価の取引を監視する装置の例である。実施例1および2では、管理計算機１０３が、携帯端末からのデータを複数の分散計算機間でまたがる際の処理を説明した。変形例１では、株価取引監視装置において複数の分散計算機の分割閾値が変化した際の対応処理を説明する。

図19は、株価取引監視システム1901を示す。取引監視システム１９０１では、管理計算機１０３、分散計算機1902及び１９０３、そして。データ分配装置１０４を備える計算機システムである。負荷分散のため、2つの分散計算機1902および1903が、演算を行う。2つの分散計算機へのデータの分配は実施例1と同じくデータ分配装置104を用いて行い、ここでは株の銘柄番号を表すid (識別子、Identifier)が10,000より大きいか否かで分配先を決定する。

またこちらも実施例２の場合と同じく管理計算機１０３を用いて遷移元管理表1209と個別クエリの管理を行う。なお、管理計算機103の構成は、実施例２と同様のものであるが、ここでは図を簡略化するため、遷移元管理表以外の構成要素を省略した。実際には、CPUと主記憶とストレージとネットワークインターフェースを備え、分散計算機とネットワークを介して接続する計算機である。主記憶は遷移元管理表管理部とクエリ送信管理部とウインドウ送信管理部を持ち、ストレージは遷移元管理表と分散計算機一覧表と個別クエリマスタレポジトリを持ち、主記憶上の各管理部及び送信部はCPUによって実行される。

分散計算機１９０２及び１９０３は、図２２や図２３のような構成を有している。

株価取引監視システム1901では銘柄番号であるid列を用いてデータを分割しており、これはRDBにおける外部キーによる分割であるため、定常運用時には実施例２のように複数の計算機の間をデータが行き来する事はない。しかし、分散計算機#1 1902と分散計算機#2 1903の間で負荷の偏りが生じた場合に、データ分配装置１０４による分配先を変更することで負荷を均衡化できる。たとえば分散計算機#1 1902の負荷が高くなってしまった場合には、計算機#1 1902へ分配するデータをid <= 8,000、計算機#2 1903へ分配するデータをid > 8,000などと変更することで負荷を均衡化できる。このような負荷の均衡化処理は、実施例２の場合と同じく、同一の外部キー値を持つデータの処理割り当てを複数の分散計算機間で変更し、実施例２の場合と同様に、関連するクエリおよびウインドウを分散計算機#1 1902および分散計算機#2 1903の間で移動させる。

上述した実施形態は、複数の計算機を用いたデータ処理全般、特にストリームデータ処理に適用可能である。

１０１ 位置情報処理装置
１０２ 計算機
１０３ マスターデータ管理装置
１０４ データ分配装置
１０５ クエリ実行制御部
１０６ 個別クエリ取得部
１０７ ウインドウ取得部
１０８ 個別クエリ送信部
１０９ ウインドウ送信部
１１０ 一般クエリ格納部
１１１ 個別クエリ格納部
１１２ 共通クエリ格納部
１１３ ウインドウ格納部
１１４ 遷移元管理表
１１５ 個別クエリマスタレポジトリ
１１６ CPU
１１７ 主記憶
１１８ 遷移元管理表管理部
１１９ ストレージ
１２０ CPU
１２１ 主記憶
１２２ ストレージ

Claims (20)

1. 計算機システムであって、
   第一のメモリを有しクエリを実行可能な第一の計算機と、第二のメモリを有し前記クエリを実行可能な第二の計算機とを、備え、
   前記第一の計算機は、
   外部デバイスからネットワークを介して、ストリームデータを受信し、前記クエリを実行する場合、前記第一のメモリに当該データを保持する第一の保持領域が構成されているか否かを判定し、
   前記第一の保持領域が構成されていた場合、前記第一の保持領域にストリームデータを格納し、前記第一の保持領域に保持されているデータを用いて前記クエリを実行し、
   前記第一の保持領域が構成されていなかった場合、受信したストリームデータに含まれる識別子を前記第二の計算機に送信し、
   前記第二の計算機から前記第一の保持領域に保持すべきデータを受信し、
   前記第一のメモリに、前記受信した保持すべきデータと、前記ストリームデータとを保持する第一の保持領域を構成し、
   前記第一の保持領域に保持されるデータを用いて前記クエリを実行する、
   ことを特徴とする計算機システム。
2. 請求項１記載の計算機システムであって、
   前記第二の計算機は、
   前記第二のメモリに前記クエリに用いるデータを保持する第二の保持領域を構成し、
   前記第一の計算機から、前記識別子を受信した場合、
   前記第二の保持領域に保持される前記識別子に関連するデータを前記第一の計算機に送信する、
   ことを特徴とする計算機システム。
3. 請求項２記載の計算機システムであって、
   前記第二の計算機は、さらに、前記識別子に基づいて、該当する保持領域が構成されているか否かについて前記第２のメモリを検索する、ことを特徴とする計算機システム。
4. 請求項２記載の計算機システムであって、
   前記第２の計算機は、さらに、前記第二の保持領域の構成を前記第二のメモリから削除する、ことを特徴とする計算機システム。
5. 請求項２記載の計算機システムであって、
   前記第２の計算機は、前記クエリに関する実行木から、前記第２の保持領域に保持されるデータをダンプして取得する、ことを特徴とする計算機システム。
6. 請求項１記載の計算機システムであって、
   前記第一の保持領域は、ウインドウであって、前記ウインドウが前記クエリに対応付けられていることを特徴とする計算機システム。
7. 請求項１記載の計算機システムであって、
   前記識別子は、前記クエリに定義されている”partition by ”により指定される識別子である、ことを特徴とする計算機システム。
8. 請求項２記載の計算機システムであって、
   前記保持すべきデータは、前記第２の保持領域に保持されているデータであることを特徴とする計算機システム。
9. 請求項１記載の計算機システムであって、
   前記第二の計算機は複数有し、
   前記第一の計算機が実行するクエリの処理対象であるデータに含まれる識別子は、前記第二の計算機いずれかが実行するクエリの処理対象であるデータに含まれる識別子とは、同じ場合、
   前記第１の計算機は、前記第二の計算機から前記第二の保持領域に保持されているデータを取得する、ことを特徴とする計算機システム。
10. 請求項９記載の計算機システムであって、
    前記第二の計算機は、第二の保持領域に保持されているデータを削除し、第二のメモリから前記第二の保持領域の構成を削除する、ことを特徴とする計算機システム。
11. 請求項１記載の計算機システムであって、
    前記第一の計算機が実行するクエリの処理対象であるデータに含まれる識別子と前記第二の計算機が実行するクエリの処理対象であるデータに含まれる識別子とは、お互いに異なり、
    前記第一の計算機は、前記第二の計算機で実行可能なクエリに必要な情報を、前記第二の計算機から取得し、異なる識別子で特定されるデータに対して前記第二の計算機で実行可能なクエリと同一のクエリを実行することを特徴とする計算機システム。
12. 請求項１記載の計算機システムであって、
    前記第一の計算機は、前記第二の計算機のうち、所定の第二の計算機に前記識別子を送信する、ことを特徴とする計算機システム。
13. 請求項１記載の計算機システムであって、
    前記第一の計算機と前記第二の計算機とに接続される管理計算機をさらに備え、
    前記管理計算機は、
    前記外部デバイスから送信されるデータに含まれる識別子ごとに、当該データを処理すべき第一の計算機または第二の計算機を決定する、ことを特徴とする計算機システム。
14. 請求項１記載の計算機システムであって、
    前記第一の計算機と前記第二の計算機とに接続される管理計算機をさらに備え、
    前記管理計算機は、
    前記第一の計算機に、複数の第二の計算機のうち、前記識別子を含む問い合わせをいずれか一の第二の計算機に行うべきかを通知する、ことを特徴とする計算機システム。
15. 請求項２記載の計算機システムであって、前記外部デバイスは移動体端末であって、前記識別子は、移動体端末ごとに対応づいて定められ、
    前記ストリームデータは、前記識別子と関連付けられた前記移動体端末の位置情報を含む、ことを特徴する、計算機システム。
16. 請求項２記載の計算機システムであって、
    前記保持領域に含まれるデータは、前記外部デバイスにより受信したデータ及び前記クエリによる実行した結果であることを特徴とする計算機システム。
17. 第一の計算機であって、
    ネットワークに接続されるネットワークインターフェースと、
    前記ネットワークインターフェースに接続されるプロセッサと、
    前記プロセッサに接続されるメモリと、を備え、
    前記メモリは、前記クエリが格納され、
    前記ネットワークインターフェースは、前記ネットワークを介して外部デバイスからのデータを受信可能で、
    前記プロセッサは、
    前記外部デバイスからの受信タプルを前記ネットワークインターフェースを介して受信した場合は、前記メモリに前記クエリに対応するウインドウが構成されているか否かを判定し、
    前記ウインドウが構成されている場合、前記ウインドウに保持されているタプル及び受信したタプルを用いて前記クエリを実行し、
    前記プロセッサが実行するクエリに対応する保持領域を構成されていない場合、前記受信タプルに含まれる識別子を前記ネットワークインタフェースを介して前記第二の計算機へ送信し、
    前記第二の計算機から前記クエリを実行するために必要なウインドウデータを受信し、
    前記受信したウインドウデータ及び前記受信タプルにより前記クエリに対応する保持領域を前記メモリに構成し、
    前記クエリを実行する、
    ことを特徴とする第一の計算機。
18. 請求項１７記載の第一の計算機であって、
    前記第一の計算機が格納するクエリは、前記第二の計算機が保持するクエリとは、同じ演算処理を行うクエリであり、
    前記第二の計算機から、前記保持領域に保持されるデータの取得要求を受けた場合は、前記取得要求に対応するデータを前記第二の計算機に前記ネットワークインタフェースを介して送信し、前記保持領域の構成を前記メモリから削除する、ことを特徴とする第一の計算機。
19. 請求項１７記載の第一の計算機であって、
    前記第一の計算機が格納するクエリは、前記第二の計算機が保持するクエリとは、異なる演算処理を行うクエリで、
    前記プロセッサは、前記第二の計算機が保持するクエリと、前記第二の計算機が保持するクエリに対応するウインドウデータとを、前記ネットワークインターフェースを介して前記第二の計算機から取得することを特徴とする第一の計算機。
20. 第一のメモリを有しクエリを実行可能な第一の計算機と、第二のメモリを有し前記クエリを実行可能な第二の計算機とを、備える計算機システムにおけるクエリ分散処理方法であって、
    前記第一の計算機は、外部デバイスからネットワークを介して、ストリームデータを受信し、
    前記クエリを実行する場合、前記第一のメモリに当該データを保持する第一の保持領域が構成されているか否かを判定し、
    前記第一の保持領域が構成されていた場合、前記第一の保持領域にストリームデータを格納し、前記第一の保持領域に保持されているデータを用いて前記クエリを実行し、
    前記第一の保持領域が構成されていなかった場合、受信したストリームデータに含まれる識別子を前記第二の計算機に送信し、
    前記第二の計算機から前記第一の保持領域に保持すべきデータを受信し、
    前記第一のメモリに、前記受信した保持すべきデータと、前記ストリームデータとを保持する第一の保持領域を構成し、
    前記第一の保持領域に保持されるデータを用いて前記クエリを実行する、
    ことを特徴とするクエリ分散処理方法。

Images