国产数据库适合国家标准吗?

数据库 其他数据库
无论如何,这些标准都只是接口上的标准。不同的数据库产品的核心差异极大。哪怕我们用SQL访问起来,SQL代码都是兼容的,但是访问数据库的执行计划差异会很大,相同的执行计划算子,其性能与能力也会有差异,因此接口上的兼容性不等于能力的完全替代。

​前阵子有个企业的IT负责人和我讨论,对于信创数据库,制定一些国家标准,会不会对国产数据库产业有帮助。当时我的第一反应是,国产数据库咋做标准化,不同的数据库产品技术路线不同,架构不同,技术水平不同,实现方式不同,我们没办法也没必要去做个国标来做一些限制吧。说实在的,标准是个双刃剑,搞好了,能够促进国产数据库产业,搞得不好,就变成党同伐异的工具了。

前些年一些行业制订了数据库的一系列的数据库标准,实际上这些标准更像是招标文件中的技术规范书,很难对数据库产业发展有什么作用。另外一个典型的案例就是等保安全标准,前些年Oracle参加过一次等保2级测试,居然惨败,也就很说明问题了,了解Oracle安全的朋友绝对相信Oracle数据库绝对不会比当时的国产数据库在安全方面差,但是当时的不少国产数据库是可以轻松过等保三级的。

不过仔细想一想,我倒是觉得国产数据库标准也不见得是一件坏事情,如果做好了,还真的能促进国产数据库产业的发展。国外商用数据库发展过程中也是先万花齐放,不同的架构、不同的技术路线、不同的编程接口。发展到一定阶段才发现,如果不遵循某些标准,野蛮生长,数据库市场就很难快速增长。于是大家才开始互相“学习”,采用一些事实标准,最终其能力也开始趋同了。SQL语言、B树索引、MVCC,事务隔离级别、存储过程、触发器,等等等等,正是这些技术被商用数据库厂商广泛使用后,才让关系型数据库市场变得繁荣起来。国产数据库的起步比较晚,因此不但上述这些都成了标配,并且大家都有意无意的向几个数据库产品靠拢。一个是Oracle,另外就是MySQL、Postgresql两大开源数据库。

2014年的时候,我们的优化项目开始接触达梦、金仓等国产数据库。刚刚接手一个全新的数据库的时候,我们完全时懵的。不过看到DBA_TABLES,v$sysstat、v$sessions等熟悉的视图的时候,心里就踏实了很多。虽然达梦数据库与Oracle的内核不同,sysstat和会话信息所反映的系统状况也没Oracle那么清晰,不过这种兼容性也让我们在做这个优化项目时受益良多。后来这个项目的完成比原来预想的顺利很多,效果也超出了我们开始时的预期。

数据库的核心技术实无法做标准化的,做起来也无益,差异化竞争才能让优秀的数据库产品更好的成长起来。不过在某些方面还是可以建立一些国标的。比如可观测性接口、数据字典表、云平台纳管接口等外围接口方面,如果能形成标准化,那么对于国产数据库市场还是有所助益的。

我们是做运维工具的,对可观测性接口的问题深有感触。每纳管一个数据库产品,我们都需要从头开发,从指标体系构建,到指标采集,再到诊断工具,都要重新写一套。实际上,不管数据库产品核心的差异有多大,很多指标实际上都是标准的,负载、性能、并发、集群等方面都有很多指标都是普适性的,系统状态、系统指标、等待事件等接口能力都是可以提供的。在我们这些年的工具开发中发现,PG兼容的数据库产品的监控开发工作量相对较小,虽然很多数据库在底层都做了很多优化,也增加了一些可观测性的接口,不过因为其核心部分的指标体系,监控视图方面存在较多兼容的地方,因此纳管新的PG类的国产数据库的开发成本远低于一个全新的数据库产品。

如果能够形成一套国家标准,那么今后不仅对于数据库监控产品的厂商,对于DBA来说也是一个福音。比如日志文件的存储位置,日志文件的文件名格式,日志条目的格式,这些按照一个标准化的格式去输出,对于数据库内核来说影响不大,完全是可以标准化的。甚至日志输出的内容,我们也可以做一些标准化,比如错误类日志,可以学习Oracle那样,把应用中几层堆栈的报错按照顺序一起输出,而不仅仅输出最后报错点多而错误信息,这十分有助于故障诊断。

