# TiDB Architecture
  + Components:
    + Placement Driver (PD) Cluster
    + TiDB Cluster with Application Connections using MySQL protocol
    + Storage Cluster (TiKV TiFlash)
    + Spark Cluster Connections using Spark SQL	
![left](./student-guide/diagram/TiDBArchitecture_aa_001_20220524.png)
------------------------------------------------------------
Components:
  - PD Cluster (Process Control)
  - TiDB Cluster (TiDB Databases) <-> Application via MySQL Protocol
  - Storage Cluster (TiKV/TiFlash)
  - Spark/ Spark Cluster/TiSPark <-> Sparl SQL

When we are talking about TiDB in the cloud we are still talking about TiDB Architecture with the functionality that exists on prem.
In the Cloud TiDB is still responsible for managing TiDB architecture components.

The components in the image above are fully automatically hosted by the TiDB Cloud control plane and turned on according to the tenant's purchase needs.
  - Note: AWS and GCP accounts still need to be manually opened and managed . After designing the Prod OU unit permission boundary and Prod's Group and Role and Policy templates, there is Security as Code management related to security operations, and application functions can be managed by Infra as Code Managed , but before integrating into Code, any Role and Policy need to pass Security Review to avoid automatic integration of Role and Policy. The permissions are too large and uncontrollable .

The TiKV server is responsible for storing data.  TiKV is a distributed transactional key-value storage engine. Region is the basic unit to store data. Each Region stores the data for a particular Key Range which is a left-closed and right-open interval from StartKey to EndKey. Multiple Regions exist in each TiKV node. TiKV APIs provide native support to distributed transactions at the key-value pair level and supports the Snapshot Isolation level isolation by default. This is the core of how TiDB supports distributed transactions at the SQL level.  After processing SQL statements, the TiDB server converts the SQL execution plan to an actual call to the TiKV API. Therefore, data is stored in TiKV. All the data in TiKV is automatically maintained in multiple replicas (three replicas by default), so TiKV has native high availability and supports automatic failover.

TiFlash server is a special type of storage server.  Unlike ordinary TiKV nodes, TiFlash stores data by column, mainly designed to accelerate analytical processing.
As we distribute and replicate data in Regions, we have a distributed Key-Value system that, to some extent, has the capability of disaster recovery. You no longer need to worry about the capacity, or disk failure and data loss.

TiDB uses the Raft consensus algorithm to ensure that data is highly available and safely replicated throughout storage in Raft Groups. Data is redundantly copied between storage nodes and placed in different availability zones to protect against machine or data center failures. With automatic failover, TiDB ensures that your service is always on.TiDB Cloud clusters consist of three major components: TiDB node, TiKV node, and TiFlash node. The highly availability implementation of each component is as follows:

  - TiDB node
  TiDB is for computing only and does not store data. It is horizontally scalable. TiDB Cloud deploys TiDB nodes equally to different availability zones in a region. It is recommended that you configure at least two TiDB nodes in each TiDB Cloud cluster for high availability.

  - TiKV node
  TiKV is for storing data. It is horizontally scalable and the number of nodes should be at least 1 set (3 nodes in 3 different availability zones). The data in TiKV of each TiDB Cloud cluster has 3 replicas, and each replica is stored in three different TiKV nodes which are distributed in three different availability zones.

  - TiFlash(beta) node
  As a columnar storage extension of TiKV, TiFlashbeta is the key component that makes TiDB essentially a Hybrid Transactional/Analytical Processing (HTAP) database. In TiFlashbeta, the columnar replicas are asynchronously replicated according to the Raft Learner consensus algorithm. To save the cost of data transfer between TiFlashbeta nodes, TiDB Cloud deploys all TiFlashbeta nodes of one TiDB Cloud cluster in one availability zone in a region. It is recommended that you configure at least two TiFlashbeta nodes in each TiDB Cloud cluster and create at least 2 replicas of the data for high availability in yourproduction environment.