开源一个纯 Go 编写的高性能内嵌型 KV 数据库 NutsDB,支持事务以及多种数据结构。

2019-03-06 15:32:33 +08:00
 xujiajun001

大家好,分享一个最近开源的 KV 数据库项目 NutsDB。是我对 nosql 一个阶段性实践吧。

NutsDB 是纯 Go 语言编写一个简单、高性能、内嵌型、持久化的 key-value 数据库。

NutsDB 支持 ACID 事务,所有的操作都在事务中执行,保证了数据的完整性。NutsDB 从 v0.2.0 版本开始支持多种数据结构,如列表(list)、集合(set)、有序集合(sorted set)。

项目地址

https://github.com/xujiajun/nutsdb

项目特性

项目背景

对于现状或多或少的不满

我想找一个用纯 go 编写,尽量简单(方便二次开发、研究)、高性能(读写都能快一点)、内嵌型的(减少网络开销)数据库,最好支持事务。因为我觉得对于数据库而言,数据完整性很重要。如果能像 Redis 一样支持多种数据结构就更好了。 而像 Redis 一般用作缓存,对于事务支持也很弱。

找到几个备选项:

BoltDB BoltDB 是一个基于 B+ tree,有着非常好的读性能,还支持很实用的特性:范围扫描和按照前缀进行扫描。有很多项目采用了他。虽然现在官方不维护,由 etcd 团队在维护 他也支持 ACID 事务,但是他的写性能不是很好。如果对写性能要求不高也值得尝试。

GoLevelDB GoLevelDB 是 google 开源的 leveldb 的 go 语言版本的实现。他的性能很高,特别是写性能,据官方 c++版本说可以到 40w+次写 /秒,他基于 LSM tree 实现。他不支持事务。

Badger Badger 同样是基于 LSM tree,不同的是他把 key/value 分离。据他官网描述是基于为 SSD 优化。同是他也支持事务。但是我简单写了 benchmark 发现他的写性能没我想象中高。

好奇心的驱使

对于如何实现 kv 数据库的好奇心吧。数据库可以说是系统的核心,了解数据库的内核或者自己有实现,对更好的用轮子或者下次根据业务定制轮子都很有帮助。

基于以上两点,我决定尝试开发一个简单的 kv 数据库,性能要好,功能也要强大(至少他们好的功能特性都要继承)。

如上面的选项,我发现大致基于存储引擎的模型分:B+ tree 和 LSM tree。基于 B+ tree 的模型相对后者成熟。一般使用覆盖页的方式和 WAL (预写日志)来作崩溃恢复。而 LSM tree 的模型他是先写 log 文件,然后在写入 MemTable 内存中,当一定的时候写回 SSTable,文件会越来越多,于是他一般作法是在后台进行合并和压缩操作。 一般来说,基于 B+ tree 的模型写性能不如 LSM tree 的模型。而在读性能上比 LSM tree 的模型要来得好。当然 LSM tree 的模型也可以优化,比如引入 BloomFilter。 但是这些模型还是太复杂了。我喜欢简单,简单意味着好实现,好维护,相对不容易出错。

直到我找到 bitcask 这种模型,他其实本质上也算 LSM tree 的范畴吧。 他模型非常简单很好理解和实现,很快我就实现了一个版本。但是他的缺点是不支持范围扫描。我尝试去优化他,又开发一个版本,基于 B+ tree 作为索引,满足了范围扫描的问题 ,读性能是够了,写性能很一般,又用 mmap 和对原模型作了精简,这样又实现了一版。写性能又提高了几十倍。现在这个版本基本上都实现上面提到的数据库的一些有用的特性,包括支持范围扫描和前缀扫描、包括支持 bucket、事务等,还支持了更多的数据结构( list、set、sorted set )。从 benchmark 来看,NutsDB 性能只高不低, 这是 example 里面的代码 https://github.com/xujiajun/nutsdb/blob/master/examples/batch/put/main.go ,100w 条数据,我本机基本上 2s 跑完 ,写性能可达到 40~50W+/秒。

天下没有银弹,NutsDB 也有他的局限,比如随着数据量的增大,索引变大,启动会慢。 只想说 NutsDB 还有很多优化和提高的空间,由于本人精力以及能力有限。所以把这个项目开源出来。更重要的是我认为一个项目需要有人去使用,有人提意见才会成长。

希望一起来参与贡献,欢迎 Star、提 issues、提交 PR !

5309 次点击
所在节点    Go 编程语言
38 条回复
Damnever
2019-03-07 09:36:57 +08:00
@xujiajun001 文档说的没错,你用错了,要保证 nutsdb 宣称的 ACID 等高大上的特性,每次 commit 你都必须的 flush/sync,而 ACID 也不是说你简单加个锁就保证
srt180
2019-03-07 09:48:21 +08:00
想听一下作者对 redis 的看法。
虽说 redis 的事务不具备原子性,但是 redis 可以通过 lua 脚本支持事务。
BBCCBB
2019-03-07 10:21:11 +08:00
=_= 楼主,我是来求资料的, Go 的 mmap 相关的貌似每个操作系统的 api 都不一样? 这方面的博客好少, 楼主有 Go 的 mmap 相关的资料吗, 弱弱求一份, 我大 Java 里的 mmap api 是统一的, Go 的这个搞的我很头疼 ..

