Understanding TiDB’s Architecture: How TiKV, PD, and TiDB Server Work Together

Preface

After a few days of study, I have gained a basic understanding of the TiDB database and now summarize its architecture.

Overall Framework

TiDB consists of three core components—TiDB Server, PD Server, and TiKV Server—plus the TiSpark component for complex OLAP needs. A single‑node deployment runs all three components; production clusters are typically deployed with Ansible.

A complete TiDB cluster framework is shown below:

TiKV Server

TiKV Server is responsible for data storage and must provide the following capabilities:

Cross‑data‑center disaster recovery

High write throughput

Efficient read performance

Support for data modification and concurrent updates

Atomicity for multi‑record transactions

TiKV uses a key‑value model with ordered iteration. Keys are stored in binary order, allowing sequential scans via a Next operation.

The storage model is independent of SQL tables; TiKV is essentially a large, distributed map.

Data is persisted to disk through RocksDB, a high‑performance single‑node engine maintained by Facebook.

To achieve no data loss and cross‑data‑center replication, TiDB relies on the Raft consensus algorithm, which has been heavily optimized by PingCAP.

Raft provides leader election, membership changes, and log replication.

TiKV writes data via Raft; each change becomes a Raft log entry that is replicated to a majority of nodes in the Raft group, ensuring safety even if a node fails.

The storage flow is illustrated below:

TiKV stores data in regions, each covering a contiguous key range (default size ≤ 64 MiB). Regions are distributed evenly across nodes for horizontal scaling and load balancing. A PD component tracks region placement, enabling lookup of the region and node for any key.

Each region has multiple replicas (a Raft group). One replica acts as the leader; others are followers. All reads and writes go through the leader, which replicates changes to followers.

Diagram of region replication:

In short, TiKV is a distributed key‑value storage engine, a massive ordered map.

PD Server

The Placement Driver (PD) is the global control node of TiDB, responsible for cluster scheduling.

Information Collection

PD gathers two types of heartbeat information:

1. Store heartbeats

Each TiKV store periodically reports its status, including total and available disk capacity, number of regions, write speed, snapshot counts, overload status, and label information.

2. Raft group leader heartbeats

Leaders report region status such as leader location, follower locations, number of down replicas, and read/write speeds.

PD uses this data to make scheduling decisions. It can also receive manual updates via its management API, for example to mark a store as offline immediately.

Scheduling Strategies

Ensure each region has the correct number of replicas.

Distribute replicas of a Raft group across different stores.

Balance replica count evenly among stores.

Evenly distribute leaders among stores.

Spread hot regions (high read/write load) across stores.

Keep storage usage roughly equal across stores.

Control scheduling speed to avoid impacting online services.

Support manual node decommissioning.

PD integrates etcd for auto‑failover and uses etcd’s Raft to guarantee strong consistency. It also generates global IDs, timestamps (TSO), and provides routing information to clients.

TiDB Server

TiDB Server receives SQL requests, parses MySQL protocol packets, performs syntax analysis, query planning, optimization, and execution, and interacts with PD to locate the required TiKV data. It is stateless and can be horizontally scaled behind load balancers such as LVS or HAProxy.

Because TiKV is a key‑value engine, TiDB must translate SQL to KV operations; the mapping details are beyond this summary.

TiSpark

TiSpark (Spark SQL on TiKV) addresses complex OLAP workloads by running Spark SQL directly on TiDB’s storage layer, combining TiKV’s distributed advantages with TiDB’s HTAP capabilities. Using TiSpark requires a separate Spark cluster.

Conclusion

TiKV Server handles storage, PD Server manages scheduling, TiDB Server performs computation, and the Raft protocol ensures data safety and consistency across the distributed TiDB database.

Official Documentation

https://pingcap.com/docs-cn/