TiDB 数据库笔记（PCAP认证 TiDB 数据库专员 V6 考试复习笔记）-摩杜云开发者社区

TiDB 数据库核心原理与架构笔记

1.功能介绍

TiDB Server集群（无状态，不存储数据）
- 处理客户端发送的sql语句，进行解析编译优化，生成执行计划
- 如果是insert要将表的数据转换为key和value的形式，向TiKV存储
- 执行online DDL
- 每隔十分钟左右进行垃圾回收（GC）将历史版本数据删除
- 可水平扩展，增强并发处理能力
TiKV
- 存储数据（数据持久化），存储引擎集群，默认创建三副本（只有一个leader可以读写，其他都不可以读写，其他的跟着leader变），高可用性
- 存region（行存）
  - rocksdb单机的Key-Value存储引擎（内部使用这个数据库保障TiKV的数据持久化）
  - rockdbkv(rocksdb实例):将表数据转换为key-value的形式存储在rockdb实例中
  - rockdbraft(rocksdb实例)：存储表的增删改等指令
  - Raft协议（保障了三副本的强一致性）
  - MVCC（保障了其他操作可以正常执行，例：读的是修改前的数据）
  - Transaction事务层（支持事务）
  - 算子下推实际上是一个分布式计算的模型
TiFlash
- 存储数据，存储引擎集群
- 存region（列存，擅长统计分析数据）
- TiKV行存更多承载在线交易型业务OLTP(事务型)
- TiFlash更多承载分析型业务OLAP(暴力扫描)
- HTAP(OLTP,OLAP)支持
region : 96M->144M
- 数据库表切分,分布存储在TiKV
PD:PlacementDriver
- 集群的大脑
- 存储想要的表在TiKV,TiFlash的对应位置（这些信息叫做：region 的元数据：表在哪些TiKV,TiFlash上分布信息）region与TiKV,TiFlash的对应关系
- 存储查询每条sql执行的开始时间，结束时间（TSO对时间进行标识，计时器：对一个事务有开始的TSO有结束的TSO）
体系特点：
- 水平扩容或缩容
- 金融级高可用
- 实时HTAP
- 云原生的分布式数据库
- 兼容MySQL5.7协议

题目：

2.TiDBServer详情

TiDB server 架构
- 功能：
  - 处理客户端的连接（Protocol Layer）
  - SQL 语句的解析和编译（Parse，Compile）生成执行计划交由Excutor进行执行
    - AST语法树
  - 关系型数据与 KV 的转化
    - 聚簇表：标号+原表主键做主键（主键唯一）
      - region(默认大小96M->144M，超出分裂，分布式存储在TiKV中)
    - 非聚簇表（自动生成主键）
  - SQL 语句的执行
    - DistSQL将复杂sql的执行计划转换为单表计算任务组合发送给TiKV,涉及一张表涉及多个region
    - 简单查询，点查走KV就不走DistSQL
    - Transaction将开始时间和结束时间(TSO)发送给PDClient
  - 在线 DDL 的执行
    - 对于整个tidb数据库来说，同一时刻只能有一个TiDBServer做DDL操作（worker）
    - owner执行job,不是固定的，有任期时长，轮换当owner，谁当owner谁复制执行job队列的DDLJob
    - schema load将最新的所有的表信息同步到内部的缓存中，好根据这些信息执行jobqueue里面的job
    - TIKV持久化存储
  - 垃圾回收（定期清理过期版本的数据）
    - GCLifeTime(默认十分钟)保存当前时间到savepoint时间的数据，其他的进行清除
  - 热点小表缓存 V6.0 （cacheTable）进一步热点缓存区
    - 解决数据可能不一致的问题（缓存租约，既存在使用时间，租约时间内，可以读，无法进行写操作）
    - 应用：
      - TiDB 对于每张缓存表的大小限制为 64 MB
      - 适用于查询频繁、数据量不大、极少修改的场景
      - 在租约（tidb_table_cache_lease）时间内,写操作会被阻塞
      - 当租约到期（tidb_table_cache_lease）时,读性能会下降
      - 不支持对缓存表直接做 DDL 操作,需要先关闭
      - 对于表加载较慢或者极少修改的表,可以适当延长 tidb_table_cache_lease 保持读性能稳定
  - TiDB缓存
    - 默认使用TIDB数据库的所有内存
    - 使用场景
    - tidb_mem_quota_query限制每条sql占用的缓存
    - oom-action决定超出了上面缓存以后的操作
