Basic Architecture

Compared with traditional stand-alone databases, TiDB has the following advantages:

• Pure distributed architecture, with good scalability, supporting elastic scaling
• Support SQL, expose MySQL network protocol, compatible with most MySQL syntax, and can directly replace MySQL in most scenarios
• High availability supported by default. When a few replicas fail, the database itself can automatically perform data repair and failover, which is transparent to the business.
• Support ACID transactions, and friendly to some scenarios with strong consistency requirements, such as: Bank transfer
• It features a rich tool chain ecology, covering data migration, synchronization, backup and other scenarios.

In terms of kernel design, TiDB Service divides the overall architecture into multiple modules, which communicate with each other to form a complete TiDB system. The corresponding architecture diagram is as follows:

Architecture diagram

• TiDB Server: SQL layer, which exposes the connection endpoint of MySQL protocol, is responsible for accepting connections from clients, performing SQL parsing and optimization, and finally generating a distributed execution plan. The TiDB layer itself is stateless. In practice, multiple TiDB instances can be booted, and a unified access address is provided externally through load balance components (such as LVS, HAProxy or F5). Client connections can be evenly distributed on multiple TiDB instances to achieve load balance. TiDB Server itself does not store data, but only parses SQL and forwards the actual data read requests to the underlying storage node TiKV (or TiFlash).

• PD (Placement Driver) Server: The meta information management module of the entire TiDB cluster, is responsible for storing the real-time data distribution of each TiKV node and the overall topology of the cluster, providing TiDB Dashboard control interface and assigning transaction IDs for distributed transactions. PD not only stores meta information, bu also issues data scheduling commands to specific TiKV nodes according to the real-time data distribution status reported by TiKV nodes, which can be said to be the “brain” of the entire cluster. Furthermore, PD itself is also composed of at least 3 nodes, with high availability. It is recommended to deploy an odd number of PD nodes.

• Storage Node

  • TiKV Server: It is responsible for storing data. From the outside, TiKV is a distributed key-value storage engine that provides transactions. The basic unit for storing data is region. Each region is responsible for storing the data of a key range (left-closed and right-open interval from StartKey to EndKey). Each TiKV node is responsible for multiple regions. TiKV’s API offers a native support for distributed transactions at the KV key-value pair level, and provides the isolation level of SI (Snapshot Isolation) by default, which is also the core of TiDB’s support for distributed transactions at the SQL level. After SQL parsing is completed for the SQL layer of TiDB, it will convert the SQL execution plan into the actual call to the TiKV API. Therefore, the data is stored in TiKV. Besides, the data in TiKV will automatically maintain multiple replicas (three replicas by default), which naturally supports high availability and automatic failover.
  • TiFlash: TiFlash is a special type of storage node. Unlike ordinary TiKV nodes, in TiFlash, data is stored in column-based form, mainly used for accelerating analysis-based scenarios.