深入理解RDBMS | 青训营笔记 

等待救赎的波
136 阅读8分钟

这是我参与「第三届青训营 -后端场」笔记创作活动的的第15篇笔记

经典案例

RDBMS 事务 ACID

事务(Transaction):是由一组SQL语句组成的一个程序执行单元(Unit)，它需要满足ACID特性。

image.png

ACID:

  • 原子性(Atomieity):事务足一个不可再分割的工作单元，事务中的操作要么都发生，要么都不发生。
  • 一致性(Consisteney):数据库事务不能破坏关系数据的完整性以及业务逻辑上的一致性。
  • 隔离性(Jsolation):多个事务并发访问时，事务之间足隔离的，一个事务不应该影响其它事务运行效果。
  • 持久性(Durasility):在事务完成以后，该事务所对数据库所作的更改便持久的保存在数据库之中，并不会被回滚。

红包雨与ACID

Case 1:抖音的账户上扣了一个亿之后，假设服务器挂了，还没来得及给羊老师账户上加一个亿

image.png

原子性 Atomicity

两个操作要么同时成功，要么同时失败，不存在中间状态。

Case2：假设抖音的账户上只有0.5个亿，但是扣减1个亿的操作成功了。

image.png

一致性Consistency

每个操作都必须是合法的，账户信息应该从一个有效的状态变为另一个有效的状态。

Case 3:羊老师从抖音抢了一个亿红包，又从头条抢了一个亿，两个转账同时进行，假设他们都以为是从零开始更新羊老师的账户余额，羊老师最后得到一个亿。 image.png

隔离性

两个操作在对同一个账户并发进行操作时，应该是相互不影响，表现的像是串行操作。

Case 4:抖音的账户上扣了一个亿，然后羊老师账户上加一个小目标，但都还没写到磁盘上。这个时候，如果服务器挂了:

image.png 持久性Durability

操作更新成功之后，更新的洁果应该永久性的保留下来，不会因为宕机等问题而丢失。

红包雨与高并发

Case 5:全国4亿人，假设有10亿人同时开抢红包，每秒处理一个请求，那需要31年才能完成。春节完了，抖音可能也被大家嫌弃了......---高并发Concurreney

image.png

红包雨与高可靠

Case 6:假设除夕晚上大家正在愉快的从抖音身上薅羊毛"，这时候服务器挂了，程序员花了一个小时，头发都掉光了，终于修好了。这时候发现李谷一老师《难忘今宵》都唱完了。"抖音宕机秒上热搜.....--高可幕、高可用High Reliability/ Availability

image.png

发展历史

前DBMS时代 - 人工管理

在现代计算机发明出来以前，通过人工的方式进行数璐记录和管理:

image.png

DBMS 时代

1960s，传统的文件系统已经不能满足人们的需要，数据中管理系统(DBMS)应运而生。

DBMS:按照某种数据模型来组织、存储和管理数据的仓库。

所以通常按照数据模型的特点将传统数据库系统分成网状数据库、层次数据库和关系数据库三类。

image.png

DBMS数据模型 - 网状模型

网状数据库所基于的网状数据模型建立的数据之间的联系，能反映现实世界中信息的关联，是许多空间对象的自然表达形式,1964年，世界上第一个数据库系统——集成数据存储（Integrated Data Storage，IDS）诞生于通用电气公司。IDS是世界上第一个网状数据库，奠定了数据库发展的基础，在当时得到了广泛的应用。在1970s网状数据库系统十分流行，在数据库系统产品中占据主导地位

image.png

DBMS数据模型 - 层次模型

image.png

1968年，世界上第一个层次数据库--信息管理系统(Information Management System,IMS)诞生于IBM公司，这也是世界上第一个大型商用的数据库系统。层次数据模型，即使用树形结构来描述实体及其之间关系的数据模型。

DBMS数据模型 - 关系模型

1970年，IBM的研究员E.F.Codd博士发表了一篇名为“ReltionalModlel ilDita fior Largeshared Dat Ban”的论文，提出了关系模型的概念，奠定了关系模型的理论基础。1979年Oracle首次将关系型数据库商业化，后续DB2, SAP Sysbase ASE, and Informid等知名数据阵产品也纷纷面世。

image.png

DBMS 数据模型

image.png

SQL语言

image.png

1974年IBM的Ray Boyce和Don Chamberin将Codd关系数据库的12条准则的数学定义以简单的关键字语法表现出来，里程碑式地捉出了SQL(Structured Query Language)语言。

  • 语法风格接近自然语言;
  • 高度非过程化;
  • 面向集合的操作方式;
  • 语言简洁，易学易用

