JP2011514577A - 分散共有ストリーム処理システムのクエリ配備プラン - Google Patents

Abstract

【課題】
【解決手段】分散共有ストリーム処理システムにおけるクエリに関する配備プランを提供するための方法は、ストリーム処理システムにおいて現在配備されているクエリに関する実現可能な配備プランのセットを記憶することを含む。クエリは、情報を求めるクライアント要求に応答してデータストリームを提供する、ストリーム処理システム内のノードでホスティングされる複数の演算子を含む。本発明はまた、クエリのＱｏＳメトリック制約が違反されているか否かを判断することと、ＱｏＳメトリック制約が違反されているとの判断に応じて、クエリを提供するのに使用するために実現可能な配備プランのセットから１つの配備プランを選択することとを含む。
【選択図】図５

Description

本発明は、分散共有ストリーム処理システムのクエリ配備プランに関する。

［関連出願の相互参照］
本出願は、２００８年１月２９日に出願された仮出願第６１／０２４，３００号の優先権を主張する。この仮出願の内容は、参照によりそっくりそのまま本明細書に援用される。

この数年間で、ストリーム処理システム（ＳＰＳ）は、惑星規模センサネットワークすなわち「マクロスコープ」、ネットワークの性能及びセキュリティの監視、マルチプレイヤオンラインゲーム、並びにフィードベースの情報マッシュアップを含む広範囲の用途でかなりの注目を集めてきた。
これらのＳＰＳは、潜在的に大量のデータストリームを生成するデータパブリッシャ及びこれらのデータストリームに関して多くの同時クエリを登録するクライアントを含めて、多くの地理的に分散したエンティティにより特徴付けられる。
例えば、クライアントは、クエリをデータパブリッシャへ送信し、一定の処理結果を受信する。

ＳＰＳは、要求されたデータストリームをクライアントに提供できるように、高いネットワークスケーラビリティ及びワークロードスケーラビリティを提供すべきである。
高いネットワークスケーラビリティは、システムコンポーネントの増大する地理的分布を優雅に取り扱う能力を指すのに対して、ワークロードスケーラビリティは、多くの同時に起こるユーザクエリに対処する。
双方のタイプのスケーラビリティを達成するために、ＳＰＳは、自身の処理をスケールアウトして、ネットワーク内の複数のノードにわたって分散させることができるべきである。

ＳＰＳの分散バージョンが提案されているが、これらの分散ＳＰＳの配備は困難である可能性がある。
ＳＰＳの配備に関連した難点は、アプリケーションが処理コンポーネントを共有する共有処理環境において、その配備がストリームベースのクエリをハンドリングするＳＰＳについてのものであるときに、さらに悪化する。
第１に、アプリケーションは、例えば、実用性、応答遅延、エンドツーエンド損失率又はレイテンシ等、出力のさまざまな特徴とその有用性との間の関係を記述するサービス品質（ＱｏＳ）仕様を表すことが多い。
例えば、多くのリアルタイム金融アプリケーションでは、クエリ回答は、タイムリーに受信された場合にのみ役立つ。
金融データを運ぶデータストリームが複数のマシンにわたって処理されるとき、データストリームを提供するＱｏＳは、複数のマシンのそれぞれによって影響を受ける。
したがって、マシンのいくつかが過負荷である場合、これらのマシンは、データストリームを提供するＱｏＳに影響を与える。
その上、ストリーム処理アプリケーションは、多くの信頼できないノードを有する公衆インターネットを介して動作すると予想され、ピアツーピア設定の場合等、それら信頼できないノードの一部又はすべては、自身の資源を一時的にしか与えない場合がある。
さらに、ストリーム処理及びデータストリームのクライアントへの配信には、複数のノードがチェーン又はツリーで動作してストリームを処理及び配信することが必要とされる場合がある。このチェーン又はツリーでは、或るノードの出力は、別のノードの入力となる。
したがって、処理がネットワーク内の新しいノードへ移動される場合、チェーン又はツリーの下流側処理及びＱｏＳが影響を受ける場合がある。
例えば、処理が、新しい地理的ロケーションの新しいノードへ移動される場合、これによって、エンドツーエンドのレイテンシが、クライアントにとって許容できない程度にまで増加される場合がある。

本発明の実施形態は、以下の図を参照して以下の説明で詳細に説明される。

一実施形態によるシステムを示す図である。 一実施形態による、図１に示すシステムのデータストリームを示す図である。 一実施形態による、システムのオーバーレイノード、システムにおけるクエリの例、及び演算子（operator）の候補ホストの例を示す図である。 一実施形態による初期クエリ配置のための方法のフローチャートである。 一実施形態による最適化のための方法のフローチャートである。 一実施形態による配備プラン生成のための方法のフローチャートである。 一実施形態による衝突を解決するための方法のフローチャートである。 一実施形態によるコンピュータシステムのブロック図である。

簡単にするために且つ例証の目的で、実施形態の原理は、主として実施形態の例を参照することによって説明される。
以下の説明では、実施形態の完全な理解を提供するために、多数の具体的な詳細が述べられる。
しかしながら、実施形態は、これらの具体的な詳細に限定されることなく実施できることが当業者には明らかであろう。
いくつかの例では、実施形態を不必要に不明瞭にしないように、既知の方法及び構造は詳細に説明されていない。

一実施形態によれば、分散ＳＰＳ（ＤＳＰＳ）は、オーバーレイネットワーク内の複数のオーバーレイノードにわたる分散ストリーム処理を提供する。
ノード及びオーバーレイノードは、本明細書では交換可能に使用される。
ＤＳＰＳは、データストリームを処理して、クライアントへ配信する。
データストリームは、データのフィードを含む。
例えば、データストリームは、ＲＳＳフィード又はリアルタイム金融データのストリームを含むことができる。
データストリームは、マルチメディアを含むこともできる。
データストリームは、データの連続送信又は定期的送信（リアルタイム相場又はＲＳＳフィード等）を含むこともできるし、データストリームは、アパートリスト（apartment listing）を求める要求の結果のような、必ずしも連続して又は定期的に送信されないデータのセットを含むこともできる。
ＤＳＰＳによって実行されるストリーム処理は、共有されたストリーム処理を含み、ここでは、後述するように、複数のデータストリームが演算子を共有できることに留意すべきである。

ＤＳＰＳは、複数の利用可能なノードにわたってストリーム処理クエリを分散させる適応型オーバーレイベースフレームワークを含む。
ノードは、分散リソースディレクトリサービスを使用して自己組織化する。
このリソースディレクトリサービスは、ノードにおける利用可能なコンピュータリソースをアドバタイズ及び発見するのに使用される。

ＤＳＰＳは、ノードのリソース制約及び各アプリケーション（例えば、データストリーム）のＱｏＳ期待値を考慮に入れながら、複数の共有されたストリーム処理クエリのデータストリーム配備を提供すると同時に、低い帯域幅消費を維持する。
一実施形態によれば、ＤＳＰＳは、プロアクティブ手法を使用する。この手法では、ノードは、データストリームの代替的な配備プランを事前に計算するように定期的に協力する。
配備プランは、本明細書ではプランとも呼ばれる。
ランタイム中、コンピュータリソース又はＱｏＳメトリックの制約違反が発生すると、ＤＳＰＳは、変更に高速に反応することができ、事前に計算された配備プランのうちの最適なものを適用することによって、実現可能な配備プランにマイグレーションすることができる。
その上、違反がない場合であっても、これらのプランの最良のものを適用して、システムの帯域幅消費を定期的に改善することができる。

図１は、一実施形態によるストリーム処理システム１００を示す。
システム１００は、オーバーレイノード１１１で構成されるオーバーレイネットワーク１１０、リソースディレクトリ１２０、及びネットワーク監視サービス１３０を含む。

