特開 2024-96963 マルチクラスタウェアハウス

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

(12)【公報種別】公開特許公報(A)

(11)【公開番号】P2024096963

(43)【公開日】2024-07-17

(54)【発明の名称】マルチクラスタウェアハウス

(51)【国際特許分類】

   G06F 9/50 20060101AFI20240709BHJP

【ＦＩ】

G06F9/50 120Z

【審査請求】有

【請求項の数】15

【出願形態】ＯＬ

(21)【出願番号】P 2024067497

(22)【出願日】2024-04-18

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

【原出願日】2017-04-28

(31)【優先権主張番号】62/328,943

(32)【優先日】2016-04-28

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

(71)【出願人】

【識別番号】516245999

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

(74)【代理人】

【識別番号】100121083

【弁理士】

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

(74)【代理人】

【識別番号】100138391

【弁理士】

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

(74)【代理人】

【識別番号】100074099

【弁理士】

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

(72)【発明者】

【氏名】ファンケ， フローリアン アンドレアス

(72)【発明者】

【氏名】ポヴィネック， ピーター

(72)【発明者】

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

(72)【発明者】

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

(57)【要約】

【課題】マルチクラスタウェアハウスのための方法は、仮想ウェアハウスの一部として複数の計算クラスタを割り当てることを含む。
【解決手段】計算クラスタは、１つ以上のクラウド格納リソース中の１つ以上のデータベースに対してアクセスしクエリを実行するために使用される。方法は、複数の計算クラスタの各々に仮想ウェアハウスに対するクエリを提供することを含む。仮想ウェアハウスの複数の計算クラスタの各々は、コンピューティング負荷が異なるクラスタに分散するように複数のクエリを受信する。方法はまた、複数の計算クラスタの作業量に基づいて、必要に応じて、動的に、仮想ウェアハウスに計算クラスタを追加し、仮想ウェアハウスから計算クラスタを除去することを含む。
【選択図】図１

【特許請求の範囲】

【請求項1】

実行プラットフォームとは別の格納プラットフォーム上に配置された１つ以上のクラウド格納リソース内の１つ以上のデータベースにアクセスしクエリを実施するための仮想ウェアハウスの一部として複数の計算クラスタを割り当てるための手段であって、前記複数の計算クラスタは、前記１つ以上のクラウド格納リソースとは別に割り当てられ、前記複数の計算クラスタの各々は、前記格納プラットフォーム上に格納されたデータをキャッシ ュするためのキャッシュメモリを含む１つ以上の実行ノードを含む、前記手段と、
前記複数の計算クラスタの各々に対する実行時に計算された同時実行性の程度と、顧客によって入力された目標の同時実行性の程度との比較に基づいて、前記複数の計算クラスタの現在の作業量を判定するための手段と、
現在配置された１つ以上の計算クラスタが、性能メトリックを満たしつつクエリの内の１つ以上及び前記現在の作業量を処理できる否かに基づいて、動的に前記仮想ウェアハウスに第１の計算クラスタを追加し、前記仮想ウェアハウスから第２の計算クラスタを非アクティブ化するための手段であって、前記性能メトリックは前記クエリに対する最大待機時間を含み、前記第１の計算クラスタを追加する又は前記第２の計算クラスタを非アクティブ化するための前記手段は、前記１つ以上のクラウド格納リソースを増加又は減少させることがなく、前記第２の計算クラスタを非アクティブ化することは、
追加のクエリが前記第２の計算クラスタに提供されることを阻止することと、
前記第２の計算クラスタが現在のスケジューリングされたクエリを完了することを可能にすることと、
前記現在のスケジューリングされたクエリが完了すると、前記第２の計算クラスタに対応する１つ以上のリソースを解放すること
を含む、前記手段と
を含む、システム。

【請求項2】

動的に前記仮想ウェアハウスに前記第１の計算クラスタを追加し、前記仮想ウェアハウスから前記第２の計算クラスタを非アクティブ化するための前記手段は、
現在割り当てられている１つ以上の計算クラスタが、前記性能メトリックを満たしつつ、前記現在の作業量と組み合わせて前記クエリを処理できないと判定することに応答して、前記第１の計算クラスタの起動をトリガーするための手段と、
前記現在の作業量が前記性能メトリックを満たしつつ、前記複数の計算クラスタよりも１つ少ない数でサービス可能か否かを判定するための手段と
の内の１つ以上を含み、
前記第２の計算クラスタを非アクティブ化することは、前記現在の作業量が前記性能メトリックを満たしつつ、前記複数の計算クラスタよりも１つ少ない計算クラスタでサービス可能であると判定することに更に応答する、
請求項１に記載のシステム。

【請求項3】

前記仮想ウェアハウスに対するクエリを前記複数の計算クラスタの各々に提供するための手段を更に含み、クエリを提供するための前記手段は、
前記クエリが発信されるセッションに基づいてクエリをルーティングするための手段、又は
クエリを実行するために、クラスタリソースの可用性に基づいて前記クエリをルーティングするための手段
の内の１つ以上を含む、請求項１に記載のシステム。

【請求項4】

実行プラットフォームとは別の格納プラットフォーム上に配置された１つ以上のクラウド格納リソース内の１つ以上のデータベースにアクセスしてクエリを実施するための仮想ウェアハウスの一部として前記実行プラットフォーム上に複数の計算クラスタを割り当てることであって、前記複数の計算クラスタは、前記１つ以上のクラウド格納リソースとは別に割り当てられ、前記複数の計算クラスタの各々は、前記格納プラットフォーム上に格納されたデータをキャッシュするためのキャッシュメモリを含む１つ以上の実行ノードを含むことと、
前記複数の計算クラスタの各々に対する実行時に計算された同時実行性の程度と、顧客によって入力された目標の同時実行性の程度との比較に基づいて、前記複数の計算クラスタの現在の作業量を判定することと、
現在割り当てられている１つ以上の計算クラスタが、性能メトリックを満たしつつ、クエリの内の１つ以上及び前記現在の作業量を処理できるか否かに少なくとも部分的に基づいて、動的に前記仮想ウェアハウスに第１の計算クラスタを追加し、又は前記仮想ウェアハウスから第２の計算クラスタを非アクティブ化することであって、前記性能メトリックは前記クエリに対する最大待機時間を含み、前記第１の計算クラスタを追加する又は前記第２の計算クラスタを非アクティブ化することは、前記１つ以上のクラウド格納リソースを増加又は減少させることがなく、前記第２の計算クラスタを非アクティブ化することは、
追加のクエリが前記第２の計算クラスタに提供されることを阻止することと、
前記第２の計算クラスタが現在のスケジューリングされたクエリを完了することを可能にすることと、
前記現在のスケジューリングされたクエリが完了すると、前記第２の計算クラスタに対応する１つ以上のリソースを解放すること
を含むこと
を含む、方法。

【請求項5】

前記複数の計算クラスタに対する前記作業量を判定することであって、前記作業量を判定することは、前記複数の計算クラスタの各々に対するプロセッサリソース、又は前記複数の計算クラスタの各々に対するメモリリソースの内の１つ以上の可用性を判定することを含むことと、
前記性能メトリックが各クエリに対して満たされるように、前記計算クラスタに向けられた各クエリに対して前記クエリが処理できるか否かを判定すること
の内の１つ以上を更に含む、請求項４に記載の方法。

【請求項6】

前記作業量に基づいて前記仮想ウェアハウスに前記第１の計算クラスタを動的に追加することは、
クエリが、前記クエリに対する性能メトリックを満たしつつ処理できるか否かを判定することと、
現在の作業量と組み合わせて前記クエリが、現在割り当てられている１つ以上の計算クラスタが前記性能メトリックを満たすようにすることができないと判定することに応答して、前記第１の計算クラスタの起動をトリガーすること
を含む、請求項４に記載の方法。

【請求項7】

前記性能メトリックは、前記クエリに対する最大待機時間を定義するサービスレベルアグリーメントを更に含む、請求項６に記載の方法。

【請求項8】

前記作業量に基づいて前記第２の計算クラスタを非アクティブ化することは、現在の作業量が、性能メトリックを満たしつつ前記複数の計算クラスタよりも１つ少ない計算クラスタでサービス可能か否かを判定することを含む、請求項４に記載の方法。

【請求項9】

