iOS CoreData - có bất kỳ nhược điểm nào khi kích hoạt tính năng sqlite WAL/Write-Ahead Logging

Question

Tại phiên WWDC 2013 '207: Có gì mới trong dữ liệu cốt lõi', họ đề cập rằng bạn có thể bật SQLite WAL bằng cách chuyển từ điển tùy chọn khi thêm lưu trữ liên tục:

@{ NSSQLitePragmasOption: @"journal_mode = WAL" } 

(có sẵn trên iOS4 + và sẽ là mặc định cho các phiên bản iOS trong tương lai).

Tôi tự hỏi liệu điều này nói chung sẽ là một điều tốt để bật trong ứng dụng của tôi cho các phiên bản iOS cũ hơn.

Tôi đã tham khảo ý kiến ​​SQLite page about write ahead logging và những nhược điểm họ đề cập, hầu hết trong số họ dường như không áp dụng cho iOS ngoài:

• WAL có thể rất hơi chậm (có lẽ 1% hoặc 2% chậm hơn) hơn phương pháp tiếp cận rollback-journal truyền thống trong các ứng dụng chủ yếu là đọc và ít khi viết.

khá nhiều tất cả những ưu điểm làm âm thanh như họ có thể sẽ là một lợi ích trên iOS:

• WAL là đáng kể nhanh hơn trong hầu hết các tình huống.
• WAL cung cấp đồng thời hơn vì người đọc không chặn nhà văn và người viết không chặn người đọc. Đọc và viết có thể tiến hành đồng thời.
• Hoạt động I/O đĩa thường có xu hướng tuần tự hơn bằng cách sử dụng WAL.
• WAL sử dụng nhiều thao tác fsync() ít hơn và do đó ít dễ bị tổn thương hơn đối với các sự cố trên hệ thống mà cuộc gọi hệ thống fsync() bị hỏng.

Tôi đang chuẩn bị (có thể phải thực hiện một số kiểm tra trên ứng dụng của mình để đảm bảo rằng nó không làm chậm công việc), đây là một điều tốt để kích hoạt, nhưng có bất kỳ nhược điểm nào tôi nên xem hoặc bất kỳ vấn đề đã biết nào?

Answer 1

http://pablin.org/2013/05/24/problems-with-core-data-migration-manager-and-journal-mode-wal/ gợi ý rằng họ có thể là vấn đề với di cư, đặc biệt là:

Khi bạn sử dụng một Giám đốc Migration, Core Dữ liệu sẽ tạo ra một cơ sở dữ liệu mới cho bạn, và bắt đầu sao chép các đối tượng từng người một từ DB cũ thành hình mới.

Vì chúng tôi đang sử dụng journal_mode = WAL, có một tệp bổ sung bên cạnh DB.sqlite được gọi là DB.sqlite-wal. Từ những gì tôi có thể nói, vấn đề dường như là dữ liệu cốt lõi tạo ra một mã số tạm thời DB, chèn tất cả mọi thứ ở đó, và khi nó đổi tên thành tên gốc, tập tin -wal được giữ như một phần còn lại từ cũ phiên bản. Vấn đề là bạn kết thúc với một DB không nhất quán.

(cũng được đề cập trên https://github.com/magicalpanda/MagicalRecord/issues/490 - điều này gợi ý rằng nếu bạn sử dụng kỷ lục kỳ diệu sau đó nó đã được mặc định cho WAL)

Answer 2

Về lỗi xảy ra với di cư phi nhẹ liên quan đến subclassing NSMigrationManager, mà tôi đã báo cáo lại cho Apple là Bug 16038419.

Tôi cũng đã thực hiện một khác nhau, method-swizzling workaround vá lỗi trong trường hợp bạn luôn luôn muốn sử dụng nhật ký xóa/khôi phục cũ. Theo tôi hiểu, Pablin's fix dành cho các trường hợp bạn muốn sử dụng WAL ngoại trừ trong khi di chuyển. Ngoài ra, bạn có thể thấy lỗi đó xảy ra trong this video.