JP2008217766A - グリッド環境におけるデータ及びタスクインスタンスの分散 - Google Patents

Abstract

【課題】グリッド環境でデータ及びタスクインスタンスを分散するシステムを提供する。
【解決手段】パーティション分析手段は、グリッドネットワークのデータベースの中のデータパーティションを指定し、グリッドネットワークの中で部分的に実行されるべきアプリケーションのタスクにデータパーティションのマッピングを実行する。プロビジョニング管理手段は、タスクのタスクインスタンスを判定し、マッピングに基づいてグリッドネットワークの初期ノードに格納されるデータパーティションを判定する。タスクインスタンスの実行に必要とされる処理資源を有するグリッドネットワークの処理ノード、及びデータパーティションの格納に必要とされるメモリ資源を有するグリッドネットワークのデータノードが判定される。比較に基づいて、タスクインスタンスは、処理ノードに展開されると共に、データパーティションは、初期ノードからデータノードに移動される。
【選択図】図１

Description

この明細書は、グリッドコンピューティングに関係する。

グリッドコンピューティング環境は、一般的に、１つ以上の問題を解決するために、複数のコンピュータが協力的に使用される、分散化されると共にネットワーク化されたコンピューティングモデルのことを指す。多くの場合、解決されるべきそのような問題は、コンピュータ的に集中的であると共に、従来のコンピューティング領域において完成させるために、広範囲で高価な資源を必要とするであろう。例えば、天候パターンまたは金融市場のモデル化のような問題は、１つのコンピュータを用いて解決することが困難であり、多くの費用がかかるかもしれず、グリッドコンピューティングを用いて着手され得る。従って、グリッドコンピューティングは、コンピュータ的に集中的である問題に着手するための、費用効果が高い信頼できる方法を提供し得る。
米国特許第６，４６０，０３１号公報

そのようなコンピュータ的に集中的であるソフトウェアアプリケーションと比べると、多くのソフトウェアアプリケーションは、代りに（もしくは、更に）データベース的に集中的であり得る。すなわち、そのようなアプリケーションは、データベースに対する多数の呼び出し、及び／または頻繁な呼び出し（例えば、照会）を必要とし得る。例えば、企業の場合には、その企業が、例えば、顧客、従業員、手続き、または他のビジネス関係データに関連した多量のデータを格納することができる大きな中央データベースを維持することが、しばしば発生し得る。データベース集中型アプリケーション（Database-intensive applications）は、従って、顧客レポートを生成するか、もしくは企業の人件費を処理することのような、関連する機能性を実行するために、中央データベースにアクセスし得る。従って、グリッドコンピューティングモデルのように、分散されたコンピューティング資源を使用することの利益が、その状況の中で要求されたデータにアクセスするために必要とされる時間と資源によって、減らされ得るか、または超えられ得るので、グリッドコンピューティング環境において、そのようなデータベース集中型アプリケーション実行することは、難しいかもしれない。

１つ一般的な特徴によれば、システムは、グリッドネットワークのデータベースの中の少なくとも１つのデータパーティションを指定するように構成されると共に、グリッドネットワークの中で部分的に実行されるべきアプリケーションの少なくとも１つのタスクに対してデータパーティションのマッピングを実行するように更に構成されるパーティション分析手段を備える。システムは、更に、少なくとも１つのタスクのタスクインスタンスを判定し、マッピングに基づいて、グリッドネットワークの初期ノードに格納されるデータパーティションを判定し、タスクインスタンスを実行するのに必要とされる処理資源を有するグリッドネットワークの処理ノード、及びデータパーティションを格納するのに必要とされるメモリ資源を有するグリッドネットワークのデータノードを、それらの間の待ち時間に基づいて判定し、データノードにおけるデータパーティションを有するタスクインスタンスの実行時間が、初期ノードに残存するデータパーティションを有するタスクインスタンスのデフォルトの実行時間より少ないか否かに関して、比較を実行し、比較に基づいて、タスクインスタンスを処理ノードに展開すると共に、データパーティションを初期ノードからデータノードに移動するように構成されるプロビジョニング（provisioning）管理手段を備える。

別の一般的な特徴によれば、実行されるべきタスクインスタンスが判定され、そしてタスクインスタンスの実行と関連付けられると共に、グリッドネットワークの初期ノードに格納されるデータパーティションが判定され得る。タスクインスタンスを実行するのに必要とされる処理資源を有するグリッドネットワークの処理ノード、及びデータパーティションを格納するのに必要とされるメモリ資源を有するグリッドネットワークのデータノードの両方が、それらの間の待ち時間に基づいて判定され得る。データノードにおけるデータパーティションを有するタスクインスタンスの実行時間が、初期ノードに残存するデータパーティションを有するタスクインスタンスのデフォルトの実行時間より少ないか否かに関して比較が実行され得る。比較に基づいて、タスクインスタンスは、処理ノードに展開され得ると共に、データパーティションは、初期ノードからデータノードに移動させられ得る。

別の一般的な特徴によれば、コンピュータプログラム製品は、コンピュータ読み取り可能な記録媒体上で明白に具現化され得ると共に、実行可能コードを含み得る。実行可能コードは、実行された場合に、データ処理装置に、アプリケーションのタスクから例示化される、グリッドネットワークにおいて実行されるべきタスクインスタンスを受信する処理を実行させるように構成され得る。実行可能コードは、実行された場合に、データ処理装置に、アプリケーションと関連付けられたデータベースから、タスクインスタンスに基づいて、タスクと関連付けられると共に、グリッドネットワークの初期ノードに格納されたデータパーティションを判定する処理を実行させるように構成され得る。実行可能コードは、実行された場合に、データ処理装置に、タスクインスタンスを実行するための十分な処理資源を有するグリッドネットワークの処理ノードを判定する処理と、データパーティションを格納するための十分なメモリ資源を有するグリッドネットワークのデータノードを判定する処理とを実行させるように構成され得る。実行可能コードは、実行された場合に、データ処理装置に、初期ノードからデータノードに移動されたデータパーティションを有する処理ノードにおけるタスクインスタンスの実行時間が、初期ノードに残存するデータパーティションを有するタスクインスタンスのデフォルトの実行時間より少ないと判定する処理を実行させるように構成され得る。実行可能コードは、実行された場合に、データ処理装置に、タスクインスタンスを処理ノードに展開する処理と、データパーティションを初期ノードからデータノードに移動する処理とを実行させるように構成され得る。

１つ以上の実施の詳細が、以下の添付図面及び記述において説明される。他の特徴は、説明及び図面、そして請求項の内容から明白になる。

図１は、それにより、データベース集中型アプリケーションが図１のグリッド環境から利益を得ること、例えば、グリッド環境と関連付けられる、増加した処理資源、増加した信頼性、及び減少したコストで利益を得ることを可能にするために、グリッド環境においてデータ及びタスクインスタンスを分散するためのシステム１００の構成図である。更に具体的には、そのようなデータベース集中型アプリケーションは、例えば、タスクインスタンスとデータベース集中型アプリケーションの対応するデータの両方のプロビジョニング（provisioning：設定）によって、グリッド環境の中でそのような利益を獲得し得ると共に、この状況における対応するデータは、関連するタスクにとって非常に有益であるとして提示されたデータのことを指す。そのようなタスクインスタンス及び対応するデータは、グリッド環境の中に設定され得ると共に、タスクインスタンスの対応するデータに対するデータ呼び出し（及びタスクインスタンスに対する呼び出されたデータの対応応答）の待ち時間は、最小限にされる。この待ち時間を最小限にすることによって、図１のグリッド環境のまさに言及された利益をまだ獲得している一方、データベース集中型アプリケーションの全体の実行時間は、最適化され得るか、及び／または改善され得る。

図１のシステム１００において、グリッド環境、またはグリッドネットワークは、中央ノード１０２、及び複数のノード１０４ａ、１０４ｂを備える。この点に関して、中央ノード１０２、及び／またはノード１０４ａ、１０４ｂは、グリッドネットワークの装置のハードウェア処理系及び／または（例えば、仮想の）ソフトウェア処理系のことを指し得るということが認識されることになる。例えば、中央ノード１０２は、世界的企業が、企業の法人本部において、１つ以上の大きなデータベースを保存する場合のような、そこに多量のデータが格納されるコンピューティング装置のことを指し得る。一方、ノード１０４ａ、１０４ｂは、中央ノード１０２に接続され得るあらゆる数のノードを表すと共に、実際上は、例えばここで説明された動作を実行するために十分な処理能力、及び／またはメモリ能力を有するあらゆるコンピューティング装置のことを指し得る。例えば、中央ノード１０２、及び／または、ノード１０４ａ、１０４ｂは、ラップトップコンピュータ、もしくは他のパーソナルコンピュータを含み得るか、または明らかなように、企業サーバかまたは他の潜在的に資源が豊かなコンピューティング装置を含み得る（か、または企業サーバかまたは他の潜在的に資源が豊かなコンピューティング装置に関連付けられ得る）。

図１の例において、グリッドミドルウェア１０６は、図１のシステム１００のグリッド環境の実装及び動作を容易にするソフトウェアを指すことが例証される。例えば、グリッドミドルウェア１０６は、タスクインスタンスをグリッド環境の中で展開／移動するために使用され得ると共に、更に一般的には、図１のグリッド環境を横断して様々な異なるアプリケーション、プロトコル、プラットフォーム、オペレーティングシステム、アーキテクチャ、または他のパラメータの使用を容易にし、そして提供するために使用され得る。同様に、グリッドミドルウェア１０６は、ノード１０４ａ、１０４ｂ（及び図１において示されなかった他のノード）の動作を同期させるか、もしくは他の場合は動作を統合するために使用され得る。従って、グリッドコンピューティングの特徴の内の１つは、一般的に、実質的に同種の結果を潜在的に異種の環境から獲得することであると共に、グリッドミドルウェア１０６は、この結果を獲得するのに役立ち得る。

更に、図１において、上述のデータベース集中型アプリケーションの例は、ビジネスアプリケーション１０８として例証される。この点に関して、その上ビジネスアプリケーション１０８は、同様に、例えば学校、政府、教会、チャリティ、病院、または実質的には他のあらゆる組織を含む非営利的な試みのことを指し得るが、用語“ビジネスアプリケーション”は、実質的にある種類の利益生成に使用され得るあらゆるアプリケーションを含むと、広く解釈されるべきである。更に、ビジネスアプリケーション１０８は、単に一例であると共に、個人的使用のためのアプリケーションのような他のアプリケーションが、同様に使用され得る。

ここで参照されるように、ビジネスアプリケーション１０８は、問題の機能性の実行を完了するために関連データへのアクセスを必要とし得る様々な機能性を実行し得る。その場合に、一例としてのみ、ビジネスアプリケーション１０８は、照会発生器１１０、及びレポート管理手段１１２を含むとして例証される。例えば、人件費の例において、企業は、一人以上の従業員に支払うべきであり得る現行賃金、または給料を決定するために、照会発生器１１０を使用して関連データを照会し得る。別の例として、レポート管理手段１１２は、様々なビジネスの側面に関して、例えば経常在庫レベル、または経常収支支払い可能／受け取り可能情報を含むレポートを生成するために使用され得る。