数据字典接口标准化也会给DBA与生态工具合作伙伴带来极大的便利。Tablename/table_name/tname这些字段都能表示表的名字,为什么就不能使用统一的名称呢?既然大家习惯使用dba_tables了,大家就都用这个耳熟能详的视图名称好了。国产数据库都采用标准的数据字典接口,也可以降低国产数据库的学习成本,让应用软件在不同的国产数据库之间做迁移时成本得到极大的降低。

编程接口的标准化工作实际上有一部分已经让JDBC/ODBC等事实上的标准做了。不过在一些常用的细节上,不同的数据库产品依然十分有个性。序列号的使用,Oracle用seq.nextval,有不少国产数据库做了这方面的兼容,但是并不是所有的数据库产品都这么使用。存储过程就更是百花齐放了,MYSQL系的PG系的,仿Oracle PL/SQL的三大系列三足鼎立。我们是不是也可以出一个国家级的存储过程语法标准呢?我们完全可以学习Oracle,用类ADA语法做一个标准,这个标准基本上兼容了Oracle的PL/SQL,也具有一定的独立性。

关于数据库云纳管标准实际上来自于最近遇到的一个案例。某企业测试国产数据库产品,必须在云平台上测试。这就遇到了不公平的问题,因为云平台厂家自己的数据库产品可以以RDS的形式提供,而第三方的国产数据库产品就只能部署到云主机里了。RDS部署不仅部署起来比第三方数据库方便,更重要的是RDS都是跑在裸金属服务器上的,而云主机的云盘性能垃圾的很。这样测试下来,公正性就大打折扣了。于是云厂商和数据库厂商之间就打起嘴炮来了。数据库厂商说云厂商排外,不肯把他们的数据库纳入RDS范畴,云厂商说国产数据库产品这么多,标准不统一,我们把他们做成RDS成本太高。如果大家各退一步,云厂商做一个数据库RDS纳管接口标准规范,数据库厂商各自实现接口规范,这个问题不就解决了。当然技术上不难,这个案例中实际上还是一个商务问题。

无论如何,这些标准都只是接口上的标准。不同的数据库产品的核心差异极大。哪怕我们用SQL访问起来,SQL代码都是兼容的,但是访问数据库的执行计划差异会很大,相同的执行计划算子,其性能与能力也会有差异,因此接口上的兼容性不等于能力的完全替代。以前我们做过的数据库迁移项目中,从Oracle迁移到某国产数据库上,SQL执行时间变长数倍甚至十数倍是十分常见的。不过这些问题最终都通过优化去解决掉了。我们的很多应用系统的数据库设计做的都很差,索引建的很乱,在Oracle CBO下,这一切都还不是问题,但是迁移到国产数据库上,就问题多多了。这些内功的问题,需要我们的国产数据库厂商逐步去解决,而一些接口的标准化上,实际上目前是应该做些工作了。

这些标准不需要设置为行业强制标准,而是给一些愿意让使用者用的更习惯的数据库厂商有一个参考标准。如果有一些厂家愿意参与进来,形成的小集团确实方便了用户,那么会有更多的用户会参与进来,厂家实际上也会受益。这样就能够让更多的数据库厂商也参与进来。这种靠市场发展的标准,比那些被用于招标的标准,有价值的多。​

责任编辑:武晓燕 来源: 白鳝的洞穴
相关推荐

2013-04-15 10:33:04

光纤网络宽带网络网络建设

2020-11-09 11:41:08

区块链

2012-11-08 14:49:14

线缆

2019-10-16 11:54:24

东软车联网车载信息安全

2020-11-09 11:23:37

云计算

2020-11-09 10:38:57

物联网

2014-07-30 16:15:38

华为

2015-04-03 17:38:41

曙光云计算

2011-11-04 14:07:40

存储

2020-05-07 21:35:59

网络安全安全标准标准

2011-03-11 09:26:13

2011-03-11 09:14:18

国产数据库

2012-04-23 09:26:09

移动支付NFC

2019-10-29 14:22:44

阿里云云计算认证测试

2011-03-11 12:51:48

国产数据库安全

2022-10-21 07:07:33

TiDBHTAP数据库
点赞
收藏

51CTO技术栈公众号