




版權(quán)說明:本文檔由用戶提供并上傳,收益歸屬內(nèi)容提供方,若內(nèi)容存在侵權(quán),請進(jìn)行舉報或認(rèn)領(lǐng)
文檔簡介
1、根據(jù)CAP理論,一致性(C),可用性(A),分區(qū)容錯性(P),三者不可兼得,必須有所取舍。 而傳統(tǒng)數(shù)據(jù)庫保證了強一致性(ACID模型)和高可用性,所以要想實現(xiàn)一個分布式數(shù)據(jù)庫集 群非常困難,這也解釋了為什么數(shù)據(jù)庫的擴展能力十分有限。而近年來不斷發(fā)展壯大的 NoSQL運動,就是通過犧牲強一致性,采用BASE模型,用最終一致性的思想來設(shè)計分布 式系統(tǒng),從而使得系統(tǒng)可以達(dá)到很高的可用性和擴展性。但是,對于CAP理論也有一些不同的聲音,數(shù)據(jù)庫大師Michael Stonebraker就撰文Errors in Database Systems, Eventual Consistency, and the
2、 CAP Theorem,表示為了 P 而犧牲 C 是不 可取的。事實上,數(shù)據(jù)庫系統(tǒng)最大的優(yōu)勢就對一致性的保證,如果我們放棄了一致性,也許 NoSQL比數(shù)據(jù)庫更有優(yōu)勢。那么,有沒有可能實現(xiàn)一套分布式數(shù)據(jù)庫集群,即保證可用性 和一致性,又可以提供很好的擴展能力呢?回答是:有的。目前,有很多分布式 數(shù)據(jù)庫的產(chǎn)品,但是絕大部分是面向DSS類型的應(yīng)用,因為相比較 OLTP應(yīng)用,DSS應(yīng)用更容易做到分布式擴展。Michael Stonebraker提到了一種新型的數(shù)據(jù) 庫 VoltDB,它的定義是 Next-Generation SQL Database for Fast-Scaling OLTP Ap
3、plications 雖 然產(chǎn)品還沒有問世,但是從技術(shù)資料上來看,它有幾個特點:采用Share nothing架構(gòu),將物理服務(wù)器劃分為以CPU core為單位的Virtual node,采用 Sharding技術(shù),將數(shù)據(jù)自動分布到不同的Virtual node,最大限度的利用機器的計算資源;采用內(nèi)存數(shù)據(jù)訪問技術(shù),類似于內(nèi)存數(shù)據(jù)庫(In-memory database),區(qū)別于傳統(tǒng)的數(shù)據(jù)庫 (Disk-based database),消除了傳統(tǒng)數(shù)據(jù)庫內(nèi)存管理的開銷,而且響應(yīng)速度非???;每個Virtual node上的操作是自治的,利用隊列技術(shù)將并發(fā)訪問變?yōu)榇性L問,消除了傳 統(tǒng)數(shù)據(jù)庫串行控制的開
4、銷(比如Latch和Lock);數(shù)據(jù)同步寫多個副本,不存在單點故障,而且消除了傳統(tǒng)數(shù)據(jù)庫需要記錄redo log的開銷。Sharednothing OLTP DBMS Rijn?5CindLJSrcif nodes connectedbyLANSingie4hreaded execution engines3 deployed to each coreTables automatically partitioned & distributed to engines where theyre processed at main memory speedDistributed execution
5、planner assigns work to engines, which ope rate exclusively on their assigned partitionsAuto replicabon & recovery across nodes for high availability d across casters for disaster recoveryVoltDB與傳統(tǒng)數(shù)據(jù)庫的對比,可以看到VoltDB即支持傳統(tǒng)數(shù)據(jù)庫的ACID模型,又提供了 類似NoSQL產(chǎn)品很高的擴展能力。mysqldmysqldCastons Ciients CNDBAPI)這個產(chǎn)品,讓我想到了 M
6、ySQL cluster,同樣是shared-nothing架構(gòu),NDB存儲引擎也要求 將數(shù)據(jù)存放在內(nèi)存中,數(shù)據(jù)根據(jù)PK被分布到多個不同的節(jié)點上,同一份數(shù)據(jù)可以保存多個 副本,防止單點故障。(NDBManagement I-勰mJMySQLC APINDB Management Server ndb_ingmdClients / APIsPHPmysqldData NodesI iCon nector/ N ET| / /J Connector/JNoSQLVoltDBTraditionalDBMSScale-outgrowth Clustered high availability Inte
7、grated replication ACID compliant SQL interface Single-threadedAgile schema.Cross-partition joinsIn app codeIn app code AutomaticCost at web scaleB中MySQL cluster目前的主要問題是性能不佳,但是我認(rèn)為MySQL cluster的架構(gòu)是分布式數(shù) 據(jù)庫未來的趨勢,Oracle收購MySQL后,很多人對MySQL的前途表示擔(dān)憂,而我作為一 個用戶,除了可能會收費這件事以外,我一點也不擔(dān)心MySQL的前景,反而有所期待,因 為在數(shù)據(jù)庫領(lǐng)域沒有任何
8、一個公司比Oracle更懂?dāng)?shù)據(jù)庫,而Oracle也正在大力發(fā)展MySQL cluster,MySQL cluster一定會成為分布式數(shù)據(jù)庫領(lǐng)域內(nèi)最好的解決方案之一。NoSQL數(shù)據(jù)庫異軍突起,隨著Digg和大型應(yīng)用不斷采取NoSQL,NoSQL運動 已經(jīng)蓬勃發(fā)展,NoSQL數(shù)據(jù)庫很多,如何對他們分類,以便方便地根據(jù)自己應(yīng)用特色選擇 不同的NoSQL數(shù)據(jù)庫呢?NoSQL = HVSP無(傳統(tǒng)關(guān)系數(shù)據(jù)庫的)join或明顯事務(wù)的高容量簡單處理。按照數(shù)據(jù)模型保存性質(zhì)將當(dāng)前NoSQL分為四種:Key-value stores 鍵值存儲,保存 keys+BLOBs (二進(jìn)制大對象 Binary Large
9、OBjects)Table-oriented 面向表,主要有 Google 的 BigTable 和 Cassandra.Document-oriented面向文本,文本是一種類似XML文檔,MongoDB和CouchDBGraph-oriented 面向圖論.如 Neo4J.NoSQL 一般都是分布式數(shù)據(jù)庫,高性能是其特點,因此,數(shù)據(jù)是如何被分布、復(fù)制/碎片 以及合成就成為關(guān)鍵,這其中涉及你的應(yīng)用對數(shù)據(jù)一致性的要求,見CAP原理,不同一致 性處理方式?jīng)Q定不同類型:基本上基于Dynamo.核心思想就是在多個節(jié)點之間獲得最終一致性就可以,即使你有 時會讀到臟數(shù)據(jù).好處是寫數(shù)據(jù)時從來不會阻塞。那種
10、強制性節(jié)點一致性,如2PC,兩段事 務(wù)提交將會讓你的寫關(guān)閉停頓,使用Dynamo-like風(fēng)格你能將數(shù)據(jù)寫到多個節(jié)點中,通過 一致hashing,然后你可以從這些節(jié)點讀取數(shù)據(jù),返回正確結(jié)果給用戶。基本基于BigTable.這種模型中,使用常用方式保持節(jié)點充分的一致性。比如同步復(fù)制, 由數(shù)據(jù)自己活或數(shù)據(jù)所在位置來實現(xiàn)一致性,不同產(chǎn)品實現(xiàn)細(xì)節(jié)不一樣。比如:MongoDB有一個面向文本類型的數(shù)據(jù)模型,它采取類似BigTable-like復(fù)制策略; Cassandra有面向表table-like數(shù)據(jù)模型,采取的是Dynamo-like風(fēng)格.以后應(yīng)該有數(shù)據(jù)是如何被持久化保存到磁盤上的區(qū)分,不同NoSQL
11、處理策略不一樣,有 的是寫一次保存一次;有的是定期保存,后者性能要好些。_ NoSQL數(shù)據(jù)庫最終一致性/BASE VS ACIDCAP理論六月 22nd, 2010 No Comments 存儲&NoSQL作者:閻斌|可以轉(zhuǎn)載,但必須以超鏈接形式標(biāo)明文章原始出處和作者信息網(wǎng)址:http:/UltimateA10年前,Eric Brewer教授提出了非常著名的CAP理論,后人也論證了 CAP理論的正確性。CAP理論指出:一個分布式系統(tǒng)不可能同時滿足一致性(Consistency),可用性(Availibility) 和分區(qū)容忍性(Partition Tolerance)這三個需求。最多只能同時滿
12、足其中的兩個。 一致性(Consistency):對于分布式的存儲系統(tǒng),一個數(shù)據(jù)往往會存在多份。簡單的說,一致性會讓 客戶對數(shù)據(jù)的修改操作(增/刪/改)要么在所有的數(shù)據(jù)副本(在英文文獻(xiàn)中 常稱為Replica)全部成功,要么全部失敗。即,修改操作對于一份數(shù)據(jù)的所 有副本而言,是原子(Atomic)的操作。如果一個存儲系統(tǒng)可以保證一致性,那么則客戶讀寫的數(shù)據(jù)完全可以保證是 最新的。不會發(fā)生兩個不同的客戶端在不同的存儲節(jié)點中讀取到不同副本的 情況。 可用性(Availability):可用性很簡單,顧名思義,就是指在客戶端想要訪問數(shù)據(jù)的時候,可以得到 響應(yīng)。但是注意,系統(tǒng)可用(Available)
13、并不代表存儲系統(tǒng)所有節(jié)點提供的 數(shù)據(jù)是一致的。比如客戶端想要讀取文章評論,存儲系統(tǒng)可以返回客戶端數(shù) 據(jù),但是評論缺少最新的一條。這種情況,我們?nèi)匀徽f系統(tǒng)是可用的。往往我們會對不同的應(yīng)用設(shè)定一個最長響應(yīng)時間,超過這個響應(yīng)時間的服務(wù) 我們?nèi)匀环Q之為不可用的。分區(qū)容忍性(Partition Tolerance):如果你的存儲系統(tǒng)只運行在一個節(jié)點上,要么系統(tǒng)整個崩潰,要么全部運行 良好。一旦針對同一服務(wù)的存儲系統(tǒng)分布到了多個節(jié)點后,整個存儲系統(tǒng)就 存在分區(qū)的可能性。比如,兩個存儲節(jié)點之間聯(lián)通的網(wǎng)絡(luò)斷開(無論長時間 或者短暫的),就形成了分區(qū)。對當(dāng)前的互聯(lián)網(wǎng)公司(例如Google)來說,為了提高服務(wù)質(zhì)量
14、,同一份數(shù)據(jù) 放置在不同城市乃至不同國家是非常正常的。因此節(jié)點之間形成分區(qū)也很正 常。Gilbert和Lynch將分區(qū)容忍性定義如下:No set of failures less than total network failure is allowed to cause the system to respond incorrectly除全部網(wǎng)絡(luò)節(jié)點全部故障以外,所有子節(jié)點集合的故障都不允許導(dǎo)致整個系 統(tǒng)不正確響應(yīng)。我在另外一篇文章(BASE: An Acid Alternative)中找到了一個對分區(qū)容忍性更為恰當(dāng)好理解的解釋:Operations will complete, even
15、 if individual components are unavailable.(即使部分的組件不可用,施加的操作也可以完成)CAP說明:在設(shè)計一個分布式存儲系統(tǒng)時,你不得不在三個特性中選擇放棄 一個。如果選擇Partition Tolerance和Consistency,那么即使壞了節(jié)點,操作必須 又一致,又能順利完成。所以就必須100%保證所有節(jié)點之間有很好的連通 性。這是很難做到的。最好的辦法就是將所有數(shù)據(jù)放到同一個節(jié)點中。但是 顯然這種設(shè)計是不滿足Availability的。如果要滿足Availability和Consistency,那么,為了保證可用,數(shù)據(jù)必須要 有Replica。這樣,系統(tǒng)顯然無法容忍Partitiono當(dāng)同一數(shù)據(jù)的兩個副本(Replica)分配到了兩個無法通信的Partition上時,顯然會返回錯誤的數(shù)據(jù)。最后看一下滿足Availability和Partition Tolerance的情況。滿足可用,就說 明數(shù)據(jù)必須要在不同節(jié)點中有replica。然而還必須保證在產(chǎn)生Partition的時 候仍然操作可以完成。那么,必然操作
溫馨提示
- 1. 本站所有資源如無特殊說明,都需要本地電腦安裝OFFICE2007和PDF閱讀器。圖紙軟件為CAD,CAXA,PROE,UG,SolidWorks等.壓縮文件請下載最新的WinRAR軟件解壓。
- 2. 本站的文檔不包含任何第三方提供的附件圖紙等,如果需要附件,請聯(lián)系上傳者。文件的所有權(quán)益歸上傳用戶所有。
- 3. 本站RAR壓縮包中若帶圖紙,網(wǎng)頁內(nèi)容里面會有圖紙預(yù)覽,若沒有圖紙預(yù)覽就沒有圖紙。
- 4. 未經(jīng)權(quán)益所有人同意不得將文件中的內(nèi)容挪作商業(yè)或盈利用途。
- 5. 人人文庫網(wǎng)僅提供信息存儲空間,僅對用戶上傳內(nèi)容的表現(xiàn)方式做保護(hù)處理,對用戶上傳分享的文檔內(nèi)容本身不做任何修改或編輯,并不能對任何下載內(nèi)容負(fù)責(zé)。
- 6. 下載文件中如有侵權(quán)或不適當(dāng)內(nèi)容,請與我們聯(lián)系,我們立即糾正。
- 7. 本站不保證下載資源的準(zhǔn)確性、安全性和完整性, 同時也不承擔(dān)用戶因使用這些下載資源對自己和他人造成任何形式的傷害或損失。
最新文檔
- 建筑施工合同轉(zhuǎn)讓協(xié)議
- 砂礫購銷合同
- 房地產(chǎn)項目顧問服務(wù)合同
- 售貨機銷售合同協(xié)議
- 醫(yī)藥研發(fā)服務(wù)合同
- 第12課《自定主題活動三:制作方便面盒滑翔機》(教學(xué)設(shè)計)-2023-2024學(xué)年四年級下冊綜合實踐活動浙教版
- Unit 6 教學(xué)設(shè)計2024-2025學(xué)年人教版(2024)七年級英語上冊
- 六安職業(yè)技術(shù)學(xué)院《獸醫(yī)流行病學(xué)專題》2023-2024學(xué)年第二學(xué)期期末試卷
- 石家莊城市經(jīng)濟職業(yè)學(xué)院《化學(xué)合成實驗》2023-2024學(xué)年第二學(xué)期期末試卷
- 中國地質(zhì)大學(xué)(北京)《水生態(tài)保護(hù)與修復(fù)》2023-2024學(xué)年第二學(xué)期期末試卷
- 2024-2025學(xué)年九年級化學(xué)人教版上冊檢測試卷(1-4單元)
- 2024年遼寧省鞍山岫巖滿族自治縣事業(yè)單位招聘(150人)歷年高頻難、易錯點500題模擬試題附帶答案詳解
- 護(hù)理質(zhì)控護(hù)士競聘
- 2024年4月自考00263外國法制史試題及答案
- 《井中分布式光纖聲波傳感數(shù)據(jù)采集規(guī)程》標(biāo)準(zhǔn)報批稿
- 人音版 音樂 八年級下冊 第一單元 我和你教案
- 代理法人免責(zé)協(xié)議書版本
- 2024年青島港灣職業(yè)技術(shù)學(xué)院單招職業(yè)適應(yīng)性測試題庫必考題
- 門診導(dǎo)診課件
- 《糖尿病患者血脂管理中國專家共識(2024版)》解讀
- 廣州石牌村改造規(guī)劃方案
評論
0/150
提交評論