そのようなアプリケーション特有の機能性は、タスクリポジトリ１１４に格納され得るタスクと言われ得る。概して言えば、そのようなタスクは、そのインスタンスが、望ましい結果を獲得するために、個々に、もしくは一緒に使用され得る、再利用可能な以前にテストされたコンポーネントまたはオブジェクトを表し得る。例えば、ビジネスアプリケーション１０８は、実質的に、例えば、株式相場を提供すること、航空会社または他の予約を提供すること、購買作業／請求作業の機能性を提供すること、もしくはサプライチェーン管理または在庫管理のあらゆる状況を提供することを含む、ネットワークを介してアプリケーションによって提供され得るあらゆる機能性を提供し得る。

いくつかの例において、タスクリポジトリ１１４のタスクは、そのようなタスクの一部分として送信／受信され得るメッセージだけでなく、実行されるべきタスクを含み得る。そのようなタスクは、プロセスモデルにあるような望ましい結果を獲得するために、結合され、そして整理され得ると共に、その中で、周知のように、そのようなタスクは、容易な理解及びグラフィカルユーザインタフェース上のそれらの操作のために、図によって表され得る。これらの状況において、それらのタスクは、並列タスク（parallel tasks）、反復タスク（iterative tasks）、入れ子型ループ（nested loops）、または他の既知のタスク連鎖（task progressions）を含む構造を獲得するために、適切な境界（矢印）及び制御タスク（例えば、分割及び／または結合）によって結合され得る。

更に、もしくは代りに、ビジネスアプリケーション１０８のタスクは、少なくとも一部分がアプリケーションサービスを用いて（例えば、サービス指向のアーキテクチャ（ＳＯＡ）の一部分として）実行され得る。そのようなアプリケーションサービスは、多くの場合に（インタフェースの動作及び使用が知られているか、または必要に応じて決定される）サービスインタフェースを経由してネットワーク（例えば、インターネット）を介して他のアプリケーションに公開される１つ以上の特有の機能性を有するアプリケーションのことを指し得る。そのようなサービス（及び／または、サービスのインタフェース）が、ワールドワイドウェブ（ここではＷＷＷまたはウェブとも呼ばれる）上で公開される／利用可能である場合に、その場合には、プロビジョニングサービスは、ウェブサービスとして知られ得る。

例えば、そのようなサービス（例えば、ウェブサービス）の合成を提供するように設計されている“Business Process Execution Language”（ＢＰＥＬ）のような言語が存在すると共に、それは、従ってＳＯＡに対してトップダウンのプロセス指向のアプローチを提供し得る。従って、ＢＰＥＬか、または（例えば“Web Services Flow Language”（ＷＳＦＬ）、拡張可能言語（eXtensible language：ＸＬＡＮＧ）、及び／または“Business Process Execution Language”（ＢＰＥＬ）のような）他のそのような言語、またはそれらの変更／拡張は、タスクリポジトリ１１４のタスクを定義するか、及び／または統合するか、及び／または展開するために使用され得る。

従って、タスクリポジトリ１１４のタスクは、指定された機能性を有する一般的なコンポーネントを表すと共に、それらのタスクは、ビジネスアプリケーション１０８の特別な処理系を実施するために例示化され得る。例えば、ビジネスアプリケーション１０８は、企業の人件費を計算するためにタスクを含み得ると共に、そのようなタスクは、現在の従業員を判定する処理と、企業の現在の給与構造を判定する処理と、もしあれば個々の従業員の個々の状況（例えば、働いた時間数、または使用された病気欠勤日の数）の影響を判定する処理とを含み得る。もちろん、これらは、単に一例であるが、しかしそこから、（毎月の人件費処理に関して）これらのタスクの異なるインスタンスは、１年の各月に対して作成され得ると共に、例えば、様々なパラメータ（例えば、その月の日数または休日数、ある月に適用されたボーナス（例えば年末のボーナス）の量、または人件費関連変数）が、月毎に変化するか、または変化し得るので、タスクの“１月”のインスタンスは、タスクの“２月”のインスタンスと異なり得る、ということが認識されることになる。

その場合に、動作において、ビジネスアプリケーション１０８は、分散された方法で、そのような人件費処理、または他の機能性を実行することを希望し得る。例えば、ノード１０４ａはニューヨークに配置され、一方ノード１０４ｂはロンドンに配置され得ると共に、ノードの配置は、問題の企業の経営上の中心と対応し得る。この場合に、ビジネスアプリケーション１０８は、ノード１０４ｂによる実行のために、ノード１０４ｂにタスクインスタンス１１６を分散し、展開し、設定するか、または他の場合には提供するように、グリッドミドルウェア１０６及び中央ノード１０２を使用し得る。もちろん、多数のタスクインスタンスが、複数のノードに展開される必要があり得るということ、及び１つだけのタスクインスタンス１１６が、実例のためだけに、図１で例証されるということが認識されることになる。

上で参照されたように、そのようなノード１０４ｂに対するタスクインスタンス１１６の分散は、ノード１０４ｂの利用可能なコンピューティング資源を活用することによって、総じてタスクインスタンス１１６の、そしてアプリケーション１０８の全体の信頼性及び実行時間を改善し得る。しかしながら、同様に上で参照されたように、そのような利点は、タスクインスタンス１１６が、それの実行の間に、中央ノード１０２の中央データベース１１８にアクセスする（例えば、データ呼び出し（data calls）を実行する）必要があり得るという事実によって超えられ得る（か、または超えられないかも知れない）。

例えば、上で提供された人件費の例について引き続き説明すると、中央データベース１１８は、他の人件費関係のデータと同様に、企業の従業員の現在のリストを含み得る。従って、タスクインスタンス１１６は、その関連付けられた人件費計算を実行するために、中央データベース１１８に対して照会を実行するか、または中央データベース１１８に対して他のデータ呼び出しを実行する必要があり得る。しかしながら、例えば（ノード１０４ｂがロンドンに配置されていると共に、中央ノード１０２がヴァルドルフ（Walldorf）に配置されている場合のように）ノード１０４ｂが中央ノード１０２から離れて配置されている場合に、タスクインスタンス１１６のそのような各呼び出しと関連付けられたささいでない（non-trivial）待ち時間があり得る。例えば、待ち時間のサイズ、及び／またはデータ呼び出しの量または頻度のような要因に応じて、その結果生じるタスクインスタンス１１６の実行時間の増加は、まず第一に、タスクインスタンス１１６をノード１０４ｂに展開することの計算の利点を上回る可能性がある。

図１の例において、中央ノード１０２は、タスクインスタンス１１６と共にデータパーティション１２２ａを展開することによって、上記の考察事項を考慮するように構成され得る分散システム１２０を備える。更に具体的には、分散システム１２０は、中央データベース１１８のデータを、２つ以上のそのようなデータパーティションに分割するように構成され得ると共に、ここで、そのようなデータパーティションは、それらの間のデータの整合性を保証するために同期化が必要とされないように、個々に融合しているが、しかし相互からは離接的である首尾一貫したデータのセットを含み得る。例えば、データパーティション１２２ａは、ニューヨークの従業員と関連付けられた（図１において例証されない）データの同様のパーティションから隣接的であり得る、ロンドンの従業員と関連付けられたデータのブロックを含み得る。（ここで、例えば、ロンドンの従業員の雇用、及び対応するデータパーティション１２２ａに対する更新は、ニューヨークの従業員と関連付けられた対応するデータパーティションとの同期化を必要としない可能性がある。）

以下で更に詳細に示されるように、分散システム１２０は、データパーティション１２２ａが、タスクインスタンス１１６によって最も高頻度に呼び出されるか、及び／または最も適当に呼び出されるデータを含むということが、前もって知られ得るように、タスクインスタンス１１６自身のタスクに基づいて、中央データベース１１８のデータの中からデータパーティション１２２ａを分割するか、そうでない場合は判定し得る。このように、タスクインスタンス１１６からのデータ呼び出しの大部分または全ては、例えば、もしタスクインスタンス１１６及びデータパーティション１２２ａの両方が一緒にノード１０４ｂに展開される場合に、タスクインスタンス１１６のデータ呼び出しと関連付けられる待ち時間が、徹底的に削減されるか、もしくは効果的に消去され得るように、データパーティション１２２ａに対して実行され得ると共に、それは、タスクインスタンス１１６の全体（及び総じてアプリケーション１０８）の実行時間における対応する減少に帰着し得る。

データパーティション１２２ａを中央データベース１１８から分割するか、及び／またはデータパーティション１２２ａを中央データベース１１８に展開するか、及び／またはデータパーティション１２２ａを中央データベース１１８に移動するか、及び／またはデータパーティション１２２ａを中央データベース１１８に再結合させる際、連合データベース管理システム（federated database management system：ＦＤＢＭＳ）１２４ａ、１２４ｂ、１２４ｃが使用され得る。各々、示されたように、ＦＤＢＭＳ１２４ａ、１２４ｂ、及び１２４ｃは、それぞれ中央ノード１０２、ノード１０４ａ、及びノード１０４ｂ上で実行され得る。そのようなシステムは、その結果、連合化されたデータにアクセスするために、唯一の同一のインタフェースが人間またはコンピュータユーザに提示され得るように、複数の分散型データベースから仮想連合データベースを形成するために使用され得る。例えば、上述のコンピュータによるグリッドが分散型処理資源及び要求を利用するために使用され得るが、分散されたストレージ資源及び要求を活用するために、そのようなデータベースの連合を実行し得る従来のストレージグリッド（storage grid）が使用され得る。既知のノードの現在の使い勝手の悪さまたは機能不良のような理由、もしくは他の既知の理由で、そのような従来のストレージグリッドの一部分として、ノードの間で個々のデータベースを移動するために、連合データベース管理システムが使用され得る。

しかしながら、図１の例においては、データパーティション１２２ａのパーティション分割及び展開を容易にするために、分散システム１２０によって、ＦＤＢＭＳ１２４ａ、１２４ｂ、１２４ｃが使用され得る。すなわち、上述のように、分散されたデータに対して１つのインタフェースを提供するために、ＦＤＢＭＳ１２４ａ、１２４ｂ、１２４ｃが使用され得るが、それは、現在の説明から、ＦＤＢＭＳ１２４ａ、１２４ｂ、及び１２４ｃは、更に、もしくは代りに、図１のグリッド環境の中で、例えば分散システム１２０の指示で、データパーティション１２２ａを、作成するか、分散するか、展開するか、移動するか、またはそうでに場合には提供するための更に大きな処理の一部分として使用され得ると認識されることになる。

このように、データパーティション１２２ａがローカルノード１０４ｂの（例えばあらゆる標準のメモリ装置技術を用いて実現され得る）ローカルデータベース１２８ｂに格納され得る一方、タスクインスタンス１１６は、（ノード１０４ｂにおいてハードウェアまたはソフトウェアで実現され得る）サーバ１２６ｂ上で実行され得る。従って、ここで説明されたように、タスクインスタンス１１６は、データパーティション１２２ａに対する必要とされるデータ呼び出しに関連付けられた（この例では、ノード１０４ｂにおけるタスクインスタンス１１６及びデータパーティション１２２ａのコロケーション（co-location）に起因する）最小の待ち時間によって実行され得る。

上記のように、そして図４及び図５を参照して更に詳細に説明されるように、分散システム１２０は、パーティション分析手段１３０を備え得る。パーティション分析手段１３０は、タスクリポジトリ１１４のタスク、中央データベース１１８の内容及び構造、及び様々な他の関連要因を分析するように構成され得ると共に、その後、データパーティション１２２ａ（及び恐らくは図１において例証されなかった他のパーティション）を含むために、中央データベース１１８のデータを分割し得る。例えば、上記の人件費の例では、パーティション分析手段１３０は、そこからタスクインスタンス１１６が例示化されたタスクを分析すると共に、タスクが特別な地理領域または場所に極めて特有である（例えば、指定された領域／場所にいる従業員のグループに関するデータと関連付けられ得る）ことを判定するように構成され得る。従って、パーティション分析手段１３０は、中央データベースを、他の領域／場所と関連付けられた他のデータパーティションに分割するのと同様に、（ロンドンを基準とする人件費処理と関連付けられた）データパーティション１２２ａに分割し得る。

その後、マッピングデータベース１３２は、タスクとデータパーティションとの間の判定された関係を格納するために使用され得る。例えば、図４で例証されたように、１つ以上のタスクが１つのデータパーティション（例えば、データパーティション１２２ａ）にマッピングされ得る。例えば、上述のように、毎月の人件費処理の実行と関連付けられた複数の人件費関連のタスクがあり得ると共に、これらのタスクの大部分または全ては、地理的に定義された対応するデータパーティションにマッピングされ得る。従って、データパーティションとタスクインスタンスとの間には１対ｎ（1:n）のマッピングが存在し得る。

ビジネスアプリケーション１０８のランタイム（run-time）の間、例えば、当月の終りに人件費処理が始まる場合に、分散システム１２０のプロビジョニング管理手段１３４は、タスクインスタンス１１６及びタスクリポジトリ１１４のタスクの関連するタスクインスタンスを、グリッド環境の１つ以上のノード１０４ａ、１０４ｂに展開するように構成され得る。ここで参照されるように、プロビジョニング管理手段１３４は、更に、データパーティション１２２ａを図１のグリッド環境の中に展開する（例えば、移動する）か否か、そしてどのように展開するかを判定するように構成され得る。

プロビジョニング管理手段１３４の更に具体的な例は、図６に関して以下で提供されると共に、プロビジョニング管理手段１３４の動作の例は、図７に関して提供される。しかしながら、一般的に、プロビジョニング管理手段１３４は、タスクインスタンス１１６及びデータパーティション１２２ａを展開するか否か、そしてどのように展開するかを判定するために、多くの要因を判定するように構成され得るということが認識され得る。例えば、プロビジョニング管理手段１３４は、グリッド環境のノード１０４ａ、１０４ｂの各々において利用可能である、現在利用可能なコンピューティング資源及びメモリ資源を判定し得る。更に、プロビジョニング管理手段１３４は、１つ以上の一組のノード１０４ａ、１０４ｂ（及び、例証されなかった他のノード）と関連付けられた待ち時間を判定し得る。その場合に、プロビジョニング管理手段１３４は、タスクインスタンス１１６の実行時間を改善するために、データパーティション１２２ａが展開されるべきか否か、そしてどのように展開されるべきかに関して、判定を実行し得る。

例えば、図２に関して以下で説明されるように、データパーティション１２２ａが、最初に中央ノード１０２における中央データベース１１８の中に配置されていることを発見し得る。この場合、プロビジョニング管理手段１３４は、例えば、タスクインスタンス１１６の処理時間または複雑さと比較して、データパーティション１２２ａをノード１０４ｂに移動するのに必要とされる時間が十分に大きいかもしれないこと、そしてデータパーティション１２２ａのノード１０４ｂへの移動は、タスクインスタンス１１６の実行時間の正味の減少または評価できる減少に帰着し得ないことを判定し得る。すなわち、プロビジョニング管理手段１３４は、データパーティション１２２ａを中央データベース１１８からノード１０４ｂのローカルデータベース１２８ｂへ移動して展開する時間をかけるより、ノード１０４ｂから中央データベース１１８に対する次の呼び出しのために、タスクインスタンス１１６をノード１０４ｂに展開することによって、タスクインスタンス１１６が、更に速く完了し得ることを判定し得る。

このシナリオにおいて、プロビジョニング管理手段１３４は、データパーティション１２２ａの断続線表現で例証されたように、データパーティション１２２ａがノード１０４ａのローカルデータベース１２８ａに展開され得ると判定し得るということを、それでもなお発見し得る。すなわち、たとえタスクインスタンス１１６とデータパーティション１２２ａがグリッド環境の同じノードに展開されないとしても、グリッド環境に展開されたタスクインスタンス１１６とデータパーティション１２２ａの両方を有することは、展開されたタスクインスタンス１１６から中央データベース１１８に対する呼び出しのために中央データベース１１８にデータパーティション１２２ａを残すことより、更に有益であり得る。例えば、ノード１０４ａとノード１０４ｂとの間の待ち時間が、ノード１０４ａとノード１０４ｂのいずれかと（例えば、ヴァルドルフ（Walldorf）の）中央データベース１１８との間の待ち時間と比較して、相対的に軽微であり得るように、ノード１０４ａが、同様に、（上記のニューヨークの例とは対照的に）ロンドンに位置し得ることを発見し得る。

同様に図２に関して、以下で詳細に例証されると共に論じられる最後の例のシナリオにおいて、タスクインスタンス１１６の展開の最初に、データパーティション１２２が既にノード１０４ｂのローカルデータベース１２８ｂに配置され得ることを発見し得る。この場合、プロビジョニング管理手段１３４は、データパーティション１２２ａをノード１０４ｂに残すことが最も良いことであると判定し得ると共に、このシナリオにおけるタスクインスタンス１１６のデータ呼び出しによって感じられる最小の待ち時間を利用するために、タスクインスタンス１１６をノード１０４ｂに展開し得る。

様々な他の例がここで提供されると共に、具体的に論じられないか、もしくは例証されなかった多くの改良が更に実行され得るということが認識されることになる。例えば、中央ノード１０２から分離しているとして示されたが、ビジネスアプリケーション１０８は、中央ノード１０２に配置され得る。他の例において、異なる用語が、ここで説明された、同じ概念か、もしくは同様の概念と関連付けられ得るということが認識されることになる。例えば、用語“タスクインスタンス”は、“タームジョブ”によって置き換えられ得るか、または“タームジョブ”に実質的に交換可能である。同様に、他の変形及び改良が明白であり得る。

図２は、図１のシステムの実装例を例証する構成図である。図２において、展開処理または分散処理の初めに、中央ノード１０２は、データパーティション１２２ａと同様に、展開されるべきタスクインスタンス１１６ａ、１１６ｂと関連付けられていると仮定されている。まず第一に、その場合に、例えば、ノード１０４ｃがタスクインスタンスを実行するのに十分な処理資源を備えるという分散システム１２０による判定に基づいて、タスクインスタンス１１６ａがノード１０４ｃに展開されるべきであることを発見し得る。この例において、ノード１０４ｃが、タスクインスタンス１１６ａを処理するためのその処理能力に基づいて選択されることを例証するために、ノード１０４ｃは、図２において、“処理”ノードと呼ばれる。

類似して、ノード１０４ｄは、分散システム１２０によってデータパーティション１２２ａを格納するための十分なメモリ資源を有すると判定され得る、ということが判定され得る。この例において、ノード１０４ｄが、データパーティション１２２ａを格納するためのその使用可能な記憶容量に基づいて選択されることを例証するために、ノード１０４ｄは、図２において、“データ”ノードと呼ばれる。幾分同様に、中央ノード１０２は、データパーティション１２２ａがそこに最初に配置されるので、“初期”ノードと呼ばれ得る。

更に、ここで詳細に説明されたように、データパーティション１２２ａのデータノード１０４ｄへの移動が、データパーティション１２２ａが中央データベース１１８に単純に残る基準の状況と比較して、タスクインスタンス１１６ａの全体の実行時間を減少させ得るということが判定され得る。すなわち、タスクインスタンス１１６ａが、処理ノード１０４ｃに展開されると共に、中央データベース１１８の中のデータパーティション１２２ａに呼び出しを行うことによって実行されるという第１のシナリオと、タスクインスタンス１１６ａが、処理ノード１０４ｃに展開されると共に、処理ノード１０４ｄの中のデータパーティション１２２ａに呼び出しを行うことによって実行されるという第２のシナリオとの間で比較が実行される。その場合には、削減された実行時間に帰着する第１のシナリオと第２のシナリオのいずれかが、選択されると共に、実行され得る。

これらの２つのシナリオ、及び他のシナリオの間で判定を実行するための様々な一例のアルゴリズム及びパラメータが、以下で更に詳細に説明される。しかしながら、一般的に、処理ノード１０４ｃとデータノード１０４ｄとの間の更に低い待ち時間は、データパーティションノード１２２ａのデータノード１０４ｄに対する展開によって、タスクインスタンス１１６ａの実行時間を減少させる可能性の増加に帰着し得るということが認識され得る。タスクインスタンス１１６ａとデータパーティション１２２ａとの両方が同じノードに展開される場合に、最小量の待ち時間が発生し得ると共に、その結果、実際的な待ち時間は、ゼロに達し得る。従って、“処理ノード”と“データノード”の名称は、ここで（例えば、図１において）詳細に説明されたように、単に異なるノード１０４ｃ、１０４ｄの可能な機能を例証するために使用されるということが認識されることになり、１つのノード（例えば、ノード１０４ｂ）が処理ノードとデータノードの両方として機能し得ることを発見し得ると共に、その場合、ちょうど言及されたように、タスクインスタンス１１６ａからデータパーティション１２２ａに対する呼び出しの効果的な待ち時間は、ゼロに達し得る。

データパーティション１２２ａが実際にはデータノード１０４ｄに展開される図２の例について引き続き説明すると、タスクインスタンス１１６ｂが中央ノード１０２から展開されるべき／中央ノード１０２を介して展開されるべきであることを後で発見し得る。図２の例において、タスクインスタンス１１６ｂがノード１０４ｆに展開されるということが例証される。例えば、タスクインスタンス１１６ｂは、ノード１０４ｃで現在利用可能である処理資源より更に大きな処理資源を必要とし得ると共に、その結果、ノード１０４ｃは、タスクインスタンス１１６ｂを受け取るには適当ではない。

この場合、分散システム１２０は、どのようにタスクインスタンス１１６ｂの最小の実行時間を達成するかに関して、再度判定を実行し得る。例えば、タスクインスタンス１１６ｂは、単に、ノード１０４ｆからデータノード１０４ｄ内のデータパーティション１２２ａに対してデータ呼び出しを実行し得る。もちろん、そのような呼び出しのそれぞれと関連付けられた関連する待ち時間があり得るが、しかし、それでもなお、タスクインスタンス１１６ｂの全体の実行時間は、タスクインスタンス１１６ｂを受け取るために、データノード１０４ｄにできる限り近いノード（または、そうでなければ、データノード１０４ｄに対して呼び出しを実行する際に最小化された待ち時間を経験するノード）を選択することによって、最小化され得る。

しかしながら、他の実施例において、タスクインスタンス１１６ｂの実行時間は、データパーティション１２２ａをデータノード１０４ｄからノード１０４ｆに移動することによって削減され得る。そのような例において、その場合に、ノード１０４ｂは、データパーティション１２２ａが問題の（可能な）移動の目的のためにそこに初めに位置付けられるので、“初期ノード”であると考えられ得る。この例では、その場合に、図２において示されたように、ノード１０４ｆは、処理ノードとデータノードの両方として機能するであろう。更に、そのような結果は、タスクインスタンス１１６ｂからデータパーティション１２２ａに対する呼び出しと関連付けられた待ち時間を最小化し得るか、または消去し得る。

