謝謝邀請。

我現(xiàn)在帶的項(xiàng)目用到了MongoDB，本人對MongoDB也有一定的了解，下面我談?wù)勛约旱目捶ā?/p>

先一句話概括：MongoDB和MySQL（關(guān)系型數(shù)據(jù)庫）各有特點(diǎn)，它們適合的場景不同；而企業(yè)級(jí)應(yīng)用的大部分場景，MongoDB是無法完全取代MySQL的。

MongoDB是什么

在分析這個(gè)問題之前，我們還是看看MongoDB的定義：MongoDB是一個(gè)數(shù)據(jù)庫；再稍微詳細(xì)一點(diǎn)兒，它是一個(gè)開源的、基于分布式文件存儲(chǔ)的、非關(guān)系型數(shù)據(jù)庫。

說到非關(guān)系型數(shù)據(jù)庫，最有名的可能就是Redis了，它是一種Key-Value類型的數(shù)據(jù)庫；而MongoDB，它是文檔型數(shù)據(jù)庫的一種，它的存儲(chǔ)方式類似于JSON。

MongoDB的特性

MongoDB更多適用于大數(shù)據(jù)量、高并發(fā)、弱事務(wù)、不確定數(shù)據(jù)類型的應(yīng)用；特別是這里的“不確定數(shù)據(jù)類型”，也是MongoDB最大的特點(diǎn)之一。

大家在用關(guān)系型數(shù)據(jù)庫的時(shí)候，如果表中的數(shù)據(jù)量很大，想要給表添加一個(gè)字段，是一件很痛苦的事情；而MongoDB是無需事先創(chuàng)建表結(jié)構(gòu)或修改表結(jié)構(gòu)，所有的改變都是動(dòng)態(tài)的。

MongoDB能否取代MySQL（關(guān)系型數(shù)據(jù)庫）？

MongoDB不適用于高度事務(wù)性的系統(tǒng)，如果系統(tǒng)對數(shù)據(jù)的事務(wù)性要求很高，還是用關(guān)系型數(shù)據(jù)庫比較合適。（MongoDB3.6對單集合的事務(wù)支持不錯(cuò)，據(jù)說4.0之后，對多集合的事務(wù)支持也可以，不過我沒有深入研究過）

MongoDB的多集合關(guān)聯(lián)也沒有關(guān)系型數(shù)據(jù)庫強(qiáng)大，不過MongoDB更擅長把幾個(gè)表的信息，放在一個(gè)集合里面。

所以總結(jié)來說，關(guān)系型數(shù)據(jù)庫和MongoDB是不存在誰替代誰的問題，他們應(yīng)該是各有優(yōu)勢，相互補(bǔ)充的。就好像我們平時(shí)用的無線鍵盤和機(jī)械鍵盤一樣，無線鍵盤靈活輕便、外觀比較時(shí)尚，而機(jī)械鍵盤手感出色、跪著舒服，不傷膝蓋，各有優(yōu)勢。

希望我的回答，能夠幫助到你！我將持續(xù)分享Java開發(fā)、架構(gòu)設(shè)計(jì)、職業(yè)發(fā)展等方面的見解，希望能得到你的關(guān)注；另外，關(guān)注我后私信【資料】兩個(gè)字，可獲取架構(gòu)、大數(shù)據(jù)、面試等相關(guān)資料。

Mongodb作為最靠近關(guān)系數(shù)據(jù)庫的Nosql存儲(chǔ)，取代MySQL可以嗎？

從功能角度看，是可以取代的。

關(guān)系數(shù)據(jù)庫應(yīng)該有的核心功能它都有了：B樹索引，事務(wù)（4.0）。

一些比較重要的小更新，比如Decimal128（3.4）的添加都讓它的功能更加完善。

你在Mysql里面用的復(fù)雜查詢基本上都可以用管道或者M(jìn)apReduce實(shí)現(xiàn)。

我在好幾個(gè)項(xiàng)目中完全使用的Mongodb，經(jīng)驗(yàn)如下：

