创建大量目录，每个目录只有几个文件，还是创建更少目录，文件量大？答案

【问题标题】：Creating lots of directories with a few files each, or fewer directories with huge amounts of files?创建大量目录，每个目录只有几个文件，还是创建更少目录，文件量大？
【发布时间】：2012-09-29 12:45:48
【问题描述】：

我必须存储和管理大量与设计主题相关的信息。这一切都可以通过两种可能的方式在逻辑上组织起来：

每个网站用户都有一个目录，与主题相关的文件存储在此目录中。（每个目录的文件不多）。
每个主题都有一个目录，其中包含所有相关用户的文件。（许多主题和许多用户）。

每次用户登录时，都必须获取相关文件。我的网站是用 PHP 开发并托管在 CentOS 上的。这个问题是一个重要的设计问题吗？任何一种选择都会对存储和性能产生影响吗？就个人而言，我觉得第一选择会更容易遵循。

【问题讨论】：

目录中的文件数量过多会导致速度变慢，您可以考虑为 /files/a/n/t/ant.file 之间的每个字母添加子目录

标签： php filesystems centos storage directory

【解决方案1】：

经典的答案总是：大目录会降低性能。

但是，我们有 2012。 80 后或 90 后的答案不一定是好答案。

Here 是一个很好的微基准测试，在 LevelDB 系统的上下文中完成。在那个使用 ext3 的基准测试中，在一个有 1000 个文件的目录中打开一个文件需要 9 毫秒，有 10,000 个文件需要 10 毫秒，有 100,000 个文件需要 16 毫秒。但请记住，读取和打开额外目录也需要一些时间。

通常，当目录中的文件数量增加时，您应该期望对数增长。除非您使用极其脑残的文件系统，例如FAT32 或配置混乱。但是，当使用大量目录或目录层次结构时，您也可以预期渐近相同的增长。

作为对比，大致流程如下：

在包含大量文件的目录中打开文件：

爬取文件系统以查找目录 inode。即使这样也可能使用多个 IO，但缓存会有所帮助
读取目录inode
查找文件的目录条目。每个现代文件系统都以某种形式的树结构组织目录的目录条目，例如甚至 ext3 在 6 年左右的时间里默认使用 H-Tree。在较大的目录中，这需要对数步数，具有较大的分支因子。
读取文件inode
读取文件数据

在文件少但有另一层目录的目录中打开文件：

爬取文件系统以查找父目录 inode。即使这样也可能使用多个 IO，但缓存会有所帮助
读取父目录inode
查找子目录的目录条目。同样，对数，但可能比替代方案少 IO。
读取目录inode
找到文件本身的目录条目。同样，对数，但可能比替代方案少 IO。
读取文件inode
读取文件数据

渐近地说，将数据拆分为大量目录并不会为您购买任何东西来读取/写入数据。

[编辑：] W.r.t 建议为每个单词的字母建立一个目录层次结构。这意味着您的分支因子最多为 52，并且文件分布可能存在较大偏差。一些字母更常见，目录包含更多文件。使用隐式树结构文件系统时的分支因子，例如会更高，分布不会偏斜。这显着减少了 IO。以性能为目标时，这简直是个坏主意。如果有人真的想使用目录，请考虑将数据散列到目录中，以至少确保良好的数据分布。

【讨论】：

【解决方案2】：

大目录一旦包含太多文件就会产生很大的开销（并且“太多”的定义取决于操作系统和文件系统；所以通常你最好使用更多的目录（甚至嵌套子目录）并且每个文件更少...我通常尝试使用 100 个文件/目录作为上限

【讨论】：