# RDBMS介绍 ｜ 青训营笔记

小倪酱
59 阅读7分钟

这是我参与「第五届青训营 」伴学笔记创作活动的第2天

经典案例

数据库所需特性

  1. ACID特性

  • 原子性(Atomicity)：事务是一个不可再分割的工作单元，事务中的操作要么都发生，要么都不发生。

  • 一致性(Consistency)：数据库事务不能破坏关系数据的完整性以及业务逻辑上的一致性。

  • 隔离性(Isolation)：多个事务并发访问时，事务之间是隔离的，一个事务不应该影响其它事务运行效果。

  • 持久性(Durability)：在事务完成以后，该事务所对数据库所做的更改便持久的保存在数据库之中，并不会被回滚。

  1. 高并发特性

    数据库具备并发处理多个请求的特性

  2. 高可靠、高可用

发展历史

  • 前DBMS时代

    1. 人工管理时代

    2. 文件系统时代（数据管理通过文件系统实现）

  • DBMS（数据库管理系统）时代

    1. 网状模型
      • 用有向图表示实体和实体之间的联系的数据结构模型称为网状数据模型。(因为是有向图，每个节点可能存在多个父节点)
    2. 层次模型
      • 层次数据模型是用树状<层次>结构来组织数据的数据模型。(因为是树状结构，每个节点至多只有父节点)
    3. 关系模型

      • 使用表格表示实体和实体之间关系的数据模型称之为关系数据模型。(使用二维表描述)

    • 网状模型层次模型关系模型
      优势能直接描述现实世界 存取效率较高结构简单 查询效率高 可以提供较好的完整性支持实体及实体间的的联系都通过二维表结构表示 可以方便的表示M:N关系 数据访问路径对用户透明
      劣势结构复杂 用户不易使用 访问程序设计复杂无法表示M:N的关系 插入、删除限制多 遍历子节点必须经过父节点 访问程序设计复杂关联查询效率不够高关系必须规范化

关键技术

SQL语言

优点：

  • 语法风格接近自然语言

  • 高度非过程化

  • 面向集合的操作方式

  • 语言简介，易学易用

eg:update account_table set balance = balance - '小目标' where name = ‘抖音’

这句代码只是说明更新什么，无需说明怎么更新，是高度非过程化的。

在SQL执行过程中，需要经历SQL引擎、存储引擎、以及事务引擎等模块。而其中SQL引擎又分为Parser(语法解析器)、Optimizer(优化器)、Executor(执行器)几个部分：

下图来自学习资料

6632feb8206e4fa999b5be879d82f065tplv-k3u1fbpfcp-zoom-in-crop-mark4536000.webp

SQL引擎

  • Parser

    • 经过词法分析、语法分析生成语法树，然后对语法树进行合法性校验。

  • Optimizer

    • 根据Parser产生的语法树，根据规则或者代价产生执行计划树。

      为什么需要一个优化器？

      在多种可能中选择最好的办法，表连接的顺序，连接的方法等等

    • 基于规则优化

      • 条件简化
      • 表连接优化
      • Scan优化

    • 基于代价的优化

      • 代价可以是时间、IO等资源使用
      • 多种执行方案选择代价最小的方案

  • Executor

    • 火山模型
      • 每个operator调用next操作，访问下层operator，获得下层operator返回的一行数据，经过计算后将这行数据返回给上层
      • 优点：每个算子独立抽线实现，相互之间没有耦合。逻辑结构简单
      • 缺点：每计算一条数据有多次函数调用开销，导致CPU效率不高
    • 向量化模型
      • 每个operator操作计算的不再是一行数据，而是一批数据(Batch N行数据)，计算完成后向上层算子返回一个Batch，类似神经网络使用Batch size来分组训练数据
      • 优点：函数调用次数降低为1/N，CPU cache命中率更高，可以利用CPU提供的SIMD机制
    • 编译执行
      • 通过编译将所有操作封装到一个函数里面，函数调用代价大大降低
      • LLVM动态编译执行技术

存储引擎-InnoDB

image-20230213192016368.png

  • In-Memory
    • Buffer Pool：存储引擎位于内存中的重要结构，用于缓存数据，减少磁盘IO的开销。
    • log Buffer:日志缓存
  • On-Disk：
    • System Tablespace：存储表的元信息(列明，表名等等)
    • General Tablespaces ：表的具体数据
    • Undo Tablespaces: Undo日志
    • Temporary Tablespaces
    • Redo log：Redo 日志

  1. Buffer Pool

    管理所用的重要结构

    • HashMap：通过HashMap来寻找block

    • LRU：使用LRU替换规则来替换内存数据

  2. Page

    数据存储的最基本单位，一般为16KB。

  3. B+ Tree：InnoDB中最常用的索引结构(二分查找树的扩展)

事务引擎

事务引擎实现了数据库的ACID能力

  • Atomicity：InnoDB中通过undo日志实现了数据库的原子性，通过Undo Log，数据库可以回滚到事务开始的状态；

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

  • 一致性(Consistency)：一般由业务层实现

  • Isolation：通过Undo Log实现MVCC（多版本并发控制），降低读写冲突。

    MVCC的意义

    • 读写不阻塞
    • 降低死锁概率
    • 实现一致性读

  • Durability：通过Redo Log（一种WAL实现方式）来保证事务在提交后一定能持久化到磁盘中。

    • 方案一：事务提交前写页面：随机IO与写放大的缺陷

      方案二：WAL技术：redo log物理日志记录页面变化，保证事务持久化。如果数据写入前磁盘崩溃，重启后会根据redo log重新写入。

企业实践

抖音红包雨需要克服大流量、流量突增、高可靠等问题。

大流量——使用Sharding

Sharding：分库分表

背景：

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

解决方案：

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

实施效果：

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

流量突增

方案一：扩容

问题背景：

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

解决方案

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

实施效果

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

方案二：代理连接池

问题背景：

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

解决方案：

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

实施效果：

  • 避免DB被突增流量打死

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

稳定性&可靠性

  1. 3AZ高可用

    部署多个独立不相互影响的数据中心

  • 三机房部署

  • proxy

  • 监控警报

  1. HA管理

    问题背景：

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

    解决办法：

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

总结体会

通过学习，了解RDBMS的特点特性，与日常学习相互印证，通过最后的企业示例讲解，认识到理论知识如何应用到实践中去。

参考资料

青训营课程

青训营课程学习资料

avatar
文章
阅读
粉丝