JP4687253B2 - ストリームデータ処理システムのクエリ処理方法 - Google Patents

Description

本発明は、リアルタイムストリームデータとアーカイブデータに対するシームレスなアクセスが可能なストリームデータ処理システムの構成方法、該ストリームデータ処理システムにおけるリアルタイムデータとアーカイブデータのシームレスなアクセス方法、および複数の該ストリームデータ処理システムの連携によるストリームデータの処理方法に関する。

ストレージに格納されたデータに対する処理を実行するデータベース管理システム（以下、ＤＢＭＳとする）に対して、時々刻々と到着するデータをリアルタイム処理するデータ処理システムに対する要求が高まっている。例えば、株式の売買を行うシステムでは、株価の変動にいかに迅速に反応できるかがシステムの最重要の課題の一つであり、従来のＤＢＭＳのように株式のデータを一旦記憶装置に格納してから、該格納データに関して検索を行うような方法では、株価変動のスピードに即応できず、ビジネスチャンスを逃してしまうことになりかねない。米国出願５４９５６００（特許文献１）では、記憶されているクエリが周期的に実行される機構を開示しているが、株価のようにデータが入ってきた瞬間にクエリを実行することが重要なリアルタイムデータ処理には適用が困難であった。

このようなリアルタイムデータ処理に好適なデータ処理システムとして、ストリームデータ処理システムが提案されている。例えばＲ． Ｍｏｔｗａｎｉ， Ｊ． Ｗｉｄｏｍ， Ａ． Ａｒａｓｕ， Ｂ． Ｂａｂｃｏｃｋ， Ｓ． Ｂａｂｕ， Ｍ． Ｄａｔａｒ， Ｇ． Ｍａｎｋｕ， Ｃ． Ｏｌｓｔｏｎ， Ｊ． Ｒｏｓｅｎｓｔｅｉｎ， ａｎｄ Ｒ． Ｖａｒｍａ著：“Ｑｕｅｒｙ Ｐｒｏｃｅｓｓｉｎｇ， Ｒｅｓｏｕｒｃｅ Ｍａｎａｇｅｍｅｎｔ， ａｎｄ Ａｐｐｒｏｘｉｍａｔｉｏｎ ｉｎ ａ Ｄａｔａ Ｓｔｒｅａｍ Ｍａｎａｇｅｍｅｎｔ Ｓｙｓｔｅｍ”，Ｉｎ Ｐｒｏｃ． ｏｆ ｔｈｅ ２００３ Ｃｏｎｆ． ｏｎ Ｉｎｎｏｖａｔｉｖｅ Ｄａｔａ Ｓｙｓｔｅｍｓ Ｒｅｓｅａｒｃｈ （ＣＩＤＲ）， Ｊａｎｕａｒｙ ２００３ （非特許文献１）に開示されているストリームデータ処理システムＳＴＲＥＡＭが開示されている。

ストリームデータ処理システムでは、従来のＤＢＭＳとは異なり、まずクエリ（問合せ）をシステムに登録し、データの到来と共に該クエリが継続的に実行される。前記ＳＴＲＥＡＭでは、ストリームデータを効率的に処理するために、ストリームデータの一部を切り取るスライディングウィンドウと呼ばれる概念を導入している。スライディングウィンドウ指定を含むクエリの記述言語の好適な例としては非特許文献１に開示されているＣＱＬ（Ｃｏｎｔｉｎｕｏｕｓ Ｑｕｅｒｙ Ｌａｎｇｕａｇｅ）をあげることができる。ＣＱＬは、ＤＢＭＳで広く用いられているＳＱＬ（Ｓｔｒｕｃｔｕｒｅｄ Ｑｕｅｒｙ Ｌａｎｇｕａｇｅ）のＦＲＯＭ句に、ストリーム名に続いて括弧を用いることにより、スライディングウィンドウを指定する拡張が施されている。ＳＱＬに関しては、Ｃ． Ｊ． Ｄａｔｅ， Ｈｕｇｈ Ｄａｒｗｅｎ著：“Ａ Ｇｕｉｄｅ ｔｏ ＳＱＬ Ｓｔａｎｄａｒｄ （４ｔｈ Ｅｄｉｔｉｏｎ）”，Ａｄｄｉｓｏｎ−Ｗｅｓｌｅｙ Ｐｒｏｆｅｓｓｉｏｎａｌ； ４ ｅｄｉｔｉｏｎ （Ｎｏｖｅｍｂｅｒ ８， １９９６），ＩＳＢＮ： ０２０１９６４２６０（非特許文献２）が詳しい。図１４は非特許文献１の２．１節に示されているＣＱＬによるクエリの例である。該クエリでは、ドメインｓｔａｎｆｏｒｄ．ｅｄｕからの過去１日分のアクセスの総数を計算する。Ｒｅｑｕｅｓｔは従来のＤＢＭＳで取り扱うテーブル（表）ではなく、終わりのないストリームであるので、スライディングウィンドウ指定［Ｒａｎｇｅ １ Ｄａｙ Ｐｒｅｃｅｄｉｎｇ］なしでは、その総数を数えることはできない。スライディングウィンドウによって切り取られたストリームデータはメモリ上に保持され、クエリ処理に使用される。

ストリームデータ処理システムは、ファイナンシャルアプリケーション、交通情報システム、計算機システム管理に代表される、リアルタイム処理が必要とされる応用に対する適用が期待されている。しかしながら、従来のストリームデータ処理システムでは、（１）負荷の増大、もしくは障害によってストリーム処理システムのクエリ処理が遅延、もしくは停止してしまった際に、ストリームデータが失われてしまう、（２）クエリで指定されたウィンドウの大きさに対して利用可能なメモリが不足している場合にはストリームデータ処理が実行できない、（３）登録していたクエリよりも、さらに時間をさかのぼって検索範囲を拡大することができない、さらに、（４）ストリームデータ処理システムの能力を上回る量のストリームデータが到来した場合、もしくはデータ処理が必要となった場合に業務に必要な性能を保つことができないという問題があり、実業務への適用が困難であった。

米国特許第５４９５６００号公報

