六年三次架构迭代，OceanBase 单机分布式一体化会是大势所趋吗？

Posted 2023-04-01 OceanBase数据库官方博客

本文选自 InfoQ《中国卓越技术团队访谈录》（2022 年第四季），此次采访，希望能够将 OceanBase 具有创新性的技术演进历程展现在读者面前，让开发者和业内人士更加深入了解与 OceanBase 数据库有关的一切。

 

基础软件是个需要漫长时间积累才有可能沉淀出结果的领域。作为三大基础软件之一的数据库技术，没有十年以上的深耕和积累，很难在巨头林立的国际市场砸出水花。

我国数据库技术相对于欧美国家起步较晚，大约始于七十年代中期。1977 年 11 月，由中国科技大学在黄山主办了第一次数据库技术研讨会，标志着中国数据库软件产业进入了技术跟踪期，其后经历了三十多年的发展，中国数据库软件产业相继经历了强势垄断期、创新发展期，最终进入了目前的产品成熟期。

 

OceanBase 六年演进历史

 

2009 年，淘宝发起了“双十一购物节”活动，使得瞬时数据呈爆炸式增长，传统单机数据库很难应付峰值时的海量数据，这也就有了 OceanBase 诞生的土壤。

2014 年，OceanBase 数据库的自研工作取得了一定成效，研发团队将支付宝交易业务中 10% 的任务量迁移到了 OceanBase 上，这是整个核心业务使用 OceanBase 迈出的第一步。对于业内来说，也是核心业务使用国产数据库的一个 0 的突破。

2016 年，OceanBase 数据库发布了架构重新设计后的 1.0 版本，支持了分布式事务，提升了高并发写业务中的扩展，同时实现了多租户架构，这个整体架构延续至今。同时，到 年“双 11”时，支付宝全部核心库的业务流量 100% 运行在 OceanBase 数据库上，包括交易、支付、会员和最重要的账务库。

至此，阿里巴巴实现了数据库自由。

2017 年，OceanBase 数据库开始试点外部业务，成功应用于南京银行。

2018 年，OceanBase 数据库发布 2.0 版本，开始支持 Oracle 兼容模式。这一特性降低应用改造适配成本，在外部客户中快速推广开来。

到了 2019 年，OceanBase 数据库 2.2 版本参加代表 OLTP 数据库最权威的 TPC-C 评测，以 6088 万 tpmC 的成绩备受瞩目。随后，在 2020 年，又以 7.07 亿 tpmC 刷新纪录。OceanBase 数据库是第一个也是截止目前唯一一个上榜 TPC-C 的中国数据库产品。

2021 年，OceanBase 数据库 3.0 版本基于全新的向量化执行引擎，在 TPC-H 30000GB 的评测中以 1526 万 QphH 的成绩刷新了评测榜单。这标志着 OceanBase 数据库一套引擎处理 AP 和 TP 混合负载的能力取得了基础性的突破。

在 2021 年一个特殊的日子——六一儿童节，OceanBase 数据库宣布全面开源。

经过多年的发展，在 8 月举行的 2022 OceanBase 年度发布会上，版本代号为“小鱼”的 OceanBase 4.0 正式发布，这是业内首个单机分布式一体化数据库，它实现了单机部署并兼顾分布式架构的扩展性与集中式架构的性能优势，不仅一举突破了分布式数据库单机性能的瓶颈，实现了单机性能赶超集中式数据库的行业历史性“跨越”。

OceanBase CTO 杨传辉在接受 InfoQ 采访时表示：“OceanBase 4.0 版本的发布，是我们对分布式数据库该怎样演进的一个重新思考。我们在这个版本上引入了一个一体化结构的理念，核心的目标是为了让这个产品能够通用，能够规模化地去支持大中小企业对数据库各种各样的需求，能够很好地适配在云环境中。从用户角度讲，4.0 版本与以往最大的不同在于它打破了分布式只能支持大企业、大体量数据的思维定式，让它也能够应用到中小企业中。”

 

步入 4.0，架构完成了第三次升级

 

随着大数据、5G 和 AI 的发展，目前市场上的许多数据库产品已经十分成熟。就拿单机数据库来说，如果数据量不是特别大，性能较好的单机数据库足以应付。

