知財求人 - 知財ポータルサイト「IP Force」
(19)【発行国】日本国特許庁(JP)
(12)【公報種別】公表特許公報(A)
(11)【公表番号】
(43)【公表日】2024-12-10
(54)【発明の名称】圧縮データの分割、処理、および保護
(51)【国際特許分類】
G06F 16/28 20190101AFI20241203BHJP
G06F 16/182 20190101ALI20241203BHJP
【ＦＩ】
G06F16/28
G06F16/182
【審査請求】未請求
【予備審査請求】未請求
(21)【出願番号】P 2024528458
(86)(22)【出願日】2022-11-01
(85)【翻訳文提出日】2024-07-12
(86)【国際出願番号】 US2022048590
(87)【国際公開番号】W WO2023086242
(87)【国際公開日】2023-05-19
(31)【優先権主張番号】63/278,900
(32)【優先日】2021-11-12
(33)【優先権主張国・地域又は機関】US
(81)【指定国・地域】
【公序良俗違反の表示】
（特許庁注：以下のものは登録商標）
１．ＪＡＶＡＳＣＲＩＰＴ
２．ＡＷＳ
(71)【出願人】
【識別番号】524178931
【氏名又は名称】エアーメトル インコーポレイテッド
【氏名又は名称原語表記】ＡＩＲＭＥＴＴＬＥ， ＩＮＣ．
【住所又は居所原語表記】２７００ Ｐｏｓｔ Ｏａｋ Ｂｌｖｄ．，２１ｓｔ Ｆｌｏｏｒ Ｈｏｕｓｔｏｎ， Ｔｅｘａｓ ７７０５６ Ｕ．Ｓ．Ａ．
(74)【代理人】
【識別番号】100122426
【弁理士】
【氏名又は名称】加藤 清志
(72)【発明者】
【氏名】スティーブンス、ドンポール・シー
(72)【発明者】
【氏名】フス、ジョシュア・アール
【テーマコード（参考）】
5B175
【Ｆターム（参考）】
5B175AA01
5B175CA08
(57)【要約】
圧縮データを分割する技術は、圧縮データを複数の部分に分割することを含む。この技術はさらに、現在の部分に関連付けてて解凍状態を保存することを含み、解凍状態は前の部分のデータに基づいており、他の部分とは独立した現在の部分の解凍を可能にする。
【選択図】図１６
【選択図】図１６
【特許請求の範囲】
【請求項1】
圧縮データを複数の前記圧縮データの部分に分割し、前記部分は、（ｉ）前記圧縮データの現在の部分と、（ｉｉ）前記現在の部分の直前の前記圧縮データの前の部分と、を含み、前記前の部分の解凍に基づいて解凍状態をキャプチャし、前記解凍状態は前記現在の部分の前記解凍を可能にし、および、
前記現在の部分が前記前の部分を参照することなく解凍可能であるように、前記現在の部分を前記解凍状態と関連付けて保存すること、
を含む、圧縮データの管理方法。
【請求項2】
前記現在の部分に関連付けて保存された前記解凍状態は、前記前の部分の解凍されたデータの範囲から形成されたディクショナリを含む、請求項１に記載の方法。
【請求項3】
前記解凍されたデータの範囲は、長さを有し、前記前の部分の終わりまで延びる、請求項２に記載の方法。
【請求項4】
前記圧縮データの前記部分を、ストレージクラスタのストレージノード上のそれぞれのセグメントに保存すること、および、メタデータにおいて、前記ストレージノード上の前記それぞれのセグメントの位置を追跡すること、
をさらに含む、請求項１～３のいずれか１項に記載の方法。
【請求項5】
前記圧縮データの前記部分を前記それぞれのセグメントに保存することは、前記ストレージクラスタの特定のノード上の現在のセグメントに前記現在の部分を保存することを含み、前記解凍状態に関連して前記現在の部分を保存することは、前記特定のノード上に前記解凍状態を保存することを含む、請求項４に記載の方法。
【請求項6】
前記特定のノードに前記解凍状態を保存することは、前記現在のセグメントのヘッダーおよび／またはフッターに前記解凍状態を保存することを含む、請求項５に記載の方法。
【請求項7】
前記メタデータは、セグメントと、前記それぞれのセグメントに保存された前記圧縮データのそれぞれのバイト範囲とを関連付け、方法は更に：前記圧縮データの指定されたバイト範囲を受信すること、
前記メタデータから、前記圧縮データの前記指定されたバイト範囲の少なくとも一部を保存するターゲットセグメントを識別すること、および、
前記ターゲットセグメントにアクセスして、前記指定されたバイト範囲またはその前記一部を取得すること、
を含む、請求項４に記載の方法。
【請求項8】
前記メタデータがセグメントを非圧縮データのそれぞれのバイト範囲に関連付け、前記方法は更に：前記非圧縮データの指定されたバイト範囲を受信すること、
前記メタデータから、解凍されると前記非圧縮データの前記指定されたバイト範囲の少なくとも一部を提供する前記圧縮データを保存するターゲットセグメントを識別すること、および、
前記ターゲットセグメントにアクセスして前記非圧縮データの前記指定されたバイト範囲またはその前記一部を取得すること、
を含む、請求項４に記載の方法。
【請求項9】
前記メタデータが、セグメントを非圧縮データの行または記録のそれぞれの範囲に関連付け、方法は更に：前記非圧縮データの行または記録の指定された範囲を受信すること、
前記メタデータから、解凍されたときに前記行または記録の前記指定された範囲の少なくとも一部を提供する前記圧縮データを保存するターゲットセグメントを識別すること、および、
前記ターゲットセグメントにアクセスして前記行または記録の前記指定された範囲またはその前記一部を取得すること、
を含む、請求項４に記載の方法。
【請求項10】
前記圧縮データを複数の部分に分割する場合、前記圧縮データの前記部分の非圧縮バージョンは、前記圧縮データの前記部分よりもサイズが互いに近い、請求項２に記載の方法。
【請求項11】
前記圧縮データを分割することは：前記圧縮データ内のターゲット分割位置を識別すること、および、
前記圧縮データの非圧縮コンテンツに基づいて、前記ターゲット分割位置とは異なる選択された分割位置で前記圧縮データを分割し、前記選択された分割位置は、前記現在の部分と、前記現在の部分の直後に続く次の部分とを分離すること、
を含む、請求項２に記載の方法。
【請求項12】
前記選択された分割位置で前記圧縮データを分割することは：前記現在の部分の前記圧縮データの範囲を解凍すること、
範囲の解凍されたデータ内の境界を識別し、前記境界は、解凍されたデータの個別に処理可能な単位の終わりを定義し、および、
前記選択された分割位置を、前記境界に続く位置として割り当てること、
を含む、請求項１１に記載の方法。
【請求項13】
解凍されたデータの前記個別に処理可能な単位は、（ｉ）ＣＳＶ（カンマ区切り値）データの行、（ｉｉ）ＪＳＯＮ（ＪａｖａＳｃｒｉｐｔ Ｏｂｊｅｃｔ Ｎｏｔａｔｉｏｎ）記録、または（ｉｉｉ）行区切りデータの他の行または記録区切りデータの記録、のいずれか１つを含む、請求項１２に記載の方法。
【請求項14】
前記圧縮データがデフレートブロック内に配置され、前記境界は、前記圧縮データの特定のデフレートブロック内に含まれ、前記特定のデフレートブロックは終わりを有し、および、
前記選択された分割位置を前記境界に続く位置として割り当てることは、前記選択された分割位置を前記特定のデフレートブロックの終わりとして定義することを含む、請求項１２に記載の方法。
【請求項15】
前記境界と前記選択された分割位置との間に位置するデータとしてフィックスアップデータのセットを取得すること、および、前記フィックスアップデータのセットを前記次の部分に関連付けて保存すること、
をさらに含む、請求項１２に記載の方法。
【請求項16】
前記境界のインジケータを前記現在の部分と関連付けて保存することをさらに含み、前記インジケータは、前記現在の部分の前記圧縮データから得られる非圧縮データの処理が無視され始める位置を識別する、請求項１５に記載の方法。
【請求項17】
前記フィックスアップデータのセットは、前記次の部分と関連付けて保存されるディクショナリ内に完全に含まれ、前記方法は、前記次の部分と関連付けて、前記ディクショナリ内に前記境界のインジケータを保存することをさらに含む、請求項１５に記載の方法。
【請求項18】
前記フィックスアップデータのセットは、前記次の部分と関連付けて保存されるディクショナリ内に完全に含まれず、前記フィックスアップデータのセットを保存することは、前記次の部分と関連付けて、前記ディクショナリ内に含まれていない追加のフィックスアップデータを保存することを含む、請求項１６に記載の方法。
【請求項19】
前記現在の部分の前記解凍されたデータ中の記述的な内容を識別し、前記次の部分のデータの独立した処理を容易にするために、前記記述的な内容を前記次の部分と関連付けて保存することをさらに含む、請求項１５に記載の方法。
【請求項20】
前記圧縮データを圧縮データの複数の部分に分割することは、２つの連続する部分が共に重複部分を含むように、前記２つの連続する部分の間に前記重複部分を提供することを含む、請求項１に記載の方法。
【請求項21】
メモリに結合されたプロセッサのセットを含む制御回路を備え、前記制御回路は：圧縮データを複数の前記圧縮データの部分に分割し、前記部分は、（ｉ）前記圧縮データの現在の部分と、（ｉｉ）前記現在の部分の直前の前記圧縮データの前の部分と、を含み、
前記前の部分の解凍に基づいて解凍状態をキャプチャし、前記解凍状態は前記現在の部分の前記解凍を可能にし、および、
前記現在の部分が前記前の部分を参照することなく解凍可能であるように、前記現在の部分を前記解凍状態と関連付けて保存する、
ように構成および構築される、コンピュータ化された装置。
【請求項22】
コンピュータ化された装置の制御回路によって実行されると、前記コンピュータ化された装置に圧縮データを管理する方法を実行させる命令を有する非一時的なコンピュータ可読媒体のセットを含むコンピュータプログラム製品であって、前記方法は：前記圧縮データを複数の前記圧縮データの部分に分割し、前記部分は、（ｉ）前記圧縮データの現在の部分と、（ｉｉ）前記現在の部分の直前の前記圧縮データの前の部分と、を含み、
前記前の部分の解凍に基づいて解凍状態をキャプチャし、前記解凍状態は前記現在の部分の前記解凍を可能にし、および、
前記現在の部分が前記前の部分を参照することなく解凍可能であるように、前記現在の部分を前記解凍状態と関連付けて保存すること、
を含む、コンピュータプログラム製品。
【発明の詳細な説明】
【背景技術】
【0001】
関連出願への相互参照：本発明は、２０２１年１１月１２日に提出された米国仮出願番号６３／２７８，９００の利益を主張するものであり、その内容および教示は、その全体が参照により本明細書に組み込まれます。
連邦政府が後援する研究または開発に関する声明：本発明は、国立科学財団によって授与された２１３５００７に基づく政府支援を受けて行われました。政府は、本発明に対して一定の権利を有します。
データの処理と保護は、安価なプロセッサと記憶媒体が利用可能になったことで、大きく変化した。ユーザは現在、データをローカルで処理し保存することも、ネットワークで接続されたサーバ、コンピューティングクラスタ、またはクラウドにデータを保存することもできる。さらに、クラウド・コンピューティングの選択肢には、パブリック・クラウドとプライベート・クラウドの両方がある。
連邦政府が後援する研究または開発に関する声明：本発明は、国立科学財団によって授与された２１３５００７に基づく政府支援を受けて行われました。政府は、本発明に対して一定の権利を有します。
データの処理と保護は、安価なプロセッサと記憶媒体が利用可能になったことで、大きく変化した。ユーザは現在、データをローカルで処理し保存することも、ネットワークで接続されたサーバ、コンピューティングクラスタ、またはクラウドにデータを保存することもできる。さらに、クラウド・コンピューティングの選択肢には、パブリック・クラウドとプライベート・クラウドの両方がある。
【0002】
ビッグデータの時代が到来し、ユーザはこれまで以上に大量のデータオブジェクトを保存し、処理することを望んでいる。例えば、表形式データ、ツリーベースのデータ、オーディオデータおよび／またはビデオデータのサイズがギガバイト範囲またはそれ以上に達することは珍しくない。このような大容量データオブジェクトの処理、保護、保存には、独特の課題がある。
【0003】
一般的なアプローチは、大きなオブジェクトを分割してそれぞれのコンピュータに保存することである。プログラムは、オブジェクト内のバイト境界を識別し、サイズが等しいか、ほぼ等しい部分を生成することによって、オブジェクトを分割することができる。分配方式で保存されたデータオブジェクトに対してデータ処理を実行するために、コンピュータは、元のオブジェクトの特定の部分または部分のグループを収集し、収集された部分に対して所望の処理タスクを実行し、結果を生成することができる。
【発明の概要】
【0004】
残念なことに、上述の分配アプローチは非効率的な場合がある。例えば、大きなデータオブジェクトを等しい部分またはほぼ等しい部分に分割する方法は、構造的特徴を無視し、異なるデータ部分間またはデータ部分間に依存関係をもたらす可能性がある。簡単な例として、多くの行の表形式データを含むデータオブジェクトを考えてみる：オブジェクトを分割して等しいサイズにすることは、行を途中で切断することを意味する。そのため、切断された行へのアクセスを含む後続のクエリは、データオブジェクトの２つの部分（行の先頭を保存する部分と、終わりを保存する部分）へのアクセスを必要とする場合がある。この２つの部分は、通常、ネットワーク上の異なるコンピュータに保存される。
【0005】
上記の例を続けると、（切断された行の両方の部分を含む）両方の部分をリクエスト元または他のノードに転送して戻し、そこで部分を再組み立てしてクエリを実行することがさらに必要になる場合がある。これらの行為には、ネットワーク上の大量のデータのコピーが含まれるため、大幅な非効率が生じる。
【0006】
上記に加え、従来のアプローチではコンテンツが無視される可能性がある。例えば、データオブジェクトの分割された部分は、データオブジェクト全体との関連性を失う可能性がある。また、表形式のデータ（例えば、行データのみが保存されている場合）では、フィールド名が欠落している可能性がある。このように、分配オブジェクトから意味のあるデータを抽出するには、目的の処理タスクを完了するために必要なすべてのピースを収集するために、異なるコンピュータに多くのネットワークアクセスを指示する必要がある。必要なのは、大きなデータオブジェクトをより効率的に扱う方法である。
【0007】
この必要性に少なくとも部分的に対処するために、ストレージクラスタにおいてデータオブジェクトを管理するための技術は、データオブジェクト内の境界においてデータオブジェクトを複数の部分に分割することを含む。この技術はさらに、データオブジェクトの部分を、個別に処理可能な単位を提供するセグメントに変換することと、ストレージクラスタの複数のコンピューティングノード間でセグメントを分配してそこに保存することとを含む。
【0008】
有利なことに、セグメントを個別に処理可能な単位として提供することは、データオブジェクトに対する処理タスクの実行に関連する作業負荷を、データオブジェクトのセグメントをローカルに保存するコンピューティングノードに効率的にプッシュダウンできることを意味する。したがって、この技術は、各コンピューティングノードが、そこに保存されたデータオブジェクトのセグメントのみに対して処理タスクを実行する、真の並列処理を可能にする。また、従来の方式に比べてネットワーク・トラフィックが大幅に削減される。例えば、コンピューティングノードのローカルストレージへの高速接続により、全体的な効率が大幅に向上する。さらに、セグメントが独立しているため、処理タスクを完了するためにコンピューティングノード間で（依存関係を解決するためなどの）通信がほとんど、あるいはまったく必要ない。
【0009】
上記に加え、圧縮データを分割、変換、分配する際に、特別な課題が発生する。圧縮データは容易に分割することができるが、結果として得られる部分は、一般に、前の部分のデータを参照せずに解凍することができない。例えば、典型的な解凍アルゴリズムでは、解凍を継続するためのディクショナリとなる、前の解凍のデータを参照する必要がある。しかし、圧縮データを単に分割して分配させただけでは、そのような前の解凍データが特に欠けてしまう。したがって、必要なのは、前の部分や他の部分へのアクセスを必要とせずに、個別の部分を解凍する能力を保持する圧縮データの分割方法である。
【0010】
この必要性に少なくとも部分的に対処するために、圧縮データを分割する改良された技術は、圧縮データを複数の部分に分割することを含む。この技術はさらに、現在の部分に関連づけて解凍状態を記憶することを含み、解凍状態は前の部分のデータに基づき、他の部分とは独立して現在の部分の解凍を可能にする。
【0011】
有利なことに、改良された技術により、圧縮データの一部を他の部分から独立して解凍することが可能になり、したがって、ストレージクラスタの異なるノード上などに分配して一部が保存されている場合の効率が大幅に向上した。
【0012】
特定の実施形態は、圧縮データを管理する方法を対象とする。本方法は、圧縮データを圧縮データの複数の部分に分割することを含み、部分は、（ｉ）圧縮データの現在の部分と、（ｉｉ）現在の部分の直前の圧縮データの前の部分とを含む。本方法はさらに、前の部分の解凍に基づいて解凍状態をキャプチャし、解凍状態が現在の部分の解凍を可能にすることと、現在の部分が前の部分を参照することなく解凍可能であるように、解凍状態に関連付けて現在の部分を保存することとを含む。
【0013】
いくつかの例では、現在の部分に関連して記憶された解凍状態は、前の部分の解凍されたデータの範囲から形成されたディクショナリを含む。
【0014】
いくつかの例では、解凍されたデータの範囲は長さを有し、前の部分の終わりまで延びる。
【0015】
いくつかの例では、本方法はさらに、圧縮データの部分をストレージクラスタのストレージノード上のそれぞれのセグメントに保存し、メタデータにおいて、ストレージノード上のそれぞれのセグメントの位置を追跡することを含む。
【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】
消失訂正符号化は、データ配置に一定の制約を課し得ることを理解されたい。例えば、同じリペアグループ８０２に属する２つのセグメント１７０は、通常、同じディスクドライブ（例えば、ＳＳＤ、磁気ディスクドライブなど）に保存されるべきではない。そうすることは、消失訂正符号化の冗長性を損ない、セグメントをデータ損失の増大リスクにさらすことになるからである。同様の理由で、同じリペアグループ８０２に属する２つのセグメント１７０は、通常、同じコンピューティングノード１２０に保存されるべきではない。そうすることで、例えば、コンピューティングノード１２０に障害が発生した場合の冗長性が低下するからである。しかし、これらのルールは、通常、異なるリペアグループ８０２には適用されない。例えば、２つのセグメントが同じリペアグループ８０２に属さない限り、異なるリペアグループ８０２に属するセグメント１７０を同じコンピューティングノード１２０に保存しても、冗長性の実質的な損失は生じない。例えば、１つのコンピューティングノード１２０が、所定のデータオブジェクト１６０を保護するＲ個のリペアグループのそれぞれから１つのセグメント１７０を保存することが許容される場合がある（同じデータオブジェクトの合計Ｒ個のセグメント）。
【0110】
さらに、消失訂正符号化はデータを保護する１つの方法であり、他の方法はレプリケーションであることを理解されたい。一例として、データオブジェクト１６０とそれに関連するリペアデータおよび／またはレプリカはオブジェクトストアのバケットに存在し、データ保護スキームはバケットごとに適用される。データ保護にレプリケーションを使用するバケットは、その中に含まれるすべてのオブジェクト１６０を含む、すべてのコンテンツの保護にレプリケーションを使用することになる。同様に、データ保護に消失訂正符号化を使用するバケットは、そのすべてのコンテンツに消失訂正符号化を使用する。消失訂正符号化パラメータＫおよびＭは、バケットごとに選択および適用することもできる。したがって、図９の構成は、オブジェクト１６０ｘを含むバケットがこれらの設定を使用するため、Ｋ＝９およびＭ＝３の消失訂正符号化を使用することができ、したがって、これらの設定は、バケットのすべてのコンテンツにグローバルに適用される。
【0111】
図１０は、データオブジェクト１６０とそのセグメント１７０を管理する際に使用される様々な量を決定するための例示的な方法１０００を示す。方法１０００は、消失訂正符号化を使用したデータ保護を想定しており、セグメント１７０の所望のターゲットサイズ３２０（図３）、およびデータオブジェクト１６０を保護するために使用するリペアグループ８０２の数Ｒ（図９）を決定するために使用することができる。方法１０００は、例えば、ゲートウェイ１１０によって、ストレージクラスタ１３０のノード１２０によって、またはクラスタ１３０に接続可能な他のコンピュータによって実行され得る。方法１０００の開始時に、データオブジェクト１６０のサイズと（Ｋ＋Ｍ消失訂正符号化で使用されるような）数Ｋとが予め知られていると仮定される。
【0112】
１０１０において、方法１０００は、ノード１２０によって効率的に処理され得るセグメント１７０の最大サイズＳＭＡＸを確立する。最大サイズは、ノード１２０のハードウェア仕様（例えば、クロック速度、コア数、メモリ量など）、処理タスクの予想される待ち時間およびユーザの期待などの実用的な考慮事項に基づいてもよい。ＳＭＡＸの典型的な範囲は、例えば、数百キロバイトから数メガバイトの間である。
【0113】
１０１２において、本方法は、列あたりの平均バイト数ＢＣを計算する。一例では、ＢＣの値は、データオブジェクト１６０のサイズ「ＯｂｊｅｃｔＳｉｚｅ」と、データオブジェクト１６０を保護するために使用されるＫ＋Ｍ消失訂正符号化で使用される数Ｋとに基づいてもよい。例えば、ＢＣ＝ＯｂｊｅｃｔＳｉｚｅ／Ｋである。図９に簡単に戻ると、ＢＣは、図示された列における列ごとのデータの平均量を表すことがわかる。
【0114】
１０１４で、方法１０００は、例えば、ＢＣをＳＭＡＸで割り、最も近い整数に切り上げることによって、リペアグループの数Ｒを計算する。より具体的には、リペアグループの数は、Ｒ＝ＢＣ／ＳＭＡＸとして計算され、切り上げられる。
【0115】
１０１６において、本方法はターゲットセグメントサイズ３２０をＳＴＡＲ＝ＢＣ／Ｒとして計算する。結果の量ＳＴＡＲは、例えば、データオブジェクト１６０を分割するときに境界２５２の探索を開始する場所を決定する際に、スプリッタ２２０に提供され得る。
【0116】
１０１８で、方法１０００は、少なくともＳＴＡＲと同じ大きさの部分２５０を生成する方法でデータオブジェクト１６０を分割するように、例えば、ＳＴＡＲを越えて次の境界２５２まで延びる部分２５０を生成するように、スプリッタ２２０に指示する。
【0117】
このようにして、方法１０００は、特定のデータオブジェクト１６０に使用されるターゲットセグメントサイズ３２０およびリペアグループの数Ｒを確立するための有用なガイドラインを提供する。これらの量の実際の選択は、管理者の裁量を伴う場合があり、説明した以外の要因によって左右される場合がある。したがって、方法１０００は、必須ではなく、助言的であることを意図している。
【0118】
図１１は、例示的なコンピューティングノード１２０をさらに詳細に示す。コンピューティングノード１２０は、ストレージクラスタ１３０のコンピューティングノード１２０－１、１２０－２、および１２０－３を代表することを意図している。また、図１のゲートウェイ１１０を代表することも意図している。
【0119】
示されるように、コンピューティングノード１２０は、１つまたは複数のネットワークインターフェースカード（ＮＩＣ）１１１０などの１つまたは複数の通信インターフェース、１つまたは複数の処理チップおよび／またはアセンブリなどのプロセッサ１１２０のセット、ソフトウェアを実行するための揮発性メモリなどのメモリ１１３０、および１つまたは複数のソリッドステートディスク（ＳＳＤ）、磁気ディスクドライブなどの永続ストレージ１１４０を含む。プロセッサ１１２０のセットとメモリ１１３０は共に制御回路を形成し、この制御回路は、本明細書で説明するような様々な方法および機能を実行するように構成および配置される。また、メモリ１１３０は、実行可能命令の形態で実現される、図１および図２に示されるような様々なソフトウェア構成を含む。実行可能命令がプロセッサ１１２０のセットによって実行されると、プロセッサ１１２０のセットはソフトウェア構成の動作を実行する。一例では、プロセッサ１１２０のセットのうちの１つ以上がネットワークカード１１１０（複数可）に存在してもよく、これにより、ネットワーク１４０を介した高速通信が促進され、帯域幅と効率が向上する。
【0120】
図１２、図１３、および図１４は、環境１００に関連して実施される可能性のある、例示的な方法１２００、１３００、および１４００を示しており、上述した特徴のいくつかの要約を提供している。方法１２００、１３００、および１４００である。このような方法は、一般的には、例えば、図１および図２に関連して説明したソフトウェア構成体によって実行される。方法１２００、１３００、および１４００の様々な行為は、任意の適切な方法で順序付けることができる。従って、実施形態は、いくつかの行為を同時に実行することを含み得る、図示されたものとは異なる順序で行為が実行されるように構築され得る。
【0121】
図１２は、データオブジェクトを管理する例示的な方法１２００を示す。１２１０で、データオブジェクト１６０は、データオブジェクト１６０内の境界２５２で複数の部分２５０に分割される（図２参照）。境界２５２は、データオブジェクトのタイプ（例えば、ＣＳＶ、ＪＳＯＮ、ＸＭＬ、Ｐａｒｑｕｅｔ、ビデオなど）に従って、データオブジェクト１６０の処理可能な単位２５０間のセパレータを提供する。１２２０において、部分２５０は、データオブジェクト１６０のタイプと同じタイプの個別に処理可能な単位を提供するセグメント１７０に変換される。例えば、データおよび／またはメタデータは、セグメント１７０間の依存関係を低減又は排除するために、１つの部分２５０から他の部分へコピーされてもよく、他の修正が行われてもよい。１２３０において、セグメント１７０は、ストレージクラスタ１３０の複数のコンピューティングノード１２０の間に分配され、そこに保存される。
【0122】
図１３は、データオブジェクトを管理する例示的な方法１３００を示す。１３１０において、データオブジェクト１６０は、例えば、スプリッタ２２０（図２）の操作によって、複数のセグメント１７０に分割される。１３２０において、セグメント１７０は、ストレージクラスタ１３０の複数のコンピューティングノード１２０に分配される。１３３０において、分配処理タスクがストレージクラスタ１３０によって実行される。分配処理タスクは、ストレージクラスタ１３０の複数のそれぞれのコンピューティングノード１２０によって、そこに保存されたそれぞれのセグメント１７０またはセグメント１７０のセットに対して独立して実行される。
【0123】
図１４は、データオブジェクトを管理する例示的な方法１４００を示す。１４１０では、データオブジェクト１６０が複数のセグメント１７０に分割され、セグメント１７０の少なくとも一部は互いに異なる長さを有する（図７および図８参照）。１４２０において、セグメント１７０は、ストレージクラスタ１３０の複数のコンピューティングノード１２０に分配される。１４３０において、Ｋ個のセグメント１７０は、Ｋ個のセグメントから生成されたリペアデータのＭ個のエレメント８１０を使用して保護され、各々のＭ個のエレメント８１０は、Ｋ個のセグメントから選択されたセグメントのそれぞれのグループ化（例えば、Ｋ個のセグメントを有するもののグループ、Ｋ－１個のセグメントを有するもののグループなど）から計算されたリペアデータを保存する複数の範囲（例えば、Ｒｎｇ１、Ｒｎｇ２など）を有する。
【0124】
ストレージクラスタ１３０においてデータオブジェクト１６０を管理するための改良された技術は、データオブジェクト１６０を、データオブジェクト１６０内の境界２５２において複数の部分２５０に分割することを含む。この技術はさらに、データオブジェクト１６０の部分２５０を、個別に処理可能な単位を提供するセグメント１７０に変換すること、およびセグメント１７０をストレージクラスタ１３０の複数のコンピューティングノード１２０の間に分配してそこに保存することを含む。
【0125】
セクションＩＩ：圧縮データの分割、処理、および保護
本セクションでは、圧縮データを管理する例について説明する。上記のセクションＩで説明したような特徴および方法論のいずれもが、このセクションＩＩで説明する実施形態でも使用できることを理解されたい。しかしながら、セクションＩＩの特定の実施形態は、セクションＩに記載された実施形態とは独立して使用することができる。したがって、特に反対のことが示されていない限り、セクションＩの特徴は、以下に説明するセクションＩＩの特徴のいずれにも必須または必要であるとみなされるべきではない。
本セクションでは、圧縮データを管理する例について説明する。上記のセクションＩで説明したような特徴および方法論のいずれもが、このセクションＩＩで説明する実施形態でも使用できることを理解されたい。しかしながら、セクションＩＩの特定の実施形態は、セクションＩに記載された実施形態とは独立して使用することができる。したがって、特に反対のことが示されていない限り、セクションＩの特徴は、以下に説明するセクションＩＩの特徴のいずれにも必須または必要であるとみなされるべきではない。
【0126】
セクションＩＩの内容の概要：
圧縮データを分割する改良された技術は、ファイルまたはストリーム内の圧縮データを受信し、ファイルまたはストリームのそれぞれの圧縮部分を保存する複数のセグメントにファイルまたはストリームを分割することを含む。この技術はさらに、現在のセグメントに関連付けて解凍状態を保存することを含み、解凍状態は前のセグメントのデータに基づいており、他のセグメントとは独立して現在のセグメントの解凍を可能にする。
圧縮データを分割する改良された技術は、ファイルまたはストリーム内の圧縮データを受信し、ファイルまたはストリームのそれぞれの圧縮部分を保存する複数のセグメントにファイルまたはストリームを分割することを含む。この技術はさらに、現在のセグメントに関連付けて解凍状態を保存することを含み、解凍状態は前のセグメントのデータに基づいており、他のセグメントとは独立して現在のセグメントの解凍を可能にする。
【0127】
いくつかの例では、現在のセグメントに関連付けられて保存された解凍状態は、前のセグメントの解凍されたデータの範囲から形成されたディクショナリを提供する。
【0128】
いくつかの例では、解凍されたデータの範囲は所定の長さを有し、前のセグメントの終わりまで延びる。
【0129】
いくつかの例はさらに、圧縮データの次のセグメントに関連付けて、現在のセグメントの終わりに現れる解凍データの範囲を、次のセグメントの解凍状態として保存することを含む。
【0130】
いくつかの例では、圧縮ファイルまたはストリームは、一連のブロック（たとえば、デフレートブロック）を含み、ファイルまたはストリームを複数のセグメントに分割することは、隣接するブロック間の境界で実行される。
【0131】
いくつかの例では、圧縮データは、一般的なＧＺＩＰソフトウェアで使用されているＺＬＩＢで使用されているＤｅｆｌａｔｅアルゴリズムを使用して圧縮される。
【0132】
いくつかの例では、この技術はさらに、ファイルまたはストリームから形成されたセグメントと、セグメントに含まれるファイルまたはストリームのそれぞれのバイト範囲とを関連付けるオブジェクトメタデータを保存することを含む。いくつかの例では、オブジェクトメタデータに保存されるバイト範囲は、圧縮データの範囲を含む。いくつかの例では、オブジェクトメタデータに保存されたバイト範囲は、非圧縮データの範囲を含む。いくつかの例では、オブジェクトメタデータに保存されたバイト範囲は、圧縮データの範囲と非圧縮データの範囲の両方を含む。いくつかの例では、オブジェクトメタデータは、圧縮バイト位置に基づいておよび／または非圧縮バイト位置に基づいて、圧縮ファイルまたはストリームのデータへのアクセスを許可する。
【0133】
いくつかの例では、この技術はさらに、セグメントを、それらのセグメントに保存されたデータの行または記録のそれぞれの範囲に関連付けるオブジェクトメタデータを保存することを含む。行または記録の範囲は、番号（例えば、１行目、２行目、１００行目など）によって識別することができる。特定の例では、オブジェクトメタデータは、第１の行または記録の番号と、関連するセグメントに保存された行または記録のカウントを示すことができる。行または記録の範囲を保存すると、行番号または記録番号に基づく検索が容易になる。
【0134】
いくつかの例では、ファイルまたはストリームを複数のセグメントに分割することは、圧縮ファイルまたはストリームのデータの内容に関係なく実行される。
【0135】
他の例では、ファイルまたはストリームを複数のセグメントに分割することは、圧縮ファイルまたはストリームのコンテンツに応じて実行される。
【0136】
例えば、ファイルまたはストリームの分割は、関連するデータをまとめた形で実行することができる。
【0137】
一例では、分割は、セグメントのターゲットサイズに基づいて分割のターゲット位置を特定することを含み得るが、その後、関連するデータを一緒に保つように、ターゲット位置とは異なる位置でファイルまたはストリームを分割する。
【0138】
いくつかの例では、分割は、ファイルまたはストリームの少なくとも一部のデータを解凍することと、ＣＳＶデータの行の終わり、ＪＳＯＮ記録の終わり、ビデオデータのキーフレーム（ＩＤＲフレーム）など、解凍されたデータ内の自然境界を突き止めることとを含み得る。このような例では、分割はさらに、ファイルまたはストリーム内の分割位置を、位置付けられた自然境界に続く第１のブロック境界として特定することを含む。
【0139】
いくつかの例では、この技術は、自然境界と分割位置の間に現れるフィックスアップデータを、次のセグメントのメタデータに保存することをさらに含む。
【0140】
いくつかの例では、この技術は、現在のセグメントと次のセグメントの少なくとも一方のメタデータに、自然境界の位置をマークすることをさらに含む。
【0141】
いくつかの例では、フィックスアップデータは、次のセグメントのディクショナリを形成する解凍データの範囲の長さを超えない長さを有する。このような場合、フィックスアップデータの保存は、次のセグメントのメタデータにディクショナリを保存する一部として行われ、追加の保存は必要ない。
【0142】
他の例では、フィックスアップデータは、ディクショナリの解凍データの範囲の長さを超える長さを有する。このような場合、フィックスアップデータを保存することは、次のセグメントのメタデータに、追加のフィックスアップデータ、すなわち、ディクショナリを超えるフィックスアップデータを保存することを含む。
【0143】
いくつかの例では、この技術はさらに、現在のセグメントの解凍されたデータ内に、ヘッダーおよび／またはフッターなどの記述的コンテンツを識別し、次のセグメントのデータの独立した処理を容易にするために、次のセグメントのメタデータに記述的コンテンツを保存することを含む。
【0144】
いくつかの例では、この技術はさらに、セクションＩでセグメントについて説明したいずれかの方法で、セグメントを保存、保護、および／または処理することを含む。
【0145】
前述の「セクションＩＩの内容の概要」は、読者が本明細書に提示された例示的な特徴を容易に把握するのを支援するための例示目的で提示されたものであるが、この概要は、必須の要素を規定すること、または本明細書の実施形態を何らかの形で限定することを意図するものではない。上述の特徴は、技術的に理にかなった任意の方法で組み合わせることができ、そのような組み合わせが明示的に特定されているか否かにかかわらず、そのような組み合わせのすべてが本明細書に開示されることを意図していることを理解されたい。
セクションＩＩの内容の説明：
セクションＩＩの内容の説明：
【0146】
図１５は、圧縮ファイル１５１０を解凍するための構成例を示す。ファイル１５１０は、本明細書の改良に従って分割可能なタイプである。例えば、ファイル１５１０は、一般的なＧＺＩＰソフトウェアによって一般的に使用されるＺＬＩＢによって使用されるようなＤｅｆｌａｔｅアルゴリズムを使用して圧縮されてもよく、または示された方法で解凍することができる他のタイプのファイルであってもよい。ＺＬＩＢについての詳しい情報はインターネット＜URL：http://zlib.net/＞参照。ＺＬＩＢのＤｅｆｌａｔｅアルゴリズムについての詳細は、インターネット＜URL：http://zlib.net/feldspar.html＞参照。ＧＺＩＰについての詳しい情報はインターネット＜URL：http://www.gnu.org/software/gzip/＞参照。図１５の例は圧縮ファイルに関するものであるが、同様の動作は圧縮ストリームのために実行されてもよい。
【0147】
ファイル１５１０は、たとえば、ヘッダー１５１２、圧縮データのペイロード１５１４、およびフッター１５１６を含むとわかる。解凍は、ペイロード１５１４の先頭（点Ｐ０）から始まり、順方向に進み得る。点Ｐ１において、解凍は、初期解凍領域１５２０ａが生成される点まで進んでいる。この初期領域の解凍は、たとえば、ディクショナリなしで、デフォルトディクショナリで、またはユーザ指定のディクショナリで進行することができる。解凍されたデータは、ファイル１５１０の後続のデータを解凍するためのディクショナリ１５３０を形成する。たとえば、ディクショナリ１５３０は、単に最新の解凍データであり、ディクショナリ１５３０に続く圧縮データは、ディクショナリ１５３０内のバイト範囲への参照を含む。そのような参照は、例えば、オフセット（例えば、現在の位置から後退したバイト数）および長さとして提供され得る。
【0148】
一例では、ディクショナリ１５３０は、たとえば３２ｋＢなど、決められた長さの解凍データのスライディングウィンドウとして提供される。解凍が進むにつれて、ディクショナリウィンドウ１５３０は、現在のバイト位置のすぐ後ろに留まりながら進む。例えば、ディクショナリ１５３０は、解凍された領域１５２０ｂの最後に表示され、その後、解凍された領域１５２０ｃの最後に表示される（図１５の下部）。
【0149】
図１５に示す例はファイル１５１０のものであるが、同様の原理がストリームにも適用される。したがって、実施形態はファイルに限定されない。
【0150】
図１６は、圧縮データを解凍する能力を保持しながら、図１５の圧縮ペイロード１５１４を分割する例を示す。ここでは、圧縮ペイロード１５１４は、位置１６０２（例えば、圧縮データ内の指定されたバイトオフセット）で分割される。圧縮ペイロードの第１の部分２５０ａは第１のセグメント１７０ｘに行き、圧縮データの第２の部分２５０ｂは第２のセグメント１７０ｙに行く。部分２５０ａおよび２５０ｂならびにセグメント１７０ｘおよび１７０ｙは、セクションＩに関連して説明した部分２５０およびセグメント１７０の例であってよく、例えば、スプリッタ２２０によって形成される部分およびトランスフォーマ２３０によって形成されるセグメントであってよい（図２）。
【0151】
圧縮ペイロードを分割する手順がここで停止すると、第２の圧縮部分２５０ｂは、第１の圧縮部分２５０ａから独立して解凍することができない。これは、第２の部分２５０ｂの解凍が、ディクショナリ１５３０（例えば、最近解凍されたデータの範囲）へのアクセスを有することに依存するからである。従来のＤｅｆｌａｔｅ解凍は、第１の部分２５０ａについては独立して機能するが（例えば、デフォルトディクショナリやユーザが選択したディクショナリを利用するか、またはディクショナリを利用しないため）、第２の部分２５０ｂについては、必要なディクショナリ１５３０が欠落しているため、独立して機能しない。
【0152】
この欠陥に対処するために、本明細書の実施形態では、第１の部分２５０ａの終了時点のディクショナリ１５３０の状態をキャプチャし、そのディクショナリを第２の部分２５０ｂに関連するメタデータとして保存する。ここでは、このディクショナリを、前の部分の終わりからのものであることを識別するために、参照１５３０ｅと呼ぶ。ディクショナリ１５３０ｅは、様々な方法で第２の部分２５０ｂに関連付けて保存することができる。これらには、例えば、第２の圧縮部分２５０ｂを含むセグメント１７０ｙのヘッダーとして、セグメント１７０ｙのフッターとして、または図１に関連して説明したセグメントメタデータ１２４のような別のメタデータとして、ディクショナリを保存することが含まれる。いくつかの例では、フラグおよび／または他の設定など、追加の解凍状態メタデータがディクショナリ１５３０ｅとともに保存されることがある。たとえば、Ｉｎｆｌａｔｅアルゴリズムの状態全体が保存される場合がある。
【0153】
分割位置１６０２は、圧縮ペイロード１５１４の長さに沿った任意の位置であり得ることを理解されたい。したがって、分割位置１６０２でディクショナリ１５３０をキャプチャするには、ペイロード１５１４を最初から解凍し、位置１６０２に達すると解凍を一時停止する必要がある場合がある。この時点で、ディクショナリ１５３０は、単に現在のディクショナリ状態として（例えば、ＺＬＩＢなどのライブラリの呼び出しを経由して）取得されてもよい。圧縮ペイロード１５１４の解凍は、その後、必要に応じて（例えば、追加の分割が必要な場合）再開されてもよい。
【0154】
第２の部分２５０ｂのメタデータにディクショナリ１５３０ｅを保持することにより、第２の部分２５０ｂを第１の部分２５０ａから独立して解凍することが可能になる。これは、ディクショナリ１５３０ｅを使用して第２の部分２５０ｂの第１のバイトを解凍し、ディクショナリが第２の部分２５０ｂの解凍されたデータから完全に形成されるまで、例えば図１５で説明した方法でディクショナリを前進させることによって行うことができる。その後、通常の方法で解凍を進めることができる。ディクショナリ１５３０ｅは、それ自体、圧縮形態で、例えば独立して圧縮オブジェクトとして、第２の部分２５０ｂに保存されてもよく、その後、第２の部分２５０ｂの解凍が所望されるときに解凍されることを理解すべきである。しかし、ディクショナリ１５３０ｅの圧縮保存は必須ではない。
【0155】
図１６の例では、２つの部分２５０を形成する単一の分割のみが示されているが、圧縮ペイロード１５１４は、任意の所望の数の部分に分割されてもよい。そのような場合、第１の部分を除く各圧縮部分は、直前の部分の終了時点のそれぞれのディクショナリ１５３０ｅ（および他の任意の所望の解凍状態情報）を含む。
【0156】
部分２５０ａおよび２５０ｂは、圧縮ペイロード１５１４のそれぞれの範囲と好ましくは同一である圧縮データを保存することを理解されたい。したがって、分割行為は、好ましくは、あらゆる点で元の圧縮データを保持する。解凍は、ディクショナリ１５３０ｅを提供するため（同様に、後述する他の目的のため）に使用され得るが、ペイロード１５１４全体の解凍されたデータを保存することは、通常必要でも望ましくもない。むしろ、解凍されたデータは、通常必要とされず、所望のときにいつでも要求に応じて得ることができる。
【0157】
いくつかの例では、圧縮ペイロード１５１４の分割は、対応する非圧縮データに関する情報に少なくとも部分的に基づくことがある。例えば、データ処理時のコンピューティングリソースのバランスを取ることができるため、データが解凍されたときに類似したデータ量のセグメントを保存することが望ましい場合がある。従って、分割は、解凍されたデータの同様のサイズに解凍される部分２５０を形成するような方法で行われることがある。これは、（圧縮データの）部分自体のサイズが著しく異なることを意味する場合であっても同様である。したがって、圧縮データを複数の部分に分割する場合、圧縮データの部分の非圧縮バージョンは、互いに大きく異なる場合がある圧縮データの対応する部分よりもサイズが互いに近い場合がある。
【0158】
図１７は、図１７のペイロード１５１４が複数のブロック１７１０で構成されていると見られる点を除き、図１６と同様の構成を示している。このようなブロック１７１０は、本明細書では、デフレート（サイズ圧縮）された「デフレートブロック」と呼ぶことがある。ブロック１７１０のサイズは均一であってもよいが、これは必須ではない。ブロック１７１０間の境界は、任意の適切な方法で示すことができる。
【0159】
いくつかの例では、ブロック１７１０は、ペイロード１５１４を分割するときに一緒にされ得る。したがって、分割はブロック境界（または「境界」）で行われることがある。例えば、圧縮サイズおよび／または解凍サイズなどに基づいて、所望の分割位置が識別されると、実際の分割位置は、例えば、最も近いブロック境界まで前方または後方に移動されてもよい。
【0160】
図１８は、圧縮ペイロード１５１４を分割する例示的な方法１８００を示し、上述した活動の一部を要約している。方法１８００は、例えば、タイプ検出器２１０、スプリッタ２２０、およびトランスフォーマ２３０を含む、図２に関連して説明されたゲートウェイ１１０によって実行されてもよい。
【0161】
１８１０において、圧縮データが、例えば、圧縮ファイルまたはストリームの形態で受信される。ファイルまたはストリームは圧縮ペイロード１５１４を含み、このペイロードは例えばＺＬＩＢのＤｅｆｌａｔｅ圧縮アルゴリズムを使用して圧縮される。
【0162】
１８２０において、圧縮ペイロード１５１４内の１つまたは複数の分割位置１６０２が決定される。分割位置１６０２の決定は、圧縮部分２５０の所望のサイズおよび／または圧縮部分２５０の非圧縮データの所望のサイズを含み得る、任意の数の要因に基づいてもよい。非圧縮サイズを考慮する場合、方法１８００は、ペイロード１５１４の部分の実際の解凍（例えば、分割のためのディクショナリ１５３０を識別するときに実行される）に基づいて、非圧縮サイズを計算してもよい。分割位置１６０２は、ペイロード１５１４に保存されたデータの性質またはタイプを考慮して、または考慮せずに、決定され得る。
【0163】
１８３０において、ペイロード１５１４の圧縮データは、決定された分割位置（複数可）１６０２に基づいて、複数の部分２５０としてレンダリングされる。例えば、スプリッタ２２０は、圧縮ペイロード１５１４を部分２５０に分離し、それをトランスフォーマ２３０がそれぞれのセグメント１７０に配置する。独立した解凍を可能にするために、ディクショナリ１５３０ｅは、例えば、それぞれのセグメント１７０とともに保存されたメタデータとして、第１の部分を除く各部分２５０とともに提供される。圧縮部分２５０とともに保存されるディクショナリ１５３０ｅは、直前の部分の終了時点の解凍状態を反映する。
【0164】
１８４０において、方法１８００は、圧縮部分２５０を保存するセグメント１７０でカバーされるデータの範囲を反映するために、図１のメタデータ１１２などのオブジェクトメタデータを更新することをさらに含む。ペイロード１５１４の分割は、そのデータの実行中の解凍の実行を含むので、オブジェクトメタデータ１１２は、圧縮データの範囲と同様に、非圧縮データの範囲を反映することができる。オブジェクトメタデータ１１２はまた、行または記録の範囲、行または記録の総数、圧縮バイトの総数、非圧縮バイトの総数、およびその他の有用な情報を反映することができる。いくつかの例では、オブジェクトメタデータ１１２は、ＣＳＶデータ、ＪＳＯＮデータなどのデータの性質またはタイプを識別し、これは、例えば、タイプ検出器２１０および／またはスプリッタ２２０によって識別され得る。
【0165】
図１９は、このようなオブジェクトメタデータ１１２の例をさらに詳細に示す。示されるように、オブジェクトメタデータ１１２は、セグメント１７０（ＳｅｇＩＤとして指定される）を、圧縮された開始オフセット、終了オフセット、および長さ、ならびに圧縮されていない開始オフセット、終了オフセット、および長さに関連付けることができる。オフセットおよび長さの単位は、たとえばバイトであってもよい。このようにして、オブジェクトメタデータ１１２は、その範囲が圧縮データの範囲として表現されるか、非圧縮データの範囲として表現されるかにかかわらず、任意のバイト範囲へのランダムアクセスをサポートすることができる。いくつかの実施形態では、開始オフセットが既知である場合、終了オフセットと長さのいずれかが他方を意味するため、終了オフセットと長さの両方を保存することを避けることができることに留意されたい。
【0166】
一例として、クライアントはファイルの一部を圧縮バイト範囲としてリクエストすることができる。オブジェクトメタデータ１１２にクエリすることにより、クライアントは、リクエストされたデータを保存するセグメント１７０を、例えば、リクエストされた範囲を包含する圧縮開始オフセットと終了オフセットに関連付けられたＳｅｇＩＤとして識別することができる。次に、リクエストされたバイトは、バイト単位でカウントを進めてリクエストされた範囲の開始と終了を特定することによって、識別されたセグメント１７０からアクセスされ得る。
【0167】
リクエストされた圧縮バイトの範囲が複数のセグメント（例えば、連続するＳｅｇＩＤを有するセグメント）にまたがる場合、そのようなセグメントは、リストされた開始オフセットおよび終了オフセットに基づいて、再びオブジェクトメタデータ１１２から識別され得る。クラスタは第１のセグメントを識別し、バイト単位でカウントを進めてリクエストされた範囲の第１のバイトを特定し、リクエストされた範囲の最後のバイトに遭遇するまで、１つまたは複数の後続のセグメントに交差しながらバイト単位でカウントを進め続けることができる。その後、クラスタは、リクエストに対する応答として、第１のバイトと最後のバイトの間の圧縮データを返すことができる。
【0168】
あるいは、クライアントはファイルの一部を非圧縮バイトの範囲としてリクエストし得る。例えば、クライアントはオブジェクトメタデータ１１２にクエリして、リクエストされた範囲の非圧縮バイトのデータを保存するセグメント１７０を、例えばリクエストされた範囲を包含する非圧縮の開始オフセットと終了オフセットに関連付けられたＳｅｇＩＤとして識別し得る。次に、リクエストされたデータは、識別されたセグメント１７０から、識別されたセグメントに保存された部分２５０の全部または一部を解凍し、解凍されたデータ内をバイト単位でカウントして、リクエストされた範囲の先頭と終わりを特定することによってアクセスすることができる。その後、クラスタは、リクエストに対する応答として、先頭と終わりの間の非圧縮バイトを返すことができる。注目すべきは、これを実現するために、他のセグメントに保存されたデータを解凍する必要はないということである。むしろ、指示されたセグメント１７０を独立して解凍してもよい。
【0169】
リクエストされた非圧縮バイトの範囲が複数のセグメントにまたがる場合、それらのセグメントはオブジェクトメタデータ１１２から識別され、順に解凍され得る。たとえば、クラスタは、最初に識別されたセグメントを解凍し、バイト単位でカウントを進め、リクエストされた範囲の第１のバイトを特定する。次にクラスタは、リクエストされた範囲の最後のバイトに遭遇するまで、順次解凍される１つまたは複数の後続のセグメントを非圧縮のバイト単位でカウントを進め続ける。その後、クラスタは第１のバイトと最後のバイトの間の非圧縮データをクエリ応答として返す。
【0170】
いくつかの例では、オブジェクトメタデータ１１２は、特定のセグメント１７０に関連して、開始行または記録番号１９１０と、行または記録のカウント１９２０とをさらに保存し得る。行または記録は、例えば、ＣＳＶ行（ライン）、ＪＳＯＮ記録、Ｐａｒｑｕｅｔ行グループなどに関連し得る。行または記録は、行または記録番号（例えば、１行目、２行目、１００行目など）に基づいて識別され得る。例えば、ペイロード１５１４を解凍するとき、スプリッタ２２０は、第１の行または記録の番号および各部分２５０におけるそのような行または記録のカウントを識別するように、解凍されたデータに行または記録を追跡してよい。スプリッタ２２０は、いくつかの例では、終了行または記録番号も追跡してよい。
【0171】
ＣＳＶデータに対してスプリッタ２２０を動作させる場合、最初の行がヘッダー行であるかどうかを判断する必要はない。したがって、例えば、開始行／記録１９１０とカウント１９２０は、ヘッダー行とコンテンツ行を区別する必要はない。むしろ、ヘッダー行とコンテンツ行はすべて同じようにカウントしてもよい。ＣＳＶデータを読み取るための後のリクエストは、（ヘッダーを無視して）絶対的な用語で行を指定してもよいし、ヘッダーに続く行番号に基づいて行を指定してもよい。ヘッダー行が指定された場合、内容行は単純に絶対行数より一つ少ない行数として計算され得る。この調整は、データがリクエストされたときに容易に行うことができ、分割および保存時に行う必要はない。とはいえ、本明細書では、データがヘッダー行を含むかどうかのしるしをオブジェクトメタデータ１１２が保存することを妨げるものではない。オブジェクトメタデータ１１２は、関連するデータが圧縮形式で保存されるか非圧縮形式で保存されるかに関係なく、行または記録の開始番号１９１０およびカウント１９２０を保存し得ることを理解されたい。
【0172】
開始行または記録番号１９１０とカウント１９２０の保存は、ルックアップを非常に容易にする。クライアントが、指定されたデータオブジェクトのＣＳＶ行「１０００」をリクエストする場合を考える。リクエストに応答して、ストレージクラスタ１３０は、オブジェクトメタデータ１１２をチェックして、たとえばメタデータ９１０および９１２に基づいて、ＣＳＶ行１０００を保存する特定のセグメントを識別することができる。次に、クラスタは、識別されたセグメントにアクセスし、そのデータを（全部または部分的に）解凍し、開始行／記録１９１０から行１０００までカウントを進めてもよい。その後、クラスタはＣＳＶデータの行１０００を抽出してクライアントに返すことができる。同様の行為は、複数のセグメントにまたがる範囲を含む行の範囲に対して実行されてもよい。記録の範囲または行が複数のセグメントにまたがる場合、クラスタはオブジェクトメタデータ１１２からそのような各セグメントを識別し、各セグメントに順番にアクセスし、そのデータを解凍し、指定された行を抽出し得る。
【0173】
時には、非圧縮データのクエリされたバイト範囲が行や記録の途中で始まったり終わったりして、行や記録の一部だけがリクエストされた範囲に含まれることがある。このような場合、行または記録全体を含めるか、または除外するかのいずれかの規則を採用し得る。たとえば、行または記録のいずれかのバイトがリクエストされたときは常に、行または記録全体を返すという規則を指定することができる。この規則を満たすためには、返されるデータが圧縮されていても、その行または記録の境界を特定するために解凍を実行する必要があり得る。
【0174】
図２０は、コンテンツセンシティブな方法でデータを分割する方法２０００の例を示す。コンテンツセンシティブな分割は、セグメントに保存されたデータが他のセグメントから独立して処理されるように、データの個別に処理可能な単位をそれぞれのセグメント１７０に配置しようとする場合に有用である。方法２０００は、例えば、図２に関連して説明したスプリッタ２２０によって実行することができる。
【0175】
この例では、圧縮ペイロード１５１４は、関連するデータを一緒に保ち、それによってストレージクラスタ１３０のノード１２０による関連するデータの独立した処理を容易にする方法で分割される。方法２０００は以下のように進行し得る。
【0176】
２０１０において、ターゲットサイズが第１の部分２５０ａに対して提供され得る。上述したように、ターゲットサイズは、圧縮データのサイズおよび／または対応する非圧縮データのサイズに基づいてもよい。ターゲットサイズは、例えば、ペイロードの開始オフセットにターゲットサイズを加えたものとして、ペイロード１５１４内のターゲット分割位置を意味する。ターゲットサイズは、すべての部分２５０に対して一度に提供されてもよいし、異なる部分２５０に対して個別に提供されてもよい。
【0177】
２０２０において、ペイロード１５１４の解凍が開始される。最初の解凍は、ディクショナリ１５３０ｅを必要とせず、むしろ、デフォルトディクショナリ、ユーザが選択したディクショナリを使用するか、またはディクショナリを使用しない場合がある。解凍が開始すると、タイプ検出器２１０および／またはスプリッタ２２０は、提供されたデータのタイプ、たとえば、ペイロードがＣＳＶデータ、Ｐａｒｑｕｅｔデータ、ビデオデータなどを含むかどうかを、たとえば、図２に関連して説明した方法で識別しようと試み得る。
【0178】
２０３０において、スプリッタ２２０は、指定されたターゲットサイズに近い解凍データの境界２５２を特定する。境界２５２の例には、ＣＳＶ記録の終了、ＪＳＯＮ記録の終了、Ｐａｒｑｕｅｔ行グループの終了、ビデオデータのキーフレームなどが含まれる。スプリッタ２２０はまた、ＣＳＶヘッダー、Ｐａｒｑｕｅｔヘッダーおよびフッターなどの記述情報を、非圧縮データ内で識別しようと試み得る。このような記述的データは、基礎となるデータの独立した処理を容易にするために、複数のセグメントに伝搬され得る。
【0179】
２０４０において、スプリッタ２２０は、より適切なスプリット位置１６０２を見つけるために、任意にデフレートブロック単位で前進または後退する。例えば、デフレートブロック１７１０の終わり付近、すなわち、分割後の次の部分２５０ｂのディクショナリ１５３０ｅとなる範囲内に、自然境界２５２を見つけることができれば、一般に最も効率的である。その範囲内に自然境界２５２が見つからない場合、スプリッタは、次のデフレートブロックまたは前のデフレートブロック（または各方向に複数のブロック）を試して、その終わり付近に境界２５２を持つデフレートブロックを見つけようと試みることができる。ターゲット分割位置から妥当な距離内に、その終わりの近くに境界２５２を持つそのようなデフレートブロックが見つからない場合、スプリッタは、ターゲット分割位置の近くのブロックの中から、その終わりに最も近い境界２５２を持つブロックとして、デフレートブロックを選択することができる。
【0180】
２０５０において、スプリッタ２２０は、現在の部分２５０ａの終わりを、選択されたデフレートブロックの終わりとして確定する。スプリッタ２２０はまた、次の部分２５０ｂの開始を、選択されたデフレートブロックの直後に続くデフレートブロック１７１０の開始として確定する。スプリッタ２２０はさらに、選択されたデフレートブロックの終わりからディクショナリ１５３０ｅを識別する。識別されたディクショナリ１５３０ｅは、次の部分２５０ｂを含むセグメント１７０のメタデータに保存される。
【0181】
理想的には、特定された境界２５２と、選択されたブロック内でそれに続くデータはすべてディクショナリ１５３０ｅ内に含まれ、ディクショナリ１５３０ｅは、次の部分２５０ｂのデータを独立して処理するために必要な、必要な「フィックスアップ」データ、すなわち、境界２５２の後に現れる現在の部分２５０ａのデータをすべて含むようになっている。例えば、フィックスアップデータがなければ、次の部分のデータは完全ではなく、独立して処理することができない（独立して解凍することはできる）。境界２５２が、選択されたデフレートブロックのディクショナリ１５３０ｅ内に見出されず、むしろ選択されたデフレートブロックの初期に現れる場合、追加のフィックスアップデータが、すなわち、境界２５２の後であってディクショナリ１５３０ｅの開始前に現れるデータとして、識別され得る。このような追加フィックスアップデータは、例えば追加メタデータとして、次の部分／セグメントとともに保存することができる。これにより、次のセグメントのデータは、現在のセグメントのデータ、または他のセグメントのデータとは独立して処理できるようになる。
【0182】
２０６０において、境界２５２の位置が、現在の部分２５０ａのメタデータにマークされる。このようなマーキングは、現在の部分２５０ａの非圧縮データを独立して処理するときに、境界２５２以降のデータを無視できるようになるため（次の部分２５０ｂで処理される可能性があるため）、後で有用である。さらに、いくつかの例では、ステップ２０３０の間に検出された任意の記述データ（例えば、ＣＳＶヘッダー、Ｐａｒｑｕｅｔヘッダーまたはフッターなど）は、次のセグメント１７０のメタデータにコピーされ、次の部分の独立した処理を容易にすることができる。
【0183】
２０７０において、スプリッタ２２０は、ペイロード１５１４にさらに分割すべきデータがあるかどうかを判定する。その場合、動作は２０１０に戻り、次の部分２５０ｂについて新しいターゲットサイズとターゲット分割位置が判定され、上述の行為２０１０～２０６０が繰り返される。方法２０００は、これ以上の分割が不要になるまで本方法で続けられ、その時点で方法２０００は終了する。本方法２０００は、それぞれのセグメントのデータを独立に解凍できるだけでなく、解凍後にそのようなデータを独立に処理できることを保証するものであることを理解されたい。
【0184】
図２１は、自然境界２５２が、分割位置近傍のデフレートブロック１７１０のディクショナリ１５３０ｅ内に見出される構成例を示す。ここで、分割位置２１０２は、デフレートブロックＡ～Ｈを含むペイロード１５１４のデフレートブロックＤとＥの境界と一致する。解凍された（膨張された）ブロック２１０４に見られるように、ブロックＤには、ブロックＤの終わりのディクショナリ１５３０ｅ内に含まれる境界２５２が含まれる。フィックスアップデータ２１１０は、境界２５２の後に現れるブロックＤのデータとして定義され得る。ペイロード１５１４が分割されるとき、デフレートブロックＡ～Ｄはセグメント１７０ｘに割り当てられ、デフレートブロックＥ～Ｈはセグメント１７０ｙに割り当てられる。
【0185】
独立した処理を容易にするために、セグメント１７０ｘは境界２５２の位置２１２０を保存する。このような位置２１２０は、セグメント１７０ｘ内のデータの後の処理において、境界２５２の後に現れるデータを無視することを可能にする。また、セグメント１７０ｙは、フィックスアップデータ２１１０を含むメタデータを保存し、この場合、フィックスアップデータ２１１０はディクショナリ１５３０ｅ内に完全に含まれている。セグメント１７０ｙのメタデータは、フィックスアップデータ２１１０の位置２１３０（例えば、保存されたディクショナリ１５３０ｅ内の境界２５２の位置）も含む。このようなメタデータは、セグメント１７０ｙ内のデータを独自に処理するのに有用な任意の記述データ２１４０（例えば、ＣＳＶヘッダー、Ｐａｒｑｕｅｔヘッダーおよびフッターなど）も含み得る。
【0186】
図２２は、ここでは自然境界２５２がディクショナリ１５３０ｅの範囲内に入らず、むしろディクショナリ１５３０ｅの前に現れることを除いて、図２１に類似している。この場合、フィックスアップデータ２１１０は、ディクショナリ１５３０ｅのすべてのデータと、追加データ２１１０ａとを含む。追加のフィックスアップデータ２１１０ａは、セグメント１７０ｙのメタデータとともに、例えば、ヘッダー、フッターなどに保存されてもよく、圧縮形式で保存されても非圧縮形式で保存されてもよい。
【0187】
図２３は、メタデータの分割と保存の追加的な例を示す。示されるように、セグメント１７０は、デフレートデータのオリジナル部分２５０に加えて、セグメントヘッダーデータ２３１０およびセグメントフッターデータ２３２０を含むことができ、これらは、上述の記述データ２１４０を提供することができる。セグメント１７０はさらに、ヘッダー長２３３０、追加のフィックスアップデータ２１１０ａ、および保存された解凍状態２３４０を含むことがあり、この解凍状態２３４０は、ディクショナリ１５３０ｅのほか、追加のフラグおよび／または設定２３５０を含み得る。いくつかの例では、ヘッダー長２３３０内に境界２１２０および２１３０が設けられることがあり、境界２１２０は、現在のセグメントの非圧縮データの処理が停止できる場所を示し、境界２１３０は、現在のセグメントを処理するためのフィックスアップデータが開始する場所を示す。
【0188】
図２４は、特定の実施形態において実施され得る例示的な方法２４００を示し、上述した特徴のいくつかの要約を提供する。方法２４００は、例えば、図２に関連して説明したゲートウェイ１１０によって実行されてもよい。
【0189】
２４１０において、圧縮データ１５１４は圧縮データの複数の部分２５０に分割される。部分２５０は、（ｉ）圧縮データの現在の部分２５０ｂと、（ｉｉ）現在の部分２５０ｂの直前の圧縮データの前の部分２５０ａとを含む。
【0190】
２４２０において、前の部分２５０ａの解凍に基づいて、解凍状態２３４０（例えば、ディクショナリ１５３０ｅおよびフラグ／設定２３５０）がキャプチャされる。解凍状態２３４０は、現在の部分２５０ｂの解凍を可能にする。
【0191】
２４３０において、現在の部分２５０ｂは、現在の部分が前の部分２５０ａを参照することなく解凍可能であるように、解凍状態２３４０と関連付けられて保存される。
【0192】
圧縮データ１５１４を分割する改良された技術について説明されている。この技術は、圧縮データ１５１４を複数の部分２５０に分割することを含む。この技術は、現在の部分２５０ｂに関連付けて解凍状態２３４０を保存することをさらに含み、解凍状態２３４０は、前の部分２５０ａのデータに基づいており、現在の部分２５０ｂを他の部分から独立して解凍することを可能にする。
【0193】
特定の実施形態を説明したが、多数の代替的な実施形態または変形が可能である。例えば、各セグメント１７０が圧縮／デフレートデータのそれぞれの部分２５０を含み、ストレージクラスタ１３０のそれぞれのノードに保存される実施形態について説明したが、これは単なる例示に過ぎない。あるいは、複数のセグメントをストレージクラスタ１３０の特定のノードにまとめて保存してもよい。このようなセグメントは、既に上述した形態で保存されてもよいが、代替的に異なる形態をとることもできる。例えば、単一のノード上の複数のセグメント１７０を結合して、データの単一のシャードを形成することができる。このような場合、シャードの構成セグメント１７０のヘッダーおよびフッターは、（メモリ内での過剰なジャンピングを避けるために）単一のヘッダーまたはフッターに統合されてもよく、圧縮／解凍データの部分２５０は、連続的な圧縮範囲として、順番にアグリゲートされてもよい。このような場合、セグメントフッターデータ２３２０は、アグリゲートされた部分２５０の前、例えば、追加のフィックスアップデータ２１１０ａの直後に現れることがあり、これにより、オブジェクトの最後まで読み込むことなく、完全なセグメントを構築することができる。このように部分２５０を保存することにより、個別の部分のサイズおよびノードごとに保存されるデータ量を独立に制御することができる。データをシャードに保存する場合、セクションＩの図７～９に関連して説明したような消失訂正符号化は、それぞれのセグメント１７０ではなく、それぞれのシャードに対して実行することができる。
【0194】
さらに、圧縮データの部分２５０が、データの個別の処理可能な単位間の境界２５２に少なくとも部分的に基づいて定義される例が説明されているが、これは単なる例に過ぎない。生物学的データ、実験データなど、データの形式によっては、処理可能な単位間に明確な境界線２５２がない場合がある。このような場合、データの重複領域を保存することが望ましい場合がある。重複領域は、圧縮データとして保存してもよいし、非圧縮データとして保存してもよい。圧縮データとして保存される場合、圧縮データの次の部分は、連続する両方の部分が同じ重複領域を含むように、前の部分の終わりより前のある決定されたオフセットから開始することができる。あるいは、領域２５０は区別されたままであってもよく、圧縮重複領域はメタデータとして、例えばセグメントヘッダーやフッターに保存されてもよい。非圧縮で保存される場合、重複領域はメタデータとして（例えば、セグメントヘッダーやフッターに）保存されてもよい。所望の重複領域の長さがディクショナリ１５３０ｅの長さより短い場合、ディクショナリ１５３０ｅは既に所望の重複領域を含むので、追加のデータ保存は必要ない場合がある。
【0195】
さらに、本明細書の特定の実施形態を参照して特徴を示し説明してきたが、そのような特徴は、開示された実施形態およびそれらの変形例のいずれにも含まれ得、本明細書に含まれる。したがって、任意の実施形態に関連して開示された特徴は、他の任意の実施形態に含まれることが理解される。
【0196】
さらに、改良またはその一部は、磁気ディスク、磁気テープ、コンパクトディスク、ＤＶＤ、光ディスク、フラッシュドライブ、ソリッドステートドライブ、ＳＤ（セキュアデジタル）チップまたはデバイス、特定用途向け集積回路（ＡＳＩＣ）、フィールドプログラマブルゲートアレイ（ＦＰＧＡ）などの１つまたは複数の非一時的な、コンピュータ読み取り可能な記憶媒体を含むコンピュータプログラム製品として具現化されてもよい（図１２、図１８、および図２４に媒体１２５０として例示する）。任意の数のコンピュータ可読媒体を使用することができる。媒体は、１つ以上のコンピュータまたは他のプロセッサ上で実行されると、本明細書に記載される処理を実行する命令がエンコードされていてもよい。このような媒体は、製造品または機械と見なすことができ、ある機械から別の機械へ輸送可能であってもよい。
【0197】
本明細書全体を通して使用される場合、「備える」、「含む」、「含有する」、および「有する」という語は、オープンエンドな様式で何かの特定の項目、ステップ、要素、または態様を規定することを意図している。また、本明細書で使用される場合、特に反対の記述がない限り、「セット」という語は、１つまたは複数の何かを意味する。これは、「のセット」という語句の後に単数または複数の目的語が続くかどうかや、単数または複数の動詞が活用されるかどうかに関係なく、同様である。また、「セット」要素は、存在するすべての要素よりも少ない数を表すこともある。したがって、その集合に含まれない同種の要素がさらに存在する可能性がある。さらに、「第１」、「第２」、「第３」などの序数的表現は、本明細書では識別の目的で形容詞として使用することがある。具体的に示されない限り、これらの序数的表現は、いかなる順序または順序を意味するものでもない。従って、例えば、「第２」の事象は、「第１」の事象の前または後に起こる可能性があり、また、第１の事象が発生しない場合であっても起こり得る。さらに、本明細書において、特定の要素、特徴、または行為を「第１の」そのような要素、特徴、または行為であると特定することは、「第２の」または他のそのような要素、特徴、または行為も存在しなければならないことをリクエストするものとして解釈されるべきではない。むしろ、「第１」の項目が唯一であってもよい。また、特に反対の記載がない限り、「～に基づく」は非排他的であることを意図している。したがって、「に基づく」は、特に断りのない限り、「に排他的に基づく」という意味ではなく、「に少なくとも部分的に基づく」という意味に解釈されるべきである。特定の実施形態が本明細書に開示されているが、これらは例示としてのみ提供されており、限定的なものとして解釈されるべきではないことを理解されたい。
【0198】
したがって、当業者であれば、以下の特許請求の範囲から逸脱することなく、本明細書に開示された実施形態に対して形態および細部の様々な変更を加えることができることを理解するであろう。
【図1】
【図2】
【図3】
【図4】
【図5】
【図6】
【図7】
【図8】
【図9】
【図10】
【図11】
【図12】
【図13】
【図14】
【図15】
【図16】
【図17】
【図18】
【図19】
【図20】
【図21】
【図22】
【図23】
【図24】
【国際調査報告】