一名开发者眼中的 TiDB 与 MySQL 选择

2023-04-14
北京
本文字数：9355 字
阅读完需：约 31 分钟

作者： angryart 原文来源：https://tidb.net/blog/60200e06

TiDB 长期霸榜国产数据库第一名，社区活跃人气旺盛。作为 TiDB 其中的一个粉丝，我把近年的学习调研实践归纳如下，TiDB 是一款通用性的数据解决方案，任何数据场景都可以使用它来解决问题，所以它与所有市场上所有的数据库产品多多少少存在直接上的或者间接上的竞争关系。

那么市场竞争上谁是 TiDB 的第一梯队竞争对手, 本人认为是 MySQL 是其中一个，当然也可以是 Oracle、DB2 等等，主要是 MySQL 在中国深入人心，工程师信手拿来就能使用。

TiDB 与 MySQL 的对比

有些人直接称 TiDB 为大号的 MySQL，其实不对，为了工程师像使用 MySQL 使用 TiDB，TiDB 在接口层下了大量的功夫，在语法、表名、引用甚至元数据方面尽量与 MySQL 贴合，但是每个语句背后执行的都是不同的数据流程和服务流向。

类型上比较，MySQL 是纯粹单机式数据库，TiDB 是分布式数据库，TiDB 可以方便自由增加节点扩展存算能力，而 MySQL 增加节点增强性能，必须通过定向策略，例如中间件路由或者读写分离的方式，显得呆滞固化。

引擎上比较，MySQL 有 myisam、innodb、memory 等引擎，也可以通过插件支持更多的引擎例如 rocksdb，HandlerSocket 等等，而 TiDB 虽然只有两个引擎, 但是却能应对所有的应用场景。

架构上比较，MySQL 是偏紧密耦合，分为三层分别是接口层、服务层、存储层，接口层负责请求处理、授权认证、安全，服务层负责查询解析、分析、优化、缓存、系统内置函数，存储层负责数据的存储和处理，统一体现在一个服务进程上。TiDB 则是松散耦合型，把数据库的关键组件抽象，根据本身分布式的特性，分别是计算层、存储层、协调层。

TiDB 计算层类似 MySQL 接口层，负责负责接收 SQL 请求，处理 SQL 相关的逻辑，并通过协调层找到存储计算所需存储层数据的地址，与存储层交互获取数据，最终返回结果。
TiDB 存储层负责存储数据，数据的存储容量没有上限，存储层上同一份数据一般有 3 个副本，满足高并发需求。协调层会对存储层中的数据做出负载均衡的处理。
TiDB 协调层负责集群的管理模块，经常干的事情有 3 个，一个是集群的元信息，一个是对存储层的数据进行调度和负载均衡，一个分配全局唯一且递增的事务 ID。

数据处理技术上，MySQL 是 B+ 树的组织存储结构，B+ 树适合读多写少，如果写多了，写的影响动作主要是插入、删除，会导致全局的平衡树下面的页频繁分裂或者合并，直接影响性能，影响读放大。TiDB 是 LSM 树的组织存储结构, 擅长写多读少，如果读多了，在内存扫描不到数据，就会去硬盘里面去寻找无序的 sst 文件，所以数据越多越大就会读放大。

TiDB 做了诸多优化，例如使用 RocksDB 作为背端存储, 优化 LSM 机制等等，协同提高数据全链条的处理性能，而且是存算分离的组织完成这个性能的。

产品方向上比较，MySQL 默认 innodb，擅长 OLTP 的业务场景，同时 MySQL 可以插件组装各式引擎，换言之 MySQL 是一个通用型的数据库产品支持所有的业务场景。而 TiDB 默认悲观事务，同样是以 OLTP 为重，同样是一个通用型的数据库产品。但是两者是不一样的，由于 MySQL 是单机型的结构，如果它要扩展，只能通过数据库中间件路由划分，如果数据满了需要停机停服，重新进行数据的割分。

TiDB 对业务无侵入性，扩展非常简单，发展至今安装与维护都非常成熟，通过 Tiup 就可以就可以对分布式集群进行组装维护的相关操作，并且支持在线升级，无缝迁移。

