# Mvcc (Continue...)


![left](./student-guide/diagram/03-MVCC-02-01.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:

- In Write CF, since only transaction 1 has been committed, there will be commit records for key = 1 and key = 2 in transaction 1, and the value change is start_st = 100.

- In Default CF, we care about the new data after TSO = 100, which are key = 1, key = 2, and key =4, where key = 1 appears twice, because in transaction 1 and transaction 2, key = 1 is modify once.

- In Lock CF, since transaction 1 has been committed, the locks for key = 1 and key = 2 in transaction 1 are deleted. Since transaction 2 has not been committed, locks for key = 1 and key = 4 in transaction 2 still exist.
So, in what order is this data stored in RocksDB, let's take note of the following points:

- 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.

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

Knowing the above, we can understand how MVCC works.