5 ms·
There are several key-value stores you can choose from. RocksDB, LevelDB, lmdb, Berkeley DB, Tokyo Cabinet, sophia, and others. What about those? You can always
by misframer 10y ago
There are several key-value stores you can choose from. RocksDB, LevelDB, lmdb, Berkeley DB, Tokyo Cabinet, sophia, and others. What about those? You can always build abstractions on top.
- lopatin 10y agoBoltDB if you'd like to embed it into a Go program.
- chaotic-good 10y agoBoltDB can be corrupted on crash (kill -9 or hard reset) at least this was the case when I gave it a try. Any database can but in that case that was easy to achieve.
- mbertschler 10y agodid you file a bug for this? I thought it was pretty resilient in such cases
- chaotic-good 10y agoI've found several submitted issues that described this problem. All this issues are closed now so maybe I was wrong about Bolt.
- qwertyuiop924 10y agoThanks for the suggestions. Some of those might work. The only problem with k/v stores is the serialization/deserialization cost, as most of them can only store strings.
- ddorian43 10y agolmdb has some special cases where you can store capnproto/flat-buffers objects and read without copying/deserializing!
- qwertyuiop924 10y agoReally? that could be useful...
- ddorian43 10y agoLMDB can hand you back a pointer to your object in the memory map, and we can easily use that pointer with Cap'n Proto without any calls to malloc(). source: https://news.ycombinator.com/item?id=12394385 https://news.ycombinator.com/item?id=12394385
- erichocean 10y ago> The only problem with k/v stores is the serialization/deserialization cost, as most of them can only store strings. I store Cap'n Proto objects directly into LMDB, and can read them without any memory allocation or deserialization cost. Freaking rocks.