说起做数据库，没人会觉得这是一件能够随便成功的事情。
1985，此前忙于推广 Ingres 商业化的 Michael Stonebraker 重返学术界，想要解决当时数据库存在的问题。到了 1988 年，Michael 所在的项目组才实现并运行了第一个 Demo 版本，次年才发布了 1.0 版本。
不过，这个项目优化到 4.0 版本后就被停掉了。1994 年，加利福尼亚大学伯克利分校研究生 Andrew Yu 和 Jolly Chen 用增加的一个 SQL 语言解释器替代了早先基于 Ingres 的 QUEL 系统，并创建了 Postgres95。1996 年，Postgres95 被重命名为 PostgreSQL。
简单的文字背后是两代人努力了近十年才有了雏形，此后又是二十多年的不断优化和改进。
在国产数据库热潮下，很多进入这个赛道的企业会选择基于开源做数据库，这是可以理解的：创业者从零开始研发不仅要经历不断试错、改进带来的更长产品周期，而且未来能否被市场接纳并盈利更是未知，期间的风险不言而喻。
不过，也有一些做数据库研发的人选择从第一行代码开始去亲手构建完整的数据库，深圳计算机科学研究院（以下简称深算院）的 YashanDB 便是其中之一。他们从零开始，选择将多年的学术研究成果转化为工程产品，然后再投入到市场中检验和优化，让企业可以用另一套方式运行数据库。本期《中国卓越技术团队访谈录》，我们有幸邀请了 YashanDB 的研发团队来讲讲他们从无到有打造自研数据库的故事。
2018 年 11 月，深圳市人民政府批准建设“十大基础研究机构”，深算院便是其中之一。2019 年 4 月，深算院正式揭牌运营。当时，市面上缺乏一款从代码层面完全掌握主导权，并能与国际产品同台竞争的商业数据库。能不能做、可以做成什么样，成为深算院需要考虑清楚的问题。
经过调研和企业沟通后，深算院发现了一个问题：当时市面上的数据库普遍缺乏在关键业务场景下完全一比一平替甲骨文的能力，这成为深算院切入市场的好角度。然后，盘点了自身在数据库领域的积累后，深算院认为自己有能力做出这样的架构，甚至未来在某些场景可以超过 Oracle。如此，深算院便成立了专门的团队来做，这也是后来的 YashanDB 研发团队。
YashanDB 研发团队最开始不到十个人，但都是经验丰富的“老手”。像 YashanDB 研发总监欧伟杰有十年以上数据库内核设计与开发经验，YashanDB 解决方案总监王义寅有着二十年行业从业经验。
当时，研究院的工作场地还没有落定，这些人就先在类似众创空间的场地里办公，两间办公室，一间也就容纳四五个人。“大家都是想把数据库当作毕生事业去经营的人。尽管办公室非常狭小，但丝毫不影响大家的奋斗热情，因为重要的是我们有一方天地可以做自己感兴趣的事情。”欧伟杰回忆道。
YashanDB 研发团队初始成员，来源：YashanDB
现在，YashanDB 研发团队已经发展成为三百多人的大团队了。对数据库的情怀也延伸到了招人选择上，他们会更青睐看好数据库行业、又认为这值得长期投入的应聘者。
YashanDB 研发团队，或者说整个深算院，沿袭了贝尔实验室的模式：基础研究——技术开发——新产品生产——市场营销——信息反馈——产品改进。这与企业主导的研究团队和高校的研究团队存在本质上的不同。
企业主导的研究有一个很明显的特征，就是目标性很强。一个产品做出来后能否在短期内盈利决定了这个产品寿命的长短。这样的结果就是，企业没有足够的耐心做各种细节上的打磨。但是研究工作，特别是基础软件领域的研究，非常需要持续的技术积累，比如 Oracle 比较成功的 7.0 版本也是经过了十年时间的打磨才做出来的。
研发基础软件路阻且长，深算院做好了潜心研究以及更多耐心和时间打磨的准备。同时，深算院又设立了专门的基础研究团队，可以直接解决工业界工程实施过程中遇到的问题，并从中抽象出研究课题。
与高校研究相比，深算院拥有经验丰富的工程团队，可以把研究成果直接转化为工业级系统，这在大学很难实现。
那么，YashanDB 研发团队是如何将学术研究转化为商业产品呢？具体来说有三个阶段：学术论证、工程实现和市场验证。研发团队首先要论证学术课题的可行性，至少要做原型验证，然后再进行工程实现，之后再到市场中做具体场景的验证，否则产品能否支撑业务永远都会是一个未知数。
纵观数据库五十年发展历程，从 E.F.Codd 提出数据关系模型、到 J.Gray 提出共享数据库的一致性和锁的粒度，再到 L.Lamport 提出 Lamport 逻辑时钟，数据库的发展一直是由原创理论方法驱动产业技术革新。
但数据库内核上的理论创新进展缓慢。YashanDB 解决方案架构师王义寅用了十年的时间，从最初的实用数据库慢慢接近到数据库内核。但到了内核层面后，他突然觉得找不到方向了，因为很多理论还是三十年前的理论。“现在数据库行业需要的并不是应用创新，而是理论的革新。”王义寅说道。
深算院的基础研究部承担了理论创新的责任。一方面，基础研究部展开大数据领域的原始创新探索，专注在理论研究和突破上；另一方面，他们将原创创新成果带到实战场，希望用新技术实现弯道超车。
YashanDB 研发团队成立时，樊文飞院士的有界计算理论（bounded evaluation）和数据驱动的近似计算（data-driven approximation）理论已横扫计算机理论和系统大奖，这成为后来 YashanDB 研发团队的技术突破口。
樊文飞院士是国际上囊括了数据库理论与系统顶级会议最佳论文或时间检验奖的两位学者之一。有界计算理论是把大数据计算规约成小数据上的处理，近似计算则可在硬件规模投入有限的情况下，实现大数据精确高效查询。
樊文飞院士曾分享道，在数十亿条数据的实时查询场景下，91% 的查询可以用有界计算来解决，并且 70% 以上的查询效率可以提升 25 倍到 14 万倍，剩余 9% 不具备有界计算条件的查询，可以通过数据驱动的近似计算理论来解决。
2019 年 4 月，YashanDB 研发团队的七八位工程师听了樊文飞院士的理论阐述，经过一番讨论后，锁定了有界理论工程落地的关键技术点。当时，YashanDB 研发团队考虑关系型数据库里的很多计算是低效的，即使增加硬件设备也达不到理想的提升效果。这与有界计算和近似计算的研究方向十分匹配。
因此，在樊文飞院士的带领下，一批青年科学家与工程专家聚集在 YashanDB 研发团队，开启了自己新的一段数据库生涯。
很多研究没办法落地的原因就是理论和产品之间存在鸿沟，没有办法落实到产品里。理论研究要进入生产环境必须要经过原型验证的考验。原型验证针对性更强，会选择优先验证某一方面的特性。2019 年年中，YashanDB 研发团队在第一时间对有界计算理论做了原型验证。
传统关系理论本身已经相当成熟，现有关系型数据库系统大都基于传统关系理论打造，而有界计算理论突破了传统关系。如何在现有理论框架之下，把有界计算理论融入到关系计算的模型中存在非常大的挑战。
具体来说，一是如何与现有系统兼容，在不改变现有用户体验情况下，使用标准的 SQL 能力充分发挥有界理论的先进性；二是数据的实时变更，保证加速数据与源数据的一致性；三是如何让有界查询加速更好地服务于实际的业务场景。
为此，团队成员决定基于开源 PostgreSQL 从单机加速引擎开始验证。2019 年 9 月，BEAS（有界计算引擎） 1.0 性能测试完成，结果让团队感到振奋：基于有界计算理论，实现在 AIRCA 数据集上将查询的响应时间平均缩短了 100 倍。2020 年 6 月，团队又将有界计算扩展至分布式系统中，到了 2.0 阶段，AC discovery 已经可以通过算法的方式实现数据语义的自动发现，代替用户操作，大大提高了效率。
在刚刚发布的 22.2 版本中，YashanDB 提供了有界计算能力，将大数据变小，实现在大数据分析时不需要访问全部数据，只需要取其中的小数据集就能得到想要的答案。经实测，数据量从 10GB 增长到 1TB，YashanDB 响应时延维持亚秒级，性能提升千倍以上且未衰减，极大地节约了计算资源。
“2019 年时，基础研究团队和产品研发团队前前后后讨论了将近两个多月，不断地发现问题、讨论解决问题，经过很多尝试后最终实现了它的验证。”欧伟杰说道。
现在，研发团队和基础研究团队之间彼此支持，会定期交流，互通有无。比如研发团队在事务调度方面遇到性能瓶颈时，就会将问题提交给基础研究团队研究；基础研究团队也会将最新的研究成果同步研发团队，研发团队再做验证，如果结果得到学术界和研发团队认可，再继而转化成研发需求，成为产品能力的一部分。
因此，基础研究部做理论研究的方式大概有两种：一是该领域普遍面临的科学性课题，二是将 YashanDB 运行后遇到的问题和挑战抽象成研究课题。
随着某一理论的成熟，基础理论团队的研发重点也会相应调整。比如把有界计算应用于图计算，去拓展它的应用范围。现在，团队开始主攻跨模计算方向，优化对多模数据的查询。
数据库要应对的场景非常多，一种理论方法不能只在某个场景有效。对于做学术研究的人来说，从数学层面去证明方案在各场景的有效性非常重要。从一定程度来说，数据库理论创新就是要用最严谨科学的方式，证明自身解决方案的适用范围。
科研理论更多是在单点上实现最大化突破，而要做一个产品就得考虑方方面面的事情，包括易用性、可维护性等，维度更多、更复杂。如果说原型验证是一个点，那么工程实现就是一个面。
在花费了数月的时间做完原型验证后，团队在 2019 年下半年启动了全自研的系统开发，2022 年中正式发布 YashanDB 首个版本。
研发初期，YashanDB 研发团队首先就是做环境搭建，这是后来规模化协作平台的基础。得益于核心成员丰富的经验，研发团队用了不到一个月的时间就搭建完成了。
之后，研发团队将内核代码做了模块化划分，每个工程师会被分配到特定的模块后就专注于该模块的功能研发。做模块研发时，工程师先要梳理接口，搞清楚模块之间的交互方式，否则后面整个系统链条都会遇到问题。
“系统的实现节点有点像洋葱，它是一层一层的。我们肯定是从最核心、最内部、最基础的能力开始做，在这个基础上再不断地基于这些内核能力做特性增强。”欧伟杰表示。研发团队最开始的理念就是先用最小粒度的内核能力让系统跑起来。
“根据团队成员们的经验，在大多数场景下，一个数据库 80% 以上的功能都不会被用到，反而可能只有 20% 的功能是真正需要。因此，我们就优先解决关键矛盾，即先解决那 20% 的功能，不常用功能的优先级相对较低，后续根据外部客户的需求再添加。”欧伟杰表示。
YashanDB 研发团队最先做了 SQL 引擎和存储引擎，SQL 引擎方面首要考虑其执行能力，存储引擎则更多考虑存储组织等。这些能力打通后，研发团队开始考虑做能力优化，比如在 SQL 引擎上增加有界计算支持来提高查询性能，存储引擎上考虑数据复制、事务处理等能力。
常规的开发模式是积累到一定规模后要先设计再验证，但 YashanDB 研发团队早期选择了开发迭代速度更快的方式，即在保持竞争力的前提下小步快跑，不断增强和调优。
“打个不恰当的比方，有点像在一路狂奔。团队给要增加的功能定下上线时间后，各模块的同学就完全沉侵在工作中了。”欧伟杰说道。这也促使早期 YashanDB 基本以周为单位进行迭代。
YashanDB 与 Oracle 的表现形态接近，但底层基础完全不一样。用欧伟杰的话说就是：车子的外形可能看起来差不多，但里边的发动机却有很大的差别。
在优化器方面，Oracle 的优化器经历了很长时间的打磨和不同场景的调优，毫无疑问是业内领先的水平，而刚刚起步的数据库很难找到所有场景，甚至很多场景都还没见过。YashanDB 研发团队的应对思路也是先从简单的着手，再逐渐衍生到复杂场景。
根据团队里从业多年 DBA 总结的经验，研发团队先把最常见、最基础的优化规则放到了自己的优化器里，这可以被认为是 RBO（Rule-Based Optimization，基于规则的优化器）。在此基础上，团队做了完全自研的 CBO（Cost-Based Optimization，基于代价的优化方式)，完成了第二阶段的工作。下一步，也是现在研发团队正在做的，就是基于机器学习能力积累各种场景应对能力，研发团队也希望可以借此实现弯道超车。
鉴于一旦使用开源产品，存储引擎的能力就会受制于开源，YashanDB 研发团队选择了全自研的方式。存储引擎本身是一个非常精巧、需要细致打磨的组件。在此方面，研发团队优先关注数据持久化和事务处理。
数据持久化与硬件资源紧密相关，如何最大化 IO 资源的使用、保证数据可以在最短时间内写到硬盘上是个挑战。事务则要保证无论怎么对数据增删查改，都要保证它的 ACID 特性（原子性、一致性、隔离性、持久性）不受影响。
对于事务处理，团队会更看重性价比。事务处理的粒度越小，并发性就越好，并发访问同一个事务单元的几率也越小。但是，如果事务处理的粒度非常细就会带来大量的管理成本。所以业界大部分的实现都在找事务并发粒度和管理成本的平衡点。
研发团队则利用了樊文飞院士提出的并发事务调度方式。当前，业界主要的事务处理方式有 MVCC（多版本并发控制）、OCC（又名乐观锁）和 PCC（又名悲观锁）。实践中，大家更偏向 MVCC，但学术界多年来都在研究 OCC 并发控制思路。樊文飞院士则结合了 MVCC 和 OCC 的优势，使得在高并发场景下，系统不受核数改变的影响，而且整体成本可控。
面对大压力场景，数据库保持稳定的常用方法是让内存资源开销保持相对稳定，避免因资源大幅波动导致系统行为不可控。YashanDB 则结合了存储、事务处理等能力，最大限度保证在线高通量场景下数据库的性能稳定。
对于 YashanDB 的定位，研发团队最开始瞄准的是新兴场景，主要聚焦在 OLAP 领域，商业目标与 Snowflake 类似。
到了 2019 年下半年，YashanDB 研发团队认为，基于开源改良 / 二次开发的产品并不是解决我国安全可控的可行技术路线，于是同步进入 OLTP 领域，目标是打造一个全自研的国产数据库，具备全面替代 Oracle 的能力，真正从核心应用层面进行国产替代。
“金融对数据操作正确性要求非常严格，这种场景是我们比较擅长的。”王义寅说道，“很多软件是在假设硬件非常可靠的情况下设计的，而我们设计的前提是硬件没有那么可靠。”
金融行业对高可用的要求非常高，而基础设施如存储、网络、服务器等本身存在故障失效和性能扰动。国产替代后，硬件扰动出现的概率有所增加，如果与软件适配性差，产生的业务影响很可能是致命的。YashanDB 研发团队给出的解决方案是增加一个主动监测机制，间隔特定时间自动检测一次并主动报错、修复等，包括硬件故障的主动修复。
对于企业来说，迁移面临最重要的问题是这个过程中是否存在显式和隐式的转换。如果存在大量的显式和隐式转换，则意味着需要做大量的适配，风险也会更高。
为使企业从 Oracle 迁移更加无缝，YashanDB 研发团队将存储的数据类型，比如字符串、日期、浮点类型等细节上都做了与 Oracle 精度完全一致，消除隐式转换风险。显式转换上，则在 SQL 函数、语法格式等方面与 Oracle 兼容。团队还提供了一系列迁移工具，比如数据和应用校验工具等。
针对重点行业的核心系统国产化迁移，YashanDB 建立了一套完整的适配替代保障机制，完善故障预案、保障措施齐备，来确保操作充分验证且可回退，从而达到无感切换的目标。
具体来说，在业务上线前，YashanDB 通过充分调研数据库使用情况，对原有配套软硬件提前适配，并对关键 SQL 的执行计划进行性能评估，确保关键 SQL 的执行性能不低于替代系统。同时会进行关键负载场景下的业务长稳测试，保证系统环境的高可用。业务上线过程中，通过多种工具手段，YashanDB 会反复验证存在转换的操作，通过双平面长周期并跑，确保满足平滑切换条件。上线运行后，除了提供服务热线和提供驻场服务外，YashanDB 还提供”Bug 直通车”，凭借对数据库代码的完全掌握能力，即使触发软件错误也可以快速及时修复。
“我们会主动跟团队的人强调要从客户视角去思考问题。”王义寅说道，“技术团队容易说我的代码多好、技术多牛，但客户要的只是能否以最小成本获得最优的产品体验，这才是关键。”
“没有技术积累做不出好产品，而技术的本质体现在人上。”欧伟杰说道。
YashanDB 研发团队能够快速发展的原因，除了 2019 年赶上了国产数据库发展的快车道外，还有就是现在进入数据库行业的人相比之前越来越多了。但事实上，国内数据库开发人才的缺口还是很大，真正能去做数据库内核的人没几个。
“为什么数据库这么少的人在做？因为大家都觉得这件事很难，都觉得这不是一件很容易成功的事情。”欧伟杰说道，“但是当你明明知道它很难，还愿意义无反顾去做的时候，必然是有某种激情或者是热爱来驱动自己。”在欧伟杰看来，兴趣难以持久，能让人长期坚持下去的是热爱。
“很多工程师，特别是一些专家，不经过一定时间的积累是很难真正在这个领域有所建树的。国内外的很多大牛，年龄不要说 35，很多都是五字开头的，他们在随着数据库一起成长。”欧伟杰分享道。
但欧伟杰也坦诚，在招人方面，深算院的优势并不明显。当前，YashanDB 虽然已经商业化，但还需要继续深入。但欧伟杰表示，相对于很多企业要有经验的人，YashanDB 研发团队对零基础的同学会有更多耐心，通过进行相关培训来帮助新人度过陡峭的学习曲线。
面对越来越庞大的团队，YashanDB 研发团队的管理理念跟他们做数据库的思路很类似：化整为零，即把复杂的事情变成更小的粒度。团队以小组为基本单位，每组 5-7 人。“我们尽可能想让信息能在内部传递流畅，过深的层级可能导致大家只能看到自己眼前的一亩三分地。我们希望大家，尤其是校招的应届同学能够看到一个完整的体系，端到端地去思考一些问题，这对大家成长更有利。”欧伟杰说道。
在欧伟杰看来，一个行业要出现好的产品，至少需要两方面的因素：一是有一定程度的技术积累，二是被市场接纳。数据库是 To B 的生意，新产品就需要时间逐层突破。
未来国产数据库要做的就是真正将企业核心业务承载起来，这场竞赛中只有过硬的产品才能胜出。对于这个部分成员甚至已经有几十年数据库经验的团队，当前的重点是多活共享集群的打造，他们要直接对标 Oracle RAC，支持可扩展的、多活共享集群的能力，真正实现在核心业务上的高性能、可信赖。
“这对 YashanDB 来说也是一个里程碑，我们一定要打出漂亮的一仗！”欧伟杰说道。
嘉宾介绍：
欧伟杰，武汉大学博士，深圳计算科学研究院 YashanDB 研发总监，10 年以上数据库内核设计与开发经验，曾负责分布式 NewSQL 数据库研发, 多篇顶级会议论文及技术专利，熟悉 OLTP，HTAP 业务场景及前沿技术趋势，研发的产品服务全球数亿用户。
王义寅，YashanDB 解决方案总监，毕业于南京邮电学院通信工程系。曾就职三大运营商、四大行、ICT 巨头，近二十年行业从业经验，主导产品有营账系统、分布式数据库、移动设备自研数据管理方案等，多项中美技术专利。
