SuRF: Practical Range Query Filtering with Fast Succinct Tries（2018 SIGMOD）

bloomfilter索引对于判断某个key是否存在是非常高效的，其能用极少的空间（与key长度无关），极低的出错概率判断key的存在性。

比如在RocksDB 里面，为了加速 key 查询的速度，使用了 Bloom filter，但 Bloom filter 只适用于 point query，

​ 现有的过滤器都仅仅支持point query，例如现在RocksDB里面有一张学生表，现在要做查询，找出年龄等于18岁的学术，我们可以通过在每一个SSTable（LSM Tree的分层结构）上加一个布隆过滤器减少磁盘IO，从而加速查找过程。但是现在查询请求变成了学生表中是否含有年龄段在22到25之间的学生，这个时候布隆过滤器就没有办法工作了。 

 本篇论文的核心是提出了一种基于succinct data structure的trie树，同时对该树进行合理的编码，从而降低占用内存的大小，同时保留查询能力，既支持point query，也支持range quey。 

1. 在图中， storing the full keys (‘SIGAI’, ‘SIGMOD’, ‘SIGOPS’) ，这是 一棵不做任何处理的 Trie 树

2. 从起始节点到最底层的叶子节点存储了一个完整的key，所以它是完全精确的，在集合中查找某个字符串的时候，不会出现关键字是否存在判别错误的情况。但是它有一个缺点就是占用的内存空间太大。

1. 为了让这棵 Trie 树变小，就要去截断一部分后缀，只会保存最短的前缀且这个前缀可以与集合中其他元素不同，这棵 Trie 树被称为 Surf-Base

2. Surf-Base 有个问题就是如果现在有一个字符串的前缀和树中存储的字符串前缀相同，但它又不在给定的字符串集合中，这时判别集合中是否有关键字的 FPR(False Positive Rate) 就会很高。

3. 比如通过上图右部的 SuRF -Base 去判别集合中SIGMETRIC是否存在，就会认为该字符串存在于该集合中，就会得到一种错误信息

1. 为了降低 FPR ，作者对原来的 SuRF -Base 结构做了改进，提出了 SuRF -Hash 、 SuRF -Real 以及 SuRF -Mixed 三种结构。

2. SuRF -Hash( SuRF with Hashed Key Suffixes) ：针对 SuRF -Base 有很高的 FPR ，在将集合中的关键字加入到 SuRF -Base 树的同时，也会对关键字进行 hash 计算，将得到的 hash 值的 n 个 bit 存储到最终的 value 中，当进行关键字的查找时，不仅要在 Trie 树上面查找，还要对比 hash 值。这种结构有利于 Point 查询， 且保存的 hash 值每多一位， 做 Point quey 的 FPR 就会减少一半。但是这个结构并不会对 Range query 有任何帮助，不能减少 range query 的 FPR 。

3.   SuRF-Real(SuRF with Real Key Suffixes)：SuRF-Real将存储的hash值的n个bit换成了真实key（即value中存放着key），例如上图的右部分表示添加了8bit的suffixes，这样虽然同时增强了Point query和Range query，但是关键字的区分度还是不高，在point查询下, 它的FPR比SuRF-Hash要高。

SuRF-Mixed(SuRF with Mixed Key Suffixes)：为了同时享受Hash和Real两种方式的优点, Mixed模式就是将两种方式混合使用，存储的value中有一部分是real key，另一部分是hashed key，混合的比例可以根据数据分布进行调节来获得最好的效果。如下图是一个案例： 

 

1. FAST SUCCINCT TRIES 是作者提出来的一种对 Trie 树进行编码的方式，可以减小该树在内存中空间，同时保留了查询的能力

2. 因为这种方式是基于 LOUDS(Level-Ordered Unary Degre