讀性能超過Memcached 65%, 單核也超過redis, 支持日志支持掉電保護(hù)，歡迎試用

wlmqgzm

今年第1個(gè)高性能數(shù)據(jù)庫產(chǎn)品開發(fā)已經(jīng)完成，

由于支持日志功能，所以，可以滿足各中對(duì)可靠性要求比較高的場(chǎng)合， 并且在打開日志功能的情況下， 依舊具備非常高的性能，滿足了性能和可靠性 。
日志部分也是亮點(diǎn)， 主要是日志的寫合并技術(shù)比較先進(jìn)，因此，超越了各類數(shù)據(jù)庫很多。

產(chǎn)品試用下載： http://www.haisql.com/fwzc/soft/
如果產(chǎn)品的試用期過了30天， 請(qǐng)重新下載拷貝一次， 就又可以使用30天了。

我們的軟件讀性能: 讀4.1Kbyte的數(shù)據(jù)包大小, 4核8線程3.4G主頻DDR3內(nèi)存, 讀900萬次數(shù)據(jù), 900并發(fā), 花費(fèi)時(shí)間23.631秒, 讀性能38萬QPS.
我們的軟件寫性能: 寫4.1Kbyte的數(shù)據(jù)包大小, 寫100萬次數(shù)據(jù), 100并發(fā), 花費(fèi)時(shí)間3.136秒, 寫性能32萬TPS.

目前版本1.0.35  查詢性能已經(jīng)比memcache大約高出64%，
插入/更新性能比memcache高出30%，
由于Redis只支持單CPU線程, 我們的軟件支持多CPU線程,因此, 我們的性能在多核CPU下比Redis快得多.

由于與Memcache指令集兼容，包括返回的內(nèi)容和錯(cuò)誤提示均一致， 所以直接作為一個(gè)MemCached的客戶端上連使用就行，
可以把我們的程序也作為一個(gè)特殊版本的MemCache服務(wù)器端來看待，
使用時(shí)與使用Memcache沒有區(qū)別，
Linux下測(cè)試性能， 也可以用MemCache的測(cè)試工具， 例如：memcslap等。

===========================================================================================================================
準(zhǔn)備開發(fā)一個(gè)高性能KV數(shù)據(jù)庫, 類似MongoDB這樣的, 學(xué)習(xí)MongoDB leveldb innodb，只是一個(gè)練手貼,  記錄一下自己的學(xué)習(xí)開發(fā)KV數(shù)據(jù)庫的過程.
去年學(xué)習(xí)開發(fā)過一個(gè)基于ASIO的網(wǎng)絡(luò)庫,  覺得寫日記對(duì)自己有幫助, 起到一定的督促作用,  而且能夠得到很多高手的各種提點(diǎn)( 尤其感謝Windoze ).

今年比較懈怠, 為了督促自己學(xué)習(xí)和進(jìn)步, 決定現(xiàn)在開始開發(fā)一個(gè)小型化的KV數(shù)據(jù)庫, 測(cè)試了解高性能軟件開發(fā)的特性.
第一次開發(fā)高性能KV數(shù)據(jù)庫, 只是一個(gè)練手的過程,  記錄下來, 當(dāng)做工作日志, 以便日后總結(jié)經(jīng)驗(yàn).
非開源項(xiàng)目, 只是一個(gè)練手貼.

初步計(jì)劃的思路是:
1)完全使用Memcached或者M(jìn)YSQL的命令集, 這樣就不用開發(fā)客戶端代碼了, 實(shí)現(xiàn)一個(gè)服務(wù)器端的軟件.
2)測(cè)試和優(yōu)化, 對(duì)比與MemCached/MongoDB的性能, 找到提升性能的思路.

