2022 年 12 月 14 日~16 日，由 IT168 联结旗下 ITPUB、ChinaUnix 两大技术社区主办的第 13 届中国数据库技术大会（DTCC 2022）在线上隆重召开。大会以“数据智能 价值翻新”为主题，上百位技术首领齐聚云端，进行多维度、多视角、多层级的交换碰撞，为宽广数据畛域从业人士提供一场年度技术盛宴。

OceanBase 首席架构师杨志丰（花名：竹翁），在主论坛带来题为《OceanBase 4.0：单机分布式一体化的技术演进》的演讲，和业内分享 OceanBase 从 0.5 版本到 4.0 版本的技术架构倒退与演变。

 

 

以下为 OceanBase 首席架构师杨志丰在 DTCC 2022 上的发言实录。

大家好，我是 OceanBase 的杨志丰，明天和大家分享的题目是《OceanBase 4.0：单机分布式一体化的技术演进》，次要内容更加偏差技术解读，探讨架构演进的同时，会与大家分享 OceanBase 对于单机分布式一体化架构的了解和思考。

在往年 8 月 10 日 OceanBase 年度发布会上，咱们正式公布了 OceanBase 4.0 小鱼，这个版本有一个形象的比喻叫做“小就是大”， 咱们心愿通过这个版本架构的变动，使得 OceanBase 能够从原来反对大型企业为主，真正走向中小型企业。 用户能够应用一个 OceanBase 数据库，在企业或业务倒退的不同阶段都能应用单个数据库，不必做迁徙。我明天将从技术的视角去分享一下这背地技术的原理是如何思考的。

 

12年，从OceanBase0.5到4.0

 

▋ OceanBase 0.5~3.0

 

OceanBase 从 2010 年开始研发，上面是 OceanBase 0.5 版本的整体架构图，彼时 OceanBase 分成存储和计算两层。上一层是无状态提供 SQL 服务的服务层，下一层是由两种 server 独特组成的存储集群。

 

 

这样的架构可能使 OceanBase 比拟好的撑持相似于淘宝收藏夹的业务，具备肯定的扩展性，特地是读的扩展性比拟强，并且 SQL 层是无状态的，能够自在的伸缩。

但同时，这个架构面临最次要的问题是因为写入的节点为 UpdateServer 节点，其是单点写入、多点读的架构，会导致在更大规模并发要求下，没有方法进行扩大。

仅从这幅图上还有一个不容易被意识到的问题：咱们发现以这样一个形式去割裂存储层和 SQL 层之后会有一个很大的问题，查问时延不好管制。实际上网络服务很难管制时延，会有一些抖动，如果对时延要求极高状况下，很难管制时延抖动。

为了解决上述问题，OceanBase 摒弃之前的架构，倒退出了 OceanBase1.0 - 3.0 的架构，整体上来说是一个齐全对等的节点，所有的节点都能够在解决 SQL 的同时，处理事务并保留数据。在这幅示意图中，纵向方向是分布式可扩大层，横向方向是复制层。横向方向提供服务高可用能力，纵向是通过一直加机器去晋升整个服务的扩展性。

 

 

演进到 4.0 版本之前，原有的架构曾经有了十分好的扩展性。在这一扩展性下，咱们用 3.0 版本加入了 TPC-C 测试，OceanBase 是过后惟一一个通过了 TPC-C 测试的分布式数据库，也是惟一一个通过 TPC-C 测试的国产数据库，而且到目前为止放弃世界第一。

 

 

这也反映出 OceanBase 3.0 架构在程度扩展性上有十分好的适应性，如图能够看到，从三个节点到 OceanBase 打榜拿到了 7.07 亿 tpmC 指标的状况下，随着节点数减少，整个tpmC指标有十分好的线性扩展性。加入 TPC-C 评测时，OceanBase 通过 1557 台机器组成的大集群，在压测 8 个小时之内，每秒钟有 2000 万次事务处理能力。这个后果阐明，后面的架构是能撑持十分好的扩展性，简直这一扩展性和并发解决能力是能够满足绝大多数以后世界上在线服务零碎需要的。

 

▋ 引入动静日志流的 OceanBase 4.0

 

但随着业务需要的迭代，咱们还是倒退出了 4.0 架构，OceanBase 4.0 架构外围的变动，是引入动静日志流的概念。原来把事务扩大和存储扩大的粒度等同起来一起去看，但如果存储分成了若干个分片，导致事务处理和高可用能力也是以这样的分片为粒度的。咱们在 4.0 版本里把这两个概念进行理解耦，所以若干个存储的分片会共享一个事务日志流以及这个日志流所对应前面的高可用服务。

 

 

