作者:
大数据模型
对制造业、银行业、通讯业理解多一点,关怀专一国产数据库技术布道以及数据资产建设的利用实际。
导读
随着 MySQL 8.0 的公布和行将到来的 5.7 版本的进行反对,许多 MySQL 用户正面临降级和转型的抉择。本文为 TiDB 社区用户撰写,以一名开发者的视角,深入探讨和比拟了 TiDB 和 MySQL 的差别。心愿通过本文,能为读者在架构选型方面提供一些帮忙和领导 。
TiDB 在墨天轮国产数据库排行榜中长年位列前茅,社区活跃度高且人气旺盛。那么 TiDB 应用场景类似产品中,有哪些比拟优良呢?我认为其中一个是 MySQL——毕竟在中国,MySQL 早已深入人心,并且工程师们可能轻松地使用它。
TIDB 与 MySQL 的比照
有些人间接将 TiDB 称为"大号的 MySQL",但理论状况并非如此。为了使工程师们可能像应用 MySQL 一样应用 TiDB,TiDB 在接口层进行了大量的改良。它在语法、表名、援用甚至元数据等方面尽量与 MySQL 保持一致,然而理论执行的每个语句背地都有不同的数据流程和服务流向。因而,只管在表面上它们类似,但其背地的数据处理和服务机制是不同的。
类型方面 ,MySQL 是纯正单机式数据库,TiDB 则是分布式数据库。TiDB 可能不便自在地减少节点来扩大存算能力,而 MySQL 则须要通过定向策略,如中间件路由或读写拆散等形式来减少节点以晋升性能,这使得 MySQL 的扩展性绝对受限且绝对僵化。
引擎方面 ,MySQL 领有多个引擎选项,如 MyISAM、InnoDB、Memory 等,并且能够通过插件反对更多的引擎,如 RocksDB 和 HandlerSocket 等。而 TiDB 尽管只有两个引擎选项,但却可能应答各种利用场景的需要。
架构方面 , MySQL 是偏严密耦合 ,分为接口层、服务层、存储层三个档次。接口层负责申请解决、受权认证和安全性,服务层负责查问解析、剖析、优化、缓存和零碎内置函数,存储层负责数据的存储和解决,所有这些组件都在一个服务过程中对立运行。 而 TiDB 采纳涣散耦合的架构,将数据库的要害组件进行形象,并依据其分布式个性划分为计算层、存储层和协调层。
● TiDB 计算层相似 MySQL 的接口层,负责接管 SQL 申请,解决 SQL 相干的逻辑,并通过协调层找到存储层数据的地位。它与存储层进行交互以获取数据,并最终返回后果。
● TiDB 的存储层负责数据的存储,其存储容量没有下限。通常状况下,存储层会为同一份数据保护 3 个正本;以满足高并发需要。协调层会对存储层中的数据进行负载平衡的解决。
● TiDB 的协调层是集群的治理模块,其次要工作包含三个方面:治理集群的元信息、调度和负载平衡存储层的数据,以及调配全局惟一且递增的事务 ID。
数据处理技术上 ,MySQL 是 B+树 的组织存储构造,B+树适宜读多写少,如果写多了,写的影响动作次要是插入、删除,会导致全局的均衡树上面的页频繁决裂或者合并,间接影响性能,影响读放大。 TiDB 是 LSM 树的组织存储构造,善于写多读少,如果读多了,在内存扫描不到数据,就会去硬盘外面去寻找无序的 sst 文件,所以数据越多越大就会读放大。
解决存储上 ,MySQL 相似微内核,微内核架构由外围服务和插件模块组成, 外围服务负责申请后处理机制流程并进行优化,插件模块次要用来搁置 置解决存储的引擎,引擎决定性能下限 , 微内核的插件式对开发者敌对,能够自在扩大,所以 MySQL 派生了 infobright、MyRocks 等第三方相干引擎,TiDB 的外围服务扩散在 TiDB 模块和 PD 模块外面,两者协同工作形成申请解析、解决、优化及其它服务性能 , TiKV 模块和 TiFlash 模块则是引擎。无论是程序读写还是随机读写, 外围服务协同背端的引擎 工作串成整个数据全链条过程,MySQL 是在单机单过程的外部去实现这个过程的,而 TiDB 是分布式多过程实现这个过程的。
产品方面 ,MySQL 默认应用 InnoDB 引擎,善于解决 OLTP 的业务场景。同时,MySQL 还反对插件组装各种引擎,使其成为一个通用型的数据库产品,实用于各种业务场景。而 TiDB 默认采纳乐观事务的形式,同样专一于 OLTP,也是一个通用型的数据库产品。然而,这两者之间存在一些差别。因为 MySQL 是单机型构造,如果须要进行扩大,只能通过数据库中间件路由的形式进行划分。而如果数据已满,就须要停机或停服,从新进行数据的宰割。
TiDB 具备对业务的无侵入性,且扩大非常简单。在其倒退至今,装置和保护方面曾经十分成熟。通过 TiUP 工具,能够轻松进行分布式集群的组装和保护操作,并且反对在线降级和无缝迁徙。这使得应用 TiDB 的过程更加便捷和高效,使用户可能更好地治理和运维他们的分布式数据库系统。
综上所述,TiDB 与 MySQL 属于不同类型的数据产品,并不能间接进行比照。然而,从数据库的个性和市场趋势的角度来看,它们能够有一些维度上的比照指标。事实上,TiDB 致力于向 MySQL 学习,并且还延聘了 InnoDB 的外围开发工程师,致力于调整 TiDB 的底盘,使其在外部和内部都更像 MySQL。
同类竞争产品
TiDB 是一款 分布式数据库产品 ,它以分布式为标识并能基于线下装置,在国内外都有相似的产品。那么 TiDB 与其余产品有什么不同?参照数据库解决的流程,我将从工作开始到工作完结来详述。
1. 用户发动申请:数据库客户端向指定的数据库集群发动申请。
2. 指标数据库响应:数据库集群的指定节点响应用户的申请。
3. 两者建设会话:数据库集群其中一个节点与客户端产生会话。
4. 对象申请解析 :数据库对接管到的申请进行语法查看、对象解析,并将其转换为对应的关系代数构造,而后进行打算工作优化。
5. 调度并且执行:寻找最合适的正本,依据优先级进行,是内存、缓存、数据快照、存储等等。
6. 监测工作状态:数据库监测执行中工作的状态。
7. 返回数据后果:数据库服务端将执行后果返回给数据库客户端 。
上述环节中,最要害的是第 2 步、第 4 步和第 5 步。
第 2 步是 哪一个节点响应数据库客户的申请,分布式数据库有两种零碎架构,一种是中心化架构【master\slave】,一种是去中心化架构。中心化架构的负色职责分清,负责干活、负责指挥、负责接待用户,而去中心化架构则是每个节点角色平等,看待客户的申请,其中的一个节点会霎时切换成负责接待,残余的节点依据状况转化执行。
TiDB 在这里采纳中心化的架构,节点角色之间的职责更加清晰,分工更加明确。
第 4 步和第 5 步是数据计算和数据存储的关键步骤,TiDB 在这里做了深度的涣散解耦,数据计算用 TiDB,数据存储用 TiKV,两者是真正意义上的存算拆散,要减少存储容量,能够减少没有 CPU 的硬盘服务器,要减少计算能力,能够减少没有硬盘的服务器。对于分布式的性能和作用则集中在一个 PD 的模块上。
采纳集中式的分布式架构的产品则采纳了去核心架构,而且计算和存储高度耦合,又称为单机式的分布式架构。
TiDB 比起同类产品在架构上更加高度涣散耦合,与云计算技术更加严密合作,珠联璧合。
TiDB VS MySQL
如果 TiDB 要做大做强,必须要撼动宽广开发人员的工作应用习惯。大部分开发人员曾经非常相熟并宽泛应用 MySQL,无论是在 TP 利用还是 AP 利用中。不管性能如何,他们首先会抉择 MySQL 来开发业务代码。这也意味着 MySQL 常常被用作 HTAP 数据库。接下来,我将应用 CH-benchmark 来对 TiDB 6.0 和 MySQL 8.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)。
测试环境
硬件配置
操作系统 | CentOS Linux release 7.6.1810 |
---|---|
CPU | 8 核 Intel(R) Xeon(R) |
内存 | 16 |
测试配置
软件版本 | IP | 作用 |
---|---|---|
MySQL8.0 | 192.168.1.X | MySQL 单机 |
TiDB6.0 | 192.168.1.X | TiDB 单机 |
CH-benchmark | 192.168.2.X | HTAP 测试工具,生成数据 |
TiUP Bench | 192.168.2.X | HTAP 测试工具,进行测试 |
生成数据
在我的试验中,我应用了 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
4.1 建表语句
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`));
4.2 导入数据
导入数据前,留神要对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 '|';
4.3 运行压测命令
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
4.4 测试摘要
tiup bench ch --host 192.168.1.x -Uhenley -pxxxxxx -P3306 --warehouses 1 run -D tpcch -T 50 -t 1 --time 1mtpmC: 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
4.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 模块源代码的技术门路倒退是轻量级的元数据存储的治理,三者兼进,TiDB 将可能最大化地帮忙用户升高存储老本,晋升计算弹性,通过分布式实现元数据最优存储,灵便、牢靠,在更多场景失去利用。