JP5967673B2 - データメンテナンス用の方法 - Google Patents

Description

本開示は、複数のデータ記憶ノードを含むデータ記憶システムにおけるデータにアクセスし、データを書き込み、且つデータを削除する装置及び方法に関し、方法は、データ記憶システムにおけるサーバ及び／又は記憶ノードにおいて利用され得る。本開示は、更に、かかる方法を実行できる記憶ノード又はサーバに関する。

かかる方法は、米国特許出願公開第２００５／０２４６３９３ Ａ１号明細書に開示されている。この方法は、地理的に異なる場所における複数の記憶センタを使用可能なシステム用に開示されている。記憶データに関する情報を維持するために、分散オブジェクト記憶マネージャが含まれても良い。

かかるシステムに関連する１つの問題は、単純であるが堅固で信頼できるデータメンテナンスをどのように達成するかということである。

通信ネットワークによって相互接続されたデータ記憶ノードを含むデータ記憶システムにおいてデータを維持する方法が開示される。方法は、第１のデータ項目に対する要求を複数の記憶ノードに送信することを含んでも良い。第１のデータ項目は、記憶システムに記憶された第２のデータ項目への参照を含んでも良い。方法はまた、少なくとも１つの記憶ノードから第１のデータ項目を受信すること、及び／又は例えば第１のデータ項目に含まれる参照に基づいて、第２のデータ項目に対する要求を複数の記憶ノードに送信することを含んでも良い。

実施形態において、仮想ディレクトリ構造が、構造化されていない方法でファイルが記憶される記憶システムにおいて実現されても良い。

第１及び第２のデータエンティティに対する要求は、マルチキャストによって送信されても良い。

例えば、マルチキャストを利用することによって、多くの記憶ノードが、容易にアクセスされ得る。

第１及び第２のデータ項目は、第１及び第２の一意キーによって識別されても良い。

実施形態において、記憶システムにおけるファイルは、システムにおけるそれらの位置に関係なく、直接アクセスされ得る。

第１及び第２の一意キーは、システム内における前記記憶ノードのサブセットを指し示すクラスタアドレス、及び／又は記憶ノードのサブセット内におけるデータ項目を識別するデータ項目識別子を含んでも良い。データ項目への参照は、一意キーを含んでも良い。

実施形態において、方法は、大きな記憶システム、例えば何百又は何千もの記憶ノードを含む記憶システムにおいて実行されても良い。

方法は、アプリケーションプログラミングインターフェースＡＰＩから第１及び第２の要求を送信することを含んでも良い。

例えば、記憶ノードにアクセスするために共通ＡＰＩを利用することによって、方法は、多くのプラットホーム上で容易に実行され得る。

ＡＰＩは、記憶ノードと通信するサーバ上で実行されても良い。

実施形態において、方法は、例えば、記憶ノードの維持に責任を負わなくても良い第三者によって設けられた専用装置上で実行されても良い。

ＡＰＩは、記憶ノードで実行されても良い。

例示的な実施形態において、記憶ノードにおいてＡＰＩを実行することによって、記憶システムへのアクセスポイントの数が増加されるようにすることが可能になる。

方法は、ＡＰＩが、受信された第１のデータ項目から、第２のデータ項目を識別する一意キーを検索することを含んでも良い。

例えば、第２のデータ項目用の一意識別子は、一意識別子の表示が第１のデータ項目に含まれている場合に、容易に検索可能であり得る。

方法は、第１のデータ項目を識別するキーをＡＰＩにおいて受信することを含んでも良い。

実施形態において、１つ又は複数のディレクトリ構造が、同時に実現されても良い。

第２のデータ項目は、第３のデータ項目への参照を含んでも良い。

例えば、実施形態において、多数のレベルを備えたディレクトリ構造が、実現されても良い。

第２のデータ項目は、画像などのペイロードデータを含んでも良い。

例えば、ペイロードデータを備えたデータファイルは、（例えばサブフォルダに記憶された）ディレクトリ構造の一部であっても良い。

第１のデータ項目は、ユニキャストによって送信されても良い。

例えば、ユニキャストを利用することによって、データ項目は、帯域幅を効率的に利用する方法で転送され得る。

実施形態によれば、通信ネットワークによって相互接続されたデータ記憶ノードを含むデータ記憶システムにおいてデータを維持する方法は、サーバ及び／又はデータ記憶ノードにおいて実行されても良い。方法は、第１のデータ項目を少なくとも１つの記憶ノードに記憶することを含んでも良い。方法はまた、少なくとも１つの記憶ノードに記憶された第２のデータ項目を更新することを含んでも良い。例えば、第２のデータ項目は、第１のデータ項目への参照を第２のデータ項目に追加によって更新されても良い。第２のデータ項目の更新は、第２のデータ項目のコピーを記憶する少なくとも１つの記憶ノードに要求を送信することを含んでも良い。要求は、その少なくとも１つの記憶ノードが、第１のデータ項目への参照を第２のデータ項目に追加することを命令及び／又は要求しても良い。

実施形態において、新しい項目は、例えば新しい項目への参照をディレクトリ構造における他の項目に追加することによって、ディレクトリ構造に容易に追加され得る。

