导读开源数据库OceanBase（https://github.com/oceanbase）作为单机分

导读 开源数据库OceanBase（/oceanbase）作为单机分布式一体化架构的数据库，其OLTP的能力已经广为人知。实际上，由于原生分布式的特性，OceanBase早期版本就具备了较好的HTAP能力，并在版本有了长足进步，在近期发布的版本中又得到强化。本文将围绕OceanBase HTAP能力，从以下七部分解析其核心技术和功能特性，并披露相关性能数据。

【资料图】

全文目录：

1. OceanBase核心特性及技术架构

2. 执行引擎：OceanBase性能优化实现

3. 高级查询优化器：影响执行引擎效果

4. 存储引擎：决定行列混合存储效果

5. 资源隔离：防止TP业务与AP业务互相影响

6. 快速导入：Direct Path特性

7. 总结

8. Q&A

分享嘉宾｜张鑫 奥星贝斯 OceanBase开源架构师

编辑整理｜阿东同学 中国科学院大学

内容审核｜李瑶

出品社区｜DataFun

01

OceanBase核心特性及技术架构

1. OceanBase的发展历程

首先，介绍一下OceanBase的发展历程。OceanBase始于2010年，起初是淘宝内部的一个项目，旨在解决淘宝收藏夹功能的需求。直至今日，当大家使用淘宝的收藏夹时，存储后台仍然是OceanBase。OceanBase经历了十多年的发展，历经几个阶段。其中，第一个阶段是OceanBase的版本，着重磨练OceanBase的分布式能力。

在第一个阶段之后， OceanBase迎来了架构层面大的升级，也就是 版本，成为全分布式的多点写入的分布式型关系型数据库。从这一时间点开始， OceanBase进入蚂蚁集团。截止到 2016 年，蚂蚁集团和网商银行的全部核心系统，包括交易、支付账务都已经使用 OceanBase作为后台的业务处理数据库。到 2017 年， OceanBase走出蚂蚁集团，对外做一些商业化 。近两年，在互联网金融，特别是银行、保险、通信、能源等行业大范围推广，如携程等公司的核心系统已经采用OceanBase。

的核心特性

下面简单介绍一下 OceanBase的核心特性。

高性能。 在 2019 年和 2020 年分别做了 TPC-C 的打榜，无论在学术界还是在工业界，TPC-C 都是 OLTP 领域比较权威的评测标准。2020 年，以 亿 tpmC 的记录打破世界纪录，并在 2019 年的基础上提升了 10 倍的性能。

高可用性。 当少数机器出现故障的时候，OceanBase可以做到在 8 秒之内就快速恢复整个业务系统，保持整个业务系统的连续性。

高扩展性。 OceanBase不仅可以做水平扩展的分布式数据库，还可以做很好的垂直扩展，后面会有数据跟大家分享。在弹性方面，蚂蚁集团历年的双十一都非常依赖于 OceanBase来做弹性的扩缩容，在双十一的前一周，会把集群的规模扩到可以满足双十一当天高峰大促的并发的要求，然后在双十一过后，又可以快速地把资源释放出来，这是极致弹性的能力。

MySQL 和 Oracle兼容。 在用户接口方面，企业版 OceanBase同时支持 MySQL 和 Oracle 的两种兼容模式，用户可以在同集群里面创建，两种不同的租户可以同时工作。社区版 OceanBase目前只兼容MySQL模式，实际上底层是同一套存储引擎，由于是完全自研的，因此所有功能都是一体化的设计。

HTAP： 很多用户都知道OceanBase本身在 OLTP 这块的能力做得不错，并打破了 TPC-C 记录，印象中会觉得OceanBase是一款 OLTP 型的数据库。但其实，OceanBase是具备 TP、AP 混合负载的HTAP关系型数据库，OLAP能力在TPC国际事务处理性能委员会的TPC-H基准测试中刷新过世界纪录，并在 到演进过程中不断增强。

低成本。 OceanBase不同于传统的 B+树的存储引擎，自研的存储引擎采用 LSM-Tree，并且结合业务特点做了非常多的针对性优化。最具特色的一点就是数据压缩，同样的数据在 MySQL 和Oracle数据库上，OceanBase的数据库磁盘占用空间大概是传统的1/3 到 1/4，甚至有些场景可以做到 1/ 10。

原生多租户的能力。 在集群里面可以创建多个租户，服务多个不同的业务，这一层是在数据库的集群内部做的，不需要依赖于外部的虚拟化的一些机制，租户之间的资源完全隔离，并且后续可以随意扩展。