以下部分是優(yōu)化部分:
主要是實(shí)現(xiàn)一個(gè)高性能的磁盤IO系統(tǒng)
3)實(shí)現(xiàn)存儲(chǔ)和落地, 增加KV數(shù)據(jù)庫的適應(yīng)性, 并且學(xué)習(xí)磁盤IO的處理之道.
4)實(shí)現(xiàn)存儲(chǔ)層對(duì)SSD的完全優(yōu)化, 做到完全去掉隨機(jī)寫, 只有隨機(jī)讀和順序?qū)? 實(shí)現(xiàn)一個(gè)高性能的存儲(chǔ)層.
5)存儲(chǔ)層實(shí)現(xiàn)高性能壓縮, 初步計(jì)劃輸入輸出數(shù)據(jù)可采用LZ4壓縮
6)多線程的處理過程, 實(shí)現(xiàn)高性能的查詢性能.
7)高性能的緩存系統(tǒng), 學(xué)習(xí)高性能緩存的開發(fā)思路.

已經(jīng)實(shí)現(xiàn)的部分:
7)高性能網(wǎng)絡(luò)層, 已經(jīng)實(shí)現(xiàn)低端4核8線程CPU上, 使用4工作線程, 4測(cè)試線程, PingPong測(cè)試,  87萬QPS的性能.
具體實(shí)現(xiàn) 在這個(gè)帖子中討論過    <<ASIO,高并發(fā),高可靠, 統(tǒng)一網(wǎng)絡(luò)架構(gòu),抗DOS,低端4核心服務(wù)器CPU 每秒87萬QPS ECHO >> http://www.72891.cn/thread-4189684-1-1.html

wlmqgzm

完全重新造輪子, ,  不用現(xiàn)在常用的技術(shù)手段和方法, 看能否找到新的開發(fā)思路和方法.

初步計(jì)劃先開始就弄存儲(chǔ)層,  存儲(chǔ)層代碼先不采用AIO, 先測(cè)試和完善一個(gè)基于 file_mapping 技術(shù)的磁盤IO,  采用這個(gè)技術(shù)方案可以減少IO過程中一半的data Copy過程, 對(duì)SSD有吸引力, 實(shí)現(xiàn)了用戶態(tài)內(nèi)存和系統(tǒng)態(tài)內(nèi)存共享, 減少用戶態(tài)的切換次數(shù), 有望提供更高的磁盤讀寫性能.

lxyscls

file map？那你應(yīng)該看看mongo

王楠w_n

歡迎繼續(xù)更新，加油回復(fù) 2# wlmqgzm


   

windoze

對(duì)于memcache這一類業(yè)務(wù)邏輯超級(jí)簡(jiǎn)單的應(yīng)用，你得先看看LSM tree之類的數(shù)據(jù)結(jié)構(gòu)，其它的部分其實(shí)真沒什么好操心的，隨便寫寫就能把千兆網(wǎng)跑滿。

wlmqgzm

存儲(chǔ)層的數(shù)據(jù)規(guī)劃思路:  

1)主要技術(shù)思路與Mangodb接近.分為數(shù)據(jù)和索引兩部分, 數(shù)據(jù)完全在存放在文件中, 由File mapping管理, 所有的讀寫全部由操作系統(tǒng)來控制, 代碼除了定期flush一下, 就完全不管了. 索引全部放在內(nèi)存中.

其余部分是與mangoDB不同的:
2)索引部分是真正由自己的代碼控制, 主要就是一個(gè)"hash(Key)===>(Key_value data)offset"的構(gòu)造, 實(shí)現(xiàn)Key--Value的查詢.
   查詢過程是: Key==>Hash(key) 統(tǒng)一轉(zhuǎn)化為8字節(jié)的編碼==>hash_map find, map內(nèi)部第2次hash,==>輸出8字節(jié)全局Offset==>3字節(jié)文件索引號(hào)+4字節(jié)File offset+1字節(jié)塊內(nèi)部索引編號(hào)
   ==>利用file mapping讀取數(shù)據(jù)頭, 發(fā)現(xiàn)是LZ4壓縮, 執(zhí)行LZ4讀, 如果是非壓縮格式, 直接讀
