|
項目中用的是MongoDB，但是為什么用其實當時選型的時候也沒有太多考慮，只是認為數(shù)據(jù)量比較大，所以采用MongoDB。
最近又想起為什么用MongoDB，就查閱一下，匯總匯總：
之前也用過redis，當時是用來存儲一些熱數(shù)據(jù)，量也不大，但是操作很頻繁?，F(xiàn)在項目中用的是MongoDB，目前是百萬級的數(shù)據(jù)，將來會有千萬級、億級。
就Redis和MongoDB來說，大家一般稱之為Redis緩存、MongoDB數(shù)據(jù)庫。這也是有道有理有根據(jù)的，
Redis主要把數(shù)據(jù)存儲在內(nèi)存中，其“緩存”的性質(zhì)遠大于其“數(shù)據(jù)存儲“的性質(zhì)，其中數(shù)據(jù)的增刪改查也只是像變量操作一樣簡單；
MongoDB卻是一個“存儲數(shù)據(jù)”的系統(tǒng)，增刪改查可以添加很多條件，就像SQL數(shù)據(jù)庫一樣靈活，這一點在面試的時候很受用。
點擊查看：MongoDB語法與現(xiàn)有關(guān)系型數(shù)據(jù)庫SQL語法比較
Mongodb與Redis應(yīng)用指標對比
MongoDB和Redis都是NoSQL，采用結(jié)構(gòu)型數(shù)據(jù)存儲。二者在使用場景中，存在一定的區(qū)別，這也主要由于
二者在內(nèi)存映射的處理過程，持久化的處理方法不同。MongoDB建議集群部署，更多的考慮到集群方案，Redis
更偏重于進程順序?qū)懭?，雖然支持集群，也僅限于主-從模式。
| 指標 | MongoDB(v2.4.9) | Redis(v2.4.17) | 比較說明 |
|---|
| 實現(xiàn)語言 |
C++ |
C/C++ |
- |
| 協(xié)議 |
BSON、自定義二進制 |
類Telnet |
- |
| 性能 |
依賴內(nèi)存，TPS較高 |
依賴內(nèi)存，TPS非常高 |
Redis優(yōu)于MongoDB |
| 可操作性 |
豐富的數(shù)據(jù)表達、索引；最類似于關(guān)系數(shù)據(jù)庫，支持豐富的查詢語言 |
數(shù)據(jù)豐富，較少的IO |
MongoDB優(yōu)于Redis |
| 內(nèi)存及存儲 |
適合大數(shù)據(jù)量存儲，依賴系統(tǒng)虛擬內(nèi)存管理，采用鏡像文件存儲；內(nèi)存占有率比較高，官方建議獨立部署在64位系統(tǒng)（32位有最大2.5G文件限制，64位沒有改限制） |
Redis2.0后增加虛擬內(nèi)存特性，突破物理內(nèi)存限制；數(shù)據(jù)可以設(shè)置時效性，類似于memcache |
不同的應(yīng)用角度看，各有優(yōu)勢 |
| 可用性 |
支持master-slave,replicaset（內(nèi)部采用paxos選舉算法，自動故障恢復(fù)）,auto sharding機制，對客戶端屏蔽了故障轉(zhuǎn)移和切分機制 |
依賴客戶端來實現(xiàn)分布式讀寫；主從復(fù)制時，每次從節(jié)點重新連接主節(jié)點都要依賴整個快照,無增量復(fù)制；不支持自動sharding,需要依賴程序設(shè)定一致hash機制 |
MongoDB優(yōu)于Redis；單點問題上，MongoDB應(yīng)用簡單，相對用戶透明，Redis比較復(fù)雜，需要客戶端主動解決。（MongoDB 一般會使用replica sets和sharding功能結(jié)合，replica sets側(cè)重高可用性及高可靠性，而sharding側(cè)重于性能、易擴展） |
| 可靠性 |
從1.8版本后，采用binlog方式（MySQL同樣采用該方式）支持持久化，增加可靠性 |
依賴快照進行持久化；AOF增強可靠性；增強可靠性的同時，影響訪問性能 |
MongoDB優(yōu)于Redis |
| 一致性 |
不支持事物，靠客戶端自身保證 |
支持事物，比較弱，僅能保證事物中的操作按順序執(zhí)行 |
Redis優(yōu)于MongoDB |
| 數(shù)據(jù)分析 |
內(nèi)置數(shù)據(jù)分析功能（mapreduce） |
不支持 |
MongoDB優(yōu)于Redis |
| 應(yīng)用場景 |
海量數(shù)據(jù)的訪問效率提升 |
較小數(shù)據(jù)量的性能及運算 |
MongoDB優(yōu)于Redis |
參考鏈接：https://yq.aliyun.com/ziliao/64031
|
