本文是《极客时间》-《TiDb极简入门》的学习笔记。传送门：https://time.geekbang.org/opencourse/videointro/100089601

这部分讲解了Tidb的整体概述。

一 我们需要一个什么样的数据库？

数据库设计要考虑什么

1.扩展性 scale-out

颗粒度越小越好，常见的颗粒度：集群/db/表/分表/分区表

写入能力的线性扩展

2.强一致，高可用

强一致： CAP里的一致性（副本一致性）

由于副本节点数和网络延迟成正比，节点数量越多，网络延迟越大。 普遍采用多数派强一致，常见的3副本强制写2节点

数据容灾：RPO（数据恢复点目标）所能容忍的数据容量量

rto(恢复时间目标)所能容忍业务停止服务的最长时间

强一致，高可用目标是实现RPO=0，RTO足够小（目前普遍是若干秒级）

3.实现标准SQL与事务的支持

因为SQL是高度易用性，已经是数据交互类语言的实施标准，所以兼容sql非常重要

同时在很多场景下，尤其是oltp，完整事务是必选项

4.云原生

5混合数据服务HTAP

在海量数据下OLTP OLAP的数据服务融合

行列混合

更彻底的资源隔离

6.兼容主流生态协议

数据技术栈领域里常见的基础因素

1. 数据模型： 关系模型/ 文档模型/KV模型

2. 数据存储与检索结构：B-Tree/LSM-Tree/分形树

3. 数据格式：结构化数据/非结构化数据/半结构化数据

4. 存储引擎：负责数据的存储和持久化：Inno DB Rocks DB

5. 复制协议：保证数据的可用性，Raft/Paxos

6. 分布式事务模型：事务处理时的并发处理方法,以保证事务的可串行化 XA/Percolato

7. 数据架构：多个计算引擎共享同一份数据/多份数据，常见的有 Share-Disk/Share-Nothing/Share-Everything等

8. 优化器算法：根据数据分布/统计信息生成成本最低的执行计划

9. 执行引擎：火山引擎/向量化/大规模并行计算等

10.计算引擎：是否是一个标准SQL的引擎

计算与存储分离的必然性

1. 计算与存储绑定，意味着总有一个资源是浪费的

2. 服务器选型困难

3. 在云计算场景下，弹性的颗粒度是机器，不能做到真正资源的弹性

TiDB高度分层架构

弹性是整个架构设计的核心考量点，计算与存储分离

从逻辑上TiDb主要分为3层

1.TiDB-Server: 支持标准SQL的计算引擎（以Mysql5.7为主，在逐步兼容Mysql8.0）, 本身并不存储数据,只进行计算

2.TiKv: 分布式存储引擎

3.Placement Driver(PD): 负责元信息与调度引擎，整个集群的大脑，为了保证高可用性，至少有3个节点，通过raft复制。

PD有以下几个功能：

集群的元信息管理：分片的分布，拓扑结构

分布式事务ID的分配

调度中心

二 如何构建一个分布式存储系统

我们需要一个什么样的存储引擎

1.更细粒度的弹性扩缩容

2.高并发读写

3.数据不丢不错

4.多副本保障一致性及高可用性

5.支持完整的分布式事务

TiDb 的选择

数据结构

选择了KV的数据索引， 简单随处可见，而且是其他更复杂索引基础构建的模块

存储引擎

选择了基于LSM-Tree的RocksDB引擎

支持批量写入

无锁快照读

为什么不用B-Tree:

在传统的OLTP系统中，写入是最昂贵的成本

B-Tree至少要写两次，一次预写（WAL）,一次写入树本身，

B-Tree是严格平衡的数据结构，他的设计是对读友好，数据写入触发的B-Tree分裂与平衡成本是非常高的,因此B-Tree相对于写入并不友好

在传统的主从架构里，不管加多少个节点，集群的写入容量完全由主哭的机器配置决定，扩容只能通过分库（集群拆分）来进行

因此选择了LSM-Tree，本质是用空间置换写入延迟，用顺序写入替代随机写入到数据结构

采用顺序写，写到了一定阈值以后，持久化成一个静态文件，随着静态文件越来越大，会被推到下一层进行合并

