JP5939583B2 - 抽出装置、データ処理システム、抽出方法および抽出プログラム - Google Patents

Description

本発明は、クエリーを実行し、ストリーム・データおよびデータベースに格納されているデータに対して処理を行うデータ処理システム、そのデータ処理システムに用いられる、クエリーからストリーム・データを処理するためのプログラムに変換する変換対象を抽出する抽出装置、その抽出方法およびその方法をコンピュータに実行させるための抽出プログラムに関する。

ＩＣタグ等のセンサ、ＩＣカード、オンライン・ショッピングやオンライン・ゲーム等のオンライン・サービス、ＧＰＳ(Global Positioning System)を搭載した携帯電話やスマートフォン、ネットワークに接続されたカーナビゲーション・システムの普及等に伴い、これらセンサ等により継続的に大量のデータが生成されている。これら大量のデータは、ストリーム・データと呼ばれ、ネットワーク上を流れ、分析等のためにデータベースへ格納される。

必要なデータは、データベースを管理するデータベース管理システム（ＤＢＭＳ）に対してクエリーを発行し、ＤＢＭＳでそのクエリーを実行することによりデータベースから取得される。なお、クエリーは、データの取得のほか、データの更新、追加、削除等の処理をＤＢＭＳに実行させることができる。

近年、地球温暖化等の影響により、風の風速や雨量が急激に変化し、避難に数分遅れただけで災害に遭ってしまうといったケースが出てきている。このような急激な変化を見極め、早急に避難することができるようにするために、リアルタイムに風量データや雨量データを取得することができる高速なクエリーが求められている。

データベースには、大量のデータが格納されており、必要なデータを検索し、取得するためには、時間がかかる。その時間は、データ数やマシンの処理能力にもよるが、数分から数時間かかる場合もある。これでは、リアルタイムにデータを取得することが要求される場合に対応することができない。

そこで、データベースに格納する前の、データベースに入力されるストリーム・データに対して処理を行う技術が提案されている（例えば、特許文献１〜４参照）。これらの技術では、ストリーム・データに対して検索等の処理を行うので、リアルタイムにデータを取得することができる。

特開２００６−３３８４３２号公報 特開２０１０−１０８０７３号公報 特開２０１０−２１７９６８号公報 特開２０１１−０５９９６７号公報

ストリーム・データに対して処理を行う場合、クエリーを登録しておき、継続的に入力されるストリーム・データに対して、そのクエリーを継続的に実行させなければならない。このため、クエリーは、ストリーム・データに対する命令を記述し、その記述に際して、ＳＰＬ(Stream Processing Language)等のストリーム・データ処理言語が利用される。このクエリーは、コンパイルにより、ストリーム・データ処理コードと呼ばれる、ストリーム・データを処理するためのプログラムに変換され、そのコードの実行により処理が実行される。

一方、データベースに格納されているデータに対して処理を行う場合、データベースが保持する複数のテーブルを検索する等の複数のクエリーを、上記と同じストリーム・データ処理言語により記述するのは容易ではないため、ＳＱＬ等のデータベース問い合わせ言語が利用される。

ストリーム・データとデータベースに格納されたデータとに対して処理を行うためには、異なる言語により記述したクエリーを使用する必要があった。このため、従来の技術では、ストリーム・データと、データベースに格納されたデータとに対して１つのクエリーを使用し、効率的に処理を行うことはできなかった。

ストリーム・データに対して処理を行う場合、そのストリーム・データをメモリに一度保存し、その保存したデータに対して行われる。このため、ストリーム・データをメモリに保存する必要がある。しかしながら、ストリーム・データが大量のデータである場合、その保存により、メモリ不足が生じ、システムが停止してしまう可能性がある。

また、ハード・リアルタイムを実現しようとすると、クライアント・コンピュータやエッジ・サーバ等のメモリ制約が厳しい機器で実行させる必要があるが、メモリ不足が生じやすくなり、システム停止も起こりやすくなる。

そこで、メモリ不足の発生を防止することができ、１つのクエリーでストリーム・データとデータベースに格納されたデータの両方に対して効率的に処理を実行することを可能にする装置や方法の提供が望まれていた。

本発明は、上記課題に鑑み、データベースを管理するデータベース管理システムに発行する１以上の命令をサブクエリーとして含むクエリーから、該データベースへ継続的に入力されるストリーム・データに対して処理を行うためのプログラムに変換するサブクエリーを変換対象として抽出する抽出装置であって、クエリーと、ストリーム・データの処理により使用量が増加するメモリの最大メモリ増加量と、データベース管理システムがクエリーを実行した場合と比較してプログラムによりストリーム・データを処理した場合に削減される単位メモリ増加量当たりの処理時間としての効率の下限値との入力を受け付ける入力部と、クエリーに含まれる各サブクエリーにつき、プログラムに変換してストリーム・データを処理した場合のメモリ増加量と、データベース管理システムが実行した場合と比較してストリーム・データを処理した場合に削減される処理時間とを計算し、計算した少なくとも１つのメモリ増加量と削減される処理時間とを用いて効率を算出する演算部と、算出された効率が下限値以上のサブクエリーを少なくとも１つ選択し、選択したサブクエリーにつき計算されたメモリ増加量を積算し、積算したメモリ増加量が最大メモリ増加量以下となることを条件として、選択したサブクエリーを変換対象として抽出する抽出部とを含む、抽出装置が提供される。

本発明によれば、メモリ不足の発生を防止でき、ストリーム・データとデータベースに格納されたデータに対して１つのクエリーを使用して処理を実行することが可能となる。

本実施形態のデータ処理システムの全体構成図。 図１に示すデータ処理システムが備えるクライアントおよびフロント・エンド・サーバのハードウェア構成を例示した図。 図１に示すデータ処理システムが行う処理を説明するための図。 ＳＱＬグラフを２つのノード群に分類しているところを示した図。 ＳＱＬグラフのパス毎に効率を計算しているところを示した図。 ＳＱＬグラフにおいて変換対象のノードを抽出しているところを示した図。 抽出装置として機能するクライアントの機能ブロック図。 ＳＰＬテンプレートを例示した図。 抽出装置が行う処理の流れを例示したフローチャート。 ＳＱＬで記述されたクエリーを例示した図。 ＳＱＬで記述されたクエリーに含まれるサブクエリーをノードで示した図。 パイプライン処理を行うサブクエリーの記述例と、非パイプライン処理を行うサブクエリーの記述例を示した図。 最終Ｉｎｎｅｒ ｊｏｉｎ部分を非パイプライン処理化した例を示した図。 パイプライン処理および非パイプライン処理により生成されたテーブルの例およびそのテーブルを参照するように変換されたＳＱＬの例を示した図。

以下、本発明を図面に示した具体的な実施の形態に沿って説明するが、本発明は、後述する実施の形態に限定されるものではない。図１は、本実施形態のデータ処理システムの全体構成図である。データ処理システムは、ＩＯＴ(Internet of Things)デバイス１０と、パケット通信網１１と、クライアント・コンピュータ（以下、クライアントと略す）１２と、フロント・エンド・サーバ１３と、バック・エンド・サーバ１４とを含んで構成されている。図１では、各機器は１つずつしか示されていないが、データ処理システムは、各機器を２以上含んで構成されていてもよい。

パケット通信網１１は、データを分割したパケットの送受信を行う通信網で、インターネット網を含む。ＩＯＴデバイス１０は、そのインターネット網に接続可能な、データを生成してインターネットへ送信するデバイスである。ＩＯＴデバイス１０としては、車両、ヘルスケアデバイス、工場や学校等に取り付けられた各種センサ等を挙げることができる。ＩＯＴデバイス１０とパケット通信網１１との間の通信は、図示しないアクセス・ポイントを介してＷｉ−Ｆｉ等の無線通信により行われる。

ヘルスケアデバイスとしては、例えば、体重計、体組成計、歩数計、活動量計、基礎体温計、血圧計等を挙げることができる。これらのデバイスは、計測するためのセンサ等を備えていて、計測データを生成し、それをインターネットへ送信する。

車両は、位置を計測するためのＧＰＳ、車速センサ、燃料圧等の各種圧力センサ、室温や外気温等の各種温度センサ等を備え、各センサが検出し、生成した計測データを送信する。ヘルスケアデバイスは、体重、歩数、体温、血圧等を計測し、生成した計測データを送信する。工場等に取り付けられた各種センサとしては、例えば、プラントや装置に取り付けられた温度計、流量計、圧力計、濃度計等に搭載されたそれらを計測するためのセンサを挙げることができる。

