2009-01-11 137 views
3

我正在寻找建立一个服务器与大量的XML API提供的小文件。它不会对目录或顺序文件块进行大量迭代 - 我们正在谈论很多和寻找不连续数据的问题。文件系统寻求与很多小文件的性能

在BSD上寻找时间UFS会随着时间的推移而降低个别文件的请求吗?我知道文件系统的inode限制是基于分区/分区的大小,但是硬盘驱动器必须在每次文件请求之前遍历inode表,才能发现数据的位置。什么文件系统可以获得最佳搜寻性能?

另一种方法是设置2-4GB的“blob”文件,并有一个单独的系统从软件中查找其中包含的文件。该软件的“inode表”可以根据当前登录的用户等进行优化以供交付......这些“inode表”可能会被缓存在RAM中,并且只会涉及当前登录的用户,从而减少浪费的资源。

从可扩展性和维护的角度来看,这两种解决方案在哪里进行评估?通过使用第二种解决方案,我可以期待什么样的性能提升(如果有的话)?

回答

5

最明显且经过时间验证的缓解技术是对目录(和路径名搜索策略)使用良好的分层设计,并且每个目录中包含的文件较少。

+0

我完全同意这一点。 – ariso 2009-05-02 02:47:33

1

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

编辑:据我所知,一个文件夹中的大量文件将降低FS的速度,因为它必须维护更大的文件列表,权限和名称,数据库旨在将数据列表保存在内存中并通过它寻求一种非常优化的方式。

0

您的情况的更多细节将有所帮助,文件是否存在或将由您的应用程序创建?如果您需要一种方法来存储任意数据,而无需使用关系数据库的结构,您可以看看object databases

+0

这些将是新文件。 我的方法的两个目标是尽量减少文件查找时间,尽可能简化备份和节省空间。 – Nolte 2009-01-12 05:13:17

0

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

+0

我们已经通过Squid缓存HTTP请求。不错的建议,但:) – Nolte 2009-01-12 05:11:41

+0

清漆更好地保存在内存中的一切,所以你很少打文件系统。当它这样做时,它使用自己的虚拟内存格式,因此您不会遇到目录大小限制。 – wulong 2009-01-12 17:18:38

3

对于最近的FreeBSD版本和dirhash和softupdates我没有看到每个目录有几万个文件没有问题。你可能不想在500.000左右的档案北边。例如。用2.500.000个文件删除一个目录花了我三天。