JP6899064B2 - データ・ストリーミング・アプリケーションにおけるフロー遅延を低減するためのコンピュータ実行方法、コンピュータ可読媒体、およびデータ処理装置 - Google Patents

Description

本開示は、一般に、ストリーム・コンピューティングに関し、詳細には、ストリーミング・データを受信し、ストリーミング・データの受信時にデータを処理するコンピューティング・アプリケーションに関する。

２０世紀の後半において、情報革命と呼ばれる現象が始まった。情報革命は、どの事象または機械よりも範囲において広い歴史的発展であるが、デジタル電子コンピュータよりも情報革命を象徴するデバイスはなかった。コンピュータ・システムの発展は、間違いなく革命であった。コンピュータ・システムは、毎年急速に成長し、より多くのデータを格納し、より多くのアプリケーションをユーザに提供している。

最新のコンピュータ・システムを使用して、さまざまなアプリケーションをサポートすることができるが、１つの共通の用途は、情報を取得できる大規模なリレーショナル・データベースの保守である。大規模なリレーショナル・データベースは、多くの場合、複数のユーザがネットワークを介してアクセスすることができ、それらのどのユーザも、データベースの情報を照会すること、またはデータベース内のデータを更新すること、あるいはその両方を行うことができる。

データベース・システムは、通常、データを格納するプロセスを、データベースに格納されたデータにアクセスすること、あるいはデータベースに格納されたデータを操作または使用することから分離するように、構成される。さらに具体的には、データベース・システムは、その後の照会および解析の前に、データがメモリ内で最初に格納されてインデックス付けされるモデルを使用する。一般に、データベース・システムは、ストリーミング・データのリアルタイムの処理および解析を実行するのにあまり適していないことがある。特に、データベース・システムは、大量のストリーミング・データを効率的に、またはリアルタイムに、格納すること、インデックス付けすること、および解析することができないことがある。

リアルタイムでの大量の受信データをより効果的に処理するために、ストリームベースの計算（データ・ストリーミングとも呼ばれる）が使用されている。データ・ストリーミング・アプリケーションでは、データは、「グラフ」と呼ばれる「処理要素」の接続されたネットワークを経由して移動し、各処理要素は、１つまたは複数の何らかの機能をデータに対して実行する。

ストリームベースの計算は、すべてのデータが、オペレータ・グラフを通って移動しながら存続しているというパラダイムに対して有効である。グラフ内の各処理要素は、このパラダイムに従って、その機能をすぐに実行するために必要なデータをすべて含んでおり、グラフを通るデータ・フローを高速に維持できるほど十分迅速に、その機能を実行することができる。しかし、処理要素は、外部のデータ（すなわち、ストレージ内またはリモート・データベース内のデータ）にアクセスすることが必要な場合がある（検索動作と呼ばれることがある事象）。この事象が発生した場合、処理要素は、必要なデータが取得されている間、待機しなければならない。このような待機は、ストリーミング・アプリケーションの性能を大幅に低下させる可能性がある。多くの場合、この待機は、オペレータ・グラフを通る連鎖反応をもたらし、他の処理要素が、データを不必要に待機すること、またはストリーム・アプリケーションのさまざまなバッファにデータがバックアップされるのを不必要に待機すること、あるいはその両方を引き起こす。

大量のデータ・フローを管理するための改良された技術、特に、データ検索動作を管理する改良されたデータ・ストリーミング技術に対する必要性が存在する。データ・ストリーミング・アプリケーションにおけるフロー遅延の低減を行うことを課題とする。

データ・ストリーミング・アプリケーションの現在の実行インスタンスまたは１つまたは複数の以前の実行インスタンスあるいはその両方の実行中に、１つまたは複数の前の時間間隔から収集されたプロファイリング・データが、データ・ストリーミング・アプリケーションの現在の実行インスタンスにおいて処理要素によって取得されることが必要になるデータを予測するために使用される。この予測に応答して、データを必要とする処理要素による実際の要求に先立って、データが取得される。

１つまたは複数の実施形態では、予測は、上流のタプルの内容に少なくとも部分的に基づく。すなわち、データ・ストリーミング・グラフの対象の処理要素の上流で発生したあるタプル内の特定の値のセットが、例えばそのタプルが対象の処理要素に到達したときに、対象の処理要素による特定のデータに対するその後の必要性を予測するために使用されてよい。１つまたは複数の実施形態では、予測は、データ・ストリーミング・アプリケーションの過去データの取得パターンに少なくとも部分的に基づく。そのような過去のパターンは、（ａ）通常はデータ要素が取得される時刻／週、（ｂ）特定の事象の発生後の時間、（ｃ）特定の条件の存在、または（ｄ）他のデータの取得との相関関係のいずれか、あるいはすべてを含むことができる。１つまたは複数の実施形態では、必要なデータの予測は、データが必要になる予測時刻を含んでもよく、データがちょうどよいときに取得されるように、必要になると予測されたデータの取得が遅延されてよい。

必要なデータの予測は、完全である必要はない。必要であると予測されたデータが、実際は不要だった場合、データ・ストリーミング・アプリケーションは正常に実行を継続し、その場合の損失は、未使用のデータを取得するというわずかなオーバーヘッドのみである。データが実際に必要だが、予測されていない場合、そのデータは、従来技術と同様に、処理要素の要求に応じて取得される。データ・ストリーミング・アプリケーションにおいて、１つまたは複数の処理要素によって必要とされる少なくとも一部のデータを予測し、処理要素によるデータの要求に先立って、そのデータを処理要素に取得することによって、処理要素によるアイドリングまたはデータの待機が削減され、データ・ストリーミング・アプリケーションの実行の効率が改善される。

本発明の実施形態は、その構造および動作の両方に関して添付の図面を参照して最も良く理解することができ、添付の図面において、類似する参照番号は類似する部分を参照している。

さまざまな実施形態に従う、ストリーム・コンピューティング・アプリケーションを実行するように構成されたコンピューティング・インフラストラクチャを示す図である。 さまざまな実施形態に従う、複数の機能要素のいずれかの役割を実行するために使用できる、代表的な汎用コンピュータ・システムの主要ハードウェア・コンポーネントの上位のブロック図である。 さまざまな実施形態に従う、図１の計算ノードのメモリ内の特定のソフトウェア・コンポーネントの概念図である。 さまざまな実施形態に従う、ストリーミング・データ・アプリケーション・バッファ（streaming data application buffer）内のタプルのセットの概念的表現である。 さまざまな実施形態に従う、図１の管理システムのメモリ内の特定のソフトウェア・コンポーネントの概念図である。 さまざまな実施形態に従う、図１のコンパイラ・システムのメモリ内の特定のソフトウェア・コンポーネントの概念図である。 さまざまな実施形態に従う、ストリーム・コンピューティング・アプリケーションのオペレータ・グラフを示す図である。 さまざまな実施形態に従う、データベース・サーバ・コンピュータ・システムのメモリ内の主要ソフトウェア・コンポーネントの概念図である。 さまざまな実施形態に従う、プロファイル解析をサポートするために変更されたデータ・ストリーミング・アプリケーションの変更されたタプルの概念的表現である。 さまざまな実施形態に従う、データ・ストリーミング・アプリケーションのプロファイル・データを収集するプロセスを上位で示すフロー図である。 さまざまな実施形態に従う、例示的な検索事象サマリー・レコード（lookup event summary records）のセットの構造の概念図である。 さまざまな実施形態に従う、検索事象サマリー・レコードのセットを生成するためのプロファイル・データを解析するプロセスを上位で示すフロー図である。 さまざまな実施形態に従う、実行中の検索動作を制御する状態データ構造を生成または更新するプロセスを上位で示すフロー図である。 さまざまな実施形態に従う、データ・ストリーミング・アプリケーションの例示的な処理要素の実行プロセスを示すフロー図である。

ストリーム処理の概要
ストリームベースの計算およびストリームベースのデータベース計算が、データベース・システム用の発達中の技術として現れている。ストリーミング・データがデータベース・ファイルに到達する前に、そのストリーミング・データを処理および照会するアプリケーションをユーザが作成できるようにする製品が、利用可能である。ユーザは、この新たに出現した技術を使用して、インバウンド・データ・レコードが、結果を使用できる時間が極めて短い（多くの場合、１秒未満である）「イン・フライト」であるときに、インバウンド・データ・レコードに適用される処理論理を指定することができる。このタイプの処理を使用してアプリケーションを構築することによって、広範囲のさまざまな革新的アプリケーション、システム、およびプロセスの開発を可能にすると共に、アプリケーション・プログラマーおよびデータベース開発者にとっての新しい課題を提示する、新しいプログラミング・パラダイムが切り開かれた。

ストリーム・コンピューティング・アプリケーションでは、データが１つのストリーム・オペレータ（stream operator）から次のストリーム・オペレータへ（例えば、ＴＣＰ／ＩＰソケットを経由して）流れるように、ストリーム・オペレータが互いに接続される。ストリーム・オペレータは、データを受信したときに、属性を追加するか、または差し引くことによって、あるいはタプル内の既存の属性の値を更新することによって、タプルを変更することができる、解析論理などの動作を実行してよい。解析論理が完了した後に、新しいタプルが次のストリーム・オペレータに送信される。実行ファイル（すなわち、処理要素）を作成し、処理要素を複数のノード上で複製し、ノード間で負荷バランスを調整することによって、ノード間でアプリケーションを分散して、拡張性が実現される。ストリーム・コンピューティング・アプリケーション内のストリーム・オペレータは、一緒に融合されて、実行ファイルである処理要素を形成することができる。これを行うことによって、処理要素は、共通のプロセス空間を共有できるようになり、ストリーム・オペレータ間の通信速度が、プロセス間通信技術を使用して（例えば、ＴＣＰ／ＩＰソケットを使用して）利用可能な通信速度よりも非常に速くなる。さらに、ストリーム・コンピューティング・アプリケーションを介して、処理要素を、データのフローを表すオペレータ・グラフに動的に挿入するか、またはそのオペレータ・グラフから動的に削除することができる。特定のストリーム・オペレータは、他のストリーム・オペレータと同じオペレーティング・システム・プロセス内に存在しても、存在しなくてもよい。加えて、同じオペレータ・グラフ内のストリーム・オペレータは、異なるノード上（例えば、異なる計算ノード上または計算ノードの異なるコア上）でホストされてよい。

データは、「タプル」の形態で、あるストリーム・オペレータから別のストリーム・オペレータに流れる。タプルは、実体に関連付けられた１つまたは複数の属性のシーケンスである。属性は、さまざまなタイプ（例えば、整数、浮動小数、ブール、文字列など）のいずれかであってよい。属性は、順序付けられてよい。タプルは、実体に関連付けられた属性に加えて、メタデータ（すなわち、タプルに関するデータ）を含んでよい。タプルは、１つまたは複数の追加の属性またはメタデータをタプルに追加することによって、拡張されてよい。本明細書において使用されるとき、「ストリーム」または「データ・ストリーム」は、タプルのシーケンスを指す。通常、ストリームは、タプルの擬似無限のシーケンスであると考えられてよい。

タプルは、ストリーム・オペレータおよび処理要素によって受信され、出力されてよい。ただし、あるストリーム・オペレータまたは処理要素によって受信される特定の実体と一致する入力タプルは、出力タプルが入力タプルと同じ実体またはデータと一致する場合でも、通常、このストリーム・オペレータまたは処理要素によって出力されるタプルと同じタプルであるとは考えられない。出力タプルは、何らかの方法で入力タプルから変更される必要はない。

それでも、出力タプルは、ストリーム・オペレータまたは処理要素によって何らかの方法で変更されてよい。属性またはメタデータは、追加、削除、または変更されてよい。例えばタプルは、多くの場合、２つ以上の属性を含む。ストリーム・オペレータまたは処理要素は、複数の属性を含んでいるタプルを受信し、入力タプルと一致するタプルを出力してよい。ストリーム・オペレータまたは処理要素は、１つの属性を除く出力タプルのすべての属性が入力タプルの属性と同じになるように、属性のうちの１つのみを変更してよい。

通常、ストリーム・オペレータまたは処理要素によって出力される特定のタプルは、入力タプルが処理要素によって変更されない場合でも、対応する入力タプルと同じタプルであると考えられなくてよい。ただし、本説明および特許請求の範囲を簡略化するために、対応する入力タプルと同じデータ属性を含んでいるか、または対応する入力タプルと同じ実体に関連付けられている出力タプルは、特に文脈で示されるか、または明示的に示されない限り、本明細書では同じタプルであると見なされる。

ストリーム・コンピューティング・アプリケーションは、効率的にリアルタイムに処理される必要のある大量のデータを処理する。例えば、ストリーム・コンピューティング・アプリケーションは、１秒当たり数十万のメッセージ、および１日当たり最大数ペタバイトのデータを、継続的に取り込んで解析することができる。したがって、ストリーム・コンピューティング・アプリケーション内の各ストリーム・オペレータは、受信されたタプルを１秒未満で処理する必要があることがある。複数のストリーム・オペレータが同じ処理要素に配置されない限り、タプルがあるストリーム・オペレータから別のストリーム・オペレータへ送信されるたびに、プロセス間通信経路を使用する必要がある。プロセス間通信経路は、ストリーム・コンピューティング・アプリケーションにおいて極めて重要なリソースになり得る。さまざまな実施形態によれば、１つまたは複数のプロセス間通信経路で利用可能な帯域幅を節約することができる。プロセス間通信の帯域幅を効率的に使用することによって、処理を高速化できる。

図１は、一部の実施形態に従って、ストリーム・コンピューティング・アプリケーションを実行するように構成することができる１つの例示的なコンピューティング・インフラストラクチャ１００を示している。コンピューティング・インフラストラクチャ１００は、管理システム１０５および２つ以上の計算ノード１１０Ａ〜１１０Ｄ（本明細書では、総称して特徴１１０と呼ばれる）（すなわち、ホスト）を含んでおり、これらは、１つまたは複数の通信ネットワーク１２０を使用して、通信によって互いに結合される。通信ネットワーク１２０は、１つまたは複数のサーバ、ネットワーク、またはデータベースを含んでよく、特定の通信プロトコルを使用して計算ノード１１０間でデータを転送してよい。コンパイラ・システム１０２は、管理システム１０５および計算ノード１１０に、直接的または通信ネットワーク１２０を介して、通信によって結合されてよい。さらに、データベース１４０を含んでいるデータベース・システム１１５は、管理システム１０５または計算ノード１１０あるいはその両方との通信のために、ネットワーク１２０に通信によって結合されてよい。

通信ネットワーク１２０は、さまざまなタイプの物理通信チャネルまたは「リンク」を含んでよい。それらのリンクは、有線、無線、光学的、または任意のその他の適切な媒体であってよい。加えて、通信ネットワーク１２０は、ルータ、スイッチ、またはブリッジなどの、ルーティング、スイッチング、およびその他の機能を実行するためのさまざまなネットワーク・ハードウェアおよびネットワーク・ソフトウェアを含んでよい。通信ネットワーク１２０は、ストリーム・コンピューティング・アプリケーション専用であるか、または他のアプリケーションおよびユーザと共有されてよい。通信ネットワーク１２０は、任意の大きさであってよい。例えば、通信ネットワーク１２０は、単一のローカル・エリア・ネットワーク、またはインターネットなどの大きい地理的領域に広がる広域ネットワークを含んでよい。それらのリンクは、特定の速度でデータを転送するために、異なるレベルの帯域幅および容量を提供してよい。特定のリンクが提供する帯域幅は、通信媒体のタイプ、および特定のネットワーク・ハードウェアまたはネットワーク・ソフトウェアが正常に、または最大の能力で機能しているかどうかを含む、さまざまな要因に応じて、変化することがある。加えて、特定のリンクがストリーム・コンピューティング・アプリケーションに提供する帯域幅は、そのリンクが他のアプリケーションおよびユーザと共有されている場合、変化することがある。利用可能な帯域幅は、他のアプリケーションおよびユーザによってリンクに与えられる負荷に応じて変化することがある。特定のリンクが提供する帯域幅は、時刻、曜日、月の特定の日、または季節などの、時間的な要因に応じて変化することもある。

コンピュータ・システムのハードウェア・コンポーネント
図２は、代表的な汎用コンピュータ・システム２００の主要ハードウェア・コンポーネントの上位のブロック図である。１つまたは複数の実施形態では、コンパイラ・システム１０２、管理システム１０５、計算ノード１１０、およびデータベース・システム１１５はそれぞれ、各１つまたは複数の汎用コンピュータ・システムとして物理的に具現化され、システム２００は、そのような汎用コンピュータ・システムを表している。

コンピュータ・システム２００は、メイン・メモリ２０２からの命令を実行し、データを処理する、１つまたは複数の汎用プログラマブル・プロセッサ（ＣＰＵ）２０１を含んでいる。メイン・メモリ２０２は、さまざまなメモリ技術のいずれかを使用する少なくとも１つ（通常は複数）の半導体集積回路チップ・モジュールを備えている揮発性ランダム・アクセス・メモリであるのが好ましく、メイン・メモリ２０２内のデータは、ＣＰＵ２０１によって処理するために、ストレージから、またはその他の方法で読み込まれる。

