Context我们有一个自行开发的文件系统支持的缓存库。目前，由于条目数量较多（例如多达 100,000 个），我们在一次安装中遇到了性能问题。问题：我们将所有文件系统条目存储在一个“缓存目录”中。非常大的目录性能很差。
我们正在考虑将这些条目分散到子目录中——就像 git 所做的那样，例如100 个子目录，每个子目录约有 1,000 个条目。
问题
我知道较小的目录大小将有助于文件系统访问。
但是“传播到子目录”会加速遍历所有条目，例如枚举/读取所有 100,000 个条目？ IE。当我们从 FS 存储初始化/预热缓存时，我们需要遍历所有 100,000 个条目（并删除旧条目），这可能需要 10 多分钟。
“传播数据”会减少这个“遍历时间”吗？此外，这种“遍历”实际上可以/确实删除过时的条目（例如，早于 N 天）“传播数据”会缩短删除时间吗？
附加背景-NTFS
-Windows系列操作系统（服务器2003、2008）
-Java J2ee 应用程序。
我/我们将不胜感激任何关于文件系统可扩展性问题的教育。
提前致谢。
will
附注我应该评论说，我有工具和能力来亲自测试这一点，但我想我会首先选择蜂巢思维来获取理论和经验。
我还相信跨子目录传播文件会加快操作速度。
所以我进行了测试：我生成了从 AAAA 到 ZZZZ 的文件（26^4 个文件，大约 450K）并将它们放入一个 NTFS 目录中。我还将相同的文件放置到从 AA 到 ZZ 的子目录中（即按文件名的前 2 个字母对文件进行分组）。然后我执行了一些测试 - 枚举和随机访问。我在创建后和测试之间重新启动了系统。
扁平结构表现出比子目录稍好的性能。我相信这是因为目录被缓存并且 NTFS 索引目录内容，因此查找速度很快。
请注意，对于 400K 文件，完整枚举（在这两种情况下）大约需要 3 分钟。这是很重要的时间，但子目录会让情况变得更糟。
结论：特别是在 NTFS 上，如果可以访问任何文件，则将文件分组到子目录中是没有意义的。如果你有一个cache，我还会测试按日期或按域对文件进行分组，假设某些文件的访问频率比其他文件更频繁，并且操作系统不需要将所有目录保留在内存中。但是，对于您的文件数量（低于 100K），这可能也不会提供显着的好处。我认为你需要自己衡量这些具体场景。
Update:我已将随机访问测试减少到仅访问一半文件（从 AA 到 OO）。假设这将涉及一个平面目录和仅一半的子目录（对子目录的情况给予奖励）。仍然扁平目录表现更好。所以我假设除非你有数百万个文件，否则将它们保存在一个平面目录中on NTFS将比将它们分组到子目录中更快。
本文内容由网友自发贡献，版权归原作者所有，本站不承担相应法律责任。如您发现有涉嫌抄袭侵权的内容，请联系:hwhale#tublm.com(使用前将#替换为@)
