特表 2023-525882 データの分割、処理、および保護

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

(12)【公報種別】公表特許公報(A)

(11)【公表番号】

(43)【公表日】2023-06-19

(54)【発明の名称】データの分割、処理、および保護

(51)【国際特許分類】

   G06F 16/182 20190101AFI20230612BHJP

【ＦＩ】

G06F16/182

【審査請求】未請求

【予備審査請求】未請求

(21)【出願番号】P 2022569552

(86)(22)【出願日】2021-05-12

(85)【翻訳文提出日】2022-11-30

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

(87)【国際公開番号】W WO2021231554

(87)【国際公開日】2021-11-18

(31)【優先権主張番号】63/023,791

(32)【優先日】2020-05-12

(33)【優先権主張国・地域又は機関】US

(81)【指定国・地域】

【公序良俗違反の表示】

（特許庁注：以下のものは登録商標）

１．ＪＡＶＡＳＣＲＩＰＴ

(71)【出願人】

【識別番号】522444483

【氏名又は名称】エアメトゥル，インコーポレーテッド

(74)【代理人】

【識別番号】100118913

【弁理士】

【氏名又は名称】上田 邦生

(74)【代理人】

【識別番号】100142789

【弁理士】

【氏名又は名称】柳 順一郎

(74)【代理人】

【識別番号】100201466

【弁理士】

【氏名又は名称】竹内 邦彦

(72)【発明者】

【氏名】ステファンズ， ドンポール

(72)【発明者】

【氏名】コーエン， ネイル

(57)【要約】

ストレージクラスタ内のデータオブジェクトを管理する技術であって、データオブジェクトを該データオブジェクト内の境界において複数の部分に分割することを含む。この技術は、さらに、データオブジェクトの部分を、個別に処理可能なユニットを提供するセグメントに変換することと、そこに格納するために、ストレージクラスタの複数のコンピューティングノードにセグメントを分配することとを含む。
【選択図】図２

【特許請求の範囲】

【請求項1】

データオブジェクトを、該データオブジェクト内の境界において複数の部分に分割し、前記境界が、前記データオブジェクトの種類に関連する該データオブジェクトの処理可能なユニット間のセパレータを提供することと、
前記データオブジェクトの種類と同じ種類の処理可能なユニットを個別に提供するセグメントに前記部分を変換することと、
前記セグメントを、そこに格納するために、ストレージクラスタの複数のコンピューティングノードに分配することとを含むデータオブジェクトの管理方法。

【請求項2】

前記部分を前記セグメントに変換することが、一組の前記部分のメタデータを追加または変更することを含む請求項１に記載の方法。

【請求項3】

前記メタデータを追加または変更することが、前記データオブジェクトのヘッダメタデータを特定することと、該ヘッダメタデータまたはその変更版を一組の前記部分の各々に追加することとを含む請求項２に記載の方法。

【請求項4】

前記データオブジェクトが、列名を特定するヘッダを有するＣＳＶ（ｃｏｍｍａ－ｓｅｐａｒａｔｅｄ ｖａｌｕｅｓ）ファイルであり、
前記メタデータを追加または変更することが、前記ＣＳＶファイルのヘッダを特定することと、該ヘッダを一組の前記部分の各々に追加することとを含む請求項２に記載の方法。

【請求項5】

前記メタデータを追加または変更することが、前記部分の１つにおいてフッタメタデータを特定することと、該フッタメタデータまたはその変更版を一組の前記部分の各々に追加することとを含む請求項２に記載の方法。

【請求項6】

前記データオブジェクトが、複数の行グループとフッタとを含むＰａｒｑｕｅｔファイルであり、
前記データオブジェクトを分割することが、一組の前記部分の各々に前記行グループの各組を提供することを含み、
前記メタデータを追加または変更することが、一組の前記部分の各々に前記フッタまたはその変更版を追加することを含む請求項２に記載の方法。

【請求項7】

前記メタデータを追加または変更することが、前記セグメントの組の各々にヘッダを追加することをさらに含み、
該ヘッダが、Ｐａｒｑｕｅｔファイルを指定する符号を含み、
前記フッタまたはその変更版を一組の前記部分の各々に追加することが、（ｉ）それぞれの前記部分の前記行グループの組を記述するが他の前記部分の前記行グループを記述しないフッタメタデータを追加し、（ｉｉ）該フッタメタデータの長さを追加し、（ｉｉｉ）前記Ｐａｒｑｕｅｔファイルを指定する符号を追加することを含む請求項６に記載の方法。

【請求項8】

前記データオブジェクトが、複数のフレームを含むビデオファイルまたはストリームであり、
前記データオブジェクトを分割することが、（ｉ）前記ビデオファイルまたは前記ストリーム内のｉフレームを特定することと、（ｉｉ）現在のセグメントの終了を、特定された前記ｉフレームの１フレーム前にあるフレームと定義することと、（ｉｉｉ）次のセグメントの開始を、特定された前記ｉフレームと定義することとを含む請求項１に記載の方法。

【請求項9】

前記データオブジェクトを分割する前に、該データオブジェクトの一組の領域を読み取り、該一組の領域に基づいて前記データオブジェクトのタイプを識別することをさらに含み、
前記データオブジェクトを分割することが、識別された前記タイプの前記データオブジェクトの処理可能なユニットを分離するために用いられるセパレータを前記データオブジェクトから検索することを含む請求項１に記載の方法。

【請求項10】

前記ストレージクラスタによって、分配された処理タスクを実行することをさらに含み、
分配された該処理タスクが、前記ストレージクラスタの複数のそれぞれのコンピューティングノードによって、そこに格納されたそれぞれの前記セグメントまたは該セグメントの組に対して独立して実行される請求項１に記載の方法。

【請求項11】

前記データオブジェクトのセグメントと、各該セグメントが格納されている前記ストレージクラスタ内の位置とを関連付けるオブジェクトメタデータを格納することをさらに含む請求項１０に記載の方法。

【請求項12】

前記オブジェクトメタデータを格納することが、前記データオブジェクトのバイト範囲と前記データオブジェクトの前記セグメントとの間の関連付けを格納することを含む請求項１１に記載の方法。

【請求項13】

分配された前記処理タスクを実行することが、前記オブジェクトメタデータへのアクセスに基づいて、前記処理タスクにより要求されるデータを含む前記セグメントのサブセットを特定することと、前記セグメントのサブセットを格納する前記コンピューティングノードに前記処理タスクを指示し、前記セグメントのサブセットの一部である前記セグメントを格納しない前記コンピューティングノードには指示しないこととを含む請求項１２に記載の方法。

【請求項14】

ゲートウェイによって、複数の前記コンピューティングノードから前記処理タスクの出力を受信することと、該出力を結合して出力データを生成することとをさらに含む請求項１１に記載の方法。

【請求項15】

前記複数のコンピューティングノードから受信した出力が、ある順序で受信され、前記出力を結合することが、受信した順序で前記出力を提供することを含む請求項１４に記載の方法。

【請求項16】

前記ゲートウェイによって複数の前記コンピューティングノードから受信した前記出力は、複数のＲＤＭＡ（リモートダイレクトメモリアクセス）送信によって到来する請求項１５に記載の方法。

【請求項17】

前記データオブジェクトがデータレコードを含み、
前記処理タスクが集計クエリを定義し、該集計クエリの結果として１ｋＢ未満の出力データを返す請求項１１に記載の方法。

【請求項18】

Ｋ個の前記セグメントから生成された修復データのＭ個の要素を使用して、前記コンピューティングノード間に分配されたＫ個の前記セグメントを保護することをさらに含み、Ｍ個の前記要素の各々が、Ｋ個の前記セグメントから選択された前記セグメントのそれぞれのグループ化から計算された前記修復データを格納する複数の範囲を有する請求項１に記載の方法。

【請求項19】

前記修復データのＭ個の前記要素を生成することをさらに含み、該生成することが、Ｋ個の前記セグメントを論理的に配列することと、
一組のＫ個の前記セグメントの各ｉ番目の最短のセグメントについて、
前記修復データの範囲がまだ計算されていない、前記ｉ番目の最短のセグメントの未処理範囲を特定することと、
最短のセグメントとしてそれまでに識別されていないＫ－ｉ番目の他のセグメントを識別することと、
前記ｉ番目の最短のセグメントの未処理の範囲と一致する前記Ｋ－ｉ番目の他のセグメントの対応する範囲を特定することと、
Ｍ個の前記要素の各々のｉ番目の範囲を、前記ｉ番目の最短のセグメントの未処理の範囲と、前記Ｋ－ｉ番目の他のセグメントの対応する範囲とに基づいて計算することとを含む請求項１８に記載の方法。

【請求項20】

前記生成することが、さらに、
前記修復データの範囲がまだ計算されていない、最後のセグメントの未処理の範囲を特定することと、
Ｍ個の前記要素のそれぞれの最後の範囲を、前記最後のセグメントの未処理の範囲のそれぞれのレプリカとして提供することとを含む請求項１９に記載の方法。

【請求項21】

前記部分を前記セグメントに変換することが、第１の部分と第２の部分との間の境界に隣接する第１の部分から第２の部分へデータの領域を複製することを含む請求項１に記載の方法。

【請求項22】

前記部分を前記セグメントに変換することが、第１の部分の最初の領域を、一組の他の部分のそれぞれの最初の領域に複製するすることを含む請求項１に記載の方法。

【請求項23】

ヘッダを使用しない前記データオブジェクトの処理を指定する処理要求を受信することと、
該処理要求に応答して、前記第１の部分の最初の領域を処理するが、一組の前記他の部分のそれぞれの最初の領域は無視することを含む請求項２２に記載の方法。

【請求項24】

前記データオブジェクトを複数の前記部分に分割するときに、より高速な処理を可能にする前記データオブジェクトの前記部分における特徴を特定することと、前記部分が特定された特徴を含むことを示すために、前記部分に関連するメタデータを更新することとをさらに含む請求項１に記載の方法。

【請求項25】

メモリに結合された一組の処理ユニットを含む制御回路を備え、
該制御回路が、
データオブジェクトを、該データオブジェクト内の境界において複数の部分に分割し、前記境界が、前記データオブジェクトのタイプに従って、前記データオブジェクトの処理可能なユニット間のセパレータを提供し、
前記データオブジェクトのタイプと同じタイプの処理可能なユニットを個々に提供するセグメントに前記部分を変換し、
前記セグメントを、そこに格納するために、ストレージクラスタの複数のコンピューティングノードに分配するように構成されかつ配置されたコンピュータ化された装置。

【請求項26】

コンピュータ化された装置の制御回路によって実行されると、該コンピュータ化された装置にデータオブジェクトを管理する方法を実行させる命令を有する一組の非一時的なコンピュータ読み取り可能な媒体を含むコンピュータプログラム製品であって、
前記方法が、
データオブジェクトを、該データオブジェクト内の境界において複数の部分に分割し、前記境界が、前記データオブジェクトのタイプに従って、前記データオブジェクトの処理可能なユニット間にセパレータを提供することと、
前記データオブジェクトのタイプと同じタイプの処理可能なユニットを個々に提供するセグメントに前記部分を変換することと、
前記セグメントを、そこに格納するために、ストレージクラスタの複数のコンピューティングノードに分配することとを含むコンピュータプログラム製品。

【請求項27】

データオブジェクトを管理する方法であって、
前記データオブジェクトを複数のセグメントに分割することと、
該セグメントをストレージクラスタの複数のコンピューティングノードに分配することと、
前記ストレージクラスタによって分配された処理タスクを実行することであって、分配された前記処理タスクが、前記ストレージクラスタの複数のそれぞれの前記コンピューティングノードによって、そこに格納されたそれぞれの前記セグメントまたは該セグメントの組に対して独立して実行されることとを含む方法。

【請求項28】

前記データオブジェクトのオブジェクトメタデータを格納することをさらに含み、前記オブジェクトメタデータが、前記セグメントを前記データオブジェクトのそれぞれの部分と関連付ける請求項２７に記載の方法。

【請求項29】

