JP2020140717A - イベント処理のための動的に型付けされたビッグデータによるイベントの充実化 - Google Patents

Abstract

【課題】イベント処理のための動的に型付けされたビッグデータによるイベントを処理する方法、コンピュータ読取可能媒体及びシステムを提供する。【解決手段】連続イベントプロセッサは、イベントの連続的なストリームを受信し、各イベントを、そのイベントにＣＥＰクエリを適用することによって処理する。ＣＱＬプロセッサを使用してデータストアに含まれる文脈データでソースイベントを充実化する方法は、イベント処理ネットワークにおいてデータストアを表わすために、ＣＱＬイベント属性からデータストアにおけるデータに関連付けられた情報へのマッピングを特定するためのマッピングコンポーネントを有するイベント処理ネットワークテーブルコンポーネントを作成する。テーブルコンポーネントは、データストアからのイベントに対応するデータの選択、及びデータによるイベントの充実化を含む動作を行なうように、外部関係ソースとして使用される。【選択図】なし

Description

関連出願との相互参照
本願は、２０１５年６月３０日に出願された米国特許出願第１４／７５５，０８８号（代理人整理番号８８３２５−９３７６２７（１５３５００））の優先権および利益を主張し、当該出願は、２０１４年９月２４日に出願された米国仮出願第６２／０５４，７３２号（代理人整理番号８８３２５−９０８３８１（１５３５０１ＵＳ））の優先権利益を主張する。各々の開示全体は、あらゆる目的のためにここに引用により全面的に援用される。

背景
データベースは伝統的に、データの格納と格納されたデータに対する問合せ能力とを必要とするアプリケーションで使用されてきた。既存のデータベースはこのため、格納された有限のデータセットに対してクエリを実行するように最良に備えられている。しかしながら、伝統的なデータベースモデルは、制限されたデータセットとしてではなくデータイベントのストリームとしてデータが受信される、ますます増加する現代のアプリケーションには、あまり適していない。イベントストリームとも呼ばれるデータストリームは、リアルタイムの、場合によっては連続的な、一連のイベントによって特徴付けられる。データまたはイベントストリームはこのため、制限のないデータのセットを表わす。データストリームを生成するソースの例としては、一連のセンサ測定値を送信するように構成されたセンサおよびプローブ（たとえば、無線周波数識別子（radio frequency identifier：ＲＦＩＤ）センサ、温度センサ等など）、金融ティッカー、ネットワークステータス更新を送信するネットワーク監視およびトラフィック管理アプリケーション、クリックストリーム分析ツールなどが含まれる。

連続イベント処理（Continuous event processing：ＣＥＰ）は、イベントストリーム
におけるデータを処理するために有用な技術である。ＣＥＰは高度にステートフルである。ＣＥＰは、イベントを連続的に受信し、それらのイベント中に何らかのパターンを見つけることを伴う。したがって、ＣＥＰにはかなりの量の状態維持が関与している。ＣＥＰはこのように多くの状態の維持を伴うため、ＣＥＰクエリをイベントストリーム内のデータに適用するプロセスは、常にシングルスレッド化されてきた。コンピュータプログラミングでは、シングルスレッディングとは、一度に１つのコマンドの処理である。

ＣＥＰクエリ処理は一般に、イベントストリーム内で特定されたイベントに対するクエリの連続的な実行を伴う。たとえば、ＣＥＰクエリ処理は、直近の１時間の平均株価を連続的に観察するために使用されるかもしれない。そのような状況下では、ＣＥＰクエリ処理は、さまざまな時点での現在株価を各々示したイベントを含んだイベントストリームに対して行なわれ得る。クエリは、最近の１時間の株価を集約し、次にそれらの株価の平均を計算することができる。クエリは、計算された各平均を出力できる。価格の１時間の長さのウィンドウが動くにつれて、クエリを連続的に実行することができ、クエリは、さまざまな異なる平均株価を出力できる。

連続イベントプロセッサは、イベントの連続的なストリームを受信し、そこに含まれる各イベントを、そのイベントにＣＥＰクエリを適用することによって処理することができる。そのようなＣＥＰクエリは、構造化クエリ言語（structured query language：ＳＱ
Ｌ）を拡張したものである連続クエリ言語（continuous query language：ＣＱＬ）など
のＣＥＰクエリ言語の構文に適合するようにフォーマットされてもよい。ＳＱＬクエリは、リレーショナルデータベースのテーブルにすでに格納されたデータに（ユーザ要求ごとに）１回適用されることが多く、一方、ＣＱＬクエリは、入来イベントストリームにおけるイベントが連続イベントプロセッサによって受信される際に、それらのイベントに繰り返し適用される。このため、ＣＥＰが効果的に行なわれることを可能にするシステムへの要望が明らかに存在する。

簡単な概要
ここに記載される実施形態は、データベースおよび連続イベント処理に関する。いくつかの実施形態によれば、ＣＱＬクエリの処理は、異なる処理ノード間にわたって分散され得る。イベント処理メカニズムが、複数の別個の仮想マシン間にわたって分散され得る。記載される実施形態は、リアルタイムの連続データクエリのためのＣＥＰを効果的に可能にするシステムを提供する。

いくつかの実施形態によれば、ＨＢａｓｅデータベースストアが、連続クエリ言語プロセッサ（ＣＱＬプロセッサ）のためのデータソースとして使用される。この使用は、ＲＤＢＭＳテーブルに存在するデータによるイベントの充実化方法と同様に、このストアに存在するデータによってイベントが充実化されることを可能にする。いくつかの実施形態によれば、ＨＢａｓｅデータベースストアは、テーブルシンク機能と同様のデータシンクとして使用される。

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

いくつかの実施形態に従った、ＨＢａｓｅデータストアにおけるテーブルの一例を示す図である。 いくつかの実施形態に従った、単純なイベント処理ネットワークの一例を示すブロック図である。 いくつかの実施形態に従った、ブロードキャストイベント処理ネットワークの一例を示すブロック図である。 いくつかの実施形態に従った、ロードバランシングイベント処理ネットワークの一例を示すブロック図である。 いくつかの実施形態に従った、ロードバランシングイベント処理ネットワークの次の状態の一例を示すブロック図である。 いくつかの実施形態に従った、１つのチャネルが２つのコンシューマを有するブロードキャストイベント処理ネットワークの一例を示すブロック図である。 この発明の一実施形態に従った、複数のリソースサーバからサービスを要求するために使用可能な単一トークンを生成するための手法の一例を示すフロー図である。 いくつかの実施形態に従った、パーティショニングされたイベント処理ネットワークの一例を示すブロック図である。 いくつかの実施形態に従った、パーティショニングされたイベント処理ネットワークの別の例を示すブロック図である。 いくつかの実施形態に従った、ファン・イン（fan-in）イベント処理ネットワークの一例を示すブロック図である。 いくつかの実施形態に従った、線グラフの一例を示す図である。 いくつかの実施形態に従った、散布図の一例を示す図である。 いくつかの実施形態に従った、平滑化された曲線適合線が引かれた散布図の一例を示す図である。 いくつかの実施形態に従った、点のサイズが異なっている散布図の一例を示す図である。 いくつかの実施形態に従った、レーダー図の一例を示す図である。 実施形態のうちの１つを実現するための分散型システムの簡略図である。 この開示の一実施形態に従った、実施形態システムのコンポーネントによって提供されるサービスをクラウドサービスとして提供し得るシステム環境のコンポーネントの簡略ブロック図である。 この発明のさまざまな実施形態が実現され得るコンピュータシステムの一例を示す図である。 いくつかの実施形態に従った、散布図上に重ね合わされたクラスタ表現形状の一例を示す図である。

詳細な説明
以下の記載では、説明の目的のため、特定の詳細が、この発明の実施形態の完全な理解を提供するために述べられる。しかしながら、これらの特定の詳細がなくてもこの発明は実践され得るということは、明らかであろう。

イベント処理アプリケーションのための処理は分散され得る。オラクル・イベント・プロセッシング（Oracle Event Processing）製品は、イベントプロセッサ（連続クエリ言
語プロセッサ）の一例である。いくつかの実施形態によれば、ＣＱＬクエリの処理は、異なる処理ノード間にわたって分散され得る。そのような処理ノードは各々、たとえば、別個のマシンまたはコンピューティング装置であってもよい。ＣＱＬクエリの処理を異なる処理ノード間にわたって分散させる場合、イベントを順序付けるセマンティクス（semantics）が、何らかの態様で定義される。

イベントを順序付けるためのある初歩的なアプローチは、イベントストリームにおけるイベント間で先入先出（first in, first out：ＦＩＦＯ）順序付けを維持しようとする
ものである。しかしながら、イベントストリーミングシステムの中には、複数のイベントパブリッシャと複数のイベントコンシューマとを伴い得るものもある。システムにおける各マシンは、それ自体のクロックを有し得る。そのような状況下では、任意の単一のマシンによって生成されたイベントタイムスタンプは、システム全体にわたって決定的ではないかもしれない。

複数のイベントコンシューマを伴うシステム内では、各コンシューマは、別個の一組の要件を有するかもしれない。各コンシューマは、ＣＱＬクエリを連続的に実行するイベントプロセッサであり得る。そのようなＣＱＬクエリは各々、イベント順序付けに関して別個の要件を有し得る。

いくつかの実施形態によれば、分散フローが定義される。各分散フローは、イベントプロデューサとイベントコンシューマとの間でイベントを分散させる特定の方法である。ある種類の分散フローは、一組のイベントコンシューマ間でイベントをロードバランス化することができる。たとえば、イベントプロデューサが第１のイベントを生成すると、ロードバランシング分散フローは、その第１のイベントが第１のイベントコンシューマにルーティングされるようにすることができる。次に、イベントプロデューサが第２のイベントを生成すると、ロードバランシング分散フローは、その第２のイベントが第２のイベントコンシューマにルーティングされるようにすることができる。

他の種類の分散フローは、パーティション分散フロー、ファン・イン分散フロー、ブロ
ードキャストフローなどを含む。使用されている分散フローのタイプに依存して、および、イベントを受信しているイベントコンシューマの要件にも依存して、異なるイベント順序付け手法が、イベントコンシューマが受信するイベントを順序付けるために使用されてもよい。

マップ−リデュース概要
ここで、多数のコンピューティングマシン（ノード）を使用して莫大なデータセットに関する並列化可能な問題を処理するためのフレームワークである、マップ−リデュース（Map-Reduce）について言及する。ノードは、すべてのノードが同じローカルネットワーク上にあり、同様のハードウェアを使用する場合、クラスタと総称される。これに代えて、ノードは、ノードが地理的にかつ管理的に分散されたシステム間にわたって共有され、より異機種のハードウェアを使用する場合、グリッドと総称される。ファイルシステムで見つかり得るような非構造化データ、またはデータベースで見つかり得るような構造化データに対して、演算処理を行なうことができる。マップ−リデュースはデータの局所性を利用することができ、データが送信される距離を減少させるためにストレージ資産上またはその近くでデータを処理する。

「マップ」ステップでは、マスターノードがタスクを入力として受信し、入力をより小さい部分問題（sub-problem）に分割し、部分問題をワーカーノードに分散させる。所与
のワーカーノードがこの分割および分散を繰り返すことができ、マルチレベルのツリー構造をもたらす。各ワーカーノードは、それに割当てられた部分問題を処理し、処理の結果をそのマスターノードに戻す。

「リデュース」ステップでは、マスターノードは、すべての部分問題の処理の結果を収集する。マスターノードは、何らかの方法で結果を組合せて最終出力を形成する。最終出力は、マスターノードが行なうために元々与えられたタスクの成果である。

マップ−リデュースは、マッピングオペレーションおよびリデュースオペレーションの分散処理を可能にする。各マッピングオペレーションが他のマッピングオペレーションから独立しているならば、すべてのマッピングオペレーションは並列で行なわれ得る。同様に、同じキーを共有するマッピングオペレーションのすべての出力が同じリデューサに同時に提示される場合、または、リデュース関数が結合的である場合、一組のリデューシングノードがリデュースフェイズを行なうことができる。最終結果を生成するために必要な総時間を減少させることに加えて、並列処理は、動作中のサーバまたはストレージの部分故障から回復する何らかの可能性も提供する。１つのマッピングノードまたはリデューシングノードが故障した場合、入力データが依然として利用可能であれば、作業のスケジュールを変更することができる。

マップ−リデュースは、５ステップの並列で分散された演算として概念化され得る。第１のステップでは、マップ入力が準備される。マップ−リデュースシステムは、マッププロセッサを指定し、各マッププロセッサが作業できる第１の入力キー値を割当て、その第１の入力キー値に関連付けられた入力データのすべてを各マッププロセッサに提供する。

第２のステップでは、マッピングノードが、ユーザから提供されたマップコードを実行する。マッピングノードは、第１のキー値の各々ごとに１回、マップコードを実行する。マップコードの実行は、第２のキー値によって編成された出力を生成する。

第３のステップでは、第２のステップからの出力がリデューシングノードにシャッフルされる。マップ−リデュースシステムは、リデューシングプロセッサを指定する。マップ−リデュースシステムは、各リデューシングプロセッサに、そのプロセッサが作業すべき
第２のキー値を割当てる。マップ−リデュースシステムは、各リデューシングプロセッサに、そのリデューシングプロセッサの割当てられた第２のキー値にも関連付けられた、第２のステップ中に生成されたデータのすべてを提供する。

第４のステップで、リデューシングノードは、ユーザから提供されたリデュースコードを実行する。リデューシングノードは、第２のステップ中に生成された第２のキー値の各々ごとに１回、リデューシングコードを実行する。

第５のステップで、最終出力が生成される。マップ−リデュースシステムは、第４のステップによって生成された出力データをすべて収集し、そのデータをそれらの第２のキー値によってソートして、最終出力を生成する。

上述のステップは順に実行されると想像され得るが、実際には、ステップは、最終出力がインターリーブによって影響されない限り、インターリーブされ得る。

分散から恩恵を受けるイベント処理シナリオ
現代では分析されるべきデータの量が非常に増大したため、スケーラブルなイベント処理メカニズムが非常に有用である。この文脈でのスケーラビリティは、イベント処理の実行に関与するスレッドを処理する量だけでなく、イベントを並列で処理できるコンピューティングマシンの量の増加も意味し得る。ここに開示されるのは、ＪＡＶＡ（登録商標）仮想マシン（JAVA virtual machine：ＪＶＭ）といった複数の仮想マシン間にわたってイベント処理アプリケーションを分散させるための手法である。

多くの異なるイベント処理シナリオが、分散実行によく向いている。これらのシナリオは、ある特性を有する傾向がある。第１に、これらのシナリオは、待ち時間に非常に束縛されるものではなく、たとえばマイクロ秒範囲の待ち時間を伴ってもよい。第２に、これらのシナリオは、顧客または領域などによって論理的にパーティショニング（partition
）されることができる。第３に、これらのシナリオは、全体の順序付け制約がないように、並列で実行され得る別々の個々のコンポーネントまたはタスクに論理的に分割されることができる。

分散される態様で有用に実行され得るイベント処理シナリオの一例は、単語カウントシナリオである。このシナリオでは、システムは、入来した文を意味のある用語にマッピングし、次に、これらの用語を（用語ごとに）カウントにリデュースする。単語カウントシナリオにおいて行なわれる作業は、マップ−リデュースバッチ処理を使用して行なわれ得るが、ストリーム処理を使用しても行なわれ得る。これは、ストリーム処理を使用して、ツイッター（登録商標）または別のソーシャルメディアフィードから来るものなどの単語のリアルタイムフローがカウントされ得るためである。ソーシャルメディアフィードに対してストリーム処理を使用することは、他の処理アプローチを使用して可能であり得るものよりも迅速な反応を可能にする。

ストリーム処理が、ソーシャルメディアフィードを扱うために、たとえばそれらのフィードにおける単語をカウントするために使用される場合、ストリーム処理メカニズムは、入来する非常に大量の単語にさらされるかもしれない。大量の情報を扱うために、情報の処理を分散させることができる。別々のコンピューティングマシンが、ツイッターストリームなどの異なるソーシャルメディアストリームをサブスクライブする（subscribe）こ
とができる。これらのマシンは、ストリーム内の単語をカウントしてストリームを並列に処理し、次に、結果として生じるカウントを結合して、完全な結果を生成することができる。

分散される態様で有用に実行され得るイベント処理シナリオの別の例は、行列乗算シナリオである。インターネットサーチエンジンによって使用されるページランキングアルゴリズムが、ウェブページの重要性を単一の数字として要約することができる。そのようなアルゴリズムは、一連のカスケード状の大きい行列乗算オペレーションとして実現され得る。

行列乗算は高度に並列化され得るため、マップ−リデュースは、行列乗算に関するオペレーションを行なうのに有益となり得る。行列乗算オペレーションは、自然結合として概念化可能であり、グループ化および集約が後に続く。

分散される態様で有用に実行され得るイベント処理シナリオの別の例は、用語頻度−逆文書頻度（term frequency-inverted document frequency：ＴＦ−ＩＤＦ）シナリオである。ＴＦ−ＩＤＦは、用語の重要性を判断するためにサーチエンジンによってしばしば採用されるアルゴリズムである。用語は、それが他の文書で頻繁に見られる場合、期待に反してそれほど重要ではなく、よって、アルゴリズムの「逆文書頻度」局面である。

上述の単語カウントシナリオと同様に、ストリーム処理を使用してＴＦ−ＩＤＦ処理をリアルタイムで行なうことができる値がある。単語カウントシナリオとは異なり、ＴＦ−ＩＤＦ値の計算は、「逆文書頻度」計算のために履歴文書にアクセスすることを伴う。履歴文書の関与は、ＴＦ−ＩＤＦシナリオを、Ｈａｄｏｏｐ、および／またはＨＢａｓｅのような何らかの索引付け層で使用するためにふさわしい候補にする。ＨａｄｏｏｐおよびＨＢａｓｅ、ならびにイベントストリーム処理におけるそれらの使用も、ここに説明される。