オーバーレイネットワーク１１０は、コンピュータシステム、ルータ等を含む下部ネットワークインフラストラクチャを含むが、オーバーレイネットワーク１１０は、ストリームベースのクエリ処理サービスを含めて、ストリーム処理についての追加の機能性を提供する。
例えば、オーバーレイネットワーク１１０は、インターネット又は他のパブリックコンピュータネットワーク若しくはプライベートコンピュータネットワークの上に構築することができる。
オーバーレイネットワーク１１０は、オーバーレイノード１１１で構成され、オーバーレイノード１１１は、ストリーム処理機能性を提供する。
オーバーレイノード１１１は、オーバーレイパスを形成する論理リンクを介して互いに接続され、各論理リンクは、下部ネットワークにおける複数のホップを含む場合がある。

一実施形態によれば、オーバーレイノード１１１は、ストリームベースのクエリ処理サービスを提供するように動作可能である。
例えば、オーバーレイノード１１１は、クエリのための演算子を含む。
クエリは、ストリーム処理システムにおけるノードでホスティングされる複数の演算子を含む。
クエリは、クライアントクエリ又は情報の要求の受信及び登録に応じて提供され得る。
演算子は、クエリの関数である。
演算子は、データストリームに対する特定の演算を実行するように動作可能なノード上で動作するソフトウェアを含むことができる。
オーバーレイノードのコンピュータリソースの一部を、クエリのための演算子を提供するのに使用することができる。
オーバーレイノードは、他の機能を実行することができ、したがって、演算子をホスティングするオーバーレイノードを選択するときに、オーバーレイノード上の負荷を考慮することができる。

演算子の例には、結合（join）、集約、フィルタ等が含まれる。
これらの演算子は、従来のデータベースにおいてクエリのために通常は使用される演算子を含むことができる。しかしながら、システム１００における演算子は、データストリームに対して演算を行う。
演算子は、複数のクエリによって共有され得、ここで、各クエリは、１つ又は複数のデータストリームによって表され得る。
また、サブクエリが、演算子によって作成される。
一面において、複数の演算子から成るどのクエリも、たとえそのクエリが単一のクライアント用のものであっても、各演算子につき１つの、複数のサブクエリを有する。
別の面において、別のクライアントからの新しいクエリが、前のクエリの結果を部分的な結果として使用できるとき、前のクエリは、その新しいクエリのサブクエリとなる。
例えば、前のクエリを新しいクエリに部分的に使用できる状況について、フィルタ演算は、前の要求の結果を表すデータストリームに対してノードにより実行され得る。
例えば、オリジナルのクライアントクエリは、北カリフォルニア州のすべてのアパートリストを要求することができ、フィルタ演算をノードにおいて実行して、パロアルトのみのリストを導出することができる。

結合演算は、従業員の住所と従業員ＩＤとの結合のような、従来のデータベースにおける２つのテーブルの結合である。
同じ演算は、連続データ又は定期的に送信されるデータを有するデータストリームを除くデータストリームに適用され、ストリームにおいて結合を実行すべき箇所を求めるのにスライディングウィンドウが使用される。
例えば、結合演算子は、或る入力である第１のストリーム及び別の入力である第２のストリームを有する。
結合は、ストリームからのデータが、スライディングウィンドウ内にタイムスタンプを有する場合に実行される。
スライディングウィンドウの一例は、２分ウィンドウとすることができるが、他の長さのウィンドウも使用することができる。

演算子は、異なるオーバーレイノードにおいて割り当てられ得、時間と共に、ネットワークにわたるクエリの分布が最適化されるにつれてリアロケートされ得る。
最適化は、いくつかのタイプのメトリックを考慮に入れることができる。
メトリックのタイプは、ＣＰＵ使用率、メモリ使用率等のようなノードレベルメトリックだけでなく、帯域幅消費等のようなサービスプロバイダメトリックも含み得る。
また、レイテンシのようなＱｏＳメトリックも考慮される。
最適化は、以下でさらに詳細に説明される。

データのクライアントクエリをオーバーレイネットワーク１１０へサブミットすることができる。
クエリのための演算子のロケーションは、クエリの配備プランを定義する。このクエリの配備プランも、以下でさらに詳細に説明される。
ネットワークにおいて利用可能なリソース及びクエリの要件に依拠して、各クエリは、複数の代替的な事前に計算された配備プランを有することができる。
クエリの演算子は、オーバーレイネットワーク１１０内のノード１１１間のオーバーレイリンクによって相互接続される。
各演算子は、演算子の出力を、クエリプランにおける次の処理演算子へ転送する。
したがって、クエリ配備は、登録されたクエリのデータフローと一致するトポロジーを有するオーバーレイネットワークを作成する。
演算子ｏ_ｉが、その出力を演算子ｏ_ｊへ転送する場合、ｏ_ｉは、ｏ_ｊの上流側演算子（又はｏ_ｊのパブリッシャ）と呼ばれ、ｏ_ｊはｏ_ｉの下流側演算子（又はｏ_ｉのサブスクライバ）と呼ばれる。
演算子は、複数のパブリッシャ（例えば、結合演算子、統合演算子）を有することができ、演算子はクエリ間で共有され得るので、演算子は、複数のサブスクライバを有することもできる。
ｏ_ｉのサブスクライバのセットはｓｕｂ_ｏｉと表記され、ｏ_ｉのパブリッシャのセットはｐｕｂ_ｏｉと表記される。

システム１００は、データソース１４０及びクライアント１５０も含む。
データソース１４０は、データストリームをパブリッシュする一方、クライアントは、ストリーム指向型の連続クエリとして表されたそれらのデータインタレスト（data interests）をサブスクライブする。
システム１００は、オーバーレイノード１１１に配備された演算子を介してパブリッシャからクライアントへデータをストリーミングする。
パブリッシュされたデータストリームの例には、ＲＳＳフィード、センサネットワークからのデータ、インターネットを介してプレイされるマルチプレイヤゲームからのデータ等が含まれ得る。

クエリに関する配備プランを作成することは、クエリを配備するためのオーバーレイノード上にホスティングされる演算子を識別することを含む。
演算子をホスティングするための見込みオーバーレイノードを発見するために、リソースディレクトリ１２０が使用される。
リソースディレクトリ１２０を、複数のオーバーレイノードにわたって提供される分散サービスとすることができる。
一実施形態では、リソースディレクトリ１２０は、Basu他の「Nodewiz: Peer-to-peer resource discovery for grids」に説明されたＮｏｄｅＷｉｚシステムに基づいている。
Ｎｏｄｅｗｉｚシステムは、リソース発見用のスケーラブルなツリーベースのオーバーレイインフラストラクチャである。

オーバーレイノード１１０は、リソースディレクトリ１２０を使用して、各ノードの利用可能なコンピュータリソースの属性をアドバタイズし、多属性クエリを効率的に実行して、アドバタイズされたリソースを発見する。
例えば、各オーバーレイノードは、自身の利用可能なコンピュータリソース容量をリソースディレクトリ１２０へ送信し、リソースディレクトリ１２０は、この情報を記憶する。
容量属性の例には、ＣＰＵ容量、メモリ容量、Ｉ／Ｏ容量等が含まれる。
また、最適化中、オーバーレイノード又は他の或るエンティティは、クエリをリソースディレクトリ１２０へ送信して、再配置された演算子を実行するのに使用できる所定の利用可能な容量を有するオーバーレイノードを識別することができる。
リソースディレクトリ１２０は、アドバタイズメントの分配及びクエリの実行の負荷がノード間でバランスされるように演算子の割り当てを適合させることができる。