分配された前記処理タスクを実行することが、
前記データオブジェクトの前記オブジェクトメタデータにアクセスし、前記データオブジェクトの前記セグメントを格納する前記コンピューティングノードをそこから特定することと、
特定された前記コンピューティングノードに、それぞれの前記セグメントに対して前記処理タスクを実行するように指示することとを含む請求項２８に記載の方法。

【請求項30】

前記オブジェクトメタデータを格納することが、前記データオブジェクトのバイト範囲と前記データオブジェクトの前記セグメントとの間の関連付けを格納することを含む請求項２８に記載の方法。

【請求項31】

分配された前記処理タスクを実行することが、
前記オブジェクトメタデータへのアクセスに基づいて、前記処理タスクによって必要とされるデータを含む前記セグメントのサブセットを特定することと、
前記セグメントのサブセットを記憶する前記コンピューティングノードに前記処理タスクを指示し、前記セグメントのサブセットの一部である前記セグメントを格納しない前記コンピューティングノードには前記処理タスクを指示しないこととを含む請求項２８に記載の方法。

【請求項32】

データセグメントを分割することが、別個のレコードまたは領域の間の前記データオブジェクト内の境界を識別することを含み、
一組の前記セグメントに対してセグメントメタデータを作成することであって、該セグメントメタデータが、各前記セグメントを前記データオブジェクトと同じタイプの独立に処理可能なユニットに変換するコンテンツを含むことと、
各前記セグメントを前記コンピューティングノード間で分配するときに、各前記セグメントにおいて前記セグメントメタデータを提供することとを含む請求項２７に記載の方法。

【請求項33】

前記セグメントメタデータを作成することが、
前記データオブジェクトのヘッダを特定することと、
一組の前記セグメントの各々において前記ヘッダまたはその変更版を提供することとを含む請求項３２に記載の方法。

【請求項34】

前記データオブジェクトが、ＣＳＶ（ｃｏｍｍａ－ｓｅｐａｒａｔｅｄ ｖａｌｕｅｓ）ファイルであり、
前記ヘッダまたはその変更版を提供することが、一組の前記セグメントのそれぞれの先頭に前記ヘッダを提供することを含む請求項３３に記載の方法。

【請求項35】

前記セグメントメタデータを作成することが、
前記データオブジェクトのフッタを特定することと、
一組の前記セグメントの各々において、前記フッタまたはその変更版を提供することとを含む請求項３２に記載の方法。

【請求項36】

前記データオブジェクトが複数の行グループを含むＰａｒｑｕｅｔファイルであり、
前記データオブジェクトを分割することが、一組の前記セグメントの各々においてそれぞれの前記行グループの組を提供することを含み、前記セグメントメタデータを作成することが、
一組の前記セグメントの各々において前記フッタを記憶することであって、該フッタが、（ｉ）それぞれの前記セグメントにおける一組の前記行グループを記述し、他の前記セグメントにおける前記行グループを記述しないフッタメタデータと、（ｉｉ）該フッタメタデータの長さと、（ｉｉｉ）前記Ｐａｒｑｕｅｔファイルを指定する符号とを含む請求項３５に記載の方法。

【請求項37】

前記セグメントメタデータを作成することが、前記セグメントの組の各々について、前記セグメントの開始時にヘッダとして符号を提供することをさらに含む請求項３６に記載の方法。

【請求項38】

前記セグメントの組の各々におけるそれぞれの前記行グループの組を提供することが、前記セグメントの組の各々において単一の前記行グループを提供することを含む請求項３６に記載の方法。

【請求項39】

ゲートウェイによって、複数の前記コンピューティングノードから前記処理タスクの出力を受信することと、出力データを生成するために前記出力を結合することとをさらに含む請求項２７に記載の方法。

【請求項40】

複数の前記コンピューティングノードから受信した出力が、ある順序で受信され、前記出力を結合することが、受信された順序で前記出力を提供する請求項３９に記載の方法。

【請求項41】

受信された順序で前記出力を提供することが、複数の前記コンピューティングノードの異なるものからの前記出力をインターリーブ方式で前記出力データに挿入することを含む請求項４０に記載の方法。

【請求項42】

複数の前記コンピューティングノードから前記ゲートウェイによって受信された前記出力が、複数のＲＤＭＡ（リモート・ダイレクト・メモリ・アクセス）送信によって到来する請求項３９に記載の方法。

【請求項43】

前記データオブジェクトがデータレコードを含み、前記処理タスクが、集計クエリの結果として１ｋＢ未満の前記出力データを返す集計クエリを定義する請求項３９に記載の方法。

【請求項44】

データオブジェクトを管理する方法であって、
前記データオブジェクトを複数のセグメントに分割することであって、該セグメントの少なくともいくつかが互いに異なる長さを有することと、
前記セグメントをストレージクラスタの複数のコンピューティングノードに分配することと、
Ｋ個の前記セグメントから生成された修復データのＭ個の要素を使用して、Ｋ個の前記セグメントを保護することであって、Ｍ個の前記要素の各々が、Ｋ個の前記セグメントから選択された前記セグメントのそれぞれのグループ化から計算された前記修復データを格納する複数の範囲を有することとを含む方法。

【請求項45】

Ｍ個の前記要素のそれぞれの第１の範囲が、Ｋ個の前記セグメントの全てのＫから計算され、
Ｍ個の前記要素の第２の範囲が、Ｋ個の前記セグメントの内のＫ－１個から計算され、
Ｍ個の前記要素の第３の範囲が、Ｋ個の前記セグメントの内のＫ－２個から計算される請求項４４に記載の方法。

【請求項46】

Ｍ個の前記要素の第４の範囲が、Ｋ個の前記セグメントの内の単一のものだけに基づく請求項４５に記載の方法。

【請求項47】

修復データのＭ個の前記要素を生成することをさらに含み、
該生成することが、
Ｋ個の前記セグメントを論理的に整列させることと、
Ｋ個の前記セグメントの内の最短のセグメントおよびＫ－１個の他のセグメントを識別するステップと、
前記Ｋ－１個の他のセグメントにおいて前記最短のセグメントと整列する対応する範囲を特定することと、
前記最短のセグメントと、前記Ｋ－１個の他のセグメントの対応する範囲とに基づいて、Ｍ個の前記要素のそれぞれの第１の範囲を計算することとを含む請求項４４に記載の方法。

【請求項48】

修復データのＭ個の前記要素を生成することをさらに含み、
該生成することが、Ｋ個の前記セグメントを論理的に整列することと、
Ｋ個の前記セグメントの組の各ｉ番目の最短セグメントに対して、
前記修復データの範囲がまだ計算されていない、前記ｉ番目の最短のセグメントの未処理範囲を特定することと、
前記最短のセグメントとして以前に識別されなかったＫ－ｉ個の他のセグメントを特定することと、
前記ｉ番目の最短のセグメントの未処理の範囲と一致する、前記Ｋ－ｉ個の他のセグメントの対応する範囲を特定することと、
Ｍ個の前記要素の各々のｉ番目の範囲を、前記ｉ番目の最短のセグメントの未処理の範囲と、前記Ｋ－ｉ個の他のセグメントの対応する範囲とに基づいて計算することとを含む請求項４４に記載の方法であって、

【請求項49】

前記生成することが、さらに、
最後のセグメントの、まだ前記修復データの範囲が計算されていない未処理範囲を特定することと、
Ｍ個の前記要素のそれぞれの最後の範囲を、前記最後のセグメントの未処理範囲のそれぞれのレプリカとして提供することとを含む請求項４８に記載の方法。

【請求項50】

Ｋ個の前記セグメントが、前記データオブジェクトのデータを含む第１の修復グループを形成し、前記データオブジェクトを分割するときに形成される前記複数のセグメントが、それぞれがＫ個以下の前記セグメントを含む一組の追加の修復グループを含む請求項４４に記載の方法。

【請求項51】

前記ストレージクラスタの複数の前記コンピューティングノードに前記セグメントを分配することが、異なるそれぞれの前記修復グループの複数の前記セグメントを前記ストレージクラスタの単一の前記コンピューティングノードに分配することを含む請求項５０に記載の方法。

【請求項52】

前記ストレージクラスタの複数の前記コンピューティングノードに前記セグメントを分配することが、前記ストレージクラスタの単一の前記コンピューティングノードに単一の前記修復グループの２つの前記セグメントを分配しないことを含む請求項５０に記載の方法。

【請求項53】

（ｉ）前記データオブジェクトのサイズ、（ｉｉ）前記コンピューティングノードによって効率的に処理できる所望の最大セグメントサイズ、（ｉｉｉ）前記セグメントの数Ｋ、および（ｉｖ）前記修復グループの数Ｒに基づいて、前記セグメントの目標最小サイズを確立することをさらに含む請求項５０に記載の方法。

【請求項54】

前記データオブジェクトを分割することが、
前記セグメントの開始点を定義することと、
目標最小サイズに達した後に、開始点から前方にスキャンして、前記データオブジェクトの第１の境界として前記セグメントの終了点を特定することと、
前記開始点から始まり前記終了点で終わる前記データオブジェクトの部分に基づいて前記セグメントの範囲を定義することとを含む請求項４４に記載の方法。

【請求項55】

前記第１の境界が、
データベースレコードの終了点、
ログファイルまたはＣＳＶファイルにおいて区切られた改行、
Ｐａｒｑｕｅｔファイルにおける行グループの終端、または、
ビデオファイルまたはストリームのｉフレームの直前に先行するフレームの内の１つに対応する請求項５４に記載の方法。

【発明の詳細な説明】

【関連出願への相互参照】

【0001】

本出願は、２０２０年５月１２日に出願された米国仮出願第６３／０２３，７９１号の利益を主張し、その内容および教示は、参照によりその全体が本明細書に組み込まれる。

【背景技術】

【0002】

データ処理および保護は、安価なプロセッサおよび記憶媒体の利用可能性の増加とともに、変革的な変化を遂げてきた。ユーザは現在、データをローカルに処理および格納するか、またはネットワークを介して接続されたサーバ、コンピューティングクラスタまたはクラウドにデータを格納するかの選択肢を有する。さらに、クラウドコンピューティングの選択肢には、パブリッククラウドとプライベートクラウドとの両方が含まれる。

【0003】

ビッグデータの時代が到来し、ユーザは、これまで以上に大量のデータオブジェクトを格納し、処理することを望んでいる。例えば、表形式データ、ツリーベースのデータ、およびオーディオおよび／またはビデオデータが、ギガバイトレンジまたはそれ以上のサイズに達することは、珍しくない。このような大きなデータオブジェクトを処理、保護、および格納することは、独自の課題を提起する。

【0004】

一般的なアプローチは、大きなオブジェクトを別々の部分に分割し、その部分をそれぞれのコンピュータに格納することである。プログラムは、オブジェクト内のバイト境界を識別し、等しいサイズまたはそれに近いサイズの部分を生成することによって、オブジェクトを分割することができる。データオブジェクトが一旦分散して格納された後にデータ処理を行うために、コンピュータは、元のオブジェクトの特定の部分または部分のグループを集め、集められた部分に対して所望の処理タスクを実行し、結果を生成することができる。

【発明の概要】

【0005】

残念ながら、上述した分散型アプローチは非効率的である場合がある。例えば、大きなデータオブジェクトを等しいまたはほぼ等しい部分に分割することは、構造的特徴を無視することになり、異なるデータ部分間またはデータ部分中に依存性を導入することになる。簡単な例として、何行もの表形式データを含むデータオブジェクトを想定する。このオブジェクトを分割して同じ大きさの部分を作ることは、行を途中で切断することを意味する。そのため、切断された行へのアクセスに関する後続のクエリは、データオブジェクトの２つの部分、すなわち、１つは行の先頭を格納し、１つは行の末尾を格納する２つの部分にアクセスする必要がある場合がある。これら２つの部分は、典型的には、ネットワーク上の異なるコンピュータに格納されることがある。

【0006】

上記の例を続けると、さらに、（切断された行の両方の部分を含む）両方の部分を要求者またはいくつかの他のノードに転送し、そこで部分が再組み立てされ、クエリを実行する必要がある場合がある。これらの行為は、ネットワークを介したデータの大きな複製を伴うので、大きな非効率をもたらす。

【0007】

