{"id":21263,"date":"2026-09-18T14:04:57","date_gmt":"2026-09-18T21:04:57","guid":{"rendered":"https:\/\/www.pingcap.com\/article\/exploring-tidbs-distributed-sql-database-architecture\/"},"modified":"2026-09-18T14:11:49","modified_gmt":"2026-09-18T21:11:49","slug":"exploring-tidbs-distributed-sql-database-architecture","status":"publish","type":"article","link":"https:\/\/www.pingcap.com\/ko\/article\/exploring-tidbs-distributed-sql-database-architecture\/","title":{"rendered":"Exploring TiDB’s Distributed SQL Database Architecture"},"content":{"rendered":"

A single-node database becomes a single point of failure the moment your data outgrows one machine, and rewriting an application around a new query language to fix that is rarely an option. \ud2f0DB<\/a> was built to solve that specific problem: a distributed SQL database that scales horizontally while staying compatible with the MySQL protocol you already use. This piece walks through the three components that make that possible and how they hold together under node failure.<\/p>\n\n\n\n

<\/span>What Is TiDB’s Distributed SQL Architecture?<\/strong><\/span><\/h2>\n\n\n\n

TiDB’s architecture separates three concerns into three component types: the TiDB Server handles SQL parsing and query planning, TiKV stores the actual data as a distributed key-value store, and the Placement Driver (PD) manages cluster metadata and data placement. Each component type scales independently, so adding compute or storage capacity never requires resharding data by hand.<\/p>\n\n\n\n

<\/span>TiDB’s Key Components<\/strong><\/span><\/h2>\n\n\n\n

The architecture of TiDB consists of several key components that work in cohesion to deliver a reliable database solution: the TiDB Server<\/a>, TiKV<\/a>, and the Placement Driver (PD)<\/a>.<\/p>\n\n\n\n

\"TiDB<\/figure>\n\n\n\n

TiDB Server: SQL Processing Layer<\/strong><\/p>\n\n\n\n

The TiDB server acts as the SQL layer, managing client requests and generating execution plans for SQL queries. It is stateless, meaning it does not store data but handles SQL parsing, optimization, and execution plans. By separating compute from storage, the TiDB server is intrinsically scalable, and it provides a unified interface to applications through load balancing components such as Linux Virtual Server (LVS) and HAProxy.<\/p>\n\n\n\n

TiKV: Distributed Storage Engine<\/strong><\/p>\n\n\n\n

TiKV serves as the distributed storage engine for TiDB, responsible for storing data persistently. It is a key-value store built on the Raft consensus algorithm, ensuring data consistency and high availability. Each piece of data is stored in a region, and each region is replicated across three nodes by default. TiKV supports ACID transactions with snapshot isolation, enabling distributed transactions at the SQL level.<\/p>\n\n\n\n

Placement Driver (PD): Cluster Management<\/strong><\/p>\n\n\n\n

The Placement Driver (PD) manages cluster metadata, coordinates distributed transactions, and dynamically allocates transaction IDs. PD servers store metadata on data distribution and topology, and they monitor and balance the cluster by scheduling data across TiKV nodes based on real-time metrics.<\/p>\n\n\n\n

<\/span>Data Distribution and Replication in TiDB<\/strong><\/span><\/h2>\n\n\n\n

Sharding and Automatic Data Distribution<\/strong><\/p>\n\n\n\n

TiDB automatically shards tables into smaller chunks known as regions. Each region is a contiguous range of rows, managed independently. This approach distributes data across many nodes, providing balanced workload distribution and preventing bottlenecks. As data grows, regions split and redistribute dynamically, keeping data access and storage efficient.<\/p>\n\n\n\n

Consistent Hashing and Region Split<\/strong><\/p>\n\n\n\n

Consistent hashing manages the dynamic partitioning of key spaces across distributed nodes. When a region exceeds a certain size (96 MB by default), it automatically splits into two smaller regions, which are then distributed across different nodes for load balancing and scalability.<\/p>\n\n\n\n

Raft Protocol for Data Replication<\/strong><\/p>\n\n\n\n

The Raft protocol is central to TiDB’s reliability and data consistency. Raft achieves consensus among distributed nodes, ensuring that all replicas of a region hold the same data. In a Raft group, a leader elected through consensus handles client requests and log replication, and a majority of replicas must agree before a transaction commits.<\/p>\n\n\n\n

# Example: Checking Raft Leader in TiKV
tikv-ctl --host <TiKV-node-ip> raft --region <region-id> --show-region-id<\/code><\/pre>\n\n\n\n
<\/span>How TiDB’s Raft Architecture Solves Distributed Consistency<\/strong><\/span><\/h2>\n\n\n\n
Replicating data across many nodes creates a specific risk: replicas can drift out of sync, or a network partition can leave two nodes both believing they’re the leader. TiDB avoids this with a multi-Raft group architecture, where each region runs its own independent Raft group, so a delay or failure in one group never blocks the others. If a region’s leader becomes unavailable, Raft elects a new one from the surviving replicas automatically, and a transaction only commits once a majority of replicas confirm it, which is what keeps reads consistent even mid-failover.<\/p>\n\n\n\n
-- Example: Starting a Transaction in TiDB
START TRANSACTION;

-- Example: Performing a Write Operation
UPDATE users SET balance = balance + 100 WHERE user_id = 1;

-- Example: Committing the Transaction
COMMIT;<\/code><\/pre>\n\n\n\n
Rakuten<\/a> relies on this multi-Raft design to keep its loyalty program’s transactional data consistent while scaling out, without the manual failover runbooks a single-leader architecture would require.<\/p>\n\n\n\n
<\/span>Key Query Performance<\/strong><\/span><\/h2>\n\n\n\n
Load balancing components like LVS and HAProxy distribute incoming requests across TiDB servers so no single instance becomes a bottleneck as traffic grows. TiDB also applies cost-based query optimization and secondary indexes to generate efficient execution plans, and the TiFlash<\/a> columnar engine accelerates analytical queries without touching the transactional path.<\/p>\n\n\n\n
-- Example: Creating an Index in TiDB
CREATE INDEX idx_user_balance ON users(balance);

-- Example: Optimized Query Using Indexes
SELECT * FROM users WHERE balance > 1000;<\/code><\/pre>\n\n\n\n
<\/span>\uc790\uc8fc \ubb3b\ub294 \uc9c8\ubb38<\/strong><\/span><\/h2>\n\n\n\n
What are the three main components of TiDB’s architecture?<\/strong><\/p>\n\n\n\n