SMTX ZBS+OceanBase 性能测试，揭秘国产分布式存储+分布式数据库真实表现！

作者：SmartX 方案技术专家钟锦锌

OceanBase 是由阿里集团自研的企业级分布式数据库，得益于其高可用、云原生、强一致性、高度兼容 Oracle/MySQL 等特性，在金融、电商等行业得到了广泛应用。OceanBase 支持多种存储方案，不同的存储方案会对 OceanBase 的性能和可用性带来较大的影响；同时鉴于很多用户都很关心国产数据库的真实性能与调优方案，以下，我们将对比介绍 OceanBase 部署方案，并以 SmartX 自研分布式存储 SMTX ZBS 作为 OceanBase 的外部共享存储开展性能测试，为用户展示“国产分布式存储+国产分布式数据库”的真实表现。

测试结果

使用 SMTX ZBS 存储卷作为 Oceanbase 的外部存储不影响其性能横向扩展能力。
SMTX ZBS 冗余副本与 OceanBase 冗余副本叠加使用场景下，数据库性能不会发生明显下降。
附 SMTX ZBS 与全闪集中式存储作为 OceanBase 外部存储的性能数据对比。

下载《SmartX 产品在数据库场景下的测试与实践合集》，了解更多数据库场景性能评测！（扫码并关注“SmartX 用户社区”后将自动弹出电子书链接）

OceanBase 部署方案对比

OceanBase 数据库（简称 OB）采用无共享（Shared-Nothing）分布式集群架构，各个节点之间完全对等，每个节点都有自己的 SQL 引擎、存储引擎、事务引擎，运行在普通 PC 服务器组成的集群之上。

部署架构

1. 单机模式

OceanBase 虽是一款分布式数据库软件，但它支持单机部署，该模式下不支持数据库的高可用，且数据库性能也严重受限。因此，官方不建议在生产环境中使用单机方式部署。

2. 集群模式

OceanBase 集群是由 3 台或以上的服务器组成，业务访问请求会通过数据库的负载均衡组件分散至多个 OB 服务器节点中进行处理，充分利用多台服务器节点的运算能力提升数据库的整体性能。生产环境中 OB 也是以集群的形式进行部署为主。

部署硬件

1. 物理机部署

使用物理机部署 OceanBase 数据库集群在生产环境中是比较常见的：数据库服务直接运行在物理机上，计算资源损耗最小；对于数据库访问压力较大的生产业务系统，可最大化发挥服务器硬件的性能。

2. 虚拟机部署（运行在超融合/虚拟化平台上）

使用虚拟机部署 OceanBase 集群相较物理机部署虽有一定的性能损耗，但这种部署模式非常灵活，可大幅缩短部署时间，并有效减少服务器硬件投入。虚拟化部署可以降低用户使用分布式数据库的门槛，可以小规模起步，按需进行扩展。此外，用户通常也会在测试环境、准生产环境中采用虚拟机部署的模式。

存储方案

OceanBase 可使用本地硬盘，结合多副本为数据库提供存储服务；也可以使用外部共享存储为数据库提供存储服务。不同的存储方案对 OceanBase 数据库的可用性和性能都有着不同的影响。

1. 本地硬盘 + 多副本（OceanBase 的标准存储方案）

在 OceanBase 数据库中，为了数据安全和提供高可用的数据服务，每个分区的数据在物理盘上进行多份存储，每一份叫做分区的一个副本。数据库通过分区复制、日志同步等方式将数据复制到多个副本以防止数据丢失，确保 OceanBase 数据库在少数副本故障的情况下依然能够提供无损的数据库服务。

2. 外部存储卷 + 单副本

OceanBase 可支持单副本模式：该模式下，OB 本身对数据副本不提供冗余保护，需由外部存储解决数据冗余保护的问题。此外，由于 OB 是 Shared-Nothing 架构，数据卷本身也没有共享访问的机制，因此在单副本模式下，每个数据库节点只会存储和管理一部分数据，一旦某个节点发生离线，又没有冗余副本可以访问（虽然数据依然存放在外部存储，但数据库依旧判断这部分数据处于离线状态），导致数据库层面无法实现高可用。单副本由于不需要做数据副本的复制和同步，正常状态下性能会优于多副本部署。

3. 外部存储卷 + 多副本

