(19)【発行国】日本国特許庁(JP)
(12)【公報種別】特許公報(B2)
(11)【特許番号】
(24)【登録日】2023-04-11
(45)【発行日】2023-04-19
(54)【発明の名称】圧縮データの記憶及び取得の最適化
(51)【国際特許分類】
G06F 16/174 20190101AFI20230412BHJP
【FI】
G06F16/174
(21)【出願番号】P 2021560689
(86)(22)【出願日】2019-04-29
(86)【国際出願番号】 US2019029560
(87)【国際公開番号】W WO2020222727
(87)【国際公開日】2020-11-05
【審査請求日】2021-10-12
(73)【特許権者】
【識別番号】520155228
【氏名又は名称】ヒタチ ヴァンタラ エルエルシー
(74)【代理人】
【識別番号】110000279
【氏名又は名称】弁理士法人ウィルフォート国際特許事務所
(72)【発明者】
【氏名】トリンブル, ロナルド レイ
【審査官】齊藤 貴孝
(56)【参考文献】
【文献】特開2006-186411(JP,A)
【文献】米国特許出願公開第2016/0050297(US,A1)
【文献】特開2006-222626(JP,A)
【文献】米国特許出願公開第2015/0154221(US,A1)
【文献】米国特許出願公開第2009/0288026(US,A1)
(58)【調査した分野】(Int.Cl.,DB名)
G06F 16/00-16/958
(57)【特許請求の範囲】
【請求項1】
システムであって、
1又は複数のプロセッサと、
前記1又は複数のプロセッサによって実行されると、前記1又は複数のプロセッサをオペレーションを実行するように構成する実行可能命令を記憶する1又は複数の非一時的コンピュータ可読媒体とを含み、前記オペレーションは、
データオブジェクトの複数のデータチャンクを受信すること、
複数の圧縮チャンクを得るために前記複数のデータチャンクを圧縮すること、
前記複数の圧縮チャンクの全体が第1閾値サイズ未満であるか否かを判定すること、
前記複数の圧縮チャンクの全体が前記第1閾値サイズ未満であると判定したことに基づいて、前記複数の圧縮チャンクの個々のサイズを、マップデータ構造内の個々のエントリに加えること、
前記個々のエントリの少なくとも2つの中の値を結合することによって前記マップデータ構造を短縮すること、及び
前記複数の圧縮チャンク及び短縮マップデータ構造を記憶することを含む
、システム。
【請求項2】
請求項1に記載のシステムにおいて、
前記複数の
データチャンクは前記データオブジェクトの第1の複数の
データチャンクであり、前記複数の圧縮チャンクは第1の複数の圧縮チャンクであり、前記オペレーションは、
前記データオブジェクトの第2の複数のデータチャンクを受信すること、
第2の複数の圧縮チャンクを得るために前記第2の複数のデータチャンクを圧縮すること、
前記第2の複数の圧縮チャンクの全体が前記第
1閾値サイズ未満であるか否かを判定すること、
前記第2の複数の圧縮チャンクの全体が前記第
1閾値サイズ未満ではないと判定したことに基づいて、前記第2の複数の
データチャンクが圧縮されていないことを示す値を、前記マップデータ構造内の個々のエントリに加えること、及び
前記第1の複数の圧縮チャンクと共に、前記第2の複数の
データチャンクを非圧縮形式で記憶すること
を更に含む、システム。
【請求項3】
請求項1に記載のシステムにおいて、
前記複数の圧縮チャンクと共に含まれる前記複数のデータチャンクのうちの前記
データチャンクの少なくとも1つは圧縮不能であり、前記複数の圧縮チャンクは全体的に圧縮可能であり、前記オペレーションは、
前記マップデータ構造内の前記個々のエントリ内に前記
データチャンクの前記少なくとも1つについての所定値を含めることであって、前記所定値は前記
データチャンクの前記少なくとも1つが圧縮されていないことを示すサイズを有する、含めること、及び
前記所定値と前記
データチャンクの前記少なくとも1つの実際のサイズ値との差に相当するオーバーフロー値を、前記複数の圧縮チャンクのうちの前記圧縮チャンクの少なくとも1つに対応する前記マップデータ構造内の少なくとも1つの他のエントリに割り振ること
を更に含む、システム。
【請求項4】
請求項3に記載のシステムにおいて、
前記オペレーションは、
前記圧縮チャンクのそれぞれが個々に第2閾値サイズ未満であるか否かを判定すること、
試みられた圧縮の後で前記複数の
データチャンクのうちの前記
データチャンクの前記少なくとも1つの前記実際のサイズ値が前記第2閾値サイズを上回っていると判定したことに基づいて、前記
データチャンクの前記少なくとも1つが圧縮不能であると判定すること、
前記マップデータ構造内の前記
データチャンクの前記少なくとも1つの前記個々のエントリ内
に圧縮サイズとして前記所定値を入力すること、及び
前記実際のサイズ値と前記所定値との前記差を、前記圧縮チャンクの前記少なくとも1つの前記圧縮サイズに加えることによって前記オーバーフロー値を割り当てることであって、前記圧縮チャンクの前記少なくとも1つは、前記第2閾値サイズ未満の圧縮サイズを有する、割り振ること
を更に含む、システム。
【請求項5】
請求項3に記載のシステムにおいて、
前記マップデータ構造を短縮する間、前記所定値は、前記マップデータ構造内の近隣のエントリの値と結合される、システム。
【請求項6】
請求項1に記載のシステムにおいて、
前記オペレーションは、
前記マップデータ構造又は前記短縮マップデータ構造の少なくとも1つについてヘッダを生成することを含み、前記ヘッダはチャンクサイズのしるし及び前記短縮マップデータ構造の記憶位置のしるしを含む、システム。
【請求項7】
請求項6に記載のシステムにおいて、
前記短縮マップデータ構造を記憶することは、
前記短縮マップデータ構造を前記ヘッダに関連してメタデータデータベース内に記憶すること、又は
前記データオブジェクトの少なくとも一部の圧縮後に、前記短縮マップ
データ構造を前記データオブジェクトに関連してネットワーク記憶位置に記憶すること
の少なくとも1つを含む、システム。
【請求項8】
請求項1に記載のシステムにおいて、
前記オペレーションは、
前記データオブジェクトの少なくとも部分的な圧縮後に前記データオブジェクト内のデータにアクセスするための要求を受信すること、
前記データオブジェクトから取得すべきデータの範囲を決定すること、
前記範囲に基づき、前記短縮マップデータ構造を使用して前記データオブジェクトの前記少なくとも部分的な圧縮後に、前記データオブジェクトの一部を読み出すこと、
前記データの範囲を得るために前記データオブジェクトの前記一部の中の圧縮データを解凍すること、及び
前記要求に応答して前記データの範囲を返すこと
を更に含む、システム。
【請求項9】
請求項8に記載のシステムにおいて、
前記マップデータ構造は、前記マップデータ構造内の前記エントリについての参照点としての少なくとも1つのオフセットインジケータを含み、個々のオフセットインジケータは非圧縮状態にある前記データオブジェクト内の個々の位置に関連付けることができ、
前記短縮マップデータ構造を使用して前記データオブジェクトの一部を読み出すことは、
前記要求に対応する、非圧縮形式にある前記データオブジェクト内の位置を決定すること、
前記データオブジェクトの少なくとも部分的な圧縮後に、前記位置を、前記データオブジェクト内の開始位置として前記マップデータ構造内のオフセットインジケータに相関させること、及び
前記開始位置及び前記短縮マップデータ構造内の前記エントリに基づいてデータを読み出すこと
を含む、システム。
【請求項10】
請求項8に記載のシステムにおいて、
前記短縮マップデータ構造を使用して前記データオブジェクトの一部を読み出すことは、
前記要求に対応する、非圧縮形式にある前記データオブジェクト内の位置を決定すること、
前記データオブジェクト内の開始位置を決定するために、前記短縮マップデータ構造内の少なくとも1つのエントリ内で示される少なくとも1つのチャンクの圧縮サイズに基づいて、前記データオブジェクト内の前記位置を前記短縮マップデータ構造内の位置に関係づけること、及び
少なくとも前記開始位置に基づいて前記データオブジェクトのデータを読み出すこと
を含む、システム。
【請求項11】
請求項1に記載のシステムにおいて、
前記オペレーションは、
前記短縮マップデータ構造のサイズが閾値マップサイズ未満になるまで、前記マップデータ構造を複数回短縮することを更に含む、システム。
【請求項12】
請求項1に記載のシステムにおいて、
前記マップデータ構造は、前記複数の圧縮チャンクについての参照点としてのオフセットインジケータを含み、前記オフセットインジケータは、非圧縮状態にある前記データオブジェクト内の位置に関連付けることができ、前記オフセットインジケータは、前記マップデータ構造内の前記オフセットインジケータに先行するエントリに対応する圧縮チャンク及び非圧縮チャンクの合計サイズを示す、システム。
【請求項13】
1又は複数のプロセッサによって実行されると、前記1又は複数のプロセッサを、オペレーションを行うようにプログラムする命令を格納する1又は複数の非一時的コンピュータ可読媒体であって、
前記オペレーションは、
データオブジェクトの複数のデータチャンクを受信すること、
前記複数のデータチャンクを圧縮して複数の圧縮チャンクを得ること、
前記複数の圧縮チャンクの全体が閾値サイズ未満であるか否かを判定すること、
前記複数の圧縮チャンクの全体が前記閾値サイズ未満であると判定されたことに基づいて、前記複数の圧縮チャンクの個々のサイズを、マップデータ構造内の個々のエントリに加えること、
前記個々のエントリの少なくとも2つの中の値を結合することによって前記マップデータ構造を短縮すること、及び
前記複数の圧縮チャンク及
び短縮
された前記マップデータ構造を記憶すること
を含む
、1又は複数の非一時的コンピュータ可読媒体。
【請求項14】
方法であって、
1又は複数のプロセッサによって、データオブジェクトの複数のデータチャンクを受信することと、
前記複数のデータチャンクを圧縮して複数の圧縮チャンクを得ることと、
前記複数の圧縮チャンクの全体が閾値サイズ未満であるか否かを判定することと、
前記複数の圧縮チャンクの全体が前記閾値サイズ未満であると判定したことに基づいて、前記複数の圧縮チャンクの個々のサイズをマップデータ構造内の個々のエントリに加えることと、
前記個々のエントリの少なくとも2つの中の値を結合することによって前記マップデータ構造を短縮することと、
前記複数の圧縮チャンク及
び短縮
された前記マップデータ構造を記憶することと
を含む、方法。
【請求項15】
請求項14に記載の方法において、
前記複数の圧縮チャンク
のための参照点として少なくとも1つのオフセットインジケータを前記マップデータ構造内に含めることであって、前記オフセットインジケータは非圧縮状態にある前記データオブジェクト内の位置に関連付けることができる、ことを更に含み、
前記オフセットインジケータは、前記マップデータ構造内の前記オフセットインジケータに先行するエントリに対応する圧縮チャンク及び非圧縮チャンクの合計サイズを示す、
方法。
【発明の詳細な説明】
【技術分野】
【0001】
本開示は、圧縮データの記憶及び取得の技術分野に関する。
【背景技術】
【0002】
ストレージシステム内に記憶可能なデータ量を増やすために、ストレージシステム内に記憶されるデータが圧縮される場合があり得る。一例として、圧縮データオブジェクトは1つ又は複数のネットワーク記憶位置においてネットワークを介して記憶されることがある。範囲指定読み出しによって記憶データオブジェクトの一部にアクセスすることをユーザが望む場合、要求された部分に先行する全てのオブジェクトデータが典型的にはネットワークストレージから取得され、解凍され得る。例えば従来の技法は、先行するデータの圧縮を決定することなしに特定の要求された部分だけから始まる解凍を可能にしない場合がある。従って、所望の部分に対する解凍及びアクセスを可能にするために、先行データの全てが典型的には解凍され得る。この処理は計算的に非効率であり、時間がかかるものであり得る。
【発明の概要】
【課題を解決するための手段】
【0003】
いくつかの実装形態は、データオブジェクトの複数のデータチャンクを受信してもよいコンピュータシステムを含む。このシステムは複数の圧縮チャンクを得るために複数のデータチャンクを圧縮してもよく、複数の圧縮チャンクの全体が閾値サイズ未満であるか否かを判定してもよい。複数の圧縮チャンクの全体が閾値サイズ未満であると判定したことに基づいて、システムは複数の圧縮チャンクの個々のサイズをマップデータ構造内の個々のエントリに加えてもよい。更にこのシステムは、個々のエントリの少なくとも2つの中の値を結合することによってマップデータ構造を短縮してもよく、複数の圧縮チャンク及び短縮マップデータ構造を記憶してもよい。
【0004】
添付図面を参照して詳細な説明を記載する。図中、参照番号の先頭の数字はその参照番号が初めて登場した図面を識別する。異なる図面内で同じ参照番号を使用することは同様の又は同一のアイテム又は特徴を示す。
【図面の簡単な説明】
【0005】
【
図1】
図1は、いくつかの実装形態に係る圧縮データを記憶し、アクセスすることができるシステムの構造例を示す。
【0006】
【
図2】
図2は、いくつかの実装形態に係るチャンクサイズ及びデータサイズごとのマップサイズを含むデータ構造例を示す。
【0007】
【
図3】
図3は、いくつかの実装形態に係る特殊値オーバーフローの割り振り及びマップ短縮を示すデータ構造例を示す。
【0008】
【
図4】
図4は、いくつかの実装形態に係る割り振りアルゴリズムのオペレーションの例を示す。
【0009】
【
図5】
図5は、いくつかの実装形態に係るマップヘッダのデータ構造及びレイアウト例を示す。
【0010】
【
図6】
図6は、いくつかの実装形態に係るマップのデータ構造の構成例を示す。
【0011】
【
図7】
図7は、いくつかの実装形態に係るマップのデータ構造の構成例を示す。
【0012】
【
図8】
図8は、いくつかの実装形態に係る1回の短縮後のマップのデータ構造の構成例を示す。
【0013】
【
図9】
図9は、いくつかの実装形態に係る圧縮及びマップ生成のための処理例を示す流れ図である。
【0014】
【
図10】
図10は、いくつかの実装形態に係る
図9の処理の続きである処理例を示す流れ図である。
【0015】
【
図11】
図11は、いくつかの実装形態に係るマップに基づく解凍のための処理例を示す流れ図である。
【0016】
【
図12】
図12は、いくつかの実装形態に係る
図11の処理の続きである処理例を示す流れ図である。
【発明を実施するための形態】
【0017】
本明細書のいくつかの実装形態は、圧縮データ及び/又は非圧縮データと混合された圧縮データの高性能の範囲指定読み出しを可能にするための技法及び配置を対象とする。いくつかの事例では、データはクラウド内のストレージに記憶してもよく、或いはネットワークを介してネットワーク記憶位置に記憶されてもよい。いくつかの例では、データ内の圧縮及び非圧縮位置を関連付けるためにマップデータ構造(本明細書では以下「マップ」と呼ぶ)は生成され、保持されてもよい。例えばデータが圧縮されている間、元の非圧縮オブジェクト内の位置を圧縮データ内のオフセットと関連付けるためにマップが生成されてもよい。更に、ユーザ要求等に基づいて、圧縮オブジェクトのオブジェクトデータの或る範囲のアクセスが要求された場合、全圧縮オブジェクトを解凍しなければならないのではなく、要求された範囲の直前のオフセットにおいて解凍を開始できるようにするためにマップを使用してもよい。
【0018】
いくつかの例では、データを(例えば32K、64K、128K、256K等の指定の既定サイズである)チャンクへ分割して圧縮してもよい。例えばチャンクは指定のチャンクサイズを有してもよく、かかるサイズは各圧縮要求に使用される元のオブジェクト内のバイト数に対応してもよい。オブジェクト内の最後のチャンクはオブジェクト内の他のチャンクよりも小さいチャンクサイズを有してもよい。チャンクの圧縮後、チャンクのサイズを表すエントリをチャンクごとにマップに追加してもよい。更に、マップを説明するためにチャンクサイズ等の情報を含むマップヘッダを生成してもよい。マップヘッダはマップよりも前にアクセスしてもよく、いくつかのケースではマップを検索するために使用してもよい。マップ自体がマップヘッダに付加されてもよく、さもなければマップヘッダに続いてもよく、或いはマップが圧縮オブジェクトに付加されてもよい。
【0019】
いくつかのケースでは、マップ全体をメモリ内により上手く収められるようにするため等に、マップをより小さいサイズに短縮してもよい。マップを短縮するために、短縮領域が圧縮データと非圧縮データとの混合を含むことはできない。これを実現するために、ストリーミングデータオブジェクトは、より大きいストリーム集合サイズ(例えば512K)のチャンク(例えば64K)として圧縮されてもよい。チャンクの全集合(本明細書ではいくつかの例において「オペレーション」と呼ぶ)が領域として圧縮不能である場合、集合内の全てのチャンクサイズは、マップ内で「0」の圧縮サイズを有するものとして記録されてもよく、対応するチャンクのどれにも圧縮は使用されない。マップ内の非圧縮チャンクの集合を短縮することは、全ての0サイズのチャンクを加えることによって行われ、これは、依然として圧縮されていない0サイズの短縮チャンクをもたらす。
【0020】
本明細書の実装形態は、圧縮ファイル及び他のデータオブジェクトの最適化された範囲指定読み出し性能を提供する。これらの例は、圧縮位置及び非圧縮位置を関連付けるリレーショナル圧縮マップ、及びマップサイズを最小化するための技術、例えば64Kの圧縮データ当たり2バイトにマップサイズを制限するための技術を含み得る。更に、本明細書の例は、データの初期サイズ及び圧縮率は未知である、ストリーミングファイル及び他のストリーミングデータを圧縮し、及び圧縮が有益である領域に対してのみ圧縮を使用する能力を提供する。
【0021】
更に、本明細書のマップ短縮技術によって、圧縮中に全マップをメモリ内に保持することができ、そのように全マップをメモリ内に保持することはマップが大きくなり過ぎることにより従来のマッピング技術では不可能な場合がある。加えていくつかの例は、マップをメモリ内に保持することができるようにマップが大きくなるときマップを短縮する能力と共に64K等の初期最適チャンクサイズを可能にする。加えて、マップ内の余分なバイトを使用することなしに圧縮可能領域と圧縮不能領域とを短縮中に結合することができる。いくつかの例では、或るデータ領域に対して圧縮が使用されなかったことを示すためにゼロの不可能サイズ又は他の適切なインジケータを使用してもよい。
【0022】
加えて本明細書の例は、チャンクの集合が圧縮可能だが、1又は複数の個々のチャンクが圧縮可能でない場合に提示される課題を克服する。例えば64K又は16M等のチャンクサイズを使用するとき、サイズの増加を含める一切の余地なしに2バイト又は3バイトそれぞれの最適化サイズフィールドが潜在的サイズにちょうど収まる。64K当たり少なくとも2バイト節約して圧縮を使用するように各集合(オペレーション)を指定した後、64K-1(又はより大きいチャンクではその倍数)の特殊圧縮サイズをマップ内で使用して圧縮が利益なしに使用されたことを示すことができる。近隣チャンクを単純に加える短縮を可能にするアルゴリズムを使用し、集合内の近隣チャンクに余分なバイトを加えてもよい。集合が特殊サイズを有する場合、圧縮オブジェクト内の個々のチャンク位置を突き止めることができず、位置を特定することができる集合の境界上で解凍を開始することができる。
【0023】
加えて、いくつかの例は、圧縮不能チャンクが圧縮を回避できるようにするための最適化を含む。例えば各チャンクを圧縮が使用されなかったことを示すための0の圧縮サイズで表すことができる。圧縮を使用するだけの価値をもたせるのにチャンクの圧縮が不十分である場合、圧縮データの代わりに非圧縮データを圧縮オブジェクト内に含めてもよく、圧縮が使用されなかったことを示すためにマップ内の非圧縮データに0を関連付けることができる。
【0024】
更に、いくつかの例は、マップサイズを最小化するためのマップ短縮を含む。例えばマップ内の各エントリは、圧縮チャンクサイズに関連するチャンクサイズ表現であってもよい。圧縮が幾らかの空間を節約すると仮定し、マップ内の各エントリは対応するチャンクのチャンクサイズが十分含まれる大きさであるだけでよい場合がある。従って64K以下のチャンクサイズはチャンクごとにマップ内で2バイトだけ利用すればよい。64Kを上回るが16MBを下回るチャンクサイズでは、チャンクごとにマップ内で3バイトが利用されればよい。更に、16MBを上回るチャンクサイズを有するチャンクの場合、データのチャンクごとにマップ内で4バイトが利用されればよい。
【0025】
加えて、いくつかの例は、周期的なマップ短縮と共にデータのストリーミングを可能にするための最適化を含む。最初に、ストリーミングオブジェクトを圧縮する場合、ストリーミングオブジェクトの完全なサイズがしばしば未知であり得る。ストリーミングデータは圧縮され、ネットワーク記憶位置(いくつかの例ではクラウドストレージとも呼ぶ)内に記憶されてっもよい。マップの作成を効率的に処理するために、圧縮オブジェクトと共にマップがクラウドに書き込まれるまで、マップはメモリ内に保持されてもよく、いくつかの事例ではマップサイズを指定の閾値サイズ未満に保つためにマップを周期的に短縮してもよい。全マップをメモリ内に保持することにより、マップはマップの作成中にハードディスクドライブ又はソリッドステートドライブ等のローカルストレージに書き込み、圧縮データに関連して記憶するために完成したマップをネットワーク記憶位置に送信するために圧縮完了後に再び読み出す必要がない。いくつかの例では、オブジェクトの圧縮完了後、データオブジェクトの圧縮サイズ内にマップを含めることができるように、マップを圧縮オブジェクトに付加してもよい(例えば
図2参照)。
【0026】
非限定的な一例として、チャンク当たり64KBのチャンクサイズを使用する場合、2TBオブジェクトのマップはほぼ62MB利用してもよい。メモリ内にマップを保持しながらそのような大きいオブジェクトの圧縮を処理するために、本明細書のマップは短縮可能であってもよい。マップを短縮することは、隣接エントリを結合してチャンクサイズを2倍にすることによって実現してもよい。例えば、マップエントリによって表されるチャンクサイズがチャンク当たり64KBではなく1MBになるまで、2TBオブジェクト用の62MBマップが短縮されると仮定する。この場合、マップは62MBではなく6MB未満を利用し得る。
【0027】
本明細書の例では、短縮が圧縮チャンクと非圧縮チャンクとの混合をもたらすことは望ましくない。従って、最大短縮時のチャンクサイズはオペレーションサイズとして使用してもよい。例えばオペレーションは全て圧縮を使用する、又は全て圧縮をスキップするチャンクの集合を含んでもよい。従ってシステムは、オペレーションに含まれるチャンクの全てから結果を集めた後で圧縮を使用すべきか否かを判定してもよい。例えば各オペレーションは2のべき乗のチャンクの集合であってもよい。オペレーションを圧縮すべきか否かを判定する前に、オペレーション内の全てのチャンクが圧縮される。オペレーションが圧縮不能である(例えば圧縮が閾値未満の全体的なサイズ低減をもたらす)場合、マップは、圧縮が使用されなかったことを示すためにオペレーション内の全てのチャンクについて0で更新される。オペレーション内の任意のチャンクに圧縮が使用される場合、そのオペレーション内の全てのチャンクに圧縮が使用される。
【0028】
論述目的で、いくつかの実施形態は、1又は複数のネットワーク記憶位置と通信する1又は複数のサービス計算装置、及びデータの圧縮を最適化できる1又は複数のユーザ装置の環境内において説明される。但し、本明細書の実装形態は、提供される特定の例に限定されず、本明細書の開示に照らして当業者に明らかになるように、他の種類の計算システム構造、他の種類のストレージ環境、他の種類のクライアント構成、他の種類のデータ等に拡張されてもよい。
【0029】
図1は、いくつかの実装形態に係る圧縮データを記憶し、アクセスすることができるシステム100の構造例を示す。システム100は、1又は複数のネットワーク106等によって少なくとも1つのストレージシステム104と通信することができる、或いは少なくとも1つのストレージシステム104に接続される1又は複数のサービス計算装置102を含む。更にサービス計算装置102は、以下で更に論じるように様々な種類の計算装置の何れかとすることができる、ユーザ装置108(1)、108(2)、...等の1又は複数のユーザ計算装置108とネットワーク106を介して通信することができる。
【0030】
いくつかの例では、サービス計算装置102は任意の数のやり方で実装され得る1又は複数のサーバを含んでもよい。例えばサービス計算装置102のプログラム、他の機能コンポーネント、及びデータストレージの少なくとも一部は、サーバのクラスタ、サーバファーム、データセンタ、クラウドによってホストされる計算サービス等の中の少なくとも1つのサーバ上に実装されてもよいが、他のコンピュータ構造が追加で又は代替的に使用されてもよい。図示の例では、サービス計算装置102は1又は複数のプロセッサ110、1又は複数のコンピュータ可読媒体112、及び1又は複数の通信インタフェース114を含む、又はそれらに関連づけられていてもよい。
【0031】
各プロセッサ110は単一の処理ユニット又は多数の処理ユニットであってもよく、単一の若しくは複数の計算ユニット又は複数の処理コアを含んでもよい。プロセッサ110は、1又は複数の中央処理装置、マイクロプロセッサ、マイクロコンピュータ、マイクロコントローラ、デジタル信号プロセッサ、ステートマシーン、論理回路、及び/又はオペレーション命令に基づいて信号を操作する任意の装置として実装することができる。一例としてプロセッサ110は、本明細書に記載のアルゴリズム及び処理を実行するように特別にプログラムされ又は構成された任意の適切な種類の1又は複数のハードウェアプロセッサ及び/又は論理回路を含んでもよい。プロセッサ110は、本明細書に記載の機能を実行するようにプロセッサ110をプログラムし得る、コンピュータ可読媒体112内に記憶されるコンピュータ可読命令を取り出し実行するように構してもよい。
【0032】
コンピュータ可読媒体112は、メモリ113及びローカルストレージ115を含んでもよい。例えばメモリ113は、コンピュータ可読命令、データ構造、プログラムモジュール、又は他のデータ等の情報を記憶するための任意の種類の技術によって実装された揮発性メモリ及び不揮発性メモリ、及び/又は取外し可能媒体及び取外し不能媒体を含んでもよい。例えばメモリ113は、これだけに限定されないが、RAM、ROM、EEPROM、フラッシュメモリ又は他のメモリ技術を含んでもよい。更に、ローカルストレージ115及び他のコンピュータ可読媒体112は、光学ストレージ、ソリッドステートストレージ、磁気テープ、磁気ディスクストレージ、RAIDストレージシステム、ストレージアレイ、ネットワーク接続ストレージ、ストレージエリアネットワーク、クラウドストレージ、又は所望の情報を記憶するために使用することができ計算装置によってアクセス可能な他の任意の媒体を含んでもよい。サービス計算装置102の構成にもよるが、言及するとき非一時的コンピュータ可読媒体がエネルギ、搬送波信号、電磁波、及び/又は信号自体等の媒体を除外する限りにおいて、コンピュータ可読媒体112は有形の非一時的媒体を含んでもよい。いくつかの事例では、コンピュータ可読媒体112は、サービス計算装置102と同じ位置にあってもよい一方、他の例ではコンピュータ可読媒体112の一部はサービス計算装置102と部分的に離れていてもよい。例えばいくつかの事例では、コンピュータ可読媒体112はストレージシステム104内のストレージの一部を含んでもよい。
【0033】
コンピュータ可読媒体112は、プロセッサ110によって実行可能な任意の数の機能構成部を記憶するために使用されてもよい。多くの実装形態において、これらの機能構成部は、プロセッサ110によって実行可能であり且つ実行された時に本明細書ではサービス計算装置102によるものとするアクションを実行するようにプロセッサ110をとりわけプログラムする命令又はプログラムを含む。コンピュータ可読媒体112内に記憶される機能構成部はサーバプログラム116及びストレージプログラム118を含んでもよく、それらのそれぞれは1又は複数のコンピュータプログラム、アプリケーション、実行可能コード、又はその一部を含んでもよい。例えばサーバプログラム116は、ユーザ装置108及びストレージシステム104との通信機能を提供してもよい。
【0034】
ストレージプログラム118は、本明細書に記載のデータ圧縮/解凍並びにマップ生成及び管理機能を実行するように構成されてもよい。加えてストレージプログラム118は、サービス計算装置102によって記憶され管理されるデータに関係するメタデータを含むメタデータデータベース(DB)120を作成し管理するためのデータベース管理機能を含んでもよい。例えばストレージプログラム118は、ファイルシステム、オブジェクト情報、データ管理情報、及び他の情報をメタデータデータベース120の一部としてストレージプログラム118に保持させるように構成される実行可能命令を含んでもよい。ストレージプログラム118は、ユーザ情報のようなメタデータデータベース120内に含まれる他の種類の情報を管理するための管理機能を更に実行してもよい。ストレージプログラム118は、保存期間、ストレージの保護レベル、災害復旧のための他のサイトへの記憶データの複製等を管理するため等に、ネットワークストレージシステム104において記憶されるデータのストレージを更に管理してもよい。
【0035】
加えてコンピュータ可読媒体112は、本明細書に記載の機能及びサービスを実行するために使用されるデータ、データ構造、及び他の情報を記憶してもよい。例えばオブジェクトの圧縮中、コンピュータ可読媒体112は圧縮オブジェクト124のマップ122をメモリ113内に記憶してもよく、その一方で圧縮オブジェクトがメモリ113内に記憶するには大き過ぎる場合には、圧縮オブジェクトは、ローカルストレージ115内に記憶されてもよい。加えてコンピュータ可読媒体112は、以下で更に論じるように本明細書に記載の機能の一部を実行するときストレージプログラム118によって使用されるメタデータDB120を記憶してもよい。加えてメモリ113は、データの圧縮中及び/又は解凍中のようにデータの少なくとも一部を一時的に記憶するために使用することができるインジェストバッファ126及び出力バッファ128を含んでもよい。
【0036】
サービス計算装置102はプログラム、ドライバ等及び機能コンポーネントによって使用され又は生成されるデータを含み得る、他の機能コンポーネント及びデータも含み又は保持してもよい。更に、サービス計算装置102は他の多くの論理的、プログラム的、及び物理的なコンポーネントを含んでもよく、そのうち上記で記載したものは本明細書の議論に関係する例に過ぎない。
【0037】
1又は複数の通信インタフェース114は、1又は複数のネットワーク106を介してのように他の様々な装置との通信を可能にするための1又は複数のソフトウェア及びハードウェア構成部を含んでもよい。従って通信インタフェース114は、ストレージシステム104、他のサービス計算装置102、及びユーザ装置108と通信するためのネットワーク106への接続を提供する1又は複数のポートを含む、又は接続するようにしてもよい。例えば通信インタフェース114は、本明細書の他の箇所で更に挙げるように、LAN、インターネット、ケーブルネットワーク、セルラネットワーク、無線ネットワーク(例えばWi-Fi)及び有線ネットワーク(例えばファイバチャネル、光ファイバ、イーサネット)、直接接続、並びにBLUETOOTH(登録商標)等の近距離通信等のうちの1又は複数を介する通信を可能にし得る。
【0038】
1又は複数のネットワーク106は、インターネット等の広域ネットワーク、イントラネット等のローカルエリアネットワーク(LAN)、セルラネットワーク等の無線ネットワーク、Wi-Fi等のローカル無線ネットワーク、及び/又はBLUETOOTH(登録商標)等の短距離無線通信、ファイバチャネル、光ファイバ、イーサネット、又は他の任意のかかるネットワークを含む有線ネットワーク、直接有線接続、又はそれらの任意の組み合わせを含む任意の適切なネットワークを含んでもよい。従って、1又は複数のネットワーク106は有線通信技術及び/又は無線通信技術の両方を含んでもよい。このような通信に使用される構成部はネットワークの種類、選択された環境、又はその両方に少なくとも部分的に依存し得る。そのようなネットワーク上で通信するためのプロトコルはよく知られており、本明細書では詳しくは論じない。従って、サービス計算装置102、ネットワークストレージシステム104、及びユーザ装置108は、有線接続又は無線接続及びその組み合わせを使用して1又は複数のネットワーク106を介して通信することができる。
【0039】
各ユーザ装置108は、デスクトップ、ラップトップ、タブレット計算装置、モバイル装置、スマートフォン、ウェアラブル装置、及び/又はネットワークを介してデータを送信可能な他の任意の種類の計算装置等の任意の適切な種類の計算装置であってもよい。ユーザ130(1)、130(2)、...のそれぞれは、個々のユーザアカウント、ユーザログイン資格情報等を介してユーザ装置108(1)、108(2)、...に関連付けられてもよい。更にユーザ装置108は、1又は複数のネットワーク106を介して、別個のネットワークを介して、又は他の任意の適切な種類の通信接続を介してサービス計算装置102と通信可能であってもよい。本明細書の開示の利益を得る当業者に数多くの他の改変形態が明らかになる。
【0040】
更に、各ユーザ装置108(1)、108(2)、...は、例えばネットワークストレージシステム104上に記憶するためのユーザデータを送信するため及び/又はネットワークストレージシステム104から記憶されたデータを受信するため等のサーバプログラム116と通信するために、個々のユーザ装置108(1)、108(2)、...上で実行され得るユーザアプリケーション136(1)、136(2)、...の個々のインスタンスを含んでもよい。いくつかの事例では、アプリケーション136はブラウザを含んでもよく又はブラウザを介して動作することができてもよく、サーバプログラム116はユーザがサービス計算装置102を介して記憶されたデータにアクセスすることを可能にするためのウェブアプリケーションを含んでもよい。或いは他の事例では、アプリケーション136は、1又は複数のネットワーク106を介してサーバプログラム116との通信を可能にする通信機能を有する他の任意の種類のアプリケーションを含んでもよい。
【0041】
ストレージシステム104は1又は複数のストレージ計算装置140を含んでもよく、ストレージ計算装置140は、サービス計算装置102に関して上記で論じた例の何れかのような1若しくは複数のサーバ又は他の任意の適切な計算装置を含んでもよい。ストレージ計算装置140のそれぞれは、1又は複数のプロセッサ142、1又は複数のコンピュータ可読媒体144、及び1又は複数の通信インタフェース146を含んでもよい。例えばプロセッサ142は、プロセッサ110に関して上記で論じた例の何れかに対応してもよく、コンピュータ可読媒体144はコンピュータ可読媒体112に関して上記で論じた例の何れかに対応してもよく、通信インタフェース146は通信インタフェース114に関して上記で論じた例の何れかに対応してもよい。
【0042】
加えてコンピュータ可読媒体144は、ストレージシステム104内に含まれるストレージ150上のデータの記憶を管理するために1又は複数のプロセッサ142によって実行される機能構成部としてストレージプログラム148を含んでもよい。ストレージ150は、記憶装置156の1又は複数のアレイ154等にデータを記憶するための、ストレージ150に関係付けられた1又は複数のコントローラ152を含んでもよい。例えばコントローラ152は、RAID構成、JBOD構成等でアレイ154を構成するために、及び/又は記憶装置156に基づく論理ユニットをストレージプログラム148に提示するために、及び基礎を成す物理記憶装置156上にクラウドデータ158として記憶されるデータオブジェクト又は他のデータ等のデータを管理するために等、アレイ154を制御してもよい。記憶装置156はハードディスクドライブ、ソリッドステートドライブ、光学ドライブ、磁気テープ、それらのものの組み合わせ等、任意の種類の記憶装置であってもよい。いくつかの例では、ネットワークストレージシステム104は当技術分野で知られている市販のクラウドストレージを含んでもよい一方、他の例では、ネットワークストレージシステム104はサービス計算装置102に関連付けられたエンティティによってのみアクセスできるプライベート又はエンタプライズストレージシステムを含んでもよい。
【0043】
システム100において、ユーザ130はかれらのそれぞれのユーザ装置108が通信しているサービス計算装置102にデータを記憶し、サービス計算装置102からデータを受信し得る。従って、サービス計算装置102はユーザ130及びそれぞれのユーザ装置108にローカルストレージを提供してもよい。定常状態オペレーションの間、サービス計算装置102と周期的に通信するユーザ108があってもよい。
【0044】
いくつかの事例では、サービス計算装置102は、1又は複数のグループ、クラスタ、システム等に構成されてもよい。例えば、いくつかの例(
図1に不図示)では、サービス計算装置102は、第1のサービス計算装置102を第2のサービス計算装置102に、複数のユーザ装置108にストレージ及びデータ管理サービスを提供するための計算ノードをそれらの計算装置が一緒に形成できるように接続されてもよいように、対で配置されてもよい。例えば少なくともメタデータデータベース120を維持することに関して、第1のサービス計算装置102は主計算装置として働いてもよい一方、第2のサービス計算装置102は副計算装置として働いてもよい。加えて又は選択的に、いくつかの例において、複製及び災害復旧を可能にするために、サービス計算装置102を地理的に離れ且つ遠隔の位置にある複数のクラスタに配置してもよい。本明細書の開示の利益を得る当業者に数多くの他の構成が明らかになる。
【0045】
図1の例では、第1のユーザ130(1)はネットワークストレージシステム104において記憶するためにサービス計算装置102に対して160で示すようにデータオブジェクトをストリーミングすると仮定する。ストレージプログラム118は、ストリーミングされたデータオブジェクト160を圧縮するために、サービス計算装置102上で実行されてもよい。オブジェクトがサービス計算装置102にストリーミングされている間、ローカルストレージ115内のディスク上にマップ122を記憶する必要なしに、マップ122は、作成され、メモリ113内に保持されてもよい。一例として、ストレージプログラム118はマップ122を生成するとき、512Kオペレーションにおける64Kチャンク等の既定のチャンクサイズを最初に使用してもよい。そのように既定のチャンクサイズを使用することは、例えばメモリ内に常に収まることが典型的に予期され得る256Kチャンク用の単一設定マップよりもデータ取得中に優れた性能をもたらす。従って既定の構成は、殆どのオブジェクトについてメモリ又はマップサイズ要件が2倍になるだけで4倍の範囲性能を提供しながら、大きいオブジェクトに必要なマップメモリを半分に減らすことができる。様々なオブジェクトサイズ及びチャンクサイズに関連するマップサイズの更なる例を、例えば
図2に関して以下で論じる。更に、これらのパラメータはユーザの要件に基づいてユーザによって最適化されてもよい。
【0046】
オブジェクトがサービス計算装置102へストリーミングされ、サービス計算装置102によって圧縮されることが完了すると、いくつかの例ではマップ122は圧縮オブジェクト124に付加されてもよく、圧縮オブジェクト124及びマップ122はネットワーク106を介してネットワークストレージシステム104に送信されてもよい。ネットワークストレージ104は、圧縮オブジェクト124及びマップ122をストレージ150内に記憶してもよい。加えてマップヘッダ(
図1には不図示)はマップ122のために作成されてもよく、オブジェクト124についての他のメタデータに関連付けてメタデータデータベース120内に記憶されてもよい。更に、この例ではマップ122が圧縮オブジェクト124に付加されてもよいが、他の例ではマップ122は関連付けられた圧縮オブジェクト124から分離してネットワークストレージ104に記憶されてもよい。他の事例では、マップ122は、マップヘッダに付加され、メタデータデータベース120内に記憶されてもよい。
【0047】
更にいくつかの事例では、圧縮オブジェクト124の1又は複数の部分が、圧縮オブジェクト124及び/又はマップ122の1又は複数の他の部分とは別にネットワークストレージシステム104に送信されてもよい。例えばストリーミングされたデータオブジェクト160の一部が圧縮されると、非常に大きいオブジェクトの場合、又は圧縮オブジェクトをローカルストレージ115に記憶し、後で圧縮オブジェクトをローカルストレージ115から読み出すよりも、圧縮オブジェクトをメモリ113から直接送信することが望ましい場合等に、圧縮部分はネットワークストレージシステム104に独立して送信されてもよい。本明細書の開示の利益を得る当業者に数多くの他の改変形態が明らかになる。
【0048】
更に、一例として、ユーザ130(2)が、圧縮オブジェクト124の一部がユーザ装置108(2)に送信されることを要求するデータ要求170を後に送信すると仮定する。ストレージプログラム118はマップヘッダにアクセスし、マップがネットワークストレージシステム104に記憶されていると判定し、マップ122を得てもよい。要求されたデータ部分を得るためにデータの読み出しを開始する非圧縮オブジェクト内の位置を決定することに基づいて、並びにマップ122内のオフセット及び以下で更に論じる他の情報に基づいて、ストレージプログラム118はデータオブジェクトの一部に対するリード要求174をネットワークストレージシステム104に送信してもよい。これに応答し、ネットワークストレージシステム104は、要求されたデータ部分をサービス計算装置102に送信してもよい。ストレージプログラム118は、要求されたデータ部分の1又は複数の部分を解凍してもよく、非圧縮データ部分178によってデータ要求170に応答してもよい。
【0049】
図2は、いくつかの実装形態に係るチャンクサイズ及びデータサイズごとのマップサイズを含むデータ構造200の例を示す。この例のデータ構造200は、チャンクサイズ及びデータサイズ(例えばオブジェクトサイズ)ごとのマップサイズを示し、1024エントリオフセット頻度によってシリアル化されている。例えばオフセット頻度はマップ内の絶対オフセット間で生じるマップエントリの数(圧縮サイズ)を示してもよい。絶対オフセットは、関連するマップエントリが適用されるチャンクが存在する圧縮オブジェクト内へのオフセットを含んでもよい。加えて、圧縮サイズエントリはマップ内で表される単一チャンクの圧縮サイズを含んでもよい。いくつかの事例では、圧縮サイズエントリは、圧縮が使用されなかったことを示すために0としてもよく、又はオペレーションに関する全ての圧縮サイズエントリが未知であることを示すために特殊値としてもよい。
【0050】
図示の例では、データ構造200は、10KBから2,000,000,000KBまでのデータサイズの範囲を列挙するデータサイズカラム502を含む。このデータ構造は、チャンクサイズ32KB、64KB、128KB、256KB、512KB、1024KB、及び2048KBそれぞれのマップサイズを列挙する7個のマップサイズカラム504、506、508、512、514及び516と、カラム502内に列挙される対応するデータサイズとを更に含む。例えばデータサイズが100,000KBであり、チャンクサイズが64KBである場合、マップサイズは3134バイトである。
【0051】
本明細書のいくつかの例では、全オペレーション(例えば一連のチャンク群)が圧縮されていても、圧縮されていなくてもよい。オペレーションの圧縮率はオペレーション内の全チャンクに関する総空間節約によって決定することができる。例えば圧縮が少なくとも閾値を達成しない場合、全オペエーションを圧縮しないままにしておいてもよい。
【0052】
他方で、オペレーション内の1又は複数の個々のチャンクが圧縮可能でない可能性がある、又は最小限に圧縮可能である場合であっても、全オペレーションに関する圧縮の閾値レベルを達成するのにオペレーション内の他のチャンクが十分圧縮可能である場合は全オペレーションを依然として圧縮することができる。この状況では、最適なマップエントリサイズが非圧縮チャンクと合わない問題があり得る。例えば64K-1は、マップ内の64KBサイズのチャンクに使用される最適エントリサイズである2バイト内に収めることができる最大数である。これを扱うために、64K-1の特殊サイズを、実際の圧縮サイズが少なくとも64K-1であることを示すために使用されてもよい。
【0053】
短縮がエントリを正しく結合することを保証する、以下で更に論じる割り振りアルゴリズムを使用し、オペレーション内の他の圧縮サイズエントリに余分なバイトを割り振ってもよい。これがオペレーション内の少なくとも1つのチャンクに生じる場合、オペレーション内の他のチャンクのサイズエントリが正しくない可能性がある。但し、合計圧縮オペレーションサイズは依然としてオペレーション内の圧縮チャンクサイズエントリの和である。この事例では、オペレーションの任意のマップエントリが特殊サイズであるとき、解凍はオペレーション内の最初のチャンクでのみ整列されてもよい。それに該当する場合、所望の範囲の開始に達する前に、解凍データの全チャンクを破棄する必要があり得る。
【0054】
マップの短縮を通して特殊サイズは維持されるので、短縮ごとに値が2倍になり得る。特殊サイズは、エントリサイズが64Kチャンクについての2バイト及び16MBチャンクについての3バイト等の最適である場合にのみ必要とされるが、この状況では、特殊サイズが短縮を通して維持される。別の例として、16MBのチャンクサイズを有するマップに特殊サイズが使用される場合、特殊サイズは16MBチャンクについて16MB-256になる。或る非限定的な例として、オペレーションを圧縮可能だと考えるのに必要とされる平均最小空間節約閾値は、チャンクサイズ又はオペレーションサイズに関係なく64K当たり2バイトであり得る。それよりも高い圧縮率を構成することはできるが、それよりも低い圧縮率は構成できない。更に、読み出し中にオペレーションサイズが分かり得るので、以下で更に論じるようにマップヘッダ内にオペレーションサイズの値を含めることができる。
【0055】
図3は、いくつかの実装形態に係る特殊値オーバーフローの割り振り及びマップ短縮を示すデータ構造300例を示す。データ構造300は、チャンクサイズ302、圧縮サイズ(実際のサイズ)304、(2バイトのエントリでの)マップ内圧縮サイズ306、1回短縮後のマップ内圧縮サイズ(3バイトエントリ)308、及び2回短縮後のマップ内圧縮サイズ(3バイトエントリ)を含む。
図3では、302に示すようにチャンクサイズは64Kである。更に、圧縮された実際のサイズが304に示されており、(マップ内のカラム306で圧縮サイズについて「0」で示すように)最初の4つのエントリが圧縮されていないことが示されている。
【0056】
この例では、最初の4つのエントリは圧縮されなかった第1のオペレーションであり、第2のオペレーションはロウ312で開始し、複数の特殊値を含み、第3のオペレーションは320で開始し、同じく複数の特殊値を含むと仮定する。具体的には、ロウ312、316、318、322、及び326では、カラム304内で示す圧縮された実際のサイズが64Kを上回る。従って、ロウ312、316、318、322、及び326のカラム306内の値のそれぞれが64K-1、即ち65535に等しいように余分なビットを引いて再割り振りさせる。例えば余分な6バイト(312、316、及び318からそれぞれ2)をロウ314内の値に加え、カラム304の500の値をカラム306の506に増やす。同様に(322から)2バイトをロウ320内の1000の値に加え、(326から)3バイトをロウ324内の値に加える。従って、カラム306内の特殊値を作成するために追加のバイトが他の圧縮チャンク値の間で割り振られる。
【0057】
上記で述べたように、特定のチャンクは圧縮可能オペレーションの最中に圧縮不能であり得る。マップサイズを最小化することによって圧縮を最適化するために、マップ内の圧縮サイズエントリは最小数のバイトを利用してもよい。64Kチャンクの場合のようにエントリに使用されるバイト数がチャンクサイズに辛うじて収まる場合、チャンクが圧縮可能でない限り圧縮サイズはエントリ内に収まらない。0から65535(64K-1)までの数を表すために2バイト(64Kチャンクのマップエントリサイズ)が使用可能である。64K以上は2バイトでは表せない。従って本明細書の実装形態では、そのようなオペレーションに圧縮を使用するために、特殊サイズは実際の圧縮サイズが未知であることを示すためにマップエントリ内で使用されてもよい。
【0058】
オペレーション全体(即ちチャンク群)が圧縮可能だが、1又は複数のチャンクが圧縮不能である場合、圧縮不能チャンク用の特殊サイズからのオーバーフローは、オペレーションのための他のマップエントリの間で割り振られてもよい。このことは圧縮オペレーションサイズを正しく保ち、オペレーションレベルでのナビゲーションを可能にする。例えばマップを短縮できない場合、より小さい圧縮サイズを有する他の任意のチャンクに余分なバイトを割り振ることで十分である。但し、マップは後で短縮され得るので、オーバーフローは後の短縮中に結合される方法と真逆に割り振らせることができる。特殊サイズを有するオペレーションの短縮中、オペレーション内のチャンクの実際の圧縮サイズを決定することはできない。このことは、短縮は隣接する対を結合するほど簡単なものであってもよい。隣接結合エントリの何れも特殊サイズではない場合、結果は特殊サイズにならず、結合エントリは対応する結合チャンクの圧縮サイズを表すことができる。全ての圧縮サイズが依然として知られている間の原割り振りは、マップエントリがどのように結合されているのかの方法を説明し得る。(64K-1)*2^nの特殊サイズであって、nは64Kのチャンクサイズを超える短縮の数である、特殊サイズを使用することにより、特殊サイズに隣接する64Kのチャンクサイズを結合することによる短縮チャンクサイズを特殊サイズと結合して、短縮マップのための正しいエントリ内に特殊サイズを生成することができる。
【0059】
カラム308に示すように、第1の短縮の間、最初の4つのエントリは、「0」の値を有する結果として生じる2つのエントリを得るように結合されてもよい。更に、ロウ312及び314における306内の値が結合される場合、カラム308内の結果は65535+506(対として今なお圧縮不能なロウ316及び318から4バイトは依然として残っている)の66041である。加えてロウ316及び318において、2つの特殊サイズが結合されて新たな特殊サイズ131070となる。ロウ312及び314と同様のやり方でロウ320及び322が結合され、ロウ324及び326も同様に結合される。第2の短縮の間、カラム310内に示すように、カラム310内の値に到達するようにマップをさらに短縮化するために、隣接する対を結合することによりカラム308内の値を同様に結合してもよい。
【0060】
将来の全ての短縮が圧縮サイズの完全性を保つように特殊サイズからのオーバーフローが割り振られることを保証するために、以下に記載するような割り振りアルゴリズムを使用してオーバーフローを割り振らせることができる。割り振りアルゴリズムは、オペレーションに関する実際の圧縮サイズのアレイ、サイズ超過エントリの位置、64K-1等の特殊サイズ値、オペレーションのべき乗(2のべき乗としてのオペレーション当たりのチャンク)、及び最終オペレーション上のオペレーション当たりのチャンクを上回ることができないチャンクカウントによって機能してもよい。オーバーフローの候補は1から開始してオペレーションのべき乗に進み、2のべき乗のチャンクを調査することによって決定することができる。調査するためのアレイ内の開始エントリは、サイズ超過エントリの位置を2進値として表し、現在の2のべき乗の下位ビットをゼロで埋めることによって決定してもよい。順番に、これを、調査の開始を2^現在のべき乗エントリの先頭に置き、それらのエントリは将来の潜在的な短縮数(べき乗)によって結合され得る。これらのエントリは、オーバーフローが完全に振り分けられるまで、特殊サイズを上回ることなしにオーバーフローを含むように調節される。
【0061】
図3の例では、第2のオペレーション(ロウ312~318)及び第3のオペレーション(ロウ320~326)は、2バイトの圧縮サイズエントリ内に割り振るために本明細書の割り振りアルゴリズムを使用した結果の例を示す。割り振りアルゴリズムの疑似コードの一例は以下を含む:
【0062】
discrepancy=operationMap[pos]-special;
【0063】
for(int power=1;power<=operationPower;++power){
【0064】
int start=(pos>>power)<<power;
【0065】
for(int i=start;i<start+(1<<power)&&i<chunkCount;++i){
【0066】
if(operationMap[i]<special){
【0067】
int extraSpace=min(discrepancy,special-operationMap[i]);
【0068】
operationMap[i]+=extraSpace;
【0069】
discrepancy-=extraSpace;
【0070】
if(discrepancy==0){
【0071】
return;
【0072】
} } } }
【0073】
図4は、いくつかの実装形態に係る割り振りアルゴリズムのオペレーションの例を示す。上記の割り振りアルゴリズムでは、割り振りアルゴリズムは、特殊サイズから他のチャンク表現(オペレーションエントリ)にオーバーフローを割り振るための1又は複数のパスを作成するために実行されてもよい。例えば第1の例401は、オペレーションエントリ402、第1パス404、第2パス406、及び第3パス408を含む。例えば410に示すように、オペレーションエントリ402は圧縮不能エントリを含む。割り振りアルゴリズムは、同じオペレーション412内の直接隣接するエントリを検査するための第1パス404を作成するために実行されてもよい。次に、第1パスがオーバーフローの割り振りをもたらさない場合、割り振りアルゴリズムは、同じオペレーション412内の他のエントリを検査するための第2パス406を作成するために実行されてもよい。次に、第2パスがオーバーフローの割り振りをもたらさない場合、割り振りアルゴリズムは、隣接するオペレーション414内の他のエントリを検査するために実行されてもよい。割り振りアルゴリズムは、オーバーフローが割り振られるまで続行されてもよい。
【0074】
同様に例420では、422で示すようにオペレーションエントリ402は圧縮不能エントリを含む。割り振りアルゴリズムは、同じオペレーション422内の直接隣接するエントリを検査するための第1パス404を作成するために実行されてもよい。次に、第1パスがオーバーフローの割り振りをもたらさない場合、割り振りアルゴリズムは、同じオペレーション422内の他のエントリを検査するための第2パス406を作成するために実行されてもよい。次に、第2パスがオーバーフローの割り振りをもたらさない場合、割り振りアルゴリズムは、隣接するオペレーション424内の他のエントリを分散アルゴリズムが検査してもよい。割り振りアルゴリズムは、オーバーフローが割り振られるまで続行されてもよい。
【0075】
図5は、いくつかの実装形態に係るマップヘッダ500のデータ構造及びレイアウト例を示す。マップに関する詳細は2バイト、即ち第1バイト502及び第2バイト504に収めることができる。例えばチャンクサイズ、(オペレーション当たりのチャンクとして表される)オペレーションサイズ、及びオフセット頻度に加えて、読み出し性能を改善するため、取り込み中に記録される更なる詳細がマップヘッダ内に含められてもよい。従って第1バイト502は、予約ビット506、特殊値インジケータ508(1ビット)、マップ状態510(2ビット)、及び2のべき乗引く10としてのチャンクサイズ512(4ビット)を含んでもよい。第2バイト504は、2のべき乗としてのオペレーション当たりのチャンク514(2ビット)、及び2のべき乗としてのオフセット頻度516(4ビット)を含んでもよい。
【0076】
特殊値インジケータ508は、マップ内で任意の特殊値が使用されているか否かを示してもよい。特殊値が使用されていない場合、64K-1のようなエントリは、実際の圧縮サイズを意味し、オペレーションの開始においてではなく計算されたチャンク上で解凍を開始することができる。一例として「0」は特殊値がないことを示してもよく、64K-1は実サイズとして扱うことができる一方、「1」は少なくとも1つの特殊値が使用されたこと(その逆も同様)を示してもよい。
【0077】
マップ状態510は、実際にマップがあるのか否か、マップがヘッダ又は圧縮オブジェクトに続くか否か、及びマップが任意の非圧縮チャンクを含むか否かを示してもよい。オブジェクトが圧縮されないためにチャンクのいずれもが圧縮されていない場合は、マップヘッダがないことがあり、従ってマップは不要である。加えて、全てのチャンクが圧縮され、このサイズオブジェクトについて範囲要求が予期されない場合は、マップは指定されない。或いはマップがインラインとして指定され、マップがヘッダに続く場合、マップを得るための追加のクラウド読み出しをなくしてもよい。加えて、マップ内の全てのチャンクが圧縮されている場合、0の位置からの読み出しはマップを必要としない。一例として「0」はマップなしを示してもよく、「1」はマップがインラインであること(マップコンテンツが圧縮オブジェクトではなくヘッダに続くこと)を示してもよく、「2」は、マップは外部にあり全てのチャンクが圧縮されることを示してもよく、「3」は、マップは外部にありいくつかのチャンクは圧縮されないことを示してもよい。
【0078】
((2のべき乗)-10)として表されるチャンクサイズ(4ビット)(1KB-32MBのチャンクサイズ)512は、マップによって表されるチャンクのチャンクサイズを示してもよい。この例ではヘッダ内の値が、16-10に等しい「6」である。その結果、16が2のべき乗であり、チャンクサイズは64Kである。
【0079】
2のべき乗として表されるオペレーション当たりのチャンク514は、既定値としてもよく又はユーザによって指定されてもよい。更に、2のべき乗として表されるチャンク当たりのオフセット頻度(4ビット)516も、マップ内の絶対オフセット間で生じるマップエントリの数(圧縮サイズ)を示す既定値であってもよい。
【0080】
上記で論じたデータ構造300から拡張した設定例に基づいて、チャンクサイズ=64K、オペレーションサイズ=256K(4チャンク)、及び絶対オフセット頻度=8である。更にマップは特殊値を含み、いくつかのチャンクは圧縮されていない。
【0081】
加えて、ヘッダ500は、範囲要求を満たすための部分的なマップ読み出しを可能にする最適化を含んでもよい。例えば大きいオブジェクトのマップのサイズは数メガバイトであり得るので、狭い範囲のために全マップを読み出すことはコストが多大になり過ぎる場合がある。この問題に対処するために、圧縮オブジェクト内への絶対オフセットは、所定のオフセット頻度に基づいてマップ内に配置されてもよい。この頻度は最終的なチャンク数に基づいており、チャンクサイズ又はマップの短縮の有無の影響を受けなくてもよい。オフセット頻度は、圧縮オブジェクト内の範囲の位置を決定するためにアクセス可能なマップ内の独立した固定サイズのセグメントを作成する。マップセグメントは、第1のチャンクのための圧縮オブジェクト内への8バイトの絶対オフセットと、その後に続くその後の(オフセット頻度)チャンクのための圧縮サイズエントリとを含んでもよい。従ってオフセット頻度516は、マップを解析することができるように、マップヘッダ500内に含まれてもよい。
【0082】
図6は、いくつかの実装形態に係るマップ600のデータ構造の構成例を示す。マップ600は、オペレーション当たりの圧縮チャンクサイズ表現の数を示すオペレーションサイズインジケーション602を含み、圧縮チャンクサイズ表現604及び圧縮オブジェクト内への周期的な絶対オフセット606の一覧を更に含む。例えば、圧縮チャンクサイズ表現に使用されるバイト数は、チャンクサイズに基づいて最小かされ、例えばチャンクサイズが64Kを上回らない限り2バイトに、64Kを上回る場合は圧縮チャンクサイズ表現604に3バイト608を使用してもよい。上記で述べたように、圧縮サイズ表現は、対応するチャンクの実際の圧縮サイズであってもよく、圧縮が使用されなかったことを示すために「0」であってもよく、又はオペレーション内のエントリの和が圧縮オペレーションサイズであるが個々のチャンクの圧縮サイズが未知であることを示すために特殊値としてもよい。
【0083】
絶対オフセット606は、前回の絶対オフセット606以降の全ての圧縮及び非圧縮チャンクサイズの和である。絶対オフセット606は8バイト608であってもよく、単に先行するチャンクのエントリの和ではない。例えば絶対オフセットを計算するとき、圧縮オブジェクト内のその後のエントリに関連するチャンクの位置を特定するために絶対オフセット606を使用することができるように、任意の0は、対応するチャンクの非圧縮チャンクサイズで置換される。最大オブジェクトサイズが256TB未満である場合、絶対オフセット606に使用される8バイトのうちの2バイトは、絶対オフセットを示すためにハードコードされてもよい。
【0084】
従ってマップ内で、非圧縮チャンクサイズが<=64kである場合は圧縮チャンクサイズは2バイトで表され、又はチャンクサイズが>64k&<=16Mである場合は圧縮チャンクサイズは3バイトで表され、チャンクサイズが>16Mである場合は圧縮チャンクサイズは4バイトで表される。更に、それぞれのオペレーション(チャンク群)について各チャンクがチャンクのサイズ未満に圧縮される場合、圧縮チャンクのサイズがマップに追加される。全てのチャンクが圧縮されない場合、表現としてゼロが使用されてもよい。それ以外は、オペレーションサイズの合計がオペレーションの圧縮サイズに等しくてもよいが、オペレーション内に含まれる表現される個々のチャンクは対応するチャンクの圧縮サイズを必ずしも示さない。
【0085】
本明細書のマップは、ユーザのニーズに最も上手く適合するように好みに基づいてユーザによって設定されてもよい。ユーザが非常に狭い範囲に対する高速アクセスを必要とする場合、マップは1KB等の小さいチャンクサイズで開始することができる。2バイトのエントリを有する最適化マップが未決定の作業負荷の目標である場合、64KBの初期チャンクサイズを使用することができる。メモリの可用性が小さい又は非常に大きいオブジェクトに対するアクセス速度がさほど重要でない場合、4MB等の大きいオペレーションサイズを使用することができる。マップを読み出す時間よりも圧縮比の方が重要である場合、32768等の高いオフセット頻度を使用することができる。短縮のガイドラインも構成することができる。取り込み中にマップの短縮を試みるときに、マップメモリフットプリントを特定してもよい。結果として生じるより小さなマップが効率を高め得る場合、完了後にマップ短縮を試みるべきかどうか及び何回試みるべきかを指定することもできる。構成の選択肢はチャンクサイズ、オペレーションサイズ、オフセット頻度、最大マップメモリ、及び短縮の価値があるマップサイズ目標を含む。オペレーションサイズはチャンクサイズの2のべき乗倍としてもよい。オフセット頻度はオペレーション当たりのチャンクの倍数としてもよい。更に
図6にはマップのデータ構造の構成例が示荒れているが、同じ機能を実行するために考えられる他の多数のデータ構造の構成が本開示の利益を得る当業者に明らかになる。
【0086】
図7は、いくつかの実装形態に係るマップ700のデータ構造の構成例を示す。この例では、マップ700はチャンクごとの個々のチャンクサイズ表現702、及び説明目的の記述704を含む。例えばロウ706~712のチャンクサイズ表現は非圧縮であり、従ってロウ706~712についてチャンクサイズ表現に割り当てられる値は「0」である。更に、ロウ714、718、720、726、及び730は特殊サイズエントリを有する一方、ロウ716、724、及び728は個々のチャンクに特殊サイズからの幾らかのオーバーフローを加えたサイズを含む。さらにロウ732~738及び742~746は通常の圧縮データを有するのに対し、ロウ722及び740は絶対オフセットとして役割を果たす。
【0087】
この例では、チャンクサイズ=64K、オペレーションサイズ=256K(4チャンク)、及び絶対オフセット頻度=8であると仮定する。従ってマップ700は、チャンクサイズ表現706~712を含む第1オペレーション750、チャンクサイズ表現714~716を含む第2オペレーション752、チャンクサイズ表現724~730を含む第3オペレーション754、チャンクサイズ表現732~738を含む第4オペレーション756、及びチャンクサイズ表現742~746を含む第5オペレーション758との5つのオペレーションを含む。
【0088】
図8は、いくつかの実装形態に係る1回の短縮後のマップ800のデータ構造の構成例を示す。この例では、1回の短縮後にチャンクサイズ=128K(3バイトサイズのエントリ)であり、絶対オフセット頻度=8のままである。更に短縮は、
図7のマップ700からの2つのチャンクサイズの結合をそれぞれ表す、オペレーション当たり2つのチャンクサイズ表現をもたらしている。例えば、第1オペレーション750は4つのチャンクサイズ表現から2つのチャンクサイズ表現802及び804に短縮され、第2オペレーション752は4つのチャンクサイズ表現から2つのチャンクサイズ表現806及び808に短縮され、第3オペレーション754は4つのチャンクサイズ表現から2つのチャンクサイズ表現810及び812に短縮され、第4オペレーション756は4つのチャンクサイズ表現から2つのチャンクサイズ表現814及び816に短縮され、第5オペレーション758は3つのチャンクサイズ表現から2つのチャンクサイズ表現820及び746に短縮されている。第5オペレーション758内には奇数のチャンクサイズ表現があるので、この例における最後のチャンクサイズ表現746は短縮中に別のチャンクサイズ表現と結合されておらず、従って短縮前と同じ値を保っている。
【0089】
短縮の結果として、第1オペレーション750内の802及び804のチャンクサイズ表現の値は、短縮中に「0」を結合することに基づいてどちらも「0」である。第2オペレーション752は、806におけるオーバーフロー値を有するサイズ、及び808における特殊サイズを含む。絶対オフセット818におけるオペレーション750、752、754、及び756の全体値は、圧縮マップ800内で782330であり、これは、
図7のマップ700内の絶対オフセット740の値と同じである。
【0090】
図9~
図12は、いくつかの実装形態に係る処理の例を示す流れ図である。これらの処理は論理流れ図のブロックの集まりとして示してあり、それらのブロックはその一部又は全てをハードウェア、ソフトウェア、又はそれらの組み合わせによって実装し得る一連のオペレーションを表す。ソフトウェアの脈絡では、ブロックは、1又は複数のプロセッサによって実行されるとき、列挙したオペレーションを実行するようにプロセッサをプログラムする1又は複数のコンピュータ可読媒体に記憶されるコンピュータ実行可能命令を表してもよい。典型的にはコンピュータ実行可能命令は、特定の機能を実行し又は特定のデータ型を実装するルーチン、プログラム、オブジェクト、コンポーネント、データ構造等を含む。ブロックが記載される順序は限定として解釈すべきではない。記載されるブロックの任意の個数は、任意の順序で及び/又は並列に組み合わせてこの処理又は代替的処理を実施することができ、ブロックの全てを実行しなければならない訳ではない。本明細書の例の中で記載した環境、枠組み、及びシステムに関して処理を論述目的で説明したが、これらの処理は多岐にわたる他の環境、枠組み、及びシステム内で実装されてもよい。
【0091】
図9は、いくつかの実装形態に係る圧縮及びマップ生成のための処理900の一例を示す流れ図である。いくつかの事例では、処理900はサービス計算装置又は他の適切な計算装置によって少なくとも部分的に実行されてもよい。一例として、
図1に関して上記で論じたサービス計算装置102の1又は複数のプロセッサ110によって実行されるストレージプログラムは、
図9の処理900の少なくとも一部を実行するための実行可能命令を含んでもよい。
【0092】
データはチャンクごとに圧縮されるが、結果は圧縮について決定されてもよく、マップは、複数のチャンクのオペレーションに基づいて作成されてもよい。オペレーション内の各チャンクは圧縮され、メモリ内のマップの中に結果が記憶される。オペレーションに対する圧縮が有用でない場合は圧縮が使用されず、全ての圧縮チャンクサイズがマップ内で「0」にラベル付けされる。これに代えて、圧縮がオペレーション全体について有用だが(例えばオペレーションを圧縮することによって圧縮の閾値レベルが達成される)、オペレーション内の1又は複数のチャンクの圧縮がそうではない場合、圧縮サイズは圧縮チャンクサイズフィールド内に収まらず、その1又は複数のチャンクについてマップエントリ内に特殊サイズ、例えば2バイトフィールドチャンク表現の場合は[64K-1]又は3バイトフィールドチャンク表現の場合は[16M-256]が入力される。更にオーバーフローサイズ(例えば圧縮サイズの量が特殊サイズを上回る場合)は、特殊サイズチャンク表現を一緒に短縮することができ、十分な空きを有する近隣チャンク表現に割り振られてもよい。
【0093】
他の事例では、オペレーションの圧縮が有用であり、圧縮チャンクサイズがチャンクサイズ表現のマップエントリ内に収まる場合、チャンクサイズ表現は、実際の圧縮サイズとしてラベル付けされる。マップは集合間で、又は一部の事例ではデータの圧縮完了後に短縮されてもよい。全てのオペレーションが完了した後にマップヘッダは完成され保存される。いくつかの事例では、マップヘッダはマップに付加されてもよく、又は離れて保たれてもよい。更に、一部の例では、マップは圧縮オブジェクトに付加されてもよく、又は他の例では離れて記憶されてもよい。非圧縮オブジェクトサイズ及び圧縮オブジェクトサイズは今では知られ、記録されてもよい。
【0094】
902で、データオブジェクトの圧縮を開始する前に、計算装置は構成変数、例えばチャンクサイズ、オペレーションサイズ、絶対オフセット頻度、最大マップメモリサイズ、データベース内の最大マップサイズを受信し、及び/又は割り当ててもよい。いくつかの例では、これらのパラメータの既定値は、サービス計算装置によって行われる圧縮オペレーションを管理する管理者又は他のユーザ等のユーザによって既に確立されていてもよい。この例のために、チャンクサイズ=64K、オペレーションサイズ=512K(8チャンク)、絶対オフセット頻度が1024エントリであり、最大マップメモリ=1M、及びDB内の最大マップ=300バイトだと仮定する。これらの値は論述目的に過ぎず、本明細書の実装形態はこれらのパラメータの或る特定の値に限定されない。
【0095】
904で、計算装置は圧縮用のデータを受信し、受信したデータの少なくとも一部を、例えばデータのオペレーションサイズまでインジェストバッファ内に記憶するようにしてもよい。いくつかの例では、データはネットワークを介してストリーミングデータとして受信されてもよく、他の事例ではデータは記憶位置等から読み出されてもよい。
【0096】
906で、計算装置は、出力バッファ内に受信したデータのチャンクサイズまで圧縮してもよく、一時的なオペレーションの集合内にチャンクの圧縮サイズを記憶してもよい。
【0097】
908で、計算装置はインジェストバッファ内に更にデータがあるか否かを判定してもよい。例えば、オペレーション分のデータ(例えば上記の902で述べた指定のオペレーションサイズ(512K)に対応するこの例の8チャンクサイズの量)がインジェストバッファに追加される場合、計算装置はインジェストバッファが空になるまでインジェストバッファ内のデータの個々のチャンクに対して操作してもよい。インジェストバッファが空の場合、オペレーション分のデータが処理されており、計算装置は圧縮の閾値レベルがオペレーションについて満たされているか否かを判定してもよい。インジェストバッファ内にデータが依然としてある場合、この処理は906に戻る。それ以外の場合には、この処理は910に進む。
【0098】
910で、計算装置は、オペレーション内のチャンクの集合を、チャンクサイズから1を引いた値とオペレーション内のチャンク数とを掛けた値未満に圧縮するか否かを判定してもよい。例えばこの例の圧縮閾値の特定値は(64K-1)・8である。オペレーションが閾値未満に圧縮する場合、この処理は912に進む。そうでなければ、この処理は914に進む。
【0099】
912で、圧縮閾値が満たされる場合、計算装置は圧縮サイズの集合を更新してもよく、64Kを上回る値を64K-1に等しい値に低減し、例えば
図3及び
図4に関して上記で論じたようにオーバーフロー(差)を別のチャンクサイズ表現エントリに加えてもよい。更に計算装置はマップ内のメモリ内チャンクサイズリストに値を移してもよく、既に処理されているいずれかのオブジェクトデータに出力バッファ内の圧縮データを付加してもよい。
【0100】
914では、他方で、圧縮閾値が満たされない場合、計算装置はマップ内のメモリ内チャンクサイズリストに全て0を保存してもよく、既に処理されているいずれかのオブジェクトデータにインジェストバッファのデータを付加してもよい。
【0101】
916で、計算装置は、インジェストバッファ内に取り込むための更なるデータがあるか否かを判定してもよい。該当する場合、この処理は918に進む。該当しない場合、この処理は922に進む。
【0102】
918で、インジェストバッファ内に取り込むための更なるデータがある場合、計算装置はチャンクサイズリストが1MBを上回るか否かを判定することにより、既存のマップを短縮することが望ましいか否かを判定してもよい。例えば上記の902で、最大マップメモリは1MBに指定されている。従って、この時点でマップサイズがこの量を上回る場合は、マップは短縮されてもよい。上回らない場合、この処理は904に戻って更なるデータをインジェストバッファに追加する。
【0103】
920で、マップサイズが指定された閾値量(例えばこの例では1MB)を上回る場合、計算装置は、近隣の対を結合し、チャンクサイズを2倍にすることによって、マップ内のチャンクサイズリストを短縮してもよい。このオペレーションが可能である(例えばチャンクサイズが依然としてオペレーションサイズ未満である)場合、構成情報内で指定された1MB未満にマップサイズを低減するのに1回の短縮で十分だと予期される。マップの短縮後、この処理は904に戻って更なるデータをインジェストバッファに追加する。
【0104】
922で、インジェストバッファに追加するデータがこれ以上ない場合、このことはデータオブジェクトの圧縮が完了したことを示し、計算装置はマップを最大DBサイズに短縮され得るか否かを判定してもよい。該当する場合、この処理は924に進む。該当しない場合、この処理は
図10の処理に進む。
【0105】
924で、計算装置はマップサイズが最大マップDBサイズ未満になるまで、例えばこの例では300バイト未満になるまで、近隣の対を結合し、チャンクサイズを2倍にすることによって、マップ内のチャンクサイズリストを短縮してもよい。マップの短縮後、この処理は
図10の処理に進む。
【0106】
図10は、いくつかの実装形態に係る
図9の処理900の続きである処理1000の一例を示す流れ図である。
【0107】
1002で、計算装置はチャンクサイズ、オペレーションサイズ、オフセット頻度、及び
図5に関して上記で論じた他のパラメータを有するマップのマップヘッダを完成してもよく、
図1に関して上記で論じたメタデータデータベース120等のデータベース内に少なくともマップヘッダを記憶してもよい。いくつかの事例ではマップもデータベース内に記憶してもよく、及び/又はマップは、ネットワークストレージで記憶するためにオブジェクトに付加されてもよい。
【0108】
1004で、計算装置はマップサイズリストが300バイト、例えば最大DBサイズ未満であるか否かを判定してもよい。該当しない場合、この処理は1006に進む。該当する場合、この処理は1014に進む。
【0109】
1006で、計算装置は圧縮オブジェクトをサイズリストエントリに付加し、絶対オフセットにおける合計サイズが正確であるように、0の代わりに最終チャンクサイズを使用してサイズを累積合計に加えてもよい。
【0110】
1008で、計算装置はマップ内に更にエントリがあるか否かを判定してもよい。該当する場合、この処理は1010に進む。該当しない場合、この処理は1016に進む。
【0111】
1010で、計算装置は追加のエントリがオフセット頻度にあるか否かを判定してもよい。該当する場合、この処理は1012に進む。該当しない場合、この処理は1006に進む。
【0112】
1012で、計算装置は圧縮オブジェクト、サイズリストエントリの累積合計を付加してもよく、1006に戻る。
【0113】
1014で、マップサイズリストがデータベースの最大閾値、例えばこの例では300バイト未満、である場合、計算装置はマップとしてメタデータデータベース内のマップヘッダをサイズリストに付加してもよい。
【0114】
1016で、計算装置は圧縮オブジェクト(及び圧縮オブジェクトに付加される場合はマップ)を記憶するために記憶位置に送信してもよい。例えば
図1に関して上記で論じたように、いくつかの例では圧縮オブジェクト及びマップはネットワーク記憶位置に記憶されてもよい。
【0115】
図11は、いくつかの実装形態に係るマップに基づく解凍のための処理1100の一例を示す流れ図である。いくつかの事例では、処理1100はサービス計算装置又は他の適切な計算装置によって少なくとも部分的に実行されてもよい。一例として、
図1に関して上記で論じたサービス計算装置102の複数の中の1つのプロセッサによって実行されるストレージプログラムは、
図11の処理1100の少なくとも一部を実行するための実行可能命令を含んでもよい。
【0116】
圧縮データオブジェクトの少なくとも一部にアクセスするための要求が受信された場合、サービス計算装置は例えば
図5に関して上記で論じたようなチャンクサイズ、オペレーションサイズ、オフセット頻度、マップ状態、及び特殊値インジケータを含むパラメータを決定するために、オブジェクトのマップヘッダにアクセスし、読み出してもよい。マップがない又は全てのチャンクが圧縮され、要求が0の位置で開始する場合、計算装置はマップなしにオブジェクトの全データを解凍してもよい。例えばオブジェクトはマップ等を生成するのに十分大きくなかった可能性がある。
【0117】
いくつかの例では、マップがヘッダと共にメタデータデータベース内に記憶された場合はマップはヘッダの後に見つけられることができ、又は他の例ではマップは圧縮オブジェクトの末尾に付加され又は離れた記憶位置に記憶される。マップサイズは、チャンク数(非圧縮オブジェクトサイズ割るチャンクサイズ)掛ける圧縮チャンクサイズ表現エントリ内のバイト数足す絶対オフセット数(チャンク数割るオフセット頻度)掛けるオペレーション内のチャンク数(例えば
図9及び
図10の例では8)として計算してもよい。マップが圧縮オブジェクトに付加されている場合、マップは圧縮オブジェクトの終わりよりもマップサイズバイトだけ前において見つけられる。
【0118】
計算装置は、例えば(要求開始/(オフセット頻度*チャンクサイズ))に基づいて要求が開始するマップセグメントを決定してもよい。計算装置は、計算された最初のセグメントから要求サイズの最終セグメントまでマップセグメントを読み出してもよい。計算装置は、要求開始の後に来ない最終オペレーションまでスキップしてもよい。オペレーション内の任意のチャンクが特殊サイズ(64K-1の倍数)を有することができ、有する場合、計算装置は要求された開始位置よりも前のデータを破棄してオペレーション内の最初のチャンクから続けて解凍してもよい。オペレーション内のチャンクが0又は特殊サイズを有さない場合、計算装置は次のチャンクの位置が高くなるまでチャンクをスキップし、解凍を開始し、要求された開始位置よりも前のデータを破棄してもよい。圧縮サイズエントリが0である場合、計算装置は要求されたオペレーション内の位置からオペレーションの残りの部分まで圧縮オブジェクトのデータを複製してもよい。任意の圧縮サイズエントリが0である場合、計算装置は要求サイズが満たされるまでその後必要とされるオペレーションを解凍し続ける又はデータを複製し続けてもよい。
【0119】
1102で、計算装置はデータにアクセスするための要求を受信してもよく、対応するマップヘッダからパラメータ、例えばチャンクサイズ、オペレーションサイズ、及びオフセット頻度を取得してもいい。例えばユーザ、アプリケーション等は、1又は複数の記憶済み圧縮オブジェクトの1又は複数の部分にアクセスすることを要求してもよい。例えばリード要求は圧縮オブジェクトからのデータの範囲に対するものであってもよい。開始位置及びサイズは、例えば非圧縮オブジェクト内の開始位置及びサイズに基づいて要求内に指定されてもよい。
【0120】
1104で、計算装置は既知の非圧縮オブジェクトサイズに基づいてマップのサイズを判定してもよく、例えばマップは圧縮オブジェクトサイズ引くマップサイズにおいて開始してもよい。例えば圧縮オブジェクトサイズ及び非圧縮オブジェクトサイズは、オブジェクトの取り込み及び圧縮中にメタデータデータベース内に記憶されていてもよい。
【0121】
1106で、計算装置は要求に対応するセグメントを、例えば(要求開始/(オフセット頻度*チャンクサイズ)に基づいて決定してもよい。更に計算装置はマップセグメントを読み出し、圧縮オフセットを(第1の値-絶対オフセット)に設定し、非圧縮位置を(セグメント数*オフセット頻度*チャンクサイズ)に設定してもよい。例えば、マップセグメントは圧縮オブジェクト内の相対的位置を確立するために絶対オフセットから開始するので、マップセグメントはマップの残りの部分なしに使用可能なマップエントリの集合であってもよい。
【0122】
1108で、計算装置は(位置+オペレーションサイズ)が要求開始未満か否かを判定してもよい。該当する場合、この処理は1110に進む。該当しない場合、この処理は1112に進む。例えば位置は非圧縮オブジェクトから決定される位置等に基づく開始位置であってもよい。
【0123】
1110で、計算装置は(オペレーション当たりのチャンク)のサイズを取得し、もしある場合は0に実際のチャンクサイズを使用してそれを圧縮オフセットに加え、オペレーションサイズを位置に加えてもよい。この処理は1108に戻って(位置+オペレーションサイズ)が要求開始未満か否かを判定する。1108及び1110におけるオペレーションは、この処理が1112に進むまで繰り返される。
【0124】
1112で、計算装置は現在のオペレーションについて全ての圧縮サイズを得てもよく、
図12の処理に進めてもよい。
【0125】
図12は、いくつかの実装形態に係る
図11の処理1100の続きである処理1200の一例を示す流れ図である。
【0126】
1202で、計算装置は圧縮サイズが全てゼロであるか否かを判定してもよい。該当する場合、この処理は1218に進む。該当しない場合、この処理は1204に進む。
【0127】
1204で、計算装置は特殊値((64K-1)の倍数)があるか否かを判定してもよい。該当する場合、この処理は1214に進む。該当しない場合、この処理は1206に進む。
【0128】
1206で、計算装置は(位置+チャンクサイズ)<要求開始であるか否かを判定してもよい。該当する場合、この処理は1208に進む。該当しない場合、この処理は1210に進む。
【0129】
1208で、計算装置は圧縮サイズをオフセットに加えてもよく、チャンクサイズを位置に加えてもよい。
【0130】
1210で、計算装置は計算装置は、オペレーション内の残りのチャンクを解凍し、(要求開始-位置)を破棄してもよい。
【0131】
1212で、計算装置は残りの圧縮サイズをオフセットに加え、残りのチャンクサイズを位置に加え、読み出したデータを要求開始に加え、読み出したデータを要求サイズから引いてもよい。
【0132】
1214で、1204で発見された特殊値がある場合、計算装置は全てのオペレーションデータを解凍し、(要求開始-位置)を破棄してもよい。
【0133】
1216で、計算装置は全ての圧縮サイズをオフセットに加え、オペレーションサイズを位置に加え、読み出したデータを要求開始に加え、読み出したデータを要求サイズから引いてもよい。
【0134】
1218で、オペレーションの圧縮サイズが1202で全てゼロである場合、計算装置は(オフセット+要求開始-位置)において解凍なしにデータの読み出しを開始してもよく、オペレーションデータの残りの部分まで読み出してもよい。
【0135】
1220で、計算装置はオペレーションサイズを位置及びオフセットに加え、読み出したデータを要求開始に加え、読み出したデータを要求サイズから引いてもよい。
【0136】
1222で、計算装置は要求サイズがゼロを上回るか否かを判定してもよい。該当する場合、この処理は1224に進む。該当しない場合、この処理は1228に進む。
【0137】
1224で、計算装置はセグメント内に更にチャンク表現があるか否かを判定してもよい。該当する場合、この処理はブロック1112へと
図11の処理に進む。該当しない場合、この処理は1226に進む。
【0138】
1226で、計算装置は次のマップセグメントを読み出し、
図11のブロック1112に進んでもよい。
【0139】
1228で、要求サイズがゼロに達すると、計算装置はまだ解凍されていない圧縮データを解凍してもよく、要求に応答してもよい。
【0140】
本明細書に記載した処理例は論述目的で示した処理の例に過ぎない。本明細書の開示に照らして数多くの他の改変形態は当業者に明らかになる。更に、本明細書の開示は処理を実行するのに適した枠組み、アーキテクチャ、及び環境の幾つかの例を記載したが、本明細書の実装形態は図示し述べた具体例に限定されない。更に、本開示は記載し図中に示した様々な実装形態の例を提供する。但し本開示は、本明細書に記載し示した実装形態に限定されず、当業者に知られる又は当業者に知られることになる他の実装形態に及び得る。
【0141】
本明細書に記載した様々な命令、処理、及び技術は、コンピュータ可読媒体上に記憶され、本明細書のプロセッサによって実行されるプログラム等のコンピュータ実行可能命令の全般的な脈絡において検討することができる。典型的にはプログラムは、特定のタスクを実行し又は特定の抽象データ型を実装するためのアプリケーション、ルーチン、オブジェクト、構成部、データ構造、実行可能コード等を含む。これらのプログラム等はネイティブコードとして実行されてもよく、又は仮想マシン若しくは他のジャストインタイムコンパイル実行環境等の中でダウンロードし実行されてもよい。典型的には、プログラムの機能は様々な実装形態において所望の通りに組み合わせられ又は分散されてもよい。これらのモジュール及び技術の実装はコンピュータ可読記憶媒体上に記憶されてもよく、又は何らかの形の通信媒体上で伝送されてもよい。
【0142】
構造上の特徴及び/又は方法論的な行為に固有の言語によって本内容を説明してきたが、添付の特許請求の範囲に定める本内容は記載した特定の特徴又は行為に必ずしも限定されないことを理解すべきである。むしろ特許請求の範囲を実装する形態の例として特定の特徴及び行為を開示している。