（关注“数据库架构师”公众号，提升数据库技能，助力职业发展）

背景

2021年6月1日，蚂蚁集团开源 OceanBase 代码，这款连续两年占领 TPC-C 榜首的数据库产品再次拥抱开源。而此时，在开源社区国产数据库的赛道上还有另外一位明星选手：TiDB。同为关系型数据库，两者都采用分布式架构，具备可扩展、高可用、兼容 MySQL 的特性，相同特性背后两者的实现却大相径庭，各有考量。接下来将对两者架构、特性与性能方面做一些介绍，希望能对业务了解、选择与使用上有一些帮助。

架构OceanBase

OceanBase 的核心集群架构主要包括 ObServer，ObProxy 2个模块，如下图所示：

ObServer 为核心模块，提供存储（使用自研 LSM-Tree 存储引擎）、事务处理、集群管理等功能。从上面架构图可以看出，OceanBase 按 zone 属性聚合 ObServer，集群中包含若干个 zone，我们可以把 zone 理解为一个地区，数据中心或者机房。OceanBase 使用分区表管理数据，普通表或者分区表的一个分区在各个 zone 内都存在一份副本，其中主副本负责处理 SQL 请求，并通过 Paxos 协议同步数据。此外 OceanBase 包含租户的概念，提供资源管理功能，如下图所示，租户资源由若干个资源池组成，单个资源池包含若干个相同规格的资源单元，租户拥有的资源单元分布在不同的 ObServer 上，同一 ObServer 上的资源单元互相隔离（目前支持 cpu 与内存），租户创建的分区分布在租户管理的资源单元中。ObProxy 提供集群代理服务，主要功能是高性能转发 SQL 请求。简单的解析 SQL 获取目的分区，根据路由规则和路由表转发请求到合适的 ObServer 节点。TiDB

TiDB 集群架构如下图，主要介绍其中 TiKV, TiDB, PD 3个模块。

TIKV 负责数据存储，底层使用基于 LSM-Tree 结构的 RocksDB 存储引擎存储 k-v 数据。集群中包含若干个 TiKV 节点，单个 TiKV 节点包含若干个数据分片的副本，TiDB 对 kv 按照区间范围分片（称为 Region），单个 Region 包含特定数量的副本（称为 Peer），其中主副本（称为 Leader Peer）处理读写请求，通过 Raft 协议同步数据，对外提供 k-v 事务读写接口。TiDB 为 SQL 层，对外暴露遵循 MySQL 协议的端口，负责解析并处理客户端 SQL 请求。TiDB 解析 SQL 转化为 k-v 请求，从 PD 模块获取时间戳以及 Key 所在 Region 信息，然后作为两阶段提交的协调者处理 SQL 请求，TiDB 自身无状态，集群中可以部署多个 TiDB 服务分摊客户端请求。PD 为集群元信息管理模块，除了管理 Region 信息，为 TiDB 提供时间戳等功能，PD 还是集群的“大脑”，通过调度 Region 副本与主副本在 TiKV 节点间的分布，保障节点负载均衡、Region 健康，为了实现高可用，集群内可以部署多个 PD 服务，并且建议为奇数个。特性可扩展

随着数据量的增加，单机数据库不得不面对计算、存储能力不足的问题，传统的分库分表方案在解决问题的同时也引入了新的问题：对业务使用不透明，具有侵入性；跨库 SQL 语句受到限制；跨库语句难以100%保证事务特性等，针对这个问题，OceanBase和TiDB有不同的解决方案。

OceanBase 中 zone 提供主控服务，负责整个集群的资源调度、资源分配、数据分布信息管理以及 Schema 管理等功能。现在 zone 中添加 ObServer 节点时，节点资源会被总控服务管理供租户使用，集群的计算、存储等能力得到水平扩展。此外 ObServer 还支持租户级别的可扩展特性，修改资源单元的数量与规格即可完成租户能力的水平扩展。就单表而言，业务在建表时需要指定分区键（分区键必须是主键与唯一索引的子集）与分区方式（支持 Hash, Range 和 List 分区，支持二级组合分区）。不同的分区，可以分布在不同的数据节点上，通过分区可以提高系统的可扩展性，可管理性，以及性能。目前的最新版本尚未支持分区分裂的特性（已咨询OB开发人员，得到反馈该功能正在开发中，预计12月完成），所以目前属于静态分区方式。此方式在极端场景下（未进行合理分区），可能会使得系统的扩展性降低。但实际上，OB与WTable、WList的数据分片方式类似，在绝大多数线上场景下，都是可以具备便捷的水平扩展性的。TiDB 对底层 k-v 按区间范围分片（称为 Region），当分片包含的数据量达到一定大小时会触发分裂，我们可以简单地认为集群管理的 Region 数量没有上限，那么集群的数据量也就没有限制。此外当我们向集群中添加/删除 TiKV 节点时，PD 会调度 Region 分布，尽量保证各节点 cpu，磁盘，io 负载均衡，因此调度完成后，集群的计算、存储能力是得到水平扩展的。

从上述分析可以看出，OceanBase与TiDB集群均具备水平扩展的特性，此外 OceanBase实现了租户资源管理功能，支持租户的水平扩展，具备按需分配的能力，但是当前版本静态分区的方式对业务使用不够透明，需要在建表的同时确定合理的分区方式和分区数量；而TiDB Region自动分裂的特性，使得其内部数据切分对业务是透明的，使用起来较为方便，但在实际测试过程中，也会遇到少数Region分裂造成服务性能抖动的现象。

高可用

