JP7261317B2 - 圧縮データの記憶及び取得の最適化 - Google Patents

Description

本開示は、圧縮データの記憶及び取得の技術分野に関する。

ストレージシステム内に記憶可能なデータ量を増やすために、ストレージシステム内に記憶されるデータが圧縮される場合があり得る。一例として、圧縮データオブジェクトは１つ又は複数のネットワーク記憶位置においてネットワークを介して記憶されることがある。範囲指定読み出しによって記憶データオブジェクトの一部にアクセスすることをユーザが望む場合、要求された部分に先行する全てのオブジェクトデータが典型的にはネットワークストレージから取得され、解凍され得る。例えば従来の技法は、先行するデータの圧縮を決定することなしに特定の要求された部分だけから始まる解凍を可能にしない場合がある。従って、所望の部分に対する解凍及びアクセスを可能にするために、先行データの全てが典型的には解凍され得る。この処理は計算的に非効率であり、時間がかかるものであり得る。

いくつかの実装形態は、データオブジェクトの複数のデータチャンクを受信してもよいコンピュータシステムを含む。このシステムは複数の圧縮チャンクを得るために複数のデータチャンクを圧縮してもよく、複数の圧縮チャンクの全体が閾値サイズ未満であるか否かを判定してもよい。複数の圧縮チャンクの全体が閾値サイズ未満であると判定したことに基づいて、システムは複数の圧縮チャンクの個々のサイズをマップデータ構造内の個々のエントリに加えてもよい。更にこのシステムは、個々のエントリの少なくとも２つの中の値を結合することによってマップデータ構造を短縮してもよく、複数の圧縮チャンク及び短縮マップデータ構造を記憶してもよい。

添付図面を参照して詳細な説明を記載する。図中、参照番号の先頭の数字はその参照番号が初めて登場した図面を識別する。異なる図面内で同じ参照番号を使用することは同様の又は同一のアイテム又は特徴を示す。

図１は、いくつかの実装形態に係る圧縮データを記憶し、アクセスすることができるシステムの構造例を示す。

図２は、いくつかの実装形態に係るチャンクサイズ及びデータサイズごとのマップサイズを含むデータ構造例を示す。

図３は、いくつかの実装形態に係る特殊値オーバーフローの割り振り及びマップ短縮を示すデータ構造例を示す。

図４は、いくつかの実装形態に係る割り振りアルゴリズムのオペレーションの例を示す。

図５は、いくつかの実装形態に係るマップヘッダのデータ構造及びレイアウト例を示す。

図６は、いくつかの実装形態に係るマップのデータ構造の構成例を示す。

図７は、いくつかの実装形態に係るマップのデータ構造の構成例を示す。

図８は、いくつかの実装形態に係る１回の短縮後のマップのデータ構造の構成例を示す。

図９は、いくつかの実装形態に係る圧縮及びマップ生成のための処理例を示す流れ図である。

図１０は、いくつかの実装形態に係る図９の処理の続きである処理例を示す流れ図である。

図１１は、いくつかの実装形態に係るマップに基づく解凍のための処理例を示す流れ図である。

図１２は、いくつかの実装形態に係る図１１の処理の続きである処理例を示す流れ図である。

本明細書のいくつかの実装形態は、圧縮データ及び／又は非圧縮データと混合された圧縮データの高性能の範囲指定読み出しを可能にするための技法及び配置を対象とする。いくつかの事例では、データはクラウド内のストレージに記憶してもよく、或いはネットワークを介してネットワーク記憶位置に記憶されてもよい。いくつかの例では、データ内の圧縮及び非圧縮位置を関連付けるためにマップデータ構造（本明細書では以下「マップ」と呼ぶ）は生成され、保持されてもよい。例えばデータが圧縮されている間、元の非圧縮オブジェクト内の位置を圧縮データ内のオフセットと関連付けるためにマップが生成されてもよい。更に、ユーザ要求等に基づいて、圧縮オブジェクトのオブジェクトデータの或る範囲のアクセスが要求された場合、全圧縮オブジェクトを解凍しなければならないのではなく、要求された範囲の直前のオフセットにおいて解凍を開始できるようにするためにマップを使用してもよい。

いくつかの例では、データを（例えば３２Ｋ、６４Ｋ、１２８Ｋ、２５６Ｋ等の指定の既定サイズである）チャンクへ分割して圧縮してもよい。例えばチャンクは指定のチャンクサイズを有してもよく、かかるサイズは各圧縮要求に使用される元のオブジェクト内のバイト数に対応してもよい。オブジェクト内の最後のチャンクはオブジェクト内の他のチャンクよりも小さいチャンクサイズを有してもよい。チャンクの圧縮後、チャンクのサイズを表すエントリをチャンクごとにマップに追加してもよい。更に、マップを説明するためにチャンクサイズ等の情報を含むマップヘッダを生成してもよい。マップヘッダはマップよりも前にアクセスしてもよく、いくつかのケースではマップを検索するために使用してもよい。マップ自体がマップヘッダに付加されてもよく、さもなければマップヘッダに続いてもよく、或いはマップが圧縮オブジェクトに付加されてもよい。

いくつかのケースでは、マップ全体をメモリ内により上手く収められるようにするため等に、マップをより小さいサイズに短縮してもよい。マップを短縮するために、短縮領域が圧縮データと非圧縮データとの混合を含むことはできない。これを実現するために、ストリーミングデータオブジェクトは、より大きいストリーム集合サイズ（例えば５１２Ｋ）のチャンク（例えば６４Ｋ）として圧縮されてもよい。チャンクの全集合（本明細書ではいくつかの例において「オペレーション」と呼ぶ）が領域として圧縮不能である場合、集合内の全てのチャンクサイズは、マップ内で「０」の圧縮サイズを有するものとして記録されてもよく、対応するチャンクのどれにも圧縮は使用されない。マップ内の非圧縮チャンクの集合を短縮することは、全ての０サイズのチャンクを加えることによって行われ、これは、依然として圧縮されていない０サイズの短縮チャンクをもたらす。

本明細書の実装形態は、圧縮ファイル及び他のデータオブジェクトの最適化された範囲指定読み出し性能を提供する。これらの例は、圧縮位置及び非圧縮位置を関連付けるリレーショナル圧縮マップ、及びマップサイズを最小化するための技術、例えば６４Ｋの圧縮データ当たり２バイトにマップサイズを制限するための技術を含み得る。更に、本明細書の例は、データの初期サイズ及び圧縮率は未知である、ストリーミングファイル及び他のストリーミングデータを圧縮し、及び圧縮が有益である領域に対してのみ圧縮を使用する能力を提供する。

更に、本明細書のマップ短縮技術によって、圧縮中に全マップをメモリ内に保持することができ、そのように全マップをメモリ内に保持することはマップが大きくなり過ぎることにより従来のマッピング技術では不可能な場合がある。加えていくつかの例は、マップをメモリ内に保持することができるようにマップが大きくなるときマップを短縮する能力と共に６４Ｋ等の初期最適チャンクサイズを可能にする。加えて、マップ内の余分なバイトを使用することなしに圧縮可能領域と圧縮不能領域とを短縮中に結合することができる。いくつかの例では、或るデータ領域に対して圧縮が使用されなかったことを示すためにゼロの不可能サイズ又は他の適切なインジケータを使用してもよい。

加えて本明細書の例は、チャンクの集合が圧縮可能だが、１又は複数の個々のチャンクが圧縮可能でない場合に提示される課題を克服する。例えば６４Ｋ又は１６Ｍ等のチャンクサイズを使用するとき、サイズの増加を含める一切の余地なしに２バイト又は３バイトそれぞれの最適化サイズフィールドが潜在的サイズにちょうど収まる。６４Ｋ当たり少なくとも２バイト節約して圧縮を使用するように各集合（オペレーション）を指定した後、６４Ｋ－１（又はより大きいチャンクではその倍数）の特殊圧縮サイズをマップ内で使用して圧縮が利益なしに使用されたことを示すことができる。近隣チャンクを単純に加える短縮を可能にするアルゴリズムを使用し、集合内の近隣チャンクに余分なバイトを加えてもよい。集合が特殊サイズを有する場合、圧縮オブジェクト内の個々のチャンク位置を突き止めることができず、位置を特定することができる集合の境界上で解凍を開始することができる。

加えて、いくつかの例は、圧縮不能チャンクが圧縮を回避できるようにするための最適化を含む。例えば各チャンクを圧縮が使用されなかったことを示すための０の圧縮サイズで表すことができる。圧縮を使用するだけの価値をもたせるのにチャンクの圧縮が不十分である場合、圧縮データの代わりに非圧縮データを圧縮オブジェクト内に含めてもよく、圧縮が使用されなかったことを示すためにマップ内の非圧縮データに０を関連付けることができる。

更に、いくつかの例は、マップサイズを最小化するためのマップ短縮を含む。例えばマップ内の各エントリは、圧縮チャンクサイズに関連するチャンクサイズ表現であってもよい。圧縮が幾らかの空間を節約すると仮定し、マップ内の各エントリは対応するチャンクのチャンクサイズが十分含まれる大きさであるだけでよい場合がある。従って６４Ｋ以下のチャンクサイズはチャンクごとにマップ内で２バイトだけ利用すればよい。６４Ｋを上回るが１６ＭＢを下回るチャンクサイズでは、チャンクごとにマップ内で３バイトが利用されればよい。更に、１６ＭＢを上回るチャンクサイズを有するチャンクの場合、データのチャンクごとにマップ内で４バイトが利用されればよい。

加えて、いくつかの例は、周期的なマップ短縮と共にデータのストリーミングを可能にするための最適化を含む。最初に、ストリーミングオブジェクトを圧縮する場合、ストリーミングオブジェクトの完全なサイズがしばしば未知であり得る。ストリーミングデータは圧縮され、ネットワーク記憶位置（いくつかの例ではクラウドストレージとも呼ぶ）内に記憶されてっもよい。マップの作成を効率的に処理するために、圧縮オブジェクトと共にマップがクラウドに書き込まれるまで、マップはメモリ内に保持されてもよく、いくつかの事例ではマップサイズを指定の閾値サイズ未満に保つためにマップを周期的に短縮してもよい。全マップをメモリ内に保持することにより、マップはマップの作成中にハードディスクドライブ又はソリッドステートドライブ等のローカルストレージに書き込み、圧縮データに関連して記憶するために完成したマップをネットワーク記憶位置に送信するために圧縮完了後に再び読み出す必要がない。いくつかの例では、オブジェクトの圧縮完了後、データオブジェクトの圧縮サイズ内にマップを含めることができるように、マップを圧縮オブジェクトに付加してもよい（例えば図２参照）。

