CMU Database Systems - Indexes

这章主要描述索引，即通过什么样的数据结构可以更加快速的查询到数据

介绍Hash Tables，B+tree，SkipList

以及索引的并行访问

Hash Tables

hash tables可以实现O(1)的查询，设计主要考虑两点

首先用什么hash function？底下列出常用的hash function

然后怎么解决collisions？即hash schemes

首先是static hash schemes

第一个方法是Linear probe hashing

方法，如果发现冲突，就往后找，直到找到一个free的slot，所以要同时记录下key和value，这样才好去比对每个key是不是要找的

问题如图，会出现bad case，比如对于E，需要跳很多步才能找到，这样查询就从O(1)变成O(n)了

Robin Hood Hashing

像名字一样，罗宾汉，劫富济贫，解决badcase

首先存储到时候，要加上跳数，jump几次；然后根据jump数比较，来判断是否要做平均

左图，如果不用robin hood方式，D为1跳，E为3跳

右图，用robin hood后，D和E都变成2跳

Cuckoo Hashing

简单的说，用多个hash table，对于一个数据，哪边空就存哪边

但是对于当前这个C，两边都冲突，他解决的思路是，

C两边都冲突那肯定是解不了，那我先把C随便存一边，这样如图，我们就要解决B的冲突

B只能去替换A，最终A可以存在另一张表里面，所以冲突解决

这个方法明显的好处是查询路径短，最多两次

问题是，插入性能容易比较差，如果冲突比较多，有可能死循环，所以如果出现这些情况，就要去降低冲突率，比如增加hash table的大小，或者增加hashtable的个数

但这样变化后，需要完全重新rebuild

static hash schemes的问题就是，容量有限，一旦超出扩容的话，就需要整个索引完全rebuild

所以就需要Dynamic hash table

最直白的想法是Chained Hashing，hash值对应的是buckets，不存在collision，因为buckets是可以无限扩展的

问题是，数据多了，就变成O(n)了

上面的方法的问题是，随着数据的增多不断的增加bucket，但是没有没有增加目录大小，最终对应到目录中一条的数据越来越多，失去了index的意义

Extendible hashing

这个方法难理解些，

首先这里的hash函数是根据前几位去分bucket，depth的意思是几位

比如，用2位分bucket，目录大小为4，不够了就用3位去分bucket，目录大小就是8

Global depth是目录用几位，local depth其实只是个标识，表示这个bucket用的是几位，

因为只要有一个分区的bucket满了，并且如果这个分区只对应一个目录item，那么目录就需要扩展，global depth会增加

比如下图中，00指向bucketA，已经4个数满了，还要加一个，只有分离bucket，这个时候就需要扩展目录，global depth=3，其中000，001分别指向一个bucket

但是其他的bucket没满啊，所以他们的local depth还是2，并且在新的目录中，有两个item指向depth为2的bucket

但这时来个9，落在bucketB，B也满了，需要分裂，但是这个时候就不需要扩展目录，因为B本身就有两个目录item指向，正好可以分开

Linear Hashing

这个的思路也是逐步的分裂bucket，但他和extendible hashing相比，不需要维护这个目录

http://queper.in/drupal/blogs/dbsys/linear_hashing，这个链接里面的例子非常清楚

基本思想，

初始bucket数是4，按4取模分bucket，很容易理解
问题是，如果有某个bucket满了，怎么处理？

首先把overflow的数据用一个临时bucket存下来

然后接着要做bucket分裂，

这里bucket分裂的过程比较trick是逐步完成的，最终达到的是bucket翻倍

因为要一个个bucket分裂，所以这里有个split point，表示当前分裂到哪个bucket了

这里很难理解的是，他不是分裂overflow的那个bucket，而且按顺序一个个分裂；感觉一次把所有bucket全split掉，也没啥问题

如图，bucket 1 满了，但他是分裂当前split point指向的bucket 0，分成0和4，并且split point + 1

分裂的时候用的hash函数是下一轮的函数，如图的hash2

这里每overflow一次，就按顺序分裂一个bucket，当split point为4的时候，即分裂完一轮了，当前bucket=8

把split point重置成0，开始下一轮，每轮的bucket数翻倍，所以hash函数中的取余的数也要翻倍，很容易理解

这样就实现了动态扩展

Tree Indexes

https://www.cnblogs.com/fxjwind/archive/2012/06/09/2543357.html

我们说的B tree，往往说的都是B+ tree；B-tree和B+tree的区别就在于inner node是否存储数据

B+树有如下的特性，

m叉而非二叉，可以有效降低树高

每个inner node至少是half-full，这样提高读取效率，读取一个节点，往往是一个page，可以读取尽可能多的数据

inner node，对于k个keys，要有k+1个非null子节点

B+数据的结构如下，

分为inner nodes和leaf nodes

inner nodes只有索引，而leaf nodes包含真实数据，而且还有sibling pointers，这是为了更有效的range 查询

Leaf node的内容也分为两种

Leaf Node的结构如下，

两种kv不同的存储格式，这里pageId，需要理解一下，因为往往B+数的一个节点对应于一个page，所以跳到下一个节点，就是跳到另一个page

B+树的insert和delete，

Insert，关键就是node满了，需要分裂，分裂完要把middle key放到上一层节点中做索引，如果上一层节点也满了，就需要进一步分裂

delete，关键是如果delete后，节点小于half-full，需要先试图从sibling去借一些达到，half-full，如果sibling也达不到half-full，那么就merge

Clustered Indexes

http://baijiahao.baidu.com/s?id=1598257553176708891&wfr=spider&for=pc

