再聊聊数据库国产化替代

作者：白鳝

原文链接：再聊聊数据库国产化替代 (qq.com)

本文主要探讨数据库国产化数据库中的策略，选型等方面的问题。今天的文章比较长，有5000多字，建议大家先收藏再慢慢阅读。

从2019年华为事件发生开始，就不断有企业和我讨论数据库国产化替代的事情。我也参与了一些数据库国产化方案的编写工作。不过这些年来，我看到的数据库国产化替代似乎有点雷声大雨点小。大家都挺关注，领导也够重视，方案做了一遍又一遍，但是动作实际上并不大。这和前些年的去IOE浪潮形成了鲜明的对比，那一次大家也是从疑惑到开始试探，到大规模应用，不过类似的犹豫期短了很多，一旦小规模试探结束，大规模应用随之而来。这回的数据库国产化工作似乎推进的没有这么快。细想起来，这也很正常。

去IOE给企业带来的是十分明显的省钱效益，用相对已经十分稳定的,价格十分便宜的，市场上采购周期极短的X86替代昂贵，采购周期很长的小型机，以及用免费的开源数据库替代Oracle，可以大大降低企业IT的成本。而数据库国产化替代就没那么简单了，这项工作虽然说涉及到信息化的根本安全，但是当某种特殊的威胁没有立即发生到自己头上的时候，总是觉得数据库国产化替代的效费比不太划算，所以领导总说这是大事，但是到了行动上就只是蜻蜓点水，也就是很正常的事情了。

不过形势比人强，随着国际形势的变化，信息系统国产化替代的势头来的越来越猛。目前还按兵不动的企业受到的压力也越来越大。很多企业把目标定为在2027年底前实现应替尽替，因此最晚从明年开始也要开始大规模的替换工作了。数据库国产化替代的方案，也不能总是处于论证阶段，而是真的要开始着手实施了。

实际上，如果真的去做这件事，方案选型也并不是很难的事情，也并非必须经过严格的考虑才不会出错的，有时候你考虑了良久，反而最后的选择不见得最好。而我的观点是，可能会选错数据库但是你的数据库国产化道路不会走错，你会在不断的纠偏过程中不断的完善方案。

当年Oracle数据库一统江湖，替掉90年代五花八门的数据库产品，绝大多数企业也并不是做了很详细的规划，才一点点实施起来的。而且那时候Oracle数据库也没有那么好的口碑，在人们的眼中也并不是怎么选都不会错的产品。很多企业是不情愿的用了Oracle，发现Oracle很不错，以后信息系统上线就全部使用Oracle了。最后，企业里其他数据库产品也逐渐在系统升级时换成Oracle了。

我有一个客户，20年开始准备数据库国产化替代的事情。首先选了一款国产分布式数据库，迁移了一套小系统。迁移过程中发现研发投入，上线运维方面，都存在不小的问题。21年根据上级单位要求，对OA系统进行国产化迁移，选择了一套OA系统支持的集中式数据库，发现整个迁移工作顺利了很多，迁移费用也比第一个项目更低。于是他们决定试着在几个新的项目里使用这个集中式数据库产品，进一步积累经验。我想对于大多数企业来说，这种小步快跑，不断修正的方式是成本最低，比较容易成功的。等到积累了足够的迁移经验的时候，再进行大规模迁移工作，那应该不会太难。

有些企业的IT规模较大，特别怕试错，因此他们总是希望谋而后动，先把方案做扎实了，然后再全面推进。不过我总觉得做此类方案的靠谱指数往往偏低，“专家”提出来的方案也不见得是正确的、适合企业现状的。就像见过猪跑，也很难想象得出红烧肉是啥味道一样，只做方案，不去尝试，是不够的。

可能有些朋友觉得对数据库国产化替代这样一个技术问题，不谈技术，仅仅谈决心，是不是有点太唯心了。数据库替代这个难题，难道光靠下决心就可以实现的吗？事实上，如果说数据库国产化工作的成败，放在第一位的还就不是技术问题，而是决心。只要下了决心，就一定能干成。当然光有决心还是不够的，技术问题也是需要充分考虑的。今天我们的下半部分，就来讨论一下技术方面的问题，其中的核心还是数据库选型的问题。

