数据库国产化替代既然已经成为一项规避风险的策略被启动了，那么我想过多的抱怨国产数据库不好用，迷恋Oracle的好实际上意义就不大了。实际上没有国产化替代，去IOE时代就已经启动了对Oracle数据库使用的反思，是不是所有的系统都必须使用Oracle数据库。因此MySQL在这个阶段大行其道，在很多中小型系统中替代了Oracle。虽然因为传统企业不具备互联网企业那种能力，而MySQL没法大规模的在传统企业核心系统中替代的综合能力又不够强大，因此去IOE行动没能把最需要去的O去了，反而让IE被误伤了。
这些年的数据库国产化替代，其最大特点是在关键业务系统中用国产数据库替代Oracle等供应链不可控的西方进口数据库产品。什么叫供应链不可控呢？前阵子遇到了科大讯飞的朋友，他介绍说自从讯飞上了黑名单后，采购Oracle数据库，哪怕Oracle和希望卖给他们，也必须拿到美国商务部的批文才可以，这就是不可控的供应链。实际上已经有不少国内的企业上了所谓的管控名单了，这份名单的长度还在不断加长。与其说哪天上了黑名单再去想办法，不如主动地采取一些措施去规避这种风险。这就是关键行业与企业数据库国产化替代的必要性的部分原因。有些朋友可能会说，反正Oracle也没有许可证，网上下载就能用，谁能限得住呢？对于参加国际化合作与竞争的中国企业，遵守基本的国际法律，尊重知识产权是十分基本的操守，大量盗版并不是一个合理的选项。
在一些业务十分复杂与关键的行业实现数据库国产化替代是否可行呢？前几天我和一个银行的IT部门主管聊天，他说他们核心系统去O的做法很简单，就是把现在的核心系统进一步拆解，拆解出一部分，就用国产数据库替代一部分。稳定一部分再搞一部分，这样下去，几年后，剩下的核心系统也变得没那么复杂了，自己的国产数据库使用经验也已经比较丰富了。这个时候再来把剩下的核心系统替换到就水到渠成了。从上面所说的做法来看，应该是完全可行的。
实际上很多朋友并不是反对去O，而是反对用国产数据库替代Oracle，他们认为开源数据库就很不错了，为啥要去用花钱的，在开源代码基础上开发的国产数据库呢？我不知道这些朋友仅仅是一个DBA还是企业的相关管理者，可能所处的位置不同，看问题的角度也不同吧。如果作为企业的IT主管，可能会从多个方面去考虑这个问题。包括合规性、应用迁移成本、售后保障能力、安全责任等因素。
从合规性方面，很多行业对软件供应链安全是有一定要求的，数据库中的加密算法是否支持国密，安全等保级别是否过关等都是要考虑的因素。应用迁移成本方面，是否与Oracle等需要替换的数据库有较好的兼容性决定了迁移成本，这一点肯定是需要企业去认真核算的。售后保障能力是开源数据库的一个巨大的痛点，很多朋友可能觉得开源社区拥有更多的售后资源，不过不幸的是，这些资源并不向你承诺SLA。我曾经有客户在使用CDH的时候遇到问题，经历了痛苦的数月仍无法解决，无奈只能购买原厂服务的惨痛教训。安全责任是另外一个十分重要的问题，可能DBA不关心，但是企业的决策者是一定要关心的。如果你选择了开源产品，那么决策者就是最后的责任人。而你如果采购了哪怕是基于开源包装的国产数据库，那么厂商是有义务帮你解决问题的。
我有时候看微信群里DBA们的讨论，大多数在谈别人如何不行，很少有人在谈如何解决这些问题。这种空谈其实是没太大价值的，顶多也就让自己痛快了一下。与其看这个不习惯，看那个水平差，不如做点对数据库国产化有价值的事情。比如去帮国产数据库指出解决问题的方法，发现使用体验中的不足，甚至干脆自己下场去开发一个数据库产品来碾压这些你看不上的东西。坐而论道很容易，找别人的毛病更容易，不过对于这项工作而言，作用甚微。
其实今天本来没想谈上面那些复杂的，争议十足的问题的。其实今天周末也想写点东西，还是周四参加OB老友会对我的思想产生的冲击。我是今年第二次在数据库论坛会议上遇到太保数智研究院的首席数据库专家林春，每次遇到他都给我十分深刻的印象，这一次尤为如此。当有些朋友提出一些关于数据库国产化替代中遇到的问题的时候，他总是很积极的分享他们遇坑避坑的经验。从他对太保数据库国产化替代的介绍中，我们可以看出他们遇到的问题不会比别人少，不过在他们与厂家的共同努力下，这些问题都陆续解决了，他们也是踩着坑往前走的，走之后，身后留下的是一条依稀可见的小路。这种人多了，我想这条路会变成一条通途大路。
走尽坎坷成大道，历尽艰险又出发。电视剧《西游记》中的这两句歌词用在这里十分贴切。既然历史发展到这里了，那就往前走吧，无论你的自我认知如何，你如何看不惯现在正在发生的一切，事情就是这样往前走的。当年我们这批C程序员在JAVA大潮下变得十分迷茫的时候，也曾抱怨过JAVA这么垃圾，怎么现在那么多人用，我们也曾经希望JAVA是过眼云烟，C语言才是万世基业，不过在时代的巨浪前面，这些抱怨不过是一颗尘埃。
