关系型数据库的学习笔记 | 青训营笔记

浮华512
90 阅读5分钟

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

一、关系型数据库的介绍

RDBMS（关系型数据库）是目前使用最为广泛的数据库之一，同时也是整个信息化时代的基石。

RDBMS 事务ACID

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

  • 原子性(Atomicity)∶事务是一个不可再分割的工作单元，事务中的操作要么都发生，要么都不发生。
  • 一致性(Consistency):数据库事务不能破坏关系数据的完整性以及业务逻辑上的合法性（例如你加一个e，我扣一个e，结果我余额成0了）。
  • 隔离性(Isolation):多个事务并发访问时，事务之间是隔离的，一个事务不应该影响其它事务运行效果。
  • 持久性(Durability):在事务完成以后，该事务所对数据库所作的更改便持久的保存在数据库之中，并不会被回滚。

还需要RDBMS需要具有高并发、高可靠的特性。

*层次模型类似于网状模型，只不过其要求只能有单个父节点

SQL语言

【特点】

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

SQL引擎

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

【2】为什么需要一个优化器？

在许多能得到结果的路径中，选择一个最优的处理路径。

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

    • 条件化简
    • 表连接优化(总是小表先进行连接)
    • Scan优化
      • 唯一索引
      • 普通索引
      • 全表扫描

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

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

    • 一个查询有多种执行方案，CBO会选择其中代价最低的方案去真正的执行。
    • 代价例如时间、IO、CPU、NET、MEM等

【3】执行器：

  • 火山模型（最常用）
    • 每个Operator调用Next操作，访问下层Operator，获得下层Operator返回的一行数据，经过计算之后，将这行数据返回给上层。
      • 优点：每个算子独立抽象实现，相互之间没有耦合，逻辑结构简单
      • 缺点：每计算一条数据有多次函数调用开销，导致CPU效率不高。
  • 向量化的模型，每次返回不是row，而是batch！
    • 每个Operator每次操作计算的不再是一行数据，而是一批数据(Batch N行数据)，计算完成后向上层算子返回一个Batch。
      • 优点︰函数调用次数降低为1/N，CPU cache命中率更高;可以利用CPU提供的SIMD(Single Instruction Multi Data)机制。
  • 编译执行的模型：
    • 将所有的操作封装到一个函数里面，函数调用的代价也能大幅度降低。（需要用到LLVM动态编译执行技术，否则每个组合都要编译一种，那可太麻烦了）

存储引擎--以InnoDB为例

【1】Buffer Pool

用LRU机制来管理内存里面的缓存数据，保存新数据，淘汰老数据。

【2】Page--在buffer pool中的基本的内存空间单位（16K）

【3】B+ Tree是索引，是B树的扩展。

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

事务引擎

【1】原子性涉及到一个回滚---以MySQL为例，Undo Log是逻辑日志，记录的是数据的增量变化（即回退所需的操作）。利用Undo Log可以进行事务回滚，从而保证事务的原子性。同时也实现了多版本并发控制( MVCC) ,解决读写冲突和一致性读的问题。

【2】一致性，一般是在业务上实现的（检测啥的）。

【3】隔离性涉及到锁---双读用共享锁、双写用互斥锁、一读一写用就需要用到MVCC

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

【4】持久性，是通过Redo Log实现的。

  • 事务提交前页面写盘——会造成随机IO引发的磁盘性能问题&写放大（本身写十几个字节，可我要修改整个page）
  • WAL(Write-ahead logging)，redo log是物理日志，记录的是页面的变化，它的作用是保证事务持久化。如果数据写入磁盘前发生故障，重启MySQL后会根据redo log重做。

二、企业实践

以“春节红包雨挑战”为例：

有三个问题点：流量大、流量突增、稳定性。

sharding

问题：

  • 单节点写容易成为瓶颈

  • 单机数据容量上限

解决方法：

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

实施效果：

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

流量突增——扩容

问题：

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

解决方法：

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

实施效果：

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

流量突增——代理连接池

问题背景

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

解决方案

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

实施效果

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

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

image.png

稳定性&可靠性一HA管理

问题背景

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

解决方案

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