JP2017507424A - データ管理システム及び方法 - Google Patents

Abstract

例示的なデータ管理システム及び方法が記述される。一実装においては、方法は、受信されたクエリに基づいて、処理すべき複数のファイルを同定し、複数のファイルの処理に利用可能な複数の実行ノードを同定する。方法は、最初に、複数のファイルの一部をそれぞれ含む複数のスキャンセットを生成し、ファイル割り当てモデルに基づいて、実行ノードのうちの一つを各スキャンセットに割り当てる。複数のスキャンセットは、複数の実行ノードによって処理される。特定の実行ノードが、その割り当てられたスキャンセット内のすべてのファイルを処理し終わっていることを、方法が判定する場合、処理されていないファイルは、他の実行ノードから特定の実行ノードへ再割り当てされる。【選択図】図８

Description

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

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

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

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

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

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

ここに記述するシステム及び方法の例示的実施形態を図示するブロック図である。 リソースマネージャの実施形態を図示するブロック図である。 実行プラットフォームの実施形態を図示するブロック図である。 複数の仮想ウェアハウスを介して、複数のデータベースにアクセスする複数のユーザを有する例示的な動作環境を図示するブロック図である。 負荷バランサと、仮想ウェアハウスグループに含まれる複数の仮想ウェアハウスを介して、複数のデータベースにアクセスする複数のユーザを有する他の例示的な動作環境を図示するブロック図である。 複数の分散仮想ウェアハウスと仮想ウェアハウスグループを有する他の例示的な動作環境を図示するブロック図である。 データストレージと検索動作を管理するための方法の実施形態を図示するフロー図である。 複数の実行ノードによる複数のファイルの処理を管理するための方法の実施形態を図示するフロー図である。 実行ノードからのファイルの奪取を管理するための方法の実施形態のフロー図である。 コンシステントなハッシングを用いた、実行ノードへのファイルの割り当ての例示的実施形態を図示する。 コンシステントなハッシングを用いた、実行ノードへのファイルの割り当ての例示的実施形態を図示する。 コンシステントなハッシングを用いた、実行ノードへのファイルの割り当ての例示的実施形態を図示する。 コンシステントなハッシングを用いた、実行ノードへのファイルの割り当ての例示的実施形態を図示する。 例示的なコンピューティングデバイスを図示するブロック図である。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

環境５００は、１つの仮想ウェアハウスグループ５１６を示すが、別の実施形態は、任意の数の仮想ウェアハウスにそれぞれ関連する、任意の数の仮想ウェアハウスグループを含むことが出来る。特定の環境内の仮想ウェアハウスグループの数は、動的で、ユーザ及び、環境内の他のシステムのニーズの変化に基づいて、変化することが出来る。

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

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

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

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

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

図８は、複数の実行ノードによる複数のファイルの処理を管理するための方法８００の実施形態を図示するフロー図である。特定の実施形態においては、方法８００は、リソースマネージャ１０２によって実行される。最初に、方法８００は、８０２において、ユーザからのクエリを受信（または、同定）し、８０４において、受信したクエリを処理するのに必要な複数のファイルを同定する。特定のクエリを処理するために必要なファイルは、クエリごとに変化するだろう。クエリパラメータとクエリ命令は、処理されるべきデータを示し、それによって、データにアクセスするために必要なファイルを示す。例えば、クエリが、特定の日付範囲における特定の会社用の金融記録に関連している場合、必要なファイルは、その特定の会社の、その特定の日付範囲内におけるデータを含むすべてのファイルを含む。複数のファイルを実質的に同時に処理するために、複数のファイルは、複数の実行ノードに分散される。これを達成するために、方法８００は、８０６において、複数のファイルを処理するために現在利用可能な複数の実行ノードを同定する。