１つまたは複数の通信バス２０５が、ＣＰＵ２０１、メイン・メモリ２０２、およびさまざまなインターフェイス・ユニット２１１、２１２、２１３（Ｉ／Ｏプロセッサ（ＩＯＰ：I/O processors）またはＩ／Ｏアダプタ（ＩＯＡ：I/O adapters）と呼ばれることもある）の間でデータを転送するためのデータ通信経路を提供する。インターフェイス・ユニットは、さまざまなストレージ、Ｉ／Ｏデバイス、またはネットワーク、あるいはその組み合わせとの通信をサポートする。例えば、ストレージ・インターフェイス・ユニット２１１は、必要に応じてメモリに読み込むことができるデータの不揮発性ストレージを提供する１つまたは複数のストレージ・デバイス２２１〜２２３の取り付けをサポートする。そのようなストレージ・デバイスは、周知の回転磁気ハード・ディスク・ドライブ・ストレージ・デバイス、半導体デバイス（ＳＳＤ：solid state devices）、取り外し可能なメモリ・カード、光ストレージ、フラッシュ・メモリなどを含んでよく、ネットワーク接続ストレージ（ＮＡＳ：network attached storage）、ストレージ・エリア・ネットワーク（ＳＡＮ：storage area network）を介して取り付けられたデバイス、またはディスク・ドライブのアレイ、またはホストには単一の大規模なストレージ・デバイスのように見えるように構成されたその他のストレージ・デバイス、あるいはその組み合わせをさらに含むことができる。ストレージは、１つまたは複数のネットワークを介してアクセスできるクラウド・ストレージ・デバイスをさらに含んでよい。Ｉ／Ｏデバイス・インターフェイス・ユニット２１２は、ユーザ端末、ディスプレイ、キーボードまたはその他の入力デバイス、プリンタなどのさまざまなその他のタイプのＩ／Ｏデバイスのいずれかの取り付けをサポートしてよく、その他のタイプまたは追加のタイプのＩ／Ｏデバイスが使用され得るということが理解されている。ネットワーク・インターフェイス・アダプタ２１３は、１つまたは複数の他のデジタル・デバイスと通信するために、１つまたは複数の外部ネットワークへの接続をサポートしてよく、具体的には、図１において表されたデバイスと通信するために、ネットワーク１２０への接続をサポートしてよい。ネットワーク・アダプタ２１３は、単一のネットワークへの冗長な接続をサポートすることができ、または互いに通信してもしなくてもよい別々のネットワークに結合され得る。そのような外部ネットワークは、インターネットを含むのが好ましく、ローカル・エリア・ネットワークなどの１つまたは複数の中間ネットワークを含んでよく、この中間ネットワークを介してインターネットとの通信が実現される。

図２が、汎用コンピュータ・システム２００の代表的な上位の主要コンポーネントを表すよう意図されているということ、個々のコンポーネントが、図２において表されたものよりも複雑であってよいということ、図２に示されたコンポーネント以外のコンポーネント、または追加のコンポーネントが存在してよいということ、そのようなコンポーネントの数、タイプ、および構成が変化してよいということ、および複雑なコンピュータ・システムが、図２において表されたコンポーネントより多くのコンポーネントを通常は含んでいるということが、理解されるべきである。そのような追加の複雑さまたは追加の変形の複数の特定の例が本明細書において開示されており、それらが単なる例であり、そのような変形に必ずしも限定されないということが理解されている。

図２では、例示の目的で１つのＣＰＵ２０１のみが示されているが、コンピュータ・システム２００は、従来技術において知られているように、複数のＣＰＵを含んでよい。図２では、メイン・メモリ２０２が単一のモノリシックな実体として示されているが、実際には、メモリ２０２は、従来技術において知られているように、分散されること、または階層的であること、あるいはその両方であることができる。例えば、メモリは、キャッシュの複数のレベルに存在してよく、それらのキャッシュは、あるキャッシュが命令を保持している間に、別のキャッシュが、１つまたは複数のプロセッサによって使用される、命令以外のデータを保持するように、機能別にさらに分割されてよい。メモリは、さまざまな、いわゆる不均等メモリ・アクセス（ＮＵＭＡ：non-uniform memory access）コンピュータ・アーキテクチャのいずれかにおいて知られているように、異なるＣＰＵまたはＣＰＵのセットにさらに分散され、関連付けられてよい。図２では、通信バス２０５が単一の実体として示されているが、実際には、さまざまなシステム・コンポーネント間の通信は、通常、バス、インターフェイスなどの複雑な階層によって実現され、この階層内では、高速な経路がＣＰＵ２０１とメモリ２０２の間の通信に使用され、低速な経路がＩ／Ｏインターフェイス・ユニット２１１〜２１３との通信に使用される。バス２０５は、階層的構成、星形構成、またはＷｅｂ構成におけるポイントツーポイント・リンク、複数の階層的バス、並列で冗長な経路などの、さまざまな形態のいずれかで配置されてよい。例えば、ＮＵＭＡアーキテクチャにおいて知られているように、通信経路はノードを基準にして配置される。バスは、例えば、業界標準のＰＣＩバスまたは任意のその他の適切なバス技術を使用してよい。バス２０５を、さまざまなＩ／Ｏデバイスに達するさまざまな通信経路から分離する複数のＩ／Ｏインターフェイス・ユニットが示されているが、Ｉ／Ｏデバイスの一部または全部を１つまたは複数のシステム・バスに直接接続することが、代替的に可能である。図１は、ネットワーク１２０を単一の実体として表しているが、１つまたは複数の実施形態では、１つまたは複数の共有ストレージ・サーバと通信するために、別のネットワークまたはストレージ・バスが存在してよく、そのような通信は、汎用ネットワーク・アダプタ２１３から分離した専用の１つまたは複数のストレージ・インターフェイス・ユニット２１１によって駆動されてよい。

図２に示されているコンピュータ・システム２００は、複数ユーザの「メインフレーム」コンピュータ・システムなどにおいてよくあるように、複数の取り付けられた端末を含んでよい。コンピュータ・システム２００が、リモート・クライアントの代わりに作業を実行するために、計算ノード１１０またはその他のサーバとして排他的に使用される場合、コンピュータ・システム２００は、例えばシステム管理者などによる保守用のインターフェイスとして使用するために、限られた数の端末のみ、または１つの端末のみを含んでよく、場合によっては、全く端末を含まず、管理機能がリモートから実行されてよい。さらに、本明細書では、例示の目的で、特定の機能が単一のコンピュータ・システムにおいて具現化されるとして説明されているが、それらの機能の一部または全部を、互いに通信するコンピュータ・システムの分散ネットワークを使用して代替的に実装することができ、この分散ネットワーク内で、本明細書に記載された異なる機能またはステップが、異なるコンピュータ・システム上で実行される。

図１〜２では、計算ノード１１０、管理システム１０５、コンパイラ・システム１０２、およびデータベース・システム１１５が独立したシステムとして表されているが、これらの実体のいずれかまたは全部が、１つまたは複数の論理的に分割されたコンピュータ・システムの対応する論理パーティションとして実装されてよい。例えば、ＣＰＵ２１０のいずれかは、実際には、対応する論理パーティションに割り当てられた、より大きい論理的に分割されたコンピュータ・システムの処理リソース能力の対応する一部であってよく、メモリ２０２は、実際には、対応する論理パーティションに割り当てられた、より大きい論理的に分割されたコンピュータ・システムのメモリ容量の対応する一部であってよい。

さまざまなシステム・コンポーネントが上位で示され、説明されたが、標準的なコンピュータ・システムが、本発明を理解することにおいて本質的ではない、示されていない多くのその他のコンポーネントを含んでいるということが、理解されるべきである。

ストリーム・コンピューティング・コンポーネント
図３は、さまざまな実施形態に従って、計算ノード１１０のメモリ３００内の特定のソフトウェア・コンポーネントを詳細に示す概念図であり、計算ノード１１０は、図１の計算ノード１１０Ａ〜１１０Ｄのうちの１つと同じであってよい。図３に示されているように、代表的な計算ノードのメモリは、オペレーティング・システム・カーネル３０１、１つまたは複数の処理要素３１１、およびバッファ３１３を含んでいる。

オペレーティング・システム・カーネル３０１は、従来技術においてよく知られているように、デバイス・インターフェイス、メモリ・ページの管理、複数のタスクの管理およびディスパッチ、アプリケーション・プログラム用の共通サービスなどの、さまざまな低レベルのソフトウェア機能を提供する実行コードおよび状態データである。特に、ＯＳカーネル３０１は、ネットワーク・インターフェイス２１３を介したネットワーク１２０を含む１つまたは複数のネットワークとの通信を処理するために、１つまたは複数のネットワーク・アダプタ・ドライバ３０２を含むのが好ましい。

１つまたは複数の処理要素３１１はそれぞれ、各機能をデータ・ストリーム・コンピューティング・アプリケーションの一部として実行するためのコードおよび状態データを含む。ストリーム・コンピューティング・アプリケーションは、「処理要素」コンテナ３１１内にコンパイルされてよい１つまたは複数のストリーム・オペレータ３１２を含んでよい。メモリ３００は、２つ以上の処理要素３１１を含んでよく、各処理要素は、１つまたは複数のストリーム・オペレータ３１２を含んでいる。各ストリーム・オペレータ３１２は、ストリーム・コンピューティング・アプリケーションにおいて、処理要素に流れ込むタプルを処理し、同じ処理要素、他の処理要素、または同じ処理要素と他の処理要素の両方に含まれる他のストリーム・オペレータ３１２にタプルを出力する、コードの一部を含んでよい。処理要素３１１は、同じ計算ノード１１０上にあるか、または通信ネットワーク１２０を介してアクセスできる他の計算ノード上にある、他の処理要素にタプルを渡してよい。例えば、計算ノード１１０Ａ上の処理要素３１１は、計算ノード１１０Ｂ上の処理要素３１１にタプルを出力してよい。一実施形態では、処理要素３１１が、１つのＣＰＵのみによって実行されるように割り当てられるが、他の実施形態では、処理要素３１１のストリーム・オペレータ３１２が、異なる各ＣＰＵ上で実行できる複数のスレッドを含んでよい。

バッファ３１３は、ストリーム・コンピューティング・アプリケーションの一部としてストリーミングされているデータを保持するため、特にデータ・タプルを保持するための、メモリ３００の一部である。バッファ３１３は、単一の実体であってよいが、１つまたは複数の実施形態では、ウィンドウとも呼ばれるローカル・バッファ３１４、データ・ストリーミング・アプリケーションのさまざまな実体間でメッセージを渡すための１つまたは複数のＴＣＰＩＰバッファ３１５、および各１つまたは複数のスレッドによって処理されるデータをキューに入れるための１つまたは複数のスレッド・ポート３１６を含む、複数のバッファが存在する。

図４は、さまざまな実施形態に従う、ストリーミング・データ・アプリケーション・バッファ３１３内のタプルのセットの概念的表現である。バッファ３１４〜３１６のいずれかが、１つまたは複数のタプルを保持してよい。図４に示されているように、タプルのセットは１つまたは複数のタプル４０１を含み、各タプルは、複数のフィールドまたは属性４０２〜４０４として論理的に編成される。タプルのセットは、テーブルとして概念的に表されてよく、このテーブル内で、各タプル４０１はテーブルの各行に対応し、タプルの各属性またはフィールドはテーブルの各列に対応する。テーブルとして概念的に表されているが、メモリ内のタプルのセットの実際の構造は変化してよく、異なるバッファ３１４〜３１６のそれぞれにおいて異なってよく、このセットは不連続なメモリ・アドレス領域を占めてよく、タプルのサイズは変化してよく、一部の属性はタプルのサブセット内にのみ存在してよい、などとなる。さまざまな実施形態では、データ・ストリーミング・アプリケーションは、データベースのテーブルに追加されるタプルを生成するが、データ・ストリーミング・アプリケーション内のタプル４０１の構造および属性は、リレーショナル・データベースのテーブル内のタプルの構造および属性と必ずしも同一ではない。バッファ３１３に格納されるタプル４０１は、すべて単一のタイプ（すなわち、すべてが同じ属性および構造を有する）であってよく、または異なるタイプのタプルであってよい。１つまたは複数の実施形態では、タプルは、オペレータ・グラフ内のタプルの現在の状態に応じて、別々のセット内または異なるバッファ内で、別々にグループ化されてよい。例えば、あるタプルのセットは、計算ノード内の特定の処理要素３１１による処理を待っているタプル４０１を含んでよく、一方、別のセットは、特定の処理要素によってすでに処理されているタプル４０１を含んでいる。

１つまたは複数の実施形態では、計算ノードのメモリ３００は、データ・ストリーミング・アプリケーションの動作をトレースする（具体的には、オペレータ・グラフを通るタプルの進行をトレースする）トレース・データ３１８をさらに含んでよい。このトレース・データは、オペレータ・グラフ内の下流のデータ検索動作を予測することに使用するためのオペレータ・グラフ・プロファイル・データ（operator graph profile data）の構築に使用されてよい。

１つまたは複数の実施形態では、処理要素３１１内の状態データは、検索マスク３２１および１つまたは複数のトリガー・パラメータ・データセット３２２をさらに含む。検索マスク３２１は、先行する検索予測事象（lookup predictive event）を検出することに応答して先行検索動作（anticipatory lookup operation）をトリガーすることがある、１つまたは複数の処理要素、オペレータ、またはその他のコード部分ごとに、先行検索が有効化されているかどうかを示す、ビット・マスクまたは同様の構造である。トリガー・パラメータ・データセット３２２は、各処理要素、オペレータ、またはその他の場所にそれぞれ対応する、１つまたは複数のデータセットを含んでおり、検索事象のトリガーおよびその結果生じる検索事象自体を制御するパラメータを含んでいる。本明細書では、データ・ストリーミング・アプリケーションの実行中の検索マスク３２１およびトリガー・パラメータ・データセット３２２の使用が詳細に説明される。

図５は、さまざまな実施形態に従って図１の管理システム１０５のメモリ５００内の特定のソフトウェア・コンポーネントを詳細に示す概念図である。図５に示されているように、代表的な管理システムのメモリは、オペレーティング・システム・カーネル５０１、ストリーム・マネージャ１３４、オペレータ・グラフ１３２、プロファイル・データ・アナライザ５２３、およびオペレータ・グラフ・プロファイル・データ５２５を含んでいる。

オペレーティング・システム・カーネル５０１は、従来技術においてよく知られているように、デバイス・インターフェイス、メモリ・ページの管理、複数のタスクの管理およびディスパッチ、アプリケーション・プログラム用の共通サービスなどの、さまざまな低レベルのソフトウェア機能を提供する実行コードおよび状態データである。特に、ＯＳカーネル５０１は、ネットワーク・インターフェイス２１３を介したネットワーク１２０を含む１つまたは複数のネットワークとの通信を処理するために、１つまたは複数のネットワーク・アダプタ・ドライバ５０２を含むのが好ましい。

ストリーム・マネージャ１３４は、データ・ストリーミング・アプリケーションの動作を管理し、特に、オペレータ・グラフ１３２を維持する。オペレータ・グラフ１３２は、タプルを処理するために処理要素３１１にルーティングする方法を定義するデータ構造である。

１つまたは複数の実施形態では、ストリーム・マネージャ内の状態データは、検索マスク５２１および１つまたは複数のトリガー・パラメータ・データセット５２２をさらに含む。状態データは、計算ノード１１０のメモリ３００内の検索マスク３２１のローカル・コピーおよびトリガー・パラメータ・データセット３２２のローカル・コピーに類似しているが、ストリーム・マネージャは、データ・ストリーミング・アプリケーション全体に関する全体的な状態データを含み、一方、計算ノードのメモリ３００内のこのデータのローカル・コピーは、通常、その計算ノード内の処理要素に適用できる状態データのみを保持する。本明細書では、データ・ストリーミング・アプリケーションの実行中の検索マスク５２１およびトリガー・パラメータ・データセット５２２の使用が詳細に説明される。

プロファイル・データ・アナライザ５２３は、トレース・データをさまざまな計算ノードから収集し、そのデータを解析してオペレータ・グラフ・プロファイル・データ５２５を構築し、維持する、実行コードおよび状態データである。オペレータ・グラフ・プロファイル・データ５２５は、検索事象サマリー・レコード５２６およびトレース・データ５２７を含む。トレース・データ５２７は、さまざまな計算ノードからのトレース・データ３１８のすべてまたは選択的部分の集合であり、検索事象サマリー・レコード５２６を生成するためにプロファイル・データ・アナライザによって使用される。検索事象サマリー・レコードは、過去の検索事象のパターンを表す。例えば、検索事象サマリー・レコードは、さまざまな先行する検索予測事象ごとに、予測されたその後発生する各検索事象を要約することができ、必要に応じて、先行する各事象に関連付けられた１つまたは複数の確率、または先行する事象と検索事象の間の時間遅延の測定値、あるいはその両方を含むことができる。先行する事象は、特定の属性値を含み、特定の処理要素で発生する、特定のタイプの各タプルであってよい。例示的な検索事象サマリー・データ（lookup event summary data）５２６が図１１に示されており、本明細書において詳細に説明される。

