Coolhash當(dāng)前性能指標(biāo)：讀寫(xiě)吞吐量超過(guò)百萬(wàn)，千萬(wàn)級(jí)別查詢1秒完成，連續(xù)48小時(shí)打滿CPU強(qiáng)壓力運(yùn)行穩(wěn)定。redis官方公布讀寫(xiě)性能在10萬(wàn)tps，leveldb官方公布寫(xiě)性能在40萬(wàn)tps，讀在6萬(wàn)tps，redis和leveldb都是傾向k/v高速讀寫(xiě)，但不具備高效檢索功能，沒(méi)有join關(guān)聯(lián)設(shè)計(jì)。coolhash可以拿去pk世界上任何的數(shù)據(jù)庫(kù)引擎產(chǎn)品。

下面以redis為例進(jìn)行了詳細(xì)測(cè)試和技術(shù)分析，leveldb的性能可詳見(jiàn)其官方資料，在寫(xiě)性能上優(yōu)于redis，但是讀性能和多數(shù)據(jù)結(jié)構(gòu)支持上不如redis，leveldb讀代價(jià)高是因?yàn)樾枰趦?nèi)存以及各級(jí)數(shù)據(jù)文件逐項(xiàng)查找并要優(yōu)先考慮數(shù)據(jù)最新?tīng)顟B(tài)，另外redis還提供server和集群功能，leveldb不提供，redis是內(nèi)存方式+內(nèi)存快照持久化，而leveldb是Memtable+硬盤(pán)持久化，leveldb持久化不受內(nèi)存限制，也做到了接近緩存的性能，未來(lái)k/v數(shù)據(jù)庫(kù)的趨勢(shì)最好能直接當(dāng)作緩存使用，并能支持高效檢索功能。

按照redis的常用方式，我們?cè)谝慌_(tái)服務(wù)器上進(jìn)行redis“單server”和“多server”的測(cè)試：

從上面兩個(gè)圖，我們可以看到：

• redis是一個(gè)單進(jìn)程單線程的實(shí)現(xiàn)，單server的讀寫(xiě)TPS大概在8—12萬(wàn)（跟redis官網(wǎng)公布的數(shù)據(jù)一致），為了充分利用能夠資源，redis官方建議一臺(tái)機(jī)器部署多個(gè)redis server。

• 上面第二個(gè)圖的TPS超過(guò)了8-12萬(wàn)的限制，這實(shí)際上是在一臺(tái)服務(wù)器上部署了多個(gè)redis server，并將該服務(wù)器總的吞吐量算到一個(gè)redis server上得到的。但是寫(xiě)的時(shí)候是客戶端各自寫(xiě)不同的redis server，多個(gè)redis server之間的數(shù)據(jù)是彼此獨(dú)立的，在不同的內(nèi)存空間中，如果分開(kāi)計(jì)算每個(gè)redis server的寫(xiě)入總量除以時(shí)間，TPS還是在8-12萬(wàn)左右。

我們?cè)俚?4核/256g/SATA硬盤(pán)的pc server上測(cè)試一下redis的benchmark，200個(gè)客戶端共寫(xiě)入2000萬(wàn)數(shù)據(jù)，發(fā)現(xiàn)性能變化不大，還是在10萬(wàn)左右的TPS，又測(cè)試了20個(gè)客戶端寫(xiě)入2000萬(wàn)數(shù)據(jù)，12萬(wàn)TPS：

Redis很優(yōu)秀，但是也有一些局限：

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

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

• redis的存儲(chǔ)方式不是按照數(shù)據(jù)庫(kù)存儲(chǔ)索引結(jié)構(gòu)設(shè)計(jì)，無(wú)法做到高性能的按范圍、按key/value的模糊檢索，更多只能在內(nèi)存中進(jìn)行全局?jǐn)?shù)據(jù)的遍歷過(guò)濾，沒(méi)有高效的查詢功能，redis更適合做緩存讀寫(xiě)，不適合當(dāng)作數(shù)據(jù)庫(kù)存儲(chǔ)使用。

國(guó)內(nèi)的redis使用團(tuán)隊(duì)更多也是在運(yùn)維工具、監(jiān)控管理、主備、故障恢復(fù)等等方面改進(jìn)，不具備對(duì)上面redis的3點(diǎn)內(nèi)核局限的重構(gòu)能力。