但是，当数据库数量变大以后，一些产品的缺点就暴露出来了：他们虽然采用了可扩展、灵活伸缩的分布式架构，但有些却连 SQL 都不支持；还有些虽然支持一部分 SQL 功能，也支持一些分布式的能力，但是这些 SQL 在设计时都牺牲掉了某些单机性能，用户在面临数据库选型时就会选入困扰——没有一款数据库融合了集中式和分布式的双重技术优势。

所以在迭代 4.0 版本时，OceanBase 研发团队瞄定了这样一个用户需求痛点，首次采用了单机一体化架构，在保证数据库可扩展、高可用的分布式特性后还不会牺牲集中数据库的优势。

在此之前，几乎没有产品能够做到在分布式的情况下还能保证单机性能足够好且能够实现小规模部署、灵活易用，这些都不是过去分布式数据库追求的目标。而现在通过动态的日志流，把集中式日志流的优势和分布式的扩展性的优势融合到一个方案里，最终形成了的单机分布式一体化架构的解决方案。

从最初的 1.0 演进到 4.0 版本，OceanBase 在架构上完成了第三次升级。最早的 OceanBase 0.5 采用的是单写多读的架构，到了 2016 年左右，蚂蚁集团主要核心业务就都用上了 OceanBase 数据库，于是 OceanBase 进行了第二次架构升级，完全采用了分布式架构。再到 2022 年，研发团队将架构进行了第三次升级，也就是现在的单机分布式一体化架构，每次架构升级都耗时六年左右的时间。

杨传辉坦言，“每次版本的迭代，比技术本身更难的环节是做决策。如何平衡成本和收益之间的关系，也是要考虑的问题，我们能够预想到所面临的技术挑战是非常大的。不过，我们对它的前景也是很乐观的，如果做这件事的收益足够大，大到甚至能够颠覆整个数据库行业的时候，我们就愿意去试一试。”

作为 OceanBase 高级研发总监的韩富晟，在这一点上深有体会。韩富晟表示：“我们决定做这件事情因为我们认为单机分布式一体化架构会是未来数据库发展的一个方向，因为它真正能解决客户的痛点。做了这样一个大的变革，对 OceanBase 自己来说也是一个颠覆，我们有 80% 的基层研发人员都投入到了 4.0 版本的迭代中。为此我们重写了底层架构，包括重写了存储模块、事务模块等，通过一系列重写保证了单机性能上的优势。”

 

下一代分布式数据库是什么样？

 

尽管在架构上进行了三次调整，但自 1.0 版本发布以来，OceanBase 走分布式架构这条路的决心从未动摇过。

最近几年，分布式数据库在国内发展较快。一方面，技术的发展还是由业务和需求驱动的，丰富的数据库应用场景，新一代信息技术与实体经济的深度融合，这些变化都给数据处理和存储的主要核心技术带来了前所未有的发展机遇。数据规模和数据使用复杂程度的提升，使得老旧的数据库形式面对当下许多应用场景时变得力不从心，分布式数据库成为了很多企业的必然选择。

杨传辉称：“对于很多企业而言，分布式数据库就好比现在的电动汽车。当电动汽车产业刚刚起步时，它的市占率是很小的，但是在经过了几年的发展后，我们可以看到，越来越多人在购车时会优先选择电动汽车而不再是燃油车。分布式数据库也是这样，未来分布式会成为一种能力，蕴含在每一代新型数据库里面，回顾过去也可以发现，集中式数据库都是老一代数据库，而新兴的数据库都是面向云的、分布式的架构，它们更加弹性、更加灵活。分布式就犹如电动汽车的引擎或者叫电池，未来企业做数据库选型时，只要选择的是新一代数据库，那么都绕不开分布式。”

 

分布式数据库最核心解决的问题是什么？

 

数据库本身是一个极其庞大的系统软件，它之所以能成为一个非常大的市场，就是因为它解决了企业业务中大大小小、核心的、边缘的不同业务场景的各种各样的需求。如果一款数据库都能很好的满足企业的各种需求，那么企业也愿意在数据库上投入更多成本，让企业的数据管理和使用更有效率。

