JP2015505404A - クラウド・エッジ・トポロジー - Google Patents

Abstract

この説明は、クラウド・エッジ・トポロジーに関係するものである。ある種の態様は、様々なクラウド・エッジ・トポロジー内のクラウド・エッジ・アプリケーションおよびリソース使用量に関係するものである。本発明のクラウド・エッジ・トポロジーの別の態様は、一時性言語を使用するクラウド・エッジ・アプリケーションの仕様記述に関係するものであり得る。さらなる態様は、クエリ部分を走らせるためにクラウドおよびクラウド・エッジ・コンピュータ上でデータ・ストリーム管理システム（ＤＳＭＳ）エンジンを走らせるアーキテクチャを必然的に含み得る。

Description

一実施形態は、クラウドコンピューティングに関し、より具体的にはクラウド・エッジ・トポロジーに関する。

消費者によるスマートフォンなどの「スマート」ポータブル・コンピューティング・デバイスの採用が普及し、莫大な量のクラウド・ベース・コンピューティング・リソースが利用可能であることが、「クラウド・エッジ・トポロジー」として知られているものをもたらした。これらのスマート・ポータブル・コンピューティング・デバイスは、プロセッサおよびメモリの発達によって、これらのデバイスが、ユーザに利用可能な相当のコンピューティング・リソースを有することが可能になるという点で、「スマート」と呼ばれている。スマート・ポータブル・コンピューティング・デバイスは、ＧＰＳ位置、バッテリ消費、速度等のようなリアルタイム・データを生成することが可能である。これらのスマート・ポータブル・コンピューティング・デバイスを、個々のデバイスとクラウド・ベース・リソースとの間の通信をエッジと考えることが可能であるという点で、クラウド・エッジ・デバイスと考えることもまた可能である。

スマート・ポータブル・コンピューティング・デバイス上で利用可能な相当のコンピューティング・リソースが与えられる場合、ユーザは、自分のデバイス上で走る様々なアプリケーションを選択することが可能である。これらのアプリケーションの多くは、アプリケーション・インスタンスがスマート・ポータブル・コンピューティング・デバイス上で走り、別のアプリケーション・インスタンスがクラウド・ベース・コンピューティング・リソース上で走るという点で、クラウド・エッジ・アプリケーションと呼ばれる場合がある。複数のスマート・ポータブル・コンピューティング・デバイスにわたるデータとクラウドとを相関させてアプリケーションの機能性を実現する、広範な部類のクラウド・エッジ・アプリケーションが存在する。一例は、ユーザに、だれか友人がすぐそばにいるかどうかを通知するように機能する友人探し（ｆｒｉｅｎｄ−ｆｉｎｄｅｒ）アプリケーションである。このアプリケーションの機能性は、リアルタイム位置とソーシャル・ネットワークなどの遅く変化するデータとの相関によって決まる。大量のコンピューティング・リソースがスマート・ポータブル・コンピューティング・デバイスおよびクラウド・ベース・リソース上で利用可能である一方で、通信リソースなどのリソース使用量が、多数のスマート・ポータブル・コンピューティング・デバイスがクラウド・エッジ・アプリケーションを走らせているときには意味をもつものとなり得る。

この説明は、クラウド・エッジ・トポロジーに関係するものである。ある種の態様は、様々なクラウド・エッジ・トポロジー内のクラウド・エッジ・アプリケーションおよびリソース使用量に関係するものである。一例では、複数の異なるエッジ・コンピューティング・デバイスからのデータを利用するリアルタイム・ストリーミング・クエリを評価することが可能である。複数の異なるエッジ・コンピューティング・デバイスは、クラウド・ベース・リソースと通信するように、ただし、相互に直接通信しないように構成され得る。個々のエッジ・コンピューティング・デバイスは、宣言型一時性言語（ｄｅｃｌａｒａｔｉｖｅ ｔｅｍｐｏｒａｌ ｌａｎｇｕａｇｅ）の形で伝えられるアプリケーションのインスタンス化を含む。この例では、第１のシナリオと第２のシナリオとの間でリソース使用量を比較することが可能である。第１のシナリオは、処理のために、複数の異なるエッジ・コンピューティング・デバイスからクラウド・ベース・リソースにクエリ・データをアップロードすることを必然的に含む。第２のシナリオは、処理のために、複数の異なるエッジ・コンピューティング・デバイスの１つのノードを除くすべてからクラウド・ベース・リソースにクエリ・データをアップロードし、複数の異なるエッジ・コンピューティング・デバイスの１つのノードにクエリ・データをダウンロードすることを必然的に含む。

本発明のクラウド・エッジ・トポロジーの別の態様は、一時性言語を使用するクラウド・エッジ・アプリケーションの仕様記述に関係するものであり得る。さらなる態様は、クエリ部分を走らせるためにクラウドおよびクラウド・エッジ・コンピュータ上でデータ・ストリーム管理システム（ＤＳＭＳ）エンジンを走らせるアーキテクチャを必然的に含み得る。

上記の列挙した例は、読者の一助となる迅速な参照を提供することが意図されるものであり、本明細書で説明する概念の範囲を定義することは意図されない。

付随する図面は、本出願において伝えられる概念の実装形態を例示するものである。例示する実装形態の特徴を、付随する図面に連関して行う以下の説明を参照することにより、より容易に理解することが可能である。様々な図面において類似する参照番号が、類似する要素を指示することが可能な限り使用される。さらに、各々の参照番号の最も左の数字は、その参照番号が最初に導入される図および関連する論考を伝えるものである。

ある種の実装形態による、本発明のクラウド・エッジ・アプリケーション・リソース使用量概念を適用することが可能であるシステムの例を示す図である。 ある種の実装形態による、本発明のクラウド・エッジ・アプリケーション・リソース使用量概念を適用することが可能であるシステム・アーキテクチャの例を示す図である。 ある種の実装形態による、本発明のクラウド・エッジ・アプリケーション・リソース使用量概念を適用することが可能であるグラフ例を示す図である。 ある種の実装形態による、本発明のクラウド・エッジ・アプリケーション・リソース使用量概念を適用することが可能であるグラフ例を示す図である。 ある種の実装形態による、本発明のクラウド・エッジ・アプリケーション・リソース使用量概念を適用することが可能であるグラフ例を示す図である。 ある種の実装形態による、本発明のクラウド・エッジ・アプリケーション・リソース使用量概念を適用することが可能であるグラフ例を示す図である。 ある種の実装形態による、本発明のクラウド・エッジ・アプリケーション・リソース使用量概念を適用することが可能であるグラフ例を示す図である。 ある種の実装形態による、本発明のクラウド・エッジ・アプリケーション・リソース使用量概念を適用することが可能であるグラフ例を示す図である。 ある種の実装形態による、本発明のクラウド・エッジ・アプリケーション・リソース使用量概念を適用することが可能であるグラフ例を示す図である。 本発明の概念のある種の実装形態による、クラウド・エッジ・アプリケーション・リソース使用量技法の例のフローチャートを示す図である。

概要
本発明の概念は、クラウド・ベース・システム、ならびに、クラウド・ベース・システムおよび接続されたデバイス上で走るアプリケーションによる動的なリソース認識の処理に関係するものである。

解説の目的で、本発明の概念を実装することが可能であるシステム１００の例を示す導入の図１を考えてみる。システム１００は、３つのクラウド・エッジ・コンピューティング・デバイス（以降、「コンピューティング・デバイス」）１０２（１）、１０２（２）、および１０２（Ｎ）を含む（ここでＮは、任意の数のコンピューティング・デバイスを利用することが可能であることを物語る）。コンピューティング・デバイス１０２（１）〜１０２（Ｎ）は、それぞれ線１０８（１）〜１０８（３）により指示するように、ネットワーク１０６を介してクラウド１０４と通信することが可能である。この例では個々のコンピューティング・デバイスは、クラウド１０４を通して相互に通信することは可能であるが、他のコンピューティング・デバイスと直接通信することは可能でない。クラウド１０４は、莫大な量のコンピューティング・リソース１１０を供与することが可能であるが、これらのコンピューティング・リソースの正確な物理的位置は、容易には明らかになり得ないものである。クラウド・コンピューティングは、クラウド・コンピューティングが供与するコンピューティング・リソースが比較的安価であり豊富であるので、人気が増し続けている。

コンピューティング・デバイス１０２（１）〜１０２（Ｎ）は、任意のタイプのコンピューティング・デバイスであり得る。普通はこれらのコンピューティング・デバイスは、スマート・フォンおよびタブレット・コンピュータなどのポータブル・コンピューティング・デバイスである。本明細書では用語「コンピュータ」または「コンピューティング・デバイス」は、ある程度の量の処理能力を有する任意のタイプのデバイスを意味し得る。そのようなデバイスの具体的な例を解説の目的で例示するが、そのようなデバイスの他の例は、パーソナル・コンピュータ、セル電話、スマート・フォン、携帯情報端末などの従来のコンピューティング・デバイス、または、無数の絶えず進化している、もしくはまだ開発されていないタイプのデバイスの任意のものを含み得る。さらに独立型ではなく、コンピュータは別のデバイスに組み込まれる場合がある。例えばダッシュボード・コンピュータは、車または他の乗物に含まれ得る。

１つの観点から考察すると、コンピューティング・デバイス１０２（１）〜１０２（Ｎ）を、クラウド１０４およびネットワーク１０６によりサポートされるトポロジー内の「エッジ・デバイス」と考えることが可能である。これらのエッジ・デバイスの多くには、ユーザのＧＰＳ位置、速度、現在のアクティビティ、デバイスのバッテリ使用量等のようなリアルタイム・データの高頻度または継続的なストリームを生み出すセンサが装備される。加えて、例えばデータ市場によって、クラウドで利用可能にされている、ソーシャル・ネットワーク・グラフおよびガソリンスタンドでの燃料価格などの、ますます量が増える、より遅く変化する参照データが存在し得る。コンピューティング・デバイスおよびデータがこのように急増することが後押しして、新興の部類のリアルタイム・クラウド・エッジ・アプリケーション（または略してクラウド・エッジ・アプリ）への関心がますます高まってきている。これらのクラウド・エッジ・アプリは、多数のエッジ・コンピューティング・デバイスおよびクラウドから収集されるリアルタイム・フィードに基づいて、通知または推奨などのサービスを提供することが可能である。

