线索丨小官

整理丨千山

数据大爆炸时代，传统的集中式存储已经很难满足大型应用的数据存储需求，分布式存储应运而生。其中，可供存储的网络服务甚多，阿里云OSS、七牛云、腾讯云等等，不过很多公司为了节约成本，更倾向于开源的分布式存储系统，诸如Ceph、GlusterFS、FastDFS之类。

放眼整个分布式存储江湖，整体呈现乱战之象。日前，技术交流群中的众多技术人员，就当前分布式存储系统尤其是分布式文件系统的发展展开了讨论，围绕其适用场景、选型要素、优劣对比等方面进行了深入分析。

“需求决定架构”

评价一个分布式存储系统是否优秀？你可以列举出很多标准，比如数据的存储方式、数据的读取速率、数据的安全机制。但归根结底，系统并非孤立存在，其选型主要还是取决于业务需求。

社群讨论中,【Signx】提到：“需求决定架构”。

【Default】也持有类似的观点：很多公司的存储架构其实是多种类型混合的，这是根据具体的业务场景、存储类型进行选择和适配的。比如，有的企业要存储大量非结构化数据，就可以直接选择云厂商的对象存储，一来省去了自建成本，二来无需考虑后端实现。不过，有的公司会有“上云容易下云难”的顾虑，如果在能力和成本允许范围内，自建系统也是一种选择。

在【洪强】看来，细分场景确定的话，技术方向就相对固定。就像数据库对应块存储、数据共享对应文件存储、应用集成对应对象存储。具体到实践中，很多厂商都会基于开源分布式存储系统做自研优化。

分布式文件系统的“争锋”

目前主流的分布式文件系统有：GFS、HDFS、Ceph、GlusterFS、MooseFS、FastDFS、Lustre、GridFS等。

1、GFS(Google File System)

这是谷歌为了满足自身需求而开发的基于Linux的专有分布式文件系统。尽管谷歌披露了部分技术细节，但并不开源，使用困难。

2、HDFS(Hadoop Distributed File System)

HDFS支持大数据批量读写，吞吐量高，一直以来都是大数据领域专属。不支持多用户并发写相同文件，而且只有 Java SDK成熟，用于通用业务开发肯定不方便。

Ceph是近几年最流行的分布式存储系统之一，具有高性能、高可靠性和高可扩展性，几乎成为OpenStack等知名开源云平台社区的标配存储系统。

4、GlusterFS

适用于数据密集型任务的开源分布式横向扩展文件系统，可以根据存储需求快速调配存储，内含丰富的自动故障转移功能，且摈弃集中元数据服务器的思想，采用堆栈式架构。

由波兰公司Gemius SA公司推出，比较轻量级，用perl编写，性能相对较差，最近几年发展不多。

由纯C语言开发的轻量级开源分布式文件系统，适合以文件为载体的在线服务。但不支持断点续传，不适合大文件存储。

一种平行分布式文件系统，通常用于大型计算机集群和超级电脑，自英特尔不再维护后由DDN接手。

属于MongoDB的一个内置功能，提供一组文件操作的API以利用MongoDB存储文件。

由此看来，分布式文件系统之丰富，已经到了“乱花渐欲迷人眼”的地步。那么，这些系统到底适合怎样的场景，使用体验到底如何？且看开发者们如是说。

面向Ceph

其评价主要集中于三点：

适用场景：适合非结构化数据存储，其对象存储特性适合云计算环境实时访问的虚拟机镜像和虚拟机磁盘。

集成：使用存储设施提供的直接API访问写入存储，对Winows和Linux都非常友好。

扩展：可以轻松将新存储设备集成到现有存储产品中来满足扩容需求。

当然其缺点也非常鲜明：

1、 代码 质量。这实际上是个见仁见智的问题，但Ceph发展至今的确已经背负了过重的历史包袱。

2、 扩容 过程并不完美，实际扩容时，服务质量会受严重制约。

3、有些浪费硬件， 成本 核算时要考虑更多。