安全性。 支持透明加密、传输加密、安全审计等。

其它。 OceanBase在 2017 年开始商业化之后，大力发展周边生态工具。从企业的视角来看， OceanBase具备完整的从数据库开发到迁移，再到评估、运维及诊断的全生命周期的配套工具。

的整体架构

下图是OceanBase数据库的整体架构，它由若干个ZONE组成。每个ZONE有多个OB服务器，这些节点共同组成了一个完整的数据库集群系统。

在OceanBase数据库中，数据的表进行了分片，如图所示，P1、P2、P3等。每一个分片称为一个分区。同一份数据在不同的ZONE里会有多个副本。例如P1，它在第2个ZONE和第3个ZONE都有相同的数据备份。相同分片的数据同步是通过Paxos一致性协议进行的。

OceanBase在2020 年参加 TPC-C 评测时，整个集群由 1500 多个节点组成，是一个非常大的集群规模，如果业务不需要大集群， OceanBase也可以做到单机部署。

上图展示的是实际的生产数据，来自蚂蚁内部真实的业务系统。峰值的数据处理能力达到了 6100 万次每秒，单个集群规模超过 1000 台，单库有 6PB 的数据，最大一张表超过了 3200 亿行。RPO=0指的是在机器发生故障之后，保证数据不丢失。RTO < 8 秒，就是在少数机器出现故障之后，能够在 8 秒之内快速恢复业务。

这张图是OceanBase分别在2019年和2020参加TPC-C测评的结果。这里压测的亿tpmC数据，即每秒可以处理2000多万次事务。需要说明的是，这里的事务并非仅指数据库请求。

在TPC-C的模型中，有许多由复杂SQL语句组成的部分，因此综合吞吐量非常高。在这里，高并发处理能力体现在曲线上。在TPC-C评测中，要求程序以最高峰值平稳地运行两个小时，并进行两个小时的采样。在这两个小时的采样期间，整体性能的波动不得超过3％。OceanBase为自己提供了最高的标准，并进行了实际测评。从图表中可以看出，实际运行时间为8个小时，整体波动小于1％。在数据库或LSM-Tree架构中，抖动是个相当重要的问题。实际上，LSM-Tree存储引擎每次需要进行转储和合并，这通常会引起一定程度的抖动。然而，经过多年的内部打磨和外部用户实践的应用，OceanBase进行了大量的优化和改进，使得其整体平稳性能达到了极高水平。

此外， OceanBase是当时唯一通过TPC-C官方审核的分布式数据库，也是中国唯一通过官方审核的数据库。

在2020 年又参加了 OLAP 方面的打榜，即 TPC-H 的评测，以30000 GB 的数据拿了当时世界第一的结果。

大家可以看右边这张图，是OceanBase自己和自己的比较，从的版本和的版本相对于在联机分析处理(OLAP)这块的性能的对比，可以看到它的提升非常显著，整体以TPC-H为代表的OLAP能力也有了极大的提升。

现在对于许多复杂查询，人们普遍认为TPC-H相对简单，尤其是对于跨数据库的优化器来说，TPC-H对优化器的能力考验也许被视为次要的。因此，OceanBase在去年推出了版本，今年又推出了版本，下半年还将推出版本，进一步提高复杂查询和优化执行能力。

版本相比于之前的版本，在大小为100G的仓库上进行对比，整体性能提升了300秒，有了三倍的提升。现在版与版又有了更多的提升。

OceanBase整体性能提升的技术实现方式是什么？以下将简要介绍OceanBase执行引擎的能力。

首先，OceanBase的执行引擎在最初的设计中就考虑到了处理TP和AP的需求。因为从业务场景来看，很难区分查询是TP还是AP，也很难区分它是小规模查询还是大规模查询。因此，初始设计就要兼顾这两种情况。

大家对于MySQL可能比较熟悉，MySQL对于简单高频的查询处理非常出色，但在处理大规模数据方面仍有不足。然而，OceanBase从最开始就定位为分布式数据库，用户期望其具备大规模数据处理的能力。在执行引擎方面，OceanBase做了一些优化，既可以支持串行执行，也可以支持并行执行。串行执行主要面向TP业务场景，而并行执行则可以在多个节点之间进行并行查询，并且查询能力可以垂直和水平扩展。在TP领域中，时延是一个重要的指标，而不仅仅是吞吐量。因此，串行执行更多地针对TP进行优化。在串行执行时，数据有时需要跨机访问。因此OceanBase的执行引擎也有两种策略，一种是通过拉取跨机数据并使用数据拉取策略进行计算，另一种是将计算下推到下面的节点中，然后再将计算结果取回。这两种策略都是执行引擎支持的，具体如何执行取决于优化器的决策。

