{"id":26248,"date":"2026-09-03T14:06:10","date_gmt":"2026-09-03T21:06:10","guid":{"rendered":"https:\/\/www.pingcap.com\/?post_type=article&p=26248"},"modified":"2026-09-03T14:06:12","modified_gmt":"2026-09-03T21:06:12","slug":"exploring-distributed-databases-tidbs-architecture-benefits","status":"publish","type":"article","link":"https:\/\/www.pingcap.com\/ko\/article\/exploring-distributed-databases-tidbs-architecture-benefits\/","title":{"rendered":"Exploring Distributed Databases: TiDB’s Architecture & Benefits"},"content":{"rendered":"

People explain distributed database architecture at two levels. The first is the general one: replication, consensus, horizontal scale. The second is the level that decides whether a given system fits your workload, which is what its components actually are and what each one is responsible for. This page is about the second level for \ud2f0DB<\/a>: the four components, how Raft keeps them consistent, and the one architectural choice that separates it from other distributed SQL databases.<\/p>\n\n\n\n

<\/span>What a Distributed Database Has to Solve<\/strong><\/span><\/h2>\n\n\n\n

Every distributed database is answering the same three questions, and its architecture is the answer. How does data get spread across nodes without losing consistency? Why does the system keep serving when a node dies? How does it balance load as data grows unevenly?<\/p>\n\n\n\n

The general trade-offs behind those questions, the benefits against a single node and the operational costs that come with distribution, are covered in our guide to distributed database use cases<\/a> and in the piece on decentralized cloud computing<\/a>. The rest of this page is specific: how TiDB answers all three.<\/p>\n\n\n\n

<\/span>TiDB\u2019s Architecture: Components and Communication<\/strong><\/span><\/h2>\n\n\n\n

TiDB separates compute from storage across four components, each of which scales independently.<\/p>\n\n\n\n

Component<\/strong><\/th>Layer<\/strong><\/th>What it does<\/strong><\/th><\/tr><\/thead>
TiDB server<\/td>Stateless SQL<\/td>Parses SQL, plans and optimizes queries, and coordinates reads and writes. Because it holds no data, instances can be added or removed without touching storage.<\/td><\/tr>
TiKV<\/td>Row storage<\/td>Stores data in ranges, each replicated across nodes as its own Raft group. Serves transactional reads and writes.<\/td><\/tr>
TiFlash<\/td>Columnar storage<\/td>Keeps a columnar replica of the same data as a Raft learner. Serves analytical queries.<\/td><\/tr>
PD (Placement Driver)<\/td>Cluster coordination<\/td>Tracks metadata and data distribution, schedules where replicas live, and transfers Raft leadership to balance load. It does not elect Raft leaders; each Raft group does that itself.<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n

That separation is what lets one cluster serve transactional and analytical workloads at once, which is the definition of a hybrid transactional\/analytical processing (HTAP) database. It is worth naming what it rules out. Distributed SQL databases built for OLTP alone still need a second, separately maintained system for analytics. Cockroach Labs positions CockroachDB<\/a>, the closest comparison on consensus design, for transactional workloads and expects analytics to land in a separate system through change data capture.TiKV and TiFlash stay in sync inside one cluster, so that second system, and the pipeline that feeds it, does not exist here.<\/p>\n\n\n\n

<\/span>Data Consistency and Fault Tolerance in TiDB<\/strong><\/span><\/h2>\n\n\n\n

TiDB uses Raft consensus<\/a> for replication and two-phase commit for transactions, and the distinction matters. TiKV replicates each range of data across nodes as a Raft group, and a write to that range becomes durable once a majority of its replicas acknowledge it.. A transaction that touches multiple ranges commits through two-phase commit across those groups, so it is atomic even though no single node holds all of it.<\/p>\n\n\n\n

Fault tolerance falls out of the same design. Every range has multiple replicas, so when a node fails, only the Raft groups it belonged to elect new leaders, and every other range keeps serving uninterrupted. There is no cluster-wide failover event and no single primary to promote.<\/p>\n\n\n\n

<\/span>Scalability and Load Balancing in TiDB<\/strong><\/span><\/h2>\n\n\n\n

TiDB scales out by adding nodes, and the compute-storage separation is what makes that transparent to applications. Add TiDB servers for query capacity, add TiKV nodes for storage and write throughput, and add TiFlash nodes for analytical capacity. No resharding, and no application changes.<\/p>\n\n\n\n

Load balancing is PD\u2019s job. PD watches where data and traffic land across the cluster and moves replicas and Raft leadership as workloads shift, so a range that suddenly gets hot doesn’t pin one node while others sit idle.<\/p>\n\n\n\n

<\/span>TiDB in Production: MNC Bank, Flipkart, and Trip.com<\/strong><\/span><\/h2>\n\n\n\n

Three deployments show what the architecture buys across different pressures.<\/p>\n\n\n\n