我正在寻找一个包含大量由 XML API 提供的小文件的服务器。它不会对目录或顺序文件块进行大量迭代——我们正在谈论大量寻找不连续数据的过程。
对于单个文件的请求，BSD UFS 上的寻道时间会随着时间的推移而降低吗？我知道文件系统的 inode 限制基于分区/片的大小，但硬盘驱动器必须为每个文件请求单步遍历 inode 表，然后才能发现数据的位置。什么文件系统在寻道时间方面产生最佳性能？
另一种方法是设置 2-4GB 的“blob”文件，并有一个单独的系统从软件中寻找其中包含的文件。该软件的“inode 表”可以根据当前登录的用户等进行优化交付……这些“inode 表”可能会缓存在 RAM 中，并且只与当前登录的用户相关，从而减少资源浪费.
这两种解决方案在可扩展性和维护方面的评价如何？通过使用第二种解决方案，我可以期待什么样的性能提升（如果有的话）？
最明显且经过时间验证的缓解技术是对目录（和路径名搜索策略）使用良好的分层设计，并拥有更多的目录，每个目录中的文件更少。
对于最近带有dirhash和 softupdates 的 FreeBSD 版本，我发现每个目录有几万个文件没有问题。您可能不想超过 500.000 个文件。例如，删除包含 2.500.000 个文件的目录花了我三天时间。
我不确定我是否正确理解了您的问题，但是如果您想查找大量文件，为什么不使用 RAID0 或 VFS 文件系统上的分区 mysql 表呢？
编辑：据我所知，一个文件夹中的大量文件会降低任何FS 速度，因为它必须维护更大的文件、权限和名称列表，数据库旨在将数据列表保存在内存中并以非常优化的方式查找通过它的方式。
您的情况的更多详细信息会有所帮助，这些文件是否存在或者它们是否由您的应用程序创建？如果您需要一种在没有关系数据库结构的情况下存储任意数据的方法，您是否查看过对象数据库
如果您的对象应该或可以通过 HTTP 访问，另一种选择是在小型 Web 服务器前使用清漆缓存。最初对象将存储在磁盘上，但 varnish 会在第一次访问给定对象后从内存中存储和提供对象。