図面 (/)

技術 アーカイブされたリレーションを有する連続クエリの管理

出願人 オラクル・インターナショナル・コーポレイション
発明者 デシュムク,ウンメシュ・アニルスリニバサン,アナンドビシュノイ,サンディープシュクラ,ビクラムパーク,ホヨン
出願日 2013年9月26日 (7年4ヶ月経過) 出願番号 2015-534680
公開日 2016年1月7日 (5年1ヶ月経過) 公開番号 2016-500168
状態 特許登録済
技術分野 検索装置
主要キーワード 初期化アルゴリズム 構成要素タイプ 連続イベント 補助構造 履歴イベント ステム列 最適セット 不可分性
関連する未来課題
重要な関連分野

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

図面 (20)

課題・解決手段

アーカイブされたリレーションを有する連続クエリを管理する技術が提供される。いくつかの例において、少なくともデータストリームを含むクエリを識別し得る。加えて、履歴データの少なくとも一部を用いてクエリを初期化し得る。さらに、いくつかの例において、データストリームおよび履歴データの少なくとも一部に少なくとも一部基づいてクエリを評価し得る。

概要

背景

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

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

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

概要

アーカイブされたリレーションを有する連続クエリを管理する技術が提供される。いくつかの例において、少なくともデータストリームを含むクエリを識別し得る。加えて、履歴データの少なくとも一部を用いてクエリを初期化し得る。さらに、いくつかの例において、データストリームおよび履歴データの少なくとも一部に少なくとも一部基づいてクエリを評価し得る。

目的

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

効果

実績

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

この技術が所属する分野

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

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

請求項1

ステムであって、少なくともデータストリーム識別するクエリを識別するための手段と、履歴データの少なくとも一部を用いて前記クエリを初期化するための手段と、前記データストリームおよび前記履歴データの一部に少なくとも一部基づいて前記クエリを評価するための手段とを備える、システム。

請求項2

前記クエリは、到来する前記データストリームのリアルタイムデータまたは前記データストリームのアーカイブされたリレーションを処理するように構成された連続クエリを含む、請求項1に記載のシステム。

請求項3

前記リアルタイムデータは、少なくともビジネスイベントデータを含む、請求項2に記載のシステム。

請求項4

前記データストリームは、ウィンドウを用いて構成されたリレーションを含み、前記ウィンドウは、前記ウィンドウの中の前記データストリームの一部を参照するためのものである、請求項1または3のいずれかに記載のシステム。

請求項5

前記ウィンドウは、時間の経過とともに前記データストリームに沿って移動するように構成される、請求項4に記載のシステム。

請求項6

前記履歴データは、前記クエリの初期化後のある時点における前記データストリームに含まれない、請求項1〜5のいずれか一項に記載のシステム。

請求項7

前記クエリはさらに前記履歴データを識別する、請求項1〜6のいずれか一項に記載のシステム。

請求項8

前記履歴データは、前記クエリの初期化前のある時点における前記データストリームからのビジネスイベントデータを含む、請求項1〜7のいずれか一項に記載のシステム。

請求項9

前記クエリを評価することは、前記クエリの演算子を表わすノードを用いてクエリグラフを少なくとも形成することを含む、請求項1〜8のいずれか一項に記載のシステム。

請求項10

前記ノードのうちの少なくとも1つはウィンドウサイズを識別する、請求項9に記載のシステム。

請求項11

複数の命令を実行することにより、前記クエリグラフをトポロジー順序で少なくともトラバースするための手段をさらに備える、請求項9または10に記載のシステム。

請求項12

前記クエリグラフにおいて識別された最下位ステートフル演算子における少なくとも前記履歴データを用いて前記クエリを初期化するための手段をさらに備える、請求項11に記載のシステム。

請求項13

構成可能なウィンドウサイズを識別するための手段をさらに備える、請求項11に記載のシステム。

請求項14

前記クエリは、前記構成可能なウィンドウサイズに少なくとも一部基づいて初期化される、請求項13に記載のシステム。

請求項15

前記クエリを評価することは、構成可能なウィンドウサイズに少なくとも一部基づいて前記データストリームに対して前記クエリを少なくとも適用することを含む、請求項1に記載のシステム。

請求項16

前記データストリームは、第2のウィンドウの中の前記データストリームの一部を参照するための第2の構成可能なウィンドウサイズを用いて構成されたリレーションを含み、前記第2のウィンドウのサイズは、第2の構成可能なウィンドウサイズに少なくとも一部基づく、請求項1〜15のいずれか一項に記載のシステム。

請求項17

第2のウィンドウは、時間の経過とともに前記データストリームに沿って移動するように構成される、請求項1に記載のシステム。

請求項18

1つ以上のプロセッサにより実行可能な複数の命令を格納するコンピュータ読取可能なプログラムであって、前記複数の命令は、データストリームを処理するように構成された連続クエリを受けることを、前記1つ以上のプロセッサに行なわせる命令を含み、前記連続クエリは、前記データストリームの識別子および履歴データの識別子のうちの少なくとも1つを含み、前記連続クエリに少なくとも一部基づいてクエリグラフを生成することを、前記1つ以上のプロセッサに行なわせる命令と、履歴データの少なくとも一部を用いて前記連続クエリを初期化することを、前記1つ以上のプロセッサに行なわせる命令と、前記データストリームに関して前記履歴データに少なくとも一部基づいて前記連続クエリを評価することを、前記1つ以上のプロセッサに行なわせる命令とを含む、コンピュータ読取可能なプログラム。

請求項19

前記データストリームおよび前記履歴データのうちの少なくとも一方は、前記連続クエリのデータ定義言語アノテーションによって識別される、請求項18に記載のコンピュータ読取可能なプログラム。

請求項20

前記データ定義言語アノテーションは、前記履歴データの場所、前記データストリームのソース、前記データストリームに関連するデータオブジェクト、前記連続クエリの処理に関連する動作情報、前記履歴データに対応するデータベースの関連する1つ以上の列、前記連続クエリの出力に対応するデータオブジェクト、および、前記連続クエリの出力を提供するための場所のうちの少なくとも1つを識別する、請求項19に記載のコンピュータ読取可能なプログラム。

請求項21

前記クエリグラフは、前記連続クエリの演算子を表わす少なくともノードを含む、請求項18に記載のコンピュータ読取可能なプログラム。

請求項22

前記連続クエリは、前記クエリグラフをトポロジーの順でトラバースする間に、前記クエリグラフのステートフル演算子における前記履歴データの少なくとも一部を用いて初期化される、請求項18に記載のコンピュータ読取可能なプログラム。

請求項23

方法であって、ビジネスイベントデータのストリームを処理するように構成された連続クエリを受けることを含み、前記連続クエリは、前記ストリームの識別子と前記ストリームに関連する履歴データの識別子とを含み、前記連続クエリに少なくとも一部基づいてクエリグラフを生成することを含み、前記クエリグラフは、前記連続クエリの演算子を表わす少なくともノードを含み、前記クエリグラフをトラバースして最下位のステートフル演算子を識別することと、前記識別された最下位のステートフル演算子における履歴データの少なくとも一部を用いて前記連続クエリを初期化することと、前記ストリームに関して前記履歴データに少なくとも一部基づいて前記連続クエリを評価することとを含む、方法。

請求項24

前記履歴データは、前記ストリームの前の時点からのビジネスイベントデータを含む、請求項23に記載の方法。

請求項25

前記連続クエリの演算子に少なくとも一部基づいて前記連続クエリを初期化するために用いる前記履歴データの最適量を決定することをさらに含む、請求項23に記載の方法。

請求項26

前記ステートフル演算子は、前記連続クエリの少なくとも1つのノードの評価に少なくとも一部基づいて識別される、請求項23に記載の方法。

技術分野

0001

関連出願の相互参照
本願は、2013年3月14日に出願され「Managing Continuous Queries with Archived Relations(アーカイブされたリレーションを有する連続クエリの管理)」と題された米国特許出願第13/829,958号(代理人整理番号88325−859813(128010US))、2013年3月14日に出願され「Configurable Data Windows for Archived Relations(アーカイブされたリレーションのための構成可能なデータウィンドウ)」と題された米国特許出願第13/830,129号(代理人整理番号88325−859814(128020US))、および、2012年9月28日に出願され「Real Time Business Event Analysis and Monitoring(リアルタイムビジネスイベント分析およびモニタリング)」と題された米国仮出願第61/707,641号に基づく優先権と利益を主張し、すべての目的のために各出願の内容全体を本明細書に引用により援用する。

背景技術

0002

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

0003

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

0004

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

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

0005

概要
いくつかの例において、連続クエリの中のアーカイブされたリレーションを管理するためのシステムが提供される。このシステムは、メモリと、このメモリにアクセス命令を実行することにより、少なくともデータストリームを識別するクエリを識別するように構成された1つ以上のプロセッサとを含み得る。上記命令を実行することにより、履歴データの少なくとも一部を用いて上記クエリを初期化してもよい。加えて、上記命令を実行することにより、上記データストリームおよび上記履歴データの一部に少なくとも一部基づいて上記クエリを評価してもよい。場合によっては、上記クエリは、到来する上記データストリームのリアルタイムデータまたは上記データストリームのアーカイブされたリレーションを処理するように構成された連続クエリを含み得る。上記リアルタイムデータは、少なくともビジネスイベントデータを含み得る。加えて、いくつかの例において、上記データストリームは、ウィンドウを用いて構成されたリレーションを含み得る。ウィンドウは、このウィンドウの中のデータストリームの一部を参照するためのものである。上記ウィンドウは、時間の経過とともにデータストリームに沿って移動するように構成してもよい。いくつかの局面において、上記履歴データは、上記クエリの初期化後のある時点におけるデータストリームに含まれなくてもよい。上記クエリはさらに上記履歴データを識別してもよい。加えて、上記履歴データは、上記クエリの初期化前のある時点におけるデータストリームからのビジネスイベントデータを含み得る。いくつかの局面において、上記クエリを評価することは、クエリの演算子を表わすノードを用いてクエリグラフを少なくとも形成することを含み得る。加えて、上記1つ以上のプロセッサはさらに、上記複数の命令を実行することにより、上記クエリグラフをトポロジー順序で少なくともトラバースするように構成されてもよい。加えて、上記1つ以上のプロセッサはさらに、上記複数の命令を実行することにより、上記クエリグラフにおいて識別された最下位ステートフル(stateful)演算子における少なくとも履歴データを用いて上記クエリを少なくとも初期化するように構成されてもよい。

0006

加えて、いくつかの例において、コンピュータ読取可能な媒体が提供されてもよい。この媒体は、1つ以上のプロセッサにより実行可能な複数の命令を格納し得る。この命令は、いくつかの例において、データストリームを処理するように構成された連続クエリを受けることを含み得る。この連続クエリは、上記データストリームの識別子および履歴データの識別子のうちの少なくとも一方を含み得る。上記命令はまた、上記連続クエリに少なくとも一部基づいてクエリグラフを生成することを含み得る。いくつかの局面において、上記命令はまた、履歴データの少なくとも一部を用いて上記連続クエリを初期化すること、および/または、上記データストリームに関して上記履歴データに少なくとも一部基づいて上記連続クエリを評価することを含み得る。いくつかの例において、上記データストリームおよび上記履歴データのうちの少なくとも一方を、上記連続クエリのデータ定義言語アノテーションDDLannotation)によって識別してもよい。加えて、上記データ定義言語アノテーションは、上記履歴データの場所、上記データストリームのソース、上記データストリームに関連するデータオブジェクト、上記連続クエリの処理に関連する動作情報、上記履歴データに対応するデータベースの関連する1つ以上の列、上記連続クエリの出力に対応するデータオブジェクト、および、上記連続クエリの出力を提供するための場所のうちの少なくとも1つを識別してもよい。さらに、上記クエリグラフは、上記連続クエリの演算子を表わす少なくともノードを含んでいてもよく、および/または、上記連続クエリを、上記クエリグラフをトポロジーの順序でトラバースする間に、上記クエリグラフのステートフル演算子における上記履歴データの少なくとも一部を用いて初期化してもよい。これに代えて、上記命令を実施するコンピュータ読取可能なプログラムが提供されてもよい。

0007

さらに、いくつかの例において、方法が提供されてもよい。この方法は、ビジネスイベントデータのストリームを処理するように構成された連続クエリを受けるように構成されてもよく、この連続クエリは、上記ストリームの識別子と上記ストリームに関連する履歴データの識別子とを含み得る。いくつかの局面において、上記方法はまた、上記連続クエリに少なくとも一部基づいてクエリグラフを生成するように構成されてもよい。このクエリグラフは、上記連続クエリの演算子を表わす少なくともノードを含み得る。加えて、上記方法はまた、上記クエリグラフをトラバースして最下位のステートフル演算子を識別するように構成されてもよい。上記方法はまた、上記識別された最下位のステートフル演算子における履歴データの少なくとも一部を用いて上記連続クエリを初期化するように、および/または上記ストリームに関して上記履歴データに少なくとも一部基づいて上記連続クエリを評価するように構成されてもよい。加えて、いくつかの例において、上記履歴データは、上記ストリームの前の時点からのビジネスイベントデータを含み得る。この方法はまた、上記連続クエリの演算子に少なくとも一部基づいて上記連続クエリを初期化するために用いる上記履歴データの最適量を決定するように構成されてもよい。さらに、上記ステートフル演算子は、上記連続クエリの少なくとも1つのノードの評価に少なくとも一部基づいて識別してもよい。

0008

構成可能なデータウィンドウを有するアーカイブされたリレーションがある場合の連続クエリが提供されてもよい。いくつかの例において、システムが提供されてもよく、このシステムは、命令を格納するメモリ、および/または、このメモリにアクセスし命令を実行することにより少なくともデータストリームを識別するクエリを少なくとも識別するように構成されたプロセッサを、含み得る。このシステムはまた、上記命令を実行することにより、構成可能なウィンドウサイズを識別してもよい。加えて、いくつかの例において、このシステムは、上記命令を実行することにより、履歴データの少なくとも一部を用い上記ウィンドウサイズに少なくとも一部基づいて上記クエリを初期化してもよい。さらに、このシステムはまた、上記命令を実行することにより、上記データストリームおよび上記履歴データの一部に少なくとも一部基づいて上記クエリを評価するように構成されてもよい。いくつかの局面において、上記クエリは、到来する上記データストリームのリアルタイムビジネスイベントデータを処理するように構成された連続クエリを含み得る。上記クエリの評価は、上記クエリを、上記データストリームに対して、上記構成可能なウィンドウサイズに少なくとも一部基づいて適用することを含み得る。加えて、いくつかの例において、上記データストリームは、第2のウィンドウの中の上記データストリームの一部を参照するための第2の構成可能なウィンドウサイズを用いて構成されたリレーションを含み得る。上記第2のウィンドウのサイズは、第2の構成可能なウィンドウサイズに少なくとも一部基づく。

0009

