c - 随机访问一个大的二进制文件

Question

我有一个很大的二进制文件 (12 GB)，我想从中即时组装一个较小的二进制文件 (16 KB)。假设文件在磁盘上，并且较小文件的字节随机分布在较大的二进制文件中。最好和最快的方法是什么？到目前为止，我最多只能做三分钟。

我尝试过的东西，它们或多或少具有相同的性能:

1. 将文件转换为 HDF5 格式并使用 C 接口(interface)(慢)。
2. 通过文件编写一个小的 C 程序到 fseek()(慢)。

我怎样才能真正快速随机访问这些数据？

我想在几秒钟内完成查询。

Answer 1

答案基本上是否定的。

单个机械磁盘驱动器将花费 10 毫秒左右的时间来执行寻道，因为它必须移动磁头。 16000 次寻道乘以每次寻道 10 毫秒等于 160 秒。编写代码的方式完全没有区别；例如mmap() 不会有任何区别。

欢迎来到物理世界，软件人:-)。您必须改善运营地点。

首先，对您正在访问的位置进行排序。文件中的邻近位置可能在磁盘上邻近，并且在邻近位置之间查找比随机查找更快。

接下来，您的磁盘可能可以以大约 100 兆字节/秒的速度读取顺序数据；也就是说，它可以在执行查找所需的大约相同时间内连续读取 1 兆字节。因此，如果您的两个值相距小于 1 兆字节，您最好读取它们之间的所有数据，而不是在它们之间执行查找。 (但对此进行基准测试以在您的硬件上找到最佳权衡。)

最后，RAID 可以帮助提高吞吐量(但不能提高寻道时间)。如果您想多线程读取代码，它还可以提供可以并发查找的多个磁盘磁头。

但总的来说，无论是在内存中还是在磁盘上，访问随机数据都是您可以让计算机做的最糟糕的事情。顺序访问和随机访问之间的相对差异每年都在增加，因为物理学是局部的。 (好吧，无论如何，我们在这里依赖的物理学。)

[编辑]

@JeremyP's suggestion使用 SSD 是一个很好的选择。如果它们是一个选项，它们的有效寻道时间为 0.1 毫秒左右。这意味着您可以期望您的代码在此类硬件上的运行速度提高 50-100 倍。 (我没有想到这一点，因为我通常处理 1 TB 范围内的文件，SSD 太贵了。)

[编辑 2]

正如@FrankH 在评论中提到的，我的一些建议假定文件在磁盘上 是连续的，当然不能保证这一点。您可以通过使用良好的文件系统(例如 XFS)和在文件创建时给出“提示”(例如使用 posix_fallocate 通知内核您打算填充一个大文件)来帮助改进这一点。