謝謝邀請。

我現在帶的項目用到了MongoDB，本人對MongoDB也有一定的瞭解，下面我談談自己的看法。

先一句話概括：MongoDB和MySQL（關係型數據庫）各有特點，它們適合的場景不同；而企業級應用的大部分場景，MongoDB是無法完全取代MySQL的。

MongoDB是什麼

在分析這個問題之前，我們還是看看MongoDB的定義：MongoDB是一個數據庫；再稍微詳細一點兒，它是一個開源的、基於分佈式文件存儲的、非關係型數據庫。

說到非關係型數據庫，最有名的可能就是Redis了，它是一種Key-Value類型的數據庫；而MongoDB，它是文檔型數據庫的一種，它的存儲方式類似於JSON。

MongoDB的特性

MongoDB更多適用於大數據量、高併發、弱事務、不確定數據類型的應用；特別是這裡的“不確定數據類型”，也是MongoDB最大的特點之一。

大家在用關係型數據庫的時候，如果表中的數據量很大，想要給表添加一個字段，是一件很痛苦的事情；而MongoDB是無需事先創建表結構或修改表結構，所有的改變都是動態的。

MongoDB能否取代MySQL（關係型數據庫）？

MongoDB不適用於高度事務性的系統，如果系統對數據的事務性要求很高，還是用關係型數據庫比較合適。（MongoDB3.6對單集合的事務支持不錯，據說4.0之後，對多集合的事務支持也可以，不過我沒有深入研究過）

MongoDB的多集合關聯也沒有關係型數據庫強大，不過MongoDB更擅長把幾個表的信息，放在一個集合裡面。

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

希望我的回答，能夠幫助到你！我將持續分享Java開發、架構設計、職業發展等方面的見解，希望能得到你的關注；另外，關注我後私信【資料】兩個字，可獲取架構、大數據、面試等相關資料。

這個問題其實就好像問關係型數據庫可以取代非關係型數據庫一樣。

要說完全取代，肯定是不可能的。

但是某些小項目中，你可以選擇使用mongodb而不用mysql。至少我經常這麼幹。

當然，在一些特殊的大型項目裡面，你也可以完全拋棄關係型數據庫，mongodb會是你一個很好的選擇，什麼樣的項目？怎麼使用呢？我最後來告訴大家。

Mongodb確實非常好用，它的特點是高性能、易部署、易使用，存儲數據非常方便。

我們在使用的時候，不用再去考慮數據庫的設計，字段等等。

我們可以輕鬆的建立好實體，然後CRUD。

當然，它還能夠支持查詢和索引，這樣就讓我們在使用中更加的方便，只要不是複雜的表關係邏輯，我們都可以使用mongodb來完成。

但是缺點就就是上面說的，如果非常複雜的邏輯關係，那用mongodb就有點力不從心了。

因為mongodb在複雜的關係邏輯處理和事務控制方面就比較弱了。

曾經，我研究過一段時間領域驅動設計，也就是DDD。

當DDD和CQRS（命令與查詢職責分離）結合使用的時候（當然，很多時候說DDD都是結合了CQRS的），你就會發現，你是不是使用關係型數據庫已經不太重要了。

先說說底層，如果你使用DDD+CQRS，你可以有兩個數據庫，一個Command庫，一個Query庫，也就是讀庫和寫庫。

當DDD+CQRS使用時，寫庫裡面寫入的只是一個個對象的操作命令，所以可以簡單的說，一個命令就是一條記錄，而且寫庫裡面只有Insert。當然，最後的時候，寫庫裡面會有海量的數據，當數據量過大時，就會用到快照，這個就不說了。

這個時候我們就會發現，一個只有insert的單表庫，用關係型數據庫貌似沒啥意義。我用mongodb，redis都可以完成。

那我們再看看讀庫，讀庫其實是將所有的命令執行後的最終結果呈現出來，那讀庫應該是關係型的，因為我們的業務邏輯肯定是有關係的。

但是我們仔細體會後會發現，DDD的聚合，聚合根，實體對象，值對象這些概念，將本來複雜的關係整理得非常明晰（有興趣的可以去看看DDD，這些概念有點抽象，這裡就不介紹了）。

你會發現，我不使用關係型數據庫，我就是用一個緩存，或者mongodb就可以進行存儲了，因為我的查詢都是通過聚合根來實現的，我的命令也都是通過聚合根來完成的，聚合根是什麼？其實也就是一個實體類，整個聚合也就是一個複雜關係的實體類，聚合與聚合之間其實不會有聯繫，這個也就是DDD裡面的關於邊界的劃分。

那在實現這一的項目時，我就可以寫庫用Redis，讀庫用Mongodb，MySQL？可以不用了。

先給出結論：不可以取代！

能提出這樣的問題，肯定是對Mongodb不是很瞭解，來看看MongoDB是什麼，能做什麼，不能做什麼吧。

MongoDB

mongoDB是一個介於關係數據庫和非關係數據庫之間的產品，是非關係數據庫當中功能最豐富，最像關係數據庫的。他支持的數據結構非常鬆散，是類似json的bson格式，因此可以存儲比較複雜的數據類型。Mongo最大的特點是他支持的查詢語言非常強大，其語法有點類似於面向對象的查詢語言，幾乎可以實現類似關係數據庫單表查詢的絕大部分功能，而且還支持對數據建立索引。

