Yuan Chuang Solicitation | Introduction to domestic database TiDB related knowledge

TiDB is an open source distributed HTAP (Hybrid Transactional and Analytical Processing) database developed and designed by PingCAP, which combines the best features of traditional relational and non-relational databases. TiDB is compatible with MySQL, supports unlimited horizontal expansion, and has strong consistency and high availability.

And provide one-stop OLTP (Online Transactional Processing), OLAP (Online Analytical Processing), HTAP solutions

2. Composition of TiDB

TiDB mainly includes three core components: TiDB Server, PD Server and TiKV Server. Let me briefly introduce it to you.

2.1 TiDB Server

It belongs to the SQL layer and is the connection endpoint that exposes the MySQL protocol to the outside world. It is mainly responsible for accepting client connections, performing SQL parsing and optimization, and finally generating a distributed execution plan. The TiDB layer itself is stateless, and multiple TiDB instances can be started, and a unified access address is provided externally through load balancing components (such as LVS, HAProxy, or F5). Client connections can be evenly distributed among multiple TiDB instances to achieve The effect of load balancing. TiDB Server itself does not store data, but is only responsible for parsing SQL and forwarding actual data read requests to the underlying storage node TiKV (or TiFlash)

2.2 PD Server（PD）

PD is mainly responsible for the meta information management module of the entire TiDB cluster.

Responsible for storing the real-time data distribution of each TiKV node and the overall topology of the cluster, providing the TiDB Dashboard management and control interface, and assigning transaction IDs to distributed transactions.
PD not only stores meta information, but also sends data scheduling commands to specific TiKV nodes according to the real-time data distribution status reported by TiKV nodes.
PD consists of at least 3 nodes and has high availability capabilities. PD ensures data security through the Raft protocol. It is generally recommended to deploy an odd number of PD nodes.

2.3 TiKV Server

TiKV Server is mainly 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, and each Region is responsible for storing the data of a Key Range (the left-closed 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 recovery.

3. Key features of TiDB

3.1 Highly compatible with MySQL

In most cases, you can easily migrate from MySQL to TiDB database without adjusting the code, and the MySQL cluster after sub-database and table division can also be migrated in real time through TiDB tools.

3.2 Horizontal elastic expansion

TiDB can be scaled horizontally by simply adding new nodes, expanding throughput or storage according to business needs, and easily handling high concurrency and massive data scenarios. The on-demand approach can also save a lot of cost.

3.3 Distributed transactions

TiDB fully supports standard ACID transactions.

3.4 Financial level high availability

Compared with the traditional master-slave replication scheme, the majority election protocol based on Raft can provide financial-level 100% data strong consistency guarantee, and can realize automatic recovery of failures without losing most of the copies. intervention processing.

3.5 One-stop HTAP solution

As a typical OLTP row-storage database, TiDB also has powerful OLAP performance. With TiSpark, it can provide a one-stop HTAP solution. One storage can handle both OLTP & OLAP (introduction and comparison of OLAP and OLTP) without the traditional cumbersome ETL process.

3.6 Cloud Native SQL Database

TiDB is a database designed for cloud services. It can be deeply coupled with Kubernetes containerization technology and supports public clouds, private clouds, and hybrid clouds. Make installation, deployment, configuration and maintenance very simple.

4. Applicable scenarios

4.1 Tens of millions of data storage

TiDB is more suitable for large tables with at least tens of millions of rows, or T-level data in the space occupied by the database schema; if the data storage size is less than 500G and the query volume per second or the concurrency is small, it is recommended to use mysql.

4.2 High concurrency

If your concurrent volume is more than 100,000, you can use TiDB to save the trouble of middleware and sub-database sub-table.

4.3 Insufficient operation and maintenance personnel

TiDB can automatically maintain strong consistency and high availability of data, greatly reducing the work of database operation and maintenance.