海量小文件的开源存储方案选型建议

随着AI技术的发展,在智能安防、智能制造等众多领域,都面临着海量图片文件的存储问题。开源领域为了解决海量小文件问题也是伤透了脑筋,这些年冒出了大量的开源分布式存储方案,都号称自己可以解决海量文件问题。结果就是不少企业用户贸然上线,刚开始数据量不大好像还不错,一旦数据量上来,才发现真的只是“号称”。然后又尝试其他方案,而存储方案的更换并不容易,上百TB数据的迁移动辄数月、工程浩大。而各种开源方案之间又缺少必要的迁移手段,过程困难不必赘述,单说在迁移过程中数据是否会丢失都很难评估。

为帮助企业用户少走弯路,在这里我给大家介绍一下我所了解的几款开源分布式存储的优缺点,供参考。由于并不是每个开源系统都充分了解,最新的状态也不一定能实时跟进,不当之处还请多多指正。

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元数据查找问题,技术上是相对比较先进,但因为技术复杂度较大,到目前还没有商用案例,不建议企业用户使用。

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接口,通用性更强。

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

本文作者:邱尚高,杉岩数据CTO

IT从业10年,曾任华为高级研发工程师、高级研发经理,2009年参与华为第一代云平台产品研发,2011年担任华为对象存储技术研究项目经理,主导新一代对象存储技术方向,2014年作为联合创始人创立杉岩数据。

- 责任编辑:DAODAO -

- FIN -

  • 发表于:
  • 原文链接http://kuaibao.qq.com/s/20180309G138LX00?refer=cp_1026
  • 腾讯「云+社区」是腾讯内容开放平台帐号(企鹅号)传播渠道之一,根据《腾讯内容开放平台服务协议》转载发布内容。

扫码关注云+社区

领取腾讯云代金券