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

wlmqgzm

回復 20# lijianweiabcde

由于存儲層是新的設計，全動態(tài)字段的存儲模式，新增或者刪除任意字段，不需要重新rebuild table,  
實質(zhì)是一個NOSQL的存儲層， 無法與現(xiàn)有版本的MYSQL對接，還是要自己造輪子．

初步的設計思路是
存儲層的字段設計是下推到底的，字段名對應的ｉｄ直接在數(shù)據(jù)塊的每行中存在，因此，字段的數(shù)量是隨時可變的，字段的順序也是可變的，提供了靈活性，適應一切變化．
屬于一個統(tǒng)一的存儲層架構．
對于Memcached來說，就是有２個字段，字段K(ey)和字段V(alue), 也是下推到底的，有一些浪費．
就是因為數(shù)據(jù)中存在太多的冗余，　所以，一定要有壓縮跟上，這樣來解決　靈活性和數(shù)據(jù)長度的兼顧，


   

wlmqgzm

已經(jīng)完成 File_mapping層的read/write初步編碼設計，簡單進行了數(shù)據(jù)讀寫，還未進行詳細測試．后面還要增加動態(tài)擴展大小的功能，　目前暫時固定大�。�

進入Class Block的設計，　
//   設計壓縮塊／標準塊的結構:
// 1) 塊的位置號, 就是塊的唯一標志,  位置號就是offset,  ４字節(jié)整數(shù),  位置號==實際存儲的offset, 即該位置上讀到的４字節(jié)數(shù)據(jù)==該位置的offset
// 2) 塊的壓縮格式及壓縮率: 1字節(jié),  0=不壓縮, 1-9=lz4壓縮, 21-29=gzip壓縮,  31-39=bzip2, 先只做lz4, 其他備用

// 3) 塊內(nèi)部記錄數(shù)：１字節(jié)．　每個數(shù)據(jù)塊可存放１－２40條記錄，  標準塊是一條記錄一個塊，　壓縮塊是１－240個記錄一個塊

這里保留了241-255的編號, 這些編號主要是為了未來(第2個版本)預留,
這些編號對應的內(nèi)存結構, 在硬盤空間中沒有使用,
在內(nèi)存空間中使用, 將以特殊的方式, 提供高性能鎖空間
每個編號將在主鍵上以特殊方式(類似于MVCC)提供4M個鎖空間, 一共可以提供60M個鎖空間,即每個table可提供最大6000萬個鎖空間
將用于 存儲層的行鎖--更新鎖內(nèi)部使用, 這部分代碼還沒有做, 但是計劃在第2個版本中使用, 使用行鎖以后, 將提供完整MVCC和READ COMMIT等數(shù)據(jù)庫標準功能
第2個版本將實現(xiàn)完整的MVCC, 讀取是沒有任何鎖, 可提供高的性能. MVCC在第一個版本中做好預留, 但是不占數(shù)據(jù)內(nèi)存空間, 以便提供最好的性能
行鎖是寫鎖,即更新鎖, 正在考慮  不過都是第2個版本的事情, 這個版本只是做好預留, 按最簡單的方式實現(xiàn)

// 3) 塊的大小, 1-5字節(jié)整數(shù), 壓縮編碼整數(shù)，　表示未壓縮的長度
// 4) 塊的大小, 1-5字節(jié)整數(shù), 壓縮編碼整數(shù)  表示壓縮后實際的長度,如果不壓縮，同上一個值
// 5) 塊的內(nèi)容 ０K--3.999G
// 6) 塊的校驗碼:   8字節(jié),  塊內(nèi)容crc64校驗
// 7) 塊的同步碼  8字節(jié)
// 塊的管理用掉 ４+1+１＋３+３+8+8=28字節(jié) ,   對于4K字節(jié)的壓縮塊,  大約不到1%的開銷,

bule_gay_是條狗

回復 22# wlmqgzm


    樓主對 memcached 是不是也非常熟？

wlmqgzm

回復 23# bule_gay_是條狗

不熟，但是簡單看過代碼


   

bule_gay_是條狗

回復 24# wlmqgzm


    錯了，我是想說 mangoDB的，不然怎么會想起模仿他呢。

VIP_fuck

坐等樓主的源碼開源，這代碼風格還不錯。不少碼農(nóng)都胡亂命名，根本不知道什么意思。

folklore

lzv5, 8741

wlmqgzm

回復 25# bule_gay_是條狗

簡單看過mongoDB的介紹，代碼看了幾段，沒有仔細看，代碼風格不是喜歡的那種，
主要是設計存儲層的思路接近，但是，還是有很多地方不同，尤其是mongoDB浪費空間的地方很多，還有不少隨機寫的設計，
C++風格方面，例如：　它里面是自己包封的mmap, 我是采用Boost庫已經(jīng)做好的封裝．應該說，寫mongoDB代碼的人對C++Boost庫的熟悉程度還不夠,所以自己造輪子．

自己的設計上，還有很多接近Google LevelDb的思想設計，　主要體現(xiàn)消滅隨機寫，數(shù)據(jù)的自動回收合并和壓縮部分．　　
思路上接近，但是做法上差別比較大，結構上不一樣，最終實現(xiàn)的功能是一樣的，都是高速寫入優(yōu)化的，都是只有順序寫，都會自動合并文件．

覺得自己重新開始設計存儲層的話，可能會比MongoDB更節(jié)約空間，徹底消滅隨機寫，更C++, 更優(yōu)美一些．
對現(xiàn)有的各類存儲層都不夠滿意，所以，想綜合各類存儲層的主要優(yōu)點，綜合起來，實現(xiàn)更優(yōu)化的一個存儲層．

這次開發(fā)的存儲層基本框架和思路都比較先進，雖然經(jīng)過仔細考慮，要綜合各類存儲層的優(yōu)點，實現(xiàn)起來比一般的設計難度要大一些，開發(fā)的時間估計會比較長，初步估計要２個月的時間，弄完存儲層的代碼．
然后，再看情況，嫁接一個用戶層接口．



   

lijianweiabcde

回復 21# wlmqgzm
我們對接的存儲層是一個kv的存儲系統(tǒng)，搞了一個中間適配層做轉換


   

cokeboL

lzv5871b,up up!