前一段时间西南某省商业银行爆出 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。
甲骨文数据库开发者的典型工作方式则是这样的：
- 花两周时间试图理解以神秘方式相互作用的 20 个不同标志引发的这个 Bug。
- 为处理这个特殊情况添加一个新的标志。增加几行代码，检查这个标志，并绕过问题情况避免 Bug。
- 将更改提交到由大约 100 到 200 台服务器组成的测试农场，这些服务器会编译代码，构建新的甲骨文数据库，并以分布式方式运行数百万测试。
- 回家。第二天来工作，做别的事情。测试可能需要 20 到 30 小时才能完成。
- 回家。第二天来检查你的测试结果。好日子可能有大约 100 个测试失败，坏日子可能有大约 1000 个测试失败。随机挑选一些测试，试图理解你的假设出了什么问题。可能还有10个以上的标志需要考虑，才能真正理解错误的本质。
- 为了解决问题，增加一些新的标志。再次提交更改以进行测试。再等待 20 到 30 小时。
- 反复操作两周，直到你得到正确的标志组合的神秘咒语。
- 最终有一天你会成功，没有测试失败。
- 为你的新更改增加一百多个测试，以确保下一个不幸触及这部分新代码的开发者不会破坏你的修复。
- 提交最后一轮测试的工作。然后提交审核。审核本身可能需要另外2周到 2 个月。所以现在转移到下一个错误上。
- 2 周到 2 个月后，一切完成，代码最终会合并到主分支。
如果你怀疑这是添油加醋的话，这位留言的程序员特地强调：
以上是甲骨文程序员修复一个错误的生活的非夸张描述。现在想象一下开发一个新功能会是多么恐怖。开发一个小功能（比如添加一种新的认证模式，如对 AD 认证的支持）需要 6 个月到一年（有时两年！）。
refer: Hacker News
感谢有耐心看到这里。我之所以用大篇幅把这个细节罗列于此，是要说明，像 Oracle 这样成熟的商业数据库软件，已经有了巨大的「代码债务」，深陷泥潭。这样的历史包袱，还能负重前行已经算很了不起，但必然是步履蹒跚。
上面这个技术讨论发生在 2019 年，即使是最近 10 年，如果翻看 Oracle Database 的每个版本的更新说明，大家可能会发现乏善可陈，几乎不会有什么令人激动的新特性或是新能力，不是不想做，也不是没需求，而是做不出来了。
这样复杂的代码，如果真的出了问题，即使是原厂工程师也不能很快解决问题。这就是我说的，现有产品停滞不前，机会就会到来。如果 Oracle 还能持续迭代，不断推出新版本新能力，那么，想追赶并非易事。
如前所述，Oracle RDBMS 的代码量大约 2500 万行，同时期的 PostgreSQL 代码大约 150 万行，MySQL 大约 450 万行，代码规模是 PostgreSQL 的三倍。国产数据库的代码量大约多少？OceanBase 前一段时间宣布开源的核心代码量大约 300 万行。TDSQL 的代码量有多少，目前没看到对外披露。
注意我们这里说的只包括核心代码行数，不包括测试用例。要知道，即使是像 SQLite 这样轻量级的数据库软件，测试用例也有超过 90 万行的代码。
在这里强调代码总量，当然不是说代码量越大，软件越厉害。而是说，代码规模越大，迭代速度一般会越慢。即使是开源软件也会出现类似的情况。这个应该不难理解。
顺便说一下，这个现象不止发生在数据库软件产品上，在操作系统层面也非常类似。Android 当年为什么可以取代 Symbian？其中一个原因是 Symbian 代码庞大臃肿，已经没有办法迭代更新。所以大家不要觉得国产操作系统就没有机会。现在桌面操作系统的 Windows 已经臃肿不堪，手机操作系统的 iOS 也有类似迹象。
从代码量上看，我们也可以大致得出结论，国产数据库软件不排除也会出现行业内调侃的「人家一开源，我们就创新」的怪现象，但是，从头写出 300 万行代码的国产数据库软件，也是可能的。另外不要忘了，我提到的前提条件 3 ，国内现在有足够的人才储备。
最后谈谈时间窗口问题，这一点指的是，在一个足够规模化的市场里，如果要进行一款替代性产品的研发，市场能给多大的耐心。一种路径是，政府机构可以给与足够的补贴，国内的国产化软件一度依赖补贴生存，因为在市场里暂时得不到足够的认可，而数据库软件都是用在比较关键的应用上，比如银行。另一个路径是，有需求和应用场景的商业公司，可以对这样的研发团队提供资金支持，或者，就是自己公司的研发团队。而过去的十多年里，国产数据库刚好有这样的机遇。
国产数据库为什么能行，跟来自商业公司，尤其是互联网公司的支持有直接的关系。因为产品的初期验证在自己公司内部相对更为容易一点。
除去以上这些大的前提条件，还有哪些关键因素呢？有一点很重要的是，早期一定要有个热爱数据库技术，有使命感的灵魂人物，比如 OceanBase 的创始人阳振坤。一款大型商业软件的成功，最后当然是要靠程序员们一行行代码写出来，但是，只有这样的技术领袖，才能召集到足够的技术人才。
曾几何时，我不太相信国内能做出来优秀的企业级数据库产品，因为见过太多失败的案例，见过太多雷声大雨点小的所谓「国产创新」。甚至刚开始听到 OceanBase 的时候，我也是持否定态度。这是十多年前我的真实观点。
但是，因为相信，所以看见。有人做到了，我必须要说一句：佩服。
现在必须要修正一下我的旧观点。当然也有修正的必要，回到 2010 年，我认识到随着 SSD 的普及应用，数据库软件的架构范式会发生巨大的变化，分布式数据库必然是趋势。
但是完全想不到一些前提条件会成熟得这么快。
曾经一度，国内软件开发者对世界软件巨头是需要仰望的，甚至是有些迷信。但如今，我们已经可以平视，因为可以直接做原生的分布式数据库，甚至有些技术上已经开始领先，这也算是弯道超车。
回到开头的那家商业银行采购数据库的事件，我认为之所以引起行业质疑，最大的问题在于不透明，有太多语焉不详。
国产数据库不是笑话，而使用国产数据库作噱头去连蒙带骗，这才是笑话。当事厂商，如果自己确实觉得被行业冤枉，那么可以拿出稍微细节一点的部署说明，比如部署了多少服务器，部署在什么配置的服务器上，承载了多少数据量，支撑了多少应用并发……把这些信息大大方方的拿出来，更容易让人信服。
数据库软件能在银行系统上成功应用部署，无疑是用户选择产品时候所可以参考的一条金标准。以此衡量，OceanBase 目前无疑是优势最大的一家。有人或许会说，那不是因为人家产品一上来就能在核心业务上跑，别的同行哪有这个机遇。
其实还真不是，OceanBase 一开始在内部也有不少人质疑，所以最开始取得的机会只是用在淘宝的收藏夹上。这其实是个非关键业务，直接面对关键业务的严苛检验是一步一步获得信任之后的事情，即使是用来支撑核心交易，第一次也只是承担「双 11」10% 的交易流量，第二年才有机会支撑 100% 流量，然后才是上线支付宝核心账务、核心支付系统。
所以，如果是个大家都没听过名字的数据库产品，突然一上来就要替换银行旧数据库，直接拿下几个亿的订单，难免让人觉得哪里有点不对劲。声称自己很强是没有用的，要证明给别人看很重要。直接跳过这一步是不行的。
要知道，支付宝的业务对数据库软件的要求，甚至比银行还要高，不止是数据存储的可靠性，还要求必须要高性能，高扩展性，高可用性。总体拥有成本（TCO）还要足够低。在软件行业有「吃自己的狗粮」的说法，支付宝吃过了之后，潜在用户当然也就更加放心。
这就好比，造一台越野车，传统数据库厂商的架构限定了他们只能从轿车改造，以便适应越野能力。而国产数据库厂商是越野爱好者，他们更了解越野，自己的场地足够复杂，这种条件下造出来的车，天生就适合越野。从某种角度上说，这是应用驱动创新的范例。
我比较过几款国产数据库的典型客户，客观的说，OceanBase 的客户群，看起来更「刚性」一些。承载的用户业务较为苛刻，而且客户更具多样性。
我对国产数据库产品还有几个小建议：
1.文档应该再改进
我们那一批 Oracle 数据库用户，可以说都受益于 Oracle 丰富的文档，完备，优雅，简明易懂。我认为国产数据库产品，应该在这方面多下功夫。不应该只让工程师来写文档，过于晦涩，充斥着各种不规范的拼写，内容更新还不及时。应该找一些专业写文案的人进行润色。
重视文档，怎么都不为过。
2. 最佳实践案例要更丰富一些
我在国产数据库平台上可以找到一些宣传稿，但较少能找到最佳实践（Best Practice）的文档。我相信每家产品都有实际应用案例，具体的细节是怎样的，能不能详细说说？语焉不详不容易建立起信任感。
3. 产品命名应该朗朗上口
国内大公司的开源技术产品，有个通病是不会给产品起名字，完全的技术流的思维，到数据库领域也是如此。比如 TDSQL，这样的产品，中文用户日常交流的时候怎么发音呢？别扭。当然，英语用户读起来也会觉得别扭。
4. 开源是对的，更要坚定
我认为国产数据库产品的拥抱开源是一个正确的选择。但是从公司的做法看，常常会看到一些态度游移不定的开源参与者。如果要开源，不妨态度坚定一些。
不用再重复讨论国产数据库能不能替代 Oracle，现在看起来技术上完全没有问题，而且已经是实际在发生的事情。接下来，我们肯定会看到替代案例。
期待国产数据库都能走出去，也到其他国家或地区施展一下拳脚。相信自己，其实很能打。
–EOF–