IOS CoreData - существуют ли какие-либо недостатки, позволяющие использовать sqlite WAL/Write-Ahead Logging

На сессии WWDC 2013 "207: что нового в основных данных" они упоминают, что вы можете включить SQLite WAL, передав словарь опций при добавлении постоянного хранилища:

@{ NSSQLitePragmasOption: @"journal_mode = WAL" }

(который доступен на iOS4 + и будет использоваться по умолчанию для будущих версий iOS).

Мне интересно, будет ли это вообще полезно включить в мое приложение для более ранних версий iOS.

Я проконсультировался на странице SQLite о записи на будущее и об их недостатках, большинство из которых, похоже, не относятся к iOS, кроме:

  • WAL может быть немного медленнее (возможно, на 1% или на 2% медленнее), чем традиционный подход к откату-журналу в приложениях, которые в основном читает и редко пишет.

В значительной степени все преимущества звучат так, как будто они, вероятно, будут полезны для iOS:

  • В большинстве сценариев WAL значительно быстрее.
  • WAL предоставляет больше concurrency, поскольку читатели не блокируют писателей, и писатель не блокирует читателей. Чтение и запись могут продолжаться одновременно.
  • Операции диск ввода-вывода имеют тенденцию быть более последовательными с использованием WAL.
  • WAL использует намного меньше операций fsync() и, следовательно, менее уязвим для проблем в системах, где системный вызов fsync() нарушен.

Я собираюсь (возможно, подвергнусь проверке на моем приложении, чтобы убедиться, что это не замедлит работу), что это было бы хорошо, что бы включить, но есть ли недостатки, которые я должен наблюдать или какие-либо известные вопросы?

Ответы

Ответ 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)

Ответ 2

Относительно ошибки, возникающей при нелегких миграциях, которые связаны с подклассом NSMigrationManager, о котором я повторно сообщил Apple как об ошибке 16038419.

Я также сделал другое, метод-swizzling обходное решение, которое исправляет ошибку в тех случаях, когда вы всегда хотите использовать устаревшее удаление/откат ведение журнала. Насколько я понимаю, Pablin fix используется для случаев, когда вы хотите использовать WAL, кроме случаев миграции. Кроме того, вы можете увидеть, что ошибка произошла в этом видео.