* 關(guān)聯(lián)查詢麻煩，所以Mongodb在設(shè)計(jì)模型的時(shí)候傾向于數(shù)據(jù)都內(nèi)聯(lián)，配合少量的In 查詢。這樣也會(huì)導(dǎo)致數(shù)據(jù)冗余后一致性更新的問題。

* 設(shè)計(jì)動(dòng)態(tài)表格時(shí)，Mongodb的體驗(yàn)時(shí)非常好的。

* 4.0之前的沒有事務(wù)，碰到金錢相關(guān)的服務(wù)，需要自己在服務(wù)中構(gòu)造事務(wù)環(huán)境，否則一旦失敗無法回滾。這也會(huì)造成這塊代碼膨脹。

* 編寫復(fù)雜腳本查詢數(shù)據(jù)庫時(shí)，編寫腳本或者服務(wù)時(shí)難度更大，更花時(shí)間。統(tǒng)計(jì)服務(wù)較多的時(shí)候，更加傷腦子。

* 由于協(xié)議設(shè)計(jì)的原因，命令太多，導(dǎo)致不常用命令的需要經(jīng)常查詢文檔。

推薦使用Mongodb的場合：

* 在Demo期間使用Mongodb做數(shù)據(jù)存儲(chǔ)。

* 處于前期的互聯(lián)網(wǎng)產(chǎn)品，適應(yīng)快速迭代。

* 配合MySql使用，完成一些動(dòng)態(tài)數(shù)據(jù)處理的功能。不用設(shè)計(jì)冗余列，輕松構(gòu)建查詢的感覺就是好。

* 作為一些熱數(shù)據(jù)或者中間數(shù)據(jù)（比如統(tǒng)計(jì)需要的中間表）的緩存使用。

Mongdob的官方文檔很完善，你要使用，建議把文檔瀏覽一遍。尤其是聚合管道查詢，花點(diǎn)時(shí)間好好理解，這個(gè)是你寫復(fù)雜查詢的基礎(chǔ)。

復(fù)雜的業(yè)務(wù)系統(tǒng)，盡量避免，它會(huì)影響你的開發(fā)效率。

再補(bǔ)充幾點(diǎn)：

客戶端工具可以使用navicate或者NoSql manager，推薦使用navicate，順手。

如果服務(wù)端不是nodejs之類的動(dòng)態(tài)語言服務(wù)，最好寫一些命令的擴(kuò)展，驅(qū)動(dòng)在表達(dá)式轉(zhuǎn)換方面做得還不夠。

脫離業(yè)務(wù)場景，空談技術(shù)架構(gòu)都是耍流氓。

我們公司同一個(gè)項(xiàng)目就同時(shí)在用Mysql和MongoDB，希望通過下面介紹可以幫助你真正了解到Mysql和MongoDB優(yōu)劣對比及實(shí)際業(yè)務(wù)應(yīng)用場景。

數(shù)據(jù)庫人氣排行

以下來自最新的db-engines的數(shù)據(jù)庫人氣排行榜

接下來我們看一下前十名的趨勢變化圖：

關(guān)系數(shù)據(jù)庫前10名如下：

文檔數(shù)據(jù)庫前10名如下：

通過上面可以看出MongoDB雖說分?jǐn)?shù)一直保持著穩(wěn)定上升的趨勢，但和 Mysql相比依然有一定的差距。不過，MongoDB 在2018年的表現(xiàn)是非常不錯(cuò)的，至少一直都在進(jìn)步，這個(gè)表現(xiàn)也是 MongoDB 獨(dú)一份。

數(shù)據(jù)結(jié)構(gòu)

MySQL：MySQL將數(shù)據(jù)存儲(chǔ)在表中，并使用結(jié)構(gòu)化查詢語言（SQL）訪問數(shù)據(jù)。MySQL使用模式來定義數(shù)據(jù)庫結(jié)構(gòu)，要求表中的所有行具有相同的結(jié)構(gòu)，并且值由特定的數(shù)據(jù)類型表示。

MongoDB：在MongoDB中，數(shù)據(jù)存儲(chǔ)在類似JSON的文檔中，這些文檔可以有不同的結(jié)構(gòu)。為了提高查詢速度，MongoDB可以將相關(guān)數(shù)據(jù)存儲(chǔ)在一起，這些數(shù)據(jù)可以使用MongoDB查詢語言訪問。

