1、分布式存儲技術(shù)及應(yīng)用根據(jù)didyouknow(/)的數(shù)據(jù),目前互聯(lián)網(wǎng)上可訪問的信息數(shù)量接近1秫=1百萬億億(1024)。毫無疑問，各個大型網(wǎng)站也都存儲著海量的數(shù)據(jù)，這些海量的數(shù)據(jù)如何有效存儲，是每個大型網(wǎng)站的架構(gòu)師必須要解決的問題。分布式存儲技術(shù)就是為了解決這個問題而發(fā)展起來的技術(shù)，下面讓將會詳細介紹這個技術(shù)及應(yīng)用。分布式存儲概念與目前常見的集中式存儲技術(shù)不同，分布式存儲技術(shù)并不是將數(shù)據(jù)存儲在某個或多個特定的節(jié)點上，而是通過網(wǎng)絡(luò)使用企業(yè)中的每臺機器上的磁盤空間，并將這些分散的存儲資源構(gòu)成一個虛擬的存儲設(shè)備，數(shù)據(jù)分散的存儲在企業(yè)的各個角落。具體技術(shù)及應(yīng)用：

2、海量的數(shù)據(jù)按照結(jié)構(gòu)化程度來分，可以大致分為結(jié)構(gòu)化數(shù)據(jù)，非結(jié)構(gòu)化數(shù)據(jù)，半結(jié)構(gòu)化數(shù)據(jù)。本文接下來將會分別介紹這三種數(shù)據(jù)如何分布式存儲。結(jié)構(gòu)化數(shù)據(jù)的存儲及應(yīng)用所謂結(jié)構(gòu)化數(shù)據(jù)是一種用戶定義的數(shù)據(jù)類型，它包含了一系列的屬性，每一個屬性都有一個數(shù)據(jù)類型，存儲在關(guān)系數(shù)據(jù)庫里，可以用二維表結(jié)構(gòu)來表達實現(xiàn)的數(shù)據(jù)。大多數(shù)系統(tǒng)都有大量的結(jié)構(gòu)化數(shù)據(jù)，一般存儲在Oracle或MySQL勺等的關(guān)系型數(shù)據(jù)庫中，當系統(tǒng)規(guī)模大到單一節(jié)點的數(shù)據(jù)庫無法支撐時，一般有兩種方法：垂直擴展與水平擴展。垂直擴展：垂直擴展比較好理解，簡單來說就是按照功能切分數(shù)據(jù)庫，將不同功能的數(shù)據(jù)，存儲在不同的數(shù)據(jù)庫中，這樣一個大數(shù)據(jù)庫就被切分成多個小數(shù)據(jù)

3、庫，從而達到了數(shù)據(jù)庫的擴展。一個架構(gòu)設(shè)計良好的應(yīng)用系統(tǒng)，其總體功能一般肯定是由很多個松耦合的功能模塊所組成的，而每一個功能模塊所需要的數(shù)據(jù)對應(yīng)到數(shù)據(jù)庫中就是一張或多張表。各個功能模塊之間交互越少，越統(tǒng)一，系統(tǒng)的耦合度越低，這樣的系統(tǒng)就越容易實現(xiàn)垂直切分。水平擴展：簡單來說，可以將數(shù)據(jù)的水平切分理解為按照數(shù)據(jù)行來切分，就是將表中的某些行切分到一個數(shù)據(jù)庫中，而另外的某些行又切分到其他的數(shù)據(jù)庫中。為了能夠比較容易地判斷各行數(shù)據(jù)切分到了哪個數(shù)據(jù)庫中，切分總是需要按照某種特定的規(guī)則來進行的，如按照某個數(shù)字字段的范圍，某個時間類型字段的范圍，或者某個字段的hash值。垂直擴展與水平擴展各有優(yōu)缺點，一般一個

4、大型系統(tǒng)會將水平與垂直擴展結(jié)合使用。實際應(yīng)用：圖1是為核高基項目設(shè)計的結(jié)構(gòu)化數(shù)據(jù)分布式存儲的架構(gòu)圖。*CL水平切勢的mmemn。收n圖1可水平&垂直切分擴展的數(shù)據(jù)訪問框架 采用了獨立的分布式數(shù)據(jù)訪問層，后端分布式數(shù)據(jù)庫集群對前端應(yīng)用透明。 集成了Memcached集群，減少對后端數(shù)據(jù)庫的訪問，提高數(shù)據(jù)的查詢效率。 同時支持垂直及水平兩種擴展方式。 基于全局唯一性主鍵范圍的切分方式，減輕了后續(xù)維護的工作量。 全局唯一性主鍵的生成采用DRBD+Heartbeat技術(shù)保證了可靠性。 利用MySQLReplication技術(shù)實現(xiàn)高可用的架構(gòu)。注：以上的數(shù)據(jù)切分方案并不是唯一擴展MySql的方法

