论文阅读（４）：ｅｌａｓｔｉｃＢＦ

ｅｌａｓｔｉｃｂｆ：张月明　中国科技大学　ElasticBF: Fine-grained and Elastic Bloom Filter Towards Efficient Read for　LSM-tree-based KV Stores

 

针对的问题：ｌｓｍ的ｋｖ存储读放大问题很严重，尤其可能查了一遍，并不在ｌｓｍ里。现存的ｂｆ设计都很单一，很难适应动态调整，造成高误判率以及大量内存消耗。（这部分怎么验证下）

本文思路：提出弹性ｂｆ，每个ｓｓｔａｂｌｅ建立更多ｂｆ，并且根据访问频率按需加载进内存。实现了细粒度以及动态调整。

性能比较：与ｌｅｖｅｌｄｂ相比，读带宽１．９２ｘ－２．２４ｘ。并且与现存工作兼容，可以作为加速器很好的嵌入进去。

 

自己的想法：布隆过滤器不能删除和误判并没严重影响这两点，是否可以这样来看？内存中保留一个很大的ｂｆ，判断ｌｓｍ中是否有对应的ｋｅｙ，那么这个大小应该是９．６ｂ×ｋｅｙｃｏｕｎｔ（１０Ｍ）～！～１２ＭＢ，大小可以接受，但ｋｅｙｃｏｕｎｔ有待商榷，误判率１％。但问题在于，随着ｋｖ不断插入删除，内存中的ｂｆ都无法删除ｂｉｔｓｅｔ，导致最后ｂｆ基本不起到任何过滤的作用。我初步的设想，就随机删除，每个ｂｉｔ都有一定概率翻转为０，关键是要测试，这种实现能在多大程度上过滤不存在于ｌｓｍ的ｋｅｙ查询。而且可以加一层ｈａｓｈ？虽然不知道有什么用。

 

ｅｌａｓｔｉｃｂｆ主要设计：

对ｓｓｔａｂｌｅ根据访问频率划分冷热，热的ｓｓｔａｂｌｅ　ｆｉｌｔｅｒ每个ｋｅｙ分配更多ｂｉｔ，冷的则更少，从而同样的内存空间可以减少误判率。但如果ｆｉｌｔｅｒ已经被生成，那么ｂｉｔｓ－ｐｅｒ－ｋｅｙ不可动态改变。

为了达到这个目的，在构建每个ｓｓｔａｂｌｅ，建立多个ｆｉｌｔｅｒ用更小的ｂｉｔｓ－ｐｅｒ－ｋｅｙ，叫做ｆｉｌｔｅｒ单元。通过添加或减少ｆｉｌｔｅｒ　ｕｎｉｔ来动态调整ｓｓｔａｂｌｅ的ｆｉｌｔｅｒ的ｂｉｔｓ－ｐｅｒ－ｋｅｙ。

 

一个ｄａｔａｂｌｏｃｋ后面附加多个ｆｉｌｔｅｒｕｎｉｔ，每个ｆｉｌｔｅｒｕｎｉｔ都对ｄａｔａｂｌｏｃｋ中所有ｋｅｙ进行判断，而多个ｆｉｌｔｅｒｕｎｉｔ的叠加可以看做在ｂｉｔｓ－ｐｅｒ－ｋｅｙ的延长。每个ｆｉｌｔｅｒｕｎｉｔ都判断ｐｏｓｉｔｉｖｅ才会吧ｄａｔａｂｌｏｃｋ取出来找ｋｅｙ。

存在问题：怎么决定每个ｓｓｔａｂｌｅ对应的最合适的ｆｉｌｔｅｒｕｎｉｔ数量？

怎么实现动态结构，而开销不要太大？

 

动态调整的实现方式：

ＭＱ－ｍｕｌｔｉｑｕｅｕｅ。

多个ＬＲＵｑｕｅｕｅ来管理每个ｓｓｔａｂｌｅ的元信息。

ｑｉ代表有ｉ个ｆｉｌｔｅｒｕｎｉｔ的ｓｓｔａｂｌｅ的队列。有一个过期时间，每个ｓｓｔａｂｌｅ最后一次ｇｅｔ之后，长时间没有访问，那么会调整他所在队列到下一级，从而有更少的ｆｉｌｔｅｒ　ｕｎｉｔ的数量。直到我们找到足够的内存空间存放新增ｓｓｔａｂｌｅ的ｆｉｌｔｅｒ。