一文深入講解redis和couchbase的區(qū)別

一、Redis

1 Redis數(shù)據(jù)庫(kù)完全在內(nèi)存中，因此處理速度非常快，每秒能執(zhí)行約11萬(wàn)集合，每秒約81000+條記錄；

2 Redis的數(shù)據(jù)能確保一致性——所有Redis操作是原子性（Atomicity，意味著操作的不可再分，要么執(zhí)行要么不執(zhí)行）的，這保證了如果兩個(gè)客戶端同時(shí)訪問(wèn)的Redis服務(wù)器將獲得更新后的值。

3 通過(guò)定時(shí)快照（snapshot）和基于語(yǔ)句的追加（AppendOnlyFile，aof）兩種方式，redis可以支持?jǐn)?shù)據(jù)持久化——將內(nèi)存中的數(shù)據(jù)存儲(chǔ)到磁盤上，方便在宕機(jī)等突發(fā)情況下快速恢復(fù)。

優(yōu)點(diǎn)：

1. 非常豐富的數(shù)據(jù)結(jié)構(gòu)；

2. Redis提供了事務(wù)的功能，可以保證一串 命令的原子性，中間不會(huì)被任何操作打斷；

3. 數(shù)據(jù)存在內(nèi)存中，讀寫非常的高速，可以達(dá)到10w/s的頻率。

缺點(diǎn)：

1. Redis3.0后才出來(lái)官方的集群方案，但仍存在一些架構(gòu)上的問(wèn)題（出處）；

2. 持久化功能體驗(yàn)不佳——通過(guò)快照方法實(shí)現(xiàn)的話，需要每隔一段時(shí)間將整個(gè)數(shù)據(jù)庫(kù)的數(shù)據(jù)寫到磁盤上，代價(jià)非常高；而aof方法只追蹤變化的數(shù)據(jù)，類似于mysql的binlog方法，但追加log可能過(guò)大，同時(shí)所有操作均要重新執(zhí)行一遍，恢復(fù)速度慢；

3. 由于是內(nèi)存數(shù)據(jù)庫(kù)，所以，單臺(tái)機(jī)器，存儲(chǔ)的數(shù)據(jù)量，跟機(jī)器本身的內(nèi)存大小。雖然redis本身有key過(guò)期策略，但是還是需要提前預(yù)估和節(jié)約內(nèi)存。如果內(nèi)存增長(zhǎng)過(guò)快，需要定期刪除數(shù)據(jù)。

適用場(chǎng)景：

適用于數(shù)據(jù)變化快且數(shù)據(jù)庫(kù)大小可遇見（適合內(nèi)存容量）的應(yīng)用程序。

二、couchbase

Couchbase Server 是個(gè)面向文檔的數(shù)據(jù)庫(kù)（其所用的技術(shù)來(lái)自于Apache CouchDB項(xiàng)目），能夠?qū)崿F(xiàn)水平伸縮，并且對(duì)于數(shù)據(jù)的讀寫來(lái)說(shuō)都能提供低延遲的訪問(wèn)（這要?dú)w功于Membase技術(shù)）。

1.特點(diǎn)

1.1 數(shù)據(jù)格式

Couchbase 跟 MongoDB 一樣都是面向文檔的數(shù)據(jù)庫(kù)，不過(guò)在往 Couchbase 插入數(shù)據(jù)前，需要先建立 bucket —— 可以把它理解為“庫(kù)”或“表”。

因?yàn)?Couchbase 數(shù)據(jù)基于 Bucket 而導(dǎo)致缺乏表結(jié)構(gòu)的邏輯，故如果需要查詢數(shù)據(jù)，得先建立 view（跟RDBMS的視圖不同，view是將數(shù)據(jù)轉(zhuǎn)換為特定格式結(jié)構(gòu)的數(shù)據(jù)形式如JSON）來(lái)執(zhí)行。

Bucket的意義 —— 在于將數(shù)據(jù)進(jìn)行分隔，比如：任何 view 就是基于一個(gè) Bucket 的，僅對(duì) Bucket 內(nèi)的數(shù)據(jù)進(jìn)行處理。一個(gè)server上可以有多個(gè)Bucket，每個(gè)Bucket的存儲(chǔ)類型、內(nèi)容占用、數(shù)據(jù)復(fù)制數(shù)量等，都需要分別指定。從這個(gè)意義上看，每個(gè)Bucket都相當(dāng)于一個(gè)獨(dú)立的實(shí)例。在集群狀態(tài)下，我們需要對(duì)server進(jìn)行集群設(shè)置，Bucket只側(cè)重?cái)?shù)據(jù)的保管。

每當(dāng)views建立時(shí)， 就會(huì)建立indexes， index的更新和以往的數(shù)據(jù)庫(kù)索引更新區(qū)別很大。比如現(xiàn)在有1W數(shù)據(jù)，更新了200條，索引只需要更新200條，而不需要更新所有數(shù)據(jù)，map/reduce功能基于index的懶更新行為，大大得益。

要留意的是，對(duì)于所有文件，couchbase 都會(huì)建立一個(gè)額外的 56byte 的 metadata，這個(gè) metadata 功能之一就是表明數(shù)據(jù)狀態(tài)，是否活動(dòng)在內(nèi)存中。同時(shí)文件的 key 也作為標(biāo)識(shí)符和 metadata 一起長(zhǎng)期活動(dòng)在內(nèi)存中。

1.2 性能