上記に加えて、上述したアプローチは、コンテンツに気づかない場合がある。例えば、データオブジェクトの分割された部分は、全体としてデータオブジェクトとの関連性を失う可能性がある。表形式のデータでは、フィールド名が欠落する場合（例えば、行データのみが格納される場合）がある。このように、分散オブジェクトから意味のあるデータを抽出するためには、異なるコンピュータに多くのネットワークアクセスを行い、所望の処理タスクを完了するのに必要な全てのピースを収集することが必要になる場合がある。必要なのは、大きなデータオブジェクトを扱う、より効率的な方法である。

【0008】

この必要性に少なくとも部分的に対処するために、ストレージクラスタにおいてデータオブジェクトを管理するための改良された技術は、データオブジェクトをデータオブジェクト内の境界において複数の部分に分割することを含む。この技術は、データオブジェクトの部分を、個別に処理可能なユニットを提供するセグメントに変換することと、そこに格納するために、ストレージクラスタの複数のコンピューティングノードの間でセグメントを分配させることとをさらに含む。

【0009】

有利には、セグメントを個別に処理可能な単位として提供することは、データオブジェクトに対する処理タスクの実行に関連する作業負荷を、データオブジェクトのセグメントをローカルに格納するコンピューティングノードに効率的にプッシュダウンできることを意味する。したがって、この技術は、各コンピューティングノードが、そこに格納されたデータオブジェクトの１以上のセグメントのみに対して処理タスクを実行する、真の並列処理を可能にする。また、従来の方式と比較して、ネットワークトラフィックを大幅に減少させることができる。例えば、コンピューティングノードのローカルなストレージへの高速接続は、全体的な効率を大幅に向上させる。さらに、セグメントの独立性は、処理タスクを完了するためにコンピューティングノード間の通信（依存関係の解消など）をほとんど必要としないことを意味する。

【0010】

特定の実施形態は、データオブジェクトを管理する方法に向けられている。
本方法は、データオブジェクトをデータオブジェクト内の境界において複数の部分に分割することを含み、境界は、データオブジェクトのタイプに従ってデータオブジェクトの処理可能なユニット間のセパレータを提供する。本方法はさらに、部分を、データオブジェクトのタイプと同じタイプの個別に処理可能なユニットを提供するセグメントに変換することと、そこに格納するために、セグメントをストレージクラスタの複数のコンピューティングノードの間で分配することとを含む。

【0011】

他の実施形態は、データオブジェクトを管理する方法に向けられている。この方法は、データオブジェクトを複数のセグメントに分割することと、セグメントをストレージクラスタの複数のコンピューティングノードの間で分配することと、ストレージクラスタによって分散処理タスクを実行することとを含む。分散処理タスクは、ストレージクラスタの複数の各コンピューティングノードによって、そこに格納された各セグメントまたはセグメントセットに対して独立に実行される。

【0012】

さらに他の実施形態は、データオブジェクトを管理する方法に向けられている。本方法は、データオブジェクトを複数のセグメントに分割することを含み、セグメントの少なくともいくつかは、互いに異なる長さを有する。本方法はさらに、セグメントをストレージクラスタの複数のコンピューティングノードに分配することと、Ｋ個のセグメントから生成された修復データのＭ個の要素を使用してＫ個のセグメントを保護することとを含み、Ｍ個の要素の各々は、Ｋ個のセグメントから選択されたセグメントのそれぞれのグループ化から計算された修復データを格納する複数の範囲を有している。

【0013】

追加の実施形態は、上述した方法のいずれかなどのデータオブジェクトを管理する方法を実行するように構築および配置されたコンピュータ化された装置に向けられている。さらに他の実施形態は、コンピュータプログラム製品に向けられている。コンピュータプログラム製品は、コンピュータ化された装置の制御回路上において実行されると、コンピュータ化された装置に、上述した方法のいずれかのようなデータオブジェクトを管理する方法を実行させる命令を格納する。

【0014】

前述の概要は、読者が本明細書に提示された例示的な特徴を容易に把握するのを助けるために例示目的で提示されているが、この概要は、必須の要素を規定すること、または本明細書の実施形態を何らかの方法で制限することを意図していない。上述した特徴は、技術的に意味をなす任意の方法で組み合わせることができ、そのような組み合せが明示的に特定されるかどうかにかかわらず、全てのそのような組み合せが本明細書に開示されることを意図していることを理解されたい。

【図面の簡単な説明】

【0015】

上記および他の特徴および利点は、同様の参照符号が異なる図を通して同じまたは同様の部分を指している添付図面に示されるような特定の実施形態の以下の説明から明らかになるであろう。

【図1】改良された技術の実施形態が実践され得る例示的な環境のブロック図である。

【図2】図１のゲートウェイ装置の例示的な特徴をさらに詳細に示すブロック図である。

【図3A】表形式データを含むデータオブジェクトを分割するための例示的な配置を示すブロック図である。

【図3B】表形式データを含むデータオブジェクトを分割するための例示的な配置を示すブロック図である。

【図4A】Ｐａｒｑｕｅｔファイルを含むデータオブジェクトを分割するための例示的な配置を示すブロック図である。

【図4B】Ｐａｒｑｕｅｔファイルを含むデータオブジェクトを分割するための例示的な配置を示すブロック図である。

【図5A】ビデオデータを含むデータオブジェクトを分割するための例示的な配置を示すブロック図である。

【図5B】ビデオデータを含むデータオブジェクトを分割するための例示的な配置を示すブロック図である。

【図6】図１の環境において分散処理タスクを実行するための例示的な配置を示すブロック図である。

【図7】データオブジェクトの複数のセグメントをサイズが小さくなる順に配置する例を示すブロック図である。

【図8】図７に示されたセグメントを消失訂正符号化するための配置例を示すブロック図である。

【図9】データオブジェクトから生成されたセグメントから形成された複数の修復グループを示すブロック図である。

【図10】セグメントの所望の目標サイズを決定する方法の一例を示すフローチャートである。

【図11】図１および図６の環境において使用され得る例示的なコンピューティングノードのブロック図である。

【図12】一実施形態に従うデータオブジェクトを管理する例示的な方法を示すフローチャートである。

【図13】別の実施形態に従うデータオブジェクトを管理する例示的な方法を示すフローチャートである。

【図14】さらに別の実施形態に従うデータオブジェクトを管理する例示的な方法を示すフローチャートである。

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

【0016】

改良された技術の実施形態を以下に説明する。このような実施形態は、特定の特徴および原理を説明するために例示的に提供されるが、限定することを意図していないことを理解されたい。

【0017】

ストレージクラスタにおいてデータオブジェクトを管理するための改良された技術は、データオブジェクトをデータオブジェクト内の境界において複数の部分に分割することを含む。本技術は、データオブジェクトの部分を、個別に処理可能なユニットを提供するセグメントに変換することと、その中に格納するために、ストレージクラスタの複数のコンピューティングノードにセグメントを分配することとをさらに含む。

【0018】

この出願は、複数の実施形態を開示する。１つの実施形態は、ストレージクラスタにおいて分配されたストレージのためにデータオブジェクトを複数の部分に分割することに向けられている。別の実施形態は、ストレージクラスタによる分散処理タスクの実行に向けられている。さらに別の実施形態は、ストレージクラスタに格納されたデータオブジェクトのデータを保護することに向けられている。これらの実施形態は、以下の例で示し、説明するように、単一のシステムのそれぞれの態様として実現されてもよい。
あるいは、実施形態のうちの任意の１つをサポートする実装が他の実施形態もサポートする必要がないように、実施形態は独立して実施されてもよい。

【0019】

図１は、改良された技術の実施形態が実践され得る例示的な環境１００を示す。図示されるように、ゲートウェイ１１０は、ネットワーク１４０を介してストレージクラスタ１３０の複数のコンピューティングノード１２０にアクセスし、ストレージクラスタ１３０とクライアント／ユーザとの間のインターフェースとして機能するように構成される。ネットワーク１４０は、ローカルエリアネットワーク（ＬＡＮ）、ワイドエリアネットワーク（ＷＡＮ）、インターネット、またはコンピュータ間のデジタル通信をサポートする任意の他のタイプのネットワークまたはネットワークの組み合せを含んでもよい。ゲートウェイ１１０は、コンピュータまたは他の演算装置（例えば、サーバ、ワークステーション、タブレット、スマートフォン、パーソナルデータアシスタント、ゲーム機、セットトップボックス等）であってよく、それ自身のネットワークインターフェース、プロセッサ、およびメモリを備えていてもよい。いくつかの例では、ゲートウェイ１１０は、ストレージクラスタ１３０のコンピューティングノード１２０として提供されてもよい。ストレージクラスタ１３０が数百以上のような多数のノード１２０を含んでいてもよいという理解のもと、複数のコンピューティングノード１２０（本明細書では「ノード」とも言う。）１２０－１から１２０－Ｎが示されている。各ノード１２０は、プログラムを実行するための１つまたは複数のプロセッサおよびメモリ、並びに１つ以上のネットワークインターフェース（例えば、ネットワークインターフェースカード）、および１つ以上のソリッドステートドライブ（ＳＳＤ）、磁気ディスクドライブ、および／または同様のもののような永続的ストレージを含んでいる。ストレージクラスタ１３０のノード１２０は、ネットワーク１４０を介して、または専用ネットワーク（例えば、別のローカルエリアネットワーク；図示せず）を介して、または他の手段によって相互接続されていてもよい。本明細書の目的のために、ストレージクラスタ１３０の内部の任意のネットワークは、ネットワーク１４０の一部であると見なされる。

【0020】

好ましくは、各ノード１２０は、そのそれぞれの永続的なストレージへの１つ以上の高速接続を有する。例えば、ノード１２０とそのストレージ装置（例えば、ＳＳＤ）との間の接続は、ネットワーク１４０を介したノード間の接続を１桁以上上回る帯域幅を有していてもよい。

【0021】

一例では、ストレージクラスタ１３０は、オブジェクトストアとして構成され、これは、ＡＷＳ（Ａｍａｚｏｎ Ｗｅｂ Ｓｅｒｖｉｃｅｓ）Ｓ３（シンプルストレージサービス）、Ｍｉｃｒｏｓｏｆｔ Ａｚｕｒｅ Ｄａｔａ Ｌａｋｅ、および／またはＧｏｏｇｌｅ Ｃｌｏｕｄ Ｓｔｏｒａｇｅなどの市販のクラウドベースのオブジェクトストアと互換性があってもよい。特定の例においては、ストレージクラスタ１３０は、Ｓ３互換のオブジェクトストアとして構成される。この目的のために、各ノード１２０は、ノード１２０がオブジェクトストアのメンバーとして参加することを可能にするＡＰＩ（アプリケーションプログラムインターフェース）１２２を含んでいてもよい。

【0022】

クラスタ１３０は、ノード１２０がネットワーク接続されている、建物の一室または複数の部屋を占めるデータセンタに実装されてもよい。他の実装は、複数の建物にまたがっていてもよく、メトロクラスタの配置が実現可能である。

【0023】

他の例では、ストレージクラスタ１３０は、例えば、そこに提供される物理的な装置または仮想的な装置を使用するクラウドサービス１５０内に実装されてもよい。例えば、ストレージクラスタ１３０の全体は、完全にクラウドサービス１５０内に配置されてもよい。

【0024】

さらに別の例として、クラウドサービス１５０は、データの一次リポジトリとして機能し、ストレージクラスタ１３０は、クラウドサービス１５０のキャッシュとして機能してもよい。したがって、ストレージクラスタ１３０は、一般的にアクセスされるデータを格納し得るが、典型的には、クラウドサービス１５０から利用可能な全てのデータを格納するわけではない。

【0025】

実装は、個人、小規模な組織、および／または企業に適しており、ＳａａＳ（Ｓｏｆｔｗａｒｅ ａｓ ａ Ｓｅｒｖｉｃｅ）モデルに従って、または他のモデルに従って提供されてもよい。実施形態は、１００メガバイトまたはそれ以上の範囲のサイズを有し得る大きなデータオブジェクトを管理するのに特に適している。この特徴は、実施形態は、データレイクを含むものなどのビッグデータアプリケーションによく適合する。しかし、実施形態は、任意の特定のユーザ、サービスモデル、データサイズ、またはアプリケーションに限定されないことを理解されたい。

