(57)【要約】マルチクラスタウェアハウスのための方法は、仮想ウェアハウスの一部として複数の計算クラスタを割り当てることを含む。計算クラスタは、１つ以上のクラウド格納リソース中の１つ以上のデータベースに対してアクセスしクエリを実行するために使用される。方法は、複数の計算クラスタの各々に仮想ウェアハウスに対するクエリを提供することを含む。仮想ウェアハウスの複数の計算クラスタの各々は、コンピューティング負荷が異なるクラスタに分散するように複数のクエリを受信する。方法はまた、複数の計算クラスタの作業量に基づいて、必要に応じて、動的に、仮想ウェアハウスに計算クラスタを追加し、仮想ウェアハウスから計算クラスタを除去することを含む。【選択図】図１
2019519026.tif 000002
【特許請求の範囲】
【請求項１】
１つ以上のクラウド格納リソース中の１つ以上のデータベースに対してアクセスしクエリを実行するために仮想ウェアハウスの一部として複数の計算クラスタを割り当てる手段と、
前記複数の計算クラスタの各々に前記仮想ウェアハウスに対するクエリを提供する手段であって、ここで、複数のクエリは、前記仮想ウェアハウスの前記複数の計算クラスタの各々に提供され、
前記複数の計算クラスタの作業量に基づいて、必要に応じて、動的に、前記仮想ウェアハウスに計算クラスタを追加し、前記仮想ウェアハウスから計算クラスタを除去する手段と
を含むシステム。
【請求項２】
前記複数の計算クラスタは、計算クラスタを動的に追加及び除去するための前記手段が前記１つ以上のクラウド格納リソースを増加又は減少させることなく計算クラスタの数を動的に拡大及び縮小するように、前記１つ以上のクラウド格納リソースとは無関係に割り当てられる、請求項１に記載のシステム。
【請求項３】
前記作業量に基づいて、動的に、前記仮想ウェアハウスに計算クラスタを追加し、前記仮想ウェアハウスから計算クラスタを除去する前記手段は、
クエリに対する性能メトリックに合致しつつ前記クエリが処理され得るか否かを判定する手段と、
現在割り当てられた１つ以上の計算クラスタが前記性能メトリックに合致するように現在の作業量と組み合わさった前記クエリができないとの判定に応答して、新たな計算クラスタの起動を誘発する手段と
を含む、請求項１に記載のシステム。
【請求項４】
前記作業量に基づいて、動的に、前記仮想ウェアハウスに計算クラスタを追加し、前記仮想ウェアハウスから計算クラスタを除去する前記手段は、
性能メトリックに合致しながら前記複数の計算クラスタよりも少数の計算クラスタによって現在の作業量がサービス可能であるか否かを判定する手段と、
前記複数の計算クラスタよりも少数の計算クラスタによって前記作業量がサービス可能であるとの判定に応答して、前記複数の計算クラスタの内の少なくとも１つの計算クラスタを廃止する手段と
を含む、請求項１に記載のシステム。
【請求項５】
前記複数の計算クラスタの各々に前記仮想ウェアハウスに対するクエリを提供する前記手段は、
前記クエリが起きたセッションに基づいてクエリをルーティングする手段、
クラスタの可用性に基づいてクエリをルーティングする手段、及び
クエリを実行するためのクラスタリソースの可用性に基づいてクエリをルーティングする手段
の内の１つ以上を含む、請求項１に記載のシステム。
【請求項６】
マルチクラスタウェアハウスのためのコンピュータ実装の方法であって、
１つ以上のクラウド格納リソース中の１つ以上のデータベースに対してアクセスしクエリを実行するために仮想ウェアハウスの一部として複数の計算クラスタを割り当てることと、
前記複数の計算クラスタの各々に前記仮想ウェアハウスに対するクエリを提供することであって、ここで、複数のクエリは、前記仮想ウェアハウスの前記複数の計算クラスタの各々に提供されることと、
前記複数の計算クラスタの作業量に基づいて、必要に応じて、動的に、前記仮想ウェアハウスに計算クラスタを追加し、前記仮想ウェアハウスから計算クラスタを除去することと
を含む、方法。
【請求項７】
前記複数の計算クラスタは、前記１つ以上のクラウド格納リソースを増加又は減少させることなく計算クラスタの前記数を拡大及び縮小し得るように、前記１つ以上のクラウド格納リソースとは無関係に割り当てられる、請求項６に記載のコンピュータ実装の方法。
【請求項８】
前記複数の計算クラスタに対する前記作業量を判定することを更に含み、ここで、前記作業量を判定することは、
前記複数の計算クラスタの各々に対するプロセッサリソース、及び
前記複数の計算クラスタの各々に対するメモリリソース
の１つ以上の可用性を判定することを含む、請求項６に記載のコンピュータ実装の方法。
【請求項９】
前記作業量に基づいて、動的に、前記仮想ウェアハウスに計算クラスタを追加することは、
クエリに対する性能メトリックに合致しつつ前記クエリが処理され得るか否かを判定することと、
現在割り当てられた１つ以上の計算クラスタが前記性能メトリックに合致するように現在の作業量と組み合わさった前記クエリができないとの判定に応答して、新たな計算クラスタの起動を誘発することと
を含む、請求項６に記載のコンピュータ実装の方法。
【請求項１０】
前記方法は、前記性能メトリックがクエリ毎に合致するように前記計算クラスタに向けられたクエリ毎に前記クエリが処理され得るか否かを判定することを含む、請求項９に記載のコンピュータ実装の方法。
【請求項１１】
前記性能メトリックは、顧客に認容されるサービスレベルアグリーメントを含む、請求項９に記載のコンピュータ実装の方法。
【請求項１２】
前記性能メトリックは、前記クエリが待機される最大期間を含む、請求項９に記載のコンピュータ実装の方法。
【請求項１３】
計算クラスタを動的に追加することは、所定の最大計算クラスタ数になるまで計算クラスタを追加することを含む、請求項６に記載のコンピュータ実装の方法。
【請求項１４】
計算クラスタを動的に除去することは、所定の最小計算クラスタ数になるまで計算クラスタを除去することを含む、請求項６に記載のコンピュータ実装の方法。
【請求項１５】
前記作業量に基づいて計算クラスタを除去することは、
性能メトリックに合致しつつ前記複数の計算クラスタよりも少数の計算クラスタによって現在の作業量がサービス可能であるか否かを判定することと、
前記複数の計算クラスタよりも少数の計算クラスタによって前記作業量がサービス可能であるとの判定に応答して、前記複数の計算クラスタの内の少なくとも１つの計算クラスタを廃止することと
を含む、請求項６に記載のコンピュータ実装の方法。
【請求項１６】
前記少なくとも１つの計算クラスタを廃止することは、
前記少なくとも１つの計算クラスタへの追加のクエリの提供を阻止することと、
前記少なくとも１つの計算クラスタが現在割り当てられたクエリを完了し得るようにすることと、
現在割り当てられた前記クエリを完了すると、前記少なくとも１つの計算クラスタに対応する１つ以上のリソースを解放することと
を含む、請求項１５に記載のコンピュータ実装の方法。
【請求項１７】
前記複数の計算クラスタよりも少数の計算クラスタによって現在の前記作業量がサービス可能であるか否かを判定することは、前記性能メトリックに合致しながら前記複数のクラスタよりも少数の計算クラスタによって現時点に至る期間の履歴的作業量がサービス可能であったか否かを判定することを更に含み、
前記少なくとも１つの計算クラスタを廃止することは、前記複数の計算クラスタよりも少数の計算クラスタによって前記期間の前記履歴的作業量がサービス可能であったとの判定に応答して廃止することを含む、
請求項１５に記載のコンピュータ実装の方法。
【請求項１８】
前記複数の計算クラスタの各々に前記仮想ウェアハウスに対するクエリを提供することは、前記クエリが起きたセッションに基づいてクエリをルーティングすることを含む、請求項６に記載のコンピュータ実装の方法。
【請求項１９】
前記複数の計算クラスタの各々に前記仮想ウェアハウスに対するクエリを提供することは、前記複数の計算クラスタの各々の作業量に基づいてクエリをルーティングすることを含む、請求項６に記載のコンピュータ実装の方法。
【請求項２０】
前記複数の計算クラスタを割り当てることは、異なるアベイラビリティゾーン中の少なくとも２つの計算クラスタを割り当てることを含む、請求項６に記載のコンピュータ実装の方法。
【請求項２１】
マルチクラスタ処理プラットフォームシステムであって、
データベースのデータを格納するためのクラウド格納リソースと、
前記クラウド格納リソース中の前記データベースのデータに対してアクセスしクエリを実行するためのプロセッサリソースと、
仮想ウェアハウスの一部として複数の計算クラスタを割り当て、
前記複数の計算クラスタの各々に前記仮想ウェアハウスに対するクエリを提供し、ここで、複数のクエリは、前記仮想ウェアハウスの前記複数の計算クラスタの各々に提供され、
前記複数の計算クラスタの作業量に基づいて、必要に応じて、動的に、前記仮想ウェアハウスに計算クラスタを追加し、前記仮想ウェアハウスから計算クラスタを除去する
ように構成されたリソースマネージャと
を含むシステム。
【請求項２２】
前記リソースマネージャは、１つ以上の前記クラウド格納リソースを増加又は減少させることなく計算クラスタの前記数を拡大及び縮小し得るように、前記１つ以上のクラウド格納リソースとは無関係に前記複数の計算クラスタを割り当てる、請求項２１に記載のシステム。
【請求項２３】
前記リソースマネージャは、前記複数の計算クラスタの前記作業量を判定するように更に構成され、ここで、前記リソースマネージャは、
前記複数の計算クラスタの各々に対するプロセッサリソース、
前記複数の計算クラスタの各々に対するメモリリソース、及び
特定のクエリを処理するために必要な予測最小リソース
の内の少なくとも１つ以上の可用性を判定することによって前記作業量を判定する、請求項２１に記載のシステム。
【請求項２４】
前記リソースマネージャは、
クエリに対する性能メトリックに合致しつつ前記クエリが処理され得るか否かを判定することと、
現在割り当てられた１つ以上の計算クラスタが前記性能メトリックに合致するように現在の作業量と組み合わさった前記クエリができないとの判定に応答して、新たな計算クラスタの起動を誘発することと
によって前記作業量に基づいて前記仮想ウェアハウスに計算クラスタを動的に追加するように構成される、請求項２１に記載のシステム。
【請求項２５】
前記リソースマネージャは、前記性能メトリックがクエリ毎に合致するように前記計算クラスタに向けられたクエリ毎に前記性能メトリックが合致しながら前記クエリが処理され得るか否かを判定する、請求項２４に記載のシステム。
【請求項２６】
前記リソースマネージャは、
性能メトリックに合致しながら前記複数の計算クラスタよりも少数の計算クラスタによって現在の作業量がサービス可能であるか否かを判定することと、
前記複数の計算クラスタよりも少数の計算クラスタによって前記作業量がサービス可能であるとの判定に応答して、前記複数の計算クラスタの内の少なくとも１つの計算クラスタを廃止すること
によって前記作業量に基づいて計算クラスタを動的に除去するように構成される、請求項２１に記載の方法。
【請求項２７】
前記リソースマネージャは、
前記少なくとも１つの計算クラスタへの追加のクエリの提供を阻止することと、
前記少なくとも１つの計算クラスタが現在割り当てられたクエリを完了し得るようにすることと、
現在割り当てられた前記クエリを完了すると、前記少なくとも１つの計算クラスタに対応する１つ以上のリソースを解放することと
によって前記少なくとも１つの計算クラスタを廃止するように構成される、請求項２６に記載のシステム。
【請求項２８】
前記複数の計算クラスタよりも少数の計算クラスタによって現在の前記作業量がサービス可能であるか否かを判定することは、前記性能メトリックに合致しながら前記複数のクラスタよりも少数の計算クラスタによって現時点に至る期間の履歴的作業量がサービス可能であったか否かを判定することを更に含み、
前記少なくとも１つの計算クラスタを廃止することは、前記複数の計算クラスタよりも少数の計算クラスタによって前記期間の前記履歴的作業量がサービス可能であったとの判定に基づいて廃止することを含む、
請求項２６に記載のシステム。
【請求項２９】
前記複数の計算クラスタの各々に前記仮想ウェアハウスに対するクエリを提供することは、前記クエリが起きたセッションに基づいてクエリをルーティングすることを含む、請求項２１に記載のシステム。
【請求項３０】
１つ以上のクラウド格納リソース中の１つ以上のデータベースに対してアクセスしクエリを実行するために仮想ウェアハウスの一部として複数の計算クラスタを割り当てることと、
前記複数の計算クラスタの各々へ前記仮想ウェアハウスに対するクエリを転送することであって、ここで、複数のクエリは前記仮想ウェアハウスの前記複数の計算クラスタの各々に提供されること
を１つ以上のプロセッサにより実行される場合に、前記プロセッサにさせ、ここで、
前記複数の計算クラスタの各々へ前記仮想ウェアハウスに対するクエリを転送することは、同じセッションからのクエリがデフォルトにより同じ計算クラスタにルーティングされるように、前記クエリが起きた前記セッションに基づいてクエリをルーティングすることを含む、
命令を格納する非一時的コンピュータ可読格納媒体。
【請求項３１】
前記命令は、前記１つ以上のプロセッサに、前記複数の計算クラスタの各々の作業量に基づいて前記複数の計算クラスタの各々へ前記仮想ウェアハウスに対するクエリを転送させる、請求項３０に記載のコンピュータ可読格納媒体。
【請求項３２】
前記命令は更に、前記１つ以上のプロセッサに、異なるアベイラビリティゾーン中の少なくとも２つの計算クラスタを割り当てさせる、請求項３０に記載のコンピュータ可読格納媒体。
【請求項３３】
前記命令は更に、前記１つ以上のプロセッサに、前記複数の計算クラスタの作業量に基づいて、必要に応じて、動的に、前記仮想ウェアハウスに計算クラスタを追加させ、前記仮想ウェアハウスから計算クラスタを除去させる、請求項３０に記載のコンピュータ可読格納媒体。
【請求項３４】
前記命令は、前記１つ以上のプロセッサに、前記１つ以上のクラウド格納リソースを増加又は減少させることなく計算クラスタの数を拡大及び縮小し得るように、前記１つ以上のクラウド格納リソースとは無関係に前記複数の計算クラスタを割り当てさせる、請求項３０に記載のコンピュータ可読格納媒体。
【請求項３５】
前記命令は、前記１つ以上のプロセッサに、
クエリに対する性能メトリックに合致しつつ前記クエリが処理され得るか否かを判定することと、
現在割り当てられた１つ以上の計算クラスタが前記性能メトリックに合致するように現在の作業量と組み合わさった前記クエリができないとの判定に応答して、新たな計算クラスタの起動を誘発することと
によって前記作業量に基づいて前記仮想ウェアハウスに計算クラスタを動的に追加させる、請求項３０に記載のコンピュータ可読格納媒体。
【請求項３６】
前記命令は、前記１つ以上のプロセッサに、
性能メトリックに合致しながら前記複数の計算クラスタよりも少数の計算クラスタによって現在の作業量がサービス可能であるか否かを判定することと、
前記複数の計算クラスタよりも少数の計算クラスタによって前記作業量がサービス可能であるとの判定に応答して、前記複数の計算クラスタの内の少なくとも１つの計算クラスタを廃止することと
によって、前記作業量に基づいて前記仮想ウェアハウスから計算クラスタを動的に除去させる、請求項３０に記載のコンピュータ可読格納媒体。
【発明の詳細な説明】
【技術分野】
【０００１】
本出願は、２０１６年４月２８日に出願された名称“マルチクラスタウェアハウス”の米国仮出願番号６２／３２８，９４３の優先権を主張し、その全体が参照により本明細書に組み込まれる。
【０００２】
本開示は、マルチクラスタウェアハウスのためのシステム、方法、及びデバイスに関する。
【背景技術】
【０００３】
コンピューティングの利用においては、データの格納及びアクセスのためにデータベースが広く使用される。データベースは、クエリを使用して読み出され得、変更され得、又は削除され得るデータを含む又は参照する１つ以上のテーブルを含み得る。データベースは、１つ以上のテーブル内に小さな又は極めて大きなデータセットを格納することができる。このデータはウェブサイト又はアプリケーションプログラムインタフェース（ＡＰＩ）介する等して、団体の様々なユーザによりアクセスされ得、又は公的ユーザに提供するために使用され得る。コンピューティング及び格納のリソース、及びそれらの基礎をなすアーキテクチャの両方は、所望のデータベースの性能を達成するのに大きな役割を果たし得る。
【図面の簡単な説明】
【０００４】
本開示の非限定的で非網羅的な実施形態が以下の図面を参照しながら記述され、特段の定めがない限り様々な図を通じて同様の参照数字が同様の部分に付される。
【図１】本明細書に記述されるシステム及び方法の例示的実施形態に従った処理プラットフォームを図示するブロック図である。
【図２】一実施形態に従った、リソースマネージャのコンポーネントを説明するブロック図である。
【図３】一実施形態に従った、マルチクラスタウェアハウスのスケジューリングを図示するブロック図である。
【図４】一実施形態に従った、単一の実行プラットフォーム上に提供され得る複数のウェアハウスを図示するブロック図である。
【図５】一実施形態に従った、分散された多数の仮想ウェアハウスを有するシステムを説明するブロック図である。
【図６】一実施形態に従った、マルチクラスタウェアハウスのための方法を説明する概略的フローチャート図である。
【図７】一実施形態に従った、マルチクラスタウェアハウス中のコンピュータクラスタを動的に追加するための方法を説明する概略的フローチャート図である。
【図８】一実施形態に従った、マルチクラスタウェアハウス中のコンピュータクラスタを動的に除去するための方法を説明する概略的フローチャート図である。
【図９】一実施形態に従った、マルチクラスタウェアハウスのための方法を説明する概略的フローチャート図である。
【図１０】本明細書に開示される処理及びシステムの少なくとも１つの実施形態と一致する例示的コンピューティングデバイスを図示するブロック図である。
【発明を実施するための形態】
【０００５】
本開示は、マルチクラスタウェアハウスを提供及び管理するためのシステム、方法、及びデバイスに向けられる。ウェアハウスは、分析クエリの取り扱いにおいて接続又は協働される幾つかのサーバである。幾つかのウェアハウスでは、計算及び格納のリソースは相互に接続及び割り当てられる。本明細書に開示される少なくとも幾つかの実施形態では、計算リソースは、独立して割り当てられ、格納リソースとは別に拡大縮小が可能である。幾つかのケースでは、ウェアハウスは、サービスを提供するために一体となって働き得る１つ以上のクラスタ及び／又は１つ以上のサーバノードのクラスタを含む。出願人は、マルチクラスタウェアハウスのためのアーキテクチャ、方法、アルゴリズム、及びシステムを開発し、本明細書に提示する。
【０００６】
一実施形態に従うと、マルチクラスタウェアハウスのための方法は、仮想ウェアハウスの一部として複数の計算クラスタを割り当てることを含む。計算クラスタは、１つ以上のクラウド格納リソース中の１つ以上のデータベースに対してアクセスしクエリを実行するために使用され得る。方法は、仮想ウェアハウスに対するクエリを複数の計算クラスタの各々に提供することを含む。例えば、仮想ウェアハウスの複数の計算クラスタの各々は、コンピューティング負荷が異なるクラスタに分散するように複数のクエリを受信し得る。方法はまた、複数の計算クラスタの作業量に基づいて、必要に応じて、動的に、仮想ウェアハウスに計算クラスタを追加し、仮想ウェアハウスから計算クラスタを除去することを含み得る。
【０００７】
マルチクラスタウェアハウスは、同時実行性及び可用性（availability）において顕著な向上を提供し得る。例えば、ウェアハウスは、一般的に、サイズが該ウェアハウスのサイズである単一のクラスタのみを含む。例えば、大きなウェアハウスは、８つのサーバノードの単一のクラスタを含み得る。マルチクラスタウェアハウスは、多数のクラスタを有する単一のウェアハウスの創造を可能にし得る。ウェアハウス内の各クラスタは８つのサーバノードを含み得る。したがって、マルチクラスタウェアハウスは、同じサイズの単一のクラスタウェアハウスにより提供される同時実行レベルの３倍を支持し得る。このアーキテクチャは、本明細書で更に論じられるように、コンピューティングリソースの拡大縮小を可能にもしつつ、単一のウェアハウスに対して高レベルの同時実行性を可能にし得る。
【０００８】
異なるアベイラビリティゾーン（availability zone）中に異なるクラスタを設置することによって、マルチクラスタウェアハウスにおいて可用性の向上も達成され得る。例えば、各ウェアハウスクラスタは（異なるＡｍａｚｏｎ（登録商標）のアベイラビリティゾーン内等の）クラウドプロバイダの異なるアベイラビリティゾーン中に割り当てられるので、マルチクラスタウェアハウスは、誤り回復力の向上を提供する。それ故、マルチクラスタウェアハウスは、単一のクラスタウェアハウスと比較して高い可用性を有する。更に、クエリは、メモリ又はローカルなディスクベースのストレージ中に（例えば、キャッシュ中に）関連するデータセグメントが既に存在する最適クラスタにルーティングされ得る。例えば、マルチクラスタウェアハウスのための方法は、クエリが起きたセッションに基づいてクエリをルーティングすることを含み得る。同じセッションからのクエリを同じクラスタに提供することによって、クエリに必要とされるデータがメモリ中に既に存在し且つクラウド格納リソースからデータを検索する必要性を省き得る可能性を増加させる。同時実行性及び可用性の向上によって、ユーザは、その他の従来の単一のクラスタデータベースアーキテクチャでは達成することが困難又は不可能であろう応答時間及び可用性の向上を経験し得る。
【０００９】
同時実行性及び可用性の向上に加えて、計算リソースの自動的な拡大縮小の顕著な変更が可能である。例えば、少なくとも幾つかの実施形態は、クラウドストレージとは別の計算リソースの割り当てを提供する。したがって、マルチクラスタウェアハウスは、変化しない又はクエリの作業量と比べて非常に遅く変化しているデータに対してクエリを依然行いつつ、大きな作業量の変動に適応するために計算クラスタの数を拡大又は縮小し得る。
【００１０】
ウェアハウスが作業量を処理できず、クエリを待機（queue）させなければならない（或いは、許容される時間の長さよりも長くクエリを待機させる）場合に新たな又はサスペンドしたクラスタの自動的なレジューム又は開始が実行され得る。クラスタ上の総リソース消費が閾値を越えているため、クエリは待機させられ得る。例えば、リソース消費は、メモリ負荷とコンピューティング又は処理負荷とに対するパラメータを含み得る。一実施形態では、パラメータは、新たなクラスタがレジューム又は供給されるべき前にクエリがどのくらいの長さを待機し得るかに対して制御する。新たなクラスタがレジュームされると直ぐに、クエリは、新たなクラスタ上で実行されるようにスケジューリングされ得る。これは、新たなクエリと既に待機したクエリとに適用される。
【００１１】
一実施形態では、マルチクラスタウェアハウスのための方法は、作業量に基づいて仮想ウェアハウスに計算クラスタを動的に追加することを含み得る。方法は、クエリに対する性能メトリックに合致しつつクエリが処理され得るか否かを判定することを含み得る。現在の作業量と組み合わせたクエリが、現在割り当てられた１つ以上の計算クラスタを性能メトリックに合致するようにできない場合、方法は、新たな計算クラスタの起動を誘発することを含み得る。幾つかの実施形態では、新たなクラスタは、必要とされる性能メトリックよりも単一のクエリが少なくならないことを確保するのに十分速く割り当てられ得る。
【００１２】
マルチクラスタウェアハウスのアクティブクラスタの自動的なサスペンド又は廃止は、作業量のリソース消費が十分低いために、該クラスタのサスペンドが過去に実行された何れのクエリもＮ分待機（又は閾値時間よりも長く待機）させなかったであろう場合に実行され得る。クエリの待機又はクエリに対する待機時間は、使用され得る性能メトリックの一例に過ぎない。一実施形態では、マルチクラスタウェアハウスのための方法は、作業量に基づいて計算クラスタを除去することを含み得る。方法は、性能メトリックに合致しつつ複数の計算クラスタよりも少数の計算クラスタにより現在の作業量がサービス可能であるか否かを判定することを含み得る。方法は、複数の計算クラスタよりも少数の計算クラスタにより作業量がサービス可能であるとの判定に応答して、複数の計算クラスタの内の少なくとも１つの計算クラスタを廃止（又はサスペンド）することを含み得る。
【００１３】
一実施形態に従えば、クラスタの自動的な供給又は除去と、ウェアハウス内の異なるクラスタへのクエリのルーティングとは、サービスとして、強力で柔軟なマルチクラスタウェアハウスの一部に使用され得る。
【００１４】
本開示の実施形態と一致するシステム及び方法の詳細な記述が以下に提供される。幾つかの実施形態が記述されるが、この開示は、何れかの１つの実施形態に限定されないが、代わりに、多数の代替物、変形物、及び均等物を包含することを理解すべきである。また、本明細書に開示される実施形態の理解を通じて提供するために多数の具体的詳細が以下の説明で記述されるが、幾つかの実施形態はそれらの幾つか又は全ての詳細なしに実施され得る、更に、明確にする目的のため、関連する技術で周知の幾つかの技術項目は、開示を不必要に不明確にすることを避けるために詳細には記述されていない。
【００１５】
図に向けると、図１は、一実施形態に従った、マルチクラスタウェアハウスを提供及び／又は管理するための処理プラットフォーム１００を説明するブロック図である。処理プラットフォーム１００は、多数のユーザ１０４、１０６、及び１０８によりアクセス可能なリソースマネージャ１０２を含む。リソースマネージャ１０２は、本明細書ではデータベースサービスマネージャとも称され得る。幾つかの実装では、リソースマネージャ１０２は、処理プラットフォーム１００のデータ又はサービスへのアクセスを要望する任意の数のユーザを支持し得る。ユーザ１０４〜１０８は、例えば、データの格納及び検索のクエリ及びリクエストを提供するエンドユーザ、本明細書に記述されるシステム及び方法を管理するシステム管理者、データベースと相互作用するソフトウェアアプリケーション、及びリソースマネージャ１０２と相互作用するその他のコンポーネント／デバイスを含み得る。
【００１６】
リソースマネージャ１０２は、処理プラットフォーム１００内のシステム及びコンポーネントの動作を支持する様々なサービス及び機能を提供し得る。リソースマネージャ１０２は、データ処理プラットフォーム１００を通じて格納されたデータと関連付けられるメタデータ１１０を格納するためのアクセスを有する。リソースマネージャ１０２は、ユーザクエリを最適化するためにメタデータ１１０を使用し得る。幾つかの実施形態では、メタデータ１１０は、遠隔データ格納システム中に格納されたデータとローカルキャッシュ（例えば、実行プラットフォーム１１２の１つ以上のクラスタ内のキャッシュ）から入手可能なデータとの概要を含む。また、メタデータ１１０は、遠隔データ格納システム及びローカルキャッシュ中にデータを整理する方法に関する情報を含み得る。メタデータ１１０は、格納デバイスから実データをロード又はアクセスすることなくデータを処理する必要があるか否かをシステム及びサービスが判定できるようにする。
【００１７】
データ処理プラットフォーム１００の一部として、メタデータ１１０は、データ操作言語（ＤＭＬ）を使用してデータを変更させる場合に収集され得、それは、任意のＤＭＬステートメントを通じて変更させ得る。データの操作の一例は、データを選択すること、更新すること、変更すること、併合すること、及びテーブル中に挿入することを含み得るが、これらに制限されない。処理プラットフォーム１００の一部として、ファイルが作り出され得、ファイル毎及びコラムベース毎にメタデータ１１０が収集され得、その後、メタデータ１１０はメタデータストア中に保存され得る。メタデータ１１０のこの収集は、データ採取中に実行され得、又はメタデータ１１０の収集は、データが採取又はロードされた後に別のプロセスとして実行され得る。実装では、メタデータ１１０は、複数のディスティンクト値、複数のヌル値、並びに最小値及び最大値をファイル毎に含み得る。実装では、メタデータは、ストリング長情報及びストリング中の文字範囲を更に含み得る。
【００１８】
リソースマネージャ１０２は更に、実行プラットフォーム１１２と通信し、それは、以下により詳細を論じるように、様々なデータ格納及びデータ検索の動作を実行する多数のコンピューティングリソースを提供する。実行プラットフォーム１１２は、特定のウェアハウスにユーザ１０４〜１０８により提供されるクエリ作業量に基づいて特定のウェアハウスに対して動的に割り当て又はサスペンドされ得る１つ以上の計算クラスタを含み得る。実行プラットフォーム１１２は、格納プラットフォーム１１４の一部である１つ以上のデータ格納デバイス１１６、１１８、及び１２０と通信する。３つのデータ格納デバイス１１６、１１８、及び１２０が図１に示されるが、実行プラットフォーム１１２は、任意の数のデータ格納デバイスと通信可能である。幾つかの実施形態では、データ格納デバイス１１６、１１８、及び１２０は、１つ以上の地理的位置に配置されたクラウドベースの格納デバイスである。例えば、データ格納デバイス１１６、１１８、及び１２０は、公的なクラウド基盤又は私的なクラウド基盤の一部であり得、又は任意のその他の種類の分散格納システムであり得る。データ格納デバイス１１６、１１８、及び１２０は、ハードディスクドライブ（ＨＤＤ）、ソリッドステートドライブ（ＳＳＤ）、ストレージクラスタ、又は任意のその他のデータ格納技術を含み得る。また、格納プラットフォーム１１４は、（Ｈａｄｏｏｐ分散ファイルシステム（ＨＤＦＳ）等の）分散ファイルシステム、及びオブジェクト格納システム等を含み得る。
【００１９】
幾つかの実施形態では、リソースマネージャ１０２とユーザ１０４〜１０８、メタデータ１１０、及び実行プラットフォーム１１２との間の通信リンクは、１つ以上のデータ通信ネットワークを介して実装され、ユーザリクエストが最適化され得るように様々なタスクを割り当てられ得る。同様に、実行プラットフォーム１１２と格納プラットフォーム１１４中のデータ格納デバイス１１６〜１２０との間の通信リンクは、１つ以上のデータ通信ネットワークを介して実装される。これらのデータ通信ネットワークは、任意の通信プロトコルと任意の種類の通信媒体とを利用し得る。幾つかの実施形態では、データ通信ネットワークは、相互に結合された２つ以上のデータ通信ネットワーク（又はサブネットワーク）の組み合わせである。別の実施形態では、これらの通信リンクは、任意の種類の通信媒体と通信プロトコルとを使用して実装される。
【００２０】
図１に示されるように、データ格納デバイス１１６、１１８、及び１２０は、実行プラットフォーム１１２と関連付けられたコンピューティングリソースから分離される。このアーキテクチャは、データ処理プラットフォーム１００にアクセスするユーザ及びシステムのデータの格納／検索要請、コンピューティング要請、及び変更要請の変化に基づいて、データ処理プラットフォーム１００への動的変更を支持する。動的変更の支持は、データ処理プラットフォーム１００内のシステム及びコンポーネントの要求の変化に応じてデータ処理プラットフォーム１００が即座に拡大縮小できるようにする。データ格納デバイスからのコンピューティングリソースの分離は、対応する大量のコンピューティングリソースを要求することなく大量のデータの格納を支持する。同様に、このリソースの分離は、利用可能なデータ格納リソースの対応する増加を要求することなく、特定時間に利用されるコンピューティングリソースの顕著な増加を支持する。
【００２１】
リソースマネージャ１０２、メタデータ１１０、実行プラットフォーム１１２、及び格納プラットフォーム１１４は、個々のコンポーネントとして図１に示される。しかしながら、リソースマネージャ１０２、メタデータ１１０、実行プラットフォーム１１２、及び格納プラットフォーム１１４の各々は、（例えば、多数の地理的位置に多数のシステム／プラットフォームに渡って分散された）分散システムとして実装され得、又は１つ以上のシステムに結合され得る。また、リソースマネージャ１０２、メタデータ１１０用のストレージ、実行プラットフォーム１１２、及び格納プラットフォーム１１４の各々は、ユーザ１０４〜１０８から受信されたリクエストの変化又はデータ処理プラットフォーム１００の変更要請に基づいて（相互に無関係に）拡大又は縮小され得る。したがって、記述される実施形態では、データ処理プラットフォーム１００は、動的であり、現在のデータ処理の要請に合致するように規則的な変更を支持する。
【００２２】
実行プラットフォーム１１２は、処理プラットフォーム１００の計算又は処理の負荷を共有し得る複数の計算クラスタ１２２、１２４、１２６を含む。一実施形態では、顧客は、（ウェアハウスの実行中及びそのサスペンド中の両方において）ウェアハウスを作り出す又はその構成を変更する場合にレンジを指定する（例えば、ｍｉｎＣｌｕｓｔｅｒＣｏｕｎｔ及びｍａｘＣｌｕｓｔｅｒＣｏｕｎｔ等の値を指定する）ことによってアクティブな（すなわち、実行している）クラスタの数を制御し得る。顧客は、ウェアハウスがその実行の度に実行する正確な数を有するように指定すること、例えば、最小クラスタカウントを最大クラスタカウントと同数にすることによって、アクティブなクラスタの正確な数を指定し得る。最小クラスタカウントよりも大きい最大クラスタカウントをユーザが指定する場合、リソースマネージャ１０２は、スループット基準を満足し費用面で効果的であるように作業量に基づいて現在のアクティブなクラスタの数を自動的に管理し得る。それ故、ウェアハウスが実行している場合はいつも、少なくとも最小クラスタカウント（ｍｉｎＣｌｕｓｔｅｒＣｏｕｎｔ）のクラスタがアクティブにされ、せいぜい最大クラスタカウント（ｍａｘＣｌｕｓｔｅｒＣｏｕｎｔ）のクラスタがアクティブにされる。リソースマネージャ１０２は、メモリ負荷及び同時実行性レベルの観点から指定された性能基準が与えられた現在の作業量を処理するために幾つのクラスタが必要とされるかを判定し得る。
【００２３】
図２は、一実施形態に従った、リソースマネージャ１０２のコンポーネントを示すブロック図を説明する。リソースマネージャ１０２は、データ格納デバイス２０６に結合されたアクセスマネージャ２０２及びキーマネージャ２０４を含む。アクセスマネージャ２０２は、本明細書に記述されるシステムに対する認証及び承認タスクを処理する。キーマネージャ２０４は、認証及び承認タスク中に使用されるキーの格納及び承認を管理する。リクエスト処理サービス２０８は、受信されたデータ格納リクエスト及びデータ検索リクエストを管理する。管理コンソールサービス２１０は、管理者及びその他のシステムマネージャによる様々なシステム及び処理へのアクセスを支持する。
【００２４】
リソースマネージャ１０２はＳＱＬコンパイラ２１２、ＳＱＬオプティマイザ２１４、及びＳＱＬエクゼキュータ２１６をも含む。ＳＱＬコンパイラ２１２は、ＳＱＬクエリをパースし、該クエリに対する実行コードを生成する。ＳＱＬオプティマイザ２１４は、処理される必要があるデータに基づいて、クエリを実行するための最良な方法を判定する。ＳＱＬエクゼキュータ２１６は、リソースマネージャ１０２により受信されたクエリに対するクエリコードを実行する、クエリスケジューラ及びコーディネータ２１８は、編集、最適化、及び実行プラットフォーム１１２へのディスパッチのために、受信されたクエリを最適なサービス又はシステムへ送信する。仮想ウェアハウスマネージャ２２０は、実行プラットフォーム１１２に実装される、マルチクラスタウェアハウスを含む多数の仮想ウェアハウスの動作を管理する。
【００２５】
また、リソースマネージャ１０２は、コンフィグレーション及びメタデータマネージャ２２２を含み、それは、遠隔データ格納デバイス中に及びローカルキャッシュ中に格納されたデータに関する情報を管理する。モニタ及び作業量アナライザ２２４は、リソースマネージャ１０２により実行された処理を監督し、実行プラットフォーム１１２中の仮想ウェアハウス及び実行ノードに渡るタスク（例えば、作業量）の分散を管理する。コンフィグレーション及びメタデータマネージャ２２２、並びにモニタ及び作業量アナライザ２２４は、データ格納デバイス２２６に結合される。
【００２６】
リソースマネージャ１０２は、トランザクション管理及びアクセス制御モジュール２２８をも含み、それは、データ格納リクエスト及びデータアクセスリクエストの処理と関連付けられる様々なタスク及びその他のアクティビティを管理する。例えば、トランザクション管理及びアクセス制御モジュール２２８は、多数のユーザ又はシステムによるデータへの一貫し且つ同期したアクセスを提供する。多数のユーザ／システムは同じデータに同時にアクセスし得るので、各ユーザ／システムがデータの現在のバージョンで作業することを確保するために、データへの変更は同期されなければならない。トランザクション管理及びアクセス制御モジュール２２８は、リソースマネージャ１０２の一か所に集中した位置での様々なデータ処理アクティビティの制御を提供する。
【００２７】
仮想ウェアハウスマネージャ２２０を更に参照しながら、マルチクラスタウェアハウス中の自動的クラスタレジューム及び自動的クラスタサスペンドが論じられる。一実施形態では、仮想ウェアハウスマネージャ２２０は、自動的クラスタレジュームを実行する。（例えば、実行プラットフォーム１１２内の）マルチクラスタウェアハウスが自動的レジュームに対してマーキングされる場合、該ウェアハウスに対する第１のクラスタは、ＳＱＬステートメントがスケジューリングされ該ウェアハウス中の全てのクラスタがサスペンド状態にある場合に自動的にレジュームされる。しかしながら、残りのクラスタを自動的にレジュームするとの決定は、作業量に基づいて実行される。これは、ａｃｔｉｖｅＣｌｕｓｔｅｒＣｏｕｎｔ＜ｍａｘＣｌｕｓｔｅｒＣｏｕｎｔであると思われ、すなわち、アクティブ／レジュームされ得るが現在サスペンドされているクラスタを有する。
【００２８】
作業量の考慮は少なくとも２つのことを含む。第一に、作業量の考慮はメモリの使用を含み得る。全てのクラスタがそれらの最大メモリ容量にあるために、クエリがスケジューリング及び待機される場合、仮想ウェアハウスマネージャ２２０は、待機が回避され得又は短縮され得るように１つ以上のクラスタをレジュームする。クラスタのレジュームには例えば分単位の少しの時間がかかり得るので、新たなクラスタがレジュームされる必要がある場合に待機が依然として生じ得る。しかしながら、仮想ウェアハウスマネージャ２２０はまた、新たなクラスタの開始中にクエリがフリーなプール上に置かれ得るように、幾つかのフリーなサーバのフリーなプールが存在することを確認し得る。また、仮想ウェアハウスマネージャ２２０は、新たなクラスタの供給を決定する前にクエリが自身で解決されるか否かを確認するために一定期間待機し得る。
【００２９】
第二に、作業量の考慮は、クラスタについての同時実行度、又は処理／コンピューティング負荷を含み得る。全てのアクティブクラスタ上での同時実行度が高い場合、仮想ウェアハウスマネージャ２２０は、クエリをスケジューリングするための十分なメモリがたとえあったとしても別のクラスタを開始し得る。ここで、同時実行度は、並列度（ＤＯＰ）に基づいてアクティブクラスタ毎に計算され得る。具体的には、同時実行度は、全ＤＯＰで実行しているクエリの数であり得る。例えば、これは、最大ＤＯＰ（ＭＡＸ＿ＤＯＰ）と実行クエリの数との積で全実行クエリに対するＤＯＰを除算することで計算され得る。幾つかの軽量のクエリは最大よりも小さいＤＯＰで実行しているので、これは分数又は非整数であり得る。一実施形態では、同時実行度を制御するために、ウェアハウスパラメータが指定され得る。例えば、同時実行度（ｃｏｎｃｕｒｒｅｎｃｙ＿ｌｅｖｅｌ＿ｔａｒｇｅｔ）はデフォルトでは値８に設定され得る。このパラメータは、顧客がその問題に幾ら費やすのか、及びウェアハウスが共有される場合に（スタンドアローンなクエリ性能と比較して）クエリ性能がどの程度劣化することを厭わないかにその値は実際には依存するので、顧客に晒され得る。
【００３０】
一実施形態では、仮想ウェアハウスマネージャ２２０は、自動的クラスタサスペンドを実行する。一実施形態では、（例えば、ａｕｔｏ＿ｓｕｓｐｅｎｄパラメータに基づいた）インアクティブの一定秒後に、全ウェアハウスはシャットダウンし得る。これとは別に、ウェアハウスが２つ以上のアクティブクラスタを有する場合、１つ以上のクラスタは、例えば分単位で測定される所定時間よりも長い間、ウェアハウスがその容量の下で実行していた場合にサスペンドされ得る。例えば、３つのアクティブクラスタを有するウェアハウスを考える。所定時間よりも長い間、ウェアハウスが負荷を受ける、すなわち、最大同時実行度を超えて何ら待機することなく又は進むことなく現時点で所定時間のエンジンで発行された全てのＳＱＬステートメントを実行できている場合、１つ以上のクラスタはサスペンドされる。ウェアハウスは、負荷を受ける間、現在アクティブな全てのクラスタを活用することに留意されたい。クラスタは、シャットダウンするための一定時間、インアクティブにされる必要がない。自動的クラスタサスペンドに対する確認は、残り５分、残り１０分、残り３０分、残り１時間等、定期的に実行され得る。一実施形態では、自動的クラスタに対する確認は、所定時間とは異なる間隔で実行され得る。例えば、負荷の下で残り１０分にあったか否かの確認は、顧客が時間単位で請求され得るように各時間変化で実行され得る。
【００３１】
クエリスケジューラ及びコーディネータ２１８を更に参照すると、クエリのスケジューリングは、作業量、クエリの類似性、及びその他の要因に基づいて実行され得る。クエリスケジューラ及びコーディネータ２１８は、作業量に基づいて、クエリを特定のクラスタへ転送し得る。例えば、クエリスケジューラ及びコーディネータ２１８は、処理タスクを拡散するため、及びクエリの実行時間及びユーザエクスペリエンスを向上するために各クラスタ上の作業量をほぼ等しく維持するように試み得る。クエリの類似性は、関連するクエリ、特に、同じデータに関連するクエリが同じクラスタへ送信されるように使用され得る。例えば、クエリスケジューラ及びコーディネータ２１８は、同じセッション識別子を有するクエリを同じクラスタへ送信し得る。クエリの類似性に基づいてクエリを転送することは、実行予定のクエリに対するデータが特定のクラスタのローカルキャッシュ中に既に存在することをクエリスケジューラ及びコーディネータ２１８が確保できるようにし得る。これは、応答時間、作業量、及びデータ検索を著しく削減し得る。
【００３２】
図３は、マルチクラスタウェアハウス３０２とマルチクラスタウェアハウス３０２上のクエリ３０４のスケジューリングとを説明する概略的ブロック図である。ウェアハウス３０２は、複数のサーバノードを夫々含む複数のクラスタ（クラスタ１、クラスタ２、クラスタＮ）を含む。一実施形態では、クラスタの各々は、同じ数のサーバを含むが、異なる実施形態ではこれは異なってもよい。一実施形態では、クラスタ中の各サーバは、同じアベイラビリティゾーンに属するが、異なるクラスタは、異なるアベイラビリティゾーンに配置され得る。ウェアハウスの可用性の概念は、ウェアハウスの全体的な可用性の割合に基づき得る。例えば、ウェアハウス３０２内の特定のクラスタに対する可用性は、クラスタサイズと比較して（例えば、動作可能な状態で）利用可能であるサーバの割合であり得る。しかしながら、該割合がクエリを実行するために必要とされる最小（例えば、５０％）を下回る場合、該クラスタに対して可用性が０％と判定され得、ウェアハウス３０２、又はウェアハウス３０２中の幾つかのサーバが修復されるまでクエリが何ら割り当てられないことがある。本明細書で論じられるように、ウェアハウス３０２中のクラスタの数は、作業量又はクラスタのサーバ故障（failure）等に基づいて動的に調整され得る。
【００３３】
一実施形態において、クエリスケジューラ及びコーディネータ２１８は、各クエリ（例えば、ＳＱＬステートメント又はＳＱＬステートメントの一部）をその計画されたリソース消費に基づいて重み付けする。例えば、幾つかのクエリは、その他のクエリが実行のために著しくより多くの処理リソースを取り得る間に、実行のために著しくより多くのメモリを取り得る。同様に、幾つかのクエリは、メモリ及び処理の両方について高い又は低い消費を有する。リソースマネージャ１０２は、予測又は計画される消費が何であるかを判定し得、続いて、異なるクラスタ間で作業量を最も効果的に均衡化するためにクエリをどこに配置するかを判定可能であり得る。例えば、高消費のクエリは、低消費の多数のクエリと同じくらいのリソースを使用し得る。
【００３４】
一実施形態では、クエリスケジューラ及びコーディネータ２１８は、ウェアハウス３０２の１つ以上のクラスタ上にクエリをスケジューリングし得、又は作業量が高すぎる若しくは可用性が低すぎる場合にクエリを待機し得る。例えば、クエリスケジューラ及びコーディネータ２１８は、ウェアハウス３０２のアクティブな（すなわち、サスペンドされていない）クラスタ上にクエリ３０４（例えば、ＳＱＬステートメント）をスケジューリングするようにまず試み得る。多数のアクティブクラスタが存在する場合、クエリスケジューラ及びコーディネータ２１８は、利用可能ではない、又はメモリが申し込まれ過ぎ得るためにクエリ３０４が実行しないであろうクラスタのセットを除外し得る。前述したように、クラスタは、ノードのサーバの５０％未満が利用可能ではない（例えば、故障している）場合にデフォルトにより利用可能ではないと判定され得る。多数の可能なクラスタが残っている場合、クエリスケジューラ及びコーディネータ２１８は、最低負荷のクラスタを選び得る。最低負荷のクラスタは、一実施形態では、該クラスタ上で実行する全てのジョブのＤＯＰの合計で定義される。最低負荷のクラスタはまた、該クラスタに対する全てのメモリの必要性の合計に基づき得る。負荷と等しいクラスタが多数存在する場合、クエリスケジューラ及びコーディネータ２１８は、同じセッションからのクエリが同じクラスタ上で実行できるように特定のクエリ３０４に対するセッションＩＤをタイブレーカとして使用し得る。ウェアハウス３０２中のクラスタに割り当てられているクエリ３０４は、実行クエリ３０６として示される。
【００３５】
特定のクエリをスケジューリングするためのクラスタが存在しない場合、クエリスケジューラ及びコーディネータ２１８は、該クエリをグローバルキュー中に待機し得る。グローバリーに待機されたクエリ３０４は、待機クエリ３０８として示される。待機クエリ３０８は、ウェアハウス３０２のクラスタの１つが解放され、又は利用可能になるまで待機されたままであり得る。割り当てられるクラスタ中の１つ以上のサーバは、幾つかの実行クエリ３０６がクラスタの修復を待って待機しなければならない場合に、故障の疑いとしてマークされ得ることに留意されたい。
【００３６】
図４は、一実施形態に従った、単一の実行プラットフォーム１１２上でアクティブであり得又は動作し得る複数のウェアハウスの実施形態を図示するブロック図である。多数の仮想ウェアハウス４０２、４０４、４０６が示され、各仮想ウェアハウスは複数のクラスタ４０８を含む。各クラスタ４０８は、プロセッサ４１２及びキャッシュ４１４（例えば、メモリ）を夫々含む多数の実行ノード４１０を含む。３つの仮想ウェアハウス４０２〜４０６が示されるが、仮想ウェアハウスの数は動的に変更し得る。同様に、各ウェアハウス４０２〜４０６中のクラスタ４０８の数、及び各クラスタ中の実行ノード４１０の数は異なる実施形態では変更し得、また、相互に対して無制限に変更し得る。更に、要求が変化した場合に新たなクラスタ４０８及び実行ノード４１０が作り出され又は除去され得るように、仮想ウェアハウス中のクラスタ４０８の数及びクラスタ中の実行ノード４１０の数は動的であり得る。
【００３７】
各仮想ウェアハウス４０２〜４０６は、図１に示した任意のデータ格納デバイス１１６〜１２０をアクセス可能である。したがって、仮想ウェアハウス４０２〜４０６は、特定のデータ格納デバイス１１６〜１２０に割り当てられる必要がなく、代わりに、任意のデータ格納デバイス１１６〜１２０からデータをアクセスし得る。同様に、クラスタ４０８及び実行ノード４１０の各々は、任意のデータ格納デバイス１１６〜１２０からデータをアクセスし得る。幾つかの実施形態では、特定の仮想ウェアハウス又は特定の実行ノードは、特定のデータ格納デバイスに一時的に割り当てられ得るが、該仮想ウェアハウス又は実行ノードは、任意のその他のデータ格納デバイスからデータを後にアクセスし得る。
【００３８】
説明される実行ノード４１０は、１つのキャッシュと１つのプロセッサとを夫々含むが、別の実施形態は、任意の数のプロセッサと任意の数のキャッシュとを含む実行ノードを含み得る。また、キャッシュは、異なる実行ノード４１０間でサイズを変更し得る。キャッシュ４１４は、ローカル実行ノードにおいて、格納プラットフォーム１１４（図１）中の１つ以上のデータ格納デバイスから検索されたデータを格納する。したがって、キャッシュは、遠隔格納システムからデータを一貫して検索するプラットフォームに生じるボトルネックの問題を削減又は取り除く。遠隔格納デバイスからデータを繰り返しアクセスすることに代えて、本明細書に記載されるシステム及び方法は、著しく速く且つ上で論じたボトルネックの問題を避ける実行ノード中のキャッシュからデータをアクセスする。幾つかの実施形態では、キャッシュは、キャッシュされたデータへの速いアクセスを提供する高速メモリデバイスを使用して実装される。各キャッシュは、格納プラットフォーム１１４中の任意の格納デバイスからのデータを格納することができる。
【００３９】
更に、キャッシュリソース及びコンピューティングリソースは異なる実行ノード間で変更し得る。例えば、ある実行ノードは、顕著なコンピューティングリソースと最小のキャッシュリソースとを含み得、顕著なコンピューティングリソースを必要とするタスクに実行ノードを役立たせる。別の実行ノードは、顕著なキャッシュリソースと最小のコンピューティングリソースとを含み得、大量のデータのキャッシングを必要とするタスクにこの実行ノードを役立たせる。幾つかの実施形態では、特定の実行ノードと関連付けられるキャッシュリソース及びコンピューティングリソースは、実行ノードにより実行される予想タスクに基づいて、実行ノードが作り出される時に決定される。
【００４０】
また、特定の実行ノードと関連付けられるキャッシュリソース及びコンピューティングリソースは、実行ノードにより実行されるタスクの変化に基づいて時間と共に変化し得る。例えば、実行ノードにより実行されるタスクがプロセッサにより多くの負担をかける場合、該特定の実行ノードにはより多くのプロセッサが割り当てられ得る。同様に、実行ノードにより実行されるタスクがより大きなキャッシュ容量を必要とする場合、該実行ノードにはより多くのキャッシュリソースが割り当てられ得る。
【００４１】
仮想ウェアハウス４０２〜４０６は同じ実行プラットフォーム１１２と関連付けられるが、仮想ウェアハウスは、多数の地理的位置に多数のコンピューティングシステムを使用して実装され得る。例えば、仮想ウェアハウス４０２は、第１の地理的位置にコンピューティングシステムにより実装され得るが、仮想ウェアハウス４０４及び４０６は、第２の地理的位置に別のコンピューティングシステムにより実装される。幾つかの実施形態では、これらの異なるコンピューティングシステムは、１つ以上の異なるエンティティにより維持されるクラウドベースのコンピューティングシステムである。
【００４２】
また、各仮想ウェアハウスは、多数のクラスタ４０８を有するものとして図４に示される。各仮想ウェアハウスと関連付けられたクラスタ４０８は、多数の地理的位置に又は異なるアベイラビリティゾーン内に多数のコンピューティングシステムを使用して実装され得る。例えば、仮想ウェアハウス４０２の特定のインスタンスは、特定の地理的位置のあるコンピューティングプラットフォーム上に実行ノード４１０と共にクラスタ４０８を実装し、別の地理的位置の異なるコンピューティングプラットフォームにその他のクラスタ４０８及び実行ノード４１０を実装する。仮想ウェアハウス４０２〜４０６はまたフォールトトレラントである。例えば、ある仮想ウェアハウス又は実行ノード４１０では、該仮想ウェアハウス又は実行ノードは、同じ又は異なる地理的位置で即座に修復される。
【００４３】
特定の実行プラットフォーム１１２は、任意の数の仮想ウェアハウス４０２〜４０６を含み得る。また、特定の実行プラットフォーム中の仮想ウェアハウスの数は、追加の処理及び／又はキャッシュリソースが必要である場合に新たな仮想ウェアハウスが作り出されるように動的である。同様に、既存の仮想ウェアハウスは、該仮想ウェアハウスと関連付けられたリソースがもはや必要でない場合に削除され得る。
【００４４】
図５は、多数の分散された仮想ウェアハウス及び実行プラットフォーム群を有する別の例示的動作環境５００を示すブロック図を説明する。環境５００は、実行プラットフォーム群１  ５０４及び実行プラットフォーム群２  ５０６とデータ通信ネットワーク５０２を通じて通信するリソースマネージャ１０２を含む。実行プラットフォーム群１  ５０４は、２つのクラスタ、具体的には、第１の仮想ウェアハウス５０８に対するクラスタＡと第２の仮想ウェアハウス５１０に対するクラスタＡとを含む。実行プラットフォーム群２  ５０６は２つの追加のクラスタ、具体的には、第１の仮想ウェアハウス５１４に対するクラスタＢと第２の仮想ウェアハウス５１６に対するクラスタＢとを含む。リソースマネージャ１０２は、（実行プラットフォーム群５０４、５０６の何れの一部でもない）第１の仮想ウェアハウス５１２のクラスタＣともデータ通信ネットワーク５０２を通じて通信する。
【００４５】
実行プラットフォーム群５０４及び５０６と第１の仮想ウェアハウス５１２に対するクラスタＣとは、データ通信ネットワーク５１８を通じてデータベース５２０、５２２、及び５２４と通信する。幾つかの実施形態では、データ通信ネットワーク５０２及び５１８は、同じネットワーク、又は１つ以上の重複するネットワークの組み合わせである。環境５００は、データベース５２０〜５２４中にデータを格納又は検索するための、多数のウェアハウスの多数のクラスタ５０８〜５１６に渡るユーザデータ格納及び検索リクエストをリソースマネージャ１０２が調整できるようにする。実行プラットフォーム群５０４及び５０６と第１の仮想ウェアハウス５１２に対するクラスタＣとは、同じ又は異なる地理的領域に配置され得、又は同じ又は異なるアベイラビリティゾーンに配置され得る。また、実行プラットフォーム群５０４及び５０６は、同じエンティティにより、又は異なるエンティティにより実装され得る。
【００４６】
本明細書に記述されるシステム及び方法は、コンピューティング（又は処理）リソースとは別のサービスとしてデータが格納及びアクセスされ得るようにする。たとえ実行プラットフォームからコンピューティングリソースが何ら要求されていなかったとしても、遠隔データ源からのデータのリロードを必要とすることなくデータは仮想ウェアハウスに入手可能である。記述されるシステム及び方法は、何れの種類のデータでも有用である。特定の実施形態では、データは、構造化された最適なフォーマット中に格納される。コンピューティングサービスからのデータ格納／アクセスサービスの分離も、異なるユーザ及び群の間でのデータの共有を簡易化する。本明細書で論じられるように、各仮想ウェアハウスは、その他の仮想ウェアハウスが同じデータにアクセスしている同時であっても、アクセス許可を有する任意のデータにアクセスし得る。このアーキテクチャは、ローカルキャッシュ中に格納された何れの実データなしにクエリを実行することを支持する。本明細書に記述されるシステム及び方法は、トランスペアレントな動的データ移動を可能にし、それは、システムのユーザにトランスペアレントな方法で、遠隔格納デバイスからローカルキャッシュへデータを必要に応じて移動する。更に、コンピューティングサービスからのデータ格納サービスの分離に起因して何れの仮想ウェアハウスも何れのデータにアクセスできるので、このアーキテクチャは、従来のデータ移動なしにデータの共有を支持する。
【００４７】
更に、環境５００は、多数の地理的位置又はアベイラビリティゾーンに渡る単一の仮想ウェアハウスの拡散を可能にする。例えば、クラスタ５０８、５１２、及び５１４は、同じ仮想ウェアハウス（第１の仮想ウェアハウス）に全て属するが、異なる地理的領域又はアベイラビリティゾーンに配置され得る。停電又は故障は地理的領域又はアベイラビリティゾーンに渡って起き得るため、フォールトトレラントの向上が実現され得る。例えば、あるアベイラビリティゾーンの問題が異なるアベイラビリティゾーンへ拡散する可能性が僅かにあるか全くないように、アベイラビリティゾーンは、クラウドサービス（計算又は格納）プロバイダによって実装されることがある。したがって、同じウェアハウス内にあるが異なるアベイラビリティゾーンにあるクラスタは、何ら利用可能な実行又は計算ノードなくウェアハウスが残される可能性を顕著に減少させ得る。
【００４８】
一実施形態では、本明細書に開示されるマルチクラスタウェアハウスの実施形態は、特殊なデータ定義言語（ＤＤＬ）を使用し得る。以下は、マルチクラスタウェアハウスのＤＤＬの一部であり得るコマンド又は命令の幾つかの例である。
□        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 started 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.
【００４９】
図に戻ると、図６は、マルチクラスタウェアハウスのための例示的方法６００を説明する概略的フローチャート図である。方法６００は、図１の処理プラットフォーム１００又は図１、図２、若しくは図５のリソースマネージャ等の処理プラットフォーム又はリソースマネージャにより実行され得る。
【００５０】
方法６００が始まり、システムは、１つ以上のクラウド格納リソース中の１つ以上のデータベースに対してアクセスしクエリを実行するために、仮想ウェアハウスの一部として複数の計算クラスタを割り当てる（６０２）。一実施形態では、１つ以上のクラウド格納リソースの増加又は減少なしに計算クラスタの数が拡大又は縮小し得るように、複数の計算クラスタは、１つ以上のクラウド格納リソースとは無関係にシステムにより割り当てられる。システムは、複数の計算クラスタの各々に仮想ウェアハウスに対するクエリを提供する（６０４）。例えば、仮想ウェアハウスの複数の計算クラスタの各々に複数のクエリが提供され得る。システムは、複数の計算クラスタの作業量に基づいて、必要に応じて、動的に、仮想ウェアハウスに計算クラスタを追加し、仮想ウェアハウスから計算クラスタを除去する（６０６）。方法６００はまた、複数の計算クラスタに対する作業量を判定することを含み得る。システムは、複数の計算クラスタの各々に対する１つ以上のプロセッサリソースと複数の計算クラスタの各々に対するメモリリソースとの可用性を判定することによって作業量を判定し得る。
【００５１】
方法６００は、ウェアハウス等の単一のエンティティがクエリの数に依存して拡大又は縮小できるように、データベースシステム又はデバイスによって実装され得る。具体的には、ウェアハウスの同時実行性（又は計算及びメモリの負荷）の変化が起こるように、リソースマネージャ又はその他のシステムは、ウェアハウスが拡大又は縮小できるようにし得る。
【００５２】
図７は、マルチクラスタウェアハウス中の計算クラスタを動的に追加するための例示的方法７００を説明する概略的フローチャート図である。方法７００は、図１の処理プラットフォーム１００又は図１、図２、若しくは図５のリソースマネージャ等の処理プラットフォーム又はリソースマネージャによって実行され得る。方法７００は、図６の方法６００と組み合わせて、又は方法６００とは別に実行され得る。
【００５３】
方法７００が始まり、システムは、クエリに対する性能メトリックに合致しながらクエリが処理されるか否かを判定する（７０２）。一実施形態では、方法７００は、クエリ毎に性能メトリックが合致するように、計算クラスタに向けられたクエリ毎にクエリが処理され得るか否かを判定すること（７０２）を含む。性能メトリックは、顧客に容認されるサービスレベルアグリーメント（ＳＬＡ）を含み得る。例えば、ＳＬＡは、クエリが特定時間（例えば、１０秒）内にスケジューリングされることを必要とし得る。これは、任意のクエリが最大時間（例えば、１０秒）を超えてグローバル待機で待機されることを制限し得る。ＳＬＡは、サービスプロバイダとしてのウェアハウスと顧客との間で予め合意され得る。ＳＬＡが何かに基づいて異なる価格帯が提示され得、又はデータベースに対するクエリのアクセス及び実行においてユーザが最小遅延を経験することを保証するためにシステムがより多くのリソースを使用することをＳＬＡは規定し得る。
【００５４】
現在割り当てられた１つ以上の計算クラスタが性能メトリックに合致するように現在の作業量と組み合わさったクエリができないとの判定に応答して、システムは新たな計算クラスタの起動を誘発する（７０４）。一実施形態では、現在のアクティブクラスタの数が所定の最大計算クラスタ数未満である場合にのみ、システムは起動を誘発し得る（７０４）。
【００５５】
図８は、マルチクラスタウェアハウス中の計算クラスタを動的に除去するための例示的方法８００を説明する概略的フローチャート図である。方法８００は、図１の処理プラットフォーム１００又は図１、図２、若しくは図５のリソースマネージャ等の処理プラットフォーム又はリソースマネージャによって実行され得る。方法８００は、図６及び図７の方法６００又は７００の内の１つ以上と組み合わせて、又は方法６００又は７００の１つ以上とは別に実行され得る。
【００５６】
方法８００が開始し、システムは、性能メトリックに合致しつつ複数の計算クラスタよりも少数の計算クラスタによって現在の作業量がサービス可能であるか否かを判定する（８０２）。一実施形態では、複数の計算クラスタよりも少数の計算クラスタによって現在の作業量がサービス可能であるか否かを判定すること（８０２）は、性能メトリックに合致しながら複数のクラスタよりも少数の計算クラスタによって現時点に至る期間の履歴的作業量がサービス可能であったか否かを判定することを含み得る。例えば、最良のクラスタが仮想ウェアハウスから除去された場合、仮想ウェアハウスは、性能メトリックに合致しつつ全てのクエリを処理可能であっただろうか。
【００５７】
システムは、複数の計算クラスタよりも少数の計算クラスタにより作業量がサービス可能であるとの判定に応答して、複数の計算クラスタの内の少なくとも１つの計算クラスタを廃止する（８０４）（又はインアクティブにする）。システムは、アクティブクラスタの現在の数が所定の最小計算クラスタ数よりも少ない場合にのみ計算クラスタを廃止し得（８０４）又は除去し得る。一実施形態では、少なくとも１つの計算クラスタを廃止すること（８０４）は、複数の計算クラスタよりも少数の計算クラスタによってその期間の履歴的作業量がサービス可能であったとの判定に応答して廃止することを含み得る。
【００５８】
一実施形態では、少なくとも１つの計算クラスタを廃止すること（８０４）は、少なくとも１つの計算クラスタに追加のクエリを提供又はスケジューリングすることを阻止するために、クラスタを静止させることを含む。廃止すること（８０４）はまた、現在割り当てられたクエリを少なくとも１つの計算クラスタが完了できるようにすることと、既にスケジューリングされた又はアクティブなクエリが完了すると、少なくとも１つの計算クラスタに対応する１つ以上のリソースを解放することを含み得る。
【００５９】
図９は、マルチクラスタウェアハウスのための例示的方法９００を説明する概略的フローチャート図である。方法９００は、図１の処理プラットフォーム１００又は図１、図２、若しくは図５のリソースマネージャ等の処理プラットフォーム又はリソースマネージャによって実行され得る。方法９００は、図６、図７、及び図８の方法６００、７００、又は８００の内の１つ以上と組み合わせて、又は方法６００、７００、又は８００の１つ以上とは別に実行され得る。
【００６０】
方法９００が開始し、システムは、１つ以上のクラウド格納リソース中の１つ以上のデータベースに対してアクセスしクエリを実行するために、仮想ウェアハウスの一部として複数の計算クラスタを割り当てる（９０２）。システムは、仮想ウェアハウスに対するクエリを複数の計算クラスタの各々へ転送する（９０４）。該複数のクエリは、仮想ウェアハウスの複数の計算クラスタの各々に提供され得る。一実施形態では、仮想ウェアハウスに対するクエリを複数の計算クラスタの各々へ転送すること（９０４）は、同じセッションからのクエリがデフォルトにより同じ計算クラスタにルーティングされるように、クエリが起きたセッションに基づいてクエリをルーティングすること（９０６）を含む。各クラスタは、クラスタが処理するデータベースのフラグメントを持続する能力を有する。すなわち、各クラスタ（又はクラスタ中の各計算ノード）は、クラスタ上のクエリを処理しつつ現在アクセスしている全てのテーブルのキャッシュを維持し得る。したがって、リソースマネージャ又はスケジューラは、（例えば、同じセッション識別子を有する）同じクエリのストリームからのクエリを、キャッシングの効果を利用できるように同じクラスタへ動かす。幾つかのケースでは、特定のセッションを処理しているクラスタが別のクラスタよりも利用可能なリソースが非常に少ない場合、同じセッション識別子を有するクエリは、異なるクラスタ上で終わり得る。
【００６１】
一実施形態では、システムは、複数の計算クラスタの各々の作業量に基づいてクエリをルーティングし得る（９０６）。例えば、クラスタが新たなクエリを受け入れられない場合、システムは、同じセッションに対応するクエリを異なるクラスタが処理していなかったとしても該異なるクラスタにクエリを提供し得る。一実施形態では、システムは、異なるアベイラビリティゾーン中の少なくとも２つの計算クラスタにクエリを提供し得る（９０４）。
【００６２】
図１０は、例示的コンピューティングデバイス１０００を図示するブロック図である。幾つかの実施形態では、コンピューティングデバイス１０００は、本明細書で論じられる１つ以上のシステム及びコンポーネントを実装するために使用される。例えば、コンピューティングデバイス１０００は、ユーザ又は管理者がリソースマネージャ１０２をアクセスできるようにし得る。別の実施形態として、本明細書で論じられるコンポーネント、システム、又はプラットフォームは１つ以上のコンピューティングデバイス１０００を含み得る。更に、コンピューティングデバイス１０００は、本明細書に記述されるシステム及びコンポーネントの何れかと相互作用し得る。したがって、コンピューティングデバイス１０００は、本明細書で論じられるプロシージャ及びタスク等、様々なプロシージャ及びタスクを実行するために使用され得る。コンピューティングデバイス１０００は、サーバ、クライアント、又は任意のその他のコンピューティングエンティティとして機能し得る。コンピューティングデバイス１０００は、デスクトップコンピュータ、ノートブックコンピュータ、サーバコンピュータ、携帯型コンピュータ、及びタブレット等の多種多様な任意のコンピューティングデバイスであり得る。
【００６３】
コンピューティングデバイス１０００は、１つ以上のプロセッサ１００２、１つ以上のメモリデバイス１００４、１つ以上のインタフェース１００６、１つ以上の大容量格納デバイス１００８、及び１つ以上の入出力デバイス１０１０を含み、それらは全てバス１０１２に結合される。プロセッサ１００２は、メモリデバイス１００４及び／又は大容量格納デバイス１００８中に格納された命令を実行する１つ以上のプロセッサ又はコントローラを含む。プロセッサ１００２は、キャッシュメモリ等の様々な種類のコンピュータ可読媒体をも含み得る。
【００６４】
メモリデバイス１００４は、揮発性メモリ（例えば、ランダムアクセスメモリ（ＲＡＭ））及び／又は不揮発性メモリ（例えば、リードオンリーメモリ（ＲＯＭ））等の様々なコンピュータ可読媒体を含む。メモリデバイス１００４は、フラッシュメモリ等の再書き込み可能なＲＯＭをも含み得る。
【００６５】
大容量格納デバイス１００８は、磁気テープ、磁気ディスク、光ディスク、及び固体メモリ（例えば、フラッシュメモリ）等の様々なコンピュータ可読媒体を含む。様々なコンピュータ可読媒体から読み出すこと、及び／又は様々なコンピュータ可読媒体に書き込むことを可能にするために、大容量格納デバイス１００８には様々なドライブも含まれ得る。大容量格納デバイス１００８は、取り外し可能媒体及び／又は固定型媒体を含む。
【００６６】
入出力デバイス１０１０は、データ及び／又はその他の情報をコンピューティングデバイス１０００に入力でき又はコンピューティングデバイス１０００から検索できるようにする様々なデバイスを含む。例示的入出力デバイス１０１０は、カーソル制御デバイス、キーボード、キーパッド、マイク、モニタ若しくはその他の表示デバイス、スピーカ、プリンタ、ネットワークインタフェースカード、モデム、レンズ、及びＣＣＤ若しくはその他の画像取得デバイス等を含む。
【００６７】
インタフェース１００６は、コンピューティングデバイス１０００がその他のシステム、デバイス、又はコンピューティング環境と相互作用できるようにする様々なインタフェースを含む。例示的インタフェース１００６は、ローカルエリアネットワーク（ＬＡＮ）、広域ネットワーク（ＷＡＮ）、無線ネットワーク、及びインターネットへのインタフェース等の任意の数の異なるネットワークインタフェースを含む。
【００６８】
バス１０１２は、プロセッサ１００２、メモリデバイス１００４、インタフェース１００６、大容量格納デバイス１００８、及び入出力デバイス１０１０が互いに通信すると共に、バス１０１２と結合されたその他のデバイス又はコンポーネントと通信することを可能にする。バス１０１２は、システムバス、ＰＣＩバス、ＩＥＥＥ１３９４バス、及びＵＳＢバス等の様々な種類のバス構造体の１つ以上を表す。
（例）
【００６９】
以下の例は、更なる実施形態に関連する。
【００７０】
例１は、マルチクラスタウェアハウスのための、コンピュータに実装される方法である。方法は、１つ以上のクラウド格納リソース中の１つ以上のデータベースに対してアクセスしクエリを実行するために仮想ウェアハウスの一部として複数の計算クラスタを割り当てることを含む。方法は、仮想ウェアハウスに対するクエリを複数の計算クラスタの各々に提供することを含み、ここで、複数のクエリは、仮想ウェアハウスの複数の計算クラスタの各々に提供される。方法は、複数の計算クラスタの作業量に基づいて、必要に応じて、動的に、仮想ウェアハウスに計算クラスタを追加すること及び仮想ウェアハウスから計算クラスタを除去することを含む。
【００７１】
例２では、例１の複数の計算クラスタは、１つ以上のクラウド格納リソースを増加又は減少させることなく計算クラスタの数を拡大又は縮小し得るように、１つ以上のクラウド格納リソースとは無関係に割り当てられる。
【００７２】
例３では、例１〜例２の何れかの方法は、複数の計算クラスタに対する作業量を判定することを更に含む。作業量を判定することは、複数の計算クラスタの各々に対する１つ以上のプロセッサリソースと複数の計算クラスタの各々に対するメモリリソースとの可用性を判定することを含む。
【００７３】
例４では、例１〜例３の何れかにおいて計算クラスタを動的に追加することは、クエリに対する性能メトリックに合致しながらクエリが処理され得るかを判定することと、現在の作業量と組み合わさるクエリが、現在割り当てられた１つ以上のクラスタが性能メトリックに合致するようにできないとの判定に応答して、新たな計算クラスタの起動を誘発することを含む。
【００７４】
例５では、例４の方法は、クエリ毎に性能メトリックが合致するように計算クラスタに向けられたクエリ毎にクエリが処理され得るか否かを判定することを含む。
【００７５】
例６では、例４〜例５の何れかにおける性能メトリックは、顧客に容認されるサービスレベルアグリーメントを含む。
【００７６】
例７では、例４〜例６の何れかにおける性能メトリックは、クエリが待機される最大期間を含む。
【００７７】
例８では、例１〜例７の何れかにおいて計算クラスタを動的に追加することは、所定の最大計算クラスタ数になるまで計算クラスタを追加することを含む。
【００７８】
例９では、例１〜例８の何れかにおいて計算クラスタを動的に除去することは、所定の最小計算クラスタ数になるまで計算クラスタを除去することを含む。
【００７９】
例１０では、例１〜９の何れかにおいて計算クラスタを除去することは、性能メトリックに合致しつつ複数の計算クラスタよりも少数の計算クラスタによって現在の作業量がサービス可能であるか否かを判定することと、複数の計算クラスタよりも少数の計算クラスタによって作業量がサービス可能であるとの判定に応答して複数の計算クラスタの内の少なくとも１つの計算クラスタを廃止することを含む。
【００８０】
例１１では、例１０において少なくとも１つの計算クラスタを廃止することは、少なくとも１つの計算クラスタへの追加のクエリの提供を阻止することと、現在割り当てられたクエリを少なくとも１つの計算クラスタが完了できるようにすることと、現在割り当てられたクエリが完了すると、少なくとも１つの計算クラスタに対応する１つ以上のリソースを解放することを含む。
【００８１】
例１２では、例１０〜例１１の何れかにおいて現在の作業量が複数の計算クラスタよりも少数の計算クラスタによってサービス可能であるか否かを判定することは、性能メトリックに合致しながら複数のクラスタよりも少数の計算クラスタによって現時点に至る期間の履歴的作業量がサービス可能であったか否かを判定することを含む。少なくとも１つの計算クラスタを廃止することは、複数の計算クラスタよりも少数の計算クラスタによってその期間の履歴的作業量がサービス可能であったとの判定に応答して廃止することを含む。
【００８２】
例１３では、例１〜例１２の何れかにおいて仮想ウェアハウスに対するクエリを複数の計算クラスタの各々に提供することは、クエリが起きたセッションに基づいてクエリをルーティングすることを含む。
【００８３】
例１４では、例１〜例１３の何れかにおいて仮想ウェアハウスに対するクエリを複数の計算クラスタの各々に提供することは、複数の計算クラスタの各々の作業量に基づいてクエリをルーティングすることを含む。
【００８４】
例１５では、例１〜例１４の何れかにおいて複数の計算クラスタを割り当てることは、異なるアベイラビリティゾーン中の少なくとも２つの計算クラスタを割り当てることを含む。
【００８５】
例１６は、例１〜１５の何れかのような方法を実行するための手段を含む装置である。
【００８６】
例１７は、実行する場合に、例１〜例１６の何れかの方法を実装し、又は例１〜例１６の何れかの装置を実現する機械可読命令を含む機械可読ストレージである。
【００８７】
本明細書のフロー図及びブロック図は、本開示の様々な実施形態に従ったシステム、方法、及びコンピュータプログラム製品の可能的実装のアーキテクチャ、機能、及び動作を説明する。これに関して、フロー図又はブロック図の各ブロックは、指定された論理的機能を実装するための１つ以上の実行可能な命令を含むコードのモジュール、セグメント、又は一部を表し得る。ブロック図及び／又はフロー図の各ブロック、並びにブロック図及び／又はフロー図の中のブロックの組み合わせは、特定の機能又は行為を実行する専用のハードウェアベースのシステム、又は専用ハードウェアとコンピュータ命令との組み合わせにより実装され得ることも留意すべきである。これらのコンピュータプログラム命令はまた、フロー図及び／又はブロック図の１つ以上のブロックで指定される機能／行為を実装する命令手段を含む製造物をコンピュータ可読媒体中に格納された命令が生み出すように、特定の方法で機能するようにコンピュータ又はその他のプログラム可能データ処理装置に指示し得るコンピュータ可読媒体中に格納され得る。
【００８８】
本明細書に記述されるシステム及び方法は、新たなデータ処理プラットフォーム、方法、システム、及びアルゴリズムを使用して、自在かつ拡大縮小可能なデータウェアハウスを提供する。幾つかの実施形態では、記述されるシステム及び方法は、クラウドベースの格納リソース及びコンピューティングリソース等を支持するクラウド基盤を活用する。例示的なクラウドベースの格納リソースは、低コストでオンデマンドで利用可能な顕著な格納容量を提供する。更に、これらのクラウドベースの格納リソースは、フォールトトレラントで高度に拡大縮小可能であり得、それらは、私的なデータ格納システムで達成するのにはコストがかかり得る。例示的なクラウドベースのコンピューティングリソースは、オンデマンドで利用可能であり、リソースの実際の使用レベルに基づいて価格設定され得る。典型的には、クラウド基盤は、速やかに、動的に発展し、設定され、且つ廃止される。
【００８９】
記述されるシステム及び方法では、データ格納システムは、ＳＱＬ（構造化クエリ言語）ベースの関連データベースを利用する。しかしながら、これらのシステム及び方法は、任意のデータ格納アーキテクチャを使用して、且つデータベース内でデータを格納及び検索するための任意の言語を使用して、任意の種類のデータベースに適用可能である。本明細書に記述されるシステム及び方法は、異なる顧客／クライアント間及び同じ顧客／クライアント内の異なるユーザ間でコンピューティングリソース及びデータの分離を支持するマルチテナントシステムをも提供し得る。
【００９０】
様々な技術、又は幾つかの態様若しくはその一部は、フロッピーディスク、ＣＤ−ＲＯＭ、ハードドライブ、非一時的コンピュータ可読格納媒体、又は任意のその他の機械可読格納媒体等の有形媒体中に具体化されたプログラムコード（例えば、命令）の形を取り得、ここで、プログラムコードがコンピュータ等の機械にロードされ実行される場合に、該機械は様々な技術を行うための装置になる。プログラム可能コンピュータ上のプログラム実行コードのケースでは、コンピューティングデバイスは、プロセッサ、プロセッサにより読み出し可能な格納媒体（揮発性及び不揮発性のメモリ並びに／又は格納素子を含む）、少なくとも１つの入力デバイス、及び少なくとも１つの出力デバイスを含み得る。揮発性及び不揮発性のメモリ並びに／又は格納素子は、ＲＡＭ、ＥＰＲＯＭ、フラッシュドライブ、光ドライブ、磁気ハードドライブ、又は電子データを格納するための別の媒体であり得る。本明細書に記述される様々な技術を実装又は利用し得る１つ以上のプログラムは、アプリケーションプログラミングインタフェース（ＡＰＩ）及び再利用可能制御等を使用し得る。そうしたプログラムは、コンピュータシステムと通信するための高水準な手続き又はオブジェクト指向のプログラミング言語で実装され得る。しかしながら、プログラムは、必要に応じてアセンブリ又は機械言語で実装され得る。何れのケースでも、言語は、コンパイル又は翻訳された言語であり得、ハードウェア実装と結合され得る。
【００９１】
この明細書に記述される機能部の多くは１つ以上のコンポーネントとして実装され得、それは、それらの実装独立をより具体的に強調するために使用される用語であることを理解すべきである。例えば、コンポーネントは、カスタム超大規模集積（ＶＬＳＩ）回路若しくはゲートアレイを含むハードウェア回路、論理チップ等の既製品半導体、トランジスタ、又はその他の個別部品として実装され得る。コンポーネントはまた、フィールドプログラマブルゲートアレイ、プログラム可能アレイ論理、又はプログラム可能論理デバイス等のプログラム可能ハードウェアデバイスに実装され得る。
【００９２】
コンポーネントはまた、様々な種類のプロセッサによる実行用のソフトウェアに実装され得る。実行可能コードの識別コンポーネントは、例えば、コンピュータ命令の１つ以上の物理的又は論理的ブロックを含み得、それは、例えば、オブジェクト、手順、又は機能として組織化され得る。それにもかかわらず、識別コンポーネントの実行可能性は、相互に物理的に配置される必要がないが、論理的に相互に結合される場合に、コンポーネントを含み且つ該コンポーネントの規定された目的を実現する異なる位置に格納された異種の命令を含み得る。
【００９３】
実際、実行可能コードのコンポーネントは、単一の命令又は多数の命令であり得、異なるプログラムの中で幾つかの異なるコードセグメントに渡る分散もされ得る。同様に、運用データは、コンポーネント内に本明細書で識別及び説明され得、任意の適切な形式で具体化され得、任意の適切な種類のデータ構造体内に組織化され得る。運用データは、単一のデータセットとして収集され得、又は異なる格納デバイスに渡ることを含む異なる位置に渡って分散され得、少なくとも部分的には、単にシステム又はネットワーク上の電子信号として存在し得る。コンポーネントは、パッシブ又はアクティブであり得、所望の機能を実行するように動作可能なエージェントを含む。
【００９４】
この明細書を通じて“例”との言及は、該例と併せて記述される特定のフィーチャ、構造体、又は特徴が本開示の少なくとも１つの実施形態に含まれることを意味する。したがって、この明細書を通じた様々な位置における句“例では”の出現は、必ずしも全てが同じ実施形態に言及しない。
【００９５】
本明細書で使用されるように、複数の項目、構造的要素、組成上の要素、及び／又は材料は、便宜上、共通のリストで提示され得る。しかしながら、これらのリストは、リストの各要素が別々のユニークな要素として独立して識別されるように解釈されるべきである。したがって、そうしたリストの個々の要素は、正反対に示すことなく共通のグループ内のその提示に基づいて、単に同じリストの任意のその他の要素の事実上の均等物として何ら解釈されるべきではない。また、本開示の様々な実施形態及び例は、それらの様々なコンポーネントに対する代替案と共に本明細書に言及され得る。そうした実施形態、例、及び代替案は、相互の事実上の均等物として解釈されるべきではないが、本開示の別々の自律的な表現として解釈されるべきことを理解される。
【００９６】
明確にするために幾つかの詳細が前述されたが、その原理から逸脱することなく幾つかの変更及び修正がなされるであろう。本明細書に記述された処理及び装置の両方を実装する多くの別な方法があることに留意すべきである。したがって、本実施形態は、例証であって非限定的に考慮されるべきである。
【００９７】
本開示の基礎となる原理から逸脱することなく上述した実施形態の詳細に多くの変更がなされ得ることを当業者は認めるであろう。本開示の範囲は、それ故、以下の請求項によってのみ決定されるべきである。
【図１】
2019519026.tif 000003
【図２】
2019519026.tif 000004
【図３】
2019519026.tif 000005
【図４】
2019519026.tif 000006
【図５】
2019519026.tif 000007
【図６】
2019519026.tif 000008
【図７】
2019519026.tif 000009
【図８】
2019519026.tif 000010
【図９】
2019519026.tif 000011
【図１０】
2019519026.tif 000012
【国際調査報告】
2019519026.tif 000013