?1. 為什么會引入分布式存儲技術

從70年代到2000年左右，數(shù)據(jù)存儲基本上是伴隨著IBM E.F.Code提出的關系模型理論，以關系型數(shù)據(jù)庫（Oracle、DB2、MySQL）為數(shù)據(jù)管理平臺，以集中式存儲產(chǎn)品為數(shù)據(jù)最終載體形成的堅實的數(shù)據(jù)存儲架構體系。2000年后，但是隨著數(shù)據(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ù)管理平臺。

總而言之，數(shù)據(jù)量的爆發(fā)式增長催生了數(shù)據(jù)應用領域的各種新需求，數(shù)據(jù)應用領域的各種新需求驅動了數(shù)據(jù)管理層面以及數(shù)據(jù)載體層面的分布式變革。

2. 主流分布式文件系統(tǒng)技術分析

主流分布式文件系統(tǒng)技術主要有GPFS、GFS、HDFS、DFS、ClusterFS等很多，下面我們以同類或類似技術體系的典型產(chǎn)品為代表進行闡述。

2.1 GFS

GFS是基于文件系統(tǒng)實現(xiàn)的分布式存儲系統(tǒng)，是屬于有中心的分布式架構；通過對中心節(jié)點元數(shù)據(jù)的索引查詢得到數(shù)據(jù)地址空間，然后再去數(shù)據(jù)節(jié)點上查詢數(shù)據(jù)本身的機制來完成數(shù)據(jù)的讀寫；是基于文件數(shù)據(jù)存儲場景設計的架構。

接下來，我們來看GFS有哪些具體特性，選型的時候應該如何考慮？

(1) GFS是一種適合大文件，尤其是GB級別的大文件存儲場景的分布式存儲系統(tǒng)。

(2) GFS非常適合對數(shù)據(jù)訪問延遲不敏感的搜索引擎服務。

(3) GFS是一種有中心節(jié)點的分布式架構，Master節(jié)點是單一的集中管理節(jié)點，即是高可用的瓶頸，也是可能出現(xiàn)性能問題的瓶頸。

(4) GFS可以通過緩存一份部分Metadata到Client節(jié)點，減少Client與Master的交互。

(5) GFS的Master節(jié)點上的Operation log和Checkpoint文件需要通過復制方式保留多個副本，來保障元數(shù)據(jù)以及中心管理功能的高可用性。

2.2 HDFS

HDFS的架構原理與GFS基本類似，但是是基于GFS做了一些改進之后形成的一套技術體系。同樣，它基于文件系統(tǒng)實現(xiàn)的分布式存儲系統(tǒng)，是屬于有中心的分布式架構；通過對中心節(jié)點元數(shù)據(jù)的索引查詢得到數(shù)據(jù)地址空間，然后再去數(shù)據(jù)節(jié)點上查詢數(shù)據(jù)本身的機制來完成數(shù)據(jù)的讀寫；是基于文件數(shù)據(jù)存儲場景設計的架構。

接下來，我們來看HDFS有哪些具體特性，選型的時候應該如何考慮？

(1) HDFS的默認最小存儲單元為128M， 比GFS的64M更大。

(2) HDFS不支持文件并發(fā)寫，對于單個文件它僅允許有一個寫或者追加請求。

(3) HDFS從2.0版本之后支持兩個管理節(jié)點（NameNode），主備切換可以做到分鐘級別 。

(4) HDFS更適合單次寫多次讀的大文件流式讀取的場景。

(5) HDFS不支持對已寫文件的更新操作，僅支持對它的追加操作。

2.3 GlusterFS

GlusterFS雖然是基于文件系統(tǒng)的分布式存儲技術，但是它與GFS架構有本質的區(qū)別，它是去中心化的無中心分布式架構； 它是通過對文件全目錄的DHT算法計算得到相應的Brike地址 ，從而實現(xiàn)對數(shù)據(jù)的讀寫，這與GFS以及HDFS等通過元數(shù)據(jù)檢索實現(xiàn)數(shù)據(jù)尋址的方式有極大的不同。

接下來，我們來看GlusterFS都有哪些具體特性，選型的時候應該如何考慮？**

(1) GlusterFS是采用無中心對稱式架構，沒有專用的元數(shù)據(jù)服務器，也就不存在元數(shù)據(jù)服務器瓶頸。元數(shù)據(jù)存在于文件的屬性和擴展屬性中。

(2) GlusterFS可以提供Raid0、Raid1、Raid1+0等多種類型存儲卷類型。

(3) GlusterFS采用數(shù)據(jù)最終一致性算法，只要有一個副本寫完就可以Commit。

(4) GlusterFS默認會將文件切分為128KB的切片，然后分布于卷對應的所有Brike當中。所以從其設計初衷來看，更適合大文件并發(fā)的場景。

