自己也是程式設計師，分享一些觀點給你，其實不管是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，本人對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是不存在誰替代誰的問題，他們應該是各有優勢，相互補充的。就好像我們平時用的無線鍵盤和機械鍵盤一樣，無線鍵盤靈活輕便、外觀比較時尚，而機械鍵盤手感出色、跪著舒服，不傷膝蓋，各有優勢。

脫離業務場景，空談技術架構都是耍流氓。

我們公司同一個專案就同時在用Mysql和MongoDB，希望透過下面介紹可以幫助你真正瞭解到Mysql和MongoDB優劣對比及實際業務應用場景。

資料庫人氣排行

以下來自最新的db-engines的資料庫人氣排行榜

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

關係資料庫前10名如下：

文件資料庫前10名如下：

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

資料結構

MySQL：MySQL將資料儲存在表中，並使用結構化查詢語言（SQL）訪問資料。MySQL使用模式來定義資料庫結構，要求表中的所有行具有相同的結構，並且值由特定的資料型別表示。

MongoDB：在MongoDB中，資料儲存在類似JSON的文件中，這些文件可以有不同的結構。為了提高查詢速度，MongoDB可以將相關資料儲存在一起，這些資料可以使用MongoDB查詢語言訪問。

在MongoDB中，文件能夠擁有自己獨特的結構。新欄位可以隨時新增幷包含任何型別的值。

優缺點

MySQL是關係型資料庫。

優勢：

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

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

開源資料庫的份額在不斷增加，mysql的份額頁在持續增長。

缺點：

在海量資料處理的時候效率會顯著變慢。

Mongodb是非關係型資料庫(nosql )，屬於文件型資料庫。

儲存方式：虛擬記憶體+持久化。

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

適合場景：事件的記錄，內容管理或者部落格平臺等等。

架構特點：可以透過副本集，以及分片來實現高可用。

資料處理：資料是儲存在硬碟上的，只不過需要經常讀取的資料會被載入到記憶體中，將資料儲存在物理記憶體中，從而達到高速讀寫。

成熟度與廣泛度：新興資料庫，成熟度較低，Nosql資料庫中最為接近關係型資料庫，比較完善的DB之一，適用人群不斷在增長。

優點：

快速！在適量級的記憶體的Mongodb的效能是非常迅速的，它將熱資料儲存在物理記憶體中，使得熱資料的讀寫變得十分快。高擴充套件性，儲存的資料格式是json格式！

缺點：

事務關係支援薄弱。這也是所有NoSQL資料庫共同的缺陷，不過NoSQL並不是為了事務關係而設計的，具體應用還是根據需求。而且開發文件不是很完全、完善。

應用場景

關係型資料庫適合儲存結構化資料，如使用者的帳號、地址

1）這些資料通常需要做結構化查詢，比如join，這時候，關係型資料庫就要勝出一籌

2）這些資料的規模、增長的速度通常是可以預期的

3）事務性、一致性

1）這些資料通常用於模糊處理，如全文搜尋、機器學習

2）這些資料是海量的，而且增長的速度是難以預期的，

3）根據資料的特點，NoSQL資料庫通常具有無限（至少接近）伸縮性

4）按key獲取資料效率很高，但是對join或其他結構化查詢的支援就比較差

什麼場景MongoDB更適用

更高的寫入負載

預設情況下，MongoDB更側重高資料寫入效能，而非事務安全，MongoDB很適合業務系統中有大量“低價值”資料的場景。但是應當避免在高事務安全性的系統中使用MongoDB，除非能從架構設計上保證事務安全。

高可用性

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

資料量很大或者未來會變得很大

依賴資料庫(MySQL)自身的特性，完成資料的擴充套件是較困難的事，在MySQL中，當一個單達表到5-10GB時會出現明顯的效能降級，此時需要透過資料的水平和垂直拆分、庫的拆分完成擴充套件，使用MySQL通常需要藉助驅動層或代理層完成這類需求。而MongoDB內建了多種資料分片的特性，可以很好的適應大資料量的需求。

基於位置的資料查詢

MongoDB支援二維空間索引，因此可以快速及精確的從指定位置獲取資料。

表結構不明確，且資料在不斷變大