非限定的な一例として、チャンク当たり６４ＫＢのチャンクサイズを使用する場合、２ＴＢオブジェクトのマップはほぼ６２ＭＢ利用してもよい。メモリ内にマップを保持しながらそのような大きいオブジェクトの圧縮を処理するために、本明細書のマップは短縮可能であってもよい。マップを短縮することは、隣接エントリを結合してチャンクサイズを２倍にすることによって実現してもよい。例えば、マップエントリによって表されるチャンクサイズがチャンク当たり６４ＫＢではなく１ＭＢになるまで、２ＴＢオブジェクト用の６２ＭＢマップが短縮されると仮定する。この場合、マップは６２ＭＢではなく６ＭＢ未満を利用し得る。

本明細書の例では、短縮が圧縮チャンクと非圧縮チャンクとの混合をもたらすことは望ましくない。従って、最大短縮時のチャンクサイズはオペレーションサイズとして使用してもよい。例えばオペレーションは全て圧縮を使用する、又は全て圧縮をスキップするチャンクの集合を含んでもよい。従ってシステムは、オペレーションに含まれるチャンクの全てから結果を集めた後で圧縮を使用すべきか否かを判定してもよい。例えば各オペレーションは２のべき乗のチャンクの集合であってもよい。オペレーションを圧縮すべきか否かを判定する前に、オペレーション内の全てのチャンクが圧縮される。オペレーションが圧縮不能である（例えば圧縮が閾値未満の全体的なサイズ低減をもたらす）場合、マップは、圧縮が使用されなかったことを示すためにオペレーション内の全てのチャンクについて０で更新される。オペレーション内の任意のチャンクに圧縮が使用される場合、そのオペレーション内の全てのチャンクに圧縮が使用される。

論述目的で、いくつかの実施形態は、１又は複数のネットワーク記憶位置と通信する１又は複数のサービス計算装置、及びデータの圧縮を最適化できる１又は複数のユーザ装置の環境内において説明される。但し、本明細書の実装形態は、提供される特定の例に限定されず、本明細書の開示に照らして当業者に明らかになるように、他の種類の計算システム構造、他の種類のストレージ環境、他の種類のクライアント構成、他の種類のデータ等に拡張されてもよい。

図１は、いくつかの実装形態に係る圧縮データを記憶し、アクセスすることができるシステム１００の構造例を示す。システム１００は、１又は複数のネットワーク１０６等によって少なくとも１つのストレージシステム１０４と通信することができる、或いは少なくとも１つのストレージシステム１０４に接続される１又は複数のサービス計算装置１０２を含む。更にサービス計算装置１０２は、以下で更に論じるように様々な種類の計算装置の何れかとすることができる、ユーザ装置１０８（１）、１０８（２）、．．．等の１又は複数のユーザ計算装置１０８とネットワーク１０６を介して通信することができる。

いくつかの例では、サービス計算装置１０２は任意の数のやり方で実装され得る１又は複数のサーバを含んでもよい。例えばサービス計算装置１０２のプログラム、他の機能コンポーネント、及びデータストレージの少なくとも一部は、サーバのクラスタ、サーバファーム、データセンタ、クラウドによってホストされる計算サービス等の中の少なくとも１つのサーバ上に実装されてもよいが、他のコンピュータ構造が追加で又は代替的に使用されてもよい。図示の例では、サービス計算装置１０２は１又は複数のプロセッサ１１０、１又は複数のコンピュータ可読媒体１１２、及び１又は複数の通信インタフェース１１４を含む、又はそれらに関連づけられていてもよい。

各プロセッサ１１０は単一の処理ユニット又は多数の処理ユニットであってもよく、単一の若しくは複数の計算ユニット又は複数の処理コアを含んでもよい。プロセッサ１１０は、１又は複数の中央処理装置、マイクロプロセッサ、マイクロコンピュータ、マイクロコントローラ、デジタル信号プロセッサ、ステートマシーン、論理回路、及び／又はオペレーション命令に基づいて信号を操作する任意の装置として実装することができる。一例としてプロセッサ１１０は、本明細書に記載のアルゴリズム及び処理を実行するように特別にプログラムされ又は構成された任意の適切な種類の１又は複数のハードウェアプロセッサ及び／又は論理回路を含んでもよい。プロセッサ１１０は、本明細書に記載の機能を実行するようにプロセッサ１１０をプログラムし得る、コンピュータ可読媒体１１２内に記憶されるコンピュータ可読命令を取り出し実行するように構してもよい。

コンピュータ可読媒体１１２は、メモリ１１３及びローカルストレージ１１５を含んでもよい。例えばメモリ１１３は、コンピュータ可読命令、データ構造、プログラムモジュール、又は他のデータ等の情報を記憶するための任意の種類の技術によって実装された揮発性メモリ及び不揮発性メモリ、及び／又は取外し可能媒体及び取外し不能媒体を含んでもよい。例えばメモリ１１３は、これだけに限定されないが、ＲＡＭ、ＲＯＭ、ＥＥＰＲＯＭ、フラッシュメモリ又は他のメモリ技術を含んでもよい。更に、ローカルストレージ１１５及び他のコンピュータ可読媒体１１２は、光学ストレージ、ソリッドステートストレージ、磁気テープ、磁気ディスクストレージ、ＲＡＩＤストレージシステム、ストレージアレイ、ネットワーク接続ストレージ、ストレージエリアネットワーク、クラウドストレージ、又は所望の情報を記憶するために使用することができ計算装置によってアクセス可能な他の任意の媒体を含んでもよい。サービス計算装置１０２の構成にもよるが、言及するとき非一時的コンピュータ可読媒体がエネルギ、搬送波信号、電磁波、及び／又は信号自体等の媒体を除外する限りにおいて、コンピュータ可読媒体１１２は有形の非一時的媒体を含んでもよい。いくつかの事例では、コンピュータ可読媒体１１２は、サービス計算装置１０２と同じ位置にあってもよい一方、他の例ではコンピュータ可読媒体１１２の一部はサービス計算装置１０２と部分的に離れていてもよい。例えばいくつかの事例では、コンピュータ可読媒体１１２はストレージシステム１０４内のストレージの一部を含んでもよい。

コンピュータ可読媒体１１２は、プロセッサ１１０によって実行可能な任意の数の機能構成部を記憶するために使用されてもよい。多くの実装形態において、これらの機能構成部は、プロセッサ１１０によって実行可能であり且つ実行された時に本明細書ではサービス計算装置１０２によるものとするアクションを実行するようにプロセッサ１１０をとりわけプログラムする命令又はプログラムを含む。コンピュータ可読媒体１１２内に記憶される機能構成部はサーバプログラム１１６及びストレージプログラム１１８を含んでもよく、それらのそれぞれは１又は複数のコンピュータプログラム、アプリケーション、実行可能コード、又はその一部を含んでもよい。例えばサーバプログラム１１６は、ユーザ装置１０８及びストレージシステム１０４との通信機能を提供してもよい。

ストレージプログラム１１８は、本明細書に記載のデータ圧縮／解凍並びにマップ生成及び管理機能を実行するように構成されてもよい。加えてストレージプログラム１１８は、サービス計算装置１０２によって記憶され管理されるデータに関係するメタデータを含むメタデータデータベース（ＤＢ）１２０を作成し管理するためのデータベース管理機能を含んでもよい。例えばストレージプログラム１１８は、ファイルシステム、オブジェクト情報、データ管理情報、及び他の情報をメタデータデータベース１２０の一部としてストレージプログラム１１８に保持させるように構成される実行可能命令を含んでもよい。ストレージプログラム１１８は、ユーザ情報のようなメタデータデータベース１２０内に含まれる他の種類の情報を管理するための管理機能を更に実行してもよい。ストレージプログラム１１８は、保存期間、ストレージの保護レベル、災害復旧のための他のサイトへの記憶データの複製等を管理するため等に、ネットワークストレージシステム１０４において記憶されるデータのストレージを更に管理してもよい。

加えてコンピュータ可読媒体１１２は、本明細書に記載の機能及びサービスを実行するために使用されるデータ、データ構造、及び他の情報を記憶してもよい。例えばオブジェクトの圧縮中、コンピュータ可読媒体１１２は圧縮オブジェクト１２４のマップ１２２をメモリ１１３内に記憶してもよく、その一方で圧縮オブジェクトがメモリ１１３内に記憶するには大き過ぎる場合には、圧縮オブジェクトは、ローカルストレージ１１５内に記憶されてもよい。加えてコンピュータ可読媒体１１２は、以下で更に論じるように本明細書に記載の機能の一部を実行するときストレージプログラム１１８によって使用されるメタデータＤＢ１２０を記憶してもよい。加えてメモリ１１３は、データの圧縮中及び／又は解凍中のようにデータの少なくとも一部を一時的に記憶するために使用することができるインジェストバッファ１２６及び出力バッファ１２８を含んでもよい。

サービス計算装置１０２はプログラム、ドライバ等及び機能コンポーネントによって使用され又は生成されるデータを含み得る、他の機能コンポーネント及びデータも含み又は保持してもよい。更に、サービス計算装置１０２は他の多くの論理的、プログラム的、及び物理的なコンポーネントを含んでもよく、そのうち上記で記載したものは本明細書の議論に関係する例に過ぎない。

１又は複数の通信インタフェース１１４は、１又は複数のネットワーク１０６を介してのように他の様々な装置との通信を可能にするための１又は複数のソフトウェア及びハードウェア構成部を含んでもよい。従って通信インタフェース１１４は、ストレージシステム１０４、他のサービス計算装置１０２、及びユーザ装置１０８と通信するためのネットワーク１０６への接続を提供する１又は複数のポートを含む、又は接続するようにしてもよい。例えば通信インタフェース１１４は、本明細書の他の箇所で更に挙げるように、ＬＡＮ、インターネット、ケーブルネットワーク、セルラネットワーク、無線ネットワーク（例えばＷｉ－Ｆｉ）及び有線ネットワーク（例えばファイバチャネル、光ファイバ、イーサネット）、直接接続、並びにＢＬＵＥＴＯＯＴＨ（登録商標）等の近距離通信等のうちの１又は複数を介する通信を可能にし得る。

１又は複数のネットワーク１０６は、インターネット等の広域ネットワーク、イントラネット等のローカルエリアネットワーク（ＬＡＮ）、セルラネットワーク等の無線ネットワーク、Ｗｉ－Ｆｉ等のローカル無線ネットワーク、及び／又はＢＬＵＥＴＯＯＴＨ（登録商標）等の短距離無線通信、ファイバチャネル、光ファイバ、イーサネット、又は他の任意のかかるネットワークを含む有線ネットワーク、直接有線接続、又はそれらの任意の組み合わせを含む任意の適切なネットワークを含んでもよい。従って、１又は複数のネットワーク１０６は有線通信技術及び／又は無線通信技術の両方を含んでもよい。このような通信に使用される構成部はネットワークの種類、選択された環境、又はその両方に少なくとも部分的に依存し得る。そのようなネットワーク上で通信するためのプロトコルはよく知られており、本明細書では詳しくは論じない。従って、サービス計算装置１０２、ネットワークストレージシステム１０４、及びユーザ装置１０８は、有線接続又は無線接続及びその組み合わせを使用して１又は複数のネットワーク１０６を介して通信することができる。

