Live data from Hacker News

IceFireDB: Distributed disk storage database based on Raft and Redis protocol

github.com

1–10 of 71 posts

Re: IceFireDB: Distributed disk storage database based on Raft and Redis protocol

#2

  SET: 253232.12 requests per second
  GET: 2130875.50 requests per second
The 10:1 throughput ratio for GET vs SET is interesting. Redis being in-memory, the rates there are pretty close to the same for read/write.

Is a 10:1 ratio typical for a storage backed distributed kv store?

Edit: Looks like CockroachDb has roughly a 3:1 ratio, similar for YugabyteDB:

https://www.cockroachlabs.com/docs/stable/performance.html

https://forum.yugabyte.com/t/large-cluster-perf-1-25-nodes/5...

Also ~3:1 for etcd:

https://etcd.io/docs/v3.4/op-guide/performance/

Re: IceFireDB: Distributed disk storage database based on Raft and Redis protocol

#4
post #2

SET: 253232.12 requests per second GET: 2130875.50 requests per second The 10:1 throughput ratio for GET vs SET is interesting. Redis being in-memory, the rates there are pretty close to the same for read/write. Is a 10:1 ratio typical for a storage backed distributed kv store? Edit: Looks like CockroachDb has roughly a 3:1 ratio, similar for YugabyteDB: https://www.cockroachlabs.com/docs/stable/performance.html http…

Raft involves waiting for fsync on a majority of nodes, so that's not too surprising.

'Typical' is a matter of what guarantees you want to give.

Re: IceFireDB: Distributed disk storage database based on Raft and Redis protocol

#5
post #2

SET: 253232.12 requests per second GET: 2130875.50 requests per second The 10:1 throughput ratio for GET vs SET is interesting. Redis being in-memory, the rates there are pretty close to the same for read/write. Is a 10:1 ratio typical for a storage backed distributed kv store? Edit: Looks like CockroachDb has roughly a 3:1 ratio, similar for YugabyteDB: https://www.cockroachlabs.com/docs/stable/performance.html http…

Often reads of data already committed only need to hit one node but writes need to wait for a majority so they need to wait for multiple nodes to receive and acknowledge the write.

I haven't checked the code though so I might be off.

Re: IceFireDB: Distributed disk storage database based on Raft and Redis protocol

#6

Not quite sure what this is supposed to be good for.

I'd guess for "I want redis, but more durable clustering" (although I don't quite remember how much redis nowadays offers there itself). Would want a lot more info before trusting it for that though.

Re: IceFireDB: Distributed disk storage database based on Raft and Redis protocol

#7

Not quite sure what this is supposed to be good for.

It speaks Redis so ideally it can replace Redis in cases where persistence is required.

There are already several community solutions for Redis persistence - this one provides different guarantees.

The name implies the goal is to make it easy to mix "hot" (from memory) and "cold" (from disk) data. The author suggests this.

Re: IceFireDB: Distributed disk storage database based on Raft and Redis protocol

#8
post #7

Not quite sure what this is supposed to be good for.

It speaks Redis so ideally it can replace Redis in cases where persistence is required. There are already several community solutions for Redis persistence - this one provides different guarantees. The name implies the goal is to make it easy to mix "hot" (from memory) and "cold" (from disk) data. The author suggests this.

Redis itself already supports a number of persistence schemes and has since the beginning: https://redis.io/topics/persistence

Re: IceFireDB: Distributed disk storage database based on Raft and Redis protocol

#9
One of the child comments made the observation that "this speaks Redis."

Makes me wonder if there is any spec for the Redis commands. I.e., in the same way that SQL defines an interface, but leaves the details up to individual implementations, is there a "Redis" interface that leaves the details up to the implementation?

I'm thinking of something similar to ISO or RFC.

Post reply on HN