2015-02-08 197 views
1

我需要存储15GB或记录,记录有一个固定的大小等于270个字节,我想有能力通过键找到记录。密钥是记录中几个字段的散列,多个记录可以具有相同的密钥。 我试图使用gdbm,但它的速度很慢,现在我正在尝试制作自己的解决方案。 我有两个主要想法。 1-direct寻址。我创建了一个空记录的大文件。根据这个概率,新记录的索引(new_key%(文件中的全部记录))是空记录的索引至少等于1/2,如果记录与此索引已经忙于下一个索引= hash(key)%文件中的总记录以及迄今为止。 这种方法给了我很好的查找操作速度。平均而言,我需要1.65次读取记录操作才能找到合适的。 但由于大量的随机访问操作,初始填充该文件的速度非常慢。它可能需要4个小时。 2 - 二分查找。只是执行并行合并排序来创建文件。 但是二分查找需要随机访问12次以上的随机读操作才能找到合适的记录。 我的应用程序对查找操作的速度非常敏感,但我需要加快创建此文件的进程。你有什么想法吗?如何加速磁盘上的大哈希表的随机存取操作

+0

尝试'next_index = previous_index + 1'。这会将1/3的随机访问转换为顺序访问,希望可以提供25%的加速。除非散列函数不好,否则不应该给出更多的冲突。 – doublep 2015-02-08 19:08:28

+0

即使是过程切换,机械大容量存储的严重非均匀访问时间也是存在不适合RAM的密钥访问数据的不同方法的原因[B * -trees](http: //en.wikipedia.org/wiki/B%2B_tree)。 – greybeard 2015-02-08 19:31:52

回答

0

假设您拥有1 GB的可用RAM,将散列表分成15个部分,并将其中所包含的哈希表所属的数据进行分区。然后将每个部分构建在RAM中并写出。

+0

这意味着读取所有输入15次。此外,由于碰撞,人们必须非常小心从一个1 GB块跳到另一个块;如果处理不当,由此造成的错误将在以后变得非常混乱。 – doublep 2015-02-08 21:23:49

+0

“这意味着读取所有输入15次。”不,有更好的算法。 “另外,人们必须非常小心跳跃”我认为你在这里夸大了难度。 – 2015-02-08 21:41:08