#  KV And Storage

__*Multi Raft Group*__
__*TiKV Region*__
__*RocksDB*__

![center](./student-guide/diagram/tidb-storage-kv-pair-region-raft-rocksdb.drawio.png)

+ **KV**
+ **Region**
+ **Raft Group**
+ **RocksDB**

-------------------------------------------------------------
- As a data storage system, the first thing to decide is the storage model of the data, that is, what form the data will be saved in. The choice of TiKV is a key-value model and provides an ordered traverse method.

- Two key points for TiKV data storage:
  - This is a huge Map (analogy with C++ std: :map), that is, key-value pair (key-value pairs) stored
  - The key-value pairs in this Map are ordered according to the binary order of the Key, that is, you can Seek to the position of a Key, and then continuously call the Next method to get the Key-Value larger than this Key in increasing order.

- In order to implementation horizontal scale of storage, data will be spread across multiple machines. TiKV divides the entire key-value space into many segments according to the Key Range. Each segment is a series of consecutive Keys, each segment is called a Region, and tries to keep the data stored in each Region not exceeding a certain size. Currently, the default in TiKV is 96MB. Each region can be described as [startKey, endKey) with a left-closed and right-open interval. After dividing the data into regions, TiKV will do two important things: spread the data across all the nodes in the cluster in units of the region, and try to ensure that the number of regions service on each node is about the same; and Raft replication and member management by region.

- With any persistent storage engine, data is ultimately saved on disk, and TiKV is no exception. However, TiKV does not choose to write data directly to disk, but saves the data in RocksDB, and RocksDB is responsible for the specific data landing. The reason for this choice is that developing a single-instance storage engine is a lot of work, especially to make a high-performance single-instance engine, which requires various meticulous optimizations. RocksDB is a very good single-instance KV storage engine open-source by Facebook, which can meet TiKV's various requirements for single-instance engines. Here we can simply think of RocksDB as a stand-alone persistent key-value map.

- Next, the implementation of TiKV faces a more difficult task: how to ensure that data is not lost or error-free in the event of a single-instance failure?

- In simple terms, there is a need to find a way to replicate data to multiple machines, so that one machine can no longer service, and replica on other machines can still serve; in complex terms, this data replication solution also needs to be reliable and efficient, and able to handle the failure of replica. TiKV chose the Raft algorithm. Raft is a consistency protocol. This article will only give a brief introduction to Raft. Please refer to its paper for details. Raft provides several important functions: leader elect, member changes (such as adding replicas, deleting replicas, transferring leaders, etc.), and log replication.

- TiKV uses Raft for data replication. Each data change will be placed in a Raft log. Through Raft's log replication function, the data is securely and reliably synchronized to each node of the replication group. However, in actual writing, according to Raft's protocol, it is only necessary to synchronously replicate to most node to safely assume that the data was written successfully.