加えて、いくつかの例において、上記第2のウィンドウは、時間の経過とともに上記データストリームに沿って移動するように構成してもよい。上記履歴データは、上記クエリの初期化後のある時点においてデータストリームに含まれなくてもよい。また、上記履歴データは、上記クエリの初期化前のある時点におけるデータストリームからのビジネスイベントデータを含み得る。いくつかの例において、上記システムはまた、上記命令を実行することにより、上記クエリを、上記クエリの演算子を表わすノードを用いてクエリグラフを少なくとも形成することにより、少なくとも評価するように構成されてもよい。加えて、上記ノードのうちの少なくとも1つがウィンドウサイズを識別してもよい。さらに、いくつかの局面において、このシステムは、上記命令を実行することにより、上記クエリグラフをソースからトポロジーに従って少なくともトラバースするように構成されてもよい。上記1つ以上のプロセッサはまた、上記命令を実行することにより、上記クエリグラフにおいて識別された最下位のステートフル演算子における少なくとも履歴データを用いて、上記クエリを少なくとも初期化するように構成されてもよい。

0010

加えて、いくつかの例において、コンピュータ読取可能なメモリが提供されてもよい。このメモリは、アーカイブされたリレーションを処理するように構成された連続クエリを受けることを1つ以上のプロセッサに行なわせる命令を格納するように構成されてもよい。この連続クエリは、データストリームの識別子および履歴データの識別子のうちの少なくとも一方を含む。また、上記命令により、上記連続クエリに少なくとも一部基づいてクエリグラフを生成することを上記プロセッサに行なわせてもよい。加えて、いくつかの例において、上記命令により、上記アーカイブされたリレーションに関連するエンティティからウィンドウサイズを受けることを上記プロセッサに行なわせてもよい。いくつかの局面において、上記命令により、履歴データの少なくとも一部を用いて上記連続クエリを初期化することを上記プロセッサに行なわせてもよい。さらに、いくつかの例において、上記命令により、上記連続クエリを、上記アーカイブされたリレーションおよびウィンドウサイズに関して、クエリグラフに少なくとも一部基づいて評価することを、上記1つ以上のプロセッサに行なわせてもよい。上記アーカイブされたリレーションは、上記履歴データに少なくとも一部基づいていてもよい。いくつかの局面において、上記アーカイブされたリレーションおよび上記履歴データのうちの少なくとも一方を、上記連続クエリのデータ定義言語アノテーションによって識別してもよい。このデータ定義言語アノテーションは、上記履歴データの場所、上記アーカイブされたリレーションのソース、上記アーカイブされたリレーションに関連するデータオブジェクト、上記連続クエリの処理に関連する動作情報、上記履歴データに対応するデータベースの関連する1つ以上の列、上記連続クエリの出力に対応するデータオブジェクト、および、上記連続クエリの出力を与える場所のうちの少なくとも1つを識別してもよい。加えて、いくつかの例において、上記複数の命令はさらに、ウィンドウサイズに少なくとも一部基づいて上記連続クエリを初期化するために用いる履歴データの量を決定することを、上記1つ以上のプロセッサに行なわせる命令を含み得る。さらに、上記連続クエリを、上記クエリグラフを上記クエリグラフのソースからトポロジーに従ってトラバースする間に上記クエリグラフのステートフル演算子における上記履歴データの少なくとも一部を用いて初期化してもよい。

0011

さらに、いくつかの例において、コンピュータにより実装可能な方法が提供されてもよい。この方法は、ビジネスイベントデータに関連するアーカイブされたリレーションを処理するように構成された連続クエリを受けるように構成されてもよく、この連続クエリは、上記アーカイブされたリレーションの識別子と上記ストリームに関連する履歴データの識別子とを含む。加えて、この方法は、処理するアーカイブされたリレーションの有界範囲を識別するように構成されたウィンドウサイズを受けるように構成されてもよい。この方法はまた、上記連続クエリに少なくとも一部基づいてクエリグラフを生成するように構成されてもよく、このクエリグラフは、上記連続クエリの演算子を表わす少なくともノードを含む。加えて、いくつかの局面において、この方法は、上記クエリグラフをこのクエリグラフのソースノードからトポロジーに従ってトラバースすることにより、ステートフル演算子を識別するように構成されてもよい。この方法はまた、上記連続クエリを、上記識別されたステートフル演算子における履歴データの少なくとも一部を用いて初期化するように、および/または、上記連続クエリを、上記アーカイブされたリレーションに関して、ウィンドウサイズに少なくとも一部基づいて評価するように構成されてもよい。いくつかの局面において、上記履歴データは、上記連続クエリの初期化よりも前の、上記アーカイブされたリレーションのある時点からのビジネスイベントデータを含み得る。加えて、いくつかの局面において、この方法はまた、上記連続クエリの演算子に少なくとも一部基づいて上記連続クエリを初期化するために用いる上記履歴データの最適量を決定するように構成されてもよい。さらに、この方法はまた、ウィンドウサイズに少なくとも一部基づいて上記連続クエリを初期化するために用いる上記履歴データの最適量を決定するように構成されてもよい。

0012

少なくとも1つの例に従うと、システムは、少なくともデータストリームを識別するクエリを識別するための手段と、履歴データの少なくとも一部を用いて上記クエリを初期化するための手段と、データストリームおよび上記履歴データの一部に少なくとも一部基づいて上記クエリを評価するための手段とを含み得る。

0013

ここまで述べてきたことは、以下の明細書、請求項、および添付の図面を参照すると、他の特徴および実施形態とともに、より明らかになるであろう。

0014

添付の図面を参照しながら詳細な説明を行なう。図面において、参照番号の左端の桁は、その参照番号が最初に示されている図面の番号である。異なる図面で使用される同一の参照番号は、同様または同一のアイテムを示す。

図面の簡単な説明

0015

少なくとも1つの例に従うアーカイブされたリレーションを有する連続クエリを管理するためのアーキテクチャの一例を示す簡略ブロック図である。
少なくとも1つの例に従う本明細書に記載のアーカイブされたリレーションを有する連続クエリの管理の少なくともいくつかの特徴を示す簡略ブロック図である。
少なくとも1つの例に従う本明細書に記載のアーカイブされたリレーションを有する連続クエリの管理の少なくともいくつかの他の特徴を示す簡略ブロック図である。
少なくとも1つの例に従う本明細書に記載のアーカイブされたリレーションを有する連続クエリの管理の少なくともいくつかの他の特徴を示す簡略ブロック図である。
少なくとも1つの例に従う本明細書に記載のアーカイブされたリレーションを有する連続クエリの管理の少なくともいくつかの他の特徴を示す簡略ブロック図である。
少なくとも1つの例に従う本明細書に記載のアーカイブされたリレーションを有する連続クエリの管理の少なくともいくつかの特徴を示す簡略プロセスフローである。
少なくとも1つの例に従う本明細書に記載のアーカイブされたリレーションを有する連続クエリの管理の少なくともいくつかの特徴を示す別の簡略プロセスフローである。
少なくとも1つの例に従う本明細書に記載のアーカイブされたリレーションを有する連続クエリの管理の少なくともいくつかの特徴を示す別の簡略プロセスフローである。
少なくとも1つの例に従う本明細書に記載のアーカイブされたリレーションを有する連続クエリの管理の少なくともいくつかの特徴を示す別の簡略プロセスフローである。
少なくとも1つの例に従う本明細書に記載のアーカイブされたリレーションを有する連続クエリの管理の少なくともいくつかの特徴を示す別の簡略プロセスフローである。
少なくとも1つの例に従う本明細書に記載のアーカイブされたリレーションを有する連続クエリの管理の少なくともいくつかの特徴を示す別の簡略プロセスフローである。
少なくとも1つの例に従う本明細書に記載のアーカイブされたリレーションを有する連続クエリの管理の少なくともいくつかの特徴を示す別の簡略プロセスフローである。
少なくとも1つの例に従う本明細書に記載のアーカイブされたリレーションを有する連続クエリの管理の少なくともいくつかの特徴を示す別の簡略プロセスフローである。
少なくとも1つの例に従う本明細書に記載のアーカイブされたリレーションを有する連続クエリの管理の少なくともいくつかの特徴を示す別の簡略プロセスフローである。
少なくとも1つの例に従う本明細書に記載のアーカイブされたリレーションを有する連続クエリを管理する実施形態に従って使用され得るシステム環境の構成要素を示す簡略ブロック図である。
少なくとも1つの例に従う本明細書に記載のアーカイブされたリレーションを有する連続クエリを管理する実施形態に従って使用され得るコンピュータシステムを示す簡略ブロック図である。
少なくとも1つの例に従う本明細書に記載のアーカイブされたリレーションを有する連続クエリの管理の少なくともいくつかの特徴を示す別の簡略プロセスフローである。
少なくとも1つの例に従う本明細書に記載のアーカイブされたリレーションを有する連続クエリの管理の少なくともいくつかの特徴を示す別の簡略プロセスフローである。
少なくとも1つの例に従う本明細書に記載のアーカイブされたリレーションを有する連続クエリの管理の少なくともいくつかの特徴を示す別の簡略プロセスフローである。

実施例

0016

詳細な説明
以下の説明では、さまざまな実施形態が説明される。これら実施形態が十分に理解されるよう、特定の構成および詳細事項が説明のために記載される。しかしながら、これらの具体的な詳細事項がなくとも実施形態を実行し得ることも当業者には明らかであろう。さらに、記載されている実施形態が不明瞭にならぬよう、周知の特徴は省略または簡略化される場合がある。

0017

いくつかの例において、1つ以上のアーカイブされたリレーションを有する連続クエリ言語(continuous query language)(CQL)クエリ(「クエリステートメント」とも呼ばれる)をサポートする機構を提供し得る。上記アーカイブされたリレーションは、たとえばCQLリレーションを含むがこれに限定されない。これは、作成された時点において空でなくてもよい。たとえば、シナリオによっては、CQLリレーションを、ストリーム上にウィンドウを適用することによって定義してもよい。言い換えると、リレーションは有界のデータ集合であってもよい。たとえば、あるイベントストリームに対して、リレーションを先ずウィンドウによって定義してもよく、このウィンドウは(たとえばこのウィンドウの中の)ストリームの特定の数の要素またはストリームの特定の集合の要素を含む。しかしながら、リレーションを場合によっては空の状態で作成してもよい。すなわち、ウィンドウを定義してもよいが、リレーションにイベントが含まれていない場合がある。一方、アーカイブされたリレーションは、作成時にイベントデータを含み得る。いくつかの例において、アーカイバ(archiver)または他のデータオブジェクトは、アーカイブされたリレーションの作成において利用されるリアルタイムデータの管理を担当してもよく、および/またはこのデータをアーカイブされたリレーションを生成するかそうでなければ管理するように構成されたエンジンに与えてもよい。

0018

加えて、いくつかの例において、アーカイブされたリレーションを有するCQLクエリをサポートするための機構はまた、アーカイブされたリレーションの特定のデータウィンドウの構成を可能にし得る。これらデータウィンドウは、ユーザによって、管理者によって、またはアーカイブされたリレーションおよび/またはユーザのイベントデータ(たとえばビジネスイベントデータ)に関連するその他のエンティティによって、構成、生成、管理、更新、および/または操作されてもよい。さらに、いくつかの例において、連続クエリの中のアーカイブされたリレーションは、変更通知の見落としおよび/または二重カウントを回避するように実装してもよい。たとえば、クエリを実行するときは、クエリを最初にデータオブジェクト補助記憶装置に対して実行してクエリの現在の状態を確立し、その後、このデータオブジェクトからの変更通知をリッスンし(listen for)処理してもよい。しかしながら、クエリを実装する複合イベント処理(CEP)が最初のクエリを実行している間、変更通知が見落とされる場合がある。加えて、変更通知は、変更が最初のクエリに既にある場合は二重カウントされる場合もある。しかし、いくつかの例において、変更通知の見落としおよび/または二重カウントは、最初のクエリの前にリスナー(listener)を確立し、および/またはトランザクション識別子(TID)、コンテキスト識別子CID)、もしくは変更イベントを管理するための他の機構を利用することによって、回避し得る。

0019

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

0020

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

0021

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

0022

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

0023

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

0024

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

0025

...
(<timestamp_N>,<NVDA,4>)
(<timestamp_N+1>,<ORCL,62>)
(<timestamp_N+2>,<PCAR,38>)
(<timestamp_N+3>,<SPOT,53>)
(<timestamp_N+4>,<PDCO,44>)
(<timestamp_N+5>,<PTEN,50>)
...
上記ストリームにおけるストリーム要素(<timestamp_N+1>,<ORCL,62>)の場合、イベントは、「stock_symbol」(株式銘柄)および「stock_value」(株価)という属性を有する<ORCL,62>である。このストリーム要素に関連するタイムスタンプは「timestamp_N+1」である。このように、連続イベントストリームは、イベントのフローであり、各イベントは同じ一連の属性を有する。

0026

上記のように、ストリームは、CQLクエリが機能する対象であるデータの根本的ソースであってもよい。ストリームSは、要素(s,T)のバッグ(「マルチセット」とも呼ばれる)であってもよく、「s」はSのスキーマにあり、「T」は時間ドメインにある。加えて、ストリーム要素は、タイムスタンプされた一連のタプル挿入として表わすことができるタプル−タイムスタンプ対であってもよい。言い換えると、ストリームは、一連のタイムスタンプされたタプルであってもよい。場合によっては、同一のタイムスタンプを有するタプルが2つ以上ある可能性がある。また、入力ストリームのタプルは、タイムスタンプが増す順序でシステムに到着することが要求される場合がある。これに代えて、リレーション(「経時変化するリレーション」とも呼ばれ、リレーショナルデータベースからのデータを含み得る「リレーショナルデータ」と混同されてはならない)は、時間ドメインからスキーマRのタプルの無限のバッグへのマッピングであってもよい。いくつかの例において、リレーションは、順序化されていない経時変化するタプルのバッグ(すなわち瞬間的リレーション)であってもよい。場合によっては、時間の各インスタンスにおいてリレーションは有界集合であってもよい。またこれは、リレーションの変化する状態を捕捉するための挿入、削除、および/または更新を含み得る、タイムスタンプを有する一連のタプルとして表わすことができる。ストリームと同様、リレーションは、リレーションの各タプルが従い得る固定スキーマを有し得る。さらに、本明細書で使用されるように、連続クエリは通常、ストリームおよび/またはリレーションのデータを処理することができる(クエリすることができる)。加えて、このリレーションはストリームの参照データであってもよい。

0027

