文章探讨了HBase为何在稀疏索引之外使用布隆过滤器来提高数据查找效率。布隆过滤器通过计算哈希函数，能在查询时预先判断记录是否存在，避免不必要的数据块读取，从而减少磁盘IO操作。然而，这种结构对于数据变更的维护成本高，不适合频繁更新的情况。相比之下，MySQL等系统未采用布隆过滤器可能是因为这个原因。
背景
在我们以往接触到的索引中，比如mysql二级索引，每条索引记录都只是存放对应字段值和执行这些值的数据记录的指针，然后按照字段值从小到大排序，这样通过B+索引的索引结构就可以快速搜索到指定字段值的数据块，这种结构在我们看来搜索数据已经足够快了。那么为什么hbase除了使用key的稀疏索引结构外，还要结合上布隆过滤器来过滤数据记录呢？
hbase的索引结构
首先hbase的索引记录是由三部分组成的，一个是key，另一个是执行这个key所在的记录的数据块，第三部分key所指向的数据块的所有key组成的布隆过滤器字节数组，参见下图所示：
其实我们这里最想知道的是在稀疏索引记录中使用布隆过滤器的作用是什么？
首先我们假设索引记录中没有布隆过滤器的情况，此时比如查找key11所在的数据记录。那么我们通过稀疏索引首先定位到索引记录[key1,指针]这条索引记录，然后读取这条索引记录所指向的数据块中的数据记录，查找数据块中数据记录的key等于key11·的记录，直到遍历完这个数据块，我们才发现其实并没有key11的数据记录存在，不过重点是这里需要有一次IO操作把整个数据块读到内存中然后二分/遍历查找。
那么如果索引记录中包含了布隆过滤器的情况呢？还是比如查找key11所在的数据记录。那么我们通过稀疏索引首先定位到索引记录[key1,指针，布隆过滤器字节数组]这条索引记录，通过计算key11的N个hash函数，然后通过判断hash(key11)在布隆过滤器数组中位的情况就可以知道key11是否在索引记录指针指向的数据块中了，在这个例子中，可以判断key11不在对应的数据块中，所以这里就减少了一次读取数据块的磁盘IO操作.
总结
稀疏索引结合布隆过滤器的索引存储结构可以提前判断出来记录是否存在，而不需要真正的读取对应的数据块进行二分/遍历查找才能判断，而且索引的层次越高，能过滤的数据块也就也多，节省的IO次数也越多，不过这种结构适合于数据记录极少或者不会发生变更的情况，类似hbase，因为如果记录有比如删除或者中间插入导致数据块分解等操作，要维护对应的布隆过滤器的变更，这代价很大，所以这也是mysql等其他索引没有引入布隆过滤器的原因吧.
78
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
