特許 6730189 キャッシングシステム及び方法

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

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

(11)【特許番号】6730189

(24)【登録日】2020年7月6日

(45)【発行日】2020年7月29日

(54)【発明の名称】キャッシングシステム及び方法

(51)【国際特許分類】

   G06F 16/172 20190101AFI20200716BHJP

   G06F 16/21 20190101ALI20200716BHJP

【ＦＩ】

   G06F16/172

   G06F16/21

【請求項の数】20

【全頁数】24

(21)【出願番号】特願2016-552990(P2016-552990)

(86)(22)【出願日】2015年2月18日

(65)【公表番号】特表2017-512339(P2017-512339A)

(43)【公表日】2017年5月18日

(86)【国際出願番号】US2015016410

(87)【国際公開番号】WO2015126962

(87)【国際公開日】20150827

【審査請求日】2018年2月7日

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

(32)【優先日】2014年10月20日

(33)【優先権主張国】US

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

(32)【優先日】2014年2月19日

(33)【優先権主張国】US

(73)【特許権者】

【識別番号】516245999

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

(74)【代理人】

【識別番号】100074099

【弁理士】

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

(74)【代理人】

【識別番号】100121083

【弁理士】

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

(74)【代理人】

【識別番号】100138391

【弁理士】

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

(74)【代理人】

【識別番号】110000132

【氏名又は名称】大菅内外国特許事務所特許業務法人

(72)【発明者】

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

(72)【発明者】

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

(72)【発明者】

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

【審査官】 上島 拓也

(56)【参考文献】

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

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

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

【文献】 特開２００５−２８５０５８（ＪＰ，Ａ）

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

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

【文献】 特開２００２−１３２４５５（ＪＰ，Ａ）

【文献】 国際公開第２０１２／１５８６５４（ＷＯ，Ａ１）

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

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

Ｇ０６Ｆ １６／１７２

Ｇ０６Ｆ １６／２１

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

【請求項1】

複数の実行ノードを含む実行プラットフォームをリソースマネージャによって配置することであって、ここで、前記複数の実行ノードの内の各実行ノードは、データベースのデータを共同して格納する複数の共有ストレージデバイスから独立し、前記リソースマネージャは、前記データベースのデータに関係し且つ前記データベースのデータ及び前記実行プラットフォームとは別に格納されたメタデータに結合されることと、
前記データベースのデータに向けられたクエリを前記リソースマネージャによって受信することと、
前記クエリに応答して処理される必要がある前記データベースのデータ内の複数のファイルを前記リソースマネージャによって特定することと、
処理される必要がある前記複数のファイルの内の第１のファイルをキャッシュしている、前記複数の実行ノードの内の第１の実行ノードを前記リソースマネージャによって特定することであって、ここで、前記第１の実行ノード及び前記第１のファイルは前記メタデータに基づき特定されることと、
前記クエリのタスクとして処理するために、前記複数の実行ノードの内の実行ノードに前記複数のファイルの内の各ファイルを前記リソースマネージャによって割り当てることであって、ここで、前記第１のファイルは前記第１の実行ノードに割り当てられることとを含む、方法。

【請求項2】

前記複数の実行ノードの内の実行ノードの１つ以上のプロセッサによって、それに割り当てられた特定のファイルのコピーが前記１つ以上のプロセッサにローカルなキャッシュ内に存在するか否かを判定することと、
前記複数のファイルの内の何れのファイルが前記１つ以上のプロセッサにローカルな前記キャッシュ内に複写されるかを特定するために前記メタデータを更新することと
を更に含む。請求項１に記載の方法。

【請求項3】

前記特定のファイルのコピーが前記キャッシュ内に何ら存在しないと判定することに応答して、データベースのデータを共同して格納する前記複数の共有ストレージデバイスから前記特定のファイルの検索されたコピーを検索することと、検索された前記コピーを前
記１つ以上のプロセッサにローカルな前記キャッシュ中に格納することとを更に含む、請求項２に記載の方法。

【請求項4】

least recently used (LRU)アルゴリズムを実装することによって、検索された前記コ
ピーがより高速のメモリ又はより遅いメモリの何れに格納されるかを判定することを更に含む、請求項３に記載の方法。

【請求項5】

