丨T群话 江湖乱战！散布式存储 谁是王者

线索丨小官

整顿丨千山

数据大爆炸时代，传统的集中式存储曾经很难满足大型运行的数据存储需求，散布式存储应运而生。其中，可供存储的网络服务甚多，阿里云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……前浪未死，后浪已来。散布式存储的江湖中，老将与老将的交锋怀才不遇，新秀与老将的博弈暗流汹涌，几方割据的态势也将常年存在。谁主沉浮，咱们或可静心以待。