分散される態様で有用に実行され得るイベント処理シナリオの別の例は、スマートメータエネルギー消費シナリオである。今日の家庭にとって、それらの敷地に位置するスマートメータの使用を通してそれらのエネルギー消費を収集することは、一般的である。典型的には、これらのスマートメータは、イベントの形をしたエネルギー消費センサデータを一日中周期的に（たとえば、毎分）出力する。このセンサデータは、地域の処理センターにおける下流管理システムによって取り込まれる。センターは、取り込んだデータを使用して、家または近所の平均エネルギー消費といった有用な記述的統計を計算する。これらの統計は、平均エネルギー消費が地域の履歴データにどのように関係するかを明らかにすることができる。これらの実行される集約は、パーティショニングされるのによく適している。したがって、このシナリオには、分散型パーティションフローが有益に適用可能である。

そのような情報に対してイベント処理を行なって、エネルギー消費の典型的な範囲よりも上または下にある家庭、といった外れ値を識別することができる。そのような情報に対してイベント処理を行なって、今後の消費を予測しようとすることができる。識別された外れ値および予測された今後の消費は、エネルギープロバイダにより、差別化された価格設定のために、販売促進のために、および、それらのパートナーとのエネルギーの売買プロセスをより効果的に制御するために、使用され得る。

上に具体的に列挙されていないさまざまな他のシナリオが、分散された態様での処理のために適合され得る。たとえば、デリバティブの価格が変わるにつれて金融ポートフォリオの公開のリアルタイム計算を伴うリスク分析が、分散型イベントストリーム処理を使用して行なわれてもよい。

フローを作成するためにイベントストリームを分散させる方法
並列イベント処理を容易にするために複数のイベント処理ノード間にわたってイベント
ストリーム（たとえば、ある特定のデータソースから生じるストリーム）を分散させるためのいくつかの異なる手法を、ここに開示する。各手法は、異なる種類のフローを作成する。これらの手法のうちのいくつかを、以下に要約する。

パーティションフローは、ストリームにおけるイベントの１つ以上の特性をパーティショニング基準として使用して、処理スレッドまたは仮想マシン（たとえばＪＶＭ）といったいくつかの別々のコンピューティングリソース間にわたってイベントストリームをパーティショニングすることを伴う。パーティションフローのクラスタ化バージョンが、ここに開示される。また、単一ノード構成であるイベント処理ネットワークのスレッド間にわたってストリームされたイベントをパーティショニングすることも、ここに開示される。

ファン・イン・フローは、以前に分散された複数のイベントフローを集めて、単一のコンピューティングリソースに戻すことを伴う。ファン・イン・フローは、たとえば、グローバルな集約が関わる状況下といった、何らかの状態が同一場所に設置されるべき場合に使用されてもよい。

ロードバランスフローは、全体的な負荷が一組の消費リスナにわたってバランスのとれた態様で共有されるように、ストリームのイベントをこの一組に分散させることを伴う。処理のための新しいイベントを受信するために、現在作業負荷がより多いイベント処理ノードよりも、現在作業負荷がより少ないイベント処理ノードが選択され得る。これは、あるイベント処理ノードが過負荷をかけられ、一方、他のイベント処理ノードが十分に利用されないままとなることを防止する。

ブロードキャストフローは、ストリームのすべてのイベントをすべての消費リスナにブロードキャストすることを伴う。この場合、イベント処理ノードといったすべてのリスナは、すべてのイベントのコピーを受信する。

クラスタ化ドメイン生成
上述のさまざまな種類のフローに対応する分散型イベント処理ネットワークをサポートするために、いくつかの実施形態は、クラスタ化ドメインの生成を伴う。いくつかの実施形態では、構成ウィザードまたは他のツールが、分散されたフローのサポートするために構成されたドメインの生成を通して、ユーザを誘導する。

リソース拡張性（elasticity）
クラウドコンピューティング環境では、コンピューティングリソースは、需要が増加または減少するにつれて、動的に増大または縮小し得る。いくつかの実施形態によれば、クラウドコンピューティング環境にデプロイメントされた分散型イベント処理システムは、既存のインフラストラクチャにプラグ接続可能である。このシステムは、分散されたフローを現在実行するコンピューティングリソースの量を動的に増大および縮小させることができる。たとえば、負荷がますます大きくなる場合、ロードバランスフローは、負荷をさらに共有するように、新しいコンピューティングリソースを自動的に生成する。

イベント処理ネットワークとして定義される分散されたフロー
フローに対応するイベント処理ネットワークは、有向非巡回グラフとして表わされ得る。このグラフは、形式上、pair（Ｎ，Ｃ）として定義可能であり、ここで、Ｎは一組のノード（頂点）、Ｃは、ソースノードから宛先ノードへのコネクション（弧）を表わす、Ｎに対する二項関係である。

たとえば、イベント処理ネットワークは、イベント処理ネットワーク１＝（｛アダプタ１，チャネル１，プロセッサ，チャネル２，アダプタ２｝，｛（アダプタ１，チャネル１
），（チャネル１，プロセッサ），（プロセッサ，チャネル２），（チャネル２，アダプタ２）｝）として定義可能である。イベントは、プロパティ名およびプロパティ値を表わす任意のpair（ＰＮ，ＰＶ）の関係Ｐとして定義される。

別の例について、株式ティッカーを表わすイベントストリームを仮定すると、ｅ１＝｛（価格，１０），（量，２００），（記号，‘ＯＲＣＬ’）｝；ｅ２＝｛（ｐ１，ｖ１），（ｐ２，ｖ２），（ｐ３，ｖ３）｝という定義が使用できる。イベント処理ネットワークノードは２つ以上のイベントを含み得るため、（他のいくつかの場合とは異なり）、集合Ｅが、順序付けられた一連のイベントとして定義可能である。

別の例について、｛プロセッサ｝＝｛ｅ１，ｅ２｝という定義が使用できる。イベント処理ネットワークのランタイム状態Ｓ＝（Ｎ，Ｅ）は、ＮからＥへの二項関係として提示され得る。関係Ｓは単射ではない。つまり、同じイベントが２つ以上のノードに存在してもよい。しかしながら、関係Ｓは全射である。なぜなら、イベント処理ネットワークにおけるイベントの全体集合のうちのすべてのイベントが、少なくとも１つのノードにあるためである。

別の例について、state＝｛（プロセッサ，｛ｅ１，ｅ２｝），（アダプタ２，｛ｅ３
｝）｝という定義が使用できる。これは、イベントフローの論理モデルを提供する。このモデルは、物理コンポーネントで増大され得る。この増大は、イベント処理ネットワークのノードをホストするコンピューティングリソースＲを割当てることによって達成され得る。新しいモデルは次に、三項関係Ｓ＝（Ｎ，Ｒ，Ｅ）になる。ここで、Ｒは、クラスタのすべてのコンピューティングリソースの集合である。

別の例について、state＝｛（プロセッサ，マシン１，｛ｅ１，ｅ２｝），（アダプタ
２，マシン１，｛ｅ３｝）｝という定義が使用できる。

分散されたフローはしたがって、関数として定義可能である。これらの関数は、入力として、イベント処理ネットワークの静的構造、ランタイムの現在の状態、および、対象としての特定のコンピューティングリソースの特定のノードを取ることができる。関数は、イベントのフローを考慮するランタイム状態の新しい構成を対象からそのコネクションに返すことができる。形式上、これは、次のように定義可能である：

いくつかの関数は、ファン・イン、ロードバランス、パーティションおよびブロードキャストフロー用のパターンをサポートするために定義され、後者の２つは、単一の仮想マシンの場合用に１つ、クラスタ化された仮想マシンの場合用に別の１つ、という２つのバージョンを有する。分散フロー関数は、次の通りである：

これは、以下のように読める。すべてのソースｎについて、ＣおよびＳ双方で提示する（すなわち、コネクションを有し、イベントを有する）。次に、Ｃでの各宛先ｄについて、新しいタプル状態（ｄ，ｒ，ｅ）を生成する。現在の状態Ｓマイナス古いタプル（ｎ，
ｒ，ｅ）プラス新しいタプル（ｄ，ｒ，ｅ）を戻す。最後のステップにおける除去および追加は、ソースノードから宛先ノードへのイベントの移動を表わす。

この場合、新しい状態Ｓ’は、宛先ｄおよびリソースｔのすべての有効な順列のためのタプルからなる。すなわち、すべてのコンピューティングリソースは、構成された各宛先のためのイベントを受信するであろう。

この定義ではスレッディングはモデル化されていないため、ローカルパーティションとローカルブロードキャストとの間に違いはない。しかしながら、実際には、これはあてはまらない。なぜなら、スレッディングはパーティションごとに特徴付けられる（colored
）ためである。

これら最後の３つは構造が同様であり、以下の説明からわかるように、それらのスケジューリング関数に関してのみ異なっている。実際、ファン・インは、単一のキーを有するパーティションの特殊なケースと見なすことができる。

スケジューリング関数
いくつかの実施形態によれば、スケジューリング関数lb-sched、p-sched、およびfi-schedが定義される。これらの関数の実装は、分散の構造を変えない。これらの関数は、リ
ソースのスケジューリングを判断する。これらの関数のデフォルト実装は、以下の通りである：

lb-schedは、従来のラウンドロビンアルゴリズムを利用する。この場合、何らかのクラスタ化状態を維持することができる。

いくつかの実施形態によれば、min-jobsスケジューリングが使用され、min-jobsは、これまで実行されるようスケジューリングされた最小数のジョブを有するリソースを選択する。

いくつかの実施形態によれば、ターゲットサーバがランダムに選択される。大数の法則を考慮すると、この実施形態は、集中型の状態が必要ではないという点を除き、ラウンドロビンと同様である：

いくつかの実施形態では、イベントのこの集合を処理するために必要とされるリソースを有する単一のサーバへの結合が行なわれる。たとえば、イベントがイベントデータネットワーク／ＪＡＶＡメッセージングサービスに出力されるべき場合、そのようなサーバは、イベントデータネットワーク／ＪＡＶＡメッセージングサービスサーバおよび宛先構成についての情報を維持することができる。

いくつかの実施形態では、ファン・イン・ターゲットの仕様は、デフォルトで、構成されるべきメンバーの第１のサーバを示すであろう最も低いメンバーＩＤを有するクラスタメンバーとなるように選択される。

例示的なイベント処理ネットワーク
図２は、いくつかの実施形態に従った、単純なイベント処理ネットワーク２００の一例を示すブロック図である。図２では、イベント処理ネットワーク２００は、ローカルブロードキャスト（チャネル１，マシン１，イベント処理ネットワーク１，｛（チャネル１，マシン１，｛ｅ１｝）｝）＝｛（プロセッサ，マシン１，｛ｅ１｝）｝という構文を使用して定義可能である。

以下に説明されるのは、Ｒ＝｛マシン１，マシン２，マシン３｝である、何らかのクラスタ化された場合である。図３は、いくつかの実施形態に従った、ブロードキャストイベント処理ネットワーク３００の一例を示すブロック図である。図３では、イベント処理ネットワーク３００は、クラスタ化ブロードキャスト（チャネル１，マシン１，イベント処理ネットワーク１，｛（チャネル１，マシン１，｛ｅ１｝）｝）＝｛（プロセッサ，マシン１，｛ｅ１｝），（プロセッサ，マシン２，｛ｅ１｝），（プロセッサ，マシン３，｛ｅ１｝）｝という構文を使用して定義可能である。この場合、同じイベントｅ１が、コンピューティングリソースであるマシン１、マシン２、およびマシン３のすべてに分散される。

図４は、いくつかの実施形態に従った、ロードバランシングイベント処理ネットワーク４００の一例を示すブロック図である。図４では、イベント処理ネットワーク４００は、ロードバランス（チャネル１，マシン１，イベント処理ネットワーク１，｛（チャネル１，マシン１，｛ｅ１｝）｝）＝｛（プロセッサ，マシン２，｛ｅ１｝）｝という構文を使用して定義可能である。ロードバランシングの場合、｛ｅ１｝でジョブを実行すると、マシン２の状態が変更される。

図５は、いくつかの実施形態に従った、ロードバランシングイベント処理ネットワーク５００の次の状態の一例を示すブロック図である。図５は、マシン２へのｅ１の送信に続
く図４のロードバランシングイベント処理ネットワークの状態を示す。図５では、イベント処理ネットワーク５００は、ロードバランス（チャネル１，マシン１，イベント処理ネットワーク１，｛（チャネル１，マシン１，｛ｅ２，ｅ３｝）｝）＝｛（プロセッサ，マシン３，｛ｅ２，ｅ３｝）｝という構文を使用して定義可能である。この場合、ｅ２およびｅ３双方が同じマシンに送信される。これは、それらが双方ともソースノードに同時に存在するためであり、したがって、それらを一緒に保つことは理にかなっている。

いくつかのイベント処理ネットワークでは、イベント処理ネットワーク２＝（｛アダプタ１，チャネル１，プロセッサ１，プロセッサ２，チャネル２，チャネル３，アダプタ２，アダプタ３｝，｛（アダプタ１，チャネル１），（チャネル１，プロセッサ１），（プロセッサ１，チャネル２），（チャネル２，アダプタ２），（チャネル１，プロセッサ２），（プロセッサ２，チャネル３），（チャネル３，アダプタ３）｝）のように、単一のチャネルが２つのコンシューマを有し得る。そのような状況下でのクラスタ化ブロードキャストの場合、すべてのマシンにおけるすべてのプロセッサがイベントを受信する。

図６は、いくつかの実施形態に従った、１つのチャネルが２つのコンシューマを有するブロードキャストイベント処理ネットワーク６００の一例を示すブロック図である。図６では、イベント処理ネットワーク６００は、クラスタ化ブロードキャスト（チャネル１，マシン１，イベント処理ネットワーク２，｛（チャネル１，マシン１，｛ｅ１｝）｝）＝｛（プロセッサ１，マシン１，｛ｅ１｝），（プロセッサ２，マシン１，｛ｅ１｝），（プロセッサ１，マシン２，｛ｅ１｝），（プロセッサ２，マシン１，｛ｅ１｝），（プロセッサ１，マシン３，｛ｅ１｝），（プロセッサ２，マシン３，｛ｅ１｝）｝という構文を使用して定義可能である。マシン（たとえば、マシン１）内では、イベント（たとえば、ｅ１）の、その消費リスナ（たとえば、プロセッサ１、プロセッサ２）への送出は、順序付け要件に依存して、同期的に（すなわち、同じスレッド）または非同期的に（すなわち、異なるスレッド）起こり得る。

図７は、いくつかの実施形態に従った、１つのチャネルが２つのコンシューマを有するロードバランシングイベント処理ネットワーク７００の一例を示すブロック図である。この場合、複数のリスナがある。図７では、イベント処理ネットワーク７００は、ロードバランス（チャネル１，マシン１，イベント処理ネットワーク２，｛（チャネル１，マシン１，｛ｅ１｝）｝）＝｛（プロセッサ１，マシン１，｛ｅ１｝），（プロセッサ２，マシン１，｛ｅ１｝）｝という構文を使用して定義可能である。この場合、イベントは、単一のメンバーのすべてのリスナに送信される。言い換えれば、到着する次のイベントのみが、異なるサーバまたはマシンにロードバランス化されるであろう。

パーティションシナリオおよびファン・イン・シナリオは、単純なイベント処理ネットワークを再度使用して考慮され得る。図８は、いくつかの実施形態に従った、パーティショニングされたイベント処理ネットワーク８００の一例を示すブロック図である。図８では、イベント処理ネットワーク８００は、パーティション（チャネル１，マシン１，イベント処理ネットワーク１，｛（チャネル１，マシン１，｛ｅ１（ｐ１，１）｝）｝）：−｛（プロセッサ，マシン１，｛ｅ１（ｐ１，１）｝）｝という構文を使用して定義可能である。次に、イベントｅ２は、イベントｅ１と同じパーティション上で考慮され得るが、イベントｅ３は、異なるパーティション上で考慮され得る。これは、パーティション（チャネル１，マシン１，イベント処理ネットワーク１，｛（チャネル１，マシン１，｛ｅ２（ｐ１，１）｝）｝）：−｛（プロセッサ，マシン１，｛ｅ２（ｐ１，１）｝）｝；パーティション（チャネル１，マシン１，イベント処理ネットワーク１，｛（チャネル１，マシン１，｛ｅ３（ｐ１，２）｝）｝）：−｛（プロセッサ，マシン２，｛ｅ３（ｐ１，２）｝）｝という構文を使用して定義可能である。

いくつかの実施形態によれば、パーティショニングされたイベント処理ネットワークでは、イベントは、いくつかのマシンにだけではなく、すべてのマシンに到着する。図９は、いくつかの実施形態に従った、パーティショニングされたイベント処理ネットワーク９００の一例を示すブロック図である。いくつかの実施形態では、プロセッサは、それにフィードする複数の上流チャネルを有していてもよい。この状況は、複数のイベントを扱うことと同様である。

図１０は、いくつかの実施形態に従った、ファン・イン・イベント処理ネットワーク１０００の一例を示すブロック図である。図１０では、イベント処理ネットワーク１０００は、ファン・イン（チャネル１，マシン１，イベント処理ネットワーク１，｛（チャネル１，マシン１，｛ｅ１｝）｝）：−｛（プロセッサ，マシン１，｛ｅ１｝）｝；ファン・イン（チャネル１，マシン２，イベント処理ネットワーク１，｛（チャネル１，マシン２，｛ｅ２｝）｝）：−｛（プロセッサ，マシン１，｛ｅ２｝）｝という構文を使用して定義可能である。ファン・インの場合、イベントは、一緒に集められてマシン１に戻る。

順序付けおよびクエリ処理セマンティクス
いくつかの実施形態では、イベントは、あるノードから他のすべての宛先ノードへと瞬間的に現われない。そのような実施形態では、全順序はいつでも維持されるわけではない。順序付け要件は、あるシナリオにおいて、分散モデルおよびクエリ処理モデルのセマンティクスを破ることなく、安全に緩和され得る。