実施形態によれば、データを維持するための方法は、データ記憶システムに含まれるサーバ又はデータ記憶ノードにおいて実行されても良い。データ記憶ノードは、通信ネットワークによって相互接続されても良い。方法は、少なくとも１つの記憶ノードに記憶された第１のデータ項目を削除することを含んでも良い。方法はまた、第２のデータ項目における第２のデータ項目への参照を削除することによって、少なくとも１つの記憶ノードに記憶された第２のデータ項目を更新することを含んでも良い。

例示的な実施形態において、ディレクトリ構造における項目は、例えば項目への参照を削除することによって容易に削除され得る。

実施形態によれば、データ記憶システムは、通信ネットワークによって相互接続されたデータ記憶ノードを含んでも良い。サーバ又はノードは、アプリケーションプログラミングインターフェースＡＰＩを含んでも良く、且つ第１のデータ項目に対する要求を複数の記憶ノードに送信するように構成されても良い。第１のデータ項目は、記憶システムに記憶された第２のデータ項目への参照を含んでも良い。少なくとも１つの記憶ノードは、第１のデータ項目をＡＰＩに送信するように構成されても良い。ＡＰＩ及び／又は記憶ノード若しくはサーバは、第１のデータ項目に含まれる参照に基づいて、第２のデータ項目に対する要求を複数の記憶ノードに送信するように更に構成されても良い。

例えば、仮想ディレクトリ構造は、構造化されていない方法でファイルが記憶される記憶システムにおいて実現されても良い。

開示される実施形態の他の目的、特徴及び利点は、以下の詳細な開示から、添付の特許請求の範囲から、同様に図面から明らかになり得る。

一般に、特許請求の範囲において用いられる全ての用語は、本明細書において明示的に別段の定義がなされていなければ、当該技術分野におけるそれらの通常の意味に従って解釈されるべきである。「ａ／ａｎ／ｔｈｅ［要素、装置、コンポーネント、手段、ステップ等］」への全ての言及は、明示的に別段の言明がなければ、前記要素、装置、コンポーネント、手段、ステップ等の少なくとも１つの例を指すものとしてオープンに解釈されるべきである。本明細書で開示されるどんな方法のステップも、明示的な言明がなければ、開示された正確な順序で実行される必要はない。

開示される実施形態の上記の、同様に追加の目的、特徴、及び利点は、添付の図面への参照と共に、以下の例示的で非限定的な詳細な説明を通して一層良く理解されよう。図面において、同じ参照数字は、同様の要素に使用される可能性がある。

図１は、例示的な記憶システムの概略図である。 図２は、記憶システムに記憶された多数のデータ項目の例示的な概略ブロック図である。 図３は、例示的なデータ項目識別子の概略ブロック図である。 図４は、データを検索するための例示的な方法の概略ブロック図である。 図５ａは、記憶システムにおける異なるエンティティ間の例示的な通信の実例である。 図５ｂは、記憶システムにおける異なるエンティティ間の例示的な通信の実例である。 図５ｃは、記憶システムにおける異なるエンティティ間の例示的な通信の実例である。 図６は、データを記憶するための例示的な方法の概略ブロック図である。 図７は、データを削除するための例示的な方法の概略ブロック図である。

開示される方法及びシステムの詳細な実施形態が、図面に関連して説明され得る。本開示は、複数の記憶ノードを含む分散データ記憶システムに関する。システムの例示的な構造及びそれが使用され得るコンテキストが、図１に概説されている。

ユーザコンピュータ１が、例えばインターネット３を介して、サーバ７を走行するアプリケーション５にアクセスしても良い。従って、本明細書で示されているように、ユーザコンテキストは、クライアントサーバ構成であっても良い。しかしながら、開示されるデータ記憶システムが、例えば他の通信方法を利用する他の構成においてもまた有用であり得ることに留意されたい。

図示の事例において、２つのアプリケーション５、９がサーバ７上を走行しても良い。しかしながら、もちろん、任意の数のアプリケーションが、サーバ７上を走行しても良い。各アプリケーションは、分散データ記憶システム１３に関連するインターフェースを提供し得る、且つサーバ上を走行するアプリケーションからの要求、例えば書き込み及び読み出し要求をサポートできるＡＰＩ（アプリケーションプログラミングインターフェース）１１を有しても良い。データは、２０１１年４月２１日出願の米国特許出願第１３／１２５，５２４号明細書に詳細に説明されている方法を用いて、記憶システムから読み出し、且つそこに書き込んでも良く、その特許出願の内容は、これによって、参照により本明細書に援用される。従って、データの読み出し及び書き込み方法は、本明細書において更に詳細には説明されなくても良い。アプリケーションの観点からは、データ記憶システム１３からの読み出し又はそこへの書き込み情報は、任意の他のタイプの記憶ソリューション、例えばファイルサーバ又はハードドライブを用いるのと同じに見える可能性がある。

各ＡＰＩ１１は、データ記憶システム１３における記憶ノード１５と通信しても良く、記憶ノードは、互いに通信しても良い。代替又は追加として、記憶ノード１５の１つ又は複数は、上記で開示されたような要求をサポートするためのＡＰＩ２３を含んでも良い。これらの通信は、ＴＣＰ（伝送制御プロトコル）及びＵＤＰ（ユーザデータグラムプロトコル）に基づいても良い。また、他の通信プロトコルを利用しても良い。

