Loading article…
コンピューティングにおいて、データ重複排除とは、繰り返し出現するデータの重複コピーを削除する技術です。この技術を適切に実装することで、ストレージの利用効率が向上し、ストレージ容量のニーズを満たすために必要なストレージメディアの総量を削減できるため、設備投資を抑えることができます。また、ネットワークデータ転送にも適用でき、送信する必要のあるバイト数を削減できます。
重複排除処理では、一意で連続したデータブロックであるデータ「チャンク」（「バイトパターン」とも呼ばれる）を比較する必要があります。これらのチャンクは分析処理中に識別され、保存され、既存データ内の他のチャンクと比較されます。一致が発生すると、冗長なチャンクは保存されたチャンクを指す小さな参照に置き換えられます。同じバイトパターンが数十回、数百回、あるいは数千回出現する可能性があるため（一致頻度はチャンクサイズに依存します）、保存または転送する必要のあるデータ量を大幅に削減できます。[ 1 ] [ 2 ]
関連する技術として、シングルインスタンス（データ）ストレージがあります。これは、ファイル全体レベルで複数のコンテンツコピーを単一の共有コピーに置き換えるものです。この技術は他のデータ圧縮や重複排除方式と組み合わせることも可能ですが、セグメントレベルまたはサブブロックレベルで動作する新しいデータ重複排除方式とは異なります。
重複排除は、 LZ77やLZ78などのデータ圧縮アルゴリズムとは異なります。圧縮アルゴリズムは個々のファイル内の冗長なデータを識別し、その冗長なデータをより効率的にエンコードするのに対し、重複排除の目的は、大量のデータを検査し、ファイル全体やファイルの大きなセクションなど、同一の大きなセクションを識別して、共有コピーに置き換えることです。
例えば、一般的な電子メールシステムには、同じ 1 MB (メガバイト) のファイル添付ファイルが 100 個含まれている場合があります。電子メールプラットフォームがバックアップされるたびに、添付ファイルの 100 個すべてが保存され、100 MB のストレージ容量が必要になります。データ重複排除を使用すると、添付ファイルのインスタンスは実際に 1 つだけ保存され、後続のインスタンスは保存されたコピーを参照するため、重複排除率は約 100 対 1 になります。重複排除は、ストレージ容量をさらに節約するためにデータ圧縮と組み合わせて使用されることがよくあります。重複排除は、まず繰り返しデータの大きな塊を削除するために使用され、次に圧縮を使用して保存された各塊を効率的にエンコードします。[ 3 ]
コンピュータコードでは、重複排除は、例えば情報を変数に格納することで行われます。これにより、個別に記述する必要がなくなり、中央の参照場所で一度にまとめて変更できます。例としては、CSSクラスやMediaWikiの名前付き参照などが挙げられます。
ストレージベースのデータ重複排除は、特定のファイルセットに必要なストレージ量を削減します。これは、非常に類似した、あるいは同一のデータのコピーが多数単一のディスクに保存されているアプリケーションで最も効果的です。データ損失を防ぐために定期的に実行されるデータバックアップの場合、特定のバックアップ内のほとんどのデータは、前回のバックアップから変更されていません。一般的なバックアップシステムは、変更されていないファイルを省略（またはハードリンク）したり、ファイル間の差分を保存したりすることで、この特性を利用しようとします。しかし、どちらの方法もすべての冗長性を捕捉するわけではありません。ハードリンクは、電子メールデータベースのように、変更がわずかしかない大きなファイルには役立ちません。差分は、単一ファイルの隣接するバージョン間の冗長性しか検出しません（削除されて後で再び追加されたセクションや、多くのドキュメントに含まれているロゴ画像などを考えてみてください）。
インラインネットワークデータ重複排除は、エンドポイント間で転送する必要のあるバイト数を削減するために使用され、必要な帯域幅を削減できます。詳細については、WAN最適化を参照してください。
仮想サーバーや仮想デスクトップは、重複排除の恩恵を受ける。なぜなら、各仮想マシンごとに名目上は別々であるシステムファイルを、単一のストレージ領域に統合できるからだ。同時に、特定の仮想マシンがファイルをカスタマイズした場合でも、重複排除によって他の仮想マシン上のファイルが変更されることはない。これは、ハードリンクや共有ディスクといった代替手段では実現できない利点である。仮想環境のバックアップや複製作成も同様に効率化される。
重複排除は、データが流れている最中に「インライン」で行われる場合と、データが書き込まれた後に「ポストプロセス」で行われる場合がある。
後処理重複排除では、まず新しいデータがストレージデバイスに保存され、その後、別のプロセスでデータが分析され、重複が検出されます。利点は、データを保存する前にハッシュ計算とルックアップが完了するのを待つ必要がないため、ストレージのパフォーマンスが低下しないことです。ポリシーベースの操作を提供する実装では、ユーザーは「アクティブ」なファイルの最適化を延期したり、ファイルの種類と場所に基づいてファイルを処理したりできます。潜在的な欠点の1つは、重複データが不必要に短時間保存される可能性があることで、システムがほぼ満杯状態の場合に問題となる可能性があります。
あるいは、重複排除ハッシュ計算をインラインで実行することも可能です。つまり、データがターゲットデバイスに入力される際に同期されます。ストレージシステムが既に格納済みのブロックを検出した場合、新しいブロック全体ではなく、既存のブロックへの参照のみが格納されます。
インライン重複排除は、ポストプロセス重複排除に比べて、重複データが保存または転送されないため、ストレージとネットワークトラフィックが少なくて済むという利点があります。一方、ハッシュ計算は計算コストが高くなる可能性があり、ストレージのスループットが低下する可能性があります。しかし、インライン重複排除に対応したベンダーの中には、高速なインライン重複排除を実現する機器を実証しているところもあります。
データ重複排除方法を分類するもう一つの方法は、その発生場所による分類です。データが作成された場所の近くで発生する重複排除は「ソース重複排除」と呼ばれ、データが保存された場所の近くで発生する重複排除は「ターゲット重複排除」と呼ばれます。
ソース重複排除は、データソース上のデータが重複排除されることを保証します。これは通常、ファイルシステム内で直接行われます。ファイルシステムは定期的に新しいファイルをスキャンしてハッシュを作成し、既存のファイルのハッシュと比較します。同じハッシュを持つファイルが見つかった場合、ファイルのコピーは削除され、新しいファイルは古いファイルを指すようになります。ただし、ハードリンクとは異なり、重複したファイルは別々のエンティティとみなされ、重複したファイルのいずれかが後で変更された場合、コピーオンライトと呼ばれるシステムを使用して、変更されたファイルまたはブロックのコピーが作成されます。重複排除プロセスは、ユーザーとバックアップアプリケーションに対して透過的です。重複排除されたファイルシステムをバックアップすると、重複が発生することが多く、その結果、バックアップがソースデータよりも大きくなります。[ 6 ] [ 7 ]
ソースの重複排除は、コピー操作に対して明示的に宣言できます。コピーされたデータが重複排除を必要とするかどうかを知るための計算は不要です。これにより、ファイルシステム上の新しい形式のリンクが実現します。これは、一部のシステム (Linux など) では参照カウントリンク、またはreflinkと呼ばれ、 [ 8 ] macOS ではクローンファイルと呼ばれます。クローンファイルでは、1 つ以上のinode (ファイル情報エントリ) がそのデータの一部または全部を共有するように作成されます。これは、inode レベルで機能するハードリンクや、ファイル名レベルで機能するシンボリックリンクに類似した名前です。個々のエントリは、エイリアシングしないコピーオンライト動作を持ちます。つまり、1 つのコピーを後で変更しても、他のコピーには影響しません。[ 9 ] Microsoft のReFSもこの操作をサポートしています。[ 10 ]
ターゲット重複排除とは、データがその場所で生成されていない場合に重複データを削除するプロセスです。例としては、SAN/NASに接続されたサーバーが挙げられます。SAN/NASはサーバーにとってのターゲット（ターゲット重複排除）となります。サーバーは重複排除について認識しておらず、サーバー自体がデータ生成ポイントでもあります。2つ目の例としては、バックアップが挙げられます。これは通常、データリポジトリや仮想テープライブラリなどのバックアップストアになります。
データ重複排除の実装で最も一般的な形式の 1 つは、データのチャンクを比較して重複を検出するものです。そのためには、各データ チャンクに、通常は暗号学的ハッシュ関数を使用してソフトウェアによって計算された識別子が割り当てられます。多くの実装では、識別子が同一であればデータも同一であるという仮定がなされますが、鳩の巣原理により、これはすべての場合に真であるとは限りません。他の実装では、同じ識別子を持つ 2 つのデータ ブロックが同一であるとは仮定せず、同じ識別子を持つデータが同一であることを実際に検証します。[ 11 ]実装に応じて、ソフトウェアが、特定の識別子が重複排除名前空間に既に存在すると仮定するか、または 2 つのデータ ブロックの同一性を実際に検証する場合、重複したチャンクをリンクに置き換えます。
データの重複排除が完了すると、ファイルの読み出し時にリンクが見つかった箇所はすべて、システムが参照先のデータチャンクに置き換えます。この重複排除処理は、エンドユーザーやアプリケーションにとって透過的であるように設計されています。
商用の重複排除実装は、チャンキング方式とアーキテクチャによって異なる。
これまで、データ重複排除は主にセカンダリストレージシステムで使用されてきました。その理由は2つあります。1つ目は、データ重複排除には重複データの検出と削除にオーバーヘッドが発生するためです。プライマリストレージシステムでは、このオーバーヘッドがパフォーマンスに影響を与える可能性があります。2つ目は、セカンダリデータには重複データが多く含まれる傾向があるためです。特にバックアップアプリケーションは、時間の経過とともに大量の重複データを生成することがよくあります。
データ重複排除は、システム設計上、大きなオーバーヘッドやパフォーマンスへの影響が不要な場合において、プライマリストレージと連携して正常に導入されています。
Single-instance storage (SIS) is a system's ability to take multiple copies of content objects and replace them by a single shared copy. It is a means to eliminate data duplication and to increase efficiency. SIS is frequently implemented in file systems, email server software, databackup, and other storage-related computer software. Single-instance storage is a simple variant of data deduplication. While data deduplication may work at a segment or sub-block level, single instance storage works at the object level, eliminating redundant copies of objects such as entire files or email messages.[12]
Single-instance storage can be used alongside (or layered upon) other data duplication or data compression methods to improve performance in exchange for an increase in complexity and for (in some cases) a minor increase in storage space requirements.
One method for deduplicating data relies on the use of cryptographic hash functions to identify duplicate segments of data. If two different pieces of information generate the same hash value, this is known as a collision. The probability of a collision depends mainly on the hash length (see birthday attack). Thus, the concern arises that data corruption can occur if a hash collision occurs, and additional means of verification are not used to verify whether there is a difference in data, or not. Both in-line and post-process architectures may offer bit-for-bit validation of original data for guaranteed data integrity. The hash functions used include standards such as SHA-1, SHA-256, and others.
The computational resource intensity of the process can be a drawback of data deduplication. To improve performance, some systems utilize both weak and strong hashes. Weak hashes are much faster to calculate but there is a greater risk of a hash collision. Systems that utilize weak hashes will subsequently calculate a strong hash and will use it as the determining factor to whether it is actually the same data or not. Note that the system overhead associated with calculating and looking up hash values is primarily a function of the deduplication workflow. The reconstitution of files does not require this processing and any incremental performance penalty associated with re-assembly of data chunks is unlikely to impact application performance.
Another concern is the interaction of compression and encryption. The goal of encryption is to eliminate any discernible patterns in the data. Thus encrypted data cannot be deduplicated, even though the underlying data may be redundant.
Although not a shortcoming of data deduplication, there have been data breaches when insufficient security and access validation procedures are used with large repositories of deduplicated data. In some systems, as typical with cloud storage, an attacker can retrieve data owned by others by knowing or guessing the hash value of the desired data.[13]
Deduplication is implemented in some filesystems such as in ZFS or Write Anywhere File Layout and in different disk arrays models. It is a service available on both NTFS and ReFS on Windows servers.