Don't divide the database and table anymore, let's try it

• What is NewSQL
• Problems with traditional SQL
  • Upgrade server hardware
  • data sharding
• The problem with NoSQL
  • advantage
  • shortcoming
• NewSQL features
• Key Features of NewSQL
• Comparison of three kinds of SQL
• How did TiDB come about?
• TiDB Community Edition and Enterprise Edition
• TIDB Core Features
  • Horizontal elastic expansion
  • Distributed transaction support
  • Financial grade high availability
  • Real-time HTAP
  • Cloud native distributed database
  • Highly compatible with MySQL
• OLTP&OLAP (self-study)
  • OLTP (Online Transaction Processing)
  • OLAP (Online Analytical Processing)
  • feature comparison
  • Design Angle Difference
• TiDB overall architecture
• Advantages of TiDB
• Components of TiDB
  • TiDB Server
  • PD（Placement Driver）Server
  • TiKV Server
  • TiSpark
  • TiFlash
• Overall structure of TiKV
  • Region split and merge
  • Region Scheduling
  • distributed transaction
• High availability architecture
  • TiDB High Availability
  • PD high availability
  • TiKV High Availability
• Application Scenario
  • MySQL fragmentation and merging
  • Direct replacement for MySQL
  • database
  • as a module for other systems
• Applications
• Compatibility comparison between TiDB and MySQL
• MySql features not supported by TiDB
• auto-increment ID
• Limitations of SELECT
• view
• Differences in default settings
  • character set
  • collation
  • Case Sensitive
  • parameter explanation
  • timestamp type field update
  • parameter explanation
  • foreign key support

TiDB is a distributed NewSQL database. It supports horizontal elastic expansion, ACID transactions, standard SQL, MySQL syntax, and MySQL protocol, and has high-availability features with strong data consistency. It is a hybrid database that is not only suitable for OLTP scenarios but also for OLAP scenarios.

TiDB is an open source distributed relational database independently designed and developed by PingCAP. It is an integrated distributed database product that supports both online transaction processing and online analytical processing (Hybrid Transactional and Analytical Processing, HTAP). Important features such as capacity, financial-level high availability, real-time HTAP, cloud-native distributed database, compatibility with MySQL 5.7 protocol and MySQL ecology.

目标是为用户提供一站式 OLTP (Online Transactional Processing)、OLAP (Online Analytical Processing)、HTAP 解决方案。TiDB 适合高可用、强一致要求较高、数据规模较大等各种应用场景。

什么是NewSQL

数据库发展至今已经有3代了：

1. SQL，传统关系型数据库，例如 MySQL
2. noSQL，例如 MongoDB,Redis
3. newSQL

传统SQL的问题

互联网在本世纪初开始迅速发展，互联网应用的用户规模、数据量都越来越大，并且要求7X24小时在线。

传统关系型数据库在这种环境下成为了瓶颈，通常有2种解决方法：

升级服务器硬件

虽然提升了性能，但总有天花板。

数据分片

使用分布式集群结构

对单点数据库进行数据分片，存放到由廉价机器组成的分布式的集群里，可扩展性更好了，但也带来了新的麻烦。

以前在一个库里的数据，现在跨了多个库，应用系统不能自己去多个库中操作，需要使用数据库分片中间件。

分片中间件做简单的数据操作时还好，但涉及到跨库join、跨库事务时就很头疼了，很多人干脆自己在业务层处理，复杂度较高。

NoSQL 的问题

后来 noSQL 出现了，放弃了传统SQL的强事务保证和关系模型，重点放在数据库的高可用性和可扩展性。

优点

• 高可用性和可扩展性，自动分区，轻松扩展
• 不保证强一致性，性能大幅提升
• 没有关系模型的限制，极其灵活

缺点

• 不保证强一致性，对于普通应用没问题，但还是有不少像金融一样的企业级应用有强一致性的需求。
• 不支持 SQL 语句，兼容性是个大问题，不同的 NoSQL 数据库都有自己的 api 操作数据，比较复杂。