考慮すべき次元は２つあり、１つは単一のイベント用のマシン宛先の順序付け、もう１つは宛先に発信される際のイベント自体の順序付けである。各々は、別々に考慮可能である。

宛先順序付けについては、ロードバランシング、パーティションおよびファン・イン・ネットワークでは、単一の宛先（すなわち、∃！ｔ）があるため、宛先順序付けは適用できない。クラスタ化ブロードキャストネットワークでは、一般にブロードキャストの性質により、順序付け保証を仮定する必要はない。

イベント順序付けについては、ロードバランシングネットワークでは、初めにイベントが同じリソースに送信されるという保証がないため、イベントの順序付けを保証する利点はなく、よって、下流クエリ処理は、いくつかの実施形態では、アプリケーション時間順序付けを使用しようとしない。また、いくつかの実施形態では、下流クエリ処理は、すべてのイベントを受信することに依存しておらず、したがってステートレスである。この基準に該当するクエリのタイプは、フィルタリングおよびストリーム結合（１−ｎ個のストリーム関連結合）である。

クラスタ化ブロードキャストネットワークでは、すべてのサーバは、イベントの完全集合、ひいては処理の完全状態を有しており、そのためそのようなネットワークでは、順序は、各サーバ（すなわち宛先）のコンテキストで保たれる。

パーティションネットワークでは、順序付けはパーティション内で、特定の宛先へと保証される。これは、下流クエリ処理がパーティション順序付け制約を同様に利用することを可能にする。いくつかの実施形態では、この順序付けは、図９に関連して上述した場合のうちの１つと同様に、パーティショニングされるべきイベントをフィードしている複数の上流ノードの存在下でも保証される。

ファン・イン・ネットワークでは、初めにイベントがどのように分岐されたかについて、以下のように判断がなされる。イベントがロードバランス化された場合、順序付け保証
はなく、ファン・イン関数も何ら順序を課さない。下記は、イベントがパーティショニングされる場合、一実施形態において起こることの一例である：
入力：｛｛ｔ４，ｂ｝，｛ｔ３，ａ｝，｛ｔ２，ｂ｝，｛ｔ１，ａ｝｝
パーティションａ：｛｛ｔ３，ａ｝，｛ｔ１，ａ｝｝
パーティションｂ：｛｛ｔ４，ｂ｝，｛ｔ２，ｂ｝｝
スケジュール１：｛｛ｔ４，ｂ｝，｛ｔ３，ａ｝，｛ｔ１，ａ｝，｛ｔ２，ｂ｝｝
スケジュール２：｛｛ｔ４，ｂ｝，｛ｔ１，ａ｝，｛ｔ２，ｂ｝，｛ｔ３，ａ｝｝
スケジュール３：｛｛ｔ４，ｂ｝，｛ｔ３，ａ｝，｛ｔ２，ｂ｝，｛ｔ１，ａ｝｝
上流パーティショニングの場合、ファン・インは、元の入力とは異なる順序でイベントを並べ替えることに終わるかもしれない。これを避けるために、ファン・イン・ネットワークはイベントを、それらが異なるソースから受信されているにもかかわらず順序付ける。

これらの異なるシナリオに対処するために、異なるセマンティクスが異なるシナリオで使用される。順序付け無しのシナリオの場合、イベント間では、それらのタイムスタンプに従った順序付け保証は必要とはされない。

部分パーティション順序付けのシナリオの場合、いくつかの実施形態によれば、ソースおよび宛先ノードペアのコンテキストにおいて、ならびにパーティションのコンテキストにおいて、イベントは、それらのタイムスタンプに従って順序付けられるよう保証される（すなわちａ≦ｂ）。言い換えれば、異なる上流のサーバから来るイベントは、順序付けられるよう保証されず、異なるパーティション向けのイベントも同様に、順序付けられるよう保証されない。

全パーティション順序付けシナリオの場合、すべてのソースおよび宛先ノードペアにわたって、ならびにパーティションのコンテキストにおいて、イベントは、それらのタイムスタンプに従って順序付けられるよう保証される（すなわちａ≦ｂ）。このモードをサポートできるようにするために、タイムスタンプの単一のビューを、クラスタ中に課すことができる。この場合については、アプリケーションタイムスタンプを使用することができる。

部分順序付けシナリオの場合、いくつかの実施形態では、ソースおよび宛先ノードペアのコンテキストにおいて、イベントは、それらのタイムスタンプに従って順序付けられるよう保証される（すなわちａ≦ｂ）。

全順序付けの場合、いくつかの実施形態では、すべてのソースおよび宛先ノードペアにわたって、イベントは、それらのタイムスタンプに従って順序付けられるよう保証される（すなわちａ≦ｂ）。

これらの制約は、最小制約から最大制約について提示された。これらの異なる制約をサポートするために、いくつかの実施形態では、以下の追加構成が使用される。アプリケーションタイムスタンププロパティは、全順序基準に使用されるべきイベントプロパティである。タイムアウトプロパティは、進む前に上流イベントを待つための時間を示す。ばらばらの順序のポリシーは、イベントがばらばらの順序で到着した場合、それらのイベントを廃棄すべきか、故障として発生させるべきか、または配信不能キューに送信すべきかを示す。

いくつかの実施形態では、各分散フローは、異なる一組の順序付け制約を用いて使用可能である。ロードバランス化されたネットワークでは、制約は順序付けられなくてもよい。ブロードキャストネットワークでは、入力ストリームのすべてのイベントは、それらが
ブロードキャストチャネル上で受信されたのと同じ順序で、ネットワークのすべてのノードに伝搬され得る。各ノードは完全状態を維持することができ、したがって、ブロードキャストチャネルをリスニングしているあらゆるノードは、任意のタイムスタンプでの状態と全く同じ状態を有する。このため、これらのノードの各々の下流側のリスナは、出力イベントを全順序で受信でき、制約は、ローカルブロードキャストで全順序付けられ得る。クラスタ化ブロードキャストについては、ネットワークを介したイベント配信は、イベントの順序付け無しを引き起こすかもしれないが、定義により、配信は、順序付けられた配信の要件をネットワークが満たせるように、全順序付けられるべきである。パーティショニングされたネットワークでは、各ノードは、部分的な状態を維持し、イベントの部分集合を受信することができる。サブストリームの受信されたイベントは、入力ストリームにおいて観察されたのと同じ順序である。このため、パーティション間にわたって（各ノード上に１つのパーティション）、入力ストリームは順序付けられ、制約は、パーティショニングされたネットワークでパーティション順序付けがなされ得る。クラスタ化パーティションでは、ネットワークを介したイベント配信は、イベントの順序付け無しを引き起こすかもしれないが、ここでも定義により、配信は、順序付けられた配信の要件をネットワークが満たせるように、全順序付けられるべきである。ファン・イン・ネットワークでは、制約は、順序付けられないかもしれず、部分順序付けられるかもしれず、または全順序付けられるかもしれない。

また、宛先ノードがＣＱＬプロセッサであり、そのクエリが知られている場合、分散順序付け制約は、それらのクエリから推論され得る。たとえば、すべてのクエリがパーティション順序付けとして構成される場合、分散フローも、少なくとも、部分パーティション順序付けに設定され得る。

デプロイメント計画
いくつかの実施形態では、コンピューティングリソースは、ノード間にわたって共有される。リソースのよりよい共有を可能にするために、ノードが、「メモリ＞１Ｍ」または「スレッド＞３」といった一組の制約要件で注釈付けされてもよく、逆に、コンピューティングリソースが、「メモリ＝１０Ｍ」または「スレッドプール＝１０」といった一組の能力で注釈付けされてもよい。

たとえば、要件は、｛プロセッサ１｝＝｛スレッド＞３｝という要件として示され得る。能力は、｛マシン１｝＝｛最大スレッドプール＝１０，ｃｐｕ＝８｝という能力として示され得る。

ノードへのリソースのスケジューリング中、システムは、要件を能力と一致させるよう試み、そうすることにより、能力がノードに割り当てられている際に能力の現在値を動的に増減させる。たとえば、スケジュールは、スケジュール−１：｛プロセッサ１｝＝｛スレッド＞３，コンピューティングリソース＝マシン１｝；スケジュール−１：｛マシン１｝＝｛最大スレッドプール＝１０，現在のスレッドプール＝７｝として示され得る。

加えて、たとえば、アプリケーションの負荷の増加に対処するために新しいコンピューティングリソースをクラスタに追加することによって、クラスタ自体の総能力が変化し得る。これは、コンピューティング拡張性として知られている。たとえば、ｔ＝０では｛クラスタ｝＝｛マシン１，マシン２｝であるが、ｔ＝１では｛クラスタ｝＝｛マシン１，マシン２，マシン３｝である。システムは、リソースのこれらの動的変化に対処する。

システムのオペレータが特定のコンピューティングリソースへのノードの手動割当てを行ないたい場合があり得る。これは、「コンピューティングリソース」を要件自体と考えることによってサポート可能である。たとえば、要件：｛プロセッサ１｝＝｛スレッド＞
３，コンピューティングリソース＝マシン１｝である。デプロイメント要件のこの仕様はデプロイメント計画として知られており、アプリケーションメタデータ内に含まれ得る。

クラスタメンバー構成およびドメイン構成
Ｈａｄｏｏｐでは、マップ−リデュースシステムの初めのマッピング関数は、分散されたタスクに複製され、並列に実行され、各々別個の入力データを読出し、または最も一般的には、各々入力データのチャンクを読出す。ストリーム処理は同様である。上流ノード（すなわち、インバウンドアダプタ）は各々、異なるストリームに、またはストリームの異なるパーティションにサブスクライブする。これは、分散型イベント処理ネットワークが、いくつかの実施形態では、インバウンドアダプタが並列で作動することを可能にする、ということを意味する。二次ノードに存在するインバウンドアダプタを中断状態に保つ必要はない。

いくつかの実施形態では、各インバウンドアダプタは、異なるストリームに、またはストリームの異なるパーティションにサブスクライブすることができる。これは、イベント処理でクラスタ化メンバー機能を使用することによって行なうことができ、その場合、メンバーは、それが一次メンバーであるか否かを見出すことができ、クラスタにおける一意的なＩＤに関連付けられて、したがってこのＩＤをストリームまたはストリームパーティション構成へのキーとして使用することができる。

二次メンバーは、どのイベントにもサブスクライブしないことも選択してもよく、その場合、システムの入力局面は並列に実行されない。

コスト複雑性およびバッチ処理
分散型システムにおける通信コストは、データ自体を処理するコストをたやすく上回り得る。実際、リデューサが多すぎて通信コストが増加する場合と、リデューサが少なすぎて、キーに関連付けられる要素が多すぎ、ひいてはリデューサごとのメモリが十分でない場合との間に、最良のトレードオフを見つけようとすることは、Ｈａｄｏｏｐにおける共通問題である。

このコストおよびそれに対処するためのメカニズムについての理解を容易にするために、以下が提供される。待ち時間メトリックが、イベントの、その通信待ち時間による総待ち時間の比率として計算される。これは、イベントの何らかのサンプリングされたレートについて行なわれ、ランタイムに動的にオンオフされ得る。いくつかの実施形態では、バッチ処理ＡＰＩを使用して一緒に送信されたイベントは実際に、全体分散を通して一緒にバッチ処理される、という保証がある。

挙動的視点
いくつかの実施形態では、キャッシュコヒーレンスは、メッセージングおよびパーティショニング双方に使用され得る。協働するセマンティクスはフローごとに変わり、特定のキャッシュスキーム、キャッシュキー、およびフィルタリングの組合せで実現され得る。送信側（ソース）はキャッシュにイベントを挿入し（すなわちput()）、受信側（ターゲ
ット）はキャッシュからイベントを除去する（すなわち、get／delete）。正しい受信側
が正しい一組のイベントを得ることを保証するために、フィルタリングされたイベントを有するMapListener APIを使用することができる。しかしながら、イベントが別々のアク
ションとして受信され、次に削除されるべきだった場合、それは２つの別々のネットワーク動作を引き起こしたであろう。したがって、いくつかの実施形態では、イベントは、それ自体のメリットによって失効するよう許可される。このように、キャッシュコヒーレンスは、イベントの削除をバッチ処理し、それを適切な時間に行なう。

いくつかの実施形態では、フローのタイプごとに、同じキャッシュサービスが、すべてのアプリケーションのために共有される。たとえば、すべての複製されたフローのための単一のキャッシュサービス、パーティションフローのための別の単一のキャッシュサービス、などがあってもよい。エントリごとにロッキングが行なわれ得るため、あるアプリケーションにおけるあるチャネルによるあるイベントの取り扱いは他のアプリケーションに影響を与えず、これは、単一のサーバにおけるキャッシュの急増を回避する。

ブロードキャストフローの場合、すべてのイベントがすべてのメンバーによって受信されるべきであるため、複製されたキャッシュスキームを使用することができる。キャッシュキーは、メンバーＩＤ、アプリケーション名、イベント処理ネットワークステージ名（たとえばチャネル名）、およびイベントタイムスタンプ（アプリケーションベースであれ、システムベースであれ）のハッシュである：

キャッシュ値は、アプリケーションＩＤ、イベント処理ネットワークステージＩＤ、およびターゲットＩＤが追加された、元のイベントのラッパーであり、すべてのメンバーを表わすために−１に設定されている。アプリケーションＩＤおよびステージＩＤは、元のアプリケーション名およびステージ名のハッシュであり、ユーザ設定文字列（string）である。ラッパーは、イベントタイムスタンプ（アプリケーションプロパティベースではない場合）と、イベント種類（すなわち、挿入、削除、更新、ハートビート）とを含み得る：

いくつかの実施形態では、すべてのクラスタ化されたメンバーは、問題となっているブロードキャストチャネルのためのアプリケーションＩＤおよびイベント処理ネットワークステージＩＤに設定されたフィルタに、MapListenerを登録する。これは、送信側の役割
で作用するメンバーがブロードキャストキャッシュにイベントを入れると、受信側の役割で作用するすべてのメンバーがMapListener.entryInserted(MapEvent)上に呼び戻され得
る、ということを意味する。

フローが順序付け無しに設定される場合、MapListenerは非同期的であり、下流処理の
ためにコヒーレンススレッドを使用することができる。フローが順序付けに設定される場合、SynchronousMapListenerが登録可能であり、イベントは、下流処理のために単集合チャネルスレッドに直ちに手渡され得る。ある実施形態では、これは、マップ全体が同期可能であるために行なわれ、よって、各チャネルについての作業がキューに入れられ、スレッドが直ちに返され、他のチャネルがそれらのイベントを受信するようになる。送信側の元のメンバーノードが、MapListenerを通してイベントを受信することができる。

ロードバランス化されたフローの場合、ターゲットコンピューティングリソースは、クラスタにおけるメンバーの総数を見出し、［０，総数］間で乱数を生成することによって選択され得る。言い換えれば、ロードバランシングを達成するために、最近使用されたメンバーを有する何らかのクラスタ化状態を保つのではなく、ランダム化を使用することができる。キーおよび値は、ブロードキャストの場合と同様であり得る。しかしながら、MapListenerは、アプリケーションＩＤ、ステージＩＤ、およびターゲットＩＤに設定され
たフィルタに登録可能であり、ターゲットＩＤの値は、ランダムに選択されたメンバーＩＤである。言い換えれば、いくつかの実施形態では、ランダムに選択されたターゲットのみがイベントを受信するものとする。いくつかの実施形態によれば、ロードバランス化されたフローは、順序付け無しの場合のみをサポートし、そのため、非同期リスナのみが使用される。

ファン・イン・フローの場合、ターゲットコンピューティングリソースは、何らかの構成メカニズムごとに、ユーザによって直接特定され得る。このユーザ定義のターゲットＩＤはキャッシュ値ラッパーで設定可能であるが、他の点では、セマンティクスはロードバランスの場合と同様である。ファン・イン・フローは、全順序をサポートする。この場合、同期マップリスナの使用に加えて、チャネルはアプリケーションタイムスタンプを使用するように構成可能であり、受信側では、イベントは、何らかのユーザ構成可能なタイムアウト値まで並べ替え可能である。タイムアウト値は、たとえば数秒の範囲にあってもよく、より少ない待ち時間と順序がばらばらのイベントのより多い可能性との間のトレードオフバランスに基づいていてもよい。

いくつかの実施形態では、最適化は、キャッシュキーが順序付けられたまま保たれることを保証するハッシュを使用する。受信側はその場合、最近から過去のある時点に及ぶある特定のチャネルのためのすべてのエントリを検索するフィルタを使用することができる。この場合、連続クエリマップを使用することができる。このマップは、同じタイムアウト構成を使用して周期的にチェックされ得る。

ファン・イン・フローの場合、パーティショニングキャッシュスキームの固有のパーティショニングサポートを活用することができる。キャッシュデータアフィニティは、アプリケーションＩＤ、ステージＩＤ、および構成されたパーティションイベントプロパティ（値）、たとえば「記号」というイベントプロパティについての「ＯＲＣＬ」という値、からなる（パーティション）キーに関連するようにセットアップされ得る。これは、KeyAssociationクラスの使用を通して行なわれ得る。キャッシュキーは、（たとえば、タイムスタンプを用いて）同じままであってもよい。しかしながら、いくつかの実施形態では、すべてのキーが、前述したばかりのパーティションキーへの関連を有し、パーティションが同一場所に設置されたままであることを保証する。

最適場所にデータを置くためにキャッシュコヒーレンスが使用される場合、ターゲットメンバーは選択されず、したがって、MapListenerを使用する代わりに、EntryProcessor
が、アプリケーションＩＤ、ステージＩＤ、およびパーティションイベントプロパティ値に設定されたフィルタを用いて使用される。この場合、ソースノードはEntryProcessorを呼び出し、EntryProcessor実装は、データが存在するメンバーにおいて実行されることを保証され、したがって、ターゲットメンバーへのデータのコピーが、以前に明示的に選択されたものであることを回避する。キャッシュコヒーレンスは、その判断を使用して最適化することができ、クラスタメンバーおよびデータサイズごとにパーティションの正しい数を判断するために、その内部を十分に使用する。