いくつかの例において、ビジネスインテリジェンス(BI)は、特定の間隔で(たとえば場合によっては毎日ビジネスオペレーション推進し最適化するのを支援し得る。このタイプのBIは通常、オペレーシナルビジネスインテリジェンス、リアルタイムビジネスインテリジェンス、またはオペレーショナルインテリジェンス(OI)と呼ばれる。いくつかの例において、オペレーショナルインテリジェンスは、BIとビジネスアクティビティモニタリング(BAM)との間の線引を曖昧にする。たとえば、BIは、履歴データの周期的クエリを重視するものであってもよい。したがって、これは過去を振り返ることを重視したものであってもよい。しかしながら、BIは、オペレーショナルアプリケーションの中に置くこともでき、したがって、単なる戦略的分析ツールから、ビジネスオペレーションの第一線まで拡張することができる。このため、BIシステムは、イベントストリームを分析し総計をリアルタイムで計算するように構成してもよい。

0028

いくつかの例において、連続クエリ言語サービス(CQサービス)は、BI分析サーバを拡張することにより、連続クエリを扱うとともにリアルタイムの警告を可能にするよう、構成し得る。CQサービスは、いくつかの局面において、BI分析サーバおよびCQLエンジンとの統合をもたらし得る。一例にすぎないが、BI分析サーバは、連続クエリをCQサービスに委託してもよく、CQサービスは、CQLエンジンに対する論理データベース(DB)ゲートウェイとして機能してもよい。このようにして、CQLエンジンは、BI分析サーバを、その分析機能およびセマンティックモデリングについて強化することができるであろう。

0029

いくつかの例において、CQサービスは、とりわけ以下の機能を提供し得る。
・BI分析サーバに対するサービスをCQLエンジンゲートウェイとしてリモート処理する。
イベントソースシンクアダプタ
・論理的SQLに加えてCQL拡張からデータ定義言語(DDL)を生成する。
・すべての種類の連続クエリおよび実装選択に対して統一されたモデルを提供する。
メタデータを維持し再始動能力をサポートする。
高アベイラビリティおよびスケーラビリティのサポート。

0030

加えて、いくつかの例において、OIは、可視性およびビジネスオペレーションに対する洞察を与えることができる、リアルタイムの動的なビジネス分析論の一形態である。OIは、BIまたはリアルタイムBIに、どちらも大量の情報の意味を解明するのを支援するという点において、関連付けられるかまたはこれと比較されることが多い。しかしながら、根本的な相違があり、OIは主としてアクティビティ中心であり得るのに対し、BIは主としてデータ中心であり得る。加えて、パターンを識別するための、事後のかつ報告に基づく手法として従来使用されているBIと異なり、OIは、発展途上の状況(たとえば傾向およびパターン)を検出しこれに対応するのにより適している。

0031

いくつかの例において、ビジネスイベント分析およびモニタリング(BEAM)システムは、インフライト(in-flight)データを処理しおよび/または受けるCQLエンジンを含み得る。たとえば、CQLエンジンは、入ってくるリアルタイム情報(たとえばBIまたはOI)をクエリするかそうでなければ処理するように構成されたインメモリリアルタイムイベント処理エンジンであってもよい。CQLエンジンは、時間のセマンティクスを利用または理解することができ、データのウィンドウの定義を処理できるように構成し得る。CQLエンジンの利用は、場合によっては、入ってくるデータに対してクエリを常に実行することを必要とし得る。

0032

いくつかの局面において、CQLエンジンは、あらゆる特性を備えたクエリ言語を含み得る。このため、ユーザは、クエリという点から計算を指定し得る。加えて、CQLエンジンは、メモリを最適化し、クエリ言語の特徴、オペレータシェアリング豊富パターンマッチング、豊富な言語構築等を利用するように、設計してもよい。加えて、いくつかの例において、CQLエンジンは、履歴データおよびストリーミングデータ双方を処理してもよい。たとえば、ユーザは、カリフォルニア売上高がある目標を超えたときに警告を送るようにクエリを設定してもよい。このように、いくつかの例において、警告は、履歴売上高データおよび入ってくる生(すなわちリアルタイム)の売上高データに少なくとも一部基づき得る。

0033

いくつかの例において、CQLエンジンまたは以下で説明する概念のその他の特徴は、履歴に関する文脈(すなわちウェアハウスデータ)を、入ってくるデータとリアルタイム方式組合わせるように、構成してもよい。したがって、場合によっては、本開示は、データベース格納情報およびインフライト情報の境界について説明することがある。データベース格納情報およびインフライト情報はいずれもBIデータを含み得る。このため、データベースは、いくつかの例において、BIサーバであってもよく、または、何らかの種類のデータベースであってもよい。さらに、いくつかの例において、本開示の特徴により、上記特徴を、ユーザがコードをプログラムする、そうでなければ書込む方法を知らない状態で、実現することができる。言い換えると、上記特徴は、特徴が豊富なユーザインターフェイス(UI)に与えられてもよい、または、履歴データとリアルタイムデータの組合わせを非開発者が実現できるようにする他の手法に与えられてもよい。

0034

いくつかの例において、上記概念を利用することにより、複合イベント処理に関連する豊かなリアルタイムの連続イベント処理機能を強化してもよい。これに限定される訳ではないがアーカイブされたリレーション等のいくつかの特徴をサポートしてもよい。このため、このような特徴(たとえば豊かなリアルタイムの連続イベント処理)を強化するために、システムを、リレーショナルデータの始動状態および実行時状態を透明に扱うように構成してもよい。言い換えると、システムを、作成の時点で空でないクエリ(すなわちアーカイブされたリレーション)を管理するように構成してもよい。

0035

いくつかの例において、アーカイブされたリレーションを利用してもよい。このため、CQLエンジンが見るクエリが、このクエリがアーカイブされたリレーションに基づくことを示すとき、このアーカイブされたリレーションも、たとえば履歴コンテキストについてクエリするためにコールできる何等かのエンティティが存在することを示し得る。いくつかの例において、データ定義言語(DDL)は、アーカイブされたリレーションに関するアノテーションを示し得る。これは、如何にしてクエリを実行するか、何がテーブル内で重要な列か、および/または何処に残りのデータを送るか等であるが、これらに限定されない。いくつかの例において、CQLエンジンにおいて(たとえばグラフとして)クエリが構築されると、システムはこのクエリグラフを分析することができる。加えて、いくつかの局面において、「distinct」、「group aggr」、「pattern」、および/または「group by」のようなステートフルな特定の演算子がある。しかしながら、ステートレスな演算子は、入力を取込んで、親、たとえば下流の演算子に、送るだけでよい。このため、このテーブル全体をここで格納することが1つの手法である。しかしながら、システムは、アーカイブされたリレーションを利用して、クエリグラフを分析し、アーカイブにクエリするのに使用できる最下位のステートフル演算子がどれかを判断することができる。いくつかの例において、システム(またはコンピュータにより実装される1つ以上の方法)は、グラフをトラバースしている間に到達した最下位のステートフル演算子における状態を取出せばよい。たとえば、クエリグラフを、ソースからトポロジーの順序で分析してもよい。この第1のステートフル演算子に少なくとも一部基づいて、CQLエンジンは次に、アーカイブされたリレーションに対して定義されたクエリの演算子の状態を初期化するために、フェッチすべきデータの最適量を決定してもよい。

0036

限定されない少なくとも1つの例において、トポロジーに従ったトラバースにおいて、リレーションおよび/またはソースのようなソース演算子は最初に来るが、クエリ出力および/またはルートは最後に来る。たとえば、CQLクエリが、select sum(c1) from R1 where c2>c25のようなものである場合、このクエリについてのプランは、RelationSource→SELECT→GroupAggrのようなものであろう。したがって、トポロジーの順序に従うと、RelationSourceおよびSELECTはいずれもステートレスなので、最下位のステートフル演算子は、GroupAggrであろう。このようにして、クエリのステートフル演算子(この例ではGroupAggr)により、クエリエンジンは、ストリーミングデータを受ける前に、データ記憶装置からの履歴データをクエリエンジンに投入することができるであろう。これは、クエリがアーカイブされたリレーションを分析しておりアーカイブされたリレーションがそのようなものとして示されていることに少なくとも一部基づいて、可能になるであろう。

0037

いくつかの例において、所与のアーカイブリレーションについてのウィンドウサイズは、ユーザが指定してもよい。いくつかの局面において、アーカイブされたリレーションに関するウィンドウは、入ってくるストリーミングされた内容を分析するかそうでなければ評価するクエリグラフにおけるノードを含み得る。言い換えると、ウィンドウは、クエリエンジンによって分析されるおよび/または処理されるストリーミングされた内容の量、および/またはアーカイブされたリレーションに含まれる履歴データの量を定めることができる。

0038

高いレベルでは、ウィンドウがストリームに適用されると、これはリレーションになり、次に、リレーショナルデータベースと同様に、通常のリレーショナルロジックを適用すればよい。タプルがウィンドウに届いてウィンドウから出るとき、想定しているリレーションは、これに対してコンパイルされたクエリとともに変化し、同時に結果を出力する。CQLは、RANGE(ナノ秒細分性まで)、ROWS、PARTITION BYおよび拡張可能なウィンドウをサポートし得る。これらウィンドウは、ストリーム−リレーション演算子の例である。一方、ISTREAM(すなわち挿入ストリーム)、DSTREAM(すなわち削除ストリーム)およびRSTREAM(すなわちリレーションストリーム)は、リレーション−ストリーム演算子である。いくつかの例において、ユーザ、開発者、および/または管理者は、クエリエンジンによってまたはクエリエンジンを機能させるもしくはホストする1つ以上の計算システムによって(たとえばUIを介して)与えられるウィンドウサイズを設定してもよい。いくつかの例において、ストリーム上のウィンドウは、時間に基づく範囲ウィンドウであってもよい。たとえば、アーカイブされたリレーションに対する構成可能な値のウィンドウは、ウィンドウサイズおよびウィンドウの計算の元になる属性を用いて指定してもよい。アーカイブされたリレーションの上に指定された構成可能な値のウィンドウがある場合、スナップショットクエリを計算してもよく、ウィンドウの境界内にあるスナップショットタプルを出力してもよい。加えて、状態の初期化後、値のウィンドウを、入ってくるアクティブデータに適用してもよい。いくつかの例では、入ってくるアクティブデータのみが、そのウィンドウ属性の値が現在のイベント時間と異なるウィンドウに、ウィンドウサイズよりも短い間、挿入されるであろう。

0039

加えて、いくつかの例において、本開示の特徴は、CQLエンジンおよび/またはCEPエンジンの連続クエリ処理機能を強化してリアルタイムデータ分析をサポートしてもよい。いくつかの局面において、CQLエンジンおよび/またはCEPエンジンは、従来はストリーム指向分析エンジンであったであろうが、永続的記憶装置によって支援されるストリーム指向データ(たとえば上記アーカイブされたリレーション)をサポートするように拡張してもよい。たとえば、本開示は、永続的記憶装置(データベースおよび/またはテーブル)であるデータオブジェクト(DO)の概念を裏付けることができる特徴を説明している。DOに対して修正がなされると、変更通知が、対象のリスナーにブロードキャストされて、事実上データストリームが作成されるであろう。このデータストリームは、実行しているクエリをサポートするCQLエンジンおよび/またはCEPエンジンによって消費されるであろう。しかしながら、CQLエンジンおよび/またはCEPエンジンは、DO補助記憶装置における既存のデータを考慮するように設計されてはいないかもしれない。たとえば、CQLエンジンおよび/またはCEPエンジンは、CQLエンジンおよび/またはCEPエンジンにおいて実行しているクエリの初期状態が、現在DO補助記憶装置にあるすべてのデータを含むDOの現在の状態を反映することを、要求するかもしれない。このクエリがそのように初期化されると、CQLエンジンおよび/またはCEPエンジンは、従来のストリーム指向方式におけるこの点からのDO変更通知のストリームを扱うだけでよい。

0040

いくつかの局面において、CQLエンジンおよび/またはCEPエンジンは、従来はストリームまたはアーカイブされていないリレーションを処理するものであろうため、初期状態はないかもしれない。たとえば、クエリがロードされる場合、これは、実行および変化をリッスンすること等を開始するであろう。場合によっては、棒グラフによる州ごとの売上をユーザが要求しその後誰かによる新たな売上があったとすると、テーブルは更新され、ユーザは、出されたグラフに変化がみられることを予想するであろう。しかしながら、彼らがダッシュボードを閉じて一週間後に戻り売上を報告した場合、ユーザは、合計された売上データのテーブルに示された売上の合計が得られることを予想するであろう。言い換えると、クエリは、アーカイブの状態に引上げられてからアクティブな変更をリッスンする必要があるであろう。

0041

たとえば、いくつかの局面において、CQLエンジンは、アーカイブされたデータを用いて予め初期化されてもよい。初期化されると、CQLエンジンは、(たとえば挿入、削除等についてのAPIコール、アーカイブからのデータに少なくとも一部基づく)変更通知があるか否か知るためにJava(登録商標メッセージングサービス(JMS)またはその他のメッセンジャーをリッスンするであろう。したがって、サービスはリッスンすることができ、JMSが、リスニングサービスがリッスンしているのと同じトピックに関する発行を行なうと、データを受けることができる。サービスは、誰が発行しているのかまたは発行しているか否か知る必要はない。リスニングサービスはリッスンするだけでよく、何かが生じた場合にリスニングサービスはそれを聞けばよい。いくつかの例では、このようにして永続性がたとえばそのコンシューマから切離される。加えて、いくつかの例において、警告エンジンが、聞いたものに基づいて警告を発してもよく、場合によってはさらに、SQLエンジンが、リスナーに関連するプロセスクエリをリッスンしてもよい。

0042

いくつかの例において、クエリは、CQL、SQL、および/またはCEPエンジンにおいて開始されてもよく、命令は、アーカイブデータを(たとえばポンプ(pump)するために)取得した後にこれらJMSメッセージをリッスンし始めるように構成されてもよい。しかしながら、多数の挿入、削除等があるので、これは大量の情報を含み得る。加えて、リスナーがメッセージを聞く前に時間のずれがある可能性があり、いくつかの例において、リッスンすることは、割込み、アーカイブにクエリし、戻り、リッスンを開始することであろう。このため、イベントの見落としおよび/または二重カウントの可能性がある。

0043

加えて、エンジンがクエリを実行するだけであれば、エンジンがクエリを実行している間に、事実がJMSに入りエンジンがリッスンしていなかったところで発行されることがある。そこで、エンジンを、先ずリスナーをセットアップしアーカイブクエリを実行した後に戻って実際にキュー(queue)から出始めるように構成すれば、何の見落としもないであろう。このように、JMSは、事実をキューにしてもよく、エンジンがクエリを実行している間事実のバックアップがあればそれでよい。なぜなら、後で追い付くことが可能であり同期しているか否か心配する必要がないからである。もしここになければ、リッスン中、見落としはなく、リスナーが確立されている限り、エンジンが戻るまでキューにするだけでよい。

0044

加えて、いくつかの例において、システム列をユーザのデータに追加してもよい。このシステム列は、二重カウントおよび/または見落としという動作上の問題に対処する試みにおいて、トランザクションIDを示すためのものであってもよい。しかしながら、他の例において、システムは、トランザクションコンテキストテーブルを提供するかそうでなければ生成してもよい。加えて、2つの追加列としてTRANSACTION_CIDおよびTRANSACTION_TIDがあってもよい。コンテキストテーブルは、最後にコミットされたトランザクションIDのスレッド(コンテキスト)性を知るために、永続性サービスによって常に維持されていてもよい。トランザクションIDは、スレッド(コンテキスト)に対して昇順でコミットされることが保証されてもよい。たとえば、サーバは、立上ったときに、永続性サービスを実行してもよい。各々は、予め初期化された情報のデータがJMSを通過したデータすべてを含むか否か判断するために、コンテキストIDとトランザクションIDのセットを割当ててもよい。加えて、場合によっては、(JTAに準拠するおよび/または高アベイラビリティ(HA)を実現する)複数の出力サーバを利用してもよく、各サーバは、その他のサーバによって管理されるその他のテーブルと全く別の一組のコンテキスト/トランザクションテーブルを管理してもよい。

0045

上記および下記技術は、多数のやり方でおよび多数の文脈において実装し得る。以下において詳細に説明する、実装および文脈のいくつかの例を下記図面を参照しながら示す。しかしながら、以下の実装および文脈は、数あるうちのほんの一部にすぎない。

0046

図1は、アーカイブされたリレーションを有する連続クエリを管理するための技術を実装し得るシステムまたはアーキテクチャ100の簡略化された例を示す。アーキテクチャ100において、1人以上のユーザ102(たとえば口座所有者)は、ユーザの計算装置104(1)〜104(N)(まとめて「ユーザ装置104」とする)を利用して、1つ以上のサービスプロバイダコンピュータ106に、1つ以上のネットワーク108を介してアクセスし得る。いくつかの局面において、サービスプロバイダコンピュータ106も、1つ以上のストリーミングデータソースコンピュータ110および/または1つ以上のデータベース112とネットワーク108を介して通信し得る。たとえば、ユーザ102は、サービスプロバイダコンピュータ106を利用して、ストリーミングデータソースコンピュータ110および/またはデータベース112のデータにアクセスし得る、そうでなければこのデータを管理し得る(たとえば、クエリは、110、112のうちいずれかまたは双方に対して実行し得る)。データベース112は、リレーショナルデータベース、SQLサーバ等であってもよく、いくつかの例では、履歴データ、イベントデータ、リレーション、アーカイブされたリレーション等を、ユーザ102に代わって管理し得る。加えて、データベース112は、ストリーミングデータソースコンピュータ110から提供されるデータを受けることができ、そうでなければ格納することができる。いくつかの例において、ユーザ102は、ユーザ装置104を利用して、サービスプロバイダコンピュータ106と、クエリ(「クエリステートメント」とも呼ばれる)を与えることによりまたはデータ(たとえば履歴イベントデータ、ストリーミングイベントデータ等)に対する他の要求を与えることにより、対話し得る。このようなクエリまたは要求は次に、データベース112のデータおよび/またはストリーミングデータソースコンピュータ110から入ってくるデータを処理するサービスプロバイダコンピュータ106によって実行し得る。さらに、いくつかの例において、ストリーミングデータソースコンピュータ110および/またはデータベース112は、サービスプロバイダコンピュータ106に関連付けられた、一体化された分散環境の一部であってもよい。

0047

いくつかの例において、ネットワーク108は、ケーブルネットワークインターネット無線ネットワークセルラーネットワークイントラネットシステム、および/またはその他の私的および/または公的ネットワーク等の、複数の異なる種類のネットワークのうちの1つまたはこれらを組合わせたものを含み得る。示されている例はユーザ102がネットワーク108を通してサービスプロバイダコンピュータ106にアクセスすることを示しているが、記載されている技術は、ユーザ102が、1つ以上のサービスプロバイダコンピュータ106と、1つ以上のユーザ装置104を介し固定電話を通して、またはキオスクを介して、または他のやり方で、対話する場合に、等しく適用し得る。また、記載されている技術は、他のクライアントサーバ構成(たとえばセットトップボックス等)においても、および、非クライアント/サーバ構成(たとえばローカル格納アプリケーション等)においても、適用し得ることが注目される。

0048

ユーザ装置104は、携帯電話スマートフォン携帯情報端末(PDA)、ラップトップコンピュータデスクトップコンピュータシンクライアント(thin-client)装置、タブレットPC等の、任意の種類の計算装置であればよいが、これらに限定されない。いくつかの例において、ユーザ装置104は、サービスプロバイダコンピュータ106と、ネットワーク108を介してまたはその他のネットワーク接続を介して通信し得る。さらに、ユーザ装置104はまた、処理するデータベース112(またはその他のデータ記憶装置)のデータを要求するための、1つ以上のクエリまたはクエリステートメントを与えるように構成し得る。

0049

いくつかの局面において、サービスプロバイダコンピュータ106はまた、モバイルデスクトップ、シンクライアント、および/またはサーバ等のクラウド計算装置といった、任意の種類の計算装置であればよいが、これらに限定されない。いくつかの例において、サービスプロバイダコンピュータ106は、ユーザ装置104と、ネットワーク108を介してまたはその他のネットワーク接続を介して通信し得る。サービスプロバイダコンピュータ106は、おそらくは、クラスタに、サーバファームとして、または、互いに関連がない個々のサーバとして配置された、1つ以上のサーバを含み得る。これらサーバは、本明細書に記載の特徴を実行するように、そうでなければホストするように、構成し得る。上記特徴は、本明細書に記載の、アーカイブされたリレーションの管理、アーカイブされたリレーションに関連する構成可能なデータウィンドウ、および/またはアーカイブされたリレーションの管理に関連する変更イベントの正確なカウントを含むが、これらに限定されない。加えて、いくつかの局面において、サービスプロバイダコンピュータ106は、ストリーミングデータソースコンピュータ110および/またはデータベース112を含む、一体化された分散計算環境の一部として構成し得る。

0050

例示としてのある構成において、サービスプロバイダコンピュータ106は、少なくとも1つのメモリ136と、1つ以上の処理部(またはプロセッサ)138とを含み得る。プロセッサ138は適宜、ハードウェア、コンピュータにより実行可能な命令、ファームウェア、またはこれらの組合わせにおいて実装し得る。コンピュータにより実行可能な命令またはファームウェアによる、プロセッサ138の実装は、記載されているさまざまな機能を実行するために、何らかの適切なプログラミング言語で書かれた、コンピュータにより実行可能なまたはマシンにより実行可能な命令を含み得る。

0051

メモリ136は、プロセッサ138にロード可能でかつプロセッサ138において実行可能なプログラム命令と、これらプログラムの実行中に生成されるデータとを格納し得る。サービスプロバイダコンピュータ106の構成および種類に応じて、メモリ136は、揮発性ランダムアクセスメモリ(RAM)等)であってもよくおよび/または不揮発性読出専用メモリ(ROM)、フラッシュメモリ他等)であってもよい。サービスプロバイダコンピュータ106またはサーバはまた、着脱可能な記憶装置および/または着脱不能な記憶装置を含み得る、その他の記憶装置140を含み得る。その他の記憶装置140は、磁気記憶装置光ディスク、および/またはテープ記憶装置を含み得るがこれらに限定されない。ディスクドライブおよびこれらディスクドライブに関連するコンピュータ読取可能な媒体は、計算装置のための、コンピュータ読取可能な命令、データ構造プログラムモジュール、およびその他のデータの、不揮発性記憶装置を提供し得る。実装によっては、メモリ136は、スタティックランダムアクセスメモリ(SRAM)、ダイナミックランダムアクセスメモリDRAM)、またはROM等の、複数の異なる種類のメモリを含み得る。

