随机访问大型二进制文件

Question

我有一个大的二进制文件（12 GB），我希望动态地组装一个较小的二进制文件（16 KB）。假设文件在磁盘上，并且较小文件的字节在某种程度上随机分布在大型二进制文件中。什么是最好和最快的方法？到目前为止，我还没有比大约三分钟更好。

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

1. 将文件转换为HDF5格式并使用C接口（慢速）。
2. 通过文件（慢）将一个小C程序写入fseek（）。

我如何真正快速

随机访问这些数据？

我希望查询时间不到几秒钟。

Answer 1

答案基本上是“不”。

单个机械磁盘驱动器需要10毫秒左右才能执行搜索，因为它必须移动磁头。 16000寻求每次搜寻10毫秒的时间等于160秒。你编写代码的方式完全没有区别;例如mmap（）将没有任何区别。

欢迎来到物理世界，软件人:-)。您必须改善操作的位置。

首先，对您要访问的位置进行排序。文件中的附近位置可能在磁盘附近，并且在附近位置之间寻找比随机搜索更快。

接下来，您的磁盘可能会以大约100兆字节/秒的速度读取顺序数据;也就是说，它可以在执行搜索所需的大约相同的时间内按顺序读取1兆字节。因此，如果您的两个值相差小于1兆字节，那么最好先阅读它们之间的所有数据，而不是在它们之间执行搜索。 （但要对此进行基准测试，以找到硬件上的最佳权衡。）

最后，RAID可以帮助提高吞吐量（但不是寻求时间）。它还可以提供多个磁盘磁头，如果您想要多线程化读取代码，它们可以同时寻找。

但一般来说，访问随机数据是您可以要求计算机执行的最糟糕的事情，无论是在内存中还是在磁盘上。顺序访问和随机访问之间的相对差异每年都在增加，因为物理是本地的。 （好吧，无论如何，我们依赖的物理学。）

[编辑]

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

[编辑2]

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

Answer 2

嗯，你可以达到的速度在很大程度上取决于你为了提取新文件的有效载荷96 kB而执行的读操作总数。

为什么会这样？因为来自（旋转）磁盘的随机读取是寻求限制的;与重新定位磁头所需的时间相比，这样的读取（几乎）无限快。

由于您说访问模式是随机的，因此您也不太可能受益于操作系统可能决定使用的任何预读;如果您愿意，可以通过filedescriptor上的fadvise(fd, 0, MAX_OFFSET, FADV_RANDOM);关闭大文件。或者，madvise()如果您选择了mmap()它。但是，如果您正在执行大读取，那么这只会让您获益（并且您知道一个重要的预读将是无稽之谈）。对于小读取，它只是确定总数的寻道时间。

假设您需要N随机读取并且您有M毫秒的搜索时间，则执行数据提取至少需要N * m毫秒（如果您已经得到了自己的磁盘...）。没有办法打破这个障碍。

编辑：有关缓解策略的一些事项：

正如一些人所提到的，解决这个问题的关键是尽量减少寻求。有几种策略：

1. 如果可以，则发出异步读取（即如果读取操作N+1不依赖于读取操作N，则可以同时发出两者）。这允许操作系统/设备驱动程序将它们排队并可能对它们进行重新排序（或将它们与其他同时运行的进程完成的读取合并），以便最有效地进行搜索。
2. 如果您事先知道所有位置，那么执行分散 - 聚集I / O（UN * X preadv()会想到），效果相同。
3. 查询文件系统和/或块设备以获取最佳/最小块大小;如何做到这一点取决于系统，参见例如statvfs()甚至是ioctl_list。如果您知道这一点，您可能会使用Nemo提到的技术（将“最佳”块大小内的两个小读取合并为一个大型读取，不需要搜索）。
4. 甚至可以使用查询接口，例如FIEMAP / FIBMAP（Windows等效大致为FSCTL_GET_RETRIEVAL_POINTERS）来确定文件数据的物理块位置，并执行读取基于此的合并（如果实际上跨越物理块边界并且文件系统将其转换为两个，则无法发出大的“非寻址”读取。）
5. 如果你建立了相对较长时间内读取的位置，那么在你计算未来的读取偏移量时读取（异步）也将有助于隐藏寻道延迟，因为你将计算周期/等待时间变为好使用。

一般情况下，如果上述情况均不适用，则必须咬紧牙关并接受寻道延迟。购买固态硬盘和/或使用RAM支持的文件系统，如果你可以证明成本（和/或RAM的波动性）。

Answer 3

你试过mmaping文件吗？ （在您的情况下，mmap64）。这将在您访问磁盘时从磁盘中读取数据。

如果您不得不寻找整个文件来查找您正在寻找的数据，那么您将能够使用SSD加速它，但它总是会变慢。您正在寻找的数据的位置是否已提前知晓？

文件是文本文件还是二进制文件？

Answer 4

如果您必须阅读整个文件，而您使用的是机械硬盘，则会被搞砸。假设传输速率约为1 Gigabit / second，这意味着您在物理上无法在不到12 x 8 = 96秒的时间内获得总线上的所有位。这假设没有寻道时间，处理器可以处理数据。

由于传输速率受到驱动器速度的限制，即使您确切知道要读取的每个数据字节的位置，如果它们在文件中随机分布，它仍然需要大约一样长，因为你必须等待磁盘旋转，直到你想要的下一个字节在头下。

如果你有一个SSD，你可以大大改善这一点，因为没有等待在头部下方的字节......

Answer 5

我想这取决于你需要做多少寻求。 16千，或更小的数字？ 你能将12 GB文件存储在固态硬盘上吗？ 这将减少寻求延迟。

你可以分解文件并将这些文件存储在不同的硬盘上吗？ 这将使异步搜索成为可能。

Answer 6

一些提示可以加速读取文件（除了已经说过的内容）： - 读取块的倍数的块 - 在POSIX兼容系统上使用posix_fadvise（），它向操作系统提供有关分页的建议。

Answer 7

使用并行或异步读取。如果需要，可以从多个线程，进程等发出它们，或者使用preadv，就像FrankH所说的那样。

这意味着在下一个I / O请求出现之前，您不必等待一个I / O请求完成，如果您有一个聪明的RAID控制器和许多心轴，这将提高性能。

另一方面，如果你有一个非常愚蠢的I / O子系统，它可能只会产生微小的差别。考虑使用哪个I/O scheduler（您可以动态更改它们，无需重启，这非常酷）。轶事证据表明，如果你有“智能”硬件，cfq或截止日期，如果你有愚蠢的硬件，“noop”是最好的。