归根结底，分布式数据库的本质还是数据库，它的存在就是要去解决实际业务场景里的各种处理数据的需求，包括首先要在同一个系统里去做交易处理和分析查询提供更有效率的结果赋能业务端；其次是扩展，解决研发团队按需扩容、不需要按照业务波峰额外准备硬件资源的问题；然后是高可用问题，集中式数据库的系统可用性很大程度构建在可靠硬件的基础上，分布式架构将高可用问题转变为软件解决。

 

与其他软件如何适配？

 

企业在部署数据库时，除了要考虑分布式数据库本身的问题外，还要注意其与其他基础软件适配性。

韩富晟提到，在 OceanBase 与其他软件适配过程中，遇到的最大挑战之一是多核心扩展性。目前很多企业采用的是以 ARM 核心为主的架构，与 x86 的核心相比，ARM 的单核心的处理能力会相对弱一些，需要更多的核心来去支撑更多的处理能力，这个时候就需要数据库具有更好地去适应 CPU 多核心扩展性方面的能力。此外，一些企业有硬件替换的需求时，比如硬盘、机器的交换机、CPU 等，OceanBase 的容灾能力也能帮助企业把这过程中出现的故障屏蔽掉，让企业顺利完成替换。

解决了分布式数据库自身问题以及适配工作后，是否意味着分布式数据库已经成为了主流数据库？关于这个话题，过去几年争议度还是比较大的。但随着大众对分布式的接受程度和诉求越来越强后，这些争议的声音逐渐弱了下来，并且分布式数据库自身也在朝着越来越实用、易用的方向演进。

据杨传辉判断，未来的分布式数据库将向三个方向演技：第一，从架构上来看，单机分布式一体化架构将是大势所趋。分布式数据库会成为一个类似电动车的电池这样的一个核心技术慢慢应用到整个数据库的领域，而不只局限在大数据这样的细分场景中；第二个方向是混合负载 HTAP，也就是在做好 TP 的同时也会把一些偏实时性的 AP 放到同一个场景里去；第三个方向是多云。未来的数据库一定会越来越往云上发展，云数据库会越来越中立。

 

数据库选型时要考虑哪些因素？

 

即便我们看到了分布式数据库在市场上备受追捧的现状，但企业在面临数据库选型时依然会在上百款数据库产品中摇摆不定。到底什么样的数据库是对业务有所助益的？分布式数据库选型可以从哪几个方面进行考虑？

在数据库选型过程中，首先最重要的考量因素就是它的稳定性和成熟度。因为数据库本身是一个功能繁多又极为复杂的系统，它的稳定性需要去实际业务场景中打磨和验证的，不成熟的产品，无论是软件还是硬件对于企业业务迁移的影响都是很大的。

其次，是产品的兜底能力。企业本身的业务也要发展、变化，在这个过程中，一定要有预防所有风险的能力。对于底层系统或基础软件来说，兜底能力就是不管遇到任何问题和异常，都能快速定位问题并解决问题，所以这背后一定要有一个技术过硬的团队来支撑。

第三，要评估这款数据库是否代表着先进技术的发展方向，是否能够持续迭代和改进，只有顺应技术潮流的技术产品才能走得更远，更有发展前景。

最后，要衡量这款数据库的一些具体性能，到实际业务场景中去测一测便可知晓。

 

耐不住寂寞，打磨不出好的数据库产品

 

在数据库选型过程中，要考虑数据库的稳定性和成熟度，还要看产品的兜底能力。而归根结底，这些技术能力的背后，还是要看到底是怎样一群人在支撑着这款产品。

在问及 OceanBase 在招聘工程师时，最看重他们的什么品质时，杨传辉坦言，是他们对一件事情的耐心和坚持。

数据库作为一款基础软件，其研发周期和困难程度相较于应用软件要漫长和困难得多。虽然近些年来互联网的兴起让手机操作系统 android、ios 也在快速演进，但也基本上是一年多才会发布一个版本，相对于 App 十几天、个把月就出一个新版本，还是要慢得多。

更多的技术，其演进过程都是非常漫长的。比如 IPv6，上个世纪开始，人们就开始焦虑 IPv4 地址会用完，但直到今天，还只是小规模在应用。HTTP 从 1.0 走到 2.0 也花费了快 10 年的时间，可见，做这些基础软件的研发，并不是那么容易，而从事基础软件研发的工程师们，也要耐得住寂寞，才能终有收获。

