一文深入講解redis和couchbase的區(qū)別
1 Redis數(shù)據(jù)庫完全在內(nèi)存中，因此處理速度非常快，每秒能執(zhí)行約11萬集合，每秒約81000+條記錄；
2 Redis的數(shù)據(jù)能確保一致性——所有Redis操作是原子性（Atomicity，意味著操作的不可再分，要么執(zhí)行要么不執(zhí)行）的，這保證了如果兩個客戶端同時訪問的Redis服務器將獲得更新后的值。
3 通過定時快照（snapshot）和基于語句的追加（AppendOnlyFile，aof）兩種方式，redis可以支持數(shù)據(jù)持久化——將內(nèi)存中的數(shù)據(jù)存儲到磁盤上，方便在宕機等突發(fā)情況下快速恢復。
優(yōu)點：
1. 非常豐富的數(shù)據(jù)結構；
2. Redis提供了事務的功能，可以保證一串 命令的原子性，中間不會被任何操作打斷；
3. 數(shù)據(jù)存在內(nèi)存中，讀寫非常的高速，可以達到10w/s的頻率。
缺點：
1. Redis3.0后才出來官方的集群方案，但仍存在一些架構上的問題（出處）；
2. 持久化功能體驗不佳——通過快照方法實現(xiàn)的話，需要每隔一段時間將整個數(shù)據(jù)庫的數(shù)據(jù)寫到磁盤上，代價非常高；而aof方法只追蹤變化的數(shù)據(jù)，類似于mysql的binlog方法，但追加log可能過大，同時所有操作均要重新執(zhí)行一遍，恢復速度慢；
3. 由于是內(nèi)存數(shù)據(jù)庫，所以，單臺機器，存儲的數(shù)據(jù)量，跟機器本身的內(nèi)存大小。雖然redis本身有key過期策略，但是還是需要提前預估和節(jié)約內(nèi)存。如果內(nèi)存增長過快，需要定期刪除數(shù)據(jù)。
適用場景：
適用于數(shù)據(jù)變化快且數(shù)據(jù)庫大小可遇見（適合內(nèi)存容量）的應用程序。
二、couchbase
Couchbase Server 是個面向文檔的數(shù)據(jù)庫（其所用的技術來自于Apache CouchDB項目），能夠實現(xiàn)水平伸縮，并且對于數(shù)據(jù)的讀寫來說都能提供低延遲的訪問（這要歸功于Membase技術）。
1.特點
1.1 數(shù)據(jù)格式
Couchbase 跟 MongoDB 一樣都是面向文檔的數(shù)據(jù)庫，不過在往 Couchbase 插入數(shù)據(jù)前，需要先建立 bucket —— 可以把它理解為“庫”或“表”。
因為 Couchbase 數(shù)據(jù)基于 Bucket 而導致缺乏表結構的邏輯，故如果需要查詢數(shù)據(jù)，得先建立 view（跟RDBMS的視圖不同，view是將數(shù)據(jù)轉換為特定格式結構的數(shù)據(jù)形式如JSON）來執(zhí)行。
Bucket的意義 —— 在于將數(shù)據(jù)進行分隔，比如：任何 view 就是基于一個 Bucket 的，僅對 Bucket 內(nèi)的數(shù)據(jù)進行處理。一個server上可以有多個Bucket，每個Bucket的存儲類型、內(nèi)容占用、數(shù)據(jù)復制數(shù)量等，都需要分別指定。從這個意義上看，每個Bucket都相當于一個獨立的實例。在集群狀態(tài)下，我們需要對server進行集群設置，Bucket只側重數(shù)據(jù)的保管。
每當views建立時， 就會建立indexes， index的更新和以往的數(shù)據(jù)庫索引更新區(qū)別很大。比如現(xiàn)在有1W數(shù)據(jù)，更新了200條，索引只需要更新200條，而不需要更新所有數(shù)據(jù)，map/reduce功能基于index的懶更新行為，大大得益。
要留意的是，對于所有文件，couchbase 都會建立一個額外的 56byte 的 metadata，這個 metadata 功能之一就是表明數(shù)據(jù)狀態(tài)，是否活動在內(nèi)存中。同時文件的 key 也作為標識符和 metadata 一起長期活動在內(nèi)存中。
1.2 性能
couchbase 的精髓就在于依賴內(nèi)存最大化降低硬盤I/O對吞吐量的負面影響，所以其讀寫速度非常快，可以達到亞毫秒級的響應。
couchbase在對數(shù)據(jù)進行增刪時會先體現(xiàn)在內(nèi)存中，而不會立刻體現(xiàn)在硬盤上，從內(nèi)存的修改到硬盤的修改這一步驟是由 couchbase 自動完成，等待執(zhí)行的硬盤操作會以write queue的形式排隊等待執(zhí)行，也正是通過這個方法，硬盤的I/O效率在 write queue 滿之前是不會影響 couchbase 的吞吐效率的。
鑒于內(nèi)存資源肯定遠遠少于硬盤資源，所以如果數(shù)據(jù)量小，那么全部數(shù)據(jù)都放在內(nèi)存上自然是最優(yōu)選擇，這時候couchbase的效率也是異常高。
但是數(shù)據(jù)量大的時候過多的數(shù)據(jù)就會被放在硬盤之中。當然，最終所有數(shù)據(jù)都會寫入硬盤，不過有些頻繁使用的數(shù)據(jù)提前放在內(nèi)存中自然會提高效率。
1.3 持久化
其前身之一 memcached 是完全不支持持久化的，而 Couchbase 添加了對異步持久化的支持：
Couchbase提供兩種核心類型的buckets —— Couchbase 類型和 Memcached 類型。其中 Couchbase 類型提供了高可用和動態(tài)重配置的分布式數(shù)據(jù)存儲，提供持久化存儲和復制服務。
Couchbase bucket 具有持久性 —— 數(shù)據(jù)單元異步從內(nèi)存寫往磁盤，防范服務重啟或較小的故障發(fā)生時數(shù)據(jù)丟失。持久性屬性是在 bucket 級設置的。
Couchbase 群集所有點都是對等的，只是在創(chuàng)建群或者加入集群時需要指定一個主節(jié)點，一旦結點成功加入集群，所有的結點對等。
對等網(wǎng)的優(yōu)點是，集群中的任何節(jié)點失效，集群對外提供服務完全不會中斷，只是集群的容量受影響。
由于 couchbase 是對等網(wǎng)集群，所有的節(jié)點都可以同時對客戶端提供服務，這就需要有方法把集群的節(jié)點信息暴露給客戶端，couchbase 提供了一套機制，客戶端可以獲取所有節(jié)點的狀態(tài)以及節(jié)點的變動，由客戶端根據(jù)集群的當前狀態(tài)計算 key 所在的位置。
文章發(fā)布平臺：微信公眾號【碼農(nóng)編程進階筆記】
3. 優(yōu)缺點
優(yōu)勢
1. 高并發(fā)性，高靈活性，高拓展性，容錯性好；
2. 以 vBucket 的概念實現(xiàn)更理想化的自動分片以及動態(tài)擴容（了解更多）；
缺點
1. Couchbase 的存儲方式為 Key/Value，但 Value 的類型很為單一，不支持數(shù)組。另外也不會自動創(chuàng)建doc id，需要為每一文檔指定一個用于存儲的 Document Indentifer；
2. 各種組件拼接而成，都是c++實現(xiàn)，導致復雜度過高，遇到奇怪的性能問題排查比較困難，（中文）文檔比較欠缺；
3. 采用緩存全部key的策略，需要大量內(nèi)存。節(jié)點宕機時 failover 過程有不可用時間，并且有部分數(shù)據(jù)丟失的可能，在高負載系統(tǒng)上有假死現(xiàn)象；
4. 逐漸傾向于閉源，社區(qū)版本（免費，但不提供官方維護升級）和商業(yè)版本之間差距比較大。
適用場景
1. 適合對讀寫速度要求較高，但服務器負荷和內(nèi)存花銷可遇見的需求；
2. 需要支持 memcached 協(xié)議的需求。