TiDB 基础

品茗听雪抚琴

已于 2023-03-17 16:05:51 修改

阅读量337

点赞数

分类专栏： # 数据库业务文章标签：数据库 Powered by 金山文档

于 2023-03-17 14:03:43 首次发布

本文链接：https://blog.csdn.net/xiuling216/article/details/129618535

版权

数据库同时被 2 个专栏收录

2 篇文章 0 订阅

订阅专栏

业务

2 篇文章 0 订阅

订阅专栏

本章节内容为看《TiDB 快速起步》视频课程后的学习笔记。
作为个人成长学习使用，同时希望对刷到的朋友有所帮助，一起加油哦！

生命就像一朵花，要拼尽全力绽放，芳香四溢，在风中舞蹈！

数据库、大数据与 TiDB 的发展简史

1.1 数据库、大数据发展历史与趋势

数据库发展历程：

图片来自迈瑞行业报告内容。

数据库技术发展内在驱动：

业务发展：数据容量持续爆发增长——数据存储量、吞吐量、读写QPS等

场景创新：数据的交互效率与数据模型多样性——查询语言、计算模型、数据模型、读写延时等

硬件与云计算的发展：数据架构的变迁——读写分离、一体机、云原生等

数据容量催生数据架构演进：

单节点本地磁盘

纵向扩展Scale up，网络存储ShareDisk

横向扩展Scale out，分布式Share Nothing

数据模型与交互效率演进：

数据库类型	产生原因
RDBMS 单机数据库	支持事务并绝大部分采用结构化的方式存储
NoSQL	Key-value、文本、图、时序数据、地理信息等非结构化数据的需求
OLTP	大部分NoSQL数据库对于事务无法支持
NewSQL	同时支持OLTP和兼容多种数据模式

应对不同业务场景，基于这些相对固定数据基础技术，进行数据架构Trade OFF（选择与平衡）。

数据模型、数据结构、存储算法、复制协议、算子、计算模型、硬件

1.2 分布式关系数据库的发展

分布式产生的内因：

1965年，高登.摩尔（Gordon Moore），提出摩尔定律。

核心观点：集成电路上可以容纳的晶体管数目在大约每经过18个月便会增加一倍。换言之，处理器的性能每隔两年翻一倍。

隐含意思：如果你的系统需承载的计算量的增长速度，大于摩尔定律的预测，集中式系统将无法承载你所需的计算量。

分布式定义

分布式，本质上是进行数据存储与与计算的分治。

由于机器可能出现故障，分布式会提高故障率，因此需要多副本来解决高可用问题。

分布式历史

2006年，谷歌三架马车：

GFS(Google File System)	解决分布式文件系统问题
Google Bigtable	解决分布式KV存储问题
Google MapReduce	解决分布式文件系统和分布式KV存储上面如何做分布式计算和分析的问题

分布式技术的主要挑战：

如何最大程度的实现分治

如何实现全局一致性，包括序列化与全局时钟

如何进行故障与部分失效的容错

如何应对不可靠的网络与网络分区

一致性

consistency

所有节点在同一时间的数据完全一致

可用性

Avaliability

服务在正常响应时间内一直可用

分区容错性

Partition tolerance

分布式系统在遇到某节点或网络分区故障时，仍然能够对外提供满足一致性或可用性的服务。

ACID

事务的本质：并发控制单元，是用户定义的一个操作序列。要么都做，要么都不做，不可分割的工作单元。

原子性 Atomicity	事务包含的全部操作是一个不可分割的整体，要么全部执行，要么全部不执行。
一致性 Consistency	事务前后，所有的数据都保持一致的状态，不能违反数据的一致性检查。
隔离性 Isolation	各个事务之间相互影响的程度，主要用于规定多个事务访问同一数据资源，各个事务对该数据资源访问的行为。不同的隔离性是为了应对不同的现象，比如脏读、可重复读、幻读等。
持久性 Durability	事务一旦完成，要将数据所做的变更记录下来。

CAP和ACID都有一致性，但 CAP (副本一致性) 与 ACID (事务一致性) 里的两个一致性描述的场景却不同。

NewSQL

NewSQL = 分布式系统 + SQL + 事务

即原生分布式关系型数据库。

1.3 TiDB 产品与开源社区演进

分布式两个重要基础：Google spanner、Raft

开源特点：开放源码、开放态度、开源社区治理

TiDB是一个计算与存储分离的架构，存储引擎叫TiKV。

2015年5月，在Github创建项目。

TiDB 整体概述

2.1 我们到底需要一个什么样的数据库

重新设计一个数据库，必须有的功能：