前記現在の作業量が前記複数の計算クラスタよりも１つ少ない計算クラスタでサービス可能か否かを判定することは、前記現在の時間に至るまでの期間に対する履歴作業量が、前記性能メトリックを満たしつつ前記複数の計算クラスタよりも１つ少ない計算クラスタでサービス可能であったか否かを判定することを更に含む、請求項８に記載の方法。

【請求項10】

前記第２の計算クラスタを非アクティブ化することは、
前記期間に対する前記履歴作業量が前記複数の計算クラスタよりも１つ少ない計算クラスタでサービス可能であったと判定することに応答して、前記第２の計算クラスタを非アクティブ化すること、又は
前記複数の計算クラスタを割り当てることは、異なるアベイラビリティーゾーンに少なくとも２つの計算クラスタを割り当てること
を更に含む、請求項９に記載の方法。

【請求項11】

前記複数の計算クラスタの各々に前記仮想ウェアハウスに対するクエリを提供することは、
前記クエリが発信されるセッションに基づいてクエリをルーティングすること、又は
前記複数の計算クラスタの各々の作業量に基づいてクエリをルーティングすることの内の１つ以上を含む、請求項４に記載の方法。

【請求項12】

データ処理装置によって実行される場合に、
実行プラットフォームとは別の格納プラットフォーム上に配置された１つ以上のクラウド格納リソース内の１つ以上のデータベースにアクセスしクエリを実施するための仮想ウェアハウスの一部として前記実行プラットフォーム上に複数の計算クラスタを割り当てることであって、前記複数の計算クラスタは、前記１つ以上のクラウド格納リソースとは別に割り当てられ、前記複数の計算クラスタの各々は、前記格納プラットフォーム上に格納されたデータをキャッシュするためのキャッシュメモリを含む１つ以上の実行ノードを含むことと、
前記複数の計算クラスタの各々に対する実行時に計算された同時実行性の程度と、顧客によって入力された目標の同時実行性の程度との比較に基づいて、前記複数の計算クラスタの現在の作業量を判定することと、
現在割り当てられている１つ以上の計算クラスタが、性能メトリックを満たしつつ、クエリの内の１つ以上及び現在の作業量を処理できるか否かに少なくとも部分的に基づいて、動的に前記仮想ウェアハウスに第１の計算クラスタを追加し、及び前記仮想ウェアハウスから第２の計算クラスタを非アクティブ化することであって、前記性能メトリックは前記クエリに対する最大待機時間を含み、前記第１の計算クラスタを追加する又は前記第２の計算クラスタを非アクティブ化することは、前記１つ以上のクラウド格納リソースを増加又は減少させることがなく、前記第２の計算クラスタを非アクティブ化することは、
追加のクエリが前記第２の計算クラスタに提供されることを阻止することと、
前記第２の計算クラスタが現在のスケジューリングされたクエリを完了することを可能にすることと、
前記現在のスケジューリングされたクエリが完了すると、前記第２の計算クラスタに対応する１つ以上のリソースを解放すること
を含むこと
を含む動作を前記データ処理装置に実施させる命令を格納する非一時的可読格納媒体。

【請求項13】

前記動作は、
前記１つ以上のクラウド格納リソースを増加又は減少させることなく、前記計算クラスタの数をスケールアップ及びスケールダウンできるように、前記１つ以上のクラウド格納リソースから独立して前記複数の計算クラスタを割り当てること、
前記複数の計算クラスタの各々に対するプロセッサリソース、前記複数の計算クラスタの各々に対するメモリリソースの内の１つ以上の可用性を判定すること、若しくは特定のクエリを処理するために必要な最小限のリソースを予測することによって、前記複数の計算クラスタに対する前記作業量を判定すること、又は
クエリが前記クエリに対する性能メトリックを満たしつつ処理できるか否かを判定し、現在の作業量と組み合わせて前記クエリが、現在割り当てられている１つ以上の計算クラスタが前記性能メトリックを満たすようにできないと判定することに応答して、第１の計算クラスタの起動をトリガーすることによって、前記作業量に基づいて前記仮想ウェアハウスに前記第１の計算クラスタを動的に追加すること
を更に含む、請求項１２に記載の非一時的可読格納媒体。

【請求項14】

前記動作は、
前記作業量が前記複数の計算クラスタよりも１つ少ない計算クラスタでサービス可能であると判定すること
を更に含む、請求項１２に記載の非一時的可読格納媒体。

【請求項15】

前記動作は、
前記現在の作業量が前記複数の計算クラスタよりも１つ少ない計算クラスタでサービス可能か否かを判定することは、前記現在の時間に至るまでの期間に対する履歴作業量が、前記性能メトリックを満たしつつ、前記複数の計算クラスタよりも１つ少ない計算クラスタでサービス可能であったか否かを判定することを更に含むこと、及び
前記第２の計算クラスタを非アクティブ化することは、前記期間に対する前記履歴作業量が前記複数の計算クラスタよりも１つ少ない計算クラスタでサービス可能であったと判定することに応答して非アクティブ化することを含むこと、又は
前記複数の計算クラスタの各々に前記仮想ウェアハウスに対するクエリを提供することは、前記クエリが発信されるセッションに基づいてクエリをルーティングすることを含むこと、
を更に含む、請求項１４に記載の非一時的可読格納媒体。

【発明の詳細な説明】

【技術分野】

【0001】

本出願は、２０１６年４月２８日に出願された名称“マルチクラスタウェアハウス”の米国仮出願番号６２／３２８，９４３の優先権を主張し、その全体が参照により本明細書に組み込まれる。

【0002】

本開示は、マルチクラスタウェアハウスのためのシステム、方法、及びデバイスに関する。

【背景技術】

【0003】

コンピューティングの利用においては、データの格納及びアクセスのためにデータベースが広く使用される。データベースは、クエリを使用して読み出され得、変更され得、又は削除され得るデータを含む又は参照する１つ以上のテーブルを含み得る。データベースは、１つ以上のテーブル内に小さな又は極めて大きなデータセットを格納することができる。このデータはウェブサイト又はアプリケーションプログラムインタフェース（ＡＰＩ）介する等して、団体の様々なユーザによりアクセスされ得、又は公的ユーザに提供するために使用され得る。コンピューティング及び格納のリソース、及びそれらの基礎をなすアーキテクチャの両方は、所望のデータベースの性能を達成するのに大きな役割を果たし得る。

【0004】

本開示の非限定的で非網羅的な実施形態が以下の図面を参照しながら記述され、特段の定めがない限り様々な図を通じて同様の参照数字が同様の部分に付される。

【図面の簡単な説明】

【0005】

【図1】本明細書に記述されるシステム及び方法の例示的実施形態に従った処理プラットフォームを図示するブロック図である。

【図2】一実施形態に従った、リソースマネージャのコンポーネントを説明するブロック図である。

【図3】一実施形態に従った、マルチクラスタウェアハウスのスケジューリングを図示するブロック図である。

【図4】一実施形態に従った、単一の実行プラットフォーム上に提供され得る複数のウェアハウスを図示するブロック図である。

【図5】一実施形態に従った、分散された多数の仮想ウェアハウスを有するシステムを説明するブロック図である。

【図6】一実施形態に従った、マルチクラスタウェアハウスのための方法を説明する概略的フローチャート図である。

【図7】一実施形態に従った、マルチクラスタウェアハウス中のコンピュータクラスタを動的に追加するための方法を説明する概略的フローチャート図である。

【図8】一実施形態に従った、マルチクラスタウェアハウス中のコンピュータクラスタを動的に除去するための方法を説明する概略的フローチャート図である。

【図9】一実施形態に従った、マルチクラスタウェアハウスのための方法を説明する概略的フローチャート図である。

【図10】本明細書に開示される処理及びシステムの少なくとも１つの実施形態と一致する例示的コンピューティングデバイスを図示するブロック図である。

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

【0006】

本開示は、マルチクラスタウェアハウスを提供及び管理するためのシステム、方法、及びデバイスに向けられる。ウェアハウスは、分析クエリの取り扱いにおいて接続又は協働される幾つかのサーバである。幾つかのウェアハウスでは、計算及び格納のリソースは相互に接続及び割り当てられる。本明細書に開示される少なくとも幾つかの実施形態では、計算リソースは、独立して割り当てられ、格納リソースとは別に拡大縮小が可能である。幾つかのケースでは、ウェアハウスは、サービスを提供するために一体となって働き得る１つ以上のクラスタ及び／又は１つ以上のサーバノードのクラスタを含む。出願人は、マルチクラスタウェアハウスのためのアーキテクチャ、方法、アルゴリズム、及びシステムを開発し、本明細書に提示する。

