Core Data系列五——数据迁移方案

• 为什么需要迁移数据？
  数据库的模型文件发生了变化；旧的数据库文件无法按照新的数据库模型被读取，因此需要迁移到新的数据库文件中。

• 数据迁移的过程
  Core Data分别创建了两个stack:source stack和destination stack, 然后遍历Mapping model中每个entity mapping，做以下三件事情：

  1. 基于source stack，Core Data先获取现有数据，然后在destination stack里创建对应的当前entity的实例，只填充属性，不建立关系；
  2. 重新建立entity之间的关系；
  3. 验证数据的完整性和一致性，然后保存

• 数据迁移的几种方案
  在迁移过程中，可以从两个正交的维度进行自定制：

  1. 在迁移的过程中可以执行自定制的代码。通常是通过提供自己的migration policy类来实现。
  2. 可以自定制版本检测和迁移过程。指的是自己建立migration manager，判断是否需要迁移，以及控制迁移过程。

  Core Data支持三种数据迁移方案：light weight迁移、 default迁移和custom迁移。这三种方案在上述两个维度上也都有差异：

  1. light weight迁移：无需提供mapping model, 而是由Core Data自动infer一个mapping model；无需自定制版本检测和迁移过程。 light weight迁移是通过在添加PSC时设置两个选项实现的：NSMigratePersistentStoresAutomaticallyOption和NSInferMappingModelAutomaticallyOption
  2. default迁移： 需要提供mapping model（以及entity migration policy)，无需自定制版本检测和迁移过程。采用default迁移方案需要在添加PSC时设置NSMigratePersistentStoresAutomaticallyOption选项
  3. custom迁移：需要提供mapping model(以及 entit migration policy), 并自己控制版本检测和迁移过程。 关于custom迁移，objc.io上有一篇很好的文章 , 后续我也会这篇文章写一个总结，敬请关注。

• 几种迁移方案的性能对比
  关于上一节中的三种数据迁移方案，我做了个简单的测试。测试的工程里数据库结构很简单：三个entity, 但只有一个entity表中有10000条数据。测试结果如下：

  1. light weight迁移： 耗时约1.3s, cpu峰值80%, 内存占用大约3M
  2. default迁移：耗时约23.6s, cpu峰值为170%, 内存峰值为28M, 迁移完成后回落到23M
  3. custom迁移：耗时约26s, cpu峰值为149%，内存峰值为28M， 迁移完成后回落到23M. 由于这种迁移过程中有新的数据库对象创建，因此性能表现可以认为跟default迁移表现差不多。

可以看出，light weight迁移的性能最优，default迁移和custom迁移的性能表现类似。 这在官方文档里也有说明：light weight 迁移方案，core data无需把数据库条目都加载到内存里，而是通过直接执行SQL语句来完成迁移，所以性能最优。

参考文档：

• https://developer.apple.com/library/prerelease/watchos/documentation/Cocoa/Conceptual/CoreDataVersioning/Articles/Introduction.html#//apple_ref/doc/uid/TP40004399-CH1-SW1 我对这篇文档做了一些注释
• http://blog.csdn.net/jasonblog/article/details/17842535
  勘误：light weight migration由于不会加载对象到内存中，因此不会存在大数据量时的内存问题
• http://objccn.io/issue-4-7/