編者按：青云QingCloud 對象存儲(chǔ)服務(wù)提供可無限擴(kuò)展的存儲(chǔ)空間、快速的數(shù)據(jù)存取性能、高度的服務(wù)可靠性和數(shù)據(jù)安全性、細(xì)粒度的權(quán)限控制及簡單易用的接口，以向廣大用戶提供廉價(jià)、可靠的存儲(chǔ)系統(tǒng)。在本文中，青云QingCloud 系統(tǒng)工程師 Osier Yang 分享了青云QingCloud 對象存儲(chǔ)的設(shè)計(jì)理念、實(shí)際的應(yīng)用案例及進(jìn)一步研發(fā)計(jì)劃。

注：“QingStor”為“青云QingCloud 對象存儲(chǔ)”的項(xiàng)目及產(chǎn)品名稱，為行文方便，下文將皆以“QingStor”代指“青云QingCloud 對象存儲(chǔ)”。 

本文的主要內(nèi)容如下：

1、什么是對象

我們從一個(gè)故事開始。在我們的對象存儲(chǔ)研發(fā)后期，一個(gè)潛在客戶來交流，他們想了解怎么用對象存儲(chǔ)。交流期間，其中的技術(shù)負(fù)責(zé)人問了這樣一個(gè)問題: “你們這既然是對象存儲(chǔ)，那么它的類是怎么定義的？“。由此可見，即便是技術(shù)人員，也可能對”對象存儲(chǔ)“產(chǎn)生誤解。

所以要想講清楚到底什么是”對象存儲(chǔ)“，很有必要先解釋“對象存儲(chǔ)”這四個(gè)字，“存儲(chǔ)”二字不必多說，凡 IT 從業(yè)者應(yīng)該都理解，關(guān)鍵點(diǎn)是: 什么是“對象”?

Wikipedia 對“Object”分各領(lǐng)域做了解釋。別的領(lǐng)域我們不管，我們只看哲學(xué)領(lǐng)域的定義，因?yàn)檎軐W(xué)領(lǐng)域的定義更具有普遍意義。Wikipedia 對“Object”在哲學(xué)領(lǐng)域的定義是:

a thing, being, or concept

?在漢語里，和其英文本意最符合的詞也就是”東西“了吧？百科里關(guān)于”東西“的釋義如下:

泛指各種具體或抽象的人、事、物。例如: * 明朱有燉 《豹子和尚自還俗》：“我又無甚希奇物，我又無甚好東西，他偷我箇甚的？” * 《紅樓夢》第三五回：鳳姐笑道：”這一宗東西，家常不大做；今兒寶兄弟提起來了，單做給他吃。“ * 沙汀《闖關(guān)》一：“感情真是一種奇怪的東西。”

在計(jì)算機(jī)領(lǐng)域，“對象”(Object)除了在面向?qū)ο缶幊逃脕肀硎疽粋€(gè)類(Class)的實(shí)例(Instance)外，還被常用來表示一個(gè)變量(Variable)，一個(gè)函數(shù)(Function)，一個(gè)數(shù)據(jù)結(jié)構(gòu)(Data Structure)，一段在內(nèi)存中的實(shí)體，等等，不一而足，m相信計(jì)算機(jī)領(lǐng)域的研發(fā)人員在各種各樣的代碼或工具里都見過。舉個(gè)例子，Linux Kernel (Linux操作系統(tǒng)的核心)的模塊名以“.ko”為后綴名，“ko”的全稱為“Kernel Object”，這里的“Object”和 JAVA/C++ 語言里的“Object”顯然不是一回事。

由此可見，在計(jì)算機(jī)領(lǐng)域，“對象” (Object)這個(gè)詞也是一個(gè)泛指意義的詞，其意義可類比漢語中的“東西”。你可以指任一事物為“東西”，也即你可以指任一事物為“Object”。具體是什么“東西”，依場景不同而不同。至于到底“對象存儲(chǔ)”里的“對象”是什么“東西”，請見第三章節(jié)分解。

2、企業(yè) A 的存儲(chǔ)方案演進(jìn)歷程

為了一步一步理解什么是對象存儲(chǔ)，我們從另外一個(gè)故事開始: 企業(yè) A 有一個(gè)面向互聯(lián)網(wǎng)的業(yè)務(wù)，允許用戶上傳下載圖片及視頻，視頻和圖片的大小都比較小。

2.1 企業(yè) A 存儲(chǔ)方案 1

因業(yè)務(wù)發(fā)展前期用戶量很少，產(chǎn)生的數(shù)據(jù)量也足夠小，最簡單直接的方案為 (實(shí)際生產(chǎn)中應(yīng)該沒人用這種方案，但最簡單的方案往往更有助于我們看清問題的本質(zhì)) :

這種最簡單直接的方案幾乎到處是缺陷:

• 單盤容量限制。總存儲(chǔ)量及可存儲(chǔ)的單個(gè)最大文件的大小均受單盤容量限制。
• 無數(shù)據(jù)冗余。主機(jī)宕機(jī)會(huì)導(dǎo)致服務(wù)不可用，甚至數(shù)據(jù)丟失；硬盤損壞會(huì)導(dǎo)致數(shù)據(jù)丟失。
• 無數(shù)據(jù)備份。假設(shè)企業(yè)A的運(yùn)維人員誤刪數(shù)據(jù)，恢復(fù)數(shù)據(jù)將變得困難。
• 文件系統(tǒng)的限制。當(dāng)存儲(chǔ)的文件數(shù)目越來越多時(shí)，文件系統(tǒng)的目錄樹會(huì)變大，變深，元數(shù)據(jù)讀寫管理越來越低效，數(shù)據(jù)讀寫性能會(huì)越來越差，磁盤碎片增多，inode 總數(shù)也可能達(dá)到限制。

2.2 企業(yè) A 存儲(chǔ)方案 2