最後の例では、そのようにノード１０４ｆがデータパーティション１２２ａを格納するための十分なメモリ資源を現在有していない場合に、データパーティション１２２ａはノード１０４ｆに移動され得ないことを発見し得る。この例において、データパーティション１２２ａは、その代りにノード１０４ｅに移動され得ると共に、その場合に、ノード１０４ｅは、“処理ノード１０４ｆ”に対するデータノードとして機能するであろう。更に、そのような移動が望ましいものとなるように、タスクインスタンス１１６ｂがデータノード１０４ｅに呼び出しを実行する場合に、タスクインスタンス１１６ｂがデータ／初期ノード１０４ｄに呼び出しを実行する場合と比較して、タスクインスタンス１１６ｂにより経験される待ち時間（及び／または実行時間）は、削減され得る／改善され得るということが仮定され得る。

図３は、図１及び図２のシステムの動作例を例証するフローチャート３００である。図３の例において、実行されるべきタスクインスタンスが判定され得る（３０２）。例えば、プロビジョニング管理手段１３４は、ビジネスアプリケーション１０８から、タスクリポジトリ１１４のタスクが、実行のためにタスクインスタンス１１６ａ（または、１１６ｂ）として例示化されたという通知を受信し得る。

タスクインスタンスの実行と関連付けられると共に、グリッドネットワークの初期ノードに格納されたデータパーティションが、その場合に判定され得る（３０４）。例えば、プロビジョニング管理手段１３４は、タスクインスタンス１１６ａ（及び／または、１１６ｂ）がそこから例示化されたタスクにデータパーティション１２２ａがマッピングされたことを判定するために、マッピングデータベース１３２にアクセスし得る。この例では、パーティション分析手段１３０が以前に中央データベース１２２ａを分割し、ちょうど説明されたようにデータパーティション１２２ａをマッピングすると共に、プロビジョニング管理手段１３４によるアクセスのために結果をマッピングデータベース１３２に格納したと仮定され得る。図２の前述の討論から認識されることになるように、この状況における初期ノードは、中央ノード１０２か、または図３のフローチャート３００の動作の初めにそこにデータパーティション１２２ａが格納され得るノード１０４ａ〜１０４ｆの内のいずれかのことを指し得る。

タスクインスタンスを実行するのに必要とされる処理資源を有するグリッドネットワークの処理ノードが判定され得て、そして同様に、データパーティションを格納するのに必要とされるメモリ資源を有するグリッドネットワークのデータノードが更に判定され得ると共に、そのような判定は、それらの間の待ち時間に基づいて実行され得る（３０６）。例えば、場合によってはタスクインスタンス１１６ａを受け取るために、プロビジョニング管理手段１３４は、ノード１０４ｂ／１０４ｃのようなタスクインスタンス１１６ａを実行するために現在利用可能な十分な処理資源を有する第１の複数のノードを判定し得る。または、図２の他の例において、プロビジョニング管理手段１３４は、ノード１０４ｆがタスクインスタンス１１６ｂを実行するために十分な処理資源を有していることを判定し得る。同様に、プロビジョニング管理手段１３４は、データパーティション１２２ａを格納するのに必要とされる十分なメモリ資源を有する第２の複数のノードを判定し得る。例えば、プロビジョニング管理手段１３４は、問題のタスクインスタンスに応じて、そしてちょうど説明されたように、そのようなデータノード１０４ｂまたはデータノード１０４ｄ〜１０４ｆの内のいずれかを選択し得る。

その場合に、ここで更に詳細に説明されるように、第１の複数のノードの中のノードと第２の複数のノードの中のノードとの異なる組み合わせが、それらの間の待ち時間を判定するために検査されると共に、処理ノード（例えば、１０４ｂ、１０４ｃ、または１０４ｆの内の１つ）と、データノード（例えば、１０４ａ、１０４ｂ、１０４ｄ〜１０４ｆの内の１つ）は、判定された待ち時間の中の最小の待ち時間に基づいて選択され得る。例えば、図２を参照すると、もしプロビジョニング管理手段１３４が、第１の複数の可能性がある処理ノードはノード１０４ｃ及びノード１０４ｆを含んでいると判定すると共に、第２の複数の可能性があるデータノードはノード１０４ｄ及びノード１０４ｆを含んでいると判定する場合に、その場合に、ノード１０４ｆは、（この例では、ノード１０４ｆは、ノードの両方のグループに含まれるので、そして待ち時間は、一般的に単一のノードにおけるタスクインスタンスとデータパーティションとの間の通信に関して効果的にゼロであるとみなされ得るので、）処理ノードとデータノードの両方として選択され得る。

データノードにおけるデータパーティションを有するタスクインスタンスの実行時間が、初期ノードに残されたデータパーティションを有するタスクインスタンスのデフォルトの実行時間より少なくなるか否かに関して、比較が実行され得る（３０８）。例えば、図１において、ノード１０４ｂは、処理ノードとデータノードの両方として機能し得る。初期ノードが中央ノード１０２である場合において、その場合に、プロビジョニング管理手段１３４は、処理／データノード１０４ｂにおけるタスクインスタンス１１６の実行時間（実行時間は、データパーティション１２２ａを中央データベース１１８からローカルデータベース１２８ｂに移動するのに必要とされる移動時間を含んでいる。）が、単にデータパーティション１２２ａを中央データベース１１８の中に残した場合のデフォルトの実行時間より総合的に少ないか否かを判定し得る。（その場合に、例えば、タスクインスタンス１１６は、処理／データノード１０４ｂに展開され得ると共に、タスクインスタンス１１６は、必要に応じて、中央ノード１０２に対してデータ呼び出しを行うことによって実行され得る。）もちろん、他の例において、一例としてノード１０４ｄが初期ノードとして機能する上記の図２の例のように、初期ノードは、中央ノード以外のノードであり得る。更に、全体の実行時間または全体のデフォルトの実行時間の一部分として含まれ得る追加のパラメータ、もしくは代替えのパラメータが、例えば方程式（１〜１４）に関して、以下で説明される。

図１においてちょうど参照されると共に例証されるように、その場合に、例えばプロビジョニング管理手段１３４がタスクインスタンス１１６をノード１０４ｂに展開する場合のように、タスクインスタンスは処理ノードに展開され得る（３１０）。ここで説明された実施例において、中央ノード１０２は、タスクインスタンスをグリッド環境に展開するための中央展開サイトとして機能すると仮定されると共に、一般的にタスクインスタンスをそれ自体は実行しないということが認識され得る。しかしながら、いくつかの実施例において、必要であるか、または求められるときに、タスクインスタンスを展開するために使用されるノードが、それ自体タスクインスタンスを実行することが可能であり得るということが見込まれ得る。

データパーティションは、比較に基づいて、初期ノードからデータノードに移動させられ得る（３１２）。例えば、上記の例を引き続き説明すると、プロビジョニング管理手段１３４は、データパーティション１２２ａが中央ノード１０２内の中央データベース１１８に残される（と共に、ノード１０４ｂにおけるタスクインスタンス１１６から呼び出しを受ける）場合のデフォルトの実行時間と、データパーティション１２２ａのノード１０４ｂ内のローカルデータベース１２８ｂへの移動の実行に起因し得る実行時間との間の比較を実行する。その場合に、例えば、実行時間がデフォルト実行時間より少ない状況において、プロビジョニング管理手段１３４は、データパーティション１２２ａをノード１０４ｂに移動するために、連合データベース管理システム１２４ａ、１２４ｂを使用し得る。

図４は、図１及び図２のシステムのパーティション分析手段１３０の構成図である。図４の例において、中央データベース１１８は、データ３０２〜３１４を含むものとして例証される。更に、図１のタスクリポジトリ１１４に格納されると理解され得ると共に、ビジネスアプリケーション１０８を実行するために使用され得るタスク３１６ａ、３１６ｂ、及び３１６ｃが例証される。その場合に、動作の間、パーティション分析手段１３０は、データ３０２〜３１４に関するタスク３１６ａ、３１６ｂ、及び３１６ｃのアクセス特性を判定すると共に、従って中央データベース１１８を分割するために、タスク３１６ａ、３１６ｂ、及び３１６ｃを分析しようと試み得る。

図４の一般的な例において、タスク３１６ｂが、データ３０２、３０４、３０６、及び３０８にアクセスし得る一方、タスク３１６がデータ３０２、３０４、３０６に独占的にアクセスすることを発見し得る。一方、タスク３１６ｃは、一般的にデータ３１２及びデータ３１４にアクセスし得る。例において、タスク３１６ａ、３１６ｂ、３１６ｃの内のいずれもが、データ３１０にアクセスすると予測されない。

従って、パーティション分析手段１３０は、データ３０２、３０４、及び３０６を含むものとしてデータパーティション１２２ａを形成し得る。従って、おそらく、タスク３１６ａは、データパーティション１２２ａに独占的にアクセスする。それと同時に、おそらく、タスク３１６は、主として、もしくは頻繁に、データパーティション１２２ａにアクセスする（が、しかし時折、もしくはまれにデータ３０８にアクセスする）。一方、パーティション分析手段１３０は、タスク３１６ｃが、データ３１２及びデータ３１４を含むデータパーティション１２２ｂに独占的にアクセスすると判定し得る。

従って、図１から図３に関する上記の説明から、タスク３１６ａのインスタンス及びデータパーティション１２２ａは、一緒に、例えばノード１０４ｂに展開され得るということが認識されることになる。この場合、タスク３１６ａのインスタンスは、実行のために必要とされるデータ全てへのアクセスを有し得ると共に、この例において、そのようなアクセスのための待ち時間は、効果的にゼロであり得る。従って、図１及び図２のグリッドコンピューティング環境は、タスク３１６ａのタスクインスタンスの実行時間を減速するために、中央データベース１１８に対する大きな、もしくは頻繁なデータ呼び出しの有害な影響なしで、有利に利用され得る。

所定の実施例において、タスクの呼び出しの全てが単一のデータパーティションに対して実行されるようにする（例えば、タスク３１６ａのデータパーティション１２２ａに対する呼び出しの排他的な性質、及びタスク３１６ｃのデータパーティション１２２ｂに対する呼び出しの排他的な性質のような）ことがたとえ最も有利であるかもしれないとしても、タスクのデータ呼び出しのいくつかだけが特別なデータパーティションに対する呼び出しである場合に、データ及びタスクインスタンスのプロビジョニングを実行することは、まだ有利であり得る。例えば、データ呼び出し３１６ｃが、あらゆるデータパーティションに全く含まれず、それ故に中央データベース１１８から移動されることがない（もしくは、仮にあったとしても単独で動かされるであろう）データ３０８に対して実行される一方、タスク３１６ｂのデータ呼び出し３１８ａ及び３１８ｂは、データパーティション１２２ａに対して実行されるものとして例証される。

従って、もしタスク３１６ｂのタスクインスタンスがデータパーティション１２２ａと一緒にノード１０４ｂに展開される場合、その場合に、タスク３１６のタスクインスタンスの全体の実行時間は改善され得る。少なくともいくつかのデータ呼び出し（例えば、データ呼び出し３１８ｃ）が中央データベース１１８に対して実行されなければならない可能性があるとしても、これは、局所的にアクセス可能な（locally-accessible）（ローカルデータベース１２８ｂ内の）データパーティション１２２ａに対して実行されるタスクインスタンスのデータ呼び出しの殆どまたは多くが原因である。