【0007】

一実施形態に従うと、マルチクラスタウェアハウスのための方法は、仮想ウェアハウスの一部として複数の計算クラスタを割り当てることを含む。計算クラスタは、１つ以上のクラウド格納リソース中の１つ以上のデータベースに対してアクセスしクエリを実行するために使用され得る。方法は、仮想ウェアハウスに対するクエリを複数の計算クラスタの各々に提供することを含む。例えば、仮想ウェアハウスの複数の計算クラスタの各々は、コンピューティング負荷が異なるクラスタに分散するように複数のクエリを受信し得る。方法はまた、複数の計算クラスタの作業量に基づいて、必要に応じて、動的に、仮想ウェアハウスに計算クラスタを追加し、仮想ウェアハウスから計算クラスタを除去することを含み得る。

【0008】

マルチクラスタウェアハウスは、同時実行性及び可用性（availability）において顕著な向上を提供し得る。例えば、ウェアハウスは、一般的に、サイズが該ウェアハウスのサイズである単一のクラスタのみを含む。例えば、大きなウェアハウスは、８つのサーバノードの単一のクラスタを含み得る。マルチクラスタウェアハウスは、多数のクラスタを有する単一のウェアハウスの創造を可能にし得る。ウェアハウス内の各クラスタは８つのサーバノードを含み得る。したがって、マルチクラスタウェアハウスは、同じサイズの単一のクラスタウェアハウスにより提供される同時実行レベルの３倍を支持し得る。このアーキテクチャは、本明細書で更に論じられるように、コンピューティングリソースの拡大縮小を可能にもしつつ、単一のウェアハウスに対して高レベルの同時実行性を可能にし得る。

【0009】

異なるアベイラビリティゾーン（availability zone）中に異なるクラスタを設置することによって、マルチクラスタウェアハウスにおいて可用性の向上も達成され得る。例えば、各ウェアハウスクラスタは（異なるＡｍａｚｏｎ（登録商標）のアベイラビリティゾーン内等の）クラウドプロバイダの異なるアベイラビリティゾーン中に割り当てられるので、マルチクラスタウェアハウスは、誤り回復力の向上を提供する。それ故、マルチクラスタウェアハウスは、単一のクラスタウェアハウスと比較して高い可用性を有する。更に、クエリは、メモリ又はローカルなディスクベースのストレージ中に（例えば、キャッシュ中に）関連するデータセグメントが既に存在する最適クラスタにルーティングされ得る。例えば、マルチクラスタウェアハウスのための方法は、クエリが起きたセッションに基づいてクエリをルーティングすることを含み得る。同じセッションからのクエリを同じクラスタに提供することによって、クエリに必要とされるデータがメモリ中に既に存在し且つクラウド格納リソースからデータを検索する必要性を省き得る可能性を増加させる。同時実行性及び可用性の向上によって、ユーザは、その他の従来の単一のクラスタデータベースアーキテクチャでは達成することが困難又は不可能であろう応答時間及び可用性の向上を経験し得る。

【0010】

同時実行性及び可用性の向上に加えて、計算リソースの自動的な拡大縮小の顕著な変更が可能である。例えば、少なくとも幾つかの実施形態は、クラウドストレージとは別の計算リソースの割り当てを提供する。したがって、マルチクラスタウェアハウスは、変化しない又はクエリの作業量と比べて非常に遅く変化しているデータに対してクエリを依然行いつつ、大きな作業量の変動に適応するために計算クラスタの数を拡大又は縮小し得る。

【0011】

ウェアハウスが作業量を処理できず、クエリを待機（queue）させなければならない（或いは、許容される時間の長さよりも長くクエリを待機させる）場合に新たな又はサスペンドしたクラスタの自動的なレジューム又は開始が実行され得る。クラスタ上の総リソース消費が閾値を越えているため、クエリは待機させられ得る。例えば、リソース消費は、メモリ負荷とコンピューティング又は処理負荷とに対するパラメータを含み得る。一実施形態では、パラメータは、新たなクラスタがレジューム又は供給されるべき前にクエリがどのくらいの長さを待機し得るかに対して制御する。新たなクラスタがレジュームされると直ぐに、クエリは、新たなクラスタ上で実行されるようにスケジューリングされ得る。これは、新たなクエリと既に待機したクエリとに適用される。

【0012】

一実施形態では、マルチクラスタウェアハウスのための方法は、作業量に基づいて仮想ウェアハウスに計算クラスタを動的に追加することを含み得る。方法は、クエリに対する性能メトリックに合致しつつクエリが処理され得るか否かを判定することを含み得る。現在の作業量と組み合わせたクエリが、現在割り当てられた１つ以上の計算クラスタを性能メトリックに合致するようにできない場合、方法は、新たな計算クラスタの起動を誘発することを含み得る。幾つかの実施形態では、新たなクラスタは、必要とされる性能メトリックよりも単一のクエリが少なくならないことを確保するのに十分速く割り当てられ得る。

【0013】

マルチクラスタウェアハウスのアクティブクラスタの自動的なサスペンド又は廃止は、作業量のリソース消費が十分低いために、該クラスタのサスペンドが過去に実行された何れのクエリもＮ分待機（又は閾値時間よりも長く待機）させなかったであろう場合に実行され得る。クエリの待機又はクエリに対する待機時間は、使用され得る性能メトリックの一例に過ぎない。一実施形態では、マルチクラスタウェアハウスのための方法は、作業量に基づいて計算クラスタを除去することを含み得る。方法は、性能メトリックに合致しつつ複数の計算クラスタよりも少数の計算クラスタにより現在の作業量がサービス可能であるか否かを判定することを含み得る。方法は、複数の計算クラスタよりも少数の計算クラスタにより作業量がサービス可能であるとの判定に応答して、複数の計算クラスタの内の少なくとも１つの計算クラスタを廃止（又はサスペンド）することを含み得る。

【0014】

一実施形態に従えば、クラスタの自動的な供給又は除去と、ウェアハウス内の異なるクラスタへのクエリのルーティングとは、サービスとして、強力で柔軟なマルチクラスタウェアハウスの一部に使用され得る。

【0015】

本開示の実施形態と一致するシステム及び方法の詳細な記述が以下に提供される。幾つかの実施形態が記述されるが、この開示は、何れかの１つの実施形態に限定されないが、代わりに、多数の代替物、変形物、及び均等物を包含することを理解すべきである。また、本明細書に開示される実施形態の理解を通じて提供するために多数の具体的詳細が以下の説明で記述されるが、幾つかの実施形態はそれらの幾つか又は全ての詳細なしに実施され得る、更に、明確にする目的のため、関連する技術で周知の幾つかの技術項目は、開示を不必要に不明確にすることを避けるために詳細には記述されていない。

【0016】

図に向けると、図１は、一実施形態に従った、マルチクラスタウェアハウスを提供及び／又は管理するための処理プラットフォーム１００を説明するブロック図である。処理プラットフォーム１００は、多数のユーザ１０４、１０６、及び１０８によりアクセス可能なリソースマネージャ１０２を含む。リソースマネージャ１０２は、本明細書ではデータベースサービスマネージャとも称され得る。幾つかの実装では、リソースマネージャ１０２は、処理プラットフォーム１００のデータ又はサービスへのアクセスを要望する任意の数のユーザを支持し得る。ユーザ１０４～１０８は、例えば、データの格納及び検索のクエリ及びリクエストを提供するエンドユーザ、本明細書に記述されるシステム及び方法を管理するシステム管理者、データベースと相互作用するソフトウェアアプリケーション、及びリソースマネージャ１０２と相互作用するその他のコンポーネント／デバイスを含み得る。

【0017】

リソースマネージャ１０２は、処理プラットフォーム１００内のシステム及びコンポーネントの動作を支持する様々なサービス及び機能を提供し得る。リソースマネージャ１０２は、データ処理プラットフォーム１００を通じて格納されたデータと関連付けられるメタデータ１１０を格納するためのアクセスを有する。リソースマネージャ１０２は、ユーザクエリを最適化するためにメタデータ１１０を使用し得る。幾つかの実施形態では、メタデータ１１０は、遠隔データ格納システム中に格納されたデータとローカルキャッシュ（例えば、実行プラットフォーム１１２の１つ以上のクラスタ内のキャッシュ）から入手可能なデータとの概要を含む。また、メタデータ１１０は、遠隔データ格納システム及びローカルキャッシュ中にデータを整理する方法に関する情報を含み得る。メタデータ１１０は、格納デバイスから実データをロード又はアクセスすることなくデータを処理する必要があるか否かをシステム及びサービスが判定できるようにする。

