資訊專欄INFORMATION COLUMN
摘要：現在還有一種趨勢，就是直接在對象存儲上跑等工具，不再依賴于。小結在對象存儲大規模普及之前，大量的數據存儲和處理就已經存在。
導語
據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, HDFS2003年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或者云虛擬機，用對象存儲的上傳簽名機制來控制權限，利用回調機制來做控制面和數據面的互動。在這種情況下，對開源的存儲軟件需求就會越來越低。所以最近幾年盡管數據存儲量劇增，但在開源存儲上也少有新的軟件出現，選擇自建存儲系統的公司比例也越來越低。
小結：在對象存儲大規模普及之前，大量的數據存儲和處理就已經存在。但這些方案大都專注于解決其中一類問題，缺少足夠的普適性。對象存儲出現后，很多解決方案已經在向對象存儲移植或者靠攏，那么為什么對象存儲能有這么大的吸引力？對象存儲的優勢究竟在哪兒？如何用好對象存儲呢？
我們下期文章再詳細解讀！
文章版權歸作者所有，未經允許請勿轉載,若此文章存在違規行為，您可以聯系管理員刪除。
轉載請注明本文地址：http://specialneedsforspecialkids.com/yun/25486.html
摘要：導語在從軟件到服務對象存儲的發展歷程上中，我們和大家在對象存儲大規模普及之前，大量的數據存儲和處理是怎么實現的。推薦閱讀從軟件到服務對象存儲的發展歷程上免費試用點擊免費試用免費領取京東云對象存儲額度 導語 在《從軟件到服務——【對象存儲】的發展歷程（上）》中，我們和大家在對象存儲大規模普及之前，大量的數據存儲和處理是怎么實現的。但這些方案大都專注于解決其中一類問題，缺少足夠的普適性。那...
摘要：使用反向代理和加速網站響應在性能權威指南中有講到，網站性能的瓶頸，大部分時間都浪費在的握手和傳輸上。因此可以通過和反向代理的方式來加快響應。分布式數據庫是數據庫拆分的最后手段，只用在單表數據規模特別龐大的時候才使用。 前幾天跟一個朋友聊了一些關于網站緩存分布式的一些東西，發現自己的知識還是太過貧瘠。理論+協議，這是現在我亟待加強的。這個周末買了兩本關于分布式網站的書，本著好記性不如爛筆...
摘要：阿里巴巴的共享服務理念以及企業級互聯網架構建設的思路，給這些企業帶來了不少新的思路，這也是我最終決定寫這本書的最主要原因。盡在雙阿里巴巴技術演進與超越是迄今唯一由阿里巴巴集團官方出品全面闡述雙八年以來在技術和商業上演進和創新歷程的書籍。 showImg(https://segmentfault.com/img/remote/1460000015386860); 1、大型網站技術架構：核...
摘要：服務提供方對外發布服務，服務需求方調用服務提供方所發布的服務。應用服務器通過統一數據訪問模塊訪問各種數據，減輕應用程序管理諸多數據源的麻煩。 原文地址：https://blog.coding.net/blog/General-architecture-for-Java-applications 當我們架設一個系統的時候通常需要考慮到如何與其他系統交互，所以我們首先需要知道各種系統之間是...
閱讀 3640·2023-04-26 02:07
閱讀 3150·2021-09-22 15:55
閱讀 2534·2021-07-26 23:38
閱讀 3119·2019-08-29 15:16
閱讀 2008·2019-08-29 11:16
閱讀 1746·2019-08-29 11:00
閱讀 3583·2019-08-26 18:36
閱讀 3165·2019-08-26 13:32
