JP4533454B2

JP4533454B2 - 階層セグメント表現を含む記憶および伝送時のデータ圧縮に関するコンテント・ベースのセグメント化方式

Info

Publication number: JP4533454B2
Application number: JP2009112959A
Authority: JP
Inventors: スティーブンマケーン; ミカエルジェイ．デマー
Original assignee: リバーベッドテクノロジーインコーポレーティッド
Priority date: 2002-10-30
Filing date: 2009-05-07
Publication date: 2010-09-01
Anticipated expiration: 2023-10-28
Also published as: AU2003288962A1; US20040174276A1; US7852237B2; US8508389B2; AU2003288962A8; CN1736030B; US20070018858A1; US20090079597A1; US6961009B2; WO2004042930A3; JP2009171636A; JP2009171635A; EP1584139A2; US20110267207A1; JP4512893B2; DE60328528D1; US7116249B2; EP1584139A4; CN101599091A; HK1076935A1

Description

関連出願の相互参照
「Transaction Accelerator for Client-Server Communication Systems」[Attorney Docket No: 021647-000100US]（以下「McCanne I」）という名称の米国特許出願第10/285,315号は、本出願と同じ日付に出願され、参照としてすべての目的で本明細書に組み入れられる。

発明の背景
本発明は、概してデータ圧縮に関し、より具体的には圧縮に用いられるセグメント化に関する。

データ圧縮は、データをより有効に記憶し伝送するうえで有用である。データ圧縮は、圧縮後のデータが入力データよりも少ないビットまたは記号を含み、圧縮されたデータを元の入力データの少なくとも適切な近似値に解凍することができるように、入力データを圧縮データとして表すプロセスである。圧縮は、送信するビット数を少なくしても、受信側が元の1組のビットを（厳密にまたは近似的に）回復することができるため、データをより効率的に伝送するのを可能にし、かつ圧縮は、記憶する必要のあるビット数が少なくなるため、より効率的な記憶を可能にする。

「圧縮比」とは、元のデータ内のビットまたは記号の数と圧縮後のデータ内のビットまたは記号の数との比を指す。たとえば、100バイトのデータのシーケンスを5バイトのデータで表すことができる場合、この例の圧縮比は20:1である。入力データを厳密に回復する必要がない場合、一般に「ロスレス」圧縮よりも圧縮比が高くなるいわゆる「ロシー圧縮」を使用することができる。圧縮が透過的である必要のある代表的な用途では、圧縮はロスレスであるべきである。

入力されるコンテントの構造および統計に基づく圧縮が一般的である。代表的なコンプレッサは、データの入力ストリームまたはブロックを受信し、入力における記号値、入力における特定の記号値の位置、入力における様々な記号値間の関係、入力データの供給源の予想される性質を考慮に入れて圧縮ストリームまたはブロックを生成する。たとえば、入力データが英語テキストであることが予想される場合、（ピリオド）記号に続く供給源の出力は「」（空白スペース）記号である可能性が非常に高い。供給源のこの特性は、コンプレッサによって活用することができる。たとえば、空白スペースは、圧縮後のデータでは記号無しで表すことができ、したがって、データが1記号分少なくなる。もちろん、圧縮データをロスレスに解凍できるようにするために、コンプレッサは、ピリオドの後が空白スペースにならないそれぞれの例について特殊な表記を符号化する必要がある。しかし、相対的な発生頻度を仮定すると、特殊な表記よりも省略の方がずっと多いことが予想され、したがって、全体的な結果は正味圧縮になる。

入力文字の反復シーケンスを含む可能性が高い供給源に対して使用される1つの圧縮方法は辞書手法である。この手法では、記号シーケンスの辞書が作成され、辞書内の1つの記号シーケンスの各オカレンスが辞書内の索引で置き換えられる。コンプレッサとデコンプレッサが同じ辞書にアクセスできる場合、デコンプレッサは、各辞書参照を対応するエントリで置き換えることによって圧縮データをロスレスに解凍することができる。一般に、辞書圧縮では、入力ストリームをシーケンスに分割することができ、これらのシーケンスが後で入力ストリームにおいて再び発生すると仮定される。

もちろん、辞書手法を作用させるには、デコンプレッサが、コンプレッサによって使用される辞書のコピーを有する必要がある。圧縮が伝送作業を軽減するためのものである場合、コンプレッサとデコンプレッサは通常、作業が軽減される伝送チャネルによって分離されるが、辞書がそのチャネル上で送信される場合チャネルに対する負荷が増大する可能性がある。圧縮が記憶量を少なくするために適用される場合、デコンプレッサが辞書にアクセスできるように辞書を記憶する必要があり、それによって記憶作業が増大するため、同様の問題が起こる。いくつかの方式では、辞書が固定辞書であり、したがって、辞書を多数の圧縮に共用し、辞書の圧縮当たりコストをオーバヘッドが目立たない程度に安くすることができる。他の方式では、辞書は、適応的であるが、すでにデコンプレッサに利用可能なデータから解凍済みの記号として再構成することができる。

圧縮は、ネットワーク・トラフィックが帯域幅制約によって制限されるネットワークで有用である。一例は、一般に、専用ローカル・エリア・ネットワーク（LAN）や専用WANのような他のネットワークよりも1回使用するごとの空き帯域幅が少ない、インタネットなどのワイド・エリア・ネットワーク（WAN）である。コスト上の理由で、LANのみに依存するかまたは専用WANを追加する代わりに非専用WANを用いることが望まれることが多いが、非専用WANの性能によって制約される。圧縮は、場合によっては、低帯域幅リンクを高帯域幅用途に使用可能にする。これは、圧縮によって、より大きな入力シーケンスを表すのに必要な実際のビット数が少なくなるからである。同様に、圧縮は場合によっては、システム内のすべてのファイルを表すのに必要なビット数を少なくすることによってファイル・システムの性能または容量を改善することができる。

一般に、エンタープライズ・システムおよびネットワークを介して記憶され伝達されるデータには高度の情報冗長性が存在することが多い。たとえば、企業内の多数の受信側に送信されるeメール・メッセージおよび添付ファイルは、記憶システム内にメッセージ・データの多数の冗長コピーを生成すると共に、ネットワークを介して冗長トラフィックを送信させる。同様に、企業内の多くの電子ドキュメントは、様々な従業員が様々な環境において類似した企業情報で作業するため、共用度が非常に高い。

このようなデータを圧縮する場合、ネットワーク性能が向上し、有効記憶容量が増える。従来の圧縮方式は、入力記号ストリームにおける統計的相関を検出し、統計的相関に基づいてストリームの記号をできるだけ少ないビットで符号化することによって、このような冗長性をある程度活用することができる。いくつかの辞書ベースの圧縮方式は、入力記号が固定ランダム・プロセスに従うという仮定を含む様々な仮定の下で最適な圧縮方式に収束する（シャノン限界）という点で「ユニバーサル符号」と呼ばれている。このことは、単に、ネットワークにおけるネットワーク・トラフィックまたは記憶システムにおけるファイル・データの最適な圧縮を実行したニユバーサル符号化システムを導入することによって、最適な性能を実現できることを意味する。

しかし、この手法は実際にうまく働くとはかぎらない。たとえば、ルータのネットワーク・インタフェース上で圧縮を可能にすると性能が向上するが、ぎりぎりの向上（30%が典型的であるが、基本的なトラフィックに依存する）であることが公知である。従来のユニバーサル符号化方式の1つの問題は、基本的なデータ入力が非固定統計を有するため、これらの方式が最適な速度に収束するとは限らないことである。さらに、基本的な統計が固定統計であるが「長距離依存性」（LRD）を示す場合、ユニバーサル符号が最適な性能に収束する速度は非実用的な程度に遅い（おそらく指数関数的に遅い）。これは、多くの研究が、ネットワーク・トラフィックがLRDを示すという証拠を与えており、実際、基本的なデータ・プロセスがLRDランダム・プロセスとして最もうまくモデル化されるかそれとも非固定プロセスとして最もうまくモデル化されるかが未だに議論されている。他の研究は、ファイル統計（サイズ分布など）もLRDを示すことを示している。簡単に言えば、これはすべて、従来のユニバーサル符号化方法が必ずしも実際的な解決策ではなく、典型的なデータ供給源の長距離依存性を活用した技術の方が優れた機能を発揮する可能性が高いことを意味する。

