数据迁移总结

  1.复杂数据迁移时,涉及到单数据源读,单数据源写,并且在写数据源中读的情况,那么在迁移程序必须设置多数据源对数据读写处理.尤其在数据结构比较混乱的时候!
  最关键的是在数据迁移错误时,进行程序补救措施,这可以节省很多时间!
  2.数据迁移过程中,出现数据问题时,不要直接在程序中删除,比如list中remove后就不做任何处理,
  错误数据要做标识,或单独存放在记录错误数据的表中,然后根据对错误数据分析再进行确认是否要特殊处理或者放弃!要记录导致错误的原因,如果出错的数据只是小错误,不影响整体数据的有效使用,那么将来可能需要处理,如果不记录就可能出现大海捞针情况出现;
  3.根据错误类型来统计数据个数,那么就可能会出现某类原因导致的数据量比较大,这可能是没有了解到的业务特殊之处导致的,进而了解旧业务在在数据迁移程序中做单独处理.
  4.数据迁移时要考虑旧数据的数据长度导致迁移不成功的情况,尤其在旧数据库字段不熟的情况.
  5.数据迁移完成后,对旧数据个数进行统计和导入新库数据个数统计,然后进行数据个数对比.如果新库数据条数小于旧库数据条数,
  表明数据迁移缺失,此时可以做出判断的条件如下:
   a.数据迁移sql条件过滤出去数据;
   b.在封装数据进行条件过滤时各种情况的数据;
  5.将测试数据导入测试库时,对数据进行分析,并且导入数据测试要进行多次,3次以上为宜.
  6.防止数据迁移对数据造成的影响,构成系统使用基础的数据应使用编号,而不要使用Id做关联.改动性很小的基础数据可以使用Id做关联,但是此时数据可变动性变小.尤其在业务系统中,做数据做判断时,使用编号进行判断比使用纯粹Id判断可读性更好;数据迁移优势更好.使用Id关联,那么必须保证Id不可以改变,否则所有数据都会出现问题.
  7.数据迁移开发时间估算,如果旧数据字段含义不熟悉并且和新数据对应关系比较复杂,且旧数据库设计不怎么遵循第一范式即字段原子性比较差,那么数据迁移数据对照的问题,旧数据业务字段和新数据业务字段对应,和旧数据业务和新数据业务对应,都是极其耗费时间的事情,需要对旧数据业务熟悉和对新数据业务非常熟悉,出错的可能性才会降低,否则业务无法对应那么就会导致各种问题.并且数据迁移时间,不会比新数据业务开发时间,不可能几天就完成.可能是新业务开发时间的1.5-2倍时间.
  8.迁移数据有效性问题,迁移数据后需要对数据的真实性和有效性进行判断,并且及时调整.
  9.数据迁移程序开发,要比单纯开发新系统要困难,困难在于新老业务都需要熟悉且新数据库数据来源的处理,数据状态细节一一对应需要非常细心处理,耗费心力,比如新老系统的状态值对应,业务要熟悉,开发要细心,否则很痛苦,有折磨人内心的感觉,此时务必保证头脑清醒,如果头脑不清醒,一定错误连连,让开发者开始怀疑人生!
  10.如果迁移数据到新数据库有误,此时旧数据库和新数据库中数据如果没有某个字段或者联合字段做唯一性处理,不要出现以下的情景:迁移数据Id被其他用户写入的数据抢走,旧数据的数据Id被用户持久化的字段抢走了!
  解决方式不要吝啬必须预留出来足够足够多的数据Id给迁移数据使用!
  此时主要矛盾点在于找到迁移失败原因和每次验证猜测都需要很多时间,尤其数据量大的情况下,注意测试时间使用!
  需要根据数据特点,进行有技巧性地测试,而不能像最开始大批量数据迁移时数据测试那样!