杨传辉表示：“在招聘时，我们比较关注应聘者对计算机基础知识的掌握、他们的学习能力，而不是他们的行业经验。从技术的角度来看，我们不怕一个人没有经验，因为他只要来到 OceanBase 团队，他会和这个行业里顶尖的数据库人才共事，能很快地跟着团队成长起来。此外，我还会特别关注他们是否真正有耐心能沉下心来钻研一件事，也就是要能耐得住寂寞，这个是进入 OceanBase 的必选项。那种只想快速取得成功、急于求成的人，我肯定不会要。因为这些人在 OceanBase 是没有办法取得他们想要的成绩的。能耐得住寂寞，说明他至少对这件事情是有坚持，有信念感的。这样他能在做这样一个世界级的技术项目里面收获更多快感。在 OceanBase 团队内部，很多人陪着 OceanBase 走过了十几年，如果不是情怀使然，很多人都留不下来。”

 

---

采访嘉宾介绍

杨传辉，花名日照，现任蚂蚁集团企业级分布式关系数据库 OceanBase CTO。2010 年作为创始成员之一加入 OceanBase 团队，主导了 OceanBase 历次架构设计和技术研发，从无到有实现 OceanBase 在蚂蚁集团全面落地。同时，他也主导了两次 OceanBase TPC-C 测试并打破世界纪录，著有专著《大规模分布式存储系统：原理与实践》。目前，杨传辉带领 OceanBase 技术团队致力于打造更加开放、灵活、高效、易用的下一代企业级分布式数据库。

韩富晟，花名颜然，OceanBase 创始成员 & 资深研发总监，负责 OceanBase 分布式架构与高可用架构的设计与实现，主导了 OceanBase 4.0 版本架构升级，致力于将分布式数据库技术带到更多使用场景，更好支撑海量数据的处理需求。

首发 | OceanBase 2.0 重磅发布，全面降低金融业务向分布式架构转型的技术风险

小蚂蚁说：

9月21日下午，在云栖大会ATEC数字金融架构转型分论坛中，蚂蚁金服OceanBase团队的资深技术专家蒋志勇正式宣布OceanBase 2.0重磅发布！并为我们深入解读了OceanBase 2.0的产品新特性和重大技术突破点。下面小编就带大家一起来看看OceanBase的前世今生以及本次发布的精华内容。

关于OceanBase的背景，请点击阅读：

《》

《》

前言

OceanBase是一款完全自主研发的金融级分布式关系数据库，超过100万行的核心代码都由OceanBase团队的同学一行行敲出来。

从2010年立项到今天，过了8年；在最近4年多时间里，一直服务于金融核心业务。2014年，OceanBase开启了支付宝核心业务去Oracle的进程，在当年的“双十一”，支撑了10%的交易流量；最终在2017年，成功完成支付宝交易、支付、账务、会员等全部核心业务的去Oracle的工作。这在中国乃至全球都是一个标志性的事件。

对比一下美国的情况，前段时间有报道称亚马逊准备在2020年彻底去除对Oracle数据库的依赖，立刻引来了Oracle创始人的反击，他表示亚马逊已经尝试过很多次，但从未成功，足以见得去Oracle这件事对于企业而言的难度之大。

同样在2017年，OceanBase和蚂蚁金融科技的其他产品一起帮助南京银行建立了互联网金融核心系统。从去年开始截止到今天，OceanBase已经在6家外部金融机构上线，包括商业银行和保险机构。全球前三名的支付平台，两家的核心系统都在使用OceanBase数据库。

为了满足业务快速发展以及持续可用的要求，系统架构从集中式转向分布式是大势所趋。在数据库层面，要相应地从单机数据库转向分布式数据库。

OceanBase 2.0版本发布

今天，我们发布OceanBase 2.0版本，这是OceanBase数据库自身发展的里程碑，也是我们参与金融行业向分布式架构转型的关键一步，用数据库技术创新为业务架构转型奠定基础，解除行业发展的后顾之忧。

在架构转型过程中，技术决策者往往会碰到三大挑战：

第一大挑战：技术风险

