如何最有效地在Linux Web服务器上存储和提供1,000,000+个小的gzip压缩文件？

我必须通过基于Linux的Web服务器提供大量静态内容。它是一组超过一百万个小的gzip文件。90％的文件小于1K，其余文件最大为50K。将来，这可能会增长到超过1000万个gzip文件。

我应该将这些内容放在文件结构中还是应该考虑将所有这些内容都放在数据库中？如果它处于文件结构中，我可以使用大目录还是应该考虑使用较小的目录？

有人告诉我文件结构可以更快地交付，但另一方面，我知道文件会在磁盘上占用很多空间，因为文件块将超过1K。

关于交付绩效的最佳策略是什么？

更新

作为记录，我已经在Windows 7下对50万个文件进行了测试：

我猜想FS结构会更快，但是您将需要一个好的目录结构来避免包含大量文件的目录。

我不会太担心磁盘空间的丢失。例如，在16K块大小的情况下，在最坏的情况下，每个文件需要一个额外的块，您将失去15GB的空间。对于当今的磁盘大小，这已经不算什么，您可以根据您的特定需求调整文件系统的参数。

如果选择文件结构选项，则至少可以在某种程度上提高磁盘I / O性能的一件事是使用noatime + nodiratime挂载分区，除非您必须拥有它们。它们根本不是很重要，因此我建议您这样做。也许您也可以使用固态驱动器。

我认为这里的正确答案取决于如何对文件建立索引……是什么决定何时选择给定文件进行交付。

如果您已经在进行数据库查询以确定您的文件名，则可能会发现最好将文件保留在db记录中，最好通过调整数据库中的某些分页设置来找到最佳结果。选择，然后将文件存储在db中（例如：较大的页面以说明所有blob记录），或者您可能会发现使用文件系统仍然更好。

数据库选项有更好的计算机会，因为有100万条记录的情况下，每个文件的查询可能性不同。如果您可能连续或几乎连续查询一个文件，则数据库可以充当最近检索到的文件的事实缓存，在这种情况下，您通常会得到文件结果已经加载到内存中。您可能需要仔细调整数据库引擎的内部结构以获得所需的行为。

但是要摆脱我的回答，最主要的是，直到您使用一些具有代表性的测试数据并测量结果后，您才真正知道哪种方法最有效。

对于现代文件系统，这应该不是什么大问题。我已经在同一目录中测试了10亿个文件的XFS，而且我很确定ext4也会做得很好（只要文件系统本身不是太大）。有足够的内存来缓存目录条目；更大的处理器缓存也会有很大帮助。