分散データ記憶システムのコンポーネントは、記憶ノード１５及び記憶ノード１５にアクセス可能なサーバ７におけるＡＰＩ１１であっても良い。本開示は、サーバ７及び記憶ノード１５において実行される方法に関連して説明され得る。これらの方法は、主に、サーバ及び記憶ノード上でそれぞれ実行されるソフトウェア／ハードウェア組み合わせインプリメンテーションとして具体化されても良い。サーバ及び記憶ノードの動作は、全体的な分散データ記憶システムの動作及び特性を一緒に決定しても良い。

図１において、サーバ７は、記憶ノード１５とは別個の、記憶システム１３のメンバとして示されているが、サーバ７が、サーバ機能を含む記憶ノードであっても良いことに留意されたい。

記憶ノード１５は、典型的には、多数の機能ブロックを設けられたファイルサーバによって具体化されても良い。従って、記憶ノードは、例えば、ＲＡＩＤ（独立ディスクの冗長アレイ）として任意選択的に構成された多数の内部ハードドライブ（例えば統合ドライブエレクトロニクス（ＩＤＥ）、シリアルアドバンストテクノロジアタッチメント（ＳＡＴＡ）などを介して接続された）又は外部ハードドライブ（例えば、ユニバーサルシリアルバス（ＵＳＢ）、ファイアワイヤ、ブルートゥースなどを介して接続された）を含み得る記憶媒体１７を含んでも良い。しかしながら、他のタイプの記憶媒体が、同様に考えられる。

各記憶ノード１５は、ノードリスト、即ち、その記憶ノードセット又はグループにおける全ての記憶ノードのＩＰアドレスを含むノードリストを含んでも良い。グループにおける記憶ノードの数は、少数から何百又は何千の記憶ノードまで異なっても良い。

記憶媒体１７は、収集対象１９の形態をした１つ若しくは複数のデータ項目１９、２１、又はデータファイル２１の形態をしたペイロードデータを記憶しても良い。収集対象１９は、参照セットを含んでも良い。参照は、記憶システムに記憶された１つ又は複数のデータファイル、例えばデータファイル２１への参照であっても良い。参照はまた、記憶システムに記憶された別の収集対象１９への参照であっても良い。参照は、記憶ノード１５の記憶位置に対するポインタ（例えばメモリアドレス）を含んでも良い。参照は、参照される収集対象又はデータファイルの識別子を含んでも良い。

以下でより詳細に開示されるように、収集対象１９は、記憶システムにおいて構造化層を実現するために使用されても良い。収集対象１９において参照されるデータファイル２１は、かかるインプリメンテーションにおいて、構造において記憶されたデータファイルを表しても良い。収集対象１９において参照される追加収集対象１９は、かかるインプリメンテーションにおいて、ディレクトリに記憶されたサブディレクトリを表しても良い。

収集対象１９は、所定のフォーマットを有するデータ対象として具体化されても良い。データ対象は、それがＡＰＩによって解釈されるバイナリファイルであっても良いという意味で、記憶媒体１７のファイルシステムにおける特別なファイルであっても良い。例において、データ対象は、記憶媒体１７のファイルシステムにおける標準データファイルであっても良い。データ対象は、例えば、参照される収集対象１９及び／又はデータファイル２１を示すプレーンテキストファイルであっても良い。データ対象は、ファイル２１と同じ、ファイルシステムのルーチンを用いて、読み取り可能であっても良い。

図２は、一実施形態に従って収集対象１９ａを概略的に示す。収集対象１９ａは、関連する収集対象識別子２０ａを有しても良い。識別子２０ａは、例えば、汎用一意識別子（ＵＵＩＤ）であっても良い。収集対象識別子２０ａは、収集対象１９ａのヘッダに含まれても良い。しかしながら、収集対象識別子２０ａは、例えば収集対象１９ａに含まれるのではなく、記憶ノード１５に維持されるレジスタに記憶されても良い。例において、ＵＵＩＤ及び／又は記憶ノード１５に維持されるレジスタは、例えば収集対象１９ａが見つけられることになるメモリアドレスを指し示すことによって、収集対象１９ａを収集対象識別子２０ａと関連付けても良い。従って、収集対象１９ａは、第１の一意キーによって識別される第１のデータ項目を形成しても良い。

収集対象１９ａは、例えばストリングの形態で、別の収集対象１９ｂの識別子２０ｂを備えたフィールド２２ａを含んでも良い。収集対象１９ａは、収集対象１９ｂへの参照を含んでも良い。収集対象１９ｂは、収集対象１９ａと同じ記憶ノード上に、又は収集対象１９ａとは別の記憶ノード上に記憶されても良い。記憶システムは、収集対象１９ｂの位置を特定してアクセスするために、フィールド２２ａにおける識別子２０ｂを利用しても良い。従って、収集対象１９ｂは、第２の一意キーによって識別される第２のデータ項目を形成しても良い。

