"各ノードが、オブジェクトベースのストレージを提供するアプリケーションのインスタンスを実行し、メタデータオブジェクトが、アレイに渡ってノード中に分散されたリージョンのセットのリージョンに格納され、所与のリージョンが、メタデータオブジェクト属性のハッシュおよびその結果生じるハッシュ値の所与のセットのビットの抽出により識別されるようになっている、ネットワーク化された独立ノードの冗長アレイにおいて、クエリ結果を管理する方法が、複数の独立ノードのうちの第1のノードによって、基準を満たしたオブジェクトのリストの要求をクライアントアプリケーションから受信すること、前記第1のノードによって、前記受信した要求に基づき全てのノードへクエリを出すこと、各ノードによって、リージョンに格納されているメタデータオブジェクトを使用してノード中のリージョンにわたりクエリを処理すること、前記第1のノードによって、全てのノードからのクエリの結果を統合し且つフィルタすること、及び、前記第1のノードによって、統合されフィルタされた結果を前記クライアントアプリケーションに返すこと、を有する方法。各ノードによってクエリを処理することが、セット中のクエリの結果を第1のノードに提供することを含み、全てのノードからのクエリの結果が、統合され、フィルタされ且つセット中の前記クライアントアプリケーションに返される、請求項1に記載の方法。前記第1のノードによって、前記クライアントアプリケーションに統合されフィルタされた結果の現在のセットを返した後、全てのノードからの結果の次のセットを要求し検索する前、結果の次のセットの前記クライアントアプリケーションからの要求を待つこと、を更に有する請求項2に記載の方法。セット中のクエリの結果を前記第1のノードに提供することは、クエリの処理の結果として、各リージョンからのプリセットされた数のオブジェクトを提供することを含む、請求項2に記載の方法。前記第1のノードによって、プリセットされた順序を生じさせるために統合されフィルタされた結果をソートすること、を更に有する請求項1に記載の方法。前記要求が、変更時間によるクエリ、ディレクトリによるクエリ、トランザクションによるクエリ、ネームスペースによるクエリ、及び、結果を通じてのページ、のうちの1つ以上を含む、請求書1に記載の方法。各ノードは、オブジェクトベースのストレージを提供するアプリケーションのインスタンスを実行し、メタデータオブジェクトが、アレイに渡ってノード中に分散されたリージョンのセットに格納され、所与のリージョンが、メタデータオブジェクト属性のハッシュおよびその結果生じるハッシュ値のビットの所与のセットの抽出により識別されるようになっている、ネットワーク化された独立ノードの冗長アレイにおいて、クエリ結果を管理する装置が、プロセッサ、メモリ、及び、ノードの各々のために備えられたクエリ結果管理モジュールを有し、前記クエリ結果管理モジュールが、クエリ結果管理モジュールがあるノードが、基準を満たしたオブジェクトのリストの要求をクライアントアプリケーションから受信する第1のノードであれば、受信した要求に基づき全てのノードにクエリを出し、リージョンに格納されているメタデータオブジェクトを使用して、ノード中のリージョンにわたってクエリを処理し、及び、前記クエリ結果管理モジュールがあるノードが前記第1のノードであれば、全てのノードからのクエリの結果を統合しフィルタする、ようになっており、統合されフィルタされた結果が前記クライアントアプリケーションに返される、装置。クエリを処理することが、セット中のクエリの結果を第1のノードに提供することを含み、及び、全てのノードからのクエリの結果が、セット中の前記クライアントアプリケーションに返されるために統合されフィルタされる、請求項7に記載の装置。前記クエリ結果管理モジュールがあるノードが第1のノードであれば、前記クエリ結果管理モジュールは、第1のノードによって、前記クライアントアプリケーションに統合されフィルタされた結果の現在のセットを返した後、全てのノードからの結果の次のセットを要求し検索する前、結果の次のセットの前記クライアントアプリケーションからの要求を待つ、請求項8に記載の装置。セット中のクエリの結果を第1のノードに提供することが、クエリの処理の結果として、各リージョンからプリセットされたオブジェクトの数を提供することを含む、請求項8に記載の装置。前記クエリ結果管理モジュールがあるノードが前記第1のノードである場合、前記クエリ結果管理モジュールは、プリセットされた順序を生じさせるために統合されフィルタされた結果をソートする、請求項7に記載の装置。請求項7に記載の独立ノードの冗長アレイ中のノードであって、メタデータオブジェクトへのアクセスを組織し提供することを含むノード中のメタデータオブジェクトを管理するメタデータマネージャを有し、前記メタデータマネージャが、そのノードの前記クエリ結果管理モジュールを含む、ノード。各ノードが、オブジェクトベースのストレージを提供するアプリケーションのインスタンスを実行し、メタデータオブジェクトが、アレイに渡るノード中に分散されたリージョンのセットに格納され、所与のリージョンが、メタデータオブジェクト属性のハッシュおよびその結果生じるハッシュ値のビットの所与のセットの抽出により識別される、ようになっている、ネットワーク化された独立ノードの冗長アレイにおいて、クエリ結果を管理するデータプロセッサを制御するための複数の指示を記憶する、コンピュータ読取り可能な記憶媒体であって、前記コンピュータ読取り可能な記憶媒体が、各ノードに提供され、前記複数の指示が、前記コンピュータ読取り可能な記憶媒体があるノードが、基準を満たしたオブジェクトのリストの要求をクライアントアプリケーションから受信する第1のノードであれば、受信した要求に基づき全てのノードにクエリを出すことをデータプロセッサにさせる指示、リージョンに格納されているメタデータオブジェクトを使用してノード中のリージョンにわたってクエリを処理することを前記データプロセッサにさせる指示、及び、前記コンピュータ読取り可能な記憶媒体があるノードが前記第1のノードであれば、前記第1のノードによって全てのノードからのクエリの結果を統合しフィルタすることを前記データプロセッサにさせる指示、を含む、コンピュータ読取り可能な記憶媒体。クエリを処理することが、セット中のクエリの結果を前記第1のノードに提供することを含み、及び、全てのノードからのクエリの結果が統合され、フィルタされ、セット中の前記クライアントアプリケーションに返される、請求項13に記載のコンピュータ読取り可能な記憶媒体。複数の指示が更に、コンピュータ読取り可能な記憶媒体があるノードが前記第1のノードであれば、統合されフィルタされた結果の現在のセットを前記第1のノードによって前記クライアントアプリケーションに返した後、全てのノードからの結果の次のセットを要求し検索する前、結果の次のセットの前記クライアントアプリケーションからの要求を待つことを前記データプロセッサにさせる指示、を含む、請求項14に記載のコンピュータ読取り可能な記憶媒体。セット中のクエリの結果を前記第1のノードに提供することが、クエリの処理の結果として、各リージョンからプリセットされた数のオブジェクトを提供することを含む、請求項14に記載のコンピュータ読取り可能な記憶媒体。複数の指示が更に、コンピュータ読取り可能な記憶媒体があるノードが前記第1のノードであれば、プリセットされた順序を生じさせるために統合されフィルタされた結果を前記第1のノードによってソートすることを前記データプロセッサにさせる指示、を含む請求項13に記載のコンピュータ読取り可能な記憶媒体。前記要求が、変更時間によるクエリ、ディレクトリによるクエリ、トランザクションによるクエリ、ネームスペースによるクエリ、及び、結果を通じてのページ、のうちの1つ以上を含む、請求項13に記載のコンピュータ読取り可能な記憶媒体。発明の以下の詳細な説明において、開示の一部を形成する添付図面について言及がされ、その中で、図面で限定なく示され発明が実施されるかもしれない典型的な実施例として示される。図面において、類似の数字は、いくつかの見解に渡って本質的に同様のコンポーネントについて説明する。更に、注目すべきは、下記のように、及び図面の中で示されるように、詳細な説明が、様々な典型的な実施例を提供しているが、本発明が説明され、ここに示された実施例に限らず、当業者に知られている又は知られる他の実施例まで及ぶ可能性がある事である。1つの実施例、この実施例あるいはこれらの実施例の明細書中の言及は、特定な特徴、構造あるいは実施例に関して説明された特性が、発明の少なくとも1つの実施例に含まれる事を意味し、明細中の様々な個所におけるこれらの句の出現は、必ずしも全ては、同じ実施例を指していない。更に、下記の詳細な説明において、多数の特定な詳細は、本発明についての完全な理解を提供するために述べられる。しかし、本発明を実行するためにこれらの特定な詳細が必ずしも全て必要ではないかもしれない事は、当業者に明らかであろう。他の状況において、有名な構造、材料、回路、プロセス及びインターフェースは、詳細に説明されておらず、かつ、本発明が不必要に不明瞭にならないようにブロック図の形式で示されるかもしれない。更に、以下に続く詳細な説明のいくつかの部分は、コンピュータ内のオペレーションのアルゴリズム及び記号表現の点から示される。これらのアルゴリズムの説明及び記号表現は、その他の当業者に最も効果的に彼らの革新の本質を伝えるためにデータ処理に優れている人々によって使われる手段である。アルゴリズムは、所望最終状態か結果に導く一連の定義されたステップである。本発明において、行なわれたステップは、具体的結果の達成のために具体的な量の物理的な操作を要求する。通常、必ずではないが、これらの量は、格納する、組み合わす、比較する、またそうでなければ、操作することができる電気的か磁気信号あるいは指示の形式をとる。これらの信号をビット、値、要素、記号、文字、用語、数、指示などと呼ぶために主に一般的用法の理由で、時々便利であると証明されてきた。しかし、これら全て及び同類項が適切な物理量に関係しているはずであり、これらの量に当てはまる単に便利なラベルである事も留意しておくべきである。特に別記しない限り、以下の議論から明らかなものとして、説明全体に渡って、処理すること、コンピューティング、計算すること、決定すること、表示すること等の用語を使う議論は、コンピュータシステムの登録及びメモリ内の物理的な電子の量として表わされたデータをコンピュータシステムのメモリ、登録、あるいは他の情報ストレージ、送信又はディスプレイデバイス内の物理量として同様に表わされた他のデータに操作し、変形するコンピュータシステムあるいは他の情報処理デバイスのアクション及びプロセスを含むかもしれない事を認識しておくべきである。本発明は、また、オペレーションをここで行なうための装置に関する。この装置は、要求された目的のために特別に構築されるかもしれない、あるいは、それは、1つ以上のコンピュータプログラムによって選択的に作動されたか再構成された1台以上の汎用コンピュータを含むかもしれない。そのようなコンピュータプログラムは、光ディスク、磁気ディスク、読み出し専用メモリ、ランダムアクセスメモリ、ソリッドステートデバイス及びドライブ、あるいは電子情報を格納するのにふさわしい他のタイプの媒体に制限されないが、これらのようなコンピュータ読取り可能な記憶媒体に格納されるかもしれない。ここに示されたアルゴリズムとディスプレイは、本質的にどんな特定なコンピュータあるいは他の装置とも関係がない。様々な汎用のシステムは、教えに従ってプログラムとモジュールと共にここに使用されてもよい、あるいは、希望の方法ステップを行なうためにもっと専門の装置を構築するのに便利であると言ってもよい。更に、本発明は、どんな特定なプログラミング言語に関しても説明されない。当然のことながら、ここに説明されるような発明の教えを実施するために、様々なプログラミング言語が使用されてもよい。プログラミング言語の指示は、1つ以上の処理デバイス、例えば中央処理装置CPU、プロセッサ又はコントローラによって実行されても良い。より詳しく以下に説明される発明の典型的な実施例は、フォールトトレラントデータベース管理システムにおけるクエリ結果を統合する装置、方法及びコンピュータプログラムを提供する。I固定コンテンツ分散データストレージニーズが、従来のテープ及び光学ストレージ解決法に取って代わるかそれを補う、高度に可用性、信頼性及び持続性のあるやり方で固定コンテンツのアーカイブストレージについて発展してきた。用語固定コンテンツは、典型的に、参照あるいは他の目的のためにそのままで保存される事が予想される任意のタイプのデジタル情報を指す。このような固定コンテンツの例としては、多くの例の中でもとりわけ、電子メール、文書、診断画像、チェック画像、音声録音、フィルム及びビデオなどが挙げられる。従来の独立ノード冗長アレイRAINストレージ手法は、このような固定コンテンツの情報資産を記憶するための大規模なオンラインアーカイブを生み出すために選択されるアーキテクチャとして登場した。RAINアーキテクチャは、ノードが必要に応じてクラスタに結合すること及びクラスタから退出することを可能にすることにより、ストレージクラスタを1つまたは複数のノードの障害から隔離する。RAINタイプのアーカイブは、データを複数のノード上で複製することにより、ノードの障害または除去を自動的に補償することができる。通常、RAINシステムは、閉システム内の同一コンポーネントから設計されたハードウェア機器として広く提供される。図1は、そのような計量可能なディスクベースのアーカイブのストレージ管理システムを示す。ノードは、異なるハードウェアから成るかもしれないし、従って、異種であると考えられるかもしれない。ノードは、典型的に、ストレージエリアネットワークSANでのような実際の物理的なストレージディスク、又は仮想ストレージディスクかもしれない1枚以上のストレージディスクにアクセスする。各ノード上で支援されるアーカイブクラスタアプリケーション及び任意でそのアプリケーションが実行する基本的なオペレーティングシステムは、同じ又は実質的に同じかもしれない。ハードウェアが異種かもしれないのに対して、各ノード上のオペレーティングシステムを含むかもしれないソフトウェアスタックは、対称である。システムを使用すると、図1で示されるように、企業は、文書、電子メール、衛星画像、診断画像、チェック画像、音声録音、ビデオなどのような様々なタイプの固定コンテンツ情報のための永久記録媒体を特に作成することができる。もちろん、これらのタイプは、単に例である。ハイレベルな信頼度は、独立サーバ上のデータの複製、あるいは、いわゆるストレージノードにより達成される。好ましくは、各ノードは、そのピアと対称である。従って、好ましくは、任意の所与のノードが全ての機能を行なう事ができるので、どれか1つのノード障害は、アーカイブの有効性に影響をほとんど及ぼさない。一般に所有される米国特許第7,155,466号明細書で述べられているように、それは、RAINベースのアーカイブシステムでデジタル財産をキャプチャし、保存し、管理し、検索する各ノード上で実行された分散ソフトウェアアプリケーションを組込む事で知られている。図2は、1つのそのようなシステムを示す。個々のアーカイブの物理的な境界は、クラスタあるいはシステムと呼ばれる。典型的には、クラスタは、単一のデバイスではなく、好ましくはデバイスの集合である。デバイスは、同種かもしれないし、あるいは異種かもしれない。典型的なデバイスは、Linuxのようなオペレーティングシステムを実行するコンピュータ又はマシンである。コモディティハードウェア上でホストされたLinuxベースのシステムのクラスタは、少数のストレージノードサーバから何千テラバイトものデータを格納する多くのノードまで計ることができるアーカイブを提供する。このアーキテクチャは、記憶容量が組織の増加するアーカイブ要求と歩調を常に合わせることができることを保証する。上記のようなストレージシステムにおいて、アーカイブがデバイス障害から常に保護されるように、データがクラスタに渡って典型的にランダムに分散される。ディスクか又はノードが機能しなくなる場合、クラスタは、自動的に同じデータの複製を維持するクラスタ中の他のノードにフェイルオーバする。このアプローチは、データ保護の見地からうまくいくが、クラスタのための計算された平均データロスMTDL時間は、望まれたほど高くないかもしれない。特に、アーカイブがデータを失う前に、MTDLは、典型的に時間の計算量を表わす。デジタルアーカイブにおいて、どんなデータロスも望ましくないが、ハードウェアとソフトウェアのコンポーネントの性質により、そのような発生の可能性しかし、遠隔が常にある。オブジェクトのランダム分散及びアーカイブクラスタ内のそれらのコピーのため、所与のノード内の所与のディスクミラーコピーがその上に格納されるが、不意に機能しなくなる場合、例えば、オブジェクトの必要とされるコピーが利用不可能かもしれないので、MTDLは、要求されたものより低い状態で終了するかもしれない。図2に示されるように、本発明が好ましく実行される例示的なクラスタは、下記の一般的なカテゴリーのコンポーネント、すなわち、ノード202、ネットワークスイッチ204のペア、電力分散ユニットPDU206及び無停電電源UPS208を好ましくは有する。ノード202は、典型的に1つ以上のコモディティサーバを有し、CPU例えばインテルx86、適切なランダムアクセスメモリRAM、1つ以上のハードドライブ例えば標準のIDE/SATA、SCSIなど及び2枚以上のネットワークインターフェイスNICカードを有する。典型的なノードは、24GHzのチップ、512MBRAM及び6つの6200GBハードドライブを備えた2Uラックマウントユニットである。しかし、これに限られない。ネットワークスイッチ204は、典型的にノード間のピアツーピア通信を可能にする内部スイッチ205、及び、各ノードへの追加のクラスタアクセスを許可する外部スイッチ207を有する。各スイッチは、クラスタ中の全て潜在的なノードを扱うことを十分なポートに要求する。イーサネットまたはGigEのスイッチは、この目的に使用されてもよい。PDU206は、全てのノード及びスイッチに動力を提供するために使用され、UPS208は、全てのノード及びスイッチを保護するために使用される。制限しているつもりではないが、典型的にクラスタは、公衆インターネット、企業イントラネットあるいは他の広域か、ローカルエリアネットワークのようなネットワークに連結可能である。例となる実施例において、クラスタは、企業環境内で実施される。それは、例えばサイトの企業ドメイン名前システムDNSネームサーバによってナビゲートすることにより達するかもしれない。従って、例えば、クラスタのドメインは、既存のドメインの新しいサブドメインかもしれない。代表的な実施において、サブドメインは、企業のDNSサーバの中でクラスタ自体の中のネームサーバに委託される。エンドユーザは、任意の従来のインターフェースあるいはアクセスツールを使用して、クラスタにアクセスする。従って、例えば、クラスタへのアクセスは、任意のIPベースのプロトコルHTTP、FTP、NFS、AFS、SMB、ウェブサービスなど上に、APIを経由して、あるいは他の既知か、その後発展したアクセス方式、サービス、プログラムあるいはツールを通じて実行されるかもしれない。クライアントアプリケーションは、標準UNIXファイルプロトコルのような1つ以上のタイプの外部ゲートウエイによるクラスタ、またはHTTPAPIにアクセスする。アーカイブは、好ましくは、オプションで任意の標準UNIXファイルプロトコル系設備の下に位置できる仮想ファイルシステムを通じて露出される。これらは、NFS、FTP、SMB/CIFSなどを含む。1つの実施例において、アーカイブクラスタアプリケーションは、クラスタとして例えば、イーサネット経由でネットワーク化される独立ノードH-RAINの冗長アレイ上で作動する。所与のノードのハードウェアは異種かもしれない。最大の信頼性のために、しかし、好ましくは、各ノードは、今、図3に示されるようないくつかのランタイムコンポーネントから成る分散アプリケーションすなわち、同じインスタンス、あるいは本質的に同じインスタンスかもしれないのインスタンス300を実行する。従って、ハードウェアは、異種かもしれないが、ノード少なくともそれが本発明に関係のある上のソフトウェアスタックは、同じである。これらのソフトウェアコンポーネントは、ゲートウエイプロトコルレイヤ302、アクセスレイヤ304、ファイルトランザクション及び管理レイヤ306、及び、コアコンポーネントレイヤ308を有する。機能が他の意味のある方法で特徴づけられるかもしれないことを通常のスキルのうちの1つが認識するので、レイヤ指定は、説明目的に提供される。レイヤあるいはその点でコンポーネントの1つ以上は、統合されるかそうでないかもしれない。いくつかのコンポーネントは、レイヤに渡って共有されるかもしれない。ゲートウエイプロトコルレイヤ302の中のゲートウエイプロトコルは、既存のアプリケーションに透明性を提供する。具体的には、ゲートウエイは、カスタムアプリケーションを構築するためのウェブサービスAPI同様に、NFS310及びSMB/CIFS312のようなネイティヴファイルサービスを提供する。HTTPサポート314も提供される。アクセスレイヤ304は、アーカイブへのアクセスを提供する。具体的には、発明によれば、固定コンテンツファイルシステムFCFS316は、アーカイブオブジェクトへフルアクセスを提供するためにネイティヴファイルシステムをエミュレートする。あたかもそれらが通常のファイルかのように、FCFSは、アーカイブコンテンツにアプリケーションダイレクトアクセスを与える。好ましくは、メタデータがファイルとして露出されている一方、アーカイブコンテンツは、そのオリジナルフォーマットでレンダリングされる。FCFS316は、管理者らが、使いやすい方法で固定コンテンツのデータをセットアップできるように、ディレクトリと許可についての従来のビュー及びルーチンファイルレベルコールを提供する。ファイルアクセス呼び出しは、好ましくは、ユーザスペースデーモンによって傍受され、ダイナミックに呼び出しのアプリケーションへの適切な表示を作成する適切なコアコンポーネントレイヤ308にに送られる。FCFS呼び出しは、好ましくは、自律的なアーカイブ管理を促進するアーカイブポリシによって抑制される。従って、一例において、管理者かアプリケーションは、保存期間所与のポリシがまだ有効のアーカイブオブジェクトを削除することができない。アクセスレイヤ304は、好ましくは、また、ウェブユーザインターフェースUI318及びSNMPゲートウエイ320を含む。ウェブユーザインターフェース318は、ファイルトランザクション及び管理レイヤ306での管理エンジン322への対話型のアクセスを提供する管理者コンソールとして好ましくは実施される。管理上のコンソール318は、好ましくは、アーカイブオブジェクト及び個々のノードを含むアーカイブの動的考察を提供するパスワードで保護されウェブベースのGUIである。SNMPゲートウエイ320は、安全にストレージ管理アプリケーションがクラスターアクティビティを監視し制御することを可能にしながらストレージ管理アプリケーションに管理エンジン322への容易なアクセスを提供する。管理エンジンモニタは、システムとポリシイベントを含むアクティビティをクラスタする。ファイルトランザクションと管理レイヤ306は、また、要求マネージャプロセス324を含む。要求マネージャ324は、コアコンポーネントレイヤ308の中のポリシマネージャ326からの内部要求と同様に外界アクセスレイヤ304を通じてからの全ての要求を統合する。コアコンポーネントは、ポリシマネージャ326に加えて、メタデータマネージャ328及びストレージマネージャ330の1つ以上のインスタンスを含む。メタデータマネージャ328は、各ノードに好ましくはインストールされる。クラスタ中のメタデータマネージャは、集合的に、全てのアーカイブオブジェクトを管理しながら、分散型データベースとして作動する。所与のノードにおいて、メタデータマネージャ328は、好ましくは、アーカイブオブジェクトのサブセットを管理し、各オブジェクトが、好ましくは、外部ファイルEFストレージ用にアーカイブに入ったデータとアーカイブデータが物理的に検索される内部ファイル各々IFのセット間をマップする。同じメタデータマネージャ328は、また、他のノードから複製されたアーカイブオブジェクトのセットを管理する。従って、全ての外部ファイルの現状は、いくつかのノード上の複数メタデータマネージャに常に利用可能である。ノード障害の場合には、他のノード上のメタデータマネージャが、機能不全のノードによって以前管理されたデータへのアクセスを提供し続ける。ストレージマネージャ330は、分散アプリケーション中の他の全てのコンポーネントに利用可能なファイルシステムレイヤを提供する。好ましくは、それはノードのローカルファイルシステムにデータオブジェクトを格納する。所与のノード中の各ドライブは、好ましくは、それぞれ自身のストレージマネージャを持っている。これは、ノードが個別のドライブを削除し、処理能力を最適化することを可能にする。ストレージマネージャ330は、また、システム情報、データの一貫性チェック及び直接ローカル構造をトラバースする能力を提供する。さらに図3で示されるように、クラスタは、通信ミドルウェアレイヤ332及びDNSマネージャ334を通じて内部及び外部通信を管理する。インフラストラクチャ332は、アーカイブコンポーネント中の通信を可能にする効率的で信頼できるメッセージベースのミドルウェアレイヤである。図で示した実施例において、レイヤは、マルチキャストとポイントツーポイント通信をサポートする。DNSマネージャ334は、企業サーバに全てのノードを接続する分散型ネームサービスを行う。好ましくは、DNSマネージャ単独であるいはDNSサービスと共にロードバランスは、最大のクラスタ処理能力及び有効性を保証することを全てのノードに渡って要求する。図で示した実施例において、ArCアプリケーションインスタンスは、RedHatLinux90、FedoraCore6などのような基礎オペレーティングシステム336上で実行する。通信ミドルウェアは、任意の便利な分散型通信メカニズムである。他のコンポーネントは、固定コンテンツファイルシステムFCFS316のために使用されてもよいFUSEUSErspaceの中のファイルシステムを含むかもしれない。NFSゲートウエイ310は、標準のnfsdLinuxカーネルNFSドライバによって実施されるかもしれない。各ノード中のデータベースは、実施されるかもしれない、例えば、オブジェクト関係データベース管理システムORDBMSであるPostgreSQLまたここにPostgresとして引用されるである。ノードは、JavaHTTPサーバ及びservletコンテナーであるジェティのようなウェブサーバを含むかもしれない。もちろん、上記のメカニズムは、単に例となる。所与のノード上のストレージマネージャ330は、物理的な記憶デバイスを管理する責任がある。好ましくは、各ストレージマネージャインスタンスは、全てのファイルがその配置アルゴリズムによって入れられる単一のルートディレクトリの責任がある。複数のストレージマネージャインスタンスは、ノード上で同時に作動することができ、各々は、通常、システムで異なる物理的なディスクを表わす。ストレージマネージャは、システムの残りから使用されているドライブ及びインターフェース技術を抽象する。ストレージマネージャインスタンスがファイルを書くように依頼される場合、それはそのために責任を負う表現用のフルパス及びファイル名を生成する。代表的な実施例において、ストレージマネージャ上に格納される各オブジェクトは、それが異なるタイプの情報を追跡するデータを格納する場合、ファイルにそれ自身のメタデータを加えて、そのときストレージマネージャと共に保存されるローデータとして受信される。外部ファイルEFは、クエリエンジンを備えたクエリに続いて必要になる情報を格納する。例として、このメタデータは、限定無しで含む:EF長さバイトでの外部ファイルの長さ、IFセグメントサイズ内部ファイルのこの部分のサイズ、EF保護表現EF保護モード、IF保護役割この内部ファイルの表現、EF生成タイムスタンプ外部ファイルタイムスタンプ、シグネチャシグネチャタイプを含む書き込みPUTの時間の内部ファイルのシグネチャ及びEFファイル名外部ファイルファイル名。内部ファイルデータでこの追加のメタデータを格納することは、追加のレベルの保護を提供することである。具体的には、スカビンジングは、内部ファイルに保存されたメタデータからデータベースに外部ファイルレコードを作成することができる。他のポリシは、内部ファイルが元の状態のままになることを有効にするために内部ファイルに対する内部ファイルハッシュを有効にすることができる。内部ファイルは、アーカイブオブジェクト中でオリジナルのファイルの一部を表わす、データのチャンクかもしれない、また、それらはストライピングと保護ブロックを達成するために異なるノードに置かれるかもしれない。より小さくチャンクされたユニットへの外部ファイルのこの途切れ途切れは、必要不可欠ではないが、代案では、内部ファイルは、外部ファイルの完全なコピーかもしれない。典型的に、1つの外部ファイルエントリは各アーカイブオブジェクトのためのメタデータマネージャの中にあり、その一方で、個々の外部ファイルエントリのための多くの内部ファイルエントリがあるかもしれない。典型的に、内部ファイルレイアウトは、システムに依存する。所与の実施において、ディスク上のこのデータの実際の物理フォーマットは一連の可変長レコードに格納される。要求マネージャ324は、システム内の他のコンポーネントとのやりとりによりアーカイブアクションを行なうために必要とされるオペレーションのセットを実行する責任がある。要求マネージャは、異なるタイプの多くの同時のアクションをサポートし、機能不全のトランザクションをロールバックすることができ、実行するのに長い時間かかるトランザクションをサポートする。要求マネージャは、更に、アーカイブの読取り書き込みオペレーションが適切に扱われる事を保証し、全ての要求がいつでも既知の状態である事を保証する。更に、それは、所与のクライアント要求を満たすためにノードに渡って複数の読取り書き込みオペレーションを調整するためにトランザクション制御を提供する。更に、要求マネージャは、最近使われたファイルのためのメタデータマネージャエントリをキャッシュに格納し、データブロックと同様にセッションのためのバッファリングを提供する。クラスタの主要な責任は、ディスク上に無制限のファイルを確実に格納することである。それが何らかの理由で手が届かないか、そうでなければ利用不可能かもしれないという意味で、所与のノードは信頼性が低いと見なされるかもしれない。そのような潜在的に信頼性の低いノードのコレクションは、確実で、高度に利用可能なストレージを作成することに協力する。一般に、格納される必要のある2つのタイプの情報がある:ファイル自体及びファイルに関するメタデータ。固定コンテンツ分散型データストレージの追加の詳細は、参照によってここに組込まれる米国公開特許第2007/0189153号明細書及び第2006/0026219号明細書で見ることができる。IIメタデータ管理メタデータマネジメントシステムは、システムメタデータのような所与のメタデータへのアクセスを組織し提供する責任がある。このシステムメタデータは、構成情報、管理UIに表示された情報、メトリクス、回復不能なポリシ違反についての情報などに表示された情報等と同様にアーカイブに置かれたファイルについての情報を含む。詳細に示されていないが、他のタイプのメタデータ例えばアーカイブしたファイルに関連したユーザメタデータも今説明されるメタデータ管理システムを使用して管理されるかもしれない。クラスタの代表的な実施例において、メタデータ管理システムは、次のオブジェクトタイプそれらは単に例となるの1つ以上を含んでいるかもしれないメタデータオブジェクトのセットのための持続性を提供する。ExternalFile:アーカイブのユーザによって知覚されるようなファイル。InternalFile:ストレージマネージャによって格納されたファイル。典型的には、外部ファイルと内部ファイルの間に一対多数の関係があるかもしれない。ConfigObject:クラスタを構成するのに使われる名前/値ペア。AdminLogEntry:管理者UIに表示されるメッセージ。MetricsObject:ある時点でのアーカイブ例えばファイルの数のある測定を表わす、タイムスタンプされたキー/値ペア。PolicyState:あるポリシの違反。各メタデータオブジェクトは、好ましくは、変わらないユニークな名前を持っているかもしれない。メタデータオブジェクトは、リージョンに組織される。リージョンは、権限のあるリージョンコピーと許容障害発生時点TPOF数0以上のセットバックアップリージョンコピーから成る。0のコピーで、メタデータマネジメントシステムは、計量可能であるが、高度に利用可能ではないかもしれない。リージョンは、1つ以上のオブジェクト属性例えばフルパス名やその一部のようなオブジェクトの名前をハッシュ及びハッシュ値のビットの所与数の抽出により選択される。これらのビットは、リージョン番号から成る。選択されたビットは、低位ビット、高位ビット、中位ビットあるいは個々のビットの任意のコンビネーションかもしれない。代表的な実施例において、所与のビットはハッシュ値の低位ビットである。オブジェクトの属性か属性複数は、任意の便利なハッシュ関数を使用してハッシュされるかもしれない。これらは制限なしで、javalangstringhashCode等のようなJavaベースのハッシュ関数を含む。好ましくは、リージョン番号から成るビットの数は、ここでregionMapLevelと呼ばれ、構成パラメータによってコントロールされる。この構成パラメータが6にセットされる場合、例えば、これは26=64リージョンが得られる。もちろん、多くのリージョンは許され、リージョンの数はネームスペース分割スキームを使用して自動的に調節されるかもしれない。各リージョンは、重複して格納されるかもしれない。上記の通り、リージョンの1つの権限のあるコピー及び0以上のバックアップコピーがある。前述のように、バックアップコピーの数は、メタデータTPOF構成パラメータによってコントロールされる。好ましくは、リージョンコピーは、1つのノード当たりの権限のあるリージョンコピーの数の平衡を保ち、かつ1つのノード当たりの合計のリージョンコピーの数の平衡を保つようにクラスタの全てのノードに渡って分散される。メタデータ管理システムは、各ノード上で作動するデータベースにメタデータオブジェクトを格納する。このデータベースは、リージョンマップをサポートするために使用される。典型的なデータベースは、オープンソースとして利用可能であるPostgreSQLを使用して実施される。好ましくは、各リージョンコピーのスキーマがあり、各スキーマでは、各タイプのメタデータオブジェクト用のテーブルがある。スキーマは、単にテーブル、インデックス、手順及び他のデータベースオブジェクトを所有することができるネームスペースである。各リージョンは、好ましくは、それ自身のスキーマを持っている。各スキーマは、テーブル一式、すなわち各メタデータオブジェクトに1つ持っている。これらのテーブルのうちの1つの列は、単一のメタデータオブジェクトに相当する。Postgresが好ましいデータベースであると同時に、任意の便利なリレーショナルデータベース例えばオラクル、IBMDB2などが使用されてもよい。図4で示されるように、各ノード400は、プロセスあるいはコンポーネント、すなわち、1つ以上のリージョンマネージャRGM402a-n、メタデータマネージャMM404、少なくとも1つのメタデータマネージャクライアントMMC406、及び1つ以上のスキーマ410a-nがある1つのデータベース408、のセットを有する。RGMs、MM及びMMCコンポーネントは、Java仮想マシンのようなバーチャルマシン412で実行する。各リージョンコピーにつき1つのRGMがある。従って、権限のあるリージョンコピー用のRGM、各バックアップリージョンコピー用のRGM及びそれぞれ不完全なリージョンコピー用のRGMがある。RGM402のスキーマを管理する各RGM402用のデータベーススキーマ410もある。データベースは、また、リージョンマップ405を格納する。各ノードは、好ましくは、同期スキームによって強化されている要求と共に、リージョンマップの同じ全体的な見解を持っている。リージョンマネージャRGM402は、リージョンコピーそれが権限のある、バックアップ、あるいは不完全な場合によっては上で作動し、メタデータマネージャクライアント406、及び他のリージョンマネージャ402によって提出された要求の実行に責任がある。要求は、図3で示された通信ミドルウェアあるいは他のメッセージングレイヤのような任意の便利な手段を通じて所与のRGMに提供される。リージョンマネージャは、これらの要求が実行する実行環境を提供する、例えば、スキーマのRGMによって管理されているスキーマ上で作動するように構成されているデータベースへの接続を提供することによって。各リージョンマネージャは、データベース408にそのデータを格納する。メタデータマネージャ404は、ノード上のメタデータ管理の責任があるトップレベルのコンポーネントである。それは、リージョンマネージャRGMを作成し破壊し、そして、RGM、例えばクラスタ構成情報、データベース接続のプールによって必要とされるリソースを組織する責任がある。好ましくは、所与のメタデータマネージャ所与のノード中のは、リーダーとして働き、どのメタデータマネージャノードのセット又はサブセットに渡ったがどのリージョンコピーに責任を負うかを決める責任がある。賛成アルゴリズム又はその変形のようなリーダー選挙アルゴリズムは、メタデータマネージャリーダーを選ぶために使用されるかもしれない。好ましくは、1つのノード当たり複数のMMを実行することは可能であるが、各ノードは、1つのメタデータマネージャを持っている。一旦リージョンオーナー権がネームスペース分割スキーム下記に述べられるようにによって確立されたならば、各メタデータマネージャは、1つ以上のリージョンマネージャのそのセットに従って調節することに責任がある。システムコンポーネント例えば管理エンジン、ポリシマネージャなどは、メタデータマネージャクライアントを通じてメタデータマネージャMMとやりとりをする。MMCは、所与の要求を実行するためにRGMを見つける事、選択されたRGMに要求を出す事、及び選択されたRGMが利用不可能な場合に例えば、ノードが機能しなくなったので要求を再試行することに責任がある。後者の場合は、新しいリージョンマップがノードで受信される場合、再試行要求が成功するであろう。上記の通り、リージョンマップは、各リージョンの各コピーに責任のあるノードを識別する。バーチャルマシン412またその中での各RGM、MM、及びMMC構成要素は、リージョンマップ405へのアクセスを持っている;リージョンマップのコピー420も、それがJVMにコピーされた後、図4に示される。リージョンマップは、従って、所与のノード中のJVM及びデータベースの両方に利用可能である。このインスタンスとなる実施例において、各メタデータオブジェクトは、0x0と0x3fffffff合計間の整数を産出するためにハッシュされる、つまり30ビットの値の属性例えば名前を持っている。これらの値は、オーバーフロー問題例えば範囲の高域に1を加える時にぶち当たる事なく、符号付き32ビット整数中で快適に表わす事ができる。30ビットは、大きなクラスタにさえ十分であるおよそ10億までのリージョンを考慮に入れる。リージョンは、1セットのハッシュ値を表わし、全てのリージョンのセットは、あらゆるハッシュ値をカバーする。各リージョンのための異なるビット位置があり、異なるビット位置は、好ましくは固定順になっている。従って、各リージョンは、ハッシュ値のRegionLevelMapビットの抽出により好ましくは引き出される数によって識別される。64リージョンを考慮に入れて、構成パラメータが6にセットされる場合、生じるハッシュ値は、0x0から0x3fの数である。先述の通り、リージョンコピーは、3つの3段階、すなわち、権限のある、バックアップそして不完全のうちの1つにある。リージョンコピーが権限のある場合、リージョンへの全ての要求がこのコピーに行き、また、各リージョンにつき1つの権限のあるコピーがある。リージョンコピーがバックアップである場合、コピーは、バックアップ要求権限のあるリージョンマネージャプロセスからのを受信する。メタデータがロードされているが、コピーがまだ同期されない典型的に他のバックアップコピーに関して場合、リージョンコピーは、不完全である。同期が完了するまで、不完全なリージョンコピーは、別の段階への昇進の資格を有さない、すなわち、そのポイントではコピーは、バックアップコピーになる。各リージョンは、1つの権限のあるコピー、所与の数メタデータTPOF構成パラメータによってセットされたバックアップあるいは不完全なコピーを持っている。バックアップリージョンコピーは、権限のあるリージョンコピーとそのTPOFバックアップコピー間で所与のプロトコルあるいは契約を強化することにより、権限のあるリージョンコピーと同期され続ける。このプロトコルは、今説明される。簡易バックグラウンド経由で、更新要求がMMCで受信される場合、MMCは、権限のあるリージョンコピーの位置を見つけるためにローカルのリージョンマップ上の検索を行う。MMCは、権限のあるリージョンコピーに関連したRGMに更新要求を送信する、すなわち、その後、それを委託する。更新も、TPOFバックアップコピーの各々のRGMに権限のあるリージョンコピーに関連したRGMによって送られる。しかし、権限のあるRGMは、成功を示すために、更新情報を委託するのにバックアップリージョンコピーに関連した各RGMを待つ必要はない;むしろ、バックアップリージョンコピーに関連したRGMが更新情報を受信する場合、それは、直ちに確認を返す権限のあるRGMに又は返そうとする。バックアップ要求が受信される場合、そしてそれが実行される前に、この確認が出される。障害が生じない場合、一旦権限のあるRGMが全ての確認を受信すれば、それは、MMCに通知する、すなわち、その後、それは、発信者に成功を返す。しかし、所与の故障事象が生じる場合、プロトコルは、影響を与えられたRGMバックアップ、あるいは権限のあるが、サービスからそれ自身を削除するまた潜在的に影響を受けたノード事を保証し、新しいリージョンマップは、MMリーダーによって出される。好ましくは、どんな便利な技術が使用されてもよいが、RGMは、JVMを下げる事によりサービスからそれ自身を削除する。新しいマップは、失われたリージョンコピーの置換を指定する。このように、各バックアップリージョンコピーは、権限のあるリージョンコピー用のホットスタンバイであり、従って、必要ならば及びその場合、権限のあるRGMがロードバランシング目的あるいはそのような理由のために機能しなくなるので権限のあるに昇格の資格を有する。更新処理が失敗するいくつかの方法がある。従って、例えば、権限のあるリージョンマネージャ確認を待っている間は、バックアップマネージャプロセスが故障した事を示す例外に遭遇するかもしれない、あるいは、たとえそれが確認を出したとしても、バックアップマネージャプロセスは、更新要求を局所的に処理するのに失敗するかもしれない、あるいは、確認を出す間のバックアップリージョンマネージャプロセスは、権限のあるリージョンマネージャプロセスが故障した事を示す例外に遭遇するかもしれない等など。上記の通り、所与のバックアップRGMが更新情報を処理することができない場合、それは、サービスから自身を削除する。更に、バックアップRGMあるいは権限のあるRGMのいずれかが故障する場合、新しいリージョンマップが出される。メタデータマネジメントシステムは、リージョンのコピーを同期した状態に保つ。権限のあるリージョンコピーでのオブジェクトに終っている更新情報は、バックアップリージョンコピー上で複製される。一旦、更新情報が権限のあるRGMによって委託されれば、同じ更新情報は、全てのバックアップリージョンコピーに適用される。メタデータマネジメントシステムは、どんなそのような障害ノードレベル、リージョンマネージャレベルまたは同様なものも障害したノード上のリージョンコピーの配置転換を引き起こす事を保証する;従って、残るリージョンコピーのインテグリティが保証される。権限のあるRGMを含んでいるノードが障害する場合、バックアップRGMは、同期している状態現在実行する更新情報の有無に関わらずあるいは、それらは、中断された更新情報によるのみ同期していない状態である。後者の場合は、再度同期させる事が容易である。バックアップリージョンが、権限のあるリージョンと同期され続けるので、昇格バックアップから権限のあるまでは瞬間的である。ノード障害は、また、バックアップリージョンを失うであろう。バックアップリージョンは、他のあるノード、すなわち、新しく不完全なリージョン上で作成することにより復元される。不完全なリージョンが作られるとすぐに、それは、更新情報を記録し始め、権限のあるリージョンからデータをコピーし始める。複製が完了すると、最新のバックアップをもたらせながら蓄積された更新情報が適用される。その後、新しいバックアップリージョンは、それが最新であるとMMリーダーに通知する、すなわち、MMリーダーにリージョン不完全なからバックアップまでの昇格を含むマップを送信させる。注目すべきは、リージョンの数がノードの数に相当するという要求がない事である。より一般に、リージョンの数は、独立ノードのアレイのノードの数に関連しない。メタデータ管理の追加の詳細は、米国公開特許第2006/0026219号明細書で見ることができる。IIIノードによってクエリ結果を集めること発明の典型的な実施例は、RESTRepresentationalStateTransferクライアントが所与の基準のためのオブジェクトとシステムメタデータとのリストを検索するためにディレクトリ、サブディレクトリ、サブサブディレクトリ等をトラバースするために統合するアプリケーションの必要無しに所与の基準と一致するオブジェクトのリスト及びメタデータ用のコンテンツプラットフォームにクエリを行うことを可能にする。この発明の特徴は、クライアントアプリケーションが、変更時間によるクエリ、ディレクトリによるクエリ、トランザクション作成、削除、パージによるクエリ、ネームスペースによるクエリ、及び、結果を通じてのページ等を行う能力を含む。単一のコンテンツプラットフォームノードは、コンテンツプラットフォームシステムでの全てのノードに渡って全てのリージョンにクエリを分散し、同じノードは、クライアントアプリケーションにリストを返す前に結果をソートする。特定の実施例によると、データベースクエリは、メタデータマネージャの中で実施される。変更時間は、オブジェクトコンテンツプラットフォームシステムでのコンテンツが読取り専用であるので、特に、そのメタデータが、ユーザによって最後に修正された時間である。例えば、時間は、1970年1月1日以来ミリセカンドの数で計られる。ディレクトリによるクエリは、同じファイルシステムディレクトリに論理上存在する、コンテンツプラットフォームシステムでの全てのオブジェクトを検索する行為である。コンテンツプラットフォームシステムは、そのデータベースに対するSQLクエリの実行によりこれを遂行する。トランザクションによるクエリは、最近のアクセスがあるタイプのオペレーションによったコンテンツプラットフォームシステムでの全てのオブジェクトを検索する行為である。例えば、それは、最近の活動がそれらの生成であった全てのオブジェクト、あるいは、最近削除された全てのオブジェクトを返すことができるかもしれない。ネームスペースによるクエリは、全てのオブジェクト、そして、特定のコンテンツプラットフォームシステムネームスペースの中のそれらのオブジェクトだけを検索する行為である。結果を通じてのページは、個々のオブジェクト中ではなく、セット中のクエリの結果セットとやりとりを行う行為である。例えば、クエリは、1000のオブジェクトによって満たされるかもしれない。従来の相互作用において、クライアントは、1000の相互作用を要求して、ひとつずつそれらのオブジェクトを検索し検査するであろう。ページングスキームにおいて、それらは、結果をトラバースするのに必要な相互作用の数を減らす50、100あるいは他のある数のバッチ中のクライアントに返される。IIIAクエリ定義図5は、単一ノード510によって全ての他ノード512、514、516へクライアントアプリケーション502からクエリを分散することを示すコンテンツプラットフォーム500の簡略化したブロック図である。その後、クエリの結果は、それらがHTTPクライアントアプリケーション502に返される前に、フィルタされソートされる。コンテンツプラットフォーム500は、ネットワーク化された独立ノードの冗長アレイを含む。クエリの基準に適合したオブジェクトを見つけることによりクエリの結果を提供するために、クエリは、各ノード中で処理される。クエリ結果をフィルタすることは、結果セット内でRESTクライアントによる基準又は所与の基準に一致する結果だけを含むことを意味する。オブジェクトは、オペレーションタイプつまり、作成された削除された変更されたメタデータ等によってフィルタされる。例えば、クライアントが単にトランザクションレコード作成を見ることを望む場合、呼び出された全てのレコード及びトランザクション作成に一致するレコードだけが含まれる。ステップ1において、アプリケーション502は、ノード510を分散するクエリである第1のノード又は主要なノードへのクエリを送る。ステップ2において、第1のノード510は、アプリケーション502から受信した要求に基づいて、コンテンツプラットフォーム500内の他のノード512、514、516の各々へクエリを出す。ステップ3において、コンテンツプラットフォーム500内の各ノードは、ノード内の権限のあるリージョンを全てクエリし始め、セット中の結果を提供する。ステップ4において、第1のノード510は、連続的に検索し、統合し、全てのノードからの結果をフィルタしソートする。ステップ5において、第1のノード510は、アプリケーション502に結果のセットを返す。ステップ6において、アプリケーション502は、第1のノード510へ結果の次のセットの要求を出すかもしれない、そして上記のステップ2-5が繰り返される。各リージョンは、好ましくは、データベースインデックスの使用を通じてオブジェクト変更時間上のクエリを扱うために最適化されたデータベースにマッピングする。図6は、全て他のノードに第1のノード510によるクライアントアプリケーション502からのクエリを分散し、クライアントアプリケーション502へのクエリの結果を統合し、返す過程を示すフロー図の例である。この例において、クエリは、供給されたUUIDUniversalUniqueIdentifier、ディレクトリパス及びchangetimesの中の100のオブジェクトを選択する。クエリによって作られた順序付けは、uuid、changetime、fnhashである。ステップ602で、クライアントアプリケーション502は、ある基準を満たすオブジェクトのリストを要求する。ステップ604において、要求を受信する第1のノード510は、全ての他ノードにクエリを出す。ステップ606において、各ノードは、そのノードにおけるリージョンについてのクエリを始める。ステップ608で、各ノードは、ノード上の各リージョンにつき最初の100の結果を検索する。ステップ610において、第1のノード510は、全てのノードから結果の最初のセットを検索する。ステップ612において、第1のノードは、結果を統合し、フィルタし、ソートするクライアントアプリケーション502が次のセットの結果を要求することをやめるまで、これは連続的に行われる。ステップ614において、第1のノード510は、クライアントアプリケーション502に結果を返す。ステップ616において、クライアントアプリケーションは、完了クライアントアプリケーション502が次のセットの結果を要求することをやめるまで、これは行われるまで結果を受信する。ステップ618において、クライアントアプリケーション502は、結果の次のセットの要求を第1のノード502に送信する。ステップ620において、第1のノード502は、完了クライアントアプリケーション502が次のセットの結果を要求することをやめるまで、これは行われるまで全てのノードから統合され、フィルタされ、ソートされた追加の結果を要求する。クエリ結果つまりクエリを出し、処理し、クエリの結果を統合し、フィルタするを管理するプロセスは、クエリ結果管理モジュール中で実行されるかもしれない。特定な実施例において、クエリ結果管理モジュールは、コンテンツプラットフォームの各ノード中のメタデータマネージャの中で提供される。IIIBCPExternalFileQueryRequestCPExternalFileQueryRequestは、メタデータマネージャクライアントから特定な権限のあるリージョン番号への要求である。その要求は、QueryParametersに適合するexternalfileテーブルから1バッチを返す。CPExternalFileQueryRequestは、前のセクションで説明されたそれと同じクエリを起動するであろう。上記の通り、クエリは、uuid、changetime、fnhashによって指図される。バッチを返す前に、リストはこの正確な順序付けを生じさせるためにさらにソートされるメモリ内で:uuid、changetime、fnhash、ディレクトリ、filename、versionid。結果の次のセット/バッチを要求するために第1のノード510と他のノード間の通信を提供するために、この特徴は、ソフトウェアモジュールとして実施されるかもしれない。uuidは、オブジェクトのためのユニバーサルユニーク識別子である。この場合、それは、オブジェクトが存在するネームスペースを識別する。changetimeは、レコードが最後に修正された日付及び時間を反映する。fnhashは、ネームスペース中のオブジェクトの名前にハッシュ関数を適用する結果を表わし、オブジェクトの識別のために省略表現として使用される。米国公開特許第2006/0026219号明細書を参照。versionidは、ネームスペース中のオブジェクトの特別なバージョンのためのユニーク識別子である。IIICRemoteQueryBatchIteratorRemoteQueryBatchIteratorは、バッチを検索するCPExternalFileQueryRequestメッセージを送るBatchIteratorの単純拡大である。これは、通常、局所リージョンにクエリを行うBatchIteratorの典型的な実施とほんの少し異なる。クエリエンジンは、特定なリージョン番号及び生成上のマップサイズに結合する。第1のノード510がクライアントアプリケーション502からある基準を備えたオブジェクトのリストの要求を受信する場合、第1のノード510から他のノードにクエリを出すために、この特徴は、ソフトウェアモジュールとして実施されるかもしれない。IIIDExternalFileQueryExternalFileQueryクラスは、システムでクエリエンジンの全てに渡って統合するMetadataManagerClientOperationインプリメンテーションである。RemoteQueryBatchIteratorから返された各クエリエンジンが厳密に指図されるので、PriorityQueueIteratorは、これらのクエリエンジンに渡って効率的に統合することができる。結果として生じるクエリは、全てのリージョンに渡って正確に指図される。返されたクエリは、タイプMetadataIteratorになるであろう。全てのノードから第1のノード502によって集められた結果を統合し、フィルタするために、この特徴はソフトウェアモジュールとして実施されるかもしれない。全てのリージョンに渡って統合するためのアルゴリズムは、かなり簡単である:1giveノード中の全てのリージョンを処理する、2RemoteQueryBatchIteratorリージョン、QueryParametersを作成する、3PriorityQueueIterator収集iterators、QueryKeyExtractorを作成する、そして4リターンPriorityQueueIteratorを返す。発明の特定の実施例によると、上記のクエリ結果を統合するための技術は、検索エンジン、バックアップサーバ、ポリシエンジン、RBSを使用するアプリケーション、XAMを使用するアプリケーション又は同種のものを備えたコンテンツプラットフォーム統合のサポートを提供するのを助けるメタデータクエリエンジンの一部である。もちろん、図1及び5に示されたシステム構成は、本発明が実行されるかもしれないストレージアーカイブの純粋な模範例であり、発明は、特定なハードウェア構成に制限されない。発明を実行するコンピュータとストレージシステムは、また、上記発明を実行するために使用されるモジュール、プログラム及びデータ構造を格納し読む事ができるIOデバイス例えばCD及びDVDドライブ、フロッピーディスクドライブ、ハードドライブなどとして知られてきた。これらのモジュール、プログラム及びデータ構造は、そのようなコンピュータが読めるメディア上でエンコードすることができる。例えば、発明のデータ構造は、発明に使われるプログラムが存在する1以上のコンピュータが読めるメディア上に単独で格納することができる。システムのコンポーネントは、任意の形式あるいはデジタルデータ通信、例えば通信ネットワークのメディアによって相互連結することができる。通信ネットワークの例は、ローカルエリアネットワーク、広域ネットワーク、例えばインターネット、ワイヤレスネットワーク、ストレージエリアネットワークそして同種のものを含む。説明において、多数の詳細が本発明についての完全な理解を提供するために説明の目的のために述べられる。しかし、これらの特定な詳細の全てが本発明を実行するために必要だとは限らないという事が当業者には明らかである。発明がプロセス、すなわち、フローチャート、フロー図、構造図あるいはブロック図として通常描かれると説明されるかもしれない事がさらに注目される。フローチャートは、オペレーションを連続するプロセスと説明するかもしれないが、オペレーションの多くは、並行してあるいは同時に行なう事ができる。更に、オペレーションの順序は並べ替えられるかもしれない。当技術で知られているように、上記のオペレーションは、ハードウェア、ソフトウェアあるいはソフトウェアとハードウェアのあるコンビネーションによって行なう事ができる。もしプロセッサによって実行されれば、プロセッサに発明の実施例を実行する方法を行なわせるだろう機械可読媒体ソフトウェア上に格納された指示を使用して、他の態様が実施されるかもしれない一方、発明の実施例の種々態様は、回路及び論理回路ハードウェアを使用して、実施されるかもしれない。更に、他の実施例は、唯一ソフトウェア内で行なわれるかもしれないが、発明のいくつかの実施例は、唯一ハードウェア内で行なわれるかもしれない。更に、説明された様々な機能は、単一のユニットで行なう事ができるか、あらゆる方法を用いて多くのコンポーネントに広げる事ができる。ソフトウェアによって行なわれた場合、その方法は、汎用計算機のようなコンピュータが読めるミディアム上に格納された指示に基づいたプロセッサによって実行されるかもしれない。もし望まれれば、指示は、圧縮されかつまたは暗号化された、フォーマットでミディアム上に格納することができる。前述から、発明がフォールトトレラントデータベース管理システムでクエリ結果を統合するためにコンピュータ読取り可能な記憶媒体上に格納された方法、装置及びプログラムを提供することは明白であろう。更に、特定な実施例がこの明細書に示され、説明されてきた一方、当事者達は、同じ目的を達成すると計算されるいかなる配置が、公開された特定な実施例の代わりに用いられるかもしれない事を認識している。この開示は、本発明のありとあらゆる適応あるいは変化をカバーするように意図され、下記の請求項の中で使用される用語が、発明を明細書に公開された特定な実施例に制限するために解釈されるべきでない事が、理解される事になっている。正しくは、発明の範囲は、そのような請求項が与えられる同等物の全範囲に加えて請求項解釈の確立した主義に従って解釈される事になっている下記の請求項によって完全に決定される事になっている。"