図６は、さまざまな実施形態に従って図１のコンパイラ・システム１０２のメモリ６００内の特定のソフトウェア・コンポーネントを詳細に示す概念図である。図６に示されているように、代表的なコンパイラ・システムのメモリは、オペレーティング・システム・カーネル６０１、コンパイラ１３６、ならびにソース・モジュール６１１、中間コード・モジュール６１２、およびオブジェクト・コード・モジュール６１３の形態でのコンパイラの入力および出力を含んでいる。

オペレーティング・システム・カーネル６０１は、従来技術においてよく知られているように、デバイス・インターフェイス、メモリ・ページの管理、複数のタスクの管理およびディスパッチ、アプリケーション・プログラム用の共通サービスなどの、さまざまな低レベルのソフトウェア機能を提供する実行コードおよび状態データである。特に、ＯＳカーネル６０１は、ネットワーク・インターフェイス２１３を介したネットワーク１２０を含む１つまたは複数のネットワークとの通信を処理するために、１つまたは複数のネットワーク・アダプタ・ドライバ６０２を含むのが好ましい。

コンパイラ１３６は、ソース・コードまたはステートメント６１１を含んでいるモジュールを、プロセッサ上で実行される機械命令を含んでいるオブジェクト・コード６１３にコンパイルする、実行コードおよびデータ構造である。一実施形態では、コンパイラ１３６は、モジュールを中間形態６１２に変換してから、この中間形態をオブジェクト・コードに変換してよい。コンパイラ１３６は、処理要素のセット、およびストリーム・コンピューティング・アプリケーションを記述する構成ファイルであるアプリケーション記述言語ファイル（ＡＤＬファイル：application description language file）を含むことができる、配置可能な中間生成物のセットを出力してよい。一部の実施形態では、コンパイラ１３６は、インタープリタの一部として実行されるジャストインタイム・コンパイラであってよい。他の実施形態では、コンパイラ１３６は、最適化コンパイラであってよい。さまざまな実施形態では、コンパイラ１３６は、ピープホール最適化、局所的最適化、ループ最適化、手続き間またはプログラム全体の最適化、機械語の最適化、あるいはオブジェクト・コードを実行するために必要な時間を減らすか、もしくはオブジェクト・コードを実行するために必要なメモリ量を減らすか、またはその両方を減らす、任意のその他の最適化を実行してよい。コンパイラ１３６の出力は、オペレータ・グラフ（例えば、オペレータ・グラフ１３２）によって表されてよい。

コンパイラ１３６は、アプリケーション管理者に、プロファイル駆動型融合最適化（profile-driven fusion optimization）によって性能を最適化する能力を提供してもよい。オペレータを融合することによって、トランスポートの呼び出し回数を減らして、性能を向上することができる。ストリーム・オペレータを融合することによって、プロセス間通信技術を使用して利用できるよりも高速なオペレータ間の通信を実現できるが、オペレータを融合することを決定する場合、複数の計算ノード間で処理を分散することの効果と、より高速なオペレータ間通信の効果との間のバランスを調整する必要がある。コンパイラ１３６は、ユーザによって指定された制約を順守しながら、１つまたは複数の処理要素によってホストされるオペレータを最適に融合する方法を決定するように、融合プロセスを自動化してよい。このプロセスは、プロファイリング・モードでアプリケーションをコンパイルし、アプリケーションを実行すること、次に再コンパイルし、このその後のコンパイル中にオプティマイザを使用することを含む、二段階のプロセスであってよい。しかし、最終的な結果は、アプリケーション構成が最適化された、コンパイラによって提供される配置可能なアプリケーションである。

コンパイラ・システムのメモリ６００は、共通実行時コード（common run-time code）６１４をさらに含む。共通実行時コードは、ソース・コード、中間コード、またはオブジェクト・コードのいずれかであることができる。共通実行時コード６１４は、すべてまたは多くの処理要素に共通する機能を実行するために、各処理要素３１１のコードに含まれている共通コードである。共通実行時コードは、例えば、さまざまな処理要素間でメッセージを渡すこと、バッファ３１３にアクセスすること、エラーまたはその他の状態を報告することなどのための機能を含んでよい。１つまたは複数の実施形態では、共通実行時コードは、データ・ストリーミング・アプリケーションの動作をトレースするトレース・データ３１８を収集するためのトレース命令６１５、および検索予測事象に応答して先行検索動作を開始するための先行検索命令６１６を含む。トレース命令６１５を実行することによって収集されたトレース・データ３１８は、オペレータ・グラフ・プロファイル・データ５２５を構築するために使用されてよい。トレース命令６１５または先行検索命令６１６あるいはその両方は、必要に応じて含まれる命令であってよく、すなわち、必要に応じてコンパイラ１３６が、コンパイル時にコンパイラに与えられる設定または指示に応じて処理要素のコードに含める命令であってよい。

図７は、一部の実施形態に従って、１つまたは複数のソース７０２から開始して１つまたは複数のシンク７０４、７０６で終了する、ストリーム・コンピューティング・アプリケーションの例示的なオペレータ・グラフ７００を示している。本明細書では、通常は、このソースからシンクまでのフローが実行経路と呼ばれてもよい。加えて、さまざまな文脈において、ある処理要素から別の処理要素までのフローが実行経路と呼ばれてよい。図７は、接続された処理要素ＰＥ１〜ＰＥ１０を示すように抽象化されているが、オペレータ・グラフ７００は、同じまたは異なる処理要素内のストリーム・オペレータ３１２（図３）間のデータ・フローを含んでよい。通常、処理要素３１１（図３）などの処理要素は、タプルをストリームから受信し、タプルをストリームに出力する（ただし、ストリームが終了するシンク、またはストリームが開始するソースを除く）。オペレータ・グラフ７００は比較的少ない数のコンポーネントを含んでいるが、オペレータ・グラフは、これよりはるかに複雑であってよく、静的または動的に一緒にリンクできる多くの個別のオペレータ・グラフを含んでよい。

図７に示されている例示的なオペレータ・グラフは、計算ノード１１０Ａ〜１１０Ｄ上で実行される１０個の処理要素（ＰＥ１〜ＰＥ１０のラベルが付けられている）を含んでいる。処理要素は、それ自身のプロセスＩＤ（ＰＩＤ：process ID）およびメモリ空間を持ち、独立して実行されるプロセスを形成するために、一緒に融合された１つまたは複数のストリーム・オペレータを含んでよい。２つ（または３つ以上）の処理要素が独立して実行されている場合、プロセス間通信は、「トランスポート」（例えば、ネットワーク・ソケット、ＴＣＰ／ＩＰソケット、または共有メモリ）を使用して発生してよい。プロセス間通信に使用されるプロセス間通信経路は、ストリーム・コンピューティング・アプリケーションにおいて極めて重要なリソースになり得る。しかし、ストリーム・オペレータが一緒に融合された場合、融合されたストリーム・オペレータは、各処理要素内のストリーム・オペレータ間でタプルを渡すための、さらに高速な通信技術を使用できる。

オペレータ・グラフ７００は、ソース７０２で開始し、シンク７０４、７０６で終了する。計算ノード１１０Ａは、処理要素ＰＥ１、ＰＥ２、およびＰＥ３を含んでいる。ソース７０２は処理要素ＰＥ１に流れ込み、次に処理要素ＰＥ１が、ＰＥ２およびＰＥ３によって受信されるタプルを出力する。例えば、ＰＥ１は、タプル内の受信されたデータ属性を分割し、新しいタプル内の一部のデータ属性をＰＥ２に渡してよく、一方、別の新しいタプル内の他のデータ属性をＰＥ３に渡してよい。第２の例として、ＰＥ１は、一部の受信されたタプルをＰＥ２に渡してよく、一方、他のタプルをＰＥ３に渡してよい。ＰＥ２に流れるタプルは、ＰＥ２に含まれているストリーム・オペレータによって処理され、その結果得られたタプルが、計算ノード１１０Ｂ上のＰＥ４に出力される。同様に、ＰＥ４によって出力されたタプルが、シンクＰＥ６ ７０４内のオペレータに流れ込む。同様に、ＰＥ３からＰＥ５に流れるタプルも、シンクＰＥ６ ７０４内のオペレータに到達する。したがって、この例示的なオペレータ・グラフの場合、ＰＥ６は、シンクであることに加えて、ＰＥ４およびＰＥ５から受信されたタプルを結合する結合動作を実行するように構成され得る。この例示的なオペレータ・グラフは、ＰＥ３から計算ノード１１０Ｃ上のＰＥ７に流れるタプルも示しており、ノード１１０Ｃ自体は、ＰＥ８に流れ、折り返してＰＥ７に戻るタプルを示している。ＰＥ８から出力されたタプルは、計算ノード１１０Ｄ上のＰＥ９に流れ、次にＰＥ９は、シンク処理要素（例えば、ＰＥ１０ ７０６）内のオペレータによって処理されるタプルを出力する。通常、シンク７０４、７０６が、データ・ストリーミング・アプリケーションの外部（例えば、データベース、ストレージ・ファイル、またはその他の出力先）にデータ（例えば、タプル）を出力するが、処理要素のいずれかがデータを外部に出力することも可能である。

処理要素３１１（図３）は、さまざまな形式でタプルを受信または出力するように構成されてよく、例えば、処理要素またはストリーム・オペレータは、ＸＭＬドキュメントとしてマークアップされたデータを交換できる。さらに、処理要素３１１内の各ストリーム・オペレータ３１２は、任意の形態のデータ処理機能を受信されたタプルに対して実行するように構成されてよく、例えば、それらのデータ処理機能は、データベースのテーブルに書き込むこと、またはデータの結合、分割、読み取りなどのその他のデータベース操作を実行すること、あるいはその他のデータ解析機能または動作を実行することを含む。

ストリーム・マネージャ１３４は、計算ノード（例えば、計算ノード１１０Ａ〜１１０Ｄ）上で実行されているストリーム・コンピューティング・アプリケーションを監視すること、およびオペレータ・グラフ（例えば、オペレータ・グラフ１３２）の配置を変更することを実行するように構成されてよい。ストリーム・マネージャ１３４は、例えば、コンピューティング・インフラストラクチャ１００内の計算ノード１１０Ａ〜１１０Ｄの処理負荷を管理するために、処理要素を、ある計算ノード１１０から別の計算ノード１１０に移動してよい。さらに、ストリーム・マネージャ１３４は、計算ノード１１０Ａ〜１１０Ｄ上で実行されている処理要素およびストリーム・オペレータ（または、処理要素に流れるタプル）を挿入する、削除する、融合する、融合解除する、またはその他の方法で変更することによって、ストリーム・コンピューティング・アプリケーションを制御してよい。

処理要素は、融合されたストリーム・オペレータの集合であるため、特定のストリーム・オペレータ間の１つまたは複数の実行経路と同様にオペレータ・グラフを正しく表し、同じ処理要素内の異なるストリーム・オペレータへの実行経路を含むことができる。図７は、明確にするために、処理要素間の実行経路を示している。

データベース・コンポーネント
１つまたは複数の実施形態に従って、シンク７０４、７０６のうちの１つからか、またはその他の処理要素からかに関わらず、オペレータ・グラフ７００によって出力されたタプルが、構造化リレーショナル・データベース１４０の１つまたは複数のテーブルに入力される。図８は、さまざまな実施形態に従う、構造化リレーショナル・データベース１４０にアクセスするための、図１のデータベース・サーバ・コンピュータ・システム１１５のメモリ８００内の主要ソフトウェア・コンポーネントの概念図である。図８に示されているように、データベース・サーバ・コンピュータ・システムのメモリは、オペレーティング・システム・カーネル８０１、ならびにデータベース・マネージャ８１１、１つまたは複数のデータベース・テーブル８２１〜８２３、および１つまたは複数のメタデータ構造８２４〜８３２を含んでいる構造化データベース１４０を含む。

オペレーティング・システム・カーネル８０１は、従来技術においてよく知られているように、デバイス・インターフェイス、メモリ・ページの管理、複数のタスクの管理およびディスパッチ、アプリケーション・プログラム用の共通サービスなどの、さまざまな低レベルのソフトウェア機能を提供する実行コードおよび状態データである。特に、ＯＳカーネル８０１は、ネットワーク・インターフェイス２１３を介したネットワーク１２０を含む１つまたは複数のネットワークとの通信を処理するために、１つまたは複数のネットワーク・アダプタ・ドライバ８０２を含むのが好ましい。

データベース・テーブルおよびメタデータ８２０は、１つまたは複数のテーブル８２１〜８２３を含む（図８では、それらのテーブルのうちの３つが例示の目的で示されており、テーブルの数が変化してよいということが理解されている）。データベース技術において知られているように、データベース・テーブルは、複数のレコード（エントリまたはタプルとも呼ばれる）をテーブルの形態で論理的に含んでいるデータ構造であり、各レコードは、少なくとも１つの（通常は複数の）フィールド（属性とも呼ばれる）を含んでいる。テーブルの「行」はレコードに対応し、「列」はフィールドに対応する。テーブル８２１〜８２３は、論理的にテーブルと同等のデータ構造であるが、データベース技術において知られている任意の適切な構造で配置されてよい。データベース・テーブル８２１〜８２３は、コンピュータ・システムのユーザにとって役立つほぼすべてのタイプのデータを含んでよい。

データベース・テーブルには、メタデータと呼ばれることもある１つまたは複数の補助データ構造８２４〜８３２が関連付けられている（図８では、それらの補助データ構造のうちの９つが表されており、それらの構造の数およびタイプが変化してよいということが理解されている）。補助データ構造は、データベースおよびデータベース内のデータの構造を特徴付け、データベース管理に関わるさまざまなタスクにおいて役立ち、特に、データベースに対して照会を実行することにおいて役立つ。補助データ構造の例としては、データベース・インデックス８２４〜８２７、ヒストグラム８２８〜８２９、およびマテリアライズ照会テーブル（ＭＱＴ：materialized query tables）８３０〜８３１が挙げられる。補助データ構造は、照会キャッシュ８３２をさらに含んでよく、照会キャッシュ８３２には、以前に実行された照会（照会自体、照会実行計画または照会実行戦略、実行からの実行時間統計値など）に関するデータが格納される。図８では、特定の数およびタイプの補助データベース構造が示されているが、それらの構造の数およびタイプが変化してよいということ、示されている構造の一部が存在しなくてよいということ、または示されていない追加の構造が存在してよいということ、あるいはその組み合わせが理解されるであろう。

データベース・マネージャ８１１は、データベース・サーバ・システム１１５のＣＰＵ２０１上で実行されて、データベース１４０の管理のための基本機能を提供する、実行可能なコンピュータ・プログラミング・コードを含む。データベース・マネージャ８１１は、理論上は、関連する情報を含んでいてもいなくてもよい任意の数のデータベース・テーブルをサポートできるが、図８では３つのテーブルのみが示されている。データベース・マネージャ８１１は、データベースを管理するための特定の機能を自動的に実行するか、または許可されたユーザがデータベースに対して基本的な管理上の操作を実行できるようにするか、あるいはその両方を実行する、管理保守機能８１２を含むのが好ましく、例えば管理保守機能８１２には、データベース・テーブル定義を定義および編集すること、データベース内のレコードを作成、編集、および削除すること、データベース内のレコードを表示すること、ならびにインデックスおよびマテリアライズ照会テーブル、ビューなどのデータベースの補助データ構造を定義することなどがある。管理機能は、データベース・トランザクションのロギング、データの回復などをさらに含んでよい。それらの機能のうちのいくつかは、システム管理者などのみが利用可能であってよく、他の機能はクライアントが利用可能である。

データベース・マネージャ８１１は、データベース・テーブル８２１〜８２３内のデータに対して照会を実行するための照会エンジン８１３、および実行中の照会において照会エンジン８１３で使用するように最適化された照会実行計画を生成するための照会オプティマイザ８１４をさらに含むのが好ましい。データベース・マネージャ８１１は、１つまたは複数のアプリケーション・プログラミング・インターフェイス（ＡＰＩ：application programming interfaces）を含んでいる外部インターフェイス８１５をさらに含むのが好ましく、外部インターフェイス８１５によって、外部アプリケーションは、照会エンジン８１３を呼び出すか、またはその他の手段を使用して、データベース１４０内のデータにアクセスすることができる。データベース・マネージャ８１１は、従来技術において知られている、さまざまなさらに高度なデータベース機能のいずれかをさらに含んでよい。データベース・マネージャは、構造化照会言語（ＳＱＬ：structured query language）照会プロトコルを実装するデータベース管理システムなどの、一般的なデータベース管理システムであることができるが、何らかのその他のプロトコルに従って代替的にデータを照会および構造化してよく、またはカスタム設計されたデータベース管理システムであってよく、あるいはその両方であってよい。データベース・マネージャ８１１は、本明細書では、オペレーティング・システム・カーネル８０１から分離した実体として示され、説明されているが、一部のコンピュータ・アーキテクチャでは、さまざまなデータベース管理機能がオペレーティング・システムと統合されているということが理解されるであろう。

