搜索 | 会员  
海量小文件的开源存储方案选型建议
来源: 杉岩数据   作者:邱尚高  日期:2018-3-14  类别:大数据  主题:Hadoop  编辑:Barbara
HDFS缺乏多租户、纠删码(据称2017年底特性提供,但稳定性待验证)、配额管理、数据快照、跨数据中心容灾等重要的存储特性,无法作为一个普适性的企业存储使用,仅适合专用于大数据分析存储。

HDFS


HDFS是Hadoop底层的分布式存储系统,NameNode负责文件元数据管理和文件分布管理,DataNode负责文件数据分片的存储。文件按照固定大小切片(4MB)存储,NameNode负责每个数据切片的分配和位置管理。


HDFS在存储容量上可以很好地满足扩展性需求,对于语音或者视频等较大的文件存储也可以满足性能要求。但所有文件的访问均需要通过NameNode进行查询,对于海量小图片场景,由于NameNode需要记录大量的数据存储信息,NameNode将成为整个系统的瓶颈。


HDFS设计之初完全是为了Hadoop大数据分析使用,并不是作为一个独立的存储系统考虑,所以HDFS无法脱离Hadoop环境单独部署。接口上也采用了私有的接口设计,不具备通用性和标准性,未来商业产品支持HDFS接口作为存储的可能性非常小。


HDFS缺乏多租户、纠删码(据称2017年底特性提供,但稳定性待验证)、配额管理、数据快照、跨数据中心容灾等重要的存储特性,无法作为一个普适性的企业存储使用,仅适合专用于大数据分析存储。


FastDFS


FastDFS是另一个开源分布式文件系统,由Tracker Server和Storage Server构成,Tracker Storage分成多个Group,每个Group有2-3台服务器,数据在一个Group的服务器之间做冗余策略。数据上传时,Tracker Server将整个文件分配存储到某个Group上,并返回一个文件UUID,UUID中包含了Group ID。下次访问时无需通过元数据查找,直接通过文件UUID中的Group ID,在Group内进行访问,从而加快了小文件的索引效率,所以FastDFS的小文件性能比较高。


FastDFS设计依赖于固定机制,如副本依赖于Group的机器数量,文件索引依赖于文件UUID规则,虽然巧妙,但也导致了不少固有的问题,包括副本数量的调整困难且不支持纠删码。文件的访问严重依赖外部数据库,离开外部数据的记录,文件无法按照原来名称获取,与其他存储兼容性相比较差。接口上也采用了私有的接口设计,不具备通用性和标准性,在企业中缺乏周边工具和应用软件的支持。


在数据安全性方面,FastDFS采用异步复制方式,写完一份数据后直接返回,然后再异步复制成2~3份,在过程中存在数据丢失风险。跟HDFS一样,同样也缺乏多租户隔离、配额管理、数据快照、跨数据中心容灾等重要的企业特性,适用于单一应用场景。


FastDFS还有一个风险,社区活跃度较低,出现问题能够获得的支持和文档非常少,不利于后期维护和管理。优势是FastDFS由于采用固定策略方式,维护相对简单。


 


GlusterFS


GlusterFS相对来说是应用得比较多的一款分布式文件系统,而且GlusterFS做到了真正的POSIX兼容文件接口,应用程序从传统NAS无需做任何改造就可以使用,这是较多用户尝试使用GlusterFS的原因。


GlusterFS采用分布式哈希表来实现一级元数据定位,即通过目录+文件名字符串计算一个Hash值,再通过查哈希表确定文件所在的服务器和磁盘,小文件的性能相比HDFS或者传统NAS的B+树查找方式效率要高很多。


但是由于GlusterFS受制于标准POSIX文件协议要求,还是会影响到小文件的性能,比如访问一个较长的路径、每一级解析查询都会由FUSE客户端发起一次查询,才能到最终文件访问。同时,GlusterFS在磁盘文件系统层面没有太多优化,当小文件数量过多时,本地文件系统的性能也会出现问题。此外,GlusterFS缺乏较多的企业存储特性,包括多租户、跨数据中心容灾等重要企业特性。

 


CephFS 文件系统


CephFS采用动态平衡子树技术,将文件系统的B+树做成分布式架构,从而解决传统NAS元数据查找问题,技术上是相对比较先进,但因为技术复杂度较大,到目前还没有商用案例,不建议企业用户使用。

image.png

Ceph RGW 对象存储


Ceph RGW是采用对象接口方式实现文件存储功能,采用DHT(动态哈希表)技术来实现第一级的文件定位,即Bucket+文件名字符串计算一个Hash值,再通过查DHT表确定文件所在的服务器和磁盘,小文件性能相比HDFS或者传统NAS的B+树查找方式高效很多。而且RGW的对象存储不受制于POSIX接口协议,目录也采用二级扁平方式,文件目录层次不影响文件访问性能。不过在磁盘层面,由于没有做特殊的优化,单盘文件数量过多时,性能也会出现一定程度下降,方案上可以考虑适当使用小容量的磁盘缓解该问题。


在文件接口协议上,RGW采用S3协议,虽然该协议在企业相对比较新,但该协议已经成为对象存储的事实标准,互联网行业基本都兼容该协议,企业软件也开始逐步接受并兼容,如容灾、备份、Hadoop、企业网盘等常用企业工具都已支持S3协议,围绕该协议的生态逐渐成熟,在可预见的未来,S3将成为企业存储的标准协议之一。


Ceph对象存储支持多租户、文件多版本、纠删码、跨数据中心容灾等高级特性,功能相对其他开源软件特性完善很多。但是Ceph比较复杂,代码量相对其他开源产品大很多,维护难度相对较大,而且开源产品都缺乏企业级的管理功能,虽然也提供了UI界面,但主要还是以监控为主,一旦出现硬件故障需要维护,都需要通过命令行操作。

 


综述


总的来说,开源的GlusterFS和Ceph RGW是两种相对不错的小文件解决方案,但由于在本地文件系统上优化不足,文件数量过多时性能还是有所欠缺。


GlusterFS由于POSIX文件协议限制,在文件数量增多和目录层级变深的情况下性能上相对Ceph RGW要差一些。同时,GlusterFS的功能特性相比Ceph RGW少了很多,包括纠删、多租户、容灾特性没有实现或者不可商用。而GlusterFS相对Ceph RGW的优势主要是采用标准POSIX接口,通用性更强。


两个开源项目都缺乏好的运维管理系统,包括对磁盘和网络的监控、故障管理,界面基本只提供监控功能,缺乏运维操作能力,如更换磁盘基本都需要通过命令行维护,对运维能力要求比较高。


德仔网尊重行业规范,每篇文章都注明有明确的作者和来源;德仔网的原创文章,请转载时务必注明文章作者和来源:德仔网;
头条那些事
大家在关注
广告那些事
我们的推荐
也许感兴趣的
干货
了解一下吧