クライアント１２は、ユーザが使用するＰＣ等であり、第１処理装置として使用されるフロント・エンド・サーバ１３や、第２処理装置として使用されるバック・エンド・サーバ１４にて実行させるクエリーや各種パラメータの入力を受け付け、そのクエリーのコンパイル等を行う。クエリーやパラメータ、コンパイルの詳細については後述する。なお、クエリーは、バック・エンド・サーバ１４が備えるデータベースに対する問い合わせを、ＳＱＬ等のデータベース記述言語により記述したものである。

フロント・エンド・サーバ１３は、ＩＯＴデバイス１０がパケット通信網１１に送信した大量の計測データ等のストリーム・データの入力を受け付け、ストリーム・データ処理を行い、その結果を、バック・エンド・サーバ１４へ出力する。フロント・エンド・サーバ１３は、クライアント１２がクエリーをコンパイルし、このコンパイルにより生成されたストリーム・データ処理コードと呼ばれるプログラムを受け取り、このストリーム・データ処理コードを実行して、入力されるストリーム・データに対して所定の処理を行う。これにより、クエリーの一部または全部の処理を実行することができる。

バック・エンド・サーバ１４は、フロント・エンド・サーバ１３が処理した結果を受け取り、クエリーに、実行すべき残りの処理が存在する場合、その処理を実行し、その結果をデータベースに格納するとともに、クライアント１２にその結果を返す。また、バック・エンド・サーバ１４は、ストリーム・データをデータベースに格納する処理も行う。このため、バック・エンド・サーバ１４は、データベースを管理し、そのデータベースに対する処理を実行するためのデータベース管理システム（ＤＢＭＳ）を実装する。

データベースは、バック・エンド・サーバ１４内に構築され、バック・エンド・サーバ１４をデータベース・サーバとして用いることができる。しかしながら、これに限られるものではなく、データベースは、バック・エンド・サーバ１４からアクセス可能な外部に設置されていてもよい。また、データベースは、データをツリー構造で表した階層型データモデルを採用したデータベースや、問い合わせを論理演算により行う関係データベース等を用いることができる。なお、関係データベースを用いる場合、そのデータを管理するＤＢＭＳには、関係データベース管理システム（ＲＤＢＭＳ）が用いられる。関係データベースやＲＤＢＭＳについては良く知られたものであるので、ここでは詳述しない。以下、ＲＤＢＭＳを用いるものとして説明する。

ここで簡単に、図２を参照して、各機器のハードウェア構成について説明する。ＩＯＴデバイス１０は、図示しないが、温度データを出力する場合はサーミスタ等を備える温度計、速度データを出力する場合は速度計、圧力データを出力する場合は圧力計をそれぞれ備えている。なお、速度計や圧力計には、速度センサや圧力センサが用いられている。また、ＩＯＴデバイス１０は、計測データをインターネットへ送信するための送信機といった通信手段も備えている。

クライアント１２は、ホスト・コントローラ２０により相互に接続されるＣＰＵ２１と、ＲＡＭ２２と、グラフィック・コントローラ２３と、表示装置２４と、入出力コントローラ２５によりホスト・コントローラ２０に接続される通信インタフェース２６と、ハードディスク・ドライブ（ＨＤＤ）２７、ＣＤ／ＤＶＤドライブ２８とを備えている。また、クライアント１２は、入出力コントローラ２５に接続されるＲＯＭ２９と、入出力チップ３０を備えるレガシー入出力装置とを備えている。

ホスト・コントローラ２０は、ＲＡＭ２２と、高い転送レートでＲＡＭ２２をアクセスするＣＰＵ２１やグラフィック・コントローラ２３とを接続する。ＣＰＵ２１は、ＲＯＭ２９あるいはＨＤＤ２７に格納されたブート・プログラム、ＯＳ、抽出プログラム等を実行する。ＣＰＵ２１は、並列処理が可能なマルチプロセッサとすることができる。

グラフィック・コントローラ２３は、ＣＰＵ２１がＲＡＭ２２内に設けたフレーム・バッファ上に生成する画像データを取得し、表示装置２４上に表示させる。グラフィック・コントローラ２３は、内部にこのフレーム・バッファを備えることもできる。

入出力コントローラ２５は、ホスト・コントローラ２０と、比較的高速な入出力装置である通信インタフェース２６、ＨＤＤ２７、ＣＤ／ＤＶＤドライブ２８を接続する。通信インタフェース２６は、ネットワークを介して他の装置と通信する。ＨＤＤ２７は、ＯＳや抽出プログラム、アプリケーション・プログラム、各種データ等を格納する。ＣＤ／ＤＶＤドライブ２８は、ＣＤ−ＲＯＭやＤＶＤに抽出プログラムや各種データ等が記録されている場合、それらを読み取り、ＲＡＭ２２を介して入出力チップ３０に提供する。

入出力コントローラ２５は、ＲＯＭ２９と、入出力チップ３０等の比較的低速な入出力装置とが接続される。ＲＯＭ２９は、ＨＤＤ２７からＯＳをロードして起動するためのブート・プログラムや、コンピュータや機器の初期設定情報等を記録したファームウェア等を格納する。入出力チップ３０は、パラレルポート、シリアルポート、キーボードポート、マウスポート等を介して各部の入出力装置を接続する。

フロント・エンド・サーバ１３およびバック・エンド・サーバ１４は、同じハードウェア構成とし、いずれもブレード・サーバを用いることができる。このため、フロント・エンド・サーバ１３についてのみ説明する。フロント・エンド・サーバ１３は、ＣＰＵ３１、メモリ３２、ＨＤＤ３３、通信インタフェース３４を備える１以上のサーバ・ブレード３５と、１以上のサーバ・ブレード３５を収納する筐体とを含んで構成される。筐体には、各サーバ・ブレード３５の動作を監視し、異常を検知した場合に他のサーバ・ブレードに切り替える管理モジュール、各サーバ・ブレード３５が通信に必要とするＬＡＮアダプタ等を割り当てるＩ／Ｏモジュール、電源モジュール等の各種のモジュール３６と、サーバ・ブレード３５と各種のモジュール３６とを相互接続するためのコネクタを備えるバック・プレーン３７とが設けられる。

フロント・エンド・サーバ１３は、追加のサーバ・ブレードを、バック・プレーン３７が備えるコネクタに接続することで、サーバの台数を増やし、処理能力を向上させることができる。バック・エンド・サーバ１４を、データベース・サーバとして用いる場合、バック・エンド・サーバ１４の各サーバ・ブレードが備えるＨＤＤを、データベースに使用することができる。なお、フロント・エンド・サーバ１３およびバック・エンド・サーバ１４は、ブレード・サーバに限定されるものではなく、その他のラック・マウント型のサーバや、タワー型のサーバ等を用いてもよい。

図３を参照して、データ処理システムが行う処理について詳細に説明する。図示しないＩＯＴデバイスからストリーム・データが継続的に送信され、クライアント１２がユーザの入力により、入力ＳＱＬ４０と示されたクエリーと、それに対応するユーザ定義入力パラメータ４１とを受け付ける。ここでは、４つの入力ＳＱＬ４０が入力され、それに対応する４つのユーザ定義入力パラメータ４１が入力されている。

入力ＳＱＬ４０は、ＳＱＬにより記述された１以上の命令をサブクエリーとして含む。サブクエリーは、データに対する処理もしくは操作（オペレーション）を記述しており、そのオペレーションとしては、例えば、ストリーム・データとして、各装置に取り付けられた温度データが入力されている場合に、温度が３００℃以上を示す装置のみを抽出するという操作を挙げることができる。このとき、その温度は、１時間の平均温度が３００℃以上の温度とされていてもよい。これは一例であるので、サブクエリーの操作はこれに限定されるものではない。

ユーザ定義入力パラメータ４１としては、例えば、以下の３つのパラメータを設定することができる。１つ目のパラメータは、データ保存時間範囲と呼ばれるパラメータで、ストリーム・データをメモリ上に保存するデータの時間範囲を指定するものである。ストリーム・データは、パケットとして継続的に入力されるため、処理を行うためには、時間範囲またはパケット数で区切って処理を行う必要がある。ここでは、そのパラメータとして、時間範囲を入力している。

時間範囲は、例えば、１分や１０分という時間を指定することができる。時間範囲として１０分を指定した場合、ストリーム・データが入力され、１０分間分保存したところで、その１０分間分のデータに対して処理が行われる。指定する時間が長くなると、一度にメモリに保存するデータ量が増加するので、適切な時間が指定される。なお、このパラメータに代えて、上記のパケット数を指定するパラメータを入力することが可能である。

２つ目のパラメータは、最大メモリ増加量と呼ばれるパラメータである。処理を行う際、メモリにデータを一度保存し、その保存したデータに対して処理を行うことになるが、そのデータの保存により増加するメモリ増加量の最大値（上限値）を指定するものである。