長距離相関を検出する1つのブルート・フォース（brute-force）手法は、大きな帯域幅によって、データ供給源において、繰り返されるパターンを探索する辞書ベースの圧縮方式を使用し、このようなパターンを名前またはラベルで表し、対応するデータを名前またはラベルに関連付けてテーブルまたはデータベースに記憶することである。LRDを活用するときは、システムが入力を（または時間的に）任意に遡って長距離依存パターンを検出するのを可能にするデータの非常に大きい窓を維持することができる。この簡単なモデルは、直感的に企業内の情報の構造に一致する。すなわち、多数の互いに類似した情報源が長期間にわたって徐々に変化すると共に様々な場面（eメール、ファイル・システム、Webなど）に現れる。基本的な技術が向上するにつれて（たとえば、ディスクおよびメモリがますます廉価になるにつれて）、この手法はさらに実際的なものになっていく。しかし、ブルート・フォース手法はそれにもかかわらず欠点を有する。

1つの欠点は、ビット・ストリームにおいて一致するデータの任意のパターンを探索するための計算コストが高価であり、LRD統計の存在下で最適な解決策を高速にかつ効率的に見つけるという一般的な問題が十分に解決されていないことである。他の手法は、最適な解決策を見つけるという理想を棄て、その代わりに、LRDを考慮してうまく機能しかつ実際的で実現可能な近似的な解決策または発見法を重視することである。

