写在前面
第四章的内容就目前来看，有点失望。实际的东西不多，太理论，有点糊弄。说难听说太水了。特别像今天要学的内容，本以为有很多干货，结果讲自己的产品说了半天，测试版还得连线使用。就像极客时间上的《Vue开发实战》课程，花了大量的时间去讲 Ant Design，还没讲透。
好了，不吐槽了，换个角度看，也说明攒一门的不容易。开始今天的学习吧。
第二十四天
今天要学习的是《44 | 关系型数据库迁移》、《45 | 数据库迁移方式及工具》、《46 | Oracle迁移实战》
从关系数据库迁移到MongoDB的理由
- 对于高并发的需求（数千-数十万OPS），关系型数据库不容易扩展（相对的）
- 快速迭代，关系型模式太严谨（所以说模式设计很重要，预戴皇冠，必承其重）
- 灵活的JSON模式
- 大数据量需求
- 地理位置查询
- 多数据中跨地域部署（关系数据库不是不行，太光钱了）
应用迁移难度
- 关系型数据库之间迁移相对简单
- 但关系型到文档型，则相对复杂
需要考虑；
- 总体架构（比如单机式改成分布式）
- 模式设计（从关系模型改成文档模型）
- SQL语句/存储过程/JDBC/ORM等
- 数据迁移（如何处理已有数据）
总体架构
这是说的三倍资源，是因为MongoDB推荐最少要部署3个结点。
模式设计
这个才是重中之重，本来想先学习这章的目的也是这个
迁移的主战场
数据迁移
接下来的重点也是放在了数据如何迁移上，当然是借助工具的
数据库导出导入
这块是以MySQL为例，先将表导出成csv文件，然后用mongoimport将csv的表数据，直接转成文档。
适用于直接换库的场景
批量同步
主要就是借助于ETL工具了，既然是批量处理，当然对系统的性能影响就比较大了，适用于定期结转。比如将历史交易记录转到查询机，用于业务分析等
实时同步
当然还是借助于工具比如GoldenGate，只是由于是小批量时时结转，所以对系统的影响小，但如果出了问题就另说了
应用主导迁移
就是在团队协助，在不影响业务的同时，一步一步将应用从关系数据库迁移到文档数据库，当然投入就大了，周期也长，但最保险
数据迁移方式总结
迁移实战
这就不说太了，就是介绍了一下tapdata的使用
mongodb
**粗体** _斜体_ [链接](http://example.com) `代码` - 列表 > 引用。你还可以使用@来通知其他用户。