TiDB基础

一些基本概念

OLTP/OLAP

1. OLTP：On-Line Transaction Processing, 在线事务处理，主要表示对数据的增删改
   • 记录某类业务的发生。如购买行为，当有订单产生后，系统需要记录何人何时何地做了什么事，要求实时性高、稳定性强、数据更新成功
   • 提供写操作的业务，一般都可以成为OLTP业务
2. OLAP: On-Line Analytical Processing, 在线分析处理，主要表示对数据的查询
   • 当数据积累到一定程度后，需要进行数据汇总、分析、总结时，为公司决策提供数据支持，此类成为OLAP业务
   • 一般数据仓库系统是做OLAP业务

谷歌的三驾马车

1. GFS: Google File System, 分布式文件系统
2. Google MapReduce: 是一种编程模型，用于大规模数据集（大于1TB）的并行运算
3. Google BigTable: 分布式数据存储系统。海量的结构化数据开发的云存储技术

CAP理论

1. C: Consistency, 一致性。
   • Every read receives the most recent write or an error
   • 系统每次请求，都可以得到最新写入的数据，或者报错
   • 强调数据准确性，要么是最新数据，要么报错；针对每次请求的结果
2. A: Availability, 可用性。
   • Every request receives a (non-error) response – without the guarantee that it contains the most recent write
   • 系统每次请求都会得到一个响应，但是不保证返回结果是最新写入的
   • 强调可用性，不保证最新，但不会报错；针对每次请求的结果
3. P: Partition Tolerance, 分区容错性。
   • The system continues to operate despite an arbitrary number of messages being dropped (or delayed) by the network between nodes
   • 系统仍然可以继续提供服务，尽管部分消息可能丢失或者延迟了
   • 强调系统不会因为内部通信异常而挂掉；强调系统不挂

CAP理论是指： 在分布式系统中，CAP三个特性最多能同时满足其中两个特性

计算和存储分离

以前，受限于网络带宽，存储和计算都在一个节点，导致一些问题：

1. 计算与存储强绑定，意味着两种资源总有一种是浪费的
2. 对服务器选型中，需要考虑计算型还是存储型，大大增加技术复杂度
3. 云计算场景下，弹性的粒度是机器，不能做到资源的弹性

后来，网络带宽极大发展，促进了计算与存储分离的架构 （这部分不太理解。。。）

TiDB基础

TiDB设计六大目标

1. 扩展性
   • 横向扩展能力，弹性粒度更小
   • 面向写入的横向扩展
2. 强一致和高可用
   • 指CAP中的C，即副本一致性；更多只多数派的强一致，比如三个副本强制写两个节点（写的副本数越多，写延迟越大）
   • RPO: 数据恢复点目标。指系统所能容忍的数据丢失量
   • RTO: 恢复时间目标。指系统所能容忍的故障恢复时间
   • 强一致和高可用即实现：RPO = 0， RTO尽可能小
3. 标准SQL，支持ACID事务
   • OLTP场景，对于写入事务仍然是强需求
4. 云原生
   • 在计算与存储分离的背景下，云原生支持资源的弹性扩展
5. HTAP
   • 混合数据服务；支持海量数据下的OLTP和OLAP服务融合
6. 兼容主流生态和协议
   • 降低用户的接入门槛
   • 数据技术栈和架构的本质：在相对固定的基础数据技术元素上，进行各种选择、平衡和优化
     • 基础数据技术元素包括，数据模型、存储引擎、索引、数据格式等

TiDB分层结构

TiDB使用计算与存储分离的架构。主要分为三层：

1. TiDB Server: 进行语义解析和计算
2. TiKV: 数据存储
3. PD: Placement Driver, 负责元信息管理和调度引擎

TiKV底层原理

数据结构

1. 底层存储使用LSM-tree结构
   • 本质是一个用空间置换写入延迟，用顺序写替换随机写的数据结构
2. TiKV单节点选择基于LSM-tree的RockDB引擎作数据存储
   • RockDB引擎是一个成熟的LSM-tree存储引擎
   • 支持批量写入
   • 支持无锁快照读

高可用设计

1. 支持多副本机制
   • 多副本是系统可用性的保证
2. 基于raft算法，实现以RockDB引擎为基础的多副本，高可用集群

如何实现扩展

1. 使用range分片
   • 高效扫描数据行数
   • 简单实现自动化合并和分裂
   • 自动调用更友好
2. TiKV可以看成一个巨大的Key-Value Map，根据Key的大小划分成若干个Range
3. 根据range大小自动扩展和合并
   • 默认range大小为96M
   • 默认range分裂的大小为144M
4. TiKV以range为单位存储，每个range的多副本分布在不同的TiKV节点上，PD支持查询key所在的range，以及所在的节点

TiKV的MVCC和事务支持

1. TiKV的多版本控制，通过在key后面添加版本号控制
   • 所有版本都是一个新的key，且在整个key-value map中存储
2. TiKV使用去中心化的两阶段提交支持事务
   • 每个TiKV节点上分配一个CF Lock存储当前节点上的锁信息
   • PD支持所有TiKV节点的顺序一致性
   • 每个TiKV部署一个Coprocessor，利用TiKV多节点的并行计算能力，将计算下推

TiKV的存储和查找

1. TiKV给每个表分配一个TableID，每个索引分配一个IndexID，每行数据分配一个RowID（默认主键）

主键索引

1. TiKV-Key = RowID + IndexID
2. TIKV-Value = 所有的列（按照等位偏移的方式存储）

二级索引

1. TiKV-Key = 索引的列信息
2. TiKV-Value = 原表的主键（Primary Key）

名言：对于使用者来说：统一与易用性是最朴素的需求