这是我参与「第五届青训营 」伴学笔记创作活动的第 16 天
一、本堂课重点内容
- 经典案例
- 发展历史
- 关键技术
- 企业实践
二、本堂课详细内容
0.前言
我在学员手册里找到一些课前需要了解的知识在这里记录下 首先不知道什么原因,推荐的两篇论文在学员手册中无法找到,所以我找到之后把它传到飞书文档,然后贴在这里
1. A Relational Model of Data for Large Shared Data Banks
这篇论文是RDBMS的奠基之作,由RDBMS之父E.F.Codd博士于1970年发表。在这篇论文中,E.F.Codd首次提出了用于管理数据的关系模型,并将数据独立于硬件来存储,用户使用一个非过程语言来访问数据。
2. Readings in Database Systems(Fifth Edition)
这本书被称为数据库领域的“红宝书”,由著名的图灵奖获得者,数据库领域专家,Michael Stonebraker撰写。其中介绍了数据库的基本概念,传统的RDBMS以及新的数据库架构等等,是一本非常棒的数据库领域入门文章。
1.经典案例
①抖音红包雨
上图过程可以转换为下图的sql语句
②RDBMS的事务
概念
事务(Transaction):是由一组SQL语句组成的一个程序执行单元(Unit),它需要满足ACID特性。 那么什么是ACID?
- 原子性(Atomicity):事务是一个不可再分割的工作单元,事务中的操作要么都发生,要么都不发生。
- 一致性(Consistency):数据库事务不能破坏关系数据的完整性以及业务逻辑上的一致性。
- 隔离性(lsolation):多个事务并发访问时,事务之间是隔离的,一个事务不应该影响其它事务运行效果。
- 持久性(Durability):在事务完成以后,该事务所对数据库所作的更改便持久的保存在数据库之中,并不会被回滚。
学到这里突然发现 数据库原理 里边学过这个东西
下边就是解释了ACID 就是说人话这个emmm
- 原子性Atomicity
- 两个操作要么同时成功,要么同时失败,不存在中间状态。
- 一致性Consistency
- 每个操作都必须是合法的,账户信息应该从一个有效的状态变为另一个有效的状态。
- 隔离性Isolation
- 两个操作在对同一个账户并发进行操作时,应该是相互不影响,表现的像是串行操作。
- 持久性Durability
- 操作更新成功之后,更新的结果应该永久性的保留下来,不会因为宕机等问题而丢失。
高可靠 高可用 高并发 这三个基本不用解释
2.发展历史
DBMS
数据库发展最初过程中,诞生过3种数据模型,最终关系型模型成为了应用最为广泛的数据库模型。
- 网状模型:用有向图表示实体和实体之间的联系的数据结构模型称为网状数据模型。
- 层次模型:层次数据模型是用树状<层次>结构来组织数据的数据模型。
- 关系模型:使用表格表示实体和实体之间关系的数据模型称之为关系数据模型。
三种模式的优势劣势
| 网状模型 | 层次模型 | 关系模型 | |
|---|---|---|---|
| 优势 | 能直接描述现实世界 存取效率较高 | 结构简单 查询效率高 可以提供较好的完整性支持 | 实体及实体间的的联系都通过二维表结构表示 可以方便的表示M:N关系 数据访问路径对用户透明 |
| 劣势 | 结构复杂 用户不易使用 访问程序设计复杂 | 无法表示M:N的关系 插入、删除限制多 遍历子节点必须经过父节点 访问程序设计复杂 | 关联查询效率不够高 关系必须规范化 |
sql语言
1974年IBM的Ray Boyce和Don Chamberln将Codd关系数据库的12条准则的数学定义以简单的关键字语法表现出来,里程碑式地提出了SQL(Structured Query Language)语言。
其优点是
- 语法风格接近自然语言;
- 高度非过程化;
- 面向集合的操作方式;
- 语言简洁,易学易用。
sql语言对于非关系型数据库
- 高度非过程化
- 非关系数姻摸鼓擞拥操纵语言是面向过程的话言,用其完成用中请,时,必须能定存取路怪,而BSQU进行数拥媒作,用户只需提出做什么,而不必指阳怎么做,因此用户无须了解存取路径,存取路径的进挥择以及SQU语句的操作过程由系统自动完成。这不但大大减轻了用户负担,而且有利于提高数据独立性。 面向集合的操作方式
- SQL采用集合操作方式,不仅查找结果可以是元组的集合,而且一次插入、删除、更新操作的对象也可以是元组的集合。
- 语言简洁,易学易用
- SQL功能极强,但由于设计巧妙,语言十分简洁,完成数据定义、数据操纵、数据控制的核心功能只用了9个动词:CREATE、ALTER、DROP、SELECT. INSERT、UPDATE、DELETE、GRANT、REVOKE。且SQL语言语法简 单,接近英语口语,因此容易学习,也容易使用。
整个发展历史可以概括为
3.关键技术
1.一条sql的一生
SQL 引擎
SQL引擎包括了:
- Paser:经过词法分析、语法分析生成语法树,然后对语法树进行合法性校验。
- Optimizer:根据Parser产生的语法树,根据规则或者代价产生执行计划树。
- Executor:根据计划树进行执行,常见的执行方式是火山模型。
存储引擎
存储引擎负责了数据的底层存储、管理和访问工作。各大RDBMS存储引擎的设计都有不少的差异,这里选择MySQL的InnoDB存储引擎来向大家做一个介绍:
- Buffer Pool:存储引擎位于内存中的重要结构,用于缓存数据,减少磁盘IO的开销。
- Page:数据存储的最基本单位,一般为16KB。
- B+u Tree:InnoDB中最常用的索引结构。
事务引擎
事务引擎实现了数据库的ACID能力,这里还是以MySQL的InnoDB为例来介绍数据库内部是通过哪些技术来实现ACID:
- Atomicity:InnoDB中通过undo日志实现了数据库的原子性,通过Undo Log,数据库可以回滚到事务开始的状态;
- Isolation:通过Undo Log实现MVCC(多版本并发控制),降低读写冲突。
- Durability:通过Redo Log(一种WAL实现方式)来保证事务在提交后一定能持久化到磁盘中。
- Consistency:一致性本质上是一种业务层的限制。
企业实践
字节中是国内数据规模最大的互联网公司之一,公司内部有成千上万套RDBMS系统。这一章节还是以红包雨为案例,展示了字节是如何解决大流量、流量突增、高可靠等问题的。
春节红包雨面临的挑战
如何解决
- 大流量
- 问题背景
- 单节点写容易成为瓶颈
- 单机数据容量上限
- 解决方案
- 业务数据进行水平拆分
- 代理层进行分片路由
- 实施效果
- 数据库写入性能线性扩展
- 数据库容量线性扩展
- 问题背景
- 流量突增 - 扩容
- 问题背景
- 活动流量上涨
- 集群性能不满足要求
- 解决方案
- 扩容DB物理节点数量
- 利用影子表进行压测
- 问题背景
- 实施效果
- 数据库集群提供更高的吞吐
- 保证集群可以承担预期流量
- 流量突增 - 代理连接池
- 问题背景
- 突增流量导致大量建联
- 大量建联导致负载变大,延时上升
- 解决方案
- 业务侧预热连接池
- 代理侧预热连接池
- 代理侧支持连接队列
- 实施效果
- 避免DB被突增流量打死
- 避免代理和DB被大量建联打死
- 问题背景
- 稳定性&可靠性
- 两地三中心
- proxy
- 读写分离,分库分表限流,流星调度
- 监控报警
- 实时监控集群运行状态提前上报集群风险
- HA(High Availability)
- 实时监控DB运行状态宕机快速切换
- HA管理
- 问题背景
- db所在机器异常宕机. db节点异常宕机
- 解决方案
- ha服务监管、切换宕机节点·代理支持配置热加载
- 代理自动屏蔽宕机读节点
- 实施效果
- 读节点宕机秒级恢复
- 写节点宕机,30s内恢复服务
- 问题背景
三、 课后大作业
-
WAL 日志到底是如何保证数据的持久化,宕机后数据不丢失的?相比于其他方案,WAL 日志都有什么优势?
-
除了 Undo Log 之外,是否还有其他方案可以实现 MVCC?
-
基于代价的优化器一般需要考虑哪些代价?
-
执行器的执行模型,除了本课中提到的火山模型是否还有其他模型?相比于火山模型有什么优劣势?
-
InnoDB 的 B+ Tree 是怎么实现的?
-
InnoDB 的 buffer pool 是怎么实现页面管理和淘汰的?