【问题标题】:How to speed up random access operation on disk for big hash tables如何加快大哈希表在磁盘上的随机访问操作
【发布时间】: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


【解决方案1】:

假设您有,例如 1 GB 的可用 RAM,将哈希表分成 15 个部分,并根据它所属的哈希表的哪一部分对数据进行分区。然后在 RAM 中构建每个部分并将其写出。

【讨论】:

  • 这意味着读取所有输入 15 次。此外,必须非常小心元素因碰撞而从一个 1 GB 块跳转到另一个块;如果处理不当,由此引起的错误将在以后变得非常混乱。
  • "这意味着读取所有输入 15 次。"不,有更好的算法。 “另外,必须非常小心元素跳跃”我认为您在这里夸大了难度。
猜你喜欢
  • 1970-01-01
  • 2010-10-04
  • 1970-01-01
  • 1970-01-01
  • 2021-09-13
  • 1970-01-01
  • 2013-03-02
  • 2017-05-11
  • 1970-01-01
相关资源
最近更新 更多