我正在编写一个程序,该程序应该处理许多小文件,例如数千甚至数百万个文件。
我已经在500k文件中测试了该部分,第一步只是迭代其中包含约45k目录(包括subdirs的子目录等)和500k小文件的目录。遍历所有目录和文件(包括获取文件大小和计算总大小)大约需要6秒钟。现在,如果我尝试在遍历时打开每个文件并立即将其关闭,则看起来它永远不会停止。实际上,它花费的时间太长(数小时...)。由于我是在Windows上执行此操作的,因此我尝试使用CreateFileW,_wfopen和_wopen打开文件。我没有读写文件,尽管在最终实现中,我只需要阅读。但是,在任何尝试中我都没有看到明显的改善。

我想知道是否有一种更有效的方法来打开带有任何可用功能的文件,无论是C,C++还是Windows API,还是唯一更有效的方法是直接读取MFT并直接读取磁盘块,我试图避免吗?

更新:我正在处理的应用程序正在使用版本控制进行备份快照。因此,它也具有增量备份。为了进行版本控制(例如scm),在一个巨大的源代码存储库中完成了500k文件的测试。因此,所有文件都不在一个目录中。也有大约45k目录(如上所述)。

因此,建议的压缩文件的解决方案无济于事,因为备份完成后,即访问了所有文件。因此,我不会从中受益,甚至会产生一些性能成本。

最佳答案

对于任何操作系统来说,您想做的事情本质上都是很难做到的。无论如何分割,45,000个子目录都需要大量磁盘访问权限。

就NTFS而言,任何超过1,000字节的文件都是“大”文件。如果有一种方法可以使大多数数据文件小于900个字节,则可以通过将文件数据存储在MFT中来实现很高的效率。这样一来,获取数据不会比获取文件的时间戳或大小更昂贵。

我怀疑是否有任何方法可以优化程序的参数,进程选项甚至操作系统的调整参数,以使应用程序正常运行。除非您能以完全不同的方式重新设计,否则您将面临数小时的操作。

一种策略是将文件分布在多台计算机上(可能是数千台计算机),并在每个进程上都有一个子应用程序来处理本地文件,并将任何结果馈送到主应用程序。

另一种策略是将所有文件重新架构为几个较大的文件,例如@felicepollano建议的大型.zip文件,以有效地虚拟化文件集。与访问40亿个1 MB的文件相比,随机访问4000 GB的文件在本质上更有效地利用了资源。同样,将所有数据移动到合适的数据库管理器(MySQL,SQL Server等)中也可以实现此目的,并可能提供其他好处,例如轻松的搜索和轻松的存档策略。

09-10 08:22
查看更多