现在国产、开源数据库数量巨大，种类繁多，如何选择确实令人头疼。很多朋友都很关心数据库选型的技术问题，不过我觉得数据库选型，技术问题还可以往后放一放。因为数据库对应用系统研发的影响很大，因此数据库最忌讳的是经常更换。一旦完成选型，最好是能够五到十年内不要更换。因此在数据库选型的时候，要么选择相对活跃的开源社区，要么选择规模较大的大厂产品。对于IT规模较大的企业，一些很有特色的小厂产品，虽然可能在某些方面很有吸引力，不过也要慎重对待。在这一点上，大规模使用的关系型数据库选型一定要考虑长远，而对于一些特色功能的，使用范围较小的数据库，则可以选择一些中小企业的产品。

数据库选型，在商业路线上有开源、商用两个大的路线可选。开源和商用数据库产品的选择，一直争论不休。开源数据库的诱惑是任何一个企业都无法拒绝的，许可证免费，社区的支持力量，大量的用户积累下来的应用运维经验，这些对于数据库替代来说都是十分稀缺的资源。因为开源数据库的代码是开放的，从开源代码中，最终可以找到解决某些疑难问题的方法，因此相对于代码封闭的商用数据库而言，开源数据库更容易形成良好的第三方服务生态。不过开源数据库算不算国产数据库，算不算信创数据库的问题，也困扰了很多企业。另外开源数据库无法获得原厂的支持，也就缺少了一个兜底的支撑单位，这也让很多企业面临选择困境。

商用数据库则正好相反，许可证是要收费的，而且目前国产商用数据库的许可证是需要花钱购买的，而且也不像Oracle一样可以打打擦边球。国产商用数据库的用户群体目前也还不够大，第三方服务能力也十分薄弱，远远比不上一些著名的开源数据库产品。不过商用数据库后面有一个“原厂”存在，可以帮你兜底。只不过这个“原厂”的兜底能力因原厂的规模与实力不同，有较大的差别。

有些人觉得数据库国产化替代绝对不能用开源数据库简单的替代了，这一点我不是太认同。开源数据库已经被很多规模不同而企业证明了，是Oracle等数据库的很好的替代者之一。因为开源社区的特点，大部分开源协议保证了这些数据库并不会因为美国的进出口管制措施而影响你的使用。在应用最为广泛的开源数据库-MySQL和Postgresql数据库方面，很多企业已经获得了巨大的收益。

如果企业的研发能力较强，应用系统都已经微服务化了，那么可以把数据库拆分的比较细小，使用MySQL是十分好的选择。MySQL的运维十分简单，业务逻辑都在应用里做了充分优化后，只要在MySQL的高可用架构上做好设计，那么平时的运维是很简单的，偶然发生某个库出问题了，只要重启数据库实例或者切换备库就可以解决问题了。

如果企业的应用相对复杂，SQL经常会出现数张大表的关联查询，而研发部门的优化能力也有限，那么Postgresql可能是你比较好的选择。PG的优化器能力十分强大，可以解决大多数复杂查询的性能问题。而PG的插件结构也可以让你通过一些特殊的方式，甚至为某个特殊应用场景开发特殊的索引来解决一些开源版本无法解决的问题。
目前已经有不少国产数据库也走上了开源的道路，这些数据库也是国产化替代中的不错的选项。与美国主导的社区的开源数据库产品相比，我国企业主导的开源数据库产品在极端情况下会更安全。目前PingCap的TiDB、蚂蚁的Oceanbase、华为的openGauss、阿里的PolarDB都已经形成了一定规模的开源生态。

除此之外，实际上现在有很多国产数据库产品也都是基于开源项目的。比如人大金仓KingBaseES、瀚高HighoDB、优璇数据库等都是基于Postgresql开源项目的。