３つ目のパラメータは、効率の下限値と呼ばれるパラメータである。入力ＳＱＬ４０は、１以上のサブクエリーを含んで構成されている。このデータ処理システムでは、クライアント１２が入力ＳＱＬ４０をコンパイルし、その入力ＳＱＬ４０に含まれる１以上のサブクエリーから、ストリーム・データに対して処理を行うためのサブクエリーを抽出し、抽出したサブクエリーのみを変換してストリーム・データ処理コードを生成する。

この抽出の際、どのサブクエリーを抽出するかを決定するため、いずれのサブクエリーも変換せず、入力ＳＱＬ４０をＲＤＢＭＳで実行した場合の処理時間と、各サブクエリーにつき、ストリーム・データ処理コードを生成して処理を行った場合の処理時間とを計算し、それらを比較して、削減される処理時間を算出する。ストリーム・データ処理コードにより処理を行う場合、メモリにデータを保存し、その保存したデータに対して処理を行うため、そのメモリの使用量が増加する。このため、その保存によりメモリが増加した量、すなわちメモリ増加量も算出する。削減される処理時間をそのメモリ増加量で除して、メモリの単位増加量当たりに削減される処理時間を算出し、これを上記の効率とする。したがって、この効率は、ストリーム・データ処理を行うことにより、どれだけ処理時間が削減され、どれだけ効率的に処理が行われるかを示す指標となるものである。３つ目のパラメータは、このように算出した効率の下限値を指定するものである。

図３中、コンパイルを行うコンパイラ４２では、入力ＳＱＬ４０を構文解析し、各サブクエリーを各ノードとするツリー構造で表されるグラフを生成する。このツリー構造は、ストリーム・データが入力される側を根ノードとし、末端のノードを葉ノードとしている。根ノードは、それに繋がる親ノードが存在せず、葉ノードは、それに繋がる子ノードが存在しないノードである。コンパイラ４２は、構文解析した結果に基づき、各ノードがパイプライン処理可能であるか否かを判断し、可能であるノードをパイプライン処理ノード（Ｐノード）とし、不可であるノードを非パイプライン処理ノード（ＮＰノード）とする。

Ｐノードは、データを処理するための条件が固定されていて、入力されたデータを直ちに処理し、その処理結果を後続の子ノードへ出力することが可能なノードである。Ｐノードは、例えば、ストリーム・データにおいて流れてくるパケット毎に処理を行うことができるため、メモリ増加量が少なく、処理時間の削減効果も大きいという特徴を有している。

ＮＰノードは、平均、合計、最大値を計算する等の集約演算を含み、一定の時間範囲のデータをメモリに保存する必要があるノードである。このため、メモリ増加量が大きく、処理時間の削減効果はないが、オン・メモリで実施することができることから、入力ＳＱＬ４０をＲＤＢＭＳで実行する場合に比較して、処理時間を削減することができる。オン・メモリとは、プログラムを実行する際、利用するデータをすべてメモリに書き出し、データベースから読み出さないようにする技術である。

入力ＳＱＬ４０をツリー構造で表した例を、図４に示す。各ノード中、「Ｐ」はＰノードを表し、「ＮＰ」はＮＰノードを表す。その左下に記載された「ｍ１」〜「ｍ１７」はそのノードを、パイプライン処理または非パイプライン処理というストリーム・データ処理した場合のメモリ増加量で、その右隣の「ｅ１」〜「ｅ１７」はそのノードをストリーム・データ処理した場合に、入力ＳＱＬ４０をＲＤＢＭＳで実行する場合と比較して削減される処理時間を示す。なお、入力ＳＱＬ４０をＲＤＢＭＳで実行する場合の処理時間は、実際に行った場合の処理時間ではなく、想定される処理時間であり、計算により算出される処理時間である。

ストリーム・データＡは、根ノード５０、５１に入力され、ストリーム・データＢは、根ノード５２、５３に入力され、ストリーム・データＣは、根ノード５４に入力され、処理が実行される。例えば、根ノード５０で処理された結果と、根ノード５１で処理された結果は、その子ノードであるノード５５へ出力され、ノード５５により処理される。そして、ノード５５で処理された結果は、次のノード５６へと順に出力され、最後に末端の葉ノード５７へと出力され、その葉ノード５７で最後の処理が実行される。葉ノード５７で処理された結果がこの入力ＳＱＬ４０の処理結果となり、バック・エンド・サーバ１４に格納されるとともに、クライアント１２へ送られ、表示等される。

この処理を高速に行うために、Ｐノードである根ノードを検出し、検出した各根ノードをそれぞれ順に辿り、その辿った経路（パス）においてＮＰノードに到達するまでのＰノードのみから構成される１以上のＰノード群と、それ以外のノードからなる１以上のＮＰノード群とに分類する。図４では、色の薄い領域内にあるＰノードのみから構成されるノード群がＰノード群で、色の濃い領域内にあるＮＰノードを含むそれ以外のノードからなるノード群がＮＰノード群である。図４には、２つのＰノード群と、１つのＮＰノード群とが示されている。この分類後、メモリ増加量および削減される処理時間が計算される。

メモリ増加量Ｍは、ストリーム・データに対してそのノードが処理を行うために必要とされるデータの保存に要するメモリ量である。削減される処理時間ｔ_ｒｅｄは、ＲＤＢＭＳで処理を行ったときの処理時間ｔ_{ＲＤＢＭＳ}と、ストリーム・データ処理、すなわちパイプライン処理または非パイプライン処理を行ったときの処理時間ｔ_{ｓｔｒｅａｍ}とを計算し、その差により算出することができる。具体的には、下記式（１）により算出することができる。

メモリ増加量Ｍおよび削減される処理時間ｔ_ｒｅｄは、ストリーム・データのデータ・レート、ストリーム・データに対して処理を行う時間範囲（ＷＩＮＤＯＷ）、過去にクエリーを実行した結果から得られる統計情報、クエリーの操作に関する情報に基づき算出することができる。その具体的な算出方法については後述する。このようにして算出されたメモリ増加量Ｍと削減される処理時間ｔ_ｒｅｄを用いて、単位メモリ増加量当たりに削減される処理時間、すなわち効率Ｅ_ｍ（秒／ｂｙｔｅ）を、次の式（２）により算出する。

この効率Ｅ_ｍは、Ｐノードを含む場合の方が、メモリ増加量が小さいため、大きな値となる傾向がある。すなわち、効率良く処理を行うことができる。メモリ増加量Ｍと効率Ｅ_ｍは、ユーザが入力したパラメータの最大メモリ増加量Ｍ_ｍａｘと効率の下限値Ｅ_ｍｉｎと比較される。メモリ増加量Ｍを加算していき、その積算値Ｍ_ｃｏｍが、最大メモリ増加量Ｍ_ｍａｘに達するまで、パイプライン処理または非パイプライン処理するストリーム・データ処理コードへの変換対象として追加していく。このとき同時に、効率Ｅ_ｍが、下限値Ｅ_ｍｉｎ以下でないことも確認される。

効率Ｅ_ｍが下限値Ｅ_ｍｉｎ以下となる場合、削減される処理時間ｔ_ｒｅｄが短い割に、メモリ増加量が大きく、パイプライン処理や非パイプライン処理を行ってもあまり効率が良くならないことを意味する。このため、下限値Ｅ_ｍｉｎ以下となる場合には、変換対象として追加しない。変換対象として抽出されなかったノードについては、パイプライン処理や非パイプライン処理を行わず、ＲＤＢＭＳにて処理を実行する。

変換対象として追加するかどうかの評価は、ノードを順に選択して行うことができる。その選択方法の一例として、Ｐノード群の幅優先順にノードを選択することができる。ここで、幅優先とは、根ノードから始め、同じ階層にあるノードを優先して選択する方法である。最初に、Ｐノード群の１つの根ノードを選択する。どの位置にある根ノードを最初に選択するかは、予め設定により決定しておくことができる。その根ノードの変換対象の評価をし、順次同じ階層の隣接する根ノードの評価を行う。同じ階層のノードがなくなったら、１つ下の階層の子ノードを辿る。下の階層のノードにおいて、親ノードがＲＤＢＭＳでの処理となっていた場合は、そのノードもＲＤＢＭＳでの処理とする。Ｐノード群の全てのノードの評価が終了したら、別のＰノード群につき、同様の評価を行う。

別のＰノード群がないか、全てのＰノード群につき評価が終了した場合、ＮＰノード群について、Ｐノード群と同様に評価を行い、変換対象を抽出する。なお、根ノードがＲＤＢＭＳにて処理を実行すると決定された場合は、同じパスにある全てのノードについて評価は行わず、それらのノードについては、ＲＤＢＭＳにて処理を実行すると決定する。変換対象として追加されたノードについてのメモリ増加量Ｍは、随時、メモリ増加量の積算値Ｍ_ｃｏｍに加算される。