図８では、３つのデータベース・テーブル８２１〜８２３および９つの補助構造８２４〜８３２を含んでいる１つのデータベース１４０が示されているが、それらの実体の数は変化してよく、はるかに多くなることができる。コンピュータ・システムまたはコンピュータ・システムのグループは、複数のデータベースを含んでよく、各データベースは複数のテーブルを含んでよく、各データベースには、複数のインデックス、ＭＱＴ、ヒストグラム、ビュー、変動性記録（volatility records）、または示されていないその他の補助データ構造、あるいはその組み合わせが関連付けられてよい。代替として、図８で表されている一部の実体は、一部のデータベースには存在しないことがある。さらに、データベース１４０は、複数のコンピュータ・システムに格納されたより大きい分散型データベースに論理的に含まれてよい。図８では、データベース・マネージャ８１１はデータベース１４０の一部として表されているが、実行コードであるデータベース・マネージャは、「データベース」（すなわち、データ８２０）から分離した実体であると見なされることがある。

データベース・システム８００のメモリは、オペレーティング・システム８０１およびデータベース１４０に加えて、１つまたは複数のユーザ・アプリケーション８０４〜８０５のすべてまたは選択的部分を含んでよい。ユーザ・アプリケーション８０４〜８０５は、ＣＰＵ２０１上で実行されるアプリケーションであり、データベース１４０内のデータにアクセスして、１人または複数のユーザの代わりにタスクを実行してよい。そのようなユーザ・アプリケーションは、例えば売買取引、在庫管理、人事記録、会計処理、コードの開発およびコンパイル、メール、カレンダー、または多数のユーザ・アプリケーションのいずれかを含んでよく、Ｗｅｂベースである（すなわち、クライアントのブラウザに描画するために、Ｗｅｂページをリモート・クライアントに提示する）か、またはユーザ・インターフェイスのその他の形態を提供してよい。それらのアプリケーションの一部は、読み取り専用の方法でデータベースのデータにアクセスすることができ、その他のアプリケーションは、データを更新する能力を有する。さまざまなタイプの読み取りまたは書き込みデータベース・アクセス・タスクが存在することがあり、それらの各タスクは、異なるデータにアクセスするか、またはデータに対する異なる操作を要求する。例えば、あるタスクは、特定の既知のレコードからのデータにアクセスし、必要に応じてデータを更新することがあるが、別のタスクは、照会を呼び出すことがあり、その照会において、データベース内のすべてのレコードが何らかの指定された検索基準と照合され、一致したレコードからのデータが返され、必要に応じて更新される。さらに、データの読み取りまたは書き込みが、データベース・テーブル８１１〜８１３に対して直接行われることがあり、またはデータの操作が必要になることがあり、あるいはユーザによって提供されたか、別のデータベースまたはその他のソースから取得された、他のデータとのデータの結合が必要になることがある。通常、アプリケーション８０４〜８０５は、外部ＡＰＩ８１５を介してデータベース・マネージャ８１１への関数呼び出しを使用してデータベース内のデータにアクセスし、特に、データベース内のデータに対する照会を実行するが、一部のシステムでは、アプリケーションからデータベース内のデータに、独立して直接アクセスすることが可能であってよい。図８では、例示の目的で２つのアプリケーション８０４〜８０５が示されているが、それらのアプリケーションの数は変化してよい。

図３〜８では、さまざまなソフトウェアの実体が、本明細書に記載されたさまざまなシステムまたはデバイスのいずれかの各メモリに含まれているとして概念的に表されている。しかし、よく知られているように、コンピュータまたはその他のデジタル・デバイスのメモリは、一般的に、すべてのソフトウェアの実体およびその他のデータを同時に保持するには不十分であり、通常はソフトウェアの実体またはその他のデータの選択的部分が、必要に応じてストレージからメモリに読み込まれる。さらに、図３〜８では、さまざまなソフトウェアの実体は、別々の実体であるか、または他の実体に含まれているとして表されている。しかし、この表現が単に例示を目的としていること、および特定のモジュールまたはデータ実体が別々の実体であるか、あるいは共通モジュールまたはモジュールのパッケージの一部であることができるということが、理解されるであろう。さらに、図３〜８では、特定の数およびタイプのソフトウェアの実体が概念的表現で示されているが、それらの実体の実際の数が変化してよいということ、特に、複雑なデータ・ストリーミングまたはデータベース環境あるいはその両方においては、それらの実体の数および複雑さが通常、はるかに大きくなるということが、理解されるであろう。さらに、表現の完全性のために、特定のソフトウェア・コンポーネントが、それぞれ単一のシステム内で示されているが、すべてのプログラム、機能、およびデータが単一のシステム内に存在するというのは必ずしも真実ではなく、それらは、同じコンピュータ・システム上の別の部分または異なるコンピュータ・システムに存在してよい。例えば、ＡＰＩを呼び出してデータベースにアクセスするユーザ・アプリケーション８０４〜８０５は、データベースの定義、メタデータ構造の追加または削除などの特定の保守機能から分離したシステム上にあってよい。最後に、図３〜８の概念的表現が、どの特定のメモリ編成モデル（memory organizational model）も意味するよう意図されていないということ、およびデータ・ストリーミング・アプリケーションまたはデータベースをホストするコンピュータ・システムが、単一アドレス空間の仮想メモリを採用するか、または重複する複数の仮想アドレス空間を採用してよいということが、理解されるであろう。

データ・ストリーミング・プロファイル・データ（Data Streaming Profile Data）の収集
１つまたは複数の実施形態に従って、データ・ストリーミング・アプリケーションの動作を特徴付けるプロファイル・データが収集される。次に、このプロファイル・データが、オペレータ・グラフ内の処理要素による外部データ取得（検索事象）のインスタンスを、以前に発生した事象／条件（先行する検索予測事象）と相関付けるために使用される。具体的には、１つまたは複数の実施形態に従って、これらの先行する事象は、外部データ取得を引き起こす処理要素の上流のタプル内の特定のデータを含む。先行する事象は、時刻／曜日などの、外部状態変数の特定の値を含んでもよい。その後、これらの先行する事象を使用して、その後、処理要素がデータを取得することが必要になるということを予測できる。すなわち、データ・ストリーミング・アプリケーションのその後の実行中に、特定の外部データに対するその後の必要性に関連付けられた先行する事象の発生が、その外部データを必要とする処理要素によるその外部データに対する実際の要求に先立って、その外部データの取得を引き起こす。

１つまたは複数の実施形態では、プロファイル・データは、データ・ストリーミング・アプリケーションの１つまたは複数の実行インスタンスの実行をトレースすることによって取得されるが、入力データおよび出力データまたはソース・コードの解析から取得されたデータなどの、プロファイル・データのその他の形態または追加の形態が使用されてよい。トレースは周知の技術であり、トレースでは、コンピュータ・プログラムの実行中の事前に定義されたトレース可能な事象の発生が、コンピュータに、トレース可能な事象が発生した時点でのコンピュータの状態を示す特定の状態データを保存させる。トレースは、通常、コンピュータ・プログラム・コードの開発中に、エラーをデバッグすること、頻繁に使用されるコード・パスを決定すること、性能ボトルネックを識別することなどのために使用される。

トレースは、トレースされるコードを「インストルメントする」ことによって、すなわち、コンピュータ・プログラムの実行中に発生した場合に望ましい状態データの保存を引き起こすトレース命令（「インストルメンテーション」）を、さまざまなコード位置に配置することによって、実現されてよい。トレース命令は、データの保存を（命令が発生するたびに）無条件で引き起こすか、または何らかの状態値に基づいて、条件付きで引き起こすことができる。状態データが保存される正確なメカニズムは、変化してよい。トレース・インストルメンテーションは、コード内のインライン命令であるか、あるいは割り込みをトリガーする別個のルーチンまたは命令への呼び出しであることができる。

１つまたは複数の実施形態では、トレース命令６１５（インストルメンテーション）は、データ・ストリーミング・プログラムを生成するためにコンピュータ１３６によって使用される共通実行時コード６１４の少なくとも１つのバージョンに含まれる。実際、インストルメンテーションを含んでいない共通実行時コードを含む、共通実行時コードの複数のバージョンが存在することができる。異なるタイプのプロファイル・データを収集するために、複数の異なるインストルメントされたバージョンが存在することができる。共通実行時コード内のインストルメンテーションは、異なる各データ・ストリーミング・アプリケーションの開発者が独自のインストルメンテーションを作成する必要性をなくすことによって、データ・ストリーミング・アプリケーションを開発するプロセスを簡略化し、プロファイル・データの収集および解析を標準化する。

共通実行時コード６１４は、通常、トレース可能な事象が発生するルーチンを含んでいる。具体的には、１つまたは複数の実施形態では、共通実行時コード６１４は、データ・ストリーミング・アプリケーション内で新しいタプルを割り当てるためのルーチン、タプルを１つの処理要素から次の処理要素に送信するためのルーチン、データ・ストリームの外部のデータにアクセスするためのルーチン（検索事象を含んでもよい）、およびタプルをデータベースに出力するためのルーチンを含む。１つまたは複数の実施形態に従ってタプルをトレースすることにおいて対象となることのある追加のルーチンは、タプルをコピーまたは複製するためのルーチン、タプルを削除するためのルーチン、タプルの（フィールド、フィールド長などの）定義を変更するためのルーチンなどを含んでよい。１つまたは複数の実施形態では、これらの事象のいずれかまたはすべては、トレース・データの収集を引き起こすトレース可能な事象であってよく、適切なインストルメンテーションが、動作を実行する対応するルーチンに配置される。

１つまたは複数の実施形態では、共通実行時コード６１４のインストルメントされたバージョンは、トレース解析において役立つ追加データを追加することによって、データ・ストリーミング・アプリケーションで使用されるタプルの構造を変更する。図９は、さまざまな実施形態に従う、トレース・データのプロファイル解析をサポートするために変更された、データ・ストリーミング・アプリケーションの変更されたタプル９０１の概念的表現である。図９を参照すると、タプル９０１は、タプル・タイプ９０３、一意のタプル識別子９０４、および可変数の親の対９０５を含んでいるヘッダー９０２を含んでおり、各親の対は、各親タプル・タイプ９０６および親タプル識別子９０７を含んでいる。このヘッダーは、その他のデータを含んでよい。タプルは、データ・ストリーミング・アプリケーションによって定義された可変数のユーザ・データ・フィールド９０９〜９１１を含んでいる本体部分９０８をさらに含んでおり、ユーザ・データ・フィールドのうちの３つが図９に示されており、それらのユーザ・データ・フィールドの数が変化してよいということが、理解されている。タプル・タイプ９０３は、共通の定義済み構造を有するタプルのセットの名前であり、概ね、複数のタプル（レコードまたは行とも呼ばれる）を含んでいるデータベース・テーブルのテーブル名に対応している。タプル識別子９０４および親の対９０５は、共通実行時コード６１４のインストルメントされたバージョンによって追加された追加のフィールドである。これらのフィールドは、データ・ストリーミング・アプリケーションによって、トレース解析またはその他の目的あるいはその両方のために内部で使用され、アプリケーションのユーザにとって可視である必要はない。

共通実行時コードのインストルメントされたバージョンでは、新しいタプルを作成するルーチンが、新しく作成されたタプルに、前述のフィールドを自動的に割り当て、一意の通し番号に似ている一意のタプル識別子９０４を割り当てる。新しく作成されたタプルが既存のタプル（親タプル）から作成されたか、またはコピーされた場合、親タプルのタプル・タイプおよび一意のタプル識別子が、それぞれ親タプル・タイプ９０６および親タプル識別子９０７として、新しいタプルの親の対９０５にコピーされる。複数の親のチェーンが存在する可能性があるため、直近の親のすべての親の対９０５も、新しく作成されたタプルの各親の対９０５にコピーされる。

図１０は、さまざまな実施形態に従う、データ・ストリーミング・アプリケーションのプロファイル・データを収集するプロセスを上位で示すフロー図である。図１０を参照すると、インストルメントされたコードが、コンパイラ１３６によってコンパイルされる（ブロック１００１）。ブロック１００１で表されたコンパイルは、静的コンパイルまたは動的コンパイルのいずれかであることができる。静的にコンパイルされる場合、ユーザは、共通実行時コードの適切なインストルメントされたバージョンの使用を指定することによって、またはサポートされている場合は、インストルメントされたバージョンを使用するための特殊なコンパイラ指示文またはオプションによって、コンパイル時にインストルメンテーションを含むコンパイルを指示する。実行時に動的にコンパイルされる場合、データ・ストリーミング・アプリケーションの実行を呼び出しているユーザが、共通実行時コードのいずれかのインストルメントされたバージョンを含んでいるコード・ファイル（例えば、ソース・コードまたは中間コード）を指定する。コンパイラ１３６は、適切な指示文に応答して、データ・ストリーミング・アプリケーションを（場合によって、静的または動的に）コンパイルし、トレース命令を組み込む。

データ・ストリーミング・アプリケーションは、トレースが有効化されて、実行のために呼び出され、オプションのトレース・パラメータが指定される（ブロック１００２）。図１０では、ブロック１００２がブロック１００１の次に来るように表されているが、特定の動的コンパイル環境では、データ・ストリーミング・アプリケーションが実行のために呼び出された後に、コンパイルが発生してよいということが、理解されるであろう。

１つまたは複数の実施形態では、共通実行時コード内に存在しているインストルメンテーション命令は、特定のデータ・ストリーミング・アプリケーションに固有ではないため、タプルの特定のタイプまたはタプル・タイプの特定のセットに固有ではない。例えば、タプルを１つの処理要素から次の処理要素に送信する共通実行時ルーチンは、（任意のタイプの）タプルが送信されるときに常にトリガーされるトレース命令を含むことができる。ユーザがタプルの特定のタイプまたはタプル・タイプの特定のセットをトレースしたい場合、ユーザは、データ・ストリーミング・アプリケーションが呼び出されるときに、トレースされるタプルをオプションのトレース・パラメータとして指定する。トレース命令がトリガーされたときに、コードは、対応する共通実行時ルーチンによって処理されているタプルが、トレースされるべきタイプであるかどうかを判定し、それに応じてトレース・データを保存する。追加の実行時トレース・オプション（run-time tracing options）が可能である。例えば、オペレータ・グラフを通る、可能性のあるトレース可能な事象または経路の一部のみをトレースすることが望ましいことがある。オペレータ・グラフを通るすべての経路をトレースすることを可能にする全体的なトレース命令が共通実行時コードに存在してよいが、ユーザは、トレースされる特定の経路を指定するか、またはその他の方法で、トレースされる事象を制限してよい。

したがって、ブロック１００２で、データ・ストリーミング・アプリケーションが実行のために呼び出されるときに、ユーザは、任意のトレース・パラメータを指定してよい。ユーザは、性能上の理由のため、トレースを完全に無効化するオプションを保有してよい。データ・ストリーミング・アプリケーションの実行プロファイルを解析すること、およびプロファイル検索事象データ（profile lookup event data）５２６を含んでいるオペレータ・グラフ・プロファイル・データ５２５を生成することにおいて使用するためのトレース・データを収集するために、トレースが有効化されており、検索事象が発生したときに常に対象の１つまたは複数のタプル・タイプに関するトレース・データが保存され、対応するタイプのタプルが作成されて、ある処理要素から別の処理要素に送信されるか、またはデータベースに出力されるのが好ましい。必要に応じて、追加の事象がトレースされてよい。少なくとも最初に、通常は、対応するタプルの作成または送信と共に、すべての検索事象がトレースされることが期待されるであろう。しかし、データ・ストリーミング・アプリケーションがすでにプロファイルされた後に、ユーザは、対象となることが分かっている特定の検索事象をトレースしたいことがある。

ストリーム・マネージャ１３４は、さまざまな計算ノード１１０で実行を開始し、トレースを制御する環境パラメータを含む、いずれかの環境パラメータを初期化することによって応答する（ブロック１００３）。例えば、トレース有効化フラグ（trace enable flag）が設定されてよく、ビット・マスクまたはその他のデータ構造が、トレースされるべき望ましい事象、収集されるべきトレース・データなどに関して、トレースを制御するように初期化されてよい。

