你如何处理许多小文件？

Question

我正在处理的产品每天收集数千个读数并将它们存储为NTFS分区(Windows XP)上的64k二进制文件.经过一年的生产,一个目录中有超过300000个文件,而且这个数字还在不断增长.这使得从Windows资源管理器访问父/祖先目录非常耗时.

我试过关闭索引服务,但没有区别.我还考虑将文件内容移动到数据库/ zip文件/ tarball中,但对我们来说单独访问文件是有益的.基本上,这些文件仍然需要用于研究目的,研究人员不愿意处理任何其他事情.

有没有办法优化NTFS或Windows,以便它可以使用所有这些小文件？

Answer 1

只要你告诉它停止创建与16位Windows平台兼容的替代文件名,NTFS实际上将在目录中的超过10,000个文件中正常运行.默认情况下,NTFS会自动为每个创建的文件创建一个"8点3"文件名.当目录中有许多文件时,这会成为一个问题,因为Windows会查看目录中的文件,以确保它们正在创建的名称尚未使用.您可以通过将NtfsDisable8dot3NameCreation注册表值设置为1来禁用"8点3"命名.该值可在HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\FileSystem注册表路径中找到.进行此更改是安全的,因为只有为非常旧版本的Windows编写的程序才需要"8点3"名称文件.

在此设置生效之前需要重新启动.

Answer 2

在目录中的10,000个文件之后,NTFS性能严重下降.您所做的是在目录层次结构中创建一个附加级别,每个子目录包含10,000个文件.

对于它的价值,这是SVN人员在1.5版本中采用的方法.他们使用1,000个文件作为默认阈值.

Answer 3

性能问题是由单个目录中的大量文件引起的:一旦你消除了它,你应该没问题.这不是NTFS特有的问题:实际上,在大型UNIX系统上通常遇到用户主页/邮件文件.

解决此问题的一种显而易见的方法是将文件移动到具有基于文件名的名称的文件夹.假设您的所有文件都具有相似长度的文件名,例如ABCDEFGHI.db,ABCEFGHIJ.db等,请创建如下目录结构:

ABC\
    DEF\
        ABCDEFGHI.db
    EFG\
        ABCEFGHIJ.db

使用此结构,您可以根据文件名快速查找文件.如果文件名具有可变长度,请选择最大长度,并在前面添加零(或任何其他字符)以确定文件所属的目录.

Answer 4

如果您可以计算文件的名称，您也许可以按日期将它们分类到文件夹中，以便每个文件夹仅包含特定日期的文件。您可能还想创建月份和年份层次结构。

另外，您是否可以将一年以上的文件移动到不同的（但仍然可以访问）位置？

最后，再一次，这要求您能够计算名称，您会发现直接访问文件比尝试通过资源管理器打开文件要快得多。例如， 假设您知道所需文件的路径而无需获取目录列表，那么从命令行输入
notepad.exe "P:\ath\to\your\filen.ame"实际上应该很快。

Answer 5

我已经看到过去通过将文件分割成目录的嵌套层次结构的大量改进,例如,首先是文件名的第二个字母; 那么每个目录都不包含过多的文件.但是,操纵整个数据库仍然很慢.

Answer 6

我过去多次遇到过这个问题。我们尝试按日期存储、将文件压缩到日期以下，这样就不会出现大量小文件等。所有这些都是针对将数据作为大量小文件存储在 NTFS 上的实际问题的创可贴。

您可以使用 ZFS 或其他一些可以更好地处理小文件的文件系统，但仍然停下来询问是否需要存储小文件。

在我们的例子中，我们最终使用了一个系统，其中特定日期的所有小文件都以 TAR 类型的方式附加，并使用简单的分隔符来解析它们。磁盘文件从 120 万个减少到不到几千个。它们实际上加载速度更快，因为 NTFS 不能很好地处理小文件，而且驱动器无论如何都能更好地缓存 1MB 文件。在我们的例子中，与存储文件的实际存储和维护相比，找到文件正确部分的访问和解析时间是最少的。