iOS CoreData - 启用sqlite WAL / Write-Ahead Logging有任何缺点 [英] iOS CoreData - are there any disadvantages to enabling sqlite WAL / Write-Ahead Logging

问题描述

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

  @ {NSSQLitePragmasOption：@journal_mode = WAL} 
  

我想知道这是否是一个好东西，在我的应用程序中启用（在iOS4 +上可用，并且将是未来iOS版本的默认值）对于早期的iOS版本。

我已经查阅了 SQLite页面关于预写日志和他们提到的缺点，他们大多数似乎不适用于iOS除了：

• WAL可能会稍微慢一些（
  ）的应用程序中的
  传统的回滚日志方法（或许慢1％或2％）。

几乎所有的优点听起来像是他们可能会在iOS上的一个好处：

• WAL提供了更多的并发性，因为读者不会阻塞写入器，而且写入器不会阻塞读取器。


• 使用WAL，磁盘I / O操作往往更加顺序。


• WAL使用更少的fsync

我在想（可能受制于做一些检查我的应用程序，以确保它不会减慢的事情），这将是一个好东西启用，但有任何不足，我应该注意或任何已知的问题吗？

解决方案

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创建一个
临时DB ，插入一切，当它重命名为
原始名称时，-wal文件保留为旧的
版本的剩余。问题是你最终有一个不一致的数据库。

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

At the WWDC 2013 session '207: What's New in Core Data', they mention that you can enable SQLite WAL by passing an options dictionary when adding a persistent store:

@{ NSSQLitePragmasOption: @"journal_mode = WAL" }

(which is available on iOS4+ and will be the default for future iOS versions).

I'm wondering whether this would generally be a good thing to enable in my app for earlier iOS versions too.

I've consulted the SQLite page about write ahead logging and the disadvantages they mention, most of them seem not to apply to iOS apart from:

• WAL might be very slightly slower (perhaps 1% or 2% slower) than the traditional rollback-journal approach in applications that do mostly reads and seldom write.

pretty much all the advantages do sound like they'll probably be a benefit on iOS:

• WAL is significantly faster in most scenarios.
• WAL provides more concurrency as readers do not block writers and a writer does not block readers. Reading and writing can proceed concurrently.
• Disk I/O operations tends to be more sequential using WAL.
• WAL uses many fewer fsync() operations and is thus less vulnerable to problems on systems where the fsync() system call is broken.

I'm asuming (perhaps subject to doing some checks on my app to make sure it doesn't slow things down) that this would be a good thing to enable, but is there any downside I should watch for or any known issues?

解决方案

http://pablin.org/2013/05/24/problems-with-core-data-migration-manager-and-journal-mode-wal/ suggests that their could be issues with migrations, in particular:

When you use a Migration Manager, Core Data will create a new database for you, and start copying the entities one by one from the old DB to the new one.

As we are using journal_mode = WAL, there’s an additional file besides DB.sqlite called DB.sqlite-wal.

From what I can tell, the problem seems to be that Core Data creates a temporary DB, inserts everything there, and when it renames it to the original name, the -wal file is kept as a leftover from the old version. The problem is that you end up with an inconsistent DB.

(also mentioned on https://github.com/magicalpanda/MagicalRecord/issues/490 - which suggests that if you use magical record then it is already defaulting to WAL )

这篇关于iOS CoreData - 启用sqlite WAL / Write-Ahead Logging有任何缺点的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！