データ・ストリーミング・アプリケーションは、各計算ノード１１０および管理システム１０５において同時に実行され、それが図１０のブロック１００４Ａ〜Ｄとして表されている。各ノードまたは管理システム内の動作は、表現を明確にするために、ブロック１００４Ａのみに示されており、それらの動作がブロック１００４Ｂ〜Ｄにおいても同様であることが理解されている。各ノード（または管理システム）内で、データ・ストリーミング・アプリケーション・コードが、場合によっては複数の同時スレッド（ブロック１００５として簡略化された形態で表されている）内で、トレース命令が発生するまで実行される。トレース命令は、トレースが有効化されているかどうかのチェックを引き起こす（ブロック１００６）。トレースが有効化されていない場合、ブロック１００６で「いいえ」の分岐が選択されて、実行が再開される。トレースが有効化されている場合、トレース・コードが、事象および現在の状態データが、実行が呼び出されたときに指定されたトレース・パラメータに一致するかどうかを判定する（ブロック１００７）。例えば、検索動作、タプルの作成、またはある処理要素から別の処理要素へのタプルの送信、あるいはその組み合わせなどの特定の事象の場合、トレース・コードは、実行中に一時停止を引き起こすトレース命令がそれらの事象のうちの１つから発生したかどうか検証し、特定のタプル・タイプのトレースが指定された場合、トレース・コードは、トレース事象に関連付けられたタプルが指定されたタイプであることを検証する、などとなる。事象／状態データが指定されたトレース・パラメータに一致しない場合、ブロック１００７で「いいえ」の分岐が選択されて、実行が再開され、一致する場合、「はい」の分岐が選択され、トレース・コードが、保存されるトレース・データの範囲を決定する（ブロック１００８）。トレースでは、ほとんどすべてのデータを保存できるが、１つまたは複数の実施形態では、保存されたトレース・データは、トレース可能な事象に関連付けられたタプルのコピー、およびトレース可能な事象の時点でタプルが存在したオペレータ・グラフ内の位置を含む。次に、このデータは、ローカルのトレース・データ３１８に保存されるか、またはトレース命令が管理ノードで実行されている場合は、管理ノードのトレース・データ５２７に保存される（ブロック１００９）。

実行中のある時点で、終了条件が発生し、終了ブロックへのフロー・ラインによって示されているように、プログラムの実行の終了を引き起こす。そのような終了条件は、例えば、すべてのデータの処理の完了、割り込み、エラー条件、またはその他の終了条件であることができる。

プロファイル・トレース・データ（profile trace data）は、データ・ストリーミング・アプリケーションの１つまたは複数の実行インスタンスの間、または１回の実行中の複数の時間間隔の間、あるいはその両方の間にトレースすることによって、収集することができ、データ・ストリーミング・アプリケーションの挙動に関してより多くのことが学習されたき、あるいはアプリケーション・コードまたはアプリケーション・コードが通常処理するデータに対する変更が、アプリケーションの挙動に対する変更を引き起こしたときに、時間と共に改善されるか、または定期的に更新されてよい。

検索事象サマリー・データの生成
１つまたは複数の実施形態に従って、管理システム１０５でプロファイル・データ・アナライザ５２３を使用して、収集されたプロファイル・データが解析され、検索事象サマリー・レコード５２６のセットを生成する。検索事象サマリー・レコードは、特定のタプル・タイプ、またはタプルの属性値、またはオペレータ・グラフ内の特定の位置で発生するその他の状態変数、あるいはその組み合わせなどの、先行する検索予測事象を、その後発生する検索事象と相関付け、その後の検索事象が実際に発生する確率または可能性、または先行する検索予測事象の発生とその後の検索事象の間の時間遅延の何らかの測定値をさらに指定することができる。

本明細書において使用されるとき、「検索事象」は、データ・ストリーミング・アプリケーションのバッファおよびキャッシュの外部でのデータの取得、すなわち、データ・ストリーミング・アプリケーションの実行中の処理要素によるデータに対する現在の必要性の結果としての、ストレージまたはリモート・デバイスからの取得である。検索事象は、従来のコンピュータ・プログラムの実行中のページ・フォールトに類似しているが、ネットワークを経由してアクセスされるデータを含むことができるという意味では、さらに広い。検索事象は、必然的に、必要なデータを取得するためにかなりの時間を要し、データ・ストリーミング・アプリケーションの性能に影響を与えることがある。ストリーミングされたデータがさまざまなバッファに保持されるため、ストリーミングされたデータ・タプル自体は、自動的に処理要素によって使用可能になり、検索事象では取得されない。検索事象は、処理要素においてタプルを処理するために何らかの形で必要になるその他のデータを取得するために、必要になることがある。したがって、検索事象はタプル（具体的には、検索事象をトリガーした処理要素によって処理されているタプル）に関連付けられるが、関連付けられたタプル自体を検索事象において取得する必要はない。

図１１は、さまざまな実施形態に従う、例示的な検索事象サマリー・レコード５２６のセットの構造の概念図である。これらのレコードは、データ・ストリーミング・アプリケーション内の先行する検索予測事象を、その後発生する検索動作と相関付け、特に、実行中のデータ・ストリームにおいて、検索されたデータに対する実際の必要性が発生する前に、検索動作を予測する先行する事象に応答して検索動作の開始をトリガーするために、使用されてよい。

図１１を参照すると、検索事象サマリー・データ５２６は複数のレコード１１０１を含んでおり、各レコードは、先行する検索予測事象および結果として生じる検索動作の１つの対に対応している。先行する事象は、指定されたタイプの、必要に応じて１つまたは複数の指定された属性値を含み、オペレータ・グラフ内の指定された位置で発生し、必要に応じて１つまたは複数の指定された外部状態変数値に従う、タプルとして表される。検索事象サマリー・データ内の各レコード１１０１は、先行する事象（すなわち、特定のタプルの存在）が発生するオペレータ・グラフ内の位置を指定するトリガー位置フィールド１１０２、先行する事象を構成するためにオペレータ・グラフ内の対応する位置で一時的に保持されるタプルのタイプを指定する内部タプル・タイプ・フィールド１１０３、トリガー位置１１０２で指定されたトリガー位置で、トレース・データ内で検出された、タイプ・フィールド１１０３で指定されたタイプの内部タプルの数を指定する内部タプル・カウント・フィールド１１０４、および検索事象サマリー・レコードに対応する検索事象のグループ内の検索事象の数を指定する検索事象数フィールド１１０５を含む。

１つまたは複数の実施形態では、各レコード１１０１は、検索動作が発生するオペレータ・グラフ内の位置（すなわち、検索されたデータが読み込まれる位置）を指定する検索位置フィールド１１０６、および結果として生じる検索事象を定義する検索事象記述子（lookup event descriptor）１１０８をさらに含む。検索事象記述子は、対応する先行する事象から生じる特定の検索動作を定義するために必要な任意のデータを含んでよく、ネットワーク経路、デバイス経路、デバイス識別子またはストレージ・デバイスを識別する同様のもの、ネットワークの位置、あるいは検索されたデータが取得される他の実体と、ファイル名、アドレス、または検索されたデータが取得される実体内の検索対象のデータの位置を指定するその他のデータ、あるいはその組み合わせと、ページ数または取得されるデータ量のその他の測定値と、検索されたデータが読み込まれる位置のアドレスまたはその他の指定子を指定する読み込み先と、検索動作を定義するために必要になることがある任意のその他のデータとを含んでよいが、必ずしもこれらに限定されない。

各レコード１１０１は、必要に応じて、検索事象に関する特定の時間遅延をまとめて指定する遅延パラメータ１１０７をさらに含んでよく、適切な場合、先行する検索予測事象の検出後の実行中に、データ検索動作の開始を遅延させるために使用されてよい。遅延パラメータ１１０７は、先行する事象の発生と、データ・ストリーミング・アプリケーションによる、指定されたデータ検索動作の対象であるデータに対する必要性との間の経過時間を指定する１つまたは複数の値、およびデータ検索動作の開始から、取得されたデータがデータ・ストリーミング・アプリケーションで使用可能になるまでの経過時間を指定する１つまたは複数の値を含んでよい。代替として、遅延パラメータは、検索予測事象の検出とデータ検索動作の開始の間の遅延時間を表すために、これらの数値の両方が組み合わせられた複合値であることができる。遅延パラメータ１１０７内のこれらの数値のいずれかは、単一の値または複数の値（例えば、平均時間間隔およびその平均値からの標準偏差）であることができ、単一の値の場合は、平均経過時間、最小経過時間、検索動作の既定の部分の最小経過時間、またはその他の時間の測定値を表すことができる。

１つまたは複数の実施形態では、レコードは、１つまたは複数のキー・フィールド識別子１１０９（キー・フィールド識別子１１０９のうちの１つが、図１１に示されている）であって、それぞれ、フィールド１１０３内で指定された内部タプル・タイプ内のキー・フィールドを指定する、キー・フィールド識別子１１０９と、各キー・フィールド識別子に対応する可変数のキー・フィールド仕様１１１０であって、各仕様が、対応する最小値１１１１、対応する最大値１１１２、および対応する確率値１１１３を指定する、キー・フィールド仕様１１１０とをさらに含む。確率値１１１３は、先行する検索予測事象が発生することを前提として、その後発生する検索事象が発生する確率を表し、先行する事象は、内部タプル・タイプ・フィールド１１０３で指定されたタイプのタプルが、グラフ位置１１０２で、最小値１１１１および最大値１１１２によって指定された範囲内のキー・フィールド値を、キー・フィールド１１０９に含んでいることである。確率値は、０〜１の範囲内の浮動小数点値として表されてよい。代替として、確率値は値の対として格納されてよく、この確率値は、これらの値の対の商として得られる。例えば、値の対は、その後の検索事象の数のカウントおよび対象のグラフ位置で検出されたＩＴタイプの（必要に応じて、特定のパラメータを含んでいる）タプルの数のカウントを表す、２つの整数であってよい。

１つまたは複数のさらに別の実施形態では、レコード１１０１は、１つまたは複数の外部状態変数識別子１１１４（外部状態変数識別子１１１４のうちの１つが、図１１に示されている）であって、外部状態変数（すなわち、タプルの外部の変数）をそれぞれ指定する、外部状態変数識別子１１１４と、各外部状態変数に対応する可変数の外部状態変数仕様１１１５であって、それらの各仕様が、対応する最小値１１１６、対応する最大値１１１７、および対応する確率値１１１８を指定する、外部状態変数仕様１１１５とをさらに含んでよい。確率値１１１８は、確率値１１１３に類似しており、先行する検索予測事象が発生することを前提として、その後発生する検索事象が発生する確率を表し、すなわち、内部タプル・タイプ・フィールド１１０３で指定されたタイプのタプルが、グラフ位置１１０２で発生し、指定された外部状態変数識別子１１１４が、最小値１１１６および最大値１１１７によって指定された範囲内の値を含んでいる確率を表す。確率値は、確率値１１１３に関して前述されたいずれかの方法で表されてよい。

１つまたは複数の代替の実施形態では、キー・フィールド１１０９およびキー・フィールド仕様１１１０、または外部状態変数識別子１１１４および外部状態変数仕様１１１５、あるいはその両方は任意選択的であるか、または使用されなくてよい。単一の確率値は、先行する内部タプル・タイプおよびグラフ位置に対して指定されてよい（すなわち、単一の確率値は、対応するタプル内のどのデータの値にも関係しない）。１つまたは複数のさらに別の代替の実施形態では、確率値が使用されず、先行する事象が発生した場合に、その後の検索事象も必要になるということが仮定される。

トレースによって収集されたデータは、検索事象サマリー・レコード５２６を生成するためのさまざまな方法のいずれかで解析されてよい。概念的に、解析とは、その後発生する検索事象ごと、オペレータ・グラフ内を通過する、検索を引き起こすタプルまたは検索を引き起こすタプルの親タプルがオペレータ・グラフ内を通過した位置ごと、およびその位置での内部タプル（または親タプル）ごとに、その位置でのそのようなタプル（先行する事象）の数およびその後発生する検索事象の数を決定することである。さらに、１つまたは複数のキー・フィールドまたは外部状態変数あるいはその両方が識別された場合、それらの数が、対応するキー・フィールドまたは外部状態変数の値の範囲別に分けられる。さらに、先行する事象およびその後の検索事象が識別された後に、先行する事象の発生と検索事象の発生の間の遅延時間（平均値、最小値など）の１つまたは複数の測定値が決定され得る。

図１２は、さまざまな実施形態に従う、検索事象サマリー・レコード５２６のセットを生成するためのプロファイル・データを解析するプロセスを上位で示すフロー図である。管理システム１０５で、プロファイル・データ・アナライザ５２３によって、またはプロファイル・データ・アナライザ５２３の制御下で、解析が実行される。

図１２を参照すると、さまざまなノードで収集されて、計算ノード１１０の各ローカル・ノード・トレース・データ・キャッシュ（local node trace data caches）３１８に格納されたトレース・データが、解析のために管理システム１０５に送信される（ブロック１２０１）。管理システムでのトレース・データの収集は、表現を簡単にするために、単一のブロックとして示されている。実際に、図１２で表されているように、解析の開始時に、すべてのトレース・データを管理システムに送信することが可能である。代替として、管理システム１０５のプロファイル・データ・アナライザ５３２は、解析が実行されるときに、さまざまな計算ノード１１０に対して、増加的にトレース・データを要求してよい。後者のアプローチは、予備選別作業の一部を計算ノードにオフロードする。例えば、管理システムは、特定の位置で発生する特定の検索事象のみが対象であることを決定してよく、それにより、それらの検索事象のみに関する要求データに従って、解析中のネットワーク帯域幅の利用を削減し、最終的に使用されない大量のトレース・データをスキャンする管理システムの負担を低減する。

トレース・データ内の検索事象が識別され、データ・ストリーミング・アプリケーション内での発生理由および検索されたデータのソースに従って、グループに分類される（ブロック１２０２）。１つまたは複数の実施形態では、これは、同じタプル・タイプの代わりに、同じ処理要素の実行によって生成された、同じ外部データ・ソースにアクセスしている検索事象が、一緒にグループ化されるということを意味する。同じ「外部データ・ソース」は、必ずしも正確に同じデータを意味しておらず、厳密には、通常、同じデータは何らかのキャッシュ内で維持されるため、同じデータが繰り返し検索される可能性は低い。例えば、外部データ・ソースは、外部データベースなどの非常に大きいデータ実体であることがあり、その場合、各処理要素によって処理されているタプルの１つまたは複数の属性が、外部データ・ソースからのどのデータがアクセスされるかを決定するために使用される。特に、外部データ・ソースは、データベース１４０またはその特定のテーブル８２１〜８２３であることができ、あるいは何らかの他のデータベースまたはそのテーブルであることができ、あるいは管理システム１０５、計算ノード１１０のいずれか、またはコンパイラ・システム１０２内の配列またはその他のデータ構造、あるいはローカルに、またはネットワーク１２０を経由してアクセスできる任意のその他のデータであることができる。処理されているタプルの１つまたは複数の属性が、アドレス、キー値、配列インデックス、または検索動作によって取得されるより大きい外部データ・ソース（データベース、配列、またはその他のデータ構造）内の特定のデータの識別に使用される何らかのその他の値を決定するために、使用されてよい。

１つまたは複数の任意選択的な実施形態では、検索事象のグループが、優先順位付けされ、解析のために選択される（ブロック１２０３）。検索事象グループは、検索動作の対応するカテゴリに起因する、データ・ストリーミング・アプリケーションの性能に対する悪影響の適切な測定値に従って、優先順位付けされてよい。例えば、グループは、各グループ内の検索動作の総数、または各グループ内の検索動作を実行するために必要な合計累積時間、あるいは性能に対する影響の何らかのその他の測定値に従って優先順位付けされてよい。１つまたは複数のグループが、解析のために選択される。一実施形態では、既定のしきい値を超える性能への影響を有するすべてのグループが選択される。別の実施形態では、性能への影響の平均値からある偏差以上の性能への影響を有するグループが選択される。別の実施形態では、性能に対して最大の影響を有するグループのみが選択される。

性能に対する悪影響の何らかの測定値に従う検索事象のグループの解析は、性能に対する影響が少ないか、影響がない検索事象のカテゴリに関する解析およびその後の是正処置を防ぐよう意図されている。例えば、検索事象の一部のタイプは、一部のエラー条件が発生する場合のように、まれにしか発生しないことがある。そのようなまれに発生する検索事象を予測しようとする試みは、かなりの不正確さの影響を受けることがあり、それを実行するオーバーヘッドが、性能上のメリットを上回ることがある。しかし、１つまたは複数の実施形態では、任意選択的なブロック１２０３が実行されず、検索事象のすべてのグループが解析される。

次に、解析のために優先順位付けされたグループのうちから、次のグループが、解析される現在のグループとして選択される（ブロック１２０４）。オペレータ・グラフ内の位置ごとに、トレース・データが解析され、解析用に選択された検索事象のグループに対応する１つまたは複数の検索事象サマリー・レコード１１０１のセットを生成する。これが、図１２においてブロック１２０５〜１２１０として表されている。「位置」は、データ・ストリーミング・アプリケーション内のオペレータ・グラフの任意のサブセットであることができ、この位置でタプルが一時的に保持されてよく、この位置でタプルがトレースされる。１つまたは複数の実施形態では、「位置」は、オペレータ・グラフ内の処理要素であり、本明細書ではそのように説明されており、位置の粒度が計算ノード、オペレータ、または何らかのその他の実体であることができるということが理解されている。

