TiDB 发展简史
由 Google Spanner 而来的灵感。
1.0.0 GA Version
从 1.0.0 GA 版本：
- 支持计算和存储两个方面的自由扩容
- 与 MySQL 语法兼容
- 对应用透明的数据分片策略
- 应用无感知，强一致分布式事务
框架结构：
- TiDB : 无状态的 SQL 引擎，承担计算业务，可以多实例
- TiKV : 分布式 KV 存储引擎，raft
- PD Cluster : 负责元数据存储和 TiKV 中数据调度
数据仓库能力：
- 兼容 MySQL 协议，易于同步 MySQL 的生产库
- 不需要分配，对应用透明
- 数据汇总实时完成
- 大容量存储，允许多个数据源融合
- 数据仓库和数据分析 2-in-1
TiSpark
但是用了一段时间的: 发现 AP 场景的问题挺多：
- 复杂查询场景太慢
- 容易 OOM
- 无法和大数据平台进行整合
如何解决这个问题： 方案一：将 TiDB 和 TiKV 结合。重构执行器做成 MPP。 但是这样做风险高，耗时长。 方案二：学习成熟的分布式框架。 风险小，耗时短。 所以，TiSpark 诞生了。
TiSpark 为解决用户复杂 OLAP 需求。提供了分布式的计算框架，快，稳定，无缝接入大数据生态。
Spark 的缺点：
- 并发度低
- 消耗大量的计算资源
TiSpark 就资源消耗少，而且好维护。
TiFlash
但是，还是有两个核心问题没有解决：
- 行存储不适合做数据分析
- 没有资源隔离
所以需要加入列存功能，所以出现了 TiFlash，它是 TiKV 的列存扩展，在提供了良好的隔离性的同时，也兼顾了强一致性。列存副本通过 Raft Learner 协议异步复制，但是在读取的时候通过 Raft 校对索引配合 MVCC 的方式获得 Snapshot Isolation 的一致性隔离级别。这个架构很好地解决了 HTAP 场景的隔离性以及列存同步的问题。
TiDB 平台框架和全景图
TiKV TiFlash 是存储层。 TiDB TiSpark 是计算层，分别处理 MySQL,Spark SQL。 PD Cluster 是元数据存储，分配 PSO，数据定位。
TiDB(SQL Layer)
无状态 SQL 层：客户端可以连接任何 tidb 实例 全功能 SQL 层：支持 MySQL，二级索引，在线 DDL。
TiKV/TiFlash(Storage Layer)
TiKV：行存储，适合事务处理。 TiFlash：列存储，适合分析处理。
优化器选择，事务类处理 TiKV 完成，分析类 TiFlash 完成。
PD(Placement Driver)
三副本（节点），etcd 同步数据。
任务：
- 存储集群的元数据。region的位置，处于那些 TiKV 上，raft leader 是那个。
- 调度和负载均衡 region。比如将 region 迁移到另外几个 TiKV 上，将 Raft leader 迁移给其他一个 follower。
- 负责分配全局单调递增的事务时间戳。
TiSpark(SQL Layer)
为解决用户复杂 OLAP 需求。提供了分布式的计算框架，快，稳定，无缝接入大数据生态。
TiUP
包管理工具。 单机部署。 集群部署。 组件分发。
Lighting
TiDB Lightning 是一个将全量数据高速导入到 TiDB 集群的工具，目前支持 SQL 或 CSV 输出格式的数据源。
Fast Backup & Restore(BR)
TiDB 分布式备份恢复的命令行工具，用于对 TiDB 集群进行数据备份和恢复。相比 dumpling 和 mydumper，BR 更适合大数据量的场景。
TiCDC
TiCDC 是一款通过拉取 TiKV 变更日志实现的 TiDB 增量数据同步工具，具有将数据还原到与上游任意 TSO 一致状态的能力，同时提供开放数据协议 (TiCDC Open Protocol)，支持其他系统订阅数据变更。
TiDB 技术特性
基础架构：TiDB TiKV PD 扩展架构：加 TiSpark TiFlash
扩展性：
- 在线扩容
- 在线缩容
- 数据自动平衡
高可用性：
- shared nothing，无限扩展
- raft
- 故障自我恢复
- 两地三中心，多活
分布式事务：
- ACID
- 不需要在业务程序中指定分片（分库分表）
- 一条 SQL 可以将在多个数据中心的数据获取到
实时 HTAP：
- raft 实现数据备份
- 一个数据库中支持行存储和列存储
- standard SQL for TP & AP
- 实时，没有 N + 1
TiDB 4.0
TiUP
Big transaction
Tmp Storage
Dashboard
Elastic Scheduling
问题1： Do we need to specify the sharding key in TiDB? 不需要
问题2：What’s the limit for transaction sizes in TiDB 4.0? 10 GiB limit(more memory needed) 6 MB per kv pair 一个事务转化成的 kv 数量将没有限制
