我们公司有五百万用户。我们存储用户的代码文件。用户可以编辑和添加他们的文件,就像 web IDE,web IDE 列出用户的文件。我们使用 PHP 函数来实现这些操作,例如 readdir、file_get_contents 和 file_put_contents。我们使用了MooseFS,但是当我们读取程序中的文件时,尤其是加载速度很慢。
所以,我们需要更换文件系统,希望有人能给我一些建议,我们有大量的小文件,应该使用哪个分布式文件系统。
我们公司有五百万用户。我们存储用户的代码文件。用户可以编辑和添加他们的文件,就像 web IDE,web IDE 列出用户的文件。我们使用 PHP 函数来实现这些操作,例如 readdir、file_get_contents 和 file_put_contents。我们使用了MooseFS,但是当我们读取程序中的文件时,尤其是加载速度很慢。
所以,我们需要更换文件系统,希望有人能给我一些建议,我们有大量的小文件,应该使用哪个分布式文件系统。
500 万个条目对于关系数据库来说是很小的。我想知道为什么您觉得需要将这些存储在文件系统中。
是否每个用户都要求在启动时加载所有文件?如果是的话,我想知道系统的设计。O(N)
无论您如何设计该操作。
如果您将这 500 万个小文件放入关系数据库或 NoSQL 数据库,然后让每个用户连接到它并查询他们想要的特定文件,那么您就无需在启动时重复加载它们。问题解决了。
在任何分布式文件系统中,当我们考虑对小文件进行操作时,最关键的方面之一是网络延迟——这些分布式文件系统组件之间的延迟应该尽可能小(如 0.1 毫秒)。实现它的最佳方法是使用可靠的交换机并将所有机器连接到同一个交换机。
此外,在分布式文件系统(尤其是 MooseFS)中,最好的事情是可扩展性——这意味着,您拥有的节点越多(分布式计算越多,即同时在多个挂载上完成),集群的速度就越快。
如果您使用 MooseFS,请查看 MooseFS 3.0,因为从 3.0 版本开始对小文件的操作进行了改进。目前这是一种简单的方法,因为您不必进行“革命”(在升级之前记得备份主服务器上的 /var/lib/mfs - 即元数据)。MooseFS 可以很好地处理小文件,所以可能是配置有问题?
另外在 MooseFS 中(仍在考虑小文件操作),最重要的事情之一是拥有高 CPU 时钟(例如 3.7 GHz)和少量 CPU 内核,并在主服务器的 BIOS 中禁用节能选项(因为主服务器是一个单线程进程)。对于 Chunkservers 和 Clients 的情况是不同的——它们是多线程的,所以在使用多核 CPU 时你会得到更好的结果。
此外,如第 4 段“虚拟机和 MooseFS”中MooseFS 最佳实践中所述:
[...] 我们不建议在虚拟机上运行 MooseFS 组件(尤其是主服务器)。
因此,如果您在虚拟机上运行 MFS,实际上您可能会得到很差的结果。