【0026】

例示的な動作において、ゲートウェイ１１０（ストレージクラスタ１３０の一部であっても、ストレージクラスタ１３０から分離されていてもよい。）は、ストレージクラスタ１３０によって、管理されるべき１つまたは複数のデータオブジェクト１６０にアクセスする。データオブジェクト１６０は、クラウドサービス１５０に、例えば、バケットまたはブロブ内に存在してもよく、または、１つ以上の別個のソースによって提供されてもよい。例えば、データオブジェクト１６０は、データオブジェクト１６０をデータログまたは進行中の活動の他の記録として生成し得る産業または科学的プロセスなどのリアルタイムの活動によって生成されてもよい。データオブジェクト１６０は、ファイル、ストリーム、メモリ範囲として、または他の任意の方法によって提供されてもよい。

【0027】

データオブジェクト１６０は、特定のオブジェクトタイプに従って構造化されてもよい。例えば、データオブジェクト１６０は、ＣＳＶ（カンマ区切り値）またはログファイルなどの表形式オブジェクトとして、ＪＳＯＮ（ＪａｖａＳｃｒｉｐｔ Ｏｂｊｅｃｔ Ｎｏｔａｔｉｏｎ）またはＸＭＬ（ｅｘｔｅｎｓｉｂｌｅ ｍａｒｋｕｐ ｌａｎｇｕａｇｅ）文書などのツリーベースのオブジェクトとして、Ａｐａｃｈｅ Ｐａｒｑｕｅｔファイルなどの列指向オブジェクトとして、ビデオファイルまたはストリームとして、オーディオファイルまたはストリームとして、または画像のコレクションとして提供されてもよい。特定のタイプのデータが特に示され、および／または説明されているが、実施形態は、あらゆるタイプのデータを包含することを意図しており、図示され、および／または説明されたものは、動作原理を説明するために使用される具体例を提供するに過ぎないことを理解すべきである。

【0028】

データオブジェクト１６０の管理を開始するために、ゲートウェイ１１０は、データオブジェクトをスキャン、例えば、データオブジェクトの先頭から開始して前方に進行してもよい。通常、ゲートウェイ１１０は、オブジェクトに最初にアクセスするとき、データオブジェクトのタイプを記憶しておらず、オブジェクト１６０のタイプを識別するために、オブジェクトの初期スキャンを実行してもよい。スキャンは、データオブジェクトの一連の領域、典型的にはオブジェクトの先頭をサンプリングし、特定のオブジェクトタイプに固有のシーケンスまたは文字を検索することを含んでもよい。例えば、ＣＳＶファイルおよびログファイルは、典型的には、レコードの終了を示すために改行文字を使用し、隣接するフィールドを分離するためにカンマ、スペース、または他の文字を使用することができる。いくつかのデータオブジェクトは、オブジェクトのタイプを直接的に識別するヘッダを含むことがある。例えば、Ｐａｒｑｕｅｔファイルは、いわゆる「マジックナンバー」を指定する４バイトのヘッダで始まり、このヘッダで、Ｐａｒｑｕｅｔファイルとしてファイルを識別するコード「ＰＡＲ１」が提供される。ほとんどのファイルタイプは、それほど苦労せずに識別できるような明確な表示を提供する。しかし、中には識別が困難なものもある。そのような容易に識別できないタイプを認識したい場合には、機械学習または他のタイプの人工知能を含む、より高度なアルゴリズムが適用されてもよい。

【0029】

ゲートウェイ１１０がデータオブジェクト１６０のタイプを識別すると、ゲートウェイ１１０は、データオブジェクト１６０の複数の部分への分割を開始することを進行してもよい。例えば、ゲートウェイ１１０は、データオブジェクトの隣接する処理可能なユニット間のセパレータを提供するデータオブジェクトにおける境界を検索してもよい。境界の正確な性質は、あるオブジェクトタイプと別のオブジェクトタイプとで異なっていてもよい。例えば、ＣＳＶファイルは、境界を識別するために改行文字を使用してもよく、一方、ビデオファイルまたはストリームは、Ｉフレーム（ｉｎｔｒａ－ｃｏｄｅｄ ｐｉｃｔｕｒｅｓ）を使用してもよい。いくつかのオブジェクトタイプは、埋め込まれたメタデータを使用して境界を特定する。例えば、Ｐａｒｑｕｅｔファイルは、隣接する行グループ間の境界を識別するフッタを含んでいる。

【0030】

データオブジェクトの「処理可能なユニット」は、他の処理可能なユニットに対する依存性をほとんど含まないという意味で、独立した処理に従うことができる領域である。したがって、データオブジェクトを処理可能な複数のユニットに分割することは、ストレージクラスタ１３０のノード１２０による効率的な並列処理を促進する。

【0031】

分割は、分割された部分の独立した処理を促進する最初のステップであるが、最適な性能のためには必ずしも十分ではない。例えば、分割された部分は、データオブジェクト１６０の他の部分への依存性を保持する原因となる特定のメタデータ（例えば、ヘッダ、フッタ、または他のコンテンツ）を欠いている場合がある。したがって、ゲートウェイ１１０は、好ましくは、分割された部分をセグメント１７０に変換する追加のステップを実行する。一例において、変換されたセグメント１７０は、データオブジェクト１６０と同じタイプの完全な自己完結型オブジェクトであるかのように処理することができる。

【0032】

セグメント１７０は、それらが作成された部分と類似しているが、他の部分への依存性を低減または排除するように変更される。例えば、ＣＳＶファイルの最初の部分がヘッダを含み、後続の部分が含まない場合には、ゲートウェイ１１０は、最初の部分のヘッダを後続の部分から形成されるセグメント１７０の各々に複製してもよい。このようにして、各セグメント１７０は、それ自身のヘッダを有し、独立したＣＳＶファイルであるかのように処理することができる。他のオブジェクトタイプについても対応する変更を行うことができ、その変更の詳細はオブジェクトタイプに依存する。様々な例が以下に提供される。

【0033】

このようにセグメント１７０がデータオブジェクト１６０と同じタイプの、独立して処理可能なユニットとして形成されると、ゲートウェイ１１０はセグメント１７０をストレージクラスタ１３０の種々のノード１２０に分配してもよく、これらのノード１２０はセグメントを、そこに、例えば、各ノード１２０にローカルに接続された永続的なストレージに格納する。セグメントの位置を追跡するために、ゲートウェイ１１０は、オブジェクトメタデータ（オブジェクトＭＤ）１１２を更新してもよい。

【0034】

図１の拡大図に示すように、オブジェクトメタデータ１１２は、ストレージクラスタ１３０の動作を容易にするオブジェクト固有の情報を含む。このようなオブジェクトメタデータ１１２は、以下の要素を含んでもよい。例えば、
－ ＯｂｊＩＤ：オブジェクト識別子であり、ストレージクラスタ１３０のネームスペース内で一意であることが好ましい。
－ ＯｂｊＴｙｐｅ：ＣＳＶ、ＪＳＯＮ、ＸＭＬ、Ｐａｒｑｕｅｔなどのようなデータオブジェクト１６０の決定されたタイプである。
－ ＳｅｇＩＤ：オブジェクトの一部から生成されたセグメント１７０の識別子である。ストレージクラスタ１３０のネームスペース内で一意であることが好ましい。
－ ＢｙｔｅＲｎｇ：現在のセグメントに含まれるデータオブジェクト１６０のバイト範囲である。開始バイト位置と終了バイト位置とを指定する一対の値として（または、開始バイト位置と長さとして）表現されてもよい。
－ ＲｏｗＲｎｇ：現在のセグメントに含まれるデータオブジェクト１６０の行範囲である。表形式データおよび行で提供される他のタイプのデータに関連する。
－ Ｆｅａｔｕｒｅｓ：セグメントにおいて検出された、後の処理に関連する可能性のある特徴である。セグメント単位で提供されてもよい。
単一レベルの構造として示されているが、オブジェクトメタデータ１１２は、階層構造を含む任意の適切な方法で配置されてもよい。また、オブジェクトメタデータ１１２の範囲は、提供された例に限定されない。実際、オブジェクトメタデータ１１２は、ストレージクラスタ１３０の動作またはそこで実行され得る処理タスクを容易にする任意の情報を格納してもよい。

【0035】

いくつかの例において、オブジェクトメタデータ１１２は、信頼性を向上するために冗長的に格納される。例えば、オブジェクトメタデータ１１２は、例えば、マルチウェイミラーおよび／または他のＲＡＩＤ（Ｒｅｄｕｎｄａｎｔ Ａｒｒａｙ ｏｆ Ｉｎｄｅｐｅｎｄｅｎｔ Ｄｉｓｋｓ）または消失訂正符号化技術を使用して、ストレージクラスタ１３０の複数のノード１２０に格納されてもよい。また、本明細書においてゲートウェイ１１０に帰着する活動は、任意の数のコンピュータによって実行されてもよく、そのようなコンピュータは、ストレージクラスタ１３０のノード１２０を含んでいてもよい。例えば、ストレージクラスタ１３０の特定のノードは、ロードバランサとして指定されてもよく、セグメント１７０がクラスタのノード間で分配されるときに、ノード１２０の作業負荷を考慮に入れてもよい。

【0036】

図１にさらに示されるように、コンピューティングノード１２０は、各ノード１２０によって格納されたセグメント１７０を記述するセグメントメタデータ（ＳＭＤ）１２４を記憶してもよい。セグメントメタデータ１２４の例は、以下の要素を含んでもよい。
－ ＳｅｇＩＤ：コンピューティングノード１２０に記憶されているセグメントの一意の識別子である。
－ ＨＭＤ：コンピューティングノード１２０に格納されたセグメントの一部を形成するヘッダメタデータである。現在のセグメントの独立した処理を促進するために、現在のセグメントと共に含まれる、同じオブジェクトから派生した別のセグメントに元々あるヘッダメタデータの複製であってもよい。
－ ＦＭＤ：コンピューティングノード１２０に格納されるセグメントの一部を形成するフッタメタデータである。現在のセグメントの独立した処理を促進するために、現在のセグメントと共に含まれる、同じオブジェクトから派生した別のセグメントに元々あるフッタメタデータの複製であってもよい。
－ Ｌｏｃ：ノード１２０が現在のセグメントにアクセスする場所である。ディスクドライブおよび論理ブロックアドレス（ＬＢＡ）、ボリューム、ファイル、集合などの好適な方法、またはノード１２０がそのデータにアドレス指定する際に使用する他の任意の方法で表現される。

【0037】

オブジェクトメタデータ１１２と同様に、セグメントメタデータ１２４も、信頼性を向上するために冗長に格納されてもよい。いくつかの例において、ノード１２０は、メタデータが記述するセグメント１７０とともに、セグメントメタデータ１２４を格納してもよい。例えば、セグメントＡのためのセグメントメタデータはセグメントＡとともに格納されてもよい。同様に、セグメントＢのためのセグメントメタデータは、セグメントＢとともに格納されてもよい。したがって、セグメントメタデータ１２４は、セグメント１７０自体が保護されるのと同じ方法で保護されてもよい。セグメント保護の種々の例は、本明細書において以下に説明される。

【0038】

図２は、ゲートウェイ１１０の例示的な特徴をさらに詳細に示している。この例では、ゲートウェイ１１０が示された機能自体を実行することを想定している。先に述べたように、機能の一部は、クラスタ１３０のコンピューティングノード１２０を含む他のコンピュータによって実行されてもよい。

【0039】

図示のように、ゲートウェイ１１０は、タイプ検出器２１０と、分割器２２０と、変換器２３０と、分配器２４０とを備える。タイプ検出器２１０は、データオブジェクト１６０の一連の領域を、例えば、オブジェクトの先頭においてバイトをサンプリングすることによって読み取り、サンプリングに基づいてデータオブジェクト１６０のオブジェクトタイプを識別する機能を実行する。タイプ検出器２１０は、決定されたオブジェクトタイプを分割器２２０および変換器２３０に通知してもよい。

【0040】

