MongoDB與MySQL的插入、查詢性能測試
7.1 平均每條數據的插入時間
先上張圖，來點直觀感受：
圖上數據橫坐標是平均每插入1000條數據所需要的時間，單位是秒。記住，是每1000條數據，不是每條數據哦。
總結：
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不愧是一種非常穩定的數據庫，無論在指定主鍵還是在不指定主鍵插入的情況下，其效率都差不了太多。
7.2 插入穩定性分析
插入穩定性是指，隨着數據量的增大，每插入一定量數據時的插入速率情況。
在本次測試中，我們把這個指標的規模定在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插入的時候，其性能的下降還是很厲害的。
7.3 MySQL與MongoDB讀取性能的簡單測試
這是一個附加的測試，也並沒有測試得非常完整，但還是很能說明一些問題的。
測試方法：
先在1 – 100, 000, 000這一億個數中，分別隨機取1w, 5w, 10w, 20w, 50w個互不相同的數字，再計算其md5值，並保存。
至於為什么最高只選到50w這個規模，這是因為我在隨機生成100w個互不相同的數字的時候，寫的腳本跑了一晚上都沒有跑出來，估計是我生成的算法寫得太爛了。我不想重新再弄了，暫就以50w為上限吧。
在上述帶主鍵插入的兩個數據庫里，分別以上一步生成的md5源為輸入進行查詢操作。同樣，每查詢1000條數據在日志文件中將當前系統時間寫入。
測試結果：
以下三張圖的橫坐標是每查詢1000條數據所需要的時間，單位為s；縱坐標是查詢的規模，分為1w, 5w,10w, 20w, 50w五個等級。
這張圖是詳細對比，可以看出MySQL與MongoDB之間的差異了嗎……
總結：
1. 在讀取的數據規模不大時，MongoDB的查詢速度真是一騎絕塵，甩開MySQL好遠好遠。
2. 在查詢的數據量逐漸增多的時候，MySQL的查詢速度是穩步下降的，而MongoDB的查詢速度卻有些起伏。
分析：
1. 如果MySQL沒有經過查詢優化的話，其查詢速度就不要跟MongoDB比了。MongoDB可以充分利用系統的內存資源，我們的測試機器內存是64GB的，內存越大MongoDB的查詢速度就越快，畢竟磁盤與內存的I/O效率不是一個量級的。
2. 本次實驗的查詢的數據也是隨機生成的，因此所有待查詢的數據都存在MongoDB的內存緩存中的概率是很小的。在查詢時，MongoDB需要多次將內存中的數據與磁盤進行交互以便查找，因此其查詢速率取決於其交互的次數。這樣就存在這樣一種可能性，盡管待查詢的數據數目較多，但這段隨機生成的數據被MongoDB以較少的次數從磁盤中取出。因此，其查詢的平均速度反而更快一些。這樣看來，MongoDB的查詢速度波動也處在一個合理的范圍內。
3. MySQL的穩定性還是毋庸置疑的。
8. 測試總結
8.1 測試結論
1. 相比較MySQL，MongoDB數據庫更適合那些讀作業較重的任務模型。MongoDB能充分利用機器的內存資源。如果機器的內存資源豐富的話，MongoDB的查詢效率會快很多。
2. 在帶”_id”插入數據的時候，MongoDB的插入效率其實並不高。如果想充分利用MongoDB性能的話，推薦采取不帶”_id”的插入方式，然后對相關字段作索引來查詢。
8.2 測試需要進一步注意的問題
對MongoDB的讀取測試考慮不周，雖然這只是一個額外的測試。在這個測試中，隨機生成大量待測試的數據很有必要，但生成大量互不相同的數據就沒有必要了。正是這一點，把我的讀取測試規模限定在了50w條，沒能進一步進行分析。
8.3 MongoDB的優勢
1. MongoDB適合那些對數據庫具體數據格式不明確或者數據庫數據格式經常變化的需求模型，而且對開發者十分友好。
2. MongoDB官方就自帶一個分布式文件系統，可以很方便地部署到服務器機群上。MongoDB里有一個Shard的概念，就是方便為了服務器分片使用的。每增加一台Shard，MongoDB的插入性能也會以接近倍數的方式增長，磁盤容量也很可以很方便地擴充。
3. MongoDB還自帶了對map-reduce運算框架的支持，這也很方便進行數據的統計。
其他方面的優勢還在發掘中，本人也是剛剛接觸這個不久。
8.4 MongoDB的缺陷
1. 事務關系支持薄弱。這也是所有NoSQL數據庫共同的缺陷，不過NoSQL並不是為了事務關系而設計的，具體應用還是很需求。
2. 穩定性有些欠缺，這點從上面的測試便可以看出。
3. MongoDB一方面在方便開發者的同時，另一方面對運維人員卻提出了相當多的要求。業界並沒有成熟的MongoDB運維經驗，MongoDB中數據的存放格式也很隨意，等等問題都對運維人員的考驗。