図５を参照して詳細に説明すると、まず、色が薄い領域にあるＰノード群の１つを選択する。ここでは、ノード５０、５１、５２、５５、５６から構成されるＰノード群が選択される。このＰノード群は、ノード５０からノード５５へのパス、ノード５１からノード５５へのパス、ノード５２からノード５６へのパスの３つのパスを有する。

まず、ノード５０が選択され、効率Ｅ_ｍが、上記式（２）により、ｅ１／ｍ１と算出される。このｅ１／ｍ１が下限値Ｅ_ｍｉｎと比較され、下限値Ｅ_ｍｉｎ以上で、かつこれまでのメモリ増加量の積算値Ｍ_ｃｏｍにｍ１を加算して得られた新たな積算値が、最大メモリ増加量Ｍ_ｍａｘ以下である場合、ノード５０を変換対象として追加する。次にノード５１、ノード５２を同様に評価する。ノード５５の親ノードであるノード５０、ノード５１が変換対象となった場合、ノード５０からノード５５へのパスの効率（ｅ１＋ｅ５）／（ｍ１＋ｍ５）、ノード５１からノード５５へのパスの効率（ｅ２＋ｅ５）／（ｍ２＋ｍ５）を算出し、大きい方を効率Ｅ_ｍとし、同様に評価を行い、条件を満たす場合、ノード５５を変換対象として追加する。このように、複数のパスをもつノードについては、計算した効率Ｅ_ｍが最も大きい値を用いて評価を行う。

ノード５５には、Ｐノードである子ノードが存在しないため、隣接する根ノードであるノード５２について同様の評価を行う。このようにして、ノード５６、別のＰノード群にあるノード５４についても同様の評価を行う。

ここでは、Ｐノード群についてのみ説明したが、色が濃い領域にあるＮＰノード群も同様に評価を行うことができる。なお、この場合も、根ノードがＲＤＢＭＳにて処理を実行すると判断された場合は、同じパスにある全てのノードについて評価を行わず、その全てのノードは、ＲＤＢＭＳにて処理を実行する。

このようにして評価を行い、図５に示した全てのＰノード群の全てのノードと、ＮＰノード群の一部のノードが変換対象と決定された場合においても、メモリ増加量の積算値Ｍ_ｃｏｍが、最大メモリ増加量Ｍ_ｍａｘに達していない場合がある。高速に処理するためには、出来るだけ多くのノードを変換し、パイプライン処理や非パイプライン処理を行うことが望ましい。このため、根ノード側からだけではなく、その逆の葉ノード側からも、上記と同様にして、Ｐノードを評価し、変換対象に追加するか否かの判定を行う。

図６は、根ノード側からＰノードを評価し、変換対象に追加した後、最大メモリ増加量Ｍ_ｍａｘに達していないため、葉ノード側からＰノードを評価しているところを示した図である。２つのＰノード群におけるＰノードはすべて変換対象として追加され、ＮＰノード群における一部のノード（色の薄いノード）も変換対象として追加されている。上記の評価では、葉ノード５７は、この葉ノード５７へと繋がる上位ノードが、いずれもＲＤＢＭＳで処理を行うと決定されたことから、評価を行わず、ＲＤＢＭＳで処理を行うと決定されている。

葉ノード５７は、Ｐノードであり、メモリ増加量の積算値Ｍ_ｃｏｍも最大メモリ増加量Ｍ_ｍａｘに達していないため、この葉ノード側からも同様の評価を行っていく。図６では、葉ノード５７につき計算されたメモリ増加量を加算しても、その積算値Ｍ_ｃｏｍが最大メモリ増加量Ｍ_ｍａｘにはまだ達していないので、変換対象に追加され、その上位のＮＰノード（色の濃いノード）については、Ｅｍが下限値Ｅ_ｍｉｎ以下であるため、これらのノードについては変換対象に追加しないことが決定されている。なお、そのＮＰノードに挟まれたＰノードは、根ノード側でも、葉ノード側でも、それに繋がる上位ノードであるＮＰノードがＲＤＢＭＳで処理を実行すると決定されるので、評価は行わず、それらと同じＲＤＢＭＳで処理を実行すると決定される。

このように、葉ノード側からも評価を行い、変換対象に追加できるノードを追加することで、ＲＤＢＭＳにおける処理結果に対する処理を、メモリ上で行うことができる。ＲＤＢＭＳにて行う処理を中央にまとめ、出来るだけ少なくすることで、全体的な処理の高速化を図ることができる。

再び図３を参照すると、変換対象に追加されたノードは、コンパイラ４２により変換され、ストリーム・データ処理コードと呼ばれるパイプライン処理を実行するためのプログラム（パイプライン処理プログラム）および非パイプライン処理を実行するためのプログラム（非パイプライン処理プログラム）４３が生成される。継続的に入力されるストリーム・データは、ＥＴＬ処理プログラム４４により、フィルタリング等の基本的な前処理がなされ、パイプライン処理プログラムおよび非パイプライン処理プログラム４３等で利用しやすい形式に変換する処理が行われる。また、ＥＴＬ処理プログラム４４は、全ストリーム・データを第２のデータベース４６に格納する処理を行う。

パイプライン処理プログラムおよび非パイプライン処理プログラム４３は、図４〜図６で示したＰノード群の、例えばノード５０、ノード５５の順に処理を実行するように配置され、その処理結果を第１のデータベース４５に定期的な書き込みまたは残余ＳＱＬ４７の実行トリガーによる書き込みにより格納する。

入力ＳＱＬ４０は、一部のサブクエリーがストリーム・データ処理コードに変換されるため、そのサブクエリーが除かれ、ＲＤＢＭＳで実行する残りのサブクエリー、すなわち残余ＳＱＬ４７が生成される。この残余ＳＱＬ４７は、ＲＤＢＭＳにて実行され、パイプライン処理プログラムおよび非パイプライン処理プログラム４３を開始させるトリガーを発生させ、第１のデータベース４５に書き込みが終了した旨の通知を受け付ける。これに伴い、この残余ＳＱＬ４７は、第１のデータベース４５からパイプライン処理プログラムおよび非パイプライン処理プログラム４３による処理結果と、第２のデータベース４６に格納されたデータとを取得し、クエリー処理を実行する。残余ＳＱＬ４７による処理結果は、ユーザに提示されたり、外部アプリケーションにより利用される。

このことから、クライアント１２は、変換対象を抽出するための抽出装置や、パイプライン処理プログラムおよび非パイプライン処理プログラム４３に変換する変換装置として機能する。この機能は、ＨＤＤ２７に格納された抽出プログラムや変換プログラムをＣＰＵ２１により実行することにより実現することができる。ここでは、これらの装置が１つの機器であるクライアント１２に実装されているが、別個の機器として構成することも可能である。

クライアント１２は、図７に示すように、その機能部として、１以上のサブクエリーを含む入力ＳＱＬ４０と、ストリーム・データ処理によりその使用量が増加するメモリの最大メモリ増加量Ｍ_ｍａｘと、効率の下限値Ｅ_ｍｉｎとの入力を受け付ける入力部６０を備える。また、クライアント１２は、各サブクエリーにつき、ストリーム・データ処理した場合のメモリ増加量と、ストリーム・データ処理したときにＲＤＢＭＳで処理を行う場合に比較して削減される処理時間とを計算し、計算した少なくとも１つのメモリ増加量と削減される処理時間とから、効率を算出する演算部６１を備える。

クライアント１２は、演算部６１により算出された効率が、入力部６０が受け付けた効率の下限値Ｅ_ｍｉｎ以上となるサブクエリーを少なくとも１つ選択し、既に抽出したサブクエリーがある場合には、その全てのサブクエリーにつき計算され積算されたメモリ増加量に、その選択したサブクエリーにつき計算されたメモリ増加量を加算し、加算した後のメモリ増加量を、ない場合には、その計算されたメモリ増加量を、最大メモリ増加量Ｍ_ｍａｘ以下となることを条件として、その選択したサブクエリーを変換対象として抽出する抽出部６２をさらに備える。

クライアント１２は、上記の入力部６０と、演算部６１と、抽出部６２とを少なくとも備え、それに加えて、入力ＳＱＬ４０を構文解析し、各サブクエリーを各ノードとし、ノード間の依存関係を示すツリー構造で表されるＳＱＬグラフを生成するグラフ生成部６３をさらに備えることができる。また、クライアント１２は、その構文解析の結果に基づき、各ノードにつき、入力されたデータを処理し、処理結果を出力するパイプライン処理が可能なＰノードか否かを決定し、上記のグラフを参照し、根ノードから階層的に繋がるノードがＰノードのみからなる１以上のＰノード群と、残りのノードからなる１以上のＮＰノード群とに分類する分類部６４を備えることができる。