前記LRUアルゴリズムを実装することは、前記キャッシュから除去される、前記複数の
ファイルの内の１つ以上のファイルの１つ以上のコピーを特定することを更に含む、請求項４に記載の方法。

【請求項6】

前記第１のファイルをキャッシュしている前記第１の実行ノードを特定することは、前記第１の実行ノードのキャッシュ内に何が格納されているかを特定するために、前記メタデータ中のリストを調べることを含む、請求項１に記載の方法。

【請求項7】

前記実行プラットフォームの各実行ノードはキャッシュを含み、前記キャッシュは、第１のストレージ部分と第２のストレージ部分とを含み、前記第１のストレージ部分は、前記第２のストレージ部分よりもかなり高速である、請求項１に記載の方法。

【請求項8】

前記クエリは、実質的に同時に前記複数のファイルの内の各ファイルに前記実行プラットフォームによって適用される単一の命令を含む、請求項１に記載の方法。

【請求項9】

実行ノードのキャッシュ中にファイルが格納されていないと判定することに応答して、
前記ファイルのどの部分が前記クエリを処理するために用いられるかを判定することと、
リモートストレージデバイスから、前記クエリを処理するために用いられる前記ファイルの前記部分のみを検索すること、
によって前記ファイルを前記リモートストレージデバイスから検索することを更に含む、請求項１に記載の方法。

【請求項10】

前記実行ノードの前記キャッシュに、前記クエリを処理するために用いられる前記ファイルの前記部分を格納すること、を更に含む、請求項９に記載の方法。

【請求項11】

前記複数の実行ノードの内の実行ノードの１つ以上のプロセッサによって、それに割り当てられた特定のファイルのコピーが前記１つ以上のプロセッサにローカルなキャッシュ内に存在するか否かを判定することと、
前記特定のファイルのコピーが前記キャッシュ内に何ら存在しないと判定することに応答して、前記複数の共有ストレージデバイスから前記ファイルの検索されたコピーを前記１つ以上のプロセッサによって検索することと、
前記キャッシュに検索された前記コピーを格納する前に、検索された前記コピーのデータ構造を改変すること、を更に含む、請求項１に記載の方法。

【請求項12】

検索された前記コピーの前記データ構造を改変することは、検索された前記コピーを解読すること、を含む、請求項１１に記載の方法。

【請求項13】

検索された前記コピーの前記データ構造を改変することは、検索された前記コピーを解凍すること、を含む、請求項１１に記載の方法。

【請求項14】

データベースのデータを共同して格納する複数の共有ストレージデバイスと、
複数の実行ノードを含む実行プラットフォームであって、ここで、実行プラットフォー
ムの各実行ノードは、前記複数の共有ストレージデバイスから独立している、前記実行プラットフォームと、
前記データベースのデータに関係するメタデータであって、ここで、前記メタデータは、前記データベースのデータ及び前記実行プラットフォームとは別に格納される、前記メタデータと、
メモリに格納され１つ以上のプロセッサにより実行されるソフトウェアプログラムを含むリソースマネージャであって、
前記データベースのデータに向けられたクエリを受信することと、
前記クエリに応答して処理される必要がある、前記データベースのデータ内の複数のファイルを特定することであって、ここで、前記複数のファイルは前記メタデータに基づき特定されることと、
処理される必要がある前記複数のファイルの内の第１のファイルをキャッシュしている、前記複数の実行ノードの内の第１の実行ノードを特定することであって、ここで、前記第１の実行ノード及び前記第１のファイルは、前記実行プラットフォームに渡る複数のキャッシュ中に格納された全てのファイルの表示を含む前記メタデータ中のリストに基づき特定されることと、
前記クエリのタスクとして処理するために、前記実行プラットフォームの前記複数のノードの内の異なるノードに、前記複数のファイルの内の異なるファイルを割り当てることであって、ここで、前記第１のファイルは前記第１の実行ノードに割り当てられることと
をするようにプログラムされた前記リソースマネージャと
を含む、システム。

【請求項15】

前記実行プラットフォームの各実行ノードは、少なくとも１つのローカルプロセッサと少なくとも１つのキャッシュとを含み、各実行ノードの前記少なくとも１つのキャッシュは、メモリデバイスとディスクストレージデバイスとを含む、請求項１４に記載のシステム。

