sqlite - 评估将 Core Data 与 Dropbox 同步的策略

Question

这个问题是关于使用 Dropbox 在多个 iOS 设备之间同步 sqlite 核心数据存储。考虑这样的安排:

1. 应用程序使用核心数据存储，将其称为 local.sql，保存在应用程序自己的 NSDocumentDirectory

2. 该应用使用 Dropbox Sync API 来观察用户 Dropbox 中的某个文件，例如 user/myapp/synced.sql

3. 应用程序会观察 NSManagedObjectContextDidSaveNotification，并在每次保存时将 local.sql 复制到 user/myapp/synced.sql，从而取代后者。

4. 当 Dropbox API 通知我们 synced.sql 发生更改时，我们或多或少会执行与第 3 部分相反的操作:拆除核心数据堆栈，替换 local.sql 与 synced.sql，并重新创建核心数据堆栈。同时，用户会在 UI 中看到“正在同步”或“正在加载”。

问题:

A.这种安排是否效率极低，以至于应该完全避免？如果我们能保证数据库规模不大怎么办？

B.这种安排是否有利于文件损坏？不仅仅是通过增量/变更日志同步？如果是这样，请详细解释一下原因吗？

Answer 1

A. Is this arrangement hugely inefficient, to the extent where it should be completely avoided? What if we can guarantee the database is not large in size?

无关紧要，因为:

B. Is this arrangement conducive to file corruption? More than syncing via deltas/changelogs? If so, will you please explain in detail why?

是的，非常如此。几乎有保证。我建议查看How to Corrupt An SQLite Database File 。您可能会临时犯下第 1 节中描述的至少两个问题，包括在事务处于事件状态时复制文件以及删除(或未能复制或制作无用的副本)日志文件。在任何严肃的测试中，您的方案很可能几乎立即崩溃。

如果这还不够糟糕，请考虑两个设备同时保存更改的场景。然后怎样呢？如果幸运的话，您只会得到 Dropbox 臭名昭著的“冲突副本”文件副本之一，这“仅”意味着丢失一些数据。如果没有，您将再次陷入数据库完全损坏的境地。

当然，拆除核心数据堆栈进行同步会给用户带来极大的不便。

如果您想考虑通过 Dropbox 同步核心数据，我建议您采用以下方法之一:

1. Ensembles ，它可以通过 Dropbox(同时避免上述问题)或 iCloud(同时避免 iOS 内置 Core Data/iCloud 同步问题)进行同步。
2. TICoreDataSync ，它使用 Dropbox 文件同步，但避免将 SQLite 文件放入文件存储中。
3. ParcelKit ，它使用 Dropbox 的新数据存储 API。 (请注意，这是相当新的，数据存储 API 本身仍处于测试阶段)。