补充TiDB与云原生数据库的性能比较，测试结果先诧异，之后懂了

前段时间小编测试了三家云厂商的云原生数据库库，包括阿里云 PolarDB、百度智能云 GaiaDB 和 腾讯云 TDSQL-C，测试的结论是" 阿里云 PolarDB > 百度智能云 GaiaDB > 腾讯云 TDSQL-C"。有读者私信我想比较下TiDB，因为企业在MySQL替换过程中会纠结TiDB自建还是直接用云原生数据库，因此小编在之前的测试基础上补充了TiDB的性能对比。未阅读过上一篇性能对比文章的读者可以查看 云原生数据库性能对比（阿里云、百度智能云、腾讯云）

我们还是先看下结果

TiDB在本测试场景下，性能表现不如云原生数据库，差距还是比较大的。小编通过查看TiDB的官方论坛也找到了一些答案，文章最后会给出问题分析。

（蓝色：百度智能云 GaiaDB 红色：腾讯云 TDSQL-C 绿色：阿里云 PolarDB 紫色：TiDB）

测试方案

测试环境

厂商	虚机客户端	数据库信息
阿里-PolarDB	地域/可用区：华北2（北京）客户端：32核64GB实例镜像：CentOS 8.2 64位网络：云服务器 ECS 和云原生数据库集群在同一私有网络（VPC）	内核版本：mysql8.0.2实例类型：独享型实例规格：2C8G、4C16G、8C32G、8C64G、16C128G、32C256G节点个数：一主一只读
腾讯-TDSQL-C	地域/可用区：北京客户端：32核64GB客户端操作系统：CentOS 8.2 64位网络：云服务器 CVM 和云原生数据库集群在同一私有网络（VPC）	内核版本：mysql8.0实例类型：独享型实例规格：2C8G、4C16G、8C32G、8C64G、16C128G、32C256G节点个数：一主一只读
百度-GaiaDB	地域/可用区：华北-北京客户端：32核64GB客户端操作系统：CentOS 8.2 64位网络：云服务器BCC和云原生数据库集群在同一私有网络（VPC）	内核版本：mysq8.0.18实例类型：独享型实例规格：2C8G、4C16G、8C32G、8C64G、16C128G、32C256G节点个数：一主一只读
TiDB 7.2.0	地域/可用区：华北2（保定）客户端：32核64GB实例镜像：CentOS 8.2 64位网络：云服务器 BCC 和部署TiDB社区版的BCC同一私有网络（VPC）	内核版本：TiDB 7.2.0-DMR实例类型：独享型实例规格：根据云原生数据库不同规格集群的各组件套餐，对应分配TiDB各组件套餐，实现资源对齐，可参考如下表格（2C8G、4C16G、8C32G、16C128G、32C256G）节点个数：一主一只读

TiDB的物理部署资源

对比云厂商的规格	Tidb	Tikv	PD
2C8G	2C8G * 2	8C24G * 3	2C8G * 3
4C16G	4C16G * 2	8C24G * 3	2C8G * 3
8C32G	8C32G * 2	8C24G * 3	2C8G * 3
16C64G	16C64G * 2	8C24G * 3	2C8G * 3
32C256G	32C256G * 2	8C24G * 3	2C8G * 3

测试工具

• sysbench工具介绍：SysBench 是一个跨平台且支持多线程的模块化基准测试工具，用于评估系统在运行高负载的数据库时相关核心参数的性能表现。可绕过复杂的数据库基准设置，甚至在没有安装数据库的前提下，快速了解数据库系统的性能。sysbench官方文档

• sysbench版本：1.0.20版本

• sysbench测试模型：
  

  • sysbench 标准 OLTP 读写混合场景中一个事务包含18个读写 SQL。

  • sysbench 标准 OLTP 只读场景中一个事务包含14个读 SQL（10条主键点查询、4条范围查询）。

  • sysbench 标准 OLTP 只写场景中一个事务包含4个写 SQL（2条 UPDATE、1条 DETELE、1条 INSERT）。

测试指标

性能测试的指标包括：

• 每秒执行事务数TPS（Transactions Per Second）数据库每秒执行的事务数，以COMMIT成功次数为准。

• 每秒执行请求数QPS（Queries Per Second）数据库每秒执行的SQL数，包含INSERT、SELECT、UPDATE、DETELE、COMMIT等。

• 所有 event 95分位耗时 95_lat（95% Latency）

评测方法

1. 阿里云、百度智能云、腾讯云分别申请同配置云主机作为客户端

2. 云厂商申请同等价位和配置的数据库实例

3. Sysbench工具从云主机客户端向数据库实例发起读请求、写请求和读写请求

测试方法

• OLTP读写场景压测

#准备数据：