【請求項16】

前記実行プラットフォームの各実行ノードは、
それに割り当てられた特定のファイルのコピーがそのローカルキャッシュ内に存在するか否かを判定することと、
前記特定のファイルの前記コピーが前記ローカルキャッシュ内に存在しないと判定することに応答して、前記複数の共有ストレージデバイスから前記特定のファイルを検索することと、
前記メモリデバイス又は前記ディスクストレージデバイスの何れに前記コピーを格納するかを判定することと
をするようにプログラムされる、請求項１５に記載のシステム。

【請求項17】

前記実行プラットフォームは、複数の仮想ウェアハウスにセグメント分割され、それらの内の各仮想ウェアハウスは、前記複数の実行ノードの内の多数の実行ノードを含む、請求項１４に記載のシステム。

【請求項18】

前記実行プラットフォームの各実行ノードは、それに割り当てられた特定のファイルのコピーと関連付けられたデータ構造を、そのキャッシュ中に前記特定のファイルを格納する前に改変するようにプログラムされる、請求項１４に記載のシステム。

【請求項19】

メモリ中に格納され１つ以上のプログラムにより実行されるソフトウェアプログラムを含むリソースマネージャによって、複数の共有ストレージデバイス内に共同して格納されたデータベースのデータに向けられたクエリを受信することであって、ここで、前記リソースマネージャは、前記データベースのデータに関係するメタデータに結合されることと
、
前記クエリに応答して処理される必要がある、前記データベースのデータ内の複数のファイルを前記リソースマネージャによって特定することであって、ここで、前記複数のファイルは前記メタデータに基づき特定されることと、
処理される必要がある前記複数のファイルの内の第１のファイルをキャッシュしている、実行プラットフォームの複数の実行ノードの内の第１の実行ノードを前記リソースマネージャによって特定することであって、ここで、前記第１の実行ノード及び前記第１のファイルは前記メタデータに基づき特定されることと、
前記クエリのタスクとして処理するために、前記複数の実行ノードの内の実行ノードに前記複数のファイルの内の各ファイルを前記リソースマネージャによって割り当てることであって、ここで、前記第１のファイルは前記第１の実行ノードに割り当てられることとを含む、方法。

【請求項20】

前記複数の実行ノードの各々はキャッシュを含み、前記複数の実行ノード中の前記キャッシュは、前記リソースマネージャにより管理される分散キャッシュを含む、請求項１９に記載の方法。

【発明の詳細な説明】

【技術分野】

【0001】

＜関連出願への参照＞
この出願は、２０１４年２月１９日出願の“Apparatus and method for enterprise data warehouse data processing on cloud infrastructure,”という発明の名称の米国仮出願第６１／９４１，９８６号の利益を主張し、その開示は、ここに、参照によって全体が組み込まれる。

【0002】

＜技術分野＞
本開示は、データのキャッシングを管理するリソース管理システム及び方法に関する。

【背景技術】

【0003】

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

【0004】

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

【0005】

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

【図面の簡単な説明】

【0006】

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

【0007】

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

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

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

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

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

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

【図7】データ格納・検索動作を管理する方法の実施形態を図示するフロー図である。

【図8】データキャッシュを管理する方法の実施形態を図示するフロー図である。

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

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

【0008】

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

【0009】

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

【0010】

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

【0011】

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

【0012】

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

【0013】

実施形態は、また、クラウドコンピューティング環境に実装されてもよい。この記述及び以下の請求項においては、「クラウドコンピューティング」は、仮想化を介して迅速に提供可能で、最小の管理努力あるいはサービスプロバイダ相互作用でリリース出来、それに応じてその後スケーリング出来る、構成可能なコンピューティングリソース（例えば、ネットワーク、サーバ、ストレージ、アプリケーション、及びサービス）の共有プールへの、ユビキタスで、便利で、オンデマンドなネットワークアクセスを可能にするモデルとして定義されてもよい。クラウドモデルは、様々な特性（例えば、オンデマンドセルフサービス、広範なネットワークアクセス、リソースプーリング、迅速な柔軟性（rapid elasticity）、及び、測定されたサービス（measured service））、サービスモデル（例えば、ソフトウェアアズアサービス(“SaaS”)、プラットフォームアズアサービス(“PaaS”)、及び、インフラストラクチャアズアサービス(“IaaS”)）、及び、展開モデル（例えば、プライベートクラウド、コミュニティクラウド、公衆クラウド、及び、ハイブリッドクラウド）から構成出来る。

