特許 7163430 リソースを提供するためのシステム、方法、及び非一時的コンピュータ可読媒体

(19)【発行国】日本国特許庁(JP)

(12)【公報種別】特許公報(B2)

(11)【特許番号】

(24)【登録日】2022-10-21

(45)【発行日】2022-10-31

(54)【発明の名称】リソースを提供するためのシステム、方法、及び非一時的コンピュータ可読媒体

(51)【国際特許分類】

   G06F 9/50 20060101AFI20221024BHJP

   G06F 16/188 20190101ALI20221024BHJP

   G06F 9/455 20060101ALI20221024BHJP

【ＦＩ】

G06F9/50 120Z

G06F16/188

G06F9/455 150

【請求項の数】 24

(21)【出願番号】P 2021017358

(22)【出願日】2021-02-05

(62)【分割の表示】P 2016553025の分割

【原出願日】2015-02-18

(65)【公開番号】P2021077406

(43)【公開日】2021-05-20

【審査請求日】2021-03-05

(31)【優先権主張番号】14/518,826

(32)【優先日】2014-10-20

(33)【優先権主張国・地域又は機関】US

(31)【優先権主張番号】61/941,986

(32)【優先日】2014-02-19

(33)【優先権主張国・地域又は機関】US

(73)【特許権者】

【識別番号】516245999

【氏名又は名称】スノーフレーク インク．

(74)【代理人】

【識別番号】100121083

【弁理士】

【氏名又は名称】青木 宏義

(74)【代理人】

【識別番号】100138391

【弁理士】

【氏名又は名称】天田 昌行

(74)【代理人】

【識別番号】100074099

【弁理士】

【氏名又は名称】大菅 義之

(72)【発明者】

【氏名】ダジュヴィル，ブノワット

(72)【発明者】

【氏名】クルアネス，ティエリー

(72)【発明者】

【氏名】ズコウスキー，マシーン

【審査官】多賀 実

(56)【参考文献】

【文献】特開２０１３－１８２５０９（ＪＰ，Ａ）

【文献】特開２００５－０５６０７７（ＪＰ，Ａ）

【文献】米国特許出願公開第２０１０／０１４５９２９（ＵＳ，Ａ１）

【文献】特開２０１２－１９８８４３（ＪＰ，Ａ）

【文献】特開２０１２－２０８７８１（ＪＰ，Ａ）

(58)【調査した分野】(Int.Cl.，ＤＢ名)

Ｇ０６Ｆ ９／４５５－９／５４

Ｇ０６Ｆ １６／１８８

(57)【特許請求の範囲】

【請求項1】

データベースデータを纏めて格納する複数のリモートストレージデバイスと、
前記複数のリモートストレージデバイスにアクセスする実行プラットフォームであって、前記実行プラットフォームは複数の仮想ウェアハウスを含み、前記複数の仮想ウェアハウスの各々は、前記複数のリモートストレージデバイスのうちの任意のリモートストレージデバイスからデータを取得し、かつ、前記複数のリモートストレージデバイスのうちの任意のリモートストレージデバイスにデータを格納し、前記複数の仮想ウェアハウスの各々は、１つ以上のクライアント装置から前記データベースデータに向けられたデータ処理要求を実行するための複数の実行ノードを含み、前記複数の実行ノードの各々が、前記複数のリモートストレージデバイスのうちの１つ以上から取得されたデータを格納するように構成されたキャッシュと、前記複数のリモートストレージデバイスから独立して動作するプロセッサとを含む、実行プラットフォームと、
前記１つ以上のクライアント装置と前記実行プラットフォームとの間に結合されたリソースマネージャと、
を備えたシステムであって、
前記リソースマネージャは、
前記１つ以上のクライアント装置から受信された各データ処理要求に対して、該データ処理要求を処理するのに必要な複数のタスクを決定し、該複数のタスクを前記仮想ウェアハウスの前記複数の実行ノードに分配することと、
以前に受信したデータ処理要求に基づき、未来の予測されるデータ処理要求を決定することと、
前記１つ以上のクライアント装置から受信された前記データ処理要求を監視することであって、該受信されたデータ処理要求は、現在継続中のデータ処理要求である、ことと、
前記複数の仮想ウェアハウスの各々の現在のリソース利用率を監視することであって、前記仮想ウェアハウスの前記現在のリソース利用率は、前記仮想ウェアハウス内の１つ以上の実行ノードのキャッシュ利用率及びプロセッサ利用率を含む、ことと、
前記１つ以上のクライアント装置から受信された前記データ処理要求と前記予測されるデータ処理要求とを実行するための十分な利用可能なリソースを前記複数の仮想ウェアハウスが有しているか否かを、前記複数の仮想ウェアハウスの各々における前記現在のリソース利用率に基づいて判定することにより、追加の仮想ウェアハウスが必要か否かを判定することと、
追加の仮想ウェアハウスが必要であるという判定に応じて、前記複数のリモートストレージデバイスにおけるストレージの量を増加させずに、新規の仮想ウェアハウスを提供することと、
を行う、システム。

【請求項2】

前記リソースマネージャは、クエリ応答率を監視することを更に行う、請求項１に記載のシステム。

【請求項3】

前記リソースマネージャは、同時に実行しているクエリの数、最大負荷のパーセンテージ、及び、いずれかのクエリの処理が遅延しているか否か、のうちの少なくとも１つを監視すること、を更に行う、請求項１に記載のシステム。

【請求項4】

前記リソースマネージャは、前記新規の仮想ウェアハウスがもう必要ないと判定するのに応じて、前記新規の仮想ウェアハウスを非アクティブにすること、を更に行う、請求項１に記載のシステム。

【請求項5】

前記リソースマネージャは、
今度のデータ処理プロジェクトの通知を受信することと、
前記今度のデータ処理プロジェクトの前記通知を受信するのに応じて、前記今度のデータ処理プロジェクトに関連付けられた新規の仮想ウェアハウスを生成することと、
を更に行う、請求項１に記載のシステム。

【請求項6】

前記リソースマネージャは、前記今度のデータ処理プロジェクトの完了時に、前記今度のデータ処理プロジェクトに関連付けられた前記新規の仮想ウェアハウスを非アクティブにすること、を更に行う、請求項５に記載のシステム。

【請求項7】

前記今度のデータ処理プロジェクトが所定の持続期間を有しており、前記今度のデータ処理プロジェクトに関連付けられた前記新規の仮想ウェアハウスは、前記所定の持続時間の後、非アクティブにされる、請求項５に記載のシステム。

【請求項8】

前記リソースマネージャは、
複数のデータ処理活動を実行するための要求を受信することと、
前記複数のデータ処理活動を実行するための前記要求を受信するのに応じて、前記受信した要求に関連付けられた新規の仮想ウェアハウスを自動的に生成することと、
を更に行う、請求項１に記載のシステム。

【請求項9】

１つ以上のクライアント装置から受信された各データ処理要求に対して、該データ処理要求を処理するのに必要な複数のタスクを決定し、該複数のタスクを仮想ウェアハウスの複数の実行ノードに分配することであって、前記仮想ウェアハウスは複数の仮想ウェアハウスのうちの１つであり、前記複数の仮想ウェアハウスの各々は、前記１つ以上のクライアント装置から、複数のリモートストレージデバイスに格納されたデータベースデータに向けられた、データ処理要求を実行するための複数の実行ノードを含む、ことと、
以前に受信したデータ処理要求に基づき、未来の予測されるデータ処理要求を決定することと、
前記１つ以上のクライアント装置から受信された前記データ処理要求を監視することであって、該受信されたデータ処理要求は、現在継続中のデータ処理要求である、ことと、
前記複数の仮想ウェアハウスの各々の現在のリソース利用率を監視することであって、前記仮想ウェアハウスの前記現在のリソース利用率は、前記仮想ウェアハウス内の１つ以上の実行ノードのキャッシュ利用率及びプロセッサ利用率を含む、ことと、
前記１つ以上のクライアント装置から受信された前記データ処理要求と前記予測されるデータ処理要求とを実行するための十分な利用可能なリソースを前記複数の仮想ウェアハウスが有しているか否かを、前記複数の仮想ウェアハウスの各々における前記現在のリソース利用率に基づいて判定することにより、追加の仮想ウェアハウスが必要か否かを判定することと、
追加の仮想ウェアハウスが必要であるという判定に応じて、前記複数のリモートストレージデバイスにおけるストレージの量を増加させずに、新規の仮想ウェアハウスを提供することと、
を含む方法。

【請求項10】

クエリ応答率を監視することを更に含む、請求項９に記載の方法。

【請求項11】

同時に実行しているクエリの数、最大負荷のパーセンテージ、及び、いずれかのクエリの処理が遅延しているか否か、のうちの少なくとも１つを監視すること、を更に含む、請求項９に記載の方法。

【請求項12】

前記新規の仮想ウェアハウスがもう必要ないと判定するのに応じて、前記新規の仮想ウェアハウスを非アクティブにすること、を更に含む、請求項９に記載の方法。

【請求項13】

今度のデータ処理プロジェクトの通知を受信することと、
前記今度のデータ処理プロジェクトの前記通知を受信するのに応じて、前記今度のデータ処理プロジェクトに関連付けられた新規の仮想ウェアハウスを生成することと、
を更に含む、請求項９に記載の方法。

【請求項14】

前記データ処理プロジェクトの完了時に、前記新規の仮想ウェアハウスを非アクティブにすること、を更に含む、請求項１３に記載の方法。

【請求項15】

前記今度のデータ処理プロジェクトが所定の持続期間を有しており、前記新規の仮想ウェアハウスは、前記所定の持続時間の後、非アクティブにされる、請求項１３に記載の方法。

【請求項16】

複数のデータ処理活動を実行するための要求を受信することと、
前記複数のデータ処理活動を実行するための前記要求を受信するのに応じて、前記受信した要求に関連付けられた新規の仮想ウェアハウスを自動的に生成することと、
を更に含む、請求項９に記載の方法。

【請求項17】

