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

Question

我的 Mac 应用程序保存了一组对象(使用 Core Data)，每个对象都有一个封面图像，我为其分配了 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 是否限制目录中的文件数？从磁盘中检索它们是否以某种方式更快？这会使用于计算文件名的代码更加复杂，所以我想看看是否有充分的理由这样做。

Answer 1

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

我曾经在一家 ISP 工作，他们会使用多目录方案来分解主目录(他们有 90k 多个)。您可以使用 UUID 的前两个字符，然后是后两个字符来对目录进行分区，例如:

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

这样您就不需要计算任何额外的字符或代码，只需使用已有的字符或代码将其分解即可。由于您的 UUID 每次都会不同，这应该足够了。