关于moosefs,我的看法

发布于 2022-09-05 12:52:24 字数 1056 浏览 28 评论 9

先说性能,实测,小规模应用,它的性能不如GLUSTERFS2.0。MFS的排序使用的是HASH排序,64位CHUNK号HASH成16位,HASH号相同的组成一个不定长的链表,用来存储CHUNK的信息。这种排序要命的地方是它必须得保证所有CHUNK索引都得放在MASTER服务器的内存中,如果存储在磁盘上,MASTER的效率会非常低下,低下到你忍受不了的程度。因为服务器内存容量一般都相当有限,这种排序方法也就决定了MFS不可能管理太多的文件,除非它能改成B树排序。
   MFS对内存容量的要求非常大,一般的服务器也就几G的内存,PB级的存储,可能要消耗1TB的内存(跟文件数量有关),有点离谱了。
   MFS对超过64M大小的文件会进行切割,这种切割跟GOOGLE的GFS是一样的,可以说MFS跟GFS结构和原理上都很相像,区别是MFS支持POSIX,而GFS则不支持POSIX,对于NAS一类需要POSIX支持的应用,GFS、KFS、HDFS、MogileFS等等都是不能用的,而MFS则可以,但是MFS同时肯定也得付出性能代价。
   MFS支持类似WINDOWS回收站的功能,前面提到的文件系统都没有这个功能,如果误删了文件,可以从回收站里再MV回来。对POSIX的支持和回收站功能,使得MFS特别适合做NAS存储。
   MFS的MASTER不是分布式的,一套MFS的存储系统里面只能有一个MASTER,MASTER挂了存储集群就没法工作了。除了可靠性的问题外,非分布式的MASTER也限制了MFS文件系统的性能。
   MFS的CHUNK SERVER并不是挂上去就能自动同步的,得find "mount目录" *它才会进行同步,所以你不能一次更换太多的CHUNK SERVER,这样做有丢数据的可能。
   目前版本的MFS还不完全适合做NAS,因为不支持磁盘配额,上线后单位员工滥用空间你可就死定了,等1.7版吧。不过我已经放弃它了,等CEPH吧,反正也不急着用

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(9

聚集的泪 2022-09-10 14:58:59

呵呵,在bj大神的世界里b树是二叉树

梦巷 2022-09-10 14:08:55

。。。。。。。。。。。。头一次看见人说b数是2叉数。。。。

请您去看下《算导》或者《数据库概论》吧

迷乱花海 2022-09-10 10:55:35

回复  peidright

    B树是二叉树。
bbjmmj 发表于 2010-07-17 20:34

    否! 是平衡树。

生生漫 2022-09-09 22:18:13

回复 6# peidright

    B树是二叉树。

月朦胧 2022-09-09 19:29:01

本帖最后由 peidright 于 2010-07-17 13:27 编辑

回复 5# bbjmmj

    B树的深度,一般是3,4。每层 256 叉。

256 * 256 *256 * 256 = 2^32  40 亿文件,能否说下,30层,一般是怎么来的? 有具体的实现么?每层2 叉的B树? 2^32 也有40亿了。

夜访吸血鬼 2022-09-09 17:32:16

回复 4# peidright

    第一点是根基问题,大问题啊,现在的分布式文件系统,检索都用B树了。B树是可以存到硬盘上的,因为遍历深度相当有限。比如说10亿个文件,如果用B树的话,遍历深度大约是30,而如果用MFS的HASH树,平均遍历深度将达到10亿/65536。
   关于第二点,NAS上存储的文件,平均大小远低于32M,连1M都不到。MFS比较适合存一些大的文件,大表、什么的。

过期以后 2022-09-09 16:42:43

回复 3# bbjmmj

    第一点感觉不是问题, 部分放在磁盘就行了。相信mfs可以改进

    第二点, 拿web应用感觉不太合适。。平均假设的文件,至少在32M的话, 1PB, 32*1024*1024  个chunk.   管理每个chunk占用内存10K字节的话,估算是 3G内存。

    拿dfs 存小文件的决策人员,智商都是非常shit.  集中元数据管理的模型,可能有问题,但是问题并没有那么严重,即使是单Master+standby。。

    上面我的估计也是粗略算的,没任何实际依据, 但是感觉上是多算了的。 能否说说你具体1T内存,是如何估计出来的?

天暗了我发光 2022-09-09 07:36:00

1.MFS 排序用来干嘛的? 所有chunk 索引都放在内存中?
2.MFS MFS对内存容量要求非常大, PB级别的,要消耗 ...
peidright 发表于 2010-07-17 10:11

    1、有点类似在多个硬盘上找某一个文件,文件位置的索引就是LINUX的目录文件,当目录较多,且深度较大时,查找文件就会相当耗时。MFS的做法相当于把所有目录结构都事先读到内存里去,进行HASH排序,虽然排序后索引深度增加,但因为都是在内存里,速度可以比存储在硬盘上快得多。大概就是这么个意思。
   2、MFS对内存容量的需求我曾经用我自己的土办法做过估算,我怀疑我的估算是错误的,因为没人去做这个估算,所以我就假定我估算的结果是错的,然后我去打听一些稍大型的生产系统,几十TB容量的,得到的结果却跟我用土办法估算出来的结果一样,于是大概推算出对于WEB类型的应用,1PB的MFS存储,MATASERVER大概需要1TB内存。我的测试办法是改变MFS文件系统文件数量,然后观察内存占用的变化,做测试用了上百万个文件。当然,科学的做法应该是对源码进行分析。

紫罗兰の梦幻 2022-09-05 13:20:52

1.MFS 排序用来干嘛的? 所有chunk 索引都放在内存中?
2.MFS MFS对内存容量要求非常大, PB级别的,要消耗1TB内存,这点怎么推算出来的?
PB级别的4k小文件?

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文