分布式关系数据库OceanBase与TiDB哪个更好 _OceanBase

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

文章插图

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

TiDBTiDB 集群架构如下图，主要介绍其中 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有不同的解决方案。