c++:多一些小文件还是少一些大文件

c++: more small files or fewer large files?

本文关键字：文件 小文 c++      更新时间：2023-10-16

我已经编写了一个c++程序来查询一个100 GB的字典。我把字典分成了n个大小相等的文件。所有拆分的文件都放在同一目录中。字典是完全索引的，也就是说，一旦出现查询，我就知道要打开哪个split文件以及在哪里查找。我的问题是为了更好的性能，哪种分割会更好：(a) 少量大文件还是(b)大量小文件？此外，什么是理想的分手？

您的字典是静态的还是可以在运行时更改？

如果它是静态的，那么对所有内容都使用一个文件。

如果它是动态的，并且您的索引是"向量"(不是最好的主意)，则为数据使用一个文件，为每个索引使用一个文档。

如果它是动态的，并且索引是"树"(包括不是100%连续的deques和其他类似矢量的ADT)，则可以再次使用单个文件，除非为了速度起见，将索引存储在单独的卷上是有意义的。

您应该在一开始就打开文件，再也不要招致文件打开/关闭的处罚。

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

如果您的应用程序是32位的，仍然可以使用内存映射来访问该文件。您需要为您可能需要进行的每一次可能的并发访问创建一个内存映射的"窗口"(对于静态数据，可能是数据上每个线程一个，每个索引上每个线程一两个)。

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

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

  1. 如果你得到很多查询，打开文件可能会很昂贵，在这个以防您可能需要缓存文件或搜索查询更好的性能
  2. 当你打开一个文件并读取它时，你是按顺序进行的，这意味着或多或少地将文件加载到内存中，我曾经遇到过一个用于java的sax xml解析器，它能够只将所需的xml块加载到内存，用于处理真正巨大的xml文件，也许c++也有类似的东西。SAX项目

检查文件何时加载到内存

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

相关文章：