不同體系分散式儲存技術的技術特性

本文對分散式儲存技術架構體系進行綜述分析，區分了不同技術體系應用場景，對不同體系的分散式儲存技術典型產品特性進行分析，明確不同技術產品的資料模型、資料訪問、資料效能、資料量級等不同層面的優劣勢。希望大家能夠透過這些典型特性的瞭解以及對具體業務場景的資料需求挖掘，能將比較優秀的資料儲存技術匹配到最合適的業務場景中。

1. 為什麼會引入分散式儲存技術

從70年代到2000年左右，資料儲存基本上是伴隨著IBM E.F.Code提出的關係模型理論，以關係型資料庫(Oracle、DB2、MySQL)為資料管理平臺，以集中式儲存產品為資料最終載體形成的堅實的資料儲存架構體系。2000年後，但是隨著資料量的增加，單機的資料庫瓶頸已經不能滿足大資料量的需求，從資料管理層面開始誕生分庫分表的方案。自2006年穀歌發了三篇論文(GFS、Big Table、Map-Reduce)之後，在資料管理層面以及資料載體層面不斷湧現各類分散式產品，例如GFS、GPFS、HFS、DFS等各類分散式檔案系統，例如Hadoop、Hbase、Redis、MongoDB、RockDB等系列分散式資料管理平臺。

總而言之，資料量的爆發式增長催生了資料應用領域的各種新需求，資料應用領域的各種新需求驅動了資料管理層面以及資料載體層面的分散式變革。

2. 主流分散式檔案系統技術分析

主流分散式檔案系統技術主要有GPFS、GFS、HDFS、DFS、ClusterFS等很多，下面我們以同類或類似技術體系的典型產品為代表進行闡述。

2.1 GFS

GFS是基於檔案系統實現的分散式儲存系統，是屬於有中心的分散式架構;透過對中心節點後設資料的索引查詢得到資料地址空間，然後再去資料節點上查詢資料本身的機制來完成資料的讀寫;是基於檔案資料儲存場景設計的架構。

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

(1) GFS是一種適合大檔案，尤其是GB級別的大檔案儲存場景的分散式儲存系統。

(2) GFS非常適合對資料訪問延遲不敏感的搜尋引擎服務。

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

(4) GFS可以透過快取一份部分Metadata到Client節點，減少Client與Master的互動。

(5) GFS的Master節點上的Operation log和Checkpoint檔案需要透過複製方式保留多個副本，來保障後設資料以及中心管理功能的高可用性。

2.2 HDFS

HDFS的架構原理與GFS基本類似，但是是基於GFS做了一些改進之後形成的一套技術體系。同樣，它基於檔案系統實現的分散式儲存系統，是屬於有中心的分散式架構;透過對中心節點後設資料的索引查詢得到資料地址空間，然後再去資料節點上查詢資料本身的機制來完成資料的讀寫;是基於檔案資料儲存場景設計的架構。

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

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

(2) HDFS不支援檔案併發寫，對於單個檔案它僅允許有一個寫或者追加請求。

(3) HDFS從2.0版本之後支援兩個管理節點(NameNode)，主備切換可以做到分鐘級別 。

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

(5) HDFS不支援對已寫檔案的更新操作，僅支援對它的追加操作。

2.3 GlusterFS

GlusterFS雖然是基於檔案系統的分散式儲存技術，但是它與GFS架構有本質的區別，它是去中心化的無中心分散式架構; 它是透過對檔案全目錄的DHT演算法計算得到相應的Brike地址 ，從而實現對資料的讀寫，這與GFS以及HDFS等透過後設資料檢索實現資料定址的方式有極大的不同。

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

(1) GlusterFS是採用無中心對稱式架構，沒有專用的後設資料伺服器，也就不存在後設資料伺服器瓶頸。後設資料存在於檔案的屬性和擴充套件屬性中。

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

(3) GlusterFS採用資料最終一致性演算法，只要有一個副本寫完就可以Commit。

(4) GlusterFS預設會將檔案切分為128KB的切片，然後分佈於卷對應的所有Brike當中。所以從其設計初衷來看，更適合大檔案併發的場景。

(5) GlusterFS 採用的DHT演算法不具備良好的穩定性，一旦儲存節點發生增減變化，勢必影響卷下面所有Brike的資料進行再平衡操作，開銷比較大。

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

3. 主流分散式物件儲存技術分析

目前應用比較廣發的分散式物件儲存技術基本都是基於Swift或者Ceph體系衍生出來的產品。

3.1 Ceph

Ceph首先是一種物件儲存技術，也就是說它儲存資料的機制與我們之前接觸的檔案系統機制是完全不一樣的，它是將資料抽象為物件和物件標識來進行管理。 從架構上來講，Ceph相對類似於GlusterFS的無中心化架構;它是透過對物件的雜湊演算法得到相應的Bucket&Node地址，從而實現對資料的讀寫 。

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

(1) Ceph是一種統一了三種介面的統一儲存平臺，上層應用支援Object、Block、File。

(2) Ceph採用Crush演算法完成資料分佈計算，透過Tree的邏輯物件資料結構自然實現故障隔離副本位置計算，透過將Bucket內節點的組織結構，叢集結構變化導致的資料遷移量最小。

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

(4) Ceph物件儲存的最小單元為4M，相比GFS&HDFS而言，適合一些小的非結構化資料儲存。

