【譯】MongoDb vs Mysql—以NodeJs為例
親愛的讀者,您可能想知道為什麼要寫關于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 作者:Tynam.Yang出處:https://www.cnblogs.com/tynam/