sparse index是一篇老论文，出现在FAST’09。当时，数据去重的主流研究方向是索引设计，一个好的索引必须有高吞吐率，低内存，高重删率等特点。我希望destor能支持所有的主流索引，因此近期实现了sparse index，并对索引模块的接口做了比较大的改动。

• sparse index首先使用传统的分块算法将数据流分块，为数据块计算哈希；
• 根据哈希值选取segment边界（比如数据块的哈希取摸后等于某个预定义的值，就认为这个块是segment的边界，这里segment相当于超级块），到此数据流被分割为变长的segment；
• 针对每个segment，为其抽样一定数量的hook（抽样的方法是：若一个数据块的哈希前n个bit为0，就认为该哈希是segment的一个hook），这样每个segment会产生一个hook集合；
• 作者认为两个segment的hook交集越多，意味着它们有更好的重删潜力，因此作者设计了sparse index：sparse index是一个内存索引，是一个键值映射，键是hook，值是拥有这个hook的所有segment的地址。
• 根据当前segment的hook集合，搜索sparse index，得到与当前segment共享hook的所有segment的地址，对这些segment进行排序（文中并不是简单排序，however，太细节），只保留交集最大的前M个segment，称为champions集合。
• 读取champions对应的指纹，与当前segment进行去重。

sparse index依赖数据流的局部性。destor的实现与原作有一些细微的修改：

1. 选取segment边界，destor是根据哈希值得前N个bits是否为0选取边界的，当然N要比取样使用的n要大一些来保证每个segment的hook数量，这种方式的好处是能保证每个segment的第一个数据块一定是hook；
   
2. sparse index的抽样方法，在实践中是的确会产生一些segment无法取样到hook。destor很好避免了这点，但是数据流的第一个segment仍然可能出现取样失败。若出现这种情况，destor会将该segment与第二个segment合并。
   
3. 在极端特殊的情况下，整个数据流只有一个segment，并且取样失败，destor选第一个块为hook。

下面是一些实验结果，champions的数量以及取样率对重删率的影响。理论上，选取的champions越多（重删的范围越大），重删率越高，吞吐率越差；取样率越高（选择的champions越准确），重删率越高，（Sparse Index）内存消耗越多。





上面两幅图是变化champions数量的实验结果（mean segment size是20MB，mean chunk size是10KB，抽样率是1/256），baseline指完美重删，数据集是虚拟机镜像。当只选取一个champion时，重删率下降了47.6%；当选择16个champions时，重删率下降了10.7%，由于此时读16个manifests，性能应该会受到影响。





上面两图是针对抽样率的实验结果（默认的champions数量是8）。实验证明越高的抽样率，重删率越高。当抽样率为1/64时，抽样率只下降了4.8%；而当抽样率为1/1024时，重删率下降了35.6%。 值得注意的是：连续备份同一个数据流，后面的备份虽然全部是重复数据，但sparse index是有可能无法完全找出重复数据的。 优质内容筛选与推荐>>
1、vue + typescript 项目起手式
2、网站优化—mysql explain执行计划
3、关于学习英语口语我的一点点理解和建议
4、flex builder与flash协同开发
5、hdu 2255 带权最大匹配 km算法