主流分布式存儲(chǔ)技術(shù)對(duì)比分析

【導(dǎo)讀】 如今分布式存儲(chǔ)產(chǎn)品眾多令人眼花繚亂，如何選型？要根據(jù)其背后的核心架構(gòu)來(lái)分析它本來(lái)的原貌，然后才能決定其是否適合我們的具體場(chǎng)景。

【作者】 趙海

1 引言

目前市面上各個(gè)廠家的分布式存儲(chǔ)產(chǎn)品五花八門，但是如果透過(guò)產(chǎn)品本身的包裝看到其背后的核心技術(shù)體系，基本上會(huì)分為兩種架構(gòu)，一種是有中心架構(gòu)的分布式文件系統(tǒng)架構(gòu)，以GFS、HDFS為代表；另外一種是完全無(wú)中心的分布式存儲(chǔ)架構(gòu)，以Ceph、Swift、GlusterFS為代表。對(duì)具體分布式存儲(chǔ)產(chǎn)品選型的時(shí)候，要根據(jù)其背后的核心架構(gòu)來(lái)分析它本來(lái)的原貌，然后才能決定其是否適合我們的具體場(chǎng)景。

2 主流分布式存儲(chǔ)技術(shù)對(duì)比分析

2.1 GFS & HDFS

GFS和HDFS都是基于文件系統(tǒng)實(shí)現(xiàn)的分布式存儲(chǔ)系統(tǒng)；都是有中心的分布式架構(gòu) （圖2.1） ；通過(guò)對(duì)中心節(jié)點(diǎn)元數(shù)據(jù)的索引查詢得到數(shù)據(jù)地址空間，然后再去數(shù)據(jù)節(jié)點(diǎn)上查詢數(shù)據(jù)本身的機(jī)制來(lái)完成數(shù)據(jù)的讀寫；都是基于文件數(shù)據(jù)存儲(chǔ)場(chǎng)景設(shè)計(jì)的架構(gòu) ；都是適合順序?qū)懭腠樞蜃x取，對(duì)隨機(jī)讀寫不友好。

圖2.1 中心化的分布式存儲(chǔ)架構(gòu)

接下來(lái)，我們來(lái)看GFS和HDFS都有哪些具體特性，我們應(yīng)該如何應(yīng)用？

1. GFS是一種適合大文件，尤其是GB級(jí)別的大文件存儲(chǔ)場(chǎng)景的分布式存儲(chǔ)系統(tǒng)。
2. GFS非常適合對(duì)數(shù)據(jù)訪問(wèn)延遲不敏感的搜索引擎服務(wù)。
3. GFS是一種有中心節(jié)點(diǎn)的分布式架構(gòu)，Master節(jié)點(diǎn)是單一的集中管理節(jié)點(diǎn)，既是高可用的瓶頸，也是可能出現(xiàn)性能問(wèn)題的瓶頸。
4. GFS可以通過(guò)緩存一部分Metadata到Client節(jié)點(diǎn)，減少Client與Master的交互。
5. GFS的Master節(jié)點(diǎn)上的Operation log和Checkpoint文件需要通過(guò)復(fù)制方式保留多個(gè)副本，來(lái)保障元數(shù)據(jù)以及中心管理功能的高可用性。

相對(duì)于GFS來(lái)說(shuō)，我們來(lái)看HDFS做了哪些區(qū)別？

1. HDFS的默認(rèn)最小存儲(chǔ)單元為128M，比GFS的64M更大。
2. HDFS不支持文件并發(fā)寫，對(duì)于單個(gè)文件它僅允許有一個(gè)寫或者追加請(qǐng)求。
3. HDFS從2.0版本之后支持兩個(gè)管理節(jié)點(diǎn)（NameNode），主備切換可以做到分鐘級(jí)別。
4. HDFS 更適合單次寫多次讀的大文件流式讀取的場(chǎng)景。
5. HDFS不支持對(duì)已寫文件的更新操作，僅支持對(duì)它的追加操作。

2.2 GlusterFS