数据副本

数据冗余决定了系统可用性

强一致数据算法：raft

对比Paxos, Raft的目标是提供更清晰的逻辑分工，使得算法本身能被更好地理解，同时他的安全性更高，能提供一些额外的特性。（from wiki）

如何实现扩展

做分片，预先分片还是自动分片？

传统的分库分表属于预先分片，只解决了表容量问题，没有解决弹性问题

分片算法：哈希，范围，列举

Tikv采取了范围，原因

1. 在“where 字段> value”的场景下，在这个场景下，range分片可以更高效的扫描数据

2. 可以简单实现自动完成分裂和合并

3. 弹性有限，分片需要可以自由调度，range对于自由调度更友好

range分片的问题

1.需要考虑热点问题？

region概念

把Tikv看成是一个巨大的有序的kv map,通过范围的方式，将整个kv空间分成若干段，每一段也是一些列连续的kv,把每一段成为region, 并且尽量保证每个region中保存的数据不超过一定的大小

如何进行分离与扩展

当region超过一定大小，会自动分成两个region, 当由于大量删除请求导致region变小，会自动和相邻的region合并

灵活调度机制

PD来负责将region尽可能的，均匀的，离散的，分布在集群的所有节点上。

1.实现了存储容量的水平扩展，通过增加新的节点会自动将其他节点上的region分片调度过来

2.实现了负载均衡

TiKv整体架构

参考率goole spanner设计的multi raft-group副本机制

多版本控制MVCC

通过在key后面增加版本号实现

分布式事务模型

参考了google的percolator事务模型

去中心化两阶段提交

每个节点单独分配区域存放锁信息（Tikv的锁是基于列簇，CF lock）

通过PD全局授时（TSO）

TIDB默认隔离级别是SI（快照隔离），也支持RC(read commit)

默认乐观锁，在3.0以后也支持悲观锁，可以自由选择，在5.0以后，实现了两阶段异步提交

协作处理器Coprocessor

tikv中读取数据的计算模块

在数据层尽快的进行计算和预处理，例如在本地节点尽快完成filter,group by等

三 如何构建一个分布式sql引擎

如何在kv上实现逻辑表

每个表有一个tableid, 每个索引indexid, 每行有rowid

简单来看，key = rowid+indexid

value=所有列按等位偏移的方式进行connect进行连接

在数据查询的时候，我们通过等位偏移对value进行反解析，然后对应schema的元信息进行列信息映射

二级索引：也是一个全局有序的kvmap

简单来说：key= 索引列信息

value= primary-key

然后通过pk在原表查数据，类似于b-tree的回表

sql引擎过程

SQL: sql语法解析/语义解析

抽象语法树：从文本解析成结构化数据

逻辑优化：将各种sql等价改写以及优化

物理优化：基于统计信息与成本进行生产执行计划(重要)

执行引擎：根据优化器定下的执行路径进行数据寻址，数据计算

基于成本优化器

cost model里需要进行合理的匹配计算

分布式sql引擎主要优化策略

最大程度让数据在分布式存储层尽快的完成过滤以及预计算（最大下推策略 push down）

关键算子分布式化

如何构建一个Online DDL

1.tidb没有分表概念，所以整个ddl完成过程是很快的，秒回

2.ddl过程分成public/delete-only/write-only等几个状态，每个状态在多节点之间同步和一致，完成最终的ddl（根据goggle的f1论文）

如何连接到tidb-server

可以使用mysql客户端或者sdk直接连接

从进程的角度看tidb-server

就是一个后台进程，不断监听port，和client通信，按照mysql协议解析收到的网络请求，获取时间戳，通过分片的路由信息找到对应的存储节点去查询数据

从内部角度看tidb-server

mysql协议层

sql核心层：sql的parse分析，逻辑优化，物理优化，统计信息收集，执行层等

其他功能

前台功能

1.管理连接和账号权限管理

2.mysql协议编码解码

3.独立sql执行

4.库表元信息，系统变量管理

后台功能

1.GCC

2.执行DDL

3.统计信息收集

4.sql优化器与执行器