高级数据库典型技术

数据库作为计算机学科中一个比较重要的分支，也是一个对于程序员来说非常好的学习方向。平时我们用的最多的，同时也是接触最多的一定是增删改查语句，select, update,delete等，当然，我不会拿这些再说一遍，这些都是老的掉渣的东西了。所以我们可以学习高级

数据库作为计算机学科中一个比较重要的分支，也是一个对于程序员来说非常好的学习方向。平时我们用的最多的，同时也是接触最多的一定是增删改查语句，select,

update,delete等，当然，我不会拿这些再说一遍，这些都是老的掉渣的东西了。所以我们可以学习高级数据库中所以涉及的技术。换句话，其实就是抛开业务层的逻辑，从更加深层次的角度理解数据库。今天我主要提交3个技术点，

1.数据索引技术，典型的B+树索引系列

2.数据库故障恢复技术，我这里只提的是基于日志的恢复技术

3.数据库系统结构，讲讲时下流行的分布式数据库系统

数据库索引技术关系着数据的查询速度，当数据量比较小的时候，响应是没有问题，当数据库中拥有百万，千万级数据量的数据时，建立索引是必须的。传统的数据查询操作时在海量数据中一条条的查询，在磁盘块中逐个寻找效率当然不高，如果是连续存储的还算运气好，如果是物理上不连续的，那结果可想而知。所以在这里我们引入了一个名叫“index”索引概念的东西，他不保存真实的数据，索引其实是一个指向真实数据记录的地址指针，要查询的数据的时候，先找到此索引值，然后根据此索引值，找到真实记录地址，因为不保存真实数据，索引查询的速度比较快。首先我们说说顺序索引，顺序索引的定义是当数据文件的存储顺序是按某个索引键值的顺序排列时，称该文件为顺序文件，为顺序文件建立索引的时候，一般此索引的建立以某个索引键一致，比如说某ID建立的索引为顺序索引，顺序文件的索引可以采用二分查找方法能够很快定位到相应的索引记录。B+树索引是以平衡树的结构构建的索引，B+树凭借其特殊的结构设计，一直保持着一种比较高的查询效率，在我之前的文章中也都提到过了。最后说的是散列索引，散列索引是利用哈希函数将搜索键值，分别映射到M个记录搜索键值存储地址的桶中，这样可以利用哈希算法直接检索，我们都知道哈希算法，的速度是相当快的哦，但是同时此时的一个好的哈希算法就显得至关重要了，最好能将索引记录均匀地分布到各个桶中。

基于日志的恢复技术也是数据库容灾处理的一部分，这里的日志主要有3个，undo，redo，undo/redo三种。undo，从这个英文中我们也可大概知道他的意思是不要做，就是撤销操作的意思了,一般我们在操作未完全完成的情况下才会执行撤销动作，这样可以避免脏数据的诞生。undo的日志就是为了防止出现这个情况的。undo的日志记录结构为：

其中:T是更新数据的事务，X是T更新的数据元素，V是更新前的旧值，数据出错了就是拿这个值更新回去的，一个完整的undo日志记录如下:

//开启事务

//对数据A 进行了数据更改，把他的旧值记录下来

//对数据B进行了数据操作，把B的旧值也记录下来

//事务执行成功，也记录

如果在commit 操作之前系统故障了，也就是没有写入记录中，也不知道数据操作到底对不对，日志统一从后往前逆序读取，首先遇到 ,将B更新到旧值10，然后又遇到 ，将A还原回到10，直到遇到 ,说明事物恢复成功，又回到了事物的出发点日志恢复结束。undo日志的事务执行顺序为：

(1).写更新数据量元素的日志

(2).再写更新的数据元素

(3).最后写COMMIT，表明事务已经成功提交

但是在这里其实会暴露一个潜在的问题，此要求事务必须将所做的修改写到磁盘后才能提交事务，这无疑增加了I/O开销，实际上，我们可以将数据的修改操作暂缓写到磁盘上，等到缓冲区满时再写入磁盘，就可以节省很多I/O操作了，于是就有了redo日志的出现，redo日志的格式与undo日志略有区别：

(1).写更新数据量元素的日志

(2).再写COMMIT，表明事务已经成功提交

(3).最后写更新的数据元素

所以如果在2,3步骤直接出错，系统也当时值已经更新成功了，会重做操作的，这里的V保存的就是新的值，用于重做操作时使用的，说明A,B的值可能延迟更长的时间才能写到磁盘中，如果这段时间系统出异常了，就redo操作，还有一种是undo/redo,模式相结合的，灵活性最强。所有的日志记录都要检查点的一个机制，检查点之前的记录都可以忽略不计了，每次都从新的检查点开始，检查点的2个标记为：

每次寻找到END CKPT，可以将上一个前的的日志丢弃。

最后来看看近年来随着分布式系统的出现，也出现了分布式数据库的概念，分布式数据库数据库系统可以看做一系列的集中式数据库的联合，在逻辑上属于同一系统，物理上是分布式，不连续的。他们之间的唯一联系就是----网络。一个数据库的查询可以涉及多地的分布式数据查询，与之相应的还有分布式事务管理，这个比分布式查询更为复杂，网络因素将成为影响分布式查询时间的最大的影响因素，在传统的本地数据库中，计算机的CPU处理速度会是影响查询速度的最主要因素，与现在的分布式数据库是截然不同的，所以分布式数据库的设计能设置成本地访问的就不要搞成分布式的查询，一般90%的查询可以用在本地查询，真到了那10%就通过分布式查询的方式，而且分布式的查询，也应该选择离自己最近的一个分布式数据库中。分布式数据的设计方法有自底向上和自顶向下2种，这个我就不展开了，比较复杂。