十年沉淀，国产数据库研制之路 | CCCF精选

阳振坤：感谢CCF和社会各界的认可。我离开高校前往企业界的原因有三。其一，我的导师是王选院士，他经常教育我们要把研究立足于工程之上，并在此方面有长期的积累。我个人偏向于软件研发，北京大学在文理方面氛围浓厚，相较而言，企业界在工程上的投入会更多一些。其二，激光照排系统经过一些年的发展逐渐进入成熟阶段，我希望尝试更多自己感兴趣的新东西。其三，我认为互联网是一个重要的时代发展机遇。综合以上原因，我下定决心离开高校进入企业界。

阳振坤：我认为在选择研究方向时，应该做四点考量：其一，技术顶天（门槛高、难度大）；其二，产品立地（市场大、价值高）；其三，行业契机（要求高、需求新）；其四，舍我其谁（我们能做、别人难做）。前两点是王选老师总结出来的，后两点是我总结出来的。在我看来，数据库有着广泛的市场规模与价值，同时在技术上具有较高的门槛和难度。

在互联网早期，用户数量少、数据少，大家都是用终端机访问数据，数据库的并发量并不高。随着互联网的发展和移动端设备的普及，用户数据快速增加，数据库的并发量快速增加，成本激增，导致业务矛盾变大。这种现象用一种很形象的比喻就是“小马拉大车”。此外，这个变化对数据库的可靠性提出了更高的要求，因为一旦数据库出现了问题，整个业务系统就会垮掉。同时，由于数据量太大，在实践中会把交易系统（TP系统）与分析系统（AP系统）演化成两套独立系统，使很多实时报表业务无法实现。

那时，数据库产品已经落后于工业界的实际业务需求了。但已有的数据库已经足够稳定，用户没有理由选择一个新兴的数据库，加之数据库本身研发投入大，周期又长，这就导致新的数据库难以诞生。

2010年，淘宝和支付宝的后台数据库系统承受着较大的压力（有6500个数据库），让我深刻地意识到集中式数据库发展到头了。并不是所有的用户都能用大型机，并且国际上一直没有更好的解决方案，这让我看到了机会。

但是我在研发OceanBase项目前并不是做数据库研究的，只有一些分布式系统经验。因此，这个项目在立项时是备受争议的。

阳振坤：对我而言，长期的困难就是团队的人力和物力总是有限的。我需要权衡和判断今年该做什么，明年该做什么，然后与团队的骨干达成一致。

OceanBase项目刚成立的时候，并不是我们定个目标，然后就开始招人干活，而是需要先找到业务（用户）。如果没有业务，我们就不知道哪些功能该做，哪些功能不用做。

但早些时候，没有业务愿意用我们提出的新产品。那个时候我们连一行代码都没有写，但找到了2个潜在业务。一个是淘宝的收藏夹（属于二级业务），我敢干；另一个是淘宝的购物车（属于一级业务），我不敢干。这两个业务的特征都是有2张大表的连接（join），用于查看商品价格、是否下架、是否有促销等。

收藏夹的表有几百亿条数据，商品表有10亿条数据。对于数据库的连接操作来说，如果是一个大表和一些小表连接就较容易，采用将小表全部加载到内存的方式就解决了。而如果是两个大表做连接就非常困难。我在技术上做了冒险：基于日志结构合并技术（LSM）做了实时物化视图，原理是周期性地在特定时间（比如每天凌晨2点）更新物化视图，假设在那个时间点，数据库中的数据是静态不变的，那之后所有的商品修改都先暂时放到内存中。其实对于购物车业务，也可以这么做，但是一旦出问题，对淘宝来说损失将是巨大的。因此OceanBase项目的第一个业务，我选择了影响较小的淘宝收藏夹业务。

后来，我负责支付宝业务线。那时我可以算是一个“大销售”，主要任务是寻找业务用户。支付宝的主要问题在于它占用了很多存储空间。因为其业务规模大，又没有足够的资金购买昂贵的高端磁盘阵列，只能使用中低档阵列，发生故障的概率非常高。一旦发生故障，就需要把整条业务线的人聚集起来应急：把所有网关数据都拿出来，与备份库比对是否缺数据。支付宝业务线的同事说只要能解决这个问题，就用我们的系统。我们采用三个副本的技术，通过副本投票修复数据。当时关系数据库没有系统地做这部分，但是副本投票确实能够解决这个问题。虽然当时我们的数据库系统有很多其他问题，但是如果能够把他们最痛苦的问题解决掉，他们就再也不用半夜把整个业务线的人员拉起来查找问题了。这个问题一解决，很多业务线都愿意用我们的系统了。

所以，工作的核心是要做好“大销售”，抓住合适又恰到好处的痛点问题——我们能够做出来，又能解决他的问题。而像购物车业务，我觉得我当时做不了，所以就不做。

