>其它>>正文

大师问答|亿级海量小文件存储,上千个节点整合能很好实现么?

原标题:大师问答|亿级海量小文件存储,上千个节点整合能很好实现么?

【问】:亿级海量小文件存储,上千个节点整合能很好实现么?每个文件大小约64k,在一个共享文件夹里面50亿个文件,这能跑下去嘛?将1024个node整合在一起,对于这种场景会有效吗?

【大师】:这明显是一个关于亿级海量小文件存储,上千个节点整合能不能很好实现的问题。

传统厂商的设备,还真没见过哪个客户1024个node的存储。现在,互联网公司一定会这么干吧,很多需求是说要实现比较大范围的data sharing,而且这种sharing是无计划,无安排的。

假设一台假设60TB空间,一个chunk假设2M,一台就需要3千万个,一百万就是30万亿个对象,如果再计算其他的关系,很轻松就突破到千万亿这个级别,这个级别下,不管你增加hash的长度,还是用嵌套,计算量都太大了些。其实,首先不够的应该是内存。

需要明白的:传统hash上千节点,64k chunk size应该还是ok的,两层哈希表嵌套一下,256字长,到万就不够用了。

100T肯定是够的,主要是文件数是不是支持了。但是,基于凭证的访问不是这么实现的,会给你生成一个逻辑上的数据视图沙盒之类。针对NFS或者SMB,这个要看文件系统的设计,metadata搞不搞得定这么多inode。虽然50亿这个两基,islon还是可以跑下去的,但是你通过SMB或者NFS自己search起来有点费劲。

因为到了亿这个单位,瓶颈首先在你自己的search处理,其次才考虑后台系统。然而文件索引信息,存储端有独立的空间才对,不然,这瓶颈。

所以1024个node,整合在一起,对于这种场景没效,还是看metadata设计zookeeper估计悬,集中式看优化。另外,还要看业务。

不管是NFS还是SMB,标准client协议本身就不是为这个量级设计的,举个简单的例子,标准client会很傻的去把inode信息buffer在client本地,这个对于范围搜索就是灾难了。这也解决不了1024个节点整合在一起的问题。

脱离业务需求讨论这个没啥意义,是这么个道理,所以,ls(ls这个参数是字母L的小写,不是数字1,属于linux下的ls命令)一条指令下去,会卡住。而我遇到过的说法,Isilon跑这样的数据不会卡,很流畅,不知道怎么实现的。

你在一个NFS标准client端上对一个1亿文件的空间做ls都会卡,不管谁都一样,Isilon的区别在于你不会卡在server端。因而,Isilon的技术本质在于如果你去访问一个几十亿文件里的一个子集,不会卡。如果你做ls,不卡才怪。Isilon设计也不是给这个场景用的。事实上,Isilon在广电行业应用得很好,很多人访问同一个影片视频大文件,要求带宽很高,但文件数不多。

对于应用需要给单个卷(容量为70T)存放约30-40亿个文件,是否可以,是否有潜在风险或影响?

文件系统领域的大佬们,所以早年间人家自己定位为集群NAS,问题是这么个数量的文件需求,没性能问题,谁都不信。或许对于这个需求,你让他上mangoDB吧。

不过单个卷70亿文件,这是拍脑袋想的吗?还针对的是文件系统?不读不写不查询了?只能说写需求的人对文件数量增长的压力一无所知。即便这样,eap行业基本都这么用。然而,对于IoT就直接搞对象算了,这么投入没必要。

为此,我们也看到单一命名空间的价值所在,基本都是一个命名空间,后面多个子集然而。在半导体、汽车制造、保险、互联网金融和某些银行,这种需求都非常常见。初步感觉是他们当初系统上线,都没考虑过海量数据的优化设计。容量从9T增长起来,后面遭遇海量数据暴增,设计不够,规划来凑,于是导入存储新思维:上全闪存存储吧。

对于这样的应用方式,假如采用18*18的目录嵌套,然后做ls,基本上敲完就可以回家睡觉了,第二天过来看输出结果。

不过,即使单卷,你肯定也需要做好目录规划。所谓单卷更多是为了存储上的管理考虑需要,比如快照或者备份。

以前研究过scaleIO,记得官方号称能到1024个节点,不知道是不是分层的结构,还是一个扁平的单层结构?当时觉得scaleIO已经很牛了,vsan才64个节点。然而,vsan要处理的问题比scaleIO要复杂得多,scaleIO是裸设备(raw device),不需要分层。

本次答疑:黄昆、何庆、雪飞、马总mushroom

对此,你怎么看?

欢迎提问返回搜狐,查看更多

责任编辑:

声明:该文观点仅代表作者本人,搜狐号系信息发布平台,搜狐仅提供信息存储空间服务。
阅读 ()
投诉
推荐阅读
免费获取
今日搜狐热点
今日推荐