在MongoDB中，文檔能夠擁有自己獨(dú)特的結(jié)構(gòu)。新字段可以隨時(shí)添加并包含任何類型的值。

優(yōu)缺點(diǎn)

MySQL是關(guān)系型數(shù)據(jù)庫。

優(yōu)勢：

在不同的引擎上有不同的存儲(chǔ)方式。

查詢語句是使用傳統(tǒng)的sql語句，擁有較為成熟的體系，成熟度很高。

開源數(shù)據(jù)庫的份額在不斷增加，mysql的份額頁在持續(xù)增長。

缺點(diǎn)：

在海量數(shù)據(jù)處理的時(shí)候效率會(huì)顯著變慢。

Mongodb是非關(guān)系型數(shù)據(jù)庫(nosql )，屬于文檔型數(shù)據(jù)庫。

存儲(chǔ)方式：虛擬內(nèi)存+持久化。

查詢語句：是獨(dú)特的Mongodb的查詢方式。

適合場景：事件的記錄，內(nèi)容管理或者博客平臺(tái)等等。

架構(gòu)特點(diǎn)：可以通過副本集，以及分片來實(shí)現(xiàn)高可用。

數(shù)據(jù)處理：數(shù)據(jù)是存儲(chǔ)在硬盤上的，只不過需要經(jīng)常讀取的數(shù)據(jù)會(huì)被加載到內(nèi)存中，將數(shù)據(jù)存儲(chǔ)在物理內(nèi)存中，從而達(dá)到高速讀寫。

成熟度與廣泛度：新興數(shù)據(jù)庫，成熟度較低，Nosql數(shù)據(jù)庫中最為接近關(guān)系型數(shù)據(jù)庫，比較完善的DB之一，適用人群不斷在增長。

優(yōu)點(diǎn)：

快速！在適量級(jí)的內(nèi)存的Mongodb的性能是非常迅速的，它將熱數(shù)據(jù)存儲(chǔ)在物理內(nèi)存中，使得熱數(shù)據(jù)的讀寫變得十分快。高擴(kuò)展性，存儲(chǔ)的數(shù)據(jù)格式是json格式！

缺點(diǎn)：

事務(wù)關(guān)系支持薄弱。這也是所有NoSQL數(shù)據(jù)庫共同的缺陷，不過NoSQL并不是為了事務(wù)關(guān)系而設(shè)計(jì)的，具體應(yīng)用還是根據(jù)需求。而且開發(fā)文檔不是很完全、完善。

應(yīng)用場景

關(guān)系型數(shù)據(jù)庫適合存儲(chǔ)結(jié)構(gòu)化數(shù)據(jù)，如用戶的帳號(hào)、地址

1）這些數(shù)據(jù)通常需要做結(jié)構(gòu)化查詢，比如join，這時(shí)候，關(guān)系型數(shù)據(jù)庫就要?jiǎng)俪鲆换I

2）這些數(shù)據(jù)的規(guī)模、增長的速度通常是可以預(yù)期的

3）事務(wù)性、一致性

NoSQL適合存儲(chǔ)非結(jié)構(gòu)化數(shù)據(jù)，如文章、評(píng)論：

1）這些數(shù)據(jù)通常用于模糊處理，如全文搜索、機(jī)器學(xué)習(xí)

2）這些數(shù)據(jù)是海量的，而且增長的速度是難以預(yù)期的，

3）根據(jù)數(shù)據(jù)的特點(diǎn)，NoSQL數(shù)據(jù)庫通常具有無限（至少接近）伸縮性

4）按key獲取數(shù)據(jù)效率很高，但是對join或其他結(jié)構(gòu)化查詢的支持就比較差

什么場景MongoDB更適用

更高的寫入負(fù)載

默認(rèn)情況下，MongoDB更側(cè)重高數(shù)據(jù)寫入性能，而非事務(wù)安全，MongoDB很適合業(yè)務(wù)系統(tǒng)中有大量“低價(jià)值”數(shù)據(jù)的場景。但是應(yīng)當(dāng)避免在高事務(wù)安全性的系統(tǒng)中使用MongoDB，除非能從架構(gòu)設(shè)計(jì)上保證事務(wù)安全。

