分布式存儲概念

與目前常見的集中式存儲技術不同，分布式存儲技術并不是將數據存儲在某個或多個特定的節點上，而是通過網絡使用企業中的每臺機器上的磁盤空間，并將這些分散的存儲資源構成一個虛擬的存儲設備，數據分散的存儲在企業的各個角落。

具體技術及應用：

海量的數據按照結構化程度來分，可以大致分為結構化數據，非結構化數據，半結構化數據。

本文接下來將會分別介紹這三種數據如何分布式存儲。

結構化數據的存儲及應用

所謂結構化數據是一種用戶定義的數據類型，它包含了一系列的屬性，每一個屬性都有一個數據類型，存儲在關系數據庫里,可以用二維表結構來表達實現的數據。

大多數系統都有大量的結構化數據，一般存儲在Oracle或MySQL的等的關系型數據庫中，當系統規模大到單一節點的數據庫無法支撐時，一般有兩種方法：垂直擴展與水平擴展。

·垂直擴展：垂直擴展比較好理解，簡單來說就是按照功能切分數據庫，將不同功能的數據，存儲在不同的數據庫中，這樣一個大數據庫就被切分成多個小數據庫，從而達到了數據庫的擴展。一個架構設計良好的應用系統，其總體功能一般肯定是由很多個松耦合的功能模塊所組成的，而每一個功能模塊所需要的數據對應到數據庫中就是一張或多張表。各個功能模塊之間交互越少，越統一，系統的耦合度越低，這樣的系統就越容易實現垂直切分。

·水平擴展：簡單來說，可以將數據的水平切分理解為按照數據行來切分，就是將表中的某些行切分到一個數據庫中，而另外的某些行又切分到其他的數據庫中。為了能夠比較容易地判斷各行數據切分到了哪個數據庫中，切分總是需要按照某種特定的規則來進行的，如按照某個數字字段的范圍，某個時間類型字段的范圍，或者某個字段的hash值。

垂直擴展與水平擴展各有優缺點，一般一個大型系統會將水平與垂直擴展結合使用。

實際應用：圖1是為核高基項目設計的結構化數據分布式存儲的架構圖。

圖1可水平&垂直切分擴展的數據訪問框架

·采用了獨立的分布式數據訪問層，后端分布式數據庫集群對前端應用透明。

·集成了Memcached集群，減少對后端數據庫的訪問，提高數據的查詢效率。

·同時支持垂直及水平兩種擴展方式。

·基于全局唯一性主鍵范圍的切分方式，減輕了后續維護的工作量。

·全局唯一性主鍵的生成采用DRBD+Heartbeat技術保證了可靠性。

·利用MySQL Replication技術實現高可用的架構。

注:以上的數據切分方案并不是唯一擴展MySql的方法，有興趣的讀者可以關注一下”云計算時代的MySQL-Clustrix Sierra分布式數據庫系統”。

非結構化數據的存儲及應用

相對于結構化數據而言,不方便用數據庫二維邏輯表來表現的數據即稱為非結構化數據,包括所有格式的辦公文檔、文本、圖片、XML、HTML、各類報表、圖像和音頻/視頻信息等等。

分布式文件系統是實現非結構化數據存儲的主要技術，說到分布式文件系統就不得不提GFS（全稱為"Google File System"），GFS的系統架構圖如下圖所示。

圖2 Google-file-system架構圖

圖3 Google-file-system架構圖（詳細）

GFS將整個系統分為三類角色：Client（客戶端）、Master（主服務器）、Chunk Server（數據塊服務器）。

·Client（客戶端）：是GFS提供給應用程序的訪問接口，它是一組專用接口，不遵守POSIX規范，以庫文件的形式提供。應用程序直接調用這些庫函數，并與該庫鏈接在一起。

·Master（主服務器）：是GFS的管理節點，主要存儲與數據文件相關的元數據，而不是Chunk（數據塊）。元數據包括：命名空間（Name Space），也就是整個文件系統的目錄結構，一個能將64位標簽映射到數據塊的位置及其組成文件的表格，Chunk副本位置信息和哪個進程正在讀寫特定的數據塊等。還有Master節點會周期性地接收從每個Chunk節點來的更新（"Heart- beat"）來讓元數據保持最新狀態。