3)只有索引部分常駐內(nèi)存, 因此,這部分?jǐn)?shù)據(jù)決定了內(nèi)存的消耗量, 目前的設(shè)計(jì)是16個(gè)字節(jié)索引一條記錄, 8字節(jié)的hash(Key), 8字節(jié)的全局Offset. 對(duì)于1億條記錄, 總體消耗1.6G內(nèi)存.
   32G內(nèi)存, 理論上總體可實(shí)現(xiàn)20億條記錄的索引全部緩存在內(nèi)存中, 實(shí)際按照80%可用內(nèi)存消耗計(jì)算, 對(duì)于32G的單機(jī), 大約是16億條記錄每臺(tái)服務(wù)器.

8字節(jié)全局Offset==>3字節(jié)文件索引號(hào)+4字節(jié)File offset+1字節(jié)塊內(nèi)部索引編號(hào)
3字節(jié)索引號(hào) 表示最大使用1600萬個(gè)文件.
4字節(jié)File offset  表示每個(gè)文件最大4G字節(jié), 其實(shí)默認(rèn)就是4G字節(jié), 也是推薦的參數(shù). 這個(gè)可以把4字節(jié)的每個(gè)比特都用盡, 不浪費(fèi).
1字節(jié)塊內(nèi)部索引編號(hào)  表示每個(gè)數(shù)據(jù)塊最大存儲(chǔ)254個(gè)記錄, 其中記錄號(hào)0保留作為單塊單記錄的標(biāo)識(shí), 記錄號(hào)255保留做未來擴(kuò)充使用, 能夠使用的只有1-254, 一共能夠最大存儲(chǔ)254個(gè)記錄.
為了提高性能, 初步確定, 每個(gè)數(shù)據(jù)塊內(nèi)部的記錄Offset使用2個(gè)字節(jié)來表示, 因此,數(shù)據(jù)塊最大長(zhǎng)度為64KByte,  這個(gè)塊的大小是可調(diào)整的, 建議的范圍是０K--64KB, 這個(gè)塊大小與Mysql 4K-32K很接近.
最終推薦大小將根據(jù)產(chǎn)品的實(shí)際測(cè)試情況,推薦或者固定為一個(gè)最優(yōu)值.

與過去的其他任何數(shù)據(jù)庫的設(shè)計(jì)的重要的區(qū)別:
1)這次設(shè)計(jì)的數(shù)據(jù)塊要完全優(yōu)化SSD, 絕對(duì)避免隨機(jī)寫, 任何數(shù)據(jù)塊都是只寫一次, 不會(huì)有第2次重寫, 因此, 為了節(jié)約存儲(chǔ)空間, 所有的塊都是按照實(shí)際使用量連續(xù)排列的, 內(nèi)部沒有任何浪費(fèi),沒有任何預(yù)留空間, 并且塊開頭不是4K對(duì)齊的.
由于塊與塊是緊密相連的, 為了故障處理和崩潰恢復(fù), 在塊與塊之間, 引入了同步隔離碼的概念.

2)數(shù)據(jù)是壓縮與非壓縮混合的, 任何一個(gè)數(shù)據(jù)塊在第一次寫入時(shí)都是非壓縮的, 就是說任何最近的數(shù)據(jù)都是非壓縮格式. 這樣提供了最高的讀寫性能.
對(duì)于稍微舊一些的數(shù)據(jù)(還是有效數(shù)據(jù)), 或者在夜間時(shí)段，或者滿足一定的條件，　將在后臺(tái)低優(yōu)先級(jí)進(jìn)程啟用最高壓縮率的處理,  數(shù)據(jù)將第2次寫入, 但是寫入到新的區(qū)域,
使用LZ4壓縮, LZ4壓縮方式是HC模式, 即默認(rèn)高壓縮模式, 該模式非常消耗CPU資源, 大約壓縮性能與gzip相當(dāng), LZ4解壓是高性能的, 大約500M字節(jié)每秒.
這種設(shè)計(jì)實(shí)現(xiàn)了高性能并發(fā)與高壓縮比同時(shí)兼顧,  并且實(shí)現(xiàn)了查詢下的高性能解壓縮, 從設(shè)計(jì)理念上是非常先進(jìn)的.

