3 ms·

Thanks for the kind words. I really like Bolt. It's a wonderful library with an good API. I was inspired by the simplicity of it's transaction model. Both Bol

by tidwall 10y ago

Thanks for the kind words. I really like Bolt. It's a wonderful library with an good API. I was inspired by the simplicity of it's transaction model. Both Bolt and Bunt are ACID, and both persist data to disk. The biggest difference between them is that Bolt reads and writes from disk, while Bunt reads and writes from memory (and has an append-only file for durability). Therefore the amount of data that Bolt can handle is limited by the size the disk, while Bunt is limited by the amount of RAM. A general purpose database user will likely see a bump in performance by moving from Bolt to Bunt. What I'm seeing for my projects about 2x on reads and about a 40x on writes. I wrote a Raft store implementation that is a drop-in replacement for the the Bolt version. Here's a comparison benchmark: https://github.com/tidwall/raft-boltdb#benchmarks https://github.com/tidwall/raft-boltdb#benchmarks It really comes down to what you need. Lots of data, or lots of speed.

rakoo 10y ago
> Both Bolt and Bunt are ACID, and both persist data to disk. The biggest difference between them is that Bolt reads and writes from disk, while Bunt reads and writes from memory (and has an append-only file for durability). Just to be sure: does this mean that Bunt has a window of time where data is purely in ram only, and it is eventually persisted ? Because the description made me think that BuntDB was purely in-memor. Is there some upper limit on how much time an object may be in memory but not persisted yet ? On another note, congrats for this project. I see that you changed the default "Set" to use strings instead of bytes, this was a bit of a pain point when I used BoltDB. Indexes should also be interesting.
- tidwall 10y ago
  Bunt is a purely in-memory database, but it also persists to disk so that the database can be reopened. It's a lot like Redis in this manner. Basically, BuntDB requires that data be persisted prior to completing a transaction. There is no window of time where there is data in memory and not on disk. It's designed so that there is no way for data to exist in memory and not be on disk. I decided that strings were a better way to go because 1) the string is the most common type in a key/value database, 2) strings take up less memory than a byte slice, and 3) strings are just bytes anyhow so they can always be converted using []byte(str). Thanks for the kind words and I hope you give it a try.
  - rakoo 10y ago
    So, what about this paragraph at the end: https://github.com/tidwall/buntdb#durability-and-fsync https://github.com/tidwall/buntdb#durability-and-fsync In the default configuration there is a 1 second window where data is not fsynced to disk ?

by tidwall 10y ago

rakoo 10y ago

> Both Bolt and Bunt are ACID, and both persist data to disk. The biggest difference between them is that Bolt reads and writes from disk, while Bunt reads and writes from memory (and has an append-only file for durability). Just to be sure: does this mean that Bunt has a window of time where data is purely in ram only, and it is eventually persisted ? Because the description made me think that BuntDB was purely in-memor. Is there some upper limit on how much time an object may be in memory but not persisted yet ? On another note, congrats for this project. I see that you changed the default "Set" to use strings instead of bytes, this was a bit of a pain point when I used BoltDB. Indexes should also be interesting.

tidwall 10y ago
Bunt is a purely in-memory database, but it also persists to disk so that the database can be reopened. It's a lot like Redis in this manner. Basically, BuntDB requires that data be persisted prior to completing a transaction. There is no window of time where there is data in memory and not on disk. It's designed so that there is no way for data to exist in memory and not be on disk. I decided that strings were a better way to go because 1) the string is the most common type in a key/value database, 2) strings take up less memory than a byte slice, and 3) strings are just bytes anyhow so they can always be converted using []byte(str). Thanks for the kind words and I hope you give it a try.
- rakoo 10y ago
  So, what about this paragraph at the end: https://github.com/tidwall/buntdb#durability-and-fsync https://github.com/tidwall/buntdb#durability-and-fsync In the default configuration there is a 1 second window where data is not fsynced to disk ?