高可用性

MongoDB的復(fù)副集(Master-Slave)配置非常簡潔方便，此外，MongoDB可以快速響應(yīng)的處理單節(jié)點(diǎn)故障，自動(dòng)、安全的完成故障轉(zhuǎn)移。這些特性使得MongoDB能在一個(gè)相對不穩(wěn)定（如云主機(jī)）的環(huán)境中，保持高可用性。

數(shù)據(jù)量很大或者未來會(huì)變得很大

依賴數(shù)據(jù)庫(MySQL)自身的特性，完成數(shù)據(jù)的擴(kuò)展是較困難的事，在MySQL中，當(dāng)一個(gè)單達(dá)表到5-10GB時(shí)會(huì)出現(xiàn)明顯的性能降級(jí)，此時(shí)需要通過數(shù)據(jù)的水平和垂直拆分、庫的拆分完成擴(kuò)展，使用MySQL通常需要借助驅(qū)動(dòng)層或代理層完成這類需求。而MongoDB內(nèi)建了多種數(shù)據(jù)分片的特性，可以很好的適應(yīng)大數(shù)據(jù)量的需求。

基于位置的數(shù)據(jù)查詢

MongoDB支持二維空間索引，因此可以快速及精確的從指定位置獲取數(shù)據(jù)。

表結(jié)構(gòu)不明確，且數(shù)據(jù)在不斷變大

在一些傳統(tǒng)RDBMS中，增加一個(gè)字段會(huì)鎖住整個(gè)數(shù)據(jù)庫/表，或者在執(zhí)行一個(gè)重負(fù)載的請求時(shí)會(huì)明顯造成其它請求的性能降級(jí)。通常發(fā)生在數(shù)據(jù)表大于1G的時(shí)候（當(dāng)大于1TB時(shí)更甚）。 因MongoDB是文檔型數(shù)據(jù)庫，為非結(jié)構(gòu)貨的文檔增加一個(gè)新字段是很快速的操作，并且不會(huì)影響到已有數(shù)據(jù)。另外一個(gè)好處當(dāng)業(yè)務(wù)數(shù)據(jù)發(fā)生變化時(shí)，是將不在需要由DBA修改表結(jié)構(gòu)。

沒有DBA支持

如果沒有專職的DBA，并且準(zhǔn)備不使用標(biāo)準(zhǔn)的關(guān)系型思想（結(jié)構(gòu)化、連接等）來處理數(shù)據(jù)，那么MongoDB將會(huì)是你的首選。MongoDB對于對像數(shù)據(jù)的存儲(chǔ)非常方便，類可以直接序列化成JSON存儲(chǔ)到MongoDB中。 但是需要先了解一些最佳實(shí)踐，避免當(dāng)數(shù)據(jù)變大后，由于文檔設(shè)計(jì)問題而造成的性能缺陷。

實(shí)際業(yè)務(wù)應(yīng)用

BillRun – 基于MongoDB的帳單系統(tǒng) (來自oc666)

BillRun是由Ofer Cohen推出開源賬單系統(tǒng)，采用MongoDB做為數(shù)據(jù)存儲(chǔ)。這套賬單系統(tǒng)被以色列一家增速最快的電信運(yùn)營商采用，每月處理5億條通信記錄，Ofer在Slideshare上說明了具體利到了MongoDB的哪些特性：

弱數(shù)據(jù)結(jié)構(gòu)的特點(diǎn)，使得BillRun能很快的支持新的CDR(通訊記錄)類型。這個(gè)特性使文檔型數(shù)據(jù)庫很適用于快速發(fā)展、業(yè)務(wù)需求不確定的系統(tǒng)中。

BillRun僅使用了一個(gè)Collection，已經(jīng)管理了數(shù)TB的文檔數(shù)據(jù)，并且沒有遇到由結(jié)構(gòu)變更、數(shù)據(jù)爆發(fā)式增長的帶來的限制和問題。

replicaSet副本集特性使建立更多的數(shù)據(jù)中心DRP變得更輕松。

