去O？首选PostgreSQL而非MySQL | 浅谈运营商去“IOE”之精彩互动

Posted 2021-05-01 高效运维

参与讨论人员

• 盖国强@云和恩墨

• 龚勇@美资汽车厂-上海

• 陈洋@友宝-北京

• 李祝平@涛石云联-北京

编 辑

• 李 宁@TaOle-深（内容收集 & 整理）

• 董伟，萧田国（审核 &发布）

分享嘉宾介绍

王晓征 中国移动通信集团浙江有限公司信息技术部总经理助理，主讲嘉宾。

目前在浙江移动信息技术部负责应用运维和平台架构。1997年毕业于浙江大学电机系工业电气自动化专业，机缘巧合加入了浙江移动一直工作至今。走管理路线之前，干过开发、系统管理员，不过大部分精力在做DBA。

汤人杰@浙江移动，三少@浙江移动 中国移动通信集团浙江有限公司架构师，助讲嘉宾

关于本文相应的分享实录，请参见文末的“阅读原文”。

下面就是本次分享的互动环节整理（真的非常精彩哦：）。

问题1：浙江移动PostgreSQL现在进行到啥程度了，遇到那些坑？

回答1：浙江移动对去O的进程分为三个阶段:

第一个阶段是对可用的数据库进行分析

第二阶段是在生产系统中小范围上选定的数据库

第三个阶段是全面开始产品去O

目前进展到第二个阶段。在使用PostgreSQL的时候，为了能支持后续的大规模分布式环境，我们在小范围上的时候，使用的是PostgreSQL-xc的架构。

目前为止碰到一个最大的坑，就是多节点之间的数据偶尔出现问题，已经确认是bug，目前我们联合中移动苏州研发中心，华为，腾讯以及PostgreSQL社区，正在全力解决中，预计1-2个月内会解决。

关于这个坑，目前PostgreSQL-xc的首席架构师、日本POstgreSQL社区的主席铃木幸一已经介入，国内华为、腾讯等多家厂商均在全力解决，华为已经提交一个patch。

问题2，我有个小问题，我们Oracle其实不大，一个DG，但之前为了开发简单，很多的物化视图、存储过程，这种要迁移的话，是不是也只能重构了？还有其他好办法吗？

回答2：物化视图，需要重构；目前为止，没有其他数据库支持；存储过程，可以不重构，如果选择PostgreSQL的话，稍做修改即可。

个人建议，全部重构，把业务的逻辑还给业务，让数据库做数据库该做的事情；实际上如果数据库是单PostgreSQL库就可以搞定的，迁移的代价并不算大，目前如果你的应用使用了ORM的框架软件，那基本是可以平滑迁移的

问题3: 移动去O产品或服务，是否仅仅是信息部门角度的考虑，而从移动公司的角度来说，去O本就没有太大动力

回答3：事实上和你想的不太一样，我们IT部门角度一开始并没有想去掉谁。我们只是被动接招了。有些高层看来，如果你说你对去O有不同意，那么首先怀疑你的技术掌控力。

我们希望能发出自己的声音，你不全面分析，甚至不去掉一点O，没人听你说话的。此外，如果说去掉O的服务，我这些年一直自己在做，没有去IOE说法前就开始了.

问题4：是否应该考虑非关系型数据库？

回答4：数据库的发展历程来看，关系型数据库是比较经典的一种数据库，目前来看除了特定领域使用特定数据库外，OLTP类的业务可能关系型数据库还是最通用的选择。

OldSQL NewSQL NoSQL各有各的适用场景，去O更现实的是用不同数据库去实现不同的场景，而不是简单地去掉O，甚至全面否定关系型数据库。

有些产品技术上很有特点，不一定能在现实中得到有效应用，成本，开发团队适应度，技术成熟度，兼容性，方方面面问题都要考虑的，我们毕竟是在我们的现实环境中生存。开源也有关系型数据库嘛。

问题5：去IOE给浙移动带来经济效益了吗？请稍微解释下

回答5：去I我们已经接近完成，应该说经过这几年的努力，效果还是很明显的，具体数字我不便透露，但是我们在服务器上的TCO降低非常显著

问题6：如果以上问题都清楚，我还是要去 Oracle，请王总分析一下应用层的约束，浙江在目前阶段实际上还没对应用层做过多约束，甚至还保留现状？

回答6：目前我们对应用层没有太特别的约束，例如一些Oracle特有的函数之类的，要约束，基本上要求支持到sql92，就可以了，不能写sql92不支持的。

我们组建了一个开发DBA团队，还有数据管理的团队，来指导开发以及审核开发的所有SQL代码。

问题7：王总如何看待生态圈，PostgreSQL 是否有机会构建一个长期的，类似Oracle的生态圈？

回答7：我觉得吧，一切皆有可能。Oracle的技术生态圈走到今天，有多方面因素：

1.O记的产品发展进步和成熟度较好

2.O记的知识体系开放性较好，当年我玩metalink的时候，越玩越觉得叹为观止

3.O记对第三方技术合作伙伴还是比较重视的。国内第三方合作伙伴力量，比如盖总公司，发展也非常给力

4.O记连同合作伙伴的培训做的很火爆，最终用户现场力量的建设也比较有条件

以上因素综合起来，成就了今天O记的繁荣生态局面。

今天，mysql也好，PostgreSQL也罢，要建设一个良好的生态环境，也要借鉴。这个时代，发展太快，谁跑的快，地盘就是谁的。

如果说机会，机会一定是有的。其实如何去推广，我觉得还是方向和套路比较明确的，关键是落地。

有关PostgreSQL,我觉得现在我们可能正在迎来一次机遇。

就像我在去O分析中说的，MySQL和PostgreSQL有不同的适用场景，在传统行业的某些环境下，POstgreSQL可能比Mysql更适合。

这样或许也会给POstgreSQL的生态环境发展促成一些积极因素，众人拾柴火焰高，我拭目以待吧，我现在自己也在培养PostgreSQL DBA。

问题8:PostgreSQL和Oracle相比，目前主要的不足有哪些？

回答8：对于习惯于O记的成熟保障的DBA来说，可能会遇到几方面的挑战：

1，O记的监控实图和监控工具更多，监控能力上有差距；

2，开源数据库，出现底层bug的话，处理速度和O记比还是不一样的；

3，灾备方面，O记已经非常成熟了，相比POstgreSQL方面还没有那么成熟，现在也没有找到支持POstgreSQL的异构容灾复制或数据同步工具。

—————互动结束—————

点击最下方阅读原文可直达本文给力的去IOE分享哦~~

如何一起愉快地发展

这是一个新的时代！每个人都有自己的声音，值得被尊重，并且有机会被尊重。

高效运维系列微信群于2015年4月底创建，已然成为国内高端运维圈子，并成为运维行业垂直社交的典范。现有会员800余名，其中运维总监及以上级别会员300多名。主力成员分布甚广，不仅来自互联网大厂，更有包括移动、银联、农业等各产业朋友。

来吧朋友，共襄盛举。