多次HASH算法解决冲突的效果测试

多次HASH算法解决冲突的效果测试

自己实现的共享内存的HSH算法解决冲突的方法是开链，最近在考虑做一个简化版本的数据存储时，需求的同事提出了希望能备份共享内存中的数据，当然这个有简单的方法，让使用者根据地址自己拷贝复制就可以了（当然如果你共享内存比较大，建议考虑64位的系统）。但是由于开链的算法天生弱点（开链的链表的处理不能分割），复制的事情只能让使用者解决，于是开始看公司另外一些同事的算法，多次HASH的解决冲突的算法。

多次HASH由于所有数据的存储完全是序列化的，没有链子，而且可以使用一个不可能出现的数据作标示某个位置没用使用，所以相对更加安全（没有特别不能打断的操作），所以可以外部进行拷贝，复制。当然要注意，这样的拷贝复制也不是完全安全的，因为如果多点操作，还是会出现只拷贝了半截数据的问题，但是由于中间没有链表，拷贝备份的数据即使有少量错误不会引起备份文件无法使用的问题。

当然多次HASH也有不足的地方，比如每次查询就必须进行固定N次HASH处理，而且在极端情况下，如果N次HASH后，得到的每个位置都被人占用了，那么存在不能插入的可能。但是和几个同事聊的过程中，他们告知我他们的实际应用中多次HASH的发生不可能插入的性非常低，而且发生这种情况是，空间的利用率往往都在80%以上了，而且他们最近一次监测的效果是，利用率达到90%。

打算自己用模板实现多次HASH的算法，但是在多次到底是几次这个问题上，我犹豫了，因为如果N设置过大，会影响处理速度，如果过小，负载能力应该会降低。由于我们的HASH算法本质还是通过质数取模的算法，我自己写一个小程序生成N组HASH数列，进行效果检查。

测试环境visual studio2010，虽然我是后台程序员，还是不喜欢直接用GCC干活。测试算法当然是写随机数插入看效果，一开始直接选择了VS 2010默认的rand函数看效果。结果发现居然非常糟糕，当测试容量加大到1000万时，第一次出现无法插入的利用率居然不到30%，先是挠头，然后逐步跟踪了一些效果，发现rand选择的数据范围明显偏窄，放弃他，最近在学习BOOST,换BOOST的mt19937随机数算法上，发现出现冲突是空间利用率明显上升。为了方便理解，将几次测试的结果列表出来。因为都进行过多次测试，发现数据比较接近，所以偷懒只列出其中一次的数据，一般测试中有1%的差距。

                                                                                                           表1 测试数据表格

 

10次HASH

15次HASH

16次HASH

20次HASH

希望保存的NODE的空间

1000万

1000万

1000万

1000万

实际空间NODE数量，（我代码内部会扩张一些）

1200576

1201775

1201572

1202042

出现无法放入时，已经放入的NODE的数量（多次测试数据比价接近）

808065

950252

973951

1011147

和实际空间比较负载率（多次测试数据比价接近）

67.3064%

79.0707%

81.0564%

84.1191%

和希望保存空间比较的负载率

80.8065%

95.0252%

97.3951%

101.115%

 

可以发现随着HASH次数的增多，负载能力可以逐步提高。当然这个也必须权衡利弊，毕竟如进行20次操作，对于平衡二叉树等算法，也已经可以检索100万的数据了。

 

考虑了半天，我将我默认算法的N次HASH的数值定为16,另外，其实O(16)次的查询次数也不算少，这个设计的优势还是在于比较大的数据量上的查询，最后还是提供了一个让用户自己设计自己质数队列的方法，避免一些特殊情况。

感谢icezhuang，mikewei，spraydong等同事。

【本文作者是fullsail(雁渡寒潭)，本着自由的精神，你可以在无盈利的情况完整转载此文档，转载时请附上BLOG链接:http://blog.csdn.net/fullsail，否则每字一元不讲价。对Baidu文库加价一倍】