第一个是技术风险，传统单机数据库系统经过几十年的发展，运行在可靠的专用硬件和存储上，在金融行业得到充分锻炼，整体稳定。分布式数据库系统运行在普通商业硬件上，采用廉价存储，运行环境和传统方式有很大差异，保证系统可用性和可靠性的手段也大不相同；同时在某些基本行为方面和传统单机数据库也有差异。比如要获取一个系统一致性快照，对单机数据库是一件很轻松的事情，但在分布式系统中，却没那么容易。如果不能提供一致性快照，业务系统就被迫要做相应的改造和调整，调整就会带来风险。可以说：对于一些基本特性，分布式数据库系统相对于传统数据库的每一个行为上的差异都增加了架构转型的不确定性，很有可能就是在转型的道路上埋了一个雷。

第二大挑战：迁移实施成本

传统数据库是功能的集大成者，分布式数据库由于发展时间较短以及分布式架构自身的复杂性，在功能上比传统数据库有所欠缺。如果缺少的正是业务系统需要的功能，往往就要通过修改业务系统来解决。除了系统改造成本，还有运维成本，人员知识结构更新带来的成本，等等。

第三大挑战：新产品的质量和服务

最后一点是新产品的质量和服务能否满足金融业务的要求。数据库产品和其他产品的重要差异在于它关乎企业的核心数据资产。数据库新产品的质量不能仅仅依靠测试报告来保证，而是要看有没有经过实际业务的长期锻炼。对于应用过程中出现的任何问题，技术研发和服务团队有没有能力限期解决。

上述的三个问题，是技术决策者需要思考和解决的。

OceanBase 2.0的发布，在一定程度上就是为了解决上面的三个问题，减轻技术决策者的决策风险。今天的报告分成如下六个部分，分别介绍OceanBase2.0在减少分布式架构对业务的影响、提高数据可用性、增强运维能力、提升性价比和产品兼容性方面的进展，最后还会谈一谈2.0版本在今年“双十一”大促中将要承担的任务。

业务透明的分布式系统

对分布式数据库而言，如果对业务能表现成一个具备动态伸缩能力、功能完备的高可用单机数据库，那基本上就达到了向业务屏蔽分布式架构复杂性的目标。把分布式架构实现的复杂性留给了自己，把便利性提供给了业务。为了这个目标，OceanBase 2.0版本实现了全局一致性快照，支持了全局索引，丰富了负载均衡策略。

1. OceanBase的整体架构

先来看一下OceanBase的架构，从1.0版本就确立下来的对等节点无共享存储分布式架构。集群中的每一个节点都是对等的，包含完备的SQL、事务、存储引擎，负责管理一部分分区，并响应客户端的请求。

在所有的节点中，有部分节点承担了集群全局性的管理功能，图例中的Root Service节点，略微有点特殊，但是这个管理能力是其他节点都具备的，在必要的时候可以随时接管。

为了高可用，数据通常有多个副本，分布在不同的可用区，图例中部署有三个可用区，单节点故障、单可用区故障都不会影响系统和数据的可用性。在9月20日ATEC主论坛中演示的“三地五中心”高可用架构，在发生城市级故障的时候数据不丢失，26秒恢复业务，用的数据库就是OceanBase。OceanBase也是云数据库，单个集群服务多个租户，租户之间数据和资源隔离。

2. 全局一致性快照

在没有实现全局一致性快照之前，分布式数据库在功能上是有比较大的欠缺的。有两个典型问题：一个是无法实现跨节点的一致性读，另一个是无法保证因果序。

无法实现跨节点的一致性读，对于应用系统设计和开发人员是很有挑战的，他们得保证在一条SQL语句中访问的多个表、多个分区都在同一个节点上，否则这个查询就会出错。

无法保证因果序的一个表现是：用户在两个事务中分别修改了位于两个节点上的两张表，先修改了源表，再改了目的表。但在另外的一个观察者看来：后修改的表已经在查询中反映出来了，但源表还没有变。这对于依赖操作顺序的业务系统，简直是个灾难。

