【发布时间】:2015-04-08 09:53:07
【问题描述】:
我需要存储 15Gb 或记录,记录的固定大小等于 270 字节,我希望能够通过键找到记录。 key 是记录中少数字段的哈希,多条记录可以有相同的键。 我尝试使用 gdbm 但速度很慢,现在我正在尝试制作自己的解决方案。 我有两个主要想法。 1-直接寻址。我创建了一个空记录的大文件。数量或空记录比我要存储的要大两倍,根据这个概率,新记录的索引(new_key%(文件中的总记录))是空记录的索引至少等于 1/2,如果记录有这个索引到目前为止,已经忙于文件中的下一个 index=hash(key)%total 记录。 这种方法给了我很好的查找操作速度。平均而言,我需要 1.65 次读取记录操作才能找到合适的。 但是由于很多随机访问操作,最初填充这个文件非常慢。可能需要4个小时。 2 - 二进制搜索。只是执行并行合并排序来创建文件。 但是二进制搜索需要 12 倍的随机读取操作和随机访问才能找到合适的记录。 我的应用程序对查找操作的速度非常敏感,但我需要加快创建此文件的过程。你有什么想法吗?
【问题讨论】:
-
试试
next_index = previous_index + 1。这会将 1/3 的随机访问转换为顺序访问,有望提高 25% 的速度。除非散列函数不好,否则不会再产生任何冲突。 -
机械大容量存储的访问时间非常不均匀,甚至超出了进程切换的数量级,这正是存在不同方法通过不适合 RAM 的键访问数据的原因,@987654321 @,一个。
标签: performance algorithm hash