大家好， 想給大家分享下我最近為 nutsdb 做的數據測試。

測試項目

起因

事情起因是這個 issue ，簡單說就是內存高了，不夠用了。

可能很多人不知道 NutsDB。簡單介紹下，NutsDB 是我幾個月以前開源的一個 Go 語言編寫的內嵌型 KV 數據庫，支持多種數據結構。開源取的的反饋：一開源就上了 Go 趨勢榜。一周斬獲 500+star，也得到很多同行的關注，給我提建議。還有幾個用在了生產環境。

驗證測試一億條數據

回到正題：

為了驗證這個 issue

于是我先測了一個億的數據量

版本：nutsdb V0.4.0

服務器配置：Ubuntu 16.04 64 位 8 核 64G

數據量：占有 11G 左右 (目前版本沒有做壓縮)

為了加快測試，沒有設置實時 sync，寫入速度：25.7w/s

key\value 類似:

key := []byte("namename" + strconv.Itoa(i))

val := []byte("valvalvavalvalvalvavalvalvalvavalvalvalvaval" + strconv.Itoa(i))

測試結果：

Mem : 64430 MB , Free: 63776 MB , Used:176 MB , Usage:0.273957%

start db index cost time: 72.076μs

batch put data cost: 6m29.067011134s

Mem : 64430 MB , Free: 24760 MB , Used:39147 MB , Usage:60.759105%

發現 消耗內存是數據量的 3.46 倍左右，說實話雖然比他說的少幾倍，但我還是有點接受不了。怎么辦？

解決

于是開發了新的模式 EntryIdxMode:HintBPTSparseIdxMode, 專門為節約內存設計。原理采用 b+樹多級索引的方式。

master 分支 已經支持了，有興趣的歡迎嘗試。

那我們單機先來測試 10 億條數據。

新模式測試 10 億條數據

版本 ：nutsdb master 分支

主機配置：Ubuntu 16.04 64 位 2 核 2G

key\value 類似上面的

為了加快測試，沒有設置實時 sync

測試結果：

Mem : 1999 MB , Free: 1786 MB , Used:53 MB , Usage:2.688618%

Mem : 1999 MB , Free: 1695 MB , Used:135 MB , Usage:6.784733%

內存占用只有 82MB，完成 10 億條數據插入，但是寫速度降到 4.35w/s。產生索引數據文件 153G

再來看下讀的表現，讀取 10 條數據，這個是沒有加緩存的結果如下：

load cost: 2.607796193s

key , find val namename0 valvalvavalvalvalvavalvalvalvavalvalvalvaval0

key , find val namename1 valvalvavalvalvalvavalvalvalvavalvalvalvaval1

key , find val namename2 valvalvavalvalvalvavalvalvalvavalvalvalvaval2

key , find val namename3 valvalvavalvalvalvavalvalvalvavalvalvalvaval3

key , find val namename4 valvalvavalvalvalvavalvalvalvavalvalvalvaval4

key , find val namename5 valvalvavalvalvalvavalvalvalvavalvalvalvaval5

key , find val namename6 valvalvavalvalvalvavalvalvalvavalvalvalvaval6

key , find val namename7 valvalvavalvalvalvavalvalvalvavalvalvalvaval7

key , find val namename8 valvalvavalvalvalvavalvalvalvavalvalvalvaval8

key , find val namename9 valvalvavalvalvalvavalvalvalvavalvalvalvaval9

read cost 87.208728ms

好了分享到這里。歡迎留言交流。

最后，歡迎去 nutsdb 提 issue，點 Star 關注，提交 PR，謝謝！