国产数据库与开源代码

发布时间：2025-11-04 14:22:33 来源：创站工坊 作者：人工智能

​很多朋友觉得国产数据库应该是国产完全自研的数据库产品，不应该基于开源代码去做开发。数据不过如果我换一个问题，库开一个只有三五年历史的源代完全国产自研的数据库产品与一个十分成熟的开源数据库产品供他选择，并且必须选择其中之一，国产那么大概率情况下他会去选择开源数据库。数据这是库开一个十分现实的问题，数据库是源代十分重要的IT基础设施，其成熟度与稳定性是国产十分关键的。

在自研比例较高的数据国产数据库厂商中，达梦是库开十分典型的一家，其数据库产品已经有是源代超过20年历史了。从达梦6开始在国家电网电力调度等核心系统中获得了应用，国产也经受了磨练。数据从客户用得战战兢兢到获得了客户的库开信任，这是花了至少五年时间的磨合的免费信息发布网。从DM7开始，代码进行了全面的重构，代码自主率已经达到了较高的程度，目前的主流版本已经是DM8了，其稳定性已经经过了大量客户的实际应用考验。

国内像达梦一样具有超过20年历史的数据库产品并不多，不过很多国产数据库产品历史虽然不是很长，但是都是基于相对比较成熟的开源项目的基础上研发的。作为DBA或者用户来说，我们对这些产品也是比较信任的，因为这些开源数据库产品有社区里上百万的用户在使用。

而如果有人告诉我，他们的数据库产品是一行行代码自己开发出来的，没有采用任何开源代码，免费源码下载而这个产品的历史不过三五年，那么恕我直言，我宁愿你是基于开源代码开发的。三五年时间码出的一个数据库产品，没有经过数万个用户去验证过的，我是不敢完全信任它的。一个通用关系型数据库产品是几百万行代码起步的，哪怕只有两百万行代码，那也是至少300-400个人年的全流程开发工作量。哪怕你的整个研发队伍有100人，也需要3-4年的时间才能完成beta测试，交付给客户试用。而这些产品必须能够在企业核心业务场景中获得使用的机会，才有可能从不够成熟变得相对成熟。但是在目前的国产数据库产品如此内卷的市场环境中，是云服务器很难找到当年达梦与电力调度这样的磨练机会的。

国产数据库产品真的不是必须是一行行代码都是自己写的，这样会导致重复的去创造轮子，浪费有限的而研发费用与时间。实际上哪怕Oracle数据库里也大量使用了开源代码，用开源代码没有什么大不了的事情。我实际上是十分赞成在符合开源协议的基础上，合理的使用开源代码来开发国产数据库产品的。

俄乌战争后，Oracle，IBM等都中断了俄罗斯的业务，俄罗斯本土企业PostgresqlPro成为了Oracle的重要替代品。这家Postgresql开源社区下游的数据库厂商，其核心完全使用PG开源代码，整合进自己的原创代码，发布了自主的企业版PG版本。美国的技术遏制并没有对PostgresqlPro的数据库业务造成影响，也证明了PG开源社区的安全性。使用开源代码并不像某些领导想象的那样，会不够安全。

实际上，在通用关系型数据库领域，最近几年在技术上贡献比较大的是亚马逊，Aurora是近些年来数据库领域最具影响力的创新技术。2022年谷歌推出的AlloyDB也是对Aurora的一种致敬。不管是Aurora还是AlloyDB都是完全基于开源数据库基础上的技术创新，其数据库的最为核心的代码都是开源代码，随着开源社区的发展，Aurora和AlloyDB都可以升级其数据库核心代码。从我个人的观点来看，亚马逊Aurora在数据库技术上的创新和贡献远远高于号称代码自主率超过90%的任何一家国产数据库厂商。

使用开源代码并不丢人，而是一种快速发展国产数据库产业的有效模式。但是在数据库产品中一定要有自己的原创，有自己的创新。PostgresqlPro让人尊敬的原因也是如此，在PG社区还没有解决XID64的时候，他们的企业版数据库产品已经支持XID64了。日本的自主数据库产业也是基于开源数据库项目的，日本的PG数据库应用规模十分庞大，并且也有大量的原创技术。从NTT的项目中孵化出了著名的PGXC/PGXL两个开源项目，这两个开源项目目前也被大量的国产数据库厂商所使用。

令人欣慰的是国产数据库基于开源项目的创新也已经起步。openGauss的起点是PG 9.2.4核心，不过整个代码已经进行了重构，在开发语言上用C++替代了C语言，为了更好的适应NUMA架构，openGauss采用了单进程多线程架构替代了传统PG的多进程架构。openGauss的核心代码已经完全脱离PG社区，不过从openGauss 3.x的性能上来看，基本上是追上开源社区的最新版本了，在某些方面甚至还实现了对PG社区最新稳定版本的超越。虽然openGauss目前的SQL引擎的核心还在大量使用PG社区版的代码，但是已经融入了大量的创新技术。特别是openGauss在USTOR替换ASTOR的方面进展十分迅速，我想4.0时openGauss会给我们更多的惊喜。目前已经有大量的国产数据库厂商加入了openGauss开源生态，在中国广大的用户群体的磨练下，openGauss的前途十分光明。

瀚高旗下的ivorySQL走的是另外一条路线，其核心代码完全兼容PG，并且能够随着PG版本升级，而ivorySQL的创新点集中在与Oracle的兼容性方面。我想完全兼容最新的PG核心和与Oracle高度兼容这个特性必然会满足一部分准备把数据库从Oracle迁移到开源或者国产数据库的中小型用户的需求，这个创新点虽然在技术上并不高大上，但是也十分有价值。

我十分赞同国产数据库产品使用成熟的开源代码，但是我们不能只做开源社区的吸血鬼，而应该为开源数据库做出中国贡献。前阵子我写过一篇关于在PG数据库中消除DOUBLE BUFFERING，引入AIO的文章，实际上对于一些开源数据库中的老大难问题，我们的使用开源数据库代码的数据库厂商完全是可以组织攻关的，把成果提交给开源社区或者在自己的企业版中自用都是没有问题的。一旦创新进入深水区，那么解决核心问题也并不是不可能的事情。

实际上目前国产数据库在自己的开源社区发展方面也十分成功，PINGCAP的TiDB，蚂蚁的Oceanbase都已经发展成为有一定国际影响力的开源数据库产品。阿里的Polardb-PG从架构上充分学习了Aurora的日志即数据库的思想，充分利用开源数据库PG的核心能力，打造出能够支撑核心关键业务的自主数据库产品，并把代码保持开源。依托这些我国企业主导的开源数据库产品，也必将能够涌现出一批以这些开源项目为基础的国产商用数据库产品。

对于我国的数据库产业而言，是否基于开源数据库代码构建商用数据库产品并不重要，基于哪种开源社区代码，PG还是MYSQL也不重要。只要企业能够符合开源社区的版权要求，那么封装商用数据库产品都是合理的。我们的行业管理部门也不应该以是否使用了开源代码来衡量是否符合信创的要求。只要代码本身是安全的，并且符合我国的等保要求，比如支持SM3国密等，就可以了。

我们的行业监管部门应该把评测重点放在数据库产品本身的能力上，其评测结果能够给数据库用户提供更好的参考性，这样的评测也才更有价值。比如我们可以基于某个国内企业使用较广的ERP产品，财务软件，MES系统，OA系统等，与我们的国产数据库进行适配，形成适配兼容性报告与核心模块性能报告。这些评测报告可能对于企业来说，比代码自主率评测报告有价值的多。​

相关文章