抽出部６２は、サブクエリーを選択する際、設定により、効率が大きい順に選択することができる。効率が大きいサブクエリーから順に選択することで、より効率的に処理を行うことができるからである。抽出部６２は、分類部６４の分類結果に基づき、Ｐノード群に分類されたノードを優先し、効率が下限値以上であるノードのうち効率が大きい順に選択し、変換対象を抽出することができる。

メモリ増加量の積算値Ｍ_ｃｏｍが、最大メモリ増加量Ｍ_ｍａｘに達していない場合、分類部６４が、葉ノード側から階層的に繋がるノードがＰノードのみからなる１以上のＰノード群と、残りのノードからなるＮＰノード群にさらに分類する。抽出部６２は、そのＰノード群に分類されたノードにつき、上記と同様の評価を行う。すなわち、効率Ｅ_ｍが下限値Ｅ_ｍｉｎ以上となるノードを選択し、それにつき計算されたメモリ増加量を加算して最大メモリ増加量Ｍ_ｍａｘに達したかどうかを判断し、達していなければ、変換対象に追加する。

このように、変換対象を抽出することで、その後に、変換装置にてパイプライン処理プログラムや非パイプライン処理プログラムに変換し、また、入力ＳＱＬから変換対象部分を除いた残余ＳＱＬを生成し、それらを第１処理装置としてのフロント・エンド・サーバ１３および第２処理装置としてのバック・エンド・サーバ１４へ送り、ストリーム・データとデータベースに格納されたデータに対して１つのクエリーを使用して処理を実行することが可能となる。また、変換対象を抽出し、その変換を制限することで、パイプライン処理や非パイプライン処理により増加するメモリによるメモリ不足が発生するのを防止することも可能となる。

なお、変換対象は、ＳＱＬの節（テンプレートが用意できる節）を予め決定しておき、その予め決定されたＳＱＬの節を探し出すことにより抽出することができる。変換対象以外が入力された場合は、警告表示し、ＤＢアクセスのままにしておくか、エラー表示することができる。このＳＱＬの節としては、データの照会を行うｓｅｌｅｃｔ節、ｗｈｅｒｅ節、ｇｒｏｕｐ ｂｙ節、ｏｒｄｅｒ ｂｙ節、ｈａｖｉｎｇ節を挙げることができる。また、ストリーム・データ処理コードの生成は、ＳＱＬの節に対応するテンプレートを用いて行うことができる。図８に、そのテンプレートの例として「select A1,agg(A2) as agg_A2 from B where C group by D1,D2 having E」というＳＱＬに対するＳＰＬのテンプレートを示す。

このクライアント１２が行う処理について、図９に示すフローチャートを参照して簡単に説明する。ステップ９００からこの処理を開始し、ステップ９１０では、入力部６０が、ユーザから入力ＳＱＬおよびユーザ定義入力パラメータの入力を受け付ける。これらは、グラフ生成部６３に送られ、ステップ９２０で、グラフ生成部６３が、入力ＳＱＬを構文解析し、図４に示すような、サブクエリー間の依存関係を示すツリー構造で表されるＳＱＬグラフを生成する。

ステップ９３０では、分類部６４が、グラフ生成部６３から構文解析により得られた各サブクエリーの処理タイプを取得し、その処理タイプから、各サブクエリーがＰノードであるか、ＮＰノードであるかを決定し、１以上のＰノード群と１以上のＮＰノード群とに分類する。分類部６４は、この分類結果を抽出部６２へ渡す。

ステップ９４０では、演算部６１が、各サブクエリーにつき、メモリ増加量と、ストリーム・データ処理したときにＲＤＢＭＳで処理を行う場合に比較して削減される処理時間とを計算する。そして、演算部６１は、計算したメモリ増加量と、削減される処理時間とから、効率を算出する。演算部６１によるこの処理は、分類部６４による分類の前に実行されてもよいし、その分類と並行して実行してもよい。

ステップ９５０では、抽出部６２が、演算部６１により算出されたメモリ増加量Ｍおよび効率Ｅ_ｍと、分類部６４の分類結果およびグラフとを受け取り、根ノード側から、その効率Ｅ_ｍが下限値Ｅ_ｍｉｎ以上となるサブクエリーを少なくとも１つ選択する。抽出部６２は、既に抽出したサブクエリーがある場合には、その全てのサブクエリーにつき計算され積算されたメモリ増加量に、その選択したサブクエリーにつき計算されたメモリ増加量Ｍを加算する。そして、抽出部６２は、加算した後のメモリ増加量の積算値Ｍ_ｃｏｍが最大メモリ増加量Ｍ_ｍａｘ以下となる場合に、その選択したサブクエリーを変換対象として抽出する。

ステップ９６０では、メモリ増加量の積算値Ｍ_ｃｏｍが最大メモリ増加量Ｍ_ｍａｘに達していないかどうかを判断する。例えば、最大メモリ増加量Ｍ_ｍａｘに達するまでの残量が一定量以下である場合は、達したと判断し、一定量を超える場合は、達していないと判断することもできる。達したと判断した場合は、ステップ９８０へ進み、この処理を終了する。

これに対し、達していないと判断した場合は、ステップ９７０へ進み、抽出部６２が、葉ノードの側から、効率Ｅ_ｍが下限値Ｅ_ｍｉｎ以上となるサブクエリーを少なくとも１つ選択する。そして、抽出部６２は、上記のメモリ増加量の積算値Ｍ_ｃｏｍに、その選択したサブクエリーにつき計算されたメモリ増加量を加算し、最大メモリ増加量Ｍ_ｍａｘ以下となる場合に、その選択したサブクエリーを変換対象として抽出する。葉ノード側からの評価も終了したところで、ステップ９８０へ進み、この処理を終了する。

ここから、具体的な例を用いて、分類方法、メモリ増加量や削減される処理時間の計算方法、抽出した後に生成されるパイプライン処理プログラムや残余ＳＱＬ等について詳細に説明する。図１０は、入力ＳＱＬ４０の一例を示した図である。このＳＱＬは、リアルタイムのクーポン発行処理を実行させるためのクエリーである。

長期間運転で休息をとっておらず、渋滞に巻き込まれていて、コンビニエンス・ストアを頻繁に訪れるドライバーに、コンビニエンス・ストアのクーポンを発行することを考える。入力ＳＱＬ４０は、該当する車両を抽出するためのクエリーである。入力ＳＱＬ４０中、car_all_tableは、車両が送信するストリーム・データである。このストリーム・データは、各車両が１００ｍ／秒ごとに送信するデータで、車両を識別するための車両ＩＤ、車両の現在の位置を識別するための位置ＩＤ、車両のエンジンを制御するエンジン制御ユニット（ＥＣＵ）から出力される各種ＥＣＵデータ等が含まれる。各種ＥＣＵデータとしては、１分間の平均速度やエンジンの稼働時間等を挙げることができる。

conv_fav_car_tableは、過去の行動履歴として、データベースに蓄積されたストリーム・データから、コンビニエンス・ストアに頻繁に訪れる車両の車両情報を取得したリストである。SLOW_LONG_OP_CARSは、低速走行で、エンジン稼働時間が長い車両の車両ＩＤリストである。稼働時間が長いかどうかは、任意の閾値を超えたかどうかにより判断することができる。CONV_STORE_FAV_CARは、頻繁にコンビニエンス・ストアを訪れる車両の車両ＩＤリストである。

この入力ＳＱＬ４０を構文解析すると、ストリーム・データであるcar_all_tableが入力され、その中から低速走行で、エンジン稼働時間が長い車両の車両ＩＤリストを抽出する処理を行うSLOW_LONG_OP_CARSが１つのノード７０として得られる。また、蓄積されたストリーム・データであるconv_fav_car_tableが入力され、頻繁にコンビニエンス・ストアを訪れる車両の車両ＩＤリストを抽出する処理を行うCONV_STORE_FAV_CARがもう１つのノード７１として得られる。さらに、これらの車両ＩＤリストを結合するノード７２も得られる。このようにして、図１１（ａ）に示すような、ツリー構造をもつＳＱＬグラフを生成することができる。

