用户工具

站点工具


simhash

在文章的实验中,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中检索出的结果

simhash.txt · 最后更改: 2020/02/01 21:41 (外部编辑)