大家好，又見面了，我是你們的朋友全棧君。
本篇文章給大家帶來的内容是關于Mongodb與MySQL之間的比較分析，有一定的參考價值，有需要的朋友可以參考一下，希望對你有所幫助。
在資料庫存放的資料中，有一種特殊的鍵值叫做主鍵，它用于惟一地辨別表中的某一條記錄。也就是說，一個表不能有多個主鍵，并且主鍵不能為空值。無論是MongoDB還是MySQL，都存在着主鍵的定義。
對于MongoDB來說，其主鍵名叫”_id”，在生成資料的時候，如果使用者不主動為其配置設定一個主鍵的話，MongoDB會自動為其生成一個随機配置設定的值。
在MySQL中，主鍵的指定是在MySQL插入資料時指明PRIMARY KEY來定義的。當沒有指定主鍵的時候，另一種工具 —— 索引，相當于替代了主鍵的功能。索引可以為空，也可以有重複，另外有一種不允許重複的索引叫惟一索引。如果既沒有指定主鍵也沒有指定索引的話，MySQL會自動為資料建立一個。
存儲速度對比
1、資料庫的平均插入速率：MongoDB不指定_id插入 > MySQL不指定主鍵插入 > MySQL指定主鍵插入 > MongoDB指定_id插入。
2、MongoDB在指定_id與不指定_id插入時速度相差很大，而MySQL的差别卻小很多。
分析：
1、在指定_id或主鍵時，兩種資料庫在插入時要對索引值進行處理，并查找資料庫中是否存在相同的鍵值，這會減慢插入的速率。
2、在MongoDB中，指定索引插入比不指定慢很多，這是因為，MongoDB裡每一條資料的_id值都是唯一的。當在不指定_id插入資料的時候，其_id是系統自動計算生成的。MongoDB通過計算機特征值、時間、程序ID與随機數來確定生成的_id是唯一的。而在指定_id插入時，MongoDB每插一條資料，都需要檢查此_id可不可用，當資料庫中資料條數太多的時候，這一步的查詢開銷會拖慢整個資料庫的插入速度。
3、MongoDB會充分使用系統記憶體作為緩存，這是一種非常優秀的特性。我們的測試機的記憶體有64G，在插入時，MongoDB會盡可能地在記憶體快寫不進去資料之後，再将資料持久化儲存到硬碟上。這也是在不指定_id插入的時候，MongoDB的效率遙遙領先的原因。但在指定_id插入時，當資料量一大記憶體裝不下時，MongoDB就需要将磁盤中的資訊讀取到記憶體中來查重，這樣一來其插入效率反而慢了。
4、MySQL不愧是一種非常穩定的資料庫，無論在指定主鍵還是在不指定主鍵插入的情況下，其效率都差不了太多。
插入穩定性分析
插入穩定性是指，随着資料量的增大，每插入一定量資料時的插入速率情況。
在本次測試中，我們把這個名額的規模定在10w，即顯示的資料是在每插入10w條資料時，在這段時間内每秒鐘能插入多少條資料。
先呈現四張圖上來：
1、 MongoDB指定_id插入：
2、 MongoDB不指定_id插入：
3、 MySQL指定PRIMARY KEY插入：
4、 MySQL不指定PRIMARY KEY插入：
總結：
1、整體上的插入速度還是和上一回的統計資料類似：MongoDB不指定_id插入 > MySQL不指定主鍵插入 > MySQL指定主鍵插入 > MongoDB指定_id插入。
2、從圖中可以看出，在指定主鍵插入資料的時候，MySQL與MongoDB在不同資料數量級時，每秒插入的資料每隔一段時間就會有一個波動，在圖表中顯示成為規律的毛刺現象。而在不指定插入資料時，在大多數情況下插入速率都比較平均，但随着資料庫中資料的增多，插入的效率在某一時段有瞬間下降，随即又會變穩定。
3、整體上來看，MongoDB的速率波動比MySQL的嚴重，方差變化較大。
4、MongoDB在指定_id插入時，當插入的資料變多之後，插入效率有明顯地下降。在其他三種的插入測試中，從開始到結束，其插入的速率在大多數的時候都固定在一個标準上。
分析：
1、毛刺現象是因為，當插入的資料太多的時候，MongoDB需要将記憶體中的資料寫進硬碟，MySQL需要重新分表。這些操作每當資料庫中的資料達到一定量級後就會自動進行，是以每隔一段時間就會有一個明顯的毛刺。
2、MongoDB畢竟還是新生事物，其穩定性沒有已應用多年的MySQL優秀。
3、MongoDB在指定_id插入的時候，其性能的下降還是很厲害的。
4、在讀取的資料規模不大時，MongoDB的查詢速度真是一騎絕塵，甩開MySQL好遠好遠。
5、在查詢的資料量逐漸增多的時候，MySQL的查詢速度是穩步下降的，而MongoDB的查詢速度卻有些起伏。
分析：
1、如果MySQL沒有經過查詢優化的話，其查詢速度就不要跟MongoDB比了。MongoDB可以充分利用系統的記憶體資源，我們的測試機器記憶體是64GB的，記憶體越大MongoDB的查詢速度就越快，畢竟磁盤與記憶體的I/O效率不是一個量級的。
2、本次實驗的查詢的資料也是随機生成的，是以所有待查詢的資料都存在MongoDB的記憶體緩存中的機率是很小的。在查詢時，MongoDB需要多次将記憶體中的資料與磁盤進行互動以便查找，是以其查詢速率取決于其互動的次數。這樣就存在這樣一種可能性，盡管待查詢的資料數目較多，但這段随機生成的資料被MongoDB以較少的次數從磁盤中取出。是以，其查詢的平均速度反而更快一些。這樣看來，MongoDB的查詢速度波動也處在一個合理的範圍内。
3、MySQL的穩定性還是毋庸置疑的。
結論
1、相比較MySQL，MongoDB資料庫更适合那些讀作業較重的任務模型。MongoDB能充分利用機器的記憶體資源。如果機器的記憶體資源豐富的話，MongoDB的查詢效率會快很多。
2、在帶”_id”插入資料的時候，MongoDB的插入效率其實并不高。如果想充分利用MongoDB性能的話，推薦采取不帶”_id”的插入方式，然後對相關字段作索引來查詢。
3、MongoDB适合那些對資料庫具體資料格式不明确或者資料庫資料格式經常變化的需求模型，而且對開發者十分友好。
4、MongoDB官方就自帶一個分布式檔案系統，可以很友善地部署到伺服器機群上。MongoDB裡有一個Shard的概念，就是友善為了伺服器分片使用的。每增加一台Shard，MongoDB的插入性能也會以接近倍數的方式增長，磁盤容量也很可以很友善地擴充。
5、MongoDB還自帶了對map-reduce運算架構的支援，這也很友善進行資料的統計。
MongoDB的缺陷
1、事務關系支援薄弱。這也是所有NoSQL資料庫共同的缺陷，不過NoSQL并不是為了事務關系而設計的，具體應用還是很需求。
2、穩定性有些欠缺，這點從上面的測試便可以看出。
3、MongoDB一方面在友善開發者的同時，另一方面對運維人員卻提出了相當多的要求。業界并沒有成熟的MongoDB運維經驗，MongoDB中資料的存放格式也很随意，等等問題都對運維人員的考驗。
釋出者：全棧程式員棧長，轉載請注明出處：https://javaforall.cn/149221.html原文連結：https://javaforall.cn