·Chunk Server（數據塊服務器）：負責具體的存儲工作，用來存儲Chunk。GFS將文件按照固定大小進行分塊，默認是64MB，每一塊稱為一個Chunk（數據塊），每一個Chunk以Block為單位進行劃分，大小為64KB，每個Chunk有一個唯一的64位標簽。GFS采用副本的方式實現容錯，每一個Chunk有多個存儲副本（默認為三個）。Chunk Server的個數可有有多個，它的數目直接決定了GFS的規模。

GFS之所以重要的原因在于，在Google公布了GFS論文之后，許多開源組織基于GFS的論文開發了各自的分布式文件系統，其中比較知名的有HDFS，MooseFS，MogileFS等。

實際應用：由于核高基的項目中未來會有大量的數據與應用需要存儲，所以我們設計時也采用分布式文件系統的方案，由于開源的分布式文件系統可以基本滿足我們需求，另外從時間上來說也比較緊張，所以我們采用了開源的MooseFS作為底層的分布式文件系統。

·MooseFS存在的問題：由于MooseFS是也是按照GFS論文設計的，只有一個Master（主服務器），雖然可以增加一個備份的日志服務器，但是還是存在Master無法擴展的問題，當單一Master節點上存儲的元數據越來越多的時候，Master節點占用的內存會越來越多，直到達到服務器的內存上限，所以單一Master節點存在內存上的瓶頸，只能存儲有限的數據，可擴展性差，并且不穩定。

·對MooseFS的優化：面對MooseFS存在的問題，我們采用了類似分布式數據庫中的“Sharding”技術，設計了一個分布式文件系統訪問框架，可以做到對分布式文件系統做垂直與水平切分。這樣就最大限度的保證了MooseFS系統的可擴展性與穩定性。

下圖是為核高基項目設計的非結構化數據分布式存儲的架構圖。我們設計了兩種訪問方式，一種是類似GFS的API訪問方式，以庫文件的方式提供，應用程序通過調用API直接訪問分布式文件系統。第二種是通過RESTful web Service訪問。

圖4可水平&垂直切分擴展的分布式文件系統訪問框架（API版）

圖5可水平&垂直切分擴展的分布式文件系統訪問框架（RESTful web Service版）

半結構化數據的存儲及應用

就是介于完全結構化數據（如關系型數據庫、面向對象數據庫中的數據）和完全無結構的數據（如聲音、圖像文件等）之間的數據， 半結構化數據模型具有一定的結構性，但較之傳統的關系和面向對象的模型更為靈活。半結構數據模型完全不基于傳統數據庫模式的嚴格概念，這些模型中的數據都是自描述的。

由于半結構化數據沒有嚴格的schema定義，所以不適合用傳統的關系型數據庫進行存儲，適合存儲這類數據的數據庫被稱作“NoSQL”數據庫。

NoSQL的定義：

被稱作下一代的數據庫，具有非關系型，分布式，輕量級，支持水平擴展且一般不保證遵循ACID原則的數據儲存系統。“NoSQL”其實是具有誤導性的別名，稱作Non Relational Database(非關系型數據庫)更為恰當。所謂“非關系型數據庫”指的是：

·使用松耦合類型、可擴展的數據模式來對數據進行邏輯建模(Map，列，文檔，圖表等)，而不是使用固定的關系模式元組來構建數據模型。

·以遵循于CAP定理（能保證在一致性，可用性和分區容忍性三者中中達到任意兩個）的跨多節點數據分布模型而設計，支持水平伸縮。這意味著對于多數據中心和動態供應（在生產集群中透明地加入/刪除節點）的必要支持，也即彈性(Elasticity)。

·擁有在磁盤或內存中，或者在這兩者中都有的，對數據持久化的能力，有時候還可以使用可熱插拔的定制存儲。

·支持多種的‘Non-SQL’接口(通常多于一種)來進行數據訪問。

圖6是Sourav Mazumder提出的NoSQL總體架構：

圖6 NoSQL總體架構