隨著業(yè)務(wù)發(fā)展，用戶上傳的數(shù)據(jù)量不斷增加，我們假設(shè)容量率先增大了瓶頸，企業(yè) A 為了解決容量問題，將存儲(chǔ)架構(gòu)改變?yōu)?

注:  * PV (LVM Physical Volume)  * VG (LVM Volume Group)  * LV (LVM Logical Group)

以上方案的利用 LVM 將眾多硬盤空間抽象為一塊大硬盤，突破了單個(gè)硬盤的容量限制，容量需求增加時(shí)，添加硬盤到 VG ，并對 LV 進(jìn)行擴(kuò)容即可。支持文件系統(tǒng)級別的 Snapshot , 可將數(shù)據(jù)回滾至某個(gè)點(diǎn)。但仍有缺陷:

• 單機(jī)容量限制。單機(jī)可掛的硬盤總數(shù)有限制，即總?cè)萘咳匀挥邢拗啤?/li>
• 無數(shù)據(jù)冗余。雖然 LVM 支持文件系統(tǒng)級別 Snapshot ，但 Snapshot 只能將數(shù)據(jù)回滾到某個(gè)點(diǎn)。并不能夠應(yīng)對災(zāi)難情況，比如物理機(jī)宕機(jī)，服務(wù)仍然不可用，數(shù)據(jù)也可能丟失；硬盤損壞時(shí)，數(shù)據(jù)仍然可能會(huì)丟失。
• 文件系統(tǒng)的限制。當(dāng)存儲(chǔ)的文件數(shù)目越來越多時(shí)，文件系統(tǒng)的目錄樹會(huì)變大，變深，元數(shù)據(jù)讀寫管理越來越低效，數(shù)據(jù)讀寫性能會(huì)越來越差，磁盤碎片增多，inode 總數(shù)也可能達(dá)到限制。

2.3 企業(yè) A 存儲(chǔ)方案 3

假設(shè)企業(yè) A 的存儲(chǔ)容量需求在短時(shí)間內(nèi)達(dá)不到單機(jī)的容量限制，但隨著業(yè)務(wù)的發(fā)展，用戶量增多，企業(yè) A 開始重視數(shù)據(jù)的安全性。存儲(chǔ)方案進(jìn)一步演化為：

方案 3 引入了RAID 來做數(shù)據(jù)的冗余，同時(shí)保留了 LVM 帶來了靈活性。但仍然有缺點(diǎn):

• 單機(jī)容量限制。可掛的硬盤總數(shù)有限制，即總?cè)萘咳匀挥邢拗啤?/li>
• 文件系統(tǒng)的限制。當(dāng)存儲(chǔ)的文件數(shù)目越來越多時(shí)，文件系統(tǒng)的目錄樹會(huì)變大，變深，元數(shù)據(jù)讀寫管理越來越低效，數(shù)據(jù)讀寫性能會(huì)越來越差，磁盤碎片增多，inode 總數(shù)也可能達(dá)到限制。
• 不可靠。當(dāng)宕機(jī)時(shí)，服務(wù)便不可用。

2.4 企業(yè) A 存儲(chǔ)方案 4

我們假設(shè)企業(yè) A 隨著業(yè)務(wù)的進(jìn)一步發(fā)展，存儲(chǔ)容量需求在短時(shí)間內(nèi)仍然達(dá)不到單機(jī)的容量限制，但開始重視服務(wù)的可靠性。故將存儲(chǔ)方案進(jìn)一步演化為:

此方案保留軟 RAID 及 LVM 的同時(shí)，引入了 DRBD，通過網(wǎng)絡(luò)來做塊設(shè)備級別的復(fù)制，可靠性提高了一倍。但仍然有缺點(diǎn):

• 單機(jī)容量限制。可掛的硬盤總數(shù)有限制，即總?cè)萘咳匀挥邢拗啤?/li>
• 文件系統(tǒng)的限制。當(dāng)存儲(chǔ)的文件數(shù)目越來越多時(shí)，文件系統(tǒng)的目錄樹會(huì)變大，變深，元數(shù)據(jù)讀寫管理越來越低效，數(shù)據(jù)讀寫性能會(huì)越來越差，磁盤碎片增多，inode 總數(shù)也可能達(dá)到限制。

2.5 企業(yè) A 存儲(chǔ)方案 5

隨著業(yè)務(wù)的進(jìn)一步發(fā)展，單機(jī)容量已無法滿足企業(yè)A的存儲(chǔ)需求。此時(shí)只剩下一條路：分布式存儲(chǔ)。企業(yè) A 不想投入人力自己開發(fā)分布式存儲(chǔ)，而開源分布式存儲(chǔ)方案繁多，經(jīng)反復(fù)調(diào)研與測試，最終將方案確定為 HDFS :

HDFS的引入去除了單機(jī)容量的限制，但仍有缺陷:

• HDFS并非為存儲(chǔ)海量小文件而設(shè)計(jì)，不適合存儲(chǔ)海量小文件。每一存儲(chǔ)在HDFS中的文件、目錄或塊(Block)都會(huì)有一個(gè)對應(yīng)的索引對象存儲(chǔ)于NameNode的內(nèi)存中，在海量小文件的存儲(chǔ)場景下，NameNode的內(nèi)存稱為一個(gè)限制。當(dāng)然，Hadoop 社區(qū)為應(yīng)對海量小文件也做了一些措施，如
  HAR (Hadoop Archives) files，及 SequeuesFile。但這些方案均只能緩解問題，并不能從根本上解決問題。

