# TiDB Architecture

+ Horizontal scale-out and scale-in
+ Financial-grade high availability
+ HTAP in real time
+ Cloud-native distributed database
+ Compatible with MySQL protocol

![`smart`](TiDBClusterArchitectureNormal_aa_001_20220506.png)

-------------------------------------------------------------------------------------
TiDB, a distributed relational database, is a converged distributed database product that supports both Online Transactional Processing and Online Analytical Processing (Hybrid Transactional and Analytical Processing). It has horizontal scale out or scale in, high availability at financial-grade, real-time HTAP, and cloud important features such as a native distributed database, compatibility with the MySQL 5.7 protocol, and the MySQL ecosystem.

The three key components of the TiDB are PD cluster, TiDB cluster, and TiKV cluster.

Among them, the PD cluster is the control center of the entire TiDB. It is responsible for generating global TSO timestamps, scheduling the distribution of region in TiKV nodes, collecting the health and load balancing status of TiKV nodes, and assigning transaction ID to distributed transaction. PD itself is also composed of at least 3 nodes and has high availability capabilities, so it is recommended to deploy an odd number of PD nodes.

The TiDB server cluster does not store business data, but it is responsible for receiving the SQL statements from the client, parsing and compiling the SQL statements, and finally generating the execution plan. Finally, TiDB server is responsible for executing these execution plans, accessing data in TiKV or TiFlash storage engines, and organizing the result set and return it to the client. Finally, the recovery (GC) of DDL operations and old version data is also done by TiDB server. The TiDB layer itself is stateless. In practice, multiple TiDB instances can be started to provide a uniform access address to the outside world through load balancing components (such as LVS, HAProxy or F5), and client connections can be evenly distributed across multiple TiDB instances to achieve load balancing effects.

The data is mainly stored in the TiKV cluster in the form of key-value. The TiKV cluster is mainly responsible for data persistence, MVCC (multi-version concurrency control), Coprocessor (pushing the operator down to the underlying storage node), high availability and strong consistency of transaction and their own replication implementation (using the multi Raft mechanism), which we will cover in detail in the TiKV chapters.

Here, we also have another component, TiFlash, a columnar storage engine. It mainly synchronizes data with TiKV through the Raft consensus algorithm, which realizes load balancing and strong consistent read, and TiFlash supports real-time replication. In this way, analysis query service isolation is realized for OLTP scenario, and query efficiency is greatly improved for OLAP scenarios.