ある種のシナリオではコンピューティング・デバイス１０２（１）〜１０２（Ｎ）は、クラウド・コンピューティング・リソース１１０上で走る１つまたは複数のサービス・プロバイダによる処理のために、クラウド１０４にそれらのコンピューティング・デバイスのデータを伝達する。例えば解説の目的で、１つのそのようなサービスが、ユーザに、自分の友人のだれかが自分の現在の位置の近くにいるときはいつでも通知する友人探しサービスであるということを仮定する。ある種の実装形態では友人探しサービスを、クラウド・コンピューティング・リソース１１０上で走る友人探しアプリケーション、および、個々のコンピューティング・デバイス１０２（１）〜１０２（Ｎ）上で走る対応する友人探しアプリケーションにより達成することが可能である。

友人探しアプリケーションを可能にするには、ユーザのスマートフォン（例えばコンピューティング・デバイス１０２（１）〜１０２（Ｎ））からのリアルタイム位置と、（友人関係を定義する）ソーシャル・ネットワークなどの遅く変化する参照データとの相関が必然的に必要となる。解説しやすいように、コンピューティング・デバイス１０２（１）および１０２（２）のみを考えるものとし、コンピューティング・デバイス１０２（１）はユーザ１に属するということ、および、コンピューティング・デバイス１０２（２）はユーザ２に属するということを仮定する。さらに、ユーザ１およびユーザ２は「友人」とみなされているということを仮定する。各々のコンピューティング・デバイスは、矢印１１２（１）および１１２（２）により指示するように、クラウドにデータを時折アップロードすることが可能である。アップロードされたデータを、クラウド・コンピューティング・リソース１１０上で動作するサービス・プロバイダにより処理することが可能である。サービス・プロバイダは、各々のコンピューティング・デバイスに対する結果を決定し、それぞれのコンピューティング・デバイス１０２（１）および１０２（２）に戻すようにそれらの結果を伝達することが可能である。ある種の場合ではそのような処理では、クラウド１０４とコンピューティング・デバイス１０２（１）および１０２（２）との間での、ネットワーク１０６を介した、大きな数のアップロードする通信およびダウンロードする通信が必然的に必要になる場合がある。本発明の概念によって、代替的な選択肢が可能になり得る。この代替的な選択肢は、動的なリソース認識の選択肢と考えることが可能であるものである。動的なリソース認識の選択肢では、コンピューティング・デバイス１０２（１）および１０２（２）の一方は、個々のコンピューティング・デバイスが、クラウドから他方のコンピューティング・デバイスのデータを取得し、個々のコンピューティング・デバイス上で局所的に処理に対処することにより、これらのネットワーク通信などのシステム・リソース使用量を削減することが可能であると決定することが可能である。（ネットワーク通信を、数により、および／またはネットワーク帯域幅使用量により考慮することが可能である。）そのような場合、その個々のコンピューティング・デバイスはアップロードしない。他方の（残りの）コンピューティング・デバイスは通常のようにアップロードし、その個々のコンピューティング・デバイスはダウンロードする。この動的なリソース認識の選択肢は、リソース使用量算出が、シナリオが変化する際に変化し得るという点で動的と考えることが可能である。１つのそのような例を、コンピューティング・デバイスが位置データを生成しているレートに関して下記で説明する。リソース使用量算出は、位置データのレートが変化するときに異なる結果を生み出す場合がある。したがって１回の決定であるのではなく、決定を、条件またはパラメータが変化する際に反復型の様式で繰り返す場合がある。

この削減されるリソース使用量を例示するために、コンピューティング・デバイス１０２（１）はユーザ１に属するものとし、コンピューティング・デバイス１０２（２）はユーザ２に属するものとする。さらに、ユーザ１は自分の職場で仕事をしており（例えば、比較的動かない）、ユーザ２は近くの界隈で車を運転しているということを仮定する。上記で説明した一定の構成において、既存の友人探しアプリは、ユーザ２（コンピューティング・デバイス１０２（２）に、クラウドがユーザ１の位置と相関させるためにユーザ２の最新の位置を知るように、高頻度で（例えば１０秒ごとに１回）ユーザ２の位置をアップロードする（１１２（２））ように求めることになる。これに対してユーザ１（コンピューティング・デバイス１０２（１））は、ユーザ１はあまり移動していないので、低頻度で（例えば１時間に１回）ユーザ１の位置をアップロードする（１１２（１））ことが可能である。この例では、ユーザ１およびユーザ２の全体の通信オーバーヘッドは、ネットワーク１０６を介して（最終的な通知メッセージを無視して）１時間あたり３６１メッセージとなる。このネットワーク使用量は、特にユーザが、多くの友人を有する、または多くのそのようなアプリを走らせるときには高価なものとなり得る。このことは、ユーザのデータを相関させる頻度の程度を制限することをアプリケーションが強制され、そのことによって通知のレイテンシが大きくなる結果になるので、アプリケーションの有用性を厳しく制限する可能性がある。さらにユーザは、アプリケーションのリソース使用量が高いことに起因して、アプリケーションを単にオフにする場合がある。しかしながらこの非効率性に関しては、動的なリソース認識の選択肢によって上記の例において容易に対応処理することが可能である。クラウドで相関させる方法論を使用する代わりに、ユーザ１の位置を、ユーザ２のコンピューティング・デバイス１０２（２）に（それぞれ矢印１１４および１１６により指示するようにクラウド１０４を通して）送出することが可能である。次いで相関を、ユーザ２のコンピューティング・デバイスにより遂行することが可能である。この場合、ユーザ２は自分の位置をどこかに送出する必要がなく、全体のコストは１時間あたり２メッセージのみ（一方はユーザ１からクラウドへ、および他方はクラウドからユーザ２へ）となる。ユーザ１が自宅に進行しているときなど、その後の時点では、動的なリソース認識の選択肢は、クラウド１０４で処理するなど異なる手法を決定し得ることに留意されたい。

要約すると、動的なリソース認識の選択肢は、（あるとすれば）何の計算をプッシュすべきか、および、どのエッジ・コンピューティング・デバイスに対してその計算をプッシュすべきかに関して決定することが可能である。この決定を、ネットワーク・トポロジー、データ・ストリームのレート、データのアップロードおよびダウンロードのコスト、相関させるべきストリームの対などのような様々な要因によって決まる最適化問題と考えることが可能である。さらに、これらのパラメータは経時的に変化し得る（例えばユーザ１のレートは、ユーザ１が職場での時間の後に進行を開始するときに変化し得る）ので、決定は動的に更新され得るものである。１つの動的なリソース認識の選択肢の実装形態は、ＲＡＣＥと呼ばれるものであり、下記で詳細に説明する。

手短に言えばＲＡＣＥ（リアルタイム・アプリケーション・オーバー・クラウド・エッジ（Ｒｅａｌ−ｔｉｍｅ Ａｐｐｌｉｃａｔｉｏｎｓ ｏｖｅｒ Ｃｌｏｕｄ−Ｅｄｇｅ）を表す）は、クラウド・エッジ・アプリを仕様記述し効率的に実行するためのフレームワークおよびシステムである。ＲＡＣＥは、データベース技法を使用して２つの主な態様に関して対応処理することが可能である。第１にＲＡＣＥは、リアルタイム・クラウド・エッジ・アプリケーションの仕様記述に関して対応処理する。第２にＲＡＣＥは、リアルタイム・クラウド・エッジ・アプリケーションの実行に関連するシステム・リソース使用量に関して対応処理する。システム・リソース使用量は高められ得る、および／または最適化され得る（以降では簡潔にするために、用語「最適化される」は「高められる、および／または最適化される」を意味する）。

クラウド・エッジ・アプリケーションの仕様記述
ＲＡＣＥは、１組のストリーミング・データ・ソースにわたってプラットフォーム非依存の継続的クエリ（ＣＱ）としてクラウド・エッジ・アプリのコア・ロジックを抽出することにより、リアルタイム・クラウド・エッジ・アプリケーションの仕様記述に関して対応処理する。

クラウド・エッジ・アプリは、Ｏｂｊｅｃｔｉｖｅ Ｃ、Ｊａｖａ(登録商標)、またはＣ＃などの標準的な命令型言語の形で表記されることが多い。アプリケーション開発者は、クロス・デバイス通信、データ・ストリームに対するパブリッシュおよびサブスクライブ、ならびに、一時性結合（ｔｅｍｐｏｒａｌ ｊｏｉｎ）およびウィンドウが設定された計算などのアプリケーション・ロジック内の時間に関係する意味規則に対処する機構を手動で実装するように求められる。この処理は、時間がかかりエラーが起こりやすいものである。ＲＡＣＥは、大多数のクラウド・エッジ・アプリにより共有される共通の機能性に対するプラットフォーム・サポートを追加することが可能である。したがってアプリケーション設計者は、実装形態細部ではなくコア・アプリケーション・ロジックに重点を置くことが可能である。

本発明の実装形態は、異なるクラウド・エッジ・アプリが多様な特定用途の特徴（例えば、視覚化およびプライバシーに対するサポート）を有する一方で、それらのクラウド・エッジ・アプリはある種の共通性を共有することが可能であるという事実を活用する。例えば、クラウド・エッジ・アプリに対するデータおよびコア・アプリケーション・ロジックの両方は本質的に一時性であることが多い。換言すればクラウド・エッジ・アプリを、大規模分散システムにおいて、リアルタイムのデータと、より遅く変化する（ただしそれでも一時性の）参照データとを継続的に相関させる継続的クエリとみなすことが可能である。

例えば友人探しアプリを、エッジ・デバイスのリアルタイムＧＰＳ位置と、より遅く変化するソーシャル・ネットワーク・ストリームとの間の一時性結合と考えることが可能である。位置認識のクーポン・アプリケーションは、（履歴の時間ウィンドウにわたって計算された）ユーザのプロファイルを伴う現在のユーザ位置情報と現在の広告とを相関させる。したがってある種の実装形態では、クラウド・エッジ・アプリに対する仕様記述言語は、一時性意味規則に対するネイティブ・サポートを包含すべきである。そのようなサポートによって、一時性結合およびウィンドウが設定された集約などの時間指向の動作の誤りのない表現が可能になる。代替的または追加的に、言語は他の特質を有し得る。例えば１つのそのような特質は、仕様記述言語の宣言型の性質である。このことによってアプリケーション設計者は、宣言型の、およびネットワーク・トポロジー非依存の様式でアプリケーションを仕様記述することが可能になり得るものであり、その場合アプリケーション設計者は、アプリケーションが「どのように」実装されるかではなく、アプリケーションが「何」であるかに重点を置くことが可能である。実装形態細部は、アプリケーション設計者にとって意識されないようなものであり得るものであり、その代わりに表層下のプラットフォームにより自動的に対処され得る。別の特質は、簡明性に関係し得るものである。アプリケーションの仕様記述は簡明であり得るものであり、アプリケーション設計者による生産的なプロトタイピング、デプロイメント、およびデバッグを可能にし得る。簡明性は、当然ながら宣言型仕様記述を採用することに適合している。柔軟性は、別の特質であり得る。仕様記述言語は、アプリケーション設計者が異なる入出力ソースおよび構成によってアプリケーションを容易にカスタマイズすることが可能であるように柔軟であり得る。