各グループは検索事象の特定のカテゴリに対応しているため、対応する検索事象は、特定のタプル・タイプの代わりに、データ・ストリーミング・アプリケーション内の特定の処理要素で必然的に発生する。プロファイル・データ・アナライザが、オペレータ・グラフのデータにアクセスし、検索事象を引き起こしたタプル・タイプ（または、このタプル・タイプの親）を生成した、オペレータ・グラフ内の先行する処理要素を決定する（ブロック１２０５）。すなわち、プロファイル・データ・アナライザは、オペレータ・グラフを後方にトラバースする。そのような先行する処理要素が存在する場合（ブロック１２０６からの「はい」の分岐）、その処理要素が、解析用の現在の処理要素として選択される。説明を簡単にするために、本明細書では、そのようなタプル・タイプが存在する処理要素ごとに、唯一のそのような先行する処理要素が存在するということが仮定されるが、実際は、複数の先行する処理要素が存在することが可能であり、その場合、そのような各処理要素が順番に解析される。

プロファイル・データ・アナライザが、トレースをスキャンして、現在の処理要素内の対応するタプル・タイプ（または、このタプル・タイプの親）のすべての発生を識別し（ブロック１２０７）、これらのタプルが、内部タプルの現在のセットを形成する。現在の処理要素および検索事象グループに対応する検索事象サマリー・レコード１１０１が生成される（ブロック１２０８）。検索事象サマリー・レコードのトリガー位置１１０２は、現在の処理要素であり、内部タプル・タイプ１１０３は、現在の処理要素内の対応するタプル・タイプ（または、このタプル・タイプの親）であり、内部タプル・カウント１１０４は、トレースにおいて検出されたタプルの数であり、検索事象数１１０５は、検索動作の現在のグループ内の検索動作の数であり、検索位置１１０６は、現在のグループ内の検索が発生した処理要素であり、検索事象記述子１１０８は、現在のグループの検索の識別パラメータを含んでいる記述子である。検索事象数（フィールド１１０５）に対する内部タプル数（フィールド１１０４）の比率によって、実行中にトリガー位置で指定されたタイプのタプルが発生したときに、検索事象の現在のグループを形成する検索事象のカテゴリのその後の検索事象が必要になる近似的な確率が得られる。

１つまたは複数の実施形態では、トレース・データが解析されて、１つまたは複数の遅延パラメータ１１０７を決定し、それらの遅延パラメータ１１０７が検索事象サマリー・レコード１１０１に追加される（ブロック１２０９）。遅延パラメータは、適切な状況において、実行中の先行する検索予測事象の検出後に、検索事象の開始を遅延させるために使用されてよい。先行する検索予測事象の検出後の遅延時間は、検索されたデータを、検索位置の処理要素によって必要とされる直前に使用可能にするために、ちょうど足りる長さになるのが理想的である。この遅延時間は、先行する検索事象（すなわち、適用可能なトリガー位置でトレースされたタプル）の発生と（データの必要性を示す）検索動作の開始の間の時間間隔に応じて決定することができ、検索動作を実行するために必要な時間よりも短い。多くの場合、後者の時間は、前者の時間間隔よりも長く、先行する検索予測事象が検出されたときに、すぐにデータ検索動作を開始するべきであるということを示している。これらの時間間隔は必ずしも均一でないため、平均時間間隔およびその標準偏差などの、標準的挙動または平均的挙動の何らかの測定値を決定するために、トレース・データが解析されてよく、先行する事象と検索事象の間の間隔、およびデータ検索に必要な時間の両方が、別々に測定されてよい。性能監視統計値などの、何らかの他のソースから平均検索動作時間の測定値を取得することが、代替的に可能であってよい。

１つまたは複数の実施形態では、タプル内の特定の属性値または外部状態変数値あるいはその両方と、その同じタプルに関するその後の検索事象との間の相関関係を識別するために、トレース・データが解析される（ブロック１２１０）。タプル内の属性値とその後の検索事象の間で相関関係が検出された場合、キー・フィールド１１０９および１つまたは複数の関連付けられたキー・フィールド仕様１１１０が、ブロック１２０８で生成された検索事象サマリー・レコードに追加されてよい。同様に、外部状態変数値とその後の検索事象の間で相関関係が検出された場合、外部状態変数識別子１１１４および１つまたは複数の関連付けられた外部状態変数仕様が、検索事象サマリー・レコードに追加されてよい。

具体的には、対応する内部タプル・タイプの内部タプル内のいずれかのキー属性フィールドのいずれかの値に関する、またはいずれかの外部状態変数値に関する、実行されている検索動作の現在のグループ内のその後の検索動作の確率が、同じタプル・タイプの内部タプルのセットに関する確率（すなわち、検索事象数フィールド１１０５に対するタプル数フィールド１１０４の比率）と全体的に大幅に異なるかどうかを知ることが望ましい。キー・フィールドまたは外部状態変数あるいはその両方は、ストリーム・マネージャへの何らかの外部コマンドによって指定することができ、またはプロファイル・データ・アナライザ５２３でトレース・データを解析することによって決定することができる。具体的には、さまざまな解析技術または解析ツールのいずれかを使用して、データ内の相関関係を検出することができる。

そのようなキー・フィールドまたは外部状態変数および対応する値の範囲が識別された場合、キー・フィールド／外部状態変数がキー・フィールド１１０９または外部状態変数ＩＤ１１１４として検索事象サマリー・レコード１１０１に保存され、対象の各値または値の範囲、およびそれらに対応する検索事象の確率が、各最小値１１１１または１１１６、各最大値１１１２または１１１７、および各検索事象の確率１１１３または１１１８を含んでいる各キー・フィールド仕様１１１０または外部状態変数仕様１１１５として保存される。この確率は、タプルがトリガー位置で発生しており、対応する範囲内のキー・フィールド値を含んでいる（または、外部状態変数が対応する範囲内にある場合の条件下にある）ことを前提として、検索事象の現在のグループの検索事象が、その後、同じタプルに必要になる確率を反映する。

一実施形態では、キー・フィールド１１０９または外部状態変数ＩＤ１１１４は、対応する検索事象の確率が、同じタプル・タイプの内部タプルのセットに関する検索事象の確率よりも全体的に大幅に大きい値の場合にのみ、（対応するキー・フィールド仕様１１１０または外部状態変数仕様１１１５と共に）検索事象サマリー・レコード１１０１に保存される。代替の実施形態では、キー・フィールド１１０９または外部状態変数ＩＤ１１１４は、対応する検索事象の確率が、同じタプル・タイプの内部タプルのセットに関する検索事象の確率と全体的に大幅に異なる（大きいか、または小さい）値の場合に、（対応するキー・フィールド仕様１１１０または外部状態変数仕様１１１５と共に）検索事象サマリー・レコード１１０１に保存される。別の代替の実施形態では、同じタプル・タイプの内部タプルのセットに関する検索事象の確率が全体的に十分に大きく、タプルがトリガー位置で発生したときに対応するデータが常に検索されるはずであるということを示している場合、ブロック１２１０がスキップされてよく、キー・フィールド１１０９も外部状態変数ＩＤ１１１４も、（対応するキー・フィールド仕様１１１０または外部状態変数仕様１１１５と共に）検索事象サマリー・レコード１１０１に追加されない。

遅延パラメータが計算され（ブロック１２０９）、特定の属性／外部変数値と、その後の検索の間の相関関係に関してトレース・データが解析された（ブロック１２１０）後に、アナライザがブロック１２０５に戻り、グラフ内の別の先行する位置を決定する。

ブロック１２０６で、先行する処理要素が存在しない場合、オペレータ・グラフが対応するタプルの作成まで遡ってトラバースされており、ブロック１２０６から「いいえ」の分岐が選択され、検索事象の対応するグループが解析されたことを示す。この場合、解析されるべき検索事象の選択されたグループがまだ残っている場合、ブロック１２１１から「はい」の分岐が選択され、ブロック１２０４で次のグループが選択される。このようにして、すべてのグループが解析された場合、ブロック１２１１から「いいえ」の分岐が選択され、プロファイル・データの解析が完了する。

上記の説明および図１２の図では、理解しやすくするために、さまざまな動作が、連続して実行されているように示され、説明されているということが、理解されるであろう。しかし、システム効率をさらに向上するために、トレース・データの複数のスキャンを単一のスキャンに結合することによって、これらの動作のうちの多くを同時に実行することが可能であってよい。プロファイル・サマリー・レコード（profile summary record）の生成結果に影響を与えずに、特定の動作の順序を変更できるということが、さらに理解されるであろう。最後に、検索事象および先行する検索予測事象の解析に使用されるプロファイル・データの形態における多くの変形が可能であるということ、および本明細書に記載された検索事象サマリー・レコードが、使用できるプロファイル・データの可能性のある形態の一部のみを表しているということが、理解されるであろう。プロファイル・レコードは、その他のフィールドまたは追加のフィールドを含んでよく、トレース・データ以外のデータまたはトレース・データに加えたデータに基づいてよく、異なる方法でデータ・ストリーミング・アプリケーションの挙動を特徴付けてよい、などであってよい。

実行中の初期検索動作
１つまたは複数の実施形態に従って、各トリガーが、対応する検索事象サマリー・レコードによってそれぞれ識別される１つまたは複数のトリガー位置に挿入される。実行中のトリガーの発生は、検索予測事象であるか、あるいは適用可能な検索事象サマリー・レコードで指定されたパラメータに従う検索予測事象またはこの検索予測事象から得られたデータあるいはその両方の検証を引き起こす。検索予測事象を検出することに応答して、検索されたデータに対する実際の要求に先立って、検索動作が実行され、検索されたデータが、このデータを必要とすると予測された処理要素によってアクセスできるバッファまたはキャッシュに提供される。検索動作は、検索されたデータを必要とすると予測された処理要素がこのデータを待つことを引き起こさずに遅延が実行可能であることを、遅延時間データが示している場合に、検索予測事象の第１の指示を超えて遅延されてよい。

１つまたは複数の実施形態では、データ・ストリーミング・アプリケーションの開始時またはその後の時々あるいはその両方の時点で、管理システム１０５内のストリーム・マネージャ１３４は、検索事象サマリー・レコード５２６にアクセスして、検索マスク５２１および１つまたは複数のトリガー・パラメータ・データセット５２２を生成する。検索マスクのローカル・コピーが検索された後に、トリガー・パラメータ・データセットがさまざまな計算ノード１１０に送信される。これらのデータ構造のローカル・コピーは、計算ノードのメモリ３００内で維持され、計算ノード１１０内のさまざまな処理要素３１１の実行を制御する、状態データ構造になるよう意図されている。

図１３は、さまざまな実施形態に従う、実行中の検索動作を制御する状態データ構造を生成または更新するプロセスを上位で示すフロー図である。図１３を参照すると、ストリーム・マネージャ１３４が、データ・ストリーミング・アプリケーションの実行中に先行検索動作を制御する状態データを初期化／更新するための条件を検出する（ブロック１３０１）。この条件は、データ・ストリーミング・アプリケーションの初期化であってよい。代替として、システム構成に対する変更、ワークロードの変化、性能調整などを考慮するために、状態データが時々更新されてよい。この更新は、固定されたスケジュールに従って、または更新の必要性を示すことのある特定の事象（システム構成の変更など）が検出されたとき、あるいはその両方の時点で実行され得る。ストリーム・マネージャは、そのような条件自体を必ずしも検出せず、検索状態データをリセットするか、または更新するための外部コマンドを単に受信してよい。

適切な条件の検出時に、ストリーム・マネージャは、オペレータ・グラフ１３２にアクセスして検索マスク５２１を初期化する（ブロック１３０２）。検索マスクは、すべての処理要素またはその他の実体が無効化されて、初期化される。１つまたは複数の実施形態では、本明細書に記載されているように、検索マスクおよび検索事象サマリー・レコードの両方が、処理要素の粒度を有しており、すなわち、処理要素ごとに個別のマスク・ビットが存在し、１つまたは複数の処理要素に対して個別の検索事象サマリー・レコードが存在する。ただし、マスクまたは検索事象サマリー・レコードあるいはその両方の粒度が異なることが可能であるということが、理解されるであろう。例えば、処理要素内のオペレータごとに個別のマスク・ビット、またはオペレータの少なくとも一部に対して個別の検索事象サマリー・レコード、あるいはその両方が存在できる。

どの検索事象サマリー・レコード５２６も選択されていない場合（ブロック１３０３からの「はい」の分岐）、ストリーム・マネージャは、次の検索事象サマリー・レコードを選択して取得する（ブロック１３０４）。

ストリーム・マネージャ１３４は、現在の検索事象サマリー・レコードに関して、先行検索を実行するかどうかの判定に使用される予測検索確率しきい値（predictive lookup probability threshold）を決定する（ブロック１３０５）。データに対する必要性の予測された確率がこのしきい値を超えた場合、検索動作が実行されるべきである。１つまたは複数の実施形態では、このしきい値は、複数の動的要因に応じて変化することができ、したがって、実行時に決定される。それらの要因は、次のいずれかまたはすべてを含んでよい。（ａ）活動、特に、検索で使用されるＩ／Ｏチャネルに対するＩ／Ｏ活動の現在のレベル。活動の現在のレベルが高いほど、先行検索動作のオーバーヘッド・コストが高くなり、したがってしきい値が高いことを示す。（ｂ）検索によって取得されるデータ量。やはり、検索のオーバーヘッド・コストに関連し、データ量が大きいほど、しきい値が高いことを示す。（ｃ）検索されたデータを受信するためのバッファ内のバッファ・メモリのサイズ。バッファのサイズが小さいほど、バッファの競合の可能性が大きくなることに起因して、しきい値が高いことを示す。（ｄ）検索動作を実行する時間の長さ。検索時間が長いほど、実際に必要とされるデータの検索に失敗することによるコストが大きくなり、したがってしきい値が低いことを示す。その他の要因または追加の要因が使用され得る。これらの動的要因に起因して、確率しきい値が、異なる検索動作では異なってよく、同じ検索動作では、時間と共に変化してよいということが、観察されるであろう。ただし、１つまたは複数の代替の実施形態では、固定された確率しきい値が使用され、ブロック１３０５を不要にする。

次に、ストリーム・マネージャが、選択された検索事象サマリー・レコード１１０１に関して、検索確率しきい値が満たされているかどうかを判定する（ブロック１３０６）。この場合、このレコードに関する検索確率は、内部タプル数１１０４に対する検索事象数１１０５の比率であり、この比率は、トリガー位置１１０２での対応する内部タプル・タイプ１１０３の内部タプルの発生を前提として、その後の検索動作が必要になる近似的な確率を表す。この比率が、以前に決定された検索確率しきい値を超えた場合、ブロック１３０６から「はい」の分岐が選択され、対応するトリガー・パラメータ・データセットが作成される（ブロック１３０８）。

ブロック１３０８で作成されたトリガー・パラメータ・データセットは、検索事象サマリー・レコード１１０１内のデータの省略されたバージョンであり、実行中に先行検索動作を管理するために必要なもののみを含んでいる。ストリーム・マネージャが、確率しきい値が満たされていることをすでに決定しているため、ブロック１３０８で作成されたトリガー・パラメータ・データセットが、確率データ、キー・フィールドまたはキー・フィールド仕様、外部状態変数ＩＤまたは外部状態変数仕様を含む必要はない。このデータセットの存在は、対応する先行検索動作が実行されるべきであるということを示す。次にストリーム・マネージャは、ブロック１３１０に進む。

ブロック１３０６で、このレコードの検索確率が検索確率しきい値を超えていない場合、ブロック１３０６から「いいえ」の分岐が選択される。その場合、検索事象サマリー・レコード１１０１内のキー・フィールド仕様１１１０または外部状態変数仕様１１１５が調べられ、対応する確率１１１０または１１１５がしきい値を超えているかどうかを判定する。検索確率しきい値を超えているそのような確率は、トリガー位置１１０２での内部タイプ・フィールド１１０３で指定されたタイプのランダムなタプルの発生がその後の検索事象の十分に高い確率を示していないが、キー・フィールドまたは外部状態変数あるいはその両方が、適用可能なキー・フィールド仕様１１１０または外部状態変数仕様１１１５で指定された範囲内の対応する値を含んでいる場合、その後の検索事象の確率が確かにしきい値を満たしており、先行検索動作が実行されるべきであるということを示す。それに応じて、ブロック１３０７から「はい」の分岐が選択され、対応するトリガー・パラメータ・データセットが作成される（ブロック１３０９）。

一実施形態では、１つのキー・フィールドも、外部状態変数仕様も、検索確率しきい値を満たしていない場合、ブロック１３０６で、複合条件が評価されてよい。例えば、異なるキー・フィールドまたは外部状態変数それぞれの２つの個別の条件が、検索確率しきい値を個々に満たしていない場合でも、個別の確率データ（例えば、先行する事象の数および必要なその後の検索の数のカウント）から、２つの条件の論理積に関して検索確率の推定を実行し、検索確率しきい値と比較できる。