もちろん、パーティション分析手段１３０は、代替えの実施例において、データパーティション１２２ａを、データ３０２〜３０８の全てを含むものとして定義し得る。しかしながら、この場合には、データパーティション１２２ａが問題のグリッドネットワークのノードに格納されたときはいつでも、更に多くのデータが移動されなければならないであろう。しかしながら、もしデータ３０８に対するデータ呼び出し３１８ｃが非常にまれであるか、もしくは非常に少ない場合、その場合には、例えば、そのような追加のデータ移動は、保証されていないか、もしくは有害であり得る。すなわち、データ３０８の少ないか、もしくはまれな使用のみの利益のために、データ３０８をデータパーティション１２２ａの全ての移動に含むためのコストがあるであろう。パーティション分析手段１３０は、従って、プロビジョニング管理手段１３４による使用のために中央データベース１１８のパーティション分割を最適化するように、これら及び他のコストと利益とを比較検討することに関して責任があり得る。

一度、パーティション分割が発生すると、またはそれと連動して、パーティション分析手段１３０は、マッピングデータベース１３２の中に、その結果生じるタスク３１６ａ、３１６ｂ、及び３１６ｃと、データパーティション１２２ａ、１２２ｂとの関連性、またはマッピングを格納し得る。複数のタスク（例えば、タスク３１６ａ、及び３１６ｂ）が単一のデータパーティション（例えば、データパーティション１２２ａ）にマッピングされ得るので、示されたように、タスク対パーティションの間で、そのようなマッピングは、ｎ対１（n:1）で実行され得る。

図５は、図１、及び図４のパーティション分析手段１３０の動作例を例証するフローチャート５００である。図５の例において、中央データベース１１８のアプリケーション独立型（application-independent）パーティション分割が発生し得る（５０２）。例えば、パーティション分析手段１３０は、部分的に、もしくは完全にビジネスアプリケーション１０８から独立している中央データベース１１８の最初のパーティション分割を実行し得る（例えば、それは、複数のそのようなビジネスアプリケーションに適用でき得る。）。例えば、上で参照されたように、ノード１０４ａ及びノード１０４ｂは、問題の企業のニューヨークオフィス及びロンドンオフィスと関連付けられ得る。この場合には、多くのビジネスアプリケーションに関して、パーティション分析手段１３０が、場所特有またはオフィス特有のパーティションへの中央データベース１１８の最初のパーティション分割を実行し得ることは、論理的であり得る。

その場合に、アプリケーションと関連付けられたタスクが判定され得る（５０４）。例えば、パーティション分析手段１３０は、タスク３１６ａ、３１６ｂ、及び３１６ｃが問題のアプリケーション、例えばアプリケーション１０８と関連付けられていると判定し得る。

その場合に、各タスクと関連付けられたデータが判定され得る（５０６）。例えば、パーティション分析手段１３０は、タスク３１６ａがデータ３０２〜３０６と関連付けられ、タスク３１６ｂは、データ３０８と関連付けられていると共に、タスク３１６ｃは、データ３１２、３１４と関連付けられていると判定し得る。

各タスクによるデータアクセスの頻度、サイズ、及び／またはパターン、あるいは他の関連したアクセス特性が判定され得る（５０８）。例えば、パーティション分析手段１３０は、タスク３１６ａが図４のデータパーティション１２２ａに独占的にアクセスすると判定し得ると共に、タスク３１６ｂが頻繁に、しかし独占的ではなく、データパーティション１２２ａにアクセスする（が、しかし更にデータ３０８にアクセスする）と判定し得る。上で参照されたように、特定のタスクによって呼び出されたデータの平均サイズは、タスクのデータアクセスの特性を示す際、データ呼び出しの絶対数の重要性を上回り得る。すなわち、もしタスク３１６が、少ない回数、しかし毎回多量のデータで、データ３０８にアクセスする場合、その場合に、データ３０８に対するタスク３１６のアクセスは、データパーティション１２２ａに対するタスク３１６のアクセスより、タスク３１６のタスクインスタンスの実行時間に対してより大きい影響を与え得る。

ちょうど説明されたように、データは、例えば、データアクセスの頻度、サイズ、またはアクセスパターンに従って、タスクによってアクセスされるパーティションに分割され得る（５１０）。例えば、図４に関して上で説明されると共に、例証されたように、パーティション分析手段１３０は、データベース１１８のデータを、データパーティション１２２ａ、及びデータパーティション１２２ｂに分割し得る。

アクセスされたデータパーティションに対する各タスクのマッピングが判定され得ると共に、格納され得る（５１２）。例えば、パーティション分析手段１３０は、タスク３１６ｃがデータパーティション１２２ｂにマッピングされるべきである一方、タスク３１６ａがデータパーティション１２２ａにマッピングされるべきであると判定し得る。

図４及び図５の技術は、データセットの非常に大きなサイズまで測定可能であるということが認識されることになる。例えば、もし中央データベース１１８のデータセットが増加したとしたら、及び／または何らかの特別なデータパーティション１２２ａ、１２２ｂが増加したとしたら、その場合に、パーティション分析手段１３０は、データパーティションの数を単に増加し（そして、各データパーティションのサイズを相応じて減少させ）得ると共に、従ってマッピングデータベース１３２を更新し得る。

図６は、図１及び図２のプロビジョニング管理手段の構成図である。図６の例において、プロビジョニング管理手段１３４は、グリッドミドルウェア１０６を経由してアプリケーション１０８からタスクインスタンスを受け取る待ち行列６０２を含む。例えば、アプリケーション１０８は、各月の終りに、または待ち行列６０２に送るのに適切であるように様々なタスクを例示化し得る、人件費処理計画を実行し得る。

様々なタスクインスタンスは、待ち行列に入れられ得ると共に、最終的には割り当てモジュール６０４に渡され得る。割り当てモジュール６０４は、タスクインスタンス、例えばタスクインスタンス１１６ａの通知を受信し得ると共に、関連するデータパーティション、例えばデータパーティション１２２ａを判定するために、マッピングデータベース１３２を閲覧し得る。

割り当てモジュールは、その場合に、タスクインスタンスを実行するためのコンピューティンググリッドの現存する利用可能な資源を判定するために、資源管理プログラム６０６に問い合わせを行い得る。ここで説明されたように、そのような資源は、帯域幅、サービス品質（例えば、コストまたは安全性）、または待ち時間のようなネットワーク資源または環境資源と同様に、利用可能なノードの処理資源及び／またはメモリ資源（例えば、各ノードのローカルデータベースの現在の利用）を含み得る。一般的に、そのようなパラメータのための値は、例えばグリッドミドルウェア１０６を介して、適切なノード、またはグリッドコンピューティング環境の他の装置に問い合わせることによって、リアルタイムに、もしくはリアルタイムに近く判定され得る。

他の実施例において、そのような値は、１度、もしくは定期的に、前もって決定され得ると共に、後のアクセスのために格納され得る。例えば、図６において、インタフェース６０８は、グリッドコンピューティング環境における各一組のノードの間の待ち時間の値を判定するために使用され得る。ちょうど参照されたように、そのような待ち時間の値は、必要に応じて判定され得るか、または待ち時間マトリクス６１０、または他のフォーマットで格納され得る。インタフェース６０８は、新しいノードがグリッドコンピューティング環境に登録される場合か、もしくは現在のノードが取り除かれる場合を判定するために使用され得る。その場合に、待ち時間の値は、従って更新され得る。

割り当てモジュール６０４は、資源管理プログラム６０６から資源情報を受信すると共に、資源管理プログラム６０６によって提供された（例えば待ち情報を含む）資源情報を用いて、展開されるべきタスクインスタンス及びデータパーティションの特性に基づき、１つ以上のアルゴリズムを実行する。多くの異なるアルゴリズムが利用可能であるけれど、ここでは、（関連付けられたデータパーティションの、処理ノードと同じであり得るかまたは処理ノードと異なり得るデータノードに対する移動と一緒に）タスクインスタンスが処理ノードに移動されるべきであった場合の問題のタスクインスタンスに関する実行時間を、データパーティションが初期ノード（例えば、中央ノード１０２）に残したままにされる一方、タスクインスタンスが移動される／展開される場合のタスクインスタンスに関するデフォルトの実行時間と比較するために使用される一例のアルゴリズムが提供される。

結局のところ、割り当てモジュール６０４は、タスクインスタンスを、選択された処理ノードに展開することを判定し得ると共に、更に、関連するデータパーティションを展開するか否か、及び関連するデータパーティションをどこに展開するかを判定し得る。その場合に、タスクインスタンス、及びデータパーティションは、グリッドネットワークの所望のノードにタスクインスタンスとデータパーティションの両方を提供するために使用され得る展開モジュール６１２に識別され得る。そのように行う際、展開モジュール６１２は、連合データベース管理システム１２４、及び／またはグリッドミドルウェア１０６の従来の機能性と協力して機能し得るということが認識されることになる。

プロビジョニング管理手段１３４は、様々な他の能力、及び機能性を有し得る。例えば、外部の理由（例えば、管理者の要望、資源の再分配、または使用中止にされたノードの故障）のために、ノードがコンピューティンググリッドから使用中止にされて解除されるべきであるとき、例えば、インタフェース６１４は、割り当てモジュール６０４の呼び出しを可能にするグリッドミドルウェア１０６を備えた外部インタフェースの代理をし得る。その場合に、プロビジョニング管理手段１３４は、影響を受けたタスクインスタンス、及び関連するデータパーティションを、別のノードに移動させ得る。

そのように行う際、割り当てモジュール６０４は、例えば、資源管理プログラム６０６からの情報を使用することによって、送り先ノード上で利用可能な資源を検出し得る。割り当てモジュール６０４は、その場合に、もし可能であるならば、少なくともデータパーティションを主催するのに十分な資源を備えたノード“ｉ”、更に、影響を受けたタスクインスタンスのいくらか、または全部を要求する。もし影響を受けたタスクインスタンスの全てをノード“ｉ”へ移動することが実行可能ではないならば、その場合に、割り当てモジュール６０４は、資源管理プログラム６０６に、ノード“ｉ”とノード“ｊ”の各々との間の待ち時間の量によって順序づけられると共に、残っているタスクインスタンスを主催できるノード“ｊ”のセットを提供することを要求し得る。

一度、適切なノードが配置されれば、移動させられるべきデータパーティションと関連付けられた、コンピューティンググリッド上の全てのタスクインスタンスは、中止され得る。割り当てモジュール６０４は、その場合に、データパーティションを移動させると共に、使用中止にされるべきノードから新たに選択されたノードにタスクインスタンスを移動させるために、展開モジュール６１２を呼び出し得る。最終的に、割り当てモジュール６０４は、今停止されたタスクインスタンスを主催する他の全てのノードに関連する待ち時間が、上述の動作によって大幅に増加したか否かをチェックし得る。もしそうであれば、その場合に、ちょうど説明された、ノード“ｊ”の各々とノード“ｉ”との間の待ち時間に関して順序付けられるノード“ｊ”のセットを選択することと同じ手法を使用して、タスクインスタンスは移動させられる（再展開させられる）。

