本人qq群也有許多的技術(shù)文檔，希望可以為你提供一些幫助(非技術(shù)的勿加)。QQ群： 281442983 (點(diǎn)擊鏈接加入群：http://jq.qq.com/?_wv=1027&k=29LoD19) QQ：1542385235
根據(jù)did you know(http:///)的數(shù)據(jù)，目前互聯(lián)網(wǎng)上可訪問(wèn)的信息數(shù)量接近1秭= 1百萬(wàn)億億 (1024)。毫無(wú)疑問(wèn)，各個(gè)大型網(wǎng)站也都存儲(chǔ)著海量的數(shù)據(jù)，這些海量的數(shù)據(jù)如何有效存儲(chǔ)，是每個(gè)大型網(wǎng)站的架構(gòu)師必須要解決的問(wèn)題。分布式存儲(chǔ)技術(shù)就是為了解決這個(gè)問(wèn)題而發(fā)展起來(lái)的技術(shù)，下面讓將會(huì)詳細(xì)介紹這個(gè)技術(shù)及應(yīng)用。
分布式存儲(chǔ)概念 與目前常見(jiàn)的集中式存儲(chǔ)技術(shù)不同，分布式存儲(chǔ)技術(shù)并不是將數(shù)據(jù)存儲(chǔ)在某個(gè)或多個(gè)特定的節(jié)點(diǎn)上，而是通過(guò)網(wǎng)絡(luò)使用企業(yè)中的每臺(tái)機(jī)器上的磁盤(pán)空間，并將這些分散的存儲(chǔ)資源構(gòu)成一個(gè)虛擬的存儲(chǔ)設(shè)備，數(shù)據(jù)分散的存儲(chǔ)在企業(yè)的各個(gè)角落。
具體技術(shù)及應(yīng)用： 海量的數(shù)據(jù)按照結(jié)構(gòu)化程度來(lái)分，可以大致分為結(jié)構(gòu)化數(shù)據(jù)，非結(jié)構(gòu)化數(shù)據(jù)，半結(jié)構(gòu)化數(shù)據(jù)。 本文接下來(lái)將會(huì)分別介紹這三種數(shù)據(jù)如何分布式存儲(chǔ)。
結(jié)構(gòu)化數(shù)據(jù)的存儲(chǔ)及應(yīng)用 所謂結(jié)構(gòu)化數(shù)據(jù)是一種用戶定義的數(shù)據(jù)類型，它包含了一系列的屬性，每一個(gè)屬性都有一個(gè)數(shù)據(jù)類型，存儲(chǔ)在關(guān)系數(shù)據(jù)庫(kù)里,可以用二維表結(jié)構(gòu)來(lái)表達(dá)實(shí)現(xiàn)的數(shù)據(jù)。 大多數(shù)系統(tǒng)都有大量的結(jié)構(gòu)化數(shù)據(jù)，一般存儲(chǔ)在Oracle或MySQL的等的關(guān)系型數(shù)據(jù)庫(kù)中，當(dāng)系統(tǒng)規(guī)模大到單一節(jié)點(diǎn)的數(shù)據(jù)庫(kù)無(wú)法支撐時(shí)，一般有兩種方法：垂直擴(kuò)展與水平擴(kuò)展。 · 垂直擴(kuò)展：垂直擴(kuò)展比較好理解，簡(jiǎn)單來(lái)說(shuō)就是按照功能切分?jǐn)?shù)據(jù)庫(kù)，將不同功能的數(shù)據(jù)，存儲(chǔ)在不同的數(shù)據(jù)庫(kù)中，這樣一個(gè)大數(shù)據(jù)庫(kù)就被切分成多個(gè)小數(shù)據(jù)庫(kù)，從而達(dá)到了數(shù)據(jù)庫(kù)的擴(kuò)展。一個(gè)架構(gòu)設(shè)計(jì)良好的應(yīng)用系統(tǒng)，其總體功能一般肯定是由很多個(gè)松耦合的功能模塊所組成的，而每一個(gè)功能模塊所需要的數(shù)據(jù)對(duì)應(yīng)到數(shù)據(jù)庫(kù)中就是一張或多張表。各個(gè)功能模塊之間交互越少，越統(tǒng)一，系統(tǒng)的耦合度越低，這樣的系統(tǒng)就越容易實(shí)現(xiàn)垂直切分。 · 水平擴(kuò)展：簡(jiǎn)單來(lái)說(shuō)，可以將數(shù)據(jù)的水平切分理解為按照數(shù)據(jù)行來(lái)切分，就是將表中的某些行切分到一個(gè)數(shù)據(jù)庫(kù)中，而另外的某些行又切分到其他的數(shù)據(jù)庫(kù)中。為了能夠比較容易地判斷各行數(shù)據(jù)切分到了哪個(gè)數(shù)據(jù)庫(kù)中，切分總是需要按照某種特定的規(guī)則來(lái)進(jìn)行的，如按照某個(gè)數(shù)字字段的范圍，某個(gè)時(shí)間類型字段的范圍，或者某個(gè)字段的hash值。 垂直擴(kuò)展與水平擴(kuò)展各有優(yōu)缺點(diǎn)，一般一個(gè)大型系統(tǒng)會(huì)將水平與垂直擴(kuò)展結(jié)合使用。
實(shí)際應(yīng)用：圖1是為核高基項(xiàng)目設(shè)計(jì)的結(jié)構(gòu)化數(shù)據(jù)分布式存儲(chǔ)的架構(gòu)圖。
圖1可水平&垂直切分?jǐn)U展的數(shù)據(jù)訪問(wèn)框架
· 采用了獨(dú)立的分布式數(shù)據(jù)訪問(wèn)層，后端分布式數(shù)據(jù)庫(kù)集群對(duì)前端應(yīng)用透明。 · 集成了Memcached集群，減少對(duì)后端數(shù)據(jù)庫(kù)的訪問(wèn)，提高數(shù)據(jù)的查詢效率。 · 同時(shí)支持垂直及水平兩種擴(kuò)展方式。 · 基于全局唯一性主鍵范圍的切分方式，減輕了后續(xù)維護(hù)的工作量。 · 全局唯一性主鍵的生成采用DRBD+Heartbeat技術(shù)保證了可靠性。 · 利用MySQL Replication技術(shù)實(shí)現(xiàn)高可用的架構(gòu)。 注:以上的數(shù)據(jù)切分方案并不是唯一擴(kuò)展MySql的方法，有興趣的讀者可以關(guān)注一下” 云計(jì)算時(shí)代的MySQL-Clustrix Sierra分布式數(shù)據(jù)庫(kù)系統(tǒng)”。
非結(jié)構(gòu)化數(shù)據(jù)的存儲(chǔ)及應(yīng)用 相對(duì)于結(jié)構(gòu)化數(shù)據(jù)而言,不方便用數(shù)據(jù)庫(kù)二維邏輯表來(lái)表現(xiàn)的數(shù)據(jù)即稱為非結(jié)構(gòu)化數(shù)據(jù),包括所有格式的辦公文檔、文本、圖片、XML、HTML、各類報(bào)表、圖像和音頻/視頻信息等等。 分布式文件系統(tǒng)是實(shí)現(xiàn)非結(jié)構(gòu)化數(shù)據(jù)存儲(chǔ)的主要技術(shù)，說(shuō)到分布式文件系統(tǒng)就不得不提GFS（全稱為"Google File System"），GFS的系統(tǒng)架構(gòu)圖如下圖所示。
圖3 Google-file-system架構(gòu)圖（詳細(xì)）
GFS將整個(gè)系統(tǒng)分為三類角色：Client（客戶端）、Master（主服務(wù)器）、Chunk Server（數(shù)據(jù)塊服務(wù)器）。
· Client（客戶端）：是GFS提供給應(yīng)用程序的訪問(wèn)接口，它是一組專用接口，不遵守POSIX規(guī)范，以庫(kù)文件的形式提供。應(yīng)用程序直接調(diào)用這些庫(kù)函數(shù)，并與該庫(kù)鏈接在一起。 · Master（主服務(wù)器）：是GFS的管理節(jié)點(diǎn)，主要存儲(chǔ)與數(shù)據(jù)文件相關(guān)的元數(shù)據(jù)，而不是Chunk（數(shù)據(jù)塊）。元數(shù)據(jù)包括：命名空間（Name Space），也就是整個(gè)文件系統(tǒng)的目錄結(jié)構(gòu)，一個(gè)能將64位標(biāo)簽映射到數(shù)據(jù)塊的位置及其組成文件的表格，Chunk副本位置信息和哪個(gè)進(jìn)程正在讀寫(xiě)特定的數(shù)據(jù)塊等。還有Master節(jié)點(diǎn)會(huì)周期性地接收從每個(gè)Chunk節(jié)點(diǎn)來(lái)的更新（"Heart- beat"）來(lái)讓元數(shù)據(jù)保持最新?tīng)顟B(tài)。 · Chunk Server（數(shù)據(jù)塊服務(wù)器）：負(fù)責(zé)具體的存儲(chǔ)工作，用來(lái)存儲(chǔ)Chunk。GFS將文件按照固定大小進(jìn)行分塊，默認(rèn)是64MB，每一塊稱為一個(gè)Chunk（數(shù)據(jù)塊），每一個(gè)Chunk以Block為單位進(jìn)行劃分，大小為64KB，每個(gè)Chunk有一個(gè)唯一的64位標(biāo)簽。GFS采用副本的方式實(shí)現(xiàn)容錯(cuò)，每一個(gè)Chunk有多個(gè)存儲(chǔ)副本（默認(rèn)為三個(gè)）。 Chunk Server的個(gè)數(shù)可有有多個(gè)，它的數(shù)目直接決定了GFS的規(guī)模。 GFS之所以重要的原因在于，在Google公布了GFS論文之后，許多開(kāi)源組織基于GFS的論文開(kāi)發(fā)了各自的分布式文件系統(tǒng)，其中比較知名的有HDFS，MooseFS，MogileFS等。
實(shí)際應(yīng)用：由于核高基的項(xiàng)目中未來(lái)會(huì)有大量的數(shù)據(jù)與應(yīng)用需要存儲(chǔ)，所以我們?cè)O(shè)計(jì)時(shí)也采用分布式文件系統(tǒng)的方案，由于開(kāi)源的分布式文件系統(tǒng)可以基本滿足我們需求，另外從時(shí)間上來(lái)說(shuō)也比較緊張，所以我們采用了開(kāi)源的MooseFS作為底層的分布式文件系統(tǒng)。 · MooseFS存在的問(wèn)題：由于MooseFS是也是按照GFS論文設(shè)計(jì)的，只有一個(gè)Master（主服務(wù)器），雖然可以增加一個(gè)備份的日志服務(wù)器，但是還是存在Master無(wú)法擴(kuò)展的問(wèn)題，當(dāng)單一Master節(jié)點(diǎn)上存儲(chǔ)的元數(shù)據(jù)越來(lái)越多的時(shí)候，Master節(jié)點(diǎn)占用的內(nèi)存會(huì)越來(lái)越多，直到達(dá)到服務(wù)器的內(nèi)存上限，所以單一Master節(jié)點(diǎn)存在內(nèi)存上的瓶頸，只能存儲(chǔ)有限的數(shù)據(jù)，可擴(kuò)展性差，并且不穩(wěn)定。 · 對(duì)MooseFS的優(yōu)化：面對(duì)MooseFS存在的問(wèn)題，我們采用了類似分布式數(shù)據(jù)庫(kù)中的“Sharding”技術(shù)，設(shè)計(jì)了一個(gè)分布式文件系統(tǒng)訪問(wèn)框架，可以做到對(duì)分布式文件系統(tǒng)做垂直與水平切分。這樣就最大限度的保證了MooseFS系統(tǒng)的可擴(kuò)展性與穩(wěn)定性。 下圖是為核高基項(xiàng)目設(shè)計(jì)的非結(jié)構(gòu)化數(shù)據(jù)分布式存儲(chǔ)的架構(gòu)圖。我們?cè)O(shè)計(jì)了兩種訪問(wèn)方式，一種是類似GFS的API訪問(wèn)方式，以庫(kù)文件的方式提供，應(yīng)用程序通過(guò)調(diào)用API直接訪問(wèn)分布式文件系統(tǒng)。第二種是通過(guò)RESTful web Service訪問(wèn)。
圖4可水平&垂直切分?jǐn)U展的分布式文件系統(tǒng)訪問(wèn)框架（API版）
圖5可水平&垂直切分?jǐn)U展的分布式文件系統(tǒng)訪問(wèn)框架（RESTful web Service版）
半結(jié)構(gòu)化數(shù)據(jù)的存儲(chǔ)及應(yīng)用 就是介于完全結(jié)構(gòu)化數(shù)據(jù)（如關(guān)系型數(shù)據(jù)庫(kù)、面向?qū)ο髷?shù)據(jù)庫(kù)中的數(shù)據(jù)）和完全無(wú)結(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ù)庫(kù)模式的嚴(yán)格概念，這些模型中的數(shù)據(jù)都是自描述的。
由于半結(jié)構(gòu)化數(shù)據(jù)沒(méi)有嚴(yán)格的schema定義，所以不適合用傳統(tǒng)的關(guān)系型數(shù)據(jù)庫(kù)進(jìn)行存儲(chǔ)，適合存儲(chǔ)這類數(shù)據(jù)的數(shù)據(jù)庫(kù)被稱作“NoSQL”數(shù)據(jù)庫(kù)。
NoSQL的定義： 被稱作下一代的數(shù)據(jù)庫(kù)，具有非關(guān)系型，分布式，輕量級(jí)，支持水平擴(kuò)展且一般不保證遵循ACID原則的數(shù)據(jù)儲(chǔ)存系統(tǒng)?！癗oSQL”其實(shí)是具有誤導(dǎo)性的別名，稱作Non Relational Database(非關(guān)系型數(shù)據(jù)庫(kù))更為恰當(dāng)。所謂“非關(guān)系型數(shù)據(jù)庫(kù)”指的是： · 使用松耦合類型、可擴(kuò)展的數(shù)據(jù)模式來(lái)對(duì)數(shù)據(jù)進(jìn)行邏輯建模(Map，列，文檔，圖表等)，而不是使用固定的關(guān)系模式元組來(lái)構(gòu)建數(shù)據(jù)模型。 · 以遵循于CAP定理（能保證在一致性，可用性和分區(qū)容忍性三者中中達(dá)到任意兩個(gè)）的跨多節(jié)點(diǎn)數(shù)據(jù)分布模型而設(shè)計(jì)，支持水平伸縮。這意味著對(duì)于多數(shù)據(jù)中心和動(dòng)態(tài)供應(yīng)（在生產(chǎn)集群中透明地加入/刪除節(jié)點(diǎn)）的必要支持，也即彈性(Elasticity)。 · 擁有在磁盤(pán)或內(nèi)存中，或者在這兩者中都有的，對(duì)數(shù)據(jù)持久化的能力，有時(shí)候還可以使用可熱插拔的定制存儲(chǔ)。 · 支持多種的‘Non-SQL’接口(通常多于一種)來(lái)進(jìn)行數(shù)據(jù)訪問(wèn)。 圖6是Sourav Mazumder提出的NoSQL總體架構(gòu)：
圖6 NoSQL總體架構(gòu) · 接口：REST (HBase，CouchDB，Riak等)，MapReduce (HBase，CouchDB，MongoDB，Hypertable等)，Get/Put (Voldemort，Scalaris等)，Thrift (HBase，Hypertable，Cassandra等)，語(yǔ)言特定的API(MongoDB)。 · 邏輯數(shù)據(jù)模型：面向鍵值對(duì)的(Voldemort，Dynomite 等)，面向Column Family的(BigTable，HBase，Hypertable 等)，面向文檔的(Couch DB，MongoDB等)，面向圖的(Neo4j， Infogrid等) · 數(shù)據(jù)分布模型：致性和可用性(HBase，Hypertable， MongoDB等)， 可用性和可分區(qū)性(Cassandra等)。一致性和可分區(qū)性的組合會(huì)導(dǎo)致一些非額定的節(jié)點(diǎn)產(chǎn)生可用性的損失。有趣的是目前還沒(méi)有一個(gè)“非關(guān)系型數(shù)據(jù)庫(kù)”支持這一組合。 · 數(shù)據(jù)持久性：基于內(nèi)存的(如Redis，Scalaris， Terrastore)，基于磁盤(pán)的(如MongoDB，Riak等)，或內(nèi)存及磁盤(pán)二者的結(jié)合(如 HBase，Hypertable，Cassandra)。存儲(chǔ)的類型有助于我們辨別該解決方案適用于哪種類型。然而，在大多數(shù)情況下人們發(fā)現(xiàn)基于組合方 案的解決方案是最佳的選擇。既能通過(guò)內(nèi)存數(shù)據(jù)存儲(chǔ)支持高性能，又能在寫(xiě)入足夠多的數(shù)據(jù)后存儲(chǔ)到磁盤(pán)來(lái)保證持續(xù)性。 NoSQL中的重要理論基礎(chǔ)： CAP理論： · C: Consistency 一致性 · A: Availability 可用性(指的是快速獲取數(shù)據(jù)) · P: Tolerance of network Partition 分區(qū)容忍性(分布式)
圖7 CAP理論 CAP原理告訴我們，這三個(gè)因素最多只能滿足兩個(gè)，不可能三者兼顧。對(duì)于分布式系統(tǒng)來(lái)說(shuō)，分區(qū)容錯(cuò)是基本要求，所以必然要放棄一致性。對(duì)于大型網(wǎng)站來(lái)說(shuō)，分區(qū)容錯(cuò)和可用性的要求更高，所以一般都會(huì)選擇適當(dāng)放棄一致性。對(duì)應(yīng)CAP理論，NoSQL追求的是AP，而傳統(tǒng)數(shù)據(jù)庫(kù)追求的是CA，這也可以解釋為什么 傳統(tǒng)數(shù)據(jù)庫(kù)的擴(kuò)展能力有限的原因。
BASE模型： 說(shuō)起來(lái)很有趣，BASE的英文意義是堿，而ACID是酸。真的是水火不容啊。 · Basically Availble –基本可用 · Soft-state –軟狀態(tài)/柔性事務(wù) · Eventual Consistency –最終一致性 BASE模型是傳統(tǒng)ACID模型的反面，不同于ACID模型，BASE強(qiáng)調(diào)犧牲高一致性，從而獲得可用性或可靠性。 基本可用是指通過(guò)Sharding，允許部分分區(qū)失敗。 軟狀態(tài)是指異步，允許數(shù)據(jù)在一段時(shí)間內(nèi)的不一致，只要保證最終一致就可以了。 最終一致性是整個(gè)NoSQL中的一個(gè)核心理念，強(qiáng)調(diào)最終數(shù)據(jù)是一致的就可以了，而不是時(shí)時(shí)一致。 Quorum NRW：
圖8 Quorum NRW
N: 復(fù)制的節(jié)點(diǎn)數(shù)，即一份數(shù)據(jù)被保存的份數(shù)。
這三個(gè)因素決定了可用性，一致性和分區(qū)容錯(cuò)性。只需W + R > N，就可以保證強(qiáng)一致性。
實(shí)際應(yīng)用： 今年上半年我在aspire的搜索團(tuán)隊(duì)中負(fù)責(zé)互聯(lián)網(wǎng)搜索的設(shè)計(jì)與開(kāi)發(fā)，我設(shè)計(jì)的網(wǎng)頁(yè)爬蟲(chóng)系統(tǒng)就是采用Cassandra來(lái)存儲(chǔ)網(wǎng)頁(yè)與鏈接信息的。下面結(jié)合我的實(shí)際使用經(jīng)驗(yàn)談?wù)勎覍?duì)Cassandra的看法： 優(yōu)點(diǎn)： · 彈性擴(kuò)展：由于Cassandra是完全分布式的，使用時(shí)不需要再像使用MySQL那樣自己設(shè)計(jì)復(fù)雜的數(shù)據(jù)切分方案，也不再配置復(fù)雜的DRBD+Heartbeat，一切都變得非常簡(jiǎn)單了，只需要簡(jiǎn)單的配置就可以給一個(gè)集群中增加一個(gè)新的節(jié)點(diǎn)，而且對(duì)客戶端完全是透明的，不需要任何更改。 · 靈活的schema：不需要象數(shù)據(jù)庫(kù)一樣預(yù)先設(shè)計(jì)schema，增加或者刪除字段非常方便。 · 使用簡(jiǎn)單：由于沒(méi)有類似SQL這樣復(fù)雜的查詢語(yǔ)言，學(xué)習(xí)成本不高，很容易上手。 缺點(diǎn)： · 穩(wěn)定性差：在我們的實(shí)際使用過(guò)程中發(fā)現(xiàn)，單機(jī)數(shù)據(jù)量達(dá)到200G以上，時(shí)不時(shí)就會(huì)發(fā)生宕機(jī)現(xiàn)象。 · 缺乏管理與分析工具：傳統(tǒng)的關(guān)系型數(shù)據(jù)都有比較好用的管理與分析工具，使用這些工具可以輕松的管理數(shù)據(jù)庫(kù)，查看數(shù)據(jù)，分析性能瓶頸等，而Cassandra確缺少類似的工具，就連簡(jiǎn)單的查看一條數(shù)據(jù)，都要通過(guò)編程才能看到。
本人qq群也有許多的技術(shù)文檔，希望可以為你提供一些幫助(非技術(shù)的勿加)。QQ群： 281442983 (點(diǎn)擊鏈接加入群：http://jq.qq.com/?_wv=1027&k=29LoD19) QQ：1542385235
我的淘寶店，可以進(jìn)去逛逛噢：https://shop108912636.taobao.com/index.htm?spm=2013.1.w5001-7867000954.3.1d29318dPlLar7&scene=taobao_shop
|
|
|