题目：

3.TiKV

概述
TiKV 架构和作用
- RocksDB （单机kvmap）针对 Flash 存储进行优化,延迟极小,使用 LSM 存储引擎。
  - 高性能的 Key-Value 数据库
  - 完善的持久化机制,同时保证性能和安全性
  - 良好的支持范围查询
  - 为需要存储 TB 级别数据到本地 FLASH(固态盘) 或者 RAM 的应用服务器设计
  - 针对存储在高速设备的中小键值进行优化 —可以存储在 FLASH 或者直接存储在内存
  - 性能随 CPU 数量线性提升,对多核系统友好
TiKV 数据持久化和读取
- - RSMTree：客户提供(tom,xxx,xxx,xxx,信息)
  - 顺序写
  - SST（键值对存储，key排好序的，找文件时采用二分查找）
  - MenTable，当写的数据大于write_bufffer_size时（写满了后），将数据转存在immutable MenTable中，读时数据永远是最新的
  - immutable MenTable（不可修改），刷到磁盘中，防止写阻塞。(设置write stall=5):当immutable MenTable大于5个时，写会限速（流控）
  - WAL（日志文件）(预写，防丢失)保障事务的原子性和持久性，设置sync_log=true直接压入磁盘，不经过操作系统的缓存，最后会被SST覆盖
  - - compaction：当level层数据达到4个时向下压缩到第下一层（压缩,key排好序形成一个SST文件）
    - 只需要一次磁盘IO,一次内存IO,比B+树效率高
    - 读写只需要操作MenTable即可
    - 对写友好，对查询没有那么友好（比B+树查询慢）
- - 每个文件都有一个bloom filter（帮助判断集合中的元素在不在这个文件中，不在肯定不在，在不一定在）
- 列簇（CF）（rocksdb的数据分片技术）按照不同的属性分配不同的Column Familiy（存的是一类属性）
  - 写入形式：write（cf1,id,name,age）write(cf2,id,addr,tel)，如果没有指定分配列簇会自动加入default列簇
  - Column Familiy共享WAL（日志文件不分）
TiKV 如何提供 MVCC 和分布式事务支持
- 事务存储进TiKV
  - 存在时间戳TSO
  - 提交时修改信息和锁信息被写入TiKV中，才被别人感知（乐观锁），默认乐观锁
  - 直接写入TiKV中，被别人感知（悲观锁）
  - 一个TiKV节点中对应三个列簇（cf）（
    - 修改的数据Default:数据会加时间戳，比如:（3_100）
    - 锁信息Lock:只有一把主锁
    - 提交信息Write（包括时间戳）
  - write 列:当用户写入了一行数据时,如果该行数据长度小于 255 字节,那么会被存储 write 列中,否则的话该行数据会被存入到 default 列中。
  - default 列:用于存储超过 255 字节长度的数据。
  - - w（写锁）可以读不能写
    - pk(主锁)：只在分布式事务的第一行加锁
    - @1我的主锁在1这，其他行我加是一个主锁指向，随着主锁走的
    - 锁释放：加一行去掉锁的语句（将W改为D），不会删除
- 分布式事务解决了原子性问题
- MVCC（多版本并发控制）
  - 增删改是以新值进行添加
  - 可以读取所有历史版本值，包括未提交的值（悲观锁）
  - 不阻塞读，阻塞写操作
