开源一个纯 Go 编写的高性能内嵌型 KV 数据库 NutsDB,支持事务以及多种数据结构。 - V2EX
The Go Programming Language
http://golang.org/
Go Playground
Go Projects
Revel Web Framework
xujiajun001

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

  •  2
     
  •   xujiajun001
    xujiajun Mar 6, 2019 6128 views
    This topic created in 2629 days ago, the information mentioned may be changed or developed.

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

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

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

    项目地址

    https://github.com/xujiajun/nutsdb

    项目特性

    • 高性能
    • 支持 ACID 事务
    • 支持基本的 Put、Delete、Get 操作
    • 支持前缀扫描
    • 支持范围扫描
    • 除了基本的 String,还支持多种数据结构如列表(list)、集合(set)、有序集合(sorted set)

    项目背景

    对于现状或多或少的不满

    我想找一个用纯 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 !

    Supplement 1    Mar 11, 2019
    0.3.0 版本刚发布,支持数据持久化,一旦 commit 作强同步。
    Supplement 2    Mar 11, 2019

    抛弃了mmap的方式。从0.3.0开始返璞归真 用嘴基础的读写api,发现benchmark 也还能接受。找了2款 BadgerDBh和BoltDB,他们都是内嵌型的数据库,支持持久化和事务,不过不支持多种数据结构。以基础的put和get作比较,结果如下,如有问题,希望帮我指正。我及时改 :

    badger 2019/03/11 18:06:05 INFO: All 0 tables opened in 0s goos: darwin goarch: amd64 pkg: github.com/xujiajun/kvstore-bench BenchmarkBadgerDBPutValue64B-8 10000 112382 ns/op 2374 B/op 74 allocs/op BenchmarkBadgerDBPutValue128B-8 20000 94110 ns/op 2503 B/op 74 allocs/op BenchmarkBadgerDBPutValue256B-8 20000 93480 ns/op 2759 B/op 74 allocs/op BenchmarkBadgerDBPutValue512B-8 10000 101407 ns/op 3271 B/op 74 allocs/op BenchmarkBadgerDBGet-8 1000000 1552 ns/op 416 B/op 9 allocs/op BenchmarkBoltDBPutValue64B-8 10000 203128 ns/op 21231 B/op 62 allocs/op BenchmarkBoltDBPutValue128B-8 5000 229568 ns/op 13716 B/op 64 allocs/op BenchmarkBoltDBPutValue256B-8 10000 196513 ns/op 17974 B/op 64 allocs/op BenchmarkBoltDBPutValue512B-8 10000 199805 ns/op 17064 B/op 64 allocs/op BenchmarkBoltDBGet-8 1000000 1122 ns/op 592 B/op 10 allocs/op BenchmarkNutsDBPutValue64B-8 30000 53614 ns/op 626 B/op 14 allocs/op BenchmarkNutsDBPutValue128B-8 30000 51998 ns/op 664 B/op 13 allocs/op BenchmarkNutsDBPutValue256B-8 30000 53958 ns/op 920 B/op 13 allocs/op BenchmarkNutsDBPutValue512B-8 30000 55787 ns/op 1432 B/op 13 allocs/op BenchmarkNutsDBGet-8 2000000 661 ns/op 88 B/op 3 allocs/op BenchmarkNutsDBGetByHintKey-8 50000 27255 ns/op 840 B/op 16 allocs/op PASS ok github.com/xujiajun/kvstore-bench 83.856s 

    详细移步: https://github.com/xujiajun/nutsdb/blob/master/README-CN.md#benchmarks

    Supplement 3    Mar 15, 2019
    nutsdb v0.4.0 发布。

    * 修复事务提交的时候的 bug
    * 支持了自定义的启动加载的方式
    * 增加了新的参数配置:RWMode, SyncEnable and StartFileLoadingMode
    * 支持了自定义的读写文件的方式
    * 支持了自定义是否开启 sync 的方式
    Supplement 4    Apr 11, 2019

    有人提出要建微信群。如果有人想加群交流,可以去点下赞。如果点赞人数够,我觉得可以开通下,大家交流一下。不然意义不大。地址:https://github.com/xujiajun/nutsdb/issues/29

    38 replies    2019-03-15 23:10:31 +08:00
    KgM4gLtF0shViDH3
        1
    KgM4gLtF0shViDH3  
       Mar 6, 2019 via iPhone
    支持
    GG668v26Fd55CP5W
        2
    GG668v26Fd55CP5W  
       Mar 6, 2019
    学习了
    whoisghost
        3
    whoisghost  
       Mar 6, 2019
    我最近在看 BoltDB 的实现,快读完了,打算用 C 重写其核心部分练练手,了解如何实现持久化 k/v 数据库。先 star 之,之后我拜读下你写的。
    reus
        4
    reus  
       Mar 6, 2019   1
    CockroachDB 的作者也写了个叫 pebble https://github.com/petermattis/pebble,最近才开始受到注意

    还不够成熟,不过以作者的实力,如果投入足够,应该会是不错的。CockroachDB 现在用的是 RocksDB,我想他们可能也想用一个纯 go 实现的 kv 来代替吧。
    1892
        5
    1892  
       Mar 6, 2019
    能否提供类似 select db 的函数,每次都要指定 bucket 有点繁琐
    solu
        6
    solu  
       Mar 6, 2019
    star 为敬
    misaka19000
        7
    misaka19000  
       Mar 6, 2019
    额,这是个 production 还是一个 toy ?
    Damnever
        8
    Damnever  
       Mar 6, 2019
    想法很好,但有个大问题 https://github.com/xujiajun/nutsdb/issues/10
    server
        9
    server  
       Mar 6, 2019
    star
    JohnSmith
        10
    JohnSmith  
       Mar 6, 2019
    @Damnever #8 意思是东西都在内存里的嘛~
    wbrobot
        11
    wbrobot  
       Mar 6, 2019
    bitcask 如果不 flush 的话,会一直增大到无法忍受吧,以前豆瓣有个 beansdb
    Damnever
        12
    Damnever  
       Mar 6, 2019 via iPhone
    @JohnSmith 也不能这么说,操作系统会有一些策略把脏数据刷到磁盘,依赖操作系统正常情况下都没啥大问题,但是… 我只能说这个 benchmark 太不不公平了…
    fuyufjh
        13
    fuyufjh  
       Mar 6, 2019
    先 star 为敬
    azh7138m
        14
    azh7138m  
       Mar 6, 2019 via Android
    @JohnSmith 要么是我对持久化有什么误解,要么是作者对持久化有什么误解 :)
    F281M6Dh8DXpD1g2
        15
    F281M6Dh8DXpD1g2  
       Mar 6, 2019
    @Damnever
    这不跟 mongodb 当年的套路一样么,不做 flush / fsync 啥玩意都能跑的飞快........
    runningman
        16
    runningman  
       Mar 6, 2019 via iPhone
    咋都在喷 不如想办法改进
    xujiajun001
        17
    xujiajun001  
    OP
       Mar 7, 2019
    @Damnever 你好 你在我项目中提交的 issue 我已经回复你了,不好意思现在才回你。我其实在代码中使用了 unmmap,我的依据是 https://linux.cn/man2/mmap.2.html 提到这样一句话 The file may not actually be updated until msync(2) or munmap(2) are called,按照他这么说,只调用 unmap 实测发现数据是更新的, 难道我理解错了。
    xujiajun001
        18
    xujiajun001  
    OP
       Mar 7, 2019
    xujiajun001
        19
    xujiajun001  
    OP
       Mar 7, 2019
    @runningman 谢谢 你说的很中肯哈
    xujiajun001
        20
    xujiajun001  
    OP
       Mar 7, 2019
    @JohnSmith 我发现数据还是会更新到磁盘的。我是调用了 unmap,可能再加个 flush 的话更保障一点。
    Damnever
        21
    Damnever  
       Mar 7, 2019 via iPhone
    @xujiajun001 文档说的没错,你用错了,要保证 nutsdb 宣称的 ACID 等高大上的特性,每次 commit 你都必须的 flush/sync,而 ACID 也不是说你简单加个锁就保证
    srt180
        22
    srt180  
       Mar 7, 2019
    想听一下作者对 redis 的看法。
    虽说 redis 的事务不具备原子性,但是 redis 可以通过 lua 脚本支持事务。
    BBCCBB
        23
    BBCCBB  
       Mar 7, 2019
    =_= 楼主,我是来求资料的, Go 的 mmap 相关的貌似每个操作系统的 api 都不一样? 这方面的博客好少, 楼主有 Go 的 mmap 相关的资料吗, 弱弱求一份, 我大 Java 里的 mmap api 是统一的, Go 的这个搞的我很头疼 ..

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

    就简单的说下 A 吧,毕竟是落盘的,简单的 unlock 来 rollback 就说不过去了
    Damnever
        26
    Damnever  
       Mar 7, 2019 via iPhone
    @xujiajun001 代码没细看,可能我说的不对,但 ACID 这一块我觉得你还是得仔细考量下,简单并不一定正确
    xujiajun001
        27
    xujiajun001  
    OP
       Mar 7, 2019
    @srt180 redis 我一般当做缓存来用,不会去当 db 使用,事务支持也很弱。不过他的支持丰富的数据结构真的很棒。nutsdb 的数据结构 api 就是模仿他的名字命名。至于 lua 脚本的方式 ,我没试过,不过我在想在代码里写脚本 ,优点是灵活 缺点有点像直接写原生 sql 的感觉,不好维护 也不好看吧。最好 Redis 原生支持最好。
    xujiajun001
        28
    xujiajun001  
    OP
       Mar 7, 2019
    @Damnever 好的 我再想想。谢谢你。
    xujiajun001
        29
    xujiajun001  
    OP
       Mar 7, 2019
    rebill
        30
    rebill  
       Mar 7, 2019
    如果抛开事务支持这一特性,NutsDB 可以秒杀其他了呢?
    Damnever
        31
    Damnever  
       Mar 7, 2019
    @rebill 这就是一种可能存在的误解了.. 所以作者这个项目如果作为自身学习是没问题的,大家也很支持,问题在于文案写的“越来越认真”导致了一些严重错误的东西被掩盖对于其它学习或者使用者来说是很误导人的
    xujiajun001
        32
    xujiajun001  
    OP
       Mar 8, 2019
    @Damnever 认同 “导致了一些严重错误的东西被掩盖对于其它学习”, 已经更新了 README 在警告说明处做了阐述,我还会继续更新文档的,让我好好整理下。谢谢 Damnever 关注。有问题 我继续改。
    另外大家希望多多提 issue。
    @1892 有问题直接去项目提 issue 哦。
    xujiajun001
        33
    xujiajun001  
    OP
       Mar 11, 2019
    @Damnever 你好 我已在最新的 master 和当前最新的版本 v0.3.0 支持了 强同步。真正支持了 D (持久化),性能报告也重新更新了。欢迎帮我 review,如有问题帮我指正。thank ;)
    Damnever
        34
    Damnever  
       Mar 14, 2019 via iPhone
    @xujiajun001 review 就谈不上了,benchmark 结果很不错,但要做全做好也是个学问,我不太懂就不瞎说了
    Damnever
        35
    Damnever  
       Mar 14, 2019 via iPhone
    @xujiajun001 就测试的规模来看,顶多几十兆的数据为啥还要搞个嵌入式的 kv 这么麻烦呢?
    xujiajun001
        36
    xujiajun001  
    OP
       Mar 15, 2019
    @Damnever 是的,做全做好也是个学问,我认可的。 我也在探索中,一有空就在改进优化中。后面有精力打算做成分布式的,这是后话。数据量的话, 当前版本 nutsdb 的数据存储上限取决于你的配置,如果是默认的全内存索引模型,瓶颈是内存,还有一种是内存+磁盘索引的模式,会放下比内存大的数据量。nutsdb 的场景数据,几十 M 肯定不止的。
    Damnever
        37
    Damnever  
       Mar 15, 2019 via iPhone
    @xujiajun001 我的意思是 benchmark 数据量可能太小了
    xujiajun001
        38
    xujiajun001  
    OP
       Mar 15, 2019
    @Damnever 嗯 。后面有空去弄下大一点的数据量的性能表现。
    About     Help     Advertise     Blog     API     FAQ     Solana   Highest 6679       Select Language
    创意工作者们的社区
    World is powered by solitude
    VERSION: 3.9.8.5 85ms UTC 19:02 PVG 03:02 LAX 12:02 JFK 15:02
    Do have faith in what you're doing.
    ubao msn snddm index pchome yahoo rakuten mypaper meadowduck bidyahoo youbao zxmzxm asda bnvcg cvbfg dfscv mmhjk xxddc yybgb zznbn ccubao uaitu acv GXCV ET GDG YH FG BCVB FJFH CBRE CBC GDG ET54 WRWR RWER WREW WRWER RWER SDG EW SF DSFSF fbbs ubao fhd dfg ewr dg df ewwr ewwr et ruyut utut dfg fgd gdfgt etg dfgt dfgd ert4 gd fgg wr 235 wer3 we vsdf sdf gdf ert xcv sdf rwer hfd dfg cvb rwf afb dfh jgh bmn lgh rty gfds cxv xcv xcs vdas fdf fgd cv sdf tert sdf sdf sdf sdf sdf sdf sdf sdf sdf sdf sdf sdf sdf sdf sdf sdf sdf sdf sdf sdf sdf sdf sdf sdf sdf sdf sdf sdf sdf sdf sdf sdf sdf sdf sdf sdf sdf sdf sdf sdf shasha9178 shasha9178 shasha9178 shasha9178 shasha9178 liflif2 liflif2 liflif2 liflif2 liflif2 liblib3 liblib3 liblib3 liblib3 liblib3 zhazha444 zhazha444 zhazha444 zhazha444 zhazha444 dende5 dende denden denden2 denden21 fenfen9 fenf619 fen619 fenfe9 fe619 sdf sdf sdf sdf sdf zhazh90 zhazh0 zhaa50 zha90 zh590 zho zhoz zhozh zhozho zhozho2 lislis lls95 lili95 lils5 liss9 sdf0ty987 sdft876 sdft9876 sdf09876 sd0t9876 sdf0ty98 sdf0976 sdf0ty986 sdf0ty96 sdf0t76 sdf0876 df0ty98 sf0t876 sd0ty76 sdy76 sdf76 sdf0t76 sdf0ty9 sdf0ty98 sdf0ty987 sdf0ty98 sdf6676 sdf876 sd876 sd876 sdf6 sdf6 sdf9876 sdf0t sdf06 sdf0ty9776 sdf0ty9776 sdf0ty76 sdf8876 sdf0t sd6 sdf06 s688876 sd688 sdf86