呼び出し可能タスクは、それが扱っているエントリのためのロックを暗黙的に取得する。このこと、およびデータが同一場所に設置されるという事実は、エントリが、（エントリを失効させる代わりに）別のネットワーク動作を引き起こすことなく処理の終わりで削除可能である、ということを意味する。フローが順序付けられないように構成される場合、タスクは、チャネルのマルチスレッドのエグゼキュータにできるだけ早く手渡され得る。フローが順序付けられる場合も、同様にタスクはチャネルに手渡され得るが、単集合チャネルスレッドに手渡され得る。フローがパーティション順序付けである場合、手渡しはパーティションごとに起こり得る。パーティションは、キー関連から判断可能であり、次
に、実行のための正しいスレッドに索引を付けるために使用可能である。言い換えれば、スレッドは、パーティションごとに特徴付けられ得る。

耐故障性に関し、送信側がイベントを発行する際にメンバーがダウンしている場合、および受信側がMapListenerを使用している場合、イベントは、メンバーが再度立ち上がっ
た際に受信されない。これを解決するための１つのアプローチは、MapListenerと連続ク
エリマップとの組合せを使用することである。この場合、イベントは、だらだらするのではなく、それが完全に処理されるやいなや、削除され得る。メンバーがイベントを受信し、そのイベントの処理を終了する前にダウンした場合、イベントは再処理される。つまり、イベントは、それが完全に処理されるまで、キャッシュから削除されない。

パーティショニングされたデータが異なるサーバに移動する場合、パーティションが移動されたかどうかという通知のために、ライブイベントがリスニングされ得る。いくつかの実施形態では、この状況は、新しいウィンドウが経過するまで状態が失われることをユーザに知らせるために、故障として発生する。たとえば、１０分のウィンドウの最中では、次のウィンドウでのみ状態は有効であろう。

構造的視点
いくつかの実施形態では、分散フローを通過するすべてのイベントは、シリアル化され得る。構成の点で、チャネルコンポーネントに以下を追加することができる。フロータイプ：ローカルまたはクラスタ化パーティション、ローカルまたはクラスタ化ブロードキャスト、ロードバランス、ファン・イン；順序付け：順序付け無し、部分パーティション順序付け、全パーティション順序付け、部分順序付け、全順序付け；パーティションプロパティ：文字列；アプリケーションタイムスタンプ：long型；全順序タイムアウト：long型。

デプロイメント視点
コヒーレンスキャッシュ構成は、サーバデプロイメント／構成の一部として含まれ得る。これは、異なる分散フローの各々ごとに、異なるキャッシュスキーマのための構成を含み得る。

設計−時間の考慮事項
いくつかの実施形態では、統合開発環境（integrated development environment：ＩＤＥ）内で、開発者は、パレットから、通常チャネル、ブロードキャストチャネル、パーティションチャネル、またはファン・イン・チャネルという異なる種類のチャネルを選択することができる。パレットにおける異なるチャネル種類は、ユーザへの視覚的合図である。それらは、ユーザが、ＩＤＥにおいてアプリケーションを作成する必要なく、ランタイム分散フローを変更することを可能にするように、構成として実装可能である。パーティションチャネルの場合、ＩＤＥは、順序付けられた一組のイベントプロパティがパーティション基準として使用されるようにユーザを促すことによって、フォローアップすることができる。この順序付けられた一組のイベントプロパティは、チャネルのイベントタイプで定義されたように存在し得る。同様に、任意の他のチャネル特有構成が、それに応じて構成可能になり得る。

管理、動作、およびセキュリティ
分散されたチャネル種類、およびそれに関連付けられた任意の構成が、イベント処理ネットワーク図におけるチャネルおよびチャネル構成の一部として、管理コンソールにおいて提示されてもよい。管理／監視コンソールはまた、クラスタのコンピューティングリソースの完全なネットワークを視覚化するためのメカニズムを提供することができる。これは、クラスタのデプロイメント図である。

また、１つの局面は、あるコンピューティングリソースにおけるソースノードと別のコンピューティングリソースにおける宛先ノードとの間のランタイムインタラクションまたはマッピングを理解できることを伴う。これは、クラスタの接続図を構成する。この場合、ランタイム接続だけでなく、接続を通過したイベントの数も示される。

別の有用な監視ツールは、特定のイベントのために防護する能力を提供する。たとえば、ユーザは、イベントｅ１＝｛（ｐ１，１），（ｐ２，２）｝がマシン３のプロセッサ２を通過したことを保証できる。いくつかの実施形態では、イベントを待ち構えるためのメカニズムが提供される。

イベントデータに基づくグラフのプロット
いくつかの実施形態は、ストリーミングデータにおける、脅威および機会といった状況のリアルタイム識別を可能にする。そのような状況は、視覚化されたグラフを通して識別され得る。データを視覚化するために使用され得るさまざまなグラフおよびプロットを、以下に説明する。いくつかのそのようなグラフは、監視グラフではなく、むしろ調査グラフである。調査グラフは、異なる状況の試行観察ピンポイント化（try-and-see pin-pointing）を可能にするように構成可能であり得る。

いくつかの実施形態によれば、グラフ化メカニズムは、時系列データを入力として受信する。時系列データとは、時間とともに変わるデータである。時系列データは、線グラフ、散布図、およびレーダーチャートといったタイプのチャートによって表わされ得る。棒グラフおよび円グラフは、カテゴリーデータを表わすために使用可能である。

線グラフは、時系列データを視覚化する１つの方法である。Ｘ軸は、時間の動きを表わすために使用可能であり、このため、時間が進む際のデータの自然なスクロールを可能にする。Ｙ軸は、時間が進む際の従属変数、すなわち対象変数の変化を見るために使用可能である。図１１は、いくつかの実施形態に従った、線グラフ１１００の一例を示す図である。

従属変数は、出力イベントのプロパティのいずれかであり得る。たとえば、従属変数は、株というイベントの「価格」というプロパティ、または、ソースへの概要および条件の適用から生じる「合計（価格）＞１０」というプロパティであり得る。線グラフは、連続変数にとって好適である。いくつかの実施形態では、線グラフのために、数値であるイベントプロパティの選択が許可される。いくつかの実施形態では、インターバル、DateTime、ブーリアン、文字列、ＸＭＬなどのタイプのプロパティは、Ｙ軸で選択されるよう許可されていない。出力イベントの第１の数値プロパティは、最初にＹ軸として選択され得る。ユーザは、これを任意の他の数値プロパティに変更するよう許可される。

上述のように、Ｘ軸は時系列を特定できる。この軸は、ＨＨ：ＭＭ：ＳＳ：ミリ秒フォーマットに変換された出力イベントの到着のシステムタイムスタンプを使用することができ、クエリを評価してライブストリームの表形式の出力テーブルを更新するために公知の摺動基準を使用して摺動することができる。これはおそらく１／１０秒〜１／２秒の範囲にあるであろう。いくつかの実施形態では、オプションで、ＣＱＬによって指示されるような出力イベントの実際のタイムスタンプまたは要素時間が使用可能である。アプリケーションタイムスタンプされたクエリの場合、タイムスタンプはアプリケーション時間を表わし、それはシステム時間とは著しく異なり得る。たとえば、アプリケーション時間は、実際の１時間ごとに１目盛り動いてもよい。

ストリーミングデータを分析する別の局面は、その変数間の相関を理解することである
。相関は、ペアの変数の共分散（covariance）を示し、−１（強い逆相関）から、０（無相関）、１（強い正相関）に及ぶ。たとえば、自動車の重量は、そのマイル／ガロン（miles per gallon：ＭＰＧ）に正相関する。しかしながら、自動車の重量とその色との間には相関がない。この相関をサポートするために、いくつかの実施形態は、（異なる色の）第２の線が線グラフにプロットされることを可能にする。この第２の線は第２の変数を表わし、それは、ユーザによって選択された第２のイベントプロパティであり得る。

ｘとｙとのペアの組から構成された各線は、データ系列として知られている。プロットされた２本の線を有することにより、ユーザは、変数が直接線形性を有するか、または間接線形性を有するかを視覚化することができる。加えて、グラフにおいて、変数の相関係数を計算し提示することができる。相関係数は、correlate() CQL関数を使用して計算可
能である。相関係数は色目盛りを使用して提示可能であり、緑は正相関、赤は逆相関であり、灰色は無相関を意味する。

いくつかの実施形態では、（たとえば５〜１０の）何らかの便利な最大値までの線（系列）として線グラフにプロットされるべき追加の変数（すなわちイベントプロパティ）を選択するためのメカニズムが、ユーザに提供される。ユーザが出力イベントのプロパティを選択している際、ユーザは、カテゴリープロパティのカウントの結果といった、計算された変数を選択できる。しかしながら、相関はペア状に行なわれ、また重い負担をかける場合があるため、いくつかの実施形態は、一度に２つの変数のみが相関されることを許可する。チャートが３つ以上の変数を有する場合、ユーザは、相関係数を計算するためにどの２つを使用すべきかを通知してもよい。

いくつかの実施形態では、オプションで、相関係数の計算と並んで、結果の確実性を計算することができる。これは、ランダムサンプルが同じ結果をもたらす可能性がどれくらいあるかをユーザに知らせる。

相関は、分散（variance）および共分散に結び付けられる。いくつかの実施形態では、オプションで、グラフの目に見える特徴が、グラフ内に表わされた分布が正規分布であるか否かを示す。

いくつかの実施形態では、上位Ｎ個の相関ペア状変数が自動的に判断可能である。
時間次元がそれほど重要ではない場合、データは、散布図における表現を通してより良好に理解され得る。図１２は、いくつかの実施形態に従った、散布図１２００の一例を示す図である。この場合、ユーザは、異なるイベントプロパティをＸ軸およびＹ軸双方に割り当てることができる。しかしながら、いくつかの実施形態では、双方とも数値変数であるように制約される。いくつかの実施形態では、デフォルトで、出力イベント（タイプ）から、数値である最初の２つのプロパティを選択することができる。Ｘ軸は説明変数を表わし、Ｙ軸は応答変数を表わす。よって、totalX、またはsumOfY、またはoutcomeZといった、応答または計算されたフィールドを示すプロパティは、Ｙ軸への自動割当てにとってふさわしい候補であり得る。

時系列の場合、新しい値がグラフの右側で入り、古い値が左側で出る。しかしながら、この挙動は散布図に変換されない。なぜなら、新しい点はどこにでも現われ得るためである。よって、いくつかの実施形態では、新しい点は、何らかの視覚的合図を与えられる。たとえば、他の既存の点とは異なり、新しい点は最初に赤または青で描かれ、新しい点が到着するにつれて徐々に消えていくようになっていてもよい。

グラフの最も古い点が自動的に除去され始める前に、一度にさまざまな数の点をグラフに維持することができる。この除去を行なう方法はいくつかある。１つの手法は、点が視
覚化を劣化させない（またはごちゃごちゃさせない）限り、できるだけ多くの点を保つ。別の手法は、データを理解するために必要とされる最小の組のイベントを保つ。

いくつかの実施形態では、何らかの形で点を制限する、または形作る線を、散布図に引くことができる。１つの手法は、Ｙ軸のすべての値より上に最大値を表わす線を引き、Ｙ軸のすべての値より下に最小値を表わす別の線を引く。別の手法は、すべての点を包含する多角形を描く。これは、値がどこに位置するかについての制限された図をユーザに与える。

別の手法は、平滑化された曲線適合線（すなわち部分的に重付けされた回帰（lowess））を引く。図１３は、いくつかの実施形態に従った、平滑化された曲線適合線が引かれた散布図１３００の一例を示す図である。この手法は、予測オンライン処理のために活用され得る。線グラフの場合と同様に、問題となっている２つの変数の相関係数を提供することができる。平滑化された線および回帰適合は、線形性も示すことができる。

散布図は、点のサイズとして表わされる第３の次元の視覚化のサポートによく向いている。図１４は、いくつかの実施形態に従った、点のサイズが異なっている散布図１４００の一例を示す図である。この場合、ユーザは、「サイズ」という次元に第３のイベントプロパティを割り当てることができる。メカニズムは、グラフをごちゃごちゃにしない態様でサイズをスケーリングすることができる。

レーダーチャートは、Ｘ軸が、２４時間周期といった時間周期を表わす円として描かれ、それをレーダーのように見せる点を除き、線グラフと同様である。図１５は、いくつかの実施形態に従った、レーダー図１５００の一例を示す図である。レーダーチャートは、ある特定の状況が周期的であるかどうかを見つけるのに有用であり、よって、時系列を扱うための有用なツールである。たとえば、そのようなチャートは、株価が典型的に営業日の最初または最後で高いかどうか、もしくは、金曜日に販売された航空券の数が他の曜日より多いかどうかを判断するために使用可能である。

レーダーチャートのための応答変数も、数値であり得る。Ｘ軸のための正しい目盛りを見つけることは、レーダーチャートのための考慮事項である。ウィンドウ範囲が定義されている場合、それはレーダーチャートのためのデフォルト周期として使用可能である。他の場合、周期は、ミリ秒から時間単位に変更可能である。線グラフと同様に、追加の線は、チャートにおける異なる応答変数を表わすことができる。

数値変数は、グラフで視覚化され得る唯一の変数ではない。カテゴリー変数も、それらが名目的（たとえば、男性、女性）であれ、順序的（たとえば、高い、中間、低い）であれ、グラフで視覚化され得る。カテゴリー変数は一般に、たとえば、不正行為の数（要因は「不正行為」、「不正行為なし」）、上客と普通の顧客との比率、先週観られた上位５本の映画などといった頻度として分析される。そのような変数は通常、棒グラフおよび円グラフで視覚化される。場合によっては、上位ｎ個のように、頻度の計算に関与する多いＣＰＵ／メモリ消費があり得る。このため、いくつかの実施形態では、そのような計算はバックグラウンドで行なわれない。いくつかの実施形態では、以下の動作が行なわれる：
１．棒グラフ（または円グラフ）を選択する
２．文字列タイプのイベントプロパティをＸ軸に割当てる
３．カウント結果（または任意の他の数値プロパティ）をＹ軸に割当てる。

カウント結果は、ユーザによって定義された通りに、たとえばウィンドウ範囲を使用して更新可能であり、よって、棒グラフから値を明示的にパージする必要はない。円グラフも選択可能である。カテゴリー間にわたる総量が１００％になることを確かめることが、
ユーザに委ねられ得る。

線グラフは、時系列における一般的傾向を探すことを伴うシナリオにとって、および数値変数にとって好適である。散布図は、相関を探すことを伴うシナリオにとって、および数値変数にとって好適である。レーダーチャートは、周期を探すことを伴うシナリオにとって、および数値変数にとって好適である。棒グラフは、頻度をカウントすることを伴うシナリオにとって、およびカテゴリー変数にとって好適である。

あるタイプのグラフはある特定のタイプのデータ（たとえば、カテゴリーデータまたは数値データ）および分析により良好に適し得るため、それらは同様に、異なるようにサイズ決めされ更新され得る。時系列に焦点を合わせた線グラフは、最近のｔ回のイベントを含んでおり、システム（ＣＰＵ）の時間の動きとともに動く（更新する）ことができる。言い換えれば、イベントが到着しなくても、グラフは依然として更新し、以前にプロットされたイベントを右から左に動かすであろう。デフォルトで、線グラフは、最近の３００秒のイベントを含むように構成可能である。しかしながら、ユーザは、パラメータｔ（たとえば３００）を変更するだけでなく、時間粗さをミリ秒から分単位に変更することもできる。時間ウィンドウが定義されている場合、時間ウィンドウのサイズは、線グラフのためのＸ軸のデフォルトサイズ（目盛り）として使用され得る。

レーダーチャートは線グラフと同様であり、周期間隔も構成することが追加されている。たとえば、構成は、各６０秒の周期（期間）で３００秒を示すことを表示できる。散布図および棒グラフは時間を対象としていないため、いくつかの実施形態では、イベントが到着したときのみ更新され、時間が進むにつれて必ずしも更新されない。Ｘ軸のサイズは、以下のようにパワー分析を使用して判断され得る。散布図は相関を見つけるために使用されていること、および、典型的には、変数間に８０％の共分散がある場合、相関は強いと考えられることを考慮すると、信頼度９５％（すなわち、有意のパターンを表わすランダムな点が５％ある可能性がある）を使用した場合、以下のようになる：

すなわち、散布図は、少なくとも２６５個の点を含むべきである。これが、１０％の許容誤差を有する７５％の相関に緩和された場合、以下のようになる：

双方のオプションが可能である。いくつかの実施形態では、ユーザは、サイズを任意の数にカスタマイズすることができる。

棒グラフは散布図と同様に機能し、いくつかの実施形態では、新しいイベントが到着したときのみ更新される。カテゴリーの数は、プロセスを使用して決定され得る。１０〜２０の範囲におけるデフォルトが仮定され得る。ユーザは、必要に応じてさらにカスタマイズすることができる。いくつかの実施形態では、上位ｎ個のカテゴリーが選択され得る。いくつかの実施形態では、これはクエリにコード化され得る。

表形式の出力も、散布図と同様の言い方でサイズ決めされ得る。複数の変数を有する点をプロットする場合に生じる１つの問題は、目盛りの問題である。特にこれは、複数の系
列を有する線グラフを使用する場合、非常に明らかである。これは、２つのステップで行なわれ得る：
１．データが平均値により近くなるように、データを中央に置く。これは、外れ値をもたらす；
２．データをその標準偏差で割ることによって比率を正規化する。

式は、以下の通りである：
ｘ’＝（ｘ−平均）／標準偏差
平均および標準偏差は、そのストリーミングする性質のため、いくつかの実施形態では連続的に更新される。

