c++：更多的小文件还是更少的大文件？ [关闭]答案

【问题标题】：c++: more small files or fewer large files? [closed]c++：更多的小文件还是更少的大文件？ [关闭]
【发布时间】：2012-09-20 22:18:16
【问题描述】：

我编写了一个 C++ 程序来查询 100 GB 的字典。我已将字典拆分为 n 个大小相等的文件。所有拆分文件都放在同一个目录中。字典是完全索引的，即，一旦有查询，我就知道要打开哪个 spit 文件以及在哪里寻找。我的问题是为了获得更好的性能，哪个拆分会更好： (a) 少量大文件或 (b) 大量小文件？另外，理想的分裂是什么？

【问题讨论】：

理想情况下，您会在正确实施的数据库中使用索引表。以 SQLite 为例，它可以嵌入到您自己的 C++ 代码中。

标签： c++ performance file file-access

【解决方案1】：

你的字典是静态的还是可以在运行时改变？

如果它是静态的，则对所有内容使用单个文件。

如果它是动态的并且您的索引是“向量”（不是最好的主意），请为数据使用一个文件，为每个索引使用一个文件。

如果它是动态的并且您的索引是“树”（包括非 100% 连续的双端队列和其他向量（如 ADT）），您可以再次使用单个文件，除非出于速度考虑将索引存储在单独的卷上有意义.

您应该在开始时打开文件，并且不再受到文件打开/关闭的惩罚。

如果您的应用程序是 64 位，只需将整个文件映射到内存中，然后让操作系统完成其余的工作。

如果您的应用程序是 32 位的，仍然使用内存映射来访问文件。您需要为可能需要执行的每个可能的并发访问创建一个内存映射“窗口”（对于静态数据，可能每个数据线程一个，每个索引每个线程一个或两个）。

【讨论】：

【解决方案2】：

我认为这个问题没有直接的答案。只有实验才能告诉你。打开文件进行读取的成本应该是恒定的，无论大小如何，读取文件的内容当然取决于文件的大小。

还有其他提示我假设当您收到查询时，您打开文件，完全解析/读取它，或者直到找到单词然后关闭文件并返回结果，在这种情况下，有很多增强功能要做，也许您有它们，也许不是，但这里有

如果您收到大量查询，打开文件可能会很昂贵，在此如果您可能需要缓存您的文件或您的搜索查询更好的性能
当你打开一个文件并读取它时，你是按顺序进行的，这意味着文件或多或少地被加载到内存中，我曾经遇到过一个用于 java 的 sax xml 解析器，它能够加载只有所需的 xml 块进入内存，用于处理非常大的 xml 文件，也许 C++ 有类似的东西。 SAX project

检查when is a file loaded into memory

完全不同的方法是使用带索引的数据库。这个问题你不用处理文件打开问题

【讨论】：

谢谢。 “无论大小如何，打开文件进行读取的成本都应该是恒定的”是有用的——这意味着拆分大小应该无关紧要。我会通过实验检查它。代码不会顺序读取文件；它执行查找操作，因为它知道与查询词相关的信息在文件中的确切位置。
是的，但是取决于操作系统和打开的函数，文件加载到内存的时间是不同的。
打开文件进行读取的开销应该与文件大小无关，但不会与文件路径中每个目录的目录内容无关（以root开头）。当然，对于合理的目录，差异可以忽略不计。也就是说，在一个有 10 个文件的目录和一个有 100 个文件的目录中打开文件时，您应该看不到区别。但是在包含一百万个文件的目录中，事情会变得很慢。
另外请注意，驱动器（硬件）、设备驱动程序（这里考虑 sata）和文件系统驱动程序（考虑 NTFS、ext3 等）的缓存会根据您是否正在执行“首次访问”或多次访问。在性能和资源方面，我想说单个文件应该以最少的资源使用提供最佳性能（您打开它一次，所以根本没有时间重新打开它）。如果您的索引变成一个数据文件，每个索引一个文件（打开所有内容一次）。那是假设您的数据可能会更改。如果它是静态的，只需对所有内容使用单个文件。
感谢您的 cmets。减少 dir 负载的建议很有用。