redis、memcache、mongoDB 對比

 

一、性能
都比較高，性能對咱們來講應該都不是瓶頸
整體來說，TPS方面redis和memcache差很少，要大於mongodb


二、操做的便利性
memcache數據結構單一
redis豐富一些，數據操做方面，redis更好一些，較少的網絡IO次數
mongodb支持豐富的數據表達，索引，最相似關係型數據庫，支持的查詢語言很是豐富


三、內存空間的大小和數據量的大小
redis在2.0版本後增長了本身的VM特性，突破物理內存的限制；能夠對key value設置過時時間（相似memcache）
memcache能夠修改最大可用內存,採用LRU算法
mongoDB適合大數據量的存儲，依賴操做系統VM作內存管理，吃內存也比較厲害，服務不要和別的服務在一塊兒

四、可用性（單點問題）

對於單點問題，
redis，依賴客戶端來實現分佈式讀寫；主從複製時，每次從節點從新鏈接主節點都要依賴整個快照,無增量複製，因性能和效率問題，
因此單點問題比較複雜；不支持自動sharding,須要依賴程序設定一致hash 機制。
一種替代方案是，不用redis自己的複製機制，採用本身作主動複製（多份存儲），或者改爲增量複製的方式（須要本身實現），一致性問題和性能的權衡

Memcache自己沒有數據冗餘機制，也不必；對於故障預防，採用依賴成熟的hash或者環狀的算法，解決單點故障引發的抖動問題。

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


五、可靠性（持久化）

對於數據持久化和數據恢復，

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

memcache不支持，一般用在作緩存,提高性能；

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


六、數據一致性（事務支持）

Memcache 在併發場景下，用cas保證一致性

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

mongoDB不支持事務


七、數據分析

mongoDB內置了數據分析的功能(mapreduce),其餘不支持


八、應用場景
redis：數據量較小的更性能操做和運算上

memcache：用於在動態系統中減小數據庫負載，提高性能;作緩存，提升性能（適合讀多寫少，對於數據量比較大，能夠採用sharding）

MongoDB:主要解決海量數據的訪問效率問題