OceanBase创始于2010年6月，在过去的9年时间里承载了阿里巴巴和蚂蚁金服许多的艰难使命：核心链路去O、支撑双11。业内流传过一个有趣的故事：在2014年的双11，OceanBase创始人阳振坤对当时视察的蚂蚁金服董事长彭蕾说了这样一句话：“你看我们窗子都已经打开了，如果等会出了问题，我们就准备从这跳下去。”而这之后OceanBase承载着这样一种使命平稳支撑了每一个双11。2017年，随着蚂蚁金服的开放战略，OceanBase也开始进入了商业化的进程。
梅庆（花名庆涛），现任蚂蚁金服OceanBase团队技术专家。早些年在阿里巴巴B2B团队做Oracle应用DBA支持业务，后来支持淘宝旺旺去O、阿里云数据库、天猫双11大促业务等，在分布式数据库的应用开发和架构上有着丰富的经验。目前主要从事OceanBase对外输出的解决方案设计和技术推广工作。（个人公众号：OceanBase技术闲谈）
01
数据库行业资深老炮寄情阿里8年
Q1：您从事数据库行业已经十几年了，可否从技术角度回顾下自己的职业经历？
庆涛：我毕业后从事企业软件开发，接触了Oracle和SQL Server数据库，对数据库优化非常感兴趣就来到阿里巴巴B2B从事Oracle开发DBA。三年后集团团队调整后支持阿里旺旺MySQL去O业务，随后支持阿里云数据库MySQL和SQLServer。中间离开阿里2年，15年开始支持天猫业务（分布式MySQL），17年从事集团数据库产品和解决方案的对外输出，18年开始从事蚂蚁金服OceanBase数据库产品和解决方案对外输出。
Q2：始于2010年阿里主张的“去IOE”（IBM小型机、Oracle数据库和EMC存储设备）成为现象级事件，虽然现在鲜有提及，当初您做了哪些事情以及对您带来了哪些改变？
庆涛：早期主要是跟团队一起探索MySQL的变更和规模化运维，主要是分布式MySQL的高可用切换和性能诊断方面的工作。
Q3：您在阿里8年，经历了很多角色的转变，从起初在阿里B2B从事与Oracle相关的开发DBA、后来又加入到“去IOE”运动中，接着支持RDS MySQL和SQLServer，现在是OceanBase技术专家，您在期间是如何调整的？对于新技术的学习您有什么心得和体会可分享？
庆涛：各个数据库功能虽然有些不一样，但运维的方法思路是一样的。此外底层的原理也有相通，可以举一反三融会贯通。我觉得能让我一直适应这个变化的关键是对数据库运维和性能诊断技术的喜欢。对于新技术的学习我倾向于先从原理上学习。
Q4：目前，您主要从事OceanBase对外输出的解决方案设计和技术推广工作，这段时间您认为对您最大的挑战是什么？
庆涛：由于OceanBase对外商用的时间还不长，还在逐步建立自己的技术社群和生态，目前最大的挑战是让传统数据库的业务开发和运维理解OceanBase的优势和使用方法。
Q5：您是技术出身，您觉得技术人员要如何提升对业务的敏锐度？
庆涛：个人觉得先熟悉业务数据库，熟悉每个SQL及其背后的业务意义，熟悉数据库性能变化后的业务因素。然后尽可能的介入业务数据库架构设计、业务性能诊断，探索业务压力和数据库资源及性能的关系。
Q6：能否推荐一些对您影响较大的一本书或一些人。
庆涛：个人接触过比较好的书有《OracleDatabase 9i/10g/11g编程艺术》、《高性能MySQL》、《数据密集型应用系统设计》。影响比较大的人有早期DBA团队的人和OceanBase团队阳老师。阳老师带领OceanBase团队9年下来能坚持做一个产品逐步做大做强这点很令人敬佩。有兴趣的可以去OceanBase公众号看看关于阳老师的专访。
02
九年OceanBase的里程碑事件及架构特点
Q7：OceanBase作为国产自研数据库的一员，它是一款怎样的数据库？原生分布式数据库？NewSQL数据库？以及经历了哪些里程碑式的事件。
庆涛：OceanBase定位是通用的分布式关系型企业数据库。虽然诞生于阿里巴巴和蚂蚁金服的业务场景，但并不仅仅是为电商和金融定制的数据库。OceanBase是原生的分布式数据库，其高可用、弹性伸缩和负载均衡能力有着独特的优势。OceanBase通常被归类为NewSQL数据库，以兼容MySQL和Oracle为目标。
OceanBase的里程碑事件：
OceanBase起源自2010年。最早的时候，它并不是一个全功能的SQL数据库。起源的时候其实还是一个分布式的存储系统，主要的目标是支持淘宝里收藏夹的应用。
淘宝收藏夹是一个海量数据量、非常高访问请求的一个应用。随着淘宝用户量和淘宝商品量的不断增长，这个系统仍然运行在OceanBase上。而且经历了这么多年的沉淀，已经为淘宝收藏夹提供了非常完善的一个支撑能力，这实际上是一个很重要的里程碑。
当核心的分布式的数据存储能力和数据访问能力得到了基本的保障之后，OceanBase产品其实也在一步步增强和优化。
支持收藏夹业务的时候，OceanBase还是在阿里集团，后续随着业务的发展，我们在蚂蚁金服看到了更多的发展机会，所以后来集团决定把OceanBase的产品转到蚂蚁金服持续的发展。
到2015年、2016年的时候，支付宝上的所有核心交易的核心链路，已经100%完全承载在OceanBase上了。这之后OceanBase已经成长为一个非常全面，有强支撑能力，而且通过了极限考验的一个数据库产品。这也是一个里程碑。
在这之后，从2016年、2017年开始，OceanBase开始对外商用，也有越来越多的企业级客户愿意选择相信OceanBase，包括南京银行、苏州银行、人保财险等。在这些客户选择OceanBase后，其实在它们的互联网的系统里OceanBase已经发挥了非常重要的作用。这算是第三个里程碑。
Q8：OceanBase于2010年发V 0.1-v0.3、2011年V 0.4、2014年V 0.5、2016年闭源从1.0开始重构；2018年发布V 2.0，OceanBase数据库系统整体架构是怎样的？有着怎样的特点？
庆涛：OceanBase 1.0之前的版本架构上分为多个角色：主控服务器Rootserver、更新服务器Update Server、基线服务器Chunkserver以及合并服务器Mergeserver。系统内部按照时间将数据分为基线数据和增量数据，基线数据是只读的，修改都是产生增量数据，系统内部定期将基线数据和增量数据合并。1.0之后版本重构，架构上服务器只有一个角色OBServer，其内部会包含一个SQL引擎和存储引擎（负责存储基线数据和增量书），整个集群还有一台服务器会有总控服务。整个架构更清爽，服务器角色都平等，配置统一。2.0版本发布后在全局一致性快照上有突破，同时逐步兼容Oracle常用功能。
Q9：OceanBase在发展过程中应对了哪些业务挑战？相应的架构产生了怎样的演进？
庆涛：最大的挑战就是在海量的数据和并发访问下还要保证正确性、高性能和高可用。OceanBase从0.4版本就开始在核心业务里替换Oracle，成功后后面为了继续扩大成果，从OceanBase 1.0开始架构做了一次大的重构，目前到2.x版本，架构大体未变，相关功能细节得到业务打磨更加完善和稳定。
Q10：在过去的十多年里，蚂蚁在整个基础数据库架构上一共经历了三代升级，第一代架构构建在IOE基础之上，第二代是Oracle和EMC商业存储，加上蚂蚁自身的分布式中间件，第三代是由OceanBase为代表的金融级云数据库和分布式中间件所构成。数据库架构升级并非易事，可否从兼容性、迁移成本、性能、稳定性、数据质量等角度，就第三代而言，谈一谈OceanBase的是如何做的？
庆涛：兼容性方面业务需要做比较大的妥协。比如说去除对Oracle存储过程的依赖、避免多个大表之间的表连接、减少统计类查询等。使得OceanBase早期可以专注短平快的事务的性能、稳定性等。
数据迁移方面主要得益于相关中间件产品。比如说数据迁移服务DRC、数据校验服务AMG等。架构上还实现了在线迁移、灰度验证以及回滚机制等。
高可用方面一方面是OceanBase自身可靠性很高，故障切换时做到自动切换和不丢数据，另外一方面是蚂蚁业务架构根据业务特点设计相应的业务FO库（Failover），用于数据库服务性能下降或中断时，业务快速弹性切换到FO库，从而更快恢复服务。
Q11：结合您多年的工作经验，您认为OceanBase的优劣势是什么？
庆涛：OceanBase运维方面的优势是在数据库内部提供极致的弹性伸缩能力和高可用能力，还有跨地域部署多副本并保证强一致和随时切换的能力。这些为用户做数据库两地三中心（或三地五中心）的容灾和多活建设提供了极大的便利。
OceanBase吸引开发的地方就是自身也提供透明的水平拆分能力（即分区），兼容MySQL和Oracle常用功能。如果业务非常关注数据的安全性和性能，OceanBase是一个很好的选择。
OceanBase的缺点也有。目前主要是复杂的多表关联查询性能还不够好，此外存储过程、Package等还不具备生产环境使用能力。
Q12：OceanBase在生产数据方面有哪些别致的表现？
庆涛：主要体现在下面三个方面：
- 高可用：OceanBase节点故障后，只是该节点局部数据访问中断，此后迅速切换恢复且保证不丢数据。RPO等于0，RTO在30s以内。此外，即使在三地五中心架构下，也可以随时做机房间的数据库容灾演练。
- 可线性扩展：单集群的最大存储容量超过2PB，单集群最大机器规模超过100台。在双十一前后，可以快速在线针对大量集群做弹性扩容和缩容。
- 高性能：单张表最大容量突破3200亿行，并且大表之间可以连接访问(淘宝收藏夹业务)。蚂蚁双11所有OceanBase集群处理峰值高达4200万/秒，每秒交易峰值24w/秒。(2017年数据)。
Q13：目前您主要从事OceanBase对外输出的解决方案设计，可否分享下OceanBase走向商业化数据库产品的历程？
庆涛：OceanBase商业化到目前已经快两年了，一开始我们选择的是以银行为代表的金融行业，主要是面向中小客户，和蚂蚁金融科技整体方案一起，做基于云平台的输出；后来随着产品本身的不断成熟，我们也开始做面向头部客户的独立软件输出。到今天为止，我们已经在四大行，股份制行，头部的城商行、农商行，农信系统等都落地了许多案例。除了银行之外，我们在包括保险、证券等泛金融行业也取得了一些成绩，目前我们正在做面向非金行业头部客户的突破。
Q14：您认为互联网时代下企业级数据库面临着怎样的业务挑战？
庆涛：性能要求会越来越高、资源的弹性伸缩要求也会变多。部分业务还有异地容灾或多活的需求。
Q15：OceanBase用在了哪些业务场景？可否分享一些特别的案例？
庆涛：支付宝的会员、账务、交易、支付等跟交易有关的业务全部在OceanBase上。非金行业一个有代表性的案例即淘宝收藏夹业务也是跑在OceanBase上，淘宝收藏夹业务从0.3版本就一直使用OceanBase，集群规模最大曾经超过100台。这个业务特点就是数据量非常大（几百亿），收藏大表关联商品大表查询。
Q16：OceanBase也有自己的数据库集群管控平台OceanBase云平台，该平台的架构及组成是怎样的？
庆涛：OceanBase云平台由运维链路、监控链路、诊断链路、数据链路、高可用链路、基础设施等若干子系统组成。每个子系统又切分成数十个甚至上百个小服务，服务间弱依赖。
OceanBase云平台架构
OceanBase云平台有1.0和2.0两个版本：
- 1.0的版本架构跟互联网产品一样，包含很多开源组件（如Kafka、JStorm、HBase等），能够支撑很大规模的OceanBase集群性能数据采集和运算。缺点是对传统客户维护起来比较麻烦。
- 2.0后的版本重构了一下，不再依赖开源组件产品，整个程序只有一个Java程序和元数据库（独立的OceanBase集群），由OceanBase承担性能数据的运算。
03
OceanBase的兼容性和自动化运维
Q17：关于OceanBase和其他数据库的兼容性，以Oracle为例，据了解现在能达到20~30%的Oracle兼容性，可否详细说说？其他数据库情况是怎样的呢？
庆涛：Oracle常用的数据类型都支持，包括BLOB。常用的查询、修改SQL，基本的函数，还有一些复杂的统计分析窗口函数，全局Sequence等都已实现。存储过程简单的已经实现，功能还在完善。
Q18：可否简单说说OceanBase和Oracle、MySQL的相同和不同之处？
庆涛：OceanBase是单进程软件，集群化部署（至少三节点）。三节点下，每份数据（即分区）有三个副本，角色有Leader和Follower区分，默认Leader副本提供读写服务。每个分区Leader位置不固定，三节点没有主备之分，可以同时提供读写服务。三副本之间数据保持强同步，并在Leader副本故障时内部自动切换恢复服务，时间20s左右。
OceanBase对资源管理支持多租户模式，租户和集群可以分别在线独立扩容和缩容，期间数据迁移是OceanBase内部逻辑，迁移期间保证数据强一致和服务高可用。
OceanBase的数据读写是基线数据（只读）加增量数据（只写）结合，没有Undo。内存资源比较关键，每天定时有一次基线和增量数据大合并。在大合并之前如果增量内存使用超过阈值会触发冻结和转储逻辑（释放增量内存）。OceanBase通常只有在转储和合并的时候才会写磁盘，所以对SSD寿命非常友好。分布式数据库可能会跨节点传输数据，网络流量会非常大，需要万兆网卡。
Q19：业内已有诸多的分布式数据库，腾讯TDSQL（DCDB）、阿里DRDS和PetaData（HybridDB for MySQL）、MariaDB Spider、PingCAP TiDB、SequoiaDB、亚马逊Aurora和阿里PolarDB，相比较之后OceanBase的市场位置在哪?
庆涛：市场上分布式数据库通常有两类。一类是原生的分布式数据库，分布式细节功能实现都在内部完成，另外一类是分布式数据库中间件，底层数据存储还是传统关系型数据库（主要是MySQL）。
OceanBase目前客户多是金融场景，以及两地三中心容灾或多活场景。随着后期产品功能的加强和市场运营的推广，未来将在更多行业进行布局。
Q20：数据库在一定规模的时候可以人肉，对于上规模后需要各类的工具平台，可否分享下您对自动化运维的理解，以及OceanBase在自动化运维方面如何做的？
庆涛：自动化运维需求最早是在MySQL场景下出现的。分布式MySQL规模上去后，自动化运维可以提高效率。但是由于MySQL自身的设计并不能严格保证不丢数据，所以MySQL的高可用有一定比率会失败，需要运维介入处理（比如说修复主从同步中断或数据不一致问题）。当整体数据库集群规模很大的时候，这个运维处理工作量也不小。
此外，分布式MySQL的扩容和缩容可能涉及到数据的迁移，这个也需要借助MySQL原生的主从同步或者外部工具实现，也不能严格保证数据强一致。OceanBase把运维中最重要的两个要求RPO和RTO做到产品内部，不需要运维介入，这个就有一定程度的自动化了。
OceanBase云平台主要是做很多OceanBase集群的自动化运维。比如说集群搭建、重启、升级或扩容、下线，以及监控告警、性能诊断之类事情。
04
技术从业者如何学习分布式系统？
Q21：您撰文谈及“现在提分布式数据库的优势，必然是成本低，扩展性好，性能不够就加机器。但是业务真上了分布式数据库才发现并不一定如此。”为什么？还有什么其他分布式数据库的经验分享？
庆涛：所有分布式数据库通常都具备水平拆分能力和弹性伸缩能力，这是不错的，说的是产品有这个能力。但是应用能否发挥出产品能力就看怎么用了。分布式架构在性能方面的优势靠的是扩展性，通俗的说用更多的服务器去应对更大的数据量和更高的访问量，这是一个分而治之的思路。
所以水平拆分是关键，通常有两种思路。一是无业务规则的拆分，在存储层面拆分，对业务透明；二是有业务规则的拆分，业务需要制定拆分列（或分区列）。前者对业务完全透明，后者这个分区列的选择就需要根据业务特点综合考虑。通常无论怎么选都不可能满足所有业务场景，业务架构需要有所取舍。如果做的不好，自然有些场景性能就会不好。
此外针对SQL特点。如果是并发少的大查询，同时调动多个甚至全部节点能力参与计算，其性能自然好。但是如果并发非常高，每个SQL都要调动多个甚至全部节点能力参与计算，集群节点很容易就到达性能瓶颈，这个SQL的吞吐量也就到了瓶颈。所以更好的情况是每个SQL只需要调动某个节点的局部的资源参与运算，所有节点同时提供服务时业务吞吐量最高。这类业务通常称为OLTP型业务。
所有分布式产品的性能都会受跨节点请求延时影响。即使网络延时限制降低到很多，并发量高时这个延时总的影响也是不可忽视的，尤其时机房节点相隔很远的时候。所以当有表连接的时候，我们更希望做连接的相关数据存在同一个节点内部或者同一个机房内部，这时候水平拆分支持业务规则对业务又会更实用一些。
Q22：技术从业者该如何去学习分布式系统方面的知识技能呢？
庆涛：个人建议先了解一些数据库基本的原理和使用特点。比如说事务、高可用。然后了解一些分库分表的原理介绍和案例分享和问题（这方面资料相对比较多一些）。最后可以看一些使用Paxos协议做强同步的分布式数据库产品的介绍。
Q23：最后，OceanBase好学吗？推荐一些资料吧。
庆涛：OceanBase 1.x版本兼容MySQL SQL，2.x版本新增Oracle兼容，这个对业务开发比较友好。对运维而言，OceanBase的一些运维命令语法像MySQL。如查看数据库列表show databases，查看表结构show create table，查看会话show full processlist，查看租户变量设置值show global variables。有些命令像Oracle。如查看集群参数设置show parameters。以及一些内部管理和性能相关的视图命名以gv$开头，SQL诊断方面参考了Oracle AWR的设计经验。相信无论之前从事的是MySQL还是Oracle，在OceanBase里都会找到熟悉但又不完全一样的东西。学习OceanBase将是一件很有趣的事情。