ネットワーク監視サービス１３０は、オーバーレイノード１１１間のオーバーレイリンクの統計を収集する。
統計の一例には、レイテンシ統計が含まれる。
ネットワーク監視サービス１３０は、Yalagandula他の「s3: A scalable sensing service for monitoring large networked systems」に説明されたＳ３に基づくことができる。
ネットワーク監視サービス１３０は、大規模ネットワーク化システムのためのリアルタイムで且つ構成可能な監視のためのスケーラブルセンシングサービスである。
このインフラストラクチャは、オーバーレイノード１１１を含むことができ、スケーラブルな方法でデータを集約している間、ＱｏＳメトリック、ノードレベルメトリック、及びサービスプロバイダメトリックを測定するのに使用され得る。
その上、推論アルゴリズムを使用して、ネットワークパスの小さなセットに基づくすべてのノード対のパス特性を導出することもできる。
最適化中、ネットワーク監視サービス１３０は、前もって必要なＱｏＳを提供するノード間のエンドツーエンドオーバーレイパス又はエンドツーエンドオーバーレイリンク、例えば、しきい値よりも低いレイテンシを有するパスを識別するために、クエリを受けることができる。

図２は、データストリームを配備する一例を示す。
例えば、リアルタイム金融パブリッシャ１４０ａは、１つ又は複数のクライアントクエリに応じて、リアルタイムの株価を有するデータストリームを生成する。
金融ニュースパブリッシャ１４０ｂも、金融ニュースのデータストリームを生成する。
ノード１１１ａ〜１１１ｅにおける演算子は、それらノードの各演算子を実行することによりサブクエリを提供して、クライアントに所望のデータを提供するように機能する。
例えば、クライアント１５０ａ〜１５０ｃは、異なる企業の株価及び対応する金融ニュースを望み、クライアント１５０ｂ及び１５０ｃは、データストリームの特定のソートを必要とする。
演算子は、パブリッシャからのオリジナルのデータストリームに対してサブクエリを実行して、所望のデータをクライアントに提供する。

最適化中、ノード１１１ａが過負荷であるか又はＱｏＳメトリック制約違反があることから、結合演算子をノード１１１ａから移動させる必要があると判断される場合がある。
結合演算子は、ノード１１１ｆへ移動され得るが、下流側演算子が影響を受ける。
最適化は、ＱｏＳメトリック制約にもノードのコンピュータリソース容量にも違反しない実現可能な配備プランを事前に計算する。

システム１００は、各クエリに対するＱｏＳ期待値及びノードの各資源制約が違反されないように、オーバーレイネットワーク内のノード間での演算子の分布を容易にする最適化プロトコルを実施する。
最適化は、登録されたすべてのクエリのための代替的な実現可能配備プランを事前に計算することを含む。
各ノードは、自身のローカル演算子の配置に関する情報を保持し、自身の「近傍（close neighborhood）」のノードと定期的に協力して、演算子の全セットを分散させる配備プランを構成する。
配備プランは、演算子と、パブリッシャからクライアントへのデータストリームのエンドツーエンドオーバーレイパスを提供する、演算子をホスティングするノードとを識別する。

コンピュータリソース制約違反又はＱｏＳメトリック制約違反が既存の配備プランに発生したときはいつでも、システムは、事前に計算されたセットから最適なプランを適用することによって迅速に対処することができる。
その上、違反がない場合であっても、システムは、現在の配備よりも効率的な配備を適用することによって、自身の現在の状態を定期的に改善することができる。

最適化プロセスは、下流側演算子／ノードに、それらの上流側演算子の実現可能な配置について知らせることに基づくプロアクティブ分散演算子配置を含む。
このように、オーバーレイノードは、可能な最良の方法で自身の共有クエリに影響を与える自身のローカル演算子及び上流側演算子の配置に関する決定を行うことができる。
この手法の１つの主な利点は、ノードが独力で配置の決定を行うことができるということである。これによって、どのＱｏＳメトリック制約違反にも迅速な対処が提供される。

各演算子は、自身のサブスクライブされた下流側演算子へ、それら下流側演算子の上流側演算子の可能な配置を記述した配備プランを定期的に送信する。
これらのプランは、クエリの演算子のサブセットしか配備しないので、部分的と呼ばれる。
ノードは、上流側ノードから部分的プランを受信すると、上記上流側演算子の可能な配置を追加することによってプランを拡張する。
プランにおける演算子を共有するすべてのクエリのＱｏＳ制約を満たす部分的プランは、他のノードへ伝播される。

実現可能な配備プランを識別するために、ｋ−前方検索（k-ahead search）が実行される。
ｋ−前方検索は、例えば最も低いレイテンシを招くローカル演算子から前方のｋ個の演算子（k operators ahead）の配置を発見する。
レイテンシの代わりに、他のＱｏＳメトリックを使用することもできる。
最小のレイテンシに基づいて、ＱｏＳ境界に違反する可能性のある部分的プラン（例えば、しきい値よりも大きなレイテンシ）は、最適化プロセスのできるだけ早期に削除される。
また、あらゆるノードは、自身のローカルな部分的プランを完成させる。
これは、各ノードが、帯域幅消費及びすべての影響を受けるクエリのレイテンシに対する自身の影響を評価することを含むことができる。
最終プランを使用すると、ノードは、ランタイムで高速配置決定を行うことができる。

いくつかのタイプのメトリックを用いて、配備プランを選択できることに留意すべきである。
代替的な実現可能配備プランのセットを選択するときに、例えば、エンドツーエンドレイテンシのようなクライアントによって提供される１つ又は複数のＱｏＳメトリック、及びコンピュータリソースの利用可能な容量のような１つ又は複数のノードレベルメトリックを使用して、或るパスが実現可能なパスであるか否かを判断することができる。
また、例えば、最小総帯域幅消費、コンソリデーション等のようなサービスプロバイダメトリックといった別のタイプのメトリックを使用して、データストリーム用に配備するために、実現可能な配備プランのセットからパスの１つを選択することができる。

次に、最適化プロセスが詳細に説明され、以下の表１のシンボル定義が、最適化プロセスを説明するのに使用される。

各オーバーレイノードは、自身のすべてのローカル演算子に関する部分的配備プランのセットを定期的に識別する。
演算子ｏ_ｉは、クエリ

のセットによって共有されると仮定する。
また、ｏ_ｉの上流側演算子のセットを

とする。
一例が図３に示される。
クエリｑ_１及びｑ_２は、演算子ｏ_１及びｏ_２を共有し、

である。

ｏ_ｉに関する部分的配備プランは、各演算子

をネットワーク内のオーバーレイノードの１つに割り当てる。
各部分的プランｐは、（ａ）例えばその部分的プランが行われるときの帯域幅消費といった部分的コストｐｃ^ｐ、及び（ｂ）その部分的プランが影響を与える各クエリの部分的レイテンシ

に関連付けられる。
例えば、ｏ_２に関する部分的プランは、演算子ｏ_１及びｏ_２を２つのノードに割り当て、これらの配置に起因して消費される帯域幅、並びに各クエリｑ_１及びｑ_２のための演算子ｏ_２までの応答レイテンシを評価する。

図３は、ノードリンクを実現可能な配備プランの一部として使用できるか否かを判断するときに評価される候補ノード、候補リンク、及びそれらリンクのレイテンシも示す。
配備プラン生成のための候補ノード及びＱｏＳメトリック（例えば、レイテンシ）の評価は、以下でさらに詳細に説明される。

図４は、一実施形態によるクエリの初期配置の方法４００を示す。
ステップ４０１において、クライアントはクエリを登録する。
例えば、図２に示すクエリ１５０ａは、株価及び関連した金融ニュースを要求するクライアントクエリをパブリッシャ１４０ａ及び１４０ｂへ送信する。

ステップ４０２において、現在配備されている、そのクエリのためのあらゆる演算子及びデータストリームが識別される。
図２に示すリソースディレクトリ１２０は、配備された演算子及びストリームについての情報を記憶するのに使用され得る。

ステップ４０３において、存在しないあらゆる演算子について、その演算子をホスティングするために、十分なコンピュータリソース容量を有するノードであって、パブリッシャ又はそれらのパブリッシャ演算子に最も近いノードが識別される。
これは、ノードの初期割り当て／クエリの初期配置についてのものであることに留意されたい。
パブリッシャ又はそれらのパブリッシャ演算子に最も近くない可能性のある他のノードは、最適化用に選択され得る。