0052

着脱可能および着脱不能な、メモリ136およびその他の記憶装置140はすべて、コンピュータ読取可能な記録媒体の例である。たとえば、コンピュータ読取可能な記録媒体は、コンピュータ読取可能な命令、データ構造、プログラムモジュール、またはその他のデータ等の、情報の格納のための何等かの方法または技術において実装される、揮発性または不揮発性で着脱可能または着脱不能な媒体を含み得る。メモリ136およびその他の記憶装置140はすべて、コンピュータ記録媒体の例である。

0053

サービスプロバイダコンピュータ106はまた、アイデンティティインターフェイスコンピュータ120が、格納されているデータベース、別の計算装置もしくはサーバ、ユーザ端末、および/またはネットワーク108上のその他の装置と通信できるようにする、通信接続142を含み得る。サービスプロバイダコンピュータ106はまた、キーボードマウスペン音声入力装置タッチ入力装置ディスプレイ、1つ以上のスピーカプリンタ他等の、入出力(I/O)装置144を含み得る。

0054

次にメモリ136の内容の詳細について述べる。メモリ136は、オペレーティングシステム146と、アーカイブリレーションモジュール148、構成可能ウィンドウモジュール150、および/またはイベントカウントモジュール152を少なくとも含む、本明細書に開示される特徴を実装するための、1つ以上のアプリケーションプログラムまたはサービスとを含み得る。本明細書で使用されるモジュールは、サービスの一部であるサーバまたはサーバのクラスタによって実行されるプログラミングモジュールであってもよい。この特定の文脈において、モジュールを、サービスプロバイダコンピュータ106の一部であるサーバまたはサーバのクラスタによって実行してもよい。いくつかの例において、アーカイブリレーションモジュール148は、1つ以上のイベントストリームエントリs1、s2、…sNへの参照を含み得る1つ以上のアーカイブされたリレーション154を、受ける、識別する、生成する、そうでなければ提供するように構成し得る。たとえば、アーカイブされたリレーションは、これらエントリ(すなわちs1〜sN)を含むストリームにウィンドウを適用することによって定義してもよい。このため、アーカイブされたリレーションは、これらエントリを含む有界のデータ集合であってもよい。しかしながら、これらエントリは生成時に空でない場合がある。これには、限定ではないが、永続性または履歴データのその他のデータベースから予めロードされたリレーションのエントリのうちの1つ以上(たとえばs1および/またはs2、これよりも多いまたは少ないエントリ)を有することが含まれる。このため、これら予めロードされたエントリは履歴データを含み得る。リレーションの残りは入ってくるストリーミングデータを含み得る。いくつかの例において、アーカイブされたリレーション154は、最初に{s3,s4}として識別されるかもしれない。しかしながら、ウィンドウがw1からw2に移動すると、アーカイブされたリレーション154は、{s4,s5}として識別されs3の削除および/またはs5の挿入によって変更されているかもしれない。

0055

先に述べたように、アーカイブされたリレーション154は、その作成の「瞬間」において(おそらくは)空でないCQLリレーションであってもよい。これは、作成された「瞬間」において内容が空である「通常の」CQLリレーションと対照的である。いくつかの例において、アーカイブされたリレーション154の内容がその作成の瞬間において「時間の始まり」から存在していたと仮定する(Long.MIN_VALUE)。BEAMコンテキストにおいては、CQLエンジン156のオブジェクト(いくつかの例ではすべてのオブジェクト)をサーバの起動の度に作成し得る点に注目するのが有用である。いくつかの点で、アーカイブされたリレーション154は、「通常の」CQL内部リレーションに似ていることがある。特に、演算(JOIN、GROUP AGGR、ORDER BY TOP Nのようなリレーション−リレーション演算、および、I/D/RSTREAMのようなリレーション−ストリーム演算)は、「通常の」CQL内部リレーションに対して有するのと同一のセマンティクスを保持し得る。加えて、いくつかの例において、「アーカイバ」は、CQLエンジン156との特定のコントラクトを実装するJava(登録商標)クラスであってもよい。これは、アーカイバを可能にする機能を有するIArchiverインターフェイスまたはその他のインターフェイスを実装し得る。この「アーカイバ」は、アーカイブされたリレーション154に対応する「アーカイバ」によって管理される論理エンティティの識別子(たとえばデータオブジェクトの名称)とともに、アーカイブされたリレーション154を作成するのに使用されるDDLステートメントの一部として指定されてもよい。

0056

いくつかの局面において、アーカイバは、CQLエンジン156とのコントラクトに少なくとも一部基づいて実装されることにより、アーカイブされたリレーション154の内容をその作成時に少なくとも提供してもよい。加えて、アーカイバは、自身の(たとえばCQLエンジン156の外部の)アーカイブされたリレーション154の「経時変化する」内容を維持すると予想できる。しかしながら、いくつかの例において、アーカイバはステートレスであってもよい。この例において、アーカイバは、アーカイブされたリレーションのフレームワークによって渡されたクエリを実行する方法(たとえば「execute()」)を実装し得る。アーカイバは次に、この方法が実行されると内容をアーカイブされたリレーションのフレームワークに返してもよい。アーカイバはまた、アーカイブされたリレーション154に対するクエリ機能(たとえばSQL−99クエリとして表現される)を提供するように構成されてもよい。加えて、いくつかの例において、「アーカイバ」に提示されるクエリにおけるFROMのアイテムは、「アーカイバ」エンティティの名称および/またはデータオブジェクトの名称(たとえば永続的記憶装置上で維持される)であってもよい。FROM句のアイテムがデータオブジェクトの名称の場合、これらは、作成DDLにおけるアーカイブされたリレーションにマッピングしてもよい。これに加えてまたはこれに代えて、アーカイバの名称を用いてアーカイバインスタンス(2つ以上のアーカイバがある可能性がある)をルックアップしてから、このアーカイバインスタンスに対する実行(クエリ)をコールしてもよい。クエリにおいて使用される属性名は、希望に応じて、CREATE ARCHIVED RELATION DDLまたはその他適切なDDLにおいて指定される列の名称であってもよい。クエリを実行する間、「アーカイバ」は、txn T_nの時点でコミットされた変更を含むデータオブジェクトのスナップショット上でクエリを実行してもよい。上記T_nは、データオブジェクトに対するイベントがストリーミング入力として提示された最新のトランザクションよりも前である。特に、「後の」トランザクションに対応する入力として与えられたストリーミングデータオブジェクトイベントはないであろう。

0057

さらに、「アーカイバ」は、このクエリが実行されたトランザクションのIDを返してもよい。このIDは、後のトランザクションのIDが前のトランザクションのIDよりも大きくなるように単調に増加する数字(必ずしも連続しない)であってもよい。更新イベントの場合、「アーカイバ」は、ストリーミングイベントの一部として、OLD値とNEW値を与えてもよい。これに加えてまたはこれに代えて、いくつかの例では、永続性サービスが、OLD値およびNEW値双方についての変更通知をCQサービスに送ってもよい。このようにして、CQサービスは、適切な動作をアーカイブされたリレーションに対して行なうことができるであろう。削除イベントの場合、「アーカイバ」は、削除イベントを、妥当性検査パスした場合に(いくつかの例では「場合にのみ」)、ストリーミングイベントとして与えてもよい。いくつかの例において、アーカイバの機能は、クエリが処理しないデータオブジェクトイベントはないというシナリオを可能にし得る。CQLエンジン156も、すべてのデータオブジェクトイベントの処理をスキップすることによりイベントは重複して処理されないというシナリオを可能にし得る。この場合、トランザクション識別子<=「スナップショット」クエリの実行の一部として「アーカイバ」によって返されるトランザクション識別子である。いくつかの例において、アーカイバは永続性サービスと同等であり得る。これに代えてまたはこれに加えて、クエリの瞬間におけるスナップショット情報を、トランザクションコンテキストテーブルから得てもよい。このスナップショット情報は、CQLエンジンにおいて維持されてもよく、スナップショットID(増大する識別子)はこれと関連付けられてもよい。同じものを、このクエリのプランにおける選択されたいくつかの演算子の入力キューに設定してもよい。これらは、「コネクタ」演算子と呼ばれ、ローカルクエリプランがグローバル(全体)クエリプランに結合し得る場所を表わしてもよい。イベントがCQLエンジンに達すると、このイベントに対し、スナップショットIDを、その中のコンテキストIDおよびトランザクションIDの値を用いて計算してもよい。スナップショットIDは、CQLエンジンにおいて維持されているスナップショット情報を用いて計算してもよい。イベントのスナップショットIDは次に、入力キューのスナップショットIDと比較してもよい。イベントのID>キューのIDであれば、これを処理をしてもよく、そうでなければ、以前既に考慮されている可能性がありしたがって二重カウントを避けるために無視してもよい。