各ユーザ装置１０８は、デスクトップ、ラップトップ、タブレット計算装置、モバイル装置、スマートフォン、ウェアラブル装置、及び／又はネットワークを介してデータを送信可能な他の任意の種類の計算装置等の任意の適切な種類の計算装置であってもよい。ユーザ１３０（１）、１３０（２）、．．．のそれぞれは、個々のユーザアカウント、ユーザログイン資格情報等を介してユーザ装置１０８（１）、１０８（２）、．．．に関連付けられてもよい。更にユーザ装置１０８は、１又は複数のネットワーク１０６を介して、別個のネットワークを介して、又は他の任意の適切な種類の通信接続を介してサービス計算装置１０２と通信可能であってもよい。本明細書の開示の利益を得る当業者に数多くの他の改変形態が明らかになる。

更に、各ユーザ装置１０８（１）、１０８（２）、．．．は、例えばネットワークストレージシステム１０４上に記憶するためのユーザデータを送信するため及び／又はネットワークストレージシステム１０４から記憶されたデータを受信するため等のサーバプログラム１１６と通信するために、個々のユーザ装置１０８（１）、１０８（２）、．．．上で実行され得るユーザアプリケーション１３６（１）、１３６（２）、．．．の個々のインスタンスを含んでもよい。いくつかの事例では、アプリケーション１３６はブラウザを含んでもよく又はブラウザを介して動作することができてもよく、サーバプログラム１１６はユーザがサービス計算装置１０２を介して記憶されたデータにアクセスすることを可能にするためのウェブアプリケーションを含んでもよい。或いは他の事例では、アプリケーション１３６は、１又は複数のネットワーク１０６を介してサーバプログラム１１６との通信を可能にする通信機能を有する他の任意の種類のアプリケーションを含んでもよい。

ストレージシステム１０４は１又は複数のストレージ計算装置１４０を含んでもよく、ストレージ計算装置１４０は、サービス計算装置１０２に関して上記で論じた例の何れかのような１若しくは複数のサーバ又は他の任意の適切な計算装置を含んでもよい。ストレージ計算装置１４０のそれぞれは、１又は複数のプロセッサ１４２、１又は複数のコンピュータ可読媒体１４４、及び１又は複数の通信インタフェース１４６を含んでもよい。例えばプロセッサ１４２は、プロセッサ１１０に関して上記で論じた例の何れかに対応してもよく、コンピュータ可読媒体１４４はコンピュータ可読媒体１１２に関して上記で論じた例の何れかに対応してもよく、通信インタフェース１４６は通信インタフェース１１４に関して上記で論じた例の何れかに対応してもよい。

加えてコンピュータ可読媒体１４４は、ストレージシステム１０４内に含まれるストレージ１５０上のデータの記憶を管理するために１又は複数のプロセッサ１４２によって実行される機能構成部としてストレージプログラム１４８を含んでもよい。ストレージ１５０は、記憶装置１５６の１又は複数のアレイ１５４等にデータを記憶するための、ストレージ１５０に関係付けられた１又は複数のコントローラ１５２を含んでもよい。例えばコントローラ１５２は、ＲＡＩＤ構成、ＪＢＯＤ構成等でアレイ１５４を構成するために、及び／又は記憶装置１５６に基づく論理ユニットをストレージプログラム１４８に提示するために、及び基礎を成す物理記憶装置１５６上にクラウドデータ１５８として記憶されるデータオブジェクト又は他のデータ等のデータを管理するために等、アレイ１５４を制御してもよい。記憶装置１５６はハードディスクドライブ、ソリッドステートドライブ、光学ドライブ、磁気テープ、それらのものの組み合わせ等、任意の種類の記憶装置であってもよい。いくつかの例では、ネットワークストレージシステム１０４は当技術分野で知られている市販のクラウドストレージを含んでもよい一方、他の例では、ネットワークストレージシステム１０４はサービス計算装置１０２に関連付けられたエンティティによってのみアクセスできるプライベート又はエンタプライズストレージシステムを含んでもよい。

システム１００において、ユーザ１３０はかれらのそれぞれのユーザ装置１０８が通信しているサービス計算装置１０２にデータを記憶し、サービス計算装置１０２からデータを受信し得る。従って、サービス計算装置１０２はユーザ１３０及びそれぞれのユーザ装置１０８にローカルストレージを提供してもよい。定常状態オペレーションの間、サービス計算装置１０２と周期的に通信するユーザ１０８があってもよい。

いくつかの事例では、サービス計算装置１０２は、１又は複数のグループ、クラスタ、システム等に構成されてもよい。例えば、いくつかの例（図１に不図示）では、サービス計算装置１０２は、第１のサービス計算装置１０２を第２のサービス計算装置１０２に、複数のユーザ装置１０８にストレージ及びデータ管理サービスを提供するための計算ノードをそれらの計算装置が一緒に形成できるように接続されてもよいように、対で配置されてもよい。例えば少なくともメタデータデータベース１２０を維持することに関して、第１のサービス計算装置１０２は主計算装置として働いてもよい一方、第２のサービス計算装置１０２は副計算装置として働いてもよい。加えて又は選択的に、いくつかの例において、複製及び災害復旧を可能にするために、サービス計算装置１０２を地理的に離れ且つ遠隔の位置にある複数のクラスタに配置してもよい。本明細書の開示の利益を得る当業者に数多くの他の構成が明らかになる。

図１の例では、第１のユーザ１３０（１）はネットワークストレージシステム１０４において記憶するためにサービス計算装置１０２に対して１６０で示すようにデータオブジェクトをストリーミングすると仮定する。ストレージプログラム１１８は、ストリーミングされたデータオブジェクト１６０を圧縮するために、サービス計算装置１０２上で実行されてもよい。オブジェクトがサービス計算装置１０２にストリーミングされている間、ローカルストレージ１１５内のディスク上にマップ１２２を記憶する必要なしに、マップ１２２は、作成され、メモリ１１３内に保持されてもよい。一例として、ストレージプログラム１１８はマップ１２２を生成するとき、５１２Ｋオペレーションにおける６４Ｋチャンク等の既定のチャンクサイズを最初に使用してもよい。そのように既定のチャンクサイズを使用することは、例えばメモリ内に常に収まることが典型的に予期され得る２５６Ｋチャンク用の単一設定マップよりもデータ取得中に優れた性能をもたらす。従って既定の構成は、殆どのオブジェクトについてメモリ又はマップサイズ要件が２倍になるだけで４倍の範囲性能を提供しながら、大きいオブジェクトに必要なマップメモリを半分に減らすことができる。様々なオブジェクトサイズ及びチャンクサイズに関連するマップサイズの更なる例を、例えば図２に関して以下で論じる。更に、これらのパラメータはユーザの要件に基づいてユーザによって最適化されてもよい。

オブジェクトがサービス計算装置１０２へストリーミングされ、サービス計算装置１０２によって圧縮されることが完了すると、いくつかの例ではマップ１２２は圧縮オブジェクト１２４に付加されてもよく、圧縮オブジェクト１２４及びマップ１２２はネットワーク１０６を介してネットワークストレージシステム１０４に送信されてもよい。ネットワークストレージ１０４は、圧縮オブジェクト１２４及びマップ１２２をストレージ１５０内に記憶してもよい。加えてマップヘッダ（図１には不図示）はマップ１２２のために作成されてもよく、オブジェクト１２４についての他のメタデータに関連付けてメタデータデータベース１２０内に記憶されてもよい。更に、この例ではマップ１２２が圧縮オブジェクト１２４に付加されてもよいが、他の例ではマップ１２２は関連付けられた圧縮オブジェクト１２４から分離してネットワークストレージ１０４に記憶されてもよい。他の事例では、マップ１２２は、マップヘッダに付加され、メタデータデータベース１２０内に記憶されてもよい。

更にいくつかの事例では、圧縮オブジェクト１２４の１又は複数の部分が、圧縮オブジェクト１２４及び／又はマップ１２２の１又は複数の他の部分とは別にネットワークストレージシステム１０４に送信されてもよい。例えばストリーミングされたデータオブジェクト１６０の一部が圧縮されると、非常に大きいオブジェクトの場合、又は圧縮オブジェクトをローカルストレージ１１５に記憶し、後で圧縮オブジェクトをローカルストレージ１１５から読み出すよりも、圧縮オブジェクトをメモリ１１３から直接送信することが望ましい場合等に、圧縮部分はネットワークストレージシステム１０４に独立して送信されてもよい。本明細書の開示の利益を得る当業者に数多くの他の改変形態が明らかになる。

更に、一例として、ユーザ１３０（２）が、圧縮オブジェクト１２４の一部がユーザ装置１０８（２）に送信されることを要求するデータ要求１７０を後に送信すると仮定する。ストレージプログラム１１８はマップヘッダにアクセスし、マップがネットワークストレージシステム１０４に記憶されていると判定し、マップ１２２を得てもよい。要求されたデータ部分を得るためにデータの読み出しを開始する非圧縮オブジェクト内の位置を決定することに基づいて、並びにマップ１２２内のオフセット及び以下で更に論じる他の情報に基づいて、ストレージプログラム１１８はデータオブジェクトの一部に対するリード要求１７４をネットワークストレージシステム１０４に送信してもよい。これに応答し、ネットワークストレージシステム１０４は、要求されたデータ部分をサービス計算装置１０２に送信してもよい。ストレージプログラム１１８は、要求されたデータ部分の１又は複数の部分を解凍してもよく、非圧縮データ部分１７８によってデータ要求１７０に応答してもよい。

図２は、いくつかの実装形態に係るチャンクサイズ及びデータサイズごとのマップサイズを含むデータ構造２００の例を示す。この例のデータ構造２００は、チャンクサイズ及びデータサイズ（例えばオブジェクトサイズ）ごとのマップサイズを示し、１０２４エントリオフセット頻度によってシリアル化されている。例えばオフセット頻度はマップ内の絶対オフセット間で生じるマップエントリの数（圧縮サイズ）を示してもよい。絶対オフセットは、関連するマップエントリが適用されるチャンクが存在する圧縮オブジェクト内へのオフセットを含んでもよい。加えて、圧縮サイズエントリはマップ内で表される単一チャンクの圧縮サイズを含んでもよい。いくつかの事例では、圧縮サイズエントリは、圧縮が使用されなかったことを示すために０としてもよく、又はオペレーションに関する全ての圧縮サイズエントリが未知であることを示すために特殊値としてもよい。

図示の例では、データ構造２００は、１０ＫＢから２，０００，０００，０００ＫＢまでのデータサイズの範囲を列挙するデータサイズカラム５０２を含む。このデータ構造は、チャンクサイズ３２ＫＢ、６４ＫＢ、１２８ＫＢ、２５６ＫＢ、５１２ＫＢ、１０２４ＫＢ、及び２０４８ＫＢそれぞれのマップサイズを列挙する７個のマップサイズカラム５０４、５０６、５０８、５１２、５１４及び５１６と、カラム５０２内に列挙される対応するデータサイズとを更に含む。例えばデータサイズが１００，０００ＫＢであり、チャンクサイズが６４ＫＢである場合、マップサイズは３１３４バイトである。