この点で有用であることが証明されている1つの手段は、外部から課される何らかのブロッキングまたはフレーミング方式ではなく、入力コンテント自体に基づいてデータをセグメント化することによってデータ内の繰り返されるパターンを見つける提案された発見法である。たとえば、Muthitacharouen, A., et al., 「A Low-Bandwidth Network File System」, in Proceedings of the 18th ACM Symposium on Operating Systems Principles (SOSP '01), pp. 174-187 (Chateau Lake Louise, Branff, Canada, October 2001) （ACM SIGOPS Operating Systems Review, ACM Pressの第35巻の5）を参照されたい。この論文に記載されたLBFSシステムでは、伝送されるファイルの一部がハッシュで置き換えられ、受信側がハッシュを使用してどのファイルのどの部分が置き換えられたデータに対応するかを再構成する。入力コンテントに基づくセグメント化の他の例は、Manber, 「Findings Similar Files in a Large File System」, USENIX Proceedings, San Francisco 1994（University of Arizona Dept. of Comp. Sci. Technical Report TR93-33として入手可能）に記載されているように、ファイルの一致する部分に関して記載されている。

辞書形式圧縮技術によってネットワーク・トラフィックを低減させる他の試みはネットワーク・レイヤに対して行われている。1つのそのような技術は、ネットワーク・トラフィックの各部をトークンで表し、接続部の各端部にトークンのテーブルを維持することを含む。たとえば、Spring, N., et al., 「A Protocol-Independent Technique for Eliminating Redundant Network Traffic」, in Proceedings of ACM SIGCOMM (2000年8月)を参照されたい。この参考文献に記載されているように、冗長性を含むネットワーク・トラフィックは、繰り返されるストリングを識別し、接続部の各端部の所の共用テーブルから分解すべきトークンで、繰り返されるストリングを置き換えることによって低減させることができる。この手法は個々のパケットにのみ作用するので、この手法から得られる性能上の利点は、パケット・ペイロード・サイズとパケット・ヘッダの比によって制限される（パケット・ヘッダは一般に、前述の技術では圧縮できないため）。さらに、この機構は、パケット・レベルで実現されるので、ネットワークの、通信パスの2つの端部が装置を含むように構成されている領域にのみ適用される。この構成は、ある種の環境では、非実際的ではないにせよ実現が困難である。さらに、比較的小さなメモリ・ベースのテーブルと先入れ先出し置換方式を用いて（たとえば、ディスク・ベースの大きなバッキング・ストアの助けなしに）ネットワーク・パケットを索引付けすることによって、この手法の効果は、時間的にかなり局部化された冗長性の検出および活用に制限され、すなわち、この手法は、基本的なデータ・ストリームのLRD特性を活用することができない。

ネットワーク・トラフィックを低減させる他の手法は、データのコピーがローカルにキャッシュで利用できる場合にデータの要求がネットワーク上で送信されるキャッシングを含む。本明細書では、用語「近い」、「遠い」、「ローカル」、および「リモート」は、物理的な距離を指すことがあるが、より典型的には有効距離を指す。2つのコンピュータ、コンピューティング装置、サーバ、クライアント、周辺装置などの間の有効距離は、少なくとも概ね、2つのコンピュータ間でデータを得る際の困難さの尺度である。

キャッシングは、変化しないデータのブロックであって、それぞれの異なる名前を有する互いに類似した形式としては存在しないデータのブロックには良好であるが、依然として多くの場合、改善が必要である。ファイル・キャッシングでは、キャッシングの単位は通常、ファイルのブロックまたはファイル全体である。異なるファイルに同じデータが存在するか、または2つのファイルがわずかな違いしか有さない場合、キャッシングによって冗長性が除去されることも、通信コストが削減されることもない。データ・オブジェクトが多数のブロックとしてセグメント化され、各ブロックが別々にキャッシングされる場合でも、基本的なオブジェクトにデータの削除をわずかに挿入するとデータが（すべてではないにせよ）多数のブロックにわたってシフトし、したがって、キャッシングの利点が無効になるため、正味結果は依然として非効率的である。これは、各ブロックが任意に入力ストリームに課され、したがって、基本的なデータにわずかな変更のみが加えられたことを検出するのが不可能であるからである。

上記を考慮して、ネットワーク環境、記憶システムなどにおけるデータの圧縮を改良することができる。

Muthitacharouen, A., et al., 「A Low-Bandwidth Network File System」, in Proceedings of the 18th ACM Symposium on Operating Systems Principles (SOSP '01), pp. 174-187 (Chateau Lake Louise, Branff, Canada, October 2001) （ACM SIGOPS Operating Systems Review, ACM Pressの第35巻の5） Manber, 「Findings Similar Files in a Large File System」, USENIX Proceedings, San Francisco 1994（University of Arizona Dept. of Comp. Sci. Technical Report TR93-33として入手可能） Spring, N., et al., 「A Protocol-Independent Technique for Eliminating Redundant Network Traffic」, in Proceedings of ACM SIGCOMM (2000年8月)

発明の簡単な概要
本発明の一態様による符号化システムでは、システム内の入力データが符号化される。入力データは、入力データ内で繰り返されるかまたはシステム内で符号化される他の入力データ内で発生する記号のシーケンスを含んでよい。符号化は、1つまたは複数のターゲット・セグメント・サイズを判定する段階と、1つまたは複数の窓サイズを判定する段階と、入力データ内のオフセットにおける記号の窓内のフィンガープリントを識別する段階と、オフセットをカット・ポイントとして指定すべきかどうかを判定する段階と、1組のカット・ポイントによって示されるように入力データをセグメント化する段階とを含む。識別すべき各セグメントごとに、エンコーダは、セグメントが参照されるセグメントであるかそれとも参照されないセグメントであるかを判定し、それぞれの参照されるセグメントのセグメント・データを参照ラベルで置き換え、必要に応じて、それぞれの参照されるセグメントの持続セグメント・ストアに参照バインディングを記憶する。このプロセスは、各階層において、参照ラベル・ストリングをグループとしてセグメント化し、グループ分けされた参照をグループ・ラベルで置き換え、グループ分けされた参照とグループ・ラベルとの間のバインディングがすでに存在していない場合にこのバインディングを記憶し、このプロセスを繰り返すことによって繰り返すことができる。階層レベルの数は、事前に固定することも、符号化されるコンテントから決定することもできる。

本発明の他の特徴および利点は、以下の詳細な説明および好ましい態様を鑑みて明らかになると思われる。

コンテント参照およびセグメント参照に基づくセグメント化を用いてデータ・ストリームまたはブロックを符号化するエンコーダのブロック図である。持続セグメント・ストアからのセグメント化バインディングを用いてデータ・ストリームまたはブロックを復号するデコーダのブロック図である。符号化プロセスを詳しく示す図である。復号化プロセスを詳しく示す図である。階層符号化プロセスを示す図である。複数のレベル・セグメント・ストアを有する持続セグメント・ストアの図である。用いる符号化レベルが少なすぎる場合の問題を概略的に示す図である。用いる符号化レベルが少なすぎる場合の問題を概略的に示す図である。任意の参照深さを保持するように構成された持続セグメント・ストアの図である。図9の持続セグメント・ストアを用いた復号化プロセスを示す図である。階層的なコンテント誘導セグメント化を示す図である。クライアントとサーバとの間のあるトラフィックがクライアント側トランザクション・アクセルレータ（「CTA」）およびサーバ側トランザクション・アクセルレータ（「STA」）を通してルーティングされるネットワーク化されたクライアント−サーバ対のブロック図である。階層的なコンテント誘導セグメント化を用いたファイル・システムを示す図である。ニアライン・ファイル・システム（NLFS）およびファイル・サーバ・フロント・エンドを示す図である。

発明の詳細な説明
本発明は、本開示を読んだ後で明らかになる多数の用途を有する。本発明による圧縮システムの態様を説明するうえで、可能な変形態様のいくつかのみについて説明する。当業者には他の用途および変形態様が明らかになり、したがって、本発明は実施例ほど狭義に解釈すべきではなく、むしろ添付の特許請求の範囲に従って解釈すべきである。

符号化（符号化、復号）は、ハードウェア、ソフトウェア、またはその両方を含んでよいいくつかの異なる装置によって行うことができる。符号化は、コンピュータ、コンピューティング装置、周辺装置、電子機器などを用い、かつ／またはそのような要素によって実行もしくは制御されるアプリケーションを用いて行うことができる。符合化は、McCanne Iに記載されたような透過的なプロセスに付随して行うことができる。本明細書に記載された符号化装置およびプロセスを用いて、重要なチャネル上で重要な時間に伝送する必要のあるビットの数を少なくすることによって、ネットワーク上のトランザクションの応答性を改善することができる。さらに、符号化システムを独立記憶システムと統合して容量を最適化することができる。この環境では、本明細書で説明する符号化システムは共通のデータ・シーケンスを抽出し、シーケンスが場合によっては何度も、場合によっては多数の異なるファイルに表れる場合でも、一度しか記憶しないため、記憶システムの有効容量を改善することができる。

図1は、エンコーダが有することのできる特定の入力を示している。図1に示されているように、エンコーダは、入力データを受信するための入力と、ターゲット・セグメント・サイズ、窓サイズ、その他の制御パラメータなどのパラメータ用の入力と、符号化プロセスで生成された出力データおよびバインディング用の出力とを有する。これらのデータは、必要に応じて持続セグメント・ストア（PSS）210に記憶される。動作時には、エンコーダ140は、入力データを処理し、データのセグメントを識別し、セグメントのデータを参照で置き換え、セグメント・データおよびセグメント参照をバインディングの形でPSS 142に与え、符号化されたデータを出力する。符号化データは、参照されないセグメント・データ、埋め込みバインディング、および／または参照されるセグメント用の参照ラベルを含んでよい。最も簡単なケースでは、出力データ全体が参照ラベルである。

ターゲット・セグメント・サイズ・パラメータは、エンコーダがセグメントの平均サイズを調節するのに用いられる。一般に、セグメントは可変長であり、以下に説明するようにこのサイズの選択では設計上の兼ね合わせが行われる。

図2は、エンコーダ200によって行われる符号化を反転させた復号を協働して実行するデコーダ300およびPSS 310を示している。上述のように、符号化データは参照、バインディング、および参照されない残留データを含んでよい。デコーダ150は、受信したデータ内にバインディングを見つけると、そのバインディング内のセグメント・データを用いて元のデータを再構成し、かつバインディングをデコーダ150のPSSに記憶することができる。デコーダ150は、バインディングのない参照を見つけると、その参照を用いてPSS 152からセグメント・データを得て、セグメントを再構成することができる。PSS 152にセグメント参照がない場合、デコーダ150はそのセグメント・データを求める要求を送信することができる。

図3は符号化プロセスを詳しく示す図である。図3に示されているように、符号化すべき入力データは、バッファ220に記憶され、PSS 210用の出力参照およびバインディングを作成するセグメント・デリミタ222によってセグメント化される。必要な出力参照、セグメント224のような参照されないセグメント、およびバインディングは、出力バッファ230に供給され、エンコーダの出力が形成される。

図4は、復号化プロセスを詳しく示す図である。図4に示されているように、符号化されたデータは入力バッファ320にバッファされる。バッファのコンテントからバインディングが抽出され、PSS 310に記憶される。参照ラベルは、それを参照されるセグメント・データで置き換え、データを出力バッファ330内に配置するリプレーサ325に供給される。参照されないセグメント・データは、出力バッファ330に直接出力され、最終的に再構成されたデータとして出力される。

上述の図が示しているように、符号化プロセスの一局面は入力データのセグメント化である。セグメント化プロセスにおいて、あるセグメントが終わり次のセグメントが始まる入力データ内のオフセットなどの「カット・ポイント」を識別することは、入力データを別々のデータ構造などに分離することと同等である。

セグメント化方式が適切に設計されている場合、セグメント境界は、同じデータ・シーケンスについては、そのデータが現れた文脈にかかわらず、常に同じ場所に現れる必要がある。そうである場合、共通に繰り返されるデータ・パターンは、各データ反復上で同じようにセグメント化され、これらの繰り返されるパターンを効率的に識別するようにシステムを設計することができる。たとえば、より大きなファイル（ワープロ文書、スライド発表文書、ウェブ・ページ上など）内の多数の異なる位置に現れる特定のデータ・シーケンス（広く使用されているGIF画像の一部や一般に使用されているグラフィカル・アイコンを表すビットマップの一部）は、それをどんなデータが囲んでいるかにかかわらず、常に同じように見つけられセグメント化される。

この特性を実現するために、本明細書のセグメント化方式では、ブロック・サイズ、トランザクション境界のような外部から課されるパラメータらではなく、データ自体の情報を用いてセグメント化プロセスを導く。入力データが符号化プロセスで消費された際、入力記号の様々な値および構造が（後述のように）セグメント化プロセスを導く。したがって、システムは、互いに類似したデータ・パターンがその入力に与えられた場合に、同じセグメント境界が検出される特性であって、以前に見たのと同じセグメントの形成を含む「自己同期」特性を有する。さらに、このことは、以前に存在していたセグメント境界が見つかると、その点から新しいセグメントが既存のセグメントに一致する（その点からのデータ・パターンを以前に見たことがあると仮定する）という点で、システムが基本的な入力データにおける挿入、削除、またはその他の変更に対してロバストであることを意味する。

この方式は、入力のコンテントによって導かれるので、本明細書では「コンテント誘導セグメント化」と呼ぶ。非常に大きなタイム・スケールにわたって繰り返されるパターンを有する（すなわち、LRD統計を示す）入力ストリームにコンテント誘導セグメント化を適用することによって、以前に見たことのあるデータ・パターンの履歴全体を追跡する必要なしに同じセグメントが作成される。すなわち、セグメント化プロセスは、すでに見つかっている既存のデータ・パターンを探索する必要なしに入力自体に基づいて入力を簡単にセグメント化することができる。一般に、この手法では、最適なセグメント化は行われない（すなわち、セグメントのサイズが最大になり、同時に、見つけられる反復セグメントの数が最大になる）が、複雑さと性能の兼ね合わせが適切に行われ、この方式は、効率的で実際的な実現態様を実現しつつある種のLRDを活用するうえで有効である。

コンテント誘導セグメント化
図3のセグメント・デリミタ222などのセグメンタは、1組の入力データの一部（またはすべて）に作用する。セグメンタは、（現在のオフセットおよび窓サイズ・パラメータによって決定される）ある数の入力記号をまとめ、窓に対するハッシュ関数を算出する。これを窓のフィンガープリントと呼ぶ。確定的フィンガープリント・インジケータ関数は、オフセットをカット・ポイントとみなすべきかどうかを示す各フィンガープリントのブール値を返し、それによってセグメント境界を定義する。好ましくは、窓はアプリケーション・データ・ユニット（ADU）の各端部を越えて延びず、したがって、各窓寄与は、厳密に1つのADUから得られる。したがって、好ましくは、入力データ・ストリーム内の、あるADUが終わり別のADUが始まる表示が、エンコーダに与えられる。しかし、このような表示は、システムを正しく動作させるのに必要ではない。むしろ、このような表示は、エンコーダが、ADU境界が終わるセグメント化境界をストリーム内に強制的に配置するのを可能にし、したがって、到達しない可能性のあるデータを待つ余分な遅延のような実質的な非効率を防止する（たとえば、この代わりに、実現タイムアウトに依存してセグメント境界を強制的に配置する）。さらに、セグメント境界を単一のADU内に制限すると、セグメントが2つのADUにわたる場合のように将来繰り返される可能性の低いセグメントをシステムが検出し記憶するのが防止される。

フィンガープリント・インジケータ関数値が1および0である場合、1はカット・ポイントを表すことができ、0はカット・ポイント以外を表す。したがって、ある規約の下では、関数が所与のオフセットおよび窓を有する所与のフィンガープリントについて1に評価されると、新しいセグメントが、（入力データ順による順序の）入力データの第1の記号によって定義される記号の所に作成される。この規約の下では、関数が0に評価された場合、さらに1つの入力記号が消費され、この新しい記号をカバーするように窓が進められる（かつ最下位の現在の記号が窓から除去されるが現在のセグメントに残る）。したがって、ターゲット・セグメント・サイズをフィンガープリント・インジケータ関数のパラメータとして制御することができる。

適切に選択されたフィンガープリント関数は、フィンガープリント内にランダム・ビット・パターンを作成する傾向があるので、ターゲット・セグメント化・サイズによってパラメータ化されたランダム変数のベルヌーイ分布関数を用いて、ハッシュ値をインジケータ値にマップすることができる。たとえば、パラメータは、平均して、フィンガープリント入力のランダム分布を仮定すると、M回のうち1回は関数が真に評価されるように選択することができる。したがって、平均して、セグメント・サイズはM+Wバイトになる。ここでWは使用時の窓サイズである（なぜなら、セグメントの大きさは少なくともWバイトであるからである）。したがって、Mの値はターゲット・セグメント・サイズを決定する。

セグメント・プロセスの変形態様は、窓がセグメント境界の終了位置の代わりにセグメント境界の開始位置を定義するのを可能にする。これによってセグメントを任意に小さくすることができる。というのは、フィンガープリント窓を定義するのに用いられるデータのパターンは、セグメント化の一部として消費されるとは限らないからである。

他の態様では、明白なフィンガープリント窓は必要とされない。その代わり、可変数の入力記号に対してハッシュ関数が算出される。各入力記号が消費されると、消費された記号のバッファ全体に対してフィンガープリント関数が再計算される。この場合も、フィンガープリントに適用される後続のインジケータ関数が、入力内の現在のポイントにいつ新しいセグメント境界を挿入すべきか、およびこの挿入を行うかどうかを決定する。この手法は、一般に前述の手法よりも効率が低い。なぜなら、セグメントの開始位置の近くのデータの変化が、進行するセグメント化プロセスに影響を与えるからである。したがって、他の場合には作成され前のセグメントと突き合わされたであろうセグメント境界を、所望の境界から遠くへ除去される可能性のあるデータの変更のために見失うからである。前述の窓手法はこの目標を厳密に実現する。

フィンガープリント・ハッシング方式は、入力記号が読み取られたときに増分的に更新できるハッシュ関数を使用することによって効率化することができる。増分的に更新される窓用のハッシュ関数を効率的に生成する例は既知であり、本明細書で詳しく説明する必要はない。たとえば、Rabin, 「Fingerprinting by Random Polynomials」, Technical Report TR-15-81, Dept. of Comp Sci., Harvard University (1981)を参照されたい。

（新しいセグメント境界を見つけることによって）新しいセグメントが定義されると、そのセグメントは、PSSに記憶されているすべての既存のセグメントと比較される。この参照プロセスは、セグメント・データに対して算出されるハッシュ関数によって調節されるセグメントの指数を維持することによって（セグメント・コンテント全体、セグメント・コンテントの一部、セグメント・フィンガープリント値）効率化することができる。各ハッシュ値について、指数は、その値にハッシュされる、PSSに存在する1組のセグメントを含む。したがって、あるセグメントがPSSに存在するかどうかを判定するために、エンコーダは、関心対象のセグメントのハッシュの算出し、そのハッシュを用いてセグメントを参照する。参照が失敗した場合、そのセグメントはPSSに存在しない可能性がある。参照が成功した場合、エンコーダは、参照によって返された各セグメントを関心対象のセグメントと比較し、厳密に一致しているかどうかを検査することができる。これによって、複数のセグメントが同じハッシュ指数にハッシュされるというまれなケースが対処される。

引き続き符号化プロセスについて説明すると、許容できるセグメント（通常同一のセグメントであるが、特殊なケースでは、完全な同一性は必要とされない）が存在する場合、この新しいセグメントに新しい固有の名前が割り当てられ、バインディング（参照ラベル、セグメント・データ）がPSSに入力される。必要に応じて、バインディングを圧縮することができるが、PSSが制限されない最も単純なケースでは、各レコードのフィールドが、参照ラベルを表すストリングとセグメント・データを表すデータとを記憶するレコードとして、バインディングをデータベースに記憶することができる。さらに、任意のセグメント・データに存在する短距離依存性を有効に活用する従来の圧縮アルゴリズムを用いて、バインディング内のセグメント・データ自体を圧縮することができる。このことは、セグメント命名方式の詳細に依存して高度の冗長性を有することのできるラベルのストリングを含む非末端セグメント（後述）で特に有用である。

比較できるセグメントが存在する場合、その定義済みの参照ラベルがこの新しいセグメントに用いられ、新しいバインディングは作成されない。次いで、この参照ラベルは、図3に示されているシーケンス226によって示されているように、実際のセグメント・データの代わりに出力される。したがって、元の入力データは、PSSに記憶されているデータ・オブジェクトに結合された参照ラベルのシーケンスとして表される。特定のセグメント（たとえば、図3のセグメント224）を参照ラベルと置き換えても性能が実質的に改善されないと判定された場合など、データによっては参照ラベルで置き換えられないデータもある。しかし、いくつかの態様では、すべてのセグメントが参照ラベルで置き換えられる。

参照ラベルはコンパクトに表されず、シーケンス226に必要なよりも多くのビットが使用される場合がある。この場合、従来の圧縮方法を用いて、たとえば、参照ラベルの差分符号化の後にラン・レングス符号化および／またはハフマン符号化を行ったり、その他の手法を用いたりして参照ラベルを圧縮することができる。

図4は、図3に示されているプロセスを反転させた復号化プロセスを示している。符号化されたデータ（参照ラベル、場合によってはさらにバインディングおよび参照されないセグメント・データ）が入力バッファ320に受け入れられる。この入力されたバッファ・データから、バインディングが抽出されPSS 310に記憶され、参照されないセグメント・データが出力バッファ330に移動させられる。符号化されたデータにおいて参照ラベル（または圧縮された参照ラベル）として表されている参照されるセグメントは、リプレーサ325により、参照ラベルを用いてPSS 310内のバインディングを見つけ、したがって対応するセグメント・データを得ることによって、そのセグメント・データと置き換えられる。参照ラベルは、固有のデータに対して一意であるため、常に正しいセグメント・データを与えることができる。参照されるバインディングがPSS 310に存在しない場合、たとえばPSS 210に要求することができる。符号化が記憶のために行われる場合、PSS 210およびPSS 310は、エンコーダによって書き込まれデコーダによって読み取られる1つのデータ構造であってよい。

多くの場合、符号化プロセスのパラメータは、良好な性能が得られるように慎重に選択する必要がある。ターゲット・セグメント・サイズとして非常に大きなサイズを選択する場合、有効圧縮比は高くなる。これは、多数の記号がセグメントとしてグループ分けされ、セグメントの参照ラベルを表す比較的少数のビットで置き換えられるからである。しかし、ターゲット・ブロック・サイズが大きいと、データの微細な繰返しを見失い、ほぼ同様なセグメント・データの複数のバージョンを記憶し移動させるオーバヘッドが増す傾向がある。一方、ターゲット・セグメント・サイズとして非常に小さいサイズを選択する場合、圧縮比は低くなる。これは、参照ラベルを表すのに必要なビット数が、元のセグメント・データ内のビット数よりも実質的に少なくならないからである。一般に、特定のセグメント化方式が有効である程度は、データの基本的な統計に依存する。この問題は、参照ラベル方式に階層を導入することによって解決することができる。この手法を本明細書では階層コンテント誘導セグメント化（HCS）と呼ぶ。

階層コンテント誘導セグメント化
大きいターゲット・ブロック・サイズの利点（高い圧縮比など）および小さいターゲット・ブロック・サイズの利点（微細な繰返しを認識させそのようにセグメント化させることなど）を得るには、階層参照を使用することができる。このようなシステムでは、小さいターゲット・ブロック・サイズを用いて、符号化すべき入力データをセグメント化し、多数の参照ラベルを生成することができる。参照ラベルは、グループ分けされ、グループ・ラベルで置き換えられ、参照バインディング（グループ・ラベル、グループを形成する参照ラベルのシーケンス）がPSSのような構造に記憶される。この場合、反復パターンが微細に生じるか、それとも粗に生じるかにかかわらず、様々な種類の反復データに対して単一の技術を使用することができる。微細な反復パターンを取り込む場合、ターゲット・ブロック・サイズとしては比較的小さいサイズが選択される。ターゲット・ブロック・サイズが小さいと、符号化参照ストリームはより冗長になるが、階層参照は、多数の参照ラベル・パターンを繰り返させ、実際上、最終結果において結果的に得られる各ラベルに、繰り返されていることが分かるほど大きいスパンの入力データを表させるオーバヘッドを低減させる傾向がある。この階層参照は、各レベルで、そのレベルでの参照名の相対サイズに調整された異なるターゲット・ブロック・サイズを使用するか、または同じサイズを使用することができる。同様に、階層参照は、階層内の各レベルで異なるフィンガープリント関数および／または異なるフィンガープリント窓サイズを使用するか、または全体にわたって一様に同じ関数を使用することができる。

2種類のこのような方式について以下に説明する。階層参照符号化の例を図5に示す。入力バッファに符号化すべき入力データがロードされ、その入力データがセグメントS_A、S_B、S_C、S_D、S_E、およびS_Fにセグメント化される。この例では、最初の5つのセグメントが参照で置き換えられ、これらの参照はR¹ ₁₅、R¹ ₁₆、R¹ ₁₇、R¹ ₃、およびR¹ ₈である。これらの参照は必ずしも順序正しいものではないことに留意されたい。この例は、いくつかの参照（たとえば、R¹ ₃およびR¹ ₈）がすでに見たことのあるセグメント・データに対する参照であり、その場合、新しいセグメントは使用されず、既存のセグメントが参照されることを示している。

理想的には、エンコーダは、たとえば、シーケンス（R¹ ₁₅, R¹ ₁₆, R¹ ₁₇）および（R¹ ₃, R¹ ₈）が頻繁に生じており、したがって、これらのシーケンスをグループ分けし、それぞれR² ₁およびR² ₂などのグループ・ラベルで置き換えることができると判定する。しかし、この問題の解決は一般的に困難である（同じ問題を基本的な問題に対して直接解決するのも同様に困難である）。したがって、エンコーダは、コンテント誘導セグメント化方法を参照ラベル・シーケンスに再適用し、元の手法と同様であるが、より高いレベルの利点をもたらす（すなわち、複雑さが比較的低くなり、入力シーケンスにおいて、基本的なデータに対するシフトおよびローカルな変更とは無関係のパターンを見つけることができる）。したがって、（フィンガープリント関数、窓、およびインジケータを再適用することによって）シーケンス（R² ₁, R² ₂, S_F）がこのより高い層における新しいセグメントに対応するとセグメンタが判定したと仮定すると、元の入力データを新しいセグメント（R² ₁, R² ₂, S_F）の参照によって表すことができる。これに対して、新しい参照ラベルを新しいより高レベルのセグメントに関係付けるバインディングがPSSに入力される。この例には存在しないが、最終シーケンスは任意のまたはすべてのレベルの参照ラベルおよびグループ・ラベルを有することができる。必要に応じて、セグメント・バインディングおよび参照バインディングは記憶され、かつ／またはデコーダに与えられる。

固定レベルHCS
固定レベルHCSでは、PSSは1組のN個の（1よりも大きなある確定整数）バインディング・テーブルPSS¹, PSS², ..., PSS^Nとして構造化される。バインディング・テーブルPSS²は、参照ラベルとセグメント・データとのバインディングを与える。他のバインディング・テーブルは、参照ラベルのグループ用のバインディングなどを与える。これを図6に示す。

バインディング・テーブルは、各セグメントについての任意のビット・ストリングと参照ラベルの任意のシーケンスとを記憶することができる。図5のセグメント化および表現の例を用いると、PSS¹は、バインディング（R¹ ₁₅, S_A）、（R¹ ₁₆, S_B）、（R¹ ₁₇, S_C）、（R¹ ₃, S_D）、および（R¹ ₈, S_E）を保持し、PSS²は、バインディング（R² ₁, R¹ ₁₅+R¹ ₁₆+R¹ ₁₇）および（R² ₂, R¹ ₃+R¹ ₈）を保持する。

この方式を使用すると、入力バッファ内のすべてのデータを最終的に単一のラベルR^N ₁で表すことができ、データ・シーケンスが再び現れた場合、そのシーケンスは単一の参照記号に効率的に表される。同様に、データのサブセットまたはデータのわずかに変更された部分が再び与えられた場合、互いに類似した部分は、同じコンパクトな記号ストリングによって効率的に表され、違いのみが、互いに異なるコンパクトな記号ストリングによって表される。

符号化プロセスとコンテント・ベースのセグメント化との組合せのこのような階層分解は、データがローカルに変化し、それが任意に大きな変化である場合でも、繰り返されるデータの未変更部分は影響を受けないという魅力的な特性を有する。固定サイズ・セグメントを有するシステムでは、データ・オブジェクトの前方近くに数バイトが挿入または削除された場合、あらゆるセグメントが変更される。これは、各固定サイズ・ブロック内のデータがシフトし、したがって、システムには異なるデータに見えるからである。しかし、図5の例では、オブジェクト内の、セグメントS_Cで覆われた点に任意の量のデータを挿入することができ、影響を受けるのは参照R¹ ₁₇およびR² ₁だけである。大きなデータ・オブジェクトの場合、影響をこのように局部化すると、この概念に基づく様々なアルゴリズムによって性能面の重要な節約を活用することができる。

可変レベルHCS
参照グループ分けは、前述の例の固定されたN個のレベルの代わりに、実行時に決定される可変深さを有することができる。これによって、すべての種類およびサイズのデータに作用するNの値を選択する必要がある問題が解消される。

図7に概略的に示されているように、符号化レベルの数が少な過ぎる場合、大きなデータ・ブロックの符号化された参照ストリームはやはり、多数の記号を必要とする。なぜなら、この場合も、基本的なデータを符号化するのに多数の参照ラベルが必要であるからである。言い換えれば、階層レベルが増えた場合、最上レベルの基本的なデータを表す記号の数はさらに少なくなる。しかし、図8に示されているように符号化レベルの数が多過ぎる場合、符号化は小さなデータ・チャンクについての不要なオーバヘッドを導入する。これは、参照レベルが不必要に定義され送信されるからである。

図9は、この問題に対処するために任意の参照深さを保持するように構成された持続セグメント・ストアの図である。図9では、各参照ラベルが指定されたレベル（上記の例の上付き文字）を有するのではなく、セグメント・データ記号のシーケンス用の参照ラベル、参照ラベルのシーケンス用の参照ラベルであるか、それともこの2つのシーケンスの組合せ用の参照ラベルであるかにかかわらず、すべての参照が同様に扱われる。図9に示されているように、参照ラベルR₁はセグメント・データS_Aに結合され、参照ラベルR₂はセグメント・データS_Bに結合され、参照レベルR_iは一群の参照ラベル（R₃, R₇, R₉）に結合され、以下同様である。

エンコーダが入力ストリームに基づいて適切な符号化レベルを柔軟に選択できると仮定した場合、デコーダは、任意の所与の時点で存在する階層レベルの数を知る必要がある。したがって、この情報は、符号化されたビット・ストリームにおいて何らかの方法で送る必要がある。一態様では、符号化された参照ストリームは、レベルの数を特殊な符号によってビット・ストリーム内に逐語的に明白に示す。この方式では、エンコーダは、使用時にレベルの数を変更すると、その変更を明白に示す符号を放出する。

他の態様では、図9に示されているように、各セグメントを非末端または末端として（バインディングで送られる場合と同様に）明白にマーク付けすることによって、この適応的なレベル構造を、符号化された出力で送ることができる。図9では、末端セグメントは最終出力データのストリングを表し、一方、非末端セグメントはラベルのストリングを表す。この情報は、各バインディングごとに、そのバインディングが階層の末端であり最終出力データを表しているかどうか、またはバインディングが他のバインディングを指すラベルのシーケンスを指しているかどうかを示す「リーフ・ビット」としてPSS内に記憶される。セットされたリーフ・ビット（たとえば、「1」）は、そのレコードが末端セグメントのレコードであり、そのレコードのコンテントがさらなるデリミタを含まないセグメント・データであることを示し、クリアされたリーフ・ビット（たとえば、「0」）は、そのレコードが参照ラベルのシーケンスであることを示す。参照ラベルが固定長であるか、または固有の解読性を有する場合、グループ内で参照を区切るのにスペースは必要とされない。他の態様では、各レコードのコンテントは、コンテントが参照を含むかそれともコンテント全体が特定のリーフ・ビットが存在しないセグメント・データであるかをリーダが判定できるように符号化される。

可変レベルHCSを実現するために、エンコーダは、入力データ・ストリームを消費する際、新しい参照を生成し、それを第1レベル参照ラベルのシーケンスに付加する。この成長するラベル・ブロックに新しい参照が付加されるたびに、エンコーダは、参照ラベル・シーケンスに適用されるコンテント誘導セグメント化を用いてセグメント境界を定義する必要があるかどうかを判定する。それによって、フィンガープリント窓と、新しいセグメントをどこに作成すべきかを示すフィンガープリント・インジケータ関数とを用いてラベル・シーケンスに対するフィンガープリントが算出される。これらのパラメータが復号化プロセスとは無関係であり、デコーダがこれらのパラメータを知る必要はない（むしろ、これらのパラメータはエンコーダでの性能の兼ね合せを制御する）ことに留意されたい。新たに付加された参照がシーケンスにセグメント境界を定義させることはないことをフィンガープリント関数が示している場合、エンコーダは引き続き、次の入力データ記号を消費する。

しかし、エンコーダが第1レベル参照シーケンスにおいて新しいセグメント境界を検出した場合、参照ラベルのストリングを含む新しいセグメントが定義される。入力データにおいて新しいセグメントが定義される際に行われるプロセスと同様に、この新しいセグメントは適切なPSS内のすべての既存のセグメントと比較される。既存のセグメントが見つかった場合、そのセグメントの既存の参照ラベルがPSSから検索される。セグメントが見つからなかった場合、参照ラベルのブロックに新しいラベルが割り当てられ、PSS（および場合によっては出力ストリーム）に新しいバインディングが付加される。いずれの場合も、ここで第2レベルのラベルを用いて第1レベルの参照レベルのシーケンスを表すことができる。次いで、この新しいラベルは、成長する第2レベル参照ラベル・シーケンスに付加される。符号化プロセスは、この第2レベル参照シーケンスを調べ、第2レベル参照ラベル・シーケンスにコンテント誘導セグメント化を適用し、セグメント境界があるかどうかを再び判定し、セグメント境界がある場合、第2レベルのラベルのセグメント用の第3レベル参照を生成する。このプロセスは、以後の階層レベルに対して増分的に繰り返され、それぞれの場合に、次に高いレベルの新しい参照定義が生じる（「バブリング・アップ(bubbling up)」）。このように、エンコーダを通過する大きなデータ・ブロックは、複数回にわたって反復的に通過する可能性が高く、一方、小さなデータ・ブロックは不要な符号化レベルを受けない。

図10は、各参照レベルがそのバインディングで置き換えられる、図9の持続セグメント・ストアを用いた復号化プロセスを示している。セグメント・コンテントが参照のシーケンスを含む場合、これらの参照は置き換えられ、プロセスは、すべての参照ラベルが末端ノードを指すまで繰り返され、次いでセグメント・データを出力することができる。言い換えれば、デコーダは参照ブロックを再帰的に分解し、データ・セグメントに達したときに終了する。この態様では、符号化ストリームは、木の葉の所のセグメントが、復号横断をどこで停止すべきであるかを示すように（末端フラグを介して）マーク付けされる参照の階層木と等価である。

このセグメント化方式の1つの利点は、単一の入力ストリーム内の共通のパターンを効果的に認識しかつ圧縮できることである。図11は、1つのそのような例を示している。入力ストリームは、3つのセグメントS₁、S₂、およびS₃に切り分けられる初期データ・バイト・シーケンスを含む。これらのセグメントには参照R₁、R₂、およびR₃が割り当てられる。この例では、残りの入力ストリームは、他の記号を含むと共に、同じデータがさらに2回繰り返されている。セグメント・カット・ポイントはコンテントの関数として定義されるので、PSSで同じセグメント境界が検出され見つかり、したがって、同じ参照シーケンスが出力される。同様に、参照<R₁, R₂, R₃>のシーケンスが新しいセグメント用のカット・ポイントを定義していると階層符号化が判定したと仮定すると、この場合も、単一のラベルR₁₀を用いて、入力ストリームにおいて後で繰り返されるシーケンスを識別することができる。

HCSで実現可能なクライアント−サーバ・トランスポート・プロキシ
図12は、本明細書で説明するHCS符号化を使用できるシステムの例を示している。図12に示されているように、クライアント612は、ネットワーク616上でクライアント側トランザクション・アクセルレータ（「CTA」）620およびサーバ側トランザクション・アクセルレータ（「STA」）622を介してサーバ614に結合されている。1つのクライアントおよび1つのサーバしか示されていないが、CTAおよびSTAが複数のクライアントおよび／または複数のサーバと一緒に動作できることを理解されたい。

クライアント612はCTA 620のクライアント・プロキシ630に結合されている。図12に示されているCTA 620の他の要素には、トランザクション変換器（TT）632と、逆トランザクション変換器（TT^-1）634と、持続セグメント・ストア（PSS）636と、参照リゾルバ（RR）638とが含まれる。サーバ614は、トランザクション変換器（TT）642、逆トランザクション変換器（TT^-1）644、持続セグメント・ストア（PSS）646、および参照リゾルバ（RR）648のような、CTA 620と同様の要素を含むように示されているSTA 622のサーバ・プロキシ640に結合されている。

クライアント612は、TT 632およびTT^-1 634に結合されたクライアント・プロキシ630に結合されている。TT 632は、PSS 636に結合されると共に、CTA 620とSTA 622との間のネットワークに結合されている。TT^-1 634は、PSS 636、クライアント・プロキシ630、RR 638に結合されると共に、CTA 620とSTA 622との間のネットワークに結合されている。RR 638は、図示のように、PSS 636に結合されると共に、CTA 620とSTA 622との間のネットワークに結合されている。

図の反対側で、サーバ614は、TT 642およびTT^-1 644に結合されたサーバ・プロキシ640に結合されている。TT 642は、PSS 646に結合されると共に、STA 622とCTA 620との間のネットワークに結合されている。TT^-1 644は、PSS 646、サーバ・プロキシ640、RR 648に結合されると共に、STA 622とCTA 620との間のネットワークに結合されている。RR 648は、図示のように、PSS 646に結合されると共に、STA 622とCTA 620との間のネットワークに結合されている。

図示の接続のうちで、矢印は、情報の流れの最も一般的な方向を示しているが、情報は他の方向に流れることがあり、単一の方向の情報の流れは、逆方向に流れるデータも含むことがある。たとえば、TT 632は一般に、TT^-1 644の方向に情報を送信するが、これには、TT^-1 644からTT 632に流れる確認、ハンドシェークなどのデータが含まれることがある。

動作時には、CTAおよびSTAは、そのトランザクションが認められている場合のトランザクションのペイロード、および固有の命名方式を用いてこれらのペイロードから導かれるデータのストア／キャッシュ・ストリングまたはその他のシーケンスをセグメント化し（「セグメント」）、このストア／キャッシュ・ストリングまたはその他のシーケンスは、トランザクションとは無関係であってよく、ペイロードをあるTAから別のTAに送信する際、セグメント・データが、以前のトランザクションに現れたか、または他のプロセスによって受信側に送信されたため、受信側が一意に命名されたこのセグメント・データを有することを送信側が予想できるようなセグメント・データであるときに、セグメントの参照においてセグメント・データに置き換わる。

たとえば、クライアントとサーバの対話は、サーバからクライアントへのファイル・データの転送を含んでよい。ただし、これは、クライアント−サーバ・トランザクション志向アプリケーションの特殊ケースに過ぎない。ここで、クライアント612は、ファイル・オープン要求をサーバ614に送信することによってサーバ614にいくつかのファイルを要求することができる。これらの要求は、STAのプロキシ640を介してサーバ614への要求を満たすSTA 622と対話するクライアント・プロキシ630によって満たされる。このように、クライアントとサーバの通信は、他のエンティティに対して（性能の向上を除いて）透過的に加速することができる。クライアント・プロキシ630は、ファイル・オープン要求であり、おそらく符号化されない要求をTT 632にルーティングする。サーバ614からの応答は、要求されたファイルの一部を含むペイロードを含むと仮定される。システムによっては、サーバはまず、クライアントがオープン・ファイルに対するファイル読取り要求を出したときにペイロードのみを含む短い応答でファイル要求メッセージに応答する。ここで、サーバはファイル・コンテントをペイロードとして返すと仮定する。

サーバ・プロキシ640は、応答メッセージおよびそのペイロードを受信すると、そのデータをTT 642に送り、TT 642は、後述のように応答メッセージ（またはそのペイロードのみ）を符号化し、TT 642が作成したあらゆるバインディングをPSS 646に付加し、符号化されたメッセージをTT^-1 634に送信する。TT^-1 634は、メッセージを再構成し、クライアント・プロキシ630を介してクライアント612に中継する。TT^-1 634は、メッセージ内のセグメント参照に置き換わるバインディングを有するため、メッセージを再構成することができる。これらのバインディングはPSS 636から得られ、バインディングがPSS 636にない場合、参照リゾルバ638は参照リゾルバ648からバインディングを得ることができる。このように、メッセージは、メッセージ送信側および受信側に対して透過的に符号化し復号することができる。

各TTは、バインディングを作成すると、参照ラベルの受信側が常に参照ラベルを明確なセグメント・データで置き換えることができるようにグローバルに一意の参照ラベルを割り当てる。McCanne Iに記載されているように、一意の名前を保証するのにいくつかの方式が使用可能である。

HCSで実現可能なファイル・システム
本発明の他の態様は、ファイル・システム内でHCSを使用する。ファイル・システムの設計にHCSを適切に適用することにより、ファイル・システム内のすべてのファイル（およびデータ構造）にわたって繰り返されるデータのパターンを認識し、したがって、任意の所与のデータ・パターンを一度しかディスク上に記憶しないことによって容量を実質的に増やすことができる。HCSをファイル・システムにこのように導入する1つの手法は、HCSエンコーダおよびHCSデコーダをネイティブ・ファイル・システムのネイティブ構成要素として組み込むことである。たとえば、ファイル・システムがディスク・ブロックを読み取るかまたは書き込むときはいつでも、これらのディスク・ブロックにHCSを適用することができる。しかし、この直接的な手法は、多数のアプリケーションが高性能ファイル入出力を要求しているが、HCS符号化プロセスが計算上のオーバヘッドを導入する可能性があるときに性能上の問題を生じさせる恐れがある。さらに、HCSは、アプリケーションまたはファイル・データの互いに隣接した広い領域が与えられたときに最も効率的に働き、ファイル・システムの多数の実現態様は通常、比較的小さい固定サイズ・ブロックを用いてファイルを操作する。

より優れた手法は、ブロック・ベースのアクセスではなくファイル全体のアクセスを使用するファイル・システムにHCSを適用する手法である。図13に示されているシステムは、全ファイル・インタフェースを有するファイル・システムを実現し、HCSを導入する。すなわち、クライアントは、ファイルの個々の部分ではなくファイル全体を記憶し、検索し、削除する。この手法は通常、標準ファイル・システム・インタフェースをサポートできないが、たとえば、バックアップ・システムの基本としての、ファイル・システムの他の用途に適している。アクセスがネイティブ・ファイル・システムよりも低速であるが（テープに基づく）従来のバックアップ・システムよりも高速であるディスク・ベースのオンライン・バックアップ・システムは、高性能オンライン・ファイル・システムと低性能オフライン・バックアップ・システムとの間の妥協点を表す「ニアライン」記憶装置と呼ばれることが多い。したがって、本明細書では、図13に示されているファイル・システムを「ニアライン・ファイル・システム（NLFS）」と呼ぶ。

図示のモデルでは、クライアントはファイル全体を記憶し、検索し、削除することができる。NLFSは、HCSエンコーダ、PSS、およびHCSデコーダを用いて、共通する各セグメントの単一のコピーを一度記憶するだけでよいようにファイル・データを効率的に記憶する。さらに、NLFSは、「ファイル・マップ・データベース（FMDB）」と呼ばれるデータベース・テーブルを用いて、ファイル名を、特定のファイルを表すトップ・レベル・ラベルにマップする。一態様では、FMDBは、ファイル・システムが、様々な時点でのファイルを表す、同じファイルの複数のコピーを含むことができるように、タイム・スタンプ・フィールドを含む。

ファイル・システムは以下のように機能する。クライアントは、ファイル・システムに「STORE」コマンドを送信し、その後ファイル名およびファイル・データを送信することによってファイルを記憶または更新する。ファイル・システムは次いで、すべてのファイル・データをHCSエンコーダに送信し、HCSエンコーダは、記憶されているファイルを表す1つまたは複数のラベルを返す。これらのラベルは次いで、新しいファイルまたは更新済みのファイルを表す組の一部としてFMDBに入力される。この組には、対応するファイル名および（たとえば、時刻機構から得られた）現在のタイム・スタンプが含まれる。

クライアントは、ファイルを検索する場合、「RETRIEVE」コマンドをファイル名および任意のタイム・スタンプと一緒にファイル・システムに送信する。ファイル・システムは、ファイル名をキーとして含む問合せをFMDBに送信し、このファイル名を含むすべての組を検索する。そのような組がない場合、クライアントにエラーが返される。ファイル・システムは次いで、指定されたタイム・スタンプ以下の最大のタイム・スタンプを有する組を選択する。コマンドにタイム・スタンプが指定されていない場合、最大のタイム・スタンプを有する組が選択される。これは、要求された時間にシステムに記憶されていたファイルのバージョンを選択する効果を有する。次に、ファイル・システムは、選択された組から得たラベル・ストリングをHCSデコーダに送信する。HCSデコーダは、各ラベルをファイル・データに復号し、そのデータをファイル・システムに返す。ファイル・システムは次いで、ファイル・データをクライアントに返す。もちろん、このプロセスは、デコーダが復号済みのファイルをファイル・システムに供給するときにファイル・システムがクライアントにファイル・データを供給できるようにパイプライン化することができる。

クライアントは、ファイル・システムからファイルを削除する場合、「DELETE」コマンドをファイル名および任意の時間範囲と一緒にファイル・システムに送信し、指定された時間範囲に関して記憶されていたすべてのファイルを削除するよう指示する。これに応答して、NLFSは、FMDBを参照して対応するエントリをFMDBから削除し、PSSから対応するラベルを削除する。

一態様では、NLFS構成要素は、標準バックアップ・アーキテクチャに配置され、NDMPなどの標準プロトコルによってバックアップ・サービスを望むクライアントとのインタフェースをとる。

他の態様では、上述のNLFSをファイル・システム・フロント・エンドと組み合わせることによって、HCDをオペレーティング・システム・ベースのより標準的なファイル・システムの補構成要素として使用することができる。この手法は、NLFSおよびファイル・サーバ・フロント・エンドを示す図14に示されている。この手法では、1つまたは複数のクライアントが特定のファイルを開くときはいつでも、ファイル・サーバが、そのファイルをNLFSシステムから読み取り、ローカル・ファイル・システムにコピーする。このファイルは実際上、ローカル・フロント・エンド・ファイル・システムにキャッシングされ、それによってファイル・サーバは通常のファイル・システム・プロトコルおよびアルゴリズムを用いてオープン・ファイルを管理することができる。フロント・エンド・ファイル・サーバのみがNLFSと通信するようにし、通常のファイル・システム・ロッキング機構およびコンシスタンシー機構を用いることによって、NLFSに記憶されているファイルは、ファイル・サーバのローカル・ファイル・システム内のファイルに適合する。すべてのクライアントがファイルを閉じると、ファイル・サーバは、ファイルをNLFSに書き戻し、ローカル・ファイル・サーバ内の対応する記憶装置を解放する。

公知のファイル・システム設計技術および全ファイル・キャッシング技術に基づいてフロント・エンド・ファイル・サーバを構築する多数の方法があるが、一態様では、公知のユニックス・ファイル・システム（UFS）がNLFSとのインタフェースをとるように拡張される。たとえば、UFS（と他のファイル・システム）は、辞書を用いてファイル名をディスク・データ構造にマップする。UFSでは、ファイル用の辞書エントリは索引ノード（またはiノード）を指す。したがって、UFSは、ULFS内のファイルの参照を含む新しいiノード・タイプを含むように拡張することができる。この方式の下で、クライアントが既存のファイルを開くと、UFSは、この新しいiノード・タイプがあるかどうかを検査し、そのiノード・タイプがあるときは、NLFSからファイルを読み取る。UFSは次いで、返されたファイル・データをローカル・ファイル・システムに書き込み、実際上、通常のiノード・データ構造を用いてファイル・データをローカル・ディスク上にフォーマットする。実際上、NLFSを指す単一のiノードは、実際のファイルをローカルに表すように、多数のiノードおよびディスク・ブロックで置き換えられる。

この点で、クライアント・オープン・コールが終了する。その後、すべてのクライアント・ファイル活動が従来のUFSモデルと同様に進行し（複数のクライアントが同じファイルを同時に開く場合を含む）、あらゆるファイル更新または変更がローカル・ファイル・コピーに反映される。（すべてのクライアントｂによって）ファイルが閉じられると、修正されたUFSが、（通常のiノード・データ構造を用いて）ローカル・ファイル・システムからファイル・データを読み取り、このデータをNLFSに書き戻す。ファイルが首尾よく書き込まれると、ファイル・データを表すiノードを、解放し、NLFSを指す新しい種類の単一のノードで置き換えることができる。または、将来ファイルにアクセスする際にNLFSを待つ必要がなくなるように、ファイルのローカル・コピーを解放する必要なしにこのようにNLFSからファイルをコピーすることができる。次いで、ローカル・ファイル・システムが最大限までの充填を開始すると、UFSは、多数の公知のキャッシュ交換方式（たとえば、LRU（Least Recently Used）、LFA（Least Frequently Accessed）など）を適用することによって上述の方法を用いてファイルを解放することができる。

上記の説明は例示的なものであり制限的なものではない。当業者には、本開示を検討したときに本発明の多数の変形態様が明らかになると思われる。したがって、本発明の範囲は、上記の説明を参照して判定すべきではなく、添付の特許請求の範囲をその全範囲の等価物と共に参照して判定すべきである。

Claims

サーバでクライアントからのファイルを受信する段階；
ファイルを１又は複数の重なりのないセグメントにセグメント化する段階；
各セグメントが、セグメント・ストアに存在するかどうかを判定する段階であって、セグメント・ストアに存在するセグメントは割り当てられた参照ラベルを有している、段階と、
セグメント・ストア内に存在する各セグメントについて、リストに割り当てられた参照ラベルを加える段階と、及び
セグメント・ストア内に存在しない各セグメントについて、該セグメントに参照ラベルを割り当てる段階、該セグメントと該参照ラベルを記憶する段階、及び該参照ラベルをリストに加える段階
とを含む、リストを形成する段階；
ファイルとリストとの間の関連を記憶する段階
を含む、データを記憶するための方法。
セグメントと割り当てられた参照ラベルがセグメント・ストアにともに記憶されている、請求項１記載の方法。
参照ラベルはセグメントのコンテントと部分的に無関係である、請求項１記載の方法。
タイム・スタンプをリストに加える段階をさらに含む、請求項１記載の方法。
サーバは、ユニックス・ファイル・システム（UFS）であり、ファイル用のUFSの辞書エントリがセグメント・ストアを参照する、請求項１記載の方法。
セグメントの任意のシーケンスを参照グループとしてグループ分けするどうかを判定する段階を更に含み、
リストを形成する段階は、
参照グループが、セグメント・ストアに存在しているかどうかを判定する段階であって、該セグメント・ストアがセグメント・ストアに存在する参照グループの参照ラベルに対するグループ・ラベルを含む、段階；
セグメント・ストアに存在する各参照グループについて、グループ・ラベルをリストに加える段階；
セグメント・ストアに存在しない各参照グループについて、セグメント・ストアに存在しない参照グループセグメントに参照ラベルを割り当てる段階、参照グループセグメントと参照ラベルをセグメント・ストア内に記憶する段階、セグメント・ストア内のグループ・ラベルを記憶する段階、及びグループ・ラベルを参照グループの参照ラベルに割り当てる段階、セグメント・ストア内のグループ・ラベルを記憶する段階、及びグループ・ラベルをリストに加える段階
をさらに含む、
請求項１記載の方法。
以下を含む、データを記憶するためのシステム。
クライアントからのファイルを受信するためのサーバ；
ファイルを重なりのないセグメントにセグメント化するように構成されたセグメンタ；
リストを形成するためのエンコーダであって、
各セグメントがセグメント・ストア内に存在するかどうかを判定するように構成されたロジックであって、セグメント・ストア内に存在するセグメントは割り当てられた参照ラベルを有する、ロジック；
セグメント・ストア内に存在する各セグメントについて、リストに割り当てられた参照ラベルを加えるように構成されたロジック；及び
セグメント・ストア内に存在しない各セグメントについて、セグメントに参照ラベルを割り当て、セグメントと参照ラベルを記憶し、参照ラベルをリストに加えるように構成されたロジック；
を含むエンコーダ；及び
ファイルとリストとの間の関連を記憶するように構成されたロジック。
セグメントと割り当てられたラベルはセグメント・ストアにともに記憶されている、請求項７記載のシステム。
以下を含む、データを検索するための方法。
クライアントからのファイルに対する要求をサーバで受信する段階；
ファイルの重なりのないセグメントに対する参照ラベルからなるリストを検索する段階であって、該リストはファイルに関連している、段階；
該参照ラベルとファイルの重なりのないセグメントのコンテントを置き換える段階を含む、リストを復号する段階及び
該ファイルをサーバからクライアントに送信する段階。
以下を含む、ファイルのバックアップを実行するための方法。
バックアップ・システムで、バックアップすべき複数のファイルを受信する段階；
ファイルのコンテントに基づいて実行される、バックアップ・システムのセグメンタによって、各ファイルを１または複数の重なりのないセグメントにセグメント化する段階；
以下の(a)〜(c)を含む、各ファイル用のリストを形成する段階；
(a)各セグメントがセグメント・ストアに存在するかどうかを判定する段階であって、セグメント・ストアに存在するセグメントが割り当てられた参照ラベルを有する、段階；
(b)セグメント・ストアに存在する各セグメントについて、リストに割り当てられた参照ラベルを加える段階；
(c)セグメント・ストアに存在しない各セグメントについて、該セグメントに参照ラベルを割り当てる段階、セグメントと参照ラベルを記憶する段階、及び参照ラベルをリストに加える段階；及び
バックアップ・システムのデータベースで、各ファイルと対応するリストとの間の関連を記憶する段階。
ファイルのバックアップを実行するためのバックアップ・システムであって、該バックアップ・システムは、以下を含む、バックアップ・システム。
バックアップすべき複数のファイルを受信するためのインターフェース；
各ファイルを重なりのないセグメントにセグメント化するように構成されたセグメンタ；
以下の(a)〜(c)を含む、各ファイル用のリストを形成するためのエンコーダ；
(a)各セグメントがセグメント・ストアに存在するかどうかを判定するように構成されたロジックであって、セグメント・ストアに存在するセグメントが割り当てられた参照ラベルを有する、ロジック；
(b)セグメント・ストアに存在する各セグメントについて、リストに割り当てられた参照ラベルを加えるように構成されたロジック；
(c)セグメント・ストアに存在しない各セグメントについて、該セグメントに参照ラベルを割り当て、セグメントと参照ラベルを記憶し、及び参照ラベルをリストに加えるように構成されたロジック；及び
各ファイルと対応するリストとの間の関連を記憶するためのロジック。
ファイルを1つ又は複数の重なりのないセグメントにセグメント化する段階は、ファイルのコンテントに基づいて実行される、請求項１〜６及び１０の何れか１項記載の方法。
セグメンタは、ファイルのコンテントに基づき、ファイルを重なりのないセグメントにセグメント化するように構成された、請求項７、８及び１１の何れか１項記載のシステム。