特點：

1. 面向集合存儲，易存儲對象類型的數據。
2. 模式自由。
3. 支持動態查詢。
4. 支持完全索引，包含內部對象。
5. 支持查詢。
6. 支持複製和故障恢復。
7. 使用高效的二進制數據存儲，包括大型對象（如視頻等）。
8. 自動處理碎片，以支持雲計算層次的擴展性。
9. 支持RUBY，PYTHON，JAVA，C++，PHP，C#等多種語言。
10. 文件存儲格式為BSON（一種JSON的擴展）。
11. 可通過網絡訪問。

使用原理

不適用的場景如下：

1）要求高度事務性的系統。

3）複雜的跨文檔（表）級聯查詢。

結論

從MongoDB不適用場景就可以看出其不可能替代MySQL.

自己也是程序員，分享一些觀點給你，其實不管是MongoDB還是Mysql,它們都是用來存儲數據用的，只不過存儲數據的方式不同，MySQL主要用於存儲關係類的數據，而MongoDB主要用於存儲鍵值類的數據，也就是我們常說的NOSQL，曾經一段時間，NOSQL是很多中小互聯網公司追求的東西。

那麼既然都是存儲數據用的，那麼肯定也可以相互替換，但是一個重要的問題就是，怎麼樣將MongoDB裡面的數據存儲到MySQL裡面或者相反方向有怎麼存儲？這才是整個業務代碼非常複雜的實現部分，比如你要將MySQL的數據存儲到MongoDB裡面去，那麼你需要做的事情就是理清MySQL數據表裡面的各種關係，然後將這些關係轉換為鍵值對存儲到MongoDB裡面去，想象一下這個工作量我們就應該知道，不是那麼的簡單，尤其是數據表非常多，並且數據表關係非常複雜的時候，這項遷移工程是需要後端程序員、數據庫DBA、運維人員等等一起才能夠完成的事情。

所以得出結論，雖然兩種數據庫可以相互替換，但是替換的成本非常高，很多企業是不會這樣做的，除非現在項目性能已經嚴重影響到目標用戶。

Mongodb作為最靠近關係數據庫的Nosql存儲，取代MySQL可以嗎？

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

關係數據庫應該有的核心功能它都有了：B樹索引，事務（4.0）。

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

你在Mysql裡面用的複雜查詢基本上都可以用管道或者MapReduce實現。

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

* 關聯查詢麻煩，所以Mongodb在設計模型的時候傾向於數據都內聯，配合少量的In 查詢。這樣也會導致數據冗餘後一致性更新的問題。

* 設計動態表格時，Mongodb的體驗時非常好的。

* 4.0之前的沒有事務，碰到金錢相關的服務，需要自己在服務中構造事務環境，否則一旦失敗無法回滾。這也會造成這塊代碼膨脹。

* 編寫複雜腳本查詢數據庫時，編寫腳本或者服務時難度更大，更花時間。統計服務較多的時候，更加傷腦子。

* 由於協議設計的原因，命令太多，導致不常用命令的需要經常查詢文檔。

推薦使用Mongodb的場合：

* 在Demo期間使用Mongodb做數據存儲。

* 處於前期的互聯網產品，適應快速迭代。

* 配合MySql使用，完成一些動態數據處理的功能。不用設計冗餘列，輕鬆構建查詢的感覺就是好。

* 作為一些熱數據或者中間數據（比如統計需要的中間表）的緩存使用。

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

複雜的業務系統，儘量避免，它會影響你的開發效率。

再補充幾點：

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

如果服務端不是nodejs之類的動態語言服務，最好寫一些命令的擴展，驅動在表達式轉換方面做得還不夠。

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

1、易於開發，上手快，開發效率快；

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

3、隨處部署的能力，可以和雲技術、容器技術深度集成，符合當前devops、微服務等技術發展趨勢。

正是因為上述原因，很多應用都已經或者正在考慮使用MongoDB替代MySQL。特別是在MongoDB 4.0之後，應用使用MongoDB替代MySQL順利成章，主要原因是：

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

2. MongoDB 4.0 優化了副本集的從節點的讀能力，從性能上更好的支撐分析型應用；

3. MongoDB 4.0 優化了聚合框架，從功能上更好的支撐分析型應用。

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

1. 對MongoDB的“反範式”建模理解不夠；“反範式”建模作為一種創新的建模方式，以應用使用數據為導向，而不是過去以“實體”和“關係”為導向；

2. 對現有的基於MySQL的應用的數據遷移到MongoDB。這種數據遷移中挑戰比較大的地方在於如何實現實時遷移，MongoDB 3.6的Change Stream可以幫助實現數據實時遷移。

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

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

粘貼那麼多介紹幹嘛，一句話：不同業務場景，選用就不一樣。mysql針對業務結構複雜的用，mongodb反之。兩者結合，mongodb可以拿來做高級緩存或者提供查詢性能來存儲。mysql就出來業務結構複雜的數據存儲，還有事務回滾。mongodb是沒有事務回滾的

一種是關係數據庫，一種是非關係數據庫，他們的共同地方就是都是數據庫，都是用來存儲項目數據的，所以從理論上來說是可以相互替代的，但是，有一個實際問題，就是兩種數據的保存方式不同，也就是應用程序寫入數據的方式不同，所以相互替換時，需要熟悉兩個程序的保存方式和業務邏輯。