【0014】

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

【0015】

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

【0016】

記述したシステム及び方法においては、データストレージシステムは、SQL(Structured Query Language)ベースのリレーショナルデータベースを利用する。しかし、これらのシステム及び方法は、データ格納・検索プラットフォーム内にデータを格納し検索するために、任意のデータストレージアーキテクチャを用い、任意の言語を用いて、任意のタイプのデータベース、並びに任意のタイプのデータ格納・検索プラットフォームに適用可能である。ここに記述されるシステム及び方法は、異なる顧客／クライアント間、及び同一の顧客／クライアント内の異なるユーザ間でのコンピュータリソース及びデータの隔離をサポートするマルチテナントシステムを更に提供する。

【0017】

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

【0018】

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

【0019】

リソースマネージャ１０２は、以下に詳しく議論するように、様々なデータストレージ及びデータ検索タスクを実行する複数のコンピューティングリソースを提供する、実行プラットフォーム１１２に更に結合される。実行プラットフォーム１１２は、ストレージプラットフォーム１１４の一部である、複数のデータストレージデバイス１１６、１１８、１２０に結合される。３つのデータストレージデバイス１１６、１１８、及び１２０が図１に示されているが、実行プラットフォーム１１２は、任意の数のデータストレージデバイスと通信することが出来る。幾つかの実施形態においては、データストレージデバイス１１６、１１８、及び１２０は、１つ以上の地理的場所に配置されたクラウドベースのストレージデバイスである。例えば、データストレージデバイス１１６、１１８、及び１２０は、公衆クラウドインフラストラクチャあるいはプライベートクラウドインフラストラクチャの一部であってもよい。データストレージデバイス１１６、１１８、及び１２０は、ハードディスクドライブ（HHD)、固体デバイス（SSD)、ストレージクラスタ、Amazon S3（商標）ストレージシステム、あるいは、任意の他のデータストレージ技術であってもよい。更に、ストレージプラットフォーム１１４は、分散ファイルシステム（Hadoop Distributed File Systems (HDFS)など）、及びオブジェクトストレージシステムなどを含むことが出来る。

【0020】

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

【0021】

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

【0022】

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

【0023】

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

【0024】

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

【0025】

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

【0026】

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

【0027】

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

【0028】

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

【0029】

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

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

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

【0056】

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

【0057】

図８は、データキャッシュを管理する方法８００の実施形態を図示するフロー図である。まず、方法８００は、８０２において、ユーザからのクエリを受信（あるいは、特定）する。方法８００は、８０４において、受信したクエリを処理するために必要な複数のファイルを特定する。実質的に同時に複数のファイルを処理するために、複数のファイルのそれぞれは、８０６において、処理のために、特定の実行ノードに分配される。特定の実施形態においては、任意の数の実行ノードが、複数のファイルを処理するために用いられる。実行ノードのそれぞれは、その実行ノードに分配されたファイルに基づいて、８０８において、クエリを実行するための命令を受ける。

【0058】

方法８００は、８１０において、実行ノードに分配されたファイルが実行ノードのキャッシュに格納されているか否かを各実行ノードが判定することとして継続する。実行ノードのキャッシュは、「ローカルキャッシュ」と呼ぶことも出来る。ファイルが実行ノードのキャッシュに既に格納されている場合、実行ノードは、８１６において、それらのキャッシュされたファイルを用いて、クエリを処理する。しかし、１つ以上のファイルが実行ノードのキャッシュに格納されていない場合は、実行ノードは、８１２において、リモートストレージデバイスから、キャッシュされていないファイルを検索する。実行ノードは、８１４において、ローカルキャッシュに、検索されたファイルを格納し、８１６において、検索されたファイルを用いて、クエリを処理する。幾つかの実施形態においては、実行ノードは、ローカルキャッシュにファイルを格納する前に、検索されたファイルを改変する。例えば、実行ノードは、暗号化されたファイルを解読し、あるいは、圧縮されたファイルを解凍することが出来る。キャッシュする前にファイルを解読あるいは解凍することにより、実行ノードは、ローカルキャッシュからそれがアクセスされる度にファイルを解読あるいは解凍するのではなく、一回のみ改変を行う。

