Why TiDB Is Revolutionizing Distributed Databases: Architecture, Use Cases, and HTAP

As hardware becomes more cost‑effective and network speeds increase, the trend toward database layering emerges, allowing caches and databases to handle the workloads they excel at.

Huang Dongxu notes that modern databases face challenges in scaling, consistency, big‑data analytics, and cloud integration. Traditional systems like Oracle and MySQL were not built for distributed environments, leading to fragmented solutions; NoSQL solves elasticity but sacrifices strong consistency and ACID support.

TiDB addresses these issues by heavily abstracting and separating compute and storage layers. It employs I/O priority queues, intelligent replica scheduling, and hybrid row‑column storage, achieving near‑full MySQL compatibility while preserving ACID transactions, offering elastic scaling, high availability, and the ability to handle both OLTP and OLAP workloads without ETL.

TiDB’s architecture consists of a distributed SQL layer (TiDB), a distributed KV storage engine (TiKV), and a PD module that manages the cluster, enabling unlimited horizontal scaling of both compute and storage resources.

HTAP (Hybrid Transactional/Analytical Processing) offers developers a new approach to real‑time data analysis, eliminating the need for separate offline data warehouses, reducing ETL effort, and cutting storage and compute costs.

Use Case 1: MySQL Sharding and Merging

TiDB can act as a MySQL slave via the Syncer tool, allowing existing MySQL deployments to treat TiDB as a downstream replica, enabling complex cross‑shard, cross‑table, and cross‑business real‑time SQL queries. This reverses the traditional master‑slave model to a multi‑master‑single‑slave setup.

Use Case 2: Direct MySQL Replacement

When an application’s architecture was originally built solely on MySQL, rapid growth can expose scalability limits. TiDB replaces MySQL without requiring sharding; the distributed layer handles scaling, offering MySQL‑compatible protocols, out‑of‑the‑box deployment, and NoSQL‑like elasticity. Mobike, for example, migrated from MySQL to TiDB in 2017 and now runs multiple TiDB clusters with hundreds of nodes handling tens of terabytes of data.

Use Case 3: Data Warehouse

TiDB can serve as a data warehouse; in TPC‑H benchmarks, TiDB 2.0 delivers OLAP query times under ten seconds. For workloads beyond TiDB’s native SQL, PingCAP provides TiSpark, a Spark plugin that enables real‑time big‑data analysis on TiKV.

Use Case 4: Module for Other Systems

The KV layer of TiDB can replace systems like HBase and supports cross‑row transactions via an ACID Transaction API. A Raw API offers single‑row operations with higher performance but without ACID guarantees. Some users have implemented the Redis protocol on top of TiKV for high‑capacity, latency‑tolerant caching scenarios.