一次面试中,关于MYSQL迁移到MONGODB 的思考

一次面试中,关于MYSQL迁移到MONGODB 的思考_第1张图片

昨天面试了一个MYSQL的DBA, 在面试的过程中有一个项目经营,某银行的MYSQL数据到MONGODB 的数据迁移. 我比较好奇,多问了两句

问: 我还比较敢兴趣您这边的MYSQL 到MONGODB 数据迁移项目的经验,您能谈谈吗?

答: 银行交代需要将目前的MYSQL 的数据迁移到MONGODB 中, 我们通过 XXXX的方法将数据迁移到了MONGODB

问: 这个项目从MYSQL到MONGODB 的原因是什么呢?  这样有格式的数据变成无模式的数据,他的意义在哪里,程序需要不需要改动呢?  成本是多少?

答: 我不知道,我就是按照交代的做,主要的原因是银行认为 MYSQL 承载的数据量小,查询大数据量的表慢,MONGODB 快,所以就迁移了. 成本什么的我也不知道.

问: 那其实有没有可能我们通过分表的方案,将这些大表进行分割后,分散到多个MYSQL的物理服务器,这样就可以满足相关的要求了.

答:就是这样的想法,MONGODB 才用的少.

其实在很多项目中,都会遇到类似的问题,数据库的使用"误区", 主要的原因是, 架构师自己也搞不清众多种类的数据库,到底应该用在哪里, 而互联网的大旗一直在挥舞着MYSQL ,导致哪里都是MYSQL ,最终传统行业不吃你那套,导致数据库选型的失败和项目的重构和返工.

MYSQL 他不是万能的, 所以考量一个架构师的标准中是否也应有一项数据库的选型.

那我想试着回答上面的问题

问: 我还比较敢兴趣您这边的MYSQL 到MONGODB 数据迁移项目的经验,您能谈谈吗?

答: 好的,实际上数据迁移并不是整体项目重要的部分,代码的重构才是这个项目的重点,将格式化的数据,转变为无格式的数据,这次项目主要转换的是XX流水日志. DB 在这个项目中的工作点并不是很多,但意义很大, 通过此项目,未来的和日志有关的数据可能都会存储在MONGODB中,而不是MYSQL.

问: 这个项目从MYSQL到MONGODB 的原因是什么呢?  这样有格式的数据变成无模式的数据,他的意义在哪里,程序需要不需要改动呢?  成本是多少?

答: 这个项目从MYSQL 到MONGODB 主要的原因在于从单库来看,MYSQL的数据的承载力和数据的存储容量,的确是无法和MONGODB 进行比较,并且从数据的单条读取时间来看,两种数据库也存在着比较大的差别. 所以后面项目改造选择了MONGODB 代替MYSQL. 并且业务是日志,则日志可能变动的情况比较多,为了更适应于业务,则MONGODB 的无结构模式更适合来存在这样的数据和解决这样业务的问题., 而关键在于程序的改动, 但无结构化的数据的改造成本,远远低于将MYSQL 换为其他传统RDBMS的数据库的成本.

问: 那其实有没有可能我们通过分表的方案,将这些大表进行分割后,分散到多个MYSQL的物理服务器,这样就可以满足相关的要求了.

答:实际上不少单位也是这样做到的, 可能有两个原因 1  本身对MONGODB的不熟悉, 2 懒,在技术上不愿因在进行投入,而采用了传统意义上的认为正确的方式, 而忽略了 运维和管理成本的问题,明明可以通过很少的成本来完成的工作,非要通过昂贵的成本来完成, 所以这样的思路应该被改变.

所以如果,这个DBA 能以这样的思路来回答问题,结果也会是不同的.

一次面试中,关于MYSQL迁移到MONGODB 的思考_第2张图片

你可能感兴趣的:(数据库,java,mysql,大数据,mongodb)