FastFDS和MogileFS的对比

happy_fish100

上传文件成功后，文件ID由storage server返回给客户端。文件ID中包括了分组、文件路径和文件名等信息，需要由客户端来保存文件ID。因此FastDFS 服务器端是不需要保存文件ID或索引等信息的。这样就避免了像mogileFS借助数据库来存放文件索引信息导致的性能瓶颈问题。

lwxian

我针对我们的情况，觉得系统存在以下不足，分析来源于PPT里的一句话，不知道正确不正确：

group：组，也可称为卷。同组内服务器上的文件是完全相同的；


缺点：
系统采用group来管理存储，同一组内的服务器的文件是完全相同的；那么要求组内存储空间容量必须一样；这样的要求对于新购服务器可能问题不大，但对于利旧服务器的话有些问题；

这种设计没有办法通过扩充机器来扩充同一组内的容量；因为很有可能机器原有机器没有办法扩容了；

关于负载均衡，group与group之间 没有没有做；这样可能会导致有些组忙，有些组闲；




不知道分析是否正确，请指点一二；

happy_fish100

你分析得比较有道理的。
同组storage服务器的配置保持一致，这是FastDFS的架构特点所要求的。

>>关于负载均衡，group与group之间 没有没有做；这样可能会导致有些组忙，有些组闲；
你说的是访问的冷热均衡问题，要解决这个问题，要付出相当大的代价。
对于这一点，相信任何分布式文件系统都没有太好的解决方法。

FunBSD

文件ID中包括了分组、文件路径和文件名等信息，需要由客户端来保存文件ID。因此FastDFS 服务器端是不需要保存文件ID或索引等信息的。

客户端将文件ID放在客户端的base_path目录里吗？
如果客户端丢失了这些文件ID，如何找回？

如果客户端不能找回这些文件ID，并做删除操作，那这些文件岂不是一直占用很大的空间？

文件ID是从Client的metadata里检索到的吗？

happy_fish100

回复 14# FunBSD

>>客户端将文件ID放在客户端的base_path目录里吗？
客户端（应用）自己保存即可，比如可以保存到数据库中。

>>如果客户端丢失了这些文件ID，如何找回？
这个就没办法了。对于重要数据，客户端应该采用冗余备份的方案，或者定期备份的做法。

>>如果客户端不能找回这些文件ID，并做删除操作，那这些文件岂不是一直占用很大的空间？
客户端的数据不能轻易丢失吧？

>>文件ID是从Client的metadata里检索到的吗？
文件ID本身是自治的。包含了分组名、文件路径和文件名。

dayssir

你分析得比较有道理的。
同组storage服务器的配置保持一致，这是FastDFS的架构特点所要求的。

>>关于负 ...
happy_fish100 发表于 2009-10-29 15:47

其实，我们自己是可以做各组之间转移的功能，只是麻烦一点。

有个建议，希望FastDFS提供各组之间转移的功能。还有，最好能做访问量的统计，这样能更好地分析哪些文件访问得多。