GlusterFS雖然是基于文件系統(tǒng)的分布式存儲(chǔ)技術(shù)，但是它與GFS/HDFS有本質(zhì)的區(qū)別，它是去中心化的無(wú)中心分布式架構(gòu)（圖2.2）；它是通過(guò)對(duì)文件全目錄的DHT算法計(jì)算得到相應(yīng)的Brike地址，從而實(shí)現(xiàn)對(duì)數(shù)據(jù)的讀寫；它與Ceph/Swift的架構(gòu)區(qū)別在于它沒(méi)有集中收集保存集群拓?fù)浣Y(jié)構(gòu)信息的存儲(chǔ)區(qū)，因此在做計(jì)算的時(shí)候，需要遍歷整個(gè)卷的Brike信息。

圖2.2 Gluster FS

接下來(lái)，我們來(lái)看GlusterFS都有哪些具體特性，我們應(yīng)該如何應(yīng)用？

1. GlusterFS是采用無(wú)中心對(duì)稱式架構(gòu)，沒(méi)有專用的元數(shù)據(jù)服務(wù)器，也就不存在元數(shù)據(jù)服務(wù)器瓶頸。元數(shù)據(jù)存在于文件的屬性和擴(kuò)展屬性中 。
2. GlusterFS可以提供Raid0、Raid1、Raid1+0等多種類型存儲(chǔ)卷類型。
3. GlusterFS采用數(shù)據(jù)最終一致性算法，只要有一個(gè)副本寫完就可以Commit。
4. GlusterFS默認(rèn)會(huì)將文件切分為128KB的切片，然后分布于卷對(duì)應(yīng)的所有Brike當(dāng)中。所以從其設(shè)計(jì)初衷來(lái)看，更適合大文件并發(fā)的場(chǎng)景。
5. GlusterFS 采用的DHT算法不具備良好的穩(wěn)定性，一旦存儲(chǔ)節(jié)點(diǎn)發(fā)生增減變化，勢(shì)必影響卷下面所有Brike的數(shù)據(jù)進(jìn)行再平衡操作，開銷比較大。
6. Gluster FS文件 目錄利用擴(kuò)展屬性記錄子卷的中brick的hash分布范圍，每個(gè)brick的范圍均不重疊。遍歷目錄時(shí)，需要獲取每個(gè)文件的屬性和擴(kuò)展屬性進(jìn)行聚合，當(dāng)目錄文件 較多 時(shí)，遍歷 效率很差 。

2.3 Ceph & Swift

我們知道， 相對(duì)于文件系統(tǒng)的中心架構(gòu)分布式存儲(chǔ)技術(shù)，Ceph&Swift都是去中心化的無(wú)中心分布式架構(gòu)（圖2.3）；他們底層都是對(duì)象存儲(chǔ)技術(shù)；他們都是通過(guò)對(duì)對(duì)象的哈希算法得到相應(yīng)的Bucket&Node地址，從而實(shí)現(xiàn)對(duì)數(shù)據(jù)的讀寫 。

圖2.3 去中心化的分布式存儲(chǔ)架構(gòu)

接下來(lái)，我們來(lái)看Ceph和Swift都有哪些具體特性，我們應(yīng)該如何應(yīng)用？

1. Ceph是一種統(tǒng)一了三種接口的統(tǒng)一存儲(chǔ)平臺(tái)，上層應(yīng)用支持Object、Block、File 。
2. Ceph采用Crush算法完成數(shù)據(jù)分布計(jì)算，通過(guò)Tree的邏輯對(duì)象數(shù)據(jù)結(jié)構(gòu)自然實(shí)現(xiàn)故障隔離副本位置計(jì)算，通過(guò)將Bucket內(nèi)節(jié)點(diǎn)的組織結(jié)構(gòu)，集群結(jié)構(gòu)變化導(dǎo)致的數(shù)據(jù)遷移量最小。
3. Ceph保持?jǐn)?shù)據(jù)強(qiáng)一致性算法，數(shù)據(jù)的所有副本都寫入并返回才算寫事務(wù)的完成，寫的效率會(huì)差一些，所以更適合寫少讀多的場(chǎng)景。
4. 對(duì)象保存的最小單元為4M，相比GFS&HDFS而言，適合一些小的非結(jié)構(gòu)化數(shù)據(jù)存儲(chǔ)。

雖然底層都是對(duì)象存儲(chǔ)，相對(duì)于Ceph來(lái)說(shuō)，Swift又有哪些獨(dú)特的特性呢？