命令が格納された非一時的コンピュータ可読媒体であって、前記命令がプロセッサによって実行された場合、前記プロセッサに、
１つ以上のクライアント装置から受信された各データ処理要求に対して、該データ処理要求を処理するのに必要な複数のタスクを決定し、該複数のタスクを仮想ウェアハウスの複数の実行ノードに分配することであって、前記仮想ウェアハウスは複数の仮想ウェアハウスのうちの１つであり、前記複数の仮想ウェアハウスの各々は、前記１つ以上のクライアント装置から、複数のリモートストレージデバイスに格納されたデータベースデータに向けられた、データ処理要求を実行するための複数の実行ノードを含む、ことと、
以前に受信したデータ処理要求に基づき、未来の予測されるデータ処理要求を決定することと、
前記１つ以上のクライアント装置から受信された前記データ処理要求を監視することであって、該受信されたデータ処理要求は、現在継続中のデータ処理要求である、ことと、
前記複数の仮想ウェアハウスの各々の現在のリソース利用率を監視することであって、前記仮想ウェアハウスの前記現在のリソース利用率は、前記仮想ウェアハウス内の１つ以上の実行ノードのキャッシュ利用率及びプロセッサ利用率を含む、ことと、
前記１つ以上のクライアント装置から受信された前記データ処理要求と前記予測されるデータ処理要求とを実行するための十分な利用可能なリソースを前記複数の仮想ウェアハウスが有しているか否かを、前記複数の仮想ウェアハウスの各々における前記現在のリソース利用率に基づいて判定することにより、追加の仮想ウェアハウスが必要か否かを判定することと、
追加の仮想ウェアハウスが必要であるという判定に応じて、前記複数のリモートストレージデバイスにおけるストレージの量を増加させずに、新規の仮想ウェアハウスを提供することと、
を行わせる、非一時的コンピュータ可読媒体。

【請求項18】

前記プロセッサは、クエリ応答率を監視すること、を更に行う、請求項１７に記載の非一時的コンピュータ可読媒体。

【請求項19】

前記プロセッサは、同時に実行しているクエリの数、最大負荷のパーセンテージ、及び、いずれかのクエリの処理が遅延しているか否か、のうちの少なくとも１つを監視すること、を更に行う、請求項１７に記載の非一時的コンピュータ可読媒体。

【請求項20】

前記プロセッサは、前記新規の仮想ウェアハウスがもう必要ないと判定するのに応じて、前記新規の仮想ウェアハウスを非アクティブにすること、を更に行う、請求項１７に記載の非一時的コンピュータ可読媒体。

【請求項21】

前記プロセッサは、
今度のデータ処理プロジェクトの通知を受信することと、
前記今度のデータ処理プロジェクトの前記通知を受信するのに応じて、前記今度のデータ処理プロジェクトに関連付けられた新規の仮想ウェアハウスを生成することと、
を更に行う、請求項１７に記載の非一時的コンピュータ可読媒体。

【請求項22】

前記プロセッサは、前記データ処理プロジェクトの完了時に、前記新規の仮想ウェアハウスを非アクティブにすること、を更に行う、請求項２１に記載の非一時的コンピュータ可読媒体。

【請求項23】

前記今度のデータ処理プロジェクトが所定の持続期間を有しており、前記新規の仮想ウェアハウスは、前記所定の持続時間の後、非アクティブにされる、請求項２１に記載の非一時的コンピュータ可読媒体。

【請求項24】

前記プロセッサは、
複数のデータ処理活動を実行するための要求を受信することと、
前記複数のデータ処理活動を実行するための前記要求を受信するのに応じて、前記受信した要求に関連付けられた新規の仮想ウェアハウスを自動的に生成することと、
を更に行う、請求項１７に記載の非一時的コンピュータ可読媒体。

【発明の詳細な説明】

【技術分野】

【0001】

＜関連出願への参照＞
この出願は、２０１４年２月１９日出願の“Ａｐｐａｒａｔｕｓ ａｎｄ ｍｅｔｈｏｄ ｆｏｒ ｅｎｔｅｒｐｒｉｓｅ ｄａｔａ ｗａｒｅｈｏｕｓｅ ｄａｔａ ｐｒｏｃｅｓｓｉｎｇ ｏｎ ｃｌｏｕｄ ｉｎｆｒａｓｔｒｕｃｔｕｒｅ，”という発明の名称の米国仮出願第６１／９４１，９８６号の利益を主張し、米国仮出願第６１／９４１，９８６号の全体は、ここに、参照によって組み込まれる。

【0002】

＜技術分野＞
本開示は、データ処理及びデータストレージに関するリソースを管理するリソース管理システム及び方法に関する。

【背景技術】

【0003】

今日、多くの既存のデータ格納・検索（ｒｅｔｒｉｅｖａｌ、取得）システムが利用可能である。例えば、共有ディスクシステムにおいては、すべてのデータは、データクラスタ内のすべての処理ノードからアクセス可能な共有ストレージデバイス上に格納される。この種類のシステムにおいては、データクラスタ内のすべての処理ノードが、データの整合性のあるバージョンにアクセスすることを保証するために、すべてのデータの変更は共有ストレージデバイスに書き込まれる。共有ディスクシステムにおいて、処理ノードの数が増加すると、共有ストレージデバイス（及び、処理ノードと共有ストレージデバイスとの間の通信リンク）は、データの読み取り、及び、データの書き込み動作を遅くするボトルネックとなる。このボトルネックは、より多くの処理ノードを追加することにより、更に悪化する。従って、既存の共有ディスクシステムは、このボトルネック問題により、スケーラビリティが制限される。

【0004】

他の既存のデータストレージ及び検索システムは、「シェアド・ナッシング・アーキテクチャ（ｓｈａｒｅｄ－ｎｏｔｈｉｎｇ ａｒｃｈｉｔｅｃｔｕｒｅ）」と呼ばれる。このアーキテクチャにおいては、データは、複数の処理ノードに渡って分散され、各ノードが、データベース全体のデータの部分集合を格納するようにする。新規の処理ノードが追加または、除去されるとき、シェアド・ナッシング・アーキテクチャは、複数の処理ノードに渡って、データを再配置しなければならない。このデータの再配置は、時間がかかり、データ再配置の間に実行されるデータ読み取り、及び、書き込み動作に対して、混乱を起こしえる。そして、データの特定のノードに対するアフィニティは、良く使われるデータ用のデータクラスタ上で、「ホットスポット」を形成しうる。更に、各処理ノードは、また、ストレージ機能も実行するので、このアーキテクチャは、少なくとも１つの処理ノードにデータを格納することを要求する。従って、シェアド・ナッシング・アーキテクチャは、すべての処理ノードが取除かれると、データを格納することが出来ない。更に、シェアド・ナッシング・アーキテクチャにおけるデータの管理は、多くの異なる処理ノードに渡るデータの分散により、複雑である。

【0005】

ここに記述されるシステム及び方法は、既存のシステムの上記制限を軽減する、データストレージ及びデータ検索への改善されたアプローチを提供する。

【発明の概要】

【0006】

本発明の一態様に係るシステムは、データベースデータを纏めて格納する複数のリモートストレージデバイスと、前記複数のリモートストレージデバイスにアクセスする実行プラットフォームであって、前記実行プラットフォームは複数の仮想ウェアハウスを含み、前記複数の仮想ウェアハウスの各々は、前記複数のリモートストレージデバイスのうちの任意のリモートストレージデバイスからデータを取得し、かつ、前記複数のリモートストレージデバイスのうちの任意のリモートストレージデバイスにデータを格納し、前記複数の仮想ウェアハウスの各々は、１つ以上のクライアント装置から前記データベースデータに向けられたデータ処理要求を実行するための複数の実行ノードを含み、前記複数の実行ノードの各々が、前記複数のリモートストレージデバイスのうちの１つ以上から取得されたデータを格納するように構成されたキャッシュと、前記複数のリモートストレージデバイスから独立して動作するプロセッサとを含む、実行プラットフォームと、前記１つ以上のクライアント装置と前記実行プラットフォームとの間に結合されたリソースマネージャと、を備えたシステムであって、前記リソースマネージャは、前記１つ以上のクライアント装置から受信された各データ処理要求に対して、該データ処理要求を処理するのに必要な複数のタスクを決定し、該複数のタスクを前記仮想ウェアハウスの前記複数の実行ノードに分配することと、以前に受信したデータ処理要求に基づき、未来の予測されるデータ処理要求を決定することと、前記１つ以上のクライアント装置から受信された前記データ処理要求を監視することであって、該受信されたデータ処理要求は、現在継続中のデータ処理要求である、ことと、前記複数の仮想ウェアハウスの各々の現在のリソース利用率を監視することであって、前記仮想ウェアハウスの前記現在のリソース利用率は、前記仮想ウェアハウス内の１つ以上の実行ノードのキャッシュ利用率及びプロセッサ利用率を含む、ことと、前記１つ以上のクライアント装置から受信された前記データ処理要求と前記予測されるデータ処理要求とを実行するための十分な利用可能なリソースを前記複数の仮想ウェアハウスが有しているか否かを、前記複数の仮想ウェアハウスの各々における前記現在のリソース利用率に基づいて判定することにより、追加の仮想ウェアハウスが必要か否かを判定することと、追加の仮想ウェアハウスが必要であるという判定に応じて、前記複数のリモートストレージデバイスにおけるストレージの量を増加させずに、新規の仮想ウェアハウスを提供することと、を行う。

【図面の簡単な説明】

【0007】

本開示の非限定的且つ非網羅的実施形態が、以下の図面を参照して記述され、図面においては、同様な参照番号は、特に断られない限り、様々な図面に渡って、同様な部分を指す。

【0008】

【図1】ここに記述するシステム及び方法の例示的実施形態を図示するブロック図である。

【図2】リソースマネージャの実施形態を図示するブロック図である。

【図3】実行プラットフォームの実施形態を図示するブロック図である。

【図4】複数の仮想ウェアハウスを介して、複数のデータベースにアクセスする複数のユーザを有する例示的な動作環境を図示するブロック図である。

【図5】負荷バランサと、仮想ウェアハウスグループに含まれる複数の仮想ウェアハウスを介して、複数のデータベースにアクセスする複数のユーザを有する他の例示的な動作環境を図示するブロック図である。

【図6】複数の分散仮想ウェアハウスと仮想ウェアハウスグループを有する他の例示的な動作環境を図示するブロック図である。

【図7】データストレージと検索動作を管理するための方法の実施形態を図示するフロー図である。

【図8】新規の仮想ウェアハウスを提供するための方法の実施形態を図示するフロー図である。

【図9A】リソースをスケーリングするための方法の実施形態のフロー図を図示する。

【図9B】リソースをスケーリングするための方法の実施形態のフロー図を図示する。

【図10】リソースをスケーリングするための他の方法の実施形態を図示するフロー図である。

【図11】例示的コンピューティングデバイスを図示するブロック図である。

【発明を実施するための形態】

【0009】

