【代碼周邊】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插入的時候，其性能的降低仍是很厲害的。

1.       在讀取的數據規模不大時，MongoDB的查詢速度真是一騎絕塵，甩開MySQL好遠好遠。

2.       在查詢的數據量逐漸增多的時候，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」的插入方式，而後對相關字段做索引來查詢。

1. MongoDB適合那些對數據庫具體數據格式不明確或者數據庫數據格式常常變化的需求模型，並且對開發者十分友好。

2. MongoDB官方就自帶一個分佈式文件系統，能夠很方便地部署到服務器機羣上。MongoDB裏有一個Shard的概念，就是方便爲了服務器分片使用的。每增長一臺Shard，MongoDB的插入性能也會以接近倍數的方式增加，磁盤容量也很能夠很方便地擴充。

3. MongoDB還自帶了對map-reduce運算框架的支持，這也很方便進行數據的統計。

 

MongoDB的缺陷

1. 事務關係支持薄弱。這也是全部NoSQL數據庫共同的缺陷，不過NoSQL並非爲了事務關係而設計的，具體應用仍是很需求。

2. 穩定性有些欠缺，這點從上面的測試即可以看出。

3. MongoDB一方面在方便開發者的同時，另外一方面對運維人員卻提出了至關多的要求。業界並無成熟的MongoDB運維經驗，MongoDB中數據的存放格式也很隨意，等等問題都對運維人員的考驗。

 

參考原文：撒哈拉的雪：https://www.cnblogs.com/web-fusheng/p/6884759.html