分佈式存儲技術及應用

本人qq羣也有許多的技術文檔，但願能夠爲你提供一些幫助(非技術的勿加)。

QQ羣：   281442983 (點擊連接加入羣：http://jq.qq.com/?_wv=1027&k=29LoD19)    QQ：1542385235

 

根據did you know(http://didyouknow.org/)的數據，目前互聯網上可訪問的信息數量接近1秭= 1百萬億億 (1024)。毫無疑問，各個大型網站也都存儲着海量的數據，這些海量的數據如何有效存儲，是每一個大型網站的架構師必需要解決的問題。分佈式存儲技術就是爲了解決這個問題而發展起來的技術，下面讓將會詳細介紹這個技術及應用。

 

分佈式存儲概念

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

 

具體技術及應用：

海量的數據按照結構化程度來分，能夠大體分爲結構化數據，非結構化數據，半結構化數據。 

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

 

結構化數據的存儲及應用

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

大多數系統都有大量的結構化數據，通常存儲在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確缺乏相似的工具，就連簡單的查看一條數據，都要經過編程才能看到。

 

我的公衆號謝謝各位老鐵支持

本人qq羣也有許多的技術文檔，但願能夠爲你提供一些幫助(非技術的勿加)。

QQ羣：   281442983 (點擊連接加入羣：http://jq.qq.com/?_wv=1027&k=29LoD19)    QQ：1542385235

 

個人淘寶店，能夠進去逛逛噢：https://shop108912636.taobao.com/index.htm?spm=2013.1.w5001-7867000954.3.1d29318dPlLar7&scene=taobao_shop