【0059】

クエリを処理した後、実行ノードは、８１８において、ローカルキャッシュの現在の状態に基づいて、メタデータ情報を更新する。メタデータ１１０（図１）は、各実行ノードにキャッシュされたデータについての情報を格納する。従って、実行ノード内のデータが更新される（例えば、新規のデータがキャッシュされる、あるいは、データが高速メモリから遅いHDDに移動される）たびに、メタデータ１１０は、実行ノード更新を反映するために更新される。

【0060】

幾つかの実施形態においては、受信されたクエリは、単一の命令を含む。その単一の命令は、実質的に同時に、複数の実行ノードのそれぞれによって実装される。複数の実行ノードのそれぞれは、同一の命令を実装するが、各実行ノードは、命令が実装される異なるファイルについて責任を負っている。従って、単一の命令は、相互に並列に、複数の実行ノードによって複数の異なるデータファイル上に実装される。

【0061】

ここに記述した例示的システム及び方法は、単一の仮想ウェアハウス内の、あるいは複数の仮想ウェアハウスに渡る、分散キャッシュアーキテクチャを提供する。特定の仮想ウェアハウス内の各実行ノードは、自身のキャッシュを有する。特定の仮想ウェアハウス内の複数の実行ノードは、分散キャッシュ（つまり、複数の実行ノードに渡って分散された）を形成する。他の実施形態においては、キャッシュは、複数の異なる仮想ウェアハウス内に含まれる複数の実行ノードに渡って分散されることが出来る。

【0062】

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

【0063】

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

【0064】

幾つかの実施形態においては、実行ノードに含まれる１つ以上のキャッシュは、異なる種類のデータストレージデバイスを含むマルチレベルキャッシュである。例えば、特定のキャッシュは、異なるデータアクセス速度を提供するデータストレージデバイスの階層を有することが出来る。一実施形態においては、キャッシュは、最速のデータアクセス速度を提供するメモリ、中間のデータアクセス速度を提供する固体ドライブ（SSD）、及びより遅いデータアクセス速度を提供するハードディスクドライブ（HDD）を含む。リソースマネージャ１０２（図１）及び／または、他のシステムは、どのデータが異なるデータストレージデバイスに格納されるかを管理することが出来る。例えば、もっとも頻繁にアクセスされるデータは、メモリに格納され、わずかな頻繁でアクセスされるデータは、ハードディスクドライブに格納される。幾つかの実施形態においては、least-recently used (LRU) アルゴリズムは、複数のストレージデバイスにおけるデータのストレージを管理するために利用される。例えば、LRUアルゴリズムは、特定のデータを高速のメモリあるいはより遅いストレージデバイスのいずれに格納するかを判定することが出来る。幾つかの実施形態においては、LRUアルゴリズムは、どのデータをキャッシュから除去するかを判定することも出来る。

【0065】

幾つかの実施形態においては、あるファイルの一部のみがキャッシュされる。例えば、データが列形式で格納され、ファイル内のある列のみが定期的にアクセスされている場合、システムは、アクセスされる列をキャッシュする（及び、他の列をキャッシュしない）ことを選択することが出来る。このアプローチは、キャッシュストレージ空間を節約し、利用可能なキャッシュリソースの効果的な使用を提供する。更に、このアプローチは、リモートストレージデバイスからキャッシュへコピーされるデータ量を削減する。リモートストレージデバイスからファイル全体をコピーするのではなく、関連した列のみが、リモートストレージデバイスからキャッシュにコピーされる。他の実施形態においては、記述されたシステム及び方法は、定期的にアクセスされているファイル内のある行をキャッシュする。

【0066】

更に、記述したシステム及び方法は、特定のクエリに関係ない場合には、そのデータの部分に最初にアクセスする必要なく、データのその部分を切り取ることが出来る。例えば、システム及び方法は、水平的に（システムが、アクセスされる必要のある行の部分集合を知っている）且つ垂直的に（参照された列のみロードされる）切り取ることにより、リモートストレージデバイスからロードされるデータ量を最小化する。これは、格納されたデータとは別に、メタデータ（つまり、格納されたデータに関連したメタデータ）を格納することにより達成される。このメタデータは、システム及び方法が、どのファイル（及び、どのファイル部分）が、特定のタスクのためにアクセスされる必要があるかを判定することを可能とする。