NewSQL 特性

NewSQL 提供了与 noSQL 相同的可扩展性，而且仍基于关系模型，还保留了极其成熟的 SQL 作为查询语言，保证了ACID事务特性。

简单来讲，NewSQL 就是在传统关系型数据库上集成了 NoSQL 强大的可扩展性。

传统的SQL架构设计基因中是没有分布式的，而 NewSQL 生于云时代，天生就是分布式架构。

Key Features of NewSQL

• SQL support for complex queries and big data analysis.
• Support ACID transaction, support isolation level.
• Elastic scaling, capacity expansion and contraction are completely transparent to the business layer.
• High availability and automatic disaster recovery.

Comparison of three kinds of SQL

picture

How did TiDB come about?

The author of the famous open source distributed caching service Codis, co-founder & CTO of PingCAP, Huang Dongxu, a senior infrastructure engineer, is good at the design and implementation of distributed storage systems, and is a technical master of open source fanatics. Even when the Internet is so prosperous today, in the blurred and uncertain area of ​​the database, he is still trying to find a deterministic practice direction.

Until the end of 2012, he saw the two papers published by Google, like a prism, refracting the light in his own heart. These two papers describe F1/Spanner, a massive relational database used internally by Google, which solves the problems of relational databases, elastic expansion, and global distribution, and is used in production on a large scale. "If this can be realized, it will be subversive for the field of data storage." Huang Dongxu was excited about the emergence of the perfect solution, and PingCAP's TiDB was born on this basis.

TiDB Community Edition and Enterprise Edition

TiDB is divided into community edition and enterprise edition. The enterprise edition provides services and security support for a fee.

picture

TIDB Core Features

Horizontal elastic expansion

Horizontal expansion of TiDB can be realized by simply adding new nodes, and throughput or storage can be expanded on demand to easily cope with high concurrency and massive data scenarios

Thanks to the design of TiDB's storage-computing-separated architecture, computing and storage can be expanded or reduced online as needed, and the process of expansion or reduction is transparent to application operation and maintenance personnel.

Distributed transaction support

TiDB 100% supports standard ACID transactions

Financial grade high availability

Compared with the traditional master-slave (MS) replication scheme, the Raft-based majority election protocol can provide financial-level 100% data strong consistency guarantee, and can realize automatic failure recovery without losing most copies ( auto-failover), without manual intervention

数据采用多副本存储，数据副本通过 Multi-Raft 协议同步事务日志，多数派写入成功事务才能提交，确保数据强一致性且少数副本发生故障时不影响数据的可用性。可按需配置副本地理位置、副本数量等策略满足不同容灾级别的要求。

实时 HTAP

TiDB 作为典型的 OLTP 行存数据库，同时兼具强大的 OLAP 性能，配合 TiSpark，可提供一站式 HTAP 解决方案，一份存储同时处理 OLTP & OLAP 无需传统繁琐的 ETL 过程

提供行存储引擎 TiKV、列存储引擎 TiFlash 两款存储引擎，TiFlash 通过 Multi-Raft Learner 协议实时从 TiKV 复制数据，确保行存储引擎 TiKV 和列存储引擎 TiFlash 之间的数据强一致。TiKV、TiFlash 可按需部署在不同的机器，解决 HTAP 资源隔离的问题。

云原生的分布式数据库

TiDB 是为云而设计的数据库，同 Kubernetes 深度耦合，支持公有云、私有云和混合云，使部署、配置和维护变得十分简单。TiDB 的设计目标是 100% 的 OLTP 场景和 80% 的 OLAP 场景，更复杂的 OLAP 分析可以通过 TiSpark 项目来完成。TiDB 对业务没有任何侵入性，能优雅的替换传统的数据库中间件、数据库分库分表等 Sharding 方案。同时它也让开发运维人员不用关注数据库 Scale 的细节问题，专注于业务开发，极大的提升研发的生产力

