Is it necessary to implement read-write separation in a TiDB cluster to improve database query performance, and are there better solutions besides read-write separation?

This topic has been translated from a Chinese forum by GPT and might contain errors.

Original topic: tidb集群是否有必要再做读写分离,为更好的提升数据库的查询性能,除数据读写分离外有有没更优的方案?

| username: xiaoxiaozuofang

[TiDB Usage Environment] Production Environment
[TiDB Version] tidbv6.1.0
[Reproduction Path] What operations were performed when the issue occurred
[Encountered Issue] Slow multi-table join query
[Resource Configuration] 2 TiDB (8 cores/32G/100G), 3 PD (8 cores/32G/100G), 5 KV (8 cores/32G/200G (SSD))
[Attachments: Screenshots/Logs/Monitoring]

| username: 啦啦啦啦啦 | Original post link

You can consider Follower Read

You can also refer to the following post

| username: 近墨者zyl | Original post link

Since leaders are load-balanced across all TiKV nodes, the load is already distributed, making read-write separation unnecessary. Manually separating reads and writes could potentially disrupt load balancing, and follower reads inherently have latency. To achieve fast queries and writes in TiDB, you need to properly adjust concurrency and indexing.

Read-write separation has little significance for distributed databases.

| username: OnTheRoad | Original post link

If the primary key of the table is AUTO_RANDOM, the data is already distributed across multiple TiKV nodes during storage, so there is no need to consider read-write separation. Additionally, the TiFlash component can be introduced to improve query speed for large volumes of data.

| username: 大鱼海棠 | Original post link

TiDB is natively distributed, unlike traditional relational databases. The leaders for reading have already been balanced across various nodes, so there is no need for read-write separation.

| username: 张雨齐0720 | Original post link

The cost of read-write separation is actually quite high, including the software and hardware costs of the standby machine and development adaptation. You also have to consider scenarios such as handling data inconsistencies. If you can solve it through weak reads and scattering, it’s better not to consider read-write separation.

| username: TiDBer_jYQINSnf | Original post link

Read-write separation was a compromise for single-node databases in the past. At that time, write traffic couldn’t be separated, so read traffic had to be distributed to other machines to enhance the processing capability of the single-node database. TiDB can evenly distribute both read and write traffic across all machines, fully utilizing all resources, making read-write separation unnecessary.

Additionally, Follower Read still needs to request from the leader, which will also increase latency.