5、，有興趣的讀者可以關(guān)注一下“云計算時代的MySQL-ClustrixSierra分布式數(shù)據(jù)庫系統(tǒng)”。非結(jié)構(gòu)化數(shù)據(jù)的存儲及應(yīng)用相對于結(jié)構(gòu)化數(shù)據(jù)而言，不方便用數(shù)據(jù)庫二維邏輯表來表現(xiàn)白數(shù)據(jù)即稱為非結(jié)構(gòu)化數(shù)據(jù)，包括所有格式的辦公文檔、文本、圖片、XMLHTML各類報表、圖像和音頻/視頻信息等等。分布式文件系統(tǒng)是實現(xiàn)非結(jié)構(gòu)化數(shù)據(jù)存儲的主要技術(shù)，說到分布式文件系統(tǒng)就不得不提GFS（全稱為"GoogleFileSystem"）,GFS的系統(tǒng)架構(gòu)圖如下圖所示。GFSArchitectureifls-dvHGFSMasterGFSMasterMasterscriunkserver1ChunK

6、5ervB2ChunkzserverN Filesbrokenintochunksi.typically64ME) pylastermanagesmeladata Datatransit莒happendirectlybetweenclients/chunkservers圖2Google-file-system架構(gòu)圖ChunkJijb'iChunki'1'Chunks?'t上桿老,ChunkA-jIiChunkIJh./"QI")Kt猖總目打羽伯總圖3Google-file-system架構(gòu)圖（詳細）GFSW整個系統(tǒng)分為三類角色：Client（

7、客戶端）、Master（主服務(wù)器）、ChunkServer（數(shù)據(jù)塊服務(wù)器）。Client（客戶端）：是GF限供給應(yīng)用程序的訪問接口，它是一組專用接口，不遵守POSIX規(guī)范，以庫文件的形式提供。應(yīng)用程序直接調(diào)用這些庫函數(shù)，并與該庫鏈接在一起。 Master（主服務(wù)器）：是GFS的管理節(jié)點，主要存儲與數(shù)據(jù)文件相關(guān)的元數(shù)據(jù)，而不是Chunk（數(shù)據(jù)塊）。元數(shù)據(jù)包括：命名空間（NameSpace）,也就是整個文件系統(tǒng)的目錄結(jié)構(gòu)，一個能將64位標簽映射到數(shù)據(jù)塊的位置及其組成文件的表格，Chunk副本位置信息和哪個進程正在讀寫特定的數(shù)據(jù)塊等。還有Master節(jié)點會周期性地接收從每個Chunk節(jié)點來的更新（&

8、quot;Heart-beat"）來讓元數(shù)據(jù)保持最新狀態(tài)。 ChunkServer（數(shù)據(jù)塊服務(wù)器）：負責具體的存儲工作，用來存儲Chunk。GFSW文件按照固定大小進行分塊，默認是64MB每一塊稱為一個Chunk（數(shù)據(jù)塊），每一個Chunk以Block為單位進行劃分，大小為64KB,每個Chunk有一個唯一的64位標簽。GFS采用副本的方式實現(xiàn)容錯，每一個Chunk有多個存儲副本（默認為三個）。ChunkServer的個數(shù)可有有多個，它的數(shù)目直接決定了GFS的規(guī)模。GFM所以重要的原因在于，在Google公布了GFS論文之后，許多開源組織基于GFS的論文開發(fā)了各自的分布式文件系統(tǒng)，其

9、中比較知名的有HDFSMooseFS,MogileFS等。實際應(yīng)用：由于核高基的項目中未來會有大量的數(shù)據(jù)與應(yīng)用需要存儲，所以我們設(shè)計時也采用分布式文件系統(tǒng)的方案，由于開源的分布式文件系統(tǒng)可以基本滿足我們需求，另外從時間上來說也比較緊張，所以我們采用了開源的MooseFS作為底層的分布式文件系統(tǒng)。 MooseFS存在的問題：由于MooseFS是也是按照GFS論文設(shè)計的，只有一個Master（主服務(wù)器），雖然可以增加一個備份的日志服務(wù)器，但是還是存在Master無法擴展的問題，當單一Master節(jié)點上存儲的元數(shù)據(jù)越來越多的時候，Master節(jié)點占用的內(nèi)存會越來越多，直到達到服務(wù)器的內(nèi)存上限，所以單