ステップ４０４において、ステップ４０２からの演算子及びデータストリームがもしあればそれらを使用し、ステップ４０３からの演算子がもしあればそれらの演算子を使用して、クエリが配備される。
例えば、そのクエリのためのデータストリームは、そのクエリを登録したクライアントへ送信される。

ステップ４０５において、最適化プロセスが開始される。
最適化プロセスは、１つ又は複数のメトリックの点から現在の配備プランよりも良好であり得る配備プランを識別する。

図５は、一実施形態による最適化プロセスのための方法５００を示す。
方法５００のステップの１つ又は複数は、方法４００におけるステップ４０５において実行することができる。

ステップ５０１において、プラン生成プロセスが定期的に起動される。
このプロセスは、最新のノードワークロード及びネットワーク状態を反映する実現可能な配備プランを作成する。
これらの事前に計算された配備プランは、オーバーレイノードに記憶され、ＱｏＳ違反が検出されたときに使用され得、又は、事前に計算されたプランの１つを配備することによって帯域幅消費若しくは別のメトリックを改善できるか否かについての判断がなされる場合に使用され得る。
プラン生成プロセスは、方法６００について以下でさらに詳細に説明される。

ステップ５０２において、ノードは、ＱｏＳメトリック制約違反が発生したか否かを判断する。
例えば、レイテンシのようなＱｏＳメトリックがしきい値と比較される。このしきい値は制約である。
しきい値を超えている場合、ＱｏＳ違反が発生している。

これらの違反を検出するために、あらゆるオーバーレイノードは、あらゆるローカル演算子について、そのパブリッシャのロケーションまでのレイテンシを監視する。
あらゆるオーバーレイノードは、そのローカル演算子を共有するすべてのクエリのレイテンシも定期的に受信し、それらのＱｏＳ期待値からのそれらの「スラック」、すなわち各クエリが許容できるレイテンシの増加、を定量化する。
例えば、単一のパブリッシャｏ_ｍを有する演算子ｏ_ｉであって、応答遅延ｄ_ｑｔ及びスラックｓｌａｃｋ_ｑｔを有するクエリｑ_ｔによって共有される演算子ｏ_ｉを仮定する。
ｏ_ｉとｏ_ｍとの間のオーバーレイリンクのレイテンシが、Δｄ（ｈ（ｏ_ｍ），ｈ（ｏ_ｉ））＞ｓｌａｃｋ_ｑｔだけ増加した場合、クエリｑｔのＱｏＳは違反され、異なる配備が直ちに適用されるべきである。

ステップ５０３において、ＱｏＳ違反が発生した場合、事前に計算されたプランの１つを使用してＱｏＳを改善できるか否かを判断する。
このプランは、ＱｏＳ違反を除去するだけ十分にＱｏＳを改善すべきである。

ｏ_ｉのホストに記憶されたすべての最終プランにわたって、少なくとも

だけｑｔのレイテンシを減少させるプランｐを求めて、検索が実行される。
この条件を充足するすべてのプランにわたって、ｏ_ｉ及びｏ_ｍをマイグレーションせず（すなわち、ボトルネックリンクを含む）、且つ

を充足するいずれのプランｐも除去される。

ＱｏＳを改善するのに使用できる事前に計算されたプランが存在する場合、その事前に計算されたプランが、ステップ５０４において配備される。
例えば、上述したように、ｏ_ｉ及びｏ_ｍをマイグレーションせず（すなわち、ボトルネックリンクを含む）、且つ

を充足するいずれのプランｐも除去される。
残りのプランから、帯域幅消費を最も多く改善する１つのプランが適用される。

そうでない場合、ステップ５０５において、ＱｏＳを改善できる実現可能なプランを求める要求が他のノードへ送信される。
例えば、この要求は、その下流側サブスクライバ／演算子へ伝播される。
すなわち、ｑ_ｔのＱｏＳを満たすことができる配備をｏ_ｉのホストにおいて発見できない場合、ノードは、違反したクエリｑ_ｔについて、適したプランを求める要求を自身のサブスクライバへ送信する。
この要求は、輻輳したリンクに関するメタデータ（例えば、当該リンクの新しいレイテンシ）も含む。
このような要求を受信したノードは、クエリｑ_ｔのＱｏＳを充足できるプランの発見を試みる。
下流側ノードは、より多くの演算子をマイグレーションするプランを記憶するので、それら下流側ノードは、ｑ_ｔに関する実現可能な配備を発見する可能性がより高い。
この伝播は、違反したクエリの最後の演算子をホスティングするノードに達するまで続く。

ステップ５０６において、要求に応じてプランを識別できるか否かについての判断が行われる。
プランを識別できない場合、ステップ５０７において、クエリを充足することはできない。
クライアントは、クエリを充足することができないことの通知を受けることができ、クライアントは、別のクエリを登録することができる。
そうでない場合、ＱｏＳ違反を除去するだけ十分にＱｏＳを改善できる、要求に応じて識別されたプランが配備される。

新しい配備プランを識別することは小さなオーバーヘッドを有することに留意することが重要である。
本質的に、ノードは、クエリのレイテンシを十分削減するプランを検索しなければならない。
最終プランは、それら最終プランが影響を与えるクエリに基づいてインデックスされ得、各クエリのレイテンシに対するそれら最終プランの影響に基づいてソートされ得る。
したがって、ＱｏＳ違反が発生すると、本発明者らのシステムは、自身の「回復」配備を非常に迅速に識別することができる。

ステップ５０２〜５０７において、ＱｏＳ違反に応じて新しいプランを配備することができる。
これらのステップの多くは、ＱｏＳ違反が発生していないときに配備され得るが、新しいプランが、既存のプランよりも良好なＱｏＳ、又は良好なノードレベル（例えば、コンピュータリソース容量）メトリック若しくはサービスプロバイダメトリック（例えば、帯域幅消費）を提供できるとの判断が行われる。

図６は、一実施形態による配備プラン生成のための方法６００を示す。
方法６００のステップの１つ又は複数は、プラン生成プロセスとして、方法５００におけるステップ５０１において実行され得る。

ｋ−前方検索は、方法６００の前に実行され得、以下でさらに詳細に説明される。
ｋ−前方検索によって、各ノードは、部分的配備プランために使用できるローカル演算子の候補ホストに気付く。

ステップ６０１において、部分的配備プランが、リーフノードにおいて生成される。
ｏ_ｉを、ノードｎ_ｖで実行されるリーフ演算子とする。
ノードｎ_ｖは、部分的プランのセットを作成する。
各部分的プランは、異なる候補ホスト

にｏ_ｉを割り当てる。
ノードｎ_ｖは、自身の部分的コスト及びｏ_ｉを共有するすべてのクエリの部分的レイテンシを評価する。

がｏ_ｉに関する入力ソースのセットであり、且つ

がソースｓの代わりにデータをパブリッシュするノードである場合、クエリｑ_ｔの部分的レイテンシ（すなわち、ソースからｎ_ｊへのレイテンシ）は、

である。
最後に、このプランは、最初の演算子を割り当てるので、その部分的帯域幅消費は０である。

ステップ６０２において、実現不可能な部分的配備プランが削除される。
部分的プランが一旦作成されると、その部分的プランを下流側に転送して、より多くの演算子マイグレーションを追加することにより拡張すべきか否かについての決定が行われる。
部分的プランは、実現可能な配備につながる可能性がある場合にのみ伝播される。
この決定は、ｋ−前方検索の結果に基づく。
ｏ_ｉがｎ_ｊに配置されていると仮定すると、三重項（ｏ_ｉ，ｎ_ｊ，ｑ_ｔ）に関するｋ−前方レイテンシは、ｏ_ｉの前方のｋ個の演算子のすべての可能な配置にわたるクエリｑ_ｔに対する最小レイテンシオーバーヘッドを表す。
演算子ｏ_ｉまでのクエリのレイテンシに前方のｋ個の演算子の最小レイテンシを加えたものがクエリのＱｏＳに違反している場合、その部分的プランは、いかなる実現可能な配備にもつながる可能性はない。
より具体的には、

