Coolhash當前性能指標：讀寫吞吐量超過百萬，千萬級別查詢1秒完成，連續48小時打滿CPU強壓力運行穩定。redis官方公布讀寫性能在10萬tps，leveldb官方公布寫性能在40萬tps，讀在6萬tps，redis和leveldb都是傾向k/v高速讀寫，但不具備高效檢索功能，沒有join關聯設計。coolhash可以拿去pk世界上任何的數據庫引擎產品。

下面以redis為例進行了詳細測試和技術分析，leveldb的性能可詳見其官方資料，在寫性能上優于redis，但是讀性能和多數據結構支持上不如redis，leveldb讀代價高是因為需要在內存以及各級數據文件逐項查找并要優先考慮數據最新狀態，另外redis還提供server和集群功能，leveldb不提供，redis是內存方式+內存快照持久化，而leveldb是Memtable+硬盤持久化，leveldb持久化不受內存限制，也做到了接近緩存的性能，未來k/v數據庫的趨勢最好能直接當作緩存使用，并能支持高效檢索功能。

按照redis的常用方式，我們在一臺服務器上進行redis“單server”和“多server”的測試：

從上面兩個圖，我們可以看到：

• redis是一個單進程單線程的實現，單server的讀寫TPS大概在8—12萬（跟redis官網公布的數據一致），為了充分利用能夠資源，redis官方建議一臺機器部署多個redis server。

• 上面第二個圖的TPS超過了8-12萬的限制，這實際上是在一臺服務器上部署了多個redis server，并將該服務器總的吞吐量算到一個redis server上得到的。但是寫的時候是客戶端各自寫不同的redis server，多個redis server之間的數據是彼此獨立的，在不同的內存空間中，如果分開計算每個redis server的寫入總量除以時間，TPS還是在8-12萬左右。

我們再到24核/256g/SATA硬盤的pc server上測試一下redis的benchmark，200個客戶端共寫入2000萬數據，發現性能變化不大，還是在10萬左右的TPS，又測試了20個客戶端寫入2000萬數據，12萬TPS：

Redis很優秀，但是也有一些局限：

• redis不是一個并行數據庫，由單進程單線程實現，已經做到了單進程極限，性能很難再突破。如果要重新改寫redis，代價很大，而且只有redis作者有能力做，其他外圍的捐獻者動不了。redis官方采取一種曲線救國方式，不改變單進程模式，采取外圍做集群，部署多個server來提高CPU利用率，redis3.0的集群方案使用一種hash slot算法（不是一致哈希），用多個redis server做數據分片存儲，按照crc16/16384取模方式，讓客戶端根據hash slot的配置尋址，擴容按照slot單位做數據遷移達到負載均衡。由于在同臺服務器也存在多server實例集群，會牽扯出很多server的master-slave復制和數據遷移一致性等復雜性，也容易引起后端的IO爭用，特別是在AOF模式時。

• redis是一種內存快照方式，也就意味著它的持久化大小受內存限制，不是真正的數據庫持久化存儲，內存是昂貴的，為了擴大內存存儲，往往需要更多的服務器搭建緩存集群，redis作者曾想增加一種diskstore的全持久化+cache方式，采用SHA1算法來建立存儲結構，來改進內存快照方式的種種不足，但是涉及到對redis底層持久化方式的重構，這個計劃從11年提出，截至到目前3.0版本，仍然還沒有提供。

• redis的存儲方式不是按照數據庫存儲索引結構設計，無法做到高性能的按范圍、按key/value的模糊檢索，更多只能在內存中進行全局數據的遍歷過濾，沒有高效的查詢功能，redis更適合做緩存讀寫，不適合當作數據庫存儲使用。

國內的redis使用團隊更多也是在運維工具、監控管理、主備、故障恢復等等方面改進，不具備對上面redis的3點內核局限的重構能力。

我們接下來在同機環境（24核/256g/SATA硬盤）測試coolhash，實際上coolhash也可以像上面redis那樣在一臺服務器上部署多個server實例，但是我們這里啟動一個coolhash就夠了。coolhash是一個并行數據庫引擎和數據庫server，可以通過調整“coolhash數據工人數量、客戶端并發數量、每客戶端讀寫數量”三個指標項達到一臺服務器的最佳吞吐量性能。