・ 方法８００は、８０８において、複数のスキャンセットを生成することにより継続し、各スキャンセットは、複数のファイルの一部を含む。スキャンセットは、１以上のファイルの任意の集合である。すべてのスキャンセットの和集合は、受信したクエリを処理するために必要なすべてのファイルを含む。異なるスキャンセットは、異なる数のファイルを含むことが出来る。各スキャンセットは、最初に、コンシステントなファイル割り当てモデルに基づいて、特定の実行ノードに割り当てられる。これは、スキャンセットファイルの最初の割り当てである。というのも、あるファイルは、以下に議論するように、続いて、異なる実行ノードに再割り当てされうるからである。コンシステントなファイル割り当てモデルは、実行ノードにファイルを割り当てるためのアプローチを規定し、クエリに関連したファイルが処理のために実行ノードに割り当てられるたびに用いられる。同一のファイル割り当てモデルを繰り返し用いることにより、殆どのファイルは、処理のために同一の実行ノードに割り当てられ、それによって、高いキャッシュヒット率を維持する実行ノードのキャッシュ内に割り当てられたファイルが既に在在する可能性を増加させる。各スキャンセット内のファイルは、コンシステントなファイル割り当てモデルに基づいて配置（または、順序付け）される。幾つかの実施形態においては、（例えば、類似のファイルにアクセスする複数のクエリについて）配置が複数回繰り返されたときに配置が同一となるように、各スキャンセット内のファイルは、それらのサイズに基づいて配置される。例えば、スキャンセット内のファイルは、最大から最小へと、または最小から最大へと配置されることが出来る。以下に議論するように、スキャンセットの実行ノードへの割り当ては、例えば、コンシステントなハッシングアプローチを用いることが出来る。

幾つかの実施形態においては、任意のアルゴリズムが、スキャンセットを実行ノードに割り当てるために用いられることが出来る。このアルゴリズムの目的は、実行ノードが、そのキャッシュの中でファイルを見つける確率が最大化されるように、スキャンセットを割り当てることである。これは、スキャンセットを実行ノードに割り当てるために、同一のアルゴリズムまたは同一のアプローチを用いることによって達成されることが出来る。同様にコンシステントな割り当てスキャンセットにより、実行ノードは、必要なファイルをそのキャッシュ内に持つ傾向がより高くなる。更に、各実行ノードに割り当てられるファイルをコンシステントに順序付ける（つまり、実行ノードがそのファイルを処理する順序）ことは、最初に処理されるファイルがキャッシュ内にある可能性を増加するだろう。幾つかの実施形態においては、キャッシュにない可能性が最も高いファイルが最後に処理されるように、ファイルが順序付けられ、ここに議論するように、それによって、それらのファイルが他の実行ノードに奪取されるだろう可能性を増加する。

複数の実行ノードは、８１０において、並列に、関連するスキャンセット内のファイルの処理を開始する。特定のスキャンセット内のファイルは、コンシステントなファイル割り当てモデルを用いて、予め決定された配置（または順番）で実行ノードにより処理される。特定の実行ノードが、割り当てられたスキャンセット内のすべてのファイルを処理し終わると、その実行ノードは、８１２において、ファイル奪取モデルに基づいて、処理されていないファイルを他の実行ノードから奪取する。ここに用いられるように、ファイルを「奪取する」とは、第１の実行ノードから第２の実行ノードにそのファイルを再割り当てすることを指す。語句「奪取する」及び「再割り当てする」は、ここでは、相互に入れ替えて用いられる。ファイル奪取モデルは、実行ノード間でファイルを奪取するためのアプローチを規定する。特定の実行ノード用にファイルを奪取するとき、スキャンセットが生成されたときに、他の実行ノード（つまり、処理されていないファイルを有する実行ノード）が利用できなかった場合に、その実行ノードは、最初にそれが受信しただろうファイルを割り当てられる。幾つかの実施形態においては、奪取されたファイルは、スキャンセット内で、逆順で選択される（例えば、奪取されたファイルは、スキャンセット内のファイルの順序リストの下から選択される）。

ファイル奪取モデルに基づいて、特定の処理されていないファイルは、利用可能な実行ノードによって、処理するために選択される。この処理されていないファイルは、８１４において、元の実行ノードのスキャンセットから除去され、利用可能な実行ノードによって処理される。方法８００は、すべてのファイルを処理し終わった他の実行ノードを同定することによって継続し、その実行ノードに、処理されていないファイルを奪取するよう命令する。これは、すべてのスキャンセット内にあるすべてのファイルが処理されるまで継続する。幾つかの実施形態においては、ファイル奪取モデルは、ここに議論されるように、コンシステントなハッシングアルゴリズムを用いる。他の実施形態においては、ファイル奪取モデルは、ある実行ノードから他の実行ノードへ奪取されるべき（または、再割り当てされるべき）ファイルのコンシステントな選択を提供する任意のアルゴリズムまたはプロセスを用いることが出来る。ファイルのこのコンシステントな選択は、一般に、キャッシュヒット率を増加させる。