1. 并行执行调度

并行执行引擎将SQL查询计划拆分成多个分片，每个分片可能涉及多个数据。也可以拆分成若干子片，每个子片称为DFO，DFO组成整个查询的数据流。在并行调度时，可以将整个数据流划分为多个片段，相邻片段可以并行调度，逐步上传数据。当然，并行度可以根据用户自定义进行指定。

OceanBase是一个具有丰富并行查询策略的分布式数据库。举个例子，在AP场景中，数据会根据主键或分区键拆分成若干个分片，也称为分区。例如，R1和R2两张表，其中有a和b两个列。以b列作为分区键，表中数据会根据b列的哈希值不同分散在多台机器上。与单机数据库不同的是，OceanBase可以灵活地处理并行处理数据。

表的连接有4种最基本的方式。由于列b是分区列而a是普通列，因此如果对R1表的b列和R2表的b列做连接查询，可以将每个分片对应起来。因为分区策略是相同的，就可以分别对每个分区进行连接。这种方式被称为分区连接（partition with join）。在这种情况下，同一张表的分区之间不需要进行数据交叉。

如果是分区列 b 列和另外一张表的普通列a列做 join ，可以把不分区的 R2 这一列求哈希值以后根据它对应的在 a 表上的分区方式，把它 shuffle 到 R1 表的分区上面，这种方式叫部分 partition with join。

第三种情况是当完全使用a列进行连接时，由于没有分区，因此所有数据都存在于不同的分片中。此时，可以直接对所有a列进行哈希，然后在不同的机器上进行连接。

最后一种情况是当R2表是一张小表时，可以将该表广播到R1表的每个分区中，无论条件如何。这四种策略实际上都需要在优化时进行自动选择。

2. 自适应执行

自适应执行以 group by分组算法为例，比如要把上面的查询按照 b 列做分组，然后按照 c 列做求和，每个分组做求和的简单的查询。在分布式场景里面，可以在每个分区上先做求和的动作，然后再把所有的分区的计算结果聚合起来。

每个分区上做分组是否值得，主要取决于每个分区有多少个不同的 b 值。做聚合的时候，先要为表建哈希表，建哈希表其实是有代价的。比如 100 行数据，建了哈希表之后它还是有 100 个不同的值，那么建哈希表其实是浪费的，对数据的消减作用非常小。这在优化器来看是没办法决定的，因为聚合以后有多少不同的值，优化器预先是不知道，所以就需要做自适应的执行。优化器遇到这种场景会判断第一个分片上的消减作用是大还是小。如果消减作用是非常小的，那么在后面的分区上做的时候，就不需要再创建哈希表，而是直接把数据推到上一层，去做计算。这就是自适应引擎的策略。

在 OLAP 领域中，优化器的能力非常重要，执行引擎的能力有很多，用的好不好依赖于优化器是否能产生一个好的执行计划。经过多年的深入研究和实践，OceanBase 的优化器已经达到了非常高的水平，并在蚂蚁集团内部以及一些大型银行和保险公司的核心业务场景中得到了验证。对优化器的核心算法进行了精心优化，增加了许多专门针对特定场景的规则和策略。在 OceanBase 中采用了两阶段的方式生成执行计划，首先生成串行执行计划，然后在需要时对最优的执行计划进行并行化。

1. 一阶段分布式查询优化

这种两阶段执行计划生成方式存在一些问题。例如在下图中，从串行计算的角度来看，根据算法复杂度，AB执行计划的时间只需要100毫秒，因此执行计划被认为是更优的。然而，这并不意味着生成两个阶段的执行计划再并行化会得到最优的执行方案。

实际上还是需要考虑数据分布的情况，在例子中的R1、R2、 R3 这三张表，数据到底位于哪些机器上？即使在第一个阶段分析，看到耗时是更高的 150 毫秒的执行计划，但是因为它对于后边的排序，或者说数据的分布是有用的，因此需要把这个执行计划也保留下来，等执行编译之后再看最终的执行计划哪个更好。

所以这部分的优化，就是把之前的两阶段的执行计划变成一阶段，可以带来很大的好处，整体上在秒级别可以完成 50 张表的连接。

2. 并行下压

