pandaAnthony：分布式数据库TiDB

1、背景

传统的数据库单表超过千万级别性能会急剧下降，不满足某些行业的业务需求（电商之类数据量巨大的）。
那么怎么解决这种大数据量的存储呢，大体有2种方式：1、使用分布式存储来解决这个问题（nosql，大数据hadoop的hdfs）；2、数据库分库分表。

NoSQL，泛指非关系型的数据库，具体分类如下：

image.png

数据库分库分表有不少成熟的框架，具体如下：

image.png

其中用得比较多的应该是MyCAT（需要服务端），官网地址http://www.mycat.org.cn/。
还有以前当当的shardingjdbc（不需要服务端），现在改名成shardingsphere（也有支持服务端的sharding-proxy），官网地址http://shardingsphere.apache.org/。

其中nosql的方案不支持数据库的ACID，只能保证最终一致性；
分库分表可以解决问题，但是会引进不少其他的问题需要解决，而且对运维的难度有所提升；这里有一篇介绍分库分表方案的不足的帖子https://dbaplus.cn/news-11-1854-1.html

2、TiDB简介

在各种解决方案都不是非常好的情况下，诞生了一种新的数据库newsql：NewSQL 是对各种新的可扩展/高性能数据库的简称，这类数据库不仅具有NoSQL对海量数据的存储管理能力，还保持了传统数据库支持ACID和SQL等特性。
这里有一篇关于newsql的帖子可以了解下：https://cloud.tencent.com/developer/article/1445846
其中TiDB是用go开发的一款newsql，官网地址是https://pingcap.com/。git地址https://github.com/pingcap