次に仕様記述言語の設計空間を、これらの特質に照らして説明する。ＳＱＬおよびＤａｔａｌｏｇ（およびその異形、例えばＮｅｔｗｏｒｋ Ｄａｔａｌｏｇ）などの宣言型言語によって、分散環境での継続的クエリの簡明で柔軟な仕様記述が可能になり得る。しかしながらこれらの言語は、一時性意味規則に対するネイティブ・サポートを有しておらず、そのことは大多数のクラウド・エッジ・アプリにとっては重大であり得る。他方でデータ・ストリーム管理システム（ＤＳＭＳ）は、所望の特質を満たす宣言型一時性言語を使用する。例は、ＳｔｒｅａｍＩｎｓｉｇｈｔ（商標）に対するＬＩＮＱ（商標）、およびＯｒａｃｌｅ（登録商標）ＣＥＰに対するＳｔｒｅａｍＳＱＬ（商標）、およびＳｔｒｅａｍＢａｓｅ（商標）を含む。下記の説明は、仕様記述言語としてＳｔｒｅａｍＩｎｓｉｇｈｔに対するＬＩＮＱを利用するが、他の構成に適用可能である。ＬＩＮＱは、一時性クエリの宣言型仕様記述を可能にするものであり、クラウド・エッジ・アプリの一時性の性質に十分に適する、良好に定義された代数および意味規則に基づく。

後に続く論考では、クラウド・エッジ・アプリ仕様記述の例を提供する。友人探しクエリは、条件：１）ユーザ２はユーザ１の友人である、および、２）２人のユーザは所与の時間に相互に地理的に近い、を満たすすべてのユーザ対（ユーザ１，ユーザ２）を探し出すということを想起されたい。この点で、解説の目的で、友人関係が非対称である、すなわち、ユーザ２がユーザ１の友人であるということが、ある時点で考えると必ずしも逆のことを含意するとは限らないということを仮定する。友人探しアプリに対する２つの入力、すなわち、エッジ・デバイスにより報告されるＧＰＳ位置ストリーム、およびソーシャル・ネットワーク・データが存在する。ＧＰＳ位置はランタイムに活発に収集され、一方でソーシャル・ネットワーク・データは、比較的遅く変化し、一般的にはクラウドで利用可能である。友人探しを、下記に例示するように２つの段階の一時性結合クエリとして表記することが可能である。

第１のクエリ（ｑｕｅｒｙ０）は、ＧＰＳ位置ストリーム（ｌｏｃａｔｉｏｎ）をソーシャル・ネットワーク参照ストリーム（ｓｏｃｉａｌＮｅｔｗｏｒｋ）に結合し、結果として得られる出力ストリームが、友人の各々の対の間の距離をチェックするために、（ｑｕｅｒｙ１において）再度ＧＰＳ位置に結合される。最終的な出力は、２人のユーザが友人であり相互に地理的に近い、対（ユーザ１，ユーザ２）のストリームである。

上記のクエリ仕様記述は、一時性結合としてクエリの高レベル・ロジックを定義し、ｌｏｃａｔｉｏｎストリームおよびｓｏｃｉａｌＮｅｔｗｏｒｋストリームのスキーマを参照する。そのクエリ仕様記述は、ソーシャル・ネットワーク・ストリームおよび概念的に統合されるＧＰＳ位置ストリーム入力に対して表記され、したがってネットワーク・トポロジー非依存である。別の例として、所望の機能が、ここ１週間以内に特定の位置（例えば料理店）を訪れた友人を探し出すことであるということを仮定する。このことを仕様記述するために、本発明の概念では、ｑｕｅｒｙ１でのｌｏｃａｔｉｏｎ入力をｌｏｃａｔｉｏｎ．ＡｌｔｅｒＥｖｅｎｔＤｕｒａｔｉｏｎ（ＴｉｍｅＳｐａｎ．ＦｒｏｍＤａｙｓ（７））で置き換えることを可能にし得る。このことによって、ｌｏｃａｔｉｏｎイベントの「存続時間」が７日間に延び、そのことによって結合が、ここ１週間以内の友人からのイベントを考慮することが可能になる。

要約するとＲＡＣＥは、クラウド・エッジ・アプリの宣言型仕様記述を利用することが可能である。ＲＡＣＥは、エッジ・デバイスおよびクラウドから構成される分散システム上でロジックを実行することが可能である。ＲＡＣＥは、修正されないＤＳＭＳをブラック・ボックスとして使用して、個々のエッジ・デバイスおよびクラウド上でクエリを局所的に実行することが可能である。ある種のＲＡＣＥ実装形態は、ＤＳＭＳが、（実行されることになる継続的クエリを定義する）クエリ、（入力データ・ストリームのスキーマを指定する）イベント・タイプ、ならびに、（ストリーミング・データが外側の世界からＤＳＭＳに、およびその逆にどのように到達するかを定義する）入力および出力のアダプタを付託するために、ユーザに管理アプリケーション・プログラム・インターフェース（ＡＰＩ）を提供するという仮定を基に動作する場合がある。さらにＡＰＩによって、ユーザがＤＳＭＳ上のクエリを開始および停止することもまた可能になる。

言い換えればある種の実装形態は、異なるデータ・ストリーム（またはストリームの一部）をクラウドに、および／または、クラウドを介して他のエッジ・コンピューティング・デバイスに移動させることが可能である。ある種の他のデータ・ストリームは、デバイスで局所的に保持され得るものであり、クラウドにはアップロードされ得ない。さらにこれらの様々な（移動させられた、および局所的な）ストリームは、様々な位置で（デバイスのサブセットなど、またはクラウドでも）走るアプリケーション・クエリ・セグメントへの入力として役立ち得るものである。そのようなクエリの出力ストリームは、それら自体は、さらなる計算のために局所的に保持されるか、クラウドにアップロードされる（および、その後場合によっては他のデバイスに転送される）かのいずれかであり得る。全体的には、エンド・ユーザにより仕様記述される計算を、分散型の様式で遂行することが可能である。

ＲＡＣＥアーキテクチャ
図２は、１つのＲＡＣＥ実装形態の全体的なシステムまたはシステム・アーキテクチャ２００を示す。システム・アーキテクチャ２００は、図１からコンピューティング・デバイス１０２（１）〜１０２（Ｎ）、クラウド１０４、およびネットワーク１０６を引き継いでいる。システム・アーキテクチャ２００は、ＲＡＣＥ管理サービス２０２およびＲＡＣＥプロセッサ２０４を導入する。ＲＡＣＥプロセッサは、グラフ・コンストラクタ２０６、オプティマイザ２０８、およびクエリ・コンストラクタ２１０を含む。システム・アーキテクチャ２００は、統計データ２１４、参照データ２１６、制御プレーン２１８、およびデータ・プレーン２２０もまた含む。コンピューティング・デバイス１０２（１）〜１０２（Ｎ）は、それぞれＤＳＭＳ２２２（１）〜２２２（３）のインスタンスを含む。ＤＳＭＳインスタンス２２２（４）がさらに、クラウド１０４内に見出される。

システム・アーキテクチャ２００を、アプリケーション開発者２２４にもたらされる使用感に関して解説する。アプリケーション開発者は、ＬＩＮＱ２２６などの宣言型および一時性の言語の形でアプリケーションを表記することにより、ＲＡＣＥ管理サービス２０２とインターラクションすることが可能である。解説の目的で、アプリケーションは友人探しアプリ２２８であるということを仮定する。友人探しアプリの機能性は、図１に関して上記で紹介している。友人探しアプリ２２８は、それぞれ友人探しアプリ・インスタンス化２２８（１）〜２２８（３）として個々のコンピューティング・デバイス１０２（１）〜１０２（Ｎ）上で、および、友人探しアプリ・インスタンス化２２８（４）としてクラウド１０４上で顕在化し得る。さらに、簡潔にするためにコンピューティング・デバイス１０２（１）に関して例示するだけであるが、個々のコンピューティング・デバイスは、様々なハードウェア２３０を含み得る。この例では例示するハードウェアは、プロセッサ２３２、記憶装置２３４、および、他のもの２３６である。上記で述べた要素を、下記でより詳細に説明する。

プロセッサ２３２は、コンピュータ可読命令の形式でのデータを実行して、友人探し機能性などの機能性を提供することが可能である。コンピュータ可読命令などのデータを、記憶装置２３４上に記憶することが可能である。記憶装置は、コンピューティング・デバイスの内部または外部にあり得るものである。記憶装置２３４は、揮発性もしくは不揮発性のメモリ、ハード・ドライブ、および／または、光記憶デバイス（例えばＣＤ、ＤＶＤ等）などの、いずれか１つまたは複数を含み得る。

コンピュータ１０２（１）を、記憶装置２３４からのコンピュータ可読命令の形式でのデータを受信および／または生成するように構成することもまた可能である。コンピュータ１０２（１）は、ネットワーク１０６を介して、コンピュータ可読命令の形式でのデータを受信することもまた可能であり、そのデータは次いで、コンピュータのプロセッサによる実行のためにコンピュータ上に記憶される。

代替的な構成ではコンピュータ１０２（１）を、システム・オン・チップ（ＳＯＣ）タイプの設計として実装することが可能である。そのような場合では、コンピュータにより提供される機能性を、単一のＳＯＣまたは複数の連結したＳＯＣ上に集積することが可能である。ある種の構成ではコンピューティング・デバイスは、共有リソースおよび専用リソースを含み得る。インターフェース（複数可）によって、共有リソースと専用リソースとの間の通信が容易になる。その名前が含意するように、専用リソースを、具体的な機能性を実現することに対して専用である個々の一部分を含むと考えることが可能である。共有リソースは、複数の機能性により使用され得る記憶装置、処理ユニット等であり得る。

