謝謝邀請。

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

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

MongoDB是什么

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

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

MongoDB的特性

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

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

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

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

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

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

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

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

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

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

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

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

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

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

* 設(shè)計動態(tài)表格時，Mongodb的體驗時非常好的。

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

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

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

推薦使用Mongodb的場合：

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

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

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

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

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

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

再補充幾點：

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

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

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

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

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

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

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

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

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

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

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

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

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

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

優(yōu)缺點

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

優(yōu)勢：

在不同的引擎上有不同的存儲方式。

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

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

缺點：

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

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

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

查詢語句：是獨特的Mongodb的查詢方式。

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

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

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

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

優(yōu)點：

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

缺點：

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

應(yīng)用場景

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

1）這些數(shù)據(jù)通常需要做結(jié)構(gòu)化查詢，比如join，這時候，關(guān)系型數(shù)據(jù)庫就要勝出一籌

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

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

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

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

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

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

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

什么場景MongoDB更適用

更高的寫入負載

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

高可用性

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

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

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

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

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

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

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

沒有DBA支持

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

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

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

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

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

BillRun僅使用了一個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è)計上很好的支持了高負載的數(shù)據(jù)寫入。并且可以使用findAndModify(相對緩慢)完成基礎(chǔ)的事務(wù)特性，并且通過應(yīng)用層面的支持，實現(xiàn)雙段式提交。

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

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

以上，如果對你有幫助幫忙點個贊吧

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

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

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

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

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

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

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

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

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

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

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

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

正是因為上述原因，很多應(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é)點的讀能力，從性能上更好的支撐分析型應(yīng)用；

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

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

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

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

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

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

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

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

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

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