Ｒ． Ｍｏｔｗａｎｉ， Ｊ． Ｗｉｄｏｍ， Ａ． Ａｒａｓｕ， Ｂ． Ｂａｂｃｏｃｋ， Ｓ． Ｂａｂｕ， Ｍ． Ｄａｔａｒ， Ｇ． Ｍａｎｋｕ， Ｃ． Ｏｌｓｔｏｎ， Ｊ． Ｒｏｓｅｎｓｔｅｉｎ， ａｎｄ Ｒ． Ｖａｒｍａ著："Ｑｕｅｒｙ Ｐｒｏｃｅｓｓｉｎｇ， Ｒｅｓｏｕｒｃｅ Ｍａｎａｇｅｍｅｎｔ， ａｎｄ Ａｐｐｒｏｘｉｍａｔｉｏｎ ｉｎ ａ Ｄａｔａ Ｓｔｒｅａｍ Ｍａｎａｇｅｍｅｎｔ Ｓｙｓｔｅｍ"，Ｉｎ Ｐｒｏｃ． ｏｆ ｔｈｅ ２００３ Ｃｏｎｆ． ｏｎ Ｉｎｎｏｖａｔｉｖｅ Ｄａｔａ Ｓｙｓｔｅｍｓ Ｒｅｓｅａｒｃｈ （ＣＩＤＲ）， Ｊａｎｕａｒｙ ２００３ Ｃ． Ｊ． Ｄａｔｅ， Ｈｕｇｈ Ｄａｒｗｅｎ著："Ａ Ｇｕｉｄｅ ｔｏ ＳＱＬ Ｓｔａｎｄａｒｄ （４ｔｈ Ｅｄｉｔｉｏｎ）"，Ａｄｄｉｓｏｎ−Ｗｅｓｌｅｙ Ｐｒｏｆｅｓｓｉｏｎａｌ； ４ ｅｄｉｔｉｏｎ （Ｎｏｖｅｍｂｅｒ ８， １９９６），ＩＳＢＮ： ０２０１９６４２６０ Ｓｔｒａｔｉｓ Ｖｉｇｌａｓ，Ｊｅｆｆｒｅｙ Ｆ． Ｎａｕｇｈｔｏｎ，Ｊｏｓｅｆ Ｂｕｒｇｅｒ著："Ｍａｘｉｍｉｚｉｎｇ ｔｈｅ Ｏｕｔｐｕｔ Ｒａｔｅ ｏｆ Ｍｕｌｔｉ−Ｗａｙ Ｊｏｉｎ Ｑｕｅｒｉｅｓ ｏｖｅｒ Ｓｔｒｅａｍｉｎｇ Ｉｎｆｏｒｍａｔｉｏｎ Ｓｏｕｒｃｅｓ"，Ｉｎ Ｐｒｏｃ． ｏｆ ＶＬＤＢ ２００３，ｐｐ．２８５−２９６ Ｊｅｆｆｒｅｙ Ｄ．Ｕｌｌｍａｎ著，"ＰＲＩＮＣＩＰＬＥＳ ＯＦ ＤＡＴＡＢＡＳＥ ＡＮＤ ＫＮＯＷＬＥＤＧＥ−ＢＡＳＥ ＳＹＳＴＥＭＳ"，ＶＯＬＵＭＥ ＩＩ，ＣＯＭＰＵＴＥＲ ＳＣＩＥＮＣＥ ＰＲＥＳＳ，ＩＳＢＮ ０−７１６７−８１６２−Ｘ，第１４章"Ｏｐｔｉｍｉｚａｔｉｏｎ ｆｏｒ Ｃｏｎｊｕｎｃｔｉｖｅ Ｑｕｅｒｉｅｓ" Ｓｔｒａｔｉｓ Ｖｉｇｌａｓ，Ｊｅｆｆｒｅｙ Ｆ． Ｎａｕｇｈｔｏｎ著："Ｒａｔｅ−ｂａｓｅｄ ｑｕｅｒｙ ｏｐｔｉｍｉｚａｔｉｏｎ ｆｏｒ ｓｔｒｅａｍｉｎｇ ｉｎｆｏｒｍａｔｉｏｎ ｓｏｕｒｃｅｓ"，Ｉｎ Ｐｒｏｃ． ｏｆ ＳＩＧＭＯＤ Ｃｏｎｆｅｒｅｎｃｅ ２００２，ｐｐ． ３７−４８

実業務への適用可能なストリームデータ処理システムを提供するために、（１）負荷の増大、もしくは障害によってストリーム処理システムのクエリ処理が遅延、もしくは停止してしまった際にもストリームデータを保護することが課題となっていた。また、（２）クエリで指定されたウィンドウの大きさに対して利用可能なメモリが不足している場合にもストリームデータ処理を実行することも課題となっていた。さらに、（３）登録していたクエリよりも、さらに時間をさかのぼって検索範囲を拡大できることも課題となっており、最後に（４）ストリームデータ処理システムの能力を上回る量のストリームデータが到来した場合、もしくはデータ処理が必要となった場合にも業務に必要な性能を保つ機構を提供することが課題となっていた。

本発明の第１の目的は、負荷の増大、もしくは障害によってストリーム処理システムのクエリ処理が遅延、もしくは停止してしまった際にもストリームデータを保護する機構を提供することである。また、本発明の第２の目的は、クエリで指定されたウィンドウの大きさに対して利用可能なメモリが不足している場合にもストリームデータ処理を実行する機構を提供することである。さらに、本発明の第３の目的は、登録していたクエリよりも、さらに時間をさかのぼって検索範囲を拡大できる機構を提供することである。最後に、本発明の第４の目的は、ストリームデータ処理システムの能力を上回る量のストリームデータが到来した場合、もしくはデータ処理が必要となった場合にも業務に必要な性能を保つ機構を提供することである。

前記第１の目的を達成するため、本発明では必要に応じてストリームデータの一部、もしくは全部を複製し、不揮発性の記憶媒体にアーカイブする機構を設ける。次に、第２の目的を達成するため、本発明ではユーザ、もしくはアプリケーションによってシステムに登録されたクエリのうち、メモリ不足で実行不可能なクエリをメモリ上で実行できるクエリと、前記アーカイブされたデータに対して実行するクエリに書き換え、メモリ上のストリームデータに対して前記書き換え後のクエリを実行した結果と、前記アーカイブデータに対して実行した前記書き換え後のクエリを実行した結果とを統合して、ユーザ、もしくはアプリケーションに結果を返す機構を提供する。さらに、第３の目的を達成するために、本発明ではメモリ上に存在しないストリームデータに対する問合せをアーカイブされたデータに対して実行するとともに、新たに登録されたクエリに利用可能なメモリを徐々に割り当ててクエリ処理を可能とする機構を提供する。最後に、第４の目的を達成するために、本発明では複数のストリームデータ処理システムを連携させ、クエリ処理の性能を向上させる機構を提供する。

本発明を用いることにより、高信頼・高可用のリアルタイムデータ処理が可能なストリームデータ処理システムが実現できる。