TiDB 是 PingCAP 公司自主设计、研发的开源分布式关系型数据库，是一款同时支持在线事务处理与在线分析处理 (Hybrid Transactional and Analytical Processing, HTAP）的融合型分布式数据库产品，具备水平扩容或者缩容、金融级高可用、实时 HTAP、云原生的分布式数据库、兼容 MySQL 5.7 协议和 MySQL 生态等重要特性。目标是为用户提供一站式 OLTP (Online Transactional Processing)、OLAP (Online Analytical Processing)、HTAP 解决方案。TiDB 适合高可用、强一致要求较高、数据规模较大等各种应用场景。

2.1、TiDB 整体架构

与传统的单机数据库相比，TiDB 具有以下优势：

• 纯分布式架构，拥有良好的扩展性，支持弹性的扩缩容
• 支持 SQL，对外暴露 MySQL 的网络协议，并兼容大多数 MySQL 的语法，在大多数场景下可以直接替换 MySQL
• 默认支持高可用，在少数副本失效的情况下，数据库本身能够自动进行数据修复和故障转移，对业务透明
• 支持 ACID 事务，对于一些有强一致需求的场景友好，例如：银行转账
• 具有丰富的工具链生态，覆盖数据迁移、同步、备份等多种场景

在内核设计上，TiDB 分布式数据库将整体架构拆分成了多个模块，各模块之间互相通信，组成完整的 TiDB 系统。对应的架构图如下：

architecture

• TiDB Server：SQL 层，对外暴露 MySQL 协议的连接 endpoint，负责接受客户端的连接，执行 SQL 解析和优化，最终生成分布式执行计划。TiDB 层本身是无状态的，实践中可以启动多个 TiDB 实例，通过负载均衡组件（如 LVS、HAProxy 或 F5）对外提供统一的接入地址，客户端的连接可以均匀地分摊在多个 TiDB 实例上以达到负载均衡的效果。TiDB Server 本身并不存储数据，只是解析 SQL，将实际的数据读取请求转发给底层的存储节点 TiKV（或 TiFlash）。

• PD Server：整个 TiDB 集群的元信息管理模块，负责存储每个 TiKV 节点实时的数据分布情况和集群的整体拓扑结构，提供 TiDB Dashboard 管控界面，并为分布式事务分配事务 ID。PD 不仅存储元信息，同时还会根据 TiKV 节点实时上报的数据分布状态，下发数据调度命令给具体的 TiKV 节点，可以说是整个集群的“大脑”。此外，PD 本身也是由至少 3 个节点构成，拥有高可用的能力。建议部署奇数个 PD 节点。

• 存储节点

  • TiKV Server：负责存储数据，从外部看 TiKV 是一个分布式的提供事务的 Key-Value 存储引擎。存储数据的基本单位是 Region，每个 Region 负责存储一个 Key Range（从 StartKey 到 EndKey 的左闭右开区间）的数据，每个 TiKV 节点会负责多个 Region。TiKV 的 API 在 KV 键值对层面提供对分布式事务的原生支持，默认提供了 SI (Snapshot Isolation) 的隔离级别，这也是 TiDB 在 SQL 层面支持分布式事务的核心。TiDB 的 SQL 层做完 SQL 解析后，会将 SQL 的执行计划转换为对 TiKV API 的实际调用。所以，数据都存储在 TiKV 中。另外，TiKV 中的数据都会自动维护多副本（默认为三副本），天然支持高可用和自动故障转移。
  • TiFlash：TiFlash 是一类特殊的存储节点。和普通 TiKV 节点不一样的是，在 TiFlash 内部，数据是以列式的形式进行存储，主要的功能是为分析型的场景加速。

2.2、与 MySQL 兼容性对比概览

基本上mysql的基本功能都支持：

• TiDB 100% 兼容 MySQL 5.7 协议、MySQL 5.7 常用的功能及语法。MySQL 5.7 生态中的系统工具（PHPMyAdmin、Navicat、MySQL Workbench、mysqldump、Mydumper/Myloader）、客户端等均用于 TiDB。
• 由于 TiDB 是一款分布式数据库，MySQL 5.7 中的部分特性因工程实现难度较大，投入产出比较低等多种原因在 TiDB 中未能实现或者仅兼容语法但功能并没有实现，因此使用过程中请特别注意。例如：CREATE TABLE 语句中 ENGINE，仅兼容语法，功能并没有实现，因此 TiDB 中没有 ENGINE 这类的概念。

不支持的功能特性：

• 存储过程与函数
• 触发器
• 事件
• 自定义函数
• 外键约束
• 全文/空间函数与索引
• 非 ascii/latin1/binary/utf8/utf8mb4 的字符集
• SYS schema
• MySQL 追踪优化器
• XML 函数
• X Protocol
• Savepoints
• 列级权限
• XA 语法（TiDB 内部使用两阶段提交，但并没有通过 SQL 接口公开）
• CREATE TABLE tblName AS SELECT stmt 语法
• CREATE TEMPORARY TABLE 语法
• CHECK TABLE 语法
• CHECKSUM TABLE 语法

更详细的内容查看官网：https://docs.pingcap.com/zh/tidb/stable/mysql-compatibility

2.3、TiDB 软件和硬件环境建议配置

TiDB对于硬件的要求不是很低，存储的TiKv和TiFlash都需要固态硬盘，尤其是用于分析的TiFlash内存和cpu要求比较高（这里暂时就不介绍怎么安装了）：

image.png

其他配置详见：https://pingcap.com/docs-cn/stable/hardware-and-software-requirements/

2.4、适用场景

• 对数据一致性及高可靠、系统高可用、可扩展性、容灾要求较高的金融行业属性的场景
  众所周知，金融行业对数据一致性及高可靠、系统高可用、可扩展性、容灾要求较高。传统的解决方案是同城两个机房提供服务、异地一个机房提供数据容灾能力但不提供服务，此解决方案存在以下缺点：资源利用率低、维护成本高、RTO (Recovery Time Objective) 及 RPO (Recovery Point Objective) 无法真实达到企业所期望的值。TiDB 采用多副本 + Multi-Raft 协议的方式将数据调度到不同的机房、机架、机器，当部分机器出现故障时系统可自动进行切换，确保系统的 RTO <= 30s 及 RPO = 0 。
• 对存储容量、可扩展性、并发要求较高的海量数据及高并发的 OLTP 场景
  随着业务的高速发展，数据呈现爆炸性的增长，传统的单机数据库无法满足因数据爆炸性的增长对数据库的容量要求，可行方案是采用分库分表的中间件产品或者 NewSQL 数据库替代、采用高端的存储设备等，其中性价比最大的是 NewSQL 数据库，例如：TiDB。TiDB 采用计算、存储分离的架构，可对计算、存储分别进行扩容和缩容，计算最大支持 512 节点，每个节点最大支持 1000 并发，集群容量最大支持 PB 级别。
• Real-time HTAP 场景
  随着 5G、物联网、人工智能的高速发展，企业所生产的数据会越来越多，其规模可能达到数百 TB 甚至 PB 级别，传统的解决方案是通过 OLTP 型数据库处理在线联机交易业务，通过 ETL 工具将数据同步到 OLAP 型数据库进行数据分析，这种处理方案存在存储成本高、实时性差等多方面的问题。TiDB 在 4.0 版本中引入列存储引擎 TiFlash 结合行存储引擎 TiKV 构建真正的 HTAP 数据库，在增加少量存储成本的情况下，可以同一个系统中做联机交易处理、实时数据分析，极大地节省企业的成本。
• 数据汇聚、二次加工处理的场景
  当前绝大部分企业的业务数据都分散在不同的系统中，没有一个统一的汇总，随着业务的发展，企业的决策层需要了解整个公司的业务状况以便及时做出决策，故需要将分散在各个系统的数据汇聚在同一个系统并进行二次加工处理生成 T+0 或 T+1 的报表。传统常见的解决方案是采用 ETL + Hadoop 来完成，但 Hadoop 体系太复杂，运维、存储成本太高无法满足用户的需求。与 Hadoop 相比，TiDB 就简单得多，业务通过 ETL 工具或者 TiDB 的同步工具将数据同步到 TiDB，在 TiDB 中可通过 SQL 直接生成报表。

最后，一些合作案例和PingCAP公司相关的文章地址http://www.ctoutiao.com/c/74735854/