这种存储方案比较特别：每台 OB 服务器节点都分别连接外部存储卷（存储卷自身有冗余机制），同时在 OB 层面也启用了多副本（副本冗余机制）；相当于存储层面有两重冗余机制，数据可靠性非常高，但存储硬件成本也会随之上升。

虽然 OceanBase 本身内置类似分布式存储的功能，但接入外部存储的方案在以下场景中仍有一定的优势：

对分布式数据库的运维不熟悉：接触 OceanBase 数据库的初期，用户通常对其各种机制都不是十分了解，尤其是 OB 将计算与存储的运维耦合在一起；与传统数据库不同，很多用户会对 OB 节点硬盘配置、硬盘的故障处理流程产生困惑，加剧运营初期的不确定性。而使用管理员更熟悉的外部共享存储可在一定程度上缓解这种不确定性。
部分硬件需要利旧：一些用户希望使用既有设备部署 OceanBase ，但服务器可能没有配备合适（或足够）的本地硬盘，硬件采购流程不是特别便利时，可以通过使用外部共享存储解决问题。

基于以上背景，我们将通过一系列的测试验证 SmartX 自研分布式存储 SMTX ZBS 作为 OceanBase 的外部存储设施的可行性。其中，测试中涉及的软、硬件的详细信息可通过文末附录进行查看。

SMTX ZBS 支持 OceanBase 的性能测试

我们以 SMTX ZBS 作为 OceanBase 外部存储方案，带着几个用户关注的疑问进行了测试：

SMTX ZBS 是否会影响 OceanBase 性能横向扩展特性（即数据库性能与数据库节点规模成正比）？
SMTX ZBS 本身也有副本机制，同时叠加 OceanBase 3 副本，性能是否会发生明显下降？
SMTX ZBS 对比传统中端全闪集中式存储性能如何？

测试基准

通过独立部署的 BenchmarkSQL 压力测试工具，基于 TPC-C 测试模型压测 OceanBase 数据库，并以 tpmC 作为测试结果。

测试结论 1：使用 SMTX ZBS 存储卷不影响 OceanBase 性能横向扩展的特性

测试对象：1 节点 OB 集群和 3 节点 OB 集群共两组对象。
测试模型：1000/2000 warehouse 两种数据集规模，每种数据集分别进行多组并发测试。
测试目标：对比两组测试对象的 TPC-C 性能值的比例是否基本符合 OB 节点数比例，验证 SMTX ZBS 环境下 OB 集群依旧具备性能横向扩展的特性。

从上述图表得知，所有测试场景下（多组不同规模、不同并发压力）测试结果基本一致：3 节点集群和 1 节点集群，节点数之比为 3:1，两者理论 tpmC 值比例应接近 3:1（实际会有损耗）；各个场景中，两者 tpmC 值的比例都维持在 2.65:1 左右，与性能横向扩展的特征相吻合。因此，使用 SMTX ZBS 作为 OceanBase 的存储卷不会削弱 OB 集群的横向扩展特性。

测试结论 2：OceanBase 3 副本和 1 副本的性能接近，性能没有明显下降

测试对象：采用 1 副本与 3 副本的 3 节点 OB 集群（SMTX ZBS 采用 2 副本）共两组对象。
测试模型：1000/2000 warehouse 两种数据集规模，每种数据集分别进行多组并发测试。
测试目标：对比两组测试对象的 TPC-C 性能值是否有明显差异，验证 SMTX ZBS 2 副本叠加 OceanBase 3 副本的策略不会对性能带来明显影响。

从上述图表得知，所有测试场景下（多组不同规模、不同并发压力）测试结果基本一致：

绝大部分场景下，3 副本 OB 集群 tpmC 数值都是 1 副本集群的 90% 左右，两者性能非常接近。
个别场景下 3 副本集群的性能甚至与 1 副本集群持平（或者略高）。

因此，使用 SMTX ZBS 存储卷（2 副本）叠加 OceanBase 3 副本策略场景下，性能不会发生大幅度下滑，与 OceanBase 1 副本的性能是接近的。

SMTX ZBS 对比传统集中式存储报告数据