一般的に、本明細書で説明する機能のいずれも、ソフトウェア、ファームウェア、ハードウェア（例えば固定論理回路）、手動処理、またはこれらの実装形態の組み合わせを使用して実装することが可能である。本明細書では用語「ツール」、「コンポーネント」、または「モジュール」は一般的に、ソフトウェア、ファームウェア、ハードウェア、デバイスもしくはネットワークの全体、またはそれらの組み合わせを表す。例えばソフトウェア実装形態の場合、これらの用語は、プロセッサ（例えば、ＣＰＵまたは複数のＣＰＵ）上で実行されるときに、指定されたタスクを遂行するプログラム・コードを表し得る。プログラム・コードを、コンピュータ可読記憶媒体などの１つまたは複数のコンピュータ可読メモリ・デバイス内に記憶することが可能である。コンポーネントの特徴および技法はプラットフォームから独立しており、このことは、それらの特徴および技法を、種々の処理構成を有する種々の市販のコンピューティング・プラットフォーム上で実装することが可能であることを意味する。

本明細書では用語「コンピュータ可読媒体」は、一時的および非一時的な命令を含み得る。対照的に用語「コンピュータ可読記憶媒体」は、一時的なインスタンスを除外する。コンピュータ可読記憶媒体は、「コンピュータ可読記憶デバイス」を含み得る。コンピュータ可読記憶デバイスの例は、ＲＡＭなどの揮発性記憶媒体、ならびに、ハード・ドライブ、光ディスク、およびフラッシュ・メモリ等のような不揮発性記憶媒体を含む。

他のハードウェア２３６は、様々なコンピューティング・デバイス上で実装され得るディスプレイ、入出力デバイス、センサ等を含み得る。

ＲＡＣＥ管理サービス２０２は、クラウド１０４内で走り得るものであり、ＤＳＭＳの管理ＡＰＩと完全に互換性がある管理サービスを公開し得る。したがって個々のコンピューティング・デバイス１０２（１）〜１０２（Ｎ）は、それぞれのＤＳＭＳ２２２（１）〜２２２（Ｎ）によりサポートされる正規の一時性宣言型クエリとして、ＲＡＣＥ管理サービス２０２にコンピューティング・デバイス１０２（１）〜１０２（Ｎ）の宣言型クラウド・エッジ・アプリ・ロジックを付託することが可能である。エッジ・デバイスの観点（例えばコンピューティング・デバイス１０２（１）〜１０２（Ｎ））からは、それらのデバイスは単に通常のＤＳＭＳエンジンと通信するように見えるということに留意されたい。

別の観点から考察すると、ＲＡＣＥ管理サービス２０２を、クラウド上で、および、クラウドと通信している個々のエッジ・コンピューティング・デバイスで実行するアプリケーションとインターラクションするように構成されると考えることが可能である。ＲＡＣＥ管理サービス２０２は、ＤＳＭＳエンジンを模倣して、個々のエッジ・コンピューティング・デバイスから一時性宣言型クエリを受信するように構成され得る。

手短に言えばＲＡＣＥプロセッサ２０４を、友人探しアプリ２２８を走らせる個々のコンピューティング・デバイス１０２（１）〜１０２（Ｎ）からの入来するクエリ、アダプタ、およびタイプを、インターセプトおよびパースすると考えることが可能である。次いでＲＡＣＥプロセッサ２０４は、これらの入力を元のクエリのオブジェクト表現にコンパイルする。オブジェクト表現はグラフ・コンストラクタ・モジュール２０６に渡され、グラフ・コンストラクタ・モジュール２０６は、元のクエリをより大きなクエリ・グラフに変換する。例えばより大きなクエリ・グラフは、エッジごとの入力ストリームおよび演算子を含み得る。クエリ・グラフは、最適演算子配置を確定するためにオプティマイザ・モジュール２０８に渡される。最終的にクエリ・コンストラクタ・モジュール２１０が、個々のコンピューティング・デバイス１０２（１）〜１０２（Ｎ）上で、またはクラウド１０４で実行されることになる、タイプ、アダプタ、および（サブ）クエリのオブジェクト表現を生成することが可能である。これらのオブジェクトは、分散型の方式でアプリケーション・ロジックを実行するために、それぞれのコンピューティング・デバイスの個々のＤＳＭＳに（それらの管理ＡＰＩによって）送出される。この構成では、ＲＡＣＥ管理サービス２０２およびＲＡＣＥプロセッサ２０４はクラウド１０４上で実装されるが、他の実装形態では代替的または追加的に、ＲＡＣＥ管理サービスおよび／またはＲＡＣＥプロセッサを、コンピューティング・デバイス１０２（１）〜１０２（Ｎ）の１つまたは複数上で実装することが可能であるということに留意されたい。コンピューティング・デバイス上で実装されるＲＡＣＥ管理サービスおよび／またはＲＡＣＥプロセッサは、独立型である場合があり、または、クラウド上の対応するＲＡＣＥ管理サービスおよび／もしくはＲＡＣＥプロセッサのインスタンス化とともに協働的な様式で作動する場合がある。

グラフ・コンストラクタ２０６を、ストリーム・レートに関する統計値および各々の入力に関するメタデータ情報とともに、入力としてクエリのオブジェクト表現を受け取ると考えることが可能である。グラフ・コンストラクタは最初に、クエリのオブジェクト表現を使用して、拡大されたクエリ・グラフを生成するためのテンプレートまたはスケルトンを表すクエリ・パターンを生成することが可能である。例えば図３は、段落２５に関して上記で説明した友人探しクエリに対してグラフ・コンストラクタ２０６により出力されるクエリ・パターン３０２を例示する。

クエリ・パターン３０２内の入力ストリームのある種のものは、ＧＰＳ位置ソースなどのデバイスごとのデータ・ストリームを指す。グラフ・コンストラクタ２０６は、クエリ・パターンの複数のインスタンスを、そのようなストリームを、エッジごとに１つである複数の入力に分割することにより発生させることが可能である。ソーシャル・ネットワークなどの遅く変化する参照データ入力を、生成されるクエリ・グラフのサイズを制限するように具現することが可能である。例えば図４は、４人のユーザＰ、Ｑ、Ｒ、およびＳのソーシャル・ネットワーク４００を示す。図５は、友人探しクエリに対しての対応するインスタンス化されたクエリ・パターン５０２（１）、５０２（２）、および５０２（３）を示す。情報共有を可能にし、インスタンス化されたクエリ・パターン内の重複したエッジを回避するために、インスタンス化されたソースおよび結合演算子は、図５に示すように慎重に名前が付けられることに留意されたい。最終的なステップは、インスタンス化されたクエリ・パターン５０２（１）〜５０２（３）を完成したクエリ・グラフにまとめることである。

図６は、図５に示すインスタンス化されたクエリ・パターンから導出される最終的なクエリ・グラフ６０２を示す。インスタンス化されたクエリ・パターンを組み合わせるとき、同じ名前を伴う（インスタンス化されたパターン内の）頂点は、最終的なクエリ・グラフ内の同じ頂点にマッピングされることに留意されたい。例えば、結合＜ＧＰＳ−Ｐ，ＳＮＰ＞頂点は、エッジ（Ｐ；Ｒ）および（Ｐ；Ｓ）に対するインスタンス化されたパターンにより共有されている。

図２に戻ると、オプティマイザ・モジュール２０８が、入力として最終的なクエリ・グラフ６０２を受け入れ、アプリケーションの全体の、または集合的な通信コストが最小限に抑えられる（または少なくとも削減される）ように、クエリ・グラフ内の各々の演算子（例えばクエリ部分）をどこで実行すべきかを確定する。数千、または数百万ものユーザがクラウド・エッジ・システムに参加する状態では、最終的なクエリ・グラフは、数百万の演算子を包含する巨大なものとなり得る。そのような大きなクエリ・グラフに対しては、最適演算子配置は自明なことではない。ＲＡＣＥオプティマイザ・モジュールは、様々な技法を利用して、最適演算子配置を決定することが可能である。１つのそのような技法を、下記で「最適演算子配置」の見出しの下で説明する。ＲＡＣＥは、周期的な再最適化を遂行して、クエリ・グラフおよび／または統計値の変化に対して配置を調整することが可能である。

高められた／最適演算子配置に関する確定が行われた後、ＲＡＣＥプロセッサ２０４は、（各々が一時性演算子の有向非巡回グラフ（ＤＡＧ）からなる）１組の根の付いたクエリ・グラフを有する。各々のそのようなグラフは、ある種の位置（エッジまたはクラウド）に対応する。クエリ・コンストラクタ・モジュール２１０は、各々のグラフに対する（イベント・タイプ、アダプタ、およびクエリを含む）クエリ・コンポーネントのオブジェクト表現を生成することが可能である。次いでクエリ・コンストラクタ・モジュールは、制御プレーン２１８によって対応するＤＳＭＳにオブジェクト表現を付託することが可能である。２つの追加的なアダプタを各々のＤＳＭＳインスタンスに設置することが可能であり、１つはデータ・プレーン２２０にイベント・データを送出するためのものであり、もう１つはデータ・プレーンからイベント・データを受信するためのものであるということに留意されたい。

ＲＡＣＥ制御プレーン２１８は、ＤＳＭＳの管理ＡＰＩを使用して、ＤＳＭＳのクラウド・インスタンスおよびエッジ・インスタンスに、生成されたクエリ・フラグメントおよびメタデータをデプロイするために使用される。厄介な問題となるのが、エッジ・デバイス（例えば電話）は、普通はＲＡＣＥ管理サービス２０２からは直接到達可能またはアドレス指定可能ではないということである。代わりにＲＡＣＥ管理サービスは、エッジ・デバイスが、エッジ上のＤＳＭＳインスタンスに転送される管理コマンドを受信するために永続的な接続を発生させ維持する相手であるサーバを維持することが可能である。クエリ実行中に、イベントがエッジ・デバイスとクラウドとの間を流れる。ＲＡＣＥ管理サービス２０２は、クラウド１０４でのサーバとして公開されている離隔したデータ・プレーン２２０を使用することが可能であり、データ・プレーン２２０にエッジ・コンピューティング・デバイス１０２（１）〜１０２（Ｎ）は、制御プレーン２１８によって接続することが可能である。エッジ・コンピューティング・デバイスおよびクラウド上の生成されたクエリは、データ・プレーン２２０に登録される名前が付けられたストリームに関するサブスクライブおよびパブリッシュを行う。データ・プレーンは、クラウド１０４からエッジ・コンピューティング・デバイス１０２（１）〜１０２（Ｎ）に、およびその逆にイベントをルーティングする。

