初步的鍵值比較，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表現依舊毫無起色。總結下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終於取得了勝利!
總結：這裡沒有勝者，只有不斷的提高
誰成了誰的過客，誰成了誰的永遠！
今天凌晨做了乙個夢，一夢醒來回味，發覺心有一種痠痛，淚在眼眶中。夢是這樣的 我好像是快要結婚了，班長明濤 也許他對我已經沒有了記憶 帶著他媳婦王愛英還有一幫連邦的同學來看我，還有乙個我已經沒有了映像的同學硬要向我塞錢 呵呵，所說夢中見到錢可不是什麼好事 我說不要不要，你結婚我又沒去過，大家聚聚就行了...
誰建立，誰釋放
恕我愚見，雲風大哥的一些觀點我不認同。c 是面向對像程式設計，其意是我只需要知道你的這個對像，不用管你內部是如何實現的，把交待好的事情給你辦，你把辦好的結果給我就行了。這樣就能減少邏輯的複雜性，不必事事親躬。就拿上面所說結構內部的data成員的生命週期來說，如果data是你的struct結構建立出來...
誰是誰的誰
目前，我們的工作面臨了很多的困難，從中不僅感嘆世道炎涼。不可不說，這個世界上忘恩負義之徒太多了，只要你侵犯了他們一點的利益，他們就會不顧往日的恩義，刀兵相向，不客氣地說，這個世界90 以上的人都屬於這個型別，淒涼否？應該是的，這個世界是如此的黑，我們是不是就害怕呢？是不是就不要踏入到社會呢？那你也太...