你如何处理许多小文件？

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

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

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

1> Dan Finucane..：

---

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

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

---

建议在300,000个文件以上关闭8点3.http://technet.microsoft.com/en-us/library/cc778996(WS.10).aspx您可以在较新版本的Windows上更改命令行的行为,例如`fsutil 8dot3name set 1`.

2> Adam Tegen..：

---

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

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

---

你有一个链接解释为什么性能在10,000个文件后严重降级？

---

请记住,最初的答案是7年,硬盘驱动器*显着*更快这些天.

3> mdb..：

---

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

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

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

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

4> moonshadow..：

---

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