Database RocksDB

[tredoe]

Instead of RocksDB, you could use a database built in Go (to a better deploy):

• Bolt is a pure Go key/value store inspired by the LMDB project. Bolt currently works on Mac OS and Linux. Windows support is coming soon.

https://github.com/boltdb/bolt
https://godoc.org/github.com/boltdb/bolt

• Package kv implements a simple and easy to use persistent key/value (KV) store:

https://github.com/cznic/kv
http://godoc.org/github.com/cznic/kv

[andybons]

I’m a big fan of Bolt (and Ben, for that matter). However, do you have
reasons other than a less painful deploy to switch?

RocksDB is mature, fast, tunable, and used in very large scale production
environments.

Bolt is still in beta.

I’m not familiar enough with kv to make an educated judgement of it. Is it
used heavily in production somewhere?

On Wed, Apr 23, 2014 at 5:42 AM, Jonas mg [email protected] wrote:

Instead of RocksDB, you could use a database built in Go (to a better
deploy):

• Bolt is a pure Go key/value store inspired by the LMDB project. Bolt
  currently works on Mac OS and Linux. Windows support is coming soon.

https://github.com/boltdb/bolt

https://godoc.org/github.com/boltdb/bolt

• Package kv implements a simple and easy to use persistent key/value
  (KV) store:

https://github.com/cznic/kv
http://godoc.org/github.com/cznic/kv

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/14
.

[strangemonad]

Hey @kless thanks for your feedback.

At some point, it might make sense to allow plugging in different KV stores as the durability backends. Think about how Riak allows you to use bitcask vs leveldb vs rocksdb. In the riak case, you end up choosing between them based on the the characteristics of your key-space (e.g. sparse vs dense). Anyway, random aside.

As for rocks db, the fact that it's key-value (and shares that in common with bolt) is somewhat superficial. We're going to make much more heavy use of the fact that

• it's an LSM / SST store
• it supports efficient range scans
• it has a plug-able compactor (that scales well on multi-core machines).
• fine-grained control over file system flushing.

To answer this question in another way, bolt is actually too high-level for our needs (if we're hoping to implement this in an efficient way). E.g. storing things in a b-tree, providing ACID and MVCC at this level would introduce too much overhead in our lowest level layer (raw storage).

hope this makes sense.

[tredoe]

@strangemonad yeah, it makes sense. Thanks for for leave it so clear.