分割器２２０は、データオブジェクト１６０を複数の部分２５０に分割する機能を実行する。部分２５０は、データオブジェクト１６０のそれぞれ処理可能なユニットを含み、データオブジェクト内の境界２５２によって定義される。分割器２２０の境界検出器２２２は、データオブジェクト１６０をスキャンして境界２５２、すなわち処理可能なユニット間のセパレータを探し、データオブジェクト１６０に対する境界２５２の位置を（例えば、バイト位置に基づいて）記録する。先に述べたように、境界２５２の性質は、データオブジェクト１６０のオブジェクトタイプに依存し、これは、好ましくは、タイプ検出器２１０の動作に基づいて既知である。

【0041】

Ｐａｒｑｕｅｔファイルを分割するときなどのいくつかの例では、境界検出器２２２は、データオブジェクト１６０内の全ての境界２５２を識別し、各対の境界の間に新たな部分２５０を定義してもよい。全ての境界を検出することは、境界２５２が、大きくなりがちな（例えば、メガバイトの範囲の）行グループに基づいている、Ｐａｒｑｕｅｔファイルに対してうまく機能する。しかし、行グループが異常に小さいことが判明した場合には、複数の行グループが単一の部分２５０内に含まれるように、境界がスキップされてもよい。ＣＳＶファイルを分割するときなどの他の例では、境界検出器２２２は、そうすると望ましくないほど多数の小部分２５０を生成することになるので、データオブジェクト１６０の全ての単一の境界をマークしない。
そのような場合には、境界検出器２２２は、現在の部分２５０をスキャンするとき、部分２５０のスキャンされたサイズがある所望の目標サイズを超えるまで、境界２５２の検出を開始するのを待ってもよい。スキャンが目標サイズを過ぎると、境界検出器２２２は境界の検出を開始してもよく、好ましくは、目標サイズを越えてオブジェクトが含む最初の境界を識別する。したがって、現在の部分は終了し、新しい部分が最初に検出された境界において開始されてもよい。

【0042】

境界検出器２２２が境界２５２を探してオブジェクト１６０をスキャンするとき、特徴検出器２２４は、後の処理に関連する有用な情報を提供し得る追加の特徴についてオブジェクトをスキャンしてもよい。特定のコンテンツが存在すること、または存在しないことが事前に分かっている場合には、特定の処理タスクがより速く実行されることが知られている。特定の例として、ＣＳＶファイルの特定のクエリは、データ内に引用符がないことが事前に分かっていれば、より迅速に実行される。したがって、特徴検出器２２４は、引用符の存在または不在についてＣＳＶファイルをチェックし、それに応じてオブジェクトメタデータ１１２（「Ｆｅａｔｕｒｅｓ」）を更新することができる。

【0043】

データオブジェクト１６０の部分２５０が境界２５２に基づいて識別された状態で、変換器２３０は、部分２５０をそれぞれのセグメント１７０に変換する。例えば、変換器２３０は、ある部分で見つかったメタデータを１つ以上の他の部分に追加することによって、そのような部分が独立した処理により適合するように、すなわち部分２５０間の依存性を取り除くことによって、部分２５０の少なくともいくつかを変更する。変更の性質は、タイプ検出器２１０の動作に基づいて既知であるオブジェクトタイプに依存する。変換器２３０の動作の結果は、データオブジェクトの個別に処理可能なユニットを提供するセグメント１７０である。例えば、セグメント１７０の各々は、データオブジェクト１６０と同じオブジェクトタイプとして与えられる。従って、セグメント１７０は、データオブジェクトが処理されるのと同じ方法で処理され得るが、主な違いは、セグメント１７０がはるかに小さく、より容易に扱えることである。

【0044】

次に、分配器２４０は、セグメント１７０をストレージクラスタ１３０の選択されたノード１２０に格納するために、当該ノードに分配する。このとき、ゲートウェイ１１０は、セグメント１７０が送られる場所、例えば、特定のノード１２０の識別子を記録するために、オブジェクトメタデータ１１２を更新する。このように、説明した方法において、データオブジェクト１６０は、分割され、変換され、ストレージクラスタ１３０の複数のノード１２０に分配される。

【0045】

図３Ａおよび図３Ｂは、ＣＳＶファイルなどの表形式データを含むデータオブジェクト１６０ａを分割および変換するための例示的な配置を示す図である。図３Ａは、分割の結果例を示し、図３Ｂは、変換の結果例を示す。

【0046】

図３Ａに示すように、データオブジェクト１６０ａは、第１行３１０と、２から８とラベル付けされた追加の行（列１参照）とを有する。データオブジェクト１６０ａは、４つの列を有する。各行は、ＣＳＶにおける行の区切りとして機能する＜改行＞文字で終わっている。

【0047】

データオブジェクト１６０ａを分割するとき、分割器２２０は、データオブジェクト１６０ａの部分３５０の最小サイズを定義する目標サイズ３２０を適用してもよい。例えば、分割器２２０は、目標サイズ３２０に対応するデータオブジェクト１６０ａに沿った位置（点線で示す）を特定し、特定した位置に続く第１の境界においてデータオブジェクト１６０ａを分割してもよい。図示の例では、分割器２２０は、目標サイズ３２０に続く第１の境界２５２として、６行目の末尾の改行文字を検出し、この位置でオブジェクト１６０ａを分割する。その結果、オブジェクト１６０ａの最初の６行は、第１の部分３５０ａを形成し、次の２行は、第２の部分３５０ｂの最初の２行を形成する。分割器２２０がオブジェクト１６０ａをスキャンし続けると、追加の行が第２の部分３５０ｂに追加され得る。

【0048】

分割器２２０が行の境界でオブジェクト１６０ａをうまく分離（したがって、同じ行の異なる部分が異なる部分３５０に割り当てられることを回避）したとしても、分割の結果が依然として非効率的である場合がある。例えば、オブジェクト１６０ａの最初の行３１０がヘッダ行（例えば、列名を示すテキストを含む行）である場合、第２の部分３５０ｂはそのヘッダを欠き、その後の処理が損なわれるかもしれない。例えば、ヘッダは、特定のクエリまたは他のアクティビティに応答するために必要とされる場合がある。しかしながら、この欠落は、変換器２３０によって対処されてもよい。

【0049】

図３Ｂは、変換器２３０によってなされた変更の結果の例を示す。ここで、部分３５０ａ，３５０ｂは、現在、それぞれセグメント３７０ａ，３７０ｂとして与えられている。セグメント３７０ｂは、第１のセグメント３７０ａに見られる第１の行３１０の複製である第１の行３１０ａの挿入によって変更された。第１の行３１０ａの追加により、第２の部分３７０ｂは、独立した処理可能なユニットに効果的に変換される。セグメント３７０ｂにおいて行われた変更は、オブジェクト１６０ａに対して生成された他のセグメント３７０において繰り返されてもよく、それによって、全てのセグメント３７０が、第１のセグメント３７０ａのものと同じ第１の行３１０を有するように形成されることを理解されたい。このように、全てのそのようなセグメント３７０は、独立して処理可能であるように形成される。

【0050】

ＣＳＶファイルによっては、ヘッダ行を使用せず、第１行３１０がテキストベースのフィールド名ではなく、データを含むことがあることに留意されたい。そのような場合には、最初のセグメント３７０ａの最初の行３１０のオブジェクト１６０ａの他のセグメント３７０への複製は、単に冗長なデータを広げるだけかもしれない。しかしながら、そのような場合は、容易に処理することができる。例えば、クエリまたは（例えば、ストレージクラスタのクライアントから到来する）他の処理タスクは、オブジェクト１６０ａによって表されるＣＳＶファイルがヘッダを含むかどうかを特定してもよい。もし含む場合には、ヘッダを複製することが適切であったため、変更を行う必要はない。しかし、タスクがＣＳＶファイルにヘッダが含まれていないことを特定した場合には、複製は不要であったことが判明する。このような場合には、ＣＳＶファイルに対して分散処理タスクを実行するノード１２０は、セグメント３７０のうち最初のセグメント３７０ａ以外の全てのセグメントの最初の行を無視するように指示するだけでよい。セグメント３７０のサイズと比較して典型的には無視できるサイズの最初の行３１０を複製した結果として、失われるものは少ないであろう。

【0051】

図４Ａおよび図４Ｂは、Ｐａｒｑｕｅｔファイルのような列ベースのデータを含むデータオブジェクト１６０ｂを分割および変換するための例示的な配置を示す。図４Ａは、分割および変換前の例示的なＰａｒｑｕｅｔファイル構造を示し、図４Ｂは、分割および変換後の例示的な結果を示す。

【0052】

図４Ａに見られるように、Ｐａｒｑｕｅｔファイル１６０ｂは、上述したように、４バイトの「マジックナンバー」（「ＰＡＲ１」）で始まり、終了する。ファイル１６０ｂは、さらに、複数の行グループ４１０（１からＮ、ここで、「Ｎ」は任意の正の整数）、およびフッタ４２０を含む。行グループ４１０は、典型的にはそれぞれメガバイトオーダーの大きな構造体である。フッタ４２０は、ファイル１６０ｂ内の行グループ４１０の位置（例えば、バイト位置）を提供する行グループメタデータを含む、ファイルメタデータを含む。また、フッタ４２０は、「ファイルメタデータの長さ」を符号化する４バイトのデータ要素を含む。

【0053】

オブジェクトを前方にスキャンしながら境界２５２を直接検出することができるＣＳＶの例とは異なり、行グループ４１０間の境界は、フッタ４２０を読むことによってのみ容易に検出することができる。これは、分割器２２０が、典型的には、フッタ４２０に到達する前にファイル１６０ａ全体を通過させ、その後、遡及的に分割を行うことを意味する。分割は、一般に、Ｐａｒｑｕｅｔファイル１６０ｂの各部分２６０が単一の行グループ４１０を含むように、全ての行グループ境界において実行される。行グループ４１０がコンテンツに基づいてサイズが変化する可能性があることを考慮すると、２つ以上の行グループ４１０を単一の部分２６０に配置することが時折、価値があることがある。これは、設計上の好みの問題である。

【0054】

図４Ｂに示すように、図４ＡのＰａｒｑｕｅｔファイル１６０ｂは、Ｎ個の異なるセグメント４７０（４７０－１から４７０－Ｎ）として与えられており、各セグメントは単一の行グループを含んでいる。例えば、セグメント４７０－１は行グループ１を含み、セグメント４７０－２は行グループ２を含み、行グループＮを含むセグメント４７０－Ｎまで、同様である。

【0055】

変換器２３０によって実装され得る図４Ｂに示される変更は、各行グループを自己完結型のＰａｒｑｕｅｔファイルとして与える。例えば、セグメント４７０－１から４７０－Ｎの各々は、先頭および末尾にマジックナンバー「ＰＡＲ１」を含む。また、セグメント４７０－１から４７０－Ｎの各々は、フッタ４２０の変更版であってもよい、変更されたフッタを含む。各セグメント４７０のフッタは、その行グループメタデータがそのセグメントに含まれる行グループ（または複数の行グループ）のみに限定され、そのセグメントに含まれない行グループの行グループメタデータを除外するように作成されている。また、各セグメントにおけるファイルメタデータの実際の長さを反映するために、「ファイルメタデータの長さ」が、各セグメントに提供されている。したがって、各セグメント４７０－１から４７０－Ｎは、それ自体を、任意のＰａｒｑｕｅｔファイルと同様に独立した処理に従う完全なＰａｒｑｕｅｔファイルとして提供する。

【0056】

いくつかの例では、追加のセグメント４７０－（Ｎ＋ｌ）が、Ｐａｒｑｕｅｔファイル１６０ｂの最終セグメントとして提供されてもよい。セグメント４７０－（Ｎ＋ｌ）は、行グループを含まず、むしろ、ファイル１６０ｂの元々のフッタ４２０の一部の持続版、すなわち、「ファイルメタデータ（全行グループ用）」および「ファイルメタデータの長さ」を提供する。このセグメントは、参照のために提供され、特定の処理タスクを高速化するために有用であるが、自己完結型のＰａｒｑｕｅｔファイルとして扱われることは意図していない。また、クエリを実行する際のデータのソースとして使用することも意図していない。

