# MVCC - Cont'd

![`smart`](MVCC01_aa_001_20220511.png)

------------------------------------------------------------------------------
The three Column Family instances in the RocksDB instance in TiKV store data as follows:

1. The Write CF contains records of transactions and their commits for specific keys, along with the associated value changes and start timestamps. For example, there is a record of transaction 1 and its commits for key values 1 and 2 with a start timestamp of 100. There is also a record of key 4 with a start timestamp of 80, indicating that it was submitted previously.

2. The Default CF contains records for key values 1, 2, and 4, where key 1 and 2 have start timestamps of 100, indicating that they were submitted by the same transaction. Key 4 has the same start timestamp value as in the Write CF.

3. In the Lock CF, since transaction 1 has already been committed, the locks for key values 1 and 2 in transaction 1 have been removed. However, since transaction 2 has not been committed, the locks for key values 1 and 4 in transaction 2 still exist.

Thus, the data in RocksDB is organized according to the following rules:

1. For the Default CF, the KEY is composed of the user key and the start timestamp. For the Write CF, the KEY is composed of the user key and the commit timestamp. For the Lock CF, the KEY is simply the user key. Note that the user key refers to the business key, while the KEY refers to the key stored in RocksDB.

2. In all Column Families, the data is first sorted by the user key, and then, within the same user key, the KEY values are sorted in descending order, with newer data (i.e. data with larger start timestamps or commit timestamps) ranked ahead of older data (i.e. data with smaller start timestamps or commit timestamps).

With this information, we can better understand how MVCC (Multi-Version Concurrency Control) works in TiKV.