我的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是否限制目录中的文件数量？从磁盘检索它们在某种程度上更快吗？这将使用于计算文件名称的代码更复杂，所以我想知道是否有充分的理由这样做。
答案 0 :(得分：3)
在某些文件系统上（我也相信HFS +），在同一目录中包含太多文件会导致性能问题。
我曾经在ISP工作，他们会分解主目录（他们有90k +）使用多目录方案。您可以使用UUID的前两个字符，然后使用后两个字符对目录进行分区，例如：
/.../Covers/3B/72/3B723A52-C228-4C5F-A71C-3169EBA33677.jpg
/.../Covers/6B/EC/6BEC2FC4-B9DA-4E28-8A58-387BC6FF8E06.jpg
这样您就不需要计算任何额外的字符或代码，只需使用已经分解的字符或代码。由于你的UUID每次都会有所不同，这应该足够了。
答案 1 :(得分：2)
主要原因是，在后一种方式中，正如您所提到的，磁盘检索速度更快，因为您的目录较小（因此FS将在较小的表中查找文件是否存在）。
答案 2 :(得分：2)
正如其他人提到的，在某些文件系统上，操作系统打开文件需要更长的时间，因为一个包含许多文件的目录比几个短目录读取的时间更长。
但是，您应该对特定文件系统和特定使用方案执行测量。我在Windows XP上为NTFS做了这个，并且惊讶地发现平面目录在各种测试中表现得比分层结构更好。