別の実施例において、もし１つのパーティションと関連付けられたタスクインスタンスが活動的ではないと共に、もはやタスクインスタンスが関連するデータパーティションのために予定されていない場合、その場合に、データパーティションは、中央データベース１１８に対して移動され得る。データパーティションを中央データベース１１８に対して移動するための要求は、割り当てモジュール６０４の対応するインタフェース６１４を用いて送信され得る。

図７は、図６のプロビジョニング管理手段の動作例を例証するフローチャート７００である。図７の例において、タスクインスタンスは、待ち行列６０２で受信され得る（７０２）と共に、その後、待ち行列６０２は、タスクインスタンスの到着を割り当てモジュール６０４に通知し得る（７０４）。割り当てモジュール６０４は、従って、もしあればどのデータパーティションがそれらと関連付けられる（例えば、そこからタスクインスタンスが例示化された親タスクと関連付けられる）かを判定するために、マッピングデータベース１３２にアクセスし得る（７０６）。

恐らく資源管理プログラム１３４を使用する割り当てモジュール６０４は、関連するデータパーティションの現在の位置を判定し得る（７０８）と共に、すなわち、そこからデータパーティションが移動させられ得る初期ノードを判定し得る。上述のように、データパーティションは、中央データベース１１８に、もしくは、（例えば、データパーティションのそれに対する更に初期に実行された移動の結果として）実質的にグリッド環境のノードの内の１つのあらゆるローカルデータベースに格納され得る。

割り当てモジュール６０４は、その場合に、資源管理プログラム６０８に、十分な処理資源を有するノードを判定させる（７１０）と共に、十分なメモリ資源を有するノードを判定させる（７１２）。その結果生じるノードのリストは、関連するグリッドパラメータに基づいてフィルタ処理され得る（７１４）。例えば、そのようなグリッドパラメータは、もしそのノードがサービスのしきい値のいくらかの定義された品質を有していない場合に、他の場合には適当なノードが、ノードのリストから取り除かれ得るように、サービス特性の品質を含み得る。

資源管理プログラム６０８は、グリッド環境における一組のノードに関して発見されたか、もしくは利用可能な待ち時間情報を使用し得ると共に、この待ち時間情報を、潜在的な処理ノードのリスト及び潜在的なデータノードのリストの様々な要素のペアに適用し得る。有利な実施例において、潜在的な処理ノードのリスト及び潜在的なデータノードのリストは、このノードが、イントラノード通信に関して取るに足らない待ち時間を有し得るように、少なくとも１つの共通の、もしくは重複しているノードを有していることを発見し得る。もしそうでなければ、その場合には、資源管理プログラム６０８は、最も少ない待ち時間を有する（例えば、最も相互に近い）潜在的な処理ノードと潜在的なデータノードのペアを判定し得る。従って、資源管理プログラム６０８は、最も少ない待ち時間を有する処理ノード及び／またはデータノードを判定し得る（７１６）。

一般的に、資源管理プログラム６０８は、必要とされた処理、メモリ、及び待ち時間特性の全てを有する単一のノードまたは一組のノードを判定し得ると共に、従って、このノードまたは一組のノードを割り当てモジュール６０４に移動し得ると仮定され得る。実際上、もちろん、資源管理プログラム６０８が、それぞれが処理ノードとデータノードの両方として機能し得る（と共に、従って取るに足らない待ち時間を有するであろう）複数のノードを返すということを発見し得る。この場合に、資源管理プログラム６０８は、これらのノードの間の判定を行うために、例えば、最初の利用可能なノード、または最も近いノード、または最も高品質のサービス特性を有するノードを選択し得るために、いくつかの他の基準を使用し得る。

その場合に、割り当てモジュール６０４は、（データノードと同一であるか否かに関係ない処理ノードに対するタスクインスタンスの展開と同様に、）初期ノードから選択されたデータノードに対するデータパーティションの移動が、タスクインスタンスの全体の実行時間を改善することになるか否かを判定し得る（７１８）。この判定を行うための一例のアルゴリズム及び計算は、以下で詳細に提供される。

もし実行時間が移動によって改善されることになる場合、その場合に、タスクインスタンス及びデータパーティションは、展開モジュール６１２によって、上記で判定されたノード（ペア）に展開され得る（７２０）。他の場合には、展開モジュール６１２は、データパーティションを、その現在の位置、すなわち初期ノードに残したままで、単にタスクインスタンスを処理ノードに展開し得る（７２２）。

上記で参照されたように、多くのアルゴリズム及び計算が、タスクインスタンスの処理ノードに対する展開と同様に、初期ノードから選択されたデータノードに対するデータパーティションの移動が、タスクインスタンスの全体の実行時間を改善することになるか否かを判定するために、割り当てモジュール６０４によって使用され得る。下記で説明される一例のアルゴリズムにおいて、以下の変数及び表記法が使用される。最初に、例えば、２つのノード“ｉ”と“ｊ”との間の待ち時間“ｌ”が“ｌ_ｉｊ”で指定され得るように、ノードは、“i”もしくは“j”を使用して表記される。同様に、ノードの間のネットワーク帯域幅“b”は、“b_ij”で指定され得る。

他の変数が、１つ以上の特定のタスクインスタンスの実行に特有であり得る一方、あらゆる特定のタスクインスタンスに特有ではない待ち時間及び帯域幅のような変数は、環境変数と言われ得る。例えば、タスクインスタンスの実行のための時間“ｔ”は、データベースアクセス時間要求にかかわらず、“ｔ_ｅｘｅ”と書かれ得る。

この状況におけるタスクインスタンスは、タスクインスタンスの実行のための仕様を提供するバイナリファイル“ｂｉｎ”であると考えられ得る。同様に、データパーティションは、“ｐａｒｔ”と示され得る。上述のように、タスクインスタンスのバイナリファイル“ｂｉｎ”及びデータパーティション“ｐａｒｔ”の両方は、ノード“ｉ”とノード“ｊ”との間の移動“Ｔ”を経験し得ると共に、ここで、ノード“ｉ”は、ノード“０”として示され得る特別な場合である中央ノードを含み得る。

前述の表記法を使用すると、その場合に、中央ノード１０２からノード“ｉ”に対してタスクインスタンスのバイナリファイル“ｂｉｎ”を移動すると共に展開する時間は、“ｔ_{Ｔｂｉｎ−ｉ}”と書かれ得る。同様に、中央ノード１０２からノード“ｊ”に対してデータパーティション“ｐａｒｔ”を移動すると共に展開する時間は、“ｔ_{Ｔｐａｒｔ−ｊ}”と書かれ得る。

更に表記法に関して、タスクインスタンスにより要求される、対応するデータベースに対するデータベース呼び出しの数は、呼び出しの数“ｃ”と書かれ得る一方、特別なデータベース呼び出しは、呼び出し“ｋ”と表現され得る。タスクインスタンスのバイナリファイル“ｂｉｎ”のファイルのサイズ、またはデータパーティション“ｐａｒｔ”（それは同様にバイナリファイルであり得る）のサイズは、サイズのための変数“ｓ”を用いて表現され得る。ノード“ｉ”からノード“ｊ”に対するデータベース呼び出し“ｋ”を実行するのに必要とされる時間は、“ｔ_{ｃａｌｌ−ｋｉｊ}”と書かれ得る。

前述の表記法を使用すると、これらの例の目的のために、ノード“ｉ”とノード“ｊ”との間のネットワーク接続は、ノード“ｊ”とノード“ｉ”との間の接続と同じ動きを有すると仮定され得る。更に、内部の通信のための待ち時間は、効果的にゼロであると仮定され得る。これらの仮定は、“ｌ_ｉｊ＝ｌ_ｊｉ”と“ｔ_{ｃａｌｌ−ｋｉｊ}＝ｔ_{ｃａｌｌ−ｋｊｉ}”、そして、もし“ｉ＝ｊ”ならば、その場合に“ｌ_ｉｊ＝ｔ_ｉｊ＝０”であるように、様々なノードに関して対称的な待ち時間と時間行列を可能にする。これらの例に関する最終の仮定において、もし“ｉ＝ｊ”ならば、その場合に“ｂ_ｉｊ＝∞”であり、そうでなければ“ｂ_ｉｊ＝ｂ”であるように、コンピューティンググリッドにおける異なる２つのノードの間の帯域幅は、グリッドの至る所で実質的に一定であると共に、１つのノードに関する内部の帯域幅は、ごくわずかだけ高いと仮定され得る。

ノード“ｉ”へのタスクインスタンスの展開、及びノード“ｊ”への必要なデータパーティションの移動を含む全体の実行時間“ｔ”は、前述の表記法を用いて、式（１）によって表され得る。

式（１）は、ノード“ｊ”への関連するデータパーティションの移動と一緒に、ノード“ｉ”に展開されるタスクインスタンスの全体の実行に寄与し得る多くの時間成分の和を提供する。

第１の時間成分は、タスクインスタンスバイナリファイル“ｂｉｎ”及びデータパーティション“ｐａｒｔ”の移動を実行するために必要な時間を処理する。具体的には、項“ｍａｘ（ｔ_{Ｔｂｉｎ−ｉ}、ｔ_{Ｔｐａｒｔ−ｊ}）”は、タスクインスタンスの展開、及びデータパーティションの移動が独立して起こるので、全体の実行時間“ｔ_ｉｊ”への影響が、両方の時間のより長い（すなわち、最大の）ものだけに依存することを意図する。

表記法の前述の記述から認識されるように、第２の時間成分は、単にデータベースアクセス要求を意識せずにタスクインスタンスのバイナリファイルを実行するのに必要とされる実行時間“ｔ_ｅｘｅ”である。最後に、第３の時間成分は、ノード“ｉ”とノード“ｊ”との間の全てのデータベース呼び出しのために必要とされる時間の総和を含む。

式（１）は、特定の例の状況における見方によって更によく理解され得る。例えば、もしパーティションが移動されず、しかし中央ノード１０２、すなわちノード０に単に残される場合、その場合に、以下の効果が式（１）において見られ得る。具体的には、データパーティションの移動のための時間は、この例における定義によって、ゼロ秒であると共に、その結果、第１の項“ｍａｘ（ｔ_{Ｔｂｉｎ−ｉ}、ｔ_{Ｔｐａｒｔ−ｊ}）”は、式（２）で示されたように、単に“ｔ_{Ｔｂｉｎ−ｉ}”に単純化する。

式（２）において、データ呼び出しは、式（２）の第３項によって示されたように、展開されたタスクインスタンス（すなわち、処理ノード“ｉ”上のタスクインスタンス）と、ノード“０”上の中央データベース１１８との間にまだ発生する。

別の例において、データパーティションは、そのジョブが展開される同じノード“ｉ”、すなわち“ｊ＝ｉ≠０”に移動され得る。この例において、式（３）で示されるように、ノードの中のデータ呼び出しのために必要とされるごくわずかな時間の上の仮定は、第３の項がゼロ秒になることを意味する。

式（２）と式（３）を使用して、ノード“ｉ＝ｊ”に対してタスクインスタンス及びデータパーティションを移動する場合に、全体の実行時間が改善され得るか否かに関して、比較が実行され得る。すなわち、もし“ｔ_ｉｉ≦ｔ_ｉ０”である場合に、その場合に、（タスクインスタンスの展開と連動する）関連するデータパーティションの移動は、総合的なタスクインスタンスの実行時間を減少させることが理解され得る。この不等式（及び共通の項“ｔ_ｅｘｅ”の削除の結果生じる単純化）は、以下の式（４）に帰着する。