奪取プロセスは、すべての実行ノードリソースを十分に利用することにより、システム全体の性能を改善する。他の実行ノードが処理用に待機しているファイルを有している間に、ある実行ノードは、アイドル状態に留まることを許可するのではなく、アイドル状態の実行ノードは、他の実行ノードプロセスと並行して、待機しているファイルを処理することが出来る。処理されていないファイルを奪取する（または、再割り当てする）ことに関する追加の詳細が以下に議論される。

幾つかの実施形態においては、ファイル奪取プロセスは、また、コンシステントなハッシングモデルを用いる。これらの実施形態においては、各実行ノードは、異なるレベルではあるが、全てのファイルの所有権を有する。例えば、所有権の最高レベル（レベル０）は、そのファイルがその実行ノードに最初に割り当てられたことを示す。特定の実行ノードが、最初に割り当てられたファイル（レベル０のファイル）を全て処理してしまった後、その実行ノードは、それから、レベル１のファイルを処理し、その後、レベル２のファイルを処理する、などのようにして進行する。レベル１のファイルは、直接隣接する実行ノードが無かった場合に、そのファイルが実行ノードに最初に割り当てられるだろうことを示す。幾つかの実施形態においては、ある実行ノードが他の実行ノードからファイルを奪取するとき、「奪取する」実行ノードは、それが、唯一の隣接する（つまり、ファイルが奪取される他の実行ノードに隣接する）実行ノードであるので、そのファイルを奪取することが出来る唯一の実行ノードである。これは、同一のファイルを奪取しようとする場合の複数の実行ノード間の任意の競合を防止する。

特定の実装においては、クエリスケジューラ及びコーディネータ２１８（図２）は、これらの種類のファイルアクティビティの管理に責任がある。幾つかの実施形態においては、クエリスケジューラ及びコーディネータ２１８は、様々な仮想ウェアハウスと仮想ウェアハウス内の実行ノード間でのファイルの分配を管理するファイルマネージャを含む。このファイルマネージャは、また、異なる実行ノード間でのファイルの奪取（または、再割り当て）を管理する。

ここに議論するコンシステントなハッシングアルゴリズムの使用は、ピア・ツー・ピア動作を可能とし、それによって、個々の実行ノードのそれぞれを管理するための、中央論理に対するニーズを排除する。むしろ、各実行ノードは、リング内のすべての他の実行ノードを知っている。ファイルを奪取するとき、「奪取する」実行ノードは、奪取されるべき利用可能なファイルを持っているか否かを、隣接する実行ノードにクエリる。隣接する実行ノードに、奪取すべきレベル１のファイルが残っていない場合には、奪取する実行ノードは、リング内の次の実行ノードへ移動するだろう。どの実行ノードにもレベル１のファイルが残っていない場合には、奪取する実行ノードは、レベル２のファイルに移動し、以下同様である。

図９は、実行ノードからのファイルの奪取を管理するための方法９００の実施形態を図示するフロー図である。特定の実施形態においては、方法９００は、リソースマネージャ１０２によって実行される。最初に、第１の実行ノードは、９０２において、第２の実行ノードからファイルを奪取するように命令される。図８について上記したように、例えば、特定の実行ノードが、その割り当てられたスキャンセット内のすべてのファイルを処理したが、（他のノードのスキャンセット内の）追加のファイルが処理されずに残っているときに、このファイル奪取が発生することが出来る。

第１の実行ノードは、９０４において、リモートストレージデバイスからファイルの検索を開始する。方法９００は、９０６で、第１の実行ノードによる（リモートストレージデバイスからの）ファイルの検索が、完了したか否かを判定する。ファイルの検索が完了した場合、第２の実行ノードは、９０８において、ファイルを処理しないように命令される。幾つかの実施形態においては、第２の実行ノードにファイルを処理しないように命令することに加え、第２の実行ノードは、そのスキャンセットからファイルを除去するように命令される。

第１の実行ノードが、９０６において、リモートストレージデバイスからのファイルの検索を完了していないならば、方法９００は、９１０において、第２の実行ノードが、ファイルの処理に利用可能となったか否かを判定する。第２の実行ノードが、ファイルの処理に利用可能でない場合、方法９００は、９０６において、第１の実行ノードによるファイル検索の完了のチェックに戻る。

