TiDB基础

一些基本概念

OLTP/OLAP谷歌的三驾马车CAP理论计算和存储分离 TiDB基础

TiDB设计六大目标TiDB分层结构 TiKV底层原理

数据结构高可用设计如何实现扩展TiKV的MVCC和事务支持TiKV的存储和查找

主键索引二级索引

OLTP：On-Line Transaction Processing, 在线事务处理，主要表示对数据的增删改

记录某类业务的发生。如购买行为，当有订单产生后，系统需要记录何人何时何地做了什么事，要求实时性高、稳定性强、数据更新成功提供写操作的业务，一般都可以成为OLTP业务 OLAP: On-Line Analytical Processing, 在线分析处理，主要表示对数据的查询

当数据积累到一定程度后，需要进行数据汇总、分析、总结时，为公司决策提供数据支持，此类成为OLAP业务一般数据仓库系统是做OLAP业务

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

C: Consistency, 一致性。

Every read receives the most recent write or an error系统每次请求，都可以得到最新写入的数据，或者报错强调数据准确性，要么是最新数据，要么报错；针对每次请求的结果 A: Availability, 可用性。

Every request receives a (non-error) response – without the guarantee that it contains the most recent write系统每次请求都会得到一个响应，但是不保证返回结果是最新写入的强调可用性，不保证最新，但不会报错；针对每次请求的结果 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三个特性最多能同时满足其中两个特性

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

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

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

扩展性

横向扩展能力，弹性粒度更小面向写入的横向扩展 强一致和高可用

指CAP中的C，即副本一致性；更多只多数派的强一致，比如三个副本强制写两个节点（写的副本数越多，写延迟越大）RPO: 数据恢复点目标。指系统所能容忍的数据丢失量RTO: 恢复时间目标。指系统所能容忍的故障恢复时间强一致和高可用即实现：RPO = 0， RTO尽可能小 标准SQL，支持ACID事务

OLTP场景，对于写入事务仍然是强需求 云原生

在计算与存储分离的背景下，云原生支持资源的弹性扩展 HTAP

混合数据服务；支持海量数据下的OLTP和OLAP服务融合 兼容主流生态和协议

降低用户的接入门槛数据技术栈和架构的本质：在相对固定的基础数据技术元素上，进行各种选择、平衡和优化

基础数据技术元素包括，数据模型、存储引擎、索引、数据格式等

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

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

底层存储使用LSM-tree结构

本质是一个用空间置换写入延迟，用顺序写替换随机写的数据结构 TiKV单节点选择基于LSM-tree的RockDB引擎作数据存储

RockDB引擎是一个成熟的LSM-tree存储引擎支持批量写入支持无锁快照读

支持多副本机制

多副本是系统可用性的保证 基于raft算法，实现以RockDB引擎为基础的多副本，高可用集群

使用range分片

高效扫描数据行数简单实现自动化合并和分裂自动调用更友好 TiKV可以看成一个巨大的Key-Value Map，根据Key的大小划分成若干个Range根据range大小自动扩展和合并

默认range大小为96M默认range分裂的大小为144M TiKV以range为单位存储，每个range的多副本分布在不同的TiKV节点上，PD支持查询key所在的range，以及所在的节点

TiKV的多版本控制，通过在key后面添加版本号控制

所有版本都是一个新的key，且在整个key-value map中存储 TiKV使用去中心化的两阶段提交支持事务

每个TiKV节点上分配一个CF Lock存储当前节点上的锁信息PD支持所有TiKV节点的顺序一致性每个TiKV部署一个Coprocessor，利用TiKV多节点的并行计算能力，将计算下推

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

TiKV-Key = RowID + IndexIDTIKV-Value = 所有的列（按照等位偏移的方式存储）

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

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