(1) 扩展性

弹性角度，颗粒度越小越好。

数据库写入资源昂贵，需要面向写入能力的线性扩展机制。

(2) 强一致性与高可用性

强一致性指CAP的一致性。常见强制写入两节点副本。

RPO(Recovery Point Objective)即数据恢复点目标。

RTO(Recovery Time Objective)即恢复时间目标。

强一致等价：RPO=0 ，RTO足够小，通常若干秒级。

(3) 标准SQL与事务（ACID）的支持

SQL易用性

OLTP完整事务性

(4) 云原生数据库

(5) HTAP

支持海量数据

行列混合，彻底资源隔离

开放，兼容数据库与大数据生态

统一数据查询服务

(6) 兼容主流生态与协议

降低使用门槛和成本

基础数据技术元素

序号	元素	说明
1	数据模型	关系模型、文档模型、key-value模型等
2	数据存储与检索结构	数据结构、索引结构，常见B-tree、LSM-tree等
3	数据格式	关系型和非关系型
4	存储引擎	负责数据的存取和持久化存储，比如Innodb\Rockdb等。
5	复制协议	保证数据可用性，复制协议与算法，常见Raft、Paxos等
6	分布式事务模式	事务处理时的并发控制方法，以保证可串行化。常用模型SZ\TCC\Percolator等。
7	数据架构	一般指多个计算引擎共享一份数据，或者每个计算引擎都有一份数据。常见Share-Nothing\Share-Disk等。
8	优化器算法	根据数据分布、数据量和统计信息，生成成本最低的执行计划。
9	执行引擎	比如火山模型、向量化、大规模并行计算等。
10	计算引擎	负责SQL语句接口，解析生成执行计划并发送给存储引擎来执行，同时大部分计算引擎具有缓存数据的功能。

计算与存储分离

存储与计算耦合方式弊端：

(1) 计算与存储强绑定，意味着总有一种资源的浪费。

(2) 在服务器选型时，会纠结计算型、存储型，增加了复杂度，降低了通用性。

(3) 在云计算的场景下，弹性的颗粒度是机器，不能真正做到资源的弹性。

在云时代，基于高性能的网络块存储（EBS），存储与计算耦合的方式更不合理。

TiDB高度分层架构

(1) 支持标准SQL的计算，引擎TiDB-Server

(2) 分布式存储引擎TiKV

(3) 负责元信息管理与调度的，调度引擎Placement Driver

2.2 如何构建一个分布式存储系统

我们需要一个什么样的存储引擎：

更细粒度的弹性扩容、缩容

高并发读写

数据不丢不错

多副本保障一致性及高可用

支持分布式事务

如何构建一个完整的分布式存储系统

(1) 选择数据结构

Key-value数据模型

索引结构LSM-tree.（对写入采取了顺序写的方式，写入到一定阈值后，持久化成一个静态文件，随着写入的越来越大，生产的静态文件会被推到下一层进行再合并。本质上是用空间置换写入延迟，用顺序写入替换随机写入。）

(2) 选择数据副本——Raft

(3) 如何实现扩展

分片采用：rang算法

Region：key-value空间的分段。当前默认96MB。

(4) 如何进行分离与扩展

通过region的大小来分裂与合并。——当region超过一定限制（默认144MB），TiKV会将它分裂为两个或多个，当region因大量删除过小，TiKV会合并相邻region。

有一个组件记录Region在各节点分布情况。

Raft对三副本复制

(5) 灵活调度机制

PD组件负责region均匀分散，实现存储容量水平扩展、负载均衡。

(6) 多版本控制MVCC

(7) 分布式事务模型

采用Google的Percolator事务模型，并优化及该井。克服了采用“两阶段”提交方式事务管理器性能瓶颈：

采用“去中心化”的两阶段提交算法。列簇、全局受时TSO；

默认隔离级别Snapshot Isolation，SI和RR（可重复度）隔离级别接近，天然没有幻读现象。同时也支持RC(提交读）隔离级别；

支持乐观锁、悲观锁；

支持第二阶段异步提交。

(8) 协作处理器

协调计算器Coprocessor。

(9) TiKV整体架构

TiKV参考Google Spanner设计了multi raft-group的副本机制，首先将数据按照key的范围划分成大致相等的切片（region），每个切片会有多个副本（通常3个），其中一个副本是leader，提供读写服务。TiKV通过PD对这些region以及副本进行调度，并决策哪个副本成为leader，以保证数据和读写负载都均匀的分散在各个TiKV上，这样的设计保证了整个集群资源的充分利用并且可以随着机器数量的增加水平扩展。