分布式数据库TiDB

当我们使用 Mysql数据库到达一定量级以后，性能就会逐步下降，而解决此类问题，常用的手段就是引入数据库中间件进行分库分表处理，比如使用 Mycat、ShadingShpere等，但是这种都是过去式了，现在使用分布式数据库可以避免分库分表

为什么不建议分库分表呢？

分库分表以后，会面临以下问题

• 分页问题，例如：使用传统写法，随着页数过大性能会急剧下降
• 分布式事务问题
• 数据迁移问题，例如：需要把现有数据通过分配算法导入到所有的分库中
• 数据扩容问题，分库分表的数据总有一天也会到达极限，需要增大分片
• 开发模式变化，比如在请求数据时，需要带分片键，否则就会导致所有节点执行
  跨库跨表查询问题
• 业务需要进行一定取舍，由于分库分表的局限性，有些场景下需要业务进行取舍

以上只是列举了一部分问题，为了避免这些问题，可以使用分布式数据库TiDB来处理

TiDB介绍

TiDB 是 PingCAP 公司设计的开源分布式 HTAP (Hybrid Transactional and Analytical Processing) 数据库，结合了传统的 RDBMS 和 NoSQL 的最佳特性。
TiDB 兼容 MySQL，支持无限的水平扩展，具备强一致性和高可用性。
TiDB 的目标是为 OLTP (Online Transactional Processing) 和 OLAP (Online Analytical Processing) 场景提供一站式的解决方案。

核心特性

• 金融级高可用
• 在线水平扩容或者缩容，并且存算分离
• 云原生的分布式数据库，支持部署在公有云，私有云，混合云中
• 实时HTAP，提供TIKV行存储引擎和TiFlash列存储引擎
• 兼容MySQL协议和MySQL生态
• 分布式事务强一致性
• 从 MySQL 无缝切换到 TiDB，几乎无需修改代码，迁移成本极低
• PD在分布式理论CAP方面满足CP，是强一致性的

系统架构

image.png
TiDB 集群主要包括三个核心组件：TiDB Server，PD Server 和 TiKV Server
TiDB Server
TiDB Server 负责接收 SQL 请求，处理 SQL 相关的逻辑，并通过 PD 找到存储计算所需数据的 TiKV 地址，与 TiKV 交互获取数据，最终返回结果。TiDB Server 是无状态的，其本身并不存储数据，只负责计算，可以无限水平扩展，可以通过负载均衡组件（如LVS、HAProxy 或 F5）对外提供统一的接入地址。
PD Server
Placement Driver (简称 PD) 是整个集群的管理模块，其主要工作有三个：一是存储集群的元信息（某个 Key 存储在哪个 TiKV 节点）；二是对 TiKV 集群进行调度和负载均衡（如数据的迁移、Raft group leader 的迁移等）；三是分配全局唯一且递增的事务 ID。
PD 通过 Raft 协议保证数据的安全性。Raft 的 leader server 负责处理所有操作，其余的 PD server 仅用于保证高可用。建议部署奇数个 PD 节点。
TiKV Server
TiKV Server 负责存储数据，从外部看 TiKV 是一个分布式的提供事务的 Key-Value 存储引擎。存储数据的基本单位是 Region，每个 Region 负责存储一个 Key Range（从 StartKey 到 EndKey 的左闭右开区间）的数据，每个 TiKV 节点会负责多个 Region。TiKV 使用 Raft 协议做复制，保持数据的一致性和容灾。副本以 Region 为单位进行管理，不同节点上的多个 Region 构成一个 Raft Group，互为副本。数据在多个 TiKV 之间的负载均衡由 PD 调度，这里也是以 Region 为单位进行调度。

TiKV如何做到数据不丢失？

image.png

简单理解，就是把数据复制到多台机器上，这样一个节点down 机，其他节点上的副本还能继续提供服务；复杂理解，需要这个数据可靠并且高效复制到其他节点，并且能处理副本失效的情况，那怎么做呢，就是使用 Raft一致性算法

与MySQL的对比

支持的特性

• 支持分布式事务，原理是基于Google Percolator，Percolator是基于Bigtable的，所以数据结构直接使用了Bigtable的Tablet。
• 支持锁，TIDB是乐观锁 +MVCC ，MySQL是悲观锁+MVCC，要注意TIDB执行Update、Insert、Delete时不会检查冲突，只有在提交时才会检查写写冲突，所以在业务端执行SQL语句后，要注意检查返回值，即使执行没有出错，提交的时候也可能出错。

不支持的功能特性

• 不支持存储过程、函数、触发器
• 自增id只支持在单个TIDB Server的自增，不支持多个TIDB Server的自增。
• 外键约束
• 临时表
• XA 语法（TiDB 内部使用两阶段提交，但并没有通过 SQL 接口公开）

总结

如果贵司的数据量比较大，正在考虑要分库分表，那么完全可以使用它，来避免分库分表，分库分表是一个过渡方案，使用分布式数据库才是终极方案。同时如果贵司的数据量比较小，那么就没必要引入了