ここに記述されるシステム及び方法は、既存のシステムが直面する問題なしに、データを格納し且つ検索（取得）する新規のプラットフォームを提供する。例えば、この新規のプラットフォームは、シェアド・ナッシング・アーキテクチャによって要求されるデータファイルの再配置の必要なく、新規のノードを追加することをサポートする。更に、ノードは、共有ディスクシステムにおいて一般的なボトルネックを生成することなく、プラットフォームに追加されることが可能である。この新規のプラットフォームは、あるノードが、メンテナンスのためにオフラインであったり、または障害が発生している場合でも、データ読み取り及びデータ書き込み動作のために、常に利用可能である。記述されるプラットフォームは、データストレージリソースをコンピューティングリソースから分離し、専用コンピューティングリソースを使用することを要求することなく、データが格納されることができるようにする。これは、すべてのコンピューティングリソースが除去されるとき、データを格納することが出来ない、シェアド・ナッシング・アーキテクチャに対する改善である。従って、新規のプラットフォームは、コンピューティングリソースがもう利用できない、または、他のタスクを実行している場合であっても、データを格納し続ける。

【0010】

以下の記述においては、その一部をなす添付図面を参照し、それにおいては、例示として、開示を実施しうる特定の例示的実施形態を示す。これらの実施形態は、ここに開示の概念を当業者が実施することが出来るように、十分に詳細に記述され、本開示の範囲を逸脱することなく、様々な開示された実施形態への変更をすることができ、他の実施形態が利用可能であることを理解されたい。従って、以下の詳細な記述は、限定的な意味で解釈されるべきではない。

【0011】

この明細書に渡って、「一実施形態」、「一つの実施形態」、「一例」または「一つの例」への参照は、実施形態または例に関連して記述される特定のフィーチャ、構造、または、特性が、本開示の少なくとも１つの実施形態に含まれることを意味する。従って、この明細書に渡って、様々な場所における語句「一実施形態において」、「一つの実施形態において」、「一例」または「一つの例」の出現は、全てが、同一の実施形態または例を示す必要は必ずしもない。更に、ここに提供する図面は、当業者への説明目的のものであり、図面は、必ずしも同一の縮尺では描かれていないことを理解されたい。

【0012】

本開示による実施形態は、装置、方法、または、コンピュータプログラム製品として実体化されることが出来る。従って、本開示は、一般に、「回路」、「モジュール」または「システム」とここで呼ばれうる、全体的にハードウェアからなる実施形態、全体的にソフトウェアからなる実施形態（ファームウェア、常駐ソフトウェア、マイクロコード、などを含む）または、ソフトウェアとハードウェアの態様を組み合わせた実施形態の形態を取ることが出来る。更に、本開示の実施形態は、媒体に実体化されたコンピュータ利用可能なプログラムコードを有する表現の任意の有形な媒体に実体化されたコンピュータプログラム製品の形態を取ることが出来る。

【0013】

１以上のコンピュータ利用可能、または、コンピュータ可読媒体の任意の組み合わせが利用されることが出来る。例えば、コンピュータ可読媒体は、ポータブルコンピュータディスケット、ハードディスク、ランダムアクセスメモリ（ＲＡＭ）デバイス、リードオンリーメモリ（ＲＯＭ）デバイス、消去可能プログラマブルリードオンリーメモリ（ＥＰＲＯＭまたはフラッシュメモリ）デバイス、ポータブルコンパクトディスクリードオンリーメモリ（ＣＤＲＯＭ）、光ストレージデバイス、及び、磁気ストレージデバイスの１以上を含むことが出来る。本開示の動作を実行するためのコンピュータプログラムコードは、１以上のプログラミング言語の任意の組み合わせで書かれることが出来る。そのようなコードは、ソースコードからコンピュータ可読アセンブリ言語、または、コードが実行されるデバイスもしくはコンピュータに適した機械コードに、コンパイルされることが出来る。

【0014】

実施形態は、また、クラウドコンピューティング環境に実装されることも出来る。この記述及び以下の請求項においては、「クラウドコンピューティング」は、高速に、仮想化によって提供可能で、最小の管理努力、または、サービスプロバイダ相互作用でリリースされることが出来、その後、それに従ってスケーリングされることが出来る、構成可能なコンピューティングリソース（例えば、ネットワーク、サーバ、ストレージ、アプリケーション、及びサービス）の共有プールに対する、ユビキタスで、便利で、オンデマンドなネットワークアクセスを可能にするモデルとして規定されることが出来る。クラウドモデルは、様々な特性（例えば、オンデマンドセルフサービス、広範なネットワークアクセス、リソースプーリング、迅速な柔軟性（ｒａｐｉｄ ｅｌａｓｔｉｃｉｔｙ）、及び、メジャードサービス（ｍｅａｓｕｒｅｄ ｓｅｒｖｉｃｅ））、サービスモデル（例えば、ソフトウェア・アズ・ア・サービス（“ＳａａＳ”）、プラットフォーム・アズ・ア・サービス（“ＰａａＳ”）、及び、インフラストラクチャ・アズ・ア・サービス（“ＩａａＳ”））、及び、展開モデル（例えば、プライベートクラウド、コミュニティクラウド、公衆クラウド、及び、ハイブリッドクラウド）からなることが出来る。

【0015】

添付の図面のフロー図、及び、ブロック図は、本開示の様々な実施形態による、システム、方法、及び、コンピュータプログラム製品の可能な実装のアーキテクチャ、機能、及び、動作を図示する。この点、フロー図またはブロック図における各ブロックは、特定の（複数の）論理機能を実装するための１以上の実行可能な命令を含む、モジュール、セグメント、または、コードの一部を表し得る。ブロック図及び／または、フロー図の各ブロック、ならびに、ブロック図及び／またはフロー図におけるブロックの組み合わせは、特定の機能もしくは作用を実行する専用ハードウェアベースのシステム、または、専用ハードウェア及びコンピュータ命令の組み合わせによって実装されることが出来ることも注意されたい。これらのコンピュータプログラム命令は、また、コンピュータまたは、他のプログラマブルデータ処理装置を特定の方法で機能させるコンピュータ可読媒体に格納されることも出来、コンピュータ可読媒体に格納される命令は、フロー図及び／または、ブロック図の１つまたは複数のブロックにおいて指定される機能／作用を実装する命令手段を含む製造製品を生成するようにする。

【0016】

ここに記述されるシステム及び方法は、新規のデータ処理プラットフォームを用いたフレキシブル且つスケーラブルなデータウェアハウスを提供する。幾つかの実施形態においては、記述されたシステム及び方法は、クラウドベースのストレージリソース、コンピューティングリソースなどをサポートするクラウドインフラストラクチャを利用する。例示的なクラウドベースのストレージリソースは、低コストで、オンデマンドで利用可能な大きなストレージ容量を提供する。更に、これらのクラウドベースのストレージリソースは、フォールトトレラントであり、高度にスケーラブルであることが出来るが、これをプライベートなデータストレージシステムで達成するにはコストがかかる。例示的なクラウドベースのコンピューティングリソースは、オンデマンドで利用でき、リソースの実際の使用レベルに基づいて、価格設定することが出来る。典型的には、クラウドインフラストラクチャは、高速で、動的に、展開、再構成、及び、取り外しされる。

【0017】

記述したシステム及び方法においては、データストレージシステムは、ＳＱＬ（Ｓｔｒｕｃｔｕｒｅｄ Ｑｕｅｒｙ Ｌａｎｇｕａｇｅ）ベースのリレーショナルデータベースを利用する。しかし、これらのシステム及び方法は、データ格納・検索（取得）プラットフォーム内のデータを格納し且つ検索（取得）するために、任意のデータストレージアーキテクチャを用いて、及び、任意の言語を用いて、任意のタイプのデータベースならびに任意のタイプのデータ格納・検索プラットフォームに適用可能である。ここに記述されるシステム及び方法は、異なる顧客／クライアント間、及び、同一の顧客／クライアント内の異なるユーザ間のコンピューティングリソース及びデータの隔離をサポートするマルチテナントシステムを更に提供する。

【0018】

図１は、新規のデータ処理プラットフォーム１００の例示的実施形態を図示するブロック図である。図１に示されるように、リソースマネージャ１０２は、複数のユーザ１０４、１０６、及び１０８に結合される。特定の実装においては、リソースマネージャ１０２は、データ処理プラットフォーム１００にアクセスを望む任意の数のユーザをサポートすることが出来る。ユーザ１０４～１０８は、例えば、データ格納・検索要求を提供するエンドユーザと、ここで記述するシステム及び方法、リソースマネージャ１０２と相互作用する他のコンポーネント／デバイスを管理するシステム管理者と、を含むことが出来る。リソースマネージャ１０２は、データ処理プラットフォーム１００内のすべてのシステム及びコンポーネントの動作をサポートする様々なサービス及び機能を提供する。ここに用いられるように、リソースマネージャ１０２は、また、ここに記述する様々な機能を実行する「グローバルサービスシステム」と呼ばれることもある。

【0019】

リソースマネージャ１０２は、また、データ処理プラットフォーム１００に渡って格納されるデータ全体に関連づけられた、メタデータ１１０に結合される。幾つかの実施形態においては、メタデータ１１０は、ローカルキャッシュから得られるデータと共に、リモートデータストレージシステムに格納されたデータの概要を含む。更に、メタデータ１１０は、データがどのようにリモートデータストレージシステムとローカルキャッシュ内で組織化されるかについての情報を含むことが出来る。メタデータ１１０により、システム及びサービスは、ストレージデバイスから実際のデータをロードする、または、実際のデータにアクセスすることなく、データの一部がアクセスされる必要があるか否かを判定することが出来る。

【0020】

リソースマネージャ１０２は、以下に詳しく議論するように、様々なデータストレージ及びデータ検索タスクを実行する複数のコンピューティングリソースを提供する、実行プラットフォーム１１２に更に結合される。実行プラットフォーム１１２は、ストレージプラットフォーム１１４の一部である、複数のデータストレージデバイス１１６、１１８、１２０に結合される。３つのデータストレージデバイス１１６、１１８、及び１２０が、図１に示されているが、実行プラットフォーム１１２は、任意の数のデータストレージデバイスと通信することが出来る。幾つかの実施形態においては、データストレージデバイス１１６、１１８、及び１２０は、１以上の地理的場所に配置されたクラウドベースのストレージデバイスである。例えば、データストレージデバイス１１６、１１８、及び１２０は、公衆クラウドインフラストラクチャまたはプライベートクラウドインフラストラクチャの一部とすることが出来る。データストレージデバイス１１６、１１８、及び１２０は、ハードディスクドライブ（ＨＤＤ）、固体ドライブ（ＳＳＤ）、ストレージクラスタ、Ａｍａｚｏｎ Ｓ３（商標）ストレージシステム、または、任意の他のデータストレージ技術とすることが出来る。更に、ストレージプラットフォーム１１４は、分散ファイルシステム（Ｈａｄｏｏｐ Ｄｉｓｔｒｉｂｕｔｅｄ Ｆｉｌｅ Ｓｙｓｔｅｍｓ（ＨＤＦＳ）など）、オブジェクトストレージシステムなどを含むことが出来る。