前文讲到的 group by 的例子是有下压的策略， OceanBase 的版本对于有一类的执行计划是不能够做并行下压的，在 之后可以完全支持，因为引入了三阶段下压的策略。

举个例子，就是一种带有distinct的聚合函数使用group by的情况。核心部分需要把数据查出来后，对不同的c值进行sum求和，并进行消重。但是因为需要对c列进行消重后再求和，所以无论有多少个分区，分区间并行都无法充分利用。因此，在版本中OceanBase采用引入了三阶段的下压策略实现并行。首先在每个分区上进行消重，然后再进行哈希，把每个分片上先在c列上消重，再将每片的1、2和3值聚合起来进行消重，这就是3号算子。接着在第二层上进行最后的求和操作，最后再进行整体的求和。这种策略对于一些复杂查询有着非常明显的提升。

前面讲的都是 SQL 引擎，下面来介绍一下 OceanBase的存储引擎，存储引擎对于这种 HTAP 场景影响非常大。这是 OceanBase整个存储引擎的结构，可以看到是比较简单的LSM-Tree 的结构。

1. 行列混合存储及编码压缩

数据存储可以被看作是有序的键值对，所有更新操作都以增量方式记录到内存中。在读取时，将磁盘上的数据、内存的数据和内存中更新的数据合并，提供读取服务。此外，还有块缓存和行缓存等各种缓存。定期整理增量数据和基线SSTable数据，进行合并，这是LSM-Tree的基本逻辑。

相对于使用"B+树"的存储引擎，LSM-Tree的最大优点就是它的整个更新过程没有随机写入。所有的插入和更新都先直接写入内存，相当于聚合大量的数据并按顺序写入磁盘。

为什么之前没有提出这个策略？这实际上与硬件的发展有很大关系。现在LSM-Tree这种存储引擎不仅适用于OLTP，对于OLAP方面也有很大的优势。其优点在于，它的基线数据只有在下一次合并时才会修改，因此，这部分数据在磁盘上可以高度压缩。

除了通用压缩，由于行列混合的模式，OceanBase的行列混合模式可以通过按列的方式进行压缩。数据表按数据分成多个Row Group，并按列的方式存储在磁盘上。因此，在磁盘上，每个数据块都是以列为紧凑的存储方式存储，这对于压缩非常有利。刚才为什么说“同一块数据从MySQL迁移到OceanBase可能有三倍的压缩率”？主要是由于LSM-Tree，在编码后，又进行了通用压缩，因此具有非常高的压缩比率。并且，它能够在线进行这种压缩算法，而B+树无法实现。OceanBase的好处主要在于LSM-Tree的后台整理数据的特性，因为SSTable的基线数据在下一次合并和整理时是后台处理的，而不是在用户执行插入操作时直接进行压缩。

可以想象一下，如果是 B+树，实时地做在线的压缩动作，其实对于压缩算法的要求是非常高的。如果把它变成后台动作，可以非常高效地做压缩，并且可以选择更好的压缩算法。

2. 查询过滤下压

又因为磁盘上是列式的存储，所以对于 OLAP 来说，这种大规模的数据扫描以及数据分析，可以把整个查询的filter过滤算子做下压，并且在不解压的情况下就做过滤。

比如，一个数据表有性别一列，通常只有男女两种类别。实际上，经过压缩后，男性和女性属性值只占用一个比特，从而可以实现高度压缩。在数据处理时，可以在数据字典上进行过滤，然后通过已压缩值进行高效处理，实现高效性。

此外，OLAP引擎经常采用的策略在OceanBase的存储引擎中得到了充分的体现。这也是因为OceanBase的存储引擎既满足了TP高并发低延迟的要求，又能够在大规模数据处理时充分利用列存的优势。因此， OceanBase是TP和AP存储引擎的完美结合。

前面都是讲存储引擎和执行引擎的逻辑，但在实际业务中，很多时候很难区分它是 TP 还是AP，在混合的场景下，大家会倾向于保护TP 的这些查询的资源，防止一些大的 AP 的查询争用资源，影响TP 的时延。因此引出了资源隔离的概念。

OceanBase本身是原生的多租户的数据库，前面介绍的架构其实比较简单，在其架构上层还有租户的概念。在OceanBase的集群中，可以有若干个租户，相当于虚拟的容器，每个容器可以看作是数据库的实例。这些容器主要限制CPU、内存和IOPS的使用。有了这项技术，就可以实现多租户，就做到了刚才所说的CPU和内存的隔离。同样的技术也可以用于HTAP，即TP和AP负混合负载的场景。因此，另外一项技术——资源组得以发展。

