写这篇文章的周末，经常在思考一个数据库国产化的建设方案，看了很多资料。今年恰好是我参加工作的第31个年头。工作的前十年，写了十年代码，从汇编、COBOL到C语言，写了几十万行代码；在帮助用户用好数据库的同时，我也在帮助Oracle推广RAC技术；自2015年以来，我一直致力于数据库优化，同时帮助客户从Oracle迁移到成本更低的数据库系统。所以我一直对国产数据库有一种很特殊的情感，一种又爱又恨的情感。所以今天终于用到“混沌”这个话题的时候，还是有些犹豫的。在国内数据库发展如火如荼的时候，泼冷水合适吗？乱象1.国内关系数据库厂商数量众多，各自为政严重。根据工信部《2021年数据库发展白皮书》描述，截至2021年6月底，仅国内关系型数据库厂商就有81家之多。估计2022年的版本很快就会发布，在这里突破100家甚至150家公司是很有可能的。与十多年前的那几家公司相比，国内数据库行业这几年的发展确实非常迅猛，用野蛮生长来形容也不为过。在这些新兴的国内数据库厂商中，也不乏基因强大、投资巨大、真正认真对待数据库行业的企业，但大潮之下，肯定会有泥沙。国内起步较晚、人才储备和资金投入不足的数据库行业，被拆分成这么多小单元，每个独立个体的真实能力值得怀疑。无论是CPU、服务器、操作系统、中间件等IT基础设施，有多少企业致力于IT基础设施的王冠。不知道对于中文数据库来说是福是祸。上周五在一个沙龙分享了一些基于业务场景选择国产数据库的演讲。我没有开门见山地讨论业务场景和数据库选型，而是从国内数据库厂商的分析入手。这些分析是基于工信部产业发展白皮书的内容。从成立年限来看，我们国内的数据库公司还很年轻，但是成立超过20年的公司还有14家，但是这些公司过去的20年并不轻松，而且以销售数据库产品为主营业务无法生存。下去。所以，虽然它有20年的历史，但实际上，真正的历史可能要打个折扣。只看历史可能无法直接感受到差距，但从从业人员数量上，我们可以看出国内数据库行业各自为政的恶果。超过60%的数据库供应商员工人数少于100人，而员工人数超过500人的公司不到10%。对于中国的数据库企业来说，想要坐上IT基础设施的桂冠，最大的企业规模可能还不如国外二三流数据库厂商的一个小研发部门。如果把人员细分为管理、研发、产品、市场、销售、物流等部门，恐怕研发人员就更少了。据说国内最大的数据库厂商目前研发人员不到500人，这就是中国数据库企业的现状。2、技术基础薄弱，人才稀缺。大多数技术来自开源项目。如果再从技术层面来看，从专利数量来看，90%的数据库公司在数据库领域的专利数量都在100件以下。关系数据库厂商的专利总数不到4000件，截至2020年，仅甲骨文一家就拥有超过14000件专利。在技??术基础薄弱、人才匮乏的情况下，为什么能一下子涌现出这么多数据库公司和产品？从国内数据库的技术来源分析，我们可以看出一些端倪。以上图表是我们根据收集到的信息制作的，可能不是很准确，但能大致反映国内数据库的技术来源。他们大多来自开源项目，因此会有大量规模较小的数据库公司。使用开源技术发展自己的数据库产业并不是坏事。事实上，我非常赞成它。充分利用开源技术，可以加快国内数据库产业的发展，缩短与国外领先企业的差距。但是，使用开源技术并不意味着完全依赖开源技术，而是应该在开源技术的基础上进行大量的自主创新，加入自己的技术。比如国内有很多使用PG开源代码的数据库产品。哪家公司懂PG源码，贡献俄罗斯POSTGRESQLPRO级别的PG社区？好消息是，在这种乱象的背后，我们看到了一些数据库厂商开始了自主创新，他们在开源代码的基础上已经走了很长一段路。我想再多几年的积累，我们一定会突破开源的。一定的技术瓶颈，走出自己的自主之路。3、国产数据库的代码自主率成谜。你看工信部的代码自治测试报告，大部分号称国产的数据库产品都能出一份自治率非常高的报告，动辄95。％多于。我曾经测试过一款号称代码自治率超过95%的数据库产品。它的SQL引擎完全“兼容”MYSQL，使用的存储引擎不是INNODB。有一次我不小心调整了一个参数，这个参数在原来的MYSQL生态中并不常用。没想到SQL引擎的工作模式按照参数的要求进行了调整。如果保持MYSQL语法兼容性的自制代码，连这样的精妙之处都能模仿得如此完美，那就太牛逼了。4.我经常声称打败Oracle，但实际上与Oracle差距很大。虽然国产数据库的专利很少，但这并不影响国产数据库。.但在实际应用场景中，反映出我们国产数据库在CBO和SQL引擎方面远远落后于Oracle。我也和一些数据库开发人员有过深入的交流，他们也承认在数据库方面要缩短与Oracle的差距是非常困难的。在人才积累、资金投入、实际应用案例反馈等方面存在巨大差距。尤其是第三点，Oracle可以在生产环境中不断发现优化器的问题并进行改进，但我们连优化器改进的目标都不知道，更不用说从架构上规划优化器的发展路线了。5、HTAP成为国内数据库的标配功能。虽然我们国产数据库不能解决用户改进SQL引擎和优化器的迫切需求，但不妨碍我们在其他领域进行创新。在各种宣传资料中，HTAP已经成为了国内数据库的标配功能，但我想国内的数据库厂商自己真正了解什么是HTAP的却寥寥无几。他们所宣称的所谓HTAP大多只是OLTP数据库上的某种批处理能力。OLAP的计算场景与OLTP完全不同。OLTP要求资源均衡分配，每次执行时延稳定且尽可能短。而OLAP则需要小并发下的大规模甚至巨型计算。采用并行执行，充分利用服务器资源，尽可能压榨出CPU/内存/IO能力，完成复杂的计算，高吞吐量的数据输入输出。一个连资源隔离都做不好的数据库产品，如何在HTAP中支持两种可以互相伤害的计算场景？我见过的大多数号称完美解决HTAP问题的数据库产品，其实并没有真正具备实用的混合负载能力。只是它在一些测试环境下能展现出一些能力而已。即便如此，也不妨碍HTAP成为众多企业投标中的参数指标。不知道采购单位是真的需要这种算力，还是只是为了对抗差异的噱头？6、评价体系混乱。每年都会发布各种所谓的国内数据库排名，但是这种排名好像有点像坐在一排。前几天看到一个榜单，第一名和第十名的差距只有1分多。如果我是企业的IT主管，我会有一种感觉，选择这个列表中的任何一个产品都没有太大的区别。结束语国产数据库正迎来最好的发展机遇。我们看到，芯片、服务器、安全等领域在这个机会到来之际，都展现出旺盛的生命力。但是在我比较熟悉的数据库领域，我看到的只是一种表面的繁荣，而不是良性的发展趋势。希望这种情况早日改变，希望国内的数据库行业能够异军突起。
