就性能和效率而言，使用大量小文件（我的意思是几百万个）还是几个（十个左右）大（几千兆字节）文件更好？假设我正在构建一个数据库（不完全正确，但重要的是它将被大量访问）。
我主要关心读取性能。我的文件系统目前是 Linux 上的 ext3（如果重要的话，是 Ubuntu 服务器版），尽管我仍然可以切换，所以不同文件系统之间的比较会很棒。出于技术原因，我不能为此使用实际的 DBMS（因此是问题），所以“只使用 MySQL”不是一个好的答案。
提前谢谢，如果我需要更具体，请告诉我。
编辑：我将存储大量相对较小的数据，这就是为什么使用大量小文件对我来说更容易。因此，如果我使用一些大文件，我一次只能从中检索几个 KB。我也会使用索引，所以这不是一个真正的问题。此外，一些数据指向其他数据片段（它会在很多小文件的情况下指向文件，而在大文件的情况下指向文件中数据的位置）。
这里有很多假设，但出于所有意图和目的，搜索一个大文件比搜索一堆小文件要快得多。
假设您正在寻找包含在文本文件中的一串文本。搜索1TB 文件比打开1,000,000 MB 文件并搜索这些文件要快得多。
每个文件打开操作都需要时间。大文件只需打开一次。
而且，在考虑磁盘性能时，单个文件比大量文件更有可能连续存储。
...再次，这些都是概括，而不了解您的具体应用程序。
TMO 这里的主要问题是关于索引。如果您要在没有良好索引的大文件中搜索信息，则必须扫描整个文件以查找可能很长的正确信息。如果你认为你可以建立强大的索引机制，那么你应该使用大文件。
我更愿意将此任务委托给 ext3，它应该非常擅长。
编辑 ：
根据这篇关于 ext3 的维基百科文章要考虑的一点是，碎片确实会随着时间的推移而发生。因此，如果您有大量占用文件系统很大比例的小文件，那么您将随着时间的推移失去性能。
该文章还验证了关于每个目录限制 32k 文件的声明（假设维基百科文章可以验证任何内容）
这取决于。真的。不同的文件系统以不同的方式进行优化，但总的来说，小文件被有效地打包。拥有大文件的好处是您不必打开和关闭很多东西。打开和关闭是需要时间的操作。如果你有一个大文件，你通常只打开和关闭一次，然后使用查找操作
如果您选择大量文件解决方案，我建议您使用类似的结构
b/a/bar
b/a/baz
f/o/foo
因为您对目录中的文件数量有限制。
我相信 Ext3 每个目录有大约 32000 个文件/子目录的限制。如果您要处理数百万个文件，则需要将它们分布在许多目录中。我不知道这会对性能产生什么影响。
我更喜欢几个大文件。事实上，为什么有几个，除非它们是某种逻辑上独立的单元？如果你还只是为了分裂而分裂，我说不要那样做。Ext3 可以很好地处理非常大的文件。
我使用的系统在 Linux 下的 XFS 文件系统上存储多达约 500 万个文件，并且没有任何性能问题。我们只使用文件来存储数据，我们从不全面扫描它们，我们有一个用于搜索的数据库，并且表中的一个字段包含一个我们用来检索的 guid。我们使用上面的两级目录，文件名是 guid，但如果文件数量更大，可以使用更多。我们选择这种方法是为了避免在数据库中存储一些额外的 TB 数据，这些数据只需要存储/返回并且从不搜索，它对我们来说效果很好。我们的文件范围从 1k 到大约 500k。
我们还在 ext3 上运行了系统，它运行良好，但我不确定我们是否曾经将它推过大约一百万个文件。由于每个目录的最大文件数限制，我们可能需要转到 3 目录系统。