從「軟件」到「服務「——【對象存儲】的發展歷程（上）

導語

據IDC的分析師預測，2025年，全球範圍內的數據量將增加到163 ZB，相較於2016年的16.1 ZB，十年間將增加1000%。面對飛速增加的數據量，企業和機構在將來又將如何存儲這些數據呢？

![在這裏插入圖片描述](

)

本文今天將與你們一塊兒分享、探討對象存儲的進化及發展歷程。

當咱們有海量的數據須要存儲處理時，首先可能會想到的就是對象存儲和Hadoop的HDFS。如今還有一種趨勢，就是直接在對象存儲上跑 MapReduce、Spark 等工具，再也不依賴於HDFS。

其實在對象存儲出現以前，也會遇到海量數據存儲的問題，那麼隨着數據量的不斷增加，存儲技術又發生着怎麼樣的變化呢？

讓咱們從不一樣維度來進行分析。

科學計算領域：glusterfs, lustre, GPFS

在2000年以前，也就是互聯網尚未真正意義上的大規模崛起時，科學計算應該算是當時真正的大規模存儲玩家。在蛋白質模擬、計算化學這類的科學計算領域，它們只消耗計算，對存儲的需求不高。 但在氣象預測、天文等領域，因爲數據採集量巨大，所以也有着大規模存儲的需求。撇開專有的存儲系統來看，glusterfs、lustre、以及IBM的GPFS(Spectrum Scale) 算是在這個領域的佼佼者，但這些跟後面咱們看到的其餘存儲系統有很大不一樣的是，這些系統都支持 POSIX 文件系統，方便原有的程序從本地文件系統平滑遷移到分佈式文件系統。

但也正是由於須要支持 POSIX 文件系統，這類系統的基礎性能會出現必定的問題。好比 glusterfs對於小文件、qps的損失就比較大。除此以外，還常常受到文件系統自己各類限制的影響，好比：單一目錄下文件的數目不能太多，深層次目錄尋址很慢等。

大數據領域：GFS, HDFS

2003年Google發表了 GFS 論文, 2004 年發表了 MapReduce 論文。分別解決了Google搜索業務遇到的大規模的存儲和計算問題。業界很快就認識到了這個方法在解決大數據問題上的重要性和通用性，2006年就誕生了 Hadoop 項目，並隨後衍生了 HBase, HIVE, Pig等Hadoop生態項目。

Hadoop的底層存儲引擎叫HDFS，HDFS 在設計時充分考慮了離線大文件的存儲問題，但對於小文件存儲，NameNode 容易出現過載的狀況。不過對於這個問題也能夠有一些變通解決方案，好比把數據存在HBase而不是Hadoop中，或者把小文件拼成大文件，大文件存在HDFS，而後把對應的元信息存在HBase裏。

上面的變通方法能改善小文件的存儲問題，但因爲遠離了 Hadoop 自己的設計目標，因此仍是會被其餘問題所限制。除小文件以外，早期Hadoop對於在線應用的支持也是遠遠不足的，好比數據遷移時會有可用性問題；HBase的數據在數據片切分和合並時也有可用性問題；NameNode 更改時主從是異步更改的，在主節點出故障時甚至有丟失數據的風險。

Hadoop 整個生態，因爲自身的設計目標問題，因此不多有人用它來替代對象存儲，反而是對象存儲自己在逐步考慮支持 HDFS 協議，簡化Hadoop生態的存儲形態。

圖片存儲: Mogilefs, GridFS, FastDFS

從Web 1.0 時代開始圖片存儲的問題就已經存在了，內容網站須要圖片、論壇/BBS須要支持附件。而這些存儲問題的最先方案就是用服務器的文件系統來直接存儲，再加上合理的備份機制來防止文件丟失。

隨着互聯網的進一步發展，網站圖片等富媒體的容量快速從TB級增長到PB甚至幾十PB的級別。在這種狀況下，傳統的圖片存儲方式，不論是可用性、修復成本、仍是管理複雜度等問題都沒法很好地獲得解決。

• MogileFS

MogileFS 算是第一個被普遍使用的圖片存儲系統，曾有報道稱豆瓣、大衆點評、花瓣等網站都曾經用過 MogileFS 來存儲本身的圖片。但MogileFS 的性能受制於核心數據庫，因此很快又出現了 FastDFS 這類的存儲系統，把大量的元信息存儲在圖片的key(也能夠認爲是URL)中，大幅度下降了對中心數據庫的壓力。
![在這裏插入圖片描述](

)

• GridFS

在圖片存儲領域有一個不太成功但卻值得一提的軟件：GridFS。隨着4square等網站的崛起，用於支撐這類網站的MongoDB數據庫也大紅大紫。MongoDB提供了一個GridFS，本意是用來解決少許大於數據庫限制的文檔存儲問題，結果卻有很多人用它來解決圖片存儲的問題。

這一作法在低壓力下還算可用，但在壓力稍高的狀況下時，就會遇到主從同步速率不足致使主從同步失敗，以及在分佈式系統中寫入壓力嚴重不均等，高壓力下自動擴容困難等問題。MongoDB自己的目標不在於提供文件存儲，因此對 GridFS 的這些問題並不在乎。只不過不少網站由於選型錯誤，在發展道路上走了沒必要要的彎路。

圖片存儲引擎中，mogilefs有嚴重的性能瓶頸，FastDFS 又沒法指定 key 來存儲，再加上大量的互聯網應用，已經能很好地實現控制流與數據流分離，即全部圖片等富媒體的上傳下載直接走雲上的對象存儲服務，而控制流的部分繼續用自建IDC或者雲虛擬機，用對象存儲的上傳簽名機制來控制權限，利用回調機制來作控制面和數據面的互動。在這種狀況下，對開源的存儲軟件需求就會愈來愈低。因此最近幾年儘管數據存儲量劇增，但在開源存儲上也少有新的軟件出現，選擇自建存儲系統的公司比例也愈來愈低。

小結：

在對象存儲大規模普及以前，大量的數據存儲和處理就已經存在。但這些方案大都專一於解決其中一類問題，缺乏足夠的普適性。對象存儲出現後，不少解決方案已經在向對象存儲移植或者靠攏，那麼爲何對象存儲能有這麼大的吸引力？對象存儲的優點究竟在哪兒？如何用好對象存儲呢？

咱們下期文章再詳細解讀！