1. Swift只保障數(shù)據(jù)的最終一致性，寫完2個(gè)副本后即可Commit，這就導(dǎo)致讀操作需要進(jìn)行副本的對(duì)比校驗(yàn)，讀的效率相對(duì)較低。
2. Swift采用一致性哈希算法完成數(shù)據(jù)分布計(jì)算，通過(guò)首次計(jì)算對(duì)象針對(duì)邏輯對(duì)象（Zone）的映射實(shí)現(xiàn)數(shù)據(jù)副本的故障隔離分布，然后通過(guò)哈希一致性算法完成對(duì)象在Bucket當(dāng)中的分布計(jì)算，采用Ring環(huán)結(jié)構(gòu)組織Bucket節(jié)點(diǎn)組織，數(shù)據(jù)分布不如Ceph均勻。
3. Swift 需要借助Proxy節(jié)點(diǎn)完成對(duì)數(shù)據(jù)的訪問(wèn)，不同于通過(guò)客戶端直接訪問(wèn)數(shù)據(jù)節(jié)點(diǎn)，相對(duì)數(shù)據(jù)的訪問(wèn)效率來(lái)講，比Ceph要差一些。

總結(jié)來(lái)看，由于Swift需要通過(guò)Proxy節(jié)點(diǎn)完成與數(shù)據(jù)節(jié)點(diǎn)的交互，雖然Proxy節(jié)點(diǎn)可以負(fù)載均衡，但是畢竟經(jīng)歷了中間層，在并發(fā)量較大而且小文件操作量比較的場(chǎng)景下，Ceph的性能表現(xiàn)會(huì)優(yōu)秀一些。 為了說(shuō)明我們從原理層面的判斷，接下來(lái)借助ICCLAB&SPLAB的性能測(cè)試結(jié)果來(lái)說(shuō)明。

表1 Ceph集群配置

表2 Swift集群配置

以上是測(cè)試本身對(duì)于Ceph和Swift的節(jié)點(diǎn)及物理對(duì)象配置信息，從表的對(duì)比，基本可以看出物理硬件配置都是相同的，只不過(guò)在Swift的配置當(dāng)中還需要配置Container相關(guān)邏輯對(duì)象。

{x}count{y}kb，x表示Swift集群當(dāng)中設(shè)置的Container數(shù)量，y表示進(jìn)行壓力測(cè)試所用的數(shù)據(jù)大小。從圖中表現(xiàn)出來(lái)的性能趨勢(shì)分析：

1. Container的數(shù)量越多，Swift的讀寫性能會(huì)相對(duì)差一些；
2. 在4K-128K數(shù)據(jù)大小的范圍內(nèi)，Ceph和Swift的讀性能表現(xiàn)都是最佳的；
3. 在4K-64K數(shù)據(jù)大小范圍內(nèi)，Ceph的讀性能幾乎是Swift的2-3倍，但是寫的性能相差不是非常大。

Ceph_{x}Swift{x},x表示并發(fā)數(shù)量。從圖中表現(xiàn)出來(lái)的性能趨勢(shì)分析：

1. 對(duì)于并發(fā)讀操作，Ceph的表現(xiàn)上明顯優(yōu)于Swift，無(wú)論是穩(wěn)定性還是IOPS指標(biāo)；
2. 對(duì)于并發(fā)寫操作，Ceph的并發(fā)量越高其性能表現(xiàn)越接近Swift，并發(fā)量越少其性能表現(xiàn)會(huì)明顯遜色于Swift。
3. 對(duì)于并發(fā)讀寫操作的性能穩(wěn)定性上，Ceph遠(yuǎn)勝于Swift。

3 結(jié)語(yǔ)

通過(guò)對(duì)主流分布式存儲(chǔ)技術(shù)的各項(xiàng)特性分析梳理之后，我們基本上可以得出以下若干結(jié)論：

1. GFS/HDFS還是適合特定大文件應(yīng)用的分布式文件存儲(chǔ)系統(tǒng)（搜索、大數(shù)據(jù)...）；
2. GlusterFS是可以代替NAS的通用分布式文件系統(tǒng)存儲(chǔ)技術(shù)，可配置性較強(qiáng)；
3. Ceph是平衡各個(gè)維度之后相對(duì)比較寬容的統(tǒng)一分布式存儲(chǔ)技術(shù)；
4. 分布式存儲(chǔ)技術(shù)終究不適合應(yīng)用到熱點(diǎn)比較集中的關(guān)系型數(shù)據(jù)庫(kù)的存儲(chǔ)卷場(chǎng)景上。