use*_*465 5 java filesystems performance ntfs large-data-volumes
上下文 我们有一个自行开发的文件系统支持的缓存库.由于大量条目(例如,最多100,000个),我们目前在一次安装时遇到性能问题.问题是:我们将所有fs条目存储在一个"缓存目录"中.非常大的目录表现不佳.
我们正在考虑将这些条目分布在子目录上 - 就像git那样,例如100个子目录,每个子目录大约有1,000个条目.
这个问题
我知道较小的目录大小将有助于文件系统访问.
但是"传播到子目录"会加速遍历所有条目,例如枚举/读取所有100,000条目吗？即当我们从FS存储中初始化/加热缓存时,我们需要遍历所有100,000个条目(并删除旧条目)可能需要10多分钟.
"传播数据"会减少这种"遍历时间".此外,这种"遍历"实际上可以/确实删除陈旧的条目(例如,比N天更早)"传播数据"会改进删除时间吗？
附加上下文 -NTFS -Windows系列操作系统(Server 2003,2008)
-Java J2ee应用程序.
我/我们将感谢文件系统可扩展性问题的任何教育.
提前致谢.
将
ps我应该评论说我有自己测试这个的工具和能力,但我想首先选择理论和经验的蜂巢头脑.
我还相信在子目录中传播文件会加速操作.
所以我进行了测试:我已经生成了从AAAA到ZZZZ的文件(26 ^ 4个文件,大约450K)并将它们放入一个NTFS目录中.我还将相同的文件放在从AA到ZZ的子目录中(即按名称的前2个字母分组文件).然后我进行了一些测试 - 枚举和随机访问.我在创建之后和测试之间重新启动了系统.
扁平结构暴露的性能略好于子目录.我相信这是因为目录被缓存而NTFS索引目录内容,所以查找速度很快.
请注意,400K文件的完整枚举(在两种情况下)大约需要3分钟.这是重要的时间,但子目录使情况更糟.
结论:特别是在NTFS上,如果可以访问任何这些文件,将文件分组到子目录中是没有意义的.如果你有一个缓存,我还会测试按日期或按域分组文件,假设某些文件比其他文件更频繁地访问,并且操作系统不需要将所有目录保存在内存中.但是,对于您的文件数量(低于100K),这可能也不会带来显着的好处.我想你需要自己测量这些特定场景.
更新:我已经减少了我的随机访问测试,只能访问一半的文件(从AA到OO).假设这将涉及一个平面目录和只有一半的子目录(给子目录案例奖励).仍然平坦的目录表现更好.所以我假设除非你有数百万个文件,否则将它们保存在NTFS上的一个平面目录中比将它们分组到子目录中要快.