《MongoDB高手课》学习记录(第二十四天)

写在前面

第四章的内容就目前来看,有点失望。实际的东西不多,太理论,有点糊弄。说难听说太水了。特别像今天要学的内容,本以为有很多干货,结果讲自己的产品说了半天,测试版还得连线使用。就像极客时间上的《Vue开发实战》课程,花了大量的时间去讲 Ant Design,还没讲透。
好了,不吐槽了,换个角度看,也说明攒一门的不容易。开始今天的学习吧。

第二十四天

今天要学习的是《44 | 关系型数据库迁移》、《45 | 数据库迁移方式及工具》、《46 | Oracle迁移实战》

从关系数据库迁移到MongoDB的理由

  1. 对于高并发的需求(数千-数十万OPS),关系型数据库不容易扩展(相对的)
  2. 快速迭代,关系型模式太严谨(所以说模式设计很重要,预戴皇冠,必承其重)
  3. 灵活的JSON模式
  4. 大数据量需求
  5. 地理位置查询
  6. 多数据中跨地域部署(关系数据库不是不行,太光钱了)

应用迁移难度

  1. 关系型数据库之间迁移相对简单
  2. 但关系型到文档型,则相对复杂
  3. 需要考虑;

    1. 总体架构(比如单机式改成分布式)
    2. 模式设计(从关系模型改成文档模型)
    3. SQL语句/存储过程/JDBC/ORM等
    4. 数据迁移(如何处理已有数据)

总体架构

这是说的三倍资源,是因为MongoDB推荐最少要部署3个结点。
image.png

模式设计

这个才是重中之重,本来想先学习这章的目的也是这个
image.png

迁移的主战场

image.png

数据迁移

接下来的重点也是放在了数据如何迁移上,当然是借助工具的
image.png

数据库导出导入

这块是以MySQL为例,先将表导出成csv文件,然后用mongoimport将csv的表数据,直接转成文档。
适用于直接换库的场景
image.png

批量同步

主要就是借助于ETL工具了,既然是批量处理,当然对系统的性能影响就比较大了,适用于定期结转。比如将历史交易记录转到查询机,用于业务分析等
image.png

实时同步

当然还是借助于工具比如GoldenGate,只是由于是小批量时时结转,所以对系统的影响小,但如果出了问题就另说了
image.png

应用主导迁移

就是在团队协助,在不影响业务的同时,一步一步将应用从关系数据库迁移到文档数据库,当然投入就大了,周期也长,但最保险
image.png

数据迁移方式总结

image.png

迁移实战

这就不说太了,就是介绍了一下tapdata的使用
image.png

附录

Golden Gate
Talend
Pentaho(Kettle)
Informatica

你可能感兴趣的:(mongodb)