数据库的国产化替代

今天是深圳慢生活的第八天，福田区也终于解禁了，凭核酸证明可以出入小区，乘坐公交了，企业也在有序复工。不过目前我还只能维持远程办公的状态，因为南京对外省人员还是采取3+11的方式，会去也要先居家。

前几天发了一篇关于数据库碎片化的文章，实际上我们处于一个碎片化的时代，世界上反全球化的势力也越来越强大，特别是俄乌战争这个火药桶爆发后，以意识形态、宗教、价值观等不同形成的全世界的割裂肯定是越来越严重的。对于数据库要不要国产化这个问题，以前可能大家还有一定的观点冲突。有些人认为数据库国产化必须全面开展，某运营商已经确定了2020年底前完成这一工作；有些人认为可以根据企业的具体情况慢慢实现国产胡替代，降低企业的运营成本；还有些企业认为数据库国产化涉及的成本极高，风险极大，要缓行。

不过随着新一轮的世界割裂，国际间的对立从政治上不断向经济上扩散是一个大家都能够看得见的过程了。于是最近这段时间，数据库国产化的问题又变得热门起来了，而且这回主要不是聚焦在要不要国产化替代上，而是如何做国产化替代上了。

数据库国产化实际上并不是一个简单的事情，我们选一款适合自己的数据库，然后把系统迁移过去就行了。很多企业经过二十年的信息化过程，已经拥有的存量系统已经十分巨大了，这些系统的数据库很可能大多数都是Oracle，开发团队与运维团队也都积累了大量的经验在Oracle数据库上，一下子要从Oracle数据库上迁移下来，也并不是一件十分容易的事情。首先我们需要制定一个策略问题，我们如何做数据库国产化替代？先动存量系统还是先不管存量，首先考虑新建系统；先动核心系统还是先不管核心系统，去迁移边缘系统？

数据库是一个上联应用系统，下达基础设施的关键型IT基础设施，数据库的迁移不仅仅关系到一个数据库本身，和企业的云平台、网络、服务器、存储、操作系统等也是紧密关联的。因此在考虑数据库国产化迁移的时候，我们还需要和企业的云平台建设，以及相关的IT政策做统筹考虑。除此之外，我们还需要考虑本次国产化改造是不是把国产CPU也一并考虑了。动数据库是伤筋动骨的事情，如果本次迁移只考虑选一个国产数据库，而没有考虑国产CPU的服务器问题，那么过两年是不是还得再遭二遍罪？

在这个问题上，可能从不同的角度考虑会有不同的选择，如果考虑数据库国产化后本身性能就有下降，再考虑国产化的数据库服务器，那么可以一下子受不了，因此选择暂时先不动服务器；怕折腾两遍的考虑既然做这么大动作了，干脆彻底换了，省的以后再折腾。选择这两种策略的没法说哪个一定就是错误的，根据企业不同的现状，采取不同的措施对于企业自身来说，是稳妥的。

不过对于负载极高的核心系统来说，从X86迁移到国产CPU环境，不是简单的一个服务器平台迁移的问题。很可能在X86上表现的差不多的数据库产品，到了某个国产芯片的环境中，性能上会有较大的差异。因为国产CPU、国产操作系统、国产数据库的磨合时间很短，很多情况下仅仅是完成了兼容性的磨合，数据库如何更好的发挥操作系统、硬件的性能，国外商用数据库上花了10多年才完成，我们的国产数据库要完成这个工作，依然需要较长的时间，在各种业务负载下磨合几年才能做好。

为了避免这些问题，国内的一些金融机构采用了选择分布式数据库的方式，避免单机性能问题导致系统无法承受高负载压力，从而确保今后系统能扛住超高并发的冲击。这是一种相对保守，不过也是相当明智的做法。通过将核心系统迁移到分布式数据库，并进行相应的改在，让核心系统的横向扩展能力更为强大，从而利用分布式数据库的横向扩展能力提升总体并发能力，这种工作虽然投入巨大，不过一旦完成，相当于对自己的核心系统完成了互联网化改造，意义十分深远。其缺点是，投入巨大，也存在一定的风险，需要企业的高层十分坚决才能成功。

其实数据库国产化替代中一个比较纠结的问题是存量的不是特别重要的系统是否需要迁移，如何迁移的问题。按理说这些系统已经购买了商用许可证，凑合着用是最省钱的，当然前提条件是不再购买renew，否则renew也是一笔不小的钱。也有朋友说，不买renew继续用呗，从实际操作上可以这么做，不过不买renew，就不能更新补丁，不能升级了。随着时间推移，这些系统的数据库也还是存在升级的需求，因此在这次国产化改造的时候把这个问题解决掉也是一种很常见的选择。

有些企业选择用这样的系统先来练练手，积累迁移改造与运行维护的经验。这也是很多企业的常规选择。对于数量十分大的小系统的迁移，其实很大的工作量并不在于数据库迁移本身，而是应用的适配性改造。如果国产数据库与Oracle等商用数据库之间的代码兼容性很强，原来在Oracle上的应用系统可以不改一行代码就平稳迁移，这无疑是成本最小的，也是企业最欢迎的。目前很多国产数据库厂商都在自己的产品里加大兼容性的支持，这实际上是比较好的。

去年和一个客户探讨数据库国产化改在的方式，他们设计的方案是较小的系统，如果使用开源MySQL/POSTGRESQL等开源数据库的，暂时都不动；使用Oracle数据库的，选择一款和Oracle兼容性最好的数据库产品，尽可能不修改任何代码就迁移过去；大型核心系统，选择一款分布式数据库系统，集中公司的技术力量和资金，完成代码改造，实现迁移。他问我他们的方案是否可行，我有什么优化建议。我觉得他们考略的已经比较全面了，只要下定决心去干，完成就是个时间问题了。以前有个朋友说过，数据库国产化的问题，往往是在做方案的时候看到的都是困难，而真正做起来的时候，那就只剩下钱是个问题了，真正想起来也确实很对。

实际上今天我聊的这个问题，不仅仅是对想做数据库国产化迁移的人说的，也是对我们的国产化数据库厂商说的。用户的需求就是我们改善产品的方向。如果我们的数据库产品和Oracle具有不修改一行代码就可以迁移的兼容性；表、字段、数据也也可以有完整的兼容对应序列，迁移工具能够对不管多大数据量的系统实现便捷的一键迁移；字符集、TIMEZONE、高可用、读写分离等细节也都能考虑的十分完善。那么，客户在选择国产化替代产品的时候，你的机会是不是会大一些呢？