TiKV 基于 Raft 算法的分布式一致性
- - region超出了分裂，太小合并
  - raft group有三个region
  - multi raft是多个raft group组成
  - candidate （候选者）是由于leader长时间没有统治信息，由follower投票选出来的
  - Raft 算法实现了分布式数据的强一致性
  - 写数据只写leader，leader将指令变成日志的形式，向所有的follower复制，当大多数节点都收到日志，并持久化后，follower会返回append成功的信息给leader后，leader会apply到rocksdb的kv的编程数据中
  - TiKV中超过50000个region后管理成本很高，因为每个region会定期向PD汇报自己的心跳信息，网络压力比较大
- raft日志复制功能
  - 第一步：propose，操作被leader收到了，leader准备开始同步
  - 第二步：append，将日志写入racksdb中
    - 将写入请求变成一条日志，变成一条写入日志，叫做raft log，存到自己的日志文件里（对TiKV存储在本地的racksdb实例中，专门存raft log）
    - 唯一标识：region号_日志当前序号.log，从标识找到先后顺序，哪个region发出的知道
    - Replicate：将leader的日志分发复制给其他follower所在节点。其他节点持久化到存储中后，会返回响应值（append成功的信息）给leader后，超过一半以上的节点给了回应后，leader会apply到rocksdb的kv的编程数据中
  - 第三步：commited，大多数region表示append成功持久化消息后TiKV会将这条日志取出来，应用转换为数据写在另一个rocksdb中，叫做rocksdbKV
  - 第四步：apply
  - 有两个rocksdb实例，一个是log一个是kv
- leader选举
  - term：时长不固定
  - election timeout=10s，未发送心跳信息时超过10s后，就认为现在集群就处于没有leader的状态，开始投票选自己，可能会重复选举
  - random election timeout 降低重复选举的概率
  - candidate （候选者）发请求，我要当leader，term大的candidate 成为leader
  - heatbeat time interal = 10s leader固定10s发送心跳信息
TiKV 的 Coprocessor（协同处理器，提供算子下推的能力）
- 数据写入
- 数据读取（主要解决读取数据时保证是从leader中读）
  - readIndex Read
    - 等读
  - LeaseRead（优化）localRead
  - FollowerRead
    - 和leader中的数据保持线性一致
- Coprocessor
题目：

4.PD（Placement Driver）

描述 PD 的架构与功能
- - PD有三个，有leader，只有leader可以获得TSO
  - 整个集群 TiKV 的元数据存储，region在哪个TIKV上
  - 分配全局 ID 和事务 ID
  - 生成全局时间戳 TSO
  - 收集集群信息进行调度
  - 提供 label, 支持高可用(打标签)
  - 提供 TiDB Dashboard
- 路由功能
  - 找region在哪个TIKV上
  - TiDBClient缓存TiKVRegion位置，有时不需要从PD中获取Region位置,减轻缓存压力
  - 数据太旧，可能重新访问PD写到TiKVClient
描述 TSO 的分配
- TSO = physical time + logical time
- TSO 是64位的整形数
- TSO 分配
  - 某个时间段有批处理功能
  - 解决IO存储性能瓶颈方法：
    - - 磁盘IO变成了3秒一次
      - 将一段时间的TSO放到缓存中TiDBServer各种会话排队来使用
- 高可用
  - 当leader宕机后，新leader直接跳过这3秒，形成新的TSO来继续分配，保障了高可用性（一个PD宕机后，系统依然可以使用）
  - 增长性可以保障，连续性不能保障
描述 PD 的调度原理
- PD知道全局的region分布，TiKV会周期性的汇报心跳信息
- 生成调度注意点：
  - Balance（leader，Region），Hot Region，集群拓扑，缩容，故障恢复，Region merge