我們接下來(lái)在同機(jī)環(huán)境（24核/256g/SATA硬盤(pán)）測(cè)試coolhash，實(shí)際上coolhash也可以像上面redis那樣在一臺(tái)服務(wù)器上部署多個(gè)server實(shí)例，但是我們這里啟動(dòng)一個(gè)coolhash就夠了。coolhash是一個(gè)并行數(shù)據(jù)庫(kù)引擎和數(shù)據(jù)庫(kù)server，可以通過(guò)調(diào)整“coolhash數(shù)據(jù)工人數(shù)量、客戶端并發(fā)數(shù)量、每客戶端讀寫(xiě)數(shù)量”三個(gè)指標(biāo)項(xiàng)達(dá)到一臺(tái)服務(wù)器的最佳吞吐量性能。

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

測(cè)試1：x個(gè)數(shù)據(jù)工人，200個(gè)客戶端并發(fā)，每個(gè)客戶端寫(xiě)入10萬(wàn)數(shù)據(jù)

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

根據(jù)上面的結(jié)論，我們配置coolhash啟動(dòng)24個(gè)數(shù)據(jù)工人最合適，接下來(lái)再進(jìn)一步調(diào)整“客戶端并發(fā)數(shù)”和“每個(gè)客戶端寫(xiě)入數(shù)量”，來(lái)達(dá)到一臺(tái)服務(wù)器的最佳性能。

測(cè)試2：24個(gè)數(shù)據(jù)工人，x個(gè)客戶端并發(fā)，每個(gè)客戶端寫(xiě)入10萬(wàn)數(shù)據(jù)

分析：如果每個(gè)客戶端寫(xiě)相同數(shù)量的數(shù)據(jù)，隨著并發(fā)數(shù)的提高，總體的吞吐量會(huì)高于單客戶端呈線性增長(zhǎng)趨勢(shì)，但是受服務(wù)器cpu、內(nèi)存、io等性能限制，不會(huì)一直增長(zhǎng)，會(huì)傾向于一個(gè)平衡值。每臺(tái)服務(wù)器并不是能承受無(wú)限大的并發(fā)數(shù)量，如果超出了承受限制，客戶端會(huì)長(zhǎng)時(shí)間等待，容易產(chǎn)生socket連接超時(shí)。合理的控制并發(fā)數(shù)量能提升服務(wù)器的吞吐性能，下面我們?cè)龃竺總€(gè)客戶端的寫(xiě)入數(shù)量，減少總的并發(fā)數(shù)，并觀察效果。

測(cè)試3：24個(gè)數(shù)據(jù)工人，20個(gè)客戶端并發(fā)，每個(gè)客戶端寫(xiě)入x萬(wàn)數(shù)據(jù)

分析：可以看到同樣寫(xiě)入2000萬(wàn)數(shù)據(jù)，采用20并發(fā)*100萬(wàn)比200并發(fā)*10萬(wàn)的性能提升了一倍，能達(dá)到200萬(wàn)以上TPS。這是因?yàn)榭蛻舳私⑦B接后，一次提交100萬(wàn)條數(shù)據(jù)的寫(xiě)入請(qǐng)求，相比每條數(shù)據(jù)連接server，能很大節(jié)省網(wǎng)絡(luò)開(kāi)銷(xiāo)和硬盤(pán)IO開(kāi)銷(xiāo)。由此我們也能得到，并不是并發(fā)連接越多越好，而是控制一定數(shù)量的連接池性能會(huì)更好。

接下來(lái)我們?cè)僖允褂孟嗤瑓?shù)，測(cè)試一下讀的性能。

測(cè)試4：24個(gè)數(shù)據(jù)工人，20個(gè)客戶端并發(fā)，每個(gè)客戶端讀出x萬(wàn)數(shù)據(jù)

分析：coolhash是一個(gè)讀寫(xiě)平衡的數(shù)據(jù)庫(kù)引擎，可以看到讀和寫(xiě)的性能相差不大，都能達(dá)到200萬(wàn)的TPS。

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

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

#p#

測(cè)試5：24個(gè)數(shù)據(jù)工人，x個(gè)客戶端模糊查詢x萬(wàn)數(shù)據(jù)

單個(gè)客戶端模糊查詢：

多個(gè)客戶端高并發(fā)模糊查詢：

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

