図面 (/)

技術 連続データストリームに対する継続時間可変ウィンドウ

出願人 オラクル・インターナショナル・コーポレイション
発明者 ビシュノイ,サンディープスリニバサン,アナンド
出願日 2014年1月9日 (6年10ヶ月経過) 出願番号 2015-552781
公開日 2016年5月12日 (4年6ヶ月経過) 公開番号 2016-513300
状態 特許登録済
技術分野 検索装置 バス制御
主要キーワード アラームタイマ 連続イベント 順序条件 アセンブリファイル イベント値 一次プロセッサ イベントストリーム 入力サブシステム
関連する未来課題
重要な関連分野

この項目の情報は公開日時点(2016年5月12日)のものです。
また、この項目は機械的に抽出しているため、正しく解析できていない場合があります

図面 (10)

課題・解決手段

データのストリームを処理するための、改善された技術が提供される。1つのイベント時間ベースウィンドウ内に留まる資格がある継続時間は、同一のイベントストリームを介して受信した異なるイベントごとに異なり得る。ある実施形態において、1つの入力イベントが時間ベースのウィンドウ内にある継続時間は、このイベントの1つ以上の属性の1つ以上の値の関数である。異なるイベントは異なる1つ以上の属性値を有することがあるので、異なるイベントがそのイベントストリームのための時間ベースのウィンドウ内にある時間の量は異なることがある。1つのイベントが時間ベースのウィンドウ内にある時間の量は、このイベントの1つ以上の属性によって制御することができる。

概要

背景

背景
開示されている実施形態は、概してデータ処理システムに関し、より具体的には継続時間可変ウィンドウを用いて連続イベントストリームを処理するための技術に関する。

従来のデータベースシステムにおいて、データは、通常はテーブルの形態で1つ以上のデータベースに格納される。格納されたデータはその後、SQL等のデータ管理言語を用いてクエリされ操作される。たとえば、SQLクエリは、データベースに格納されているデータのうちの関連データを識別するために定義し実行することができる。したがって、SQLクエリは、データベースに格納されている有限集合のデータに対して実行される。さらに、SQLクエリが実行されるとき、SQLは有限データ集合に対して一度実行されて有限の静的結果をもたらす。このように、データベースは、格納されている有限のデータ集合に対してクエリが実行されるよう最適に作成されている。

しかしながら、数多くの現代アプリケーションおよびシステムは、データを、有限のデータ集合ではなく連続データまたはイベントストリームの形態で生成する。このようなアプリケーションの例は、センサデータアプリケーション、財務表示機ネットワークパフォーマンス測定ツール(たとえば、ネットワークモニタリングおよびトラフィック管理アプリケーション)、クリックストリーム分析ツール自動車交通モニタリング等を含むが、これらに限定されない。たとえば、温度センサを、温度測定値発信するように構成することができる。このようなアプリケーションから、データストリームを処理することが可能な新たな種類のアプリケーションの必要性が生じた。

イベントストリームに基づくこれらの種類のアプリケーションの場合のデータの管理および処理は、時間を強く重視してデータ管理およびクエリ機能を構築することを含む。連続する無限のデータ集合に対する長時間のクエリ実行を含む、異なる種類のクエリ機構が必要である。現在イベントストリーム処理に適した製品一式を提供している販売業者はあるが、これら製品が提供するものは依然として、現代のイベント処理ニーズ対処するのに必要な処理の柔軟性に欠けている。

概要

データのストリームを処理するための、改善された技術が提供される。1つのイベント時間ベースのウィンドウ内に留まる資格がある継続時間は、同一のイベントストリームを介して受信した異なるイベントごとに異なり得る。ある実施形態において、1つの入力イベントが時間ベースのウィンドウ内にある継続時間は、このイベントの1つ以上の属性の1つ以上の値の関数である。異なるイベントは異なる1つ以上の属性値を有することがあるので、異なるイベントがそのイベントストリームのための時間ベースのウィンドウ内にある時間の量は異なることがある。1つのイベントが時間ベースのウィンドウ内にある時間の量は、このイベントの1つ以上の属性によって制御することができる。

目的

現在イベントストリーム処理に適した製品一式を提供している販売業者はあるが、これら製品が提供する

効果

実績

技術文献被引用数
0件
牽制数
1件

この技術が所属する分野

ライセンス契約や譲渡などの可能性がある特許掲載中! 開放特許随時追加・更新中 詳しくはこちら

請求項1

方法であって、イベントストリームを介して受信した第1のイベントの第1の継続時間計算装置によって決定することを含み、前記第1の継続時間は、前記イベントストリームに対して指定された時間ベースウィンドウ内に前記第1のイベントが留まる資格がある継続時間を示し、前記イベントストリームを介して受信した第2のイベントの第2の継続時間を前記計算装置によって決定することを含み、前記第2の継続時間は、前記時間ベースのウィンドウ内に前記第2のイベントが留まる資格がある継続時間を示し、前記第2の継続時間は前記第1の継続時間と異なる、方法。

請求項2

前記第1の時間イベントが前記時間ベースのウィンドウ内に前記第1の継続時間留まった後に、前記第1のイベントを前記時間ベースのウィンドウから前記計算装置によって除去することと、前記第2の時間イベントが前記時間ベースのウィンドウ内に前記第2の継続時間留まった後に、前記第2のイベントを前記時間ベースのウィンドウから前記計算装置によって除去することとをさらに含む、請求項1に記載の方法。

請求項3

前記第1のイベントは関連付けられた第1の時間を有し、前記第2のイベントは関連付けられた第2の時間を有し、前記第1の時間は前記第2の時間と同一である、請求項1または2に記載の方法。

請求項4

前記第1のイベントは関連付けられた第1の時間を有し、前記第2のイベントは関連付けられた第2の時間を有し、前記第1の時間は前記第2の時間と異なる、請求項1または2に記載の方法。

請求項5

前記第1の継続時間を決定することは、前記第1のイベントの1つ以上の属性の1つ以上の値に基づいて前記第1の継続時間を計算することを含み、前記第2の継続時間を決定することは、前記第2のイベントの1つ以上の属性の1つ以上の値に基づいて前記第2の継続時間を計算することを含む、請求項1〜4のいずれか一項に記載の方法。

請求項6

前記第1のイベントの第1の属性の値に基づいて前記第1のイベントのための第1の区画を決定することと、前記第2のイベントの第1の属性の値に基づいて前記第2のイベントが前記第1の区画に属すると決定することとをさらに含み、前記時間ベースのウィンドウは前記第1の区画のためのものである、請求項1〜5のいずれか一項に記載の方法。

請求項7

前記第1のイベントに関連付けられた第1の時間と前記第1の継続時間とに基づいて前記第1のイベントの第1の満了時間を前記計算装置によって決定することと、前記第2のイベントに関連付けられた第2の時間と前記第2の継続時間とに基づいて前記第2のイベントの第2の満了時間を前記計算装置によって決定することと、前記第1の満了時間の到来時または到来後に前記時間ベースのウィンドウから前記第1のイベントを除去することと、前記第2の満了時間の到来時または到来後に前記時間ベースのウィンドウから前記第2のイベントを除去することとをさらに含む、請求項1〜6のいずれか一項に記載の方法。

請求項8

計算装置であって、メモリと、一組の処理部とを備え、前記一組の処理部のうちの1つ以上の処理部は、イベントストリームを介して受信した第1のイベントの第1の継続時間を決定するように適合され、前記第1の継続時間は、前記イベントストリームに対して指定された時間ベースのウィンドウ内に前記第1のイベントが留まる資格がある継続時間を示し、前記イベントストリームを介して受信した第2のイベントの第2の継続時間を決定するように適合され、前記第2の継続時間は、前記時間ベースのウィンドウ内に前記第2のイベントが留まる資格がある継続時間を示し、前記第2の継続時間は前記第1の継続時間と異なる、計算装置。

請求項9

前記一組の処理部のうちの1つ以上の処理部は、前記第1の時間イベントが前記時間ベースのウィンドウ内に前記第1の継続時間留まった後に、前記第1のイベントを前記時間ベースのウィンドウから除去するように適合され、前記第2の時間イベントが前記時間ベースのウィンドウ内に前記第2の継続時間留まった後に、前記第2のイベントを前記時間ベースのウィンドウから除去するように適合される、請求項8に記載の計算装置。

請求項10

前記第1のイベントは関連付けられた第1の時間を有し、前記第2のイベントは関連付けられた第2の時間を有し、前記第1の時間は前記第2の時間と同一である、請求項8または9に記載の計算装置。

請求項11

前記第1のイベントは関連付けられた第1の時間を有し、前記第2のイベントは関連付けられた第2の時間を有し、前記第1の時間は前記第2の時間と異なる、請求項8または9に記載の計算装置。

請求項12

前記一組の処理部のうちの1つ以上の処理部は、前記第1のイベントの1つ以上の属性の1つ以上の値に基づいて前記第1の継続時間を決定するように適合され、前記第2のイベントの1つ以上の属性の1つ以上の値に基づいて前記第2の継続時間を決定するように適合される、請求項8〜11のいずれか一項に記載の計算装置。

請求項13

前記一組の処理部のうちの1つ以上の処理部は、前記第1のイベントの第1の属性の値に基づいて前記第1のイベントのための第1の区画を決定するように適合され、前記第2のイベントの第1の属性の値に基づいて前記第2のイベントが前記第1の区画に属すると決定するように適合され、前記時間ベースのウィンドウは前記第1の区画のためのものである、請求項8〜12のいずれか一項に記載の計算装置。

請求項14

前記一組の処理部のうちの1つ以上の処理部は、前記第1のイベントに関連付けられた第1の時間と前記第1の継続時間とに基づいて前記第1のイベントの第1の満了時間を決定するように適合され、前記第2のイベントに関連付けられた第2の時間と前記第2の継続時間とに基づいて前記第2のイベントの第2の満了時間を決定するように適合され、前記第1の満了時間の到来時または到来後に前記時間ベースのウィンドウから前記第1のイベントを除去するように適合され、前記第2の満了時間の到来時または到来後に前記時間ベースのウィンドウから前記第2のイベントを除去するように適合される、請求項8〜13のいずれか一項に記載の計算装置。

請求項15

1つ以上の処理部によって実行可能な複数の命令を格納するコンピュータ読取可能なメモリであって、前記複数の命令は、前記1つ以上の処理部のうちの少なくとも1つの処理部に、イベントストリームを介して受信した第1のイベントの第1の継続時間を決定させる命令を含み、前記第1の継続時間は、前記イベントストリームに対して指定された時間ベースのウィンドウ内に前記第1のイベントが留まる資格がある継続時間を示し、前記1つ以上の処理部のうちの少なくとも1つの処理部に、前記イベントストリームを介して受信した第2のイベントの第2の継続時間を決定させる命令を含み、前記第2の継続時間は、前記時間ベースのウィンドウ内に前記第2のイベントが留まる資格がある継続時間を示し、前記第2の継続時間は前記第1の継続時間と異なる、コンピュータ読取可能なメモリ。

請求項16

前記複数の命令は、前記1つ以上の処理部のうちの少なくとも1つの処理部に、前記第1の時間イベントが前記時間ベースのウィンドウ内に前記第1の継続時間留まった後に、前記第1のイベントを前記時間ベースのウィンドウから除去させる命令と、前記1つ以上の処理部のうちの少なくとも1つの処理部に、前記第2の時間イベントが前記時間ベースのウィンドウ内に前記第2の継続時間留まった後に、前記第2のイベントを前記時間ベースのウィンドウから除去させる命令とを含む、請求項15に記載のコンピュータ読取可能なメモリ。

請求項17

前記第1のイベントは関連付けられた第1の時間を有し、前記第2のイベントは関連付けられた第2の時間を有し、前記第1の時間は前記第2の時間と同一である、請求項15または16に記載のコンピュータ読取可能なメモリ。

請求項18

前記第1のイベントは関連付けられた第1の時間を有し、前記第2のイベントは関連付けられた第2の時間を有し、前記第1の時間は前記第2の時間と異なる、請求項15または16に記載のコンピュータ読取可能なメモリ。

請求項19

前記複数の命令は、前記1つ以上の処理部のうちの少なくとも1つの処理部に、前記第1のイベントの1つ以上の属性の1つ以上の値に基づいて前記第1の継続時間を決定させる命令と、前記1つ以上の処理部のうちの少なくとも1つの処理部に、前記第2のイベントの1つ以上の属性の1つ以上の値に基づいて前記第2の継続時間を決定させる命令とを含む、請求項15〜18のいずれか一項に記載のコンピュータ読取可能なメモリ。

請求項20

前記複数の命令は、前記1つ以上の処理部のうちの少なくとも1つの処理部に、前記第1のイベントの第1の属性の値に基づいて前記第1のイベントのための第1の区画を決定させる命令と、前記1つ以上の処理部のうちの少なくとも1つの処理部に、前記第2のイベントの第1の属性の値に基づいて前記第2のイベントが前記第1の区画に属すると決定させる命令とを含み、前記時間ベースのウィンドウは前記第1の区画のためのものである、請求項15〜19のいずれか一項に記載のコンピュータ読取可能なメモリ。

請求項21

前記複数の命令は、前記1つ以上の処理部のうちの少なくとも1つの処理部に、前記第1のイベントに関連付けられた第1の時間と前記第1の継続時間とに基づいて前記第1のイベントの第1の満了時間を決定させる命令と、前記1つ以上の処理部のうちの少なくとも1つの処理部に、前記第2のイベントに関連付けられた第2の時間と前記第2の継続時間とに基づいて前記第2のイベントの第2の満了時間を決定させる命令と、前記1つ以上の処理部のうちの少なくとも1つの処理部に、前記第1の満了時間の到来時または到来後に前記時間ベースのウィンドウから前記第1のイベントを除去させる命令と、前記1つ以上の処理部のうちの少なくとも1つの処理部に、前記第2の満了時間の到来時または到来後に前記時間ベースのウィンドウから前記第2のイベントを除去させる命令とを含む、請求項15〜20のいずれか一項に記載のコンピュータ読取可能なメモリ。

請求項22

ステムであって、イベントストリームを介して受信した第1のイベントの第1の継続時間を決定するための手段を備え、前記第1の継続時間は、前記イベントストリームに対して指定された時間ベースのウィンドウ内に前記第1のイベントが留まる資格がある継続時間を示し、前記イベントストリームを介して受信した第2のイベントの第2の継続時間を決定するための手段を備え、前記第2の継続時間は、前記時間ベースのウィンドウ内に前記第2のイベントが留まる資格がある継続時間を示し、前記第2の継続時間は前記第1の継続時間と異なる、システム。

請求項23

前記第1の時間イベントが前記時間ベースのウィンドウ内に前記第1の継続時間留まった後に、前記第1のイベントを前記時間ベースのウィンドウから除去するための手段と、前記第2の時間イベントが前記時間ベースのウィンドウ内に前記第2の継続時間留まった後に、前記第2のイベントを前記時間ベースのウィンドウから除去するための手段とをさらに備える、請求項22に記載のシステム。

請求項24

前記第1のイベントは関連付けられた第1の時間を有し、前記第2のイベントは関連付けられた第2の時間を有し、前記第1の時間は前記第2の時間と同一である、請求項22または23に記載のシステム。

請求項25

前記第1のイベントは関連付けられた第1の時間を有し、前記第2のイベントは関連付けられた第2の時間を有し、前記第1の時間は前記第2の時間と異なる、請求項22または23に記載のシステム。

請求項26

前記第1の継続時間を決定するための手段は、前記第1のイベントの1つ以上の属性の1つ以上の値に基づいて前記第1の継続時間を計算するための手段を含み、前記第2の継続時間を決定するための手段は、前記第2のイベントの1つ以上の属性の1つ以上の値に基づいて前記第2の継続時間を計算するための手段を含む、請求項22〜25のいずれか一項に記載のシステム。

請求項27

前記第1のイベントの第1の属性の値に基づいて前記第1のイベントのための第1の区画を決定するための手段と、前記第2のイベントの第1の属性の値に基づいて前記第2のイベントが前記第1の区画に属すると決定するための手段とをさらに備え、前記時間ベースのウィンドウは前記第1の区画のためのものである、請求項22〜26のいずれか一項に記載のシステム。

請求項28

前記第1のイベントに関連付けられた第1の時間と前記第1の継続時間とに基づいて前記第1のイベントの第1の満了時間を決定するための手段と、前記第2のイベントに関連付けられた第2の時間と前記第2の継続時間とに基づいて前記第2のイベントの第2の満了時間を決定するための手段と、前記第1の満了時間の到来時または到来後に前記時間ベースのウィンドウから前記第1のイベントを除去するための手段と、前記第2の満了時間の到来時または到来後に前記時間ベースのウィンドウから前記第2のイベントを除去するための手段とをさらに備える、請求項22〜27のいずれか一項に記載のシステム。

技術分野

0001