这一变动背地最外围的思路，是咱们心愿可能撑持更小的规模下的一些利用。比方蚂蚁这样大规模利用里，3.0 架构不会遇到瓶颈问题，但随着 OceanBase 走向通用，特地是各种各样的中小企业时，如果日志流的数目和分区数绑定到一起的话，在很多场景下是不能适应对中小规模企业撑持的。也就是说，如果日志流特地多，在越小规模下开销显得就会越大。

基于此，咱们有必要从以下几个方面对单机分布式一体化的概念进行解释：

  • OceanBase 单机分布式一体化数据库体系结构
  • OceanBase SQL 引擎的单机分布式一体化
  • OceanBase 事务处理的单机分布式一体化
  • OceanBase 单机的性能扩展性试验

 

OceanBase单机分布式一体化数据库体系结构

 

4.0 架构既能够通过分布式形式应用 OceanBase 数据库，也能够用大家原来相熟的相似 MySQL 单机形式应用 OceanBase。

第一，如果以单机形式部署 OceanBase，或者在 OceanBase 集群内部署单容器租户，都能提供原来应用单机数据库一样的效率和性能。

第二，如果应用分布式模式，在租户层面上、事务层面上以及单条 SQL 执行层面上，都不须要因为引入了分布式而付出额定代价。在这种状况下，须要咱们在 SQL 层、存储层、事务层各层设计上，以一种单机分布式一体化设计的形式去满足各种状况，在各个层面上做到兼顾。

 

▋ shared-everything or shared-nothing？

 

在数据库倒退的阶段有一个争执：数据库应该是基于无共享的集群去设计，还是应用 shared-everything 架构去设计数据库，才可能提供最好的效率？

 

 

当初理论的集群，从物理集群角度来看，既不是齐全 shared-everything，也不是齐全 shared-nothing。在每个机器节点下来看单个节点，也是多处理器的构造，很多 CPU，当初有 96 核机器，甚至更大规格的机器，内存也是越来越大，应用十分高速零碎内的总线去和磁盘、和所有外部设备去做交互，并且有很好的网络。所以事实应用的集群不能简略看作是 shared-nothing，就是单机内有十分强的计算和存储的解决能力，为什么不利用这样的能力呢？这也是单机数据库或集中数据库所有的 scale-up 的方向。分布式数据库不应该只思考程度的扩大，而不去思考垂直扩大的问题。

如果想利用硬件垂直扩大能力的话，数据库应该怎么做？能够构想一下有这样一种分布式数据库，以下方左图为例，这是当初很多分布式数据库的理论架构图，有点像 OceanBase 0.5 的构造，有专门的计算节点和存储节点。计算节点是一层，存储节点是另外一层，这两层做了独自形象，它们两头会通过 GTM/TSO 解决全局事务的模块，做多机交互时也须要和这个模块做交互。

 

 

如果把这一分布式数据库以非常简单的形式塞到了一个节点上，让它以单机的形式去运行，这里最大的问题是什么？就是这些组件之间的交互在单机内工作时开销十分大，这种开销实质上对于 MySQL 这样的单机数据库是额定的非必要开销，所以显然这样一种简略的形式是很难以和单机数据库相比的。

 

▋ 单机分布式一体化：兼顾单机和分布式场景

 

如果在单机内来看，单机内要有齐全独立的单机 SQL、事务和存储三层，绝对另外一种形式是所谓的分布式数据库会把分布式 SQL 引擎、分布式事务引擎和分布式存储引擎也看作是独立的三层。咱们心愿同时去糅合单机这三种引擎和分布式这三种引擎，应用同一套代码，甚至能够动静地去做变换和交互。

 

OceanBase所认为单机分布式一体化DB架构

 

除此之外，所谓单机数据库，要在单机内充分发挥扩展性能力，须要在 SQL 层提供并行执行的能力，须要在事务层去提供相似 MVCC 的扩展性核心技术，并且应用相似组提交的技术，使得单机内多个事务也能够并发去执行。在存储层，须要可能撑持单机并行的 IO，当单机内减少更多磁盘和存储带宽时，能够可能充分利用。

分布式内的单机数据库，不能简略把分布式的扩展性做好就行了，即便是以分布式形式去部署时，单机效率也必须是十分高的，须要可能高效去反对串行的执行，高效的执行在分布式事务的状况下，使得单机事务可能有自适应的优化。

