私は、信頼できる方法でデータを永続化する必要があるアプリに取り組んでいます。つまり、アプリケーションのクラッシュや終了などに直面しても、更新を全か無かで永続化する必要があります。
ただし、Core Data がサポートできる回復力のレベルに関する情報はあまり見つかりません。また、周りを見渡すと、Core Data が破損している可能性があるようです。これは正しいですか、それとも Core Data は、信頼できるデータ ストレージをサポートするために必要な高レベルおよび低レベルのACIDプロパティを提供できますか?
どの API がこれらの保証を提供するかについて具体的に教えてください。たとえば、保存中にクラッシュが発生した場合でも (おそらく別のスレッドで)、保存はすべての更新をコミットするか、まったくコミットしないことが保証されますか?
ACID はデータベースにのみ適用され、Core Data はデータベース API ではないため、ACID 標準は実際には Core Data には適用されません。ACID は、せいぜい SQLite 永続ストアを使用する場合にのみ適用され、バイナリ、xml、in-mmemory、またはカスタム アトミック ストアには適用されません。
NSManagedObjectContext は、最初の 3 つの ACID コンポーネント (原子性、一貫性、および分離) を強制します。原則として、SQLite のロギング機能をオンにして、Durability を取得できます。
ACID は、マルチユーザーの大規模な鉄のデータベースの理論上の標準として考案されました。原子性、一貫性、および分離はすべて、複数の同時ユーザー トランザクションが相互に干渉してデータベースを破損しないようにすることを目的としています。耐久性は、他の方法では実質的にバックアップできないシステムにのみ適用されます。
対照的に、Core Data は、Model-View-Controller デザイン アプリケーションのモデル レイヤーを実装するための API です。その永続化機能は単なるオプションです。複数のユーザーはサポートされませんが、同じアプリの複数のサブプロセスのみがサポートされます。
ハードウェア障害が発生した場合にデータの整合性を完全に保証できるシステムはありません。せいぜい、以前のバージョンのデータに戻すことは保証できますが、変更中にハードウェア障害から保護することはできません。
とはいえ、Core Data は非常に堅牢です。私は永続ストアが破損し、通常は極端な状況下で発生する文字通り一握りのケースを見てきました。現在、デスクトップおよびモバイル プラットフォームで利用できる他のどのシステムよりも信頼性が高いとは思いません。
どの API がこれらの保証を提供するかについて具体的に説明してください。たとえば、保存中に (おそらく別のスレッドで) クラッシュが発生した場合でも、保存はすべての更新をコミットするか、まったくコミットしないことが保証されますか? ... 私が言及している失敗の種類アプリ内でのクラッシュまたはアプリの終了です。この場合、最後のトランザクションのみが影響を受ける (つまり、最悪の場合は失われる) ことが望ましいですが、Core Data でこれを表現する方法がわかりません。
ここには、ディスクに書き込む永続ストアの操作と、オブジェクト グラフの整合性を維持してグラフを保存する際の管理対象オブジェクト コンテキストの操作という 2 つの領域があります。
SQLite ストアの場合、SQLite 自体は ACID に準拠しています。
トランザクション データベースは、すべての変更とクエリが Atomic、Consistent、Isolated、Durable (ACID) であるように見えるデータベースです。SQLite は、トランザクションがプログラムのクラッシュ、オペレーティング システムのクラッシュ、またはコンピューターの電源障害によって中断された場合でも、原子的で、一貫性があり、分離され、耐久性のあるシリアル化可能なトランザクションを実装します。
ユニタリ ファイルとして書き出されるその他のストアについては、Core Data は安全な書き込み方法を使用して、既存の正常なファイルが破損したファイルによって上書きされないようにします。
オブジェクト グラフのより高い抽象化レベルでは、マネージド オブジェクト コンテキストはストアに書き込む前に検証を実行し、検証エラーが発生した場合は書き込み試行全体を拒否します (リンク保留中)。この動作は、オブジェクト グラフによって必要とされます。
オブジェクト グラフは、メモリ内の関連するライブ オブジェクトのコレクションです。データがフィールドにのみエンコードされる手続き型データベースとは異なり、オブジェクト間の関係によって重要なデータがエンコードされます。したがって、グラフ全体を段階的に検証してから、1 つの段階で保存する必要があります。(もちろん、sqlite ストアを使用する舞台裏では、手続き型の ACID 準拠の手順がありますが、このレベルに達する前にオブジェクト グラフの検証が行われます。)
たとえば、ファイル システムをモデル化/シミュレートするためのデータ モデルがあります。と の 2 つのエンティティがFolderありFileます。実際の各ファイルは常にフォルダー内にあるため、各Fileオブジェクトには単一のオブジェクトとの必要な関係があります。Folderただし、フォルダーを持たないファイル オブジェクトを挿入します。保存のためにコンテキストがオブジェクト グラフを検証するとき、グラフはフォルダー内にないファイル オブジェクトでは無意味であるため、グラフ全体が拒否されます。