関連出願の相互参照
本願は、2013年1月15日に出願され「VARIABLE DURATION WINDOWS ON CONTINUOUSDATA STREAMS連続データストリームに対する継続時間可変ウィンドウ)」と題された米国仮出願第61/752,850号に基づく利益および優先権を主張する。本願はまた、米国仮出願第61/752,850号に基づく優先権を主張する2013年3月15日に出願され「VARIABLE DURATION WINDOWS ON CONTINUOUS DATA STREAMS」と題された米国非仮出願第13/838,259号に基づく利益および優先権を主張する。出願第61/752,850号および第13/838,259号の内容全体をすべての目的のために本明細書に引用により援用する。

背景技術

0002

背景
開示されている実施形態は、概してデータ処理システムに関し、より具体的には継続時間可変ウィンドウを用いて連続イベントストリームを処理するための技術に関する。

0003

従来のデータベースシステムにおいて、データは、通常はテーブルの形態で1つ以上のデータベースに格納される。格納されたデータはその後、SQL等のデータ管理言語を用いてクエリされ操作される。たとえば、SQLクエリは、データベースに格納されているデータのうちの関連データを識別するために定義し実行することができる。したがって、SQLクエリは、データベースに格納されている有限集合のデータに対して実行される。さらに、SQLクエリが実行されるとき、SQLは有限データ集合に対して一度実行されて有限の静的結果をもたらす。このように、データベースは、格納されている有限のデータ集合に対してクエリが実行されるよう最適に作成されている。

0004

しかしながら、数多くの現代アプリケーションおよびシステムは、データを、有限のデータ集合ではなく連続データまたはイベントストリームの形態で生成する。このようなアプリケーションの例は、センサデータアプリケーション、財務表示機ネットワークパフォーマンス測定ツール(たとえば、ネットワークモニタリングおよびトラフィック管理アプリケーション)、クリックストリーム分析ツール自動車交通モニタリング等を含むが、これらに限定されない。たとえば、温度センサを、温度測定値発信するように構成することができる。このようなアプリケーションから、データストリームを処理することが可能な新たな種類のアプリケーションの必要性が生じた。

0005

イベントストリームに基づくこれらの種類のアプリケーションの場合のデータの管理および処理は、時間を強く重視してデータ管理およびクエリ機能を構築することを含む。連続する無限のデータ集合に対する長時間のクエリ実行を含む、異なる種類のクエリ機構が必要である。現在イベントストリーム処理に適した製品一式を提供している販売業者はあるが、これら製品が提供するものは依然として、現代のイベント処理ニーズ対処するのに必要な処理の柔軟性に欠けている。

課題を解決するための手段

0006

簡単な概要
本発明のある実施形態は、一般的にはデータ処理システムに関し、より具体的には継続時間可変ウィンドウを用いて連続イベントストリームを処理するための技術に関する。この技術は、たとえば、イベントデータストリームに対して機能する、コンピュータによって実施される方法、イベントデータストリームを処理する計算機、システム、または装置、1つ以上の処理部によって実行可能な複数の命令を格納するコンピュータ読取可能なメモリなどを用いて実施される技術を含み得る。

0007

ある実施形態において、1つのイベント時間ベースのウィンドウ内に留まる資格がある継続時間は、同一のイベントストリームを介して受信した異なるイベントごとに異なり得る。たとえば、このイベントストリームを介して受信した第1の入力イベントの場合にこの第1のイベントが時間ベースの範囲ウィンドウ内に留まる資格がある継続時間が「X」で、同一のイベントストリームを介して受信した第2のイベントの場合にこの第2のイベントが時間ベースのウィンドウ内に留まる資格がある継続時間が「Y」で、「X」が「Y」と同じでないことがある。第1および第2のイベントは、関連付けられたタイムスタンプが同一または異なる場合がある。本発明の実施形態はしたがって、1つのイベントが時間ベースのウィンドウ内にある時間の量を制御できるようにする。

0008

ある実施形態において、入力イベントが時間ベースのウィンドウ内にある継続時間は、このイベントの1つ以上の属性の1つ以上の値の関数である。イベントの種類が異なれば1つ以上の属性の値は異なり得るので、異なるイベントが時間ベースのウィンドウ内にある時間の量は異なり得る。したがって、1つのイベントが時間ベースのウィンドウ内にある時間の量は、このイベントの1つ以上の属性を介して制御することができる。

0009

一実施形態において、複数のイベントがイベントストリームを介して計算装置によって受信されてもよい。たとえば、第1のイベントおよび第2のイベントがイベントストリームを介して受信されてもよい。第1のイベントに対して第1の継続時間を決定してもよく、第1の継続時間は、このイベントストリームに対して指定された時間ベースのウィンドウ内に第1のイベントが留まる資格がある継続時間を示す。第2のイベントに対して第2の継続時間を決定してもよく、第2の継続時間は、時間ベースのウィンドウ内に第2のイベントが留まる資格がある継続時間を示し、第2の継続時間は第1の継続時間と異なる。

0010

ある実施形態において、第1および第2のイベントを、そのイベントストリームに対して指定された時間ベースのウィンドウに追加してもよい。第1のイベントは、時間ベースのウィンドウ内に第1の継続時間留まった後に、時間ベースのウィンドウから除去または削除される。第2のイベントは、時間ベースのウィンドウ内に第2の継続時間留まった後に、時間ベースのウィンドウから除去または削除される。このように、第1のイベントが時間ベースのウィンドウ内にある継続時間は、第2のイベントがこの時間ベースのウィンドウ内にある継続時間と異なり得る。

0011

上記第1および第2のイベントの例の実施形態において、第1のイベントは関連付けられた第1の時間を有していてもよく、第2のイベントは関連付けられた第2の時間を有していてもよい。一例において、第1の時間と第2の時間は同一であってもよい。第2の例において、第1の時間は第2の時間と異なっていてもよい。

0012

ある実施形態において、1つのイベントが時間ベースのウィンドウ内にある資格がある継続時間は、このイベントの1つ以上の属性の値に基づいていてもよい。

0013

ある実施形態において、行‐時間範囲ウィンドウは、異なる区画であってもよい。1つのイベントが属する区画は、第1のイベントの属性の値に基づいていてもよい。1つのイベントが、1つの区画のための行‐時間範囲ウィンドウ内にある資格がある時間の量は、このイベントの1つ以上の属性の1つ以上の値に基づいていてもよい。したがって、特定の区画に属するイベントについては、異なるイベントは、この特定の区画のための行‐時間範囲ウィンドウ内に異なる継続時間留まる資格を有し得る。

0014

ある実施形態において、第1のイベントに関連付けられた第1の時間と第1の継続時間とに基づいて、第1のイベントの第1の満了時間を計算してもよい。第2のイベントに関連付けられた第2の時間と第2の継続時間とに基づいて、第2のイベントの第2の満了時間を計算してもよい。第1のイベントは、第1の満了時間の到来時または到来後に、時間ベースのウィンドウから除去または削除される。同様に、第2のイベントは、第2の満了時間の到来時または到来後に、時間ベースのウィンドウから除去または削除されてもよい。

0015

本開示の一局面に従い、計算装置が提供される。この計算装置は、計算装置がイベントストリームを介して受信した第1のイベントの第1の継続時間を決定するように構成された第1の決定部を含み、第1の継続時間は、イベントストリームに対して指定された時間ベースのウィンドウ内に第1のイベントが留まる資格がある継続時間を示す。計算装置は、計算装置がイベントストリームを介して受信した第2のイベントの第2の継続時間を決定するように構成された第2の決定部を含んでいてもよく、第2の継続時間は、時間ベースのウィンドウ内に第2のイベントが留まる資格がある継続時間を示す。第2の継続時間は第1の継続時間と異なっていてもよい。

0016

ある実施形態において、計算装置はさらに、第1の時間イベントが時間ベースのウィンドウ内に第1の継続時間留まった後に第1のイベントを時間ベースのウィンドウから除去するように構成された第1の除去部と、第2の時間イベントが時間ベースのウィンドウ内に第2の継続時間留まった後に第2のイベントを時間ベースのウィンドウから除去するように構成された第2の除去部とを含む。

0017

ある実施形態において、第1のイベントは関連付けられた第1の時間を有し、第2のイベントは関連付けられた第2の時間を有し、第1の時間は第2の時間と同一である。

0018

ある実施形態において、第1のイベントは関連付けられた第1の時間を有し、第2のイベントは関連付けられた第2の時間を有し、第1の時間は第2の時間と異なる。

0019

ある実施形態において、第1の継続時間を決定することは、第1のイベントの1つ以上の属性の1つ以上の値に基づいて第1の継続時間を計算することを含む。さらに、第2の継続時間を決定することは、第2のイベントの1つ以上の属性の1つ以上の値に基づいて第2の継続時間を計算することを含む。

0020

ある実施形態において、第1の決定部は、第1のイベントの第1の属性の値に基づいて、第1のイベントのための第1の区画を決定するように構成される。第2の決定部は、第2のイベントの第1の属性の値に基づいて、第2のイベントは第1の区画に属すると決定するように構成される。時間ベースのウィンドウは第1の区画のためのものである。

0021

ある実施形態において、第1の決定部は、第1のイベントに関連付けられた第1の時間と第1の継続時間とに基づいて第1のイベントの第1の満了時間を決定するように構成される。第2の決定部は第2のイベントに関連付けられた第2の時間と第2の継続時間とに基づいて第2のイベントの第2の満了時間を決定するように構成される。第1の除去部は、第1の満了時間の到来時または到来後に時間ベースのウィンドウから第1のイベントを除去するように構成される。第2の除去部は、第2の満了時間の到来時または到来後に時間ベースのウィンドウから第2のイベントを除去するように構成される。

0022

以下の詳細な説明は、添付の図面とともに、本発明の実施形態の性質の一層の理解をもたらすであろう。

図面の簡単な説明

0023

本発明の実施形態を組込み得るイベント処理システムの簡略化された高レベルの図を示す。
本発明の実施形態に従い、継続時間可変ウィンドウを管理するための方法を示す簡略化されたフローチャートを示す。
本発明の実施形態に従い、継続時間可変の時間ベースウィンドウ処理を実現するために使用し得るモジュールおよびデータ構造を示す。
上記のように優先度キューを用いて継続時間可変の時間ベースウィンドウを実現する実施形態において時間ベースウィンドウオペレータが実行し得る処理を示す簡略化されたフローチャートを示す。
本発明の実施形態に従い、区画のための継続時間可変ウィンドウを管理するための方法を示す簡略化されたフローチャートを示す。
本発明の実施形態に従い、優先度キューを用いて区画のための継続時間可変ウィンドウを扱うために時間ベースウィンドウオペレータが実行し得る処理を示す簡略化されたフローチャートを示す。
本発明の実施形態に従い使用し得るシステム環境の構成要素を示す簡略化されたブロック図である。
本発明のある実施形態に従い使用し得るコンピュータシステムの簡略化されたブロック図である。
本発明のある実施形態に従い使用し得る計算装置の簡略化されたブロック図である。

実施例

0024

詳細な説明
以下の記載では、説明を目的として具体的な詳細事項が本発明の実施形態の十分な理解をもたらすべく述べられている。しかしながら、さまざまな実施形態がこういった具体的な詳細事項なしで実施し得ることは明らかであろう。図面および説明は限定を意図したものではない。

0025

データのストリームを処理するための改善された技術を提供する、ある実施形態について説明する。1つのイベントが時間ベースのウィンドウ内に留まる資格がある継続時間は、同一イベントストリームを介して受信した異なるイベントごとに異なり得る。ある実施形態において、入力イベントが時間ベースのウィンドウ内にある継続時間は、このイベントの1つ以上の属性の1つ以上の値の関数である。イベントが異なれば1つ以上の属性値は異なり得るので、異なるイベントがそのイベントストリーム用の時間ベースのウィンドウ内にある時間の量は異なり得る。1つのイベントが時間ベースのウィンドウ内にある時間の量は、このイベントの1つ以上の属性を介して制御することができる。

0026

連続データストリーム(イベントストリームまたはイベントデータストリームとも呼ばれる)は、明確な終わりがない、本質的に連続するまたは無限であるデータまたはイベントのストリームである。論理的に、イベントまたはデータストリームは、一連データ要素(イベントとも呼ばれる)であり、各データ要素は関連付けられたタイムスタンプを有する。連続イベントストリームは、論理的には要素(s,T)のバッグ(bag)またはセットで表わすことができ、「s」はデータ部分を表わし「T」は時間ドメインを表わす。「s」部分は一般的にタプルまたはイベントと呼ばれる。イベントストリームはしたがってタイムスタンプされた一連のタプルまたはイベントである。

0027

いくつかの実施形態において、あるストリーム内のイベントに関連付けられるタイムスタンプは、クロック時間に匹敵し得る。しかしながら、他の実施形態において、あるイベントストリーム内のイベントに関連付けられる時間は、アプリケーションドメインによって定義してもよく、クロック時間に対応しなくてもよいが、たとえばその代わりに連続番号によって表わしてもよい。したがって、あるイベントストリーム内のイベントに関連付けられる時間情報は、数字、タイムスタンプ、または時間の連続の概念を表わす他の情報によって表わすことができる。入力イベントストリームを受信するシステムでは、イベントは、タイムスタンプが増す順序でシステムに到着する。同一のタイムスタンプを有する2つ以上のイベントがある場合がある。

0028

いくつかの実施形態において、あるイベントストリーム内のイベントは、世の中の何らかのイベントの発生(たとえば、温度センサの値が新たな値に変化したとき、株式銘柄の価格が変化したとき)を表わしてもよく、このイベントに関連付けられた時間情報が、データストリームイベントによって表わされる上記世の中のイベントが発生した時間を示してもよい。

0029

イベントストリームを介して受信するイベントについては、イベントに関連付けられた時間情報を用いて、イベントストリーム内のイベントがタイムスタンプの値が増す順序で到着することを保証する。これにより、受信するイベントストリーム内のイベントを、それぞれのイベントに関連付けられた時間情報に基づいて並べることができる。このように並べることを可能にするためには、後で生成されたイベントが、先に生成されたイベントよりも後のタイムスタンプを有するように、タイムスタンプを、イベントストリーム内のイベントと、タイムスタンプが減少しないやり方で関連付ければよい。別の例として、連続番号を時間情報として用いるのであれば、後に生成されたイベントに関連付けられる連続番号は、先に生成されたイベントに関連付けられる連続番号よりも大きい。同一のイベントストリームに属するイベントは通常、関連付けられた時間情報によってこれらイベントに課された順序で処理され、先のイベントは後のイベントよりも前に処理される。いくつかの実施形態において、たとえば、データストリームイベントで表わされる世の中のイベントが同時に発生するときには、複数のイベントが同一のタイムスタンプまたは連続番号に関連付けられることがある。これらの状況において、イベントは受信された順序で処理される。

0030

イベントストリーム内のイベントに関連付けられる時間情報(たとえばタイムスタンプ)は、ストリームのソースによって設定されてもよく、または、その代わりに、このストリームを受信するシステムによって設定されてもよい。たとえば、ある実施形態において、イベントストリームを受信するシステム上でハートビート(heartbeat)を管理してもよく、イベントに関連付けられる時間は、ハートビートによって測定される、システムへのイベントの到着時間に基づいていてもよい。あるイベントストリーム内の2つのイベントが同一の時間情報を有することが起こり得る。タイムスタンプの順序条件は、1つのイベントストリームに特有のものであるが、異なるストリームのイベントを、任意で交互配置してもよいことに注意しなければならない。

0031

イベントストリームには、関連付けられたスキーマ「S」があり、スキーマは、時間情報と、名前付きの1つ以上の属性からなる一組の属性とを含む。特定のイベントストリームに属するすべてのイベントは、この特定のイベントストリームに関連付けられたスキーマに従う。したがって、イベントストリーム(s,T)の場合、このイベントストリームは、スキーマ「S」を、(<time_stamp>,<attribute(s)>)として有し得る。<attributes>は、スキーマのデータ部分を表わし1つ以上の属性を含み得る。たとえば、株式相場表示機のイベントストリームについてのスキーマは、<株式銘柄>および<株価>という属性を含み得る。このようなストリームを介して受ける各イベントは、1つのタイムスタンプと上記2つの属性とを有する。たとえば、株式相場表示機のイベントストリームは、以下のイベントおよび関連付けられたタイムスタンプを受けることができる。

0032

...
(,)
(,)
(,<PCAR,38>)
(,)
(,)
(,)
...
上記ストリームにおけるストリーム要素(<timestamp_N+1>,<ORCL,62>)の場合、「stock_symbol」(株式銘柄)および「stock_value」(株価)という属性に対するイベント値はそれぞれORCLおよび62である。このストリーム要素に関連付けられたタイムスタンプは「timestamp_N+1」である。このように、連続イベントストリームは、イベントのフローであり、各イベントは同じ一連の属性を有する。

0033