总结，TiDB 与 MySQL 没有对比性，他们不是同一类的数据产品，但是从数据库的特性和市场方向上出发，他们又有了对比的维度指标。事实上，TiDB 努力向 MySQL 学习，甚至还聘请了 innodb 的内核开发工程师，努力调整 TiDB 的底盘，让 TiDB 从内向外都像 MySQL。

TiDB vs MySQL

如果 TiDB 要做大做强，必须要撼动广大码农的工作使用习惯，广大码民对 MySQL 的使用已经深入人心了，不管是 TP 应用，还是 AP 应用，先不管性能，首先用 MySQL 完成业务代码的开发，这意味着 MySQL 经常被当 HTAP 数据库来用。下面我用 CH-benchmark 针对 TiDB6.0 以及 MySQL8.0 来做一个测试。

TPC-CH 由未经修改的 TPC-C 模型和事务、以及 TPC-H 查询的改编版本构成，TPC-CH 保持所有 TPC-C 实体和关系完全不变，并集成了 TPC-H 模型中的 SUPPLIER、REGION 和 NATION 表。这些表在 TPC-H 查询中频繁使用，并允许以非侵入的方式集成到 TPC-C 模型中。SUPPLIER 包含固定数量（10,000 条）的条目。因此，STOCK 中的一条记录可以通过 STOCK.S I ID × STOCK.S W ID mod 10, 000 = SUPPLIER.SU SUPPKEY 与其唯一的供应商（SUPPLIER 表中对应记录）关联起来。TPC-C 中的原始 CUSTOMER 表不包含引用自 NATION 表的外键。我们并没有改变原始模型，从而保持了与现有 TPC-C 的兼容性，所以外键是从字段 C STATE 的第一个字符开始计算的。TPC-C 规定第一个字符可以有 62 个不同的值（即大写字母、小写字母、数字），因此我们选择了 62 个国家来填充 NATION。根据 TPC-H 规范，主键 N NATIONKEY 是一个标识符。它的值被规定，从而使得与这些值相关联的 ASCII 值是一个字母或数字, 即 N NATIONKEY ∈ [48, 57]∪[65, 90]∪[97. 122]。因此，不需要额外的计算来跳过 ASCII 码中数字、大写字母和小写字母之间的间隔。不支持从字符转换到 ASCII 码的数据库系统可能会偏离 TPC-H 模式，使用单个字符作为 NATION 的主键。REGION 包含国家的五个地区。新表之间的关系使用简单的外键字段来建模：NATION.N REGIONKEY 和 SUPPLIER.SU NATIONKEY。

在 CH-Benchmark 中结合了 TPC-C 和 TPC-H 两种基准，它把原来 TPC-C 中的 9 个表和 TPC-H 中的 8 个表修改合并成了 12 个表，并将两者的伸缩模型也统一起来（Scaling TPC-H by the same factors of TPC-C）。

测试环境

硬件配置

测试配置

生成数据

我这里是通过 TiDB Bench 对数据进行压测，但是数据却是通过 CH-benchmark 去生成的。

安装 CH-benchmark

https://github.com/DASLab-IDA/CH-benchmark-rwxr-xr-x. 1 root root 1007440 Mar 29 16:13 chBenchmark-rw-r--r--. 1 root root   12745 Mar  3  2022 chBenchmark.cpp-rw-r--r--. 1 root root  194096 Mar 29 16:13 chBenchmark.o-rw-r--r--. 1 root root     561 Mar  3  2022 LICENSE-rw-r--r--. 1 root root    1167 Mar  3  2022 Makefile-rw-r--r--. 1 root root    2650 Mar  3  2022 README.mddrwxr-xr-x. 3 root root    4096 Mar 29 16:13 src[root@hdp1 CH-benchmark-main]# make运行make之后会就对当天的文件进行编译，生成chBenchmark 执行命令chBenchmark命令如下Create initial database as CSV files:    chBenchmark    -csv    -wh <WAREHOUSE_COUNT>    -pa <INITIAL_DB_GEN_PATH>    example: chBenchmark -csv -wh 50 -pa /path/to/any/directory    生成数据如下,生成一个warehouse的数据chBenchmark -csv -wh 1 -pa  /tmp/chBenchmark1

复制代码

建表语句