測(cè)試6：壓力測(cè)試，200高并發(fā)下每客戶端讀取10萬(wàn)數(shù)據(jù)連續(xù)48小時(shí)不間斷，服務(wù)端cpu、內(nèi)存、帶寬資源高壓力運(yùn)行穩(wěn)定無(wú)異常。

下面歸納一下coolhash和redis的基本區(qū)別：

總結(jié)：

• 首先不能簡(jiǎn)單的以實(shí)現(xiàn)語(yǔ)言來(lái)衡量性能，認(rèn)為c實(shí)現(xiàn)的就一定比java高效，數(shù)據(jù)庫(kù)引擎的效率提升更多取決于底層算法改進(jìn)和設(shè)計(jì)突破，c在底層和操作系統(tǒng)交互上有優(yōu)勢(shì)，但是取決于開(kāi)發(fā)者，一個(gè)蹩腳的c工程師寫(xiě)出的代碼只會(huì)低效和漏洞百出。

• redis的優(yōu)勢(shì)在于快速的緩存讀寫(xiě)、豐富的數(shù)據(jù)類(lèi)型支持，以及完善的主備復(fù)制和集群實(shí)現(xiàn)，劣勢(shì)在于單進(jìn)程模式、內(nèi)存限制、查詢檢索等方面。

• coolhash是一個(gè)并行數(shù)據(jù)庫(kù)引擎，在很多地方采用了大膽創(chuàng)新的設(shè)計(jì)，并獲得了很好的性能體驗(yàn)，改進(jìn)后的哈希算法能實(shí)現(xiàn)更快的讀寫(xiě)吞吐量，key層次結(jié)構(gòu)和key指針等設(shè)計(jì)能實(shí)現(xiàn)更高效的查詢檢索和join關(guān)聯(lián)。由于只做數(shù)據(jù)庫(kù)引擎，暫不提供主備和集群功能，但是fourinone提供了大部分分布式技術(shù)簡(jiǎn)單實(shí)現(xiàn)的開(kāi)發(fā)API，開(kāi)發(fā)者可以利用這些自己去實(shí)現(xiàn)。

• 隨著數(shù)據(jù)庫(kù)實(shí)現(xiàn)技術(shù)的發(fā)展，kv緩存和kv持久化存儲(chǔ)的性能越來(lái)越接近，邊界會(huì)越來(lái)越模糊，也會(huì)越來(lái)越涵蓋關(guān)系數(shù)據(jù)庫(kù)的功能。存儲(chǔ)硬件技術(shù)也在發(fā)展，未來(lái)在內(nèi)存+ssd混合存儲(chǔ)上還會(huì)有更好的性能突破。

以上測(cè)試程序和運(yùn)行包都來(lái)源于fourinone4.0版本，可以到以下地址下載：

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

• 國(guó)內(nèi)oschina code：https://git.oschina.net/fourinone/fourinone/blob/master/fourinone-4.05.06.zip

CoolHash數(shù)據(jù)庫(kù)demo目錄內(nèi)容：

• RunServer.java：?jiǎn)?dòng)服務(wù)端

• RunClient.java：?jiǎn)?dòng)客戶端

• CoolHashTestRun.java：?jiǎn)?dòng)多個(gè)并發(fā)客戶端

CoolHash作者聲明：歡迎各位朋友理性驗(yàn)證和討論，不歡迎不理會(huì)各種噴子言論。

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

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

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

一些人對(duì)coolhash很質(zhì)疑，認(rèn)為很少人很少代碼實(shí)現(xiàn)不了高性能，實(shí)際上早在幾年前，fourinone就在一片質(zhì)疑聲中被要求壓測(cè)，結(jié)果出乎意料在計(jì)算性能上優(yōu)于hadoop，現(xiàn)在coolhash只是重演了創(chuàng)新能力而已。建議各種質(zhì)疑者跟風(fēng)者先放下政治偏見(jiàn)、利益沖突、情感排斥，耐心的動(dòng)手去試試。對(duì)于技術(shù)上缺乏分辨力的人，建議你認(rèn)準(zhǔn)三點(diǎn)，一看上手是否容易；二看功能是否強(qiáng)大；三看性能是否高效，只要滿足這三點(diǎn)就沒(méi)有人可以忽悠得了你，然后你再結(jié)合源碼去反思是如何做到的。

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

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

本文來(lái)自：http://my.oschina.net/fourinone/blog/289122