如果我們?cè)诜?wù)端存儲(chǔ)文件，例如一個(gè)O2O應(yīng)用中的圖片或者企業(yè)級(jí)云盤里的文檔,，以前我們可能會(huì)毫不猶豫地把它們放到文件系統(tǒng)里,，比如說NAS或者一個(gè)分布式文件系統(tǒng)里，但是,，隨著技術(shù)的發(fā)展,，我們有了一個(gè)新的選擇——對(duì)象存儲(chǔ)，今天我們來討論一下,，對(duì)象存儲(chǔ)相對(duì)于文件系統(tǒng)有什么特點(diǎn),？什么時(shí)候我們應(yīng)該選擇對(duì)象存儲(chǔ)？文件系統(tǒng)將來的發(fā)展方向是什么,？

一,、對(duì)象存儲(chǔ)的概念

對(duì)象存儲(chǔ)和我們經(jīng)常接觸到的硬盤和文件系統(tǒng)等存儲(chǔ)形態(tài)不同，它提供Key-Value（簡(jiǎn)稱K/V）方式的RESTful數(shù)據(jù)讀寫接口,，并且常以網(wǎng)絡(luò)服務(wù)的形式提供數(shù)據(jù)的訪問,。

在早些年，特別是2006年以前,，人們提到對(duì)象存儲(chǔ),，往往指的是以類似標(biāo)準(zhǔn)化組織SNIA定義的OSD（object storage device）和MDS（Metadata Server）為基本組成部分的分布式存儲(chǔ)，通常是分布式文件系統(tǒng),。我們經(jīng)常聽到的分布式存儲(chǔ)Ceph的底層RADOS（Reliable Autonomous Distributed Object Store）,，即屬于這類對(duì)象存儲(chǔ)。

（圖片部分內(nèi)容引用自Ceph官網(wǎng)和SwiftStack官網(wǎng)）

而2006年以后,，人們說到對(duì)象存儲(chǔ),，往往指的是以AWS的S3為代表的，通過HTTP接口提供訪問的存儲(chǔ)服務(wù)或者存儲(chǔ)系統(tǒng),。類似的系統(tǒng)還有Rackspace于2009年開始研發(fā)并于2010年開源的OpenStack Swift（Rackspace的對(duì)象存儲(chǔ)服務(wù)開始于2008年,，但是Swift項(xiàng)目的開發(fā)是從2009年開始的，Rackspace用Swift項(xiàng)目對(duì)其云存儲(chǔ)系統(tǒng)進(jìn)行了徹底重構(gòu)）,。這里的“對(duì)象”（Object）和我們平時(shí)說的文件類似,，如果我們把一個(gè)文件傳到對(duì)象存儲(chǔ)系統(tǒng)里面存起來，就叫做一個(gè)對(duì)象,。

（圖片部分內(nèi)容引用自Ceph官網(wǎng)和SwiftStack）

從另一個(gè)角度來說,，2006年以前常說的對(duì)象存儲(chǔ)，指的是一種存儲(chǔ)系統(tǒng)的架構(gòu),；而2006年以后,，人們說到對(duì)象存儲(chǔ)常指的是一種存儲(chǔ)形態(tài)，我們這里討論的對(duì)象存儲(chǔ)也正是后者,。

目前,，對(duì)象存儲(chǔ)已經(jīng)得到了廣泛的應(yīng)用,。具有代表性的大規(guī)模實(shí)現(xiàn)主要在各個(gè)公有云服務(wù)商，比如AWS的S3,、Rackspace的CloudFiles，國(guó)內(nèi)的七牛云存儲(chǔ),、阿里云的開放存儲(chǔ)服務(wù)OSS也屬于對(duì)象存儲(chǔ),，最近，青云也發(fā)布了對(duì)象存儲(chǔ)服務(wù),。

對(duì)象存儲(chǔ)也有一些著名的開源實(shí)現(xiàn),，如OpenStack Swift，開源的統(tǒng)一存儲(chǔ)系統(tǒng)Ceph也可以通過Ceph Object Gateway提供對(duì)象存儲(chǔ)服務(wù),，也稱作RADOS Gateway,，縮寫為RADOSGW。

二,、對(duì)象存儲(chǔ)與文件系統(tǒng)的比較