となるような少なくとも１つのクエリ

が存在する場合、演算子ｏ_ｉをノードｎ_ｊへ配置する部分的プランｐは実現不可能である。

ｋ−前方レイテンシは、実現可能なプランを削除しないが、すべての実現不可能な配備を識別するとは限らないことに留意されたい。
したがって、伝播されたプランは、以下のステップで実現不可能であると判明する場合がある「潜在的」に実現可能なプランである。

その上、パラメータｋについてトレードオフがある。
検索される前方の演算子が多いほど、ｋ−前方検索のオーバーヘッドは高くなる。しかしながら、実現不可能なプランをより早期に発見することができる。

ステップ６０３において、削除されない部分的プランが、新しい部分的プランの影響を評価するためのメタデータと共に下流側に転送される。
これらは、ステップ６０２から識別された実現可能な部分的配備プランを含む。
メタデータは、部分的レイテンシ及び／又はプランの実現可能性を判断するための他のメトリックを含むことができる。

演算子ｏ_ｉを処理するノードｎ_ｖは、そのパブリッシャ

から部分的プランｐを受信すると仮定する。
例証の目的で、単一のパブリッシャを仮定するが、以下の式は、複数のパブリッシャについて直接的な方法で一般化され得る。
ｏ_ｉを共有する各クエリは、そのパブリッシャも共有していることに留意されたい。
したがって、受信された各プランは、部分的レイテンシ

を含む。
最適化プロセスは、ローカル演算子ｏ_ｉをその候補ホストへマイグレーションすることを追加することによってこれらのプランのそれぞれを拡張する。

各候補ホスト

について、ノードｎ_ｖは、リソース可用性を確認する。
例えば、ノードｎ_ｖは、プランｐをパースして、いくつかの上流側演算子がｎ_ｊにも割り当てられているか否かをチェックする。
これを容易にするために、各プランと共に、各プランに含まれる各演算子の予想負荷要件に関するメタデータが送信される。
ｎ_ｊの残り容量が、ｏ_ｉを含む割り当てられたすべての演算子を処理するのに十分である場合、新しい部分的プランｆの影響は、

及び

として推定される。
ここで、ｈ^ｐ（ｏ_ｍ）は、部分的プランｐにおけるｏ_ｍのホストである。
新しい各部分的プランｆについて、その部分的プランが、ｋ−前方レイテンシ

に基づいて実現可能な配備につながる可能性があるか否かもチェックされ、実現可能な部分的プランのみが伝播される。

ステップ６０４において、ステップ６０３において転送された部分的プランを受信した中間上流側ノードは、上述したように、部分的プランの実現可能性を判断する。
例えば、プランを受信した中間ノードは、クエリの演算子の候補である。
中間ノードは、演算子をホスティングする自身のコンピュータリソース可用性を確認し、演算子をホスティングする予定である場合には、ＱｏＳに対する影響を判断する。
ステップ６０５において、実現可能な部分的プランが、帯域幅消費のようなサービスプロバイダメトリックに対する影響に基づいて選択される。

ステップ６０６において、選択された実現可能な部分的プランはオーバーレイノードに記憶される。
例えば、ノードで作成された部分的プランは、「完成」され、ローカルに記憶される。
部分的プランを完成させるために、現在の帯域幅消費及びその部分的プランが影響するクエリのレイテンシに対するその影響が評価される。
このプロセスを実施するために、あらゆるローカル演算子の上流側演算子によって消費される帯域幅及びこのローカル演算子までのクエリレイテンシに関する統計が保持される。
例えば、図３では、ｏ_１がリーフ演算子である場合、ｎ_２が、ｏ_１からｏ_２への帯域幅消費及び演算子ｏ_２までのレイテンシに関する統計を保持する。
各プランについて、現在の配備とそのプランによって提案された配備との間のこれらのメトリックの差が評価され、対応する最終プランと共にメタデータとして記憶される。
したがって、あらゆるノードは、自身のローカル演算子及び上流側演算子の実現可能な配備のセットを、システムコスト及びクエリのレイテンシに対するこれらの配備の影響と共に記憶する。
図３では、ｎ_２は、演算子｛ｏ_１，ｏ_２｝をマイグレーションするプランを記憶する一方、ｎ_４は、｛ｏ_１，ｏ_２，ｏ_４｝を配置するプランを記憶する。

上流側ノードから受信された部分的プランを結合して拡張することによって、多くの最終プランが生成される場合がある。
この問題を取り扱うために、多数の削除ヒューリスティクスを用いることができる。
例えば、クエリレイテンシに対して同様の影響を有する最終プランの間では、最小の帯域幅消費を有する最終プランが維持される一方、最終プランが帯域幅に対して同様の影響を有する場合には、クエリレイテンシを最も多く削減する最終プランが維持される。

上述したように、ノードは、ｋ−前方検索を実行して、ローカル演算子の候補ホストを識別する。
ステップ６０１において、リーフノードが部分的プランを作成する。
部分的プランは、ｋ−前方検索を使用して作成され得る。

ｋ−前方検索では、あらゆるノードｎ_ｖが、各ローカル演算子

及びその演算子の各候補ホストについてｋ−前方検索を実行する。

がｏ_ｉの候補ホストのセットである場合、ｏ_ｉがノード

に配置されると仮定して、検索により、ｏ_ｉを共有するクエリのそれぞれについてｏ_ｉの前方のｋ個の演算子の最小レイテンシ配置が識別される。
直観的に、ｏ_ｉをノードｎ_ｊへマイグレーションすることが各クエリｑｔの次のｋ個の下流側演算子の（例えば、レイテンシについての）最良の配置決定を行う場合、検索は、各クエリ

のレイテンシに対する最小の影響を識別することを試みる。
以下に、ｋ−前方検索のステップが説明される。
ｋ−前方検索は、最初に、１−前方レイテンシを評価し、次に、あらゆる三重項（ｏ_ｉ，ｎ_ｊ，ｑ_ｔ）に関するｋ−前方レイテンシ値を導出する。
ここで、

である。

各演算子

について、ｎ_ｖは、以下のステップを実行する。

１．リソースディレクトリサービスをクエリすることによってローカル演算子ｏ_ｉの候補ホスト

を識別する。
ｏ_ｉの制約要件はＣ＝｛（ｃ_１，ｖ_１），（ｃ_２，ｖ_２），…，（ｃ_ｍ，ｖ_ｍ）｝であると仮定し、リソースディレクトリは、ｃ_１≧ｖ_１∧ｃ_２≧ｖ_２∧…∧ｃ_ｍ≧ｖ_ｍを有するノードについてクエリされると仮定する。
ここで、ｃ_ｉはリソース属性であり、ｖｉは、そのリソースに関する演算子の要件である。

２．ｏ_ｍが、クエリ

についてのｏ_ｉの下流側演算子である場合、ノードは、その演算子の候補ホスト

のセットを求める要求をｏ_ｍのホストへ送信する。
これらの候補ノードのそれぞれ１つについて、そのノードは、レイテンシ

についてネットワーキング監視サービスをクエリする。
ｏｉ演算子の候補ｎ_ｊ及びクエリ

についてのｏｉ演算子に関する１−前方レイテンシは、

である。
図３では、

であり、ｎ_１は、演算子ｏ_２の候補ホスト

をｎ_２に要求し、１−前方レイテンシ

を推定する。
また、ｏ_２について、

及び

も仮定する。

３．検索は、数ラウンド続き、この検索において、各演算子ｏ_ｉについて、ノードは、クエリ

における自身のサブスクライバｏ_ｍが、ｋ−前方レイテンシの推定を進める前に、（ｋ−１）−前方レイテンシの評価を完了するのを待つ。
ｏ_ｉ演算子の候補ｎ_ｊ及びクエリ

についてのｏ_ｉ演算子に関するｋ−前方レイテンシは、

である。

最後のステップは、図３の例を使用して説明される。
この場合、