第２の実行ノードが、９１０において、ファイルの処理に利用可能である場合、方法９００は、９１２において、第２の実行ノードのキャッシュにおいてファイルが利用可能であるか否かを判定する。ファイルが第２の実行ノードのキャッシュにない場合、方法９００は、９１８に分岐し、第１の実行ノードは、ファイルの検索と処理を継続し、第２の実行ノードは、ファイルの処理をしないように命令される。この状況では、第２の実行ノードは、ファイルをキャッシュしていなかったので、第２の実行ノードによる新規のファイル検索プロセスを開始するより速い可能性が高いので、第１の実行ノードは、リモートストレージデバイスからのファイルの検索の継続を許可される。

９１２において、ファイルが第２のノードのキャッシュにおいて利用可能となっている場合、第１の実行ノードは、９１４において、ファイルを処理しないよう命令される。更に、第２の実行ノードは、９１６において、キャッシュされたファイルを処理するように命令される。この状況においては、第２の実行ノードが、ファイルの処理に利用可能であり、ファイルが、第２の実行ノードのキャッシュ内に既に在るので、依然、リモートストレージデバイスからファイルを検索している第１の実行ノードよりも速く、第２の実行ノードはファイルを処理することが出来る。

幾つかの実施形態においては、ある実行ノードは、他の実行ノードのキャッシュから直接ファイルをコピーすることによって、他の実行ノードからファイルを奪取することが出来る。従って、実行ノードが、リモートストレージシステムから、奪取されたファイルを検索するのではなく、他の実行ノードのキャッシュからファイルを検索るほうが速いであろう。

幾つかの実施形態においては、コンシステントなハッシングは、最初に、処理のために実行ノードにファイルを割り当て、実行ノードが最初に割り当てられたファイルを全て処理してしまったとき、ファイルを再割り当て（または、奪取）するための、基礎となるモデルとして用いられる。一実施形態においては、コンシステントなハッシングは、クラスタ内の各サーバに対して（例えば、物理サーバ識別子を用いて）、６４ビットハッシュ空間などの大きなハッシュ空間へのハッシュ化を実行する。最初にファイルを実行ノードに割り当てるために、ファイルは、ファイルの一意的な識別子を用いて、同様にハッシュ化される。そのファイルに関連した実行ノードは、ファイルのハッシュ化が実行された後、ハッシュ空間内に現れる第１の実行ノードである。このアプローチは、最大のハッシュ値に至った場合には、ゼロに「まき戻す」。

このコンシステントなハッシングアプローチを用いることは、ファイルの著しく異なる初期割り当てを引き起こすことなく、サーバ（及び、実行ノード）の追加または除去をサポートする。例えば、１０台のサーバを有するシステムにおいては、１台のサーバの追加は、約１０％のファイルの再割り当てを引き起こすだろう。従って、約９０％のファイルは再割り当てされない。特に、実行ノードの数が少ないとき、スキューの（幾つかの実行ノードが、他の実行ノードよりもより多くのファイル処理作業を実行する）リスクを最小化するために、幾つかの実施形態は、複数のハッシュ関数を用いて、ハッシュ空間内に、各実行ノードの複数のレプリカを生成する。特定の実装においては、システムは、各実行ノードに対して１２８個のレプリカを生成し、ハッシュ空間に対して、６４ビットのハッシュ値を用いることが出来る。

図１０Ａ〜図１０Ｄは、コンシステントなハッシングを用いて、実行ノードにファイルを割り当てる例示的実施形態を図示する。特定の実施形態においては、この実行ノードへのファイルの割り当ては、リソースマネージャ１０２によって実行される。図１０Ａは、３つの実行ノードへの１０個のファイルの割り当てを図示する。図１０Ａの円の頂点から開始して、時計回りに回ると、ファイル６とファイル３は、次の実行ノード（実行ノード３）に割り当てられ、それから、ファイル１、８、４、及び５は、次の実行ノード（実行ノード２）に割り当てられ、最後に、ファイル７、１０、９、及び２は、次の実行ノード（実行ノード１）に割り当てられる。

