大家好, 想给大家分享下我最近为 nutsdb 做的数据测试。
## 测试项目
github 地址: https://github.com/xujiajun/nutsdb
## 起因
事情起因是这个 [issue](https://github.com/xujiajun/nutsdb/issues/33) : 简单说就是内存高了,不够用了。
## 验证测试一亿条数据
回到正题: 为了验证这个 issue 于是我先测了一个亿的数据量
```
版本:nutsdb V0.4.0
服务器配置:Ubuntu 16.04 64 位 8 核 64G
为了加快测试,没有设置实时 sync
```
## 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%
```
数据量:占有 11G 左右 (目前版本没有做压缩)。写入速度:25.7w/s。发现 消耗内存是数据量的 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,谢谢!
有疑问加站长微信联系(非本文作者)