·接口：REST (HBase，CouchDB，Riak等)，MapReduce (HBase，CouchDB，MongoDB，Hypertable等)，Get/Put (Voldemort，Scalaris等)，Thrift (HBase，Hypertable，Cassandra等)，語言特定的API(MongoDB)。

·邏輯數據模型：面向鍵值對的(Voldemort，Dynomite等)，面向Column Family的(BigTable，HBase，Hypertable等)，面向文檔的(Couch DB，MongoDB等)，面向圖的(Neo4j，Infogrid等)

·數據分布模型：致性和可用性(HBase，Hypertable，MongoDB等)， 可用性和可分區性(Cassandra等)。一致性和可分區性的組合會導致一些非額定的節點產生可用性的損失。有趣的是目前還沒有一個“非關系型數據庫”支持這一組合。

·數據持久性：基于內存的(如Redis，Scalaris，Terrastore)，基于磁盤的(如MongoDB，Riak等)，或內存及磁盤二者的結合(如HBase，Hypertable，Cassandra)。存儲的類型有助于我們辨別該解決方案適用于哪種類型。然而，在大多數情況下人們發現基于組合方 案的解決方案是最佳的選擇。既能通過內存數據存儲支持高性能，又能在寫入足夠多的數據后存儲到磁盤來保證持續性。

NoSQL中的重要理論基礎：

CAP理論：

·C: Consistency一致性

·A: Availability可用性(指的是快速獲取數據)

·P: Tolerance of network Partition分區容忍性(分布式)

圖7 CAP理論

CAP原理告訴我們，這三個因素最多只能滿足兩個，不可能三者兼顧。對于分布式系統來說，分區容錯是基本要求，所以必然要放棄一致性。對于大型網站來說，分區容錯和可用性的要求更高，所以一般都會選擇適當放棄一致性。對應CAP理論，NoSQL追求的是AP，而傳統數據庫追求的是CA，這也可以解釋為什么 傳統數據庫的擴展能力有限的原因。

BASE模型：

說起來很有趣，BASE的英文意義是堿，而ACID是酸。真的是水火不容啊。

·Basically Availble –基本可用

·Soft-state –軟狀態/柔性事務

·Eventual Consistency –最終一致性

BASE模型是傳統ACID模型的反面，不同于ACID模型，BASE強調犧牲高一致性，從而獲得可用性或可靠性。

基本可用是指通過Sharding，允許部分分區失敗。

軟狀態是指異步，允許數據在一段時間內的不一致，只要保證最終一致就可以了。

最終一致性是整個NoSQL中的一個核心理念，強調最終數據是一致的就可以了，而不是時時一致。

Quorum NRW：

圖8 Quorum NRW

N:復制的節點數，即一份數據被保存的份數。
R:成功讀操作的最小節點數，即每次讀取成功需要的份數。
W:成功寫操作的最小節點數 ，即每次寫成功需要的份數。

這三個因素決定了可用性，一致性和分區容錯性。只需W + R > N，就可以保證強一致性。

實際應用：今年上半年我在aspire的搜索團隊中負責互聯網搜索的設計與開發，我設計的網頁爬蟲系統就是采用Cassandra來存儲網頁與鏈接信息的。下面結合我的實際使用經驗談談我對Cassandra的看法：

優點：

·彈性擴展：由于Cassandra是完全分布式的，使用時不需要再像使用MySQL那樣自己設計復雜的數據切分方案，也不再配置復雜的DRBD+Heartbeat，一切都變得非常簡單了，只需要簡單的配置就可以給一個集群中增加一個新的節點，而且對客戶端完全是透明的，不需要任何更改。

·靈活的schema：不需要象數據庫一樣預先設計schema，增加或者刪除字段非常方便。

·使用簡單：由于沒有類似SQL這樣復雜的查詢語言，學習成本不高，很容易上手。

缺點：

·穩定性差：在我們的實際使用過程中發現，單機數據量達到200G以上，時不時就會發生宕機現象。

·缺乏管理與分析工具：傳統的關系型數據都有比較好用的管理與分析工具，使用這些工具可以輕松的管理數據庫，查看數據，分析性能瓶頸等，而Cassandra確缺少類似的工具，就連簡單的查看一條數據，都要通過編程才能看到。