図１０Ｂは、他の実行ノード（実行ノード４）を追加した後の結果のファイル割り当てを示す。この例においては、実行ノード２と実行ノード３に関連したファイルは、図１０Ａから変化がない。図１０Ａの実行ノード１に関連したファイルは、図１０Ｂの実行ノード１と実行ノード４との間で共有される。従って、実行ノード４を追加した結果として、ほんの数個のファイルが再割り当てされる。

図１０Ａ及び図１０Ｂに示される例は、３つの実行ノードのみが利用できるので、スキューの問題（ある実行ノードは、他の実行ノードより多くのファイル処理作業を実行するという状況）を有するだろう。スキューの確率を減少するために、各実行ノードの複数のレプリカが、ハッシュ空間に提供される

図１０Ｃは、図１０Ａと同様の例を示すが、３つの実行ノードのそれぞれに対して８個のレプリカを用いている。このアプローチは、実行ノード間でのより均一なファイルの割り当てを提供する。

図１０Ｄは、他の実行ノード（実行ノード４）を追加した後の結果のファイル割り当てを示す。この例においては、実行ノード４の８個のレプリカがハッシュ空間に追加される。図１０Ｄに示されるように、ファイル１は、実行ノード３から新規の実行ノード４に移され、ファイル５は、実行ノード２から実行ノード４に移される。従って、図１０Ａ及び図１０Ｂに図示されるように、ファイルは、同一のノードから両者が移されるのではなく、２つの異なるノードから移される。

図１０Ａ〜図１０Ｂに示されるコンシステントなハッシング例は、実行ノードへのスキャンセット（または、個々のファイル）の初期割り当てに有益であり、ある実行ノードから他の実行ノードへのファイルの再割り当て（例えば、奪取）にも有益である。両方の例において、コンシステントなハッシングアプローチは、実行ノードによって処理されるファイルのキャッシュヒットの可能性を増加させる。

幾つかの実施形態においては、利用可能な実行ノードが、ファイルを奪取する準備が出来ている場合、コンシステントなハッシングアプローチは、初期ファイル割り当てが実行されたときに、他の実行ノード（ファイルが最初に割り当てられた実行ノード）が利用不可能であった場合、利用可能な実行ノードに割り当てられただろう処理されていないファイルを同定するために用いられる。このアプローチは、利用可能な実行ノードが、利用可能な実行ノード上に既にキャッシュされているファイルを奪取するだろう確率を増加させる。

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

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

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

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

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

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

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

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

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

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

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

Claims (20)

1. 受信したクエリに基づいて、処理するべき複数のファイルを同定することと、
   前記複数のファイルを処理するために利用可能な複数の実行ノードを同定することと、
   複数のスキャンセットを最初に生成し、ファイル割り当てモデルに基づいて、前記複数の実行ノードのうちの一つに前記スキャンセットのそれぞれを割り当てることであって、各スキャンセットは、前記複数のファイルの一部を含む、ことと、
   前記複数の実行ノードによって、前記複数のスキャンセットを処理することと、
   特定の実行ノードが、その割り当てられたスキャンセット内のすべてのファイルを処理し終わったか否かを判定することと、
   特定の実行ノードが、その割り当てられたスキャンセット内のすべてのファイルを処理し終わったことを判定することに応じて、
   第２の実行ノードから処理されていないファイルを再割り当てすることと、
   処理のために、前記特定の実行ノードへ、前記処理されていないファイルを割り当てることと、
   を含む方法。