数千、または数百万ものユーザがクラウド・エッジ・システムに参加する状態では、最終的なクエリ・グラフは、数百万の演算子を包含する巨大なものとなり得る。データ・ソースは分散されている（例えば、様々なユーザのＧＰＳデータ・ストリームは、それらのユーザのエッジ・デバイスから発出させられる）ので、あらゆる演算子の配置は、その影響をクエリ評価のオーバーヘッドに与える。演算子配置の指数関数的に多くの異なる組み合わせが存在する。設計空間全体を検索する単純な手法は、実現可能ではない場合がある。加えて中間結果を共有することを考慮すると、問題はさらに難しくなる。

以下の論考は、クラウド・エッジ・システムの特別な「スター」トポロジーを活用することによる、最適演算子配置のための効率的なアルゴリズムの例に関係するものである。ある種の実装形態に関して、アルゴリズムが正しいことを、下記で述べる２つの仮定が与えられる場合に証明することが可能である。さらに、最適配置を探し出すオーバーヘッドは非常に低くなり得る。

仮定１．クエリの最終的な出力は、入力ストリーミング・データより比較的はるかに小さく、したがってそのコストは無視され得る。

この仮定は、クラウド・エッジ・アプリの一般的な性質を考え合わせると合理的なものである。加えてプライバシーの考慮に基づいて、ある種の実装形態は、演算子の許される位置を制約する場合がある。例えばストリーミング・データは、取り扱いに注意を要する個人情報（例えば、携帯電話の地理的位置追跡）を含み得る。エッジ・クライアントは、未加工の情報が（結合演算の最終的な結果から取り扱いに注意を要するデータを除外することにより）適正に処理されないならば、またはその未加工の情報が、許可されているノードに単に輸送されるならば、その未加工の情報を公開することを望まない場合がある。

仮定２．任意の結合

［外１］

（ただしＡおよびＢは、結合の入力ストリームである）に関して、結合演算は、ＡまたはＢが発出した、クラウドで、またはノード上でのいずれかで遂行される。

この仮定は、配置問題を簡単にはせず、依然として指数関数的な数の可能な演算子配置が存在することに留意されたい。その論拠および提案するアルゴリズムを提示する前に、いくつかのグラフに基づく明示的意味を説明する。

定義（要求）．対（ｖ_１，ｖ_２）として、ストリーミング・データ・ソースｖ_２が、別のソースｖ_１により生成されるデータを「要求する」（すなわち、その生成されるデータと相関することを必要とする）ということが意味され得る。

定義（要求グラフ）．クラウド・エッジ・アプリが与えられる場合、要求グラフＧ＝（Ｖ，Ｅ）が次のように定義される：頂点集合Ｖ＝｛ｖ｜ｖはストリーミング・データ・ソースである｝、およびＥ＝｛（ｖ_１，ｖ_２）｜（ｖ_１，ｖ_２）は要求対である｝。各々のエッジｅ＝（ｉ，）∈Ｅは、ｖ_ｊにより要求されるｖ_ｊのストリームのレートを指示するレートｒ_ｉｊに関連する。

図７は、図４に示すソーシャル・ネットワークが与えられる場合の、友人探しクエリに対する対応する要求グラフ７０２を示す。要求グラフ７０２内のエッジは、要求関係を例示する。例えばエッジ（ＧＰＳ−Ｐ，ＳＮ_Ｐ）は、Ｐから読み出すＧＰＳ（ＧＰＳ−Ｐ）がソーシャル・ネットワーク（ＳＮ_Ｐ）と相関させられるべきであるということを指示する。要求グラフでは結合演算子は、（結合演算子はストリームとして結合結果を生み出しているので）要求グラフ内の仮想的なデータ・ソースとして扱われる。実際には、要求グラフとクエリ・グラフとの間に１対１のマッピングが存在する。クエリ・グラフＧ^Ｑ＝（Ｖ^Ｑ，Ｅ^Ｑ）が与えられる場合、アルゴリズム１は対応する要求グラフＧ^Ｄ＝（Ｖ^Ｄ，Ｅ^Ｄ）を生成する。クエリ・グラフを、同様のアルゴリズムにしたがうことにより要求グラフからリエンジニアリングすることが可能である。

割り当て（ａｓｓｉｇｎｍｅｎｔ）：ダウンロード対アップロード．一般的には、分散クエリ評価のための最適演算子配置を確定することは難しい問題であることが知られている。提案するアルゴリズムの本質は、クラウド・エッジ・アーキテクチャの特別なネットワーク特質を活用することに根付くものである。この場合エッジ・コンピューティング・デバイスは、直接相互に通信することは可能でない。代わりに情報を交換するために、エッジ・コンピューティング・デバイスは、クラウド側のサーバを通してデータをアップロードまたはダウンロードしなければならない。

定義（アップロードおよびダウンロード）．要求グラフＧ＝（Ｖ，Ｅ）が与えられる場合、エッジ（Ｉ，ｊ）∈Ｅに対して、この実装形態は、ｖ_ｊがどこに配置されるかに関わらず（エッジ・コンピューティング・デバイスまたはクラウド・サーバのいずれでも）、ｖ_ｊが常に、（ｖ_ｉにより要求される）対応するストリームをクラウド・サーバで利用可能にするための活動を行うならば、（Ｉ，ｊ）上で「アップロードする」とｖ_ｊを特徴付け、そうでないならば、ｖ_ｉは（ｉ，ｊ）上で「ダウンロードする」と特徴付けられる。

直観的には、頂点がエッジ上でアップロードすることを確定すると（このことは、データ相関が求められていることを表す）、（データはすでにクラウド側で利用可能にされているので）相関はクラウド側で単に遂行され得るため、その頂点がクラウド側のサーバからこの相関のために何らかのデータをダウンロードする理由はない。以下の補助定理を考えてみる。

補助定理１．要求グラフＧ＝（Ｖ，Ｅ）が与えられる場合、その要求グラフの最適演算子配置、∀（ｉ，ｊ）∈Ｅにおいて、（ｉ，ｊ）は２つの状態の１つ、すなわち、ｖ_ｉが（ｉ，ｊ）上でアップロードしている（ただしダウンロードしていない）か、ダウンロードしている（ただしアップロードしていない）かのいずれかでなければならない。

証明．頂点ｖ_ｉ∈Ｖが、（ｉ，）上でアップロードおよびダウンロードの両方を行うことを確定するものとする。対応する相関のための結合演算子を、（仮定２によって）３つの位置、すなわちｖ_ｉ、ｖ_ｊ、およびクラウドに配置することが可能である。この場合結合演算子は、ｖ_ｉがｖ_ｉのストリームをすでにアップロードしている際は、最適配置においてｖ_ｉに配置され得ない。結合演算はクラウドで遂行され得たものであり、その場合クラウドは、ｖ_ｉにｖ_ｊのデータをダウンロードするための通信コストを節約する。したがってｖ_ｉは、（ｖ_ｉに配置される結合演算子がないので）（ｉ，）上でダウンロードしていない。

補助定理１は、要求グラフＧ＝（Ｖ，Ｅ）が与えられる場合、その要求グラフの最適配置から、Ｇ内の各々の頂点に関して行われる１組のアップロード対ダウンロードの確定へのマッピングが存在するという結論に対する裏付けを供与する。そのような１組の確定を、割り当てと定義する。

定義（割り当て）．要求グラフＧ＝（Ｖ，Ｅ）が与えられる場合、割り当てＡ：Ｅ→｛Ｄ，Ｕ｝が次のように定義される：頂点ｖ_ｊがエッジ（ｉ，ｊ）上でｖ_ｊのストリーミング・データをアップロードすることを確定するならばＡ_ｉ，ｊ＝Ｕであり、そうでないならばＡ_ｉ，ｊ＝Ｄである。

最適配置、およびその最適配置の対応する割り当てを、Ｐ^ｏｐｔおよびＡ^ｏｐｔと表すことが可能である。図８は、図７の要求グラフ７０２に対する最適配置（Ｐ^ｏｐｔ）を示す。図９は、対応する割り当て（Ａ^ｏｐｔ）を示す。最適演算子配置において、ＧＰＳ−ＰとＳＮ_Ｐとの間の結合がノードＰで遂行され、このことは、区分化されたソーシャル・ネットワーク・グラフＳＮ_ＰがノードＰに輸送されるべきである、すなわち、ＳＮ_Ｐがクラウドに「アップロードされ」、ＧＰＳ−Ｐはアップロードされないということを意味する。このことは、図９で与える割り当てと整合している。

疑問１）Ａ^ｏｐｔからＰ^ｏｐｔへの逆のマッピングが存在するかどうか、および、２）要求グラフが与えられる場合、Ａ^ｏｐｔを探し出す効率的なアルゴリズムが存在するかどうかを問うのは当然のことである。下記の論考は、最初は第１の疑問に関係するものであり、次いで徐々に第２の疑問に対する答えを展開する。

すべての割り当てを、実行可能な評価プランにマッピングすることが可能であるとは限らない。結合はすべてのその入力が同じ場所に位置することを求めるという、基本的な制約が存在する。したがって、異なるソース（エッジ・デバイス）から入力を受け取るどの結合に関しても、多くても１つのデバイスがダウンロードしている。

定義（実行可能性およびコンフリクト）．要求グラフＧ＝（Ｖ，Ｅ）が与えられる場合、割り当てＡが次の条件：∀ｅ＝（ｉ，）∈Ｅ、Ａ_ｉ，ｊ≠Ｄ∨Ａ_ｊ，ｉ≠Ｄを満たすならば、その割り当てＡは実行可能である。この条件を破るエッジを、コンフリクト・エッジと呼ぶ。

例えば図９は、どの相関に対しても、多くても１つのデータ・ソースがダウンロードすることを確定しているような、図７に示す要求グラフが与えられる場合の実行可能な割り当てを例示する。Ａ_{ＳＮＰ，ＧＰＳ−Ｐ}がダウンロードするように変更されるならば、そのことによって、エッジ（ＳＮ，ＧＰＳ−Ｃ）がコンフリクト・エッジであるので、割り当ては無効になることになる。