図１に、本発明の実施例のストリームデータ処理システム、及び関連するシステムの構成を示す。アプリケーション１（１０２）を実行するクライアント計算機１０１、アプリケーション２（１０４）を実行するクライアント計算機１０３は、ネットワーク１０７を介してストリームデータ処理システム１１５に接続されている。ネットワーク１０７は、イーサネット（登録商標）、光ファイバ、ＦＤＤＩで接続されるローカルエリアネットワーク（ＬＡＮ）、もしくはＬＡＮよりも低速なインターネットを含んだワイドエリアネットワーク（ＷＡＮ）でも差し支えない。また、クライアント計算機は（株）日立製作所のＨｉｔａｃｈｉ ＦＬＯＲＡ（登録商標）などのパーソナルコンピュータ、（株）日立製作所のＨｉｔａｃｈｉ ＵＮＩＸ（登録商標）ワークステーション９０００Ｖ Ｂ２６００などの任意のコンピュータシステムでよい。

アプリケーションは、ストリームデータ処理システムに対してまずクエリ１０５を登録する。クエリ登録の手順、ストリームデータ処理システム内部のデータの格納方法、格納形式の好適な例を図１、図２、および図３を用いて説明する。クライアント計算機１０３のアプリケーション２（１０４）は、図２に示すクエリ登録コマンド２０１を用いて、クエリＱ１（２０１）をストリームデータ処理システム１１５内のコマンドマネージャ１０８に送信する。コマンドマネージャ１０８は受け付けたコマンドを解析し、クエリ登録コマンド２０１中のクエリ部分（２０１の２行目から４行目）をクエリ解析部１０９に送る。クエリ解析部１０９で解析されたクエリは、続いてクエリ最適化部１１０に送られる。クエリ最適化部１１０では効率のよい実行方式を選択する最適化処理を受け、クエリ生成部１１１で該最適化処理の結果に基づいてクエリの実行方式を生成する。クエリＱ１（２０１）のような宣言形式のクエリから、その実行形式を生成する方法に関しては、非特許文献１の第３節にその方法が開示されている。実行形式に変換されたクエリはクエリリポジトリ１１２に格納される。

図２の２０１はクエリＱ１をストリームデータ処理システムに登録する際の好適なコマンドの記述例である。Ｑ１は過去２週間分の欠陥品データ（ｄｅｆｅｃｔ＿ｌｉｓｔストリーム）を作業工程にある過去２時間分の部品データ（ｐａｒｔｓストリーム）に付きあわせ、部品ＩＤ（ｐａｒｔｓ．ｉｄ）、部品製造者名（ｐａｒｔｓ．ｍａｎｕｆａｃｔｕｒｅｒ）、部品ロット番号（ｐａｔｓ．ｌｏｔｎｏ）を抜き出すクエリであり（２０１の２行目から４行目）、該クエリの実行開始時刻が日本標準時間の２００４年９月８日午前９時０分０秒であること（２０１の５行目）、同終了時刻が日本標準時間の２００４年９月１０日午前５時０分０秒であること（２０１の６行目）を示している。

本クエリＱ１は、クエリリポジトリ（図１の１１２）中のクエリ管理テーブルに格納される。クエリ管理テーブルの構成を図３に示す。「クエリ名」カラム３０１には、登録したクエリの名前を格納する。次に「クエリ」カラム３０２には、前述のスライディングウィンドウ指定を含むクエリを格納する。クエリ記述言語は、前述のＣＱＬで差し支えない。次に、「クエリ実行形式格納先」カラム３０３には、前述したクエリ解析部１０９、クエリ最適化部１１０、およびクエリ生成部１１１によって生成されたクエリの実行形式の格納先のアドレス（ポインタ）が格納される。実行形式をあらかじめ作成しておくことにより、クエリの実行のたびにコンパイルを行うオーバヘッドを削減することができる。「登録者」カラム３０４、「登録日時」カラム３０５にはそれぞれ、クエリの登録者、クエリの登録日時が格納され、システムのアクセス管理、セキュリティ管理に使用される。次に「実行開始時刻」カラム３０６、「実行終了時刻」カラム３０７にはそれぞれ登録クエリの実行開始時刻と実行終了時刻が格納される。本情報を利用することにより、システムは複数のクエリに効率的に計算機資源を配分することができる。

最後に、「実行対象ストリーム」カラム３０８にはクエリ実行対象となるストリーム名が格納される。図２の２０２は、登録されたクエリのシステムからの削除するコマンドの記述例を示す。このコマンドを実行するとクエリ管理テーブルよりクエリ名Ｑ１のエントリが削除される。

次に、本実施例のストリームデータ処理システムへのストリームの登録方法、およびシステム内のデータ保持方法を図１、図４、および図５を用いて説明する。クライアント計算機１０３上で稼動するアプリケーション２（１０４）は、図４に示すストリーム登録コマンドを用いてストリーム定義の指示をストリームデータ処理システム１１５に対して発行する。コマンドを受け付けたコマンドマネージャ１０８はコマンドを解析し、システムディクショナリ１１８を参照して指定されたストリーム定義のスキーマをチェックし、そのストリーム定義を図５に示すストリーム管理テーブルに登録する。ストリーム管理テーブルはシステムディクショナリ１１８内に保管される。

以下、図４に例示するストリーム登録コマンドのうちｐａｒｔｓストリームのストリーム登録コマンド４０１、および該当する図５のストリーム管理テーブルのエントリを示しながらストリームの登録方法を具体的に説明する。ｐａｒｔｓストリームは、ｉｎｔｅｇｅｒ型のｉｄ属性、ｃｈａｒ（３２）型のｍａｎｕｆａｃｔｕｒｅｒ属性、ｉｎｔｅｇｅｒ型のｌｏｔｎｏ属性、そしてｄａｔｅ型のｇｅｎｄａｔｅ属性からなる（４０１の２行目、および３行目）。ストリーム名と該ストリームを構成する属性情報はそれぞれ、ストリーム管理テーブルの「ストリーム名」カラム５０１、および「ストリーム定義」カラム５０２に格納される。ストリーム定義コマンド４０１の４行目は、ｐａｒｔｓストリームの送信元がｎｉｓｈｉｚａｗａ＿ｐａｒｔｓ．ｃｏｍであることを、５行目はその送信プロトコルがＳＯＡＰ／ＨＴＴＰであることを、６行目は通信ポートとして８０８０用いていることを、７行目はｐａｒｔｓストリームの受付開始時刻が日本標準時間の２００４年９月８日午前９時０分０秒であることを、そして８行目はｐａｒｔｓストリームの受付終了時刻が日本標準時間の２００４年９月１０日午後５時０分０秒であることを示している。これらの情報は、それぞれストリーム管理テーブルの「ストリーム名」カラム５０１、「ストリーム定義」カラム５０２、「ストリームデータソース」カラム５０３、「プロトコル」カラム５０４、「ポート」カラム５０５、「ストリーム受付開始時間」カラム５０６、そして「ストリーム受付終了時間」カラム５０７）に格納される。さらにストリーム管理テーブルでは、ストリーム登録者とその登録日時がそれぞれ、「登録者」（５０８）、および「登録日時」カラム（５０９）に格納される。