【0067】

幾つかの実施形態においては、ここに記述されるシステム及び方法は、特定のキャッシュに関連したメタデータ状態を保存することが出来る。例えば、メタデータ状態情報は、キャッシュに格納された全ファイル（あるいは、ファイルの部分）のリストと、各ファイル（あるいは、ファイルの部分）がアクセスされた最後の時間とを含むことが出来る。このメタデータ状態情報は、実行ノードあるいは仮想ウェアハウスが休眠されたときに保存される。その後、実行ノードあるいは仮想ウェアハウスが復帰したときは、メタデータ状態情報は、キャッシュを前もって準備するために用いられることが出来、それにより休眠が発生したときと同じ状態にキャッシュを復帰する（つまり、同一のデータファイルを格納する）。このアプローチを用いると、キャッシュは、割り当てられたタスクに基づいて、ある期間に渡ってデータが再投入される必要が無い。むしろ、キャッシュは、空のキャッシュで開始するタイムラグなしに、以前の状態に復帰するために、データが直ぐに投入される。このプロセスは、「ウォーミングキャッシュ」と呼ばれることが出来る。

【0068】

ここに議論されるメタデータは、ファイル内のオフセットについての情報を含むことが出来る。例えば、メタデータは、特定のファイルのすべての部分を特定してもよく、ファイルのマップ（つまり、ファイルのすべての部分を特定するマップ）を含んでもよい。ファイルの部分に関連したメタデータは、ファイル名、ファイルサイズ、ファイルが属するテーブル、列サイズ、及び列位置などを含むことが出来る。列位置は、列オフセット（例えば、ファイルの開始からのオフセット）として表現されることが出来る。列オフセットは、ファイル内の特定の位置を指定する。幾つかの実施形態においては、このメタデータは、ファイルヘッダの最初の数バイトに含まれる。従って、システムは、メタデータデータベース（例えば、図１のデータベース１１０）にアクセスすることなく（メタデータに規定されるファイルのマップを用いて）、どのようにファイルの部分にアクセスするかをファイルヘッダから決定することが出来る。

【0069】

特定の実装においては、キャッシュは、メモリ及びローカルディスクストレージデバイスなどの、複数のストレージデバイスを用いることが出来る。キャッシュヒット率を最大化するために、最近アクセスされていないファイル（あるいは、ファイルの部分）は、より頻繁にアクセスされている他のファイル（あるいは、他のファイルの部分）にストレージ空間を提供するために、キャッシュから除去される。

【0070】

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

【0071】

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

【0072】

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

【0073】

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

【0074】

I/Oデバイス９１０は、データ及び／またはその他の情報がコンピュータデバイス９００へ入力され、あるいはこれから検索されることを可能とする様々なデバイスを含む。例示的I/Oデバイス９１０は、カーソル制御デバイス、キーボード、キーパッド、マイクロフォン、モニタあるいはその他のディスプレイデバイス、スピーカ、プリンタ、ネットワークインタフェースカード、モデム、レンズ、CCD、またはその他の画像捕捉デバイスなどを含む。

【0075】

インタフェース９０６は、コンピューティングデバイス９００が他のシステム、デバイス、あるいはコンピューティング環境と相互作用できるようにする様々なインタフェースを含む。例示的インタフェース９０６は、ローカルエリアネットワーク（LAN）、ワイドエリアネットワーク（WAN）、無線ネットワーク、及びインターネットへのインタフェースなどの任意の数の異なるネットワークインタフェースを含む。

【0076】

バス９１２により、プロセッサ９０２、メモリデバイス９０４、インタフェース９０６、大容量ストレージデバイス９０８、及び／またはI/Oデバイス９１０は、バス９１２に結合される他のデバイスあるいはコンポーネントと共に、相互に通信することが可能となる。バス９１２は、システムバス、PCIバス、IEEE１３９４バス、及びUSBバスなどの１つ以上の数種類のバス構造を表す。

【0077】

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

【0078】

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

【図1】

【図2】

【図3】

【図4】

【図5】

【図6】

【図7】

【図8】

【図9】