iOS文件系统在处理单个文件夹中的大量文件时的效率如何

如果我有大量文件（n x 100K个单独文件），那么在iOS文件系统中存储它们的最有效方式是什么（从按路径访问文件的速度来看）？我应该将它们全部转储到一个文件夹中，还是将它们分解到多级文件夹层次结构中

这基本上分为三个问题：

文件访问时间是否取决于“兄弟”文件的数量（我认为 答案是肯定的。如果我是正确的文件名被组织成b-树 那么它应该是O（logn））

沿路径从一个文件夹遍历到另一个文件夹的成本有多高 路径（类似于m*O（lognm）-其中m是 路径中的组件和nm是每个路径上的“兄弟”数 组成部分）

在文件系统级别缓存了什么使上述假设不正确

如果有人对这类问题有直接的经验，并能分享一些现实生活中的结果，那就太好了

---

您的评论将受到高度赞赏

我认为您应该将所有内容都存储在一个文件夹中，并创建一个哈希表，其中包括键（文件名）和值（源路径）参数。通过创建具有常量日志（1）的哈希表复杂性，这也将加快您的处理过程。

文件系统不是最佳数据库。对于成千上万的文件，您应该考虑使用核心数据或其他数据库来存储每个文件的名称和内容。

< P>这似乎可以提供相关的、硬的数据：

文件系统与核心数据：映像缓存测试

结论:

正如预期的那样，文件系统缓存速度更快。核心数据在存储时很快就会落后（稍微慢一点），但在执行单个随机访问时，加载时间要高得多

对于这样一个简单的情况，核心数据功能确实不起作用，所以请坚持使用文件系统版本

---

我不确定这对我有多大帮助。我对创建文件路径没有问题。我的问题是如何组织我的文件以确保我能尽快访问它们——如何让iOS更容易解析路径。如果我能够获得文件的节点ID（CNID），然后通过CNID打开文件（我认为是O（1）），这可能会起作用，但我找不到任何提供节点ID访问的公共API。实际上，我现在正在使用核心数据，对性能完全不感兴趣。删除10万条或更多记录需要很长时间。我希望使用文件系统会更快（删除）。如果我能以相当快的速度访问文件，我将非常乐意放弃核心数据。您的删除规则设置如何？级联删除可能需要“永远”。