MySQL-深入理解RDBMS | 青训营

已注销
98 阅读11分钟

这是我参与[第五届青训营]伴学笔记的第15天。

课程内容：

  1. 经典案例：喜闻乐见:从一场抖音红包雨说起~
  2. 发展历史：源远流长:RDBMS从1970年第一篇论文发布至今已有50余年，衍生出Oracle ,DB2,MySQL , SQL Sever ,urora等—系列知名数据库产品。
  3. 关键技术：万变归宗:无论RDBMS如何演变，其核心都是SQL引擎、存储引擎、事务引擎。
  4. 企业实践：繁花似锦:RDBMS广泛的应用于互联网、金融、电信、电力等领域。成为了各类企业级应用的数据基石。

1.1从一场红包雨说起

每一年的春节，抖音上都会下一场温暖人心的红包雨~

  • 从抖音的账户上扣除一个小目标
  • 给羊老师的账户加上一个小目标
  1. UPDATE account_table SET balance = balance - ‘小目标’ wHERE name =‘抖音';
  2. UPDATE account_table SET balance = balance + '小目标’ wHERE name =‘羊老师;

1.2RDBMS事务ACID

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

ACID

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

1.3红包雨与ACID

  1. Case 1:抖音的账户上扣了一个亿之后，假设服务器挂了，还没来得及给羊老师账户上加一个亿。
  • 抖音血亏，银行不赚。
  • 原子性：两个操作要么同时成功，要么同时失败，不存在中间状态。
  1. Case 2:假设抖音的账户上只有0.5个亿，但是扣减1个亿的操作成功了。
  • 银行血亏，并决定把抖音账户封了。
  • 一致性：每个操作都必须是合法的，账户信息应该从一个有效的状态变为另一个有效的状态。
  1. Case 3 :羊老师从抖音抢了一个亿红包，又从头条抢了一个亿，两个转账同时进行，假设他们都以为是从零开始更新羊老师的账户余额，羊老师最后得到一个亿。
  • 羊老师赚了，但没完全赚。
  • 隔离性：两个操作在对同一个账户并发进行操作时，应该是相互不影响，表现的像是串行操作。
  1. Case 4:抖音的账户上扣了一个亿，然后羊老师账户上加一个小目标，但都还没写到磁盘上。这个时候，如果服务器挂了。
  • 到手的一个亿没有了。
  • 持久性：操作更新成功之后，更新的结果应该永久性的保留下来，不会因为宕机等问题而丢失。

1.5红包雨与高并发

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

1.6红包雨与高可靠

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

02.发展历史

2.1前DBMS时代-人工管理

在现代计算机发明出来以前，通过人工的方式进行数据记录和管理: 结绳记事->清代钱庄账本->用于1890年人口普查的霍列瑞斯式的打孔机

2.2前DBMS时代-文件系统

1950s，现代计算机的雏形基本出现。1956年IBM发布了第一个的磁盘驱动器--Model 305 RAMAC，从此数据存储进入磁盘时代。在这个阶段，数据管理直接通过文件系统来实现。

2.3DBMS时代

  • 1960s，传统的文件系统已经不能满足人们的需要，数据库管理系统(DBMS )应运而生。
  • DBMS:按照某种数据模型来组织、存储和管理数据的仓库。
  • 所以通常按照数据模型的特点将传统数据库系统分成网状数据库、层次数据库和关系数据库三类。

2.3.1DBMS数据模型-网状模型

网状数据库所基于的网状数据模型建立的数据之间的联系，能反映现实世界中信息的关联，是许多空间对象的自然表达形式。

1964年，世界上第一个数据库系统——集成数据存储（Ilntegrated Data Storage , IDS )诞生于通用电气公司。IDS是世界上第一个网状数据库，奠定了数据库发展的基础，在当时得到了广泛的应用。在1970s网状数据库系统十分流行，在数据库系统产品中占据主导地位。

image.png

2.3.2DBMS数据模型-层次模型

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

677bff866f6358832989e23e5821759.png

2.3.3DBMS数据模型-关系模型

1970年，IBM的研究员E.FCodd博士发表了一篇名为"ARelational Model of Data for Large Shared Data Banks"的论文，提出了关系模型的概念，奠定了关系模型的理论基础。1979年Oracle首次将关系型数据库商业化，后续DB2, SAP Sysbase ASE, and Informix等知名数据库产品也纷纷面世。

image.png

2.4DBMS数据模型

image.png

2.5SQL语言

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

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

SQL语言：

  1. UPDATE account_table SET balance = balance - '小目标’ wHERE name =‘抖音';

过程化语言：

  1. Find account_table
  2. Search account_table and compare name to ‘抖音′
  3. Calculate balance - ‘小目标'
  4. write new balance back to account_table

2.6历史回顾

image.png

03.关键技术

3.1SQL一条SQL的一生

UPDATE account_table SET balance = balance - "小目标’ wHERE name =‘抖音';