【0018】

データ処理プラットフォーム１００の一部として、メタデータ１１０は、データ操作言語（ＤＭＬ）を使用してデータを変更させる場合に収集され得、それは、任意のＤＭＬステートメントを通じて変更させ得る。データの操作の一例は、データを選択すること、更新すること、変更すること、併合すること、及びテーブル中に挿入することを含み得るが、これらに制限されない。処理プラットフォーム１００の一部として、ファイルが作り出され得、ファイル毎及びコラムベース毎にメタデータ１１０が収集され得、その後、メタデータ１１０はメタデータストア中に保存され得る。メタデータ１１０のこの収集は、データ採取中に実行され得、又はメタデータ１１０の収集は、データが採取又はロードされた後に別のプロセスとして実行され得る。実装では、メタデータ１１０は、複数のディスティンクト値、複数のヌル値、並びに最小値及び最大値をファイル毎に含み得る。実装では、メタデータは、ストリング長情報及びストリング中の文字範囲を更に含み得る。

【0019】

リソースマネージャ１０２は更に、実行プラットフォーム１１２と通信し、それは、以下により詳細を論じるように、様々なデータ格納及びデータ検索の動作を実行する多数のコンピューティングリソースを提供する。実行プラットフォーム１１２は、特定のウェアハウスにユーザ１０４～１０８により提供されるクエリ作業量に基づいて特定のウェアハウスに対して動的に割り当て又はサスペンドされ得る１つ以上の計算クラスタを含み得る。実行プラットフォーム１１２は、格納プラットフォーム１１４の一部である１つ以上のデータ格納デバイス１１６、１１８、及び１２０と通信する。３つのデータ格納デバイス１１６、１１８、及び１２０が図１に示されるが、実行プラットフォーム１１２は、任意の数のデータ格納デバイスと通信可能である。幾つかの実施形態では、データ格納デバイス１１６、１１８、及び１２０は、１つ以上の地理的位置に配置されたクラウドベースの格納デバイスである。例えば、データ格納デバイス１１６、１１８、及び１２０は、公的なクラウド基盤又は私的なクラウド基盤の一部であり得、又は任意のその他の種類の分散格納システムであり得る。データ格納デバイス１１６、１１８、及び１２０は、ハードディスクドライブ（ＨＤＤ）、ソリッドステートドライブ（ＳＳＤ）、ストレージクラスタ、又は任意のその他のデータ格納技術を含み得る。また、格納プラットフォーム１１４は、（Ｈａｄｏｏｐ分散ファイルシステム（ＨＤＦＳ）等の）分散ファイルシステム、及びオブジェクト格納システム等を含み得る。

【0020】

幾つかの実施形態では、リソースマネージャ１０２とユーザ１０４～１０８、メタデータ１１０、及び実行プラットフォーム１１２との間の通信リンクは、１つ以上のデータ通信ネットワークを介して実装され、ユーザリクエストが最適化され得るように様々なタスクを割り当てられ得る。同様に、実行プラットフォーム１１２と格納プラットフォーム１１４中のデータ格納デバイス１１６～１２０との間の通信リンクは、１つ以上のデータ通信ネットワークを介して実装される。これらのデータ通信ネットワークは、任意の通信プロトコルと任意の種類の通信媒体とを利用し得る。幾つかの実施形態では、データ通信ネットワークは、相互に結合された２つ以上のデータ通信ネットワーク（又はサブネットワーク）の組み合わせである。別の実施形態では、これらの通信リンクは、任意の種類の通信媒体と通信プロトコルとを使用して実装される。

【0021】

図１に示されるように、データ格納デバイス１１６、１１８、及び１２０は、実行プラットフォーム１１２と関連付けられたコンピューティングリソースから分離される。このアーキテクチャは、データ処理プラットフォーム１００にアクセスするユーザ及びシステムのデータの格納／検索要請、コンピューティング要請、及び変更要請の変化に基づいて、データ処理プラットフォーム１００への動的変更を支持する。動的変更の支持は、データ処理プラットフォーム１００内のシステム及びコンポーネントの要求の変化に応じてデータ処理プラットフォーム１００が即座に拡大縮小できるようにする。データ格納デバイスからのコンピューティングリソースの分離は、対応する大量のコンピューティングリソースを要求することなく大量のデータの格納を支持する。同様に、このリソースの分離は、利用可能なデータ格納リソースの対応する増加を要求することなく、特定時間に利用されるコンピューティングリソースの顕著な増加を支持する。

【0022】

リソースマネージャ１０２、メタデータ１１０、実行プラットフォーム１１２、及び格納プラットフォーム１１４は、個々のコンポーネントとして図１に示される。しかしながら、リソースマネージャ１０２、メタデータ１１０、実行プラットフォーム１１２、及び格納プラットフォーム１１４の各々は、（例えば、多数の地理的位置に多数のシステム／プラットフォームに渡って分散された）分散システムとして実装され得、又は１つ以上のシステムに結合され得る。また、リソースマネージャ１０２、メタデータ１１０用のストレージ、実行プラットフォーム１１２、及び格納プラットフォーム１１４の各々は、ユーザ１０４～１０８から受信されたリクエストの変化又はデータ処理プラットフォーム１００の変更要請に基づいて（相互に無関係に）拡大又は縮小され得る。したがって、記述される実施形態では、データ処理プラットフォーム１００は、動的であり、現在のデータ処理の要請に合致するように規則的な変更を支持する。

【0023】

実行プラットフォーム１１２は、処理プラットフォーム１００の計算又は処理の負荷を共有し得る複数の計算クラスタ１２２、１２４、１２６を含む。一実施形態では、顧客は、（ウェアハウスの実行中及びそのサスペンド中の両方において）ウェアハウスを作り出す又はその構成を変更する場合にレンジを指定する（例えば、ｍｉｎＣｌｕｓｔｅｒＣｏｕｎｔ及びｍａｘＣｌｕｓｔｅｒＣｏｕｎｔ等の値を指定する）ことによってアクティブな（すなわち、実行している）クラスタの数を制御し得る。顧客は、ウェアハウスがその実行の度に実行する正確な数を有するように指定すること、例えば、最小クラスタカウントを最大クラスタカウントと同数にすることによって、アクティブなクラスタの正確な数を指定し得る。最小クラスタカウントよりも大きい最大クラスタカウントをユーザが指定する場合、リソースマネージャ１０２は、スループット基準を満足し費用面で効果的であるように作業量に基づいて現在のアクティブなクラスタの数を自動的に管理し得る。それ故、ウェアハウスが実行している場合はいつも、少なくとも最小クラスタカウント（ｍｉｎＣｌｕｓｔｅｒＣｏｕｎｔ）のクラスタがアクティブにされ、せいぜい最大クラスタカウント（ｍａｘＣｌｕｓｔｅｒＣｏｕｎｔ）のクラスタがアクティブにされる。リソースマネージャ１０２は、メモリ負荷及び同時実行性レベルの観点から指定された性能基準が与えられた現在の作業量を処理するために幾つのクラスタが必要とされるかを判定し得る。

【0024】

図２は、一実施形態に従った、リソースマネージャ１０２のコンポーネントを示すブロック図を説明する。リソースマネージャ１０２は、データ格納デバイス２０６に結合されたアクセスマネージャ２０２及びキーマネージャ２０４を含む。アクセスマネージャ２０２は、本明細書に記述されるシステムに対する認証及び承認タスクを処理する。キーマネージャ２０４は、認証及び承認タスク中に使用されるキーの格納及び承認を管理する。リクエスト処理サービス２０８は、受信されたデータ格納リクエスト及びデータ検索リクエストを管理する。管理コンソールサービス２１０は、管理者及びその他のシステムマネージャによる様々なシステム及び処理へのアクセスを支持する。

【0025】

