(57)【特許請求の範囲】
【請求項１】
無損失データ削減を実行するための方法であって、前記方法は、
データ構造に含まれる複数の基本データエレメントの中から、データチャンクに基づく１つ以上の基本データエレメントを識別することを備え、
前記データ構造は、前記複数の基本データエレメントの名前に基づいて、昇順または降順に前記複数の基本データエレメントを組織化し、
前記識別することは、前記データチャンクの名前を用いて前記データ構造内をナビゲートすることによって、前記１つ以上の基本データエレメントを識別することを含み、前記方法はさらに、
再構成プログラムを前記１つ以上の基本データエレメントに適用することによって前記データチャンクが再構成され得るように、前記データチャンクおよび前記１つ以上の基本データエレメントに基づいて前記再構成プログラムを決定することと、
前記データチャンクの無損失削減表現を生成することとを備え、前記無損失削減表現は、前記１つ以上の基本データエレメント内の各基本データエレメントの参照と、前記再構成プログラムの記述とを含む、方法。
【請求項２】
前記データ構造はツリーデータ構造であり、前記データ構造内をナビゲートすることは、前記ツリーデータ構造内の一連のエッジを横断することを備え、前記一連のエッジ内の各エッジは、前記データチャンクの名前の一部に対応し、前記ツリーデータ構造内のノードにナビゲートするために用いられる前記名前の各部分は、前記ノードをルートとするサブツリー内のすべての基本データエレメント内に存在するコンテンツに対応する、請求項１に記載の方法。
【請求項３】
前記データチャンクの名前を用いて前記データ構造内をナビゲートすることは、前記データチャンクの名前の連続する部分を用いることによって前記データ構造内をナビゲートすることを含む、請求項１に記載の方法。
【請求項４】
前記データチャンクの前記無損失削減表現を生成することは、（ｉ）前記１つ以上の基本データエレメントの参照のサイズと、（ii）前記再構成プログラムの前記記述のサイズとの合計が前記データチャンクのサイズの所定割合未満であると判断したことに応答して行われ、
前記方法はさらに、（ｉ）前記１つ以上の基本データエレメントの前記参照の前記サイズと、（ii）前記再構成プログラムの前記記述の前記サイズとの合計が前記データチャンクの前記サイズの前記所定割合以上であると判断したことに応答して、
前記データチャンクを、前記データ構造内の新たな基本データエレメントとして追加することと、
前記データチャンクの第２の無損失削減表現を生成することとを備え、前記第２の無損失削減表現は前記新たな基本データエレメントの参照を含む、請求項１に記載の方法。
【請求項５】
前記再構成プログラムの前記記述は一連の変換を指定し、前記一連の変換が前記１つ以上の基本データエレメントに適用されると、前記データチャンクがもたらされる、請求項１に記載の方法。
【請求項６】
前記再構成プログラムの前記記述は、再構成プログラムストアに記憶されている第２の再構成プログラムの参照を含み、前記第２の再構成プログラムは一連の変換を指定し、前記一連の変換が前記１つ以上の基本データエレメントに適用されると、前記データチャンクがもたらされる、請求項１に記載の方法。
【請求項７】
前記再構成プログラムの前記記述は、再構成プログラムストアに記憶されている第２の再構成プログラムの参照と、第３の再構成プログラムの記述とを含み、前記第３の再構成プログラムが前記第２の再構成プログラムに適用されると一連の変換がもたらされ、前記一連の変換が前記１つ以上の基本データエレメントに適用されると、前記データチャンクがもたらされる、請求項１に記載の方法。
【請求項８】
前記方法はさらに、
前記データチャンクの前記無損失削減表現を記憶装置に記憶することと、
前記記憶装置から前記データチャンクの前記無損失削減表現を受信することとを備え、前記無損失削減表現は、前記１つ以上の基本データエレメントの参照と、前記再構成プログラムの前記記述とを含み、前記方法はさらに、
前記１つ以上の基本データエレメントの前記参照に基づいて、前記データ構造から前記１つ以上の基本データエレメントを取出すことと、
前記再構成プログラムを前記１つ以上の基本データエレメントに適用することによって前記データチャンクを生成することとを備える、請求項１に記載の方法。
【請求項９】
前記方法はさらに、入力データを固定サイズのデータチャンクに因数分解することを備える、請求項１に記載の方法。
【請求項１０】
前記方法はさらに、入力データを可変サイズのデータチャンクに因数分解することを備える、請求項１に記載の方法。
【請求項１１】
前記可変サイズのデータチャンクの境界は、フィンガープリンティングプロセスを前記入力データに適用することによって決定される、請求項１０に記載の方法。
【請求項１２】
前記データチャンクの前記無損失削減表現をネットワーク上で送信することと、
前記データ構造を前記ネットワーク上で送信することとをさらに備え、前記データ構造は、前記データチャンクの前記無損失削減表現を送信する前に、送信するのと同時に、または送信した後に送信される、請求項１に記載の方法。
【請求項１３】
無損失データ削減を実行するための装置であって、
データ構造に含まれる複数の基本データエレメントの中から、データチャンクに基づく１つ以上の基本データエレメントを識別するための手段を備え、
前記データ構造は、前記複数の基本データエレメントの名前に基づいて、昇順または降順に前記複数の基本データエレメントを組織化し、
前記識別するための手段は、前記データチャンクの名前を用いて、前記データ構造内をナビゲートすることによって前記１つ以上の基本データエレメントを識別し、前記装置はさらに、
再構成プログラムを前記１つ以上の基本データエレメントに適用することによって前記データチャンクが再構成され得るように、前記データチャンクおよび前記１つ以上の基本データエレメントに基づいて前記再構成プログラムを決定するための手段と、
前記データチャンクの無損失削減表現を生成するための手段とを備え、前記無損失削減表現は、前記１つ以上の基本データエレメント内の各基本データエレメントの参照と、前記再構成プログラムの記述とを含む、装置。
【請求項１４】
前記データ構造はツリーデータ構造であり、前記データ構造内をナビゲートすることは、前記ツリーデータ構造内の一連のエッジを横断することを備え、前記一連のエッジ内の各エッジは、前記データチャンクの名前の一部に対応し、前記ツリーデータ構造内のノードにナビゲートするために用いられる前記名前の各部分は、前記ノードをルートとするサブツリー内のすべての基本データエレメント内に存在するコンテンツに対応する、請求項１３に記載の装置。
【請求項１５】
前記データチャンクの前記無損失削減表現をネットワーク上で送信するための手段と、
前記データ構造を前記ネットワーク上で送信するための手段とをさらに備え、前記データ構造は、前記データチャンクの前記無損失削減表現を送信する前に、送信するのと同時に、または送信した後に送信される、請求項１３に記載の装置。
【発明の詳細な説明】
【技術分野】
【０００１】
背景
技術分野
本開示はデータの記憶、取出し、および通信に関する。より具体的には、本開示はコンテンツ連想シーブ（sieve）を用いるデータの無損失削減に関する。
【背景技術】
【０００２】
関連技術
現代の情報化時代は、莫大な量のデータの作成、取得、および分析を特徴とする。新たなデータは多様なソースから生成され、その例として、購入取引記録、企業および政府の記録および通信、電子メール、ソーシャルメディアの投稿、デジタル写真および映像、マシンログ、埋込装置からの信号、デジタルセンサ、携帯電話全地球測位衛星、宇宙衛星、科学計算、ならびにグランドチャレンジ科学がある。データは多様なフォーマットで生成され、そのほとんどは構造化されておらず、旧来のデータベースへのエントリに適していない。企業、政府、および個人は前例のないほどの速度でデータを生成しており、このデータを記憶、分析、および通信するのに苦労している。蓄積されるデータを保持するストレージシステムの購入に年間何百億ドルという費用が費やされている。データを処理するコンピュータシステムにも同様の多額の費用が費やされている。
【０００３】
最新型のコンピュータおよびストレージシステムにおいて、データは、ストレージ階層として組織化される、複数のストレージ層にわたって収容されデプロイされる。頻繁かつ迅速にアクセスする必要があるデータは、最も高価であるが最速の層に入れられるが、データの大部分（バックアップ用のコピーを含む）は、最も密度が高く最も安価な記憶媒体に記憶されることが好ましい。最速および最も高価なデータストレージ層は、コンピュータシステムの揮発性ランダムアクセスメモリまたはＲＡＭであり、これはマイクロプロセッサコアに近接して存在しており、データのランダムアクセスのための最低待ち時間および最高帯域幅を提供する。漸進的に密度が高くなり安価になるが遅くなる層（ランダムアクセスの漸進的に高くなる待ち時間および低くなる帯域幅を有する）として、不揮発性ソリッドステートメモリまたはフラッシュストレージ、ハードディスクドライブ（ＨＤＤ）、および最後にテープドライブがある。
【０００４】
増加するデータをより効果的に記憶して処理するために、コンピュータ業界はデータ記憶媒体の密度および速度、ならびにコンピュータの処理能力を向上させ続けている。しかし、データ量の増加はコンピューティングおよびデータストレージシステムの容量および密度の向上をはるかに上回っている。２０１４年のデータストレージ業界からの統計では、過去数年間に作成されて取得された新たなデータは、これまでに世界中で取得されたデータの大半を含むことが明らかになっている。今日まで世界中で作成されたデータの量は数ゼタバイト（ゼタバイトは１０21バイトである）を超えると見積もられている。データの大幅な増加は、このデータを確実に記憶、処理、および通信しなければならないデータ記憶、計算、および通信システムに大きな要求を突き付けている。これは、データを低コストで記憶し、同様に効率的に処理して通信することができるようにデータを圧縮する、無損失データ削減または圧縮技術の使用の増加の動機付けとなっている。
【０００５】
さまざまな無損失データ削減または圧縮技術が長年にわたって生まれて進化してきた。これらの技術は、データを調べてデータ内に何らかの形態の冗長を探し、その冗長を利用して、情報を損失することなくデータフットプリントの削減を実現する。データ内の特定の形態の冗長を利用することを試みる所与の技術について、達成されるデータ削減の程度は、その特定の形態の冗長がどれほど頻繁にデータ内に見つかるかに依存する。データ削減技術は、データ内のいずれかの利用可能な冗長を柔軟に発見して利用することが可能であることが望ましい。データは多種多様なソースおよび環境からさまざまなフォーマットで生じるため、この多様なデータを取扱う汎用無損失データ削減技術の開発および採用に大きい関心が集まっている。汎用データ削減技術は、アルファベット以外の入力データの予備知識が不要な技術である。したがって、これは一般的に、データの構造および統計的分布特性を予め知る必要なしに、あらゆるデータに適用可能である。
【０００６】
データ圧縮技術のさまざまな実現例同士を比較するために用いられ得る適合度メトリクスとして、ターゲットデータセット上で達成されるデータ削減の程度、圧縮または削減が達成される効率、およびデータが将来の使用のために復元されて取出される効率がある。効率メトリクスは、ソリューションのパフォーマンスおよびコスト効果を評価する。パフォーマンスメトリクスとして、新たなデータが消費され削減され得るスループットまたは取込速度、入力データを削減するのに必要な待ち時間または時間、データが復元され取出され得るスループットまたは速度、およびデータを復元して取出すのに必要な待ち時間または時間がある。コストメトリクスとして、マイクロプロセッサコアまたはマイクロプロセッサ利用（中央処理装置利用）といった、必要ないずれかの専用ハードウェアコンポーネントのコスト、専用スクラッチメモリおよびメモリ帯域幅の量、ならびにデータを保持するさまざまなストレージ層から要求されるアクセス回数および帯域幅がある。なお、効率的で迅速な圧縮ならびに復元および取出しを同時に提供しつつデータのフットプリントを削減することには、データを記憶して通信するための全体のコストを削減するだけでなく、その後のデータの処理を効率的に可能にするという利点もある。
【０００７】
業界で現在使用されている汎用データ圧縮技術の多くは、Abraham LempelおよびJacob Zivによって１９７７年に開発されたLempel-Ziv圧縮法に由来する。たとえば、Jacob Ziv and Abraham Lempel, "A Universal Algorithm for Sequential Data Compression," IEEE transactions on information theory, Vol. IT-23, NO. 3, May 1997参照。この方法は、インターネットを介した効率的なデータ送信を可能にする基礎となった。Lempel-Ziv法（LZ77、LZ78およびそれらの変形と名付けられる）は、繰返し発生する文字列を、シーケンシャルに提示される入力データストリームのスライディングウインドウ内に見られる以前の発生の参照で置換することによって、データフットプリントを削減する。入力データストリームからの所与のデータブロックから新規な文字列を消費すると、これらの技術は、最大でウインドウの長さまで、現在のおよび以前のブロック内で以前に見られたすべての文字列を検索する。新規な文字列が重複である場合、それは元の文字列の逆方向参照で置換される。重複文字列によって除去されるバイトの数が逆方向参照に必要なバイトの数よりも大きければ、データの削減が達成されている。ウインドウ内に見えるすべての文字列を検索するために、かつ最大の文字列一致を提供するために、これらの技術の実現例では、反復走査を含み、かつウインドウ内に見えるすべての文字列の辞書を含む一時的な帳簿構造を構築する、さまざまなスキームを使用する。新たな入力バイトを消費して新規な文字列をアセンブルすると、これらの技術は、既存のウインドウ内の全バイトを走査するか、または、文字列の辞書の参照を作成し（その後何らかの計算を行ない）、重複が見つかったか否かを決定し、重複を逆方向参照で置換する（あるいは、辞書に追加が必要か否かを決定する）。
【０００８】
Lempel-Ziv圧縮法は、データに適用される第２の最適化を伴うことが多く、この最適化では、ソースシンボルが、圧縮中のデータブロック内のソースシンボルの発生の頻度または確率に基づいて動的に再符号化され、より短い長さのコードがより頻繁なシンボルに用いられることによってデータを削減できるように可変幅符号化スキームが使用されることが多い。たとえば、David A. Huffman, "A Method for the Construction of Minimum-Redundancy Codes," Proceedings of the IRE-Institute of Radio Engineers, Sep. 1952, pp. 1098-1101参照。この技術はハフマン再符号化と称され、典型的に、頻度を計算するための１回目のデータの通過、およびデータを実際に符号化するための２回目の通過を必要とする。この主題に沿ったいくつかの変形も使用されている。
【０００９】
これらの技術を用いる一例は、Lempel-Ziv LZ77圧縮法をハフマン再符号化と組合せた「Deflate」として知られるスキームである。Deflateは、バイトのシーケンスを（通常はより短い）ビットのシーケンスとして表わすための方法、および後者のビットシーケンスをバイトにパックするための方法を指定する、圧縮ストリームデータフォーマット仕様を提供する。Deflateスキームは本来、PKZIPアーカイブユーティリティのためにPKWARE, Inc.社のPhillip W. Katzによって設計された。たとえば、"String searcher, and compressor using same," Phillip W. Katz、米国特許第５，０５１，７４５号（１９９１年９月２４日）参照。米国特許第５，０５１，７４５号には、予め定められたターゲット文字列（入力文字列）を求めてシンボルのベクトル（ウインドウ）を検索するための方法が記載されている。このソリューションは、ウインドウ内のシンボル毎にポインタを有するポインタアレイを使用しており、ハッシング方法を用いて、入力文字列の同一コピーを求めて検索する必要があるウインドウ内の可能性のある場所をフィルタする。その後、それらの場所で走査および文字列一致が行なわれる。
【００１０】
Deflateスキームは、データ圧縮用のzlibライブラリにおいて実現される。zlibは、Linux（登録商標）、Mac OS X、iOSといったいくつかのソフトウェアプラットフォーム、およびさまざまなゲーミングコンソールの主要なコンポーネントであるソフトウェアライブラリである。zlibライブラリは、zip（ファイルアーカイビング）、gzip（単一ファイル圧縮）、png（無損失圧縮画像のためのポータブルネットワークグラフィックス）、および多くの他のアプリケーションによって使用されるDeflate圧縮および復元コードを提供する。zlibは今や、データ送信および記憶のために幅広く使用されている。サーバおよびブラウザによるほとんどのＨＴＴＰトランザクションは、zlibを用いてデータを圧縮して復元する。同様の実装はデータストレージシステムによってますます使用されつつある。
【００１１】
２０１４年４月にインテル社が発表した「High Performance ZLIB Compression on Intel（登録商標）Architecture Processors」と題された論文は、現在のインテルプロセッサ（コアＩ７  ４７７０プロセッサ、３．４ＧＨｚ、８ＭＢキャッシュ）上で動作し、かつデータのカルガリーコーパスに対して実行されるzlibライブラリの最適化バージョンの圧縮およびパフォーマンスを特徴化している。zlibで用いられるDeflateフォーマットは、一致用の最小文字列長さを３文字に設定し、最大一致長さを２５６文字に設定し、ウインドウのサイズを３２キロバイトに設定している。この実装は９レベルの最適化についての制御を提供し、レベル９は最高圧縮を提供するが計算の大部分を使用して最も網羅的な文字列の一致を実行し、レベル１は最速レベルであり、貪欲な文字列一致を使用する。この論文は、zlibレベル１（最速レベル）を使用し、シングルスレッドプロセッサを使用し、平均１７．６６クロック／バイトの入力データを消費して、５１％の圧縮率を報告している。３．４ＧＨｚのクロック周波数では、これは、単一のマイクロプロセッサコアを使い果たしつつ１９２ＭＢ／秒の取込速度を意味する。この報告ではさらに、パフォーマンスが、適度な圧縮のゲインのために最適化レベル６を用いると３８ＭＢ／秒の取込速度（平均８８．１クロック／バイト）に、最適化レベル９を用いると１６ＭＢ／秒の取込速度（平均２０９．５クロック／バイト）に急激に低下することが記載されている。
【００１２】
既存のデータ圧縮ソリューションは典型的に、現在のマイクロプロセッサ上でシングルプロセッサコアを用いて１０ＭＢ／秒から２００ＭＢ／秒の範囲の取込速度で動作する。取込速度をさらに高めるためには、複数のコアを使用するか、またはウインドウサイズを減少させる。コストは増加するが、カスタムハードウェアアクセラレータを用いると、取込速度のさらなる向上が達成される。
【００１３】
上記の既存のデータ圧縮法は、典型的に１つのメッセージもしくはファイル、または場合によってはいくつかのファイルのサイズであるローカルウインドウ内の短い文字列および記号のレベルで細かい冗長を利用するのに効果的である。これらの方法は、大型または超大型データセット上で動作し、かつ高速のデータ取込みおよびデータ取出しを必要とするアプリケーションで用いられる場合、重大な制限および欠点がある。
【００１４】
１つの重要な制限は、これらの方法の実際的な実現例が、ローカルウインドウ内でしか冗長を効率的に利用できないことである。これらの実現例は、任意に長いデータの入力ストリームを随意に受付けることができるが、効率のため、細かい冗長を発見すべきウインドウのサイズに制限が課される。これらの方法は高度に計算集約的であり、ウインドウ内のすべてのデータへの頻繁かつ迅速なアクセスを必要とする。さまざまな帳簿構造の文字列一致およびルックアップは、新規な入力文字列を作成する新規な１バイト（またはいくつかのバイト）の入力データを消費するとトリガされる。所望の取込速度を達成するために、文字列一致のためのウインドウおよび関連の機械はほとんどがプロセッサキャッシュサブシステム内に存在している必要があり、これによって実際面でウインドウサイズに制約が課される。
【００１５】
たとえば、シングルプロセッサコア上で２００ＭＢ／秒の取込速度を達成するためには、利用可能な平均タイムバジェット／取込バイト（すべてのデータアクセスおよび計算を含む）は５ｎｓ．であり、つまり、３．４ＧＨｚの動作周波数で現在のプロセッサを用いて１７クロックである。このバジェットは、（少数のサイクルを占める）オンチップキャッシュへのアクセスを収容し、その後、何らかの文字列一致が行なわれる。現在のプロセッサは、数メガバイトの容量のオンチップキャッシュを有する。メインメモリへのアクセスは２００サイクル（〜７０ｎｓ．）を占めるため、ほとんどがメモリ内に存在する大きいウインドウは取込速度をさらに遅くさせる。また、ウインドウサイズが増加するにつれて、かつ重複文字列までの距離が増加するにつれて、逆方向参照の長さを指定するコストも増加するため、重複を求めてより長い文字列のみがより広い範囲全体にわたって検索されることが促進される。
【００１６】
ほとんどの現在のデータストレージシステム上では、ストレージ階層のさまざまな層にわたって記憶されるデータのフットプリントは、システム内のメモリ容量より数桁大きい。たとえば、システムが数百ギガバイトのメモリを提供し得るのに対して、フラッシュストレージ内に存在するアクティブデータのデータフットプリントは数十テラバイトであり得、ストレージシステム内の全データは数百テラバイトから数ペタバイトの範囲であり得る。また、後続のストレージ層へのデータアクセスの達成可能なスループットは、後続の層毎に１桁以上減少する。スライディングウインドウが大きくなり過ぎてメモリに収まらなくなると、これらの技術は、かなり低い帯域幅、およびデータ記憶の次のレベルへのランダムなＩＯ（入力または出力操作）アクセスの高い待ち時間によって抑圧される。
【００１７】
たとえば、既存のデータ内に既に存在しており２５６テラバイトのフットプリントにわたって分散している、たとえば平均長さが４０バイトの１００個の文字列を参照することによって当該データからアセンブルされ得る４キロバイトの受信データのファイルまたはページを考えてみる。各参照には、４０バイトを保存することを約束しつつ、そのアドレスを指定するために６バイト、文字列長さに１バイトを要する。この例で述べるページは５倍よりも大きく圧縮可能であるが、このページについての取込速度は、（これらの文字列が存在する場所を完全にかつ安価に予想できたとしても）１００個の重複文字列をフェッチして検証するのに必要なストレージシステムへの１００回以上のＩＯアクセスによって制限されることになる。２５０，０００回のランダムなＩＯアクセス／秒（４ＫＢのページへの１ＧＢ／秒の帯域幅のランダムアクセスを意味する）を提供するストレージシステムは、ストレージシステムの全帯域幅を使い果たしつつ、わずか１０ＭＢ／秒の取込速度のために毎秒４ＫＢのサイズのそのようなページを２，５００枚しか圧縮できないため、ストレージシステムとして利用不可能である。
【００１８】
テラバイトまたはペタバイトのオーダの大きいウインドウサイズを用いる従来の圧縮法の実現例は、ストレージシステムへのデータアクセスの帯域幅減少によって不足しており、許容できないほど遅い。したがって、これらの技術の実際的な実現例は、プロセッサキャッシュまたはシステムメモリに収まるウインドウサイズに対して、冗長が局所的に存在している場合にのみ冗長を効率的に発見して利用する。冗長データが受信データから空間的にまたは時間的に数テラバイト、ペタバイト、またはエクサバイトだけ離れている場合、これらの実現例は許容可能な速度で冗長を発見することができなくなり、ストレージアクセス帯域幅によって制限される。
【００１９】
従来の方法の別の制限は、それら方法がデータのランダムアクセスに適していないことである。いずれかのブロック内のいずれかのチャンクにアクセスできるようにする前に、圧縮されたウインドウ全体に跨っているデータのブロックを復元しなければならない。これは、ウインドウのサイズに実際的な制限を課す。また、旧来は非圧縮データに対して行なわれる操作（たとえば検索操作）を圧縮データに対して効率的に行なうことができない。
【００２０】
従来の方法（および特にLempel-Zivに基づく方法）のさらに別の制限は、それら方法が、同一文字列を逆方向参照で置換する、１つの次元のみに沿って冗長があるか検索することである。ハフマン再符号化スキームの制限は、周波数を計算して次に再符号化するためにデータを２回通過しなければならないことである。これは、ブロックが大きくなると遅くなる。
【００２１】
データのグローバルストア全体にわたって長い重複文字列を検出するデータ圧縮法は、デジタルフィンガープリンティングとハッシングスキームとの組合せを用いることが多い。この圧縮プロセスはデータ重複排除と称される。データ重複排除の最も基本的な技術は、ファイルを固定サイズのブロックに分割し、データレポジトリ全体にわたって重複ブロックを探す。ファイルのコピーが作成されると、第１のファイル内の各ブロックは第２のファイル内に重複を有することになり、当該重複は元のブロックの参照で置換され得る。潜在的な重複ブロック同士の一致を迅速化するために、ハッシングの方法が使用される。ハッシュ関数は、文字列をそのハッシュ値と称される数値にコンバートする関数である。２つの文字列同士が等しい場合、それらのハッシュ値同士も等しい。ハッシュ関数は複数の文字列を所与のハッシュ値にマップし、これによって長い文字列をはるかに短い長さのハッシュ値に減少させることができる。ハッシュ値同士の一致は、２つの長い文字列同士の一致よりもはるかに速くなる。したがって、ハッシュ値同士の一致がまず行なわれて、重複であり得る可能性のある文字列がフィルタされる。入力文字列またはブロックのハッシュ値が、レポジトリ内に存在する文字列またはブロックのハッシュ値と一致する場合、入力文字列は次に同一のハッシュ値を有するレポジトリ内の各文字列と比較されて重複の存在が確認され得る。
【００２２】
ファイルを固定サイズのブロックに分割することは単純で簡便であり、固定サイズのブロックは高パフォーマンスのストレージシステムにおいて非常に望ましい。しかし、この技術は、それが発見可能な冗長の量に制限があり、つまり、これらの技術は圧縮レベルが低い。たとえば、第１のファイルのコピーが第２のファイルを作成するために作られた場合、１バイトのデータでさえも第２のファイルに挿入されると、すべての下流ブロックの整列が変更され、新たな各ブロックのハッシュ値が新たに計算され、データ重複排除法はすべての重複を見つけることができなくなる。
【００２３】
データ重複排除法におけるこの制限に対処するために、業界では、一致するコンテンツの場所でデータストリームを同期させ整列させるフィンガープリンティングの使用が採用されている。この後者のスキームでは、フィンガープリントに基づいて可変サイズのブロックがもたらされる。Michael Rabinは、ランダムに選択した既約多項式を用いてビット文字列をフィンガープリントできることを示している。たとえば、Michael O. Rabin, "Fingerprinting by Random Polynomials," Center for Research in Computing Technology, Harvard University, TR-15-81, 1981参照。このスキームでは、ランダムに選択された素数ｐを用いて、長い文字列を、大きい整数モジュロｐと見なされるその文字列の剰余を計算することによってフィンガープリントする。このスキームでは、ｋビット整数に対して整数演算を行う必要があり、ここでｋ＝ｌｏｇ2（ｐ）である。あるいは、オーダｋのランダムな既約素数多項式を用いてもよく、その場合、フィンガープリントは素数多項式のデータモジュロの多項式表現である。
【００２４】
このフィンガープリンティングの方法はデータ重複排除システムにおいて用いられ、チャンク境界を確立すべき好適な位置を特定することによって、当該システムがグローバルレポジトリ内のこれらのチャンクの重複を探すことができる。チャンク境界は、特定値のフィンガープリントが見つかると設定され得る。そのような使用の例として、フィンガープリントは、オーダ３２以下の多項式を使用することによって、入力データ内の４８バイト文字列毎に（入力の最初のバイトで始まり、次いで、その後は連続バイト毎に）計算され得る。次いで、３２ビットフィンガープリントの下位１３ビットを調べて、それら１３ビットの値が予め指定された値（たとえば値１）であるたびにブレークポイントを設定することができる。ランダムデータについては、その１３ビットがその特定値を有する可能性は２13分の１であるため、そのようなブレークポイントはおよそ８ＫＢ毎に遭遇する可能性が高く、平均サイズが８ＫＢの可変サイズのチャンクがもたらされる。ブレークポイントまたはチャンク境界は、データのコンテンツに依存するフィンガープリントと効果的に整列することになる。フィンガープリントが長時間見つからない場合、ブレークポイントを何らかの予め指定された閾値で強制することができるので、システムは、レポジトリについて予め指定されたサイズよりも短いチャンクを確実に作成する。たとえば、Athicha Muthitacharoen, Benjie Chen and David Mazieres, "A Low-bandwidth Network File System," SOSP '01, Proceedings of the eighteenth ACM symposium on Operating Systems Principles, 10/21/2001, pp. 174-187参照。
【００２５】
Michael RabinおよびRichard Karpによって開発されたラビン−カープ（Rabin-Karp）文字列一致技術は、フィンガープリンティングおよび文字列一致の効率をさらに向上させた（たとえば、Michael O. Rabin and R. Karp, "Efficient Randomized Pattern-Matching Algorithms," IBM Jour. of Res. and Dev., Vol. 31, 1987, pp. 249-260参照）。なお、そのフィンガープリントについてのｍバイト部分文字列を調べるフィンガープリンティング法は、フィンガープリンティング多項式関数をＯ（ｍ）時間で評価し得る。この方法は、たとえばｎバイト入力ストリームの各バイトで始まる部分文字列に適用される必要があるので、データストリーム全体に対してフィンガープリンティングを行なうのに必要な全労力はＯ（ｎ×ｍ）となる。ラビン−カープはローリングハッシュと称されるハッシュ関数を特定しており、これに対して、部分文字列の長さとは無関係に一定数の演算のみを行なうことによって、前の部分文字列から次の部分文字列のハッシュ値を計算することができる。したがって、右に１バイトシフトした後、新たなｍバイト文字列に対するフィンガープリントの計算を増分的に行なうことができる。これによって、フィンガープリントを計算する労力がＯ（１）に、データストリーム全体をフィンガープリントするための全労力がＯ（ｎ）に、データのサイズと直線的に減少する。これによって、フィンガープリントの計算および識別が大きく迅速化される。
【００２６】
上記のデータ重複排除法についての典型的なデータアクセスおよび計算要件は以下のように説明することができる。所与の入力について、フィンガープリンティングが完了してチャンクが作成されると、当該チャンクのハッシュ値が計算された後、これらの方法はまず、すべてのチャンクのハッシュ値をレポジトリ内に維持するグローバルハッシュテーブルを検索してルックアップするために、メモリおよび後続のストレージ層への１セットのアクセスを必要とする。これは典型的に、ストレージへの１回目のＩＯアクセスを必要とする。ハッシュテーブル内に一致があると、続いて２回目の一組のストレージＩＯ（典型的に１回であるが、同一のハッシュ値を有するチャンクがどのくらいレポジトリ内に存在するかに依存して２回以上であり得る）が行われて、同一のハッシュ値を有する実際のデータチャンクがフェッチされる。最後に、バイト単位の一致が行われ、入力されたチャンクがフェッチされた潜在的に一致するチャンクと比較されて重複が確認され識別される。この後、新たな重複ブロックをオリジナルの参照で置換するための（メタデータ空間への）３回目のストレージＩＯアクセスが行なわれる。グローバルハッシュテーブル内に一致がない場合（または重複が見つからない場合）、システムは、新たなブロックをレポジトリに入力するために１回のＩＯ、およびグローバルハッシュテーブルを更新して新たなハッシュ値を入力するためにさらにもう１回のＩＯを必要とする。ゆえに、大型データセットについては（メタデータおよびグローバルハッシュテーブルがメモリに収まらず、したがってそれらにアクセスするためにストレージＩＯを必要とする場合）、そのようなシステムは入力チャンク毎に平均３回のＩＯを必要とし得る。グローバルハッシュテーブルにアクセスするための１回目のストレージＩＯを必要とせずにグローバルハッシュテーブル内の欠落を検出できるようにさまざまなフィルタを使用して、チャンクのうちのいくつかを処理するのに必要なＩＯの回数を２回にまで削減することによって、さらなる向上が可能である。
【００２７】
２５０，０００回のランダムＩＯアクセス／秒（４ＫＢのページへの１ＧＢ／秒のランダムアクセスの帯域幅を意味する）を提供するストレージシステムは、毎秒４ＫＢの平均サイズの約８３,３３３個（入力チャンク毎に３回のＩＯで分割される２５０，０００個）の入力チャンクを取込んで重複排除することによって、ストレージシステムの全帯域幅を使い果たしつつ３３３ＭＢ／秒の取込速度を可能にする。ストレージシステムの帯域幅の半分のみが用いられる（したがって残りの半分は記憶データへのアクセスに利用可能である）場合も、そのような重複排除システムはやはり１６６ＭＢ／秒の取込速度を提供可能である。これらの取込速度（Ｉ／Ｏ帯域幅によって制限される）は、十分な処理能力がシステムで利用可能であるという条件で達成可能である。ゆえに、十分な処理能力を前提として、データ重複排除システムは、無駄のないＩＯでデータのグローバル範囲全体にわたってデータの大きい重複を見つけることができ、現在のストレージシステムに対して数百メガバイト／秒の取込速度でデータ削減を提供することができる。
【００２８】
上記の説明に基づいて、これらの重複排除法はグローバル範囲全体にわたって長い文字列の重複を見つけるのに効果的であるが、それらは主に大きい重複を見つけるのに効果的であることが明確であるべきである。より細かくデータに変形または変更がある場合は、利用可能な冗長はこの方法を用いて見つけられない。これによって、これらの方法が有用なデータセットの幅が大きく減少する。これらの方法は、たとえば、バックアップ中の新たなデータが変更されるファイルをほんのわずかしか有しておらず、残りはすべて以前のバックアップで保存されたファイルの重複である、定期的なデータのバックアップなどの、一定のデータストレージシステムおよびアプリケーションに使用されている。同様に、データ重複排除に基づくシステムは、データセンタにおける仮想環境といった、データまたはコードの複数の完全なコピーが作られる環境でデプロイされることが多い。しかし、データが発展して、より一般的にまたはより細かく変更されるにつれて、データ重複排除に基づく技術はその有効性が失われつつある。
【００２９】
いくつかのアプローチ（通常はデータバックアップアプリケーションで使用される）では、入力データと入力のハッシュ値と一致するハッシュ値を有する文字列との間の実際のバイト単位の比較が行なわれない。そのようなソリューションは、ＳＨＡ−１などの強いハッシュ関数を用いて低い衝突可能性に依拠する。しかし、（複数の異なる文字列同士が同一のハッシュ値にマップし得る）衝突の有限のゼロでない可能性のため、そのような方法は無損失データ削減を提供すると見なすことができず、したがって、プライマリストレージおよび通信の高いデータ完全性要件を満たさない。
【００３０】
いくつかのアプローチでは、複数の既存のデータ圧縮技術同士が組合される。典型的に、そのようなセットアップでは、まずグローバルデータ重複排除法がデータに適用される。続いて、重複排除されたデータセットに対して、小さいウインドウを使用して、ハフマン再符号化と組合されたLempel-Ziv文字列圧縮法が適用されてさらなるデータ削減が達成される。
【００３１】
しかし、これまでに知られているすべての技術の利用にも係わらず、増加して蓄積されるデータの必要性と、世界経済が最良の利用可能な現代のストレージシステムを用いて手軽に収容できるものとの間には桁違いの大きさのギャップが存在し続けている。増加するデータが要求する記憶容量の並外れた要件を考慮すると、データのフットプリントをさらに削減する改良された方法が必要であり続けている。既存の技術の制限に対処する、または既存の技術が対処していない次元に沿ったデータ内の利用可能な冗長を利用する方法を開発することが必要であり続けている。同時に、許容可能な速度で、かつ許容可能な処理コストで効率的にデータにアクセスしてデータを取出すことが可能であることも重要であり続けている。
【００３２】
要約すると、大型および超大型データセット全体にわたって冗長を利用し、高速のデータ取込みおよびデータ取出しを提供することができる無損失データ削減ソリューションが長年にわたって切実に求められ続けている。
【発明の概要】
【課題を解決するための手段】
【００３３】
概要
本明細書に記載の実施形態は、高速のデータ取込みおよびデータ取出しを提供しつつ、大型および超大型データセットに対する無損失データ削減を実行可能な、かつ既存のデータ圧縮システムの欠点および制限を受けない技術およびシステムを特徴とする。
【００３４】
具体的には、いくつかの実施形態では、データチャンクに基づいて１つ以上の基本データエレメントを識別することができ、識別することは、データチャンクのコンテンツを用いて、基本データエレメントのコンテンツに基づいて基本データエレメントを組織化するデータ構造内をナビゲートすることを含む。次に、実施形態では、再構成プログラムを１つ以上の基本データエレメントに適用することによってデータチャンクが再構成され得るように、データチャンクおよび識別した１つ以上の基本データエレメントに基づいて再構成プログラムを決定することができる。実施形態では次いで、データチャンクの無損失削減表現を生成することができ、無損失削減表現は、識別した１つ以上の基本データエレメント内の各基本データエレメントの参照と、再構成プログラムの記述とを含む。
【図面の簡単な説明】
【００３５】
【図１Ａ】本明細書に記載のいくつかの実施形態に従う、入力データをエレメントに因子分解し、これらを基本データストアに存在している基本データエレメントから導出するデータ削減のための方法および装置を示す図である。
【図１Ｂ】本明細書に記載のいくつかの実施形態に従う、図１Ａに示す方法および装置の変形を示す図である。
【図１Ｃ】本明細書に記載のいくつかの実施形態に従う、図１Ａに示す方法および装置の変形を示す図である。
【図１Ｄ】本明細書に記載のいくつかの実施形態に従う、図１Ａに示す方法および装置の変形を示す図である。
【図１Ｅ】本明細書に記載のいくつかの実施形態に従う、図１Ａに示す方法および装置の変形を示す図である。
【図１Ｆ】本明細書に記載のいくつかの実施形態に従う、図１Ａに示す方法および装置の変形を示す図である。
【図１Ｇ】本明細書に記載のいくつかの実施形態に従う、図１Ａに示す方法および装置の変形を示す図である。
【図１Ｈ】本明細書に記載のいくつかの実施形態に従う、蒸留データの構造を記述するフォーマットおよび仕様の例を提示する図である。
【図１Ｉ】図１Ａから図１Ｇに示すデータ削減のための方法および装置の変形についての入力データの無損失削減形態への概念的な変換を示す図である。
【図１Ｊ】図１Ａから図１Ｇに示すデータ削減のための方法および装置の変形についての入力データの無損失削減形態への概念的な変換を示す図である。
【図１Ｋ】図１Ａから図１Ｇに示すデータ削減のための方法および装置の変形についての入力データの無損失削減形態への概念的な変換を示す図である。
【図１Ｌ】図１Ａから図１Ｇに示すデータ削減のための方法および装置の変形についての入力データの無損失削減形態への概念的な変換を示す図である。
【図１Ｍ】図１Ａから図１Ｇに示すデータ削減のための方法および装置の変形についての入力データの無損失削減形態への概念的な変換を示す図である。
【図１Ｎ】図１Ａから図１Ｇに示すデータ削減のための方法および装置の変形についての入力データの無損失削減形態への概念的な変換を示す図である。
【図１Ｏ】図１Ａから図１Ｇに示すデータ削減のための方法および装置の変形についての入力データの無損失削減形態への概念的な変換を示す図である。
【図１Ｐ】図１Ａから図１Ｇに示すデータ削減のための方法および装置の変形についての入力データの無損失削減形態への概念的な変換を示す図である。
【図２】本明細書に記載のいくつかの実施形態に従う、入力データをエレメントに因子分解し、これらエレメントを基本データストア内に存在する基本データエレメントから導出することによるデータ削減のためのプロセスを示す図である。
【図３Ａ】本明細書に記載のいくつかの実施形態に従う、基本データエレメントをそれらの名前に基づいて組織化するために用いられ得るデータ組織システムを示す図である。
【図３Ｂ】本明細書に記載のいくつかの実施形態に従う、基本データエレメントをそれらの名前に基づいて組織化するために用いられ得るデータ組織システムを示す図である。
【図３Ｃ】本明細書に記載のいくつかの実施形態に従う、基本データエレメントをそれらの名前に基づいて組織化するために用いられ得るデータ組織システムを示す図である。
【図３Ｄ】本明細書に記載のいくつかの実施形態に従う、基本データエレメントをそれらの名前に基づいて組織化するために用いられ得るデータ組織システムを示す図である。
【図３Ｅ】本明細書に記載のいくつかの実施形態に従う、基本データエレメントをそれらの名前に基づいて組織化するために用いられ得るデータ組織システムを示す図である。
【図３Ｆ】本明細書に記載のいくつかの実施形態に従う自己記述ツリーノードデータ構造を提示する図である。
【図３Ｇ】本明細書に記載のいくつかの実施形態に従う自己記述リーフノードデータ構造を提示する図である。
【図３Ｈ】本明細書に記載のいくつかの実施形態に従うナビゲーションルックアヘッドフィールドを含む自己記述リーフノードデータ構造を提示する図である。
【図４】本明細書に記載のいくつかの実施形態に従う、２５６ＴＢの基本データがどのようにツリー形態に組織化され得るかの例を示し、当該ツリーがどのようにメモリおよびストレージ内にレイアウトされ得るかを提示する図である。
【図５Ａ】本明細書に記載の実施形態を用いてデータがどのように組織化され得るかの実際の例を示す図である。
【図５Ｂ】本明細書に記載の実施形態を用いてデータがどのように組織化され得るかの実際の例を示す図である。
【図５Ｃ】本明細書に記載の実施形態を用いてデータがどのように組織化され得るかの実際の例を示す図である。
【図６Ａ】本明細書に記載のいくつかの実施形態に従う、図１Ａを参照して説明したコンテンツ連想マッパーについてツリーデータ構造がどのように使用され得るかを示す図である。
【図６Ｂ】本明細書に記載のいくつかの実施形態に従う、図１Ｂを参照して説明したコンテンツ連想マッパーについてツリーデータ構造がどのように使用され得るかを示す図である。
【図６Ｃ】本明細書に記載のいくつかの実施形態に従う、図１Ｃを参照して説明したコンテンツ連想マッパーについてツリーデータ構造がどのように使用され得るかを示す図である。
【図７Ａ】本明細書に記載のいくつかの実施形態に従う、再構成プログラム内に指定され得る変換の例を提供する図である。
【図７Ｂ】本明細書に記載のいくつかの実施形態に従う、基本データエレメントから導出されている候補エレメントの結果の例を示す図である。
【図８Ａ】本明細書に記載のいくつかの実施形態に従う、入力データを固定サイズのエレメントに因子分解し、当該エレメントを図３Ｄおよび図３Ｅを参照して説明したツリーデータ構造に組織化することによって、どのようにデータ削減が実行され得るかを示す図である。
【図８Ｂ】本明細書に記載のいくつかの実施形態に従う、入力データを固定サイズのエレメントに因子分解し、当該エレメントを図３Ｄおよび図３Ｅを参照して説明したツリーデータ構造に組織化することによって、どのようにデータ削減が実行され得るかを示す図である。
【図８Ｃ】本明細書に記載のいくつかの実施形態に従う、入力データを固定サイズのエレメントに因子分解し、当該エレメントを図３Ｄおよび図３Ｅを参照して説明したツリーデータ構造に組織化することによって、どのようにデータ削減が実行され得るかを示す図である。
【図８Ｄ】本明細書に記載のいくつかの実施形態に従う、入力データを固定サイズのエレメントに因子分解し、当該エレメントを図３Ｄおよび図３Ｅを参照して説明したツリーデータ構造に組織化することによって、どのようにデータ削減が実行され得るかを示す図である。
【図８Ｅ】本明細書に記載のいくつかの実施形態に従う、入力データを固定サイズのエレメントに因子分解し、当該エレメントを図３Ｄおよび図３Ｅを参照して説明したツリーデータ構造に組織化することによって、どのようにデータ削減が実行され得るかを示す図である。
【図９Ａ】本明細書に記載のいくつかの実施形態に従う、図１Ｃに示すシステムに基づくData Distillation（商標）スキームの例を示す図である。
【図９Ｂ】本明細書に記載のいくつかの実施形態に従う、図１Ｃに示すシステムに基づくData Distillation（商標）スキームの例を示す図である。
【図９Ｃ】本明細書に記載のいくつかの実施形態に従う、図１Ｃに示すシステムに基づくData Distillation（商標）スキームの例を示す図である。
【図１０Ａ】本明細書に記載のいくつかの実施形態に従う、再構成プログラム内に指定された変換がどのように基本データエレメントに適用されて導出エレメントをもたらすかの例を提供する図である。
【図１０Ｂ】本明細書に記載のいくつかの実施形態に従うデータ取出しプロセスを示す図である。
【図１０Ｃ】本明細書に記載のいくつかの実施形態に従うデータ取出しプロセスを示す図である。
【図１１Ａ−１１Ｆ】本明細書に記載のいくつかの実施形態に従う、Data Distillation（商標）メカニズム（ソフトウェア、ハードウェア、またはそれらの組合せを用いて実現され得る）を含むシステムを示す図である。
【図１１Ｇ】本明細書に記載のいくつかの実施形態に従う、Data Distillation（商標）メカニズム（ソフトウェア、ハードウェア、またはそれらの組合せを用いて実現され得る）を含むシステムを示す図である。
【図１１Ｈ】本明細書に記載のいくつかの実施形態に従う、Data Distillation（商標）装置がどのようにサンプル汎用計算プラットフォームに干渉し得るかを示す図である。
【図１２Ａ】本明細書に記載のいくつかの実施形態に従う、帯域幅が制約された通信媒体全体にわたるデータの通信のためのData Distillation（商標）装置の使用を示す図である。
【図１２Ｂ】本明細書に記載のいくつかの実施形態に従う、帯域幅が制約された通信媒体全体にわたるデータの通信のためのData Distillation（商標）装置の使用を示す図である。
【図１２Ｃ】本明細書に記載のいくつかの実施形態に従う、さまざまな使用モデルについてData Distillation（商標）装置によって生成される削減データのさまざまなコンポーネントを示す図である。
【図１２Ｄ】本明細書に記載のいくつかの実施形態に従う、さまざまな使用モデルについてData Distillation（商標）装置によって生成される削減データのさまざまなコンポーネントを示す図である。
【図１２Ｅ】本明細書に記載のいくつかの実施形態に従う、さまざまな使用モデルについてData Distillation（商標）装置によって生成される削減データのさまざまなコンポーネントを示す図である。
【図１２Ｆ】本明細書に記載のいくつかの実施形態に従う、さまざまな使用モデルについてData Distillation（商標）装置によって生成される削減データのさまざまなコンポーネントを示す図である。
【図１２Ｇ】本明細書に記載のいくつかの実施形態に従う、さまざまな使用モデルについてData Distillation（商標）装置によって生成される削減データのさまざまなコンポーネントを示す図である。
【図１２Ｈ】本明細書に記載のいくつかの実施形態に従う、さまざまな使用モデルについてData Distillation（商標）装置によって生成される削減データのさまざまなコンポーネントを示す図である。
【図１２Ｉ】本明細書に記載のいくつかの実施形態に従う、さまざまな使用モデルについてData Distillation（商標）装置によって生成される削減データのさまざまなコンポーネントを示す図である。
【図１２Ｊ】本明細書に記載のいくつかの実施形態に従う、さまざまな使用モデルについてData Distillation（商標）装置によって生成される削減データのさまざまなコンポーネントを示す図である。
【図１２Ｋ】本明細書に記載のいくつかの実施形態に従う、さまざまな使用モデルについてData Distillation（商標）装置によって生成される削減データのさまざまなコンポーネントを示す図である。
【発明を実施するための形態】
【００３６】
詳細な説明
以下の説明は、当業者が本発明を行って用いることができるように提示されており、特定の用途およびその要件の文脈において提供されている。開示される実施形態に対するさまざまな変更が当業者に容易に明らかとなり、本明細書に定義される一般原理は本発明の精神および範囲から逸脱することなく他の実施形態および用途にも適用され得る。ゆえに、本発明は示される実施形態に限定されず、本明細書に開示される原理および特徴と一致した最も広範な範囲が与えられる。本開示において、ある語句が「および／または」という語を一組のエンティティとともに用いる場合、当該語句は特に記載のない限りその一組のエンティティのすべての可能性のある組合せを包含する。たとえば、「Ｘ、Ｙ、および／またはＺ」という語句は、「Ｘのみ」、「Ｙのみ」、「Ｚのみ」、「Ｚを含まないＸおよびＹ」、「Ｙを含まないＸおよびＺ」、「Ｘを含まないＹおよびＺ」、ならびに「Ｘ、Ｙ、およびＺ」の７個の組合せを包含する。
【００３７】
コンテンツ連想シーブを用いたデータの効率的な無損失削減
本明細書に記載のいくつかの実施形態では、データセット全体にわたってグローバルに冗長を効率的に発見して利用するようにデータが組織化されて記憶される。入力データストリームはエレメントと称される構成片またはチャンクに分割され、エレメント同士間の冗長がエレメント自体よりも細かく検出され利用されることによって、記憶データのフットプリント全体が削減される。基本データエレメントと称される一組のエレメントが識別されてデータセットのための共通および共有の構築ブロックとして用いられ、基本データストアまたはシーブと称される構造に記憶される。基本データエレメントは単に、一定サイズのビット、バイト、または桁のシーケンスである。基本データエレメントは、実現例に依存して固定サイズであってもよく、または可変サイズであってもよい。入力データの他の構成要素が基本データエレメントから導出されて導出エレメント（Derivative Element）と称される。ゆえに、入力データは基本データエレメントおよび導出エレメントに因子分解される。
【００３８】
基本データストアは、基本データストアをコンテンツ連想的に検索してアクセスできるように、基本データエレメントを順序付けて組織化する。何らかの入力コンテンツを前提として、いくつかの制限を伴い、基本データストアに問合わせて、そのコンテンツを含む基本データエレメントを取出すことができる。入力エレメントを前提として、当該エレメントの値、または当該エレメント内の一定のフィールドの値を用いて基本データストアを検索して、１つのまたは小さい一組の基本データエレメントを迅速に提供することができ、そこから、導出を指定するのに必要な最小ストレージで入力エレメントを導出することができる。いくつかの実施形態では、基本データストア内のエレメントはツリー形態に組織化される。基本データエレメントに対して変換を実行することによって基本データエレメントから導出エレメントが導出され、そのような変換は、１つ以上の基本データエレメントから導出エレメントをどのように生成するかを記述する再構成プログラム内に指定されている。距離閾値が、導出エレメントの記憶フットプリントのサイズに対する制限を指定する。この閾値は、基本データエレメントからの導出エレメントの最大許容距離を指定し、また、導出エレメントを生成するために用いられ得る再構成プログラムのサイズに制限を課す。
【００３９】
導出データの取出しは、導出によって指定される１つ以上の基本データエレメントに対して再構成プログラムを実行することによって達成される。
【００４０】
本開示では、上記の汎用無損失データ削減技術はData Distillation（商標）プロセスと称され得る。これは、化学の蒸留と同様の、混合物をその構成要素に分離する機能を果たす。基本データストアは、シーブまたはData Distillation（商標）シーブとも称される。
【００４１】
このスキームでは、入力データストリームはエレメントのシーケンスに因子分解され、各エレメントは、基本データエレメント、または１つ以上の基本データエレメントから導出される導出エレメントである。各エレメントは無損失削減表現に変換され、これは、基本データエレメントの場合は基本データエレメントの参照を含み、導出エレメントの場合は、導出に伴う１つ以上の基本データエレメントの参照と、再構成プログラムの記述とを含む。ゆえに、入力データストリームは、無損失削減表現内にあるエレメントのシーケンスに因子分解される。この（無損失削減表現内に現われる）エレメントのシーケンスは、蒸留データストリームまたは蒸留データと称される。蒸留データ内のエレメントのシーケンスは、入力データ内のエレメントのシーケンスと１対１の対応関係を有しており、すなわち、蒸留データ内のエレメントのシーケンス内のｎ番目のエレメントは、入力データ内のエレメントのシーケンス内のｎ番目のエレメントに対応する。
【００４２】
本開示に記載の汎用無損失データ削減技術は、入力データストリームを受信し、蒸留データストリームおよび基本データストアのフットプリントの合計が入力データストリームのフットプリントよりも通常は小さいように、入力データストリームを蒸留データストリームと基本データストアとの組合せにコンバートする。本開示では、蒸留データストリームおよび基本データストアは無損失削減データと総称され、同じ意味で「削減データストリーム」または「削減データ」とも称される。同様に、本開示に記載の無損失データ削減技術によって生成され、かつ無損失削減フォーマットで現われるエレメントのシーケンスについて、「削減出力データストリーム」、「削減出力データ」、「蒸留データストリーム」、および「蒸留データ」という語は同じ意味で用いられる。
【００４３】
図１Ａは、本明細書に記載のいくつかの実施形態に従う、入力データをエレメントに因子分解し、これらを基本データストアに存在している基本データエレメントから導出するデータ削減のための方法および装置を示す。この図はデータ削減またはData Distillation（商標）方法および装置の全体ブロック図を示しており、機能コンポーネント、構造、および演算の概要を提供している。図１Ａに示すコンポーネントおよび／または演算はソフトウェア、ハードウェア、またはそれらの組合せを用いて実現され得る。
【００４４】
バイトのシーケンスが入力データストリームから受信され、Data Distillation（商標）装置とも称されるデータ削減装置１０３に入力データ１０２として提示される。パーサおよび因子分解部１０４が受信データをパースし、当該データをチャンクまたは候補エレメントに分割する。因子分解部は、入力ストリーム内のどこにブレークを挿入してストリームを候補エレメントにスライスアップするかを決定する。データ内の連続する２つのブレークが識別されると、候補エレメント１０５がパーサおよび因子分解部によって作成され、Data Distillation（商標）シーブとも称される基本データストア１０６に提示される。
【００４５】
Data Distillation（商標）シーブまたは基本データストア１０６は、（図１ＡにおいてＰＤＥとラベル付けされている）すべての基本データエレメントを含んでおり、それらの値またはコンテンツに基づいてそれらを順序付けて組織化する。シーブは２種類のアクセスのサポートを提供する。第１に、基本データエレメントの各々には、基本データエレメントがシーブ内に存在する場所の参照によって、直接アクセス可能である。第２に、エレメントには、ソフトウェア、ハードウェア、またはそれらの組合せで実現され得るコンテンツ連想マッパー１２１を用いることによって、コンテンツ連想的にアクセス可能である。シーブへのこの第２のアクセス形態は、候補エレメント１０５と完全に一致する基本データエレメントを識別するために、または、候補エレメントをそこから導出可能な基本データエレメントを識別するために、開示される実施形態によって用いられる重要な特徴である。具体的には、たとえば候補エレメント１０５などの候補エレメントを前提として、基本データストア１０６を（候補エレメント１０５の値に基づいて、または候補エレメント１０５内の一定のフィールドの値に基づいて）検索して、１つのまたは小さい一組の基本データエレメント１０７を迅速に提供することができ、そこから、導出を指定するのに必要な最小ストレージで候補エレメントを導出することができる。
【００４６】
シーブまたは基本データストア１０６は、その値がデータ空間にわたって分散している一組の基本データエレメントで初期化され得る。あるいは、シーブは空で開始してもよく、図１Ａ〜図１Ｃおよび図２を参照して本明細書に記載されるData Distillation（商標）プロセスに従って、データが取込まれるにつれて基本データエレメントがシーブに動的に追加されてもよい。
【００４７】
導出部１１０は、候補エレメント１０５と、（基本データストア１０６から連想的に取出されるコンテンツである）導出に好適な取出された基本データエレメント１０７とを受信し、候補エレメント１０５がこれらの基本データエレメントの１つ以上から導出可能であるか否かを判断し、削減されたデータコンポーネント１１５（関連の基本データエレメントの参照および再構成プログラムで構成される）を生成し、基本データストアの更新１１４を提供する。候補エレメントが、取出された基本データエレメントの重複である場合、導出部は、基本データストア内にある基本データエレメントの参照（またはポインタ）と、これが基本データエレメントであるというインジケータとを、蒸留データ１０８に入れる。重複が見つからない場合、導出部は、候補エレメントを、１つ以上の取出された基本データエレメントに対して実行された１つ以上の変換の結果として表現し、この一連の変換は、たとえば再構成プログラム１１９Ａなどの再構成プログラムと総称される。各導出では、その固有のプログラムを導出部によって構築する必要があり得る。再構成プログラムは、基本データエレメントに適用可能な挿入、削除、置換、連結、算術、および論理演算といった変換を指定する。導出エレメントのフットプリント（再構成プログラムのサイズに、必要な基本データエレメントの参照のサイズを加えたものとして計算される）が（データ削減を可能にするための）候補エレメントに関して一定の指定された距離閾値内にあるという条件で、候補エレメントは導出エレメントとして再公式化され、再構成プログラムと１つの（または複数の）関連の基本データエレメントの参照との組合せで置換され、この場合、これらは削減されたデータコンポーネント１１５を形成する。閾値を超えた場合、または基本データストアから好適な基本データエレメントが取出されなかった場合、基本データストアは候補を新規な基本データエレメントとしてインストールするように指示され得る。この場合、導出部は、新たに追加された基本データエレメントの参照と、さらに、これが基本データエレメントであるというインジケータとを蒸留データに入れる。
【００４８】
データの取出し要求（たとえば取出し要求１０９）は、基本データエレメントを含む基本データストア内の場所の参照の形態、または、導出物（Derivative）の場合には、基本データエレメントのそのような参照と、関連付けられた再構成プログラムとの組合せ（または複数の基本データエレメントに基づく導出物の場合は、複数の基本データエレメントの参照と、関連付けられた再構成プログラムとの組合せ）の形態であり得る。基本データストア内の基本データエレメントの１つ以上の参照を用いて、取出部１１１は基本データストアにアクセスして１つ以上の基本データエレメントをフェッチし、１つ以上の基本データエレメントおよび再構成プログラムを再構成部１１２に与えることができ、再構成部１１２は、（再構成プログラム内に指定されている）変換を１つ以上の基本データエレメントに対して実行して再構成されたデータ１１６（要求されたデータ）を生成し、それをデータ取出し要求に応答して取出されたデータ出力１１３に供給する。
【００４９】
本実施形態の変形では、基本データエレメントは、（ハフマン符号化およびLempel Ziv法を含む先行技術において公知の技術を用いて）圧縮形態でシーブに記憶され、必要に応じて復元されてもよい。これには、基本データストアのフットプリント全体を削減するという利点がある。唯一の制約は、コンテンツ連想マッパー１２１が、前と同様に基本データエレメントへのコンテンツ連想アクセスを提供し続けなければならないことである。
【００５０】
図１Ｂおよび図１Ｃは、本明細書に記載のいくつかの実施形態に従う、図１Ａに示す方法および装置の変形を示す。図１Ｂでは、再構成プログラムは基本データストアに記憶されて基本データエレメントとして取扱われ得る。再構成プログラム１１９Ａ自体を提供する代わりに、再構成プログラムの参照またはポインタ１１９Ｂが蒸留データ１０８内に提供される。再構成プログラムが他の導出物によって共有される場合、および、再構成プログラムの参照またはポインタ（さらに、再構成プログラムと再構成プログラムの参照とを区別するために必要な任意のメタデータを加えたもの）のストレージスペースが再構成プログラム自体よりも小さくて済む場合、さらなるデータ削減が達成される。
【００５１】
図１Ｂでは、再構成プログラムは基本データエレメントと同様に取扱われてアクセスされ、基本データエレメントとして基本データストアに記憶されることによって、基本データストアからの再構成プログラムのコンテンツ連想検索および取出しが可能になり得る。導出エレメントを作成する導出プロセスの際、導出部１１０が導出に必要な再構成プログラムを決定すると、導出部１１０は次いで、この候補再構成プログラムが基本データストア内に既に存在しているか否か、またはこの候補再構成プログラムが基本データストア内に既に存在している別のエントリから導出可能であるか否かを判断し得る。候補再構成プログラムが基本データストア内に既に存在している場合は、導出部１１０は既存のエントリの参照を決定し、当該参照を蒸留データ１０８に含めることができる。候補再構成プログラムが基本データストアに既に存在している既存のエントリから導出可能である場合、導出部は候補再構成プログラムの導出物または再公式化を蒸留データに供給し得、すなわち、導出部は、基本データストア内に予め存在しているエントリの参照を、この予め存在しているエントリから候補再構成プログラムを導出する増分的な再構成プログラムとともに、蒸留データに入れる。候補再構成プログラムが基本データストア内に存在しておらず、基本データストアへのエントリからも導出不可能である場合は、導出部１１０は再構成プログラムを基本データストアに追加し（再構成プログラムをストアに追加する演算は、新たに追加されたエントリの参照を戻し得る）、再構成プログラムの参照を蒸留データ１０８に含めることができる。
【００５２】
図１Ｃは、本明細書に記載のいくつかの実施形態に従う、図１Ｂに示す方法および装置の変形を提示する。具体的には、再構成プログラムを記憶して再構成プログラムに問合せるために用いられる図１Ｃのメカニズムは、基本データエレメントを記憶して基本データエレメントに問合せるために用いられるメカニズムと同様であるが、再構成プログラムは、基本データエレメントを含む構造とは別の構造内に維持される。そのような構造へのエントリは、基本再構成プログラム（図１ＣにおいてＰＲＰとラベル付けされている）と称される。基本データストア１０６は、迅速なコンテンツ連想ルックアップ操作をサポートするコンテンツ連想マッパー１２１を含んでいることを思い起こされたい。図１Ｃに示す実施形態は、コンテンツ連想マッパー１２１と同様のコンテンツ連想マッパー１２２を含む。図１Ｃでは、コンテンツ連想マッパー１２２およびコンテンツ連想マッパー１２１は基本データストアまたはシーブ１０６の一部であるとして示されている。他の実施形態では、コンテンツ連想マッパー１２２および再構成プログラムは基本データストアまたはシーブ１０６とは別に記憶されてもよい。
【００５３】
本実施形態の変形では、基本データエレメントは、（ハフマン符号化およびLempel Ziv法を含む先行技術において公知の技術を用いて）圧縮形態でシーブに記憶され、必要に応じて復元されてもよい。同様に、基本再構成プログラムは、（ハフマン符号化およびLempel Ziv法を含む先行技術において公知の技術を用いて）圧縮形態で基本再構成プログラムシーブに記憶され、必要に応じて復元されてもよい。これには、基本データシーブおよび基本再構成プログラムシーブのフットプリント全体を削減するという利点がある。唯一の制約は、コンテンツ連想マッパー１２１および１２２が、前と同様に基本データエレメントおよび基本再構成プログラムへのコンテンツ連想アクセスを提供し続けなければならないことである。
【００５４】
図１Ｄは、本明細書に記載のいくつかの実施形態に従う、図１Ａに示す方法および装置の変形を提示する。具体的には、図１Ｄに記載の実施形態では、基本データエレメントは蒸留データ内にインラインに記憶されている。基本データシーブまたは基本データストア１０６は基本データエレメントへのコンテンツ連想アクセスを提供し続け、基本データエレメントを論理的に包含し続ける。それは、蒸留データ内にインラインに配置されている基本データエレメントの参照またはリンクを維持する。たとえば、図１Ｄでは、基本データエレメント１３０は蒸留データ１０８内にインラインに配置されている。基本データシーブまたは基本データストア１０６は基本データエレメント１３０の参照１３１を維持する。ここでも、このセットアップにおいて、導出エレメントの無損失削減表現は、必要な基本データエレメントの参照を含む。データ取出し時、取出部１１１は、必要な基本データエレメントをその配置場所からフェッチする。
【００５５】
図１Ｅは、本明細書に記載のいくつかの実施形態に従う、図１Ｄに示す方法および装置の変形を提示する。具体的には、図１Ｅに記載の実施形態では、図１Ｂに示すセットアップと同様に、再構成プログラムが他の基本再構成プログラムから導出され、増分再構成プログラムに基本再構成プログラムの参照を加えたものとして指定され得る。そのような基本再構成プログラムは基本データエレメントと同様に取扱われ、基本データシーブに論理的にインストールされる。さらに、このセットアップでは、基本データエレメントおよび基本再構成プログラムの両方が蒸留データ内にインラインに記憶される。基本データシーブまたは基本データストア１０６は、基本データエレメントおよび基本再構成プログラムのコンテンツ連想アクセスを提供し続け、これら基本データエレメントおよび基本再構成プログラムを、それらが蒸留データ内にインラインに配置されている場所の参照またはリンクを維持しつつ、論理的に包含し続ける。たとえば、図１Ｅでは、基本データエレメント１３０は蒸留データ１０８内にインラインに配置されている。また図１Ｅでは、基本再構成プログラム１３２は蒸留データ内にインラインに配置されている。基本データシーブまたは基本データストア１０６は、基本データエレメント１３０（PDE_i）の参照１３１（Reference_to_PDE_i）、および基本再構成プログラム１３２（Prime_Recon_Program_l）の参照１３３（Reference_to_PDE_j）を維持する。ここでも、このセットアップにおいて、導出エレメントの無損失削減表現は、必要な基本データエレメントおよび必要な基本再構成プログラムの参照を含む。データ取出しの際、取出部１１１は、必要なコンポーネントを、対応する蒸留データ内のそれらの配置場所からフェッチする。
【００５６】
図１Ｆは、本明細書に記載のいくつかの実施形態に従う、図１Ｅに示す方法および装置の変形を提示する。具体的には、図１Ｆに記載の実施形態では、図１Ｃに示すセットアップと同様に、基本データシーブ１０８は別個のマッパー、すなわち、基本データエレメントのためのコンテンツ連想マッパー１２１、および基本再構成プログラムのためのコンテンツ連想マッパー１２２を含む。
【００５７】
図１Ｇは、図１Ａから図１Ｆに示す方法および装置のより一般化した変形を提示する。具体的には、図１Ｇに記載の実施形態では、基本データエレメントは基本データシーブ内に、または蒸留データ内にインラインに配置され得る。いくつかの基本データエレメントは基本データシーブ内に配置され得、他の基本データエレメントは蒸留データ内にインラインに配置される。同様に、基本再構成プログラムは基本データシーブ内に、または蒸留データ内にインラインに配置され得る。いくつかの基本再構成プログラムは基本データシーブ内に配置され得、他の基本再構成プログラムは蒸留データ内にインラインに配置される。基本データシーブは、すべての基本データエレメントおよび基本再構成プログラムを論理的に包含しており、基本データエレメントまたは基本再構成プログラムが蒸留データ内にインラインに配置されている場合は、基本データシーブはその場所の参照を供給する。
【００５８】
入力データをエレメントに因子分解し、これらを基本データストアに存在している基本データエレメントから導出するデータ削減のための方法および装置の上記の説明は、例示および説明目的で提示されているに過ぎない。それらは網羅的であること、または本発明を開示された形態に限定することを意図していない。したがって、多くの変更および変形が当業者に明らかになるであろう。
【００５９】
図１Ｈは、本明細書に記載のいくつかの実施形態に従う、Data Distillation（商標）プロセスのための方法および装置の図１Ａの蒸留データ１１９Ａの構造を記述するフォーマットおよび仕様の例を提示する。Data Distillation（商標）プロセスは入力データを基本データエレメントおよび導出エレメントに因子分解するので、データの無損失削減表現のためのフォーマットはこれらエレメントを識別し、蒸留データ内のこれらのエレメントのさまざまなコンポーネントを記述する。自己記述フォーマットは蒸留データ内の各レコードを識別し、それが基本データエレメントであるか導出エレメントであるかを指示し、さまざまなコンポーネント、すなわち、シーブにインストールされる１つ以上の基本データエレメントの参照、基本データストアにインストールされる再構成プログラムの参照（図１Ｂの１１９Ｂのように）、または再構成プログラム（ＲＰ）ストアに記憶される再構成プログラム（図１Ｃの１１９Ｃのように）、およびインラインの再構成プログラム（ＲＰ）の参照を記述する。再構成プログラム（ＲＰ）ストアは、同じ意味で基本再構成プログラム（ＰＲＰ）ストアとも称される。図１Ｈのフォーマットは、複数の基本データエレメントに対して再構成プログラムを実行することによって導出を指定する規定を有し、導出エレメントおよび基本データエレメントの各々のサイズは独立して指定可能である。図１Ｈのフォーマットはさらに、基本データストア内に配置されるのではなく蒸留データ内にインラインに配置されている基本データエレメントを指定する規定を有する。これは、エレメントのタイプが、蒸留データ内にインラインに配置されている基本データエレメントであることを指定するオペコード符号化７によって指定される。蒸留データは、このフォーマットを用いてデータストレージシステムに記憶される。このフォーマットのデータは、当該データのさまざまなコンポーネントがフェッチされた後に再構成され得るように、データ取出部１１１によって消費される。
【００６０】
図１Ｉから図１Ｐは、図１Ａから図１Ｇに示すデータ削減のための方法および装置の変形についての入力データの無損失削減形態への概念的な変換を示す。図１Ｉは、どのように入力データのストリームが候補エレメントに因子分解され、続いて、候補エレメントが基本データエレメントまたは導出エレメントと見なされるかを示す。最後に、データは無損失削減形態に変換される。図１Ｉから図１Ｎは、さまざま実施形態についての無損失削減形態の変形を示す。
【００６１】
図１Ｉから図１Ｊは、図１Ａに示す方法および装置によって生成されるデータの無損失削減形態の例を示す。図１Ｉの無損失削減形態はコンテンツ連想マッパーを含んでおり、データの連続的なさらなる取込み、および既存の基本データエレメントに対するこのデータの削減を可能にする形態である。一方、図１Ｊの無損失削減形態はコンテンツ連想マッパーをもはや保持しておらず、より小さいフットプリントのデータがもたらされる。図１Ｋおよび図１Ｌは、図１Ｃに示す方法および装置によって生成されるデータの無損失削減形態の例を示す。図１Ｋの無損失削減形態はコンテンツ連想マッパーを含んでおり、データの連続的なさらなる取込み、ならびに既存の基本データエレメントおよび基本再構成プログラムに対するこのデータの削減を可能にする形態である。一方、図１Ｌの無損失削減形態はコンテンツ連想マッパーをもはや保持しておらず、より小さいフットプリントのデータがもたらされる。
【００６２】
図１Ｍおよび図１Ｎは、図１Ｆに示す方法および装置によって生成されるデータの無損失削減形態の例を示しており、基本データエレメントおよび基本再構成プログラムは蒸留データ内にインラインに配置されている。図１Ｍの無損失削減形態はコンテンツ連想マッパーを含んでおり、データの連続的なさらなる取込み、ならびに既存の基本データエレメントおよび基本再構成プログラムに対するこのデータの削減を可能にする形態である。一方、図１Ｎの無損失削減形態はコンテンツ連想マッパーをもはや保持しておらず、より小さいフットプリントのデータがもたらされる。図１Ｏおよび図１Ｐは、図１Ｇに示す方法および装置によって生成されるデータの無損失削減形態の例を示しており、基本データエレメントおよび基本再構成プログラムは蒸留データ内にインラインに、または基本データシーブ内に配置され得る。図１Ｏの無損失削減形態はコンテンツ連想マッパーを含んでおり、データの連続的なさらなる取込み、ならびに既存の基本データエレメントおよび基本再構成プログラムに対するこのデータの削減を可能にする形態である。一方、図１Ｐの無損失削減形態はコンテンツ連想マッパーをもはや保持しておらず、より小さいフットプリントのデータがもたらされる。
【００６３】
図１Ａから図１Ｐに示す実施形態の変形では、削減データのさまざまなコンポーネントは、（ハフマン符号化およびLempel Ziv法といった）先行技術において公知の技術を用いてさらに削減または圧縮され、この圧縮形態で記憶されてもよい。これらのコンポーネントは続いて、それらがデータ蒸留装置での使用に必要となったときに圧縮され得る。これには、データのフットプリント全体をさらに削減するという利点がある。
【００６４】
図２は、本明細書に記載のいくつかの実施形態に従う、入力データをエレメントに因子分解し、これらエレメントを基本データストア内に存在する基本データエレメントから導出することによるデータ削減のためのプロセスを示す。入力データが到着すると、当該データはパースされ、一連の候補エレメントに因子分解されるか分割され得る（オペレーション２０２）。次の候補エレメントが入力から消費され（オペレーション２０４）、基本データストアのコンテンツ連想ルックアップが候補エレメントのコンテンツに基づいて実行されて、候補エレメントをそこから導出可能ないずれかの好適なエレメントがあるか否かが調べられる（オペレーション２０６）。基本データストアがそのようなエレメントを全く見つけなかった場合（オペレーション２０８の「Ｎｏ」のブランチ）、候補エレメントが割当てられて新たな基本データエレメントとしてシーブに入力され、候補エレメントのために作成された蒸留データへのエントリが、新たに作成された基本データエレメントの参照となる（オペレーション２１６）。基本データストアのコンテンツ連想ルックアップが、候補がそこから導出される可能性がある１つ以上の好適なエレメントをもたらす場合（オペレーション２０８の「Ｙｅｓ」のブランチ）、取出された基本データエレメントに対して分析および計算が行われて、当該エレメントから候補エレメントが導出される。なお、いくつかの実施形態では、まず好適な基本データエレメントのためのメタデータのみがフェッチされてこのメタデータに対して分析が行われ、この好適な基本データエレメントは有用であると見なされた場合にのみ続いてフェッチされる（これらの実施形態では、基本データエレメントのためのメタデータが基本データエレメントのコンテンツについての何らかの情報を提供することによって、システムがメタデータに基づいて迅速に一致を排除するか導出可能性を評価することができる）。他の実施形態では、基本データストアは基本データエレメントを直接（すなわち、基本データエレメントを取出す前にまずメタデータを取出してメタデータを分析することなく）取出すので、分析および計算は取出された基本データエレメントに対して行なわれる。
【００６５】
候補がこれらエレメントのうちのいずれかの重複であるか否かを調べるための第１の確認が行なわれる（オペレーション２１０）。この確認は任意の好適なハッシング技術を用いて迅速化され得る。候補が基本データストアから取出された基本データエレメントと同一である場合（オペレーション２１０の「Ｙｅｓ」のブランチ）、候補エレメントのために作成された蒸留データへのエントリは、この基本データエレメントの参照と、このエントリが基本データエレメントであるという指示とに置換される（オペレーション２２０）。重複が見つからない場合（オペレーション２１０の「Ｎｏ」のブランチ）、候補エレメントに基づいて基本データストアから取出されたエントリが、候補エレメントをそこから導出できる可能性があるエントリと見なされる。以下は、基本データストアの重要な、新規の、非自明な特徴である：基本データストア内に重複が見つからない場合、基本データストアは基本データエレメントを戻すことができ、基本データエレメントは、候補エレメントと同一ではないが、１つ以上の変換を基本データエレメントに適用することによって候補エレメントがそこから導出される可能性があるエレメントである。プロセスは次に分析および計算を行って、最適な基本データエレメントまたは一組の好適な基本データエレメントから候補エレメントを導出し得る（オペレーション２１２）。いくつかの実施形態では、導出は、候補エレメントを、１つ以上の基本データエレメントに対して実行した変換の結果として表現し、そのような変換は再構成プログラムと総称される。各導出では、その固有のプログラムを構築する必要があり得る。再構成プログラムを構築するのに加えて、プロセスはさらに、ストレージリソースのレベルを一般的に示す距離メトリック、および／または、候補エレメントの再公式化を記憶するために、かつ再公式化から候補エレメントを再構成するために必要な計算リソースを計算し得る。いくつかの実施形態では、導出エレメントのフットプリントは、基本データエレメントからの候補の距離の測定として用いられ、具体的には、距離メトリックは、再構成プログラムのサイズに、導出に伴う１つ以上の基本データエレメントの参照のサイズのを加えた合計と定義され得る。最小距離を有する導出が選択され得る。この導出のための距離は距離閾値と比較され（オペレーション２１４）、距離が距離閾値を超えない場合、導出が受付けられる（オペレーション２１４の「Ｙｅｓ」のブランチ）。データ削減をもたらすために、距離閾値は常に候補エレメントのサイズ未満でなければならない。たとえば、距離閾値は候補エレメントのサイズの５０％に設定されてもよく、これによって、導出物は、そのフットプリントが候補エレメントのフットプリントの半分以下である場合にのみ受付けられることになり、これによって、好適な導出が存在する候補エレメント毎に２倍以上の削減が確実となる。距離閾値は、ユーザが指定した入力に基づく、またはシステムによって選択される、予め定められた割合または分率であってもよい。距離閾値は、システムの静的または動的パラメータに基づいてシステムによって決定されてもよい。導出が受付けられると、候補エレメントが再公式化され、再構成プログラムと１つ以上の基本データエレメントの参照との組合せで置換される。候補エレメントのために作成された蒸留データへのエントリは導出で置換され、すなわち、それは、再構成プログラムに、導出に伴う１つ以上の基本データエレメントの参照を加えたものとともに、これは導出エレメントであるという指示に置換される（オペレーション２１８）。一方、最良導出のための距離が距離閾値を超えた場合（オペレーション２１４の「Ｎｏ」のブランチ）、可能性のある導出物はいずれも受付けられない。その場合、候補エレメントが割当てられ、新たな基本データエレメントとしてシーブに入力され、候補エレメントのために作成された蒸留データへのエントリは、これが基本データエレメントであるという指示とともに、新たに作成された基本データエレメントの参照となる（オペレーション２１６）。
【００６６】
最後に、プロセスは追加の候補エレメントがあるか否かを確認し（オペレーション２２２）、追加の候補エレメントがある場合（オペレーション２２２の「Ｙｅｓ」のブランチ）はオペレーション２０４に戻り、追加の候補エレメントがない場合（オペレーション２２２の「Ｎｏ」のブランチ）はプロセスを終了し得る。
【００６７】
図２のオペレーション２０２を実行するために、すなわち受信データをパースしてそれを候補エレメントに分割するために、さまざまな方法が利用され得る。因子分解アルゴリズムは、バイトストリーム内のどこにブレークを挿入してストリームを候補エレメントにスライスアップするかを決定する必要がある。可能性のある技術として、ストリームを固定サイズのブロック（４０９６バイトのページなど）に分割すること、または、フィンガープリンティングの方法（ランダムな素数多項式を入力ストリームの部分文字列に適用する技術など）を適用して、エレメントの境界となる好適なフィンガープリントのデータストリーム内の位置を特定すること（この技術によって可変サイズのエレメントを得ることができる）、または、入力をパースしてヘッダもしくは何らかの予め宣言された構造を検出し、この構造に基づいてエレメントの輪郭を描くことがある（がこれらに限定されない）。入力はパースされて、スキーマによって宣言される一定の構造が検出され得る。入力はパースされて、データ内の予め宣言されたパターン、文法、または正規表現の存在が検出され得る。データ内の連続する２つのブレークが識別されると、候補エレメントが作成され（候補エレメントは連続する２つのブレーク同士の間にあるデータである）、コンテンツ連想ルックアップのために基本データストアに提示される。可変サイズのエレメントが作成されると、候補エレメントの長さを指定し、候補エレメントとともにメタデータとして伝送する必要がある。
【００６８】
基本データストアの１つの重要な機能は、基本データストアに提示される候補エレメントに基づいてコンテンツ連想ルックアップを提供すること、および、導出を指定するのに必要な最小ストレージで候補エレメントをそこから導出可能な１つのまたは小さい一組の基本データエレメントを迅速に提供することである。これは、大型データセットを前提とすると困難な問題である。テラバイトのデータを前提として、キロバイトサイズのエレメントであっても、検索して選択する何十億ものエレメントが存在する。この問題はデータセットが大きくなるとより深刻になる。好適な技術を用いてエレメントを組織化して順序付けした後、エレメントのその組織内の類似および導出可能性を検出して、小さい一組の好適な基本データエレメントを迅速に提供可能であることが重要になる。
【００６９】
シーブへのエントリは各エレメント（すなわち基本データエレメント）の値に基づいて順序付けられ得るので、すべてのエントリは値によって昇順または降順に配置され得る。あるいは、エントリは、エレメント内の一定のフィールドの値に基づく主軸に沿って、次にエレメントの残りのコンテンツを用いる副軸に沿って順序付けられてもよい。この文脈において、フィールドは、エレメントのコンテンツからの一組の隣接バイトである。フィールドは、フィンガープリントの場所がフィールドの位置を特定するようにエレメントのコンテンツにフィンガープリンティングの方法を適用することによって、位置が特定され得る。あるいは、エレメントのコンテンツ内部の一定の固定オフセットを選択してフィールドの位置を特定してもよい。他の方法を用いてフィールドの位置を特定してもよく、当該方法として、エレメントをパースして一定の宣言された構造を検出し、その構造内のフィールドの位置を特定することをがある。
【００７０】
さらに別の形態の組織では、エレメント内の一定のフィールドまたはフィールド同士の組合せを次元と見なすことができるので、これらの次元の連結、およびそれに続く各エレメントの残りのコンテンツを用いてデータエレメントを順序付けて組織化してもよい。一般的に、フィールドおよび次元同士の間の対応関係またはマッピングは任意に複雑であり得る。たとえば、いくつかの実施形態では、１つのフィールドのみが１つの次元のみにマップし得る。他の実施形態では、たとえばＦ１、Ｆ２、およびＦ３などの複数のフィールドの組合せが１つの次元にマップし得る。フィールドの組合せは、２つのフィールド同士を連結することによって、またはそれらにその他の好適な関数を適用することによって達成され得る。重要な要件は、フィールドの配置、次元、およびエレメントを組織化するために用いられるエレメントの残りのコンテンツが、すべての基本データエレメントをそれらのコンテンツによって固有に識別してシーブ内に順序付けることが可能でなければならないことである。
【００７１】
いくつかの実施形態では、エレメントのコンテンツは以下のような表現：Element =  Head  .* sig1  .*  sig2 .*  … sigI .*… sigN .* Tailとして表わすことができ、式中、「Head」はエレメントの先頭バイトを含むバイトのシーケンスであり、「Tail」はエレメントの終了バイトを含むバイトのシーケンスであり、「sig1」、「sig2」、「sigI」、および「sigN」は、エレメントを特徴付けるエレメントのコンテンツの本体内の一定長さのバイトのさまざまな署名またはパターンまたは正規表現またはシーケンスである。さまざまな署名同士の間の「.*」という表現はワイルドカード表現であり、すなわち、これは、「.*」という表現に続く署名以外の任意の値の任意の数の中間バイトを許可する正規表現の表記法である。いくつかの実施形態では、Ｎタプル（sig1, sig2, … sigI,… sigN）がエレメントの骨格データ構造またはスケルトンと称され、エレメントの減少した本質的なサブセットまたは本質と見なすことができる。他の実施形態では、（Ｎ＋２）タプル（Head, sig1, sig2, … sigI,… sigN, Tail）がエレメントの骨格データ構造またはスケルトンと称される。あるいは、HeadまたはTailを残りの署名とともに含むＮ＋１を使用してもよい。
【００７２】
フィンガープリンティングの方法がエレメントのコンテンツに適用されて、エレメントのコンテンツ内の骨格データ構造のさまざまなコンポーネント（または署名）の場所が判定され得る。あるいは、エレメントのコンテンツ内部の一定の固定オフセットを選択してコンポーネントの位置を特定してもよい。他の方法を用いて骨格データ構造のコンポーネントの位置を特定してもよく、当該方法として、エレメントをパースして一定の宣言された構造を検出し、その構造内のコンポーネントの位置を特定することがある。基本データエレメントは、それらの骨格データ構造に基づいてシーブ内に順序付けられ得る。言い換えると、エレメントの骨格データ構造のさまざまなコンポーネントを次元と見なすことができるため、これらの次元同士の連結、およびそれに続く各エレメントの残りのコンテンツを用いて、基本データエレメントをシーブ内に順序付けて組織化してもよい。
【００７３】
いくつかの実施形態では入力データが候補エレメントに因子分解され、各候補エレメントのサイズは、グローバルデータセット内のすべてのそのようなエレメントにアクセスするのに必要な参照のサイズより実質的に大きい。そのようなデータチャンクに分割される（かつコンテンツ連想的にアクセスされる）データに関する１つの観察は、実際のデータは、データチャンクが指定可能なすべての可能性のある値に対して非常に疎らであることである。たとえば、１ゼタバイトのデータセットを考えてみる。このデータセット内の全バイトをアドレス指定するには約７０ビットが必要である。１２８バイト（１０２４ビット）のチャンクサイズでは、１ゼタバイトのデータセット内に約２63個のチャンクが存在するので、これらすべてのチャンクをアドレス指定するには６３ビット（８バイト未満）が必要である。なお、１０２４ビットのエレメントまたはチャンクは２1024個の可能性のある値のうちの１つを有し得るが、データセット内の所与のチャンクの実際値の数はせいぜい２63個（すべてのチャンクが別個である場合）である。これは、実際のデータは、エレメントのコンテンツが達し得るまたは名付け得る値の数に対して非常に疎らであることを示す。これによって、効率的なコンテンツベースのルックアップを可能にし、新たなエレメントをツリー構造に効率的に追加することを可能にし、かつ、ツリー構造自体に必要な増分ストレージの面でコスト効率の高い態様で非常に疎らなデータを組織化するのに適しているツリー構造の使用が可能になる。１ゼタバイトのデータセット内には別個のチャンクが２63個しかないため、それら同士を区別するのに６３個の区別ビットの情報しか必要でないが、関連の区別ビットはエレメントの１０２４ビットにわたって分散し、エレメント毎に異なる場所で起こり得る。したがって、すべてのエレメント同士を完全に区別するためには、コンテンツから固定の６３ビットを調べるのみでは不十分であり、むしろ、エレメントのコンテンツ全体が、エレメントをソートするのに、特に、データセット内のすべてのエレメントへの真のコンテンツ連想アクセスを提供するソリューションに関与する必要がある。Data Distillation（商標）フレームワークでは、データを順序付けて組織化するために用いられるフレームワーク内の導出可能性を検出可能であることが望ましい。上記のすべてを念頭に置いて、コンテンツに基づくツリー構造（より多くのコンテンツが調べられるにつれてデータを漸進的に区別する）は、因子分解されたデータセット内のすべてのエレメントを順序付けて区別するのに好適な組織である。そのような構造は、導出可能エレメントのグループ分け、または導出可能性の同様のプロパティを有するエレメントのグループ分けとして取扱われ得るサブツリーの多数の中間レベルを提供する。そのような構造は、各サブツリーを特徴付けるメタデータで、またはデータの各エレメントを特徴付けるメタデータで階層的に拡張され得る。そのような構造は、データ内の実際値の密度、近接、および分布を含む、当該構造が含むデータ全体の成分を効果的に通信し得る。
【００７４】
いくつかの実施形態では、基本データエレメントがツリー形態でシーブ内に組織化される。各基本データエレメントは、当該基本データエレメントのコンテンツ全体から構築される別個の「名前」を有する。この名前は、基本データエレメントを固有に識別するのに、かつそれをツリー内のすべての他のエレメントに対して区別するのに十分であるように設計される。基本データエレメントのコンテンツから名前を構築可能な方法はいくつかある。名前は単に基本データエレメントの全バイトで構成されてもよく、これらのバイトは、それらが基本データエレメント内に存在しているのと同じ順序で名前内に現われる。別の実施形態では、次元と称される一定のフィールドまたはフィールド同士の組合せ（フィールドおよび次元は上記の通り）を用いて名前の先頭バイトが形成され、基本データエレメントの残りのコンテンツは残りの名前を形成しているので、基本データエレメントのコンテンツ全体がエレメントの完全な固有の名前を作成するのに関与している。さらに別の実施形態では、エレメントの骨格データ構造のフィールドが次元として選択され（フィールドおよび次元は上記の通り）、当該フィールドを用いて名前の先頭バイトが形成され、基本データエレメントの残りのコンテンツは残りの名前を形成しているので、基本データエレメントのコンテンツ全体がエレメントの完全な固有の名前を作成するのに関与している。
【００７５】
各基本データエレメントの名前を用いて、基本データエレメントが順序付られてツリーに組織化される。ほとんどの実用的なデータセット、さらにはサイズが非常に大きい（たとえば、４ＫＢサイズの２58個のエレメントで構成される１ゼタバイトのデータセットなど）データセットについては、名前のバイトの小さいサブセットが基本データエレメントの大半をソートしてツリー内に順序付ける役割を果たすことが多いと予想される。
【００７６】
図３Ａ、図３Ｂ、図３Ｃ、図３Ｄおよび図３Ｅは、本明細書に記載のいくつかの実施形態に従う、基本データエレメントをそれらの名前に基づいて組織化するために用いられ得るさまざまなデータ組織システムを示す。
【００７７】
図３Ａは、基本データエレメントが各基本データエレメントの名前からの連続バイトの値に基づいて漸進的に小さくなるグループに組織化されるトライデータ構造を示す。図３Ａに示す例では、各基本データエレメントは、当該基本データエレメントのコンテンツ全体から構築される別個の名前を有しており、この名前は単に基本データエレメントの全バイトで構成されており、これらのバイトは、それらが基本データエレメント内に存在しているのと同じ順序で名前内に現われる。トライのルートノードはすべての基本データエレメントを表わす。トライの他のノードは基本データエレメントのサブセットまたはグループを表わす。トライのルートノードまたは第１レベル（図３Ａにおいてルート３０２とラベル付けされている）で始まり、基本データエレメントはそれらの名前の最大有効バイト（図３ＡにおいてＮ１とラベル付けされている）の値に基づいてサブツリーにグループ分けされる。それらの名前の最大有効バイトにおいて同じ値を有するすべての基本データエレメントが共通のサブツリーに互いにグループ分けされ、その値が示すリンクが、ルートノードからそのサブツリーを表わすノードに存在する。たとえば、図３Ａでは、ノード３０３は、各自の名前のそれらの最大有効バイトＮ１内に同じ値２を各々が有する基本データエレメントのサブツリーまたはグループを表わす。図３Ａでは、このグループは基本データエレメント３０５，３０６および３０７を含む。
【００７８】
トライの第２レベルにおいて、各基本データエレメントの名前の２番目の最大有効バイトを用いて、基本データエレメントの各グループがより小さいサブグループにさらに分割される。たとえば、図３Ａでは、ノード３０３によって表わされる基本データエレメントのグループが、２番目の最大有効バイトＮ２を用いてサブグループにさらに細分割される。ノード３０４は、それらの最大有効バイトＮ１内に値２を有し、かつ各自の名前のそれらの第２の最大有効バイトＮ２内に値１を有する基本データエレメントのサブグループを表わす。このサブグループは基本データエレメント３０５および３０６を含む。
【００７９】
細分割のプロセスは、親ノードから各子ノードのリンクを作成するトライの各レベルで継続し、子ノードは親ノードによって表わされる基本データエレメントのサブセットを表わす。このプロセスは、トライのリーフに個別の基本データエレメントしか存在しなくなるまで継続する。リーフノードはリーフのグループを表わす。図３Ａでは、ノード３０４がリーフノードである。ノード３０４によって表わされる基本データエレメントのグループは、基本データエレメント３０５および３０６を含む。図３Ａでは、このグループは、個別の基本データエレメント３０５および３０６に、それらの名前の３番目の最大有効バイトを用いてさらに細分割される。Ｎ３＝３の値は基本データエレメント３０５に至り、値Ｎ３＝５は基本データエレメント３０６に至る。この例では、それらの完全な名前のうち、基本データエレメント３０５および３０６を完全に識別するのに３つの有効バイトのみで十分である。同様に、基本データエレメント３０７を識別するのに名前からの２つの有効バイトのみで十分である。
【００８０】
この例は、基本データエレメントの所与の混合において、名前のバイトのサブセットのみがツリー内の基本データエレメントを識別する役割を果たし、固有の基本データエレメントに到達するのに名前全体は不要であることを示す。また、基本データエレメントまたは基本データエレメントのグループは各々が、それらを固有に識別できるようにするために異なる数の有効バイトを必要とし得る。ゆえに、ルートノードから基本データエレメントまでのトライの深さは基本データエレメント毎に異なり得る。さらに、トライにおいて、各ノードは下位のサブツリーに下降する異なる数のリンクを有し得る。
【００８１】
そのようなトライでは、各ノードは、このノードにどのように到達するかを指定するバイトのシーケンスで構成される名前を有する。たとえば、ノード３０４についての名前は「２１」である。また、ツリー内のエレメントの現在の分布におけるエレメントを固有に識別するエレメントの名前からのバイトのサブセットは、ルートノードからこの基本データエレメントまでの「パス」である。たとえば、図３Ａでは、値２１３を有するパス３０１が基本データエレメント３０５を識別する。
【００８２】
ここに記載するトライ構造は、ツリー内のエレメントの名前のすべての区別バイトが１レベルの深さをトライに追加するため、深いツリー（すなわち多くのレベルを有するツリー）を作成し得る。
【００８３】
なお、図３Ａ〜図３Ｅのツリーデータ構造は左から右に描かれている。したがって、図の左側から図の右側に移動するにつれて、ツリーの高レベルからツリーの低レベルに移動する。所与のノードの下位に（すなわち図３Ａ〜図３Ｅの所与のノードの右側に向かって）、名前からの区別バイトの一定値によって選択される任意の子について、その子の下位のサブツリーに存在しているすべてのエレメントは、当該エレメントの名前内のその対応するバイト内に同じ値を有する。
【００８４】
次に、入力候補エレメントを前提として、トライ構造のコンテンツ連想ルックアップのための方法を説明する。この方法は、候補エレメントの名前を用いるトライ構造のナビゲーションを伴い、その後、分析およびスクリーニングが続いて行なわれて、コンテンツ連想ルックアップ全体の結果として何を戻すべきかが決定される。言い換えると、トライナビゲーションプロセスは第１の結果を戻し、次に、その結果に対して分析およびスクリーニングが行われて、コンテンツ連想ルックアップ全体の結果が判定される。
【００８５】
トライナビゲーションプロセスを開始するために、候補エレメントの名前から最大有効バイトの値を用いて、ルートノードから、それらの名前の最大有効バイト内にその同じ値を有する基本データエレメントのサブツリーを表わす後続ノードまでのリンク（その値によって示される）が選択される。このノードから進んで、候補エレメントの名前からの第２のバイトを調べ、その値が示すリンクを選択することによって、１レベル深く（または低く）トライの中へと進み、それらの名前からの少なくとも２つの有効バイトにおいて候補エレメントと共有するようになった基本データエレメントのより小さいサブグループが選択される。このプロセスは、１つの基本データエレメントに到達するまで、または候補エレメントの名前からの対応するバイトの値と一致するリンクがなくなるまで継続される。これらの条件のいずれか一方の下で、ツリーナビゲーションプロセスが終了する。１つの基本データエレメントに到達すると、それはトライナビゲーションプロセスの結果として戻され得る。そうでない場合、１つの代替案は「欠落」を報告することである。別の代替案は、ナビゲーションが終了したノードをルートとするサブツリー内にある複数の基本データエレメントを戻すことである。
【００８６】
トライナビゲーションプロセスが終了すると、他の基準および要件を用いてトライナビゲーションプロセスの結果が分析されスクリーニングされて、コンテンツ連想ルックアップの結果として何を戻すべきかが決定され得る。たとえば、１つの基本データエレメントまたは複数の基本データエレメントがトライナビゲーションプロセスによって戻された場合は、それらは、コンテンツ連想ルックアップの結果として戻される資格を得る前に、候補エレメントの名前と一定の最小数のバイトを共有しているという付加的な要件があり得る（そうでない場合、コンテンツ連想ルックアップは欠落を戻す）。スクリーニング要件の別の例は、トライナビゲーションプロセスが、複数の基本データエレメント（トライナビゲーションが終了したノードをルートとする）がトライナビゲーションプロセスの結果として戻されるように、１つの基本データエレメントに到達することなく終了した場合は、これら複数の基本データエレメントは、これらエレメントの数が一定の指定された制限未満である場合にのみ、コンテンツ連想ルックアップ全体の結果として戻される資格を得るようなものであってもよい（そうでない場合、コンテンツ連想ルックアップは欠落を戻す）。複数の要件同士の組合せを使用して、コンテンツ連想ルックアップの結果を判定してもよい。このように、ルックアッププロセスは、「欠落」を報告するかもしくは１つの基本データエレメントを戻し、または１つの基本データエレメントでない場合は、候補エレメントを導出するための良好な開始点である可能性が高い一組の基本データエレメントを戻す。
【００８７】
以下に記載する図３Ｂ〜図３Ｅは、図３Ａに示すツリーデータ構造の変形および変更に関する。これらの変形は、図３Ａに示すトライデータ構造に対する向上および利点を提供するが、データ構造をナビゲートするためのプロセスは図３Ａを参照して上記したプロセスと同様である。すなわち、図３Ｂ〜図３Ｅに示すツリーデータ構造のためのツリーナビゲーションが終了した後、続いて分析およびスクリーニングが行われてコンテンツ連想ルックアップ全体の結果が判定され、プロセス全体は、欠落、１つの基本データエレメント、または候補エレメントを導出するための良好な開始点である可能性が高い一組の基本データエレメントを戻す。
【００８８】
図３Ｂは、基本データエレメントをそれらの名前に基づいて組織化するために用いられ得る別のデータ組織システムを示す。図３Ｂに示す例では、各基本データエレメントは、当該基本データエレメントのコンテンツ全体から構築される別個の名前を有しており、この名前は単に当該基本データエレメントの全バイトで構成されており、これらのバイトは、それらが基本データエレメント内に存在しているのと同じ順序で名前内に現われる。図３Ｂは、１つのリンクが下位のサブツリー内の基本データエレメントの名前から（図３Ａのトライに用いられる単一のバイトではなく）複数のバイトを使用して再分割または次のレベルのグループ分けを作成する、よりコンパクトな構造を示す。親ノードから子ノードへのリンクは、ここでは複数のバイトによって示されている。さらに、任意の所与の親ノードから、各リンクは、そのリンクと関連付けられているサブツリーを区別して識別するために異なる数のバイトを使用し得る。たとえば、図３Ｂでは、ルートノードからノード３０８のリンクは名前から４バイト（Ｎ1Ｎ2Ｎ3Ｎ4＝９８４５）を用いることによって区別されているが、ルートノードからノード３０９へのリンクは名前から３バイト（Ｎ1Ｎ2Ｎ3＝３４７）を用いることによって区別されている。
【００８９】
なお、（所与の候補エレメントからのコンテンツを用いる）ツリーナビゲーションの際、ツリー内のいずれかの親ノードに到着すると、ツリーナビゲーションプロセスは、候補エレメントの名前から十分なバイトを調べてどのリンクを選択すべきかを明確に決定することを保証する必要がある。所与のリンクを選択するために、候補の名前からのバイトは、移行を示す全バイトをその特定のリンクと一致させなければならない。ここでも、そのようなツリーにおいて、ツリーの各ノードは、このノードにどのように到達すべきかを指定するバイトのシーケンスで構成される名前を有する。たとえば、ノード３０９の名前は、これが基本データエレメント（たとえばエレメント３１１および３１２）のグループを表わしているので「３４７」であり得、それらの名前の先頭の３バイトは「３４７」である。名前の先頭の３バイトが３４７である候補エレメントを用いるツリーをルックアップすると、このデータパターンによって、ツリーナビゲーションプロセスは図３Ｂに示すようにノード３０９に到達する。ここでも、ツリー内のエレメントの現在の混合内のエレメントを固有に識別するエレメントの名前からのバイトのサブセットは、ルートノードからこの基本データエレメントへの「パス」である。たとえば、図３Ｂでは、バイトのシーケンス３４７５は基本データエレメント３１２に至り、その例に示す基本データエレメントの混合内の基本データエレメント３１２を固有に識別する。
【００９０】
多様で疎らなデータについて、図３Ｂのツリー構造は、図３Ａのトライ構造よりも柔軟でコンパクトであることが判明している。
【００９１】
図３Ｃは、基本データエレメントをそれらの名前に基づいて組織化するために用いられ得る別のデータ組織システムを示す。図３Ｃに示す例では、各基本データエレメントは、当該基本データエレメントのコンテンツ全体から構築される別個の名前を有しており、この名前は単に当該基本データエレメントの全バイトで構成されており、これらのバイトは、それらが基本データエレメント内に存在しているのと同じ順序で名前内に現われる。図３Ｃは、（必要および／または有用であれば）正規表現を使用してさまざまなリンクに至る基本データエレメントの名前からの値を指定することによってツリーおよびグループエレメントをサブツリーにさらにコンパクト化する（図３Ｂに記載の組織に対する）別の変形を示す。正規表現の使用によって、同じサブツリー下の対応するバイト上の同一表現を共有するエレメントの効率的なグループ分けが可能になり、これに続いて、当該サブツリー内の別個の基本データエレメントのより局所的な曖昧性除去を行なうことができる。また、正規表現の使用によって、エレメントを下位の任意のサブツリーにマップするために必要なバイトの値を記述する、よりコンパクトな方法が可能になる。これによって、ツリーを指定するのに必要なバイトの数がさらに減少する。たとえば、正規表現３１８は２８個の連続した「Ｆ」のパターンを指定しており、ツリーナビゲーション時にこのリンクをたどると、エレメント３１４に到達することができ、これは正規表現３１８に従って２８個の連続した「Ｆ」を有するパターン３２０を含む。同様に、エレメント３１６に到達するパスは、１６個の連続した「０」を有するパターンを指定する正規表現を使用するリンクまたはブランチを有する。そのようなツリーについては、ツリーナビゲーションプロセスは、どのリンクを選択すべきかを決定するためにそのような正規表現を検出して実行する必要がある。
【００９２】
図３Ｄは、基本データエレメントをそれらの名前に基づいて組織化するために用いられ得る別のデータ組織システムを示す。図３Ｄに示す例では、各基本データエレメントは、当該基本データエレメントのコンテンツ全体から構築される別個の名前を有する。フィンガープリンティングの方法が各エレメントに適用されて、選択されたフィンガープリントを評価するコンテンツを含むフィールドの場所が識別される。エレメント内に見つかった第１のフィンガープリントの場所におけるフィールドは次元として取扱われ、このフィールドからの一定数のバイト（たとえばｘバイトであり、ここでｘはエレメント内のバイトの数より実質的に小さい）が抽出されてエレメントの名前の先頭バイトとして用いられ、名前の残りのバイトは、基本データエレメントの残りのバイトで構成され、それらが基本データエレメント内に存在しているのと同じ周期的順序で現われる。この名前を用いて基本データエレメントがツリーに組織化される。この例では、エレメント内にフィンガープリントが検出されない場合、名前は、単にエレメントの全バイトをそれらがエレメント内に存在している順序で用いることによって公式化される。別個のサブツリー（フィンガープリントが見つからなかったという指示によって示される）が、すべてのそのようなエレメントをそれらの名前に基づいて保持して組織化する。
【００９３】
たとえば、図３Ｄに示すように、フィンガープリンティング技術がエレメント３３８（ｔバイトのデータ、すなわちＢ1Ｂ2Ｂ3…Ｂtを含む）に適用されて、「次元１」として選択されるフィールドを識別するバイトＢi+1におけるフィンガープリント場所「フィンガープリント１」が得られ得る。次に、「フィンガープリント１」によって識別された場所からのｘバイトを抽出して「次元１」が形成され得、これらｘバイトは図３Ｄの各エレメントの名前の先頭バイトＮ1Ｎ2…Ｎxとして用いられ得る。続いて、エレメント３３８からの残りのｔ−ｘバイト（Ｂi+x+1で始まり、後でＢ1Ｂ2Ｂ3…Ｂiにラップアラウンドする）が連結され、名前の残りのバイトＮx+1Ｎx+2…Ｎtとして用いられる。エレメント内にフィンガープリントが見つからない場合、名前Ｎ1Ｎ2……Ｎtは単にエレメント３３８からのＢ1Ｂ2Ｂ3…Ｂtである。基本データエレメントは、それらの名前を用いてソートされてツリーに組織化される。たとえば、基本データエレメント（ＰＤＥ）３３０は、パス１３６５４…０６を用いてツリーの２つのレベルを横断した後に識別されて到達され、バイト１３６５４…０は次元１からのバイトであるＮ1Ｎ2……Ｎxである。（フィンガープリントが見つからなかったという指示によって示される）リンク３３４に沿ったルートから到達されるノード３３５における別個のサブツリーが、選択されたフィンガープリントを評価しなかったコンテンツを有するすべての基本データエレメントを保持して組織化する。ゆえに、この組織では、たとえばリンク３３６などのいくつかのリンクは、エレメント内に現われるのと同じ順序で現われるエレメントのバイトで構成される名前を用いてエレメントを組織化し得るが、たとえばリンク３４０などの他のリンクは、フィンガープリントを用いて公式化される名前を用いてエレメントを組織化し得る。
【００９４】
候補エレメントを受信すると、プロセスは上記と同一の技術を適用して候補エレメントの名前を判定し、この名前を用いてコンテンツ連想ルックアップのためにツリーをナビゲートする。ゆえに、同一の一貫した処理が基本データエレメントに（それらがツリーにインストールされると）、および候補エレメントに（それらをパーサおよび因子分解部から受信すると）適用されてそれらの名前が作成される。ツリーナビゲーションプロセスは、候補エレメントの名前を用いてツリーをナビゲートする。本実施形態では、候補エレメント内にフィンガープリントが見つからない場合、ツリーナビゲーションプロセスは、フィンガープリントを評価しなかったコンテンツを有する基本データエレメントを組織化して含んでいるサブツリーをたどってナビゲートする。
【００９５】
図３Ｅは、基本データエレメントをそれらの名前に基づいて組織化するために用いられ得る別のデータ組織システムを示す。図３Ｅに示す例では、各基本データエレメントは、当該基本データエレメントのコンテンツ全体から構築される別個の名前を有する。フィンガープリンティングの方法が各エレメントに適用されて、２つのフィンガープリントのいずれか一方を評価するコンテンツを含むフィールドの場所が識別される。エレメント内の第１のフィンガープリント（図３Ｅのフィンガープリント１）の第１の発生の場所にあるフィールドは第１の次元（次元１）として取扱われ、第２のフィンガープリント（図３Ｅのフィンガープリント２）の第１の発生の場所にあるフィールドは第２の次元（次元２）として取扱われる。フィンガープリンティングを用いてエレメント上の２つの別個のフィンガープリントを探すと、４つの可能なシナリオにつながる：（１）両フィンガープリントがエレメント内に見つかる、（２）フィンガープリント１は見つかるがフィンガープリント２は見つからない、（３）フィンガープリント２は見つかるがフィンガープリント１は見つからない、および（４）フィンガープリントがまったく見つからない。基本データエレメントは、上記シナリオの各々に対応する４つのサブツリーにグループ分けされ得る。図３Ｅでは、「ＦＰ１」はフィンガープリント１の存在を示し、「ＦＰ２」はフィンガープリント２の存在を示し、「〜ＦＰ１」はフィンガープリント１の欠如を示し、「〜ＦＰ２」はフィンガープリント２の欠如を示す。
【００９６】
４つのシナリオの各々について、エレメントの名前は以下のように作成される：（１）両フィンガープリントが見つかる場合、「フィンガープリント１」によって識別される場所からのｘバイトが抽出されて「次元１」が形成され得、「フィンガープリント２」によって識別される場所からのｙバイトが抽出されて「次元２」が形成され得、これらｘ＋ｙバイトが、図３Ｅにおけるそのような各エレメントの名前の先頭バイトＮ1Ｎ2…Ｎx+yとして用いられ得る。続いて、エレメント３４８からの残りのｔ−（ｘ＋ｙ）バイトが周期的に（第１の次元からのバイトの後に開始して）抽出され、連結されて名前の残りのバイトＮx+y+1Ｎx+y+2…Ｎtとして用いられる。（２）フィンガープリント１は見つかるがフィンガープリント２は見つからない場合、「フィンガープリント１」によって識別される場所からのｘバイトが抽出されて先頭次元が形成され得、これらｘバイトはそのような各エレメントの名前の先頭バイトＮ1Ｎ2…Ｎxとして用いられ得る。続いて、エレメント３４８からの残りのｔ−ｘバイト（Ｂi+x+1から開始し、後でＢ1Ｂ2Ｂ3…Ｂiにラップアラウンドする）が連結され、名前の残りのバイトＮx+1Ｎx+2…Ｎtとして用いられる。（３）フィンガープリント２は見つかるがフィンガープリント１は見つからない場合、「フィンガープリント２」によって識別される場所からのｙバイトが抽出されて先頭次元が形成され得、これらｙバイトは、そのような各エレメントの名前の先頭バイトＮ1Ｎ2…Ｎyとして用いられ得る。続いて、エレメント３４８からの残りのｔ−ｙバイト（Ｂj+y+1から開始し、後でＢ1Ｂ2Ｂ3…Ｂjにラップアラウンドする）が連結され、名前の残りのバイトＮy+1Ｎy+2…Ｎtとして用いられる。（４）エレメント内にフィンガープリントがまったく見つからない場合、名前Ｎ1Ｎ2……Ｎtは単にエレメント３４８からのＢ1Ｂ2Ｂ3…Ｂtである。ゆえに、これら４つのシナリオ毎に別個のサブツリーが存在する。エレメント３４８のための名前（Ｎ1Ｎ2Ｎ3…Ｎt）を抽出するためのプロセスは、以下のように４つのシナリオについて要約することができる：
（１）  フィンガープリント１およびフィンガープリント２の両方が見つかる：
Ｎ1−Ｎx←Ｂi+1−Ｂi+x＝次元１からのｘバイト
Ｎx+1−Ｎx+y←Ｂj+1−Ｂj+y＝次元２からのｙバイト
Ｎx+y+1…Ｎt＝（ｔバイトのサイズの候補エレメントからの）残りのバイト＝Ｂi+x+1Ｂi+x+2Ｂi+x+3…ＢjＢj+y+1Ｂj+y+2Ｂj+y+3…ＢtＢ1Ｂ2Ｂ3…Ｂi
（２）  フィンガープリント１は見つかり、フィンガープリント２は見つからない：
Ｎ1−Ｎx←Ｂi+1−Ｂi+x＝次元１からのｘバイト
Ｎx+1…Ｎt＝（ｔバイトのサイズの候補エレメントからの）残りのバイト＝Ｂi+x+1Ｂi+x+2Ｂi+x+3…ＢtＢ1Ｂ2Ｂ3…Ｂi
（３）  フィンガープリント２は見つかり、フィンガープリント１は見つからない：
Ｎ1−Ｎy←Ｂj+1−Ｂj+y＝次元２からのｙバイト
Ｎy+1…Ｎt＝（ｔバイトのサイズの候補エレメントからの）残りのバイト＝Ｂj+y+1Ｂj+y+2Ｂj+y+3…ＢtＢ1Ｂ2Ｂ3…Ｂj
（４）  フィンガープリントがまったく見つからない：
Ｎ1−Ｎx←Ｂ1−Ｂt
【００９７】
候補エレメントを受信すると、プロセスは上記と同一の技術を適用して候補エレメントの名前を判定する。本実施形態では、（フィンガープリント１およびフィンガープリント２が見つかるか否かに依存して）上記の名前構築の４つの方法が、基本データエレメントがシーブに入力される際の基本データエレメントに対するのと同様に、候補エレメントに適用される。ゆえに、同一の一貫した処理が基本データエレメントに（それらがツリーにインストールされると）、および候補エレメントに（それらをパーサおよび因子分解部から受信すると）適用されてそれらの名前が作成される。ツリーナビゲーションプロセスは、候補エレメントの名前を用いてコンテンツ連想ルックアップのためにツリーをナビゲートする。
【００９８】
コンテンツ連想ルックアップが成功すると、候補エレメントと同一のパターンを特定次元の場所に有する基本データエレメントがもたらされる。たとえば、両フィンガープリントが候補エレメント内に見つかると、ツリーナビゲーションプロセスは、ルートノードから開始して、それをツリーのリンク３５４にダウンさせる。候補エレメントが「次元１」としてパターン「９９…３」を有し、「次元２」としてパターン「７…５」を有する場合、ツリーナビゲーションプロセスはノード３３４に到着する。これは、導出のターゲットの可能性が高い、２つの基本データエレメント（ＰＤＥ３５２およびＰＤＥ３５３）を含むサブツリーに到達する。付加的な分析およびスクリーニングが（最初にメタデータを調べることによって、かつ必要であれば、続いて実際の基本データエレメントをフェッチして調べることによって）行われて、どの基本データエレメントが導出に最適であるかが判断される。ゆえに、本明細書に記載の実施形態は、シーブ内に用いられ得るさまざまなツリー構造を識別する。そのような構造の組合せまたはそれらの変形を使用して基本データエレメントが組織化され得る。いくつかの実施形態では基本データエレメントはツリー形態に組織化され、エレメントのコンテンツ全体がエレメントの名前として用いられる。しかし、バイトがエレメントの名前内に現われる順番は、必ずしも当該バイトがエレメント内に現われる順番とは限らない。エレメントの一定のフィールドが次元として抽出されて名前の先頭バイトを形成するために用いられ、エレメントの残りのバイトは残りの名前を構成する。これらの名前を用いて、エレメントはシーブ内にツリー形態で順序付けられる。名前の先頭桁を用いてツリーのより高位のブランチ（またはリンク）同士が区別され、残りの桁を用いてツリーのすべてのブランチ（またはリンク）が漸進的に区別される。ツリーの各ノードは、そのノードから発生する異なる数のリンクを有し得る。また、ノードからの各リンクは異なる数のバイトによって区別され表示され得、これらのバイトの記述は、正規表現およびそれらの仕様を表現する他の強力な方法を用いて達成され得る。これら特徴はすべて、コンパクトなツリー構造をもたらす。ツリーのリーフノードには、個々の基本データエレメントの参照が存在している。
【００９９】
一実施形態では、フィンガープリンティングの方法が基本データエレメントを含むバイトに適用され得る。フィンガープリントによって識別される場所に存在するバイトの数を用いて、名前のエレメントのコンポーネントが作成され得る。１つ以上のコンポーネントが組合されて次元が提供され得る。複数のフィンガープリントを用いて複数の次元が識別され得る。これら次元は連結され、エレメントの名前の先頭バイトとして用いられ、エレメントの残りのバイトはエレメントの残りの名前を含む。次元はフィンガープリントによって識別される位置にあるため、これによって、名前が各エレメントからの一貫したコンテンツから形成されている可能性が高くなる。フィンガープリントによって位置を特定されたフィールドにおけるコンテンツの同一の値を有するエレメントは、ツリーの同一のレッグに沿って互いにグループ分けされる。このように、同様のエレメントはツリーデータ構造に互いにグループ分けされる。内部にフィンガープリントが見つからないエレメントは、それらの名前の代替の公式化を用いて、別個のサブツリーに互いにグループ分けされ得る。
【０１００】
一実施形態では、フィンガープリンティングの方法がエレメントのコンテンツに適用されて、エレメントのコンテンツ内の（上記の）骨格データ構造のさまざまなコンポーネント（または署名）の場所が判定され得る。あるいは、エレメントのコンテンツ内部の一定の固定オフセットを選択してコンポーネントの位置を特定してもよい。他の方法を用いてエレメントの骨格データ構造のコンポーネントの位置を特定してもよく、当該方法として、エレメントをパースして一定の宣言された構造を検出し、その構造内のコンポーネントの位置を特定することがある。エレメントの骨格データ構造のさまざまなコンポーネントを次元と見なすことができるため、これらの次元同士の連結、およびそれに続く各エレメントの残りのコンテンツを用いて、各エレメントの名前が作成される。名前を用いて基本データエレメントが順序付けられてツリーに組織化される。
【０１０１】
別の実施形態では、エレメントの一定の構造を検出するためにエレメントがパースされる。この構造内の一定のフィールドは次元として識別される。複数のそのような次元は連結されて名前の先頭バイトとして用いられ、エレメントの残りのバイトはエレメントの残りの名前を含む。次元はエレメントをパースしてその構造を検出することによって識別される位置にあるため、これによって、名前が各エレメントからの一貫したコンテンツから形成されている可能性が高くなる。パースすることによって位置を特定されたフィールドにおけるコンテンツの同一の値を有するエレメントは、ツリーの同一のレッグに沿って互いにグループ分けされる。このように、ここでも、同様のエレメントはツリーデータ構造に互いにグループ分けされる。
【０１０２】
いくつかの実施形態では、ツリーデータ構造内の各ノードは自己記述仕様を含む。ツリーノードは１つ以上の子を有する。各子エントリは、当該子へのリンク上の区別バイトについての情報、および当該子ノードの参照を含む。子ノードはツリーノードまたはリーフノードであり得る。図３Ｆは、本明細書に記載のいくつかの実施形態に従う、自己記述ツリーノードデータ構造を提示する。図３Ｆに示すツリーノードデータ構造は、（Ａ）ルートノードからこのツリーノードへのパスに関連する情報であって、以下のコンポーネントのすべてまたはサブセットを含む：名前からこのツリーノードに到達するためのバイトの実際のシーケンス、ルートノードからこのノードに到達するために消費する名前のバイトの数、この消費するバイトの数が何らかの予め指定された閾値よりも大きいか否かの指示、ならびに、このノードへのパスを記述し、ツリーのコンテンツ連想検索に、およびツリーの構築に関連する決定に有用な他のメタデータ、（Ｂ）ノードが有する子の数を指定し、（Ｃ）各子（各子はツリーの１つのブランチに対応する）について、（１）子ＩＤ、（２）ツリーのこのリンクを下位に移行させるために名前の後続バイトから必要とされる区別バイトの数、（３）それをこのリンクにダウンさせる名前からのバイトの実際値についての仕様、および（４）子ノードの参照を指定する。
【０１０３】
図３Ｇは、本明細書に記載のいくつかの実施形態に従う、自己記述リーフノードデータ構造を提示する。リーフノードは１つ以上の子を有する。各子は基本データエレメントへのリンクである。各子エントリは、基本データエレメントへのリンク上の区別バイトについての情報、基本データエレメントの参照、重複および導出物のカウント、ならびに基本データエレメントについての他のメタデータを含む。図３Ｇに示すリーフノードデータ構造は、（Ａ）ルートノードからこのリーフノードへのパスに関連する情報であって、以下のコンポーネントのすべてまたはサブセットを含む：名前からこのリーフノードに到達するためのバイトの実際のシーケンス、ルートノードからこのノードに到達するために消費する名前のバイトの数、この消費するバイトの数が何らかの予め指定された閾値よりも大きいか否かの指示、ならびに、このノードへのパスを記述し、ツリーのコンテンツ連想検索に、およびツリーの構築に関連する決定に有用な他のメタデータ、（Ｂ）ノードが有する子の数を指定し、（Ｃ）各子（各子はリーフノード下の１つの基本データエレメントに対応する）について、（１）子ＩＤ、（２）基本データエレメントへのツリーのこのリンクを下位に移行させるために名前の後続バイトから必要とされる区別バイトの数、（３）それをこのレッグにダウンさせる名前からのバイトの実際値についての仕様、（４）ツリーのこのパス上のツリーを終了させる基本データエレメントの参照、（５）いくつの重複および導出物がこの基本データエレメントを指しているかのカウント（これは、ストレージシステム内のデータが削除されるとシーブからエントリを削除可能であるか否かを確かめるために用いられる）、ならびに（６）基本データエレメントのサイズを含む基本データエレメントについての他のメタデータ等を指定する。
【０１０４】
新規な基本データエレメントがツリーにインストールされる効率を増加させるために、いくつかの実施形態では、ツリーのリーフノードで維持される基本データエレメント毎に付加的なフィールドがリーフノードデータ構造に組込まれる。なお、新規なエレメントをツリーに挿入する必要がある場合、サブツリー内のどこに新規なエレメントを挿入すべきかを決定するために、またはサブツリーのさらなるパーティション分割をトリガするか否かを決定するために、対象のサブツリー内の基本データエレメントの各々の名前またはコンテンツのさらなるバイトが必要であり得る。これら付加的なバイトが必要であるので、新規なエレメントに対してこれらのエレメント毎に関連の区別バイトを抽出するために、対象の基本データエレメントのうちのいくつかをフェッチすることが必要であり得る。このタスクに必要なＩＯの数を減らして最適化する（かつ、ほとんどの場合は完全になくす）ために、リーフノード内のデータ構造は、そのリーフノード下の各基本データエレメントの名前からの一定数の付加的なバイトを含む。これら付加的なバイトはナビゲーションルックアヘッドバイトと称され、新規な受信エレメントに対して基本データエレメントをソートするのに役立つ。所与の基本データエレメントについてのナビゲーションルックアヘッドバイトは、基本データエレメントがシーブにインストールされると、リーフノード構造にインストールされる。この目的で保持すべきバイトの数は、関与するサブツリーの深さ、およびそのサブツリー内の基本データエレメントの密度を含むさまざまな基準を用いて静的にまたは動的に選択され得る。たとえば、ツリーの浅いレベルにインストールされている基本データエレメントについては、このソリューションは、非常に深いツリー内に存在する基本データエレメントに対してよりも長いナビゲーションルックアヘッドフィールドを追加し得る。また、新規なエレメントがシーブにインストールされており、かつ既存のターゲットサブツリー内に多くの基本データエレメントが既にある（差し迫った再パーティション分割の可能性が高い）場合は、付加的なナビゲーションルックアヘッドバイトは、新規な基本データエレメントがサブツリーにインストールされている間、その新規な基本データエレメントのために保持され得る。
【０１０５】
図３Ｈは、ナビゲーションルックアヘッドフィールドを含むリーフノードについてのリーフノードデータ構造を提示する。このデータ構造は、（Ａ）ルートノードからこのリーフノードへのパスに関連する情報であって、以下のコンポーネントのすべてまたはサブセットを含む：名前からこのリーフノードに到達するためのバイトの実際のシーケンス、ルートノードからこのノードに到達するために消費する名前のバイトの数、この消費するバイトの数が何らかの予め指定された閾値よりも大きいか否かの指示、ならびに、このノードへのパスを記述し、ツリーのコンテンツ連想検索に、およびツリーの構築に関連する決定に有用な他のメタデータ、（Ｂ）ノードが有する子の数を指定し、（Ｃ）各子（各子はリーフノード下の１つの基本データエレメントに対応する）について、（１）子ＩＤ、（２）基本データエレメントへのツリーのこのリンクを下位に移行させるために名前の後続バイトから必要とされる区別バイトの数、（３）それをこのレッグにダウンさせるバイトの実際値についての仕様、（４）ツリーのこのパス上のツリーを終了させる基本データエレメントの参照、（５）何バイトのナビゲーションルックアヘッドが基本データエレメントのために保持されているか、およびそれらのバイトの実際値を指定するナビゲーションルックアヘッドフィールド、（６）いくつの重複および導出物がこの基本データエレメントを指しているかのカウント（これは、ストレージシステム内のデータが削除されるとシーブからエントリを削除可能であるか否かを確かめるために用いられる）、ならびに（７）基本データエレメントのサイズを含む基本データエレメントについての他のメタデータ等を指定する。
【０１０６】
いくつかの実施形態では、ツリーのさまざまなブランチを用いて、子サブツリーに至るリンクに沿った区別バイトを範囲デリミタと解釈することによって形成されるグループまたは範囲にさまざまなデータエレメントがマップされる。その子サブツリー内のすべてのエレメントは、エレメント内の対応するバイトの値が、特定の子サブツリーへのリンクに指定される区別バイトの値以下となるようなものである。ゆえに、各サブツリーはこうして、特定の範囲内に収まる値を有するエレメントのグループを表わすことになる。所与のサブツリーの内部で、ツリーの各後続レベルはエレメントのセットをより小さい範囲に漸進的に分割する。本実施形態は、図３Ｆに示す自己記述ツリーノード構造のコンポーネントに異なる解釈を提供する。図３ＦのＮ個の子は、ツリーノードデータ構造内でそれらの区別バイトの値によって順序付けられ、非重複範囲の順序付けられたシーケンスを表わす。Ｎ個のノードに対して、Ｎ＋１個の範囲が存在し、最低のまたは１番目の範囲は最小エントリ以下の値を含み、Ｎ＋１番目の範囲はＮ番目のエントリよりも大きい値を含む。Ｎ＋１番目の範囲は範囲外として取扱われるので、Ｎ個のリンクは下位のＮ個のサブツリーまたは範囲に至る。
【０１０７】
たとえば、図３Ｆでは、子１は最低範囲を規定しており、その範囲を区別するために（abef12d6743aの値の）６バイトを使用しており、子１の範囲は00000000からabef12d6743aである。候補エレメントの対応する６バイトは、終了値を含むこの範囲内に収まり、この子についてのリンクが選択される。候補エレメントの対応する先頭６バイトが範囲デリミタabef12d6743aよりも大きい場合、子１は選択されない。候補が子２の範囲内に収まるか否かを調べるためには、２つの条件を満たす必要があり、第１に、候補は直前の子（この例では子１）の範囲外にある必要があり、第２に、その名前の中の対応するバイトは子２の範囲デリミタ以下である必要がある。この例では、子２の範囲デリミタはdcfaの値の２バイトで記述されている。ゆえに、候補エレメントについての対応する２バイトはdcfa以下である必要がある。この方法を用いて、ツリーノード内の候補エレメントおよびすべての子を調べて、Ｎ＋１個の範囲のうちのどれに候補エレメントが収まるかを確認することができる。図３Ｆに示す例では、候補エレメントの名前の対応する４バイトが、f3231929である子Ｎへのリンクについての区別バイトの値よりも大きい場合、欠落状態が検出される。
【０１０８】
ツリーナビゲーションプロセスは、この新たな範囲ノードを収容するように修正され得る。範囲ノードに到着すると、そのノードから発生する所与のリンクを選択するために、候補の名前からのバイトは、その特定のリンクについて規定された範囲内に収まる必要がある。候補の名前からのバイトの値が、すべてのリンク内の対応するバイトの値よりも大きく、候補エレメントが下位のサブツリーが跨っているすべての範囲外にある場合−この場合（「範囲外状態」と称する）、欠落状態が検出され、ツリーナビゲーションプロセスは終了する。候補エレメントの名前の先頭バイトが、子サブツリーに至るリンクに沿った対応する区別バイトによって決定される範囲内に収まる場合、ツリーナビゲーションは下位のそのサブツリーに継続する。「範囲外状態」のために終了しない限り、ツリーナビゲーションは、リーフノードデータ構造に到達するまでツリーの下方へとより深く漸進的に継続し得る。
【０１０９】
この種類の範囲ノードは、図３Ａ〜図３Ｅに記載のトライノードとともにツリー構造において使用され得る。いくつかの実施形態では、ツリー構造の一定数のレベルの上位ノードがトライノードであり得、ツリーの横断は、候補エレメントの名前の先頭バイトと、ツリーのリンクに沿った対応するバイトとの正確な一致に基づいている。後続のノードは範囲ノードであり得、ツリーの横断は、候補エレメントの名前の対応するバイトが収まる範囲によって決まる。ツリーナビゲーションプロセスが終了すると、本文書で上述したように、さまざまな基準を用いて、コンテンツ連想ルックアップ全体の結果として何を戻すべきかが決定され得る。
【０１１０】
ツリーノードおよびリーフノードを表現および使用するための方法および装置の上記の説明は、例示および説明目的で提示されているに過ぎない。それらは網羅的であること、または本発明を開示された形態に限定することを意図していない。したがって、多くの変更および変形が当業者に明らかになるであろう。
【０１１１】
候補エレメントが入力として提示されると、上記のツリーノードおよびリーフノード構造を横断することができ、ツリーのコンテンツ連想ルックアップを候補エレメントのコンテンツに基づいて実行することができる。候補エレメントの名前は、基本データエレメントがシーブにインストールされたときに基本データエレメントの名前が基本データエレメントのコンテンツから構築されたのと同様に、候補エレメントのバイトから構築される。入力候補エレメントを前提として、ツリーのコンテンツ連想ルックアップのための方法は、候補エレメントの名前を用いるツリー構造のナビゲーションを伴い、その後、分析およびスクリーニングが続いて行われて、コンテンツ連想ルックアップ全体の結果として何を戻すべきかが決定される。言い換えると、ツリーナビゲーションプロセスは第１の結果を戻し、次に、その結果に対して分析およびスクリーニングが行なわれて、コンテンツ連想ルックアップ全体の結果が判定される。
【０１１２】
候補と同じ名前の先頭バイト（またはそれらが同じ範囲に収まるようなバイト）を有する基本データエレメントがある場合、ツリーは、リンクによって示されるエレメントのサブツリーの形態の基本データエレメントのそのサブセットを識別する。一般的に、各ツリーノードまたはリーフノードは、ツリーナビゲーションプロセスが、存在する場合はどの送信リンクを選択すべきかを判断して、入力エレメントの名前の対応するバイトと、選択されたリンクに沿ってツリーがナビゲートされると到達するノードのアイデンティティとに基づいてツリー内の次の下位レベルにナビゲートすることを可能にする情報を記憶し得る。各ノードがこの情報を含んでいる場合は、ツリーナビゲーションプロセスは、一致が見つからなくなるまで（この点で、ツリーナビゲーションプロセスは、現在のノードをルートとするサブツリー内に存在する一組の基本データエレメントを戻すことができる）、または基本データエレメントに到達するまで（この点で、ツリーナビゲーションプロセスは、基本データエレメントおよび任意の関連のメタデータを戻すことができる）、ツリー内の各レベルに再帰的にナビゲートダウンし得る。
【０１１３】
ツリーナビゲーションプロセスが終了すると、他の基準および要件を用いてツリーナビゲーションプロセスの結果が分析されスクリーニングされて、コンテンツ連想ルックアップ全体の結果として何を戻すべきかが決定され得る。まず、候補と共通の名前から最多数の先頭バイトを有する基本データエレメントを選ぶことができる。次に、１つの基本データエレメントまたは複数の基本データエレメントがツリーナビゲーションプロセスによって戻された場合は、それらは、コンテンツ連想ルックアップの結果として戻される資格を得る前に、候補エレメントの名前と一定の最小数のバイトを共有しているという付加的な要件があり得る（そうでない場合、コンテンツ連想ルックアップは欠落を戻す）。スクリーニング要件の別の例は、ツリーナビゲーションプロセスが、複数の基本データエレメント（ツリーナビゲーションが終了したノードをルートとする）がツリーナビゲーションプロセスの結果として戻されるように、１つも基本データエレメントに到達することなく終了した場合は、これら複数の基本データエレメントは、これらエレメントの数が４〜１６個のエレメントといった一定の指定された制限未満である場合にのみ、コンテンツ連想ルックアップ全体の結果として戻される資格を得るようなものであってもよい（そうでない場合、コンテンツ連想ルックアップは欠落を戻す）。複数の要件同士の組合せを使用して、コンテンツ連想ルックアップの結果を判定してもよい。複数の候補がまだ残っている場合は、ナビゲーションルックアヘッドバイトおよび関連のメタデータを調べて、どの基本データエレメントが最適であるかを決定してもよい。選択を１つの基本データエレメントにまだ狭めることができない場合は、複数の基本データエレメントを導出関数に供給してもよい。このように、ルックアッププロセスは、「欠落」を報告するかもしくは１つの基本データエレメントを戻し、または１つの基本データエレメントでない場合は、候補エレメントを導出するための良好な開始点である可能性が高い一組の基本データエレメントを戻す。
【０１１４】
ツリーは、効率的なコンテンツ連想アクセスのために設計される必要がある。バランスの取れたツリーは、データの大部分について同程度のアクセス深度を提供する。ツリーのいくつかの上位レベルはプロセッサキャッシュ内に、次のいくつかのレベルは高速メモリ内に、その後続レベルはフラッシュストレージに存在していることが多いと予想される。超大型データセットについては、１つ以上のレベルがフラッシュストレージ内に、またはさらにはディスク内に存在しなければならない可能性もある。
【０１１５】
図４は、本明細書に記載のいくつかの実施形態に従う、２５６ＴＢの基本データがどのようにツリー形態に組織化され得るかの例を示し、当該ツリーがどのようにメモリおよびストレージ内にレイアウトされ得るかを提示する。ノード毎に６４（２6）個の子の平均ファンアウトを仮定して、基本データエレメントの参照は、（平均して）ツリーの第６レベル（すなわち５個のリンク横断またはホップの後）に存在している（たとえば図３Ｈに示すような）リーフノードデータ構造に到達することによってアクセスされ得る。したがって、５個のホップ後のツリーの第６レベルにおけるそのような構造は、さらに２30個のそのようなノードに沿って存在し、各々が平均６４個の子（これらの子は基本データエレメントの参照である）を有するので、約６４０億個の基本データエレメントを収容している。４ＫＢのエレメントサイズでは、これによって２５６ＴＢの基本データエレメントが収容される。
【０１１６】
ツリーは、以下のようにツリーの６レベルを横断することができるようにレイアウトされ得る：オンチップキャッシュ内に存在する３レベル（約２５６Ｋ個のノードへのリンクのための移行を指定する約４０００個の「上位レベル」ツリーノードデータ構造を含む）、メモリ内の２レベル（約１０億個のリーフノードへのリンクのための移行を指定する１６００万個の「中位レベル」ツリーノードデータ構造を含む）、およびフラッシュストレージ内の第６レベル（１０億個のリーフノードデータ構造を収容する）。フラッシュストレージ内のツリーのこの第６レベルに存在している１０億個のリーフノードデータ構造は、６４０億個の基本データエレメントの参照（リーフノード毎に平均で６４個のエレメント）を供給する。
【０１１７】
図４に示す例では、第４および第５レベルにおいて、各ノードは平均で１６バイト／エレメント（子ＩＤに１バイト、たとえばＰＤＥの６バイト参照、およびさらに、バイトカウントに１バイト、およびさらに、実際の移行バイトを指定するために平均で８バイト、および何らかのメタデータ）を費やす。第６レベルにおいて、各リーフノードは平均で４８バイト／エレメント（子ＩＤに１バイト、バイトカウントに１バイト、実際の移行バイトを指定するために８バイト、基本データエレメントの６バイト参照、この基本データエレメントからの導出物のカウントのために１バイト、ナビゲーションルックアヘッドの１６バイト、基本データエレメントのサイズに２バイト、および１３バイトの他のメタデータ）を費やし、したがって、ツリーに必要なフラッシュストレージ内の全容量（基本データエレメントの参照を含み、いずれかのメタデータを含む）は約３テラバイトである。ツリーの上位ノードに必要な全容量はこのサイズのほんの一部である（ノードが少なく、子ノードのより緊密な参照を指定するのに必要なバイトが少なくて済み、ノード毎に必要なメタデータが少なくて済むため）。この例では、上位ツリーノードは平均で８バイト／エレメント（子ＩＤに１バイト、バイトカウントに１バイト、およびさらに、実際の移行バイトを指定するために平均で３〜４バイト、および子ノードの２〜３バイト参照）を費やす。全体として、この例では、２５６ＴＢの基本データを有する合成データセットが、３ＴＢ（または２５６ＴＢの１．１７％）の付加的な装置を用いて１０億個のグループにソートされる。
【０１１８】
２５６ＴＢの基本データの各々が４ＫＢの６４０億個の基本データエレメントを含む図４に示す例では、６４０億個の基本データエレメント同士を完全に区別するために５バイト（または３６ビット）未満のアドレスが必要である。コンテンツ連想の観点から、データの混合が、平均４バイトの漸進的な名前が最初の３レベルの各々で消費され、８バイトが次の３レベルの各々で消費されるようなものである場合、（平均で）合計３６バイト（２８８ビット）の名前が６４０億個の基本データエレメントのすべてを区別することになる。これら３６バイトは、各エレメントを構成する４ＫＢの１％未満である。４ＫＢの基本データエレメントがそのバイトの１％（またはさらには５〜１０％）によって識別可能である場合は、（バイトの大半を構成する）残りのバイトはゆらぎに耐えることができ、そのようなゆらぎを有する候補でもこの基本データエレメントに到達することができ、そこからの導出のために考慮され得る。
【０１１９】
なお、（下位のさまざまな下位のサブツリー同士を区別するための）任意の所与のリンク上に必要なバイトの数は、データセットを含むエレメントの混合内の実際のデータによって支配される。同様に、所与のノードから出るリンクの数もデータによって異なる。自己記述ツリーノードおよびリーフノードデータ構造は、実際の数、およびリンク毎に必要なバイトの値、および任意のノードから発生するリンクの数を宣言する。
【０１２０】
ツリーのさまざまなレベルで費やされるキャッシュ、メモリ、およびストレージの量を制限するようにさらに制御して、入力を、増分ストレージの割当てられたバジェット内で可能な限り多くの区別されたグループにソートすることができる。エレメント同士を完全に区別するために非常に深いサブツリーを必要とするデータの密度およびポケットが存在する状況に対処するために、そのような密度は、大きい一組の関連のエレメントをツリーの一定の深さ（たとえば第６レベル）におけるフラットなグループにグループ分けし、これらに対して合理化された検索および導出を行なうことによって（まずナビゲーションルックアヘッドおよびメタデータを調べて最良の基本データエレメントを判定するか、または（フォールバックとして）残りのデータについて当該方法によって与えられる全導出ではなく重複のみを探すことによって）効率的に対処され得る。これによって非常に深いツリーの作成が回避される。別の代替案は、これらのレベルが利用可能なメモリに収まる限り、（多くのレベルを有する）深いツリーを許可することである。より深いレベルがフラッシュまたはディスクにスピルアウトした瞬間に、ツリーをそのレベルから前方にフラット化して、待ち時間を最小化するための工程を取ることができ、そうしなければ、フラッシュまたはディスクに記憶されたツリーノードのより深いレベルへの複数の連続アクセスによって待ち時間が発生する。
【０１２１】
多くの場合、各基本データエレメントを識別するのに、エレメントの名前からの全バイトの比較的小さい一部で十分であると予想される。本明細書に記載の実施形態を用いてさまざまな実世界データベースに対して行なった研究では、基本データエレメントのバイトの小さいサブセットがエレメントの大半を順序付けてソリューションを可能にする役割を果たすことが確認されている。ゆえに、そのようなソリューションは、そのオペレーションのために必要なストレージの量の観点で効率的である。
【０１２２】
図４の例に必要なアクセスの観点から、４ＫＢのチャンクの入力（または候補エレメント）を受信するごとに、スキームはツリー構造に問合せてリーフノードに到達するために以下のアクセスを必要とする：３つのキャッシュ参照、２つのメモリ参照（または場合によっては複数のメモリ参照）、およびさらに、リーフノードデータ構造にアクセスするためのフラッシュストレージからの１回のＩＯ。ストレージからのこの１回のＩＯは４ＫＢのページをフェッチし、これは、対象の基本データエレメントに費やされる４８バイトを含む、約６４個のエレメントのグループについてのリーフノードデータ構造の情報を保持する。これら４８バイトは、対象の基本データエレメントについてのメタデータを含む。これによってツリールックアッププロセスが終了する。続いて、必要なＩＯの回数は、候補エレメントが重複であるか、導出物であるか、またはシーブにインストールすべき新規な基本データエレメントであるかに依存する。
【０１２３】
基本データエレメントの重複である候補エレメントは、基本データエレメントをフェッチして当該重複を検証するために１回のＩＯを必要とする。重複が検証されると、ツリー内のメタデータを更新するためにもう１回ＩＯがある。したがって、重複エレメントの取込みにはツリールックアップの後に２回のＩＯが必要であり、全部で３回のＩＯが必要である。
【０１２４】
ツリールックアップに失敗し、重複でも導出物でもない候補エレメントは、当該エレメントを新たな基本データエレメントとしてシーブに記憶するためにもう１回のＩＯ、およびツリー内のメタデータを更新するためにさらにもう１回のＩＯを必要とする。ゆえに、ツリールックアップに失敗する候補エレメントの取込みにはツリールックアップ後に２回のＩＯが必要であり、全部で３回のＩＯが必要である。しかし、ツリールックアッププロセスがストレージＩＯを必要とせずに終了する候補エレメントについては、そのような候補エレメントを取込むためには全部で２回のＩＯで済む。
【０１２５】
導出物である（しかし重複ではない）候補エレメントはまず、導出を計算するために必要な基本データエレメントをフェッチするために１回のＩＯを必要とする。ほとんどの場合、導出は（複数ではなく）１つの基本データエレメントからのものであると予想されるので、基本データエレメントをフェッチするには１回のＩＯのみで済むと予想される。導出の完了が成功したのに続いて、再構成プログラムおよび導出詳細を記憶されるエレメントについて作成されたエントリに記憶するためにもう１回のＩＯが、かつ新たな導出物を反映するようにツリー内のメタデータ（カウントなど）を更新するためにさらにもう１回のＩＯが必要となる。したがって、導出物となる候補エレメントの取込みには第１のツリールックアップの後にさらに３回のＩＯが必要であり、全部で４回のＩＯが必要である。
【０１２６】
要約すると、（超大型データセット全体にわたってグローバルに冗長を利用しつつ）候補エレメントを取込み、当該候補エレメントにData Distillation（商標）法を適用するためには、約３回から４回のＩＯが必要である。旧来のデータ重複排除技術が必要とするものと比較して、これは典型的に候補エレメント毎にＩＯが１回増えただけであり、その見返りに、エレメント自体よりも細かくデータセット全体にわたってグローバルに冗長を利用することができる。
【０１２７】
２５０，０００回のランダムＩＯアクセス／秒（４ＫＢのページへの１ＧＢ／秒のランダムアクセスの帯域幅を意味する）を提供するストレージシステムは、約６２，５００個の入力チャンク／秒（各々が４ＫＢの平均サイズの入力チャンク毎に４回のＩＯで分割される２５０，０００個）に対してData Distillation（商標）法を取込んで実行することができる。これによって、ストレージシステムの全帯域幅を使い果たしつつ２５０ＭＢ／秒の取込速度が可能になる。ストレージシステムの帯域幅の半分のみが用いられる（したがって残りの半分は記憶データのアクセスに利用可能である）場合も、そのようなData Distillation（商標）システムはやはり１２５ＭＢ／秒の取込速度を提供可能である。ゆえに、十分な処理能力を前提として、Data Distillation（商標）システムは、無駄のないＩＯで（エレメント自体よりも細かく）データセット全体にわたってグローバルに冗長を利用することができ、現在のストレージシステムに対して数百メガバイト／秒の取込速度でデータ削減を提供することができる。
【０１２８】
ゆえに、試験結果によって確認されたように、本明細書に記載の実施形態は、無駄のないＩＯアクセスで、装置に必要な最小の増分ストレージで、莫大なデータストアからエレメントがあるかを検索する（導出を指定するのに必要な最小ストレージで、そこから入力エレメントが導出され得る）複雑なタスクを達成する。このように構築されたこのフレームワークによって、エレメントの全バイトのより小さい割合を用いて導出に好適なエレメントを見つけることが実行可能になり、バイトの大部分がゆらぎおよび導出に利用可能になる。このスキームがほとんどのデータに対して効率的に働く理由を説明する重要な洞察は、ツリーが、シーブ内のエレメントを特定する区別バイトおよび識別バイトの位置を特定することができる使いやすい細かい構造を提供することであり、これらのバイトは各々がデータ内の異なる深さおよび位置にあるが、それらをツリー構造内で効率的に分離して記憶できることである。
【０１２９】
図５Ａ〜図５Ｃは、本明細書に記載の実施形態を用いてデータがどのように組織化され得るかの実際の例を示す。図５Ａは、５１２バイトの入力データ、および因子分解の結果（たとえば図２のオペレーション２０２を実行した結果）を示す。この例では、フィンガープリンティングが適用されてデータ内のブレークが求められるので、連続するブレークが候補エレメントを識別する。交互に現われる候補エレメントは太字および通常フォントを用いて示されている。たとえば、第１の候補エレメントは「b8ac83d9dc7caf18f2f2e3f783a0ec69774bb50bbe1d3ef1ef8a82436ec43283 bc1c0f6a82e19c224b22f9b2」であり、次の候補エレメントは「ac83d9619ae5571ad2bbcc15d3e493eef62054b0 5b2dbccce933483a6d3daab3cb19567dedbe33e952a966c49f3297191cf22aa3 1b98b9dcd0fb54a7f761415e」である、などである。図５Ａの入力は、示されるように１２個の可変サイズの候補エレメントに因子分解される。各チャンクの先頭バイトを用いてエレメントがシーブ内に順序付けられて組織化される。図５Ｂは、図５Ａに示す１２個の候補エレメントが、それらの名前を用いて、かつ図３Ｂに記載のツリー構造を用いて、どのようにツリー形態でシーブ内に基本データエレメントとして組織化され得るかを示す。各エレメントは、当該エレメントのコンテンツ全体から構築される別個の名前を有する。この例では、フィンガープリンティングが適用されて１２個の候補エレメント同士の間のブレークが求められるので、各候補エレメントの先頭バイトは既にアンカーフィンガープリントと整列していることになる。したがって、各名前の先頭バイトは、このフィンガープリントをアンカーとするコンテンツの第１の次元からすでに構築されていることになる。名前の先頭バイトはさまざまなエレメントを組織化する。たとえば、エレメントの名前の最初のバイトが「0x22」と等しい場合は、トップリンクを取って基本データエレメント♯１を選択する。なお、図５Ｂのさまざまなリンクは、図３Ｂに示すツリーデータ構造を参照して説明したようにさまざまな数のバイトを用いて区別される。
【０１３０】
図５Ｃは、図５Ａに示す１２個の候補エレメントが、図３Ｄを参照して説明したツリーデータ構造を用いてどのように組織化され得るかを示す。フィンガープリンティングが各エレメントのコンテンツにさらに適用されて、エレメントのコンテンツ内の２次フィンガープリントが識別される。第１のフィンガープリント（各エレメントの境界に既に存在している）および第２のフィンガープリントの場所から抽出されたコンテンツのバイトが連結されて名前の先頭バイトが形成され、これを用いてエレメントが組織化される。言い換えると、名前のエレメントは以下のように構築される：２つの次元またはフィールド（それぞれアンカーフィンガープリントおよび２次フィンガープリントによって位置を特定される）からのデータのバイトが連結されて名前の先頭バイトが形成され、残りのバイトがそれに続く。この名前の構築の選択の結果として、バイトのさまざまなシーケンスによってさまざまな基本データエレメントが（図５Ｂに対して）図５Ｃにおいてもたらされる。たとえば、基本データエレメント♯４に到達するために、ツリーナビゲーションプロセスはまず、第１の次元（すなわち第１のフィンガープリント）におけるフィールドの先頭バイトである「46093f9d」に対応するリンクを取り、次に、第２の次元（すなわち第２のフィンガープリント）に位置するフィールドの先頭バイトである「c4」に対応するリンクを取る。
【０１３１】
図６Ａ〜図６Ｃは、本明細書に記載のいくつかの実施形態に従う、それぞれ図１Ａ〜図１Ｃを参照して説明したコンテンツ連想マッパー１２１および１２２にどのようにツリーデータ構造が使用され得るかを示す。
【０１３２】
好適な基本データエレメント（そこから候補エレメントを導出することを試みる）を探すという困難な問題が解決すると、問題は、基本データエレメントの１つまたは小さいサブセットを調べること、および、導出を指定するのに必要な最小ストレージでそれらから候補エレメントを最適に導出することに絞り込まれる。他の目的として、ストレージシステムへのアクセス数を最小限に維持すること、ならびに導出時間および再構成時間を許容可能に維持することがある。
【０１３３】
導出部は、１つ以上の基本データエレメントに対して行った変換の結果として候補エレメントを表現する必要があり、これらの変換を、データが取出されると導出物を再生成するために用いられる再構成プログラムとして指定する必要がある。各導出では、その固有のプログラムを構築する必要があり得る。導出部の機能は、これらの変換を識別し、再構成プログラムを最小フットプリントで作成することである。１つ以上の基本データエレメントに対して、または各エレメントの特定のフィールドに対して実行される算術、代数、または論理演算を含む、さまざまな変換が使用され得る。また、１つ以上の基本データエレメントにおけるバイトの連結、挿入、置換、および削除といった、バイト操作変換を用いてもよい。
【０１３４】
図７Ａは、本明細書に記載のいくつかの実施形態に従う、再構成プログラム内に指定され得る変換の例を提供する。この例で指定される変換の語彙は、エレメント内の特定長さのフィールドに対する算術演算、ならびに、基本データエレメント内の指定されたオフセットにおける宣言された長さのバイトの挿入、削除、付加、および置換を含む。さまざまな技術および演算が導出部によって使用されて、候補エレメントと１つ以上の基本データエレメントとの間の類似および相違が検出され、再構成プログラムが構築され得る。導出部は、根本的なハードウェアにおいて利用可能な語彙を利用してその機能を実行し得る。この作業の最終結果は、再構成プログラムについて指定される語彙で変換を指定すること、および、最小量の増分ストレージを用いて、高速データ取出しをも可能にする態様でそれを行なうことである。
【０１３５】
導出部は、根本的なマシンの処理能力を利用し、自身に割当てられた処理予算内で作業して、システムのコストパフォーマンス制約内で可能な最良の分析を提供する。マイクロプロセッサコアがより容易に利用可能であると仮定して、かつストレージへのＩＯアクセスが高価であると仮定して、Data Distillation（商標）ソリューションは、現在のマイクロプロセッサの処理能力を利用して、数個の基本データエレメントから候補エレメントのコンテンツの局所的な分析および導出を効率的に行なうように設計されている。（超大型データに対する）Data Distillation（商標）ソリューションのパフォーマンスは、計算処理によってではなく典型的なストレージシステムのＩＯ帯域幅によって速度が制限される。たとえば、２５０，０００回のＩＯ／秒をサポートする典型的なフラッシュベースのストレージシステムに対して数百メガバイト／秒の取込速度をサポートするために必要な計算および分析を行なうのに、２、３個のマイクロプロセッサコアで十分であると予想される。なお、インテルXeonプロセッサＥ５−２６８７Ｗ（１０コア、３．１ＧＨｚ、２５ＭＢキャッシュ）といった現在のマイクロプロセッサからの２つのそのようなマイクロプロセッサコアは、プロセッサから利用可能な全計算能力のごく一部（１０分の２）である。
【０１３６】
図７Ｂは、本明細書に記載のいくつかの実施形態に従う、基本データエレメントから導出されている候補エレメントの結果の例を示す。具体的には、データパターン「Elem」は基本データストアに記憶されている基本データエレメントであり、データパターン「Cand」は基本データエレメントから導出すべき候補エレメントである。「Cand」と「Elem」との間の１８個の共通バイトがハイライト表示されている。再構成プログラム７０２は、データパターン「Cand」がデータパターン「Elem」からどのように導出され得るかを指定する。図７Ｂに示すように、再構成プログラム７０２は、１バイトの置換、６バイトの挿入、３バイトの削除、７バイトのバルク置換を用いることによって「Elem」から「Cand」をどのように導出するかを示す。導出物を指定するコストは２０バイト＋３バイト参照＝２３バイトであり、これは元のサイズの６５．７１％である。なお、示される再構成プログラム７０２は人間が読取り可能なプログラムの表現であり、プログラムが本明細書の記載の実施形態によってどのように実際に記憶されるかではない場合がある。同様に、乗算および加算などの算術演算に基づく他の再構成プログラムも図７Ｂに示されている。たとえば、「Elem」がbc1c0f6a790c82e19c224b22f900ac83d9619ae5571ad2bbec152054ffffff83であり、「Cand」がbc1c0f6a790c82e19c224b22f91c4da1aa0369a0461ad2bbec152054ffffff83である場合は、乗算(00ac83d9619ae557)*2a = [00]1c4da1aa0369a046を用いて示されるように８バイトの差が導出され得る。導出物を指定するコストは４バイト＋３バイト参照＝７バイトであり、これは元のサイズの２０．００％である。あるいは、「Elem」がbc1c0f6a790c82e19c224b22f9b2ac83ffffffffffffffffffffffffffffb283であり、「Cand」がbc1c0f6a790c82e19c224b22f9b2ac8300000000000000000000000000002426である場合は、加算を用いて、たとえば、オフセット１６で始まる１６バイト領域に0x71a3を加算して繰り上げを切り捨てることによって、示されるように１６バイトの差が導出され得る。導出物を指定するコストは５バイト＋３バイト参照＝８バイトであり、これは元のサイズの２２．８５％である。なお、図７Ａのサンプル符号化は例示目的で選択されているに過ぎない。図７Ｂの例は３２バイトのデータサイズを有しており、したがって、エレメント内の長さおよびオフセットフィールドには５ビットで十分である。大きいエレメント（たとえば４ＫＢのエレメント）については、これらのフィールドのサイズを１２ビットに増加させる必要がある。同様に、サンプル符号化は３バイトまたは２４ビットの参照サイズを収容する。これによって、１６００万個の基本データエレメントを参照することが可能になるべきである。参照が、たとえば２５６ＴＢのデータ内のいずれかの場所をアドレス指定できる必要がある場合、参照は６バイトのサイズである必要がある。そのようなデータセットを４ＫＢのエレメントに因子分解すると、参照を指定するのに必要な６バイトは４ＫＢのエレメントのサイズのほんの一部である。
【０１３７】
（１つ以上の基本データエレメントから導出される）導出エレメントを指定するのに必要な情報のサイズは、再構成プログラムのサイズと、必要な（１つ以上の）基本データエレメントを指定するのに必要な参照のサイズとの合計である。候補エレメントを導出エレメントとして指定するのに必要な情報のサイズは、基本データエレメントからの候補の距離と称される。候補が複数のセットの基本データエレメントのうちのいずれか１セットから実行可能に導出され得る場合、最短距離を有する基本データエレメントのセットがターゲットとして選択される。
【０１３８】
２つ以上の基本データエレメントから（これらの各々から導出した抽出をアセンブルすることによって）候補エレメントを導出する必要がある場合、導出部は、ストレージシステムへの付加的なアクセスのコストを考慮に入れ、それを、より小さい再構成プログラムおよびより小さい距離の利点と比較検討する必要がある。候補についての最適な再構成プログラムが作成されると、その距離が距離閾値と比較され、距離が閾値を超えない場合は導出が受付けられる。導出が受付けられると、候補エレメントは導出エレメントとして再公式化され、基本データエレメントと再構成プログラムとの組合せで置換される。候補エレメントについて作成された蒸留データへのエントリは、再構成プログラムと、関連の基本データエレメントの１つ以上の参照とで置換される。最良の導出についての距離が距離閾値を超える場合は、導出物は受付けられない。
【０１３９】
データ削減をもたらすために、距離閾値は常に候補エレメントのサイズ未満でなければならない。たとえば、距離閾値は候補エレメントのサイズの５０％に設定されてもよく、これによって、導出物は、そのフットプリントが候補エレメントのフットプリントの半分以下である場合にのみ受付けられることになり、これによって、好適な導出が存在する候補エレメント毎に２倍以上の削減が確実になる。距離閾値は、ユーザが指定した入力に基づく、またはシステムによって選択される、予め定められた割合または分数であってもよい。距離閾値は、システムの静的または動的パラメータに基づいてシステムによって決定されてもよい。
【０１４０】
図８Ａ〜８Ｅは、本明細書に記載のいくつかの実施形態に従う、入力データを固定サイズのエレメントに因子分解し、当該エレメントを図３Ｄおよび図３Ｅを参照して説明したツリーデータ構造に組織化することによってどのようにデータ削減が実行され得るかを示す。図８Ａは、どのように入力データが３２バイトのチャンクに単純に因子分解され得るかを示す。具体的には、図８Ａは最初の１０個のチャンクを、そしてたとえば４２００万個のチャンクの後に現われるさらにいくつかのチャンクを示す。図８Ｂは、名前の先頭バイトが（アンカーフィンガープリント、２次フィンガープリントおよび３次フィンガープリントの場所に対応する）エレメントのコンテンツ内の３つの次元からのコンテンツで構成されるように構築された名前を用いる、シーブ内の基本データエレメントの組織を示す。具体的には、図８Ｂでは、各３２バイトのチャンクが３２バイトの候補エレメント（固定サイズのブロック）になる。フィンガープリンティングの方法がエレメントのコンテンツに適用される。各エレメントは、以下のように構築される名前を有する：エレメントの３つの次元またはフィールド（それぞれアンカーフィンガープリント、２次フィンガープリント、および３次フィンガープリントによって位置が特定される）からのデータのバイトが連結されて名前の先頭バイトが形成され、エレメントの残りのバイトがそれに続く。名前を用いてエレメントがシーブ内に組織化される。図８Ｂに示すように、最初の１０個のチャンクは重複または導出物を含んでおらず、エレメントとしてシーブに順次インストールされる。図８Ｂは、１０番目のチャンクが消費された後のシーブを示す。図８Ｃは、さらに数百万個のデータ入力のエレメントを消費した後の、たとえば次の４２００万個のチャンクが提示された後の、その後の時点におけるシーブのコンテンツを示す。シーブは重複または導出物があるか否か調べられる。エレメントから導出不可能なチャンクはシーブにインストールされる。図８Ｃは、４２００万個のチャンクが消費された後のシーブを示しており、１６，０００，０１０個のエレメント（３バイトの参照アドレスで論理的にアドレス指定可能）を含んでおり、残りの２６，０００，０００個のチャンクは導出物になる。図８Ｄは、続いてシーブに提示されてシーブへの（エレメント番号２４，７８９として示される）エントリの重複として識別される、新規な入力の例を示す。この例では、シーブは、エレメント２４，７８９（チャンク９）をチャンク４２，０００，０１１について最適なエレメントとして識別する。導出関数は、新たなチャンクが正確な重複であると判断し、それをエレメント２４，７８９の参照で置換する。導出物を表わすコストは元の３５Ｂに対して３バイト参照であり、これは元のサイズの８．５７％である。図８Ｄは、シーブ内の（エレメント番号１８７，１２６として示される）エントリの導出物にコンバートされる入力の第２の例（チャンク４２，０００，０１２）を示す。この例では、シーブは正確な一致がないと判断する。シーブは、エレメント１８７，１２５および１８７，１２６（チャンク８および１）を最適なエレメントとして識別する。新たなエレメントは最適なエレメントから導出される。エレメント１８７，１２５に対する導出およびエレメント１８７，１２６に対する導出が図８Ｄに示されている。エレメント１８７，１２５に対する導出を表わすコストは３９バイト＋３バイト参照＝４２バイトであり、これは元のサイズの１２．００％である。エレメント１８７，１２６に対する導出を表わすコストは１２バイト＋３バイト参照＝１５バイトであり、これは元のサイズの４２．８５％である。（エレメント１８７，１２６に対する）最良の導出が選択される。再構成サイズは閾値と比較される。たとえば、閾値が５０％である場合、この導出物（４２．８５％）は受付けられる。図８Ｅは、基本データエレメントから導出されるデータチャンクの２つの付加的な例を提供しており、導出物が２つの基本データエレメントからの導出によって実際に作成される一例を含む。第１の例では、チャンク４２，０００，０１３が提示される。シーブは、エレメント９，２９９，９９８（チャンク１０）を最適なエレメントとして識別する。エレメント９，２９９，９９８に対する導出が図８Ｅに示されている。導出物を表わすコストは４バイト＋３バイト参照＝７バイトであり、これは元のサイズの２０．００％である。再構成サイズは閾値と比較される。たとえば、閾値が５０％である場合、この導出物（２０．００％）は受付けられる。第２の例では、チャンク４２，０００，０１４が提示される。この例では、チャンク４２，０００，０１４は、チャンクの半分がエレメント９，２９９，９９７から最良に導出され得、チャンクの残りの半分がエレメント９，２９９，９９８から最良に導出され得るようなものである。したがって、マルチ導出エレメントが作成されてさらなるデータ削減がもたらされる。マルチエレメント導出は図８Ｅに示されている。マルチ導出エレメントを表わすコストは３バイト参照＋３バイト＋３バイト参照＝９バイトであり、これは元のサイズの２５．７１％である。再構成サイズは閾値と比較され、たとえば閾値が５０％である場合、この導出物（２５．７１％）は受付けられる。なお、単一の導出エレメントからの最良の結果は４５．７１％であったはずである。
【０１４１】
図８Ａ〜８Ｅは、Data Distillation（商標）システムが固定サイズのブロックを消費して生成しつつデータ削減を行うのに効果的であり得るという、Data Distillation（商標）システムの重要な利点を示す。なお、固定サイズのブロックは高パフォーマンスストレージシステムにおいて非常に望ましい。Data Distillation（商標）装置を用いて、多数の固定サイズのブロックで構成される大きい受信入力ファイルが、すべての基本データエレメントが固定サイズであるように、多数の固定サイズのエレメントに因子分解され得る。導出エレメント毎の潜在的に可変サイズの再構成プログラムは互いにパックされて蒸留データファイル内にインラインに維持され得、これは続いて固定サイズのブロックにチャンク分けされ得る。ゆえに、すべての実用的な目的で、ストレージシステム内で固定サイズのブロックを消費して作成しつつ、強力なデータ削減を実行することができる。
【０１４２】
図９Ａ〜図９Ｃは、最初に図１Ｃに示したData Distillation（商標）スキームの例を示す。このスキームは、コンテンツ連想的にアクセスされ得る別個の基本再構成プログラムストアを使用する。そのような構造によって、基本再構成プログラムストア内に既に存在している再構成プログラムを構築する導出物の検出が可能になる。そのような導出物は、既存の再構成プログラムを参照するように再公式化され得る。これによって、再構成プログラム同士の間の冗長の検出が可能になる。図９Ａでは、入力データが取込まれる。フィンガープリンティングの方法が当該データに適用され、フィンガープリント位置にチャンク境界が設定される。入力は、示されるように８個の候補エレメント（図９Ａにおいて太字および正規のフォントで示される交互に現われるチャンク）に因子分解される。図９Ｂでは、８個の候補エレメントがシーブ内に組織化されて示されている。各エレメントは、当該エレメントのコンテンツ全体から構築される別個の名前を有する。この例では、エレメントの名前は以下のように構築される：２つの次元またはフィールド（それぞれアンカーフィンガープリントおよび２次フィンガープリントによって位置を特定される）からのデータのバイトが連結されて名前の先頭バイトが形成され、残りのバイトがそれに続く。この名前を用いてシーブ内にエレメントが順序付けられ、また、ツリー構造を介してシーブへのコンテンツ連想アクセスが提供される。図９Ｂはさらに、基本再構成プログラムを含む第２のコンテンツ連想構造を示す。図９Ｃは重複再構成を示す。いずれの基本データエレメントの重複でもない５５バイトの候補エレメント（図９Ｃに示す）が到着すると仮定する。エレメント３が最適なエレメントとして選択され、最初の２つの次元はＰＤＥ２および３について同一であるが、８８ａ７で始まる残りのバイトはエレメント３と一致する。新たな入力は、１２バイト再構成プログラム（ＲＰ）を用いてエレメント３から導出される。符号化は図７Ａに示すようなものである。なお、この例については、最大エレメントサイズは６４ビットであり、すべてのオフセットおよび長さは、図７Ａに示す５ビットの長さおよびオフセットとは対照的に、６ビット値として符号化される。ＲＰストアが検索され、この新たなＲＰは見つけられない。このＲＰは基本ＲＰストアに挿入され、その値に基づいて順序付けられる。新たなエレメントは、ＲＰストア内の基本データエレメント３の参照、および参照４における新たに作成された基本再構成プログラムの参照として再公式化される。この導出エレメントについての全ストレージサイズは、３バイトのＰＤＥ参照、３バイトのＲＰ参照、１２バイトのＲＰ＝１８バイトであり、これは、それをＰＤＥとして記憶することに対して、サイズの３１．０％である。その後、５５バイトの候補エレメントのコピーが到着すると仮定する。前と同様に、エレメント３に基づいて１２バイトのＲＰが作成される。ＲＰストアが検索され、基本ＲＰ  ＩＤ＝３、ＲＰ参照＝４を有するＲＰが見つけられる。この候補エレメントは、基本データエレメント３の参照および再構成プログラム４の参照としてシステム内に表わされる。この導出エレメントについて追加される��ストレージサイズは、３バイトのＰＤＥ参照、３バイトのＲＰ参照＝６バイトとなり、これは、それをＰＤＥとして記憶することに対して、サイズの１０．３％である。
【０１４３】
図１０Ａは、本明細書に記載のいくつかの実施形態に従う、再構成プログラム内に指定された変換がどのように基本データエレメントに適用されて導出エレメントをもたらすかの例を提供する。この例は、１８７，１２６と番号付けられた基本データエレメント（この基本データエレメントは図８Ｃのシーブ内にも示されている）に、示される再構成プログラムによって指定されるような４つの変換（挿入、置換、削除、および付加）を適用することによって当該基本データエレメントから生成されるように指定された導出エレメントを示す。図１０Ａに示すように、エレメント１８７，１２６がシーブからロードされ、再構成プログラムが実行されてエレメント１８７，１２６からチャンク４２，０００，０１２が導出される。図１０Ｂ〜図１０Ｃは、本明細書に記載のいくつかの実施形態に従うデータ取出しプロセスを示す。各データ取出し要求は本質的に蒸留データ内のエレメントの形態を取り、無損失削減フォーマットで検索エンジンに提示される。エレメント毎の無損失削減フォーマットは、関連付けられた基本データエレメントおよび再構成プログラムの参照を含む。Data Distillation（商標）装置の取出部は基本データエレメントおよび再構成プログラムをフェッチし、これらを再構成のために再構成部に供給する。蒸留データのエレメントについての関連の基本データエレメントおよび再構成プログラムがフェッチされた後、再構成部は再構成プログラムを実行して、エレメントをその本来の未削減形態で生成する。再構成を実行するためにデータ取出しプロセスが必要とする労力は、再構成プログラムのサイズおよび基本データエレメントのサイズに対して直線的である。したがって、当該システムによって高いデータ取出率を達成することができる。
【０１４４】
蒸留データ内の無損失削減形態からその本来の未削減形態にエレメントを再構成するためには、当該エレメントについて指定された基本データエレメントおよび再構成プログラムのみをフェッチするだけでよいことが明白である。ゆえに、所与のエレメントを再構成するために、他のエレメントにアクセスするかまたは他のエレメントを再構成することは不要である。このため、Data Distillation（商標）装置は、再構成および取出しの要求のランダムなシーケンスをサービスする場合にも効率的である。なお、Lempel Ziv法といった旧来の圧縮法は、所望のブロックを含むデータのウインドウ全体をフェッチして復元する必要がある。たとえば、ストレージシステムがLempel-Ziv法を利用して３２ＫＢのウインドウを用いて４ＫＢのデータのブロックを圧縮し、次に所与の４ＫＢのブロックをフェッチして復元する場合、３２ＫＢのウインドウ全体をフェッチして復元する必要がある。これは、所望のデータを提供するためにより大きい帯域幅を消費し、より大量のデータを復元する必要があるため、パフォーマンスペナルティを課す。Data Distillation（商標）装置はそのようなペナルティを受けない。
【０１４５】
Data Distillation（商標）装置は、システム内のデータ全体にわたってグローバルに冗長を効率的に発見して利用する態様でデータを組織化して記憶するようにさまざまな方法でコンピュータシステムに統合され得る。図１１Ａ〜図１１Ｇは、本明細書に記載のいくつかの実施形態に従う、Data Distillation（商標）メカニズム（ソフトウェア、ハードウェア、またはそれらの組合せを用いて実現され得る）を含むシステムを示す。図１１Ａは、プロセッサ、メモリおよびデータストレージコンポーネントで構成されるハードウェアプラットフォーム上で実行されるシステムソフトウェア上で動作するソフトウェアアプリケーションを有する汎用計算プラットフォームを提示する。図１１Ｂは、プラットフォームのアプリケーション層に統合されたData Distillation（商標）装置を示しており、各特定のアプリケーションは当該装置を用いてそのアプリケーションのためのデータセット内で冗長を利用する。図１１Ｃは、データ仮想化層またはサービスの上位で動作するすべてのアプリケーションについて当該データ仮想化層またはサービスを提供するように使用されるData Distillation（商標）装置を示す。図１１Ｄおよび図１１Ｅは、サンプル計算プラットフォームのオペレーティングシステム、ファイルシステムおよびデータ管理サービスを有するData Distillation（商標）装置の２つの異なる統合形態を示す。他の統合方法として、図１１Ｆに示すようなフラッシュベースのデータストレージサブシステムにおいて使用されるようなハードウェアプラットフォームにおける埋込計算スタックとの統合があるが、これに限定されない。
【０１４６】
図１１Ｇは、図１１Ｄに示すサンプル計算プラットフォームを有するData Distillation（商標）装置の統合のさらなる詳細を提示する。図１１Ｇは、汎用プロセッサ上のソフトウェアとして実行されるパーサおよび因子分解部、導出部、取出部、ならびに再構成部、ならびにストレージ階層のいくつかのレベルにわたって存在しているコンテンツ連想マッピング構造を有する、Data Distillation（商標）装置のコンポーネントを示す。基本データストアは、（フラッシュベースのストレージドライブといった）記憶媒体内に存在し得る。
【０１４７】
図１１Ｈは、Data Distillation（商標）装置がどのようにサンプル汎用計算プラットフォームに干渉し得るかを示す。
【０１４８】
ファイルシステムは、ファイル（たとえばテキスト文書、スプレッドシート、実行可能ファイル、マルチメディアファイル等）を識別子（たとえばファイル名、ファイルハンドル等）と関連付け、ファイルと関連付けられた識別子を用いることによってファイル上で演算（たとえば読出、書込、挿入、付加、削除等）を実行できるようにする。ファイルシステムによって実現されるネームスペースはフラットであってもよく、または階層状であってもよい。また、ネームスペースは多層化されてもよく、たとえば、最上層識別子が完全に分解されるまで、最上層識別子が、順次下層において１つ以上の識別子に分解されてもよい。このように、ファイルシステムは、ファイルのコンテンツを物理的に記憶する物理データストレージデバイスおよび／または記憶媒体（たとえばコンピュータメモリ、フラッシュドライブ、ディスクドライブ、ネットワークストレージデバイス、ＣＤ−ＲＯＭ、ＤＶＤ等）の抽象化を提供する。
【０１４９】
情報をファイルシステムに記憶するために用いられる物理ストレージデバイスおよび／または記憶媒体は１つまたは複数のストレージ技術を用いてもよく、同一のネットワーク場所に存在してもよいし、または異なるネットワーク場所にわたって分散していてもよい。ファイルおよび当該ファイル上で実行されるように要求される１つ以上の演算と関連付けられた識別子を前提として、ファイルシステムは（１）１つ以上の物理ストレージデバイスおよび／または記憶媒体を識別することができ、（２）当該ファイルシステムによって識別された物理ストレージデバイスおよび／または記憶媒体に、当該識別子と関連付けられたファイル上で実行されるように要求された演算を実行させることができる。
【０１５０】
システム内で読出または書込操作が実行されるたびに、異なるソフトウェアおよび／またはハードウェアコンポーネントが関与し得る。「リーダ」という用語は、所与の読出操作がシステム内で実行される際に関与するシステム内のソフトウェアおよび／またはハードウェアコンポーネントの集まりを指し得、「ライタ」という用語は、所与の書込操作がシステム内で実行される際に関与するシステム内のソフトウェアおよび／またはハードウェアコンポーネントの集まりを指し得る。本明細書に記載のデータ削減のための方法および装置のいくつか実施形態は、所与の読出または書込操作が実行される際に関与するシステムの１つ以上のソフトウェアおよび／またはハードウェアコンポーネントによって利用され得るか、またはそれに組込まれ得る。異なるリーダおよびライタは異なるデータ削減実現例を利用するかまたは組込み得る。しかし、特定のデータ削減実現例を利用するかまたは組込む各ライタは、これも同一のデータ削減実現例を利用するかまたは組込むリーダに対応する。なお、当該システムにおいて実行される読出および書込操作の中には、データ削減装置を利用しないかまたは組込まない操作もある。たとえば、Data Distillation（商標）装置またはデータ削減装置１０３が基本データエレメントを取出すか、または新たな基本データエレメントを基本データストアに追加すると、当該装置はデータ削減なしで読出および書込操作を直接実行することができる。
【０１５１】
具体的には、図１１Ｈにおいて、ライタ１５０Ｗは一般的に、所与の書込操作が実行される際に関与するシステムのソフトウェアおよび／またはハードウェアコンポーネントを指し得、リーダ１５０Ｒは一般的に、所与の読出操作が実行される際に関与するシステムのソフトウェアおよび／またはハードウェアコンポーネントを指し得る。図１１Ｈに示すように、ライタ１５０Ｗは入力データをData Distillation（商標）装置またはデータ削減装置１０３に与え、Data Distillation（商標）装置またはデータ削減装置１０３から蒸留データ１０８を受信する。リーダ１５０Ｒは取出し要求１０９をData Distillation（商標）装置またはデータ削減装置１０３に与え、取出されたデータ出力１１３をData Distillation（商標）装置またはデータ削減装置１０３から受信する。
【０１５２】
図１１Ｈについての実現例として、Data Distillation（商標）装置またはデータ削減装置１０３をアプリケーション、オペレーティングシステムカーネル、ファイルシステム、データ管理モジュール、デバイスドライバ、またはフラッシュもしくはディスクドライブのファームウェアに組込むかまたは利用することがあるが、これらに限定されない。これは、図１１Ｂ〜図１１Ｆに記載のさまざまな構成および使用方法に及ぶ。
【０１５３】
図１２Ａは、本明細書に記載のいくつかの実施形態に従う、帯域幅が制約された通信媒体全体にわたるデータの通信のためのData Distillation（商標）装置の使用を示す。示されるセットアップでは、通信ノードＡは、通信ノードＢに送信すべき一組のファイルを作成する。ノードＡは、Data Distillation（商標）装置を用いて、入力ファイルを、基本データストアにインストールされる基本データエレメントの参照と、導出エレメントのための再構成プログラムとを含む蒸留データまたは蒸留ファイルに変換する。ノードＡは次に、蒸留ファイルを基本データストアとともにノードＢに送信する（基本データストアは、蒸留ファイルを送信する前に、送信するのと同時に、または送信した後に送信され得、さらに、基本データストアは、同一の通信チャネル上で、または蒸留ファイルを送信するために用いられる通信ファイルとは異なる通信チャネル上で送信され得る）。ノードＢは基本データストアをその端における対応の構造にインストールし、続いてノードＢのData Distillation（商標）装置に存在している取出部および再構成部を介して蒸留ファイルを送り、ノードＡが作成した元の一組のファイルをもたらす。ゆえに、Data Distillation（商標）装置を媒体の両端で使用して削減データのみを送信することによって、帯域幅が制約された通信媒体がより効率的に使用される。なお、Data Distillation（商標）を使用することによって、（Lempel-Zivといった従来の技術を用いて実行可能である範囲を超えて）より大きい範囲にわたって冗長を利用することができるので、さらに大型のファイルまたはファイルのグループを効率的に送信することができる。
【０１５４】
次に、複数のノードにわたって分散しているデータをワークグループが共同して共有する広域ネットワークインストールにおけるData Distillation（商標）装置の使用を説明する。データがまず作成されると、当該データは図１２Ａに示すように削減されて通信され得る。広域ネットワークはデータのコピーを各サイトに維持して、当該データへの迅速なローカルアクセスを可能にする。Data Distillation（商標）装置の使用によって各サイトのフットプリントを削減することができる。さらに、続いていずれかのサイトで新規データを取込むと、新規データと既存の基本データストアのコンテンツとの間のいずれかの冗長を利用して新規データを削減することができる。
【０１５５】
そのようなインストールでは、任意の所与のサイトにおけるデータのいずれの修正も、各サイトの基本データストアが一貫して保持されるように、すべての他のサイトに通信する必要がある。したがって、図１２Ｂに示すように、基本データエレメントのインストールおよび削減などの更新、ならびにメタデータ更新は、本明細書に記載のいくつかの実施形態に従って各サイトの基本データストアに通信され得る。たとえば、所与のサイトのシーブに新規な基本データエレメントがインストールされると、基本データエレメントをすべての他のサイトに通信する必要がある。各サイトは、基本データエレメントの値を用いてコンテンツ連想的にシーブにアクセスし、シーブ内のどこに新たなエントリを追加する必要があるかを判断することができる。同様に、所与のサイトのシーブから基本データエレメントが削除されると、この削除を反映するようにすべての他のサイトを更新する必要がある。これが達成され得る１つの方法は、各サイトが基本データエレメントを用いてコンテンツ連想的にシーブにアクセスしてリーフノードへのどのエントリを削除する必要があるかを判断できるように、すべてのサイトに基本データエレメントを、ツリー内の関連リンクへの必要な更新およびストアからのその基本データエレメントの削除とともに通信することによってである。別の方法は、基本データエレメントが存在しているリーフノード内の基本データエレメントについてのエントリの参照をすべてのサイトに通信することである。
【０１５６】
ゆえに、Data Distillation（商標）装置を用いて、広域ネットワークのさまざまなサイトにわたって記憶されているデータのフットプリントを削減し、ネットワークの通信リンクを効率的に使用することができる。
【０１５７】
図１２Ｃ〜図１２Ｋは、本明細書に記載のいくつかの実施形態に従う、さまざまな使用モデルについてData Distillation（商標）装置によって生成される削減データのさまざまなコンポーネントを示す。
【０１５８】
図１２Ｃは、Data Distillation（商標）装置１２０３がどのように一組の入力ファイル１２０１を取込み、蒸留プロセスの完了後に一組の蒸留ファイル１２０５および基本データシーブまたは基本データストア１２０６を生成するかを示す。図１２Ｃの基本データシーブまたは基本データストア１２０６自体は２つのコンポーネント、すなわち、図１２Ｄに示すようなマッパー１２０７および基本データエレメント（またはＰＤＥ）１２０８で構成されている。
【０１５９】
マッパー１２０７自体は内部に２つのコンポーネント、すなわち、ツリー全体を規定する一組のツリーノードデータ構造および一組のリーフノードデータ構造を有する。一組のツリーノードデータ構造は１つ以上のファイルに入れられ得る。同様に、一組のリーフノードデータ構造は１つ以上のファイルに入れられ得る。いくつかの実施形態では、ツリーノードファイルと称される１つのファイルが、所与のデータセット（入力ファイル１２０１）のために基本データエレメントについて作成されたツリーのための一組のツリーノードデータ構造全体を保持し、リーフノードファイルと称される別の１つのファイルが、そのデータセットのための基本データエレメントについて作成されたツリーのための一組のリーフノードデータ構造全体を保持する。
【０１６０】
図１２Ｄでは、基本データエレメント１２０８は、所与のデータセット（入力ファイル１２０１）のために作成された一組の基本データエレメントを含む。一組の基本データエレメントは１つ以上のファイルに入れられ得る。いくつかの実施形態では、ＰＤＥファイルと称される１つのファイルが、所与のデータセットのために作成された一組の基本データエレメント全体を保持する。
【０１６１】
ツリーノードファイル内のツリーノードは、ツリーノードファイル内の他のツリーノードの参照を含む。ツリーノードファイル内のツリーノードの最深層（または最低レベル）は、リーフノードファイル内のリーフノードデータ構造へのエントリの参照を含む。リーフノードファイル内のリーフノードデータ構造へのエントリは、基本データエレメントの参照をＰＤＥファイルに含む。
【０１６２】
ツリーノードファイル、リーフノードファイル、およびＰＤＥファイルは、装置によって作成されるすべてのコンポーネントの詳細を示す図１２Ｅに示されている。図１２Ｅは、ファイル１、ファイル２、ファイル３、…ファイルＮと名付けられたＮ個のファイルを含む一組の入力ファイル１２０１を示しており、当該ファイルはData Distillation（商標）装置によって削減されて、一組の蒸留ファイル１２０５および基本データシーブのさまざまなコンポーネント、すなわち、ツリーノードファイル１２０９、リーフノードファイル１２１０、およびＰＤＥファイル１２１１を生成する。蒸留ファイル１２０５は、file1.dist, file2.dist, file3.dist…fileN.distと名付けられたＮ個のファイルを含む。Data Distillation（商標）装置は入力データをその構成要素に因子分解し、２つのカテゴリのデータエレメント、すなわち基本データエレメントおよび導出エレメントを作成する。蒸留ファイルは無損失削減フォーマットのデータエレメントの記述を含み、ＰＤＥファイル内の基本データエレメントの参照を含む。入力ファイル１２０１内の各ファイルは、蒸留ファイル１２０５内の対応する蒸留ファイルを有する。たとえば、入力ファイル１２０１内のファイル１  １２１２は、蒸留ファイル１２０５内のfile１．distと名付けられた蒸留ファイル１２１３に対応する。
【０１６３】
なお、図１２Ｅは、図１Ａに従う蒸留データおよび基本データストアの組織に基づいてData Distillation（商標）装置によって作成されたさまざまなコンポーネントを示しており、再構成プログラムは蒸留ファイル内のエレメントの無損失削減表現に入れられている。なお、（図１Ｂに従う）いくつかの実施形態では、再構成プログラムを基本データストアに入れて、それらを基本データエレメントと同様に取扱うことができる。蒸留ファイル内のエレメントの無損失削減表現は、（再構成プログラム自体を含むのではなく）基本データストア内の再構成プログラムの参照を含む。これらの実施形態では、再構成プログラムは基本データエレメントと同様に取扱われてＰＤＥファイル１２１１内に生成される。さらに別の実施形態では、図１Ｃに従って、再構成プログラムは、基本データエレメントとは別個に、再構成プログラムストアと称される構造に記憶される。そのような実施形態では、蒸留ファイル内のエレメントの無損失削減表現は、再構成プログラムストア内の再構成プログラムの参照を含む。そのような実施形態では、図１２Ｆに示すように、基本データエレメントのツリー組織のためのツリーノードファイル１２０９、リーフノードファイル１２１０およびＰＤＥファイル１２１１を生成することに加えて、装置は、再構成ツリーノードファイル１２１９および再構成リーフノードファイル１２２０と称される第２の一組のツリーおよびリーフノードファイルを、ＲＰファイル１２２１と称されるすべての再構成プログラムを含むファイルとともに生成する。
【０１６４】
図１２Ｅに示すData Distillation（商標）装置はさらに、ツリーノードファイル１２０９、リーフノードファイル１２１０、ＰＤＥファイル１２１１および蒸留ファイル１２０５の１つ以上における演算を支配する構成および制御情報を記憶する。あるいは、この情報を含む第５のコンポーネントが生成されてもよい。図１２Ｆに示す装置と同様に、構成および制御情報は図１２Ｆに示すさまざまなコンポーネントの１つ以上に記憶されてもよく、またはそれは、この目的で生成された別のコンポーネントに記憶されてもよい。
【０１６５】
図１２ＧはData Distillation（商標）装置の使用の概要を示しており、所与のデータセット（入力データセット１２２１）がData Distillation（商標）装置１２０３に送られ処理されて、無損失削減データセット（無損失削減データセット１２２４）が生成される。入力データセット１２２１は、ファイル、オブジェクト、ブロック、チャンク、またはデータストリームからの抽出の集まりで構成され得る。なお、図１２Ｅは、データセットがファイルで構成される例を示す。図１２Ｇの入力データセット１２２１は図１２Ｅの入力ファイル１２０１に対応し、図１２Ｇの無損失削減データセット１２２４は図１２Ｅに示す４つのコンポーネント、すなわち、図１２Ｅの蒸留ファイル１２０５、ツリーノードファイル１２０９、リーフノードファイル１２１０、およびＰＤＥファイル１２１１を含む。図１２Ｇでは、Data Distillation（商標）装置は、当該装置に提示される入力データセットの範囲全体にわたるデータエレメント同士の間の冗長を利用する。
【０１６６】
Data Distillation（商標）装置は、入力データセットのサブセット全体にわたって冗長を利用し、当該装置に提示されるデータのサブセット毎に無損失削減を提供するように構成され得る。たとえば、図１２Ｈに示すように、入力データセット１２２１は多数のより小さいデータの集まりにパーティション分割され得、各集りは本開示において「ロット」または「データのロット」または「データロット」と称される。図１２Ｈは、入力データロット１２２４を取込んで無損失削減データロット１２２５を生成するように構成されたData Distillation（商標）装置を示す。図１２Ｈは、データロット１、…データロットｉ、…データロットｎである多数のデータの集まりで構成される入力データセット１２２１を示す。このデータは一度に１データロットずつData Distillation（商標）装置に提示され、各データロットの範囲全体にわたって冗長が利用されて無損失削減データロットが生成される。たとえば、入力データセット１２２１からのデータロットｉ１２２６が装置に送られ、無損失削減データロットｉ１２２８が無損失削減データセット１２２７に供給される。入力データセット１２２１からの各データロットは装置に送られ、対応する無損失削減データロットが無損失削減データセット１２２７に供給される。データロット１、…データロットｉ…データロットｎのすべてを消費して削減すると、入力データセット１２２１は無損失削減データセット１２２７に削減される。
【０１６７】
Data Distillation（商標）装置は、設計によって、データのグローバル範囲全体にわたって冗長を利用するのに既に効率的であるが、上記の技術を用いてデータ削減プロセスをさらに迅速化させ、その効率をさらに向上させてもよい。データ削減プロセスのスループットは、データロットのサイズをシステムの利用可能なメモリに収まることができるように制限することによって増加し得る。たとえば、サイズが多くのテラバイト、またはさらにはペタバイトである入力データセットを、各々のサイズがたとえば２５６ＧＢである多数のデータロットに分割することができ、各データロットを迅速に削減することができる。２５６ＧＢのメモリを有するシングルプロセッサコア（インテルXeon  Ｅ５−１６５０  Ｖ３、Haswell ３．５Ｇｈｚプロセッサ）を用いて、２５６ＧＢの範囲全体にわたって冗長を利用するそのようなソリューションが我々の研究所で実現され、さまざまなデータセットに対して２〜３倍の削減レベルを提供しつつ数百メガバイト／秒のデータの取込速度がもたらされた。なお、２５６ＧＢの範囲は、Lempel Ziv法が現代のプロセッサに対して１０ＭＢ／秒から２００ＭＢ／秒の取込みパフォーマンスを提供するウインドウのサイズである３２ＫＢより何百万倍も大きい。ゆえに、冗長の範囲を適切に制限することによって、データ蒸留プロセスの速度の向上が、いくらかの削減を潜在的に犠牲にして達成され得る。
【０１６８】
図１２Ｉは図１２Ｈのセットアップの変形を示しており、入力データセットのデータ削減（およびデータ再構成／取出し）のスループットを大きく高める複数のプロセッサ上で動作する複数のデータ蒸留プロセスを示す。図１２Ｉは、ｘ個のデータロットにパーティション分割された入力データセット１２０１を示しており、ｘ個の独立したデータロットは、独立したプロセッサコア上で動作するｊ個の独立したプロセスに送り込まれ（各プロセスには、それに送り込まれるいずれかのデータロットを収容するのに十分なメモリが割当てられている）、並列に実行され、データ削減および再構成／取出しの両方について約ｊ倍の迅速化をもたらす。図１２Ｊは、使用モデルについてData Distillation（商標）装置によって生成される削減データのさまざまなコンポーネントを示しており、ここでは入力データセットの削減の後にマッパーをもはや保持しなくてもよい。そのような使用モデルの例として、ある種のデータバックアップおよびデータアーカイビングアプリケーションがある。そのような使用モデルでは、削減データの唯一のその後の使用は、削減データセットからの入力データセットの再構成および取出しである。そのようなシナリオでは、データ削減が完了した後にマッパーを記憶しないことによって、削減データのフットプリントをさらに削減することができる。図１２Ｊは装置に送られる入力ファイル１２０１を示しており、当該装置は蒸留ファイル１２０５およびＰＤＥファイル１２１１を生成する、これらコンポーネントはこのシナリオでは削減データを含む。なお、入力ファイル１２０１は、蒸留ファイル１２０５およびＰＤＥファイル１２１１のみを用いて、完全に再生成および回復され得る。蒸留ファイル内のエレメント毎の無損失削減表現は、必要な場合は再構成プログラム、およびＰＤＥファイル内の基本データエレメントの参照を含むことを思い起こされたい。ＰＤＥファイルと結合されると、これは再構成を実行するのに必要なすべての情報である。
【０１６９】
なお、図１２Ｊは、図１Ａに従う蒸留データおよび基本データストアの組織に基づいてData Distillation装置によって作成されるさまざまなコンポーネントを示しており、再構成プログラムは蒸留ファイル内のエレメントの無損失削減表現に入れられる。なお、（図１Ｂに従う）いくつかの実施形態では、再構成プログラムを基本データストアに入れて、それらを基本データエレメントと同様に取扱うことができる。蒸留ファイル内のエレメントの無損失削減表現は、（再構成プログラム自体を含むのではなく）基本データストア内の再構成プログラムの参照を含む。これらの実施形態では、再構成プログラムは基本データエレメントと同様に取扱われてＰＤＥファイル１２１１内に生成される。さらに別の実施形態では、図１Ｃに従って、再構成プログラムは、基本データエレメントとは別個に、再構成プログラムストアと称される構造に記憶される。そのような実施形態では、蒸留ファイル内のエレメントの無損失削減表現は、再構成プログラムストア内の再構成プログラムの参照を含む。そのような実施形態では、基本データエレメントのためのＰＤＥファイルを生成することに加えて、装置は、ＲＰファイルと称されるすべての再構成プログラムを含むファイルをさらに生成する。これは、使用モデルについての削減データのコンポーネントを示す図１２Ｋに示されており、ここではマッパーをもはや保持しなくてもよい。図１２Ｋは、蒸留ファイル１２０５、ＰＤＥファイル１２１１、およびＲＰファイル１２２１を含む削減されたデータコンポーネントを示す。
【０１７０】
本明細書に記載の実施形態を用いてさまざまな実世界データベースに対してデータ削減を行い、これら実施形態の有効性を判定した。検討した実世界データベースとして、企業電子メールのエンロンコーパス、さまざまな米国政府記録および文書、MongoDB NOSQLデータベースに入力された米国運輸省記録、ならびに公衆が利用可能な企業のパワーポイントプレゼンテーションがある。本明細書に記載の実施形態を用いて、入力データを平均で４ＫＢの可変サイズのエレメント（フィンガープリンティングによって境界が決まる）に因子分解すると、これらデータベース全体にわたって３．２３倍の平均データ削減が達成された。３．２３倍の削減は、削減データのサイズが３．２３倍で割った元のデータのサイズと等しいことを意味しており、これによって３１％の圧縮率の削減フットプリントがもたらされる。旧来のデータ重複排除技術は、同等のパラメータを用いてこれらデータセットに対して１．４８７倍のデータ削減を提供することがわかった。本明細書に記載の実施形態を用いて、入力データを４ＫＢの固定サイズのエレメントに因子分解すると、これらデータセット全体にわたって１．８６倍の平均データ削減が達成された。旧来のデータ重複排除技術は、同等のパラメータを用いてこれらデータセットに対して１．０８倍のデータ削減を提供することがわかった。したがって、Data Distillation（商標）ソリューションは、旧来のデータ重複排除ソリューションよりもはるかに良好なデータ削減を提供することがわかった。
【０１７１】
また、テストランでは、基本データエレメントのバイトの小さいサブセットがシーブ内のエレメントの大半を順序付けることによって、その演算のための最小の増分ストレージで済むソリューションを可能にすることがわかった。
【０１７２】
これらの結果によって、Data Distillation（商標）装置は、エレメント自体よりも細かく、データセット全体にわたってグローバルにデータエレメント同士の間の冗長を利用することを効率的に可能にすることが確認された。この方法によって提供される無損失データ削減は、無駄のないデータアクセスおよびＩＯで、それら自体が最小の増分ストレージで済むデータ構造を使用して、かつ、現代のマルチコアマイクロプロセッサ上で利用可能な全計算処理能力のごく一部を用いて達成される。前節に記載の実施形態は、高速のデータ取込みおよびデータ取出しを提供しつつ、大型および超大型データセットに対する無損失データ削減を実行する、かつ従来の技術の欠点および制限を受けないシステムおよび技術を特徴とする。
【０１７３】
上記の説明は、当業者が実施形態を行って用いることができるように提示されている。開示される実施形態に対するさまざまな変更が当業者に容易に明らかとなり、本明細書に定義される一般原理は本開示の精神および範囲から逸脱することなく他の実施形態および用途にも適用され得る。ゆえに、本発明は示される実施形態に限定されず、本明細書に開示される原理および特徴と一致した最も広範な範囲が与えられる。
【０１７４】
本開示に記載のデータ構造およびコードは、コンピュータ読取可能記憶媒体および／またはハードウェアモジュールおよび／またはハードウェア装置上に部分的または完全に格納され得る。コンピュータ読取可能記憶媒体として、揮発性メモリ、不揮発性メモリ、ディスクドライブ、磁気テープ、ＣＤ（コンパクトディスク）、ＤＶＤ（デジタル汎用ディスクもしくはデジタルビデオディスク）といった磁気および光学記憶装置、または現在公知のもしくは将来開発される、コードおよび／もしくはデータを格納可能な他の媒体があるがこれらに限定されない。本開示に記載のハードウェアモジュールまたは装置として、特定用途向け集積回路（ＡＳＩＣ）、フィールドプログラマブルゲートアレイ（ＦＰＧＡ）、専用もしくは共有プロセッサ、および／または現在公知のもしくは将来開発される他のハードウェアモジュールもしくは装置があるがこれらに限定されない。
【０１７５】
本開示に記載の方法およびプロセスは、コンピュータ読取可能記憶媒体または装置に格納されるコードおよび／またはデータとして部分的にまたは完全に具体化され得るので、コンピュータシステムが当該コードおよび／またはデータを読出して実行すると、コンピュータシステムは関連付けられた方法およびプロセスを実行する。当該方法およびプロセスはハードウェアモジュールまたは装置においても部分的にまたは完全に具体化され得るので、ハードウェアモジュールまたは装置は、起動されると、関連付けられた方法およびプロセスを実行する。なお、当該方法およびプロセスは、コード、データ、およびハードウェアモジュールまたは装置の組合せを用いて具体化されてもよい。
【０１７６】
本明の実施形態の上記の説明は、例示および説明目的で提示されているに過ぎない。それらは網羅的であること、または本発明を開示された形態に限定することを意図していない。したがって、多くの変更および変形が当業者に明らかになるであろう。また、上記の開示は本発明を制限することを意図していない。
【図１Ａ】
0006596102.tif 000002
【図１Ｂ】
0006596102.tif 000003
【図１Ｃ】
0006596102.tif 000004
【図１Ｄ】
0006596102.tif 000005
【図１Ｅ】
0006596102.tif 000006
【図１Ｆ】
0006596102.tif 000007
【図１Ｇ】
0006596102.tif 000008
【図１Ｈ】
0006596102.tif 000009
【図１Ｉ】
0006596102.tif 000010
【図１Ｊ】
0006596102.tif 000011
【図１Ｋ】
0006596102.tif 000012
【図１Ｌ】
0006596102.tif 000013
【図１Ｍ】
0006596102.tif 000014
【図１Ｎ】
0006596102.tif 000015
【図１Ｏ】
0006596102.tif 000016
【図１Ｐ】
0006596102.tif 000017
【図２】
0006596102.tif 000018
【図３Ａ】
0006596102.tif 000019
【図３Ｂ】
0006596102.tif 000020
【図３Ｃ】
0006596102.tif 000021
【図３Ｄ】
0006596102.tif 000022
【図３Ｅ】
0006596102.tif 000023
【図３Ｆ】
0006596102.tif 000024
【図３Ｇ】
0006596102.tif 000025
【図３Ｈ】
0006596102.tif 000026
【図４】
0006596102.tif 000027
【図５Ａ】
0006596102.tif 000028
【図５Ｂ】
0006596102.tif 000029
【図５Ｃ】
0006596102.tif 000030
【図６Ａ】
0006596102.tif 000031
【図６Ｂ】
0006596102.tif 000032
【図６Ｃ】
0006596102.tif 000033
【図７Ａ】
0006596102.tif 000034
【図７Ｂ】
0006596102.tif 000035
【図８Ａ】
0006596102.tif 000036
【図８Ｂ】
0006596102.tif 000037
【図８Ｃ】
0006596102.tif 000038
【図８Ｄ】
0006596102.tif 000039
【図８Ｅ】
0006596102.tif 000040
【図９Ａ】
0006596102.tif 000041
【図９Ｂ】
0006596102.tif 000042
【図９Ｃ】
0006596102.tif 000043
【図１０Ａ】
0006596102.tif 000044
【図１０Ｂ】
0006596102.tif 000045
【図１０Ｃ】
0006596102.tif 000046
【図１１Ａ−１１Ｆ】
0006596102.tif 000047
【図１１Ｇ】
0006596102.tif 000048
【図１１Ｈ】
0006596102.tif 000049
【図１２Ａ】
0006596102.tif 000050
【図１２Ｂ】
0006596102.tif 000051
【図１２Ｃ】
0006596102.tif 000052
【図１２Ｄ】
0006596102.tif 000053
【図１２Ｅ】
0006596102.tif 000054
【図１２Ｆ】
0006596102.tif 000055
【図１２Ｇ】
0006596102.tif 000056
【図１２Ｈ】
0006596102.tif 000057
【図１２Ｉ】
0006596102.tif 000058
【図１２Ｊ】
0006596102.tif 000059
【図１２Ｋ】
0006596102.tif 000060