與文件系統(tǒng)相比,，以AWS S3和Swift為代表的對(duì)象存儲(chǔ)有兩個(gè)顯著的特征——REST風(fēng)格的接口和扁平的數(shù)據(jù)組織結(jié)構(gòu)。

1.對(duì)象存儲(chǔ)的接口

對(duì)于大多數(shù)文件系統(tǒng)來說,，尤其是POSIX兼容的文件系統(tǒng),，提供open、close,、read,、write和lseek等接口。

而對(duì)象存儲(chǔ)的接口是REST風(fēng)格的,，通常是基于HTTP協(xié)議的RESTful Web API,，通過HTTP請(qǐng)求中的PUT和GET等操作進(jìn)行文件的上傳即寫入和下載即讀取，通過DELETE操作刪除文件,。

（圖片內(nèi)容來自SwiftStack）

對(duì)象存儲(chǔ)和文件系統(tǒng)在接口上的本質(zhì)區(qū)別是對(duì)象存儲(chǔ)不支持和fread和fwrite類似的隨機(jī)位置讀寫操作,，即一個(gè)文件PUT到對(duì)象存儲(chǔ)里以后，如果要讀取,，只能GET整個(gè)文件,，如果要修改一個(gè)對(duì)象，只能重新PUT一個(gè)新的到對(duì)象存儲(chǔ)里,，覆蓋之前的對(duì)象或者形成一個(gè)新的版本,。

如果結(jié)合平時(shí)使用云盤的經(jīng)驗(yàn)，就不難理解這個(gè)特點(diǎn)了,，用戶會(huì)上傳文件到云盤或者從云盤下載文件,。如果要修改一個(gè)文件，會(huì)把文件下載下來,，修改以后重新上傳,，替換之前的版本,。實(shí)際上幾乎所有的互聯(lián)網(wǎng)應(yīng)用，都是用這種存儲(chǔ)方式讀寫數(shù)據(jù)的,，比如微信,，在朋友圈里發(fā)照片是上傳圖像、收取別人發(fā)的照片是下載圖像,，也可以從朋友圈中刪除以前發(fā)送的內(nèi)容,；微博也是如此，通過微博API我們可以了解到,，微博客戶端的每一張圖片都是通過REST風(fēng)格的HTTP請(qǐng)求從服務(wù)端獲取的,，而我們要發(fā)微博的話，也是通過HTTP請(qǐng)求將數(shù)據(jù)包括圖片傳上去的,。在沒有對(duì)象存儲(chǔ)以前,，開發(fā)者需要自己為客戶端提供HTTP的數(shù)據(jù)讀寫接口，并通過程序代碼轉(zhuǎn)換為對(duì)文件系統(tǒng)的讀寫操作,。

能夠放棄隨機(jī)讀寫接口而采用REST接口的一個(gè)重要原因是計(jì)算機(jī)系統(tǒng)本身的演進(jìn)呼喚存儲(chǔ)系統(tǒng)的變革,，目前的計(jì)算機(jī)的內(nèi)存大小已經(jīng)和當(dāng)初設(shè)計(jì)POSIX文件系統(tǒng)接口時(shí)大不一樣了。文件系統(tǒng)誕生于1960年代,，當(dāng)時(shí)的內(nèi)存是以KB為單位的,，內(nèi)存資源非常寶貴，同時(shí)外存的數(shù)據(jù)讀寫速率也非常低,，所以把文件中的一小部分?jǐn)?shù)據(jù)加載進(jìn)內(nèi)存進(jìn)行操作顯得非常有必要,。而如今，計(jì)算機(jī)的內(nèi)存是以GB為單位的,，往往在幾十,、幾百GB量級(jí)，而常常需要存取的文件——如圖片,、文檔等,，則是在MB級(jí)別，GB以上的文件數(shù)量非常少（多為長(zhǎng)視頻,、歸檔文件,、虛擬機(jī)鏡像等，這一類數(shù)據(jù)我們會(huì)在本系列的后面幾篇中進(jìn)行討論）,，外存和網(wǎng)絡(luò)的吞吐率較之1960年代,，也有了數(shù)千倍的提升，把一個(gè)文件完全加載到內(nèi)存中進(jìn)行處理和可視化的已經(jīng)開銷微不足道了,，而帶來的計(jì)算效率和用戶體驗(yàn)的提升卻是顯著的,。