0058

固有のCQLコンセプトとしてアーカイブされたリレーション154を導入することによって、CQLエンジン156は、アーカイブされたリレーション154に対して定義されたクエリの演算子の状態を初期化するためにフェッチする必要があるデータの最適量を決定することができる。いくつかの例において、クエリのコンパイルの最終ステップとして、クエリプラン生成(および/またはグローバルプランとのマージ)に従い、状態初期化フェイズを導入して、「アーカイバ」に対して実行する必要があるクエリの最適セットを決定してもよい(たとえば演算子の状態の初期化のために)。場合によっては、クエリのセット(たとえば最適セット)を決定するために使用される状態初期化アルゴリズムは、ステートフル演算子に遭遇するまで、一連の演算子の状態化の実現を遅らせるかもしれない(これはデータを集計ししたがってメモリ内のすべての詳細/事実の実現と比較すると取出すデータは少ないかもしれない)。クエリ実行の第1ステップは、状態初期化クエリが実行される前であっても、スナップショットクエリの実行および/またはクライアントへの結果の送達であろう。いくつかの例において、スナップショットクエリ(「アーカイバクエリ」とも呼ばれる)は、演算子を結果の内容によって初期化し得る状態初期化の一部であってもよい。次に、これら結果を下流の演算子(たとえば下流の演算子すべて)に伝搬することによって、結果を出力してもよい。次に、状態初期化アルゴリズムによって決定されたクエリを実行してもよい。この第1ステップの終了時に、すべての演算子それぞれの状態は適切に初期化されクエリはストリーミングイベントを処理できる状態になっているであろう。

0059

CQLクエリが、システム再起動中に、アーカイブされたリレーション154を参照するとき、CQLエンジン156は、クエリ内の実行演算子の状態がシャットダウン前に持っていた値に初期化されるというシナリオを可能にするように構成されてもよい。これに代えてまたはこれに加えて、クエリが(再)起動される度に、それがシャットダウンの一部であろうと自発的なものであろうと、クエリは、フレッシュなすなわち新たなアーカイバクエリを発行することによって状態を再び初期化してもよい。いくつかの例において、これは、t0+デルタの時点ではt0の時点と異なり得る。場合によっては、状態初期化アルゴリズムを、この機能を扱うように構成してもよい。いくつかの例において、各々(またはすべて)のアーカイブされたリレーション154は、リレーションを構成するイベントを追跡するアーカイバオブジェクトにマッピングしてもよく、自身に対して発行されたSQLクエリ(データベーステーブルと同様)に答えてもよい。加えて、CQLクエリにおける実行演算子の状態の初期化は、CQLクエリが依存するアーカイブされたリレーション154にマッピングするアーカイバに対して適切なSQLクエリを発行することと、戻された結果を使用して演算子の状態を初期化することとを少なくとも含む、2段階のプロセスであってもよい。(アーカイバから得た)イベントの実現を遅らせると、結果としてメモリおよび/または処理時間消費が削減されるかもしれない。これに加えてまたはこれに代えて、メモリの削減は、メモリを最小にする適切な演算子が発見されたためであるかもしれない。たとえば、集計された/要約されたデータをメモリに入れると、大幅なメモリの削減につながり得る。

0060

いくつかの例において、状態初期化プロセス(これは、全体のプロセスの中の1ステップであってもよく、CQLクエリの起動時に実装されてもよく、アーカイブされたリレーション(複数可)を参照する)は、メタデータオブジェクトを用いてクエリの論理プランを取得することと、論理プランから物理プランを構築することと、ローカル物理プランをオプティマイザを用いて最適化することと、オペレーション共有してグローバル物理プランを得ることと、補助構造(たとえばシノプシス、記憶、キュー等)を追加することと、クエリをインスタンス化すること(実行演算子を構築しおよび/または実行構造をサポートする)とを、含み得る。加えて、状態初期化アルゴリズムをコールする適切な場所は、ローカル物理プラン最適化の直後であってもよい。いくつかの例において、状態初期化アルゴリズムは、クエリがアーカイブされた1以上のリレーション154に依存するときにコールされるだけであってもよい。

0061

いくつかの例において、バイナリ演算子の場合、子演算子をクエリ演算子としてマークしてもよい。また、クエリプラン全体のトラバース後にクエリ演算子が識別されない場合、ルートをクエリ演算子としてマークしてもよい。演算子がクエリ演算子として識別された後、インスタンス化フェイズの間にイズクエリ演算子(isQueryOperator)フラグがセットされた場合、構築されたアーカイバクエリを実行する方法が演算子ファクトリコードからコールされるであろう。次に、戻された結果セットをタプルのセットに変換すればよく、リストを実行演算子インスタンスにセットすればよい。このようにして、インスタンス化されると、状態を必要とする実行演算子は、その状態を初期化するのに十分であろうタプルのリストを有し得る。インスタンス化されると、これらタプルを用いて状態を初期化しこれを下流に伝搬する方法をコールするトポロジー順でクエリプランに対してもう1つのパスを行なえばよい。この方法は演算子固有であってもよく、および/または、初期化処理は、シノプシスの投入、内部データ構造の維持等と同様であってもよい。

0062

いくつかの例において、「売上高」のアーカイブされたリレーション154の上の下記CQLクエリを実装してもよい。

0063

0064

いくつかの例において、CQLエンジン156においてコンパイルされたときのクエリプランは、次のように説明することができる。

0065

0066

いくつかの例において、CQLエンジン156は、上記クエリをコンパイルするとき、このクエリは、その起動時の状態は外部から利用することができ潜在的に大きい可能性があるリレーション(たとえばアーカイブされたリレーション154)に対して表現されると、判断し得る。CQLには、ステートフルな演算子(たとえばGROUP BY、PATTERN)のセットがある一方で、ステートフルでない演算子(たとえばFILTER、PROJECT、OUTPUT)があるであろう。状態初期化アルゴリズムは、考慮するシナリオに対して次のように機能し得る。すなわち、REL_SOURCE演算子は、アーカイブされたリレーションに対してステートレスなので、アーカイバのコールをスキップし得る。次のFILTERも、ステートレスなので、状態に対するアーカイバのコールをスキップし得る。次に、GROUP BY演算子に遭遇する可能性があり、これは、アーカイバを呼出し、下記SQLクエリ(希望に応じてアーカイバクエリはサブクエリに基づく手法を用いて形成されたクエリであってもよく下記のものよりも複雑であってもよい)を用いて、その状態を満たしてもよい。

0067

0068

なお、ユーザのクエリはCOUNT集計を含まないかもしれないが、GROUP BYはCOUNT集計を有するSQLクエリを発行し得る。その理由は次の通りである。この情報を、(その状態の一部としての)GROUP BY演算子によって要求して、グループ(この例では「productid」に対応する)が空になりグループに関連して使用し得る何等かのリソースを(メモリのように)解放するか否か、判断することができる。

0069

次に、−veタプルが到着した状況について考える。上記シナリオにおいて、REL_SOURCEは、状態を維持しないかもしれず、その場合、一連の演算子の中の次の演算子に判断させるであろう(「通常の」CQLリレーションのように例外スローするのではなく)。FILTER演算子も、状態を維持しないかもしれず、その場合、同じようにするであろう。次に、GROUP BY演算子はタプルを見ることになるであろう。その状態は初期化されているので、対応するグループの位置を正しく確認し残りの処理を実行することができるであろう。たとえば、これが、region=「APAC」でproductid=「携帯電話」のタプルであれば、SUM集計関数は、タプルに存在する額だけ、「携帯電話」のその時点までの合計を減じるであろう。

0070

いくつかの例において、「売上高」のアーカイブされたリレーション154の上の下記CQLクエリを、上記例における合計ではなく中央値を求めるために実装してもよい。

0071

0072

いくつかの例において、CQLエンジン156においてコンパイルされたときのクエリプランは、次のように説明することができる。

0073

0074

いくつかの例において、状態初期化アルゴリズムは、考慮するシナリオに対して次のように機能する。REL_SOURCE演算子は、アーカイブされたリレーションに対してステートレスなので、アーカイバのコールをスキップし得る。次のFILTERも、ステートレスなので、状態に対するアーカイバのコールをスキップし得る。次に、GROUP BY演算子に遭遇する可能性がある。この演算子はステートフルなので状態の初期化を要求し得る。ここで、クエリは、少なくとも1つの包括的な(holistic)関数(MEDIAN)を必要とするので、集計された/要約状態をデータベースから得るだけでは十分でないかもしれない。MEDIANを計算する対象である値のセット全体を、GROUP BY状態に対して要求してもよい。

0075

したがって、この段階では、最下位のステートフル演算子を識別しており、かつ、より詳細な事項を要求してその状態を構成すると判断しているので、演算子プランを逆方向(すなわち「下に」)トラバースすればよい。すなわち、このプランをこの段階からは上から下にトラバースすればよい。いくつかの例において、状態を構築する責任は、ツリーにおいて下方向に次の演算子にある。この演算子はこの場合FILTERであり、これは、要求された値のセットをメモリに入れることができる以下のSQLクエリを(「アーカイバ」に)発行し得る。

0076

0077

いくつかの例において、これらタプルが取出されると、FILTERは、これら値を上流に伝搬してもよく、GROUP BYは、その状態を、ツリーまたはグラフ(たとえば、限定されないが増強された赤黒ツリー等)を構成することによって構築してもよい。このデータ構造によって、次の(O(log n)時間)増分MEDIAN計算を非常に高速で行なうことができる。いくつかの例において、上記クエリにFILTERがない場合、状態を構築する責任はREL_SOURCE演算子にあり、リレーションの全内容(最適化のように、クエリによってアクセスされる関連フィールドのみが、行全体ではなく各行に対して取出される。当然ながら、すべてのフィールドがアクセスされる場合は行全体がフェッチされる)がメモリに取込まれているであろう。

0078

いくつかの局面において、アーカイブされたリレーション154に基づいてクエリに到達するマイナスイベントを処理するためには、他のサポートが有用であろう。結合のような射影、バイナリ演算子等のCQLエンジン156演算子の中には、系統(lineage)シノプシスを維持するものがある。この系統シノプシスにおけるルックアップは、タプルIDに基づく。プラスタプルが届くと、これをシノプシスに挿入すればよい。この演算子にマイナスタプルが届くと、タプルIDに生じる系統シノプシスをルックアップする。アーカイブされたリレーション154のコンテキストに生じ得る問題は次の通りである。

0079

1.クエリが起動したとき、系統シノプシスを維持する演算子はクエリ演算子として識別される場合があり、これは、アーカイバにクエリし返された結果をタプルに変換し系統シノプシスに入れる場合がある。

0080

2.加えて、クエリが実行を開始したとき、これが受ける最初のタプルは、アーカイブされたプラスタプルのうちの1つに対応するマイナスタプルの場合がある。ここで、プラスおよびマイナスタプルのIDは一致しない場合があり、このことは、ルックアップの失敗および間違った結果につながる。

0081

3.通常のリレーションの場合、リレーションソースは、プラスおよびマイナスタプルが同一のIDを確実に有するようにするのに役立つであろう。なぜならこれはシノプシスを維持し得るからである。しかしながら、アーカイブされる場合は、これが可能でないことがある。

0082

このため、BEAM永続性レイヤはイベントIDを各イベントに割当てればよく、イベントの挿入(プラス)、削除(マイナス)、および更新通知はすべてこのIDの同一の値を有するであろう。この機能を利用することによって、上記問題を回避すればよい。したがって、もう一つの句をアーカイブされたリレーション154のDDLに追加することにより、EVENTIDENTIFIER句を指定すればよい。これは、CQL bigint型の列であってもよく、この列は、イベントのプラス、マイナス、および更新タプルについて同じ値を有するであろう。

0083

場合によっては、CQLエンジン156内で、EVENTIDENTIFIER句において指定された列を利用してもよい。たとえば、アーカイバがクエリされるとき、このフィールドは、選択リストに存在するように強制されてもよく、このフィールドの値を使用することにより、記録をタプルに変換する一方でタプルIDを設定してもよい。また、通常の入力イベントが来たとき(たとえばクエリが実行しているとき)、このフィールドにおける値には、タプルの値をリレーションソースコードのITupleに変換する一方で、タプルIDが割当てられてもよい。こうすることにより、イベントのプラスおよびマイナスが確実に同じタプルIDを有するようにするための構成が可能になるであろう。

0084

いくつかの例において、以下の構文をアーカイブされたリレーションのDDLに利用してもよい。

0085

0086

アーカイブされたリレーションを作成するためのこのDDLは、エンドユーザおよび他の構成要素からは見えない場合がある。たとえば、アーカイブされたリレーションの作成は、EPNがCQLプロセッサノードに接続されたデータオブジェクトノードを含むときに、CQLプロセッサコードにより、「隠れて」処理することができる。たとえば以下のEPNについて考える。

0087

0088

このEPNコードは、CQLエンジン156において作成するアーカイブされたリレーションの列名としてデータオブジェクトのフィールド名を使用してもよい。そうすることにより、フィールドの名称とフィールドの順序が確実に一致する。

0089

加えて、いくつかの例において、アーカイブされたストリームを、CQLエンジン156および/またはその他のエンジンを介して可能にしてもよい。概念上、アーカイブされたストリームは、アーカイブされたリレーションの特徴によく似ているかもしれない。しかしながら、ストリームとリレーションの間には意味の相違があるので、アーカイブされたリレーションの特徴との比較で、何らかの変更を、アーカイブされたストリームの設計および構文に行なえばよい。たとえば、リレーションの内容には、加算、更新、または削除が発生したときに、変化が生じ得る。このため、この内容は、時間の経過とともに、サイズが大きくまたは小さくなる可能性がある。しかしながら、ストリームの場合、定義により、更新および削除は不可能である。よって、ストリームのサイズは大きくなり続けるしかない。したがって、ストリームの過去の内容のサイズは非常に大きく、ほとんどの場合、ユーザは、アーカイバによって維持される直近の過去のサブセットにしか興味がない。

0090

このため、以下の構文をアーカイブされたストリームのDDLに利用してもよい。

0091

0092

ここで、ARCHIVERおよびENTITY句は、アーカイブされたリレーション154と同じ意味を有し得る。しかしながら、EVENT IDENTIFIER句は必要でないかもしれない。なぜなら、これは一般的に、ストリームに対して入力として到来することができないマイナスイベントを扱うだけだからである。加えて、REPLAY LAST句によって、ユーザは、興味ある直近の過去の部分を指定することができる。ユーザはこれを、時間範囲として、または行の数によって指定することができる。よって、たとえば、REPLAY句は、REPLAY LAST 30MINUTES(この場合過去30分において到達した記録をアーカイバからフェッチすればよい)、または、REPLAY LAST 50ROWS(この場合、到着時間で並べられた最新の50記録をアーカイバからフェッチすればよい)であってもよい。

