像MongoDB, Cassandra, HBase, DynamoDB, 和
創(chuàng)新互聯(lián)是一家專業(yè)提供孟村企業(yè)網(wǎng)站建設(shè),專注與成都做網(wǎng)站、成都網(wǎng)站設(shè)計(jì)、HTML5、小程序制作等業(yè)務(wù)。10年已為孟村眾多企業(yè)、政府機(jī)構(gòu)等服務(wù)。創(chuàng)新互聯(lián)專業(yè)網(wǎng)絡(luò)公司優(yōu)惠進(jìn)行中。
Riak這些NoSQL缺乏傳統(tǒng)的原子事務(wù)機(jī)制,所謂原子事務(wù)機(jī)制是可以保證一系列寫操作要么全部完成,要么全部不會(huì)完成,不會(huì)發(fā)生只完成一系列中一兩個(gè)
寫操作;因?yàn)閿?shù)據(jù)庫不提供這種事務(wù)機(jī)制支持,開發(fā)者需要自己編寫代碼來確保一系列寫操作的事務(wù)機(jī)制,比較復(fù)雜和測試。
這些NoSQL數(shù)據(jù)庫不提供事務(wù)機(jī)制原因在于其分布式特點(diǎ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ù)過程中必須依次確認(rèn),這就需要一種協(xié)議確保一個(gè)事務(wù)中沒有任何一臺(tái)機(jī)器寫操
作失敗。
這種協(xié)調(diào)是昂貴的,會(huì)增加延遲時(shí)間,關(guān)鍵問題是,當(dāng)協(xié)調(diào)沒有完成時(shí),其他操作是不能讀取事務(wù)中寫操作結(jié)果的,這是因?yàn)槭聞?wù)的all-or-
nothing原理導(dǎo)致,萬一協(xié)調(diào)過程發(fā)現(xiàn)某個(gè)寫操作不能完成,那么需要將其他寫操作成功的進(jìn)行回滾。針對(duì)分布式事務(wù)的分布式協(xié)調(diào)對(duì)整體數(shù)據(jù)庫性能有嚴(yán)重
影響,不只是吞吐量還包括延遲時(shí)間,這樣大部分NoSQL數(shù)據(jù)庫因?yàn)樾阅軉栴}就選擇不提供分布式事務(wù)。
MongoDB, Riak, HBase, 和 Cassandra提供基于單一鍵的事務(wù),這是因?yàn)樗行畔⒍己鸵粋€(gè)鍵key有關(guān),這個(gè)鍵是存儲(chǔ)在單個(gè)服務(wù)器上,這樣基于單鍵的事務(wù)不會(huì)帶來復(fù)雜的分布式協(xié)調(diào)。
那么看來擴(kuò)展性性能和分布式事務(wù)是一對(duì)矛盾,總要有取舍?實(shí)際上是不完全是,現(xiàn)在完全有可能提供高擴(kuò)展的性能同時(shí)提供分布式原子事務(wù)。
FIT是這樣一個(gè)在分布式系統(tǒng)提供原子事務(wù)的策略,在fairness公平性, isolation隔離性, 和throughput吞吐量(簡稱FIT)可以權(quán)衡。
一個(gè)支持分布式事務(wù)的可伸縮分布式系統(tǒng)能夠完成這三個(gè)屬性中兩個(gè),公平是事務(wù)之間不會(huì)相互影響造成延遲;隔離性提供一種幻覺好像整個(gè)數(shù)據(jù)庫只有它自
己一個(gè)事務(wù),隔離性保證當(dāng)任何同時(shí)發(fā)生的事務(wù)發(fā)生沖突時(shí),能夠保證彼此能看到彼此的寫操作結(jié)果,因此減輕了程序員為避免事務(wù)讀寫沖突的強(qiáng)邏輯推理要求;吞
吐量是指每單元時(shí)間數(shù)據(jù)庫能夠并發(fā)處理多少事務(wù)。
FIT是如下進(jìn)行權(quán)衡:
保證公平性fairness 和隔離性isolation, 但是犧牲吞吐量
保證公平性fairness和吞吐量, 犧牲隔離性isolation
保證隔離性isolation和吞吐量throughput, 但是犧牲公平性fairness.
犧牲公平性:放棄公平性,數(shù)據(jù)庫能有更多機(jī)會(huì)降低分布式事務(wù)的成本,主要成本是分布式協(xié)調(diào)帶來的,也就是說,不需要在每個(gè)事務(wù)過程內(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ì)帶來高自由高效率。
1、性能
都比較高,性能對(duì)我們來說應(yīng)該都不是瓶頸。
總體來講,TPS 方面 redis 和 memcache 差不多,要大于 mongodb。
2、操作的便利性
memcache 數(shù)據(jù)結(jié)構(gòu)單一。(key-value)
redis 豐富一些,數(shù)據(jù)操作方面,redis 更好一些,較少的網(wǎng)絡(luò) IO 次數(shù),同時(shí)還提供 list,set,
hash 等數(shù)據(jù)結(jié)構(gòu)的存儲(chǔ)。
mongodb 支持豐富的數(shù)據(jù)表達(dá),索引,最類似關(guān)系型數(shù)據(jù)庫,支持的查詢語言非常豐富。
3、內(nèi)存空間的大小和數(shù)據(jù)量的大小
redis 在 2.0 版本后增加了自己的 VM 特性,突破物理內(nèi)存的限制;可以對(duì) key value 設(shè)置過
期時(shí)間(類似 memcache)
memcache 可以修改最大可用內(nèi)存,采用 LRU 算法。Memcached 代理軟件 magent,比如建立
10 臺(tái) 4G 的 Memcache 集群,就相當(dāng)于有了 40G。 magent -s 10.1.2.1 -s 10.1.2.2:11211 -b
10.1.2.3:14000 mongoDB 適合大數(shù)據(jù)量的存儲(chǔ),依賴操作系統(tǒng) VM 做內(nèi)存管理,吃內(nèi)存也比較厲害,服務(wù)
不要和別的服務(wù)在一起。
4、可用性(單點(diǎn)問題)
對(duì)于單點(diǎn)問題,
redis,依賴客戶端來實(shí)現(xiàn)分布式讀寫;主從復(fù)制時(shí),每次從節(jié)點(diǎn)重新連接主節(jié)點(diǎn)都要依賴整
個(gè)快照,無增量復(fù)制,因性能和效率問題,
所以單點(diǎn)問題比較復(fù)雜;不支持自動(dòng) sharding,需要依賴程序設(shè)定一致 hash 機(jī)制。
一種替代方案是,不用 redis 本身的復(fù)制機(jī)制,采用自己做主動(dòng)復(fù)制(多份存儲(chǔ)),或者改成
增量復(fù)制的方式(需要自己實(shí)現(xiàn)),一致性問題和性能的權(quán)衡
Memcache 本身沒有數(shù)據(jù)冗余機(jī)制,也沒必要;對(duì)于故障預(yù)防,采用依賴成熟的 hash 或者環(huán)
狀的算法,解決單點(diǎn)故障引起的抖動(dòng)問題。
mongoDB 支持 master-slave,replicaset(內(nèi)部采用 paxos 選舉算法,自動(dòng)故障恢復(fù)),auto sharding 機(jī)制,對(duì)客戶端屏蔽了故障轉(zhuǎn)移和切分機(jī)制。
5、可靠性(持久化)
對(duì)于數(shù)據(jù)持久化和數(shù)據(jù)恢復(fù),
redis 支持(快照、AOF):依賴快照進(jìn)行持久化,aof 增強(qiáng)了可靠性的同時(shí),對(duì)性能有所影
響
memcache 不支持,通常用在做緩存,提升性能;
MongoDB 從 1.8 版本開始采用 binlog 方式支持持久化的可靠性
6、數(shù)據(jù)一致性(事務(wù)支持)
Memcache 在并發(fā)場景下,用 cas 保證一致性redis 事務(wù)支持比較弱,只能保證事務(wù)中的每個(gè)操作連續(xù)執(zhí)行
mongoDB 不支持事務(wù)
7、數(shù)據(jù)分析
mongoDB 內(nèi)置了數(shù)據(jù)分析的功能(mapreduce),其他不支持
8、應(yīng)用場景
redis:數(shù)據(jù)量較小的更性能操作和運(yùn)算上
memcache:用于在動(dòng)態(tài)系統(tǒng)中減少數(shù)據(jù)庫負(fù)載,提升性能;做緩存,提高性能(適合讀多寫
少,對(duì)于數(shù)據(jù)量比較大,可以采用 sharding)
MongoDB:主要解決海量數(shù)據(jù)的訪問效率問題。
表格比較:
memcache redis 類型 內(nèi)存數(shù)據(jù)庫 內(nèi)存數(shù)據(jù)庫
數(shù)據(jù)類型 在定義 value 時(shí)就要固定數(shù)據(jù)類型 不需要
有字符串,鏈表,集 合和有序集合
虛擬內(nèi)存 不支持 支持
過期策略 支持 支持
分布式 magent master-slave,一主一從或一主多從
存儲(chǔ)數(shù)據(jù)安全 不支持 使用 save 存儲(chǔ)到 dump.rdb 中
災(zāi)難恢復(fù) 不支持 append only file(aof)用于數(shù)據(jù)恢復(fù)
性能
1、類型——memcache 和 redis 都是將數(shù)據(jù)存放在內(nèi)存,所以是內(nèi)存數(shù)據(jù)庫。當(dāng)然,memcache 也可用于緩存其他東西,例如圖片等等。
2、 數(shù)據(jù)類型——Memcache 在添加數(shù)據(jù)時(shí)就要指定數(shù)據(jù)的字節(jié)長度,而 redis 不需要。
3、 虛擬內(nèi)存——當(dāng)物理內(nèi)存用完時(shí),可以將一些很久沒用到的 value 交換到磁盤。
4、 過期策略——memcache 在 set 時(shí)就指定,例如 set key1 0 0 8,即永不過期。Redis 可以通
過例如 expire 設(shè)定,例如 expire name 10。
5、 分布式——設(shè)定 memcache 集群,利用 magent 做一主多從;redis 可以做一主多從。都可
以一主一從。
6、 存儲(chǔ)數(shù)據(jù)安全——memcache 斷電就斷了,數(shù)據(jù)沒了;redis 可以定期 save 到磁盤。
7、 災(zāi)難恢復(fù)——memcache 同上,redis 丟了后可以通過 aof 恢復(fù)。
Memecache 端口 11211
yum -y install memcached
yum -y install php-pecl-memcache
/etc/init.d/memcached start memcached -d -p 11211 -u memcached -m 64 -c 1024 -P /var/run/memcached/memcached.pid
-d 啟動(dòng)一個(gè)守護(hù)進(jìn)程
-p 端口
-m 分配的內(nèi)存是 M
-c 最大運(yùn)行并發(fā)數(shù)-P memcache 的 pid
//0 壓縮(是否 MEMCACHE_COMPRESSED) 30 秒失效時(shí)間
//delete 5 是 timeout
2. 什么是NoSQL?
2.1 NoSQL 概述
NoSQL(NoSQL = Not Only SQL ),意即“不僅僅是SQL”,
泛指非關(guān)系型的數(shù)據(jù)庫。隨著互聯(lián)網(wǎng)web2.0網(wǎng)站的興起,傳統(tǒng)的關(guān)系數(shù)據(jù)庫在應(yīng)付web2.0網(wǎng)站,特別是超大規(guī)模和高并發(fā)的SNS類型的web2.0純動(dòng)態(tài)網(wǎng)站已經(jīng)顯得力不從心,暴露了很多難以克服的問題,而非關(guān)系型的數(shù)據(jù)庫則由于其本身的特點(diǎn)得到了非常迅速的發(fā)展。NoSQL數(shù)據(jù)庫的產(chǎn)生就是為了解決大規(guī)模數(shù)據(jù)集合多重?cái)?shù)據(jù)種類帶來的挑戰(zhàn),尤其是大數(shù)據(jù)應(yīng)用難題,包括超大規(guī)模數(shù)據(jù)的存儲(chǔ)。
(例如谷歌或Facebook每天為他們的用戶收集萬億比特的數(shù)據(jù))。這些類型的數(shù)據(jù)存儲(chǔ)不需要固定的模式,無需多余操作就可以橫向擴(kuò)展。
2.2 NoSQL代表
MongDB、 Redis、Memcache
3. 關(guān)系型數(shù)據(jù)庫與NoSQL的區(qū)別?
3.1 RDBMS
高度組織化結(jié)構(gòu)化數(shù)據(jù)
結(jié)構(gòu)化查詢語言(SQL)
數(shù)據(jù)和關(guān)系都存儲(chǔ)在單獨(dú)的表中。
數(shù)據(jù)操縱語言,數(shù)據(jù)定義語言
嚴(yán)格的一致性
基礎(chǔ)事務(wù)
ACID
關(guān)系型數(shù)據(jù)庫遵循ACID規(guī)則
事務(wù)在英文中是transaction,和現(xiàn)實(shí)世界中的交易很類似,它有如下四個(gè)特性:
A (Atomicity) 原子性
原子性很容易理解,也就是說事務(wù)里的所有操作要么全部做完,要么都不做,事務(wù)成功的條件是事務(wù)里的所有操作都成功,只要有一個(gè)操作失敗,整個(gè)事務(wù)就失敗,需要回滾。比如銀行轉(zhuǎn)賬,從A賬戶轉(zhuǎn)100元至B賬戶,分為兩個(gè)步驟:1)從A賬戶取100元;2)存入100元至B賬戶。這兩步要么一起完成,要么一起不完成,如果只完成第一步,第二步失敗,錢會(huì)莫名其妙少了100元。
C (Consistency) 一致性
一致性也比較容易理解,也就是說數(shù)據(jù)庫要一直處于一致的狀態(tài),事務(wù)的運(yùn)行不會(huì)改變數(shù)據(jù)庫原本的一致性約束。
I (Isolation) 獨(dú)立性
所謂的獨(dú)立性是指并發(fā)的事務(wù)之間不會(huì)互相影響,如果一個(gè)事務(wù)要訪問的數(shù)據(jù)正在被另外一個(gè)事務(wù)修改,只要另外一個(gè)事務(wù)未提交,它所訪問的數(shù)據(jù)就不受未提交事務(wù)的影響。比如現(xiàn)有有個(gè)交易是從A賬戶轉(zhuǎn)100元至B賬戶,在這個(gè)交易還未完成的情況下,如果此時(shí)B查詢自己的賬戶,是看不到新增加的100元的
D (Durability) 持久性
持久性是指一旦事務(wù)提交后,它所做的修改將會(huì)永久的保存在數(shù)據(jù)庫上,即使出現(xiàn)宕機(jī)也不會(huì)丟失。
3.2 NoSQL
代表著不僅僅是SQL
沒有聲明性查詢語言
沒有預(yù)定義的模式
鍵 - 值對(duì)存儲(chǔ),列存儲(chǔ),文檔存儲(chǔ),圖形數(shù)據(jù)庫
最終一致性,而非ACID屬性
非結(jié)構(gòu)化和不可預(yù)知的數(shù)據(jù)
CAP定理
高性能,高可用性和可伸縮性
分布式數(shù)據(jù)庫中的CAP原理(了解)
CAP定理:
Consistency(一致性), 數(shù)據(jù)一致更新,所有數(shù)據(jù)變動(dòng)都是同步的
Availability(可用性), 好的響應(yīng)性能
Partition tolerance(分區(qū)容錯(cuò)性) 可靠性
P: 系統(tǒng)中任意信息的丟失或失敗不會(huì)影響系統(tǒng)的繼續(xù)運(yùn)作。
定理:任何分布式系統(tǒng)只可同時(shí)滿足二點(diǎn),沒法三者兼顧。
CAP理論的核心是:一個(gè)分布式系統(tǒng)不可能同時(shí)很好的滿足一致性,可用性和分區(qū)容錯(cuò)性這三個(gè)需求,
因此,根據(jù) CAP 原理將 NoSQL 數(shù)據(jù)庫分成了滿足 CA 原則、滿足 CP 原則和滿足 AP 原則三 大類:
CA - 單點(diǎn)集群,滿足一致性,可用性的系統(tǒng),通常在可擴(kuò)展性上不太強(qiáng)大。
CP - 滿足一致性,分區(qū)容忍性的系統(tǒng),通常性能不是特別高。
AP - 滿足可用性,分區(qū)容忍性的系統(tǒng),通常可能對(duì)一致性要求低一些。
CAP理論就是說在分布式存儲(chǔ)系統(tǒng)中,最多只能實(shí)現(xiàn)上面的兩點(diǎn)。
而由于當(dāng)前的網(wǎng)絡(luò)硬件肯定會(huì)出現(xiàn)延遲丟包等問題,所以分區(qū)容忍性是我們必須需要實(shí)現(xiàn)的。
所以我們只能在一致性和可用性之間進(jìn)行權(quán)衡,沒有NoSQL系統(tǒng)能同時(shí)保證這三點(diǎn)。
說明:C:強(qiáng)一致性 A:高可用性 P:分布式容忍性
舉例:
CA:傳統(tǒng)Oracle數(shù)據(jù)庫
AP:大多數(shù)網(wǎng)站架構(gòu)的選擇
CP:Redis、Mongodb
注意:分布式架構(gòu)的時(shí)候必須做出取舍。
一致性和可用性之間取一個(gè)平衡。多余大多數(shù)web應(yīng)用,其實(shí)并不需要強(qiáng)一致性。
因此犧牲C換取P,這是目前分布式數(shù)據(jù)庫產(chǎn)品的方向。
4. 當(dāng)下NoSQL的經(jīng)典應(yīng)用
當(dāng)下的應(yīng)用是 SQL 與 NoSQL 一起使用的。
代表項(xiàng)目:阿里巴巴商品信息的存放。
去 IOE 化。
ps:I 是指 IBM 的小型機(jī),很貴的,好像好幾萬一臺(tái);O 是指 Oracle 數(shù)據(jù)庫,也很貴的,好幾萬呢;M 是指 EMC 的存儲(chǔ)設(shè)備,也很貴的。
難點(diǎn):
數(shù)據(jù)類型多樣性。
數(shù)據(jù)源多樣性和變化重構(gòu)。
數(shù)據(jù)源改造而服務(wù)平臺(tái)不需要大面積重構(gòu)。
nosql是not only sql的意思。是近今年新發(fā)展起來的存儲(chǔ)系統(tǒng)。當(dāng)前使用最多的是key-value模型,用于處理超大規(guī)模的數(shù)據(jù)。
以下是摘自百度百科中的一部分
NoSQL 是非關(guān)系型數(shù)據(jù)存儲(chǔ)的廣義定義。它打破了長久以來關(guān)系型數(shù)據(jù)庫與ACID理論大一統(tǒng)的局面。NoSQL 數(shù)據(jù)存儲(chǔ)不需要固定的表結(jié)構(gòu),通常也不存在連接操作。在大數(shù)據(jù)存取上具備關(guān)系型數(shù)據(jù)庫無法比擬的性能優(yōu)勢(shì)。該術(shù)語在 2009 年初得到了廣泛認(rèn)同。
當(dāng)今的應(yīng)用體系結(jié)構(gòu)需要數(shù)據(jù)存儲(chǔ)在橫向伸縮性上能夠滿足需求。而 NoSQL 存儲(chǔ)就是為了實(shí)現(xiàn)這個(gè)需求。Google 的BigTable與Amazon的Dynamo是非常成功的商業(yè) NoSQL 實(shí)現(xiàn)。一些開源的 NoSQL 體系,如Facebook 的Cassandra, Apache 的HBase,也得到了廣泛認(rèn)同。從這些NoSQL項(xiàng)目的名字上看不出什么相同之處:Hadoop、Voldemort、Dynomite,還有其它很多。
NoSQL與關(guān)系型數(shù)據(jù)庫設(shè)計(jì)理念比較
關(guān)系型數(shù)據(jù)庫中的表都是存儲(chǔ)一些格式化的數(shù)據(jù)結(jié)構(gòu),每個(gè)元組字段的組成都一樣,即使不是每個(gè)元組都需要所有的字段,但數(shù)據(jù)庫會(huì)為每個(gè)元組分配所有的字段,這樣的結(jié)構(gòu)可以便于表與表之間進(jìn)行連接等操作,但從另一個(gè)角度來說它也是關(guān)系型數(shù)據(jù)庫性能瓶頸的一個(gè)因素。而非關(guān)系型數(shù)據(jù)庫以鍵值對(duì)存儲(chǔ),它的結(jié)構(gòu)不固定,每一個(gè)元組可以有不一樣的字段,每個(gè)元組可以根據(jù)需要增加一些自己的鍵值對(duì),這樣就不會(huì)局限于固定的結(jié)構(gòu),可以減少一些時(shí)間和空間的開銷。