数据库-3.1 数据库架构

如何设计一个关系型数据库？
一个关系型数据库应该包括以下内容：

数据库最主要的功能是什么？就是存储数据，因此它会有一个存储模块，来负责存储我们的数据，存储模块就类似于我们的OS文件系统，将数据最终持久化存入磁盘中，如存入机械硬盘，或者SSD固态硬盘，抑或是它们的磁盘阵列矩阵中。
可是光有存储是不行的，我们还要组织并用到这些数据，因此咱们需要有程序的实例，用逻辑结构来映射物理结构来，并且在程序中提供获取以及管理数据的方式，还有必要的问题追踪机制。
接下来，咱们细分一下程序的模块。
首先我们需要对数据的格式以及文件的风格进行统一的管理，即把物理数据通过逻辑的形式给组织和表示出来，于是便涉及到了咱们程序的存储管理模块。
（ps:我们需要如何优化存储效能？咱们都知道，处理数据不可能在磁盘上做，而肯定是让程序加载到程序空间所在的内存里去做，而磁盘IO速率往往是程序执行速度的主要瓶颈，大家可以看到，咱们的机械硬盘，它通过马达的驱动，盘面的转动，以及磁头的移动来查找数据，这样的速度远差于内存的查找效率，即便是通过电流驱动的固态硬盘，虽然拥有比机械硬盘更快的IO速度，但是跟内存比起来也不是同一个量级的。因此为了执行效率，咱们要尽可能地减少IO，就这个存储管理功能而言，咱们如果按照逐行去查找并返回，这频繁的IO会使数据库的执行效率慢如蜗牛，因为一次IO读取多条数据和单条数据花费的时间并没有多大的区别，所以我们可以一次性地去读取多行，以提升IO的效能，所以行就失去了它的意义。那实际上数据库也是把逻辑存储单位用块或页来表示，每个块或页中存放多行数据，这样读取的时候，可以将多个块一起加载进内存当中）

作为一款很追求性能的软件，我们没有好好利用内存，因此呢，为了更快更好地优化我们的程序，我们应该想到做项目的时候的一种普遍做法便是引入缓存机制，把取出来的数据块存放在缓存里，下次需要的时候直接从内存返回而不用发生IO，这里需要补充的是，刚刚咱们说到的一次性加载多个块或者页，这些块里包含数据行，有相当的一部分并不是我们本次查询所需要的行，但是根据一旦某行数据被访问了，那么它周围的数据也极有可能被访问的经验，咱们缓存的非本次数据，也能起到优化访问效率的作用，比如，一次加载进来的这个块中，它有A，B，C三条数据，我们只需要A的数据，但B和C也会加载到内存当中，那按照经验来说，下次B和C被访问到的几率是非常大的，那也就是它也能提升我们的访问性能。关于如何管理缓存有很多的方法，也不能说哪个方法最好，某种方法适应于某个具体的场景。
我们还要能提供给外界的指令来操作我们的数据库，即可读的SQL语言，那么我们就需要一个SQL的解析模块，将SQL编译解析，转换成机器可识别的指令，那么这个时候为了进一步去提升SQL的执行效率，怎么办？老方法，还是将SQL缓存到我们的缓存中，那么编译好的SQL方便下次来了直接解析就可以了。
大家可以注意到，我们设计程序的时候，要先实现功能，接着再考虑优化，周而复始。这里还需要补充一点，我们的缓存不宜过大，且算法里得有淘汰机制，淘汰掉一些之后不常用的数据。此外，我们做的这个SQL操作，需要记录下来，方便我们做数据库的主从同步，或者灾难恢复，因此我们就需要有日志管理办法，去对我们的操作做记录。
我们还需要提供给用户管理数据的私密空间，即权限划分，通俗的讲，就是老板能看到员工的数据，而员工只能看到自己该看到的数据。权限划分是我们DBA做的事情。
设计系统的时候，除了考虑正常的功能，还要考虑异常的情况，那么这么处理异常的情况呢？我们就需要引入异常机制，即容灾，当我们的数据库挂了，该如何恢复，恢复到什么程度，这些都需要设计。
好了为了进一步提升查询数据的速度以及让数据库知识并发，咱们还需要引入最能够突出数据库特点的两个模块，即索引和锁模块。