NoSQL,是not only sql,是非關(guān)系數(shù)據(jù)庫(kù),不同于oracle等關(guān)系數(shù)據(jù)庫(kù)。hadoop,是分布式解決方案,即為Mapreduce(計(jì)算的)和HDFS(文件系統(tǒng)),使用Hadoop和NoSQL可以構(gòu)造海量數(shù)據(jù)解決方案。
創(chuàng)新互聯(lián)為客戶提供專業(yè)的網(wǎng)站設(shè)計(jì)制作、成都網(wǎng)站設(shè)計(jì)、程序、域名、空間一條龍服務(wù),提供基于WEB的系統(tǒng)開(kāi)發(fā). 服務(wù)項(xiàng)目涵蓋了網(wǎng)頁(yè)設(shè)計(jì)、網(wǎng)站程序開(kāi)發(fā)、WEB系統(tǒng)開(kāi)發(fā)、微信二次開(kāi)發(fā)、成都做手機(jī)網(wǎng)站等網(wǎng)站方面業(yè)務(wù)。
1. 鍵值數(shù)據(jù)庫(kù)
相關(guān)產(chǎn)品:Redis、Riak、SimpleDB、Chordless、Scalaris、Memcached
應(yīng)用:內(nèi)容緩存
優(yōu)點(diǎn):擴(kuò)展性好、靈活性好、大量寫(xiě)操作時(shí)性能高
缺點(diǎn):無(wú)法存儲(chǔ)結(jié)構(gòu)化信息、條件查詢效率較低
使用者:百度云(Redis)、GitHub(Riak)、BestBuy(Riak)、Twitter(Ridis和Memcached)
2. 列族數(shù)據(jù)庫(kù)
相關(guān)產(chǎn)品:BigTable、HBase、Cassandra、HadoopDB、GreenPlum、PNUTS
應(yīng)用:分布式數(shù)據(jù)存儲(chǔ)與管理
優(yōu)點(diǎn):查找速度快、可擴(kuò)展性強(qiáng)、容易進(jìn)行分布式擴(kuò)展、復(fù)雜性低
使用者:Ebay(Cassandra)、Instagram(Cassandra)、NASA(Cassandra)、Facebook(HBase)
3. 文檔數(shù)據(jù)庫(kù)
相關(guān)產(chǎn)品:MongoDB、CouchDB、ThruDB、CloudKit、Perservere、Jackrabbit
應(yīng)用:存儲(chǔ)、索引并管理面向文檔的數(shù)據(jù)或者類似的半結(jié)構(gòu)化數(shù)據(jù)
優(yōu)點(diǎn):性能好、靈活性高、復(fù)雜性低、數(shù)據(jù)結(jié)構(gòu)靈活
缺點(diǎn):缺乏統(tǒng)一的查詢語(yǔ)言
使用者:百度云數(shù)據(jù)庫(kù)(MongoDB)、SAP(MongoDB)
4. 圖形數(shù)據(jù)庫(kù)
圖形數(shù)據(jù)庫(kù)-使用圖作為數(shù)據(jù)模型來(lái)存儲(chǔ)數(shù)據(jù)。
相關(guān)產(chǎn)品:Neo4J、OrientDB、InfoGrid、GraphDB
應(yīng)用:大量復(fù)雜、互連接、低結(jié)構(gòu)化的圖結(jié)構(gòu)場(chǎng)合,如社交網(wǎng)絡(luò)、推薦系統(tǒng)等
優(yōu)點(diǎn):靈活性高、支持復(fù)雜的圖形算法、可用于構(gòu)建復(fù)雜的關(guān)系圖譜
缺點(diǎn):復(fù)雜性高、只能支持一定的數(shù)據(jù)規(guī)模
使用者:Adobe(Neo4J)、Cisco(Neo4J)、T-Mobile(Neo4J)
互聯(lián)網(wǎng)公司常用的基本集中在以下幾種,每種只舉一個(gè)比較常見(jiàn)或者應(yīng)用比較成功的例子吧。
1. In-Memory KV Store : Redis
in memory key-value store,同時(shí)提供了更加豐富的數(shù)據(jù)結(jié)構(gòu)和運(yùn)算的能力,成功用法是替代memcached,通過(guò)checkpoint和commit log提供了快速的宕機(jī)恢復(fù),同時(shí)支持replication提供讀可擴(kuò)展和高可用。
2. Disk-Based KV Store: Leveldb
真正基于磁盤(pán)的key-value storage, 模型單一簡(jiǎn)單,數(shù)據(jù)量不受限于內(nèi)存大小,數(shù)據(jù)落盤(pán)高可靠,Google的幾位大神出品的精品,LSM模型天然寫(xiě)優(yōu)化,順序?qū)懕P(pán)的方式對(duì)于新硬件ssd再適合不過(guò)了,不足是僅提供了一個(gè)庫(kù),需要自己封裝server端。
3. Document Store: Mongodb
分布式nosql,具備了區(qū)別mysql的最大亮點(diǎn):可擴(kuò)展性。mongodb 最新引人的莫過(guò)于提供了sql接口,是目前nosql里最像mysql的,只是沒(méi)有ACID的特性,發(fā)展很快,支持了索引等特性,上手容易,對(duì)于數(shù)據(jù)量遠(yuǎn)超內(nèi)存限制的場(chǎng)景來(lái)說(shuō),還需要慎重。
4. Column Table Store: HBase
這個(gè)富二代似乎不用贅述了,最大的優(yōu)勢(shì)是開(kāi)源,對(duì)于普通的scan和基于行的get等基本查詢,性能完全不是問(wèn)題,只是只提供裸的api,易用性上是短板,可擴(kuò)展性方面是最強(qiáng)的,其次坐上了Hadoop的快車,社區(qū)發(fā)展很快,各種基于其上的開(kāi)源產(chǎn)品不少,來(lái)解決諸如join、聚集運(yùn)算等復(fù)雜查詢。
什么是NoSQL數(shù)據(jù)庫(kù)?從名稱“非SQL”或“非關(guān)系型”衍生而來(lái),這些數(shù)據(jù)庫(kù)不使用類似SQL的查詢語(yǔ)言,通常稱為結(jié)構(gòu)化存儲(chǔ)。這些數(shù)據(jù)庫(kù)自1960年就已經(jīng)存在,但是直到現(xiàn)在一些大公司(例如Google和Facebook)開(kāi)始使用它們時(shí),這些數(shù)據(jù)庫(kù)才流行起來(lái)。該數(shù)據(jù)庫(kù)最明顯的優(yōu)勢(shì)是擺脫了一組固定的列、連接和類似SQL的查詢語(yǔ)言的限制。有時(shí),NoSQL這個(gè)名稱也可能表示“不僅僅SQL”,來(lái)確保它們可能支持SQL。 NoSQL數(shù)據(jù)庫(kù)使用諸如鍵值、寬列、圖形或文檔之類的數(shù)據(jù)結(jié)構(gòu),并且可以如JSON之類的不同格式存儲(chǔ)。
像MongoDB, Cassandra, HBase, DynamoDB, 和
Riak這些NoSQL缺乏傳統(tǒng)的原子事務(wù)機(jī)制,所謂原子事務(wù)機(jī)制是可以保證一系列寫(xiě)操作要么全部完成,要么全部不會(huì)完成,不會(huì)發(fā)生只完成一系列中一兩個(gè)
寫(xiě)操作;因?yàn)閿?shù)據(jù)庫(kù)不提供這種事務(wù)機(jī)制支持,開(kāi)發(fā)者需要自己編寫(xiě)代碼來(lái)確保一系列寫(xiě)操作的事務(wù)機(jī)制,比較復(fù)雜和測(cè)試。
這些NoSQL數(shù)據(jù)庫(kù)不提供事務(wù)機(jī)制原因在于其分布式特點(diǎn),一系列寫(xiě)操作中訪問(wèn)的數(shù)據(jù)可能位于不同的分區(qū)服務(wù)器,這樣的事務(wù)就變成分布式事務(wù),在分
布式事務(wù)中實(shí)現(xiàn)原子性需要彼此協(xié)調(diào),而協(xié)調(diào)是耗費(fèi)時(shí)間的,每臺(tái)機(jī)器在一個(gè)大事務(wù)過(guò)程中必須依次確認(rèn),這就需要一種協(xié)議確保一個(gè)事務(wù)中沒(méi)有任何一臺(tái)機(jī)器寫(xiě)操
作失敗。
這種協(xié)調(diào)是昂貴的,會(huì)增加延遲時(shí)間,關(guān)鍵問(wèn)題是,當(dāng)協(xié)調(diào)沒(méi)有完成時(shí),其他操作是不能讀取事務(wù)中寫(xiě)操作結(jié)果的,這是因?yàn)槭聞?wù)的all-or-
nothing原理導(dǎo)致,萬(wàn)一協(xié)調(diào)過(guò)程發(fā)現(xiàn)某個(gè)寫(xiě)操作不能完成,那么需要將其他寫(xiě)操作成功的進(jìn)行回滾。針對(duì)分布式事務(wù)的分布式協(xié)調(diào)對(duì)整體數(shù)據(jù)庫(kù)性能有嚴(yán)重
影響,不只是吞吐量還包括延遲時(shí)間,這樣大部分NoSQL數(shù)據(jù)庫(kù)因?yàn)樾阅軉?wèn)題就選擇不提供分布式事務(wù)。
MongoDB, Riak, HBase, 和 Cassandra提供基于單一鍵的事務(wù),這是因?yàn)樗行畔⒍己鸵粋€(gè)鍵key有關(guān),這個(gè)鍵是存儲(chǔ)在單個(gè)服務(wù)器上,這樣基于單鍵的事務(wù)不會(huì)帶來(lái)復(fù)雜的分布式協(xié)調(diào)。
那么看來(lái)擴(kuò)展性性能和分布式事務(wù)是一對(duì)矛盾,總要有取舍?實(shí)際上是不完全是,現(xiàn)在完全有可能提供高擴(kuò)展的性能同時(shí)提供分布式原子事務(wù)。
FIT是這樣一個(gè)在分布式系統(tǒng)提供原子事務(wù)的策略,在fairness公平性, isolation隔離性, 和throughput吞吐量(簡(jiǎn)稱FIT)可以權(quán)衡。
一個(gè)支持分布式事務(wù)的可伸縮分布式系統(tǒng)能夠完成這三個(gè)屬性中兩個(gè),公平是事務(wù)之間不會(huì)相互影響造成延遲;隔離性提供一種幻覺(jué)好像整個(gè)數(shù)據(jù)庫(kù)只有它自
己一個(gè)事務(wù),隔離性保證當(dāng)任何同時(shí)發(fā)生的事務(wù)發(fā)生沖突時(shí),能夠保證彼此能看到彼此的寫(xiě)操作結(jié)果,因此減輕了程序員為避免事務(wù)讀寫(xiě)沖突的強(qiáng)邏輯推理要求;吞
吐量是指每單元時(shí)間數(shù)據(jù)庫(kù)能夠并發(fā)處理多少事務(wù)。
FIT是如下進(jìn)行權(quán)衡:
保證公平性fairness 和隔離性isolation, 但是犧牲吞吐量
保證公平性fairness和吞吐量, 犧牲隔離性isolation
保證隔離性isolation和吞吐量throughput, 但是犧牲公平性fairness.
犧牲公平性:放棄公平性,數(shù)據(jù)庫(kù)能有更多機(jī)會(huì)降低分布式事務(wù)的成本,主要成本是分布式協(xié)調(diào)帶來(lái)的,也就是說(shuō),不需要在每個(gè)事務(wù)過(guò)程內(nèi)對(duì)每個(gè)機(jī)器都依
次確認(rèn)事務(wù)完成,這樣排隊(duì)式的確認(rèn)commit事務(wù)是很浪費(fèi)時(shí)間的,放棄公平性,意味著可以在事務(wù)外面進(jìn)行協(xié)調(diào),這樣就只是增加了協(xié)調(diào)時(shí)間,不會(huì)增加互相
沖突事務(wù)因?yàn)楸舜藳_突而不能運(yùn)行所耽擱的時(shí)間,當(dāng)系統(tǒng)不需要公平性時(shí),需要根據(jù)事務(wù)的優(yōu)先級(jí)或延遲等標(biāo)準(zhǔn)進(jìn)行指定先后執(zhí)行順序,這樣就能夠獲得很好的吞吐
量。
G-Store是一種放棄公平性的 Isolation-Throughput
的分布式key-value存儲(chǔ),支持多鍵事務(wù)(multi-key transactions),MongoDB 和
HBase在鍵key在同樣分區(qū)上也支持多鍵事務(wù),但是不支持跨分區(qū)的事務(wù)。
總之:傳統(tǒng)分布式事務(wù)性能不佳的原因是確保原子性(分布式協(xié)調(diào))和隔離性同時(shí)重疊,創(chuàng)建一個(gè)高吞吐量分布式事務(wù)的關(guān)鍵是分離這兩種關(guān)注,這種分離原
子性和隔離性的視角將導(dǎo)致兩種類型的系統(tǒng),第一種選擇是弱隔離性能讓沖突事務(wù)并行執(zhí)行和確認(rèn)提交;第二個(gè)選擇重新排序原子性和隔離性機(jī)制保證它們不會(huì)某個(gè)
時(shí)間重疊,這是一種放棄公平的事務(wù)執(zhí)行,所謂放棄公平就是不再同時(shí)照顧原子性和隔離性了,有所傾斜,放棄高標(biāo)準(zhǔn)道德要求就會(huì)帶來(lái)高自由高效率。