CREATE TABLE `customer` (  `c_id` int NOT NULL,  `c_d_id` int NOT NULL,  `c_w_id` int NOT NULL,  `c_first` varchar(16) DEFAULT NULL,  `c_middle` char(2) DEFAULT NULL,  `c_last` varchar(16) DEFAULT NULL,  `c_street_1` varchar(20) DEFAULT NULL,  `c_street_2` varchar(20) DEFAULT NULL,  `c_city` varchar(20) DEFAULT NULL,  `c_state` char(2) DEFAULT NULL,  `c_zip` char(9) DEFAULT NULL,  `c_phone` char(16) DEFAULT NULL,  `c_since` datetime DEFAULT NULL,  `c_credit` char(2) DEFAULT NULL,  `c_credit_lim` decimal(12,2) DEFAULT NULL,  `c_discount` decimal(4,4) DEFAULT NULL,  `c_balance` decimal(12,2) DEFAULT NULL,  `c_ytd_payment` decimal(12,2) DEFAULT NULL,  `c_payment_cnt` int DEFAULT NULL,  `c_delivery_cnt` int DEFAULT NULL,  `c_data` varchar(500) DEFAULT NULL,  PRIMARY KEY (`c_w_id`,`c_d_id`,`c_id`),  KEY `idx_customer` (`c_w_id`,`c_d_id`,`c_last`,`c_first`));CREATE TABLE `district` (  `d_id` int NOT NULL,  `d_w_id` int NOT NULL,  `d_name` varchar(10) DEFAULT NULL,  `d_street_1` varchar(20) DEFAULT NULL,  `d_street_2` varchar(20) DEFAULT NULL,  `d_city` varchar(20) DEFAULT NULL,  `d_state` char(2) DEFAULT NULL,  `d_zip` char(9) DEFAULT NULL,  `d_tax` decimal(4,4) DEFAULT NULL,  `d_ytd` decimal(12,2) DEFAULT NULL,  `d_next_o_id` int DEFAULT NULL,  PRIMARY KEY (`d_w_id`,`d_id`));CREATE TABLE `history` (  `h_c_id` int NOT NULL,  `h_c_d_id` int NOT NULL,  `h_c_w_id` int NOT NULL,  `h_d_id` int NOT NULL,  `h_w_id` int NOT NULL,  `h_date` datetime DEFAULT NULL,  `h_amount` decimal(6,2) DEFAULT NULL,  `h_data` varchar(24) DEFAULT NULL,  KEY `idx_h_w_id` (`h_w_id`),  KEY `idx_h_c_w_id` (`h_c_w_id`));CREATE TABLE `item` (  `i_id` int NOT NULL,  `i_im_id` int DEFAULT NULL,  `i_name` varchar(24) DEFAULT NULL,  `i_price` decimal(5,2) DEFAULT NULL,  `i_data` varchar(50) DEFAULT NULL,  PRIMARY KEY (`i_id`));CREATE TABLE `nation` (  `n_nationkey` tinyint NOT NULL,  `n_name` char(25) NOT NULL,  `n_regionkey` tinyint NOT NULL,  `n_comment` char(152) NOT NULL,  PRIMARY KEY (`n_nationkey`));CREATE TABLE `new_order` (  `no_o_id` int NOT NULL,  `no_d_id` int NOT NULL,  `no_w_id` int NOT NULL,  PRIMARY KEY (`no_w_id`,`no_d_id`,`no_o_id`));CREATE TABLE `orderline` (  `ol_o_id` int NOT NULL,  `ol_d_id` tinyint NOT NULL,  `ol_w_id` int NOT NULL,  `ol_number` tinyint NOT NULL,  `ol_i_id` int DEFAULT NULL,  `ol_supply_w_id` int DEFAULT NULL,  `ol_delivery_d` date DEFAULT NULL,  `ol_quantity` smallint DEFAULT NULL,  `ol_amount` decimal(6,2) DEFAULT NULL,  `ol_dist_info` char(24) DEFAULT NULL,  PRIMARY KEY (`ol_w_id`,`ol_d_id`,`ol_o_id`,`ol_number`),  KEY `fk_orderline_order` (`ol_w_id`,`ol_d_id`,`ol_o_id`),  KEY `fk_orderline_stock` (`ol_supply_w_id`,`ol_i_id`));CREATE TABLE `orders` (  `o_id` int NOT NULL,  `o_d_id` int NOT NULL,  `o_w_id` int NOT NULL,  `o_c_id` int DEFAULT NULL,  `o_entry_d` datetime DEFAULT NULL,  `o_carrier_id` int DEFAULT NULL,  `o_ol_cnt` int DEFAULT NULL,  `o_all_local` int DEFAULT NULL,  PRIMARY KEY (`o_w_id`,`o_d_id`,`o_id`),  KEY `idx_order` (`o_w_id`,`o_d_id`,`o_c_id`,`o_id`)); CREATE TABLE `region` (  `r_regionkey` tinyint NOT NULL,  `r_name` char(55) NOT NULL,  `r_comment` char(152) NOT NULL,  PRIMARY KEY (`r_regionkey`));CREATE TABLE `stock` (  `s_i_id` int NOT NULL,  `s_w_id` int NOT NULL,  `s_quantity` int DEFAULT NULL,  `s_dist_01` char(24) DEFAULT NULL,  `s_dist_02` char(24) DEFAULT NULL,  `s_dist_03` char(24) DEFAULT NULL,  `s_dist_04` char(24) DEFAULT NULL,  `s_dist_05` char(24) DEFAULT NULL,  `s_dist_06` char(24) DEFAULT NULL,  `s_dist_07` char(24) DEFAULT NULL,  `s_dist_08` char(24) DEFAULT NULL,  `s_dist_09` char(24) DEFAULT NULL,  `s_dist_10` char(24) DEFAULT NULL,  `s_ytd` int DEFAULT NULL,  `s_order_cnt` int DEFAULT NULL,  `s_remote_cnt` int DEFAULT NULL,  `s_data` varchar(50) DEFAULT NULL,  PRIMARY KEY (`s_w_id`,`s_i_id`)) ;CREATE TABLE `supplier` (  `s_suppkey` smallint NOT NULL,  `s_name` char(25) NOT NULL,  `s_address` char(40) NOT NULL,  `s_nationkey` tinyint NOT NULL,  `s_phone` char(15) NOT NULL,  `s_acctbal` decimal(12,2) NOT NULL,  `s_comment` char(101) NOT NULL,  PRIMARY KEY (`s_suppkey`));CREATE TABLE `warehouse` (  `w_id` int NOT NULL,  `w_name` varchar(10) DEFAULT NULL,  `w_street_1` varchar(20) DEFAULT NULL,  `w_street_2` varchar(20) DEFAULT NULL,  `w_city` varchar(20) DEFAULT NULL,  `w_state` char(2) DEFAULT NULL,  `w_zip` char(9) DEFAULT NULL,  `w_tax` decimal(4,4) DEFAULT NULL,  `w_ytd` decimal(12,2) DEFAULT NULL,  PRIMARY KEY (`w_id`));

