iOS CoreData - 启用 sqlite WAL / 预写日志记录有什么缺点吗答案

【问题标题】：iOS CoreData - are there any disadvantages to enabling sqlite WAL / Write-Ahead LoggingiOS CoreData - 启用 sqlite WAL / 预写日志记录有什么缺点吗
【发布时间】：2013-07-03 11:07:48
【问题描述】：

在 WWDC 2013 会议“207：Core Data 中的新功能”中，他们提到您可以在添加持久存储时通过传递选项字典来启用 SQLite WAL：

@{ NSSQLitePragmasOption: @"journal_mode = WAL" }

（在 iOS4+ 上可用，并将成为未来 iOS 版本的默认设置）。

我想知道在我的应用中为早期 iOS 版本启用这通常是否是一件好事。

我咨询了SQLite page about write ahead logging 以及他们提到的缺点，其中大多数似乎不适用于iOS，除了：

WAL 可能比应用程序中的传统回滚日志方法读书很少写。

几乎所有的优势听起来都像是在 iOS 上的优势：

WAL 在大多数情况下明显更快。
WAL 提供更多并发性，因为读取器不会阻塞写入器，写入器不会阻塞读取器。读写可以同时进行。
磁盘 I/O 操作往往使用 WAL 更加有序。
WAL 使用更少的 fsync() 操作，因此在 fsync() 系统调用被破坏的系统上不易受到问题的影响。

我假设（可能需要对我的应用程序进行一些检查以确保它不会减慢速度）启用这将是一件好事，但是我应该注意或任何已知的缺点问题？

【问题讨论】：

标签： ios sqlite core-data

【解决方案1】：

http://pablin.org/2013/05/24/problems-with-core-data-migration-manager-and-journal-mode-wal/ 表示它们可能是迁移的问题，特别是：

当您使用迁移管理器时，Core Data 将创建一个新数据库为您，并开始将实体从旧数据库中一一复制到新的。

当我们使用 journal_mode = WAL 时，还有一个额外的文件 DB.sqlite 称为 DB.sqlite-wal。

据我所知，问题似乎在于 Core Data 创建了一个临时数据库，将所有内容插入其中，并在将其重命名为原始名称，-wal 文件保留为旧文件的剩余部分版本。问题是您最终会得到一个不一致的数据库。

（在https://github.com/magicalpanda/MagicalRecord/issues/490 上也提到过——这表明如果你使用魔法记录，那么它已经默认为 WAL）

【讨论】：

我应该注意，这只发生在“高级”迁移中，当您需要迁移管理器时。不太激进的迁移（例如添加或重命名列）可以正常工作，因为它们是在同一个数据库上执行的，而不是在副本中执行的。
您不能暂时禁用 WAL，删除日志（-wal 文件），然后进行迁移...？
数据库迁移通常发生在应用程序启动期间。这是否意味着在上次应用程序关闭期间检查点必须已经运行？
@Him 问题出在高级迁移期间，coredata 无法正确重命名文件。链接的博客文章中提到的解决方法是在应用检测到需要进行迁移时指定 journal_mode = DELETE，从而避免在迁移发生时该文件存在。

【解决方案2】：

关于涉及子类化 NSMigrationManager 的非轻量级迁移发生的错误，我已将其作为错误 16038419 重新报告给 Apple。

我还做了一个不同的method-swizzling workaround，它在您总是想要使用旧的删除/回滚日志的情况下修补错误。据我了解，Pablin's fix 适用于您希望在迁移期间使用 WAL except 的情况。此外，您还可以在this video 中看到该错误。

【讨论】：

太棒了，谢谢。出于兴趣，在什么情况下您希望始终避免使用 WAL？
案例 1：Mac OS X Core Data 应用程序不使用文件包。 sqlite 文件是文档文件。当用户在 Finder 中看到与他们的文档相邻的 -shm 和 -wal 文件时，他们会摸不着头脑。他们可能认为这些是垃圾，要么将它们丢弃，要么在移动或复制文档文件时忽略它们。结果：数据丢失。案例 2：“但是，不建议将 WAL journal_mode 用于只读数据库文件或需要与 iOS 4 或更早版本互操作的文件。”那是来自：developer.apple.com/library/ios/releasenotes/DataManagement/…