內(nèi)建的Sharding分片特性避免系統(tǒng)在數(shù)據(jù)增長的過程中遇到性能瓶頸。

每秒鐘2000條通信記錄的插入，MongoDB在架構(gòu)設(shè)計(jì)上很好的支持了高負(fù)載的數(shù)據(jù)寫入。并且可以使用findAndModify(相對緩慢)完成基礎(chǔ)的事務(wù)特性，并且通過應(yīng)用層面的支持，實(shí)現(xiàn)雙段式提交。

查詢方式相比SQL，更加易讀、易懂，開發(fā)相對輕松。

基于位置允許更好的分析用戶使用情況，從而更好地制定移動(dòng)電話基礎(chǔ)設(shè)施的投入點(diǎn)。

以上，如果對你有幫助幫忙點(diǎn)個(gè)贊吧

專注于Java領(lǐng)域優(yōu)質(zhì)技術(shù)號(hào)，歡迎關(guān)注

粘貼那么多介紹干嘛，一句話：不同業(yè)務(wù)場景，選用就不一樣。mysql針對業(yè)務(wù)結(jié)構(gòu)復(fù)雜的用，mongodb反之。兩者結(jié)合，mongodb可以拿來做高級(jí)緩存或者提供查詢性能來存儲(chǔ)。mysql就出來業(yè)務(wù)結(jié)構(gòu)復(fù)雜的數(shù)據(jù)存儲(chǔ)，還有事務(wù)回滾。mongodb是沒有事務(wù)回滾的

完全取代是必然的，只是一個(gè)時(shí)間問題，關(guān)系型數(shù)據(jù)庫或者說所有基于二維數(shù)據(jù)表的數(shù)據(jù)庫都應(yīng)該被淘汰了。

淺而易見的道理，二維數(shù)據(jù)表能做的哈希數(shù)據(jù)集（姑且稱之為三維數(shù)據(jù)集）都能做到，可以說后者包含前者，而如果要反過來那就不是那么簡單了，需要多個(gè)二維數(shù)據(jù)表才能實(shí)現(xiàn)一個(gè)哈希樹形數(shù)據(jù)集的目標(biāo)。

二維表中為了多表關(guān)系導(dǎo)致大量字段數(shù)據(jù)重復(fù)，開發(fā)模塊的邏輯層進(jìn)行數(shù)據(jù)對象組織所需要的轉(zhuǎn)換變得繁鎖，設(shè)計(jì)毫無低技術(shù)含量又臃腫，高開銷低效率，不參與檢索的大量字段暴露在頂層數(shù)據(jù)中顯得無趣又無意義。

而這些二維表罄竹難書的缺點(diǎn)，哈希樹形數(shù)據(jù)結(jié)構(gòu)的NoSQL數(shù)據(jù)集數(shù)據(jù)庫具備先天性的優(yōu)勢。

MongoDB4.0以后，事物問題被徹底解決，實(shí)在找不出還要舍Mongodb而抱MySql的理由，其次MySql被甲骨文收購之后，前途未卜，畢竟它們還是要靠Oracle賺錢的。

就好像再問，戰(zhàn)斗力可以替換為民航客機(jī)么？

MongoDB作為新一代的數(shù)據(jù)庫平臺(tái)，具備了智能操作數(shù)據(jù)平臺(tái)的特點(diǎn)：

1、易于開發(fā)，上手快，開發(fā)效率快；

2、天生的高可用性（副本集），天生的可擴(kuò)展性（分片技術(shù)）滿足企業(yè)級(jí)的需求；

3、隨處部署的能力，可以和云技術(shù)、容器技術(shù)深度集成，符合當(dāng)前devops、微服務(wù)等技術(shù)發(fā)展趨勢。

正是因?yàn)樯鲜鲈?，很多?yīng)用都已經(jīng)或者正在考慮使用MongoDB替代MySQL。特別是在MongoDB 4.0之后，應(yīng)用使用MongoDB替代MySQL順利成章，主要原因是：

1. MongoDB 4.0 提供了多文檔事務(wù)，支持完整的ACID操作；

2. MongoDB 4.0 優(yōu)化了副本集的從節(jié)點(diǎn)的讀能力，從性能上更好的支撐分析型應(yīng)用；

