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.
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.
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.
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.
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.
|
username: xiaoxiaozuofang
|
username: 
|
username: 
|
username: 
|
username: 
|
username: 
|
username: