Loading article…
データの不整合とは、異なる場所に保存されている同じデータが一致するかどうかを指します。
時点整合性はバックアップファイルの重要な特性であり、バックアップを作成するソフトウェアの重要な目標です。また、ディスクメモリシステムの設計、特に予期せぬシャットダウンが発生した場合の動作にも関連しています。
バックアップの適切な例として、オンライン百科事典のWikipediaのようなデータベースを持つウェブサイトを考えてみましょう。Wikipediaは24時間365日稼働している必要がありますが、災害に備えて定期的にバックアップを取る必要もあります。Wikipediaの一部は毎日毎分更新されていますが、Wikipediaのデータベースはサーバー上に1つまたは複数の非常に大きなファイルとして保存されており、バックアップには数分から数時間かかります。
これらの大容量ファイルは、他のデータベースと同様に、位置によって互いを参照する多数のデータ構造を含んでいます。例えば、一部の構造はインデックスであり、データベースサブシステムが検索結果を迅速に見つけることを可能にします。データ構造が互いに正しく参照しなくなった場合、データベースは破損していると言えます。
時点の一貫性の重要性は、それがなければバックアップが作成された場合に何が起こるかを考えてみるとよくわかります。
Wikipediaのデータベースは巨大なファイルであり、重要な索引が全体の20%の位置にあり、記事データは75%の時点で保存されると仮定します。編集者が新しい記事を作成すると同時にバックアップが実行されている状況を考えてみましょう。このバックアップは、大きなファイルの先頭から末尾までをコピーする単純な「ファイルコピー」として作成され、データの一貫性は考慮されません。記事編集の時点で、バックアップは50%完了しています。新しい記事は記事スペースに追加され（75%の時点）、対応する索引エントリが追加されます（20%の時点）。
バックアップは既に半分完了しており、インデックスも既にコピーされているため、バックアップファイルには記事データは含まれますが、インデックス参照は欠落した状態で書き込まれます。この不整合の結果、このファイルは破損しているとみなされます。
現実世界では、Wikipediaのような実際のデータベースは1時間に数千回編集される可能性があり、参照箇所はほぼ常にファイル全体に分散しており、その数は数百万、数十億、あるいはそれ以上になることもあります。逐次的な「コピー」バックアップでは、非常に多くの小さな破損が含まれるため、長時間の修復プロセスを行わない限り、バックアップは全く使用できなくなります。しかも、復元されたデータの完全性を保証することはできません。
データの一貫性を適切に考慮したバックアッププロセスは、バックアップがデータベース全体の特定の時点の状態を捉えたスナップショットであることを保証します。Wikipediaの例では、 75%の時点で追加された記事を含めずにバックアップが作成されるため、記事データは以前に書き込まれたインデックスデータと整合性が保たれます。
時点内一貫性は、コンピュータのディスクサブシステムにも関連する。
具体的には、オペレーティングシステムとファイルシステムは、それらが動作するコンピュータシステムがいつでも停電、クラッシュ、故障、またはその他の理由で動作を停止する可能性があることを想定して設計されています。適切に設計されていれば、停電が発生した場合でもデータが回復不能なほど破損しないことが保証されます。オペレーティングシステムとファイルシステムは、データが特定の順序でハードディスクに書き込まれるようにすることでこれを実現し、予期せぬシャットダウンを検出して復旧するためにその順序に依存しています。
一方、データの整合性を最大限に高める順序で厳密にデータをディスクに書き込むことは、パフォーマンスにも影響を与えます。書き込みキャッシュと呼ばれるプロセスは、書き込み操作を統合して順序を並べ替えることで、ディスクヘッドの移動時間を最小限に抑え、処理速度を向上させるために使用されます。
書き込みキャッシュによって書き込みの実行順序が変わると、データの一貫性に関する懸念が生じます。これは、予期せぬシャットダウンが発生し、すべての書き込みが順次コミットされるというオペレーティングシステムの想定が崩れる可能性があるためです。
例えば、一般的な文書ファイルや画像ファイルを保存する場合、オペレーティングシステムは次のようなレコードを次の順序でディスクに書き込む可能性があります。
オペレーティングシステムは、項目1が存在する（ファイルが保存されようとしていることを示す）が、項目4が欠落している（保存が成功したことを示す）場合、保存操作が失敗したと判断し、保存のために既に行われた不完全な手順（例えば、セクター123が正しく埋められていないため空き領域としてマークする、ファイルディレクトリからXYZの記録を削除するなど）を取り消す必要があるという前提に基づいています。これらの項目が順番にディスクに書き込まれることを前提としています。
キャッシュアルゴリズムが、これらの項目をディスクに4-3-1-2の順に書き込むのが最も速いと判断し、書き込みを開始したとします。しかし、4の書き込みが完了した後、3、1、2の書き込み前に電源が切断され、これらの書き込みは実行されません。コンピュータの電源が再びオンになると、ファイルシステムにはセクター123にXYZという名前のファイルが存在すると表示されますが、実際にはこのセクターにはそのファイルは存在しません。（代わりに、このセクターにはゴミデータ、ゼロ、または古いファイルのランダムな部分が格納されており、ファイルを開くとそれが表示されます。）
さらに、ファイルシステムの空き領域マップにはセクター123が使用中であることを示すエントリが含まれていないため、ファイルシステムはセクター123が使用可能であると誤認し、後ほどそのセクターを次の保存対象ファイルに割り当てる可能性が高くなります。その結果、ファイルシステムには、予期せず同じセクターを占有する2つのファイル（相互リンクファイルと呼ばれる）が存在することになります。したがって、一方のファイルへの書き込みによってもう一方のファイルの一部が上書きされ、目に見えない形で破損してしまう可能性があります。
時点の一貫性を保証するディスクキャッシュサブシステムは、予期せぬシャットダウンが発生した場合でも、4つの要素が完全に（1-2-3-4）、部分的に（1、1-2、1-2-3）、またはまったく書き込まれない、という5つの方法のうちのいずれかで書き込まれることを保証します。
サーバーなどに搭載されているようなハイエンドのハードウェアディスクコントローラは、キャッシュメモリに小型のバッテリーバックアップユニットを搭載しており、意図しないシャットダウンのリスクを軽減しながら、書き込みキャッシュによるパフォーマンス向上を実現しています。バッテリーバックアップユニットは、シャットダウン中もメモリへの電力供給を維持するため、コンピュータの電源が再びオンになったときに、以前にコミットした書き込みを迅速に完了できます。このようなコントローラでは、オペレーティングシステムが4つの書き込み（1-2-3-4）をこの順序で要求するかもしれませんが、コントローラはそれらを書き込む最も速い方法は4-3-1-2であると判断する場合があります。コントローラは基本的にオペレーティングシステムに嘘をつき、書き込みが順番通りに完了したと報告します（これは、電源が失われた場合にデータが破損するリスクを犠牲にしてパフォーマンスを向上させる嘘です）。そして、バッテリーバックアップは、結果として発生する可能性のあるあらゆる損傷をコントローラが静かに修復する方法を提供することで、データ破損のリスクを軽減します。
要素4への書き込み後に電源が遮断された場合、バッテリーバックアップメモリには他の3つの項目の書き込みコミットメント記録が保持されており、次の利用可能な機会にそれらがディスクに書き込まれる（「フラッシュ」される）ことが保証されます。
分散データベースシステムにおける一貫性（データベースシステム）とは、多くのACIDデータベースが持つ特性であり、データベーストランザクションの結果がすべてのノードから同時に確認できることを保証するものです。つまり、トランザクションがコミットされると、データベースにアクセスしようとするすべての関係者が、そのトランザクションの結果を同時に確認できるようになります。
取引の一貫性の重要性を示す良い例として、送金処理を扱うデータベースが挙げられます。送金処理には、ある場所に借方を、別の場所に貸方を書き込むという2つの操作が必要だとします。一方の操作は完了したがもう一方の操作が完了していない状態でシステムがクラッシュまたはシャットダウンし、それを修正する仕組みがない場合、そのシステムは取引の一貫性を欠いていると言えます。送金処理においては、取引全体が完了するとか、あるいは全く完了しないかのどちらかであることが望ましいです。どちらの場合も、残高の整合性が保たれます。
トランザクションの一貫性とは、まさにそれを保証するものです。つまり、システムが電源投入時に不完全なトランザクションを検出し、検出された不完全なトランザクションの部分を元に戻す（または「ロールバック」する）ようにプログラムされているということです。
アプリケーションの一貫性は、トランザクションの一貫性と同様に、より大規模なスケールで適用されます。単一のトランザクションの範囲ではなく、1つまたは複数のアプリケーションからの多数の異なるトランザクションストリームの範囲内でデータの一貫性が確保される必要があります。アプリケーションは、さまざまな種類のデータ、ファイル、および他のアプリケーションからのデータフィードで構成される場合があります。アプリケーションの一貫性とは、関連するすべてのファイルとデータベースが同期され、アプリケーションの真の状態を表す状態のことです。