- 論壇徽章:
- 9
|
本帖最后由 wlmqgzm 于 2016-07-17 14:45 編輯
繼續(xù)開發(fā)代碼, 現(xiàn)在準(zhǔn)備解決的主要的問題是:
1)計劃重新寫 Key Map 這部分代碼, 準(zhǔn)備先簡化, 主字段 整體所有的字節(jié)都放到內(nèi)存中, 包括主字段Key, hash id, Global Offset, 占用空間為主字段Key的長度+16字節(jié), 減少程序間的耦合, 后期再考慮優(yōu)化空間.
初期這部分代碼主要的思路是: 初期的設(shè)計考慮用盡可能少的內(nèi)存來實現(xiàn)最大化的記錄數(shù)的地址索引, 因此, 架構(gòu)中 主字段( key) 先hash轉(zhuǎn)化為一個64bit的長整數(shù), 然后再映射到File_maping中, 以一個64bit的offset來表示實際存儲的位置.
將所有的數(shù)據(jù)分解為兩大類, 有hash沖突的, 無哈希沖突的,然后分別處理,
無哈希沖突的, 2個64比特就足夠表示, 考慮hash沖突有可能對于多數(shù)記錄都不存在, 因此多數(shù)記錄都不需要保存主字段, 只占用16個字節(jié)就可以完整表示一個記錄的位置, 占用內(nèi)存空間比較少, 32G內(nèi)存就肯定可以處理20億的記錄,
出現(xiàn)hash沖突后, 讀取沖突的舊數(shù)據(jù), 重新寫入另外的數(shù)據(jù)結(jié)構(gòu)中, 這部分?jǐn)?shù)據(jù)結(jié)構(gòu)中主要是 包含了主字段
總之, 就是代碼復(fù)雜, 并且與下層的File_mapping的存儲結(jié)構(gòu)耦合. 要額外增加一些只讀IO.
2) MVCC的處理: 要簡化掉,
初期的設(shè)計中, 考慮到MVCC的并發(fā)情況, 因此, 對于每個數(shù)據(jù)記錄都要有多個版本的記錄, 并且正在更新的原始記錄中還要有連接號, 那么SELECT查詢就很復(fù)雜, 這部分代碼對多版本的處理部分, 目前看做的比較復(fù)雜, 從已經(jīng)寫的代碼看, 比預(yù)想的要復(fù)雜的多, TODO:的內(nèi)容也比較多, 這部分代碼準(zhǔn)備要大塊的暫時取消掉, 隱藏掉.
|
|