SuRF : Practical Range Query Filtering with Fast Succinct Tries

1. Introduction

　　在数据库管理系统中查找某些关键字会致使很大的磁盘I/O开销，针对这一问题，一般会使用一个内存开销小而且常驻内存的过滤器来检测该关键字是否存。好比如今经常使用的bloom过滤器对判断某个key是否存在是很是高效的，其能用极少的空间（与key长度无关），极低的出错几率判断key的存在性。

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

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

2. SUCCINCT RANGE FILTERS

　　为了在集合中查找字符串，首先想到的是Trie，一棵不作任何处理的Trie树以下图所示

　　从起始节点到最底层的叶子节点存储了一个完整的key，因此它是彻底精确的，在集合中查找某个字符串的时候，不会出现关键字是否存在判别错误的状况。可是它有一个缺点就是占用的内存空间太大。为了让这棵Trie树变小，就要去截断一部分后缀，只会保存最短的前缀且这个前缀能够与集合中其余元素不一样，这棵Trie树被称为Surf-Base，如图所示

　　可是Surf-Base有个问题就是若是如今有一个字符串的前缀和树中存储的字符串前缀相同，但它又不在给定的字符串集合中，这时判别集合中是否有关键字的FPR(False Positive Rate)就会很高，好比经过上图右部的SuRF-Base去判别集合中SIGMETRIC是否存在，就会认为该字符串存在于该集合中，就会获得一种错误信息。为了下降FPR，做者对原来的SuRF-Base结构作了改进，提出了SuRF-Hash、SuRF-Real以及SuRF-Mixed三种结构。

• 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。

• SuRF-Real(SuRF with Real Key Suffixes)：和SuRF with Hashed 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，混合的比例能够根据数据分布进行调节来得到最好的效果。以下图是一个案例：

3. FAST SUCCINCT TRIES

LOUDS编码

　　FAST SUCCINCT TRIES是做者提出来的一种对Trie树进行编码的方式，能够减少该树在内存中空间，同时保留了查询的能力。由于这种方式是基于LOUDS(Level-Ordered Unary Degree Sequence)提出来的，因此须要先了解LOUDS的编码规则：

• 从根节点开始，按广度优先的方式去遍历这棵树。

• 扫描到一个节点时，该节点有n个孩子，则用n个1和一个0对这个节点进行编码。

　　举例以下图所示：从根节点开始依次层序遍历这棵树，遇到一个节点，该节点有几个孩子，就用几个1再加上一个结束标志0对该节点编码，例如，对于节点3，它有3个孩子，就用“1110”对该节点编码。

　　对这棵树编码完成后获得的是一组01字符串，如今要根据这个字符串来访问树中的节点，能够总结成两个经典的操做：

• 经过父亲节点找孩子节点

• 经过孩子节点找父亲节点

　　为了可以实现上述两个操做从而实现访问树中的任意节点，根据该树的编码特色以及字符串的形式，定义了四个操做：

• rank1(i) : 返回在 [0, i] 位置区间内 1 的个数

• rank0(i) : 返回在 [0, i] 位置区间内 0 的个数

• select1(i) : 返回第i个1的位置(整个bit序列)

• select0(i) : 返回第i个0的位置(整个bit序列)

　　上面的操做能够经过下面的表格来具体详细解释，其中value行的比特序列是上面那张图中的编码序列：

　　如今基于下面三个公式来访问整个树：

• 求层序遍历的第i个节点在比特序列中的位置

  position(i-th node) = select0(i) +1 //由于节点间编码以0间隔开，因此当前序列位置前面有多少0，就表示有多少节点，第i个节点的位置，前面有i个节点（节点序号从0开始），及定位到第i个0，就能够定位到第i-1个节点编码序列最后一个比特在比特序列的位置，加1后就表示第i个节点的起始位置了。便可知，对任何一个位置来讲，开始位置到该点之间的bit 0出现的个数表示该点前面有多少个节点。

• 求在比特序列中起始位置为p的节点的孩子位置

  first-child(i) = select0(rank1(p)) + 1 //由于每个节点都会经过1的个数去标记其直接孩子的个数，根据这个特性，对任何一个位置，开始位置到该点之间的bit 1出现的个数表示该点前面的节点加上其直接孩子的节点数目。

• 求在比特序列中起始位置为p的节点的父亲位置

  parent(i) = select1(rank0(p)) //这个关系能够根据父亲求孩子来倒推。先求出该节点前面有多少节点，而后根据“对任何一个位置，开始位置到该点之间的bit 1出现的个数表示该点前面的节点加上其直接孩子的节点数目”。倒推父亲节点。

　　举例以下：

