News for hackers. Stuff that matters.
Re:RocksDB – A persistent key-value store for fast storage e... by gfodor on Thursday November 14, 2013 @07:52PM (#6736989)
this is cool, though I'd wonder how it compares to Kyoto Cabinet. another big issue I've run into personally is the fact that both LevelDB and KC don't explicitly support multiple processes reading the db at once. (KC's API allows this but advises against it, LevelDB afaik doesn't even allow it.) I wonder if RocksDB gets past this.
Re:RocksDB – A persistent key-value store for fast storage e... by dhruba_b on Thursday November 14, 2013 @09:36PM (#6737342)
RocksDB allows only one process to open the DB in read-write mode but other process can access the DB read-only (with a few configuration settings)
Re:RocksDB – A persistent key-value store for fast storage e... by stass on Thursday November 14, 2013 @09:30PM (#6737318)
If you just need concurrent reading and update the database from a single process, you can use CDB. It always served me well.
Re:RocksDB – A persistent key-value store for fast storage e... by hyc_symas on Thursday November 14, 2013 @11:10PM (#6737687)
Kyoto Cabinet will self-corrupt if you use it that way. LMDB supports multi-process explicitly.
Re:RocksDB – A persistent key-value store for fast storage e... by gfodor on Friday November 15, 2013 @12:31AM (#6737909)
can you explain how this happens? if it's just a read-only process, how can it corrupt anything?
Re:RocksDB – A persistent key-value store for fast storage e... by maaku on Thursday November 14, 2013 @08:03PM (#6737042)
HyperDex?