企業(yè)A 的故事到這里就結(jié)束了。在這個(gè)故事里，所有方案都基于PC Server構(gòu)建，我們從未提起過傳統(tǒng)企業(yè)存儲(chǔ)方案DAS, SAN, 及NAS。關(guān)于傳統(tǒng)企業(yè)存儲(chǔ)方案，和此次分享關(guān)系不大，想了解傳統(tǒng)企業(yè)存儲(chǔ)方案在數(shù)據(jù)爆發(fā)的時(shí)代的缺陷者，請參見青云QingCloud 硬件大師 Lester (廖洋) 先前的分享(深度剖析——超融合架構(gòu)應(yīng)用與實(shí)踐分享)，或我先前的公開分享 (青云QingCloud存儲(chǔ)系統(tǒng)架構(gòu))。我們也只提到了一種分布式存儲(chǔ)方案(HDFS)，分布式存儲(chǔ)開源方案項(xiàng)目繁多，此章節(jié)就不一一列舉了，第四章節(jié)會(huì)對主流的支持對象存儲(chǔ)的開源分布式存儲(chǔ)做簡要分析。

3、什么是對象存儲(chǔ)

“對象存儲(chǔ)”來源于英文“Object Storage”或“Object-based Storage”，照前文所述，那“Object Storage”應(yīng)譯為“東西存儲(chǔ)”？ 如此翻譯很晦澀，但并不妨礙我們將“Object Storage”理解為“存東西的存儲(chǔ)”，那么“對象存儲(chǔ)”存的到底是什么“東西”？

3.1 對象存儲(chǔ)的大致目標(biāo)

現(xiàn)在我們回顧一下企業(yè)A經(jīng)歷的存儲(chǔ)方案歷程，為了滿足不斷發(fā)展及增長的業(yè)務(wù)需求，企業(yè) A 不斷得在解決容量，數(shù)據(jù)安全，服務(wù)高可靠，可存儲(chǔ)文件數(shù)量，讀寫性能等諸多問題，方案也變的越來越復(fù)雜。

而像企業(yè) A 這種有大量存儲(chǔ)需求的企業(yè)不在少數(shù)，且不同企業(yè)，不同業(yè)務(wù)的數(shù)據(jù)特征千差萬別。對象存儲(chǔ)作為一種面向多租戶的公共服務(wù)，除應(yīng)該具備企業(yè)A的存儲(chǔ)方案演變過程中不斷追求的特性外，還應(yīng)該通用，不能假設(shè)用戶的數(shù)據(jù)特征(如類型，大小)。

我們先大致歸納一下對象存儲(chǔ)應(yīng)該有的特性:

• 多租戶
• 不假設(shè)數(shù)據(jù)特征，包括類型，大小等
• 存儲(chǔ)空間可無限擴(kuò)展，且性能該隨容量水平擴(kuò)展而線性提升，不然數(shù)據(jù)量越大，請求越多，性能卻不提升，系統(tǒng)的存取性能只會(huì)越來越慢
• 數(shù)據(jù)安全
• 服務(wù)高可靠

3.2 對象存儲(chǔ)的索引設(shè)計(jì)

前面我們以企業(yè) A 的存儲(chǔ)方案演進(jìn)過程中所遇到的問題，歸納出了對象存儲(chǔ)的應(yīng)該有的特性，即大致目標(biāo)，但還只局限于在數(shù)據(jù)存儲(chǔ)層討論，下面我們來看看索引層。

細(xì)心的同學(xué)可能已經(jīng)發(fā)現(xiàn)，前文中我們一直在提一個(gè)問題：文件系統(tǒng)的限制。當(dāng)存儲(chǔ)的文件數(shù)目越來越多時(shí)，文件系統(tǒng)的目錄樹會(huì)變大，變深，元數(shù)據(jù)讀寫管理越來越低效，數(shù)據(jù)讀寫性能會(huì)越來越差，磁盤碎片增多，inode 總數(shù)也可能達(dá)到限制。

文件系統(tǒng)層次的限制根源在于當(dāng)前的文件系統(tǒng)都是為單機(jī)存儲(chǔ)而設(shè)計(jì)的，樹狀的索引結(jié)構(gòu)在非海量數(shù)據(jù)時(shí)代，很好的完成了數(shù)據(jù)索引的使命。但在面向海量存儲(chǔ)時(shí)，就表現(xiàn)出了一些先天性問題，尤其在面向海量小文件時(shí)。

避免文件系統(tǒng)面對海量數(shù)據(jù)時(shí)的缺陷可以有多種方案，其中最直接有效的方案是構(gòu)建簡潔獨(dú)立的索引層，這樣既能避免文件系統(tǒng)的樹狀索引面對海量數(shù)據(jù)時(shí)的問題，同時(shí)能利用文件系統(tǒng)經(jīng)長期驗(yàn)證過的優(yōu)勢，如穩(wěn)定性和可靠性。

那么怎么設(shè)計(jì)獨(dú)立索引層？如前所述，文件系統(tǒng)面對海量數(shù)據(jù)時(shí)的缺陷主要來自于樹狀索引結(jié)構(gòu)，那新構(gòu)建的獨(dú)立索引層就應(yīng)該盡量避免將樹狀索引結(jié)構(gòu)，但因?qū)ο蟠鎯?chǔ)面向多租戶，用戶間的存儲(chǔ)空間總是要區(qū)分開的，即使是單用戶，用戶也可能有按業(yè)務(wù)或場景劃分存儲(chǔ)空間的需求，也就是說存儲(chǔ)空間這一層的索引是必須的，所以最終索引結(jié)構(gòu)如下:

如上圖所示，“Service”為頂層命名空間(Namespace)，其下可有任意多個(gè) Bucket (存儲(chǔ)空間)，Bucket 命名空間為第一級命名空間，其下可以有任意多 Object。 這樣我們便既盡量避免了過深的樹狀索引結(jié)構(gòu)，又做到了存儲(chǔ)空間的區(qū)分。

3.3 什么是對象

探討完數(shù)據(jù)存儲(chǔ)層及索引層，我們終于可以回到本章節(jié)開頭的問題了: “對象存儲(chǔ)”的“對象”到底是個(gè)什么“東西”?