もし、一例の目的で、タスクインスタンスの展開が少なくともデータパーティションの移動と同じくらいの時間がかかる、すなわち“ｔ_{Ｔｂｉｎ−ｉ}≧ｔ_{Ｔｐａｒｔ−ｉ}”という更なる仮定がなされる場合、その場合に、項“ｍａｘ（ｔ_{Ｔｂｉｎ−ｉ}、ｔ_{Ｔｐａｒｔ−ｊ}）”は、ちょうど“ｔ_{Ｔｂｉｎ−ｉ}”となり、結果的に以下の式（５）となる。

従って、式（５）は、単に、もしタスクインスタンスの展開が少なくともデータパーティションの移動と同じくらい時間がかかる場合、その場合に、ノード“ｉ”に対するデータパーティションの移動は、全体の実行時間の改善になると考えられ得るということが分かり得るという点を示している。これは、もしタスクインスタンスの展開に要求された時間の間にデータパーティションの移動が発生し得る場合、その場合に、基本的に全体の実行時間“ｔ_ｉｉ”に対する損失または効果はないという事実から分かり得ると共に、従って、データパーティションの移動は、データパーティションへのデータ呼び出しを実行するのに必要とされる削減された時間の利益を得るために、（すなわち、中央データベースに対して実行されるデータ呼び出しと対立するような、ノードそれ自体の中のデータ呼び出しのために、）進行するべきである。

しかしながら、逆の場合において、データパーティションを移動するための時間が、タスクインスタンスを展開するために必要とされる時間より長い場合に、その結果は以下の式（６）で示される。

ランタイムにおいてこの不等式を解決するために、割り当てモジュール６０４は、様々な時間変数に値を代入し得ると共に、結果を計算し得る。

このような目的で、様々な時間変数は、割り当てモジュール６０４に知られている値、及びユニットの観点から表現され得るか、及び／または割り当てモジュール６０４によって計算され得る。そのような表現は、式（７）から式（９）の例において以下で提供される。

例えば、グリッドネットワークにおいてデータを移動するための時間は、(例えば、バイトにおける)データのサイズ“ｓ”、帯域幅“ｂ”、及び待ち時間“ｌ”の関数として説明され得る。例えば、式（７）は、移動されるパーティションのサイズ、中央ノード１０２とノード“ｉ”との間の待ち時間、及び関連する帯域幅“ｂ”の観点から、データパーティションをノード“ｉ”移動するための時間を表現する。

関連するデータ呼び出しのために必要とされる時間は、以下の式（８）で書かれ得ると共に、それは、データ呼び出しに関する要求と応答における待ち時間を説明するための２つの待ち時間の項“ｌ_ｉ０”及び“ｌ_０ｉ”を含んでいる。

タスクインスタンスを展開する（例えば、ジョブバイナリ（job binary）を移動する）ために必要とされる時間は、式（９）のように書かれ得ると共に、それは、式（７）と式（８）に類似しており、ノード“ｉ”のローカルサーバ（例えば、図１のサーバ１２６ｂ）上のタスクインスタンスの移動されたバイナリファイルを実際に展開するために必要とされる時間と関連付けられた“ｔ_{ｄｅｐｌｏｙ}”だけでなく、バイナリのサイズ、帯域幅、及び中央ノードとノード“ｉ”との間の待ち時間によって変わる。

式（７）、式（８）、及び式（９）を、式（６）の不等式に代入することは、式（１１）に示される結果を提供する。

“ｔ_{ｄｅｐｌｏｙ}≧０”なので、もし以下の式（１２）が維持される場合に、上記の条件は、正しい。

従って、データパーティションの移動を行うか否かに関する判定は、式（１３）のように書かれ得ると共に、ここで、項“２ｃ”は、関連するデータ呼び出しと関連付けられた通信の全２重特性を説明する。

認識され得るように、式（１３）は、データパーティションの移動が例の状況において有益であるように、データパーティションのサイズとタスクインスタンスのバイナリファイルのサイズとの間のサイズにおける差異（すなわち、不等式の左手側）は、データ呼び出しの数、関連する待ち時間、帯域幅、及びデータ呼び出しのサイズによって判定された量（すなわち、不等式の右手側）より小さくなければならないことを意味する。この状態は、高い待ち時間“ｌ_ｉ０”、大きな帯域幅“ｂ”、多数のデータ呼び出し、及び／または送信されるべき多量のデータ“ｓ_{ｄａｔａ−ｋ}”の存在下で、より発生し得る。この点に関して、上述のように、この明細書は、グリッドにより改善される（grid-enhanced）べきである（すなわち、グリッド関連の（grid-related）地理的分散が、高い待ち時間“ｌ_ｉ０”の可能性を増やす）データ集中型アプリケーション（data-intensive application）（すなわち、“ｃ”及び“ｓ_{ｄａｔａ−ｋ}”が大きくなることがあり得る）を対象とするということが理解されることになる。従って、上述の状態の多数または全ては、説明されたシナリオにおいて、及び他の同様のシナリオにおいて維持され得ると共に、これらの状況における利益は、データパーティションの移動から獲得され得る。

同様の計算が、他の同様のシナリオで実行され得る。例えば、前述の計算は、データパーティションが中央ノードから（すなわち、初期ノードとしての中央ノードによって）展開されるべきである状況に関して提供される。しかしながら、もし別のノード“ｊ”が現在データパーティションを格納しており（すなわち、初期ノードとして機能することになる）、別のノード“ｉ”が関連したタスクインスタンスを主催すると共に、少なくとも“ｌ_ｉｊ”と同じくらい大きい“ｌ_ｉ０”を有することが発見され得る場合に、その場合に、性能改善は、タスクインスタンスをノード“ｉ”に展開することによって獲得され得る。もちろん、もし“ｉ＝ｊ”である場合、その場合に、待ち時間“ｌ_ｉｊ”はゼロに達すると共に、ちょうど言及された状態が維持されることになる。

前述の記述は、一例の目的のためであると共に、他の実施例を制限するものではない。例えば、上述の計算は、単一のタスクインスタンスに基づいてデータパーティションを移動する場合に、性能改善があるか否かを評価する。しかしながら、ランタイムでは、同じタスクの１を超えるインスタンスがあり得る。もしゴールが総じてタスクの平均性能を向上させることであるならば、その場合に、全ての関連するタスクインスタンスの蓄積された性能が考慮され得る。例えば、プロビジョニング管理手段１３４は、第１のタスクインスタンスが待ち行列６０２に入る時に、実際には全部で“ｍ”個のタスクインスタンスが予測されると判定し得る。

この例において、その場合に、データパーティションを移動することを支持する状況は、単一のタスクが“ｍ”個のタスクインスタンスを必要とする場合に、以下の式（１４）で与えられる。式（１４）において、“（ｍ−１）”個のタスクインスタンスに関して、バイナリの移動時間と展開時間（ｔ’_ｉｉ）の和だけが考慮される必要があるということが認識されることになる。

ここで説明された様々な技術の処理系は、デジタル電子回路部品において、もしくはコンピュータハードウェア、ファームウェア、ソフトウェアにおいて、もしくはそれらの組み合わせにおいて実現され得る。処理系は、データ処理装置、例えばプログラム可能なプロセッサ、コンピュータ、または複数のコンピュータによる実行のために、または前記データ処理装置の動作を制御するために、コンピュータプログラム製品、すなわち情報担体において、例えばコンピュータ読み取り可能な記憶装置、もしくは伝搬された信号において明白に具現化されたコンピュータプログラムとして実現され得る。上述のコンピュータプログラムのようなコンピュータプログラムは、コンパイラ型言語またはインタープリタ型言語を含むあらゆる形式のプログラミング言語で書かれ得ると共に、スタンドアロンプログラムのような、またはモジュール、コンポーネント、サブルーチンのような、またはコンピュータ環境における使用に適当な他のユニットのようなあらゆる形式で展開され得る。コンピュータプログラムは、１つのサイトの１台のコンピュータ上で、もしくは１つのサイトの複数のコンピュータ上で実行されるように展開され得るか、または複数のサイトを横断して分散され得ると共に、通信ネットワークによって相互接続され得る。

方法のステップは、入力データを処理すると共に、出力を生成することによって機能を実行するために、コンピュータプログラムを遂行する１つ以上のプログラム可能なプロセッサによって実行され得る。同様に、方法のステップは、専用論理回路構成、例えば、ＦＰＧＡ（field programmable gate array）、またはＡＳＩＣ（特定用途向け集積回路）によって実行され得ると共に、装置は、専用論理回路構成、例えば、ＦＰＧＡ（field programmable gate array）、またはＡＳＩＣ（特定用途向け集積回路）として実装され得る。

コンピュータプログラムの実行に適当なプロセッサは、一例として、一般的な目的そして特別な目的のマイクロプロセッサ、及びあらゆる種類のデジタルコンピュータの内のあらゆる１つ以上のプロセッサを含む。一般的に、プロセッサは、リードオンリーメモリ（ＲＯＭ）またはランダムアクセスメモリ（ＲＡＭ）またはその両方から、命令及びデータを受信することになる。コンピュータの要素は、命令を実行するための少なくとも１つのプロセッサと、命令及びデータを格納するための１つ以上のメモリ装置とを含み得る。一般的に、コンピュータは、更に、そこからデータを受信するか、またはそこへデータを移動するか、またはその両方のために、データを格納するための１つ以上の大容量記憶装置、例えば、磁気ディスク、光磁気ディスク、または光ディスクを備え得るか、あるいは動作可能なように、データを格納するための１つ以上の大容量記憶装置、例えば、磁気ディスク、光磁気ディスク、または光ディスクに接続され得る。コンピュータプログラム命令及びデータを具現化することに適当な情報担体は、全ての形式の不揮発性メモリ、一例として、半導体メモリ装置、例えばＥＰＲＯＭ、ＥＥＰＲＯＭ；及びフラッシュメモリ装置；磁気ディスク、例えば内蔵ハードディスクまたはリムーバブルディスク；光磁気ディスク；及びＣＤ−ＲＯＭディスクとＤＶＤ−ＲＯＭディスクを含む。プロセッサ及びメモリは、専用論理回路構成によって追加され得るか、または専用論理回路構成に組み込まれ得る。

ユーザとの対話を提供するために、処理系は、情報をユーザに表示するための表示装置、例えばブラウン管（ＣＲＴ）または液晶表示装置（ＬＣＤ）、そして、それによりユーザがコンピュータに入力を提供することができるキーボード及びポインティングデバイス、例えばマウスまたはトラックボールを有するコンピュータ上で実現され得る。同様に、他の種類の装置が、ユーザとの対話を提供するために使用され得て、例えば、ユーザに提供されたフィードバックは、あらゆる形式のセンサフィードバック、例えば視覚フィードバック、聴覚フィードバック、または触覚フィードバックであり得えると共に、音響入力、音声入力、または触覚入力（tactile input）を含むユーザからの入力は、いかなる形式にせよ受け入れられ得る。