パイプライン処理か、非パイプライン処理かは、図１２（ａ）に示すように、ｗｈｅｒｅ節における条件が一定であり、ストリーム・データが入力されたときに処理を行い、直ちに後続のノードへ送出可能であるノードかどうかにより判断する。図１２（ａ）に示す例では、速度（speed）が５ｋｍ／ｈ以下の車両の車両ＩＤ（car_id）を取得し、それを直ちにリストにして送出するので、パイプライン処理である。ここで、ｗｈｅｒｅ節は、データを選択等する際の条件を指定するコマンドである。

図１２（ｂ）に示す例では、集約演算であるＡＶＧ（平均）を含み、平均を計算するには一定の時間範囲のデータを保存する必要があるので、直ちに後続のノードへ送出できない。このため、この処理は、非パイプライン処理である。例えば、ｗｈｅｒｅ節中に、ＡＶＧ等の特定の文字を検出したかどうかにより、いずれかを判断することができる。

再び図１１を参照すると、SLOW_LONG_OP_CARSはパイプライン処理として決定され、変換対象として抽出され、conv_fav_car_tableはパイプライン処理として決定されるが、効率が小さいので、変換対象として抽出されないものとする。ノード７０は、図１１（ｂ）に示すように、変換対象として抽出され、パイプライン処理プログラム７３へ変換される。パイプライン処理プログラム７３では、その実行により、該当する車両ＩＤを取得し、それをリストにしてテーブルを生成する。入力ＳＱＬ４０は、パイプライン処理プログラム７３により実行される処理を除いたＳＱＬに書き換えられる。書き換えられたＳＱＬは、パイプライン処理プログラム７３により処理された結果を参照する残余ＳＱＬ７４が生成される。

図１１に示した例では、ノード７２において２つのテーブルが、例えば車両ＩＤに基づき結合され、結合して得られたテーブルを送出するように構成されているが、この結合処理を非パイプライン処理とし、非パイプライン処理プログラムにより行うようにすれば、ＲＤＢＭＳで実行すべき処理が少なくなり、より高速化を図ることができる。そこで、図１３に示すように構成することができる。図１３は、上記のノード７２における結合処理を表す最終ｉｎｎｅｒ ｊｏｉｎ部分を、非パイプライン処理に置き換えた残余ＳＱＬを示している。なお、Ｉｎｎｅｒ ｊｏｉｎは、２つのテーブルにある共通するレコードを１つにまとめ、それら２つのテーブルを結合する操作である。

パイプライン処理プログラムや非パイプライン処理プログラムにより処理を実行すると、該当する車両ＩＤを取得し、取得した車両ＩＤをリストしたテーブルを生成する。図１４（ａ）は、このようにして生成されたテーブルを例示した図である。このテーブルでは、１分間の平均速度が５ｋｍ／ｈで、かつ１２０分以上の長時間運転の車両ＩＤがＷＩＮＤＯＷ時間分含まれている。ＷＩＮＤＯＷは、入力された時間範囲である。

図１４（ｂ）は、図９に示した入力ＳＱＬの例と同じものである。この入力ＳＱＬは、パイプライン処理プログラム等により、図１４（ａ）に示すようなテーブルが生成されると、その生成されたテーブルを参照するように、図１４（ｃ）に示すような残余ＳＱＬへ変換される。具体的には、図１４（ｂ）のオン・メモリで車両ＩＤを抽出する処理から、テーブル（SLOW_LONG_OP_CARS）から車両ＩＤを抽出する処理を行うように、その部分の記述が書き換えられる。

メモリ増加量、削減される処理時間の計算方法について詳細に説明する。メモリ増加量は、サブクエリーをノードとし、そのノードの処理を行うために保持しなければならないデータ量である。Ｐノードについては、入力されたストリーム・データをバッファリングする時間分のデータ量とされる。なお、バッファリングすることで、同時に複数のパケットを処理することができる。ＮＰノードについては、入力されたストリーム・データのＷＩＮＤＯＷ時間分のデータ量とされる。２つのテーブルを結合（join）する処理については、それぞれから入力されたデータを直積したデータ量とされる。

削減される処理時間は、上記式（１）により算出される。式（１）中、入力ＳＱＬをＲＤＢＭＳで処理を行ったときの処理時間ｔ_{ＲＤＢＭＳ}は、次の式（３）により算出することができる。式（３）中、ｔ_ｓｃａｎは、データを検索するデータ・スキャン時間であり、ｔ_ｏｐは、データの選択や演算を行うデータ操作時間である。

データ・スキャン時間ｔ_ｓｃａｎは、次の式（４）により、データ操作時間ｔ_ｏｐは、次の式５により算出することができる。なお、式（４）中、Ｄ_ｉｎは、入力されるデータのデータ・サイズであり、Ｕ_ｓｃａｎは、単位データ・サイズ当たりのスキャン時間である。式（５）中、Ｄ_ｏｐは、操作対象のデータのデータ・サイズであり、Ｕ_ｏｐは、単位データ・サイズ当たりの操作時間である。これらのＵ_ｓｃａｎ、Ｕ_ｏｐは、実際に、ＲＤＢＭＳにより実行し、また、ストリーム・データ処理を行い、予め求めておき、その求めた値を用いる。

上記式（４）中、入力されるデータ・サイズは、次の（ｉ）〜（ｉｉｉ）の処理を順に実行することにより求めることができる。
（ｉ）複数のテーブルを結合（join）する処理がある場合、入力されたデータを直積したデータ・サイズを計算する。
（ｉｉ）ｗｈｅｒｅ節、ｈａｖｉｎｇ節がある場合、予め過去に蓄積されたデータ（統計情報）からその各条件のフィルタ率、すなわち該当するデータを抽出できる確率を求めておき、上記（ｉ）の処理後のデータに対して、そのフィルタ率を適用したときのデータ・サイズを計算する。ここで、ｈａｖｉｎｇ節は、ｗｈｅｒｅ節と同様、条件を指定するものであるが、ＡＶＧ等の集約演算において使用されるコマンドである。
（ｉｉｉ）上記（ｉｉ）の処理後のデータに対して、Ｓｅｌｅｃｔ処理で選択されるカラム選択率を適用したときのデータ・サイズを計算する。ここで、カラム選択率は、選択されるカラム数を、入力されるデータのカラム数を除することにより算出される値である。

上記式（５）中、操作対象のデータ・サイズは、上記（ｉ）の処理後のデータ・サイズと、上記（ｉｉ）の処理後のデータ・サイズとを加算した値を用いることができる。

具体例を用いて説明する。入力ＳＱＬは、図１０に示した例の入力ＳＱＬ４０を使用するものとする。入力データは、ストリーム・データ（car_all_table）であり、各車両が１００ｍｓｅｃ毎に１００カラムのパケットを送信し、それが入力されるものとする。１カラムのデータは、４バイトとする。１０００台の車両がそのパケットを送信するものとする。すると、ストリーム・データのデータ・レートは、１００カラム×４バイト×１０パケット／ｓｅｃ×１０００台＝４ＭＢ／ｓｅｃとなる。

また、蓄積されたデータ（conv_fav_car_table）は、車両１００００台分の３０カラムのデータとすると、１００００台×３０カラム×４バイト＝１．２ＭＢとなる。

ストリーム・データのノード内でのバッファリング時間、すなわちＰノードでのバッファリング時間（時間範囲）を、１ｓｅｃとし、過去の統計情報から得られるフィルタ率を１％とする。なお、フィルタ率は、平均速度が５ｋｍ／ｈより小さく、かつエンジン稼働時間が１２０分より大きいものについてのものである。ＲＤＢＭＳで処理を行う場合の単位データ・スキャン時間を１０ｓｅｃ／ＭＢとし、ＲＤＢＭＳで処理を行う場合の単位データ操作時間を２ｓｅｃ／ＭＢとする。ストリーム・データ処理における単位データ・スキャン時間を２ｓｅｃ／ＭＢ、ストリーム・データ処理における単位データ操作時間を１ｓｅｃ／ＭＢとする。ストリーム・データ処理は、Ｊａｖａ（登録商標）プログラムのメモリ処理とする。

