JP2013545162A5 - - Google Patents
Download PDFInfo
- Publication number
- JP2013545162A5 JP2013545162A5 JP2013530184A JP2013530184A JP2013545162A5 JP 2013545162 A5 JP2013545162 A5 JP 2013545162A5 JP 2013530184 A JP2013530184 A JP 2013530184A JP 2013530184 A JP2013530184 A JP 2013530184A JP 2013545162 A5 JP2013545162 A5 JP 2013545162A5
- Authority
- JP
- Japan
- Prior art keywords
- metadata
- node
- nodes
- content data
- query
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Granted
Links
Description
【書類名】明細書
【発明の名称】フォールトトレラントデータベース管理システムにおいてクエリ結果を統合するシステム及び方法
【背景技術】
【０００１】
本発明は、一般に、ストレージシステム、及び、特に、フォールトトレラントデータベース管理システムにおけるクエリ結果を統合するシステム及び方法に関する。
【０００２】
顧客は、彼らのビジネスニーズおよびシナリオに基づきコンテンツプラットフォームを備えた異なる統合ニーズを持つことができる。１つの共通テーマは、彼らのインフラストラクチャにおける別のアプリケーションに移る、特定の機能（例えば、データの検索又はデータのバックアップ）のオブジェクトとそれらオブジェクトについての情報とのリスト、を検索することを取り囲む。これをするために、そのアプリケーションは、この情報を検索するためにより多くの仕事をするように要求されるかもしれない。例えば、統合アプリケーションは、所与の基準のオブジェクトとシステムメタデータとのリストを検索するためにディレクトリ、サブディレクトリ、サブサブディレクトリ、その他をトラバースしなければならないであろう。これは、独立ノードの冗長アレイがネットワーク化されていて、ノードの各クラスタ／システムが、テナントとネームスペースに分割される場合、インタレストの全てのネームスペースに渡って、インタレストの全てのテナントに渡って等などネームスペース内で全てのディレクトリのために行われなければならない。ネームスペースは、クラスタの論理パーティションで、特に少なくとも１つの定義されたアプリケーションにオブジェクトのコレクションとして本質的に役目を果たす。各ネームスペースは、他のネームスペースに関してプライベートファイルシステムを持っている。さらに、1つのネームスペースへのアクセスは、別のネームスペースへのユーザアクセスを許可しない。テナントは、ネームスペース、場合により他のサブテナントのグループである。クラスタ／システムは、物理的なアーカイブインスタンスである。同一出願人による、２００９年１０月３０日に出願された米国特許出願第１２／６０９，８０４「分割されたコンテンツプラットフォーム内の、ネームスペースを使用する固定コンテンツストレージ」と題する、を参照することにより本書に組み込まれる、を参照すること。
【発明の簡単な概要】
【０００３】
発明の典型的な実施例は、ＲＥＳＴ（Representational State Transfer）クライアントが、ディレクトリ、サブディレクトリ、サブサブディレクトリ、その他をトラバースする統合アプリケーションの必要無しに、所与の基準のオブジェクトとシステムメタデータとのリストを検索するために、所与の基準と一致するオブジェクトとメタデータとのリストについてのコンテンツプラットフォームにクエリを行うことを、可能にする。例えば、クライアントアプリケーションは、変更時間によるクエリの実行、ディレクトリによるクエリの実行、トランザクション（作成、削除、パージ）によるクエリの実行、ネームスペースによるクエリの実行、又は、結果をぱらぱらと確認すること、を行うかもしれない。この発明で、単一のコンテンツプラットフォームノードは、コンテンツプラットフォームシステムでの全てのノードに渡って全てのリージョンにクエリを分散し、同じノードは、クライアントアプリケーションにリストを返す前に結果をソートする。このように、コンテンツプラットフォームシステムは、コンテンツプラットフォームシステムでの全てのノードに渡ってクエリを行い、結果をフィルタし、ソートし、そして、クライアントアプリケーションに結果を返すことにより、この仕事のより多い負担を担う。
【０００４】
本発明の一態様は、ネットワーク化された独立ノードの冗長アレイを対象とし、各ノードは、オブジェクトベースのストレージを提供するアプリケーションのインスタンスを実行し、メタデータオブジェクトは、アレイに渡ってノード中に分散されたリージョンのセットに格納され、所与のリージョンは、メタデータオブジェクト属性をハッシュし、且つ、結果として生じるハッシュ値のビットの所与のセットを抽出することにより識別される。クエリ結果を管理する方法は、基準を満たしたオブジェクトのリストの要求をクライアントアプリケーションから複数の独立ノードの第１のノードによって受信すること、受信した要求に基づき全てのノードにクエリを第１のノードによって出すこと、リージョンに格納されているメタデータオブジェクトを使用してノードにおけるリージョンにわたってクエリを各ノードによって処理すること、全てのノードからのクエリの結果を第１のノードによって統合しフィルタすること、及び、統合されフィルタされた結果をクライアントアプリケーションに第１のノードによって返すこと、を有する。
【０００５】
いくつかの実施例において、各ノードによってクエリを処理することは、セット中のクエリの結果を第１のノードに提供することを有し、そして、全てのノードからのクエリの結果は、統合され、フィルタされ、セット中のクライアントアプリケーションに返される。その方法は、更に、第１のノードによって、統合されフィルタされた結果の現在のセットをクライアントアプリケーションに返した後、全てのノードから結果の次のセットを要求し検索する前、結果の次のセットのためのクライアントアプリケーションからの要求を待つこと、を有する。セット中のクエリの結果を第１のノードに提供することは、各リージョンからのオブジェクトのプリセットされた数をクエリの処理をすることの結果として提供すること、を有する。その方法は、更に、統合されフィルタされた結果をプリセットされた順序を生じさせるために第１のノードによってソートすること、を有する。その要求は、変更時間によるクエリ、ディレクトリによるクエリ、トランザクションによるクエリ、ネームスペースによるクエリ、及び、結果を通じたページ、のうちの１以上を含む。
【０００６】
本発明の別の一態様は、ネットワーク化された独立ノードの冗長アレイにおけるクエリ結果を管理する装置を対象とし、各ノードは、オブジェクトベースのストレージを提供するアプリケーションのインスタンスを実行し、メタデータオブジェクトは、アレイに渡ってノード中に分散されたリージョンのセットに格納され、所与のリージョンは、メタデータオブジェクト属性をハッシュし、且つ、結果として生じるハッシュ値のビットの所与のセットを抽出することにより識別される。その装置は、プロセッサ、メモリ、及び、ノードの各々のために備えられたクエリ結果管理モジュールを有する。クエリ結果管理モジュールは、そのクエリ結果管理モジュールを持つノードが、基準を満たしたオブジェクトのリストの要求をクライアントアプリケーションから受信する第１のノードであれば受信した要求に基づき全てのノードへクエリを出し、リージョンに格納されているメタデータオブジェクトを使用してノードにおけるリージョンにわたってクエリを処理し、そのクエリ結果管理モジュールを持ったノードが第１のノードであれば全てのノードからのクエリの結果を統合しフィルタする、ようになっており、統合しフィルタされた結果はクライアントアプリケーションに返される。
【０００７】
特定の実施例において、１つのノードは、メタデータオブジェクへのアクセスを組織し提供することを含むそのノード中のメタデータオブジェクトを管理するメタデータマネージャ、を有する。メタデータマネージャは、そのノードのクエリ結果管理モジュールを含む。
【０００８】
本発明の別の態様は、ネットワーク化された独立ノードの冗長アレイにおけるクエリ結果を管理するデータプロセッサを制御する複数の指示を記憶する、コンピュータ読取り可能な記憶媒体、を対象とし、各ノードは、オブジェクトベースのストレージを提供するアプリケーションのインスタンスを実行し、メタデータオブジェクトは、アレイに渡ってノード中に分散されたリージョンのセットに格納され、所与のリージョンは、メタデータオブジェクト属性をハッシュし、且つ、結果として生じるハッシュ値のビットの所与のセットを抽出することにより識別される。複数の指示は、そのコンピュータ読取り可能な記憶媒体を有するノードが、基準を満たしたオブジェクトのリストの要求をクライアントアプリケーションから受信する第１のノードであれば、受信した要求に基づき全てのノードへクエリを発行することをデータプロセッサにさせる指示を有し、また、リージョンに格納されているメタデータオブジェクトを使用してノードにおけるリージョンにわたってクエリを処理することをデータプロセッサにさせる指示を有し、また、コンピュータ読取り可能な記憶媒体があるノードが第１のノードであれば全てのノードからのクエリの結果を第１のノードによって統合しフィルタすることをデータプロセッサにさせる指示を有し、統合されフィルタされた結果はクライアントアプリケーションに返される。
【０００９】
本発明のこれら及び他の特徴及び利点は、特定の実施例の以下の詳細な説明を考慮して当業者に明らかになるであろう。
【図面の簡単な説明】
【図１】
【００１０】
図１は、発明の方法及び装置が適用され得る固定コンテンツストレージアーカイブの簡略化されたブロック図である。
【図２】
【００１１】
図２は、それぞれが対称でありアーカイブクラスタアプリケーションをサポートする独立ノードの冗長アレイの簡略化された説明図である。
【図３】
【００１２】
図３は、所与のノード上で実行するアーカイブクラスタアプリケーションの様々なコンポーネントの高レベル説明図である。
【図４】
【００１３】
図４は、クラスタの所与のノード上のメタデータ管理システムのコンポーネントの例を示す図である。
【図５】
【００１４】
図５は、単一ノードによりクライアントアプリケーションから全ての他ノードへクエリを分散することとクライアントアプリケーションに返されるクエリ結果を統合することとを示す、コンテンツプラットフォームの簡略化されたブロック図である。
【図６】
【００１５】
図６は、単一ノードによりクライアントアプリケーションから全ての他ノードへクエリを分散することと、単一ノードによりクライアントアプリケーションへのクエリ結果を統合し返すこととの処理を示すフロー図の例である。
【発明を実施するための形態】
【００１６】
発明の以下の詳細な説明において、開示の一部を形成する添付図面について言及がされ、その中で、図面で限定なく示され発明が実施されるかもしれない典型的な実施例として示される。図面において、類似の数字は、いくつかの見解に渡って本質的に同様のコンポーネントについて説明する。更に、注目すべきは、下記のように、及び図面の中で示されるように、詳細な説明が、様々な典型的な実施例を提供しているが、本発明が説明され、ここに示された実施例に限らず、当業者に知られている又は知られる他の実施例まで及ぶ可能性がある事である。「１つの実施例」、「この実施例」あるいは「これらの実施例」の明細書中の言及は、特定な特徴、構造あるいは実施例に関して説明された特性が、発明の少なくとも１つの実施例に含まれる事を意味し、明細中の様々な個所におけるこれらの句の出現は、必ずしも全ては、同じ実施例を指していない。更に、下記の詳細な説明において、多数の特定な詳細は、本発明についての完全な理解を提供するために述べられる。しかし、本発明を実行するためにこれらの特定な詳細が必ずしも全て必要ではないかもしれない事は、当業者に明らかであろう。他の状況において、有名な構造、材料、回路、プロセス及びインターフェースは、詳細に説明されておらず、かつ、本発明が不必要に不明瞭にならないようにブロック図の形式で示されるかもしれない。
【００１７】
更に、以下に続く詳細な説明のいくつかの部分は、コンピュータ内のオペレーションのアルゴリズム及び記号表現の点から示される。これらのアルゴリズムの説明及び記号表現は、その他の当業者に最も効果的に彼らの革新の本質を伝えるためにデータ処理に優れている人々によって使われる手段である。アルゴリズムは、所望最終状態か結果に導く一連の定義されたステップである。本発明において、行なわれたステップは、具体的結果の達成のために具体的な量の物理的な操作を要求する。通常、必ずではないが、これらの量は、格納する、組み合わす、比較する、またそうでなければ、操作することができる電気的か磁気信号あるいは指示の形式をとる。これらの信号をビット、値、要素、記号、文字、用語、数、指示などと呼ぶために主に一般的用法の理由で、時々便利であると証明されてきた。しかし、これら全て及び同類項が適切な物理量に関係しているはずであり、これらの量に当てはまる単に便利なラベルである事も留意しておくべきである。特に別記しない限り、以下の議論から明らかなものとして、説明全体に渡って、「処理すること」、「コンピューティング」、「計算すること」、「決定すること」、「表示すること」等の用語を使う議論は、コンピュータシステムの登録及びメモリ内の物理的な（電子の）量として表わされたデータをコンピュータシステムのメモリ、登録、あるいは他の情報ストレージ、送信又はディスプレイデバイス内の物理量として同様に表わされた他のデータに操作し、変形するコンピュータシステムあるいは他の情報処理デバイスのアクション及びプロセスを含むかもしれない事を認識しておくべきである。
【００１８】
本発明は、また、オペレーションをここで行なうための装置に関する。この装置は、要求された目的のために特別に構築されるかもしれない、あるいは、それは、１つ以上のコンピュータプログラムによって選択的に作動されたか再構成された１台以上の汎用コンピュータを含むかもしれない。そのようなコンピュータプログラムは、光ディスク、磁気ディスク、読み出し専用メモリ、ランダムアクセスメモリ、ソリッドステートデバイス及びドライブ、あるいは電子情報を格納するのにふさわしい他のタイプの媒体に制限されないが、これらのようなコンピュータ読取り可能な記憶媒体に格納されるかもしれない。ここに示されたアルゴリズムとディスプレイは、本質的にどんな特定なコンピュータあるいは他の装置とも関係がない。様々な汎用のシステムは、教えに従ってプログラムとモジュールと共にここに使用されてもよい、あるいは、希望の方法ステップを行なうためにもっと専門の装置を構築するのに便利であると言ってもよい。更に、本発明は、どんな特定なプログラミング言語に関しても説明されない。当然のことながら、ここに説明されるような発明の教えを実施するために、様々なプログラミング言語が使用されてもよい。プログラミング言語の指示は、１つ以上の処理デバイス、例えば中央処理装置（ＣＰＵ）、プロセッサ又はコントローラによって実行されても良い。
【００１９】
より詳しく以下に説明される発明の典型的な実施例は、フォールトトレラントデータベース管理システムにおけるクエリ結果を統合する装置、方法及びコンピュータプログラムを提供する。
【００２０】
I. 固定コンテンツ分散データストレージ
【００２１】
ニーズが、従来のテープ及び光学ストレージ解決法に取って代わるかそれを補う、高度に可用性、信頼性及び持続性のあるやり方で「固定コンテンツ」のアーカイブストレージについて発展してきた。用語「固定コンテンツ」は、典型的に、参照あるいは他の目的のためにそのままで保存される事が予想される任意のタイプのデジタル情報を指す。このような固定コンテンツの例としては、多くの例の中でもとりわけ、電子メール、文書、診断画像、チェック画像、音声録音、フィルム及びビデオなどが挙げられる。従来の独立ノード冗長アレイ（ＲＡＩＮ）ストレージ手法は、このような固定コンテンツの情報資産を記憶するための大規模なオンラインアーカイブを生み出すために選択されるアーキテクチャとして登場した。ＲＡＩＮアーキテクチャは、ノードが必要に応じてクラスタに結合すること及びクラスタから退出することを可能にすることにより、ストレージクラスタを１つまたは複数のノードの障害から隔離する。ＲＡＩＮタイプのアーカイブは、データを複数のノード上で複製することにより、ノードの障害または除去を自動的に補償することができる。通常、ＲＡＩＮシステムは、閉システム内の同一コンポーネントから設計されたハードウェア機器として広く提供される。
【００２２】
図１は、そのような計量可能なディスクベースのアーカイブのストレージ管理システムを示す。ノードは、異なるハードウェアから成るかもしれないし、従って、「異種である」と考えられるかもしれない。ノードは、典型的に、ストレージエリアネットワーク（ＳＡＮ）でのような実際の物理的なストレージディスク、又は仮想ストレージディスクかもしれない１枚以上のストレージディスクにアクセスする。各ノード上で支援されるアーカイブクラスタアプリケーション（及び任意でそのアプリケーションが実行する基本的なオペレーティングシステム）は、同じ又は実質的に同じかもしれない。ハードウェアが異種かもしれないのに対して、各ノード上の（オペレーティングシステムを含むかもしれない）ソフトウェアスタックは、対称である。システムを使用すると、図１で示されるように、企業は、文書、電子メール、衛星画像、診断画像、チェック画像、音声録音、ビデオなどのような様々なタイプの固定コンテンツ情報のための永久記録媒体を特に作成することができる。もちろん、これらのタイプは、単に例である。 ハイレベルな信頼度は、独立サーバ上のデータの複製、あるいは、いわゆるストレージノードにより達成される。好ましくは、各ノードは、そのピアと対称である。従って、好ましくは、任意の所与のノードが全ての機能を行なう事ができるので、どれか１つのノード障害は、アーカイブの有効性に影響をほとんど及ぼさない。
【００２３】
一般に所有される米国特許第７，１５５，４６６号明細書で述べられているように、それは、ＲＡＩＮベースのアーカイブシステムでデジタル財産をキャプチャし、保存し、管理し、検索する各ノード上で実行された分散ソフトウェアアプリケーションを組込む事で知られている。図２は、１つのそのようなシステムを示す。個々のアーカイブの物理的な境界は、クラスタ（あるいはシステム）と呼ばれる。典型的には、クラスタは、単一のデバイスではなく、好ましくはデバイスの集合である。デバイスは、同種かもしれないし、あるいは異種かもしれない。典型的なデバイスは、Ｌｉｎｕｘのようなオペレーティングシステムを実行するコンピュータ又はマシンである。コモディティハードウェア上でホストされたＬｉｎｕｘベースのシステムのクラスタは、少数のストレージノードサーバから何千テラバイトものデータを格納する多くのノードまで計ることができるアーカイブを提供する。このアーキテクチャは、記憶容量が組織の増加するアーカイブ要求と歩調を常に合わせることができることを保証する。
【００２４】
上記のようなストレージシステムにおいて、アーカイブがデバイス障害から常に保護されるように、データがクラスタに渡って典型的にランダムに分散される。ディスクか又はノードが機能しなくなる場合、クラスタは、自動的に同じデータの複製を維持するクラスタ中の他のノードにフェイルオーバする。このアプローチは、データ保護の見地からうまくいくが、クラスタのための計算された平均データロス（ＭＴＤＬ）時間は、望まれたほど高くないかもしれない。特に、アーカイブがデータを失う前に、ＭＴＤＬは、典型的に時間の計算量を表わす。デジタルアーカイブにおいて、どんなデータロスも望ましくないが、ハードウェアとソフトウェアのコンポーネントの性質により、そのような発生の可能性（しかし、遠隔）が常にある。オブジェクトのランダム分散及びアーカイブクラスタ内のそれらのコピーのため、所与のノード内の所与のディスク（ミラーコピーがその上に格納される）が、不意に機能しなくなる場合、例えば、オブジェクトの必要とされるコピーが利用不可能かもしれないので、ＭＴＤＬは、要求されたものより低い状態で終了するかもしれない。
【００２５】
図２に示されるように、本発明が好ましく実行される例示的なクラスタは、下記の一般的なカテゴリーのコンポーネント、すなわち、ノード２０２、ネットワークスイッチ２０４のペア、電力分散ユニット（ＰＤＵ）２０６及び無停電電源（ＵＰＳ）２０８を好ましくは有する。ノード２０２は、典型的に１つ以上のコモディティサーバを有し、ＣＰＵ（例えばインテルｘ８６、適切なランダムアクセスメモリ（ＲＡＭ）、１つ以上のハードドライブ（例えば標準のＩＤＥ／ＳＡＴＡ、ＳＣＳＩなど）及び２枚以上のネットワークインターフェイス（ＮＩＣ）カード）を有する。典型的なノードは、２.４ＧＨｚのチップ、５１２ＭＢ ＲＡＭ及び６つの（６）２００ＧＢハードドライブを備えた２Ｕラックマウントユニットである。しかし、これに限られない。ネットワークスイッチ２０４は、典型的にノード間のピアツーピア通信を可能にする内部スイッチ２０５、及び、各ノードへの追加のクラスタアクセスを許可する外部スイッチ２０７を有する。各スイッチは、クラスタ中の全て潜在的なノードを扱うことを十分なポートに要求する。イーサネットまたはGigEのスイッチは、この目的に使用されてもよい。ＰＤＵ２０６は、全てのノード及びスイッチに動力を提供するために使用され、ＵＰＳ２０８は、全てのノード及びスイッチを保護するために使用される。制限しているつもりではないが、典型的にクラスタは、公衆インターネット、企業イントラネットあるいは他の広域か、ローカルエリアネットワークのようなネットワークに連結可能である。例となる実施例において、クラスタは、企業環境内で実施される。それは、例えばサイトの企業ドメイン名前システム（ＤＮＳ）ネームサーバによってナビゲートすることにより達するかもしれない。従って、例えば、クラスタのドメインは、既存のドメインの新しいサブドメインかもしれない。代表的な実施において、サブドメインは、企業のＤＮＳサーバの中でクラスタ自体の中のネームサーバに委託される。エンドユーザは、任意の従来のインターフェースあるいはアクセスツールを使用して、クラスタにアクセスする。従って、例えば、クラスタへのアクセスは、任意のＩＰベースのプロトコル（ＨＴＴＰ、ＦＴＰ、ＮＦＳ、ＡＦＳ、ＳＭＢ、ウェブサービスなど）上に、ＡＰＩを経由して、あるいは他の既知か、その後発展したアクセス方式、サービス、プログラムあるいはツールを通じて実行されるかもしれない。
【００２６】
クライアントアプリケーションは、標準ＵＮＩＸファイルプロトコルのような１つ以上のタイプの外部ゲートウエイによるクラスタ、またはＨＴＴＰ ＡＰＩにアクセスする。アーカイブは、好ましくは、オプションで任意の標準ＵＮＩＸファイルプロトコル系設備の下に位置できる仮想ファイルシステムを通じて露出される。これらは、ＮＦＳ、ＦＴＰ、ＳＭＢ／ＣＩＦＳなどを含む。
【００２７】
１つの実施例において、アーカイブクラスタアプリケーションは、クラスタとして（例えば、イーサネット経由で）ネットワーク化される独立ノード（Ｈ−ＲＡＩＮ）の冗長アレイ上で作動する。所与のノードのハードウェアは異種かもしれない。最大の信頼性のために、しかし、好ましくは、各ノードは、今、図３に示されるようないくつかのランタイムコンポーネントから成る分散アプリケーション（すなわち、同じインスタンス、あるいは本質的に同じインスタンスかもしれない）のインスタンス３００を実行する。従って、ハードウェアは、異種かもしれないが、ノード（少なくともそれが本発明に関係のある）上のソフトウェアスタックは、同じである。これらのソフトウェアコンポーネントは、ゲートウエイプロトコルレイヤ３０２、アクセスレイヤ３０４、ファイルトランザクション及び管理レイヤ３０６、及び、コアコンポーネントレイヤ３０８を有する。機能が他の意味のある方法で特徴づけられるかもしれないことを通常のスキルのうちの１つが認識するので、「レイヤ」指定は、説明目的に提供される。レイヤ（あるいはその点でコンポーネント）の１つ以上は、統合されるかそうでないかもしれない。いくつかのコンポーネントは、レイヤに渡って共有されるかもしれない。
【００２８】
ゲートウエイプロトコルレイヤ３０２の中のゲートウエイプロトコルは、既存のアプリケーションに透明性を提供する。具体的には、ゲートウエイは、カスタムアプリケーションを構築するためのウェブサービスＡＰＩ同様に、ＮＦＳ３１０及びＳＭＢ／ＣＩＦＳ３１２のようなネイティヴファイルサービスを提供する。ＨＴＴＰサポート３１４も提供される。アクセスレイヤ３０４は、アーカイブへのアクセスを提供する。具体的には、発明によれば、固定コンテンツファイルシステム（ＦＣＦＳ）３１６は、アーカイブオブジェクトへフルアクセスを提供するためにネイティヴファイルシステムをエミュレートする。あたかもそれらが通常のファイルかのように、ＦＣＦＳは、アーカイブコンテンツにアプリケーションダイレクトアクセスを与える。好ましくは、メタデータがファイルとして露出されている一方、アーカイブコンテンツは、そのオリジナルフォーマットでレンダリングされる。ＦＣＦＳ３１６は、管理者らが、使いやすい方法で固定コンテンツのデータをセットアップできるように、ディレクトリと許可についての従来のビュー及びルーチンファイルレベルコールを提供する。ファイルアクセス呼び出しは、好ましくは、ユーザスペースデーモンによって傍受され、ダイナミックに呼び出しのアプリケーションへの適切な表示を作成する適切なコアコンポーネント（レイヤ３０８に）に送られる。ＦＣＦＳ呼び出しは、好ましくは、自律的なアーカイブ管理を促進するアーカイブポリシによって抑制される。従って、一例において、管理者かアプリケーションは、保存期間（所与のポリシ）がまだ有効のアーカイブオブジェクトを削除することができない。
【００２９】
アクセスレイヤ３０４は、好ましくは、また、ウェブユーザインターフェース（ＵＩ）３１８及びＳＮＭＰゲートウエイ３２０を含む。ウェブユーザインターフェース３１８は、ファイルトランザクション及び管理レイヤ３０６での管理エンジン３２２への対話型のアクセスを提供する管理者コンソールとして好ましくは実施される。管理上のコンソール３１８は、好ましくは、アーカイブオブジェクト及び個々のノードを含むアーカイブの動的考察を提供するパスワードで保護されウェブベースのＧＵＩである。ＳＮＭＰゲートウエイ３２０は、安全にストレージ管理アプリケーションがクラスターアクティビティを監視し制御することを可能にしながらストレージ管理アプリケーションに管理エンジン３２２への容易なアクセスを提供する。管理エンジンモニタは、システムとポリシイベントを含むアクティビティをクラスタする。ファイルトランザクションと管理レイヤ３０６は、また、要求マネージャプロセス３２４を含む。要求マネージャ３２４は、コアコンポーネントレイヤ３０８の中のポリシマネージャ３２６からの内部要求と同様に外界（アクセスレイヤ３０４を通じて）からの全ての要求を統合する。
【００３０】
コアコンポーネントは、ポリシマネージャ３２６に加えて、メタデータマネージャ３２８及びストレージマネージャ３３０の１つ以上のインスタンスを含む。メタデータマネージャ３２８は、各ノードに好ましくはインストールされる。クラスタ中のメタデータマネージャは、集合的に、全てのアーカイブオブジェクトを管理しながら、分散型データベースとして作動する。所与のノードにおいて、メタデータマネージャ３２８は、好ましくは、アーカイブオブジェクトのサブセットを管理し、各オブジェクトが、好ましくは、外部ファイル（「ＥＦ」（ストレージ用にアーカイブに入ったデータ））とアーカイブデータが物理的に検索される内部ファイル（各々「ＩＦ」）のセット間をマップする。同じメタデータマネージャ３２８は、また、他のノードから複製されたアーカイブオブジェクトのセットを管理する。従って、全ての外部ファイルの現状は、いくつかのノード上の複数メタデータマネージャに常に利用可能である。ノード障害の場合には、他のノード上のメタデータマネージャが、機能不全のノードによって以前管理されたデータへのアクセスを提供し続ける。ストレージマネージャ３３０は、分散アプリケーション中の他の全てのコンポーネントに利用可能なファイルシステムレイヤを提供する。好ましくは、それはノードのローカルファイルシステムにデータオブジェクトを格納する。所与のノード中の各ドライブは、好ましくは、それぞれ自身のストレージマネージャを持っている。これは、ノードが個別のドライブを削除し、処理能力を最適化することを可能にする。ストレージマネージャ３３０は、また、システム情報、データの一貫性チェック及び直接ローカル構造をトラバースする能力を提供する。
【００３１】
さらに図３で示されるように、クラスタは、通信ミドルウェアレイヤ３３２及びＤＮＳマネージャ３３４を通じて内部及び外部通信を管理する。インフラストラクチャ３３２は、アーカイブコンポーネント中の通信を可能にする効率的で信頼できるメッセージベースのミドルウェアレイヤである。図で示した実施例において、レイヤは、マルチキャストとポイントツーポイント通信をサポートする。ＤＮＳマネージャ３３４は、企業サーバに全てのノードを接続する分散型ネームサービスを行う。好ましくは、ＤＮＳマネージャ（単独であるいはＤＮＳサービスと共に）ロードバランスは、最大のクラスタ処理能力及び有効性を保証することを全てのノードに渡って要求する。
【００３２】
図で示した実施例において、ＡｒＣアプリケーションインスタンスは、Red Hat Linux 9.0、Fedora Core 6などのような基礎オペレーティングシステム３３６上で実行する。通信ミドルウェアは、任意の便利な分散型通信メカニズムである。他のコンポーネントは、固定コンテンツファイルシステム（ＦＣＦＳ）３１６のために使用されてもよいＦＵＳＥ（USErspaceの中のファイルシステム）を含むかもしれない。ＮＦＳゲートウエイ３１０は、標準のnfsd LinuxカーネルＮＦＳドライバによって実施されるかもしれない。各ノード中のデータベースは、実施されるかもしれない、例えば、オブジェクト関係データベース管理システム（ＯＲＤＢＭＳ）であるPostgreSQL（またここにPostgresとして引用される）である。ノードは、Java HTTPサーバ及びservletコンテナーであるジェティのようなウェブサーバを含むかもしれない。もちろん、上記のメカニズムは、単に例となる。
【００３３】
所与のノード上のストレージマネージャ３３０は、物理的な記憶デバイスを管理する責任がある。好ましくは、各ストレージマネージャインスタンスは、全てのファイルがその配置アルゴリズムによって入れられる単一のルートディレクトリの責任がある。複数のストレージマネージャインスタンスは、ノード上で同時に作動することができ、各々は、通常、システムで異なる物理的なディスクを表わす。ストレージマネージャは、システムの残りから使用されているドライブ及びインターフェース技術を抽象する。ストレージマネージャインスタンスがファイルを書くように依頼される場合、それはそのために責任を負う表現用のフルパス及びファイル名を生成する。代表的な実施例において、ストレージマネージャ上に格納される各オブジェクトは、それが異なるタイプの情報を追跡するデータを格納する場合、ファイルにそれ自身のメタデータを加えて、そのときストレージマネージャと共に保存されるローデータとして受信される。外部ファイル（ＥＦ）は、クエリエンジンを備えたクエリに続いて必要になる情報を格納する。例として、このメタデータは、限定無しで含む：ＥＦ長さ（バイトでの外部ファイルの長さ）、ＩＦセグメントサイズ（内部ファイルのこの部分のサイズ）、ＥＦ保護表現（ＥＦ保護モード）、ＩＦ保護役割（この内部ファイルの表現）、ＥＦ生成タイムスタンプ（外部ファイルタイムスタンプ）、シグネチャ（シグネチャタイプを含む書き込み（ＰＵＴ）の時間の内部ファイルのシグネチャ）及びＥＦファイル名（外部ファイルファイル名）。内部ファイルデータでこの追加のメタデータを格納することは、追加のレベルの保護を提供することである。具体的には、スカビンジングは、内部ファイルに保存されたメタデータからデータベースに外部ファイルレコードを作成することができる。他のポリシは、内部ファイルが元の状態のままになることを有効にするために内部ファイルに対する内部ファイルハッシュを有効にすることができる。
【００３４】
内部ファイルは、アーカイブオブジェクト中でオリジナルの「ファイル」の一部を表わす、データの「チャンク」かもしれない、また、それらはストライピングと保護ブロックを達成するために異なるノードに置かれるかもしれない。より小さくチャンクされたユニットへの外部ファイルのこの途切れ途切れは、必要不可欠ではないが、代案では、内部ファイルは、外部ファイルの完全なコピーかもしれない。典型的に、１つの外部ファイルエントリは各アーカイブオブジェクトのためのメタデータマネージャの中にあり、その一方で、個々の外部ファイルエントリのための多くの内部ファイルエントリがあるかもしれない。典型的に、内部ファイルレイアウトは、システムに依存する。所与の実施において、ディスク上のこのデータの実際の物理フォーマットは一連の可変長レコードに格納される。
【００３５】
要求マネージャ３２４は、システム内の他のコンポーネントとのやりとりによりアーカイブアクションを行なうために必要とされるオペレーションのセットを実行する責任がある。要求マネージャは、異なるタイプの多くの同時のアクションをサポートし、機能不全のトランザクションをロールバックすることができ、実行するのに長い時間かかるトランザクションをサポートする。要求マネージャは、更に、アーカイブの読取り書き込みオペレーションが適切に扱われる事を保証し、全ての要求がいつでも既知の状態である事を保証する。更に、それは、所与のクライアント要求を満たすためにノードに渡って複数の読取り書き込みオペレーションを調整するためにトランザクション制御を提供する。更に、要求マネージャは、最近使われたファイルのためのメタデータマネージャエントリをキャッシュに格納し、データブロックと同様にセッションのためのバッファリングを提供する。
【００３６】
クラスタの主要な責任は、ディスク上に無制限のファイルを確実に格納することである。それが何らかの理由で手が届かないか、そうでなければ利用不可能かもしれないという意味で、所与のノードは「信頼性が低い」と見なされるかもしれない。そのような潜在的に信頼性の低いノードのコレクションは、確実で、高度に利用可能なストレージを作成することに協力する。一般に、格納される必要のある２つのタイプの情報がある：ファイル自体及びファイルに関するメタデータ。固定コンテンツ分散型データストレージの追加の詳細は、参照によってここに組込まれる米国公開特許第２００７／０１８９１５３号明細書及び第２００６／００２６２１９号明細書で見ることができる。
【００３７】
II. メタデータ管理
【００３８】
メタデータマネジメントシステムは、システムメタデータのような所与のメタデータへのアクセスを組織し提供する責任がある。このシステムメタデータは、構成情報、管理ＵＩに表示された情報、メトリクス、回復不能なポリシ違反についての情報などに表示された情報等と同様にアーカイブに置かれたファイルについての情報を含む。詳細に示されていないが、他のタイプのメタデータ（例えばアーカイブしたファイルに関連したユーザメタデータ）も今説明されるメタデータ管理システムを使用して管理されるかもしれない。
【００３９】
クラスタの代表的な実施例において、メタデータ管理システムは、次のオブジェクトタイプ（それらは単に例となる）の１つ以上を含んでいるかもしれないメタデータオブジェクトのセットのための持続性を提供する。
【００４０】
ExternalFile：アーカイブのユーザによって知覚されるようなファイル。
【００４１】
InternalFile：ストレージマネージャによって格納されたファイル。典型的には、外部ファイルと内部ファイルの間に一対多数の関係があるかもしれない。
【００４２】
ConfigObject：クラスタを構成するのに使われる名前／値ペア。
【００４３】
AdminLogEntry：管理者ＵＩに表示されるメッセージ。
【００４４】
MetricsObject：ある時点でのアーカイブ（例えばファイルの数）のある測定を表わす、タイムスタンプされたキー／値ペア。
【００４５】
PolicyState：あるポリシの違反。
【００４６】
各メタデータオブジェクトは、好ましくは、変わらないユニークな名前を持っているかもしれない。メタデータオブジェクトは、リージョンに組織される。リージョンは、正式なリージョンコピーと「許容障害発生時点」（ＴＰＯＦ）数（０以上のセット）バックアップリージョンコピーから成る。０のコピーで、メタデータマネジメントシステムは、計量可能であるが、高度に利用可能ではないかもしれない。リージョンは、１つ以上のオブジェクト属性（例えばフルパス名やその一部のようなオブジェクトの名前）をハッシュ及びハッシュ値のビットの所与数の抽出により選択される。これらのビットは、リージョン番号から成る。選択されたビットは、低位ビット、高位ビット、中位ビットあるいは個々のビットの任意のコンビネーションかもしれない。代表的な実施例において、所与のビットはハッシュ値の低位ビットである。オブジェクトの属性か属性（複数）は、任意の便利なハッシュ関数を使用してハッシュされるかもしれない。これらは制限なしで、java.lang.string.hashCode等のようなＪａｖａベースのハッシュ関数を含む。 好ましくは、リージョン番号から成るビットの数は、ここでregionMapLevelと呼ばれ、構成パラメータによってコントロールされる。この構成パラメータが６にセットされる場合、例えば、これは２６＝６４リージョンが得られる。もちろん、多くのリージョンは許され、リージョンの数はネームスペース分割スキームを使用して自動的に調節されるかもしれない。
【００４７】
各リージョンは、重複して格納されるかもしれない。上記の通り、リージョンの１つの正式なコピー及び０以上のバックアップコピーがある。前述のように、バックアップコピーの数は、メタデータＴＰＯＦ構成パラメータによってコントロールされる。好ましくは、リージョンコピーは、１つのノード当たりの正式なリージョンコピーの数の平衡を保ち、かつ１つのノード当たりの合計のリージョンコピーの数の平衡を保つようにクラスタの全てのノードに渡って分散される。
【００４８】
メタデータ管理システムは、各ノード上で作動するデータベースにメタデータオブジェクトを格納する。このデータベースは、リージョンマップをサポートするために使用される。典型的なデータベースは、オープンソースとして利用可能であるPostgreSQLを使用して実施される。好ましくは、各リージョンコピーのスキーマがあり、各スキーマでは、各タイプのメタデータオブジェクト用のテーブルがある。スキーマは、単にテーブル、インデックス、手順及び他のデータベースオブジェクトを所有することができるネームスペースである。各リージョンは、好ましくは、それ自身のスキーマを持っている。各スキーマは、テーブル一式、すなわち各メタデータオブジェクトに１つ持っている。これらのテーブルのうちの１つの列は、単一のメタデータオブジェクトに相当する。Postgresが好ましいデータベースであると同時に、任意の便利なリレーショナルデータベース（例えばオラクル、IBM DB/2など）が使用されてもよい。
【００４９】
図４で示されるように、各ノード４００は、プロセスあるいはコンポーネント、すなわち、１つ以上のリージョンマネージャ（ＲＧＭ）４０２ａ−ｎ、メタデータマネージャ（ＭＭ）４０４、少なくとも１つのメタデータマネージャクライアント（ＭＭＣ）４０６、及び１つ以上のスキーマ４１０ａ−ｎがある１つのデータベース４０８、のセットを有する。ＲＧＭ（s）、ＭＭ及びＭＭＣコンポーネントは、Ｊａｖａ仮想マシンのようなバーチャルマシン４１２で実行する。各リージョンコピーにつき１つのＲＧＭがある。従って、正式なリージョンコピー用のＲＧＭ、各バックアップリージョンコピー用のRGM及びそれぞれ不完全なリージョンコピー用のＲＧＭがある。ＲＧＭ４０２のスキーマを管理する各ＲＧＭ４０２用のデータベーススキーマ４１０もある。データベースは、また、リージョンマップ４０５を格納する。各ノードは、好ましくは、同期スキームによって強化されている要求と共に、リージョンマップの同じ全体的な見解を持っている。リージョンマネージャＲＧＭ ４０２は、リージョンコピー（それが正式な、バックアップ、あるいは不完全な場合によっては）上で作動し、メタデータマネージャクライアント４０６、及び他のリージョンマネージャ４０２によって提出された要求の実行に責任がある。要求は、図３で示された通信ミドルウェアあるいは他のメッセージングレイヤのような任意の便利な手段を通じて所与のRGMに提供される。リージョンマネージャは、これらの要求が実行する実行環境を提供する、例えば、スキーマのＲＧＭによって管理されているスキーマ上で作動するように構成されているデータベースへの接続を提供することによって。各リージョンマネージャは、データベース４０８にそのデータを格納する。メタデータマネージャ４０４は、ノード上のメタデータ管理の責任があるトップレベルのコンポーネントである。それは、リージョンマネージャ（ＲＧＭ）を作成し破壊し、そして、ＲＧＭ、例えばクラスタ構成情報、データベース接続のプールによって必要とされるリソースを組織する責任がある。好ましくは、所与のメタデータマネージャ（所与のノード中の）は、リーダーとして働き、どのメタデータマネージャ（ノードのセット又はサブセットに渡った）がどのリージョンコピーに責任を負うかを決める責任がある。賛成アルゴリズム又はその変形のようなリーダー選挙アルゴリズムは、メタデータマネージャリーダーを選ぶために使用されるかもしれない。好ましくは、１つのノード当たり複数のＭＭを実行することは可能であるが、各ノードは、１つのメタデータマネージャを持っている。一旦リージョンオーナー権がネームスペース分割スキーム（下記に述べられるように）によって確立されたならば、各メタデータマネージャは、１つ以上のリージョンマネージャのそのセットに従って調節することに責任がある。システムコンポーネント（例えば管理エンジン、ポリシマネージャなど）は、メタデータマネージャクライアントを通じてメタデータマネージャＭＭとやりとりをする。ＭＭＣは、所与の要求を実行するためにＲＧＭを見つける事、選択されたＲＧＭに要求を出す事、及び選択されたＲＧＭが利用不可能な場合に（例えば、ノードが機能しなくなったので）要求を再試行することに責任がある。後者の場合は、新しいリージョンマップがノードで受信される場合、再試行要求が成功するであろう。
【００５０】
上記の通り、リージョンマップは、各リージョンの各コピーに責任のあるノードを識別する。バーチャルマシン４１２（またその中での各ＲＧＭ、ＭＭ、及びＭＭＣ構成要素）は、リージョンマップ４０５へのアクセスを持っている；リージョンマップのコピー４２０も、それがＪＶＭにコピーされた後、図４に示される。リージョンマップは、従って、所与のノード中のＪＶＭ及びデータベースの両方に利用可能である。このインスタンスとなる実施例において、各メタデータオブジェクトは、0x0と0x3fffffff合計間の整数を産出するためにハッシュされる、つまり３０ビットの値の属性（例えば名前）を持っている。これらの値は、オーバーフロー問題（例えば範囲の高域に１を加える時）にぶち当たる事なく、符号付き３２ビット整数中で快適に表わす事ができる。３０ビットは、大きなクラスタにさえ十分であるおよそ１０億までのリージョンを考慮に入れる。リージョンは、１セットのハッシュ値を表わし、全てのリージョンのセットは、あらゆるハッシュ値をカバーする。各リージョンのための異なるビット位置があり、異なるビット位置は、好ましくは固定順になっている。従って、各リージョンは、ハッシュ値のRegionLevelMapビットの抽出により好ましくは引き出される数によって識別される。６４リージョンを考慮に入れて、構成パラメータが６にセットされる場合、生じるハッシュ値は、0x0から0x3fの数である。
【００５１】
先述の通り、リージョンコピーは、３つの（３）段階、すなわち、「正式な」、「バックアップ」そして「不完全」のうちの１つにある。リージョンコピーが正式のある場合、リージョンへの全ての要求がこのコピーに行き、また、各リージョンにつき１つの正式なコピーがある。リージョンコピーがバックアップである場合、コピーは、バックアップ要求（正式なリージョンマネージャプロセスからの）を受信する。メタデータがロードされているが、コピーがまだ同期されない（典型的に他のバックアップコピーに関して）場合、リージョンコピーは、不完全である。同期が完了するまで、不完全なリージョンコピーは、別の段階への昇進の資格を有さない、すなわち、そのポイントではコピーは、バックアップコピーになる。各リージョンは、１つの正式なコピー、所与の数（メタデータＴＰＯＦ構成パラメータによってセットされた）バックアップあるいは不完全なコピーを持っている。
【００５２】
バックアップリージョンコピーは、正式なリージョンコピーとそのＴＰＯＦバックアップコピー間で所与のプロトコル（あるいは「契約」）を強化することにより、正式なリージョンコピーと同期され続ける。このプロトコルは、今説明される。
【００５３】
簡易バックグラウンド経由で、更新要求がＭＭＣで受信される場合、ＭＭＣは正式なリージョンコピーの位置を見つけるためにローカルのリージョンマップ上の検索を行う。ＭＭＣは、正式なリージョンコピーに関連したＲＧＭに更新要求を送信する、すなわち、その後、それを委託する。更新も、ＴＰＯＦバックアップコピーの各々のＲＧＭに（正式なリージョンコピーに関連したＲＧＭによって）送られる。しかし、正式なＲＧＭは、成功を示すために、更新情報を委託するのにバックアップリージョンコピーに関連した各ＲＧＭを待つ必要はない；むしろ、バックアップリージョンコピーに関連したＲＧＭが更新情報を受信する場合、それは、直ちに確認を返す（正式なＲＧＭに）又は返そうとする。バックアップ要求が受信される場合、そしてそれが実行される前に、この確認が出される。障害が生じない場合、一旦正式なＲＧＭが全ての確認を受信すれば、それは、ＭＭＣに通知する、すなわち、その後、それは、発信者に成功を返す。しかし、所与の故障事象が生じる場合、プロトコルは、影響を与えられたＲＧＭ（バックアップ、あるいは正式な）が、サービスからそれ自身を削除する（また潜在的に影響を受けたノード）事を保証し、新しいリージョンマップは、ＭＭリーダーによって出される。好ましくは、どんな便利な技術が使用されてもよいが、ＲＧＭは、ＪＶＭを下げる事によりサービスからそれ自身を削除する。新しいマップは、失われたリージョンコピーの置換を指定する。このように、各バックアップリージョンコピーは、正式なリージョンコピー用の「ホットスタンバイ」であり、従って、必要ならば及びその場合、（正式なＲＧＭがロードバランシング目的あるいはそのような理由のために機能しなくなるので）正式なに昇格の資格を有する。
【００５４】
更新処理が失敗するいくつかの方法がある。従って、例えば、正式なリージョンマネージャ（確認を待っている間）は、バックアップマネージャプロセスが故障した事を示す例外に遭遇するかもしれない、あるいは、たとえそれが確認を出したとしても、バックアップマネージャプロセスは、更新要求を局所的に処理するのに失敗するかもしれない、あるいは、確認を出す間のバックアップリージョンマネージャプロセスは、正式なリージョンマネージャプロセスが故障した事を示す例外に遭遇するかもしれない等など。上記の通り、所与のバックアップRGMが更新情報を処理することができない場合、それは、サービスから自身を削除する。更に、バックアップRGMあるいは正式なRGMのいずれかが故障する場合、新しいリージョンマップが出される。
【００５５】
メタデータマネジメントシステムは、リージョンのコピーを同期した状態に保つ。正式なリージョンコピーでのオブジェクトに終っている更新情報は、バックアップリージョンコピー上で複製される。一旦、更新情報が正式なRGMによって委託されれば、同じ更新情報は、全てのバックアップリージョンコピーに適用される。メタデータマネジメントシステムは、どんなそのような障害（ノードレベル、リージョンマネージャレベルまたは同様なもの）も障害したノード上のリージョンコピーの配置転換を引き起こす事を保証する；従って、残るリージョンコピーのインテグリティが保証される。正式なRGMを含んでいるノードが障害する場合、バックアップRGMは、同期している状態（現在実行する更新情報の有無に関わらず）あるいは、それらは、中断された更新情報によるのみ同期していない状態である。後者の場合は、再度同期させる事が容易である。バックアップリージョンが、正式なリージョンと同期され続けるので、昇格（バックアップから正式なまで）は瞬間的である。
【００５６】
ノード障害は、また、バックアップリージョンを失うであろう。バックアップリージョンは、他のあるノード、すなわち、新しく不完全なリージョン上で作成することにより復元される。不完全なリージョンが作られるとすぐに、それは、更新情報を記録し始め、正式なリージョンからデータをコピーし始める。複製が完了すると、最新のバックアップをもたらせながら蓄積された更新情報が適用される。その後、新しいバックアップリージョンは、それが最新であるとＭＭリーダーに通知する、すなわち、ＭＭリーダーにリージョン（不完全なからバックアップまで）の昇格を含むマップを送信させる。
【００５７】
注目すべきは、リージョンの数がノードの数に相当するという要求がない事である。より一般に、リージョンの数は、独立ノードのアレイのノードの数に関連しない。メタデータ管理の追加の詳細は、米国公開特許第２００６／００２６２１９号明細書で見ることができる。
【００５８】
III. ノードによってクエリ結果を集めること
【００５９】
発明の典型的な実施例は、ＲＥＳＴ（Representational State Transfer）クライアントが所与の基準のためのオブジェクトとシステムメタデータとのリストを検索するためにディレクトリ、サブディレクトリ、サブサブディレクトリ等をトラバースするために統合するアプリケーションの必要無しに所与の基準と一致するオブジェクトのリスト及びメタデータ用のコンテンツプラットフォームにクエリを行うことを可能にする。この発明の特徴は、クライアントアプリケーションが、変更時間によるクエリ、ディレクトリによるクエリ、トランザクション（作成、削除、パージ）によるクエリ、ネームスペースによるクエリ、及び、結果を通じてのページ等を行う能力を含む。単一のコンテンツプラットフォームノードは、コンテンツプラットフォームシステムでの全てのノードに渡って全てのリージョンにクエリを分散し、同じノードは、クライアントアプリケーションにリストを返す前に結果をソートする。特定の実施例によると、データベースクエリは、メタデータマネージャの中で実施される。
【００６０】
「変更時間」は、オブジェクト（コンテンツプラットフォームシステムでのコンテンツが読取り専用であるので、特に、そのメタデータ）が、ユーザによって最後に修正された時間である。例えば、時間は、１９７０年１月１日以来ミリセカンドの数で計られる。「ディレクトリによるクエリ」は、同じファイルシステムディレクトリに論理上存在する、コンテンツプラットフォームシステムでの全てのオブジェクトを検索する行為である。コンテンツプラットフォームシステムは、そのデータベースに対するSQLクエリの実行によりこれを遂行する。「トランザクションによるクエリ」は、最近のアクセスがあるタイプのオペレーションによったコンテンツプラットフォームシステムでの全てのオブジェクトを検索する行為である。例えば、それは、最近の活動がそれらの生成であった全てのオブジェクト、あるいは、最近削除された全てのオブジェクトを返すことができるかもしれない。「ネームスペースによるクエリ」は、全てのオブジェクト、そして、特定のコンテンツプラットフォームシステムネームスペースの中のそれらのオブジェクトだけを検索する行為である。「結果を通じてのページ」は、個々のオブジェクト中ではなく、セット中のクエリの結果セットとやりとりを行う行為である。例えば、クエリは、１０００のオブジェクトによって満たされるかもしれない。従来の相互作用において、クライアントは、１０００の相互作用を要求して、ひとつずつそれらのオブジェクトを検索し検査するであろう。 ページングスキームにおいて、それらは、結果をトラバースするのに必要な相互作用の数を減らす５０、１００あるいは他のある数のバッチ中のクライアントに返される。
【００６１】
III.A. クエリ定義
【００６２】
図５は、単一ノード５１０によって全ての他ノード５１２、５１４、５１６へクライアントアプリケーション５０２からクエリを分散することを示すコンテンツプラットフォーム５００の簡略化したブロック図である。その後、クエリの結果は、それらがHTTPクライアントアプリケーション５０２に返される前に、フィルタされソートされる。コンテンツプラットフォーム５００は、ネットワーク化された独立ノードの冗長アレイを含む。クエリの基準に適合したオブジェクトを見つけることによりクエリの結果を提供するために、クエリは、各ノード中で処理される。クエリ結果をフィルタすることは、結果セット内でＲＥＳＴクライアントによる基準又は所与の基準に一致する結果だけを含むことを意味する。オブジェクトは、オペレーションタイプ（つまり、「作成された」「削除された」「変更されたメタデータ」等）によってフィルタされる。例えば、クライアントが単にトランザクション=レコード作成を見ることを望む場合、呼び出された全てのレコード及びトランザクション=作成に一致するレコードだけが含まれる。
【００６３】
ステップ１において、アプリケーション５０２は、ノード５１０を分散するクエリである第１のノード又は主要なノードへのクエリを送る。ステップ２において、第１のノード５１０は、アプリケーション５０２から受信した要求に基づいて、コンテンツプラットフォーム５００内の他のノード５１２、５１４、５１６の各々へクエリを出す。ステップ３において、コンテンツプラットフォーム５００内の各ノードは、ノード内の正式なリージョンを全てクエリし始め、セット中の結果を提供する。ステップ４において、第１のノード５１０は、連続的に検索し、統合し、全てのノードからの結果をフィルタしソートする。ステップ５において、第１のノード５１０は、アプリケーション５０２に結果のセットを返す。ステップ６において、アプリケーション５０２は、第１のノード５１０へ結果の次のセットの要求を出すかもしれない、そして上記のステップ２−５が繰り返される。各リージョンは、好ましくは、データベースインデックスの使用を通じてオブジェクト変更時間上のクエリを扱うために最適化されたデータベースにマッピングする。
【００６４】
図６は、全て他のノードに第１のノード５１０によるクライアントアプリケーション５０２からのクエリを分散し、クライアントアプリケーション５０２へのクエリの結果を統合し、返す過程を示すフロー図の例である。この例において、クエリは、供給されたＵＵＩＤ（Universal Unique Identifier）、ディレクトリパス及びchange_timesの中の１００のオブジェクトを選択する。クエリによって作られた順序付けは、（uuid、change_time、fn_hash）である。
【００６５】
ステップ６０２で、クライアントアプリケーション５０２は、ある基準を満たすオブジェクトのリストを要求する。ステップ６０４において、要求を受信する第１のノード５１０は、全ての他ノードにクエリを出す。ステップ６０６において、各ノードは、そのノードにおけるリージョンについてのクエリを始める。ステップ６０８で、各ノードは、ノード上の各リージョンにつき最初の１００の結果を検索する。ステップ６１０において、第１のノード５１０は、全てのノードから結果の最初のセットを検索する。ステップ６１２において、第１のノードは、結果を統合し、フィルタし、ソートする（クライアントアプリケーション５０２が次のセットの結果を要求することをやめるまで、これは連続的に行われる）。ステップ６１４において、第１のノード５１０は、クライアントアプリケーション５０２に結果を返す。ステップ６１６において、クライアントアプリケーションは、完了（クライアントアプリケーション５０２が次のセットの結果を要求することをやめるまで、これは行われる）まで結果を受信する。ステップ６１８において、クライアントアプリケーション５０２は、結果の次のセットの要求を第１のノード５０２に送信する。ステップ６２０において、第１のノード５０２は、完了（クライアントアプリケーション５０２が次のセットの結果を要求することをやめるまで、これは行われる）まで全てのノードから統合され、フィルタされ、ソートされた追加の結果を要求する。
【００６６】
クエリ結果（つまりクエリを出し、処理し、クエリの結果を統合し、フィルタする）を管理するプロセスは、クエリ結果管理モジュール中で実行されるかもしれない。特定な実施例において、クエリ結果管理モジュールは、コンテンツプラットフォームの各ノード中のメタデータマネージャの中で提供される。
【００６７】
III.B. CPExternalFileQueryRequest
【００６８】
CPExternalFileQueryRequestは、メタデータマネージャクライアントから特定な正式なリージョン番号への要求である。その要求は、QueryParametersに適合するexternal_fileテーブルから１バッチを返す。CPExternalFileQueryRequestは、前のセクションで説明されたそれと同じクエリを起動するであろう。上記の通り、クエリは、（uuid、change_time、fn_hash）によって指図される。バッチを返す前に、リストはこの正確な順序付けを生じさせるためにさらにソートされる（メモリ内で）：
（uuid、change_time、fn_hash、ディレクトリ、file_name、version_id）。
結果の次のセット／バッチを要求するために第１のノード５１０と他のノード間の通信を提供するために、この特徴は、ソフトウェアモジュールとして実施されるかもしれない。「uuid」は、オブジェクトのためのユニバーサルユニーク識別子である。この場合、それは、オブジェクトが存在するネームスペースを識別する。「change_time」は、レコードが最後に修正された日付及び時間を反映する。「fn_hash」は、ネームスペース中のオブジェクトの名前にハッシュ関数を適用する結果を表わし、オブジェクトの識別のために省略表現として使用される。米国公開特許第２００６／００２６２１９号明細書を参照。「version_id」は、ネームスペース中のオブジェクトの特別なバージョンのためのユニーク識別子である。
【００６９】
III.C. RemoteQueryBatchIterator
【００７０】
RemoteQueryBatchIteratorは、バッチを検索するCPExternalFileQueryRequestメッセージを送るBatchIteratorの単純拡大である。これは、通常、局所リージョンにクエリを行うBatchIteratorの典型的な実施とほんの少し異なる。クエリエンジンは、特定なリージョン番号及び生成上のマップサイズに結合する。第１のノード５１０がクライアントアプリケーション５０２からある基準を備えたオブジェクトのリストの要求を受信する場合、第１のノード５１０から他のノードにクエリを出すために、この特徴は、ソフトウェアモジュールとして実施されるかもしれない。
【００７１】
III.D. ExternalFileQuery
【００７２】
ExternalFileQueryクラスは、システムでクエリエンジンの全てに渡って統合するMetadataManagerClient.Operationインプリメンテーションである。RemoteQueryBatchIteratorから返された各クエリエンジンが厳密に指図されるので、PriorityQueueIteratorは、これらのクエリエンジンに渡って効率的に統合することができる。結果として生じるクエリは、全てのリージョンに渡って正確に指図される。返されたクエリは、タイプMetadataIterator<ExternalFile>になるであろう。全てのノードから第１のノード５０２によって集められた結果を統合し、フィルタするために、この特徴はソフトウェアモジュールとして実施されるかもしれない。
【００７３】
全てのリージョンに渡って統合するためのアルゴリズムは、かなり簡単である：（１）giveノード中の全てのリージョンを処理する、（２）RemoteQueryBatchIterator（リージョン、QueryParameters）を作成する、（３）PriorityQueueIterator（収集<RemoteQueryBatchIterator>iterators、QueryKeyExtractor）を作成する、そして（４）リターンPriorityQueueIteratorを返す。
【００７４】
発明の特定の実施例によると、上記のクエリ結果を統合するための技術は、検索エンジン、バックアップサーバ、ポリシエンジン、RBSを使用するアプリケーション、XAMを使用するアプリケーション又は同種のものを備えたコンテンツプラットフォーム統合のサポートを提供するのを助けるメタデータクエリエンジンの一部である。
【００７５】
もちろん、図１及び５に示されたシステム構成は、本発明が実行されるかもしれないストレージアーカイブの純粋な模範例であり、発明は、特定なハードウェア構成に制限されない。発明を実行するコンピュータとストレージシステムは、また、上記発明を実行するために使用されるモジュール、プログラム及びデータ構造を格納し読む事ができるI/Oデバイス（例えばCD及びDVDドライブ、フロッピーディスクドライブ、ハードドライブなど）として知られてきた。これらのモジュール、プログラム及びデータ構造は、そのようなコンピュータが読めるメディア上でエンコードすることができる。例えば、発明のデータ構造は、発明に使われるプログラムが存在する１以上のコンピュータが読めるメディア上に単独で格納することができる。システムのコンポーネントは、任意の形式あるいはデジタルデータ通信、例えば通信ネットワークのメディアによって相互連結することができる。通信ネットワークの例は、ローカルエリアネットワーク、広域ネットワーク、例えばインターネット、ワイヤレスネットワーク、ストレージエリアネットワークそして同種のものを含む。
【００７６】
説明において、多数の詳細が本発明についての完全な理解を提供するために説明の目的のために述べられる。しかし、これらの特定な詳細の全てが本発明を実行するために必要だとは限らないという事が当業者には明らかである。発明がプロセス、すなわち、フローチャート、フロー図、構造図あるいはブロック図として通常描かれると説明されるかもしれない事がさらに注目される。フローチャートは、オペレーションを連続するプロセスと説明するかもしれないが、オペレーションの多くは、並行してあるいは同時に行なう事ができる。更に、オペレーションの順序は並べ替えられるかもしれない。
【００７７】
当技術で知られているように、上記のオペレーションは、ハードウェア、ソフトウェアあるいはソフトウェアとハードウェアのあるコンビネーションによって行なう事ができる。もしプロセッサによって実行されれば、プロセッサに発明の実施例を実行する方法を行なわせるだろう機械可読媒体（ソフトウェア）上に格納された指示を使用して、他の態様が実施されるかもしれない一方、発明の実施例の種々態様は、回路及び論理回路（ハードウェア）を使用して、実施されるかもしれない。更に、他の実施例は、唯一ソフトウェア内で行なわれるかもしれないが、発明のいくつかの実施例は、唯一ハードウェア内で行なわれるかもしれない。更に、説明された様々な機能は、単一のユニットで行なう事ができるか、あらゆる方法を用いて多くのコンポーネントに広げる事ができる。ソフトウェアによって行なわれた場合、その方法は、汎用計算機のようなコンピュータが読めるミディアム上に格納された指示に基づいたプロセッサによって実行されるかもしれない。もし望まれれば、指示は、圧縮されかつまたは暗号化された、フォーマットでミディアム上に格納することができる。
【００７８】
前述から、発明がフォールトトレラントデータベース管理システムでクエリ結果を統合するためにコンピュータ読取り可能な記憶媒体上に格納された方法、装置及びプログラムを提供することは明白であろう。更に、特定な実施例がこの明細書に示され、説明されてきた一方、当事者達は、同じ目的を達成すると計算されるいかなる配置が、公開された特定な実施例の代わりに用いられるかもしれない事を認識している。この開示は、本発明のありとあらゆる適応あるいは変化をカバーするように意図され、下記の請求項の中で使用される用語が、発明を明細書に公開された特定な実施例に制限するために解釈されるべきでない事が、理解される事になっている。正しくは、発明の範囲は、そのような請求項が与えられる同等物の全範囲に加えて請求項解釈の確立した主義に従って解釈される事になっている下記の請求項によって完全に決定される事になっている。
【発明の名称】フォールトトレラントデータベース管理システムにおいてクエリ結果を統合するシステム及び方法
【背景技術】
【０００１】
本発明は、一般に、ストレージシステム、及び、特に、フォールトトレラントデータベース管理システムにおけるクエリ結果を統合するシステム及び方法に関する。
【０００２】
顧客は、彼らのビジネスニーズおよびシナリオに基づきコンテンツプラットフォームを備えた異なる統合ニーズを持つことができる。１つの共通テーマは、彼らのインフラストラクチャにおける別のアプリケーションに移る、特定の機能（例えば、データの検索又はデータのバックアップ）のオブジェクトとそれらオブジェクトについての情報とのリスト、を検索することを取り囲む。これをするために、そのアプリケーションは、この情報を検索するためにより多くの仕事をするように要求されるかもしれない。例えば、統合アプリケーションは、所与の基準のオブジェクトとシステムメタデータとのリストを検索するためにディレクトリ、サブディレクトリ、サブサブディレクトリ、その他をトラバースしなければならないであろう。これは、独立ノードの冗長アレイがネットワーク化されていて、ノードの各クラスタ／システムが、テナントとネームスペースに分割される場合、インタレストの全てのネームスペースに渡って、インタレストの全てのテナントに渡って等などネームスペース内で全てのディレクトリのために行われなければならない。ネームスペースは、クラスタの論理パーティションで、特に少なくとも１つの定義されたアプリケーションにオブジェクトのコレクションとして本質的に役目を果たす。各ネームスペースは、他のネームスペースに関してプライベートファイルシステムを持っている。さらに、1つのネームスペースへのアクセスは、別のネームスペースへのユーザアクセスを許可しない。テナントは、ネームスペース、場合により他のサブテナントのグループである。クラスタ／システムは、物理的なアーカイブインスタンスである。同一出願人による、２００９年１０月３０日に出願された米国特許出願第１２／６０９，８０４「分割されたコンテンツプラットフォーム内の、ネームスペースを使用する固定コンテンツストレージ」と題する、を参照することにより本書に組み込まれる、を参照すること。
【発明の簡単な概要】
【０００３】
発明の典型的な実施例は、ＲＥＳＴ（Representational State Transfer）クライアントが、ディレクトリ、サブディレクトリ、サブサブディレクトリ、その他をトラバースする統合アプリケーションの必要無しに、所与の基準のオブジェクトとシステムメタデータとのリストを検索するために、所与の基準と一致するオブジェクトとメタデータとのリストについてのコンテンツプラットフォームにクエリを行うことを、可能にする。例えば、クライアントアプリケーションは、変更時間によるクエリの実行、ディレクトリによるクエリの実行、トランザクション（作成、削除、パージ）によるクエリの実行、ネームスペースによるクエリの実行、又は、結果をぱらぱらと確認すること、を行うかもしれない。この発明で、単一のコンテンツプラットフォームノードは、コンテンツプラットフォームシステムでの全てのノードに渡って全てのリージョンにクエリを分散し、同じノードは、クライアントアプリケーションにリストを返す前に結果をソートする。このように、コンテンツプラットフォームシステムは、コンテンツプラットフォームシステムでの全てのノードに渡ってクエリを行い、結果をフィルタし、ソートし、そして、クライアントアプリケーションに結果を返すことにより、この仕事のより多い負担を担う。
【０００４】
本発明の一態様は、ネットワーク化された独立ノードの冗長アレイを対象とし、各ノードは、オブジェクトベースのストレージを提供するアプリケーションのインスタンスを実行し、メタデータオブジェクトは、アレイに渡ってノード中に分散されたリージョンのセットに格納され、所与のリージョンは、メタデータオブジェクト属性をハッシュし、且つ、結果として生じるハッシュ値のビットの所与のセットを抽出することにより識別される。クエリ結果を管理する方法は、基準を満たしたオブジェクトのリストの要求をクライアントアプリケーションから複数の独立ノードの第１のノードによって受信すること、受信した要求に基づき全てのノードにクエリを第１のノードによって出すこと、リージョンに格納されているメタデータオブジェクトを使用してノードにおけるリージョンにわたってクエリを各ノードによって処理すること、全てのノードからのクエリの結果を第１のノードによって統合しフィルタすること、及び、統合されフィルタされた結果をクライアントアプリケーションに第１のノードによって返すこと、を有する。
【０００５】
いくつかの実施例において、各ノードによってクエリを処理することは、セット中のクエリの結果を第１のノードに提供することを有し、そして、全てのノードからのクエリの結果は、統合され、フィルタされ、セット中のクライアントアプリケーションに返される。その方法は、更に、第１のノードによって、統合されフィルタされた結果の現在のセットをクライアントアプリケーションに返した後、全てのノードから結果の次のセットを要求し検索する前、結果の次のセットのためのクライアントアプリケーションからの要求を待つこと、を有する。セット中のクエリの結果を第１のノードに提供することは、各リージョンからのオブジェクトのプリセットされた数をクエリの処理をすることの結果として提供すること、を有する。その方法は、更に、統合されフィルタされた結果をプリセットされた順序を生じさせるために第１のノードによってソートすること、を有する。その要求は、変更時間によるクエリ、ディレクトリによるクエリ、トランザクションによるクエリ、ネームスペースによるクエリ、及び、結果を通じたページ、のうちの１以上を含む。
【０００６】
本発明の別の一態様は、ネットワーク化された独立ノードの冗長アレイにおけるクエリ結果を管理する装置を対象とし、各ノードは、オブジェクトベースのストレージを提供するアプリケーションのインスタンスを実行し、メタデータオブジェクトは、アレイに渡ってノード中に分散されたリージョンのセットに格納され、所与のリージョンは、メタデータオブジェクト属性をハッシュし、且つ、結果として生じるハッシュ値のビットの所与のセットを抽出することにより識別される。その装置は、プロセッサ、メモリ、及び、ノードの各々のために備えられたクエリ結果管理モジュールを有する。クエリ結果管理モジュールは、そのクエリ結果管理モジュールを持つノードが、基準を満たしたオブジェクトのリストの要求をクライアントアプリケーションから受信する第１のノードであれば受信した要求に基づき全てのノードへクエリを出し、リージョンに格納されているメタデータオブジェクトを使用してノードにおけるリージョンにわたってクエリを処理し、そのクエリ結果管理モジュールを持ったノードが第１のノードであれば全てのノードからのクエリの結果を統合しフィルタする、ようになっており、統合しフィルタされた結果はクライアントアプリケーションに返される。
【０００７】
特定の実施例において、１つのノードは、メタデータオブジェクへのアクセスを組織し提供することを含むそのノード中のメタデータオブジェクトを管理するメタデータマネージャ、を有する。メタデータマネージャは、そのノードのクエリ結果管理モジュールを含む。
【０００８】
本発明の別の態様は、ネットワーク化された独立ノードの冗長アレイにおけるクエリ結果を管理するデータプロセッサを制御する複数の指示を記憶する、コンピュータ読取り可能な記憶媒体、を対象とし、各ノードは、オブジェクトベースのストレージを提供するアプリケーションのインスタンスを実行し、メタデータオブジェクトは、アレイに渡ってノード中に分散されたリージョンのセットに格納され、所与のリージョンは、メタデータオブジェクト属性をハッシュし、且つ、結果として生じるハッシュ値のビットの所与のセットを抽出することにより識別される。複数の指示は、そのコンピュータ読取り可能な記憶媒体を有するノードが、基準を満たしたオブジェクトのリストの要求をクライアントアプリケーションから受信する第１のノードであれば、受信した要求に基づき全てのノードへクエリを発行することをデータプロセッサにさせる指示を有し、また、リージョンに格納されているメタデータオブジェクトを使用してノードにおけるリージョンにわたってクエリを処理することをデータプロセッサにさせる指示を有し、また、コンピュータ読取り可能な記憶媒体があるノードが第１のノードであれば全てのノードからのクエリの結果を第１のノードによって統合しフィルタすることをデータプロセッサにさせる指示を有し、統合されフィルタされた結果はクライアントアプリケーションに返される。
【０００９】
本発明のこれら及び他の特徴及び利点は、特定の実施例の以下の詳細な説明を考慮して当業者に明らかになるであろう。
【図面の簡単な説明】
【図１】
【００１０】
図１は、発明の方法及び装置が適用され得る固定コンテンツストレージアーカイブの簡略化されたブロック図である。
【図２】
【００１１】
図２は、それぞれが対称でありアーカイブクラスタアプリケーションをサポートする独立ノードの冗長アレイの簡略化された説明図である。
【図３】
【００１２】
図３は、所与のノード上で実行するアーカイブクラスタアプリケーションの様々なコンポーネントの高レベル説明図である。
【図４】
【００１３】
図４は、クラスタの所与のノード上のメタデータ管理システムのコンポーネントの例を示す図である。
【図５】
【００１４】
図５は、単一ノードによりクライアントアプリケーションから全ての他ノードへクエリを分散することとクライアントアプリケーションに返されるクエリ結果を統合することとを示す、コンテンツプラットフォームの簡略化されたブロック図である。
【図６】
【００１５】
図６は、単一ノードによりクライアントアプリケーションから全ての他ノードへクエリを分散することと、単一ノードによりクライアントアプリケーションへのクエリ結果を統合し返すこととの処理を示すフロー図の例である。
【発明を実施するための形態】
【００１６】
発明の以下の詳細な説明において、開示の一部を形成する添付図面について言及がされ、その中で、図面で限定なく示され発明が実施されるかもしれない典型的な実施例として示される。図面において、類似の数字は、いくつかの見解に渡って本質的に同様のコンポーネントについて説明する。更に、注目すべきは、下記のように、及び図面の中で示されるように、詳細な説明が、様々な典型的な実施例を提供しているが、本発明が説明され、ここに示された実施例に限らず、当業者に知られている又は知られる他の実施例まで及ぶ可能性がある事である。「１つの実施例」、「この実施例」あるいは「これらの実施例」の明細書中の言及は、特定な特徴、構造あるいは実施例に関して説明された特性が、発明の少なくとも１つの実施例に含まれる事を意味し、明細中の様々な個所におけるこれらの句の出現は、必ずしも全ては、同じ実施例を指していない。更に、下記の詳細な説明において、多数の特定な詳細は、本発明についての完全な理解を提供するために述べられる。しかし、本発明を実行するためにこれらの特定な詳細が必ずしも全て必要ではないかもしれない事は、当業者に明らかであろう。他の状況において、有名な構造、材料、回路、プロセス及びインターフェースは、詳細に説明されておらず、かつ、本発明が不必要に不明瞭にならないようにブロック図の形式で示されるかもしれない。
【００１７】
更に、以下に続く詳細な説明のいくつかの部分は、コンピュータ内のオペレーションのアルゴリズム及び記号表現の点から示される。これらのアルゴリズムの説明及び記号表現は、その他の当業者に最も効果的に彼らの革新の本質を伝えるためにデータ処理に優れている人々によって使われる手段である。アルゴリズムは、所望最終状態か結果に導く一連の定義されたステップである。本発明において、行なわれたステップは、具体的結果の達成のために具体的な量の物理的な操作を要求する。通常、必ずではないが、これらの量は、格納する、組み合わす、比較する、またそうでなければ、操作することができる電気的か磁気信号あるいは指示の形式をとる。これらの信号をビット、値、要素、記号、文字、用語、数、指示などと呼ぶために主に一般的用法の理由で、時々便利であると証明されてきた。しかし、これら全て及び同類項が適切な物理量に関係しているはずであり、これらの量に当てはまる単に便利なラベルである事も留意しておくべきである。特に別記しない限り、以下の議論から明らかなものとして、説明全体に渡って、「処理すること」、「コンピューティング」、「計算すること」、「決定すること」、「表示すること」等の用語を使う議論は、コンピュータシステムの登録及びメモリ内の物理的な（電子の）量として表わされたデータをコンピュータシステムのメモリ、登録、あるいは他の情報ストレージ、送信又はディスプレイデバイス内の物理量として同様に表わされた他のデータに操作し、変形するコンピュータシステムあるいは他の情報処理デバイスのアクション及びプロセスを含むかもしれない事を認識しておくべきである。
【００１８】
本発明は、また、オペレーションをここで行なうための装置に関する。この装置は、要求された目的のために特別に構築されるかもしれない、あるいは、それは、１つ以上のコンピュータプログラムによって選択的に作動されたか再構成された１台以上の汎用コンピュータを含むかもしれない。そのようなコンピュータプログラムは、光ディスク、磁気ディスク、読み出し専用メモリ、ランダムアクセスメモリ、ソリッドステートデバイス及びドライブ、あるいは電子情報を格納するのにふさわしい他のタイプの媒体に制限されないが、これらのようなコンピュータ読取り可能な記憶媒体に格納されるかもしれない。ここに示されたアルゴリズムとディスプレイは、本質的にどんな特定なコンピュータあるいは他の装置とも関係がない。様々な汎用のシステムは、教えに従ってプログラムとモジュールと共にここに使用されてもよい、あるいは、希望の方法ステップを行なうためにもっと専門の装置を構築するのに便利であると言ってもよい。更に、本発明は、どんな特定なプログラミング言語に関しても説明されない。当然のことながら、ここに説明されるような発明の教えを実施するために、様々なプログラミング言語が使用されてもよい。プログラミング言語の指示は、１つ以上の処理デバイス、例えば中央処理装置（ＣＰＵ）、プロセッサ又はコントローラによって実行されても良い。
【００１９】
より詳しく以下に説明される発明の典型的な実施例は、フォールトトレラントデータベース管理システムにおけるクエリ結果を統合する装置、方法及びコンピュータプログラムを提供する。
【００２０】
I. 固定コンテンツ分散データストレージ
【００２１】
ニーズが、従来のテープ及び光学ストレージ解決法に取って代わるかそれを補う、高度に可用性、信頼性及び持続性のあるやり方で「固定コンテンツ」のアーカイブストレージについて発展してきた。用語「固定コンテンツ」は、典型的に、参照あるいは他の目的のためにそのままで保存される事が予想される任意のタイプのデジタル情報を指す。このような固定コンテンツの例としては、多くの例の中でもとりわけ、電子メール、文書、診断画像、チェック画像、音声録音、フィルム及びビデオなどが挙げられる。従来の独立ノード冗長アレイ（ＲＡＩＮ）ストレージ手法は、このような固定コンテンツの情報資産を記憶するための大規模なオンラインアーカイブを生み出すために選択されるアーキテクチャとして登場した。ＲＡＩＮアーキテクチャは、ノードが必要に応じてクラスタに結合すること及びクラスタから退出することを可能にすることにより、ストレージクラスタを１つまたは複数のノードの障害から隔離する。ＲＡＩＮタイプのアーカイブは、データを複数のノード上で複製することにより、ノードの障害または除去を自動的に補償することができる。通常、ＲＡＩＮシステムは、閉システム内の同一コンポーネントから設計されたハードウェア機器として広く提供される。
【００２２】
図１は、そのような計量可能なディスクベースのアーカイブのストレージ管理システムを示す。ノードは、異なるハードウェアから成るかもしれないし、従って、「異種である」と考えられるかもしれない。ノードは、典型的に、ストレージエリアネットワーク（ＳＡＮ）でのような実際の物理的なストレージディスク、又は仮想ストレージディスクかもしれない１枚以上のストレージディスクにアクセスする。各ノード上で支援されるアーカイブクラスタアプリケーション（及び任意でそのアプリケーションが実行する基本的なオペレーティングシステム）は、同じ又は実質的に同じかもしれない。ハードウェアが異種かもしれないのに対して、各ノード上の（オペレーティングシステムを含むかもしれない）ソフトウェアスタックは、対称である。システムを使用すると、図１で示されるように、企業は、文書、電子メール、衛星画像、診断画像、チェック画像、音声録音、ビデオなどのような様々なタイプの固定コンテンツ情報のための永久記録媒体を特に作成することができる。もちろん、これらのタイプは、単に例である。 ハイレベルな信頼度は、独立サーバ上のデータの複製、あるいは、いわゆるストレージノードにより達成される。好ましくは、各ノードは、そのピアと対称である。従って、好ましくは、任意の所与のノードが全ての機能を行なう事ができるので、どれか１つのノード障害は、アーカイブの有効性に影響をほとんど及ぼさない。
【００２３】
一般に所有される米国特許第７，１５５，４６６号明細書で述べられているように、それは、ＲＡＩＮベースのアーカイブシステムでデジタル財産をキャプチャし、保存し、管理し、検索する各ノード上で実行された分散ソフトウェアアプリケーションを組込む事で知られている。図２は、１つのそのようなシステムを示す。個々のアーカイブの物理的な境界は、クラスタ（あるいはシステム）と呼ばれる。典型的には、クラスタは、単一のデバイスではなく、好ましくはデバイスの集合である。デバイスは、同種かもしれないし、あるいは異種かもしれない。典型的なデバイスは、Ｌｉｎｕｘのようなオペレーティングシステムを実行するコンピュータ又はマシンである。コモディティハードウェア上でホストされたＬｉｎｕｘベースのシステムのクラスタは、少数のストレージノードサーバから何千テラバイトものデータを格納する多くのノードまで計ることができるアーカイブを提供する。このアーキテクチャは、記憶容量が組織の増加するアーカイブ要求と歩調を常に合わせることができることを保証する。
【００２４】
上記のようなストレージシステムにおいて、アーカイブがデバイス障害から常に保護されるように、データがクラスタに渡って典型的にランダムに分散される。ディスクか又はノードが機能しなくなる場合、クラスタは、自動的に同じデータの複製を維持するクラスタ中の他のノードにフェイルオーバする。このアプローチは、データ保護の見地からうまくいくが、クラスタのための計算された平均データロス（ＭＴＤＬ）時間は、望まれたほど高くないかもしれない。特に、アーカイブがデータを失う前に、ＭＴＤＬは、典型的に時間の計算量を表わす。デジタルアーカイブにおいて、どんなデータロスも望ましくないが、ハードウェアとソフトウェアのコンポーネントの性質により、そのような発生の可能性（しかし、遠隔）が常にある。オブジェクトのランダム分散及びアーカイブクラスタ内のそれらのコピーのため、所与のノード内の所与のディスク（ミラーコピーがその上に格納される）が、不意に機能しなくなる場合、例えば、オブジェクトの必要とされるコピーが利用不可能かもしれないので、ＭＴＤＬは、要求されたものより低い状態で終了するかもしれない。
【００２５】
図２に示されるように、本発明が好ましく実行される例示的なクラスタは、下記の一般的なカテゴリーのコンポーネント、すなわち、ノード２０２、ネットワークスイッチ２０４のペア、電力分散ユニット（ＰＤＵ）２０６及び無停電電源（ＵＰＳ）２０８を好ましくは有する。ノード２０２は、典型的に１つ以上のコモディティサーバを有し、ＣＰＵ（例えばインテルｘ８６、適切なランダムアクセスメモリ（ＲＡＭ）、１つ以上のハードドライブ（例えば標準のＩＤＥ／ＳＡＴＡ、ＳＣＳＩなど）及び２枚以上のネットワークインターフェイス（ＮＩＣ）カード）を有する。典型的なノードは、２.４ＧＨｚのチップ、５１２ＭＢ ＲＡＭ及び６つの（６）２００ＧＢハードドライブを備えた２Ｕラックマウントユニットである。しかし、これに限られない。ネットワークスイッチ２０４は、典型的にノード間のピアツーピア通信を可能にする内部スイッチ２０５、及び、各ノードへの追加のクラスタアクセスを許可する外部スイッチ２０７を有する。各スイッチは、クラスタ中の全て潜在的なノードを扱うことを十分なポートに要求する。イーサネットまたはGigEのスイッチは、この目的に使用されてもよい。ＰＤＵ２０６は、全てのノード及びスイッチに動力を提供するために使用され、ＵＰＳ２０８は、全てのノード及びスイッチを保護するために使用される。制限しているつもりではないが、典型的にクラスタは、公衆インターネット、企業イントラネットあるいは他の広域か、ローカルエリアネットワークのようなネットワークに連結可能である。例となる実施例において、クラスタは、企業環境内で実施される。それは、例えばサイトの企業ドメイン名前システム（ＤＮＳ）ネームサーバによってナビゲートすることにより達するかもしれない。従って、例えば、クラスタのドメインは、既存のドメインの新しいサブドメインかもしれない。代表的な実施において、サブドメインは、企業のＤＮＳサーバの中でクラスタ自体の中のネームサーバに委託される。エンドユーザは、任意の従来のインターフェースあるいはアクセスツールを使用して、クラスタにアクセスする。従って、例えば、クラスタへのアクセスは、任意のＩＰベースのプロトコル（ＨＴＴＰ、ＦＴＰ、ＮＦＳ、ＡＦＳ、ＳＭＢ、ウェブサービスなど）上に、ＡＰＩを経由して、あるいは他の既知か、その後発展したアクセス方式、サービス、プログラムあるいはツールを通じて実行されるかもしれない。
【００２６】
クライアントアプリケーションは、標準ＵＮＩＸファイルプロトコルのような１つ以上のタイプの外部ゲートウエイによるクラスタ、またはＨＴＴＰ ＡＰＩにアクセスする。アーカイブは、好ましくは、オプションで任意の標準ＵＮＩＸファイルプロトコル系設備の下に位置できる仮想ファイルシステムを通じて露出される。これらは、ＮＦＳ、ＦＴＰ、ＳＭＢ／ＣＩＦＳなどを含む。
【００２７】
１つの実施例において、アーカイブクラスタアプリケーションは、クラスタとして（例えば、イーサネット経由で）ネットワーク化される独立ノード（Ｈ−ＲＡＩＮ）の冗長アレイ上で作動する。所与のノードのハードウェアは異種かもしれない。最大の信頼性のために、しかし、好ましくは、各ノードは、今、図３に示されるようないくつかのランタイムコンポーネントから成る分散アプリケーション（すなわち、同じインスタンス、あるいは本質的に同じインスタンスかもしれない）のインスタンス３００を実行する。従って、ハードウェアは、異種かもしれないが、ノード（少なくともそれが本発明に関係のある）上のソフトウェアスタックは、同じである。これらのソフトウェアコンポーネントは、ゲートウエイプロトコルレイヤ３０２、アクセスレイヤ３０４、ファイルトランザクション及び管理レイヤ３０６、及び、コアコンポーネントレイヤ３０８を有する。機能が他の意味のある方法で特徴づけられるかもしれないことを通常のスキルのうちの１つが認識するので、「レイヤ」指定は、説明目的に提供される。レイヤ（あるいはその点でコンポーネント）の１つ以上は、統合されるかそうでないかもしれない。いくつかのコンポーネントは、レイヤに渡って共有されるかもしれない。
【００２８】
ゲートウエイプロトコルレイヤ３０２の中のゲートウエイプロトコルは、既存のアプリケーションに透明性を提供する。具体的には、ゲートウエイは、カスタムアプリケーションを構築するためのウェブサービスＡＰＩ同様に、ＮＦＳ３１０及びＳＭＢ／ＣＩＦＳ３１２のようなネイティヴファイルサービスを提供する。ＨＴＴＰサポート３１４も提供される。アクセスレイヤ３０４は、アーカイブへのアクセスを提供する。具体的には、発明によれば、固定コンテンツファイルシステム（ＦＣＦＳ）３１６は、アーカイブオブジェクトへフルアクセスを提供するためにネイティヴファイルシステムをエミュレートする。あたかもそれらが通常のファイルかのように、ＦＣＦＳは、アーカイブコンテンツにアプリケーションダイレクトアクセスを与える。好ましくは、メタデータがファイルとして露出されている一方、アーカイブコンテンツは、そのオリジナルフォーマットでレンダリングされる。ＦＣＦＳ３１６は、管理者らが、使いやすい方法で固定コンテンツのデータをセットアップできるように、ディレクトリと許可についての従来のビュー及びルーチンファイルレベルコールを提供する。ファイルアクセス呼び出しは、好ましくは、ユーザスペースデーモンによって傍受され、ダイナミックに呼び出しのアプリケーションへの適切な表示を作成する適切なコアコンポーネント（レイヤ３０８に）に送られる。ＦＣＦＳ呼び出しは、好ましくは、自律的なアーカイブ管理を促進するアーカイブポリシによって抑制される。従って、一例において、管理者かアプリケーションは、保存期間（所与のポリシ）がまだ有効のアーカイブオブジェクトを削除することができない。
【００２９】
アクセスレイヤ３０４は、好ましくは、また、ウェブユーザインターフェース（ＵＩ）３１８及びＳＮＭＰゲートウエイ３２０を含む。ウェブユーザインターフェース３１８は、ファイルトランザクション及び管理レイヤ３０６での管理エンジン３２２への対話型のアクセスを提供する管理者コンソールとして好ましくは実施される。管理上のコンソール３１８は、好ましくは、アーカイブオブジェクト及び個々のノードを含むアーカイブの動的考察を提供するパスワードで保護されウェブベースのＧＵＩである。ＳＮＭＰゲートウエイ３２０は、安全にストレージ管理アプリケーションがクラスターアクティビティを監視し制御することを可能にしながらストレージ管理アプリケーションに管理エンジン３２２への容易なアクセスを提供する。管理エンジンモニタは、システムとポリシイベントを含むアクティビティをクラスタする。ファイルトランザクションと管理レイヤ３０６は、また、要求マネージャプロセス３２４を含む。要求マネージャ３２４は、コアコンポーネントレイヤ３０８の中のポリシマネージャ３２６からの内部要求と同様に外界（アクセスレイヤ３０４を通じて）からの全ての要求を統合する。
【００３０】
コアコンポーネントは、ポリシマネージャ３２６に加えて、メタデータマネージャ３２８及びストレージマネージャ３３０の１つ以上のインスタンスを含む。メタデータマネージャ３２８は、各ノードに好ましくはインストールされる。クラスタ中のメタデータマネージャは、集合的に、全てのアーカイブオブジェクトを管理しながら、分散型データベースとして作動する。所与のノードにおいて、メタデータマネージャ３２８は、好ましくは、アーカイブオブジェクトのサブセットを管理し、各オブジェクトが、好ましくは、外部ファイル（「ＥＦ」（ストレージ用にアーカイブに入ったデータ））とアーカイブデータが物理的に検索される内部ファイル（各々「ＩＦ」）のセット間をマップする。同じメタデータマネージャ３２８は、また、他のノードから複製されたアーカイブオブジェクトのセットを管理する。従って、全ての外部ファイルの現状は、いくつかのノード上の複数メタデータマネージャに常に利用可能である。ノード障害の場合には、他のノード上のメタデータマネージャが、機能不全のノードによって以前管理されたデータへのアクセスを提供し続ける。ストレージマネージャ３３０は、分散アプリケーション中の他の全てのコンポーネントに利用可能なファイルシステムレイヤを提供する。好ましくは、それはノードのローカルファイルシステムにデータオブジェクトを格納する。所与のノード中の各ドライブは、好ましくは、それぞれ自身のストレージマネージャを持っている。これは、ノードが個別のドライブを削除し、処理能力を最適化することを可能にする。ストレージマネージャ３３０は、また、システム情報、データの一貫性チェック及び直接ローカル構造をトラバースする能力を提供する。
【００３１】
さらに図３で示されるように、クラスタは、通信ミドルウェアレイヤ３３２及びＤＮＳマネージャ３３４を通じて内部及び外部通信を管理する。インフラストラクチャ３３２は、アーカイブコンポーネント中の通信を可能にする効率的で信頼できるメッセージベースのミドルウェアレイヤである。図で示した実施例において、レイヤは、マルチキャストとポイントツーポイント通信をサポートする。ＤＮＳマネージャ３３４は、企業サーバに全てのノードを接続する分散型ネームサービスを行う。好ましくは、ＤＮＳマネージャ（単独であるいはＤＮＳサービスと共に）ロードバランスは、最大のクラスタ処理能力及び有効性を保証することを全てのノードに渡って要求する。
【００３２】
図で示した実施例において、ＡｒＣアプリケーションインスタンスは、Red Hat Linux 9.0、Fedora Core 6などのような基礎オペレーティングシステム３３６上で実行する。通信ミドルウェアは、任意の便利な分散型通信メカニズムである。他のコンポーネントは、固定コンテンツファイルシステム（ＦＣＦＳ）３１６のために使用されてもよいＦＵＳＥ（USErspaceの中のファイルシステム）を含むかもしれない。ＮＦＳゲートウエイ３１０は、標準のnfsd LinuxカーネルＮＦＳドライバによって実施されるかもしれない。各ノード中のデータベースは、実施されるかもしれない、例えば、オブジェクト関係データベース管理システム（ＯＲＤＢＭＳ）であるPostgreSQL（またここにPostgresとして引用される）である。ノードは、Java HTTPサーバ及びservletコンテナーであるジェティのようなウェブサーバを含むかもしれない。もちろん、上記のメカニズムは、単に例となる。
【００３３】
所与のノード上のストレージマネージャ３３０は、物理的な記憶デバイスを管理する責任がある。好ましくは、各ストレージマネージャインスタンスは、全てのファイルがその配置アルゴリズムによって入れられる単一のルートディレクトリの責任がある。複数のストレージマネージャインスタンスは、ノード上で同時に作動することができ、各々は、通常、システムで異なる物理的なディスクを表わす。ストレージマネージャは、システムの残りから使用されているドライブ及びインターフェース技術を抽象する。ストレージマネージャインスタンスがファイルを書くように依頼される場合、それはそのために責任を負う表現用のフルパス及びファイル名を生成する。代表的な実施例において、ストレージマネージャ上に格納される各オブジェクトは、それが異なるタイプの情報を追跡するデータを格納する場合、ファイルにそれ自身のメタデータを加えて、そのときストレージマネージャと共に保存されるローデータとして受信される。外部ファイル（ＥＦ）は、クエリエンジンを備えたクエリに続いて必要になる情報を格納する。例として、このメタデータは、限定無しで含む：ＥＦ長さ（バイトでの外部ファイルの長さ）、ＩＦセグメントサイズ（内部ファイルのこの部分のサイズ）、ＥＦ保護表現（ＥＦ保護モード）、ＩＦ保護役割（この内部ファイルの表現）、ＥＦ生成タイムスタンプ（外部ファイルタイムスタンプ）、シグネチャ（シグネチャタイプを含む書き込み（ＰＵＴ）の時間の内部ファイルのシグネチャ）及びＥＦファイル名（外部ファイルファイル名）。内部ファイルデータでこの追加のメタデータを格納することは、追加のレベルの保護を提供することである。具体的には、スカビンジングは、内部ファイルに保存されたメタデータからデータベースに外部ファイルレコードを作成することができる。他のポリシは、内部ファイルが元の状態のままになることを有効にするために内部ファイルに対する内部ファイルハッシュを有効にすることができる。
【００３４】
内部ファイルは、アーカイブオブジェクト中でオリジナルの「ファイル」の一部を表わす、データの「チャンク」かもしれない、また、それらはストライピングと保護ブロックを達成するために異なるノードに置かれるかもしれない。より小さくチャンクされたユニットへの外部ファイルのこの途切れ途切れは、必要不可欠ではないが、代案では、内部ファイルは、外部ファイルの完全なコピーかもしれない。典型的に、１つの外部ファイルエントリは各アーカイブオブジェクトのためのメタデータマネージャの中にあり、その一方で、個々の外部ファイルエントリのための多くの内部ファイルエントリがあるかもしれない。典型的に、内部ファイルレイアウトは、システムに依存する。所与の実施において、ディスク上のこのデータの実際の物理フォーマットは一連の可変長レコードに格納される。
【００３５】
要求マネージャ３２４は、システム内の他のコンポーネントとのやりとりによりアーカイブアクションを行なうために必要とされるオペレーションのセットを実行する責任がある。要求マネージャは、異なるタイプの多くの同時のアクションをサポートし、機能不全のトランザクションをロールバックすることができ、実行するのに長い時間かかるトランザクションをサポートする。要求マネージャは、更に、アーカイブの読取り書き込みオペレーションが適切に扱われる事を保証し、全ての要求がいつでも既知の状態である事を保証する。更に、それは、所与のクライアント要求を満たすためにノードに渡って複数の読取り書き込みオペレーションを調整するためにトランザクション制御を提供する。更に、要求マネージャは、最近使われたファイルのためのメタデータマネージャエントリをキャッシュに格納し、データブロックと同様にセッションのためのバッファリングを提供する。
【００３６】
クラスタの主要な責任は、ディスク上に無制限のファイルを確実に格納することである。それが何らかの理由で手が届かないか、そうでなければ利用不可能かもしれないという意味で、所与のノードは「信頼性が低い」と見なされるかもしれない。そのような潜在的に信頼性の低いノードのコレクションは、確実で、高度に利用可能なストレージを作成することに協力する。一般に、格納される必要のある２つのタイプの情報がある：ファイル自体及びファイルに関するメタデータ。固定コンテンツ分散型データストレージの追加の詳細は、参照によってここに組込まれる米国公開特許第２００７／０１８９１５３号明細書及び第２００６／００２６２１９号明細書で見ることができる。
【００３７】
II. メタデータ管理
【００３８】
メタデータマネジメントシステムは、システムメタデータのような所与のメタデータへのアクセスを組織し提供する責任がある。このシステムメタデータは、構成情報、管理ＵＩに表示された情報、メトリクス、回復不能なポリシ違反についての情報などに表示された情報等と同様にアーカイブに置かれたファイルについての情報を含む。詳細に示されていないが、他のタイプのメタデータ（例えばアーカイブしたファイルに関連したユーザメタデータ）も今説明されるメタデータ管理システムを使用して管理されるかもしれない。
【００３９】
クラスタの代表的な実施例において、メタデータ管理システムは、次のオブジェクトタイプ（それらは単に例となる）の１つ以上を含んでいるかもしれないメタデータオブジェクトのセットのための持続性を提供する。
【００４０】
ExternalFile：アーカイブのユーザによって知覚されるようなファイル。
【００４１】
InternalFile：ストレージマネージャによって格納されたファイル。典型的には、外部ファイルと内部ファイルの間に一対多数の関係があるかもしれない。
【００４２】
ConfigObject：クラスタを構成するのに使われる名前／値ペア。
【００４３】
AdminLogEntry：管理者ＵＩに表示されるメッセージ。
【００４４】
MetricsObject：ある時点でのアーカイブ（例えばファイルの数）のある測定を表わす、タイムスタンプされたキー／値ペア。
【００４５】
PolicyState：あるポリシの違反。
【００４６】
各メタデータオブジェクトは、好ましくは、変わらないユニークな名前を持っているかもしれない。メタデータオブジェクトは、リージョンに組織される。リージョンは、正式なリージョンコピーと「許容障害発生時点」（ＴＰＯＦ）数（０以上のセット）バックアップリージョンコピーから成る。０のコピーで、メタデータマネジメントシステムは、計量可能であるが、高度に利用可能ではないかもしれない。リージョンは、１つ以上のオブジェクト属性（例えばフルパス名やその一部のようなオブジェクトの名前）をハッシュ及びハッシュ値のビットの所与数の抽出により選択される。これらのビットは、リージョン番号から成る。選択されたビットは、低位ビット、高位ビット、中位ビットあるいは個々のビットの任意のコンビネーションかもしれない。代表的な実施例において、所与のビットはハッシュ値の低位ビットである。オブジェクトの属性か属性（複数）は、任意の便利なハッシュ関数を使用してハッシュされるかもしれない。これらは制限なしで、java.lang.string.hashCode等のようなＪａｖａベースのハッシュ関数を含む。 好ましくは、リージョン番号から成るビットの数は、ここでregionMapLevelと呼ばれ、構成パラメータによってコントロールされる。この構成パラメータが６にセットされる場合、例えば、これは２６＝６４リージョンが得られる。もちろん、多くのリージョンは許され、リージョンの数はネームスペース分割スキームを使用して自動的に調節されるかもしれない。
【００４７】
各リージョンは、重複して格納されるかもしれない。上記の通り、リージョンの１つの正式なコピー及び０以上のバックアップコピーがある。前述のように、バックアップコピーの数は、メタデータＴＰＯＦ構成パラメータによってコントロールされる。好ましくは、リージョンコピーは、１つのノード当たりの正式なリージョンコピーの数の平衡を保ち、かつ１つのノード当たりの合計のリージョンコピーの数の平衡を保つようにクラスタの全てのノードに渡って分散される。
【００４８】
メタデータ管理システムは、各ノード上で作動するデータベースにメタデータオブジェクトを格納する。このデータベースは、リージョンマップをサポートするために使用される。典型的なデータベースは、オープンソースとして利用可能であるPostgreSQLを使用して実施される。好ましくは、各リージョンコピーのスキーマがあり、各スキーマでは、各タイプのメタデータオブジェクト用のテーブルがある。スキーマは、単にテーブル、インデックス、手順及び他のデータベースオブジェクトを所有することができるネームスペースである。各リージョンは、好ましくは、それ自身のスキーマを持っている。各スキーマは、テーブル一式、すなわち各メタデータオブジェクトに１つ持っている。これらのテーブルのうちの１つの列は、単一のメタデータオブジェクトに相当する。Postgresが好ましいデータベースであると同時に、任意の便利なリレーショナルデータベース（例えばオラクル、IBM DB/2など）が使用されてもよい。
【００４９】
図４で示されるように、各ノード４００は、プロセスあるいはコンポーネント、すなわち、１つ以上のリージョンマネージャ（ＲＧＭ）４０２ａ−ｎ、メタデータマネージャ（ＭＭ）４０４、少なくとも１つのメタデータマネージャクライアント（ＭＭＣ）４０６、及び１つ以上のスキーマ４１０ａ−ｎがある１つのデータベース４０８、のセットを有する。ＲＧＭ（s）、ＭＭ及びＭＭＣコンポーネントは、Ｊａｖａ仮想マシンのようなバーチャルマシン４１２で実行する。各リージョンコピーにつき１つのＲＧＭがある。従って、正式なリージョンコピー用のＲＧＭ、各バックアップリージョンコピー用のRGM及びそれぞれ不完全なリージョンコピー用のＲＧＭがある。ＲＧＭ４０２のスキーマを管理する各ＲＧＭ４０２用のデータベーススキーマ４１０もある。データベースは、また、リージョンマップ４０５を格納する。各ノードは、好ましくは、同期スキームによって強化されている要求と共に、リージョンマップの同じ全体的な見解を持っている。リージョンマネージャＲＧＭ ４０２は、リージョンコピー（それが正式な、バックアップ、あるいは不完全な場合によっては）上で作動し、メタデータマネージャクライアント４０６、及び他のリージョンマネージャ４０２によって提出された要求の実行に責任がある。要求は、図３で示された通信ミドルウェアあるいは他のメッセージングレイヤのような任意の便利な手段を通じて所与のRGMに提供される。リージョンマネージャは、これらの要求が実行する実行環境を提供する、例えば、スキーマのＲＧＭによって管理されているスキーマ上で作動するように構成されているデータベースへの接続を提供することによって。各リージョンマネージャは、データベース４０８にそのデータを格納する。メタデータマネージャ４０４は、ノード上のメタデータ管理の責任があるトップレベルのコンポーネントである。それは、リージョンマネージャ（ＲＧＭ）を作成し破壊し、そして、ＲＧＭ、例えばクラスタ構成情報、データベース接続のプールによって必要とされるリソースを組織する責任がある。好ましくは、所与のメタデータマネージャ（所与のノード中の）は、リーダーとして働き、どのメタデータマネージャ（ノードのセット又はサブセットに渡った）がどのリージョンコピーに責任を負うかを決める責任がある。賛成アルゴリズム又はその変形のようなリーダー選挙アルゴリズムは、メタデータマネージャリーダーを選ぶために使用されるかもしれない。好ましくは、１つのノード当たり複数のＭＭを実行することは可能であるが、各ノードは、１つのメタデータマネージャを持っている。一旦リージョンオーナー権がネームスペース分割スキーム（下記に述べられるように）によって確立されたならば、各メタデータマネージャは、１つ以上のリージョンマネージャのそのセットに従って調節することに責任がある。システムコンポーネント（例えば管理エンジン、ポリシマネージャなど）は、メタデータマネージャクライアントを通じてメタデータマネージャＭＭとやりとりをする。ＭＭＣは、所与の要求を実行するためにＲＧＭを見つける事、選択されたＲＧＭに要求を出す事、及び選択されたＲＧＭが利用不可能な場合に（例えば、ノードが機能しなくなったので）要求を再試行することに責任がある。後者の場合は、新しいリージョンマップがノードで受信される場合、再試行要求が成功するであろう。
【００５０】
上記の通り、リージョンマップは、各リージョンの各コピーに責任のあるノードを識別する。バーチャルマシン４１２（またその中での各ＲＧＭ、ＭＭ、及びＭＭＣ構成要素）は、リージョンマップ４０５へのアクセスを持っている；リージョンマップのコピー４２０も、それがＪＶＭにコピーされた後、図４に示される。リージョンマップは、従って、所与のノード中のＪＶＭ及びデータベースの両方に利用可能である。このインスタンスとなる実施例において、各メタデータオブジェクトは、0x0と0x3fffffff合計間の整数を産出するためにハッシュされる、つまり３０ビットの値の属性（例えば名前）を持っている。これらの値は、オーバーフロー問題（例えば範囲の高域に１を加える時）にぶち当たる事なく、符号付き３２ビット整数中で快適に表わす事ができる。３０ビットは、大きなクラスタにさえ十分であるおよそ１０億までのリージョンを考慮に入れる。リージョンは、１セットのハッシュ値を表わし、全てのリージョンのセットは、あらゆるハッシュ値をカバーする。各リージョンのための異なるビット位置があり、異なるビット位置は、好ましくは固定順になっている。従って、各リージョンは、ハッシュ値のRegionLevelMapビットの抽出により好ましくは引き出される数によって識別される。６４リージョンを考慮に入れて、構成パラメータが６にセットされる場合、生じるハッシュ値は、0x0から0x3fの数である。
【００５１】
先述の通り、リージョンコピーは、３つの（３）段階、すなわち、「正式な」、「バックアップ」そして「不完全」のうちの１つにある。リージョンコピーが正式のある場合、リージョンへの全ての要求がこのコピーに行き、また、各リージョンにつき１つの正式なコピーがある。リージョンコピーがバックアップである場合、コピーは、バックアップ要求（正式なリージョンマネージャプロセスからの）を受信する。メタデータがロードされているが、コピーがまだ同期されない（典型的に他のバックアップコピーに関して）場合、リージョンコピーは、不完全である。同期が完了するまで、不完全なリージョンコピーは、別の段階への昇進の資格を有さない、すなわち、そのポイントではコピーは、バックアップコピーになる。各リージョンは、１つの正式なコピー、所与の数（メタデータＴＰＯＦ構成パラメータによってセットされた）バックアップあるいは不完全なコピーを持っている。
【００５２】
バックアップリージョンコピーは、正式なリージョンコピーとそのＴＰＯＦバックアップコピー間で所与のプロトコル（あるいは「契約」）を強化することにより、正式なリージョンコピーと同期され続ける。このプロトコルは、今説明される。
【００５３】
簡易バックグラウンド経由で、更新要求がＭＭＣで受信される場合、ＭＭＣは正式なリージョンコピーの位置を見つけるためにローカルのリージョンマップ上の検索を行う。ＭＭＣは、正式なリージョンコピーに関連したＲＧＭに更新要求を送信する、すなわち、その後、それを委託する。更新も、ＴＰＯＦバックアップコピーの各々のＲＧＭに（正式なリージョンコピーに関連したＲＧＭによって）送られる。しかし、正式なＲＧＭは、成功を示すために、更新情報を委託するのにバックアップリージョンコピーに関連した各ＲＧＭを待つ必要はない；むしろ、バックアップリージョンコピーに関連したＲＧＭが更新情報を受信する場合、それは、直ちに確認を返す（正式なＲＧＭに）又は返そうとする。バックアップ要求が受信される場合、そしてそれが実行される前に、この確認が出される。障害が生じない場合、一旦正式なＲＧＭが全ての確認を受信すれば、それは、ＭＭＣに通知する、すなわち、その後、それは、発信者に成功を返す。しかし、所与の故障事象が生じる場合、プロトコルは、影響を与えられたＲＧＭ（バックアップ、あるいは正式な）が、サービスからそれ自身を削除する（また潜在的に影響を受けたノード）事を保証し、新しいリージョンマップは、ＭＭリーダーによって出される。好ましくは、どんな便利な技術が使用されてもよいが、ＲＧＭは、ＪＶＭを下げる事によりサービスからそれ自身を削除する。新しいマップは、失われたリージョンコピーの置換を指定する。このように、各バックアップリージョンコピーは、正式なリージョンコピー用の「ホットスタンバイ」であり、従って、必要ならば及びその場合、（正式なＲＧＭがロードバランシング目的あるいはそのような理由のために機能しなくなるので）正式なに昇格の資格を有する。
【００５４】
更新処理が失敗するいくつかの方法がある。従って、例えば、正式なリージョンマネージャ（確認を待っている間）は、バックアップマネージャプロセスが故障した事を示す例外に遭遇するかもしれない、あるいは、たとえそれが確認を出したとしても、バックアップマネージャプロセスは、更新要求を局所的に処理するのに失敗するかもしれない、あるいは、確認を出す間のバックアップリージョンマネージャプロセスは、正式なリージョンマネージャプロセスが故障した事を示す例外に遭遇するかもしれない等など。上記の通り、所与のバックアップRGMが更新情報を処理することができない場合、それは、サービスから自身を削除する。更に、バックアップRGMあるいは正式なRGMのいずれかが故障する場合、新しいリージョンマップが出される。
【００５５】
メタデータマネジメントシステムは、リージョンのコピーを同期した状態に保つ。正式なリージョンコピーでのオブジェクトに終っている更新情報は、バックアップリージョンコピー上で複製される。一旦、更新情報が正式なRGMによって委託されれば、同じ更新情報は、全てのバックアップリージョンコピーに適用される。メタデータマネジメントシステムは、どんなそのような障害（ノードレベル、リージョンマネージャレベルまたは同様なもの）も障害したノード上のリージョンコピーの配置転換を引き起こす事を保証する；従って、残るリージョンコピーのインテグリティが保証される。正式なRGMを含んでいるノードが障害する場合、バックアップRGMは、同期している状態（現在実行する更新情報の有無に関わらず）あるいは、それらは、中断された更新情報によるのみ同期していない状態である。後者の場合は、再度同期させる事が容易である。バックアップリージョンが、正式なリージョンと同期され続けるので、昇格（バックアップから正式なまで）は瞬間的である。
【００５６】
ノード障害は、また、バックアップリージョンを失うであろう。バックアップリージョンは、他のあるノード、すなわち、新しく不完全なリージョン上で作成することにより復元される。不完全なリージョンが作られるとすぐに、それは、更新情報を記録し始め、正式なリージョンからデータをコピーし始める。複製が完了すると、最新のバックアップをもたらせながら蓄積された更新情報が適用される。その後、新しいバックアップリージョンは、それが最新であるとＭＭリーダーに通知する、すなわち、ＭＭリーダーにリージョン（不完全なからバックアップまで）の昇格を含むマップを送信させる。
【００５７】
注目すべきは、リージョンの数がノードの数に相当するという要求がない事である。より一般に、リージョンの数は、独立ノードのアレイのノードの数に関連しない。メタデータ管理の追加の詳細は、米国公開特許第２００６／００２６２１９号明細書で見ることができる。
【００５８】
III. ノードによってクエリ結果を集めること
【００５９】
発明の典型的な実施例は、ＲＥＳＴ（Representational State Transfer）クライアントが所与の基準のためのオブジェクトとシステムメタデータとのリストを検索するためにディレクトリ、サブディレクトリ、サブサブディレクトリ等をトラバースするために統合するアプリケーションの必要無しに所与の基準と一致するオブジェクトのリスト及びメタデータ用のコンテンツプラットフォームにクエリを行うことを可能にする。この発明の特徴は、クライアントアプリケーションが、変更時間によるクエリ、ディレクトリによるクエリ、トランザクション（作成、削除、パージ）によるクエリ、ネームスペースによるクエリ、及び、結果を通じてのページ等を行う能力を含む。単一のコンテンツプラットフォームノードは、コンテンツプラットフォームシステムでの全てのノードに渡って全てのリージョンにクエリを分散し、同じノードは、クライアントアプリケーションにリストを返す前に結果をソートする。特定の実施例によると、データベースクエリは、メタデータマネージャの中で実施される。
【００６０】
「変更時間」は、オブジェクト（コンテンツプラットフォームシステムでのコンテンツが読取り専用であるので、特に、そのメタデータ）が、ユーザによって最後に修正された時間である。例えば、時間は、１９７０年１月１日以来ミリセカンドの数で計られる。「ディレクトリによるクエリ」は、同じファイルシステムディレクトリに論理上存在する、コンテンツプラットフォームシステムでの全てのオブジェクトを検索する行為である。コンテンツプラットフォームシステムは、そのデータベースに対するSQLクエリの実行によりこれを遂行する。「トランザクションによるクエリ」は、最近のアクセスがあるタイプのオペレーションによったコンテンツプラットフォームシステムでの全てのオブジェクトを検索する行為である。例えば、それは、最近の活動がそれらの生成であった全てのオブジェクト、あるいは、最近削除された全てのオブジェクトを返すことができるかもしれない。「ネームスペースによるクエリ」は、全てのオブジェクト、そして、特定のコンテンツプラットフォームシステムネームスペースの中のそれらのオブジェクトだけを検索する行為である。「結果を通じてのページ」は、個々のオブジェクト中ではなく、セット中のクエリの結果セットとやりとりを行う行為である。例えば、クエリは、１０００のオブジェクトによって満たされるかもしれない。従来の相互作用において、クライアントは、１０００の相互作用を要求して、ひとつずつそれらのオブジェクトを検索し検査するであろう。 ページングスキームにおいて、それらは、結果をトラバースするのに必要な相互作用の数を減らす５０、１００あるいは他のある数のバッチ中のクライアントに返される。
【００６１】
III.A. クエリ定義
【００６２】
図５は、単一ノード５１０によって全ての他ノード５１２、５１４、５１６へクライアントアプリケーション５０２からクエリを分散することを示すコンテンツプラットフォーム５００の簡略化したブロック図である。その後、クエリの結果は、それらがHTTPクライアントアプリケーション５０２に返される前に、フィルタされソートされる。コンテンツプラットフォーム５００は、ネットワーク化された独立ノードの冗長アレイを含む。クエリの基準に適合したオブジェクトを見つけることによりクエリの結果を提供するために、クエリは、各ノード中で処理される。クエリ結果をフィルタすることは、結果セット内でＲＥＳＴクライアントによる基準又は所与の基準に一致する結果だけを含むことを意味する。オブジェクトは、オペレーションタイプ（つまり、「作成された」「削除された」「変更されたメタデータ」等）によってフィルタされる。例えば、クライアントが単にトランザクション=レコード作成を見ることを望む場合、呼び出された全てのレコード及びトランザクション=作成に一致するレコードだけが含まれる。
【００６３】
ステップ１において、アプリケーション５０２は、ノード５１０を分散するクエリである第１のノード又は主要なノードへのクエリを送る。ステップ２において、第１のノード５１０は、アプリケーション５０２から受信した要求に基づいて、コンテンツプラットフォーム５００内の他のノード５１２、５１４、５１６の各々へクエリを出す。ステップ３において、コンテンツプラットフォーム５００内の各ノードは、ノード内の正式なリージョンを全てクエリし始め、セット中の結果を提供する。ステップ４において、第１のノード５１０は、連続的に検索し、統合し、全てのノードからの結果をフィルタしソートする。ステップ５において、第１のノード５１０は、アプリケーション５０２に結果のセットを返す。ステップ６において、アプリケーション５０２は、第１のノード５１０へ結果の次のセットの要求を出すかもしれない、そして上記のステップ２−５が繰り返される。各リージョンは、好ましくは、データベースインデックスの使用を通じてオブジェクト変更時間上のクエリを扱うために最適化されたデータベースにマッピングする。
【００６４】
図６は、全て他のノードに第１のノード５１０によるクライアントアプリケーション５０２からのクエリを分散し、クライアントアプリケーション５０２へのクエリの結果を統合し、返す過程を示すフロー図の例である。この例において、クエリは、供給されたＵＵＩＤ（Universal Unique Identifier）、ディレクトリパス及びchange_timesの中の１００のオブジェクトを選択する。クエリによって作られた順序付けは、（uuid、change_time、fn_hash）である。
【００６５】
ステップ６０２で、クライアントアプリケーション５０２は、ある基準を満たすオブジェクトのリストを要求する。ステップ６０４において、要求を受信する第１のノード５１０は、全ての他ノードにクエリを出す。ステップ６０６において、各ノードは、そのノードにおけるリージョンについてのクエリを始める。ステップ６０８で、各ノードは、ノード上の各リージョンにつき最初の１００の結果を検索する。ステップ６１０において、第１のノード５１０は、全てのノードから結果の最初のセットを検索する。ステップ６１２において、第１のノードは、結果を統合し、フィルタし、ソートする（クライアントアプリケーション５０２が次のセットの結果を要求することをやめるまで、これは連続的に行われる）。ステップ６１４において、第１のノード５１０は、クライアントアプリケーション５０２に結果を返す。ステップ６１６において、クライアントアプリケーションは、完了（クライアントアプリケーション５０２が次のセットの結果を要求することをやめるまで、これは行われる）まで結果を受信する。ステップ６１８において、クライアントアプリケーション５０２は、結果の次のセットの要求を第１のノード５０２に送信する。ステップ６２０において、第１のノード５０２は、完了（クライアントアプリケーション５０２が次のセットの結果を要求することをやめるまで、これは行われる）まで全てのノードから統合され、フィルタされ、ソートされた追加の結果を要求する。
【００６６】
クエリ結果（つまりクエリを出し、処理し、クエリの結果を統合し、フィルタする）を管理するプロセスは、クエリ結果管理モジュール中で実行されるかもしれない。特定な実施例において、クエリ結果管理モジュールは、コンテンツプラットフォームの各ノード中のメタデータマネージャの中で提供される。
【００６７】
III.B. CPExternalFileQueryRequest
【００６８】
CPExternalFileQueryRequestは、メタデータマネージャクライアントから特定な正式なリージョン番号への要求である。その要求は、QueryParametersに適合するexternal_fileテーブルから１バッチを返す。CPExternalFileQueryRequestは、前のセクションで説明されたそれと同じクエリを起動するであろう。上記の通り、クエリは、（uuid、change_time、fn_hash）によって指図される。バッチを返す前に、リストはこの正確な順序付けを生じさせるためにさらにソートされる（メモリ内で）：
（uuid、change_time、fn_hash、ディレクトリ、file_name、version_id）。
結果の次のセット／バッチを要求するために第１のノード５１０と他のノード間の通信を提供するために、この特徴は、ソフトウェアモジュールとして実施されるかもしれない。「uuid」は、オブジェクトのためのユニバーサルユニーク識別子である。この場合、それは、オブジェクトが存在するネームスペースを識別する。「change_time」は、レコードが最後に修正された日付及び時間を反映する。「fn_hash」は、ネームスペース中のオブジェクトの名前にハッシュ関数を適用する結果を表わし、オブジェクトの識別のために省略表現として使用される。米国公開特許第２００６／００２６２１９号明細書を参照。「version_id」は、ネームスペース中のオブジェクトの特別なバージョンのためのユニーク識別子である。
【００６９】
III.C. RemoteQueryBatchIterator
【００７０】
RemoteQueryBatchIteratorは、バッチを検索するCPExternalFileQueryRequestメッセージを送るBatchIteratorの単純拡大である。これは、通常、局所リージョンにクエリを行うBatchIteratorの典型的な実施とほんの少し異なる。クエリエンジンは、特定なリージョン番号及び生成上のマップサイズに結合する。第１のノード５１０がクライアントアプリケーション５０２からある基準を備えたオブジェクトのリストの要求を受信する場合、第１のノード５１０から他のノードにクエリを出すために、この特徴は、ソフトウェアモジュールとして実施されるかもしれない。
【００７１】
III.D. ExternalFileQuery
【００７２】
ExternalFileQueryクラスは、システムでクエリエンジンの全てに渡って統合するMetadataManagerClient.Operationインプリメンテーションである。RemoteQueryBatchIteratorから返された各クエリエンジンが厳密に指図されるので、PriorityQueueIteratorは、これらのクエリエンジンに渡って効率的に統合することができる。結果として生じるクエリは、全てのリージョンに渡って正確に指図される。返されたクエリは、タイプMetadataIterator<ExternalFile>になるであろう。全てのノードから第１のノード５０２によって集められた結果を統合し、フィルタするために、この特徴はソフトウェアモジュールとして実施されるかもしれない。
【００７３】
全てのリージョンに渡って統合するためのアルゴリズムは、かなり簡単である：（１）giveノード中の全てのリージョンを処理する、（２）RemoteQueryBatchIterator（リージョン、QueryParameters）を作成する、（３）PriorityQueueIterator（収集<RemoteQueryBatchIterator>iterators、QueryKeyExtractor）を作成する、そして（４）リターンPriorityQueueIteratorを返す。
【００７４】
発明の特定の実施例によると、上記のクエリ結果を統合するための技術は、検索エンジン、バックアップサーバ、ポリシエンジン、RBSを使用するアプリケーション、XAMを使用するアプリケーション又は同種のものを備えたコンテンツプラットフォーム統合のサポートを提供するのを助けるメタデータクエリエンジンの一部である。
【００７５】
もちろん、図１及び５に示されたシステム構成は、本発明が実行されるかもしれないストレージアーカイブの純粋な模範例であり、発明は、特定なハードウェア構成に制限されない。発明を実行するコンピュータとストレージシステムは、また、上記発明を実行するために使用されるモジュール、プログラム及びデータ構造を格納し読む事ができるI/Oデバイス（例えばCD及びDVDドライブ、フロッピーディスクドライブ、ハードドライブなど）として知られてきた。これらのモジュール、プログラム及びデータ構造は、そのようなコンピュータが読めるメディア上でエンコードすることができる。例えば、発明のデータ構造は、発明に使われるプログラムが存在する１以上のコンピュータが読めるメディア上に単独で格納することができる。システムのコンポーネントは、任意の形式あるいはデジタルデータ通信、例えば通信ネットワークのメディアによって相互連結することができる。通信ネットワークの例は、ローカルエリアネットワーク、広域ネットワーク、例えばインターネット、ワイヤレスネットワーク、ストレージエリアネットワークそして同種のものを含む。
【００７６】
説明において、多数の詳細が本発明についての完全な理解を提供するために説明の目的のために述べられる。しかし、これらの特定な詳細の全てが本発明を実行するために必要だとは限らないという事が当業者には明らかである。発明がプロセス、すなわち、フローチャート、フロー図、構造図あるいはブロック図として通常描かれると説明されるかもしれない事がさらに注目される。フローチャートは、オペレーションを連続するプロセスと説明するかもしれないが、オペレーションの多くは、並行してあるいは同時に行なう事ができる。更に、オペレーションの順序は並べ替えられるかもしれない。
【００７７】
当技術で知られているように、上記のオペレーションは、ハードウェア、ソフトウェアあるいはソフトウェアとハードウェアのあるコンビネーションによって行なう事ができる。もしプロセッサによって実行されれば、プロセッサに発明の実施例を実行する方法を行なわせるだろう機械可読媒体（ソフトウェア）上に格納された指示を使用して、他の態様が実施されるかもしれない一方、発明の実施例の種々態様は、回路及び論理回路（ハードウェア）を使用して、実施されるかもしれない。更に、他の実施例は、唯一ソフトウェア内で行なわれるかもしれないが、発明のいくつかの実施例は、唯一ハードウェア内で行なわれるかもしれない。更に、説明された様々な機能は、単一のユニットで行なう事ができるか、あらゆる方法を用いて多くのコンポーネントに広げる事ができる。ソフトウェアによって行なわれた場合、その方法は、汎用計算機のようなコンピュータが読めるミディアム上に格納された指示に基づいたプロセッサによって実行されるかもしれない。もし望まれれば、指示は、圧縮されかつまたは暗号化された、フォーマットでミディアム上に格納することができる。
【００７８】
前述から、発明がフォールトトレラントデータベース管理システムでクエリ結果を統合するためにコンピュータ読取り可能な記憶媒体上に格納された方法、装置及びプログラムを提供することは明白であろう。更に、特定な実施例がこの明細書に示され、説明されてきた一方、当事者達は、同じ目的を達成すると計算されるいかなる配置が、公開された特定な実施例の代わりに用いられるかもしれない事を認識している。この開示は、本発明のありとあらゆる適応あるいは変化をカバーするように意図され、下記の請求項の中で使用される用語が、発明を明細書に公開された特定な実施例に制限するために解釈されるべきでない事が、理解される事になっている。正しくは、発明の範囲は、そのような請求項が与えられる同等物の全範囲に加えて請求項解釈の確立した主義に従って解釈される事になっている下記の請求項によって完全に決定される事になっている。
Claims (15)
- 基準を満たしたコンテンツデータ及び/又はメタデータの情報を要求する第１クエリを受信する第１ノードを含んだ複数のノードを有し、複数のコンテンツデータと、前記複数のコンテンツデータに対応する複数のメタデータと複数のバックアップメタデータと、を格納し、前記複数のノードの各々が、前記複数のメタデータに含まれる１以上のメタデータを格納する第１リージョンと、前記複数のバックアップメタデータに含まれる１以上のバックアップメタデータを格納する第２リージョンとを管理する、ストレージシステム、における管理方法であって、
前記第１ノードは、前記複数のノードのうちの前記第１ノード以外の１以上のノードである１以上の第２ノードの各々へ、前記第１クエリに基づき第２クエリを発行し、
各第２ノードは、前記第２クエリに基づき、その第２ノードが管理する第１リージョン内の１以上のメタデータをサーチして、前記基準を満たしたコンテンツデータ及び/又はメタデータを検索し、
前記第１ノードは、前記サーチの結果を統合する、
ことを特徴とする方法。 - 前記第１ノードは、前記統合された結果を、コンテンツデータ及び/又はメタデータへの操作タイプによりフィルタする、
ことを特徴とする請求項１に記載の方法。 - 前記各第２ノードが、サーチの結果を前記第１ノードに提供し、
前記第１ノードは、前記第１ノードが管理する第１リージョン内の１以上のメタデータをサーチして、基準を満たしたコンテンツデータ及び/又はメタデータを検索し、
前記第１ノードが、前記提供されたサーチの結果と、前記第１ノードによるサーチの結果を統合する、
ことを特徴とする請求項１に記載の方法。 - 前記基準は、少なくとも、コンテンツデータ及び/又はメタデータが最後に更新された期間、コンテンツデータ及び/又はメタデータが格納されるディレクトリ、コンテンツデータ及び/又はメタデータが格納される名前空間、のいずれかを指定する、
ことを特徴とする請求項１乃至３のうちのいずれか１項に記載の方法。 - 前記各第２ノードは、各々が管理する前記第２リージョン内の前記１以上のバックアップメタデータをサーチしない、
ことを特徴とする請求項１に記載の方法。 - 複数のコンテンツデータと、前記複数のコンテンツデータに対応する複数のメタデータと複数のバックアップメタデータと、を格納するストレージシステムであって、
基準を満たしたコンテンツデータ及び/又はメタデータの情報を要求する第１クエリを受信する第１ノードを含み、各々、前記複数のメタデータに含まれる１以上のメタデータを格納する第１リージョンと、前記複数のバックアップメタデータに含まれる１以上のバックアップメタデータを格納する第２リージョンと、を管理する複数のノードを有し、
前記第１ノードは、前記第１クエリに基づき前記複数のノードのうちの前記第１ノード以外の１以上のノードである１以上の第２ノードの各々に第２クエリを発行し、
各第２ノードは、前記第２クエリに基づき、その第２ノードが管理する第１リージョン内の１以上のメタデータをサーチして、前記基準を満たしたコンテンツデータ及び/又はメタデータを検索し、
前記第１ノードは、前記サーチの結果を統合する、
ことを特徴とするストレージシステム。 - 前記第１ノードは、前記統合された結果を、コンテンツデータ及び/又はメタデータへの操作タイプによりフィルタする、
ことを特徴とする請求項６に記載のストレージシステム。 - 前記各第２ノードが、サーチの結果を前記第１ノードに提供し、
前記第１ノードは、前記第１ノードが管理する第１リージョン内の１以上のメタデータをサーチして、前記基準を満たしたコンテンツデータ及び/又はメタデータを検索し、
前記第１ノードが、前記提供されたサーチの結果と、前記第１ノードによるサーチの結果を統合する、
ことを特徴とする請求項６に記載のストレージシステム。 - 前記基準は、少なくとも、コンテンツデータ及び/又はメタデータが最後に更新された期間、コンテンツデータ及び/又はメタデータが格納されるディレクトリ、コンテンツデータ及び/又はメタデータが格納される名前空間、のいずれかを指定する、
ことを特徴とする請求項６乃至８のうちのいずれか１項に記載のストレージシステム。 - 前記各第２ノードは、各々が管理する前記第２リージョン内の前記１以上のバックアップメタデータをサーチしない、
ことを特徴とする請求項７に記載のストレージシステム。 - 基準を満たしたコンテンツデータ及び/又はメタデータの情報を要求する第１クエリを受信する第１ノードを含んだ複数のノードを有し、複数のコンテンツデータと、前記複数のコンテンツデータに対応する複数のメタデータと複数のバックアップメタデータと、を格納し、前記複数のノードの各々が、前記複数のメタデータに含まれる１以上のメタデータを格納する第１リージョンと、前記複数のバックアップメタデータに含まれる１以上のバックアップメタデータを格納する第２リージョンとを管理する、ストレージシステム、における、前記第１ノードとしてコンピュータを実行させるコンピュータプログラムであって、
前記複数のノードのうちの前記第１ノード以外の１以上のノードである１以上の第２ノードの各々へ、前記第１クエリに基づき第２クエリを発行し、各第２ノードが、前記第２クエリに基づき、その第２ノードが管理する第１リージョン内の１以上のメタデータをサーチして、前記基準を満たしたコンテンツデータ及び/又はメタデータを検索するようになっており、
前記サーチの結果を統合する、
ことをコンピュータに実行させることを特徴とするコンピュータプログラム。 - 前記統合された結果を、コンテンツデータ及び/又はメタデータへの操作タイプによりフィルタする、
ことをコンピュータに実行させることを特徴とする請求項１１に記載のコンピュータプログラム。 - 前記各第２ノードから、サーチの結果を受信し、
前記第１ノードが管理する第１リージョン内の１以上のメタデータをサーチして、基準を満たしたコンテンツデータ及び/又はメタデータを検索し、
そのサーチの結果と、前記受信したサーチの結果とを統合する、
ことをコンピュータに実行させることを特徴とする請求項１１に記載のコンピュータプログラム。 - 前記基準は、少なくとも、コンテンツデータ及び/又はメタデータが最後に更新された期間、コンテンツデータ及び/又はメタデータが格納されるディレクトリ、コンテンツデータ及び/又はメタデータが格納される名前空間、のいずれかを指定する、
ことを特徴とする請求項１１乃至１３のうちのいずれか１項に記載のコンピュータプログラム。 - 前記各第２ノードは、各々が管理する前記第２リージョン内の前記１以上のバックアップメタデータをサーチしない、
ことを特徴とする請求項１１に記載のコンピュータプログラム。
Applications Claiming Priority (3)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| US12/889,574 US8838624B2 (en) | 2010-09-24 | 2010-09-24 | System and method for aggregating query results in a fault-tolerant database management system |
| US12/889,574 | 2010-09-24 | ||
| PCT/US2011/051319 WO2012039992A1 (en) | 2010-09-24 | 2011-09-13 | System and method for aggregating query results in a fault-tolerant database management system |
Publications (3)
| Publication Number | Publication Date |
|---|---|
| JP2013545162A JP2013545162A (ja) | 2013-12-19 |
| JP2013545162A5 true JP2013545162A5 (ja) | 2014-10-30 |
| JP5918244B2 JP5918244B2 (ja) | 2016-05-18 |
Family
ID=45871682
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| JP2013530184A Active JP5918244B2 (ja) | 2010-09-24 | 2011-09-13 | フォールトトレラントデータベース管理システムにおいてクエリ結果を統合するシステム及び方法 |
Country Status (5)
| Country | Link |
|---|---|
| US (3) | US8838624B2 (ja) |
| EP (1) | EP2619696A4 (ja) |
| JP (1) | JP5918244B2 (ja) |
| CN (1) | CN103109292B (ja) |
| WO (1) | WO2012039992A1 (ja) |
Families Citing this family (101)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US8484162B2 (en) | 2008-06-24 | 2013-07-09 | Commvault Systems, Inc. | De-duplication systems and methods for application-specific data |
| US8930306B1 (en) | 2009-07-08 | 2015-01-06 | Commvault Systems, Inc. | Synchronized data deduplication |
| US11449394B2 (en) | 2010-06-04 | 2022-09-20 | Commvault Systems, Inc. | Failover systems and methods for performing backup operations, including heterogeneous indexing and load balancing of backup and indexing resources |
| US9449007B1 (en) * | 2010-06-29 | 2016-09-20 | Emc Corporation | Controlling access to XAM metadata |
| US8578109B2 (en) | 2010-09-30 | 2013-11-05 | Commvault Systems, Inc. | Systems and methods for retaining and using data block signatures in data protection operations |
| US8577851B2 (en) | 2010-09-30 | 2013-11-05 | Commvault Systems, Inc. | Content aligned block-based deduplication |
| US9020900B2 (en) | 2010-12-14 | 2015-04-28 | Commvault Systems, Inc. | Distributed deduplicated storage system |
| US9104623B2 (en) | 2010-12-14 | 2015-08-11 | Commvault Systems, Inc. | Client-side repository in a networked deduplicated storage system |
| US8775486B2 (en) | 2011-04-04 | 2014-07-08 | Symantec Corporation | Global indexing within an enterprise object store file system |
| US9262449B2 (en) | 2012-03-08 | 2016-02-16 | Commvault Systems, Inc. | Automated, tiered data retention |
| US20130339310A1 (en) | 2012-06-13 | 2013-12-19 | Commvault Systems, Inc. | Restore using a client side signature repository in a networked storage system |
| US10042907B2 (en) * | 2012-11-29 | 2018-08-07 | Teradata Us, Inc. | Providing metadata to database systems and environments with multiple processing units or modules |
| US20140181438A1 (en) * | 2012-12-21 | 2014-06-26 | Commvault Systems, Inc. | Filtered reference copy of secondary storage data in a data storage system |
| US9633033B2 (en) | 2013-01-11 | 2017-04-25 | Commvault Systems, Inc. | High availability distributed deduplicated storage system |
| US9633056B2 (en) | 2014-03-17 | 2017-04-25 | Commvault Systems, Inc. | Maintaining a deduplication database |
| US10380072B2 (en) | 2014-03-17 | 2019-08-13 | Commvault Systems, Inc. | Managing deletions from a deduplication database |
| US9811427B2 (en) | 2014-04-02 | 2017-11-07 | Commvault Systems, Inc. | Information management by a media agent in the absence of communications with a storage manager |
| US9852026B2 (en) | 2014-08-06 | 2017-12-26 | Commvault Systems, Inc. | Efficient application recovery in an information management system based on a pseudo-storage-device driver |
| US11249858B2 (en) | 2014-08-06 | 2022-02-15 | Commvault Systems, Inc. | Point-in-time backups of a production application made accessible over fibre channel and/or ISCSI as data sources to a remote application by representing the backups as pseudo-disks operating apart from the production application and its host |
| US10459927B1 (en) | 2014-08-15 | 2019-10-29 | Groupon, Inc. | Enforcing diversity in ranked relevance results returned from a universal relevance service framework |
| US11216843B1 (en) | 2014-08-15 | 2022-01-04 | Groupon, Inc. | Ranked relevance results using multi-feature scoring returned from a universal relevance service framework |
| US9747331B2 (en) * | 2014-10-06 | 2017-08-29 | International Business Machines Corporation | Limiting scans of loosely ordered and/or grouped relations in a database |
| US9575673B2 (en) | 2014-10-29 | 2017-02-21 | Commvault Systems, Inc. | Accessing a file system using tiered deduplication |
| US11294893B2 (en) * | 2015-03-20 | 2022-04-05 | Pure Storage, Inc. | Aggregation of queries |
| US10339106B2 (en) | 2015-04-09 | 2019-07-02 | Commvault Systems, Inc. | Highly reusable deduplication database after disaster recovery |
| US20160350391A1 (en) | 2015-05-26 | 2016-12-01 | Commvault Systems, Inc. | Replication using deduplicated secondary copy data |
| US9880880B2 (en) * | 2015-06-26 | 2018-01-30 | Amazon Technologies, Inc. | Automatic scaling of computing resources using aggregated metrics |
| WO2016210332A1 (en) * | 2015-06-26 | 2016-12-29 | Amazon Technologies, Inc. | Datastore for aggregated measurements for metrics |
| US9882830B2 (en) * | 2015-06-26 | 2018-01-30 | Amazon Technologies, Inc. | Architecture for metrics aggregation without service partitioning |
| US10599662B2 (en) * | 2015-06-26 | 2020-03-24 | Mcafee, Llc | Query engine for remote endpoint information retrieval |
| US9882982B2 (en) * | 2015-06-26 | 2018-01-30 | Amazon Technologies, Inc. | Datastore for aggregated measurements for metrics |
| US9880919B2 (en) * | 2015-06-26 | 2018-01-30 | Amazon Technologies, Inc. | Aggregation of metrics data with fine granularity |
| US9910755B2 (en) | 2015-06-26 | 2018-03-06 | Amazon Technologies, Inc. | Retrieval of authoritative measurement data from in-memory datastores |
| US9766825B2 (en) | 2015-07-22 | 2017-09-19 | Commvault Systems, Inc. | Browse and restore for block-level backups |
| US10061663B2 (en) | 2015-12-30 | 2018-08-28 | Commvault Systems, Inc. | Rebuilding deduplication data in a distributed deduplication data storage system |
| US11442945B1 (en) | 2015-12-31 | 2022-09-13 | Groupon, Inc. | Dynamic freshness for relevance rankings |
| US10296368B2 (en) | 2016-03-09 | 2019-05-21 | Commvault Systems, Inc. | Hypervisor-independent block-level live browse for access to backed up virtual machine (VM) data and hypervisor-free file-level recovery (block-level pseudo-mount) |
| US11249970B2 (en) * | 2016-05-05 | 2022-02-15 | Mastercard International Incorporated | Method and system for distributed data storage with eternal integrity guarantees |
| US11243963B2 (en) | 2016-09-26 | 2022-02-08 | Splunk Inc. | Distributing partial results to worker nodes from an external data system |
| US11232100B2 (en) | 2016-09-26 | 2022-01-25 | Splunk Inc. | Resource allocation for multiple datasets |
| US11442935B2 (en) | 2016-09-26 | 2022-09-13 | Splunk Inc. | Determining a record generation estimate of a processing task |
| US11023463B2 (en) | 2016-09-26 | 2021-06-01 | Splunk Inc. | Converting and modifying a subquery for an external data system |
| US11294941B1 (en) | 2016-09-26 | 2022-04-05 | Splunk Inc. | Message-based data ingestion to a data intake and query system |
| US10956415B2 (en) | 2016-09-26 | 2021-03-23 | Splunk Inc. | Generating a subquery for an external data system using a configuration file |
| US11250056B1 (en) | 2016-09-26 | 2022-02-15 | Splunk Inc. | Updating a location marker of an ingestion buffer based on storing buckets in a shared storage system |
| US11461334B2 (en) | 2016-09-26 | 2022-10-04 | Splunk Inc. | Data conditioning for dataset destination |
| US11314753B2 (en) * | 2016-09-26 | 2022-04-26 | Splunk Inc. | Execution of a query received from a data intake and query system |
| US11615104B2 (en) | 2016-09-26 | 2023-03-28 | Splunk Inc. | Subquery generation based on a data ingest estimate of an external data system |
| US11593377B2 (en) | 2016-09-26 | 2023-02-28 | Splunk Inc. | Assigning processing tasks in a data intake and query system |
| US11222066B1 (en) | 2016-09-26 | 2022-01-11 | Splunk Inc. | Processing data using containerized state-free indexing nodes in a containerized scalable environment |
| US20180089324A1 (en) | 2016-09-26 | 2018-03-29 | Splunk Inc. | Dynamic resource allocation for real-time search |
| US11269939B1 (en) | 2016-09-26 | 2022-03-08 | Splunk Inc. | Iterative message-based data processing including streaming analytics |
| US11663227B2 (en) | 2016-09-26 | 2023-05-30 | Splunk Inc. | Generating a subquery for a distinct data intake and query system |
| US11126632B2 (en) | 2016-09-26 | 2021-09-21 | Splunk Inc. | Subquery generation based on search configuration data from an external data system |
| US11586627B2 (en) | 2016-09-26 | 2023-02-21 | Splunk Inc. | Partitioning and reducing records at ingest of a worker node |
| US11567993B1 (en) | 2016-09-26 | 2023-01-31 | Splunk Inc. | Copying buckets from a remote shared storage system to memory associated with a search node for query execution |
| US11874691B1 (en) | 2016-09-26 | 2024-01-16 | Splunk Inc. | Managing efficient query execution including mapping of buckets to search nodes |
| US11562023B1 (en) | 2016-09-26 | 2023-01-24 | Splunk Inc. | Merging buckets in a data intake and query system |
| US11604795B2 (en) | 2016-09-26 | 2023-03-14 | Splunk Inc. | Distributing partial results from an external data system between worker nodes |
| US11281706B2 (en) | 2016-09-26 | 2022-03-22 | Splunk Inc. | Multi-layer partition allocation for query execution |
| US11416528B2 (en) | 2016-09-26 | 2022-08-16 | Splunk Inc. | Query acceleration data store |
| US10977260B2 (en) | 2016-09-26 | 2021-04-13 | Splunk Inc. | Task distribution in an execution node of a distributed execution environment |
| US12013895B2 (en) | 2016-09-26 | 2024-06-18 | Splunk Inc. | Processing data using containerized nodes in a containerized scalable environment |
| US11580107B2 (en) | 2016-09-26 | 2023-02-14 | Splunk Inc. | Bucket data distribution for exporting data to worker nodes |
| US10353965B2 (en) | 2016-09-26 | 2019-07-16 | Splunk Inc. | Data fabric service system architecture |
| US11321321B2 (en) | 2016-09-26 | 2022-05-03 | Splunk Inc. | Record expansion and reduction based on a processing task in a data intake and query system |
| US11003714B1 (en) | 2016-09-26 | 2021-05-11 | Splunk Inc. | Search node and bucket identification using a search node catalog and a data store catalog |
| US11860940B1 (en) | 2016-09-26 | 2024-01-02 | Splunk Inc. | Identifying buckets for query execution using a catalog of buckets |
| US10984044B1 (en) | 2016-09-26 | 2021-04-20 | Splunk Inc. | Identifying buckets for query execution using a catalog of buckets stored in a remote shared storage system |
| US11599541B2 (en) | 2016-09-26 | 2023-03-07 | Splunk Inc. | Determining records generated by a processing task of a query |
| US11550847B1 (en) | 2016-09-26 | 2023-01-10 | Splunk Inc. | Hashing bucket identifiers to identify search nodes for efficient query execution |
| US11620336B1 (en) | 2016-09-26 | 2023-04-04 | Splunk Inc. | Managing and storing buckets to a remote shared storage system based on a collective bucket size |
| US11106734B1 (en) | 2016-09-26 | 2021-08-31 | Splunk Inc. | Query execution using containerized state-free search nodes in a containerized scalable environment |
| US11163758B2 (en) | 2016-09-26 | 2021-11-02 | Splunk Inc. | External dataset capability compensation |
| US10417102B2 (en) | 2016-09-30 | 2019-09-17 | Commvault Systems, Inc. | Heartbeat monitoring of virtual machines for initiating failover operations in a data storage management system, including virtual machine distribution logic |
| US10740193B2 (en) | 2017-02-27 | 2020-08-11 | Commvault Systems, Inc. | Hypervisor-independent reference copies of virtual machine payload data based on block-level pseudo-mount |
| US10664352B2 (en) | 2017-06-14 | 2020-05-26 | Commvault Systems, Inc. | Live browsing of backed up data residing on cloned disks |
| US11989194B2 (en) | 2017-07-31 | 2024-05-21 | Splunk Inc. | Addressing memory limits for partition tracking among worker nodes |
| US11921672B2 (en) | 2017-07-31 | 2024-03-05 | Splunk Inc. | Query execution at a remote heterogeneous data store of a data fabric service |
| US10896182B2 (en) | 2017-09-25 | 2021-01-19 | Splunk Inc. | Multi-partitioning determination for combination operations |
| US11151137B2 (en) | 2017-09-25 | 2021-10-19 | Splunk Inc. | Multi-partition operation in combination operations |
| CN107832455B (zh) * | 2017-11-24 | 2021-09-17 | 郑州云海信息技术有限公司 | 一种存储对象的数据获取方法、***、设备及存储介质 |
| CN110399397A (zh) * | 2018-04-19 | 2019-11-01 | 北京京东尚科信息技术有限公司 | 一种数据查询方法和*** |
| US11334543B1 (en) | 2018-04-30 | 2022-05-17 | Splunk Inc. | Scalable bucket merging for a data intake and query system |
| US11016696B2 (en) | 2018-09-14 | 2021-05-25 | Commvault Systems, Inc. | Redundant distributed data storage system |
| US11010258B2 (en) | 2018-11-27 | 2021-05-18 | Commvault Systems, Inc. | Generating backup copies through interoperability between components of a data storage management system and appliances for data storage and deduplication |
| US11200124B2 (en) | 2018-12-06 | 2021-12-14 | Commvault Systems, Inc. | Assigning backup resources based on failover of partnered data storage servers in a data storage management system |
| US11698727B2 (en) | 2018-12-14 | 2023-07-11 | Commvault Systems, Inc. | Performing secondary copy operations based on deduplication performance |
| US20200327017A1 (en) | 2019-04-10 | 2020-10-15 | Commvault Systems, Inc. | Restore using deduplicated secondary copy data |
| WO2020220216A1 (en) | 2019-04-29 | 2020-11-05 | Splunk Inc. | Search time estimate in data intake and query system |
| US11715051B1 (en) | 2019-04-30 | 2023-08-01 | Splunk Inc. | Service provider instance recommendations using machine-learned classifications and reconciliation |
| US11463264B2 (en) | 2019-05-08 | 2022-10-04 | Commvault Systems, Inc. | Use of data block signatures for monitoring in an information management system |
| JP7288085B2 (ja) * | 2019-05-17 | 2023-06-06 | ヒタチ ヴァンタラ エルエルシー | オブジェクトベースファイルシステムを管理するための装置、システム及び方法 |
| CN110147372B (zh) * | 2019-05-21 | 2022-12-23 | 电子科技大学 | 一种面向htap的分布式数据库智能混合存储方法 |
| US11494380B2 (en) | 2019-10-18 | 2022-11-08 | Splunk Inc. | Management of distributed computing framework components in a data fabric service system |
| US20210173811A1 (en) | 2019-12-04 | 2021-06-10 | Commvault Systems, Inc. | Optimizing the restoration of deduplicated data stored in multi-node replicated file systems |
| US11922222B1 (en) | 2020-01-30 | 2024-03-05 | Splunk Inc. | Generating a modified component for a data intake and query system using an isolated execution environment image |
| US11099956B1 (en) | 2020-03-26 | 2021-08-24 | Commvault Systems, Inc. | Snapshot-based disaster recovery orchestration of virtual machine failover and failback operations |
| US11687424B2 (en) | 2020-05-28 | 2023-06-27 | Commvault Systems, Inc. | Automated media agent state management |
| US11704313B1 (en) | 2020-10-19 | 2023-07-18 | Splunk Inc. | Parallel branch operation using intermediary nodes |
| US11645175B2 (en) | 2021-02-12 | 2023-05-09 | Commvault Systems, Inc. | Automatic failover of a storage manager |
Family Cites Families (15)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US6862602B2 (en) | 1997-03-07 | 2005-03-01 | Apple Computer, Inc. | System and method for rapidly identifying the existence and location of an item in a file |
| US7099871B2 (en) | 2001-05-04 | 2006-08-29 | Sun Microsystems, Inc. | System and method for distributed real-time search |
| US20050188248A1 (en) * | 2003-05-09 | 2005-08-25 | O'brien John | Scalable storage architecture |
| AU2004286660B2 (en) | 2003-10-27 | 2011-06-16 | Hitachi Vantara, LLC | Policy-based management of a redundant array of independent nodes |
| US8131674B2 (en) * | 2004-06-25 | 2012-03-06 | Apple Inc. | Methods and systems for managing data |
| US7657581B2 (en) | 2004-07-29 | 2010-02-02 | Archivas, Inc. | Metadata management for fixed content distributed data storage |
| US20060036602A1 (en) * | 2004-08-13 | 2006-02-16 | Unangst Marc J | Distributed object-based storage system that stores virtualization maps in object attributes |
| US7779001B2 (en) | 2004-10-29 | 2010-08-17 | Microsoft Corporation | Web page ranking with hierarchical considerations |
| US7761451B2 (en) * | 2005-06-17 | 2010-07-20 | Microsoft Corporation | Efficient querying and paging in databases |
| US9305011B2 (en) | 2005-07-27 | 2016-04-05 | Hitachi Data Systems Corporation | Method for improving mean time to data loss (MTDL) in a fixed content distributed data storage |
| US8392400B1 (en) * | 2005-12-29 | 2013-03-05 | Amazon Technologies, Inc. | Method and apparatus for stress management in a searchable data service |
| US20080033925A1 (en) * | 2006-08-07 | 2008-02-07 | Bea Systems, Inc. | Distributed search analysis |
| US7725470B2 (en) * | 2006-08-07 | 2010-05-25 | Bea Systems, Inc. | Distributed query search using partition nodes |
| US8386508B2 (en) | 2008-04-28 | 2013-02-26 | Infosys Technologies Limited | System and method for parallel query evaluation |
| CN101661484A (zh) * | 2008-08-29 | 2010-03-03 | 株式会社理光 | 一种查询方法及*** |
-
2010
- 2010-09-24 US US12/889,574 patent/US8838624B2/en active Active
-
2011
- 2011-09-13 WO PCT/US2011/051319 patent/WO2012039992A1/en active Application Filing
- 2011-09-13 CN CN201180044786.1A patent/CN103109292B/zh active Active
- 2011-09-13 EP EP11827230.1A patent/EP2619696A4/en active Pending
- 2011-09-13 JP JP2013530184A patent/JP5918244B2/ja active Active
-
2014
- 2014-08-19 US US14/462,706 patent/US9355141B2/en active Active
-
2016
- 2016-05-03 US US15/145,367 patent/US9898514B2/en active Active
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| JP5918244B2 (ja) | フォールトトレラントデータベース管理システムにおいてクエリ結果を統合するシステム及び方法 | |
| JP2013545162A5 (ja) | ||
| JP5918243B2 (ja) | 分散型データベースにおいてインテグリティを管理するためのシステム及び方法 | |
| JP6009097B2 (ja) | 分散オブジェクトストレージエコシステムにおけるコンテンツとメタデータの分離 | |
| CA2574735C (en) | Metadata management for fixed content distributed data storage | |
| US8229893B2 (en) | Metadata management for fixed content distributed data storage | |
| US9575975B2 (en) | Cluster-wide unique ID for object access control lists | |
| US8515915B2 (en) | System and method for enhancing availability of a distributed object storage system during a partial database outage | |
| JP2013544386A5 (ja) | ||
| WO2014133494A1 (en) | Multiple collections of user-defined metadata for self-describing objects | |
| AU2011265370B2 (en) | Metadata management for fixed content distributed data storage |