阿里日照：做关系型数据库比做 key-value 挑战更大

OceanBase 是一个分布式的关系型数据库，是阿里巴巴自主研发的开源项目之一。根据其Github 页面上的介绍，OceanBase 实现了跨行跨表的事务，支持数千亿条记录、数百TB 数据上的SQL 操作，截止到2012 年8 月为止，OceanBase 数据库支持了阿里巴巴集团下多个重要业务的数据存储，支持业务包括收藏夹、直通车报表、天猫评价等，截止2013 年4 月份，OceanBase 线上业务的数据量已经超过一千亿条。

在2013 年4 月支付宝官方博客上的一篇访谈中，阿里正祥介绍了OceanBase 的一些设计思路和技术进展。2013 年7 月的阿里技术嘉年华上，阿里高级技术专家日照带来了一场分享，介绍OceanBase 4.0，即OceanBase SQL 版本的整体架构，质量保证和运维。会议期间，InfoQ 编辑与日照进行了一些沟通，了解一些OceanBase 的应用状态和团队情况。

嘉宾简介：杨传辉，花名日照，阿里高级技术专家，热于分享底层技术并从分享中学习。负责OceanBase 开发，关注云计算和分布式数据库，之前在百度从事大规模分布式存储、计算系统等底层基础设施构建工作。

InfoQ：先介绍一下你个人在数据库、存储系统开发方面的经历吧。在这个过程中，感觉做数据库开发这个工作本身经历了哪些变化？

日照：我之前在百度做了两年半左右的云存储、云计算系统的开发。到阿里以后三年多的时间一直做 OceanBase。以前是做纯粹的分布式系统，现在做的 OceanBase 则是融合了分布式系统和传统的关系数据库这两块东西。

我自己的经历，一直都是比较专的，基本上是一直做一件事情。

InfoQ：从做数据库的角度，做这种 Key-value 和做关系数据库有什么区别？

日照：关系数据库的复杂度比普通的 Key-Value 系统要大一个数量级。从技术的角度看，关系数据库内部的 SQL 执行、事务、多版本并发控制、数据一致性都非常复杂。另外一点，那就是大家对你的看法。只要你说要做关系数据库，用户就会将你做的系统和 Oracle、MySQL 这样的通用数据库做对比，要求支持各种业务场景、易于运维，等等。相反，如果做 Key-Value 系统的话，只需要在某种业务场景下有优势就可以了。

InfoQ：听你这么说，重头做一个关系数据库会比较吃亏，还不如在 MySQL 的基础上进行改进？

日照：MySQL 发展了这么多年，有很多值得借鉴的地方，同时也面临一些问题。关系数据库设计之初假设都是基于传统的机械磁盘，而现在 SSD 这样的新硬件发展很快，大有取代机械磁盘之势。另外，虽然 MySQL 在单机层面做了大量的工作，但是在主备同步和可扩展性上存在很大的问题。基于 MySQL 做改进的好处是可以很快应用到生产上，阿里也有这样的团队。OceanBase 则是希望从根本上解决这些问题，技术挑战要比直接改进 MySQL 大一个数量级，不过从阿里数据库的规模上看，这样的投入是值得的。

InfoQ：OceanBase 0.4 版本主要的改动在哪些方面？这些方面的开发优先级是如何确立的？

日照：OceanBase 0.4 出来之前只支持 API 接口，0.4 版本最大的一个改动就是支持 SQL。支持 SQL 以后，底层的实现机制也做了很大的改变，例如支持查询计划执行、行锁、多版本并发控制，等等，另外，二级索引功能也在开发中。另外的改进就是性能优化，0.4 之前我们的主要精力在开发功能，没有精力优化，0.4 专门成立了一个性能优化小组，整体性能上提升了一个数量级。对于查询简单且数据量较大的业务场景，OceanBase 的性能是比 MySQL 要好的。

OceanBase 开发的需求有两个来源：一个是开发版本计划的功能，另外一个是业务方提出的需求。OceanBase 大体上按照预定的计划开发新功能，不过也会根据业务方的需求调整优先级。

InfoQ：OceanBase 现在主要的客户有哪些？

日照：OceanBase 有 40 几个业务方，这些业务方来自淘宝、天猫、支付宝等各个集团子公司。

