提供70,000个静态文件（jpg）的最佳方式？

基准，基准，基准！ 你可能会发现两个选项之间没有显着的差异 ，这意味着你的时间更好地花在其他问题上。 如果你做了基准testing，发现没有真正的区别，那么select哪个scheme更容易 – 如果只有程序必须访问这些文件，那么很容易编码，或者如果人们需要频繁使用这些文件，人们很容易处理这些问题。

至于哪一个更快，目录查找时间，我相信，与目录中的文件数的对数成正比。 因此，对嵌套结构的三次查找中的每一个都将比一次大的查找更快，但是三者的总和可能会更大。

但不要相信我，我不知道我在做什么！ 在重要的时候衡量绩效 ！

它真的取决于您用来存储文件的文件系统。

有一些文件系统（如ext2和ext3）在一个目录中有成千上万的文件时会显得很慢，因此使用子目录是一个非常好的主意。

其他文件系统，如XFS或reiserfs（*），不会在一个目录中放慢数千个文件的速度，所以无论您是否拥有一个大目录或大量较小的子目录都无关紧要。

（*）reiserfs有一些很好的function，但是它是一个具有灾难性故障历史的实验玩具。 不要在任何重要的事情上使用它。

正如其他人所说，目录哈希很可能是最优化的。

我build议你做的事情是使你的URI 独立于你使用的任何目录模式，使用nginx的重写模块，例如map example123456.jpg到/path/12/34/123456.jpg

然后，如果您的目录结构需要更改性能的原因，您可以更改，而无需更改您的发布的URI。

做一些基本的目录哈希通常是一个好主意。 即使你的文件系统处理好70k文件， 说目录中的数百万个文件将变得难以pipe理。 另外 – 你的备份软件如何像一个目录中的许多文件等等

这就是说：要获得复制（冗余）和更容易的可扩展性，考虑将文件存储在MogileFS中，而不是在文件系统中。 如果文件比较小，有些文件比其他文件更受欢迎，那么可以考虑使用Varnish（varnish-cache.org）来快速地为它们提供服务。

另一个想法：使用CDN – 他们惊人地便宜。 我们使用的成本与我们为“常规带宽”支付的成本基本相同; 即使在低使用率（10-20Mbit / sec）的情况下也是如此。

你可以在你的nginx服务器上放一个鱿鱼caching。 鱿鱼可以保留在内存中的stream行图像，或使用它自己的文件布局快速查找。

对于Squid，缺省值是16个一级目录和256个二级目录。 这些是我的文件系统的合理默认值。

如果你不使用像Squid这样的产品，并创build自己的文件结构，那么你需要为你的文件提出一个合理的哈希algorithm。 如果文件名是随机生成的，这很容易，您可以使用文件名本身分成桶。 如果所有的文件看起来像IMG_xxxx，那么你需要使用最低有效数字，或者散列文件名并根据该散列号进行分割。

正如其他人所提到的那样，您需要testing一下您的设置和使用模式，以了解哪种布局最适合您。

但是，您也可能要查看nginx中的open_file_cache参数。 请参阅http://wiki.nginx.org/NginxHttpCoreModule#open_file_cache

通过一切手段，基准和使用这些信息来帮助你做出决定，但如果这是我的系统，我也会考虑长期维护。 根据你需要做什么，如果有一个目录结构，而不是一个目录中的所有东西，pipe理事情可能会更容易。

将它们拆分成目录听起来是个好主意。 基本上（你可能知道）这种方法的原因是，在一个目录中有太多的文件会使得目录索引变得很大，并导致操作系统花费很长时间来search它; 相反，（方向）太多（对不起，坏的双关）意味着要为每个文件进行大量的磁盘查找。

我build议把文件分成一两级目录 – 运行一些试验来看看最好的方法。 如果70,000个图像中有多个图像比其他图像更受欢迎，请尝试将所有这些图像放在一个目录中，以便操作系统可以使用caching的目录索引。 或者事实上，你甚至可以把stream行的图像放到根目录下，就像这样：

 images/ 021398012.jpg 379284790.jpg ... 000/ 000/ 000000000.jpg 000000001.jpg ... 001/ ... 002/ ... 

…希望你看到的模式。 在Linux上，你可以使用硬链接stream行的图像（但不是符号链接，降低效率AFAIK）。

也想想人们将如何下载图像。 是否有任何个人客户要求只有几个图像，或整个集？ 因为在后一种情况下，创buildTAR或ZIP归档文件（或可能是多个归档文件）与其中的图像是有意义的，因为传输一些大文件比许多较小文件更有效。

PS我在理论上有些被甩掉，但是kquinn是对的，你真的需要做一些实验来看看什么对你最好，而这种差别很可能是微不足道的。

我认为这是一个好主意，打破文件的层次结构，没有其他原因，如果你需要下拉，并在目录上做一个ls将花费更less的时间。

我不知道aboutext4，但是股票ext2不能处理在一个目录中的许多文件，reiserfs（reiser3）被devise来处理这个好（一个ls仍然是丑陋的）。

文件的组织与文件系统的性能和稳定性有关，而不是传递性能。 我会避免ext2 / ext3和xfs或reiser。

你真的想看看caching。 无论是内置的Web服务器caching还是像清漆一样的第三方caching。

正如kquinn所提到的，基准将是业绩收益/损失的真实指标。

将这些文件转储到亚马逊S3存储桶中并从那里提供服务对你来说是否值得？

让他们担心优化。