An Overview of TiDB: NewSQL Distributed Database Architecture, Features, and MySQL Compatibility
This article provides a comprehensive introduction to TiDB, a NewSQL distributed database, covering its origins, core components, high‑availability design, NewSQL characteristics, differences from traditional SQL and NoSQL, compatibility with MySQL, configuration nuances, and typical use cases such as HTAP and cloud‑native deployments.
What is NewSQL
NewSQL is the third generation of databases that combines the scalability of NoSQL with the strong consistency and relational model of traditional SQL databases.
Problems of Traditional SQL
As internet traffic grew, single‑node relational databases became bottlenecks. Scaling by upgrading hardware hits limits, while sharding introduces complexity and middleware.
Problems of NoSQL
NoSQL offers high availability and horizontal scaling but sacrifices strong consistency, full SQL support, and relational features.
NewSQL Characteristics
NewSQL provides NoSQL‑level elasticity, retains ACID transactions, uses a distributed architecture, and supports complex queries and analytics.
Key Features of TiDB (NewSQL)
SQL support with MySQL 5.7 protocol compatibility.
Horizontal elastic scaling and automatic sharding.
Strong consistency via Raft‑based replication.
Distributed ACID transactions.
Real‑time HTAP using TiKV (row store) and TiFlash (column store) together with TiSpark.
Cloud‑native deployment on Kubernetes.
TiDB Core Components
TiDB Server
Stateless SQL layer that receives queries, parses them, and forwards data requests to TiKV through PD.
Placement Driver (PD)
Manages metadata, schedules region placement, and allocates global transaction IDs.
TiKV Server
Distributed transactional key‑value store; data is split into regions and replicated via Raft.
TiSpark & TiFlash
TiSpark runs Spark SQL on TiKV for OLAP workloads; TiFlash stores data column‑wise for fast analytical queries.
High‑Availability Architecture
TiDB, PD, and TiKV each form Raft clusters; loss of a minority of nodes does not affect overall service availability.
Compatibility with MySQL
TiDB speaks the MySQL 5.7 protocol, allowing most MySQL clients and tools to work unchanged, though some features (stored procedures, triggers, foreign keys, etc.) are not supported.
Configuration Differences
Default character set is utf8mb4 , case‑insensitive table names ( lower_case_table_names=2 ), and timestamp handling differs from MySQL 5.7.
Use Cases
Replacing MySQL with TiDB for seamless horizontal scaling.
MySQL sharding consolidation via TiDB as a unified backend.
Data‑warehouse workloads using TiDB’s HTAP capabilities.
Embedding TiKV as a distributed KV store for other systems.
Architect's Guide
Dedicated to sharing programmer-architect skills—Java backend, system, microservice, and distributed architectures—to help you become a senior architect.
How this landed with the community
Was this worth your time?
0 Comments
Thoughtful readers leave field notes, pushback, and hard-won operational detail here.