对 OceanBase 来说，还独创引入了一个翻新技术——单机 LSM-Tree 存储引擎。如果以单机设计的视角去看的话，的确只能做前后台可能会相互影响的合并操作，但咱们不是一个单机数据库，如果真正是分布式部署的话，又能够引入一种分布式策略，使得多个正本之间能够做错峰轮转的合并。所以在整体设计上，在 SQL 层、事务层和存储层里，咱们每一层的设计都是兼顾了单机和分布式的场景，使得它在单机和分布式场景下都没有多余额定的开销，这是咱们的设计指标。

这样咱们就要求有 2 个根本个性：

  • 第一，在单机状况下工作时，OceanBase 没有额定其余的组件，就是一个单过程就能够工作，没有多余过程之间简单的交互。在单过程、多线程模型下，各个组件实际上都是应用简略的函数调用就能够实现交互，这是十分要害的一点。
  • 第二，所有的组件之间既在图里有纵向的交互，也就是 SQL 层、事务层、存储层。如果在单机内就用函数调用的形式去做交互；如果在节点之间，在必要时必须要有节点之间的交互时，才通过 RPC 去交互。

相应于后面所讲的 shared-nothing 和 shared-everything 联合的架构，实际上在每个 OBserver 节点外部，SQL 和事务存储之间都应用函数调用间接去交互的，这和单机数据库是一样的，当咱们要在多节点之间交互时，也会突破所谓严格的去做分层的，抉择最优的、最合适的、效率最高的计划。

例如，一个节点的 SQL 向另外一个节点上的 SQL 层发一个音讯，让这个 SQL 层再去拜访它的存储节点，这里最优的取决于你要做什么，不同的负载上面可能有不同的抉择，OceanBase 能够间接拜访一个近程存储。在事务处理层也是如此，如果单机事务下不须要和他人去做交互，就不须要和其余的事务组件进行交互。

 

 

OceanBase 执行引擎，要解决很多状况，为什么要做这么多细分呢？是因为心愿在每种状况下都能自适应做到最优。大的层面上来说，每一条 SQL 的执行都有两种模式：串行执行或并行执行。

 

 

▋ 串行执行-单机内并行-分布式并行

 

在串行执行时，如果这个表或者这个分区是位于本机的，这条路线和本机 SQL 的解决、单机 SQL 的解决是没有任何区别的。如果所拜访的是另外一台节点上的数据，有两种做法：把数据近程拉取到本机来，叫做近程数据获取服务。近程执行，如果单个事务内所拜访的数据都位于另外一个节点上，会把整个事务处理和存储拜访过程全副发送到另外一个节点上，将整个事务提交全副代理给它，而后再返回来；如果单条 SQL 拜访的数据位于很多个节点上，能够把计算压到每个节点上，并且为了可能达到串行执行（在单机状况下开销最小）的成果，还会提供分布式执行能力，即把计算压给每个节点，让它在本机做解决，最初做汇总，并行度只有1，不会因为这个而减少资源额定的耗费。如果是并行执行，反对并行查问，对并行查问分本机的并行和分布式并行，同时反对 DML 写入操作的并行。

对于串行的执行，个别开销最小。这种执行打算，在单机做串行的扫描，既没有上下文切换，也没有近程数据的拜访，是十分高效的。对于以后很多小规模业务来说，串行执行的解决形式足够。但如果须要拜访大量数据时，能够在 OceanBase 单机内引入并行能力，目前，这个能力很多开源的单机数据库还不反对，但只有有足够多的 CPU，是能够通过并行的形式使得单条 SQL 解决能力线性地缩短工夫。只有有一个高性能多核服务器减少并行就能够了。

 

 

针对同样模式的分布式执行打算，能够让它在多机上分布式去做并行，这样能够撑持更大的规模，冲破单机 CPU 的数目，去做更大规模的并行，比方从几百核到几千核的能力。

 

▋ 串行执行：DAS 执行和分布式执行

 

针对串行执行有两种执行形式：DAS 执行和分布式执行。

DAS 执行，形式之一是拉数据，如果数据位于近程，并且是简略的点查问或索引拜访回表查问，这种形式资源耗费是最小的，咱们会把这个数据拉取到本地，它的执行打算和本地的执行打算从模式上、形态上是没有区别的，在执行器里会主动去做这个动作。但有时候把数据拉过来，不如把计算压下去，所以咱们同时反对了分布式执行，须要强调的是这种分布式执行并没有额定减少资源的耗费，咱们会保障它的并行度和后面 DAS 执行是一样的。

