论坛徽章:: 0

电梯直达

1楼 [收藏(0)] [报告]

发表于 2011-02-17 00:42 |只看该作者 |倒序浏览

我阅读了FastDFS的介绍资料后，据说FastDFS的扩展性很好。。。我对此有些疑问。。。

按说FastDFS中，文件ID进行hash后可得到文件存储在哪个卷（volume）。当系统需要扩容时，如果新增加卷，则是否需要对hash函数进行改动呢？如果是的话，则需对所有客户端进行更新，开销较大，可扩展性不好。

请高手帮我分析一下，谢谢！

文库|博客

happy_fish100

巨富豪门

论坛徽章:: 4

2楼 [报告]

发表于 2011-02-17 09:40 |只看该作者

回复 1# Ivy就是长青草

FastDFS对文件存储时，并没有采用hash方式。
tracker server作为中心服务器，起作负载均衡和调度作用。
理论上，group可以无限扩容。FastDFS支持上K的group数，没有任何问题。

实战分享：从技术角度谈机器学习入门| 【大话IT】RadonDB低门槛向MySQL集群下战书 | ChinaUnix打赏功能已上线！ | 新一代分布式关系型数据库RadonDB知多少？

Ivy就是长青草

白手起家

论坛徽章:: 0

3楼 [报告]

发表于 2011-02-17 12:21 |只看该作者

回复 2# happy_fish100

谢谢！我还想再请问一下：

TFS中的文件ID，是对block ID和File ID等进行编码得到的，请问FastDFS中的文件ID是否也是对卷号、偏移量、文件名等进行了编码呢？

还有一个问题，如果使用hash的方式，可能会降低可扩展性吧，但应该也会有些优点吧，能否帮忙分析一下？

谢谢！

实战分享：从技术角度谈机器学习入门| 【大话IT】RadonDB低门槛向MySQL集群下战书 | ChinaUnix打赏功能已上线！ | 新一代分布式关系型数据库RadonDB知多少？

happy_fish100

巨富豪门

论坛徽章:: 4

4楼 [报告]

发表于 2011-02-17 14:11 |只看该作者

本帖最后由 happy_fish100 于 2011-02-17 14:12 编辑

回复 3# Ivy就是长青草

存储文件，不需要采用hash分布的方式吧。
如果你是存储key value pair，按key进行hash分布，是比较合理的。

FastDFS 3.0将对小文件进行优化，到时才会引入文件存储偏移量，谢谢！