本文來自微信公眾號(hào)“twt企業(yè)IT社區(qū)”，作者/趙海。
1.為什么會(huì)引入分布式存儲(chǔ)技術(shù)
從70年代到2000年左右，數(shù)據(jù)存儲(chǔ)基本上是伴隨著IBM E.F.Code提出的關(guān)系模型理論，以關(guān)系型數(shù)據(jù)庫（Oracle、DB2、MySQL）為數(shù)據(jù)管理平臺(tái)，以集中式存儲(chǔ)產(chǎn)品為數(shù)據(jù)最終載體形成的堅(jiān)實(shí)的數(shù)據(jù)存儲(chǔ)架構(gòu)體系。2000年后，但是隨著數(shù)據(jù)量的增加，單機(jī)的數(shù)據(jù)庫瓶頸已經(jīng)不能滿足大數(shù)據(jù)量的需求，從數(shù)據(jù)管理層面開始誕生分庫分表的方案。自2006年谷歌發(fā)了三篇論文（GFS、Big Table、Map-Reduce）之后，在數(shù)據(jù)管理層面以及數(shù)據(jù)載體層面不斷涌現(xiàn)各類分布式產(chǎn)品，例如GFS、GPFS、HFS、DFS等各類分布式文件系統(tǒng)，例如Hadoop、Hbase、Redis、MongoDB、RockDB等系列分布式數(shù)據(jù)管理平臺(tái)。
總而言之，數(shù)據(jù)量的爆發(fā)式增長(zhǎng)催生了數(shù)據(jù)應(yīng)用領(lǐng)域的各種新需求，數(shù)據(jù)應(yīng)用領(lǐng)域的各種新需求驅(qū)動(dòng)了數(shù)據(jù)管理層面以及數(shù)據(jù)載體層面的分布式變革。
2.主流分布式文件系統(tǒng)技術(shù)分析
主流分布式文件系統(tǒng)技術(shù)主要有GPFS、GFS、HDFS、DFS、ClusterFS等很多，下面我們以同類或類似技術(shù)體系的典型產(chǎn)品為代表進(jìn)行闡述。
2.1 GFS
GFS是基于文件系統(tǒng)實(shí)現(xiàn)的分布式存儲(chǔ)系統(tǒng)，是屬于有中心的分布式架構(gòu)；通過對(duì)中心節(jié)點(diǎn)元數(shù)據(jù)的索引查詢得到數(shù)據(jù)地址空間，然后再去數(shù)據(jù)節(jié)點(diǎn)上查詢數(shù)據(jù)本身的機(jī)制來完成數(shù)據(jù)的讀寫；是基于文件數(shù)據(jù)存儲(chǔ)場(chǎng)景設(shè)計(jì)的架構(gòu)。
接下來，我們來看GFS有哪些具體特性，選型的時(shí)候應(yīng)該如何考慮？
(1)GFS是一種適合大文件，尤其是GB級(jí)別的大文件存儲(chǔ)場(chǎng)景的分布式存儲(chǔ)系統(tǒng)。
(2)GFS非常適合對(duì)數(shù)據(jù)訪問延遲不敏感的搜索引擎服務(wù)。
(3)GFS是一種有中心節(jié)點(diǎn)的分布式架構(gòu)，Master節(jié)點(diǎn)是單一的集中管理節(jié)點(diǎn)，即是高可用的瓶頸，也是可能出現(xiàn)性能問題的瓶頸。
(4)GFS可以通過緩存一份部分Metadata到Client節(jié)點(diǎn)，減少Client與Master的交互。
(5)GFS的Master節(jié)點(diǎn)上的Operation log和Checkpoint文件需要通過復(fù)制方式保留多個(gè)副本，來保障元數(shù)據(jù)以及中心管理功能的高可用性。
2.2 HDFS
HDFS的架構(gòu)原理與GFS基本類似，但是是基于GFS做了一些改進(jìn)之后形成的一套技術(shù)體系。同樣，它基于文件系統(tǒng)實(shí)現(xiàn)的分布式存儲(chǔ)系統(tǒng)，是屬于有中心的分布式架構(gòu)；通過對(duì)中心節(jié)點(diǎn)元數(shù)據(jù)的索引查詢得到數(shù)據(jù)地址空間，然后再去數(shù)據(jù)節(jié)點(diǎn)上查詢數(shù)據(jù)本身的機(jī)制來完成數(shù)據(jù)的讀寫；是基于文件數(shù)據(jù)存儲(chǔ)場(chǎng)景設(shè)計(jì)的架構(gòu)。
接下來，我們來看HDFS有哪些具體特性，選型的時(shí)候應(yīng)該如何考慮？
(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.3 GlusterFS
GlusterFS雖然是基于文件系統(tǒng)的分布式存儲(chǔ)技術(shù)，但是它與GFS架構(gòu)有本質(zhì)的區(qū)別，它是去中心化的無中心分布式架構(gòu)；它是通過對(duì)文件全目錄的DHT算法計(jì)算得到相應(yīng)的Brike地址，從而實(shí)現(xiàn)對(duì)數(shù)據(jù)的讀寫，這與GFS以及HDFS等通過元數(shù)據(jù)檢索實(shí)現(xiàn)數(shù)據(jù)尋址的方式有極大的不同。
接下來，我們來看GlusterFS都有哪些具體特性，選型的時(shí)候應(yīng)該如何考慮？**
(1)GlusterFS是采用無中心對(duì)稱式架構(gòu)，沒有專用的元數(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ì)初衷來看，更適合大文件并發(fā)的場(chǎng)景。
(5)GlusterFS采用的DHT算法不具備良好的穩(wěn)定性，一旦存儲(chǔ)節(jié)點(diǎn)發(fā)生增減變化，勢(shì)必影響卷下面所有Brike的數(shù)據(jù)進(jìn)行再平衡操作，開銷比較大。
(6)GlusterFS文件目錄利用擴(kuò)展屬性記錄子卷的中brick的hash分布范圍，每個(gè)brick的范圍均不重疊。遍歷目錄時(shí)，需要獲取每個(gè)文件的屬性和擴(kuò)展屬性進(jìn)行聚合，當(dāng)目錄文件較多時(shí)，遍歷效率很差。
3.主流分布式對(duì)象存儲(chǔ)技術(shù)分析
目前應(yīng)用比較廣發(fā)的分布式對(duì)象存儲(chǔ)技術(shù)基本都是基于Swift或者Ceph體系衍生出來的產(chǎn)品。
3.1 Ceph
Ceph首先是一種對(duì)象存儲(chǔ)技術(shù)，也就是說它存儲(chǔ)數(shù)據(jù)的機(jī)制與我們之前接觸的文件系統(tǒng)機(jī)制是完全不一樣的，它是將數(shù)據(jù)抽象為對(duì)象和對(duì)象標(biāo)識(shí)來進(jìn)行管理。從架構(gòu)上來講，Ceph相對(duì)類似于GlusterFS的無中心化架構(gòu)；它是通過對(duì)對(duì)象的哈希算法得到相應(yīng)的Bucket&Node地址，從而實(shí)現(xiàn)對(duì)數(shù)據(jù)的讀寫。
接下來，我們來看Ceph都有哪些具體特性，選型的時(shí)候應(yīng)該如何考慮？
(1)Ceph是一種統(tǒng)一了三種接口的統(tǒng)一存儲(chǔ)平臺(tái)，上層應(yīng)用支持Object、Block、File。
(2)Ceph采用Crush算法完成數(shù)據(jù)分布計(jì)算，通過Tree的邏輯對(duì)象數(shù)據(jù)結(jié)構(gòu)自然實(shí)現(xiàn)故障隔離副本位置計(jì)算，通過將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)Ceph對(duì)象保存的最小單元為4M，相比GFS&HDFS而言，適合一些小的非結(jié)構(gòu)化數(shù)據(jù)存儲(chǔ)。
3.2 Swift
Swifty也是是一種對(duì)象存儲(chǔ)技術(shù)，它與Ceph的架構(gòu)有類似的地方，也是無中心化架構(gòu)；它是通過對(duì)對(duì)象的哈希算法得到相應(yīng)的Bucket&Node地址，從而實(shí)現(xiàn)對(duì)數(shù)據(jù)的讀寫。但是Swift是需要通過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)秀一些。
接下來，我們來看Swift都有哪些具體特性，選型的時(shí)候應(yīng)該如何考慮？
(1)Swift只保障數(shù)據(jù)的最終一致性，寫完2個(gè)副本后即可Commit，這就導(dǎo)致讀操作需要進(jìn)行副本的對(duì)比校驗(yàn)，讀的效率相對(duì)較低。
(2)Swift采用一致性哈希算法完成數(shù)據(jù)分布計(jì)算，通過首次計(jì)算對(duì)象針對(duì)邏輯對(duì)象（Zone）的映射實(shí)現(xiàn)數(shù)據(jù)副本的故障隔離分布，然后通過哈希一致性算法完成對(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ù)的訪問，不同通過客戶端直接訪問數(shù)據(jù)節(jié)點(diǎn)，相對(duì)數(shù)據(jù)的訪問效率來講，比Ceph要差一些(可以參照ICCLAB&SPLAB的性能測(cè)試報(bào)告)。
4.主流分布式數(shù)據(jù)庫技術(shù)分析
目前在分布式數(shù)據(jù)庫技術(shù)的應(yīng)用場(chǎng)景下，各行各業(yè)采用的產(chǎn)品比較多，尤其是NOSQL&NewSQL領(lǐng)域。記下來我們以文檔、健值、內(nèi)存、列式等幾個(gè)典型分類來進(jìn)行闡述。
4.1 MongoDB
MongoDB是以二進(jìn)制JSON或叫BSON格式存儲(chǔ)文檔數(shù)據(jù)為數(shù)據(jù)模型，專門為文檔存儲(chǔ)設(shè)計(jì)。當(dāng)查詢MongoDB并返回結(jié)果時(shí)，這些數(shù)據(jù)就會(huì)轉(zhuǎn)換為易于閱讀的數(shù)據(jù)格式。它的所謂分布式主要是指它的切片集群機(jī)制。通過基于范圍的分區(qū)機(jī)制來實(shí)現(xiàn)水平擴(kuò)展，稱為分片機(jī)制，它可以自動(dòng)化管理每個(gè)分布式節(jié)點(diǎn)存儲(chǔ)的數(shù)據(jù)。
接下來，我們來看MongoDB都有哪些具體特性，選型的時(shí)候應(yīng)該如何考慮。
(1)MongoDB面向集合存儲(chǔ)，模式自由，易存儲(chǔ)對(duì)象類型的數(shù)據(jù)，文件存儲(chǔ)格式為JSON，從這個(gè)角度來講，我們需要從數(shù)據(jù)業(yè)務(wù)場(chǎng)景角度去剖析其與MongoDB數(shù)據(jù)模型的契合性。
(2)MongoDB使用高效的二進(jìn)制數(shù)據(jù)存儲(chǔ)，包括大型對(duì)象，因此比較適合媒體、視頻之類的大對(duì)象的存取場(chǎng)景。
(3)MongoDB支持支持動(dòng)態(tài)查詢，支持完全索引，支持RUBY，PYTHON，JAVA，C，PHP，C#等多種語言，因此它與前端應(yīng)用匹配的靈活性很強(qiáng)，適用于很多場(chǎng)景。
(4)MongoDB水平擴(kuò)展能力較強(qiáng)，可以通過分布式集群架構(gòu)將數(shù)據(jù)分布到多臺(tái)機(jī)器，并且有完善的支持復(fù)制和故障恢復(fù)機(jī)制，支持海量數(shù)據(jù)的處理場(chǎng)景。
4.2 Redis
Redis是一個(gè)開源的使用ANSI C語言編寫、遵守BSD協(xié)議、支持網(wǎng)絡(luò)、可基于內(nèi)存、分布式、可選持久性的鍵值對(duì)(Key-Value)存儲(chǔ)數(shù)據(jù)庫，并提供多種語言的API。Redis通常被稱為數(shù)據(jù)結(jié)構(gòu)服務(wù)器，因?yàn)橹担╲alue）可以是字符串(String)、哈希(Hash)、列表(list)、集合(sets)和有序集合(sorted sets)等類型。
接下來，我們來看Redis都有哪些具體特性，選型的時(shí)候應(yīng)該如何考慮？
(1)Redis所有數(shù)據(jù)是存放在內(nèi)存中的，源代碼采用C語言編寫，距離底層操作系統(tǒng)更近，并且使用單線程架構(gòu)，避免了多線程可能產(chǎn)生的競(jìng)爭(zhēng)開銷。以上決定了它是執(zhí)行速度非常快的數(shù)據(jù)庫。
(2)Redis不僅僅支持簡(jiǎn)單的key-value類型的數(shù)據(jù)，同時(shí)還提供list，set，zset，hash等數(shù)據(jù)結(jié)構(gòu)的存儲(chǔ)。結(jié)合這個(gè)相對(duì)比較靈活的數(shù)據(jù)模型，Redis通常被用來作為高速緩存使用。
(3)Redis提供兩種持久化方案AOF和RDB，因此它不僅僅適合高速緩存場(chǎng)景，而且適合基于此需求的衍生性業(yè)務(wù)場(chǎng)景。
(4)Redis從3.0版本后開始支持集群模式，很好的實(shí)現(xiàn)了處理能力的水平擴(kuò)展，結(jié)合它的速度快的特性，這就為互聯(lián)網(wǎng)電子商務(wù)的高并發(fā)場(chǎng)景提供了解決方案。
4.3 Hbase
Hbase是Google Bigtable的開源實(shí)現(xiàn)，與Bigtable利用GFS作為其文件存儲(chǔ)系統(tǒng)類似，HBase利用Hadoop HDFS作為其文件存儲(chǔ)系統(tǒng);運(yùn)行MapReduce來處理Bigtable中的海量數(shù)據(jù)。因此從源頭來看，Hbase是為大數(shù)據(jù)處理提供的數(shù)據(jù)存取解決方案，可稱為列式數(shù)據(jù)庫。
接下來，我們來看Hbase都有哪些具體特性，選型的時(shí)候應(yīng)該如何考慮。
(1)Hbase與很多面向行存儲(chǔ)的關(guān)系型數(shù)據(jù)庫不同，HBase是面向列的存儲(chǔ)和權(quán)限控制的，它里面的每個(gè)列是單獨(dú)存儲(chǔ)的，且支持基于列的獨(dú)立檢索。因此它天然適合分析類應(yīng)用（OLAP）。
(2)HBase中的數(shù)據(jù)都是以字符串形式存儲(chǔ)的，為空的列并不占用存儲(chǔ)空間，因此HBase的列存儲(chǔ)解決了數(shù)據(jù)稀疏性的問題，通常可以設(shè)計(jì)成稀疏矩陣，在很大程度上節(jié)省了存儲(chǔ)開銷。
(3)HBase的單表容量非常大，可以有百億行、百萬列，可以在橫向和縱向兩個(gè)維度插入數(shù)據(jù)，具有很強(qiáng)的彈性。HBase采用LSM樹作為內(nèi)部數(shù)據(jù)存儲(chǔ)結(jié)構(gòu)，這種結(jié)構(gòu)會(huì)周期性地將較小文件合并成大文件，以減少對(duì)磁盤的訪問。這些特性尤其適合單表數(shù)據(jù)量巨大的數(shù)據(jù)存取場(chǎng)景。
5.總結(jié)與展望
通過對(duì)分布式存儲(chǔ)技術(shù)架構(gòu)體系的綜述分析，我們首先區(qū)分了不同技術(shù)體系究竟是應(yīng)該用在數(shù)據(jù)管理場(chǎng)景還是數(shù)據(jù)載體場(chǎng)景。隨后我們通過對(duì)不同體系的分布式存儲(chǔ)技術(shù)典型產(chǎn)品特性的分析，明確了不同技術(shù)產(chǎn)品的數(shù)據(jù)模型、數(shù)據(jù)訪問、數(shù)據(jù)性能、數(shù)據(jù)量級(jí)等不同層面的優(yōu)劣勢(shì)，最終希望通過這些典型特性的了解以及對(duì)具體業(yè)務(wù)場(chǎng)景的數(shù)據(jù)需求挖掘，能將比較優(yōu)秀的數(shù)據(jù)存儲(chǔ)技術(shù)匹配到最合適的業(yè)務(wù)場(chǎng)景中。
