前几天参加一个行业技术研讨，参会的大多是各企业的一线工作者和高校的相关专业科研人员。谈到一些国产IT软硬件基础设施产品的时候，好几位专家提到国产IT基础软硬件目前最重要的是要满足一线生产系统的基本需要，不要谈太多空洞的概念，不要去追那些花里胡哨的功能。目前行业的核心业务支撑并不需要太多的新功能，能把国外商用软件十几年前的基础功能做扎实了，就是对目前的信创工作的最好支撑。

其中一位专家谈到现在的一个现象，国产基础软硬件与国外商用产品的技术还是有很大差距的，不过在概念上一点都不落后，说句不太好听的话就是技术不够概念凑。我一直认为当产品做到只会玩概念了，那离死也就不远了。以目前应用最为广泛的交易型数据库为例，实际上这个已经发展了三十多年的IT基础设施，基础功能就已经十分庞杂了，用户大多数也只会用到其中最为核心的功能。我见过的大多数以Oracle为核心数据库的银行，其主流版本还是十多年前的Oracle 11g。

很多用户和DBA对国产数据库最厌烦的事情就是过度宣传，各种大会上从来没输过，而到了实际应用场景上，却从来没顺利过。数据库厂商却觉得很委屈，如此内卷的市场，多做宣传，咋活下去呢?酒香还怕巷子深呢，更何况街边的酒铺子太多了，为了吸引客人，都在大量往里兑香料 ，你原汁原味，别人都感觉不到你的存在。于是数据库的PK没法在其核心功能的主战场上进行，必须另辟蹊径，在一些新概念上做文章。技术不大好PK，那就只能PK概念了。

国产数据库的对标对象Oracle不太擅长搞一些比较虚无的概念，所有的概念都实实在在地写在《Oracle Concepts》这个文档里，都十分扎实，如果去PK这些概念会很吃亏。因此用来凑数的概念也必须搞得云山雾罩才好。

“极致高可用”，这个词是不是很高大上，我用了三十年数据库了，最近几年才在国产数据库那里听到这个名词。现在参加某个数据库的产品介绍会，几乎都会提这个能力。我第一次听到这个词的时候还是颇受震撼的，正是因为“极致”这个词正是用户对数据库“高可用”的追求目标。当时说是极致高可用能力可以把故障切换时间从分钟级降低到秒钟级，30秒左右实现切换。今年这个数字已经降低到10秒了，如果你敢说自己的产品故障切换是15秒开外 ，那么就不配叫极致高可用了。

“极致高可用”这个名词，把我脑子里的高可用概念完全弄乱了。十多年前，我给客户培训Oracle 10g Fast Connect Failover(FCF)的时候，就告诉客户，从TAF迁移到FCF，可以实现亚秒级的故障切换，亚秒是低于一秒的意思，这个亚秒级的应用故障 切换比极致高可用差了多少呢?O记起名字的能力真的比我们差了不是一星半点。

后来和O记的一个朋友探讨O记为什么没有在文档中强调亚秒级的应用切换能力，他们的回答是故障切换是和应用场景紧密相关的，在一般情况下，Oracle RAC确实能够在几百毫秒内甚至更快完成故障切换，但是在某些场景下，是可能会出现较长的切换时间的，这和跨节点日志回放、失败事务回滚、全局锁管理等机制有关的 ，因此O记无法给出一个确定的确保完成的时间。当我和某国产数据库厂商谈到很多用户在实际生产环境中的故障切换往往无法达到他们承诺的15秒、30秒的标准，这是怎么回事，他的回答也是故障切换时间与应用场景有关，有时候无法确保。

还有一些更加高大上的概念，比如日执行SQL 超过1亿条，是不是够牛的。可能大多数朋友和我一样，数学能力退化了。我默默地打开计算器，按照日忙时集中系数为0.1计算，大概日执行SQL一亿条相当于高峰时段一小时内平均每秒执行数为2800左右。我翻了翻手头的AWR报告，在一个2009年的报告中，我找到了一个数字，当时一台现在看来性能很烂的IBM P550上，有个Oracle数据库RAC节点，从AWR上看到的数据是每秒执行5799条SQL。从这个角度来看，似乎一个亿的日SQL执行量也不见得就是个多么牛逼的事情了，如果写成平均每秒执行SQL 3000条，可能就显得不那么高大上了。从这个例子也可以看出，有些看似很牛掰的概念也是经不起计算的。

非要用一些让人看不透或者十分缥缈的概念来宣传自己的产品，而不是踏踏实实的让自己的产品更加好地适配客户的应用场景，这是目前内卷的数据库市场中的一个十分不正常的现象。其实数据库和快消品不同，数据库是个长周期的产品，不是依靠短时间的营销就能做成的。因此我们的数据库厂商应该多听听客户的需求，而不要把精力都放到让人看不大懂的概念上。

原文标题：《技术不够概念凑》