暂无图片
暂无图片
10
暂无图片
暂无图片
暂无图片

国产数据库替换的几点建议

原创 多明戈教你玩狼人杀 2022-06-29
3357

我本人是从2020年开始做国产数据库的替换,彼时赶上华为芯片断供的新闻,和从事芯片的朋友聊起这事。他说了一句话,芯片代工断供,只是大家所看到的最终结果,其实连芯片设计软件都不能自主,说不定还有更多软件是被卡脖子。

说者无心,听者有意。我评估了一下公司手头的数据库,超过一半都是国外的商业数据库。即便是开源的MySQL,也有了商业版。如果哪天真到了数据库软件断供那天,不再为中国的企业提供任何服务,我们该怎么办?退回当年大规模用盗版,还是替换成国产数据库?第二天来到公司,我就开始在研究市面上各类国产数据库,也在测试环境开始做一些实验。那段时间同事和领导对我的行为褒贬不一,有的觉得我想法很好,有的觉得我多管闲事。我的理由也很明确,即便现在和我们没有关系,然而刀子砍到自己身上那天真的什么都晚了。后来经过探索和实践,用了一年左右的时间,终于把生产环境的一套Oracle替换成了国产数据库,这中间也有很多故事,如果单独写又是一篇长文。从选择到迁移到上线,一个流程下来,让我对国产数据库替换有了实际操作层面的认知。

如果你和两年前的我一样,有这方面的想法,我希望能够通过本文,带来一些启发给你。


Part I 换新还是换旧

很多传统企业,尤其是信息化时间比较久的企业,都有大量的老旧系统。因为历史原因,仍然在运行中,有的版本早已经过了支持期限,有的甚至负责开发的公司已经倒闭了。这类老旧系统往往都跑在商业数据库上,依托着商业数据库的稳定以及售后服务,才勉强支撑下去。

这类系统我不建议去替换,除非业务部门牵头,对系统进行重构甚至重新开发。一个新数据库,无论怎么宣传兼容某某数据库,实际真正跑起来,都会有很多你想象不到的坑。老旧的系统在很难找到开发人员的情况下,这些坑靠DBA自己是填不上的。强行替换不但会给运维带来很多问题,也会让正常的业务难以为继。这不仅仅只是被人说“XXX跑的好好的,你换掉它干什么?”,而是影响公司业务运营。

对于这类系统,我通常会定期做汇总,xxx系统已经x年没有做过更新,xxx系统原厂也不再提供后续支持,xxx系统数据库版本过低官方已下线等等。提前把相关的风险告知系统负责人或者业务部门,至于是否有预算去改造去替换,不是DBA自己能决定的。

与此同时,一些即将立项或者开发进度较为靠前的系统,替换起来就容易很多。这类系统往往可以成为最早的试验田,而这时候兼容xx数据库的优势就发挥出来了。选择一款开发人员在语法和功能上适应更容易的产品,由DBA辅助,是可以完成从旧数据库到新数据库的替换工作。这其中如果说服项目经理或者业务部门,需要DBA对两种数据库有着较为清晰认知,并且替换的理由也要立得住。切忌为了换而换。

把握住一个大原则,数据库是为应用系统服务的,应用系统是为业务服务的。站在业务的角度,帮助他们降本增效才是最终目的。替换的结果如果达不到,无论新旧数据库,都不要轻易尝试。


Part II 什么样的阶段替换

和成熟的商业数据库或者开源数据库不同的是,绝大多数国产数据库都处在一个告诉发展的阶段。一个大版本更新的周期可能比过往的产品要短,功能的演进性能的提高稳定性的进步,都肉眼可见中发生着。成熟的数据库我们可以按照一锤子买卖的思维去做,安装一个稳定版本,没有大的问题,一直用到这个系统下线,这也就诞生了无数上一部分提及的老旧系统。

然而在替换国产数据库时,这种思维就没法再继续用下去了。稳定阶段还没到来,后续有了大的版本更新,就要做出抉择,是否要升级迭代。这就给了DBA一个难题,需要较为准确判断这个数据库产品的生命周期和开发阶段。之前的经验,我会选择先看看各家官网或者推送,然后和相关厂商的人去聊一下,你们产品未来两三年年,有什么相关计划?有没有什么大的架构调整或者大的功能变动?

