Redis、Memcache和MongoDB的區別 （資源）

Redis、Memcache和MongoDB的區別

Memcached

Memcached的優勢：
Memcached能夠利用多核優點，單實例吞吐量極高，能夠達到幾十萬QPS（取決於key、value的字節大小以及服務器硬件性能，平常環境中QPS高峯大約在4-6w左右）。適用於最大程度扛量。持直接配置爲session handle。
支持直接配置爲session handle。

更高的寫負載，MongoDB擁有更高的插入速度。

高可用性，設置M-S不只方便並且很快，MongoDB還能夠快速、安全及自動化的實現節點(數據中心)故障轉移。

快速的查詢，MongoDB支持二維空間索引，好比管道，所以能夠快速及精確的從指定位置獲取數據。MongoDB在啓動後會將數據庫中的數據以文件映射的方式加載到內存中。若是內存資源至關豐富的話，這將極大地提升數據庫的查詢速度。

Memcached的侷限性：
一、只支持簡單的key/value數據結構，不像Redis能夠支持豐富的數據類型。
沒法進行持久化，數據不能備份，只能用於緩存使用，且重啓後數據所有丟失。
沒法進行數據同步，不能將MC中的數據遷移到其餘MC實例中。
Memcached內存分配採用Slab Allocation機制管理內存，value大小分佈差別較大時會形成內存利用率下降，並引起低利用率時依然出現踢出等問題。須要用戶注重value設計。

二、不支持事務。MongoDB佔用空間過大 。

三、MongoDB沒有成熟的維護工具。

Redis

