前段时间，某企业的IT负责人和我讨论，制定一些新创数据库的国家标准，对国内的数据库行业有没有帮助。当时我的第一反应是国内的数据库要标准化。不同的数据库产品有不同的技术路线、不同的架构、不同的技术层次、不同的实现方式。我们没有办法也没有必要制定国家标准来设置一些限制。说实话，标准是一把双刃剑。如果做得好，可以带动国内的数据库行业。几年前，一些行业针对数据库制定了一系列的数据库标准。事实上，这些标准更像是招标文件中的技术规范，很难对数据库行业的发展产生任何影响。另一个典型案例是安全标准。几年前，Oracle参加了一个2级安全测试，结果惨败，就说明了问题所在。了解Oracle安全的朋友绝对相信，当时的Oracle数据库绝对不会比国产数据库好。数据库安全性较差，但当时国内很多数据库都可以轻松过三级安全。但是仔细想想，我觉得国内的数据库标准未必是坏事。做好了，才能真正推动国内数据库行业的发展。在国外商业数据库的发展过程中，百花齐放，架构不同，技术路线不同，编程接口也不同。发展到一定阶段就发现，如果不遵循一定的标准，数据库野蛮生长，数据库市场就很难快速增长。于是大家开始互相“学习”，采用一些事实上的标准，最终他们的能力开始趋同。SQL语言、B树索引、MVCC、事务隔离级别、存储过程、触发器等等等等，正是这些被商业数据库厂商广泛采用的技术，才使得关系数据库市场蓬勃发展。国内的数据库起步较晚，所以不仅上述特性成为了标配，大家也有意无意地向几款数据库产品靠拢。一个是Oracle，一个是MySQL和Postgresql，两个开源数据库。2014年，我们的优化项目开始接触国内的大梦、金仓等数据库。当我们第一次接手一个全新的数据库时，我们完全一头雾水。但是，当我看到DBA_TABLES、v$sysstat、v$sessions这些熟悉的视图时，心里踏实了很多。虽然大梦数据库的内核和Oracle不同，sysstat和session信息反映的系统状态没有Oracle那么清晰，但是这种兼容也让我们在做这个优化项目的时候受益匪浅。后来这个项目的完成比原先预想的顺利很多，效果也超出了我们当初的预期。数据库的核心技术不能标准化，这样做是没有用的。只有通过差异化竞争，优秀的数据库产品才能更好地成长。但是，一些国家标准在某些方面还是可以建立起来的。比如在可观测接口、数据字典表、云平台管理接口等外围接口方面，如果能形成标准化，对国内数据库市场还是有帮助的。我们是做运维工具的，深知可观察接口的问题。我们每管理一个数据库产品，都需要从头开始开发，从索引系统构建，到索引采集，再到诊断工具，我们都要重写一套。事实上，无论数据库产品的核心如何不同，其实很多指标都是标准的。负载、性能、并发、集群等方面的很多指标都是通用的，比如系统状态、系统指标、等待事件等。接口功能可用。我们在这些年的工具开发中，发现PG兼容的数据库产品的监控开发工作量是比较小的。虽然很多数据库在底层做了很多优化，增加了一些可观察接口，但是由于其核心部分在指标体系和监控视图方面有很多兼容点，所以国内新的PG类的开发成本数据库比一个全新的数据库产品要低得多。如果能形成一套国家标准，不仅对数据库监控产品的厂商是福音，对以后的DBA也是福音。例如，日志文件的存储位置、日志文件的文件名格式、日志条目的格式等。这些都是标准化的格式输出，对数据库内核影响很小，可以完全标准化。我们甚至可以将日志输出的内容标准化，比如错误日志。我们可以向Oracle学习，在应用程序中依次输出几层堆栈的错误报告，而不是只在最后输出错误点很多的错误信息。这个非常重要。有助于故障排除。数据字典接口的标准化，也将为DBA和生态工具合作伙伴带来极大的便利。Tablename/table_name/tname这几个字段都可以代表表的名字，为什么不能用一个统一的名字呢？既然大家都习惯了使用dba_tables，那么大家应该会使用这个熟悉的视图名。国产数据库都采用标准的数据字典接口，也可以降低国产数据库的学习成本，大大降低应用软件在不同国产数据库之间迁移的成本。事实上，部分编程接口的标准化已经由JDBC/ODBC等事实标准完成。但是在一些常用的细节上，不同的数据库产品还是很有个性的。对于序列号的使用，Oracle使用的是seq.nextval，国内很多数据库都在这方面做了兼容，但并不是所有的数据库产品都是这样使用的。存储过程更是百花齐放。以MYSQL系统、PG系统、仿OraclePL/SQL三大系列为三大支柱。是不是也能出一个国家的存储过程语法标准呢？我们可以向Oracle学习，用类似ADA的语法做一个标准。该标准与Oracle的PL/SQL基本兼容，具有一定的独立性。数据库云管理标准其实来源于最近的一个案例。企业在测试国产数据库产品时，一定要在云平台上进行测试。这就遇到了一个不公平的问题，因为云平台厂商自己的数据库产品可以以RDS的形式提供，而国内的第三方数据库产品只能部署在云主机上。RDS部署不仅比第三方数据库更容易部署，更重要的是RDS运行在裸机服务器上，云主机的云盘性能非常垃圾。经过这个测试，公平性会大大降低。于是，云厂商和数据库厂商开始谈起。数据库厂商说云厂商是排他性的，拒绝将他们的数据库归入RDS范畴。云厂商说，国内的数据库产品太多了，标准也不统一。我们把它们做成RDS太贵了。如果大家退一步说，云厂商做一个数据库RDS管理接口标准规范，数据库厂商去执行接口规范，问题也解决不了。当然，这在技术上并不难。在这种情况下，它实际上是一个业务问题。无论如何，这些标准只是接口上的标准。不同的数据库产品的核心是非常不同的。即使我们使用SQL访问，SQL代码是兼容的，但是访问数据库的执行计划会有很大的不同。同一个执行计划算子会有不同的性能和能力。因此，接口的兼容性并不意味着完全替换的能力。在我们之前做过的数据库迁移项目中，从Oracle迁移到国产数据库时，SQL执行时间变长几倍甚至十几倍是很常见的。不过这些问题最终都通过优化得到了解决。我们很多应用系统的数据库设计的很差，索引构建的很乱。在OracleCBO下，这些都不是问题，但是迁移到国产数据库，问题就多了。这些内部问题需要我们国内的数据库厂商逐步解决，在一些接口的标准化上做一些工作。这些标准不需要设置为行业强制性标准，而是为一些愿意让用户更习惯使用它们的数据库厂商提供参考标准。如果有厂商愿意参与，形成的小组确实方便了用户，那么就会有更多的用户参与，厂商才会真正受益。这将使更多的数据库供应商参与进来。这种由市场制定的标准比用于招标的标准更有价值。