2. 扁平的數(shù)據(jù)組織結(jié)構(gòu)

對(duì)比文件系統(tǒng)，對(duì)象存儲(chǔ)的第二個(gè)特點(diǎn)是沒有嵌套的文件夾，而是采用扁平的數(shù)據(jù)組織結(jié)構(gòu),，往往是兩層或者三層,，例如AWS S3和華為的UDS，每個(gè)用戶可以把它的存儲(chǔ)空間劃分為“容器”（Bucket）,，然后往每個(gè)容器里放對(duì)象,，對(duì)象不能直接放到租戶的根存儲(chǔ)空間里，必須放到某個(gè)容器下面,，而不能嵌套,，也就是說，容器下面不能再放一層容器,，只能放對(duì)象。OpenStack Swift也類似

這就是所謂“扁平數(shù)據(jù)組織結(jié)構(gòu)”,，因?yàn)樗臀募A可以一級(jí)一級(jí)嵌套不同,，層次關(guān)系是固定的，而且只有兩到三級(jí),，是扁平的,。每一級(jí)的每個(gè)元素，例如S3中的某個(gè)容器或者某個(gè)對(duì)象,，在系統(tǒng)中都有唯一的標(biāo)識(shí),，用戶通過這個(gè)標(biāo)識(shí)來訪問容器或者對(duì)象，所以,，對(duì)象存儲(chǔ)提供的是一種K/V的訪問方式,。

（圖片內(nèi)容來自華為）

采用扁平的數(shù)據(jù)組織結(jié)構(gòu)拋棄了嵌套的文件夾，避免維護(hù)龐大的目錄樹,。隨著大數(shù)據(jù)和互聯(lián)網(wǎng)的發(fā)展,，如今的存儲(chǔ)系統(tǒng)中，動(dòng)輒數(shù)百萬,、千萬甚至上億個(gè)文件/對(duì)象,，單位時(shí)間內(nèi)的訪問次數(shù)和并發(fā)訪問量也達(dá)到了前所未有的量級(jí)，在這種情況下,，目錄樹會(huì)給存儲(chǔ)系統(tǒng)帶來很大的開銷和諸多問題,，成為系統(tǒng)的瓶頸。反觀目錄結(jié)構(gòu)的初衷——數(shù)據(jù)管理,，如今作用非常有限,，我們已經(jīng)很難通過目錄的劃分對(duì)文件進(jìn)行歸類和管理了，因?yàn)橐粋€(gè)文件最終只能放到一個(gè)文件夾下,，作為目錄樹的葉子節(jié)點(diǎn)存在,，而文件的屬性是多維度的。目前各類應(yīng)用中廣泛采用元數(shù)據(jù)檢索的方式進(jìn)行數(shù)據(jù)的管理,，通過對(duì)元數(shù)據(jù)的匹配得到一個(gè)Index或者Key,，再根據(jù)這個(gè)Index或者Key找到并讀取數(shù)據(jù),，所以，對(duì)象存儲(chǔ)的扁平數(shù)據(jù)組織形式和K/V訪問方式更能滿足數(shù)據(jù)管理的需求,。

不難看出,，對(duì)象存儲(chǔ)有著鮮明的互聯(lián)網(wǎng)和大數(shù)據(jù)時(shí)代的特點(diǎn)，隨著“互聯(lián)網(wǎng)+”的推進(jìn),，互聯(lián)網(wǎng)技術(shù)正在滲透到各行各業(yè),，數(shù)據(jù)量也在成指數(shù)倍數(shù)增長(zhǎng)，對(duì)象存儲(chǔ)將發(fā)揮越來越大的作用,。

三,、文件系統(tǒng)和對(duì)象存儲(chǔ)系統(tǒng)的優(yōu)劣和發(fā)展趨勢(shì)分析

上述分析了對(duì)象存儲(chǔ)的特點(diǎn)并與文件系統(tǒng)做了比較，接下來就不得不回答一個(gè)問題：文件系統(tǒng)是不是沒有生命力了,？答案當(dāng)然是否定的,。對(duì)象存儲(chǔ)打破了文件系統(tǒng)一統(tǒng)天下的局面，給我們帶來了更多的選擇,，并不意味著我們就要否定文件系統(tǒng),。

