图像缓存的平面或嵌套目录结构？

我的Mac应用程序保持一个对象（包含核心数据）的集合，每个对象都有一个封面图像，创建时我将其分配给一个UUID。我原本一直将封面图像作为字段存储在我的Core Data存储中，但最近开始将它们存储在文件系统中的磁盘上。图像缓存的平面或嵌套目录结构？

最初，我将这些封面存储在一个平面目录中，使用UUID命名文件，如下所示。这让我O（1）抓取，因为我知道究竟在哪里看。

... 
/.../Covers/3B723A52-C228-4C5F-A71C-3169EBA33677.jpg 
/.../Covers/6BEC2FC4-B9DA-4E28-8A58-387BC6FF8E06.jpg 
...

我看的方式与其它应用程序处理这个任务，不过，注意到一个多层次的方案，如下（例如）。这仍然可以在O（1）时间内实施。

... 
/.../Covers/A/B/3B723A52-C228-4C5F-A71C-3169EBA33677.jpg 
/.../Covers/C/D/6BEC2FC4-B9DA-4E28-8A58-387BC6FF8E06.jpg 
...

可能是这样做的原因是什么？ OS X是否限制目录中文件的数量？从磁盘检索它们的速度有些快吗？这会使用于计算文件名的代码更加复杂，所以我想知道是否有这样做的好理由。

2011-06-16 Dov

在某些文件系统上（我也相信HFS +），在同一目录中有太多文件会导致性能问题。

我曾经在一个ISP中工作，他们将打破主目录（他们有90k +）使用多目录方案。您可以通过使用，比方说，前两个字符的UUID，那么后两个分区的目录，如：

/.../Covers/3B/72/3B723A52-C228-4C5F-A71C-3169EBA33677.jpg 
/.../Covers/6B/EC/6BEC2FC4-B9DA-4E28-8A58-387BC6FF8E06.jpg

这样，你不需要计算任何额外的字符或代码，只需使用你已经打破了。由于你的UUID每次都会有所不同，这应该就足够了。

2011-06-16 12:23:30 Clinton

谢谢，我一直在思考这些问题。我将UUID设置为'NSMutableString'，然后在前两位和后两位字符后面插入'/'，所以现在我的文件名也缩短了4个字符。 – Dov 2011-06-16 12:44:39

虽然有太多的处罚可以分解吗？使用2个2位十六进制数字目录的方案每个意味着创建至多256^2个目录，这意味着（假设均匀分布）每个文件实际上都有自己的目录。 – Dov 2011-06-16 12:56:06

这取决于您计划存储多少个文件，但是，您可以从1位开始，然后如果数量太大，请使用第二位数字创建子目录，依此类推。 – Clinton 2011-06-16 13:07:07

最主要的原因是在后一种方式中，正如你所提到的，磁盘检索速度更快，因为你的目录较小（所以FS会在较小的表中查找文件）。

2011-06-16 12:20:10

所以，要清楚，从一个具有更多内容的目录中读取文件需要更长的时间？ – Dov 2011-06-16 12:21:52

不需要。操作系统需要较长时间才能确定该目录中是否存在文件。一旦你得到文件句柄，读/写时间应该是相同的。 – 2011-06-16 12:23:05

正如其他人提到的，在某些文件系统上，操作系统打开文件需要更长的时间，因为一个包含多个文件的目录比两个短目录要长。

但是，您应该针对特定的文件系统和特定的使用场景执行测量。我在Windows XP上为NTFS做了这个工作，并且惊讶地发现平面目录在各种测试中的表现都比分层结构更好。

2011-06-16 13:03:24

回答