である。
したがって、ｏ_１のｎ_５へのマイグレーションを仮定すると、次の２つの演算子の最小レイテンシを有する配置は、ｑ_１の部分的応答レイテンシを１５ｍｓだけ増加させ、ｑ_２の部分的レイテンシを２５ｍｓだけ増加させる。ここで、各部分的レイテンシは、より多くの演算子がそのクエリに割り当てられるほど増加する。

共有されたクエリの同時変更は、同時変更の影響を受けるクエリの最終レイテンシについて衝突を生み出す可能性があるので、特別な注意を要する。
例えば、図３において、ｑ_１及びｑ_２の双方のＱｏＳが満たされないと仮定し、ノードｎ_３及びｎ_４が、各クエリについて異なる配備プランを適用するように同時に決定すると仮定する。
これらのプランの並列実行は、それらのＱｏＳ期待値が充足されることを保証しない。

この問題に対処するために、演算子を複製することができる。
配備プランは、演算子のマイグレーションが、それら演算子に依存するすべてのクエリのＱｏＳメトリック制約を充足できないときはいつでもそれら演算子を複製することによって実施される。
しかしながら、複製処理は、帯域幅消費を増加させるだけでなく、システムの処理負荷も増加させる。
したがって、プロセスは、衝突が代替的な候補プランによって解決できるか否かを識別し、代替的な候補プランが利用可能でない場合には、プロセスは複製を適用する。
プロセスは、プラン生成フェーズ中に作成されたメタデータを使用して、複製ソリューションに代わるものを識別する。
より具体的には、プロセスは、既存の配備プランを使用して、（１）マイグレーションによるプランを適用することが、同時に違反されたすべてのクエリを充足するか否かを決定し、（２）安全であるときはいつでも複数のマイグレーションを可能にし、すなわち、並列マイグレーションを可能にし、（３）既存の配備プランを使用できないときは、衝突のないプランを構築する。
次のパラグラフでは、プロセスが、以下の定義を使用して説明される。

直接的な依存関係の定義：２つのクエリｑ_ｉ及びｑ_ｊは、或る演算子を共有する場合、直接的に依存する。すなわち、ｑ_ｉ∈Ｑ（ｏ_ｋ）且つｑ_ｊ∈Ｑ（ｏ_ｋ）となるような∃ｏ_ｋである。
その場合、ｑ_ｉ及びｑ_ｊは、あらゆる演算子ｏ_ｋの依存するクエリである。
クエリｑ_ｉの依存するクエリのセットはＤ_ｑｉであり、演算子ｏ_ｋの依存するクエリはＤ_ｏｋである。
この場合、Ｏ（ｑ_ｉ）がクエリｑ_ｉにおける演算子のセットである場合、

である。

直接的に依存するクエリは、独立したプランを有さず、したがって、それらの配備プランの同時変更は、あらゆる衝突及び遅延制約の違反を回避するために、特別なハンドリングを要する。

間接的な依存関係の定義：２つのクエリｑ_ｉ及びｑ_ｊは、

であり且つ

である場合にのみ間接的に依存する。

間接的に依存するクエリは、独立した（重ならない）プランを有する。
それにもかかわらず、それらの配備プランに対する同時変更は、それらの共通の依存するクエリに影響を与える可能性がある。
したがって、プロセスは、これらの衝突にも同様に対処し、依存するクエリのＯｏＳ期待値が充足されることを保証する。
同時変更を検出するために、リースベース（lease-based）の手法が使用される。
新しい配備が適用されるべきであるとノードが一旦決定すると、プランのすべての演算子及びそれらの上流側演算子はロックされる。
すでにロックされた演算子のマイグレーションを試みるノードは、自身の変更が、進行中の現在のものと衝突しないか否かをチェックする。
衝突が存在する場合、ノードは、衝突のない代替的な配備を識別することを試みる。
そうでない場合、ノードは、演算子を複製することによって、自身の初期プランを適用する。
リースベースの手法は、次のパラグラフで説明される。

ノードは、クエリｑに適用するプランｐを決定していると仮定する。
ノードは、ＲＥＱＵＥＳＴ ＬＯＣＫ（ｑ，ｐ）（ロック要求）メッセージを自身のパブリッシャ及びサブスクライバへ転送する。
間接的な依存関係をハンドリングするために、このロック要求を受信した各ノードも、そのロック要求を、クエリｑの自身のローカル演算子のサブスクライバへ送信する。
この要求は、いずれかのクエリ演算子及びそれらに依存するものを実行するノードに、新しい配備プランを知らせ、ｑ及びその依存するもののロックを要求する。
クエリがロックを有さない（これは、依存するものを有さないクエリには常に当てはまる）とすると、パブリッシャ／サブスクライバは、そのクエリの自身のパブリッシャ／サブスクライバからＭＩＧＲ ＬＥＡＳＥ（ｑ）要求を一旦受信すると、ＭＩＧＲ ＬＥＡＳＥ（ｑ）許可でリプライする。
マイグレーションリースを許可したノードは、そのリースが解除される（又は或る満了しきい値に基づいて満了する）まで、別のマイグレーションリースを許可することが認められない。

ノードｎが、ｑの自身のすべてのパブリッシャ及びサブスクライバから自身のマイグレーションリースを一旦受信すると、ノードｎは、そのクエリのプランｐを適用する。
ノードｎは、配備プランをパースし、ノードｎへのマイグレーション演算子ｏをホスティングするノードごとに、ＭＩＧＲＡＴＥ（ｏ，ｎ）メッセージを送信する。
マイグレーションは、クエリプランのトップダウン方向で適用される。すなわち、最も上流側のノードが（プランによって必要とされている場合に）自身の演算子をマイグレーションし、このプロセスが一旦完了すると、すぐ隣の演算子（immediate operator）は、変更を知らされ、それら演算子の新しいロケーションへサブスクライブする。
ノードは、自身の接続を更新するとき、プランによって指定されたあらゆるローカルマイグレーションも適用する。
プラン全体が一旦配備されると、ＲＥＬＥＡＳＥ ＬＯＣＫ（ｑ）要求が、演算子及びそれらに依存するものの古いロケーションへ転送され、これらは、クエリのロックを解除する。

ロック要求は、プランに含まれる演算子をホスティングするすべてのノード及びプランの演算子を共有するすべてのクエリにわたって送信される。
ロックが一旦許可されると、あらゆる後続のロック要求は、複製リース又はマイグレーションリースのいずれかによって充足される。
マイグレーションリースによって、配備プランは、その演算子をマイグレーションすることによって適用されることが可能になる。
しかしながら、クエリネットワーク上での同時変更によってこのようなリースを許可できない場合、複製リースを許可することができ、ノードは、関与する演算子を複製することによってそのクエリの配備プランを適用することが可能になる。
このように、この特定のクエリのみが影響を受ける。

留意すべき１つの特性は、演算子ｏ_ｉがクエリのセット

によって共有される場合に、ｏ_ｉをルートとするサブプランも、同じクエリのセットによって共有されるということである。
次に、共にそのＱｏＳメトリック制約が違反されている２つの依存するクエリｑ_ｉ及びｑ_ｊを仮定する。
クエリｑ_ｉは、ＲＥＱＵＥＳＴＬＯＣＫ（ｑｉ，ｐｉ）要求をこの下流側演算子へ送信し、クエリｑ_ｊについても同様である。
その上、依存関係に気付いている共有演算子は、同じ要求を自身のサブスクライバへ転送して、依存するクエリにも、要求されたロックを知らせる。
クエリはいくつかの演算子を共有するので、少なくとも１つの演算子は、双方のロック要求を受信する。
その演算子は、最初の要求を受信すると、後述する手順を適用する。すなわち、衝突を識別し、２つのプランのメタデータに基づいて衝突を解決する。
一方、２番目のロックの要求が到着すると、受信する最初の共有ノードは、このクエリのマイグレーションリースがすでに許可されているので、その要求をどのパブリッシャへも転送しない。