図１１（ａ）に示したノード７０（SLOW_LONG_OP_CARS）については、下記（ａ）〜（ｆ）に示すようにして、各値を算出することができる。
（ａ）メモリ増加量は、入力されるデータのデータ量とされ、データ・レート×バッファリング時間により算出する。すなわち、４ＭＢ／ｓｅｃ×１ｓｅｃ＝４ＭＢとなる。
（ｂ）操作対象データ・サイズは、上記（ａ）で算出したメモリ増加量＋そのメモリ増加量×フィルタ率により算出する。すなわち、４ＭＢ＋４ＭＢ×０．０１＝４．０４ＭＢとなる。
（ｃ）ＲＤＢＭＳで処理を行う場合の処理時間ｔ_{ＲＤＢＭＳ}は、上記（ａ）で算出したメモリ増加量×ＲＤＢＭＳで処理を行う場合の単位データ・スキャン時間＋上記（ｂ）で算出した操作対象データ・サイズ×ＲＤＢＭＳで処理を行う場合の単位データ操作時間により算出する。すなわち、ｔ_{ＲＤＢＭＳ}＝４ＭＢ×１０ｓｅｃ／ＭＢ＋４．０４ＭＢ×２ｓｅｃ／ＭＢ＝４８．０８ｓｅｃとなる。
（ｄ）ストリーム・データ処理を行う場合の処理時間ｔ_Ｓは、上記（ａ）で算出したメモリ増加量×ストリーム・データ処理における単位データ・スキャン時間＋上記（ｂ）で算出した操作対象データ・サイズ×ストリーム・データ処理における単位データ操作時間により算出する。すなわち、ｔ_Ｓ＝４ＭＢ×２ｓｅｃ／ＭＢ＋４．０４ＭＢ×１ｓｅｃ／ＭＢ＝１２．０４ｓｅｃとなる。
（ｅ）削減される処理時間ｔ_Ｄは、ｔ_{ＲＤＢＭＳ}−ｔ_Ｓにより算出する。すなわち、ｔ_Ｄ＝４８．０８ｓｅｃ−１２．０４ｓｅｃ＝３６．０４ｓｅｃとなる。
（ｆ）ノード７２へ出力するデータのデータ・サイズは、上記（ａ）で算出したメモリ増加量×フィルタ率×カラム選択率により算出する。カラム選択率は、選択されるカラム数が１で、入力されるカラム数が１００であるため、１／１００＝０．０１である。すると、このデータ・サイズは、４ＭＢ×０．０１×０．０１＝０．０００４ＭＢ（０．４ｋＢ）となる。

図１１（ａ）に示したノード７１（CONV_STORE_FAV_CAR）については、下記（ａ’）〜（ｆ’）に示すようにして、各値を算出することができる。なお、（ｃ’）〜（ｅ’）については、上記（ｃ）〜（ｅ）と同様の計算式により算出する。
（ａ’）メモリ増加量は、入力されるデータであり、１．２ＭＢである。
（ｂ’）操作対象データ・サイズは、上記（ａ’）と同じ１．２ＭＢである。
（ｃ’）ｔ_{ＲＤＢＭＳ}は、１．２ＭＢ×１０ｓｅｃ／ＭＢ＋１．２ＭＢ×２ｓｅｃ／ＭＢ＝１４．４ｓｅｃとなる。
（ｄ’）ｔ_Ｓは、１．２ＭＢ×２ｓｅｃ／ＭＢ＋１．２ＭＢ×１ｓｅｃ／ＭＢ＝３．６ｓｅｃとなる。
（ｅ’）ｔ_Ｄは、１４．４ｓｅｃ−３．６ｓｅｃ＝１０．８ｓｅｃとなる。
（ｆ’）ノード７２へ出力するデータのデータ・サイズは、上記（ａ’）のメモリ増加量×カラム選択率により算出する。カラム選択率は、選択されるカラム数が１で、入力されるカラム数が３０であるため、１／３０である。すると、このデータ・サイズは、１．２ＭＢ×１／３０＝０．０４ＭＢ（４０ｋＢ）となる。

図１１（ａ）に示したノード７２については、下記（ａ”）〜（ｅ”）に示すようにして、各値を算出することができる。なお、（ｃ”）〜（ｅ”）については、上記（ｃ）〜（ｅ）と同様の計算式により算出する。
（ａ”）メモリ増加量は、ＷＩＮＤＯＷ時間分の入力データで、ＷＩＮＤＯＷ時間分のノード７０から出力されるデータと、ＷＩＮＤＯＷ時間分のノード７１から出力されるデータとの直積により算出する。ここでは、ＷＩＮＤＯＷ時間を１０分（６００ｓｅｃ）とする。すると、（０．４ｋＢ×６００ｓｅｃ）×（４０ｋＢ×６００ｓｅｃ）＝５７６００００ｋＢ（５７６０ＭＢ）となる。
（ｂ”）操作対象データ・サイズは、上記（ａ”）と同じ５７６０ＭＢである。
（ｃ”）ｔ_{ＲＤＢＭＳ}は、５７６０ＭＢ×１０ｓｅｃ／ＭＢ＋５７６０ＭＢ×２ｓｅｃ／ＭＢ＝６９１２０ｓｅｃとなる。
（ｄ”）ｔ_Ｓは、５７６０ＭＢ×２ｓｅｃ／ＭＢ＋５７６０ＭＢ×１ｓｅｃ／ＭＢ＝１７２８０ｓｅｃとなる。
（ｅ”）ｔ_Ｄは、６９１２０ｓｅｃ−１７２８０ｓｅｃ＝５１８４０ｓｅｃとなる。

これまで、本発明の抽出装置、その抽出装置を備えるデータ処理システムおよび抽出方法について、図面を参照して詳細に説明してきたが、他の実施形態や、追加、変更、削除など、当業者が想到することができる範囲内で変更することができ、いずれの態様においても本発明の作用・効果を奏する限り、本発明の範囲に含まれるものである。したがって、抽出装置と変換装置とを備えるクライアント等も提供することができる。

また、この抽出方法は、各機能部が実行する処理ステップを、コンピュータに実行させるための抽出プログラムにより実現することができ、本発明では、この抽出プログラムも提供することが可能である。なお、この抽出プログラムは、ＣＤ−ＲＯＭ、ＤＶＤ、ＳＤカード、ＨＤＤ等の記録媒体に格納して提供することができる。また、コンテンツ・サーバ等に格納され、そのコンテンツ・サーバ等からダウンロードすることにより取得することも可能である。

１０…ＩＯＴデバイス、１１…パケット通信網、１２…クライアント、１３…フロント・エンド・サーバ、１４…バック・エンド・サーバ、２０…ホスト・コントローラ、２１…ＣＰＵ、２２…ＲＡＭ、２３…グラフィック・コントローラ、２４…表示装置、２５…入出力コントローラ、２６…通信インタフェース、２７…ＨＤＤ、２８…ＣＤ／ＤＶＤドライブ、２９…ＲＯＭ、３０…入出力チップ、３１…ＣＰＵ、３２…メモリ、３３…ＨＤＤ、３４…通信インタフェース、３５…サーバ・ブレード、３６…モジュール、３７…バック・プレーン、４０…入力ＳＱＬ、４１…ユーザ定義入力パラメータ、４２…コンパイラ、４３、４５…ＥＴＬ処理プログラム、４４…パイプライン処理プログラムおよび非パイプライン処理プログラム、４６…第１のデータベース、４７…第２のデータベース、５０〜５７…ノード、６０…入力部、６１…演算部、６２…抽出部、６３…グラフ生成部、６４…分類部、７０〜７２…ノード、７３…パイプライン処理プログラム、７４…残余ＳＱＬ

Claims (16)

1. データベースを管理するデータベース管理システムに発行する１以上の命令をサブクエリーとして含むクエリーから、前記データベースへ継続的に入力されるストリーム・データに対して処理を行うためのプログラムに変換するサブクエリーを変換対象として抽出する抽出装置であって、
   前記クエリーと、前記ストリーム・データの処理により使用量が増加するメモリの最大メモリ増加量と、前記データベース管理システムが前記クエリーを実行した場合と比較して前記プログラムにより前記ストリーム・データを処理した場合に削減される単位メモリ増加量当たりの処理時間としての効率の下限値との入力を受け付ける入力部と、
   前記クエリーに含まれる各前記サブクエリーにつき、前記プログラムに変換して前記ストリーム・データを処理した場合のメモリ増加量と、前記データベース管理システムが実行した場合と比較して前記ストリーム・データを処理した場合に削減される処理時間とを計算し、計算した少なくとも１つの前記メモリ増加量と前記削減される処理時間とを用いて前記効率を算出する演算部と、
   算出された前記効率が前記下限値以上の前記サブクエリーを少なくとも１つ選択し、選択した前記サブクエリーにつき計算されたメモリ増加量を積算し、積算した前記メモリ増加量が前記最大メモリ増加量以下となることを条件として、選択した前記サブクエリーを前記変換対象として抽出する抽出部とを含む、抽出装置。
2. 前記抽出部は、算出された前記効率が大きい順に前記サブクエリーを選択する、請求項１に記載の抽出装置。
3. 前記クエリーを構文解析し、各前記サブクエリーを各ノードとするツリー構造で表されるグラフを生成するグラフ生成部と、
   前記クエリーを構文解析した結果に基づき、前記各ノードにつき、入力されたデータを処理し、処理結果を出力するパイプライン処理が可能な第１ノードか、前記パイプライン処理が不可の第２ノードかを決定し、生成された前記グラフを参照して、根ノードから階層的に繋がるノードが前記第１ノードのみからなる１以上の第１ノード群と、残りのノードからなる１以上の第２ノード群とに分類する分類部とをさらに含み、
   前記抽出部は、前記第１ノード群に分類されたノードにつき、前記効率が前記下限値以上であるノードを選択し、前記変換対象を抽出する、請求項１に記載の抽出装置。
