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