資訊專欄INFORMATION COLUMN
摘要：現(xiàn)在還有一種趨勢，就是直接在對象存儲上跑等工具，不再依賴于。小結在對象存儲大規(guī)模普及之前，大量的數(shù)據(jù)存儲和處理就已經(jīng)存在。
導語
據(jù)IDC的分析師預測，2025年，全球范圍內(nèi)的數(shù)據(jù)量將增長到163 ZB，相較于2016年的16.1 ZB，十年間將增長1000%。面對飛速增長的數(shù)據(jù)量，企業(yè)和機構在未來又將如何存儲這些數(shù)據(jù)呢？
本文今天將與大家一起分享、探討對象存儲的進化及發(fā)展歷程。
當我們有海量的數(shù)據(jù)需要存儲處理時，首先可能會想到的就是對象存儲和Hadoop的HDFS?，F(xiàn)在還有一種趨勢，就是直接在對象存儲上跑 MapReduce、Spark 等工具，不再依賴于HDFS。
其實在對象存儲出現(xiàn)之前，也會遇到海量數(shù)據(jù)存儲的問題，那么隨著數(shù)據(jù)量的不斷增長，存儲技術又發(fā)生著怎么樣的變化呢？
讓我們從不同維度來進行分析。
科學計算領域：glusterfs, lustre, GPFS在2000年之前，也就是互聯(lián)網(wǎng)還沒有真正意義上的大規(guī)模崛起時，科學計算應該算是當時真正的大規(guī)模存儲玩家。在蛋白質模擬、計算化學這類的科學計算領域，它們只消耗計算，對存儲的需求不高。 但在氣象預測、天文等領域，由于數(shù)據(jù)采集量巨大，因此也有著大規(guī)模存儲的需求。撇開專有的存儲系統(tǒng)來看，glusterfs、lustre、以及IBM的GPFS(Spectrum Scale) 算是在這個領域的佼佼者，但這些跟后面我們看到的其他存儲系統(tǒng)有很大不同的是，這些系統(tǒng)都支持 POSIX 文件系統(tǒng)，方便原有的程序從本地文件系統(tǒng)平滑遷移到分布式文件系統(tǒng)。
但也正是因為需要支持 POSIX 文件系統(tǒng)，這類系統(tǒng)的基礎性能會出現(xiàn)一定的問題。比如 glusterfs對于小文件、qps的損失就比較大。除此之外，還經(jīng)常受到文件系統(tǒng)本身各種限制的影響，比如：單一目錄下文件的數(shù)目不能太多，深層次目錄尋址很慢等。
大數(shù)據(jù)領域：GFS, HDFS2003年Google發(fā)表了 GFS 論文, 2004 年發(fā)表了 MapReduce 論文。分別解決了Google搜索業(yè)務遇到的大規(guī)模的存儲和計算問題。業(yè)界很快就認識到了這個方法在解決大數(shù)據(jù)問題上的重要性和通用性，2006年就誕生了 Hadoop 項目，并隨后衍生了 HBase, HIVE, Pig等Hadoop生態(tài)項目。
Hadoop的底層存儲引擎叫HDFS，HDFS 在設計時充分考慮了離線大文件的存儲問題，但對于小文件存儲，NameNode 容易出現(xiàn)過載的情況。不過對于這個問題也可以有一些變通解決方案，比如把數(shù)據(jù)存在HBase而不是Hadoop中，或者把小文件拼成大文件，大文件存在HDFS，然后把對應的元信息存在HBase里。
上面的變通方法能改善小文件的存儲問題，但由于遠離了 Hadoop 本身的設計目標，所以還是會被其他問題所限制。除小文件之外，早期Hadoop對于在線應用的支持也是遠遠不足的，比如數(shù)據(jù)遷移時會有可用性問題；HBase的數(shù)據(jù)在數(shù)據(jù)片切分和合并時也有可用性問題；NameNode 更改時主從是異步更改的，在主節(jié)點出故障時甚至有丟失數(shù)據(jù)的風險。
Hadoop 整個生態(tài)，由于自身的設計目標問題，所以很少有人用它來替代對象存儲，反而是對象存儲本身在逐步考慮支持 HDFS 協(xié)議，簡化Hadoop生態(tài)的存儲形態(tài)。
圖片存儲: Mogilefs, GridFS, FastDFS從Web 1.0 時代開始圖片存儲的問題就已經(jīng)存在了，內(nèi)容網(wǎng)站需要圖片、論壇/BBS需要支持附件。而這些存儲問題的最早方案就是用服務器的文件系統(tǒng)來直接存儲，再加上合理的備份機制來防止文件丟失。
隨著互聯(lián)網(wǎng)的進一步發(fā)展，網(wǎng)站圖片等富媒體的容量快速從TB級增加到PB甚至幾十PB的級別。在這種情況下，傳統(tǒng)的圖片存儲方式，不管是可用性、修復成本、還是管理復雜度等問題都無法很好地得到解決。
MogileFS
MogileFS 算是第一個被廣泛使用的圖片存儲系統(tǒng)，曾有報道稱豆瓣、大眾點評、花瓣等網(wǎng)站都曾經(jīng)用過 MogileFS 來存儲自己的圖片。但MogileFS 的性能受制于核心數(shù)據(jù)庫，所以很快又出現(xiàn)了 FastDFS 這類的存儲系統(tǒng)，把大量的元信息存儲在圖片的key(也可以認為是URL)中，大幅度降低了對中心數(shù)據(jù)庫的壓力。
GridFS
在圖片存儲領域有一個不太成功但卻值得一提的軟件：GridFS。隨著4square等網(wǎng)站的崛起，用于支撐這類網(wǎng)站的MongoDB數(shù)據(jù)庫也大紅大紫。MongoDB提供了一個GridFS，本意是用來解決少量大于數(shù)據(jù)庫限制的文檔存儲問題，結果卻有不少人用它來解決圖片存儲的問題。
這一做法在低壓力下還算可用，但在壓力稍高的情況下時，就會遇到主從同步速率不足導致主從同步失敗，以及在分布式系統(tǒng)中寫入壓力嚴重不均等，高壓力下自動擴容困難等問題。MongoDB本身的目標不在于提供文件存儲，所以對 GridFS 的這些問題并不在意。只不過很多網(wǎng)站因為選型錯誤，在發(fā)展道路上走了不必要的彎路。
圖片存儲引擎中，mogilefs有嚴重的性能瓶頸，F(xiàn)astDFS 又無法指定 key 來存儲，再加上大量的互聯(lián)網(wǎng)應用，已經(jīng)能很好地實現(xiàn)控制流與數(shù)據(jù)流分離，即所有圖片等富媒體的上傳下載直接走云上的對象存儲服務，而控制流的部分繼續(xù)用自建IDC或者云虛擬機，用對象存儲的上傳簽名機制來控制權限，利用回調機制來做控制面和數(shù)據(jù)面的互動。在這種情況下，對開源的存儲軟件需求就會越來越低。所以最近幾年盡管數(shù)據(jù)存儲量劇增，但在開源存儲上也少有新的軟件出現(xiàn)，選擇自建存儲系統(tǒng)的公司比例也越來越低。
小結：在對象存儲大規(guī)模普及之前，大量的數(shù)據(jù)存儲和處理就已經(jīng)存在。但這些方案大都專注于解決其中一類問題，缺少足夠的普適性。對象存儲出現(xiàn)后，很多解決方案已經(jīng)在向對象存儲移植或者靠攏，那么為什么對象存儲能有這么大的吸引力？對象存儲的優(yōu)勢究竟在哪兒？如何用好對象存儲呢？
我們下期文章再詳細解讀！
文章版權歸作者所有，未經(jīng)允許請勿轉載,若此文章存在違規(guī)行為，您可以聯(lián)系管理員刪除。
轉載請注明本文地址：http://www.ezyhdfw.cn/yun/25486.html
摘要：導語在從軟件到服務對象存儲的發(fā)展歷程上中，我們和大家在對象存儲大規(guī)模普及之前，大量的數(shù)據(jù)存儲和處理是怎么實現(xiàn)的。推薦閱讀從軟件到服務對象存儲的發(fā)展歷程上免費試用點擊免費試用免費領取京東云對象存儲額度 導語 在《從軟件到服務——【對象存儲】的發(fā)展歷程（上）》中，我們和大家在對象存儲大規(guī)模普及之前，大量的數(shù)據(jù)存儲和處理是怎么實現(xiàn)的。但這些方案大都專注于解決其中一類問題，缺少足夠的普適性。那...
摘要：使用反向代理和加速網(wǎng)站響應在性能權威指南中有講到，網(wǎng)站性能的瓶頸，大部分時間都浪費在的握手和傳輸上。因此可以通過和反向代理的方式來加快響應。分布式數(shù)據(jù)庫是數(shù)據(jù)庫拆分的最后手段，只用在單表數(shù)據(jù)規(guī)模特別龐大的時候才使用。 前幾天跟一個朋友聊了一些關于網(wǎng)站緩存分布式的一些東西，發(fā)現(xiàn)自己的知識還是太過貧瘠。理論+協(xié)議，這是現(xiàn)在我亟待加強的。這個周末買了兩本關于分布式網(wǎng)站的書，本著好記性不如爛筆...
摘要：阿里巴巴的共享服務理念以及企業(yè)級互聯(lián)網(wǎng)架構建設的思路，給這些企業(yè)帶來了不少新的思路，這也是我最終決定寫這本書的最主要原因。盡在雙阿里巴巴技術演進與超越是迄今唯一由阿里巴巴集團官方出品全面闡述雙八年以來在技術和商業(yè)上演進和創(chuàng)新歷程的書籍。 showImg(https://segmentfault.com/img/remote/1460000015386860); 1、大型網(wǎng)站技術架構：核...
摘要：服務提供方對外發(fā)布服務，服務需求方調用服務提供方所發(fā)布的服務。應用服務器通過統(tǒng)一數(shù)據(jù)訪問模塊訪問各種數(shù)據(jù)，減輕應用程序管理諸多數(shù)據(jù)源的麻煩。 原文地址：https://blog.coding.net/blog/General-architecture-for-Java-applications 當我們架設一個系統(tǒng)的時候通常需要考慮到如何與其他系統(tǒng)交互，所以我們首先需要知道各種系統(tǒng)之間是...
閱讀 3841·2023-04-26 02:07
閱讀 3289·2021-09-22 15:55
閱讀 2608·2021-07-26 23:38
閱讀 3207·2019-08-29 15:16
閱讀 2067·2019-08-29 11:16
閱讀 1828·2019-08-29 11:00
閱讀 3714·2019-08-26 18:36
閱讀 3230·2019-08-26 13:32