高度兼容 MySQL

兼容 MySQL 5.7 协议、MySQL 常用的功能、MySQL 生态，应用无需或者修改少量代码即可从 MySQL 迁移到 TiDB。

提供丰富的数据迁移工具帮助应用便捷完成数据迁移，大多数情况下，无需修改代码即可从 MySQL 轻松迁移至 TiDB，分库分表后的 MySQL 集群亦可通过 TiDB 工具进行实时迁移。

OLTP&OLAP(自学)

OLTP(联机事务处理)

OLTP(Online Transactional Processing) 即联机事务处理，OLTP 是传统的关系型数据库的主要应用，主要是基本的、日常的事务处理，记录即时的增、删、改、查，比如在银行存取一笔款，就是一个事务交易

联机事务处理是事务性非常高的系统，一般都是高可用的在线系统，以小的事务以及小的查询为主，评估其系统的时候，一般看其每秒执行的Transaction以及Execute SQL的数量。在这样的系统中，单个数据库每秒处理的Transaction往往超过几百个，或者是几千个，Select 语句的执行量每秒几千甚至几万个。典型的OLTP系统有电子商务系统、银行、证券等，如美国eBay的业务数据库，就是很典型的OLTP数据库。

OLAP(联机分析处理)

OLAP(Online Analytical Processing) 即联机分析处理，是数据仓库的核心部心，支持复杂的分析操作，侧重决策支持，并且提供直观易懂的查询结果。典型的应用就是复杂的动态报表系统

在这样的系统中，语句的执行量不是考核标准，因为一条语句的执行时间可能会非常长，读取的数据也非常多。所以，在这样的系统中，考核的标准往往是磁盘子系统的吞吐量（带宽），如能达到多少MB/s的流量。

特性对比

OLTP和OLAP的特性对比

—OLTPOLAP real-time OLTP has high real-time requirements. The OLTP database is designed to allow transactional applications to write only the required data so that a single transaction can be processed as soon as possible. The real-time requirements of OLAP are not very high, and many applications update data every day at most. Volume OLTP data volume is not very large, generally only read/write dozens of records, and handle simple transactions. OLAP data volume is large, because OLAP supports dynamic query, so users may have to count a lot of data before they can get what they want. Known information, such as time series analysis, etc., so the amount of data processed is large. User and system-oriented OLTP is customer-oriented, and is used for transaction and query processing. OLAP is market-oriented, and is used for data analysis. Database design OLTP adopts Entity-Relationship ER Model and Application-Oriented Database Design OLAP Using Star or Snowflake Schema and Subject-Oriented Database Design

Design Angle Difference

—OLTPOLAP user operators, low-level managers, decision-makers, senior managers, functions, daily operations, processing, analysis, decision-making, main work, addition, deletion, modification, query DB design, application-oriented, topic-oriented data, current, latest details, two-dimensional, discrete history Single, aggregated, multi-dimensional integrated, unified access read/write dozens of records read millions of records unit of work simple transaction complex query thousands of users hundreds of DB size 100MB-GB100GB-TB

TiDB overall architecture

Advantages of TiDB

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

• Purely distributed architecture, with good scalability, supports flexible expansion and contraction
• Supports SQL, exposes MySQL's network protocol to the outside world, and is compatible with most MySQL syntaxes, and can directly replace MySQL in most scenarios
• High availability is supported by default. In the case of a small number of replicas failing, the database itself can automatically perform data repair and failover, which is transparent to the business
• Supports ACID transactions, and is friendly to some scenarios with strong consistency requirements, such as bank transfers
• Has a rich tool chain ecology, covering data migration, synchronization, backup and other scenarios

Components of TiDB

To gain a deep understanding of TiDB's horizontal expansion and high availability features, you first need to understand the overall architecture of TiDB. The TiDB cluster mainly includes three core components: TiDB Server, PD Server, and TiKV Server. In addition, there is a TiSpark component for solving complex OLAP needs of users.