0093

TIMESTAMPCOLUMN句は、アーカイバにクエリしている間に返されるであろう記録の識別に利用してもよい。これは、アーカイバクエリの結果セットの一部である記録を決定するアーカイバクエリのWHERE句において使用してもよい。この列の値は、タイムスタンプをCQLエンジン156内部のタプル(アーカイバにクエリすることによって得られる)に割当てる間に利用してもよい。この列の名称は、BEAM永続性によって割当てられた作成タイムスタンプを有するDO内の列の名称である可能性がある。

0094

加えて、いくつかの例において、構成ウィンドウモジュール150は、CQLエンジン156の1つ以上のアーカイブされたリレーション154を構成するためのウィンドウサイズ158を、生成する、受ける、および/または決定するように構成されてもよい。しかしながら、いくつかの例において、アーカイブされたリレーションに対して異なるウィンドウサイズを定めても、アーカイブされたリレーションの別々のインスタンスは作成されないかもしれない。むしろ、ウィンドウが適用されたとき、アーカイブされたリレーションのインスタンスは1つしかないかもしれず、ウィンドウは、特定のクエリにとって「興味」があるアーカイブされたリレーションにおけるデータを求めればよい。上記のように、ウィンドウサイズ158は、アーカイブされたリレーション154のウィンドウw1、w2、および/またはwNのサイズを構成し得る。このようにして、ユーザは、ウィンドウサイズを制御することができ、希望に応じて、ビジネスイベントデータおよび/または個人的関心、ビジネスの目標、および/またはその他の要素に関連する情報に少なくとも基づいて、ウィンドウのサイズを指定すればよい。

0095

さらに、いくつかの例において、イベントカウントモジュール152は、CQLエンジン156内で、または、ストリームもしくはアーカイブされたリレーション154の中の変更イベントを正しくカウントできるように構成されたその他のエンジン内で、1つ以上のリスニングサービス160を実装するように構成されてもよい。簡単に述べたように、連続クエリ162が、CQLエンジン156によって管理されるストリームおよび/またはアーカイブされたリレーション164に対する従属性を示すとき、CQLエンジン156はリスニングサービス160を実装してもよい。少なくともいくつかの例において、リスニングサービスを実装するタイミングにより、ストリーム/リレーション164の中の変更イベントが正しくカウントされるか否かを判断することができる。加えて、上記のように、いくつかの例において、連続クエリ162は、履歴および/またはウェアハウスデータのデータ記憶装置166に対してクエリすることによって、アーカイブされたリレーション164のデータを初期化するように、構成されてもよい。

0096

いくつかの例において、クエリがCQLエンジン156内で実行されるとき、これは、最初にクエリをデータオブジェクト補助記憶装置に対して実行することによってデータオブジェクトの現在の状態を確立してからデータオブジェクトからの変更通知をリッスンし処理する場合がある。そうすると2つの問題が生じる。すなわち、CQLエンジン156が最初のクエリを実行している間に変更通知が見落とされるかもしれないことであり、もう1つは、最初のクエリに変更が既にあった場合変更通知が二重カウントされるかもしれないことである。

0097

変更通知の見落としは、最初のクエリが起動される前に変更通知リスナーを確立するが、アーカイバクエリ実行が完了するまでおよび/または状態初期化がなされるまでこれらを処理しないことによって、解消することができる。これら変更通知は、CQLエンジン156がこれらを処理する準備ができるまで、メッセージングサービス(JMS)にバッファすればよい。場合によっては、変更通知の二重カウントの解消を、追加情報を永続性サービスに提供することで、どの変更通知が最初のクエリ結果に含まれどの変更通知がこれに含まれていないかCQLエンジン156に判断させることにより、実行してもよい。

0098

いくつかの例において、最後のトランザクションのトランザクションIDを含む各データオブジェクトに、その他の列を追加する(たとえばDATAOBJECT_ID)ことにより、このデータオブジェクトのインスタンス(行)に影響を及ぼしてもよい。しかしながら、他の例では、その他の列は追加せず、その代わりにトランザクションのコンテキストを利用してもよい。このトランザクションIDは、JTAのような他のトランザクション機構と混同されない内部BEAMアーティファクトであってもよい。このトランザクションIDは、いくつかの例において、単調に増加する整数であってもよい。同一のJTAトランザクションによって修正されるいくつか(またはすべて)のデータオブジェクトインスタンス(たとえば行)を、同一のトランザクションIDでタグ付けしてもよい。加えて、トランザクションIDを昇順でコミットしてもよい。この同じ列は、データオブジェクト変更通知に含まれていてもよい。上述のことから、クエリがMAX(DATAOBJECT_TID)を含む場合、クエリ結果において最大のトランザクションIDはわかっているであろう。このため、変更通知におけるトランザクションIDの値を、最大値と比較すればよい。なぜなら、それよりも小さいかまたはそれに等しい値は無視すればよく(すなわち既にカウントされているであろうから)、それよりも大きな値を処理すればよい(まだカウントされていないであろうから)。

0099

しかしながら、場合によっては、トランザクションIDを昇順でコミットするために、データオブジェクトトランザクションを順番に並べてもよい。しかしながら、これは同時性不利益な影響を与え得る。それでも、同時性は、コンテキストIDの概念を導入することによって高めることができる。いくつかの例において、各コンテキストIDはそれ自身のトランザクションIDを維持してもよい。BEAMデータオブジェクトに対して演算を実行するJTAトランザクションが、BEAMコンテキストへの包括的アクセスを得てもよい。次に、同じBEAMコンテキストを、上記JTAトランザクションによって実行される演算(たとえばすべての演算)に使用してもよく、最終的には、JTAトランザクションのコミットまたはロールバック時に解放すればよい。こうすれば、BEAMコンテキストにおいて処理を並列に進めることができる。よって、同時性のレベルは、BEAMコンテキストの割当てに釣合ったものになるであろう。その他の列(DATAOBJECT_CID)を、各データオブジェクトに追加することにより、最後のコンテキストのIDを保持して、そのデータオブジェクトのインスタンス(行)を修正することができる。しかしながら、他の例では、その他の列は追加されず、その代わりにトランザクションコンテキストを利用してもよい。コンテキストIDは、トランザクションIDのように、データオブジェクトの変更通知に含まれてもよい。しかしながら、これにより、二重カウントを解消するためにコンテキストIDに対してMAX(DATAOBJECT_TID)を取得することを必要とし得るという点において、クエリ側に対する要求が変化し得る。

0100

いくつかの例において、同じレベルの同時性は、トランザクションコンテキストエンティティの概念が導入されるのであれば、データオブジェクトに他の列を追加することなく、得ることができる。次に、新たなJavaクラスおよび関連するJPAエンティティを作成してデータベースにおけるコンテキストIDの状態を維持してもよい。トランザクションコンテキストエンティティは、コンテキストIDと、関連する(最大、最後に使用された)トランザクションIDとを含み得る。コンテキストIDはシーケンスとして生成してもよく、エンティティに対する主キーであってもよい。

0101

永続性サービスは、初期化されると、構成された数のトランザクションコンテキストインスタンスを作成してもよい。これらトランザクションコンテキストインスタンスは、この永続性サービスが単独使用するためのものであってもよい。別の永続性サービスが別のサーバ上で初期化される場合、これも、構成された数のトランザクションコンテキストインスタンスを作成してもよい。このやり方で、各永続性サービスがコンテキストの固有のセットを有することを保証してもよい。永続性サービスは、トランザクションコンテキストのインスタンスを作成してもよく、これらをJPAを介して存続させてもよい。これはシーケンス状に並べられたエンティティでありこのシーケンスはコンテキストIDであるので、作成されたトランザクションコンテキストインスタンスは自動的に固有のものである。作成された各トランザクションコンテキストは次の連続番号を得るであろう。永続性サービスは、シャットダウンされるとき、作成したトランザクションコンテキストインスタンスを削除してもよい。場合によっては、これによってインスタンスがデータベースから削除されてもよい。

0102

いくつかの例において、データオブジェクト演算(たとえばすべてのまたはいくつかのデータオブジェクト演算)は、最終的にはEJB法(たとえばプロセスデータオブジェクト演算と呼ばれる)によって行なってもよい。この方法は、挿入、更新、アップサート(upsert)、および/または削除に対する派生があるデータオブジェクト演算の集合体を利用してもよい。各データオブジェクト演算は、対象とするデータオブジェクトを、名称、特定の演算、およびこの演算に必要なデータによって、指定してもよい。データオブジェクト演算は、データオブジェクト演算の対象および/または任意の数のデータオブジェクトの組合わせを含み得る。データオブジェクト演算は、演算がデータオブジェクト演算に追加された順序で実行してもよい。プロセスデータオブジェクト演算法は、TransactionAttributeType.REQUIREDとして定義してもよく、これは、JTAトランザクション内でコールされた場合このトランザクションに参加し得ることを意味する。しかしながらJTAトランザクション外でコールされた場合、アプリケーションサーバは、JTAトランザクションを、この方法のコールの期間中に起動してもよい。いくつかの例において、このことは、プロセスデータオブジェクト演算が常にJTAトランザクション内で機能しているであろうことを意味する。加えて、データオブジェクトに対するすべてのまたはいくつかの演算は、JTAトランザクション内で発生し得る。

0103

いくつかの例において、変更イベントの二重カウントの解消は、以下の動作によって可能になるであろう(これは希望に応じて任意の適切な順序で実行すればよい)。たとえば、プロセスデータオブジェクト演算がコールされたときに以下の動作を行なう(以下の動作には番号が付けられているが、これらの番号は、説明を助けるためのものに過ぎず、この一組の動作を特定の順序または必要な何らかの動作に限定するものではない)。

0104

1.関連するJTAトランザクションからトランザクションコンテキストをフェッチすることを試みてもよい。関連するトランザクションコンテキストがある場合はそれを使用すればよい。しかしながら、関連するトランザクションコンテキストがない場合は次のようにする。

0105

a)起動時に永続性サービスによって作成された利用可能なトランザクションコンテキストインスタンスのセット(プール)からのトランザクションコンテキストインスタンスに対する排他ロックを取得してもよい。トランザクションコンテキストが利用可能でなければ、トランザクションコンテキストが利用可能になるまでコールをブロックしてもよい。このロックはJavaおよび/またはデータベースにおいて行なってもよい。

0106

b)このトランザクションコンテキストにおけるトランザクションIDを、関連するJTAトランザクションのトランザクションIDとなり得る、一連の数のうちの次の数に増分してもよい。

0107

c)トランザクションコンテキストインスタンスを、JTAトランザクションに、アプリケーションリソースとして「添付」してもよい。そうすることによって、この1つのJTAトランザクションの中で複数のコールがなされた場合は、永続性サービスが、トランザクションコンテキストを、その関連するJTAトランザクション(たとえば上記1の動作のもの)を取得することができるであろう。これによって、JTAトランザクションがBEAMサーバの中から開始されようとBEAMサーバなしで開始されようと、同じJTAトランザクションの中で実行される動作に対して同じトランザクションコンテキストを使用できることを保証し得る。

0108

d)トランザクションコンテキストインスタンスを、トランザクション同期リスナーとして、関連するJTAトランザクションに追加してもよい。これによって、永続性サービスに、JTAトランザクションがいつ完了したか知らせて、適切な動作を行なえるようにすることができる。

0109

e)増分されたトランザクションIDを有するトランザクションコンテキストエンティティをマージしてもよい。いくつかの例において、このデータベース更新は、関連するJTAトランザクション内でも発生し得る。

0110

2.指定されたデータオブジェクト動作を実行してもよい。トリガされた変更通知を、トランザクションコンテキストからのコンテキストIDおよびトランザクションIDでタグ付けしてもよい。

0111

3.プロセスデータオブジェクト演算法のコールが終了し得る。
4.同じJTAトランザクション内で他のコールがなされた場合、上記動作1は、添付された」トランザクションコンテキストをピックアップして動作2に進めばよい。

0112

5.場合によって、JTAトランザクションがコミットするならば、
a)実行されたデータオブジェクト動作をデータベースにコミットしてもよい。

0113

b)データオブジェクトの変更通知を送ってもよい(JMS)。
c)トランザクションコンテキストのマージをコミットしてもよい。

0114

d)トランザクションが完了しトランザクションコンテキストを次のトランザクションによる使用のために解放してプールに戻し得ることを、永続性に通知してもよい。いくつかの局面において、これはコミット後のある時点で起こり得る。

0115

6.場合によって、JTAトランザクションがロールバックするならば、
a)実行されたデータオブジェクト動作をロールバックしてもよい。

0116

b)データオブジェクトの変更通知を破棄してもよい(JMS)。
c)BEAMトランザクションコンテキストのマージをロールバックしてもよい。

0117

d)トランザクションが完了したのでトランザクションコンテキストを次のトランザクションによる使用のために解放してプールに戻し得ることを、永続性に通知してもよい。いくつかの局面において、これはロールバック後に起こり得る。

0118

ある例において、クエリを実行して初期状態をデータオブジェクト補助記憶装置から取得するとき、クエリを不可分的に実行することにより、UNIONもトランザクションコンテキストテーブルに含めてもよい。このようにして、クエリ結果に加えて、クエリ結果におけるすべてのデータに対する各BEAMコンテキストの最大のコミットされたトランザクションIDを受けることができる。トランザクションコンテキスト情報は、データオブジェクトの変更通知を検査し変更通知におけるIDをトランザクションコンテキストテーブルにおけるIDと突合せて検査することによって二重カウントを解消することを、可能にする。これに代えてまたはこれに加えて、クエリの瞬間におけるスナップショット情報を、トランザクションコンテキストテーブルから得てもよい。このスナップショット情報は、CQLエンジンにおいて維持されてもよく、スナップショットID(増大する識別子)はこれと関連付けられてもよい。同じものを、このクエリのプランにおける選択されたいくつかの演算子の入力キューに設定してもよい。これらは、「コネクタ」演算子と呼ばれ、ローカルクエリプランがグローバル(全体)クエリプランに結合し得る場所を表わしてもよい。イベントがCQLエンジンに達すると、このイベントに対し、スナップショットIDを、その中のコンテキストIDおよびトランザクションIDの値を用いて計算してもよい。スナップショットIDは、CQLエンジンにおいて維持されているスナップショット情報を用いて計算してもよい。イベントのスナップショットIDは次に、入力キューのスナップショットIDと比較してもよい。イベントのID>キューのIDであれば、これを処理をしてもよく、そうでなければ、以前既に考慮されている可能性がありしたがって二重カウントを回避するために無視してもよい。

0119

