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

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

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

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

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

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

從另一個(gè)角度來(lái)說(shuō)，2006年以前常說(shuō)的對(duì)象存儲(chǔ)，指的是一種存儲(chǔ)系統(tǒng)的架構(gòu);而2006年以后，人們說(shuō)到對(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ǔ)、阿里云的開(kāi)放存儲(chǔ)服務(wù)OSS也屬于對(duì)象存儲(chǔ)，最近，青云也發(fā)布了對(duì)象存儲(chǔ)服務(wù)。

對(duì)象存儲(chǔ)也有一些著名的開(kāi)源實(shí)現(xiàn)，如OpenStack Swift，開(kāi)源的統(tǒng)一存儲(chǔ)系統(tǒng)Ceph也可以通過(guò)Ceph Object Gateway提供對(duì)象存儲(chǔ)服務(wù)，也稱作RADOS Gateway，縮寫(xiě)為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)來(lái)說(shuō)，尤其是POSIX兼容的文件系統(tǒng)，提供open、close、read、write和lseek等接口。

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

(圖片內(nèi)容來(lái)自SwiftStack)

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

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

能夠放棄隨機(jī)讀寫(xiě)接口而采用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ù)讀寫(xiě)速率也非常低，所以把文件中的一小部分?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)開(kāi)銷微不足道了，而帶來(lái)的計(jì)算效率和用戶體驗(yàn)的提升卻是顯著的。

#p#

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

對(duì)比文件系統(tǒng)，對(duì)象存儲(chǔ)的第二個(gè)特點(diǎn)是沒(méi)有嵌套的文件夾，而是采用扁平的數(shù)據(jù)組織結(jié)構(gòu)，往往是兩層或者三層，例如AWS S3和華為的UDS，每個(gè)用戶可以把它的存儲(chǔ)空間劃分為“容器”(Bucket)，然后往每個(gè)容器里放對(duì)象，對(duì)象不能直接放到租戶的根存儲(chǔ)空間里，必須放到某個(gè)容器下面，而不能嵌套，也就是說(shuō)，容器下面不能再放一層容器，只能放對(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í)，用戶通過(guò)這個(gè)標(biāo)識(shí)來(lái)訪問(wèn)容器或者對(duì)象，所以，對(duì)象存儲(chǔ)提供的是一種K/V的訪問(wèn)方式。

(圖片內(nèi)容來(lái)自華為)

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

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

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

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

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

從另一個(gè)角度來(lái)看，現(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ā)訪問(wèn)的場(chǎng)景;2. 海量十KB級(jí)到GB級(jí)對(duì)象/文件的存儲(chǔ)，小于10KB的數(shù)據(jù)更適用于使用K/V數(shù)據(jù)庫(kù)，而大于10GB的文件***將其分割為多個(gè)對(duì)象并行寫(xiě)入對(duì)象存儲(chǔ)系統(tǒng)中，多數(shù)對(duì)象存儲(chǔ)系統(tǒng)都有單個(gè)對(duì)象大小上限的限制。所以，如果應(yīng)用具有上述兩種特點(diǎn)，對(duì)象存儲(chǔ)是***。

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