　　求第4个节点在编码序列中的位置：select0(4)+1 = 11 + 1 =12

　　求在比特序列中起始位置为12的孩子位置：select0(rank1(12)) = select0(9)+1 = 22

　　求在比特序列中起始位置为22的节点的父亲位置：select1(rank0(22)) = select1(9) = 12

FST编码

　　基于LOUDS编码方式, FST( FAST SUCCINCT TRIES)对LOUDS进行了进一步压缩, 下图介绍了基本的压缩方法:

 　FST将LOUDS分红了两层, 上层节点数量少，数据访问频繁, 使用LOUDS-Dense编码方式, 下层节点数多, 数据访问次数少，使用LOUDS-Sparse编码方式.

LOUDS-Dense和LOUDS-Sparse

1. LOUDS-Dense

　　每一个节点最多有256个子节点, 那么在LOUDS-Dense编码方式中, 每一个节点使用3个256个bit的bit map和一个bit序列来保存信息. 它们分别是:

• D-Labels : 为节点中的每个值作一个分支标记。例如根节点有以 f，s 和 t做为前缀的三个分支，那么会将这个大小为256的bit map的第 102（f），115（s） 和 116 （t）bit 位就会设置为 1。能够看到，具体哪个bit 位，就是 ASCII 码的值。

• D-HasChild : 标记对应的子节点是不是叶子节点仍是中间节点。以根节点的三个分支为例，f 和 t 都有子节点，而 s 没有，因此 102 和 116 bit 都会设置为 1。

• D-IsPrefixKey : 标记当前前缀是不是有效的key。

• D-Values : 存储的是固定大小的 value，在本文中，表示的是指向以前说过三种后缀（hashed, Real, Mixed）的指针。

如今仍然可使用select&rank操做来访问Trie树中LOUDS-Dense对应的节点：

• 求孩子节点：假设某一结点的label分支有节点，即对应的D-HasChild[pos] = 1，则对应的分支的孩子节点的位置是 D-ChildNodePos(pos)=256×rank1(D-HasChild,pos)

  举例：求根节点的中D-Label为t的孩子节点（D-HasChild(pos)=1）分支，Position(t) = 116，则：

  D-ChildNodePos(256)=256×rank1(D-HasChild,pos) = 256 * 2= 512 //第三个节点的起始位置为512。

  注：operator(seq,pos) 表示在序列seq上作operator操做，上式就是在D-HasChild中作rank1(pos)操做

• 求父亲节点：假设求pos=623(第三个节)的父亲位置：

  D-ParentNodePos(pos) = select1(D-HasChild, ⌊pos/256⌋)

  带入公式得D-ParentNodePos(pos) = select1(D-HasChild,⌊623/256⌋) = select1(D-HasChild, 2) = 116

2. LOUDS-Sparse

　　使用3个bit序列来对trie树进行编码, 在整个bit序列中, 每一个节点的长度相同, 这三个bit序列分别是:

• S-Labels(bit-sequences) : 直接存储节点中的值，按照 level order 的方式记录了全部 node 的 label，用0xFF($)标记该前缀也是key节点（做用至关于LOUDS-Dense中的D-IsPrefixKey ）。

• S-HasChild(one bit) : 记录每一个节点中的label是否含有分支子节点, 有的话标记为1, 每一个label使用一个bit。

• S-LOUDS(one bit) : 记录每一个label是不是该节点的第一个label。譬如上图第三层，r，p 和 i 都是本节点的第一个label，那么对应的 S-LOUDS 就设置为 1 了。

• S-Values : 存储的是固定大小的 value，在本文中，表示的是指向以前说过三种后缀（hashed, Real, Mixed）的指针。

使用select&rank操做来访问Trie树中LOUDS-Sparse对应的节点：

• 求孩子节点：假设某一结点的label分支有节点，即对应的S-HasChild[pos] = 1，则对应label分支的孩子节点的位置是:S-ChildNodePos(pos) = select1(S-LOUDS,rank1(S-HasChild,pos) + 1)

  例如，S-HasChild[5]=1，rank1(S-HasChild, pos) = 2 + 5 =7（这里要加上LOUDS-Dense上的D-HasChild），select1(S-LOUDS, 7 + 1) = 9（S-LOUDS主要表明节点的label边界，须要减去LOUDS-Dense上的3个节点，实际上求的是select1(S-LOUDS, 8-3)）

• 求父亲节点：假设求pos=623(第三个节)的父亲位置：

  S-ParentNodePos(pos) = select1(S-HasChild, rank1(S-LOUDS, pos) -1);

  例如，如今求pos = 9的父节点，rank1(S-LOUDS, pos) = 8（ rank1(S-LOUDS, pos) = 5 可是加上LOUDS-Dense上的3个节点）select1(S-HasChild, 7) = 6 （S-HasChild还包括了LOUDS-Dense上的D-HasChild）