clustered indexes是B+树的应用，

在Innodb里面，每个表都有一个聚簇索引，该索引是根据primary key对行记录生成的B+树索引，如果没有primary key，会生成自增id作为替代；

叶子节点存放的是行数据，称之为数据页，故表中的数据也是聚簇索引中的一部分，数据页之间通过一个双向链表来链接

除了Clustered Indexes以外，都称为Secondary Indexes，与聚簇索引的区别在于辅助索引的叶子节点中存放的是主键的键值

Clustered indexes只有一个，但是辅助索引却可以有多个

可想而知，通过辅助索引只能查到主键id，所以如果你要读到数据，还要再查一次聚簇索引；好处是因为辅助索引不包含数据，所以远小于聚簇索引，查询效率比较高

可以用一列，也可以用多列来创建辅助索引，称为联合索引，
联合索引和普通索引的结构没有不同，只是会在节点中同时记录下多个列的值，遵循最左原则，就是先按第一个列排序，再按第二个列排序。。。。。。

所以查询条件，也需要满足最左原则，否则无法使用索引

对于变长的keys和重复的keys

节点内的search方法，

其他B+树还有些优化，

索引覆盖，CoveringIndexes

查询需要的数据，都可以在索引中获取到，不需要读取原始tuple

SkipList，跳表

http://www.cnblogs.com/seniusen/p/9870398.html

如果用有序的数组来实现索引，可以简单的用二分查找，但是插入和删除数据会比较麻烦；

最简单的方法实现动态保序的index的方法是用有序链表，但链表的只支持线性搜索，时间复杂度为O(n)

如何让链表也能二分查找，提高查询效率，这就是skiplist

跳表的数据存在第一层，上面的都是索引，想法很简单，避免一个个遍历，越往上层建的索引越稀疏，总之就是为了模拟出二分查找，空间换时间，所以时间复杂度可以近似O(logn)

跳表比较有意思的是他的insert过程，

比如插入，k5v5，这里关键是如何建立索引？即要把K5加到哪几层里面

这里的答案是flip coin，就是一个伯努利过程

连续抛硬币，连续出现正面的次数为k，我们就会对前k层建立索引

如果k大于当前最大的level，就需要创建新的level

这有两个好处，

因为是伯努利过程，所以自然约高的level出现概率越低，以1/2降低

并且插入的数据越多，出现较大k的概率越大，因为较大的k是小概率事件

这个设计的还是非常精巧的，和loglogcounting类似的思路

跳表的查询就比较直观了，二分查找下来就ok

跳表的删除，也不难理解，关键是需要一个标识，先逻辑删除，再物理删除

图中就是刚完成逻辑删除，物理删除就是把这些节点真正删掉

跳表的优缺点

Radix Tree

核心的思路，前缀树，节点的path就代表key，可以reconstructed

树高，取决于key的length，而不是key的多少；其实key多了，表示key的length肯定要变长，一样的

不需要rebalance

Radix Tree的例子，看出和Trie的区别

Radix只有共享的才需要单独的节点

Radix的优点，就是插入和删除特别简单

Index Concurrency Control

讨论多线程并发访问索引
其中Logical correctness是指应用层的，transaction
而这里主要讨论的是Physical correctness，内部数据结构的并发访问

这里再解释在数据库领域，lock和latch的区别

既然讨论的是内部数据结构的并发控制，那用的就是latch

Latch分为两种类型，读和写

从表中可以看出来，我们要解决写写，和读写冲突，读读是没有冲突的

对于数据库中主要的索引结构，B+tree

解决冲突的方式称为，Latch Crabbing/Coupling

这个其实很容易理解，

读比较简单，从root开始，只要能获取到child的latch，就可以释放parent

更新复杂些，因为我更新当前节点，可能会导致split和merge，这样父节点也需要更新
所以要同时获取父子两层的latch，只有当不会发生split和merge，所以没有必要改动父节点，safe，才释放父节点的latch

Delete的例子，对于delete我们要考虑的是否要merge

所以在B的时候，我们不能释放A的Latch，因为B只有一个35，可能在delete的过程中需要merge
而到了C，C有38，44，删除一个也不会导致merge，所以可以释放A，B的latch

同样对于Insert，我们要考虑的是split
B的时候，有一个空，没有split的风险，释放A
但到D的时候，有split的风险，不能释放B，到I发现有空，不需要split，释放B，D

这个Case到F的时候，发现要split，所以不能释放C的latch，C也要增加节点

这个方法有个显著的问题，

Root会成为明显的瓶颈，以为所有锁都要从root开始锁起

优化的思路，

这有个假设，就是大部分更新是不需要，split和merge的，否则效率反而更低了

如果不需要split和merge，就没有必要给parent加写latch，用读latch就可以；用读latch，首先避免每次都在root写写冲突，因为读读是不冲突的，而且又保证了读写冲突，因为别人在更新的同时，你需要等待的

Leaf Node Scan

前面说的latch的方式都是Top-down的，所以不会产生死锁，大家加锁的方向一致的，不会形成环

但是B+tree在leaf node之间也是有pointer的，这就会形成环

读的场景，不冲突

写的场景，就会产生冲突

T2，冲突的时候，有两个选择，一个是等，一个是自杀(防止死锁)
因为T2不知道T1在干啥，所以合理的方式是，等一个timeout，然后自杀，这样可以有效避免死锁

Delayed parent updates

延迟对于parent的变更，这样会更有效

后续会有线程单独的来更新parent

对于parent的更新可以批量，并且降低写latch的冲突的概率