図1は、本発明の実施形態を組込み得るイベント処理システム100の簡略化された高レベルの図を示す。イベント処理システム100は、1つ以上のイベントソース(104,106,108)と、イベントストリームを処理するための環境を提供するように構成されたイベント処理サーバ(event processing server)(EPS)102と、1つ以上のイベントシンク(110,112)とを含み得る。イベントソースは、EPS102が受信するイベントストリームを生成する。EPS102は、1つ以上のイベントストリームを1つ以上のイベントソースから受信し得る。たとえば、図1に示されるように、EPS102は、入力イベントストリーム114をイベントソース104から受信し、第2の入力イベントストリーム116をイベントソース106から受信し、第3のイベントストリーム118をイベントソース108から受信する。1つ以上のイベント処理アプリケーション(120,122,および124)をEPS102に導入しEPS102によって実行してもよい。EPS102によって実行されるイベント処理アプリケーションは、1つ以上の入力イベントストリームをリッスンし、1つ以上のイベントストリームを介して受信したイベントを、入力イベントストリームから1つ以上のイベントを注目すべきイベントとして選択する処理ロジックに基づいて処理するように構成されてもよい。注目すべきイベントは次に、1つ以上の出力イベントストリームの形態で1つ以上のイベントシンク(110,112)に送信してもよい。たとえば、図1において、EPS102は、出力イベントストリーム126をイベントシンク110に出力し、第2の出力イベントストリーム128をイベントシンク112に出力する。ある実施形態において、イベントソース、イベント処理アプリケーション、およびイベントシンクは、これら構成要素のうちのいずれも、他の構成要素の変更を生じさせることなく追加または除去できるよう、互いに分離されている。

0034

