初步的鍵值比較，MongoDB勝出

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

避免使用磁盤(pán)，盡可能的以?xún)?nèi)存替代

用更快的磁盤(pán)(如SSD)

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

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

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

大量的原材料要寫(xiě)入磁盤(pán)

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

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

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

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

言歸正傳，我的服務(wù)器(8核心的AMD CPU和16GB RAM)已經(jīng)就緒。將對(duì)擁有InnoDB儲(chǔ)存引擎的MySQL、MySQL Cluster及MongoDB進(jìn)行測(cè)試。測(cè)試的項(xiàng)目是在同等情況下10次對(duì)分布在100個(gè)線(xiàn)程上100萬(wàn)行數(shù)據(jù)進(jìn)行讀取。為了公平起見(jiàn)，必須確保我需要安裝進(jìn)內(nèi)存的數(shù)據(jù)已經(jīng)被放在內(nèi)存上，所以先試運(yùn)行了兩次。NDB情況下，將使用MySQL API(NDBAPI將在最后進(jìn)行測(cè)試)。結(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越來(lái)越便宜的時(shí)代，請(qǐng)移除那該死的512M設(shè)定!

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

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

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

MongoDB110000 rows read per second

InnoDB 39000 rows read per second

NDB 32000 rows read per second

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

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

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

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

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

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

磁盤(pán)系統(tǒng)：因?yàn)闆](méi)有磁盤(pá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è)線(xiàn)程上的100萬(wàn)數(shù)據(jù)的讀入，確保了不會(huì)受到磁盤(pán)I/O影響后，得出的測(cè)試結(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)無(wú)疑是令人失望的!然后在測(cè)試中還發(fā)現(xiàn)MylSAM只緩存自己的鍵，而不是整個(gè)數(shù)據(jù)。但是MylSAM表現(xiàn)還是值得贊許的，自始至終都沒(méi)有發(fā)現(xiàn)磁盤(pán)I/O。在解決了這個(gè)問(wèn)題我們看一下結(jié)果：

MySQL with MyISAM 37000 rows read per second

MySQL勝出

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

MySQL with MEMORY/HEAP：43000 rows read per second

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

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

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

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

MySQL with NDB(不使用CLIENT_COMPRESS46000 rows per second

NDB 32000 rows read per second

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

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

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