本明細書のいくつかの例では、全オペレーション（例えば一連のチャンク群）が圧縮されていても、圧縮されていなくてもよい。オペレーションの圧縮率はオペレーション内の全チャンクに関する総空間節約によって決定することができる。例えば圧縮が少なくとも閾値を達成しない場合、全オペエーションを圧縮しないままにしておいてもよい。

他方で、オペレーション内の１又は複数の個々のチャンクが圧縮可能でない可能性がある、又は最小限に圧縮可能である場合であっても、全オペレーションに関する圧縮の閾値レベルを達成するのにオペレーション内の他のチャンクが十分圧縮可能である場合は全オペレーションを依然として圧縮することができる。この状況では、最適なマップエントリサイズが非圧縮チャンクと合わない問題があり得る。例えば６４Ｋ－１は、マップ内の６４ＫＢサイズのチャンクに使用される最適エントリサイズである２バイト内に収めることができる最大数である。これを扱うために、６４Ｋ－１の特殊サイズを、実際の圧縮サイズが少なくとも６４Ｋ－１であることを示すために使用されてもよい。

短縮がエントリを正しく結合することを保証する、以下で更に論じる割り振りアルゴリズムを使用し、オペレーション内の他の圧縮サイズエントリに余分なバイトを割り振ってもよい。これがオペレーション内の少なくとも１つのチャンクに生じる場合、オペレーション内の他のチャンクのサイズエントリが正しくない可能性がある。但し、合計圧縮オペレーションサイズは依然としてオペレーション内の圧縮チャンクサイズエントリの和である。この事例では、オペレーションの任意のマップエントリが特殊サイズであるとき、解凍はオペレーション内の最初のチャンクでのみ整列されてもよい。それに該当する場合、所望の範囲の開始に達する前に、解凍データの全チャンクを破棄する必要があり得る。

マップの短縮を通して特殊サイズは維持されるので、短縮ごとに値が２倍になり得る。特殊サイズは、エントリサイズが６４Ｋチャンクについての２バイト及び１６ＭＢチャンクについての３バイト等の最適である場合にのみ必要とされるが、この状況では、特殊サイズが短縮を通して維持される。別の例として、１６ＭＢのチャンクサイズを有するマップに特殊サイズが使用される場合、特殊サイズは１６ＭＢチャンクについて１６ＭＢ－２５６になる。或る非限定的な例として、オペレーションを圧縮可能だと考えるのに必要とされる平均最小空間節約閾値は、チャンクサイズ又はオペレーションサイズに関係なく６４Ｋ当たり２バイトであり得る。それよりも高い圧縮率を構成することはできるが、それよりも低い圧縮率は構成できない。更に、読み出し中にオペレーションサイズが分かり得るので、以下で更に論じるようにマップヘッダ内にオペレーションサイズの値を含めることができる。

図３は、いくつかの実装形態に係る特殊値オーバーフローの割り振り及びマップ短縮を示すデータ構造３００例を示す。データ構造３００は、チャンクサイズ３０２、圧縮サイズ（実際のサイズ）３０４、（２バイトのエントリでの）マップ内圧縮サイズ３０６、１回短縮後のマップ内圧縮サイズ（３バイトエントリ）３０８、及び２回短縮後のマップ内圧縮サイズ（３バイトエントリ）を含む。図３では、３０２に示すようにチャンクサイズは６４Ｋである。更に、圧縮された実際のサイズが３０４に示されており、（マップ内のカラム３０６で圧縮サイズについて「０」で示すように）最初の４つのエントリが圧縮されていないことが示されている。

この例では、最初の４つのエントリは圧縮されなかった第１のオペレーションであり、第２のオペレーションはロウ３１２で開始し、複数の特殊値を含み、第３のオペレーションは３２０で開始し、同じく複数の特殊値を含むと仮定する。具体的には、ロウ３１２、３１６、３１８、３２２、及び３２６では、カラム３０４内で示す圧縮された実際のサイズが６４Ｋを上回る。従って、ロウ３１２、３１６、３１８、３２２、及び３２６のカラム３０６内の値のそれぞれが６４Ｋ－１、即ち６５５３５に等しいように余分なビットを引いて再割り振りさせる。例えば余分な６バイト（３１２、３１６、及び３１８からそれぞれ２）をロウ３１４内の値に加え、カラム３０４の５００の値をカラム３０６の５０６に増やす。同様に（３２２から）２バイトをロウ３２０内の１０００の値に加え、（３２６から）３バイトをロウ３２４内の値に加える。従って、カラム３０６内の特殊値を作成するために追加のバイトが他の圧縮チャンク値の間で割り振られる。

上記で述べたように、特定のチャンクは圧縮可能オペレーションの最中に圧縮不能であり得る。マップサイズを最小化することによって圧縮を最適化するために、マップ内の圧縮サイズエントリは最小数のバイトを利用してもよい。６４Ｋチャンクの場合のようにエントリに使用されるバイト数がチャンクサイズに辛うじて収まる場合、チャンクが圧縮可能でない限り圧縮サイズはエントリ内に収まらない。０から６５５３５（６４Ｋ－１）までの数を表すために２バイト（６４Ｋチャンクのマップエントリサイズ）が使用可能である。６４Ｋ以上は２バイトでは表せない。従って本明細書の実装形態では、そのようなオペレーションに圧縮を使用するために、特殊サイズは実際の圧縮サイズが未知であることを示すためにマップエントリ内で使用されてもよい。

オペレーション全体（即ちチャンク群）が圧縮可能だが、１又は複数のチャンクが圧縮不能である場合、圧縮不能チャンク用の特殊サイズからのオーバーフローは、オペレーションのための他のマップエントリの間で割り振られてもよい。このことは圧縮オペレーションサイズを正しく保ち、オペレーションレベルでのナビゲーションを可能にする。例えばマップを短縮できない場合、より小さい圧縮サイズを有する他の任意のチャンクに余分なバイトを割り振ることで十分である。但し、マップは後で短縮され得るので、オーバーフローは後の短縮中に結合される方法と真逆に割り振らせることができる。特殊サイズを有するオペレーションの短縮中、オペレーション内のチャンクの実際の圧縮サイズを決定することはできない。このことは、短縮は隣接する対を結合するほど簡単なものであってもよい。隣接結合エントリの何れも特殊サイズではない場合、結果は特殊サイズにならず、結合エントリは対応する結合チャンクの圧縮サイズを表すことができる。全ての圧縮サイズが依然として知られている間の原割り振りは、マップエントリがどのように結合されているのかの方法を説明し得る。（６４Ｋ－１）^＊２＾ｎの特殊サイズであって、ｎは６４Ｋのチャンクサイズを超える短縮の数である、特殊サイズを使用することにより、特殊サイズに隣接する６４Ｋのチャンクサイズを結合することによる短縮チャンクサイズを特殊サイズと結合して、短縮マップのための正しいエントリ内に特殊サイズを生成することができる。

カラム３０８に示すように、第１の短縮の間、最初の４つのエントリは、「０」の値を有する結果として生じる２つのエントリを得るように結合されてもよい。更に、ロウ３１２及び３１４における３０６内の値が結合される場合、カラム３０８内の結果は６５５３５＋５０６（対として今なお圧縮不能なロウ３１６及び３１８から４バイトは依然として残っている）の６６０４１である。加えてロウ３１６及び３１８において、２つの特殊サイズが結合されて新たな特殊サイズ１３１０７０となる。ロウ３１２及び３１４と同様のやり方でロウ３２０及び３２２が結合され、ロウ３２４及び３２６も同様に結合される。第２の短縮の間、カラム３１０内に示すように、カラム３１０内の値に到達するようにマップをさらに短縮化するために、隣接する対を結合することによりカラム３０８内の値を同様に結合してもよい。

将来の全ての短縮が圧縮サイズの完全性を保つように特殊サイズからのオーバーフローが割り振られることを保証するために、以下に記載するような割り振りアルゴリズムを使用してオーバーフローを割り振らせることができる。割り振りアルゴリズムは、オペレーションに関する実際の圧縮サイズのアレイ、サイズ超過エントリの位置、６４Ｋ－１等の特殊サイズ値、オペレーションのべき乗（２のべき乗としてのオペレーション当たりのチャンク）、及び最終オペレーション上のオペレーション当たりのチャンクを上回ることができないチャンクカウントによって機能してもよい。オーバーフローの候補は１から開始してオペレーションのべき乗に進み、２のべき乗のチャンクを調査することによって決定することができる。調査するためのアレイ内の開始エントリは、サイズ超過エントリの位置を２進値として表し、現在の２のべき乗の下位ビットをゼロで埋めることによって決定してもよい。順番に、これを、調査の開始を２＾現在のべき乗エントリの先頭に置き、それらのエントリは将来の潜在的な短縮数（べき乗）によって結合され得る。これらのエントリは、オーバーフローが完全に振り分けられるまで、特殊サイズを上回ることなしにオーバーフローを含むように調節される。

図３の例では、第２のオペレーション（ロウ３１２～３１８）及び第３のオペレーション（ロウ３２０～３２６）は、２バイトの圧縮サイズエントリ内に割り振るために本明細書の割り振りアルゴリズムを使用した結果の例を示す。割り振りアルゴリズムの疑似コードの一例は以下を含む：

ｄｉｓｃｒｅｐａｎｃｙ＝ｏｐｅｒａｔｉｏｎＭａｐ［ｐｏｓ］－ｓｐｅｃｉａｌ；

ｆｏｒ（ｉｎｔ ｐｏｗｅｒ＝１；ｐｏｗｅｒ＜＝ｏｐｅｒａｔｉｏｎＰｏｗｅｒ；＋＋ｐｏｗｅｒ）｛

ｉｎｔ ｓｔａｒｔ＝（ｐｏｓ＞＞ｐｏｗｅｒ）＜＜ｐｏｗｅｒ；

ｆｏｒ（ｉｎｔ ｉ＝ｓｔａｒｔ；ｉ＜ｓｔａｒｔ＋（１＜＜ｐｏｗｅｒ）＆＆ｉ＜ｃｈｕｎｋＣｏｕｎｔ；＋＋ｉ）｛

ｉｆ（ｏｐｅｒａｔｉｏｎＭａｐ［ｉ］＜ｓｐｅｃｉａｌ）｛

ｉｎｔ ｅｘｔｒａＳｐａｃｅ＝ｍｉｎ（ｄｉｓｃｒｅｐａｎｃｙ，ｓｐｅｃｉａｌ－ｏｐｅｒａｔｉｏｎＭａｐ［ｉ］）；

ｏｐｅｒａｔｉｏｎＭａｐ［ｉ］＋＝ｅｘｔｒａＳｐａｃｅ；

ｄｉｓｃｒｅｐａｎｃｙ－＝ｅｘｔｒａＳｐａｃｅ；

