目录

  • 一些基本概念
  • OLTP/OLAP
  • 谷歌的三驾马车
  • CAP理论
  • 计算和存储分离
  • TiDB基础
  • TiDB设计六大目标
  • TiDB分层结构
  • TiKV底层原理
  • 数据结构
  • 高可用设计
  • 如何实现扩展
  • TiKV的MVCC和事务支持
  • TiKV的存储和查找
  • 主键索引
  • 二级索引


一些基本概念

OLTP/OLAP

  1. OLTP：On-Line Transaction Processing, 在线事务处理，主要表示对数据的增删改
  • 记录某类业务的发生。如购买行为，当有订单产生后，系统需要记录何人何时何地做了什么事，要求实时性高、稳定性强、数据更新成功
  • 提供写操作的业务，一般都可以成为OLTP业务
  1. OLAP: On-Line Analytical Processing, 在线分析处理，主要表示对数据的查询
  • 当数据积累到一定程度后，需要进行数据汇总、分析、总结时，为公司决策提供数据支持，此类成为OLAP业务
  • 一般数据仓库系统是做OLAP业务

谷歌的三驾马车

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

CAP理论

  1. C: Consistency, 一致性。
  • Every read receives the most recent write or an error
  • 系统每次请求，都可以得到最新写入的数据，或者报错
  • 强调数据准确性，要么是最新数据，要么报错；针对每次请求的结果
  1. A: Availability, 可用性。
  • Every request receives a (non-error) response – without the guarantee that it contains the most recent write
  • 系统每次请求都会得到一个响应，但是不保证返回结果是最新写入的
  • 强调可用性，不保证最新，但不会报错；针对每次请求的结果
  1. 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三个特性最多能同时满足其中两个特性

计算和存储分离

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

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

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

TiDB基础

TiDB设计六大目标

  1. 扩展性
  • 横向扩展能力，弹性粒度更小
  • 面向写入的横向扩展
  1. 强一致和高可用
  • 指CAP中的C，即副本一致性；更多只多数派的强一致，比如三个副本强制写两个节点（写的副本数越多，写延迟越大）
  • RPO: 数据恢复点目标。指系统所能容忍的数据丢失量
  • RTO: 恢复时间目标。指系统所能容忍的故障恢复时间
  • 强一致和高可用即实现：RPO = 0， RTO尽可能小
  1. 标准SQL，支持ACID事务
  • OLTP场景，对于写入事务仍然是强需求
  1. 云原生
  • 在计算与存储分离的背景下，云原生支持资源的弹性扩展
  1. HTAP
  • 混合数据服务；支持海量数据下的OLTP和OLAP服务融合
  1. 兼容主流生态和协议
  • 降低用户的接入门槛
  • 数据技术栈和架构的本质：在相对固定的基础数据技术元素上，进行各种选择、平衡和优化
  • 基础数据技术元素包括，数据模型、存储引擎、索引、数据格式等

TiDB分层结构

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

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

TiKV底层原理

数据结构

  1. 底层存储使用LSM-tree结构
  • 本质是一个用空间置换写入延迟，用顺序写替换随机写的数据结构
  1. TiKV单节点选择基于LSM-tree的RockDB引擎作数据存储
  • RockDB引擎是一个成熟的LSM-tree存储引擎
  • 支持批量写入
  • 支持无锁快照读

高可用设计

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

如何实现扩展

  1. 使用range分片
  • 高效扫描数据行数
  • 简单实现自动化合并和分裂
  • 自动调用更友好
  1. TiKV可以看成一个巨大的Key-Value Map，根据Key的大小划分成若干个Range
  2. 根据range大小自动扩展和合并
  • 默认range大小为96M
  • 默认range分裂的大小为144M
  1. TiKV以range为单位存储，每个range的多副本分布在不同的TiKV节点上，PD支持查询key所在的range，以及所在的节点

TiKV的MVCC和事务支持

  1. TiKV的多版本控制，通过在key后面添加版本号控制
  • 所有版本都是一个新的key，且在整个key-value map中存储
  1. TiKV使用去中心化的两阶段提交支持事务
  • 每个TiKV节点上分配一个CF Lock存储当前节点上的锁信息
  • PD支持所有TiKV节点的顺序一致性
  • 每个TiKV部署一个Coprocessor，利用TiKV多节点的并行计算能力，将计算下推

TiKV的存储和查找

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

主键索引

  1. TiKV-Key = RowID + IndexID
  2. TIKV-Value = 所有的列（按照等位偏移的方式存储）

二级索引

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

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