乐趣区

关于mongodb: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 个结点。

模式设计

这个才是重中之重,原本想先学习这章的目标也是这个

迁徙的主战场





数据迁徙

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

数据库导出导入

这块是以 MySQL 为例,先将表导出成 csv 文件,而后用 mongoimport 将 csv 的表数据,间接转成文档。
实用于间接换库的场景


批量同步

次要就是借助于 ETL 工具了,既然是批量解决,当然对系统的性能影响就比拟大了,实用于定期结转。比方将历史交易记录转到查问机,用于业务剖析等

实时同步

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

利用主导迁徙

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

数据迁徙形式总结

迁徙实战

这就不说太了,就是介绍了一下 tapdata 的应用






附录

Golden Gate
Talend
Pentaho(Kettle)
Informatica

退出移动版