ブロック１３０９で作成されたトリガー・パラメータ・データセットは、ブロック１３０８で作成されたトリガー・パラメータ・データセットに類似しているが、適用可能なキー・フィールドまたは外部状態変数あるいはその両方の１つまたは複数の条件を指定するための追加データを含んでいる。ブロック１３０８で作成されたトリガー・パラメータ・データセットの場合のように、トリガー・パラメータ・データセット内の実際の確率を指定する必要はなく、検索確率しきい値を満たす条件のみを指定する必要がある。複数の条件が存在することができ、複数の論理和として指定することができ、それらの各論理的条件は、１つまたは複数の論理積が取られた条件を含んでよい。次にストリーム・マネージャは、ブロック１３１０に進む。

次に、ブロック１３１０で、検索マスク５２１内の対応するマスク・ビットが、選択された検索事象レコード１１０１のトリガー位置フィールド１１０２で識別された位置に関して有効化される。このマスク・ビットは、実行中に検索動作のトリガーを有効化する。

１つまたは複数の実施形態では、ストリーム・マネージャは、遅延パラメータ１１０７をさらに使用して、内部タプル・フィールド１１０３で識別されたタイプのタプルがトリガー位置１１０２で発生する（先行する検索予測事象の）時間と、検索動作が実行されるためのその後の検索動作との間に十分な遅延時間間隔が存在するかどうかを判定する（ブロック１３１１）。すなわち、トリガー位置でタプルを検出した直後に先行検索動作が開始されると仮定して、検索動作が、そのタプルがフィールド１１０６で識別された検索位置で検索されたデータを必要とするときまでに完了するかどうかを判定する。過去の検索時間およびストリーミング遅延時間が変化するため、遅延パラメータが、望ましい信頼度で予測を行うための十分なデータを提供することが好ましい。例えば、検索動作のあるパーセンテージ（例えば、９０％）が時間通りに完了する場合に、遅延時間間隔が「十分」であると見なされるように、遅延時間および検索時間の平均値および標準偏差が提供されてよい。遅延時間が十分であると見なされる場合、トリガー・パラメータ・レコード（trigger parameter record）が、そのようにマーク付けされる。この決定は、下でブロック１３１２〜１３１９に関して説明されているように、特定の早すぎるトリガー・パラメータ・データセットを取り除くために使用される。ストリーム・マネージャはブロック１３０３に戻り、次のレコードを選択する。

ブロック１３０７で、どのキー・フィールド仕様または外部状態変数仕様（あるいはその組み合わせ）も、検索確率しきい値を超える検索確率を示していない場合、ブロック１３０７から「いいえ」の分岐が選択される。その場合、検索マスクは変更されず（すなわち、対応するトリガー位置に関して無効化されたままになる）、対応するトリガー・パラメータ・データセットが作成されない。その結果、実行中に、現在のトリガー位置１１０２から検索は実行されない。次に、ストリーム・マネージャはブロック１３０３に戻り、次の検索事象レコードを検討する。

このようにして、すべての検索事象レコードが調べられて処理されたときに、ブロック１３０３から「いいえ」の分岐が選択される。その後、ストリーム・マネージャは、冗長であるか、または早すぎる特定のトリガー・パラメータ・データセットを取り除き、対応するマスク・ビットを無効化する（ブロック１３１２〜１３１９に示されている）。

この取り除きは、検索動作のトリガーを削減することによって実行効率を改善するために実行される。特定のタイプの内部タプルが、データの検索を要求する前に、複数の処理要素を通過する場合、それらの処理要素のうちの２つ以上（場合によっては、すべて）が、検索確率しきい値を満たす対応する検索事象レコードを含んでいる可能性があり、したがって、トリガー・マスク内の対応するビットが有効化され、トリガー・パラメータ・データセットが作成される。取り除きが存在しない場合、実行中の複数の処理要素のそれぞれで先行検索がトリガーされる結果になるであろう（ただし、Ｉ／Ｏ動作キューなどの他のメカニズムは、重複する動作が実行されるのを回避することがある）。これには、次の２つの望ましくない影響がある。第１に、場合によっては、タプルが第１の処理要素の下流の第２の処理要素に到達するまで待つことが、（タプルの変化／削除に起因して）検索動作の数を減らすか、または検索されたデータをより新しくするか、あるいはその両方を行うことができる場合に、検索動作が、第１の処理要素で必要とされる時点よりも早くトリガーされることがある。第２に、同じデータに関して、異なる処理要素内で、検索が複数回トリガーされることがある。

ストリーム・マネージャは、取り除きの可能性について、トリガー・パラメータ・データセットを再調査する。この再調査は任意の順序で実行できるが、ある順序（例えば、オペレータ・グラフを後方にトラバースする）が、より効率的であることがある。取り除きの解析のために選択されていないトリガー・パラメータ・データセットがまだ存在する場合（ブロック１３１２からの「はい」の分岐）、ストリーム・マネージャは次のデータセットを選択する（ブロック１３１３）。

オペレータ・グラフ内の選択されたデータセットの直近の後続処理要素（successor(s) processing element）が識別される（ブロック１３１４）。「直近の後続処理要素」は、選択されたデータセット内で識別されるタイプの内部タプルを次に受信する処理要素である。多くの場合、１つの直近の後続処理要素のみが存在するが、オペレータ・グラフのデータ・フローにおける分岐を示す複数の後続処理要素が存在することができる。すべての直近の後続処理要素に関して、対応する処理要素での検索予測タプルの発生と、その後の検索事象との間の遅延時間間隔が、検索を実行するために必要な時間よりも大きいか（ブロック１３１１ですでに決定されている）、または対応するトリガー・パラメータ・データセットが存在しない場合（特定の経路の検索の確率が低いことを示す）、ブロック１３１５から「はい」の分岐が選択され、現在選択されているトリガー・パラメータ・データセットが取り除かれ、トリガー・マスク（trigger mask）５２１内の対応するマスク・ビットが無効化される（ブロック１３１６）。後続処理要素において、検索動作が実行されるのを待つことができるため、取り除きは適切である。取り除いた後に、ストリーム・マネージャはブロック１３１２に戻り、次のトリガー・パラメータ・データセットを選択する。

ブロック１３１５で、直近の後続処理要素が、検索動作を実行するための十分な遅延時間間隔を有していない場合、「いいえ」の分岐が選択される。その場合、検索が、現在選択されているデータセットに対応する処理要素と少なくとも同じくらい早く処理されるべきであるため、現在選択されているデータセットは取り除かれない。直近の後続処理要素のトリガー・パラメータ・データセットが、現在選択されているトリガー・パラメータ・データセットの条件に含まれている条件を含んでいない場合（すなわち、必ずしも現在のトリガー・パラメータ・データセットによってトリガーされない新しい条件を含んでいる場合）、ブロック１３１７から「いいえ」の分岐が選択され、ブロック１３１２で次のトリガー・パラメータ・データセットが選択される。直近の後続処理要素のトリガー・パラメータ・データセットが、現在選択されているトリガー・パラメータ・データセットの条件に含まれている条件を含んでいる場合、ブロック１３１７から「はい」の分岐が選択され、後続処理要素のトリガー・パラメータ・データセットが取り除かれ、トリガー・マスク５２１内の対応するマスク・ビットが無効化される（ブロック１３１８）。これを実行する理由は、後続処理要素によって実行されるすべての検索が、現在選択されているトリガー・パラメータ・データセットによって実行される検索と重複するからである。取り除かれた直近の後続処理要素の下流の後続処理要素がすべて識別され、それらの後続処理要素が、現在選択されているトリガー・パラメータ・データセットの条件に含まれている条件を同様に含んでいる場合、それらの後続処理要素が同様に取り除かれ、トリガー・マスク５２１内の対応するマスク・ビットも同様に無効化される（ブロック１３１９）。次に、ストリーム・マネージャがブロック１３１２に戻り、次のトリガー・パラメータ・データセットを選択する。

このようにして、すべてのトリガー・パラメータ・データセットが再調査され、必要に応じて取り除かれたときに、ブロック１３１２から「いいえ」の分岐が選択される。その後、ストリーム・マネージャはトリガー・マスク５２１およびトリガー・パラメータ・データセット５２２のローカル・コピーを各計算ノードに送信し（ブロック１３２０）、これらのローカル・コピーが、ローカルのトリガー・マスク３２１およびローカルのトリガー・パラメータ・データセット３２２として、それぞれ格納される。マスク・ビット／データセットのみを含んでいるローカル・コピーは、受信側計算ノードによって必要とされる。その後、実行時に検索動作を制御する状態データ構造を生成／更新するプロセスが終了する。

初期化後に、データが（タプルの形態で）処理要素に到着したときに、各処理要素でデータ・ストリーミング・アプリケーションが実行され、ローカルのトリガー・マスク３２１およびローカルのトリガー・パラメータ・データセット３２２を使用して、先行検索動作をトリガーするのに適した条件を識別する。図１４は、さまざまな実施形態に従う、データ・ストリーミング・アプリケーションの例示的な処理要素３１１の実行プロセスを示すフロー図であり、このフロー図では、処理要素は、適切な場合に、ローカルのトリガー・マスク３２１およびローカルのトリガー・パラメータ・データセットを使用して先行検索動作をトリガーしてよい。

図１４を参照すると、オペレータ・グラフをトラバースするタプルが、処理のために例示的な処理要素に到着する（ブロック１４０１）。処理要素への入力時に実行される共通実行時コード６１４内の先行検索命令６１６が、ローカルのトリガー・マスク３２１をチェックする（ブロック１４０２）。このチェックは、処理要素への入力時に実行されるように図１４に示され、本明細書において説明されているが、代替として、必ず実行される処理要素のコード内の終了または任意の位置で実行され得るということが、理解されるであろう。

対応するトリガー・ビットが設定されている場合、ブロック１４０２から「はい」の分岐が選択され、検索命令６１６がローカルのトリガー・パラメータ・データセット３２２にアクセスして、トリガー位置が現在の処理要素であるデータセットを検出する（ブロック１４０３）。そのような２つ以上のデータセット（すなわち、同じ処理要素からトリガーされた２つ以上の検索動作）が存在できる可能性がある。トリガー・パラメータ・データセットは、トリガーの１つまたは複数の条件を指定する。条件のいずれかが満たされた場合、ブロック１４０４から「はい」の分岐が選択され、検索命令６１６が、トリガー・パラメータ・データセット内の検索記述子データまたは（例えば、タプルからの）使用可能な追加データあるいはその両方を使用して、検索動作を開始する（ブロック１４０５）。この検索動作は、例えば、検索記述子によって定義されたストレージ内のアドレスを指定することによるか、検索記述子によって定義されたデータに対する要求を、検索記述子によって定義された実体に、ネットワークを経由して送信することによるか、またはその他の方法によるものであってよい。どの条件も満たされない場合、ブロック１４０４から「いいえ」の分岐が選択され、ブロック１４０５が回避される。

次に、処理要素が引き続きタプルに対して実行される。この実施形態例では、処理要素が、ブロック１４０６〜１４０８として示されているオペレータＡ、Ｂ、およびＣを呼び出す。これらのオペレータは、逐次的に、または並列に実行することができ、オペレータの数は変化してよい。すべてのオペレータの実行が完了したときに、タプルの処理が完了する。

前述のさまざまな実施形態では、実際の必要性が生じる前に、同じデータに対して同じ検索動作が複数回実行される可能性がある。図１３に関して、冗長な検索動作を引き起こすことがある冗長なトリガー・パラメータ・データセットを取り除こうとする試みが説明されたが、取り除きが、冗長な検索がなくなることを常に保証できるとは限らない。本開示の範囲を超える他のメカニズムが、冗長な検索動作の数を削減してよい。例えば、オペレーティング・システムが、進行中のストレージ・アクセス動作の記録を維持してよく、それによってオペレーティング・システムは、同じストレージ位置への冗長なアクセスを防ぐことができる。最悪の場合、ストレージ・チャネル、ネットワーク帯域幅などの少量の追加の使用を引き起こす、ある程度の冗長な検索動作が存在することがある。

代替の検索予測事象
前述のさまざまな実施形態では、検索予測事象は、オペレータ・グラフ内の指定された位置での、指定されたタイプのタプルの発生である。場合によっては、このタプルの発生のみが、検索動作をトリガーするための十分な条件になる。その他の場合、このタプルの発生に加えて、１つまたは複数のタプルの属性または外部状態変数あるいはその両方が、検索動作をトリガーするための指定された条件を満たさなければならない。

しかし、１つまたは複数の代替の実施形態では、検索動作は、オペレータ・グラフの特定の位置で、特定のタプル・タイプによってトリガーされる必要はなく、実行中に検出されることのあるその他の条件によってトリガーされる。例えば、データに対する必要性の予測は、データ・ストリーミング・アプリケーションの過去データの取得パターンに少なくとも部分的に基づいてよい。そのような過去のパターンは、（ａ）通常はデータ要素が取得される時刻／週、（ｂ）特定の事象の発生後の時間、（ｃ）特定の条件の存在、または（ｄ）他のデータの取得との相関関係のいずれか、あるいはすべてを含むことができる。これらの過去データのパターンのいずれか、またはすべてが、プロファイル・データの解析によって検出されてよく、適切なデータ構造またはトリガーのメカニズムあるいはその両方を使用して、先行する検索予測事象に応答して検索動作をトリガーすることができる。

その他の変形
上では、一連のステップが、１つまたは複数の好ましい実施形態または代替の実施形態あるいはその両方として説明されたが、検索動作に起因するデータ・ストリーミング・アプリケーションにおける遅延時間を削減するための技術の多くの変形が可能であるということが、理解されるであろう。具体的には、本明細書に記載された機能を実行するために、一部のステップが異なる順序で実行されてよく、異なるデータ構造が使用されてよく、あるいは異なるハードウェア・リソースまたはソフトウェア・リソースが採用されてよく、あるいはその組み合わせが行われてよい。さらに、特定の方式、しきい値、論理的条件などが、１つまたは複数の実施形態として開示されていることがあるが、これらの方式、しきい値、論理的条件など、およびこれらの変形が、可能性のある実施形態の一部に過ぎないということ、および他の技術が代替として使用され得るということが、理解されるであろう。

本発明は、任意の可能な統合の技術的詳細レベルで、システム、方法、またはコンピュータ・プログラム製品、あるいはその組み合わせであってよい。コンピュータ・プログラム製品は、プロセッサに本発明の態様を実行させるための（非一過性の）コンピュータ可読プログラム命令を含んでいるコンピュータ可読記憶媒体を含んでよい。

コンピュータ可読記憶媒体は、命令実行デバイスで使用するための命令を保持および格納できる有形のデバイスにすることができる。コンピュータ可読記憶媒体は、例えば、電子ストレージ・デバイス、磁気ストレージ・デバイス、光ストレージ・デバイス、電磁ストレージ・デバイス、半導体ストレージ・デバイス、またはこれらの任意の適切な組み合わせであってよいが、これらに限定されない。コンピュータ可読記憶媒体のさらに具体的な例の非網羅的リストは、ポータブル・コンピュータ・ディスケット、ハード・ディスク、ランダム・アクセス・メモリ（ＲＡＭ：random access memory）、読み取り専用メモリ（ＲＯＭ：read-only memory）、消去可能プログラマブル読み取り専用メモリ（ＥＰＲＯＭ：erasable programmable read-only memoryまたはフラッシュ・メモリ）、スタティック・ランダム・アクセス・メモリ（ＳＲＡＭ：static random access memory）、ポータブル・コンパクト・ディスク読み取り専用メモリ（ＣＤ−ＲＯＭ：compact disc read-only memory）、デジタル多用途ディスク（ＤＶＤ：digital versatile disk）、メモリ・スティック、フロッピー・ディスク、パンチカードまたは命令が記録されている溝の中の隆起構造などの機械的にエンコードされるデバイス、およびこれらの任意の適切な組み合わせを含む。コンピュータ可読記憶媒体の例が、図２に、システム・メモリ２０２およびデータ・ストレージ・デバイス２２５〜２２７として示されている。本明細書において使用されるとき、コンピュータ可読記憶媒体は、それ自体が、電波またはその他の自由に伝搬する電磁波、導波管またはその他の送信媒体を伝搬する電磁波（例えば、光ファイバ・ケーブルを通過する光パルス）、あるいはワイヤを介して送信される電気信号などの一時的信号であると解釈されるべきではない。

本明細書に記載されたコンピュータ可読プログラム命令は、コンピュータ可読記憶媒体から各コンピューティング・デバイス／処理デバイスへ、またはネットワーク（例えば、インターネット、ローカル・エリア・ネットワーク、広域ネットワーク、または無線ネットワーク、あるいはその組み合わせ）を介して外部コンピュータまたは外部ストレージ・デバイスへダウンロードされ得る。このネットワークは、銅伝送ケーブル、光伝送ファイバ、無線送信、ルータ、ファイアウォール、スイッチ、ゲートウェイ・コンピュータ、またはエッジ・サーバ、あるいはその組み合わせを備えてよい。各コンピューティング・デバイス／処理デバイス内のネットワーク・アダプタ・カードまたはネットワーク・インターフェイスは、コンピュータ可読プログラム命令をネットワークから受信し、それらのコンピュータ可読プログラム命令を各コンピューティング・デバイス／処理デバイス内のコンピュータ可読記憶媒体に格納するために転送する。

