我正在编写一个应该处理许多小文件的程序,比如数千甚至数百万.
我一直在测试500k文件的那一部分,第一步就是迭代一个目录,里面有大约45k目录(包括子目录的子目录等)和500k小文件.遍历所有目录和文件,包括获取文件大小和计算总大小大约需要6秒.现在,如果我尝试在遍历时打开每个文件并立即关闭它,它看起来永远不会停止.事实上,它需要太长时间(小时……).自从我在 Windows上执行此操作后,我尝试使用CreateFileW,_wfopen和_wopen打开文件.我没有在文件上读或写任何东西,尽管在最后的实现中我只需要阅读.但是,我没有看到任何尝试都有明显的改善.
我一直在测试500k文件的那一部分,第一步就是迭代一个目录,里面有大约45k目录(包括子目录的子目录等)和500k小文件.遍历所有目录和文件,包括获取文件大小和计算总大小大约需要6秒.现在,如果我尝试在遍历时打开每个文件并立即关闭它,它看起来永远不会停止.事实上,它需要太长时间(小时……).自从我在 Windows上执行此操作后,我尝试使用CreateFileW,_wfopen和_wopen打开文件.我没有在文件上读或写任何东西,尽管在最后的实现中我只需要阅读.但是,我没有看到任何尝试都有明显的改善.
我想知道是否有一种更有效的方法来打开具有任何可用功能的文件,无论是C,C还是Windows API,或者唯一更有效的方法是读取MFT并直接读取磁盘块,我我想避免？
更新：我正在处理的应用程序是使用版本控制进行备份快照.因此,它还具有增量备份. 500k文件的测试是在一个巨大的源代码库上完成的,以便进行版本控制,就像scm一样.因此,所有文件都不在一个目录中.还有大约45k目录(如上所述).
因此,建议的压缩文件解决方案没有帮助,因为当备份完成时,就是访问所有文件的时候.因此,我认为没有任何好处,甚至会产生一些性能成本.
解决方法
您要做的事情本质上是任何操作系统都难以有效地执行. 45,000个子目录需要大量磁盘访问,无论它是如何切片的.
就NTFS而言,任何大约1,000字节的文件都是“大”的.如果有一种方法可以使大多数数据文件小于大约900字节,那么通过将文件数据存储在MFT中可以实现主要的效率.然后,获取数据并不比获取文件的时间戳或大小更昂贵.
我怀疑有没有办法优化程序的参数,过程选项,甚至操作系统的调整参数,以使应用程序运行良好.您将面临多小时操作,除非您能够以完全不同的方式重新构建它.
一种策略是将文件分布在多台计算机上 – 可能是数千台计算机 – 并在每个进程上有一个子应用程序本地文件,将任何结果提供给主应用程序.
另一个策略是将所有文件重新构建为一些较大的文件,如@felicepollano建议的大.zip文件,有效地虚拟化您的文件集.随机访问4000 GB文件本质上比访问40亿个1 MB文件更有效和更有效地使用资源.将所有数据移动到合适的数据库管理器(MySQL,sql Server等)中也可以实现这一点,并可能提供其他好处,如简单搜索和简单的归档策略.
