@dcoder 我的原意是取名坚果数据库。没有想这么多哈

@xieshaohu 谢谢支持

@kulle 我不知道你的 key 是怎么设计的，假设你的 key 类似 “ user_xxx” 你可以记下最大的 key （假设最新是“user_0000100”），作为 end key，减去 49 的那个数作为 start key （即 user_0000051 ），然后 Range scans 从 user_0000051 到 user_0000100，即最新的 50 的数 （在同一个 bucket ）。

@Mitt 嗯嗯。

@Mitt 哦哦。 那我要取名字叫“坚果数据库”，要怎么翻译准确啊 [捂脸]

@hijoker
> 当时查出来 nut 坚果，复数 nuts 都是坚果，基本上可以确定 nut 原意就是坚果。你说的估计出现在一定的语境中，而且应该不常用的。 你就按我的原意理解这个名字就好了。

> 这个要具体问题具体分析了。 既然选择了 GO 开发，GC 是免不了，只能说你能接受多少 STW 的问题。老实说我没有特意去考虑解决 GC 引起的问题， 遇到问题再解决就好了。

@hijoker
> 为啥起这个名字啊?
想到坚果（ nuts ）给人印象是坚固的外壳（好比数据库很坚固）+里面营养的果实（类比装有用的数据）
> 怎么解决 gc 引起的问题?
你指的是 Go 引起的 GC 的问题？

@xiri 谢谢你 我刚自己搞定了！

赞 先收藏了

@Damnever 嗯 。后面有空去弄下大一点的数据量的性能表现。

@Damnever 是的，做全做好也是个学问，我认可的。 我也在探索中，一有空就在改进优化中。后面有精力打算做成分布式的，这是后话。数据量的话， 当前版本 nutsdb 的数据存储上限取决于你的配置，如果是默认的全内存索引模型，瓶颈是内存，还有一种是内存+磁盘索引的模式，会放下比内存大的数据量。nutsdb 的场景数据，几十 M 肯定不止的。

@Damnever 你好 我已在最新的 master 和当前最新的版本 v0.3.0 支持了 强同步。真正支持了 D （持久化），性能报告也重新更新了。欢迎帮我 review，如有问题帮我指正。thank ；）

@Damnever 认同 “导致了一些严重错误的东西被掩盖对于其它学习”， 已经更新了 README 在警告说明处做了阐述，我还会继续更新文档的，让我好好整理下。谢谢 Damnever 关注。有问题 我继续改。
另外大家希望多多提 issue。
@1892 有问题直接去项目提 issue 哦。

@BBCCBB 谢谢支持 可以看下这个 https://github.com/edsrzf/mmap-go，我用了这个 github.com/grandecola/mmap

@Damnever 好的 我再想想。谢谢你。

@srt180 redis 我一般当做缓存来用，不会去当 db 使用，事务支持也很弱。不过他的支持丰富的数据结构真的很棒。nutsdb 的数据结构 api 就是模仿他的名字命名。至于 lua 脚本的方式 ，我没试过，不过我在想在代码里写脚本 ，优点是灵活 缺点有点像直接写原生 sql 的感觉，不好维护 也不好看吧。最好 Redis 原生支持最好。

@Damnever 谢谢你的意见建议。为了保证 ACID 的 D 特性 每次 commit 你都必须的 flush/sync，这个我理解的，强一致性。nutsdb 的实现为了写性能更高，现在对 nutsdb 的做法有点缓冲的味道，到 unmap 的时候才能保证数据一定落盘。
” ACID 也不是说你简单加个锁就保证“，能多说一点吗？

@JohnSmith 我发现数据还是会更新到磁盘的。我是调用了 unmap，可能再加个 flush 的话更保障一点。

@runningman 谢谢 你说的很中肯哈