補助定理２．実行可能な割り当てＡが与えられる場合、Ａを、対応する演算子配置にマッピングすることが可能である。

証明．構造様式により証明する。演算子配置は、（アルゴリズム２として示す）ボトムアップ方式で確定される。基本の場合として、クエリ・グラフ内の葉頂点の位置が知られている（自明ではあるが、ストリーム・ソースである）。内部頂点（すなわち、結合演算子を表す仮想的な頂点）に関して、仮定２によれば、その内部頂点は、クラウド側のサーバに配置され得るものであり、そうでなければ、その内部頂点の入力の１つと同じ場所に位置する。すべてのその内部頂点の入力ソースがアップロードすることを確定するならば、結合演算子はクラウドに配置されるべきであり、そうでないならば、（割り当てＡが実行可能であることが与えられる場合）ダウンロードすることを確定する唯一無二の入力ソースが存在し、したがって結合演算子は、その入力ソースと同じ場所に位置させられるべきである。

定理４．５．最適演算子配置問題を、（補助定理１および補助定理２から直接導出される）最適コストによって実行可能な割り当てを探し出すことに転化させることが可能である。

単一レベル結合クエリ

この論考は、アプリケーションが単一レベル結合クエリとして仕様記述される単純型のシナリオによって開始する。この論考を、後に続く論考においてマルチレベル結合クエリに拡張する。

同じ要求レート

論考では最初に、要求グラフ内の任意の頂点ｉに関して、すべての外出するエッジに対するストリーム・レートが同じである、すなわち、∀（ｉ，ｊ）∈Ｅ；ｒ_ｉ，ｊ＝ｒ_ｉである、単一レベル結合クエリの特別な場合を考える。基本的に結合演算子は、結合演算を遂行するために各々の入力ストリームからの完全なストリーミング・データを求める。このことは、（射影または選択などの）フィルタリングが結合の前に遂行されないクエリに対応する。

割り当てのコストを直接考慮する代わりに、ある種の実装形態では、基本の実行可能な割り当て、すなわち、すべての頂点がそれらのストリーミング・データをアップロードすることを確定するという単純な解決策と比較して、（正にも負にもなり得る）アップロードおよびダウンロードを切り替えることの利得を計算することが可能である。アップロードからダウンロードに頂点ｉを切り替えることにより、利得を次のように計算することが可能である：利得_ｉ＝ｒ_ｉ−Σ_{（ｉ，ｊ）∈Ｅ}ｒ_ｊ。すなわち利得を、ｉのストリームと相関させられるすべてのストリームをダウンロードすることを代償としてｉのストリーミング・データをアップロードしないことの利益と考えることが可能である。

定義（大域的最適性）．要求グラフＧ＝（Ｖ，Ｅ）が与えられる場合、大域的最適割り当てに対するものが、全体の利得を最大化する実行可能な割り当てＡである。

大域的最適性を与える割り当てＡ^ｏｐｔを探し出すための以下の技法は、要求グラフ内の各々の頂点が、その頂点自体の利益に基づいて割り当て確定を局所的に行う貪欲な手法を考慮する。

定義（局所的最適性）．要求グラフＧ＝（Ｖ，Ｅ）が与えられる場合、各々の頂点ｖ∈Ｖに対して、ｖに対する局所的最適割り当ては、局所的利得を最大化するＡ_ｖに関する局所的確定である。具体的には、利得_ｖ＞０である場合にのみＡ_ｖ＝Ｄである。

局所的最適性が実際には大域的最適性と整合するということを証明することが可能であり、そのことには２つの含意がある。第１に、局所的最適性を計算することに関するオーバーヘッドは低く、要求グラフ内の頂点の次数の数に対して線形である。第２にそのことは、割り当て問題を、区分化し並列に解くことが可能であることを意味する。このことは、この技法はクラウドでの莫大な計算リソースを活用して効率的にその割り当て問題を解くことが可能であるので、要求グラフが巨大である場合には特に重要である。

定理１．要求グラフＧ＝（Ｖ，Ｅ）が与えられる場合、割り当てＡ＝｛Ａ_ｖ｜Ａ_ｖ＝ｖでの局所的最適割り当て、v∈Ｖ｝は実行可能である。

証明．矛盾により証明する。Ａ_ｉ＝ＤおよびＡ_ｊ＝Ｄであることを意味する、コンフリクト・エッジｅ＝（ｉ，ｊ）が存在するものとする。Ａ_ｉ＝Ｄであることは、利得_ｉ＝ｒ_ｉ−Σ_{（ｉ，ｊ）∈Ｅ}ｒ_ｊ＞０であるということを規定する。したがってｒ_ｉ＞ｒ_ｊである。同様に、ｒ_ｊ＞ｒ_ｉであることをＡ_ｊ＝Ｄであることから導出することが可能である。したがって矛盾する。

定理２．局所的最適性は大域的最適性と整合する、すなわち、大域的最適性を、局所的最適性を個々に適用することにより導出することが可能である。

証明．１）定理１は、局所的最適性を個々に適用することにより導出される割り当てが実行可能であることを示す。２）各々の局所的最適性は、隔離された物理的リンクに対する最大利得を計算することであり、大域的最適性は単に、物理的リンクに関する利得の加算である。

異なる要求レート

次に論考を、所与の頂点ｉに対して、他の頂点の各々により要求されるストリーム・レートが異なる場合があるシナリオを考慮するように拡張する。例えば友人探しアプリの場合では、特定のユーザに対するイベント・レートは、そのユーザの友人の各々に関して異なる場合がある。ここでは、より低いレートを伴うストリームを、より高いレートを伴うストリームを使用して構築することが可能であるということを仮定するものであり、このことは、サンプリング・フィルタを適用するクエリに対応する。換言すれば、ｘイベント／秒をサンプリングする必要があるフィルタを、任意のｙ≧ｘに対しての、ｙイベント／秒をサンプリングする別のフィルタにより提供することが可能である。そのようなシナリオでは、アップロードすること対ダウンロードすることに関する確定を、要求グラフ内の（各々の頂点ではなく）各々のエッジに対して行う必要がある。

レート

［外２］

が、

［外３］

であるように頂点ｉでソートされていると仮定すると、ｐ個のソートされたエッジに対する最適割り当てが、パターン［Ｕ，…，Ｕ，Ｄ，…，Ｄ］を有さなければならないということを確かめることは難しくない。

定義（局所的最適性）．ある割り当てにおいての利得

［外４］

を考えてみる。ある種の実装形態では、

［外５］

を選択し、上記で説明したパターンでの割り当てを構成することが可能である。

補助定理４．８．頂点ｉで局所的最適性を適用した後は、

［外６］

であること、そのことには、

［外７］

であることが含意されている。

証明．矛盾により証明する。

［外８］

であるとする。局所的最適性の定義によれば、

［外９］

となる。

［外１０］

であるので、ｊ＞ｋであることに注目されたい。また、

［外１１］

である。このことにより、（

［外１２］

が最適であるので）矛盾が発生する。

定理３．実行可能性定理（定理１）は依然として有効である。

証明．矛盾により証明する。コンフリクト・エッジｅ（ｖ_１，ｖ_２）が存在するものとする。補助定理３を適用することで、Ａ_{ｖ１，ｖ２}＝Ｄからｒ_{ｖ１，ｖ２}＞ｒ_{ｖ２，ｖ１}が、および、Ａ_{ｖ２，ｖ１}＝Ｄからｒ_{ｖ２，ｖ１}＞ｒ_{ｖ１，ｖ２}が与えられ、このことが矛盾を生み出す。

マルチレベル結合クエリ

マルチレベル結合クエリを考慮するとき、単一レベル結合クエリに対して開発されたアルゴリズムを単純に適用することを妨げる困難が存在し得る。例えば単一レベル結合クエリに関しては、結合演算子に対する出力ストリームのコストは、（最終的な出力が、入力ストリームと比較して無視できるということを仮定するので）考慮されない。しかしながらそのことは、マルチレベル結合クエリに関しての実情ではない。例えば、前のセクションで提示したアルゴリズムを単純に適用するとき、エッジ・デバイスは、他のストリームをダウンロードし、局所的に計算を遂行することを個々に確定することが可能である。しかしながら、出力ストリームがその後、（その最適配置がクラウド側である）より高いレベルの結合演算子に対して求められるという事実をエッジ・デバイスが認識しているならば、そのエッジ・デバイスは異なる確定を行う場合がある。下記の論考は、この課題が、単一レベル結合に対するアルゴリズムを拡張することによりどのように解決されるかに関係するものである。

仮定３．所与のエッジからのデータ・ストリームは、クエリ・グラフ内の任意の演算子の１つ以下の子部分木に現れる。

このことは合理的な仮定であり、その理由は、同じエッジ・デバイスからのストリームを単一のストリームに単に組み合わせること、または、これらのストリームが必然的に含まれる必要な計算を局所的に遂行することが可能であるからというものである。この仮定はソースまたは中間結果の共有を排除せず、特にその仮定は、クエリ・パターンが、異なるデータ・ソースにわたる左深木（ｌｅｆｔ−ｄｅｅｐ ｔｒｅｅ）である場合に常に有効であるということに留意されたい。

トップダウン方式での演算子配置

クエリ・グラフ内の内部結合演算子を、仮想的なストリーム・ソースとみなすことが可能であるが、それらの内部結合演算子の位置は確定される必要がある。直観的にはクエリ・グラフが与えられる場合、本発明の技法は、トップダウン方式で演算子に対するアップロード対ダウンロードの確定を行うことが可能である。例えば確定を、結合演算子に対応する所与の頂点ｖ_１に対して、その結合演算子の出力が輸送されるべき位置（その結合演算子の親演算子により行われる配置確定に基づく）が知られている限りにおいて行うことが可能である。単一レベル結合クエリに対するアルゴリズムを、行先に出力ストリームを輸送するコストを追加的に含むことにより、直接的に拡張することが可能である。

考慮されるただ１つの行先はクラウド側であるということに留意されたい。例えば、行先が別のエッジ・デバイスである（出力ストリームが、そのエッジ・デバイスに位置する別の頂点ｖ_２により求められるため）場合でも、この技法では、輸送コストのダウンロードする部分（すなわち、クラウド側からそのエッジ・デバイスに出力ストリームを送出するコスト）に関しては、このダウンロードするコストは、ｖ_２に対する利得を算出する際にすでに考慮されているので、考慮する必要がない。仮定１および３によって、頂点ｖ_１を考慮するとき、実際の配置確定は、その行先に関しては、それが、クラウドに、そうでなければ、ｖ_１（またはその部分木）が重複しない何か他のエッジに確かに配置されることになるので、無視され得るということが確実になるということに留意されたい。この主要な知見によってアルゴリズムの拡張が可能になるとともに、拡張されたアルゴリズムが依然として、実行可能で最適な割り当てを保証するということを容易に示すことが可能である。