(5) GlusterFS 采用的DHT算法不具備良好的穩(wěn)定性，一旦存儲節(jié)點發(fā)生增減變化，勢必影響卷下面所有Brike的數(shù)據(jù)進行再平衡操作，開銷比較大。

(6) GlusterFS文件目錄利用擴展屬性記錄子卷的中brick的hash分布范圍，每個brick的范圍均不重疊。遍歷目錄時，需要獲取每個文件的屬性和擴展屬性進行聚合，當目錄文件較多時，遍歷效率很差。

3. 主流分布式對象存儲技術分析

目前應用比較廣發(fā)的分布式對象存儲技術基本都是基于Swift或者Ceph體系衍生出來的產(chǎn)品。

3.1 Ceph

Ceph首先是一種對象存儲技術，也就是說它存儲數(shù)據(jù)的機制與我們之前接觸的文件系統(tǒng)機制是完全不一樣的，它是將數(shù)據(jù)抽象為對象和對象標識來進行管理。 從架構上來講，Ceph相對類似于GlusterFS的無中心化架構；它是通過對對象的哈希算法得到相應的Bucket&Node地址，從而實現(xiàn)對數(shù)據(jù)的讀寫 。

接下來，我們來看Ceph都有哪些具體特性，選型的時候應該如何考慮？

(1) Ceph是一種統(tǒng)一了三種接口的統(tǒng)一存儲平臺，上層應用支持Object、Block、File。

(2) Ceph采用Crush算法完成數(shù)據(jù)分布計算，通過Tree的邏輯對象數(shù)據(jù)結構自然實現(xiàn)故障隔離副本位置計算，通過將Bucket內節(jié)點的組織結構，集群結構變化導致的數(shù)據(jù)遷移量最小。

(3) Ceph保持數(shù)據(jù)強一致性算法，數(shù)據(jù)的所有副本都寫入并返回才算寫事務的完成，寫的效率會差一些，所以更適合寫少讀多的場景。

(4) Ceph對象保存的最小單元為4M，相比GFS&HDFS而言，適合一些小的非結構化數(shù)據(jù)存儲。

3.2 Swift

Swifty也是是一種對象存儲技術，它與Ceph的架構有類似的地方，也是 無中心化架構；它是通過對對象的哈希算法得到相應的Bucket&Node地址，從而實現(xiàn)對數(shù)據(jù)的讀寫 。但是Swift是需要通過Proxy節(jié)點完成與數(shù)據(jù)節(jié)點的交互，雖然Proxy節(jié)點可以負載均衡，但是畢竟經(jīng)歷了中間層，在并發(fā)量較大而且小文件操作量比較的場景下，Ceph的性能表現(xiàn)會優(yōu)秀一些。

接下來，我們來看Swift都有哪些具體特性，選型的時候應該如何考慮？

(1) Swift只保障數(shù)據(jù)的最終一致性，寫完2個副本后即可Commit，這就導致讀操作需要進行副本的對比校驗，讀的效率相對較低。

(2) Swift采用一致性哈希算法完成數(shù)據(jù)分布計算，通過首次計算對象針對邏輯對象（Zone）的映射實現(xiàn)數(shù)據(jù)副本的故障隔離分布，然后通過哈希一致性算法完成對象在Bucket當中的分布計算，采用Ring環(huán)結構組織Bucket節(jié)點組織，數(shù)據(jù)分布不如Ceph均勻。

(3) Swift 需要借助Proxy節(jié)點完成對數(shù)據(jù)的訪問，不同通過客戶端直接訪問數(shù)據(jù)節(jié)點，相對數(shù)據(jù)的訪問效率來講，比Ceph要差一些( 可以參照ICCLAB&SPLAB的性能測試報告 )。

4. 主流分布式數(shù)據(jù)庫技術分析

目前在分布式數(shù)據(jù)庫技術的應用場景下，各行各業(yè)采用的產(chǎn)品比較多，尤其是NOSQL&NewSQL領域。記下來我們以文檔、健值、內存、列式等幾個典型分類來進行闡述。

4.1 MongoDB

MongoDB是以二進制JSON 或叫BSON 格式存儲文檔數(shù)據(jù) 為數(shù)據(jù)模型 ，專門為文檔存儲設計。當查詢MongoDB并返回結果時，這些數(shù)據(jù)就會轉換為易于閱讀的數(shù)據(jù)格式。它的所謂分布式主要是指它的切片集群機制。通過基于范圍的分區(qū)機制來實現(xiàn)水平擴展，稱為分片機制，它可以自動化管理每個分布式節(jié)點存儲的數(shù)據(jù)。

接下來，我們來看MongoDB都有哪些具體特性，選型的時候應該如何考慮。