4、去中心化设计牺牲了不少元数据，比如lastacesstime，给未来的 数据治理 带来了压力。

5、 运维门槛 较高，没有丰富的分布式系统和存储系统运维经验的业务开发者很难搞定。

面向GlusterFS

技术人员的评价同样有褒有贬。优点包括：

适用场景 ：适合结构化数据，采用传统的树形文件系统，适宜海量大文件存储以及流式数据顺序读写，尤其适用于近线存储、数据归档环境。

集成 ：遵守POSIX便携式操作系统接口标准，对Linux特别友好。但如果要和Windows环境集成，需要额外步骤。

扩展 ：具有很好的可扩展性。软件的结构设计良好，易于扩展和配置，通过各个模块的灵活搭配以得到针对性的解决方案。

而GlusterFS的缺点，除了公认的“对于小文件的存储效率和访问性能都表现不佳”这一点外，【接地气的小虾米】进行了集中吐槽：

1、由于没有元数据服务器，其访问控制、信息统计的实现都特别复杂。

2、有副本的模式下，写的性能会下降为单副本的N倍（N=副本因子），因为它是完全同步写N份数据的。

3、压力比较大的时候，ls会非常之慢，难以忍受。原因是它在客户端没有文件信息的缓存，每次都要去遍历brick。如果brick有几百个，其速度之慢可以想象，所以其宣称的线性扩展性要大打折扣。当然如果知道文件名，直接访问则另当别论。

4、存在一些明显的bug没有修复。比如AFR副本，许多读操作基本上也都是落在一个上，根本无法实现其宣称的副本能够提高读性能；对于stripe模式，多次测试也没有发现具有提高性能的作用，干脆放弃不用。

面向FastDFS

大家的使用体验也不尽相同。

【自由】提到，在金融场景中选择FastDFS，主要用于存储中小文件以及照片。原因在于：

有主备Tracker服务，提高了系统的可用性。

支持在线扩容机制。这一点非常实用，一旦使用的内存不够，可以不停机在线扩容，降低了特殊情况下对于业务系统的影响。

实现了软RAID，增强了系统的并发处理能力和数据容错恢复能力。

其缺点则主要集中在以下几点：

1、通过API下载，存在单点的性能瓶颈。

2、不支持断点续传，对大文件是噩梦。

3、同步机制不支持文件正确性校验，降低了系统的可用性。

4、不支持POSIX通用接口访问，通用性较低。

5、对跨公网的文件同步存在着比较大的延迟，需要应用做相应的容错策略。

综上所述，正如有的开发人员所说，技术本身没有绝对的好坏。但在特定的场景下，技术的适配与否是有评判标准的。“因为在场景下，你有了立场，就有了亟待解决的问题的优先级，也就一定能按优先级选择出最适合你的技术。”

前浪未死，后浪已来

在分布式文件系统的选型中，我们已经可以梳理出一些基本的思路。比如根据特性，

适合做通用文件系统的有：Ceph，Lustre……

适合做小文件存储的文件系统有：Ceph，MooseFS，FastDFS……

适合做大文件存储的文件系统有：HDFS，Ceph，Lustre，GridFS……

简单易用的文件系统有：MooseFS，FastDFS，GlusterFS……

不过稍加回顾，可以发现，像 GlusterFS、CephFS、HDFS、MooseFS、Lustre这些项目都是在2010年之前出现的，距今都有十多年的发展史了。在日新月异的技术更迭中，它们有的再度火起，有的一时沉寂。

随着云原生时代的到来，近几年，分布式存储系统领域又涌现出了若干新秀：为云环境设计，兼容 POSIX、HDFS和S3协议的JuiceFS；由OPPO主导开发与运营的开源云原生存储产品CubeFS……前浪未死，后浪已来。分布式存储的江湖中，老将与老将的交锋锋芒毕露，新秀与老将的博弈暗流汹涌，几方割据的态势也将长期存在。谁主沉浮，我们或可静心以待。