我有大量静态内容需要通过基于 Linux 的 Web 服务器进行传输。这些内容包括超过一百万个小型 gzip 文件。其中 90% 的文件小于 1K，其余文件最多为 50K。未来，这些 gzip 文件的数量可能会增长到超过一千万个。
我应该把这些内容放在文件结构中，还是应该考虑把所有这些内容放在数据库中？如果放在文件结构中，我可以使用大型目录吗？还是应该考虑较小的目录？
有人告诉我文件结构的传输速度会更快，但另一方面，我知道文件会占用磁盘上的大量空间，因为文件块将超过 1K。
关于交付绩效的最佳策略是什么？
更新
为了记录，我在 Windows 7 下进行了一项测试，其中包含五十万个文件：
答案1
我猜测 FS 结构会更快，但是您需要一个良好的目录结构以避免目录中包含大量文件。
我不会太担心磁盘空间的丢失。例如，在 16K 块大小下，在最坏的情况下，您将丢失 15GB 的空间，因为每个文件都需要一个额外的块。对于当今的磁盘大小，这不算什么，您可以根据特定需求调整文件系统的参数。
答案2
如果您选择文件结构选项，您可以做的一件事至少在一定程度上提高磁盘 I/O 性能是使用 noatime+nodiratime 挂载分区，除非您必须使用它们。它们根本不重要，所以我建议这样做。也许您也可以使用固态硬盘。
答案3
我认为这里的正确答案取决于如何对文件进行索引......决定何时选择给定的文件进行传送。
如果您已经通过数据库查询来确定文件名，那么您很可能会发现最好将文件保存在数据库记录中，您可能会发现通过调整所选数据库中的某些分页设置然后将文件存储在数据库中可以获得最佳结果（例如：更大的页面以容纳所有 blob 记录），或者您可能会发现最好使用文件系统。
数据库选项的成功率稍高一些，因为对于一百万条记录，每个文件被查询的概率可能并不相同。如果您遇到一个文件可能连续或几乎连续被查询多次的情况，则数据库可以充当最近检索的文件的实际缓存，在这种情况下，您通常会将文件结果加载到内存中。您可能需要仔细调整数据库引擎的内部结构以获得所需的行为。
但我的回答主要要说明的是除非您使用一些有代表性的测试数据进行尝试并测量结果，否则您无法真正知道什么方法最有效。
答案4
使用现代文件系统，这应该不是什么大问题。我已经测试过 XFS，在同一目录中有 10 亿个文件，我确信 ext4 也能很好地完成任务（只要文件系统本身不是太大）。有足够的内存来缓存目录条目；更大的处理器缓存也会有很大帮助。