There is also github.com/robaho/keydb which uses LSM and transactions and it is very fast :)
> On Mar 12, 2019, at 1:10 AM, xujiajun <[email protected]> wrote: > > Hi, guys. i share you a key/value store named NutsDB. > > NutsDB is a simple, fast, embeddable and persistent key/value store written > in pure Go. > > It supports fully serializable transactions and many data structures such as > list、set、sorted set. All operations happen inside a Tx. Tx represents a > transaction, which can be read-only or read-write. Read-only transactions can > read values for a given bucket and given key or iterate over a set of > key-value pairs. Read-write transactions can update and delete keys from the > DB. > > This project is still in the experimental stage and has not passed the test > of the actual production environment. Welcome to issue and contribute > > > > see repository link: https://github.com/xujiajun/nutsdb for detail. > > > Motivation > > I wanted a simple, fast, embeddable and persistent key/value store written in > pure Go. And if it supports more data structures such as list, set, sorted > set，it will be better. > > > > There are some options around the embeddable kv store in Go: > > > > 1. BoltDB,it is based on B+ tree, has a good random read performance and > awesome sequential scan performance, and it supports ACID transactions with > serializable isolation, but it is terrible at random write performance and > not supports more data structures such as list etc. > > > > 2. GoLevelDB is based on a log-structured merge-tree (LSM tree), but it not > supports transactions and more data structures. > > > > 3. Badger is based on LSM tree with value log. It designed for SSDs. It also > supports transactions. But its write performance is not as good as i > thought.And it also not supports more data structures. > > > > So i tried to build a kv store by myself, i wanted to find a simple store > engine model as reference. Finally i found the bitcask model. It is simple > and easy to implement. Howerver it has its limition,like range or prefix > queries are not effcient. For example, you can not easily scan over all keys > between user000000 and user999999, you had to look up each key individully in > the hashmap. > > In order to break the limition, i tried to optimize them. Finally i did it > and named NutsDB. > > > > And it still has a lot of room for optimization. Welcome contributions to > NutsDB. > > > > > > > > -- > You received this message because you are subscribed to the Google Groups > "golang-nuts" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to [email protected]. > For more options, visit https://groups.google.com/d/optout. -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. For more options, visit https://groups.google.com/d/optout.