描述 label 的作用
- - DC:独立数据中心
  - 12台主机，6个机柜，3个主中心
  - raft协议，多数派原则，如果一个数据中心坏了，有两个主从region坏了，则不可用了
  - region3可用性比较高，region不可用，数据库不可用
  - Region原始分布默认随PD随机分步的
  - PD只能保障同一个TiKV节点上，不会存在一个region的两个节点，region存储是由PD控制的
  - PD按照label 期待的格式进行region的分配，PD使用label 感知region的具体分布
  - 隔离级别设置isolation，表示副本分布
题目：

5.TiDB 数据库 SQL 执行流程

描述 DML 语句读写流程
- DML 语句，对表数据修改语句（delete,select,update...）
- DDL 语句，对表结构修改语句(alert,creat 表...)
- 读流程
  - 只获取开始时间
- 写流程
  - 获取开始时间，获取结束时间
  - （用户提交分为两阶段提交）两阶段提交
    - apply将内存中的修改行加锁，修改和锁信息进行持久到TiKV中（leader及其他副本）
    - commit写提交信息，将锁清理掉,去PD节点读取结束TSO
描述执行流程
- 执行流程
  - 从一个TiDBserver读取ddl数据，从owner的TiDBserver具体执行，不一定是同一个
  - owner会进行选举，轮流做owner
  - Pase解析，compile编译
  - 只读取一行数据，叫做点查（第一行Compile,PointGet）
  - 逻辑优化AST语法树，optimize（优化器）物理优化
  - DML 语句读取的执行
    - backoff说明缓存中数据过期，重新从PD中获取
    - 元数据：表头，列名
    - - KV对应点查时
      - DistSQL将复杂的操作转换为单表的操作
      - snapshot快照
    - - cop task
      - root task
  - DML 语句写入的执行
    - 解决同key操作冲突的问题，谁获取latch谁执行
  - DDL 语句的执行
题目：

6.TiDB 数据库 HTAP 概述

描述 HTAP 技术
- - OLTP（高并发） OLAP（暴力扫描）
- - ETL工具将数据抽取
- HTAP 的基本要求
  - 可扩展性：分布式事务，分布式存储
  - 同时支持 OLTP 与 OLAP：（同时有两种版本）同时支持行存和列存，OLTP与 OLAP 业务隔离
  - 实时性：行存与列存数据实时同步
- TiDB 的 HTAP 功能特性
  - 行列混合：列存（TiFlash）支持基于主键的实时更新，TiFlash 作为列存副本，OLTP 与 OLAP 业务隔离
  - 智能选择（CBO 自动或者人工选择）走TiKV还是TiFlash
  - MPP 架构，只能在TiFlash上执行(过滤，聚合，表连接)，并行计算
- MPP
  - 过滤，交换数据，表连接，聚合发生在各个TiFlash上做
  - 并行计算
工作场景
题目：

7.TiFlash

- TiFlash是TiKV的列存版本，数据和分区是一模一样的
- Reft leaner使用日志异步同步
- TiFlash只接入日志，没办法写入，只能读，和其他follower一样，从TiKV的leader复制转换来的，对原来性能影响很小，因此做到了业务的隔离性，如果TiFlash宕机后，重新复制即可
- 存在mvcc快照隔离级别，和TIKV一致性读取
TiFlash 主要功能
- 异步复制（Reft leaner）
- 一致性读取（mvcc快照隔离级别）
  - 发日志，等待确定后读取
- 引擎智能选择（可以主动选择使用TiKV还是TiFlash还是混合使用）
- 计算加速
题目

8.TiDB 6.0 新特性

了解 Placement Rules in SQL（SQL中的放置规则）（指定表具体放置在哪个节点上）
- Placement Rules in SQL 之前
  - 跨地域部署的集群,无法本地访问
  - 无法根据业务隔离资源
  - 难以按照业务等级配置资源和副本数
- Placement Rules in SQL 之后
  - 跨地域部署的集群,支持本地访问
  - 根据业务隔离资源
  - 按照业务等级配置资源和副本数