次に、本願のストリームデータ処理システムにおけるアーカイブ機構を図１、図６、および図７を用いて説明する。クライアント計算機１０３のアプリケーション２（１０４）は、図６に示すａｒｃｈｉｖｅ ｓｔｒｅａｍコマンドを用いてストリームのアーカイブの指示をストリームデータ処理システム１１５に対して発行する（１２５）。コマンドを受け付けたコマンドマネージャ１０８はコマンドを解析し、図７に示すアーカイブ管理テーブルに登録する。アーカイブ管理テーブルはストリーム管理テーブルと同じく、システムディクショナリ１１８内に保管される。

図６に示すａｒｃｈｉｖｅ ｓｔｒｅａｍコマンドの詳細、および該コマンドのシステム登録方法を図６のｐａｒｔｓストリームのアーカイブ定義コマンド（アーカイブ指定）６０１、および該当する図７のアーカイブ管理テーブルのエントリを示しながら具体的に説明する。アーカイブ指定６０１の１行目は、アーカイブがｐａｒｔｓストリームを構成する属性中のｉｄ、ｍａｎｕｆａｃｔｕｒｅｒ、ｌｏｔｎｏ、ｇｅｎｄａｔｅを対象に実行されることを示している。アーカイブに含まれる属性は、図７のアーカイブ管理テーブルの「アーカイブ対象属性」カラム７０２に格納される。次にアーカイブ指定６０１の２行目は、本アーカイブ名がｐａｒｔｓ＿ａｒｃｈｉｖｅｄであり、アーカイブデータの格納先がＲＡＩＤ＿０１であることを示している。これらはそれぞれ、アーカイブ管理テーブルの「アーカイブ名」カラム７０３、および「アーカイブ先ストレージ」カラム７０６に格納される。アーカイブ指定６０１の３行目、および４行目はそれぞれ、本アーカイブの開始時刻と終了時刻を示しており、これらはアーカイブ管理テーブルの「アーカイブ開始時刻」カラム７０４、および「アーカイブ終了時刻」カラム７０５に格納される。アーカイブ指定６０１の５行目はアーカイブ実行時に属性ｉｄに対してサンプリングを行うことを、そして６行目はサンプリングの方法がランダムサンプリングであり、サンプリングレートが１０％であることを示している。サンプリングの可否、サンプリング対象属性、サンプリング方法、そしてサンプリングレートはそれぞれ、アーカイブ管理テーブルの「サンプリング」カラム７０７、「サンプリング対象属性」カラム７０８、「サンプリング方法」カラム７０９、および「サンプリングレート」カラム７１０に格納される。ストリームデータはその到来レートによってデータ量が莫大となる場合もあり、その全てを保存しておく必要がない場合に本サンプリング指定は非常に重要である。

全てのデータをアーカイブしておく必要がある場合には、アーカイブ指定６０２の６行目に示すように、ｓａｍｐｌｉｎｇ ｄｉｓａｂｌｅｄと指定すればよい。サンプリング指定があったストリームに関しては、ストリームを受け付けた場合に図１のストリームデータ処理システム１１５内のストリームデータフローマネージャ１１９の指示によってサンプリング実行部（１２６）がアーカイブ時にサンプリングを実行する。

最後に、アーカイブ指定６０１の７行目はアーカイブ作成時に暗号化を行うか否かを指定している。データ格納時の暗号化は、セキュリティへの必要性の高まりに伴ってその重要性が指摘されており、システムには不可欠な要素であるといえる。本属性は、アーカイブ管理テーブルの「暗号化」カラム７１１に格納される。アーカイブ定義６０１のｐａｒｔｓストリームに対しては暗号化を行わないため、本暗号化属性はｄｉｓａｂｌｅｄと指定されているが、アーカイブ定義６０２のｄｅｆｅｃｔ＿ｌｉｓｔストリームに関しては暗号化を有効とし、その暗号化方式がＤＥＳであることが指定されている。暗号化方式はアーカイブ管理テーブルの「暗号化方法」カラム７１２に格納される。

暗号化指定があったストリームに関しては、ストリームを受け付けた場合に図１のストリームデータ処理システム１１５内のストリームデータフローマネージャ１１９の指示によって暗号／復号化実行部１２７がアーカイブ実行時に暗号化を行う。そしてアーカイブからの読み出し時には暗号／復号化実行部１２７が複合化を実行する。アーカイブ管理テーブルの「登録者」カラム７１３、および「登録時刻」カラム７１４はアーカイブ指定の登録者と登録日時を示しており、システムのアクセスログ管理、セキュリティ管理に用いられる。

他のストリームデータ処理システムの主要な構成要素について、再び図１を用いて説明する。リレーショナルストア１１４は、従来のＤＢＭＳでの利用対象であったテーブル（表）を格納する。ストリームデータ処理システム１１５では、検索対象としてストリームデータに加えて従来ＤＢＭＳで利用していたテーブルも取り扱うことができる。テーブルを検索対象としたい場合には、図８に示すように、クエリのｆｒｏｍ句において検索対象のテーブルを指定すればよい。図８は従業員テーブルＥｍｐｌｏｙｅｅから、給与（ｓａｌａｒｙ）が３０万円以上の従業員のＩＤ（ｉｄ）、および名前（ｎａｍｅ）を検索するクエリである。スケジューリングマネージャ１１６は、ストリームクエリ処理時のシステムのスケジューリングを行う。また、メモリマネージャ１１７は、システム稼動時に必要に応じてメモリをクエリ処理エンジン１１３あるいは他のマネージャに割り当て、不要になった場合に回収処理を行う。以上でストリームデータ処理システム１１５の主要構成要素の説明を終了する。

次に、ストリームデータ処理システム１１５を用いたデータ処理の手順を図１および図９を用いて説明する。ストリームデータ処理システム１１５を用いたデータ処理では、まずアプリケーション、もしくはユーザがクエリ、およびストリームをシステムに登録する（１４０２）。ここで、アプリケーションプログラムは、図１の構成ではネットワークを介したクライアント計算機上にあるが、ストリームデータ処理システム１１５が稼動する同一計算機上で実行してももちろん差し支えない。また、クエリの登録とストリームの登録の順序は逆であっても差し支えない。ストリームの登録後、必要に応じてストリームのアーカイブ指定を行う（１４０２）。