リソースマネージャ１０２はＳＱＬコンパイラ２１２、ＳＱＬオプティマイザ２１４、及びＳＱＬエクゼキュータ２１６をも含む。ＳＱＬコンパイラ２１２は、ＳＱＬクエリをパースし、該クエリに対する実行コードを生成する。ＳＱＬオプティマイザ２１４は、処理される必要があるデータに基づいて、クエリを実行するための最良な方法を判定する。ＳＱＬエクゼキュータ２１６は、リソースマネージャ１０２により受信されたクエリに対するクエリコードを実行する、クエリスケジューラ及びコーディネータ２１８は、編集、最適化、及び実行プラットフォーム１１２へのディスパッチのために、受信されたクエリを最適なサービス又はシステムへ送信する。仮想ウェアハウスマネージャ２２０は、実行プラットフォーム１１２に実装される、マルチクラスタウェアハウスを含む多数の仮想ウェアハウスの動作を管理する。

【0026】

また、リソースマネージャ１０２は、コンフィグレーション及びメタデータマネージャ２２２を含み、それは、遠隔データ格納デバイス中に及びローカルキャッシュ中に格納されたデータに関する情報を管理する。モニタ及び作業量アナライザ２２４は、リソースマネージャ１０２により実行された処理を監督し、実行プラットフォーム１１２中の仮想ウェアハウス及び実行ノードに渡るタスク（例えば、作業量）の分散を管理する。コンフィグレーション及びメタデータマネージャ２２２、並びにモニタ及び作業量アナライザ２２４は、データ格納デバイス２２６に結合される。

【0027】

リソースマネージャ１０２は、トランザクション管理及びアクセス制御モジュール２２８をも含み、それは、データ格納リクエスト及びデータアクセスリクエストの処理と関連付けられる様々なタスク及びその他のアクティビティを管理する。例えば、トランザクション管理及びアクセス制御モジュール２２８は、多数のユーザ又はシステムによるデータへの一貫し且つ同期したアクセスを提供する。多数のユーザ／システムは同じデータに同時にアクセスし得るので、各ユーザ／システムがデータの現在のバージョンで作業することを確保するために、データへの変更は同期されなければならない。トランザクション管理及びアクセス制御モジュール２２８は、リソースマネージャ１０２の一か所に集中した位置での様々なデータ処理アクティビティの制御を提供する。

【0028】

仮想ウェアハウスマネージャ２２０を更に参照しながら、マルチクラスタウェアハウス中の自動的クラスタレジューム及び自動的クラスタサスペンドが論じられる。一実施形態では、仮想ウェアハウスマネージャ２２０は、自動的クラスタレジュームを実行する。（例えば、実行プラットフォーム１１２内の）マルチクラスタウェアハウスが自動的レジュームに対してマーキングされる場合、該ウェアハウスに対する第１のクラスタは、ＳＱＬステートメントがスケジューリングされ該ウェアハウス中の全てのクラスタがサスペンド状態にある場合に自動的にレジュームされる。しかしながら、残りのクラスタを自動的にレジュームするとの決定は、作業量に基づいて実行される。これは、ａｃｔｉｖｅＣｌｕｓｔｅｒＣｏｕｎｔ＜ｍａｘＣｌｕｓｔｅｒＣｏｕｎｔであると思われ、すなわち、アクティブ／レジュームされ得るが現在サスペンドされているクラスタを有する。

【0029】

作業量の考慮は少なくとも２つのことを含む。第一に、作業量の考慮はメモリの使用を含み得る。全てのクラスタがそれらの最大メモリ容量にあるために、クエリがスケジューリング及び待機される場合、仮想ウェアハウスマネージャ２２０は、待機が回避され得又は短縮され得るように１つ以上のクラスタをレジュームする。クラスタのレジュームには例えば分単位の少しの時間がかかり得るので、新たなクラスタがレジュームされる必要がある場合に待機が依然として生じ得る。しかしながら、仮想ウェアハウスマネージャ２２０はまた、新たなクラスタの開始中にクエリがフリーなプール上に置かれ得るように、幾つかのフリーなサーバのフリーなプールが存在することを確認し得る。また、仮想ウェアハウスマネージャ２２０は、新たなクラスタの供給を決定する前にクエリが自身で解決さ れるか否かを確認するために一定期間待機し得る。

【0030】

第二に、作業量の考慮は、クラスタについての同時実行度、又は処理／コンピューティング負荷を含み得る。全てのアクティブクラスタ上での同時実行度が高い場合、仮想ウェアハウスマネージャ２２０は、クエリをスケジューリングするための十分なメモリがたとえあったとしても別のクラスタを開始し得る。ここで、同時実行度は、並列度（ＤＯＰ）に基づいてアクティブクラスタ毎に計算され得る。具体的には、同時実行度は、全ＤＯＰで実行しているクエリの数であり得る。例えば、これは、最大ＤＯＰ（ＭＡＸ＿ＤＯＰ）と実行クエリの数との積で全実行クエリに対するＤＯＰを除算することで計算され得る。幾つかの軽量のクエリは最大よりも小さいＤＯＰで実行しているので、これは分数又は非整数であり得る。一実施形態では、同時実行度を制御するために、ウェアハウスパラメータが指定され得る。例えば、同時実行度（ｃｏｎｃｕｒｒｅｎｃｙ＿ｌｅｖｅｌ＿ｔａｒｇｅｔ）はデフォルトでは値８に設定され得る。このパラメータは、顧客がその問題に幾ら費やすのか、及びウェアハウスが共有される場合に（スタンドアローンなクエリ性能と比較して）クエリ性能がどの程度劣化することを厭わないかにその値は実際には依存するので、顧客に晒され得る。

【0031】

一実施形態では、仮想ウェアハウスマネージャ２２０は、自動的クラスタサスペンドを実行する。一実施形態では、（例えば、ａｕｔｏ＿ｓｕｓｐｅｎｄパラメータに基づいた）インアクティブの一定秒後に、全ウェアハウスはシャットダウンし得る。これとは別に、ウェアハウスが２つ以上のアクティブクラスタを有する場合、１つ以上のクラスタは、例えば分単位で測定される所定時間よりも長い間、ウェアハウスがその容量の下で実行していた場合にサスペンドされ得る。例えば、３つのアクティブクラスタを有するウェアハウスを考える。所定時間よりも長い間、ウェアハウスが負荷を受ける、すなわち、最大同時実行度を超えて何ら待機することなく又は進むことなく現時点で所定時間のエンジンで発行された全てのＳＱＬステートメントを実行できている場合、１つ以上のクラスタはサスペンドされる。ウェアハウスは、負荷を受ける間、現在アクティブな全てのクラスタを活用することに留意されたい。クラスタは、シャットダウンするための一定時間、インアクティブにされる必要がない。自動的クラスタサスペンドに対する確認は、残り５分、残り１０分、残り３０分、残り１時間等、定期的に実行され得る。一実施形態では、自動的クラスタに対する確認は、所定時間とは異なる間隔で実行され得る。例えば、負荷の下で残り１０分にあったか否かの確認は、顧客が時間単位で請求され得るように各時間変化で実行され得る。

【0032】

クエリスケジューラ及びコーディネータ２１８を更に参照すると、クエリのスケジューリングは、作業量、クエリの類似性、及びその他の要因に基づいて実行され得る。クエリスケジューラ及びコーディネータ２１８は、作業量に基づいて、クエリを特定のクラスタへ転送し得る。例えば、クエリスケジューラ及びコーディネータ２１８は、処理タスクを拡散するため、及びクエリの実行時間及びユーザエクスペリエンスを向上するために各クラスタ上の作業量をほぼ等しく維持するように試み得る。クエリの類似性は、関連するクエリ、特に、同じデータに関連するクエリが同じクラスタへ送信されるように使用され得る。例えば、クエリスケジューラ及びコーディネータ２１８は、同じセッション識別子を有するクエリを同じクラスタへ送信し得る。クエリの類似性に基づいてクエリを転送することは、実行予定のクエリに対するデータが特定のクラスタのローカルキャッシュ中に既に存在することをクエリスケジューラ及びコーディネータ２１８が確保できるようにし得る。これは、応答時間、作業量、及びデータ検索を著しく削減し得る。

【0033】

