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://www.cnblogs.com/mindyme/p/4930411.html