如果有人了解過文件系統(tǒng)的實(shí)現(xiàn)，定會(huì)發(fā)現(xiàn)文件系統(tǒng)的索引結(jié)構(gòu)里包含了許多元信息 (請參見kernel/linux/fs.h 的 inode 結(jié)構(gòu)體)。而對于對象存儲(chǔ)系統(tǒng)而言，其中很多元信息無意義，我們創(chuàng)建了扁平化的、獨(dú)立的、簡潔的索引層，不需要再帶著這些無意義的元信息，我們需要的僅僅是基本且必須的元信息：

• 屬于哪個(gè)存儲(chǔ)空間
• 類型
• 大小
• 校驗(yàn)值
• 最后修改時(shí)間

對于多數(shù)業(yè)務(wù)來說，基本的元信息已經(jīng)足夠，但對于某些業(yè)務(wù)而言，可能還需要更多的元信息。比如一個(gè)歌曲文件，除了類型、大小、校驗(yàn)值，最后修改時(shí)間，用戶的業(yè)務(wù)可能還想要額外的描述，如:

• 演唱者是誰
• 作詞者是誰
• 作曲者是誰
• 屬于哪張唱片
• 屬于什么風(fēng)格
• ……

如果對象存儲(chǔ)的索引層能夠允許用戶自定義元數(shù)據(jù)。用戶就不需要單獨(dú)維護(hù)數(shù)據(jù)庫去存儲(chǔ)這些信息。

了解了”對象”(Object)的索引構(gòu)成后，我們終于可以歸納一下”對象”(Object)”到底是什么”東西”了。

注:  * 數(shù)據(jù)實(shí)體 (Data Entity)  * 數(shù)據(jù)實(shí)體的元數(shù)據(jù) (Metadata)  * 數(shù)據(jù)實(shí)體的用戶定義元數(shù)據(jù) (User defined metadata)

下面是一個(gè)文件的元數(shù)據(jù)示例：

HTTP/1.1 200 OKServer: QingStorDate: Sun, 16 Aug 2015 09:05:00 GMTLast-Modified: Fri, 14 Aug 2015 09:10:39 GMTETag: "0c2f573d81194064b129e940edcefe9b"Content-Type: image/jpegContent-Length: 7987Connection: closeRequest-ID: aa08cf7a43f611e5886952542e6ce14

其中的“Last-Modified”, “Content-Type”, “Content-Type”, “ETag”(數(shù)據(jù)實(shí)體的 MD5 值)即為 QingStor 上一個(gè)“對象”(Object)的元信息。

4、開源方案探討

每次交流時(shí)，都會(huì)有人問到對象存儲(chǔ)相關(guān)的開源方案，問 Qingstor 為什么我們沒有采取開源方案。我們在正式開發(fā) QingStor 前，確實(shí)調(diào)研及測試過不少開源方案，但無一能夠滿足我們的目標(biāo)。下面我們就選幾個(gè)主流的開源方案探討一下。

4.1 Openstack Swift

上面是 Openstack Swift 的架構(gòu)圖。下面是 Swift 的問題:

• 未對小文件進(jìn)行合并。從上面的架構(gòu)圖中我們可以看到，Swift沒有文件合并組件，當(dāng)存儲(chǔ)的小文件數(shù)量過多時(shí)，系統(tǒng)在文件系統(tǒng)這一層就會(huì)開始出現(xiàn)瓶頸，文件的讀寫及目錄的列取性能都會(huì)下降，甚至自身組件（如 “replicator”，數(shù)據(jù)遷移／修復(fù)) 都可能會(huì)出問題。有興趣了解更多者請參見: http://engineering.spilgames.com/openstack-swift-lots-small-files

• Object 的元數(shù)據(jù)存儲(chǔ)于文件的擴(kuò)展屬性里，無額外索引。此設(shè)計(jì)帶來的可能問題:

  • 獲取 Object 元信息慢，尤其當(dāng)文件數(shù)目過多時(shí)。
  • 若支持用戶自定義元數(shù)據(jù)，會(huì)進(jìn)一步加劇元數(shù)據(jù)獲取慢的問題

• 一個(gè) Container (存儲(chǔ)空間) 的元信息對應(yīng)一個(gè) SQLite 數(shù)據(jù)庫，其中維護(hù)著該 Container 下的 Object 列表信息，這是為了 緩解從文件系統(tǒng)列取 Container 下 Objects 時(shí)糟糕的性能。但問題是當(dāng)一個(gè) Container 下 Object 過多時(shí)，SQLite 數(shù)據(jù)庫會(huì)支撐不住。所以單個(gè) Container 下存儲(chǔ)不了過多的 Object。

關(guān)于Openstack Swift架構(gòu)的更多信息，請參見 Openstack Swift 原理、架構(gòu)與 API 介紹

4.2 Ceph RadosGW

Ceph RadosGW 糟糕的索引設(shè)計(jì)注定完全不能用于生產(chǎn)。

起先Radosgw的索引設(shè)計(jì)是將一個(gè)Bucket的索引存做一個(gè)Rados object。這個(gè)做的后果是:

• 一個(gè)Bucket下存不了太多object
• 當(dāng)Ceph集群正在對Bucket的索引Object進(jìn)行修復(fù)或回填時(shí)，在修復(fù)或回填操作完成前，整個(gè)Bucket無法寫入

請見下面這段引自Ceph官方的文檔 (RGW - BUCKET INDEX SCALABILITY)

Currently the bucket index info is kept in a single object that may serve as a scalability pain point, as the update operation on a single rados object is not scalable.

Another problem with one single big bucket, is that when backfill/recovery are happening to the bucket index object, all updates to that object (which is at the critical path of a put request) are stalled until the object is fully recovered. Per our testing, when there are 3 million objects within a bucket, it takes around 2 minutes to recover thus most requests during this period get timeout.

