在文章的实验中，simhash采用64位的哈希函数。在80亿网页规模下汉明距离=3刚好合适。

因此任务的f-bit=64 , k=3 , n= 8*10^11

任务清晰，首先看一下两种很直观的方法：

1. 枚举出所有汉明距离小于3的simhash指纹，对每个指纹在80亿排序指纹中查询。（这种方法需要进行C（64，3）=41664词的simhash指纹，再为每个进行一次查询）

2. 所有接近的指纹排序到一起，这至多有41664排序可能，需要庞大的空间。提出的方法介于两者之间，合理的空间和时间的折中。

• 假设我们有一个已经排序的容量为2d，f-bit指纹集。看每个指纹的高d位。该高低位具有以下性质：尽管有很多的2d位组合存在，但高d位中有只有少量重复的。

• 现在找一个接近于d的数字d’，由于整个表是排好序的，所以一趟搜索就能找出高d’位与目标指纹F相同的指纹集合f’。因为d’和d很接近，所以找出的集合f’也不会很大。

• 最后在集合f’中查找 和F之间海明距离为k的指纹也就很快了。

• 总的思想：先要把检索的集合缩小，然后在小集合中检索f-d’位的海明距离

按照例子，80亿网页 有2^34 个，那么理论上34位就能表示完80亿不重复的指纹。我们假设最前的34位的表示完了80亿指纹，假设指纹在前30位是一样的，那么后面4位还可以表示24个， 只需要逐一比较这16个指纹是否于待测指纹汉明距离小于3。

如果库中有2^34 个（大概 10 亿）签名，那么匹配上每个块的结果最多有 2^(34-16)=262144 个候选结果 (假设数据是均匀分布， 16 位的数据，产生的像限为 2^16 个，则平均每个像限分布的文档数则 2^34/2^16 = 2^(34-16)) ，四个块返回的总结果数为 4* 262144 （大概 100 万）。原本需要比较 10 亿次，经过索引，大概就只需要处理 100 万次了。由此可见，确实大大减少了计算量。

假设：对任意34位中的30位都可以这么做。

因此在一次完整的查找中，限定前q位精确匹配（假设这些指纹已经是q位有序的，可以采用二分查找，如果指纹量非常大，且分布均匀，甚至可以采用内插搜索），之后的2d-q个指纹剩下64-q位需要比较汉明距离小于3。

于是问题就转变为如何切割64位的q。

将64位平分成若干份，例如4份ABCD，每份16位。

假设这些指纹已经按A部分排序好了，我们先按A的16位精确匹配到一个区间，这个区间的后BCD位检查汉明距离是否小于3。

同样的假设，其次我们按B的16位精确匹配到另一个区间，这个区间的所有指纹需要在ACD位上比较汉明距离是否小于3。

同理还有C和D

所以这里我们需要将全部的指纹T复制4份， T1 T2 T3 T4， T1按A排序，T2按B排序… 4份可以并行进行查询，最后把结果合并。这样即使最坏的情况：3个位分别落在其中3个区域ABC,ACD,BCD,ABD…都不会被漏掉。

只精确匹配16位，还需要逐一比较的指纹量依然庞大，可能达到2d-16个，我们也可以精确匹配更多的。

例如：将64位平分成4份ABCD，每份16位，在BCD的48位上，我们再分成4份，WXZY，每份12位， 汉明距离的3位可以散落在任意三块，那么A与WXZY任意一份合起来做精确的28位…剩下3份用来检查汉明距离。 同理B，C，D也可以这样，那么T需要复制16次，ABCD与WXYZ的组合做精确匹配，每次精确匹配后还需要逐一比较的个数降低到2d-28个。不同的组合方式也就是时间和空间上的权衡。

最坏情况是其中3份可能有1位汉明距离差异为1。

算法的描述如下：

1）先复制原表T为Tt份：T1,T2,….Tt

2）每个Ti都关联一个pi和一个πi，其中pi是一个整数, πi是一个置换函数，负责把pi个bit位换到高位上。

3）应用置换函数πi到相应的Ti表上，然后对Ti进行排序

4）然后对每一个Ti和要匹配的指纹F、海明距离k做如下运算：

a) 然后使用F’的高pi位检索，找出Ti中高pi位相同的集合

b) 在检索出的集合中比较f-pi位，找出海明距离小于等于k的指纹

5）最后合并所有Ti中检索出的结果