openGauss这个开源项目的源头也是Postgresql 9.2，海量G100、MogDB、神州通用数据库等则都是基于openGauss开源项目的闭源商用数据库。不少朋友和我讨论过这些基于开源项目的闭源商用国产数据库产品，认为这种套壳国产化产品不能算是真正的国产数据库。对于这个问题，可能大家的观点很难一致。我还是比较赞成基于开源项目构建商用产品的，因为这样可以大大减少研发的开销，另外也可以利用壮大开源社区，充分整合开源社区的资源。只要产品对于开源协议是遵循的，不违反开源协议的前提下做闭源，是没有问题的。当然，如果能够像openGauss等国产开源项目一样，一方面脱离国外开源社区，另外一方面发布开源版本，那就更好了。如果一个数据库既有商用版本，又有开源版本，那么既可以解决企业大规模使用的成本问题，又可以为企业的核心应用托底，这解决了很多大型企业数据库替代的一个大问题了。

除了商业路线以外，还有一个十分重要的选项是集中式数据库与分布式数据库。集中式数据库使用、运维起来很简单，不过可扩展性、高可用方不如分布式数据库。分布式数据库高可扩展，容错能力强，但是结构复杂，运维复杂，出了问题也不好定位。这二者优缺点都十分明显，确实不好选择。实际上还存在第三种路线，就是亚马逊发明的Aurora，这种日志就是数据库理念的产品可以实现強一致性的读写分离，因此很多情况下被算成是非对称架构的分布式数据库，而实际上这是一种介于集中式数据库与分布式数据库之间的架构（实际上Oracle RAC也可以近似归类于这种类型），今天我们把它看做第三种技术路线。

集中式与分布式数据库的选择依然取决于企业的应用场景、应用目标与企业IT的能力积累。集中式数据库相对简单，对于应用开发与运维来说，只要做好高可用架构、主备库等，可用性也是有保障的。最严重情况下，确保30分钟内恢复应用也是有保障的。

不过依然存在一些应用场景需要更高的可靠性，比如股票交易、实时系统等，这种系统在企业中虽然数量不是很大，但是往往又是最为核心的。如果需要分钟级恢复应用，那么分布式数据库在架构上更具优势。而对于互联网交易、物联网应用等业务逻辑相对简单，高并发数据写入，大批量数据输出等场景，分布式数据库也因为其极高的可扩展性而更为适合。

我想在一个企业中，很可能是集中式数据库用于广泛的，中小型的或者规模相对稳定的系统使用相对简单的集中式数据库，而可用性要求极高、超高并发的少量系统使用分布式数据库很可能是一种十分常见的形态。

第三类数据库目前在国产数据库中还比较少，最为典型的是阿里的PolarDB-PG、PolarDB-O，这是基于Postgresql开源项目的非对称分布式架构数据库产品。通过底层多副本实现IO能力的扩展，通过读写分离集群实现有限的横向扩展。实际上目前的绝大多数国产集中时间数据库产品都可以研发类似的衍生产品。我了解到很多国产集中式数据库厂商都在开发类似Oracle RAC的产品，而达梦的类似RAC功能的数据库产品已经开始商用了。不过我依然觉得类似PolarDB的非对称读写分离架构对于绝大多数企业来说已经够用了。

既可以通过读写分离分离开销最大的读负载，又可以实现亚分钟级别的高可用故障切换，完全能够满足高可用性要求的核心系统的需求了。一个集中式数据库产品如果能够具有此种能力，并且在前端通过代理实现读负载的自动卸载，那么对于80%以上是读负载的绝大多数管理信息系统来说，就完全解决了单机无法扩展的问题。集中式数据库厂商可以凭借此能力与分布式数据库争夺核心业务的市场。