【0021】

特定の実施形態においては、リソースマネージャ１０２と、ユーザ１０４～１０８、メタデータ１１０、及び実行プラットフォーム１１２との間の通信リンクは、１以上のデータ通信ネットワークを介して、実装される。同様に、実行プラットフォーム１１２とストレージプラットフォーム１１４内のデータストレージデバイス１１６～１２０との間の通信リンクは、１以上のデータ通信ネットワークを介して、実装される。これらのデータ通信ネットワークは、任意の通信プロトコル及び、任意のタイプの通信媒体を利用することが出来る。幾つかの実施形態においては、データ通信ネットワークは、相互に結合する、２以上のデータ通信ネットワーク（または、サブネットワーク）の組み合わせである。別の実施形態においては、これらの通信リンクは、任意のタイプの通信媒体及び任意の通信プロトコルを用いて実装される。

【0022】

図１に示されるように、データストレージデバイス１１６、１１８、及び１２０は、実行プラットフォーム１１２に関連したコンピューティングリソースから分離される。このアーキテクチャは、データ処理プラットフォーム１００にアクセスするユーザ及びシステムのニーズの変化と共に、変化するデータストレージ／検索ニーズに基づいて、データ処理プラットフォーム１００への動的な変更をサポートする。動的な変更のサポートにより、データ処理プラットフォーム１００は、データ処理プラットフォーム１００内のシステムとコンポーネントに対する要求の変化に応じて、迅速にスケーリングすることが出来る
。コンピューティングリソースのデータストレージデバイスからの分離は、対応する大容量のコンピューティングリソースを要求することなく、大容量のデータの格納をサポートする。同様に、リソースのこの分離は、利用可能なデータストレージリソースにおける対応する増加を要求することなく、特定の時間において利用されるコンピューティングリソースにおける非常に多くの増加をサポートする。

【0023】

リソースマネージャ１０２、メタデータ１１０、実行プラットフォーム１１２、及びストレージプラットフォーム１１４は、図１において、個別のコンポーネントとして図示されている。しかし、リソースマネージャ１０２、メタデータ１１０、実行プラットフォーム１１２、及びストレージプラットフォーム１１４のぞれぞれは、分散システムとして（例えば、複数の地理的場所における複数のシステム／プラットフォームに渡って分散される、など）、実装されることが出来る。更に、リソースマネージャ１０２、メタデータ１１０、実行プラットフォーム１１２、及びストレージプラットフォーム１１４のそれぞれは、ユーザ１０４～１０８から受信する要求に対する変更及びデータ処理プラットフォーム１００のニーズの変化に依存して、（相互に独立に）スケールアップまたはスケールダウンされることが出来る。従って、記述された実施形態においては、データ処理プラットフォーム１００は、動的で、現在のデータ処理ニーズに合致するように、定期的変更をサポートする。

【0024】

典型的な動作の間、データ処理プラットフォーム１００は、任意のユーザ１０４～１０８から受信される複数のクエリ（または要求）を処理する。これらのクエリは、いつ、及び、どのように、これらのクエリを実行するかを決定するために、リソースマネージャ１０２によって管理される。例えば、リソースマネージャ１０２は、どのデータが、クエリを処理するために必要とされるかを判定し、実行プラットフォーム１１２内のどのノードが、クエリを処理するのにもっとも向いているかを更に判定することが出来る。幾つかのノードは、クエリを処理するのに必要なデータを既にキャッシュに持っていることが出来、従って、そのクエリを処理するための良い候補となる。メタデータ１１０は、実行プラットフォーム１１２内のどのノードが、クエリを処理するのに必要なデータの少なくとも一部を既にキャッシュに持っているかを判定するうえで、リソースマネージャ１０２を支援する。実行プラットフォーム１１２内の１以上のノードは、ノードによってキャッシュされたデータ、必要に応じて、ストレージプラットフォーム１１４から検索（取得）されたデータを用いて、クエリを処理する。検索速度は、典型的には、ストレージプラットフォーム１１４からデータを検索することよりもずっと速いので、実行プラットフォーム１１２内のキャッシュから、できるだけ多くのデータを検索することが望ましい。

【0025】

図１に示されるように、データ処理プラットフォーム１００は、ストレージプラットフォーム１１４から実行プラットフォーム１１２を分離する。この配置においては、実行プラットフォーム１１２内の処理リソースとキャッシュリソースは、ストレージプラットフォーム１１４内のデータストレージリソース１１６～１２０から独立して動作する。従って、コンピューティングリソースとキャッシュリソースは、特定のデータストレージリソース１１６～１２０には限定されない。むしろ、すべてのコンピューティングリソースとすべてのキャッシュリソースは、ストレージプラットフォーム１１４内のデータストレージリソースのうちの任意のデータストレージリソースからデータを検索し、これらへデータを格納することが出来る。更に、データ処理プラットフォーム１００は、ストレージプラットフォーム１１４へいかなる変更も要求しないで、実行プラットフォーム１１２への新規のコンピューティングリソースとキャッシュリソースの追加をサポートする。同様に、データ処理プラットフォーム１００は、実行プラットフォーム１１２内のノードにいかなる変更も要求することなく、ストレージプラットフォーム１１４へのデータストレージリソースの追加をサポートする。

【0026】

図２は、リソースマネージャ１０２の実施形態を図示するブロック図である。図２に示されるように、リソースマネージャ１０２は、データストレージデバイス２０６に結合した、アクセスマネージャ２０２と、キーマネージャ２０４とを含む。アクセスマネージャ２０２は、ここに記述するシステムに対する認証と、承認タスクを扱う。キーマネージャ２０４は、認証と承認タスクの間に用いられる、キーの格納と認証を管理する。例えば、アクセスマネージャ２０２とキーマネージャ２０４は、リモートストレージデバイス（例えば、ストレージプラットフォーム１１４内のデータストレージデバイス）内に格納されたデータにアクセスするために用いられるキーを管理する。ここに用いられるように、リモートストレージデバイスは、また、「永続的ストレージデバイス（ｐｅｒｓｉｓｔｅｎｔ ｓｔｏｒａｇｅ ｄｅｖｉｃｅ）」とも呼ばれる。要求処理サービス２０８は、受信されたデータストレージ要求と、データ検索要求（例えば、データベースクエリ）とを管理する。例えば、要求処理サービス２０８は、受信されたデータストレージ要求またはデータ検索要求を処理するのに必要なデータを決定することが出来る。必要なデータは、（以下に詳細に議論するように）実行プラットフォーム１１２内のキャッシュ、または、ストレージプラットフォーム１１４内のデータストレージデバイス内に格納されることが出来る。管理コンソールサービス２１０は、管理者及び他のシステム管理者による、様々なシステム及びプロセスへのアクセスをサポートする。更に、管理コンソールサービス２１０は、クエリを発行するために、ユーザ１０４～１０８から要求を受信し、システムの作業負荷を監視することが出来る。幾つかの実施形態においては、特定のユーザは、彼等の特定のクエリがシステムに課す作業負荷を監視する要求を発行することが出来る。

【0027】

リソースマネージャ１０２は、また、ＳＱＬコンパイラ２１２、ＳＱＬオプティマイザ２１４、及びＳＱＬエグゼキュータ２１０を含む。ＳＱＬコンパイラ２１２は、ＳＱＬクエリを解析し、そのクエリのための実行コードを生成する。ＳＱＬオプティマイザ２１４は、処理される必要のあるデータに基づいて、クエリを実行するための最良の方法を決定する。ＳＱＬオプティマイザ２１４は、また、ＳＱＬクエリを実行する速度と効率を改善するため、様々なデータプルーニングオペレーションと他のデータ最適化技術を扱う。ＳＱＬエグゼキュータ２１６は、リソースマネージャ１０２によって受信されるクエリ用のクエリコードを実行する。

【0028】

クエリスケジューラ及びコーディネータ２１８は、コンパイル、最適化及び、実行プラットフォーム１１２へのディスパッチのために、適切なサービスまたはシステムに受信したクエリを送信する。例えば、クエリは、優先順位がつけられ、その優先順位で処理されることが出来る。幾つかの実施形態においては、クエリスケジューラ及びコーディネータ２１８は、実行プラットフォーム１１２内の特定のノードを、特定のクエリを処理するために、同定し、または、割り当てる。仮想ウェアハウスマネージャ２２０は、実行プラットフォーム１１２に実装される複数の仮想ウェアハウスの動作を管理する。以下に議論されるように、各仮想ウェアハウスは、キャッシュとプロセッサとをそれぞれ含む、複数の実行ノードを含む。

【0029】

更に、リソースマネージャ１０２は、リモートデータストレージデバイスとローカルキャッシュ（つまり、実行プラットフォーム１１２内のキャッシュ）に格納されているデータに関連した情報を管理する、構成及びメタデータマネージャ２２２を含む。以下に詳しく議論するように、構成及びメタデータマネージャ２２２は、特定のクエリを処理するためのデータを検索（取得）するために、どのデータファイルにアクセスが必要かを判定するために、メタデータを用いる。監視及び作業負荷アナライザ２２４は、リソースマネージャ１０２によって実行されるプロセスを監督し、仮想ウェアハウスと、実行プラットフォーム１１２内の実行ノードとに渡って、タスク（例えば、作業負荷）の分配を監視する。監視及び作業負荷アナライザ２２４は、また、データ処理プラットフォーム１００に渡る作業負荷の変化に基づいて、必要に応じて、タスクを再分配する。構成及びメタデータマネージャ２２２と、監視及び作業負荷アナライザ２２４は、データストレージデバイス２２６に結合される。図２のデータストレージデバイス２０６と２２６は、データ処理プラットフォーム１００内の任意のデータストレージデバイスを表す。例えば、データストレージデバイス２０６と２２６は、実行プラットフォーム１１２内のキャッシュ、ストレージプラットフォーム１１４内のストレージデバイス、または、任意の他のストレージデバイスを表すことが出来る。

【0030】

