(圖片部分內容引用自Ceph官網和SwiftStack)

而2006年以后，人們說到對象存儲，往往指的是以AWS的S3為代表的，通過HTTP接口提供訪問的存儲服務或者存儲系統。類似的系統還有Rackspace于2009年開始研發并于2010年開源的OpenStack Swift(Rackspace的對象存儲服務開始于2008年，但是Swift項目的開發是從2009年開始的，Rackspace用Swift項目對其云存儲系統進行了徹底重構)。這里的“對象”(Object)和我們平時說的文件類似，如果我們把一個文件傳到對象存儲系統里面存起來，就叫做一個對象。

從另一個角度來說，2006年以前常說的對象存儲，指的是一種存儲系統的架構;而2006年以后，人們說到對象存儲常指的是一種存儲形態，我們這里討論的對象存儲也正是后者。

目前，對象存儲已經得到了廣泛的應用。具有代表性的大規模實現主要在各個公有云服務商，比如AWS的S3、Rackspace的CloudFiles，國內的七牛云存儲、阿里云的開放存儲服務OSS也屬于對象存儲，最近，青云也發布了對象存儲服務。

對象存儲也有一些著名的開源實現，如OpenStack Swift，開源的統一存儲系統Ceph也可以通過Ceph Object Gateway提供對象存儲服務，也稱作RADOS Gateway，縮寫為RADOSGW。

二、對象存儲與文件系統的比較

與文件系統相比，以AWS S3和Swift為代表的對象存儲有兩個顯著的特征——REST風格的接口和扁平的數據組織結構。

1、對象存儲的接口

對于大多數文件系統來說，尤其是POSIX兼容的文件系統，提供open、close、read、write和lseek等接口。

而對象存儲的接口是REST風格的，通常是基于HTTP協議的RESTful Web API，通過HTTP請求中的PUT和GET等操作進行文件的上傳即寫入和下載即讀取，通過DELETE操作刪除文件。

(圖片內容來自SwiftStack)

對象存儲和文件系統在接口上的本質區別是對象存儲不支持和fread和fwrite類似的隨機位置讀寫操作，即一個文件PUT到對象存儲里以后，如果要讀取，只能GET整個文件，如果要修改一個對象，只能重新PUT一個新的到對象存儲里，覆蓋之前的對象或者形成一個新的版本。

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

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

2、扁平的數據組織結構

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

這就是所謂“扁平數據組織結構”，因為它和文件夾可以一級一級嵌套不同，層次關系是固定的，而且只有兩到三級，是扁平的。每一級的每個元素，例如S3中的某個容器或者某個對象，在系統中都有唯一的標識，用戶通過這個標識來訪問容器或者對象，所以，對象存儲提供的是一種K/V的訪問方式。

(圖片內容來自華為)

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

不難看出，對象存儲有著鮮明的互聯網和大數據時代的特點，隨著“互聯網+”的推進，互聯網技術正在滲透到各行各業，數據量也在成指數倍數增長，對象存儲將發揮越來越大的作用。

三、文件系統和對象存儲系統的優劣和發展趨勢分析

上述分析了對象存儲的特點并與文件系統做了比較，接下來就不得不回答一個問題：文件系統是不是沒有生命力了?答案當然是否定的。對象存儲打破了文件系統一統天下的局面，給我們帶來了更多的選擇，并不意味著我們就要否定文件系統。

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

由此看來文件系統將來的發展趨勢更多的是專用文件系統，而不再是像以前那樣，以前一套Filesystem適用于所有場景，更有一些部分要讓位于對象存儲或者其他存儲形態。

從另一個角度來看，現代對象存儲系統的“甜區”在哪里：1. 互聯網和類似互聯網的應用場景，這不僅僅是因為REST風格的HTTP的接口，而且還因為大多數對象存儲系統在設計上能夠非常方便地進行橫向擴展以適應大量用戶高并發訪問的場景;2. 海量十KB級到GB級對象/文件的存儲，小于10KB的數據更適用于使用K/V數據庫，而大于10GB的文件最好將其分割為多個對象并行寫入對象存儲系統中，多數對象存儲系統都有單個對象大小上限的限制。所以，如果應用具有上述兩種特點，對象存儲是首選。

也有人在對象存儲上做出進一步的開發或者改進，使其能夠很好地支持歸檔備份、MapReduce大數據處理等場景，甚至將對象存儲的接口轉為文件系統接口;反之，OpenStack Swift等對象存儲系統也支持使用GlusterFS等通用文件系統作為存儲后端。人們為什么會在這些對象存儲和文件系統相互轉換的技術上進行人力和資金的投入?這些做法的意義何在?應該在什么時候使用這些技術?我們將在本系列的后續章節中給出答案。

本系列還將以OpenStack Swift為例來剖析對象存儲的設計與實現，并且討論對象存儲在實際應用中所遇到的問題以及在Swift中是如何解決的，進而討論對象存儲的發展對底層硬件帶來的挑戰和機遇。另外，由于對象存儲和傳統存儲形態的差別，性能評估已經不能以IOPS和讀寫速率等傳統指標來衡量，應當如何對對象存儲進行評估?我們也將在后續章節中進行探討。