Show HN: RedixDB – a fast persistent key-value store with the Redis protocol

Re:Show HN: RedixDB – a fast persistent key-value store with... by cperciva on Sunday December 23, 2018 @02:00AM (#18744850)

A somewhat more accurate title, in case it saves someone else the time I just spent: "RedixDB - a Redis frontend to the Badger key-value store".

[ Parent | on HN ]

Re:Show HN: RedixDB – a fast persistent key-value store with... by alash3al on Sunday December 23, 2018 @02:49AM (#18744971)

So, mysql is a frontend to InnoDB? Cockroach is a frontend to RocksDB?

Note: Redix has a pluggable storage engine, the current engine is "badgerdb", the next is "bolt" and it is already integrated and I'll release it soon.

[ Parent | on HN ]

Re:Show HN: RedixDB – a fast persistent key-value store with... by cperciva on Sunday December 23, 2018 @03:43AM (#18745107)

So, mysql is a frontend to InnoDB?

I would put it the other way around: InnoDB is a backend for MySQL. But an SQL database is far more complicated than a key-value store, and has a lot of "middle end" between the "talk to the client" front end and the "store stuff on disk" back end.

I'm not saying that RedixDB isn't interesting -- having a network front-end to Badger seems like it would extremely useful for most people who want to use Badger. It's just that I spent a while digging through the code trying to figure out where the back end was and what data structures you were using, only to discover that you didn't have a backend (or rather, you're using a pre-existing one).

[ Parent | on HN ]

Re:Show HN: RedixDB – a fast persistent key-value store with... by kieckerjan on Sunday December 23, 2018 @06:12AM (#18745505)

Second that. It would help if you included on the website some info about the technical implementation. That would help instill confidence in the solution.

[ Parent | on HN ]

Re:Show HN: RedixDB – a fast persistent key-value store with... by networkimprov on Sunday December 23, 2018 @03:50AM (#18745126)

None of these backends currently fsync() correctly on MacOS, due to a Go bug fixed in 1.12.

[ Parent | on HN ]

Re:Show HN: RedixDB – a fast persistent key-value store with... by fulafel on Sunday December 23, 2018 @07:34AM (#18745745)

To split hairs, the bug is in MacOS - its fsync() does not flush data to stable storage. Go 1.12 includes a workaround for this MacOS bug.

[ Parent | on HN ]

Re:Show HN: RedixDB – a fast persistent key-value store with... by networkimprov on Tuesday December 25, 2018 @05:59PM (#18759533)

To split further, it's a MacOS design flaw, with a published workaround. It is a bug to fail to use the workaround :-)

[ Parent | on HN ]

Re:Show HN: RedixDB – a fast persistent key-value store with... by fulafel on Wednesday December 26, 2018 @06:49AM (#18761726)

I don't know if Apoke really acknowledges it as a bug or flaw. Their man page for fsync reads like an intentional misunderstanding of fsync semantics.

[ Parent | on HN ]

Re:Show HN: RedixDB – a fast persistent key-value store with... by rlaanemets on Sunday December 23, 2018 @04:49AM (#18745291)

There is also Facebook's MyRocks which is MySQL frontend with RocksDB backend. It has lower write amplification than InnoDB, which is the main reason why it was created.

[ Parent | on HN ]

Re:Show HN: RedixDB – a fast persistent key-value store with... by tidwall on Sunday December 23, 2018 @10:22AM (#18746539)

RedixDB appears to provide a lot of new functionality that is not available to a plain Badger database.

I disagree that Badger plays such a big part in this project that it needs to be included in the title. Badger is only the storage component and it can be easily swapped out for an alternative.

[ Parent | on HN ]