リソースマネージャ１０２は、また、データストレージ要求とデータアクセス要求の処理に関連した様々なタスクと他の活動を管理する、トランザクション管理及びアクセス制御モジュール２２８を含む。例えば、トランザクション管理及びアクセス制御モジュール２２８は、複数のユーザまたはシステムによる、データに対して整合性のある、同期されたアクセスを提供する。複数のユーザ／システムは、同一のデータに同時にアクセスすることができるので、各ユーザ／システムが、データの現在のバージョンで作業することを確保するために、データへの変更は同期されなくてはならない。トランザクション管理及びアクセス制御モジュール２２８は、リソースマネージャ１０２内の単一の、中心的場所において、様々なデータ処理活動の制御を提供する。幾つかの実施形態においては、トランザクション管理及びアクセス制御モジュール２２８は、ＳＱＬエグゼキュータ２１６によって実行される様々なタスクの管理をサポートするために、ＳＱＬエグゼキュータ２１６と相互作用する。

【0031】

図３は、実行プラットフォーム１１２の実施形態を示すブロック図である。図３に示されるように、実行プラットフォーム１１２は、複数の仮想ウェアハウス３０２、３０４、及び３０６を含む。各仮想ウェアハウスは、データキャッシュとプロセッサとを各々含む、複数の実行ノードを含む。仮想ウェアハウス３０２、３０４、及び３０６は、複数の実行ノードを用いることにより、並列に、複数のクエリ（及び他のタスク）を実行することが出来る。ここに議論するように、実行プラットフォーム１１２は、システムとユーザの現在の処理ニーズに基づいて、リアルタイムで、新規の仮想ウェアハウスを追加したり、既存の仮想ウェアハウスを取り外したりすることが出来る。この柔軟性により、実行プラットフォーム１１２は、必要なくなったとき、それらのコンピューティングリソースに支払いを続けることを強いられることなく、必要なときに、大容量のコンピューティングリソースを、迅速に展開することが出来る。すべての仮想ウェアハウスは、任意のデータストレージデバイス（例えば、ストレージプラットフォーム１１４内の任意のストレージデバイス）からデータにアクセスすることが出来る。

【0032】

図３に示される各仮想ウェアハウス３０２～３０６は、３つの実行ノードを含んでいるが、特定の仮想ウェアハウスは、任意の数の実行ノードを含むことが出来る。更に、仮想ウェアハウス内の実行ノードの数は、動的で、追加の要求がある場合には、新規の実行ノードが生成され、必要なくなったときには、既存の実行ノードが削除されるようにする。

【0033】

各仮想ウェアハウス３０２～３０６は、図１に示される任意のデータストレージデバイス１１６～１２０にアクセスすることが出来る。従って、仮想ウェアハウス３０２～３０６は、特定のデータストレージデバイス１１６～１２０に必ずしも割り当てられる必要は無く、むしろ、任意のデータストレージデバイス１１６～１２０からデータにアクセス可能である。同様に、図３に示される実行ノードのそれぞれは、任意のデータストレージデバイス１１６～１２０からデータにアクセスすることが出来る。幾つかの実施形態においては、特定の仮想ウェアハウスまたは、特定の実行ノードは、特定のデータストレージデバイスに、一時的に割り当てられることが出来るが、仮想ウェアハウスまたは、実行ノードは、後に、任意の他のデータストレージデバイスからデータにアクセスすることが出来る。

【0034】

図３の例においては、仮想ウェアハウス３０２は、３つの実行ノード３０８、３１０、及び３１２を含む。実行ノード３０８は、キャッシュ３１４とプロセッサ３１６とを含む。実行ノード３１０は、キャッシュ３１８とプロセッサ３２０とを含む。実行ノード３１２は、キャッシュ３２２とプロセッサ３２４とを含む。各実行ノード３０８～３１２は、１以上のデータストレージ及び／またはデータ検索タスクを処理することに関連する。例えば、特定の仮想ウェアハウスは、特定のユーザまたは顧客に関連したデータストレージ及びデータ検索タスクを扱うことが出来る。他の実装においては、特定の仮想ウェアハウスは、特定のデータストレージシステムまたはデータの特定のカテゴリに関連した、データストレージ及びデータ検索タスクを扱うことが出来る。

【0035】

上記した仮想ウェアハウス３０２と同様に、仮想ウェアハウス３０４は、３つの実行ノード３２６、３２８、及び３３０を含む。実行ノード３２６は、キャッシュ３３２とプロセッサ３３４とを含む。実行ノード３２８は、キャッシュ３３６とプロセッサ３３８とを含む。実行ノード３３０は、キャッシュ３４０とプロセッサ３４２とを含む。更に、仮想ウェアハウス３０６は、３つの実行ノード３４４、３４６、及び３４８を含む。実行ノード３４４は、キャッシュ３５０とプロセッサ３５２とを含む。実行ノード３４６は、キャッシュ３５４とプロセッサ３５６とを含む。実行ノード３４８は、キャッシュ３５８とプロセッサ３６０とを含む。

【0036】

幾つかの実施形態においては、図３に示される実行ノードは、実行ノードがキャッシュしているデータについて、ステートレスである。例えば、これらの実行ノードは、実行ノードについての状態情報、または、特定の状態ノードによってキャッシュされているデータについての状態情報を格納しないか、さもなくば、これらを保持しない。従って、実行ノードエラーの場合、エラーが出たノードは、透過的（トランスペアレント）に、他のノードに置き換えられることが出来る。エラーが出た実行ノードに関連した状態情報が無いので、新規の（置き換えの）実行ノードは、特定の状態を再生成するという懸念なしに、エラーが出たノードを容易に置き換えることが出来る。

【0037】

図３に示される実行ノードは、１つのデータキャッシュと１つのプロセッサとを各々含むが、別の実施形態は、任意の数のプロセッサと任意の数のキャッシュとを含む実行ノードを含むことが出来る。更に、キャッシュは、異なる実行ノードの間で、サイズが変化してもよい。図３に示されるキャッシュは、ストレージプラットフォーム１１４（図１）内の１以上のデータストレージデバイスから検索されたデータをローカル実行ノードに格納する。従って、キャッシュは、リモートストレージシステムから、一貫してデータを検索するプラットフォームに発生するボトルネック問題を軽減、または、排除する。リモートストレージデバイスからデータに繰り返しアクセスするのではなく、ここに記述するシステム及び方法は、かなり高速な実行ノード内のキャッシュからデータにアクセスし、上記したボトルネック問題を避回避する。幾つかの実施形態においては、キャッシュは、キャッシュされたデータへの高速のアクセスを提供する高速メモリデバイスを用いて実装される。各キャッシュは、ストレージプラットフォーム１１４内の任意のストレージデバイスからのデータを格納することが出来る。

【0038】

更に、キャッシュリソース及びコンピューティングリソースは、異なる実行ノード間で異なることがある。例えば、１つの実行ノードは、多くのコンピューティングリソースと最小のキャッシュリソースとを含んでもよく、その実行ノードを、多くのコンピューティングリソースを要求するタスクに有用とすることが出来る。他の実行ノードは、多くのキャッシュリソースと最小のコンピューティングリソースとを含んでもよく、この実行ノードを、大容量のデータのキャッシングを要求するタスクに有用とすることが出来る。更に他の実行ノードは、高速な入力－出力動作を提供するキャッシュリソースを含んでもよく、大容量のデータの高速なスキャンを要求するタスクに有用とすることが出来る。幾つかの実施形態においては、特定の実行ノードに関連したキャッシュリソースとコンピューティングリソースは、その実行ノードによって実行されるべき予測タスクに基づいて、実行ノードが生成されたときに決定される。

【0039】

更に、特定の実行ノードに関連したキャッシュリソースとコンピューティングリソースは、その実行ノードによって実行されるタスクの変化に基づいて、時間経過と共に変化することが出来る。例えば、実行ノードによって実行されるタスクが、プロセッサをより多く使用するようになるとき、特定の実行ノードはより多くの処理リソースを割り当てられることが出来る。同様に、実行ノードによって実行されるタスクが、より多くのキャッシュ容量を要求するとき、その実行ノードは、より多くのキャッシュリソースを割り当てられることが出来る。

【0040】

仮想ウェアハウス３０２～３０６は、同一の実行プラットフォーム１１２に関連付けられるが、仮想ウェアハウスは、複数の地理的場所における複数のコンピューティングシステムを用いて、実装されることが出来る。例えば、仮想ウェアハウス３０２は、第１の地理的場所において、コンピューティングシステムによって実装されることができ、一方、仮想ウェアハウス３０４と３０６は、第２の地理的場所において、他のコンピューティングシステムによって実装される。幾つかの実施形態においては、これらの異なるコンピューティングシステムは、１以上の異なる実体（エンティティ）によって維持されるクラウドベースのコンピューティングシステムである。

【0041】

更に、各仮想ウェアハウスは、複数の実行ノードを有しているものとして、図３に示されている。各仮想ウェアハウスに関連した複数の実行ノードは、複数の地理的場所において、複数のコンピューティングシステムを用いて実装されることが出来る。例えば、仮想ウェアハウス３０２の具体的な例は、特定の地理的場所における一つのコンピューティングプラットフォーム上に、実行ノード３０８と３１０を実装し、他の地理的場所における異なるコンピューティングプラットフォームにおいて、実行ノード３１２を実装する。実行ノードを実装すべき特定のコンピューティングシステムを選択することは、特定の実行ノードに必要とされるリソースのレベル（例えば、処理リソース要件とキャッシュ要件）、特定のコンピューティングシステムに利用可能なリソース、地理的場所内、または、地理的場所間でのネットワークの通信性能、どのコンピューティングシステムが、仮想ウェアハウス内で、他の実行ノードを既に実装しているか、などの様々な要因に依存することがある。

【0042】

実行プラットフォーム１１２は、また、フォールトトレラントである。例えば、一つの仮想ウェアハウスでエラーが発生すると、その仮想ウェアハウスは、異なる地理的場所における異なる仮想ウェアハウスに迅速に置き換えられる。

【0043】

特定の実行プラットフォーム１１２は、任意の数の仮想ウェアハウス３０２～３０６を含むことが出来る。更に、特定の実行プラットフォームにおける仮想ウェアハウスの数は、動的で、追加的処理及び／またはキャッシングリソースが必要となったとき、新規の仮想ウェアハウスが生成されるようにする。同様に、仮想ウェアハウスに関連したリソースがもはや必要ないとき、既存の仮想ウェアハウスは削除されることが出来る。

【0044】