一実施形態において、多数のネットワークにわたる大きな記憶システムを実現するために、データ項目識別子２０ａ−ｄは、２つのデータ要素を含んでも良い。図３を参照すると、第１のデータ要素３０は、データ項目（収集対象１９ａ−ｃ又はデータファイル２１ａ）が位置するクラスタを識別可能なクラスタＩＤ３１であっても良い。クラスタアドレスは、マルチキャストアドレス３２であっても良い。マルチキャストアドレス３２は、データ項目に対する要求を特定のクラスタに送るために、ＡＰＩによって利用されても良い。第２のデータ要素３３は、クラスタ内のデータ項目１９ａ−ｄを識別する一意番号３５によって形成されたデータ項目ＩＤ３４であっても良い。一意番号３５は、定義された長さ、例えば１２８ビットを備えた番号であっても良く、又は長さは、変化しても良い。一意番号３５は、多数のビットを含んで、多数のデータ項目をクラスタ内で一意に識別できるようにしても良い。この配置によって、一クラスタにおける収集要素は、別のクラスタにおける別の収集要素又はデータファイルを参照し得る。換言すれば、第１及び第２の一意キーは、システム内における記憶ノードのサブセットを指し示すクラスタアドレス、及び記憶ノードのサブセット内におけるデータ項目を識別するデータ項目識別子を含んでも良い。

再び図１及び２に参照すると、サーバ７は、例えば、特定の識別子（例えば識別子２０ａ）に関連する収集対象（例えば収集対象１９ａ）を記憶する記憶ノード１５を示すレジスタを含んでも良い。別の例において、収集対象１９ａは、米国特許出願第１３／１２５，５２４号明細書に開示されている読み出し方法を用いて位置を特定されても良い。簡潔に言えば、この読み出し方法によれば、サーバ７又は記憶ノード１５は、複数の記憶ノード１５にマルチキャストメッセージを送信しても良い。マルチキャストメッセージは、所望の収集対象１９ａの識別子２０ａを含んでも良い。各記憶ノード１５は、マルチキャストメッセージの受信に応じて、前記識別子を有する収集対象のために、自らの記憶媒体１７を走査しても良い。見つかった場合に、記憶ノード１５は、それが、求められている対象を記憶していることをマルチキャストメッセージの発信者に応答して知らせても良い。次に、収集対象１９ａは、収集対象１９ａを記憶する応答記憶ノード１５に送信されたユニキャスト要求によってアクセスされても良い。

本実施形態によれば、マルチキャスト通信は、複数の記憶ノードと同時に通信するために使用されても良い。マルチキャスト又はＩＰマルチキャストによって、本明細書では、マルチキャストアプリケーション用に取っておいても良いＩＰアドレスにメッセージを送信することによって達成され得るポイントツーマルチポイント通信が意味される。例えば、メッセージ、例えば要求は、かかるＩＰアドレス（例えば２４４．０．０．１）に送信されても良く、多くの受信サーバが、そのＩＰアドレスへの申込者として登録されても良い。受信サーバのそれぞれは、それ自体のＩＰアドレスを有しても良い。ネットワークにおけるスイッチが、２４４．０．０．１に向けられたメッセージを受信した場合に、スイッチは、そのメッセージを、申込者として登録された各サーバのＩＰアドレスに転送しても良い。

原則として、単一のサーバが、マルチキャストアドレスへの申込者として登録されても良く、その場合に、ポイントツーポイント通信が、達成され得る。しかしながら、この開示のコンテキストにおいて、かかる通信は、マルチキャスト方式が用いられるので、やはりマルチキャスト通信と考えられ得る。

本実施形態によれば、ユニキャスト通信は、単一の受信者との通信を指しても良い。ユニキャスト通信は、ネットワークの関係者によって開始されても良く、単一の特定の受信者に向けられても良い。

収集対象１９ａに加えて、収集対象１９ｂは、第３の収集対象１９ｃの識別子２０ｃを備えたフィールド２２ｂを含んでも良い。収集対象１９ｃは、データファイル２１ａの識別子２０ｄを備えたフィールド２２ｃを含んでも良い。換言すれば、収集対象１９ａ−ｃのどれでも（又は例えば収集対象１９ａ−ｃのそれぞれ）が、第３のデータ項目への参照を含む第２のデータ項目を表しても良く、データファイル２１ａは、ペイロードデータ、例えば画像を含む第２のデータ項目を表しても良い。

ルート収集対象として収集対象１９ａを指定することによって、収集対象１９ａは、記憶システムのルートディレクトリ１９ａを表しても良い。同様に、収集対象１９ｂは、ルートディレクトリ１９ａのサブディレクトリ１９ｂを表しても良い。収集対象１９ｃは、サブディレクトリ１９ｂのサブディレクトリを表しても良い。データファイル２１ａは、サブディレクトリ１９ｃに記憶されたデータファイルを表しても良い。このように、収集対象１９ａ−ｃは、階層記憶構造を定義しても良い。構造は、ディレクトリツリーと呼ばれても良い。

図４及び５ａ−ｃを参照すると、記憶ノード１５に記憶されたファイル１９、２１にアクセスするために、ディレクトリ構造を解析するための方法が開示され得る。

ディレクトリ構造の出発点は、所定のルートキーであっても良い。例えば、記憶ノード１５のどれも、ルートキーを含んでも良い。このキーは、記憶クラスタの外部に記憶されても良く、且つディレクトリ構造における第１のデータ項目（例えば収集対象１９ａ）を識別するために用いられても良い。記憶クラスタは、ユーザが、同じ記憶クラスタ内に記憶された多数の個別ディレクトリ構造を有することができるようにする多数のルートキーを有しても良い。ディレクトリ構造は、いくつかの記憶クラスタにわたっても良い。ルートキーは、クラスタ内に記憶されたディレクトリ構造を示す外部情報と一緒に記憶されも良い。

ブロック４０において、サーバ７は、ルートキーを受信しても良く、ルートキーは、第１のデータ項目１９、２１を識別しても良く、且つ記憶システム内のファイルを識別する一意識別子をＡＰＩ１１に伝達しても良い。例において、ＡＰＩ２３は、記憶ノード１５において実行されても良く、ルートキーは、サーバ７ではなく記憶ノード１５で受信されても良い。

ブロック４１において、サーバ７におけるＡＰＩ１１は、ルートキーによって識別されたデータ項目（例えば収集対象１９ａ）に対する要求を、記憶システムにおける記憶ノード１５ａ−ｅ又はノードのサブセットにマルチキャストしても良い。例えば、マルチキャストメッセージは、例えば図３に関連して開示されたデータ項目識別子構成を用いて、特定のクラスタに送信されても良い。一実施形態によれば、ルートキーによって識別されたデータ項目（例えば収集対象１９ａ）は、それが、システムによって使用され得る追加メタデータを含んでも良いという意味で、特定のデータ項目であっても良い。かかるデータの例は、ディレクトリ構造における項目へのアクセス許可に関する情報、あるデータ項目をどこに（例えば、ソリッドステートドライブ（ＳＳＤ）など、迅速なアクセスを備えた記憶ノード上に）記憶するかの情報等であっても良い。

ブロック４２において、記憶ノード１５ａ−ｅは、マルチキャストメッセージの受信に応じて、ルートキーにおけるデータ項目ＩＤ３４によって識別されるデータ項目の位置を特定しようとして、自らのそれぞれの記憶媒体１７を走査しても良い。

説明のために、ノード１５ｂ及び１５ｅが、データ項目ＩＤ３４によって識別されるデータ項目の位置を特定することが、この例において仮定されても良い。ブロック４３において、データ項目を見つけたノード１５ｂ、１５ｅは、どの他のノード１５ｂ、１５ｄ、１５ｅが、ノード１５ｂ、１５ｅにおけるデータ項目及び現在の実行負荷（例えば、ノードがどれくらい忙しいか、ノードがどれほど多数の要求を受信したか、どれだけの空き空間がノード上にあるか等）に関する情報を用いて応答しても良い。要求されたデータ項目は、複数の記憶ノード１５ｂ、１５ｄ、１５ｅに記憶されている可能性があり、ＡＰＩは、ノード１５ｂ、１５ｄ、１５ｅから受信された情報を収集しても良く、且つＡＰＩが、データ項目の検索のためにどのノードを選択するかに関する決定し得る前に、ＡＰＩが、データ項目を含むリストされた記憶ノード１５ｂ、１５ｄ、１５ｅの５０％超から応答を受信するまで、待っても良い。決定は、最低の実行負荷を有するどのノードに基づいても良い。

ブロック４４において、ＡＰＩ１１は、特定のファイルに対するユニキャスト要求を、選択された記憶ノードに送信しても良い。この例において、説明のために、記憶ノード１５ｂが選択されることが仮定されても良い。ＡＰＩ１１は、記憶ノード１５ｂからデータ項目を検索しても良い。ＡＰＩ１１は、選択されたノード１５ｂとの読み出し又は通信障害の場合には、ファイルのコピーを記憶する全ての記憶ノード１５ｂ、１５ｄ、１５ｅのリストを維持しても良い。エラーが発生した場合に、ＡＰＩ１１は、リストにおいて次善のノードを明白に選択し、読み出し動作を継続しても良い。

ブロック４５において、ＡＰＩは、検索されたデータ項目の内容を解釈しても良い。ディレクトリ構造が追加のレベルを含む場合に、検索されるデータ項目は、収集対象１９ｂであっても良い。そうならば、ＡＰＩ１１は、ディレクトリ構造における別の収集対象１９ｃを指す識別子２０ｂを含み得るフィールド２２ｂを読み出しても良い。例えば、ＡＰＩは、第２のデータ項目、例えば収集対象１９ｂを識別する一意キー、即ち識別子２０ｂを、受信された第１のデータ項目、例えば収集対象１９ａから検索しても良い。次に、プロセスは、ブロック４１に戻っても良く、且つディレクトリ構造の解析を継続しても良い。従って、第１及び第２の要求の両方とも、アプリケーションプログラミングインターフェースＡＰＩから送信されても良い。プロセスは、ディレクトリ構造における最後の対象、例えばデータファイル２１ａ、即ちそのファイルにおいてプロセスが、４６で終了し得るデータファイル２１ａが識別され検索されてしまうまで、継続しても良い。別の例において、ＡＰＩ１１は、更新要求、例えばディレクトリ構造における対象に対応するデータ項目におけるデータを変更又は連結するコマンドを、識別された対象に送信しても良い。