OceanBase 2.0版本实现的全局一致性快照，从根本上解决了这些问题。相对于Google Truetime基于原子钟的硬件实现，OceanBase的全局时间戳（GTS）服务是纯软件实现的。不依赖特定的硬件设备，也不对客户方的部署环境提额外的要求，使得OceanBase能够服务更广泛的专有云客户。

全局时间戳（GTS）服务是系统的基础服务，该服务的性能和可用性对系统有很大的影响。OceanBase 2.0的单个全局时间戳服务1秒钟内能够响应2百万次以上的时间戳获取请求，满足单租户百万级TPS的要求。在系统满负荷运行的情况下，对性能的影响不超过5%。时间戳服务的高可用机制和数据分区高可用机制相同，后者在过去几年中经历了支付宝生产系统严苛的检验，非常稳定。

2.0版本的全局时间戳服务缺省打开，跨节点读写、因果序的行为和单机数据库完全一致。对于数据都集中在一台机器上的小租户，或者对性能有极致要求的租户，可以选择关闭自己的全局时间戳服务。

3. 全局索引

全局索引是单机数据库的常用功能，在分布式数据库中比较难实现。对于分区表来说，全局索引的价值在于为不带分区键条件的查询提供一种性能提升手段。在没有全局索引的时候，不带分区键条件的查询性能是比较差的，要在每一个分区上做一遍这个查询，而大部分分区上根本没有满足条件的记录。

我们看到，有些业务不能接受这么长的查询响应时间，就会创建另外一张表来模拟全局索引的功能，这个额外创建的表的维护就会带来很多问题，数据一致性、以及在何种情况下使用这个表都需要应用系统去管理。

全局索引功能将业务从这些问题中解脱出来。在全局索引的创建和使用上，OceanBase都基于代价做选择，在创建的时候，可以基于基本表，也可以基于另外一个索引。大表的索引创建通常耗时较长，对于大规模的分布式系统，设备故障也并不少见，为了提高创建索引成功率，在发生错误的时候采用子任务级别的重试。

对于查询优化器来说，何时采用哪一个全局索引也是基于代价计算的，目前索引回表查询是通过在计划上生成基础表和全局索引表的连接操作来实现的，代价模型也和一般查询相同。对有全局索引表的DML和查询操作很容易产生分布式查询和分布式事务，为了提升性能，在实现上做了很多细节优化，比如对于分布式查询，将任务的粒度从之前的分区级提升到节点级，以便减少RPC的次数。

4. 负载均衡

在负载均衡方面，2.0版本丰富了均衡策略。租户内的负载均衡让该租户上的工作负载能比较平均地分配在租户的多个节点上，对于数据装载和分析型的查询，可以有效地减少响应时间。此外，还可以设置租户间的亲和关系，实现将负载高峰出现时段相同的租户分布在不同节点上，峰值时段不同的租户分布在同一个节点上，充分地利用系统资源。除了提供给用户可配置的手段，负载均衡还结合CPU、Mem、存储等资源的使用情况，在负载差异超过阈值的时候，自动平衡节点间的负载，简化运维操作。

数据持续可用

在9月20日下午蚂蚁金服副CTO胡喜的主题演讲中，演示了OceanBase三地五中心城市级故障无损容灾方案，树立了金融核心业务高可用新标杆。

这一场三地五中心方案的现场演示是我们1.4版本支持的特性。在提升数据可用性方面，2.0版本也有了显著改进，索引实时生效、闪回查询、在线分区分裂，这三个新特性，每一个都解决了业务使用中的痛点。

1. 索引实时生效

了解OceanBase之前版本的同学都知道，索引生效和每日合并是强绑定的，普通索引的生效要经过一次每日合并，唯一索引要经过两次。有的时候，索引创建失败了，业务还不知道，造成了很大的困扰。

在2.0版本中，索引创建和每日合并解耦，索引基于数据的一个全局快照创建，再合并后续的变更，创建成功即可使用。如果出现错误，也能及时给用户反馈，提升了用户体验。通过先在一个数据副本上创建索引，成功以后再通过复制的方式生成其他的副本，避免同时在多个副本上创建索引造成的系统资源浪费。支持创建全局唯一索引，进行全局唯一性检查；在数据一致性校验方面，和之前的版本一样，会检查索引和表中的相同列的一致性。

2. 闪回查询