數(shù)據(jù)塊內(nèi)部的進(jìn)一步編碼優(yōu)化: 這個(gè)部分尚在仔細(xì)考慮設(shè)計(jì)中, 因?yàn)橐呀?jīng)決定使用LZ4壓縮存儲(chǔ), 對(duì)塊內(nèi)部的壓縮, 或者沒有必要進(jìn)行額外的壓縮處理.  (正在考慮是否采用)
長(zhǎng)整數(shù)編碼的壓縮設(shè)計(jì): 使用壓縮編碼來編碼8字節(jié)長(zhǎng)整數(shù), 壓縮后編碼長(zhǎng)度范圍是1字節(jié)到9字節(jié), 平均長(zhǎng)度是4字節(jié).  4字節(jié)整數(shù)的壓縮后平均長(zhǎng)度是2字節(jié)
這部分整數(shù)壓縮代碼雖然已經(jīng)測(cè)試完畢, 但是可能最終會(huì)廢棄不使用.  整數(shù)壓縮的原理是: 4-8字節(jié)的整數(shù), 可能多數(shù)時(shí)候只有少數(shù)字節(jié)是非零的,這樣就可以用非零字節(jié)數(shù)+非零字節(jié)來表示, 尤其是全零的整數(shù), 只需要1個(gè)字節(jié)就可表示.

先提交這部分設(shè)計(jì), 后續(xù)再寫.

wlmqgzm

回復(fù) 5# windoze

我的設(shè)計(jì)與LSM Tree有類似的地方，但是可能更接近MangoDB的存儲(chǔ)層的設(shè)計(jì)思路，基本上融合了LSM Tree與MangoDB的優(yōu)點(diǎn)，還額外提供了壓縮處理．

我覺得自己的最大優(yōu)勢(shì)是全新設(shè)計(jì)的存儲(chǔ)層，可以采用目前所有nosql中的精華，現(xiàn)有的Mysql數(shù)據(jù)庫存儲(chǔ)層太老了，對(duì)SSD的優(yōu)化基本沒有，　　

至于用戶接口層是采用Memcached, 還是Mysql, 還在猶豫中．．．．．．．．．．，決定先做核心關(guān)鍵技術(shù)，最后再做用戶接口層．　
其實(shí)，如果時(shí)間足夠的話，想做一個(gè)MYSQL接口，而不是利用MemCached的接口，那個(gè)接口太簡(jiǎn)陋了，但是實(shí)現(xiàn)起來快，只是過渡產(chǎn)品，　但是　有利于我的性能測(cè)試和快速迭代．

或者先做一個(gè)單Table的Mysql, 實(shí)現(xiàn)單表的SELECT, UPDATE，DELETE, INSERT, CREATE TABLE.　DROP TABLE, ALTER TABLE, TRUNC TABLE.
由于存儲(chǔ)層的全新設(shè)計(jì)，ALTER TABLE將不會(huì)更新數(shù)據(jù),　只是更新幾條頭數(shù)據(jù)．
這個(gè)是我的理想．

MYSQL接口還是好用一些，最起碼功能豐富一些，　這個(gè)還在猶豫．．．．．．．．，等存儲(chǔ)層主要代碼做完，再?zèng)Q定用戶接口層，使用什么接口吧．

   

windoze

對(duì)于memcache來說壓縮幾乎總是劃算的，本來就沒什么地方特別耗CPU，IO才是最貴的。

fender0107401

windoze 發(fā)表于 2016-05-09 11:59
對(duì)于memcache來說壓縮幾乎總是劃算的，本來就沒什么地方特別耗CPU，IO才是最貴的。

IO永遠(yuǎn)是個(gè)要命的話題啊。。。

最近弄一個(gè)東西，需要打開幾十萬個(gè)小文件。。。

結(jié)果程序慢的死去活來的。。。

windoze

回復(fù) 9# fender0107401

你可以考慮把這些小文件合并成一個(gè)大文件，建一個(gè)偏移量索引，然后用mmap。