后來Ceph社區(qū)改進(jìn)了一下索引設(shè)計(jì)，將單個(gè)Bucket的索引Object進(jìn)行了分片，詳情見
(rgw: Shard bucket index objects to improve single bucket PUT throughput)。下面選取 Ceph RadosGW 對Bucket的索引Object分片邏輯的代碼片段看一下:

int RGWRados::get_bucket_index_object(const string& bucket_oid_base, const string& obj_key,    uint32_t num_shards, RGWBucketInfo::BIShardsHashType hash_type, string *bucket_obj, int *shard_id){                                                                                 int r = 0;                                                                      switch (hash_type) {                                                              case RGWBucketInfo::MOD:                                                          if (!num_shards) {                                                                // By default with no sharding, we use the bucket oid as itself                 (*bucket_obj) = bucket_oid_base;                                                if (shard_id) {                                                                   *shard_id = -1;                                                               }                                                                             } else {                                                                          uint32_t sid = ceph_str_hash_linux(obj_key.c_str(), obj_key.size());            uint32_t sid2 = sid ^ ((sid & 0xFF) << 24);                                     sid = sid2 % MAX_BUCKET_INDEX_SHARDS_PRIME % num_shards;                        char buf[bucket_oid_base.size() + 32];                                          snprintf(buf, sizeof(buf), "%s.%d", bucket_oid_base.c_str(), sid);              (*bucket_obj) = buf;                                                            if (shard_id) {                                                                   *shard_id = (int)sid;                                                         }                                                                             }                                                                               break;                                                                        default:                                                                          r = -ENOTSUP;                                                               }                                                                               return r;                                                                     }     

從上面的代碼中可以很容易看出，其分片邏輯采用了最簡單的Hash算法: 取模。這意味著一個(gè)Bucket的索引Object分片個(gè)數(shù)一經(jīng)確定，便無法更改。因?yàn)橐坏┍桓模馕吨鳫ash范圍變化，整個(gè)Bucket的索引也就被破壞了。

另外，正所謂治標(biāo)不治本，分片方法僅僅是對其糟糕的索引設(shè)計(jì)有些許改善，但當(dāng)Ceph正在對Bucket的某個(gè)或者某些索引Object的分片進(jìn)行修復(fù)或回填時(shí)，在修復(fù)或回填操作完成前，Hash到此或此些索引Object分片的寫入都將掛起，直至修復(fù)或回填操作完成。而且實(shí)際情況是，分片個(gè)數(shù)還不能太多，太多的情況下 List 性能下降很嚴(yán)重，詳情請見 (RadosGW Big Index)。

4.3 Gluster

和Ceph相反，Gluster 的設(shè)計(jì)非常工程派。無獨(dú)立索引；未對文件進(jìn)行任何切割或合并操作；所做的所有事情都是為了一個(gè)目的：一個(gè)更大的文件系統(tǒng)。

這種設(shè)計(jì)帶來的問題是，它并未解決文件系統(tǒng)本身的限制，因?yàn)樗磳ξ募到y(tǒng)的語義做任何修改。當(dāng)存儲(chǔ)海量小文件時(shí)，性能會(huì)變的很差，盡管 Gluster 社區(qū)為此做了各種優(yōu)化（有興趣的可以查找 Gluster 關(guān)于小文件讀寫性能優(yōu)化的各種 translator )，但也是治標(biāo)不治本。

4.4 小結(jié)

在此章節(jié)，我們簡要分析了三個(gè)主流的開源對象存儲(chǔ)相關(guān)項(xiàng)目，其他項(xiàng)目我也調(diào)研過。總體而言，開源的項(xiàng)目大要么如Ceph RadosGW有嚴(yán)重缺陷，要么是應(yīng)對特定場景的，對用戶的數(shù)據(jù)特征存在假設(shè)，不可通用化。而對數(shù)據(jù)特征不假設(shè)是最難的，如果把這個(gè)要求去掉，對象存儲(chǔ)的設(shè)計(jì)可以簡化很多，有興趣的同學(xué)可以去看Facebook的Haystack，及淘寶的TFS的設(shè)計(jì)，這兩個(gè)項(xiàng)目都是用來解決其企業(yè)業(yè)務(wù)中所面對的特定需求及場景的。

順便說一下，有人說雅虎用 Ceph RadosGW 存了幾 PB 的數(shù)據(jù)，大概是他們可以接受單個(gè)Bucket下的Object數(shù)量限制，也可以接收寫操作掛起等待吧，否則該怎么解釋呢？

5、QingStor 的架構(gòu)與實(shí)現(xiàn)

5.1 接入層

在章節(jié) “3” 中我們逐步探討了數(shù)據(jù)存儲(chǔ)層，索引層，及對象。但為了循序漸進(jìn)，在企業(yè)A的存儲(chǔ)演化過程中，我們刻意省略掉了一個(gè)組件: 接入層。

傳統(tǒng)存儲(chǔ)的訪問接口各不相同。塊存儲(chǔ)暴露給用戶的是一個(gè)一個(gè)的 Block 。文件系統(tǒng)或網(wǎng)絡(luò)文件系統(tǒng)(如 NFS )暴露給用戶的是 POSIX 文件系統(tǒng)接口。但無論是哪一種接口，都有一個(gè)共同的問題: 數(shù)據(jù)流轉(zhuǎn)不便。

而對象存儲(chǔ)通過將資源 URL 化，數(shù)據(jù)的流轉(zhuǎn)方式就方便多了。

對象存儲(chǔ)接收請求的協(xié)議為 HTTP ，所有一定有 HTTP Server ，而接收到用戶的文件上傳和下載請求后，需要有相應(yīng)的處理方法。且作為面向多租戶的公有服務(wù)，無法假設(shè)用戶的請求行為，所有用戶加起來的并發(fā)請求可能會(huì)很高。另外，接入層得高可用。所以得引入負(fù)載均衡。