单点故障时单机数据库不得不面对的又一难题，传统的主从方案具备一定的可用性和容灾能力，但是并不完全可靠：备机故障时，主备同步会从最大保护模式（实时同步 Redo-Log）切换到最大性能模式（异步同步 Redo-Log），带来丢失数据的风险；主机故障时备机一般主动切换为主（避免脑裂问题），需要人工干预，这样则存在较长时间无法提供服务的风险。TiDB 与 OceanBase 均能规避单点故障问题，提供恢复时间目标 RTO <= 30s 及 恢复点目标 RPO = 0 最高级别的灾难恢复能力。

OceanBase 使用 Paxos 协议同步数据，同样允许半数以下节点故障。此外前面我们提到了 zone 的概念，OceanBase 支持添加删除 zone 等操作，基于 zone 的管理操作 OceanBase 很容易实现同城多机房、两地三中心以及三地五中心等部署方案，实现跨机房、跨地区的容灾能力。TiDB 使用 Raft 协议同步数据，允许半数以下节点故障，故障节点主副本所在 Region 重新选主恢复读写能力，备副本由于 Region 存在半数以上存活节点读写正常，后续 PD 还会主动调度失效的副本到正常节点上，保证 Region 健康。此外 TiDB 支持设置隔离级别（跨数据中心、机房或者 Host），后续 PD 会根据集群拓扑信息调度迁移 Region Peers 以满足设置的隔离级别。

Raft 与Paxos 都是生产环境下广泛使用的协议，都具备半数下节点故障的容忍能力，此外两者都支持对 Region（或分区）副本实现跨机房、跨地区或跨主机的隔离，比较而言 OceanBase 按 zone 组织 ObServe 的实现方案更加简单直观，便于业务使用。

兼容 MySQL

为了降低业务迁移与使用成本，TiDB 与 OceanBase 都高度兼容 MySQL 协议与语法，TiDB 文档宣称 100% 兼容 MySQL 5.7 协议、MySQL 5.7 常用功能及语法，OceanBase文档则声明兼容 MySQL 5.6 绝大部分功能和语法，两者文档中都对 MySQL 不支持或者实现有差异的功能特性做了说明。

对于 MySQL 事务特性，TiDB 与 Oceanbase 均支持分布式事务。两者参考 Google Percolator 实现两阶段提交，基于多版本并发控制为事务提供可重复读与快照隔离两种隔离级别，详细介绍可以参考 TiDB 文档、OceanBase 文档。

性能

TiDB 与 OceanBase 都在官方文档中给出了压测方案与性能数据，但是两者给出的机器配置不同，这里使用公司机器搭建集群进行压测获得了一些性能数据供大家参考了解。

压测环境

TiDB 使用5.0.0版本，OceanBase 使用3.1.0_CE社区版本，Sysbench 使用1.0.20版本。OceanBase 租户分配资源36个逻辑 CPU + 100 G 物理内存，TiDB 调整 RocksDB 缓存 100G。测试数据规模为16张表，单表1000万行数据，每次测试跑300秒。

机器

型号

服务

10.10.1.1

S04

TiKV、TiDB、PD、Sysbench

10.10.1.2

S04

TiKV、TiDB、PD、Sysbench

10.10.1.3

S04

TiKV、TiDB、PD、Sysbench

10.10.1.4

S04

ObServer、ObProxy

10.10.1.5

S04

ObServer、Sysbench

10.10.1.6

S04

ObServer

只读测试

只读测试中单个事务中包含5条 SQL语句，分别为1次主键查询与4次主键范围查询（分别获取字段，字段和，字段排序以及字段排序后不同值），压测 QPS 数据如下，不难看出 TiDB 仅在32线程下 QPS 高于 OceanBase，其余线程测试下OceanBase 最佳性能优于 TiDB。

写入测试

写入测试中单个事务4条 SQL 语句，分别为更新索引字段、更新非索引字段、删除行与插入行，压测 QPS 数据如下，OceanBase 性能一直优于 TiDB，最佳性能也在 TiDB 之上。

总结

上述测试只是一个简单的初步测试，后续我们会使用最新版本进行更全面与详细的对比测试。总体上来说，TiDB 与 OceanBase 按照各自的方案实现了可扩展、高可用的特性，并且高度兼容 MySQL 协议与语法。两者的一些区别包括：TiDB 底层 Region 动态分裂，单表计算、存储能力可以水平扩展；OceanBase 着重实现了集群资源管理功能，可为租户按需分配资源。OceanBase使用静态分区方式，在业务使用时需合理规划分区，以得到更好的性能以及扩展性。

后话

在2021年10月18日举办的DTCC 2021（第十二届中国数据库技术大会）中，OceanBase正式发布了开源3.1.1版本，新版本在原有性能优势基础之上，打通开源组件和开源的生态更好的协作在一起。譬如：支持 MySQL 5.7 驱动协议；开放了 TABLE API 接口让 OceanBase 数据库拥有 NoSQL 的能力，提供 KV 数据库访问能力；开放 CDC 接口，提供 OceanBase 对外数据同步接口；同时，新版本支持 20 多个生态工具，支持 Docker 部署，实现全量和增量的数据迁移。接下来我们也会对最新版本进行进一步的性能测试。

在DTCC大会上OceanBase进行了专场分享，其中也包括美团、哔哩哔哩、携程等公司都分享了他们使用OceanBase的经验及心路历程。OceanBase方也表示了其认真做开源、持续投入开源的决心和愿景。

如果这篇文章对你有帮助，还请帮忙点赞、转发 以下，你的支持会激励我们输出更多高质量的文章！

如果你还想看更多优质文章，欢迎关注我的公众号「数据库架构师」，提升数据库技能，助力职业发展。