一実施形態において、EPS102を、サービス共有するEquinox OSGiをベースとするもののような軽量Java(登録商標アプリケーションコンテナを含むJavaサーバとして実現してもよい。いくつかの実施形態において、EPS102は、たとえばJRockit Real Timeを用いてイベント処理の超高スループットおよびマイクロ秒レイテンシサポートし得る。EPS102はまた、イベント処理アプリケーションを開発するためのツール(たとえばOracle CEP VisualizerおよびOracle CEP IDE)を含む開発プラットフォーム(たとえば完全なリアルタイムエンドツーエンドJavaイベント駆動型アーキテクチャ(Event-Driven Architecture)(EDA)開発プラットフォーム)を提供し得る。

0035

イベント処理アプリケーションは、1つ以上の入力イベントストリームをリッスンし、この1つ以上の入力イベントストリームから注目すべき1つ以上のイベントを選択するためにロジック(たとえばクエリ)を実行し、選択した注目すべきイベントを1つ以上の出力イベントストリームを介して1つ以上のイベントソースに出力するように構成される。図1は、1つのこのようなイベント処理アプリケーション120についてのドリルダウンを提供する。図1に示されるように、イベント処理アプリケーション120は、入力イベントストリーム118をリッスンし、入力イベントストリーム118から注目すべき1つ以上のイベントを選択するためにロジックを含むクエリ130を実行し、選択した注目すべきイベントを出力イベントストリーム128を介してイベントシンク112に出力するように構成される。イベントソースの例は、アダプタ(たとえばJMS、HTTP、およびファイル)、チャネルプロセッサ、テーブル、キャッシュ等を含むがこれらに限定されない。イベントシンクの例は、アダプタ(たとえばJMS、HTTP、およびファイル)、チャネル、プロセッサ、キャッシュなどを含むがこれらに限定されない。

0036

図1のイベント処理アプリケーション120は、1つの入力ストリームをリッスンし選択したイベントを1つの出力ストリームを介して出力するものとして示されているが、これは限定を意図したものでない。これに代わる実施形態では、イベント処理アプリケーションは、1つ以上のイベントソースから受信した複数の入力ストリームをリッスンし、モニタリングされたストリームからイベントを選択し、選択したイベントを1つ以上の出力イベントストリームを介して1つ以上のイベントシンクに出力するように構成されてもよい。同一のクエリを2つ以上のイベントシンクに関連付け異なる種類のイベントシンクに関連付けてもよい。

0037

その性質上無制限なので、1つのイベントストリームを介して受信されるデータの量は通常非常に多い。結果として、クエリを目的としてすべてのデータを格納またはアーカイブすることは、通常実用的でなく望ましくない。イベントストリームを処理するには、イベントをEPS102が受信したときに、受信したイベントデータをすべて格納することなく、イベントをリアルタイムで処理することが必要である。したがって、EPS102は、EPS102がイベントを受信したときに、受信したイベントをすべて格納することなく、イベントを処理できるようにする、特別なクエリ機構を提供する。

0038

イベント駆動型のアプリケーションはルール駆動型であり、これらルールは、入力ストリームを処理するのに使用される連続クエリの形態で表わしてもよい。連続クエリは、クエリ処理の結果としてどのイベントを注目すべきイベントとして選択し出力すべきかということを含む、受信したイベントに対して実行すべき処理を特定する命令(たとえばビジネスロジック)を含み得る。連続クエリは、データ記憶装置まで持続させて、イベントの入力ストリームの処理およびイベントの出力ストリームの生成のために使用してもよい。連続クエリは、発見すべきフィルタリングおよび集約関数を指定し入力イベントストリームから注目すべきイベントを抽出してもよい。結果として、出力イベントストリームにおけるアウトバウンドのイベントの数は通常、イベントを選択する元になる入力イベントストリームにおけるイベントの数よりも遥かに少ない。

0039

有限データ集合に対して一度実行されるSQLクエリと異なり、特定のイベントストリームに対してアプリケーションによりEPS102に登録された連続クエリは、このイベントストリーム内のイベントが受信される度に実行されてもよい。連続クエリ実行の一部として、EPS102は、受信したイベントを、連続クエリが指定する命令に基づいて評価することにより、1つ以上のイベントを注目すべきイベントとして選択すべきか否か決定し、連続クエリ実行の結果として出力する。

0040

連続クエリは異なる言語を用いてプログラムしてもよい。ある実施形態において、連続クエリは、Oracle社が提供する連続クエリ言語(Continuous Query Language)(CQL)を用いて構成されOracle社の複合イベント処理(Complex Events Processing)(CEP)という製品によって使用されてもよい。Oracle社のCQLは、イベントストリームに対して実行することができるクエリ(CQLクエリと呼ばれる)をプログラムするのに使用できる宣言型言語である。ある実施形態において、CQLは、ストリーミングイベントデータの処理をサポートする構成が追加されたSQLに基づく。

0041

一実施形態において、イベント処理アプリケーションは、以下の種類の構成要素で構成されてもよい。

0042

(1)入力および出力ストリームならびにリレーションソースおよびシンクに直接インターフェイスする1つ以上のアダプタ。アダプタは、入力および出力ストリームプロトコル解釈するように構成され、イベントデータを、アプリケーションプロセッサがクエリできる標準化された形態に変換する役割を担う。アダプタは、標準化されたイベントデータを、チャネルまたは出力ストリームおよびリレーションシンクに転送してもよい。イベントアダプタを、さまざまなデータソースおよびシンクに対して定めてもよい。

0043

(2)イベント処理のエンドポイントとして作用する1つ以上のチャネル。特に、チャネルは、イベント処理エージェントがイベントデータに対して機能を発揮できるようになるまでイベントデータをキュー保管する役割を担う。

0044

(3)1つ以上のアプリケーションプロセッサ(またはイベント処理エージェント)は、チャネルからの標準化されたイベントデータを消費(consume)し、これをクエリを用いて処理することにより注目すべきイベントを選択し、選択した注目すべきイベントを出力チャネルに転送(またはコピー)するように構成される。

0045

(4)1つ以上のビーン(bean)は、出力チャネルをリッスンするように構成または登録されてもよく、新たなイベントが出力チャネルに挿入されたことによってトリガされてもよい。いくつかの実施形態において、このユーザコードは、昔からある単なるJavaオブジェクト(plain-old-Java-object)(POJO)であってもよく、または、ユーザコードがOracle CEPのイベントビーンAPIを使用してビーンをOracle CEPによって管理できるようにしてもよい。ユーザアプリケーションは、JMS、ウェブサービス、ファイルライター等の一組の外部サービスを利用して、生成されたイベントを外部イベントシンクに転送することができる。

0046

一実施形態において、イベントアダプタは、イベントデータを入力チャネルに与える。入力チャネルは、入力チャネルが与えるイベントに対して機能する1つ以上のCQLクエリに関連付けられたCQLプロセッサに接続される。CQLプロセッサは、クエリ結果書込まれる出力チャネルに接続される。

0047

いくつかの実施形態において、イベント処理アプリケーションに対し、イベント処理アプリケーションのさまざまな構成要素を説明しどのようにして構成要素同士が接続されるかを説明しアプリケーションによって処理されるイベントタイプを説明するアセンブリファイルを与えてもよい。イベントを選択するための連続クエリまたはビジネスロジックを指定するために別々のファイルを与えてもよい。

0048

図1に示されるシステム100が図1に示される構成要素以外の構成要素を有し得ることが理解されるはずである。さらに、図1に示される実施形態は、本発明の実施形態を組込み得るシステムの一例に過ぎない。他のいくつかの実施形態では、システム100が有する構成要素の数は図1に示されるものよりも多くても少なくてもよく、2つ以上の構成要素を組合わせてもよく、または、構成要素の構成または配置が異なっていてもよい。システム100は、パーソナルコンピュータポータブルデバイス(たとえば携帯電話または装置)、ワークステーションネットワークコンピュータメインフレームキオスク、サーバ、またはその他何等かのデータ処理システムを含むさまざまな種類のものであってもよい。他のいくつかの実施形態において、システム100を、システム100の1つ以上の構成要素がクラウド内の1つ以上のネットワークに分散している分散システムとして構成してもよい。

0049

図1に示される構成要素のうちの1つ以上は、ソフトウェアハードウェア、またはその組合わせにおいて実現し得る。いくつかの実施形態において、ソフトウェアは、メモリ(たとえば非一時的なコンピュータ読取可能な媒体)に、メモリ素子に、または何等かのその他の物理メモリに格納されてもよく、1つ以上の処理部(たとえば1つ以上のプロセッサ、1つ以上のプロセッサコア、2つ以上のGPUなど)によって実行されてもよい。

0050

イベントおよびアプリケーションの例
(1)市場変動に基づいた株式取引を自動化するための金融アルゴリズム取引アプリケーション。クエリの例:いずれかの20秒ウィンドウ内で株式Bの上昇が2%を上回り株式Aはそうではない場合、自動的に株式Aを購入する。

0051

(2)運輸イベント間パターンを検出することによって不正行為を発見するための安全および不正検出アプリケーション。クエリの例:都市地下鉄システムにアクセスするために1枚のIDカードが5秒未満の間に2度使用された場合、ピギーバックについてセキュリティ警告を発する。

0052

(3)偽陽性(false positive)警告を減じるためのエネルギおよび電気通信警告相関アプリケーション。クエリの例:いずれかの5秒ウィンドウ内で15の警告を受けたが30秒以内に検出された同様の警告が5未満の場合、何もしない。

0053

(4)患者バイタルサインをモニタリングし特定のイベントが発生した場合に何らかのタスクを実行するためのヘルスケア患者モニタリングアプリケーション。クエリの例:薬の変更に続いて患者の血圧がいずれかの10秒ウィンドウ内でこの患者の最大許容血圧の20%以内上昇した場合、最も近い看護師通知する。

0054

ウィンドウベースの処理
別の例として、イベント処理アプリケーションは、ある時間範囲のデータまたはイベントを照合し処理するように構成されてもよい。たとえば、EPS102は、「温度(temp)」属性および関連付けられた時間を含むイベントからなる温度イベントストリームを受信してもよい。「温度」データは、関連付けられた時間における温度を示してもよい。前の10秒の平均温度を得るために、CQLクエリをこのようなイベントストリーム用に構築してもよい。クエリは次のように指定してもよい。

0055

Select avg (temp) from temp [range 10]
上記クエリは、「10」という範囲(range)における「温度(temp)」の平均(avg)を発見する。この例における範囲「10」は10秒を表わす。他の実施形態において、この範囲を、分、日、またはそれ以外の指定された時間単位等、他の時間単位を用いて指定してもよい。このCQLクエリは、EPS102によって実行されると、前の10秒で受信したタプルを評価し平均温度を見出す。「満了」タプル、すなわち示されている範囲よりも前に(すなわち10秒ウィンドウ外で)受信したタプルは、クエリによって無視される。したがって、CQLクエリは、受信したイベントすべてを捕えて格納する必要はなく、最新の10秒ウィンドウ内のイベントを処理するだけでよい。

0056

イベントストリームは無限の可能性があるタプルストリームを表わすので、タプルを受信したときに処理するために、CQLクエリ(または一般的には連続クエリ)は、CQLクエリの各実行時に処理するのに使用される受信イベントサブセットを特定する。CQLクエリはこれをウィンドウを指定することによって行なう。この場合のウィンドウは、CQLクエリを実行するときに処理目的で使用する受信イベントのサブセット(すなわち一部)を定める。ウィンドウは、イベントストリームからのゼロ以上のイベントからなる有限のサブセットである。

0057

オラクルイベント処理のCQLのセマンティクスでは、ウィンドウは、ストリーム−リレーションオペレータとして定義され、すべての瞬間において、リレーションは、順序付けられていない、時間によって変化する、イベントの有限の集合(またはバッグ)である。一実施形態において、ストリーム−リレーションオペレータは、ストリームに対してスライディングウィンドウを提供し、ウィンドウ仕様を用いて定められる。いくつかの実施形態において、ウィンドウは、
(1)時間ベース‐特定の継続時間に基づくもの、
(2)タプルベースまたはイベントベース‐イベントの数に基づくもの、または、
(3)区画ベース‐各区画で時間ベースまたはタプルベースのものであってもよい。

0058

時間ベースのウィンドウ
イベントストリームを処理するために、時間ベースのウィンドウは、このウィンドウに含まれるイベントを制御する時間パラメータを用いて定められる。いくつかの実施形態において、時間パラメータは、このウィンドウの時間範囲を指定してもよい。たとえば、CQLクエリは、入力ストリームSに対する時間範囲ベースのウィンドウを次のように指定してもよい。

0059

S [range T]
上記CQLコードは、継続時間「T」をパラメータとして取る、ストリームに対する時間ベースの範囲ウィンドウを作成し、出力リレーションを生成する。継続時間Tは、分、秒、日等の何等かの時間単位で指定されればよく、一実施形態では、単位が指定されなければデフォルトを秒にする。このように、「範囲」というキーワードを用いて指定された時間ベースのウィンドウは、ストリームSに対し、時間間隔「T」をパラメータとして取り出力リレーション「R(t)」を生成する時間ベースのスライディングウィンドウを作成する。時間「t」において、出力リレーションR(t)は、入力イベントストリームSからの、「t−T」と「t」の間の関連するタイムスタンプを有するすべてのイベントを含み、「T」はこのウィンドウのサイズすなわち継続時間である。

0060

時間ベースの範囲ウィンドウの過去の実装例では、CQLにおいて時間ウィンドウの継続時間を指定するために使用される時間パラメータ「T」は、一定または固定されていた。したがって、以前の実装例では、各イベントが時間ベースのウィンドウ内にある時間の量は、イベント自体に応じて異なるものではない。すべてのイベントは等しく扱われ、すべてのイベントは時間ベースのウィンドウ内に同じ継続時間存在する。たとえば、先に説明した温度平均のCQLクエリの例では、範囲は「[range 10]」として指定され、「T」の値は10秒を表わす固定値「10」に設定される。この範囲ウィンドウは固定されており変動しないという性質のものであるので、時間「t」において、ウィンドウは最新の10秒(すなわち「t」と「t−10」の間)で受信したイベントのリレーションセットを評価する。ウィンドウ自体は「t」でスライドするが、ウィンドウの継続時間は常に10秒に固定されることに注意しなければならない。継続時間が固定されているので、以前は、時間ベースのウィンドウ内のイベントは常に、この時間ウィンドウ内の同じ継続時間後に満了した。

0061

固定されたまたは一定の時間ベースの範囲ウィンドウに加えて、本発明のある実施形態は、時間ベースのウィンドウの継続時間を、同一のイベントストリームを介して受信した異なるイベントごとに変えることができる。このような実施形態では、スライドする時間ベースの範囲ウィンドウの継続時間を定めるために用いられる継続時間パラメータ「T」の値を、異なるイベントごとに異なるようにする、したがって変えることができる。このため、特定のイベントストリームに対してEPS102に登録されたクエリにとって、このイベントストリームを介して受信したイベントの継続時間は、異なるイベントごとに異なり得る。たとえば、図1に示されるように、イベントアプリケーション120は、可変の時間ベースのウィンドウを指定するCQLコードを有する連続クエリ130を含み得る。

0062

たとえば、イベントストリームを介して受信した第1の入力イベントについて、第1のイベントが時間ベースの範囲ウィンドウ内に留まる資格がある継続時間は「X」で、同じイベントストリームを介して受信した第2のイベントについて、第2のイベントが時間ベースのウィンドウ内に留まる資格がある継続時間は「Y」で、「X」が「Y」と同一でないという場合がある。第1および第2のイベントは、同じ関連タイムスタンプを有し得る、または、異なるタイムスタンプを有し得る。本発明の実施形態はしたがって、イベントが時間ベースのウィンドウ内にある時間の量を制御できるようにする。

0063

イベントに対して継続時間可変範囲パラメータTの値を設定できる方法としてはさまざまな方法がある。いくつかの実施形態において、継続時間パラメータTは、ユーザによって構成可能なものであってもよい。ある実施形態において、Tの値(すなわち時間ベースの範囲ウィンドウの継続時間)は、イベント自体の関数である。たとえば、受信したイベントに対するTの値は、受信したイベントの1つ以上の属性の値に基づいて設定してもよい。たとえば、関連するスキーマが2つの属性<attr_1,attr_2>を有するイベントストリームを想定する。一実施形態において、このイベントストリームを対象とするCQLクエリにおいて、イベントが時間ベースの範囲ウィンドウ内にあることが可能な時間を、属性「attr_2」の値に設定されるようにプログラムしてもよい。たとえば、イベントストリームが下記イベントを受信するとする。

0064

...
(,)
(,)
(,)
(,)
...
timestamp_Nを有するイベントを受信したとき、このイベントが時間ベースの範囲ウィンドウ内に留まることができる継続時間は、5時間単位と計算される。なぜなら、タプルのattr_2の値が5であるからである。timestamp_N+1を有するイベントの場合、このイベントが時間ベースの範囲ウィンドウ内に留まることができる継続時間は、2時間単位と計算され、timestamp_N+2を有するイベントの場合、このイベントが時間ベースの範囲ウィンドウ内に留まることができる継続時間は、2時間単位と計算され、timestamp_N+3を有するイベントの場合、このイベントが時間ベースの範囲ウィンドウ内に留まることができる継続時間は、4時間単位と計算され、以降同様に続く。このようにして、1つのイベントがそのイベントストリームに対する時間ベースのウィンドウ内に留まる資格がある継続時間は、イベントごとに異なり得る。上記例において、継続時間は受信したイベントの属性「attr_2」に基づいて変化する。

0065

他のいくつかの実施形態において、時間パラメータTは、数式(mathematical expression)として次のように表わしてもよい。

0066

S [RANGE ]
ある実施形態において、この数式は、イベントストリームスキーマの1つ以上の属性に基づくものであってもよい。たとえば、スキーマ属性が<attr_1,attr_2>であるイベントストリームについて、<mathematical_espression>は、<attr_2+4>,<attr_1+attr_2>等として定めてもよい。これに代わる実施形態において、イベントベースであってもなくてもよい他の関数または条件を用いて、連続クエリの時間ベースの範囲ウィンドウの継続時間を設定し変化させてもよい。

0067

別の例として、ストリームを次のように定義するとする。
CREATE STREAM S (DATA INTEGER, RANGE_COLUMN BIGINT)
この定義によると、各ストリームイベントは、2つの属性(カラムとも呼ばれる)、すなわち、整数データ値を取る第1の属性「DATA」と、bigint(長い)値を取る第2の属性「RANGE_COLUMN」とを含む。次に、この「RANGE_COLUMN」属性を用いて、時間ベースの範囲ウィンドウの継続時間を指定してもよい。

0068

継続時間可変の時間ベース範囲ウィンドウを指定するCQLクエリは、ストリームSに対し、次のように指定してもよい。

0069

CREATE QUERY Q1 AS SELECT * FROM S [RANGE ]
これにより、時間ベースの範囲ウィンドウに対して連続クエリQ1が作成され、この場合、時間ベースのウィンドウの継続時間が「range_expression」という式として指定される。

0070

一実施形態において、range_expressionは、ストリームSからの1つ以上の属性に基づいていてもよい。たとえば次の通りである。

0071

CREATE QUERY Q1 AS SELECT * FROM S [RANGE RANGE_COLUMN]
ここで、受信したイベントの属性RANGE_COLUMNの値は、時間ベースの範囲ウィンドウの継続時間を指定する。この場合、<range_expression>の値は、Sというイベントストリームを介して受信した各入力イベントに対し、受信した入力イベントの属性RANGE_COLUMNの値を用いて計算される。時間「t」で受信した入力タプルは、時間ベースのウィンドウに挿入され、この時間ベースのウィンドウ内に、<range_expression>の値に従う継続時間留まった後、満了するかまたはウィンドウから除去される。受信イベントに対して計算される満了時間はしたがって、(t+range_expression_value)であり、「range_expression_value」は、イベントを受信したときに、受信したイベントのRANGE_COLUMN属性の値を用いて<range_expression>の値を求めることによって計算される値である。属性RANGE_COLUMNの値はイベントごとに異なり得るので、時間ベースのウィンドウの継続時間もイベントごとに異なり得る。

0072

以下の例は、イベント受信時の継続時間可変の時間ベース範囲ウィンドウの効果を示す。この例について、入力イベントストリームSは、3つの属性c1、c2、およびc3として(c1 integer,c2 bigint,c3 double)を有するスキーマ(<timestamp>,<attributes>)を有すると想定する。連続CQLクエリをストリームSに対して以下のように指定してもよい。

0073

SELECT * FROM S [range c2]
このクエリによると、受信した各入力について、時間ベースのウィンドウの継続時間は属性c2の値に基づく。

0074

以下の表Aは、タプルの入力ストリームと、入力イベントストリームSを介してイベントを受信するときのさまざまな時点における時間ベースの範囲ウィンドウの内容とを示す。

0075

0076

上記表Aにおいて、左の列はスキーマ(タイムスタンプ,c1,c2,c3)を有するストリームSを介して受信されたイベントのストリームを示す。タイムスタンプはミリ秒(msecs)で示され、1秒=1000msecsである。タイムスタンプは、たとえば、イベントの受信時の時間またはイベントの発生時の時間であってもよい。表Aの右の列は、さまざまな時点(ミリ秒(msecs)で示され、1秒=1000msecsである)における、時間ベースの範囲ウィンドウの内容(すなわちイベント)を示す。イベントの前の「+」表記は、このイベントが時間ベースのウィンドウに追加されたことを示すために使用される。イベントの前の「−」表記は、このイベントが、このイベントが満了したために、時間ベースのウィンドウから削除されたことを示すために使用される。

0077

一実施形態において、イベントが受信されると、このイベントの満了時間が計算される。イベントに対して計算される満了時間は、このイベントが満了し時間ベースのウィンドウから削除されることになる時間を示す。その後このイベントは時間ベースのウィンドウに追加される。また、時間ベースのウィンドウが検査されて、このウィンドウ内のいずれかのイベントが満了しておりウィンドウから取除かれる必要があるか否か判断される。

0078

時間「t」に到着し時間範囲または継続時間が「T」であるイベントについて、このイベントの満了時間は(t+T)である。以下のクエリの場合、範囲の値は、受信したイベントの属性c2の値に基づく。

0079

SELECT * FROM S [range c2]
したがって、関連付けられたタイムスタンプが「t」である受信イベントについて、このイベントの満了時間は(t+c2の値)である。上記表Aにおいて、各受信イベントの満了時間(expiration time)は、このイベントの添え字として示されている。

0080

0081

ある実施形態において、範囲によって具体的に指定されない限り、範囲の時間単位のデフォルトは秒であり、したがって、S[range 1]は、S[range 1秒]に等しい。

0082

時間ベースのウィンドウ(すなわち時間ベースのウィンドウによって出力されるリレーションセット)は、1000ミリ秒の時点でイベントが到着する前、すなわち関連付けられたタイムスタンプが1000ミリ秒であるイベントが到着する前は、空である。表Aに示されるように、イベント(1000,10,1,10.0)が最初に受信される。このイベントの満了時間は2秒(イベントのタイムスタンプ+c2の値、すなわち1+1=2秒)と計算される。次に、このイベントは時間ベースのウィンドウに追加される(「+」で示される)。イベント(1000,10,1,10.0)は、時間ベースのウィンドウに1秒間留まり2秒の標識の時点でウィンドウから削除されることになる。この時点で、時間ベースの範囲ウィンドウは、1つのイベント(1000,10,1,10.0)を含む。

0083

次にイベント(2000,20,2,20.0)が受信される。一実施形態において、2000ミリ秒というタイムスタンプは、このイベントが受信された時間を表わしてもよい。時間ベースのウィンドウの内容が検査されて、このウィンドウ内のいずれかのイベントが満了しているか否か判断される。イベント(1000,10,1,10.0)は満了しており時間ベースのウィンドウから削除される(「−」で示される)と判断される。イベント(2000,20,2,20.0)の満了時間は4秒(イベントのタイムスタンプ+c2の値、すなわち、2+2=4秒)と計算される。次に、このイベントは時間ベースのウィンドウに追加される。このイベントは、ウィンドウ内に2秒間留まり4秒の標識の時点でウィンドウから削除されることになっている。この時点で、時間ベースの範囲ウィンドウは、1つのイベント(2000,20,2,20.0)を含む。

0084

次にイベント(3000,30,3,30.0)が受信される。時間ベースのウィンドウの内容が検査されて、このウィンドウ内のいずれかのイベントが満了しているか否か判断され、満了しているイベントはないと判断される。イベント(3000,30,3,30.0)の満了時間は6秒(イベントのタイムスタンプ+c2の値、すなわち、3+3=6秒)と計算される。このイベントは時間ベースのウィンドウに追加される。このイベントは、ウィンドウ内に3秒間留まり6秒の標識の時点でウィンドウから削除されることになっている。この時点で、時間ベースの範囲ウィンドウは、2つのイベント(2000,20,2,20.0)および新たに追加されたイベント(3000,30,3,30.0)を含む。

0085

次にイベント(4000,40,4,40.0)が受信される。時間ベースのウィンドウの内容が検査されて、このウィンドウ内のいずれかのイベントが満了しているか否か判断される。イベント(2000,20,2,20.0)は満了しており時間ベースのウィンドウから削除される(「−」で示される)と判断される。イベント(4000,40,4,40.0)の満了時間は8秒(イベントのタイムスタンプ+c2の値、すなわち、4+4=8秒)と計算される。次に、このイベントは時間ベースのウィンドウに追加される。このイベントは、ウィンドウ内に4秒間留まり8秒の標識の時点でウィンドウから削除されることになっている。この時点で、時間ベースの範囲ウィンドウは、2つのイベント(3000,30,3,30.0)および新たに追加されたイベント(4000,40,4,40.0)を含む。

0086

次にイベント(5000,50,5,50.0)が受信される。時間ベースのウィンドウの内容が検査されて、このウィンドウ内のいずれかのイベントが満了しているか否か判断され、満了しているイベントはないと判断される。イベント(5000,50,5,50.0)の満了時間は10秒(イベントのタイムスタンプ+c2の値、すなわち、5+5=10秒)と計算される。次に、このイベントは時間ベースのウィンドウに追加される。このイベントは、ウィンドウ内に5秒間留まり10秒の標識の時点でウィンドウから削除されることになっている。この時点で、時間ベースの範囲ウィンドウは、3つのイベント(3000,30,3,30.0)、(4000,40,4,40.0)、および新たに追加されたイベント(5000,50,5,50.0)を含む。

0087

次にイベント(6000,60,6,60.0)が受信される。時間ベースのウィンドウの内容が検査されて、このウィンドウ内のいずれかのイベントが満了しているか否か判断され、イベント(3000,30,3,30.0)は満了しており時間ベースのウィンドウから削除される(「−」で示される)と判断される。イベント(6000,60,6,60.0)の満了時間は12秒(イベントのタイムスタンプ+c2の値、すなわち、6+6=12秒)と計算される。次に、このイベントは時間ベースのウィンドウに追加される。このイベントは、ウィンドウ内に6秒間留まり12秒の標識の時点でウィンドウから削除されることになっている。この時点で、時間ベースの範囲ウィンドウは、3つのイベント(4000,40,4,40.0)、(5000,50,5,50.0)および新たに追加されたイベント(6000,60,6,60.0)を含む。

0088

次にイベント(7000,70,7,70.0)が受信される。時間ベースのウィンドウの内容が検査されて、このウィンドウ内のいずれかのイベントが満了しているか否か判断され、満了しているイベントはないと判断される。イベント(7000,70,7,70.0)の満了時間は14秒(イベントの到着時間+c2の値、すなわち、7+7=14秒)と計算される。次に、このイベントは時間ベースのウィンドウに追加される。このイベントは、ウィンドウ内に7秒間留まり14秒の標識の時点でウィンドウから削除されることになっている。この時点で、時間ベースの範囲ウィンドウは、4つのイベント(4000,40,4,40.0)、(5000,50,5,50.0)、(6000,60,6,60.0)、および新たに追加されたイベント(7000,70,7,70.0)を含む。

0089

次にイベント(8000,80,8,80.0)が受信される。時間ベースのウィンドウの内容が検査されて、このウィンドウ内のいずれかのイベントが満了しているか否か判断され、イベント(4000,40,4,40.0)は満了しており時間ベースのウィンドウから削除される(「−」で示される)と判断される。イベント(8000,80,8,80.0)の満了時間は16秒(イベントのタイムスタンプ+c2の値、すなわち、8+8=16秒)と計算される。次に、このイベントは時間ベースのウィンドウに追加される。このイベントは、ウィンドウ内に8秒間留まり16秒の標識の時点でウィンドウから削除されることになっている。この時点で、時間ベースの範囲ウィンドウは、4つのイベント(5000,50,5,50.0)、(6000,60,6,60.0)、(7000,70,7,70.0)、および新たに追加されたイベント(8000,80,8,80.0)を含む。

0090

次にイベント(9000,90,9,90.0)が受信される。時間ベースのウィンドウの内容が検査されて、このウィンドウ内のいずれかのイベントが満了しているか否か判断され、満了しているイベントはないと判断される。イベント(9000,90,9,90.0)の満了時間は18秒(イベントの到着時間+c2の値、すなわち、9+9=18秒)と計算される。このイベントは時間ベースのウィンドウに追加される。このイベントは、ウィンドウ内に9秒間留まり18秒の標識の時点でウィンドウから削除されることになっている。この時点で、時間ベースの範囲ウィンドウは、5つのイベント(5000,50,5,50.0)、(6000,60,6,60.0)、(7000,70,7,70.0)、(8000,80,8,80.0)、および新たに追加されたイベント(9000,90,9,90.0)を含む。

0091

次にイベント(10000,100,10,100.0)が受信される。時間ベースのウィンドウの内容が検査されて、このウィンドウ内のいずれかのイベントが満了しているか否か判断され、イベント(5000,50,5,50.0)は満了しており時間ベースのウィンドウから削除される(「−」で示される)と判断される。イベント(10000,100,10,100.0)の満了時間は20秒(イベントのタイムスタンプ+c2の値、すなわち、10+10=20秒)と計算される。このイベントは時間ベースのウィンドウに追加される。このイベントは、ウィンドウ内に10秒間留まり20秒の標識の時点でウィンドウから削除されることになっている。この時点で、時間ベースの範囲ウィンドウは、5つのイベント(6000,60,6,60.0)、(7000,70,7,70.0)、(8000,80,8,80.0)、(9000,90,9,90.0)、および新たに追加されたイベント(10000,100,10,100.0)を含む。

0092

次にイベント(11000,110,11,110.0)が受信される。時間ベースのウィンドウの内容が検査されて、このウィンドウ内のいずれかのイベントが満了しているか否か判断され、満了しているイベントはないと判断される。イベント(11000,110,11,110.0)の満了時間は22秒(イベントのタイムスタンプ+c2の値、すなわち、11+11=22秒)と計算される。このイベントは時間ベースのウィンドウに追加される。このイベントは、ウィンドウ内に11秒間留まり22秒の標識の時点でウィンドウから削除されることになっている。この時点で、時間ベースの範囲ウィンドウは、6つのイベント(6000,60,6,60.0)、(7000,70,7,70.0)、(8000,80,8,80.0)、(9000,90,9,90.0)、(10000,100,10,100.0)、および新たに追加されたイベント(11000,110,11,110.0)を含む。

0093

次にイベント(12000,120,12,12.0)が受信される。時間ベースのウィンドウの内容が検査されて、このウィンドウ内のいずれかのイベントが満了しているか否か判断され、イベント(6000,60,6,60.0)は満了しており時間ベースのウィンドウから削除される(「−」で示される)と判断される。イベント(12000,120,12,120.0)の満了時間は24秒(イベントの到着時間+c2の値、すなわち、12+12=24秒)と計算される。次に、このイベントは時間ベースのウィンドウに追加される。このイベントは、ウィンドウ内に12秒間留まり24秒の標識の時点でウィンドウから削除されることになっている。この時点で、時間ベースの範囲ウィンドウは、6つのイベント(7000,70,7,70.0)、(8000,80,8,80.0)、(9000,90,9,90.0)、(10000,100,10,100.0)、(11000,110,11,110.0)、および新たに追加されたイベント(12000,120,12,120.0)を含む。

0094

表Aに関して先に述べたように、入力イベントの受信時に実行される処理は、入力イベントの満了時間を決定することと、入力イベントを時間ベースのウィンドウに追加することと、ウィンドウを検査することにより、満了したイベントを同定し削除することとを含む。イベントが時間ベースのウィンドウ内にある継続時間は、入力イベントの属性の関数であってもよい。この属性の値は、イベントが異なれば異なり得るので、イベントが時間ベースのウィンドウ内にある継続時間は、イベントごとに異なり得る。したがって、イベントが時間ベースのウィンドウ内に留まる資格がある継続時間は、イベントが異なれば異なり得る。

0095

図2は、本発明の実施形態に従い、継続時間可変ウィンドウを管理するための方法を示す簡略化されたフローチャート200を示す。図2に示される処理は、1つ以上のプロセッサによって実行されるソフトウェア(たとえばコード、命令、プログラム)で実施されてもよく、ハードウェアで実施されてもよく、またはその組合わせにおいて実施されてもよい。ソフトウェアは、メモリに(たとえばメモリ素子に、非一時的なコンピュータ読取可能な記録媒体に)格納されていてもよい。図2に示される特定の一連の処理ステップは、限定を意図したものではない。

0096

ある実施形態において、図2に示される処理は、イベントストリームを介して入力イベントが受信される度に、連続クエリ実行の一部として実行されてもよい。202で、イベントストリーム内の入力イベント(タプル)が受信されてもよい。このイベントは、関連付けられた時間情報(たとえばタイムスタンプ)を有していてもよい。いくつかの例において、あるイベントに関連付けられた時間は、このイベントの受信時の時間を示すものであってもよい。

0097

204で、受信されたイベントについて、このイベントが時間ベースのウィンドウ内で保持されることになる継続時間が計算される。204の一部として、CQLコードによって時間ベースのウィンドウに対して指定された範囲パラメータが決定され継続時間を決定するのに使用される。先に説明したように、いくつかの実施形態において、連続クエリは、時間ベースのウィンドウの継続時間を、受信された入力イベントの1つ以上の属性の値の関数として定めてもよい。このようなシナリオにおいて、204で継続時間を決定することは、202で受信されたイベントの1つ以上の属性の値を決定することと、これら値の関数として継続時間を計算することとを含み得る。継続時間を計算するために使用される上記1つ以上の属性の値は、異なるイベントごとに異なり得るので、この継続時間は個々のイベントごとに異なる可能性がある。

0098

たとえば、ある実施形態において、この継続時間は、イベントの特定の属性の値に設定されてもよい。この特定の属性の値は、204で決定されてもよく、入力イベントに対するウィンドウ継続時間は、決定された値に設定される。他のいくつかの実施形態において、連続クエリは、ウィンドウの継続時間を、1つ以上の属性値に基づいて、算術式として定めてもよい。このようなシナリオにおいて、204で、受信されたイベントの1つ以上の属性値が決定されてもよく、その後、決定された値を用いて算術式の値が求められ、それにより、受信イベントの継続時間が計算されてもよい。

0099

206で、受信されたイベントについて、204で決定された継続時間に基づいて満了時間が計算される。一実施形態において、
イベントの満了時間=t+T
であり、「t」は202で受信されたイベントに関連付けられた時間(たとえばイベントの到着時間)であり、「T」は204で決定された継続時間である。

0100

208で、206で計算された満了時間は、202で受信されたイベントに関連付けられてもよい。たとえば、満了時間情報を格納しておいて、EPS102がイベントが与えられたときにこのイベントに対して計算される満了時間を容易に求めることができるようにしてもよい。

0101

210で、時間ベースのウィンドウが検査されて、満了したイベント(すなわち以前に受信したイベント)を含むか否か判断される。満了していると識別されたイベントについては、このイベントは210で時間ベースのウィンドウから削除または除去される。一実施形態において、時間ベースのウィンドウ内のイベントは、このイベントについて計算された満了時間が現在の時間と等しいかまたはそれよりも前であれば、満了しているとみなされる。上記のように、あるイベントの満了時間は(t+T)と計算される。したがって、現在の時間(tp)が(t+T)と同一かまたはそれよりも後であれば、イベントは満了しているとみなされる。満了したと判断されたイベントは次に、時間ベースのウィンドウから削除または除去される。

0102

212で、202で受信されたイベントが、時間ベースのウィンドウに挿入または追加される。214で、この処理はその後、イベントストリーム内の次のイベントを待つ。次のイベントが受信されると、処理は202から214まで繰り返される。

0103

図2に関して先に説明したように、受信された各イベントについて継続時間と満了時間が計算され、イベントはその後時間ベースのウィンドウに挿入される。さらに、時間ベースのウィンドウ内にあるイベントが検査されて、満了したイベントが識別され、満了したイベントはその後時間ベースのウィンドウから削除または除去される。このようにして、あるイベントが時間ベースのウィンドウ内に留まることになる継続時間を、イベントごとに計算し、この継続時間は、イベントの1つ以上の属性値に基づいていてもよい。イベントについて、継続時間に基づいて計算される満了時間は、イベントが満了し時間ベースのウィンドウから削除または除去されることになる時間を表わす。

0104

図3は、本発明の実施形態に従い、継続時間可変の時間ベースウィンドウ処理を実現するために使用し得るモジュールおよびデータ構造を示す。図3に示されるモジュールは、ソフトウェア、またはハードウェア、またはその組合わせにおいて実現し得る。さらに、図3に示されるモジュールおよびデータ構造は限定を意図したものではない。これに代わる実施形態は、さまざまな配置および組み合わせの、図3に示されるものよりも多いかまたは少ないモジュールを有していてもよい。

0105

図3に示される実施形態において、モジュールは、継続時間および満了時間評価器モジュール302と、時間ベースウィンドウオペレータモジュール304とを含む。継続時間および満了時間評価器モジュール302は、新たに受信した各イベントに対し、この受信イベントの継続時間および満了時間を決定するように構成されてもよい。受信イベントはその後、このイベントに対して計算された満了時間とともに、さらなる処理のために時間ベースウィンドウオペレータ304に渡されもよい。一実施形態において、継続時間および満了時間評価器302は、図2の204、206、および208に示され先に説明された処理を実行するように構成されてもよい。

0106

時間ベースウィンドウオペレータ304は、時間ベースのウィンドウを管理するように構成されてもよい。これは、新たに受信したイベントを時間ベースのウィンドウに挿入することと、時間ベースのウィンドウ内のイベントがいつ満了したか判断することと、満了したイベントを時間ベースのウィンドウから削除または除去することとを含み得る。一実施形態において、時間ベースウィンドウオペレータ304は、210および212に示され先に説明された処理を実行するように構成されてもよい。

0107

さまざまなデータ構造を用いて継続時間可変の時間ベースウィンドウを実現してもよい。一実施形態において、優先度キューが使用され、優先度はウィンドウ内のイベントに対して計算された満了時間によって指示される。新たに受信されたイベントはキューに追加され、満了したイベントはキューから削除される。キューの中にあるイベントは、それぞれに関連付けられた満了時間に基づいてソートされてもよい。一実施形態において、イベントは、満了時間がより早いイベントがキューの先頭により近く満了時間がより遅いイベントがキューの末尾により近くなるように、ソートされる。どの時点でも、優先度キューは、その時点で時間ベースのウィンドウ内にあるゼロ以上のイベントを表わすゼロ以上のイベントを含み得る。

0108

図4は、上記のように優先度キューを用いて継続時間可変の時間ベースウィンドウを実現する実施形態において時間ベースウィンドウオペレータが実行し得る処理を示す簡略化されたフローチャート400を示す。図4に示される処理は、1つ以上のプロセッサによって実行されるソフトウェア(たとえばコード、命令、プログラム)で実施されてもよく、ハードウェアで実施されてもよく、またはその組合わせにおいて実施されてもよい。ソフトウェアは、メモリに(たとえばメモリ素子に、非一時的なコンピュータ読取可能な記録媒体に)格納されていてもよい。図4に示される特定の一連の処理ステップは、限定を意図したものではない。

0109

402で、新たに受信されたイベントは、関連付けられた満了時間とともに受信されてもよい。このイベントの満了時間は、継続時間および満了時間評価器302によって既に計算されていてもよい。

0110

404で、キューは空か否か判断される。空のキューは、現在ウィンドウ内にイベントがないことを示す。404でキューが空であると判断された場合、処理は412に続き、そうでなければ処理は406に続く。

0111

406で、優先度キューの先頭にあるイベントがアクセスされる。優先度キューの中にあるイベント要素は常に、これらイベントに関連付けられた満了時間に基づいてソートされ、満了時間がより早いイベントはキューの先頭により近く、満了時間がより遅いイベントはキューの末尾により近いので、キューの先頭にあるイベントは、ウィンドウ内で満了時間が最も早いイベントを表わす。

0112

408で、406でアクセスされたイベントが満了しているか否か判断される。一実施形態において、アクセスされたイベントに関連付けられた満了時間が現在の時間に等しいかまたはそれよりも早い場合、このイベントは満了しているとみなされる。たとえば、現在の時間が10秒の標識にあるとすると、アクセスされたイベントに関連付けられた満了時間が10秒または10秒未満であれば、このアクセスされたイベントは満了しているとみなされる。408で、アクセスされたイベントが満了していると判断された場合、410で、アクセスされたイベントは優先度キューから除去または削除され、処理は404に続く。408で、アクセスされたイベントが満了していないと判断された場合、処理は412に続く。このようにして、404、406、408、および410の処理は、キューの中の満了したイベントすべてがキューから除去されるまで、または、キューが空になるまで、繰り返される。

0113

404でキューは空であると判断されるかまたは406でアクセスされたイベントが満了していないと判断された場合、処理は412に続く。412では、402で受信されたイベントが、このイベントに対して計算された満了時間に基づいてキューに追加される。イベントは、キューのソートされた(すなわち満了時間に基づいてソートされた)状態が維持されるように挿入される。次に、処理は414に続き、414でEPS102はイベントストリーム内の次のイベントを待つ。イベントが来ると、処理は402に続く。

0114

時間ベースの区画ウィンドウ
ある実施形態において、「PARTITION BY」というCQL句によって、1つのイベントストリームを、このストリームの属性に基づいて、論理的に複数のサブストリームに分割することができる。次に、範囲(range)Tのスライディングウィンドウが、各サブストリームに対して独立して計算される。

0115

たとえば、ストリームSに対し、時間ベースの区画ウィンドウは次のように定義されてもよい。

0116

S [partition by A1,..., Ak rows N range T]
ストリームSに対する上記分割スライディングウィンドウは、イベントの正の整数Nと、ストリームの属性のサブセット{A1,...Ak}とをパラメータとして取り、(1)属性A1,...Akが同等であることに基づいて、論理的にSを異なるサブストリームに分割し、(2)各サブストリームに対し独立してサイズがNで範囲/継続時間がTのイベントベースのスライディングウィンドウを計算する。イベントベースのスライディングウィンドウは独立して各区画に適用される。このようなウィンドウを「行‐時間範囲ウィンドウ」と呼んでもよい。なぜなら、ある区画に対するウィンドウについて、イベントは、「range(範囲)T」によって制御されるそれぞれのイベントに関連付けられた満了時間に基づいて、または、「rows(行)N」によって制御されるウィンドウ内のイベントの数に基づいて、ウィンドウから満了するからである。上記Nは行‐時間範囲ウィンドウ内のイベントの最大数を定める。

0117

過去の実装例では、範囲/継続時間パラメータ「T」は、一定または固定されており可変ではなかった。本発明のある実施形態では、PARTITION BY句によって作成された1つの区画のための行‐時間範囲ウィンドウ内に1つのイベントが留まる資格がある継続時間を指定する範囲/継続時間パラメータTを、異なるイベントごとに異なるようにすることができる。結果として、特定の入力イベントストリームに対しEPS102に登録されたクエリについて、1つの区画のためのウィンドウ内にイベントが留まる継続時間を、異なるイベントごとに異なるようにすることができる。

0118

たとえば、継続時間可変区画ウィンドウを有する以下のCQLクエリについて考える。
CREATE QUERY Q1 AS
SELECT *
FROM S [PARTITION BYDATA ROWS M RANGE ]
上記CQLコードは、ストリームSを、「DATA」の値に基づいて区画すなわちサブストリームに分割する。各区画について、CQLコードは行‐時間範囲ウィンドウを指定し、この行‐時間範囲ウィンドウ内のイベントの最大数は「M」であり、1つのイベントがこの行‐時間範囲ウィンドウ内に留まる資格がある継続時間は<range_expression>で表わされる。この例において、「range」についてのパラメータは、式「<range_expression>」として指定され、range_expressionは、変数または算術式であってもよい。ある実施形態において、<range_expression>は、イベント属性に基づくものであってもよい。他の実施形態において、<range_expression>は、イベントストリームスキーマの1つ以上の属性に基づき得る算術式であってもよい。

0119

例として以下のものについて考える。
FROM S [PARTITION BYDATA ROWS 2 RANGE RANGE_COLUMN]
この場合も、イベントストリームSは、属性「DATA」の値に基づいて区画に分割される。CQLコードは、各区画に対し、行‐時間範囲ウィンドウを指定する。1つの区画のためのウィンドウ内のイベントの最大数は2であり、1つのイベントがこのウィンドウ内に留まる資格がある継続時間は、イベント属性であるRANGE_COLUMNで表わされる。特定の区画に属する1つのイベントについて、このイベントがこの区画のための行‐時間範囲ウィンドウ内に留まる資格がある継続時間は、このイベントの属性RANGE_COLUMNの値と、この区画ウィンドウ内のイベントの数(最大で2)とによって制御される。したがって、属性RANGE_COLUMNの値が互いに異なるイベントは、互いに異なる継続時間ウィンドウ内に留まる資格があることになる。

0120

以下の例において、区画時間ベースの継続時間パラメータは、以下の算術式で表わされる。

0121

CREATE QUERY Q1 AS
SELECT * FROM S [PARTITION BYDATA ROWS 2 RANGE ]
この場合、イベントストリームSは、属性「DATA」の値に基づいて区画に分割される。CQLコードは、各区画に対して行‐時間範囲ウィンドウを指定し、1つのウィンドウ内のイベントの最大数は2であり、1つのイベントがこのウィンドウ内に留まる資格がある継続時間は、式<range_expression>で表わされる。この行‐時間範囲ウィンドウは、独立して各区画に適用される。ある区画の受信イベントに対して計算される満了時間はしたがって(t+range_expression_value)であり、「range_expression_value」は、イベントの受信時に<range_expression>の値を求めることによって計算される値である。

0122

以下の例は、イベントの受信時に、異なる区画に適用される継続時間可変の時間ベース範囲ウィンドウの効果を示す。この例について、入力イベントストリームSは2つの属性c1およびc2を有するスキーマを有すると想定する。

0123

S (c1 character(2), c2 bigint)
ストリームSに対する連続CQLクエリは次のように指定してもよい。

0124

SELECT * from S [PARTITION BY c1 ROWS 2 RANGE c2]
上記CQLコードによると、入力ストリームSは、属性c1の値に基づいて区画に分割される。CQLコードは、各区画に対し行‐時間範囲ウィンドウを指定し、1つの区画のためのウィンドウ内のイベントの最大数は、(「ROWS 2」なので)2であり、イベントがこの区画のためのウィンドウ内に留まる資格がある継続時間は、(「RANGE c2」なので)このイベントの属性c2の値によって決定される。

0125

以下の表Bは、タプルの入力ストリーム、ならびに、タプルの内容および入力イベントストリームSを介してイベントを受信するときのさまざまな時点において複数の区画に適用される行‐時間範囲ウィンドウの内容を示す。

0126

0127

上記表Bにおいて、左の列はスキーマ(タイムスタンプ,c1,c2)を有するストリームSを介して受信されたイベントのストリームを示す。タイムスタンプはミリ秒(msecs)で示され、1秒=1000msecsである。一実施形態において、あるイベントに関連付けられたタイムスタンプは、このイベントの受信時の時間またはこのイベントの発生時の時間を表わし得る。表Bの右の列は、各区画について、さまざまな時点における、この区画のための行‐時間範囲ウィンドウの内容(すなわちイベント)を示す。イベントの前の「+」表記は、そのイベントが区画のための行‐時間範囲ウィンドウに追加されたことを示すために使用される。イベントの前の「−」表記は、このイベントが、このイベントが満了したために、区画のための行‐時間範囲ウィンドウから削除されたことを示すために使用される。

0128

一実施形態において、イベントが受信されると、このイベントのための区画が決定される。このイベントの満了時間が計算される。イベントに対して計算される満了時間は、このイベントが満了しその区画のための行‐範囲ウィンドウから削除されることになる時間を示す。その後このイベントは、適切な区画のための行‐時間範囲ウィンドウに追加される。また、各区画のための行‐時間範囲ウィンドウが検査されて、この行‐時間範囲ウィンドウ内のいずれかのイベントを、このイベントが満了したためまたはROWS条件のために、ウィンドウから削除する必要があるか否か判断される。

0129

関連付けられたタイムスタンプが「t」であり時間範囲または継続時間が「T」であるイベントの場合、このイベントの満了時間は(t+T)である。以下のクエリの場合、範囲の値は、受信したイベントの属性c2の値に基づく。

0130

SELECT * from S [PARTITION BY c1 ROWS 2 RANGE c2]
したがって、受信したイベントについて、このイベントの満了時間は(t+c2の値)である。上記表Bにおいて、各受信イベントの満了時間(expiration time)は、このイベントの添え字として示されている。

0131

0132

表Bに示されるように、イベント(1000,a,2)が受信される。さまざまな区画のための行‐時間範囲ウィンドウ(すなわち各区画のためのウィンドウが出力するリレーションセット)が検査されて、いずれかのイベントをそのイベントが満了しているので行‐時間範囲ウィンドウから削除する必要があるか否か判断される。表Bに示される例のために、さまざまな区画のための行‐時間範囲ウィンドウは、イベント(1000,a,2)の到着前は空であると想定する。このイベントのc2属性の値に基づいて、このイベントは、属性値「a」に対応する区画(「Pa」)のための行‐時間範囲ウィンドウ内に、2秒間留まることになっていると判断される。イベント(1000,a,2)の満了時間は3秒標識(このイベントのタイムスタンプ+c2の値、すなわち1+2=3秒)であると計算される。次に、このイベント(1000,a,2)は、Paのための行‐時間範囲ウィンドウに追加される(「+」で示される)。イベント(1000,a,2)は、区画Paのための行‐時間範囲ウィンドウ内に2秒間留まる資格がある。このイベントは、3秒標識の時点で(またはこの区画ウィンドウの「ROWS 2」条件のためにそれよりも早く)行‐時間範囲ウィンドウから削除されることになっている。Paのための行‐時間範囲ウィンドウはその後検査されて、いずれかのイベントを「ROWS 2」条件のために行‐時間範囲ウィンドウから削除する必要があるか否か判断される。削除する必要があるイベントはないと判断される。

0133

関連付けられたタイムスタンプ情報が同一であるイベント(1000,a,9)が受信される。このイベントのc2属性の値に基づいて、このイベントはPaのための行‐時間範囲ウィンドウ内に9秒間留まることになっていると判断される。このイベントの満了時間は10秒標識(このイベントのタイムスタンプ+c2の値、すなわち1+9=10秒)であると計算される。次に、このイベント(1000,a,9)は、区画Paのための行‐時間範囲ウィンドウに追加される(「+」で示される)。イベント(1000,a,9)は、区画Paのための行‐時間範囲ウィンドウ内に9秒間留まる資格がある。このイベントは、10秒標識の時点で(またはこの区画ウィンドウの「ROWS 2」条件のためにそれよりも早く)行‐時間範囲ウィンドウから削除されることになっている。Paのための行‐時間範囲ウィンドウが検査されて、いずれかのイベントを、イベント(1000,a,9)を挿入して「ROWS 2」条件を満たすようにしたために、行‐時間範囲ウィンドウから削除する必要があるか否か判断される。削除する必要があるイベントはないと判断される。この時点で、区画Paのための行‐時間範囲ウィンドウは、2つのイベント(1000,a,2)および(1000,a,9)を含む。

0134

次にイベント(2000,a,1)が受信される。さまざまな区画のための行‐時間範囲ウィンドウが検査されて、いずれかのイベントをそのイベントの満了のために行‐時間範囲ウィンドウから削除する必要があるか否か判断される。満了したイベントはないと判断される。上記イベントのc2属性の値に基づいて、このイベントはPaのための行‐時間範囲ウィンドウ内に1秒間留まることになっていると判断される。イベント(a,1)の満了時間は3秒標識(このイベントのタイムスタンプ+c2の値、すなわち2+1=3)であると計算される。次に、このイベント(2000,a,1)は、区画Paのための行‐時間範囲ウィンドウに追加される(「+」で示される)。イベント(2000,a,1)は区画Paのための行‐時間範囲ウィンドウ内に1秒間留まる資格がある。このイベントは、3秒標識の時点で(またはこの区画ウィンドウの「ROWS 2」条件のためにそれよりも早く)行‐時間範囲ウィンドウから削除されることになっている。次に、Paのための行‐時間範囲ウィンドウが検査されて、いずれかのイベントを、イベント(2000,a,1)を挿入して「ROWS 2」条件を満たすようにしたために、Paのための行‐時間範囲ウィンドウから削除する必要があるか否か判断される。Paのための行‐時間範囲ウィンドウの「ROWS 2」条件のために、イベント(2000,a,1)を追加したことによってイベント(1000,a,2)は区画Paのための行‐時間範囲ウィンドウから削除されることになり、区画Paのための行‐時間範囲ウィンドウ内には、2つのイベント(1000,a,9)および(2000,a,1)が残される。

0135

次にイベント(3000,b,1)が受信される。さまざまな区画のための行‐時間範囲ウィンドウが検査されて、いずれかのイベントをそのイベントの満了のために行‐時間範囲ウィンドウから削除する必要があるか否か判断される。区画Paのための行‐時間範囲ウィンドウ内のイベント(2000,a,1)は満了しておりこのウィンドウから削除される(「−」で示される)と判断される。c2属性の値に基づいて、イベント(3000,b,1)は、属性値「b」に対応する区画(「Pb」)のための行‐時間範囲ウィンドウ内に、1秒間留まることになっていると判断される。イベント(3000,b,1)の満了時間は4秒標識(このイベントのタイムスタンプ+c2の値、すなわち3+1=4秒)であると計算される。次に、このイベント(3000,b,1)は、Pbのための行‐時間範囲ウィンドウに追加される(「+」で示される)。イベント(3000,b,1)は、区画Pbのための行‐時間範囲ウィンドウ内に1秒間留まる資格がある。このイベントは、4秒標識の時点で(またはこの区画ウィンドウの「ROWS 2」条件のためにそれよりも早く)行‐時間範囲ウィンドウから削除されることになっている。Pbのための行‐時間範囲ウィンドウが検査されて、いずれかのイベントを、イベント(3000,b,1)を挿入して「ROWS 2」条件を満たすようにしたために、行‐時間範囲ウィンドウから削除する必要があるか否か判断される。削除する必要があるイベントはないと判断される。この時点で、区画Paのための行‐時間範囲ウィンドウはイベント(1000,a,9)を含み、区画Pbのための行‐時間範囲ウィンドウはイベント(3000,b,1)を含む。

0136

次に、関連付けられたタイムスタンプが同一である3つのイベント(4000,a,2)、(4000,a,3)および(4000,b,3)が受信される。さまざまな区画のための行‐時間範囲ウィンドウが検査されて、いずれかのイベントをそのイベントの満了のために行‐時間範囲ウィンドウから削除する必要があるか否か判断される。区画Pbのための行‐時間範囲ウィンドウ内のイベント(3000,b,1)は満了しておりこのウィンドウから削除される(「−」で示される)と判断される。c2属性の値に基づいて、イベント(4000,a,2)は、Paのための行‐時間範囲ウィンドウ内に2秒間留まることになっていると判断される。イベント(4000,a,2)の満了時間は6秒標識(このイベントのタイムスタンプ+c2の値、すなわち4+2=6秒)であると計算される。次に、このイベント(4000,a,2)は、区画Paのための行‐時間範囲ウィンドウに追加される(「+」で示される)。イベント(a,2)は、区画Paのための行‐時間範囲ウィンドウ内に2秒間留まる資格があり、6秒標識の時点で(またはこの区画ウィンドウの「ROWS 2」条件のためにそれよりも早く)このウィンドウから削除されることになっている。Paのための行‐時間範囲ウィンドウが検査されて、いずれかのイベントを、イベント(4000,a,2)を挿入して「ROWS 2」条件を満たすようにしたために、行‐時間範囲ウィンドウから削除する必要があるか否か判断される。削除する必要があるイベントはないと判断される。

0137

イベント(4000,a,3)について、c2属性の値に基づいて、イベント(4000,a,3)は、Paのための行‐時間範囲ウィンドウ内に3秒間留まることになっていると判断される。イベント(4000,a,3)の満了時間は7秒標識(このイベントのタイムスタンプ+c2の値、すなわち4+3=7秒)であると計算される。次に、このイベント(4000,a,3)は、区画Paのための行‐時間範囲ウィンドウに追加される(「+」で示される)。イベント(4000,a,3)は、区画Paのための行‐時間範囲ウィンドウ内に3秒間留まる資格があり、7秒標識の時点で(またはこの区画ウィンドウの「ROWS 2」条件のためにそれよりも早く)このウィンドウから削除されることになっている。次に、Paのための行‐時間範囲ウィンドウが検査されて、いずれかのイベントを、イベント(4000,a,3)を挿入して「ROWS 2」条件を満たすようにしたために、Paのための行‐時間範囲ウィンドウから削除する必要があるか否か判断される。イベント(4000,a,3)を追加したことによってイベント(1000,a,9)は区画Paのための行‐時間範囲ウィンドウから削除されることになる(「−」で示される)。

0138

イベント(4000,b,3)について、c2属性の値に基づいて、イベント(4000,b,3)は、区画Pbのための行‐時間範囲ウィンドウ内に3秒間留まることになっていると判断される。イベント(4000,b,3)の満了時間は7秒標識(このイベントのタイムスタンプ+c2の値、すなわち4+3=7秒)であると計算される。次に、このイベント(4000,b,3)は、区画Pbのための行‐時間範囲ウィンドウに追加される(「+」で示される)。イベント(b,3)は、区画Pbのための行‐時間範囲ウィンドウ内に3秒間留まる資格があり、7秒標識の時点で(またはこの区画ウィンドウの「ROWS 2」条件のためにそれよりも早く)このウィンドウから削除されることになっている。Pbのための行‐時間範囲ウィンドウが検査されて、いずれかのイベントを、イベント(4000,b,3)を挿入して「ROWS 2」条件を満たすようにしたために、この行‐時間範囲ウィンドウから削除する必要があるか否か判断される。削除する必要があるイベントはないと判断される。この時点で、区画Paのための行‐時間範囲ウィンドウはイベント(4000,a,2)および(4000,a,3)を含み、区画Pbのためのウィンドウはイベント(4000,b,3)を含む。

0139

次にイベント(5000,b,2)が受信される。さまざまな区画のための行‐時間範囲ウィンドウが検査されて、いずれかのイベントをそのイベントの満了のために行‐時間範囲ウィンドウから削除する必要があるか否か判断される。満了したイベントはないと判断される。c2属性の値に基づいて、このイベント(5000,b,2)は区画Pbのための行‐時間範囲ウィンドウ内に2秒間留まることになっていると判断される。イベント(5000,b,2)の満了時間は7秒標識(このイベントのタイムスタンプ+c2の値、すなわち5+2=7)であると計算される。次に、イベント(5000,b,2)は、区画Pbのための行‐時間範囲ウィンドウに追加される(「+」で示される)。イベント(5000,b,2)は区画Pbのための行‐時間範囲ウィンドウ内に2秒間留まる資格があり、7秒標識の時点で(またはこの区画ウィンドウの「ROWS 2」条件のためにそれよりも早く)このウィンドウから削除されることになっている。区画Pbのための行‐時間範囲ウィンドウが検査されて、いずれかのイベントを、イベント(50000,b,2)を挿入して「ROWS 2」条件を満たすようにしたために、行‐時間範囲ウィンドウから削除する必要があるか否か判断される。削除する必要があるイベントはないと判断される。この時点で、区画Paのための行‐時間範囲ウィンドウはイベント(4000,a,2)および(4000,a,3)を含み、区画Pbのための行‐時間範囲ウィンドウはイベント(4000,b,3)および(5000,b,2)を含む。

0140

次に、関連付けられたタイムスタンプが6000ミリ秒であるハートビートイベントが受信される。一実施形態において、ハートビートイベントは、単に時間の経過情報を伝えるために使用される特殊な入力イベントである。ハートビートイベントには、他の属性の値はない。イベント処理システムを、システムのユーザによって構成できる周期的な間隔でハートビートを自動的に送信するように構成してもよい。そうすれば、ハートビートイベントは、その継続時間内に他の実際のイベントが受信されなければ(すなわちイベントストリームはその継続時間サイレント状態である)、自動的に生成され周期的な間隔で送信される。このハートビートイベントが受信されると、ウィンドウに関連する処理が実行される。したがって、ハートビートイベント(6000,<heartbeat_event>)が受信されたとき、さまざまな区画のための行‐時間範囲ウィンドウが検査されて、いずれかのイベントをそのイベントが満了しているので行‐時間範囲ウィンドウから削除する必要があるか否か判断される。区画Paのための行‐時間範囲ウィンドウ内のイベント(4000,a,2)は満了しておりこのウィンドウから削除される(「−」で示される)と判断される。この時点で、区画Paのための行‐時間範囲ウィンドウはイベント(4000,a,3)を含み、区画Pbのための行‐時間範囲ウィンドウはイベント(4000,b,3)および(5000,b,2)を含む。

0141

次にイベント(7000,c,1)が受信される。さまざまな区画のための行‐時間範囲ウィンドウが検査されて、いずれかのイベントをそのイベントの満了のために行‐時間範囲ウィンドウから削除する必要があるか否か判断される。区画Paのための行‐時間範囲ウィンドウ内のイベント(4000,a,3)ならびに区画Pbのための行‐時間範囲ウィンドウ内のイベント(4000,b,3)および(5000,b,2)は満了しておりウィンドウから削除される(「−」で示される)と判断される。c2属性の値に基づいて、イベント(7000,c,1)は、属性値「c」に対応する区画(「Pc」)のための行‐時間範囲ウィンドウ内に、1秒間留まることになっていると判断される。イベント(7000,c,1)の満了時間は8秒標識(このイベントのタイムスタンプ+c2の値、すなわち7+1=8秒)であると計算される。次に、このイベント(7000,c,1)は、属性値「c」に対応する区画Pcのための行‐時間範囲ウィンドウに追加される(「+」で示される)。イベント(7000,c,1)は、区画Pcのための行‐時間範囲ウィンドウ内に1秒間留まる資格があり、8秒標識の時点で(またはこの区画ウィンドウの「ROWS 2」条件のためにそれよりも早く)ウィンドウから削除されることになっている。区画Pcのための行‐時間範囲ウィンドウが検査されて、いずれかのイベントを、イベント(7000,c,1)を挿入して「ROWS 2」条件を満たすようにしたために、行‐時間範囲ウィンドウから削除する必要があるか否か判断される。削除する必要があるイベントはないと判断される。この時点で、区画PaおよびPbのための行‐時間範囲ウィンドウは空であり区画Pcのための行‐時間範囲ウィンドウはイベント(7000,c,1)を含む。

0142

すべてのシステムがハートビートイベント送信機構を有する必要はないことに注意しなければならない。ハートビートイベントを送信しないシステムにおいて、ウィンドウに関連する処理は、イベントストリームを介して通常の入力イベントが受信されると実行される。たとえば、表Bに示されるイベントストリームの場合、ハートビートイベント送信機能がないシステムでは、6000ミリ秒標識および7000ミリ秒標識の時点で実行される処理は、新たなイベント(7000,c,1)が受信されたときに7000ミリ秒標識の時点で実行されてもよい。

0143

次に、ハートビートイベント(8000,<heartbeat_event>)が受信される。さまざまな区画のための行‐時間範囲ウィンドウが検査されて、いずれかのイベントをそのイベントの満了のために行‐時間範囲ウィンドウから削除する必要があるか否か判断される。区画Pcのための行‐時間範囲ウィンドウ内のイベント(7000,c,1)は満了しておりウィンドウから削除される(「−」で示される)と判断される。この時点で、区画Pa、Pb、およびPcのための行‐時間範囲ウィンドウは空である。

0144

表Bに関して先に説明したように、入力イベントの受信時に実行される処理は、この入力イベントの満了時間を決定することと、このイベントが属する区画を決定することと、この入力イベントをこの区画のための行‐時間範囲ウィンドウに追加することと、さまざまな区画のための行‐時間範囲ウィンドウを検査して、満了したイベント、または、ROWS条件の結果として区画ウィンドウから除去する必要があるイベントを識別し削除する。ある区画のための行‐時間範囲ウィンドウ内に1つのイベントが留まる継続時間は、入力イベントの属性の関数であってもよく、これは異なる入力イベントごとに異なり得る。したがって、イベントがある区画のための行‐時間範囲ウィンドウ内に留まる資格がある継続時間は、異なるイベントごとに異なり得る。

0145

図5は、本発明の実施形態に従い、区画のための継続時間可変ウィンドウを管理するための方法を示す簡略化されたフローチャート500を示す。図5に示される処理は、1つ以上のプロセッサによって実行されるソフトウェア(たとえばコード、命令、プログラム)で実施されてもよく、ハードウェアで実施されてもよく、またはその組合わせにおいて実施されてもよい。ソフトウェアは、メモリに(たとえばメモリ素子に、非一時的なコンピュータ読取可能な記録媒体に)格納されていてもよい。図5に示される特定の一連の処理ステップは、限定を意図したものではない。

0146

ある実施形態において、図5に示される処理は、イベントストリームを介して入力イベント(実際のイベントまたはハートビートイベントであり得る)が受信される度に、連続クエリ実行の一部として実行されてもよい。502で、イベントストリーム内の入力イベント(タプル)が受信されてもよい。このイベントは、関連付けられた時間情報(たとえばタイムスタンプ)を有していてもよい。いくつかの例において、あるイベントに関連付けられた時間は、このイベントの受信時の時間を示すものであってもよい。

0147

504で、受信されたイベントについて、このイベントが区画のための行‐時間範囲ウィンドウ内に留まる資格がある継続時間が計算される。504の一部として、CQLコードによって行‐時間範囲ウィンドウに対して指定された範囲パラメータが決定され継続時間を決定するのに使用される。先に説明したように、いくつかの実施形態において、連続クエリは、この継続時間を、受信された入力イベントの1つ以上の属性の値の関数として定めてもよい。このようなシナリオにおいて、504で継続時間を決定することは、502で受信されたイベントの1つ以上の属性の値を決定することと、このイベントについての継続時間をこれら値の関数として計算することとを含み得る。継続時間の計算に使用される1つ以上の属性の値は、異なるイベントごとに異なり得るので、この継続時間は個々のイベントごとに異なる可能性がある。

0148

たとえば、ある実施形態において、この継続時間は、イベントの特定の属性の値に設定されてもよい。この特定の属性の値は、504で決定されてもよく、入力イベントに対する行‐時間範囲ウィンドウは、決定された値に設定される。他のいくつかの実施形態において、連続クエリは、行‐時間範囲ウィンドウの継続時間を、1つ以上の属性値に基づいて算術式として定めてもよい。このようなシナリオにおいて、504で、受信されたイベントの1つ以上の属性値が決定されてもよく、その後、決定された値を用いて算術式の値が求められ、それにより、受信されたイベントの継続時間が計算されてもよい。

0149

506で、受信されたイベントについて、504で決定された継続時間に基づいて満了時間が計算される。一実施形態において、
イベントの満了時間=t+T
であり、「t」は502で受信されたイベントに関連付けられた時間(たとえばイベントの到着時間)であり、「T」は504で決定された継続時間である。

0150

508で、506で計算された満了時間は、502で受信されたイベントに関連付けられてもよい。たとえば、満了時間情報を格納しておいて、EPS102がイベントを与えられたときにこのイベントについて計算される満了時間を容易に求めることができるようにしてもよい。

0151

510で、既存の各区画について、この区画のための行‐時間範囲ウィンドウが検査されて、満了したイベントが識別され削除される。満了していると識別されたイベントについては、このイベントはその区画の行‐時間範囲ウィンドウから削除または除去される。一実施形態において、行‐時間範囲ウィンドウ内のイベントは、このイベントについて計算された満了時間が現在の時間と等しいかまたはそれよりも前であれば、満了しているとみなされる。上記のように、あるイベントの満了時間は(t+T)と計算される。したがって、現在の時間(tp)が(t+T)と同一かまたはそれよりも後であれば、イベントは、満了しているとみなされる。

0152

512で、502で受信された入力イベントについて区画が決定される。このイベントが属する区画は、このイベントの属性の値に応じて決まるものであってもよい。したがって、512で、受信された入力イベントについて、入力イベントストリームを区画に分割するために使用された属性の値が検査され、この値に基づいて、イベントが属する区画が求められる。

0153

514で、502で受信されたイベントが、512で決定された区画の行‐時間範囲ウィンドウに挿入または追加される。

0154

上記のように、以下の句
S [partition by A1,..., Ak rows N range T]
の場合、区画からのイベントの除去は、このイベントの満了時間に基づいて、または、行‐時間範囲ウィンドウ内のイベントの総数に基づいて制御される。たとえば、「...rows N...」は、最大「N」個のイベントを1つの区画のための行‐時間範囲ウィンドウ内に入れることが可能であることを意味し、新たなイベントが受信されてこのウィンドウに追加されたときに、「rows N」という条件を満たすためにこの区画内の最も早いイベントが行‐時間範囲ウィンドウから削除される。したがって、516では、512で決定された区画のための行‐時間範囲ウィンドウが検査されて、「rows N」条件を満たすためにイベントが識別され削除される。いくつかの実施形態において、516の処理は、514の処理よりも前に実行されてもよく、または、これに代えて、514および516で実行される処理は一緒に実行されてもよい。

0155

518で、処理はその後イベントストリーム内の次のイベントを待つ。次のイベントが受信されると、処理は502から繰り返される。

0156

図3に示され先に説明されたさまざまなモジュールは、本発明の実施形態に従う区画ベースで継続時間可変の時間ベースウィンドウ処理においても使用し得る。一実施形態において、継続時間および満了時間評価器モジュール302を、図5の502、504、506、および508の処理を実行するように適応させてもよい。時間ベースウィンドウオペレータモジュール304は、上記さまざまな機能に加えて、場合によっては複数の区画行‐時間範囲ウィンドウを管理するように適応させてもよい。たとえば、時間ベースウィンドウオペレータ304は、図5の510、512、514、および516に従う処理を実行するように構成されてもよい。

0157

さまざまなデータ構造を用いてさまざまな区画のための行‐時間範囲ウィンドウを実現してもよい。一実施形態において、一組の優先度キューが使用されてもよく、各優先度キューは、特定の区画のための行‐時間範囲ウィンドウに対応する。ある区画のための行‐時間範囲ウィンドウを表わす優先度キューにおいて、優先度は行‐時間範囲ウィンドウ内のイベントに対して計算された満了時間によって指示されてもよい。ある区画に属する、新たに受信されたイベントは、この区画のための優先度キューに追加される。ある区画について、満了したイベントおよび/または「row N」条件のために区画の行‐時間範囲ウィンドウから除去されるイベントは、対応する優先度キューから削除される。

0158

ある区画のためのキューの中において、このキューの中にあるイベントは、それぞれに関連付けられた満了時間に基づいてソートされてもよい。一実施形態において、イベントは、満了時間がより早いイベントがキューの先頭により近く満了時間がより遅いイベントがキューの末尾により近くなるように、ソートされる。どの時点でも、ある区画のための優先度キューは、その時点でその区画のためのウィンドウ内にあるゼロ以上のイベントを表わすゼロ以上のイベントを含み得る。

0159

図6は、本発明の実施形態に従い、優先度キューを用いて区画のための継続時間可変ウィンドウを扱うために時間ベースウィンドウオペレータ304が実行し得る処理を示す簡略化されたフローチャート600を示す。図6に示される処理は、1つ以上のプロセッサによって実行されるソフトウェア(たとえばコード、命令、プログラム)で実施されてもよく、ハードウェアで実施されてもよく、またはその組合わせにおいて実施されてもよい。ソフトウェアは、メモリに(たとえばメモリ素子に、非一時的なコンピュータ読取可能な記録媒体に)格納されていてもよい。図6に示される特定の一連の処理ステップは、限定を意図したものではない。

0160

602で、新たに受信された入力イベントは、関連付けられた満了時間とともに受信されてもよい。このイベントの満了時間は、継続時間および満了時間評価器302によって既に計算されていてもよい。

0161

604、606、608、610、614、および612による処理は、既存の各区画に対して実行される。604で、未処理の区画のための行‐時間範囲ウィンドウに対応する優先度キューがアクセスされる。606で、このキューが空か否か判断される。空のキューは、この区画の行‐時間範囲ウィンドウ内に現在イベントがないことを示す。606でキューが空であると判断された場合、処理は614に続き、614で、次の未処理の区画に対する処理が604から再び開始される。606でキューが空でないと判断された場合、処理は608に続く。

0162

608で、処理されている区画のための優先度キューの先頭にあるイベントがアクセスされる。この区画のための優先度キューの中にあるイベント要素は常に、これらイベントに関連付けられた満了時間に基づいてソートされ、満了時間がより早いイベントはキューの先頭により近く、満了時間がより遅いイベントはキューの末尾により近いので、キューの先頭にあるイベントは、その区画のウィンドウ内で満了時間が最も早いイベントを表わす。

0163

610で、608でアクセスされたイベントが満了しているか否か判断される。一実施形態において、アクセスされたイベントに関連付けられた満了時間が現在の時間に等しいかまたはそれよりも早い場合、このイベントは満了しているとみなされる。たとえば、現在の時間が10秒の標識にあるとすると、アクセスされたイベントに関連付けられた満了時間が10秒または10秒未満であれば、このアクセスされたイベントは満了しているとみなされる。610で、アクセスされたイベントが満了していると判断された場合、612で、アクセスされたイベントはこの区画のための優先度キューから除去または削除され、処理は606に続く。610で、アクセスされたイベントが満了していないと判断された場合、処理は614に続く。このようにして、604、606、608、610、612、および614の処理は、さまざまな区画のための行‐時間範囲ウィンドウから、満了したイベントすべてが削除されるまで、繰り返される。その後処理は616に続く。

0164

616で、602で受信されたイベントに対し区画が決定される。このイベントのための区画は、入力されたイベントの属性の値に基づいて決定されてもよい。

0165

618で、616で決定された区画のための行‐時間範囲ウィンドウに対応する優先度キューがアクセスされる。620で、618でアクセスされた優先度キューにイベントが挿入または追加される。一実施形態において、キューの要素がこのキューの中のイベントに対して計算された満了時間に基づいてソートされた状態を保つように、イベントはこのイベントのために計算された満了時間に基づいて挿入されてもよい。

0166

ある実施形態において、ハッシュ関数を用いて、616で決定された特定の区画に対応するキューがアクセスされてもよい。入力イベントストリームを区画に分割するために使用された属性の値が入力としてハッシュ関数に与えられてもよく、そうすると、ハッシュ関数はその区画のための行‐時間範囲に対応するキューに対するリファレンス(たとえばポインタ)を返す。

0167

622で、618でアクセスされたキューが処理されて、「rows N」条件を満たすためにキューのイベントが識別されキューから削除される。624で、処理は、イベントストリーム内の次のイベントを待つ。次のイベントが受信されると、処理は602から繰り返される。

0168

上記のやり方で、1つのイベントが時間ベースのウィンドウ内に留まる資格がある継続時間がイベントごとに異なるようにすることができる。さらにある実施形態において、あるイベントの継続時間は、このイベント自体の1つ以上の属性に基づくものでありかつこの1つ以上の属性の関数であってもよい。あるイベントが時間ベースのウィンドウ(通常の時間ベースのウィンドウまたは区画のための行‐時間範囲ウィンドウのいずれか)内に留まる資格がある継続時間は、イベントごとに異なるようにすることができ、したがってイベント固有のものである。

0169

イベントがそれぞれ異なる継続時間ベースのウィンドウ内に留まるという状況は、数通りある。1つの状況は、2つのイベントが同時に受信された場合(たとえば関連付けられたタイムスタンプが同一)、これらのイベントが時間ベースのウィンドウ内にある継続時間は互いに異なることがある。その結果、これら2つのイベントの満了時間も互いに異なることがある。たとえば、あるイベントストリームに対して、時間ベースのウィンドウの継続時間がこのストリームのためのスキーマ内の属性「attr」の値の関数である、連続クエリが定められる場合がある。2つのイベントのうち第1のイベント(e1)が時間t1で受信され第2のイベント(e2)も時間t1で受信される場合について考える。さらに、e1の属性「attr」の値がa1でありe2の属性「attr」の値がa2でありa2はa1と同一でないと仮定する。そうすると次のようになる。

0170

e1のための時間ベースのウィンドウの継続時間=a1
e1の満了時間=t1+a1
e2のための時間ベースのウィンドウの継続時間=a2
e2の満了時間=t1+a2
a1とa2は同一でないので、e1の満了時間(すなわちt1+a1)は、e2の満了時間(すなわちt1+a2)と同一ではない。このため、これら2つのイベントは同時に受信されているが(すなわち関連付けられた時間情報が同一)、2つのイベントは異なる2つの時間に満了し、したがってウィンドウ内に留まる継続時間が互いに異なる。これは、同時に受信した2つのイベントは常に同時にウィンドウから満了する、以前の時間ベースウィンドウの実装例では不可能であった。

0171

継続時間可変の時間ベースウィンドウのもう1つの状況として、先に受信されたイベントに関連付けられた満了時間が後に受信されたイベントに関連付けられた満了時間よりも遅い、すなわち言い換えると、後に受信されたイベントが先に受信されたイベントよりも早くウィンドウから満了する可能性がある。たとえば、上記例において、第1のイベント(e1)が時間t1に受信され第2のイベント(e2)がt1よりも後のt2で受信されたとする。さらに、e1の属性「attr」の値がa1でありe2の属性「attr」の値がa2であると仮定する。そうすると次のようになる。

0172

e1のための時間ベースのウィンドウの継続時間=a1
e1の満了時間=t1+a1
e2のための時間ベースのウィンドウの継続時間=a2
e2の満了時間=t2+a2
e2の満了時間(すなわちt2+a2)がe1の満了時間(すなわちt1+a1)よりも前、すなわち(t2+a2)が(t1+a1)よりも前である可能性がある。したがって、イベントe2は後で到着したのにe1よりも前に満了する。これは、以前の時間ベースウィンドウの実装例では不可能であった。以前の実装例では、先に受信されたイベントは、常に後に受信されたイベントよりも前に満了し、その理由はこれら2つのイベントのウィンドウ継続時間が同一であるからである。

0173

継続時間可変の時間ベースウィンドウによって、ユーザは、あるイベントがウィンドウ内にある継続時間を制御することができ、この継続時間はイベントごとに異なるようにすることができる。これは、異なるさまざまな応用例において有益である。たとえば、製品関連情報に関するイベントのストリームを処理するように構成された応用例を考える。各製品の有効期間がそれぞれ異なるということが起こり得る(たとえば生鮮食品の有効期間は非生鮮食品の有効期間よりも短い)。製品の有効期間に基づいて時間ベースのウィンドウの継続時間を変える必要があるアプリケーションでは、ストリームのためのスキーマは、有効期間が属性としてスキーマに加えられるように指定されてもよい。そうすると、あるイベントのための時間ベースのウィンドウは、有効期間という属性によって特定される値に基づくことになるであろう。継続時間可変の時間ベースウィンドウを利用することができる他の応用例は、例として、関連付けられているアラームタイマがそれぞれ異なるタスクのためのイベントに関連する応用例、完了日がそれぞれ異なるタスクのためのイベントに関連する応用例などであるが、これらに限定されない。

0174

上記のように、あるイベントについてのウィンドウ継続時間は、このイベント自体の1つ以上の属性に基づくものであってもよい。ある実施形態において、継続時間の基になる属性は、入力イベントストリームスキーマ自体の一部であってもよい。しかしながら、いくつかの実施形態において、このような属性は受信された入力ストリームの一部でなくてもよい。このような一実施形態において、ウィンドウの継続時間を決定するために使用される1つ以上の属性は、元のストリームから新たなストリームを導き出すことによってイベントストリームに追加されてもよく、継続時間計算の基になる1つ以上の属性は、導き出されたイベントストリームのスキーマの一部である。

0175

図7は、本発明の実施形態に従い使用し得るシステム環境700の構成要素を示す簡略化されたブロック図である。図に示されているように、システム環境700は、1つ以上のクライアント計算装置702、704、706、708を含み、これら装置は、ウェブブラウザ、専用のクライアント(たとえばOracle Forms)等のクライアントアプリケーションを操作するように構成されている。さまざまな実施形態において、クライアント計算装置702、704、706、および708は、イベント処理システム712と情報をやり取りし得る。

0176

クライアント計算装置702、704、706、708は、汎用のパーソナルコンピュータ(例として、さまざまなバージョンのMicrosoft Windows(登録商標)および/またはApple Macintosh(登録商標)オペレーティングシステムを実行するパーソナルコンピュータおよび/またはラップトップコンピュータを含む)、携帯電話もしくはPDA(Microsoft Windows Mobile等のソフトウェアを実行し、インターネット電子メール、SMS、ブラックベリー(Blackberry)(登録商標)、またはその他の通信プロトコル使用可能)、および/またはさまざまな市販のUNIX(登録商標)もしくはUNIXのようなオペレーティングシステム(さまざまなGNU/Linux(登録商標)オペレーティングシステムを含むがこれに限定されない)のいずれかを実行するワークステーションコンピュータであってもよい。これに代えて、クライアント計算装置702、704、706、および708は、ネットワーク(たとえば以下で説明するネットワーク710)を通して通信可能なシンクライアントコンピュータ、インターネットを使用可能なゲーム機、および/またはパーソナルメッセージングデバイス等のその他の電子デバイスであってもよい。典型的なシステム環境700が4つのクライアント計算装置とともに示されているが、クライアント計算装置の数はいくつであってもそれらをサポートし得る。センサ等を有する装置のような他の装置が、システム712と情報をやり取りしてもよい。

0177

ネットワーク710は、クライアント702、704、706、および708とイベント処理システム712との間でのデータの通信および交換を容易にし得る。ネットワーク710は、TCP/IP、SNAIPX、AppleTalk等を含むがこれらに限定されないさまざまな市販のプロトコルのいずれかを用いたデータ通信をサポートできる、当業者によく知られているネットワークであれば、どのような種類のネットワークであってもよい。単なる例として、ネットワーク710は、イーサネット(登録商標)ネットワーク、トークンリングネットワーク等のローカルエリアネットワーク(LAN)、ワイドエリアネットワークバーチャルプライベートネットワーク(VPN)を含むがこれに限定されないバーチャルネットワーク、インターネット、イントラネットエクストラネット公衆電話交換回線網(PSTN)、赤外線ネットワークワイヤレスネットワーク(たとえば、IEEE 802.1Xプロトコル群のいずれかの下で動作するネットワーク、当該技術分野において公知のブルートゥース(登録商標)プロトコル、および/またはその他のワイヤレスプロトコル)、および/または、これらおよび/または他のネットワークの任意の組合わせであってもよい。

0178

イベント処理システム712は1つ以上のコンピュータおよび/またはサーバを含み得る。これは、汎用コンピュータ、専用のサーバコンピュータ(例として、PCサーバUNIXサーバミッドレンジサーバ、メインフレームコンピュータ、ラックマウント式(rack-mounted)のサーバ等を含む)、サーバファームサーバクラスタ、またはその他の適切な配置および/または組み合わせであってもよい。さまざまな実施形態において、システム712は、本願のこれまでの開示において説明された1つ以上のサービスまたはソフトウェアアプリケーションを実行するようにされていてもよい。

0179

システム712は、上述したオペレーティングシステムのうちのいずれかおよび任意の市販のサーバオペレーティングシステムを含むオペレーティングシステムを実行してもよい。また、システム712は、HTTPサーバFTPサーバCGIサーバ、Javaサーバ、およびデータベースサーバ等を含むさまざまなその他のサーバアプリケーション、および/またはミッドティア(mid-tier)アプリケーションのうちのいずれかを実行してもよい。典型的なデータベースサーバは、Oracle、Microsoft、Sybase、IBM等から市販されているものを含むが、これらに限定されない。

0180

また、システム環境700は1つ以上のデータベース714および716を含み得る。データベース714および716はさまざまな場所に存在し得る。例として、データベース714および716のうちの1つ以上は、システム712に対してローカルな(および/またはシステム712内に常駐している)記録媒体に存在していてもよい。これに代えて、データベース714および716は、システム712から離れていてネットワークベースまたは専用回線を介してシステム712と通信してもよい。一組の実施形態において、データベース714および716は、当業者によく知られているストレージエリアネットワーク(SAN)に存在していてもよい。同様に、システム712による機能を実行するために必要なファイルは、必要に応じて、システム712に対してローカルにおよび/または遠隔で格納されてもよい。一組の実施形態において、データベース714および716は、SQLフォーマットコマンドに応答してデータを格納し、更新し、取出すようにされている、Oracle 11g等のリレーショナルデータベースを含み得る。

0181

図8は、本発明のある実施形態に従い使用し得るコンピュータシステム800の簡略化されたブロック図である。たとえば、システム800を用いて図1に示されるイベント処理システム100を実現してもよい。バス824を介して電気的に接続し得るさまざまな構成要素を含むコンピュータシステム800が示されている。この構成要素は、1つ以上の処理部802と、入力サブシステム804と、出力サブシステム806と、記憶装置808と、コンピュータ読取可能な記録媒体810に接続されたコンピュータ読取可能記媒体リーダ812と、通信サブシステム814と、処理加速サブシステム816と、ワーキングメモリ818とを含み得る。

0182

バスサブシステム824は、コンピュータシステム800のさまざまな構成要素およびサブシステムを意図された通りに相互通信させるためのメカニズムを提供する。バスサブシステム824は概略的に1本のバスとして示されているが、これに代わるバスサブシステムの実施形態は複数のバスを利用してもよい。

0183

入力サブシステム804は、マウスキーボードポインティングデバイスタッチパッド等といった1つ以上の入力装置を含み得る。一般的に、入力サブシステム804は、コンピュータシステム800に情報を入力するための装置またはメカニズムを含み得る。

0184

出力サブシステム806は、コンピュータシステム800から情報を出力するための1つ以上の出力装置を含み得る。出力装置の例は、表示装置プリンタ投影装置等を含むがこれらに限定されない。一般的に、出力サブシステム806は、コンピュータシステム800から情報を出力するための装置またはメカニズムを含み得る。

0185

処理部802は、1つ以上のプロセッサ、プロセッサの1つ以上のコア、およびその組み合わせ等を含み得る。いくつかの実施形態において、処理部802は、汎用一次プロセッサと、グラフィックプロセッサデジタル信号プロセッサ等といった1つ以上の専用コプロセッサとを含み得る。いくつかの実施形態において、処理部802のうちのいくつかまたはすべてを、特定用途向け集積回路ASIC)またはフィールドプログラマブルゲートアレイFPGA)のようなカスタマイズされた回路を用いて実現することができる。いくつかの実施形態において、このような集積回路は、回路そのものに格納された命令を実行する。他の実施形態において、処理部802は、ワーキングメモリ818にまたは記憶装置808に格納された命令を実行してもよい。さまざまな実施形態において、処理部802は、多様なプログラムまたはコード命令を実行することができ、現在実行している複数のプログラムまたはプロセスを管理することができる。どの時点でも、これから実行するプログラムコードのうちのいくつかまたはすべては、システムワーキングメモリ818、記憶装置808、および/またはコンピュータ読取可能な記録媒体810に常駐していてもよい。適切なプログラミングによって、処理部802は、イベントストリームに関連する処理を実行するための上記さまざまな機能を提供することができる。いくつかの実施形態において、コンピュータシステム800はまた、デジタル信号プロセッサ(DSP)、専用プロセッサ、および/またはそれと同様のものを含み得る処理加速部816を含んでいてもよい。