ｉｆ（ｄｉｓｃｒｅｐａｎｃｙ＝＝０）｛

ｒｅｔｕｒｎ；

｝ ｝ ｝ ｝

図４は、いくつかの実装形態に係る割り振りアルゴリズムのオペレーションの例を示す。上記の割り振りアルゴリズムでは、割り振りアルゴリズムは、特殊サイズから他のチャンク表現（オペレーションエントリ）にオーバーフローを割り振るための１又は複数のパスを作成するために実行されてもよい。例えば第１の例４０１は、オペレーションエントリ４０２、第１パス４０４、第２パス４０６、及び第３パス４０８を含む。例えば４１０に示すように、オペレーションエントリ４０２は圧縮不能エントリを含む。割り振りアルゴリズムは、同じオペレーション４１２内の直接隣接するエントリを検査するための第１パス４０４を作成するために実行されてもよい。次に、第１パスがオーバーフローの割り振りをもたらさない場合、割り振りアルゴリズムは、同じオペレーション４１２内の他のエントリを検査するための第２パス４０６を作成するために実行されてもよい。次に、第２パスがオーバーフローの割り振りをもたらさない場合、割り振りアルゴリズムは、隣接するオペレーション４１４内の他のエントリを検査するために実行されてもよい。割り振りアルゴリズムは、オーバーフローが割り振られるまで続行されてもよい。

同様に例４２０では、４２２で示すようにオペレーションエントリ４０２は圧縮不能エントリを含む。割り振りアルゴリズムは、同じオペレーション４２２内の直接隣接するエントリを検査するための第１パス４０４を作成するために実行されてもよい。次に、第１パスがオーバーフローの割り振りをもたらさない場合、割り振りアルゴリズムは、同じオペレーション４２２内の他のエントリを検査するための第２パス４０６を作成するために実行されてもよい。次に、第２パスがオーバーフローの割り振りをもたらさない場合、割り振りアルゴリズムは、隣接するオペレーション４２４内の他のエントリを分散アルゴリズムが検査してもよい。割り振りアルゴリズムは、オーバーフローが割り振られるまで続行されてもよい。

図５は、いくつかの実装形態に係るマップヘッダ５００のデータ構造及びレイアウト例を示す。マップに関する詳細は２バイト、即ち第１バイト５０２及び第２バイト５０４に収めることができる。例えばチャンクサイズ、（オペレーション当たりのチャンクとして表される）オペレーションサイズ、及びオフセット頻度に加えて、読み出し性能を改善するため、取り込み中に記録される更なる詳細がマップヘッダ内に含められてもよい。従って第１バイト５０２は、予約ビット５０６、特殊値インジケータ５０８（１ビット）、マップ状態５１０（２ビット）、及び２のべき乗引く１０としてのチャンクサイズ５１２（４ビット）を含んでもよい。第２バイト５０４は、２のべき乗としてのオペレーション当たりのチャンク５１４（２ビット）、及び２のべき乗としてのオフセット頻度５１６（４ビット）を含んでもよい。

特殊値インジケータ５０８は、マップ内で任意の特殊値が使用されているか否かを示してもよい。特殊値が使用されていない場合、６４Ｋ－１のようなエントリは、実際の圧縮サイズを意味し、オペレーションの開始においてではなく計算されたチャンク上で解凍を開始することができる。一例として「０」は特殊値がないことを示してもよく、６４Ｋ－１は実サイズとして扱うことができる一方、「１」は少なくとも１つの特殊値が使用されたこと（その逆も同様）を示してもよい。

マップ状態５１０は、実際にマップがあるのか否か、マップがヘッダ又は圧縮オブジェクトに続くか否か、及びマップが任意の非圧縮チャンクを含むか否かを示してもよい。オブジェクトが圧縮されないためにチャンクのいずれもが圧縮されていない場合は、マップヘッダがないことがあり、従ってマップは不要である。加えて、全てのチャンクが圧縮され、このサイズオブジェクトについて範囲要求が予期されない場合は、マップは指定されない。或いはマップがインラインとして指定され、マップがヘッダに続く場合、マップを得るための追加のクラウド読み出しをなくしてもよい。加えて、マップ内の全てのチャンクが圧縮されている場合、０の位置からの読み出しはマップを必要としない。一例として「０」はマップなしを示してもよく、「１」はマップがインラインであること（マップコンテンツが圧縮オブジェクトではなくヘッダに続くこと）を示してもよく、「２」は、マップは外部にあり全てのチャンクが圧縮されることを示してもよく、「３」は、マップは外部にありいくつかのチャンクは圧縮されないことを示してもよい。

（（２のべき乗）－１０）として表されるチャンクサイズ（４ビット）（１ＫＢ－３２ＭＢのチャンクサイズ）５１２は、マップによって表されるチャンクのチャンクサイズを示してもよい。この例ではヘッダ内の値が、１６－１０に等しい「６」である。その結果、１６が２のべき乗であり、チャンクサイズは６４Ｋである。

２のべき乗として表されるオペレーション当たりのチャンク５１４は、既定値としてもよく又はユーザによって指定されてもよい。更に、２のべき乗として表されるチャンク当たりのオフセット頻度（４ビット）５１６も、マップ内の絶対オフセット間で生じるマップエントリの数（圧縮サイズ）を示す既定値であってもよい。

上記で論じたデータ構造３００から拡張した設定例に基づいて、チャンクサイズ＝６４Ｋ、オペレーションサイズ＝２５６Ｋ（４チャンク）、及び絶対オフセット頻度＝８である。更にマップは特殊値を含み、いくつかのチャンクは圧縮されていない。

加えて、ヘッダ５００は、範囲要求を満たすための部分的なマップ読み出しを可能にする最適化を含んでもよい。例えば大きいオブジェクトのマップのサイズは数メガバイトであり得るので、狭い範囲のために全マップを読み出すことはコストが多大になり過ぎる場合がある。この問題に対処するために、圧縮オブジェクト内への絶対オフセットは、所定のオフセット頻度に基づいてマップ内に配置されてもよい。この頻度は最終的なチャンク数に基づいており、チャンクサイズ又はマップの短縮の有無の影響を受けなくてもよい。オフセット頻度は、圧縮オブジェクト内の範囲の位置を決定するためにアクセス可能なマップ内の独立した固定サイズのセグメントを作成する。マップセグメントは、第１のチャンクのための圧縮オブジェクト内への８バイトの絶対オフセットと、その後に続くその後の（オフセット頻度）チャンクのための圧縮サイズエントリとを含んでもよい。従ってオフセット頻度５１６は、マップを解析することができるように、マップヘッダ５００内に含まれてもよい。

図６は、いくつかの実装形態に係るマップ６００のデータ構造の構成例を示す。マップ６００は、オペレーション当たりの圧縮チャンクサイズ表現の数を示すオペレーションサイズインジケーション６０２を含み、圧縮チャンクサイズ表現６０４及び圧縮オブジェクト内への周期的な絶対オフセット６０６の一覧を更に含む。例えば、圧縮チャンクサイズ表現に使用されるバイト数は、チャンクサイズに基づいて最小かされ、例えばチャンクサイズが６４Ｋを上回らない限り２バイトに、６４Ｋを上回る場合は圧縮チャンクサイズ表現６０４に３バイト６０８を使用してもよい。上記で述べたように、圧縮サイズ表現は、対応するチャンクの実際の圧縮サイズであってもよく、圧縮が使用されなかったことを示すために「０」であってもよく、又はオペレーション内のエントリの和が圧縮オペレーションサイズであるが個々のチャンクの圧縮サイズが未知であることを示すために特殊値としてもよい。

絶対オフセット６０６は、前回の絶対オフセット６０６以降の全ての圧縮及び非圧縮チャンクサイズの和である。絶対オフセット６０６は８バイト６０８であってもよく、単に先行するチャンクのエントリの和ではない。例えば絶対オフセットを計算するとき、圧縮オブジェクト内のその後のエントリに関連するチャンクの位置を特定するために絶対オフセット６０６を使用することができるように、任意の０は、対応するチャンクの非圧縮チャンクサイズで置換される。最大オブジェクトサイズが２５６ＴＢ未満である場合、絶対オフセット６０６に使用される８バイトのうちの２バイトは、絶対オフセットを示すためにハードコードされてもよい。

従ってマップ内で、非圧縮チャンクサイズが＜＝６４ｋである場合は圧縮チャンクサイズは２バイトで表され、又はチャンクサイズが＞６４ｋ＆＜＝１６Ｍである場合は圧縮チャンクサイズは３バイトで表され、チャンクサイズが＞１６Ｍである場合は圧縮チャンクサイズは４バイトで表される。更に、それぞれのオペレーション（チャンク群）について各チャンクがチャンクのサイズ未満に圧縮される場合、圧縮チャンクのサイズがマップに追加される。全てのチャンクが圧縮されない場合、表現としてゼロが使用されてもよい。それ以外は、オペレーションサイズの合計がオペレーションの圧縮サイズに等しくてもよいが、オペレーション内に含まれる表現される個々のチャンクは対応するチャンクの圧縮サイズを必ずしも示さない。

本明細書のマップは、ユーザのニーズに最も上手く適合するように好みに基づいてユーザによって設定されてもよい。ユーザが非常に狭い範囲に対する高速アクセスを必要とする場合、マップは１ＫＢ等の小さいチャンクサイズで開始することができる。２バイトのエントリを有する最適化マップが未決定の作業負荷の目標である場合、６４ＫＢの初期チャンクサイズを使用することができる。メモリの可用性が小さい又は非常に大きいオブジェクトに対するアクセス速度がさほど重要でない場合、４ＭＢ等の大きいオペレーションサイズを使用することができる。マップを読み出す時間よりも圧縮比の方が重要である場合、３２７６８等の高いオフセット頻度を使用することができる。短縮のガイドラインも構成することができる。取り込み中にマップの短縮を試みるときに、マップメモリフットプリントを特定してもよい。結果として生じるより小さなマップが効率を高め得る場合、完了後にマップ短縮を試みるべきかどうか及び何回試みるべきかを指定することもできる。構成の選択肢はチャンクサイズ、オペレーションサイズ、オフセット頻度、最大マップメモリ、及び短縮の価値があるマップサイズ目標を含む。オペレーションサイズはチャンクサイズの２のべき乗倍としてもよい。オフセット頻度はオペレーション当たりのチャンクの倍数としてもよい。更に図６にはマップのデータ構造の構成例が示荒れているが、同じ機能を実行するために考えられる他の多数のデータ構造の構成が本開示の利益を得る当業者に明らかになる。

図７は、いくつかの実装形態に係るマップ７００のデータ構造の構成例を示す。この例では、マップ７００はチャンクごとの個々のチャンクサイズ表現７０２、及び説明目的の記述７０４を含む。例えばロウ７０６～７１２のチャンクサイズ表現は非圧縮であり、従ってロウ７０６～７１２についてチャンクサイズ表現に割り当てられる値は「０」である。更に、ロウ７１４、７１８、７２０、７２６、及び７３０は特殊サイズエントリを有する一方、ロウ７１６、７２４、及び７２８は個々のチャンクに特殊サイズからの幾らかのオーバーフローを加えたサイズを含む。さらにロウ７３２～７３８及び７４２～７４６は通常の圧縮データを有するのに対し、ロウ７２２及び７４０は絶対オフセットとして役割を果たす。

