杨传辉：深挖 OceanBase 背后的技术逻辑，助力数据库核心系统升级
数据库是信息社会的基础设施，通过开放开源助力数据库技术的快速发展，构建新一代数据基础设施是大势所趋！在“2021 云栖大会 . OceanBase 原生分布式数据库论坛” 上，OceanBase CTO 杨传辉为大家带来了一场主题为《OceanBase 一体化架构助力核心系统升级》的演讲。
01 核心场景背后的一体化架构技术
演讲开始，杨传辉从核心场景背后的一体化架构技术谈起，列举了用户使用分布式数据库时的两类需求并做了解释。第一种是分布式、扩展性、高可用需求，第二种是对数据库本身功能和性能的要求。
当前，很多客户业务发展很快，因此每隔一段时间就需要对数据库进行扩容。尽管经典数据库采用 IOE 架构，基于高可靠硬件做容错，但是即使使用大机也可能发生故障，且发生故障时只能等待厂商恢复。另一方面，经典数据库中的备库只是用来做读取，甚至某些备库只做故障恢复没有办法做写入，造成了大量的资源浪费。
而大多客户只想要一个数据库，在一套系统里一并支持 OLAP 和 OLTP ，并保证数据分析操作不会影响在线交易的业务。同时在一家公司的多个部门之间，数据库不会产生干扰。当某个部门数据库出现问题时，比如说写的 SQL 不稳定，不会影响其它部门。
在对客户需求进行分析以后，杨传辉谈到当前数据库领域最大的趋势——融合。这里的融合指的是分布式和数据库的融合，当下的分布式数据库已经进入了第三次迭代期。
最早一次迭代是分布式存储系统，当时被叫做 NoSQL。因为很难保证跨机分布式事务的高效性和强一致，所以最早的做法就是牺牲一致性，牺牲 SQL 来换取分布式的扩展性和高可用能力，那时候只支持 NoSQL。当 NoSQL 发展到一定阶段，大家发现它不再好用，还是 SQL 更符合人类思维，此时第二代分布式数据库诞生，本质是在第一代 NoSQL 的基础之上，引入了 SQL 语法支持，支持一些基本的 SQL 功能，也被称为可扩展的 SQL 处理，但牺牲了单机性能和成本，且很难应用到核心场景。
发展到第三代时，最大差别就在于兼顾了分布式的扩展性和单机性能。尽管第三次迭代的底层还是原生分布式架构，但是它对外体现的是与经典关系型数据库相同的使用方式，追求单机性能极致，最终做到单机性能和延迟与经典集中式数据库基本相当，并且对“ HTAP ”进行了深度挖掘，从而满足了核心系统要求。
最早的数据库没有区分 OLTP 和 OLAP，无论是关系模型、事务模型还是代价优化器，都没有针对 OLTP 或者 OLAP 场景。然而，早期数据库采用集中式架构，随着用户和应用场景不断增多，数据库的处理能力成为瓶颈，于是有了把数据分析从数据库中拆分出来的做法，并引入了 OLAP 和数据仓库这两个概念。随着云计算和分布式计算的不断发展，可以通过分布式架构不断提升数据库的处理能力，于是又有了把 OLTP 和 OLAP 融合在一起的趋势，这也就需要把国外提出的 HTAP 理念在中国作进一步创新结合。
02 完全自研+融合核心场景的核心优势
杨传辉进一步阐述了一体化架构充分融合分布式和集中式架构的优势。
一方面它的底层仍然是原生分布式架构，可以永远在线无限扩展，且不需要考虑容量和服务器故障，所有硬件问题都由软件做处理和容错，基于分布式架构之上对外体现更加符合用户使用习惯。与经典数据库兼容的 HTAP 架构、单机性能和延迟与经典数据库也基本相当。
对于一体化架构的核心理念，需要开发者开放心态充分把分布式、云计算最新技术融入到我们的数据库里面，同时站在数据库几十年的发展基础之上再做创新。杨传辉进一步强调了 OceanBase 的核心技术理念：坚持完全自研、坚持原生分布式、坚持核心场景。因为原生分布式一定要重视性能，完全掌控内核，应用到核心场景才可以代表未来。
目前，国内的数据库产品主要有两条研发路线：第一是基于开源做二次开发的主流路线；第二则是完全自主研发的路线。两条路线各有优劣，基于开源做二次开发，其好处是刚开始投入成本比较低，但后期发展会面临瓶颈，完全自研则可以完全百分之百掌控内核，做出有灵魂的数据库，但前期投入成本特别高，周期甚至长达十年二十年。
杨传辉以 OceanBase 现身说法：“刚开始的初心是要做比 Oracle 更为强大的下一代分布式数据库，那么走开源路线肯定做不到。开源数据库离 Oracle 这样的商业数据库有很大的差距，也不具备分布式能力，要做出比 Oracle 更加强大的企业级分布式数据库，开发必须要完全掌控内核。”
“时至今日，回过头来看很幸运，因为自研这条路线很正确。2017 年，蚂蚁集团将所有数据库完完全全由 Oracle 迁移到 OceanBase，那个时间点也正是 OceanBase 自研系统的能力开始超过开源数据库的转折点，OceanBase 数十年成长历程积累的内核掌控能力，正在不断拉开与基于开源做二次开发的数据库的技术代差。”杨传辉感慨道。
03 从技术层面解读原生分布式架构
对于 OceanBase CEO 杨冰曾在多个场合提及的“把简单留给用户，把复杂留给数据库”，杨传辉也此从技术层面作了解读。
OceanBase 的原生分布式架构涉及三个关键特性：坚持强一致、坚持动态扩展、坚持单机性能。 OceanBase 的强同步配置可以做到事务提交没有数据丢失，且当服务器发生故障是也能自动容错，保证持续高可用，这也是真正的原生分布式数据库的理念，我们也不会在 PoC 的时候做一种配置，在正式生产的时候用另一种配置。原生分布式架构对应的一个方案就是基于中间件分库分表，二者最大的差别在于原生分布式架构支持动态按需扩展，基于中间件分库分表方案只能做人工静态扩展。
从扩容方面来看，OceanBase 所有的扩容不是双倍或四倍扩容，而是按需扩容；因为不是静态扩容，所以不需要 DBA 做大量人工运维操作，只需要增加服务器就可以，所有扩容操作由数据库后台自动处理，且可以确保扩容时不会影响在线服务。以支付宝双十一实践为例，双十一峰值压力是平常的几十倍，通常需要在双十一前几天完成扩容，双十一完成后尽快下线。这样的操作涉及到上万台数据库节点和几十万个数据库变更，OceanBase 都能在小时级自动完成，不需要人为变更，大大提高了效率。
正如杨传辉提到的：“OceanBase 坚持核心场景，走从 OLAP 到 HTAP 的发展路线，始终相信应用才是数据库技术的第一推动力，一个数据库最终能不能做好，有没有很多应用来使用，关键要看有没有核心场景打磨。OceanBase 在不断实践中进一步触及到金融、互联网等其他行业，在这个过程中，我们最大的竞争力就是稳定可靠，这不是某一个技术指标可以衡量，而是通过多年打磨的内核掌控能力。今天很多核心场景已经开始使用我们的国产数据库，毫无疑问，面对新场景不可能不出问题，但我们的团队有信心可以解决这些问题。”
而怎么做出稳定可靠的系统，需要涉及的点很多，从架构设计，到研发，到写代码都需要兼顾，因为任何环节出现问题，都可能导致核心场景的重大故障，从设计角度来看，两个技术点需要特别关注——数据的正确性和运行的连续性。
杨传辉在分析 OceanBase 的天然优势也提到：唯一一个在数据库内核里面持续校验数据正确性的系统。即使出现 bug，也可以在线下模拟运行时通过校验能力发现风险及时完善。OceanBase 在生产环境中经历过极端异常场景的长时间检验，每年双十一大促都会有多台服务器发生各种类型的故障，OceanBase 总是能够自动处理。业内某个非常大型的商业银行的某次 PoC 测试专门模拟了网络时断时续的极端异常场景，最终只有 OceanBase 通过了该项测试。
04 核心场景持续运行 助力用户平滑迁移
今天的数据库，都有三个基本模块：存储模块、事务模块和 SQL 模块。我们谈到的一体化架构是相对分离架构来说的，为了实现分布式扩展性，一种比较简单的做法就是分离架构，把事务和存储分离开来，只需要在存储层实现分布式的扩展性和高可用，不涉及事务层。这种方式的好处是实现简单，问题在于额外增加了事务层与存储层的一次 RPC 调用，且分布式事务的 overhead 大幅增加，在架构上牺牲了性能和延迟，无法应用到核心场景。一体化架构把存储和事务有机地融合起来，在事务层实现分布式的扩展性。这种做法的好处是架构上没有牺牲性能，通过代码实现的不断追求极致，最终能够做到单机性能与集中式数据库基本相当，能够应用到核心场景，问题在于实现复杂度较高。
核心场景持续运行的成长进程中，经常有服务器发生故障。尽管经典数据库一般会有主备模式做高可用，但这种模式理论上无法同时保证强一致和高可用。而 OceanBase 的原生分布式数据库系统在支付宝交易业务上，首次把 Paxos 协议引入了金融级数据库，并最终做到 RPO 等于 0，RTO 小于 30 秒。目前，蚂蚁集团已经实现了三地五中心的部署，而这个部署正是应用驱动出来的，蚂蚁集团早期在杭州部署三个机房，突然有一次施工同时挖断了两条离得比较近的光纤，两个机房同时中断，造成服务不可用，于是后来我们把架构变成了三地五中心。
此外，OceanBase 还可以通过分区技术实现在线扩容不停服务，当我们处理能力不足的时候可以动态增加服务器，以分区粒度把数据迁移到新增的空闲服务器上，最终做到按需扩容，不影响业务。双十一的时候也不需要人为操作，可自动实现在云上做弹性扩容。
OceanBase 实现了 DataBase as a Service（DBaaS）架构，在数据库内部实现多租户之间的隔离，从而提升部署密度，降低运维成本。OceanBase 的存储成本很低，通过在线极致压缩技术，最终在蚂蚁做到存储成本只有 MySQL/Oracle 的 1/3。另外，与经典数据库不同点在于，所有节点都是可读可写，避免了资源浪费。OceanBase 每年都会持续做性能优化，最新的 3.2 版本相比上一个 2.x 大版本 sysbench 读写性能提升了 61%，延迟降低了 34%，其它只读、只写等各个场景也有不同程度的提升。
为了实现平滑迁移，除了透明分布式跟语法兼容能力以外，杨传辉提到了一站式迁移工具，包含两个工具：一个是数据库迁移服务 OMS，提供迁移能力的同时支持数据的回流，一键切流，反向同步数据，发生任何问题可以切换回原系统。另外一个是 OMA 评估源数据库的 SQL、存储过程、对象、Schema 等语法兼容性。我们在某个大型客户迁移了上千万行存储过程的代码，基本做到了平滑迁移、无缝替代。
在演讲的结尾，杨传辉宣布 OceanBase 3.2 版本正式发布，作为 3.0 发布会之后第一个大的商业版本，主要包含五大核心技术升级。（详情可跳转《OceanBase 3.2 正式发布 | 更硬核的 HTAP，TPC-H 性能提升6倍！》）
正如杨传辉所说：面向未来，我们还是会坚持将原生分布式数据库应用到核心场景，并且在核心场景基础之上拓展更多场景，最终提供分布式数据库坚实技术底座。一方面，针对核心场景，提升并发性能降低延迟，增强 MySQL/Oracle 兼容性；针对通用场景，持续提升 HTAP 能力，支持列存，适配更多 OLAP 生态工具。另一方面，通过开源发展更多用户，坚持把内核完全开源作为我们的长期方向。最终的目标是让每一个用户都能简单地使用 OceanBase，让每一个用户都可以快速获取蚂蚁集团 11 年数据库技术积累。
往期推荐:
企业级原生分布式数据库 2020.05.06 加入
github：https://github.com/oceanbase/oceanbase 欢迎大家
评论