在更少的文件夹中有更多的文件，还是在更少的文件中有更多的文件夹更快？答案

【问题标题】：Is it faster to have more files in fewer folders, or more folders with fewer files?在更少的文件夹中有更多的文件，还是在更少的文件中有更多的文件夹更快？
【发布时间】：2010-10-18 23:15:12
【问题描述】：

大家好。我正在创建一个将生成和存储数百万张图像的应用程序。在我开始之前，我想知道是否有人知道生成更多文件夹并在每个文件夹中只保留几个文件更好，还是我应该使用几个文件夹并用大量文件填充它们？

生成器将用 C++ 编写，文件将通过 GET 请求直接访问。

谢谢，史蒂夫

【问题讨论】：

我认为更多的上下文可能会有所帮助...例如，您是在谈论 Web 应用程序吗？您将在什么系统上运行您的应用程序？
如果不知道您使用的是什么操作系统和文件系统，真的不可能有任何好的答案。例如，当您在单个目录中有数千个文件时，使用 NTFS 的 Windows 会出现性能问题； AFAIK，大多数 Linux 文件系统都没有同样的问题。

标签： file-io performance directory

【解决方案1】：

在速度、可管理性等方面：使用更多文件夹。如果您检查一些大型应用程序，通常它们会将文件拆分为多个文件夹。大多数应用程序和/或文件系统不喜欢一个文件夹中有太多文件。从程序员的角度来看，这没关系。

【讨论】：

【解决方案2】：

与以往一样，您需要在特定部署平台上针对各种场景运行一些测试。请注意，您没有提到您正在运行的操作系统/文件系统等。

我通常会在深度嵌套的层次结构（可能快速但难以管理）和将所有内容存储在一个目录中的扁平层次结构之间实现某种平衡。后一种情况导致我过去在大多数平台上出现性能问题。您需要存储多少数据以及您需要的解决方案的性能将决定您如何构建目录，一些实验将在此处为您提供指导。

【讨论】：

【解决方案3】：

想到的事情：

专业版“更少的文件夹”

每个要导航的文件夹都意味着用户再次点击，页面加载时又出现延迟。
如果用户要浏览所有（或树的大部分），所有这些额外的文件只是要发送更多的字节。除非您将“许多文件夹”策略发挥到极致，否则这与总数相比是微不足道的，但它表明某处有一定的界限。

专业版“更多文件夹”：

一长串目录内容将迫使用户滚动、提前输入或以其他方式与查找特定文件进行交互，而不仅仅是选择，因为他们可以让页面一目了然。
单击文件夹 Foo 的用户必须等待该目录中的所有项目加载完毕，页面才能完成呈现。对于只想要一张图片的用户来说，这可能是明显的延迟和大量字节。
每次访问目录中的项目都需要一些时间。在老式文件系统上，这通常是 O(n) 操作。较新的文件系统支持 O(ln(n)) 访问。这如何影响系统的最佳运行取决于您计划使用的文件系统的性能。还要注意通常的用例（我认为这是查看少量目录而不是跨越整个树，不是吗？）。

针对这些竞争压力进行优化将取决于了解典型的使用模式是什么样的，这意味着您最初可能不得不猜测。

但为了方便在屏幕上显示，我建议每个目录中的条目应多于少数且少于 100 个。然后您可以收集统计数据并从那里进行调整。

【讨论】：

【解决方案4】：

@dmckee 没有点击，因为图像都是自动加载的。想想地图软件。

@布莱恩·阿格纽它将在某种 Linux 云上运行/服务。无论如何，我都不是 IT 人，只是程序员。但它肯定会扩展到一堆机器。

@Onkelborg 我同意。我也倾向于使用更多文件夹和更少文件。我在想布局会是这样的......

设置/缩放级别/列/row.jpg

我想使用文件名/目录结构在不查询服务器的情况下提取文件。如果我们放大 5 倍，左上角的坐标是 25,600 x 15,360，给定一个 256 像素的方形图块，一些基本的数学运算会给出这个 URL：

2389/5/20/12.jpg

其中“2389”是图块集 ID。所以你可以看到图像只会存储在三层深的目录中。根据缩放级别，带有图像的目录可能包含 4 - ~100 个图像。或者可能有十几个到几百个（文件夹稍微少一点），如果这样的话......

设置/缩放级别/行/列.jpg

我遇到了一个类似的系统，它使用了类似的四叉树系统，并注意到他们必须在奇怪的非系统位置拆分到新文件夹，这让我认为他们这样做是出于性能问题或其他限制。

在我写这篇文章时，我想我意识到第一个布局可能是要走的路。迭代查找请求的文件的项目更少。我只是在考虑碎片化，但我想这将是 IT 的工作。 ;)

【讨论】：