【0057】

図５Ａおよび図５Ｂは、ビデオファイルまたはストリームなどのビデオデータを含むデータオブジェクト１６０ｃを分割および変換するための例示的な配置を示す。図５Ａは、分割および変換前のビデオフレームの例示的なシーケンスを示し、図５Ｂは、分割および変換後の例示的な結果を示す。

【0058】

図５Ａに見られるように、データオブジェクト１６０ｃは、フレーム５１０のシーケンスを含み、描かれている例では、フレーム５１０は、１つ以上のＩフレーム（例えば、５１０－１および５１０ｃ）、１つ以上のＰフレーム（例えば、５１０－２，５１０－３，５１０ａ，５１０ｄおよび５１０ｅ）、および１つ以上のＢフレーム（例えば、５１０ｂ）を含んでいる。周知のように、Ｉフレームは、完全な画像を含むビデオフレームであり、完全性のために他のフレームに依存しない。対照的に、ＰフレームおよびＢフレームは、不完全であり、完全性のために他のフレームに依存する。Ｐフレームは通常、前のフレームを参照するが、Ｂフレームは前方または後方を参照することができる。典型的には、Ｉフレームは、ＰフレームまたはＢフレームよりも大きく、格納および送信にコストがかかるので、Ｉフレームは、ＰフレームまたはＢフレームよりもはるかに少ない頻度で現れる。

【0059】

オブジェクト１６０ｃにおけるビデオデータの分割は、オブジェクト１６０ａ（図３Ａおよび図３Ｂ）におけるＣＳＶデータの分割とよく似た動作をする。例えば、分割器２２０は、目標サイズ３２０と等しいかまたはそれよりわずかに大きいサイズを有する部分２５０を生成することを目的としてもよい。分割器２２０は、目標サイズを通過した後に生じるデータオブジェクト内の最初の境界２５２を見つけようとする。ビデオデータにおける境界を検出するために、分割器２２０は、以前または以後のフレームへの参照を必要としないため、自然な境界を提供するＩフレームを識別するように構成されてもよい。図示された例では、分割器２２０は、目標サイズ３２０を超える次の境界をＩフレーム５１０ｃとして識別する。

【0060】

しかし、Ｉフレーム５１０ｃの直前のビデオを分割すると、Ｂフレーム５１０ｂがＩフレーム５１０ｃを参照し、したがって、それなしでは描写できないので、問題が生じる。分割器２２０がＢフレーム５１０ｂの直後のビデオを分割しようとすると、Ｂフレーム５１０ｂを含むセグメントにおいてビデオにギャップが現れる。したがって、そのセグメントは、別のセグメントに依存することになるため、不完全なものとなる。

【0061】

図５Ｂは、例示的な解決策を示す。ここでは、これまで処理されたオブジェクト１６０ｃは、２つのセグメント５７０ａ，５７０ｂとして描写される。依存性を解決するために、セグメント５７０ａには、Ｉフレーム５１０ｃの複製５１０ｃｃが提供される。複製５１０ｃｃは、Ｂフレーム５１０ｂからの必要な参照を提供し、セグメント５７０ａを描写する際に落とされたビデオフレームを回避する。一方、セグメント５７０ｂは、Ｉフレーム５１０ｃをその最初のフレームとして保持し、したがって、セグメント５７０ｂを開始するための独立した基準線を提供する。後続のフレーム、例えば、フレーム５１０ｄ，５１０ｅは、完全性のためにＩフレーム５１０ｃに依存してもよいが、後続のフレームはいずれも、Ｉフレーム５１０ｃよりも前の任意のフレームを参照しない。したがって、セグメント５７０ａ，５７０ｂの各々は、独立した個別処理可能なユニットとして与えられ、完全性のために他のセグメントに依存しない。

【0062】

図６は、追加の実施形態に従う分散処理を実行するための例示的な配置を示す。描かれた配置は、図１の環境１００または他の環境において実装されてもよい。以下の説明は、上述の特徴が即座の実施形態の部分を形成するように、環境１００における実装を想定している。他の例では、図６の配置は、異なる特徴を有する他の環境において実装されてもよい。したがって、上述した特徴は、例示的な例としてみなされるべきであるが、具体的に示されない限り必要なものとしてみなされるべきではない。

【0063】

図６に示すように、ゲートウェイ１１０は、分散処理を行う際のその役割をサポートするコンポーネントを備える。これらは、上述したオブジェクトメタデータ１１２に加えて、タスク要求器６１０、ディスパッチャ６２０、出力受信器６３０、および出力集計器６４０を備える。

【0064】

例示的な動作では、タスク要求器６１０は、指定されたデータオブジェクト１６０（またはオブジェクト１６０の組）に対して処理タスクを実行するための要求６５０を発する。様々なタイプのタスクが企図される。これらは、例えば、（例えば、表形式またはツリーベースのデータオブジェクトのための）指定されたデータの読み取りおよび／またはクエリを含んでもよい。クエリのタイプは、ＳＱＬ（Ｓｉｍｐｌｅ Ｑｕｅｒｙ Ｌａｎｇｕａｇｅ）クエリ、キー値ルックアップ、ｎｏＳＱＬクエリなどを含んでいてもよい。ビデオデータオブジェクトのタスクは、指定されたグラフィックコンテンツ（例えば、顔、ナンバープレート、地理的特徴など）の検索のような、分散ビデオ処理タスクを含んでいてもよい。音声データオブジェクトのタスクは、話し言葉、音声特性（例えば、トーン、アクセント、ピッチなど）、特定の音などの検索を含んでいてもよい。基本的に、複数のノード１２０の間で分割することが可能であり、潜在的に大量のデータへのアクセスを伴う任意のタスクは、図６の配置における処理のための良い候補である。

【0065】

要求６５０が発せられると、ディスパッチャ６２０は、要求されたタスクのコンポーネントをそれぞれのノード１２０に分配することを開始する。例えば、ディスパッチャ６２０は、オブジェクトメタデータ１１２をチェックして、指定されたデータオブジェクト１６０（またはオブジェクトの組）のセグメント１７０と、ストレージクラスタ１３０内のそれぞれの位置とを識別する。図示された簡略化された例では、オブジェクトメタデータ１１２は、データオブジェクト１６０を構成する３つのセグメント１７０（例えば、Ｓ１、Ｓ２、およびＳ３）（典型的な結果は、数十または数百のセグメントを含み得る）およびそれぞれのセグメント１７０を格納する３つのコンピューティングノード１２０－１，１２０－２，１２０－３を識別する。

【0066】

次に、ディスパッチャ６２０は、識別されたノード１２０－１，１２０－２，１２０－３にそれぞれ、要求６５０－１，６５０－２，６５０－３を送信する。要求６５０－１，６５０－２，６５０－３は、要求６５０と類似または同一であってもよく、例えば、要求６５０において指定されるのと同じクエリまたは他のタスクを提供してもよい。しかしながら、そのような要求６５０－１，６５０－２，６５０－３は、互いに同一である必要はない。例えば、いくつかの要求は、他の要求において送信されたものとは異なるセグメント固有のメタデータ（例えば、オブジェクトメタデータ１１２に格納されている）を含んでいてもよく、これは、特定のノード上の処理タスクを導くために使用されてもよい。

【0067】

特定されたノード１２０－１，１２０－２，１２０－３は、それぞれ、要求６５０－１，６５０－２，６５０－３を受信し、これらのノードの各々は、そのそれぞれのセグメント上で要求タスクの実行を開始する。例えば、ノード１２０－１は、セグメントＳ１上でタスクを実行し、ノード１２０－２は、セグメントＳ２上でタスクを実行し、ノード１２０－３は、セグメントＳ３上でタスクを実行する。一例では、各ノード１２０は、他のノード１２０に連絡する必要なく、それぞれのセグメント１７０上でそれぞれのタスクを独立に実行する。例えば、ノード１２０－１は、Ｓ２またはＳ３へのアクセスを必要とせず、Ｓ１のみにアクセスすることにより、その作業を完了する。他のノードについても同様である。

【0068】

ノード１２０－１，１２０－２，１２０－３がそれぞれの作業を実行すると、それらのノードは、ノード１２０－１からの出力６６０－１、ノード１２０－２からの出力６６０－２、およびノード１２０－３からの出力６６０－３として示される、それぞれの出力６６０を生成する。参加ノードは、それぞれの出力６６０をゲートウェイ１１０に送り返し、ゲートウェイ１１０は出力を出力受信器６３０において収集する。

【0069】

図６の下部付近の拡大図に示すように、出力受信器６３０は、任意の順序で参加ノード１２０から出力６６０を受信してもよい。第１のシナリオにおいて、ノード１２０－１，１２０－２，１２０－３は、出力を送り返す前に、それぞれのタスクが完了するのを待つように構成される。この場合には、特定のノードからの出力６６０は、全て一度に到着し、異なるノードからの出力は、それぞれの完了時間に基づいて、異なる時間に到着してもよい。出力データ６６２は、この第１のシナリオによる結果例を示す。ここでは、ノード１２０－２からの出力６６０－２が最初に到着し、したがって出力データ６６２に最初に現れ、次に（ノード１２０－１からの）出力６６０－１が続き、次に（ノード１２０－３からの）最後に到着する出力６６０－３が現れる。出力６６０は、このように出力データ６６２においてインターリーブされる。

【0070】

第２のシナリオにおいて、ノード１２０－１，１２０－２，１２０－３は、そのようなインクリメントが利用可能になったときに直ちにというように、段階的に出力を返すように構成される。この第２のシナリオでは、各参加ノードは、複数の送信においてその出力６６０を返すことができ、それは時間的に広がってもよい。出力データ６６４は、このシナリオに従った例示的な結果を示す。ここで、出力データ６６４は、６つの異なるバッチ（６６０－１ａ，６６０－１ｂ，６６０－２ａ，６６０－２ｂ，６６０－３ａ，６６０－３ｂ）、すなわち、ノード１２０－１，１２０－２，１２０－３のそれぞれからの２つの出力のバッチを含むことがわかる。バッチは、受け取った順序で出力データ６６４に現れ、したがって、第１のシナリオで見られたよりも細かい粒度でインターリーブされてもよい。

【0071】

もちろん、ゲートウェイ１１０は、任意の所望の方法で出力６６０をソートしてもよく、ストレージクラスタ１３０の任意のノード１２０が、このタスクを実行するために呼び出されてもよい。いくつかの例では、影響を受けるノードとゲートウェイ１１０の両方が、出力６６０をソートすることに参加してもよい。例えば、ノードの各々は、結果６６０－１，６６０－２，６６０－３の各々がソートされた順序で個別に到着するように、そのそれぞれの出力をソートしてもよい。その後、ゲートウェイ１１０は、例えば、返された結果のソートされたセットの間でソートするために出力集計器６４０を用いることによって、作業を完了させてもよい。

【0072】

ソートには時間がかかり、多くの処理タスクは、ソートされた出力よりも速度を高く評価する。高速動作をさらに促進するために、コンピューティングノード１２０は、いくつかの例において、出力６６０をゲートウェイ１１０に返すときにＲＤＭＡ（リモートダイレクトメモリアクセス）を用いてもよい。

【0073】

いくつかの処理タスクについて、ディスパッチャ６２０は、処理要求を全ての関係するノードに（すなわち、対象データオブジェクトのセグメントを格納する全てのノードに）送信してもよい。他の例では、ディスパッチャ６２０は、例えば、先験的なセグメントコンテンツ、セグメントのバイト範囲、または他の要因の知識に基づいて、要求が送信されるノードを制限してもよい。このように関与するノードの数を制限することは、ネットワーク１４０（図１）上のトラフィックを減少させ、効率をさらに向上するのに役立つ。

【0074】