幾つかの実施形態においては、仮想ウェアハウス３０２、３０４、及び３０６は、ストレージプラットフォーム１１４内の同一のデータに操作を加えることが出来るが、各仮想ウェアハウスは、独立した処理及びキャッシングリソースを有する、それ自体の実行ノードを有する。この構成により、異なる仮想ウェアハウスへの要求が、独立して、且つ、要求間での干渉なしに処理されることを可能とする。この独立した処理は、仮想ウェアハウスを動的に追加、削除する機能と組み合わせて、既存のユーザによって観察される性能に影響を与えることなく、新規のユーザ用の新規の処理能力の追加をサポートする。

【0045】

図４は、複数の仮想ウェアハウスを介して複数のデータベースにアクセスする複数のユーザを有する例示的な動作環境４００を図示するブロック図である。環境４００において、複数のユーザ４０２、４０４、及び４０６は、複数の仮想ウェアハウス４０８、４１０、及び４１２を介して、複数のデータベース４１４、４１６、４１８、４２０、４２２、及び４２４にアクセスする。図４には図示されていないが、ユーザ４０２、４０４、及び４０６は、リソースマネージャ１０２（図１）を介して、仮想ウェアハウス４０８、４１０、及び４１２にアクセスすることが出来る。特定の実施形態においては、データベース４１４～４２４は、ストレージプラットフォーム１１４（図１）に含まれ、実行プラットフォーム１１２内に実装される任意の仮想ウェアハウスによってアクセス可能である。幾つかの実施形態においては、ユーザ４０２～４０６は、インターネットなどのデータ通信ネットワークを用いて、仮想ウェアハウス４０８～４１２のうちの一つにアクセスする。幾つかの実装においては、各ユーザ４０２～４０６は、特定の時間に作業をするため、特定の仮想ウェアハウス４０８～４１２を同定する。図４の例においては、ユーザ４０２は、仮想ウェアハウス４０８と相互作用し、ユーザ４０４は、仮想ウェアハウス４１０と相互作用し、及び、ユーザ４０６は、仮想ウェアハウス４１２と相互作用する。従って、ユーザ４０２は、仮想ウェアハウス４０８を介して、データ検索及びデータストレージ要求を提出する。同様に、ユーザ４０４と４０６は、それぞれ、仮想ウェアハウス４１０と４１２を介して、データ検索及びデータストレージ要求を提出する。

【0046】

各仮想ウェアハウス４０８～４１２は、すべてのデータベース４１４～４２４の部分集合と通信するように構成される。例えば、環境４００において、仮想ウェアハウス４０８は、データベース４１４、４１６、及び４２２と通信するように構成される。同様に、仮想ウェアハウス４１０は、データベース４１６、４１８、４２０、及び４２４と通信するように構成される。そして、仮想ウェアハウス４１２は、データベース４１６、４２２、及び４２４と通信するように構成される。別の実施形態においては、仮想ウェアハウス４０８～４１２のうちの１以上は、データベース４１４～４２４のすべてと通信する。図４に示される配置により、個別のユーザは、単一の仮想ウェアハウスを介して、すべてのデータ検索及びデータストレージ要求を送信することが出来る。その仮想ウェアハウスは、仮想ウェアハウス内の実行ノードのうちの一つ内にキャッシュされたデータを用いて、データ検索及びデータストレージタスクを処理し、または、適切なデータベースから必要なデータを検索（及びキャッシュ）する。仮想ウェアハウス間のマッピングは、論理マッピングであり、ハードウェアマッピングではない。この論理マッピングは、セキュリティとリソースアクセス管理設定に関連したアクセス制御パラメータに基づく。論理マッピングは、仮想ウェアハウスまたはストレージリソースの再構築を要求することなく、容易に変更される。

【0047】

環境４００は、データベース４１４～４２４の特定の部分集合と通信するように構成された仮想ウェアハウス４０８～４１２を示すが、その構成は動的である。例えば、仮想ウェアハウス４０８は、仮想ウェアハウス４０８によって実行されるべきタスクの変化に基づいて、データベース４１４～４２４の異なる部分集合と通信するように再構成されることが出来る。例えば、仮想ウェアハウス４０８が、データ４１８から、データにアクセスする要求を受信したとすると、仮想ウェアハウス４０８は、データベース４１８とも通信するように再構成されることが出来る。後の時間になって、仮想ウェアハウス４０８が、データベース４１８からデータにアクセスする必要が無いときは、仮想ウェアハウス４０８は、データベース４１８との通信を削除するように再構成されることが出来る。

【0048】

図５は、負荷バランサと、仮想ウェアハウスグループに含まれる複数の仮想ウェアハウスを介して、複数のデータベースにアクセスする複数のユーザを有する、他の例示的な動作環境５００を図示するブロック図である。環境５００は、環境４００（図４）に似ているが、仮想ウェアハウスリソースマネージャ５０８と、仮想ウェアハウスグループ５１６に配置される複数の仮想ウェアハウス５１０、５１２、及び５１４を追加的に含む。仮想ウェアハウスリソースマネージャ５０８は、リソースマネージャ１０２に含まれることが出来る。特に、複数のユーザ５０２、５０４、及び５０６は、仮想ウェアハウスリソースマネージャ５０８と仮想ウェアハウスグループ５１６を介して、複数のデータベース５１８、５２０、５２２、５２４、５２６、及び５２８にアクセスする。幾つかの実施形態においては、ユーザ５０２～５０６は、インターネットなどのデータ通信ネットワークを用いて、仮想ウェアハウスリソースマネージャ５０８にアクセスする。図５に示されていないが、ユーザ５０２、５０４、及び５０６は、リソースマネージャ１０２（図１）を介して、仮想ウェアハウスリソースマネージャ５０８にアクセスすることが出来る。幾つかの実施形態においては、仮想ウェアハウスリソースマネージャ５０８は、リソースマネージャ１０２内に実装される。

【0049】

ユーザ５０２～５０６は、データ検索及びデータストレージ要求を仮想ウェアハウスグループ５１６内の適切な仮想ウェアハウス５１０～５１４にルーティングする仮想ウェアハウスリソースマネージャ５０８に、データ検索及びデータストレージ要求を提出することが出来る。幾つかの実装においては、仮想ウェアハウスリソースマネージャ５０８は、仮想ウェアハウス５１０～５１４への、ユーザ５０２～５０６の動的な割り当てを提供する。データ検索またはデータストレージ要求を提出するとき、ユーザ５０２～５０６は、その要求を処理するだろう特定の仮想ウェアハウス５１０～５１４を指定することなしに、その要求を処理すべき仮想ウェアハウスグループ５１６を指定することが出来る。この配置により、仮想ウェアハウスリソースマネージャ５０８は、効率、利用可能なリソース、及び、仮想ウェアハウス５１０～５１４内にキャッシュされたデータの利用可能性に基づいて、仮想ウェアハウス５１０～５１４に渡って、複数の要求を分配することが出来る。データ処理要求をどのようにルーティングするかを決定するときは、仮想ウェアハウスリソースマネージャ５０８は、利用可能なリソース、現在のリソース負荷、現在のユーザの数、などを考慮する。

【0050】

幾つかの実施形態においては、フォールトトレラントなシステムは、仮想ウェアハウスの障害に応じて、新規の仮想ウェアハウスを生成する。新規の仮想ウェアハウスは、同一の仮想ウェアハウスグループ内にあってもよいし、異なる地理的場所にある、異なる仮想ウェアハウスグループ内に生成されても良い。

【0051】

各仮想ウェアハウス５１０～５１４は、全てのデータベース５１８～５２８の部分集合と通信するように構成される。例えば、環境５００において、仮想ウェアハウス５１０は、データベース５１８、５２０、及び５２６と通信するように構成される。同様に、仮想ウェアハウス５１２は、データベース５２０、５２２、５２４、及び５２８と通信するように構成される。そして、仮想ウェアハウス５１４は、データベース５２０、５２６、及び５２８と通信するように構成される。別の実施形態においては、仮想ウェアハウス５１０～５１４は、データベース５１８～５２８のうちの任意の（または、全ての）データベースと通信することが出来る。

【0052】

環境５００は、１つの仮想ウェアハウスグループ５１６を示すが、別の実施形態は、それぞれが任意の数の仮想ウェアハウスに関連した、任意の数の仮想ウェアハウスグループを含むことが出来る。例えば、異なる仮想ウェアハウスは、各顧客用またはユーザのグループ用に生成されることが出来る。更に、異なる仮想ウェアハウスは、異なるエンティティ、または、異なるデータセットにアクセスする任意の他のグループ用に生成されることが出来る。複数の仮想ウェアハウスグループは、異なるサイズと構成を有することが出来る。特定の環境内の仮想ウェアハウスグループの数は、動的で、ユーザ及び、環境内の他のシステムのニーズの変化に基づいて、変化することが出来る。

【0053】

図６は、複数の分散仮想ウェアハウスと仮想ウェアハウスグループを有する他の例示的な動作環境６００を図示するブロック図である。環境６００は、データ通信ネットワーク６０２を介して、仮想ウェアハウスグループ６０４及び６０６と通信するリソースマネージャ１０２を含む。ウェアハウスグループ６０４は、２つの仮想ウェアハウス６０８と６１０とを含み、ウェアハウスグループ６０６は、他の２つの仮想ウェアハウス６１４と６１６とを含む。リソースマネージャ１０２は、また、データ通信ネットワーク６０２を介して、仮想ウェアハウス６１２（仮想ウェアハウスグループの一部ではない）とも通信する。

【0054】

仮想ウェアハウス６１２と共に、仮想ウェアハウスグループ６０４及び６０６は、データ通信ネットワーク６１８を介して、データベース６２０、６２２、及び６２４と通信する。幾つかの実施形態においては、データ通信ネットワーク６０２及び６１８は、同一のネットワークである。環境６００により、リソースマネージャ１０２は、データベース６２０～６２４内にデータを格納したり、データを検索したりするために、複数の仮想ウェアハウス６０８～６１６に渡って、ユーザデータ格納・検索要求を調整することが出来る。仮想ウェアハウスグループ６０４と６０６は、同一の地理的領域に位置することが出来、または、地理的に離れていることも出来る。更に、仮想ウェアハウスグループ６０４と６０６は、同一のエンティティ、または、異なるエンティティによって実装されることも出来る。

【0055】