図３は、マルチクラスタウェアハウス３０２とマルチクラスタウェアハウス３０２上のクエリ３０４のスケジューリングとを説明する概略的ブロック図である。ウェアハウス３０２は、複数のサーバノードを夫々含む複数のクラスタ（クラスタ１、クラスタ２、クラスタＮ）を含む。一実施形態では、クラスタの各々は、同じ数のサーバを含むが、異なる実施形態ではこれは異なってもよい。一実施形態では、クラスタ中の各サーバは、同じアベイラビリティゾーンに属するが、異なるクラスタは、異なるアベイラビリティゾーンに配置され得る。ウェアハウスの可用性の概念は、ウェアハウスの全体的な可用性の割合に基づき得る。例えば、ウェアハウス３０２内の特定のクラスタに対する可用性は、クラスタサイズと比較して（例えば、動作可能な状態で）利用可能であるサーバの割合であり得る。しかしながら、該割合がクエリを実行するために必要とされる最小（例えば、５０％）を下回る場合、該クラスタに対して可用性が０％と判定され得、ウェアハウス３０２、又はウェアハウス３０２中の幾つかのサーバが修復されるまでクエリが何ら割り当てられないことがある。本明細書で論じられるように、ウェアハウス３０２中のクラスタの数は、作業量又はクラスタのサーバ故障（failure）等に基づいて動的に調整され得る。

【0034】

一実施形態において、クエリスケジューラ及びコーディネータ２１８は、各クエリ（例えば、ＳＱＬステートメント又はＳＱＬステートメントの一部）をその計画されたリソース消費に基づいて重み付けする。例えば、幾つかのクエリは、その他のクエリが実行のために著しくより多くの処理リソースを取り得る間に、実行のために著しくより多くのメモリを取り得る。同様に、幾つかのクエリは、メモリ及び処理の両方について高い又は低い消費を有する。リソースマネージャ１０２は、予測又は計画される消費が何であるかを判定し得、続いて、異なるクラスタ間で作業量を最も効果的に均衡化するためにクエリをどこに配置するかを判定可能であり得る。例えば、高消費のクエリは、低消費の多数のクエリと同じくらいのリソースを使用し得る。

【0035】

一実施形態では、クエリスケジューラ及びコーディネータ２１８は、ウェアハウス３０２の１つ以上のクラスタ上にクエリをスケジューリングし得、又は作業量が高すぎる若しくは可用性が低すぎる場合にクエリを待機し得る。例えば、クエリスケジューラ及びコーディネータ２１８は、ウェアハウス３０２のアクティブな（すなわち、サスペンドされていない）クラスタ上にクエリ３０４（例えば、ＳＱＬステートメント）をスケジューリングするようにまず試み得る。多数のアクティブクラスタが存在する場合、クエリスケジューラ及びコーディネータ２１８は、利用可能ではない、又はメモリが申し込まれ過ぎ得るためにクエリ３０４が実行しないであろうクラスタのセットを除外し得る。前述したように、クラスタは、ノードのサーバの５０％未満が利用可能ではない（例えば、故障している）場合にデフォルトにより利用可能ではないと判定され得る。多数の可能なクラスタが残っている場合、クエリスケジューラ及びコーディネータ２１８は、最低負荷のクラスタを選び得る。最低負荷のクラスタは、一実施形態では、該クラスタ上で実行する全てのジョブのＤＯＰの合計で定義される。最低負荷のクラスタはまた、該クラスタに対する全てのメモリの必要性の合計に基づき得る。負荷と等しいクラスタが多数存在する場合、クエリスケジューラ及びコーディネータ２１８は、同じセッションからのクエリが同じクラスタ上で実行できるように特定のクエリ３０４に対するセッションＩＤをタイブレーカとして使用し得る。ウェアハウス３０２中のクラスタに割り当てられているクエリ３０４は、実行クエリ３０６として示される。

【0036】

特定のクエリをスケジューリングするためのクラスタが存在しない場合、クエリスケジューラ及びコーディネータ２１８は、該クエリをグローバルキュー中に待機し得る。グローバリーに待機されたクエリ３０４は、待機クエリ３０８として示される。待機クエリ３０８は、ウェアハウス３０２のクラスタの１つが解放され、又は利用可能になるまで待機されたままであり得る。割り当てられるクラスタ中の１つ以上のサーバは、幾つかの実行クエリ３０６がクラスタの修復を待って待機しなければならない場合に、故障の疑いとしてマークされ得ることに留意されたい。

【0037】

図４は、一実施形態に従った、単一の実行プラットフォーム１１２上でアクティブであり得又は動作し得る複数のウェアハウスの実施形態を図示するブロック図である。多数の仮想ウェアハウス４０２、４０４、４０６が示され、各仮想ウェアハウスは複数のクラスタ４０８を含む。各クラスタ４０８は、プロセッサ４１２及びキャッシュ４１４（例えば、メモリ）を夫々含む多数の実行ノード４１０を含む。３つの仮想ウェアハウス４０２～４０６が示されるが、仮想ウェアハウスの数は動的に変更し得る。同様に、各ウェアハウス４０２～４０６中のクラスタ４０８の数、及び各クラスタ中の実行ノード４１０の数は異なる実施形態では変更し得、また、相互に対して無制限に変更し得る。更に、要求が変化した場合に新たなクラスタ４０８及び実行ノード４１０が作り出され又は除去され得るように、仮想ウェアハウス中のクラスタ４０８の数及びクラスタ中の実行ノード４１０の数は動的であり得る。

【0038】

各仮想ウェアハウス４０２～４０６は、図１に示した任意のデータ格納デバイス１１６～１２０をアクセス可能である。したがって、仮想ウェアハウス４０２～４０６は、特定のデータ格納デバイス１１６～１２０に割り当てられる必要がなく、代わりに、任意のデータ格納デバイス１１６～１２０からデータをアクセスし得る。同様に、クラスタ４０８及び実行ノード４１０の各々は、任意のデータ格納デバイス１１６～１２０からデータをアクセスし得る。幾つかの実施形態では、特定の仮想ウェアハウス又は特定の実行ノードは、特定のデータ格納デバイスに一時的に割り当てられ得るが、該仮想ウェアハウス又は実行ノードは、任意のその他のデータ格納デバイスからデータを後にアクセスし得る。

【0039】

説明される実行ノード４１０は、１つのキャッシュと１つのプロセッサとを夫々含むが、別の実施形態は、任意の数のプロセッサと任意の数のキャッシュとを含む実行ノードを含み得る。また、キャッシュは、異なる実行ノード４１０間でサイズを変更し得る。キャッシュ４１４は、ローカル実行ノードにおいて、格納プラットフォーム１１４（図１）中の１つ以上のデータ格納デバイスから検索されたデータを格納する。したがって、キャッシュは、遠隔格納システムからデータを一貫して検索するプラットフォームに生じるボトルネックの問題を削減又は取り除く。遠隔格納デバイスからデータを繰り返しアクセスすることに代えて、本明細書に記載されるシステム及び方法は、著しく速く且つ上で論じたボトルネックの問題を避ける実行ノード中のキャッシュからデータをアクセスする。幾つかの実施形態では、キャッシュは、キャッシュされたデータへの速いアクセスを提供する高速メモリデバイスを使用して実装される。各キャッシュは、格納プラットフォーム１１４中の任意の格納デバイスからのデータを格納することができる。

【0040】

更に、キャッシュリソース及びコンピューティングリソースは異なる実行ノード間で変更し得る。例えば、ある実行ノードは、顕著なコンピューティングリソースと最小のキャッシュリソースとを含み得、顕著なコンピューティングリソースを必要とするタスクに実行ノードを役立たせる。別の実行ノードは、顕著なキャッシュリソースと最小のコンピューティングリソースとを含み得、大量のデータのキャッシングを必要とするタスクにこの実行ノードを役立たせる。幾つかの実施形態では、特定の実行ノードと関連付けられるキャッシュリソース及びコンピューティングリソースは、実行ノードにより実行される予想タスクに基づいて、実行ノードが作り出される時に決定される。

【0041】

また、特定の実行ノードと関連付けられるキャッシュリソース及びコンピューティングリソースは、実行ノードにより実行されるタスクの変化に基づいて時間と共に変化し得る。例えば、実行ノードにより実行されるタスクがプロセッサにより多くの負担をかける場合、該特定の実行ノードにはより多くのプロセッサが割り当てられ得る。同様に、実行ノードにより実行されるタスクがより大きなキャッシュ容量を必要とする場合、該実行ノードにはより多くのキャッシュリソースが割り当てられ得る。

【0042】

仮想ウェアハウス４０２～４０６は同じ実行プラットフォーム１１２と関連付けられるが、仮想ウェアハウスは、多数の地理的位置に多数のコンピューティングシステムを使用して実装され得る。例えば、仮想ウェアハウス４０２は、第１の地理的位置にコンピューティングシステムにより実装され得るが、仮想ウェアハウス４０４及び４０６は、第２の地理的位置に別のコンピューティングシステムにより実装される。幾つかの実施形態では、これらの異なるコンピューティングシステムは、１つ以上の異なるエンティティにより維持されるクラウドベースのコンピューティングシステムである。

