这是我参与8月更文挑战的第8天,活动详情查看:8月更文挑战
PingCAP 自研的分布式关系型数据库,实现了 HTAP = OLTP + OLAP。
高可用、强一致性、数据规模大(聚合计算)。
兼容 MySQL 5.7 协议 和 MySQL 生态。
一、主要组件
1. TiDB Server
- 角色:接收客户端连接的服务端;
- SQL 解析和优化,生成分布式执行计划;
2. TiKV Server
- 角色:行存储引擎;
- 存储层:以 Region 为单位存储数据;
- 副本:默认 3个,提供高可用和自动故障转移;
3. TiFlash
- 角色:列存储引擎;
- 用法:通过 Multi-Raft Learner 协议(多数派写入成功后才算成功),从 TiKV 异步复制数据;
- tiflash proxy:用于处理 Multi-Raft 协议通信相关工作;
- pd buddy:负责与 PD 协同工作
4. PD Server
- 角色:元信息层,存储数据分布情况、集群整体拓扑结构;
- 为分布式事务分配 ID;
- 下发数据调度命令:(1)TiKV 节点定时汇报心跳信息(含磁盘容量、负载、拓扑结构/标签;Raft Group Leader 上报 Region 健康等信息)(2)故障转移、增删节点(3)平衡各节点的 Store 存储使用(4)通过参数设置,调节调度速度;
- 提供 Dashboard UI;
5. PD Server - Dashboard UI
- Cluster Info:集群各组件的监控;
- Key Visualizer:可视化集群的流量监控;
- SQL Statements:SQL执行的统计数据;
- Slow Queries:慢查询日志;
- Diagnostic Report:定期自我诊断汇报;
- Log Search & Download:可视化日志检索;
6. RocksDB
基于 LevelDB 开发的键值存储与读写功能的 LSM-tree 架构引擎。
- 角色:用于存储 Raft 日志(raftdb)和 用户数据+MVCC信息(kvdb);
- 原理:键值对先写入 WAL(Writer Ahead Log),再写入 SkipList(MemTable)。内存数据达到阈值后,会被刷到 SST(Sorted String Table)文件。这样设计的优点是将随机写转化为顺序写,得到更高的吞吐量。
- SST 划分为 6层,每一层达到阈值后被合并转入下一层。通常每一层是上一层数据的 10倍。
- Titan:基于 RocksDB 的高性能存储引擎插件。
7. TiSpark
待定
8. TiDB Operator
9. TiUP
- Compoent 组件管理功能:组件安装卸载等;
- Cluster 集群管理功能:部署与变更操作;
- Playground 本地部署功能:快速部署测试环境;
- Mirror 私有镜像管理功能:可构建私有镜像,离线部署;
- Beachmark 性能测试功能:TPC-C/TPC-H;
10. 与 MySQL 兼容
- AUTO_INCREMENT 自增ID:单个 TiDB 实例内自增,不保证多个 TiDB 中连续自增(实现原理:提前申请连续的 ID 段,其他实例无法使用);
- AUTO_RANDOM 随机ID:不保证连续,只保证唯一;
- SHARD_ROW_ID_BITS 表属性未设置主键时会设置此项,会将数据打散写入到多个不同的 Region 中,缓解写入热点问题。默认 0 表示 1个分片,设置 4 则表示 2^4 = 16 个分片;
二、存储思想
- 总体以 KV 结构存储;
- 底层为 RocksDB(Facebook 单机高性能 KV 存储引擎);
- Raft 协议:采用 Raft 日志来同步复制各副本的数据;
- Region:数据按 key 分布到多个 Region。一个 Region 的多个副本(Replica)组成 Raft Group。默认读写操作都在 Group Leader 上执行。
- MVCC:在 key 后面添加版本号;
- ACID:采用事务模型 Percolator
三、主要特性
- 兼容MySQL协议
- 支持事务
- 支持索引
- 稳定可靠
- 备份/恢复/容灾
- 可扩展