TIDB是一款分布式关系型数据库。它同时支持在线事务处理(OLTP)和在线分析处理(HTAP)。
它的处理时延在几十ms到若干秒。承诺在秒级内响应。支持乐观事务、悲观事务、可重复读(快照)和读已提交
Overview
tidb-architecture-v3.1PD
是一个中心管理节点。管理整个集群的信息。记录表和KV的关系,记录KV的region分布。分配唯一id。
TiDB
是计算引擎,兼容mysql客户端。把收到的sql得到执行计划,把关系型数据转化为KV数据,并发送给TiKV或者TiFlash来执行,并返回数据
TiKV
是一个行KV存储节点,每个TiKV会存储若干region的KV数据,并通过raft来同步数据。使用rocksdb来存储KV对
TiFlash
是一个列KV存储节点,用于在线分析。通过raft同步TiKV的数据,保持强一致性
TiSpark
兼容spark客户端
五大特性
-
一键水平扩容/缩容(通过TiUP)
可按需对计算、存储分别进行在线扩缩容
-
金融级别高可用
通过raft算法同步数据
-
实时HTAP
为HTAP提供列式存储引擎TiFlash。TiFlash通过Raft同步TIKV的数据,确保TiFlash与TiKV的强一致性
-
云原生分布式数据库
-
兼容mysql
计算引擎TiDB兼容mysql客户端,应用程序可以快速从mysql迁移到TIDB
基本API
通过sql操作,计算引擎会自动选择TiKV还是TiFlash来返回数据
生产环境推荐硬件
组件 | CPU | 内存 | 硬盘类型 | 网络 | 实例数量(最低要求) |
---|---|---|---|---|---|
TiDB | 16 核+ | 48 GB+ | SAS | 万兆网卡(2 块最佳) | 2 |
PD | 8 核+ | 16 GB+ | SSD | 万兆网卡(2 块最佳) | 3 |
TiKV | 16 核+ | 64 GB+ | SSD | 万兆网卡(2 块最佳) | 3 |
TiFlash | 48 核+ | 128 GB+ | 1 or more SSDs | 万兆网卡(2 块最佳) | 2 |
TiCDC | 16 核+ | 64 GB+ | SSD | 万兆网卡(2 块最佳) | 2 |
监控 | 8 核+ | 16 GB+ | SAS | 千兆网卡 | 1 |
迁移工具
名称 | 使用场景 | 上游(或输入源文件) | 下游(或输出文件) | 主要优势 | 使用限制 |
---|---|---|---|---|---|
TiDB DM | 用于将数据从与 MySQL 协议兼容的数据库迁移到 TiDB。 | MySQL,MariaDB,Aurora,MySQL | TiDB | 一体化的数据迁移任务管理工具,支持全量迁移和增量同步;支持对表与操作进行过滤;支持分库分表的合并迁移。 | 建议用于 1TB 以内的存量数据迁移。 |
Dumpling | 用于将数据从 MySQL/TiDB 进行全量导出。 | MySQL,TiDB | SQL,CSV | 支持全新的 table-filter,筛选数据更加方便;支持导出到 Amazon S3 云盘 | 如果导出后计划往非 TiDB 的数据库恢复,建议使用 Dumpling;如果是往另一个 TiDB 恢复,建议使用 BR。 |
TiDB Lightning | 用于将数据全量导入到 TiDB。 | Dumpling 输出的文件;CSV 文件;从本地盘或 Amazon S3 云盘读取数据。 | TiDB | 支持迅速导入大量新数据,实现快速初始化 TiDB 集群的指定表;支持断点续传;支持数据过滤。 | 如果使用 Local-backend 进行数据导入,TiDB Lightning 运行后,TiDB 集群将无法正常对外提供服务。如果你不希望 TiDB 集群的对外服务受到影响,可以参考 TiDB Lightning TiDB-backend 中的硬件需求与部署方式进行数据导入。 |
Backup & Restore (BR) | 通过对大数据量的 TiDB 集群进行数据备份和恢复,实现数据迁移。 | TiDB | SST;backup.meta 文件;backup.lock 文件 | 适用于向另一个 TiDB 迁移数据。支持数据冷备份到外部存储,可以用于灾备恢复。 | BR 恢复到 TiCDC / Drainer 的上游集群时,恢复数据无法由 TiCDC / Drainer 同步到下游。BR 只支持在 new_collations_enabled_on_first_bootstrap 开关值相同的集群之间进行操作。 |
TiCDC | 通过拉取 TiKV 变更日志实现的 TiDB 增量数据同步工具,具有将数据还原到与上游任意 TSO 一致状态的能力,支持其他系统订阅数据变更。 | TiDB | TiDB,MySQL,Apache Pulsar,Kafka,Confluent | 提供开放数据协议 (TiCDC Open Protocol)。 | TiCDC 只能同步至少存在一个有效索引的表。暂不支持以下场景:暂不支持单独使用 RawKV 的 TiKV 集群。暂不支持在 TiDB 中创建 SEQUENCE 的 DDL 操作和 SEQUENCE 函数。 |
TiDB Binlog | 用于 TiDB 集群间的增量数据同步,如将其中一个 TiDB 集群作为另一个 TiDB 集群的从集群。 | TiDB | TiDB,MySQL,Kafka,增量备份文件 | 支持实时备份和恢复。备份 TiDB 集群数据,同时可以用于 TiDB 集群故障时恢复。 | 与部分 TiDB 版本不兼容,不能一起使用。 |
sync-diff-inspector | 用于校验 MySQL/TiDB 中两份数据的一致性。 | TiDB,MySQL | TiDB,MySQL | 提供了修复数据的功能,适用于修复少量不一致的数据。 | 对于 MySQL 和 TiDB 之间的数据同步不支持在线校验。不支持 JSON、BIT、BINARY、BLOB 等类型的数据。 |
部署
Labels设计
tidb-three-data-centers-in-two-cities-deployment-03同城多中心
tidb-deploy-3dc两地三中心
tidb-three-data-centers-in-two-cities-deployment-01tidb-three-data-centers-in-two-cities-deployment-02
热点
-
PD会检测Region是否存在热点,把不同的热点region分配到不同的机器上
-
PD调度的最小单位是region。再细粒度的调度可以通过load base split。
Load Base Spit会检测10s内超过阈值的region,并再合适的位置把region拆分,并把region分配到不同的计算机器上。被拆分的region不会被迅速merge。PD会跳过这些region,并通过心跳来监控region的QPS,避免合并两个QPS很高的region
限流
Store limit
原理
存储TiKV
tidb-storage-architecture-
本地存储使用rocksdb,相同TiKV的不同region会存放再相同的rocksdb中
-
使用raft来同步数据
-
region是一块有序的数据块,从start_key到end_key。每块region不超过94M,raft以region为单位同步数据。region的分布通过PD动态调整
-
MVCC支持,通过再key后面加上version来实现
Key1_Version3 -> Value Key1_Version2 -> Value Key1_Version1 -> Value …… Key2_Version4 -> Value Key2_Version3 -> Value Key2_Version2 -> Value Key2_Version1 -> Value …… KeyN_Version2 -> Value KeyN_Version1 -> Value ……
-
分布式ACID事务
- 乐观事务
- 悲观事务
计算TiDB
行转kv
Key: tablePrefix{TableID}_recordPrefixSep{RowID}
Value: [col1, col2, col3, col4]
索引
Key: tablePrefix{tableID}_indexPrefixSep{indexID}_indexedColumnsValue
Value: RowID
Key: tablePrefix{TableID}_indexPrefixSep{IndexID}_indexedColumnsValue_{RowID}
Value: null
元数据
存放再TiKV中
调度PD
任务
- region合理分布,提高集群利用率
- 跨机房部署时,要保证一个机房掉线,不会丢失region的多数副本
- 添加一个TiKV节点,需要合理的迁移其他节点的region到新增节点
- 当一个节点掉线时,需要考虑快速容灾
- 掉线后,region副本数量不够,需要选择合适机器补充副本
- 节点恢复后,region副本数量过多,需要合理删除多余副本
- 热点region负载均衡
- 负载均衡时需要考虑数据迁移是否会占用大量网络资源、磁盘IO、CPU。需要限速进行
实现
PD通过心跳收集每个TiKV节点的信息,做调度策略
性能
Threads | 主键查询 TPS | 95% latency (ms) | 更新非索引字段 TPS | 95% latency (ms) | 更新索引字段 TPS | 95% latency (ms) | 读写 tps | 95% latency (ms) |
---|---|---|---|---|---|---|---|---|
300 | 265353.15 | 1.89 | 42991.9 | 11.45 | 19198.89 | 23.95 | 4914.11 | 82.96 |
600 | 358976.94 | 2.57 | 54099.58 | 20.37 | 22877.58 | 41.85 | 5848.09 | 150.29 |
900 | 407625.11 | 3.68 | 62084.65 | 26.68 | 26431.12 | 53.85 | 6223.95 | 223.34 |
优化手段
- 热点识别,拆分region
- sql编译计划缓存
- sql执行计划缓存
- 热点小表缓存
- 建索引
- sql优化
网友评论