TiDB介绍

769 阅读3分钟

这是我参与8月更文挑战的第8天,活动详情查看:8月更文挑战

PingCAP 自研的分布式关系型数据库,实现了 HTAP = OLTP + OLAP。

高可用、强一致性、数据规模大(聚合计算)。

兼容 MySQL 5.7 协议 和 MySQL 生态。

一、主要组件

1. TiDB Server

  1. 角色:接收客户端连接的服务端;
  2. SQL 解析和优化,生成分布式执行计划;

2. TiKV Server

  1. 角色:行存储引擎
  2. 存储层:以 Region 为单位存储数据;
  3. 副本:默认 3个,提供高可用和自动故障转移;

3. TiFlash

  1. 角色:列存储引擎
  2. 用法:通过 Multi-Raft Learner 协议(多数派写入成功后才算成功),从 TiKV 异步复制数据;
  3. tiflash proxy:用于处理 Multi-Raft 协议通信相关工作;
  4. pd buddy:负责与 PD 协同工作

4. PD Server

  1. 角色:元信息层,存储数据分布情况、集群整体拓扑结构;
  2. 为分布式事务分配 ID;
  3. 下发数据调度命令:(1)TiKV 节点定时汇报心跳信息(含磁盘容量、负载、拓扑结构/标签;Raft Group Leader 上报 Region 健康等信息)(2)故障转移、增删节点(3)平衡各节点的 Store 存储使用(4)通过参数设置,调节调度速度;
  4. 提供 Dashboard UI

5. PD Server - Dashboard UI

  1. Cluster Info:集群各组件的监控;
  2. Key Visualizer:可视化集群的流量监控;
  3. SQL Statements:SQL执行的统计数据;
  4. Slow Queries:慢查询日志;
  5. Diagnostic Report:定期自我诊断汇报;
  6. Log Search & Download:可视化日志检索;

6. RocksDB

基于 LevelDB 开发的键值存储与读写功能的 LSM-tree 架构引擎。

  1. 角色:用于存储 Raft 日志(raftdb)和 用户数据+MVCC信息(kvdb);
  2. 原理:键值对先写入 WAL(Writer Ahead Log),再写入 SkipList(MemTable)。内存数据达到阈值后,会被刷到 SST(Sorted String Table)文件。这样设计的优点是将随机写转化为顺序写,得到更高的吞吐量。
  3. SST 划分为 6层,每一层达到阈值后被合并转入下一层。通常每一层是上一层数据的 10倍。
  4. Titan:基于 RocksDB 的高性能存储引擎插件。

7. TiSpark

待定

8. TiDB Operator

云部署工具

9. TiUP

  1. Compoent 组件管理功能:组件安装卸载等;
  2. Cluster 集群管理功能:部署与变更操作;
  3. Playground 本地部署功能:快速部署测试环境;
  4. Mirror 私有镜像管理功能:可构建私有镜像,离线部署;
  5. Beachmark 性能测试功能:TPC-C/TPC-H;

10. 与 MySQL 兼容

  1. AUTO_INCREMENT 自增ID:单个 TiDB 实例内自增,不保证多个 TiDB 中连续自增(实现原理:提前申请连续的 ID 段,其他实例无法使用);
  2. AUTO_RANDOM 随机ID:不保证连续,只保证唯一;
  3. SHARD_ROW_ID_BITS 表属性未设置主键时会设置此项,会将数据打散写入到多个不同的 Region 中,缓解写入热点问题。默认 0 表示 1个分片,设置 4 则表示 2^4 = 16 个分片;

二、存储思想

  1. 总体以 KV 结构存储;
  2. 底层为 RocksDB(Facebook 单机高性能 KV 存储引擎);
  3. Raft 协议:采用 Raft 日志来同步复制各副本的数据;
  4. Region:数据按 key 分布到多个 Region。一个 Region 的多个副本(Replica)组成 Raft Group。默认读写操作都在 Group Leader 上执行。
  5. MVCC:在 key 后面添加版本号;
  6. ACID:采用事务模型 Percolator

三、主要特性

  1. 兼容MySQL协议
  2. 支持事务
  3. 支持索引
  4. 稳定可靠
  5. 备份/恢复/容灾
  6. 可扩展