image.png把SQL语言解析，语法解析器生成一个语法树，给到一个优化器，根据语法器，生成一个plan树，然后执行器执行，到文件进行执行，读取和写入文件，最后一步步返回。

  • SQL引擎：router\rdbms\parser\optimizer\executor
  • 事务引擎：没有显示的表现在图中
  • 存储引擎：data file，log file

3.2SQL引擎-Parser

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

3.2SQL引擎-optimizer

基于规则的优化RBO

  • 条件化简

  • 表连接优化

    • 总是小表先进行连接

  • Scan优化

    • 唯一索引
    • 普通索引
    • 全表扫描

数据库索引:是数据库管理系统中辅助数据结构，以协助快速查询、更新数据库表中数据。目前数据库中最常用的索引是通过B+树实现的。

基于代价的优化CBO

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

不仅考虑单个，也要考虑整体的时延。

3.2SQL引擎-executor

火山模型

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

  • 优点:

每个算子独立抽象实现，相互之间没有耦合，逻辑结构简单

  • 缺点:

每计算一条数据有多次函数调用开销，导致CPU效率不高。

向量化

image.png

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

优点:

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

编译执行

image.png

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

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

LLVM动态编译执行技术

3.3存储引擎-innoDB

  • In-Memory:

    • Buffer Pool
    • Change Buffer
    • Adaptive Hash Index
    • Log Buffer

  • On-Disk:

    • System Tablespace(ibdata1)
    • General Tablespaces(xoxx.ibd)
    • Undo Tablespaces(xoxx.ibu)
    • Temporary Tablespaces(xoxx.ibt)
    • Redo Log(ib_logfileN)

3.3存储引擎-buffer pool

image.png

  1. hashmap

image.png

  1. LRU

image.png

3.3存储引擎-page

image.pngHeader

  1. delete_mask:标识此条数据是否被删除。
  2. next _record:下一条数据的位置。
  3. record_type:表示当前记录的类型。

3.3存储引擎-B+ Tree

  • 页面内:

页目录中使用二分法快速定位到对应的槽，然后再遍历该槽对应分组中的记录即可快速找到指定的记录。

  • 从根到叶:

中间节点存储

image.png

3.4事务引擎-Atomicity与undo log

如何将数据库回退到修改之前的状态？

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

3.4事务引擎-isolation与锁

  1. 读读-share lock
  2. 写写-exclusive lock
  3. 读写share lock,exclusive lock

实现读写MVCC

  1. 读写互不阻塞;
  2. 降低死锁概率;
  3. 实现一致性读。

实现一致性durability与redo log

  1. 方案一：事务提交前页面写盘（随机IO、写放大）
  2. 方案二:WAL(Write-ahead logging)

redo log是物理日志，记录的是页面的变化，它的作用是保证事务持久化。如果数据写入磁盘前发生故障，重启MySQL后会根据redo log重做。

04.企业实践

4.1大流量-sharding

问题背景

  • 单节点写容易成为瓶颈
  • 单机数据容量上限

解决方案

  • 业务数据进行水平拆分
  • 代理层进行分片路由

实施效果

  • 数据库写入性能线性扩展
  • 数据库容量线性扩展

4.2流量突增-扩容

问题背景

  • 活动流量上涨
  • 集群性能不满足要求

解决方案

  • 扩容DB物理节点数量
  • 利用影子表进行压测

实施效果

  • 数据库集群提供更高的吞吐
  • 保证集群可以承担预期流量

4.4流量徒突增-代理连接池

问题背景

  • 突增流量导致大量建联
  • 大量建联导致负载变大，延时上升

解决方案

  • 业务侧预热连接池
  • 代理侧预热连接池
  • 代理侧支持连接队列

实施效果

  • 避免DB被突增流量打死
  • 避免代理和DB被大量建联打死

4.5稳定性&可靠性

3AZ高可用

image.png

三个不同城市建设三个机房，其中一个断电并不会影响其他两个。不同机房之间通过日志来同步。

  1. 三机房部署
  • 机房级别容灾
  • 机房级别流量调度
  1. proxy
  • 读写分离，分库分表
  • 限流，流量调度
  1. 监控报警
  • 实时监控集群运行状态
  • 提前上报集群风险

HA管理

问题背景

  • db所在机器异常宕机
  • db节点异常宕机

解决方案

  • ha服务监管、切换宕机
  • 节点代理支持配置热加载
  • 代理自动屏蔽宕机读节点

本次课程通过经典案例引出acid、大并发与高可靠等数据库的概念。然后讲解了数据库的关键技术，包括sql引擎、引擎存储以及事务引擎。介绍了前DBMS时代、3个数据模型以及发展时间线。后面介绍了数据库的实践，通过sharding实现大容量与大流量问题。容量扩增以及代理连接池来解决流量突增的问题，通过ha和3az来解决可靠性与稳定性的问题。

avatar
文章
阅读
粉丝