In terms of core design, the TiDB distributed database splits the overall architecture into multiple modules, and each module communicates with each other to form a complete TiDB system. The corresponding architecture diagram is as follows:

picture

architecture

TiDB Server

TiDB Server is responsible for receiving SQL requests, processing SQL-related logic, finding the TiKV address for storing data required for calculation through PD, interacting with TiKV to obtain data, and finally returning the result. TiDB Server is stateless, it does not store data itself, it is only responsible for computing, it can be expanded horizontally indefinitely, and can provide a unified access address externally through load balancing components (such as LVS, HAProxy or F5).

PD (Placement Driver) Server

Placement Driver (referred to as PD) 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 second is to schedule and load balance the TiKV cluster (such as data migration, Raft group leader migration, etc.);
• The third is to assign a globally unique and incremental transaction ID.

PD ensures data security through the Raft protocol. The leader server of Raft is responsible for handling all operations, and the remaining PD servers are only used to ensure high availability. It is recommended to deploy an odd number of PD nodes

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, 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. 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 units of Regions.

TiSpark

TiSpark, as the main component in TiDB to solve users' complex OLAP needs, runs Spark SQL directly on the TiDB storage layer, and at the same time integrates the advantages of TiKV distributed clusters and integrates into the big data community ecology. So far, TiDB can support both OLTP and OLAP through one system, eliminating the trouble of user data synchronization.

TiFlash

TiFlash is a special type of storage node. Different from ordinary TiKV nodes, inside TiFlash, data is stored in the form of columns, and its main function is to accelerate analytical scenarios.

Overall structure of TiKV

Different from the traditional full-node backup method, TiKV divides the data into approximately equal slices (hereinafter collectively referred to as Regions) according to the range of the key. Each slice has multiple copies (usually 3), one of which is Leader, providing read and write services. TiKV schedules these Regions and replicas through PD to ensure that data and read and write loads are evenly distributed on each TiKV. This design ensures full utilization of the entire cluster resource and can be scaled horizontally as the number of machines increases.

picture

Region split and merge

当某个 Region 的大小超过一定限制（默认是 144MB）后，TiKV 会将它分裂为两个或者更多个 Region，以保证各个 Region 的大小是大致接近的，这样更有利于 PD 进行调度决策。同样，当某个 Region 因为大量的删除请求导致 Region 的大小变得更小时，TiKV 会将比较小的两个相邻 Region 合并为一个。

Region调度

Region 与副本之间通过 Raft 协议来维持数据一致性，任何写请求都只能在 Leader 上写入，并且需要写入多数副本后（默认配置为 3 副本，即所有请求必须至少写入两个副本成功）才会返回客户端写入成功。

当 PD 需要把某个 Region 的一个副本从一个 TiKV 节点调度到另一个上面时，PD 会先为这个 Raft Group 在目标节点上增加一个 Learner 副本（复制 Leader 的数据）。当这个 Learner 副本的进度大致追上 Leader 副本时，Leader 会将它变更为 Follower，之后再移除操作节点的 Follower 副本，这样就完成了 Region 副本的一次调度。

Leader 副本的调度原理也类似，不过需要在目标节点的 Learner 副本变为 Follower 副本后，再执行一次 Leader Transfer，让该 Follower 主动发起一次选举成为新 Leader，之后新 Leader 负责删除旧 Leader 这个副本。

分布式事务

TiKV 支持分布式事务，用户（或者 TiDB）可以一次性写入多个 key-value 而不必关心这些 key-value 是否处于同一个数据切片 (Region) 上，TiKV 通过两阶段提交保证了这些读写请求的 ACID 约束。

高可用架构

高可用是 TiDB 的另一大特点，TiDB/TiKV/PD 这三个组件都能容忍部分实例失效，不影响整个集群的可用性。下面分别说明这三个组件的可用性、单个实例失效后的后果以及如何恢复。

TiDB高可用

