我看国产数据库
前一段时间西南某省商业银行爆出 4.27 亿购买的「国产数据库」出现造假的传闻,引发了业内不小的关注,有人来问我这个前从业者的看法,顺带还问起对国产数据库的评价。
长久以来,从业者对于国产数据库,包括国产软件,有些复杂情绪。那些资深的从业者,不可避免存在着一些根深蒂固的成见,对于非专业的从业者,讨论起相关问题来也存在不少偏见、误解和迷思。有必要对这个问题展开聊一聊。
对于数据库软件而言,市场里早已经有成熟的产品,商业上也早就取得了巨大成功。有些人先质疑的是必要性,是不是必须要国产化?当然,现在在信创产业大环境下,这个问题已经不再需要争论,大多数人也已能理解这种必要性。
数据库软件,如果做到国产化并且能够形成超越,我认为有一些必须要确定的前提条件:
- 足够大的市场空间
- 出现新的应用场景
- 相关人才大量涌现
- 已有产品停滞不前
- 有合适的时间窗口
这些前提条件,缺一不可。
曾几何时,数据库软件国产化大家都当做笑话来看,也确实有几家公司坚持了很多年,但恕我直言,那个时期的国产化数据库,还没达到开源数据库(比如当时的 MySQL)的水准,我当时的看法更苛刻,「跟个玩具差不多」。应该说,这受当时客观条件的限制,比如,专业技术人才的匮乏就是最主要的问题之一。
那么现在,和二十年前,十年前相比,我们具备了哪些条件?
中国互联网和信息产业的市场规模在不断变大。2000 年,我国软件产业规模只有 593 亿,2010 年,1.84 万亿,2020 年,8.16 万亿。这么大的市场,即使没有相关政策的扶持,也必然会出现各种软件的竞争产品,因为有各种新的需求。
市场大,也意味着通过持续获得客户取得商业收入会成为一种常态,可以生存下来,而不是只依靠补贴或是风投的钱。
然后看应用场景,以电子商业领域而言,随着用户规模的急剧扩大,新的应用场景层出不穷,必须要面对解决一些特定的问题,放眼全世界都是难题。比如,大促时候的「秒杀」,就必须要解决超大规模的高速并发难题。移动互联网如超新星一样的大爆发,各种新应用场景如同大爆炸一样涌现,这就带来了独特的新机遇。
场景的挑战足够大,困难足够多,这时候依赖旧的技术解决方案是行不通的,行业在该领域必须做出创新,也只能创新才可能有发展。
以 Oracle、DB2 为代表的商业数据库软件,是旧技术体系年代不断演进的产物,在互联网时代已经有些力不从心,到了云时代,架构方面的问题就更显而易见。
我们在过去的二十年间,涌现出了大量的技术人才。关于技术人才的规模性增加,这也是一种必然。我们每年都有足够大的毕业生基数,然后这些人才毕业后进入到市场,面对各种复杂场景,技能不断提升。慢慢的就会出现一些专门面向数据库的开发人才。现在能给数据库软件贡献代码的优秀工程师可能比我刚从业的时候的 DBA(数据库管理员)都多。
至于现有产品的停滞不前,这一点见仁见智。以我的观察,行业内最主要的领头羊,Oracle,最近十年的在数据库软件上的创新能力乏善可陈。
巧得很,前几天我刚好看到 Hacker News 上一则讨论,「你见过的最大规模的烂代码是什么?」
有一则回答是这样的:
甲骨文数据库 12.2 版本,差不多有 2500 万行 C 代码。这简直是难以想象的恐怖!在这个产品中,改动任何一行代码都会导致成千上万的现有测试失败。几代程序员在严峻的截止日期下工作,使代码充满了各种杂乱。非常复杂的逻辑、内存管理、上下文切换等都是由成千上万的标志维系在一起。整个代码充满了神秘的宏,没有拿笔记本手动展开宏的相关部分,是无法理解的。理解一个宏的作用可能需要一到两天。有时候,需要了解 20 个不同标志的值和效果,才能预测代码在不同情况下的表现。有时甚至需要了解上百个。我并不夸张。这个产品之所以还能存活并运行,完全是因为数以百万计的测试!
这里说的甲骨文数据库,其实就是指 Oracle 的 RDBMS,要知道 Oracle 的产品体系现在也非常复杂,已经是一个巨大的产品家族。数据库 12.2 的版本对应的外部版本应该是 Oracle 19C。
甲骨文数据库开发者的典型工作方式则是这样的:
开始处理一个新的 Bug。 - 花两周时间试图理解以神秘方式相互作用的 20 个不同标志引发的这个 Bug。
- 为处理这个特殊情况添加一个新的标志。增加几行代码,检查这个标志,并绕过问题情况避免 Bug。
- 将更改提交到由大约 100 到 200 台服务器组成的测试农场,这些服务器会编译代码,构建新的甲骨文数据库,并以分布式方式运行数百万测试。
- 回家。第二天来工作,做别的事情。测试可能需要 20 到 30 小时才能完成。
- 回家。第二天来检查你的测试结果。好日子可能有大约 100 个测试失败,坏日子可能有大约 1000 个测试失败。随机挑选一些测试,试图理解你的假设出了什么问题。可能还有10个以上的标志需要考虑,才能真正理解错误的本质。
- 为了解决问题,增加一些新的标志。再次提交更改以进行测试。再等待 20 到 30 小时。
- 反复操作两周,直到你得到正确的标志组合的神秘咒语。
- 最终有一天你会成功,没有测试失败。
- 为你的新更改增加一百多个测试,以确保下一个不幸触及这部分新代码的开发者不会破坏你的修复。
- 提交最后一轮测试的工作。然后提交审核。审核本身可能需要另外2周到 2 个月。所以现在转移到下一个错误上。
2 周到 2 个月后,一切完成,代码最终会合并到主分支。
以上是甲骨文程序员修复一个错误的生活的非夸张描述。现在想象一下开发一个新功能会是多么恐怖。开发一个小功能(比如添加一种新的认证模式,如对 AD 认证的支持)需要 6 个月到一年(有时两年!)。
文档应该再改进
阅读原文
最新评论
推荐文章
作者最新文章
你可能感兴趣的文章
Copyright Disclaimer: The copyright of contents (including texts, images, videos and audios) posted above belong to the User who shared or the third-party website which the User shared from. If you found your copyright have been infringed, please send a DMCA takedown notice to [email protected]. For more detail of the source, please click on the button "Read Original Post" below. For other communications, please send to [email protected].
版权声明:以上内容为用户推荐收藏至CareerEngine平台,其内容(含文字、图片、视频、音频等)及知识版权均属用户或用户转发自的第三方网站,如涉嫌侵权,请通知[email protected]进行信息删除。如需查看信息来源,请点击“查看原文”。如需洽谈其它事宜,请联系[email protected]。
版权声明:以上内容为用户推荐收藏至CareerEngine平台,其内容(含文字、图片、视频、音频等)及知识版权均属用户或用户转发自的第三方网站,如涉嫌侵权,请通知[email protected]进行信息删除。如需查看信息来源,请点击“查看原文”。如需洽谈其它事宜,请联系[email protected]。