MySQL vs MongoDB 各有勝負！
初步的鍵值比較，MongoDB勝出
快還要更快，這一直都是我們給予數據庫系統的目標MySQL Dragster把磁盤的速度當作它的最大障礙，這真的能說通嗎?姑且就把作一個障礙，那解決方案呢?!如果一個障礙限制了你的Dragster，你完全可以選擇更快的繞過它或者在計算機方面提升。舉個例子：
避免使用磁盤，盡可能的以內存替代
用更快的磁盤(如SSD)
其實上面這對類比并不好，因為來自磁盤的限制是如此之大，而且出人意料的是從未得到過改善。你可能會說，我們不是有SSD嗎?對，這的確讓硬盤得到了提升，但是別忘了：CPU和RAM提升的速度比之硬盤來的更快!但是不妨假設一下，我們的內存大到可以直接取代硬盤了，那么一切就運行的與光一樣快了?顯然不是，所以不要再露出硬盤是你最大限制的丑惡嘴臉了!
如同CPU核心的提升速度越來越快，有一天突然不再像以前提升的那么迅速了。為了解決這個問題，多核心技術誕生。然而限制新CPU性能的問題接踵而至，成為了最令人頭痛的問題!比如線程的互斥!又比如MySQL里的Query Cache互斥!
言歸正傳，現在終于可以開始測試在5月擬定的基準了(英語文獻)。這里說一下為什么這么久才開始，因為把數據加載到MySQL中花了很多的時間。在這個過程中，我創建了一個開源項目，用于把JSON中的數據導出來然后導進MySQL中。這項工作完成后，我就擁有了以現實世界規則分類的數據。在這里，還必須得刪除一些列從而MySQL就可以處理這些數據了，因為MySQL Cluster只能在磁盤上存儲定長的數據。這個給我來了很大的工作量：
大量的原材料要寫入磁盤
UTF-8編碼更意味著3倍以上的數據要寫入
這樣就保證了MySQL Cluster的良好的運作，但是還有一些特殊的情況，這個取決于值的類型。假如值的類型是文本或者類，那么我們還必須使用VARCHAR或者類似的格式，這些才真正的限制了MySQL Cluster。為了讓MySQL運行的更加完美，只能創建很簡單的表格：
在這張表格里，加載了大約1.05億行數據。這對于MySQL Cluster來說應該是小菜一碟，對吧?但是還要除下MySQL Cluster只支持每部分512MB哈希數據(真正愚蠢的限制)。萬般無奈之下只能把數據分成5個部分，這一部分工作也算是完成了。
不得不說，沒有磁盤數據，MySQL Cluster運作起來穩定了很多。偶爾的數據丟失和其他古怪在加載VARCHAR格式數據表格時都沒有發生。因此，不僅是磁盤上的數據限制了你，你的數據類型(VARCHAR)看起來也需要進一步的完善。
言歸正傳，我的服務器(8核心的AMD CPU和16GB RAM)已經就緒。將對擁有InnoDB儲存引擎的MySQL、MySQL Cluster及MongoDB進行測試。測試的項目是在同等情況下10次對分布在100個線程上100萬行數據進行讀取。為了公平起見，必須確保我需要安裝進內存的數據已經被放在內存上，所以先試運行了兩次。NDB情況下，將使用MySQL API(NDBAPI將在最后進行測試)。結果如下：
MongoDB 110000 rows read per second
MySQL with InnoDB 30000 rows read per second
MySQL with NDB 32000 rows read per second
在NDB情況下下，先做以下設置：
可以明確告訴你，在這種模式下產生了巨大的差別。加載普通數據，結果也是相似的。但是當加載JSON(JSON是MongoDB的本土文件形式)的時候，預期中的事情發生了，MongoDB的速度比NDB/InnoDB快 2.5倍，而NDB/InnoDB兩者相當。
總結：
在RAM越來越便宜的時代，請移除那該死的512M設定!
鍵值對比的更正與添加，MongoDB依舊勝出
首先，與上面完全相同的測試環境;其次，都使用單一表;最后在MySQL中分別使用InnoDB和NDB兩種處理引擎。測試對100萬行數據的讀取(表格大小總計1.05億)。同樣是10次分布在100個線程上，總計1000萬行數據讀入。
經過了一些檢查以后發現，InnoDB引擎沒有完全緩存，更正以后測試結果如下：
MongoDB110000 rows read per second
InnoDB 39000 rows read per second
NDB 32000 rows read per second
在這次對決中MongoDB仍處于絕對優勢，并且InnoDB也明顯比NDB來的快。
特定環境的鍵值對比，MySQL曙光乍現
MySQL的成熟度遠非MongoDB能比，當把MongoDB放到硬盤上就會發現其速度衰退的厲害。假如我們擁有足夠量的內存(我們把它放到Amazon上，那里有足夠多的內存使用)，是否意味著不產生任何磁盤I/O它就會有很好的表現?
選出一個MongoDB數據存儲，同樣有1.05億行數據。最初我打算使用全部的MongoDB數據存儲，但必須排除其中像VARCHAR格式的數據而且通過NDB把數據放到磁盤上將消耗很多的磁盤I/O，確保NDB存儲數據將是定長后(所以一個UTF-8 VARCHAR(256)字段將占據768字節)。制作表格模式如下：
結束上面的工作，測試控制臺還需要一些工具：
CPU:AMD FX-8120 8核 內存：16G;主板：M5A88-V(使用Lite-On LINE100TX網卡替代了主板搭載的Realtek芯片組)
磁盤系統：因為沒有磁盤I/O，不做介紹
Ubuntu 10.10
MySQL 5.6.5 64-bit
MySQL Cluster 7.2.6 64-bit
MongoDB 2.0.5 64-bit
同樣是10次分布在100個線程上的100萬數據的讀入，確保了不會受到磁盤I/O影響后，得出的測試結果是：
MongoDB 110000 rows read per second
MySQL Cluster 32000 rows read per second
MySQL with InnoDB 39000 rows read per second
MySQL with MEMORY/HEAP 43000 rows read per second
MySQL with MylSAM 28000 rows read per second
MySQL在最后兩項的表現無疑是令人失望的!然后在測試中還發現MylSAM只緩存自己的鍵，而不是整個數據。但是MylSAM表現還是值得贊許的，自始至終都沒有發現磁盤I/O。在解決了這個問題我們看一下結果：
MySQL with MyISAM 37000 rows read per second
MySQL勝出
之后我們又測試了一些其他情況，比如：使用NDB而不使用CLIENT_COMPRESS。但是對比了MongoDB的11萬，MySQL表現依舊毫無起色?？偨Y下MySQL在不斷嘗試中的最好表現:
MySQL with MEMORY/HEAP：43000 rows read per second
MySQL with NDB(不使用CLIENT_COMPRESS)：46000 rows per second
雖然沒有測試所有組合，但是依據上邊兩條結果不難推斷出：當MySQL在使用MEMORY存儲引擎和CLIENT_COMPRESS的情況下不使用MySQL Storage Engines，速度肯定快于4.3萬。
不難預計這種情況下MySQL將對CPU造成很高的負載。因為一切都在內存中沒有了磁盤I/O，那么這里可能束縛MySQL的就只剩下了CPU。所以我們繞過標準服務器使用MySQL Cluster，直接訪問NDBAPI。這樣得到了更好的表現9萬，然而這還是落后于MongoDB。
綜合上面的測試，我們還會發現：
MySQL with NDB(不使用CLIENT_COMPRESS46000 rows per second
NDB 32000 rows read per second
我們是否可以認為CLIENT_COMPRESS是個“害蟲”?是否可以推測CLIENT_COMPRESS會把速度降低25%-30%?!想看看客戶端的消耗到底是多少，最簡單的辦法就是使用libmysqld —MySQL Embedded Library。這樣我們就要對基準程序進行改變，在開始測試前同樣要確保數據已經被寫入內存。準備就緒后開始測試，然而得出的結果正如我們推測的一樣。11.5萬!MySQL終于取得了勝利!
總結：這里沒有勝者，只有不斷的提高
之后還測試出了MySQL 17.2萬的飛速，但是把這個作為戰勝MongoDB的依據無疑十分牽強。是的，在這里我們看到的不是勝負，而是MongoDB的來勢洶洶及MySQL還擁有的巨大提升空間。