0186

記憶装置808は、ディスクドライブ光学式記憶装置等のメモリデバイス、ならびに、プログラム可能で、一瞬で更新可能で(flash-updatable)、および/またはそれと同じようなことが可能なランダムアクセスメモリ(RAM)および/または読出専用メモリ(ROM)等のソリッドステート記憶装置を含み得る。処理部802によって実行されると上記機能を提供するソフトウェア(プログラム、コードモジュール、命令)は、記憶装置808に格納されてもよい。記憶装置808も、本発明の実施形態に従い使用されるデータを格納するためのリポジトリを提供し得る。

0187

コンピュータ読取可能記録媒体リーダ812はさらに、コンピュータ読取可能な記録媒体810に接続されてもよい。コンピュータ読取可能な記録媒体810はともに、(かつ任意に記憶装置808と組合わせて)リモート式ローカル式固定式および/または着脱交換式の記憶装置、および、一時的および/またはより永続的にコンピュータ読取可能な情報を収容するための記録媒体を総合的に意味している。

0188

通信サブシステム814によって、ネットワーク710および/またはシステム環境700に関連する上述のその他のコンピュータと、データをやり取りすることが可能であってもよい。通信サブシステム814は、コンピュータシステム800からの他のシステムからデータを受信しこのシステムにデータを送信するためのインターフェイスの役割を果たす。通信は、有線または無線プロトコルを用いて提供し得る。たとえば、通信サブシステム814によって、コンピュータ800がインターネットを介してクライアント装置と接続できるようにしてもよい。通信サブシステム814は、モデムネットワークカード無線または有線)、赤外線通信装置GPS受信機等を含み得る。