いくつかの例において、永続性レイヤはコンテキストID(ワーカー(worker)識別子)およびトランザクションID(トランザクション識別子)に各変更イベント通知を与えてもよく、および/または、永続性レイヤはトランザクションコンテキストテーブルを維持してもよい。加えて、クエリ起動時に、CQLエンジンは、トランザクションコンテキストテーブルからの「スナップショット」情報(ワーカー識別子、トランザクション識別子対)にクエリし、増大するスナップショットIDをこれに関連付けてもよい。また、CQLエンジンは、起動時に「コネクタ」演算子の入力キューにスナップショットIDを設定してもよい。加えて、クエリ実行時に、CQLエンジンは、入力イベントにおけるワーカー識別子および/またはトランザクション識別子フィールドと、維持されている「スナップショット」情報を用いて、各入力イベントのスナップショットIDを計算してもよい。クエリ実行時に、CQLエンジンはまた、入力イベントのスナップショットIDを、(クエリ起動時の)入力キューにおいて設定されたものと比較することにより、イベントを処理するべきか無視すべきか判断してもよい。以下は、ワーカーおよびトランザクションID句のDDLの一般的な形態の一例である。

0120

0121

いくつかの例において、アーカイバ(Archiver)はCQサービスによって維持されてもよく、エンティティ(Entity)は引用されたストリングとしてのデータオブジェクトの名称であってもよく、イベントID(Event ID)はこのリレーションに対して固有イベントID列として機能し得るロングタイプの列であってもよく、ワーカーID(Worker ID)は永続性の生成された変更通知におけるコンテキストID列にマッピングし得るロングタイプの列であってもよく、トランザクションID(Transaction ID)は、永続性の生成された変更通知におけるトランザクションID列にマッピングし得るロングタイプの列であってもよい。以下は実装例である。

0122

0123

同様に、いくつかの例において、これら2つの句を、アーカイブされたストリームのREPLAY句の後に追加してもよい。

0124

先に述べたように、各データオブジェクトインスタンスを、これを修正した最新のコンテキストおよびトランザクションIDで実際にタグ付けする必要はないであろう。いくつかの例において、この情報は、代わりにトランザクションコンテキストエンティティから受けることができる。そうするための1つのやり方は、先に述べたように、データオブジェクトからの所望のデータおよびトランザクションコンテキストエンティティの内容双方に対して不可分的にクエリすることである。不可分性実現のために、これを1つのクエリのみを用いて実行してもよい。たとえば、UNION句を用いることにより、2つの異種のクエリからの結果セットを1つのクエリに追加することができる。いくつかの例において、上記データオブジェクトおよび/または永続性サービスは、図1のデータ記憶装置166によって実現してもよい。

0125

サービスプロバイダコンピュータ106および/またはユーザ装置104に存在し得るその他の種類のコンピュータ記録媒体(これも非一時的であってもよい)は、プログラマブルランダムアクセスメモリ(PRAM)、SRAM、DRAM、RAM、ROM、電気的に消去可能なプログラマブル読出専用メモリ(EEPROM)、フラッシュメモリもしくはその他のメモリ技術コンパクトディスク読出専用メモリ(CD−ROM)、デジタル汎用ディスク(DVD)もしくはその他の記憶装置、磁気カセット磁気テープ磁気ディスク記憶装置もしくはその他の磁気記憶装置、または、所望の情報を格納するのに使用することができサービスプロバイダコンピュータ106および/またはユーザ装置104からアクセス可能なその他の媒体を含み得るがこれらに限定されない。上記のうちのいずれかを組合わせたものも、コンピュータ読取可能な媒体の範囲に含まれるはずである。

0126

これに代えて、コンピュータ読取可能な通信媒体が、コンピュータ読取可能な命令、プログラムモジュール、または、搬送波等のデータ信号内で伝送されるその他のデータ、またはその他の伝送を含む場合がある。しかしながら、本明細書で使用されるコンピュータ読取可能な記録媒体は、コンピュータ読取可能な通信媒体を含まない。

0127

図2は簡略ブロック図200を示し、これを用いて、アーカイブされたリレーションを有する連続クエリの管理の特徴を説明することができる。上記の、いくつかの例における、アーカイブされたリレーション、構成可能なアーカイブされたリレーションのウィンドウ、および/または変更イベントのカウントについて、本明細書で説明することができる。示されるように、図2は、(たとえば射影203に関連する)アーカイブされたリレーションを管理するための、CQLエンジン156および/またはCQサービス202の、少なくとも1つの実装例を示す。いくつかの例において、アーカイブされリレーションを含むクエリ(たとえば連続クエリ)162が識別されたとき(たとえば、射影203に関連するグループ化(Group By)演算子204および/または売上情報(Sales Info)演算子206が、ストリームまたは履歴データではなくアーカイブされたリレーションを参照する場合)、CQLエンジン156は、このクエリ162をパース(parse)してCQサービス202のアーカイバ208に送ってもよい。加えて、いくつかの例において、CQLエンジン156は、この場合クエリ演算子としてのGroupAggr(またはグループ化204)演算子を識別してもよく、この演算子のためのアーカイバクエリを構成してもよい。このアーカイバクエリは次にアーカイバ208に送ってもよい。場合によっては、この時点で、CQサービス202は外に出てスナップショットを得てもよい(たとえば永続的データ記憶装置166からおよび/またはBIサーバから)。また、永続性レイヤ(BI/DBを含む)210は多数のエントリを有し得るが、(たとえばグループ化演算子204があるので)CQサービス202は積の合計を取出すだけでよい。このため、CQLエンジン156は、変更イベント212と履歴データ166双方を受けることができる。そこで、出力214は、データ記憶装置166からの元の履歴データに加えて取出した変更イベント212を反映し得る。いくつかの例において、−12,75という変更イベントを受けると、+12,125は、出力214における更新された合計値を反映し得る。CQLサービス202を変更イベント212につなぐ点線で示した矢印は、CQLサービス202が、変更イベントを、永続性レイヤ210から受けた後にCQLエンジン156に送ることができることを示している。クエリ162における上向きの矢印は、クエリ162に関連するクエリプランにおけるイベントの流れを示すことを意図している。

0128

図3は、本開示の実施形態を取入れることができるイベント処理システム300の簡略化された高レベルの図を示す。イベント処理システム300は、1つ以上のイベントソース(304,306,308)と、イベントストリームを処理するための環境を提供するように構成されたイベント処理サーバEPS)302と、1つ以上のイベントシンク(310,312)とを含み得る。イベントソースは、EPS302が受けるイベントストリームを生成する。EPS302は、1つ以上のイベントストリームを1つ以上のイベントソースから受けることができる。たとえば、図3に示されるように、EPS302は、入力イベントストリーム314をイベントソース304から受け、第2の入力イベントストリーム316をイベントソース306から受け、第3のイベントストリーム318をイベントソース308から受ける。1つ以上のイベント処理アプリケーション(320,322,324)をEPS302上で展開しEPS302によって実行することができる。EPS302によって実行されるイベント処理アプリケーションは、1つ以上の入力イベントストリームをリッスンし、顕著なイベントとして入力イベントストリームから1つ以上のイベントを選択する処理ロジックに基づいて1つ以上のイベントストリームを介して受けたイベントを処理するように、構成されてもよい。顕著なイベントは次に、1つ以上の出力イベントストリームの形態の1つ以上のイベントシンク(310,312)に送ってもよい。たとえば、図3において、EPS302は、出力イベントストリーム326をイベントシンク310に出力し、第2の出力イベントストリーム328をイベントシンク312に出力する。ある実施形態において、イベントソース、イベント処理アプリケーション、およびイベントシンクは、他の構成要素の変更を引起すことなくこれら構成要素のうちのいずれかを追加または削除することができるように、相互に切離される。

0129

ある実施形態において、EPS302は、共有サービスを有する、Equinox OSGiに基づくもののような、軽量Javaアプリケーションコンテナを含むJavaサーバとして実装してもよい。いくつかの実施形態において、EPS302は、たとえば、イベントの処理における極めて高いスループットおよびマイクロ秒レイテンシを、JRockkit Real Timeを使用することによってサポートし得る。EPS302はまた、イベント処理アプリケーションを開発するためのツール(たとえばOracle CEP VisualizerおよびOracle CEP IDE)を含む開発プラットフォーム(たとえば完全リアルタイムエンドツーエンドJavaイベント駆動アーキテクチャ(EDA)開発プラットフォーム)を提供し得る。

0130

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

0131

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

0132

制約がないという性質があるので、イベントストリームを介して受けるデータの量は、一般的に非常に多い。結果として、クエリのためにすべてのデータを格納またはアーカイブすることは、一般的に実用的ではなく望ましくない。イベントストリームの処理では、イベントをEPS302が受けるときに、受けたイベントのデータすべてを格納しなくても、イベントをリアルタイムで処理することが、必要である。したがって、EPS302は、イベントをEPS302が受けるときに受けたイベントすべてを格納しなくても、イベントを処理できるようにする特別なクエリ機構を提供する。

0133

イベント駆動型アプリケーションルール駆動型であり、これらルールは、入力ストリームを処理するのに使用される連続クエリの形態で表わすことができる。連続クエリは、受けたイベントに対して実行すべき処理を識別する命令(たとえばビジネスロジック)を含み得る。これは、クエリ処理の結果としてどのようなイベントを顕著なイベントとして選択し出力すべきかを含む。連続クエリは、データ格納装置に存続させ、イベントの入力ストリームを処理しイベントの出力ストリームを生成するために使用することができる。連続クエリは、典型的にはフィルタリングおよび集計関数を実行することにより、入力イベントストリームから顕著なイベントストリームを発見して抽出する。結果として、出力イベントストリームにおける外部へのイベントの数は一般的に、イベントを選択する元になった入力イベントストリームのイベントの数よりも遥かに少ない。

0134

有限のデータ集合に対して一度実行されるSQLクエリと異なり、特定のイベントストリームに対する、EPS302にアプリケーションによって登録されている連続クエリは、このイベントストリームにおいてイベントを受ける度に実行し得る。連続クエリの実行の一部として、EPS302は、受けたイベントを、連続クエリによって指定された命令に基づいて評価することにより、連続クエリ実行の結果として、1つ以上のイベントを顕著なイベントとして選択して出力するか否か判断する。

0135

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

0136

一実施形態において、イベント処理アプリケーションは、以下の構成要素タイプからなるものであってもよい。
(1)入力および出力ストリームならびにリレーションソースおよびシンクに対して直接インターフェイスする1つ以上のアダプタ。アダプタは、入力および出力ストリームプロトコルを理解するように構成され、イベントデータを、アプリケーションプロセッサによってクエリできる正規化された形態に変換する役割を果たす。アダプタは、正規化されたイベントデータを、チャネルまたは出力ストリームおよびリレーションシンクに送ってもよい。イベントアダプタは、さまざまなデータソースおよびシンクに対して定めることができる。
(2)イベント処理の終点として機能する1つ以上のチャネル。特に、チャネルは、イベントデータを、イベント処理エージェントがそれに対して働くことが可能になる時点まで、キューに入れておく役割を果たす。
(3)1つ以上のアプリケーションプロセッサ(またはイベント処理エージェント)が、チャネルからの正規化されたイベントデータを消費し、クエリを用いてこれを処理することで顕著なイベントを選択し、選択された顕著なイベントを出力チャネルに送る(またはコピーする)ように、構成される。
(4)1つ以上のビーン(bean)が、出力チャネルをリッスンするように構成され、出力チャネルへの新たなイベントの挿入によってトリガされる。いくつかの実施形態において、このユーザコードは、plain-old-Java-object(POJO)である。ユーザアプリケーションは、一組の、JMS、ウェブサービス、およびファイルライタ(writer)といった外部サービスを利用することによって、生成されたイベントを外部イベントシンクに送ることができる。
(5)イベントビーンは、出力チャネルをリッスンするために登録されてもよく、出力チャネルへの新たなイベントの挿入によってトリガされる。いくつかの実施形態において、このユーザコードは、Oracle CEPイベントビーンAPIを用い、このビーンをOracle CEPによって管理できるようにしてもよい。

0137

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

0138

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

0139

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

0140

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

0141

図4は簡略ブロック図400を示し、これを用いてアーカイブされたリレーションの管理の特徴を説明することができる。図4に示されるように、アーカイブされたリレーションは、クエリグラフ402として表わすことができる。いくつかの例において、クエリグラフ402は、クエリの演算子を表わすノードおよびクエリグラフ402の演算子間の経路を表わす頂点を含み得る。限定されない1つの例において、図4のクエリグラフ402は、射影演算子404と、グループ化演算子406と、リレーショナルソース演算子408とを含む。さらに、いくつかの例において、射影演算子404およびリレーショナルソース408はステートレスでもよく、グループ化演算子406はステートフルでもよい。場合によっては、ステートレス演算子は、状態を、追跡、管理、または要求しないが、ステートフル演算子は、状態を、追跡、管理、または要求する。上記のように、いくつかの例において、クエリグラフ402を、上から下へというやり方で分析または評価し410、ステートフル演算子(いくつかの例では第1のまたは最下位のステートフル演算子)における履歴データをインポートしてもよい。クエリグラフ402を分析する410間に、クエリグラフ402における第1のステートフル演算子を決定するように、サービスおよび/またはエンジン(たとえば図1図3を参照しながら説明したCQサービス202および/またはCQLエンジン156)を構成してもよい。図4の例において、第1のステートフル演算子はグループ化406である。このため、412で、サービスが射影演算子404(この例ではステートレス)に達したとき、テーブルデータ(すなわち履歴データ)はインポートしなくてよい。しかしながら、414で、グループ化演算子406に達したとき、履歴、ウェアハウス、および/またはテーブルデータをインポートして、アーカイブされたリレーションを初期化すればよい。

0142

これに代えてまたはこれに加えて、いくつかの例において、クエリグラフ402(プランとも呼ばれる)を、ソース(ここではリレーショナルソース演算子408)から初めてトポロジーの順にトラバースしてもよい。このため、この例において、トラバースは下から上へというやり方でもよい。このトラバースにおいて、第1のステートフル演算子に達したとき、これをクエリ演算子としてマークしてもよく、よって、グラフ402をこの分岐においてさらにトラバースする必要はない。なお、aggregate distinctのようないくつかのCQLクエリの場合、クエリプランは2つ以上の分岐を有し得る。この例において、リレーショナルソース408はステートレスでもよく、そうすると、トラバースは上方向でありグループ化406を見ることになるであろう。グループ化406はステートフルなので、これは、クエリ演算子としてマークしてもよい。よって、トラバースは完了することができ、射影演算子404まで上る必要はないであろう。なぜなら、グループ化406はアーカイバにクエリし、その状態を埋め、また、スナップショット出力を射影404に伝搬しさらに下流の演算子があればそこに伝搬する。

0143

図5は、(上記)TRANSACTION_CIDおよび/またはTRANSACTION_TID等であるがこれらに限定されない1つ以上のテーブルIDを利用して、アーカイブされたリレーションに関連する変更イベントをカウントするための、限定されない少なくとも1つの例500を示す。図5に示されるように、最初のトランザクションコンテキストテーブル502および挿入後のトランザクションコンテキストテーブル504が示されている。いくつかの例において、トランザクションIDを管理するように構成されたサーバを、初期化するかそうでなければ起動すればよい。永続性サービスは、このサーバによって起動されると、1組のトランザクションインスタンスを作成し得る。このため、トランザクションコンテキストテーブル502は、自身が使用するために10のコンテキストインスタンスを作成した1つの永続性サービスの起動後の内容を示す。TRANSACTION_CID列はコンテキストIDを含み、TRANSACTION_TID列はこのコンテキストIDによってコミットされる最大トランザクションIDを含む。