教師無し学習のクラスタ化
クラスタ化は、その変数（特徴）がともにより近いイベントをグループ化する。このグループ化により、ユーザは、何らかの未知の関係によって一緒に動くイベントを識別できるようになる。たとえば、株式市場では、デリバティブのクラスタが一緒に上下することは一般的である。たとえば、ＩＢＭからの肯定的な収益報告書がある場合、オラクル、マイクロソフト、およびＳＡＰからも肯定的な結果が続く可能性がある。

クラスタ化の１つの魅力は、それが教師無しということである。すなわち、ユーザは、応答変数を識別したり訓練データを提供したりする必要はない。このフレームワークは、ストリーミングデータによく合う。いくつかの実施形態では、以下のアルゴリズムが使用される。

各イベントｉがｊ個の変数（たとえば、価格、体積）を含む場合（ｘｉｊとして特定される）、および、イベントをｋ個のクラスタにクラスタ化して、各ｋクラスタが、クラスタの一部であるすべてのイベントについてのｊ個の変数の平均のベクトルであるその重心ｃｋｊによって定義されるようにすることが目的である場合、処理ウィンドウに挿入される各イベントについて、そのｋクラスタを判断することができる：
１．それが第１のイベントである場合、それを最小のｋクラスタ（たとえばクラスタ０）に割当てる
２．すべての（新しい）入力イベントｉについて、以下のように、ｋ個のクラスタの重心までのその（二乗）距離を計算する

２ｂ．イベントｉを、最も小さいdistikを有するクラスタｋに割当てる
３．選択されたクラスタｋのための重心を再計算する

ストリーミングデータについては、処理ウィンドウを出るイベントを扱う追加の複雑性がある：
１．パージされるクラスタｋからのすべての（古い）イベントｉについて、そのクラスタの重心を再計算する

重心が変わるにつれて（それは（新しい、および古い）すべてのイベントについて起こる）、既存のイベント（点）が新しいクラスタに再配置される可能性があり、その場合、距離は最小となっている。よって、いくつかの実施形態におけるプロセスは、再割当てがもう起こらなくなるまで、すべての割当てられた点について距離を再計算する。しかしながら、これは困難なステップであり得る。処理ウィンドウが小さく、ペースが速い場合、新しい点の除去および追加は同じ効果を有し、達成可能な最良の局所最適点にゆっくり収束するであろう。この収束は保証されていないため、イベントが到着すると再計算を有効／無効にするオプションが提供され得る。

別の問題は、スケーリングの問題である。距離は、特徴間のユークリッド距離として計算されるので、いくつかの実施形態では、特徴は等しくスケーリングされる。他の場合では、距離計算中、単一の特徴が他の特徴を圧倒するかもしれない。

クラスタ化アルゴリズムは、以下の形のＣＱＬ集約関数として表現され得る：

パラメータ最大クラスタは、クラスタの総数（すなわちｋ）を定義し、クエリが一旦始まると変更されない。後者のシグネチャは、クラスタ割当ての再計算を有効にし、イベントキーのリストをクラスタ割当てに返す。

視覚化に関して、クラスタ化データは、以前に定義された、サポートされたグラフのうちのいずれかの上に重ね合わされ得る。言い換えれば、ユーザが散布図を選択した場合、各点の一部として、その点をｋ個のクラスタのうちの１つに関連付ける色および／または形状が含まれ得る。図１９は、いくつかの実施形態に従った、散布図１９００上に重ね合わされたクラスタ表現形状の一例を示す図である。形状は、形状が表わすクラスタに属する点を含む。

ＨＢａｓｅ
上述のように、ＴＦ−ＩＤＦ値の計算は、「逆文書頻度」計算のために履歴文書にアクセスすることを伴い、ＴＦ−ＩＤＦストリーム処理シナリオを、ＨＢａｓｅのような索引付け層で使用するためにふさわしい候補にする。ＨＢａｓｅは、リレーショナルデータベース管理システム（relational database management system：ＲＤＢＭＳ）の機能性が
要求されない「ビッグデータ」格納にとって好適である。ＨＢａｓｅは、一種の「ＮＯＳＱＬ」データベースである。ＨＢａｓｅは、構造化クエリ言語（ＳＱＬ）を、データにアクセスするための主要手段としてサポートしない。代わりに、ＨＢａｓｅは、データを検索するために、ＪＡＶＡアプリケーションプログラミングインターフェイス（application programming interface：ＡＰＩ）を提供する。

ＨＢａｓｅデータストアにおけるすべての行は、キーを有する。ＨＢａｓｅデータストアにおけるすべての列は、特定の列ファミリーに属する。各列ファミリーは、１つ以上の修飾子からなる。このため、ＨＢａｓｅデータストアからそのデータを検索するために、
行キー、列ファミリー、および列修飾子の組合せが使用される。ＨＢａｓｅデータストアでは、すべてのテーブルは、リレーショナルデータベースにおけるすべてのテーブルが行キーを有する方法と同様に、行キーを有する。

図１は、いくつかの実施形態に従った、ＨＢａｓｅデータストアにおけるテーブル１００の一例を示す図である。テーブル１００は列１０２〜１１０を含む。列１０２は行キーを格納する。列１０４は名前を格納する。列１０６は性別を格納する。列１０８はデータベースクラスについての等級を格納する。列１１０はアルゴリズムクラスについての等級を格納する。テーブル１００についての列修飾子は、名前、性別、データベース、およびアルゴリズムという列１０２〜１１０の名称を表わす。

テーブル１００は、２つの列ファミリー１１２および１１４を伴う。列ファミリー１１２は、列１０４および１０６を含む。この例では、列ファミリー１１２は「基本情報」と名付けられる。列ファミリー１１４は、列１０８および１１０を含む。この例では、列ファミリー１１４は「クラス等級」と名付けられる。

ＨＢａｓｅ列修飾子の概念は、ＮｏＳｑｌＤＢにおけるマイナーキーの概念と同様である。たとえば、ＮｏＳｑｌＤＢでは、記録のためのメジャーキーは、人の名前であってもよい。マイナーキーは、その人のために格納されるであろう異なる情報であってもよい。たとえば、メジャーキーが「/Bob/Smith」の場合、対応するマイナーキーは「birth date」、「city」、および「state」を含んでいてもよい。別の例として、メジャーキーが「/John/Snow」の場合、対応するマイナーキーは同様に「birth date」、「city」、および
「state」を含んでいてもよい。

ＨＢａｓｅデータストアに含まれる情報は、どのクエリ言語も使用しても検索されない。ＨＢａｓｅの背後の目的は、複雑なデータ検索動作を何ら行なうことなく、大量のデータを効率的に格納することである。上述のように、ＨＢａｓｅでは、データはＪＡＶＡ ＡＰＩを使用して検索される。以下のコード断片は、データをどのようにＨＢａｓｅに格納し、検索することができるかという考えを与える：

ＨＢａｓｅは、さまざまなアプリケーションのためのメタデータ情報を格納するために使用されてもよい。たとえば、会社は、さまざまなセールスに関連付けられた顧客情報をＨＢａｓｅデータベースに格納してもよい。その場合、ＨＢａｓｅデータベースは、ＨＢａｓｅを外部データソースとして使用してＣＱＬクエリの書込みを有効にしたＨＢａｓｅカートリッジを使用してもよい。

いくつかの実施形態によれば、ＣＱＬプロセッサを使用して、ソースイベントは、ＨＢａｓｅデータストアに含まれる文脈データで充実化される。ＨＢａｓｅデータストアは、抽象形態を通して参照される。

いくつかの実施形態によれば、ＨＢａｓｅデータストアを表わすために、イベント処理ネットワーク（イベント処理ネットワーク）コンポーネントが作成される。ＨＢａｓｅデータストアイベント処理ネットワークコンポーネントは、イベント処理ネットワーク＜table＞コンポーネントに似ており、ＣＱＬプロセッサにおいて外部リレーショナルソース
として使用される。ＨＢａｓｅデータストアイベント処理ネットワークコンポーネントは、イベントタイプを使用して型付けされる。ＨＢａｓｅデータベースは、それ自体のメカニズムを通して開始され、アクセス可能である。ＨＢａｓｅデータベースは、オラクル・イベント・プロセッサ（Oracle Event Processor：ＯＥＰ）などのイベントプロセッサによって直接管理される必要はない。

いくつかの実施形態によれば、ＨＢａｓｅデータストアイベント処理ネットワークコンポーネントは、データカートリッジとして提供される。ＨＢａｓｅデータカートリッジは、イベント処理ネットワークコンポーネントのｉｄ、store-location（ドメインの形をした場所：ＨＢａｓｅデータベースサーバのポート）、event-type（ＣＱＬプロセッサによって見られるようなストアのためのスキーマ）、table-name（ＨＢａｓｅテーブルの名称）というプロパティを、＜store＞イベント処理ネットワークコンポーネントに提供する
。

いくつかの実施形態によれば、このイベント処理ネットワークコンポーネントは、ＣＱＬイベント属性からＨＢａｓｅ列ファミリー／修飾子へのマッピングを特定するために、関連する＜column-mappings＞コンポーネントを有する。このコンポーネントは、ＪＡＶ
Ａデータベース接続性（JAVA Database Connectivity：ＪＤＢＣ）カートリッジ構成と同様のＨＢａｓｅカートリッジ構成ファイルで宣言される。このコンポーネントは、name（マッピングが宣言されている＜store＞イベント処理ネットワークコンポーネントのｉｄ
）、rowkey（ＨＢａｓｅテーブルの行キー）、cql-attribute（ＣＱＬクエリで使用され
るＣＱＬ列名）、hbase-family（ＨＢａｓｅ列ファミリー）、およびhbase-qualifer（ＨＢａｓｅ列修飾子）というプロパティを有する。いくつかの実施形態によれば、ＣＱＬ列がjava.util.mapである場合、ユーザは「hbase-family」のみを特定する。いくつかの実
施形態によれば、ＣＱＬ列が基本データ型である場合、ユーザは「hbase-family」および「hbase-qualifier」の双方を特定する。

いくつかの実施形態によれば、＜hbase:store＞コンポーネントは、以下の例でのよう
に、「table-source」要素を使用してＣＱＬプロセッサにリンクされる：

いくつかの実施形態によれば、この＜hbase:store＞コンポーネントのための列マッピ
ングは、以下の例でのように、イベントプロセッサ（たとえばＯＥＰ）のＨＢａｓｅ構成
ファイルで特定される：

いくつかの実施形態によれば、UserEventクラスは、以下のフィールドを有する：

上述の例では、ＣＱＬ列「address」は、列ファミリー「address」からのすべての列修飾子を保持するため、マップである。ＣＱＬ列「firstname」、「lastname」、「email」、および「role」は、基本データ型を保持する。これらは、「data」列ファミリーからの特定の列修飾子である。イベントタイプからの「userName」フィールドは行キーであり、よって、それは、ＨＢａｓｅ列ファミリーまたは修飾子へのマッピングを何ら有していない。

いくつかの実施形態によれば、ＨＢａｓｅスキーマは動的な性質であってもよく、追加の列ファミリーおよび／または列修飾子が、ＨＢａｓｅテーブルが作成された後の任意の時点で追加されてもよい。よって、イベントプロセッサ（たとえばＯＥＰ）は、ユーザが、動的に追加された列修飾子をすべて含むマップとしてイベントフィールドを検索することを可能にする。この場合、ユーザは、ＪＡＶＡイベントタイプにおけるイベントフィー
ルドのうちの１つとしてjava.util.Mapを宣言する。よって、上述の「UserEvent」イベントタイプは、名称「address」を有するjava.util.Mapフィールドを有する。動的に追加された列ファミリーをカートリッジがサポートしない場合、イベント処理アプリケーションが新しく追加された列ファミリーを使用する必要があれば、イベントタイプは修正され得る。

いくつかの実施形態によれば、ＨＢａｓｅデータベースはクラスタとして実行される。そのようなシナリオでは、マスターノードのホスト名は上述の構成で提供される。

いくつかの実施形態によれば、ＨＢａｓｅソースの構成中、イベントタイプリポジトリに存在するイベントタイプの名称が、ユーザから受信される。「column-mappings」がユ
ーザから受信されている場合、ユーザインターフェイスは、その特定のイベントタイプにおける列（フィールド）名をcql-columnとして提供することができる。このため、間違った入力は、ユーザインターフェイスレベルで排除され得る。利用可能なＨＢａｓｅ列ファミリーおよびそれらの内部の列修飾子の詳細が、ユーザがそれらから選択するために提供され得る。構文解析ツールの確認が、カートリッジにおいて行なわれる。

顧客セールス例
以下の例は、大口セールスおよび関連付けられた顧客を識別する。セールスデータは入来ストリームにおいて取得され、顧客情報はＨＢａｓｅデータベースから取得される：

以下の列マッピングが、ＨＢａｓｅカートリッジ構成ファイルで特定される：

上述の例における「User」ＨＢａｓｅテーブルは、以下のスキーマを有する：
行キー：username
列ファミリー：data,address
「data」列ファミリーについての列修飾子：firstname,lastname,email,role
「address」列ファミリーについての列修飾子：country,state,city,street
プロセッサは、入力ストリームをこのテーブルと結合する以下のＣＱＬクエリを実行する：

ここで、「address」列ファミリーは、「com.bea.wlevs.example.UserEvent」クラスにおける「java.util.Map」フィールドとして宣言された。よって、この列ファミリーから
特定の列修飾子の値を検索するために、「user.address.get('<column-qualifer-name>')」が使用される。

ＯｐｅｎＴＳＢＤ監視システムのためのＨａｓｅ基本
いくつかの実施形態は、行キー、列ファミリー、列修飾子、および複数のバージョンというマップのマップを伴い得る。行は、複数の列ファミリーを含んでいてもよい。しかしながら、各ファミリーは、一緒に扱われる（たとえば、圧縮／解凍される）。列ファミリーは、複数の列修飾子を含んでいてもよい。列修飾子は、動的に追加または除去され得る。各セルは複数のバージョンを有し、デフォルトで、直近のバージョンが検索される。列ファミリーに関連付けられたポリシーが、バージョンがいくつ保たれるか、およびそれらがいつパージされるかを判断する。

いくつかの実施形態は、スキーマレスおよびタイプレスである。ＡＰＩは、get、put、delete、scan、およびincrementを含み得る。非キーについて問合せることは、リッチフ
ィルタリング言語をサポートする、フィルタリングされたスキャンを使用して行なわれる。

ＯｐｅｎＴＳＢＤ監視システムのためのスキーマ
いくつかの実施形態は、以下のようなＵＩＤテーブルを伴い得る：

いくつかの実施形態は、以下のようなメトリクステーブルを伴い得る：

ＯｐｅｎＴＳＢＤ監視システムのためのクエリ
いくつかの実施形態によれば、ＣＱＬの観点から、外部関係がＨＢａｓｅテーブルソー
スにマッピングする。ＨＢａｓｅテーブルソースを構成する際、外部関係のどの属性がＨＢａｓｅにおけるどの列ファミリーまたは列ファミリー．列修飾子にマッピングするかについての詳細を、ユーザから受信することができる。

いくつかの実施形態によれば、メトリック名からＵＩＤを見つけることができる。ＣＱＬクエリは以下のように見え得る：

ここで、「metrics」は、UID_TABLEという名称のＨＢａｓｅテーブルの「name」列ファミリーにおける「metrics」列修飾子にマッピングする、UID_TABLEという名称の外部関係の属性である。加えて、「rowkey」は、ＨＢａｓｅテーブルの行キーにマッピングする外部関係の別の属性である。

いくつかの実施形態によれば、cpuで始まるメトリック名はすべて、以下のようなクエ
リを使用して見つけることができる：

ここで、整合させるべき正規表現を表わす文字列が特定される。この文字列は、ストリームＳの属性であってもよいが、ストリームＳの属性でなくてもよい。そのような正規表現ベースの問合せは、ＨＢａｓｅ ＡＰＩを使用してサポートされ得る。ＨＢａｓｅでは、行は、包括的開始および排他的終了を特定することによってスキャンされる。

いくつかの実施形態によれば、以下のような同様の手法が使用される：

いくつかの実施形態は、http://hbase.apache.org/apidocs/org/apache/hadoop/hbase/filter/RegexStringComparator.htmlを利用する。

いくつかの実施形態によれば、外部関係のために、述語サポート能力が特定される。所与の述語がサポートされた述語能力リストに該当する場合、それは外部関係に対して実行される。他の場合、データのすべてがメモリに入れられ、次に、ＣＱＬエンジンがその述語を適用する。

いくつかの実施形態によれば、ホストによってフィルタリングされるサービス待ち時間メトリックのための措置を見つけることができる。この場合、ＣＱＬは以下の通りである：

上述の例では、「rowkey」、「host」、および「measures」は、ＨＢａｓｅテーブルソースにマッピングする外部関係の列であり、key-encodingは、ユーザ定義関数である。

いくつかの実施形態によれば、サービス待ち時間が１０００（ミリ秒）を超えるホストの領域を見つけることができる。列修飾子を既存の行に動的に追加することができる。たとえば、ホストがデプロイメントされている領域を含む、新しい列修飾子「region」を追加することができる。属性「host」を確認するためのメタデータが利用できない場合、以下のアプローチを使用することができる。hbase:column-mappingsにおいて、ユーザは以
下を特定することができる：

ここで、「cf1」は列ファミリー名、ｃ１はタイプjava.util.Mapである。ユーザは、c1.get("qualifier-name")として「cf1」における修飾子にアクセスすることができる。し
たがって、ＣＱＬクエリは以下のように見え得る：

ここで、「info」は、「region」修飾子が動的に追加される列ファミリーにマッピングする外部関係の属性の名称である。

措置は、複数のバージョンを有していてもよい。いくつかの実施形態によれば、何らかのアプリケーションタイムスタンプが直近のバージョンよりも古い場合、以前のバージョンが取得される。いくつかの実施形態によれば、直近のバージョンが使用される。以下のような、トランザクション指向の使用事例が存在するかもしれない：

