文件系統(tǒng)vs對象存儲——選型和趨勢

作者：李明宇 2015-08-12 14:35:47

云計算 目前，對象存儲已經(jīng)得到了廣泛的應用。具有代表性的大規(guī)模實現(xiàn)主要在各個公有云服務商，比如AWS的S3、Rackspace的CloudFiles，國內(nèi)的七牛云存儲、阿里云的開放存儲服務OSS也屬于對象存儲，最近，青云也發(fā)布了對象存儲服務。對象存儲也有一些著名的開源實現(xiàn)，如OpenStack Swift，開源的統(tǒng)一存儲系統(tǒng)Ceph也可以通過Ceph Object Gateway提供對象存儲服務，也稱作RADOS Gateway，縮寫為RADOSGW。

安岳網(wǎng)站制作公司哪家好，找創(chuàng)新互聯(lián)！從網(wǎng)頁設計、網(wǎng)站建設、微信開發(fā)、APP開發(fā)、成都響應式網(wǎng)站建設公司等網(wǎng)站項目制作，到程序開發(fā)，運營維護。創(chuàng)新互聯(lián)2013年至今到現(xiàn)在10年的時間，我們擁有了豐富的建站經(jīng)驗和運維經(jīng)驗，來保證我們的工作的順利進行。專注于網(wǎng)站建設就選創(chuàng)新互聯(lián)。

如果我們在服務端存儲文件，例如一個O2O應用中的圖片或者企業(yè)級云盤里的文檔，以前我們可能會毫不猶豫地把它們放到文件系統(tǒng)里，比如說NAS設備或者GlusterFS等分布式文件系統(tǒng)，但是，隨著技術的發(fā)展，我們有了一個新的選擇——對象存儲，今天我們來討論一下，對象存儲相對于文件系統(tǒng)有什么特點?什么時候我們應該選擇對象存儲?文件系統(tǒng)將來的發(fā)展方向是什么?

一、對象存儲的概念

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

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

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

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

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

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

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

二、對象存儲與文件系統(tǒng)的比較

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

1、對象存儲的接口

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

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

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

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

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

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

#p#

2、扁平的數(shù)據(jù)組織結構

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

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

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

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

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

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

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

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

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

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

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

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

網(wǎng)站標題：文件系統(tǒng)vs對象存儲——選型和趨勢
標題路徑：http://www.5511xx.com/article/cddhiig.html