coolhash通過一組數據工人并行的完成任務，我們先測試一個coolhash啟動多少個數據工人最合適，下面在一臺服務器上運行coolhash并分別啟動1-96個工人，再用另外一臺服務器模擬了200個客戶端并發，每個客戶端寫入10萬數據，累計2000萬數據，數據格式key=n(0<n<2000萬)，value=n(0<n<2000萬)，平均大小在幾十字節左右，比上面redis的benchmark的每條數據3字節要大，客戶端和服務器在同一個局域網內，通過IP訪問。（注意：不要簡單的在一個jvm里以多線程模擬并發，如果客戶端包存在公共變量，容易引起混亂，應該啟動200個獨立客戶端）

測試1：x個數據工人，200個客戶端并發，每個客戶端寫入10萬數據

分析：可以清晰的看到并行數據庫的優勢明顯，如果只有一個數據工人，也就是單進程模式，它的TPS是很難超出10萬的，如果是8個數據工人并行作業，性能一下子就能從400秒減少到40秒，提升10倍，但也不是數據工人越多性能越好，我們看到24-32個工人是個頂峰，如果再增加工人數雖然能提升cpu使用率，但是調度開銷大，后端硬盤io等跟不上，導致性能反而有所下降。

根據上面的結論，我們配置coolhash啟動24個數據工人最合適，接下來再進一步調整“客戶端并發數”和“每個客戶端寫入數量”，來達到一臺服務器的最佳性能。

測試2：24個數據工人，x個客戶端并發，每個客戶端寫入10萬數據

分析：如果每個客戶端寫相同數量的數據，隨著并發數的提高，總體的吞吐量會高于單客戶端呈線性增長趨勢，但是受服務器cpu、內存、io等性能限制，不會一直增長，會傾向于一個平衡值。每臺服務器并不是能承受無限大的并發數量，如果超出了承受限制，客戶端會長時間等待，容易產生socket連接超時。合理的控制并發數量能提升服務器的吞吐性能，下面我們增大每個客戶端的寫入數量，減少總的并發數，并觀察效果。

測試3：24個數據工人，20個客戶端并發，每個客戶端寫入x萬數據

分析：可以看到同樣寫入2000萬數據，采用20并發*100萬比200并發*10萬的性能提升了一倍，能達到200萬以上TPS。這是因為客戶端建立連接后，一次提交100萬條數據的寫入請求，相比每條數據連接server，能很大節省網絡開銷和硬盤IO開銷。由此我們也能得到，并不是并發連接越多越好，而是控制一定數量的連接池性能會更好。

接下來我們再以使用相同參數，測試一下讀的性能。

測試4：24個數據工人，20個客戶端并發，每個客戶端讀出x萬數據

分析：coolhash是一個讀寫平衡的數據庫引擎，可以看到讀和寫的性能相差不大，都能達到200萬的TPS。

coolhash提供了高效的查詢檢索功能，可以支持key和value的同時模糊查詢，下面按照600萬—3億不同的數據總量進行模糊查詢，數據格式為key=n(0<n<3億)，value=n(0<n<3億)，模糊查詢value包括“8888888”的數據：

CoolHashResult hr = chc.find("*", ValueFilter.contains(“8888888”))

#p#

測試5：24個數據工人，x個客戶端模糊查詢x萬數據

單個客戶端模糊查詢：

多個客戶端高并發模糊查詢：

分析：對于千萬級別的數據，客戶端一次任意模糊查詢的耗時都是在1秒完成，如果超過1億需要2秒，3億需要6秒（在沒有額外構建索引情況下）。如果是100個客戶端并發模糊查詢，按照上面表格里100并發查詢2000萬數據，平均耗時37秒，每次查詢耗時37/100=0.37秒，每秒查詢次數100/37=2.7次，每秒查詢數據范圍大小100*2000萬/37秒=5400萬。這里測試key是“*”代表所有，如果key根據業務特點進行了分層設計，以“user.*.name”這樣形式模糊查詢，范圍會縮小，速度會更快。

測試6：壓力測試，200高并發下每客戶端讀取10萬數據連續48小時不間斷，服務端cpu、內存、帶寬資源高壓力運行穩定無異常。

下面歸納一下coolhash和redis的基本區別：

總結：

• 首先不能簡單的以實現語言來衡量性能，認為c實現的就一定比java高效，數據庫引擎的效率提升更多取決于底層算法改進和設計突破，c在底層和操作系統交互上有優勢，但是取決于開發者，一個蹩腳的c工程師寫出的代碼只會低效和漏洞百出。

• redis的優勢在于快速的緩存讀寫、豐富的數據類型支持，以及完善的主備復制和集群實現，劣勢在于單進程模式、內存限制、查詢檢索等方面。