システムへのクエリ登録、ストリーム登録、およびアーカイブ指定の後、ストリームデータソース（図１の１２２、１２３）からネットワーク経由でストリームデータ受け付けを開始する（１４０３）。ストリームデータを受け付けたストリームデータフローマネージャ１１９は、システムディクショナリ１１８中のストリーム管理テーブル（図５）、アーカイブ管理テーブル（図７）を参照し、必要に応じてストリームを複製し、アーカイブストア１２０、およびクエリ処理エンジン１１３に配信する。ストリームを配信されたアーカイブストア１２０、およびクエリ処理エンジン１１３では、それぞれアーカイブ処理、クエリ処理を実行する（１４０４）。クエリ処理の詳細に関しては後述する。アーカイブ処理、クエリ処理はストリームデータがシステムに到来し続け、かつクエリ登録、ストリーム登録、およびアーカイブ登録ステップ（１４０２）で指定した、それぞれの処理の開始時刻および終了時刻の間は継続的に実行する必要がある。ストリームデータ処理システムでは、クエリ登録、ストリーム定義、およびアーカイブ登録で指定したそれぞれの処理の開始時刻および終了時刻を図３のクエリ管理テーブル、図５のストリーム管理テーブル、そして図７のアーカイブ管理テーブルを参照し、少なくとも一つの処理を実行する必要があると判定した場合（ステップ１４０５でＹｅｓが選択された場合）には、処理を継続する。いずれの処理も継続の必要なしと判断した場合（ステップ１４０５でＮｏが選択された場合）には、データ処理を終了する（１４０６）。

次に、図１０を参照してストリームデータ処理システムにおけるクエリ処理方法を説明する。クエリの定義は図２のＱ１（２０１）であるとし、クエリ中に記述されるｐａｒｔｓストリームおよびｄｅｆｅｃｔ＿ｌｉｓｔストリームは図４のストリーム登録コマンド４０１、および４０２によりそれぞれ定義されている。それぞれのストリームデータに関するアーカイブ指定は図６の６０１、および６０２であるとする。また、説明時点の時刻は、日本標準時で２００４年９月９日午前１０時１０分２０秒であるとする。ストリームデータフローマネージャ１１９はシステムディクショナリ中のストリーム管理テーブル（図５）、およびアーカイブ管理テーブル（図７）をチェックする。ｐａｒｔｓストリーム８０１とｄｅｆｅｃｔ＿ｌｉｓｔストリーム８０２の両方がストリーム受付時間内、かつアーカイブ作成時間内であることから、該２つのストリームからデータを受け付け、データを複製して一方をアーカイブストア１２０に格納し、他の一方をクエリ処理エンジン１１３に配信する。クエリ処理エンジン１１３はクエリリポジトリ（図１の１１２）内にあるクエリ管理テーブル（図２）を参照し、クエリＱ１（図３）を実行すべき時間内であることをチェックした後、クエリ処理を継続実行する。

クエリＱ１はｐａｒｔｓストリームとｄｅｆｅｃｔ＿ｌｉｓｔストリームのジョイン処理であり、該処理の好適な実行方法はクエリ処理エンジン１１３内に示すように、２つの入力ストリームをジョインオペレータ８０７でジョインしその結果８１０をストリームとして出力することである。ところが、ストリームデータは従来のテーブルと異なり、一旦読み捨ててしまうと基本的には二度と読み直すことはできない。そのため、ジョイン処理のように同一データに対して複数回のアクセスが必要なデータに関しては、ストリームデータを一時的に保持するバッファを用いる必要がある。そのため、クエリ処理エンジン１１３内には、ｐａｒｔｓストリーム用の処理バッファ８０８とｄｅｆｅｃｔ＿ｌｉｓｔストリーム用の処理バッファ８０９が割り当てられている。このようなバッファを用いたストリームのジョイン処理に関しては、その方法がＳｔｒａｔｉｓ Ｖｉｇｌａｓ，Ｊｅｆｆｒｅｙ Ｆ． Ｎａｕｇｈｔｏｎ，Ｊｏｓｅｆ Ｂｕｒｇｅｒ著：“Ｍａｘｉｍｉｚｉｎｇ ｔｈｅ Ｏｕｔｐｕｔ Ｒａｔｅ ｏｆ Ｍｕｌｔｉ−Ｗａｙ Ｊｏｉｎ Ｑｕｅｒｉｅｓ ｏｖｅｒ Ｓｔｒｅａｍｉｎｇ Ｉｎｆｏｒｍａｔｉｏｎ Ｓｏｕｒｃｅｓ”，Ｉｎ Ｐｒｏｃ． ｏｆ ＶＬＤＢ ２００３，ｐｐ．２８５−２９６（非特許文献３）に開示されている。

ストリーム処理用のバッファ割り当ては、ストリームデータ処理システム内のメモリマネージャ（図１の１１７）が行う。システム全体のメモリ割り当て状況を管理する好適な実施の形態が図１１に示すメモリ管理テーブルである。メモリ管理テーブルのカラム９０１には、メモリを割り当てる対象を一意に識別するＩＤである「割当先オブジェクトＩＤ」が、カラム９０２には該オブジェクトのタイプを示す「割当先タイプ」が、カラム９０３には該オブジェクトが要求するメモリ量を表す「割当要求量」が、カラム９０４にはメモリ割り当ての優先度を示す「優先度」が、カラム９０５には該オブジェクトに実際に割り当てられたメモリ量を表す「割当済メモリ量」が、そしてカラム９０６には割り当てられたメモリのページのリストである「割当済ページリスト」が格納される。

図１１に示した例では、オブジェクトＩＤが１０１００１のエントリ（メモリ管理テーブルの第一番目のエントリ）がｐａｒｔｓ用処理バッファに、そしてオブジェクトＩＤが１０１００２のエントリ（メモリ管理テーブルの第二番目のエントリ）がｄｅｆｅｃｔ＿ｌｉｓｔ用バッファに割り当てられたメモリである。ｐａｒｔｓストリームについては、割当要求量１０ＭＢに対して要求通り１０ＭＢのメモリが割り当てられている。一方、ｄｅｆｅｃｔ＿ｌｉｓｔストリームについては５０ＭＢの要求に対して３０ＭＢのメモリしか割り当てられていない。このような場合、従来のストリームデータ処理システムでは処理に必要なストリームデータを保持することができず、クエリ処理を継続することが困難であった。そこで本実施例のストリームデータ処理システムでは、処理バッファに要求通りのメモリの割当が不可能な場合にも、アーカイブストア１２０内のアーカイブデータが利用できる場合には処理を継続する機構を有する。具体的には、メモリ割当が不足しているｄｅｆｅｃｔ＿ｌｉｓｔストリームのアーカイブ対象属性（図７の７０２）がクエリ処理で必要とするｄｅｆｅｃｔ＿ｌｉｓｔの属性であるｄｅｆｅｃｔ＿ｌｉｓｔ．ｉｄを含んでいるので、処理対象のクエリＱ１を、クエリエンジン内の処理バッファを対象としたクエリと、アーカイブストア１２０内のｄｅｆｅｃｔ＿ｌｉｓｔストリームのアーカイブであるｄｅｆｅｃｔ＿ｌｉｓｔ＿ａｒｃｈｉｖｅｄを対象としたクエリに書き換え、処理結果を統合することでクエリ処理の継続が可能となる。