10、一Master節(jié)點存在內(nèi)存上的瓶頸，只能存儲有限的數(shù)據(jù)，可擴展性差，并且不穩(wěn)定。 對MooseFS的優(yōu)化：面對MooseFS存在的問題，我們采用了類似分布式數(shù)據(jù)庫中的“Sharding”技術(shù)，設(shè)計了一個分布式文件系統(tǒng)訪問框架，可以做到對分布式文件系統(tǒng)做垂直與水平切分。這樣就最大限度的保證了MooseFS系統(tǒng)的可擴展性與穩(wěn)定性。下圖是為核高基項目設(shè)計的非結(jié)構(gòu)化數(shù)據(jù)分布式存儲的架構(gòu)圖。我們設(shè)計了兩種訪問方式，一種是類似GFS的API訪問方式，以庫文件的方式提供，應(yīng)用程序通過調(diào)用API直接訪問分布式文件系統(tǒng)。第二種是通過RESTfulwebService訪問。UlfrBiHit1事向，然宇切外M分用

11、苴史f*H映糧的圖4可水平&垂直切分擴展的分布式文件系統(tǒng)訪問框架（API版）st#Rh水平切分的分毫式工件為城（皿耀）厚期圖5可水平&垂直切分擴展的分布式文件系統(tǒng)訪問框架（RESTfulwebService版）半結(jié)構(gòu)化數(shù)據(jù)的存儲及應(yīng)用就是介于完全結(jié)構(gòu)化數(shù)據(jù)（如關(guān)系型數(shù)據(jù)庫、面向?qū)ο髷?shù)據(jù)庫中的數(shù)據(jù)）和完全無結(jié)構(gòu)的數(shù)據(jù)（如聲音、圖像文件等）之間的數(shù)據(jù)，半結(jié)構(gòu)化數(shù)據(jù)模型具有一定的結(jié)構(gòu)性，但較之傳統(tǒng)的關(guān)系和面向?qū)ο蟮哪Ｐ透鼮殪`活。半結(jié)構(gòu)數(shù)據(jù)模型完全不基于傳統(tǒng)數(shù)據(jù)庫模式的嚴格概念，這些模型中的數(shù)據(jù)都是自描述的。由于半結(jié)構(gòu)化數(shù)據(jù)沒有嚴格的schema定義，所以不適合用傳統(tǒng)的關(guān)系型數(shù)據(jù)庫進行

12、存儲，適合存儲這類數(shù)據(jù)的數(shù)據(jù)庫被稱作“NoSQL數(shù)據(jù)庫。NoSQL勺定義：被稱作下一代的數(shù)據(jù)庫，具有非關(guān)系型，分布式，輕量級，支持水平擴展且一般不保證遵循ACID原則的數(shù)據(jù)儲存系統(tǒng)。“NoSQL”其實是具有誤導(dǎo)f的別名，稱作NonRelationalDatabase（非關(guān)系型數(shù)據(jù)庫）更為恰當。所謂“非關(guān)系型數(shù)據(jù)庫”指的是：使用松耦合類型、可擴展的數(shù)據(jù)模式來對數(shù)據(jù)進行邏輯建模（Map,歹U,文檔，圖表等），而不是使用固定的關(guān)系模式元組來構(gòu)建數(shù)據(jù)模型。以遵循于CAP定理（能保證在一致性，可用性和分區(qū)容忍性三者中中達到任意兩個）的跨多節(jié)點數(shù)據(jù)分布模型而設(shè)計，支持水平伸縮。這意味著對于多數(shù)據(jù)中心和動態(tài)

13、供應(yīng)（在生產(chǎn)集群中透明地加入/刪除節(jié)點）的必要支持，也即彈性（Elasticity）。擁有在磁盤或內(nèi)存中，或者在這兩者中都有的，對數(shù)據(jù)持久化的能力，有時候還可以使用可熱插拔的定制存儲。支持多種的Non-SQL'接口（通常多于一種）來進行數(shù)據(jù)訪問。圖6是SouravMazumder提出的NoSQL總體架構(gòu)：接口層RESTThriftMapReduceGET/PUTJS音特定APIISOI子集數(shù)據(jù)邏輯模型層Key-ValueColumnFamilyDocumentGraph數(shù)據(jù)分布層cap支持in支持多數(shù)據(jù)中心一動態(tài)部署數(shù)據(jù)持久層基于內(nèi)存If基于硬盤1基于內(nèi)存而硬£1廠前可插拔圖

