Allow TiDB read by TiKV's RC

[you06]

Enhancement

Background

High isolation and consistency level offer a strong guarantee, however, the performance would be poorer than low isolation and consistency level. Currently, TiDB offers 2 isolation levels: "Repeatable Read" and "Read Committed", their definitions are below:

Repeatable Read

Also known as snapshot isolation(SI), which reads data from a consistent snapshot. In TiDB, a snapshot is based on startTS which is a global monotonic timestamp allocated from PD. Reads based on a snapshot cannot see the data whose commitTS > startTS, but must see the data whose commitTS <= startTS. The model is ideal for the client, however, it'll hurt the performance. To provide the monotonic guarantee, every read should check if there is a lock in the key before reading the value, if so, it should go resolve-lock phase, which leads to high latency.

Read Committed

TiDB's read committed can be described as Oracle's statement-level read consistency, the implementation is simple, there is an individual snapshot for each statement. Besides, the read lock and wait lock mechanism is the same as Repeatable Read.

Weak Read Consistency

This issue suggests a consistency level named "weak read consistency", which will read through TiKV's RC. By using TiKV's RC, it can offer better performance and lower latency. It reads data with lock skipped, it's executed without fetching the global monotonic timestamp, however, it offers only weak read consistency.

Affected User Behavior

Users can turn on weak read consistency by setting set session/global tidb_read_consistency = weak. Then the statements that hit all the following requirements will go through weak read consistency read.

• It should be an auto-committed read request.
• It should be a read operation(select statement or execute a select statement)

Consistency

Use it only if you understand the consistency risk. Though there is a lot of benefits, there is consistency risk.

No Snapshot

Weak consistency doesn't read through a snapshot, which means some operations will read data from different versions. e.g.

create table t(id int primary key, c int);
insert into t values(1, 1), (2, 2);

update t set c = 10 * c; -- stmt1
select * from t; -- stmt2, use weak consistency, executed concurrently with stmt1
+----+------+
| id | c    |
+----+------+
|  1 |   1  |
|  2 |   20 |
+----+------+
2 rows in set (0.002 sec)

Index and data consistency

In every snapshot, an index should point to corresponding data, that's a basic invariant in the database. By reading through TiKV's RC, we may get indexes and data that belong to different versions. That means we may read an index but don't have corresponding data, or have the previous data(the correct data is not visible yet). Only if you avoid updating index, it'll work correctly. But admin check or in-transaction statements won't be weak consistency, so there will not be inconsistent data in the storage engine.

Summary

Weak consistency has some risks, however, can improve performance a lot, it's worth a try.

[TonsnakeLin]

why not add a new isolation level like RC-WRAK, then It is not necessary to import a new variable.
It Increases the user's difficulty when import new variables @you06 @youjiali1995

[you06]

why not add a new isolation level like RC-WRAK, then It is not necessary to import a new variable. It Increases the user's difficulty when import new variables @you06 @youjiali1995

Actually, I wonder this feature would never be used by the users who do not understand the consistency at a very high level.