いくつかの処理タスクは、集計を含むことができる。例えば、クエリは、レコード自体ではなく、指定された基準を満たすレコードのカウントを要求することができる。クエリは、平均値、最大値、最小値、または他の何らかの集計値を要求することもできる。ノード１２０は、特定の集計関数（例えば、カウント、合計、最大、最小など）を自ら実行することができるが、個々のノード１２０は、通常、複数のノードにわたる出力を集計することはない。むしろ、この機能は、データ集計器６４０によって実行されてもよい。例えば、集計器６４０は、各々がそれぞれのセグメントに関するその処理から得られた部分的な集計結果を提供する、複数のノードからカウントを受信してもよい。集計器６４０は、次に、応答するノードからのカウントを合計して、データオブジェクト１６０全体についての集計された合計を生成してもよい。データオブジェクトの集計された平均を生成するために、例えば、集計器６４０は、カウントと合計の両方を提供するように各参加ノードに指示してもよい。次に、返された全てのカウントを合計して集計カウントを生成し、全ての総計を合計して集計総計を生成し、次に、集計総計を集計カウントで除算して所望の集計平均を生成してもよい。集計関数の他のタイプは、同様の方法で実行されてもよい。

【0075】

図６の配置は、帯域幅の点で非常に低いコストで集計クエリを実行することができることを理解されたい。各参加ノードは、ローカル集計を計算し、その結果のみを返すので、集計クエリは、非常に大きなデータセットにわたって実行され、通常は１キロバイト未満であり、しばしば数バイト程度に小さいこともある非常に小さな出力６６０を生成することができる。

【0076】

ゲートウェイ１１０は、タスク要求６５０の発信者、影響を受けるノードへの要求のディスパッチャ、およびノードからの出力６６０のコレクタとして示され説明されてきたが、これらの機能は、代替的に他のコンピュータによって、または複数のコンピュータによって実行されてもよい。実際、それらは、ストレージクラスタ１３０の１つまたは複数のノード１２０によって実行されてもよい。従って、示された例は、限定的ではなく例示的であることが意図されている。

【0077】

図７および図８は、追加の実施形態に従ってセグメント１７０のデータ保護を実行するための例示的な配置を示す。図６および図７の描かれた配置は、図１および／または図６の環境１００、あるいは上記に例示されたものとは異なる環境において実装されてもよい。

【0078】

図７は、単一のデータオブジェクト１６０から生成された複数のセグメント１７０を、セグメント１７０を縦に配置して示している。必須ではないが、セグメント１７０は、この場合、最も早く作成されたセグメント（オブジェクトの始まりに最も近い）が上に現れ、縦方向に隣接するセグメント１７０がデータオブジェクト１６０の隣接部分に対応するように、順番に配置されてもよい。データオブジェクト１６０から９つよりも多くのセグメント１７０が生成されているかもしれないことを理解した上で、９つのセグメント１７０が示されている。一例では、図示された９つのセグメント１７０は、データオブジェクトから（例えば、分割器２２０および変換器２３０によって；図２）生成される最初の９つのセグメントである。

【0079】

注目すべきは、セグメント１７０が異なるそれぞれの長さを有することである。したがって、図の右上に示すように、セグメント１７０を長さの順に、例えば、最長から最短にランク付けすることが可能である。

【0080】

図８は、ランク付けされた同じセグメント１７０を拡大した図である。ここでは、種々の形態のパリティ情報を提供する修復データのＭ＝３個の要素８１０を生成するために、９つのセグメント（Ｋ＝９）に対してＫ＋Ｍ回の消去コード処理が（例えば、ゲートウェイ１１０によって）実行される。Ｋ個のセグメントは、Ｍ個の修復要素とともに、全体として合計１２個の要素を含む修復グループ８０２を構成する。

【0081】

図示された修復グループ８０２は、データ損失を経験する前に、最大Ｍ個の要素に損傷を与えることを許容にする。損傷した要素は、データセグメント１７０および／または修復要素８１０を含む修復グループ８０２の任意の要素であってもよく、任意の組み合せであってもよい。完全な回復および修復は、Ｍ個の全ての要素よりも大きい要素が損傷されない限り達成され得る。Ｋ＝９およびＭ＝３の選択は、他の要因の中でも、所望のデータ保護レベルに基づいて、変化させることができることを理解すべきである。実施例においては、修復要素８１０は、全く新しいと思われる計算上効率的な手順８００を使用して生成される。

【0082】

以前の消去符号化スキームは、全てのＫ個のデータ要素が等しい長さを有することを必要とする場合がある。データ要素が不均等な長さを有する場合、長さを等しくするためにゼロパディングが使用され得る。次に、パリティ計算が、全てのＫ個のデータ要素の全長を使用して実行され、Ｋ個のデータ要素と同じ長さを有するＭ個のパリティ要素を生成する。

【0083】

通常の消失訂正符号化アプローチと対照的に、手順８００は、不等長を有するデータ要素から修復要素を生成する。ゼロパディングは必要ない。一例において、手順８００は、セグメント１７０、すなわち、Ｋ＝９のデータ要素を論理的に整列させることによって進行する。例えば、セグメント１７０は、図示されるように、それぞれの上端において整列されてもよい。あるいは、セグメント１７０は、それぞれの下端（図示せず）において整列されてもよく、あるいは、他の何らかの既知の方法で整列されてもよい。任意のセグメント１７０の実際の移動が要求されないので、そのような整列は、物理的というよりも論理的であることに留意されたい。また、セグメント１７０の図示された順位は、物理的というよりも論理的であると理解されるべきである。

【0084】

セグメント２７０が論理的に整列された状態で、手順８００は、最短のセグメント１７０（「１」とラベル付けされている）を特定し、対応する範囲（Ｒｎｇ１）を特定することによって進行する。Ｒｎｇ１は、セグメント１と整列し、同じサイズおよび限界を有する。セグメント１が最短のセグメントであり、セグメント１７０が論理的に整列しているので、Ｋ個のセグメント１７０（セグメント１から９）の全てがＲｎｇ１内にデータを有する。セグメント１から９にわたるＲｎｇ１データを使用して、手順は、Ｍ個の修復要素８１０のそれぞれに対して１組ずつ、Ｍ組の修復データを計算し、Ｒｎｇ１の位置においてそれぞれの修復要素８１０に修復データを配置する。Ｒｎｇ１の修復データは、このように完全であり、そのような修復データは、Ｋ個全てのセグメント１７０に基づいている。修復データの本明細書における計算は、従来のＫ＋Ｍ回の消失訂正符号化において使用されるものと同様であってよく、その詳細は、実施形態にとって重要ではなく、これ以上説明されないことを理解されたい。

【0085】

次に、手順８００は、追加の範囲に対して同様の方法で継続する。例えば、Ｒｎｇ２は、セグメント１を越えて延びるセグメント２の部分、すなわち、修復データがまだ計算されていないセグメント２の部分に対応する。セグメント１にはＲｎｇ２のデータがないため、Ｒｎｇ２の修復データは、セグメント２～９の対応する部分のみ（すなわち、合計Ｋ－１個のセグメント）を使用して計算することができる。上記と同様に、手順は、Ｍ個の修復要素８１０のそれぞれに対して１組ずつ、Ｍ組の修復データを計算し、修復データをそれぞれの修復要素８１０に、今回はＲｎｇ２の位置に配置する。このようにして、Ｒｎｇ２に対する修復データが完成するが、かかる修復データは、Ｋ－１個のセグメント１７０のみに基づいている。

【0086】

手順８００は、範囲Ｒｎｇ３からＲｎｇ８の各々についてこの方法で継続することができ、各範囲の修復データの計算は、直前の範囲の計算よりも１つ少ないセグメントを含む。したがって、Ｒｎｇ３の計算にはＫ－２個のセグメントが含まれ、Ｒｎｇ４の計算にはＫ－３個のセグメントが含まれ、Ｒｎｇ８の計算にはＫ－７個のセグメント、すなわち、セグメント８，９のみが含まれるようになる。なお、Ｒｎｇ９は１つのセグメント（セグメント９）しか交差しないので、Ｒｎｇ９の計算は不要である。Ｒｎｇ９に対する修復データを計算するのではなく、手順８００は、代わりに、影響を受けるデータ、すなわち、Ｒｎｇ９内のセグメント９の部分のレプリカ（複製）を格納する。Ｒｎｇ９データの別個の複製は、修復要素８１０の各々のＲｎｇ９の位置に提供されてもよい。

【0087】

消失訂正符号化手順８００は、典型的には、従来の消失訂正符号化よりも計算が高速である。Ｍ個の修復要素８１０の修復データを計算するためにＫ個全てのデータ要素を必要とする代わりに、手順８００は、最短のデータ要素のみに対してＫ個のデータ要素を必要とする。次に短いデータ要素ごとに、手順８００は、１つ少ないデータ要素を必要とし、最終的には２つのデータ要素のみを必要とし、したがって、計算の複雑さおよび実行時間を低減する。

【0088】

オブジェクト１６０から生成されるようなセグメント１７０は、消失訂正符号化手順８００を使用して保護されてもよいことを理解されたい。例えば、セグメント１７０をクラスタ１３０に格納するためにコンピューティングノード１２０に分配するとき、ゲートウェイ１１０（またはいくつかの他のコンピュータ）は、低減された計算コストで修復要素８１０を生成するために手順８００を実行してもよい。手順８００は、一度にＫ個のセグメント１７０で動作し、それぞれについてＭ個の修復要素を生成し、Ｋ＋Ｍ個の要素の各組についてそれぞれの修復グループ８０２を形成する。

【0089】

図９は、特定のデータオブジェクト１６０ｘを保護するために使用され得る、複数の修復グループ８０２の例示的な配置を示す。図示されるように、修復グループ８０２－１，８０２－２、および修復グループ８０２－Ｒまでは、例えば、消去符号化手順８０２を使用して、データオブジェクト１６０ｘのデータ保護を行う。第１の修復グループ８０２－１は、データオブジェクト１６０ｘから生成されるＫ個のセグメント１７０の第１のグループを含みかつ保護し、第２の修復グループ８０２－２は、同じデータオブジェクト１６０ｘから生成されるＫ個のセグメント１７０の第２のグループを含みかつ保護するというように、最後のセグメント１７０グループを保護する第Ｒの修復グループ８０２－Ｒまで続く。修復グループ８０２－Ｒは、Ｋ個より少ないセグメントを含むことに留意されたい。例えば、データオブジェクト１６０ｘは、７つのセグメントのみを生成した後に終了（データを使い果たす）してもよい。修復グループ８０２を構成するセグメント１７０は、列（列１から列９）に配置され、各列がＫ個の要素のそれぞれの１つに対応することが分かる。

【0090】

消失訂正符号化は、データ配置にある種の制約を設けることができることを理解されたい。例えば、同じ修復グループ８０２に属する２つのセグメント１７０は、通常、同じディスクドライブ（例えば、ＳＳＤ、磁気ディスクドライブなど）に格納されるべきではなく、そうすることは、消失訂正符号化の冗長性を損ない、セグメントがデータ損失の増加リスクにさらされることになるからである。同様の理由で、同じ修復グループ８０２に属する２つのセグメント１７０は、通常、同じコンピューティングノード１２０に格納されるべきではなく、そうすることは、例えば、コンピューティングノード１２０の故障の場合に、冗長性を低下させることになるからである。しかしながら、これらのルールは、通常、異なる修復グループ８０２には適用されない。例えば、２つのセグメントが同じ修復グループ８０２に属さない限り、異なる修復グループ８０２に属するセグメント１７０を同じコンピューティングノード１２０に格納しても、冗長性の実質的損失は生じない。例えば、単一のコンピューティングノード１２０が、所定のデータオブジェクト１６０（同じデータオブジェクトのＲ個のセグメントの合計）を保護するＲ個の修復グループの各々から１つのセグメント１７０を格納することが許されてもよい。

【0091】

消失訂正符号化は、データを保護するための１つの方法であり、他の方法は複製であることをさらに理解されたい。一例では、データオブジェクト１６０およびそれらに関連する修復データおよび／またはレプリカは、オブジェクトストアのバケットに存在し、データ保護スキームは、バケット単位で適用される。データ保護に複製を使用するバケットは、したがって、そこに含まれる全てのオブジェクト１６０を含むそのコンテンツの全てを保護するために複製を使用することになる。同様に、データ保護に消失訂正符号化を用いるバケットは、その全てのコンテンツに消失訂正符号化を用いる。消失訂正符号化パラメータＫ，Ｍも、バケット単位で選択および適用されてもよい。したがって、図９の配置は、オブジェクト１６０ｘを含むバケットがこれらの設定を使用するので、Ｋ＝９およびＭ＝３の消失訂正符号化を使用してもよく、したがって、バケットの全てのコンテンツにグローバルに適用される。

【0092】

図１０は、データオブジェクト１６０およびそのセグメント１７０を管理する際に使用される種々の量を決定するための例示的な方法１０００を示す。方法１０００は、消失訂正符号化を用いたデータ保護を想定しており、セグメント１７０の所望の目標サイズ３２０（図３）、およびデータオブジェクト１６０の保護に使用する修復グループ８０２の数Ｒ（図９）を決定するために使用されてもよい。方法１０００は、例えば、ゲートウェイ１１０、ストレージクラスタ１３０のノード１２０、またはクラスタ１３０に接続可能な他のコンピュータによって実行されてもよい。方法１０００の開始時に、データオブジェクト１６０のサイズと（Ｋ＋Ｍ回の消失訂正符号化において使用される）数Ｋが予め分かっているものとする。

【0093】

１０１０において、方法１０００は、ノード１２０によって効率的に処理されることができるセグメント１７０の最大サイズＳＭＡＸを確立する。最大サイズは、ノード１２０のハードウェア仕様（例えば、クロック速度、コアの数、メモリの量など）、ならびに処理タスクに対する予想されるレイテンシおよびユーザの期待などの実用的な考慮事項に基づいてもよい。ＳＭＡＸの典型的な範囲は、例えば、数１００キロバイトと数メガバイトの間であってもよい。

【0094】

１０１２において、本方法は、列あたりの平均バイト数ＢＣを計算する。一例において、ＢＣの値は、データオブジェクト１６０のサイズ「ＯｂｊｅｃｔＳｉｚｅ」と、データオブジェクト１６０を保護するために使用されるＫ＋Ｍ回の消失訂正符号化において使用される数Ｋとに基づいてもよい。例えば、ＢＣ＝ＯｂｊｅｃｔＳｉｚｅ／Ｋである。図９に戻って参照すると、ＢＣは、図示された列における列ごとのデータの平均量を表すことが分かる。

【0095】

１０１４において、方法１０００は、例えば、ＢＣをＳＭＡＸで除算し、最も近い自然数に切り上げることによって、修復グループの数Ｒを計算する。より具体的には、修復グループの数は、Ｒ＝ＢＣ／ＳＭＡＸとして計算され、切り上げられればよい。

【0096】

１０１６において、本方法は、目標セグメントサイズ３２０をＳＴＡＲ＝ＢＣ／Ｒとして計算する。結果として得られる量ＳＴＡＲは、例えば、データオブジェクト１６０を分割するときに境界２５２の検索を開始する場所を決定する際に、分割器２２０に提供されてもよい。

【0097】

１０１８において、方法１０００は、少なくともＳＴＡＲと同じ大きさの部分２５０を生成する方法でデータオブジェクト１６０を分割するように、例えば、ＳＴＡＲを越えて次の境界２５２まで延びる部分２５０を生成するように分割器２２０に指示する。

【0098】

このように、方法１０００は、特定のデータオブジェクト１６０に対して使用されるべき目標セグメントサイズ３２０および修復グループの数Ｒを確立するための有用なガイドラインを提供する。これらの量の実際の選択は、管理者の裁量を含んでいてもよく、説明されたもの以外の他の要因によって操作されることがある。したがって、方法１０００は、必須ではなく、助言的であることを意図している。

【0099】

図１１は、例示的なコンピューティングノード１２０をさらに詳細に示している。コンピューティングノード１２０は、ストレージクラスタ１３０のコンピューティングノード１２０－１，１２０－２，１２０－３を代表するものであることを意図している。また、図１のゲートウェイ１１０を代表するものであることが意図されている。

【0100】

図示されているように、コンピューティングノード１２０は、１つまたは複数のネットワークインターフェースカード（ＮＩＣ）１１１０などの１つまたは複数の通信インターフェース、１つまたは複数の処理チップおよび／またはアセンブリなどの一組のプロセッサ１１２０、ソフトウェアを実行するための揮発性メモリなどのメモリ１１３０、および１つまたは複数の固体ディスク（ＳＳＤ）、磁気ディスクドライブなどの永続的ストレージ１１４０を備えている。一組のプロセッサ１１２０およびメモリ１１３０は、共に制御回路を形成し、本明細書に記載されるような種々の方法および機能を実行するように構成されかつ配置される。また、メモリ１１３０は、図１および図２に示されるような種々のソフトウェア構成を含み、これらは実行可能な命令の形態で実現される。実行可能な命令が一組のプロセッサ１１２０によって実行されると、一組のプロセッサ１１２０は、ソフトウェア構成の動作を実行する。一例では、１つ以上の一組のプロセッサ１１２０は、１以上のネットワークカード１１１０に常駐していてもよく、これにより、ネットワーク１４０上の高速通信を促進し、帯域幅および効率を向上することができる。

【0101】

図１２、図１３および図１４は、環境１００に関連して実施され得る例示的な方法１２００，１３００，１４００を示し、上述の特徴のいくつかの要約を提供する。方法１２００，１３００，１４００は、例えば、図１および図２に関連して説明したソフトウェア構成によって典型的に実行される。方法１２００，１３００，１４００の様々な動作は、任意の適切な方法で順序付けられてもよい。したがって、動作が図示されたものとは異なる順序で実行される実施形態が構築されてもよく、それは、いくつかの動作を同時に実行することを含んでもよい。

【0102】

図１２は、データオブジェクトを管理する例示的な方法１２００を示す。１２１０において、データオブジェクト１６０は、データオブジェクト１６０内の境界２５２において複数の部分２５０に分割される（図２参照）。境界２５２は、データオブジェクトのタイプ（例えば、ＣＳＶ、ＪＳＯＮ、ＸＭＬ、Ｐａｒｑｕｅｔ、ビデオなど）に従って、データオブジェクト１６０の処理可能なユニット２５０の間のセパレータを提供する。１２２０において、部分２５０は、データオブジェクト１６０のタイプと同じタイプの個別に処理可能なユニットを提供するセグメント１７０に変換される。例えば、データおよび／またはメタデータは、１つの部分２５０から他の部分に複製されてもよく、セグメント１７０間およびセグメント間の依存性を低減または除去するために、他の変更がなされてもよい。１２３０において、セグメント１７０は、そこに格納するために、ストレージクラスタ１３０の複数のコンピューティングノード１２０の間に分配される。

【0103】

図１３は、データオブジェクトを管理する例示的な方法１３００を示す。１３１０において、データオブジェクト１６０は、例えば、分割器２２０（図２）の動作によって、複数のセグメント１７０に分割される。１３２０において、セグメント１７０は、ストレージクラスタ１３０の複数のコンピューティングノード１２０の間に分配される。１３３０において、分配された処理タスクが、ストレージクラスタ１３０によって実行される。分配された処理タスクは、ストレージクラスタ１３０の複数のそれぞれのコンピューティングノード１２０によって、そこに格納されたそれぞれのセグメント１７０またはセグメント１７０の組に対して独立に実行される。

【0104】

図１４は、データオブジェクトを管理する例示的な方法１４００を示す。１４１０において、データオブジェクト１６０は、複数のセグメント１７０に分割され、セグメント１７０の少なくともいくつかは、互いに異なる長さを有する（図７および図８を参照）。１４２０において、セグメント１７０は、ストレージクラスタ１３０の複数のコンピューティングノード１２０に分配される。１４３０において、セグメント１７０のＫ個は、Ｋ個のセグメントから生成された修復データのＭ個の要素８１０を用いて保護され、Ｍ個の要素８１０の各々は、Ｋ個のセグメントから選択されたセグメントのそれぞれのグループ化（例えば、Ｋ個のセグメントを有する１つのグループ化、Ｋ－１個のセグメントを有する１つのグループ化等々）から計算された修復データを格納する複数の範囲（例えば、Ｒｎｇ１，Ｒｎｇ２等）を有する。

【0105】

ストレージクラスタ１３０においてデータオブジェクト１６０を管理するための改良された技術は、データオブジェクト１６０を、データオブジェクト１６０内の境界２５２において複数の部分２５０に分割することを含む。本技術は、データオブジェクト１６０の部分２５０を、個別に処理可能なユニットを提供するセグメント１７０に変換することと、そこに格納するために、セグメント１７０をストレージクラスタ１３０の複数のコンピューティングノード１２０に分配することとをさらに含む。

【0106】

特定の実施形態を説明してきたが、多数の代替的な実施形態または変形を行うことができる。さらに、特徴は、本明細書の特定の実施形態を参照して示され、説明されてきたが、そのような特徴は、開示された実施形態およびその変形例のいずれにも含まれてもよく、本明細書では、そのような特徴が含まれている。したがって、任意の実施形態に関連して開示された特徴は、任意の他の実施形態に含まれることが理解される。

【0107】

さらに、改良またはその一部は、（図１２において媒体１２５０として例示的に示された）磁気ディスク、磁気テープ、コンパクトディスク、ＤＶＤ、光ディスク、フラッシュドライブ、ソリッドステートドライブ、ＳＤ（Ｓｅｃｕｒｅ Ｄｉｇｉｔａｌ）チップまたはデバイス、ＡＳＩＣ（Ａｐｐｌｉｃａｔｉｏｎ Ｓｐｅｃｉｆｉｃ Ｉｎｔｅｇｒａｔｅｄ Ｃｉｒｃｕｉｔ）、ＦＰＧＡ（Ｆｉｅｌｄ Ｐｒｏｇｒａｍｍａｂｌｅ Ｇａｔｅ Ａｒｒａｙ）などの１以上の非一過性のコンピュータ読取り可能な記憶媒体を含むコンピュータプログラム製品として具現化されてもよい。任意の数のコンピュータ読み取り可能な媒体が使用されてもよい。媒体は、１つ以上のコンピュータまたは他のプロセッサ上で実行されると、本明細書に記載された１以上の処理を実行する命令で符号化されてもよい。そのような媒体は、製造物または機械とみなされてもよく、１つの機械から別の機械に転送可能であってもよい。

【0108】

本書全体で使用されているように、語句「備える」、「含む」および「有する」は、開放的な方法で何かの特定の項目、ステップ、要素、または側面を規定することを意図している。また、本明細書で使用される場合、特に反対の記述がない限り、「組」という語句は、１つ以上の何かを意味する。これは、フレーズ「組」の後に単数または複数のオブジェクトが続くかどうか、および単数または複数の動詞が接続されるかどうかに関係ない。また、「一組の」要素は、存在する全ての要素よりも少ない数を表すことができる。したがって、その組の一部ではない同種の要素がさらに存在してもよい。
さらに、「第１」、「第２」、「第３」などの序数表現は、本明細書では識別のための形容詞として使用されてもよい。具体的に示されない限り、これらの序数表現は、任意の順序または配列を意味することを意図していない。したがって、例えば、「第２の」イベントは、「第１のイベント」の前または後に行われてもよく、あるいは、第１のイベントが発生することなく行われてもよい。さらに、特定の要素、特徴、または動作を「第１の」そのような要素、特徴、または動作であると本明細書で特定することは、「第２の」または他のそのような要素、特徴、または動作も存在しなければならないことを要求すると解釈すべきではない。むしろ、「第１」の項目が唯一のものであってもよい。また、特に断りのない限り、「～に基づく」は非排他的であることを意図している。したがって、「に基づく」は、特に断りのない限り、「にのみ基づく」ではなく、「に少なくとも部分的に基づく」を意味すると解釈されるべきである。特定の実施形態が本明細書に開示されているが、これらは例示としてのみ提供され、限定的に解釈されるべきではないと理解される。

【0109】

したがって、当業者は、以下の請求項の範囲から逸脱することなく、本明細書に開示された実施形態に対して形態および詳細における種々の変更を行うことができることを理解するであろう。

【図1】

【図2】

【図3A】

【図3B】

【図4A】

【図4B】

【図5A】

【図5B】

【図6】

【図7】

【図8】

【図9】

【図10】

【図11】

【図12】

【図13】

【図14】

【国際調査報告】