性能分析

　　假设这棵Trie树有H层，LOUDS-Dense-Size(l) 表示从0到l（不包含l）层采用LOUDS-Dense编码，而LOUDS-Sparse-Size(l) 表示从l到H层采用LOUDS-Sparse方式编码，这棵树按多少比例采用两种方式去编码：

　　LOUDS-Dense-Size(l) × R ≤ LOUDS-Sparse-Size(l) //一般R默认值是64

　　因而，LOUDS-Sparse方式的编码大小会决定这棵Trie树的实际编码空间大小。如今给定n个个关键字的集合，S-labes须要使用8n个bits, S-HasChild和S-LOUDS一共使用2n个bits, 因此LOUDS-Sparse使用10n个bits。而Dense占用的空间要远远小于Sparse部分，因此整个LOUDS-DS编码的Trie树接近10n个bits。

4. 性能测试

　　论文中使用了两组key的数据进行性能对比测试。 一组是由YCSB输出的64bit的整数， 另外一组是由字符串组成的电子邮件地址,，其中整数的key有50M个，电子邮件地址组成的key有25M个。相关细节以下：

1. FPR对比

　　首先对比了SuRF不一样模式和布隆过滤器在FPR上的对比：

　　通常状况，在point query下，SuRF比bloom filter仍是要差一些。从该图的中间部分能够看出，随着SuRF-Hash的hash后缀的bit位数的增长，它对range query起不到任何做用。该图的右侧的Mixed query说明，随着后缀的长度的增长，SuRF-Real对Point和Range query均可以加强做用，因此它降低的最快，而 SuRF-Hash只对Point query起做用，因此它的后缀增长到必定后，只是将Point query的FPR下降了，可是Range query的FPR不会变化，而在整数和Email的实验中SuRF-Real和SuRF-Mixed的变化趋势不一样，是由于在整数中后缀添加一个bit，这个 值变化很大，区分度高，可是相对于字符串，特别是邮箱，后缀添加一个bit，即使是一个字节，区分度可能不高(好比ttttttx@cs.cmu.ed和tttttts@cs.cmu.ed)

2. 性能对比

　　SuRF的不一样模式和bloom filter的吞吐对比，吞吐实际上指的是查询速度。

　　能够看出不管是Point，Range，仍是Mixed Query下，SuRF的三种模式吞吐量差异不大，并且在作Point Query时，布隆过滤器的吞吐量仍是相对高的。

应用场景测试

　　做者对RocksDB的过滤器作了些改动，提出了四种场景的RocksDB的测试案例

　　　　　　(1)no filter

　　　　　　(2)Bloom filter (14 bits per key)

　　　　　　(3)SuRF-Hash (4 bit suffix per key)

　　　　　　(4)SuRF-Real (4 bit suffix per key)

　　实验的数据集是100G，查询的key是随机产生的。做者首先作的是性能对比

　　上图左侧表示的是Point query的性能对比，能够看出添加布隆过滤器后，查询时涉及的磁盘IO最少，它的吞吐量最大；图中右侧表示Range query的性能对比，此时SuRF的两种变体就有一些性能上的提高。

　　接下来做者为了更大程度的显示SuRF的优点，因而作一组关于在range query时，故意设置一些查询语句返回为空时的性能对比试验。并逐渐增长这些查询语句在全部查询语句的比例。

　　从图中能够看出随着查询中查询结果为空的比例不断增多，SuRF的性能就会不断的提高，而带布隆过滤器的SuRF的性能始终没有任何变化。

总结

• 文中的SuRF是一种即支持Point query又支持Range query的过滤器结构

• 若是具体应用中针对Point query的FPR的要求很高，布隆过滤器则比SuRF更好。可是若是查询中出现empty result的状况不少的话，且关注性能的提高时，可使用SuRF结构。

• 能够调节SuRF-Mixed中后缀部分hashed key和Real key的各自的长度，通常都是从SuRF-Real这种模式开始作调整，由于这种模式能够对Point query和Range query都很好，而后慢慢的逐步将Real 换成Hashed Suffixes。

• SuRF是常驻内存的，并且很高效，它的FPR能够经过调整后缀的长度来下降FPR。

 

制做的PPT在github上：地址

参考文献：

HuanchenZhang. 2018. Sigmod. SuRF : Practical Range Query Filtering with Fast Succinct Tries

Guy Jacobson. 1989. Space-efficient static trees and graphs. In Foundations of Computer Science.IEEE,549–554.

SuRF Demo