Redis的優勢：
支持多種數據結構，如 string（字符串）、 list(雙向鏈表)、dict(hash表)、set(集合）、zset(排序set)、hyperloglog（基數估算）
支持持久化操做，能夠進行aof及rdb數據持久化到磁盤，從而進行數據備份或數據恢復等操做，較好的防止數據丟失的手段。
支持經過Replication進行數據複製，經過master-slave機制，能夠實時進行數據的同步複製，支持多級複製和增量複製，master-slave機制是Redis進行HA的重要手段。
單線程請求，全部命令串行執行，併發狀況下不須要考慮數據一致性問題。
支持pub/sub消息訂閱機制，能夠用來進行消息訂閱與通知。
支持簡單的事務需求，但業界使用場景不多，並不成熟。

Redis的侷限性：
Redis只能使用單線程，性能受限於CPU性能，故單實例CPU最高才可能達到5-6wQPS每秒（取決於數據結構，數據大小以及服務器硬件性能，平常環境中QPS高峯大約在1-2w左右）。
支持簡單的事務需求，但業界使用場景不多，並不成熟，既是優勢也是缺點。
Redis在string類型上會消耗較多內存，可使用dict（hash表）壓縮存儲以下降內存耗用。

Mc和Redis都是Key-Value類型，不適合在不一樣數據集之間創建關係，也不適合進行查詢搜索。好比redis的keys pattern這種匹配操做，對redis的性能是災難。

mongoDB 

mongoDB 是一種文檔性的數據庫。先解釋一下文檔的數據庫，便可以存放xml、json、bson類型系那個的數據。

這些數據具有自述性（self-describing），呈現分層的樹狀數據結構。redis能夠用hash存放簡單關係型數據。

mongoDB 存放json格式數據。

適合場景：事件記錄、內容管理或者博客平臺，好比評論系統。

1.mongodb持久化原理

     mongodb與mysql不一樣，mysql的每一次更新操做都會直接寫入硬盤，可是mongo不會，作爲內存型數據庫，數據操做會先寫入內存，而後再會持久化到硬盤中去，那麼mongo是如何持久化的呢
    mongodb在啓動時，專門初始化一個線程不斷循環（除非應用crash掉），用於在必定時間週期內來從defer隊列中獲取要持久化的數據並寫入到磁盤的journal(日誌)和mongofile(數據)處，固然由於它不是在用戶添加記錄時就寫到磁盤上，因此按mongodb開發者說，它不會形成性能上的損耗，由於看過代碼發現，當進行CUD操做時，記錄(Record類型)都被放入到defer隊列中以供延時批量（groupcommit）提交寫入，但相信其中時間週期參數是個要認真考量的參數，系統爲90毫秒，若是該值更低的話，可能會形成頻繁磁盤操做，太高又會形成系統宕機時數據丟失過。

2.什麼是NoSQL數據庫？NoSQL和RDBMS有什麼區別？在哪些狀況下使用和不使用NoSQL數據庫？
NoSQL是非關係型數據庫，NoSQL = Not Only SQL。
關係型數據庫採用的結構化的數據，NoSQL採用的是鍵值對的方式存儲數據。
在處理非結構化/半結構化的大數據時；在水平方向上進行擴展時；隨時應對動態增長的數據項時能夠優先考慮使用NoSQL數據庫。
在考慮數據庫的成熟度；支持；分析和商業智能；管理及專業性等問題時，應優先考慮關係型數據庫。

3.MySQL和MongoDB之間最基本的區別是什麼？
關係型數據庫與非關係型數據庫的區別，即數據存儲結構的不一樣。

4.MongoDB的特色是什麼？
（1）面向文檔（2）高性能（3）高可用（4）易擴展（5）豐富的查詢語言

5.MongoDB支持存儲過程嗎？若是支持的話，怎麼用？
MongoDB支持存儲過程，它是javascript寫的，保存在db.system.js表中。

6.如何理解MongoDB中的GridFS機制，MongoDB爲什麼使用GridFS來存儲文件？
GridFS是一種將大型文件存儲在MongoDB中的文件規範。使用GridFS能夠將大文件分隔成多個小文檔存放，這樣咱們可以有效的保存大文檔，並且解決了BSON對象有限制的問題。

7.爲何MongoDB的數據文件很大？
MongoDB採用的預分配空間的方式來防止文件碎片。

8.當更新一個正在被遷移的塊（Chunk）上的文檔時會發生什麼？
更新操做會當即發生在舊的塊（Chunk）上，而後更改纔會在全部權轉移前複製到新的分片上。

9.MongoDB在A:{B,C}上創建索引，查詢A:{B,C}和A:{C,B}都會使用索引嗎？
不會，只會在A:{B,C}上使用索引。

10.若是一個分片（Shard）中止或很慢的時候，發起一個查詢會怎樣？
若是一個分片中止了，除非查詢設置了「Partial」選項，不然查詢會返回一個錯誤。若是一個分片響應很慢，MongoDB會等待它的響應。

 

1.性能

三者的性能都比較高，總的來說：Memcache和Redis差很少，要高於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.數據一致性（事務支持）

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

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

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

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

Memcache 在併發場景下，用cas保證一致性。
redis事務支持比較弱，只能保證事務中的每一個操做連續執行。
mongoDB不支持事務。

7.數據分析

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

8.應用場景

redis：數據量較小的更性能操做和運算上。
memcache：用於在動態系統中減小數據庫負載，提高性能;作緩存，提升性能（適合讀多寫少，對於數據量比較大，能夠採用sharding）。
MongoDB:主要解決海量數據的訪問效率問題。

 

熱數據緩存  Redis OR Memcached 

Redis相對memcached的優點在哪裏

     Redis相對於Memcached不只僅支持簡單的k/v類型的數據，同時還提供list，set，hash等數據結構的存儲。Redis相對於Memcached還支持數據的備份， Redis相對於Memcached新增支持數據的持久化，能夠將內存中的數據保持在磁盤中，重啓的時候能夠再次加載進行使用。從redis 的官方文檔可知其實Redis中，並非全部的數據都一直存儲在內存中的，而Memcached倒是，同時Redis只會緩存全部的 key的信息，Redis實際上是能夠存在可能保存超過其機器自己內存大小的數據，而memcached並不能實現。

memcached和redis的區別

存儲方式

　　Memcached基本只支持簡單的key-value存儲，不支持枚舉，不支持持久化和複製等功能

　　Redis除key/value以外，還支持list,set,sorted set,hash等衆多數據結構，

    memecache 把數據所有存在內存之中，斷電後會掛掉，數據不能超過內存大小

    redis有部份存在硬盤上，這樣能保證數據的持久性，支持數據的持久化。

數據支持類型：

    redis在數據支持上要比memecache多的多。

使用底層模型不一樣：

    新版本的redis直接本身構建了VM 機制 ，由於通常的系統調用系統函數的話，會浪費必定的時間去移動和請求。

事物

        Memcached中除increment/decrement這樣的原子操做命令，不存在對事務的支持。而redis基本全部的命令均可以支持事務的概念

IO

　　Memcached是多線程，非阻塞IO複用的網絡模型，分爲監聽主線程和worker子線程。

　　Redis使用單線程的IO複用模型，本身封裝了一個簡單的AeEvent事件處理框架。

容災

        memcache掛掉後，數據不可恢復; redis數據丟失後能夠經過aof恢復

過時策虐

        memcache經過set指定 而redis 經過expire 關鍵字設定

內存

　　Memcached使用預分配的內存池的方式,Redis使用現場申請內存的方式來存儲數據

數據一致性

　　Memcached提供了cas命令，能夠保證多個併發訪問操做同一份數據的一致性問題。         Redis沒有提供cas 命令，並不能保證這點，不過Redis提供了事務的功能，能夠保證一串 命令的原子性，中間不會被任何操做打斷。

應用場景

     一般 Redis出來做爲NoSQL數據庫使用外，還能用作消息對象，數據堆棧和數據緩存等；Memcached適合於緩存SQL語句、數據集、用戶臨時性數據、延遲查詢數據和session等。

 

 

 

 

參考連接：https://mp.weixin.qq.com/s/kS02yHAM_Pn-T3XmqZIPDQ

 

https://mp.weixin.qq.com/s/DjMa98NCk6C48OVxMYDxBw

連接 : 

NoSQL 的選擇 -- Redis、MongoDB、Cassandra 與 HBase 的介紹與比較 :  http://techlog.cn/article/list/10182729#b

轉  高性能緩存Memcached使用教程    ：  https://blog.csdn.net/wtxwd/article/details/56841259

轉  Ehcache與Memcache的區別   ：  https://blog.csdn.net/wtxwd/article/details/56841220

Memcached實戰之單機部署----單實例/多實例          :     http://blog.51cto.com/nolinux/1543577

Memcached實戰之複製----基於repcached的主從      :        http://blog.51cto.com/nolinux/1544931

高效緩存服務器Memcached（一）     :           http://blog.51cto.com/cuchadanfan/1697978

高效緩存服務器Memcached（二）   :        http://blog.51cto.com/cuchadanfan/1697980

轉  高性能緩存Memcached使用教程         ：     https://blog.csdn.net/wtxwd/article/details/56841259

轉  Ehcache與Memcache的區別    ： https://blog.csdn.net/wtxwd/article/details/56841220

 

 

 

 

[root@localhost 01]#
[root@localhost 01]#
[root@localhost 01]#
[root@localhost 01]#
[root@localhost 01]#
[root@localhost 01]#
[root@localhost 01]#
[root@localhost 01]#
[root@localhost 01]#
[root@localhost 01]#
[root@localhost 0]#
[root@localhost 01]#
[root@localhost 01]#