初步的鍵值比較，MongoDB勝出

快還要更快，這一直都是我們給予數(shù)據(jù)庫系統(tǒng)的目標(biāo)MySQL Dragster把磁盤的速度當(dāng)作它的最大障礙，這真的能說通嗎?姑且就把作一個(gè)障礙，那解決方案呢?!如果一個(gè)障礙限制了你的Dragster，你完全可以選擇更快的繞過它或者在計(jì)算機(jī)方面提升。舉個(gè)例子：

避免使用磁盤，盡可能的以內(nèi)存替代

用更快的磁盤(如SSD)

其實(shí)上面這對類比并不好，因?yàn)閬碜源疟P的限制是如此之大，而且出人意料的是從未得到過改善。你可能會說，我們不是有SSD嗎?對，這的確讓硬盤得到了提升，但是別忘了：CPU和RAM提升的速度比之硬盤來的更快!但是不妨假設(shè)一下，我們的內(nèi)存大到可以直接取代硬盤了，那么一切就運(yùn)行的與光一樣快了?顯然不是，所以不要再露出硬盤是你最大限制的丑惡嘴臉了!

如同CPU核心的提升速度越來越快，有一天突然不再像以前提升的那么迅速了。為了解決這個(gè)問題，多核心技術(shù)誕生。然而限制新CPU性能的問題接踵而至，成為了最令人頭痛的問題!比如線程的互斥!又比如MySQL里的Query Cache互斥!

言歸正傳，現(xiàn)在終于可以開始測試在5月擬定的基準(zhǔn)了(英語文獻(xiàn))。這里說一下為什么這么久才開始，因?yàn)榘褦?shù)據(jù)加載到MySQL中花了很多的時(shí)間。在這個(gè)過程中，我創(chuàng)建了一個(gè)開源項(xiàng)目，用于把JSON中的數(shù)據(jù)導(dǎo)出來然后導(dǎo)進(jìn)MySQL中。這項(xiàng)工作完成后，我就擁有了以現(xiàn)實(shí)世界規(guī)則分類的數(shù)據(jù)。在這里，還必須得刪除一些列從而MySQL就可以處理這些數(shù)據(jù)了，因?yàn)镸ySQL Cluster只能在磁盤上存儲定長的數(shù)據(jù)。這個(gè)給我來了很大的工作量：

大量的原材料要寫入磁盤

UTF-8編碼更意味著3倍以上的數(shù)據(jù)要寫入

這樣就保證了MySQL Cluster的良好的運(yùn)作，但是還有一些特殊的情況，這個(gè)取決于值的類型。假如值的類型是文本或者類，那么我們還必須使用VARCHAR或者類似的格式，這些才真正的限制了MySQL Cluster。為了讓MySQL運(yùn)行的更加完美，只能創(chuàng)建很簡單的表格：

在這張表格里，加載了大約1.05億行數(shù)據(jù)。這對于MySQL Cluster來說應(yīng)該是小菜一碟，對吧?但是還要除下MySQL Cluster只支持每部分512MB哈希數(shù)據(jù)(真正愚蠢的限制)。萬般無奈之下只能把數(shù)據(jù)分成5個(gè)部分，這一部分工作也算是完成了。

不得不說，沒有磁盤數(shù)據(jù)，MySQL Cluster運(yùn)作起來穩(wěn)定了很多。偶爾的數(shù)據(jù)丟失和其他古怪在加載VARCHAR格式數(shù)據(jù)表格時(shí)都沒有發(fā)生。因此，不僅是磁盤上的數(shù)據(jù)限制了你，你的數(shù)據(jù)類型(VARCHAR)看起來也需要進(jìn)一步的完善。

言歸正傳，我的服務(wù)器(8核心的AMD CPU和16GB RAM)已經(jīng)就緒。將對擁有InnoDB儲存引擎的MySQL、MySQL Cluster及MongoDB進(jìn)行測試。測試的項(xiàng)目是在同等情況下10次對分布在100個(gè)線程上100萬行數(shù)據(jù)進(jìn)行讀取。為了公平起見，必須確保我需要安裝進(jìn)內(nèi)存的數(shù)據(jù)已經(jīng)被放在內(nèi)存上，所以先試運(yùn)行了兩次。NDB情況下，將使用MySQL API(NDBAPI將在最后進(jìn)行測試)。結(jié)果如下：

MongoDB 110000 rows read per second

MySQL with InnoDB 30000 rows read per second

MySQL with NDB 32000 rows read per second

在NDB情況下下，先做以下設(shè)置：

可以明確告訴你，在這種模式下產(chǎn)生了巨大的差別。加載普通數(shù)據(jù)，結(jié)果也是相似的。但是當(dāng)加載JSON(JSON是MongoDB的本土文件形式)的時(shí)候，預(yù)期中的事情發(fā)生了，MongoDB的速度比NDB/InnoDB快 2.5倍，而NDB/InnoDB兩者相當(dāng)。

總結(jié)：

在RAM越來越便宜的時(shí)代，請移除那該死的512M設(shè)定!

鍵值對比的更正與添加，MongoDB依舊勝出

