iOS CoreData - 启用sqlite WAL/Write-Ahead Logging有任何缺点

Question

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

@{ NSSQLitePragmasOption: @"journal_mode = WAL" }

(可在iOS4 +上使用,将成为未来iOS版本的默认设置).

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

我已经查阅了关于提前写入日志的SQLite页面以及它们提到的缺点,其中大多数似乎不适用于iOS,除了:

• 在大多数读取和很少写入的应用程序中,WAL可能比传统的rollback-journal方法稍慢(可能慢1%或2%).

几乎所有优点听起来都像是iOS上的好处:

• 在大多数情况下,WAL明显更快.
• WAL提供更多的并发性,因为读者不会阻止编写者,而编写者也不会阻止读者.阅读和写作可以同时进行.
• 使用WAL,磁盘I/O操作往往更顺序.
• WAL使用更少的fsync()操作,因此在fsync()系统调用被破坏的系统上不易受到问题的影响.

我很想(可能需要对我的应用程序进行一些检查,以确保它不会减慢速度),这将是一件好事,但是我应该注意哪些缺点或任何已知问题？

Answer 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)