3. MongoDB 4.0 優(yōu)化了聚合框架，從功能上更好的支撐分析型應(yīng)用。

誠然，在使用MongoDB替代MySQL過程中也會(huì)有一些挑戰(zhàn)，這些挑戰(zhàn)從個(gè)人的經(jīng)驗(yàn)來看主要集中在：

1. 對MongoDB的“反范式”建模理解不夠；“反范式”建模作為一種創(chuàng)新的建模方式，以應(yīng)用使用數(shù)據(jù)為導(dǎo)向，而不是過去以“實(shí)體”和“關(guān)系”為導(dǎo)向；

2. 對現(xiàn)有的基于MySQL的應(yīng)用的數(shù)據(jù)遷移到MongoDB。這種數(shù)據(jù)遷移中挑戰(zhàn)比較大的地方在于如何實(shí)現(xiàn)實(shí)時(shí)遷移，MongoDB 3.6的Change Stream可以幫助實(shí)現(xiàn)數(shù)據(jù)實(shí)時(shí)遷移。

上述是個(gè)人的一些理解，供參考指正！

自己也是程序員，分享一些觀點(diǎn)給你，其實(shí)不管是MongoDB還是Mysql,它們都是用來存儲(chǔ)數(shù)據(jù)用的，只不過存儲(chǔ)數(shù)據(jù)的方式不同，MySQL主要用于存儲(chǔ)關(guān)系類的數(shù)據(jù)，而MongoDB主要用于存儲(chǔ)鍵值類的數(shù)據(jù)，也就是我們常說的NOSQL，曾經(jīng)一段時(shí)間，NOSQL是很多中小互聯(lián)網(wǎng)公司追求的東西。

那么既然都是存儲(chǔ)數(shù)據(jù)用的，那么肯定也可以相互替換，但是一個(gè)重要的問題就是，怎么樣將MongoDB里面的數(shù)據(jù)存儲(chǔ)到MySQL里面或者相反方向有怎么存儲(chǔ)？這才是整個(gè)業(yè)務(wù)代碼非常復(fù)雜的實(shí)現(xiàn)部分，比如你要將MySQL的數(shù)據(jù)存儲(chǔ)到MongoDB里面去，那么你需要做的事情就是理清MySQL數(shù)據(jù)表里面的各種關(guān)系，然后將這些關(guān)系轉(zhuǎn)換為鍵值對存儲(chǔ)到MongoDB里面去，想象一下這個(gè)工作量我們就應(yīng)該知道，不是那么的簡單，尤其是數(shù)據(jù)表非常多，并且數(shù)據(jù)表關(guān)系非常復(fù)雜的時(shí)候，這項(xiàng)遷移工程是需要后端程序員、數(shù)據(jù)庫DBA、運(yùn)維人員等等一起才能夠完成的事情。

所以得出結(jié)論，雖然兩種數(shù)據(jù)庫可以相互替換，但是替換的成本非常高，很多企業(yè)是不會(huì)這樣做的，除非現(xiàn)在項(xiàng)目性能已經(jīng)嚴(yán)重影響到目標(biāo)用戶。

其實(shí)每個(gè)產(chǎn)品都有其特長的短板，可能會(huì)在一定程度上存在功能重復(fù)，但不可能完全取代。舉個(gè)不太恰當(dāng)?shù)睦觼碚f：貓和狗都可以當(dāng)寵物，貓能取代狗嗎？答案肯定是不能。但作為寵物，兩者確實(shí)都能做到惹人喜愛，也都能在主人寂寞或無聊的時(shí)候陪伴主人，作為寵物，它們甚至有更多相同的作用，但兩者永遠(yuǎn)無法取代對方。不得不說在這個(gè)技術(shù)類產(chǎn)品滿天飛的時(shí)代，總有些對技術(shù)不深入了解的人或企業(yè)做著用貓來取代狗的白日夢，希望大家保持對技術(shù)的敬畏之心，可以大膽假設(shè)，但要謹(jǐn)慎求證，最終作出正確的選擇。

看業(yè)務(wù)場景，沒有必要非a既b