免费网站从哪里申请,十大搜索引擎,佛山关键词优化服务,电力网站建设一 DML语句读写流程
1 DML语句读流程概要 用户发出SQL
被协议层接收 Protocal Layer
通过PD获取时间戳
parse模块 解析SQL#xff0c;通过词法解析 与 语法解析 生成AST语法树
编译SQL Compile模块 ,区分点查 与 非点查#xff0c;生成执行计划 发送给Executor,从TIKV获…一 DML语句读写流程
1 DML语句读流程概要 用户发出SQL
被协议层接收 Protocal Layer
通过PD获取时间戳
parse模块 解析SQL通过词法解析 与 语法解析 生成AST语法树
编译SQL Compile模块 ,区分点查 与 非点查生成执行计划 发送给Executor,从TIKV获取数据 返回给用户 2 DML语句读流程概要 写流程和读流程前面差不多 需要先把数据读出来 二 DDL语句的执行流程 在集群中有多个tidb server .可能有多个DDL 发送到TiDB server上。但是同一时刻只能有一个TiDB server的workers在做DDL
用户发出DDL语句 由模块 start job 模块接收然后放到job queue队列中。
在同一时刻 只有一个Tidb Server的角色为owner ,owner角色的 Tidb Server的worker才能中从 job queue队列中取DDL执行完成之后放到history queue中。
owner 角色有任期并不是固定在一个Tidb Server上。
当成为owner后 schema load 会收集所有表的元数据。
队列放到TiKV上主要是为了持久化存储一旦发生宕机断电可以防止数据丢失。 SQL解析 Parse 与 编译 Compile 用户发出SQL 由协议层接收 PD Client 请求PD 获取TSO 这条SQL语句起始时间Parse模块对SQL进行语法解析 词法解析yacc, 转化为AST 语法树语法树被传递到 Compile模块,细分有三步 1 Proprocess预处理阶段 检测SQL合法性 名称是否正确绑定的信息等另外还会 判断是否为点查 比如通过唯一索引 主键索引的等值查询这样就不用在走后面的流程直接执行。如果不是点查 则还需要走后面的优化流程分为逻辑优化 主要是根据关系代数等价交换的一些规则对SQL语句进行逻辑的变换比如外连接转换为内连接逻辑优化之后就是 物理优化 主要是基于逻辑优化的结果 结合表的统计信息表的行数列的选择度 直方图等等选择最优的算子从Compile模块出来的就是物理执行计划 就可以去TiKV中取数。
读取的执行 有了执行计划之后 读取的流程 主要设计的模块 在TIDB server中
Executor 执行器
KV 专门负责点查的
DistSQL 执行复杂SQL的
PD Clent 负责与PD沟通
TiKV Client 通过这个出入口与TiKV 交互
Executor 需要做两件事 1 获取元数据在TIDB 启动的时候 information schema是存储了元数据的已经被载入到Tidb Server的缓存中了所以直接读缓存就可以了。2 另外还有KEY所在的Region Region所在的TiKV等这些信息存储在PD中所以还需要访问PD但是TiDB Server 与 PD 是通过网络交互的 频繁的交互有很大的网络压力如何解决 把读取过的信息缓存在TIKV Client的 Region Cache中下一次再读取相同的Region的时候就去 Region Cache中读取即可。如果存储Region的TIKV发生了变化region 分裂 合并 过期等 根据TIKV Client的 Region Cache的信息就获取不到数据然后就需要返回这种现象叫做back Off出现back Off响应就会延迟 就会再去PD中读取一次。因为PD中的数据是最新的。
下面就可以去TIKV中读数据了。 DIstSQL 是一个 抽象层 把复杂的SQL语句转换为对单表的简单查询之后在去下发给TIKV 这样就相当于吧复杂SQL与TIKV 进行了解耦合。
TIKV接收到SQL请求之后 首先会构造一个快照snapshot,一个特定时间点的数据比如我十点发出SQL这样查询的数据永远是十点的。从TIDB 5.0之后无论是点查还是复杂查询 查都会进入到 UnifyRead Pool 线程池 按照优先级执行这些查询的 然后到rocksdb kv中查询rocksdb kv的查询也是分层的 由上而下 blockCache --MEMTable-- Immutable --MEMTable 可以参考 【TiDB理论知识 03】TiKV-持久化与数据读取_DBA之路的博客-CSDN博客
这样数据就取出来了。
单表的SQL不一定在一个TIKV上这个时候可以并行查询 。TIKV 还具有算子下推功能会帮助TiDB 做数据的过滤和聚合 这种叫做 cop task 。还有一部分 TIKV 没有办法 比如做T1 T2 T3表的三表连接 数据可能散落在各个TIKV上 只能把数据先放到 TIDB的内存中 然后再做表连接 叫做 root task
写入的执行
需要把修改的数据读入到 membuffer中 读入的操作和 之前讲的流程是一样的。咱们从数据已经读入到membuffer中开始
TIDB Server 中 与事务写入的模块主要有三个
Transction
KV
TiKV Client
流程
Transction 进入两阶段提交
TIKV
写请求发送给 Scheduler 负责协调并发写入的冲突并将收到的修改操作向下写入当又并发写入同一个key的时候用latch 管理冲突 谁拿到latch就可以写入
RaftStore 这个模块主要是将写请求转换为Raft log 之后 像两个地方分发 持久化到本地另外向其他副本发送
Apply 线程组 顺序读取这些Raft log 应用到 Rocksdb KV中。
RocksDB 是如何写入 参考 DDL的执行 TIDB 支持 online DDLDDL执行过程中不会阻塞DML的
确定自己是不是owner ,把DDL 放到 TIkV的 job queue队列中 角色为owner的TIDB Server会定期查看job queue 执行完毕后会放到history queue队列中
Owner 角色 是轮循的
add index queue 是个比较特殊的队列 唯独加索引是放到 add index queue 队列中 。加列修改列的属性都是放到 job queue中
schema load 负责把表的最新的表结构载入到TIDB server 。