言い換えれば、価格は変化したかもしれないが、トランザクションが発信された際に見られたような価格は依然として、そのアプリケーションタイムスタンプを考慮して受取られるであろう。

ハードウェア概要
図１６は、実施形態のうちの１つを実現するための分散型システム１６００の簡略図を示す。図示された実施形態では、分散型システム１６００は１つ以上のクライアントコンピューティング装置１６０２、１６０４、１６０６、および１６０８を含み、それらは、１つ以上のネットワーク１６１０を通して、ウェブブラウザ、専用クライアント（たとえば、オラクル・フォームズ（Oracle Forms））などのクライアントアプリケーションを実行し、動作させるように構成される。サーバ１６１２は、ネットワーク１６１０を介して、リモートクライアントコンピューティング装置１６０２、１６０４、１６０６、および１６０８と通信可能に結合されてもよい。

さまざまな実施形態では、サーバ１６１２は、システムのコンポーネントのうちの１つ以上によって提供される１つ以上のサービスまたはソフトウェアアプリケーションを実行するように適合されてもよい。いくつかの実施形態では、これらのサービスは、ウェブベースのサービスまたはクラウドサービスとして、もしくはソフトウェア・アズ・ア・サービス（Software as a Service：ＳａａＳ）モデルの下で、クライアントコンピューティ
ング装置１６０２、１６０４、１６０６、および／または１６０８のユーザに提供されてもよい。クライアントコンピューティング装置１６０２、１６０４、１６０６、および／または１６０８を動作させるユーザは次に、これらのコンポーネントによって提供されるサービスを利用するためにサーバ１６１２とやりとりするために、１つ以上のクライアントアプリケーションを利用してもよい。

図に示す構成では、システム１６００のソフトウェアコンポーネント１６１８、１６２０および１６２２は、サーバ１６１２上で実現されるとして図示されている。他の実施形態では、システム１６００のコンポーネントおよび／またはこれらのコンポーネントによって提供されるサービスのうちの１つ以上も、クライアントコンピューティング装置１６０２、１６０４、１６０６、および／または１６０８のうちの１つ以上によって実現されてもよい。クライアントコンピューティング装置を動作させるユーザは次に、これらのコンポーネントによって提供されるサービスを使用するために、１つ以上のクライアントアプリケーションを利用してもよい。これらのコンポーネントは、ハードウェア、ファームウェア、ソフトウェア、またはそれらの組合せで実現されてもよい。分散型システム１６００とは異なり得るさまざまな異なるシステム構成が可能であることが理解されるべきである。図に示す実施形態はこのため、実施形態システムを実現するための分散型システムの一例であり、限定的であるよう意図されてはいない。

クライアントコンピューティング装置１６０２、１６０４、１６０６、および／または１６０８は、携帯型ハンドヘルド装置（たとえば、ｉＰｈｏｎｅ（登録商標）、携帯電話、ｉＰａｄ（登録商標）、コンピューティングタブレット、携帯情報端末（ＰＤＡ））、またはウェアラブル装置（たとえば、グーグル・グラス（Google Glass）（登録商標）頭部装着型ディスプレイ）であってもよく、マイクロソフト・ウィンドウズ・モバイル（Microsoft Windows Mobile）（登録商標）などのソフトウェア、および／または、ｉＯＳ、ウィンドウズ（登録商標）フォン、アンドロイド（登録商標）、ブラックベリー（登録商標）１７、パームＯＳなどのさまざまなモバイルオペレーティングシステムを実行し、インターネット、電子メール、ショートメッセージサービス（short message service：Ｓ
ＭＳ）、ブラックベリー（登録商標）、または他の通信プロトコルに対応している。クライアントコンピューティング装置は、マイクロソフト・ウィンドウズ（登録商標）、アップル・マッキントッシュ（登録商標）、および／またはＬｉｎｕｘ（登録商標）オペレーティングシステムのさまざまなバージョンを実行するパーソナルコンピュータおよび／またはラップトップコンピュータを例として含む、汎用パーソナルコンピュータであり得る。クライアントコンピューティング装置は、たとえばグーグル・クロームＯＳなどのさまざまなＧＮＵ／Ｌｉｎｕｘオペレーティングシステムを何ら限定されることなく含む、商業的に入手可能なさまざまなＵＮＩＸ（登録商標）またはＵＮＩＸ様オペレーティングシ
ステムのうちのいずれかを実行するワークステーションコンピュータであり得る。それに代えて、またはそれに加えて、クライアントコンピューティング装置１６０２、１６０４、１６０６、および１６０８は、ネットワーク１６１０を通して通信可能である、シンクライアントコンピュータ、インターネット対応ゲーミングシステム（たとえば、Ｋｉｎｅｃｔ（登録商標）ジェスチャー入力装置を有する、または有さない、マイクロソフトＸｂｏｘゲーミングコンソール）、および／またはパーソナルメッセージング装置といった、任意の他の電子装置であってもよい。

例示的な分散型システム１６００は４つのクライアントコンピューティング装置を有して図示されているが、任意の数のクライアントコンピューティング装置がサポートされてもよい。センサを有する装置などの他の装置が、サーバ１６１２とやりとりしてもよい。

分散型システム１６００におけるネットワーク１６１０は、ＴＣＰ／ＩＰ（transmission control protocol/Internet protocol：伝送制御プロトコル／インターネットプロト
コル）、ＳＮＡ（systems network architecture：システムネットワークアーキテクチャ）、ＩＰＸ（Internet packet exchange：インターネットパケット交換）、アップル・トーク（Apple Talk）などを何ら限定されることなく含む、商業的に入手可能なさまざまなプロトコルのうちのいずれかを使用してデータ通信をサポートできる、当業者にはよく知られた任意のタイプのネットワークであってもよい。単なる例として、ネットワーク１６１０は、イーサネット（登録商標）、トークンリング（Token-Ring）などに基づくものといった、ローカルエリアネットワーク（local area network：ＬＡＮ）であり得る。ネットワーク１６１０は、ワイドエリアネットワークおよびインターネットであり得る。それは、仮想プライベートネットワーク（virtual private network：ＶＰＮ）を何ら限定さ
れることなく含む仮想ネットワーク、イントラネット、エクストラネット、公衆交換電話網（public switched telephone network：ＰＳＴＮ）、赤外線ネットワーク、無線ネッ
トワーク（たとえば、電気電子技術者協会（the Institute of Electrical and Electronics：ＩＥＥＥ）１６０２．１１プロトコルスイート、Bluetooth（登録商標）、および／または任意の他の無線プロトコルのうちのいずれかの下で動作するネットワーク）、ならびに／もしくは、これらのおよび／または他のネットワークの任意の組合せを含み得る。

サーバ１６１２は、１つ以上の汎用コンピュータ、専用サーバコンピュータ（ＰＣ（パーソナルコンピュータ）サーバ、ＵＮＩＸ（登録商標）サーバ、ミッドレンジサーバ、メインフレームコンピュータ、ラックマウントサーバなどを例として含む）、サーバファーム、サーバクラスタ、もしくは任意の他の適切な構成および／または組合せで構成されてもよい。さまざまな実施形態では、サーバ１６１２は、前述の開示で説明された１つ以上のサービスまたはソフトウェアアプリケーションを実行するように適合されてもよい。たとえば、サーバ１６１２は、この開示の一実施形態に従った上述の処理を行なうためのサーバに対応していてもよい。

サーバ１６１２は、上述のもののうちのいずれかを含むオペレーティングシステム、および商業的に入手可能な任意のサーバオペレーティングシステムを実行してもよい。サーバ１６１２はまた、さまざまな追加のサーバアプリケーションおよび／または中間層アプリケーションのうちのいずれかを実行してもよく、ＨＴＴＰ（hypertext transport protocol：ハイパーテキスト伝送プロトコル）サーバ、ＦＴＰ（file transfer protocol：ファイル転送プロトコル）サーバ、ＣＧＩ（common gateway interface：コモンゲートウェイインターフェイス）サーバ、ＪＡＶＡ（登録商標）サーバ、データベースサーバなどを含む。例示的なデータベースサーバは、オラクル、マイクロソフト、サイベース（Sybase）、ＩＢＭ（International Business Machines：インターナショナル・ビジネス・マシ
ーンズ）などから商業的に入手可能なものを何ら限定されることなく含む。

いくつかの実現化例では、サーバ１６１２は、クライアントコンピューティング装置１６０２、１６０４、１６０６、および１６０８のユーザから受信されたデータフィードおよび／またはイベント更新を分析して統合するための１つ以上のアプリケーションを含んでいてもよい。一例として、データフィードおよび／またはイベント更新は、センサデータアプリケーション、金融ティッカー、ネットワーク性能測定ツール（たとえば、ネットワーク監視およびトラフィック管理アプリケーション）、クリックストリーム分析ツール、自動車交通監視などに関連するリアルタイムイベントを含み得る、１つ以上の第三者情報源および連続データストリームから受信されたツイッター（登録商標）フィード、フェースブック（登録商標）更新またはリアルタイム更新を含んでいてもよいが、それらに限定されない。サーバ１６１２はまた、クライアントコンピューティング装置１６０２、１６０４、１６０６、および１６０８の１つ以上の表示装置を介してデータフィードおよび／またはリアルタイムイベントを表示するための１つ以上のアプリケーションを含んでいてもよい。

分散型システム１６００はまた、１つ以上のデータベース１６１４および１６１６を含んでいてもよい。データベース１６１４および１６１６は、さまざまな位置に存在していてもよい。例として、データベース１６１４および１６１６のうちの１つ以上は、サーバ１６１２に対してローカルな（および／または、サーバ１６１２内にある）非一時的記憶媒体上に存在していてもよい。それに代えて、データベース１６１４および１６１６は、サーバ１６１２からリモートであってもよく、ネットワークベースの接続または専用接続を介してサーバ１６１２と通信してもよい。一組の実施形態では、データベース１６１４および１６１６は、ストレージエリアネットワーク（storage-area network：ＳＡＮ）に存在していてもよい。同様に、サーバ１６１２に帰する機能を行なうための任意の必要なファイルが適宜、サーバ１６１２上にローカルに格納されてもよく、および／またはリモートに格納されてもよい。一組の実施形態では、データベース１６１４および１６１６は、ＳＱＬフォーマットのコマンドに応答してデータを格納し、更新し、検索するように適合された、オラクルによって提供されるデータベースなどのリレーショナルデータベースを含んでいてもよい。

図１７は、この開示の一実施形態に従った、実施形態システムの１つ以上のコンポーネントによって提供されるサービスをクラウドサービスとして提供し得るシステム環境１７００の１つ以上のコンポーネントの簡略ブロック図である。図示された実施形態では、システム環境１７００は、クラウドサービスを提供するクラウドインフラストラクチャシステム１７０２とやりとりするためにユーザによって使用され得る１つ以上のクライアントコンピューティング装置１７０４、１７０６、および１７０８を含む。クライアントコンピューティング装置は、クラウドインフラストラクチャシステム１７０２によって提供されるサービスを使用するためにクラウドインフラストラクチャシステム１７０２とやりとりするためにクライアントコンピューティング装置のユーザによって使用され得る、ウェブブラウザ、専用クライアントアプリケーション（たとえば、オラクル・フォームズ）、または何らかの他のアプリケーションといったクライアントアプリケーションを動作させるように構成されてもよい。

図に示すクラウドインフラストラクチャシステム１７０２は、図示されたもの以外のコンポーネントを有していてもよい、ということが理解されるべきである。また、図に示す実施形態は、この発明の一実施形態を取入れ得るクラウドインフラストラクチャシステムの単なる一例である。いくつかの他の実施形態では、クラウドインフラストラクチャシステム１７０２は、図に示すものよりも多い、または少ないコンポーネントを有していてもよく、２つ以上のコンポーネントを組合せてもよく、もしくは、異なる構成または配置のコンポーネントを有していてもよい。

クライアントコンピューティング装置１７０４、１７０６、および１７０８は、１６０２、１６０４、１６０６、および１６０８について上述したものと同様の装置であってもよい。

例示的なシステム環境１７００は３つのクライアントコンピューティング装置を有して図示されているが、任意の数のクライアントコンピューティング装置がサポートされてもよい。センサを有する装置などの他の装置が、クラウドインフラストラクチャシステム１７０２とやりとりしてもよい。

ネットワーク１７１０は、クライアント１７０４、１７０６、および１７０８とクラウドインフラストラクチャシステム１７０２との間のデータの通信および交換を容易にしてもよい。各ネットワークは、ネットワーク１６１０について上述したものを含む、商業的に入手可能なさまざまなプロトコルのうちのいずれかを使用してデータ通信をサポートできる、当業者にはよく知られた任意のタイプのネットワークであってもよい。

クラウドインフラストラクチャシステム１７０２は、サーバ１６１２について上述したものを含み得る１つ以上のコンピュータおよび／またはサーバを含んでいてもよい。

ある実施形態では、クラウドインフラストラクチャシステムによって提供されるサービスは、オンラインデータストレージおよびバックアップソリューション、ウェブベースの電子メールサービス、ホスト型オフィススイートおよび文書コラボレーションサービス、データベース処理、管理された技術サポートサービスといった、クラウドインフラストラクチャシステムのユーザにとってオンデマンドで利用可能にされる多数のサービスを含んでいてもよい。クラウドインフラストラクチャシステムによって提供されるサービスは、そのユーザの必要性を満たすために動的にスケール変更され得る。クラウドインフラストラクチャシステムによって提供されるサービスの特定のインスタンス化は、ここに「サービスインスタンス」と呼ばれる。一般に、クラウドサービスプロバイダのシステムから、インターネットなどの通信ネットワークを介してユーザに利用可能とされる任意のサービスは、「クラウドサービス」と呼ばれる。典型的には、パブリッククラウド環境では、クラウドサービスプロバイダのシステムを作り上げるサーバおよびシステムは、顧客自身の業務用サーバおよびシステムとは異なっている。たとえば、クラウドサービスプロバイダのシステムは、アプリケーションをホストしてもよく、ユーザは、インターネットなどの通信ネットワークを介してオンデマンドでアプリケーションをオーダーし、使用してもよい。

いくつかの例では、コンピュータネットワーククラウドインフラストラクチャにおけるサービスは、クラウドベンダーによってユーザに提供されるかまたは当該技術分野において他の態様で公知であるようなストレージ、ホスト型データベース、ホスト型ウェブサーバ、ソフトウェアアプリケーション、もしくは他のサービスへの、保護されたコンピュータネットワークアクセスを含んでいてもよい。たとえば、サービスは、インターネットを通した、クラウド上のリモートストレージへの、パスワードで保護されたアクセスを含み得る。別の例として、サービスは、ネットワーク化された開発者による私的使用のための、ウェブサービスベースのホスト型リレーショナルデータベースおよびスクリプト言語ミドルウェアエンジンを含み得る。別の例として、サービスは、クラウドベンダーのウェブサイト上でホストされる電子メールソフトウェアアプリケーションへのアクセスを含み得る。

ある実施形態では、クラウドインフラストラクチャシステム１７０２は、セルフサービスで、サブスクリプションベースで、弾力的にスケーラブルで、信頼でき、高可用性で、かつ安全な態様で顧客に配信される、アプリケーション、ミドルウェアおよびデータベー
スサービス提供物一式を含んでいてもよい。そのようなクラウドインフラストラクチャシステムの一例は、本譲受人によって提供されるオラクル・パブリック・クラウド（Oracle
Public Cloud）である。

さまざまな実施形態では、クラウドインフラストラクチャシステム１７０２は、クラウドインフラストラクチャシステム１７０２によって提供されるサービスに顧客のサブスクリプションを自動的にプロビジョニングし、管理し、追跡するように適合されてもよい。クラウドインフラストラクチャシステム１７０２は、異なるデプロイメントモデルを介してクラウドサービスを提供してもよい。たとえば、サービスは、クラウドインフラストラクチャシステム１７０２がクラウドサービスを販売する組織によって所有され（たとえば、オラクルによって所有され）、サービスが一般大衆または異なる産業企業にとって利用可能とされる、パブリッククラウドモデルの下で提供されてもよい。別の例として、サービスは、クラウドインフラストラクチャシステム１７０２が単一の組織のためにのみ動作され、その組織内の１つ以上のエンティティのためのサービスを提供し得る、プライベートクラウドモデルの下で提供されてもよい。クラウドサービスはまた、クラウドインフラストラクチャシステム１７０２、およびクラウドインフラストラクチャシステム１７０２によって提供されるサービスが、関連するコミュニティにおけるいくつかの組織によって共有される、コミュニティクラウドモデルの下で提供されてもよい。クラウドサービスはまた、２つ以上の異なるモデルの組合せであるハイブリッドクラウドモデルの下で提供されてもよい。

いくつかの実施形態では、クラウドインフラストラクチャシステム１７０２によって提供されるサービスは、ソフトウェア・アズ・ア・サービス（ＳａａＳ）カテゴリー、プラットフォーム・アズ・ア・サービス（Platform as a Service：ＰａａＳ）カテゴリー、
インフラストラクチャ・アズ・ア・サービス（Infrastructure as a Service：ＩａａＳ
）カテゴリー、または、ハイブリッドサービスを含むサービスの他のカテゴリーの下で提供される、１つ以上のサービスを含んでいてもよい。顧客は、クラウドインフラストラクチャシステム１７０２によって提供される１つ以上のサービスを、サブスクリプションオーダーを介してオーダーしてもよい。クラウドインフラストラクチャシステム１７０２は次に、顧客のサブスクリプションオーダーにおけるサービスを提供するために処理を行なう。