2. 各ファイルのサイズに基づいて、各スキャンセット内の前記ファイルを配置することを更に含む、請求項１に記載の方法。
3. 前記割り当てられた実行ノードによってキャッシュされたファイルを優先付けるために、各スキャンセット内に前記ファイルを配置することを更に含む、請求項１に記載の方法。
4. 前記ファイル割り当てモデルは、コンシステントなハッシングモデルを用いる、請求項１に記載の方法。
5. 前記再割り当ての間に、前記最初に割り当てられた実行ノードの前記スキャンセットから、前記処理されていないファイルを除去することを更に含む、請求項１に記載の方法。
6. 処理されていないファイルを他の実行ノードから再割り当てすることは、割り当てられたスキャンセット内のすべてのファイルを処理し終わった前記実行ノードによって既にキャッシュされている、再割り当てすべきファイルを同定することを含む、請求項１に記載の方法。
7. 他の実行ノードからの処理されていないファイルを再割り当てすることは、ファイル奪取モデルに基づいて、再割り当てすべき、前記処理されていないファイルを選択することを含む、請求項１に記載の方法。
8. 前記ファイル奪取モデルは、異なる所有権レベルでのコンシステントなハッシュ化を用いる、請求項７に記載の方法。
9. 前記異なる所有権レベルは、前記複数の実行ノードのそれぞれによってファイルが処理される順序を決定する、請求項８に記載の方法。
10. 前記特定の実行ノードは、リモートストレージデバイスから、前記処理されていないファイルを検索する、請求項１に記載の方法。
11. 前記第２の実行ノードが、前記処理されていないファイルの処理に利用可能となるか否かを判定することと、
    前記第２の実行ノードが、前記処理されていないファイルをキャッシュしていたか否かを判定することと、
    前記特定の実行ノードが、前記リモートストレージデバイスから前記処理されていないファイルを検索し終わったか否かを判定することと、
    前記第２の実行ノードが利用可能となり、前記第２の実行ノードが、前記処理されていないファイルをキャッシュしており、且つ、前記特定の実行ノードが、前記リモートストレージデバイスから前記処理されていないファイルの検索を完了していないことを判定するのに応じて、前記処理されていないファイルの処理を停止するよう、前記特定の実行ノードに命令することと、
    を更に含む、請求項１０に記載の方法。
12. 前記第２の実行ノードが利用可能となり、前記第２の実行ノードが、前記処理されていないファイルをキャッシュしており、且つ、前記特定の実行ノードが、前記リモートストレージデバイスから前記処理されていないファイルの検索を完了していないことを判定するのに応じて、前記処理されていないファイルを処理するよう、前記第２の実行ノードに命令することを更に含む、請求項１１に記載の方法。
13. 受信したクエリに関連した複数のファイルを同定するように構成された要求処理モジュールと、
    前記複数のファイルの処理に利用可能な複数の実行ノードを同定するように構成された仮想ウェアハウスマネージャと、
    複数のスキャンセットを生成し、ファイル割り当てモデルに基づいて、前記複数の実行ノードのうちの一つに、前記スキャンセットのそれぞれを割り当てるように構成され、特定の実行ノードが、その割り当てられたスキャンセット内のすべてのファイルを処理し終わったか否かを判定し、特定の実行ノードが、その割り当てられたスキャンセット内のすべてのファイルを処理し終わったことを判定するのに応じて、第２のノードから処理されていないファイルを再割り当てし、処理のために、前記特定の実行ノードへ前記処理されていないファイルを割り当てるように更に構成されたトランザクション管理モジュールと、
    を備える装置。
14. 各スキャンセットは、前記複数のファイルの一部を含む、請求項１３に記載の装置。
15. 前記トランザクション管理モジュールは、各ファイルのサイズに基づいて、各スキャンセット内の前記ファイルを配置するように更に構成されている、請求項１３に記載の装置。
16. 前記ファイル割り当てモデルは、コンシステントなハッシングモデルを用いる、請求項１３に記載の装置。
17. 前記トランザクション管理モジュールは、ファイル奪取モデルに基づいて、前記処理されていないファイルを選択するように更に構成されている、請求項１３に記載の装置。
18. 前記ファイル奪取モデルは、コンシステントなハッシングモデルを用いる、請求項１７に記載の装置。
19. 受信されたクエリに関連した複数のファイルを同定するための要求を処理するための手段と、
    前記複数のファイルの処理に利用可能な複数の実行ノードを同定するために、仮想ウェアハウスを管理するための手段と、
    複数のスキャンセットを生成し、ファイル割り当てモデルに基づいて、前記複数の実行ノードのうちの一つに、前記スキャンセットのそれぞれを割り当てるための管理手段であって、特定の実行ノードが、その割り当てられたスキャンセット内のすべてのファイルを処理し終わったか否かを判定し、特定の実行ノードが、その割り当てられたスキャンセット内のすべてのファイルを処理し終わったことを判定するのに応じて、第２のノードから処理されていないファイルを再割り当てし、処理のために、前記特定の実行ノードへ前記処理されていないファイルを更に割り当てるための管理手段と、
    を備える装置。
20. 前記ファイル割り当てモデルは、コンシステントなハッシングモデルを用いる、請求項１９に記載の装置。