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

Question

我的Mac应用程序保存了一个对象集合(包含核心数据)，每个对象都有一个封面图像，我在创建时为其分配了一个UUID。我最初将封面图像作为字段存储在核心数据存储中，但最近开始将它们存储在磁盘上的文件系统中。

最初，我将封面存储在一个平面目录中，使用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是否限制目录中的文件数量？从磁盘检索它们在某种程度上会更快吗？这会使用于计算文件名的代码变得更加复杂，所以我想找出是否有充分的理由这样做。

Answer 1

在某些文件系统上(我相信HFS+也是如此)，在同一目录中包含太多文件会导致性能问题。

我曾经在一家互联网服务提供商工作，在那里他们会使用多目录方案来分解主目录(他们有90k+ )。您可以使用UUID的前两个字符，然后使用第二个字符对目录进行分区，例如：

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

这样你就不需要计算任何额外的字符或代码，只需使用你已经拥有的字符或代码来分解它。因为您的UUID每次都是不同的，所以这就足够了。

Answer 2

主要原因是，在后一种方式中，正如您已经提到的，磁盘检索更快，因为您的目录较小(因此FS将在较小的表中查找要存在的文件)。

Answer 3

但是，您应该针对特定的文件系统和特定的使用场景执行测量。我对Windows XP上的NTFS执行了此操作，并惊讶地发现平面目录在所有类型的测试中都比层次结构执行得更好。