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

随着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 -