關於大資料量下Core Data的資料遷移

這種資料遷移模式稱為lightweight migration（可能對於開發人員來說是lightweight），開發人員只要在新增persistent store時設定好對應選項，其它的就交付給core data來做了：

自動遷移persistent store很好理解，就是將資料從乙個物理檔案遷移到另乙個物理檔案，通常是因為物理檔案結構發生了變化。

其它初始化場景可以參考

initiating the migration process

。以上都建立在core data能夠自動找到sourcemodel和destinationmodel的基礎上，如果無法找到對應的兩份model，則需要開發人員手工建立nsmigrationmanager來進行資料遷移（可以參考

use a migration manager if models cannot be found automatically

）。那麼，資料遷移的過程是如何進行的？

利用這三樣，當呼叫如下**時（

core data建立了兩個stack（分別為source stack和destination stack，可以參考

core data stack

1. 基於source stack，core data先獲取現有資料，然後在destination stack裡建立當前entity的例項，只填充屬性，不建立關係；

2. 重新建立entity之間的關係；

3. 驗證資料的完整性和一致性，然後儲存。

考慮到第二步是重新建立entity之間的關係，那麼應該是在第一步就把所有entity的物件都建立好了，並且保留在記憶體中，為第二步服務（事實上也是如此）。

完成第二步後，所有資料還是維持在記憶體中（可能還有兩份，因為有兩個stack），在完成資料驗證後才真正儲存。

針對這種情況，我們可以自定義遷移過程。

自定義資料遷移的過程通暢分為三步：

第一步是判斷是否需要進行資料遷移：

第二步是建立乙個migration manager物件：

第三步是真正發生資料遷移：

上面三幅圖所展示的**在記憶體使用量上跟lightweight migration也沒什麼區別，無法解決記憶體峰值過高的問題。

multiple passes

來解決。

關於multiple passes，官方文件的說明很簡明扼要，如有需要，可以參考

stackoverflow上的這麼一篇帖子。

採用上述方案來解決資料遷移過程中記憶體峰值的問題，我們仍然需要關注遷移所耗費的時間、記憶體，從而能夠在資料上驗證方案的有效性，並且在使用者互動方面進行一些必要的更改（總不能讓使用者傻傻地在那邊等資料遷移吧）。

雖然可以解決記憶體峰值的問題，但也引進了其它問題。

1. 需要對資料模型進行劃分（以及變更），存在一定的工作量和風險；

3. 需要手工編寫multiple passes遷移**；

6. 對資料模型重新劃分後，無關的entity簡單變更也會引起整個store和model的不相容，需要遷移，那麼是否考慮分庫？

7. 這麼大的動作服務的使用者數是很少的（只有少數使用者會遇到，或者是很少），但卻是比較資深的（因為訊息記錄多），疼。。。

8. 這無法解決單個entity資料量過大的問題，針對這種場景，只能自己手工編碼進行小批量的資料遷移；

jason

2014.01.02 @ hangzhou

evernote