接下来对这些未来可能做的大动作做个评估,会不会对自己未来的数据库管理产生重大影响使得不得不升级。假如我现在使用一个稳定版,如果半年后就必须做升级,那这个时间点,我宁可选择不替换而再等等。每次数据库升级迁移,一定都是要鸡飞狗跳一下,基础设施、应用运维、业务部门都要一起折腾,不是换个磁盘插根内存条那么简单。

在这方面我比较保守,之前替换的时候,先选择了一个稳定版确认了在未来一年内,不会有哪个迭代对系统特别重大的变化后,才选择进行测试,测试环境又用了三个月才进入生产环境。在生产环境刚开始运行的过程中,确实遇到了些许问题,一方面是经验不足,另一方面是产品的某些方面和宣传有出入。经过开发人员的继续开发,平稳跑到现在。

如果你看好的数据库是一个还在急速成长中的产品,那不妨参考一下我的做法。


Part III 替换的一些决定因素

中国的多数企业客户,并不是和互联网大厂一样,有大量的技术人员在支撑。很可能几万人的企业,IT部门只有几十人,分摊到各个条线,留给DBA的一只手数的过来。有的甚至一个部门只有几个人,还身兼着网管和采购办公电脑的职责。直接采购和二次开发的比重也非常多。

替换多少,怎么替换,一定要和部门的人力配置相关联。假如一个公司就你一个DBA,即便是稳定的商业数据库,都让你每天的工作量超负荷,这时候千万不要轻易动替换的念头。因为替换的过程以及后续的运维,将是一个你无法控制的工作量,这其中还包含着你去学习一个新数据库的时间,以及后续犯错填坑的时间。如果反过来,部门里大家职责相对明确,你的工作内容让你游刃有余或者有其他同事可以帮你分担,再去评估替换数据库。对于一些业务量不大,风险和业务部门关系都可控的系统,不妨考虑替换掉一些。

有的系统因为各种产品天生的不足,这类系统可能导致架构上的臃肿,比如常见的MySQL+Hadoop,innodb引擎用来做OLTP很不错,但是自身的先天不足,不得不用hadoop来做报表,但是hadoop的长处在于海量数据的存储和离线计算,实时性就差了点意思。如果能有一个产品完成这两样需求,又能精简架构又能提高实时性,何乐而不为。

如果你是在金融行业,或者有着严格的监管要求,一定要提前反复阅读监管文件,并且和公司负责法律合规、信息安全的相关同事进行沟通,逐项核对。确保你要替换的新数据库能够满足每一项监管要求,记住那句话,部分模块合规简称不合规。

还有就是,不要高估自己的学习能力和处理问题的能力。很多资深运维人员,因为经验丰富了,有时候就会产生错觉,面对一个全新的产品,自己也能驾轻就熟趟过去,全然忘记了自己刚入行时候的狼狈景象。然而随着年龄的增长,很可能自己学习新东西的能力已经打了折扣,这时候面对一个新数据库,一定要把自己当成一个门外汉,放低预期。这样在替换的时候,才不至于低估了难度和风险,使得整个项目进度失控。


作为常年和数据库打交道的人,我们都清楚,一个成熟的数据库产品需要时间的磨砺,国产数据库的成长同样也需要我们给予耐心,真正做到自主可控,可能5年可能10年甚至更久。保持一颗接纳并批判的心,去面对国产数据库,做得好我们赞扬,做得差我们指出,才是一个积极地态度。

最后修改时间:2022-07-01 16:30:03
「喜欢这篇文章,您的关注和赞赏是给作者最好的鼓励」
关注作者
1人已赞赏
【版权声明】本文为墨天轮用户原创内容,转载时必须标注文章的来源(墨天轮),文章链接,文章作者等基本信息,否则作者和墨天轮有权追究责任。如果您发现墨天轮中有涉嫌抄袭或者侵权的内容,欢迎发送邮件至:contact@modb.pro进行举报,并提供相关证据,一经查实,墨天轮将立刻删除相关内容。

评论