次のパラグラフは、直接的な依存関係及び間接的な依存関係の衝突の解決を試みるときに生じる異なる場合を説明する。
直接的な依存関係については、直接的に依存するプランに対する同時変更が生じる。

並列マイグレーションに関して、同時変更は、常に衝突になるとは限らない。
２つの配備プランがクエリの同じセットに影響を与えない場合、双方のプランを並列に適用することができる。
例えば、図３において、ｎ_３がｏ_３のみをマイグレーションし、ｎ_４がｏ_４のみをマイグレーションすると決定した場合、双方の変更を適用することができる。
この場合、ｎ_３及びｎ_４によって決定された２つのプランは、それぞれクエリｑ_１及びｑ_２に対して影響がないことを示すべきである。
配備プランは、これらの場合を効率的に識別するすべての必要な情報（マイグレーションされる演算子、新しいホスト、クエリに対する影響）を含み、したがって、衝突のない複数のプランにマイグレーションリースを許可する。

冗長なマイグレーションに関して、複数のプランの同時配備によって定義される複数のマイグレーションは、多くの場合、クエリのＱｏＳ期待値を保証するのに必要でないことがある。
非常に多くの場合に、ノードは、並列にＱｏＳ違反を識別し、自身のローカルに記憶された配備プランを適用することによってそれら違反に対処しようと試みることができる。
この場合、現在の配備を再構成するには、それらプランのいずれか１つで十分である可能性がかなりある。
しかしながら、あらゆるプランが、影響を受けるすべてのクエリに対する影響の評価を含む。
したがって、２つのプランｐ_１及びｐ_２が共に同じクエリのセットに影響を与えている場合、いずれか一方を適用することによっても、本発明者らのクエリの実現可能な配備が提供される。
したがって、マイグレーションリースを最初に取得したプランが適用される一方、２番目のプランは無視される。

代替的なマイグレーションプランに関して、共有演算子を再配置する配備プランは、並列に適用することができない。
この場合、ロックを要求する最初のプランが、演算子をマイグレーションする一方、充足されないあらゆるＱｏＳ期待値を満たすために、新しい代替的な衝突のない配備プランを識別する試みが行われる。
最初のプランは、共有演算子をマイグレーションしているので、このマイグレーションの上に構築されたあらゆるプランを求めて、下流側演算子のホストが検索される。
例えば、図３において、最初のプランが演算子ｏ_１をマイグレーションするが、ｑ_２のＱｏＳが依然として満たされない場合、ｏ_１に対する同じマイグレーションを含むあらゆるプランを求めて、ノードｎ_４が検索され、ｏ_４も同様にマイグレーションすることによってｑ_２の応答遅延をさらに削減することができる。

間接的な依存関係に関して、クエリは、演算子を共有することができないが、それでも、依存するものを共有することはできる。
したがって、間接的に依存するクエリの配備を変更する試みが行われる場合、それらの共有された依存するものに対する影響が考慮される。
この場合、適用されるプランが、依存するクエリの重複セットに影響を与えている場合、マイグレーションリースが、最初のロック要求に許可され、あらゆる後続の要求に複製リースが許可される。
一方、それらプランが、同じクエリのＱｏＳに影響を与えない場合、これらのプランは、並列に適用され得る。

図７は、共有クエリの同時変更のための方法７００を示す。
ステップ７０１において、ノードは、例えば、ＱｏＳメトリック制約違反により、新しい配備プランを適用すべきと判断する。

ステップ７０２において、プランにおけるすべての演算子がまだロックされていない場合には、それら演算子がロックされる。
あらゆる演算子がロックされている場合には、ステップ７０３において、衝突が存在するか否かについての判断が行われる。

ステップ７０４において、衝突が存在する場合、ノードは、衝突のない代替的な配備の識別を試みる。

ステップ７０５において、衝突が存在しない場合、ノードは、演算子を複製し、自身の初期プランを適用する。

図８は、図１に示すシステム１００のノード（すなわち、オーバーレイノード）として使用できるコンピュータシステム８００の一例示のブロック図を示す。
コンピュータシステム８００は、ソフトウェアを実行するための実行プラットフォームを提供するプロセッサ８０２のような１つ又は複数のプロセッサを含む。

プロセッサ８０２からのコマンド及びデータは、通信バス８０５を介して通信される。
コンピュータシステム８００は、ソフトウェアがランタイム中常駐できるランダムアクセスメモリ（ＲＡＭ）のようなメインメモリ８０４、及びデータストレージ８０６も含む。
データストレージ８０６は、例えば、ソフトウェアのコピーを記憶できるハードディスクドライブ及び／若しくは着脱可能記憶ドライブ、又は不揮発性メモリを含む。着脱可能記憶ドライブは、フロッピー（登録商標）ディスケットドライブ、磁気テープドライブ、コンパクトディスクドライブ等を表す。
データストレージ８０６には、ＲＯＭ（読み出し専用メモリ）、ＥＰＲＯＭ（消去可能プログラマブルＲＯＭ）、ＥＥＰＲＯＭ（電気的消去可能プログラマブルＲＯＭ）も含めることができる。
本明細書で説明したルーティングステップ及び他のステップのソフトウェアに加えて、ルーティングテーブル、ネットワークメトリック、及び他のデータをメインメモリ８０４及び／又はデータストレージ８０６に記憶することができる。

ユーザは、キーボード、マウス、スタイラス、ディスプレイ等のような１つ又は複数のＩ／Ｏデバイス８０７でコンピュータシステム８００とインターフェースする。
他のノード及びコンピュータシステムと通信するためのネットワークインターフェース８０８が提供される。

本明細書で説明した方法のステップ及び本明細書で説明した他のステップの１つ又は複数は、メモリ８０４及び／又はデータストレージ８０６のようなコンピュータ可読媒体に組み込まれたソフトウェアとして実施することができ、例えばプロセッサ８０２によってコンピュータシステム８００上で実行することができる。
これらのステップは、コンピュータプログラムによって具現化され得、コンピュータプログラムは、アクティブ及び非アクティブの双方のさまざまな形態で存在することができる。
例えば、ステップは、当該ステップのいくつかを実行するためのソースコード、オブジェクトコード、実行可能コード、又は他のフォーマットのプログラム命令で構成されたソフトウェアプログラム（複数可）として存在することができる。
上記のいずれも、コンピュータ可読媒体上に具現化することができる。コンピュータ可読媒体には、圧縮形態又は非圧縮形態の記憶デバイス及び信号が含まれる。
適したコンピュータ可読記憶デバイスの例には、従来のコンピュータシステムＲＡＭ（ランダムアクセスメモリ）、ＲＯＭ（読み出し専用メモリ）、ＥＰＲＯＭ（消去可能プログラマブルＲＯＭ）、ＥＥＰＲＯＭ（電気的消去可能プログラマブルＲＯＭ）、及び磁気ディスク若しくは磁気テープ又は光ディスク若しくは光テープが含まれる。
コンピュータ可読信号の例には、搬送波を使用して変調されているか否かに関わらず、コンピュータプログラムをホスティング又は実行するコンピュータシステムにアクセスするように構成され得る信号であり、インターネット又は他のネットワークを通じてダウンロードされた信号が含まれる。
前述のものの具体例には、ＣＤ ＲＯＭによる又はインターネットダウンロードを介したプログラムの配布が含まれる。
或る意味で、インターネットそのものが、抽象エンティティとして、コンピュータ可読媒体である。
同じことは、コンピュータネットワーク一般に当てはまる。
したがって、添付の請求の範囲で列挙される機能は、上述した機能を実行できる任意の電子デバイスによって実行できることが理解されるべきである。

例を参照して実施形態を説明してきたが、当業者は、請求項に記載の実施形態の範囲から逸脱することなく、説明した実施形態にさまざまな変更を行うことができる。

１００ ストリーム処理システム
１１０ オーバーレイネットワーク
１１１ オーバーレイノード
１２０ リソースディレクトリ
１３０ ネットワーク監視サービス
１４０ データソース
１５０ クライアント
８００ コンピュータシステム
８０２ プロセッサ
８０４ メモリ
８０６ マスストレージ
８０７ Ｉ／Ｏデバイス
８０８ ネットワークインターフェース

