線索丨小官

       整理丨千山

　　數據大爆炸時代，傳統的集中式存儲已經很難滿足大型應用的數據存儲需求，分布式存儲應運而生。其中，可供存儲的網絡服務甚多，阿里云OSS、七牛云、騰訊云等等，不過很多公司為了節約成本，更傾向于開源的分布式存儲系統，諸如Ceph、GlusterFS、FastDFS之類。

　　放眼整個分布式存儲江湖，整體呈現亂戰之象。日前，51CTO技術交流群中的眾多技術人員，就當前分布式存儲系統尤其是分布式文件系統的發展展開了討論，圍繞其適用場景、選型要素、優劣對比等方面進行了深入分析。

“需求決定架構”

　　評價一個分布式存儲系統是否優秀？你可以列舉出很多標準，比如數據的存儲方式、數據的讀取速率、數據的安全機制。但歸根結底，系統并非孤立存在，其選型主要還是取決于業務需求。

　　社群討論中,【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
成熟，用于通用業務開發肯定不方便。

　　3、Ceph

　　Ceph是近幾年最流行的分布式存儲系統之一，具有高性能、高可靠性和高可擴展性，幾乎成為OpenStack等知名開源云平臺社區的標配存儲系統。

　　4、GlusterFS

　　適用于數據密集型任務的開源分布式橫向擴展文件系統，可以根據存儲需求快速調配存儲，內含豐富的自動故障轉移功能，且擯棄集中元數據服務器的思想，采用堆棧式架構。

　　5、MooseFS

　　由波蘭公司Gemius SA公司推出，比較輕量級，用perl編寫，性能相對較差，最近幾年發展不多。

　　6、FastDFS

　　由純C語言開發的輕量級開源分布式文件系統，適合以文件為載體的在線服務。但不支持斷點續傳，不適合大文件存儲。

　　7、Lustre

　　一種平行分布式文件系統，通常用于大型計算機集群和超級電腦，自英特爾不再維護后由DDN接手。

　　8、GridFS

　　屬于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、對跨公網的文件同步存在著比較大的延遲，需要應用做相應的容錯策略。

　　綜上所述，正如有的開發人員所說，技術本身沒有絕對的好壞。但在特定的場景下，技術的適配與否是有評判標準的?！耙驗樵趫鼍跋?，你有了立場，就有了亟待解決的問題的優先級，也就一定能按優先級選擇出最適合你的技術?！?/p>

前浪未死，后浪已來

　　在分布式文件系統的選型中，我們已經可以梳理出一些基本的思路。比如根據特性，

　　適合做通用文件系統的有：Ceph，Lustre……

　　適合做小文件存儲的文件系統有：Ceph，MooseFS，FastDFS……

　　適合做大文件存儲的文件系統有：HDFS，Ceph，Lustre，GridFS……

　　簡單易用的文件系統有：MooseFS，FastDFS，GlusterFS……

      不過稍加回顧，可以發現，像 GlusterFS、CephFS、HDFS、MooseFS、Lustre這些項目都是在2010年之前出現的，距今都有十多年的發展史了。在日新月異的技術更迭中，它們有的再度火起，有的一時沉寂。

      隨著云原生時代的到來，近幾年，分布式存儲系統領域又涌現出了若干新秀：為云環境設計，兼容 POSIX、HDFS和S3協議的JuiceFS；由OPPO主導開發與運營的開源云原生存儲產品CubeFS……前浪未死，后浪已來。分布式存儲的江湖中，老將與老將的交鋒鋒芒畢露，新秀與老將的博弈暗流洶涌，幾方割據的態勢也將長期存在。誰主沉浮，我們或可靜心以待。

?

參考鏈接：https://www.zhihu.com/question/435267324