资源组的工作方式是什么？如果业务中既有在线交易作业，又有批处理作业，就需要以某种方式告诉数据库哪些是批处理作业，哪些是在线交易作业。简而言之，可以通过区分用户，并告知数据库哪些是批处理作业，哪些是TP类的业务。然后，根据这些用户绑定的资源组，可以控制总使用的CPU或内存不超过某个限制。

如果资源组隔离不足，也可以采取一些物理隔离的方法。由于数据采用多副本的方式存储，可以采用读写分离的方法，TP的请求访问主副本，分析查询则访问从副本。此外，还可以增加只读副本，专门用于AP分析。这些都是资源隔离的方法。

最后介绍一个小特性，即快速导入，主要针对一些 AP 的场景， AP型的系统经常需要和外部做一些数据的交互，所以在 的时候，专门做了快速导入 Direct Path特性。

数据库的导入有几种方式，第一种是“load data”，几乎所有数据库都支持它。另外就是通过 SQL 语句，直接从一张表中查询数据，然后将其写入到另一个表中。还有一种方式是通过 tableAPI 接口，可以使用外部客户端等工具将 CSV 等文件导入，在导入后，数据首先会记录到某个节点上，并在节点上进行分析。根据分区规则，将相应数据分发到相应的机器上。

在主节点内，如果在导入过程中表本身还有在线更新，可能会产生冲突。但在此类快速导入场景下，大多数被导入的表在写入时不会非常频繁。因此，基于这一特点，实际上会先锁定表的修改，并生成影子表。整个大规模导入期间表被锁定，读取仍然可以继续进行，但写操作被锁定。然后，在数据导入时绕过 SQL 层和 LSM-Tree 的内存层，直接生成最终的存储层，即列存储。前面也提到过它被称为 SSTable。同时，生成的数据还要与原始增量数据合并一次，以生成最终影子表，然后再进行切换。

旁路导入技术也在内部进行了实际评测。参见下图，第一个维度就是这张表是不是有主键，是不是按顺序排列；第二个维度就是机器的大小。从两个维度整体来看，首先因为有主键，会多一次排序，所以时间会长一些。整体来看利用了旁路导入的特性，导入的性能是有 4 到 5 倍的提升。

OceanBase作为原生分布式数据库，无论做 TP 还是AP，都有一些基础的高可用能力以及高性能的能力。OceanBase做了非常多的OLAP相关工作，包括大查询、复杂的分析查询，几十张表的join，以及支持各种窗口函数层次查询，还支持表函数，甚至可以支持自定义窗口函数等。从数据集成的角度来说，OceanBase支持DB link，可以把其它数据库的一张表的数据通过这种方式做查询。数据导入导出方面，在文中介绍了快速导入以及一些导出工具。

最后当前正在做外表的功能，将在下一版本中发布，欢迎关注，欢迎参与共建/oceanbase

以上就是本次分享的全部内容。大家如果感兴趣可以扫码加入以下社区答疑群。

08

问答环节

Q1:相同计算资源情况下， OceanBase和 Snowflake Doris Clickhouse 的查询性能对比如何？有没有发表过类似的测试的技术白皮书之类的资料，可以给到用户社区用户网上可以查看？

A：这块其实之前也有一些做过一些测试对比，但是如果从我们角度来说，肯定会说比其他产品测试下来的效果好，其实相比这些列存数据库整体性能是差不多的，但是具体的性能，还是用户自己测出来的效果会更有说服力。有一些用户有做过测试，相比 clickhouse 这些在 AP 能力其实是差别不大了。

测试白皮书这块目前还暂时还没有，用户可以根据自己的实际场景，做一些性能的对比测试。

Q2: OceanBase的安全性和高可用性稳定性如何？

A：这块其实大家可以放心一些，因为首先在刚才也有介绍到，在蚂蚁集团内部核心交易、账户系统等，这些支付宝的这些后台的数据库，都是 OceanBase，从很早开始就不断地用 OceanBase替换掉Oracle， MySQL，它的安全性、稳定性已经是经过很多年的验证。

高可用性目前因为本身它是这种分布式的数据库，原生的就是具备高可用能力，因为数据是通过 Paxos 一致性协议做复制，所有的数据提交都要保证多数派。如果少数节点出现故障的情况下，整个集群基本不会受到什么影响。

今天的分享就到这里，谢谢大家。