Introduction and overall architecture of TiDB
Introduction to TiDB
TiDB is an open source distributed HTAP (Hybrid Transactional and Analytical Processing) database designed by PingCAP company inspired by Google Spanner / F1 paper, which combines the best features of traditional RDBMS and NoSQL. TiDB is compatible with MySQL, supports unlimited horizontal expansion, and has strong consistency and high availability. The goal of TiDB is to provide a one-stop solution for OLTP (Online Transactional Processing) and OLAP (Online Analytical Processing) scenarios.
TiDB has the following core features:
-
Highly compatible with MySQL
In most cases, it is easy to migrate from MySQL to TiDB without modifying the code, and the MySQL cluster after sub-database and sub-table can also be migrated in real time through the TiDB tool.
-
Horizontal elastic expansion
By simply adding new nodes, TiDB can scale horizontally, expand throughput or storage on demand, and easily cope with high concurrency and massive data scenarios.
-
Distributed transaction
TiDB 100% supports standard ACID transactions.
-
Real financial grade high availability
Compared with the traditional master-slave (MS) replication scheme, the Raft-based majority election protocol can provide financial-grade 100% strong data consistency guarantee, and can achieve automatic recovery of failures without losing most copies ( auto-failover) without manual intervention.
-
One-stop HTAP solution
As a typical OLTP row-to-store database, TiDB also has powerful OLAP performance. Together with TiSpark, it can provide a one-stop HTAP solution. One storage can handle OLTP & OLAP at the same time, without the need for traditional and cumbersome ETL processes.
-
Cloud-native SQL database
TiDB is a database designed for the cloud. It is deeply coupled with Kubernetes, supports public cloud, private cloud and hybrid cloud, making deployment, configuration and maintenance very simple.
The design goal of TiDB is 100% OLTP scenarios and 80% OLAP scenarios, and more complex OLAP analysis can be done through the TiSpark project .
TiDB is not intrusive to business, and can elegantly replace traditional database middleware, database sub-database sub-table and other sharding solutions. At the same time, it also allows development and operation and maintenance personnel to focus on business development without paying attention to the details of database scale, which greatly improves the productivity of research and development.
Three articles to understand the inside story of TiDB technology:
TiDB overall architecture
To deeply understand the horizontal expansion and high availability features of TiDB, you first need to understand the overall architecture of TiDB.
A TiDB cluster is mainly divided into three components:
TiDB Server
TiDB Server is responsible for receiving SQL requests, processing SQL-related logic, finding the TiKV address for storing the data required for computation through PD, interacting with TiKV to obtain data, and finally returning the result. TiDB Server is stateless. It does not store data itself, but is only responsible for computing. It can be scaled infinitely horizontally. It can provide a unified access address externally through load balancing components (such as LVS, HAProxy, or F5).
PD Server
Placement Driver (PD for short) is the management module of the entire cluster. It has three main tasks: one is to store the meta information of the cluster (which TiKV node a key is stored in); the other is to schedule and load balance the TiKV cluster (such as data The third is to assign a globally unique and incremental transaction ID.
PD is a cluster and needs to deploy an odd number of nodes. Generally, it is recommended to deploy at least 3 nodes online.
TiKV Server
TiKV Server 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 data of a Key Range (the left-closed and right-open interval from StartKey to EndKey), and each TiKV node is responsible for multiple Regions. TiKV uses the Raft protocol for replication to maintain data consistency and disaster tolerance. Replicas are managed in units of Regions, and multiple Regions on different nodes form a Raft Group, which are replicas of each other. The load balancing of data among multiple TiKVs is scheduled by PD, which is also scheduled in the unit of Region.
Core Features
Horizontal expansion
Unlimited horizontal expansion is a major feature of TiDB. The horizontal expansion mentioned here includes two aspects: computing power and storage capacity. TiDB Server is responsible for processing SQL requests. With business growth, you can simply add TiDB Server nodes to improve the overall processing capability and provide higher throughput. TiKV is responsible for storing data. As the amount of data grows, more TiKV Server nodes can be deployed to solve the problem of data scale. PD will schedule between TiKV nodes in units of Regions, and migrate some data to the newly added nodes. Therefore, in the early stage of the business, only a small number of service instances can be deployed (it is recommended to deploy at least 3 TiKV, 3 PD, and 2 TiDB). As the business volume grows, TiKV or TiDB instances can be added as required.
High availability
High availability is another major feature of TiDB. The three components of TiDB/TiKV/PD can tolerate partial instance failures without affecting the availability of the entire cluster. The availability of these three components, the consequences of a single instance failure, and how to recover are described below.
-
TiDB
TiDB is stateless. It is recommended to deploy at least two instances, and the front end provides external services through load balancing components. When a single instance fails, it will affect the session that is running on this instance. From the application point of view, a single request will fail, and the service can continue to be obtained after reconnection. After a single instance fails, you can restart the instance or deploy a new instance.
-
PD
PD is a cluster that maintains data consistency through the Raft protocol. When a single instance fails, if the instance is not the Raft leader, the service will not be affected at all; if the instance is the Raft leader, a new Raft leader will be re-elected , to automatically restore service. PD cannot provide external services during the election process, which is about 3 seconds. It is recommended to deploy at least three PD instances. After a single instance fails, restart the instance or add a new instance.
-
TiKV
TiKV is a cluster that maintains data consistency through the Raft protocol (the number of copies is configurable, and three copies are saved by default), and is scheduled for load balancing through PD. When a single node fails, it will affect all Regions stored on this node. For the Leader node in the Region, the service will be interrupted, waiting for re-election; for the Follower node in the Region, the service will not be affected. When a TiKV node fails and cannot be recovered within a period of time (30 minutes by default), the PD will migrate the data on it to other TiKV nodes.