对于某些特定的查问或大规模扫描，咱们会动静自适应抉择这两者，基于代价去评估哪种执行成果最好。

 

 

并行执行框架能够自适应解决单机内并行和分布式并行，它们是同一套框架。这里所有并行处理的 Worker 既能够是本机上多个线程，也能够是位于很多个节点上的线程，咱们在分布式执行框架里有一层自适应数据的传输层，对于单机内的并行，传输层会主动把线程之间的数据交互转换成内存拷贝。这样把不同的两种场景齐全由数据传输层形象掉了，实际上并行执行引擎对于单机内的并行和分布式并行，在调度层的实现上是没有区别的。

 

OceanBase 事务处理的单机分布式一体化

 

既然做扩展性更难的是事务处理，那么事务处理过程中为什么要兼顾单机和分布式？咱们从下图开始解释：

 

 

左图是传统的分布式事务处理过程，分成事务的开启阶段和事务的提交阶段，右图是 OceanBase 的事务处理过程。

OceanBase 事务提交协定提出一个新思路，叫做参与者既协调者的两阶段提交协定。OceanBase 两阶段提交比起左图，从提交事务到提交胜利这个工夫之内，咱们所解决的音讯量和写入的日志量比右边这幅图少很多，这使得整个两阶段提交的时延有很大的劣势，这个劣势也会撑持咱们前面要讲的即便是在 OceanBase 分布式场景下，事务的解决能力也不会像很多其余的分布式数据库一样开销十分大。

如果单个事务只波及到单个日志流，一般来说如果业务数据量在负载平衡可能容忍的粒度之内，日志流不须要特地多，很大概率上，齐全以单机形式去部署时，只有一个日志流，而一个日志流内任何的事务是不须要走两阶段提交的。

事务不能独立地去看，在一个分布式系统里可能既有波及到多日志流的事务，也有波及到单日志流的事务。两者之间是有关系的，对于单日志流事务来说，OceanBase 引入了独创的优化，使得 OceanBase 单日志流事务的处理过程中，不须要去拜访全局的工夫服务，只须要拜访本地特有的工夫服务，同时保障全局的一致性。

如果抛开分布式事务提交的协定来看，所有的事务以及整个工作负载都没有分布式事务的话，整个事务处理过程和单机数据库是相当的。

 

OceanBase单机的性能扩展性试验

 

上面的试验以三个节点的形式，也就是说节点和节点之间是正本的关系，实际上事务处理是单机实现的，就把它看作是单机，OceanBase 随着硬件性能的加强扩展性试验，从 4 核到 64 核，能够做到根本线性扩大的。从 90000、180000、370000、690000、1200000。在 64 核规模范畴之内，OceanBase 能够提供线性的扩大。

 

 

大家对分布式数据库有一个误会，或者很多分布式数据库可能给大家造成一个固有的印象：原来某单机数据库或集中式数据库，能够用一台机器撑持一个业务，引入分布式数据库当前，扩展性好了，但如果想反对同样的并发量，可能不得不应用三个节点独特来提供服务，能力达到单机同样的性能和效率。

 

 

这显然不是用户所心愿的分布式数据库。关键问题在于看性能时，不光要看吞吐量的减少，还要看单个 SQL 或单个事务从利用视角来看多快能解决完，因为事务处理从单个局部来看，咱们心愿实现的是随着分布式事务比例的减少，时延是在减少的，然而要害有两点：即便是由齐全的分布式事务组成，时延也须要足够低；以及当单机事务没那么多的时候，请不要买一赠一，给我赠送额定时延。

第一，SQL 层、存储层、事务层，即便在分布式场景下，也须要为单机粒度的事务和 SQL 做优化。

第二，如果三个组件之间齐全做了独立的分层，实际上用户是不足管制伎俩的，能不能不要发一个 RPC 去拜访一个数据，如何能放到一个节点上省掉这些 RPC。所以咱们心愿可能让用户和 DBA 在十分极致性能要求下有这样一个管制的能力。好比 OceanBase 为什么要用 C++ 去实现，就心愿能充沛管制内存，管制所有时延的耗费。能够把一个事件可能做准确的管制，可控性十分重要。同样咱们分区的能力也须要可能管制的，比方通过提供 Table-group，可能使得表之间没有分布式事务开销的。

 

▋ OceanBase 4.0 VS MySQL 8.0

 