4. 前記分類部は、前記グラフを参照して、１以上の前記第２ノード群を、葉ノードから階層的に繋がるノードが前記第１ノードのみからなる１以上の第３ノード群と、残りのノードからなる１以上の第４ノード群に分類し、
   前記抽出部は、前記第１ノード群に分類されたノードにつき、前記下限値以上であるノードを選択し、前記変換対象を全て抽出した後、積算した前記メモリ増加量が前記最大メモリ増加量に達していない場合、前記第３ノード群に分類されたノードにつき、前記効率が前記下限値以上であるノードを選択し、前記変換対象を抽出する、請求項３に記載の抽出装置。
5. 前記演算部は、前記メモリ増加量と前記削減される処理時間を、前記ストリーム・データのデータ・レート、前記ストリーム・データに対して処理を行う時間範囲、過去に前記クエリーを実行した結果から得られた統計情報、前記クエリーの操作に関する情報に基づき算出する、請求項１に記載の抽出装置。
6. 請求項１に記載の抽出装置と、前記抽出装置により抽出された変換対象のサブクエリーを、ストリーム・データを処理するためのプログラムに変換し、変換されない残りのサブクエリーを生成する変換装置と、変換された前記プログラムを実行して、前記ストリーム・データを処理し、処理結果を出力する第１処理装置と、前記残りのクエリーを実行し、前記処理結果とデータベースに格納されたストリーム・データとに対して処理を行う該データベースを管理するデータベース管理システムを備える第２処理装置とを含む、データ処理システム。
7. データベースを管理するデータベース管理システムに発行する１以上の命令をサブクエリーとして含むクエリーから、前記データベースへ継続的に入力されるストリーム・データに対して処理を行うためのプログラムに変換するサブクエリーを変換対象として抽出する方法であって、
   前記クエリーと、前記ストリーム・データの処理により使用量が増加するメモリの最大メモリ増加量と、前記データベース管理システムが前記クエリーを実行した場合と比較して前記プログラムにより前記ストリーム・データを処理した場合に削減される単位メモリ増加量当たりの処理時間としての効率の下限値との入力を受け付けるステップと、
   前記クエリーに含まれる各前記サブクエリーにつき、前記プログラムに変換して前記ストリーム・データを処理した場合のメモリ増加量と、前記データベース管理システムが実行した場合と比較して前記ストリーム・データを処理した場合に削減される処理時間とを計算し、計算した少なくとも１つの前記メモリ増加量と前記削減される処理時間とを用いて前記効率を算出するステップと、
   算出された前記効率が前記下限値以上の前記サブクエリーを少なくとも１つ選択し、選択した前記サブクエリーにつき計算されたメモリ増加量を積算し、積算した前記メモリ増加量が前記最大メモリ増加量以下となることを条件として、選択した前記サブクエリーを前記変換対象として抽出するステップとを含む、抽出方法。
8. 前記抽出するステップでは、前記算出するステップで算出された前記効率が大きい順に前記サブクエリーを選択する、請求項７に記載の抽出方法。
9. 前記入力を受け付けるステップ後、前記クエリーを構文解析し、各前記サブクエリーを各ノードとするツリー構造で表されるグラフを生成するステップと、
   前記クエリーを構文解析した結果に基づき、前記各ノードにつき、入力されたデータを処理し、処理結果を出力するパイプライン処理が可能な第１ノードか、前記パイプライン処理が不可の第２ノードかを決定し、生成された前記グラフを参照して、根ノードから階層的に繋がるノードが前記第１ノードのみからなる１以上の第１ノード群と、残りのノードからなる１以上の第２ノード群とに分類するステップとをさらに含み、
   前記抽出するステップでは、前記第１ノード群に分類されたノードにつき、前記効率が前記下限値以上であるノードを選択し、前記変換対象を抽出する、請求項７に記載の抽出方法。
10. 前記分類するステップでは、前記グラフを参照して、１以上の前記第２ノード群を、葉ノードから階層的に繋がるノードが前記第１ノードのみからなる１以上の第３ノード群と、残りのノードからなる１以上の第４ノード群に分類し、
    前記抽出するステップでは、前記第１ノード群に分類されたノードにつき、前記下限値以上であるノードを選択し、前記変換対象を全て抽出した後、積算した前記メモリ増加量が前記最大メモリ増加量に達していない場合、前記第３ノード群に分類されたノードにつき、前記効率が前記下限値以上であるノードを選択し、前記変換対象を抽出する、請求項９に記載の抽出方法。
11. 前記算出するステップでは、前記メモリ増加量と前記削減される処理時間を、前記ストリーム・データのデータ・レート、前記ストリーム・データに対して処理を行う時間範囲、過去に前記クエリーを実行した結果から得られた統計情報、前記クエリーの操作に関する情報に基づき算出する、請求項７に記載の抽出方法。
12. データベースを管理するデータベース管理システムに発行する１以上の命令をサブクエリーとして含むクエリーから、前記データベースへ継続的に入力されるストリーム・データに対して処理を行うためのプログラムに変換するサブクエリーを変換対象として抽出する処理をコンピュータに実行させるための抽出プログラムであって、前記コンピュータに、
    前記クエリーと、前記ストリーム・データの処理により使用量が増加するメモリの最大メモリ増加量と、前記データベース管理システムが前記クエリーを実行した場合と比較して前記プログラムにより前記ストリーム・データを処理した場合に削減される単位メモリ増加量当たりの処理時間としての効率の下限値との入力を受け付けるステップと、
    前記クエリーに含まれる各前記サブクエリーにつき、前記プログラムに変換して前記ストリーム・データを処理した場合のメモリ増加量と、前記データベース管理システムが実行した場合と比較して前記ストリーム・データを処理した場合に削減される処理時間とを計算し、計算した少なくとも１つの前記メモリ増加量と前記削減される処理時間とを用いて前記効率を算出するステップと、
    算出された前記効率が前記下限値以上の前記サブクエリーを少なくとも１つ選択し、選択した前記サブクエリーにつき計算されたメモリ増加量を積算し、積算した前記メモリ増加量が前記最大メモリ増加量以下となることを条件として、選択した前記サブクエリーを前記変換対象として抽出するステップとを実行させる、抽出プログラム。
13. 前記抽出するステップでは、前記算出するステップで算出された前記効率が大きい順に前記サブクエリーを選択するステップを実行させる、請求項１２に記載の抽出プログラム。
14. 前記入力を受け付けるステップ後、前記クエリーを構文解析し、各前記サブクエリーを各ノードとするツリー構造で表されるグラフを生成するステップと、
    前記クエリーを構文解析した結果に基づき、前記各ノードにつき、入力されたデータを処理し、処理結果を出力するパイプライン処理が可能な第１ノードか、前記パイプライン処理が不可の第２ノードかを決定し、生成された前記グラフを参照して、根ノードから階層的に繋がるノードが前記第１ノードのみからなる１以上の第１ノード群と、残りのノードからなる１以上の第２ノード群とに分類するステップとをさらに実行させ、
    前記抽出するステップでは、前記第１ノード群に分類されたノードにつき、前記効率が前記下限値以上であるノードを選択し、前記変換対象を抽出するステップを実行させる、請求項１２に記載の抽出プログラム。
15. 前記分類するステップでは、前記グラフを参照して、１以上の前記第２ノード群を、葉ノードから階層的に繋がるノードが前記第１ノードのみからなる１以上の第３ノード群と、残りのノードからなる１以上の第４ノード群に分類するステップを実行させ、
    前記抽出するステップでは、前記第１ノード群に分類されたノードにつき、前記下限値以上であるノードを選択し、前記変換対象を全て抽出した後、積算した前記メモリ増加量が前記最大メモリ増加量に達していない場合、前記第３ノード群に分類されたノードにつき、前記効率が前記下限値以上であるノードを選択し、前記変換対象を抽出するステップを実行させる、請求項１４に記載の抽出プログラム。
16. 前記算出するステップでは、前記メモリ増加量と前記削減される処理時間を、前記ストリーム・データのデータ・レート、前記ストリーム・データに対して処理を行う時間範囲、過去に前記クエリーを実行した結果から得られた統計情報、前記クエリーの操作に関する情報に基づき算出するステップを実行させる、請求項１２に記載の抽出プログラム。