Note:
This topic has been translated from a Chinese forum by GPT and might contain errors.Original topic: tidb7.5.0 写入效率没有mysql8.0.35快
|
username: 谢斌1204
Today, using sysbench to generate 20 tables with 10 million rows each, it takes about 7 minutes per table for TiDB and about 5 minutes per table for MySQL.
This test is meaningless. Configuration will affect the results, and the sample size is too small to draw any conclusions.
What is TiDB 5.7.0? There isn’t such a version, right? Also, TiDB is a distributed database. How is the cluster configured?
First, let’s look at the hardware configuration. We don’t even know the environmental differences.
All hardware configurations are just virtual machines (clones).
Distributed systems have relatively high hardware requirements. Distributed systems generally have longer links, and a single link cannot compare to centralized systems, but multiple machines can achieve higher throughput.
If TiDB uses the same physical machine to run multiple TiKV instances, the I/O performance will drop significantly.
Comparing distributed databases and single-node databases is not very meaningful; in the same single-node environment, MySQL’s performance is definitely higher than TiDB’s. TiDB’s advantage lies in its scalability.
Performance cannot be discussed without considering configuration. Additionally, the applicable scenarios for the two other databases are different, and in some cases, they are indeed not as fast as MySQL.
Treat it according to different scenarios, there are both advantages and disadvantages.
You need to fully explain the background information before everyone can help you make a judgment. A single sentence is not enough to make a judgment.
It would be best to share the topology. If it’s a single-machine deployment with multiple TiKV instances, several times the I/O will definitely be slow.
The network and disk I/O costs for single-machine and cluster writes are different, so it is normal to see discrepancies. You can try setting TiKV’s sync-log to false. By default, it is true, which means that a commit needs to wait for most nodes to succeed before returning an ACK to the client. Generally speaking, enabling sync-log results in about a 30% performance loss [1].
TiDB has a naturally high-availability architecture, which should be compared to MySQL’s MGR architecture. Additionally, you can add more TiDB servers and perform some TiKV parameter write tuning to avoid throttling.
|
username: 
|
username: 
|
username: 
|
username: 
|
username: 
|
username: 
|
username: 
Pay attention to the question, it was tested with 7.5.
|
username: 
|
username: 
|
username: 
|
username: 
|
username: 
|
username: