author:
big data model
Know more about the manufacturing industry, banking industry, and communication industry, and care about domestic database technology evangelism and the application practice of data asset construction.
guide
With the release of MySQL 8.0 and the end of support for the upcoming 5.7 version, many MySQL users are facing the choice between upgrading and transformation. This article is written for TiDB community users. From the perspective of a developer, this article discusses and compares the differences between TiDB and MySQL in depth. I hope that through this article, I can provide readers with some help and guidance in terms of architecture selection.
TiDB has been at the top of Motianlun's domestic database rankings for many years, and the community is highly active and popular. So among the products with similar usage scenarios of TiDB, which ones are better? I think one of them is MySQL - after all, in China, MySQL has been deeply rooted in the hearts of the people, and engineers can use it easily.
Comparison of TIDB and MySQL
Some people directly refer to TiDB as a "big MySQL", but this is not the case. In order to enable engineers to use TiDB like MySQL, TiDB has made a lot of improvements at the interface layer. It tries to be consistent with MySQL in terms of syntax, table names, references and even metadata, but each statement actually executed has different data flow and service flow behind it. Therefore, although they are similar on the surface, the data processing and service mechanisms behind them are different.
In terms of type , MySQL is a pure stand-alone database, while TiDB is a distributed database. TiDB can easily and freely add nodes to expand storage and computing capabilities, while MySQL needs to use targeted strategies, such as middleware routing or read-write separation, to increase nodes to improve performance, which makes the scalability of MySQL relatively limited and relatively rigid .
In terms of engines , MySQL has multiple engine options, such as MyISAM, InnoDB, Memory, etc., and can support more engines through plug-ins, such as RocksDB and HandlerSocket. Although TiDB has only two engine options, it can meet the needs of various application scenarios.
In terms of architecture, MySQL is tightly coupled and is divided into three layers: interface layer, service layer, and storage layer. The interface layer is responsible for request processing, authorization authentication, and security. The service layer is responsible for query analysis, analysis, optimization, caching, and system built-in functions. The storage layer is responsible for data storage and processing. All these components run uniformly in a service process. TiDB, on the other hand, adopts a loosely coupled architecture, abstracts the key components of the database, and divides it into a computing layer, a storage layer, and a coordination layer according to its distributed characteristics.
● The TiDB computing layer is similar to the MySQL interface layer, responsible for receiving SQL requests, processing SQL-related logic, and finding the location of the storage layer data through the coordination layer. It interacts with the storage layer to fetch data, and finally returns the result.
● TiDB's storage layer is responsible for data storage, and its storage capacity has no upper limit. Normally, the storage layer maintains three copies of the same data to meet high concurrency requirements. The coordination layer will perform load balancing processing on the data in the storage layer.
● The coordination layer of TiDB is the management module of the cluster. Its main work includes three aspects: managing cluster meta-information, scheduling and load balancing storage layer data, and assigning globally unique and incremental transaction IDs.
In terms of data processing technology , MySQL is an organizational storage structure of B+ tree . B+ tree is suitable for reading more and writing less. If there are too many writes, the impact of writing is mainly insertion and deletion, which will cause frequent splitting or merging of pages under the global balanced tree. , directly affects performance and affects read amplification. TiDB is an organizational storage structure of the LSM tree. It is good at writing more and reading less. If you read too much and cannot scan the data in the memory, it will go to the hard disk to find out-of-order sst files, so the more data, the larger it will be read and enlarged. .
In terms of processing and storage , MySQL is similar to a microkernel. The microkernel architecture consists of core services and plug-in modules. The core service is responsible for request post-processing mechanism flow and optimization. The plug-in module is mainly used to place the engine for processing and storage. The engine determines the upper limit of performance . The plug-in type of the kernel is friendly to developers and can be expanded freely, so MySQL derives third-party related engines such as infobright and MyRocks. The core services of TiDB are scattered in the TiDB module and PD module. The two work together to form request parsing, processing, and optimization. and other service functions, the TiKV module and TiFlash module are the engines. Regardless of whether it is sequential reading or writing or random reading and writing, the core service cooperates with the back-end engine to form the entire data chain process. MySQL completes this process inside a single machine and a single process, while TiDB completes this process through distributed multi-processes. .
In terms of products , MySQL uses the InnoDB engine by default, which is good at handling OLTP business scenarios. At the same time, MySQL also supports plug-ins to assemble various engines, making it a general-purpose database product suitable for various business scenarios. TiDB, on the other hand, adopts the pessimistic transaction method by default, and also focuses on OLTP, which is also a general-purpose database product. However, there are some differences between the two. Since MySQL is a stand-alone structure, if it needs to be expanded, it can only be divided through database middleware routing. And if the data is full, you need to stop or stop the server, and re-segment the data.
TiDB is non-invasive to the business, and its expansion is very simple. It has been very mature in terms of installation and maintenance since its development. With the TiUP tool, you can easily assemble and maintain distributed clusters, and support online upgrades and seamless migrations. This makes the process of using TiDB more convenient and efficient, enabling users to better manage and maintain their distributed database systems.
To sum up, TiDB and MySQL are different types of data products and cannot be compared directly. However, from the perspective of database characteristics and market trends, they can have comparative indicators in some dimensions. In fact, TiDB is committed to learning from MySQL, and has also hired core development engineers from InnoDB to work on adjusting TiDB's chassis to make it more like MySQL internally and externally.
Competitive products
TiDB is a distributed database product , which is marked by distributed and can be installed offline. There are similar products at home and abroad. So what makes TiDB different from other products? Referring to the process of database processing, I will describe it in detail from the beginning of the task to the end of the task.
1. The user initiates a request: the database client initiates a request to the specified database cluster.
2. Target database response: The designated node of the database cluster responds to the user's request.
3. The two establish a session: one of the nodes in the database cluster creates a session with the client.
4. Object request parsing: The database performs syntax check and object parsing on the received request, and converts it into the corresponding relational algebra structure, and then optimizes the scheduled task.
5. Scheduling and execution: Find the most suitable copy, based on priority, such as memory, cache, data snapshot, storage, etc.
6. Monitoring task status: The database monitors the status of the task being executed.
7. Return data result: The database server returns the execution result to the database client.
Among the above links, the most critical steps are the 2nd, 4th and 5th steps.
The second step is which node responds to the request of the database customer. There are two system architectures for distributed databases, one is a centralized architecture [master\slave], and the other is a decentralized architecture. The responsibility of the centralized architecture is divided, responsible for work, command, and reception of users, while the decentralized architecture is that each node has an equal role. When dealing with customer requests, one of the nodes will instantly switch to be in charge of reception, and the rest The nodes are converted and executed according to the situation.
TiDB adopts a centralized architecture here, the responsibilities between node roles are clearer, and the division of labor is clearer.
Steps 4 and 5 are the key steps for data calculation and data storage. TiDB has done a deep loose decoupling here. TiDB is used for data calculation and TiKV is used for data storage. The two are the real separation of storage and calculation. To increase storage capacity, you can add hard disk servers without CPU, and to increase computing power, you can add servers without hard disks. The distributed functions and functions are concentrated on a PD module.
Products using a centralized distributed architecture use a decentralized architecture, and computing and storage are highly coupled, also known as a stand-alone distributed architecture.
Compared with similar products, TiDB has a more loosely coupled architecture, and works more closely with cloud computing technology, making it a perfect match.
TiDB VS MySQL
If TiDB is to become bigger and stronger, it must shake the working habits of developers. Most developers are already familiar with and use MySQL extensively, both in TP and AP applications. Regardless of performance, they will first choose MySQL to develop business code. This also means that MySQL is often used as the HTAP database. Next, I will use CH-benchmark to conduct a test on TiDB 6.0 and MySQL 8.0.
TPC-CH consists of unmodified TPC-C models and transactions, and adapted versions of TPC-H queries, TPC-CH keeps all TPC-C entities and relationships completely unchanged, and integrates SUPPLIER from the TPC-H model , REGION, and NATION tables. These tables are frequently used in TPC-H queries and allow integration into TPC-C models in a non-intrusive manner. SUPPLIER contains a fixed number (10,000) of entries. Therefore, a record in STOCK can be related to its unique supplier (the corresponding record in the SUPPLIER table) by STOCK.SI ID × STOCK.SW ID mod 10, 000 = SUPPLIER.SU SUPPKEY. The original CUSTOMER table in TPC-C does not contain foreign keys referenced from the NATION table. We did not change the original model to maintain compatibility with the existing TPC-C, so the foreign key is calculated from the first character of the field C STATE. TPC-C stipulates that the first character can have 62 different values (ie uppercase letters, lowercase letters, numbers), so we chose 62 countries to populate NATION. According to the TPC-H specification, the primary key N NATIONKEY is an identifier. Its values are specified such that the ASCII value associated with these values is a letter or a number, ie N NATIONKEY ∈ [48, 57]∪[65, 90]∪[97.122]. Therefore, no additional calculations are required to skip the gaps between digits, uppercase letters, and lowercase letters in ASCII codes. Database systems that do not support character-to-ASCII conversion may deviate from the TPC-H schema and use a single character as the primary key for NATION. REGION contains the five regions of the country. The relationships between the new tables are modeled using simple foreign key fields: NATION.N REGIONKEY and SUPPLIER.SU NATIONKEY.
TPC-C and TPC-H are combined in CH-Benchmark , which combines the original 9 tables in TPC-C and the 8 tables in TPC-H into 12 tables, and combines the two The scaling model of TPC-H is also unified (Scaling TPC-H by the same factors of TPC-C).
test environment
Hardware Configuration
| operating system | CentOS Linux release 7.6.1810 |
|---|---|
| CPU | 8-core Intel® Xeon® |
| Memory | 16 |
test configuration
| Software version | IP | effect |
|---|---|---|
| MySQL8.0 | 192.168.1.X | MySQL stand-alone |
| TiDB6.0 | 192.168.1.X | TiDB stand-alone |
| CH-benchmark | 192.168.2.X | HTAP test tool, generate data |
| TiUP Bench | 192.168.2.X | HTAP testing tools, for testing |
generate data
In my experiment, I used TiDB Bench to test the data, and the tool for generating these data is CH-benchmark.
Install 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.md
drwxr-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 statement
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 Import data
导入数据前，注意要对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 Run the pressure test command
Install tiup bench on 192.168.2.x
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 Test Summary
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.0
QphH: 62.5
tiup bench ch --host 192.168.2.xx -Uhenley -pP@xxx -P4000 --warehouses 1 run -D tpcch -T 50 -t 1 --time 1m
tpmC: 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.7
QphH: 62.4
4.4 Test summary
Keep the internal parameters of MySQL8.0 and TiDB6.0 unchanged, purely from the stand-alone load data data insertion, tpmC performance, and tpc-h performance data, MySQL8.0 is better than TiDB6.0. However, this is not the case in reality, because TiDB still has a lot of room for tuning. As mentioned earlier, they are two different product lines, but this proves TiDB's friendliness. It is very compatible with MySQL. If you start with the stand-alone version of TiDB, you can expand it freely and easily as your business expands.
My outlook on TiDB
From the perspective of software development, the decoupling of TiDB is complete, and TiDB has now reached version 7.0. My expectation for the future of TiDB has three aspects : the source code of the TiDB module can be used as a basic reference for distributed computing, and more possibilities can be derived, similar to the extension of presto; the source code of the TiKV module can be used as a reference for distributed storage. The development direction of the PD module may be file data storage; the technical path development of the source code of the PD module is the management of lightweight metadata storage. With the combination of the three, TiDB will be able to help users reduce storage costs and improve computing flexibility to the greatest extent. Distributed to achieve optimal storage of metadata, flexible, reliable, and applied in more scenarios.