文件系统通过大量微小文件来寻求性能

Question

我正在寻找构建一个包含许多由XML API提供的小文件的服务器。它不会对顺序文件的目录或块进行大量迭代 - 我们正在讨论大量不连续数据的搜索。

对于单个文件的请求，是否会在BSD UFS上寻找时间降级？我知道文件系统的inode限制是基于分区/片的大小，但是硬盘驱动器必须在每个文件请求之前逐步执行inode表，然后才能发现数据的位置。什么文件系统为寻道时间带来最佳性能？

另一种方法是设置2-4GB <！>“blob <！>”;文件，并有一个单独的系统，从软件中寻找包含在其中的文件。软件的<！>“inode表<！>”;可以根据当前登录的用户等优化交付......这些<！>“inode表<！>”;可能会被缓存在RAM中，并且只与当前登录的用户有关，因此浪费的资源更少。

这两种解决方案在可扩展性和维护方面的优势在哪里？通过使用第二种解决方案，我可以期待什么样的性能提升？

Answer 1

最明显且久经考验的缓解技术是对目录（和路径名搜索策略）使用良好的分层设计，并且每个目录中包含更少文件的目录。

Answer 2

对于 dirhash 和softupdates的最新FreeBSD版本我见过每个目录几万个文件没问题。你可能不想超过500.000左右的文件。例如。删除2.500.000文件的目录花了我三天。

Answer 3

我不确定我是否理解你的问题，但是如果你想查找大量文件，为什么不使用在RAID0或VFS文件系统上布置的分区mysql表？

编辑：据我所知，一个文件夹中的大量文件会降低任何 FS速度，因为它必须维护更大的文件，权限和名称列表，数据库旨在保留列表存储器中的数据，并通过它以非常优化的方式寻找。

Answer 4

您的情况的更多细节会有所帮助，文件是否已存在或是否由您的应用程序创建？如果您需要一种方法来存储关系数据库结构中的任意数据，您可以查看对象数据库

Answer 5

如果你的对象应该或可以通过HTTP访问，另一种选择是使用 varnish 在小型Web服务器前缓存。最初对象将存储在磁盘上，但是在第一次访问给定对象后，清漆将存储并从内存中提供对象。