TiDB is stateless. It is recommended to deploy at least two instances, and the front end provides external services through the load balancing component. When a single instance fails, it will affect the ongoing Session on this instance. From the application point of view, there will be a single request failure, and the service can continue to be obtained after reconnecting. After a single instance fails, it can be restarted or a new instance deployed.

PD high availability

PD is a cluster that maintains data consistency through the Raft protocol. When a single instance fails, if the instance is not the leader of Raft, the service will not be affected at all; if the instance is the leader of Raft, a new Raft leader will be re-elected , to automatically restore service. PD cannot provide external services during the election process, and this time 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 High Availability

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 uses PD for load balancing scheduling. 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 and wait 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 (10 minutes by default), PD will migrate the data on it to other TiKV nodes.

Application Scenario

MySQL fragmentation and merging

picture

The first type of scenario where TiDB is applied is the sharding and merging of MySQL. For businesses that already use MySQL, database sharding, table sharding, sharding, and middleware are commonly used methods. With the increase of shards, cross-shard query is a big problem. TiDB is compatible with the MySQL access protocol at the business layer. PingCAP has created a data synchronization tool - Syncer, which can use Huang Dongxu TiDB as a MySQL Slave, and connect TiDB as the slave library of the existing database behind the main MySQL library. This layer connects the data and can directly perform complex cross-database, cross-table, and cross-business real-time SQL queries. Huang Dongxu mentioned, "In the past, databases had one master and multiple slaves. With TiDB, it can be reversed to achieve multiple masters and one slave."

Direct replacement for MySQL

picture

The second type of scenario is to directly replace MySQL with TiDB. If your IT architecture does not consider the problem of sub-database and sub-table at the beginning of construction, and all use MySQL. With the rapid growth of business, there are more and more massive and high-concurrency OLTP scenarios. How to solve the disadvantages of the architecture?

On a TiDB database, all business scenarios do not need to be divided into databases and tables, and all distributed work is done by the database layer. TiDB is compatible with the MySQL protocol, so it can directly replace MySQL, and it basically works out of the box. There is no need to worry about the heavy workload and complicated maintenance costs brought by the traditional database and table division scheme. The friendly user interface allows regular technicians to Maintenance and management can be performed efficiently. In addition, TiDB has a capacity similar to that of NoSQL, and can improve the business support capability of the system through horizontal expansion when the amount of data and access traffic continue to grow, and the response delay is stable.

database

picture

TiDB itself is a distributed system, and the third usage scenario is to use TiDB as a data warehouse. TPC-H is a test set in the field of data analysis. The performance of TiDB 2.0 in OLAP scenarios has been greatly improved. Some complex queries that can only be run in the data warehouse can be run in TiDB 2.0, and the time can basically be controlled. within 10 seconds. Of course, because the scope of OLAP is very large, TiDB's SQL is also uncertain. For this reason, PingCAP has open sourced TiSpark. TiSpark is a Spark plug-in. Users can directly use Spark SQL to do big data analysis on TiKV in real time.

as a module for other systems

picture

TiDB is a traditional project that separates storage and computing. Its underlying Key-Value layer can be used alone as an HBase replacement, and it supports cross-row transactions. TiDB provides two API interfaces externally, one is ACID Transaction API, which is used to support cross-row transactions; the other is Raw API, which can do single-row transactions in exchange for overall performance improvement, but does not provide ACID for cross-row transactions support. Users can choose between the two APIs according to their own needs. For example, some users have directly implemented the Redis protocol on top of TiKV, replacing TiKV with some Redis scenarios with large capacity and low latency requirements.

Applications

picture

Compatibility comparison between TiDB and MySQL