我們把最前端的負(fù)載均衡，后端的 HTTP Server ，及再后端各種處理方法，統(tǒng)稱為接入層。接入層作為QingStor的最外層建筑，向用戶暴露 RESTful 的 API 。

5.2 多區(qū)域(Zone)部署

青云QingCloud IaaS 服務(wù)為多區(qū)域部署，用戶可根據(jù)自己的需求選擇適合自己業(yè)務(wù)的區(qū)域部署服務(wù)。而 QingStor 作為存儲(chǔ)服務(wù)，不應(yīng)該遠(yuǎn)離計(jì)算資源（簡單計(jì)算資源如主機(jī)，復(fù)雜計(jì)算資源如 QingCloud 的大數(shù)據(jù)平臺(tái)， Spark、Storm、 Hadoop、etc)。所以我們把決定權(quán)交給了用戶，由用戶決定如何部署計(jì)算及存儲(chǔ)資源。

QingStor 的多區(qū)域部署示意圖如下:

為了進(jìn)一步拉近計(jì)算與存儲(chǔ)的距離。同一區(qū)域的計(jì)算資源訪問 QingStor 走內(nèi)部網(wǎng)絡(luò)。

5.3 單區(qū)域(Zone)架構(gòu)

文中已分別就“接入層”，“索引層”，及“數(shù)據(jù)存儲(chǔ)層”進(jìn)行了探討。這里進(jìn)一步強(qiáng)調(diào)QingStor架構(gòu)設(shè)計(jì)的核心思想:

• 數(shù)據(jù)安全；
• 各層次均須具備水平擴(kuò)展能力。

故各層次的具體設(shè)計(jì)如下:

• 接入層: 無狀態(tài)，意味著接入層可以任意水平擴(kuò)展。
• 索引層: 多slave，保證索引數(shù)據(jù)不丟失，且高可靠; 分庫，分表; 二級索引。做到可任意水平擴(kuò)展。
• 數(shù)據(jù)存儲(chǔ)層: 多副本 (3份)，保證數(shù)據(jù)不丟；單集群可水平擴(kuò)展; 為避免單集群過大時(shí)的通訊風(fēng)暴，支持多集群調(diào)度，進(jìn)一步提高數(shù)據(jù)存儲(chǔ)層擴(kuò)展性，以達(dá)到容量可無限擴(kuò)展。

“接入層”，“索引層”，及“數(shù)據(jù)層”構(gòu)成了QingStor的架構(gòu)主干。此外，還有旁路服務(wù)“調(diào)度器”，”監(jiān)控服務(wù)“，及旁路異步服務(wù)如“垃圾回收”，“文件合并”，“碎片整理”等。

5.4 QingStor 特性

• 無限水平擴(kuò)展：系統(tǒng)可無限水平擴(kuò)展，且在存儲(chǔ)容量水平擴(kuò)展時(shí)，數(shù)據(jù)存取的性能線性提升。
• 多區(qū)域：和 QingCloud IaaS 一樣，QingStor 亦為多區(qū)域部署的服務(wù)。用戶可根據(jù)自己的業(yè)務(wù)需求在不同區(qū)域創(chuàng)建存儲(chǔ)空間（Bucket）。
• 高可靠：無單點(diǎn)故障，支持實(shí)時(shí)多副本，具備無條件的數(shù)據(jù)恢復(fù)能力。
• 通用數(shù)據(jù)存儲(chǔ)：每個(gè)用戶可擁有多個(gè)存儲(chǔ)空間。單個(gè)存儲(chǔ)空間（Bucket）容量不限，可存對象（Object）數(shù)量不限，可存對象（Object）類型不限。普通對象（Object）最大可達(dá) 5G ，通過分段上傳 API 上傳的單個(gè)對象（Object）大小最大可達(dá) 50T ，每個(gè)分段最大 5G 。
• 與計(jì)算資源緊密結(jié)合：與 QingCloud IaaS 資源可通過內(nèi)網(wǎng)進(jìn)行數(shù)據(jù)傳輸，保證高效的數(shù)據(jù)傳輸與處理，并節(jié)省用戶的成本。
• 標(biāo)準(zhǔn)用戶接口：向用戶提供標(biāo)準(zhǔn)、規(guī)范且簡單的 API 接口和 SDK 工具包，并提供詳盡的 API 文檔。
• 分段上傳：支持對文件進(jìn)行分段上傳，最大支持 10000 段，每段大小最大可達(dá) 5G 。以允許用戶將大文件在盡可能短的時(shí)間內(nèi)上傳。
• 斷點(diǎn)續(xù)傳：下載支持?jǐn)帱c(diǎn)續(xù)傳，以允許用戶在網(wǎng)絡(luò)質(zhì)量較差的環(huán)境中仍能夠下載資源。
• 安全認(rèn)證模式：基于對稱加密的請求認(rèn)證方式；存儲(chǔ)空間（Bucket）級別的訪問控制，用戶可將存* 儲(chǔ)空間的讀或?qū)憴?quán)限開放給單個(gè)或多個(gè) QingCloud 用戶，或所有人；支持通過 SSL 加密數(shù)據(jù)傳輸。
• 多維度監(jiān)控：監(jiān)控條目包括內(nèi)網(wǎng)出/入流量、外網(wǎng)出/入流量、容量、內(nèi)網(wǎng) API 調(diào)用次數(shù)、外網(wǎng) API 調(diào)用次數(shù)，及容量。各條目監(jiān)控最小粒度均為 1 小時(shí)。

6、如何使用QingStor

除 API 及 用戶指南 文檔外，目前我們支持 Python SDK，控制臺(tái)圖形化界面，及命令行工具:

• 用戶指南：https://docs.qingcloud.com/guide/object_storage.html
• API 文檔: https://docs.qingcloud.com/qingstor/api/index.html
• SDK 文檔: https://docs.qingcloud.com/qingstor/api/sdk/index.html
• CLI 文檔: https://docs.qingcloud.com/qingstor/api/cli/index.html
• 控制臺(tái): https://console.qingcloud.com

7、用戶案例 (Hash Data Warehouse – HDW)

HDW(Hash Data Warehouse)是由北京酷克數(shù)據(jù)科技有限公司開發(fā)，類似 AWS Redshift 的云端數(shù)據(jù)倉庫服務(wù)，產(chǎn)品將于今年 3 月底在青云QingCloud 上線。

HDW 基于 Greenplum Database ，為云計(jì)算平臺(tái)做了大量的系統(tǒng)架構(gòu)及工程優(yōu)化。除了具有快速部署，簡單易用和零前期投入（按使用量收費(fèi)）等商業(yè)優(yōu)勢外，還有如下技術(shù)優(yōu)勢：

• 標(biāo)準(zhǔn)SQL數(shù)據(jù)庫：ANSI SQL 2008標(biāo)準(zhǔn)，OLAP、JDBC/ODB
• 支持ACID，分布式事務(wù)
• 分布式數(shù)據(jù)庫：線性擴(kuò)展，支持上百個(gè)物理節(jié)點(diǎn)
• 與開源數(shù)據(jù)庫兼容，良性生態(tài)系統(tǒng)
• 支持多種語言用戶自定義函數(shù)（UDF）：PLPGSQL、PLPython、PLR、PLJava
• 內(nèi)置常用機(jī)器學(xué)習(xí)算法
• 兼容常用ETL和BI工具，充分利用企業(yè)已有投入
• 軟硬一體優(yōu)化，極高的性價(jià)比
• 無縫集成IaaS云平臺(tái)數(shù)據(jù)服務(wù)，融入云生態(tài)系統(tǒng)

下面演示 HDW 如何與 QingStor 集成。在這個(gè)演示中，我們將把數(shù)據(jù)從 QingStor 中導(dǎo)入到數(shù)據(jù)倉庫，并將最終的查詢結(jié)果回導(dǎo)至 QingStor 。

7.1 創(chuàng)建 Bucket (存儲(chǔ)空間)

創(chuàng)建一個(gè)Bucket，名為”hdw-hashdata-cn”，并在其下創(chuàng)建兩個(gè)目錄“input”和”output”。

7.2 創(chuàng)建 API 密鑰以訪問 QingStor

7.3 創(chuàng)建輸入文件

在本地創(chuàng)建文件 “persons.txt” 和 “orders.txt”，并將其上傳至前面創(chuàng)建的 Bucket “hdw-hashdata-cn” 的 “input”目錄里。

“persons.txt”內(nèi)容:

1,Adams,John,Oxford Street,London2,Bush,George,Fifth Avenue,New York3,Carter,Thomas,Changan Street,Beijing

orders.txt 內(nèi)容

1,77895,32,44678,33,22456,14,24562,15,34674,65

7.4 創(chuàng)建數(shù)據(jù)表

連接 HDW 數(shù)據(jù)倉庫進(jìn)入 Postgres 數(shù)據(jù)庫，執(zhí)行如下圖所示命令創(chuàng)建相應(yīng)的數(shù)據(jù)表(請將里面的 access_key_id 和 secret_access_key 換成你的 API 密鑰)。

注：外部表 e_persons 對應(yīng)前面上傳的 persons.txt 文件，e_orders 對應(yīng) orders.txt 文件，e_result 對應(yīng) Bucket hdw-hashdata-cn 的 output 目錄。

7.5 數(shù)據(jù)遷移

執(zhí)行如下命令將數(shù)據(jù)從外部表（對應(yīng)青云對象存儲(chǔ)的 input 目錄）導(dǎo)入到數(shù)據(jù)倉庫中：

7.6 執(zhí)行如下命令將查詢結(jié)果導(dǎo)出到外部表（對應(yīng)青云對象存儲(chǔ)的 output 目錄）

此時(shí)，可以看到 output 目錄下多了兩個(gè)文件（這是因?yàn)檠菔鞠到y(tǒng)中用了兩個(gè) workers ，每個(gè) worker 往外寫一個(gè)文件對象）：gpqsext.0.0 和 gpqsext.1.0 。

下載 gpqsext.0.0 和 gpqsext.1.0 ，查看內(nèi)容:

在這個(gè)例子中，我們演示了如何將數(shù)據(jù)從 QingStor 里導(dǎo)入到 HDW 數(shù)據(jù)倉庫中，并將查詢結(jié)果回導(dǎo)至青云對象存儲(chǔ)里。基于這兩個(gè)基本功能，我們可以構(gòu)建更復(fù)雜的數(shù)據(jù)倉庫管理功能，如在數(shù)據(jù)倉庫空閑的時(shí)候，將元數(shù)據(jù)和用戶數(shù)據(jù)備份到對象存儲(chǔ)中，釋放計(jì)算資源和存儲(chǔ)資源，節(jié)省成本；當(dāng)下次需要的時(shí)候，利用備份到對象存儲(chǔ)中的數(shù)據(jù)恢復(fù)數(shù)據(jù)倉庫，繼續(xù)正常使用。

8、QingStor 的進(jìn)一步產(chǎn)品規(guī)劃

這里我主要說一下兩個(gè)大的方向。

第一個(gè)方向面向性能。縱然我們在系統(tǒng)架構(gòu)設(shè)計(jì)時(shí)就在各方面考慮了性能，比如多區(qū)域部署，同區(qū)域計(jì)算資源內(nèi)網(wǎng)訪問 QingStor。但為了應(yīng)對更加復(fù)雜的場景，我們在性能方面會(huì)同時(shí)兼顧內(nèi)外網(wǎng)。內(nèi)網(wǎng)方面，我們在做內(nèi)網(wǎng)加速，外網(wǎng)方面我們在做 CDN 。兩者將兼于近期上線。