トップダウン方式でのアップロード対ダウンロード

（単一レベル結合クエリに対する）先の手法は、アップロード対ダウンロードの確定が行われた後に、ボトムアップ方式で演算子の配置を導出するということに注目されたい。アルゴリズム３を、親演算子の配置ではなく（その配置が利用可能でない際に）親演算子の割り当てに基づいて、アップロード対ダウンロードの割り当てを確定するように微調整することが可能である。

親頂点ｖ_１の確定が知られると、ある種の実装形態は、子頂点ｖ_２に対して何の確定が行われるべきかを考慮することが可能である。やはりｖ_２は、アップロードまたはダウンロードのいずれかという、２つの選定対象を有する。

１つのシナリオでは、親頂点ｖ_１の確定がダウンロードであるならば、そのことは、出力をクラウド・サーバで利用可能にするための活動を行う必要性がないことを意味する。したがって、ｖ_２に対する局所的最適性を探し出すときには、出力ストリームのコストは利得を計算する際に考慮されない。

別のシナリオでは、親頂点ｖ_１の確定がアップロードであるならば、そのことは、ｖ_２の出力ストリームがクラウド・サーバで利用可能にされるべきであることを意味する。したがって、ｖ_２に対する局所的最適性を探し出すときには、出力ストリームのコストは考慮されるべきである。

アルゴリズム３は、入力として要求グラフＧ＝（Ｖ，Ｅ）を受け取り、最適演算子配置を計算する。アルゴリズムは包括的なシナリオに適用されるものであり、そのシナリオでは、マルチレベル結合クエリ、およびエッジごとの要求レートを仮定する（すなわち、所与の頂点から開始する要求エッジに関連するレートは異なる場合がある）。定理１および２によって、導出される割り当てが実行可能であり最適であるということを確かめることは難しくない。

非対称アップロード／ダウンロード・コスト

ここまでは上記の技法は、アップロード・コストおよびダウンロード・コストが同じであるという仮定を基に動作していた。しかしながら現実では、そのことが実情ではない場合がある。例えば、アップロードすることおよびダウンロードすることに対する帯域幅利用の単位あたりの価格は異なる場合がある（例えばクラウド・サービス・プロバイダは、ユーザがクラウド内にデータを給送することを勧奨するために非対称コストを導入する場合がある）。別の例としてエッジ・デバイスは、アップロードすることおよびダウンロードすることに対して異なるバッテリ消費を呈する場合がある。

後に続く論考は、非対称アップロード／ダウンロード・コストを考慮するものである。アップロードすることおよびダウンロードすることに対する単位あたりのコストを、Ｃ^ｕおよびＣ^ｄと表す。Ｃ^ｕ＜Ｃ^ｄであるシナリオに対しては、先のセクションで提示したＣ^ｕ＝Ｃ^ｄに対する結果が依然として有効である。基本的に、主要な実行可能性定理（定理１）の論拠は有効である。

他方で、最適演算子配置を確定することは、Ｃ^ｕ＞Ｃ^ｄである場合に関してはより難しい問題である。Ｃ^ｄ＝０である特別な場合に関しては、最適演算子配置問題は、古典的な重み付き最小頂点被覆（ｗｅｉｇｈｔｅｄ ｍｉｎ ｖｅｒｔｅｘ ｃｏｖｅｒ）（ＷＭＶＣ）問題からの転化により難しいことが証明可能であるということを示すことが可能である。本質的には、実行可能性定理はこれらの場合では破綻し、したがって、エッジ・デバイスに局所的最適性を個々に適用させることが、コンフリクトをもたらす場合がある。そのような場合、実行可能な割り当てを、より高いレートでアップロードするように要求グラフ内のある種の頂点を設定することによりコンフリクトを解決することにより取得することが依然として可能である。したがって問題は、効率的な一般解を欠く、残余グラフにおけるＷＭＶＣ問題に転化する。以下の論考は、条件に関係するものである。条件が満たされるならば、最適演算子配置問題を効率的に解くことが可能である。

定義．要求グラフＧ＝（Ｖ，Ｅ）が与えられる場合、頂点ｖ∈ＶのスキューＳ_ｖは、ｖからの外出するエッジに関連する最大レートと最小レートとの間の比として定義される。すなわち、Ｓ_ｖ＝ｍａｘ_{（ｖ，ｉ）∈Ｅ，ｉ）}ｒ_ｖ，ｉ／ｍｉｎ_{（ｖ，ｊ）∈Ｅ}ｒ_ｖ，ｊである。

定義．要求グラフＧ＝（Ｖ，Ｅ）が与えられる場合、Ｇのスキューは、Ｇ内のノードの中の最大スキューとして定義される。すなわち、Ｓ＝ｍａｘ_ｖ∈ＶＳ_ｖである。

表１：演算子配置アルゴリズムの要約を示す。大域的最適性がすべての場合において実現される。

補助定理４．グラフＧのスキューＳが与えられる場合、Ｃ^ｄ＜Ｃ^ｕ＜（１＋１／Ｓ）・Ｃ^ｄであるならば、すべての頂点に関して局所的最適性を適用した後、コンフリクト・エッジからなる残余グラフＧ’は非巡回である（すなわち、離隔した木である）。

証明．矛盾により証明する。残余グラフＧ’内に巡回（ｖ_１，ｖ_２）、（ｖ_２，ｖ_３）、…、（ｖ_{（ｐ−１）}，ｖ_ｐ）、（ｖ_ｐ，ｖ_１）が存在するものとする。提示の目的で、ｖ_０＝ｖ_ｐおよびｖ_{（ｐ＋１）}＝ｖ_１ということを意味するとする。巡回内のあらゆるエッジはコンフリクト・エッジであるので、∀１≦ｉ≦ｐに対して、

［外１３］

という、閉じていない範囲が存在する。
これらの不等式を加算することにより、次式を導出することが可能である。

［外１４］

したがってこの実装形態は、以下の矛盾を導出し得る。

［外１５］

定理４．Ｃ^ｄ＜Ｃ^ｕ＜（１＋１／Ｓ）・Ｃ^ｄであるならば、最適演算子配置をＰ時間内に探し出すことが可能である。

証明．そのことを、Ｇ’は非巡回であるという補助定理４を適用することにより結論付けることが可能である。この論考は、残余グラフＧ’内の各々の木に対して、その重み付き最小頂点被覆を、動的プログラム・アルゴリズムを使用して線形時間で探し出すことが可能であるということを示す。

葉頂点から開始して、各々の頂点ｖに対して、被覆集合内のｖを有する（または有さない）、（ｖが根となる）部分木に対する頂点被覆のコストを考えてみる。任意の内部頂点ｖに対して、ｖが被覆集合内にないならば、ｖのすべての子は被覆集合内にあるべきである。したがって、コスト_ｖ ⁻＝Σ_{ｉ∈子（ｖ）}コスト_ｖ ^＋である。他方でｖが被覆集合内にあるならば、各々の部分木は、その部分木の頂点被覆を独立的に選定することが可能であり、

［外１６］

である。

異なる友人により求められるストリーム・レートが同じである特別な場合に関しては、（大部分の実際的なシナリオにおいて有効である）Ｃ^ｄ＜Ｃ^ｕ＜２・Ｃ^ｄであるならば、最適配置をＰ時間内に探し出すことが可能であるということに留意されたい。経験的にはＣ^ｕ≧２・Ｃ^ｄである場合でも、コンフリクトするエッジは依然として隔離された木を形成する。

要約

表１は、提案する演算子配置アルゴリズムが、クエリ複雑度、選択条件、およびアップロード／ダウンロード・コスト比の様々な組み合わせが与えられる場合の、理論的結果および時間複雑度を要約したものである。

演算子配置アルゴリズムは、要求グラフ内の各々の頂点に対する局所的最適性を個々に考慮することにより、大域的最適解を計算する。この論考では、（Ｃ^ｕ≦Ｃ^ｄであるならば）局所的最適性は大域的最適性と整合するということを証明する。効率的な貪欲アルゴリズムを、局所的最適性を計算するために提案する。この効率的な貪欲アルゴリズムによって、各々のノードは、局所的利得を最大化する解を個々に選定する。

このアルゴリズムは、単一レベル結合クエリ、および、より複雑なマルチレベル結合クエリの両方に対処する。マルチレベル結合クエリの場合、クエリ・グラフ内の内部結合演算子は仮想的な頂点として扱われる。局所的最適性を、トップダウン方式で各々の個々の頂点に対して計算することが可能である。加えて、残余グラフが（Ｃ^ｕ＞Ｃ^ｄに対して）非巡回であるよくある場合では、要求グラフに対する最適割り当てを探し出すための効率的な動的計画法（ＤＰ）アルゴリズムが存在する。したがって、クエリ・グラフに対する最適演算子配置を決定することが可能である。ブラック・ボックス演算子を伴う一般的なクエリ・グラフに対するこれらの概念の拡張を、さらに解説する。

（普通はリアルタイム・データにわたる相関である）クラウド・エッジ・アプリの性質が与えられる場合に、上記の論考では主に（サンプリング・フィルタを伴う）結合クエリに重点を置いた。後に続く論考は、提案するアルゴリズムを、クラウド・エッジ・トポロジー内の一般的なクエリ・グラフをサポートするためにどのように適用することが可能であるかに関係するものである。論考ではさらに、クエリ・グラフおよびイベント・レートの変化などのランタイム動態にどのように対処することが可能であるかを解説する。

一般的なクエリ・グラフへの対処