• TiDB supports the MySQL   transport protocol and most of its syntax. This means that your existing MySQL connectors and clients will continue to work. In most cases, your existing applications can be migrated to TiDB without any code modification.
• The current officially supported version of the TiDB server is MySQL 5.7  . Most MySQL operation and maintenance tools (such as PHPMyAdmin, Navicat, MySQL Workbench, etc.), as well as backup and recovery tools (such as mysqldump, Mydumper/myloader) can be used directly.
• However, because some features cannot be implemented well in a distributed environment, they are not supported for the time being or their performance is different from MySQL.
• Some MySQL syntax can be parsed and passed in TiDB, but no subsequent processing will be done . For example, the Engine in the Create Table statement is parsed and ignored.

MySql features not supported by TiDB

• stored procedures and functions
• trigger
• event
• custom function
• foreign key constraints
• Temporary tables
• Full-text/spatial functions and indexes
• Non- ascii/latin1/binary/utf8/utf8mb4  character set
• SYS schema
• MySQL 追踪优化器
• XML 函数
• X-Protocol
• Savepoints
• 列级权限
• XA 语法（TiDB 内部使用两阶段提交，但并没有通过 SQL 接口公开）
• CREATE TABLE tblName AS SELECT stmt 语法
• CHECK TABLE 语法
• CHECKSUM TABLE 语法
• GET_LOCK 和 RELEASE_LOCK 函数

自增ID

TiDB 的自增列仅保证唯一，也能保证在单个 TiDB server 中自增，但不保证多个 TiDB server 中自增，不保证自动分配的值的连续性，建议不要将缺省值和自定义值混用，若混用可能会收 Duplicated Error 的错误信息。

TiDB 可通过 tidb_allow_remove_auto_inc 系统变量开启或者关闭允许移除列的 AUTO_INCREMENT 属性。删除列属性的语法是：alter table modify 或 alter table change。

TiDB 不支持添加列的 AUTO_INCREMENT 属性，移除该属性后不可恢复。

SELECT 的限制

• 不支持 SELECT ... INTO @变量 语法。
• 不支持 SELECT ... GROUP BY ... WITH ROLLUP 语法。
• TiDB 中的 SELECT .. GROUP BY expr 的返回结果与 MySQL 5.7 并不一致。MySQL 5.7 的结果等价于 GROUP BY expr ORDER BY expr。而 TiDB 中该语法所返回的结果并不承诺任何顺序，与 MySQL 8.0 的行为一致。

视图

目前TiDB不支持 对视图进行UPDATE、INSERT、DELETE等写入操作 。

默认设置差异

字符集

• TiDB 默认：utf8mb4。
• MySQL 5.7 默认：latin1。
• MySQL 8.0 默认：utf8mb4。

排序规则

• TiDB 中 utf8mb4 字符集默认：utf8mb4_bin。
• MySQL 5.7 中 utf8mb4 字符集默认：utf8mb4_general_ci。
• MySQL 8.0 中 utf8mb4 字符集默认：utf8mb4_0900_ai_ci。

大小写敏感

关于lower_case_table_names的配置

TiDB 默认：2，且仅支持设置该值为 2。

MySQL 默认如下：

• Linux 系统中该值为 0

• Windows 系统中该值为 1

• macOS 系统中该值为 2

参数解释

• lower_case_table_names=0 表名存储为给定的大小和比较是区分大小写的
• lower_case_table_names = 1 表名存储在磁盘是小写的，但是比较的时候是不区分大小写
• lower_case_table_names=2 表名存储为给定的大小写但是比较的时候是小写的

timestamp类型字段更新

默认情况下，timestamp类型字段所在数据行被更新时，该字段会自动更新为当前时间，而参数explicit_defaults_for_timestamp控制这一种行为。

• TiDB 默认：ON，且仅支持设置该值为 ON。
• MySQL 5.7 默认：OFF。
• MySQL 8.0 默认：ON。

参数解释

• explicit_defaults_for_timestamp=off，数据行更新时，timestamp类型字段更新为当前时间
• explicit_defaults_for_timestamp=on，数据行更新时，timestamp类型字段不更新为当前时间。

外键支持

• TiDB 默认：OFF，且仅支持设置该值为 OFF。
• MySQL 5.7 默认：ON。