分布式存儲(chǔ)技術(shù)及應(yīng)用

分布式存儲(chǔ)技術(shù)及應(yīng)用didyouknow(“:///)的數(shù)據(jù)“:///)的數(shù)據(jù)，目前互聯(lián)網(wǎng)上可訪問的信息數(shù)量接近11百萬億億(12為了解決這個(gè)問題而進(jìn)展起來的技術(shù)，下面讓將會(huì)具體介紹這個(gè)技術(shù)及應(yīng)用。分布式存儲(chǔ)概念一個(gè)虛擬的存儲(chǔ)設(shè)備，數(shù)據(jù)分散的存儲(chǔ)在企業(yè)的各個(gè)角落。具體技術(shù)及應(yīng)用：本文接下來將會(huì)分別介紹這三種數(shù)據(jù)如何分布式存儲(chǔ)。構(gòu)造化數(shù)據(jù)的存儲(chǔ)及應(yīng)用數(shù)據(jù)類型，存儲(chǔ)在關(guān)系數(shù)據(jù)庫里,可以用二維表構(gòu)造來表達(dá)實(shí)現(xiàn)的數(shù)據(jù)。大多數(shù)系統(tǒng)都有大量的構(gòu)造化數(shù)據(jù)，一般存儲(chǔ)在OracleMySQL當(dāng)系統(tǒng)規(guī)模大到單一節(jié)點(diǎn)的數(shù)據(jù)庫無法支撐時(shí)，一般有兩種方法：垂直擴(kuò)展與水平擴(kuò)展。垂直擴(kuò)展：垂直擴(kuò)展比較好理解，簡潔來說就是依據(jù)功能切分?jǐn)?shù)據(jù)庫，將不同功能的數(shù)據(jù)，存儲(chǔ)在不同的數(shù)據(jù)庫中，這樣一個(gè)大數(shù)據(jù)庫就被切分成多個(gè)小數(shù)據(jù)庫，從而到達(dá)了數(shù)據(jù)庫的擴(kuò)展。一個(gè)架構(gòu)設(shè)計(jì)良好的應(yīng)用系統(tǒng)，其總體功能一般確定是由很多個(gè)松耦合的功能模塊所組成的，而每一個(gè)功能模塊所需要的數(shù)據(jù)對應(yīng)到數(shù)據(jù)庫中就是一張或多張表。各個(gè)功能模塊之間交互越少，越統(tǒng)一，系統(tǒng)的耦合度越低，這樣的系統(tǒng)就越簡潔實(shí)現(xiàn)垂直切分。水平擴(kuò)展：簡潔來說，可以將數(shù)據(jù)的水平切分理解為依據(jù)數(shù)據(jù)行來切分，就是將表中的某些行切分到一個(gè)數(shù)據(jù)庫中，而另外的某些行又切分到其他的數(shù)據(jù)庫中。為了能夠比較簡潔地推斷各行數(shù)據(jù)切分到了哪個(gè)數(shù)據(jù)庫中，切分總是需要依據(jù)某種特定的規(guī)章來進(jìn)展的，如依據(jù)某個(gè)數(shù)字字段的范圍，某個(gè)時(shí)間類型字段的范圍，或者某個(gè)字段的hash垂直擴(kuò)展與水平擴(kuò)展各有優(yōu)缺點(diǎn)，一般一個(gè)大型系統(tǒng)會(huì)將水平與垂直擴(kuò)展結(jié)合使用。實(shí)際應(yīng)用：11&垂直切分?jǐn)U展的數(shù)據(jù)訪問框架承受了獨(dú)立的分布式數(shù)據(jù)訪問層，后端分布式數(shù)據(jù)庫集群對前端應(yīng)用透亮。集成了Memcached集群，削減對后端數(shù)據(jù)庫的訪問，提高數(shù)據(jù)的查詢效率。同時(shí)支持垂直及水平兩種擴(kuò)展方式?；谌治ㄒ恍灾麈I范圍的切分方式，減輕了后續(xù)維護(hù)的工作量。全局唯一性主鍵的生成承受DRBD+Heartbeat技術(shù)保證了牢靠性。利用MySQLReplication注:以上的數(shù)據(jù)切分方案并不是唯一擴(kuò)展MySql算時(shí)代的MySQL-ClustrixSierra非構(gòu)造化數(shù)據(jù)的存儲(chǔ)及應(yīng)用相對于構(gòu)造化數(shù)據(jù)而言,不便利用數(shù)據(jù)庫二維規(guī)律表來表現(xiàn)的數(shù)據(jù)即稱為非構(gòu)造化數(shù)據(jù),包括全部格式的辦公文檔、文本、圖片、XML、HTML、各類報(bào)表、圖像和音頻/視頻信息等等。GFS〔全稱為“GoogleFileSystem“〕，GFS2Google-file-system3Google-file-system〔具體〕GFSClient〔客戶端〕Master〔主效勞器、ChunkServer〔數(shù)據(jù)塊效勞器〕。Client〔客戶端〕：是GFS供給應(yīng)應(yīng)用程序的訪問接口，它是一組專用接口，不遵守POSIX標(biāo)準(zhǔn)，以庫文件的形式供給。應(yīng)用程序直接調(diào)用這些庫函數(shù)，并與該庫鏈接在一起。Master〔主效勞器〕：是GFS的治理節(jié)點(diǎn)，主要存儲(chǔ)與數(shù)據(jù)文件相關(guān)的元數(shù)據(jù)，而Chunk〔數(shù)據(jù)塊〕。元數(shù)據(jù)包括：命名空間〔NameSpace〕，也就是整個(gè)文64格，ChunkMaster會(huì)周期性地接收從每個(gè)Chunk〔“Heart-beat“〕來讓元數(shù)據(jù)保持最狀態(tài)。ChunkServer〔數(shù)據(jù)塊效勞器〕：負(fù)責(zé)具體的存儲(chǔ)工作，用來存儲(chǔ)Chunk。GFS件依據(jù)固定大小進(jìn)展分塊，默認(rèn)是64MB，每一塊稱為一個(gè)Chunk〔數(shù)據(jù)塊〕，每ChunkBlock64KB，每個(gè)Chunk64位標(biāo)簽。GFSChunk〔默認(rèn)為三個(gè)〕。ChunkServerGFSGFS之所以重要的緣由在于，在Google公布了GFSGFS文開發(fā)了各自的分布式文件系統(tǒng)，其中比較知名的有HDFS，MooseFS，MogileFS上來說也比較緊急，所以我們承受了開源的MooseFSMooseFS存在的問題：由于MooseFS是也是依據(jù)GFSMaster〔主效勞器〕，雖然可以增加一個(gè)備份的日志效勞器，但是還是存在Master無法擴(kuò)展的問題，當(dāng)單一MasterMaster點(diǎn)占用的內(nèi)存會(huì)越來越多，直到到達(dá)效勞器的內(nèi)存上限，所以單一Master節(jié)點(diǎn)存在內(nèi)存上的瓶頸，只能存儲(chǔ)有限的數(shù)據(jù)，可擴(kuò)展性差，并且不穩(wěn)定。MooseFS的優(yōu)化：面對MooseFS“Sharding”技術(shù)，設(shè)計(jì)了一個(gè)分布式文件系統(tǒng)訪問框架，可以做到對分布式文件系統(tǒng)做垂直與水平切分。這樣就最大限度的保證了MooseFS系統(tǒng)的可擴(kuò)展性與穩(wěn)定性。以下圖是為核高基工程設(shè)計(jì)的非構(gòu)造化數(shù)據(jù)分布式存儲(chǔ)的架構(gòu)圖。我們設(shè)計(jì)了兩種訪問方式，一種是類似GFSAPIAPI布式文件系統(tǒng)。其次種是通過RESTfulwebService4&垂直切分?jǐn)U展的分布式文件系統(tǒng)訪問框架〔API〕5&垂直切分?jǐn)U展的分布式文件系統(tǒng)訪問框架〔RESTfulwebService〕半構(gòu)造化數(shù)據(jù)的存儲(chǔ)及應(yīng)用〔和完全無構(gòu)造的數(shù)據(jù)〔如聲音、圖像文件等〕之間的數(shù)據(jù)，半構(gòu)造化數(shù)據(jù)模型具有肯定的構(gòu)造性，但較之傳統(tǒng)的關(guān)系和面對對象的模型更為敏捷念，這些模型中的數(shù)據(jù)都是自描述的。由于半構(gòu)造化數(shù)據(jù)沒有嚴(yán)格的schema定義，所以不適合用傳統(tǒng)的關(guān)系型數(shù)據(jù)庫進(jìn)展存儲(chǔ)，適合存儲(chǔ)這類數(shù)據(jù)的數(shù)據(jù)庫被稱作“NoSQL”數(shù)據(jù)庫。NoSQLACID原則的數(shù)據(jù)儲(chǔ)存系統(tǒng)?！癗oSQL”其實(shí)是具有誤導(dǎo)性的別名，稱作NonRelationalDatabase(非關(guān)系型數(shù)據(jù)庫)更為恰當(dāng)。所謂“非關(guān)系型數(shù)據(jù)庫”指的是：使用松耦合類型、可擴(kuò)展的數(shù)據(jù)模式來對數(shù)據(jù)進(jìn)展規(guī)律建模(Map，列，文檔，圖表等)，而不是使用固定的關(guān)系模式元組來構(gòu)建數(shù)據(jù)模型。以遵循于CAP定理〔〕的跨多節(jié)點(diǎn)數(shù)據(jù)分布模型而設(shè)計(jì)，支持水平伸縮。這意味著對于多數(shù)據(jù)中心和動(dòng)態(tài)供給〔在生產(chǎn)集群中透亮地參加/刪除節(jié)點(diǎn)〕的必要支持，也即彈性(Elasticity)。擁有在磁盤或內(nèi)存中，或者在這兩者中都有的，對數(shù)據(jù)長久化的力量，有時(shí)候還可以使用可熱插拔的定制存儲(chǔ)。支持多種的‘Non-SQL’接口(通常多于一種)來進(jìn)展數(shù)據(jù)訪問。6SouravMazumderNoSQL總體架構(gòu)：6NoSQL接口：REST(HBase，CouchDB，Riak，MapReduce(HBase，CouchDB，MongoDB，HypertableGet/Put(VoldemorScalarisThriftCassandraAPI(MongoDB)。規(guī)律數(shù)據(jù)模型：面對鍵值對的(Voldemort，Dynomite等)，面對ColumnFamily(BigTable，HBase，Hypertable等)，面對文檔的(CouchDB，MongoDB圖的(Neo4j，Infogrid數(shù)據(jù)分布模型：致性和可用性(HBase，Hypertable，MongoDB區(qū)性(Cassandra等)。全都性和可分區(qū)性的組合會(huì)導(dǎo)致一些非額定的節(jié)點(diǎn)產(chǎn)生可用性的損失。好玩的是目前還沒有一個(gè)“非關(guān)系型數(shù)據(jù)庫”支持這一組合。數(shù)據(jù)長久性：基于內(nèi)存的(如Redis，Scalaris，Terrastore)，基于磁盤的(如MongoDB，RiakHBase，Hypertable，Cassandra)。存儲(chǔ)的類型有助于我們區(qū)分該解決方案適用于哪種類型。然而，在大多數(shù)狀況下人們覺察基于組合方案的解決方案是最正確的選擇。既能通過內(nèi)存數(shù)據(jù)存儲(chǔ)支持高性能，又能在寫入足夠多的數(shù)據(jù)后存儲(chǔ)到磁盤來保證持續(xù)性。NoSQLCAPC:Consistency全都性A:Availability可用性(指的是快速獵取數(shù)據(jù))P:ToleranceofnetworkPartition7CAPCAPCAPNoSQL追求的是AP，而傳統(tǒng)數(shù)據(jù)庫追求的是CABASE說起來很好玩，BASE的英文意義是堿，而ACID是酸。真的是水火不容啊。BasicallyAvailble–根本可用Soft-state–軟狀態(tài)/柔性事務(wù)EventualConsistency–最終全都性BASE模型是傳統(tǒng)ACID模型的反面，不同于ACIDBASE可用性或牢靠性。根本可用是指通過Sharding，允許局部分區(qū)失敗。軟狀態(tài)是指異步，允許數(shù)據(jù)在一段時(shí)間內(nèi)的不全都，只要保證最終全都就可以了。最終全都性是整個(gè)NoSQL全都。QuorumNRW：8QuorumNRWN:復(fù)制的節(jié)點(diǎn)數(shù)，即一份數(shù)據(jù)被保存的份數(shù)。R:成功讀操作的最小節(jié)點(diǎn)數(shù)，即每次讀取成功需要的份數(shù)。W:成功寫操作的最小節(jié)點(diǎn)數(shù)，即每次寫成功需要的份數(shù)。這三個(gè)因素打算了可用性，全都性和分區(qū)容錯(cuò)性。只需W+R>N，就可以保證強(qiáng)全都性。實(shí)際應(yīng)用：今年上半年我在aspire網(wǎng)頁爬蟲系統(tǒng)就是承受Cassandra談我對Cassandra優(yōu)點(diǎn)：彈性擴(kuò)展：由于Cassandra是完全分布式的，使用時(shí)不需要再像使用MySQL那樣自DRBD+Heartbeat，一切都變得格外簡潔了，只需要簡潔的配置就可以給一個(gè)集群中增加一個(gè)的節(jié)點(diǎn)，而且對客戶端完全是透亮的，不需要任何更改。敏捷的schema：不需要象數(shù)據(jù)庫一樣預(yù)先設(shè)計(jì)schema，增加或者刪除