首先，與上面完全相同的測試環(huán)境;其次，都使用單一表;最后在MySQL中分別使用InnoDB和NDB兩種處理引擎。測試對100萬行數(shù)據(jù)的讀取(表格大小總計(jì)1.05億)。同樣是10次分布在100個(gè)線程上，總計(jì)1000萬行數(shù)據(jù)讀入。

經(jīng)過了一些檢查以后發(fā)現(xiàn)，InnoDB引擎沒有完全緩存，更正以后測試結(jié)果如下：

MongoDB110000 rows read per second

InnoDB 39000 rows read per second

NDB 32000 rows read per second

在這次對決中MongoDB仍處于絕對優(yōu)勢，并且InnoDB也明顯比NDB來的快。

特定環(huán)境的鍵值對比，MySQL曙光乍現(xiàn)

MySQL的成熟度遠(yuǎn)非MongoDB能比，當(dāng)把MongoDB放到硬盤上就會發(fā)現(xiàn)其速度衰退的厲害。假如我們擁有足夠量的內(nèi)存(我們把它放到Amazon上，那里有足夠多的內(nèi)存使用)，是否意味著不產(chǎn)生任何磁盤I/O它就會有很好的表現(xiàn)?

選出一個(gè)MongoDB數(shù)據(jù)存儲，同樣有1.05億行數(shù)據(jù)。最初我打算使用全部的MongoDB數(shù)據(jù)存儲，但必須排除其中像VARCHAR格式的數(shù)據(jù)而且通過NDB把數(shù)據(jù)放到磁盤上將消耗很多的磁盤I/O，確保NDB存儲數(shù)據(jù)將是定長后(所以一個(gè)UTF-8 VARCHAR(256)字段將占據(jù)768字節(jié))。制作表格模式如下：

結(jié)束上面的工作，測試控制臺還需要一些工具：

CPU:AMD FX-8120 8核 內(nèi)存：16G;主板：M5A88-V(使用Lite-On LINE100TX網(wǎng)卡替代了主板搭載的Realtek芯片組)

磁盤系統(tǒng)：因?yàn)闆]有磁盤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個(gè)線程上的100萬數(shù)據(jù)的讀入，確保了不會受到磁盤I/O影響后，得出的測試結(jié)果是：

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在最后兩項(xiàng)的表現(xiàn)無疑是令人失望的!然后在測試中還發(fā)現(xiàn)MylSAM只緩存自己的鍵，而不是整個(gè)數(shù)據(jù)。但是MylSAM表現(xiàn)還是值得贊許的，自始至終都沒有發(fā)現(xiàn)磁盤I/O。在解決了這個(gè)問題我們看一下結(jié)果：

MySQL with MyISAM 37000 rows read per second

MySQL勝出

之后我們又測試了一些其他情況，比如：使用NDB而不使用CLIENT_COMPRESS。但是對比了MongoDB的11萬，MySQL表現(xiàn)依舊毫無起色。總結(jié)下MySQL在不斷嘗試中的最好表現(xiàn):

MySQL with MEMORY/HEAP：43000 rows read per second

MySQL with NDB(不使用CLIENT_COMPRESS)：46000 rows per second

雖然沒有測試所有組合，但是依據(jù)上邊兩條結(jié)果不難推斷出：當(dāng)MySQL在使用MEMORY存儲引擎和CLIENT_COMPRESS的情況下不使用MySQL Storage Engines，速度肯定快于4.3萬。

不難預(yù)計(jì)這種情況下MySQL將對CPU造成很高的負(fù)載。因?yàn)橐磺卸荚趦?nèi)存中沒有了磁盤I/O，那么這里可能束縛MySQL的就只剩下了CPU。所以我們繞過標(biāo)準(zhǔn)服務(wù)器使用MySQL Cluster，直接訪問NDBAPI。這樣得到了更好的表現(xiàn)9萬，然而這還是落后于MongoDB。

綜合上面的測試，我們還會發(fā)現(xiàn)：

MySQL with NDB(不使用CLIENT_COMPRESS46000 rows per second

NDB 32000 rows read per second

我們是否可以認(rèn)為CLIENT_COMPRESS是個(gè)“害蟲”?是否可以推測CLIENT_COMPRESS會把速度降低25%-30%?!想看看客戶端的消耗到底是多少，最簡單的辦法就是使用libmysqld —MySQL Embedded Library。這樣我們就要對基準(zhǔn)程序進(jìn)行改變，在開始測試前同樣要確保數(shù)據(jù)已經(jīng)被寫入內(nèi)存。準(zhǔn)備就緒后開始測試，然而得出的結(jié)果正如我們推測的一樣。11.5萬!MySQL終于取得了勝利!

總結(jié)：這里沒有勝者，只有不斷的提高

之后還測試出了MySQL 17.2萬的飛速，但是把這個(gè)作為戰(zhàn)勝M(fèi)ongoDB的依據(jù)無疑十分牽強(qiáng)。是的，在這里我們看到的不是勝負(fù)，而是MongoDB的來勢洶洶及MySQL還擁有的巨大提升空間。