先 star.
xujiajun001
2019-03-07 10:42:48 +08:00
@Damnever 谢谢你的意见建议。为了保证 ACID 的 D 特性 每次 commit 你都必须的 flush/sync,这个我理解的,强一致性。nutsdb 的实现为了写性能更高,现在对 nutsdb 的做法有点缓冲的味道,到 unmap 的时候才能保证数据一定落盘。
” ACID 也不是说你简单加个锁就保证“,能多说一点吗?
Damnever
2019-03-07 10:59:18 +08:00
@xujiajun001 为了性能高这样做是没问题,但这个权衡牺牲了其它的特性就不能再说 nutsdb 有 ACID 等等特性,没有贬低的意思,简单的从 benchmark 来看这个惊人的结果就值得仔细思考下了,毕竟其它数据库生产环境验证优化了多年

就简单的说下 A 吧,毕竟是落盘的,简单的 unlock 来 rollback 就说不过去了
Damnever
2019-03-07 11:09:05 +08:00
@xujiajun001 代码没细看,可能我说的不对,但 ACID 这一块我觉得你还是得仔细考量下,简单并不一定正确
xujiajun001
2019-03-07 15:11:26 +08:00
@srt180 redis 我一般当做缓存来用,不会去当 db 使用,事务支持也很弱。不过他的支持丰富的数据结构真的很棒。nutsdb 的数据结构 api 就是模仿他的名字命名。至于 lua 脚本的方式 ,我没试过,不过我在想在代码里写脚本 ,优点是灵活 缺点有点像直接写原生 sql 的感觉,不好维护 也不好看吧。最好 Redis 原生支持最好。
xujiajun001
2019-03-07 15:15:47 +08:00
@Damnever 好的 我再想想。谢谢你。
xujiajun001
2019-03-07 15:18:45 +08:00
rebill
2019-03-07 16:52:34 +08:00
如果抛开事务支持这一特性,NutsDB 可以秒杀其他了呢?
Damnever
2019-03-07 23:04:51 +08:00
@rebill 这就是一种可能存在的误解了.. 所以作者这个项目如果作为自身学习是没问题的,大家也很支持,问题在于文案写的“越来越认真”导致了一些严重错误的东西被掩盖对于其它学习或者使用者来说是很误导人的
xujiajun001
2019-03-08 10:19:03 +08:00
@Damnever 认同 “导致了一些严重错误的东西被掩盖对于其它学习”, 已经更新了 README 在警告说明处做了阐述,我还会继续更新文档的,让我好好整理下。谢谢 Damnever 关注。有问题 我继续改。
另外大家希望多多提 issue。
@1892 有问题直接去项目提 issue 哦。
xujiajun001
2019-03-11 20:43:06 +08:00
@Damnever 你好 我已在最新的 master 和当前最新的版本 v0.3.0 支持了 强同步。真正支持了 D (持久化),性能报告也重新更新了。欢迎帮我 review,如有问题帮我指正。thank ;)
Damnever
2019-03-14 13:11:24 +08:00
@xujiajun001 review 就谈不上了,benchmark 结果很不错,但要做全做好也是个学问,我不太懂就不瞎说了
Damnever
2019-03-14 13:17:47 +08:00
@xujiajun001 就测试的规模来看,顶多几十兆的数据为啥还要搞个嵌入式的 kv 这么麻烦呢?
xujiajun001
2019-03-15 09:56:43 +08:00
@Damnever 是的,做全做好也是个学问,我认可的。 我也在探索中,一有空就在改进优化中。后面有精力打算做成分布式的,这是后话。数据量的话, 当前版本 nutsdb 的数据存储上限取决于你的配置,如果是默认的全内存索引模型,瓶颈是内存,还有一种是内存+磁盘索引的模式,会放下比内存大的数据量。nutsdb 的场景数据,几十 M 肯定不止的。
Damnever
2019-03-15 10:35:21 +08:00
@xujiajun001 我的意思是 benchmark 数据量可能太小了
xujiajun001
2019-03-15 23:10:31 +08:00
@Damnever 嗯 。后面有空去弄下大一点的数据量的性能表现。

这是一个专为移动设备优化的页面(即为了让你能够在 Google 搜索结果里秒开这个页面),如果你希望参与 V2EX 社区的讨论,你可以继续到 V2EX 上打开本讨论主题的完整版本。

https://www.v2ex.com/t/541765

V2EX 是创意工作者们的社区,是一个分享自己正在做的有趣事物、交流想法,可以遇见新朋友甚至新机会的地方。

V2EX is a community of developers, designers and creative people.

© 2021 V2EX