couchbase 的精髓就在于依賴內(nèi)存最大化降低硬盤I/O對(duì)吞吐量的負(fù)面影響，所以其讀寫速度非常快，可以達(dá)到亞毫秒級(jí)的響應(yīng)。

couchbase在對(duì)數(shù)據(jù)進(jìn)行增刪時(shí)會(huì)先體現(xiàn)在內(nèi)存中，而不會(huì)立刻體現(xiàn)在硬盤上，從內(nèi)存的修改到硬盤的修改這一步驟是由 couchbase 自動(dòng)完成，等待執(zhí)行的硬盤操作會(huì)以write queue的形式排隊(duì)等待執(zhí)行，也正是通過(guò)這個(gè)方法，硬盤的I/O效率在 write queue 滿之前是不會(huì)影響 couchbase 的吞吐效率的。

鑒于內(nèi)存資源肯定遠(yuǎn)遠(yuǎn)少于硬盤資源，所以如果數(shù)據(jù)量小，那么全部數(shù)據(jù)都放在內(nèi)存上自然是最優(yōu)選擇，這時(shí)候couchbase的效率也是異常高。

但是數(shù)據(jù)量大的時(shí)候過(guò)多的數(shù)據(jù)就會(huì)被放在硬盤之中。當(dāng)然，最終所有數(shù)據(jù)都會(huì)寫入硬盤，不過(guò)有些頻繁使用的數(shù)據(jù)提前放在內(nèi)存中自然會(huì)提高效率。

1.3 持久化

其前身之一 memcached 是完全不支持持久化的，而 Couchbase 添加了對(duì)異步持久化的支持：

Couchbase提供兩種核心類型的buckets —— Couchbase 類型和 Memcached 類型。其中 Couchbase 類型提供了高可用和動(dòng)態(tài)重配置的分布式數(shù)據(jù)存儲(chǔ)，提供持久化存儲(chǔ)和復(fù)制服務(wù)。

Couchbase bucket 具有持久性 —— 數(shù)據(jù)單元異步從內(nèi)存寫往磁盤，防范服務(wù)重啟或較小的故障發(fā)生時(shí)數(shù)據(jù)丟失。持久性屬性是在 bucket 級(jí)設(shè)置的。

Couchbase 群集所有點(diǎn)都是對(duì)等的，只是在創(chuàng)建群或者加入集群時(shí)需要指定一個(gè)主節(jié)點(diǎn)，一旦結(jié)點(diǎn)成功加入集群，所有的結(jié)點(diǎn)對(duì)等。

對(duì)等網(wǎng)的優(yōu)點(diǎn)是，集群中的任何節(jié)點(diǎn)失效，集群對(duì)外提供服務(wù)完全不會(huì)中斷，只是集群的容量受影響。

由于 couchbase 是對(duì)等網(wǎng)集群，所有的節(jié)點(diǎn)都可以同時(shí)對(duì)客戶端提供服務(wù)，這就需要有方法把集群的節(jié)點(diǎn)信息暴露給客戶端，couchbase 提供了一套機(jī)制，客戶端可以獲取所有節(jié)點(diǎn)的狀態(tài)以及節(jié)點(diǎn)的變動(dòng)，由客戶端根據(jù)集群的當(dāng)前狀態(tài)計(jì)算 key 所在的位置。

文章發(fā)布平臺(tái)：微信公眾號(hào)【碼農(nóng)編程進(jìn)階筆記】

3. 優(yōu)缺點(diǎn)

優(yōu)勢(shì)

1. 高并發(fā)性，高靈活性，高拓展性，容錯(cuò)性好；

2. 以 vBucket 的概念實(shí)現(xiàn)更理想化的自動(dòng)分片以及動(dòng)態(tài)擴(kuò)容（了解更多）；

缺點(diǎn)

1. Couchbase 的存儲(chǔ)方式為 Key/Value，但 Value 的類型很為單一，不支持?jǐn)?shù)組。另外也不會(huì)自動(dòng)創(chuàng)建doc id，需要為每一文檔指定一個(gè)用于存儲(chǔ)的 Document Indentifer；

2. 各種組件拼接而成，都是c++實(shí)現(xiàn)，導(dǎo)致復(fù)雜度過(guò)高，遇到奇怪的性能問(wèn)題排查比較困難，（中文）文檔比較欠缺；

3. 采用緩存全部key的策略，需要大量?jī)?nèi)存。節(jié)點(diǎn)宕機(jī)時(shí) failover 過(guò)程有不可用時(shí)間，并且有部分?jǐn)?shù)據(jù)丟失的可能，在高負(fù)載系統(tǒng)上有假死現(xiàn)象；

4. 逐漸傾向于閉源，社區(qū)版本（免費(fèi)，但不提供官方維護(hù)升級(jí)）和商業(yè)版本之間差距比較大。

適用場(chǎng)景

1. 適合對(duì)讀寫速度要求較高，但服務(wù)器負(fù)荷和內(nèi)存花銷可遇見的需求；

2. 需要支持 memcached 協(xié)議的需求。

Redis 數(shù)據(jù)庫(kù)

版權(quán)聲明：本文內(nèi)容由網(wǎng)絡(luò)用戶投稿，版權(quán)歸原作者所有，本站不擁有其著作權(quán)，亦不承擔(dān)相應(yīng)法律責(zé)任。如果您發(fā)現(xiàn)本站中有涉嫌抄襲或描述失實(shí)的內(nèi)容，請(qǐng)聯(lián)系我們jiasou666@gmail.com 處理，核實(shí)后本網(wǎng)站將在24小時(shí)內(nèi)刪除侵權(quán)內(nèi)容。