図１２に好適なクエリ書き換えの例を示す。Ｑ１（１００１）がオリジナルのクエリ、そしてＱ１’（１００２）が書き換え後のクエリである。但し、本実施例においては、ｄｅｆｅｃｔ＿ｌｉｓｔで要求されている２週間分の処理バッファのうち、メモリ上に展開可能なバッファを３時間分とし、残りはアーカイブから読み出すこととしている。本実施例において、ｄｅｆｅｃｔ＿ｌｉｓｔ＿ａｒｃｈｉｖｅｄ中のｓｙｓｔｉｍｅ属性は、アーカイブ実行時のタイムスタンプを、そしてｃｕｒｔｉｍｅ（）関数はクエリ実行時点での時刻を取得する関数を表す。

本実施例では、クエリがアーカイブを用いて処理できるか否かの判定が非常に単純な場合を示したが、例えばＪｅｆｆｒｅｙ Ｄ．Ｕｌｌｍａｎ著，“ＰＲＩＮＣＩＰＬＥＳ ＯＦ ＤＡＴＡＢＡＳＥ ＡＮＤ ＫＮＯＷＬＥＤＧＥ−ＢＡＳＥ ＳＹＳＴＥＭＳ”，ＶＯＬＵＭＥ ＩＩ，ＣＯＭＰＵＴＥＲ ＳＣＩＥＮＣＥ ＰＲＥＳＳ，ＩＳＢＮ ０−７１６７−８１６２−Ｘ，第１４章“Ｏｐｔｉｍｉｚａｔｉｏｎ ｆｏｒ Ｃｏｎｊｕｎｃｔｉｖｅ Ｑｕｅｒｉｅｓ”（非特許文献４）に示されている、Ｑｕｅｒｙ Ｅｑｕｉｖａｌｅｎｃｅ，Ｑｕｅｒｙ Ｃｏｎｔａｉｎｍｅｎｔと呼ばれる方式を用いることにより、一般的な場合についても該判定は可能である。

このように、リアルタイムデータ処理とアーカイブデータ処理の両方をシームレスに処理するクエリ処理方式を用いることにより、従来は現時点でのクエリ処理の結果しか得られなかったストリームデータ処理システムを、アーカイブデータが利用できる範囲であれば、任意の時点で任意の大きさのウィンドウ指定のクエリが処理できるように拡張することができる。

図１３はリアルタイムデータ処理とアーカイブデータ処理の両方をシームレスに処理する本実施例の特徴的なクエリ処理方式（以下、シームレスクエリ処理方式と呼ぶ）の手順を示したフローチャートである。まず、処理対象のクエリが必要とするバッファが確保されていて、かつ処理に必要なデータが該バッファ上に格納されているかどうかを判定する（ステップ１１０２）。本条件が満たされている場合（ステップ１１０２がＹｅｓの場合）には、バッファを用いたクエリ処理が可能であるので、ステップ１１０８でクエリ処理を継続実行する。前記条件が満たされない場合（ステップ１１０２がＮｏの場合）は、クエリ処理継続に必要なデータがバッファ上にないので、該クエリ処理継続に必要なデータがアーカイブ中にあるか否かを判定する（ステップ１１０３）。アーカイブ中にも必要なデータが存在しない場合（ステップ１１０３がＮｏの場合）には、クエリ処理は継続不可能であるため、クエリ処理を終了する（ステップ１１０９）。クエリ処理に必要なデータがアーカイブ中に存在する場合（ステップ１１０３がＹｅｓの場合）には、該アーカイブデータがストリームデータ処理システムの管理下にあるか否かをチェックする（ステップ１１０４）。

管理下にある場合（ステップ１１０４がＹｅｓの場合）には、図１２を用いて説明したようにクエリを書き換え（ステップ１１０７）、クエリ処理を継続実行する（ステップ１１０８）。アーカイブデータが処理を行うストリームデータ処理システムの管理下にない場合（ステップ１１０４がＮｏの場合）、該データを管理する外部データ管理システムから、クエリ処理に必要なデータを取得可能か否かチェックする（ステップ１１０５）。取得不可の場合（ステップ１１０５がＮｏの場合）、クエリ処理は継続不可能であるため、クエリ処理を終了する（ステップ１１０９）。取得が可能の場合（ステップ１１０５がＹｅｓの場合）、該外部データ管理システムから処理に必要なデータを取得し（ステップ１１０６）、クエリを書き換えて（ステップ１１０７）、クエリ処理を継続実行する（１１０８）。アーカイブを管理する外部データ管理システムは、（株）日立製作所の登録商標、スケーラブルデーターベースシステムＨｉＲＤＢなどのＤＢＭＳで差し支えなく、その場合には該ＤＢＭＳに対してＳＱＬでクエリを発行し、取得したデータをアーカイブストアに格納した後に、該アーカイブストアを参照するようにオリジナルのクエリを書き換えることでクエリ処理を継続実行できる。

これまでは、単体のストリームデータ処理システムの動作を中心に実施例を説明してきた。処理対象のストリームの数、およびストリームデータの到来レートが増大した場合には、単体のシステムでは処理能力の限界が必ず訪れる。そこで、処理対象のストリーム数の増加、ストリームデータ到来レートの増大、およびストリームデータ処理の複雑度の増加等に伴って、必要となる処理量がストリームデータ処理システムの能力を上回った場合に、複数のストリームデータ処理システムを連携させることが有効となる。図１５、図１６、及び図１７は複数のストリームデータ処理システムが連携する構成へと構成変更を行う本発明の別の実施例（第２の実施例）を示す。

まず図１５は第２の実施例にてシステム１２０１が単体で所定のストリームデータ処理を行っている状態を示す。ストリームデータ処理システム１２０１に対しストリーム１（１２０６）、ストリーム２（１２０７）、およびストリーム３（１２０８）の３つのストリームが入力されている。先の実施例と同様に、ストリームはストリームデータフローマネージャ１２０２で受け付けられ、必要に応じてアーカイブストア１２０４に格納される。同時に、ストリームはクエリ処理エンジン１２０３に配信され、クエリ処理エンジン内でクエリ処理が実行される。本実施例ではＱＰ１（１２１１）、ＱＰ２（１２１２）、ＱＰ３（１２１３）、およびＱＰ４（１２１４）の４つのクエリ処理が実行されている。

各ＱＰは図１０の８０７のジョインオペレータのようなクエリの構成要素であるクエリオペレータでも、またＱＰそれぞれが完結する一つのクエリ（例えば、ＣＱＬで記述された一つのクエリ）であっても差し支えない。本実施例では、クエリ処理終了後、ストリームデータ処理システム１２０１は出力ストリーム１（１２０９）、および出力ストリーム２（１２１０）の２つのストリームを出力する。