クエリ・グラフＧは、１組のブラック・ボックス演算子（Ｏと表す）にわたる有向非巡回グラフ（ＤＡＧ）と定義され、ここでＧ内の葉をソースと呼び、根をシンクと呼ぶ。Ｏ内の各々の演算子は、ゼロ（ソースを表す）以上の入力を受け取ることが可能であり、その演算子の出力は、他の演算子への入力として使用され得る。選択および射影は１入力演算子の例であり、一方で結合演算は、２入力演算子（または、低木のような結合に関しては多入力演算子）の例である。演算子配置アルゴリズムの高レベルの直観的事実は、各々の演算子が、その演算子の局所的コストを最適化するためにその演算子の出力をその演算子がアップロードするべきか（それともダウンロードするべきか）を、（トップダウンの順序で）個々に確定することが可能であるという点で、依然として有効である。この場合、割り当ての実行可能性は依然として前のように保証される。さらに、演算子がブラック・ボックスとみなされるということを考え合わせると、異なる演算子の出力にわたる共有を用いる機会はもはや存在しない。この場合、局所的最適状態と大域的最適状態との間の整合性は、定理２と同様の論拠にしたがって、依然として有効である。したがってここでも問題を、最適なアップロード／ダウンロード割り当てを探し出すことに転化させることが可能であり、提案する効率的な局所的最適性アルゴリズムを使用することが可能である。

動態への対処

アルゴリズムのある種の実例では、クエリ・グラフ、およびすべてのストリームに対するレート統計値が利用可能であることを仮定する。最適配置は、最適化段階で収集されたこの情報に基づいて計算される。しかしながらクエリ・グラフは、例えば、ソーシャル・ネットワーク内のエッジの追加および除去に起因して、経時的に変化する場合がある。同様に、イベント・レートもまた経時的に変化する場合がある。したがって、ランタイムの間のこれらの変化に適合することが必要である場合がある。提案する最適化アルゴリズムが非常に効率的であるということを考え合わせると、周期的な再最適化が実行可能な解決策である。しかしながら再最適化は、デプロイメント・オーバーヘッド（例えば、クエリ定義などの制御プレーン・メッセージを送出すること）に直面する場合がある。実装形態が非常に高頻度で再最適化するならば、再最適化オーバーヘッドによって最適化の利益が見劣りする場合がある。

この板挟み状態を解決するためには、１つの解決策は、コスト・ベース・オンライン・アルゴリズムを使用することである。例えばそのようなアルゴリズムは、再最適化を遂行しないことに起因する蓄積される損失を推定および維持し、蓄積された損失が再最適化のオーバーヘッドを上回るならば再最適化を遂行することを選定することが可能である。この手法の潜在的に有益な特質は、その手法が３倍の競争力がある（３−ｃｏｍｐｅｔｉｔｉｖｅ）、すなわち、全体的なコストが（変化が演繹的にわかるとしても）最適状態の３倍により範囲が定められることが保証されるということである。

上記の論考は、具体的なＲＡＣＥ実装形態のきわめて詳細な部分を供与する。ＲＡＣＥは、広範な部類のリアルタイム・クラウド・エッジ・アプリケーションをサポートすることが可能である。ＲＡＣＥは、２つの主な技術的課題、すなわち（１）そのようなアプリケーションの仕様記述、および（２）クラウド・エッジ・トポロジー内でのそれらのアプリケーションの最適化された実行に関して対応処理した。（１）に関しては論考では、（ＳｔｒｅａｍＩｎｓｉｇｈｔに対するＬＩＮＱなどの）宣言型一時性クエリ言語を使用してこれらのアプリケーションを表現することが、非常に強力であり直観的であるということを示している。（２）に関しては、ＤＳＭＳエンジンの使用が、エッジ・デバイスおよびクラウド上で、処理を共有し、アプリケーション・ロジックの異なる一部分を実行するために提案されている。ここでは新規のアルゴリズムは、高度に効率的であり、それにもかかわらず証明可能であるように大域的ネットワーク・コストを最小限に抑え、一方で非対称ネットワーク、一般的なクエリ・グラフ、および中間結果の共有に対処する。上記のＲＡＣＥ実装形態は、市販で入手可能なＤＳＭＳであるＭｉｃｒｏｓｏｆｔ（登録商標）ＳｔｒｅａｍＩｎｓｉｇｈｔ（登録商標）とともに作動するように構成される。他の実装形態を、他のＤＳＭＳ選択肢を使用するように構成することが可能である。

現実のデータセットに対する実験は、ＲＡＣＥオプティマイザが、現況技術の最適配置技法より何桁か効率的であるということを指し示した。さらに本発明の実装形態により実現される配置は、８：６百万のエッジを伴う現実的なソーシャル・ネットワーク・グラフに対しての友人探しアプリに関して、より単純型の体系より何倍か低いコストをもたらした。ＲＡＣＥは、クラウド内部で容易に並列化可能である。ＲＡＣＥはさらに、最高５００までのエッジ・クライアントを伴う現実のデプロイメントに関して、まさに単一のマシンを使用することを良好にスケーリングする。ある種の実装形態の細部は、細かいレベルの粒度で、上記で説明されている。下記の論考は、上記で述べた実装形態に、および／または他の実装形態に関係する場合がある、より広範な説明を供与するものである。

さらなる方法例
図１０は、本発明の概念の少なくともある種の実装形態に整合する技法または方法１０００のフローチャートを例示する。

ブロック１００２では方法は、複数のエッジ・デバイスおよびクラウド・ベース・リソースを含むクラウド・エッジ・トポロジー内で宣言型ストリーミング・クエリを取得することが可能である。

ブロック１００４では方法は、宣言型ストリーミング・クエリを、複数のエッジ・デバイスを反映するクエリ・グラフに変換することが可能である。

ブロック１００６では方法は、クラウド・エッジ・トポロジーに関するリソース使用量に基づいて、クエリ・グラフの演算子を個々のエッジ・デバイス上で実行すべきか、それともクラウド・ベース・リソース上で実行すべきかを決定することが可能である。

上記で述べた方法を説明する順序は限定と解釈されることは意図されておらず、任意の数の説明したブロックを任意の順序で組み合わせて、その方法または代替の方法を実装することが可能である。さらに方法を、コンピューティング・デバイスが方法を実装することが可能であるように、任意の適したハードウェア、ソフトウェア、ファームウェア、またはそれらの組み合わせで実装することが可能である。１つの場合では方法は、コンピューティング・デバイスによる実行によってコンピューティング・デバイスが方法を遂行することになるように、１組の命令としてコンピュータ可読記憶媒体上に記憶される。

結論
クラウド・エッジ・リソースおよびそれらの割り振りに関係のある、技法、方法、デバイス、システム等を、構造的特徴および／または方法論的行為に対しての具体的な文言で説明しているが、添付の特許請求の範囲において定義される主題は、説明した具体的な特徴または行為に必ずしも限定されないということを理解されたい。むしろ具体的な特徴および行為は、請求する方法、デバイス、システム等を実装する例示的な形式として開示されるものである。

Claims (10)

1. 複数のエッジ・デバイスおよびクラウド・ベース・リソースを含むクラウド・エッジ・トポロジー内で宣言型ストリーミング・クエリを取得するステップと、
   前記宣言型ストリーミング・クエリを、前記複数のエッジ・デバイスを反映するクエリ・グラフに変換するステップと、
   前記クラウド・エッジ・トポロジーに関するリソース使用量に基づいて、前記クエリ・グラフの演算子を個々のエッジ・デバイス上で実行すべきか、それとも前記クラウド・ベース・リソース上で実行すべきかを決定するステップと
   を含む方法。
2. 前記エッジ・コンピューティング・デバイスが、ネットワークを介して前記クラウド・ベース・リソースと直接通信するように構成されるスマート・コンピューティング・デバイスを備え、前記ネットワークが、個々のスマート・コンピューティング・デバイスが相互に直接通信することを可能にするように構成されず、むしろ前記個々のスマート・コンピューティング・デバイスが、前記クラウド・ベース・リソースを介して間接的に相互に通信する、請求項１に記載の方法。
3. 決定する前記ステップが、ネットワーク帯域幅リソース使用量に関係する前記クラウド・ベース・リソースに対する大域的最適条件を決定するステップを含む、請求項１に記載の方法。
4. 大域的最適条件を決定する前記ステップが、前記クエリ・グラフのノードが貪欲な方途で局所的確定を行うことを可能にするステップを含み、前記局所的確定が、累積的に考察される場合に前記大域的最適条件を生み出す、請求項３に記載の方法。
5. クラウド上で、および、前記クラウドと通信している個々のエッジ・コンピューティング・デバイスで実行するアプリケーションとインターラクションするように構成される、リアルタイム・アプリケーション・オーバー・クラウド・エッジ（ＲＡＣＥ）クラウド・ベース管理サービスであって、データ・ストリーム管理システム（ＤＳＭＳ）エンジンを模倣して、前記個々のエッジ・コンピューティング・デバイスから一時性宣言型クエリを受信するように構成される、ＲＡＣＥクラウド・ベース管理サービスと、
   前記一時性宣言型クエリをインターセプトするように、ならびに、個々の一時性宣言型クエリをオブジェクト表現にパースおよびコンパイルするように構成されるＲＡＣＥプロセッサと
   を備えるシステム。
6. 前記ＲＡＣＥプロセッサが、前記オブジェクト表現からクエリ・パターンを生成するように構成されるグラフ・コンストラクタを備える、請求項５に記載のシステム。
7. 前記クエリ・パターンが、各々のエッジ・コンピューティング・デバイスからのデータ・ストリームを指す入力ストリームを含むインスタンスにおいて、前記グラフ・コンストラクタが、前記クエリ・パターンの複数のインスタンスを含むクエリ・グラフを、前記データ・ストリームを、前記クエリ・グラフのエッジごとに１つの入力ストリームを伴う前記クエリ・パターンの複数のインスタンスに分割することにより発生させるようにさらに構成される、請求項６に記載のシステム。
8. 前記ＲＡＣＥプロセッサが、前記エッジ・コンピューティング・デバイスとクラウド・ベース・リソースとの間の全体の通信コストを削減するために、前記クエリ・グラフの個々の演算子をどこで実行すべきかを決定するように構成されるオプティマイザを備える、請求項７に記載のシステム。
9. 前記オプティマイザが、前記エッジ・コンピューティング・デバイスと前記クラウド・ベース・リソースとの間の全体の通信コストを最小限に抑えるために、前記クエリ・グラフの個々の演算子をどこで実行すべきかを決定するように構成される、請求項８に記載のシステム。
10. 前記ＲＡＣＥプロセッサが、各々のエッジ・コンピューティング・デバイス上で、または前記クラウドで実行されることになる、タイプ、アダプタ、およびサブクエリのオブジェクト表現を生成するように構成されるクエリ・コンストラクタを備える、請求項５に記載のシステム。
    
    
    

Images