この例では、チャンクサイズ＝６４Ｋ、オペレーションサイズ＝２５６Ｋ（４チャンク）、及び絶対オフセット頻度＝８であると仮定する。従ってマップ７００は、チャンクサイズ表現７０６～７１２を含む第１オペレーション７５０、チャンクサイズ表現７１４～７１６を含む第２オペレーション７５２、チャンクサイズ表現７２４～７３０を含む第３オペレーション７５４、チャンクサイズ表現７３２～７３８を含む第４オペレーション７５６、及びチャンクサイズ表現７４２～７４６を含む第５オペレーション７５８との５つのオペレーションを含む。

図８は、いくつかの実装形態に係る１回の短縮後のマップ８００のデータ構造の構成例を示す。この例では、１回の短縮後にチャンクサイズ＝１２８Ｋ（３バイトサイズのエントリ）であり、絶対オフセット頻度＝８のままである。更に短縮は、図７のマップ７００からの２つのチャンクサイズの結合をそれぞれ表す、オペレーション当たり２つのチャンクサイズ表現をもたらしている。例えば、第１オペレーション７５０は４つのチャンクサイズ表現から２つのチャンクサイズ表現８０２及び８０４に短縮され、第２オペレーション７５２は４つのチャンクサイズ表現から２つのチャンクサイズ表現８０６及び８０８に短縮され、第３オペレーション７５４は４つのチャンクサイズ表現から２つのチャンクサイズ表現８１０及び８１２に短縮され、第４オペレーション７５６は４つのチャンクサイズ表現から２つのチャンクサイズ表現８１４及び８１６に短縮され、第５オペレーション７５８は３つのチャンクサイズ表現から２つのチャンクサイズ表現８２０及び７４６に短縮されている。第５オペレーション７５８内には奇数のチャンクサイズ表現があるので、この例における最後のチャンクサイズ表現７４６は短縮中に別のチャンクサイズ表現と結合されておらず、従って短縮前と同じ値を保っている。

短縮の結果として、第１オペレーション７５０内の８０２及び８０４のチャンクサイズ表現の値は、短縮中に「０」を結合することに基づいてどちらも「０」である。第２オペレーション７５２は、８０６におけるオーバーフロー値を有するサイズ、及び８０８における特殊サイズを含む。絶対オフセット８１８におけるオペレーション７５０、７５２、７５４、及び７５６の全体値は、圧縮マップ８００内で７８２３３０であり、これは、図７のマップ７００内の絶対オフセット７４０の値と同じである。

図９～図１２は、いくつかの実装形態に係る処理の例を示す流れ図である。これらの処理は論理流れ図のブロックの集まりとして示してあり、それらのブロックはその一部又は全てをハードウェア、ソフトウェア、又はそれらの組み合わせによって実装し得る一連のオペレーションを表す。ソフトウェアの脈絡では、ブロックは、１又は複数のプロセッサによって実行されるとき、列挙したオペレーションを実行するようにプロセッサをプログラムする１又は複数のコンピュータ可読媒体に記憶されるコンピュータ実行可能命令を表してもよい。典型的にはコンピュータ実行可能命令は、特定の機能を実行し又は特定のデータ型を実装するルーチン、プログラム、オブジェクト、コンポーネント、データ構造等を含む。ブロックが記載される順序は限定として解釈すべきではない。記載されるブロックの任意の個数は、任意の順序で及び／又は並列に組み合わせてこの処理又は代替的処理を実施することができ、ブロックの全てを実行しなければならない訳ではない。本明細書の例の中で記載した環境、枠組み、及びシステムに関して処理を論述目的で説明したが、これらの処理は多岐にわたる他の環境、枠組み、及びシステム内で実装されてもよい。

図９は、いくつかの実装形態に係る圧縮及びマップ生成のための処理９００の一例を示す流れ図である。いくつかの事例では、処理９００はサービス計算装置又は他の適切な計算装置によって少なくとも部分的に実行されてもよい。一例として、図１に関して上記で論じたサービス計算装置１０２の１又は複数のプロセッサ１１０によって実行されるストレージプログラムは、図９の処理９００の少なくとも一部を実行するための実行可能命令を含んでもよい。

データはチャンクごとに圧縮されるが、結果は圧縮について決定されてもよく、マップは、複数のチャンクのオペレーションに基づいて作成されてもよい。オペレーション内の各チャンクは圧縮され、メモリ内のマップの中に結果が記憶される。オペレーションに対する圧縮が有用でない場合は圧縮が使用されず、全ての圧縮チャンクサイズがマップ内で「０」にラベル付けされる。これに代えて、圧縮がオペレーション全体について有用だが（例えばオペレーションを圧縮することによって圧縮の閾値レベルが達成される）、オペレーション内の１又は複数のチャンクの圧縮がそうではない場合、圧縮サイズは圧縮チャンクサイズフィールド内に収まらず、その１又は複数のチャンクについてマップエントリ内に特殊サイズ、例えば２バイトフィールドチャンク表現の場合は［６４Ｋ－１］又は３バイトフィールドチャンク表現の場合は［１６Ｍ－２５６］が入力される。更にオーバーフローサイズ（例えば圧縮サイズの量が特殊サイズを上回る場合）は、特殊サイズチャンク表現を一緒に短縮することができ、十分な空きを有する近隣チャンク表現に割り振られてもよい。

他の事例では、オペレーションの圧縮が有用であり、圧縮チャンクサイズがチャンクサイズ表現のマップエントリ内に収まる場合、チャンクサイズ表現は、実際の圧縮サイズとしてラベル付けされる。マップは集合間で、又は一部の事例ではデータの圧縮完了後に短縮されてもよい。全てのオペレーションが完了した後にマップヘッダは完成され保存される。いくつかの事例では、マップヘッダはマップに付加されてもよく、又は離れて保たれてもよい。更に、一部の例では、マップは圧縮オブジェクトに付加されてもよく、又は他の例では離れて記憶されてもよい。非圧縮オブジェクトサイズ及び圧縮オブジェクトサイズは今では知られ、記録されてもよい。

９０２で、データオブジェクトの圧縮を開始する前に、計算装置は構成変数、例えばチャンクサイズ、オペレーションサイズ、絶対オフセット頻度、最大マップメモリサイズ、データベース内の最大マップサイズを受信し、及び／又は割り当ててもよい。いくつかの例では、これらのパラメータの既定値は、サービス計算装置によって行われる圧縮オペレーションを管理する管理者又は他のユーザ等のユーザによって既に確立されていてもよい。この例のために、チャンクサイズ＝６４Ｋ、オペレーションサイズ＝５１２Ｋ（８チャンク）、絶対オフセット頻度が１０２４エントリであり、最大マップメモリ＝１Ｍ、及びＤＢ内の最大マップ＝３００バイトだと仮定する。これらの値は論述目的に過ぎず、本明細書の実装形態はこれらのパラメータの或る特定の値に限定されない。

９０４で、計算装置は圧縮用のデータを受信し、受信したデータの少なくとも一部を、例えばデータのオペレーションサイズまでインジェストバッファ内に記憶するようにしてもよい。いくつかの例では、データはネットワークを介してストリーミングデータとして受信されてもよく、他の事例ではデータは記憶位置等から読み出されてもよい。

９０６で、計算装置は、出力バッファ内に受信したデータのチャンクサイズまで圧縮してもよく、一時的なオペレーションの集合内にチャンクの圧縮サイズを記憶してもよい。

９０８で、計算装置はインジェストバッファ内に更にデータがあるか否かを判定してもよい。例えば、オペレーション分のデータ（例えば上記の９０２で述べた指定のオペレーションサイズ（５１２Ｋ）に対応するこの例の８チャンクサイズの量）がインジェストバッファに追加される場合、計算装置はインジェストバッファが空になるまでインジェストバッファ内のデータの個々のチャンクに対して操作してもよい。インジェストバッファが空の場合、オペレーション分のデータが処理されており、計算装置は圧縮の閾値レベルがオペレーションについて満たされているか否かを判定してもよい。インジェストバッファ内にデータが依然としてある場合、この処理は９０６に戻る。それ以外の場合には、この処理は９１０に進む。

９１０で、計算装置は、オペレーション内のチャンクの集合を、チャンクサイズから１を引いた値とオペレーション内のチャンク数とを掛けた値未満に圧縮するか否かを判定してもよい。例えばこの例の圧縮閾値の特定値は（６４Ｋ－１）・８である。オペレーションが閾値未満に圧縮する場合、この処理は９１２に進む。そうでなければ、この処理は９１４に進む。

９１２で、圧縮閾値が満たされる場合、計算装置は圧縮サイズの集合を更新してもよく、６４Ｋを上回る値を６４Ｋ－１に等しい値に低減し、例えば図３及び図４に関して上記で論じたようにオーバーフロー（差）を別のチャンクサイズ表現エントリに加えてもよい。更に計算装置はマップ内のメモリ内チャンクサイズリストに値を移してもよく、既に処理されているいずれかのオブジェクトデータに出力バッファ内の圧縮データを付加してもよい。

９１４では、他方で、圧縮閾値が満たされない場合、計算装置はマップ内のメモリ内チャンクサイズリストに全て０を保存してもよく、既に処理されているいずれかのオブジェクトデータにインジェストバッファのデータを付加してもよい。

９１６で、計算装置は、インジェストバッファ内に取り込むための更なるデータがあるか否かを判定してもよい。該当する場合、この処理は９１８に進む。該当しない場合、この処理は９２２に進む。

９１８で、インジェストバッファ内に取り込むための更なるデータがある場合、計算装置はチャンクサイズリストが１ＭＢを上回るか否かを判定することにより、既存のマップを短縮することが望ましいか否かを判定してもよい。例えば上記の９０２で、最大マップメモリは１ＭＢに指定されている。従って、この時点でマップサイズがこの量を上回る場合は、マップは短縮されてもよい。上回らない場合、この処理は９０４に戻って更なるデータをインジェストバッファに追加する。

９２０で、マップサイズが指定された閾値量（例えばこの例では１ＭＢ）を上回る場合、計算装置は、近隣の対を結合し、チャンクサイズを２倍にすることによって、マップ内のチャンクサイズリストを短縮してもよい。このオペレーションが可能である（例えばチャンクサイズが依然としてオペレーションサイズ未満である）場合、構成情報内で指定された１ＭＢ未満にマップサイズを低減するのに１回の短縮で十分だと予期される。マップの短縮後、この処理は９０４に戻って更なるデータをインジェストバッファに追加する。