0189

ワーキングメモリサブシステム818は、プログラム実行中の命令およびデータの格納のためのメインランダムアクセスメモリ(RAM)と、固定命令が格納される読出専用メモリ(ROM)とを含み得る。オペレーティングシステム820および/またはアプリケーションプログラム(クライアントアプリケーション、ウェブブラウザ、ミッドティアアプリケーション、RDBMS等であってもよい)等のその他のコード822は、ワーキングメモリ818に格納されていてもよい。典型的な実施形態において、ワーキングメモリ818は、上記のようにイベントを処理し継続時間可変のウィンドウ処理を可能にするために使用される、実行可能なコードおよび関連するデータ構造(キャッシュ等)を含み得る。

0190

コンピュータシステム800の代替実施形態は、数多くの変形を伴う、上記構成要素よりも多いまたは少ない構成要素を有し得ることが、理解されるはずである。たとえば、カスタマイズされたハードウェアを使用してもよく、および/または特定の要素を、ハードウェア、ソフトウェア(アプレット等のポータブルソフトウェアを含む)、またはこれら双方で実現してもよい。さらに、ネットワーク入出力装置等の他の計算装置との接続を用いてもよい。

0191

図9は、本発明のある実施形態に従い使用し得る計算装置900の簡略化されたブロック図である。計算装置900のブロックを、ハードウェア、ソフトウェア、またはハードウェアとソフトウェアの組み合わせにおいて実現することによって本発明の原理を実行してもよい。図9に示されるブロックを組合わせるまたはサブブロックに分離することによって上記本発明の原理を実行してもよいことが、当業者には理解される。したがって、本明細書での説明は、本明細書に記載の機能ブロックの可能な組み合わせまたは分離またはさらに他の定義を裏付け得るものである。

