丹东网站设计/网站检测

丹东网站设计,网站检测,南京有哪些做网站的公司,做外贸建网站目录 1. DML语句读流程概要 2. DML语句写流程概要 3. DDL 流程概要 4. SQL的Parse和Compile 5. 读取的执行 6. 写入的执行 7. DDL的执行 8. 小结 1. DML语句读流程概要 TiDB Server接收sql并处理，TiKV负责持久化数据，PD提供TSO和Region的数据字典…

1. DML语句读流程概要

2. DML语句写流程概要

3. DDL 流程概要

4. SQL的Parse和Compile

5. 读取的执行

6. 写入的执行

7. DDL的执行

8. 小结

1. DML语句读流程概要

TiDB Server接收sql并处理，TiKV负责持久化数据，PD提供TSO和Region的数据字典信息

Protocol Layer：接收sql
PD Client到PD节点获取STO
Parse：词法解析、语法解析，将sql解析为AST语法树
Compile：区分点查和非点查，生成执行计划
Execute：拿着执行计划问PD在哪个TiKV Region读取想要的数据
读取数据后交由Execute，返回给用户

2. DML语句写流程概要

Protocol Layer：接收sql
PD Client到PD节点获取STO
Parse：词法解析、语法解析，将sql解析为AST语法树
Compile：区分点查和非点查，生成执行计划
Execute：拿着执行计划问PD在哪个TiKV Region读取想要的数据
读出来的数据放在memBuffer中进行修改，当用户发起commit的时候，进入两阶段提交
- 第一阶段：prewrite，将内存中修改的信息和锁信息写入TiKV
- 第二阶段：commit，写提交信息，将锁清理掉，获取结束TSO
二阶段提交完成后，返回给用户提交成功数据不会丢了

3. DDL 流程概要

修改表定义、加索引等等都是DDL

用户发出DDL语句
TIDB Server中的start job接收DDL语句
将DDL放入TiKV中的job queue中(添加索引是放在 add index queue中)
TIDB Server谁是owner角色谁就执行DDL，owner中的worker去job queue(先进先出)中取DDL去执行
执行完后把该job放入history queue中

4. SQL的Parse和Compile

Protocol Layer：接收sql
PD Client：去PD异步获取TSO
Parse：词法分析LEX，语法分析YACC，将sql转化成AST语法树
compile：
- preprocess：检测sql合法性，名称是否正确，一些绑定信息等，判断是否是点查
- 如果是点查(PointGet)的话直接就执行，节约了优化的工作
- 如果是非点查的话，进入优化流程：
  - ①逻辑优化：关系代数、等价交换等一些规则将sql语句进行一些逻辑的变换，比如把外连接转化为内连接等等
  - ②物理优化：基于逻辑优化的结果结合相关的统计信息(行数、列的选择度、直方图等等)选择最优的算子，如何去TiKV中好的效率最高的取得数据
编译完成后生成物理执行计划，拿着物理执行计划去TiKV中取数据

5. 读取的执行

当Executor收到执行计划后，Executor做两件事：

①从information schema（缓存中，是最新的）中获得元数据（表名、列名等）
②要修改的数据对应Key在所在的Region以及Region所在的TiKV，第一次会从PD中获取Region的位置，然后缓存在TiKV Client中的region Cache中，如果region Cache的信息过期了(back off)，访问的时候会再次从PD中读取最新的信息到region Cache中

经过了以上过程，获得了表的元数据以及Key所在的Region和TiKV

Executor读取数据：

如果是点查，KV模块就通过TiKV Client直接读取数据
如果是非点查（复杂sql语句）DistSQl模块会将复杂的sql转换成多条对单表的查询语句，然后通过TiKV Client去TiKV取数据

TiKV接收到请求后首先会构建一个快照snapshot

点查和非点查都会进入UnifyRead Pool线程池，按照优先级执行查询，到RocksDB kv去读取数据

一部分过滤和聚合在TiKV中做，叫coptask，还有一部分在TiDB中(比如三张表连接，三张表散落在3个TiKV中，先把数据读到TiDB内存中再做表连接)叫root task

6. 写入的执行

前面的读取流程是一样的，从读出数据开始，把需要修改的数据读到memBuffer中，用户commit后进入两阶段提交

第一阶段：prewrite，Transaction从memBuffer中一行一行读取数据修改数据，通过KV和TiKV Client写到TiKV中并加锁

写请求发送给Scheduler模块(协调事务并发写入的冲突，并将收到的修改操作向下写入)，同时写入同一个Key的时候，谁持有Latch谁就可以写数据，其他的需等待Latch
然后到RaftStore，将写请求转换为raft log，此时会在本地RocksDB raft持久化raft log，并把raft log发送给其他节点，然后Apply模块把读取rocksdb raft log应用到rocksdb kv中持久化存储，然后反馈写入成功。

第二阶段：commit，获取结束TSO，写提交信息，清理锁

7. DDL的执行

Protocol Layer接收DDL，经过Parse和Compile，到达start job
start job会检查自己所在的TiDB Server是不是owner
如果是owner则直接给workers执行，如果不是就会把DDL做成一个job放到TiKV的job queue中持久化（添加索引放在add index queue中）
Schema load：将最新的表的元信息载入到TiDB Server
owner中的worker会定期去查看job queue，当job queue中有job的时候workers就根据元信息执行DDL（Job queue 和 add index queue 中的语句可以并行执行）
执行完毕后把job放在history queue中

owner节点是轮询的，由PD节点控制