９２２で、インジェストバッファに追加するデータがこれ以上ない場合、このことはデータオブジェクトの圧縮が完了したことを示し、計算装置はマップを最大ＤＢサイズに短縮され得るか否かを判定してもよい。該当する場合、この処理は９２４に進む。該当しない場合、この処理は図１０の処理に進む。

９２４で、計算装置はマップサイズが最大マップＤＢサイズ未満になるまで、例えばこの例では３００バイト未満になるまで、近隣の対を結合し、チャンクサイズを２倍にすることによって、マップ内のチャンクサイズリストを短縮してもよい。マップの短縮後、この処理は図１０の処理に進む。

図１０は、いくつかの実装形態に係る図９の処理９００の続きである処理１０００の一例を示す流れ図である。

１００２で、計算装置はチャンクサイズ、オペレーションサイズ、オフセット頻度、及び図５に関して上記で論じた他のパラメータを有するマップのマップヘッダを完成してもよく、図１に関して上記で論じたメタデータデータベース１２０等のデータベース内に少なくともマップヘッダを記憶してもよい。いくつかの事例ではマップもデータベース内に記憶してもよく、及び／又はマップは、ネットワークストレージで記憶するためにオブジェクトに付加されてもよい。

１００４で、計算装置はマップサイズリストが３００バイト、例えば最大ＤＢサイズ未満であるか否かを判定してもよい。該当しない場合、この処理は１００６に進む。該当する場合、この処理は１０１４に進む。

１００６で、計算装置は圧縮オブジェクトをサイズリストエントリに付加し、絶対オフセットにおける合計サイズが正確であるように、０の代わりに最終チャンクサイズを使用してサイズを累積合計に加えてもよい。

１００８で、計算装置はマップ内に更にエントリがあるか否かを判定してもよい。該当する場合、この処理は１０１０に進む。該当しない場合、この処理は１０１６に進む。

１０１０で、計算装置は追加のエントリがオフセット頻度にあるか否かを判定してもよい。該当する場合、この処理は１０１２に進む。該当しない場合、この処理は１００６に進む。

１０１２で、計算装置は圧縮オブジェクト、サイズリストエントリの累積合計を付加してもよく、１００６に戻る。

１０１４で、マップサイズリストがデータベースの最大閾値、例えばこの例では３００バイト未満、である場合、計算装置はマップとしてメタデータデータベース内のマップヘッダをサイズリストに付加してもよい。

１０１６で、計算装置は圧縮オブジェクト（及び圧縮オブジェクトに付加される場合はマップ）を記憶するために記憶位置に送信してもよい。例えば図１に関して上記で論じたように、いくつかの例では圧縮オブジェクト及びマップはネットワーク記憶位置に記憶されてもよい。

図１１は、いくつかの実装形態に係るマップに基づく解凍のための処理１１００の一例を示す流れ図である。いくつかの事例では、処理１１００はサービス計算装置又は他の適切な計算装置によって少なくとも部分的に実行されてもよい。一例として、図１に関して上記で論じたサービス計算装置１０２の複数の中の１つのプロセッサによって実行されるストレージプログラムは、図１１の処理１１００の少なくとも一部を実行するための実行可能命令を含んでもよい。

圧縮データオブジェクトの少なくとも一部にアクセスするための要求が受信された場合、サービス計算装置は例えば図５に関して上記で論じたようなチャンクサイズ、オペレーションサイズ、オフセット頻度、マップ状態、及び特殊値インジケータを含むパラメータを決定するために、オブジェクトのマップヘッダにアクセスし、読み出してもよい。マップがない又は全てのチャンクが圧縮され、要求が０の位置で開始する場合、計算装置はマップなしにオブジェクトの全データを解凍してもよい。例えばオブジェクトはマップ等を生成するのに十分大きくなかった可能性がある。

いくつかの例では、マップがヘッダと共にメタデータデータベース内に記憶された場合はマップはヘッダの後に見つけられることができ、又は他の例ではマップは圧縮オブジェクトの末尾に付加され又は離れた記憶位置に記憶される。マップサイズは、チャンク数（非圧縮オブジェクトサイズ割るチャンクサイズ）掛ける圧縮チャンクサイズ表現エントリ内のバイト数足す絶対オフセット数（チャンク数割るオフセット頻度）掛けるオペレーション内のチャンク数（例えば図９及び図１０の例では８）として計算してもよい。マップが圧縮オブジェクトに付加されている場合、マップは圧縮オブジェクトの終わりよりもマップサイズバイトだけ前において見つけられる。

計算装置は、例えば（要求開始／（オフセット頻度^＊チャンクサイズ））に基づいて要求が開始するマップセグメントを決定してもよい。計算装置は、計算された最初のセグメントから要求サイズの最終セグメントまでマップセグメントを読み出してもよい。計算装置は、要求開始の後に来ない最終オペレーションまでスキップしてもよい。オペレーション内の任意のチャンクが特殊サイズ（６４Ｋ－１の倍数）を有することができ、有する場合、計算装置は要求された開始位置よりも前のデータを破棄してオペレーション内の最初のチャンクから続けて解凍してもよい。オペレーション内のチャンクが０又は特殊サイズを有さない場合、計算装置は次のチャンクの位置が高くなるまでチャンクをスキップし、解凍を開始し、要求された開始位置よりも前のデータを破棄してもよい。圧縮サイズエントリが０である場合、計算装置は要求されたオペレーション内の位置からオペレーションの残りの部分まで圧縮オブジェクトのデータを複製してもよい。任意の圧縮サイズエントリが０である場合、計算装置は要求サイズが満たされるまでその後必要とされるオペレーションを解凍し続ける又はデータを複製し続けてもよい。

１１０２で、計算装置はデータにアクセスするための要求を受信してもよく、対応するマップヘッダからパラメータ、例えばチャンクサイズ、オペレーションサイズ、及びオフセット頻度を取得してもいい。例えばユーザ、アプリケーション等は、１又は複数の記憶済み圧縮オブジェクトの１又は複数の部分にアクセスすることを要求してもよい。例えばリード要求は圧縮オブジェクトからのデータの範囲に対するものであってもよい。開始位置及びサイズは、例えば非圧縮オブジェクト内の開始位置及びサイズに基づいて要求内に指定されてもよい。

１１０４で、計算装置は既知の非圧縮オブジェクトサイズに基づいてマップのサイズを判定してもよく、例えばマップは圧縮オブジェクトサイズ引くマップサイズにおいて開始してもよい。例えば圧縮オブジェクトサイズ及び非圧縮オブジェクトサイズは、オブジェクトの取り込み及び圧縮中にメタデータデータベース内に記憶されていてもよい。

１１０６で、計算装置は要求に対応するセグメントを、例えば（要求開始／（オフセット頻度^＊チャンクサイズ）に基づいて決定してもよい。更に計算装置はマップセグメントを読み出し、圧縮オフセットを（第１の値－絶対オフセット）に設定し、非圧縮位置を（セグメント数^＊オフセット頻度^＊チャンクサイズ）に設定してもよい。例えば、マップセグメントは圧縮オブジェクト内の相対的位置を確立するために絶対オフセットから開始するので、マップセグメントはマップの残りの部分なしに使用可能なマップエントリの集合であってもよい。

１１０８で、計算装置は（位置＋オペレーションサイズ）が要求開始未満か否かを判定してもよい。該当する場合、この処理は１１１０に進む。該当しない場合、この処理は１１１２に進む。例えば位置は非圧縮オブジェクトから決定される位置等に基づく開始位置であってもよい。

１１１０で、計算装置は（オペレーション当たりのチャンク）のサイズを取得し、もしある場合は０に実際のチャンクサイズを使用してそれを圧縮オフセットに加え、オペレーションサイズを位置に加えてもよい。この処理は１１０８に戻って（位置＋オペレーションサイズ）が要求開始未満か否かを判定する。１１０８及び１１１０におけるオペレーションは、この処理が１１１２に進むまで繰り返される。

１１１２で、計算装置は現在のオペレーションについて全ての圧縮サイズを得てもよく、図１２の処理に進めてもよい。

図１２は、いくつかの実装形態に係る図１１の処理１１００の続きである処理１２００の一例を示す流れ図である。

１２０２で、計算装置は圧縮サイズが全てゼロであるか否かを判定してもよい。該当する場合、この処理は１２１８に進む。該当しない場合、この処理は１２０４に進む。

１２０４で、計算装置は特殊値（（６４Ｋ－１）の倍数）があるか否かを判定してもよい。該当する場合、この処理は１２１４に進む。該当しない場合、この処理は１２０６に進む。

１２０６で、計算装置は（位置＋チャンクサイズ）＜要求開始であるか否かを判定してもよい。該当する場合、この処理は１２０８に進む。該当しない場合、この処理は１２１０に進む。

１２０８で、計算装置は圧縮サイズをオフセットに加えてもよく、チャンクサイズを位置に加えてもよい。

１２１０で、計算装置は計算装置は、オペレーション内の残りのチャンクを解凍し、（要求開始－位置）を破棄してもよい。

１２１２で、計算装置は残りの圧縮サイズをオフセットに加え、残りのチャンクサイズを位置に加え、読み出したデータを要求開始に加え、読み出したデータを要求サイズから引いてもよい。

１２１４で、１２０４で発見された特殊値がある場合、計算装置は全てのオペレーションデータを解凍し、（要求開始－位置）を破棄してもよい。

１２１６で、計算装置は全ての圧縮サイズをオフセットに加え、オペレーションサイズを位置に加え、読み出したデータを要求開始に加え、読み出したデータを要求サイズから引いてもよい。

１２１８で、オペレーションの圧縮サイズが１２０２で全てゼロである場合、計算装置は（オフセット＋要求開始－位置）において解凍なしにデータの読み出しを開始してもよく、オペレーションデータの残りの部分まで読み出してもよい。

１２２０で、計算装置はオペレーションサイズを位置及びオフセットに加え、読み出したデータを要求開始に加え、読み出したデータを要求サイズから引いてもよい。

１２２２で、計算装置は要求サイズがゼロを上回るか否かを判定してもよい。該当する場合、この処理は１２２４に進む。該当しない場合、この処理は１２２８に進む。

１２２４で、計算装置はセグメント内に更にチャンク表現があるか否かを判定してもよい。該当する場合、この処理はブロック１１１２へと図１１の処理に進む。該当しない場合、この処理は１２２６に進む。

１２２６で、計算装置は次のマップセグメントを読み出し、図１１のブロック１１１２に進んでもよい。

１２２８で、要求サイズがゼロに達すると、計算装置はまだ解凍されていない圧縮データを解凍してもよく、要求に応答してもよい。

本明細書に記載した処理例は論述目的で示した処理の例に過ぎない。本明細書の開示に照らして数多くの他の改変形態は当業者に明らかになる。更に、本明細書の開示は処理を実行するのに適した枠組み、アーキテクチャ、及び環境の幾つかの例を記載したが、本明細書の実装形態は図示し述べた具体例に限定されない。更に、本開示は記載し図中に示した様々な実装形態の例を提供する。但し本開示は、本明細書に記載し示した実装形態に限定されず、当業者に知られる又は当業者に知られることになる他の実装形態に及び得る。

