# Mvcc (Continue...)

![left](./student-guide/diagram/MVCC01_aa_001_20220511.png)

------------------------------------------------------------
Next, let's take a look at the implement of TiKV.

Here, we see that the 3 column families in the RocksDB instance in TiKV store data like this:

1. In Write CF, since only transaction 1 is committed, there will be a record of transaction 1. The commit record with two values key = 1 and key = 2, and the value change is start_ts = 100. There is also a key = 4, and we see that his start_ts is 80, so this record was submitted before.

2. In Default CF, they are key = 1, key = 2, and key = 4, where the start_ts for key = 1 and key = 2 are 100, that is, the two lines of transaction 1 commit in Write CF, and the start_ts for key = 4 is 80.

3. In Lock CF, since transaction 1 has already been committed, locks with key = 1 and key = 2 in transaction 1 are deleted. Since transaction 2 is not committed, locks with key = 1 and key = 4 in transaction 2 still exist.

So, in what order are these data stored in RocksDB, we pay attention to the following points:

1. For Default CF, KEY is {user key} + {start_st}, for Write CF, KEY is {user key} + {commit_st}, and for Lock CF, key is {user key}.
Note: The {user key} here is the business key, and the KEY refers to the key stored in RocksDB.

2. All column family (CF), firstly, are stored in order of {user key}, and secondly, the same {user key} KEY is stored in st_start or st_commit order from largest to smallest. The reason for this is that newer data (i.e. data with a larger timestamp) is arranged in the older order before the data (that is, data with a smaller timestamp).

Knowing the above, we can understand how MVCC works.