14、6NoSQL總體架構(gòu) 接口：REST(HBase,CouchDBRiak等)，MapReduce(HBase,CouchDBMongoDBHypertable等)，Get/Put(Voldemort,Scalaris等)，Thrift(HBase,Hypertable,Cassandra等)，語言特定的API(MongoDB)。 邏輯數(shù)據(jù)模型：面向鍵值對的(Voldemort,Dynomite等)，面向ColumnFamily的(BigTable,HBase,Hypertable等)，面向文檔的(CouchDB,MongoD瑾),面向圖的(Neo4j,Infogrid等) 數(shù)據(jù)分布模型：致性和

15、可用性(HBase,Hypertable,MongoDB等)，可用性和可分區(qū)性(Cassandra等)。一致性和可分區(qū)性的組合會導(dǎo)致一些非額定的節(jié)點產(chǎn)生可用性的損失。有趣的是目前還沒有一個“非關(guān)系型數(shù)據(jù)庫”支持這一組合。 數(shù)據(jù)持久性：基于內(nèi)存的(如Redis,Scalaris,Terrastore),基于磁盤的(如MongoDBRiak等)，或內(nèi)存及磁盤二者的結(jié)合(如HBase,Hypertable,Cassandra)。存儲的類型有助于我們辨別該解決方案適用于哪種類型。然而，在大多數(shù)情況下人們發(fā)現(xiàn)基于組合方案的解決方案是最佳的選擇。既能通過內(nèi)存數(shù)據(jù)存儲支持高性能，又能在寫入足夠多的數(shù)據(jù)后存儲

16、到磁盤來保證持續(xù)性。NoSQL中的重要理論基礎(chǔ)：CAM論： C:Consistency一致性分區(qū)容忍性(分布式)4Availability可用性(指的是快速獲取數(shù)據(jù)) P:ToleranceofnetworkPartitionVisualGuidetoNoSQLSystemsDawModelsCtocmECTrtQgntedPickTwoMo?goD8日2伸,。1甘yDBTerrastoffiWScsUifisRAljihh巳TPnHMigTorino4SimpJeDBetCouchOBRlak圖7CAP理論CAP原理告訴我們，這三個因素最多只能滿足兩個，不可能三者兼顧。對于分布式系統(tǒng)來說，分

17、區(qū)容錯是基本要求，所以必然要放棄一致性。對于大型網(wǎng)站來說，分區(qū)容錯和可用性的要求更高，所以一般都會選擇適當放棄一致性。對應(yīng)CAM論，NoSQLB求白是AP,而傳統(tǒng)數(shù)據(jù)庫追求的是CA,這也可以解釋為什么傳統(tǒng)數(shù)據(jù)庫的擴展能力有限的原因。BAS成型：說起來很有趣，BASE的英文意義是堿，而ACID是酸。真的是水火不容啊。 BasicallyAvailble-基本可用 Soft-state-軟狀態(tài)/柔性事務(wù) EventualConsistency-最終一致性BASE模型是傳統(tǒng)ACID模型的反面，不同于ACID模型，BASE雖調(diào)犧牲高一致性，從而獲得可用性或可靠性。基本可用是指通過Sharding,允許

18、部分分區(qū)失敗。軟狀態(tài)是指異步，允許數(shù)據(jù)在一段時間內(nèi)的不一致，只要保證最終一致就可以了。最終一致性是整個NoSQL中的一個核心理念，強調(diào)最終數(shù)據(jù)是一致的就可以了，而不是時時一致。QuorumNRWNReplicasWfiTcto洲Icopies(withlatestversionno),syndwonouslyforWsuccessReadfromallcopies,waitforfirstRrespcxtses,pickthehighestversionnumberCondition:W，R>N圖8QuorumNRWN:復(fù)制的節(jié)點數(shù)，即一份數(shù)據(jù)被保存的份數(shù)。R：成功讀操作的最小節(jié)點數(shù)，即每次讀取成功需要的份數(shù)。W:成功寫操作的最小節(jié)點數(shù)，即每次寫成功需要的份數(shù)。這三個因素決定了可用性，一致性和分區(qū)容錯性。只需W+R>N,就可以保證強一致性。實際應(yīng)用：今年上半年我在aspire的搜索團隊中負責互聯(lián)網(wǎng)搜索的設(shè)計與開發(fā)，我設(shè)計的網(wǎng)頁爬蟲系統(tǒng)就是采用Cassandra來存儲網(wǎng)頁與鏈接信息的。下面結(jié)合我的實際使用經(jīng)驗談?wù)勎覍assandra的看法：優(yōu)點： 彈性擴展：由于Cassandra是完全分布式的，使用時不需要再像使用MySQL>樣自己設(shè)計復(fù)雜的數(shù)據(jù)切分方案，也不再配置復(fù)雜的DRBD+Heartbe