- Placement Rules in SQL 的使用 - 步骤
  - 步骤 1：设计业务拓扑, 为不同的 TiKV 实例设置标签
  - 步骤 2：创建 PLACEMENT POLICY（布局规则）
  - 步骤 3：设定数据对象的 PLACEMENT POLICY
- Placement Rules in SQL 的应用
  - 精细化数据放置,控制本地访问与跨区域访问
  - 指定副本数,提高重要业务的可用性和数据可靠性
  - 将业务按照等级、资源需求或者数据生命周期进行隔离
  - 业务数据整合,降低运维成本与复杂度
描述小表缓存（分布式数据库热点问题，提高小表的吞吐量）

-
- 原理：
  - 租约时间（5s）内,无法进行写操作，可读比较快
  - 租约到期,数据过期
    - 写操作不再被阻塞
    - 读，写，直接到 TiKV 节点上执行
  - 数据更新完毕,租约继续开启
- 应用
  - TiDB 6.0对于每张缓存表的大小限制为 64 MB
  - 适用于查询频繁、数据量不大、极少修改的场景
  - 在租约（tidb_table_cache_lease）时间内,写操作会被阻塞，在小表读，性能提高
  - 当租约到期（tidb_table_cache_lease）时,到 TiKV读，性能会下降
  - 不支持对缓存表直接做 DDL 操作,需要先关闭
  - 对于表加载较慢或者极少修改的表,可以适当延长
  - tidb_table_cache_lease 保持读性能稳定
描述内存悲观锁（事务性能提升）
- 使用 -
  - 配置文件
- 应用
  - 减少事务的延时
  - 降低磁盘和网络贷款
  - 降低 TiKV 的 CPU 消耗
  - 锁丢失问题，锁丢失，事务回滚（缺点）
了解 Top SQL（性能的可观测性：找到某个top5类型的sql，知道哪些sql的消耗（只能）cpu负载/开销是最大的）

作用：
- 可视化地展示 CPU 开销最多的 Top 5 类 SQL 语句
- 支持指定 TiDB server 及 TiKV 实例进行查询
- 支持统计所有正在执行的 SQL 语句
- 支持每秒请求数、平均延迟、查询计划等详细执行信息
了解 TiDB Enterprise Manager（TiEM）（企业级的管理平台，图形化流程化）
- 企业中 TiDB 集群管理的问题
  - 数量增长：集群数量、节点数量、组件数量、工具数量
  - 复杂度增长：配置参数复杂度、命令行复杂度、管理接口复杂
- 企业中 TiDB 集群管理的任务
  - 部署集群、升级集群、参数管理、组件管理、备份恢复与高可用管理、集群监控与告警、集群日志收集、审计与安全
- 功能
  - 一键部署集群 & 多套集群一站式管理、集群原地升级、参数管理、克隆集群 & 主备集群切换
题目：

9.TiDB Cloud

在Cloud方向考虑为什么选择TiDB
- - 方便横向扩展
  - raft实现高可用性
什么是TiDBCloud
- IaaS云服务厂商提供的基础硬件设施（服务器...）
- PaaS云服务厂商提供的基础软件平台设施（操作系统，数据库...）
- SaaS云服务厂商提供的软件基础设施直接运营即可（论坛软件...）
题目：

TiDB 数据库核心原理与架构笔记

1.功能介绍

TiDB Server集群（无状态，不存储数据）

TiKV

TiFlash

region : 96M->144M

PD:PlacementDriver

体系特点：

题目：

2.TiDBServer详情

TiDB server 架构

题目：

3.TiKV

概述

TiKV 架构和作用

TiKV 数据持久化和读取

TiKV 如何提供 MVCC 和分布式事务支持

TiKV 基于 Raft 算法的分布式一致性

TiKV 的 Coprocessor（协同处理器，提供算子下推的能力）

题目：

4.PD（Placement Driver）

题目：

5.TiDB 数据库 SQL 执行流程

6.TiDB 数据库 HTAP 概述

7.TiFlash

8.TiDB 6.0 新特性

9.TiDB Cloud

10.重点资料总结