分布式数据库厂商也可以把手伸进集中式数据库厂商的碗里，今年OceanBase 4.0的
发布会上给了数据库产业界一个新的启示，分布式数据库还可以有新的玩法。OB 4.0发布了一个单机数据库模式，对于一些企业，数据与业务规模还没有到必须上分布式数据库的地步，你可以先上一个单机版的OB，等以后有需求的时候，可以很方便的扩展为分布式数据库。这样企业的大小数据库都可以使用相同的数据库产品，根据需要选择集中式还是分布式。OB 4.0发布的时候，有个数据库厂商的朋友看到这个消息后和我说：“这下子不好玩了，如果OB单机模式确实如宣传所讲，能达到这样的性能，那么这算是降维打击了”。能不能降维打击还不好说，因为要想把一个分布式数据库架构的数据库产品改造为一个单机集中式数据库，而且性能能够与普通的集中式数据库相媲美，并不是一件容易事。真实的情况如何，还需要实际应用来证明。

数据库选型是一个十分复杂的过程，很难通过一些规则进行量化，通过量化打分来完成数据库选型看似很科学，实际上并不一定能够做出很好的选择来。数据库选型应该是从企业的特点出发的，不仅仅要看数据库本身的技术先进性，企业自身的技术特点，技术能力以及企业在数据库、研发等方面的投资配比等都会影响数据库选型的最终结果。今天时间有限，我就不再展开讨论了，如果大家有兴趣，我今后专门来讨论这方面的问题。

最后聊聊数据库的对比测试与评价问题，这个也是困扰企业数据库选型的一个问题。任何的测试都无法做到完全公正，因此通过测试实现选型的公正并不一定能够做到，也并不一定必须。我们要做到的是，被选中的数据库真的能够满足我们的日常应用需求。从我的经验上看，BENCHMARK测试，TPCC之类的对于绝大多数企业的数据库选型来说没有太大的意义。仅仅从简单的TPCC来说，20万TPMC基本上可以满足绝大多数企业的并发交易需求了，但是BENCHMARK这种简单的测试，无法测出企业对复杂SQL的支撑能力的好坏，因此意义不大。对于企业数据库替代测试中比较重要的测试项目包含数据库兼容性测试、复杂SQL支持能力与性能测试、高可用测试等。

数据库兼容性测试主要是和Oracle比，大部分企业将从Oracle大量迁移系统到国产数据库上。兼容性意味着迁移成本的高低。如果应用能够修改少量的代码，甚至不修改一行代码就能够实现迁移，那么对于有数百套甚至上千套系统需要迁移的企业来说，可以节约大量的成本。在这方面，达梦是真正的王者，以我们这些年做过的迁移来看，达梦数据库与Oracle的语法兼容性是最好的。在这方面国产商用数据库普遍要好于开源数据库，海量G100、人大金仓、OCEANBSE（Oracle兼容租户模式）等在与Oracle的SQL、PL/SQL兼容性方面都做的不错。

复杂SQL的测试最好选择一些比较复杂的系统进行，比如ERP系统、SCM供应链管理系统等，这些系统的业务逻辑十分复杂，大量的多张大表关联，大数据量输出的场景比较多，因此可以检验一个数据库产品对于复杂SQL的处理能力与运行性能。如果某个数据库能够比较好的支撑这些应用，那么其SQL能力就完全能够满足你其他系统的需求了。有些朋友会说，如果用数据仓库的应用来测试不是更能体现复杂SQL的能力吗？实际上过犹不及，OLAP不仅仅是SQL的问题，还有宽表优化、列存储、索引优化等方面的需求，与OLTP系统中的复杂SQL是不同的。

数据库国产化替代涉及的问题太多，我也无法通过一个五六千字的文章一网打尽。今天就聊这么多吧，早上六点多就开始写这篇文字，边想边写，可能比较乱，某些地方也可能会有些疏漏，而且仅仅是一家观点，未必正确，也未必与您的需求相一致，有不同的观点，希望多交流。今后我会找个时间，认真梳理下这篇文章，找时间再发一个更好的版本把。希望今天的文字能够对正在做这项工作，或者正在思考这个问题的朋友有所帮助。