例として、データファイル２１が、ディレクトリ構造のルートに位置することがあり得る。かかる場合に、プロセスは、一回ループされても良い。何故なら、最初に検索された収集対象１９ａが、データファイル２１ａへの参照を含み得るからである。データファイル２１ａへの参照を含むことに加えて、検索された収集対象がまた、収集対象１９ｂなどの他のデータ項目への参照を含んでも良いことが強調される。

従って、上記によれば、方法は、ファイルにアクセスするために通信ネットワークによって相互接続されたデータ記憶ノードを含むデータ記憶システムにおいて実行されても良い。方法は、第１のデータ項目１９、２１（例えば収集対象１９ａ）に対する要求を、複数の記憶ノード１５ａ−ｅに送信することを含んでも良い。第１のデータ項目は、記憶システムに記憶された第２のデータ項目（例えばデータファイル２１ａ又は収集対象１９ｂ）への参照を含んでも良い。方法は、少なくとも１つの記憶ノード１５ｂから第１のデータ項目を受信すること、及び第２のデータ項目に対する要求を、第１のデータ項目に含まれる参照に基づいて複数の記憶ノード１５ａ−ｅに送信することを含んでも良い。

実例として、図２を参照すると、ＡＰＩは、ディレクトリ構造における経路を解決するために、参照されたエンベロープを再帰的に読み出して解釈しても良い。例えば、ＡＰＩは、構造化された経路におけるファイルを表す非構造化キーを識別しても良い。例えば、記憶システムにアクセスするユーザは、経路
「／Ｄｏｃｕｍｅｎｔｓ／Ｓａｍｐｌｅ＿Ｐｉｃｔｕｒｅｓ／Ｂｌｕｅ＿Ｈｉｌｌｓ．ｊｐｇ」
を解決したいと思うかも知れない。

図２において、収集対象１９ａは、（一意キー２０ａによって識別される）ルートキー「／」を表しても良く、識別子２２ａは、（一意キー２０ｂによって識別される）フォルダ「Ｄｏｃｕｍｅｎｔｓ／」を表す収集対象１９ｂへの参照を含んでも良い。収集対象１９ｂにおける識別子２２ｂは、フォルダ「Ｓａｍｐｌｅ＿Ｐｉｃｔｕｒｅｓ／」を表す収集対象１９ｃへの参照を含んでも良い。最後に、収集対象１９ｃにおける識別子２２ｃは、ファイル「Ｂｌｕｅ＿Ｈｉｌｌｓ．ｊｐｇ」用のペイロードデータを含むデータファイル２１ａへの参照を含んでも良い。従って、収集対象における参照を再帰的に読み出すことによって、仮想ファイル構造が、非構造化記憶システムにおいて生成され得る。

図６及び５ａ−ｃを参照すると、ファイル１９、２１を記憶ノード１５に作成するためにディレクトリ構造を解析するための方法が開示されている。

図４に開示されているシステムと同様に、ディレクトリ構造の出発点は、所定のルートキーである。ルートキーは、任意のキーであっても良く、システムの全体を通して多数のルートキーがあっても良い。このキーは、記憶クラスタの外部に記憶されても良く、且つディレクトリ構造における第１のデータ項目（例えば収集対象１９ａ）を識別するために使用されても良い。

ブロック６０において、サーバ７は、ルートキーを受信しても良く、且つ記憶システム内のファイルを識別する一意識別子をＡＰＩに伝達しても良い。

ブロック６１において、ＡＰＩ１１は、上記の方法に従って、所望のデータ項目への経路を解決しても良い。

ブロック６３において、サーバ７におけるＡＰＩ１１は、例えば図３に関連して開示されたデータ項目識別子構成を用いて、識別子を含むデータ項目（例えば収集対象１９ｃ）を記憶するための要求を、記憶システムにおける全ての記憶ノード１５ａ−ｅに、又は例えば特定のクラスタ内におけるノードのサブセットにマルチキャストしても良い。

ブロック６３において、記憶ノード１５−ｅは、マルチキャストメッセージの受信に応じて、データ項目ＩＤ３４がまだ使用されていないことを検証しても良い。

ブロック６４において、その特定の識別子を備えた既存ファイルを見つけられない記憶ノード１５−ｅは、記憶ノードにおける自由な記憶空間、記憶ノードが走行しているハードウェアの使用年数の表示、現在のＣＰＵ負荷、並びに／又は緯度、経度、及び高度等の形態をした記憶ノード１５−ｅの地理的位置を示し得る受信確認で応答しても良い。

ブロック６５において、ＡＰＩ１１は、マルチキャスト要求に応答した記憶ノードから返されたデータに基づいて、３つの記憶ノード（例えば記憶ノード１５ａ、１５ｂ及び１５ｅ）を選択しても良い。３つの最も適切なノードが選択されると、ＡＰＩ１１は、データ項目を記憶する要求を３つのノードに同時に送信しても良い。選択されたノード１５ａ、１５ｂ、１５ｅの１つへのデータ項目の転送中にエラーが発生した場合に、例えば選択されたノードの５０％超が動作可能である限り、動作は継続する。