(1) MongoDB面向集合存儲，模式自由，易存儲對象類型的數(shù)據(jù)，文件存儲格式為JSON，從這個角度來講，我們需要從數(shù)據(jù)業(yè)務場景角度去剖析其與MongoDB數(shù)據(jù)模型的契合性。

(2) MongoDB使用高效的二進制數(shù)據(jù)存儲，包括大型對象，因此比較適合媒體、視頻之類的大對象的存取場景。

(3) MongoDB支持支持動態(tài)查詢，支持完全索引，支持RUBY，PYTHON，JAVA，C ，PHP，C#等多種語言，因此它與前端應用匹配的靈活性很強，適用于很多場景。

(4) MongoDB水平擴展能力較強，可以通過分布式集群架構將數(shù)據(jù)分布到多臺機器，并且有完善的支持復制和故障恢復機制，支持海量數(shù)據(jù)的處理場景。

4.2 Redis

Redis 是一個開源的使用 ANSI C 語言編寫、遵守 BSD 協(xié)議、支持網(wǎng)絡、 可基于內存 、分布式、可選持久性的 鍵值對(Key-Value)存儲數(shù)據(jù)庫 ，并提供多種語言的API。Redis 通常被稱為數(shù)據(jù)結構服務器，因為值（value）可以是字符串(String)、哈希(Hash)、列表(list)、集合(sets)和有序集合(sorted sets)等類型。

接下來，我們來看Redis都有哪些具體特性，選型的時候應該如何考慮？

(1) Redis所有數(shù)據(jù)是存放在內存中的，源代碼采用C語言編寫，距離底層操作系統(tǒng)更近，并且使用單線程架構，避免了多線程可能產(chǎn)生的競爭開銷。以上決定了它是執(zhí)行速度非?？斓臄?shù)據(jù)庫。

(2) Redis不僅僅支持簡單的key-value類型的數(shù)據(jù)，同時還提供list，set，zset，hash等數(shù)據(jù)結構的存儲。結合這個相對比較靈活的數(shù)據(jù)模型，Redis通常被用來作為高速緩存使用。

(3) Redis提供兩種持久化方案AOF和RDB，因此它不僅僅適合高速緩存場景，而且適合基于此需求的衍生性業(yè)務場景。

(4) Redis從3.0版本后開始支持集群模式，很好的實現(xiàn)了處理能力的水平擴展，結合它的速度快的特性，這就為互聯(lián)網(wǎng)電子商務的高并發(fā)場景提供了解決方案。

4.3 Hbase

Hbase 是 Google Bigtable 的開源實現(xiàn)，與 Bigtable 利用 GFS 作為其文件存儲系統(tǒng)類似，HBase 利用 Hadoop HDFS 作為其文件存儲系統(tǒng); 運行 MapReduce 來處理 Bigtable 中的海量數(shù)據(jù)。因此從源頭來看，Hbase是為大數(shù)據(jù)處理提供的數(shù)據(jù)存取解決方案，可稱為列式數(shù)據(jù)庫。

接下來，我們來看Hbase都有哪些具體特性，選型的時候應該如何考慮。

(1) Hbase 與很多面向行存儲的關系型數(shù)據(jù)庫不同，HBase 是面向列的存儲和權限控制的，它里面的每個列是單獨存儲的，且支持基于列的獨立檢索。因此它天然適合分析類應用（OLAP）。

(2) HBase 中的數(shù)據(jù)都是以字符串形式存儲的，為空的列并不占用存儲空間，因此 HBase 的列存儲解決了數(shù)據(jù)稀疏性的問題，通?？梢栽O計成稀疏矩陣，在很大程度上節(jié)省了存儲開銷。

(3) HBase 的單表容量非常大，可以有百億行、百萬列，可以在橫向和縱向兩個維度插入數(shù)據(jù)，具有很強的彈性。HBase 采用 LSM 樹作為內部數(shù)據(jù)存儲結構，這種結構會周期性地將較小文件合并成大文件，以減少對磁盤的訪問。這些特性尤其適合單表數(shù)據(jù)量巨大的數(shù)據(jù)存取場景。

5. 總結與展望

通過對分布式存儲技術架構體系的綜述分析，我們首先區(qū)分了不同技術體系究竟是應該用在數(shù)據(jù)管理場景還是數(shù)據(jù)載體場景。隨后我們通過對不同體系的分布式存儲技術典型產(chǎn)品特性的分析，明確了不同技術產(chǎn)品的數(shù)據(jù)模型、數(shù)據(jù)訪問、數(shù)據(jù)性能、數(shù)據(jù)量級等不同層面的優(yōu)劣勢，最終希望通過這些典型特性的了解以及對具體業(yè)務場景的數(shù)據(jù)需求挖掘，能將比較優(yōu)秀的數(shù)據(jù)存儲技術匹配到最合適的業(yè)務場景中。?