前阵子有个企业的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下，这一切都还不是问题，但是迁移到国产数据库上，就问题多多了。这些内功的问题，需要我们的国产数据库厂商逐步去解决，而一些接口的标准化上，实际上目前是应该做些工作了。
这些标准不需要设置为行业强制标准，而是给一些愿意让使用者用的更习惯的数据库厂商有一个参考标准。如果有一些厂家愿意参与进来，形成的小集团确实方便了用户，那么会有更多的用户会参与进来，厂家实际上也会受益。这样就能够让更多的数据库厂商也参与进来。这种靠市场发展的标准，比那些被用于招标的标准，有价值的多。