• coolhash是一個并行數據庫引擎，在很多地方采用了大膽創新的設計，并獲得了很好的性能體驗，改進后的哈希算法能實現更快的讀寫吞吐量，key層次結構和key指針等設計能實現更高效的查詢檢索和join關聯。由于只做數據庫引擎，暫不提供主備和集群功能，但是fourinone提供了大部分分布式技術簡單實現的開發API，開發者可以利用這些自己去實現。

• 隨著數據庫實現技術的發展，kv緩存和kv持久化存儲的性能越來越接近，邊界會越來越模糊，也會越來越涵蓋關系數據庫的功能。存儲硬件技術也在發展，未來在內存+ssd混合存儲上還會有更好的性能突破。

以上測試程序和運行包都來源于fourinone4.0版本，可以到以下地址下載：

• google code svn：http://fourinone.googlecode.com/svn/trunk/

• 國內oschina code：https://git.oschina.net/fourinone/fourinone/blob/master/fourinone-4.05.06.zip

CoolHash數據庫demo目錄內容：

• RunServer.java：啟動服務端

• RunClient.java：啟動客戶端

• CoolHashTestRun.java：啟動多個并發客戶端

CoolHash作者聲明：歡迎各位朋友理性驗證和討論，不歡迎不理會各種噴子言論。

這里有很多人是redis和leveldb的使用者和封裝者，其中一部分人會看coolhash不爽，甚至失去理性變成噴子，對coolhash大加攻擊和詆毀，希望coolhash只是玩具，希望coolhash沒有場景...但是噴子們要清楚自己的位置，redis和leveldb不是你的作品，你只是站在洋人前面狐假虎威而已，核心層面的東西你甚至不具備發言權。長期以來國內工程師都是以學習和使用國外開源軟件為生存技能，能理解這些人也只是混口飯吃。

很多人軟件思想意識落后，“軟件傻瓜化”超出了他的理解范圍，看到demo簡單，便誤認為框架源碼也膚淺，看到demo里沒有synchronized，便以為框架沒有同步，有人甚至懷疑源碼是假的。demo簡單是為了保護用戶的自信心和駕馭感，用戶只需要看到一個美麗的軀殼，血肉模糊的東西留給框架戴著口罩拿著手術刀去做，這實際上對設計者提出了更大的難度，所以源碼要實現那么多功能，還要做到體驗傻瓜化，一定是非常精密的邏輯組成，源碼不可能像demo那樣通俗易懂。

一些人一來就對fourinone源碼指手畫腳，評頭論足，大部分批評只停留在“編程規范、格式、變量名、包名、調了哪些工具類”這些層面，這些人需要多花時間提升自己的技術積累、設計能力、算法能力，才能真正理解源碼的各種行為，作者到過國內各種IT企業，非常清楚國內工程師的技術能力能到什么程度，國內的開源軟件大部分是基于國外開源軟件封裝后的二次開源，真正意義上的原創很少，大部分中國IT企業處在產業鏈末端，沒有核心技術，依靠外包勞動力，工程師的技術壽命很短，平均只有3-5年，然后周圍環境會暗示他轉向管理或者業務，只有這樣才能得到領導認可，技術積累太短暫，技術人員沒有悟性，也缺乏興趣，過于依賴國外，是不可能在核心軟件層面有真正的原創。

一些人對coolhash很質疑，認為很少人很少代碼實現不了高性能，實際上早在幾年前，fourinone就在一片質疑聲中被要求壓測，結果出乎意料在計算性能上優于hadoop，現在coolhash只是重演了創新能力而已。建議各種質疑者跟風者先放下政治偏見、利益沖突、情感排斥，耐心的動手去試試。對于技術上缺乏分辨力的人，建議你認準三點，一看上手是否容易；二看功能是否強大；三看性能是否高效，只要滿足這三點就沒有人可以忽悠得了你，然后你再結合源碼去反思是如何做到的。

曾國藩說過“竊喜洋人之智巧中國亦能為之，彼不能傲我以其所不知矣!”

文人不相輕，技術歸技術，本文對redis和leveldb的作者充滿尊敬和虛心學習，Salvatore Sanfilippo(antirez) 說過代碼像一首詩，Jeffrey Dean更是google map/reduce的作者，他們都表現出很高的職業素養和天賦，是這些人推動著世界軟件技術的發展，也成為中國架構師內心難以跨越的豐碑。是存在差距，但是可以站著學習，而不是跪著膜拜，一味跟從只會喪失判斷力和創新力，香港的年輕人曾經不相信大陸的taobao會比eBay強大，QQ會比MSN強大，直到MSN垮了仍然不相信是真的，沒有信心，沒有努力，夢想只會變成做夢。

本文來自：http://my.oschina.net/fourinone/blog/289122