0192

図9に示されるように、示されている計算装置900は、第1の決定部902および第2の決定部903を含む。任意で、計算装置900は、受信部901、第1の除去部904、および第2の除去部905も含むことができる。

0193

一実施形態において、受信部901は、イベントストリームを介して第1のイベントおよび第2のイベントを受信するように構成し得る。第1の決定部902は、イベントストリームを介して受信した第1のイベントの第1の継続時間を決定するように構成し得る。第1の継続時間は、イベントストリームに対して指定された時間ベースのウィンドウ内に第1のイベントが留まる資格がある継続時間を示す。第2の決定部903は、イベントストリームを介して受信した第2のイベントの第2の継続時間を決定するように構成し得る。第2の継続時間は、時間ベースのウィンドウ内に第2のイベントが留まる資格がある継続時間を示す。第2の継続時間は第1の継続時間と異なっていてもよい。

0194

一実施形態において、第1の除去部904は、第1の時間イベントが時間ベースのウィンドウ内に第1の継続時間あった後に時間ベースのウィンドウから第1のイベントを除去するように構成し得る。第2の除去部905は、第2の時間イベントが時間ベースのウィンドウ内に第2の継続時間あった後に時間ベースのウィンドウから第2のイベントを除去するように構成し得る。

0195

一実施形態において、第1のイベントは関連付けられた第1の時間を有し、第2のイベントは関連付けられた第2の時間を有し、第1の時間は第2の時間と同一である。