如图，如果没有分布式事务场景下，以分布式状况下部署，单机成果到底怎么样？OceanBase 4.0 和 MySQL 8.0 企业版在同样硬件状况下做了比照，在硬件 32 核规格下，黄色是 OceanBase，从数据上能够看到，OceanBase 4.0 在雷同硬件环境下性能优于 MySQL，即便是小规模场景下，也能够释怀地应用 OceanBase 分布式数据库。

 

应用当前有什么益处？

 

传统应用 MySQL 主备库的形式有一个很显著的问题，就是容灾时会丢数据，这个问题无奈解决，而 OceanBase 首先必定能够做三机高可用，从 4.0 当前正式会举荐大家一种部署形式——每个 ZONE 里就有一个 OceanBase 的节点，叫做单机三正本，没有太多额定的开销。OBProxy 层提供了业务连接不断的能力，如果不须要这样的能力，能够像应用 MySQL 一样不须要部署 OBProxy，就能够达到比 MySQL 更好的高可用的能力。

比方最开始是齐全单机部署，业务做一些原型试验就够了。随着业务规模扩充，对于计算和存储的要求越来越高过程中，能够把这一节点做垂直的扩大，原来是 4 核，当初变成 16 核，如果在云上买，能够在 ECS 上间接申请晋升规格，OceanBase 是能够充分利用所有减少的 CPU，提供一个更好的性能。

另外一个维度是，如果当初不须要高可用能力，不想付出三个节点的老本，那么主备库就够了，OceanBase 同样能够提供主备库能力，这种高可用能力也是和传统的数据库相当的，主备库也是咱们的一个选项。

 

▋ OceanBase 多状态、动静可变

 

如果高可用能力要求越来越高，能够应用三节点。前面可能随着业务的倒退或企业规模的扩充，能够进化成一个残缺状态的 OceanBase 分布式数据库。更要害的是，这样一个状态的变换或扩大，外面每一个箭头都能够反方向去做，每一个箭头的变换都是动静失效的，不须要去替换 OceanBase 二进制，都能够全功能地在三种状态下应用，去做动静的变换。

 

![Image]()

 

▋ OceanBase 内仍保留原生多租户

 

咱们在设计 OceanBase 单机分布式一体化架构时，思考了一个问题。大家从应用 MySQL 到应用 OceanBase 有一个不适应的中央：OceanBase 有多租户的能力，大家进来须要创立一个租户，起初咱们和用户、客户做了很多探讨，最初确定多租户的个性即便是在单机状况下也是要保留的，特地是私有化部署和私有云部署时。

 

 

如果在私有化状况上来部署，很多小企业可能不想去部署简单服务器的环节，但当初买不到一核机器，有最小规格的硬件也有很多核，这种状况下如果不须要其余额定基础设施的话，OceanBase 的原生多租户能力，能够把一个机器切成很多个数据库来应用，毋庸额定的容器治理的零碎。

对于大规格来说，OceanBase 部署后能够做非常灵活的垂直伸缩。对于分布式显而易见，如果在分布式场景下，更是能够有垂直扩大和程度扩大两个方向的能力，并且这种能力是以租户为单位的。一个租户是 4 核×3 个容器，另外一个机器心愿以单机形式运行，能够间接给它 16 核，或者不心愿做分布式，都是能够的，此时，多租户提供了一个可治理的粒度。

对于私有云的部署，或者心愿在你的企业里一个OceanBase 大集群，就更有价值了。即便是小规格，比方一个 OceanBase 的 server 通过 16 核形式启动起来，但心愿有一个更小力度的租户，比方 0.5 核的租户。在数据库外部，OceanBase 是能够反对 0.5 核租户的，帮忙用户更加精密的管制老本，能够在云上做租户内垂直扩大，也能够租户间负载平衡，这两个维度都能够去做弹性、自在伸缩。

在不同的状态下，咱们都保留了 OceanBase 所有的性能以及多租户的能力。

 

写在最初

 

对用户来说，OceanBase 单机分布式一体化能力，有两个维度的价值和意义：

第一，OceanBase 既能够单机形式部署，提供单机数据库相当的能力，并且能够在任何时刻，管理员能够去做状态的变换，由一个单机的状态变成分布式状态，从分布式状态变回单机状态，都能够做动静变换的。

第二，即便是在分布式部署场景下，相较于其余分层的分布式数据库，OceanBase 的性能有很大的劣势，如果用户做精密管制的话，单机事务比例减少当前，效率和单机数据库也是相当的。

我的分享就到这里，感激大家对 OceanBase 的关注。谢谢大家！