复制代码

导入数据

导入数据前，注意要对tidb运行以下命令ALTER DATABASE tpcch SET tiflash replica 1;mysql> SELECT * FROM information_schema.tiflash_replica WHERE TABLE_SCHEMA = 'tpcch';+--------------+------------+----------+---------------+-----------------+-----------+----------+| TABLE_SCHEMA | TABLE_NAME | TABLE_ID | REPLICA_COUNT | LOCATION_LABELS | AVAILABLE | PROGRESS |+--------------+------------+----------+---------------+-----------------+-----------+----------+| tpcch        | customer   |       90 |             1 |                 |         0 |        0 || tpcch        | district   |       93 |             1 |                 |         0 |        0 || tpcch        | history    |       96 |             1 |                 |         0 |        0 || tpcch        | item       |       99 |             1 |                 |         0 |        0 || tpcch        | nation     |      102 |             1 |                 |         0 |        0 || tpcch        | new_order  |      105 |             1 |                 |         0 |        0 || tpcch        | neworder   |      108 |             1 |                 |         0 |        0 || tpcch        | order      |      111 |             1 |                 |         0 |        0 || tpcch        | order_line |      113 |             1 |                 |         0 |        0 || tpcch        | orderline  |      115 |             1 |                 |         0 |        0 || tpcch        | orders     |      117 |             1 |                 |         0 |        0 || tpcch        | region     |      119 |             1 |                 |         0 |        0 || tpcch        | stock      |      121 |             1 |                 |         0 |        0 || tpcch        | warehouse  |      125 |             1 |                 |         0 |        0 || tpcch        | supplier   |      128 |             1 |                 |         0 |        0 |+--------------+------------+----------+---------------+-----------------+-----------+----------+15 rows in set (0.00 sec)LOAD DATA local INFILE   '/tmp/chBenchmark1/CUSTOMER.tbl' INTO TABLE tpcch.customer   FIELDS TERMINATED BY '|';     LOAD DATA local INFILE   '/tmp/chBenchmark1/DISTRICT.tbl' INTO TABLE tpcch.district   FIELDS TERMINATED BY '|';     LOAD DATA local INFILE   '/tmp/chBenchmark1/HISTORY.tbl' INTO TABLE tpcch.history   FIELDS TERMINATED BY '|';     LOAD DATA local INFILE   '/tmp/chBenchmark1/ITEM.tbl' INTO TABLE tpcch.item   FIELDS TERMINATED BY '|';     LOAD DATA local INFILE   '/tmp/chBenchmark1/NATION.tbl' INTO TABLE tpcch.nation   FIELDS TERMINATED BY '|';     LOAD DATA local INFILE   '/tmp/chBenchmark1/NEWORDER.tbl' INTO TABLE tpcch.new_order   FIELDS TERMINATED BY '|';     LOAD DATA local INFILE   '/tmp/chBenchmark1/ORDER.tbl' INTO TABLE tpcch.orders   FIELDS TERMINATED BY '|';     LOAD DATA local INFILE   '/tmp/chBenchmark1/ORDERLINE.tbl' INTO TABLE tpcch.orderline   FIELDS TERMINATED BY '|';     LOAD DATA local INFILE   '/tmp/chBenchmark1/REGION.tbl' INTO TABLE tpcch.region   FIELDS TERMINATED BY '|';     LOAD DATA local INFILE   '/tmp/chBenchmark1/STOCK.tbl' INTO TABLE tpcch.stock   FIELDS TERMINATED BY '|';     LOAD DATA local INFILE   '/tmp/chBenchmark1/SUPPLIER.tbl' INTO TABLE tpcch.supplier   FIELDS TERMINATED BY '|';     LOAD DATA local INFILE   '/tmp/chBenchmark1/WAREHOUSE.tbl' INTO TABLE tpcch.warehouse   FIELDS TERMINATED BY '|';

