一个大文件还是多个小文件？

Question

我有一个应用程序（目前用Python编写，因为我们解决了细节但最终将用C语言编写），它使用存储在纯文本文件中的单个记录。我们无法使用数据库，需要定期手动添加新记录。

我的问题是：拥有一个文件（500k-1Mb）并让我的应用程序打开，循环，查找和关闭文件会更快吗？或者将记录分开并使用某些文件命名会更快适当的约定，以便应用程序可以简单地循环文件名以找到它需要的数据？

我知道我的问题非常笼统，所以关于这个主题的任何好文章的方向都和建议一样受到赞赏。

非常感谢你的时间， 丹

Answer 1

基本上你的第二种方法是索引 - 只是你在文件系统本身构建索引。这没有什么本质上的错误，只要你安排好事情，这样你就不会在一个目录中获得太多文件，那么它就会很快。

您可以通过使用多级目录来实现“不要在一个目录中放置太多文件”目标 - 例如，具有密钥FOOBAR的记录可能存储在data/F/FO/FOOBAR而不是data/FOOBAR中。 1}}。

或者，您也可以通过构建索引文件来使单大文件执行，该文件包含（已排序的）键偏移对列表。如果你想要搜索与用于创建文件名的密钥不同的密钥，那么当目录为索引的方法失败时，如果你使用了索引文件，那么你可以为这种情况创建第二个索引。

您可能想重新考虑“我们不能使用数据库”限制，因为您实际上只是构建自己的数据库。

Answer 2

阅读目录通常比阅读文件更昂贵。但是，如果您可以在不读取目录的情况下找到所需的文件（即不是“循环文件名”，而是“构建文件名”），则由于您的命名约定，拆分数据库可能会有所帮助。

Answer 3

鉴于您的数据为1 MB，我甚至会考虑将其完全存储在内存中。

为了给你一些关于你的问题的线索，我认为只有一个大文件意味着你的应用程序正在管理这些行。拥有多个小文件依赖于系统和文件系统来管理数据。后者可能会非常慢，因为它涉及所有操作的系统调用。

Answer 4

一般来说，拥有多个小文件会更好。保持较低的内存使用率，并在搜索时提高性能。

但这取决于您需要的操作量，因为与内存存储相比，文件系统调用要昂贵得多。

Answer 5

这一切都取决于您的文件系统，块大小和内存缓存等。

像往常一样，测量并发现这是否是一个真正的问题，因为应该避免使用premature optimization。可能是使用一个文件与许多小文件对于实践中的性能并不重要，而选择应该基于清晰度和可维护性。

（我可以肯定的是，你不应该求助于线性文件搜索，而是使用命名约定来代替O（1）时间的文件。

Answer 6

一般的权衡是，拥有一个大文件可能更难以更新，但有很多小文件是繁琐的。我的建议是，如果你使用多个文件并且最终有很多文件，那么遍历一个包含一百万个文件的目录会变得很慢。如果可能的话，将文件分解为某种分组，以便将它们放入单独的目录并“键入”。我有一个应用程序，需要为系统的所有用户用户创建大量的小pdf文档。如果我们将它放在一个目录中，那将是一场噩梦，但是每个用户ID拥有一个目录会使其更易于管理。

Answer 7

在C中打开文件和关闭文件需要很长时间 即你有500个文件每个2 KB ...如果你处理它1000添加操作将添加到您的应用程序（500打开文件和500关闭）...而只有1个大小为1 MB的文件将节省您1000额外的操作......（这纯粹是我的个人意见......）

Answer 8

为什么你不能使用数据库，我很好奇？我尊重你的偏好，但只是想确保它是正确的原因。

并非所有数据库都需要服务器连接或复杂部署。例如，SQLite可以轻松嵌入到您的应用程序中。 Python已经内置了它，并且很容易与C代码连接（SQLite本身用C编写，其主要API用于C）。 SQLite在磁盘上的单个文件中管理功能完整的数据库，您可以在其中创建多个表并使用数据库的所有其他优秀功能。