從“軟體”到“服務“——【物件儲存】的發展歷程（上）

當我們有海量的資料需要儲存處理時，首先可能會想到的就是物件儲存和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或者雲虛擬機器，用物件儲存的上傳簽名機制來控制許可權，利用回撥機制來做控制面和資料面的互動。在這種情況下，對開源的儲存軟體需求就會越來越低。所以最近幾年儘管資料儲存量劇增，但在開源儲存上也少有新的軟體出現，選擇自建儲存系統的公司比例也越來越低。

小結：

在物件儲存大規模普及之前，大量的資料儲存和處理就已經存在。但這些方案大都專注於解決其中一類問題，缺少足夠的普適性。物件儲存出現後，很多解決方案已經在向物件儲存移植或者靠攏，那麼為什麼物件儲存能有這麼大的吸引力？物件儲存的優勢究竟在哪兒？如何用好物件儲存呢？

歡迎點選“ 京東雲 ”瞭解更多精彩內容

*文中圖片皆來源於網路*