0 2  为什么要做 Benchmark 测试

1. 数据库版本升级前评估兼容性和性能

数据库的版本升级在运维人员日常工作中时有发生。想象下这么一个场景，业务需要使用 Json，而当前使用的 MySQL 是5.6版本，MySQL 只有升级到5.7版本才支持 Json。在此情景下，我们需要评估数据库版本升级前后的兼容性和性能。在业务介入前，建议运维同学可以先使用 Benchmark 测试进行压测和评估。

2. 数据库选型替换前评估兼容性和性能

随着国产数据库的快速发展，在替换原有的商业数据库或者其他开源数据库的时候，我们经常会遇到选型的问题，比如从单机的数据库替换成分布式数据库，我们就需要测试其兼容性和性能，测试其水平扩展能力。

3. 新系统上线前，评估数据库容量、负载

新系统上线前，我们如何确保大并发负载下业务不停服，数据库可以平稳应对突发大流量？解决该问题需要我们模拟业务访问量，评估单台机器、多台机器的压力，评估其后续扩展性。

4. 采购新设备，评估新设备性能

在降本增效的环境下，之前企业中使用的高端存储、商业数据库和小型机可能逐步会被普通的 X86、开源数据库，特别是国产数据库所取代。如何确认新的硬件设备性能是否满足业务，可以压测数据库来观察新设备的 cpu，memory, io, network 的工作负载。

工欲善其事必先利其器，对数据库的压测，业界有哪些好用的工具呢？每种数据库压测工具是否有各自使用的场景呢？

1. Sysbench

Sysbench 是一个基于 LuaJIT 可编写脚本的多线程基准测试工具，可以执行 CPU/内存/线程/IO/数据库等方面的性能测试，常用于评估测试各种不同系统参数下的数据库负载情况。

该工具只能针对单个表进行测试，或者对多个独立的表进行测试，多表之间没有关联，不能模拟接近生产系统的业务模型。Sysbench 优点是可以用来测试数据类型兼容性，也可以通过自定义 lua 脚本以实现不同业务类型的测试。

2. TPC-C

TPC-C Benchmark 是一个对 OLTP（联机交易处理）系统进行测试的规范，通过使用一个商品销售模型对 OLTP 系统进行测试，包含五类事务：

● NewOrder –新订单的生成；

● Payment –订单付款；

● OrderStatus –最近订单查询；

● Delivery –配送；

● StockLevel –库存缺货状态分析。

TPC-C 使用 tpmC 值（Transactions per Minute）来衡量系统最大有效吞吐量（MQTh，Max Qualified Throughput），其中 Transactions 以 NewOrder Transaction 为准，即最终衡量单位为每分钟处理的新订单数。

3. TPC-H

TPC-H（商业智能计算测试）是美国交易处理效能委员会（TPC，Transaction Processing Performance Council）组织制定的用来模拟决策支持类应用的一个测试集。目前，学术界和工业界普遍采用 TPC-H 来评价决策支持技术方面应用的性能。这种商业测试可以全方位评测系统的整体商业计算综合能力，对厂商的要求更高，同时也具有普遍的商业实用意义，目前在银行信贷分析和信用卡分析、电信运营分析、税收分析、烟草行业决策分析中都有广泛的应用。

TPC-H 基准测试由 TPC-D（由 TPC 于 1994 年制定的标准，用于决策支持系统方面的测试基准）发展而来的。TPC-H 用 3NF 实现了一个数据仓库，共包含 8 个基本关系，其主要评价指标是各个查询的响应时间，即从提交查询到结果返回所需时间。TPC-H 基准测试的度量单位是每小时执行的查询数（QphH@size），其中 H 表示每小时系统执行复杂查询的平均次数，size 表示数据库规模的大小，它能够反映出系统在处理查询时的能力。

TPC-H 是根据真实的生产运行环境来建模的，这使得它可以评估一些其他测试所不能评估的关键性能参数。总而言之，TPC 组织颁布的 TPC-H 标准满足了数据仓库领域的测试需求，并且促使各个厂商以及研究机构将该项技术推向极限。

想必各位对 OceanBase 的性能都有所耳闻，TPC-C 打榜第一，TPC-H 打榜第二。那么如何用各种 Benchmark 流畅丝滑地测试 OceanBase，肯定是大家关心的重要一环。在这里我们先行给大家剧透两种 Benchmark 测试的方法。

1. OBD 测试

OceanBase Deployer（简称 OBD）是 OceanBase 开源软件的安装部署工具。同时，OBD 也提供了自动进行 Benchmark 测试的功能，用户输入集群必要的信息，即可自动进行 Schema 下发、性能调优和工具测试，从而得到一个比较可靠的性能数据结果。

2. 手工测试

如果用户出于个性化的测试目的，我们也提供了手工操作 Benchmark 测试的文档，从安装部署到性能数据分析，“一站式服务”包教包会。

更多方法，更详尽的操作，敬请关注 1月13日晚19:30 钉钉直播间，子行老师手把手在线教学。

在进行 Benchmark 测试的时候，有一些常见的操作和场景对性能影响很大，在这里也给出我们的测试建议，帮助大家避免大部分的性能不符合预期问题。

1. 磁盘划分

CLOG、LOG、SSTABLE 建议分为多个独立文件系统分盘部署，退而求其次的情况下也可以用 LVM 划分出多个 LV。如果 OBSERVER 运行日志、事务日志、数据文件都在一块盘上，可能会引发多种风险。比如事务日志（clog）在磁盘空间超过95%就会造成节点停写、掉线，同时也会影响 liboblog 同步，以及影响 CLOG 回收或者副本迁移速度等。

2. 租户设置

OceanBase 是多租户模式的数据库，所以测试租户的设置对 Benchmark 测试同样重要，建议尽量给进行测试的租户提供最多的资源（内存、cpu等）。另外，租户的 PRIMARY_ZONE 是用来控制租户里主副本的分布。如果设置为 RANDOM，就可以将不同分区的主副本分散在不同 ZONE 的节点上，以达到机器利用率的最大化。反过来，如果将 PRIMARY_ZONE 设置为某个具体的 ZONE，则只能利用部分节点。

3. 使用分区表 

OceanBase 的分区表主要有两个作用：

● 分区表的使用可以在特定的 SQL 操作中减少数据读写的总量以减少响应时间；

● 解决单机处理性能瓶颈，将海量请求分散到不同分区，而不同分区主副本则可以分散在不同节点。

建议大家在使用 TPC-H 和 BMSQL 测试的时候采用分区表，Sysbench 测试建议使用非分区表，因为 Sysbench 如果采用分区表，有大量的分布式查询，性能不如非分区表。

其实造成 Benchmark 性能数据不符合预期的因素和操作还有很多，受于篇幅限制没法详细讲解，如果大家对该话题感感兴趣，请关注 OceanBase 社区版直播教程的第六期——如何测试 OceanBase 社区版，我们一起来唠唠。

1月13日晚（下周四） 19:30，准时相约 OceanBase 社区版教程官方直播间。一个小时为你聊透 “ OceanBase 如何进行 Benchmark 测试及调优”！