3.2 Swift

Swifty也是是一種物件儲存技術，它與Ceph的架構有類似的地方，也是 無中心化架構;它是透過對物件的雜湊演算法得到相應的Bucket&Node地址，從而實現對資料的讀寫 。但是Swift是需要透過Proxy節點完成與資料節點的互動，雖然Proxy節點可以負載均衡，但是畢竟經歷了中間層，在併發量較大而且小檔案操作量比較的場景下，Ceph的效能表現會優秀一些。

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

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

(2) Swift採用一致性雜湊演算法完成資料分佈計算，透過首次計算物件針對邏輯物件(Zone)的對映實現資料副本的故障隔離分佈，然後透過雜湊一致性演算法完成物件在Bucket當中的分佈計算，採用Ring環結構組織Bucket節點組織，資料分佈不如Ceph均勻。

(3) Swift 需要藉助Proxy節點完成對資料的訪問，不同透過客戶端直接訪問資料節點，相對資料的訪問效率來講，比Ceph要差一些( 可以參照ICCLAB&SPLAB的效能測試報告 )。

4. 主流分散式資料庫技術分析

目前在分散式資料庫技術的應用場景下，各行各業採用的產品比較多，尤其是NOSQL&NewSQL領域。記下來我們以文件、健值、記憶體、列式等幾個典型分類來進行闡述。

4.1 MongoDB

MongoDB是以二進位制JSON 或叫BSON 格式儲存文件資料 為資料模型 ，專門為文件儲存設計。當查詢MongoDB並返回結果時，這些資料就會轉換為易於閱讀的資料格式。它的所謂分散式主要是指它的切片叢集機制。透過基於範圍的分割槽機制來實現水平擴充套件，稱為分片機制，它可以自動化管理每個分散式節點儲存的資料。

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

(1) MongoDB面向集合儲存，模式自由，易儲存物件型別的資料，檔案儲存格式為JSON，從這個角度來講，我們需要從資料業務場景角度去剖析其與MongoDB資料模型的契合性。

(2) MongoDB使用高效的二進位制資料儲存，包括大型物件，因此比較適合媒體、影片之類的大物件的存取場景。

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

(4) MongoDB水平擴充套件能力較強，可以透過分散式叢集架構將資料分佈到多臺機器，並且有完善的支援複製和故障恢復機制，支援海量資料的處理場景。

4.2 Redis

Redis 是一個開源的使用 ANSI C 語言編寫、遵守 BSD 協議、支援網路、 可基於記憶體 、分散式、可選永續性的 鍵值對(Key-Value)儲存資料庫 ，並提供多種語言的API。Redis 通常被稱為資料結構伺服器，因為值(value)可以是字串(String)、雜湊(Hash)、列表(list)、集合(sets)和有序集合(sorted sets)等型別。

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

(1) Redis所有資料是存放在記憶體中的，原始碼採用C語言編寫，距離底層作業系統更近，並且使用單執行緒架構，避免了多執行緒可能產生的競爭開銷。以上決定了它是執行速度非常快的資料庫。

(2) Redis不僅僅支援簡單的key-value型別的資料，同時還提供list，set，zset，hash等資料結構的儲存。結合這個相對比較靈活的資料模型，Redis通常被用來作為快取記憶體使用。

(3) Redis提供兩種持久化方案AOF和RDB，因此它不僅僅適合快取記憶體場景，而且適合基於此需求的衍生性業務場景。

(4) Redis從3.0版本後開始支援叢集模式，很好的實現了處理能力的水平擴充套件，結合它的速度快的特性，這就為網際網路電子商務的高併發場景提供瞭解決方案。

4.3 Hbase

Hbase 是 Google Bigtable 的開源實現，與 Bigtable 利用 GFS 作為其檔案儲存系統類似，HBase 利用 Hadoop HDFS 作為其檔案儲存系統; 執行 MapReduce 來處理 Bigtable 中的海量資料。因此從源頭來看，Hbase是為大資料處理提供的資料存取解決方案，可稱為列式資料庫。

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

(1) Hbase 與很多面向行儲存的關係型資料庫不同，HBase 是面向列的儲存和許可權控制的，它裡面的每個列是單獨儲存的，且支援基於列的獨立檢索。因此它天然適合分析類應用(OLAP)。

(2) HBase 中的資料都是以字串形式儲存的，為空的列並不佔用儲存空間，因此 HBase 的列儲存解決了資料稀疏性的問題，通常可以設計成稀疏矩陣，在很大程度上節省了儲存開銷。

(3) HBase 的單表容量非常大，可以有百億行、百萬列，可以在橫向和縱向兩個維度插入資料，具有很強的彈性。HBase 採用 LSM 樹作為內部資料儲存結構，這種結構會週期性地將較小檔案合併成大檔案，以減少對磁碟的訪問。這些特性尤其適合單表資料量巨大的資料存取場景。

5. 總結與展望

透過對分散式儲存技術架構體系的綜述分析，我們首先區分了不同技術體系究竟是應該用在資料管理場景還是資料載體場景。隨後我們透過對不同體系的分散式儲存技術典型產品特性的分析，明確了不同技術產品的資料模型、資料訪問、資料效能、資料量級等不同層面的優劣勢，最終希望透過這些典型特性的瞭解以及對具體業務場景的資料需求挖掘，能將比較優秀的資料儲存技術匹配到最合適的業務場景中。