# Tidb Architecture
__*TiDB features*__
+ Horizontal scale out or scale in
+ Financial-grade high availability
+ **HTAP** in real time
+ Cloud-native distributed database
+ Compatible with **MySQL 5.7** protocol

![right](./student-guide/diagram/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 (HTAP). It has horizontal scale out or scale in, high availability at financial level, 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 database are PD Cluster, TiDB Server, and TiKV.

Among them, the PD cluster is the control center of the entire TiDB database. It is responsible for generating global TSO timestamps, scheduling the distribution of region in TiKV nodes, collecting the health and distribution status of TiKV nodes, and assigning transaction IDs 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 landing data, but it is entirely responsible for receiving the SQL from the client, parse 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 TiKV node), high availability and strong consistency of transaction and their own replica (using the multi raft mechanism) implement), which I will cover in detail in the TiKV course.

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

Below, we will introduce the main functions, implement principles and features of TiDB, TiKV, TiFlash, and PD respectively.