闪回查询功能，可以指定查询某个历史时间点的数据，对减少用户误操作造成的影响很有帮助。假如用户不小心删除了一些有价值的数据，可以通过指定删除之前的时间点来查询之前的数据。

在OceanBase的实现中，内存中的修改记录原本就是多版本的。为了支持闪回查询，要求转储到外存中的数据也要保留多个版本。至于保留多长时间范围内的版本，用户可以根据自己的需要进行配置，每一个表都可以按需单独配置。为了减少多版本转储对存储的压力，存储层也将数据编码和通用压缩应用在转储上，有效地减少存储消耗。同时，在执行查询语句时，如果指定了快照版本号，查询也可以在从副本执行，分担主副本节点的压力。

3. 在线分区分裂

另外一个提高数据可用性的功能是在线分区分裂，该功能对系统扩容很有帮助。在业务早期设计表的时候，对未来的增量很有可能预估不足，所以业务发展起来以后，就需要把单个分区再拆分，分成多个分区，再用多台服务器来服务这些分裂出来的分区，达到系统扩容的目的。

如果需要拆表的业务不能停服务，拆分操作就需要在线完成。在2.0版本中，分区分裂分成两个步骤，逻辑拆分和物理拆分，逻辑拆分是在表模式上把单个分区变成多个分区，完成表的元信息更新。物理拆分是把原先单个分区中的数据移动到新生成的分区中去。逻辑拆分在用户的DDL语句返回的时候就完成了，物理拆分是后台运行的。在物理拆分没有最终完成前，仍然会用到之前分区的数据。

在分区分裂的过程中，也控制了存储空间的使用，旧分区某一个宏块的数据全部被转移到新分区了，该宏块空间就被回收了。

在分布式系统中，分区大小对负载均衡、副本迁移、复制都有影响，把分区控制在较小的规格是有价值的。在线下OceanBase 2.0测试集群中，单个节点能够服务百万个分区；线上生产系统单节点服务十万个分区。满足分区拆分以及云环境下对单节点分区服务能力的要求。

可运维性增强

分布式数据库相对于单机数据库，无论是部署还是运维都要复杂一些，所以提高系统的可运维性也是2.0版本的一个重要目标。今天主要讲三个方面：DB Replay功能、在线升级以及新运维管控平台OCP2.0。

1. DB Replay

 DB Replay是一个很有用的功能，一方面可以降低系统升级的风险，另一方面也可以用来做压测，保障大促。DB Replay主要分成三个部分：线上流量抓取，要求不能影响线上系统的服务能力；第二部分是流量分析，因为真实系统的流量非常大，抓取的数据量也很大，对分析的性能要求高，同时为了更接近抓取时的Session并发情况，在并发语句相关性分析上，粒度是行级而不是同类产品通常采用的表级；第三个部分是流量回放，保持和线上系统同样的会话之间的关系，并且可以通过调整语句之间的时间间隔来放大或者缩小对系统的压力，达到压测的目的。

2. 在线升级

作为长期支持核心业务的数据库系统，对升级的要求就是平滑、可灰度、可回滚。版本之间的数据格式是兼容的，新版本的程序能理解老版本的数据。同时通过可用区轮转升级，可以做到在线升级；在升级的过程中可以灰度切流验证，在出现异常的情况下可以回滚，不会对系统造成严重影响。

3. 新版云管控平台

数据库运维管理一直就不是一件容易的事情，对于分布式数据库更是如此。“工欲善其事、必先利其器”。OCP（Open Cloud Platform）2.0就是一款专门用来管理OceanBase数据库集群的管控平台，通过OCP平台，可以一键安装、部署、升级OceanBase集群，监控集群的运行状态，创建和维护运维任务。

相对于1.0版本，2.0版本进行了架构上的改造，提升了服务的可用性，去除了对HBase、JStorm等外部组件的依赖，减少了最小化部署对服务器资源的消耗，从原先的3台物理服务器到2个Docker，非常适合对成本敏感的专有云客户。同时提供SDK供第三方定制管控平台。在服务能力方面，OCP集群能够动态扩展，每秒能够响应百万次的http请求，充分满足运维需要。

性价比提升

