当前位置: 首页 > 科技观察

国产数据库和开源代码

时间:2023-03-16 18:14:15 科技观察

很多朋友认为国产数据库应该是完全自主研发的数据库产品,不应该基于开源代码开发。但是我换个问题,一个完全国产的,只有三五年历史的数据库产品,一个非常成熟的开源数据库产品,他可以选择,他必须选一个,他就会选择开源具有高概率数据库。这是一个很现实的问题。数据库是非常重要的IT基础设施,其成熟度和稳定性非常关键。在国内数据库自研比例较高的数据库厂商中,大梦是非常典型的一家,其数据库产品已有20多年的历史。从大梦6开始,在国家电网电力调度等核心系统中得到应用,也得到锤炼。从客户胆战心惊使用到获得客户信任,至少经历了五年的磨合。从DM7开始,代码进行了全面重构,代码自治率达到了很高的水平。目前的主流版本已经是DM8,其稳定性已经过大量客户的考验。国内像大梦这样有20多年历史的数据库产品并不多见。不过,虽然国内很多数据库产品的历史不是很长,但都是在比较成熟的开源项目的基础上发展起来的。作为DBA或者用户,我们也信任这些产品,因为这些开源数据库产品在社区中被数以百万计的用户所使用。而如果有人告诉我,他们的数据库产品是一行行代码开发的,没有使用任何开源代码,而且这个产品的历史只有三五年,那么恕我直言,我宁愿你基于开源开发它代码。时间码在2035年出品的一款数据库产品,还没有经过数万用户的验证,不敢完全相信。一个通用的关系数据库产品从几百万行代码开始。哪怕只有200万行代码,也至少是300-400人年的全流程开发工作量。就算你整个研发团队有100人,完成公测并交付给客户试用也需要3-4年的时间。而这些产品必须能够在企业的核心业务场景中使用,这样才有可能从不成熟走向相对成熟。但是,在目前国内数据库产品如此内向的市场环境下,很难找到大梦、派电这样的培训机会。国内的数据库产品真的不用自己一行一行的写代码,这样会导致重复造轮子,浪费有限的研发成本和时间。事实上,即使是Oracle数据库,也使用了很多开源代码,使用开源代码没什么大不了的。其实我是非常赞成在遵守开源协议的基础上合理使用开源代码开发国产数据库产品的。俄乌战争后,甲骨文、IBM等都中断了在俄罗斯的业务,俄罗斯本土公司PostgresqlPro成为甲骨文的重要替代者。这家Postgresql开源社区下游的数据库厂商,以PG开源代码为核心,整合自己的原始代码,发布自己的企业版PG。美国的技术围堵并没有影响到PostgresqlPro的数据库业务,这也证明了PG开源社区的安全性。使用开源代码并不像一些领导者认为的那样不安全。事实上,在通用关系型数据库领域,亚马逊近年来做出了比较大的技术贡献,而Aurora是近年来数据库领域最具影响力的创新技术。谷歌在2022年推出的AlloyDB也是对Aurora的致敬。Aurora和AlloyDB都是完全基于开源数据库的技术创新。他们数据库的核心代码都是开源代码。随着开源社区的发展,Aurora和AlloyDB都可以升级自己的数据库核心代码。就我个人而言,AmazonAurora在数据库技术上的创新和贡献远高于国内任何一家号称代码自治率超过90%的数据库厂商。使用开源代码并不可耻,反而是国内数据库行业快速发展的有效模式。但是,数据库产品一定要有自己的独创性和创新性。这也是PostgresqlPro受人尊敬的原因。在PG社区还没有解决XID64的时候,他们的企业版数据库产品就已经支持XID64了。日本的独立数据库产业也是基于开源数据库项目。日本的PG数据库应用规模非常大,也有大量的原创技术。著名的PGXC/PGXL两个开源项目就是从NTT项目中孵化出来的,这两个开源项目也被国内大量的数据库厂商所采用。令人欣喜的是,基于开源项目的国产数据库创新也开始了。openGauss的起点是PG9.2.4内核,但对整个代码进行了重构,在开发语言上使用C++代替C语言。为了更好的适配NUMA架构,openGauss采用了单进程多线程架构,而不是传统的PG多进程架构。openGauss的核心代码已经完全脱离了PG社区,但是从openGauss3.x的性能来看,基本赶上了开源社区的最新版本,甚至超过了最新的稳定版PG社区在某些方面。openGauss目前的SQL引擎核心虽然仍然大量使用PG社区版的代码,但是融入了大量的创新技术。特别是,openGauss在用USTOR替换ASTOR方面取得了快速进展。我觉得openGauss在4.0中会给我们更多的惊喜。目前,国内已有大量数据库厂商加入openGauss开源生态。在国内广大用户群体的培养下,openGauss的未来一片光明。Henkel旗下的ivorySQL则走的是另一条路。其核心代码完全兼容PG,可随PG版本升级。ivorySQL的创新点在于与Oracle的兼容。我觉得完全兼容最新的PG内核,高度兼容Oracle。这个特性肯定能满足一些中小用户准备把数据库从Oracle迁移到开源或者国产数据库的需求。虽然这种创新在技术上并不高,但它是。也很有价值。我非常认同国产数据库产品使用成熟的开源代码,但我们不应该只是做开源社区的吸血鬼,更应该为开源数据库做出中国人的贡献。前段时间写了一篇关于取消PG数据库中的DOUBLEBUFFERING并引入AIO的文章。其实对于开源数据库中的一些老生常谈的问题,我们使用开源数据库代码的数据库厂商完全可以组织研究。将结果提交到开源社区或者在自己的企业版中使用都没有问题。一旦创新进入深水区,解决核心问题并非不可能。事实上,目前国内的数据库在发展自己的开源社区方面也非常成功。PINGCAP的TiDB和蚂蚁的Oceanbase已经发展成为具有一定国际影响力的开源数据库产品。阿里的Polardb-PG从架构上充分借鉴了Aurora的日志作为数据库的思想,充分利用开源数据库PG的核心能力,打造了独立的数据库产品,能够支撑核心关键业务,并保持代码开源。依托这些中国企业主导的开源数据库产品,一定会涌现一批基于这些开源项目的国产商用数据库产品。对于我国的数据库行业来说,商业数据库产品是不是基于开源数据库代码构建的并不重要,也无关紧要是基于哪个开源社区代码,PG还是MYSQL。只要企业能够满足开源社区的版权要求,对商业数据库产品进行封装是合理的。我们行业管理部门不应该用是否开源代码来衡量是否符合信创的要求。只要代码本身是安全的,符合我国的安全要求,比如支持SM3国密等,就可以了。我们的行业监管者应该重点评估数据库产品本身的能力。评价结果可以为数据库用户提供更好的参考,这样的评价更有价值。比如我们可以基于国内某企业广泛使用的ERP产品、财务软件、MES系统、OA系统等适配我们国产的数据库,形成适配兼容性报告和核心模块性能报告。这些评估报告对企业来说可能比代码自治率评估报告更有价值。