【0043】

また、各仮想ウェアハウスは、多数のクラスタ４０８を有するものとして図４に示される。各仮想ウェアハウスと関連付けられたクラスタ４０８は、多数の地理的位置に又は異なるアベイラビリティゾーン内に多数のコンピューティングシステムを使用して実装され得る。例えば、仮想ウェアハウス４０２の特定のインスタンスは、特定の地理的位置のあるコンピューティングプラットフォーム上に実行ノード４１０と共にクラスタ４０８を実装し、別の地理的位置の異なるコンピューティングプラットフォームにその他のクラスタ４０８及び実行ノード４１０を実装する。仮想ウェアハウス４０２～４０６はまたフォールトトレラントである。例えば、ある仮想ウェアハウス又は実行ノード４１０では、該仮想ウェアハウス又は実行ノードは、同じ又は異なる地理的位置で即座に修復される。

【0044】

特定の実行プラットフォーム１１２は、任意の数の仮想ウェアハウス４０２～４０６を含み得る。また、特定の実行プラットフォーム中の仮想ウェアハウスの数は、追加の処理及び／又はキャッシュリソースが必要である場合に新たな仮想ウェアハウスが作り出されるように動的である。同様に、既存の仮想ウェアハウスは、該仮想ウェアハウスと関連付けられたリソースがもはや必要でない場合に削除され得る。

【0045】

図５は、多数の分散された仮想ウェアハウス及び実行プラットフォーム群を有する別の例示的動作環境５００を示すブロック図を説明する。環境５００は、実行プラットフォーム群１ ５０４及び実行プラットフォーム群２ ５０６とデータ通信ネットワーク５０２を通じて通信するリソースマネージャ１０２を含む。実行プラットフォーム群１ ５０４は、２つのクラスタ、具体的には、第１の仮想ウェアハウス５０８に対するクラスタＡと第２の仮想ウェアハウス５１０に対するクラスタＡとを含む。実行プラットフォーム群２ ５０６は２つの追加のクラスタ、具体的には、第１の仮想ウェアハウス５１４に対するクラスタＢと第２の仮想ウェアハウス５１６に対するクラスタＢとを含む。リソースマネージャ１０２は、（実行プラットフォーム群５０４、５０６の何れの一部でもない）第１の仮想ウェアハウス５１２のクラスタＣともデータ通信ネットワーク５０２を通じて通信する。

【0046】

実行プラットフォーム群５０４及び５０６と第１の仮想ウェアハウス５１２に対するクラスタＣとは、データ通信ネットワーク５１８を通じてデータベース５２０、５２２、及び５２４と通信する。幾つかの実施形態では、データ通信ネットワーク５０２及び５１８は、同じネットワーク、又は１つ以上の重複するネットワークの組み合わせである。環境５００は、データベース５２０～５２４中にデータを格納又は検索するための、多数のウェアハウスの多数のクラスタ５０８～５１６に渡るユーザデータ格納及び検索リクエストをリソースマネージャ１０２が調整できるようにする。実行プラットフォーム群５０４及び５０６と第１の仮想ウェアハウス５１２に対するクラスタＣとは、同じ又は異なる地理的領域に配置され得、又は同じ又は異なるアベイラビリティゾーンに配置され得る。また、実行プラットフォーム群５０４及び５０６は、同じエンティティにより、又は異なるエ ンティティにより実装され得る。

【0047】

本明細書に記述されるシステム及び方法は、コンピューティング（又は処理）リソースとは別のサービスとしてデータが格納及びアクセスされ得るようにする。たとえ実行プラットフォームからコンピューティングリソースが何ら要求されていなかったとしても、遠隔データ源からのデータのリロードを必要とすることなくデータは仮想ウェアハウスに入手可能である。記述されるシステム及び方法は、何れの種類のデータでも有用である。特定の実施形態では、データは、構造化された最適なフォーマット中に格納される。コンピューティングサービスからのデータ格納／アクセスサービスの分離も、異なるユーザ及び群の間でのデータの共有を簡易化する。本明細書で論じられるように、各仮想ウェアハウスは、その他の仮想ウェアハウスが同じデータにアクセスしている同時であっても、アクセス許可を有する任意のデータにアクセスし得る。このアーキテクチャは、ローカルキャッシュ中に格納された何れの実データなしにクエリを実行することを支持する。本明細書に記述されるシステム及び方法は、トランスペアレントな動的データ移動を可能にし、それは、システムのユーザにトランスペアレントな方法で、遠隔格納デバイスからローカルキャッシュへデータを必要に応じて移動する。更に、コンピューティングサービスからのデータ格納サービスの分離に起因して何れの仮想ウェアハウスも何れのデータにアクセスできるので、このアーキテクチャは、従来のデータ移動なしにデータの共有を支持する。

【0048】

更に、環境５００は、多数の地理的位置又はアベイラビリティゾーンに渡る単一の仮想ウェアハウスの拡散を可能にする。例えば、クラスタ５０８、５１２、及び５１４は、同じ仮想ウェアハウス（第１の仮想ウェアハウス）に全て属するが、異なる地理的領域又はアベイラビリティゾーンに配置され得る。停電又は故障は地理的領域又はアベイラビリティゾーンに渡って起き得るため、フォールトトレラントの向上が実現され得る。例えば、あるアベイラビリティゾーンの問題が異なるアベイラビリティゾーンへ拡散する可能性が僅かにあるか全くないように、アベイラビリティゾーンは、クラウドサービス（計算又は格納）プロバイダによって実装されることがある。したがって、同じウェアハウス内にあるが異なるアベイラビリティゾーンにあるクラスタは、何ら利用可能な実行又は計算ノードなくウェアハウスが残される可能性を顕著に減少させ得る。

【0049】

一実施形態では、本明細書に開示されるマルチクラスタウェアハウスの実施形態は、特殊なデータ定義言語（ＤＤＬ）を使用し得る。以下は、マルチクラスタウェアハウスのＤＤＬの一部であり得るコマンド又は命令の幾つかの例である。
□ create warehouse single_cluster size=xlarge; // this will create a single cluster warehouse
□ create warehouse multi_cluster size=xlarge max_cluster_count=3 min_cluster_count=1;
// this will create an x-large 3 cluster warehouse. Only one cluster will be sta rted by default
□ create warehouse multi_cluster size=xlarge max_cluster_count=3 min_cluster_count=2; // this will create an x-large warehouse with 2 clusters initially resumed
□ create warehouse multi_cluster size=xlarge max_cluster_count=3 min_cluster_count=3; // this will create an x-large warehouse with all clusters resumed
□ Note that the resource manager would try to make use of all availability zones, one per cluster. The availability zone to use for each cluster may be implemented by an infrastructure management system
□ alter warehouse <warehouse_name> set warehouse_size=<size>: allows one to change the size of the warehouse. If this warehouse is started, all clusters in the warehouse will be resized. The code to implement this instruction may include a resize operation for each cluster.
□ alter warehouse <warehouse_name> set max_cluster_count=<count> this will add or remove clusters from an existing warehouse. Internally clusters may be numbered so this operation will either add new clusters at the end of the range or remove clusters starting from the end of the range. If new clusters are created, they will be created in a suspended state. If clusters are removed and these clusters are active, they will first be inactivated (quiesced) to allow running queries to terminate.
□ drop warehouse <warehouse_name> drop warehouse and all associated clusters. Clusters will be inactivated (quiesced) before dropping them.

【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】

例１２では、例１０～例１１の何れかにおいて現在の作業量が複数の計算クラスタよりも少数の計算クラスタによってサービス可能であるか否かを判定することは、性能メトリックに合致しながら複数のクラスタよりも少数の計算クラスタによって現時点に至る期間の履歴的作業量がサービス可能であったか否かを判定することを含む。少なくとも１つの計算クラスタを廃止することは、複数の計算クラスタよりも少数の計算クラスタによってその期間の履歴的作業量がサービス可能であったとの判定に応答して廃止することを含む。

【0083】

例１３では、例１～例１２の何れかにおいて仮想ウェアハウスに対するクエリを複数の計算クラスタの各々に提供することは、クエリが起きたセッションに基づいてクエリをルーティングすることを含む。

【0084】