sysbench --db-driver=mysql --mysql-host=XXX --mysql-port=XXX --mysql-user=XXX --mysql-password=XXX --mysql-db=sbtest --table_size=25000 --tables=250 --events=0 --time=600 oltp_read_write prepare

#运行workload

sysbench --db-driver=mysql --mysql-host=XXX --mysql-port=XXX --mysql-user=XXX --mysql-password=XXX --mysql-db=sbtest --table_size=25000 --tables=250 --events=0 --time=600 --threads=XXX --percentile=95 --report-interval=1 oltp_read_write run

#清理

sysbench --db-driver=mysql --mysql-host=XXX --mysql-port=XXX --mysql-user=XXX --mysql-password=XXX --mysql-db=sbtest --table_size=25000 --tables=250 --events=0 --time=600 --threads=XXX --percentile=95 oltp_read_write cleanup

• OLTP只读场景压测

#准备数据：

sysbench --db-driver=mysql --mysql-host=XXX --mysql-port=XXX --mysql-user=XXX --mysql-password=XXX --mysql-db=sbtest --table_size=25000 --tables=250 --events=0 --time=600 oltp_read_only prepare

#运行workload

sysbench --db-driver=mysql --mysql-host=XXX --mysql-port=XXX --mysql-user=XXX --mysql-password=XXX --mysql-db=sbtest --table_size=25000 --tables=250 --events=0 --time=600 --threads=XXX --percentile=95 --range_selects=0 --skip-trx=1 --report-interval=1 oltp_read_only run

#清理

sysbench --db-driver=mysql --mysql-host=XXX --mysql-port=XXX --mysql-user=XXX --mysql-password=XXX --mysql-db=sbtest --table_size=25000 --tables=250 --events=0 --time=600 --threads=XXX --percentile=95 --range_selects=0 oltp_read_only cleanup

• OLTP只写场景压测

#准备数据

sysbench --db-driver=mysql --mysql-host=XXX --mysql-port=XXX --mysql-user=XXX --mysql-password=XXX --mysql-db=sbtest --table_size=25000 --tables=250 --events=0 --time=600 oltp_write_only prepare

#运行workload

sysbench --db-driver=mysql --mysql-host=XXX --mysql-port=XXX --mysql-user=XXX --mysql-password=XXX --mysql-db=sbtest --table_size=25000 --tables=250 --events=0 --time=600 --threads=XXX --percentile=95 --report-interval=1 oltp_write_only run

#清理

sysbench --db-driver=mysql --mysql-host=XXX --mysql-port=XXX --mysql-user=XXX --mysql-password=XXX --mysql-db=sbtest --table_size=25000 --tables=250 --events=0 --time=600 --threads=XXX --percentile=95 oltp_write_only cleanup

测试场景

• 分别选择百度和竞品的6种套餐2C8G、4C16G、8C32G、8C64G、16C128G、32C256G进行测试

• 对于每种规格选择读写、只读、只写3种场景进行测试

• 每个套餐均新增128并发下的测试

限制与补充说明

在测试过程中的一些限制进行补充说明，供参考。

• 不同厂商的内核兼容版本存在小版本号差别，这里忽略小版本的性能差异。

• 不同厂商的CPU、磁盘类型、价格等各有不同，所以这是一个相对对等的测试。

• 不同厂商的数据库实例的默认参数也各有不同，因此不能确定测试结果是最优配置，但基本是默认配置下的性能表现。

• TiDB与云原生数据库的测试对比是一个不完全场景的对比，只能说明在该场景下TiDB的性能表现。

总体结论与分析

综合性能排名：阿里云 > 百度智能云 > 腾讯云 > TiDB

云厂商之间的性能分析请看这篇文章：云原生数据库性能对比（阿里云、百度智能云、腾讯云）

1. 在批量插入和点查场景，TiDB性能差。主要是TiDB的架构主要是对高并发有优势，对于互联网业务中大多数的少量行操作场景没有性能优势；

2. TiDB的计算节点（tidb node），没有缓存能力。因此对于写后查的场景没有缓存加速，导致访问延迟高；

3. TiDB架构的设计主要面相大容量和并发扩展，因此能发挥TiDB并行IO能力的场景会比较适合，例如行检索的数量较多或者高并发的写入场景。

小编在TiDB官网发现，TiDB官方论坛也有很多性能方面的讨论，从官方论坛内容分析本文的测试结果应该还是符合大众认知和事实的。我们在数据库选型中还是要考虑业务场景，如果是弹性要求高、数据量大、SQL简单的场景选择云原生数据库是完全能满足需求的，如果是高并发、SQL复杂、延迟不太敏感的场景可以选择TiDB。

参考内容

tidb与MySQL性能差距

云原生数据库性能对比（阿里云、百度智能云、腾讯云）