ブロック６６において、ディレクトリ構造で１レベル高いデータ項目（例えば第１のデータ項目−収集対象１９ｂ）における識別子フィールド２２ｂは、上記による読み出し方法に従い第１のデータ項目を検索することによって、又は例えばサーバが第１のデータ項目の識別子をキャッシュした場合には、第１のデータ項目に直接アクセスすることによって、記憶されたデータ項目（例えば収集対象１９ｃ）への参照を用いて更新されても良い。

システムにおけるデータ完全性を向上させるために、上記の方法は、データ項目が記憶された後だが、しかし第１のデータ項目が更新される前に、全ての記憶ノードとの通信が失われるであろう場合に、データ項目を記憶する前に第１のデータ項目を検索する動作で補足されても良い。この手順によって、ひとたび記憶ノードとの通信が再開された場合に、ＡＰＩは、更新手順を再開し得る。

従って、上記によれば、方法は、通信ネットワークによって相互接続されたデータ記憶ノードを含むデータ記憶システム内の様々な装置において実行されても良い。方法は、第１のデータ項目を少なくとも１つの記憶ノードに記憶することと、第１のデータ項目への参照を第２のデータ項目に追加することによって、少なくとも１つの記憶ノードに記憶された第２のデータ項目を更新することと、を含んでも良い。

図７及び５ａ−ｃを参照すると、記憶ノード１５におけるファイル１９、２１を削除するためにディレクトリ構造を解析する方法が開示されている。

図４に関連する開示と同様に、ディレクトリ構造の出発点は、所定の、しかし任意のルートキーであっても良い。このキーは、記憶クラスタの外部に記憶されても良く、且つディレクトリ構造における第１のデータ項目（例えば収集対象１９ａ）を識別するために使用されても良い。

ブロック７０において、サーバ７は、ルートキーを受信しても良く、且つ記憶システム内のファイルを識別する一意識別子をＡＰＩに伝達しても良い。

ブロック７１において、ＡＰＩ１１は、上記の方法に従って、所望のデータ項目への経路を解決しても良い。

ブロック７２において、サーバ７におけるＡＰＩ１１は、例えば図３に関連して開示されたデータ項目識別子構成を用いて、識別子を含むデータ項目（例えば収集対象１９ｃ）の位置に関する問い合わせを、記憶システムにおける記憶ノード１５ａ−ｅに、又は例えば特定のクラスタ内におけるノードのサブセットにマルチキャストしても良い。

ブロック７３において、記憶ノード１５ａ−ｅは、マルチキャストメッセージの受信に応じて、データ項目ＩＤ３４によって識別されたデータ項目の位置を特定するために、自らのそれぞれの記憶媒体１７を走査しても良い。

ブロック７４において、データ項目の位置を特定したノードは、そのデータ項目を記憶している可能性がある他のノードに関する情報及びノードにおける現在の実行負荷と共に応答しても良い。要求されたデータ項目は、複数の記憶ノードに記憶されている可能性がある。ＡＰＩは、ノードから受信された情報を収集しても良く、且つデータ項目の削除のためにどのノードを選択するかを決定する前に、データ項目を含むリストされた記憶ノードの５０％超からＡＰＩが応答を受信するまで、待っても良い。

ブロック７５において、ＡＰＩ１１は、特定のファイル（例えば収集対象１９ｃ）を削除するユニキャスト要求を、選択された記憶ノードに送信しても良い。

ブロック７６において、ディレクトリ構造において１レベル高いデータ項目（例えば収集対象１９ｂ）における識別子フィールド２２ｂは、削除されたデータ項目（例えば収集対象１９ｃ）への参照を削除することによって更新されても良い。更新は、上記の読み出し方法に従って第１のデータ項目を検索することによって、及び／又は例えばサーバが第１のデータ項目の識別子をキャッシュした場合に、第１のデータ項目に直接アクセスすることによって行われても良い。削除されるデータ項目が、ディレクトリ構造において何レベルも下位に位置する場合に、削除動作は、ｉ）第１のデータ項目を削除すること、及びｉｉ）第１のデータ項目への参照を削除することによって第２のデータ項目を更新することを追加して、図４に関連して開示された方法として表現され得る。

従って、データ削除方法は、通信ネットワークによって相互接続されたデータ記憶ノードを含むデータ記憶システムにおいて実行されても良い。方法は、少なくとも１つの記憶ノードに記憶された第１のデータ項目を削除することを含んでも良い。方法はまた、第２のデータ項目における第１のデータ項目への参照を削除することによって、少なくとも１つの記憶ノードに記憶された第２のデータ項目を更新することを含んでも良い。

収集対象１９は、データファイルと同様の方法で処理され維持されても良い。これは、例えばどんなサブディレクトリもなしに、又は単一のディレクトリ内において、平坦記憶構造にデータを記憶できるようにする。仮想階層記憶構造が、参照を含む収集対象１９を他の収集対象１９及び／又はデータファイル２１に追加することによって生成されても良い。それは、収集対象１９の異なるセットを使用することによって、同じデータが、いくつかの異なる仮想階層記憶構造において組織化され得るようにさえする。