例１４では、例１～例１３の何れかにおいて仮想ウェアハウスに対するクエリを複数の計算クラスタの各々に提供することは、複数の計算クラスタの各々の作業量に基づいてクエリをルーティングすることを含む。

【0085】

例１５では、例１～例１４の何れかにおいて複数の計算クラスタを割り当てることは、異なるアベイラビリティゾーン中の少なくとも２つの計算クラスタを割り当てることを含む。

【0086】

例１６は、例１～１５の何れかのような方法を実行するための手段を含む装置である。

【0087】

例１７は、実行する場合に、例１～例１６の何れかの方法を実装し、又は例１～例１６の何れかの装置を実現する機械可読命令を含む機械可読ストレージである。

【0088】

本明細書のフロー図及びブロック図は、本開示の様々な実施形態に従ったシステム、方法、及びコンピュータプログラム製品の可能的実装のアーキテクチャ、機能、及び動作を説明する。これに関して、フロー図又はブロック図の各ブロックは、指定された論理的機能を実装するための１つ以上の実行可能な命令を含むコードのモジュール、セグメント、又は一部を表し得る。ブロック図及び／又はフロー図の各ブロック、並びにブロック図及び／又はフロー図の中のブロックの組み合わせは、特定の機能又は行為を実行する専用のハードウェアベースのシステム、又は専用ハードウェアとコンピュータ命令との組み合わせにより実装され得ることも留意すべきである。これらのコンピュータプログラム命令はまた、フロー図及び／又はブロック図の１つ以上のブロックで指定される機能／行為を実装する命令手段を含む製造物をコンピュータ可読媒体中に格納された命令が生み出すように、特定の方法で機能するようにコンピュータ又はその他のプログラム可能データ処理装置に指示し得るコンピュータ可読媒体中に格納され得る。

【0089】

本明細書に記述されるシステム及び方法は、新たなデータ処理プラットフォーム、方法、システム、及びアルゴリズムを使用して、自在かつ拡大縮小可能なデータウェアハウスを提供する。幾つかの実施形態では、記述されるシステム及び方法は、クラウドベースの格納リソース及びコンピューティングリソース等を支持するクラウド基盤を活用する。例示的なクラウドベースの格納リソースは、低コストでオンデマンドで利用可能な顕著な格納容量を提供する。更に、これらのクラウドベースの格納リソースは、フォールトトレラントで高度に拡大縮小可能であり得、それらは、私的なデータ格納システムで達成するのにはコストがかかり得る。例示的なクラウドベースのコンピューティングリソースは、オンデマンドで利用可能であり、リソースの実際の使用レベルに基づいて価格設定され得る。典型的には、クラウド基盤は、速やかに、動的に発展し、設定され、且つ廃止される。

【0090】

記述されるシステム及び方法では、データ格納システムは、ＳＱＬ（構造化クエリ言語）ベースの関連データベースを利用する。しかしながら、これらのシステム及び方法は、任意のデータ格納アーキテクチャを使用して、且つデータベース内でデータを格納及び検索するための任意の言語を使用して、任意の種類のデータベースに適用可能である。本明細書に記述されるシステム及び方法は、異なる顧客／クライアント間及び同じ顧客／クライアント内の異なるユーザ間でコンピューティングリソース及びデータの分離を支持するマルチテナントシステムをも提供し得る。

【0091】

様々な技術、又は幾つかの態様若しくはその一部は、フロッピーディスク、ＣＤ－ＲＯＭ、ハードドライブ、非一時的コンピュータ可読格納媒体、又は任意のその他の機械可読格納媒体等の有形媒体中に具体化されたプログラムコード（例えば、命令）の形を取り得、ここで、プログラムコードがコンピュータ等の機械にロードされ実行される場合に、該機械は様々な技術を行うための装置になる。プログラム可能コンピュータ上のプログラム実行コードのケースでは、コンピューティングデバイスは、プロセッサ、プロセッサにより読み出し可能な格納媒体（揮発性及び不揮発性のメモリ並びに／又は格納素子を含む）、少なくとも１つの入力デバイス、及び少なくとも１つの出力デバイスを含み得る。揮発性及び不揮発性のメモリ並びに／又は格納素子は、ＲＡＭ、ＥＰＲＯＭ、フラッシュドライブ、光ドライブ、磁気ハードドライブ、又は電子データを格納するための別の媒体であり得る。本明細書に記述される様々な技術を実装又は利用し得る１つ以上のプログラムは、アプリケーションプログラミングインタフェース（ＡＰＩ）及び再利用可能制御等を使用し得る。そうしたプログラムは、コンピュータシステムと通信するための高水準な手続き又はオブジェクト指向のプログラミング言語で実装され得る。しかしながら、プログラムは、必要に応じてアセンブリ又は機械言語で実装され得る。何れのケースでも、言語は、コンパイル又は翻訳された言語であり得、ハードウェア実装と結合され得る。

【0092】

この明細書に記述される機能部の多くは１つ以上のコンポーネントとして実装され得、それは、それらの実装独立をより具体的に強調するために使用される用語であることを理解すべきである。例えば、コンポーネントは、カスタム超大規模集積（ＶＬＳＩ）回路若しくはゲートアレイを含むハードウェア回路、論理チップ等の既製品半導体、トランジスタ、又はその他の個別部品として実装され得る。コンポーネントはまた、フィールドプログラマブルゲートアレイ、プログラム可能アレイ論理、又はプログラム可能論理デバイス等のプログラム可能ハードウェアデバイスに実装され得る。

【0093】

コンポーネントはまた、様々な種類のプロセッサによる実行用のソフトウェアに実装され得る。実行可能コードの識別コンポーネントは、例えば、コンピュータ命令の１つ以上の物理的又は論理的ブロックを含み得、それは、例えば、オブジェクト、手順、又は機能として組織化され得る。それにもかかわらず、識別コンポーネントの実行可能性は、相互に物理的に配置される必要がないが、論理的に相互に結合される場合に、コンポーネントを含み且つ該コンポーネントの規定された目的を実現する異なる位置に格納された異種の命令を含み得る。

【0094】

実際、実行可能コードのコンポーネントは、単一の命令又は多数の命令であり得、異なるプログラムの中で幾つかの異なるコードセグメントに渡る分散もされ得る。同様に、運用データは、コンポーネント内に本明細書で識別及び説明され得、任意の適切な形式で具体化され得、任意の適切な種類のデータ構造体内に組織化され得る。運用データは、単一のデータセットとして収集され得、又は異なる格納デバイスに渡ることを含む異なる位置に渡って分散され得、少なくとも部分的には、単にシステム又はネットワーク上の電子信号として存在し得る。コンポーネントは、パッシブ又はアクティブであり得、所望の機能を実行するように動作可能なエージェントを含む。

【0095】

この明細書を通じて“例”との言及は、該例と併せて記述される特定のフィーチャ、構造体、又は特徴が本開示の少なくとも１つの実施形態に含まれることを意味する。したがって、この明細書を通じた様々な位置における句“例では”の出現は、必ずしも全てが同じ実施形態に言及しない。

【0096】

本明細書で使用されるように、複数の項目、構造的要素、組成上の要素、及び／又は材料は、便宜上、共通のリストで提示され得る。しかしながら、これらのリストは、リストの各要素が別々のユニークな要素として独立して識別されるように解釈されるべきである。したがって、そうしたリストの個々の要素は、正反対に示すことなく共通のグループ内のその提示に基づいて、単に同じリストの任意のその他の要素の事実上の均等物として何ら解釈されるべきではない。また、本開示の様々な実施形態及び例は、それらの様々なコンポーネントに対する代替案と共に本明細書に言及され得る。そうした実施形態、例、及び代替案は、相互の事実上の均等物として解釈されるべきではないが、本開示の別々の自律的な表現として解釈されるべきことを理解される。

【0097】

明確にするために幾つかの詳細が前述されたが、その原理から逸脱することなく幾つかの変更及び修正がなされるであろう。本明細書に記述された処理及び装置の両方を実装する多くの別な方法があることに留意すべきである。したがって、本実施形態は、例証であって非限定的に考慮されるべきである。

【0098】

本開示の基礎となる原理から逸脱することなく上述した実施形態の詳細に多くの変更がなされ得ることを当業者は認めるであろう。本開示の範囲は、それ故、以下の請求項によ ってのみ決定されるべきである。

【図1】

【図2】

【図3】

【図4】

【図5】

【図6】

【図7】

【図8】

【図9】

【図10】