在一些傳統RDBMS中，增加一個欄位會鎖住整個資料庫/表，或者在執行一個重負載的請求時會明顯造成其它請求的效能降級。通常發生在資料表大於1G的時候（當大於1TB時更甚）。 因MongoDB是文件型資料庫，為非結構貨的文件增加一個新欄位是很快速的操作，並且不會影響到已有資料。另外一個好處當業務資料發生變化時，是將不在需要由DBA修改表結構。

沒有DBA支援

如果沒有專職的DBA，並且準備不使用標準的關係型思想（結構化、連線等）來處理資料，那麼MongoDB將會是你的首選。MongoDB對於對像資料的儲存非常方便，類可以直接序列化成JSON儲存到MongoDB中。 但是需要先了解一些最佳實踐，避免當資料變大後，由於文件設計問題而造成的效能缺陷。

實際業務應用

BillRun – 基於MongoDB的帳單系統 (來自oc666)

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

弱資料結構的特點，使得BillRun能很快的支援新的CDR(通訊記錄)型別。這個特性使文件型資料庫很適用於快速發展、業務需求不確定的系統中。

BillRun僅使用了一個Collection，已經管理了數TB的文件資料，並且沒有遇到由結構變更、資料爆發式增長的帶來的限制和問題。

replicaSet副本集特性使建立更多的資料中心DRP變得更輕鬆。

內建的Sharding分片特性避免系統在資料增長的過程中遇到效能瓶頸。

每秒鐘2000條通訊記錄的插入，MongoDB在架構設計上很好的支援了高負載的資料寫入。並且可以使用findAndModify(相對緩慢)完成基礎的事務特性，並且透過應用層面的支援，實現雙段式提交。

查詢方式相比SQL，更加易讀、易懂，開發相對輕鬆。

基於位置允許更好的分析使用者使用情況，從而更好地制定行動電話基礎設施的投入點。

MySQL是關係型資料庫。

優勢：

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

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

開源資料庫的份額在不斷增加，mysql的份額頁在持續增長。

缺點：

在海量資料處理的時候效率會顯著變慢。

Mongodb是非關係型資料庫(nosql ),屬於文件型資料庫。文件是mongoDB中資料的基本單元，類似關係資料庫的行，多個鍵值對有序地放置在一起便是文件，語法有點類似javascript面向物件的查詢語言，它是一個面向集合的，模式自由的文件型資料庫。

儲存方式：虛擬記憶體+持久化。

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

適合場景：事件的記錄，內容管理或者部落格平臺等等。

架構特點：可以透過副本集，以及分片來實現高可用。

資料處理：資料是儲存在硬碟上的，只不過需要經常讀取的資料會被載入到記憶體中，將資料儲存在物理記憶體中，從而達到高速讀寫。

成熟度與廣泛度：新興資料庫，成熟度較低，Nosql資料庫中最為接近關係型資料庫，比較完善的DB之一，適用人群不斷在增長。

優點：

快速！在適量級的記憶體的Mongodb的效能是非常迅速的，它將熱資料儲存在物理記憶體中，使得熱資料的讀寫變得十分快。高擴充套件性，儲存的資料格式是json格式！

缺點：

不支援事務，而且開發文件不是很完全，完善。

Mysql和Mongodb主要應用場景

1.如果需要將mongodb作為後端db來代替mysql使用，即這裡mysql與mongodb 屬於平行級別，那麼，這樣的使用可能有以下幾種情況的考量：

(1)mongodb所負責部分以文件形式儲存，能夠有較好的程式碼親和性，json格式的直接寫入方便。(如日誌之類)

(2)從datamodels設計階段就將原子性考慮於其中，無需事務之類的輔助。開發用如nodejs之類的語言來進行開發，對開發比較方便。

(3)mongodb本身的failover機制，無需使用如MHA之類的方式實現。

2.將mongodb作為類似redis ，memcache來做快取db，為mysql提供服務，或是後端日誌收集分析。 考慮到mongodb屬於nosql型資料庫，sql語句與資料結構不如mysql那麼親和 ，也會有很多時候將mongodb做為輔助mysql而使用的類redis memcache 之類的快取db來使用。 亦或是僅作日誌收集分析。