データセキュリティの理由で、記憶システムに記憶されたいくらか又は全ての情報（例えば収集対象１９及び／又はデータファイル２１）は、記憶システムにおいて冗長的に記憶されても良い。収集対象１９ａ−ｃ及びデータファイル２１ａは、２つ以上の記憶ノード１５に記憶されても良い。収集対象又はデータファイルの各インスタンスは、同じ識別子に関連付けられても良い。かかる場合に、上記の読み出し方法は、収集対象を記憶する各記憶ノードからの応答を結果としてもたらし得る。従って、冗長的に記憶された収集対象は、収集対象を記憶する記憶ノードの１つ又は全てから検索されても良い。

開示された方法及びシステムを例示するいくつかの実施形態を説明した。しかしながら、当業者によって容易に理解されるように、本明細書で説明される方法及びプロダクトによる上記の実施形態に加えて他の実施形態が、等しく可能である。前述の例は、限定的であるようには意図されてなく、保護の範囲は、添付の特許請求の範囲によって定義されることになる。

Claims (9)

1. データ記憶システムにおいてデータを維持するための方法において、前記データ記憶システムが、通信ネットワークによって相互接続されたデータ記憶ノード（１５）を含み、前記方法が、
   第１のデータ項目に対する要求を前記複数の記憶ノードの少なくとも１つにマルチキャストによって送信すること（４１）において、前記第１のデータ項目が、前記記憶システムに記憶された第２のデータ項目への参照を含む、送信することと、
   前記複数の記憶ノードの少なくとも１つの記憶ノードから前記第１のデータ項目を受信すること（４３）と、
   前記第２のデータ項目に対する要求を前記複数の記憶ノードのサブセットにマルチキャストによって送信すること（４１）において、前記サブセットが、前記第１のデータ項目に含まれる前記参照に基づいて決定される、送信することと、
   を含み、
   前記第１のデータ項目が第１の一意キーに関連付けられ、前記第２のデータ項目が第２の一意キーに関連付けられ、前記第１及び第２の一意キーのそれぞれがクラスタアドレス及びデータ項目識別子を含み、
   前記クラスタアドレスが、前記システム内における前記記憶ノードのサブセットを識別し、汎用一意識別子、すなわちＵＵＩＤである前記データ項目識別子が、前記記憶ノードのサブセット上に記憶されたデータ項目を識別し、前記第２のデータ項目が前記受信された第１のデータ項目からの前記一意キーに基づいて識別されることを特徴とする方法。
2. 請求項１に記載の方法において、前記第１及び第２の要求をアプリケーションプログラミングインターフェース、すなわちＡＰＩから送信することを更に含むことを特徴とする方法。
3. 請求項２に記載の方法において、前記ＡＰＩが、前記記憶システムと通信するサーバ上で実行されることを特徴とする方法。
4. 請求項２に記載の方法において、前記ＡＰＩが、前記記憶システム内の記憶ノード上で実行されることを特徴とする方法。
5. 請求項２に記載の方法において、前記第１のデータ項目が、前記ＡＰＩで受信され、前記第１の一意キーが、前記ＡＰＩにおいて識別されることを特徴とする方法。
6. 請求項１に記載の方法において、前記第２のデータ項目が、第３のデータ項目への参照を含むことを特徴とする方法。
7. 請求項１に記載の方法において、前記第２のデータ項目が、ペイロードデータを含むことを特徴とする方法。
8. 請求項７に記載の方法において、前記ペイロードデータが、画像ファイルであることを特徴とする方法。
9. 通信ネットワークを介して相互接続された他のデータ記憶ノードを含むデータ記憶システムにおけるデータ記憶ノードにおいて、当該データ記憶ノードが、
   前記通信ネットワークを介して通信するように構成された通信インターフェースと、
   アプリケーションプログラミングインターフェース、すなわちＡＰＩ（２３）において、
   第１のデータ項目に対する要求を、前記通信インターフェースを介して複数の記憶ノードにマルチキャストによって送信するように、
   前記通信インターフェースを介して前記複数の記憶ノードの少なくとも１つの記憶ノードから前記第１のデータ項目を受信し、前記第１のデータ項目が、前記記憶システムに記憶された第２のデータ項目への参照を含むように、
   前記第１のデータ項目に含まれる前記参照に基づいて、前記第２のデータ項目に対する要求を送信する相手の前記複数の記憶ノードのサブセットを決定するように、
   前記第２のデータ項目に対する前記要求を前記複数の記憶ノードの前記サブセットにマルチキャストによって送信するように構成されたアプリケーションプログラミングインターフェースと、
   を特徴とし、
   前記第１のデータ項目が第１の一意キーに関連付けられ、前記第２のデータ項目が第２の一意キーに関連付けられ、前記第１及び第２の一意キーのそれぞれがクラスタアドレス及びデータ項目識別子を含み、
   前記クラスタアドレスが、前記システム内における前記記憶ノードのサブセットを識別し、汎用一意識別子、すなわちＵＵＩＤである前記データ項目識別子が、前記記憶ノードサブセット上に記憶されたデータ項目を識別し、前記第２のデータ項目が前記受信された第１のデータ項目からの前記一意キーに基づいて識別されることを特徴とするデータ記憶ノード。
   

Images