而對(duì)于一些場(chǎng)景，比如虛擬機(jī)活動(dòng)鏡像的存儲(chǔ),，或者說虛擬機(jī)硬盤文件的存儲(chǔ),，還有大數(shù)據(jù)處理等場(chǎng)景，對(duì)象存儲(chǔ)就顯得捉襟見肘了,。而文件系統(tǒng)在這些領(lǐng)域有突出的表現(xiàn),，比如Nutanix的NDFS（Nutanix Distributed Filesystem）和VMware的VMFS（VMware Filesystem）在虛擬機(jī)鏡像存儲(chǔ)方面表現(xiàn)很出色，Google文件系統(tǒng)GFS及其開源實(shí)現(xiàn)HDFS被廣泛用于支撐基于MapReduce模型的大數(shù)據(jù)處理支持得很好,，而且能夠很好地支持百GB級(jí),、TB級(jí)甚至更大文件的存儲(chǔ)。

由此看來文件系統(tǒng)將來的發(fā)展趨勢(shì)更多的是專用文件系統(tǒng),，而不再是以前一套Filesystem一統(tǒng)天下的做法,，更有一些部分要讓位于對(duì)象存儲(chǔ)或者其他存儲(chǔ)形態(tài)。

從另一個(gè)角度來看,，現(xiàn)代對(duì)象存儲(chǔ)系統(tǒng)的“甜區(qū)”在哪里：1. 互聯(lián)網(wǎng)和類似互聯(lián)網(wǎng)的應(yīng)用場(chǎng)景,，這不僅僅是因?yàn)镽EST風(fēng)格的HTTP的接口，而且還因?yàn)榇蠖鄶?shù)對(duì)象存儲(chǔ)系統(tǒng)在設(shè)計(jì)上能夠非常方便地進(jìn)行橫向擴(kuò)展以適應(yīng)大量用戶高并發(fā)訪問的場(chǎng)景,；2. 海量十KB級(jí)到GB級(jí)對(duì)象/文件的存儲(chǔ),，小于10KB的數(shù)據(jù)更適用于使用K/V數(shù)據(jù)庫(kù)，而大于10GB的文件最好將其分割為多個(gè)對(duì)象并行寫入對(duì)象存儲(chǔ)系統(tǒng)中,，多數(shù)對(duì)象存儲(chǔ)系統(tǒng)都有單個(gè)對(duì)象大小上限的限制,。所以，如果應(yīng)用具有上述兩種特點(diǎn)，對(duì)象存儲(chǔ)是首選,。

也有人在對(duì)象存儲(chǔ)上做出進(jìn)一步的開發(fā)或者改進(jìn),，使其能夠很好地支持歸檔備份、MapReduce大數(shù)據(jù)處理等場(chǎng)景,，甚至將對(duì)象存儲(chǔ)的接口轉(zhuǎn)為文件系統(tǒng)接口,；反之，OpenStack Swift等對(duì)象存儲(chǔ)系統(tǒng)也支持使用GlusterFS等通用文件系統(tǒng)作為存儲(chǔ)后端,。人們?yōu)槭裁磿?huì)在這些對(duì)象存儲(chǔ)和文件系統(tǒng)相互轉(zhuǎn)換的技術(shù)上進(jìn)行人力和資金的投入,？這些做法的意義何在？應(yīng)該在什么時(shí)候使用這些技術(shù),？我們將在本系列的后續(xù)章節(jié)中給出答案,。

本系列還將以O(shè)penStack Swift為例來剖析對(duì)象存儲(chǔ)的設(shè)計(jì)與實(shí)現(xiàn)，并且討論對(duì)象存儲(chǔ)在實(shí)際應(yīng)用中所遇到的問題以及在Swift中是如何解決的,，進(jìn)而討論對(duì)象存儲(chǔ)的發(fā)展對(duì)底層硬件帶來的挑戰(zhàn)和機(jī)遇,。另外，由于對(duì)象存儲(chǔ)和傳統(tǒng)存儲(chǔ)形態(tài)的差別,，性能評(píng)估已經(jīng)不能以IOPS和讀寫速率等傳統(tǒng)指標(biāo)來衡量，應(yīng)當(dāng)如何對(duì)對(duì)象存儲(chǔ)進(jìn)行評(píng)估,？我們也將在后續(xù)章節(jié)中進(jìn)行探討,。