このようなストリームデータ処理を行っているストリームデータ処理システム１２０１が稼動する処理ノードに対して、その処理負荷が高くなり、到来するストリームデータの処理が継続できなくなるおそれは無いかを監視し、必要な場合に、ストリームデータ処理システムが稼動する複数の処理ノードが連携して上記ストリームデータ処理を実行する構成に構成変更するためのノード構成最適化マネージャ１３０７（図１６）を配備したのが本実施例の特徴である。図１５ではノード構成最適化マネージャ１３０７の制御・監視下の複数の処理ノードの内の一つのみを示し、他は図示を省略している。また、ノード構成最適化マネージャ１３０７は専用の計算機システム１３１８の上で稼動させても良いが、これら処理ノード計算機のいずれかの上で稼動させても良い。

図１７はノード構成最適化マネージャ１３０７で実行するノード構成最適化処理のフローを示す。最初に現在負荷が予め与えられた閾値を超えているノードが存在するか否かをチェックする（１７０２）。該閾値の好適な例としては、オペレーティングシステムのｓａｒコマンドなどで取得可能なＣＰＵ負荷、システムモニタリングアプリケーションによって取得可能なシステム負荷などを用いることができる。負荷が閾値を超えているノードが存在しない場合（１７０２でＮｏが選択された場合）には、ノード構成最適化処理はノードの再構成を行わずその処理を終了する（１７０８）。負荷が閾値を超えているノードが存在する場合（１７０２でＹｅｓが選択された場合）、ストリームデータ処理を実行可能な余剰ノードが存在するか否かをチェックする（１７０３）。あるノードが余剰ノードか否かの判定方法の好適な実施例として、該ノードの負荷がある閾値以下であるか否かをチェックし、該閾値よりも負荷が小さいノードを余剰ノードとする方法を挙げることができる。

余剰ノードが存在しない場合（１７０３でＮｏが選択された場合）、クエリ処理を他ノードに委譲することができないので、ノード構成最適化処理は中止となる（１７０５）。余剰ノードが存在する場合（１７０３でＹｅｓが選択された場合）には、余剰ノードを含めた複数ノードでストリームデータ処理を実行するための、コスト計算に基づくノード決定処理（１７０４、以下単にノード決定処理と呼ぶ）を行う。該ノード決定処理に関しては後述する。ノード決定処理が終了したときには、クエリ処理のノードへの割り当てが決定している。例えば、図１６は図１５で単体のストリームデータ処理システム１２０１で処理していたストリームデータ処理を、ストリームデータ処理システム１（１３０６）、ストリームデータ処理システム２（１３０７）、およびストリームデータ処理システム３（１３０８）の３つのストリームデータ処理システムの連携によって処理する構成となっており、クエリ処理ＱＰ１はストリームデータ処理システム１に、クエリ処理ＱＰ２はストリームデータ処理システム２に、そしてクエリ処理ＱＰ３およびＱＰ４はストリームデータ処理システム３に割り当てられている。次に、ノードへの処理割り当て変更に伴う、ストリーム処理入出力方向変更処理（１７０６）を実行する。

本処理では、ノード決定処理後の複数のストリームデータ処理システム間で実行するクエリ処理を、単体のクエリ処理エンジン内で行う場合の処理順序と合致させるようにストリーム通信の経路を設定し、必要に応じてストリームの複製処理を行う。好適な実施例を図１５および図１６を用いて説明する。図１５のクエリ処理エンジン（１２０３）内に示されているクエリ処理ＱＰ１〜ＱＰ４では、ＱＰ１（１２１１）の出力はシステムの出力ストリーム１（１２０９）となると共に、ＱＰ２（１２１２）の入力となっている。また、ＱＰ４（１２１４）はＱＰ２、およびＱＰ３（１２１３）の出力を入力とし、その出力はシステムの出力ストリーム２（１２１０）となっている。そこで、図１６に示すクエリ処理では、ストリームデータ処理システム１（１３０６）は、その内部で実行するクエリ処理ＱＰ１の出力を、システムの出力である出力ストリーム１（１３０４）として出力するように通信路を設定すると共に、ストリームデータ処理システム２（１３０７）で実行するクエリ処理ＱＰ２の入力とするために、複製したストリーム１３０９をストリームデータ処理システム２に出力するように通信路を設定する必要がある。同様に、ストリームデータ処理システム２は、その内部で実行するクエリ処理ＱＰ２の出力ストリーム（１３１０）を、ストリームデータ処理システム３（１３０８）に出力するように通信路を設定し、最後にストリームデータ処理システム３はその処理結果をシステムの出力である出力ストリーム２（１３０５）として出力するように通信路を設定する。

ストリーム入出力方向変更処理（１７０６）が終了した後、アーカイブストア、リレーショナルストアのデータ配置処理（１７０７）を行う。本データ配置処理とは、それぞれのクエリ処理が必要とするアーカイブストア中のデータ、リレーショナルストア中のデータをそれぞれのクエリ処理を実行するストリームデータ処理システムに移動する処理のことを表す。図１６の例では、クエリ処理ＱＰ１が必要とするアーカイブデータ、リレーション（表）はそれぞれ、ストリームデータ処理システム１（１３０６）の管理下にあるアーカイブストア（１３１１）、およびリレーショナルストア（１３１２）に配置される。同様に、クエリ処理ＱＰ２が必要とするアーカイブデータ、リレーションはそれぞれ、アーカイブストア（１３１３）、およびリレーショナルストア（１３１４）に、クエリ処理ＱＰ３、およびＱ４が必要とするアーカイブデータ、リレーションはそれぞれ、アーカイブストア（１３１５）、およびリレーショナルストア（１３１６）に配置される。

本データ配置処理（１７０７）を終了して、ノード構成最適化処理は終了となる（１７０８）。本ノード構成最適化処理を実行するソフトウェアモジュールであるノード構成最適化マネージャ（１３１７）は、処理ノード計算機にネットワークで接続された専用の計算機システム（１３１８）上で稼動させてもよいし、もしくは処理ノードのいずれかの計算機上で稼動させるのでも差し支えない。

最後に、コスト計算に基づくノード決定処理（１７０４、以下単にノード決定処理と呼ぶ）の説明を行う。ノード決定処理では、利用可能な計算機ノード、入力となるストリーム、必要なクエリ処理を入力として、計算機ノードへのクエリ処理の割り当てを行う。割り当て方法の好適な実施方法を説明する。最初に、処理の依存性を考慮してクエリ処理の順序付けを行う。図１５に示した例では、クエリ処理ＱＰ２はＱＰ１に依存しているので、ＱＰ１⇒ＱＰ２の順序をつけることができる。また、ＱＰ４はＱＰ３、およびＱＰ２に依存しているので、ＱＰ３⇒ＱＰ４，ＱＰ２⇒ＱＰ４の順序付けが可能である。よって、全体ではＱＰ１⇒ＱＰ２⇒ＱＰ４，ＱＰ３⇒ＱＰ４の２つの順序関係を得る。次のステップでは、順序付けを行ったクエリ処理を、処理コストを計算しながらノードに割り付けていく。この時、ストリームデータ処理のクエリの処理コストは、ストリームの入力レートに基づいて計算するのが好ましい。

