摘要：通過計算機特征值時間進程與隨機數(shù)來確保生成的是唯一的。整體上來看，的速率波動比的嚴重，方差變化較大。的缺陷事務(wù)關(guān)系支持薄弱。一方面在方便開發(fā)者的同時，另一方面對運維人員卻提出了相當多的要求。

在數(shù)據(jù)庫存放的數(shù)據(jù)中，有一種特殊的鍵值叫做主鍵，它用于惟一地標識表中的某一條記錄。也就是說，一個表不能有多個主鍵，并且主鍵不能為空值。無論是MongoDB還是MySQL，都存在著主鍵的定義。
對于MongoDB來說，其主鍵名叫”_id”，在生成數(shù)據(jù)的時候，如果用戶不主動為其分配一個主鍵的話，MongoDB會自動為其生成一個隨機分配的值。

在MySQL中，主鍵的指定是在MySQL插入數(shù)據(jù)時指明PRIMARY KEY來定義的。當沒有指定主鍵的時候，另一種工具 —— 索引，相當于替代了主鍵的功能。索引可以為空，也可以有重復(fù)，另外有一種不允許重復(fù)的索引叫惟一索引。如果既沒有指定主鍵也沒有指定索引的話，MySQL會自動為數(shù)據(jù)創(chuàng)建一個。

插入穩(wěn)定性是指，隨著數(shù)據(jù)量的增大，每插入一定量數(shù)據(jù)時的插入速率情況。

在本次測試中，我們把這個指標的規(guī)模定在10w，即顯示的數(shù)據(jù)是在每插入10w條數(shù)據(jù)時，在這段時間內(nèi)每秒鐘能插入多少條數(shù)據(jù)。

先呈現(xiàn)四張圖上來：
1. MongoDB指定_id插入：

2. MongoDB不指定_id插入：

3. MySQL指定PRIMARY KEY插入：

4. MySQL不指定PRIMARY KEY插入：

整體上的插入速度還是和上一回的統(tǒng)計數(shù)據(jù)類似：MongoDB不指定_id插入 > MySQL不指定主鍵插入 > MySQL指定主鍵插入 > MongoDB指定_id插入。

從圖中可以看出，在指定主鍵插入數(shù)據(jù)的時候，MySQL與MongoDB在不同數(shù)據(jù)數(shù)量級時，每秒插入的數(shù)據(jù)每隔一段時間就會有一個波動，在圖表中顯示成為規(guī)律的毛刺現(xiàn)象。而在不指定插入數(shù)據(jù)時，在大多數(shù)情況下插入速率都比較平均，但隨著數(shù)據(jù)庫中數(shù)據(jù)的增多，插入的效率在某一時段有瞬間下降，隨即又會變穩(wěn)定。

整體上來看，MongoDB的速率波動比MySQL的嚴重，方差變化較大。

MongoDB在指定_id插入時，當插入的數(shù)據(jù)變多之后，插入效率有明顯地下降。在其他三種的插入測試中，從開始到結(jié)束，其插入的速率在大多數(shù)的時候都固定在一個標準上。

毛刺現(xiàn)象是因為，當插入的數(shù)據(jù)太多的時候，MongoDB需要將內(nèi)存中的數(shù)據(jù)寫進硬盤，MySQL需要重新分表。這些操作每當數(shù)據(jù)庫中的數(shù)據(jù)達到一定量級后就會自動進行，因此每隔一段時間就會有一個明顯的毛刺。

MongoDB畢竟還是新生事物，其穩(wěn)定性沒有已應(yīng)用多年的MySQL優(yōu)秀。

MongoDB在指定_id插入的時候，其性能的下降還是很厲害的。

在讀取的數(shù)據(jù)規(guī)模不大時，MongoDB的查詢速度真是一騎絕塵，甩開MySQL好遠好遠。

在查詢的數(shù)據(jù)量逐漸增多的時候，MySQL的查詢速度是穩(wěn)步下降的，而MongoDB的查詢速度卻有些起伏。

如果MySQL沒有經(jīng)過查詢優(yōu)化的話，其查詢速度就不要跟MongoDB比了。MongoDB可以充分利用系統(tǒng)的內(nèi)存資源，我們的測試機器內(nèi)存是64GB的，內(nèi)存越大MongoDB的查詢速度就越快，畢竟磁盤與內(nèi)存的I/O效率不是一個量級的。

本次實驗的查詢的數(shù)據(jù)也是隨機生成的，因此所有待查詢的數(shù)據(jù)都存在MongoDB的內(nèi)存緩存中的概率是很小的。在查詢時，MongoDB需要多次將內(nèi)存中的數(shù)據(jù)與磁盤進行交互以便查找，因此其查詢速率取決于其交互的次數(shù)。這樣就存在這樣一種可能性，盡管待查詢的數(shù)據(jù)數(shù)目較多，但這段隨機生成的數(shù)據(jù)被MongoDB以較少的次數(shù)從磁盤中取出。因此，其查詢的平均速度反而更快一些。這樣看來，MongoDB的查詢速度波動也處在一個合理的范圍內(nèi)。

MySQL的穩(wěn)定性還是毋庸置疑的。

相比較MySQL，MongoDB數(shù)據(jù)庫更適合那些讀作業(yè)較重的任務(wù)模型。MongoDB能充分利用機器的內(nèi)存資源。如果機器的內(nèi)存資源豐富的話，MongoDB的查詢效率會快很多。

在帶”_id”插入數(shù)據(jù)的時候，MongoDB的插入效率其實并不高。如果想充分利用MongoDB性能的話，推薦采取不帶”_id”的插入方式，然后對相關(guān)字段作索引來查詢。

MongoDB適合那些對數(shù)據(jù)庫具體數(shù)據(jù)格式不明確或者數(shù)據(jù)庫數(shù)據(jù)格式經(jīng)常變化的需求模型，而且對開發(fā)者十分友好。

MongoDB官方就自帶一個分布式文件系統(tǒng)，可以很方便地部署到服務(wù)器機群上。MongoDB里有一個Shard的概念，就是方便為了服務(wù)器分片使用的。每增加一臺Shard，MongoDB的插入性能也會以接近倍數(shù)的方式增長，磁盤容量也很可以很方便地擴充。

MongoDB還自帶了對map-reduce運算框架的支持，這也很方便進行數(shù)據(jù)的統(tǒng)計。

事務(wù)關(guān)系支持薄弱。這也是所有NoSQL數(shù)據(jù)庫共同的缺陷，不過NoSQL并不是為了事務(wù)關(guān)系而設(shè)計的，具體應(yīng)用還是很需求。

穩(wěn)定性有些欠缺，這點從上面的測試便可以看出。

MongoDB一方面在方便開發(fā)者的同時，另一方面對運維人員卻提出了相當多的要求。業(yè)界并沒有成熟的MongoDB運維經(jīng)驗，MongoDB中數(shù)據(jù)的存放格式也很隨意，等等問題都對運維人員的考驗。