いくつかの実施形態では、クラウドインフラストラクチャシステム１７０２によって提供されるサービスは、アプリケーションサービス、プラットフォームサービス、およびインフラストラクチャサービスを、何ら限定されることなく含んでいてもよい。いくつかの例では、アプリケーションサービスは、ＳａａＳプラットフォームを介して、クラウドインフラストラクチャシステムによって提供されてもよい。ＳａａＳプラットフォームは、ＳａａＳカテゴリーに該当するクラウドサービスを提供するように構成されてもよい。たとえば、ＳａａＳプラットフォームは、統合された開発およびデプロイメントプラットフォーム上にオンデマンドアプリケーション一式を構築し、配信するための能力を提供してもよい。ＳａａＳプラットフォームは、ＳａａＳサービスを提供するための基本ソフトウェアおよびインフラストラクチャを管理し、制御してもよい。ＳａａＳプラットフォームによって提供されるサービスを利用することにより、顧客は、クラウドインフラストラクチャシステム上で実行されるアプリケーションを利用できる。顧客は、顧客が別々のライセンスおよびサポートを購入する必要なく、アプリケーションサービスを取得できる。さまざまな異なるＳａａＳサービスが提供されてもよい。例は、大型組織のための販売実績管理、企業統合、およびビジネス柔軟性についてのソリューションを提供するサービスを、何ら限定されることなく含む。

いくつかの実施形態では、プラットフォームサービスは、ＰａａＳプラットフォームを
介して、クラウドインフラストラクチャシステムによって提供されてもよい。ＰａａＳプラットフォームは、ＰａａＳカテゴリーに該当するクラウドサービスを提供するように構成されてもよい。プラットフォームサービスの例は、（オラクルなどの）組織が共有の共通アーキテクチャ上で既存のアプリケーションを統合できるようにするサービスと、プラットフォームによって提供される共有のサービスを活用する新しいアプリケーションを構築するための能力とを、何ら限定されることなく含んでいてもよい。ＰａａＳプラットフォームは、ＰａａＳサービスを提供するための基本ソフトウェアおよびインフラストラクチャを管理し、制御してもよい。顧客は、顧客が別々のライセンスおよびサポートを購入する必要なく、クラウドインフラストラクチャシステムによって提供されるＰａａＳサービスを取得できる。プラットフォームサービスの例は、オラクルＪａｖａ（登録商標）クラウドサービス（Java Cloud Service：ＪＣＳ）、オラクル・データベース・クラウド・サービス（Database Cloud Service：ＤＢＣＳ）などを、何ら限定されることなく含む。

ＰａａＳプラットフォームによって提供されるサービスを利用することにより、顧客は、クラウドインフラストラクチャシステムによってサポートされるプログラミング言語およびツールを採用するとともに、デプロイメントされたサービスを制御することができる。いくつかの実施形態では、クラウドインフラストラクチャシステムによって提供されるプラットフォームサービスは、データベースクラウドサービス、ミドルウェアクラウドサービス（たとえば、オラクル・フュージョン・ミドルウェア（Oracle Fusion Middleware）サービス）、およびＪａｖａクラウドサービスを含んでいてもよい。一実施形態では、データベースクラウドサービスは、組織がデータベースリソースをプールし、データベースクラウドの形をしたデータベース・アズ・ア・サービスを顧客に提供することを可能にする共有のサービスデプロイメントモデルをサポートしてもよい。ミドルウェアクラウドサービスは、顧客がさまざまなビジネスアプリケーションを開発してデプロイメントするためのプラットフォームを提供してもよく、Ｊａｖａクラウドサービスは、顧客がクラウドインフラストラクチャシステムにおいてＪａｖａアプリケーションをデプロイメントするためのプラットフォームを提供してもよい。

クラウドインフラストラクチャシステムにおいて、さまざまな異なるインフラストラクチャサービスが、ＩａａＳプラットフォームによって提供されてもよい。これらのインフラストラクチャサービスは、ＳａａＳプラットフォームおよびＰａａＳプラットフォームによって提供されるサービスを利用する顧客のための、ストレージ、ネットワーク、ならびに他の基礎的コンピューティングリソースなどの基本コンピューティングリソースの管理および制御を容易にする。

ある実施形態では、クラウドインフラストラクチャシステム１７０２はまた、クラウドインフラストラクチャシステムの顧客にさまざまなサービスを提供するために使用されるリソースを提供するためのインフラストラクチャリソース１７３０を含んでいてもよい。一実施形態では、インフラストラクチャリソース１７３０は、ＰａａＳプラットフォームおよびＳａａＳプラットフォームによって提供されるサービスを実行するために、サーバ、ストレージ、およびネットワーキングリソースなどのハードウェアの予め統合され最適化された組合せを含んでいてもよい。

いくつかの実施形態では、クラウドインフラストラクチャシステム１７０２におけるリソースは、複数のユーザによって共有され、要望ごとに動的に再割当てされてもよい。加えて、リソースは、異なる時間帯におけるユーザに割当てられてもよい。たとえば、クラウドインフラストラクチャシステム１７３０は、第１の時間帯における第１の一組のユーザが、特定数の時間、クラウドインフラストラクチャシステムのリソースを利用することを可能にし、次に、異なる時間帯に位置する別の一組のユーザへの同じリソースの再割当てを可能にして、それによりリソースの利用を最大化してもよい。

ある実施形態では、クラウドインフラストラクチャシステム１７０２の異なるコンポーネントまたはモジュールによって、およびクラウドインフラストラクチャシステム１７０２によって提供されるサービスによって共有される、多くの内部共有サービス１７３２が提供されてもよい。これらの内部共有サービスは、セキュリティおよびアイデンティティサービス、統合サービス、企業リポジトリサービス、企業マネージャサービス、ウィルススキャニングおよびホワイトリストサービス、高可用性、バックアップおよび復元サービス、クラウドサポートを可能にするためのサービス、電子メールサービス、通知サービス、ファイル転送サービスなどを、何ら限定されることなく含んでいてもよい。

ある実施形態では、クラウドインフラストラクチャシステム１７０２は、クラウドインフラストラクチャシステムにおけるクラウドサービス（たとえば、ＳａａＳ、ＰａａＳ、およびＩａａＳサービス）の包括的管理を提供してもよい。一実施形態では、クラウド管理機能性は、クラウドインフラストラクチャシステム１７０２によって受信された顧客のサブスクリプションをプロビジョニングし、管理し、追跡するための能力などを含んでいてもよい。

一実施形態では、図に示すように、クラウド管理機能性は、オーダー管理モジュール１７２０、オーダーオーケストレーションモジュール１７２２、オーダープロビジョニングモジュール１７２４、オーダー管理および監視モジュール１７２６、ならびにアイデンティティ管理モジュール１７２８などの１つ以上のモジュールによって提供されてもよい。これらのモジュールは、汎用コンピュータ、専用サーバコンピュータ、サーバファーム、サーバクラスタ、もしくは任意の他の適切な構成および／または組合せであり得る、１つ以上のコンピュータおよび／またはサーバを含んでいてもよく、もしくはそれらを使用して提供されてもよい。

例示的な動作１７３４では、クライアント装置１７０４、１７０６または１７０８などのクライアント装置を使用する顧客は、クラウドインフラストラクチャシステム１７０２によって提供される１つ以上のサービスを要求し、クラウドインフラストラクチャシステム１７０２によって提供される１つ以上のサービスについてサブスクリプションオーダーを出すことにより、クラウドインフラストラクチャシステム１７０２とやりとりしてもよい。ある実施形態では、顧客は、クラウドユーザインターフェイス（User Interface：ＵＩ）であるクラウドＵＩ１７１２、クラウドＵＩ１７１４および／またはクラウドＵＩ１７１６にアクセスし、これらのＵＩを介してサブスクリプションオーダーを出してもよい。顧客がオーダーを出したことに応答してクラウドインフラストラクチャシステム１７０２が受信したオーダー情報は、顧客と、顧客が申し込むつもりである、クラウドインフラストラクチャシステム１７０２によって提供される１つ以上のサービスとを識別する情報を含んでいてもよい。

顧客によってオーダーが出された後で、オーダー情報がクラウドＵＩ１７１２、１７１４および／または１７１６を介して受信される。

動作１７３６で、オーダーがオーダーデータベース１７１８に格納される。オーダーデータベース１７１８は、クラウドインフラストラクチャシステム１７０２によって動作され、他のシステム要素とともに動作される、いくつかのデータベースのうちの１つであり得る。

動作１７３８で、オーダー情報はオーダー管理モジュール１７２０に発送される。場合によっては、オーダー管理モジュール１７２０は、オーダーを検証し、検証後にオーダーを予約するといった、オーダーに関連する請求および課金機能を行なうように構成されて
もよい。

動作１７４０で、オーダーに関する情報がオーダーオーケストレーションモジュール１７２２に通信される。オーダーオーケストレーションモジュール１７２２は、顧客によって出されたオーダーのためのサービスおよびリソースのプロビジョニングをオーケストレーションするために、オーダー情報を利用してもよい。場合によっては、オーダーオーケストレーションモジュール１７２２は、オーダープロビジョニングモジュール１７２４のサービスを使用して、申し込まれたサービスをサポートするようにリソースのプロビジョニングをオーケストレーションしてもよい。

ある実施形態では、オーダーオーケストレーションモジュール１７２２は、各オーダーに関連付けられたビジネスプロセスの管理を可能にし、オーダーがプロビジョニングに進むべきか否かを判断するためにビジネス論理を適用する。動作１７４２で、新規サブスクリプションのオーダーを受信すると、オーダーオーケストレーションモジュール１７２２は、リソースを割当ててサブスクリプションオーダーを遂行するために必要とされるリソースを構成するようにという要求を、オーダープロビジョニングモジュール１７２４に送信する。オーダープロビジョニングモジュール１７２４は、顧客によってオーダーされたサービスのためのリソースの割当てを可能にする。オーダープロビジョニングモジュール１７２４は、クラウドインフラストラクチャシステム１７０２によって提供されるクラウドサービスと、要求されたサービスを提供するためのリソースをプロビジョニングするために使用される物理的実装層との間の抽象化のレベルを提供する。オーダーオーケストレーションモジュール１７２２はこのため、サービスおよびリソースが実際にオンザフライでプロビジョニングされるか否か、または予めプロビジョニングされて要求時にのみ割当てられるか否かといった実装詳細から切り離されてもよい。

動作１７４４で、サービスおよびリソースが一旦プロビジョニングされると、提供されるサービスの通知が、クラウドインフラストラクチャシステム１７０２のオーダープロビジョニングモジュール１７２４によって、クライアント装置１７０４、１７０６および／または１７０８上の顧客に送信されてもよい。

動作１７４６で、顧客のサブスクリプションオーダーが、オーダー管理および監視モジュール１７２６によって管理され、追跡されてもよい。場合によっては、オーダー管理および監視モジュール１７２６は、使用されるストレージの量、転送されるデータの量、ユーザの数、システムアップタイムおよびシステムダウンタイムの量といった、サブスクリプションオーダーにおけるサービスについての使用統計を収集するように構成されてもよい。

ある実施形態では、クラウドインフラストラクチャシステム１７０２は、アイデンティティ管理モジュール１７２８を含んでいてもよい。アイデンティティ管理モジュール１７２８は、クラウドインフラストラクチャシステム１７０２においてアクセス管理および認証サービスなどのアイデンティティサービスを提供するように構成されてもよい。いくつかの実施形態では、アイデンティティ管理モジュール１７２８は、クラウドインフラストラクチャシステム１７０２によって提供されるサービスを利用したい顧客についての情報を制御してもよい。そのような情報は、そのような顧客のアイデンティティを認証する情報と、さまざまなシステムリソース（たとえば、ファイル、ディレクトリ、アプリケーション、通信ポート、メモリセグメントなど）に対してそれらの顧客がどのアクションを行なうことが認可されているかを記述する情報とを含み得る。アイデンティティ管理モジュール１７２８はまた、各顧客についての記述的情報と、その記述的情報が誰によってどのようにアクセスされ、修正され得るかについての記述的情報との管理を含んでいてもよい。

図１８は、この発明のさまざまな実施形態が実現され得る例示的なコンピュータシステム１８００を示す。システム１８００は、上述のコンピュータシステムのうちのいずれかを実現するために使用されてもよい。図に示すように、コンピュータシステム１８００は、バスサブシステム１８０２を介して多くの周辺サブシステムと通信する処理部１８０４を含む。これらの周辺サブシステムは、処理加速部１８０６と、Ｉ／Ｏサブシステム１８０８と、記憶サブシステム１８１８と、通信サブシステム１８２４とを含んでいてもよい。記憶サブシステム１８１８は、有形のコンピュータ読取可能記憶媒体１８２２と、システムメモリ１８１０とを含む。

バスサブシステム１８０２は、コンピュータシステム１８００のさまざまなコンポーネントおよびサブシステムを意図されるように互いに通信させるためのメカニズムを提供する。バスサブシステム１８０２は単一のバスとして概略的に図示されているが、バスサブシステムの代替的な実施形態は複数のバスを利用してもよい。バスサブシステム１８０２は、さまざまなバスアーキテクチャのうちのいずれかを使用するメモリバスまたはメモリコントローラ、周辺バス、およびローカルバスを含む、いくつかのタイプのバス構造のうちのいずれかであってもよい。たとえば、そのようなアーキテクチャは、ＩＥＥＥ Ｐ１３８６．１規格で製造されるメザニンバスとして実現可能な、産業標準アーキテクチャ（Industry Standard Architecture：ＩＳＡ）バス、マイクロチャネルアーキテクチャ（Micro Channel Architecture：ＭＣＡ）バス、強化ＩＳＡ（ＥＩＳＡ）バス、ビデオエレクトロニクス標準組織（Video Electronics Standards Association：ＶＥＳＡ）ローカル
バス、および周辺コンポーネント相互接続（Peripheral Component Interconnect：ＰＣ
Ｉ）バスを含んでいてもよい。

１つ以上の集積回路（たとえば、従来のマイクロプロセッサまたはマイクロコントローラ）として実現され得る処理部１８０４は、コンピュータシステム１８００の動作を制御する。処理部１８０４には、１つ以上のプロセッサが含まれていてもよい。これらのプロセッサは、シングルコアまたはマルチコアプロセッサを含んでいてもよい。ある実施形態では、処理部１８０４は、各処理部にシングルまたはマルチコアプロセッサが含まれた、１つ以上の独立した処理部１８３２および／または１８３４として実現されてもよい。他の実施形態では、処理部１８０４はまた、２つのデュアルコアプロセッサをシングルチップへと集積することによって形成されるクアッドコア処理部として実現されてもよい。

さまざまな実施形態では、処理部１８０４は、プログラムコードに応答してさまざまなプログラムを実行でき、同時に実行される複数のプログラムまたはプロセスを維持できる。任意の所与の時間において、実行されるべきプログラムコードのうちのいくつかまたはすべては、プロセッサ１８０４に、および／または記憶サブシステム１８１８にあり得る。好適なプログラミングを通して、プロセッサ１８０４は、上述のさまざまな機能性を提供できる。コンピュータシステム１８００は加えて処理加速部１８０６を含んでいてもよく、それは、デジタル信号プロセッサ（digital signal processor：ＤＳＰ）、専用プロセッサなどを含み得る。

Ｉ／Ｏサブシステム１８０８は、ユーザインターフェイス入力装置と、ユーザインターフェイス出力装置とを含んでいてもよい。ユーザインターフェイス入力装置は、キーボード、マウスまたはトラックボールなどのポインティング装置、ディスプレイに組込まれたタッチパッドまたはタッチスクリーン、スクロールホイール、クリックホイール、ダイヤル、ボタン、スイッチ、キーパッド、音声コマンド認識システム付き音声入力装置、マイクロホン、および他のタイプの入力装置を含んでいてもよい。ユーザインターフェイス入力装置は、たとえば、ジェスチャーおよび口頭コマンドを使用したナチュラルユーザインターフェイスを通して、マイクロソフトＸｂｏｘ（登録商標）３６０ゲームコントローラ
などの入力装置をユーザが制御し、それとやりとりすることを可能にする、マイクロソフトＫｉｎｅｃｔ（登録商標）運動センサなどの運動感知および／またはジェスチャー認識装置を含んでいてもよい。ユーザインターフェイス入力装置はまた、ユーザから目の活動（たとえば、写真撮影中および／またはメニュー選択中の「まばたき」）を検出し、アイジェスチャーを入力装置（たとえば、グーグル・グラス（登録商標））への入力として変換する、グーグル・グラス（登録商標）まばたき検出器などのアイジェスチャー認識装置を含んでいてもよい。加えて、ユーザインターフェイス入力装置は、ユーザが音声コマンドを通して音声認識システム（たとえば、Ｓｉｒｉ（登録商標）ナビゲータ）とやりとりできるようにする音声認識感知装置を含んでいてもよい。

ユーザインターフェイス入力装置はまた、３次元（３Ｄ）マウス、ジョイスティックまたはポインティングスティック、ゲームパッドおよびグラフィックタブレット、ならびに、スピーカ、デジタルカメラ、デジタルビデオカメラ、携帯型メディアプレイヤー、ウェブカメラ、画像スキャナ、指紋スキャナ、バーコードリーダ３Ｄスキャナ、３Ｄプリンタ、レーザー測距器、および視線追跡装置などの音声／視覚装置を、何ら限定されることなく含んでいてもよい。加えて、ユーザインターフェイス入力装置は、たとえば、コンピュータ断層撮影装置、磁気共鳴撮像装置、ポジトロン放出断層撮影装置、医療用超音波検査装置などの医療用撮像入力装置を含んでいてもよい。ユーザインターフェイス入力装置はまた、たとえば、ＭＩＤＩキーボード、デジタル楽器などの音声入力装置を含んでいてもよい。

ユーザインターフェイス出力装置は、表示サブシステム、表示灯、または、音声出力装置などの非視覚的ディスプレイを含んでいてもよい。表示サブシステムは、陰極線管（cathode ray tube：ＣＲＴ）、液晶ディスプレイ（liquid crystal display：ＬＣＤ）またはプラズマディスプレイを使用するものなどのフラットパネル装置、投影装置、タッチスクリーンなどであってもよい。一般に、「出力装置」という用語の使用は、コンピュータシステム１８００からユーザまたは他のコンピュータに情報を出力するためのあらゆる可能なタイプの装置およびメカニズムを含むよう意図されている。たとえば、ユーザインターフェイス出力装置は、モニタ、プリンタ、スピーカ、ヘッドホン、自動車ナビゲーションシステム、プロッタ、音声出力装置、およびモデムといった、テキスト、グラフィックスおよび音声／映像情報を視覚的に伝えるさまざまな表示装置を、何ら限定されることなく含んでいてもよい。

