Mongodb與Redis應用指標對比
阿新 • • 發佈:2019-02-04
MongoDB和Redis都是NoSQL,採用結構型資料儲存。二者在使用場景中,存在一定的區別,這也主要由於
二者在記憶體對映的處理過程,持久化的處理方法不同。MongoDB建議叢集部署,更多的考慮到叢集方案,Redis
更偏重於程序順序寫入,雖然支援叢集,也僅限於主-從模式。
指標 | MongoDB(v2.4.9) | Redis(v2.4.17) | 比較說明 |
---|---|---|---|
實現語言 | C++ | C/C++ | - |
協議 | BSON、自定義二進位制 | 類Telnet | - |
效能 | 依賴記憶體,TPS較高 | 依賴記憶體,TPS非常高 | Redis優於MongoDB |
可操作性 | 豐富的資料表達、索引;最類似於關係資料庫,支援豐富的查詢語言 | 資料豐富,較少的IO | MongoDB優於Redis |
記憶體及儲存 | 適合大資料量儲存,依賴系統虛擬記憶體管理,採用映象檔案儲存;記憶體佔有率比較高,官方建議獨立部署在64位系統(32位有最大2.5G檔案限制,64位沒有改限制) | Redis2.0後增加虛擬記憶體特性,突破實體記憶體限制;資料可以設定時效性,類似於memcache | 不同的應用角度看,各有優勢 |
可用性 | 支援master-slave,replicaset(內部採用paxos選舉演算法,自動故障恢復),auto sharding機制,對客戶端遮蔽了故障轉移和切分機制 | 依賴客戶端來實現分散式讀寫;主從複製時,每次從節點重新連線主節點都要依賴整個快照,無增量複製;不支援自動sharding,需要依賴程式設定一致hash機制 | MongoDB優於Redis;單點問題上,MongoDB應用簡單,相對使用者透明,Redis比較複雜,需要客戶端主動解決。(MongoDB一般會使用replica sets和sharding功能結合,replica sets側重高可用性及高可靠性,而sharding側重於效能、易擴充套件) |
可靠性 | 從1.8版本後,採用binlog方式(MySQL同樣採用該方式)支援持久化,增加可靠性 | 依賴快照進行持久化;AOF增強可靠性;增強可靠性的同時,影響訪問效能 | MongoDB優於Redis |
一致性 | 不支援事物,靠客戶端自身保證 | 支援事物,比較弱,僅能保證事物中的操作按順序執行 | Redis優於MongoDB |
資料分析 | 內建資料分析功能(mapreduce) | 不支援 | MongoDB優於Redis |
應用場景 | 海量資料的訪問效率提升 | 較小資料量的效能及運算 | MongoDB優於Redis |