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

wlmqgzm

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

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

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

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

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

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

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

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

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

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

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

wlmqgzm

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

初步計劃先開始就弄存儲層,  存儲層代碼先不采用AIO, 先測試和完善一個基于 file_mapping 技術(shù)的磁盤IO,  采用這個技術(shù)方案可以減少IO過程中一半的data Copy過程, 對SSD有吸引力, 實現(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

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

wlmqgzm

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

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

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

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

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

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

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

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

wlmqgzm

回復(fù) 5# windoze

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

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

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

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

MYSQL接口還是好用一些，最起碼功能豐富一些，　這個還在猶豫．．．．．．．．，等存儲層主要代碼做完，再決定用戶接口層，使用什么接口吧．

   

windoze

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

fender0107401

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

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

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

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

windoze

回復(fù) 9# fender0107401

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