将它们组织成类似散列表的方式,哈希键是文件名,关联值是文件的数据。
一位同事建议将它们组织成这样的目录结构:如果我想要存储一个名为“foobar.txt”的文件,并且它存储在D盘上,则将文件放在“D:\f\o\o\b\a\r.\t\x\t”中。然而,他无法解释为什么这是一个好主意。这个想法有什么用吗?
有什么好的想法吗? 关键是找到一个文件。以最快的方式查找文件名并打开它? 编辑:
这高度取决于许多因素:
在传统磁盘上纯粹随机访问文件确实非常昂贵。您可以获得的一个重要改进是使用固态硬盘。
如果您能理解访问模式,您可能能够利用引用局部性来放置这些文件。
另一种可能的方法是使用数据库系统,并将这些文件存储在数据库中以利用系统的缓存机制。
更新:
根据您的更新,您是否可以合并一些文件?1k 文件不太适合存储为文件系统(fat32、ntfs)具有簇大小,即使文件小于簇大小,每个文件也将使用簇大小。通常每个文件夹中的文件数都有限制,会影响性能。您可以通过将尽可能多的 10k 文件放入一个文件夹中来进行简单的基准测试,以查看性能下降了多少。
如果您打算使用 trie 结构,我建议调查文件名的分布,然后根据分布将它们分成不同的文件夹。
这在很大程度上取决于您将要存储文件的文件系统。文件系统处理大量文件的能力差异很大。
您的同事基本上建议使用Trie数据结构。使用这样的目录结构意味着在每个目录级别上只有少数文件/目录可供选择;这可能有所帮助,因为随着目录中文件数量的增加,访问其中一个文件的时间也会增加(实际时间差异取决于文件系统类型)。
话虽如此,我个人不会深入那么多层次——三到四个层次应该足以提供性能优势——之后的大多数层次可能都只有很少的条目(假设您的文件名没有遵循任何特定的模式)。
此外,我会将文件本身与其完整名称一起存储,这将使手动遍历此目录结构变得更容易,如果需要的话。
因此,我会将foobar.txt存储为f/o/o/b/foobar.txt
个别文件之间有关联吗?就访问时间而言,你把东西放在哪个文件夹里并不会影响太多;物理位置才是重要的。
我知道现在已经晚了几年,但也许这可以帮助下一个人。
我的建议是使用 SAN,并映射到其他服务器也可以映射的 Z 驱动器。我不会选择你朋友所说的文件夹路径,而是采用 drive:\clientid\year\month\day\ 的方式,如果每天摄入超过 10 万个文档,则可以根据需要添加小时甚至分钟的子文件夹。这样,您永远不会有超过 60 个子文件夹,同时可以一直到秒。将链接存储在 SQL 中以便快速检索和报告。这使得文件夹路径非常简短,例如:Z:\05\2004\02\26\09\55\filename.txt,因此您不会在全局范围内遇到 256 个限制。
希望能对某些人有所帮助。:)