0196

一実施形態において、第1のイベントは関連付けられた第1の時間を有し、第2のイベントは関連付けられた第2の時間を有し、第1の時間は第2の時間と異なる。

0197

一実施形態において、第1の決定部902は、第1の継続時間を決定するときに第1のイベントの1つ以上の属性の1つ以上の値に基づいて第1の継続時間を計算するように構成し得る。第2の決定部903は、第2の継続時間を決定するときに第2のイベントの1つ以上の属性の1つ以上の値に基づいて第2の継続時間を計算するように構成し得る。

0198

一実施形態において、第1の決定部902は、第1のイベントの第1の属性の値に基づいて、第1のイベントのための第1の区画を決定するように構成し得る。第2の決定部903は、第2のイベントの第1の属性の値に基づいて、第2のイベントが第1の区画に属すると決定するように構成し得る。この時間ベースのウィンドウは第1の区画のためのものである。

0199

一実施形態において、第1の決定部902は、第1のイベントに関連付けられた第1の時間と第1の継続時間とに基づいて、第1のイベントの第1の満了時間を決定するように構成し得る。第2の決定部903は、第2のイベントに関連付けられ第2の時間と第2の継続時間とに基づいて、第2のイベントの第2の満了時間を決定するように構成し得る。第1の除去部904は、第1の満了時間の到来時または到来後に時間ベースのウィンドウから第1のイベントを除去するように構成し得る。第2の除去部905は、第2の満了時間の到来時または到来後に時間ベースのウィンドウから第2のイベントを除去するように構成し得る。

0200

本発明の特定の実施形態について説明してきたが、さまざまな修正、変更、代替構成、および均等物も、本発明の範囲に包含される。本発明の実施形態は、ある特定のデータ処理環境内での動作に限定されるものではなく、複数のデータ処理環境内で自在に機能する。加えて、本発明の実施形態について、特定の一連のトランザクションおよびステップを用いて説明してきたが、本発明の範囲が、記載されている一連のトランザクションおよびステップに限定されないことは、当業者には明らかなはずである。

0201

さらに、本発明の実施形態について、ハードウェアとソフトウェアの特定の組み合わせを用いて説明してきたが、ハードウェアとソフトウェアの他の組合わせも本発明の範囲内であることが認識されるはずである。本発明の実施形態は、ハードウェアのみで実現されてもよく、ソフトウェアのみで実現されてもよく、これらの組合わせを用いて実現されてもよい。本明細書に記載のさまざまなプロセスは、同一のプロセッサ上で実現されてもよく、または任意に組合わされた異なるプロセッサ上で実現されてもよい。したがって、構成要素またはモジュールが、特定の動作を実行するように構成されているという記載があった場合、このような構成は、たとえば、電子回路をこの動作を実行するように設計することによって、または、プログラム可能な電子回路(マイクロプロセッサ等)をこの動作を実行するようにプログラムすることによって、または、これらを任意に組合わせて実現することができる。プロセスは従来のプロセス間通信の技術を含むがこれに限定されないさまざまな技術を用いて通信することができ、異なるプロセス対は異なる技術を使用してもよく、または、同一のプロセス対が異なる技術を異なる時間に使用してもよい。

0202

明細書および図面はしたがって、限定的な意味ではなく例示的な意味で考慮されねばならない。しかしながら、これに対し、追加、控除、削除、およびその他の修正および変更を、請求項に記載のより広い精神および範囲から逸脱することなく行ない得ることは明らかであろう。このように、具体的な発明の実施形態について説明してきたが、これは限定を意図したものではない。さまざまな変形および均等物は以下の請求項の範囲に含まれる。

ページトップへ

この技術を出願した法人

この技術を発明した人物

ページトップへ

関連する挑戦したい社会課題

関連する公募課題

ページトップへ

技術視点だけで見ていませんか?

この技術の活用可能性がある分野

分野別動向を把握したい方- 事業化視点で見る -

(分野番号表示ON)※整理標準化データをもとに当社作成

ページトップへ

おススメ サービス

おススメ astavisionコンテンツ

新着 最近 公開された関連が強い技術

  • 富士ゼロックス株式会社の「 データ管理システム」が 公開されました。( 2020/09/24)

    【課題】階層構造になっている管理システムにおいて、管理対象データの実体を最上位の装置が全て管理する場合と比較して、管理対象データがユーザの意図しない装置に提供されないシステムを提供する。【解決手段】管... 詳細

  • ソニー株式会社の「 情報処理装置、情報処理方法、およびプログラム」が 公開されました。( 2020/09/24)

    【課題・解決手段】本技術は、複数人のユーザが皆満足できる空間を提供することができるようにする情報処理装置、情報処理方法、およびプログラムに関する。分析部は、複数人のユーザが存在する環境におけるセンシン... 詳細

  • アルテリックス インコーポレイテッドの「 並列処理を使用したハッシュ結合の実行」が 公開されました。( 2020/09/24)

    【課題・解決手段】データレコードは、コンピュータを使用して結合される。第1の複数のデータレコードおよび第2の複数のデータレコード内のデータレコードがハッシュされる。第1の複数のデータレコードおよび第2... 詳細

この 技術と関連性が強い人物

関連性が強い人物一覧

この 技術と関連する社会課題

関連する挑戦したい社会課題一覧

この 技術と関連する公募課題

関連する公募課題一覧

astavision 新着記事

サイト情報について

本サービスは、国が公開している情報(公開特許公報、特許整理標準化データ等)を元に構成されています。出典元のデータには一部間違いやノイズがあり、情報の正確さについては保証致しかねます。また一時的に、各データの収録範囲や更新周期によって、一部の情報が正しく表示されないことがございます。当サイトの情報を元にした諸問題、不利益等について当方は何ら責任を負いかねることを予めご承知おきのほど宜しくお願い申し上げます。

主たる情報の出典

特許情報…特許整理標準化データ(XML編)、公開特許公報、特許公報、審決公報、Patent Map Guidance System データ