在较少的文件夹中存放更多文件，或者在文件较少的文件夹中存放更多文件？

Question

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

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

谢谢， 史蒂夫

Answer 1

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

Answer 2

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

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

Answer 3

想到的事情：

Pro“更少的文件夹”

• 每个要导航的文件夹意味着用户的另一次点击，以及页面加载时的另一个延迟。
• 如果用户要导航所有（或树的大部分），那么所有这些额外文件只是要发送的更多字节。除非你将“多文件夹”策略推向极端，否则这与总数相比是微不足道的，但它表明存在某种限制。

专业“更多文件夹”：

• 目录内容的长列表将强制用户滚动，预先输入或以其他方式与查找特定文件进行交互，而不仅仅是选择因为它们可以进入页面一览无余。
• 用户点击文件夹Foo必须等待该页面完成渲染之前加载该目录中的所有项目。对于只想要一个图像的用户来说，这可能是显着的延迟和很多字节。
• 目录中项目的每次访问都需要一些时间。在旧式文件系统上，这通常是O（n）操作。较新的文件系统支持O（ln（n））访问。这对系统的最佳操作有何影响取决于您计划使用的文件系统的性能。还要注意通常的用例（我认为它是在查看少量目录而不是跨越整个树，不是吗？）。

针对这些竞争压力进行优化将取决于了解典型使用模式的外观，这意味着您最初可能需要猜测。

但是为了便于在屏幕上显示，我建议每个目录不止一个，少于一百个条目。然后你可以收集统计数据并从那里进行调整。

Answer 4

@dmckee 没有点击，因为图像全部自动加载。想想绘图软件。

@Brian Agnew 它将在某种Linux云上运行/服务。我不是任何想象力的IT人，只是程序员。但它肯定会扩展到一堆机器。

@Onkelborg 我同意。我倾向于使用更多文件夹和更少的文件。我认为布局会像......

组/缩放级别/列/ row.jpg

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

5分之2389/ 20 / 12.JPG

其中“2389”是图块集ID。所以你可以看到图像只存储在三层深的目录中。具有图像的目录可以基于缩放级别保持4到约100个图像。或者可能是十几到几百（文件夹略少），如果这样走......

组/缩放级别/行/ column.jpg

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

正如我写的那样，我想我已经意识到第一种布局可能是要走的路。迭代查找请求的文件的项目较少。我只想到碎片，但我想这将是IT的工作。 ;）