第二個(gè)方向面向數(shù)據(jù)處理。QingStor 作為海量數(shù)據(jù)存儲(chǔ)池，將會(huì)與青云QingCloud 平臺(tái)上的計(jì)算資源緊密整合，尤其是青云QingCloud 大數(shù)據(jù)平臺(tái)，如 Hadoop、Spark、 Storm 等。同時(shí)我們非常歡迎第三方數(shù)據(jù)處理服務(wù)在青云QingCloud 平臺(tái)上構(gòu)建服務(wù)，如文中的 HDW。

另外，我們也將開發(fā)一些特定的數(shù)據(jù)處理服務(wù)，比如圖形圖像處理，音視頻處理等。

本文到此結(jié)束，感謝北京酷克數(shù)據(jù)科技有限公司提供的 HDW 案例。

相關(guān)QA

1、存儲(chǔ)超過一定規(guī)模有好的性能解決方案嗎？

答：這個(gè)問題不具體。所以我也只能不具體的回答。

存儲(chǔ)是計(jì)算機(jī)系統(tǒng)里在時(shí)間和空間兩個(gè)維度上沖突最為嚴(yán)重的組件。在存儲(chǔ)系統(tǒng)的設(shè)計(jì)過程中，往往會(huì)顧此失彼。之前我在其它場合分享時(shí)曾經(jīng)說過，QingStor的一個(gè)很重要的設(shè)計(jì)思想是: 折衷，也即大家常說的 tradeoff。事實(shí)上 tradeoff 會(huì)出現(xiàn)在各種各樣的場景里，甚至在一個(gè)函數(shù)的設(shè)計(jì)里都會(huì)體現(xiàn)。但據(jù)我個(gè)人經(jīng)驗(yàn)，tradeoff 在存儲(chǔ)系統(tǒng)的設(shè)計(jì)里體現(xiàn)最為明顯。

所以該問題得視具體情況而定。

2、QingStor 有什么前端方案嗎，方便集成在應(yīng)用里。

答：沒有特別理解。但應(yīng)用可以直接調(diào)用QingStor的API。如文中所述，當(dāng)前我們支持Python語言的SDK，接下來會(huì)支持其他主流語言的SDK。屆時(shí)可直接使用。

3、我覺得 AWS 的 lambda 服務(wù)很好，青云有類似的打算么？

答：這個(gè)問題很好。說明提問者對云服務(wù)非常了解。事實(shí)上春節(jié)期間我們已經(jīng)設(shè)計(jì)了一版草案，關(guān)于青云如何構(gòu)建QingCloud 平臺(tái)上的異步事件驅(qū)動(dòng)的服務(wù)框架。由于 QingStor 是 青云QingCloud 眾多服務(wù)中第一個(gè)對異步事件驅(qū)動(dòng)的框架有明確需求的服務(wù)，所以該框架會(huì)融合在 QingStor 的研發(fā)進(jìn)程中來實(shí)現(xiàn)。我們計(jì)劃是下月或者5月份開始研發(fā)。初步規(guī)劃是，先構(gòu)建異步事件框架，然后進(jìn)一步抽象出類似于 AWS Lambda 的服務(wù)。

4、青云QingCloud 的對象存儲(chǔ)技術(shù)對于既有數(shù)據(jù)百億級，日產(chǎn)生新數(shù)據(jù) 5000 萬到 2 億的高寫入并發(fā)，相對較低的查詢并發(fā)場景下有什么方案？

答：并發(fā)的提升涉及到系統(tǒng)的各層次，和許多因素有關(guān)。這個(gè)簡單說幾個(gè)方面:

• 存儲(chǔ)服務(wù)有一個(gè)特性：數(shù)據(jù)流和控制流很難分離，對于對象存儲(chǔ)系統(tǒng)尤其如是。所以對于對象存儲(chǔ)系統(tǒng)而言，要盡量減少數(shù)據(jù)傳輸過程中的中轉(zhuǎn)。
• 擴(kuò)大接入層的集群規(guī)模。
• 優(yōu)化接入層的網(wǎng)絡(luò)鏈路，比如盡量不走Linux kernel的 TCP/IP 協(xié)議棧。
• 利用緩存和隊(duì)列緩沖數(shù)據(jù)的寫入量。

5、單 Accout 支持多少桶，多少對象，存儲(chǔ)空間？

答：初始狀態(tài)限制2個(gè)存儲(chǔ)空間，如果有需要可以提工單提高。如分享中所說，對象數(shù)量沒有限制。

6、對象副本是多少或 EC 配比

答：是三副本，目前還不支持糾刪碼。糾刪碼的支持也是我們今年要做的Feature之一。

關(guān)于作者：楊錦濤（Osier Yang），青云QingCloud 系統(tǒng)工程師，Libvirt Committer，多個(gè)其他虛擬化相關(guān)開源項(xiàng)目的 Committer/Contributor ，QingCloud 對象存儲(chǔ)系統(tǒng)的核心設(shè)計(jì)者與開發(fā)者。對 Open Source、Linux Kernel、虛擬化、分布式存儲(chǔ)、云計(jì)算等領(lǐng)域有深入研究和理解。9 年多職業(yè)生涯沒有離開過 Linux 領(lǐng)域，曾在 Red Hat 度過 6 年職業(yè)生涯，原 Red Hat Cloud BU 開發(fā)者，主攻方向?yàn)樘摂M化。

感謝魏星對本文的審校。

給InfoQ中文站投稿或者參與內(nèi)容翻譯工作，請郵件至editors@cn.infoq.com。也歡迎大家通過新浪微博（@InfoQ，@丁曉昀），微信（微信號：InfoQChina）關(guān)注我們，并與我們的編輯和其他讀者朋友交流（歡迎加入InfoQ讀者交流群（已滿），InfoQ讀者交流群（#2））。