本発明と矛盾するか、またはその他の方法で本明細書において制限されない限り、本発明の動作を実行するためのコンピュータ可読プログラム命令は、アセンブラ命令、命令セット・アーキテクチャ（ＩＳＡ：instruction-set-architecture）命令、マシン命令、マシン依存命令、マイクロコード、ファームウェア命令、状態設定データ、集積回路のための構成データ、あるいは、Ｓｍａｌｌｔａｌｋ（Ｒ）、Ｃ＋＋などのオブジェクト指向プログラミング言語、および「Ｃ」プログラミング言語または同様のプログラミング言語などの手続き型プログラミング言語を含む１つまたは複数のプログラミング言語の任意の組み合わせで記述されたソース・コードまたはオブジェクト・コードであってよい。コンピュータ可読プログラム命令は、ユーザのコンピュータ上で全体的に実行すること、ユーザのコンピュータ上でスタンドアロン・ソフトウェア・パッケージとして部分的に実行すること、ユーザのコンピュータ上およびリモート・コンピュータ上でそれぞれ部分的に実行すること、あるいはリモート・コンピュータ上またはサーバ上で全体的に実行することができる。後者のシナリオでは、リモート・コンピュータは、ローカル・エリア・ネットワーク（ＬＡＮ：local area network）または広域ネットワーク（ＷＡＮ：wide area network）を含む任意の種類のネットワークを介してユーザのコンピュータに接続されてよく、または接続は、（例えば、インターネット・サービス・プロバイダを使用してインターネットを介して）外部コンピュータに対して行われてよい。一部の実施形態では、本発明の態様を実行するために、例えばプログラマブル論理回路、フィールドプログラマブル・ゲート・アレイ（ＦＰＧＡ：field-programmable gate arrays）、またはプログラマブル・ロジック・アレイ（ＰＬＡ：programmable logic arrays）を含む電子回路は、コンピュータ可読プログラム命令の状態情報を利用することによって、電子回路をカスタマイズするためのコンピュータ可読プログラム命令を実行してよい。

本発明の態様は、本明細書において、本発明の実施形態に従って、方法、装置（システム）、およびコンピュータ・プログラム製品のフローチャート図またはブロック図あるいはその両方を参照して説明される。フローチャート図またはブロック図あるいはその両方の各ブロック、ならびにフローチャート図またはブロック図あるいはその両方に含まれるブロックの組み合わせが、コンピュータ可読プログラム命令によって実装され得るということが理解されるであろう。

これらのコンピュータ可読プログラム命令は、コンピュータまたはその他のプログラム可能なデータ処理装置のプロセッサを介して実行される命令が、フローチャートまたはブロック図あるいはその両方の１つまたは複数のブロックに指定される機能／動作を実施する手段を作り出すべく、汎用コンピュータ、専用コンピュータ、または他のプログラム可能なデータ処理装置のプロセッサに提供されてマシンを作り出すものであってよい。これらのコンピュータ可読プログラム命令は、命令が格納されたコンピュータ可読記憶媒体がフローチャートまたはブロック図あるいはその両方の１つまたは複数のブロックに指定される機能／動作の態様を実施する命令を含んでいる製品を備えるように、コンピュータ可読記憶媒体に格納され、コンピュータ、プログラム可能なデータ処理装置、または他のデバイス、あるいはその組み合わせに特定の方式で機能するように指示できるものであってもよい。

コンピュータ可読プログラム命令は、コンピュータ上、その他のプログラム可能な装置上、またはその他のデバイス上で実行される命令が、フローチャートまたはブロック図あるいはその両方の１つまたは複数のブロックに指定される機能／動作を実施するように、コンピュータ実装プロセスを生成すべく、コンピュータ、その他のプログラム可能なデータ処理装置、またはその他のデバイスに読み込まれ、コンピュータ上、その他のプログラム可能な装置上、またはその他のデバイス上で一連の動作可能なステップを実行させるものであってもよい。

図内のフローチャートおよびブロック図は、本発明のさまざまな実施形態に従って、システム、方法、およびコンピュータ・プログラム製品の可能な実装のアーキテクチャ、機能、および動作を示す。これに関連して、フローチャートまたはブロック図内の各ブロックは、規定された論理機能を実装するための１つまたは複数の実行可能な命令を備える、命令のモジュール、セグメント、または部分を表してよい。一部の代替の実装では、ブロックに示された機能は、図に示された順序とは異なる順序で発生してよい。例えば、連続して示された２つのブロックは、実際には、含まれている機能に応じて、実質的に同時に実行されるか、または場合によっては逆の順序で実行されてよい。ブロック図またはフローチャート図あるいはその両方の各ブロック、ならびにブロック図またはフローチャート図あるいはその両方に含まれるブロックの組み合わせは、規定された機能または動作を実行するか、または専用ハードウェアとコンピュータ命令の組み合わせを実行する専用ハードウェアベースのシステムによって実装され得るということにも注意する。

本発明の特定の実施形態が特定の代替手段と共に開示されたが、形態および詳細における追加の変形が以下の特許請求の範囲内で行われてよいということが、当業者によって認識されるであろう。

Claims (16)

1. 検索予測プロファイリング・データ（lookup predictive profiling data）を使用して、データ・ストリーミング・アプリケーションの実行中に発生している少なくとも１つの検索予測事象を識別すること、
   ここで、前記検索予測プロファイリング・データは、現在の実行インスタンス若しくは１つ又は複数の以前の実行インスタンス又はその両方の実行中に１つ又は複数の前の時間間隔から収集されたものであり、
   各前記検索予測事象が、前記データ・ストリーミング・アプリケーションの各処理要素、すなわち各実行ファイル、によって取得されることが必要になる各データを予測し、各処理要素は同じ計算ノード上にあるか又は通信ネットワークを介してアクセスできる他の計算ノード上にあり、
   前記検索予測プロファイリング・データが、トレース・データを前記データ・ストリーミング・アプリケーションの少なくとも１つの実行インスタンスから収集し、そして該収集されたトレース・データを解析して検索予測プロファイリング・データを生成することによって取得されたデータを含み、並びに
   前記検索予測プロファイリング・データが複数の検索事象サマリー・レコードを含み、ここで、各前記検索事象サマリー・レコードが、前記データ・ストリーミング・アプリケーション内の各タプルと、先行する事象、すなわち特定のタプルの存在、が発生するオペレータ・グラフ内の各位置とに対応し、前記データ・ストリーミング・アプリケーション内の各前記位置で前記各タプルから生じる検索動作を予測する各データを含む、
   前記データ・ストリーミング・アプリケーションの現在の実行インスタンスの間に、検索予測プロファイリング・データを使用して少なくとも１つの検索予測事象を前記識別することによって、識別された検索予測事象の前記発生を検出することに応答して、前記データ・ストリーミング・アプリケーションの前記現在の実行インスタンスの間に、各前記検索予測事象が、前記データ・ストリーミング・アプリケーションの各処理要素によって取得されることが必要になると予測している、前記各データの取得を開始すること、ここで、前記各データの取得を前記開始することが、前記各処理要素が前記各データの必要性を決定する前に実行される、
   を含む、コンピュータ実行方法。
2. 各前記検索事象サマリー・レコードが、前記予測された検索動作に関連付けられた少なくとも１つの確率値を含む、請求項１に記載のコンピュータ実行方法。
3. 各前記検索事象サマリー・レコードが、対応する検索予測事象の検出後に、検索動作が遅延されてよいかどうかを判定するための、遅延時間データを含む、請求項１に記載のコンピュータ実行方法。
4. 前記検索予測事象が、前記データ・ストリーミング・アプリケーションのオペレータ・グラフ内の指定された位置で検出された、指定されたタイプのタプルを含む、請求項１に記載のコンピュータ実行方法。
5. 前記検索予測事象が、指定された範囲内の属性値をさらに含んでおり、前記属性が、前記オペレータ・グラフ内の前記指定された位置で検出された、前記指定されたタイプのタプルの属性である、請求項４に記載のコンピュータ実行方法。
6. 前記検索予測事象が、少なくとも１つの外部状態変数の値をさらに含む、請求項４に記載のコンピュータ実行方法。
7. 前記データ・ストリーミング・アプリケーションの実行中に発生する前記少なくとも１つの検索予測事象ごとに、対応する検索予測事象の検出後に、各検索動作が遅延されてよいかどうかを判定することをさらに含む、請求項１に記載のコンピュータ実行方法。
8. 前記対応する検索予測事象の検出後に、各検索動作が遅延されてよいかどうかを前記判定することが、前記データ・ストリーミング・アプリケーションの実行中に発生する複数の検索予測事象ごとに、前記対応する検索予測事象の検出後に、前記各検索動作が遅延されてよいかどうかを判定することを含み、
   前記検索予測事象の少なくとも一部が、第１の検索動作に対応し、
   前記コンピュータ実行方法が、前記対応する検索予測事象の検出後に前記各検索動作が遅延されてよいかどうかの前記判定を使用して、前記第１の検索動作の開始を引き起こすための、前記第１の検索動作に対応する前記少なくとも一部の検索予測事象のうちの少なくとも１つを選択し、前記第１の検索動作に対応する前記少なくとも一部の検索予測事象のうちの少くとも１つが前記第１の検索動作の開始を引き起こすことを無効にすることをさらに含む、
   請求項７に記載のコンピュータ実行方法。
9. 検索予測プロファイリング・データ（lookup predictive profiling data）を使用して、データ・ストリーミング・アプリケーションの実行中に発生している少なくとも１つの検索予測事象を識別すること、
   ここで、前記検索予測事象が、前記データ・ストリーミング・アプリケーションのオペレータ・グラフ内の指定された位置で検出された、指定されたタイプのタプルを含む、
   前記検索予測プロファイリング・データは、現在の実行インスタンス若しくは１つ又は複数の以前の実行インスタンス又はその両方の実行中に１つ又は複数の前の時間間隔から収集されたものであり、並びに、
   各前記検索予測事象が、前記データ・ストリーミング・アプリケーションの各処理要素、すなわち各実行ファイル、によって取得されることが必要になる各データを予測し、各処理要素は同じ計算ノード上にあるか又は通信ネットワークを介してアクセスできる他の計算ノード上にある、
   前記データ・ストリーミング・アプリケーションの現在の実行インスタンスの間に、検索予測プロファイリング・データを使用して少なくとも１つの検索予測事象を前記識別することによって、識別された検索予測事象の前記発生を検出することに応答して、前記データ・ストリーミング・アプリケーションの前記現在の実行インスタンスの間に、各前記検索予測事象が、前記データ・ストリーミング・アプリケーションの各処理要素によって取得されることが必要になると予測している、前記各データの取得を開始すること、ここで、前記各データの取得を前記開始することが、前記各処理要素が前記各データの必要性を決定する前に実行される、
   を含む、コンピュータ実行方法。
10. 前記検索予測事象が、指定された範囲内の属性値をさらに含んでおり、前記属性が、前記オペレータ・グラフ内の前記指定された位置で検出された、前記指定されたタイプのタプルの属性である、請求項９に記載のコンピュータ実行方法。
11. 前記検索予測事象が、少なくとも１つの外部状態変数の値をさらに含んでいる、請求項９に記載のコンピュータ実行方法。
12. 複数のコンピュータ実行可能命令を含むコンピュータ・プログラムが記録されたコンピュータ可読媒体であって、前記コンピュータ・プログラムが、少なくとも１つのコンピュータ・システムによって実行されたときに、前記少なくとも１つのコンピュータ・システムに、請求項１〜１１のいずれか１項に記載のコンピュータ実行方法を実行させる、前記コンピュータ可読媒体。
13. データ・ストリーミング・アプリケーションの実行をサポートするデータ処理装置であって、
    少なくとも１つの物理プロセッサと、
    少なくとも１つの物理メモリと、
    前記少なくとも１つのプロセッサ上で実行可能な、前記少なくとも１つのメモリに格納できる命令として具現化されたデータ・ストリーミング・アプリケーションであって、複数の処理要素、すなわち各実行ファイル、のうちの処理要素間で転送されているデータ・タプルに対して動作する前記複数の処理要素を含むオペレータ・グラフを実装する、前記データ・ストリーミング・アプリケーションと、
    前記少なくとも１つのプロセッサ上で実行可能な、前記少なくとも１つのメモリに格納できる命令として具現化された先行検索機能であって、前記先行検索機能が、各先行する処理要素内の各タプルの処理中に発生する少なくとも１つの検索予測事象を検出すること、ここで、各処理要素は同じ計算ノード上にあるか又は通信ネットワークを介してアクセスできる他の計算ノード上にあり、各前記検索予測事象が、前記先行する処理要素が前記各タプルを処理した後に、前記各タプルを処理している前記データ・ストリーミング・アプリケーションの各その後の処理要素によって取得されることが必要になる各データを予測する、前記検出することと、前記検出に応答して、前記各検索予測事象が、前記各タプルが前記各その後の処理要素によって処理される前に前記データ・ストリーミング・アプリケーションの前記各その後の処理要素によって取得されることが必要になると予測している、前記各データの取得を開始することとを実行する、前記先行検索機能と、
    前記少なくとも１つのプロセッサ上で実行可能な、前記少なくとも１つのメモリに格納できる命令として具現化されたプロファイル・データ解析機能と
    を備えており、
    ここで、前記プロファイル・データ解析機能が、前記データ・ストリーミング・アプリケーションの少なくとも１つの実行インスタンスから収集されたトレース・データを解析して、検索予測プロファイリング・データを生成し、前記先行検索機能が、前記検索予測プロファイリング・データを使用して前記少なくとも１つの検索予測事象を識別し、ここで、前記検索予測プロファイリング・データは、現在の実行インスタンス若しくは１つ又は複数の以前の実行インスタンス又はその両方の実行中に１つ又は複数の前の時間間隔から収集されたものである、
    前記検索予測プロファイリング・データが複数の検索事象サマリー・レコードを含み、各前記検索事象サマリー・レコードが、前記データ・ストリーミング・アプリケーション内の各タプルと、先行する事象、すなわち特定のタプルの存在、が発生するオペレータ・グラフ内の各位置とに対応し、前記データ・ストリーミング・アプリケーション内の各前記位置で前記各タプルから生じる検索動作を予測する各データを含む、
    前記データ処理装置。
14. データ・ストリーミング・アプリケーションの実行をサポートするデータ処理装置であって、
    少なくとも１つの物理プロセッサと、
    少なくとも１つの物理メモリと、
    前記少なくとも１つのプロセッサ上で実行可能な、前記少なくとも１つのメモリに格納できる命令として具現化されたデータ・ストリーミング・アプリケーションであって、複数の処理要素、すなわち各実行ファイル、のうちの処理要素間で転送されているデータ・タプルに対して動作する前記複数の処理要素を含むオペレータ・グラフを実装する、前記データ・ストリーミング・アプリケーションと、
    前記少なくとも１つのプロセッサ上で実行可能な、前記少なくとも１つのメモリに格納できる命令として具現化された先行検索機能であって、前記先行検索機能が、各先行する処理要素内の各タプルの処理中に発生する少なくとも１つの検索予測事象を検出すること、ここで、各処理要素は同じ計算ノード上にあるか又は通信ネットワークを介してアクセスできる他の計算ノード上にあり、前記検索予測事象が、前記データ・ストリーミング・アプリケーションのオペレータ・グラフ内の指定された位置で検出された、指定されたタイプのタプルを含み、各前記検索予測事象が、前記先行する処理要素が前記各タプルを処理した後に、前記各タプルを処理している前記データ・ストリーミング・アプリケーションの各その後の処理要素によって取得されることが必要になる各データを予測する、及び、前記検出に応答して、前記各検索予測事象が、前記各タプルが前記各その後の処理要素によって処理される前に前記データ・ストリーミング・アプリケーションの前記各その後の処理要素によって取得されることが必要になると予測している、前記各データの取得を開始することとを実行する、前記先行検索機能と
    を備えている、
    データ処理装置。
15. 各少なくとも１つの物理プロセッサおよび各物理メモリをそれぞれ備えている複数のコンピュータ・システムと、
    前記複数のコンピュータ・システム間のデータの通信をサポートする少なくとも１つのネットワークと
    を備えており、
    前記複数のコンピュータ・システムの各コンピュータ・システムが、前記データ・ストリーミング・アプリケーションの少なくとも１つの各ノードを具現化する、請求項１３又は１４に記載のデータ処理装置。
16. 前記複数のコンピュータ・システムが、ストリーム・マネージャの実行をサポートする管理システムを含んでおり、
    前記ストリーム・マネージャが、前記先行検索機能で使用するための検索予測事象を識別するデータを生成する、請求項１３又は１４に記載のデータ処理装置。

Images