复制代码

运行压测命令

192.168.2.x 上面安装 tiup bench

tiup install bench

复制代码

持续对TIDB的数据库tpcch发起50个TP并发量，并进行一次AP的21个语句查询tiup bench ch --host 192.168.1.x  -Uhenley  -pxxxxxx -P4000 --warehouses 1 run -D tpcch -T 50 -t 1 --time 1m持续对mysql的数据库tpcch发起50个TP并发量，并进行一次AP的21个语句查询tiup bench ch --host 192.168.1.x  -Uhenley  -pxxxxxx -P3306 --warehouses 1 run -D tpcch -T 50 -t 1 --time 1m

复制代码

测试摘要

tiup bench ch --host 192.168.1.x  -Uhenley  -pxxxxxx -P3306 --warehouses 1 run -D tpcch -T 50 -t 1 --time 1m
tpmC: 4168.9, tpmTotal: 9231.7, efficiency: 32417.2%[Summary] Q1     - Count: 1, Sum(ms): 67.7, Avg(ms): 67.7[Summary] Q10    - Count: 1, Sum(ms): 30.6, Avg(ms): 30.6[Summary] Q11    - Count: 1, Sum(ms): 558.8, Avg(ms): 558.6[Summary] Q12    - Count: 1, Sum(ms): 19.8, Avg(ms): 19.8[Summary] Q13    - Count: 1, Sum(ms): 163.9, Avg(ms): 163.9[Summary] Q14    - Count: 1, Sum(ms): 14.5, Avg(ms): 14.5[Summary] Q15_ERR - Count: 1, Sum(ms): 277.5, Avg(ms): 277.5[Summary] Q2     - Count: 1, Sum(ms): 1360.0, Avg(ms): 1359.5[Summary] Q3     - Count: 1, Sum(ms): 90.3, Avg(ms): 90.3[Summary] Q4     - Count: 1, Sum(ms): 116.4, Avg(ms): 116.4[Summary] Q5     - Count: 1, Sum(ms): 204.9, Avg(ms): 204.8[Summary] Q6     - Count: 1, Sum(ms): 18.9, Avg(ms): 18.9[Summary] Q7     - Count: 1, Sum(ms): 21.2, Avg(ms): 21.3[Summary] Q8     - Count: 1, Sum(ms): 195.2, Avg(ms): 195.1[Summary] Q9     - Count: 1, Sum(ms): 265.0, Avg(ms): 265.0QphH: 62.5tiup bench ch --host 192.168.2.xx  -Uhenley  -pP@xxx -P4000 --warehouses 1 run -D tpcch -T 50 -t 1 --time 1mtpmC: 1805.5, tpmTotal: 4092.0, efficiency: 14039.7%[Summary] Q1     - Count: 1, Sum(ms): 145.6, Avg(ms): 145.6[Summary] Q10    - Count: 1, Sum(ms): 275.2, Avg(ms): 275.1[Summary] Q11    - Count: 1, Sum(ms): 330.5, Avg(ms): 330.4[Summary] Q12    - Count: 1, Sum(ms): 124.3, Avg(ms): 124.4[Summary] Q13    - Count: 1, Sum(ms): 98.4, Avg(ms): 98.4[Summary] Q14    - Count: 1, Sum(ms): 275.1, Avg(ms): 275.1[Summary] Q15_ERR - Count: 1, Sum(ms): 1.1, Avg(ms): 1.1[Summary] Q2     - Count: 1, Sum(ms): 469.7, Avg(ms): 469.6[Summary] Q3     - Count: 1, Sum(ms): 283.8, Avg(ms): 283.8[Summary] Q4     - Count: 1, Sum(ms): 481.1, Avg(ms): 481.2[Summary] Q5     - Count: 1, Sum(ms): 256.7, Avg(ms): 256.7[Summary] Q6     - Count: 1, Sum(ms): 98.1, Avg(ms): 98.1[Summary] Q7     - Count: 1, Sum(ms): 192.4, Avg(ms): 192.3[Summary] Q8     - Count: 1, Sum(ms): 143.1, Avg(ms): 143.1[Summary] Q9     - Count: 1, Sum(ms): 667.7, Avg(ms): 667.7QphH: 62.4