ここに記述するシステム及び方法により、データは、コンピューティング（または、処理）リソースとは別箇なサービスとして、格納され、及び、アクセスされることが出来る。コンピューティングリソースが、実行プラットフォームから割り当てられていない場合にも、データは、リモートデータソースからのデータの再ロードを要求することなく、仮想ウェアハウスに利用可能である。従って、データに関連したコンピューティングリソースの割り当てとは関係なく、データが独立に利用可能である。記述されたシステム及び方法は、任意のタイプのデータに有用である。特定の実施形態においては、データは、構造化され、最適化されたフォーマットで格納される。コンピューティングサービスからのデータストレージ／アクセスサービスの分離は、また、異なるユーザ及びグループ間でのデータの共有を簡単化する。ここに議論されるように、各仮想ウェアハウスは、他の仮想ウェアハウスが同一のデータにアクセスしているのと同時であっても、アクセス許可を有している任意のデータにアクセス可能である。このアーキテクチャは、ローカルキャッシュに実際のデータが何も格納されていなくても、実行するクエリをサポートする。ここに記述されるシステム及び方法は、システムのユーザに対しトランスペアレントな方法で、必要に応じて、リモートストレージデバイスからローカルキャッシュへデータを移動するトランスペアレントで動的なデータ移動が可能である。更に、コンピューティングサービスからのデータストレージサービスの分離により、任意の仮想ウェアハウスが任意のデータにアクセスすることができるので、このアーキテクチャは、予めデータを移動することなくデータ共有をサポートする。

【0056】

図７は、データ格納・検索動作を管理するための方法７００の実施形態を図示するフロー図である。最初に、方法７００は、７０２において、ユーザから、ステートメント、要求またはクエリを受信する。ステートメントは、データ関連の動作を実行するための、任意の要求またはコマンドである。例示的なステートメントは、データ検索要求、データストレージ要求、データ転送要求、データクエリなどを含む。幾つかの実施形態においては、ステートメントは、ＳＱＬステートメントとして実装される。リソースマネージャは、受信したステートメントを管理するため、７０４において、クエリコーディネータを生成する。例えば、クエリコーディネータは、実行プラットフォーム及び１以上のデータストレージデバイスとの相互作用を含む、受信したステートメントを処理するために必要な様々なタスクを管理する。幾つかの実施形態においては、クエリコーディネータは、受信したステートメントを管理するために特別に生成された一時的なルーチンである。

【0057】

方法７００は、７０６において、受信したステートメントを処理するのに必要な複数のタスクをリソースマネージャが決定するのに従い、継続する。複数のタスクは、例えば、実行ノード内のキャッシュからのデータにアクセスすることと、リモートストレージデバイスからデータを検索することと、キャッシュ内のデータを更新することと、リモートストレージデバイスにデータを格納すること、などを含むことが出来る。リソースマネージャは、また、７０８において、実行プラットフォーム内の実行ノードに、複数のタスクを分配する。ここに議論するように、実行プラットフォーム内の実行ノードは、仮想ウェアハウス内に実装される。各実行ノードは、７１０において、割り当てられたタスクを実行し、リソースマネージャに、タスク結果を返送する。幾つかの実施形態においては、実行ノードは、タスク結果を、クエリコーディネータに返送する。リソースマネージャは、複数のタスク結果を受信し、７１２において、ステートメント結果を生成し、７１４において、ステートメント結果をユーザに通信する。幾つかの実施形態においては、ステートメント結果がユーザに通信された後、クエリコーディネータは消去される。

【0058】

図８は、新規の仮想ウェアハウスを提供するための方法８００の実施形態を図示するフロー図である。最初に、リソースマネージャ（例えば、リソースマネージャ１０２）は、８０２において、複数のユーザから受信されるデータ処理要求を監視する。ここに説明されるように、これらのデータ処理要求は、データ検索クエリ、データ読み取り要求、データ書き込み要求などを含むことが出来る。リソースマネージャは、また、８０４において、現在のリソース利用率、クエリ応答率、各仮想ウェアハウスと相互作用するユーザの数、及び、既存の仮想ウェアハウスの他の性能測度も監視する。現在のリソース利用率は、例えば、仮想ウェアハウス内の１以上の実行ノードにおける、キャッシュ利用率及びプロセッサ利用率を含む。現在のリソース利用率は、最大利用率のパーセント（例えば、キャッシュの４０％利用率と６０％のプロセッサ利用率）として、表現されることが出来る。クエリ応答率は、例えば、ユーザのクエリに応答するために必要な平均時間として表現されることが出来る。幾つかの実施形態においては、リソースマネージャは、また、現在実行中のクエリの数、最大負荷率、あるクエリの処理が遅延される必要があるか否かなども監視する。

【0059】

方法８００は、８０６において、リソースマネージャが、現在及び未来のリソースへのニーズを判定するに従い継続する。例えば、リソースマネージャは、近未来の予測される要求と共に、継続中のデータ処理要求を同定することが出来る。予測された要求は、特定の時間に特定のユーザから以前に受信されたデータ処理要求の以前のパターンに基づいて、決定されることが出来る。更に、リソースマネージャは、データ処理プロジェクトの進行通知を受信することができ、そのプロジェクトを扱うのに必要なリソースを決定することが出来る。リソースマネージャは、それから、８０８で、現在のデータ処理要求、現在のリソース利用率、クエリ応答率、及び、既存の仮想ウェアハウスに関連した他の性能測度に基づいて、１以上の追加の仮想ウェアハウスが必要か否かを判定する。追加の仮想ウェアハウスが必要な場合、リソースマネージャは、８１０において、新規の仮想ウェアハウスを提供する。例えば、現在利用可能なものより多いリソースを要求するだろう今度のデータ処理プロジェクトについてリソースマネージャが気づいているなら、リソースマネージャは、今度のデータ処理プロジェクトを扱うための１以上の新規の仮想ウェアハウスを提供することを決定することが出来る。新規の仮想ウェアハウスは、迅速に提供され、新規の仮想ウェアハウスが、プロジェクトの開始時すぐに、データ処理要求を扱う準備が出来るようにする。

【0060】

新規の仮想ウェアハウスを追加するのに加え、方法８００は、８１２において、１以上の仮想ウェアハウスを非アクティブ化するか否かを判定することが出来る。任意の仮想ウェアハウスが必要なくなった場合、リソースマネージャは、８１４において、１以上の仮想ウェアハウスを非アクティブにする。例えば、特定の仮想ウェアハウスが、特定のデータ処理プロジェクトのために生成された場合、その仮想ウェアハウスは、特定のプロジェクトが完了した後には、非アクティブにすることが出来る。更に、多くの仮想ウェアハウスが、低いリソース利用率で動作している場合、既存の仮想ウェアハウスのうちの幾つかは、残りの仮想ウェアハウスの性能を劣化させること無く、非アクティブにされることが出来る。幾つかの実施形態においては、仮想ウェアハウスは、特定の期間に生成される。その期間が経過した後、仮想ウェアハウスは、非アクティブにされることが出来る。他の実施形態においては、リソースマネージャは、特定の期間に、アイドル状態であった仮想ウェアハウスを同定し、その仮想ウェアハウスを自動的に非アクティブにする。

【0061】

幾つかの状況においては、特定のユーザ（または、システム管理者）は、より良い性能（例えば、より良いクエリ応答時間）を望むかもしれない。その状況においては、このよりよい性能をサポートするために、追加の仮想ウェアハウスが追加されることが出来る。他の実装においては、リソースマネージャは、スケジューリングされた（が、まだ実行されていない）クエリに基づいて、今度のリソースのニーズを予測する。スケジュールされたクエリが、システムの性能をかなり劣化させる場合、リソースマネージャは、そのクエリを実行する前に、より多くのリソースを追加することができ、それによって、システム全体の性能を維持することが出来る。それらのクエリの実行の後、追加されたリソースは、リソースマネージャによって非アクティブにされることが出来る。

【0062】

幾つかの実施形態においては、リソースマネージャは、特定のクエリ（または、クエリのグループ）を実行するのに必要な時間を予測する。現在のクエリ処理性能（例えば、クエリ処理遅延、システム利用率など）に基づいて、リソースマネージャは、その特定のクエリ、または、クエリのグループのために、追加のリソースが必要か否かを判定する。例えば、現在のクエリ処理遅延が、閾値を超えているならば、リソースマネージャは、特定のクエリ、または、クエリのグループを処理するための追加のリソースを提供するために、１以上の新規の実行ノードを生成することが出来る。クエリ、または、クエリのグループの処理が完了した後、リソースマネージャは、他のクエリの処理のために、もう必要ないならば、（複数の）新規の実行ノードを非アクティブにすることが出来る。

【0063】

幾つかの実施形態において、特定のユーザは、ユーザのクエリを処理するとき、ある性能レベルを要求するかもしれない。例えば、ユーザは、５秒など、特定の期間内に、クエリ応答を要求するかもしれない。このような実施形態においては、リソースマネージャは、ユーザの性能レベルを確実に達成するために、ユーザのクエリを実行する前に、追加のリソースを割り当てることが出来る。

【0064】

図９Ａ及び９Ｂは、リソースのスケーリングのための方法９００の実施形態のフロー図を図示する。最初に、リソースマネージャは、９０２において、複数のユーザから受信される要求を監視する。更に、リソースマネージャは、９０４において、複数のストレージデバイス（例えば、複数のリモートストレージデバイス）における現在のデータ割り当てを監視し、複数のプロセッサの現在の利用率を監視する。方法９００は、９０６において、データ処理要求と、複数のストレージデバイスにおける現在のデータ割り当てとに基づいて、追加のデータストレージ容量が必要か否かをリソースマネージャが判定するに従い、継続する。リソースマネージャは、追加のデータ容量が必要と判断したとき、９０８において、複数のユーザをサポートするために、追加のデータストレージリソースを割り当てる。この追加のデータ容量は、リソースマネージャが判定したように、任意の数の複数のユーザにアクセス可能とすることができる。幾つかの実施形態においては、より多いデ
ータ容量の追加は、「水平スケーリング」と呼ばれる。

【0065】

リソースマネージャは、また、９１０において、割り当てられたデータ容量のうちの幾らかが、もう必要ないか否かも判定する。リソースマネージャが、割り当てられたデータ容量のうちの幾らかが、もう必要ないと判定した場合、リソースマネージャは、９１２において、データ容量のうちのいくらかをリリースする。例えば、リリースされたデータ容量は、他のシステムまたはサービスによって用いられることが出来るようになる、利用可能なデータ容量のプールに返される。その後の時間に、追加のデータ容量が必要になった場合、リソースマネージャは、利用可能なプールから、データリソースにアクセスすることが出来る。

【0066】