针对性能，我们主要做了两方面的工作：提交协议的优化和工程实现层面的优化。提交协议优化指的是对分布式事务二阶段提交协议的优化，在这一方面，目前在申请相关的专利，这里暂时不展开。在工程实现优化方面，我们做了大量细致的工作，包括内存分配、临界区、数据类型转换等。在降低存储成本方面，通过对静态数据进行编码，有效地减少了存储使用。通过这一系列的改进，在OLTP场景的实际应用中，2.0版本相对于1.4版本，性能提升了50%以上，存储下降30%。

兼容性提升

最后说说2.0版本的兼容性，我们花很大的力气做兼容性，就是要减少数据库迁移造成的业务系统改造，降低迁移成本，同时使得业务数据库设计人员、开发人员、数据库管理员原先积累的知识和经验能够在新系统中复用。

1. 两种兼容模式

在1.x版本中，我们主要做的是MySQL兼容。2.0版本支持两种兼容模式：MySQL和Oracle，目前Oracle兼容还比较有限，不久之后会有一个显著的提升。同一个集群中的多个租户，可以采用不同的兼容模式，在租户创建的时候指定，后续不能更改。对兼容性的要求，不仅仅是语法层面的兼容，还有语义方面、异常情况下的行为、并发行为、甚至于性能，都可以看作兼容性表现的一部分。

试想一下，同样的语句，新系统的响应时间是原系统的10倍，哪怕是语法兼容做得再好，也根本无法满足业务要求，又有什么用呢？

2. 存储过程功能

在功能方面，2.0版本实现了一个标志性新特性—存储过程。我们实现存储过程，有两个方面的目的：一个是兼容性，我们了解到，在传统行业中还是有不少系统是基于存储过程实现的。通过支持存储过程可以显著降低这部分系统的迁移成本。另外一个是高可用，通过使用存储过程，可以显著减少业务系统和数据库服务器之间的交互，如果业务流程的几十条、几百条SQL语句通过一个存储过程来实现，即便出现跨城的业务对数据库的调用，也不会对用户体验有明显的影响，系统的容灾将会更容易实现，稳定性也会更高。在为数不多的原生分布式数据库产品中，OceanBase是第一款支持存储过程功能的。

存储过程也支持MySQL、Oracle两种模式。如果业务不想让数据库来管理代码，也可以采用匿名块的使用方式，既有开发灵活性，又能获得存储过程带来的好处。存储过程采用LLVM编译执行，效率比解释执行高；支持基本调试功能，方便对大规模存储过程的开发和调试。

OceanBase 2.0的第一个“双十一”

作为阿里系的产品，不经过“双十一”的考验是不完整的。今年是天猫的第十个“双十一”，也是OceanBase 2.0经历的第一个“双十一”。

虽然刚刚出道，也要堪当大任。2.0版本将要承担一大部分支付宝的核心业务，同时，借助于2.0的在线分区分裂技术和全局索引功能，业务核心表要实现拆分，从非分区表拆成若干个分区表。

今年大促的峰值流量预计会大幅增加，但数据库服务器的成本不能增加，要靠提升数据库性能来帮助实现“零新增成本大促”这个目标。

听到这里，大家应该明白了，2.0版本所做的技术创新和产品改进，都来自于业务的真实需求，也会很快接受业务的检验。这是推动OceanBase数据库不断向前发展的原动力，也是OceanBase区别与市场同类产品的最大不同。我们输出到外部市场的产品都是经过内部业务严格检验过的，每年的“双十一”大促都是对OceanBase数据库独一无二的压力测试。

最后，以OceanBase 2.0相关的几个数字来作为结尾：

“1”  

第一个支持存储过程的原生分布式数据库系统

“30｜50”

存储减少30%，性能提升50%

“100万”  

单台服务器的分区服务能力达到100万个

“200万”  

单个租户GTS服务能力达到每秒200万次

OceanBase 2.0技术交流群

想了解更多 OceanBase 2.0 特性？

想与蚂蚁金服OceanBase的一线技术专家深入交流？

扫描下方二维码联系蚂蚁金服加群小助手，快速加入OceanBase技术交流群！

— END —

蚂蚁金服官方唯一对外技术传播渠道

投稿邮箱：[e-mail]

欢迎留言及个人转发，媒体转载请联系授权