我们能够感受到的有淘宝收藏夹，底层存储全部采用 OceanBase；也有天猫评价，双十一大促的时候用得很多；另外，所有广告主的报表信息都存放在 OceanBase。支付宝也有一些业务，比如余额包的部分数据存放在 OceanBase。

InfoQ：所以，现在在量大的业务场景，数据库运维团队都会推荐 OceanBase 吗？

日照：这是我所希望的，但也不完全是这样子，对于不需要事务的场景，运维团队也会考虑 HBase。现在很多是一个混合的方案，因为没有任何一个系统有百分之百的优势。我觉得再过一两年左右，在量大的场景里，OceanBase 会有更大的优势。OceanBase 的一个特点就是，我们进步非常快，比如从 0.3 到 0.4 也就一年多点时间，这段时间 SQL 功能从无到有，性能也提升了一个数量级，而其他系统基本上变化不大。

InfoQ：OceanBase 团队有多少人？分别是什么角色？

日照：我们这个团队基本上三年时间都只做了 OceanBase 这么一个事情。最开始的时候没有那么多人，大概十几个开发。到现在为止，整个 OceanBase 团队是三十几个开发，五个左右测试，五个左右专职运维。另外，运维这里也有一些变化。以前是由 OceanBase 专职运维负责所有线上业务接入和运维，但是随着业务线越来越多，整个数据库的运维团队都会来运维 OceanBase，和现在集团 MySQL 运维的做法类似。

InfoQ：从开发 OceanBase 的角度来说，参与到这个项目的开发者需要具备哪些方面的技能，或者背景？目前，你们是如何招揽到这种技能和背景的人才的？

日照：我们团队有一套成熟的人才培养机制，主要靠培养素质好的应届生。优秀的应届生放到我们这儿，有理论学习，也有实践工作，分布式数据库开发能力提升得很快。社招我们也做，不过做得比较少，国内做类似工作的人太少了。

InfoQ：素质比较好的人怎么来评估呢？

日照：我们公司有一套统一的招聘标准，我们自己还会在统一的招聘标准上加一些东西。对于应届生，我们会看他的实践能力，他学习成绩，包括是不是足够的踏实，是不是足够的聪明，动手能力，写代码的能力，有没有花时间专门静下心来做某一类型的项目。

InfoQ：没有对特定的语言的要求？

日照：没有什么特定语言的要求。我们更关注的是基础知识和潜质，语言只是可以很快学到的一项技能。

InfoQ：进来之后大家喜欢做这个吗？

日照：应届生里面有很多愿意做底层的，因为他们觉得很有技术含量，呵呵。我们整个项目组三年以来一直都在忙新版本、支持业务，从来没停过。新同学加入后不断会有新的技术挑战，所以，大家做得还是蛮开心的。

InfoQ：中文项目的发展有很多局限性。OceanBase 是否有国际化的打算？

日照：中文项目发展的局限性是有的。OceanBase 如果一直用中文，是会有一些人来去看代码，但是很少人会去给这个代码做贡献。同时，OceanBase 现在还是一个快速发展的时期，这个时候外部的 committer 要参与进来是比较难的，因为变化是比较大的。再过一两年的时间，相对稳定一些，到那个时候，我们还是希望吸收国际上一些英语国家的 committer。之前 OceanBase 开源的消息在 Twitter 里面放出来的时候，已经引起了很多的关注，有一些 HBase 的 committer 都知道我们这个项目。

InfoQ：OceanBase 目前主要针对阿里集团内部的业务提供服务。未来是否计划通过某种途径提供对第三方企业、个人的服务支持，比如像 TAE 那样？

日照：现在已经有一些银行在跟我们进行一些非正式的合作。比如说交行，他会有一些非核心的分析型业务，放到 OceanBase 里面来搞，我们也安排了一个专职同学花大约 20% 的时间回答他们的问题。

另外，阿里云也有一些 RDS 客户的业务更适合 OceanBase，他希望能够接入 OceanBase。对他来说，OceanBase 和 MySQL 用起来是一样的，都是兼容的。虽然 OceanBase 的功能不如 MySQL 多，但是他并没有用到那些复杂的功能，他就管哪个东西更便宜。

目前这个阶段，我们还没有把阿里集团内部的业务完全支持好，因此，这个时候我们 90% 以上的精力都放在集团内部，只花少量精力了解外部需求。等到 OceanBase 足够成熟了，我们会提供外部服务，大概在一两年之后。