本明細書に記載した様々な命令、処理、及び技術は、コンピュータ可読媒体上に記憶され、本明細書のプロセッサによって実行されるプログラム等のコンピュータ実行可能命令の全般的な脈絡において検討することができる。典型的にはプログラムは、特定のタスクを実行し又は特定の抽象データ型を実装するためのアプリケーション、ルーチン、オブジェクト、構成部、データ構造、実行可能コード等を含む。これらのプログラム等はネイティブコードとして実行されてもよく、又は仮想マシン若しくは他のジャストインタイムコンパイル実行環境等の中でダウンロードし実行されてもよい。典型的には、プログラムの機能は様々な実装形態において所望の通りに組み合わせられ又は分散されてもよい。これらのモジュール及び技術の実装はコンピュータ可読記憶媒体上に記憶されてもよく、又は何らかの形の通信媒体上で伝送されてもよい。

構造上の特徴及び／又は方法論的な行為に固有の言語によって本内容を説明してきたが、添付の特許請求の範囲に定める本内容は記載した特定の特徴又は行為に必ずしも限定されないことを理解すべきである。むしろ特許請求の範囲を実装する形態の例として特定の特徴及び行為を開示している。

Claims (15)

1. システムであって、
   １又は複数のプロセッサと、
   前記１又は複数のプロセッサによって実行されると、前記１又は複数のプロセッサをオペレーションを実行するように構成する実行可能命令を記憶する１又は複数の非一時的コンピュータ可読媒体とを含み、前記オペレーションは、
   データオブジェクトの複数のデータチャンクを受信すること、
   複数の圧縮チャンクを得るために前記複数のデータチャンクを圧縮すること、
   前記複数の圧縮チャンクの全体が第１閾値サイズ未満であるか否かを判定すること、
   前記複数の圧縮チャンクの全体が前記第１閾値サイズ未満であると判定したことに基づいて、前記複数の圧縮チャンクの個々のサイズを、マップデータ構造内の個々のエントリに加えること、
   前記個々のエントリの少なくとも２つの中の値を結合することによって前記マップデータ構造を短縮すること、及び
   前記複数の圧縮チャンク及び短縮マップデータ構造を記憶することを含む
   、システム。
2. 請求項１に記載のシステムにおいて、
   前記複数のデータチャンクは前記データオブジェクトの第１の複数のデータチャンクであり、前記複数の圧縮チャンクは第１の複数の圧縮チャンクであり、前記オペレーションは、
   前記データオブジェクトの第２の複数のデータチャンクを受信すること、
   第２の複数の圧縮チャンクを得るために前記第２の複数のデータチャンクを圧縮すること、
   前記第２の複数の圧縮チャンクの全体が前記第１閾値サイズ未満であるか否かを判定すること、
   前記第２の複数の圧縮チャンクの全体が前記第１閾値サイズ未満ではないと判定したことに基づいて、前記第２の複数のデータチャンクが圧縮されていないことを示す値を、前記マップデータ構造内の個々のエントリに加えること、及び
   前記第１の複数の圧縮チャンクと共に、前記第２の複数のデータチャンクを非圧縮形式で記憶すること
   を更に含む、システム。
3. 請求項１に記載のシステムにおいて、
   前記複数の圧縮チャンクと共に含まれる前記複数のデータチャンクのうちの前記データチャンクの少なくとも１つは圧縮不能であり、前記複数の圧縮チャンクは全体的に圧縮可能であり、前記オペレーションは、
   前記マップデータ構造内の前記個々のエントリ内に前記データチャンクの前記少なくとも１つについての所定値を含めることであって、前記所定値は前記データチャンクの前記少なくとも１つが圧縮されていないことを示すサイズを有する、含めること、及び
   前記所定値と前記データチャンクの前記少なくとも１つの実際のサイズ値との差に相当するオーバーフロー値を、前記複数の圧縮チャンクのうちの前記圧縮チャンクの少なくとも１つに対応する前記マップデータ構造内の少なくとも１つの他のエントリに割り振ること
   を更に含む、システム。
4. 請求項３に記載のシステムにおいて、
   前記オペレーションは、
   前記圧縮チャンクのそれぞれが個々に第２閾値サイズ未満であるか否かを判定すること、
   試みられた圧縮の後で前記複数のデータチャンクのうちの前記データチャンクの前記少なくとも１つの前記実際のサイズ値が前記第２閾値サイズを上回っていると判定したことに基づいて、前記データチャンクの前記少なくとも１つが圧縮不能であると判定すること、
   前記マップデータ構造内の前記データチャンクの前記少なくとも１つの前記個々のエントリ内に圧縮サイズとして前記所定値を入力すること、及び
   前記実際のサイズ値と前記所定値との前記差を、前記圧縮チャンクの前記少なくとも１つの前記圧縮サイズに加えることによって前記オーバーフロー値を割り当てることであって、前記圧縮チャンクの前記少なくとも１つは、前記第２閾値サイズ未満の圧縮サイズを有する、割り振ること
   を更に含む、システム。
5. 請求項３に記載のシステムにおいて、
   前記マップデータ構造を短縮する間、前記所定値は、前記マップデータ構造内の近隣のエントリの値と結合される、システム。
6. 請求項１に記載のシステムにおいて、
   前記オペレーションは、
   前記マップデータ構造又は前記短縮マップデータ構造の少なくとも１つについてヘッダを生成することを含み、前記ヘッダはチャンクサイズのしるし及び前記短縮マップデータ構造の記憶位置のしるしを含む、システム。
7. 請求項６に記載のシステムにおいて、
   前記短縮マップデータ構造を記憶することは、
   前記短縮マップデータ構造を前記ヘッダに関連してメタデータデータベース内に記憶すること、又は
   前記データオブジェクトの少なくとも一部の圧縮後に、前記短縮マップデータ構造を前記データオブジェクトに関連してネットワーク記憶位置に記憶すること
   の少なくとも１つを含む、システム。
8. 請求項１に記載のシステムにおいて、
   前記オペレーションは、
   前記データオブジェクトの少なくとも部分的な圧縮後に前記データオブジェクト内のデータにアクセスするための要求を受信すること、
   前記データオブジェクトから取得すべきデータの範囲を決定すること、
   前記範囲に基づき、前記短縮マップデータ構造を使用して前記データオブジェクトの前記少なくとも部分的な圧縮後に、前記データオブジェクトの一部を読み出すこと、
   前記データの範囲を得るために前記データオブジェクトの前記一部の中の圧縮データを解凍すること、及び
   前記要求に応答して前記データの範囲を返すこと
   を更に含む、システム。
9. 請求項８に記載のシステムにおいて、
   前記マップデータ構造は、前記マップデータ構造内の前記エントリについての参照点としての少なくとも１つのオフセットインジケータを含み、個々のオフセットインジケータは非圧縮状態にある前記データオブジェクト内の個々の位置に関連付けることができ、
   前記短縮マップデータ構造を使用して前記データオブジェクトの一部を読み出すことは、
   前記要求に対応する、非圧縮形式にある前記データオブジェクト内の位置を決定すること、
   前記データオブジェクトの少なくとも部分的な圧縮後に、前記位置を、前記データオブジェクト内の開始位置として前記マップデータ構造内のオフセットインジケータに相関させること、及び
   前記開始位置及び前記短縮マップデータ構造内の前記エントリに基づいてデータを読み出すこと
   を含む、システム。
10. 請求項８に記載のシステムにおいて、
    前記短縮マップデータ構造を使用して前記データオブジェクトの一部を読み出すことは、
    前記要求に対応する、非圧縮形式にある前記データオブジェクト内の位置を決定すること、
    前記データオブジェクト内の開始位置を決定するために、前記短縮マップデータ構造内の少なくとも１つのエントリ内で示される少なくとも１つのチャンクの圧縮サイズに基づいて、前記データオブジェクト内の前記位置を前記短縮マップデータ構造内の位置に関係づけること、及び
    少なくとも前記開始位置に基づいて前記データオブジェクトのデータを読み出すこと
    を含む、システム。
11. 請求項１に記載のシステムにおいて、
    前記オペレーションは、
    前記短縮マップデータ構造のサイズが閾値マップサイズ未満になるまで、前記マップデータ構造を複数回短縮することを更に含む、システム。
12. 請求項１に記載のシステムにおいて、
    前記マップデータ構造は、前記複数の圧縮チャンクについての参照点としてのオフセットインジケータを含み、前記オフセットインジケータは、非圧縮状態にある前記データオブジェクト内の位置に関連付けることができ、前記オフセットインジケータは、前記マップデータ構造内の前記オフセットインジケータに先行するエントリに対応する圧縮チャンク及び非圧縮チャンクの合計サイズを示す、システム。
13. １又は複数のプロセッサによって実行されると、前記１又は複数のプロセッサを、オペレーションを行うようにプログラムする命令を格納する１又は複数の非一時的コンピュータ可読媒体であって、
    前記オペレーションは、
    データオブジェクトの複数のデータチャンクを受信すること、
    前記複数のデータチャンクを圧縮して複数の圧縮チャンクを得ること、
    前記複数の圧縮チャンクの全体が閾値サイズ未満であるか否かを判定すること、
    前記複数の圧縮チャンクの全体が前記閾値サイズ未満であると判定されたことに基づいて、前記複数の圧縮チャンクの個々のサイズを、マップデータ構造内の個々のエントリに加えること、
    前記個々のエントリの少なくとも２つの中の値を結合することによって前記マップデータ構造を短縮すること、及び
    前記複数の圧縮チャンク及び短縮された前記マップデータ構造を記憶すること
    を含む、１又は複数の非一時的コンピュータ可読媒体。
14. 方法であって、
    １又は複数のプロセッサによって、データオブジェクトの複数のデータチャンクを受信することと、
    前記複数のデータチャンクを圧縮して複数の圧縮チャンクを得ることと、
    前記複数の圧縮チャンクの全体が閾値サイズ未満であるか否かを判定することと、
    前記複数の圧縮チャンクの全体が前記閾値サイズ未満であると判定したことに基づいて、前記複数の圧縮チャンクの個々のサイズをマップデータ構造内の個々のエントリに加えることと、
    前記個々のエントリの少なくとも２つの中の値を結合することによって前記マップデータ構造を短縮することと、
    前記複数の圧縮チャンク及び短縮された前記マップデータ構造を記憶することと
    を含む、方法。
15. 請求項１４に記載の方法において、
    前記複数の圧縮チャンクのための参照点として少なくとも１つのオフセットインジケータを前記マップデータ構造内に含めることであって、前記オフセットインジケータは非圧縮状態にある前記データオブジェクト内の位置に関連付けることができる、ことを更に含み、
    前記オフセットインジケータは、前記マップデータ構造内の前記オフセットインジケータに先行するエントリに対応する圧縮チャンク及び非圧縮チャンクの合計サイズを示す、
    方法。

Images