ストリームデータの入力レートに基づいたコスト計算の方法は、Ｓｔｒａｔｉｓ Ｖｉｇｌａｓ，Ｊｅｆｆｒｅｙ Ｆ． Ｎａｕｇｈｔｏｎ著：“Ｒａｔｅ−ｂａｓｅｄ ｑｕｅｒｙ ｏｐｔｉｍｉｚａｔｉｏｎ ｆｏｒ ｓｔｒｅａｍｉｎｇ ｉｎｆｏｒｍａｔｉｏｎ ｓｏｕｒｃｅｓ”，Ｉｎ Ｐｒｏｃ． ｏｆ ＳＩＧＭＯＤ Ｃｏｎｆｅｒｅｎｃｅ ２００２，ｐｐ． ３７−４８ （非特許文献５）に開示されており、本計算方法を用いることにより、あるノードにクエリ処理を割り付けた場合の処理コストを計算することができる。先のＱＰ１とＱＰ２のように、順番に処理する必要のあるクエリ処理を異なるノードに割り付けた場合には、各ノードでの処理コストに、ＱＰ１とＱＰ２を割り付けたノード間の通信コストを加算する。このように、ノードへのクエリ処理の割り当ての組合せを作成し、クエリ処理コストと通信処理コストの総和を計算し、その総和が最小となる、クエリ処理のノード割り当て方法を選択すればよい。但し、処理ノードの数が多い、クエリ処理の数が多いなどの理由で、全ての組合せを考慮してコストを計算することが困難な場合には、まず個々のクエリ処理を別々のノードに割り当て、コスト計算が可能な範囲内で、連続する２つの処理ノードを同一ノードに割り付けた方が総処理コストが少なくなる場合には該２つの処理ノードを結合する等の簡易アルゴリズムを用いるのでも差し支えない。

本発明を用いることにより、高信頼・高可用のリアルタイムデータ処理が可能なストリームデータ処理システムが実現できる。

本発明の実施例のストリームデータ処理システムおよび関連システムの構成を示すブロック図である。 上記実施例のクエリ登録コマンドおよびクエリ削除コマンドを示す概念図である。 上記実施例におけるクエリ管理テーブルの構成を示すデータ構成図である。 上記実施例におけるストリーム定義コマンドを示す概念図である。 上記実施例におけるストリーム管理テーブルの構成を示すデータ構成図である。 上記実施例におけるアーカイブ指定コマンドを示す概念図である。 上記実施例におけるアーカイブ管理テーブルの構成を示すデータ構成図である。 上記実施例のテーブル（表）を対象とした場合のクエリの例を示す図である。 上記実施例におけるデータ処理手順を示すフローチャートである。 上記実施例におけるクエリ処理機構を示すブロック図である。 上記実施例におけるメモリ管理テーブルの構成を示すデータ構成図である。 上記実施例におけるクエリ書き換え例を示す概念図である。 上記実施例におけるクエリ処理方式手順を示すフローチャートである。 Ｓｔａｎｆｏｒｄ大学ＳＴＲＥＡＭシステムにおけるクエリ記述例。 本発明の別の実施例における単体のストリームデータ処理システムでのクエリ処理を示すブロック図である。 上記実施例におけるノード構成最適化後の分散ストリームデータ処理の構成を示すブロック図である。 上記実施例におけるノード構成最適化手順を示すフローチャート。

符号の説明

８０７…クエリ処理オペレータ
１２１１、１２１２、１２１３、１２１４…クエリ処理
１３１１、１３１３、１３１５…アーカイブストア
１３１２、１３１４、１３１６…リレーショナルストア。

Claims (7)

1. データ処理装置と、前記データ処理装置と接続する不揮発性記憶媒体と、を備え、ストリームデータに対し所望のデータ処理を実行するためのクエリを予め前記データ処理装置に登録しておき、前記データ処理装置が、少なくとも１つのストリームデータソースから受け付けたストリームデータに、前記登録したクエリ処理を実行するストリームデータ処理システム、のクエリ処理方法であり、
   前記データ処理装置によって、
   ストリームデータを受信し、
   前記ストリームデータの一部を、前記データ処理装置内のバッファに格納し、
   前記ストリームデータの一部を、前記不揮発性記憶媒体にアーカイブし、
   予め登録した第１のクエリに基づき前記バッファを用いるクエリ処理を行ない、
   前記クエリ処理において、前記バッファに前記第１のクエリの実行対象のストリームデータの少なくとも一部が格納されておらず、前記第１のクエリの実行対象であって前記バッファに格納されていないストリームデータが前記不揮発性記憶媒体に前記アーカイブされている場合に、前記不揮発性記憶媒体の前記アーカイブされたストリームデータを用いて前記クエリ処理を実行する、ことを特徴とする、ストリームデータ処理システムのクエリ処理方法。
2. 前記アーカイブ実行時に、前記データ処理装置によって、アーカイブ対象データにサンプリングを実行することを特徴とする請求項１記載のストリームデータ処理システムのクエリ処理方法。
3. 前記アーカイブ実行時に、前記データ処理装置によって、アーカイブ対象データに暗号化を実行することを特徴とする請求項１記載のストリームデータ処理システムのクエリ処理方法。
4. 前記アーカイブ実行時に、前記データ処理装置によって、アーカイブを外部のデータ管理システムと連携して実行することを特徴とする請求項１記載のストリームデータ処理システムのクエリ処理方法。
5. 前記データ処理装置によって、前記不揮発性記憶媒体の前記アーカイブされたデータを用いて前記クエリ処理を行う場合に、前記第１のクエリから前記不揮発性記録媒体のアーカイブデータを用いたデータ処理を示す第２のクエリに書き換え、前記書き換えた該第２のクエリを実行することにより前記不揮発性記憶媒体のアーカイブデータを用いたクエリ処理を行なう、
   こと、を特徴とする請求項１記載のストリームデータ処理システムのクエリ処理方法。
6. 前記データ処理装置によって、前記クエリの登録時にクエリの実行開始時刻及び実行終了時刻を指定し、両時刻の間のみ該クエリを実行することを特徴とする請求項１記載のストリームデータ処理システムのクエリ処理方法。
7. 前記アーカイブの動作は、予め指定されたアーカイブ対象のストリームデータについて、指定された開始時刻と終了時刻の間の期間にのみ行なわれることを特徴とする請求項１のストリームデータ処理方法。

Images