2023-10-25 数据库-数据库体系架构的理解-将数据库理论融入自身-记录与分析

摘要:

对于数据库整体体系结构的理解，是随后逐个模块细化深入突破的前提.

如果不能建立全局的图景, 对各个模块之间的关系有深刻的理解，那么在对单个模块的分析突破中，就很容易迷失在里面.

更为重要的, 全局的理解，是建立自己的数据库整个体系知识结构的根基.

并且, 没有全局的视角, 各个组件和模块之间的关系的模糊，将无法将某个具体的模块的知识通过自身的知识结构回忆起来.

本文记录如何正确的理解总体架构设计, 需要说明本文所说的数据库特指关系型数据库, 例如mysql. 对于nosql或者newsql，例如redis, 由于使用的场景的不同，不在本文分析范围内.

不可直接去记忆数据库架构图和模块!

1. 这是最容易犯的错, 也是最常犯的错！因为这么做太直接了, 不会的东西，我直接去看, 死记硬背下来就行了
   1. 参考:2023-10-25 精神分析-领悟新技术的错误做法-持续数年的错误做法-记录与分析-CSDN博客​​​​​​
2. 那么说明了错误的做法，那么要如何做呢？最为根本的，是要符合大脑的思考问题的特性
3. 那么大脑是如何思考问题和分析问题的呢？
4. 是的，逐层推理演绎, 从一个点, 开始推进到后一个点, 然后逐步的推导下去
5. 所以这是一个层次的结构, 也就是一个树形结构
6. 那么对于数据库的整体架构, 最初的点是什么呢? 是要满足的需求！
   1. 是不是很震惊，是从需求出发！
   2. 就是因为太明确了，所以经常被忘掉这一点！
   3. 数据库的架构和设计, 是为了满足要达到的需求的！
   4. 那么数据库的需求是什么呢?

数据库产品的需求:

一. 使用ANSI SQL语言进行操纵

1. 这一点也是非常明显的，所以非常容易被忽略
2. 但是要明白, SQL是一门语言！
3. 那么SQL是一门语言意味着什么呢?
   1. 符合巴克斯范式的写法及符合SQL标准规范，都可以被允许, 从而导致海量的场景
   2. 存在词法解析和语法解析模块, 来对ANSI SQL处理成数据库内部的数据结构
4. SQL带来查询的复杂性
   1. 这点可以和redis的简单的command对比就一目了然
   2. 从而导致存在某些低效率的查询SQL，要被重写
   3. 这就意味着存在一个查询优化器来生成执行序列！
5. 查询优化器和查询执行器又带来了什么呢？
   1. 带来了所有数据库中最为庞大的模块！
   2. 可以说是数据库中最为复杂的模块
   3. 明白了吧？从知识的组织层次看
      1. 为什么非要有查询优化器和查询执行器？
      2. 将用户的SQL直接翻译成操作序列, 直接去执行不可以吗？
      3. 不做查询优化直接去执行用户的操作序列当然可以！但是在查询性能上竞争不过竞争对手，最终导致商业的失败

二. 要满足事务ACID的特性

1. ACID, 原子性, 一致性, 隔离性, 持久性
2. 是的, 这不是数据库的特性，而是对数据库的需求！要求数据库满足这样的目标! 
3. 就是为了要实现ACID的目标, 才出现了一系列的模块和设计
4. 为了实现原子性和一致性
   1. 要么都成功，要么都失败, 那么就需要回滚日志, 在出错后, 回滚到操作前的状态, 从而成为原子的
   2. 也就是所谓的undo log, 这个东西的出现是为了实现原子性的需求！不是因为八股文那么写就必须要死背这个东西
   3. 那么满嘴undo log, redo log, binlog, chek point，却闭口不谈要达到的需求目标和目的的，不是蠢，就是坏，而且八成就是坏, 故意误导人
5. 为了实现隔离性
   1. 这就要实现不同事务之间的隔离, 这就需要一个事务管理器来控制不同事务的可见性
   2. 从而就意味着必须对单个事务所需要的资源. 确保只有这个事务可以看到
   3. 并且要保证不同事务在运行时，不会修改对方的数据, 这就需要不同程度的锁来保护临界区
   4. 使用了锁, 那么就必然面临锁的一些问题. 例如死锁, 如何处理又是一个新的场景
   5. 对应的mysql中的X锁，S锁，间隙锁等等，都是为了对应不同的场景的隔离性, 那么忽略了需求和目的, 又是开始背八股文的沙雕, 简直就是十足的蠢货。那些一个劲的八股文的面试官也是十足的莼湖藕
6. 为了实现持久性
   1. 这就意味着数据必须保存到磁盘上
   2. 但是数据库对数据的操作都是内存上
   3. 这就导致必然需要一个磁盘间数据与内存的数据之间的管理系统，来应对数据在不同的存储层次上的处理
   4. 而事务的数据, 直接修改都是在内存中, 必须保证写入物理磁盘
   5. 这就导致事务在数据库服务突然发生异常的时候，下次数据库服务启动时，依然能恢复这个事务
   6. 在mysql中，这个机制就是redo log

从SQL和事务的需求角度去理解数据库架构设计:

1. 所有的架构和设计都必须有其目的, 否则就是失败的设计
2. 数据库的架构设计目标, 便是实现用户使用SQL操纵数据库, 以及满足事务的特性
3. 从这个角度去理解数据库整体的架构设计, 而不是去死记硬背
4. 目的, 目的，还是目的, 解决方案是为了目的设计的
5. 数据库这行已经有了太多的混子只会满嘴八股文, 做起事情只会照本宣科死板硬套, 对上忽悠，对下拿着教条当金科玉律，这种人就是十足的坏