親愛的讀者，您可能想知道為什麼要寫關於MongoDb和MySql這篇文章。那是因為我與NodeJs開發人員討論在應用程式中使用哪種資料儲存作為主要的資料儲存方式。 我看過很多評論都在爭論這個問題。 有人說：“使用MongoDb，它更快並且更適合NodeJs應用”，其他人說：“使用關聯式資料庫， 在MongoDb中不能方便的編寫資料關聯”。因此我決定去研究這兩者之間的差別。
注意：不要將此看作是對這兩者的完整研究。 本文只是在分享我的觀點，不要誤認為在說明使用這種技術好而另一種技術不好。
測試環境
對於所有這些測試，我使用了MongoDb：最新的docker容器用於 MySQL。 4G 虛擬環境。 處理器：2.5 GHz Intel CoreI5。 對於查詢，我使用了一個帶有HapiJs的內建API。 對於這些技術最大程度地在他們最理想的環境使用。對於MongoDb和MySql使用本機驅動程式，並且沒有啟用快取。
我在三種不同的模型上進行了測試。
1、Mongo-flat - 這僅僅是一個物件結構。 集合中只嵌入一個帶有住址的“使用者” 集合。
2、 Mongo-relation –mongo 關係結構。包括兩個集合：`Users`和`Address`。
3、 Mysql - 關係模式。兩張表：`Users`和`Address`
通常，“使用者”與“地址”具有一對多的關係。
基準
1、插入 - 我使用`Faker.js`插入。插入使用兩種方法進行：逐行插入和批量插入。批量插入5000條。
如上圖所示，Mongo-flat批量插入耗時最少，因為MongoDb在設計時就是用高批量插入。 而MySql 這點不如MongoDb。
2、向使用者新增地址
在這個例子中，MySql 耗時比較少。
3、刪除記錄
“Mongo-Flat” 在集合 `Users`中刪除具有優勢。 正如我上面提到的，MongoDb是為高寫入和高刪除設計的。 相反，Mysql可以卻可以幫助刪除使用外鍵約束 `ON DELETE ... `的關係。這個在資料庫中出現復雜關係時變得很方便。我不是建議一起刪除記錄，而是建議刪除時使用軟刪除。換句話說，可以依靠資料庫來完成。儘管比起MySql來說MongoDb不能這樣做。對於在`Mongo-relation`中刪除關係需要執行多個查詢才可以完成，首先得到關係資料然後通過整個關係樹才能去刪除。
4、一次獲得5000個使用者
對於資料檢索，MySql表現出更好的效能。檢索使用者mysql用了35毫秒時間，比mongo-relation快～14%，比mongo-flat快～12%。
5、統計使用者
MySql表現的不如人意， Mongo-flat 和Mongo-relation 表現出非常好的結果。
6、獲得5000個帶有地址的用戶
Mysql和Mongo-flat的表現大致相同，但是 mongo-relation關係卻不是很好;這是因為在Mongo-relation檢索中需要執行兩個查詢：一個檢索用戶，另一個檢索其地址。在MySql的情況下它只是一個`JOIN`而在Mongo-flat的情況下只返回一個flat對象。
7、獲取沒有 Florida 地址的使用者
Mysql和Mongo-Uat再次大致相同。 如上圖Mongo-flat的速度與第六次測試基準對比開始下降，那是因為在`<> ‘Florida’ and {$ne:‘Florida’}‘中存在過濾。Mongo-relation再次很慢，因為為了執行這種查詢他需要使用MongoDb聚合框架。
8、獲取5000個地址
MySql再次表現出優良的效能，與此同時Mongo-Uat在只剩最後一行就完成。原因是MongoDb`使用聚合框架`; 在Mongo-flat檢索中需要在嵌入式上聚合的資料地址關係。
9、計算地址
即使對我來說，這個結果也令人驚訝。正如上圖所示，Mongo-flat比其他慢得多。還是因為聚合計算嵌入在`Users`集合中的地址是必要的。
10、根據where語句更新地址
在嵌入地址時隨著更新資料的發生，Mongo-flat表現的更糟糕
11、獲取所有Florida地址
Mongo-flat再次成為最後一個。 再次由於聚合框架。
結論
從上面顯示的所有測試中可以看到MongoDb在插入中表現非常好。 這是因為MongoDb設計時就能夠寫出大量資料。所以我可以得出MongoDb的結論最適合您需要大量寫入的地方，例如日誌記錄或過渡資料。
但是，MySql在資料檢索方面卻是非常好的。因此，如果沒有大量資料插入或偶爾插入資料將MySql作為的業務資料儲存，例如報告，客戶管理等。
通過測試，我認為MongoDb被用作關聯式資料庫是錯誤的。僅僅使用MySql或任何其他基於Sql的資料庫都會比MongoDb好用，它們專為關聯式資料庫設計的。
但如果你還在糾結，我會建議嘗試下在兩者之間新增關係鍵，回到Mongo-relation User-> Address schema將地址ID新增到User集合中作為嵌入，因為在某些情況下基於的“使用者”地址ID。他更容易檢索。Mongo-relation 允許每個集合庫快速檢索但是當你開始得到關係時，它會急劇減速，因為沒有關聯，為了得到關係就需要多次呼叫資料庫。也可以加速通過批量檢索資料然後加入相關集合來查詢，但是後面這種方法，因為它可以使你的應用程式不可用，特別是如果使用單執行緒技術like NodeJs.像NodeJs。
使用聚合時，Mongo-flat變得非常慢。 大多數情況這可能是唯一選擇，特別是如果嘗試.檢索嵌入式關係。作為Sql語言聚合框架不夠強大。因此對於某些查詢，需要進行多次查詢以實現最終結果。 所以之間的關係越深入就會變得非常複雜。
使用Sql語言，它非常強大且易於編寫，允許建立許多表關聯; 它還包含了邏輯進入資料庫，例如：表關聯完成了資料庫級別而不是應用程式級別。
MySql可以慢嗎？是的。但在我看來，這是因為低階的工程圖表。有很多公司很多年來一直使用MySql作為他們的主要資料儲存，因為它顯示了良好的基準。
Mongo和MySql都是很棒的技術。他們都有他們自己服務的目的。即使這樣我們就應該替換另一個嗎？絕對不。就像我之前說過MongoDb適用於過渡資料，日誌，通知訊息等。MySql適用於業務資料儲存，報告，關係資料等 。
在我的思想中我發現MongoDb用作關聯式資料庫的地方失敗的。同樣，糟糕的決定會讓你失敗。 不要用MongoDb用於關係資料 - 這不是MongoDb的目的。
我可以繼續描述MongoDb和MySql，但我會在此停止讓你做決定。我做了我的研究，你做了你的。但是，每一項技術都能達到目的。
這是一件有趣的事實。
能力有限，翻譯的不是很好，請多指正。
原文地址：https://medium.com/@atasciuc/mongodb-vs-mysql-nodejs-paradigm-8bd21159075c
如果不能直接檢視原文，附上附件：https://pan.baidu.com/s/1f17Y7d7Wz2oJnAh5A5D0-A