方法９００は、９１４において、データ処理要求と複数のプロセッサの現在の利用率とに基づいて、追加の処理リソースが必要か否かをリソースマネージャが判定するのに従い、継続する。リソースマネージャは、追加の処理リソースが必要と判定した場合には、９１６において、複数のユーザをサポートするために、追加の処理リソースを割り当てる。追加の処理リソースは、リソースマネージャによって指示されるように、任意の数の複数のユーザへアクセスすることが出来る。例えば、特定のユーザが、大量のデータクエリを提出した場合、追加の処理リソースのうちの一部は、データクエリの処理を支援するために、そのユーザに割り当てられることが出来る。幾つかの実施形態においては、より多くの処理リソースの追加は、「垂直スケーリング」と呼ばれる。

【0067】

リソースマネージャは、また、９１８において、現在割り当てられている処理リソースのうちの幾つかは、もはや必要ないか否かも判定する。リソースマネージャは、現在割り当てられている処理リソースのうちの幾つかが、もはや必要ないと判定したとき、９２０において、もはや必要のない処理リソースのうちの幾つかをリリースする。幾つかの実施形態において、リリースされる処理リソースは、他のシステムまたはサービスによって使用されることが出来る、利用可能な処理リソースのプールに返される。その後の時間に、追加の処理リソースが必要となる場合、リソースマネージャは、利用可能なプールから、処理リソースにアクセスすることが出来る。

【0068】

ここに記述されるように、データ処理プラットフォーム１００は、データストレージ容量、処理リソース、キャッシュリソースなどの様々なリソースの動的な起動と、非アクティブ化とをサポートする。単一のデータ処理プラットフォーム１００は、現在のデータストレージと、継続中および、予測されるデータ処理要求の処理要件とに基づいて、オンデマンドで、動的に変更されることが出来る。データストレージと処理要件が変更されると、データ処理プラットフォーム１００は、データ処理性能の実質的に均一なレベルを維持するように自動的に調整する。

【0069】

更に、記述されるデータ処理プラットフォーム１００は、独立に、データストレージ容量と処理リソースへの変更を許容する。例えば、データストレージ容量は、既存の処理リソースへいかなる変更も行うことなく、変更されることが出来る。同様に、処理リソースは、既存のデータストレージ容量へいかなる変更も行うことなく、変更されることが出来る。

【0070】

図１０は、リソースをスケーリングするための他の方法の実施形態を図示するフロー図である。最初に、リソースマネージャ（例えば、リソースマネージャ１０２）は、１００２において、複数のユーザから受信する要求を監視する。ここに記述されるように、これらの要求は、データ検索クエリ、データ読み取り要求、データ書き込み要求などを含むことが出来る。リソースマネージャは、また、１００４において、現在のユーザの数を同定する。新規のユーザがシステムにアクセスし、既存のユーザがシステムから切断するに従い、この数は定期的に変化する。更に、リソースマネージャは、１００６において、現在のユーザの活動レベルを同定する。活動レベルは、例えば、ある期間にわたって提出されたクエリの数、継続中のクエリの数などを含む。この活動レベルは、各ユーザについて判定されることができ、または、現在のユーザの全て（もしくは、現在のユーザのグループ）についての平均の活動として表されることが出来る。

【0071】

現在のユーザの数及び現在のユーザの活動レベルに基づいて、リソースマネージャは、１００８において、現在のユーザの活動レベルをサポートするのに必要なデータストレージリソースと処理リソースを判定する。ユーザの数が定期的に変わり、ユーザの活動レベルが頻繁に変化しうるので、リソースマネージャは、現在のリソースが、現在のユーザを十分サポートするか否かを連続的に判定する。１０１０において、追加のリソースが必要な場合、リソースマネージャは、１０１２において、現在のユーザをサポートするために、１以上の新規の仮想ウェアハウスを提供する。同様に、ユーザの数及び／または、活動レベルが減少する場合、リソースマネージャは、現在のユーザをサポートするのにもはや必要ない場合には、１以上の仮想ウェアハウスを非アクティブにすることが出来る。

【0072】

幾つかの実装においては、同一のファイルが、同時に、複数の実行ノードによってキャッシュされる。ファイルのこの複数のキャッシングは、複数の実行ノードに渡る負荷バランシング（例えば、データ処理タスクをバランスする）を支援する。更に、ファイルを複数の実行ノードにキャッシングすることは、かなりの量のデータが、同一の通信リンクを通過しようとする場合、潜在的なボトルネックの防止を支援する。この実装は、また、異なる実行ノードによる、同一データの並列処理もサポートする。

【0073】

ここに記述したシステム及び方法は、共有ディスクシステム及びシェアド・ナッシング・アーキテクチャの両方の利点を利用する。データを格納し、検索するための記述されたプラットフォームは、データがローカルにキャッシュされれば、シェアド・ナッシング・アーキテクチャのようにスケーラブルである。これはまた、何の制限もなく（例えば、０からＮまで）、且つ、データのいかなる明示的なリシャッフルを要求することなく、処理ノードを追加及び除去することが出来る、共有ディスクアーキテクチャの利点のすべてを有している。

【0074】

図１１は、例示的なコンピューティングデバイス１１００を図示するブロック図である。幾つかの実施形態においては、コンピューティングデバイス１１００は、ここに記述した、１以上のシステム及びコンポーネントを実装するために、用いられる。例えば、コンピューティングデバイス１１００により、ユーザまたは管理者は、リソースマネージャ１０２にアクセス可能とすることができる。更に、コンピューティングデバイス１１００は、ここに記述された、任意のシステム及びコンポーネントと相互作用することが出来る。従って、コンピューティングデバイス１１００は、ここに記述したような、様々なプロシージャ及びタスクを実行するために用いられることが出来る。コンピューティングデバイス１１００は、サーバ、クライアント、または、任意の他のコンピューティング装置として、機能することが出来る。コンピューティングデバイス１１００は、デスクトップコンピュータ、ノートブックコンピュータ、サーバコンピュータ、ハンドヘルドコンピュータ、タブレットなどの任意の広範な様々のコンピューティングデバイスとすることが出来る。

【0075】

コンピューティングデバイス１１００は、１以上のプロセッサ１１０２、１以上のメモリデバイス１１０４、１以上のインタフェース１１０６、１以上の大容量ストレージデバイス１１０８、及び、１以上の入出力（Ｉ／Ｏ）デバイス１１１０を含み、これらすべては、バス１１１２に結合される。（複数の）プロセッサ１１０２は、（複数の）メモリデバイス１１０４及び／または（複数の）大容量ストレージデバイス１１０８に格納される命令を実行する、１以上のプロセッサまたはコントローラを含む。（複数の）プロセッサ１１０２は、また、キャッシュメモリなどの、様々なタイプのコンピュータ可読媒体を含むことが出来る。

【0076】

（複数の）メモリデバイス１１０４は、揮発性メモリ（例えば、ランダムアクセスメモリ（ＲＡＭ））及び／または不揮発性メモリ（例えば、リードオンリーメモリ（ＲＯＭ））などの、様々なコンピュータ可読媒体を含む。（複数の）メモリデバイス１１０４は、また、フラッシュメモリなどの、書き換え可能なＲＯＭを含むことが出来る。

【0077】

（複数の）大容量ストレージデバイス１１０８は、磁気テープ、磁気ディスク、光ディスク、固体メモリ（例えば、フラッシュメモリ）などの、様々なコンピュータ可読媒体を含む。さまざまなドライブは、また、様々なコンピュータ可読媒体からの読み取り、及び／または、これへの書き込みを可能にする（複数の）大容量ストレージデバイス１１０８に含まれることが出来る。（複数の）大容量ストレージデバイス１１０８は、取り外し可能な媒体、及び／または、取り外し不可能な媒体を含む。

【0078】

（複数の）Ｉ／Ｏデバイス１１１０は、データ及び／または他の情報が、コンピューティングデバイス１１００へ入力され、または、これから検索されることを可能とする様々なデバイスを含む。例示的な（複数の）Ｉ／Ｏデバイス１１１０は、カーソル制御デバイス、キーボード、キーパッド、マイクロフォン、モニタ、もしくは、他のディスプレイデバイス、スピーカ、プリンタ、ネットワークインタフェースカード、モデム、レンズ、ＣＣＤ、または、他の画像捕捉デバイスなどを含む。

【0079】

（複数の）インタフェース１１０６は、コンピューティングデバイス１１００が、他のシステム、デバイス、または、コンピューティング環境と相互作用可能とする様々なインタフェースを含む。（複数の）例示的なインタフェース１１０６は、ローカルエリアネットワーク（ＬＡＮ）、ワイドエリアネットワーク（ＷＡＮ）、無線ネットワーク、及び、インターネットに対するインタフェースなどの、任意の数の異なるネットワークインタフェースを含む。

【0080】

バス１１１２により、（複数の）プロセッサ１１０２、（複数の）メモリデバイス１１０４、（複数の）インタフェース１１０６、（複数の）大容量ストレージデバイス１１０８、及び／または、（複数の）Ｉ／Ｏデバイス１１１０は、バス１１１２に結合される他のデバイスもしくはコンポーネントと共に、相互に通信することが可能となる。バス１１１２は、システムバス、ＰＣＩバス、ＩＥＥＥ１３９４バス、ＵＳＢバスなどの１以上の幾つかのタイプのバス構造を表す。

【0081】

図示のために、プログラム及び他の実行可能なプログラムコンポーネントが、離散的なブロックとして、ここに示されたが、そのようなプログラム及びコンポーネントは、コンピューティングデバイス１１００の異なるストレージコンポーネントに、様々な時点で存在し、（複数の）プロセッサ１１０２によって実行されることが出来ることが理解される。あるいは、ここに記述されたシステム及びプロシージャは、ハードウェア、または、ハードウェア、ソフトウェア、及び／もしくは、ファームウェアの組み合わせで実装されることが出来る。例えば、１以上の特定用途向け集積回路（ＡＳＩＣ）は、ここに記述された１以上のシステム及びプロシージャを実行するために、プログラムされることが出来る。

【0082】

本開示は、ある種の好適な実施形態の観点から記述されているが、この開示という恩恵が与えられれば、当業者にとっては、ここに述べた利点と特徴をすべて提供するわけではない実施形態も含めて、他の実施形態も明らかであろうし、それらの他の実施形態もまた、この開示の範囲内である。他の実施形態は、本開示の範囲を逸脱することなく利用されることが出来ることを理解されたい。

【図1】

【図2】

【図3】

【図4】

【図5】

【図6】

【図7】

【図8】

【図9A】

【図9B】

【図10】

【図11】