复制代码

测试总结

保留对 MySQL8.0 和 TiDB6.0 的内部参数不变，从 load data 数据插入、 tpmC 性能、以及 tpc-h 的性能数据表面来看，MySQL8.0 要比 TiDB6.0 要好，其实不然，TiDB 还有很多调优的空间。前面说了，毕竟他们是两个不同的产品线，但是这里证明 TiDB 的友好性，它是十分兼容 MySQL 的，如果你从单机版 TiDB 开始，随着你的业务扩大，你可以自由轻易的扩展。

我对 TiDB 的展望

软件开发的角度，TiDB 的解耦是完整的，如果 TiDB 的发展已经去到 7.0。我对 TiDB 的未来展望是三路发展，TiDB 模块源代码，可以做为分布式计算基础参考，派生更多的可能性，类似 presto 的路线延伸。TiKV 模块源代码，可以作为分布式存储参考，以后的发展方向可能是文件数据存储。PD 模块源代码的技术路径发展是轻量级的元数据存储的管理，三者兼进，帮助用户降低存储成本，提升计算弹性，通过分布式实现元数据最优存储，多姿多彩，发扬光大。

发布于: 刚刚阅读数: 2

原文链接:【http://xie.infoq.cn/article/90b59be1d7dd8f8be1c6f1266】。文章转载请联系作者。

TiDB 社区干货传送门

关注

TiDB 社区官网:https://tidb.net/ 2021-12-15 加入

TiDB 社区干货传送门是由 TiDB 社区中布道师组委会自发组织的 TiDB 社区优质内容对外宣布的栏目，旨在加深 TiDBer 之间的交流和学习。一起构建有爱、互助、共创共建的 TiDB 社区 https://tidb.net/

发布

暂无评论

创作场景

一名开发者眼中的 TiDB 与 MySQL 选择

TiDB 与 MySQL 的对比

同类竞争产品

TiDB vs MySQL

测试环境

生成数据

建表语句

导入数据

运行压测命令

测试摘要

测试总结

我对 TiDB 的展望

TiDB 社区干货传送门

评论