image.png

历史回顾

image.png

关键技术

一条SQL的一生

image.png

SQL引擎 - Parser

解析器(Parser)一般分为词法分析(Lexical analysis)、语法分析(Syntax analysis)、语义分析(Semantic analyzer)等步骤,

image.png

SQL引擎 - Optimizer

为什么需要一个优化器?

根据不同的条件选择不同的路径

image.png

image.png

基于规则的优化(RBO Rule Base Optimizer)

image.png

基于代价的优化(CBO Cost Base Optimizer)

一个查询有多种执行方案，CBO会选择其中代价最低的方案去真正的执行。

image.png

SQL引擎 - Executor

每个Operator调用Next操作，访问下层Operator，获得下层Operator返回的一行数据，经过计算之后，将这行数据返回给上层。

优点:

  • 每个算子独立抽象实现，相互之间没有合，逻辑结构简单
  • 缺点:
  • 每计算一条数据有多次函数调用开销，导致CPU效率不高。

image.png

image.png

每个Operator每次操作计算的不再是一行数据，而是一批数据(Batch N行数据)，计算完成后向上层算子返回一个Batch,

优点:

  • 函数调用次数降低为1/N;
  • CPU cache命中率更高;
  • 可以利用CPU提供的SIMD(Single lnstruction Multi Data)机制。

image.png

将所有的操作封装到一个函数里面，函数调用的代价也能大幅度降低。

用户SQL千变万化怎么办?难道要穷举用户的所有SQL，给每一个SQL都预先写好一个执行函数吗?

image.png

image.png

存储引擎 - InnoDB

ln-Memory:

  • Buffer Pool
  • Change Buffer
  • Adaptive Hash lndex.
  • Log Buffer On-Disk
  • System Tablespace(ibdata1)
  • General Tablespaces(xox.ibd)
  • Undo Tablespaces(ox.ibu)
  • Temporary Tablespaces(cocx.ibt)
  • Redo Loglib_logfileN)

image.png

存储引擎 - Buffer Pool

image.png

image.png

image.png

存储引擎 - Page

image.png

存储引擎 - B+ Tree

页面内:

  • 页目录中使用二分法快速定位到对应的槽，然后再渥历该槽对应分组中的记录即可快速龙至指定的记录。 从根到叶:
  • 中间节点存储

image.png

事务引擎

image.png

Atomicity 与 Undo Log

image.png

Undo Log是逻辑日志，记录的是数据的增量变化。利用Undo Log可以进行事务回滚，从而保证事务的原子性。同时也实现了多版本并发控制(MVCC) ,解决读写冲突和一致性读的问题。

image.png

Isolation 与 锁

image.png

Isolation 与 MVCC

MVCC的意义:

  • 读写互不阻塞;
  • 降低死锁概率;
  • 实现一致性读。 Undo Log在MVCC的作用:
  • 每个事务有个单增的事务ID;
  • 数据页的行记录中包含了DB_ROW_ID,DB_TRX_ID,DB_ROLL_PTR;
  • DB_ROLL_PTR将数据行的所有快照记 录都通过链表的结构串联了起来。

image.png

Durability 与 Redo Log

image.png

企业实践

春节红包雨挑战

image.png

大流量 - Sharding

问题背景

  • 单节点写容易成为瓶颈
  • 单机数据容星上限 解决方案
  • 业务数据进行水平拆分
  • 代理层进行分片路由 实施效果
  • 数据库写入性能线性扩展
  • 数据库容量线性扩展

流量突增 - 扩容

问题背景

  • 活动流基上涨
  • 集群性能不满足要求 解决方案
  • 扩容DB物理节点数星
  • 利用影子表进行压测 实施效果
  • 数据库集群提供更高的吞吐
  • 保证集群可以承担预期流量

image.png

流量突增 - 代理连接池

问题背录

  • 突增流量导致大量建联
  • 大量建联导致负载变大，延时上升 解决方案 -业务侧预热连接池
  • 代理侧预热连接池
  • 代理侧支持连接队列 实施效果
  • 避兔 DB被突增流量打死
  • 避免代理和DB被大量建联打死

image.png

稳定性&可靠性 - 3AZ高可用

image.png

稳定性&可靠性 - HA管理

问题背景

  • db所在机器异常宕机
  • db节点异常宕机 解决方案
  • ha服务监管、切换宕机节点
  • 代理支持配置热加载
  • 代理自动屏蔽宕机读节点 实施效果
  • 读节点宕机秒级恢复
  • 写节点宕机30s内恢复服务

image.png

avatar
文章
阅读
粉丝