阳振坤：兼容性是我们做得最成功的一个功能。在OceanBase开发过程中，我们实现了各种数据库方言，与MySQL和Oracle兼容，显著地降低了业务迁移的成本。因为没有用户愿意被特定产品绑定，因此我们不做自己的数据库方言。一个典型例子是国内某大型保险公司，他们曾经使用了数百套集中式数据库来承载核心系统，一年时间内，仅微调了部分业务，就全部迁移到了OceanBase上。受益于OceanBase的高压缩特性，他们的机架节省出2/3的空间。而且我们不需要用昂贵的高可靠存储和高可靠服务器，在性价比上有巨大的优势。

如果一个产品想要活下来，就一定要覆盖尽可能多的用户。我们的系统设计除了帮助大型企业，还能够帮助中小微企业，这些企业的业务往往具有曲线特点（即有访问波峰和波谷）。如果用传统方案，他们的业务机器处理能力必须能够覆盖其业务曲线的峰值，但在其他时间就会导致资源浪费。而如果使用我们的分布式方案，就可以利用分布式扩缩容能力更好地贴合业务曲线，也就带来显著的成本优化。

阳振坤：OceanBase的整个系统是依靠蚂蚁集团的业务场景成长起来的，支持的是大业务、大数据量和大访问量场景，而很多小用户、中小微企业并不具备这种场景。在蚂蚁的业务场景下，每台机器的配置都非常高，普遍有512 GB以上的内存，80~100个核，为此我们有非常多的功能优化都是针对这种高配置服务器的。例如，在这种机器上，系统启动时会把所有的调度和管理功能全部开启。但对于1个4核的机器，自然不能这么做，不然这个机器就没有资源运行了。为此，我们做了一次大的架构调整，对于小机器或者低配机器，我们将参数降低，并随着访问量和数据量的增加，逐步增加管理资源，这些管理资源都是按照百分比调整的，不是完全线性的。

阳振坤：OceanBase几乎所有的模块都是我们自己做的。其他很多数据库的实现大都使用了开源或者已有的模块，这对整个系统的性能影响比较大，也就导致其系统性能与OceanBase 差距比较大。现在整个蚂蚁集团，包括支付宝上的数据库全部运行在OceanBase上，我们有好几万台数据库服务器在昼夜运行。即使在业务低谷的时候，每秒钟都有几百笔交易，在业务高峰的时候可能有几万笔，甚至几十万笔交易（只要出现1秒钟的问题，就至少有几百个人受到影响），我们有足够大的场景持续打磨数据库。

阳振坤：测试只能证明一个系统有bug，而不能证明一个系统正确。OceanBase是我人生中第一个不亲自写代码的系统。以前开发模块、系统，我都要写很大一部分代码，但是这次我决定不写，而是把这个系统想清楚。只要功能想清楚了，大方向是对的，哪怕最初的性能不是很高，都是可以逐渐改进的。但如果整个算法和方向是错的，那就很难达到目标。所以很多时候，先把事情想清楚，然后再去做，这是最重要的。

阳振坤：OceanBase的核心是分布式架构。只要有线性扩展能力，那么上榜TPC就不是问题。在这个榜单中，我们的硬件成本只占整体价格的百分之十几。

2014年时，OceanBase提出要做一个真正的分布式系统，2021年时，OceanBase决定做混合事务分析处理（HATP）系统，后面要把这两个特征持续做好。

阳振坤：我认为各种不同类型的数据库还会持续发展的，就像网上购物平台，有淘宝、天猫和京东，还有很多垂直的电商，数据库也一样。

阳振坤：关系型数据库占据了整个数据库市场的大部分，OceanBase的优势目前还没有完全发挥出来。我们目前主要在做联机事务处理（OLTP），在联机分析处理（OLAP）上的投入还要进一步加大。至于是否外延，核心点还是要回答“为什么我们能够做，而别人做不到？”因此，目前我们的核心想法还是基于OLTP场景，在其周边进行扩展，最后慢慢扩展到OLAP。

阳振坤：我认为理解一两百万行开源代码的难度比自己写一遍还要高，而且我们难以完全掌握它。此外，最关键的是开源的代码本身不是分布式的，而是集中式的，难以用此参与到国际竞争中。

阳振坤：开源对于数据库来说是很重要的。数据库成熟和成长的周期太长，并且需要让大家广泛接受。如果数据库是一个很封闭的系统，就没有人愿意用了。2011年OceanBase的开源没有及时更新，主要是因为团队人力不足。目前OceanBase只维护一个版本，如果维护两个版本（即开源版和闭源版）会把人累死（和安全相关的以及极少数功能是闭源的）。OceanBase的开源用户数量增长速度很快。

我认为开源对产品商业化没有什么负面影响。第一，使用OceanBase的用户越来越多的是公有云用户，他们本质上是买服务，没有必要买开源版。第二，企业级用户本身就有一定的付费意愿。综合这两点，OceanBase开源后对业务的促进还是比较明显的。

阳振坤：有一些。我们有一套代码审核的流程，不管是内部提交的还是外部贡献的，代码的审核流程都是一样的。

阳振坤：我自己做软件工程比较多，会把我的想法、思路告诉学生。今年是OceanBase项目设立的第13年，很多早期的骨干都留了下来，有不少人加入这个项目组已经超过10年。经过多年的培养，这些人都有了丰富的工作经验，是宝贵的财富。