0144

限定されない1つの例において、この時点で、これも自身が使用するために10のコンテキストインスタンスを作成した第2の永続性サービスが起動した場合、テーブル02は、11〜20というTRANSACTION_CIDの値を有する10の新たなエントリを示し得る。この時点で、永続性サービスは実行しているので、データオブジェクト列データタイプ各々を1つずつ含む「アルファ」という名称のデータオブジェクトが作成されるであろう。いくつかの例において、データオブジェクトが作成される度に、永続性サービスはこのデータオブジェクトに対する永続性記憶装置を表わす、対応するデータベースビューを作成してもよい。ある例において、データオブジェクトが生成されると、挿入コマンドがこれに対して実行されてもよい。コンテキストおよびトランザクションIDの処理を最も適切に示すために、合計24の挿入に対して12のスレッドを用いる1スレッド当たり2つの挿入動作が行なわれてもよい。各スレッドは、JTAトランザクションを開始し、1つの挿入動作を実行し、第2の挿入動作を実行し、次にトランザクションをコミットしてもよい。複数のスレッドを用いる理由は、そうすれば、並列に実行する複数のJTAトランザクションを作成し得るからであり、このことは、如何にしてコンテキストIDが機能するようになるかをより適切に示すであろう。これはまた、複数の(この例では1スレッド当たり2つ)データオブジェクト動作方法コールが同じJTAトランザクションにおいてなされかつこのJTAトランザクションが永続性の外で開始されコミットされたというシナリオを実証する。

0145

この例の場合、12のスレッドがコードを同時に実行しているであろう。各スレッドは、サーバの外側でトランザクションを開始し、2つの挿入コールを永続性に対して行ない、その後このトランザクションをコミットし得る。永続性は10のコンテキストIDを割当てているので、これらスレッドのうち、10個はコンテキストを取得するが、2個は最初にブロックされるであろう。2つのJTAトランザクションを、別のJTAトランザクションが完了しコンテキストを解放するまでブロックしてもよい。ブロックされたJTAトランザクションは次に、解放されたコンテキストを捕捉し永続性APIコールを処理すればよい。いくつかの例において、挿入動作の完了後、テーブル504(挿入後)の検査はまさにこの結果を示す。トランザクションコンテキスト1および2は、トランザクションID2を「最後にコミットされた」トランザクションIDとして示し、他のすべてのトランザクションコンテキストはトランザクションID1をこれらの最後にコミットされたトランザクションとして示す。

0146

いくつかの例において、データオブジェクト変更通知は、この例において実行された挿入動作の結果としてJMSを介してブロードキャストしてもよい。1つのJTAトランザクション当たり2つの挿入が実行され、合計24の挿入動作に対して12のトランザクションが実行されたことを想起されたい。トランザクションコンテキスト1および2は、2つのトランザクション各々に対して使用されたので、2つの挿入についてのトランザクションID1およびその他2つの挿入についてのトランザクションID2を有するコンテキスト1および2からの4つの変更通知を見ることになるはずである。他のすべてのコンテキストは、トランザクション1つのみに対して使用されたので、いずれもトランザクションID1を有する2つの挿入を生成しているはずである。

0147

図6図8は、本明細書に記載のアーカイブされたリレーションを有する連続クエリの管理を実装するためのプロセス600、700、および800をそれぞれ示すフロー図の例を示す。これらプロセス600、700、800は、論理フロー図として示され、その各動作は、ハードウェア、コンピュータ命令、またはこれらの組合わせにおいて実装することができる一連の動作を表わす。コンピュータ命令という文脈において、動作は、1つ以上のプロセッサによって実行されるときに、記載されている動作を実行する1つ以上のコンピュータ読取可能な記録媒体に格納されているコンピュータにより実行可能な命令を表わす。一般的に、コンピュータにより実行可能な命令は、特定の機能を果たすまたは特定のデータタイプを実装する、ルーチン、プログラム、オブジェクト、構成要素、データ構造等を含む。動作を説明する順序は限定として解釈されることを意図しておらず、記載されている動作のいくつかを任意の順序でおよび/または並列に組合わせてプロセスを実装することができる。

0148

加えて、プロセスのうちのいくつか、いずれか、またはすべてを、実行可能な命令とともに構成された1つ以上のコンピュータシステムの制御下で実行してもよく、1つ以上のプロセッサ上で、ハードウェアによって、またはこれらの組合わせによって一括で実行するコード(たとえば実行可能な命令、1つ以上のコンピュータプログラム、または1つ以上のアプリケーション)として実装してもよい。上記のように、コードは、たとえば1つ以上のプロセッサにより実行可能な複数の命令を含むコンピュータプログラムの形態で、コンピュータ読取可能な記録媒体に格納してもよい。コンピュータ読取可能な記録媒体は非一時的なものであってもよい。

0149

いくつかの例において、少なくとも図1(およびその他の図面)に示される(たとえば少なくともアーカイブリレーションモジュール148を利用する)1つ以上のサービスプロバイダコンピュータ106は、図6のプロセス600を実行し得る。プロセス600は、602で、アーカイブされたストリームまたはアーカイブされたリレーションをデータソースとして識別するクエリを識別するおよび/または受けることを含むことから始まり得る。いくつかの例において、プロセス600は、604で、履歴データを用いてクエリを初期化することを含み得る。プロセス600は、606で、アーカイブされたストリームまたはアーカイブされたリレーションおよび履歴データに少なくとも一部基づいてクエリを評価することを含み得る。プロセス600はまた、608で、クエリの演算子を表わすクエリグラフを形成することを含み得る。プロセス600は、610で、クエリグラフをグラフの上から下にトラバースすることを含み得る。さらに、いくつかの例において、プロセス600は、612で、クエリグラフにおいて識別された第1のステートフル演算子における履歴データを用いてクエリを初期化することを含むことで、終了し得る。

0150

図7は、本明細書に記載のアーカイブされたリレーションを有する連続クエリの管理を実装するためのプロセス700を示すフロー図の例を示す。少なくとも図1に示される(たとえば少なくともアーカイブリレーションモジュール148を利用する)1つ以上のサービスプロバイダコンピュータ106は、図7のプロセス700を実行し得る。プロセス700は、702で、連続クエリを受けて、データストリームまたは履歴データのIDを含むデータストリームまたはアーカイブされたリレーションを処理することを含むことから始まり得る。プロセス700は、704で、受けた連続クエリに少なくとも一部基づいてクエリグラフを生成することを含み得る。加えて、いくつかの例において、プロセス700は、履歴データの一部を用いて連続クエリを初期化することを含み得る。さらに、プロセス700は、708で、データストリームまたはアーカイブされたリレーションに関して履歴データに少なくとも一部基づいて連続クエリを評価することを含むことで、終了し得る。

0151

図8は、本明細書に記載のアーカイブされたリレーションを有する連続クエリの管理を実装するためのプロセス800を示すフロー図の例を示す。少なくとも図1に示される(たとえば少なくともアーカイブリレーションモジュール148を利用する)1つ以上のサービスプロバイダコンピュータ106は、図8のプロセス800を実行し得る。プロセス800は、802で、連続クエリを受けて、ビジネスイベントデータに関連するストリームまたはアーカイブされたリレーションを処理することを含むことから始まり得る。プロセス800は、804で、連続クエリに少なくとも一部基づいてクエリグラフを生成することを含み得る。プロセス800は、806で、クエリグラフを、ソースからトポロジーに従ってトラバースして、最下位のステートフル演算子(たとえば最下位のステートフル演算子はトラバース中に識別される最後のステートフル演算子であってもよく、および/または、これは分岐の演算子であってもよい)。いくつかの例において、プロセス800は、808で、クエリの演算子に少なくとも一部基づいて初期化のための履歴データの最適量を決定することを含み得る。プロセス800は、810で、識別された最下位のステートフル演算子における履歴データを用いて連続クエリを初期化することを含み得る。さらに、いくつかの例において、プロセス800は、812で、データストリームまたはアーカイブされたリレーションに関して履歴データに少なくとも一部基づいて連続クエリを評価することを含むことで、終了し得る。

0152

図9図11は、本明細書に記載の構成可能なデータウィンドウを有するアーカイブされたリレーションを実装するためのプロセス900、1000、および1100をそれぞれ示すフロー図の例を示す。これらプロセス900、1000、1100は、論理フロー図として示され、その各動作は、ハードウェア、コンピュータ命令、またはこれらの組合わせにおいて実装することができる一連の動作を表わす。コンピュータ命令という文脈において、動作は、1つ以上のプロセッサによって実行されるときに、記載されている動作を実行する1つ以上のコンピュータ読取可能な記録媒体に格納されているコンピュータにより実行可能な命令を表わす。一般的に、コンピュータにより実行可能な命令は、特定の機能を果たすまたは特定のデータタイプを実装する、ルーチン、プログラム、オブジェクト、構成要素、データ構造等を含む。動作を説明する順序は限定として解釈されることを意図しておらず、記載されている動作のいくつかを任意の順序でおよび/または並列に組合わせてプロセスを実装することができる。

0153

加えて、プロセスのうちのいくつか、いずれか、またはすべてを、実行可能な命令とともに構成された1つ以上のコンピュータシステムの制御下で実行してもよく、1つ以上のプロセッサ上で、ハードウェアによって、またはこれらの組合わせによって一括で実行するコード(たとえば実行可能な命令、1つ以上のコンピュータプログラム、または1つ以上のアプリケーション)として実装してもよい。上記のように、コードは、たとえば1つ以上のプロセッサにより実行可能な複数の命令を含むコンピュータプログラムの形態で、コンピュータ読取可能な記録媒体に格納してもよい。コンピュータ読取可能な記録媒体は非一時的なものであってもよい。

0154

いくつかの例において、少なくとも図1に示される(たとえば少なくとも構成可能ウィンドウモジュール150を利用する)1つ以上のサービスプロバイダコンピュータ106は、図9のプロセス900を実行し得る。プロセス900は、902で、データストリームまたはアーカイブされたリレーションを識別するクエリを識別するかそうでなければ受けることを含むことから始まり得る。プロセス900は、904で、ユーザにより構成されたウィンドウサイズを識別することを含み得る。プロセス900は、906で、履歴データを用いウィンドウサイズに少なくとも一部基づいてクエリを初期化することを含み得る。さらに、プロセス900は、908で、履歴データおよびアーカイブされたストリームまたはアーカイブされたリレーションに少なくとも一部基づいてクエリを評価することを含むことで、終了し得る。

0155

図10は、本明細書に記載の構成可能なデータウィンドウを有するアーカイブされたリレーションを実装するためのプロセス1000を示すフロー図の例を示す。少なくとも図1に示される(たとえば少なくとも構成可能ウィンドウモジュール150を利用する)1つ以上のサービスプロバイダコンピュータ106は、図10のプロセス1000を実行し得る。プロセス1000は、1002で、データストリームまたはアーカイブされたリレーションを処理するように構成された連続クエリを受けることを含むことから始まり得る。プロセス1000は、1004で、連続クエリに少なくとも一部基づいてクエリグラフを生成することを含み得る。プロセス1000は、1006で、データストリームまたはアーカイブされたリレーションを処理するように構成された連続クエリからウィンドウサイズを計算することを含み得る。いくつかの例において、プロセス1000は、1008で、ウィンドウサイズに少なくとも一部基づいて初期化のための履歴データの量を決定することを含み得る。プロセス1000は、1010で、決定した履歴データを用いて連続クエリを初期化することを含み得る。さらに、プロセス1000は、1012で、アーカイブされたストリームまたはアーカイブされたリレーション、およびウィンドウサイズに関して連続クエリを評価することを含み得る。

0156

図11は、本明細書に記載の構成可能なデータウィンドウを有するアーカイブされたリレーションを実装するためのプロセス1100を示すフロー図の例を示す。少なくとも図1に示される(たとえば少なくとも構成可能ウィンドウモジュール150を利用する)1つ以上のサービスプロバイダコンピュータ106は、図11のプロセス1100を実行し得る。プロセス1100は、1102で、アーカイブされたストリームまたはアーカイブされたリレーションを処理するように構成された連続クエリを受けることを含むことから始まり得る。1104で、連続クエリからウィンドウサイズを計算して、処理するストリームまたはアーカイブされたリレーションの有界範囲を識別することを含み得る。プロセス1100は、1106で、連続クエリに少なくとも一部基づいてクエリグラフを生成することを含み得る。加えて、いくつかの局面において、プロセス1100は、ステートフル演算子を識別するためにクエリグラフを下向きに(たとえば上から下へという手法)トラバースすることを含み得る。プロセス1100は、1110で、初期化のための履歴データの最適量を決定することを含み得る。プロセス1100は、1112で、識別されたステートフル演算子における履歴データを用いて連続クエリを初期化することを含み得る。さらに、いくつかの例において、プロセス1100は、ストリームまたはアーカイブされたリレーションに関してウィンドウサイズに少なくとも一部基づいて連続クエリを評価することを含み得る。

0157

図12図14は、本明細書に記載のアーカイブされたリレーションに関連するイベントカウントという特徴を実装するためのプロセス1200、1300、および1400をそれぞれ示すフロー図の例を示す。これらプロセス1200、1300、1400は、論理フロー図として示され、その各動作は、ハードウェア、コンピュータ命令、またはこれらの組合わせにおいて実装することができる一連の動作を表わす。コンピュータ命令という文脈において、動作は、1つ以上のプロセッサによって実行されるときに、記載されている動作を実行する1つ以上のコンピュータ読取可能な記録媒体に格納されているコンピュータにより実行可能な命令を表わす。一般的に、コンピュータにより実行可能な命令は、特定の機能を果たすまたは特定のデータタイプを実装する、ルーチン、プログラム、オブジェクト、構成要素、データ構造等を含む。動作を説明する順序は限定として解釈されることを意図しておらず、記載されている動作のいくつかを任意の順序でおよび/または並列に組合わせてプロセスを実装することができる。

0158

加えて、プロセスのうちのいくつか、いずれか、またはすべてを、実行可能な命令とともに構成された1つ以上のコンピュータシステムの制御下で実行してもよく、1つ以上のプロセッサ上で、ハードウェアによって、またはこれらの組合わせによって一括で実行するコード(たとえば実行可能な命令、1つ以上のコンピュータプログラム、または1つ以上のアプリケーション)として実装してもよい。上記のように、コードは、たとえば1つ以上のプロセッサにより実行可能な複数の命令を含むコンピュータプログラムの形態で、コンピュータ読取可能な記録媒体に格納してもよい。コンピュータ読取可能な記録媒体は非一時的なものであってもよい。

ページトップへ

この技術を出願した法人

この技術を発明した人物

ページトップへ

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

関連する公募課題

ページトップへ

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

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

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

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

ページトップへ

おススメ サービス

おススメ astavisionコンテンツ

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

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

関連性が強い 技術一覧

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

関連性が強い人物一覧

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

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

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

関連する公募課題一覧

astavision 新着記事

サイト情報について

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

主たる情報の出典

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