Redis,Memcache,mongoDB的區別

標籤：io   ar   os   on   資料   問題   log   時間   as   

從以下幾個維度，對redis、memcache、mongoDB 做了對比，歡迎拍磚

1、效能

都比較高，效能對我們來說應該都不是瓶頸

總體來講，TPS方面redis和memcache差不多，要大於mongodb

2、操作的便利性

memcache資料結構單一

redis豐富一些，資料操作方面，redis更好一些，較少的網路IO次數

mongodb支援豐富的資料表達，索引，最類似關係型資料庫，支援的查詢語言非常豐富

3、記憶體空間的大小和資料量的大小

redis在2.0版本後增加了自己的VM特性，突破實體記憶體的限制；可以對key value設定到期時間（類似memcache）

memcache可以修改最大可用記憶體,採用LRU演算法

mongoDB適合大資料量的儲存，依賴作業系統VM做記憶體管理，吃記憶體也比較厲害，服務不要和別的服務在一起

4、可用性（單點問題）

對於單點問題，

redis，依賴用戶端來實現分布式讀寫；主從複製時，每次從節點重新串連主節點都要依賴整個快照,無差異複寫，因效能和效率問題，

所以單點問題比較複雜；不支援自動sharding,需要依賴程式設定一致hash 機制。

一種替代方案是，不用redis本身的複製機制，採用自己做主動複製（多份儲存），或者改成差異複寫的方式（需要自己實現），一致性問題和效能的權衡

Memcache本身沒有資料冗餘機制，也沒必要；對於故障預防，採用依賴成熟的hash或者環狀的演算法，解決單點故障引起的抖動問題。

mongoDB支援master-slave,replicaset（內部採用paxos選舉演算法，自動故障恢複）,auto sharding機制，對用戶端屏蔽了容錯移轉和切分機制。

5、可靠性（持久化）

對於資料持久化和資料恢複，

redis支援（快照、AOF）：依賴快照進行持久化，aof增強了可靠性的同時，對效能有所影響

memcache不支援，通常用在做緩衝,提升效能；

MongoDB從1.8版本開始採用binlog方式支援持久化的可靠性

6、資料一致性（事務支援）

Memcache 在並發情境下，用cas保證一致性

redis事務支援比較弱，只能保證事務中的每個操作連續執行

mongoDB不支援事務

7、資料分析

mongoDB內建了資料分析的功能(mapreduce),其他不支援

8、應用情境

redis：資料量較小的更效能操作和運算上

memcache：用於在動態系統中減少資料庫負載，提升效能;做緩衝，提高效能（適合讀多寫少，對於資料量比較大，可以採用sharding）

MongoDB:主要解決海量資料的訪問效率問題

Redis,Memcache,mongoDB的區別