コンピュータシステム１８００は、現在システムメモリ１８１０内に位置するとして図示されたソフトウェア要素を含む記憶サブシステム１８１８を含んでいてもよい。システムメモリ１８１０は、処理部１８０４上でロード可能および実行可能なプログラム命令と、これらのプログラムの実行中に生成されたデータとを格納してもよい。

コンピュータシステム１８００の構成およびタイプに依存して、システムメモリ１８１０は揮発性（ランダムアクセスメモリ（random access memory：ＲＡＭ）など）であってもよく、および／または不揮発性（読出専用メモリ（read-only memory：ＲＯＭ）、フラッシュメモリなど）であってもよい。ＲＡＭは典型的には、処理部１８０４に直ちにアクセス可能であり、および／または処理部１８０４によって現在動作および実行中のデータおよび／またはプログラムモジュールを含む。いくつかの実現化例では、システムメモリ１８１０は、スタティックランダムアクセスメモリ（static random access memory：Ｓ
ＲＡＭ）またはダイナミックランダムアクセスメモリ（dynamic random access memory：ＤＲＡＭ）などの複数の異なるタイプのメモリを含んでいてもよい。いくつかの実現化例では、起動中などにコンピュータシステム１８００内の要素間で情報を転送するのに役立つ基本ルーチンを含む基本入力／出力システム（basic input/output system：ＢＩＯＳ
）が、典型的にはＲＯＭに格納されていてもよい。限定のためではなく例として、システ
ムメモリ１８１０はまた、クライアントアプリケーション、ウェブブラウザ、中央層アプリケーション、リレーショナルデータベース管理システム（relational database management system：ＲＤＢＭＳ）などを含み得るアプリケーションプログラム１８１２と、プ
ログラムデータ１８１４と、オペレーティングシステム１８１６とを示す。例として、オペレーティングシステム１８１６は、マイクロソフト・ウィンドウズ（登録商標）、アップル・マッキントッシュ（登録商標）、および／またはＬｉｎｕｘオペレーティングシステムのさまざまなバージョン、商業的に入手可能なさまざまなＵＮＩＸ（登録商標）またはＵＮＩＸ様オペレーティングシステム（さまざまなＧＮＵ／Ｌｉｎｕｘオペレーティングシステム、グーグル・クローム（登録商標）ＯＳなどを何ら限定されることなく含む）、および／または、ｉＯＳ、ウィンドウズ（登録商標）フォン、アンドロイド（登録商標）ＯＳ、ブラックベリー（登録商標）１８ＯＳ、パーム（登録商標）ＯＳオペレーティングシステムなどのモバイルオペレーティングシステムを含んでいてもよい。

記憶サブシステム１８１８はまた、いくつかの実施形態の機能性を提供する基本プログラミングおよびデータ構造を格納するための有形のコンピュータ読取可能記憶媒体を提供してもよい。プロセッサによって実行されると上述の機能性を提供するソフトウェア（プログラム、コードモジュール、命令）が、記憶サブシステム１８１８に格納されてもよい。これらのソフトウェアモジュールまたは命令は、処理部１８０４によって実行されてもよい。記憶サブシステム１８１８はまた、この発明に従って使用されるデータを格納するためのリポジトリを提供してもよい。

記憶サブシステム１８００はまた、コンピュータ読取可能記憶媒体１８２２にさらに接続され得るコンピュータ読取可能記憶媒体リーダ１８２０を含んでいてもよい。システムメモリ１８１０とともに、およびオプションでシステムメモリ１８１０と組合わされて、コンピュータ読取可能記憶媒体１８２２は、リモート、ローカル、固定および／またはリムーバブルの記憶装置に加えて、コンピュータ読取可能情報を一時的におよび／またはより永続的に含み、格納し、送信し、検索するための記憶媒体を包括的に表わしてもよい。

コードまたはコードの一部を含むコンピュータ読取可能記憶媒体１８２２はまた、情報の格納および／または送信のためのあらゆる方法または技術で実現される揮発性および不揮発性でリムーバブルおよび非リムーバブルの媒体を含むがそれらに限定されない記憶媒体および通信媒体を含む、当該技術分野において公知であるかまたは使用されるあらゆる適切な媒体を含み得る。これは、ＲＡＭ、ＲＯＭ、電子的消去可能プログラマブルＲＯＭ（electronically erasable programmable ROM：ＥＥＰＲＯＭ）、フラッシュメモリまたは他のメモリ技術、ＣＤ−ＲＯＭ、デジタル多用途ディスク（digital versatile disk：ＤＶＤ）または他の光学ストレージ、磁気カセット、磁気テープ、磁気ディスクストレージまたは他の磁気記憶装置、もしくは他の有形のコンピュータ読取可能媒体といった、有形のコンピュータ読取可能記憶媒体を含み得る。これは、所望の情報を送信するために使用可能であり、コンピューティングシステム１８００によってアクセスされ得るデータ信号、データ送信、または任意の他の媒体といった、非有形のコンピュータ読取可能媒体も含み得る。

例として、コンピュータ読取可能記憶媒体１８２２は、非リムーバブルで不揮発性の磁気媒体から読出し、またはそれに書込むハードディスクドライブ、リムーバブルで不揮発性の磁気ディスクから読出し、またはそれに書込む磁気ディスクドライブ、ならびに、ＣＤ ＲＯＭ、ＤＶＤ、およびＢｌｕ−Ｒａｙ（登録商標）ディスク、または他の光学媒体といった、リムーバブルで不揮発性の光ディスクから読出し、またはそれに書込む光ディスクドライブを含んでいてもよい。コンピュータ読取可能記憶媒体１８２２は、Ｚｉｐ（登録商標）ドライブ、フラッシュメモリカード、ユニバーサルシリアルバス（universal serial bus：ＵＳＢ）フラッシュドライブ、セキュアデジタル（secure digitalＳＤ）カ
ード、ＤＶＤディスク、デジタルビデオテープなどを含んでいてもよいが、それらに限定されない。コンピュータ読取可能記憶媒体１８２２はまた、フラッシュメモリベースのソリッドステートドライブ（solid-state drive：ＳＳＤ）、企業フラッシュドライブ、ソ
リッドステートＲＯＭといった、不揮発性メモリに基づいたＳＳＤ、ソリッドステートＲＡＭ、ダイナミックＲＡＭ、スタティックＲＡＭ、ＤＲＡＭベースのＳＳＤ、磁気抵抗ＲＡＭ（ＭＲＡＭ）ＳＳＤといった、揮発性メモリに基づいたＳＳＤ、および、ＤＲＡＭベースのＳＳＤとフラッシュメモリベースのＳＳＤとの組合せを使用するハイブリッドＳＳＤを含んでいてもよい。ディスクドライブおよびそれらの関連付けられたコンピュータ読取可能媒体は、コンピュータ読取可能命令、データ構造、プログラムモジュールおよび他のデータの不揮発性ストレージをコンピュータシステム１８００に提供してもよい。

通信サブシステム１８２４は、他のコンピュータシステムおよびネットワークへのインターフェイスを提供する。通信サブシステム１８２４は、コンピュータシステム１８００とは別のシステムからデータを受信し、別のシステムにデータを送信するためのインターフェイスとして機能する。たとえば、通信サブシステム１８２４は、コンピュータシステム１８００がインターネットを介して１つ以上の装置に接続できるようにしてもよい。いくつかの実施形態では、通信サブシステム１８２４は、（たとえば、３Ｇ、４Ｇ、またはＥＤＧＥ（enhanced data rates for global evolution：エンハンスト・データレート・フォー・グローバル・エボリューション）、ＷｉＦｉ（ＩＥＥＥ１６０２．１１ファミリー規格）、または他の移動通信技術、またはそれらの任意の組合せといった携帯電話技術、高度なデータネットワーク技術を使用した）無線音声および／またはデータネットワークにアクセスするための無線周波数（radio frequency：ＲＦ）トランシーバコンポーネ
ント、全地球測位システム（global positioning system：ＧＰＳ）受信機コンポーネン
ト、および／または他のコンポーネントを含み得る。いくつかの実施形態では、通信サブシステム１８２４は、無線インターフェイスに加えて、またはその代わりに、有線ネットワーク接続（たとえば、イーサネット）を提供できる。

いくつかの実施形態では、通信サブシステム１８２４はまた、コンピュータシステム１８００を使用し得る１人以上のユーザのために、構造化および／または非構造化データフィード１８２６、イベントストリーム１８２８、イベント更新１８３０などの形をした入力通信を受信してもよい。

例として、通信サブシステム１８２４は、ツイッター（登録商標）フィード、フェースブック（登録商標）更新、リッチ・サイト・サマリー（Rich Site Summary：ＲＳＳ）フ
ィードなどのウェブフィード、および／または１つ以上の第三者情報源からのリアルタイム更新といった、ソーシャルネットワークおよび／または他の通信サービスのユーザからのデータフィード１８２６をリアルタイムで受信するように構成されてもよい。

加えて、通信サブシステム１８２４はまた、リアルタイムイベントのイベントストリーム１８２８および／またはイベント更新１８３０を含み得る、明確な終わりがなく本質的に連続的または無限であり得る連続データストリームの形をしたデータを受信するように構成されてもよい。連続データを生成するアプリケーションの例は、たとえば、センサデータアプリケーション、金融ティッカー、ネットワーク性能測定ツール（たとえば、ネットワーク監視およびトラフィック管理アプリケーション）、クリックストリーム分析ツール、自動車交通監視などを含んでいてもよい。通信サブシステム１８２４はまた、構造化および／または非構造化データフィード１８２６、イベントストリーム１８２８、イベント更新１８３０などを、コンピュータシステム１８００に結合された１つ以上のストリーミングデータソースコンピュータと通信し得る１つ以上のデータベースに出力するように構成されてもよい。

コンピュータシステム１８００は、ハンドヘルド携帯装置（たとえば、ｉＰｈｏｎｅ（登録商標）携帯電話、ｉＰａｄ（登録商標）コンピューティングタブレット、ＰＤＡ）、ウェアラブル装置（たとえば、グーグル・グラス（登録商標）頭部装着型ディスプレイ）、ＰＣ、ワークステーション、メインフレーム、キオスク、サーバラック、または任意の他のデータ処理システムを含む、さまざまなタイプのうちの１つであり得る。

この実施形態のコンピュータシステム１８００およびそのコンポーネントは、前述の実施形態で説明されたようなこの発明の原則に基づいた適切な動作のうちのいずれかを行なうように構成可能である。たとえば、そのようなコンピュータシステムに含まれる通信サブシステムは、イベントストリームを受信してもよい。コンピュータシステムに含まれるプロセッサまたは処理部は、データストアのデータストアイベントを表わすテーブルコンポーネントを作成し、データストアからイベントストリームの特定のイベントに対応する特定のデータを選択してその特定のデータをその特定のイベントに追加するように、テーブルコンポーネントを外部関係ソースとして使用してイベント処理ネットワークのエンジンを実装してもよい。

好ましくは、イベント処理ネットワークのエンジンは、マップに少なくとも部分的に基づいて特定のデータを識別するように構成される。好ましくは、マップは、テーブルコンポーネントの作成後に更新されるように構成されてもよい。マップは、列ファミリーとしてテーブルコンポーネントに含まれてもよい。データストアは、データ格納場所のクラスタを含んでいてもよい。データストアは非リレーショナルデータベースを含む、または、エンジンは連続クエリ言語エンジンを含む、のうちの少なくとも１つであってもよい。

上述の部位の特定の動作プロセスについては、同じ概念を共有する関連する方法／システム実施形態における対応するステップ／コンポーネントが参照されてもよく、その参照も関連部位の開示と見なされる、ということは、当業者にとって自明である。したがって、記載の簡潔性のために、処理された特定の動作のうちのいくつかは、繰り返しまたは詳細には説明されない。

コンピュータおよびネットワークの絶えず変化する性質により、図に示すコンピュータシステム１８００の説明は、単に特定の一例として意図される。図に示すシステムよりも多い、または少ないコンポーネントを有する多くの他の構成が可能である。たとえば、カスタマイズされたハードウェアも使用されてもよく、および／または、特定の要素が、ＦＰＧＡ、ＡＳＩＣなどを含むハードウェア、ファームウェア、ソフトウェア（アプレットを含む）、または組合せで実現されてもよい。また、ネットワーク入力／出力装置などの他のコンピューティング装置への接続が採用されてもよい。ここに提供される開示および教示に基づいて、当業者であれば、さまざまな実施形態を実現するための他のやり方および／または方法を理解するであろう。

前述の明細書では、この発明の局面をその特定の実施形態を参照して説明したが、当業者であれば、この発明がそれに限定されないことを認識するであろう。上術の発明のさまざまな特徴および局面は、個々にまたは共同で使用されてもよい。また、実施形態は、明細書のより広範な精神および範囲から逸脱することなく、ここに記載されたものを超える任意の数の環境および用途において利用され得る。したがって、明細書および図面は、限定的でなく例示的であると見なされるべきである。

Claims (20)

1. データストアを表わすためにイベント処理ネットワークを作成するステップと、
   前記イベント処理ネットワークにおいて、前記データストアのデータストアイベントを表わすテーブルコンポーネントを作成するステップと、
   イベントストリームにおけるイベントのために、
   前記データストアから前記イベントに対応するデータを選択すること、および、
   前記データを前記イベントに追加すること、
   を含む動作を行なうように、前記テーブルコンポーネントを外部関係ソースとして使用して前記イベント処理ネットワークのプロセッサを実行するステップとを含む、方法。
2. 前記データは、アプリケーションプログラミングインターフェイスメソッドコールを利用して、前記データストアから検索される、請求項１に記載の方法。
3. 前記アプリケーションプログラミングインターフェイスメソッドコールは、Ｊａｖａメソッドコールを含む、請求項２に記載の方法。
4. 前記データストアは、非リレーショナルデータベースを含む、請求項１〜３のいずれか１項に記載の方法。
5. 前記非リレーショナルデータベースは、ＨＢａｓｅデータベースを含む、請求項４に記載の方法。
6. 前記プロセッサは、連続クエリ言語プロセッサを含む、請求項１〜５のいずれか１項に記載の方法。
7. １つ以上のプロセッサによって実行されると少なくとも以下の命令を行なうように１つ以上のコンピュータシステムを構成するコンピュータ実行可能命令を格納する、コンピュータ読取可能媒体であって、前記以下の命令は、
   前記１つ以上のプロセッサに、データストアのデータストアイベントを表わすテーブルコンポーネントを作成させる命令と、
   前記１つ以上のプロセッサに、
   前記１つ以上のプロセッサに、前記データストアからイベントストリームのイベントに対応するデータを選択させる命令、および、
   前記１つ以上のプロセッサに、前記データを前記イベントに追加させる命令、
   を行なうように、前記テーブルコンポーネントを外部関係ソースとして使用してイベント処理ネットワークのエンジンを実装させる命令とを含む、コンピュータ読取可能媒体。
8. 前記１つ以上のコンピュータシステムはさらに、前記１つ以上のプロセッサにマッピングコンポーネントを作成させる命令を行なうように構成される、請求項７に記載のコンピュータ読取可能媒体。
9. 前記マッピングコンポーネントは、前記イベントの属性と前記データに関連付けられた情報とのマッピングを特定するように構成される、請求項８に記載のコンピュータ読取可能媒体。
10. 前記データに関連付けられた情報は、前記データに関連付けられたファミリーまたは修飾子のうちの少なくとも１つを含む、請求項９に記載のコンピュータ読取可能媒体。
11. 前記１つ以上のコンピュータシステムはさらに、前記１つ以上のプロセッサに、前記テ
    ーブルコンポーネントの作成後、前記データに関連付けられた情報のスキーマを更新させる命令を行なうように構成される、請求項９または１０に記載のコンピュータ読取可能媒体。
12. 前記スキーマは、前記イベント処理ネットワークの前記エンジンを実装する間に動的に更新される、請求項１１に記載のコンピュータ読取可能媒体。
13. 前記スキーマは、前記データに関連付けられたファミリータイプまたは修飾子タイプのうちの少なくとも１つを定義する、請求項１１または１２に記載のコンピュータ読取可能媒体。
14. 前記エンジンは、連続クエリ言語エンジンを含む、請求項７〜１３のいずれか１項に記載のコンピュータ読取可能媒体。
15. 複数の命令を格納するメモリと、
    前記メモリにアクセスするように構成されたプロセッサとを含む、システムであって、
    前記プロセッサはさらに、少なくとも、
    データストアのデータストアイベントを表わすテーブルコンポーネントを作成し、
    前記データストアからイベントストリームのイベントに対応するデータを選択して当該データを前記イベントに追加するように、前記テーブルコンポーネントを外部関係ソースとして使用してイベント処理ネットワークのエンジンを実装する、
    ために、前記複数の命令を実行するように構成される、システム。
16. 前記イベント処理ネットワークの前記エンジンは、マップに少なくとも部分的に基づいて前記データを識別するように構成される、請求項１５に記載のシステム。
17. 前記マップは、前記テーブルコンポーネントの作成後に更新されるように構成される、請求項１６に記載のシステム。
18. 前記マップは、列ファミリーとして前記テーブルコンポーネントに含まれる、請求項１６または１７に記載のシステム。
19. 前記データストアは、データ格納場所のクラスタを含む、請求項１５〜１８のいずれか１項に記載のシステム。
20. 前記データストアは非リレーショナルデータベースを含む、または、前記エンジンは連続クエリ言語エンジンを含む、のうちの少なくとも１つである、請求項１５〜１９のいずれか１項に記載のシステム。