写在数据库国产化替代加速之际

7月底《安全可靠评测指南》正式发布了，放弃清单，依托标准成为了最终的方案，至此国产化替代中大家都在观望的事情也就尘埃落定了，一些关键系统的国产化替代迁移也很快会列上一些企业用户的日程表中。

很多企业目前可能关注的还是数据库选型、数据库迁移的事情。实际上目前还在做选型的企业大多数是还没有真正下定决心的，只是利用选型这个工作观望一下，看看替代工作是不是必须真的干。真正的实干派其实已经闷头干了一两年，成果也已经十分明显了。数据库的替换不是一件小事，当然存在很多困难，需要付出很多。因此大家存在这种观望的心态也是可以理解的。

(相关资料图)

就像90年代中后期，一些用惯了DEC VAX小型机的用户向UNIX平台迁移的时候一样，要从十分好用的VAX/VMS、RDB数据库向UNIX/ORACLE的那么难用的组合迁移，真的是老大的不愿意。实际上2000年代初，我们的一些金融客户从“稳定可靠的”SCO UNIX向“不太靠谱”的LINUX迁移的时候，也是满脑子狐疑的，生怕LINUX的不可靠会影响业务。可能以现在的眼光来看这件事，这种顾虑是相当可笑的。实际上目前我们可能也只是在重复那时候的故事,不太靠谱的LINUX总有成熟的一天，现在看上去不太靠谱的国产数据库也是如此。

有些人可能觉得我举的例子都太遥远了，实际上一个更近的例子也摆在面前。十年前去IOE的时候，用不大靠谱的MySQL来替换十分优秀的Oracle的坑你不都已经跳过了吗，有这杯酒打底，你还怕什么呢？

数据库的国产化替代一旦做起来，实际上也没有想象的那么难。今年年初的一个数据库国产化的内部研讨会上，有的企业已经在分享核心系统替换的经验，也有企业依然认为替代的难度太大，不敢轻易尝试。实际上这些并不是技术问题，更多的是态度的问题，因为二者所处的行业是完全相同的，应用系统也十分类似。感觉到难或者容易，仅仅是态度的问题，而并非技术问题。IT系统在大多数企业里都是服务于业务的，不出问题成为很多企业IT部门领导最为关注的。做国产化替代对于很多企业来说并不是刚需，都是被动做的事情，因此也没必要太积极了。不过也不能干等着，技术上的储备还是必要的，那就多做点测试和评估吧，小心些总不会有大问题。

不过该来的事情总归会来，数据库的国产化替代哪怕不是因为国际政治风云，单单从知识产权保护和合规化考虑，也是早晚要做的。参与国际化竞争的中国企业，总不能一直采用盗版的方式去使用Oracle吧，哪怕不使用国产数据库，大批量转向使用成本较低的开源数据库也是早晚要做的事情。可能有朋友会不服气，说我们的Oracle都是合法购买的，那么我建议你去认真看看Oracle的许可证文件。最近已经有用户收到了Oracle发来的没有买足许可证的律师函了。买了Oracle许可，但是没有正确的按照使用环境购买足量的许可证也是盗版的一种，会不会被人告要看人家想不想告你。

国产化替代一旦开始，那就是没有回头路的。替代迁移工作告一段落，运行运营的问题就浮出水面了。我们不仅需要顺利的替代，更需要稳定的运行。因此基于国产数据库的运维支撑与服务能力建设就迫在眉睫了。

目前我们的数据库第三方服务能力主要还是集中在Oracle、DB2、SQL SERVER等商用数据库上，另外Mysql、Postgresql等开源数据库经过这些年的应用，也有了一定的服务能力。而国产数据库的服务能力还处于十分低的水平。一旦关键行业大规模开展数据库国产化替代工作，首先会出问题的就是运维支撑。有钱的单位可能想反正我有钱，就买点原厂服务吧。实际上如果这项工作全面开启，原厂也忙不过来，你买的原厂工程师大概率也是原厂外包的第三方小白，买原厂服务也就是买了个安慰而已。

对于一些有实力的企业来说，既然第三方服务能力不行，那么就自建运维队伍吧。最近我已经听说了几个国企正在自建新创数据库运维队伍，对于想投奔国企的DBA来说，这也会是一个很好的机会。

做数据库第三方服务的企业目前实际上是面临很大的机遇，只要能力足够，这两年的客户需求是会越来越强烈的。不过还是有些问题，国产数据库要掌握起来也没那么容易，培养出一批能够从事这方面工作的工程师尚需时日。这星期我都在折腾Gaussdb和Oceanbase的运维知识图谱，要理解指标和等待事件背后的运维知识，就是一件十分困难的事情，我们能够获得的技术资料接近于零，而运维案例那就是0。实践出真知，没有大量的实践，是积累不出真知的。

实际上各个数据库厂商在摩拳擦掌，盯着用户的钱包的时候，是不是也在售后服务方面多下点工夫，组建一些产业联盟，和数据库服务厂商一起为未来的客户储备一些运维服务技术队伍呢？我希望在这方面，整个国产数据库生态能有所作为。

关键词：