処理系は、コンピューティングシステムにおいて実現され得ると共に、コンピューティングシステムは、例えばデータサーバとして、バックエンドコンポーネントを含むか、またはコンピューティングシステムは、ミドルウェアコンポーネント、例えばアプリケーションサーバを含むか、またはコンピューティングシステムは、フロントエンドコンポーネント、例えばそれを通してユーザが処理系と対話し得るグラフィカルユーザインタフェースまたはウェブブラウザを有するクライアントコンピュータを含むか、またはコンピューティングシステムは、そのようなバックエンドコンポーネント、ミドルウェアコンポーネント、フロントエンドコンポーネントのあらゆる組み合わせを含む。コンポーネントは、デジタルデータ通信のあらゆる形式または媒体、例えば通信ネットワークによって相互接続され得る。通信ネットワークの例は、ローカルエリアネットワーク（ＬＡＮ）及び広域ネットワーク（ＷＡＮ）、例えばインターネットを含む。

説明された処理系の特定の特徴がここで説明されたように例証されたが、同時に、多くの修正、置換、変更、及び等価物が、当業者の心に浮かぶことになる。従って、添付の請求項がそのような実施例の範囲内の修正及び変更の全てをカバーするように意図されるということが理解されることになる。

グリッド環境においてデータ及びタスクインスタンスを分散するためのシステムの構成図である。 図１のシステムの実施例を例証する構成図である。 図１及び図２のシステムの動作例を例証するフローチャートである。 図１及び図２のシステムのパーティション分析手段の構成図である。 図４のパーティション分析手段の動作例を例証するフローチャートである。 図１及び図２のプロビジョニング管理手段の構成図である。 図６のシステムの動作例を示すフローチャートである。

符号の説明

１００ システム
１０２ 中央ノード
１０４ａ、１０４ｂ ノード
１０４ｃ 処理ノード
１０４ｄ データノード
１０４ｅ データノード
１０４ｆ 処理／データノード
１０６ グリッドミドルウェア
１０８ ビジネスアプリケーション
１１０ 照会発生器
１１２ レポート管理手段
１１４ タスクリポジトリ
１１６ タスクインスタンス
１１６ａ タスクインスタンス
１１６ｂ タスクインスタンス
１１８ 中央データベース
１２０ 分散システム
１２２ａ データパーティション
１２２ｂ データパーティション
１２４ａ、１２４ｂ、１２４ｃ 連合データベース管理システム
１２６ａ、１２６ｂ ローカルサーバ
１２８ａ、１２８ｂ ローカルデータベース
１３０ パーティション分析手段
１３２ マッピングデータベース
１３４ プロビジョニング管理手段
３０２、３０４、３０６、３０８、３１０、３１２、３１４ データ
３１６ａ、３１６ｂ、３１６ｃ タスク
３１８ａ、３１８ｂ、３１８ｃ データ呼び出し
６０２ 待ち行列
６０４ 割り当てモジュール
６０６ 資源管理プログラム（資源管理手段）
６０８、６１４ インタフェース
６１０ 待ち時間マトリクス
６１２ 展開モジュール

Claims (20)

1. グリッドネットワークのデータベースの中の少なくとも１つのデータパーティションを指定するように構成されると共に、グリッドネットワークの中で部分的に実行されるべきアプリケーションの少なくとも１つのタスクに対してデータパーティションのマッピングを実行するように更に構成されるパーティション分析手段と、
   少なくとも１つのタスクのタスクインスタンスを判定し、前記マッピングに基づいて、前記グリッドネットワークの初期ノードに格納されるデータパーティションを判定し、前記タスクインスタンスを実行するのに必要とされる処理資源を有する前記グリッドネットワークの処理ノード、及び前記データパーティションを格納するのに必要とされるメモリ資源を有する前記グリッドネットワークのデータノードを、それらの間の待ち時間に基づいて判定し、前記データノードにおけるデータパーティションを有するタスクインスタンスの実行時間が、前記初期ノードに残存するデータパーティションを有するタスクインスタンスのデフォルトの実行時間より少ないか否かに関して、比較を実行し、前記比較に基づいて、前記タスクインスタンスを前記処理ノードに展開すると共に、前記データパーティションを前記初期ノードから前記データノードに移動するように構成されるプロビジョニング管理手段と
   を備えることを特徴とするシステム。
2. 前記パーティション分析手段が、データパーティションに対するタスクのアクセス特性に基づいて、少なくとも１つのデータパーティションを指定するように構成される
   ことを特徴とする請求項１に記載のシステム。
3. 前記アクセス特性が、１つ以上の未来のタスクインスタンスによるデータパーティションのアクセスの予測される周波数を含む
   ことを特徴とする請求項２に記載のシステム。
4. 前記初期ノードは、そこにデータベースが格納される前記グリッドネットワークの中央ノードを含む
   ことを特徴とする請求項１に記載のシステム。
5. 前記初期ノードは、少なくとも１つのデータパーティションが前記プロビジョニング管理手段の以前のプロビジョニング動作の一部分として以前に展開された以前のデータノードを含む
   ことを特徴とする請求項１に記載のシステム。
6. 前記プロビジョニング管理手段が、前記処理資源を有する前記グリッドネットワークにおける、前記処理ノードを含む第１の複数のノードを判定し、前記メモリ資源を有する前記グリッドネットワークにおける、前記データノードを含む第２の複数のノードを判定し、前記第１の複数のノードの中のノードと前記第２の複数のノードの中のノードとの組み合わせの間の待ち時間を判定することによって、前記処理ノード及び前記データノードを判定するように構成される資源管理手段を備える
   ことを特徴とする請求項１に記載のシステム。
7. 前記資源管理手段は、前記処理ノードと前記データノードとの間の待ち時間が、ノードの他の組み合わせの間の待ち時間より少ないと判定することによって、前記処理ノード及び前記データノードを判定するように構成される
   ことを特徴とする請求項６に記載のシステム。
8. 前記第１の複数のノード及び前記第２の複数のノードが、共通のノードを含むと共に、
   
   前記プロビジョニング管理手段が、前記共通のノードを前記処理ノード及び前記データノードの両方として選択するように構成される
   ことを特徴とする請求項６に記載のシステム。
9. 前記プロビジョニング管理手段が、前記グリッドネットワークに関連付けられたグリッドの伝送特性に基づいて、前記第１の複数のノード及び前記第２の複数のノードの内の１つ、または両方から、１つ以上のノードを濾過して取り除くように構成される資源管理手段を備える
   ことを特徴とする請求項６に記載のシステム。
10. 前記プロビジョニング管理手段が、前記タスクインスタンスを展開する展開時間と前記データパーティションを前記初期ノードから前記データノードに移動する移動時間のより大きい方を含む場合の実行時間を計算することによって、そして前記タスクインスタンスを展開する展開時間を含む場合のデフォルトの実行時間を計算することによって、比較を実行するように構成される割り当てモジュールを備える
    ことを特徴とする請求項１に記載のシステム。
11. 前記プロビジョニング管理手段が、前記タスクインスタンスのインスタンス実行時間を含む場合の実行時間を計算することによって、そして前記データパーティションに対するデータ呼び出しを実行するために前記タスクインスタンスにより要求されるデータ呼び出し時間を含む場合のデフォルトの実行時間を計算することによって、比較を実行するように構成される割り当てモジュールを備える
    ことを特徴とする請求項１に記載のシステム。
12. 前記プロビジョニング管理手段が、比較に基づき、連合データベース管理システムを使用して、前記データパーティションを前記初期ノードから前記データノードに移動するように構成される
    ことを特徴とする請求項１に記載のシステム。
13. 実行されるべきタスクインスタンスを判定する段階と、
    前記タスクインスタンスの実行と関連付けられると共に、グリッドネットワークの初期ノードに格納されたデータパーティションを判定する段階と、
    前記タスクインスタンスを実行するのに必要とされる処理資源を有する前記グリッドネットワークの処理ノード、及び前記データパーティションを格納するのに必要とされるメモリ資源を有する前記グリッドネットワークのデータノードを、それらの間の待ち時間に基づいて判定する段階と、
    前記データノードにおけるデータパーティションを有するタスクインスタンスの実行時間が、前記初期ノードに残存するデータパーティションを有するタスクインスタンスのデフォルトの実行時間より少ないか否かに関して、比較を実行する段階と、
    前記比較に基づいて、前記タスクインスタンスを前記処理ノードに展開すると共に、前記データパーティションを前記初期ノードから前記データノードに移動する段階と
    を含むことを特徴とする方法。
14. 前記データパーティションを判定する段階が、前記データパーティションに対して以前に実行された、そこから前記タスクインスタンスが例示化されるアプリケーションのタスクのマッピングにアクセスする段階を含み、
    前記マッピングが、前記データパーティションに対する前記タスクインスタンスのアクセス特性と関連付けられる
    ことを特徴とする請求項１３に記載の方法。
15. 待ち時間を判定する段階が、
    前記処理資源を有する前記グリッドネットワークにおける、前記処理ノードを含む第１の複数のノードを判定する段階と、
    前記メモリ資源を有する前記グリッドネットワークにおける、前記データノードを含む第２の複数のノードを判定する段階と、
    前記第１の複数のノードの中のノードと前記第２の複数のノードの中のノードとの間の待ち時間を判定することによって、前記処理ノード及び前記データノードを判定する段階と
    を含むことを特徴とする請求項１３に記載の方法。
16. 前記比較を実行する段階が、前記タスクインスタンスを展開する展開時間と前記データパーティションを前記初期ノードから前記データノードに移動する移動時間のより大きい方を含む場合の実行時間を計算する段階を含む
    ことを特徴とする請求項１３に記載の方法。
17. コンピュータ読み取り可能な記録媒体上で明白に具現化されるコンピュータプログラムであって、実行された場合に、データ処理装置に、
    アプリケーションのタスクから例示化される、グリッドネットワークにおいて実行されるべきタスクインスタンスを受信する処理と、
    前記アプリケーションと関連付けられたデータベースから、前記タスクインスタンスに基づいて、前記タスクと関連付けられると共に、前記グリッドネットワークの初期ノードに格納されたデータパーティションを判定する処理と、
    前記タスクインスタンスを実行するための十分な処理資源を有する前記グリッドネットワークの処理ノードを判定する処理と、
    前記データパーティションを格納するための十分なメモリ資源を有する前記グリッドネットワークのデータノードを判定する処理と、
    前記初期ノードから前記データノードに移動されたデータパーティションを有する前記処理ノードにおけるタスクインスタンスの実行時間が、前記初期ノードに残存するデータパーティションを有するタスクインスタンスのデフォルトの実行時間より少ないと判定する処理と、
    前記タスクインスタンスを前記処理ノードに展開する処理と、
    前記データパーティションを前記初期ノードから前記データノードに移動する処理とを実行させるように構成される実行可能コードを含む
    ことを特徴とするコンピュータプログラム。
18. 前記処理ノード及び前記データノードが、それらの間の待ち時間に基づいて選択される
    ことを特徴とする請求項１７に記載のコンピュータプログラム。
19. 前記実行時間が、前記タスクインスタンスを展開する展開時間と前記データパーティションを前記初期ノードから前記データノードに移動する移動時間のより大きい方を含む
    ことを特徴とする請求項１７に記載のコンピュータプログラム。
20. 前記グリッドネットワークと関連付けられたグリッドミドルウェアが、前記タスクインスタンスを受信すること、前記処理ノードに前記タスクインスタンスを展開すること、及び前記データパーティションを前記初期ノードから前記データノードに移動することの内の１つ以上と関連付けられる
    ことを特徴とする請求項１７に記載のコンピュータプログラム。

Images