TiDB

TiDB can expand both SQL processing and storage capacity by adding new nodes. This makes infrastructure capacity scaling easier and more flexible compared to traditional relational databases which only scale vertically.

TiDB acts like it is a MySQL 5.7 server to applications. A user can continue to use all of the existing MySQL client libraries.[7] Because TiDB's SQL processing layer is built from scratch, not a MySQL fork, its compatibility is not 100%, and there are known behavior differences between MySQL and TiDB.[8]

TiDB internally shards a table into small range-based chunks that are referred to as "Regions".[9] Each Region defaults to approximately 100 MB in size, and TiDB uses a two-phase commit internally to ensure that regions are maintained in a transactionally consistent way.

TiDB is designed to work in the cloud to make deployment, provisioning, operations, and maintenance flexible. The storage layer of TiDB, called TiKV, became a Cloud Native Computing Foundation (CNCF) member project in August 2018, as a Sandbox level project,[10] and became an incubation-level hosted project in May 2019.[11] TiKV graduated from CNCF in September 2020.[12] The architecture of the TiDB platform also allows SQL processing and storage to be scaled independently of each other.

TiDB can support both online transaction processing (OLTP) and online analytical processing (OLAP) workloads. TiDB has two storage engines: TiKV, a rowstore, and TiFlash, a columnstore. Data can be replicated from TiKV to TiFlash in real time to ensure that TiFlash processes the latest data.

TiDB uses the Raft consensus algorithm[13] to ensure that data is highly available and safely replicated throughout storage in Raft groups. In the event of failure, a Raft group will automatically elect a new leader for the failed member, and self-heal the TiDB cluster without any required manual intervention. Failure and self-healing operations are transparent to the applications.

TiDB can be deployed in a Kubernetes-enabled cloud environment by using TiDB Operator.[14] An Operator is a method of packaging, deploying, and managing a Kubernetes application. It is designed for running stateful workloads and was first introduced by CoreOS in 2016.[15] TiDB Operator[16] was originally developed by PingCAP and open-sourced in August, 2018.[17] TiDB Operator can be used to deploy TiDB on a laptop,[18] Google Cloud Platform’s Google Kubernetes Engine,[19] and Amazon Web Services’ Elastic Container Service for Kubernetes.[20]

TiDB 4.0 introduces TiUP, a cluster operation and maintenance tool. It helps users quickly install and configure a TiDB cluster with a few commands.[21]

TiDB can be deployed using Ansible by using a TiDB Ansible playbook (not recommended).[22]

Docker can be used to deploy TiDB in a containerized environment on multiple nodes and multiple machines, and Docker Compose can be used to deploy TiDB with a single command for testing purposes.[23]

TiDB Data Migration (DM) is suited for replicating data from already sharded MySQL or MariaDB tables to TiDB.[24] A common use case of DM is to connect MySQL or MariaDB tables to TiDB, treating TiDB almost as a slave, then directly run analytical workloads on this TiDB cluster in near real-time.

Backup & Restore (BR) is a distributed backup and restore tool for TiDB cluster data. It offers high backup and restore speeds for large-scale TiDB clusters.[25]

Dumpling is a data export tool that exports data stored in TiDB or MySQL. It lets users make logical full backups or full dumps from TiDB or MySQL.[26]

TiDB Lightning is a tool that supports high speed full-import of a large MySQL dump into a new TiDB cluster, providing a faster import experience than executing each SQL statement. This tool is used to quickly populate an initially empty TiDB cluster with much data, in order to speed up testing or production migration. The import speed improvement is achieved by parsing SQL statements into key-value pairs, then directly generate Sorted String Table (SST) files to RocksDB.[27][28]

TiDB Binlog is a tool used to collect the logical changes made to a TiDB cluster. It is used to provide incremental backup and replication, either between two TiDB clusters, or from a TiDB cluster to another downstream platform.[29]

It is similar in functionality to MySQL primary-secondary replication. The main difference is that since TiDB is a distributed database, the binlog generated by each TiDB instance needs to be merged and sorted according to the time of the transaction commit before being consumed downstream.[30]