这是我参与「第五届青训营 」笔记创作活动的第17天
一:RDBMS简介
1:事务 ACID
- 事务(Transaction):是由一组SQL语句组成的一个程序执行单元(Unit),它需要满足ACID特性。
- ACID:
- 原子性(Atomicity):事务是一个不可再分割的工作单元,事务中的操作要么都发生,要么都不发生
- 一致性(Consistency):数据库事务不能破坏关系数据的完整性以及业务逻辑上的一致性
- 隔离性(图solation):多个事务并发访问时,事务之间是隔离的,一个事务不应该影响其它事务运行效果
- 持久性(Durability):在事务完成以后,该事务所对数据库所作的更改便持久的保存在数据库之中,并不会被回滚
- 要满足高并发、高可靠的要求
2:DBMS数据模型
(1)网状模型
- 网状数据库所基于的网状数据模型建立的数据之间的联系,能反映现实世界中信息的关联,是许多空间对象的自然表达形式。
- 1964年,世界上第一个数据库系统——集成数据存储(Integrated Data Storage , lDS)诞生于通用电气公司。IDS是世界上第一个网状数据库,奠定了数据库发展的基础,在当时得到了广泛的应用。在1970s网状数据库系统十分流行,在数据库系统产品中占据主导地位。
(2)层次模型
1968年,世界上第一个层次数据库——信息管理系统( Information Management System , IMS )诞生于IBM公司,这也是世界上第一个大型商用的数据库系统。层次数据模型,即使用树形结构来描述实体及其之间关系的数据模型。
(3)关系模型
1970年,IBM的研究员E.F.Codd博士发表了一篇名为"A Relational Model of Data for Data Banks"的论文,提出了关系 模型的概念,奠定了关系模型的理论基础。1979年Oracle首次将关系型数据库商业化,后续DB2, SAP Sysbase ASE, and Informix等知名数据库产品也纷纷面世。
3:SQL语言
1974年IBM的Ray Boyce和Don Chamberlin将Codd关系数据库的12条准则的数学定义以简单的关键字语法表现出来,里程碑式地提出了SQL(Structured Query Language)语言。
- 语法风格接近自然语言;
- 高度非过程化;
- 面向集合的操作方式
- 语言简洁,易学易用。
二:RDBMS关键技术
1:一条SQL的生命历程
2:SQL引擎
(1)parser
解析器(Parser)一般分为词法分析(Lexical analysis )、语法分析( Syntax analysis )、语义分析(Semantic analyzer )等步骤。
(2)optimizer
- 优化器作用:
- 基于规则的优化(RBO Rule Base Optimizer)
- 条件化简
- a = 5 and b > a → a = 5 and b > 5
- a > 5 and a < b and b = 1 √ → FALSE
- 表连接优化
- 总是小表先进行连接
- Scan优化
- 唯一索引
- 普通索引
- 全表扫描
- 条件化简
数据库索引:是数据库管理系统中辅助数据结构,以协助快速查询、更新数据库表中数据。目前数据库中最常用的索引是通过B+树实现的。
- 基于代价的优化(CBO Cost Base Optimizer)
- 一个查询有多种执行方案,CBO会选择其中代价最低的方案去真正的执行。
(3)executor
-
火山模型:
-
每个Operator调用Next操作,访问下层Operator,获得下层perator返回的一行数据,经过计算之后,将这行数据返回给上层。
-
优点∶
- 每个算子独立抽象实现,相互之间没有耦合,逻辑结构简单
-
缺点∶
- 每计算一条数据有多次函数调用开销,导致CPU效率不高。
-
-
向量化:
-
每个Operator每次操作计算的不再是一行数据,而是一批数据(Batch N行数据),计算完成后向上层算子返回一个Batch,
-
优点:
- 函数调用次数降低为1/N;
- CPU cache命中率更高;
- 可以利用CPU提供的SIMD(Single Instruction Multi Data)机制。
-
-
编译执行:
- 将所有的操作封装到一个函数里面,函数调用的代价也能大幅度降低.
- 用户SQL千变万化怎么办?难道要穷举用户的所有SQL,给每一个SQL都预先写好一个执行函数吗?
- LLVM动态编译执行技术
3:存储引擎
(1)InnoDB
- In-Memory:
- Buffer Pool
- Change Buffer
- Adaptive Hash Index
- Log Buffer
- On-Disk:
- System Tablespace(ibdata1)
- General Tablespaces(xxx.ibd)
- Undo Tablespaces(xoxx.ibu)
- Temporary Tablespaces(xxx.ibt)
- Redo Log(ib_logfileN)
(2)buffer pool
(3)page
- Header
- delete_mask :标识此条数据是否被删除。
- next_record :下一条数据的位置。
- record_type:表示当前记录的类型。
(4)B+ tree
- 页面内:
- 页目录中使用二分法快速定位到对应的槽,然后再遍历该槽对应分组中的记录即可快速找到指定的记录。
- 从根到叶:中间节点存储
- 点查:
- select * from table wehre id = 2000;
- 范围查询:
- Select * from table wehre id > 2000;
4:事务引擎
(1)Atomicity Undo Log
如何取消修改?——undolog
Undo Log是逻辑日志,记录的是数据的增量变化。利用Undo Log可以进行事务回滚,从而保证事务的原子性。同时也实现了多版本并发控制(MVCC) ,解决读写冲突和一致性读的问题。
(2)isolation与锁
(3)isolation与MVCC
- MVCC的意义∶
- 读写互不阻塞;
- 降低死锁概率;
- 实现一致性读。
(4)durability与redo log
如何保证事务结束后,对数据的修改永久的保存?
- 方案一:事务提交前页面写盘
- 方案二: WAL(Write-ahead logging)
- redo log是物理日志,记录的是页面的变化,它的作用是保证事务持久化。如果数据写入磁盘前发生故障,重启MySQL后会根据redo log重做。
三:企业级实践
1:大流量-sharding
- 问题背景
- 单节点写容易成为瓶颈
- 单机数据容量上限
- 解决方案
- 业务数据进行水平拆分
- 代理层进行分片路由
- 实施效果
- 数据库写入性能线性扩展
- 数据库容量线性扩展
2:流量突增-扩容
- 问题背景
- 活动流量上涨
- 集群性能不满足要求
- 解决方案
- 扩容DB物理节点数量
- 利用影子表进行压测
- 实施效果
- 数据库集群提供更高的吞吐
- 保证集群可以承担预期流量
3:流量突增-代理连接池
- 问题背景
- 突增流量导致大量建联
- 大量建联导致负载变大,延时上升
- 解决方案
- 业务侧预热连接池。
- 代理侧预热连接池
- 代理侧支持连接队列
- 实施效果
- 避免DB被突增流量打死
- 避免代理和DB被大量建联打死
4:稳定性&可靠性 -3AZ高可用
- 三机房部署
- 机房级别容灾
- 机房级别流量调度
- proxy
- 读写分离,分库分表
- 限流,流量调度
- 监控报警
- 实时监控集群运行状态
- 提前上报集群风险
- HA
- High Availability
- 实时监控DB运行状态
- 宕机快速切换
5:稳定性&可靠性 -HA管理
- 问题背景
- db所在机器异常宕机
- db节点异常宕机
- 解决方案
- ha服务监管、切换宕机节点
- 代理支持配置热加载
- 代理自动屏蔽宕机读节点