Claims (15)

1. 分散共有ストリーム処理システムにおけるクエリに関する配備プランを提供する方法であって、
   前記ストリーム処理システムにおいて現在配備されているクエリに関する事前に計算された実現可能な配備プランのセットを記憶することであって、前記クエリは、情報を求めるクライアント要求に応答してデータストリームを提供する、前記ストリーム処理システム内のノードでホスティングされる複数の演算子を含む、記憶することと、
   前記クエリのＱｏＳメトリック制約が違反されているか否かを判断することと、
   前記ＱｏＳメトリック制約が違反されているとの判断に応じて、前記クエリを提供するのに使用される前記実現可能な配備プランのセットから一配備プランを選択することと
   を含む方法。
2. 前記実現可能な配備プランのセットを記憶することは、
   複数の部分的配備プランを識別することと、
   前記ＱｏＳメトリックに基づいて、前記複数の部分的配備プランから前記実現可能な部分的配備プランを識別することと、
   前記プランのそれぞれについて演算子を実行するノードのコンピュータリソースの可用性に基づいて、前記実現可能な部分的配備プランのサブセットを識別することと、
   サービスプロバイダメトリックを最適化するように前記実現可能な部分的配備プランのサブセットの１つ又は複数を選択することと、
   前記選択されたプランを記憶することと
   を含む
   請求項１に記載の方法。
3. 前記複数の部分的配備プランを識別することは、
   前記クエリのリーフノードにおいて複数の部分的配備プランを識別することと、
   実現可能であると判断された前記部分的配備プランを、下流側に、前記部分的配備プランの演算子をホスティングするノードへ、前記下流側ノードによって使用されるメタデータと共に転送することであって、それによって、前記部分的配備プランを、そのローカルに実行される演算子の配置で拡張し、前記ＱｏＳメトリックに対する前記配置の影響を定量化する、転送することと
   を含む
   請求項２に記載の方法。
4. 前記クエリのリーフノードにおいて複数の部分的配備プランを識別することは、
   ｋ−前方検索を実行することであって、それによって、前記ＱｏＳメトリックに対する影響を判断し、ｋ個の下流側演算子の最良の配置を提供する、実行すること
   を含む
   請求項３に記載の方法。
5. 前記ｋ−前方検索は、
   各部分的配備プランについて、前記部分的配備プランの演算子をホスティングする候補ノードを識別することと、
   下流側演算子をホスティングするノードへ、前記下流側演算子の候補ホストの第２のセット及び前記候補の前記ＱｏＳメトリックの推定値を求める要求を送信することと、
   前記ＱｏＳメトリック制約が、前記候補ノードのそれぞれについて違反されているか否かを評価することと、
   要求を送信する前記ステップ及び後続の下流側演算子について前記ＱｏＳメトリックを評価する前記ステップを繰り返すことであって、それによって、前記ＱｏＳメトリック制約を違反しない部分的プランを求める、繰り返すことと
   を含む
   請求項４に記載の方法。
6. 前記実現可能な部分的配備プランのサブセットを識別することは、
   前記下流側ノードのそれぞれにおいて、該ノードが、前記演算子をホスティングするのに十分な利用可能なコンピュータリソースを有するか否かを判断することと、
   前記ＱｏＳメトリックに基づいて前記部分的プランの前記影響を推定することと、
   前記ＱｏＳメトリック制約を充足する部分的プランのみを下流側へ伝播することと
   を含む
   請求項３に記載の方法。
7. サービスプロバイダメトリックを最適化するように実現可能な部分的配備プランの前記サブセットの１つ又は複数を選択することは、
   あらゆるローカル演算子のすべての上流側演算子について、前記サービスプロバイダメトリックに関する統計を保持することと、
   実現可能な部分的配備プランの前記サブセットの１つ又は複数を、前記統計に基づいて記憶するように選択することと
   を含む
   請求項６に記載の方法。
8. 前記クエリのＱｏＳメトリック制約が違反されているか否かを判断することは、
   前記クエリにおける各ノードが、自身のパブリッシャのロケーションへの自身の演算子の前記ＱｏＳメトリックを監視することと、
   各ノードが、前記ＱｏＳメトリックの前記監視に基づいて、前記ＱｏＳメトリック制約が違反されているか否かを判断することと
   を含む
   請求項１に記載の方法。
9. 前記ＱｏＳメトリック制約が違反されているか否かを各ノードが判断することは、
   各ノードについて、そのノードでホスティングされる前記演算子を共有するすべてのクエリの前記ＱｏＳメトリックを求めることと、
   前記ＱｏＳメトリックの許容範囲が、前記クエリのいずれについても違反されているか否かを判断することと
   を含む
   請求項８に記載の方法。
10. 分散ストリーム処理システムにおいて衝突を解決してクエリの配備プランを配備する方法であって、
    既存のクエリに関する新しい配備プランが適用されるべきと判断することと、
    前記新しい配備プランの各演算子について、その演算子がまだロックされていない場合にはその演算子をロックすることと、
    その演算子がすでにロックされている場合には、衝突が存在するか否かを判断することと、
    衝突が存在する場合には、代替的な配備プランを識別することと、
    衝突が存在しない場合には、前記演算子を複製し、前記新しい配備プランを配備することと
    を含む方法。
11. 前記演算子をロックすることは、
    前記新しい配備プランを適用すると判断したノードが、自身のパブリッシャ及び前記クエリのサブスクライバへロックする要求を送信することと、
    前記要求を受信した各ノードが、前記クエリの自身の演算子のサブスクライバへ前記要求を送信することと
    を含む
    請求項１０に記載の方法。
12. 前記要求を受信したノードは、前記演算子がまだロックされていない場合に前記クエリのローカル演算子をロックし、
    前記演算子をロックすることは、前記ロックが解除されるまで、前記ノードが前記ロックされた演算子の別のマイグレーションを可能にすることを防止する
    請求項１１に記載の方法。
13. 衝突は、前記クエリが別のクエリと直接的又は間接的な依存関係を有する場合に存在するように実施可能であり、
    前記直接的な依存関係は、前記クエリ及び前記別のクエリが演算子を共有するか否かに基づき、前記間接的な依存関係は、演算子が前記クエリ及び前記別のクエリによって共有されないが、前記クエリ及び前記別のクエリの双方が１つの演算子を共有する第３のクエリが存在するときである
    請求項１０に記載の方法。
14. 実行されると方法を実行する命令を含むソフトウェアを記憶するコンピュータ可読記憶媒体であって、前記方法は、
    分散ストリーム処理システムにおけるデータストリームのエンドツーエンドオーバーレイパスを提供するオーバーレイネットワークに現在配備されているクエリに関する部分的配備プランを作成することと、
    前記クエリのためのローカル演算子の上流側演算子によって消費される帯域幅に関する統計を記憶することと、
    前記ローカル演算子までのクエリレイテンシに関する統計を記憶することと、
    各部分的配備プランについて、前記部分的配備プランについて前記消費される帯域幅及びレイテンシと、前記現在配備されているクエリについて前記消費される帯域幅及びレイテンシとの間の差を評価することと、
    各部分的配備プランについて、前記部分的配備プランが前記配備されたクエリよりも良好であること及び前記部分的配備プランがＱｏＳメトリック制約を充足することを、前記評価された差が示す場合に、その部分的配備プラン及びその部分的配備プランのその後の評価のためのメタデータとを記憶することと
    を含む
    コンピュータ可読記憶媒体。
15. 前記クエリは、前記オーバーレイネットワーク内のノードによってホスティングされる複数の演算子を含み、前記ノードのそれぞれは、前記クエリに関して事前に計算された複数の配備プランを共に形成する部分的配備プランを作成し、評価し、及び記憶する
    請求項１４に記載のコンピュータ可読媒体。

Images