为了进一步验证 SMTX ZBS 支持 OceanBase 的性能，我们参考了金融信息化研究所与华为联合发布的《基于 OceanStor Dorado 的 OceanBase 数据库存算分离最佳实践》中相近配置方案下以 Dorado 5600 作为 OceanBase 外部存储的 TPC-C 性能数据，并基于该数据与 SMTX ZBS 实测性能数据进行对比，供读者参考。

对比说明

Dorado 存储的性能数据来自第三方报告，虽然尽可能贴近报告模型进行 SMTX ZBS 性能测试，但依然无法避免两组环境之间有部分软、硬件配置存在差异（详见下方对比）。

测试部署拓扑对比：

OceanBase 数据库服务器（单节点）配置对比：

数据库服务器硬件差异说明：

服务器 CPU 型号不一致：其中 Dorado 对应的服务器 CPU 核数是 32，而 SMTX ZBS 对应的服务器 CPU 核数为 48，两者的主频均为 2.6GHz。因此，Dorado 的 CPU 核心数约为 SMTX ZBS 的 67% 。
服务器内存容量不一致：其中 Dorado 对应的服务器内存为 512GB，而 SMTX ZBS 对应的服务器内存为 256GB。因此， Dorado 对应数据库服务器内存容量是 SMTX ZBS 的 2 倍。

压力测试服务器（单节点）配置对比：

压力测试服务器硬件差异说明：

服务器 CPU 型号、架构均不一致：其中 Dorado 对应的服务器 CPU 核数是 32，而 SMTX ZBS 对应的服务器 CPU 核数为 20 核（支持超线程），两者的主频分别 2.6GHz 和 2.1GHz，而且两者 CPU 架构也不一样，因此两者无法直接比较性能。但一般情况下，压力测试机对 CPU 压力没有数据库服务器这么大。
服务器内存容量不一致：其中 Dorado 对应的服务器内存为 512GB，而 SMTX ZBS 对应的服务器内存为 256GB。因此， Dorado 对应数据库服务器内存容量是 SMTX ZBS 的 2 倍。

对比数据

考虑到两组性能测试中的数据库服务器硬件存在差异，其中 Dorado 的 CPU 核心数是 SMTX ZBS 的 67%，与上述 OceanBase 性能测试对比 67%-69% 的结果是接近的；在不考虑内存容量差异的前提下（Dorado 对应主机的内存容量比较大），使用 SMTX ZBS 作为 OceanBase 存储方案与传统中端存储的性能表现是基本持平的。

更多数据库场景性能评测，欢迎点击下方链接下载《SmartX 产品在数据库场景下的测试与实践合集》。

《SmartX 产品在数据库场景下的测试与实践合集》https://mobile.smartx.com/p/6204e

测试后记

本次测试基本遵照 OceanBase 官方文档进行安装、调优和测试，但过程中还是遇到不少问题，有部分问题也是在咨询 OceanBase 厂家技术人员后解决的。在这里整理了一些要点，希望能帮助大家在 OB 测试中“避坑”。

1. OBserver 需要独立部署，切记不要将 OAT、MetaDB、OBLB、OCP、OBProxy 等组件一同部署在 OBserver 上，否则会导致数据库性能明显下降。

2. BenchmarkSQL 压力程序需要部署在独立的服务器中，另可将 OAT、MetaDB、OBLB、OCP、OBProxy 等组件一同部署在 BenchmarkSQL 所在服务器。

3. 根据 Oceanbase 官方调优文档进行系统调优（可点击文末“阅读原文”查阅）。

4. 需根据压力机服务器（MetaDB 所在服务器） CPU 的内核数调整 MetaDB 的 CPU 资源参数（默认设置为 32 核），当物理服务器 CPU 内核数量大于 32 ，采用默认参数会使得 CPU 整体利用率偏低，最终导致数据库性能表现不如预期。

优化前：0-31 核心利用率 100%（过载），32-79 核心利用率较低（低至 20%），CPU 核心利用率差距较大

优化后：0-79 各个核心利用率比较均衡（没有出现 100% 利用率的核心），充分发挥 CPU 性能

MetaDB 的 CPU 资源参数变更

5. 在执行性能测试之前（运行 ./runBenchmark.sh prop.oceanbase 命令之前），需要在 OCP 上对数据库的数据发起合并，等待合并完成之后再执行 ./runBenchmark.sh prop.oceanbase 命令进行性能测试，合并后性能约可提升 10%，合并方法如下图所示：